← 全記事
比較

Telegramのチャット自動化はネイティブ化したが、複数チャネルのサポートには入信キューが必要

Telegramは2026年上半期、botを単なる別アカウントではなく、アカウント自動化に近い存在へ押し上げてきました。公式の AI bot update では、すべてのユーザーがbotを自分のプロフィールに接続し、自分の代わりにメッセージへ返信させられると説明されています。どのチャットへアクセスできるかも制御できます。Bot APIにも business_connection_id、getBusinessConnection、managed bot token、アクセス設定、ビジネスアカウントに対する操作が追加されています。

TelegramだけでAIアシスタントを作るなら、これは大きな前進です。botは独立したbotアカウントとしてだけでなく、ユーザーの実際のプロフィールに近い場所で動けます。返信、既読処理、一部のビジネスアカウント操作を行い、Telegramクライアント内の自然な体験に近づきます。

ただし、サポートチームがつまずく理由は、Telegramに自動化機能が1つ足りないからではありません。10:02にTelegramから問い合わせが来て、10:04にWhatsAppから別の問い合わせが入り、10:08にLINEの購入者が追加質問を送る。そこで共通のキュー、署名検証、ルーティング規則がないことが問題になります。Telegramのネイティブ自動化はTelegram内では強力ですが、複数チャネルの入信メッセージ層ではありません。

Telegramプロフィールbotが得意なこと

Telegramの方向性は明確です。botをアカウントの横に置くのではなく、アカウントに近づけています。公式ブログは、ユーザーがbotをプロフィールに接続し、アクセスできるチャットを選ぶ流れを説明しています。Bot APIは、そのために必要なビジネス接続やmanaged botの低レイヤー機能を提供します。

これは主に3つの場面で有効です。

1つ目は、個人アシスタントです。アカウント所有者が不在の間、新しいTelegramチャットへ返信できます。アクセス範囲はユーザーが管理し、体験はTelegram内に残ります。

2つ目は、Telegram中心のビジネスです。別のWebアプリへ誘導しなくても、よくある質問をTelegram内で自動返信できます。Telegramだけで運用している小さな店舗なら、最初のサポート自動化レイヤーとして十分に役立ちます。

3つ目は、AI bot開発者です。ユーザーに別のbot IDへ話しかけてもらうより、もともと連絡されるプロフィールに近い場所で自動化を動かせます。

これらは本当に価値があります。ただし、それらをすべての入信メッセージアーキテクチャの答えとして扱うのは危険です。

境界線：ネイティブ自動化はメッセージバスではない

サポートキューには安定したイベントストリームが必要です。どのアカウントが受信したのか、どのチャネルから来たのか、送信者は誰か、いつ到着したのか、AI agentや人間が返信する前にどのpayloadを保存すべきかを把握する必要があります。

Telegramプロフィール自動化は、他のプラットフォームにその抽象化を提供しません。WhatsApp、LINE、TikTok、Zalo、XをTelegram updateへ変換するものではありません。すべてのチャネルで共通のHMAC-SHA256検証を提供するものでもありません。Telegramの business_connection_id がWhatsAppやLINEで意味を持つわけでもありません。

Telegramだけのプロダクトなら、それで問題ありません。しかし2人から10人規模の越境サポートチームでは、すぐに問題になります。必要なのは1つの運用キューであり、6つの別々のプラットフォームリスナーではありません。

判断基準は次のように整理できます。

問いTelegramネイティブ自動化複数チャネル入信キュー
TelegramだけのAIアシスタント強い適合必須ではないことが多い
プロフィール自動返信強い適合主用途ではない
WhatsApp、Telegram、LINE、TikTok、Zalo、Xを1つのキューへ不十分強い適合
1つの署名検証パスTelegram専用共通の signing_secret モデル
分析とルーティングのための1つのpayload形Telegram専用共通の message.received イベント
バックエンド側の履歴保管bot設計次第webhook到着時に保存

Telegramの方法が悪いという話ではありません。Telegramにスコープされているという話です。そのスコープがあるからTelegram内では洗練されますが、顧客が複数チャネルから連絡してくる場合には、全体の入信基盤にはなりません。

共通の入信イベントはどう見えるべきか

UnifyPortでは、Telegramは他のチャネルと同じ接続済みアカウントの1つです。webhook endpointを作成し、message.received または ["*"] を購読し、signing_secret を設定すると、X-Device-Timestamp と X-Device-Signature を含む署名付きHTTP deliveryを受け取れます。

Telegramの入信メッセージは、WhatsApp、LINE、TikTok、Zalo、Xと同じenvelopeで届きます。

{
  "id": "evt_72c9f4a18b",
  "type": "message.received",
  "provider": "telegram",
  "account_id": "acc_tg_support",
  "occurred_at": "2026-07-06T02:30:00Z",
  "data": {
    "conversation": { "id": "tg_49712031", "type": "user", "title": "Minh Tran" },
    "sender": { "id": "tg_49712031", "type": "user", "name": "Minh Tran" },
    "message": {
      "id": "tg_msg_9012",
      "type": "text",
      "text": "Can I change tomorrow's delivery address?",
      "direction": "inbound",
      "sent_at": "2026-07-06T02:29:58Z"
    },
    "event": { "kind": "message_received" }
  }
}

重要なのは、provider がTelegramであることではありません。ハンドラーが毎回同じ手順を実行できることです。

  1. endpointの signing_secret で X-Device-Signature を検証する。
  2. event idで重複を排除する。
  3. webhook eventは入信トラフィックの記録なので、raw payloadを保存する。
  4. type: "message.received" と provider でルーティングする。
  5. メッセージを人間、キュー、またはAI agentへ渡す。

次のメッセージがLINEやWhatsAppから来ても、envelopeは id、type、provider、account_id、occurred_at、data のままです。ルーティング層は値に基づいて動作を変えます。新しいSDKや別のwebhook形式を増やす必要はありません。

返信も1つのAPIにそろう

agentまたは人間が返信を決めたら、送信経路も正規化されています。同じ POST /v1/messages 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_tg_support",
    "to": { "id": "tg_49712031", "type": "user" },
    "message": { "type": "text", "text": "Yes. Please send the new address and we will update the delivery note." }
  }'

TelegramならTelegramメッセージが送られます。他の接続済みproviderでも、同じendpoint形が使えます。provider固有の違いは、チャネル接続とpayload値の中に閉じ込められます。サポートワークフロー全体に散らばることはありません。

どのレイヤーを選ぶべきか

プロダクトがTelegram-firstで、ユーザー体験をTelegramのプロフィールやビジネスアカウントモデル内に置く必要があるなら、Telegramのネイティブチャット自動化を使うべきです。個人AIアシスタント、Telegramだけのコマース、よりネイティブな体験を求めるbot開発者には合っています。

一方、サポート運用がTelegram以外からもメッセージを受け取るなら、複数チャネルの入信キューが必要です。その時点で問題は変わります。「このTelegram botはこのアカウントの代わりに返信できるか」ではなく、「顧客がどこから来ても、バックエンドはすべてのメッセージを信頼し、保存し、ルーティングし、返信できるか」です。

UnifyPortのunofficial interfaceは、この2つ目の問いのために作られています。通常アカウントを接続し、署名付きの message.received ストリームを発行し、Telegram、WhatsApp、LINE、TikTok、Zalo、Xを1つの運用契約の後ろにまとめます。

Telegramのネイティブ自動化は良いニュースです。TelegramをAIに向いた場所にします。ただし、越境販売、サポート、運用を行うチームにとって、長く使えるレイヤーは、すべてのチャネルを同じ形で受け取るキューです。