Webhook
読み: ウェブフック
Webhookとは即時連携の仕組み
Webhookは、特定のイベントが発生したタイミングで、あらかじめ指定したURLにHTTPリクエストを自動送信する仕組み。APIのように定期的に問い合わせる必要がなく、変化があった瞬間に通知を受け取れるため、リアルタイム連携に適している。
かんたんに言うと
何か起きたら教えてと登録しておくと、その瞬間に通知が届く仕組みである。こちらから繰り返し確認しに行く必要がない。
定期的なAPI問い合わせを不要にするWebhookとポーリングの違い
システム間でデータをやり取りする方法は、大きく2つに分かれる。ポーリングとWebhookである。
ポーリングは、一定間隔でAPIを叩いて新しいデータがあるか問い合わせる方式。新着がなくても毎回リクエストを送るため、APIの呼び出し回数が膨れ上がる。リアルタイム性を求めるほど間隔を短くする必要があり、サーバー負荷とAPI料金が比例して増える。
Webhookはこの無駄を省く。イベントが発生した側が、受け取り先のURLにPOSTリクエストを送るだけである。Stripeの決済完了通知、GitHubのプッシュ通知、Slackのメッセージ投稿通知など、主要なSaaSの大半がWebhookに対応している。
受信側のサーバーで必要になる実装と設計上の考慮点
Webhookを受け取るには、インターネットからアクセスできるURLを用意する必要がある。社内のファイアウォール内に閉じたシステムでは、そのままでは受信できない。
受信したら即座にHTTP 200を返し、実際の処理はバックグラウンドで非同期に行うのが定石である。レスポンスが遅いと、送信側がタイムアウトと判断して再送する。再送が重複処理を引き起こさないよう、冪等性の担保も必要になる。
セキュリティ面では、送信元の正当性を検証する仕組みが欠かせない。多くのサービスはリクエストヘッダーにHMACシグネチャを付与しており、受信側で秘密鍵を使って検証する。これを省略すると、第三者が偽のリクエストを送り込む余地が生まれる。
AI連携における活用パターンと具体例
AIワークフローでもWebhookは頻繁に使われる。
たとえば、DifyやLangChainで構築したAIパイプラインの処理完了を、社内のチャットツールに通知する場面。処理が終わるまでの時間が読めない非同期タスクでは、完了通知をWebhookで飛ばすのが自然な設計となる。
フォーム送信をトリガーにAIが自動で回答案を生成し、Slackに投稿する仕組みもWebhookの典型的な活用例である。
ZapierやMakeのようなノーコードツールもWebhookを軸にサービス同士を接続している。コードを書かずにAIと業務システムを繋げられるため、エンジニアのリソースが限られる組織では選択肢に入る。
運用で陥りがちなトラブルと対策
最も多いトラブルは、送信側のリトライによる重複処理である。ネットワーク障害やサーバーの一時的なダウンで200レスポンスを返せなかった場合、送信側は数分後に再送する。受信側でリクエストIDを記録し、同じIDが来たら処理をスキップするロジックを入れておく必要がある。
次に、送信側の仕様変更がある。ペイロードのJSON構造が予告なく変わることは珍しくない。パースに失敗したリクエストをデッドレターキューに退避させ、後から確認できるようにしておくと被害を最小限に抑えられる。
障害時の通知漏れも見落としやすい。Webhookはプッシュ型ゆえに、受信側がダウンしている間に送られた通知は届かない可能性がある。定期的にポーリングで差分を確認する併用型の設計が、重要なデータ連携では推奨される。
当社の見解
当社はツール選定において実用性を第一方針にしている。カタログスペックやベンチマークスコアではなく、実務で1週間使い倒して初めて判断する。フレームワークを増やすほど管理コストが増える経験もした。フックを増やしすぎてAIが情報過多でパニックになったこともある。足し算だけでなく、引き算の判断が選定の質を決める。検証せずに導入したツールは、ほぼ例外なく3か月以内に使わなくなった。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。