外部IF Webhook 仕様

Home

📕Arrow icon of a page linkサンエムシステム 上流工程標準(Preview版)

⚖️Arrow icon of a page linkサンエムシステム上流工程 標準規格

📘Arrow icon of a page link要件定義 実践ガイド

📘Arrow icon of a page link基本設計 実践ガイド

📄Arrow icon of a page linkテンプレート集

Get Started

📄Arrow icon of a page link基本設計工程のルール

📄Arrow icon of a page link基本設計書の構成を決める

🚧Arrow icon of a page link基本設計のプロセスモデル

実践ガイド

文書情報
システム方式設計
外部仕様設計
運用設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
レビュー・承認

外部IF Webhook 仕様

外部システムとのWebhook連携におけるイベント通知の仕様を定義し、セキュアで信頼性の高い連携を実現します。

🎯 概要


  • 目的: 外部システムとのWebhook連携における仕様を明確化し、イベント通知の確実な配信とセキュアな連携を実現する
  • スコープ: Webhook送信のエンドポイント仕様、ペイロード形式、認証方式、リトライポリシー、エラーハンドリングをカバーする。外部システム側の実装詳細は対象外
  • 推奨する実施タイミング: 外部システムとの連携要件が確定した後、API設計と並行して実施する
  • 関連するステークホルダー: システムアーキテクト、外部システム連携先担当者、セキュリティチーム、インフラチーム

📥 重要な前提知識・インプット


  • 前提知識: HTTP/HTTPS通信、RESTful API、Webhook の仕組み、HMAC署名検証、非同期処理、リトライポリシー
  • インプット: 外部システム連携要件、通知対象イベント一覧、外部システムのエンドポイント仕様、セキュリティ要件、可用性要件

📄 成果物の定義


  • ドキュメントテンプレート: 📄Arrow icon of a page link[テンプレ]外部IF Webhook 仕様
  • 必須要素: Webhookエンドポイント仕様、イベント種別一覧、ペイロード定義、認証・署名検証方式、リトライポリシー、エラーコード一覧、タイムアウト設定
✅ 品質基準・レビュー観点

品質チェックリスト:

チェック項目 チェック内容
イベント定義の完全性 通知対象イベントが漏れなく定義されている
セキュリティ対策 署名検証による改ざん検知の仕組みが実装されている
信頼性設計 リトライポリシーとタイムアウトが適切に設定されている
ペイロード形式 ペイロードのスキーマが明確で、バージョニングが考慮されている

👁️‍🗨️ レビュー観点:

  • 要件との整合性: 外部システムが必要とするイベント通知が全て含まれているか
  • セキュリティの妥当性: HMAC署名など、適切な認証・検証方式が採用されているか
  • 信頼性の確保: リトライ、タイムアウト、エラーハンドリングが適切に設計されているか
  • 運用監視の容易性: ログ出力、失敗通知の監視、再送機能が考慮されているか
🧪成果物のサンプル
# Webhook仕様

**概要:**
本システムで発生した特定のイベント(決済完了、ステータス変更等)を外部システムへリアルタイムに通知するためのWebhookインターフェース。
連携先システムが指定したエンドポイントに対してHTTP POSTリクエストでイベントデータを送信する。

**エンドポイント設定:**
- 連携先が指定するURLPOSTリクエストを送信
- 署名検証用のシークレットキーを使用

**リクエスト例:**
```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署名検証ツール

テンプレートサイト: 📄Arrow icon of a page linkテンプレート集