第06章：方式の選び方（初心者が迷わない判断軸）🧭✨

この章のゴール🎯😊

• Orchestration（司令塔） と Choreography（イベント自律） のどっちを選ぶべきか、判断できるようになる✨
• 「なんとなく」じゃなくて、理由つきで選べるようになる🧠💡
• 選んだ方式で、次の章以降（用語・境界・補償・冪等性…）にスムーズに進める🚀

---

1) まず“超ざっくり結論”😆🧩

初心者が最初に迷ったら、だいたい Orchestration（司令塔方式）からでOK になりがちです🧑‍✈️✨ 理由はシンプルで、流れが見える／追える／変更しやすいから😊 （Choreography はハマると強いけど、最初は「どこで何が起きた？」が迷子になりやすいよ〜😵‍💫）

この“ざっくり結論”は、Microsoft の Saga 解説でも

• Choreography は 少数サービスの単純フロー向き
• Orchestration は 複雑フローや拡張に向く って整理されてます📚✨ (Microsoft Learn)

---

2) 2方式を一言で言うと？🗣️💞

Orchestration（司令塔）🧑‍✈️🎛️

• オーケストレーター（司令塔） が「次はAやって→終わったらB→失敗なら補償C」みたいに指示する✨
• 司令塔が 状態を持って進行管理 する（いわば“進行表”を握ってる）📋
• サービス側は「言われたことをやる」感じで 責務がスッキリしやすい🧼
• ただし、司令塔が中心なので “中心が落ちたら？” を考える必要はある⚠️ (Microsoft Learn)

Choreography（イベント自律）💃📣

• 司令塔はいない！
• 各サービスが イベントを出して、それを見た別サービスが次の処理をする🎶
• 小さいフローならシンプルで速い✨
• でも、ステップが増えると 「誰が何を受けて動いてる？」が見えづらくなる問題が出やすい😵‍💫
• 参加者同士が相互に反応し合って 循環（ループ）依存のリスクもある⚠️ (Microsoft Learn)

（定義の根っこは「ローカルトランザクションの連鎖＋失敗時は補償」だよ、っていうやつね😊） (microservices.io)

---

3) 迷わないための判断軸チェックリスト✅🧠✨

下の項目を見て、多い方に寄せるのがコツだよ😊💕

A. フローの複雑さ（ステップ数・分岐）🧩🔀

• ✅ ステップが少ない（2〜3サービス）／分岐ほぼ無し → Choreography 寄り💃
• ✅ ステップが多い（4サービス以上）／分岐・条件が増えそう → Orchestration 寄り🧑‍✈️

根拠：Choreography は 「少数・単純」向き、増えると混乱しやすいって整理されてるよ📚 (Microsoft Learn)

---

B. 仕様変更の頻度（あとから足す？並び替える？）🔧🧱

• ✅ 変更が少ない／固定の流れ → Choreography でもいける🙆‍♀️
• ✅ ステップ追加・順番変更が起きやすい → Orchestration が安定✨

根拠：Choreography は 新しいステップ追加でワークフローが分かりにくくなる、Orchestration は 複雑化・追加に向く (Microsoft Learn)

---

C. 見える化・追跡のしやすさ（運用・障害対応）🔎🧾

• ✅ 「とにかく運用で追えることが最優先！」 → Orchestration が楽になりがち😊

  • 司令塔が状態を握るので「今どこ？」が作りやすい

• ✅ 「イベント駆動で自然に拡張、中央に寄せたくない」 → Choreography

根拠：Choreography は 誰がどのコマンド（/イベント）に反応してるか追いにくいって弱点が明記されてるよ😵‍💫 (Microsoft Learn)

---

D. テストのやりやすさ🧪😇

• ✅ 統合テストを早く回したい（初心者ほど大事！） → Orchestration 寄り
• ✅ 「全サービス立ち上げ前提でもOK」 → Choreography でも可

根拠：Choreography は **統合テストが難しくなりがち（全サービス必要）**って書かれてるよ📚 (Microsoft Learn)

---

E. 循環依存（ループ）を避けたい？🔁⚠️

• ✅ 「イベントが回り始めて止まらないの怖い…」 → Orchestration
• ✅ 「ルールを強く決めて循環を避ける運用ができる」 → Choreography でもOK

根拠：Choreography は 参加者間の循環依存リスクがある、Orchestration はそれを避けやすい (Microsoft Learn)

---

F. “中心が落ちたら？”を許容できる？🧯🏥

• ✅ 中央のコンポーネントを極力持ちたくない → Choreography
• ✅ 中央があっても、冗長化・監視できる → Orchestration

根拠：Orchestration は 司令塔がワークフロー全体を担うので単一障害点になり得る (Microsoft Learn)

---

方式選択の意思決定フロー 🧭✅

（この“寄せ方”は、Microsoft の整理とほぼ一致するよ📚✨） (Microsoft Learn)

---

5) 例で体感しよ〜😆📦

例1：小さめ（2〜3サービス）🍰

注文 → 決済 → 在庫（分岐ほぼ無し）

• Choreography：

  • Order が OrderPlaced 出す📣
  • Payment が見て PaymentAuthorized 出す📣
  • Inventory が見て InventoryReserved 出す📣 → シンプルなら気持ちいい✨ （でも「どこで止まった？」が後から困ることも😵‍💫） (Microsoft Learn)

例2：中くらい（分岐あり）🍛

注文 → 決済（失敗なら終了）→ 在庫（失敗なら返金）→ 配送（失敗なら返金＋在庫戻し）

• もうこの辺から Orchestration が楽😊
• 司令塔が「成功/失敗と補償」を一本道で管理できる🧑‍✈️✨ (Microsoft Learn)

例3：大きめ（例外だらけ）🏰

本人確認／クーポン／ポイント／与信／不正検知／配送会社分岐…

• Choreography だとイベントの絡みが増えて「誰が何の責務？」が崩れやすい😵‍💫
• Orchestration だと「フローの中心線」を保ちやすい✨ (Microsoft Learn)

---

6) ミニ演習📝😆：「自分の想定アプリ」で方式決定！

ステップ1：想定アプリを1つ決める🎮🛍️

例：ミニEC、予約、サブスク、ポイント付与…なんでもOK😊

ステップ2：下の表を埋める✅

質問	YES / NO
参加サービスは4つ以上？
分岐（条件）が2つ以上ある？
ステップ追加が起きそう？
運用で「今どこ？」を強く求める？
循環依存が怖い？
中央コンポーネントを極力持ちたくない？

ステップ3：判定✨

• YES が多いほど Orchestration 🧑‍✈️
• 「中央を持ちたくない」が強くて、かつ他が軽いなら Choreography 💃

（この章は“決め方”が目的なので、完璧な正解はないよ😊 でも 理由が言えるのが大事！）

---

7) C#ミニコード（判断軸を“コードで言語化”してみる）🧑‍💻✨

「決め方」をコードにすると、チームで議論しやすくなるよ〜😊💕

public enum SagaStyle
{
    Orchestration,
    Choreography
}

public sealed record SagaChoiceInput(
    int ServiceCount,
    bool HasBranches,
    bool ChangesOften,
    bool NeedEasyTracing,
    bool WorriedAboutCycles,
    bool AvoidCentralComponent
);

public static class SagaStyleChooser
{
    // ※これは“考え方の型”を作る例だよ（正解アルゴリズムじゃないよ😊）
    public static SagaStyle Choose(SagaChoiceInput x)
    {
        var orchestrationScore = 0;
        var choreographyScore = 0;

        if (x.ServiceCount >= 4) orchestrationScore += 2; else choreographyScore += 1;
        if (x.HasBranches) orchestrationScore += 2; else choreographyScore += 1;
        if (x.ChangesOften) orchestrationScore += 2;
        if (x.NeedEasyTracing) orchestrationScore += 2;
        if (x.WorriedAboutCycles) orchestrationScore += 1;
        if (x.AvoidCentralComponent) choreographyScore += 3;

        return orchestrationScore >= choreographyScore
            ? SagaStyle.Orchestration
            : SagaStyle.Choreography;
    }
}

使い方（例）👇

var input = new SagaChoiceInput(
    ServiceCount: 5,
    HasBranches: true,
    ChangesOften: true,
    NeedEasyTracing: true,
    WorriedAboutCycles: true,
    AvoidCentralComponent: false
);

var style = SagaStyleChooser.Choose(input);
Console.WriteLine(style); // Orchestration

---

8) AI活用コーナー🤖💖（Copilot / Codex で爆速に決める）

A. 方式決定をAIにレビューしてもらうプロンプト📝🤖

そのまま貼って使えるよ〜！

• プロンプト①：おすすめ方式＋理由

  • 「私の業務フローは『注文→決済→在庫→配送』で、参加サービスは5つ、分岐は2つ、仕様変更が多いです。Saga の Orchestration と Choreography のどちらが良い？理由とリスク、運用の注意点を箇条書きで出して」

• プロンプト②：落とし穴チェック

  • 「Choreography を選ぶ場合に初心者がハマるポイント（追跡・循環依存・テスト）をチェックリスト化して」

• プロンプト③：イベント名・コマンド名の叩き台

  • 「このフローの Command と Event を名前案として20個出して。Eventは過去形で」

（Saga では “イベント/メッセージで次に進む” が基本なので、命名や責務整理をAIに手伝わせるのは超相性いいよ📨✨） (microservices.io)

B. Visual Studio の Copilot 便利ネタ🧰✨

Visual Studio 2026 では、Copilot 周りで **NuGet の情報取得や脆弱パッケージ対応を助ける仕組み（NuGet MCP Server）**が案内されてるよ🛡️📦 (Microsoft Learn) （メッセージング系ライブラリを使うと依存関係が増えがちだから、ここで安全性チェックできるのは地味に助かるやつ😊）

---

9) よくある落とし穴（初心者あるある）😵‍💫🕳️

落とし穴①：Choreography がいつのまにか“スパゲッティイベント”🍝

• 「AのイベントでBが動き、BのイベントでCが動き…あれ？誰が全体責任？」
• ステップ追加で 全体像が崩れやすい (Microsoft Learn) ✅対策：小さいうちはOK。増えそうなら早めに Orchestration 寄せを検討🧑‍✈️

落とし穴②：循環依存でイベントがループ🔁🔥

• 「補償イベントが別の処理を再トリガーして…無限回」みたいな事故⚠️ (Microsoft Learn) ✅対策：イベント設計のルール強化＋（不安なら）Orchestration

落とし穴③：統合テストが重くて回らない🧪💦

• Choreography は 全部動かさないと再現できないことが増える (Microsoft Learn) ✅対策：最初は Orchestration で「フロー中心」をテストしやすくする

落とし穴④：補償が“できる前提”で考えちゃう🙅‍♀️

Saga は「補償で整合を取る」けど、補償がいつも成功するとは限らない…って注意もあるよ😢 (Microsoft Learn) ✅対策：補償失敗時の“最後の逃げ道”（運用介入・保留状態）を意識する（これは後の章で深掘りするよ✨）

---

10) 開発メモ（いまの最新の前提っぽい話）🗓️✨

• .NET の 2026年1月の最新サービスリリースとして .NET 10.0.2 / 9.0.12 / 8.0.23 が案内されてるよ📦 (Microsoft for Developers)
• Visual Studio 2026 のリリースノートでは 2026/1/20 に 18.2.1 が出てるよ🛠️ (Microsoft Learn)

（この章では方式決定がメインだけど、後のハンズオンで“動く形”にするときに効いてくるよ😊）

---

まとめ🎀😊

• Choreography：少数サービスのシンプルな流れに強い💃✨（でも拡張で混乱・循環・テストが重くなりやすい） (Microsoft Learn)
• Orchestration：複雑化・拡張・追跡に強い🧑‍✈️✨（ただし中心の設計と耐障害性は意識） (Microsoft Learn)

次章では、どっちを選んでも事故りにくくするために、**用語と境界（ミニDDD風）**を整えていくよ〜📖🧼✨