Claude Fable 5.1のサブエージェント並行作業でリードを待たせない設計
起動ツールの即時リターン・結果の後続メッセージ投入・待機専用ツールの3点で、Claude Fable 5.1のリードエージェントはサブエージェント実行中も動かし続けられます。
Claude Fable 5.1は、サブエージェントに作業を任せている間もリードエージェント側を待機させない設計を公式ドキュメントで推奨しています。カスタムのコーディングエージェントを組む開発者向けの指示です。サブエージェントを起動するツールをリードの手を止めない形で設計すると、同程度の品質・トークン使用量・コストを保ったまま完了までの平均時間を短縮できるとされています。一次ソースに明記された具体的な実装手順を確認します。
Claude Fable 5.1のサブエージェント並行作業とは
Claude Fable 5.1のサブエージェント並行作業とは、サブエージェントの起動を待ち状態にせず、リードエージェントが他の作業を続けながら完了を受け取れる実行方式です。公式ドキュメント「Prompting Claude Fable 5.1」は、コーディングエージェントがサブエージェントへ処理を委譲できる場合の指示を示しています。リードを毎回止めて完了を待たせないよう、明示的に勧めています。
背景にあるのは、Claude Fable 5.1がFable 5より長時間の自律実行に強くなった点です。「What's new in Claude Fable 5.1」も、長時間の自律的なコーディング作業や多段階の調査作業が強化されたと位置付けています。長時間動く実行が増えるほど、リードがサブエージェントの完了をただ待つだけの時間も伸びやすくなります。
ドキュメントが挙げる典型症状は明快です。「サブエージェントが動いている間、リードエージェントがアイドル状態になる」ケースに心当たりがあれば、この節が対象読者になります。コーディングタスクでは、リードを待たせずに動かし続けると、品質・トークン使用量・コストをほぼ変えないまま完了までの平均時間が縮むとされています。効果が出るのは常にではなく、リードが待たずに他の作業を進められた実行に限られる点は後述します。
リードを待たせない3つの実装ステップ
公式ドキュメントは、この設計を組むための実装ステップを3つ挙げています。いずれもサブエージェントを起動する側のツール設計に関わる項目です。
- サブエージェントを起動するツールを、起動した時点ですぐ呼び出し元に制御を返す設計にする
- サブエージェントの結果は、準備でき次第、後続のuserメッセージとしてリードに渡す
- リードが結果を待ちたいときに呼び出せる、待機専用の別ツールを用意する
3つとも、ツール呼び出しの同期・非同期の切り替え方に関わります。1つ目と2つ目は「起動」と「結果受け取り」を分離する設計で、3つ目はリード側に主導権を残す仕組みです。リードは待機ツールを呼ばない限り、サブエージェントの完了を意識せずに次の作業を進められます。
3条件を満たすツール設計の一例は次のとおりです。公式のツール定義そのものではなく、3ステップを満たすための実装例として示します。
{
"name": "start_subagent",
"description": "サブエージェントを起動し、完了を待たずにtask_idを返す",
"input_schema": {
"type": "object",
"properties": {
"task": { "type": "string" },
"context": { "type": "string" }
},
"required": ["task"]
}
}{
"name": "wait_for_subagent",
"description": "指定したtask_idのサブエージェントが完了するまでリードをブロックする",
"input_schema": {
"type": "object",
"properties": {
"task_id": { "type": "string" }
},
"required": ["task_id"]
}
}start_subagentは呼び出された瞬間にtask_idだけを返し、サブエージェント本体の実行はハーネス側でバックグラウンドに進みます。結果が出た段階で、ハーネスがそれを新しいuserメッセージとしてリードの会話に追加します。リードが結果を先に確認したい場合だけ、wait_for_subagentのような専用ツールを呼び出して完了を待ちます。
ここには、Claude APIの通常のツール呼び出しとの違いがあります。tool_useには同じターンでtool_resultを返す必要があります。start_subagentもこの制約に従い、task_idを含むtool_resultをその場で返して呼び出し自体はすぐに完結させます。サブエージェントの実際の結果は、そのtool_resultの中身としてではなく、完了したタイミングで新たに追加するuserメッセージとして渡します。ツール呼び出しの往復と、結果が届くタイミングを切り離す点が、この設計の技術的な核心です。
効果はどれくらいか — 待つケースと進めるケースの使い分け
この設計を入れても、Claude Fable 5.1が常にリードを動かし続けるわけではありません。公式ドキュメントは「モデルは依然としてしばしば待つことを選ぶ」と明記しています。時間短縮の効果が出るのは、リードが他の作業を進める判断をした実行に限られます。
つまりこの実装は、リードを強制的に働かせ続けるものではなく、待たなくてもよい選択肢を与える設計です。サブエージェントの結果が次の判断に直結するタスクでは、Claude Fable 5.1自身が待機ツールを呼び、逐次実行に近い挙動を選ぶことも珍しくありません。逆に、複数の独立したサブタスクを並行して進められる場面では、リードが待機ツールを呼ばずに他の作業へ進み、その分だけ完了までの時間が縮む形になります。
平均時間の短縮は、この「進めるケース」が積み重なった結果として現れる性質のものです。個々の実行で毎回時間が縮むとは限りません。導入前に把握しておく価値がある前提です。
どちらを選びやすいかは、次の作業がサブエージェントの結果に依存するかどうかで変わってくると考えられます。サブエージェントに任せたテスト実行の結果を見てから次の修正方針を決めるようなタスクでは、待機ツールを呼んで結果を確認してから動く展開になりやすそうです。一方、別ファイルのリファクタリングやドキュメント更新のように、結果を待たずに進められる作業がほかに残っていれば、リードはそちらを先に進める余地があります。
Claude Codeの既定挙動との違い
同じ「サブエージェントを待たない」設計でも、Claude Code自体はすでに近い挙動を標準で持っています。対話セッションではforkモードが既定でオンになっており、ClaudeがAgentツールで起動するサブエージェントはfork・非forkを問わずバックグラウンドで動きます。Claude Code側からフォアグラウンド実行を要求する手段自体がありません。
ここまで扱った3ステップは、Claude Codeのようにハーネス側が非同期実行をすでに組み込んでいる製品向けではありません。Anthropic APIを直接使って自前のコーディングエージェントを組む開発者に向けた指示です。Claude Codeを使う分には、fork既定onの挙動がすでに同じ効果を提供しています。自前のハーネスでサブエージェント呼び出しツールを実装している場合だけ、起動ツールを即座に返す設計へ作り直す必要があります。
Claude Codeの非対話モード(-p実行)やAgent SDKでは、fork既定がオフになります。この場合もサブエージェントは基本的にバックグラウンドで動き、Claudeが結果をすぐ使いたいときだけフォアグラウンドを選ぶ設計です。Agent SDK経由でClaude Codeのサブエージェント機構をそのまま呼び出す構成であれば、ここで挙げた3ステップを自分で組まなくても近い挙動がすでに動いています。3ステップの実装が要るのは、Claude Codeのサブエージェント機構を経由せず、Anthropic APIを直接呼び出して独自のツール呼び出しループを組んでいる場合です。
サブエージェントが長時間バックグラウンドで応答しなくなったときの検知は、Claude CodeではCLAUDE_ASYNC_AGENT_STALL_TIMEOUT_MSが担っています。自前のハーネスで起動即時リターン型の設計にする場合も、同様のストール検知を別途用意しないと、応答が止まったサブエージェントに気づけないまま待ち続けることになります。
実装時に注意すべき点
起動ツールを即時リターン型に変えるだけでは、リードが結果を見落とすリスクが残ります。実装時に踏まえておきたい点をまとめます。
- 結果を渡すuserメッセージの投入タイミングが遅れると、リードは古い前提のまま作業を続けてしまう。結果が届いた直後に会話へ反映する仕組みが要る
- 待機専用ツールを用意しないまま起動ツールだけ非同期化すると、リードが結果を確認する手段を失う。両方をセットで実装する
- 独立したサブエージェントを複数同時に起動する場面では、同じ資料が扱う「ツール呼び出しをまとめて発行する」指示と組み合わせると、起動そのものも1ターンにまとまりやすくなる
- サブエージェントの起動・終了を監視したい場合は、SubagentStart/SubagentStop hookのようなライフサイクルイベントの仕組みが参考になる。Claude Code固有の機能だが、自前ハーネスで監視を設計する際の型として使える
いずれも、リードを待たせない設計自体が壊れるわけではありません。結果の受け渡しや監視が追いつかなくなることで、効果が薄れる形の失敗です。
まとめ
Claude Fable 5.1のサブエージェント並行作業は、起動ツールの即時リターン・結果の後続メッセージ投入・待機専用ツールの3点で組む設計です。効果が出るのはリードが待たずに他の作業を進めた実行に限られ、モデルが待機を選ぶケースも残ります。Claude Codeを使っている場合はforkモードの既定挙動がすでに近い効果を提供しています。この設計転換が主に効いてくるのは、Anthropic APIを直接使って自前のコーディングエージェントを組んでいる開発者です。Claude Fable 5.1の全体像と合わせて、既存のハーネスがどちらの前提で動いているかを確認しておくと判断しやすくなります。