本日（8月25日）のAIニュースから、Google公式MCPサーバーに見つかったSSRF脆弱性、MCPのコンテキスト消費を実測した検証、消費者GPUで超巨大MoEモデルに挑む2つの試み、LLMが数字を作り出す2つの経路、エージェント状態の保存コストを41分の1に圧縮する仕組み、417万字のLLM応答をMD5指紋で解剖した記録、そして「あえて全肯定しない」対話ロボットまでを整理する。

Google公式MCP ToolboxにSSRF脆弱性──CVE-2026-14540、8日で修正

セキュリティ研究者が、Googleが公式に公開しているMCPサーバー「MCP Toolbox」（LLMエージェントをデータベースやHTTP APIに接続するためのサーバー）にサーバーサイドリクエストフォージェリ（SSRF）脆弱性を見つけ、報告から8日で修正がマージされたと発表した。数週間後にはCVE-2026-14540として公開され、CVSS 8.0（High）の深刻度が付けられている。

問題の核心はリダイレクト処理にあった。HTTPソースは呼び出し側が影響を与えられるURLに対して外向きリクエストを送るが、最初のURLこそ検証していたものの、リダイレクトの飛び先を検証しておらず、宛先アドレスのフィルタリングもなかったという。クラウド環境でメタデータサービス（169.254.169.254）へのリダイレクトを返すサーバーを用意すれば、Toolboxはそれに従ってしまい、そこにある認証情報をそのまま持ち帰ってしまう。認証情報は送信したリクエストには含まれず、環境の側が宛先で供給するため、通常の検査では見えにくい経路だ。

エージェント用ツールにおいてこの問題が特に鋭い、という指摘が示唆的だ。多くのソフトウェアでは「攻撃者がこの入力を制御できるか」を議論の対象にする必要があるが、ツール呼び出しエージェントでは、URLのような引数は信頼できる人間が入力したものではなく、制御できないウェブページやデータベース行、ファイルを読み込んだ直後のモデルが選ぶ。「呼び出し側が影響を与えられる宛先」は例外状況ではなく、むしろ通常の動作条件になるという。

Googleの修正（プルリクエスト#3448）は、リダイレクトのホップごとに宛先を検証するSSRFGuardの導入、DNSリバインディングへの耐性、設定可能なネットワーク境界、初期化時点でのベースURLの早期検証を含む。誤った設定ならリクエスト時ではなく起動時に失敗させる設計だ。研究者は現在、他の公式MCPサーバーにも同じパターンがないか監査を進めており、宛先を正しく固定しているものとそうでないものが混在しているという。見つけたものは公開前に非公開で報告し、修正後に書くという。エージェントを動かす側への問いもシンプルだ。「呼び出し側が影響を与えた値が、宛先を検証する仕組みなしに、認証付きリクエストの送信先を変えられるか」——これにイエスと答えるなら、そのコードには同じ脆弱性がある。

MCPサーバー7個でツール定義23,964トークン──発話前にコンテキストの12%が埋まる

MCPはエージェントに外部ツールを接続する標準的な仕組みとして急速に普及しているが、その利用コストを数字で見せた検証が公開された。よく使われるMCPサーバー7個を実際に立ち上げ、tools/listで取得したツール定義をそのままトークン化して数えたという。

結果は、7サーバー・131ツールで合計23,964トークン。20万トークン級のコンテキスト窓（Claude SonnetやClaude Codeクラス）に対して、ユーザーがまだ一言も入力していない時点で約12%が埋まっている計算になる。特にAzure MCPの1個だけで14,709トークンと全体の61%を占め、既定設定のままだと他のサーバーの定義を大きく押しのけてしまうことが分かる。

MCPサーバーを「つなげるほど賢くなる」と捉えがちだが、この数字はその逆側のコストを可視化する。長いタスクではコンテキストの枯渇がそのまま性能低下につながる。どのサーバーを接続し、ツール定義をどれだけ絞り込むかは、プロンプトの設計と同じ重みを持つ判断になりそうだ。

RTX 4070 Tiで2.8兆パラメータMoEに挑む──速度と品質を分けて測る2つの検証

消費者向けGPUでどこまで巨大なMoEモデルを動かせるか、という問いに真面目に取り組んだ実験が2つ注目された。

1つはRedditのLocalLLaMAに投稿された検証だ。Ryzen 7 7800X3D、RTX 4070 Ti（12GB）、32GBメモリ、NVMe SSD2本というごく普通のWindows 11機で、Kimi K3（2.779兆パラメータ、チェックポイント711GB）、DeepSeek V4 Flash（Q4/Q3）、Qwen3.5-122B-A10B（Q4）という超大型MoEに挑んだ。自作ランタイム「CRANE V2」は、2本のSSDにまたがる重みを1つの論理ストアとして扱い、必要なエキスパートのスライスだけをオンデマンドでGPUに載せる構成という。

ポイントは、速度を追求する実験と品質を保つ実験の台帳を厳密に分けている点だ。たとえばKimi K3では、正規の制御実行が約0.014トークン/秒なのに対し、エキスパート経路を意図的に変えた速度実験は9.3トークン/秒に達したものの、出力は完全に破壊され、意図的に簡単にした品質ゲートすら通らなかった。Qwen3.5-122Bも同様で、57トークン/秒の速度記録は出力がゴミだったときの数字であり、品質を保った正規実行は1.89トークン/秒が意味のある値だと明記されている。一方でDeepSeek V4 Flash Q3では、元のテンソルをそのまま使い動的ルーティングだけを変えることで、簡単な品質ゲートに合格したまま1.14トークン/秒から8.08トークン/秒まで到達した。デュアルSSDの並列読み出し、ピン留めしたステージング、転送のパイプライン化、9スロットのGPUキャッシュ、Decayed-LFU置換と、最適化を積み上げた結果という。

投稿者自身の結論は慎重だ。Kimi K3もDeepSeek V4もQwen3.5-122Bも「実用に耐えるローカルモデル」として承認したわけではなく、これらの実験はアーキテクチャとハードウェアの境界線を暴くためにあったと明言し、次の標的はもっと小さなMoEだとしている。ランタイムは未公開、レポートも査読されていない個人の技術文書という位置づけだが、「一番速い数字」ではなく「品質を保った数字」を分けて記録する姿勢は、ベンチマークの数字が一人歩きしがちな文化への健全なカウンターに見える。

もう1つは、RTX 5090の1枚でOpenAIのgpt-oss-120bを動かした検証だ。WSL2環境でFreeTokenを試し、設定を調整した状態でおおむね約50トークン/秒での生成に成功したという。120B級のMoEをGeForce1枚でこの速度で動かせるのは興味深い。一方でWSL2とBlackwellの組み合わせではCUDAのメモリ確保に癖があり、自動設定のままでは起動しなかった点も含めて、実際に動いた構成と回避策が記録されている。

LLMが数字を作り出す2つの経路──補助金データの捏造抽出と「汚染ページ1枚」

LLMが「もっともらしい数字」を作り出してしまう現象を扱った報告が2つ並んだ。

1つは国内の実務からの報告だ。Jグランツ（デジタル庁）の公開APIから毎日データを取得し、補助金検索サイトを個人運用している開発者が、補助上限額が空欄のレコード（分析時点で1,625件中562件、約3分の1）を概要本文からLLMに抽出させて埋めようとしたところ、原文のどこにも書かれていない金額を返してくることが分かったという。金額不明の補助金は利用者から見ると比較のしようがなく、埋めたくなる動機は理解できる。しかし「本文に金額が書かれていることが多い」という期待は、LLMの生成特性と組み合わさると、出どころのない数字の供給源になってしまう。何が起き、どう検証したかまで含めて記事化されており、公的データをLLMで補完する際の失敗例として示唆が大きい。

もう1つは研究側だ。「One Polluted Page Is Enough」（EMNLP 2026 Findings受け付け）は、LLMレコメンダーに対するウェブコンテンツ汚染の影響を評価した。実在しないブランドを推薦させるのに、汚染されたウェブページが1枚あれば十分で、ランク1での推薦率は27%、上位3ページを差し替えると73.8%に達するという。より重要なのは、推論モードを有効にすると汚染の影響がむしろ悪化するという結果だ。検索して考えるほど汚染ページの主張に引きずられる——ウェブを読んで動くエージェントが主流になる時代の、構造的な弱点を突く研究といえる。

LangGraphのDelta Channels──エージェント状態5.3GBを129MB、41分の1に圧縮

LangGraphのような実行ランタイムは、エージェントを「途中で落ちても再開できる」ように、各ステップの状態を丸ごとチェックポイントする。LangChainが公開した数字では、コーディングエージェントを200ターン走らせただけで、状態のスナップショットだけで5.3GBが積み上がっていたという。durable execution（耐障害実行）の価値が語られる裏で、その保存コストを口にする人はほとんどなかった——そう指摘する記事が、この問題に手を入れる仕組み「DeltaChannel」を紹介している。同一処理の状態を129MBまで、約41分の1に落とせるという。エージェントの長時間運用が当たり前になるほど、この種の「見えないコスト」の設計は効いてくるはずだ。

417万字のLLM応答をMD5指紋で解剖──「生成」ではなく「複製」と特定

WordPress向けのAI記事生成プラグインで、本来3,000字前後になるはずの下書きが4,169,336字で保存される障害が発生した。読了時間の推定値が8,712分と表示されて初めて異変に気づいたという。「LLMが暴走して同じ内容を延々と生成した」で片づけたくなるところだが、それでは課金トークン数と辻褄が合わない。この矛盾を出発点に、セクション分割とMD5指紋分析で「生成された文字」と「複製された文字」を分離し、原因がクライアント側にないことを物証で確定させた、という記録が公開されている。LLM API絡みの「なんか出力がおかしい」を印象論ではなく数字で切り分ける手順として、他の場面でも再利用できそうだ。

シャープの対話ロボ「ポケとも」、あえて「全肯定しないキャラ」へ

最後に国内の商品開発から。シャープは対話型AIロボット「ポケとも」の新モデルを発表した。従来のモデルとは性格を変え、あえてユーザーを全肯定しないキャラクターにしたという。生成AIの迎合（シコファンシー）が課題として指摘され続ける中、「肯定しない」ことをあえて売りにするコミュニケーション設計は逆説的だが、対話AIの差別化の軸としては理にかなっている。「暇だなー」と話しかけたときにどんな応答が返ってくるのか、具体的な掛け合いは元記事で確認したい。