Slack通知やLINE通知が急に来なくなった。
Webhook連携トラブルの切り分け方
執筆:岩崎哲也(KAIテクノウェブデザイン)|公開日:2026年7月18日
「Webhook(ウェブフック)」とは、あるサービスで何かが起きたときに、あらかじめ決めておいた別のサービスへ、自動でお知らせを飛ばす仕組みのことです。EagleEyeやAI工房で作った自動通知も、ほとんどはこの仕組みの上に成り立っています。
結論から先にお伝えします。ある日突然、SlackやLINEへの通知が来なくなった場合、原因は基本的に3つの段階のどこかにあります。①連携設定そのもの、②送信元サービスの仕様やトークン、③サーバー側の通信――この順番で、階段を1段ずつ確認していくのが、いちばん遠回りにならない方法です。
第1段階:連携設定そのものが外れていないかを確認する
まず疑ってほしいのは、いちばん基本的なところです。意外と、ここだけで解決するケースが多くあります。
Slackの場合は、通知を受け取っているワークスペースに、連携アプリ(Incoming Webhookなど)がまだ有効な状態で残っているかを確認してください。ワークスペースの管理設定を見直したタイミングで、意図せずアプリの権限が外れてしまうことがあります。
LINEの場合は、LINE公式アカウントやMessaging APIの管理画面で、Webhookの利用設定が「オン」になっているかを見てください。アカウントの引き継ぎや管理者の交代があったときに、この設定がオフに戻っていることがあります。
もう1つ見落としやすいのが、通知先として登録しているURLそのものです。Slackの着信Webhook URLやLINEのWebhook URLは、アプリの再連携や再設定のタイミングで新しいものに切り替わることがあります。自動化ツール側に登録してあるURLが、古いままになっていないかを見比べてください。
第2段階:送信元サービスの仕様変更・トークンの期限切れを確認する
第1段階の設定に問題がなければ、次に疑うのは「送る側の資格」に関わる部分です。
LINE Messaging APIでは、通知を送るために使うチャネルアクセストークンに、有効期限が設定されている場合があります。発行時に長期間有効なトークンを選んでいなかったり、途中で再発行の作業が抜けてしまったりすると、ある日を境に送信そのものが拒否されるようになります。
Slackについても、連携アプリの権限(スコープ)が仕様変更で更新を求められたり、ワークスペース側のセキュリティポリシーでアプリの再承認が必要になったりすることがあります。「昨日まで動いていたのに、今日から急に」という止まり方をする場合、この手の仕様側の変化が原因であることが少なくありません。
EagleEyeのような自動化ツールを間に挟んでいる場合は、そのツール自体のアップデートで、送信の仕様やAPIの呼び出し方が変わっていないかも合わせて確認しておくと安心です。
第3段階:サーバー側のエラーログとタイムアウトを確認する
第1・第2段階を確認しても原因が見当たらない場合、通知を受け取る側・中継する側のサーバーに目を向ける必要が出てきます。
通知の送信自体は成功しているのに届かない、という場合は、受け取る側のサーバーがエラーを返している可能性があります。Slack・LINEとも、Webhookの送信結果や応答コード(正常なら200番台、エラーなら400番台・500番台など)を管理画面から確認できることが多いので、まずはそこに目を通してください。
もう1つ多いのが、サーバーの応答が遅すぎてタイムアウト扱いになるケースです。サーバーの負荷が高くなっている、SSL証明書の期限が切れてHTTPS通信自体がはじかれている、セキュリティソフトやファイアウォールの設定変更で外部への通信がブロックされている――こうした要因は、画面の見た目だけではまったく気づけません。
ここまで確認しても直らない場合
ここで、正直にお伝えします。第3段階まで来ると、確認に必要なのは「設定を見比べる」レベルの作業ではなく、サーバーのログを読み解き、どこで通信が途切れているのかを技術的に特定する作業になります。ここは非エンジニアの方が独力で踏み込むには、かなりハードルの高い領域です。
原因不明のまま放置してしまうと、通知が来ていないこと自体に気づけないまま、大事な連絡やお問い合わせを見逃し続けるリスクがあります。外部連携の接続不良の調査・修正を単発で依頼できるサービス(DEV RESCUE)では、ミニプラン(5万円〜)でこうした通知トラブルの原因調査に対応しています。仕組みを作り直す必要はなく、今動いている連携のどこで止まっているかを調べてもらう、という依頼の仕方ができます。
まとめ:3段階のチェックリスト
もう一度、確認する順番を並べておきます。
- ①連携設定:アプリの権限が外れていないか、Webhook URLが変わっていないか
- ②送信元の仕様:トークンの有効期限、アプリの再承認、自動化ツールの仕様変更
- ③サーバー側の通信:エラーログの応答コード、タイムアウト、SSLや通信のブロック
①②は、管理画面を見比べるだけで確認できることがほとんどです。ここで直らない場合は、無理に自力で抱え込まず、③の調査から専門家に相談する、という切り分け方をおすすめします。
よくある質問
Q. Webhookって何ですか?
A. あるサービスで何かが起きたときに、あらかじめ登録しておいた別のサービスへ、自動でお知らせを送る仕組みのことです。「フォームに入力があったらSlackに通知する」「注文が入ったらLINEに知らせる」といった連携の裏側で、ほぼ必ずこのWebhookという仕組みが使われています。人が毎回チェックしなくても、決められた通知先へ勝手に情報が飛んでいくイメージです。
Q. 通知が止まったとき、最初に確認すべきことは?
A. いきなりログや専門的な設定を調べる必要はありません。まずは記事内の第1段階、つまり連携そのものがオンになっているか、通知先のURLが変わっていないかを確認してください。ここだけで解決するケースが実際に多くあります。専門知識がなくても、管理画面を開いて見比べるだけで確認できる範囲です。
Q. 自分でエラーログを見るにはどうすればいいですか?
A. Slackなら連携アプリの管理画面に配信履歴やエラー表示が用意されていることが多く、LINE Messaging APIならLINE Developersコンソールの「Webhook」設定欄で、直近の送信結果や応答コードを確認できます。ただし、そこに表示される情報の意味を正しく読み解くには、サーバー側の知識が必要になる場面もあります。表示自体は見られても、原因の特定まで自力で進められるかどうかは、状況によって変わってきます。
Q. SlackとLINE、両方の通知が同時に止まった場合はどう考えればいいですか?
A. 2つのサービスがまったく別のタイミングで同時に不調になることは、可能性としては低いです。多くの場合、通知の送り分けを担っている自動化ツールや中継サーバーの側に原因があります。つまり、SlackやLINE個別の設定よりも先に、その手前にある共通の送信元を疑うのが近道です。
Q. 自分で直せない場合、どこに相談すればいいですか?
A. 第1段階・第2段階を確認しても直らない場合は、サーバー側のログ解析やコードの調査が必要になっている可能性が高いです。この部分は非エンジニアが独力で進めるのが難しい領域なので、外部連携の不具合調査だけを単発で依頼できるサービスに相談するのも一つの手です。作り直しではなく、今動いている仕組みの原因調査から入れる依頼の仕方もあります。
関連して読みたい記事
関心の近いところから1本ずつどうぞ