ローカルLLMでAIエージェントは動くのか — Ollamaで作るオフライン・エージェント実験

去年の夏、ローカルLLMとクラウドLLMの品質差という記事を書きました。あのときの結論は「チャット用途ならローカルでも実用域に入りつつある。ただし込み入った推論はクラウドに分がある」というものでした。

あれから1年、質問の形が変わってきました。「チャットで使えるか」ではなく「エージェントとして使えるか」を聞かれます。要するに、LLMに人間が話しかけるのではなく、LLMがツールを呼び、結果を見て、次の手を自分で決める——あの使い方です。

これは同じ「LLMを動かす」でも要求水準がまるで違います。本記事ではその違いを整理したうえで、Ollamaを使ったローカル・エージェント環境の作り方と、誰でも同じ手順で再現できる評価設計を書きます。

1. エージェント用途はチャット用途より要求が厳しい

まず、なぜ「チャットで使えた＝エージェントで使える」にならないのか。3つの壁があります。

1-1. ツール呼び出しのJSONは「だいたい合っている」では通らない

チャットの回答は、多少言い回しが不自然でも人間が読んで補正できます。ところがツール呼び出しは違います。出力されたJSONはそのままパーサに食わせるので、1文字ずれれば実行時エラーです。

ローカルモデルで実際によく見る失敗パターンを挙げます。

重要なのは、これらは「モデルが賢いかどうか」とは別軸の問題だということです。文章としては的確な判断をしているのに、出力フォーマットの規律だけが緩い——というモデルは珍しくありません。だからこそ、後述するようにフォーマット逸脱はランタイム側で吸収できる余地がかなりあります。

1-2. 数十ターンの自律ループに耐える一貫性

エージェントの1回の仕事は、1回の推論では終わりません。「ファイルを探す → 中身を読む → 判断する → 書き換える → 確認する」で最低5ターン。実務的なタスクなら20〜40ターン回ることもざらです。

ここで効いてくるのが誤差の累積です。1ターンあたりの成功率が仮に95%だとしても、20ターン連続で成功する確率は 0.95²⁰ ≒ 36%。1ターン99%なら20ターンで82%です。つまりエージェント用途では、1ターンあたりの精度がわずかに違うだけで完走率が桁違いに変わる。

加えて、ターンが進むほど「自分がさっき何をしたか」を見失うモデルがあります。同じファイルを3回読み直す、一度失敗したアプローチを何度も繰り返す、といった挙動です。これは次の長コンテキスト問題と地続きです。

1-3. 長いコンテキストの実効的な扱い

エージェントの会話履歴は膨らみます。ツールの実行結果——ファイルの中身、コマンドの標準出力、検索結果——が全部履歴に積まれるからです。10ターンも回れば数万トークンに達します。

ここで注意したいのが、Ollamaのデフォルト・コンテキスト長です。モデルカードが128Kと書いていても、Ollamaの実行時パラメータ num_ctx はモデルのModelfile依存で、それよりずっと小さい値になっていることがあります。この場合、あふれた古い履歴は静かに切り捨てられます。

エラーは出ません。エージェントは「最初に何をしろと言われたか」を忘れたまま、それらしく動き続けます。ローカルエージェントのデバッグで最初に疑うべきポイントです。確認コマンドは後述します。

そしてもう一点。num_ctx を大きくすればKVキャッシュがVRAMを食います。7Bモデルを16GBのGPUに載せて余裕だと思っていたら、コンテキストを伸ばした途端にCPUへオフロードされて激烈に遅くなる——これも定番です。モデルサイズだけ見て「載る／載らない」を判断してはいけません。

2. 検証環境の作り方（WSL2 + Ollama）

ここからは環境構築です。WSL2上でNode環境を組む記事やWSL2にSSHで入る記事で書いたノウハウをそのまま流用できます。

2-1. インストールと起動確認

# WSL2のUbuntu上で実行
curl -fsSL https://ollama.com/install.sh | sh

# サービスとして起動しているか確認
systemctl status ollama

# WSL2でsystemdを使っていない場合は手動起動
ollama serve &

# 疎通確認
curl -s http://localhost:11434/api/tags | head

2-2. GPUがWSL2から見えているかを最初に確認する

WSL2はホストWindowsのGPUをパススルーできますが、ドライバの状態次第では静かにCPU実行にフォールバックします。「なんとなく遅い」の原因の大半はこれです。

# NVIDIA GPUがWSL2から見えているか
nvidia-smi

# Ollamaが実際にGPUを使っているか（モデル実行中に確認）
ollama ps

ollama ps の PROCESSOR 列が 100% GPU でなく CPU や 48%/52% CPU/GPU になっていたら、VRAMに載りきっていないということです。この状態で速度を測っても意味がありません。評価の前に必ず確認してください。

2-3. コンテキスト長を明示する

前述の「静かな切り捨て」を避けるため、コンテキスト長は必ず明示します。

# 現在のモデルのパラメータを確認
ollama show --parameters <モデル名>

# APIで明示指定する（推奨）
curl -s http://localhost:11434/api/chat -d '{
  "model": "<モデル名>",
  "messages": [{"role": "user", "content": "ping"}],
  "options": { "num_ctx": 32768 },
  "stream": false
}'

あるいはModelfileで固定してしまう方法もあります。

# Modelfile
FROM <ベースモデル名>
PARAMETER num_ctx 32768
PARAMETER temperature 0

ollama create agent-eval -f Modelfile

評価時は temperature 0 を推奨します。再現性が取れないと、比較にならないからです。実運用でどうするかは別の判断ですが、ベンチマークは固定してください。

2-4. モデル選定の観点（7B〜70B）

「どのモデルがいいですか」と聞かれますが、これはハードウェアの制約が先に来る話です。まず載るサイズを決めて、その中で選ぶという順序になります。

※ 重みサイズは4bit量子化での一般的な目安であり、量子化方式やモデルアーキテクチャで変動します。実際の所要VRAMは重み＋KVキャッシュ＋オーバーヘッドなので、この数字より確実に大きくなります。

そのうえで、エージェント用途ではサイズ以外に見るべき軸があります。

• ツール呼び出しの学習を受けているか — 同一サイズでも、tool useを含むデータで訓練されたモデルとそうでないモデルではJSON生成の安定度がまるで違います。モデルカードで tools 対応の記載を確認してください
• Ollamaの tools APIに対応しているか — 対応していないモデルはプロンプトでツール定義を書く自前実装になり、逸脱率が跳ね上がります
• 実効コンテキスト長 — 宣伝上の最大長ではなく、自分のVRAMで確保できる長さ
• 日本語の指示追従 — 日本語で指示して英語で思考すること自体は問題ありませんが、最終出力の言語が安定しないとパイプラインが崩れます
• ライセンス — 業務投入なら必ず。商用利用条件はモデルごとに本当にバラバラです

3. 検証タスクと評価設計【実測は未実施】

冒頭に書いたとおり、今回の執筆環境ではOllamaを動かせなかったため、以下に実測値はありません。ここに書くのは、私が実際に測るときに使う評価設計です。そのまま流用できるように、判定条件まで落として書きます。

3-1. 3つの評価タスク

タスク1：ファイル操作エージェント

与えるツールは list_files / read_file / write_file / grep の4つ。指示は「このディレクトリ配下で TODO: を含む行を全部探して、todo-report.md にファイル名と行番号つきでまとめて」。

このタスクが測っているもの: ツール選択の妥当性、引数の正確さ、複数ファイルにまたがる状態保持。テキスト処理の難易度は低く、純粋に「ツールを正しく回せるか」だけを見る設計です。ここで落ちるモデルは他の2つも通りません。最初のふるいとして使います。

タスク2：Web検索→要約パイプライン

ツールは search（クエリ→タイトル・URL・スニペットのリスト）と fetch_page（URL→本文テキスト）。指示は「◯◯について調べて、出典URL付きで500字にまとめて」。

このタスクが測っているもの: 長いコンテキストの実効的な扱いと、情報の取捨選択。fetch_page の戻り値は数千トークンになるので、2〜3ページ読んだ時点でコンテキストを圧迫します。ここで「最初の指示を忘れる」現象が出るかどうかが観測ポイントです。

タスク3：コード修正タスク

意図的にバグを1つ仕込んだ小さなスクリプトと、失敗するテストを渡します。ツールは read_file / write_file / run_tests。指示は「テストが通るように直して」。

このタスクが測っているもの: 失敗フィードバックからの自己修正。エージェントらしさが一番出るのはここです。テストが落ちたときに別のアプローチを試せるか、同じ修正を繰り返すかで、実用性がはっきり分かれます。

3-2. 記録する指標

「なんとなく賢い」では比較になりません。以下を機械的に記録します。

Ollamaのレスポンスには測定に使えるフィールドが入っています。

# 1リクエストの生成速度を測る
curl -s http://localhost:11434/api/chat -d '{
  "model": "<モデル名>",
  "messages": [{"role":"user","content":"..."}],
  "options": {"num_ctx": 32768, "temperature": 0},
  "stream": false
}' | python3 -c "import sys,json; d=json.load(sys.stdin); \
print('tok/s:', d['eval_count'] / (d['eval_duration']/1e9))"

3-3. 結果表のフォーマット

測った結果は、こういう形で残します。下表は空欄のテンプレートです。数値は入れていません。

表には必ず測定環境（GPU型番、VRAM容量、量子化方式、num_ctx、Ollamaのバージョン、試行回数）を併記してください。これがないと、他人の数字と比べようがありません。ネット上のローカルLLMベンチマークが噛み合わないのは、たいていこの記載が欠けているからです。

3-4. 測る前に打っておく手

フォーマット逸脱の多くは、モデルを変えなくてもランタイム側で減らせます。素の状態で測って「使えない」と結論づける前に、以下をやってください。

• Structured Outputs / JSON Schemaを使う — Ollamaは format にJSON Schemaを渡せます。前置きやMarkdownフェンスの混入はこれでほぼ消えます
• ツール数を絞る — 20個のツール定義を毎ターン読ませると、小さいモデルほど選択を誤ります。タスクごとに必要な3〜5個に絞る
• エラーを本文として返す — 検証に失敗したら例外を投げるのではなく、「引数 path が必須です」というメッセージをツール実行結果として返し、モデルに再試行させる
• 履歴を圧縮する — 古いツール実行結果を要約に置き換える。エージェントの記憶設計の記事で書いた考え方が、ローカルでは容量制約が厳しいぶんより効きます
• ループ上限とタイムアウトを必ず入れる — ガードレール設計の記事に書いたとおりです。ローカルは課金が発生しないぶん暴走に気づきにくく、むしろ危険です

4. ローカルエージェントが「アリ」なユースケース

ここまで制約の話が続きましたが、制約を理解したうえで当てはめれば、ローカルエージェントが明確に有利な領域があります。

4-1. 機密データの一次処理

これが最も分かりやすい適用先です。顧客情報を含むログ、社内の人事文書、医療・法務のドキュメント——そもそも外部APIに投げられないデータがあります。

ここでローカルLLMに任せるのは「一次処理」です。個人情報のマスキング、文書の分類、機密度のタグ付け。これらは推論の難易度が低く、小さいモデルでも十分こなせる作業です。マスキング済みのデータになって初めてクラウドに渡す、という設計にすれば、高度な推論はクラウドの力を借りられます。

4-2. 夜間バッチ的な非対話タスク

ローカルLLMの弱点は速度ですが、誰も待っていない処理なら速度は問題になりません。

夜間に走らせて朝にレポートができていればいい、という種類の仕事——大量ドキュメントの分類、ログの異常検知、定期的な要約——はローカルの独壇場です。マシンは眠っているだけなので、電気代以外のコストはゼロ。クラウドAPIなら数万トークン×件数分の課金が乗ります。

4-3. ハイブリッド構成：計画はクラウド、実行はローカル

実務で一番使える形がこれです。難しい判断だけクラウドの大きなモデルに任せ、決まった作業の反復はローカルで回す。

この構成のポイントは、クラウドに渡す情報の粒度を設計側でコントロールできることです。「顧客Aの契約書の3条が…」ではなく「契約書カテゴリの文書について、条項の抽出手順を示せ」と抽象化して聞く。返ってきた手順をローカルが具体的なデータに適用する。

ただし注意点があります。計画が曖昧だとローカル側が破綻します。クラウドの大きなモデルは行間を読んで進めますが、ローカルの小さいモデルは書いてある通りにしか動きません。計画のステップは「7Bモデルでも解釈が一意になる粒度」まで具体化する必要があります。ここが設計者の腕の見せどころです。

4-4. 逆に、ローカルを選ぶべきでない場面

公平を期すために書いておきます。

• 対話型で人間が待っている — 応答が数十秒かかる時点で体験が破綻します
• タスクの内容が毎回違う — 定型化できない仕事は、そのつど高度な判断が要ります
• 長い自律ループが必須 — 20ターン以上を安定して回すのは、現状ローカルには厳しい領域です
• 試行回数が少ない — 月に数回しか動かさないなら、GPUを買う理由がありません（次章）

5. コストの損益分岐点をどう計算するか

「ローカルなら無料」は正確ではありません。初期投資と電気代があり、何より運用の手間があります。ここも数字を捏造せず、計算式で示します。

5-1. 損益分岐の考え方

ローカルの月額コスト
  = GPU等の初期投資 ÷ 償却月数
  + 消費電力(kW) × 稼働時間(h/月) × 電力単価(円/kWh)
  + 運用工数(h/月) × 時間単価

クラウドの月額コスト
  = 月間タスク数 × 1タスクあたり平均トークン数 × 単価

損益分岐点：上の2式が一致する「月間タスク数」

この式に自分の数字を入れてください。私が数字を入れないのは、どれも読者ごとに桁が違うからです。GPUを既に持っている人と新規購入する人では初期投資がゼロと数十万で違いますし、電力単価も契約次第、モデルの単価は日々変わります。

5-2. 見落とされがちな項目

6. まとめ

本記事の要点を整理します。

• エージェント用途はチャット用途と評価軸が違う。1ターンの精度が掛け算で効くので、チャットで十分だったモデルが通用しないことがある
• ローカル特有の落とし穴は「静かな失敗」。num_ctx による履歴の切り捨てとCPUフォールバックは、エラーを出さずに品質と速度を殺す。ollama ps と ollama show --parameters をまず確認
• モデル選定はサイズが先、中身が後。載らないモデルは検討対象になりません。載るサイズの中で、tool use対応・実効コンテキスト・ライセンスを見る
• 評価は自分の環境で、最低5試行、条件を明記して。他人のベンチマークは環境が違えば参考にすらならない
• ハイブリッド構成が実務解。計画はクラウド、反復実行はローカル。ただし計画の粒度は「小さいモデルでも一意に解釈できる」ところまで落とす
• ローカルを選ぶ理由の多くはコストではなく制約。データを外に出せないなら、損益分岐の計算より先に「動くかどうか」を確かめるべき

最後にもう一度。この記事に実測値がないのは、測れなかったからです。数字を出せば記事としては見栄えがしますが、根拠のない数字は読者の判断を狂わせるだけで、何の価値もありません。

そして正直なところ、ローカルLLMのエージェント性能に関しては、他人の実測値もそこまで役に立ちません。GPUが違い、量子化が違い、num_ctx が違い、ツール設計が違えば、結果は簡単に逆転します。本記事の評価設計を使って、ご自身の環境で、ご自身のタスクで測ってください。それが唯一、意思決定に使える数字です。

環境が整い次第、同じ設計で実測した続編を書く予定です。