Claude Code のオーケストレーター用サブエージェントを廃止した理由——公式harness仕様に基づく構造的な3つの制約

AIエージェント Claude Code サブエージェント 運用 設計

はじめに

複数のAIに作業を分担させる構成を組んだとき、最初に置いた役割の一つが「差配役」だった。誰にどの順で何を任せるかを決め、結果を検証してから次に渡す——人間のチームで言えばプロジェクトリーダーに近い。この役だけを担当するAIを一段挟む設計は、直感的には合理的に見える。

だが実際に運用してみると、この役は構造的に機能しないことが分かった。しかもその根拠は、好みや勘ではなく、Claude Codeの公式仕様書(harnessに関する仕様)に明記されていた。この記事は、差配役を廃止した理由を3点整理し、さらに数週間後に自分の説明文を原文と照合し直したときに見つかった、小さいが見過ごせない誤りまでを記録する。

欠陥① 本人に確認する手段を持たない

差配役に与えていた運用ルールには「判断に迷ったら本人に確認する」という一文があった。もっともらしく見えるが、公式仕様には次のようにある。

The first filter removes these tools, even when listed in the tools field:

  • AskUserQuestion

本人に問いかけるための道具は、下位のAIが持つツールの許可リストに明記していても、一律に取り上げられる。つまり「確認する」という選択肢そのものが、道具として存在しない。「迷ったら聞け」という指示は、聞く手段を持たない相手には「自分で決めろ」と同義になっていた。

欠陥② 結果を受け取れない

作業を任せた結果は、いつ返ってくるのか。公式の説明はこうだ。

As of v2.1.198, subagents run in the background by default.

A background subagent’s results reach Claude as a completion notification in a later turn.

既定の実行方式は「バックグラウンド」——結果を待たずに次へ進み、報告は「後のターン」に届く。問題は、任せる側自身も下位のAIだった場合に起きる。差配役がさらに下位へ作業を投げると、その報告は差配役の「後のターン」に届くはずだが、差配役自身は作業を投げた時点で自分のターンを終えており、受け取る側がどこにも存在しない。実際にこの形で、報告が来ないまま作業が止まる場面が複数回起きた。

欠陥③ 申告を検証できない

差配役の定義には、状態を自分で確かめる道具(シェルコマンドを実行する権限)が入っていなかった。だから下位のAIが「やった」と申告してきても、それを裏取りせずそのまま上へ流すしかない。実際に「ブランチを作成させた」という報告に対し、変更ファイルもブランチもコミットも実測ではゼロ件だった、ということが起きた。

構造の外側にも、もう一つの根拠があった

3つの欠陥とは別に、Anthropic自身がharness設計について書いた文章にも、差配役を置く設計を裏付けにくくする一文があった。

Separating the agent doing the work from the agent judging it proves to be a strong lever … tuning a standalone evaluator to be skeptical turns out to be far more tractable than making a generator critical of its own work.

Out of the box, Claude is a poor QA agent. In early runs, I watched it identify legitimate issues, then talk itself into deciding they weren’t a big deal and approve the work anyway.

差配役は「作業させる」と「検証する」の両方を一人で兼ねる位置に立ちやすい。だが公式の観測では、自分が出した結果を自分で評価させると、明らかに凡庸な出来でも自信満々に褒めるという。作業役と評価役を分けること自体が効くレバーであり、単一の差配役に両方を担わせる構成は、この知見と逆を向いていた。

廃止した設計

3つの構造的欠陥とこの知見を踏まえて、差配だけを行う役割そのものを無くし、作業を任せる側が直接、実行役と検証役を指揮する形に戻した。安全装置の適用範囲も、下位のAI発の実行を不必要に塞がないよう調整した。

2026-08-06: 単一の「差配役」を介して作業を委譲する設計

      ├─▶ 欠陥① 本人に聞けない
      │       └─ 確認のための道具が全サブエージェントから無条件で除去される(公式)

      ├─▶ 欠陥② 結果を受け取れない
      │       └─ 既定は「後のターンに結果が届く」実行方式
      │             └─ 差配役自身がサブエージェントだと、受け取り先が存在しない
      │                   (戻りエッジ: 実際に複数回、報告なしで止まった)

      └─▶ 欠陥③ 申告を検証できない
              └─ 差配役の定義にシェル実行権限が無い
                    └─ 「やった」という報告をそのまま上へ流すしかない


   +もう一つの根拠: 自己評価は機能しない(公式harness知見)


   差配役という役割を廃止。実行役と検証役を直接指揮する構成へ

      ▼ …(2週間後、同じ一次資料を読み直す)
2026-08-19: 「本人に聞けない」の根拠として自分が書いた説明文を、公式原文と一字ずつ照合

      └─▶ 条件節が1つ欠けていたと判明
              (戻りエッジ: 廃止という判断は揺るがなかったが、根拠の引用精度に欠陥があった)

現在の実測 ― 差配役は本当に無くなっているか

説明だけで終わらせず、現在の運用構成を実際に確認した。作業を任せる下位のAIの定義ファイル一式を数えると、次のようになっていた(2026-08-24実測・ファイル名は役割ラベルに置き換え)。

$ grep -H "^model:" <定義ファイル群>
<review-agent-1>.md:model: opus
<work-agent-1>.md:model: sonnet
<work-agent-2>.md:model: sonnet
<work-agent-3>.md:model: sonnet
<review-agent-2>.md:model: opus
<work-agent-4>.md:model: sonnet
<work-agent-5>.md:model: sonnet
<review-agent-3>.md:model: opus
<work-agent-6>.md:model: sonnet

$ ls <定義ファイル群> | wc -l
9

検証役3体・作業役6体の計9体。差配専用の役割は、定義ファイルとして存在しない。 廃止の判断は、記述だけでなく実際の構成にも反映されていた。

数週間後、自分の引用のほうに欠陥が見つかった

差配役を廃止してから2週間ほど経ったころ、同じ公式仕様書を読み直す機会があった。今度は「これまでの判断は正しかったか」ではなく、「自分がどう引用していたか」を、原文と一字ずつ突き合わせる形で読んだ。

すると、廃止の根拠として自分が書いていた説明文に、こうあった。

AskUserQuestion は全サブエージェントから無条件で剥奪される。EnterPlanMode / ExitPlanMode も同様。

一方、公式原文はこうなっていた。

  • Agent, when the subagent is at the depth limit; in a fork the tool stays listed but returns an error instead of spawning
  • AskUserQuestion
  • EnterPlanMode
  • ExitPlanMode, unless the subagent’s permissionMode is plan

AskUserQuestion に条件は無い。だが ExitPlanMode には 「動作モードがplanでない限り」という条件が付いているAgent にも「階層の深さが上限に達した時だけ」という条件がある。自分の説明文は、この条件付きの項目を「同様に無条件」とまとめてしまっていた。廃止という判断そのものは、AskUserQuestionの無条件除去という核心部分で揺るがなかったが、周辺の引用には条件節の欠落という誤りが混ざっていた。

一次資料を引用するときに条件節を落として一般化する——これは今回に限った話ではなく、繰り返し起きてきた型の誤りでもある。一度書いた説明文を「もう確認済みだから」と読み返さずに使い続けていたら、この欠落には気づけなかった。

廃止の判断は、廃止して終わりではない

差配役という一段を無くしたことで、報告が届かない・裏取りできないという構造的な問題は解消した。だが、その判断を支えた説明文自体を後から検証し直したことで、構造の理解は正しくても、それを言語化した一文には誤りが混ざりうることが分かった。判断と、その判断を書き残した文章は、別々に検証する必要がある。

AIエージェントに「判断は人間に確認して」と書いても実行されない — Claude Code サブエージェントの制約と、委譲設計のやり直し

Claude Code の「キャッシュが壊れる」を一次資料まで遡る——Reddit の不具合報告→公式postmortem→arXiv論文2本

Claude Code の output style はサブエージェントに継承されない——公式仕様と実地検証

Claude Code のモデルは画面に出ないまま切り替わる — 「検証は上位モデルで死守」を崩しうる設定1行を、公式仕様789行の通読で見つけた

一段を減らしたのは、その役が力不足だったからではない。「判断が要るときに人へ渡す」ことが、その位置からは構造的にできなかった——できない役に司令を任せていたという、配置の誤りだった。廃止して困ったことは、今のところ一つも出ていない。

気軽にメッセージください

仕事の依頼、案件紹介、ご感想・ご質問なんでもお待ちしております。 高い志をもった同士の皆様と繋がることを切に願っております。 これからも人生を掛けたチャレンジを続けていきます。 何卒よろしくお願い致します。