LINE WORKS Incoming Webhookの設定手順とJSON送信仕様｜5URL・120req/minの上限

LINE WORKS の Incoming Webhook アプリを使うと、管理者画面からアプリを追加してトークルームに Bot を招待するだけで、外部システムからトークルームへ通知を投げられます。Developer Console でのBot作成もアクセストークンの発行・更新も要りません。ただし公式ドキュメントが定める「Webhook URL は5つまで」「120 requests/min はドメイン全体で共有」という2つの上限を知らずに監視アラートを流し込むと、通知が 429 で落ちます。設定手順、POST する JSON の実体、レート制限を踏まえた設計、そして Bot API に切り替えるべき条件までを整理します。

まとめ

先に結論だけ押さえておきます。

• 導入は4ステップ。管理者画面 > アプリ でアプリを追加 → トークルームに Incoming Webhook Bot を招待 → トークルームのメニューからチャンネルIDを取得 → Webhook リスト画面で URL を発行、で完了します。
• 送信は https://webhook.worksmobile.com/message/{発行文字列} に Content-Type: application/json で POST するだけ。必須フィールドは body.text の1つです。
• 上限は2つ。Webhook URL は5つまで、Rate Limit は 120 requests/min です。後者は URL ごとではなく LINE WORKS ドメイン全体で1枠を共有します。
• 対応プランはフリー、スタンダード、アドバンスト。アプリディレクトリの無料アプリとして提供されています。
• トークルームからのメッセージ送信、画像を含むファイルの送信と高度なメッセージ形式、リッチメニュー／固定メニューのカスタマイズは非対応。これらが必要なら Bot API を使います。

以降で、設定画面の位置と JSON の書き方、そして 429 を出さないための運用設計を具体的に見ていきます。Webhook そのものの仕組みから確認したい場合はIncoming Webhookとは？仕組みとSlack・Discordでの使い方を解説を先に読むと、LINE WORKS 固有の話に集中できます。

Incoming Webhook アプリの位置づけ｜トークン管理なしで通知を送る仕組み

Incoming Webhook アプリは、LINE WORKS のアプリディレクトリで配布されているチャットボット型のアプリです。発行された URL に HTTP リクエストを投げると、その URL に紐づいたトークルームへメッセージが投稿されます。方向は外部システムから LINE WORKS への一方通行だけです。

Bot API との違い｜アクセストークンの発行と更新が不要

LINE WORKS で外部システムから通知を送る従来の方法は、Developer Console で Bot を登録し、Service Account と秘密鍵から JWT を組んでアクセストークンを取得し、そのトークンを付けて Bot API のメッセージ送信を呼ぶ、という流れでした。アクセストークンには有効期限があるため、更新処理と失効時のリトライを自前で実装する必要があります。

Incoming Webhook アプリはこの層をまるごと省きます。認証情報は URL そのものに埋め込まれた文字列だけで、更新処理はありません。監視ツールの「通知先 URL」欄に貼るだけで動くのは、この設計のためです。裏を返せば URL が漏れれば誰でもそのトークルームに投稿できるので、URL は認証情報と同じ扱いで管理します。Git リポジトリへの直書きは避け、環境変数やシークレットマネージャに置いてください。

対応プランはフリー・スタンダード・アドバンストの3つ

アプリディレクトリの製品ページには、対応プランとしてフリー、スタンダード、アドバンストが明記されています。有償プラン限定の機能ではないため、無料で使っている環境でも通知連携を試せる状態です。アプリ自体もアプリディレクトリの無料アプリとして提供されています。

アプリ追加からWebhook URL発行までの設定手順

公式ブログが示す導入手順は4段階です。管理者が行う作業とトークルーム側で行う作業が分かれている点だけ、最初に把握しておくと迷いません。

管理者画面でのアプリ追加とBot招待

最初に管理者画面を開き、「管理者画面 > アプリ」から Incoming Webhook アプリを選んで追加します。ここで追加していないと、トークルームで Bot を検索しても出てきません。管理者画面にそもそも項目が見当たらない、という詰まり方が最も多いステップです。管理者権限を持つアカウントでログインしているか、アプリがドメインに追加済みかを先に確認してください。

追加後、通知を受け取りたいトークルームに Incoming Webhook Bot を招待します。招待した直後に Bot からメッセージが届き、そこから Webhook リスト画面に入れます。

チャンネルID取得とWebhookリストでのURL発行

Webhook URL は、どのトークルームに投稿するかを「チャンネルID」で紐づけます。チャンネルIDの取得先はトークルームのメニューです。取得したら、トークルーム下部のメニューにある「Webhook リスト」から一覧画面を開き、「追加」でタイトルとチャンネルIDを指定します。

登録が完了すると、次の形式の Webhook URL が発行されます。

https://webhook.worksmobile.com/message/xxxxxxxxxxxxxxxxx

あとはこの URL を外部サービスの通知先として設定すれば連携は完了です。ここで指定したタイトルは、送信時に title を省略した場合の既定値としても使われます。

通知リクエストの仕様｜JSON本文・ボタン・メンションの書き方

発行された URL に対して POST するだけで投稿されます。公式ブログや他社の導入解説は設定手順までで終わっているものが多いのですが、実務で詰まるのはむしろこの送信フォーマットの側です。

最小構成は body.text の1フィールドだけ

必須なのは body オブジェクト内の text のみです。動作確認は curl だけで完結します。

curl -X POST https://webhook.worksmobile.com/message/xxxxxxxxxxxxxxxxx \
  -H 'Content-Type: application/json' \
  -d '{"body":{"text":"ディスク使用率が90%を超えました"}}'

成功すると HTTP 200 が返り、ボディは {"code": 200, "description": "success"} の固定形です。レスポンスヘッダーには現在のレート消費状況が付きます。失敗時の 400 BadRequest には3つの理由があり、公式ドキュメントは invalid parameter、missing parameter、invalid webhook URL を挙げています。3つ目があるおかげで、URL の打ち間違いや削除済み URL への POST も 400 として切り分けられます。

title と button を付けた実用フォーマット

通知として使うなら、見出しにあたる title と、対応先へ飛ばす button を添えると一次対応が速くなります。フィールドの構成は次のとおりです。

公式ドキュメントのサンプルに沿って組むと、リクエストボディはこうなります。

{
  "title": "問い合わせフォーム",
  "body": {
    "text": "新しい問い合わせが届きました。"
  },
  "button": {
    "label": "管理画面を開く",
    "url": "https://example.com/admin"
  }
}

button 自体は任意ですが、使う場合は label と url の両方が必須です。片方だけの JSON は 400 の理由のうち missing parameter に該当します。

メンション記法での担当者呼び出し

body.text の中ではメンションが使えます。記法は <m userId="[email protected]"> で、userId には LINE WORKS のユーザーIDを入れます。

{
  "body": {
    "text": "<m userId=\"[email protected]\"> 障害アラートを確認してください。"
  }
}

JSON の文字列内にダブルクォートが入るため、エスケープ漏れが起きやすい箇所です。シェルから直接叩くときは、外側をシングルクォートで囲んで内側の \" をそのまま渡します。監視アラートを夜間に飛ばす運用では、重大度が一定以上のときだけメンションを付けると通知疲れを避けられます。

Webhook URL 5個と120 requests/minという2つの上限

ここが導入設計で最も効いてくる制約です。公式ドキュメントは2つの上限を明記していますが、性質がまったく違います。

全Webhook URLで共有される1枠のレート制限

Webhook URL は5つまで発行できます。この5という数字は素直に理解できます。問題はもう一方です。Rate Limit は「利用する LINE WORKS ドメインあたり 120 requests/min」であり、ドキュメントは「これは Webhook URL 単位にかかる制限ではありません。1 つの Rate Limit を全ての Webhook URL で共有します」と明示しています。

つまり URL を5本発行しても総量は増えません。5本を均等に使えば、実効レートは1本あたり平均24 requests/min まで落ちます。部署ごとにトークルームを分けて Webhook URL を割り当てる設計は、通知の整理には有効でも、流量の分散にはまったく効かないということです。ここを URL 単位の制限だと誤読したまま監視基盤をつなぐと、障害発生時にアラートが集中した瞬間、無関係な部署の通知まで一緒に落ちます。

429発生時のRateLimitヘッダーと復帰の待ち方

上限を超えると 429 Too Many Requests が返ります。復帰タイミングを勘で待つ必要はありません。レスポンスヘッダーに残量とリセットまでの秒数が入っているためです。

送信側では RateLimit-Reset の秒数だけ待って再送するのが最も確実です。固定間隔のリトライを入れると、混雑が続いている間ずっと 429 を踏み続けます。

アラート集中を通すための送信側の設計

120 requests/min は1秒あたり2件です。平常時の業務通知なら十分ですが、監視システムの障害時バーストは簡単にこれを超えます。送信側の手当てを入れておくと実害を避けられます。

まず、同種のアラートは送信側で集約します。「サーバー20台がダウン」を20通ではなく1通にまとめれば、それだけで消費は20分の1です。次に、通知の重大度でフィルタします。Warning レベルまで LINE WORKS に流す設計は、枠を使い切るうえに読まれません。最後に、429 を受けたリクエストはキューに戻し、RateLimit-Reset 経過後に再送します。捨ててはいけない通知ほど、この再送経路を用意しておく価値があります。リトライや冪等性の考え方はWebhookの実装方法と作り方｜手順と署名検証・リトライ・冪等性を解説で整理しています。

Incoming Webhookで足りる条件とBot APIが必要な条件

結論から言えば、通知を「送るだけ」ならこのアプリで十分です。ただし要件しだいでは最初から Bot API を選ぶべきで、Incoming Webhook で作り込んでから移行するのは二度手間になります。

Bot APIへ切り替えるべき4つの条件

公式ドキュメントは非対応の機能を3点挙げています。「トークルームからのメッセージの送信には対応していません」「画像を含むファイルの送信や、高度なメッセージ形式には対応していません」「リッチメニュー / 固定メニューのカスタマイズはできません」。1点目はユーザーの発言を外部システムへ取り出せないという意味で、これがある限り発言に応答する双方向のチャットボットは作れません。承認フローのように、投稿したメッセージへの返信を受けて処理を分岐させたい用途は、この時点で候補から外れます。2点目により、ボタン1つを超えるカルーセルなどのリッチテンプレートも使えません。

4つ目の条件は数の問題です。通知先トークルームが6室以上になる場合、URL の上限が5つである以上、10部署に個別通知したい要件は構造的に満たせません。ドメイン全体で 120 requests/min を超える設計になる場合も同じ理由で対象外です。

Incoming Webhookで完結する3条件

通知先が5室以内に収まり、送るのはテキストとリンクだけで、流量が毎分120件を超えない。この3条件を満たすなら、Bot API を選ぶ理由はほとんどありません。アクセストークンの更新という運用負債を抱え込むだけになります。LINE WORKS 上の他機能との組み合わせを検討しているなら、LINE WORKS AiNoteとは｜料金・60分制限・AI学習とv2.9新機能も合わせて確認しておくと、どこまでを標準機能でまかなえるかが見えます。

ノーコードツールと監視ツールからの通知連携

Webhook URL は単なる HTTP エンドポイントなので、「任意の URL に POST できる」機能を持つツールならすべて連携先になります。

Zapier・Make・IFTTTからのPOST設定

プログラムを書かずに済ませるなら、Zapier、Make、IFTTT といったノーコードの連携ツールが最短です。トリガー側に Google フォームの回答受信やスプレッドシートの行追加を置き、アクションに Webhook の POST を設定して、ボディに前述の JSON を貼るだけで動きます。IoT ゲートウェイの Gravio のように、センサー検知をトリガーに任意の Webhook URL を叩ける製品も同じ形式でつながります。

監視ツール連携で先に確認すべきペイロード編集の可否

監視系では、アラートの通知先として任意の Webhook URL を登録できる製品が対象です。ManageEngine の OpManager のように、公式ナレッジベースで LINE WORKS への通知手順を公開しているツールもあります。この場合に注意すべきなのは、多くの監視ツールが独自のペイロード形式で POST してくる点です。LINE WORKS 側は body.text を含む JSON しか受け付けないため、ツール側でリクエストボディのテンプレートを編集できるかどうかを先に確認してください。編集できない製品では、間に変換用のエンドポイントを1つ挟む必要があります。

チャットツール側の選定から検討している段階であれば、Slack・Discord・LINEの違いを比較｜料金・音声通話・セキュリティで選ぶチャットツールで通知連携以外の判断材料もそろえられます。

よくある質問

Incoming Webhook アプリは無料プランでも使えますか？

使えます。アプリディレクトリの製品ページには対応プランとしてフリー、スタンダード、アドバンストが記載されており、フリープランも対象です。アプリ自体もアプリディレクトリの無料アプリとして提供されているため、追加費用は発生しません。ただしプランに関係なく、Webhook URL 5つ・120 requests/min という上限は共通で適用されます。

Webhook URL は6つ以上発行できますか？

できません。追加可能な Webhook URL は5つまでと公式ドキュメントに明記されています。通知先トークルームが6室以上必要な場合は、複数の通知を1つのトークルームに集約するか、Bot API での実装に切り替えることになります。なお URL を増やしても Rate Limit の総量は変わりません。120 requests/min はドメイン全体で共有される1枠です。

管理者画面に Incoming Webhook の項目が見つかりません。どうすればよいですか？

アプリの追加は「管理者画面 > アプリ」から行います。この画面にアクセスできるのは管理者権限を持つアカウントだけなので、一般メンバーのアカウントでログインしている場合は項目自体が表示されません。管理者にアプリの追加を依頼してください。アプリがドメインに追加されていない状態では、トークルームで Incoming Webhook Bot を検索しても候補に出てきません。

429 が返るときはどう対処すればよいですか？

429 Too Many Requests は、ドメイン全体で 120 requests/min を超えたときに返ります。レスポンスヘッダーの RateLimit-Reset にリセットまでの残り秒数が入っているので、その秒数だけ待ってから再送してください。恒常的に超えるなら、送信側で同種アラートを1通に集約する、重大度でフィルタして送信件数自体を減らす、という順で対処します。

LINE WORKS の Incoming Webhook は廃止予定ですか？

2026年8月時点で、LINE WORKS Developers の公式ドキュメントに提供終了や非推奨の告知は掲載されていません。「incoming webhook 廃止」という検索が増えているのは Microsoft Teams 側の事情で、Teams の Office 365 コネクタ経由の Incoming Webhook は 2026年5月18日から22日にかけて無効化され、Power Automate ベースの Workflows への移行が案内されました。両者は名称が同じだけの別サービスです。

関連記事

• Incoming Webhookとは？仕組みとSlack・Discordでの使い方を解説
• Webhookとは？読み方・仕組み・APIとの違いを実際のHTTPリクエストで解説
• Webhookの実装方法と作り方｜手順と署名検証・リトライ・冪等性を解説
• LINE WORKS AiNoteとは｜料金・60分制限・AI学習とv2.9新機能
• Slack・Discord・LINEの違いを比較｜料金・音声通話・セキュリティで選ぶチャットツール