Telegram Bot-to-Bot API：AIエージェントアーキテクチャへの影響 — UnifyPort

2026年5月7日、Telegramはほとんどのメッセージングプラットフォームが手をつけていなかった機能をリリースしました。自律的なBotどうしの直接ネイティブ通信です。共有バックエンドも中継サーバーも不要。一方のBotが @username でもう一方のBotを指定するだけで、メッセージが届きます。AIエージェントシステムを構築している開発者にとって、これは注目に値する変化です。

何が変わったのか

このアップデート以前、2つのBotをTelegram上で連携させるには、すべてのメッセージを外部サービス経由でルーティングする必要がありました。Bot AがバックエンドにresultをPOSTし、バックエンドが次のステップを決定し、Bot Bに指示を送る。Bot自体は孤立しており、ユーザーからのメッセージを受け取るか、自分たちのインフラから呼び出されるだけでした。

新しいシステムは異なる仕組みで動作します。Botは @username を使って別のBotに直接DMを送れるようになりました。条件は2つ。送信側と受信側の両方がこのモードを明示的にオプトインしている必要があります。同意していないAgent graphへBotが強制的に引き込まれることはありません。

この双方向opt-inの制約は意図的な設計です。Botがスパムに晒されたり、想定外のAgent graphに組み込まれたりすることを防ぎ、開発者がどのBotがコーディネーション層に属し、どのBotがエンドユーザーに直接向き合うかを明確に把握できるようにします。

マルチエージェントシステムにとって重要な理由

専門モデルがそれぞれ異なるタスクを担当し、互いに作業を受け渡すマルチエージェントAIシステムは、この1年で急速に普及しました。コーディネーション層は常に難しい部分です。エージェントがコンテキストを渡し、サブタスクを委任し、結果を報告するための、信頼性が高くレイテンシの低いチャネルが必要です。

現在、多くのチームはメッセージキュー、共有データベース、カスタムHTTPサービスでこの問題を解決しています。これらの方法は機能しますが、インフラが増え、障害点が増え、ユーザーが実際にインタラクションしているメッセージングプラットフォームとは完全に切り離されています。

TelegramのBot-to-Botサポートにより、プラットフォーム自体がコーディネーションインフラの一部になります。独立した中継レイヤーを構築することなく、Telegramの配信保証、リトライ動作、既存の認証モデルを活用してエージェントシステムを設計できます。

生まれる2つのアーキテクチャパターン

オーケストレーター・ワーカーパターン。 1つのBotが中央コーディネーターとして機能します。ユーザーのリクエストを受け取り、サブタスクに分解し、各サブタスクをDM経由で専門のワーカーBotに割り当てます。ワーカーBotはそれぞれの処理を完了後にオーケストレーターに報告し、オーケストレーターが結果を統合してユーザーに返します。

ユーザー → オーケストレーターBot
                ↓              ↓
         ワーカーBot A    ワーカーBot B
                ↓              ↓
         オーケストレーターBot（結果を統合）
                ↓
             ユーザー

このパターンは並列化可能なタスクに適しています。リサーチ＋要約、翻訳＋フォーマット、データ取得＋分析など。

パイプラインパターン。 Botが直列チェーンとして配置されます。Bot Aが最初のステップを処理し、出力を直接Bot Bに渡し、Bot Bが次のステップを処理する、という流れが続きます。ユーザーはチェーンの最初のBotとだけやり取りし、中間結果はすべてBot層内で流れます。

このパターンは各ステップが前のステップの出力を変換していくタスクに適しています。収集 → 検証 → エンリッチメント → 配信。

構築前に考慮すべき点

双方向のopt-inは必須です。 既存のBotを変更せずにAgent graphに追加することはできません。相手のBotがBot受信モードを有効にしていなければなりません。サードパーティのBotと自作Botを組み合わせる場合は、相手がこのモードをサポートしているか確認してください。

メッセージフォーマットには制限があります。 Bot-to-BotメッセージはユーザーメッセージとまったくAPIを使用するため、同じpayloadサイズ制限とメディアタイプ制限が適用されます。任意の構造化データをネイティブメッセージとして送ることはできません。エージェント間で大きなJSONペイロードを渡す必要がある場合は、データ伝送には別チャネルを使い、Botメッセージはタスクシグナルのみに使うことを推奨します。

この機能はTelegramスコープに限定されています。 あるエージェントがTelegramイベントに反応し、別のエージェントがその結果に基づいてWhatsApp通知を送る必要がある場合、クロスプラットフォームのコーディネーションは依然としてプラットフォーム外で行う必要があります。

エージェントが複数チャネルにまたがる場合

Telegramで一部のユーザー、WhatsAppで別のユーザー、LINEやZaloでさらに別のユーザーというように、複数のメッセージングプラットフォームにまたがるエージェントシステムでは、コーディネーションの問題は単一プラットフォームのBot APIが解決できる範囲を超えます。

統一されたWebhookレイヤーがあれば、エージェントはどのチャネルからメッセージが来ても正規化されたイベントを受け取り、各エージェントが複数のProvider APIを理解することなく、適切なチャネルを通じてレスポンスをルーティングできます。それが UnifyPort が解決している問題です。統一されたAPIサーフェス、標準化されたイベント形式、エージェントがリーチする必要があるすべてのチャネルに対応します。

TelegramのBot-to-Bot機能は、メッセージングインフラをファーストクラスのコーディネーションプリミティブとして扱う重要な一歩です。このパターン——エージェントがユーザーサービスに使うのと同じ媒体で互いに通信する——は独立した中継レイヤーよりもクリーンなアーキテクチャです。TelegramがメインチャネルのシステムではこのBot-to-Bot機能を設計に組み込む価値があります。より広いカバレッジが必要なシステムでも、同じ原則がマルチチャネルレイヤーで適用されます。