F-3: オーケストレーション vs コレオグラフィ¶

この相反は何か¶

複数のコンポーネント（エージェント、サービス、ツール）の協調方式として、中央の指揮者（オーケストレータ）が全体の制御フローを管理するか、各コンポーネントがイベントに反応して自律的に動き、全体の振る舞いが創発する（コレオグラフィ）かという二者択一です。

この選択が排他的である理由は、制御の所在が根本的に異なるためです。オーケストレーションでは「次に何をすべきか」を中央の1箇所が知っています。コレオグラフィでは「次に何をすべきか」は各コンポーネントが自分で判断し、中央には全体の状態を知る場所がありません。どちらを主軸にするかによって、障害処理・監査・デバッグ・スケーリングの設計が全く異なります。

AIエージェントの文脈では、この選択が特に重要になります。エージェントは確率的（F3）であり、監査対象になりやすい（F16）ためです。中央集権的な制御は「なぜこの順序で実行されたか」を説明しやすく、[accountability] が高い業務系システムでは強い優位性を持ちます。一方、探索的な処理や高スケールのイベント駆動処理では、中央がボトルネックになり、コレオグラフィの疎結合性が活きます。

選択肢A：オーケストレーション（中央集権）¶

中央のオーケストレータが全体のワークフローを定義し、各コンポーネントを順次または並列に呼び出し、結果を集約して次のステップを決定します。Temporal、Airflow、LangGraphのSupervisorパターンなどが典型的な実装基盤です。

オーケストレーションの最大の利点は制御の明確さと監査性です。ワークフローの全体像が1箇所に定義されているため、「今どこまで進んでいるか」「なぜこのステップが実行されたか」が常に明らかです。障害時のリカバリも、オーケストレータがどのステップで失敗したかを特定し、そこから再開できます。[accountability] が高い環境では、この透明性が規制要件を満たすために不可欠です。

しかしオーケストレーションには2つの弱点があります。第一に、スケーラビリティの制約です。すべてのフローが中央を経由するため、中央がスループットのボトルネックになりえます。第二に、結合度の高さです。新しいコンポーネントを追加するたびにオーケストレータの定義を変更する必要があり、独立したチームによる並行開発が困難になります。

エージェント固有の利点として、オーケストレータがLLMの出力を検証してから次のステップに進めるため、ハルシネーション（F4）の伝播を各ステップで遮断できます。予算管理もオーケストレータが一元的に行えるため、コスト制御が容易です。

選択肢B：コレオグラフィ（イベント駆動）¶

各コンポーネントはイベントバス（Kafka、EventBridge、RabbitMQなど）上のイベントを購読し、関心のあるイベントが発生したら自律的に処理を実行し、結果を新たなイベントとして発行します。全体の制御フローを知る中央は存在せず、振る舞いはイベントの連鎖として創発します。

コレオグラフィの最大の利点は疎結合とスケーラビリティです。各コンポーネントはイベントのスキーマだけを共有し、他のコンポーネントの存在を知りません。新しいコンポーネントの追加はイベントの購読を追加するだけで済み、既存のコンポーネントに変更は不要です。各コンポーネントは独立してスケールでき、イベントバスがバッファとして機能するため、一時的な負荷の偏りを吸収できます。

しかしコレオグラフィには深刻な弱点があります。全体の状態の可視性が著しく低いのです。「このタスクは今どこまで進んでいるか」を知るには、複数のコンポーネントのイベントログを相関付ける必要があります。障害時に「どこで止まっているか」を特定するのも困難です。さらに、イベントの順序保証やべき等性の確保が各コンポーネントの責務となり、全体としての一貫性を維持するのに高い設計力が求められます。

エージェント固有の弱点として、LLMの出力が次のイベントとして伝播するため、ハルシネーションがチェーン全体に波及するリスクがあります。中央で検証を挟む場がないため、各コンポーネントが独自にガードレールを持つ必要があり、品質管理が分散してしまいます。

選定基準¶

選定は [accountability] を主軸に、以下の条件で判定します。

オーケストレーションに倒す条件：

[accountability] が中〜高で、処理の全体像と各ステップの判断根拠を事後に説明する必要があります。
処理に厳密な順序制約があります（審査→承認→実行など）。
LLMの出力を次のステップに渡す前に検証・変換する必要があります。
全体の予算（トークン・時間・コスト）を中央で管理したい場合です。
コンポーネント数が概ね10以下で、中央集権の運用負荷が許容範囲です。

コレオグラフィに倒す条件：

高スループット・高スケールが求められ、中央がボトルネックになりえます。
コンポーネントが多数のチームで独立して開発・デプロイされます。
イベントに対する「反応」が主な処理パターンです（通知、ログ記録、非同期集計など）。
[accountability] が低く、全体の実行順序を厳密に追跡する必要がありません。

デフォルトとハイブリッド¶

デフォルト：業務系システムではオーケストレーション（中央集権）がデフォルトです。 AIエージェントを含むシステムでは、LLMの確率的な出力を制御・検証する中央の存在が安全性と監査性の観点から重要です。コレオグラフィは、中央集権のスケーラビリティ限界に達してから検討しても遅くありません。

ハイブリッド：中核は中央集権、周辺探索はイベント駆動が実用的な折衷です。主要な業務フロー（受注→審査→承認→実行）はオーケストレータが管理し、周辺の非同期処理（ログ集約、通知送信、分析パイプライン）はイベント駆動で疎結合に構成します。オーケストレータが処理の各段階でイベントを発行し、周辺コンポーネントがそれを購読する構成が典型です。

判断を誤ったときの症状¶

オーケストレーションを選ぶべきだったのにコレオグラフィを選んだ場合：

「このタスクは今どの状態にあるか」を知るためにイベントログを手動で突合する作業が日常化します。
あるコンポーネントのLLM出力にハルシネーションが含まれたとき、それがイベントチェーンを通じて複数のコンポーネントに伝播し、被害が拡大します。
監査時に「なぜこの操作が行われたか」の因果関係を示せず、規制要件を満たせません。
イベントの順序逆転やべき等性の欠如により、一貫性のない状態が発生します。

コレオグラフィを選ぶべきだったのにオーケストレーションを選んだ場合：

オーケストレータへのリクエストが集中し、処理のスループットが頭打ちになります。
新しいコンポーネントを追加するたびにオーケストレータの定義変更とデプロイが必要になり、リリースサイクルが遅延します。
チーム間でオーケストレータ定義の変更が衝突し、マージコンフリクトが頻発します。
オーケストレータが単一障害点となり、その停止でシステム全体が止まります。