エージェントアーキテクチャとオーケストレーション

音声は3本です。ノートのほうが例と図が厚いので、先に該当節を読んでから聞くと残りやすいです。

• 🎧 ループと判断の主体原稿を読む
• 🎧 委任とコンテキスト原稿を読む
• 🎧 強制、分解、セッション原稿を読む

この章でできるようになること

ツールを何度も使う仕事を、モデルの一回の返答で終わらせない。複数のエージェントに分けたとき、誰が全体を見て、何を明示的に渡し、どこをプログラムで止めるかを決められる。仕事の分け方と、昨日の会話を今日続けるかどうかも選べる。

30秒で全体像

モデルはツールを実行しない。呼び出してほしい、と書き、ハーネスが実行して結果を会話に戻す。その繰り返しがエージェントループで、止める合図は stop_reason の end_turn、続ける合図は tool_use です。複数人に分けるときは、サブエージェント同士を直結せず、コーディネーターが依頼と結果を持ちます。サブエージェントは親の会話を自動では見ません。返金のように順序を外すと事故になる箇所は、文章ではなくゲートとフックで止めます。レビューのように面が決まっている仕事は順番に分け、調査のように次の問いが途中で生まれる仕事は計画を更新します。昨日のツール結果が今日のファイルと食い違うなら、その会話の再開は嘘を引き継ぎます。

用語

本編

ループは、モデルと実行側のキャッチボール

モデルの一回の呼び出しは、それまでの会話を読んで、次のメッセージを一つ返すだけです。ファイルを開くことも、返金APIを叩くことも、モデルのプロセスの中では起きません。起きるのは「このツールを、この引数で呼んでほしい」という宣言です。実行するのは、あなたのプログラムです。このプログラムをハーネスと呼びます。

返答には停止理由が付きます。tool_use なら、宣言されたツールを実行し、結果を会話に足し、同じモデルへ次の依頼を送ります。end_turn なら、モデルは利用者への返答を終えたと判断しています。ループを閉じます。

flowchart TD
  A[会話を添えてモデルを呼ぶ] --> B{stop_reason}
  B -->|tool_use| C[宣言されたツールを実行]
  C --> D[結果を会話履歴に追加]
  D --> A
  B -->|end_turn| E[利用者へ最終応答]

返品の例で、三往復を追います。利用者は「注文 A-19 の壊れたヘッドホンを返金して」と言いました。

1. 一回目の返答は tool_use で、顧客確認ツールを要求します。ハーネスが実行し、「顧客は確認済み、ID は C-42」を履歴に足します。
2. 二回目も tool_use で、注文参照を要求します。結果は「ヘッドホン、配送済み、金額 8000」。これも履歴に足します。
3. 三回目は、方針の範囲内だとモデルが判断し、返金ツールを要求します。結果が成功なら、四回目は end_turn で「返金しました」と利用者に話して終わります。

結果を履歴に戻さないと、二回目のモデルは一回目の利用者の文しか見ません。顧客IDを知らないので、注文を当てにいくか、もう一度同じ確認を要求します。モデルに隠しメモリはありません。次の判断材料は、トランスクリプトに入っているものだけです。

止める合図を文章に読まない

モデルはツールの前に、「確認します」と文章を書くことがあります。文章があることは、仕事が終わったことではありません。逆に、最終返答が短くても end_turn なら終わっています。空の文章を完了の印にすると、ツール直前の短いつなぎを完了と誤認するか、最終の一文が空に近いときに終わったのにループを続けます。

自然文の「完了しました」も主たる停止条件にしません。モデルはその語を、まだツールが必要な途中でも書きます。パーサが語を拾ってループを切ると、返金の直前で止まります。

回数の上限は、暴走したときのヒューズです。完了の定義ではありません。上限が先に発火すると、返金の途中で利用者に中途半端な状態を返します。ヒューズは残してよいです。ただし分岐の本体は stop_reason です。

トークン上限で返答が途中切断された場合も、end_turn ではありません。ツール呼び出しのJSONが欠けたまま成功扱いにすると、実行側は壊れた引数を叩きます。切断は修復（予算を足して続け直す、または失敗として返す）であり、完了ではありません。

次のツールを選ぶのはモデルか、決定木か

モデル主導では、モデルが説明と会話を見て次のツールを選びます。「返品の方針だけ教えて」には顧客確認も返金も要りません。「この注文を返金して」には確認と参照が要ります。決定木は、この差を事前に全部書き切る必要があります。書き漏れた枝は、木が間違ったツールを呼びます。

決定木が勝つのは、順序が安全の不変条件であるときだけです。その話は後のゲートです。普段の分岐まで木にすると、方針の質問でも返金APIの手前まで進みます。

失敗の型は、ツール列をプロンプトに固定することです。「必ず顧客、注文、返金の順」と書くと、モデルはだいたい従います。従わない回が残ります。従わせたいのが事故防止なら、プロンプトではなくゲートです。従わせたいのが効率なら、モデルに選ばせたほうが、不要な呼び出しを減らせます。

コーディネーターがハブになる理由

サブエージェントは、別の会話です。親の履歴はコピーされません。呼び出しと呼び出しのあいだでメモリも共有しません。検索役が「さっきの文書の続き」とだけ渡されても、さっきの文書はその会話にありません。

だから通信はコーディネーター経由にします。検索、文書分析、統合が互いの会話へ直接書く形は、経路が掛け算で増え、エラーの形がばらつき、ログの一点が消えます。コーディネーターだけが、利用者の目的と、全部の結果を同時に見られます。

flowchart LR
  U[利用者の目的] --> C[コーディネーター]
  C --> S[検索]
  C --> D[文書分析]
  C --> Y[統合]
  S --> C
  D --> C
  Y --> C

コーディネーターの仕事は四つです。目的をサブタスクに分ける。誰を呼ぶか選ぶ。結果を集める。穴があれば絞って呼び直す。

毎回、検索も分析も統合も通す必要はありません。「この用語の定義は」で全文検索から始めると、待ちと費用だけが増えます。問い合わせを見て、呼ぶ相手を選びます。

範囲の割り方は、重ねすぎないことです。題目で分けるか、情報源の種類で分けるかです。同じ三本の記事を二人に読ませると、統合は重複を消す仕事に時間を使います。

下流が成功しても、全体は欠け得る

「創作産業への影響」を、視覚表現の三題だけに割ったとします。検索は視覚の記事を見つけ、文書分析はそれを要約し、統合は一貫した文章を書きます。音楽も執筆も映像も、誰も失敗していません。割り当てられていないだけです。

原因を下流の性能に置くと、検索クエリを増やしても視覚の中で詳しくなるだけです。直すのはコーディネーターの分解です。題目の全体を先に列挙し、各サブタスクがどの部分を担うかを明示します。

穴が見えたあとの動きもコーディネーターの仕事です。統合の出力に「音楽は未調査」とあれば、検索へその題だけ再委任し、戻ったら統合をやり直します。最初から全エージェントを再実行するより安いです。一度きりのリレーは、最初の分解のミスを確定させます。

起動は Task、中身はプロンプトに書く

サブエージェントを生む道具が Task です。親がそれを要求できるよう、allowedTools に "Task" を入れます。入っていないと、モデルは「検索役に頼む」と文章で書き、ハーネスは誰も起動しません。委任は意図ではなく、ツール要求です。

渡す調査結果は、子のプロンプトに書きます。検索の結果と文書分析の結果を、統合役のプロンプトへ載せます。「前の役が知っている」は、会話が分かれているので成立しません。

載せるときは、本文とメタデータを分けます。主張、抜粋、URL、文書名、ページ、公開日。本文だけを貼ると、統合の文章から出典が溶けます。後の章の出典保持は、この受け渡しの形が起点です。

並列は、親の一回の返答に Task を複数出すことで起きます。ハーネスはその複数を同時に実行し、全部の結果が揃ってから次のモデル呼び出しをします。ターンを分けて一人ずつ起動すると、待ちが直列になります。依存があるときだけ直列にします。統合は検索の結果が要るので、検索と統合を同じ返答で並べても統合は空を受け取ります。検索と文書分析は並べられ、統合は次のターンです。

AgentDefinition には、種別の説明、システムプロンプト、使えるツールの制限を持たせます。コーディネーターは説明を読んで、誰に渡すかを決めます。説明が「なんでも調査する」だと、選択は揺れます。「公開ウェブの記事を探し、URLと抜粋を返す。論文PDFは扱わない」まで書くと、論文は文書役へ回ります。

指示は手順書より、目標と品質基準です。「この三つのクエリを順に投げ、各5件」は、三番目のサイトが落ちたときに止まります。「音楽分野の主要な反論を、一次に近い出典つきで集め、数が足りなければクエリを変えてよい。出典のない数字は書かない」なら、適応できます。手順が安全上の順序なら、それは子のプロンプトではなくゲートです。

外れてはいけない順序は、確率では守れない

モデルは指示に、高い割合で従います。割合が残ります。返金の前の本人確認を一文で強調しても、確認を飛ばす回があります。その一回が別人の口座を動かします。

ゲートはハーネスの状態検査です。返金ツールを実行する直前に、この会話で顧客確認が検証済みIDを返したかを見ます。返していなければ、APIは叩かず、ツール結果として「確認が済んでいないので実行しなかった」をモデルに返します。モデルは次の手で確認を要求できます。副作用は起きていません。

プロンプトを厚くすること、正しい順序の会話例を足すことは、従う割合を上げます。ゼロにはしません。事故の値段が高い順序はゲートです。割合でよい案内（トーン、説明の詳しさ）はプロンプトのままにします。両方をゲートにすると、方針の質問までブロックされます。

一通に用件が複数あるときは、項目に分け、共有する事実（同じ顧客ID）を持たせたうえで調べ、最後に一つの返答へまとめます。フルパイプラインを常に通す話とは別です。用件の数に合わせて枝を出す、という分解です。

人へ渡す相手は、エージェントの会話ログを開けません。必要なのは写しではなく、判断の材料です。顧客ID、何が起きたか、金額、推奨する次の行動。この四点が欠けると、人は最初から聞き直します。丁寧な全文の貼り付けは、金額を本文の途中に埋め、人が見落とします。

フックは、モデルが読む前と、実行する前で仕事が違う

PostToolUse は、ツールがすでに返り、モデルがまだ読んでいない時点で結果を変換します。注文APIがUnix時刻、配送APIがISO 8601、在庫APIが数値コード、というばらつきを、ここで日付と状態の語へ揃えます。モデルに翻訳させると、そのターンを消費し、日付の取り違えが返金判断を曲げます。変換は決定的なので、モデルの仕事ではありません。

呼び出しを止めるフックは、実行の前です。閾値を超える返金要求が来たら、APIを叩かず、人への引き渡しへ回す結果を返します。これは PostToolUse では遅いです。結果を変換するフックは、すでに実行されたあとの話だからです。名前を一つにまとめないでください。

規則をプロンプトに書き、フックを省略すると、モデルは「今回は例外のはず」と実行を要求できます。フックは要求を受け取れます。実行だけを拒否します。ビジネス規則で確実に守りたいものは、フックかゲートです。

分け方は、次の問いが最初から見えるかで選ぶ

レビューのように、見る面が事前に分かっている仕事はプロンプトチェーンです。ファイルごとに局所的な欠陥を見てから、ファイルをまたぐデータの流れを別パスで見ます。十四のファイルを一度に渡すと、注意が一部のファイルに寄り、同じパターンを片方では指摘し、片方では通します。これはモデルが怠慢なのではなく、一度に配れる注意に限りがあるからです。パスを分けると、各パスの入力が小さくなり、深さが揃います。

「古いコードベースに、抜けの大きいテストを足す」は、最初に面が分かりません。入口のディレクトリだけを手順にすると、依存の先にある危険な箇所がテストされません。先に構造を把握し、影響の大きい箇所を見つけ、依存が見つかるたびに優先度を更新します。これが動的な分解です。

チェーンを調査に使うと、名付けなかった枝が消えます。動的分解を、項目の決まったレビューに使うと、モデルはチェックリストを放棄して探索に流れます。予測できる多面レビューはチェーン。終わり方が事前に決まらない調査は動的分解、です。

セッションは、履歴が今も本当かどうかで選ぶ

--resume は、名前を付けた会話の履歴を戻して続けます。翌日も同じ調査で、ファイルが変わっていないなら、入り口の探索を繰り返さずに済みます。

履歴の中のツール結果は、実行した瞬間のファイルとAPIの写しです。昨日読んだ関数が今日書き換わっているのに再開すると、モデルは古い写しを今のコードだとして話します。再開するなら、変わったファイルを名指しで伝え、その部分だけ読み直させます。全体を最初から探させるより短いです。

写しが広く古くなっているなら、再開は不利です。残したい結論（決めた境界、未解決の問い、参照すべきファイル名）だけを構造で書き、新しい会話の最初に注入します。古いツール結果そのものは渡しません。

fork_session は、同じ分析の直後に枝を分けます。テスト方針のAとBを一つの会話で比べると、Aの前提がBの評価に混じります。枝を分ければ、各案は共通の起点だけを共有し、その後のツール結果は混ざりません。比べるのは、両方の結論を人が、またはコーディネーターが読むときです。

ツール呼び出しには識別子があり、結果は対になる

一回の返答にツール要求が二つあるとき、それぞれに識別子が付きます。ハーネスは実行結果を、その識別子へ結びます。結びを間違えると、検索の結果が文書分析の欄に入り、モデルは出典を取り違えたまま統合します。並列にしたときは、結果の配列を「返ってきた順」で暗黙に対応させないでください。識別子で対応させます。

片方だけが失敗したときも、成功した側の結果は履歴に残します。失敗した側は、失敗の構造（後の章で扱う種類、試した内容、部分結果）を、その識別子の結果として戻します。両方を捨てると、成功した検索までやり直しになります。両方を成功の空にすると、失敗が消えます。

モデルが要求していないツールを、ハーネスが気を利かせて先に実行するのは逆方向の結合です。モデルの次の判断は、自分が頼んだ結果が会話に並ぶ前提で進みます。頼んでいない顧客情報を履歴に挿入すると、どの前提で話しているかがモデルからもログからも追いにくくなります。先に実行したい不変条件があるなら、それはゲートとして「このツールはまだ実行できない」と返すほうへ置きます。

ループが同じツールを繰り返すときの切り分け

同じツールが同じ引数で三回続くなら、結果が履歴に戻っていないか、戻した文が「失敗」としか書いておらずモデルが再試行をやめる根拠を持っていないか、です。一時的な失敗ならハーネスが短い再試行をしてからモデルに返してよいです。入力が無効なのに同じ引数で再試行しているなら、エラーに「この引数は受け付けない。直すならどの欄か」を書きます。詳細はツール設計の章です。ループ側で先に見るのは、結果が次の依頼の会話に入っているか、です。

回数ヒューズが発火したときは、利用者に「完了」と返してはいけません。どこまで実行し、何が未実行かを返します。返金ツールだけが未実行なのに「対応しました」と書くのが、このヒューズの事故です。

悪い委任と、目標で書く委任

悪い親の指示はこうです。「検索ツールを使え。クエリは創作、AI、アート。五件取ったら文書役へ渡せ。」題が視覚に寄り、件数で打ち切られ、文書役は検索の会話を見られません。

目標で書くとこうです。「利用者の問いは、創作産業の雇用への影響です。視覚、音楽、執筆、映像を別の検索に分け、各結果は主張、抜粋、URL、公開日を分けて返せ。一次に近い出典が無い数字は空のままでよい。音楽が見つからなければ、見つからなかったと書け。」子はクエリを自分で変えられます。空は失敗ではなく、穴の報告です。

親が子の結論を自分の言葉で要約してから次の子へ渡すと、金額や日付が丸まります。渡す単位は、子が返した構造のままです。要約が許されるのは、次の子の予算に明らかに入らないときだけで、その場合も数字と出典の行は残します。この圧縮の失敗は、コンテキストの章でさらに扱います。

ゲートの中身

状態は会話の外、ハーネスが持つ小さな記録で足ります。顧客確認ツールが検証済みIDを返したときだけ、verified_customer_id をセットします。返金ツールの実行関数の先頭で、その値が空ならAPIクライアントを呼ばず、ツール結果を返します。プロンプトから確認の文を全部消しても、この分岐は残ります。それがゲートのテストです。

閾値が「五万円を超えたら人へ」なら、返金の実行前フックが金額を見ます。超えていれば人への引き渡し用の結果を返し、verified_customer_id があってもAPIは叩きません。確認のゲートと金額のフックは、別の不変条件です。一つにまとめると、方針の質問まで止まります。

ハンドオフの具体

人に渡す一文を、会話の貼り付けで書くと「お客様はご立腹で、注文の話のあと配送の話になり、金額はどこかで八千と言っていた」になります。人は注文番号を探し、見つからなければ聞き直します。構造なら、顧客 C-42、注文 A-19、ヘッドホン、配送済み、希望は全額返金、エージェントは破損写真が無く方針の外だと判断、推奨は写真依頼か例外承認、です。人はこの行だけ読んで次の行動を選べます。

再開とフォークの具体

月曜日に認証モジュールを読み、セッション名を auth-review にしました。水曜日に session.ts の有効期限だけが変わり、他は同じです。再開して「session.ts の有効期限の比較が十四日から一日に変わった。そのファイルだけ読み直し、月曜日の他の結論は維持してよいかを言え」と渡します。セッション全体を捨てる必要はありません。

水曜日に、認証をミドルウェアへ移す案と、各ハンドラへ残す案を比べるなら、月曜日の分析の直後でフォークします。両方の枝が router.ts を読んでも、結果は枝の中だけに残ります。一つの会話で両方を試すと、先の案の差分が後の案のファイル内容に混じります。

結論だけを新規に注入するのは、ツール結果の大半が廃棄APIのレスポンスで、もう再現できないときです。注入文に「当時のレスポンスでは在庫は十だった」と書くなら、それは事実ではなく当時の観測だとラベルします。ラベルが無い数字は、新しいセッションでも現在の在庫として扱われます。

止まった理由を、症状から先に決める

「止まった」は一つの障害ではありません。ログに残るのは、最後の stop_reason、最後に要求されたツール名と引数、その結果が履歴に一行でも入ったか、です。プロンプトを直す前に、次のどれかを決めます。

完了は、end_turn で、直前のツール結果が方針と矛盾せず、利用者への文がその結果を言っているときだけです。文章に「完了しました」とあり、stop_reason が tool_use なら、文章は無視してツールを実行します。空のアシスタント文も完了ではありません。ツール直前の短いつなぎが、空に近い文になることがあります。

同じツール、同じ引数が三回続くなら、結果が履歴に無いか、結果が「失敗」の一文だけで再試行をやめる根拠が無いか、です。前者はハーネスの結合漏れです。後者はエラーの形の問題で、直す場所はツールの戻り値です。プロンプトに「繰り返すな」と書いても、結果が見えなければ次の手は同じ要求です。

max_tokens で切れた返答は end_turn ではありません。ツール呼び出しのJSONが閉じ括弧の前で切れていたら、その引数は実行しません。出力の予算を足して同じ履歴から続け直すか、切断として利用者に返します。切れたJSONを補完して実行すると、金額の桁が欠けた返金が通ります。

回数の上限でハーネスが止めたとき、モデルはまだ tool_use を返していました。利用者への文は、実行済みのツールと未実行のツールを分けます。返金だけが未実行なのに「対応しました」と書くのが、このヒューズの誤報です。上限は暴走を止めるためのもので、仕事の定義ではありません。

分けないほうが速い仕事がある

サブエージェントは、隔離の費用です。起動、プロンプトの複製、待ち、結果の受け取りが入ります。一回の Grep で終わる呼び出し元の調査に Task を使うと、隔離の利益が無く、待ちだけが増えます。

分ける基準は三つです。入力が長く、本会話に残すと後続の設計を書く予算が無くなる。持たせるツールの集合が違い、親に全部渡すと選択が揺れる。失敗しても目的の一部だけが欠ける、と切り出せる。三つとも無いなら、親が直接ツールを呼びます。

副作用の順序は、委任で分けません。本人確認と返金APIを別の子にすると、確認済みの顧客IDは子の会話に閉じ、親のゲートが見る状態に入りません。確認も返金も、同じハーネスの状態と、実行前の検査に置きます。委任してよいのは、検索のように、失敗しても口座が動かない仕事です。

子に親の全履歴を継がせれば隔離は要らない、という案は、隔離が欲しかった理由を消します。子は親の途中の仮説まで読み、関係の無いツール結果で窓を使います。渡すのは、その子の判断に要る構造だけです。

一つの返金を、ループとゲートとフックで通す

利用者の文は「注文 A-19 を返金して」です。方針は、写真の無い破損申告は返金しない、五万円を超えたら人、です。

一ターン目の stop_reason は tool_use で、顧客確認です。ハーネスが実行し、検証済みID C-42 を状態に書き、結果を履歴に足します。状態への書き込みを忘れると、後のゲートは常に空を見て、正しい顧客でも返金できません。

二ターン目は注文参照です。生の結果は配送日時がUnix時刻、状態が数値コードです。PostToolUse が、モデルが読む前に日付の文字列と「配送済み」へ揃えます。金額 8000 と写真なしは、この時点で事実として控えます。揃えずにモデルへ渡すと、数値コードを「未配送」と読む回があり、返金の可否が変わります。

三ターン目にモデルは返金を要求します。実行前の検査は二つです。verified_customer_id があるか。金額が五万円以下か。両方を通過しても、方針の検査が写真なしを見て、APIは叩きません。ツール結果は「写真が無いので実行しなかった。人の例外が必要ならハンドオフに回せ」です。

四ターン目は end_turn で、利用者に写真を依頼する文です。この文が「返金しました」になっていないことを、ツール結果の拒否で検査できます。モデルの最終文だけを成功の印にすると、未実行の返金を完了と報告します。

同じ依頼で写真があり、金額が八千円なら、三ターン目はAPIを呼び、四ターン目の end_turn が完了です。プロンプトから「写真を見よ」を消しても、検査は残ります。文章の指示は従う割合を上げ、検査は外れた回の副作用を止めます。金額の検査と写真の検査を一つの条件にまとめると、方針の質問（返金できる条件は何か）までAPIの手前で止まります。質問にはツールが要りません。検査は返金ツールの実行関数にだけ掛けます。

並列の片側だけが落ちたとき

親の一回の返答に、視覚の検索と音楽の検索が並びます。識別子は call_v と call_m です。視覚は抜粋を返し、音楽はタイムアウトです。

次のモデル呼び出しには、call_v の抜粋と、call_m の失敗（種類、試したクエリ、空ではない部分があればそれ）が、識別子つきで入ります。モデルは視覚の統合を進め、音楽だけを再委任できます。

結果を、戻ってきた順の配列で対応させると、音楽の失敗が先に着いたとき、視覚の欄へ失敗が書かれます。統合は、視覚の記事が無かったと書きます。対応は識別子だけです。

成功側を捨てて両方をやり直すと、タイムアウトのたびに費用が倍になります。失敗側を空の成功にすると、音楽は「記事が無かった」という結論になります。残すのは、成功した結果と、失敗の構造です。モデルが要求していない検索を、ハーネスが先に足すのも同じ種類の誤りです。次の判断は、頼んだ結果が並ぶ前提で進みます。

コーディネーターのプロンプトと、子のプロンプトは別の仕事

コーディネーターに書くのは、利用者の目的、品質の線、再委任してよい条件です。「視覚が四件、音楽がゼロなら、音楽だけクエリを変えてもう一度」まで書けます。クエリの文字列そのものは書きません。書くと、子がサイトの落ち方に合わせて語を変えられません。

子に書くのは、返す構造と、空でよい条件です。主張、抜粋、URL、公開日。一次に近い出典が無い数字は空。空は失敗ではなく、その分野の報告です。手順「この三つのクエリを順に、各五件」は、三番目のサイトが落ちた時点で子が止まります。

親が子の結論を自分の言葉で要約してから次の子へ渡すと、8000 が「数千円」になり、URLが落ちます。渡す単位は、子が返した構造のままです。要約が許されるのは、次の子の予算に入らないときだけで、数字と出典の行は残します。

セッションの三択を、ファイルの古さで選ぶ

履歴の中のツール結果が、今のファイルとまだ一致するなら --resume です。変わったファイルが一つなら、再開したうえでそのパスを名指しし、そのファイルだけ読み直させます。名指しを忘れると、月曜日の session.ts が水曜日のコードとして話されます。

一致しない結果が会話の大半を占めるなら、新規です。残すのは決めた境界、未解決の問い、読むべきパスです。古いレスポンスの数字を入れるなら「当時の観測」とラベルします。ラベルが無い在庫数は、新しい会話でも現在の在庫になります。

同じ起点から二つの案を比べるなら fork_session です。一つの会話でミドルウェア案のあとハンドラ案を試すと、先に読んだ差分が後の案のファイル内容に混じります。枝は共通の分析までを共有し、その後のツール結果は混ざりません。比べるのは、両方の結論をコーディネーターが読むときです。再開とフォークを同時に使う必要はありません。古さの問題と、比較の問題は別です。

どう判断するか

• ループを閉じるのは end_turn。tool_use のあいだは実行して履歴に戻す。文章、回数、空文字は完了の定義にしない。トークン切断は完了ではない。
• 普段の次のツールはモデルに選ばせる。事故になる順序だけゲートにする。
• サブエージェントは親を見ない。Task を許可し、結果はプロンプトに、本文と出典を分けて渡す。依存のない役だけ、一返答で並列にする。
• 下流が全員成功しているのに成果物が偏るなら、分解の幅を疑う。穴は絞って再委任する。
• 結果の形を揃えるのは実行後のフック。呼び出しを拒否するのは実行前のフック。
• 面が見えているレビューはファイル単位のあと横断。面が見えない調査は計画を更新する。
• 履歴が今も妥当なら再開し、変わったファイルを名指しする。ツール結果が古いなら要約して新規。案の比較はフォーク。

確認

問1

返金エージェントが、顧客確認の結果を履歴に足さずに次の呼び出しをしています。何が起きますか。

A. モデルは確認結果を覚えているので、注文参照へ進める
B. 次の呼び出しは確認結果を見られないので、同じ確認を繰り返すか、IDなしで先へ進む
C. end_turn が自動で付き、ループが正しく終わる
D. サブエージェントが親の履歴を補う

問2

検索も文書分析も統合も、割り当てられた視覚表現の題では成功しています。報告に音楽がありません。最初に直す場所はどれですか。

A. 検索クエリの語数を増やす
B. 統合の文章を長くする
C. コーディネーターが題目を視覚だけに割ったこと
D. ループの回数上限を上げる

問3

検証済みの顧客IDが無い返金は、実行されてはいけません。従う割合を上げるだけでは足りません。どの仕組みですか。

A. システムプロンプトに順序を太字で書く
B. 正しい順序の会話例を足す
C. 返金の実行直前に、確認済みIDが状態にあるかを検査し、無ければAPIを叩かない
D. モデルに確信度を申告させ、高いときだけ実行する

問4

三つの配送APIが、時刻を別の形式で返します。モデルに読ませる前に日付の文字列へ揃えたい。どこで変換しますか。

A. 実行後、モデルが読む前の結果変換フック
B. 実行前に呼び出しを拒否するフック
C. 利用者向けの最終文のあと
D. セッションの再開時だけ

問5

三日前の調査会話を続けたい一方、当時読んだファイルは昨日大きく変わりました。どの進め方が妥当ですか。

A. 古いツール結果が残った会話を、変更を伝えずに再開する
B. 残すべき結論だけを新しい会話に注入し、古いツール結果は渡さない
C. 自然文の「完了」でループを止める
D. すべての子に親の全履歴を自動で継がせる

自分で確かめる

小さなハーネスを書き、tool_use ではダミーのツールを実行して結果を戻し、end_turn で止めてください。結果を戻す行を外すと、同じツールを要求し続けることを観察します。次に、金額が閾値を超えた返金要求を、実行前のフックで拒否し、プロンプトからその文を消しても拒否が残ることを確認します。最後に、一回の親の返答に Task を二つ載せた場合と、ターンを分けた場合で、待ちの足し方を比べます。