LINE WORKS Incoming Webhookの使い方：URL発行・送信コード・120 requests/minの共有上限と届かない時の確認

LINE WORKS の Incoming Webhook アプリは、発行した URL に JSON を POST するだけで外部システムからトークルームへ通知を送れる無料アプリです。Bot API のようなアクセストークンの取得・更新は要りません。設定は管理者画面でのアプリ追加から URL 発行までの4段階で、送信に必須なのは body.text の1項目だけです。一方で、レート制限 120 requests/min は URL ごとではなくドメイン全体で1枠を共有するため、監視アラートを何本もの URL に分けて流しても上限は増えません。この記事では設定手順、curl・Python・Google Apps Script・PHP の送信コード、400 と 429 の切り分け、通知が届かないときの確認順、Bot API へ切り替える条件を順に説明します。

まとめ

• 設定は4段階です。管理者画面 > アプリ で Incoming Webhook を追加し、通知先のトークルームに Incoming Webhook Bot を招待し、トークルームのメニューでチャンネルIDを取得し、Webhook リスト画面で URL を発行します。
• 送信は https://webhook.worksmobile.com/message/{発行文字列} へ Content-Type: application/json で POST します。必須は body.text だけで、title と button は任意です。
• 上限は Webhook URL 5つと、ドメインあたり 120 requests/min の2つです。後者は全 URL で共有するので、5本に分けると1本あたりの平均は24 requests/min になります。
• 対応プランはフリー・スタンダード・アドバンストで、アプリ自体も無料です。
• ユーザーの発言を受け取る双方向の Bot、画像やファイルの送信、リッチメニューが必要なら、最初から Bot API で作ります。
• 届かないときは、レスポンスの description を見ます。invalid webhook URL なら URL の削除や打ち間違い、missing parameter なら body.text の欠落、429 ならドメイン全体の流量超過です。

Webhook という仕組み自体や、Slack・Discord など他サービスとの違いから確認したい場合はIncoming Webhookとは？Slack・Discord・Teams・Google Chatの使い方と違い【2026年版】を先に読むと、ここからの LINE WORKS 固有の話が追いやすくなります。

Incoming Webhook アプリの位置づけと対応範囲

Incoming Webhook アプリは、LINE WORKS のアプリディレクトリで配布されているチャットボット型のアプリです。LINE WORKS Developers の公式ドキュメントは「本アプリで発行した Webhook URL へ HTTP リクエストを送ることで、通知先のトークルームに Incoming Webhook Bot からメッセージが届きます」と説明しています。通知の向きは外部システムから LINE WORKS への一方通行です。

Bot APIとの違い：トークンの取得・更新が不要

従来の方法で外部システムから通知するには、Developer Console で Bot を登録し、Service Account と秘密鍵で JWT を組んでアクセストークンを取得し、そのトークンを付けて Bot API を呼ぶ必要がありました。JWT 方式の認証ドキュメントによると Access Token の有効期限は Developer Console の設定で1時間または24時間、Refresh Token は90日です。つまり Bot API で通知を続けるには、トークンの更新処理と失効時の再取得を自前で持ち続けることになります。

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

Bot API の上限は Rate Limit のドキュメントにある値で、フリープランは1 API あたり 60 requests/min、スタンダード・アドバンストは 240 requests/min です。フリープランなら Incoming Webhook の 120 requests/min の方が多く送れ、有償プランなら逆転します。公式ドキュメントは「Incoming Webhook アプリは LINE WORKS API とは分離されているため、そちらの API の制限には影響しません」とも書いているので、平常の通知は Webhook、障害時の大量送信は Bot API と分ける構成も取れます。ただし Bot API も、30分以上連続して呼ぶなら上限の半分以下が目安で、同時に呼べるのはドメイン全体の API 合計で5スレッドまでです。

対応プランと料金

アプリディレクトリの製品ページには、対象プランとしてフリー、スタンダード、アドバンストが記載されています。公式ドキュメントも「アプリディレクトリの無料アプリとして提供しています」と明記しており、アプリの利用料はかかりません。費用が発生するのは LINE WORKS 本体のプラン料金だけです。公式ドキュメントは 5 URL と 120 requests/min をプラン別に分けずに記載しています。

LINE の Messaging API・LINE Notify とは別物

個人向けの LINE と LINE WORKS は別のサービスで、API も共通ではありません。LINE 公式アカウントの Messaging API にも Webhook がありますが、こちらはユーザーの発言などのイベントを LINE 側から自分のサーバーへ送る仕組みで、向きが Incoming Webhook と逆です。また、発行したアクセストークンを付けて POST するだけで LINE に通知できた LINE Notify は、公式の終了告知のとおり2025年3月31日にサービスを終了しました。社内の通知先を LINE WORKS に移すなら Incoming Webhook がいちばん近い代わりになります。LINE のまま続けるなら Messaging API への移行が必要で、手順はLINE Notify終了後の移行実装｜Messaging APIへの置き換え手順と通知コスト試算で扱っています。

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

作業は管理者が行う部分とトークルームで行う部分に分かれ、管理者権限のないアカウントでは最初の手順で止まります。

管理者画面からのアプリ追加

LINE WORKS 公式ブログの手順では、まず「管理者画面 > アプリ」から Incoming Webhook アプリを選んで追加します。管理者画面は管理者権限のあるアカウントでないと開けません。一般メンバーのアカウントで探しても項目が出てこないのはこのためです。

Botの招待とチャンネルIDの取得

アプリを追加したら、通知を受け取りたいトークルームに Incoming Webhook Bot を招待します。公式の手順ではアプリの追加が Bot 招待より先なので、Bot が見つからないときはまずアプリが追加済みかを確認します。続いて、トークルームのメニューにある「チャンネルID」からIDを控えます。Webhook URL はこのチャンネルIDで投稿先のトークルームと結び付きます。

Webhook リストでのURL発行

トークルームの下部に表示されるメニューの「Webhook リスト」を開き、「追加」からタイトルとチャンネルIDを入力すると、次の形式の URL が発行されます。

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

ここで入れたタイトルは、送信時に title を省略したときの見出しとしても使われます。追加できる Webhook URL は5つまでなので、部署ごとに乱発せず、通知の種類ごとにまとめて割り当ててください。

通知を送るリクエストの書き方とコード例

最小構成は 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"} が返り、レスポンスヘッダーに現在のレート消費状況が付きます。

title・button・メンションを付けた通知

通知として運用するなら、見出しの title と、対応画面へ飛ばす button を付けると、通知から対応画面へ1タップで移れます。

メンションは body.text の中に <m userId="[email protected]"> の形で書きます。JSON の文字列の中にダブルクォートが入るので、\" へのエスケープ漏れに注意してください。

{
  "title": "監視アラート",
  "body": {
    "text": "<m userId=\"[email protected]\"> web-01 の応答が5分間ありません。"
  },
  "button": {
    "label": "監視画面を開く",
    "url": "https://example.com/monitor"
  }
}

button を付けるなら label と url の両方が要ります。片方だけでは 400 エラーになります（公式は両方を required としています）。夜間の通知では、重大度が高いときだけメンションを付けると通知疲れを防げます。

Python・Google Apps Script・PHPの送信コード

Python は標準ライブラリだけで書けます。次のコードは 429 を受けたら RateLimit-Reset の秒数（ヘッダーが無ければ60秒）待って再送し、それ以外のエラーはレスポンス本文ごと例外にします。存在しない URL に向けて実行すると 400 {"code":400,"description":"invalid webhook URL "} で止まり、429 を1回返すテスト用サーバーに向けると、待機後の再送で 200 を受け取ることを Python 3.9 で確認しました。

import json
import os
import time
import urllib.error
import urllib.request

URL = os.environ["LINEWORKS_WEBHOOK_URL"]


def notify(text, title=None, retries=3):
    payload = {"body": {"text": text}}
    if title:
        payload["title"] = title
    data = json.dumps(payload).encode("utf-8")
    for attempt in range(retries):
        req = urllib.request.Request(
            URL, data=data, method="POST",
            headers={"Content-Type": "application/json"},
        )
        try:
            with urllib.request.urlopen(req, timeout=10) as res:
                return json.load(res)
        except urllib.error.HTTPError as e:
            if e.code == 429 and attempt < retries - 1:
                # ヘッダー名の大文字小文字は区別されない
                time.sleep(max(1, int(e.headers.get("RateLimit-Reset", "60"))))
                continue
            raise RuntimeError(f"{e.code} {e.read().decode()}") from e
    raise RuntimeError("429 が続いたため送信を中止しました")


if __name__ == "__main__":
    print(notify("ディスク使用率が90%を超えました", title="監視アラート"))

Google フォームやスプレッドシートの更新を通知するなら Google Apps Script が手軽です。URL はコードに書かず、スクリプトプロパティに入れておきます。muteHttpExceptions を付けないと、400 の本文を読む前に例外で止まります。

function notifyLineWorks(text) {
  const url = PropertiesService.getScriptProperties().getProperty('LINEWORKS_WEBHOOK_URL');
  const res = UrlFetchApp.fetch(url, {
    method: 'post',
    contentType: 'application/json',
    payload: JSON.stringify({ body: { text: text } }),
    muteHttpExceptions: true,
  });
  if (res.getResponseCode() !== 200) {
    throw new Error(res.getResponseCode() + ' ' + res.getContentText());
  }
}

PHP では cURL 拡張を使います。日本語をそのまま送るために JSON_UNESCAPED_UNICODE を付けています（付けなくても \uXXXX 形式の JSON として有効です）。PHP 8.5.8 で実行し、存在しない URL では 400 の本文を標準エラーに出して終了コード1で止まることを確認しました。

<?php
$url = getenv('LINEWORKS_WEBHOOK_URL');
$payload = json_encode(
    ['body' => ['text' => '新しい問い合わせが届きました']],
    JSON_UNESCAPED_UNICODE
);

$ch = curl_init($url);
curl_setopt_array($ch, [
    CURLOPT_POST => true,
    CURLOPT_HTTPHEADER => ['Content-Type: application/json'],
    CURLOPT_POSTFIELDS => $payload,
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_TIMEOUT => 10,
]);
$body = curl_exec($ch);
$status = curl_getinfo($ch, CURLINFO_HTTP_CODE);
$err = curl_error($ch);

if ($status !== 200) {
    fwrite(STDERR, "LINE WORKS への送信に失敗: {$status} {$body} {$err}\n");
    exit(1);
}
echo $body, "\n";

どの言語でも、失敗時はステータスコードとレスポンス本文の両方をログに残してください。後述する原因の切り分けは、この本文の description が手がかりになります。送信側の再送で同じ通知を二重に出さない考え方はWebhookの作り方と実装方法｜受信側の署名検証・冪等性と送信側の再送をNode.js・Pythonで解説が詳しいです。

Webhook URL 5個と120 requests/minの上限

2つの上限はどちらも公式ドキュメントに明記されていますが、性質がまったく違います。

全URLで1枠を共有するレート制限

注意が要るのはレート制限です。公式ドキュメントは「利用する LINE WORKS ドメインあたり 120 requests/min」としたうえで、「これは Webhook URL 単位にかかる制限ではありません。1 つの Rate Limit を全ての Webhook URL で共有します」と書いています。同じページには、URL を2本使えば1本あたり平均60、5本なら平均24 requests/min になるという換算表まで載っています。

部署ごとに URL を分けても流量は増えません。URL 単位の制限だと思い込んで監視基盤をつなぐと、障害でアラートが集中した瞬間に、無関係な部署の通知まで巻き込んで 429 で落ちます。

429とRateLimitヘッダーの読み方

上限を超えると 429 Too Many Requests が返ります。成功時のレスポンスヘッダーには次の4項目が付くので、残り回数を見ながら送信を絞れます。

webhook.worksmobile.com は HTTP/1.1 で接続してもヘッダー名を小文字（content-type など）で返します。LINE WORKS の Rate Limit ドキュメントも「レスポンスヘッダーのフィールド名は大文字小文字を区別せずに扱ってください」としているので、ヘッダー名を完全一致の文字列で探さず、大文字小文字を区別しない取り出し方にしてください。公式は RateLimit ヘッダーを成功時のレスポンスとして載せており、429 のときに付くかは書いていません。再送は、ヘッダーがあれば RateLimit-Reset の秒数、無ければ1分程度待ってから行います。短い固定間隔のリトライでは、混雑が続く間ずっと 429 を踏み続けます。

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

120 requests/min は1秒あたり2件で、監視システムの障害時には簡単に超えます。手当ては効果の大きい順に3つです。

1つ目は、同種のアラートを送信側で1通にまとめることです。サーバー20台のダウンを20通ではなく1通で送れば、消費は20分の1になります。2つ目は、重大度で絞ることです。Warning まで流すと枠を使い切るうえ、読まれなくなります。3つ目は、429 を受けた通知をキューに戻し、時間を置いて再送することです。捨ててはいけない通知ほど、この再送経路を用意する価値があります。

通知が届かない・項目が出てこないときの確認順

詰まるのは、画面に項目が出ない段階か、送信がエラーで返る段階のどちらかです。

管理者画面・トークルームに項目が出ない原因

「管理者画面 > アプリ」に項目が無いときは、ログイン中のアカウントに管理者権限があるかを確かめます。権限が無ければ管理者にアプリの追加を依頼するしかありません。トークルームで Bot が見つからないときは、公式の手順どおりアプリの追加が先に済んでいるかを確認します。Webhook リストは Bot を招待したトークルームの下部メニューから開くので、メニューが見えなければ招待の有無を確かめてください。

400・429・500のレスポンス別の切り分け

公式ドキュメントが挙げる 400 の理由は3つで、本文の description を見れば原因の見当が付きます。表の500は公式に載っておらず、実測で得た値です。

2026年11月2日に、存在しない URL へ JSON を変えながら POST して確かめたところ、正しい本文・必須項目の欠けた本文・JSON でない文字列のどれを送っても、返ったのは {"code":400,"description":"invalid webhook URL "} でした。URL の検証が本文の検証より先に行われるため、URL が無効なうちは本文の誤りがエラーとして見えません。この 400 には RateLimit 系のヘッダーも付きませんでした。同じ URL に GET や PUT を送ると 500 の internal server error が返ります。公式の Request Method は POST だけなので、ブラウザで URL を開いても動作確認にはなりません。

監視ツールやフォームサービスが自前の形式で POST してくる場合も、body.text が無いので 400 で落ちます。送り元の設定画面でリクエスト本文を編集できるかを確認し、できなければ間に変換処理を1つ挟みます。AWS ならEventBridge 入力トランスフォーマーの使い方：InputTemplateでSNS・Slack通知を整形するの方法で、イベントを LINE WORKS の形式に組み替えてから送れます。

Incoming WebhookとBot APIの選び分け

要件によっては最初から Bot API を選ぶべきで、Webhook で作り込んでから移行すると二度手間になります。

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

公式ドキュメントは非対応の機能として、トークルームからのメッセージの送信、画像を含むファイルの送信や高度なメッセージ形式、リッチメニュー・固定メニューのカスタマイズの3つを挙げています。1つ目は、ユーザーの発言を外部システムへ取り出せないという意味です。投稿への返信を受けて処理を分ける承認フローや、質問に答えるチャットボットは作れません。2つ目により、ボタン1つを超えるリッチなメッセージも送れません。

数の条件もあります。通知先のトークルームが6室以上になるなら、追加できる URL 5つの上限に当たる可能性が高く、ドメイン全体で毎分120件を恒常的に超えるなら流量が足りません。どちらかに当てはまるなら Bot API を選びます。

Incoming Webhookで完結する条件

通知先が5室以内で、送るのはテキストとリンクだけで、流量が毎分120件に収まる。この3つを満たすなら、Bot API を選ぶ理由はほとんどありません。1時間または24時間で切れるトークンの更新処理を抱え込むだけです。どちらで作るか判断が付かない、既存の業務システムとの連携まで含めて設計したいといった場合は、API開発・システム連携の支援もご相談いただけます。

Zapier・Make・IFTTTなどノーコードツールからの連携

Webhook URL は普通の HTTP エンドポイントなので、任意の URL に POST できるツールならどれでも送り元になります。公式ドキュメントも IFTTT、Zapier、Make との組み合わせを想定しています。トリガーに Google フォームの回答やスプレッドシートの行追加を置き、アクションで Webhook の POST を選んで、本文に body.text を含む JSON を書けば動きます。Zapier では Webhook の POST 1回が1タスクとして数えられるので、通知件数を見積もりに入れてください。Zapier の課金単位はZapierとは？読み方・できること・料金とタスク課金の仕組み【2026年版】で解説しています。監視ツールから送る場合は、前章のとおり本文のテンプレートを編集できるかを先に確かめてください。

よくある質問

Incoming Webhook アプリに料金はかかりますか？

かかりません。アプリディレクトリの無料アプリで、対象プランはフリー・スタンダード・アドバンストです。費用は LINE WORKS 本体のプラン料金だけです。

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

できません。公式ドキュメントの上限は5つです。通知先が6室以上必要なら、通知をトークルームにまとめるか Bot API で実装します。

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

管理者画面は管理者権限のあるアカウントでしか開けません。一般メンバーなら、管理者に「管理者画面 > アプリ」からの追加を依頼してください。

LINE Notify の代わりに使えますか？

送り先を LINE WORKS のトークルームにしてよいなら使えます。1本の POST で通知できる点は同じで、LINE Notify と違ってトークンも要りません。個人の LINE に送り続けたい場合は Messaging API へ移行します。

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

2026年11月時点で、LINE WORKS Developers の公式ドキュメントに提供終了や非推奨の告知はありません。「incoming webhook 廃止」で見つかる情報は Microsoft Teams のものです。Microsoft 365 Developer Blogは、Teams の Office 365 コネクタを2026年5月18日から22日にかけて無効化すると告知し、Teams の Webhook は Power Automate の Workflows へ移っています。LINE WORKS とは名前が同じだけの別サービスです。

関連記事

• Incoming Webhookとは？Slack・Discord・Teams・Google Chatの使い方と違い【2026年版】
• Webhookとは？読み方・仕組み・APIとの違いを実際のHTTPリクエストで解説
• Webhookの作り方と実装方法｜受信側の署名検証・冪等性と送信側の再送をNode.js・Pythonで解説
• Slack Incoming Webhookの実装手順：URL発行・Block Kit整形・SDK送信と429対策
• LINE Notify終了後の移行実装｜Messaging APIへの置き換え手順と通知コスト試算