{"meta":{"title":"Webhook の使用に関するベスト プラクティス","intro":"Webhook を使用する場合のセキュリティとパフォーマンスを向上させるには、次のベスト プラクティスに従います。","product":"Webhooks","breadcrumbs":[{"href":"/ja/webhooks","title":"Webhooks"},{"href":"/ja/webhooks/using-webhooks","title":"Webhook の使用"},{"href":"/ja/webhooks/using-webhooks/best-practices-for-using-webhooks","title":"ベスト プラクティス"}],"documentType":"article"},"body":"# Webhook の使用に関するベスト プラクティス\n\nWebhook を使用する場合のセキュリティとパフォーマンスを向上させるには、次のベスト プラクティスに従います。\n\n## 最小限のイベントに登録する\n\n必要な Webhook イベントのみをサブスクライブしてください。 これにより、サーバーで実行する必要がある作業量が減ります。 イベントへのサブスクライブに関する詳細については、「[webhookの作成](/ja/webhooks/using-webhooks/creating-webhooks)」と「[webhookの編集](/ja/webhooks/using-webhooks/editing-webhooks)」を参照してください。\n\n## Webhook シークレットを使用する\n\n> \\[!WARNING]\n> 機密情報が誤って公開されないよう、ペイロードの URL には機密情報を**含めない**でください。\n> これには、独自の API キーとその他の認証資格情報が含まれます。 代わりに、webhook 配信が GitHub によって送信され、改ざんされていないことを検証するには、webhook シークレットを使用します。 詳しくは、「[Webhook 配信を検証する](/ja/webhooks/using-webhooks/validating-webhook-deliveries)」をご覧ください。\n\nWebhook シークレットはエントロピーの高いランダムな文字列にしてください。 サーバーがアクセスできる方法で Webhook シークレットを安全に格納してください。\n\n## HTTPS と SSL 検証を使用する\n\nサーバーで HTTPS 接続が使用されていることを確認してください。 既定では、 GitHub は Webhook を配信するときに SSL 証明書を検証します。\nGitHub では、SSL 検証を有効のままにすることをお勧めします。\n\n## GitHubの IP アドレスを許可する\n\nサーバーの IP 許可リストを設定し、webhook 配信 GitHub 使用する IP アドレスを追加できます。 これにより、サーバーへのなりすまし要求をブロックできます。\n\n`GET /meta` エンドポイントを使用して、GitHubの IP アドレスの現在の一覧を見つけることができます。 詳しくは、「[メタデータ用 REST API エンドポイント](/ja/rest/meta/meta#get-github-meta-information)」をご覧ください。\nGitHub IP アドレスに変更が加わる場合があるため、IP 許可リストを定期的に更新する必要があります。\n\n詳しくは、「[GitHubの IP アドレスについて](/ja/authentication/keeping-your-account-and-data-secure/about-githubs-ip-addresses)」をご覧ください。\n\n## 10 秒以内に応答する\n\nサーバーは、webhook 配信を受信してから 10 秒以内に 2XX 応答で応答する必要があります。 サーバーの応答にそれ以上の時間がかかる場合、 GitHub は接続を終了し、配信が失敗したと見なします。\n\nタイムリーに応答するために、Webhook ペイロードを非同期的に処理するキューを設定できます。 サーバーは、Webhook を受信したときに応答し、その後の Webhook デリバリーをブロックすることなく、バックグラウンドでペイロードを処理できます。 たとえば、次のようになります。 [Hookdeck](https://hookdeck.com) などのサービスや、[Resque](https://github.com/resque/resque/) (Ruby) などのライブラリを使用できます。 [RQ](http://python-rq.org/) (Python)、または [RabbitMQ](http://www.rabbitmq.com/) (Java)。\n\n## イベントの処理前にイベントのタイプとアクションを確認する\n\nWebhook のイベントの種類は複数あり、イベントの多くには複数のアクション タイプがある可能性があります。\nGitHub は、既存のイベントの種類に新しいイベントの種類と新しいアクションを追加し続けます。 アプリケーションでは、ペイロードを処理する前に、Webhook ペイロードのイベントの種類とアクションを確認するようにしてください。 イベントの種類を確認するには、`X-GitHub-Event` 要求ヘッダーを使用します。 アクション タイプを決定するには、イベント ペイロードで最上位の `action` キーを使用します。\n\n## 配信されなかった場合に再配信する\n\nサーバーがダウンした場合は、サーバーが復帰したら、配信されなかった Webhook を再配信してください。 詳しくは、「[Webhook の再配信](/ja/webhooks/testing-and-troubleshooting-webhooks/redelivering-webhooks)」をご覧ください。\n\n## `X-GitHub-Delivery` ヘッダーを使用する\n\nリプレイ攻撃では、不適切なアクターが Webhook 配信をインターセプトし、配信を再送信します。 リプレイ攻撃から保護するために、`X-GitHub-Delivery` ヘッダーを使用して、各配信がイベントごとに一意であることを確認できます。\n\n> \\[!NOTE]\n> 再配信を要求した場合、`X-GitHub-Delivery` ヘッダーは元の配信と同じになります。\n\n## 参考資料\n\n* [REST API を使用するためのベスト プラクティス](/ja/rest/using-the-rest-api/best-practices-for-using-the-rest-api)\n* [GitHub アプリを作成するためのベスト プラクティス](/ja/apps/creating-github-apps/about-creating-github-apps/best-practices-for-creating-a-github-app)"}