AIを使うことと、AIで業務を回すことは違う。
チャット画面に毎回同じ説明を書き、結果をコピーし、人が次の処理を起動する。それでは、AIを使っていても仕事の流れは人間の手作業のままです。
必要だったのは、人間が普段使うDiscordを入口にしながら、AIがファイル、Git、API、テスト、デプロイ結果へ安全に到達できる仕組みでした。さらに、複数のAIが同じファイルを触らないための調整や、失敗したAIを外側から監視する仕組みも要ります。
依頼、実行、記録、監視、修正を一本の運用としてつなげました。
会話から、修正PRまで。
Discordで依頼
人間は普段の言葉で相談。専用管理画面を覚えません。
CCDBが実行
Claude Code／Codexを選び、会話と権限を保って処理します。
Schedulerが監視
定刻、ポーリング、失敗回数など用途に合う方式で起動します。
AIが調査・修正
ログとコードを読み、隔離したworktreeで変更してテストします。
PRとCIで確認
変更履歴を残し、テストを通してから反映します。
監視AIが、繰り返す起動失敗を見つけた。
2026年7月、外部スキルの設定不足によってAIの起動が繰り返し失敗していました。Bot本体は動いていたため、サービス全体の死活監視だけでは見逃す種類の問題です。
定期監視が直近12時間のログから異常を検出し、原因をYAML frontmatterの不足まで切り分けました。その後、修正、validatorによる確認、パッケージ再生成、Issue／PR、実配置での再検証まで実施。Bot/APIは対応中もhealth 200を維持しました。
| 監視 | 実際の運用 |
|---|---|
| Botエラーログ | 毎日0時・12時。対応不要な一時障害と、繰り返す実装不良を分類 |
| Scheduler自己診断 | 毎日7時30分。ジョブ定義、スケジュール、スクリプト、最新ログを検査 |
| 連続失敗 | 毎時。24時間で3回以上連続失敗したジョブを別系統から検知 |
| 品質ゲート | worktreeで隔離し、対象テスト、全体テスト、PR、CIを経て変更 |
何でも自動変更させるのではなく、無視してよいエラー、AIが直せる範囲、人間が承認すべき変更を分けています。
この仕組みを、そのまま売る必要はありません。
実行基盤の設計
社内で使えるAI、API、データ、権限、監査の条件を整理します。
定型業務の自動化
基盤がなくても、決まった入力と出力があれば一つのシステムとして作れます。
AI Opsの導入
監視結果の要約、原因調査、修正案、テスト、承認フローを段階的につなぎます。
記録は2026年7月29日までのCCDB、Scheduler、Agent Loop Runtimeの自社運用ログに基づきます。2,004回・100%は2026年7月26日に実施した直近7日間の週次レビュー値です。