このユニットの結論
連携のテストを「相手がそろってから」にすると、問題は最後にまとめて出ます。
連携でやりとりする約束（項目・形・異常のときの振る舞い）をテストの形で書き、送り手と受け手がそれぞれ自分の側を、相手がいなくても自動で確かめる。これが契約テストです。約束を文章ではなくテストにすると、読み違いが機械的に見つかります。
1. 何の話か
このユニットは、システム同士の連携を、相手を待たずに確かめる方法の話です。
07-06 36本を一覧で管理する で、連携の数が多く、両端を別の会社が担当することを学びました。両端がそろうのを待っていると、テストは最後の数週間に集中します。そこで、連携の「約束」を先にテストにしておく考え方が使われます。世界で共有されている考え方では「契約テスト（コントラクトテスト）」と呼びます。
2. なぜ必要か
約束をテストにしないと、
- 送り手と受け手が別々の仕様書を読み、項目の意味を違って実装していることに、つなげて初めて気づく
- 異常のとき（相手が止まった、同じものが 2 回届いた）の振る舞いが両側で違い、本番で初めて食い違う
- 送り手が形を少し変えたとき、受け手が壊れることを事前に検知できない
ということが起きます。約36本の連携でこれが同時に起きると、原因の切り分けだけで数週間かかります。
3. このユニットで分かること
- 「約束」に何を書くか
- 送り手側と受け手側のテストが何を確かめるか
- 正常だけでなく異常の約束が要る理由
4. 約束に書くこと
| 書くこと | 内容 | 例（一般的な例） |
|---|---|---|
| 項目 | 名前、型、必須か任意か、取りうる値 | 社員番号は 8 桁の文字列で必須。人事マスターに存在する番号のみ |
| 形 | 1 回のやりとりに何件まで、順序の決まり、識別子 | 1 回に最大 1,000 件。受け渡しごとに一意の識別子を付ける |
| 正常の例 | 代表的なやりとりを、実際の値で | 社員 A の 10 月 1 日の工数 7.5 時間 |
| 異常の例 | 必須の欠落、型の違い、範囲外、二重、無応答。それぞれの両側の振る舞い | 同じ識別子が 2 回届いたら、受け手は処理せず「受け取り済み」を返す |
約束の定義は 1 か所に置き、両側のテストがそこから作られるようにします。別々に書くと、必ずずれます。約束の定義そのものは TST-007 契約テスト仕様 にまとめ、どの連携が対象かは ARC-004 システム連携一覧 と対応させます。
5. 両側のテストが確かめること
送り手側のテストは、「自分が送り出すものが約束の形になっているか」を確かめます。相手のシステムは要りません。約束の定義と比べるだけです。
受け手側のテストは、「約束の形で来たものを受け取れるか」と「異常の例のとおりに振る舞うか」を確かめます。相手のシステムの代わりに、約束の定義から作った模擬の送り手を使います。
どちらか一方だけでは「約束」になりません。両側がそろって初めて、「相手がそろわなくても、つないだときに動く」と言えます。約束を変えるときは、版の管理（07-08 APIの版をどう管理するか）に従い、両側のテストを先に直します。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の連携に関する記載
- 約36本のシステム連携。正本で個別に定義された連携は IF-01〜IF-12
- 両端を別の会社が担当する組み合わせがある：Vendor A ネクサスシステムズ（新基幹アプリケーション）、Vendor B クラウドブリッジ（連携 など）、Vendor C ファイナンスシステムサービス（FIN-CORE、会計連携）、Vendor D タイムリンク（勤怠・工数管理SaaS）
- 成果物に TST-007 契約テスト仕様、ARC-004 システム連携一覧 がある
- P-010 宮田 直人 — テスト・品質管理リーダー
アステリア案件で契約テストが行われたか、どの連携に適用されたか、約束がどう定義されたかは、正本に記録がありません。記録なし
6. THINK — 「仕様書を共有しているから大丈夫」
連携の進め方の会議で、ある会社の担当者が次のように言いました。
「連携の仕様書は両社で共有しています。それぞれ仕様書どおりに作れば、つなげたときに動くはずです。」
問題
この進め方で、つなげたときに動くと言えるでしょうか。
判断例を開く
判断
仕様書は人が読むものです。同じ文を違う意味に読むことは、必ず起きます。
確認すること:
- 仕様書の項目に、型・必須・取りうる値が書かれているか（「日付」だけでは形が決まらない）
- 異常のとき（欠落、範囲外、二重、無応答）の振る舞いが、両側で同じに書かれているか
- 送り手が「仕様書どおりに送っている」ことを、何で確かめているか（自分で読んで確認、は確かめたことにならない）
- 受け手が「仕様書どおりに来たら受け取れる」ことを、相手なしで確かめているか
- 仕様書が変わったとき、両側のどちらが先に気づくか
「仕様書どおり」を機械的に確かめる仕組みが契約テストです。仕様書の共有は、その出発点にすぎません。
7. よくある失敗
- 連携のテストをつなげたテストの段階まで行わず、約36本分の問題が最後に集中する
- 正常の例だけをテストし、異常のときの食い違いが本番で初めて分かる
- 約束の定義を両側が別々に持ち、片方だけ直してずれる
- 送り手だけ、または受け手だけがテストを書き、「約束」になっていない
8. 成果物との接続
- TST-007 契約テスト仕様：連携ごとの約束（項目・形・正常と異常の例）と、両側のテスト
- ARC-004 システム連携一覧：どの連携が契約テストの対象で、両端を誰が担当するか
9. AI WORKFLOW — 異常の例の候補を網羅させる
AIは、約束の項目表から、起こりうる異常（欠落、型の違い、範囲外、二重、無応答、順序の入れ替わり）を網羅的に挙げる下書きに役立ちます。
指示例:
「次の約束の項目表から、項目ごとと連携全体で起こりうる異常を一覧にしてください。それぞれの『期待する振る舞い』は空欄のまま示し、提案しないでください。」
10. REVIEW — AIの一覧を確認する
- AIが挙げた異常が、項目の型や範囲から正しく導かれているか
- 空欄の「期待する振る舞い」を、送り手と受け手の両方の担当者で決めたか
- 項目表を AI に渡してよいか（相手の会社との守秘の扱い）を事前に確かめたか
11. 人間が判断すること
- 異常のときに、送り手と受け手がそれぞれどう振る舞うか
- 約束の定義をどこに置き、誰が変更を承認するか
- 契約テストをどの連携から始めるか
12. 判断演習
「人事の社員情報を、新しいシステムが毎晩受け取る」連携を考えてください。
約束に書く項目を 4 つ以上挙げ（型・必須・取りうる値つき）、異常の例を 3 つ挙げて、それぞれ「受け手はどうするか」「送り手はどうするか」を書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
約束はテストにする。項目・形・正常と異常の例を 1 か所に定義し、送り手と受け手がそれぞれ相手なしで自動で確かめる。仕様書の共有は出発点であって、確かめたことにはならない。