Fable 5の並列サブエージェント入門｜1体のAIが分身しUI・音・触覚を同時に作る仕組み

並列サブエージェント——1体のAIが、1つの依頼を複数の小さな担当に切り分け、それらを”同時に”走らせるこの仕組みが、いまAIエージェントを使う開発者の間で話題になっている。きっかけは、1体のAIに「UI・効果音・触覚フィードバックを作って」と頼んだら、そのAIが自分を3体の”エンジニア”に分け、3つを同時に組み上げていく——という実演だ。Anthropic の Lydia Hallie 氏が Claude Fable 5 で示したこのデモを、開発者の @leopardracer が「多くの開発者が見落としている機能が、ライブデモで動いた」と紹介し、注目を集めた。順番に1つずつ作るのではなく、依頼を見てから分けて同時に走らせる。その”分けて、同時に”を成り立たせているのが、dynamic workflow（動的ワークフロー） と 並列サブエージェント の組み合わせだ。

この記事では、この実演に凝縮された仕組みを日本語で噛み砕く。「dynamic workflow とは、手順を決め打ちしない何なのか」「並列サブエージェントは、なぜ3つを同時に作れるのか」「従来のマルチエージェントと何が違い、Fable 5 は何を足しているのか」を、Anthropic の公式情報とエージェント設計の一次情報を軸に、原理から順に降りていく。実演の内部実装そのものは公開情報の範囲では細部まで分からないが、そこで使われている オーケストレーター＝ワーカー と 並列化 の考え方は、設計パターンとして十分に整理できる。

いま話題の「並列サブエージェント」— @leopardracerが伝えた実演

まず、話題の発信元を押さえておく。今回の起点になったのは、開発者 @leopardracer の投稿だ。同氏は Anthropic の Lydia Hallie 氏によるライブデモを引用し、「多くの開発者が完全に見落としている機能が、ちょうどライブデモで示され、それがこのガイドの内容と一致した」という趣旨で共有した。つまり、誰かが理屈だけで語ったのではなく、実際に動いているデモ を指して「これは効く」と伝えた投稿だ。だからこそ、抽象論ではなく手触りのある話として広がった。

投稿が指し示すデモの中身は、要約するとこうなる——Lydia Hallie 氏が Claude Fable 5 上で dynamic workflow を走らせ、そこから 並列のエンジニアリング・サブエージェント が spawn（生成）され、それらが UI・音声・触覚（ハプティクス）を同時に ビルドしていく。1体のモデルが3種類の成果物を順番にこなすのではなく、”分身”したかのように3方向の作業が並走する、という点が耳目を集めた。

多くの開発者が完全に見落としている機能が、ちょうどライブデモで示され、それがこのガイドの内容と一致した。Lydia Hallie（Anthropic）が Fable 5 上の dynamic workflow を披露し、そこから並列のエンジニアリング・サブエージェントが生成され、UI・音声・触覚を同時に作り上げた。
原文（要約）：“the feature most developers are completely sleeping on just got a live demo … Lydia Hallie from Anthropic showed dynamic workflows on Fable 5 spawning parallel engineering subagents that build ui audio and haptics at the same time.”（@leopardracer, 2026-07-07）

なぜ、この話がいま響くのか。背景には、AIエージェントの使い方そのものの変化がある。かつては「1回のプロンプトに最適な文を書く」ことが工夫の中心だった。だがいまは、エージェントを長時間・自律的に走らせ、「ループを回し続ける仕組みをどう設計するか」に関心が移ってきている（この流れ自体は Claude Code のループ設計入門 で整理した）。エージェントが自律で長く走るほど、同じ時間で何をどれだけ進められるか という”時間の使い方”が、賢さと同じくらい効いてくる。1体が直列で順番にこなすのか、分身して並列で同時に進めるのか——並列サブエージェントは、この「時間の使い方」を作り替える発想なのだ。

そしてもうひとつ、いまこの実演が Fable 5 で示された点も見逃せない。Anthropic は Fable 5 を「最も高性能な、広く提供するモデル」と位置づけ、長時間の自律的な作業に向くモデルとしている。とりわけ、並列のサブエージェントへの委譲 と、長時間走るサブエージェントやピア（対等なエージェント）との非同期なやり取りの維持 を、明確な強みとして挙げている（Fable 5 の全体像は Claude Fable 5 とは何かをまとめた解説 を参照）。並列サブエージェントは、まさにこの強みが活きる使い方だ。

dynamic workflow（動的ワークフロー）とは — 手順を決め打ちしない

並列サブエージェントを理解するには、その前段にある dynamic workflow から押さえるのが近道だ。ここが土台になる。

普通の自動化やワークフローは、手順を人間が先に決め打ちする。「①UIを作る→②音を作る→③触覚を作る」と、あらかじめレール（フローチャート）を固定で敷いておくイメージだ。処理はそのレールの上を順番に流れる。予定にない作業は出てこないし、分け方も毎回同じ。手順が読めるので管理はしやすいが、依頼の中身によって最適な段取りが変わる場面では、固定のレールが窮屈になる。

dynamic workflow はこれと逆の発想を取る。手順を先に敷くのではなく、AI（オーケストレーター）が 依頼を見てから、分担や段取りをその場で設計する。「この依頼なら、UI係・音係・触覚係の3人に分ければいい」と、着いた現場を見て人員配置を決める 現場監督 のイメージに近い。レールを先に敷くのではなく、着いてから割り振るので、依頼ごとに分け方が変わる。今回の実演で「UI・音・触覚の3方向に分かれた」のは、その依頼にとってその3分割が理にかなっていたから、という位置づけになる。

この「決め打ちか、その場で設計か」の対比を、表で並べておく。

この「AIが自分でワークフローを組む」考え方は、Claude Code の文脈でも語られてきた（内部の仕組みは Claude Code の dynamic workflows 解説 にまとめている）。ポイントは、分担そのものを固定の設定ではなく、実行時の判断に委ねる ことだ。人間が「こう分けろ」と決めるのではなく、モデルが「この依頼ならこう分けるのが良い」と判断する。次に見る並列サブエージェントは、この dynamic workflow が”設計した分担”を、実際に 同時に走らせる 実行のパートにあたる。

図のように、オーケストレーターは依頼を受けてから3つの担当を spawn する。この「受けてから分ける」順序が dynamic workflow の肝で、分担は事前設定ではなく、その場の設計として生まれる。ここまでが「どう分けるか」の話。ここから「なぜ同時に走らせられるのか」に進む。

並列サブエージェントの仕組み — 分けて、同時に走らせる

dynamic workflow が分担を設計したら、次は その担当を、順番にではなく”同時に”走らせる。これが並列サブエージェントだ。ここで登場するのが サブエージェント（subagent） という考え方になる。

サブエージェントとは、オーケストレーター（司令塔）が切り出した 小さな担当エージェント のことだ。それぞれが自分の担当分（UI係なら画面、音係なら効果音、触覚係なら触覚フィードバック）に集中し、独立して手を動かす。1体のモデルが全部を1人で抱えるのではなく、担当ごとに分身を立てる、と言い換えてもいい。今回の実演で「3体のエンジニア」に見えたのは、この3つのサブエージェントだ。

なぜ”同時に”が効くのか。1体のAIが全部を1人でこなす場合、作業は 直列 になる。UIを作り終えてから音、音を作り終えてから触覚——と順番に進むので、それぞれの所要時間が 待ち時間として積み上がる。一方、並列サブエージェントは、UI係・音係・触覚係を 別々のサブエージェントとして同時に起動 する。3つの作業が並走するので、全体の所要は「3つを足した長さ」ではなく「いちばん時間のかかった1つ」に近づいていく。直列で積み上がっていた待ちを、畳み込むわけだ。

表の3行目にも書いたとおり、並列サブエージェントには”速さ”以外の利点がある。各サブエージェントが、自分の担当に絞った独立した文脈（コンテキスト）を持てる ことだ。UI係はUIのことだけ、音係は音のことだけを考える。1体が全部を抱えると、UIを作っている最中も音や触覚の事情が同じ頭の中に混ざり、注意が分散しやすい。担当を分ければ、それぞれが自分の持ち場に没頭できる。この「関心を分離する」効果は、速さと並んで並列化のもうひとつの狙いになる。

ここで、dynamic workflow（仕組みA）と並列サブエージェント（仕組みB）が どう噛み合うか を明確にしておきたい。オーケストレーターが依頼を見て”その場で”3係に分けるのがA、その3係を”同時に”走らせるのがBだ。Aで分けて、Bで同時に走らせる——この2つが一続きになって、「1体のAIが分身して、UI・音・触覚を同時に作る」という実演の見た目になる。どちらか一方だけでは足りない。分担を固定してしまえば依頼に合わせられず、分けても順番に走らせれば待ちは消えない。動的に分け、並列で走らせる、その両輪がそろって初めて成立する。

ケースで見る：小さな新機能を1周で追う

抽象論だけでは掴みにくいので、説明のために、ひとつの作業を1周だけ追ってみる。あくまで仕組みを見るための仮の例で、実演そのものの再現ではない。たとえば「アプリに新しい設定画面を1つ追加する」という小さな機能開発を、並列サブエージェントで進める場面を考える。

1. 設計（オーケストレーター）：Fable 5 が依頼を受け、この機能を「画面（UI）」「入力チェック（バリデーション）」「利用状況の記録（テレメトリ）」の3つに切り分けられると判断する。3つは互いの完成を待たずに着手できる——ここが dynamic workflow の分担設計にあたる。分け方は最初から決まっていたのではなく、依頼を見てからこの場で決まった、という点が肝だ
   
2. 委譲（オーケストレーター）：3つをそれぞれ別のサブエージェントへ委譲する。UI係は画面のレイアウトとスタイル、チェック係は入力条件、記録係はイベントの記録処理、と持ち場を分けて同時に起動する。各係は自分の担当に絞った独立した文脈を持つので、UI係が記録処理の細部に気を取られることはない
   
3. 並走（サブエージェント）：3係が同時に手を動かす。UI係が画面を組み、チェック係が条件を書き、記録係がイベントを差し込む。互いに独立しているので、誰も相手の完成を待たない。1体が直列でこなせば「画面→チェック→記録」と積み上がるはずだった時間が、ここで並走に畳み込まれる
   
4. 非同期の報告（サブエージェント→オーケストレーター）：各係が途中の進捗を非同期で司令塔へ戻す。司令塔は全員の完了を腕組みで待つのではなく、上がってきた進捗を見ながら、命名の統一や共通部分の擦り合わせといった次の差配を進める。長く走る係がいても、司令塔は手を止めずに回り続けられる
   
5. 統合（オーケストレーター）：3つが出そろったら、司令塔がそれらを1つの機能に束ね、噛み合わせ（画面とチェックと記録が矛盾なく動くか）を確認する

この1周で効いているのは、「3つが独立している」という前提だ。もし記録係が「UIの完成後でないと、記録すべきイベントが決まらない」という依存を抱えていたら、記録係はUI係を待つことになり、並列の旨みはその分だけ削られる。逆に、依存が薄いほど3係はきれいに並走でき、直列で積み上がるはずだった待ちが畳み込まれる。並列サブエージェントの効き目は、この「独立した小分けをどれだけきれいに取れるか」に、ほぼそのまま比例すると考えてよい。そして、司令塔が全員を待たずに差配を続けられるかどうかを支えているのが、次に見る非同期連携になる。小さな機能ひとつでも、この「分けて・同時に・待たずに束ねる」1周を追うと、実演で起きていたことの骨格が具体的に見えてくる。

なぜ”同時に”作れるのか — 独立性と非同期連携

「同時に作れる」ことには、実は前提がある。それは、分けた仕事が互いに依存していない ことだ。ここを外すと、並列化は空回りする。

UI・音・触覚が同時に作れたのは、この3つが 互いの完成を待たなくても着手できる 独立した成果物だったからだ。UIを作るのに効果音の完成は要らないし、触覚フィードバックを作るのにUIの完成は要らない。独立している仕事は、順番に並べる必然性がない。だから別々のサブエージェントに割り当てて同時に走らせても、誰も手待ちにならない。逆に、もし「音を分析した結果を使ってUIを作る」といった 依存関係 があれば、UI係は音係の完成を待つことになり、並列にしても待ちは消えない。並列化が効くかどうかは、仕事を独立した小分けに切れるかどうかで決まる。この見極めが、並列サブエージェント設計のいちばんの勘所になる。

この「独立した作業を同時に走らせて、結果を集める」形は、エージェント設計では 並列化（parallelization） や オーケストレーター＝ワーカー（orchestrator-workers） と呼ばれてきた発想と重なる。Anthropic 自身も、効果的なエージェントの作り方を論じた資料の中で、独立に分解できるサブタスクを並列で走らせる並列化パターンや、中央のオーケストレーターがサブタスクを動的に分解してワーカーへ委ね、結果を統合するオーケストレーター＝ワーカーのパターンを整理している。今回の実演は、この「動的な分解＋並列実行」を Fable 5 上で具体的に見せたもの、と位置づけられる。

そして、ここに Fable 5 ならではの効き所が乗る。非同期（asynchronous）の連携 だ。並列で走らせても、司令塔が「3係が全部終わるまで、腕を組んで待つ」設計だと、結局そこがボトルネックになる。Anthropic は Fable 5 について、長時間走るサブエージェントやピアと、非同期にやり取りし続けられる ことを強みに挙げている。司令塔が手を止めて全員の完了を待つのではなく、各係の進捗を 非同期で受け取りながら、次の差配を進められる。長く走る係が、途中の状況を逐一やり取りしながら仕事を続けられる、という安定性だ。

図の点線が、係から司令塔へ戻る 非同期の進捗 を表している。実線（委譲）と点線（非同期の報告）が同時に成り立つのがポイントで、司令塔は投げっぱなしにするのでも、全員を待って固まるのでもなく、走らせながら受け取る。この「委譲して、非同期で受け取り、待たずに次を差配する」流れが、長い自律作業のあいだ途切れずに回るからこそ、多数の係を並列で走らせても破綻しにくい。Anthropic が Fable 5 の設計指針として「独立したサブタスクはサブエージェントに委譲し、走らせている間も自分の作業を続けよ」という趣旨を挙げているのも、この非同期の使い方を後押しするものだ。

従来のマルチエージェントと何が違うのか

「複数のエージェントで手分けする」という発想自体は、目新しいものではない。マルチエージェントやエージェントの分業は、以前から語られてきた（担当の切り出し方は Claude のツール・スキル・サブエージェントによる分解 でも整理している）。では、今回の実演は従来と何が違うのか。差は主に2点に集約できる——分担を先に固定するか、その場で組むか、そして 司令塔が待つか、非同期で受け取るか だ。

まず 分担の決め方。従来はワークフローの担当を人間が事前に決め打ちする設計が多かった。「この処理はエージェントA、この処理はエージェントB」と役割を固定する。これは読みやすい反面、依頼の中身に合わせて分け方を変えるのが難しい。実演はここを dynamic workflow に置き換え、分担そのものをその場で設計 していた。

次に 走らせ方と司令塔の待ち。「並列」と称していても、実装によっては結局オーケストレーターが各担当の完了を 同期的に待つ（全員そろうまで次に進めない）設計は珍しくない。これだと、いちばん遅い担当に全体が引きずられる。実演で効いていたのは、前節で見た 非同期連携 だ。司令塔が待って固まるのではなく、進捗を受け取りながら次を差配できる。Fable 5 が長時間のサブエージェントやピアと非同期にやり取りし続けられる、という強みが、ここで具体的な差になって現れる。

最後に、地味だが示唆的なのが 成果物の種類 だ。並列化というと、同じ種類のタスク（例：100個のファイルを同じ手順で処理する）を思い浮かべがちだが、実演で並走していたのは UI・音・触覚という 種類の違う成果物 だった。異なる専門の担当を同時に走らせ、ひとつの完成物に束ねる。これは、単なる物量の分散を超えて、異種の作業を並行させる分業 に踏み込んでいる点で目を引く。ここは実演の見せ方に依存する部分もあり、内部でどこまで独立していたかは公開情報からは断定できないが、少なくとも”種類の違う3つを同時に”という絵は、並列サブエージェントの応用範囲の広さを印象づけた。

日本の開発現場で並列サブエージェントをどう捉えるか

ここまでの仕組みを、日本の開発チームがどう受け止めればよいか。まず確認したいのは、並列サブエージェントは万能の高速化ボタンではない ということだ。効くのは、前提条件がそろった作業に限られる。焦って何でも並列化しようとすると、調整コストばかり増えて割に合わない。

具体的な入口としては、次のような作業が考えやすい。複数ファイル・複数モジュールの並行調査——それぞれ独立に読めるので、担当を分けて同時に把握させる。独立したコンポーネントの同時実装——UI部品・API・設定のように依存の薄い部分を、別々の担当が並行して組む。多数の候補の並列評価——複数の設計案やライブラリ候補を、担当ごとに同時に検証して結果を持ち寄る。いずれも「独立した小分けが取れて、それぞれ手がかかる」という共通の形をしている。今回の実演の UI・音・触覚も、この形の一例だ。

一方で、素直に単一エージェントで進めたほうがよい作業もある。前の結果に強く依存する一本道の作業（設計を決めてからでないと実装に入れない、など）は、無理に並列化しても依存の壁で待ちが残る。1往復で終わる短い作業 も、分担や通信のオーバーヘッドだけが乗って過剰になる。並列サブエージェントは、あくまで「独立した仕事が並んでいる」ときに、その並びを畳み込む道具だと捉えるのがよい。

導入するなら、いきなり本番の大規模タスクに適用しない ことをすすめたい。まずは小さなスコープで、分担がうまく独立するか、司令塔が各係の進捗をさばけているか、を観察する。分け方が不適切だと、係同士が同じファイルを取り合ったり、依存を見落として手戻りが増えたりする。並列にすれば必ず速くなるわけではなく、独立性の見極めと、司令塔の差配 がそろって初めて効く。この手触りは、小さく試して掴むのが近道だ。また、係を増やすほど、進捗のやり取りや結果の統合といった”まとめる仕事”の比重も増える。Fable 5 の非同期連携の強みは、この”まとめる仕事”を長時間安定して回すための土台にあたる、と捉えると位置づけがはっきりする。

もうひとつ、実務で見落としやすいのが 束ねるコスト だ。係を増やすほど並走で稼げる時間は増えるが、その一方で、上がってきた成果物を突き合わせ、命名や前提の食い違いを直し、ひとつの完成物に統合する”まとめる仕事”の比重も増えていく。並列化の実際の効果は、「並走で畳み込んだ時間」から「統合にかかる時間」を差し引いた分で決まる、と捉えるとよい。係を細かく割りすぎると、この差し引きがマイナスに傾き、かえって遅くなることもある。独立した小分けを取りつつ、割りすぎない——この塩梅は、頭で決め打ちにせず、小さく試して掴んでいくのが現実的だ。とりわけ統合の局面では、各係が独立に作った成果物どうしが矛盾していないか（画面の前提とチェックの条件がずれていないか、など）を、司令塔がもう一度見直す工程を挟むと、手戻りを抑えやすい。独立に作ったからこそ、合流点での擦り合わせが効いてくる。

誠実に付け加えておくと、今回の話の一次情報は、あくまで leopardracer が紹介した 実演の様子 と、Anthropic が公表している Fable 5 の位置づけ・設計指針 だ。デモの内部実装が具体的にどのフレームワークで、どこまで独立して並列だったのか、といった細部は、公開情報からは分からない部分がある。それでも、そこで使われている dynamic workflow（動的に分ける） と 並列サブエージェント（同時に走らせる）、そして 非同期連携（待たずに受け取る） という3つの原理は、設計パターンとして確かなものだ。この3つを自分のタスクに当てはめて「独立に切れるか、同時に走らせられるか、待たずに束ねられるか」を問うことが、実演を”すごいデモ”で終わらせず、自分の現場の道具に変える出発点になる。

まとめ — 分けて、同時に、待たずに

leopardracer が紹介した Fable 5 の実演は、「1体のAIが分身して、UI・音・触覚を同時に作る」という絵で、並列サブエージェント の効き目を具体的に見せた。その内側にあったのは、依頼を見てから分担をその場で設計する dynamic workflow（分ける）、独立した担当を別々のサブエージェントとして同時起動する 並列実行（同時に走らせる）、そして司令塔が進捗を非同期で受け取りながら次を差配する 非同期連携（待たずに束ねる）——この3つの組み合わせだった。

このパターンの本質は、エージェントの”時間の使い方”を作り替える ことにある。1体が直列で順番にこなすと、独立した仕事の待ち時間まで積み上がってしまう。並列サブエージェントは、その待ちを畳み込み、独立した仕事を独立したまま同時に進める。ただし効くのは「独立した小分けが取れる」ときに限られ、依存の強い一本道や短い作業では旨みが出ない。まず問うべきは速さではなく、「この仕事は独立した小分けに切れるか」 だ。

Anthropic が Fable 5 の強みとして並列サブエージェントへの委譲と長時間の非同期連携を挙げ、その実演が公開されたいま、「どう賢く1回で答えるか」だけでなく「どう分けて、同時に、待たずに進めるか」が、エージェント設計の実践的なテーマになってきた。独立した小分けが取れる長時間タスクを抱えているなら、まず小さなスライスで、分担が独立するか・司令塔がさばけるかを観察してみる。1体が分身して並走し、進捗を受け取りながらまとまっていく様子を一度掴めば、「分けて、同時に、待たずに」という時間の使い方が、抽象論ではなく手触りのある設計判断に変わるはずだ。

参照ソース

・@leopardracer — Fable 5の並列エンジニアリングサブエージェント実演の引用投稿（2026-07-07）
・Introducing Claude Fable 5 and Claude Mythos 5（Anthropic公式, 2026-06-09）
・Building effective agents（Anthropic Engineering）
・Tool use overview（Claude Docs）
・Claude Fable 5 とMythos 5 入門（AI Heartland 解説）
・Claude Code の dynamic workflows 解説（AI Heartland 解説）
・Claude のツール・スキル・サブエージェントによる分解（AI Heartland 解説）
・Claude Fable 5 アドバイザーパターン入門（AI Heartland 解説）
・Claude Code のループ設計入門（AI Heartland 解説）