--- title: "状態遷移図とは？状態遷移表との違い・書き方・状態遷移テストへの使い方を実装者目線で解説" url: "https://www.issoh.co.jp/tech/details/15260/" published: 2026-07-17 updated: 2026-07-17 categories: ["アーキテクチャ"] publisher: "株式会社一創" --- # 状態遷移図とは？状態遷移表との違い・書き方・状態遷移テストへの使い方を実装者目線で解説 状態遷移図とは、システムが取りうる「状態」と、状態を切り替える「遷移」を、丸と矢印のビジュアルで表した設計図です。注文処理の未払いから支払済への移り変わり、通信プロトコルの接続手順、画面のモード切り替えなど、条件によってふるまいが変わる処理を一枚の図に落とし込めます。UMLでは「ステートマシン図」として標準化されており、状態遷移表という表形式の相棒と組み合わせて使うのが実務の定石です。この記事では、図の基本要素と書き方、状態遷移表との使い分け、コードへの落とし込み、そして状態遷移テストへの使い方までを、実装者の視点でたどっていきます。 ## まとめ：状態遷移図は状態と遷移でふるまいを可視化する設計図 状態遷移図の核は4つの要素で説明できます。システムがとどまる**状態**、状態を切り替える**遷移**、遷移のきっかけになる**イベント**、遷移時に走る**アクション**。この4つを丸と矢印で描くと、「いま何ができて、次に何が起きるか」が一目で読み取れる図になります。 書き方の勘所は、初期状態（黒丸）から始めて状態を角丸の四角で並べ、イベントを矢印のラベルとして遷移を引き、終了状態（二重丸）で閉じることです。網羅の抜け漏れを潰す局面では、同じ内容を格子で表す状態遷移表が効きます。図で全体の流れを合意し、表で禁止遷移や埋め残しをあぶり出す。この二段構えが設計品質を底上げします。 図は書いて終わりではありません。`enum`と分岐、Stateパターン、テーブル駆動といった実装へそのまま対応づけられ、さらに状態遷移テストのテストケースを導く土台にもなります。作図の値打ちは、状態数が増えて遷移の抜けが怖くなったところで跳ね上がる。以下、要素・書き方・実装・検証・採用判断の順に掘り下げます。設計モデルとしての深掘りは兄弟記事の[ステートマシンとは](https://www.issoh.co.jp/tech/details/14686/)に委ねます。 ## 状態遷移図の基本要素となる状態・遷移・イベント・アクションの読み方 まず図を読み書きするための語彙を固めます。状態遷移図はどのツールで描いても、この4要素の組み合わせが土台です。ここを押さえると、初見の図でも意図を追えるようになります。 ### 状態・遷移・イベント・アクションからなる状態遷移図の基本要素 **状態**は、システムがある局面でとどまっている様子を指します。注文なら「未払い」「支払済」「発送済」がそれにあたり、図では角丸の四角で描くのが決まりです。**イベント**は状態を動かす刺激で、「入金通知」「発送指示」のように外部や内部から届きます。**遷移**は「ある状態で特定のイベントを受けたとき、どの状態へ移るか」という規則を表し、矢印で引きます。矢印のそばには受け取るイベント名を書き添えるのが約束事です。 4つめの**アクション**は、遷移や状態の出入りに伴って走る副作用を指します。メール送信、在庫の引き当て、ログ記録などがこれに該当し、矢印のラベルにイベントと並べて記します。ここで肝になるのが、遷移を「現在状態とイベントの組」でしか定義しないという制約です。未払いの注文に「発送指示」が届いても、その組に遷移規則がなければ何も起こらない。許可した動きだけが成立する閉じた世界が、抜け漏れを防ぐ土台になります。 ### 初期状態・終了状態・分岐など状態遷移図で使う特殊な記号の意味 通常の状態に加えて、図には3種類の特殊な印が登場します。塗りつぶした**黒丸**は初期状態を表し、図の始点を示す印です。中央を塗った**二重丸**は終了状態で、そこに達したら以降の遷移が起きないことを意味します。**ひし形**は分岐（選択擬似状態）で、遷移の途中でガード条件によって進む先を振り分けるときに置きます。 | 記号 | 意味 | 使う場面 | | ---- | -------- | ----------- | | 黒丸 | 初期状態（始点） | 図の開始位置を示す | | 角丸四角 | 状態 | とどまる局面を表す | | 矢印 | 遷移とイベント | 状態の切り替えを描く | | 二重丸 | 終了状態 | ふるまいの終わりを示す | | ひし形 | 分岐（条件判定） | ガードで行き先を分ける | これらの記号はUMLのステートマシン図として定義されているため、記法を揃えておくとチーム内でも社外のベンダーとも図の解釈がぶれません。作図ツールを問わず通じる共通語として身につけておくと便利です。 ## 状態遷移図の書き方を初期状態から終了状態まで順を追って解説する 要素がわかったら、実際に描く手順に移ります。いきなり矢印を引き始めると遷移が絡まりやすいので、状態を洗い出してから遷移で結ぶ順序を守ると、破綻しにくい図になります。 ### 状態の洗い出しから遷移・イベント・アクションを定義する作図の手順 作図はおおむね4つのステップで進みます。第一に、対象が取りうる**状態を洗い出す**。注文フローなら「未払い」「支払済」「発送済」「取消済」を書き出します。第二に、始点となる初期状態（黒丸）と、到達したら終わる終了状態（二重丸）を決めます。第三に、各状態から出る**遷移をイベントとともに引く**。「未払い」から「入金通知」で「支払済」へ、といった具合に、現在状態とイベントの組ごとに行き先を確定させます。第四に、遷移に伴う**アクション**とガード条件を書き添えて仕上げます。 描き終えたら、すべての状態に「入ってくる矢印」と「出ていく矢印」があるかを点検してください。入ってくる矢印がない状態は到達不能、出ていく矢印がない状態は行き止まり（終了状態でなければ設計の抜け）を疑うサインになります。この見直しだけでも、仕様の穴がかなり見つかるはずです。作図に慣れないうちは状態を5〜7個に抑え、細かい分岐は別図に切り出すと読みやすさを保てます。 ## 状態遷移図と状態遷移表の違いと開発現場での使い分けの判断基準 状態遷移図とよく並べて語られるのが状態遷移表です。両者は同じ情報を別の形で表しており、優劣ではなく役割で使い分けます。ここを取り違えると、レビューで漏れを見逃したり、逆に全体像を共有できなかったりします。 ### 漏れの検出は状態遷移表・流れの共有は状態遷移図という役割分担 状態遷移表は、縦に状態、横にイベントを並べ、交点に遷移先を書く格子です。空欄は「その組み合わせは起こらない（禁止遷移）」を表し、埋め残しがそのまま仕様の穴として浮かび上がります。すべての状態とイベントの組を機械的に並べるので、抜け漏れの検出に向いた表現です。 | 状態＼イベント | 入金通知 | 発送指示 | キャンセル | | ------- | ---- | ---- | ----- | | 未払い | 支払済 | ― | 取消済 | | 支払済 | ― | 発送済 | 返金待ち | | 発送済 | ― | ― | ― | 一方の状態遷移図は、状態を丸、遷移を矢印で描くため、全体の流れを直感的につかむのに向きます。関係者の合意形成や、初めて仕様に触れる人への説明では図が強い。実務では、表で禁止遷移や埋め残しを潰し、図で流れを共有する、という二段構えが定番です。レビュー用の網羅チェックには表、キックオフや引き継ぎには図、と場面で持ち替えると設計の精度が上がります。 ## 状態遷移図をコード実装へ落とし込むenumとStateパターンの対応 状態遷移図の値打ちは、図面がそのまま実装の設計図になるところにあります。図の状態は型に、遷移は関数の分岐に、素直に対応づけられるのが強みです。フラグ変数を増やして`if`を積み重ねる書き方から抜け出す道筋を見ていきます。より踏み込んだ実装方式の比較は[ステートマシンとは](https://www.issoh.co.jp/tech/details/14686/)で扱います。 ### enumとswitchによる素朴な状態遷移図の実装とその限界 もっとも手軽な実装は、図に描いた状態を`enum`で列挙し、現在状態に対する分岐で遷移を書く方法です。状態を`boolean`フラグの組で持つと、「支払済かつ未払い」のようなあり得ない組み合わせが表現できてしまい、それを排除する`if`が増殖します。状態を`enum`にまとめると、成立しない状態はそもそも書けなくなり、バグの温床を型で消せます。 ただし`enum`と`switch`だけでは、状態ごとの処理が膨らんだときに分岐が長大になりがちです。そこで、状態ごとの振る舞いをクラスに分ける**Stateパターン**や、遷移規則を表として持つ**テーブル駆動**へ進みます。図で描いた状態遷移表を、そのまま二次元のデータ構造として持たせれば、遷移の追加が表への一行追記で済むようになります。 ### Stateパターンやテーブル駆動へ状態遷移図を橋渡しする方式 Stateパターンは、各状態を1つのクラスとして表現し、遷移を「次の状態オブジェクトを返す」という形で実装します。状態が増えても既存クラスに手を入れずクラスを足すだけで済むため、状態ごとのロジックが厚い業務処理と相性がよい方式です。テーブル駆動は、状態遷移表をコードのデータとして持ち、現在状態とイベントで引いて次状態を決めます。仕様変更が表の書き換えで完結する点が利いてきます。 こうしたステートフルな業務処理を実際のシステムに落とし込むには、状態設計と実装を一貫させる体制が要ります。状態を持つ業務システムや業務Webアプリの設計から実装までは、[業務用・Webアプリ開発](https://www.issoh.co.jp/service/apps/business/)で受託しています。図面と実装のずれを防ぐには、状態遷移図をレビュー資料と実装仕様の両方で共有し続けるのが近道です。 ## 状態遷移図を使った状態遷移テストの設計と品質保証への使い方の要点 状態遷移図は設計だけでなく、テスト設計でも働きます。図から機械的にテストケースを導けるため、品質保証の現場では状態遷移テストの入力資料として重宝されます。ここが、単なる作図ツールとの違いが出るところです。 ### 状態遷移図から状態遷移テストのテストケースを網羅的に導く手順 状態遷移テストは、図に描いた遷移を1本ずつテストケースに変換していく技法です。もっとも基本的なのが、すべての遷移（矢印）を最低1回は通す「0スイッチカバレッジ」で、これで定義した遷移が期待どおり動くかを確かめます。さらに連続する2つの遷移の組を網羅する「1スイッチカバレッジ」へ広げると、遷移の順序に依存するバグまで踏み込めます。 図があれば、この網羅基準に沿ってケースを数え上げられます。矢印の本数がそのまま最小ケース数の目安になり、テスト計画の見積もりにも使える。状態遷移表と突き合わせれば、テストすべき組と、そもそも起こらない組（禁止遷移）を切り分けられるので、無駄なケースを省けます。図と表を両輪で使うと、テスト設計の網羅と効率が両立します。 ### 無効な遷移や到達不能な状態を状態遷移図から検出する品質の観点 品質保証では、正しい遷移を確かめるだけでなく、起きてはいけない遷移を弾けるかも見ます。禁止遷移、つまり「支払済の注文に再度の入金通知が届いた」ような組に対して、システムが状態を壊さず無視や拒否で応じるか。これは状態遷移表の空欄セルがそのままテスト観点になります。 加えて、図を眺めると**到達不能な状態**（入ってくる矢印がない）や**行き止まりの状態**（出ていく矢印がなく終了状態でもない）が視覚的に見つかります。こうした構造上の欠陥は、コードを書き始める前に図の段階で潰せるのが利点です。状態遷移図をレビューの起点に据えると、テスト工程まで持ち越さずに設計の穴を早期に摘み取れます。 ## 状態遷移図を採用すべき場面と作図を見送ってよい場面の判断基準 ここまでの利点を踏まえて、独自の判断として採用の線引きを言い切ります。状態遷移図は万能ではなく、描くコストに見合う場面と、かえって過剰になる場面があるのです。境目を持っておくと、作図が目的化せずに済みます。 ### 状態が3個以上に増えて遷移の抜け漏れが怖くなった時点の採用基準 採用に踏み切る条件は明確です。第一に、**状態が3個以上あり、状態ごとに許される操作が異なる**とき。決済フロー、予約の申込から確定・キャンセル、承認ワークフロー、通信プロトコルなどが典型です。第二に、**遷移の抜け漏れが事故に直結する**とき。二重課金や在庫の不整合が起きうる業務では、状態遷移表による網羅チェックが効きます。第三に、**関係者が多く仕様の共有コストが高い**とき。図があると、仕様の齟齬を早い段階で潰せます。この3条件のどれかに当てはまるなら、作図の手間は十分に元が取れます。 ### 状態が2個程度で分岐が単純な処理では作図を見送ってよい判断基準 逆に、見送ってよい場面もはっきりしています。状態が2個程度で分岐も単純な処理、たとえば「オンとオフ」だけのトグルや、単発の入力チェックなら、素朴な条件分岐のほうが読みやすく、図はかえって冗長になります。状態がほとんど変化しない参照系の処理も同様で、無理に状態機械へ当てはめる必要はありません。 判断の物差しは「状態数が増えて遷移の抜け漏れが怖くなったか」の一点に置くと迷いません。怖くなる前は素朴な分岐で軽く始め、状態やイベントが増えて分岐が絡み始めた時点で状態遷移図と状態遷移表を導入する。この段階的な移行が、過不足のない設計を保つ現実的なやり方です。作図それ自体を目的にせず、複雑さに応じて道具を持ち替える姿勢を保ってください。 ## よくある質問 ### 状態遷移図と状態遷移表はどちらを先に作るべきですか？ 全体の流れを関係者と合意したい初期段階では、直感的につかめる状態遷移図から描くと進めやすいです。図でおおまかな状態と遷移が固まったら、状態遷移表に落として禁止遷移や埋め残しを機械的に点検します。図で発想を広げ、表で漏れを詰める、という順序が実務では回しやすいでしょう。 ### 状態遷移図とアクティビティ図やフローチャートの違いは？ フローチャートやアクティビティ図は「処理の手順・流れ」を主役に描きます。対して状態遷移図は「システムがどの状態にあり、何をきっかけに移るか」を主役に据えます。同じ処理でも、着目点が手順なら前者、状態のライフサイクルなら後者が向く、と用途で選び分けてください。 ### 状態遷移図はどのツールで書くのがよいですか？ チームがすでに使う作図ツールがあればそれで足ります。UMLのステートマシン図に準拠したツールなら記法が揃い、状態遷移表との連携機能を持つ製品も少なくありません。テキストから図を生成する記法を使うと、変更履歴をコードと同じ仕組みで管理でき、レビューにも載せやすくなります。 ### 状態遷移図の状態はどのくらいの粒度で分けるべきですか？ 「その状態のときに許される操作が、他の状態と明確に異なるか」を基準にします。操作の集合が同じなら1つの状態にまとめ、異なるなら分けます。細かく分けすぎると図が読めなくなるため、まず粗く描いて、区別が必要になった箇所だけ後から割る進め方が扱いやすいです。 ### 状態遷移図はそのままコードに変換できますか？ 完全な自動変換は限定的ですが、状態を`enum`、遷移をテーブル、という対応づけで、図の内容をほぼ機械的に実装へ写せます。状態遷移表をそのままデータ構造として持たせるテーブル駆動なら、図と実装のずれを小さく保てます。詳しい実装方式は関連記事を参照してください。 ## 関連記事 - [ステートマシンとは？状態遷移の設計と実装パターン・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/14686/)（状態遷移図が表す設計モデルと、enum・Stateパターン・XState・AWS Step Functionsといった実装手段を深掘りする兄弟記事） - [シーケンス図とは？UMLの書き方・ライフラインやメッセージ・複合フラグメントを解説](https://www.issoh.co.jp/tech/details/13482/)（同じUML振る舞い図の姉妹。時系列のやり取りを描く） - [クラス図とは？UMLの書き方・関連や多重度・集約とコンポジションの違いを解説](https://www.issoh.co.jp/tech/details/13471/)（状態を持つ対象そのものを構造として定義するUML構造図） - [ユースケース図とは？UMLの書き方・アクターと関係・要件定義での使い方を解説](https://www.issoh.co.jp/tech/details/13469/)（状態遷移の起点となるイベントや要件を洗い出す上流工程の図） --- 出典: [状態遷移図とは？状態遷移表との違い・書き方・状態遷移テストへの使い方を実装者目線で解説]()（株式会社一創）