Telegram、ボット基盤を自社サーバーに載せる「Telegram Serverless」を公開　データ保管の前提も変わる

Telegramが、ボットのバックエンドを自社サーバー上にワンコマンドで展開できる新しい実行基盤「Telegram Serverless」のドキュメントを公開した。外部ホスティングが不要になる一方で、ボットの会話データやアプリケーションロジック、データベースもTelegramの基盤内に置かれることになる。個人向けの小規模ボットには魅力的な選択肢になり得るが、機微な会話や規制対象データを扱う用途では、公開されていない条件や移行性の制約を見極める必要がある。

■Telegram Serverlessで何が変わるのか

これまでTelegramボットは、Telegram側がメッセージ配送を担い、開発者側が別途VPSやクラウド関数、マネージドコンテナなどでバックエンドを運用する構成が一般的だった。この分離は運用上は煩雑だったが、ユーザーデータをどこに保存するかを開発者が自ら決められるという意味も持っていた。

Telegram Serverlessは、その分離をなくす。開発者は通常のJavaScriptモジュールを書き、BotFatherでボットに関連付けたうえで、npx tgcloud pushを実行するだけでよい。コードはBot APIと内蔵SQLiteデータベースに隣接したV8 isolate上で実行される。サーバーを借りる、パッチを当てる、監視するといった作業は不要で、コードは必要時に起動する。

プロジェクト構成も最小限だ。Telegramの更新タイプごとにJavaScriptファイルを置くhandlers/、共通処理を置くlib/、データベースのテーブル定義を記すschema.jsの3つが基本になる。メッセージが届くと、Telegramが対応するハンドラーへ振り分け、default exportされた関数を呼び出す。その関数はapiでBot API、dbでデータベース、fetchで外部HTTPサービスにアクセスし、処理を終える。イベントループはそれで完結する。

■実行基盤はV8 isolate、ただし安全性の詳細は未公表

Telegramが採用しているV8 isolateは、仮想マシンでもコンテナでもなく、GoogleのV8 JavaScriptエンジン内で動く軽量な実行コンテキストである。ChromeやNode.jsを支えるV8上で、多数のisolateを同時に動かせるため、起動時間は5ミリ秒未満とされ、Lambdaコンテナの100〜1000ミリ秒と比べて高速だという。Cloudflare WorkersやDeno Deploy、Vercel Edge Functionsが同系統の方式を採るのもこのためだ。

一方で、V8 isolateは単一のOSプロセスを共有する。分離はOS層ではなくソフトウェア層で行われる。AquilaXのセキュリティ研究者は2026年4月、JITコンパイラの不具合やメモリ破壊系の脆弱性など、過去のV8の欠陥によってこの種の分離が破られた事例を文書化している。共有プロセス上のV8にゼロデイ脆弱性が入れば、理論上は他テナントのデータに影響が及ぶ可能性がある。

CloudflareはLinux名前空間やseccomp制限を使った追加のプロセスレベル隔離策を講じているが、TelegramはServerless実行基盤で同等の安全対策をどう実装しているかを公表していない。公式ドキュメントにも、V8サンドボックス以外の追加隔離層への言及はない。これは直ちに安全でないことを意味するものではないが、セキュリティモデルが現時点で開示されていないという別種の不確実性を示している。

■内蔵SQLiteと慎重なマイグレーション設計

各ボットには、呼び出しをまたいで利用できるSQLiteベースの専用データベースが割り当てられる。schema.jsでは、Drizzle ORMを思わせる型付きDSLでテーブルを定義できる。

マイグレーションは意図的に慎重だ。npx tgcloud pushはコードを配備しつつ、必要なデータベース変更を表示するが、その場では適用しない。変更の適用は、開発者が内容を確認した後にnpx tgcloud migrateを別途実行して行う。新しいテーブル追加やNULL許容列の追加といった安全な変更はまとめて適用され、列削除や時間のかかるインデックス作成のような警告レベルの変更は個別確認が必要になる。列型の変更のような操作は、自分で生SQLを書く必要がある。

注意すべき設計上の制約もある。この実行基盤ではPRAGMA foreign_keysが無効化されており、schema DSLでも外部キーを宣言できない。関係制約のように見える定義を書いても黙って無視されるため、参照整合性はアプリケーションコード側で担保しなければならない。さらに、Telegram Serverless環境の外へデータベースをエクスポートしたり移行したりする仕組みは、現時点で文書化されていない。

■移植性は低く、ベンダーロックインが起きやすい

Telegram Serverlessのモジュール設計は、運用の簡素さを優先しており、移植性は高くない。ハンドラーが実行時にimportできるのは、api、db、fetchを公開するsdkと、開発者自身のテーブル定義であるschemaの2系統だけだ。npmパッケージ、ファイルシステム、ネイティブバインディング、SDKのfetch以外のネットワークアクセスは使えない。

この制約はCloudflare Workersに似ているが、Telegramの方がさらに強い前提を持つ。WorkersはWebAssemblyやより広いWeb API群を許すのに対し、Telegram Serverlessは現時点でそれらを提供していない。

そのため、この実行基盤向けに書いたコードは、SDK importを書き換えない限り他のJavaScript環境へそのまま持っていけない。加えて、データベースには公開されたエクスポートAPIがない。ビジネスロジックは書き換えで移せても、未公開の方法でしか取り出せないデータベースにデータが蓄積すると、そこが最も重い移行障壁になる。なお、ファイル処理にも制限があり、現時点ではTelegramサーバー上にあるfile_id付きファイルの利用に限られる。ハンドラー内部から新しいファイルをアップロードしたり、ファイル本体をダウンロードしたりすることはまだできない。

■ユーザーデータはTelegram基盤の内側に置かれる

Telegramの通常メッセージは、標準ではエンドツーエンド暗号化されていない。利用者が明示的に開始した「Secret Chats」のみがクライアント間暗号化を使い、通常のボット対話を含むBot API経由のメッセージはすべてTelegramのサーバー上で復号される。これは以前から変わらないが、Telegram Serverlessによって変わるのは、そのメッセージを処理するアプリケーションロジックと、派生データを保存するデータベースも同じ基盤内に置かれる点である。

従来は、独自バックエンドを使う開発者であれば、ボット会話データを保持するか削除するかを自分の方針で決められた。Telegram Serverlessでは、その選択の主導権はTelegram側に移る。

この点は、特定の背景事情と合わせて考える必要がある。2025年6月には調査報道メディアiStoriesが、Telegramに関連する技術基盤がロシア連邦保安庁（FSB）に協力した企業とつながっていたとする報告を公表し、その後OCCRP、The Moscow Times、Newsweekも取り上げた。ただし、この調査はメッセージ内容への実際のアクセスを証明したわけではなく、Telegramは、契約業者がユーザーデータや重要インフラにアクセスできることはなく、ロシア国内にサーバーや従業員も存在しないとして疑惑を否定している。iStoriesの調査で引用されたセキュリティ研究者Michał Woźniakは、Telegramのトラフィック基盤にアクセスできる主体がロシア情報機関に協力していた場合、すべてのメッセージに付く一意の端末識別子auth_key_idが「ユーザーがどこにいて、どのサーバーにつないでいても監視し得る強力な道具になる」と述べていた。

別の動きとして、創業者Pavel Durovが2024年8月にフランスで逮捕された後、Telegramのデータ開示対応は大きく変化した。2024年第1四半期にフランス政府の要請へ4件、第2四半期に6件対応していたのに対し、第4四半期だけで673件に増えた。適法な裁判所命令がある場合、共有対象にはIPアドレスと電話番号が含まれる。

これらがTelegram Serverlessだけを特別に危険なものにするわけではない。ただ、利用者が自分の会話がメッセージング基盤のサーバー内に保存されないと合理的に期待し得る用途においては、自己ホスト型のボット基盤とは性質が明確に異なる。

■開発体験はよく練られている

Telegramが狙う会話AIボット、Mini Appのバックエンド、ランキングゲーム、HTTP自動化といった用途では、Telegram Serverlessは外部基盤を組み立てるより本番投入までの時間を短縮し得る。

開発体験もよく考えられている。BotFatherはスマートフォン上からプロジェクト全体を操作でき、ハンドラーの作成・編集、ライブラリ管理、データベーススキーマ変更、マイグレーション適用までタッチ操作で進められる。テスト実行のコンソール出力もチャット内に直接表示される。スマートフォンで試したハンドラーは、npx tgcloud pullでノートPC側に取り込める。

新規プロジェクトにはAGENTS.mdとdocs/tgcloud-sdk.mdが含まれ、AIコーディングエージェントが自動で参照する前提になっている。Telegramのドキュメントは、Claude Code、Cursor、opencodeを主要な開発パートナーとして明示している。個人用ボット、通知アシスタント、調査トラッカー、小規模なMini Appバックエンドのように、配備の手間が価値に見合わず止まりがちだった案件では、この運用簡素化の恩恵は大きい。残る焦点は、今後示されるデータ条件が同じだけ丁寧に設計されるかどうかだ。

■まだ公開されていない条件が多い

公開直後にTelegram Serverlessを取り上げたHacker Newsの議論では、ドキュメントが答えていない点として、実行時間制限と保存容量の上限、そしてサードパーティー向けAPIキーのような秘密情報をどう管理するのかが挙がっていた。現時点では、この実行基盤内で安全にシークレットを保存する仕組みは文書化されていない。

同種のV8系サーバーレス基盤では、通常は具体的なリソース上限が公開される。たとえばCloudflare Workersは無料枠で1リクエスト当たりCPU時間10ミリ秒、メモリ128MBを掲げ、有料枠ではHTTPリクエストごとに最長30秒の実行時間を提供している。これに対しTelegram Serverlessは、相当する数値、無料枠の仕様、利用量がしきい値を超えた際の料金体系をまだ公表していない。

この空白は本番計画に直結する。いまTelegram Serverlessを選ぶ開発者は、費用を試算できず、どの程度まで拡張できるかを計画できず、将来課金が始まったときに何が起きるかも評価できない。開発者向け基盤の無料枠は、十分な予告を伴って終了する場合もあれば、そうでない場合もある。Telegramがこの実行基盤をどう商用化するのかについて、現時点で公開された材料はない。

■Telegramの開発者戦略の一部として位置付けられる

Telegram Serverlessは、Telegramが2026年を通じて積み上げてきた開発者基盤の3層目にあたる。2026年3月から4月にかけてのBot API更新では、プログラムによるボット作成とManaged Botsが導入され、単一の管理エージェントが利用者に代わって他のエージェントを生成・制御できるようになった。2026年5月には、ボット同士がネイティブに通信し、自律エージェント同士が基盤内で直接連携できる仕組みも加わった。Telegram Serverlessは、それらを低コストで運用するための基盤層にあたる。

競争上の狙いも明白だ。現在1,000万超のアクティブボットは、Bot APIと通信するバックエンドを動かすために、CloudflareやAWS Lambda、VPS、マネージド関数ホストなど外部クラウドへ費用を払っている。Telegram Serverlessは、その中間にあったインフラ層をTelegramが吸収し、開発者との接点をさらに深くするものだ。

CloudflareのWorkers、DenoのDeploy、FastlyのComputeと似た動きではあるが、Telegramは汎用開発基盤企業ではなく、法的経緯を抱えるメッセージングプラットフォームであり、標準ではE2EEでないメッセージ構造を持ち、創業者を巡る手続きも続いている。その事業者が、ボットアプリケーションとそのデータを一体のサービスとして引き受けようとしている点が違いになる。

■どの用途なら使えるのか

結局のところ、Telegram Serverlessを選ぶべきかどうかは、そのボットが何を扱うかにほぼ尽きる。

趣味のプロジェクト、個人向け通知ツール、機微でない情報を扱う小規模コミュニティーボットであれば、トレードオフは比較的受け入れやすい。運用の簡単さは本物であり、レビュー前提のマイグレーションを備えたSQLiteデータベースの設計も良い。BotFather経由のモバイル編集を含め、実運用での摩擦をかなり減らせる。少なくとも現時点では料金も明示されておらず、データ露出の前提を許容できるなら価値提案は大きい。

一方、非公開の会話、医療情報、金融データ、あるいは利用者が機微だと考える情報を扱う本番アプリケーションでは、未公表の要素が多すぎる。リソース上限、料金、データベースのエクスポート手段、V8サンドボックスの追加安全対策、そして標準でE2EEではないメッセージ基盤。これらは個別には致命的でないとしても、同時に不明のままなのは、本番配備を預けるインフラとしては異例だ。

規制産業向けのボットを作る開発者や、政府によるデータ取得リスクが無視できない環境で利用者を抱えるチームにとっては、2024年以降のデータ開示方針や、iStoriesの調査で解消されていない基盤面の疑問も、導入前に重く比較すべき材料になる。Telegram Serverlessは今後の成熟でこうした空白を埋める可能性があるが、現時点で必要なのは、他のインフラ選定と同じく、公開されたリソース上限、料金表、データ条件、監査可能なセキュリティモデルである。それらが出そろうまでは、重要システムを載せることは、データが既にプラットフォーム内に入った後で運用条件が変わり得ることを受け入れる判断になる。

■注目ポイントQ&A

●Telegram Serverlessは技術的にどう動きますか

JavaScriptのハンドラーモジュールをV8 isolate上で実行し、TelegramのBot APIとボットごとのSQLiteデータベースの近くで処理します。更新を受け取り、ロジックを走らせ、保存データを参照し、応答を返すまでを外部サーバーなしで完結できます。SDKはapi、db、fetchの3つを提供し、コードの配備はnpx tgcloud push、スキーマ変更の適用はnpx tgcloud migrateで行います。

●Telegram Serverlessは無料ですか。制限はありますか

Telegramは現時点で、料金、実行時間制限、メモリ上限、データベース保存容量を公表していません。立ち上げ段階では無償で使えるように見えますが、無料枠の仕様や商用料金表はドキュメントにありません。本番導入を検討する場合は、リソース上限と価格条件が未確定で、導入後に設定・変更される可能性を織り込む必要があります。

●後からTelegram Serverlessの外へ移行できますか

容易ではありません。ハンドラーコードはsdkやsdk/db、sdk/apiといった独自importに依存するため、他の実行環境へ移すには書き換えが必要です。さらに重要なのは、内蔵SQLiteデータベースに文書化されたエクスポート手段がないことです。将来の移行可能性を重視するなら、重要データをfetchで接続できる外部システムに置くか、Telegramがデータ移行手段を公開するまで待つ判断が考えられます。

●Telegramボットにユーザーデータを保存しても安全ですか

通常のTelegramボットメッセージはエンドツーエンド暗号化ではなく、Telegramが内容にアクセスできるサーバー側暗号化です。Telegram Serverlessでは、そのメッセージを処理するアプリケーションロジックと、派生したユーザーデータを保存するデータベースもTelegram基盤内に置かれます。機微な個人情報を扱うボットでは、Telegramのデータ条件、利用者に想定される脅威モデル、自前基盤の方がプライバシー要件に合うかどうかを慎重に検討する必要があります。

元記事: Telegram Serverless Ships: One Deploy Command, But Your Bot Data Never Leaves Telegram