CI失敗の仕分けとインシデント対応のためのAIエージェント

真夜中に失敗するデプロイは、もう誰も起こすべきではありません。しかし多くのチームでは、いまだにオンコールのエンジニアが冷たいログを開き、原因となったコミットを探し、他のメンバーに知らせるSlackメッセージを打っています。自律型AIエージェントは、根本原因や修正に関する人の判断を決して置き換えることなく、この最初のステップを引き受けられます。

問題

CI/CDパイプラインの信頼性に関する数字は芳しくありません。CircleCIの2026年版State of Software Deliveryレポートによると、メインブランチのビルド成功率は70.8%まで落ち込み、過去5年間で最低の水準となり、同社が推奨する90%の閾値を大きく下回っています(CircleCI, 2026)。具体的には、およそ10回のマージ試行のうち3回が、本番環境に到達する前に失敗している計算になります。

インシデント対応の面では、2026年初めに公開されたRunframeのState of Incident Managementレポートが、定型的な運用業務(アラート対応、失敗の仕分け、情報のエスカレーション)に費やされるエンジニアリング時間の割合が30%に戻り、AIへの投資にもかかわらず5年ぶりに増加に転じたと指摘しています(Runframe, 2026)。同レポートは、毎日生成されるアラートのおよそ3分の2が、適切に仕分ける時間がないために無視されていると推計しています。これは慎重に受け止めるべき目安です。このレポートは複数の外部調査と定性的なヒアリングを集約したものであり、単一の直接測定ではありません。

AIを活用したソフトウェア開発に関するDORA 2025レポートも、ある根本的な点で同じ方向を示しています。AIはすでに組織にあるものを増幅するのであり、乱れた仕分けプロセスを修正するのではなく、それをより速く、より目立つ形にするだけだというものです(DORA, 2025)。監視の行き届いていないパイプラインは、AIがあってもなくても、誰かが失敗を継続的に見ていない限りそのままです。

この最後の点は、少人数のオンコール体制で複数のサービスを同時に監視するチームにとって特に重要です。深夜3時に発生したビルド失敗は、一般に誰かが目覚めるまで仕分けを待ってはくれません。朝まで無視されたままになるか、あるいは仕分けてみれば軽微だと分かる問題のために誰かを起こしてしまうかのどちらかです。どちらの結末もコストがかかります。一方は解決までの時間、もう一方は長期的に蓄積するオンコール疲労です。

エージェントが行うこと、ステップごとに

Atako上では、このエージェントは一度だけ起動してそれで終わるのではなく、専用の隔離環境の中で継続的に稼働します。2つの入力経路がこれを支えています。チームが設定してCI/CDイベントを受け取る受信Webhookと、Webhookがイベントを取りこぼした場合に備えてエージェント自身がスケジュールする、ワークフローの状態を定期的に確認するcronタスクです。

失敗が発生すると、エージェントはジョブのログとスタックトレースを読み、問題の種類(コンパイル、テスト、依存関係、デプロイ)を分類したうえで、直近のコミットとプルリクエストに関連付けて、おそらくの作成者と疑わしい変更を特定します。次に、ジョブと該当コミットへの直接リンクを添えて、オンコールチャンネルのSlackに構造化された要約を投稿し、並行してビルドに紐づいたJiraチケットを起票します。重大度がチームの定めた閾値(デプロイのブロック、複数サービスへの波及)を超えた場合は、追加のエスカレーションが適切な担当者に届きます。最後に、インシデントレポートの初稿を作成します。時系列、影響を受けたサービス、関連ログ、疑われる原因です。これは確定的な結論としてではなく、人によるレビューを前提として意図的に開かれた形で残されます。

活用するインテグレーション

各インテグレーションは、エージェントに何ができるかを正確に制限する個別のグラントを通じて許可され、ツール全体への汎用的なアクセスが与えられることは決してありません。

GitHubとGitLabは、パイプライン、ジョブ、コミットの読み取りを提供し、グラントがそのスコープをカバーしていればissueの作成やコメントといった書き込みも任意で行えます。GitHub側で実際に使われるアクションは、読み取り側がlist_workflow_runsとget_job_logs_download_url、書き込み側がcreate_issueとadd_issue_commentです。

Slackは、チームが選んだチャンネルにpost_message経由で仕分けの要約を受け取り、インシデントが長く未解決のままの場合はschedule_message経由でリマインダーを予約する機能も使えます。

Jiraはインシデントチケットそのものを担います。起票時のcreate_issue、解決に至るまでのupdate_issueとtransition_issueです。

Datadogは、チームが接続している場合、パフォーマンス指標とアプリケーショントレースをCI失敗と突き合わせて根本原因の仮説を精緻化するのに使えます。PagerDutyは現時点でAtako上に専用のインテグレーションページはありませんが、Jira側またはSlack側で設定した送信Webhookを通じてアラートの送信先として利用できます。

人に残る作業

エージェントが単独で修正のマージを決めることは決してありません。これは設計上の細部ではなく、Atakoが自律性をどう構造化しているかを示すものです。エージェントがGitHub、GitLab、Jira、Slackで実行できるすべての行動は、明示的なグラントに依存します。どの行動が正確に許可されているか、どのスコープ(読み取り専用か、読み書き)かということです。このスコープは、書き込みアクションが誤って読み取り専用の許可一覧に紛れ込んだ場合でも優先され、ツールを接続しただけで何かがデフォルトで許可されることは決してありません。

これにより、3つのことが明確に人側に残ります。まず、根本原因の調査と修正の技術的な判断です。エージェントはログ、疑わしいコミット、履歴という出発点を提供しますが、確定的な診断ではありません。次に、コードの記述とマージです。本質的に人による行動であり、エージェントができることの範囲外です。最後に、ポストモーテムです。重大度の閾値を調整し、ランブックを見直し、仕分けルールを改善する、エージェントが代わることのできないチームの作業です。

この役割分担はヒューマン・イン・ザ・ループと呼ばれるものにあたります。エージェントは仕分けの反復的で時間のかかる部分を引き受け、人は本当に重要な判断の主導権を握り続けます。エージェントが実際に何を行ったかを検証できるよう、すべてのインテグレーション呼び出しは記録され、対象のエージェント、行動、状態(許可・実行済み、グラント制御による拒否、またはプロバイダー側でのエラー)、レイテンシーが残ります。この記録はエージェントのアクティビティタイムラインで確認でき、管理者であれば、CSVエクスポートに対応した全社インテグレーションログでも確認できます。

測定可能な成果

最も直接的な効果は、ビルドが失敗してから、適切な人が行動するために十分な情報を得るまでの時間です。人がアラートに気づき、ログを開き、直近のコミットと手作業で突き合わせるのを待つ必要はもうありません。エージェントはそれを継続的に行い、深夜3時であっても、週の負荷によって気分が変わることもなく実行します。デプロイ頻度や失敗後の復旧時間といった従来のDORA指標を置き換えるものではありませんが、これらの指標がある瞬間の人の可用性だけに左右される部分を減らします。

コストはAtakoのStandardプランに従い、エージェントスロットあたり月額20ユーロ、思考・分類・執筆に使われるモデル呼び出しをカバーする1,000クレジットが毎月付与されます。導入前に投資回収を試算するには、料金ページに詳細があります。