【比較】オーケストレーションとコレオグラフィの違い¶

概要¶

複数のサービス（マイクロサービス）にまたがる業務処理をどう協調させるかの 2 つの流儀が「オーケストレーション（orchestration）」と「コレオグラフィ（choreography）」です。オーケストレーションは中央の指揮者がいる方式です。オーケストレータ（調整役のオブジェクト／ワークフローエンジン）が各参加サービスに「次はこれを実行せよ」とコマンドを送り、応答を受けて次の手を決めます。処理の流れと判断が 1 箇所に集約されます。コレオグラフィは指揮者がいない方式です。各サービスが自分の処理を終えるとドメインイベントを発行し、それを購読している他サービスが反応して自分の処理を進めます。全体の流れはどこにも書かれておらず、各サービスの「イベントへの反応」の連鎖として創発します。microservices.io はサガ（saga）パターンの文脈で、前者を「オーケストレータが参加者に実行すべきローカルトランザクションを指示する」、後者を「各ローカルトランザクションがドメインイベントを発行し、それが他サービスのローカルトランザクションを起動する」と定義しています。

両者が混同される理由は、どちらも「分散トランザクションを使わずに複数サービスで一連の処理（とくにサガ）を成立させる」目的が同じで、実装でも同じメッセージ基盤を使えるためです。しかし制御の所在が決定的に違います。オーケストレーションは中央が流れを握る（可視性・制御が得やすいが指揮者が単一の重心になりやすい）、コレオグラフィは各サービスがイベントに自律反応する（疎結合・自律になりやすいが全体像が見えにくく障害追跡が難しい）。どちらが優れているという話ではなく、可視性・結合度・障害ハンドリングのトレードオフで選びます。バックアップ的な文脈としてサガ（分散トランザクションの代替）があり、その「コーディネーション方式」としてこの 2 つが登場します。

例えるなら：オーケストラの指揮者 vs ダンサーの群舞¶

オーケストレーションは文字どおり「指揮者のいるオーケストラ」です。指揮者（オーケストレータ）が「次は弦楽器、次は管楽器」と指示（コマンド）を出し、奏者は指揮者だけを見て演奏します。全体の進行は指揮者の頭の中にあり、止めたい・やり直したい（補償したい）ときも指揮者が判断します。可視性と制御は高い一方、指揮者がいなければ曲は進みません。コレオグラフィは語源どおり「振付（choreography）に従う群舞」です。中央の指揮者はおらず、各ダンサーは「相手がこう動いたら自分はこう動く」という取り決め（イベントへの反応）だけを知っていて自律的に踊ります。疎結合で柔軟ですが、全体の振付がどこにも書かれていないため、振りがずれたとき（障害時）に「どこで何が起きたか」を俯瞰しづらくなります。比喩は制御の所在を掴むのに有効ですが、実システムでは両者を混在させる（部分的にオーケストレーション）構成も一般的な点に注意してください。

詳細比較¶

項目	オーケストレーション (Orchestration)	コレオグラフィ (Choreography)
制御の所在	中央のオーケストレータが集中管理	中央調整役なし。各サービスに分散
通信スタイル	コマンド駆動（「これを実行せよ」と指示し応答を受ける）	イベント駆動（「これが起きた」を発行し各自が反応）
流れの定義場所	オーケストレータ 1 箇所に明示的に記述	どこにも一元記述されず、反応の連鎖として創発
可視性・監視	高い（流れと状態が中央で追える。障害検出・回復が比較的容易）	低い（全体像が掴みにくく、イベント連鎖の障害追跡が困難）
結合度	業務フローの結合は中央に集まる（が通信結合は実装次第）	サービス間は疎結合・自律になりやすい
障害・補償の扱い	中央が補償トランザクションの順序を判断・調整しやすい	各サービスが補償イベントを発行し合う設計が必要で複雑化しやすい
主なリスク	オーケストレータが重心化・肥大化（ロジック集中・単一障害点になり得る）	フローが見えず、循環/想定外のイベント連鎖、デバッグ困難
代表例	サガオーケストレータ、ワークフローエンジン（例: Camunda）	イベント駆動アーキテクチャ、pub/sub によるサービス連携

microservices.io はサガの 2 つの調整方式を「Orchestration：オーケストレータ（オブジェクト）が参加者に実行すべきローカルトランザクションを指示する」「Choreography：各ローカルトランザクションがドメインイベントを発行し、それが他サービスのローカルトランザクションを起動する」と定義しています。Camunda は orchestration を「中央の権限／調整役がコマンド駆動で各コンポーネントの動作を管理・調整する」、choreography を「中央の権限／調整役なしに、コンポーネントがイベント駆動で互いに作用する」と説明し、可視性については「オーケストレーションは中央調整役が全相互作用を見渡せるため全体像を得やすく、コレオグラフィは中央調整役がないため全体像を得にくい」としています。

よくある誤解¶

「オーケストレーションは常に密結合、コレオグラフィは常に疎結合だ」は誤り。 Camunda は「オーケストレーションは密結合だと思われがちだが、それは正しくない」と明言しています。通信スタイル（同期/非同期）と構造的な結合度はしばしば混同されており、オーケストレーションでもコマンドをメッセージブローカ経由で運べば非同期・疎結合に保てます。「中央調整役がある＝密結合」と短絡するのは誤りで、結合度は実装方式に依存します。
「コレオグラフィの方が中央調整役がない分つねに優れている／シンプルだ」は誤り。 コレオグラフィは疎結合・自律という利点がある一方、Camunda が指摘するように「実装・保守がより複雑になり得る」。とくに複数サービスが関わると見えないイベント連鎖（event-chains）が生じやすく、全体フローがどこにも書かれていないため障害時の追跡（トラブルシュート）が難しくなります。常に優れているわけではなく、可視性とのトレードオフです。
「オーケストレーション＝コンテナオーケストレーション（Kubernetes など）のことだ」は文脈の取り違え。 本記事の「オーケストレーション」はビジネスプロセス／サービス間処理の調整（サガ・ワークフロー）を指します。Kubernetes のようなコンテナのスケジューリング/管理も「オーケストレーション」と呼ばれますが別概念です。同じ語でも対象が違うため、文脈を確認せず混同しないようにします。
「サガ＝オーケストレーションのこと」は誤り。 サガは「分散トランザクションを使わずに複数サービス間のデータ整合性を保つためにローカルトランザクションを連ねるパターン」であり、そのコーディネーション方式としてオーケストレーションとコレオグラフィの 2 通りがあります。サガ＝オーケストレーション、ではなく、サガはどちらの方式でも実装できます（microservices.io が両方式を提示）。

実務での選び分け¶

業務フローが複雑・分岐や補償（ロールバック相当）が多い・全体の進行を可視化し監視/再実行したい → オーケストレーション。流れを 1 箇所に記述でき、障害検出・補償順序の制御がしやすい（ワークフローエンジンの活用も検討）。
サービスを独立して開発・デプロイ・スケールしたい・関与サービスが少なくフローが単純・高スループットで中央のボトルネックを避けたい → コレオグラフィ（イベント駆動）。
オーケストレーションを選ぶときの注意 → オーケストレータにビジネスロジックを詰め込みすぎると重心化・肥大化し単一障害点になる。調整（順序制御）に責務を絞り、各サービスのドメインロジックは各サービスに残す。
コレオグラフィを選ぶときの注意 → 全体フローがどこにも書かれないため、分散トレーシング・イベントの相関 ID・イベントカタログで「見えないイベント連鎖」を観測可能にする。循環イベントに注意。
「疎結合だからコレオグラフィ」と決める前に → 結合度は通信実装にも依存する（オーケストレーションでもメッセージ経由なら疎結合化できる）。可視性・障害追跡の要件と合わせて判断する。両方式の混在（部分的オーケストレーション）も現実的な選択。

ひとことまとめ¶

オーケストレーションは「中央のオーケストレータがコマンドで各サービスに指示し流れと判断を集約する（可視性・制御が高いが重心化のリスク）」、コレオグラフィは「中央調整役なしに各サービスがイベントに自律反応する（疎結合・自律だが全体像が見えず障害追跡が難しい）」であり、制御の所在と可視性・結合度のトレードオフで選びます（サガはどちらの方式でも実装可能）。

出典・参考¶

Pattern: Saga — microservices.io — サガの調整方式は「Choreography：各ローカルトランザクションがドメインイベントを発行し他サービスのローカルトランザクションを起動」「Orchestration：オーケストレータ（オブジェクト）が参加者に実行すべきローカルトランザクションを指示」。サガは分散トランザクションなしで複数サービスのデータ整合性を保つパターン
Orchestration vs. Choreography — Camunda Blog — orchestration は中央調整役がコマンド駆動で管理、choreography は中央調整役なしのイベント駆動。「オーケストレーション＝密結合は誤り（通信スタイルと結合度の混同）」、可視性はオーケストレーションが高くコレオグラフィは全体像を得にくい・実装保守がより複雑になり得る
Pattern: Saga（Example: Orchestration-based saga 節）— microservices.io — 同ページの「Example: Orchestration-based saga」節で、サガオーケストレータが参加サービスへコマンド（例: Reserve Credit を Customer Service へ）を送り応答で次を決める集中制御の例を提示