これは何か
契約テスト仕様は、連携でやりとりする内容の約束（項目、形、順序、誤りのときの振る舞い）を、送り手と受け手の両方が自動で確かめられるように、テストの形で書いた成果物です。
連携のテストは、相手のシステムがそろうまで待っていると、いつまでも始められません（07-06 36本を一覧で管理する）。契約テストは、約束を「テストできる形」にして、相手がいなくても自分の側を確かめる考え方です。世界で共有されている考え方では「契約テスト（コントラクトテスト）」と呼ばれます。
なぜ作るか
- 相手のシステムの完成を待たずに、自分の側の連携を確かめる
- 約束を文章ではなくテストにすることで、「読み違い」を機械的に見つける
- 送り手が形を変えたとき、受け手の契約テストが失敗して、壊れる前に気づく（ARC-009 API互換性・版管理方針）
- つなげたテスト（10-02 小さい単位から全体へテストする）の前に、連携の形の問題を片づけておく
誰が使うか・いつ作るか
- 作る人：連携ごとに、送り手と受け手の両方の開発者。連携の基盤を担当する会社が形式をそろえる
- 使う人：両側の開発者、テストの担当、連携の仕様を変える人
- 一般的には、連携の仕様が決まった直後に作り、自動の流れ（DEV-003 自動テスト・自動配布構成）で毎回動かします
- アステリア案件で契約テストが行われたか、どの連携に適用されたかは、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
連携とテストに関係する記載
- 約36本のシステム連携。正本で個別に定義された連携は IF-01〜IF-12（例: IF-03 社員・組織マスター連携 人事 → 新基幹、IF-04 工数連携 勤怠・工数SaaS → 連携基盤 → 新基幹）
- 連携の両端を別の会社が担当する組み合わせがある（例: Vendor A 新基幹アプリケーション と Vendor C FIN-CORE、会計連携）
- 成果物に TST-001 テスト戦略書、TST-002 テスト計画・対象一覧 がある
- P-010 宮田 直人 — テスト・品質管理リーダー
各連携の項目・形・誤りの扱いと、それをどうテストしたかは、正本に記載がありません。未確定
主な項目
一般的には、連携 1 本ごとに次の項目を持ちます。
- 連携の識別：連携 ID、送り手、受け手、担当する会社
- 約束の内容：やりとりする項目（名前、型、必須か任意か、取りうる値）、順序や件数の決まり、時刻や識別子の形
- 正常の例：代表的な正常のやりとりを、実際の値つきで数例
- 異常の例：必須の項目がない、型が違う、値が範囲外、相手が応答しない、同じものが 2 回届く。それぞれのときに期待する振る舞い
- 送り手側のテスト：送り手が、約束の形で送り出していることを確かめるテスト
- 受け手側のテスト：受け手が、約束の形を受け取れ、異常を期待どおり扱えることを確かめるテスト
- 約束の置き場所と版：約束の定義を 1 か所に置き、両側のテストが同じ定義を参照する。版の付け方は API互換性・版管理方針に従う
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 約束の項目と、異常のときの期待
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、工数を受け渡す連携を題材にした、仕様の書き方の例です。項目名・値・期待する振る舞いは教材上の架空の例で、アステリア案件の記録ではありません。
| 項目（教材上の例） | 型 | 必須 | 取りうる値 | 備考 |
|---|---|---|---|---|
| 社員番号 | 文字列 8 桁 | 必須 | 人事マスターに存在する番号 | 存在しない番号は異常 |
| 案件番号 | 文字列 10 桁 | 必須 | 新基幹に存在する番号 | 終了した案件は異常 |
| 作業日 | 日付 | 必須 | 当月と前月のみ | それ以外は異常 |
| 工数 | 数値 | 必須 | 0.25 以上 24 以下、0.25 刻み | 範囲外は異常 |
| 受け渡し識別子 | 文字列 | 必須 | 1 回の受け渡しに一意 | 同じ識別子は二重と判定 |
| 異常（教材上の例） | 受け手の期待する振る舞い | 送り手の期待する振る舞い |
|---|---|---|
| 必須の項目がない | 受け取らず、どの項目が足りないかを返す | 返された内容を記録し、再送しない |
| 工数が範囲外 | その 1 件だけ受け取らず、ほかの件は受け取る | 受け取られなかった件を担当者に知らせる |
| 同じ識別子が 2 回届く | 2 回目は処理せず「受け取り済み」を返す | 「受け取り済み」を成功として扱う |
| 受け手が応答しない | ― | 決めた回数まで間隔を置いて再送し、それでも駄目なら止めて知らせる |
読み方
- 約束の項目に、型・必須・取りうる値がそろっているか
- 異常の例に、「受け手がどうするか」と「送り手がどうするか」の両方が書かれているか
- 送り手側と受け手側のテストが、同じ約束の定義を参照しているか（別々に書くとずれる）
- 同じものが 2 回届いたときの扱いが書かれているか（07-05 同じ処理が2回来ても大丈夫にする）
- 約束を変えるときの版の扱いが、API互換性・版管理方針と合っているか
書き方
- 連携の一覧から対象を選び、送り手と受け手の担当者をそろえる
- 約束の項目を表にし、両側で読み合わせる
- 正常の例と異常の例を、実際の値で書く
- 約束の定義を 1 か所に置き、両側のテストをそこから作る
- 自動の流れに組み込み、どちらかの側が変わるたびに動くようにする
何を書いてはいけないか
- 「仕様書どおりに送る」のような、テストにできない約束
- 正常の例だけ（異常の扱いの食い違いが、本番で初めて分かる）
- 送り手だけ、または受け手だけのテスト（片側だけでは「約束」にならない）
- 実在の製品名を、案件の正式な採用として書くこと（正本に記載がない）
どこを見るか
- 約束の項目の網羅（型・必須・値）
- 異常の例と、両側の期待する振る舞い
- 約束の定義の置き場所（1 か所か）
- 二重に届いたときの扱い
- 自動の流れへの組み込み
赤信号
- 連携のテストが「相手がそろってから」になっていて、一度も自動で動いていない
- 送り手と受け手が別々の仕様書を見ていて、項目の意味が違う
- 異常の扱いが決まっておらず、本番で初めて「相手が止まったらどうするか」を議論している
- 送り手が形を変えても、受け手側のテストが失敗しない（契約が形だけになっている）
よくある失敗
- つなげたテストの段階まで連携を確かめず、約36本分の問題が一度に出て、原因の切り分けに時間がかかる
- 約束を文章の仕様書だけに頼り、読み違いが実装まで残る
- 異常の例を省き、「相手が止まったとき」「二重に届いたとき」の振る舞いが両側で違う
関係するUnit・成果物・危機演習
- Unit：07-07 連携の約束をどうテストするか、07-06 36本を一覧で管理する、10-02 小さい単位から全体へテストする、07-05 同じ処理が2回来ても大丈夫にする
- 成果物：ARC-004 システム連携一覧、ARC-009 API互換性・版管理方針、TST-001 テスト戦略書、DEV-003 自動テスト・自動配布構成
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、約束の項目表から、異常の例の候補（必須の欠落、型の違い、範囲外、二重、無応答）を網羅的に挙げる下書きに役立ちます。
「次の約束の項目表から、項目ごとに起こりうる異常（必須の欠落、型の違い、取りうる値の範囲外）を一覧にし、連携全体で起こりうる異常（二重の受け渡し、相手の無応答、順序の入れ替わり）も挙げてください。それぞれの『期待する振る舞い』は空欄のまま示し、提案しないでください。」
REVIEW
- AIが挙げた異常が、項目表の型や範囲から正しく導かれているか
- 空欄の「期待する振る舞い」を、送り手と受け手の両方の担当者で決めたか
- 項目表を AI に渡してよいか（相手の会社との守秘の扱い）を事前に確かめたか
人間が判断すること
- 異常のときに、受け手と送り手がそれぞれどう振る舞うか
- 約束の定義をどこに置き、誰が変更を承認するか
- 契約テストをどの連携から始めるか（約36本すべてに一度に入れるか）
いつ使うか
この教材では STAGE 07｜36本のシステム連携を管理する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この仕様を読んだ送り手と受け手の開発者は、「相手のシステムが動いていなくても、自分の側が約束どおりかを自動で確かめられる」状態を、どう作ればよいか説明できますか？