こんにちは、Lena です。「ローカル AI agent」という言葉は今あちこちで使われていますが、正直、それぞれの人が指しているものは少しずつ違います。ある developer は、自分の GPU で open-weight モデルを動かすことを指している。別の人は、推論で cloud API を呼ぶとしても、agent runtime が完全にデバイス上で実行されることを指している。そして、ますます増えているのが、ローカルモデル、ローカルツール、ローカルデータ、外部呼び出しは一切なし——スタック全体のことを指す人たちです。
私はこの一年ずっと、いろいろなローカル agent の構成を組んでは評価してきました。モデル、runtime、ハードウェアの組み合わせを片っ端から試してきた、ということです。この記事は、その曖昧さを切り分けて、チーム内の議論で何度も繰り返される問いに答える試みです——ローカル AI agent とは、結局のところ何で、「ローカルでいく」のがいつ本当に意味を持つのか？
「ローカル AI agent」が実際に意味するもの
ローカル実行 vs ローカルモデル vs ハイブリッド agent
最初に解きほぐすべきは、「ローカル」がどこを修飾しているのか、です。「ローカル AI agent」と呼ばれるものには、少なくとも三つの異なる構成があります：
ローカルモデル + ローカル実行。 モデルは自分のハードウェア上で（Ollama、LM Studio、または llama.cpp 経由で）動き、agent runtime もローカルで動き、tool call も自分のマシンで完結する。何も自分のネットワークから出ません。これがローカル AI agent の最も純度の高い形です。
ローカル実行 + クラウドモデル。 Agent runtime とツールは自分のマシンで動くけれど、推論呼び出しは Claude や GPT のような cloud API へ飛ぶ。OpenClaw はデフォルトでこの形——メッセージングアプリを LLM につなぐセルフホスト型の gateway ですが、LLM 自体はだいたいクラウドモデルです。オーケストレーションがローカルだとしても、データは推論のために外部サーバーを経由します。
ハイブリッド。 タスクの一部をローカルモデルへルーティングし（単純な分類、下書き）、難しい推論タスクはフロンティア API へ送る。プロダクション環境では、機微なデータにプライバシーを与えつつ、複雑なタスクにはフロンティア級の推論能力を残したいチームでよく見る形です。
これらは実際に別物のアーキテクチャで、プライバシー、コスト、能力のプロファイルがそれぞれ違います。これを混同すると判断を誤ります。 誰かが「うちはローカル AI agent を動かしている」と言ったら、最初に聞くべきは常に同じです——ローカルモデルなのか、ローカル実行なのか、それとも両方なのか？
ローカル agent はクラウドホスト型の agent とどう違うか
クラウドホスト型の agent——プラグイン付きの ChatGPT、MCP コネクタ付きの Claude などを思い浮かべてください——は推論をリモートサーバーで実行します。プロンプトもデータもネットワークを通って外に出ます。料金はトークン課金。レイテンシは回線とプロバイダ側の負荷で決まります。
ローカル AI agent はそのトレードオフを反転させます。（ローカルモデルを動かしている限り）データは自分のマシンを出ません。 ハードウェア購入後はトークン単価がかからない。レイテンシは GPU で決まり、ネットワークの状態に左右されません。一方で、ハードウェアの上限と、open-weight モデルとフロンティア API の品質ギャップにも縛られます。
ローカル AI agent はどう動いているか
Ollama、LM Studio、llama.cpp によるローカルモデルの提供
モデルを serve する層が、たいていの人の入り口です。主流の三つのツールは、それぞれ少し違う層の人を相手にしています。
Ollama はゼロから動くローカルモデルまで一番速く到達できるルートです。1 コマンドでモデルを pull、もう 1 コマンドで localhost:11434 の OpenAI 互換 API として配信。量子化は自動でやってくれて、agent workflow 用の tool calling にも対応しています。2026 年時点では、デスクトップアプリ、さらにクラウド gateway のオプションも入りましたが、コアの local-first 体験は無料・オープンソースのままです。
LM Studio はモデルの閲覧・ダウンロード・実行を GUI で扱えます。中身は llama.cpp で、互換のローカル API を公開します。CLI より GUI でモデルを比較したいなら、こちらのほうがスタート地点として向いています。
llama.cpp は Ollama と LM Studio の両方が乗っかっている C/C++ 推論エンジンです。直接使えば最大限のコントロールが手に入ります——カスタムコンパイルフラグ、細粒度の layer offload、最新の量子化手法を上位ツールに伝わる前に試せる、といったあたり。代償としてセットアップの学習曲線は急になります。
これから始める多くの開発者には、Ollama を妥当なデフォルトとして勧めます。あとから llama.cpp に降りていけば、もっと細かい制御が手に入ります。
Agent runtime レイヤー：OpenClaw またはローカルフレームワーク
モデル単体ではまだ agent ではありません。plan-act-observe ループを回し、tool 呼び出しを管理し、セッション状態を保持する runtime 層が必要です。ここにはいくつか選択肢があります。
OpenClaw は、今もっとも目につくローカル agent プラットフォームの一つです。オープンソース、セルフホスト型の gateway で、メッセージングアプリを、シェルコマンドを実行し、ウェブを閲覧し、ファイルを管理できる AI agent に接続します。Ollama 経由でクラウドモデルとローカルモデルの両方をサポートします。OpenClaw のドキュメントがフルセットアップの流れを通しで書いています。注意点として、OpenClaw は要求する権限の幅広さで議論を呼んできた経緯があるので、デプロイ前にセキュリティ姿勢をきちんと確認してください。
他のフレームワークとしては、ステートフルなグラフベースの workflow 用の LangGraph、多 agent オーケストレーションの CrewAI、JavaScript ベースの agent loop 用の Vercel AI SDK などがあります。これらはどれも、cloud API ではなくローカルの Ollama エンドポイントに向けて動かせます。
ローカル環境での tool calling と MCP
Tool calling は言語モデルを agent に変える鍵です——モデルはテキストを生成するだけでなく、関数を呼び出す判断をします。Model Context Protocol は、ツール、リソース、プロンプトを AI アプリケーションへどう露出するかを標準化します。
ローカル構成にとって重要なのはここです——MCP はローカルモデルでも cloud API と同じくらいよく動きます。前提は、あなたのローカルモデルが function calling に対応していること。Ollama 上の Qwen 2.5 や Llama 3 などは、ネイティブで tool calling をサポートしています。ローカルで stdio 経由の MCP server を立ち上げ、agent フレームワーク経由でローカルモデルに繋げば、パイプライン全体がデバイス上に留まります。データは一切ネットワークの外に出ません。
なぜ作り手はローカル AI agent を選ぶのか
プライバシーとデータ主権
これはチームがローカルを選ぶ理由の筆頭で、議論の余地がほぼありません。自分のハードウェアで推論を回せば、プロンプトも、コードも、データも、サードパーティのサーバーには一切触れません。 GDPR、HIPAA、厳格な IP ポリシーの下で動く組織にとって、ローカル推論は「データ転送経路」というコンプライアンスのベクトルを一本まるごと消してくれます——もちろん完全な規制対応には、物理的・アクセス制御の追加も必要です。
トークン課金なしの予測可能なコスト
クラウド API のコストは予測しづらいです——agent workflow はループするので、なおさら。一つの agentic タスクが推論呼び出しを数十回行うこともあります。ローカルモデルなら、コストはハードウェア購入と電気代に固定されます。Ollama を動かす一般的なワークステーションで、一日に使う電気は $1-2 程度。初期のハードウェア投資のあとは、トークン単価ゼロ、利用上限なし。
オフライン稼働とレイテンシのコントロール
ローカル agent はインターネット接続なしでも動きます。現地配備、エアギャップ環境、あるいは単純に cloud API のレイテンシの揺れを避けたいといった場面で、これが効きます。RTX 4060 上の 7B モデルは、Q4 量子化で毎秒 40-60 トークン——リアルタイム会話にも十分なスピードです。
カスタマイズとフルスタックの制御
モデル、量子化レベル、プロンプト形式、すべてのパラメータをあなたが選びます。自分のデータでファインチューニングしても、どこにもアップロードする必要がない。モデルの差し替えは 1 コマンドで終わる。ベンダーロックインもなく、利用規約の変更に振り回されることもありません。
ローカル AI agent がぶつかる限界
フロンティア API モデルとの能力差
これは正直にいきましょう。2026 年中盤の時点で、最良の open-weight モデルとフロンティア API の間には、複雑な推論、長コンテキスト、多段の計画立案で、まだ感じ取れる品質ギャップがあります。 ローカルの Qwen 3 30B や Llama 4 Scout はそのサイズとしては印象的ですが、難問では Claude Opus や GPT-5 にまだ追いつきません。多くの agent workflow——シンプルな tool ルーティング、コード補完、要約——にはローカルモデルで十分すぎるくらいです。ただ、フロンティア級の推論を求めるなら、ギャップは本物です。
ハードウェア要件と保守コスト
7B モデルを快適に動かすには、最低でも VRAM 8GB、もしくはシステム RAM 16GB が要ります。サイズが上がれば要件も上がります——30B モデルは VRAM 16-24GB ほどになります。Apple M4 Max + 64GB ユニファイドメモリならたいていのものを快適にこなせますが、安いハードウェアではありません。初期購入のあとは、ドライバ更新、モデルのバージョン管理、推論の不具合対応も自分で抱えることになります。電話できるサポートはありません——llama.cpp プロジェクトにもあるように、あなたが動かしているのはコミュニティが保守しているオープンソースソフトウェアです。
ローカル agent も、学んだことを共有してくれない
これが私が何度もぶつかっている境界です。ローカル AI agent は、実行とデータに対する完全な制御をくれます。でも、「うまくいったやり方」を自動的には保存してくれません。 クエリを正しいツールへルーティングし、edge case を正しく扱い、きれいなアウトプットを出す workflow を組み上げても——次のセッションでは、そのコンテキストはまるごと消えています。OpenClaw のようなフレームワークはセッション間の memory を模索していますが、より広いローカル agent エコシステムは、セッション間ではまだほぼ stateless です。設定は共有できる。実運用上のノウハウは、たいてい共有できない。
ローカルが報われるとき、報われないとき
プライバシー要件の強い workflow
データがネットワークの外に出てはいけないなら——規制業界、独自コード、個人の医療データ——ローカル AI agent + ローカルモデルが最もはっきりした道です。第三者のデータ処理契約のコンプライアンスレビューも、クラウド事業者への信頼仮定も要りません。データはそのまま、その場に留まります。
フロンティア級の推論品質が必要なとき
workflow が「いま手に入る最良の推論」に依存しているなら——複雑なマルチファイルのリファクタリング、ニュアンスが効いた法務分析、高度な数学の証明——フロンティアのクラウドモデルのほうがやはり良いツールです。ローカルモデルは急速に良くなっていますが、いちばん難しいタスクではまだ届いていません。自分の workflow が本当に何を必要としているか、ここは正直に。
中間の道としてのハイブリッド構成
プロダクションで実用度が高い、私が見てきた中で一番現実的なやり方はハイブリッドです——機微なデータはローカルモデルへ、複雑な推論はフロンティア API へルーティングする。 これでプライバシーが必要なところにプライバシーを、能力が必要なところに能力を割り当てられます。LangGraph のようなフレームワークは、データの機微度を判定してから呼び出すモデルを決めるルーティングロジックを、わりと素直に書かせてくれます。Hugging Face Hub には、ローカル側で使える open-weight モデルが何千とホストされています。
FAQ
最良のローカル AI agent フレームワークはどれですか？
唯一の正解はありません——ユースケース次第です。OpenClaw は、メッセージング連携付きで常時稼働するパーソナルアシスタント系の workflow に強い。LangGraph はステートフルでグラフベースの agent ロジックを上手に扱います。単一 agent のシンプルな構成なら、Ollama を自前の Python ループに直接挿すだけで足りることが多いです。要件をカバーする最もシンプルな選択肢から始めましょう。
ローカル AI agent には GPU が必要ですか？
厳密には必須ではありません——でも、なしでは性能が出ません。CPU だけで 7B モデルを動かすと、GPU 推論の 5-10 倍遅くなります。実用に堪える最低ラインは、VRAM 8GB 以上の NVIDIA GPU（RTX 4060 以上）か、ユニファイドメモリ 16GB 以上の Apple Silicon Mac、というあたりです。
ローカル AI agent は MCP を使えますか？
使えます。MCP は transport 非依存で——ローカルプロセスには stdio、リモートサーバーには HTTP で動きます。tool calling に対応する任意のローカルモデルは、agent フレームワーク経由で MCP の tool を使えます。プロトコル側は、推論がローカルかクラウドかを気にしません。
ローカル AI agent は ChatGPT より良いですか？
「良い」は、何を最適化したいかに完全に依存します。プライバシー、コスト、オフライン能力では、ローカル agent が勝つ。素の推論品質と使いやすさでは、たいていのタスクで ChatGPT などのクラウドサービスがまだ先行しています。別の問題を解いている別のツールです。
ローカル AI agent を動かすにはいくらかかりますか？
ハードウェアが主なコストです。性能の出るセットアップ——ミドルレンジのワークステーションに RTX 4060（12GB VRAM）——なら、GPU 単体で $800-1200、システム全体で $1500-2500 ほど。Apple Silicon Mac は M4 Pro + 24GB が $1600 あたりからです。それ以降の継続コストは電気代だけ——ワークステーションで推論を回して 1 日 $1-2 が目安です。比較すると、cloud API のコストはモデルにより 100 万トークンあたり $0.15-$60 なので、規模を出せばローカル推論は早めに元が取れます。
Previous Posts:
- MCP がローカル agent workflow にどうフィットして、なぜそれがツール接続のデフォルト層になりつつあるのかを知りたいなら、次はこちら：What Is MCP AI Tool Connection Standard
- ローカル agent を動かすことと、ワークフローや運用上の記憶をセッション間で保存することは別の話です——その溝をもっと深く掘った記事：Claude Code Local Skills Memory Persistence
- セルフホスト型ワークフローのために、OpenClaw とより新しい memory 志向の agent システムを比較したい？このトレードオフの比較が本文の議論に直結します：Hermes Agent vs Evomap Agent Memory
- 実用的なローカル agent スタックを評価したいなら、MCP、CLI runtime、GEP レイヤーを切り分けて解説したこの記事が、より明確なアーキテクチャ図を与えてくれます：MCP CLI GEP Three Layers Agent Stack
- 今日のローカル agent の最大の限界はモデル品質だけではなく——セッション間の能力再利用です。この学習ギャップをこちらでより詳しく扱っています：ARC AGI 3 Agent Learning Gap GEP
