「ここは受注が確定したタイミングで、Webhookで在庫管理システムに通知を飛ばす形にしましょう」
打ち合わせの終盤、開発会社の担当者がさらりとそう言った。画面共有されたホワイトボードには、四角と矢印がいくつも並んでいる。頷きながら議事録を取っていたが、正直なところ「Webhook」という単語が出てきた瞬間から、頭の中の集中力が半分になっていた。聞き返すべきか迷ったが、隣に座る自社のエンジニア一人が「はい、それでいいと思います」とすぐ返したので、経営者として口を挟むタイミングを逃した。そのまま「お願いします」と答えて打ち合わせは終わった。
数日後、送られてきた要件定義書を読み返すと、Webhookという言葉が七箇所も出てくる。「Webhookエンドポイントを実装」「Webhookの再送ポリシー」「署名検証」――読めば読むほど、自分が何にゴーサインを出したのか分からなくなってくる。これは決して珍しい話ではない。中小企業の経営者やシステム担当者の多くが、開発会社との打ち合わせで一度はこの壁にぶつかっている。専門用語がわからないまま相槌を打ち、後で仕様書を読んで青ざめる。そういう経験を持つ人は、想像以上に多い。
この記事では、Webhookという仕組みを、非エンジニアでも自分の言葉で説明できるレベルまで噛み砕く。そして単なる用語解説で終わらせず、発注者としてこの言葉が出てきたときに何を確認すべきか、どこまで踏み込んで質問していいのかを具体的に示す。専門知識がないことは恥ではない。壁を越えて仕事を前に進めようとする人にとって、必要なのは全部を理解することではなく、要所を押さえて的確な質問を投げられることだ。
Webhookとは何か、身構えずに理解する
Webhookを一言で表すなら「何かが起きたら、システムの側から自動的に知らせてくる仕組み」だ。難しい言葉を使わずに説明するなら、宅配便の再配達通知に近い。
荷物が届かなかったとき、あなたは配送業者のサイトに何度もアクセスして「まだ届いてないかな」「今日は配達予定あるかな」と確認したりはしない。多くの場合、配達員が来られなかった時点で不在通知や再配達依頼のメッセージがスマートフォンに届く。何かが起きたら、向こうから知らせてくれる。これがWebhookの本質だ。
対照的なのが、よく一緒に語られる「API連携」という言葉だ。厳密にはWebhookもAPIの一種だが、実務上の使い分けとしては次のように理解すると分かりやすい。
- API連携(問い合わせ型): こちらのシステムが「新しい注文は入っていますか」と定期的に相手に聞きに行く。1分おき、5分おきといった間隔で確認しに行くため、確認していない間に起きた変化にはすぐ気づけない。
- Webhook(通知型): 相手のシステムで注文が入った瞬間に、相手の側から「注文が入りました」とこちらに知らせてくる。こちらから聞きに行く必要がない。
前者は、レストランの厨房に何度も「注文入りましたか」と聞きに行く店員のようなもので、聞くたびに手間がかかるし、聞いていないタイミングでの注文には気づけない。後者は、注文が入った瞬間に厨房からベルが鳴る仕組みだ。ベルが鳴るまで待っていればよく、無駄な確認作業も発生しない。開発会社が「ここはWebhookで」と言うとき、多くの場合はこの「ベルを鳴らす」設計を提案している、と理解しておけば大枠は外さない。
業務システムでWebhookがよく使われる場面
抽象的な説明だけでは実感が湧きにくいので、実際の業務でどう使われているかを具体的に見ていく。
- ECサイトで受注が確定した瞬間に、倉庫の在庫管理システムへ「この商品が1点売れた」と通知が飛び、在庫数が自動で減る。
- 決済代行サービスで入金が完了した瞬間に、自社の会計システムや受発注システムへ通知が飛び、入金待ちのステータスが自動的に「入金済み」に変わる。
- 自社サイトの問い合わせフォームが送信された瞬間に、担当部署のチャットツールやメールに「新しい問い合わせが届きました」という通知が自動で流れる。
- 予約システムで顧客がキャンセルした瞬間に、空いた枠をカレンダーシステムに反映し、代替の予約を受け付けられる状態にする。
- クラウド勤怠システムで打刻が行われた瞬間に、給与計算システムへその日の労働時間データが自動で送られる。
いずれも共通しているのは「何かが起きた瞬間」を起点に、人手を介さず次の処理へつながっている点だ。担当者が画面を開いて確認し、別のシステムに手で転記する、という作業が丸ごと不要になる。これがWebhookが業務システムの設計でよく提案される理由であり、開発会社が「ここはWebhookで」と言うときには、たいてい「この業務にかかっている人の手間を自動化で減らしましょう」という提案が背後にある。
Webhookを使うことのメリット
発注者として押さえておきたいメリットは大きく二つある。
一つ目はリアルタイム性だ。定期的に確認しに行く方式では、確認と確認の間に起きた変化に気づくまでにタイムラグが生じる。5分おきの確認であれば、最悪5分近く気づかない。受注確定から出荷準備までのスピードが競争力に直結する業種では、このタイムラグが積み重なって顧客体験を損なうことがある。Webhookであれば、起きた瞬間にほぼ即座に次の処理が動き出す。
二つ目は、手動確認にかかっていた人的コストとシステム負荷の削減だ。確認しに行く方式は、変化がなくても律儀に問い合わせを繰り返す。これは人の作業であれば単純に時間の無駄であり、システムであっても無駄な通信が積み重なって負荷になる。Webhookは変化があったときだけ動くので、無駄がない。
数字にたとえるなら、1日に300件の注文が入るECサイトで、5分おきの確認方式なら1日288回のチェックが発生する。そのほとんどは「変化なし」の空振りだ。Webhookであれば、動くのは注文が入った300回だけで済む。効率の差は明らかだろう。
発注者として知っておくべき注意点
ここからが、非エンジニアの担当者が一番つまずきやすく、かつ一番重要な部分だ。Webhookは便利だが、万能ではない。仕組み上、いくつかの弱点を抱えている。ここを理解しないまま「お願いします」と進めると、後々のトラブルの火種になる。
一つ目は、通知が届かない可能性がある、という点だ。Webhookは通知を送る側と受け取る側、両方のシステムがネットワークでつながっていて初めて成立する。受け取る側のサーバーが一時的にダウンしていたり、通信が不安定だったりすると、通知はうまく届かない。荷物の不在通知が、電波が悪くて届かなかったようなものだと思えばいい。このとき、送る側のシステムが「届かなかったら、もう一度送り直す」という再送の仕組み(リトライ)を持っているかどうかで、実際の信頼性が大きく変わる。
二つ目は、二重処理のリスクだ。再送の仕組みがあること自体は良いことだが、再送された結果、同じ注文の通知が二回届いてしまうことがある。この場合、システム側で「これはさっき処理した注文と同じだ」と判断して二重に在庫を減らしたり、二重に請求を発生させたりしないようにする仕組みが必要になる。これを専門的には「冪等性(べきとうせい)」と呼ぶが、非エンジニアが覚える必要があるのは用語ではなく、「同じ通知が二回来ても被害が出ない設計になっているか」という問いだけだ。
三つ目は、外部サービス側で障害が起きた場合にどうなるか、という点だ。決済代行サービスや外部の予約プラットフォームなど、自社の外にあるサービスからのWebhookに業務が依存している場合、そのサービス側で障害が起きれば通知そのものが止まる。このとき、自社の業務がどこまで止まるのか、手動での代替手段があるのかを、平時のうちに確認しておく必要がある。壁を越えて外部のサービスとつながることは大きな力になるが、その壁の向こう側で何かが起きたときの備えを怠ると、思わぬところで業務が止まる。
発注時に確認すべき質問リスト
専門用語を覚える必要はない。次の質問さえ投げられれば、発注者としての責任は十分に果たせる。
- 通知が届かなかった場合、自動的に再送される仕組みになっているか。再送は何回、どのくらいの間隔で行われるか。
- 同じ通知が重複して届いた場合、業務データが二重に処理されない設計になっているか。
- 通知を送る側(あるいは受け取る側)のサービスで障害が起きた場合、業務にどのような影響が出るか。手動での代替対応は可能か。
- 通知が届いたかどうかを、後から人間の目で確認できる仕組み(ログや管理画面)はあるか。
- 誰でも偽の通知を送りつけられるような、セキュリティ上の抜け穴はないか(送信元を確認する仕組みがあるか)。
- この連携が止まったとき、最初に気づくのは誰で、どう対応する想定か。
この六つを打ち合わせの場で聞いておくだけで、後から仕様書を読んで青ざめる可能性はぐっと下がる。分からない言葉が出てきたら、その場で「それは、具体的にはどういう状態になったときに困る話ですか」と聞き返してもいい。開発会社の担当者にとって、業務影響を理解しようとする発注者からの質問は歓迎されることはあっても、迷惑がられることはまずない。
よくある失敗パターン
実際の現場でよく起きる失敗をいくつか紹介する。自社に当てはまるものがないか、確認してみてほしい。
- 通知が届かなかったときの対応を決めずに稼働を始めてしまい、ある日突然「注文は入っているのに在庫が減っていない」という不整合に気づいて慌てる。原因を調べると、数日前に一度だけ通信が不安定になり、その回の通知が失われていたことが判明する。
- 再送の仕組みはあったが、二重処理を防ぐ仕組みが抜けていたため、再送された通知によって同じ注文が二回計上され、在庫がマイナスになっていた。
- 外部の決済サービスに障害が起きた際、Webhookが止まっていることに誰も気づかず、入金確認待ちの注文が数時間分たまってしまい、出荷が丸一日遅れた。
- 開発会社に「Webhookで」と言われた時点で内容を理解しないまま進め、納品後に「思っていた動きと違う」と気づいたが、要件定義の段階で確認していなかったため追加費用が発生した。
これらに共通するのは、技術的な実装が間違っていたわけではなく、発注者側が「起きたときにどうなるか」を事前に確認していなかった、という点だ。Webhookそのものは枯れた技術であり、正しく設計すれば十分に信頼できる仕組みだ。問題が起きるのは、多くの場合、想定外の事態への備えについての会話が、発注側と開発側の間で交わされていなかったときである。
まとめ
Webhookとは、何かが起きた瞬間にシステムの側から自動的に知らせてくる仕組みであり、こちらから定期的に確認しに行く方式に比べて、リアルタイム性が高く、手動確認の手間を減らせる。受注確定の通知、決済完了による在庫更新、フォーム送信による担当者への自動通知など、業務のさまざまな場面で使われている。
一方で、通知が届かない可能性、二重処理のリスク、外部サービス障害時の影響という三つの弱点を抱えている。発注者としてすべてを技術的に理解する必要はない。ただ、この記事で挙げた六つの質問を打ち合わせの場で投げられるかどうかで、後から仕様書を読んで不安になるか、自信を持って次の工程に進めるかが変わってくる。
専門用語がわからないまま相槌を打つしかなかった経験は、恥ずべきことではない。大切なのは、わからないことをそのままにせず、業務にどう影響するのかという自分たちの言葉に翻訳して聞き返す姿勢だ。その一歩を踏み出せる担当者こそが、システムと現場の壁を越えて、会社を前に進めている。