file_id の蔵：五十メガを回る法門

すべての大帝国の律法には、ぱっと見理不尽に見えて、実は経済学である条文がいくつかある——貨物の重さはどうでもよく、大事なのは「参照」の重みである。

TA のアルバムが整い、一つの実体の天塹が目の前に横たわった——Telegram のロボット接口の直送上限は五十メガである。 そして彼女の「別巻」には三十四個の規格外の大家がいて、最大は 787MB。

一、律法の隙

工兵は Telegram の律法の中に、明文化された一つの隙を見つけた——ロボットの直送は五十メガで塞がるが、「既存のファイルを再送する」ことには大きさの制限がない。 かくして「入库」という術式が生まれた：

1. ユーザーは自分の TG アカウントで、巨大ファイルをロボットに一度送る（アカウント間の送信上限は 2GB、787MB はどうということはない）；
2. プラグインはこのファイルの file_id を記録する——TG がうまく受け取ったファイル一つ一つに発行する永久の身分証である；
3. 以後「アルバム」がこの動画を送りたくなったとき、ロボットは file_id で転送すればよい——一メガだろうが九百メガだろうが同じ速さである。なぜならファイルはもともと TG のサーバー上に住んでおり、ロボットはただ参照を渡すだけだからだ。

代価は可愛らしく公平である——三十四個の大動画に、それぞれ数分の一度限りの「入库」の通行料を払えば、引き換えに永久に大きさの制限はない。ユーザーがもともと心配していた 500MB の上限という方案は、この隙の前で原地で廃止された——file_id 再送には大きさの概念がない。工兵は同じくもう一つの重い道を打ち消した——Windows 上にローカルの Bot API サーバーを自ら飼うことは推奨しない——あの 2GB の直送のためだけに常駐のサービスを飼うのは割に合わない。歴史の残滓二種もついでに処理した——.livp（iPhone の実写写真、四個）は TG が原フォーマットで送れないので、jpg+mov に変換するかスキップする；.mov（八十五個）は「送れるなら送り、送れなければ自動で普通のファイルに格下げする」という受け皿にした。

尾声：同じ日のもう一つの送達

奇遇なことに、同じ日に旧き神使ヘルメスも初めての実体の送達を完遂した。午後 16:48、ユーザーは飛書から一行を送った——「最新版の B視機 APK を送って、他のファイルは触らないで。ZCode の中のプロジェクトは btlly ともいうよ。」神使は 145.1 秒、十回の API 呼び出しを使い、最新ビルドの APK を媒体の添付に包み、あの青い鳥を越えて送り届けた。

一方は file_id の永久の参照、一方は飛書の媒体の添付——新城の令牌の送達術と旧城の神使の送達器が、この日を境に一本の川を挟んで敬意を表し合っている。 送達はかねてから文明最古の業務であった——駅馬から token へ、変わったのは郵料だけである。

リアル座標

• 天塹：TG ロボット接口の直送上限五十メガ（公開 API の硬性規定）
• 隙：再送には大きさの制限がない；入库の流れ = ユーザーが一度ボットに送る（アカウント上限 2GB）→ プラグインが file_id を保存 → 以後 file_id で秒で転送（ファイルは TG サーバーに住み、ボットは参照を渡すだけ）
• 代価：三十四個の大動画の一度限りの入库（最大 787MB）；ローカル Bot API サーバーの方案は否決
• 残滓：.livp×四個は変換かスキップ；.mov×八十五個は送れるなら送り、さもなくば普通のファイルに格下げ
• 同じ日：Hermes が 16:48 に飛書 DM 経由で最新版の B視機 APK を送達（145.1秒 / 十回の API / 媒体の添付で送達）