このユニットの結論
システムどうしの連携では、同じデータが2回届くことは「起きてはいけないこと」ではなく、「いつか必ず起きること」として設計します。
同じ処理を2回受け取っても、結果が1回分と同じになるようにしておく（この性質を「冪等性（べきとうせい）」と呼びます）ことで、送り直し（再送）を安全に行えるようになります。
1. 何の話か
このユニットは、連携の二重処理を防ぐ設計の話です。
07-04 相手システムが止まっていたらどうするか では、相手が止まっていたときに、送り直すと二重処理になるおそれがあることを学びました。このユニットでは、二重に届いても困らない仕組みを、どう作るかを考えます。
2. なぜ必要か
二重に届くことを考えずに作ると、
- 同じ工数が2回登録され、案件ごとの時間の合計が実際より多くなる
- 同じ通知が2回送られ、利用者や取引先が混乱する
- 障害のあと、どこまで届いたか分からず、送り直すのが怖くなって復旧が遅れる
- 二重になったデータを、あとから1件ずつ探して消すことになる
ということが起きます。
3. このユニットで分かること
- 同じ処理が2回届く理由
- 二重に届いても大丈夫にする方法
- 設計とテストで確かめること
- 二重処理への備えで、AIに任せてよいことと人間が決めること
4. 同じ処理が2回届く理由
一般的に、次のようなときに起きます。
- 応答が返ってこなかった：相手は受け取って処理したのに、「受け取った」という返事が届かず、送った側が失敗と考えて送り直す
- 障害のあとの送り直し：どこまで届いたかが分からないまま、まとめて送り直す
- 人の操作：利用者がボタンを2回押す、担当者が手で処理をやり直す
- 仕組みの動き：連携の仕組みが、確実に届けるために同じものを2回以上届けることがある
このうちいくつかは、どんなに注意しても完全には防げません。そのため、受け取る側で、2回来ても困らないようにすることが大切です。
5. 二重に届いても大丈夫にする方法
| 方法 | 考え方 | 例（教材上の例） |
|---|---|---|
| 一意の番号を付ける | 送るデータごとに重ならない番号を付け、受け取る側で「すでに処理した番号か」を確かめる | 工数の連携で、1件ごとに送り元の番号を付け、同じ番号は2回目を処理しない |
| 「足す」ではなく「置き換える」 | 「10を足す」ではなく「合計を10にする」のように、何回処理しても結果が同じになる形で送る | 数量の変化ではなく、最新の数量を送る |
| 処理済みの記録を残す | どこまで処理したかを記録し、送り直しはその続きから行う | 処理した最後の番号を記録する |
「置き換える」方法では、古い送り直しが新しいデータの後に届くと、新しい値を古い値で上書きしてしまいます。送った順番や、データの更新の時刻・番号も確かめるようにします。
どの方法を使うかは、連携ごとに、データの性質と、相手のシステムの作りに合わせて決めます。連携の一覧（ARC-004）に、連携ごとの方法を書いておきます。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- 約36本のシステム連携。正本で経路が定義されているのは IF-01〜IF-12
- SYS-06 システム連携基盤。IF-04 工数連携：勤怠・工数SaaS → 連携基盤 → 新基幹
- Vendor B / クラウドブリッジの担当範囲に連携が含まれる
アステリア案件の各連携が、二重処理をどう防ぐかは、正本に記載がありません。未確定 上の工数の例は教材上の例で、IF-04 の設計ではありません。
6. THINK — 「うちは送る側で気をつけるから大丈夫」
（教材上の例）連携の設計の打ち合わせで、送る側のシステムの担当者が次のように言いました。
「送る側で、同じデータを2回送らないようにしっかり作ります。だから、受け取る側で二重を確かめる仕組みは要りません。」
問題
この考えで、受け取る側の仕組みを省いてよいでしょうか。
判断例を開く
判断
省くべきではありません。
確認すること:
- 応答が返ってこなかったとき、送る側は「送れたか」を確実に知ることができるか
- 障害のあと、送り直しの範囲を、送る側だけで正しく決められるか
- 間に連携の仕組みがある場合、その仕組みが同じものを2回届けることはないか
- 担当者が手で処理をやり直すことはないか
送る側の注意は大切ですが、それだけでは防ぎきれない場面があります。受け取る側でも、2回来たときに困らないようにしておきます。
7. 設計とテストで確かめること
- 連携ごとに、二重に届いたときの方法を決めているか
- テストで、実際に同じデータを2回送り、結果が1回分と同じになるかを確かめたか（TST-002）
- 障害のあとの送り直しの手順を、決めてあるか
- 二重になりかけたこと（2回目を処理しなかったこと）を、記録に残して気づけるか
8. よくある失敗
- 送る側の注意だけに頼る
- 「足す」形のデータを送り、2回処理されると合計が変わる
- 正常の場合だけをテストし、同じデータを2回送るテストをしない
- 送り直しのとき、どこまで処理したかが分からない
9. 成果物との接続
- ARC-004 システム連携一覧：連携ごとに、二重に届いたときの方法を書く
- ARC-005 システム連携処理図：連携の流れと、処理済みの確かめ方を図で示す
- TST-002 テスト計画・対象一覧：二重に届いたときのテストを、対象に入れる
10. AI WORKFLOW — 二重処理のおそれを洗い出させる
AIは、連携の一覧から、二重処理のおそれがある箇所を探す下書きに役立ちます。
指示例:
「次の連携の一覧について、連携ごとに、①同じデータが2回届く可能性がある場面、②2回処理されたときに困ること、③決められている二重処理の防ぎ方（記載がなければ『記載なし』）、を表にしてください。防ぎ方を決めないでください。」
11. REVIEW — AIの洗い出しを確認する
- 表が、連携の一覧の元の内容と合っているか
- AIが、防ぎ方を推測で書いていないか
- 「記載なし」の連携について、担当に確かめたか
ADVANCED深掘り — 実務者向けに一段深く
深掘り — 冪等キーと、重複判定の保持期間
1 回の業務処理に 1 つの番号
送り手は、1 回の業務処理（たとえば 1 件の請求の確定）に、二度と重ならない番号を付けて送ります。受け手は、同じ番号を 2 回受け取ったら、処理せずに「済み」の結果を返します。この番号を冪等キーと呼びます。番号は通信の単位ではなく、業務の単位で付けます。通信の単位で付けると、再送のたびに新しい番号になり、意味がなくなります。
「済み」をどれだけ覚えておくか
受け手は「この番号は処理した」という記録を保持します。保持が短いと、古い再送を新しい処理として二重に行います。長いと記録が増え続けます。保持期間は、再送が起こりうる最大の遅れ（夜間処理のやり直し、相手の復旧までの時間）から決めます。
配信の保証の現実
世界で共有されている考え方では、「少なくとも 1 回は届く」設計が普通で、「ちょうど 1 回だけ届く」ことを通信だけで保証するのは難しいとされています。だから「ちょうど 1 回だけ処理する」は、受け手の冪等性で実現します。
記録と処理の順序
「処理してから済みの記録を残す」と、処理の直後に止まったとき、記録がなく二重処理になります。「記録を残してから処理する」と、処理の前に止まったとき、記録はあるのに処理されていない状態になります。どちらが安全かは業務によります。途中で止まったときの状態を書き出して、設計で決めます。
現場で確かめる問い
- 冪等キーは業務の単位で付けられているか。通信の単位になっていないか
- 「済み」の記録の保持期間は、再送が起こりうる最大の遅れから決めたか
- 連携の相手が再送してきたとき、受け手が何を返すかを、相手と文書で合わせたか
- 途中で止まったときの状態（記録あり処理なし、処理あり記録なし）を、どちらが安全か決めたか
アステリア案件で冪等キーをどう設計したかは、正本に記録がありません。記録なし
12. 人間が判断すること
- 連携ごとに、どの方法で二重処理を防ぐか
- 送り直しの手順と、送り直しを判断する人
- 二重になったデータが見つかったときの直し方
13. 判断演習
あなたは、工数の連携の設計を確かめる担当です。
「同じ工数のデータが2回届いたとき、結果が1回分と同じになるか」を確かめるテストを、1つ考えてください。何を送り、何を確かめるかを書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
同じデータが2回届くことは、いつか必ず起きることとして設計します。
受け取る側で、2回来ても結果が変わらないようにしておけば、送り直しを安全に行えます。