複数のAIエージェント（自律的にタスクを実行するAIプログラム）を組み合わせて開発作業を進める「マルチエージェントワークフロー」を試すチームが増えています。
Codex（OpenAIのコード生成・実行エージェント）やClaude Code（Anthropicのコーディング支援エージェント）、Gemini Code Assist（Googleのコード支援エージェント）など、役割の異なるAIを並行稼働させる構成です。この記事はSRE（Site Reliability Engineering、信頼性を工学的に担保する運用手法）やインフラ基盤の担当者に向けて、この構成が本番運用に忍び込んだときに起きる落とし穴を整理します。
複数のAIエージェントを個別に導入した経験がある方、あるいはこれから導入を検討している方の参考になれば幸いです。
何が起きるか：責任境界のないエージェント群が障害対応を遅らせる
AIエージェントを1体だけ使っているうちは問題が見えにくいものです。
しかし実行役・レビュー役・検証役といった複数のエージェントを並行させ始めると、誰が最終判断をしたのかが曖昧になっていきます。
ある構成では、Codexがファイルにパッチを適用し、Claudeがアーキテクチャやリスクをレビューし、GeminiやCopilotが探索的な検証を担当するという役割分担が試みられています。この体制自体は理にかなっていますが、権限（permissions）とログ（traces、実行の痕跡）が整備されていないと、障害発生時に「どのエージェントの変更が原因か」を追えなくなります。
これはインシデント対応の文脈で見ると深刻です。オンコール担当者が深夜に呼び出されたとき、まず必要なのは「直近の変更が何で、誰が承認したか」という情報です。エージェントが自律的にコードを書き換え、別のエージェントがレビューしたことになっているだけの状態では、この情報が実質的に失われます。
議事録のない会議に例えると分かりやすいかもしれません。参加者（エージェント）はそれぞれ発言（出力）していますが、誰が何を決めたかの記録がなければ、後から検証も再現もできません。
なぜ起きるか：権限とログの設計を後回しにするから
原因を段階的に分解すると、3つの層に分かれます。
1つ目は役割の対称性の誤解です。複数のAIモデルを「対等なセカンドオピニオン」として並べてしまうと、意見の集約コストが跳ね上がります。長いタスクの途中で中断が入ると、どの仮説が検証済みで、どのファイルが変更中で、どの検証が保留中かという文脈（コンテキスト）を失いやすくなります。
2つ目は権限設計の欠如です。実行役のエージェントが自分の変更を自分でしか検証しない構成では、クリティカルな変更に対する唯一の検証者になってしまいます。これはコードレビューで「自己承認のプルリクエスト」を許すのと同じリスク構造です。
3つ目はトレーサビリティ（追跡可能性）の欠如です。どのエージェントがいつ、どのMCP（Model Context Protocol、AIとツールを接続する標準規格）ツールを呼び出し、どんな根拠（evidence）を残したかが記録されていないと、事後のポストモーテム（障害振り返り）が成立しません。
Codex、Claude Code、Gemini Code Assistはいずれも設定ファイルやフック（hooks）機構を提供しています。Claude CodeにはPreToolUse・PostToolUse・SessionStartといったフックがあり、ツール呼び出しの前後で処理を挟めます。これらを使わずデフォルト設定のまま複数エージェントを走らせると、権限もログも素通しの状態になります。
自分のプロジェクトが該当するか確認する方法
以下の項目に1つでも当てはまる場合、権限とトレーサビリティの設計を見直す価値があります。
- CI/CDパイプラインやローカル開発環境でAIエージェントに直接ファイル変更やコマンド実行を許可している
- 複数のAIツール（Copilot・Claude Code・Codexなど）を同じリポジトリで併用している
- エージェントが生成した変更に対して、人間のレビューを経ずにマージされる経路がある
- インシデント発生時に「どのエージェントがいつ何を変更したか」を追う手段がログや監査証跡として存在しない
確認コマンドとしては、まずリポジトリ内にエージェント設定ファイルがあるかを確認します。
find . -iname "AGENTS.md" -o -iname "routing.yaml" -o -iname ".claude" -o -iname "*.copilot*"これらのファイルが存在する場合、中身を開いて primary（主実行者）や reviewer（レビュー者）、escalate_to（エスカレーション先）のような役割定義があるかを見ます。定義がなければ、権限がフラットなまま運用されている可能性が高いです。
CI側では、AIエージェントが生成したコミットにレビュー必須のブランチ保護ルールがかかっているかをGitHub・GitLabの設定画面で確認します。ブランチ保護がなければ、自己承認マージを防ぐ仕組みが存在しないことになります。
対策の手順
対策は大きく3つの段階に分けて進められます。
まず、役割定義をコードとして明文化します。実行役・レビュー役・検証役・エスカレーション先（人間）を1つの設定ファイルにまとめる方法が有効です。例えば以下のような構成です。
id: agent_ops_policy
planner: codex
primary: codex
reviewer: claude
escalate_to: human
validator_chain: [gemini]
mcp_policy:
mode: controlledここでのポイントは、escalate_to: human を明示することです。リスクを伴う判断は必ず人間の承認を経由させる設計にします。
次に、クリティカルな変更については単一エージェントによる自己検証を禁止します。IaC（Infrastructure as Code、インフラをコードで管理する手法）ツールであるTerraformやPulumiのplan結果をAIエージェントが自動applyする構成は特に危険です。少なくとも本番環境への適用は、別エージェントか人間によるplan差分レビューを必須にします。
最後に、実行ログをオブザーバビリティ基盤に統合します。エージェントの実行結果・使用したMCPツール・変更ファイルをOpenTelemetry（分散トレーシングの標準規格）やログ基盤に送り、通常のアプリケーションログと同じ検索軸で追えるようにします。これにより、ポストモーテムで「AIが何を根拠に変更したか」を再現できます。
まとめ
複数のAIエージェントを並行稼働させる構成は、生産性を高める一方で、責任境界が曖昧になるリスクを抱えています。
確認すべきは、リポジトリ内の設定ファイル（AGENTS.md・routing.yaml・.claude配下など）に役割定義があるか、ブランチ保護でAI生成コミットのレビューが強制されているかの2点です。
対策としては、役割定義のコード化、クリティカル変更での自己検証禁止、実行ログのオブザーバビリティ統合という3段階を順に進めることをおすすめします。
まずは手元のリポジトリで find . -iname "AGENTS.md" を実行し、エージェント設定の有無を確認するところから始めてみてください。