インターフェース要件

インターフェース要件は境界の両側が共同動作できる条件であり、API の URL 一覧ではない

まずインターフェースを棚卸しし、各境界に必要な深さを決める

案件の境界はバックエンドAPIだけでなく、ファイル、メッセージ、認証、人的引継ぎ、運用経路も含みます。送信者、受信者、業務対象、責任者を並べると、今期に作る境界、顧客や第三者への依存、両側で評価すべき変更が見えます。

1. 両側に名称と責任者があるか

   「顧客システムと連携」だけにせず、システム、サービス、組織、役割、現責任者を特定する。

   確認：システム文脈図、インターフェース台帳、責任表。

2. 全運用モードを確認したか

   通常、ピーク、保守、縮退、切断、復旧、移行、廃止で異なる経路を使うことがある。

   確認：運用概念、例外シナリオ、廃止計画。

3. 暗黙のインターフェースを発見したか

   手作業転記、共有アカウント、暫定表計算、メール添付、運用スクリプトが正式設計にない実依存になりやすい。

   確認：現場観察、ログ、実手順、支援履歴。

完全なインターフェース契約が共同で定める次元

項目名が一致しても、データを解析できることしか証明しません。共同動作には業務意味、識別、時系列、エラー、復旧の理解も必要です。契約は提供側の技術説明ではなく、境界両側の責任合意です。

検証可能なインターフェース要件の記録項目

「ERPと連携する」だけでは見積りも受入もできません。どの事象で誰がどの版の対象を送り、受領をどう確認し、障害や時間切れ後に両側がどの状態を保つかを記します。契約、データ、責任のどこが失敗したかを特定できます。

システム境界と実相互作用からインターフェース要件を発見する

既存文書は理想的な呼出しだけを示し、実運用には手入力、夜間ファイル、再送、旧版互換が残ることがあります。業務対象の全期間を追い、ログ、障害、両側の作業を照合し、文書外で責任を担う相互作用を見つけます。

1. システム文脈と責任境界を描く

   業務シナリオ、運用概念、システム境界から、外部主体、独立変更される内部要素、人を列挙する。現 API 一覧が全相互作用を含むと仮定しない。

2. 情報、制御、状態を端から端まで追う

   正常・例外経路で、入力の発生、権威事実になる場所、消費者、確認者、終了時に残る記録を追跡する。

3. 現行システムと実制約を確認する

   供給者仕様、スキーマ、速度制限、ネットワーク、本人確認、許諾、保守時間、支援約束を読み、可能なら sandbox で文書と実挙動を比較する。

4. 両側を別々に聞き取る

   業務、開発、セキュリティ、データ、運用、供給者に項目、状態、障害、責任を説明してもらい、同名異義、既定仮定、未決事項を明示する。

5. 業務意味と障害モデルを確立する

   伝送方法を選ぶ前に対象、識別子、状態、単位、時刻、成功を統一し、無効、無権限、欠落、衝突、重複、遅延、停止を列挙する。

6. 共有責任を失わず配分する

   提供側の保証、利用側の使い方、基盤・ネットワークの責任を分け、外部依存を自社だけで保証できる結果として書かない。

7. 例と反例を双方で通す

   正常、境界、例外、旧版の同じ事例を双方が解釈する。例は曖昧さを発見するが、承認ルールとスキーマが規範である。

8. 双方基準と変更過程を承認する

   実装前に版、責任者、未決値、検証環境、判断記録を承認し、その後のどちら側の変更も影響分析する。

再試行、重複、順序逆転、部分失敗を境界上で明示する

通信の時間切れは送信側が回答を得なかっただけで、受信側が未実行とは限りません。無条件の再試行は注文、支払、通知を重複させます。要求ID、再試行条件、最終状態照会、補償責任を両側で定めます。

インターフェースのセキュリティ要件は信頼境界と業務影響から作る

認証は資格情報の有効性を示すだけで、この顧客の閲覧、この対象の変更、項目の一括出力まで許可しません。資格情報から業務対象と動作へ進み、最小権限、機密データ、監査、取消し、漏えい時の実影響を扱います。

1. 各経路で相手を確認できるか

   利用者、サービス、機器、組織の本人性の確立、結合、伝達、検証、取消を定め、内部ネットワークを本人性とみなさない。

   確認：本人性の流れ、資格情報ライフサイクル、サービス間認証試験。

2. 認可が業務対象と一致するか

   主体がどのテナント、対象、項目、操作を扱えるかを定め、下流が上流の役割文字列だけを信用しない。

   確認：資源別、操作別、テナント横断の否定試験。

3. 必要データだけを交換するか

   項目ごとに目的、機微性、マスキング、暗号化、地域、キャッシュ、ログ、保存、削除を確認する。デバッグ利便は自動的な目的にならない。

   確認：データ流、辞書、プライバシー、ログ審査。

4. 入出力を不信入力として扱うか

   大きさ、型、構造、頻度、実行可能内容を制限し、署名と出所を検証し、注入、解析差、悪性ファイル、資源枯渇に備える。

   確認：スキーマ検証、ファジング、速度制限、内容安全試験。

5. 鍵とトークンを更新・失効できるか

   発行者、対象、範囲、期限、保管、ローテーション、取消、漏えい対応、時計ずれを定め、通常ログやエラーへ返さない。

   確認：資格情報台帳、更新演習、取消試験。

6. 関連付けと露出抑制を両立するか

   双方が相関 ID、保護ログ、共通時刻で問題を追う。公開応答は消費者に必要な安定情報に留め、詳細診断は保護経路に置く。

   確認：正常・攻撃場面の応答、ログ、警報。

調達申請サービスと ERP のインターフェース要件構成例

以下の顧客と無関係な調達サービスとERPの連携で、対象識別、版、確認、障害復旧を両側が合意する形を示します。名称、項目、時間は仮置きです。送信成功、業務受理、最終保存を同じ結果とみなさないことが要点です。

インターフェースを共同検証し、稼働後も統治する

片側の模擬試験では、二つの本番システムが共同動作できることを証明しません。同じ契約と代表データで正常、例外、復旧を試し、公開時の版、容量、復帰を調整し、境界を越えた障害を追える相関情報を残します。

1. 静的一貫性を審査する

   双方が名称、意味、方向、単位、時刻帯、スキーマ、状態、エラー、本人性、容量、版、責任を確認し、TBD を閉じるか責任者と期限を付ける。

2. 契約と模擬器で早期検証する

   提供・消費側が機械可読スキーマ、例、スタブ、契約試験を使い、完全な統合環境を待たず項目・状態差を発見する。

3. 代表条件で双方を統合する

   承認版、資格情報、ネットワーク、データ規模、時刻設定を使い、正常、境界、異常、同時、旧消費者を双方ログと相関 ID で試す。

4. 障害と不確定状態を作る

   時間切れ、切断、重複、順序逆転、速度制限、不正資格、部分完了、依存復旧、再生を試し、越権、重複業務、照合不能状態がないことを確認する。

5. 照合、容量、セキュリティを検証する

   双方記録と権威状態を比較し、性能要件で負荷を試し、本人性、認可、漏えい、悪性入力、監査証拠を確認する。

6. インターフェース版ごとに受入証拠を作る

   要件基準、両側構築・サービス版、環境、データ、設定、結果、未解決偏差、双方確認を記録する。一回の成功呼出しは受入ではない。

7. 稼働後に観測・演習する

   成功、拒否、遅延、滞留、重複、結果不明、照合差、版比率を監視し、支援昇格、資格更新、依存停止、手動代替経路を維持する。

インターフェース変更は両側で評価し、提供側だけの互換判断にしない

提供側が追加項目と考えても、厳密な消費側は失敗することがあります。エラー意味や既定順序の変更は構造を変えず業務結果を変えます。200が返るかではなく、両側の実利用、意味、運用リスクで互換性を判断します。

企業 AI のインターフェース要件はモデル、知識、ツール、人の境界を覆う

企業AIは複数の信頼境界を越えます。社内資料が検索へ、検索結果がモデルへ、モデル提案がツールへ進み、失敗は人へ渡ります。各境界でデータ権限、状態、責任が変わるため、モデル要求形式だけでは完全なインターフェースになりません。

インターフェース要件と隣接概念の違い

API仕様、データモデル、連携設計、サービス水準はそれぞれ境界の一部を説明しますが、単独で完全要件にはなりません。インターフェース要件は両側が業務責任を共同で果たす条件を定め、技術構造、運用品質、変更統制を結びます。