なぜ「一発の長いプロンプト」は複雑タスクで破綻するのか

オーケストレーターとは、複数の専門エージェント（特定の役割だけを持つAIの実行単位）を、決められた段取りで呼び出してつなぎ合わせる「指揮役」のことです。なぜそんな指揮役が必要になるのか。まず、一発の長いプロンプトが崩れる理由から見ていきます。

コンテキスト過積載という問題

ひとつのプロンプトに複雑な指示を詰め込むと、AIが同時に参照しなければならない文脈量が一気に増えます。後半の指示が前半の内容と矛盾しはじめ、モデルはどの制約を優先すべきか判断がつかなくなります。結果として、出力の後半になるほど指示から逸脱していきます。「リサーチ→構成→執筆→品質チェック」のように複数の専門性を1回で要求すると、モデルはいま何の役割を演じているのかが曖昧になり、品質が中途半端なところに落ち着きます。

途中の方針ぶれが連鎖する

複雑なタスクには「前の判断が後ろの前提になる」連鎖があります。ソフトウェアであれば、要件が変われば設計を、設計が変われば実装をやり直す必要があります。一発のプロンプトではどこで方針がぶれたかを特定できないため、やり直しのたびに全体を最初から投げ直すことになります。

オーケストレーターは「大きな1回」を「小さな複数回＋つなぎ役」に変える

オーケストレーターの発想はシンプルです。大きなタスクを小さなステップに分解し、各ステップを専門のエージェントに渡し、成果物を次のステップへ引き継ぐ「つなぎ役」を置く。これだけです。「大きな1回」を「小さな複数回とそのつなぎ」に変えることで、失敗箇所の特定・途中の方針修正・部分的なやり直しが、いずれも可能になります。

タスク分解の考え方 — 1ステップに1責務と成果物の契約

1ステップ＝1責務の原則

良いタスク分解の基準は「ひとつのステップがひとつの責務を持つ」ことです。「リサーチと執筆を同時にやる」ステップは分解が甘い状態です。リサーチは「情報収集と整理」、執筆は「収集済み情報の文章化」と責務を分けると、ステップが明確になります。分ける際の問いは「このステップが終わったとき、何が手元にあるか」です。答えられなければ、まだ分解が足りません。

入力と出力を「契約」として明示する

各ステップには、入力（何を受け取るか）と出力（何を渡すか）を明示します。この2点を事前に決めておくと、エージェント同士のつなぎが機械的に処理でき、オーケストレーターの仕事は「適切なタイミングで適切なエージェントに渡す」だけになります。たとえば要件定義のステップなら、入力は「やりたいこと・制約・ターゲット」、出力は「機能一覧・ページ構成・外部サービス連携先」という形です。この出力を、次の設計や実装のステップの入力としてそのまま受け渡せます。

relmeaの実例 — Crucibleと一括コンテンツ生成

relmeaが新規SaaSを開発するときに使っているCrucibleという枠組みは、この考え方を複数のフェーズに展開したものです。要件定義・設計・実装・テスト・デプロイを個別のフェーズとして定義し、それぞれに専任のエージェントを置いています。ひとつのフェーズが終われば成果物（要件書・スキーマ・テスト結果など）が中間保存され、次のフェーズへ渡ります。

コンテンツの一括生成でも同じ構造を使っています。ひとつのトピックを受け取り、担当エージェントがそれぞれ独立して記事を執筆するフェーズと、出力を確認して投稿スケジュールに反映するフェーズを分けています。コードの詳細ではなく、「段取りの設計」として共通する考え方です。

依存解決 — 直列と並列をどう見極めるか

依存解決とは何か

依存解決とは「どのステップが、どのステップの完了を待つ必要があるか」を決めること（依存関係を解くこと）です。これを事前に設計しておくと、無駄な待ち時間をなくし、安全に並列実行できる範囲を最大化できます。

直列にすべきケース

前のステップの出力が、次のステップの入力に直接なるときは直列にします。要件が決まらなければ設計できない、設計が決まらなければ実装できない、という依存がある場合です。また、後ろのステップが前のステップの「判断の是非」を前提にしている場合も直列にします。判断が確定していないまま次に進めると、後で全体をやり直すコストが発生します。

並列にすべきケース

互いに依存しない独立した作業は並列にします。たとえば「複数のアカウント向けに同じトピックの記事を書く」作業は互いに独立しているため、同時に走らせることができます。「競合A・競合B・競合Cを同時にリサーチする」調査作業も同様です。relmeaでは複数の専門エージェントを同時に起動し、それぞれの出力をオーケストレーターが集約するパターンを多用しています。

判断の目安

「このステップの結果が変わったとき、他のステップをやり直す必要があるか」が判断の目安になります。やり直す必要があれば依存あり（直列）、なければ依存なし（並列）です。

ロールバック設計 — 「どこまで戻れるか」を先に決める

ロールバックとは

ロールバックとは「失敗や方針変更が起きたとき、どのステップまで巻き戻して再実行するか」を決めることです。もとはシステム開発でデータベースの変更を取り消す操作を指す言葉ですが、ここではタスク実行の「やり直し単位」の設計として使います。

一発プロンプトにはロールバックがない

一発の長いプロンプトで作業した場合、失敗したときは最初からやり直すか、出力を手で直すかしかありません。どこで何が原因で失敗したかを特定する手段もなく、修正コストが常に最大になります。

ステップ実行がロールバックを可能にする

ステップ実行であれば、失敗したステップだけを特定して再実行できます。前のステップの成果物は中間保存されているため、失敗箇所より前をやり直す必要がありません。中間保存の設計は単純で、各ステップの完了時に成果物（ドキュメント・スキーマ・記事の下書きなど）をファイルやスプレッドシートに保存しておくだけです。後続ステップはその成果物を読み込んで開始するため、途中から再開できます。

relmeaでの具体的な実装例

Crucibleでは各フェーズの成果物をディレクトリに保存し、次のフェーズはそれを読み込んで始まります。「テストで失敗した場合は実装フェーズに戻る」「要件を変更する場合は要件定義フェーズに戻る」という巻き戻しの単位が事前に定義されています。どこまで戻るかは「どのステップの成果物が原因か」で決まります。

承認ゲートの置き方 — 全自動にしない判断軸

承認ゲートとは

承認ゲートとは、オーケストレーターが次のフェーズに進む前に人間の確認を求めるチェックポイントです。AIが判断を誤ったまま後工程を走らせると、取り返しのつかない状態になることがあります。すべてを自動にするのではなく、後戻りコストの高い分岐点だけに人の判断を挟む設計です。

ゲートを置くべき分岐点の見極め方

基準は「この決定を後から変えたとき、どれだけのコストがかかるか」です。変更コストが低いなら自動で進めてよく、高いならゲートを挟みます。後戻りコストが高い分岐点の例は次のとおりです。

  • 要件・スコープの確定：これが変わると設計・実装を全部やり直すことになります。
  • 本番環境へのデプロイ直前：本番に影響が出るためです。
  • 外部サービスの連携先・認証情報の確定：間違えると全工程を通じて影響します。
  • 大きな方針変更を含む提案の採否：アーキテクチャ変更やターゲット変更などです。

逆に、失敗しても容易に再試行できるステップ（リサーチ・初稿生成・フォーマット整形など）にはゲートを置かず、自動で進めます。

relmeaでの設計

relmeaのオーケストレーターには、要件確定・環境設定の確認・本番デプロイ直前といった分岐点に承認ゲートが定義されています。その他のフェーズはAIが自動で完了し、人の時間はゲートでの判断だけに絞っています。ゲートが多すぎると「全自動にした意味がない」状態になり、少なすぎると「知らないうちに取り返しのつかない操作が走った」状態になります。後戻りコストを軸に絞り込むことが、ちょうどよいゲート数の設計につながります。

始め方 — 「3回繰り返した段取り」から1つ作る

オーケストレーターと聞くと複雑そうに見えますが、本質は「段取りを文書化し、その順に専門エージェントを呼び出す仕組み」です。最初から数十体のエージェントを設計する必要はありません。

始め方の目安は「同じ段取りを3回繰り返したとき」です。毎回手作業で「まずリサーチ、次に構成、それから執筆、最後に投稿文を作る」という手順を踏んでいるなら、それをひとつのオーケストレーターとして定義します。各ステップの入力・出力・担当エージェントを文書に書くだけで、最小のオーケストレーターができあがります。

最初は直列3ステップで始め、「このステップとこのステップは独立している」と気づいたときに並列へ切り替える。「ここで失敗するとコストが高い」と気づいたときにゲートを足す。こうして段階的に育てることで、運用しながら実用的な仕組みになっていきます。relmeaが現在運用している数十体規模のエージェントチームも、最初から設計されていたわけではなく、「また同じパターンだ」と気づくたびに定義し直してきた積み重ねです。