サブエージェントに指示が伝わらない理由は、子が委任文しか知らないこと

親エージェントは、会話の履歴、読み込んだファイル、合格の基準、過去の失敗を持っています。子エージェントは別のコンテキストで起動するため、そのどれも知りません。子が知っているのは、親が渡した委任文だけです。

人間の組織に置き換えると、前任者の頭の中にだけある引き継ぎ事項を、メモ1枚で後任に渡すのと同じ状況です。メモに書かなかった前提は、無かったことになります。

点検で見つかった3つの欠落

2026年6月10日の点検で、全コマンドに共通して見つかった欠落は次の3つです。

  • 品質バーが子に伝わっていない：出典を付ける、捏造しない、といった基準を委任文に書いていなかった
  • 報告の様式が決まっていない：子が何をどの形で返すかを指定していなかった
  • 結果が食い違ったときの決め方が無い：複数の子が逆の結論を返したとき、どちらを採るかの手順が無かった

3つとも、親の側では当たり前に持っている基準です。当たり前のものほど、書かなければ子には届きません。

サブエージェントへの委任に入れる6要素と、欠けたときの問題

relmea の規約（社内では delegation-standards と呼んでいます）は、委任プロンプトに必ず含める要素を6つに定めています。

6要素の一覧

  1. 任務の1行定義：何を、どの範囲で、何のために調べる・作るのか。曖昧なテーマ名だけを渡さない
  2. 読むべきファイル：判断の根拠にしてよい資料のパスを明示する
  3. 品質バー：数値・事実には出典（URL、ファイルパス、コマンドの実出力）を添える。捏造は禁止。取れない情報は「不明」と書き、推測で埋めない
  4. 成果物の形式：構造、分量の目安、保存先のパス。保存するときは今日の実際の日付を使う
  5. 報告様式：完了時に「保存先パス、要点3点、人間の確認が必要な事項」を5行以内で返す
  6. 失敗時の挙動：要件を満たせないときは、できた範囲、できなかった理由、必要な追加情報を報告する。黙って薄い成果物を返さない

欠けると何が起きるか

点検で実際に欠けていたのは、品質バー、報告様式、矛盾解決の3つです。残りの要素について以下に書くことは規約の趣旨からの推定で、relmea が各要素の欠落による被害を個別に記録したものではありません。

  • 1行定義が無いと、子は範囲を自分で決めます。調べすぎるか、浅く済ませるかのどちらかになります
  • 読むべきファイルが無いと、子は手元の知識か検索結果だけで答えます。社内の基準や過去の決定は反映されません
  • 品質バーが無いと、出典の無い数字が混ざります。親が気づかなければ、そのまま統合されます
  • 成果物の形式が無いと、子ごとに構成がばらばらになり、統合の手間が増えます
  • 報告様式が無いと、親は長い報告を毎回読み解くことになります
  • 失敗時の挙動が無いと、要件を満たせなかった子が、それらしい成果物を返す余地が残ります。この項目は、後で触れる「空振りの扱い」とつながっています

委任文の実例：調査コマンドの指示は1行から何に変わったか

規約を作った同じコミット（2026年6月10日）で、調査用の consult コマンドも書き換えました。委任に関わる部分の変更前後を、そのまま引用します。

変更前

子を起動する指示は、次の1行だけでした。

「general-purpose を複数並列起動して一次調査を任せる」

何を調べるのか、どの基準で返すのか、どの形で報告するのかが、どこにも書かれていません。親は頭の中に持っていますが、子には届きません。

変更後

テーマを2〜4の調査面に分解し、面ごとに子を1体ずつ起動する形になりました。1体が1面を担当します。5面以上に膨らむ場合は、人間に分割を提案します。各体への委任プロンプトには、次の3つを必ず含めます。

  • 調査面の1行定義：何を、どの範囲で調べるか。例として「国内事例と価格相場」「技術的実現方式の比較」「失敗事例と落とし穴」が挙げられています
  • 品質バー：出典2件以上、数値は引用元のURLかファイルパスを明記、捏造禁止、取れない情報は「不明」と書く
  • 報告様式：「要点5点以内、出典リスト、この面で結論が出なかった点」で返す

「この面で結論が出なかった点」を報告に含めさせているところが、失敗時の挙動の要素に対応します。

委任の前後にも手を入れた

同じ書き換えで、委任の前後の工程も変わっています。

  • 着手前に、成果物の合格基準を3〜5項目で先に決めて提示する工程を足しました。委任文に書くべき「何をもって良しとするか」が、先に決まります
  • 追加調査は、合格基準と突き合わせた不足リストにある項目だけを起動する形にしました
  • 最後の精査は、実装と別のコンテキストで行います。精査役の子に「この成果物を懐疑的にレビューし、基準未達・事実誤り・抜けを列挙せよ」と委任する形です

効果について

コミットの記録には「consult再テスト: 委任文が白紙状態から必須要素完備の全文生成に改善したことを実証」とあります。ただし、再テストの回数や数値は記録に残っていません。そのため、何割良くなったという言い方はここではしません。確かに言えるのは、上で引用した差分の中身、つまり委任文が1行から、要素のそろった構造化された指示に変わったことです。

サブエージェントの結果を受け取る側の規則：矛盾と空振りの扱い

委任文を整えても、複数の子が返す結果は食い違うことがあります。規約は、統合する親側のルールも定めています。

結果が食い違ったときの優先順位

  1. 一次データが推測に優先：実測値、実ログ、実コマンド出力を持つ見解を採ります
  2. 新しいデータが古いデータに優先：取得日を確認します
  3. 専門領域の当事者が隣接領域に優先：そのドメイン専任の子の判定を採ります
  4. 上の3つで決まらなければ、両論を併記して人間の確認事項に上げます

採らなかった見解も握りつぶさず、統合報告に1行で残します。規約の書き方では「Bは〜と判定したが一次データ優先でAを採用」という形です。後から読む人が、何が捨てられたかを辿れます。

空振りとゼロ件の扱い

  • 検索や参照がゼロ件でも、黙って進みません。「参照0件のため〜なしで進む」と報告に明示します
  • 子が1体でも無応答かエラーだった場合は、その欠落を統合報告に書きます。全員分そろった体裁で書きません

ゼロ件を黙って流すと、読み手は「調べたうえで何も無かった」のか「調べていない」のか区別できません。

並列で起動するときの注意

複数の子を同時に走らせる場合は、書き込み先の衝突や、他の子の成果物を誤って壊す事故への備えが別途要ります。relmea では2026年7月19日にその規約を追加しました。同じ走行の中で、他のエージェントの成果物を異物と誤認して壊しにいく事故が3件続いたことがきっかけです。7月26日には、同時に1体しか触れない実体（GUIアプリ本体など）の扱いも追記しています。詳しくはAIエージェントの並列実行で競合を防ぐに書いたので、ここでは触れる程度にとどめます。

自分の運用にサブエージェントの委任規約を入れる手順

最後に、同じことを自分の環境で始める手順を示します。6月10日の展開は、規約ファイルを1本作り、各コマンドから参照させる形でした。

手順

  1. いま子に渡している委任文を3本ほど取り出します。実際に送った文面を使い、記憶で書き直さないでください
  2. それぞれに6要素が含まれているかを、1つずつ確認します。点検で見つかった3つの欠落（品質バー、報告様式、矛盾解決）から見ると、見つけやすくなります
  3. 6要素と矛盾解決のルールを、規約ファイルとして1本にまとめます。コマンドごとに文面を複製せず、規約ファイルを正本にして参照させます
  4. 各コマンドの委任部分に、規約を参照するブロックを足します。relmea は事業系17コマンドへこのブロックを追加し、consult を含めて計18コマンドになりました
  5. 書き換えた委任文で1回再テストし、委任文に必須要素がそろっているかを確認します

規約が増えたあとの状態

2026年10月19日に数えたところ、規約を参照しているコマンドは70本中57本、サブエージェント定義は15体でした（コマンド定義とエージェント定義のファイルを検索して数えた実測です）。制定時の18コマンドから、運用の中で参照が広がっています。

規約そのものも固定ではありません。履歴上は、6月10日の制定後に7月19日（並列起動）、7月26日（同時に1体しか触れない実体）と追記が続いています。9月19日と10月14日にも改訂がありますが、本稿では扱いません。実際に起きた事故のたびに、足りなかった項目を足してきた形です。

最初から完全な規約を作る必要はありません。まず6要素を委任文に入れ、事故が出たら項目を足していく進め方で足ります。