ガイド July 4, 2026

LINE Rich Menu Insightsは分析用であり、受信ルーティングではない

7月1日、LINEはMessaging APIで作成したrich menuについて、表示回数、クリック数、日別のインサイトを取得できるようになったと発表しました。その約1か月前には、同じrich menu領域で別の変更も確定しています。2026年5月26日から、Get rich menu list エンドポイントのレート制限は毎秒2000リクエストから毎秒10リクエストへ変更されました。

この2つは、分析と設定管理の更新として見れば自然です。プロダクトチームはどのrich menu領域が押されているかを知りたい。運用チームは公開中のメニューを確認したい。どちらもカスタマーサポートのメッセージ処理のホットパスに入れるべき処理ではありません。危険なのは、小規模チームがLINE公式のMessaging APIをライブのルーティング層として扱い、1件ごとの問い合わせ判断に向かないエンドポイントをポーリングし始めることです。

LINEメッセージを受信してSlack、CRM、サポートキューへ流し、あとでWhatsAppやZaloも追加したいなら、アーキテクチャは2つのループに分けるべきです。ひとつは低頻度のLINE公式分析ループ、もうひとつはイベント駆動の受信会話ループです。

LINEで何が変わったのか

7月1日の更新では、Messaging APIで作成したrich menu向けに Get rich menu insight totals と Get rich menu insight by day が追加されました。これまでは、同種の統計はLINE Official Account Managerで作成したrich menuについて管理画面から見るのが中心でした。今回の追加により、Messaging APIでメニューを作るチームも、手動ダッシュボードを開かずにレポートデータを取得できます。

5月26日の更新は、より運用寄りです。LINEは Get rich menu list のレート制限を毎秒2000リクエストから毎秒10リクエストへ変更しました。この告知では、他のエンドポイントのレート制限に変更はないとされています。

大事なのは、毎秒10回で管理画面に足りるかどうかではありません。多くの場合は足ります。大事なのは、rich menuのメタデータがキャッシュすべき設定面であり、高頻度の依存先ではないと明確になったことです。ユーザーからメッセージが届くたびにrich menuの状態を確認しているなら、その設計は本来の目的に合っていません。

3つのループ、3つの速度

LINEサポートの構成では、別々に扱うべき3つの関心事が混ざりがちです。

分析ループ。 プロダクトやマーケティングの担当者がrich menuの表示数や日別クリックを読みます。これは1時間ごと、または1日ごとで十分です。失敗しても後で再試行できます。「昨日どのメニュー項目が押されたか」に答える処理だからです。

設定ループ。 エンジニアリング側が現在のrich menu listを読み、メニューIDを保存し、変更があれば内部状態を更新します。これはキャッシュされるべきです。新しい10 rpsの制限は、設定読み取りをメッセージ処理のホットパスから外すべきだという分かりやすいサインです。

受信ルーティングループ。 サポートは、顧客が今メッセージを送ったこと、どのアカウントが受けたか、送信者は誰か、テキストまたはメディアの内容は何か、どこへ回すべきかをすぐに知る必要があります。このループはイベント駆動であるべきで、rich menu list、insight、レポート更新を待つべきではありません。

UnifyPortは3つ目のループに入ります。LINE公式の分析エンドポイントを置き換えるものではありません。LINE、WhatsApp、Telegram、TikTok、Zalo、Xの受信メッセージを、同じ標準イベント形式のwebhook-firstな層として扱えるようにします。日本ではLINEが特に重要ですが、海外顧客や越境チームでは複数チャネルが同時に並びます。

受信パスの形

UnifyPortでは、LINEメッセージは message.received webhookイベントとしてサーバーへ届きます。配信はあなたのエンドポイントへのHTTP POSTです。対応プロバイダー間でイベントの外枠は同じです。id、type、provider、account_id、occurred_at、data を使います。

LINEの受信テキストメッセージは、次のように扱えます。

{
  "id": "evt_4f1b9c2a70",
  "type": "message.received",
  "provider": "line",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-07-04T02:18:30Z",
  "data": {
    "conversation": { "id": "U4af2c891", "type": "user" },
    "sender": { "id": "U4af2c891", "type": "user", "name": "Mika Tanaka" },
    "message": {
      "id": "msg_20260704_001",
      "type": "text",
      "text": "Can you check whether my appointment moved to Monday?",
      "direction": "inbound",
      "sent_at": "2026-07-04T02:18:29Z"
    },
    "event": { "kind": "message_received" }
  }
}

webhookエンドポイントは message.received を購読できます。標準イベント全体を受けたい場合は ["*"] も使えます。署名を有効にすると、各配信には X-Device-Timestamp と X-Device-Signature が含まれます。署名は、タイムスタンプ、ドット、raw request bodyをつなげた値に対するHMAC-SHA256の16進文字列で、エンドポイントの signing_secret によって生成されます。

ルーティングサービスのルールは単純です。署名を検証し、イベントIDで重複排除し、必要なpayloadを保存し、その後にメッセージを回す。rich menu insight呼び出しは、この経路に入れません。

LINE公式インサイトの置き場所

新しいinsightエンドポイントは有用です。ただし、答える質問が違います。

「サポート」領域が「料金」領域より多くクリックされたか、平日と週末の反応がどう違うか、季節メニューを続けるべきかを判断するために使えます。スケジュールは低頻度にします。通常は毎日、キャンペーン中でもせいぜい毎時です。

ユーザーがサポートを待っているかどうかを推測するために使わないでください。rich menuのクリックはメッセージではありません。日別インサイトレポートはキューではありません。10 rps制限のある設定エンドポイントは、ルーティングのプリミティブではありません。

分け方はシンプルです。

関心事	最適なデータソース	タイミング
rich menuの表示とクリックレポート	LINE rich menu insightエンドポイント	毎時または毎日
現在のrich menu設定	LINE rich menu listエンドポイント	キャッシュ、ホットパス外
ライブの顧客メッセージ	UnifyPort `message.received` webhook	即時イベント
複数チャネルのルーティング	UnifyPort標準webhook外枠	各プロバイダーで同じhandler

この分離はチームを壊れにくくします。分析ジョブが失敗しても、サポートキューはメッセージを受け取ります。rich menuレポートが遅れても、CRMは受信会話を記録します。あとでWhatsAppやZaloを追加しても、ルーティングループは同じままで、分析ループだけがLINE固有です。

実用的な構成

小規模チームの構成は複雑である必要はありません。

UnifyPortのwebhookエンドポイントを登録し、signing_secret を設定し、message.received を購読します。handlerでは X-Device-Signature を検証し、raw eventを保存し、provider、account_id、data.sender.id、data.message.type でルーティングします。

LINE公式のrich menuレポートは別のスケジュールジョブで処理します。そのジョブはinsightエンドポイントを呼び、指標をデータウェアハウスやスプレッドシートに書き込みます。受信ルーティングをブロックしてはいけません。rich menu listのキャッシュを更新してもよいですが、サポートhandlerからは読み取り専用の情報にします。

サポート担当者が返信する場合、送信経路は明示的です。POST /v1/messages に対象アカウントとメッセージ本文を渡します。受信イベントは、誰が何をいつ言ったかの事実として残ります。

結果として、運用モデルは明確になります。

LINE公式APIはLINE固有の分析を担当する。
UnifyPortは複数プロバイダーの標準化された受信配信を担当する。
サポートbackendはメッセージ経路で公式設定エンドポイントをポーリングしない。
別のメッセージアプリを追加しても、変わるのはデータであってアーキテクチャではない。

本当の教訓

LINEの7月1日のinsight更新は、rich menuの成果を見たいチームには良いニュースです。5月26日のレート制限変更は、別の境界も示しています。rich menu設定をリアルタイムメッセージ基盤として扱ってはいけません。

LINEでの仕事が主にマーケティング分析なら、新しい公式insightエンドポイントを使えばよいです。顧客対応が中心なら、受信メッセージはイベント駆動にします。LINE、WhatsApp、Zalo、Telegram、TikTok、Xの顧客メッセージを同時に受けるチームなら、ひとつのwebhook形状にそろえ、すべてのプラットフォームを同じルーティングパイプラインに入れるべきです。

分析はポーリングできます。顧客メッセージは到着すべきです。