設計対象:

外部システムとの連携における認証（誰であるかを確認）と認可（何ができるかを制御）の方式を決定する。

具体例:

• REST API: OAuth 2.0、API Key、JWT（JSON Web Token）のいずれを使うか
• メッセージング: 共有シークレット、証明書ベース認証のいずれを使うか
• ファイル連携: SFTP（公開鍵認証）、FTPS、共有ストレージ（IAM認証）のいずれを使うか
• 認可方式: ロールベースアクセス制御（RBAC）、APIスコープ、IPアドレス制限をどう組み合わせるか

設計原則:

• セキュリティ要件への準拠: セキュリティポリシーや業界標準（OWASP、NIST）に準拠した方式を選択する
• 連携先の制約考慮: 連携先システムがサポートする認証方式に合わせる
• 最小権限の原則: 必要最小限の権限のみを付与し、過剰な権限を与えない
• トークン管理: トークンの有効期限、更新方式、失効方式を明確にする
• 監査可能性: 誰がいつアクセスしたかを記録し、監査できるようにする

文書化の推奨表現:

• 認証方式一覧: 連携種別（REST API、メッセージング、ファイル連携）ごとに採用する認証方式を表形式で整理する
• 認可ポリシー: ロール定義、APIスコープ、アクセス制御ルールを明記する
• トークン仕様: トークンの形式、有効期限、更新フロー、格納場所（ヘッダー、クエリパラメータなど）を記載する
• セキュリティ考慮事項: 通信の暗号化（TLS 1.2以上）、クレデンシャルの保管方法、ローテーションポリシーを文書化する

設計対象:

外部連携で発生するエラーの分類、共通エラーコード、リトライポリシー、エラー通知方法を決定する。

具体例:

• 共通エラーコード体系: AUTH_ERROR（認証エラー）、PERMISSION_DENIED（権限エラー）、INVALID_REQUEST（リクエスト不正）、SYSTEM_ERROR（システムエラー）、TIMEOUT（タイムアウト）
• リトライポリシー: 一時的なエラー（5xx）は最大3回リトライ（指数バックオフ）、クライアントエラー（4xx）はリトライしない
• エラー通知: 重大なエラーはアラート通知、一時的なエラーはログ記録のみ

設計原則:

• エラー分類の明確化: 一時的なエラー（リトライ可能）と恒久的なエラー（リトライ不可）を明確に区別する
• 適切なリトライ戦略: リトライ回数、リトライ間隔（固定/指数バックオフ）、リトライ条件を定義する
• エラー情報の充実: エラーコード、エラーメッセージ、詳細情報（トレースID、タイムスタンプなど）を含める
• 連携先への影響考慮: 過度なリトライで連携先システムに負荷をかけないようにする
• 運用対応の容易性: エラー発生時の調査・対応手順が明確になるように情報を設計する

文書化の推奨表現:

• エラーコード一覧: エラーコード、エラー名、原因、対処方法を表形式で整理する
• リトライポリシー表: エラー種別ごとのリトライ可否、リトライ回数、リトライ間隔を明記する
• エラーレスポンス形式: JSONやXMLでのエラーレスポンスのフォーマット例を示す
• エラー通知設計: どのエラーをどのタイミングで誰に通知するかを定義する

設計対象:

外部連携で使用するデータフォーマット（JSON、XML、CSV）、文字コード、日時形式、通信プロトコルを統一する。

具体例:

• データフォーマット: REST APIはJSON、ファイル連携はCSV（UTF-8）、レガシーシステムとの連携はXML
• 文字コード: UTF-8を標準とする（レガシーシステムとの連携時はShift_JISも許容）
• 日時形式: ISO 8601形式（YYYY-MM-DDTHH:mm:ssZ）を標準とする
• 通信プロトコル: HTTPS（TLS 1.2以上）、SFTP、MQ（TLS有効化）

設計原則:

• 標準形式の採用: 業界標準（ISO 8601、RFC 8259など）に準拠した形式を優先する
• システム全体での統一: すべての外部インターフェースで可能な限り同じ形式を使用する
• 互換性の確保: 連携先システムがサポートする形式に合わせる（変換処理を実装する）
• 拡張性の考慮: 将来の項目追加に対応できる柔軟な形式を選択する（JSONの任意フィールドなど）
• データ検証: スキーマ定義（JSON Schema、XSDなど）を用意し、データの妥当性を検証する

文書化の推奨表現:

• データフォーマット標準: 連携種別ごとの標準フォーマット、文字コード、エンコーディングを表形式で整理する
• 日時・数値形式: 日時形式（タイムゾーン含む）、数値形式（桁数、小数点）、真偽値（true/false, 0/1）の表記ルールを明記する
• 通信プロトコル仕様: 使用するプロトコル、バージョン、暗号化方式、ポート番号を記載する
• スキーマ定義: JSON Schema、XSD、CSVの列定義など、データ構造の仕様を提供する

設計対象:

外部連携の正常性監視、性能監視、ログ出力項目、ログ保管期間を決定する。

具体例:

• 監視項目: 連携成功率、レスポンスタイム、エラー発生件数、タイムアウト発生件数
• ログ出力項目: リクエスト/レスポンス内容（個人情報はマスキング）、処理時間、エラー詳細、送信元/送信先情報、トレースID
• ログ保管期間: 通常ログは3ヶ月、監査ログは1年間保管

設計原則:

• 運用性の確保: 障害発生時に原因を特定できるだけの情報を記録する
• 個人情報保護: 個人情報や機密情報はマスキングまたは除外する
• 性能への影響最小化: ログ出力による性能劣化を最小限に抑える（非同期ログ出力など）
• トレーサビリティ: トレースIDやリクエストIDを使い、複数システム間で処理を追跡できるようにする
• 監視アラート設計: 異常検知の閾値とアラート通知先を明確にする

文書化の推奨表現:

• ログ出力項目一覧: 出力する項目名、形式、必須/任意、マスキング要否を表形式で整理する
• ログレベル定義: DEBUG、INFO、WARN、ERRORの使い分け基準を明記する
• 監視ダッシュボード設計: 監視する指標（メトリクス）、可視化方法、アラート条件を記載する
• ログ保管・ローテーション: ログファイルの保管場所、保管期間、ローテーション方式を文書化する