【geek-terminalニュース】llama.cpp MCP対応でローカルLLMが実行主体へ近づく最新情報

【事象の全貌と背景】
以前お伝えしたllama.cppのOS操作API疑惑やMCP論の続報です。今回は、LocalLLaMAで「llama.cpp now has full MCP support」として話題化している件が中心です。ただし重要な注意点があります。提示された公式・大手メディア系の裏付けだけでは、llama.cpp本体のどの正式リリース、どのコミットで「full MCP support」が導入されたのかまでは明確に確認できません。したがって本稿では、これを公式確定事項としてではなく、PulseAugurやRedditで先行して盛り上がっている実装到達点として扱います。

それでも、この話がギークに刺さる理由はかなり明確です。llama.cppはこれまで、GGUFモデルを手元のCPU/GPUで回すための推論ランタイムとして強烈な存在感を持っていました。ローカルLLM界隈にとってのllama.cppは、モデルを「持っている」から「実際に動かす」へ橋渡しする基盤です。そこにMCP、つまりModel Context Protocol経由のツール接続が入ってくると、意味が変わります。モデルが文章を返すだけではなく、GitHub、Hugging Face、検索、ファイル、社内ツール、独自MCPサーバーを呼び出す実行主体へ近づくからです。

ZennのMicrosoft Agent Framework Harness記事が整理している通り、モデル単体は基本的にテキスト生成器です。エージェントとして使うには、ループ、計画、メモリ、コンテキスト管理、承認、テレメトリのようなハーネスが必要になります。今回のllama.cpp MCP騒動の本質は、クラウドAPIの外側で作っていたそのハーネス的な層が、ローカル推論ランタイムのすぐそばへ降りてきたことです。これは単なる機能追加ではなく、「推論」と「権限境界」と「ツール実行」の距離が縮む話です。

【技術的ディープダイブ】
コミュニティ側で語られている「full MCP support」の中身は、WebUIをエージェント型チャットのインターフェースとして使い、MCPサーバーをJSONファイルまたはコマンドライン引数で設定できる、というものです。PulseAugurの整理では、llama-cliがサーバーを直接利用できる方向の強化としても説明されています。ただしここは確度Bです。公式リリースノートでMCP対応の導入点が明示されているわけではないため、「コミュニティ上ではそう受け止められている」と読むのが安全です。

一方で、周辺事実として確認できる材料はあります。Hugging Face上のOrnith-1.0-35B-MXFP4モデルカードでは、ツール呼び出しやエージェント型コーディング能力が説明され、MCPサーバー経由でツールを使う構成が示されています。また、llama.cppでOpenAI互換APIをポート8000に立てる運用も記載されています。sxlvia/Ornith-1.0-9B-GGUFのモデルカードでも、llama.cppサーバーを起動し、9BクラスのGGUFモデルをMCPサーバー経由でツールへ接続する流れが確認できます。さらに、NVIDIA 16GB VRAMホスト向けの保守的プロファイルに触れている点は大きい。これは、MCP連携が巨大クラウド専用の贅沢品ではなく、ローカルGPU環境にも降りてきていることを示しています。

llama.cppの直近リリース周辺では、NewReleases上で2026年7月24日付のb10105に、mlock、mmap、directioをload-modeへ整理する引数リファクタリング、ドキュメント更新、+記号を修飾子として扱う変更などが記録されています。2026年7月22日付のb10087では、Laguna XS.2およびM.1のサポート追加と、macOS、iOS、Linux、Android、Windows、openEulerなど広いビルド対象が並びます。これらはMCP追加そのものの直接証拠ではありませんが、llama.cppが単一環境の実験ツールではなく、多OS・多実行形態の基盤として更新され続けていることを示す文脈になります。

技術的に一番おいしいポイントは、MCPサーバー設定が「モデルの外付けプラグイン」ではなく、ローカル推論フローの設定項目に近づくことです。これにより、クライアントごとにツール定義、JSON修復、失敗時のリトライ、CORS回避、権限確認を作り直す必要が薄くなります。特に小型モデルでは、ツール名を幻覚したり、壊れたJSONを吐いたりする問題が実運用の痛点になります。サーバー側でエージェントループを吸収できるなら、モデルの弱さをインフラ層で補正する余地が出ます。

【コミュニティの生々しい熱量と議論】
Redditの反応はかなり現場臭いです。LocalLLaMAでは、MCP tool callingを使ってエージェントを作ってきたユーザーが、小型モデルの最大の痛点として「ツール名の幻覚」と「壊れたJSON」を挙げています。そして、agentic loopをllama-server側で扱えるなら、各クライアントが同じガードレールを再実装する必要がなくなる、という期待が出ています。これは単なるワクワクではなく、実装者が何度も踏んできた地雷の共有です。

別のコメントでは、クラウドとローカルを同じツール構成で切り替えられる点が過小評価されている、という指摘もあります。Claudeとローカルモデルをタスクの複雑さで切り替える運用では、MCPの配管がモデルごとに違うと面倒です。ここが統一されると、モデル選定は「APIに合わせてツールを作る」から「同じツール面に対して、どの推論エンジンを差すか」へ変わります。

一方で、セキュリティ懸念もかなり具体的です。KoboldCppのMCP対応に触れたユーザーは、ブラウザベースUIとMCPエコシステムの相性、特にHTTP CORS例外の不足を問題視しています。llama.cpp側に/cors-proxyのような一般CORSプロキシがあるように見える、もし任意URLを受けるならローカルネットワーク内部リソースへのプロキシとして使われかねない、という懸念です。これは笑えない指摘です。ローカルLLMが手元のツールを叩けるということは、同時に、ローカルネットワークやファイルシステムに近い場所へ実行権限が降りてくるということだからです。

開発者らしきコメントでは、WebUIのMCPサポートについて、初期段階としてツール、プロンプト、リソースを広くカバーし、GitHub、Hugging Face、Exa Searchのremote serverをstreamable HTTPで使い、WebSocket transportもサポートしていると説明されています。ただしOAuth、notifications、samplingは初期リリースには含めない予定だとされています。ここでも、MCPを「ツールだけ」ではなく「prompts」「resources」まで含むプロトコルとして実装しようとしている点が刺さります。AnythingLLMではtoolsはあるがresourcesがない、という指摘もあり、コミュニティはかなり細かいプロトコル面を見ています。

【今後の展望とエコシステムへの影響】
この流れで古く見えてくるのは、単体チャットUIにツール機能を少し足しただけのローカルLLMアプリです。今後の比較軸は、モデルをどれだけ速く回せるかだけではありません。MCPサーバーをどう登録するか、権限をどう分離するか、ツール呼び出し失敗をどこで検証するか、UIとサーバーのどちらがagentic loopを持つか、監査ログをどう残すかが重要になります。

特にローカルLLM界隈では、「プライバシーのためにローカルで動かす」という説明だけでは足りなくなります。手元で動くモデルが、手元のGit、ブラウザ、検索、ファイル、社内APIを叩くなら、プライバシーと同じくらい権限境界が重要になります。クラウドエージェントの怖さは外部送信ですが、ローカルエージェントの怖さは内部到達です。CORSプロキシ、MCPサーバーの allowlist、subprocess実行、OAuth未対応時の認証設計、全部が攻撃面になります。

ただし、うまく設計できれば破壊力は大きいです。16GB VRAM級のローカルGPUで9BクラスGGUFを回し、重い推論だけクラウドへ逃がし、普段のファイル操作や小さなコード変更はローカルMCPで処理する。こうしたハイブリッド運用が、ようやく現実的なアーキテクチャとして見えてきます。llama.cppがこの位置を取るなら、ローカル推論ランタイムは「モデルをロードする箱」から「権限付きエージェント実行面」へ進化します。

結論として、今回のニュースは「llama.cppが公式にいつ何を出したか」だけを追うとまだ慎重さが必要です。しかし、Redditの熱量、Hugging Faceモデルカードの実用手順、MCPを標準として見るエージェント開発の流れを合わせると、方向性はかなりはっきりしています。ローカルLLMは、もう返答装置では終わりません。次の主戦場は、モデル性能ではなく、モデルに何を許し、何を拒み、失敗した実行をどこで止めるかです。llama.cpp MCP騒動が示しているのは、ローカルAIの本番化が、推論速度の話から権限設計の話へ移ったということです。