Telegram Bot API 10.1がリッチメッセージを実装――インバウンドチームにとって何が変わり、何が変わらないのか — UnifyPort
6月11日、TelegramがBot API 10.1をリリースしました。今回ばかりは、チェンジログの盛り上がりに見合う内容です。ボットがテーブル、見出し、ネストされたリスト、インラインメディア、折りたたみセクション、数式、脚注、引用ブロックを含むリッチメッセージを送信できるようになりました。新しい sendRichMessageDraft メソッドでは部分的なメッセージをストリーミング配信できるため、AIエージェントは遅延後に大量のテキストを一気に送る代わりに、「思考中」の漸進的な返信をプッシュできます。メッセージの最大長は32,768文字に拡張され、約8,000文字を超えると「もっと見る」ボタンが表示されます。
数日以内に、主要なボットライブラリ――python-telegram-bot、puregram、Telegraf――はすべて10.1対応のissueを立ち上げました。AIエージェントフレームワークもMarkdownベースの返信レンダリングを新しい RichMessage ブロックに置き換えるためのチケットを提出し始めています。Telegramボットを開発しているなら、2019年のMarkdownV2以来最大のフォーマット関連アップグレードです。
しかし、Telegramと他のプラットフォームでメッセージを受信しているチームであれば、もっと鋭い問いを立てる価値があります：この更新はインバウンドパイプラインに影響するのか？
Bot API 10.1で実際に追加されたもの
新機能はすべて送信側――つまりボットがユーザーへメッセージをフォーマットして配信する方法の改善です。
| 機能 | メソッド | 内容 |
|---|---|---|
| リッチフォーマット | sendRichMessage | テーブル、見出し、リスト、インラインメディア、数式、折りたたみブロック、脚注 |
| ストリーミング返信 | sendRichMessageDraft | 生成しながらメッセージを配信――AIエージェント向けに設計 |
| メッセージ長の拡張 | — | 最大32,768文字（従来の実効上限は約4,096） |
| リッチインライン結果 | InputRichMessageContent | インラインクエリ、ゲストモード、Web Appクエリでリッチフォーマット対応 |
| 編集対応 | editMessageText | rich_message パラメータを追加、送信済みリッチメッセージの編集が可能 |
これらの機能はすべてボットが言えることを向上させます。ボットが聞こえることは何一つ変わっていません。Update オブジェクト――ユーザーがボットにメッセージを送った際にTelegramがプッシュするデータ構造――は10.1以前とまったく同じです。ユーザーのテキストメッセージは依然として message アップデート内の text フィールドとして届きます。メディアは引き続き photo、document、voice などとして届きます。インバウンドスキーマは変わっていません。変える必要がなかったからです：ユーザーはボットにLaTeX数式や折りたたみセクションを含むリッチメッセージを送りません。
マルチプラットフォームチームにとって見かけほど重要でない理由
Telegramが唯一のチャネルなら、10.1は文句なしに良いニュースです。ボットの返信が美しくなり、AIエージェントのストリーミング出力がスムーズになり、MarkdownV2のエスケープルールと格闘する必要もなくなります。
しかし2026年にインバウンドメッセージを受信しているチームの大半は、Telegram単独ではありません。WhatsApp DM、LINEメッセージ、TikTokショップの会話、Xでのメンション、Zalo OAのメッセージをTelegramと並行して処理しています。課題は返信のフォーマットではなく、すべてのインバウンドメッセージを一箇所に、同じ形式で、SLA内に応答できるスピードで集約することです。
各プラットフォームの公式APIがインバウンドメッセージ配信で提供するものは以下の通りです：
| プラットフォーム | 公式インバウンド方式 | フォーマット | コスト | セットアップ時間 |
|---|---|---|---|---|
| Telegram | Bot API webhook (setWebhook) | Telegram Update JSON | 無料 | 数分 |
| Cloud API webhook | Meta webhook形式 | メッセージ単価＋BSPマークアップ | 数日〜数週間 | |
| LINE | Messaging API webhook | LINEイベントJSON | 無料枠あり、超過分はメッセージ単価 | 数日〜数週間（日本・台湾・タイのみ） |
| X | API v2（ポーリングまたはフィルタードストリーム） | X API JSON | $0.001〜$0.20/コール | 数時間〜数日 |
| TikTok | 汎用DM APIなし | — | — | プログラマティックパスなし |
| Zalo | OA API webhook | ZaloイベントJSON | 階層型OA料金 | 数日〜数週間 |
6つのプラットフォーム、6種類の認証モデル、6種類のwebhookフォーマット、6種類のコスト体系。Telegram Bot API 10.1はこの表の1列を強化しました――Telegramの送信側フォーマット列です。しかし、実際にインテグレーションの複雑さを決定する行――インバウンドメッセージのデータフォーマット――は変わっていません。
インバウンドの核心はフォーマットの正規化であり、フォーマッティングではない
マルチプラットフォームのインバウンドチームが必要としているのは、特定チャネルでの豊かな送信フォーマットではありません。どのプラットフォームからメッセージが来ても同じ形をした正規化されたインバウンドイベント――1つのwebhookハンドラ、1つの署名検証パス、1つのルーティング関数で6チャネルすべてをカバーできるもの――です。
それが UnifyPort の提供する機能です。アカウントを接続し――Telegram、WhatsApp、LINE、TikTok、Zalo、X――すべてのインバウンドメッセージが統一スキーマの message.received イベントとしてwebhookに届きます：
{
"event": "message.received",
"data": {
"account_id": "acct_tg_support",
"provider": "telegram",
"chat_id": "chat_7d3a1f",
"sender": "user_9c4b2e",
"message": {
"id": "tg_msg_8e1f4a",
"type": "text",
"text": "すみません、Lサイズはありますか？",
"reply_token": "rt_3f7b9c..."
},
"timestamp": 1750636800
}
}provider を whatsapp、line、tiktok に変えても、データ構造はまったく同じです。ハンドラはwebhook作成時に設定した signing_secret で1回のHMAC-SHA256署名検証を行い、メッセージをルーティングします。プラットフォームごとのSDK導入も、チャネルごとのパースロジックも、6方向のイベントフォーマット分岐も不要です。
公式APIの審査やBusiness Verificationは不要です。個人アカウントや一般アカウントがそのまま使えます。メッセージ単位の課金もテンプレート審査の待ち行列もありません。
10.1に対して実際にすべきこと
Telegramボットを開発しているなら：ライブラリをアップグレードして sendRichMessage を使い始めましょう。フォーマット機能は本当に優れていますし、sendRichMessageDraft でのストリーミングは長い返信を生成するAIボットにとって明確な改善です。
複数プラットフォームでメッセージを受信しているなら：10.1はインバウンドアーキテクチャを何も変えません。ユーザーから届くメッセージは従来と同じ形式のまま――Telegramでも、他のプラットフォームでも。インテグレーションの課題は依然として6種類の異なるインバウンドフォーマットを1つのハンドラに集約することであり、それが統一webhookによってプラットフォームごとの作業を解消するレイヤーです。
Telegramはより良い筆を出しました。配管工事――顧客からのメッセージをチームに届けること――は別の問題であり、それは本質的にプラットフォームに依存しないものです。