状態遷移図とは？基本的な定義や役割、書き方を具体例とともに解説

システムの状態変化を視覚的に整理し、曖昧な仕様や設計ミスを防ぐために役立つ「状態遷移図」。

特に、状態が複雑に変化する機能の開発では、状態遷移図を用いた視覚化がチーム内での情報共有に大きく貢献します。

本記事では、状態遷移図の定義や目的、類似の図表との違い、実務での具体的な活用例を解説します。

第三者検証の重要性｜資料ダウンロード

状態遷移図とは

まずは、そもそも状態遷移図とは何か、そしてどのようなシーンで活用されるものなのかを解説します。

状態遷移図の定義と目的

状態遷移図（State Transition Diagram）とは、システムがとりうる「状態」と、それらの間をつなぐ「遷移」の関係を視覚的に表現する図です。あるイベントや条件が発生したとき、システムがどのように状態を変化させるかを矢印で示します。

この図を用いる目的は、システムの挙動を明確に整理し、仕様の抜け漏れや誤解を防ぐことにあります。特に、状態の種類が多く、入力によって複雑に変化する機能では、文章だけの仕様書では理解が難しくなるため、状態遷移図を使って視覚的に情報を整理しておくと認識のずれを防ぎやすくなります。

状態遷移図と他の図表との違い

状態遷移図とよく混同される図に、「状態遷移表」や「フローチャート」があります。それぞれの違いは以下の通りです。

状態遷移表との違い

状態遷移表は、現在の状態とイベントの組み合わせによって「次の状態」と「実行されるアクション」を表形式で整理したものです。すべての状態とイベントの組み合わせを網羅できる点が大きな特徴であり、例えば「ある状態で特定のイベントが発生しても何も起こらない（＝遷移しない）」という情報も明示できます。

一方、状態遷移図は状態間の遷移に着目し、状態の変化がある部分だけを視覚的に表現します。流れがない関係（＝遷移が起こらない状態とイベントの組み合わせ）は図に描かれないこともあるため、すべてのパターンを俯瞰したい場合には状態遷移表のほうが適している場合があります。

図として視覚的に表すことで直感的に理解しやすいのは状態遷移図の利点です。
特に仕様を正確に確認したい局面では、状態遷移表の併用によって「起こること／起こらないこと」を明確に整理することができます。

フローチャートとの違い

フローチャートは、処理の手順や流れを順番に示す図です。それに対し、状態遷移図は「システムの状態変化」に着目し、それぞれの状態間のつながりを視覚的に表現します。そのため、条件によって状態が分岐・遷移するような複雑な処理や挙動がある場合には、状態遷移図のほうが全体の構造を把握しやすく適しています。

状態遷移図は、状態変化の流れを視覚的に把握しやすく、全体の動きや分岐を直感的に理解したい場面に向いています。一方、状態遷移表は、状態・イベント・アクションの組み合わせを網羅的に記述できるため、仕様の抜け漏れやテスト観点の整理に有効です。

また、処理の手順を順に追いたい場合にはフローチャートが適しています。それぞれの特性を理解し、目的に応じて図表を使い分けることで、設計やレビューの精度を高めることができます。

図の種類	特徴	適しているケース
状態遷移図	状態と状態の間の遷移を視覚的に示す	状態の変化や分岐の流れを視覚的に把握したい場合
状態遷移表	状態・イベント・アクションの組み合わせを網羅的に記述	状態ごとのあらゆるパターンを確認・整理したい場合
フローチャート	処理の手順や順序を示すフロー図	処理の流れを直線的に追いたい場合

状態遷移図が必要とされる場面

状態遷移図はすべてのシステム開発で必ず使われるわけではありませんが、特に次のような場面ではその効果を発揮します。

• 複雑なフローや多くの状態を持つ処理
  例：ログイン／ログアウト機能、ワークフロー処理、決済の状態管理など
  
  
• イベントや操作によって状態が変わるUI設計
  例：ボタンのON/OFF状態、モーダル（ユーザーに操作を求めるポップアップウインドウ）の開閉、通信ステータスの変化
  
  
• 異常系やエラー処理を含めて仕様を整理したいとき
  例：失敗時のリトライ処理、無効な入力への応答、タイムアウト処理

これらのように多くの状態や分岐が関係する機能の設計では、状態遷移図によって処理の全体像を可視化することが求められます。特にアジャイル開発のように、短いサイクルで設計と実装を繰り返す現場では、チーム内の認識を素早くそろえる手段として状態遷移図が有効です。

状態遷移図の構成要素と基本的な書き方

次に、状態遷移図を構成する主要な要素と、それぞれの意味や役割について解説します。

要素	内容	表記方法
状態（State）	一定の同じ動作を続けている／とどまっている様子	状態名（四角で囲う）または状態名（丸で囲う）
遷移（Transition）	ある状態から別の状態への遷移	→
イベント（Event）	状態を遷移させるきっかけ	→の上部にテキストで記載
アクション（Action）	遷移時に実行される処理や動作内容	イベントと合わせて「イベント／アクション」形式で→の上に記載するケースが多い

状態（State）

「状態」とは、システムがある特定の時点でどのような状況にあるかを表すもので、例えば「待機中」「ログイン済み」「エラー発生中」など、システムの内外における条件や振る舞いを示します。

状態遷移図では、状態を「丸」や「四角」で表現し、システムの流れの起点・終点となるポイントとして描かれます。状態を明確に区別しておくことで、処理の流れや分岐点を整理しやすくなり、設計やテストにおける抜け漏れ防止につながります。

遷移（Transition）

「遷移」とは、ある状態から別の状態へ移ることを指します。状態遷移図では、状態同士をつなぐ「矢印」で表され、矢印の始点が「現在の状態」、終点が「次に遷移する状態」を示します。

例えば、「未ログイン」→「ログイン試行中」→「ログイン成功」のように、ユーザーの操作やシステム処理によって状態が次々に変わっていく様子を、視覚的に表現することで、どの操作やイベントがどのような状態変化を引き起こすのかを可視化できます。

イベント（Event）

「イベント」は、状態を変化させるきっかけとなるアクションや条件です。ユーザーの操作（ボタンのクリックや入力の完了）や、システム内部の変化（一定時間の経過、データ受信など）が該当します。

状態遷移図では、矢印の上にイベント名を記述することで、「どのような条件で状態が変化するか」を明示します。イベントの定義が明確になることで、想定するフローの前提が整理され、関係者間の認識ズレを防ぐ効果が期待できます。

アクション（Action）

「アクション」とは、ある遷移が発生した際に実行される処理や動作のことです。例えば、「ログインボタンを押すと認証処理を実行する」や、「商品選択後に在庫を確認する」などが該当します。

状態遷移図では、「イベント／アクション」という形式で記述されることが多く、矢印の上に「ログイン押下／認証処理実行」のように書かれます。

アクションを明示することで、状態の変化に伴う処理内容まで可視化できるようになり、より精度の高い設計やレビューに役立ちます。

状態遷移図の作成手順

状態遷移図の作成は、以下の3つのステップを順に進めていくのが一般的です。

1. プロセスの状態を洗い出す

状態遷移図を作成する際は、まずシステムがとりうる「すべての状態」を洗い出す必要があります。具体的には、ユーザー操作やシステム処理のフローを上流から順に確認し、それぞれの時点でシステムがどのような状態にあるかを棚卸しします。

例えば、ログイン機能であれば「未ログイン」「認証中」「ログイン成功」「ログイン失敗」「アカウントロック」などが状態として考えられます。このとき、正常系だけでなく、異常系や例外的な状態も含めて列挙することが重要です。

【プロセスの状態の洗い出し】

状態名	説明
未ログイン	初期状態。ユーザーが未認証の状態
認証中	ログイン認証処理を実行中の状態
ログイン成功	認証成功後、ログイン済みとなった状態
ログイン失敗	認証に失敗した状態
アカウントロック	一定回数以上の失敗によるログイン操作が無効化された状態

すべての状態を洗い出しておくことで、後工程での設計漏れやテスト観点の抜けを防ぎやすくなります。

2. イベントと遷移の関係性を定義する

次に、どのような「イベント」が発生したときに、どの状態からどの状態へ「遷移」するのかを定義します。

例えば、「ログインボタンのクリック」によって「未ログイン」から「認証中」に遷移し、認証結果によって「ログイン成功」または「ログイン失敗」へ分岐する、という流れを整理します。

【イベントと遷移の関係性定義】

現在の状態	イベント（きっかけ）	遷移先の状態	アクション（処理）
未ログイン	ログインボタン押下	認証中	入力されたID/PW認証処理を開始
認証中	認証成功	ログイン成功	セッションを開始する
認証中	認証失敗（1～2回目）	ログイン失敗	エラーメッセージ表示
ログイン失敗	ログイン画面に戻るボタンの押下	未ログイン	ログイン画面に遷移
ログイン失敗	ログインを3連続失敗	アカウントロック	操作制限処理を開始

この際、「どういう状態遷移が許可されていて、何が禁止されているか」も明確にしておくと、仕様の曖昧さを防げます。（例：アカウントロック状態からログイン試行には遷移しない）。

また、遷移にともなって実行される処理（アクション）がある場合は、その内容も一緒に記載しておくと、後のテスト設計やレビューに役立ちます。

3. 図式化する

状態と遷移の関係が整理できたら、それを図式化していきます。基本的には、状態を「丸」や「四角」で表し、状態間の遷移は矢印でつなぎます。矢印の上には、トリガーとなるイベントや必要に応じてアクションも記載します。

図は紙やホワイトボードに書いても構いませんが、実務では作図ツールを使ってドキュメント化するのが一般的です。図式化した内容は、チーム内での認識合わせや仕様レビューにもそのまま使えるため、できるだけ早い段階でアウトプットとして整備しておくのがおすすめです。

身近な例で学ぶ状態遷移図

ここでは、日常生活でよく使われるサービスを例に、状態遷移図の考え方を具体的に紹介します。

自動販売機の動作

まずは、自動販売機の動作を状態遷移図で整理してみましょう。

主な「状態」は以下の通りです。

• 待機中（何も操作されていない初期状態）
• 金額投入済み（お金が投入され、選択可能な状態）
• 商品提供中（商品を送り出す処理中）
• 取引完了（商品提供後、釣り銭返却が済んだ状態）
  
  

状態遷移を引き起こすイベント（操作や条件）は次のように考えられます。

• お金を投入 → 「金額投入済み」へ
• 商品を選ぶ → 「商品選択中」から「商品提供中」へ
• 商品が出る → 「取引完了」へ
• 釣り銭が返却される → 「待機中」に戻る
  
  

以上を図式化すると、以下のようにまとめることができます。

このように整理することで、ユーザーの一連の操作によって状態がどう変化するかが可視化されます。

さらに、異常系にあたる「残高不足」「品切れ」などの状態を加えることで、機能の全体像をまとめた状態遷移図が完成します。

状態遷移図を活用したテスト設計

ここからは、状態遷移図をテスト設計にどう活かすかを具体的に解説します。

状態遷移テストとは

状態遷移テストとは、状態遷移図をもとにテストケースを設計し、システムが意図したとおりに状態を変化させるかを確認するブラックボックステスト技法の1つです。

例えば、ログイン機能において「未ログイン → ログイン試行中 → 成功」や「失敗 → ロック」といった状態遷移が、仕様通りに動作するかを検証します。状態のつながりを体系的に確認することで、システムのフロー全体を通じた品質の確保が可能になります。

テストケースの設計方法

状態遷移テストでは、以下のような手順でテストケースを設計します。

1. 状態とイベントの洗い出し

状態遷移図に記載されたすべての状態と、そこへ遷移させるイベントを一覧にします。

【ICカード改札機の例】

現在の状態	イベント（遷移のきっかけ）	遷移先の状態
待機中	カードがタッチされる	認証中
認証中	残高が十分	通過中
認証中	残高不足または無効カード	エラー
通過中	一定時間内に通過完了	待機中
エラー	一定時間経過または係員による解除	待機中

2. 遷移パターンの抽出

状態A→状態B のような遷移の組み合わせをすべて抽出します。正常系だけでなく、準正常系や異常系（失敗・例外）も含めて整理していきます。

現在の状態	イベント	次の状態	補足
待機中	カードタッチ	認証中	ユーザー操作
認証中	残高あり	通過中	正常処理
認証中	残高不足・無効カード	エラー	準正常系（入力エラー処理）
通過中	通過完了	待機中	自動復帰
エラー	一定時間経過／係員操作でリセット	待機中	状態復帰／マニュアル対応

3. 状態の組み合わせによる網羅

「1回の遷移をテスト」「2回続けた遷移をテスト」など、組み合わせパターン（n-遷移カバレッジ）を考慮して網羅性を高めます。

テストケース名	遷移の流れ	テスト目的
正常通過	待機中→認証中→通過中→待機中	ユーザーが正常に通過できることを確認
残高不足処理	待機中→認証中→エラー→待機中	残高不足でエラーになった後に初期状態に戻る動作を確認
無効カード処理	待機中→認証中（無効）→エラー係員解除→待機中	無効カードでのエラー処理と係員対応後の復帰確認
未通過タイムアウト	認証中→通過中→通過せず放置→待機中	ユーザーがゲートを通らなかった場合の処理確認

例：状態遷移図

例：0-遷移カバレッジ

テストID	網羅する状態遷移	イベント	期待結果
1	待機中➔認証中	カードをタッチ	認証中
2	認証中➔エラー	残高不足	エラー
3	認証中➔エラー	無効カード	エラー
4	認証中➔通過中	残高が十分	認証中
5	エラー➔待機中	一定時間内に通過	待機中
6	エラー➔待機中	通過せずに一定時間経過	待機中
7	通過中➔待機中	一定時間経過	待機中
8	通過中➔待機中	係員による解除	待機中

例：1-遷移カバレッジ

テストID	遷移元	網羅する状態遷移	イベント	期待結果
1-1	待機中	待機中➔認証中➔エラー	カードをタッチ	認証中
1-2	認証中	待機中➔認証中➔エラー	残高不足	エラー
2-1	待機中	待機中➔認証中➔エラー	カードをタッチ	認証中
2-2	認証中	待機中➔認証中➔エラー	無効カード	エラー
3-1	待機中	待機中➔認証中➔通過中	カードをタッチ	認証中
3-2	認証中	待機中➔認証中➔通過中	残高が十分	通過中
4-1	認証中	認証中➔エラー➔待機中	残高不足	エラー
4-2	エラー	認証中➔エラー➔待機中	一定時間内に通過	待機中
5-1	認証中	認証中➔エラー➔待機中	無効カード	エラー
5-2	エラー	認証中➔エラー➔待機中	一定時間内に通過	待機中
6-1	認証中	認証中➔エラー➔待機中	残高不足	エラー
6-2	エラー	認証中➔エラー➔待機中	通過せずに一定時間経過	待機中
7-1	認証中	認証中➔エラー➔待機中	無効カード	エラー
7-2	エラー	認証中➔エラー➔待機中	通過せずに一定時間経過	待機中
8-1	認証中	認証中➔通過中➔待機中	残高が十分	通過中
8-2	通過中	認証中➔通過中➔待機中	一定時間経過	待機中
9-1	認証中	認証中➔通過中➔待機中	残高が十分	通過中
9-2	通過中	認証中➔通過中➔待機中	係員による解除	待機中
10-1	エラー	エラー➔待機中➔認証中	一定時間内に通過	待機中
10-2	待機中	エラー➔待機中➔認証中	カードをタッチ	認証中
11-1	エラー	エラー➔待機中➔認証中	通過せずに一定時間経過	待機中
11-2	待機中	エラー➔待機中➔認証中	カードをタッチ	認証中
12-1	通過中	通過中➔待機中➔認証中	一定時間経過	待機中
12-2	待機中	通過中➔待機中➔認証中	カードをタッチ	認証中
13-1	通過中	通過中➔待機中➔認証中	係員による解除	待機中
13-2	待機中	通過中➔待機中➔認証中	カードをタッチ	認証中

1-遷移カバレッジでは、2つの状態遷移を連続で確認する必要があります。そのため、0-遷移カバレッジと比較して、多くのテストケースが必要になります。

ミッション／セーフティ・クリティカル・ソフトウェアでは、1-遷移カバレッジの達成が推奨されています。この段階では、対象ソフトウェアに応じた網羅性を確保します。

4. アクションの検証

状態遷移に伴って実行される処理（アクション）が正しく行われたかもチェック項目に含めます。

遷移の流れ	アクション（実行される処理）
待機中→認証中	ICカード情報の読み取り／残高確認
認証中→通過中	改札ゲートを開ける／通過音を鳴らす
認証中→エラー	改札を閉じたままにする／エラー音を鳴らす
通過中→待機中	一定時間経過後にゲートを閉じ、初期状態に戻す
エラー→待機中	一定時間で自動リセット、または係員におるリセット操作で復帰

これらのステップを通してテストケースを組み立てることで、漏れやダブりのない、信頼性の高い設計につなげることができます。

状態遷移テストのメリットと注意点

状態遷移テストには次のようなメリットと注意点があります。

メリット

• テストの網羅性が高い
  あらゆる状態・遷移をカバーすることで、バグの取りこぼしを防げる
  
  
• ユーザー操作に近い視点で検証できる
  実際の利用フローを再現した形でテストを実施できる
  
  
• 異常系（例外処理）のテストが設計しやすい
  「想定外の遷移」がないか、事前に可視化できる

注意点

• 状態や遷移が多すぎると設計が複雑になる
  特に大規模なシステムでは無数の状態が存在するため、粒度を適切に調整し、現実的に遂行可能なテストを設計することが重要
  
  
• 図とテストケースの整合性を常に保つ必要がある
  開発中の仕様変更に応じて状態遷移図・テストケースの両方を随時メンテナンスする体制が求められる

状態遷移図を活用する際のベストプラクティス

最後に、状態遷移図を実務で効果的に活用するために意識しておきたいポイントを紹介します。

適切な抽象度でのモデリング

状態遷移図を作成する際は、「細かすぎず」「曖昧すぎない」ちょうどいい粒度で状態を定義することが大切です。

例えば、ログイン機能の状態を「パスワード入力完了」「ボタン押下」「認証待機中」などと、細かく状態を分けすぎると、図が複雑になり実用性が下がってしまいます。

一方で、「ログイン中」とだけ表現すると、失敗時やエラー処理の検討が不十分になりがちです。

テスト担当者には、ユースケースに応じて状態をどの単位で分けるべきかを判断する力が求められます。

関係者との共有とレビュー

状態遷移図を効果的に活用するには、適切なタイミングと手段で関係者に共有し、レビューを行う工夫が欠かせません。

設計初期の段階で共有のタイミングを決め、レビュー担当を明確にしておくことで、図の活用が形骸化するのを防げます。

また、コメントの書き込みや修正履歴が残せるツールを使うことで、関係者全員の認識を揃えやすくなります。専門用語を使わず図に直接補足できれば、非エンジニアにも伝わりやすくなるでしょう。

継続的な更新とメンテナンス

状態遷移図は一度作って終わりではなく、設計や仕様変更に応じて更新し続けることが前提の資料です。

機能追加や仕様変更によって状態や遷移が変わることは珍しくありません。それにもかかわらず、図が更新されないままだと、実装とのズレが生じ、ドキュメントとしての信頼性が低下してしまいます。

特にアジャイル開発のように頻繁に仕様が変わる環境では、状態遷移図の更新もルーティンとして組み込み、常に最新の状態を維持する体制を整えておくことが必要です。

状態遷移図を活用した品質向上に向けて

状態遷移図は、システムの状態変化を可視化し、設計の精度向上やテストケースの網羅性確保に大きく貢献する手法です。

 特に、複雑な状態管理やユーザーの操作によって振る舞いが多様に変化する機能において、その重要性は一層高まります。

「状態が整理されていない」「例外処理の仕様が曖昧」「テスト設計に漏れがある」などの課題に心当たりがある場合は、状態遷移図を導入・見直すことが改善に向けた大きな一歩になるでしょう。

AGESTでは、状態遷移図を含む各種設計ドキュメントのレビュー支援や、網羅性の高いテスト設計を通じて、システム品質の継続的な向上をサポートしています。

品質確保に強い運用体制を目指す方は、ぜひAGESTのサービスをご活用ください。

ドキュメントインスペクションサービス詳細ページ

TFACT (AIテストツール)

関連コンテンツ