第26章：状態機械①：状態遷移表を作ってみよう🚥📋
「冪等性（第25章）」まで来たら、次の壁はコレ👇 **“同じ処理が何回来ても壊れない”ためには、そもそも「今この注文は何ができる状態？」をハッキリさせないと無理！**😵💫💥 そこで 状態機械（ステートマシン） の出番だよ〜🧠✨
（ちなみに2026年の最新ど真ん中は .NET 10 + C# 14 あたりが基準になるよ📌）(Microsoft)
今日のゴール🎯
- 「注文（Order）」の 状態（Status） を整理できる🧩
- 「イベント（Trigger）」を並べて 状態遷移表 を作れる📋✨
- 許される遷移 / 禁止遷移 を明確にできる🚫✅
- 「禁止遷移＝業務ルール違反」として扱う感覚がつく🚧
まずダメ例😇💥
ダメなやつ：if地獄で状態が破壊される
「今の状態」を意識せずに処理すると、すぐ破綻するよ〜😇
// 😇 ダメ例：状態を見ずに何でもできちゃう
public void Ship()
{
Status = OrderStatus.Shipped; // え、未決済でも発送できるの？😇
}
public void Pay()
{
Status = OrderStatus.Paid; // 発送後に決済…？😇
}
これだと、バグが“仕様っぽい顔”して紛れ込むのが最悪ポイント😵💫🌀
良い例😎✨
良いやつ：表で「できる / できない」を決めてからコードを書く
最初にやるのはコードじゃなくて 表📋✨ 表があると、チームでもAIでもレビューしやすいし、未来の自分が助かるよ〜🥹💖
状態機械の超基本🧠🧩
状態機械って要するに👇
- 状態（State）：いまのフェーズ（Created / Paid / Shipped / Cancelled …）
- トリガー（Trigger）：起こしたい操作（Pay / Ship / Cancel …）
- 遷移（Transition）：状態がどう変わるか（Created + Pay → Paid）
「状態機械」は昔から定番の考え方で、状態と遷移でプログラムを組み立てるのがコアだよ📌(Microsoft Learn)
手を動かす前にやること✍️🗂️
この章では、Orderingモジュールの「注文（Order）」を題材にするよ🛒✨ まずはこの2つを紙かメモに書く📝
1) 状態を列挙する🧩
まず最小でOK！今回はロードマップ通りこのへん👇
- Created（作成済み・未決済）
- Paid（決済済み）
- Shipped（発送済み）
- Cancelled（キャンセル済み）
2) トリガーを列挙する🔔
ユースケースの入口を意識して、これだけに絞る👇
- Pay（決済する）
- Ship（発送する）
- Cancel（キャンセルする）
状態遷移表を作ろう🚥📋✨
ここが本編だよ〜！ 「行＝今の状態」「列＝やりたい操作」にして、セルに結果を書く感じ😊
注文の状態遷移表📋
| 現在の状態＼トリガー | Pay（決済） | Ship（発送） | Cancel（キャンセル） |
|---|---|---|---|
| Created | Paid ✅ | × 🚫 | Cancelled ✅ |
| Paid | Paid ✅（冪等：変化なしでもOK）🔁 | Shipped ✅ | Cancelled ✅（※ポリシー次第） |
| Shipped | × 🚫 | Shipped ✅（冪等：再実行は無視）🔁 | × 🚫 |
| Cancelled | × 🚫 | × 🚫 | Cancelled ✅（冪等）🔁 |
ポイントはここ👇✨
- × は「業務ルール違反」（第17章の分類でいう “仕様としてのエラー”）🚧
- **冪等（同じ操作が来ても壊れない）**は、表の時点で決める🔁🛡️
- 「Paid から Cancel できるか？」は 事業ルール（あなたのEC次第）🧠
表ができたら、コードで“仕様”として固定する🔒✨
ここでは「ライブラリ無し」で最小実装にするよ（まずは自力で感覚をつかむ🧠✨） ※ライブラリを使うなら Stateless が定番の1つだよ〜（NuGetで配布されてる）(NuGet)
手を動かす（C#）⌨️✨
1) enum を作る🧩
public enum OrderStatus
{
Created,
Paid,
Shipped,
Cancelled
}
public enum OrderTrigger
{
Pay,
Ship,
Cancel
}
2) 遷移表をコードにする📋➡️🧱
public static class OrderStateMachineSpec
{
// 「許可される遷移だけ」定義するのがコツ✅
private static readonly IReadOnlyDictionary<(OrderStatus From, OrderTrigger Trigger), OrderStatus> _allowed
= new Dictionary<(OrderStatus, OrderTrigger), OrderStatus>
{
{(OrderStatus.Created, OrderTrigger.Pay), OrderStatus.Paid},
{(OrderStatus.Created, OrderTrigger.Cancel), OrderStatus.Cancelled},
{(OrderStatus.Paid, OrderTrigger.Pay), OrderStatus.Paid}, // 🔁冪等
{(OrderStatus.Paid, OrderTrigger.Ship), OrderStatus.Shipped},
{(OrderStatus.Paid, OrderTrigger.Cancel), OrderStatus.Cancelled},
{(OrderStatus.Shipped, OrderTrigger.Ship), OrderStatus.Shipped}, // 🔁冪等
{(OrderStatus.Cancelled, OrderTrigger.Cancel), OrderStatus.Cancelled} // 🔁冪等
};
public static bool TryGetNext(OrderStatus from, OrderTrigger trigger, out OrderStatus next)
=> _allowed.TryGetValue((from, trigger), out next);
}
3) Order から使う🛒✨
「できない遷移」はここで止める🚫
public sealed class Order
{
public OrderStatus Status { get; private set; } = OrderStatus.Created;
public bool TryApply(OrderTrigger trigger)
{
if (!OrderStateMachineSpec.TryGetNext(Status, trigger, out var next))
return false; // 🚫業務ルール違反
Status = next;
return true;
}
}
ここまでで「表＝仕様」が、コードに固定されたよ🥳🎉 （次章で ガード条件 を入れてもっと賢くするよ🧠🚦）
ミニ演習📝✨
演習1：表を拡張してみよう📋
次の状態を追加して、遷移表を更新してみてね👇
- Delivered（配達完了）📦🏠
質問：
- Shipped → Delivered は何トリガー？
- Delivered から Cancel はできる？（たぶん無理だよね😇）
演習2：禁止遷移のときに理由を返そう💬
今は false だけど、 「なぜダメか」を返すとAPIが親切になるよ😊✨
例：
- 「未決済の注文は発送できません」
- 「発送済みの注文はキャンセルできません」
AI活用プロンプト例🤖✨
仕様づくりをAIに手伝わせる🧠📋
- 「この注文フローの状態とトリガーを列挙して、状態遷移表をMarkdownで作って」
- 「禁止遷移を洗い出して、“業務ルール違反メッセージ案”を作って」
- 「冪等にすべきトリガー候補を提案して。理由も添えて」
コード支援（Copilot / Codex向け）⌨️✨
- 「この状態遷移表から、C#の遷移辞書（Dictionary）を生成して」
- 「TryApply が false のとき、理由を返す設計にリファクタして」
- 「状態遷移の単体テスト（xUnit）を作って」
まとめ📌
状態遷移表は、“できること / できないこと”を先に決めてバグを封じる表だよ🚥📋✨
次の第27章では、ここに ガード条件（条件付き遷移） を入れて、さらに事故りにくくするよ〜🧠🚦💕