Claude Code の多エージェント運用を「設計スレッド」で止める — Orca オーケストレーション実践

はじめに：並列エージェントは「止め方」で成否が決まる

Claude CodeなどのAIツールが進化し、単なるコード生成から「複数エージェントを連携させた自律開発」へとパラダイムが移行しつつあります。サブエージェント（Subagents）や並列処理を駆使すれば、複雑なタスクも自動化できると期待が高まっています。

しかし、実務でマルチエージェントを稼働させたことがある方なら、次のような課題に直面したはずです。「エージェントがいつの間にか作業を脱線して終わらない」「勝手に合格基準を曲解して、無限ループに陥る」。席を外している間にトークン上限に達し、Gitの履歴が散らかっていた……という経験を持つ方も少なくないでしょう。

結論から言えば、並列エージェント運用の最大の壁は「いかに走らせるか」ではなく「いかに止めるか」にあります。本記事では、複数エージェントによる開発体制（Orcaオーケストレーション）において、AIの暴走を防ぎ、設計スレッド（メインセッション）から確実に手綱を引くための実践的な運用手法を、実際の事故ログや生々しいプロンプトとともに解説します。

1. 多エージェント運用の黄金比：設計・実装・レビューの3層分離

なぜ同一セッションで完結させてはいけないのか

Claude Codeを動かす際、1つのターミナルセッションですべての作業（仕様確認、コード変更、テスト、修正）を行おうとすると、すぐに破綻します。会話履歴が長くなるにつれてコンテキストが汚染され、AIが「何を作るべきか」という初期の目的を見失うからです。

また、実装を担当したAIにそのまま自己レビューをさせると、特有の自己評価バイアスが働き、「テストが通らないのは環境のせいだ」「ひとまず動くからこれで完了としよう」と都合よく解釈する罠に陥ります。

設計・実装・レビューの物理的・論理的境界

コンテキスト汚染と自己採点の罠を防ぐため、実運用では設計・実装・レビューの3層分離が基本となります。

• 設計スレッド（メインセッション）： オーケストレーターとして機能します。ゴールを定義し、各ワーカーの進捗を監視・制御する役割に専念します。
• 実装ワーカー（Git worktree）： git worktree コマンドで物理的に独立した作業ディレクトリを用意し、そこで Claude Code を走らせます。これにより、他の作業とファイルの競合を起こさずに並列開発が可能になります。
• レビューワーカー（別インスタンス）： 実装ワーカーの自己採点を信用せず、全く別のインスタンスからコードの差分やテスト結果を客観的に評価させます。

このアーキテクチャにより、役割が明確化され、問題発生時の切り分けが容易になります。

2. 制御の生命線：worker_done / escalation / gate の使い分け

どこまでをAIに委譲し、どこで人間の手綱を引くか

エージェントの自律性を高める一方で、暴走を防ぐためには「状態（ステート）」の管理が必要です。実務では、以下の3つのシグナル（合図）を明確にルール化し、AIに使い分けさせます。

• worker_done：AIが「タスクを完了した」と自己判定した状態です。ただし、これを鵜呑みにせず、設計スレッド側でレビュープロセスへ回します。
• escalation：AIがエラーを解決できず、「これ以上の進行は不可能」と判断して助けを求めてきた状態です。
• gate：次のステップに進む前に、必ず人間の承認（Human-in-the-loop）を要求する関所です。

判断をAIに丸投げしない「gate（承認関所）」の組み込み方

特に重要なのが gate の設定です。例えば、「データベースのスキーマを変更する」「外部APIのモックを外して本番結合する」といった不可逆な操作や、コストに直結するプロセスの前には、設計スレッド側で必ず待機させます。

「実装が完了したら、gate を宣言して待機してください。私がレビュー結果を確認し、承認するまでマージ処理には進まないこと」とプロンプトで事前に制約をかけることで、重大な事故を未然に防げます。

3. 【実録事故】合格条件を自己解釈したワーカーが「終わらないループ」に突入した日

ここからは、実際に起きた生々しいトラブル事例を見てみましょう。

ログ分析：終わらないラウンド

ある開発プロジェクトで、テストの修正をワーカーに依頼しました。しかし、数十分経ってもプロセスが終了しません。

ログを確認すると、ワーカーは次のような挙動を繰り返していました。

1. テストが失敗する。
2. 修正コードを書く。
3. 再度テストが失敗する。
4. 「次はアプローチを変えます」と宣言し、不要なリファクタリングを始める。
5. 別のテストが壊れる。

当初の目的は「特定の単体テストを通すこと」でしたが、ワーカーはいつの間にか「周辺コード全体の最適化」へと合格条件を勝手に書き換え、終わらないラウンド（ループ）に突入していたのです。

AI特有の認知バイアス

これは、LLM特有の「まだ足りない」「直したつもり」という認知バイアスが原因です。AIは与えられたタスクを完了させようとするあまり、問題の根本原因ではなく表面的なエラーメッセージの解消に固執したり、スコープを逸脱したりする傾向があります。自律的に動けるからこそ、ゴールがブレたときの脱線も激しいのです。

4. 暴走をねじ伏せる「設計スレッドからの割り込みメッセージ」術

エージェントが暴走し始めたら、即座にオーケストレーター（設計スレッド）から介入しなければなりません。

「ゴールの絞り直し」を上書きする実効プロンプト

暴走を止めるには、抽象的な指示ではなく、冷徹かつ具体的な「ゴールの絞り直し」が必要です。実際に効果があった割り込みプロンプトの例を紹介します。

割り込みプロンプト例： 「現在の修正方針はスコープ外です。リファクタリングを中止し、〇〇ファイルのみを修正して、エラーコード500を解消することだけに集中してください。それ以外の変更はすべて破棄（git restore）してください。」

このように、作業スコープを極限まで狭め、具体的なアクション（git restore）まで指定して上書きします。

「ラウンド5で停止」「新規ワーカー起動禁止」の介入プロトコル

さらに、終わらないループを強制終了させるための介入プロトコルも設定します。実際のログで使用した指示がこちらです。

介入プロトコル例： 「ラウンド5が終わったらループを止めてください。テストが通っていなくても、そこでいったん停止して現在の状況を報告すること。また、新しいレビューワーカーは絶対に起動しないこと。」

「〇〇回で諦める」という撤退ラインを明確に指示することで、トークンの浪費と無意味な変更の連鎖を断ち切ることができます。

5. /loop を「監視カメラ」にする：5分ごとの進捗報告テンプレート

Claude Code には、一定の条件や周期でプロンプトを再実行・監視できる /loop コマンドが備わっています。これをオーケストレーター側の「監視カメラ」として活用します。

「本当に作業しているか？」を可視化する

AIが「作業中です」と出力していても、実際には裏でエラーを吐いて停止していることがあります。「本当に作業しているの？変更したファイルを見せて」と疑う姿勢が必要です。

git status や git diff --stat などのファイル変更確認コマンドを定期的に叩かせることで、エージェントが「実際に何をしているか」を可視化します。

そのまま使える進捗報告プロンプトテンプレート

実務ですぐに使える、5分ごとの進捗報告プロンプトテンプレートを用意しました。設計スレッドで以下のように設定します。

/loop 5m
以下のフォーマットで現在の進捗を報告してください。

【確認事項】
1. 現在のタスクの目標は何か？
2. 直近5分間で実行したコマンドと、変更したファイルは何か？ (`git diff --stat` の結果を含めること)
3. 発生しているエラーやブロック事項はあるか？
4. 次の5分間で何をする予定か？

※ 注意：報告以外の作業（ファイルの編集など）は行わず、状況の可視化のみに徹すること。

この監視ループを回しておくことで、エージェントが脱線し始めた兆候を早期に検知し、前述の「割り込みメッセージ」で軌道修正を図ることが可能になります。

6. まとめ：自律開発ループを成功させる「停止条件の事前定義」

ループエンジニアリングにおける鉄則チェックリスト

Claude Code を使ったマルチエージェント運用を成功させるためには、いかに走らせるか以上に「いかに止めるか」が重要です。自律開発ループを回す前に、以下の鉄則を確認してください。

• 設計・実装・レビューを物理的（worktree）に分離しているか？
• worker_done / escalation / gate のシグナルを定義しているか？
• ループの最大回数（ラウンド上限）を明確に指示しているか？
• 万が一暴走した際の「割り込みプロンプト」を準備しているか？
• /loop コマンドを活用した定期監視プロセスを導入しているか？

「停止条件を最初に決めておく」ことこそが、ループエンジニアリングを安全に運用するための最大の教訓です。

実務現場でスケールさせるための次のステップ

AIエージェントを用いた開発体制の構築は、単なるツールの導入ではなく、アーキテクチャの設計と運用ガバナンスの確立です。

個人開発の枠を超え、チームでの本番導入を目指す際には、プロジェクトに合わせたカスタマイズやオーケストレーション基盤の整備が必要になります。AIエージェントを使った開発体制の構築やオーケストレーション導入は、実務運用のノウハウを持つグランドリームにご相談ください。現場に即したガバナンスと自動化設計を支援します。