比較 July 11, 2026

LINE Bot MCP Server はツール層であり、クロスチャネルの受信箱ではない

LINE は AI Agent に扱いやすい方向へ進んでいます。公開されている LINE Bot MCP Server は、LINE Messaging API と LINE Official Account に AI Agent を接続する Model Context Protocol server として説明されています。提供される tool には、text や Flex message の push、broadcast、profile の取得、message quota の確認、rich menu 管理、follower IDs の取得などがあります。リポジトリは preview version とも明記しています。これは正しい位置づけです。実験や operator tool には便利ですが、すべてのサポートアーキテクチャを置き換えるものではありません。

LINE の developer surface も、AI tool が読みやすい形になっています。Messaging API reference には “Copy for LLM” と Markdown view があり、2026 年の LINE docs news では一部の documentation と reference が GitHub 上の Markdown として公開されています。さらに 2026 年 7 月 1 日には、Messaging API で作成した rich menu の statistics を取得できるようになったことも発表されました。AI builder にとって、これは明確な流れです。docs、analytics、action API が automation-ready になっています。

ただし、この流れを「AI Agent がそのまま inbox になった」と読んではいけません。MCP は action layer です。inbox は event layer です。チームが LINE、WhatsApp、Telegram、Zalo、TikTok、X から顧客メッセージを受けるなら、最初の境界は署名検証、保存、重複排除、ルーティングであるべきです。AI Agent の判断はその後です。

LINE MCP Server が得意なこと

公式 LINE MCP Server が向いているのは、「AI tool に LINE Official Account を操作させる」仕事です。サポート責任者は、agent に下書き済みメッセージを既知の user へ push させたり、rich menu を作成・確認させたり、quota 使用量を調べたり、profile 情報を取得させたりできます。これは MCP に自然な形です。model が intent を理解し、tool を選び、server が制御された LINE Messaging API call を実行します。

これは LINE の native API model とも合っています。LINE webhook は LINE Developers Console で channel ごとに設定されます。user が Official Account を友だち追加したりメッセージを送ったりすると、LINE Platform は設定された webhook URL へ HTTPS POST request を送ります。media content の取得も LINE の webhook event から始まります。Messaging API reference では、webhook で受け取った message IDs を使って user が送信した content を取得すると説明されています。

LINE だけの product なら、それで十分な場合があります。LINE webhook を使い、MCP server を Claude Desktop、Cline、Cursor、または別の MCP host に接続し、agent を Official Account の境界内で動かします。access token、quota、user ID、role permission、LINE 独自の event shape は扱う必要がありますが、設計としては一貫しています。

どこから inbox ではなくなるのか

クロスチャネルのサポート queue には別の契約が必要です。AI model が動く前に、次の 5 つを確定する必要があります。

Question	Why it matters
この delivery は設定済み endpoint から本当に来たのか	edge は偽造または古い request を拒否しなければならない。
この event はすでに処理済みか	Webhook delivery は at-least-once なので idempotency が必要。
どの account と provider が受信したのか	routing は channel SDK ではなく `account_id` と `provider` に依存する。
どの exact payload を保存するのか	webhook event は inbound traffic の記録。
agent は次に何を許可されるのか	action tools は policy、storage、routing の後で動くべき。

MCP server はこれらを自動的には解決しません。push_text_message tool は公開できますが、normalized audit log ではありません。rich menu data は取得できますが、WhatsApp、Zalo、TikTok、X を LINE webhook event に変換するものではありません。AI Agent の action を助けることはできますが、incoming customer message の最初の境界にすべきではありません。

小さなチームではここが重要です。最初の failure mode は生成品質ではなく運用です。buyer が LINE で問い合わせ、supplier が WhatsApp で返事をし、Vietnam の customer が Zalo を使い、TikTok の購入者が live sale の後に配送を聞きます。必要なのは 6 つの agent ではなく、1 つの信頼できる inbound queue です。

UnifyPort の event layer

UnifyPort では、LINE は WhatsApp、Telegram、TikTok、Zalo、X と同じ inbound stream に接続された account の 1 つです。webhook endpoint を作成し、message.received または ["*"] を subscribe し、signing_secret を設定します。

curl -X POST https://api.unifyport.ai/v1/webhook-endpoints \
  -H "X-Api-Key: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
  "url": "https://support.example.com/webhook",
  "status": "active",
  "subscribed_events": ["message.received"],
  "signing_secret": "<WEBHOOK_SIGNING_SECRET>"
}'

署名付き delivery には X-Device-Timestamp と X-Device-Signature が含まれます。signature は次の文字列に対する hex HMAC-SHA256 digest です。

<X-Device-Timestamp>.<raw request body>

メッセージは標準 event envelope で届きます。

{
  "id": "evt_line_72c9f4a18b",
  "type": "message.received",
  "provider": "line",
  "account_id": "acc_line_support",
  "occurred_at": "2026-07-11T02:30:00Z",
  "data": {
    "conversation": { "id": "line_user_49712031", "type": "user", "title": "Aya Tanaka" },
    "sender": { "id": "line_user_49712031", "type": "user", "name": "Aya Tanaka" },
    "message": {
      "id": "line_msg_9012",
      "type": "text",
      "text": "Can I change tomorrow's delivery address?",
      "direction": "inbound",
      "sent_at": "2026-07-11T02:29:58Z"
    },
    "event": { "kind": "message_received" }
  }
}

同じ handler で WhatsApp、Telegram、Zalo、TikTok、X の message を処理できます。envelope は常に id、type、provider、account_id、occurred_at、data だからです。code は platform ごとの webhook format ではなく、field value に基づいて動作を変えます。

MCP は queue の後ろに置く

きれいな構成は「MCP か webhook か」ではありません。正しい順序で両方を使います。

Customer message on LINE / WhatsApp / Zalo / TikTok / X
  -> UnifyPort signed message.received webhook
  -> Verify X-Device-Signature
  -> Store raw event and dedupe by event id
  -> Route by provider, account_id, conversation, and policy
  -> Let an AI agent draft, classify, summarize, or call action tools
  -> Reply through POST /v1/messages when allowed

agent または人間が返信を決めたら、UnifyPort の send path も同じ normalized endpoint です。

curl -X POST https://api.unifyport.ai/v1/messages \
  -H "X-Api-Key: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
  "account_id": "acc_line_support",
  "to": { "id": "line_user_49712031", "type": "user" },
  "message": {
    "type": "text",
    "text": "Yes. Send the new address and we will update the delivery note."
  }
}'

LINE MCP server も使うなら、action layer に置きます。rich menu、broadcast、profile read、quota check など、LINE Official Account に属する task を任せます。inbound truth は event layer が所有します。そうすれば AI Agent は context を持てますが、customer message の最初で唯一の copy にはなりません。

実用的な判断基準

product が LINE-first で、customer が LINE Official Account を明示的にフォローし、agent の仕事が制御された LINE Messaging API action を実行することなら、LINE MCP server が向いています。internal operator tools、campaign setup、Official Account automation に強い fit です。

operation が複数チャネルを扱い、ordinary messaging accounts も重要で、customer message を automation の前に durable support record にする必要があるなら、normalized inbound queue を使います。この場面では UnifyPort の unofficial interface がより狭く、より役に立ちます。message を受け取り、delivery に署名し、event を normalize し、その後の stack が次の action を決めます。

LINE の MCP work は良いニュースです。LINE を AI tool が操作しやすくなります。しかしクロスボーダーのサポートチームにとって、長く使える architecture は agent tool call ではなく、署名付き inbox から始まります。