9月19日、asyncdot.comが「Orchestrating Claude Code Agents: The Chief of Staff Pattern」と題した記事を公開した。Claude Codeエージェントを「チーフオブスタッフ」パターンでオーケストレーションし、長時間タスクにおけるコンテキスト消滅と自己報告ズレの問題を解決する設計について詳述している。なお、asyncdot.comは後述するPlan Deskの開発・運営元であり、その点を念頭に置いて読まれたい。
AIエージェントが長時間タスクで失敗する本当の理由
AIコーディングエージェントが1時間程度のタスクはこなせても、それ以上になると失敗しがちな理由は、コードが書けないからではない。コンテキストが揮発性であること、そして自己報告が現実とズレることに起因する。
具体的には3つの問題が発生する。
- コンテキストの圧縮（compaction）による情報劣化 ── 長いセッションでは過去の詳細が要約に変換され、重要なニュアンスが失われる
- 自己報告のズレ ── 「テストが通った」というエージェントの報告は、最新の観測結果ではなく、「記憶」と「意図」の組み合わせにすぎない
- 学習の持続性ゼロ ── セッション2時間目に得た教訓は、次のセッションでどこかに書き残していない限り消える
エージェントを増やしても解決しない。むしろ「信頼性の低い報告者」が増えるだけで、それを統合する役割が存在しなければ問題は倍増する。
チーフオブスタッフパターンとは何か
この問題への解法は技術的というより組織論的だ。
チーフオブスタッフパターンとは、1つの長命セッションが調整役を担い、別の短命セッションが実装を行うエージェント・オーケストレーション構造のこと。 調整役（コーディネーター）は作業を割り当て、結果を検証し、共有状態を管理する。実装はしない。
同様の構造はすでに複数の名前で知られている。
- オーケストレーター・ワーカー（階層的オーケストレーション）
- Coordinator-Implementor-Verifier（CIV）
- メーカー・チェッカー（金融・オペレーション由来）
- インテグレーション・マネージャー（Gitの分散ワークフローで文書化されているもの）
コーディネーターの役割は明確だ。タスクを引き出してブリーフを書き、実行セッションの「言ったこと」ではなく差分（diff）を読む。そして教訓を永続ストアに記録する。絶対に実装コードを書かない。コーディネーターがコーディングを始めた瞬間、パターンは崩壊して単一の過負荷セッションに逆戻りする。
実装に必要な3つのコンポーネント
1. セッション基盤：Claude Code × cmux
Claude Codeがセッション自体（ツール使用、ファイル編集、シェルアクセス）を提供する。各セッションは独立したコンテキストウィンドウを持つ。この隔離性こそが設計上の意図であり、あるセッションの混乱が他に伝染しない。
セッション管理にはcmuxを使う。コマンドラインから操作可能で、コーディネーターが新しい実行セッションをスポーンできる。
cmux workspace create \
--name project-session-12 \
--cwd /path/to/repo \
--command 'claude "Read docs/briefs/current.md and do exactly what it says."'
ここで2点が重要で、どちらも実際に失敗して学ぶタイプのミスだ。
--commandはシェルにテキストを送るだけで、エージェントを起動するわけではない。エージェントの明示的な呼び出しが必要- プロンプトは短くし、ファイルを参照させる。長い文字列は実行が不安定になる上、レビューや再実行が困難
2. 永続状態ストア：Plan Desk
Plan DeskはMCP（Model Context Protocol）経由でエージェントに公開されるプランニングボードだ。コーディネーターとすべての実行セッションが同一ボードを読み書きする。なお、Plan Deskはassyncdot.com（本記事の著者サイト）が開発・提供している自社プロダクトである。
ボードがメモリだ。セッションは使い捨て、ボードは違う。 このコンポーネントを省略したマルチエージェント構成が一晩持たない理由がここにある。
ボードには以下を置く。
- タスクをビルドコントラクトとして記述 ── 問題定義、アクション、インターフェース、検証条件、非ゴール。実行セッションが親ドキュメントを読まなくても完了できる粒度で
- ステータスはアトミックに更新 ── 開始時に
in_progress、検証完了時にdone。セッション終了時にまとめて更新するボードは信頼できない - 設計ドキュメントのリンク、コメント欄への推論記録
検証規律：このパターンの核心
複数のエージェントを走らせるだけの手法と、このパターンを分けるのが検証の厳格さだ。
報告は「証拠」であって「事実」ではない
実行セッションが「スイート全49件グリーン、失敗ゼロ」と報告したとき、コーディネーターの仕事はそれが本当かどうかを確かめることだ。エージェントが嘘をつくからではなく、「報告の対象」と「実際にチェックした対象」が別物であることが多いからだ。
記事で紹介される典型的な失敗例：あるセッションがコミットハッシュをログファイルに手書きし、git cat-fileで検証した。ところが検証はシェル変数の短いハッシュに対して行われており、ファイルに書き込まれた文字列とは別物だった。どちらのチェックも成功し、ファイルには解決不能なハッシュが残った。
ルール：アーティファクトの検証は、アーティファクト自体から値を読み返すことで行う。書き込んだと思っている変数からではなく。
最も多い欠陥クラス
AIエージェントを用いたソフトウェア開発（本記事では「エージェニックエンジニアリング」と呼ばれる、エージェントが自律的にコードを書き・検証し・コミットするエンジニアリング手法）において、最も頻繁に発生する失敗は、「実際には実行していない処理の成功を報告するチェック」だ。
| パターン | 見た目 | 騙される理由 |
|---|---|---|
| 空の検証 | 機能の有無に関わらず通るテスト | テスト対象を削除しても緑のまま |
| サイレント非マッチ | 何もマッチしないgrep/フィルタ | 0件が「クリーン」に見える |
| エラーチェック | そもそも実行できなかったコマンド | エラーが飲み込まれ、不在が証拠になる |
| スコープ不一致 | 一部だけへの緑チェックを全体として提示 | 分母が明示されない |
基本的な防御策： マッチしない可能性のあるチェックは必ずそのことを明示すること。ゼロ件と実行失敗は区別できなければならない。「何も悪いことは起きなかった」という主張には、同じ実行内でポジティブコントロールが必要だ。
この検証規律こそが、「複数エージェントを並列で走らせているだけの構成」と「チーフオブスタッフパターン」を本質的に分かつポイントだ。コーディネーターが独立した観測者として差分を読み、証拠を再実行する役割を担うことで、自己報告のズレが構造的に遮断される。
運用ループと実装上のチェックリスト
作業ループは1タスク・1ディスパッチ・1コミットを単位とする。
1. PULL ボードから次のブロックされていないタスクを取得
2. READ 関連する設計ドキュメントを先に読む
3. RED GATE 検証器を先に実行し、必ず失敗することを確認
4. DELEGATE 実行セッションにブリーフを渡す
5. PROVE 主張されたコマンドを全て再実行し、終了コードで判断
6. OBSERVE 差分をハンクごとに読む
7. GATE 承認レーンを解決し、推論を記録
8. SHIP ステータスを更新し、そのアイテムだけをコミット
レッドゲートが最初に来る理由： チェックが最初から緑なら、実装が正しいのか、チェックが機能していないのか区別できない。また、キュー内のタスクの一定数はすでに別のカードで実装済みか、後続の変更で不要になっていることがある。レッドゲートが数秒で緑に戻れば、1時間分の無駄な実装を防げる。
1コミット1アイテムの理由： GitログとボードカードがN対Nに対応する。3日後に何かが壊れたとき、症状から意思決定までの経路がgit log一発でたどれる。
このループは「コーディネーターが実装しない」という原則と表裏一体だ。各ステップでコーディネーターが行うのは取得・読解・委譲・検証・記録のみであり、コードを生成する工程がどこにも存在しない。これがパターンの整合性を保つ鍵となる。
詳細はOrchestrating Claude Code Agents: The Chief of Staff Patternを参照していただきたい。
