Home
Get Started
実践ガイド
外部仕様設計
バッチ処理仕様設計
UAC 仕様設計
データ仕様設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
外部IF Webhook 仕様
外部システムとのWebhook連携におけるイベント通知の仕様を定義し、セキュアで信頼性の高い連携を実現します。
🎯 概要
- 目的: 外部システムとのWebhook連携における仕様を明確化し、イベント通知の確実な配信とセキュアな連携を実現する
- スコープ: Webhook送信のエンドポイント仕様、ペイロード形式、認証方式、リトライポリシー、エラーハンドリングをカバーする。外部システム側の実装詳細は対象外
- 推奨する実施タイミング: 外部システムとの連携要件が確定した後、API設計と並行して実施する
- 関連するステークホルダー: システムアーキテクト、外部システム連携先担当者、セキュリティチーム、インフラチーム
📥 重要な前提知識・インプット
- 前提知識: HTTP/HTTPS通信、RESTful API、Webhook の仕組み、HMAC署名検証、非同期処理、リトライポリシー
- インプット: 外部システム連携要件、通知対象イベント一覧、外部システムのエンドポイント仕様、セキュリティ要件、可用性要件
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]外部IF Webhook 仕様
- 必須要素: Webhookエンドポイント仕様、イベント種別一覧、ペイロード定義、認証・署名検証方式、リトライポリシー、エラーコード一覧、タイムアウト設定
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| イベント定義の完全性 | 通知対象イベントが漏れなく定義されている |
| セキュリティ対策 | 署名検証による改ざん検知の仕組みが実装されている |
| 信頼性設計 | リトライポリシーとタイムアウトが適切に設定されている |
| ペイロード形式 | ペイロードのスキーマが明確で、バージョニングが考慮されている |
👁️🗨️ レビュー観点:
- 要件との整合性: 外部システムが必要とするイベント通知が全て含まれているか
- セキュリティの妥当性: HMAC署名など、適切な認証・検証方式が採用されているか
- 信頼性の確保: リトライ、タイムアウト、エラーハンドリングが適切に設計されているか
- 運用監視の容易性: ログ出力、失敗通知の監視、再送機能が考慮されているか
🧪成果物のサンプル
# Webhook仕様
**概要:**
本システムで発生した特定のイベント(決済完了、ステータス変更等)を外部システムへリアルタイムに通知するためのWebhookインターフェース。
連携先システムが指定したエンドポイントに対してHTTP POSTリクエストでイベントデータを送信する。
**エンドポイント設定:**
- 連携先が指定するURLにPOSTリクエストを送信
- 署名検証用のシークレットキーを使用
**リクエスト例:**
```http
POST /webhook/events
Content-Type: application/json
X-Signature: sha256=...
{
"event": "payment_completed",
"data": {
"payment_id": "pay_12345",
"amount": 10000,
"status": "success"
}
}
```
**リトライ:**
- HTTP 2xx以外の応答時に再送
- 最大3回、指数バックオフ
**タイムアウト:** 30秒
--- 🔄 設計の進め方・プロセス
🏗️ プロセス1: 通知対象イベントの定義
設計対象:
外部システムに通知すべきイベントを特定し、各イベントのトリガー条件と通知タイミングを明確化する。
具体例:
- どのビジネスイベント(決済完了、ステータス変更、データ更新など)を通知対象とするか
- 各イベントはどのタイミングで発火するか(トランザクション確定後、非同期処理完了後など)
- イベントの優先度や重要度はどうか(必須通知、任意通知)
- 通知の順序保証が必要か
設計原則:
- ビジネス要件との整合: 外部システムが必要とするイベントを漏れなく特定する
- 粒度の適切性: イベントの粒度が細かすぎず粗すぎない、適切なレベルで定義する
- 拡張性の確保: 将来的なイベント追加を見越して、イベント種別の命名規則を統一する
- 冪等性の考慮: 同一イベントの重複通知が発生しても問題ないよう、イベントIDで一意性を保証する
文書化の推奨表現:
- イベント一覧表の作成: イベント名、説明、トリガー条件、ペイロード概要を一覧化する
- イベントフロー図の作成: システム内でどのようにイベントが発生し、Webhookとして送信されるかをシーケンス図で表現する
- 命名規則の定義: イベント名の命名規則(例:
resource.action形式)を定義する
🏗️ プロセス2: ペイロード仕様の設計
設計対象:
各イベントで送信するデータ構造(ペイロード)を設計し、外部システムが必要とする情報を含める。
具体例:
- イベント種別、タイムスタンプ、リクエストIDなどの共通フィールドをどう定義するか
- イベント固有のデータをどのような形式で含めるか(JSON、XML)
- 個人情報や機密情報をどこまで含めるか、マスキングが必要か
- ペイロードのバージョニングをどう管理するか
設計原則:
- 必要十分な情報: 外部システムが処理に必要な情報を過不足なく含める
- プライバシー保護: 不要な個人情報は含めず、必要な場合はマスキング・暗号化を検討する
- 拡張性の確保: 将来的なフィールド追加に備え、バージョンフィールドを含める
- 標準形式の採用: JSON形式を採用し、ISO 8601形式の日時表現など標準的な形式に従う
文書化の推奨表現:
- JSONスキーマの定義: 各イベントのペイロード構造をJSONスキーマで定義する
- サンプルペイロードの提供: 実際の送信例をコードブロックで示す
- フィールド仕様表の作成: 各フィールドの名前、型、必須/任意、説明を表形式で整理する
- バージョニング方針の明記: ペイロード形式の変更時のバージョン管理方法を記載する
🏗️ プロセス3: 認証・セキュリティ方式の設計
設計対象:
Webhook送信時の認証方式と、ペイロードの改ざん検知の仕組みを設計する。
具体例:
- HMAC署名、JWT、APIキーのいずれを認証方式として採用するか
- 署名アルゴリズム(SHA256など)はどうするか
- シークレットキーの管理方法(環境変数、KMSなど)はどうするか
- HTTPS通信を必須とするか
設計原則:
- 改ざん検知の実装: HMAC署名などで、ペイロードの改ざんを受信側で検証可能にする
- シークレット管理の徹底: シークレットキーはコードに含めず、安全な方法で管理する
- HTTPS必須化: 通信経路の暗号化のため、HTTPSエンドポイントのみを許可する
- リプレイ攻撃対策: タイムスタンプを含め、古いリクエストを拒否できるようにする
文書化の推奨表現:
- 署名検証フローの記述: 署名生成と検証のアルゴリズムを具体的に記載する
- サンプルコードの提供: 受信側での署名検証のサンプルコードを提供する
- HTTPヘッダーの仕様: 署名を含むヘッダー名と形式を明記する
- セキュリティ要件の明記: HTTPS必須、タイムアウト、リプレイ攻撃対策などを記載する
🏗️ プロセス4: リトライポリシーとエラーハンドリング
設計対象:
Webhook送信失敗時のリトライロジックとエラー処理の方針を設計する。
具体例:
- リトライ回数は何回にするか(例: 最大3回)
- リトライ間隔はどうするか(固定間隔、指数バックオフ)
- どのHTTPステータスコードでリトライするか(5xx、タイムアウト)
- 最終的に失敗した場合の処理(ログ記録、アラート、手動再送キュー)
設計原則:
- 一時的障害への対応: ネットワークエラーやサーバー一時停止に対してリトライで対応する
- 無限ループの回避: リトライ回数に上限を設け、無限に再送し続けないようにする
- バックオフの実装: 指数バックオフで、受信側サーバーへの負荷を軽減する
- 監視とアラート: 失敗時のログ記録と、連続失敗時のアラート通知を実装する
文書化の推奨表現:
- リトライポリシーの明記: リトライ回数、間隔、対象ステータスコードを具体的に記載する
- タイムアウト設定の記述: HTTPリクエストのタイムアウト時間を明記する
- エラーハンドリングフローの図示: 失敗時の処理フローをフローチャートで表現する
- 運用監視の方針: ログ出力内容、監視項目、アラート条件を記載する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考文献: RFC 7518(JSON Web Algorithms)、OWASP Webhook Security Guide
- 関連する他のガイド: API設計ガイド、セキュリティ設計ガイド、非同期処理設計ガイド
- ツール・テンプレート: draw.io、Postman、JSONスキーマバリデーター、HMAC署名検証ツール
テンプレートサイト: 📄テンプレート集