← 全記事
比較

TelegramのGuest Modeと統合インバウンドWebhook:マルチプラットフォームのメッセージ問題を本当に解決するのはどちら? — UnifyPort

2026年3月、TelegramはBot API 9.5をリリースし、ボット開発者を長年悩ませてきた問題をひっそりと解決しました。ボットが参加していないグループチャットで@メンションされたら何が起きるのか、という問題です。これまでは「何も起きない」が答えでした——ボットはそのメッセージを受け取れず、チャットを見ることもできず、返信もできませんでした。Guest Modeはこれを変えます。BotFatherの設定で有効にすれば、ボットは guest_message というアップデートを受け取り、answerGuestQuery を使ってそのグループに参加することなく一度だけ返信できるようになります。

Telegramボットを開発しているなら、これは本当に便利な新機能です。しかし、Telegram、WhatsApp、LINE、Zalo、TikTok、Xを横断して動くエージェントを構築しているなら、これが解決するのは課題のおよそ6分の1にすぎません——その「6分の1」を正確に見極める価値があります。

Guest Modeが実際にやっていること

その仕組みは非常に明確で、範囲も限定されています。ユーザーが対応チャット内でボットを@メンションするか、ボットの過去のメッセージに返信すると、Telegramは guest_message を含む Update を送信します。そこには使い捨てトークンの guest_query_id、そして呼び出し元を示す guest_bot_caller_user と guest_bot_caller_chat が含まれます。ボットはそのトークンを使って answerGuestQuery を呼び出し、SentGuestMessage を受け取ります。1回のメンションに対して1回の返信、それだけです。

Telegramはこの機能の境界を明確に示しています。

  • チャット履歴なし。 ボットはその対話のトリガーとなったメッセージだけを見ることができ、それ以前の内容は見えません。
  • 参加者リストなし。 チャットに誰がいるかを列挙することはできません。
  • 常駐的な監視なし。 再度メンションまたは返信されない限り、ボットはそのチャットの以降のメッセージについて何も通知を受けません。
  • 1問い合わせにつき1返信。 これはリクエスト/レスポンス型のプリミティブであり、サブスクリプションではありません。

ある特定のタイプのボット——様々な開発者グループで@メンションされがちなドキュメント検索ボット、単位変換ボット、翻訳アシスタントなど——にとっては、これはまさに理想的です。軽量で、オプトイン方式(グループの管理者がボットを追加する必要はなく、ボット運営者がBotFatherのMiniAppでスイッチを切り替えるだけ)であり、多くのユーティリティボットの導入を妨げてきた「@MyBotをこのグループに追加してください」という障壁を取り払います。

Guest Modeが解決しないこと

Guest Modeは完全にTelegramの機能です。Telegramのクライアントとサーバーのスタック内に実装され、Telegram Bot APIを通じて公開され、Telegram特有のUI操作(Telegramのチャット内での@メンションや返信)によってトリガーされます。これらはどれも他のプラットフォームには移行できません。

チームがサポートやエージェントのワークフローを複数チャネルで運用している場合——2026年の顧客対応自動化ではこれがほぼ標準です——「正式に追加されていない会話に、ボットがどのように引き込まれるか」という問題は、Telegramだけの問題ではありません。同じ形の問題は次にも存在します:

  • WhatsApp——顧客が直接番号にメッセージを送り、既存の「会話」オブジェクトがない状態でシステムがそれを受け取る必要がある
  • LINE——ユーザーが公式アカウントを友だち追加してメッセージを送る、そこに「グループ」という概念は一切関与しない
  • X——誰かがアカウントにDMを送るか、リプライで@メンションする
  • TikTokとZalo——それぞれ独自のインバウンドメッセージの形式を持つ

Telegramは「以前明確に監視していなかった相手から自分宛てのメッセージを受け取る」という、自分のバージョンの問題を解決しました。しかし、guest_message と answerGuestQuery を中心にインバウンドパイプラインを構築すると、それは6つのチャネルのうち1つだけのために構築したことになります。残りの5つのチャネルにはそれぞれ独自の連携、独自の認証方式、独自のイベント形式が必要で、さらにGuest Modeの特有の制約(履歴なし、単発返信、再トリガーが必要)は、そもそもWhatsAppやLINEの会話モデルにきれいに当てはめることができません。

問題の本当の形

各プラットフォーム特有の仕組みを取り除くと、この状況にあるすべてのチームが本当に求めているのは同じことです。どのプラットフォームから来たかにかかわらず、自分のアカウント宛てにメッセージが届いた時に発火する、1つの正規化されたイベント。そして、返信を送るための1つのエンドポイント。

これはTelegramの機能ではありません。これは統合レイヤーです——そしてそれこそがUnifyPortの存在意義です。

統合Webhookが6つのプラットフォームで同じ範囲をカバーする方法

UnifyPortのWebhookは、接続されているどのチャネルでも、インバウンドメッセージに対して単一の message.received イベントを発行します:

{
  "event": "message.received",
  "account_id": "acct_8Q2vK",
  "provider": "telegram",
  "from": "user_3f9c1a",
  "text": "Hey, are you open on weekends?",
  "timestamp": 1749427200,
  "message_id": "tg_msg_5d2b7e"
}

provider を whatsapp、line、zalo、tiktok、x に変えても、イベントの形式は変わりません——変わるのはこのフィールドの値だけです。ハンドラーは6種類のSDKや6種類のWebhook形式に応じて分岐する必要はなく、evt.event === "message.received" を一度だけ判定し、必要であれば evt.provider でどのチャネルから返信すべきかを決めるだけです。

返信も同様に対称的です。POST /v1/messages を一度呼び出すだけで、Bearer APIキーで認証し、account_id と from で宛先を指定します——どのプラットフォームからインバウンドメッセージが届いたかにかかわらず、呼び出し方は同じです。Webhookへの各配信は、設定した signing_secret を使ってHMAC-SHA256で署名されているため、検証ロジックも6つではなく1つで済みます。

Telegram ─┐
WhatsApp ─┤
  LINE   ─┼──► UnifyPort ──► message.received ──► あなたのwebhook
  Zalo   ─┤         ▲                                   │
 TikTok  ─┤         │                                   ▼
   X     ─┘    POST /v1/messages ◄──────────── あなたの返信ロジック

Guest Modeでは、チャット管理者(または会話のコンテキストそのもの)がまずボットを@メンションしてから初めて動作がトリガーされます。一方、UnifyPortのインバウンドイベントは、各チャネルのネイティブなトリガー(DM、フォロー、リプライ)で発火し、毎回同じ message.received の形式に変換されます。Telegram特有の信号を待ってから、それを他の5つのプラットフォームで「再現」する必要はありません。

特にLINEは日本市場で支配的なチャネルです。LINEの公式アカウントを通じたインバウンドが既に多いチームほど、Telegram固有の仕組みに依存せず、最初から正規化されたイベントとして扱うことの価値が大きくなります。

実践面での意味

Telegramが本当に唯一のチャネルで、用途がGuest Modeの形にぴったり合う場合——管理していないグループチャットでときどき@メンションされる程度——であれば、有効にしておく価値はあります。無料で、ネイティブで、追加のインフラも不要です。

しかし、その段階を超えて、Telegram と WhatsApp 、さらに顧客が使う他のチャネルでもメッセージを受け取る必要があるエージェントやサポートのワークフローを運用しているなら、Telegram特有のプリミティブを中心に構築することは、同じロジックをプラットフォームごとにそれぞれの癖込みで5回作り直すことを意味します。統合Webhookは、これを一度の統合作業に圧縮します。チャネルを接続して message.received のリファレンスを確認する——もしAIコーディングエージェントに渡してレシーバーを構築させるなら、実際の構築の様子はこちらです。