状態遷移表を作り、二重処理と失敗時の扱いを決める

原稿の管理表（13項目：記事ID・カテゴリ・要件ID・先に読むと理解しやすい記事・成果物パス・対象ツール・検証状況・最終更新日など）

管理項目	内容
記事ID	05-02
主な中カテゴリ	05-02 保存・更新・整合性のルールを決める
関連中カテゴリ	05-01、04-01、05-03
関連要件ID	REQ-003、REQ-005、REQ-006、REQ-007
先に読むと理解しやすい記事	05-01（データ項目と関係を決める）を読んでいると理解しやすい。未読でも本文で必要な内容は説明する
到達目標	4状態の遷移、同時更新、二重処理、トランザクション（処理のまとまり）と失敗時の扱いを、承認と差戻しの例で説明できる。重複した承認操作への対処案を、実装の複雑さと安全性から比較して選定理由を書ける
3層の配置	理解する＝第3〜4節／作って確かめる＝第5〜7節／設計を判断する＝第8節
成果物パス	templates/05-02-state-rules_template.md、templates/05-02-state-rules_example.md
出典	第11節参照
対象ツール・バージョン	特定ツールに依存しない
検証状況	本文・ひな形・記入例はClaude Codeが作成。人による実読・内容確認は未実施
残課題	第11節参照
最終更新日	2026-09-20（新規作成）。2026-09-21（Final Content Audit：読む順路の「本文は今後制作予定」（全項目に本文がある現在は誤り）を削除。本文は不変）

この記事の会社・人物・数値はすべて架空の設定です。実在する会社や案件とは関係ありません。

この記事は何の話か。05-01で決めたデータをもとに、状態がいつ・誰の操作で・どんな条件のもとで変わるかを表にし、同時更新や二重処理が起きたときにどう扱うかを決める話です。

なぜ必要か。状態がいつ変わってよいかを決めずに実装すると、承認ボタンを2回押しただけで履歴が2件増えたり、既に承認済みの依頼がもう一度差戻しされたりする不具合が起こります。

この記事を読むとできるようになること。

• 4状態の遷移、同時更新、二重処理、トランザクション（処理のまとまり）と失敗時の扱いを、承認と差戻しの例で説明できる
• 設計書5.3の遷移表をもとに、状態遷移表と更新ルールを作れる
• 重複した承認操作への対処案を、実装の複雑さと安全性から比較して選定理由を書ける

読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。

• 基本だけ理解する：第1節→第3節→第4節→第5.2節の表→第9節。ここまでで「4状態の遷移」と「更新ルールの形」が分かり、ひな形を埋め始められます。
• 作って確かめる：上に加えて第5.4節（AIへの依頼）→第6節（失敗例と直し方）→第7節。
• 設計判断を深める：上に加えて第8節（重複対処案の比較、適用限界）。

1. 今回の業務課題と完成するもの

この記事でやることは、05-01で決めたデータ（依頼・利用者・履歴）をもとに、依頼の状態がいつ・誰の操作で・どんな条件で変わるかを状態遷移表にし、状態変更と履歴追加を1つのまとまりとして扱う更新ルール、同時更新・重複操作への対処を決めることです。

データの形が決まっても、「いつ状態を変えてよいか」「同時に2つの操作が来たらどうするか」が決まっていなければ、実装のたびに判断がばらつきます。この記事では、それを状態遷移表・更新ルールとして決めます。

この記事を読み終えると、次のものが手元にできます。

• 状態遷移表（現在の状態、操作、実行者、条件、次の状態、履歴、失敗時の扱い）
• 重複した承認操作への対処方法とその選定理由

2. 前提知識と読む順路

この記事で使う言葉を先に説明します。

状態遷移

一言でいうと、あるデータの状態が、どの操作によって、どの状態からどの状態へ変わるかの決まりです。たとえば、「提出済み」の依頼は、承認者が「承認」を実行すると「承認済み」に変わります。

これがないと、本来は起こらないはずの状態の変化（承認済みの依頼がもう一度差戻しされる、など）を防げません。

トランザクション（処理のまとまり）

一言でいうと、複数の処理を「全部成功する」か「全部失敗する（何も変わらない）」のどちらかにまとめる仕組みです。たとえば、「状態を『承認済み』に変える」と「履歴に承認の記録を追加する」は、2つの別々の処理ですが、どちらか一方だけが終わって片方が終わらない、という状態を許しません。

これがないと、状態は変わったのに履歴には記録が残らない、という食い違いが起こります（05-01の完了条件、REQ-007に対応）。

同時実行

一言でいうと、複数の利用者や複数の操作が、ほぼ同時にデータへアクセスすることです。たとえば、承認者がボタンを押した直後に、依頼者が差戻し前提で内容を編集しようとする、といった状況です。

二重処理

一言でいうと、同じ操作が、通信の再送やダブルクリックなどの理由で2回以上実行されてしまうことです。承認を2回実行すると、履歴が2件になってしまう、というのが典型的な問題です。

読む順路：データ項目・関係は05-01が該当します。役割別シナリオは04-01が該当します。この状態遷移表をもとにした権限設計は05-03が該当します。この記事だけでも進められるように、必要な説明は本文に含めています。

3. 理解する：なぜ状態遷移を先に決めるか

3.1 状態遷移を決めないとどうなるか

3.2 4状態と遷移の全体像

04-01・05-01で確認したとおり、状態は下書き・提出済み・差戻し・承認済みの4つです。この記事では、この4状態の間で許される遷移だけを決めます。新しい状態は追加しません。

3.3 よくある誤解

「状態遷移は実装の詳細なので、設計段階では細かく決めなくてよい」。誰が・どんな条件で状態を変えられるかは、REQ-002・REQ-003（役割に応じた権限）に直結する設計判断です。実装より先に決めます。

「同時に操作されることは滅多にないので、対策は後回しでよい」。滅多に起きないことほど、起きたときに気づきにくく、履歴の不整合として後から発見されることがあります。

「トランザクションはデータベースが自動でやってくれるので、考えなくてよい」。データベースの仕組み自体はありますが、「状態変更と履歴追加をどこからどこまで1つのまとまりにするか」は、この記事で設計として決める必要があります。

「AIに状態遷移を決めさせればよい」。AIは一般的な状態遷移の書き方を提示できますが、この業務でどの遷移を許すかは、設計書5.3に基づいて人が確認します（第4.3節）。

4. 判断すること

4.1 何を確認すればよいか

4.2 勝手に決めてはいけないこと

• 設計書5.3にない状態や遷移を、この記事で新しく追加しません。
• 承認済みの内容を編集・削除可能にする、代理承認を認めるなど、設計書5.3で「拡張候補」とされているものを、この記事で採用しません。
• 自己承認禁止（記事A・設計書5.2）を、この記事で緩めません。

4.3 AIに任せる範囲

一般的な状態遷移表の書き方、トランザクションの一般的な考え方の提示はAIに任せられます。しかし、この業務でどの遷移を許すか、二重処理への対処方法は、設計書5.3・REQ-006/007に基づいて人が判断します。

5. 作って確かめる：状態遷移表と更新ルールを作る

5.1 準備

05-01のデータ項目表、04-01の役割別シナリオ、設計書5.3の遷移表を用意します。

5.2 状態遷移表・更新ルール

設計書5.3の内容と一致させています。

承認済みの内容は編集・削除不可（設計書5.3）。この4遷移以外の状態変化は起こりません。

5.3 同時更新・重複操作の扱い

5.4 AIに遷移表の下書きを頼む

設計書5.3の内容をもとに、履歴・失敗時の扱いの列の下書きをAIに作らせます。

依頼・承認管理アプリの状態遷移表を作りたいです。設計書5.3の4つの遷移（下書き→提出済み、差戻し→提出済み、提出済み→承認済み、提出済み→差戻し）を渡します。

依頼：
1. 各遷移について、履歴に何を記録するか、失敗時にどう扱うかの案を出してください。
2. 二重処理（同じ操作が2回届く場合）への対処案も挙げてください。

してはいけないこと：
- 設計書5.3にない状態や遷移を追加しないでください。
- 承認済みの内容を編集可能にするなど、設計書5.3で拡張候補とされているものを採用しないでください。

6. 初稿・失敗例・修正

6.1 説明用の失敗例（AIの初稿という設定）

AIへの依頼の結果、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではありません）。

• 「承認済み→差戻し」という、設計書5.3にない遷移が追加されていた（承認後に取り消せると便利、という理由で）
• 二重処理の対処として「同じ操作は1秒以内なら無視する」という、時間だけに頼る案が提示されていた

6.2 見つけ方と直し方

• 存在しない遷移が追加されている：設計書5.3にありません。「承認済み→差戻し」を削除します。承認取消は設計書5.3で拡張候補とされており、この記事で採用しません。
• 時間だけに頼る対処：通信の遅延などにより、1秒以上空いて重複が届く可能性があります。状態の再確認（第5.2節の条件）に基づく対処に修正します。

指摘：
1. 「承認済み→差戻し」は設計書5.3にありません。削除してください。
2. 二重処理の対処を「時間で無視する」ではなく、「対象の状態が操作時にも有効か」を確認する方法に修正してください。

変えないこと：
- 設計書5.3の4つの遷移そのものは変更しないでください。

6.3 修正後の状態遷移表

修正後の状態遷移表・更新ルールは、第5.2節・第5.3節のとおりです。

7. 確認結果

第5.2〜5.3節の内容を、完了条件と照合します。

残る制限：この状態遷移表は架空の業務に基づく一例です。実際に同時に多数の操作が発生する状況での挙動は、実装・検証（08-02・08-04、09-02・09-03）を通じて確かめる必要があります。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。

8. 設計を判断する

8.1 重複した承認操作への対処案の比較

小規模な社内アプリであっても、ダブルクリックや通信の再送によって二重処理が起こる可能性は現実的にあります（REQ-006）。実装の複雑さが多少増えても、承認の効果が二重に発生することを確実に防ぐため、状態の再確認と操作の識別子を併用する案を採用します。

8.2 適用限界

この記事の状態遷移表は、架空企業「みらい業務サービス」の4状態・4遷移を前提にしています。将来、状態や遷移を追加する場合（たとえば設計書5.3で拡張候補とされている代理承認など）は、この記事の範囲外であり、あらためて設計判断が必要です。

9. 持ち帰る成果物

自分の業務に使うときの手順は次のとおりです。

1. 前工程（データ項目表、役割別シナリオ、設計の前提となる状態遷移）を用意する
2. 各遷移について、現在の状態・操作・実行者・条件・次の状態を書く
3. 各遷移に、履歴の内容と失敗時の扱いを書く
4. 同時更新・重複操作への対処方法を決める

10. 次工程への受渡し

次へ渡すもの：状態遷移表・更新ルール、重複した承認操作への対処方法（状態の再確認＋操作の識別子）。

次工程での使われ方：08-02・08-04（実装）では、この遷移表と対処方法をもとに処理を実装します。09-02（SAMPLE-B）・09-03（検証）では、この遷移表の条件が実際に守られているかを確認します。05-03（権限と外部連携を設計する）では、この遷移表を前提に、操作ごとの権限を設計します。

前工程へ戻る条件：状態遷移表を作る中で、05-01のデータ項目やデータ同士の関係に不足が見つかったら、05-01に戻って見直します。

11. 根拠と更新情報

• この記事の会社・人物・状態遷移の内容はすべて架空の設定です。
• 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
• 状態遷移表（4状態・4遷移の内容）は、教材設計書AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第5.3節にそのまま基づきます。承認済みの編集・削除不可、代理承認等が拡張候補である点も同節に基づきます。
• REQ-003（権限）・REQ-005（履歴）・REQ-006（重複防止）・REQ-007（状態変更と履歴追加の一体性）は、同設計書第5.4節に基づきます。
• 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
• 未確認事項：実際に多数の操作が同時に発生した場合の挙動は、この記事では確認しておらず、実装・検証の工程で確かめる必要があります。