【geek-terminalニュース】MCP無状態化とToken Saverの最新情報

以前お伝えしたMCPとPDF/RAGをめぐるエージェント基盤論の続報です。今回のポイントは、AIエージェントの接続標準であるModel Context Protocol、つまりMCPが企業運用に寄る方向へ仕様更新され、その一方でPDFや大容量文書を相手にした現場のトークン削減ハックも同時に盛り上がっていることです。

【事象の全貌と背景】
Ars Technicaが報じた中核事実は明確です。MCPはAIシステムと外部ツール、外部データソースのやり取りを定義するオープンソース標準であり、今回の大きな更新でプロトコルの中核がステートレス化されました。つまり、リクエストが特定セッションの状態に依存しない形へ寄せられた、ということです。記事ではこの変更が、MCP導入後でも最大級のアップデートとして扱われ、エンタープライズ規模での利用を狙うものだと説明されています。

ここで重要なのは、これは単なるプロトコルの趣味変更ではない点です。AIエージェントが業務システム、社内DB、チケット、ドキュメント、コードベース、監査ログに接続する時、セッション依存の強い設計はスケール、復旧、ロードバランシング、サーバレス運用の足かせになります。接続が切れたら状態も消える、長時間ワークフローをどこまでメモリに保持するのか、どのインスタンスが続きのリクエストを受けるのか。こうした泥臭い問題を、MCP側が企業運用を意識して整理し始めたというのが今回の熱い部分です。

同時に、現場ではPDFとRAGのトークン問題が燃えています。MarkTechPostは、PDFなど大容量文書をLLM会話へ貼り付けると、会話履歴が毎回モデルに再送信され、コンテキストウィンドウのコストが累積する問題を指摘しています。その対策として紹介されているのがToken Saverで、ローカルのハイブリッドRAGを使うオープンソースMCP拡張として、ClaudeでのPDF解析トークンコストを90〜99%削減できるとうたわれています。ただし、この削減率は公式ベンチマークとして独立確認された値ではなく、記事や開発者側の主張として扱うべきです。

【技術的ディープダイブ】
ステートレス化の技術的な意味は、MCPサーバが各リクエストを過去の接続状態に縛られず処理しやすくなることです。セッションを握ったまま長時間維持するより、必要な情報をリクエストや外部ストレージ、再取得可能な文脈に分離できる方が、水平スケールしやすい。サーバレスホストへ載せる時も、特定プロセスのRAMに状態がある前提は相性が悪い。今回の変更は、ツール呼び出し標準を個人開発者の便利プロトコルから、企業の運用基盤へ押し上げる方向の仕様更新だと見られます。

一方、Token Saver的な発想は、モデルへ毎ターン巨大PDFを飲ませるのではなく、ローカル側で文書を分割、索引化、検索し、必要な断片だけをLLMへ渡すというものです。ハイブリッドRAGという言い方からは、キーワード検索とベクトル検索の併用、あるいは構造化された文書チャンクと意味検索の組み合わせが想定されます。PDFはページ見た目、表、フォーム、段組み、脚注、画像由来テキストなどが混ざるため、素朴なテキスト抽出では欠落やハルシネーションを招きやすい。関連資料でも、AI取り込みではタグ付きPDFなど情報構造を保つ処理が重要だと説明されています。

ここでMCP無状態化とToken Saverがつながります。前者はプロトコルとサーバ運用の状態を軽くする話、後者はLLMのコンテキストに投げ込む状態を軽くする話です。どちらも本質は同じで、毎回すべてを抱えて走る設計は高い、遅い、壊れやすい、ということです。エージェントが本当に業務で使われるなら、状態はモデルの会話履歴にベタ貼りするのではなく、検索可能で監査可能な外部層に逃がす必要があります。

【コミュニティの生々しい熱量と議論】
Hacker News側の反応はかなり実務寄りです。あるユーザーは「stateless updateを楽しみにしていた」と歓迎し、別のユーザーは、実際のツール呼び出しはそもそもステートレスに近いと指摘しています。LLMがget_my_todosを呼び、次にadd_todoを呼ぶ時、サーバが魔法のようにRAM上で意図を保持しているわけではなく、前回結果がテキストとしてコンテキストへ戻り、次のツール呼び出しが発生しているだけだ、という見方です。これはかなり本質を突いています。

一方で、実装者らしい疑問も出ています。HTTPヘッダーにmethodやnameを持たせる必要があるのか、URLで表現すればよいのではないか、というAPI設計レベルの突っ込みがありました。また、長時間かかるワークフローを監視するために既存の仕組みを使っているユーザーからは、代替手段があるのか、変更が必要になるのかという不安も出ています。

これに対してMCPのLead Maintainerを名乗る人物は、今回のリリースはリモートMCPサーバをサーバレスホストへ展開したい人にとって重要な変更だと説明しつつ、既存の稼働中MCPコードに対して直ちに作業が必要になるわけではなく、新機能を使いたい場合に対応すればよい、と補足しています。ここは重要です。ステートレス化は破壊的な移行祭りというより、企業運用に耐えるための足場を追加する方向に近いと読めます。

PDF側のコミュニティ感も似ています。Redditでは「なぜPDFを殺さないのか」という苛立ちに近い問題意識が見えます。PDFは人間に配るには便利でも、AIに丸ごと読ませるには重い。しかも、ページ単位の見た目と論理構造がズレるため、RAGの素材としては厄介です。Token SaverのようなMCP拡張が刺さるのは、単に安くなるからではなく、文書処理をLLMの根性勝負からローカル索引と取得設計の問題へ戻すからです。

【今後の展望とエコシステムへの影響】
今回オワコン化しそうなのは、巨大なPDFや社内資料を毎ターンそのまま会話へ貼り直す設計です。長いコンテキストウィンドウは便利ですが、企業利用ではコスト、レイテンシ、監査性、再現性が厳しく問われます。今後は、モデルに全部覚えさせるのではなく、MCPでツール接続を標準化し、ローカルRAGや外部状態管理で必要な情報だけを引く構成が主流になっていく可能性があります。

MCPのステートレス化は、エージェント基盤をクラウドネイティブな運用モデルへ近づけます。ロードバランサの裏に複数サーバを置く、失敗した処理を再試行する、監査ログとワークフロー状態を外部DBに残す、サーバレスで必要時だけ起動する。こうした企業ITの当たり前に、AIツール接続標準がようやく寄ってきた形です。

ただし、Token Saverの90〜99%削減のような数字は、現時点では過信禁物です。公式に保証された性能値ではなく、対象PDF、質問パターン、チャンク設計、検索品質、モデル、再ランキングの有無で大きく変わります。それでも方向性は強い。エージェントの次の競争軸は、モデル単体の賢さだけではなく、状態をどこに置くか、文脈をどう圧縮するか、外部ツールをどれだけ壊れにくく呼べるかへ移っています。MCP無状態化とToken Saver的RAGは、その標準化と実コスト削減が同時に来たサインです。