AI・機械学習
Claudeコードエージェントのオーケストレーション:Chief of Staffパターン
Orchestrating Claude Code Agents: The Chief of Staff Pattern (asyncdot.com)
要約
この記事では、AIコーディングにおける「Chief of Staff」パターンを紹介しています。これは、単一のAIセッションのコンテキストの揮発性と報告の信頼性の低さという問題を解決するための組織的なアプローチです。このパターンでは、1つの「オーケストレーター」セッションが作業の調整、検証、状態管理を行い、複数の「ワーカー」セッションが実際のコーディング作業を実行します。状態はセッションのコンテキストではなく、永続的な外部ストア(例:プランニングボード)に保存され、すべての主張は再実行されて検証されます。これにより、長期間にわたるAIコーディングタスクの信頼性と堅牢性が向上します。
全文翻訳
← ブログに戻る
2026年9月19日
agents claude-code orchestration ai-tools engineering
Claudeコードエージェントのオーケストレーション:Chief of Staffパターン
1つのセッションが調整と検証を行い、他のセッションが実行し、永続的なボードが状態を保持する。
長期間実行されるClaudeコードエージェントのためのオーケストレーター・ワーカー・ループ。
長期間のAIコーディング作業が失敗するのは、エージェントがコードを書けないからではなく、コンテキストが一時的で、自己報告が信頼できないためであることが多い。その解決策は技術的なものではなく、組織的なものである。1つのセッションが調整と検証を行い、個別のセッションが実行し、永続的な外部ボードが状態を保持し、すべての主張は信じられる前に再実行される。
その形状はすでにオーケストレーター・ワーカー、またはコーディネーター・インプリメンター・ベリファイアとして知られている。Chief of Staff(最高業務責任者)は、私たちがそれを呼ぶ名前である。
これは、ループ、それを実用的にするツール、そしてそれが捕捉するために存在する障害モードをカバーしている。
TL;DR
オーケストレーションを実行から分離する。
調整セッションは、ブリーフを作成し、主張を検証し、差分を読み取る。実装作業は行わない。
状態はコンテキストではなく、永続的なストアに置く。
ボード、またはAPIを持つ外部タスクシステムは、コンパクション、セッションの終了、ハンドオフを生き延びる。会話コンテキストはそうではない。
すべてのエージェントのレポートを指示ではなく証拠として扱う。
コマンドを再実行する。
終了コードは権威があり、要約は意図である。
永続的なチャネルに書き込む。
セッション間のメッセージは遅延したり、保持されたり、期限切れになったりする可能性がある。コミットされたファイルやボードのカードは常に届く。
サーフェシングのためのタイムボックス、カットのためのものではない。
固定間隔で報告の頻度が決まるが、作業がどこで止まるかは決まらない。
自分の計測器を信用しない。
エージェント作業で最も高価なエラーは、実行されなかった作業に対して成功を報告するチェックから生じる。
この問題は何を解決するか?
単一のAIコーディングセッションは、1時間程度はうまく機能するが、それ以降は劣化する。3つの問題が発生する。
コンテキストは有限で、損失がある。長時間のセッションは圧縮される。3時間前に重要だった詳細は要約になり、その要約は詳細を有用にした具体性を失う。
自己報告は現実から乖離する。「テストはパスした」と言うエージェントは、新鮮な観測ではなく、その意図と記憶を報告している。両者の間のギャップはセッションの長さとともに広がる。
何も積み重ならない。2時間目に痛いほど学んだ教訓は、誰かが次のセッションが読む場所に書き留めない限り、次のセッションでは失われる。
エージェントを増やすことはこれを解決しない。それはそれを増幅させる。今や、複数の信頼できない報告者がいて、それらを調和させる者は誰もいない。
これを解決するのは、人間の組織から借用した分業である。仕事をするのではなく、何が真実かを知ることを仕事とする誰か。
これはプロトタイプを製品として出荷するものと区別するのと同じ規律である。生成ステップが決してボトルネックではなかった。チェックステップがボトルネックである。
Chief of Staffパターンとは何か?
Chief of Staffは、1つの長寿命セッションがコーディネーターとして機能し、作業を割り当て、主張を検証し、共有状態を維持し、一方、個別の短寿命セッションが実装を実行するエージェントオーケストレーションの形状に対する私たちの名前である。
最も速いメンタルモデルが欲しいなら、インテグレーションマネージャーと考えてほしい。Gitのインテグレーションマネージャーワークフローでは、貢献者は自分のリポジトリで作業し、1人のメンテナーが各変更をプルし、ローカルでテストし、参照リポジトリに何が取り込まれるかを決定する。コーディネーターは、エージェントセッションの代わりに、その仕事をする。
この名前は、私たちが有用だと感じる比喩である。確立された用語ではなく、認識する必要はない。その下の形状はよく知られており、いくつかの実際の名前がある。
これは通常何と呼ばれるか
オーケストレーター・ワーカー、またはスーパーバイザーまたは階層型オーケストレーション。
コーディネーター・インプリメンター・ベリファイア(CIV)。
メーカー・チェッカー、または金融およびオペレーションから借用した検証チェーン。
インテグレーションマネージャー、人間のバージョン、これはGitの分散ワークフローで、これよりずっと前に文書化されている。
そのオープンソースのバリアントは、慈悲深い独裁者と副官である。
チームリードとチームメイト、これはClaudeコード自身のサブエージェントドキュメントがそれをフレーミングする方法である。
それらはすべて同じことを言っている。1つのエージェントが計画しチェックし、他が作業を行い、共有状態は単一のコンテキストウィンドウの外に存在する。
先行事例を探しているなら、この用語ではなくそれらの用語で検索してください。
この記事が追加するのは形状そのものではない。それは、より下流の検証規律と、長期間の自律実行を破る特定の障害モードである。
1つの曖昧さの解消
Chief of staff agentというフレーズは、別の目的で広く使われている。それは、個人のカレンダー、受信トレイ、優先順位を管理し、専門エージェントに作業をルーティングするアシスタントである。Anthropicのクックブックには、スタートアップのCEOのために構築されたまさにその種のChief of Staffエージェントがある。同じ比喩、異なる問題。この記事はコーディングループに関するものである。
コーディネーターの仕事
調整セッションはオーバーウォッチと呼ばれることもある。その責任:
永続的なキューから、定義された順序で作業をプルして割り当てる。
コーディネーターの判断なしでも、弱いモデルが従えるようなブリーフを作成する。
実行セッションが実行したと主張するコマンドを再実行して、主張を検証する。
トランスクリプトではなく、差分を読む。何が取り込まれたかが重要であり、エージェントがそれについて言ったことは重要ではない。
セッションが終了する前に、永続的な成果物に教訓を記録する。
作業を取り上げることなく、ドリフトしているセッションを誘導する。
それが明確に行わないことは、実装を書くことである。コーディネーターがコーディングを開始した瞬間、それは検証を停止し、パターンは単一の過負荷セッションに崩壊する。
3つのコンポーネント
3つのものが必要である。特定のツールは交換可能だが、役割はそうではない。
1. エージェントランタイム:Claude Code
Claude Codeはセッション自体を提供する。ツール使用、ファイル編集、シェルアクセス、およびセッション間のメッセージング機能。
各セッションには独自のコンテキストウィンドウがあり、それがポイントである。1つのセッションの混乱が他のセッションに汚染しないため、分離は機能である。
2. セッション基盤:cmux
cmuxはターミナルワークスペースを管理し、コマンドラインから駆動できるため、スクリプト化可能である。
コーディネーターは次のように実行セッションを起動する:
cmux workspace create \
--name project-session-1
--cwd /path/to/repo \
--command 'claude "Read docs/briefs/current.md and do exactly what it says."'
そのコマンドの2つの点は重要であり、両方とも学習に実際の時間が必要である。
--commandはワークスペースのシェルにテキストを送信する。エージェントを開始するわけではない。エージェントを明示的に呼び出す必要がある。生の指示は実行できないシェルで入力され、ランチャーは成功を報告する。
プロンプトを短くし、ファイルを指すようにする。長いコマンド文字列は確実に実行されない。コミットされたブリーフを指す短いプロンプトの方が堅牢であり、ブリーフをレビュー可能で再実行可能にする。これはシェル履歴に埋め込まれた文字列ではできない。
3. 永続的な状態ストア:Plan Desk
Plan Deskは、MCP経由でエージェントに公開されるプランニングボードである。プロジェクト、目標、依存関係を持つタスク、リンクされた設計ドキュメント、コメント。
コーディネーターとすべての実行セッションが同じボードを読み書きする。これは人々がスキップするコンポーネントであり、スキップすることがマルチエージェントセットアップが一晩中持続しない理由である。
ボードはメモリである。セッションは使い捨てだが、ボードはそうではない。
ボード上に存在するものは以下の通り:
タスクはビルド契約として。
問題ステートメント、アクションアイテム、インターフェース、検証契約、非目標。
実行セッションが作業を完了するために親ドキュメントを読む必要がないほど詳細である。
作業と同時にアトミックに切り替わるステータス。開始した瞬間にin_progress、検証された瞬間にdone。
セッションの最後にバッチ処理されることはない。なぜなら、スタンドダウン時にのみ真実であるボードはボードではないからだ。
それらを管理する設計ドキュメントがタスクにリンクされている。
コメント、人間が指示を残し、エージェントが理由を残す場所。
オペレーティングループ
一度に1つの作業項目。
1回のディスパッチ。
1回のコミット。
1. ボードから次のブロックされていないタスクをPULLする
2. リンクされた設計ドキュメントをREADする。作業を完了する前に。