重複・入れ違い・想定利用量のリスクを、実行できる範囲で確認する

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

管理項目	内容
記事ID	09-03
主な中カテゴリ	09-03 例外・権限・同時操作・負荷を確認する
関連中カテゴリ	09-02、05-02、05-03、04-04、09-01、08-04
関連要件ID	REQ-002、REQ-003、REQ-006、REQ-007
先に読むと理解しやすい記事	09-02（AIの実装を業務の流れで検証する、SAMPLE-B）、09-01（個々の処理を確認する）を読んでいると理解しやすい。未読でも本文で必要な内容は説明する
到達目標	許可されない操作、重複、途中失敗、同時更新、想定利用量に対する振る舞いを確かめる目的を、承認と差戻しの例で説明できる
3層の配置	理解する＝第3〜4節／作って確かめる＝第5〜7節／設計を判断する＝第8節
成果物パス	templates/09-03-risk-tests_template.md、templates/09-03-risk-tests_example.md、examples/09-03-risk-tests/（storage_guard.js、run_duplicate.js、run_resubmit_guard.js、run_repeat_scale.js、run_mutation_check.js）、evidence_public/phase5b1-2026-09-20/09-03/run_log.md
出典	第11節参照
対象ツール・バージョン	教材演習用にNode.js v24.18.0（node:fs、node:pathのみ使用）
検証状況	本文のコードは examples/09-03-risk-tests/ を正本とし、Claude Codeが2026-09-20にローカルで実行して stdout・stderr・終了コードを記録済み（第6〜7節、evidence_public/phase5b1-2026-09-20/09-03/run_log.md）。ただし本格的な同時アクセス・負荷は未検証（第7・8節）。人による実読・内容確認は未実施
残課題	第11節参照
最終更新日	2026-09-20（新規作成。同日、Phase 5B-1：Verify型のPilotとして、読む順路・第3.3節「PASSで分かること・分からないこと」・第4節の判断項目・第5.4節「テストの検出力を確かめる」（run_mutation_check.js、新規）・第7節の確かめたこと・確かめていないこと・第8.3節「AIにテスト生成を任せるときの注意」を追加し、実行結果を再実行の実測に置き換えた。確認の範囲・完了条件・既存3スクリプトは不変）

この記事の会社・人物・データはすべて架空の設定です。実在する会社や案件とは関係ありません。本文のコードは examples/09-03-risk-tests/ の正本と同じもので、実行結果は2026-09-20にローカル環境で実際に実行して記録したものです（第6〜7節、実行記録は第9節）。この記事の「同時に起きる場合」の確認は、実際の同時アクセスを再現したものではなく、保存先の状態条件を順番に呼び出して確かめた独立した小さなテストです（第5節）。想定利用量は教材上の仮定であり、実際の利用量ではありません（第8.2節）。

この記事は何の話か。同じ承認操作が二重に届く場合と、承認者の承認と依頼者の再提出が入れ違う場合について、保存先の状態条件で防げるかどうかを確認し、その確認が何を証明していて何を証明していないかを書き分け、実行できない項目は未検証と明記する話です。

なぜ必要か。09-02までの確認は、1件の操作を1回だけ行う場面が中心でした。実際の業務では、操作が重複して届いたり、複数の操作が入れ違ったりする場面があり、それに対する振る舞いを確かめておく必要があります。同時に、「テストが全部通った」は「安全だ」と同じではありません。通ったテストが何を見ていて、何を見逃すかを知らないと、確認していないことを確認済みとして次の工程に渡してしまいます。

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

• 許可されない操作、重複、途中失敗、同時更新、想定利用量に対する振る舞いを確かめる目的を説明できる
• 重複・入れ違いの場面について期待する結果を定めて確認し、「PASSで分かること・分からないこと」を分けてリスク別の検証結果に記録できる
• テストの検出力（壊れたときに本当に失敗するか）を確かめ、確認する範囲を失敗の影響と確認費用から判断して、確かめない項目とその理由を書ける

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

• 基本だけ理解する：第1節→第3節（4つのリスクと、PASSで分かること・分からないこと）→第4節（判断すること）→第6節の表（リスク別の検証結果）→第7節の「確かめていないこと」→第9節。コードを読まなくても、何を確かめ、何を確かめていないかが分かります。
• 作って確かめる：上に加えて第5.1〜5.3節（重複・入れ違い・繰り返しのコード）→第5.4節（テストの検出力を確かめる）→第6節の実行結果→第7節。
• 設計判断を深める：上に加えて第8節（状態条件で防げること・防げないこと、確認する範囲の判断、AIにテスト生成を任せるときの注意）。

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

この記事でやることは、同じ承認操作が二重に届く場合と、承認者の承認と依頼者の再提出が入れ違う場合について、期待する結果を定めて実行できる範囲で確認し、リスク別の検証結果に記録することです。あわせて、想定利用量に対する小規模な繰り返し確認と、テストの検出力の確認も行います。

09-02（SAMPLE-B）では、正常・無権限・自己承認・対象外状態・重複依頼の5系統を確認しましたが、複数の操作が入れ違う場面はまだ扱っていませんでした。記事Bの確かめていないことの表には「2人の承認者が同時に操作したとき」が「09-03で」と書かれています。この記事はその項目を引き受けますが、本格的な同時操作の再現ではなく、保存先の状態条件が働くことの確認までを行います。

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

• 重複・入れ違い確認、小規模な繰り返し確認、検出力確認のコード（examples/09-03-risk-tests/）
• リスク別の検証結果（リスク、場面、期待結果、確認方法、結果、実行済み／未検証、関連要件ID）

2. 前提知識と読む順路

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

重複

一言でいうと、同じ操作の指示が2回以上届くことです。たとえば、画面の二重クリックや、通信の再送によって、同じ承認操作が2回届く場合があります。

同時更新

一言でいうと、複数の操作がほぼ同時に、同じ対象に対して行われることです。たとえば、承認者が承認する操作と、依頼者が再提出する操作が入れ違う場合です。

状態条件つきの更新

一言でいうと、「更新前の状態が期待どおりのときだけ更新する」という条件を付けた更新方法です。この記事では、実際の同時アクセスを再現する代わりに、この条件が正しく働くかを確認します。

これがないと、1回だけ操作した場合は正しく動いても、操作が重複したり入れ違ったりした場合に、意図しない状態になる可能性に気づけません。

テストの検出力

一言でいうと、実装が壊れたときに、テストが本当に失敗してくれるかどうかです。

たとえば、状態条件を削った実装に対して重複のテストを実行し、「想定外の結果」と判定されれば、そのテストには検出力があります。「期待どおり」と判定されてしまえば、そのテストは壊れていても通ってしまう、見た目だけのテストです。

これがないと、「テストが通った」が「実装が正しい」ことの証拠にならず、AIが書いたテストをAIが通す、という構図に気づけません（記事B）。

読む順路：業務の流れでの検証は09-02、状態遷移は05-02、権限は05-03、例外時の画面は04-04が該当します。この記事の検証結果は、09-04のレビュー、10-04の利用開始判定で使います。

3. 理解する：確認する4つのリスク

3.1 権限・重複・途中失敗・同時更新

3.2 よくある誤解

「同時操作の確認は、実際に複数のプログラムを同時に動かさないとできない」。本格的な同時アクセスの再現は準備の負荷が大きいため、この記事では保存先の状態条件（更新前の状態が期待どおりかどうか）を順番に呼び出して確認します。これは同時操作の再現ではなく、条件が正しく働くかどうかの確認です（設計書ADDENDUM §2と同じ考え方）。

「繰り返し実行できれば、負荷試験をしたことになる」。この記事で行う繰り返し確認は、架空データ50件をエラーなく処理できるかどうかの小規模な確認であり、本番相当の利用量・同時アクセス数に対する負荷試験ではありません（第6節・第8.2節）。

「テストが全部PASSしたら、正しいことが証明された」。テストは、書いた期待結果の範囲だけを確かめます。何を証明したかは、テストが何を見ているかで決まります（第3.3節）。

3.3 PASSで分かること・分からないこと

結論から言うと、この記事のテストがPASSして分かるのは「保存先の状態条件は、順番に呼ばれたときに働く」ことだけです。

みらい業務サービスの例で言うと、鈴木さんが承認ボタンを二度押しし、2つ目の操作が1つ目の直後に届いた場合、2つ目は更新されません。これは確かめます。しかし、2つの操作が本当に同じ瞬間に届き、両方が「まだ提出済みだ」と読んでから両方が書き込む、という場面は、この記事の方法では起きません。順番に呼んでいるからです。

この表の右の列が、第7節の「確かめていないこと」の元になります。テストを書くときは、左の「何を証明したいか」を先に決め、右の「分からないこと」を同じ重さで残します。

4. 判断すること

この検証で人が判断することは、次の5つです。

4.1 この記事で判断すること

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

• 実際の同時アクセスを再現したかのように書きません。保存先の状態条件の確認であることを明記します。
• 実際の本番利用量（利用者数、同時アクセス数など）を、確認済みの事実として書きません。架空の仮定として扱います。
• 期待結果を、実装の出力に合わせて書き換えません。
• 検出力を確かめた1通りの結果を、「このテストはどんな壊れ方も検知できる」に広げません。

4.3 AIに任せる範囲

テストコードの下書き、実行、結果の整理、失敗したときの原因の説明はAIに任せられます。しかし、何を証明したいか（第3.3節）、期待結果（第4.1節）、同時操作を再現するかどうかの判断、検出力の確認結果をどう読むかは人が決めます。AIに「テストを書いて通して」とだけ頼むと、通るテストは書けますが、何を証明したかは残りません（第8.3節）。

5. 作って確かめる：重複と入れ違いを確認する

5.1 重複した承認操作の確認

// examples/09-03-risk-tests/storage_guard.js（抜粋）
// 更新前の状態がexpectedStateと一致する場合だけ状態を変更し、更新できたかどうかを返す。
// 一致しない場合は更新せず { updated: false } を返す（保存先の条件チェックのみ。同時操作の再現ではない）。
function changeStateIfExpected(id, expectedState, nextState, actor, action) {
  const db = loadDb();
  const req = db.requests.find((r) => r.id === id);
  if (!req || req.state !== expectedState) {
    return { updated: false, currentState: req ? req.state : null };
  }
  req.state = nextState;
  db.history.push({ requestId: id, action, actor, at: new Date().toISOString() });
  saveDb(db);
  return { updated: true, currentState: nextState };
}

// examples/09-03-risk-tests/run_duplicate.js（抜粋）
console.log("=== 1回目の承認操作（先に届いた想定） ===");
const first = changeStateIfExpected("REQ-0004", "提出済み", "承認済み", "鈴木", "承認");
console.log("=== 2回目の承認操作（同じ操作が二重に届いた想定） ===");
const second = changeStateIfExpected("REQ-0004", "提出済み", "承認済み", "鈴木", "承認");

期待結果は、実装より先に記事AのAC-008（同じ承認を2回しても効果は1回分）から決めています。run_duplicate.js は末尾で first.updated && !second.updated を判定し、満たせば「期待どおり」、満たさなければ「想定外の結果」と表示します。この判定が第5.4節の検出力確認の対象です。

5.2 承認と再提出が入れ違う場合の確認

// examples/09-03-risk-tests/run_resubmit_guard.js（抜粋）
console.log("=== 承認者の承認が先に反映された想定 ===");
const approve = changeStateIfExpected("REQ-0005", "提出済み", "承認済み", "鈴木", "承認");
console.log("=== 依頼者が（承認と入れ違いで）再提出を試みた想定 ===");
const resubmit = changeStateIfExpected("REQ-0005", "提出済み", "提出済み", "佐藤", "再提出");

5.3 小規模な繰り返し確認（負荷試験ではない）

// examples/09-03-risk-tests/run_repeat_scale.js（抜粋）
const COUNT = 50; // 教材上の仮定：小規模な繰り返し確認用の件数（本番の想定利用量ではない）
const start = Date.now();
for (let i = 1; i <= COUNT; i++) {
  createRequest({ id: `REQ-BULK-${String(i).padStart(3, "0")}`, requester: "佐藤", approver: "鈴木" });
}
const elapsedMs = Date.now() - start;

5.4 テストの検出力を確かめる

第5.1節のテストが「状態条件が壊れたら本当に失敗するか」を確かめます。記事Bと同じ考え方で、正本の storage_guard.js をこのフォルダ直下の work-mutation/ にコピーし、状態条件の行をわざと削った版を作って、重複の場面を実行します。壊した版は正本に混ぜず、終了時に削除します。

// examples/09-03-risk-tests/run_mutation_check.js（抜粋）
const guardLine = "if (!req || req.state !== expectedState) {";
const mutated = original.replace(guardLine, "if (!req) { // 故意の誤変更：状態条件を削除（説明用）");
fs.writeFileSync(path.join(WORK, "storage_guard.js"), mutated);

const { createRequest, changeStateIfExpected, DB_FILE } = require(path.join(WORK, "storage_guard.js"));
createRequest({ id: "REQ-0004", requester: "佐藤", approver: "鈴木" });
const first = changeStateIfExpected("REQ-0004", "提出済み", "承認済み", "鈴木", "承認");
const second = changeStateIfExpected("REQ-0004", "提出済み", "承認済み", "鈴木", "承認");

const testPassed = first.updated && !second.updated; // run_duplicate.js と同じ判定

期待結果は「壊した版では testPassed が false になる（テストが失敗する）」です。もし壊した版でも true になれば、第5.1節のテストは状態条件の欠落を見逃す、見た目だけのテストだと分かります。

6. 実行結果（リスク別の検証結果）

examples/09-03-risk-tests/ で実行した stdout と終了コードです（整形・省略なし。stderr への出力はありませんでした。所要時間は実行のたびに変わります）。

$ node run_duplicate.js
=== 1回目の承認操作（先に届いた想定） ===
結果: {"updated":true,"currentState":"承認済み"}
=== 2回目の承認操作（同じ操作が二重に届いた想定） ===
結果: {"updated":false,"currentState":"承認済み"}

期待どおり：2回目は更新されなかった（重複を防止）
終了コード: 0

$ node run_resubmit_guard.js
=== 承認者の承認が先に反映された想定 ===
結果: {"updated":true,"currentState":"承認済み"}
=== 依頼者が（承認と入れ違いで）再提出を試みた想定 ===
結果: {"updated":false,"currentState":"承認済み"}

期待どおり：承認済みになった後の再提出は防止された
終了コード: 0

$ node run_repeat_scale.js
作成件数: 50件（想定: 50件）
所要時間: 6ms
この確認は小規模な繰り返しの動作確認であり、負荷試験ではない。
終了コード: 0

$ node run_mutation_check.js
=== 故意に状態条件を削った版に対して、同じ承認操作を2回届ける ===
1回目: {"updated":true,"currentState":"承認済み"}
2回目: {"updated":true,"currentState":"承認済み"}

検出できた：壊した版ではテストが「想定外の結果」と判定した（状態条件の欠落を見つけられる）
終了コード: 0

壊した版では2回目も updated: true になり、第5.1節の判定（first.updated && !second.updated）は false になりました。つまり、状態条件を削ると重複のテストは失敗します。このテストには、少なくとも「状態条件の欠落」に対する検出力があります。

7. 確認結果

実行環境：macOS 26.6.2、Node.js v24.18.0（node:fs、node:pathのみ使用）、2026-09-20に実行。教材演習用のローカルファイルのみを使い、実際の複数プロセス・複数利用者による同時アクセスは行っていません。stdout・stderr・終了コードをそのまま記録した実行記録は第9節の run_log.md にあります。

完了条件との照合：

この確認で確かめたこと：保存先の状態条件が、順番に呼ばれた重複・入れ違いの操作を拒否すること。架空データ50件の作成がエラーなく完了すること。状態条件を削ると重複のテストが失敗すること（検出力）。

この確認で確かめていないこと：

この4件が通ったことは、保存先の状態条件がこの4場面で期待どおりに働くことの証拠です。同時アクセスに対してアプリが安全であることの証拠ではありません。この記事の本文はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。

8. 設計を判断する

8.1 保存先の状態条件で防げること・防げないこと

保存先の状態条件は、多くの重複・入れ違いを防ぐ効果がありますが、本格的な同時アクセスの安全性を保証するものではありません。「読んでから書く」の間に別の操作が割り込む隙を塞ぐには、保存先側の排他制御（記事Bの「保存先」の行）が要ります。

8.2 確認する範囲を、失敗の影響と確認費用から判断する

想定利用量は教材上の仮定であり、実際の業務における利用者数・同時アクセス数は、この記事の時点では確認していません。

8.3 AIにテスト生成を任せるときの注意

AIにテストを書かせるのは有効ですが、次の3点は人が持ちます。

AIの「全件PASSしました」は、AIが書いた範囲のテストが通ったという意味です。何を証明したかと、何を証明していないかは、テストの数からは分かりません。

8.4 適用限界

この記事の確認は、教材演習用のローカルファイルを保存先にした小さな例に対するものです。実際のデータベースを使う実装、複数の利用者が同時に使う環境では、確認の方法（排他制御、負荷試験）も結果も変わります。

9. 持ち帰る成果物

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

1. 権限・重複・途中失敗・同時更新の4系統について、何を証明したいかと期待する結果を決める（第3.3節・第4.1節）
2. 実行できる範囲（保存先の状態条件など）で確認し、結果を記録する
3. 最も重要な条件を1つ削って、テストが失敗することを確かめる（第5.4節）
4. 実行できない項目は未検証と書き、理由と今後の確認方法を添える
5. 想定利用量を架空の仮定として明記し、確認する範囲を判断する

10. 次工程への受渡し

次へ渡すもの：リスク別の検証結果（実行済み6件、未検証5件の表）。

次工程での使われ方：09-04（第三者の視点でレビューする）では、この検証結果をレビュー観点の1つとして使います。10-04（利用開始の可否を判断する）では、この検証結果を判定材料の1つとして使い、「本格的な同時アクセス・負荷が未検証」は実業務導入前に確認する未解決問題として扱われています。

前工程へ戻る条件：この検証結果が05-02・05-03の設計と食い違う場合は、それぞれの記事に戻って確認します。検出力の確認でテストが壊れた版でも通ってしまった場合は、テストの期待結果を記事Aの受入条件と照合し直します。

11. 根拠と更新情報

• この記事の会社・人物・データはすべて架空の設定です。
• 「同時操作の本格的な検証・実装は行わない」「保存先の状態条件を、独立した小さなテストで確認する」という考え方は、教材設計書PHASE1_REVISION_ADDENDUM.md第2節に基づきます。
• テストの検出力を故意の誤変更で確かめる方法は、記事Bの mutation_check.py と同じ考え方です。この記事では壊し方を1通りに絞っています。
• 権限の確認結果は09-01・09-02、途中失敗の確認結果は08-04を引用しています。
• 制作の来歴：本文はClaude Codeが作成しました。第5〜6節のコードは examples/09-03-risk-tests/ を正本とし、2026-09-20にmacOS 26.6.2・Node.js v24.18.0の環境で実際に実行して、stdout・stderr・終了コードを evidence_public/phase5b1-2026-09-20/09-03/run_log.md に記録しています。人（ユーザー）による実読・内容確認は未実施です。
• 2026-09-20（Phase 5B-1）：Verify型のPilotとして、読む順路（3つの深さ）、第2節「テストの検出力」の用語説明、第3.3節「PASSで分かること・分からないこと」、第4節の判断項目、第5.4節「テストの検出力を確かめる」（run_mutation_check.js、新規）、第7節の確かめたこと・確かめていないことの表、第8.3節「AIにテスト生成を任せるときの注意」、記事間の参照を追加し、第6節の実行結果を再実行の実測に置き換えた（所要時間は5msから6msに変わった。環境依存の値であり、性能の指標ではない）。既存の3スクリプト・確認の範囲・完了条件は変えていない。
• 未確認事項：実際の複数プロセス・複数利用者による同時アクセス、本番相当の利用量に対する負荷試験、状態条件以外の壊れ方に対する検出力は、この記事の時点では確認していません（第7節）。