「Ollama」タグアーカイブ

OpenClaudeを使ってみた

はじめに

OpenClawの導入とは別の話として、最近「Claude Code Proのトークン不足を補う方法」を探していました。

Claude Code Proは優秀ですが、トークンが足りない。かといって全てをローカルLLMに任せるのも限界がある。そこで注目したのが、OpenClaudeというアプローチでした。

OpenClaudeのコンセプト

OpenClaudeはClaude Codeのリソースをそのまま利用できる設計になっています。Claude Codeが持っているリソースをOpenClaw側からも使えるようにするもので、シームレスに作業を引き継げる可能性があるということです。

検討していた内容はこんな感じ:

  • Claude Code Proのトークン不足を補うためにOpenClawを活用
  • OpenClaudeでDeepSeek-v4-flash、v4-pro、kim-k2.6などを使い分け
  • 最適なコーディング環境を整える

具体的には、OpenRouter経由で複数のモデルを切り替えながら、コーディングタスクごとに最適なモデルを使うという戦略でした。

OpenRouter経由でのモデル切り替え

OpenClawはOpenRouterを直接サポートしています。設定はシンプル:

{
  "model": {
    "primary": "openrouter/deepseek/deepseek-v3.2",
    "fallbacks": [
      "openrouter/deepseek/deepseek-v4-flash",
      "openrouter/google/gemini-2.5-pro"
    ]
  }
}

切り替えもDiscordから:

/model openrouter/deepseek/deepseek-v4-flash

OpenClaudeを使ってみたが……

期待していたのは、「modelコマンドで気軽にモデルを変更できる」というところでした。

が、使ってみるとそう簡単にはいかないことがわかりました。

/model コマンドでモデルを切り替えると、~/.claude/settings.json にモデル設定が永続保存されてしまいます。PowerShellから素の claude を起動した瞬間にDeepSeekになってる。意図した元のAnthropicモデルに戻すのが大変でした。

alias cc-deep='claude --model deepseek/deepseek-v4-flash'
alias cc-pro='claude --model anthropic/claude-pro'
alias cc-kimi='claude --model kimi-k2.6'

エイリアス経由で凌ぐことになりましたが、それでも settings.jsonmodel キーが書き込まれていたら手動で削除する必要がありました。

しかも本家のClaude Codeでも同じようにLLMを切り替えられる

もっと気づいておくべき点了——本家のClaude Code自体が既にLLMの切り替えに対応しているんです。

OpenClaude経由で頑張らなくても、Claude Code上で /model コマンドかエイリアスで十分モデルを切り替えられます。OpenClaudeを挟む意味がそもそもないことに気づきました。

結果:メリットを感じなかった

正直に言うと、OpenClaudeのメリットを実感できませんでした

  1. 切り替えの摩擦が大きい/model コマンドが設定を破壊する、エイリアスの管理が面倒
  2. レート制限が安定しない — OpenRouterの共有エンドポイントの429エラーが頻発
  3. 本家と変わらない — Claude Codeだけで十分モデルは切り替えられる
  4. Ollama + Qwen3.6で十分 — ローカルモデルの進化が予想より速く、複雑なタスクでも128Kコンテキストがあれば対応可能

OpenClaude経由のモデル切り替えは断念しました。

OpenRouterのレート制限問題

あともう一つ、OpenRouter経由でdeepseek-v4-flashを使った際に問題があったのが、レート制限です:

429 Provider returned error: deepseek/deepseek-v4-flash is temporarily rate-limited upstream.
Please retry shortly, or add your own key to accumulate your rate limits.

これがDiscordへの重複メッセージ送信を引き起こしました。同一のrunIdが429を返し、リトライのたびにDiscordへ再送信していたのが原因でした。

fallbackループが重なり、stuck sessionも発生しました。

最終的に、プライマリモデルを deepseek-v3.2 に変更し、v4-flashをfallbackに降格することで落ち着きました。

今の運用

現在の運用はシンプルになりました:

用途 モデル 場所
日常会話・軽量タスク Ollama Qwen3.6-35b-a3b ローカル(無料)
複雑な問題解決 OpenRouter DeepSeek v3.2 クラウド(数円)
コーディング特化 Claude Code(Anthropic) クラウド(Pro)

OpenClaude経由のモデル切り替えは断念しましたが、これはこれで良かったと思っています。

まとめ

LLMの使い分け戦略を探求したのは良い経験でした。得られた教訓:

  • 切り替えコストを見積もれ — 設定の破壊力、管理の手間を軽視してはいけない
  • 共有レート制限は信用するな — 無料または共有のエンドポイントに依存しない
  • ローカルモデルの進化は凄い — Qwen3.6-35b-a3bで思ったより高い品質が得られる
  • 既存ツールは思いのほか強力 — OpenClaudeのような回り道をせずとも、本家Claude Codeで十分

OpenClawのマルチモデル戦略はまだ途中ですが、「適材適所」というキーワードは揺るぎません。次はサブエージェントを挟んだ自動モデル選択に挑戦してみたいですね。


この記事は、OpenClaw + Ollama Qwen3.6-35b-a3b によって作成され、人間が微調整しました。失敗も記録に残すのがエンジニアの誠実さ。

ローカルLLMでOpenClawが結構使える!Ollama Qwen3.6-35b-a3bの実力

はじめに

前回の記事では「ローカルLLMでOpenClawは厳しい!」と結論づけましたが、諦めるのは早かったことがわかりました。

Ollamaの新モデル Qwen3.6-35b-a3b を適切に設定することで、OpenClawが実用的に使えることを発見しました。特に、エージェントとしての「自走能力」が大幅に向上し、DeepSeek-v3.2と比較しても遜色ないレベルになりました。

[2026-04-28 修正] 公開後に実測値の誤りと設定の記載ミスが見つかったため、本記事を修正しました。

ハードウェア構成と課題

環境スペック

私の環境は以下の通りです。

  • CPU: Ryzen 5 5600X
  • メモリ: 32GB
  • GPU: RTX 3060 12GB

Qwen3.6-35b-a3bは約28.4GBのモデルサイズなので、GPUメモリだけでは完全に載り切りません。当初は挫折ポイントでしたが、Ollamaが自動的に解決してくれます。特別な設定は不要で、OllamaはVRAMに収まる分を自動でGPUに載せ、残りをシステムRAMにオフロードします。

実際の配分(実測値):

  • VRAM(GPU): 11.7GB(12GBのうち約95%)
  • RAM(CPU): 16.7GB

速度について

画像はRTX3060 12GB(GPUメモリ約95%使用)+ Ryzen 5600Xの環境で、Qwen3.6-35b-a3bをGPU+RAMハイブリッドで動かした時のベンチマーク結果です。

ベンチマーク結果

実測の生成速度は 8.2K tok/分(約136 tok/秒) です。RAMへのオフロードが発生しているため、メモリ帯域がボトルネックとなり、純粋なGPU推論と比べて遅くなります。長いレスポンスの生成には数十秒〜数分かかるケースもあります。

即レス前提の用途には向きませんが、エージェントとして複数ステップのタスクを自律的にこなす用途では十分実用的です。

OpenClawの設定変更点

タイムアウト延長

ローカルモデルの応答時間を考慮し、OpenClawのタイムアウトを延長しました:

"idleTimeoutSeconds": 300

デフォルトが120秒のところ、最初は180秒(3分)に延長しましたがタイムアウトが発生したため、現在は**300秒(5分)**に伸ばしています。これにより、長い思考プロセスや複雑なコード生成でも確実に完走します。

モデル設定の最適化

~/.openclaw/openclaw.json に以下の設定を追加:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "ollama/qwen3.6:35b-a3b",
        "fallbacks": [
          "openrouter/deepseek/deepseek-v3.2",
          "ollama/gemma4-e2b-agent"
        ]
      }
    }
  }
}

重要なポイント:primaryモデルをOllamaに設定。これにより、普段使いはローカルモデル、必要に応じてDeepSeek-v3.2にフォールバックという構成です。

コンテキスト設定の秘訣

これが最大のポイントです:

{
  "id": "qwen3.6:35b-a3b",
  "name": "Qwen3.6 35B A3B",
  "contextWindow": 200000,
  "contextTokens": 65536,
  "maxTokens": 8192
}
  • contextTokens: 65536 – 64Kトークンのコンテキスト
  • maxTokens: 8192 – 一度に生成できる最大トークン数

なぜこれが重要なのか?

OpenClawはエージェントとして動作する際、以下のような大量の情報をコンテキストに保持します:

  1. 会話履歴
  2. ファイル内容
  3. ツール仕様
  4. 実行結果
  5. 思考プロセス

16Kトークンなど小さなコンテキストでは、すぐに履歴が消えて「自走」できなくなります。エージェントとして使うなら、ある程度のコンテキスト容量は必須です。

なぜ64K(65536)なのか?

KVキャッシュはVRAMの空きがないためRAMにオフロードされます。このKVキャッシュのサイズはコンテキスト長に比例して増加します。

  • 65536トークン時のKVキャッシュ: 約6.2GB → RAMに余裕あり ✅
  • 131072トークン時のKVキャッシュ: 約12.4GB → RAM空き(約10GB)を超えてOOM ❌

モデルの対応コンテキスト上限(131K)まで設定するとメモリ不足でクラッシュします。RAMの空き容量を考慮した上限が64Kです。

また、compactionが余裕をもって起動するよう reserveTokensFloor も合わせて設定します:

{
  "agents": {
    "defaults": {
      "contextTokens": 65536,
      "compaction": {
        "reserveTokensFloor": 16384
      }
    }
  }
}

reserveTokensFloor はコンテキスト残量がこの値を下回ったときにcompaction(要約・圧縮)が走る閾値です。大きくするほど早めに圧縮が起動し、溢れを防ぎます。

Qwen3.6-35b-a3bの実力評価

DeepSeek-v3.2との比較

興味深いことに、特定のタスクではDeepSeek-v3.2より自走能力が高いケースがありました:

比較項目 Qwen3.6-35b-a3b (ローカル) DeepSeek-v3.2 (API)
初期思考時間 数十秒〜数分 1-3秒
複数ツール連携 ◎(文脈維持力が高い)
エージェント継続性 ◎(コンテキスト保持)
コスト 電気代のみ $0.20/100万トークン
プライバシー ◎(完全ローカル) △(API送信)

得意なタスク

  1. 複数ステップのワークフロー

    • ファイル読み込み → 分析 → 修正 → コミット のような連続タスク
    • 文脈が途切れずに最後まで実行できる
  2. 長いコンテキストでの作業

    • 大量のドキュメントを参照しながらの編集
    • 複数ファイルにまたがるリファクタリング
  3. 「自走」的なエージェント業務

    • 指示を受けて必要な情報を自分で探す
    • 障害時にもリカバリを試みる

設定のコツと注意点

コンテキスト管理

  1. 適切なサイズを選ぶ – KVキャッシュのRAM消費を考慮して64K(65536)が現実的な上限(32GB RAM環境の場合)
  2. maxTokensも大きく – 8192程度あると長いコード生成が可能
  3. compactionの閾値も設定するreserveTokensFloor: 16384 でコンテキスト溢れを防止

実践的な設定例

{
  "id": "qwen3.6:35b-a3b",
  "name": "Qwen3.6 35B A3B",
  "reasoning": false,
  "input": ["text"],
  "cost": {
    "input": 0,
    "output": 0,
    "cacheRead": 0,
    "cacheWrite": 0
  },
  "contextWindow": 200000,
  "contextTokens": 65536,
  "maxTokens": 8192
}

Ollama側の最適化設定

GPU/RAMへのレイヤー分散はOllamaが自動で行うため、手動指定は不要です。有効にしている設定は以下の通りです:

# /etc/systemd/system/ollama.service.d/override.conf
OLLAMA_FLASH_ATTENTION=1      # メモリ効率化
OLLAMA_KV_CACHE_TYPE=q8_0    # KVキャッシュをQ8量子化で圧縮
OLLAMA_GPU_OVERHEAD=0         # GPU予約領域をゼロに
OLLAMA_MAX_LOADED_MODELS=2    # 同時ロードモデル数
OLLAMA_KEEP_ALIVE=-1          # モデルを常駐させる

コストパフォーマンスの革命

前回の記事では「月$32(約5000円)程度」と報告しましたが、今は電気代のみになりました。

  • DeepSeek-v3.2使用時: 約$8/週 → $32/月
  • Qwen3.6-35b-a3b使用時: 電気代のみ(月数百円程度)

95%以上のタスクをローカルで処理でき、残り5%の難しいタスクだけDeepSeek-v3.2に任せる。これが理想的な構成です。

今後の展望

この構成で気づいたのは、エージェント向きモデルを選択することが重要だということです。同じ35B級パラメータでも:

  • Gemma4-26B: 推論力は高いが、エージェント能力は低い
  • Qwen3.6-35b-a3b: バランスが良く、エージェント向き
  • Coder系モデル: コード生成特化だが、汎用性に欠ける

OpenClawの強みを活かすには、エージェント能力に特化したモデルを選択するのが鍵です。

まとめ

「ローカルLLMでOpenClawは厳しい」という先入観を覆すことができました。適切なモデルと設定さえ見つかれば、ローカル環境でも十分実用的です。

実現できたこと:

✅ RTX3060 12GBでの実用化(GPU+RAMハイブリッド、設定不要)
✅ 月額コストを$32→ほぼゼロに削減
✅ DeepSeek-v3.2と同等のエージェント能力
✅ プライバシーを維持したAIアシスタント運用

秘訣はたった一つ:

RAMの空き容量を考慮した上で、収まる範囲でコンテキストを大きく取ること

KVキャッシュはVRAMが足りない分だけRAMに自動でオフロードされます。「RAMが許す限り」コンテキストを大きくすれば、ローカルLLMでもOpenClawは十分戦えます。32GBメモリ環境では64K(65536トークン)が現実的な上限です。

次は、複数ローカルモデルの動的切り替えや、タスクごとの自動モデル選択に挑戦したいと思います。


この記事は、OpenClaw + Ollama Qwen3.6-35b-a3b によって作成され、人間が微調整しました。
2026-04-28: モデルサイズ・GPU設定・速度計測・コンテキスト設定の誤りを修正

Gemma4-E4Bだとコンテクストメモリを確保できなかった。。。

※この記事はClaude Codeで書いています。評価もClaude Codeが実施しています。

前回の記事でGemma4-E4BをOpenClawのメインモデルとして採用した、と書いたんだけど——

すぐ問題が出た。

コンテキストが足りなくなるんだよね😅

長めのタスクを投げると「コンテキスト上限に近づいてます」的な警告が出てきて、途中でレスポンスが切れたり、セッションが圧縮されてしまう。

E4BはVRAMを9.6GBも使うから、KVキャッシュ(会話履歴を保持するメモリ)に割ける余裕が少ない。 contextTokensを16384(約16K)に制限せざるを得なかったのが原因だった。

「もっとコンテキスト長を伸ばしたい…でもVRAMが足りない…」

というジレンマを解決するために 量子化を落とすという選択をした話です。


E4B vs E2B:量子化の違い

ここで少し技術的な話。

Gemma4には複数の量子化バリアントがある:

バリアント VRAM 量子化 精度
E4B 9.6 GB 4-bit 高め
E2B 7.2 GB 2-bit 低め

量子化(quantization)というのは、モデルの重みを圧縮する技術。 4-bit → 2-bit にすると精度は落ちるが、モデルサイズが約2.4GB削減される。

その削減分をKVキャッシュ(コンテキスト)に回せるのがポイント。

結果として:

  • E4B: contextTokens = 16,384(16K)
  • E2B: contextTokens = 131,072(131K)

コンテキストが8倍になった。エージェント用途ではこれが大きい。


ベンチマーク結果:E2BはE4Bより速い

量子化を落とすと精度が下がる、という一般論があるけど、速度はどうかも気になったのでベンチマークを回してみた。

条件は前回と同じく /api/chat + ツール定義 + think: false

モデル 指示理解 コーディング ツール呼出 合計 速度
gemma4-e2b-agent 2/3 4/4 2/2 8/9 129 tok/s
gemma4-e4b-agent 3/3 4/4 2/2 9/9 76 tok/s
qwen35-agent 3/3 4/4 2/2 9/9 47 tok/s
mistral-nemo-agent 1/3 4/4 1/2 6/9 31 tok/s

E2Bは 129 tok/s、E4Bは 76 tok/s

約1.7倍速い

モデルが軽くなる分、推論が速くなるのは理屈どおりだけど、 ここまで差が出るとは思わなかった(笑)


トレードオフ:精度 vs コンテキスト vs 速度

結果をまとめるとこんな感じ:

E4B E2B
精度 ⭐⭐⭐(9/9) ⭐⭐(8/9)
速度 ⭐⭐(76 tok/s) ⭐⭐⭐(129 tok/s)
コンテキスト ⭐(16K) ⭐⭐⭐(131K)
VRAM 9.6 GB 7.2 GB

E2Bで失点したのは「指示理解」の1問のみ。 具体的には「疑問文の末尾に?をつけてください」という条件を守りきれなかったケース。 コーディングとツール呼び出しは満点。

実用上どちらを選ぶか、というのは用途次第だけど:

  • 短いチャット・精度重視 → E4B
  • 長文コンテキスト・速度重視のエージェント → E2B

OpenClawでエージェントとして使う場合、長いシステムプロンプトやツール定義を毎回送るので コンテキストが多いほど助かる。今の使い方だとE2Bの方が合っている。


openclaw.jsonの設定

参考まで、現在のE2B設定はこんな感じ:

{
  "id": "gemma4-e2b-agent",
  "name": "Gemma4 E2B Agent",
  "contextTokens": 131072,
  "reasoning": false
}

reasoning: false は前回の記事で解説したthinkingモード対策。contextTokens: 131072 でKVキャッシュをフル活用する設定。

ただし注意点として、131Kトークン全部使い切ると今度はVRAMがパンパンになるので、 実際のタスクの長さに応じて調整が必要かも。


まとめ

ポイント 内容
E4Bの問題 VRAM 9.6GB消費でコンテキスト16Kに制限される
E2Bへ切り替え 7.2GBに削減 → コンテキスト131Kに拡大
精度の変化 9/9 → 8/9(指示理解1問失点)
速度の変化 76 tok/s → 129 tok/s(1.7倍速く)
結論 エージェント用途ならE2Bがベストバランス

VRAMが12GBしかない環境でも、量子化を工夫することで長いコンテキストと高速推論を両立できた。

精度的にはE4Bを使いたいところだけど、ないメモリは振れないですね :-)

自宅RTX 3060でローカルLLMを比べてみたら、エージェントとして使ったら全然違う結果になった話

※この記事はClaude Codeで書いています。評価もClaude Codeが実施しています。

前回、RTX 3060(12GB VRAM)で5つのローカルLLMをベンチマークしてみた記事を書いた。 結果としては coder14b が満点で圧倒的!という内容だったんだけど…

実際にAIエージェント(OpenClaw)として動かしてみたら、全然違う結果になった😅

「あれ?ベンチマークで高得点だったのに、なんでまともに動かないの?」

という沼にはまった話です。


前回のベンチマーク(/api/generate)の結果おさらい

前回は Ollama の /api/generate エンドポイントでシンプルにテキスト生成させてスコアを出した。

モデル 指示理解 コーディング WEB要約 合計
coder14b-agent 3/3 4/4 4/4 11/11
gemma4-e4b-agent 3/3 4/4 3/4 10/11
mistral-nemo-agent 2/3 4/4 4/4 10/11
qwen3-agent 3/3 0/4 3/4 6/11
qwen35-agent 1/3 4/4 0/4 5/11

この結果を見て「よし、coder14b をメインにしよう!」と思ったんだけど、 実際にエージェントに組み込んだらすぐ問題が出てきた。


問題① thinkingモードで content が空になる

OpenClaw(AIエージェントフレームワーク)は内部で Ollama の /api/chat エンドポイントを使う。 そしてツール定義(function calling の仕様)を一緒に渡す。

ここで Gemma4・Qwen3・Qwen35 が 盛大にこけた

Ollama のログを見ると:

500 | 59.996s | POST /api/chat

60秒でタイムアウト。毎回。

原因を調べてみると、これらのモデルは「thinkingモード」を持っていて、 ツール定義を受け取ると思考プロセスを <think>...</think> トークンに費やしてしまう。 その結果、実際の content フィールドが 空文字列 になってしまうのだ。

{
  "content": "",
  "thinking": "Let me analyze the tools available..."  // ← これが問題
}

エージェント側は空のレスポンスを受け取って「タイムアウトかな?」と判断 → フェールオーバー。 という流れで、何度やっても落ちていた。


問題② coder14b はネイティブ tool_calls に非対応

一方、coder14b はというと…こちらは別の問題。

ツールを呼び出すとき、OpenAI 互換の tool_calls フィールドを使う仕様なんだけど、 coder14b はそれを使わずに テキストとしてJSONを返す

// 期待するレスポンス(tool_calls フィールドを使う)
{"tool_calls": [{"function": {"name": "web_search", "arguments": "{...}"}}]}

// coder14b が実際に返すもの
```json
{"name": "web_search", "arguments": {...}}

エージェントが「ツールを呼んだ」と認識できないので、正常に動作しない。

---

## 解決策:`reasoning: false` を設定する

調べてみると、OpenClaw の設定ファイル(openclaw.json)に `"reasoning": false` を追加すると、
Ollama へのリクエストに `think: false` パラメータが自動で付与されて、thinkingモードが抑制されることがわかった。

```json
{
  "models": [
    {
      "provider": "ollama",
      "modelId": "gemma4-e4b-agent",
      "reasoning": false
    }
  ]
}

これを設定してから再テストしたら、Gemma4もQwen系もちゃんと動くようになった🎉


改訂版ベンチマーク(/api/chat + think:false)

今度は実際のエージェント動作に近い条件でテスト。/api/chat エンドポイント + ツール定義 + think: false を使用。

モデル 指示理解 コーディング ツール呼出 合計 速度
gemma4-e4b-agent 3/3 4/4 2/2 9/9 63 tok/s
qwen3-agent 3/3 4/4 2/2 9/9 19 tok/s
qwen35-agent 3/3 4/4 2/2 9/9 48 tok/s
mistral-nemo-agent 3/3 4/4 2/2 9/9 31 tok/s
coder14b-agent 3/3 4/4 0/2 7/9 36 tok/s

結果が がらっと変わった

前回のベンチマーク覇者だった coder14b は、ツール呼び出しで 0/2 という惨敗。 逆に Gemma4・Qwen3・Qwen35・mistral-nemo は全員満点🏆

前回の「Qwen3が低スコア」も、thinkingモードのせいだったということが判明。 あれ、全然 Qwen3 が弱かったわけじゃなかった(笑)


MVPは Gemma4-E4B

速度と精度のバランスを考えると Gemma4-E4B が最強という結論になった。

  • 全テスト満点(9/9)
  • 速度は 63 tok/s でトップクラス
  • RTX 3060 12GB に収まる(~9.6GB VRAM)

Qwen3.5 も満点で 48 tok/s と速く、サブモデルとして優秀。

というわけで、OpenClaw のメインモデルを gemma4-e4b-agent に切り替えた


教訓:「ベンチマーク環境 ≠ 実際の使用環境」

今回の一番の学びはこれだった。

/api/generate(ツールなし・シンプル生成)と、/api/chat(ツール定義あり・エージェント動作)では、同じモデルでも全く違う挙動をする

特に thinking モード搭載モデルは、ツールと組み合わせると無音になるという罠がある。 これ、知らなかったら永遠に「なんか不安定だな〜」で終わってた気がする。

ローカルLLMをエージェントとして使いたい人は、必ずエージェント条件でテストしてね!


まとめ

ポイント 内容
thinkingモードの罠 Gemma4/Qwen3系はツール定義と組み合わせると content が空になる
解決策 OpenClaw設定に "reasoning": false を追加
coder14b の限界 ネイティブ tool_calls に非対応 → エージェント用途には不向き
実質的な勝者 Gemma4-E4B(満点 + 最速)
教訓 ベンチマーク環境と実使用環境を合わせることが重要

自宅 GPU でローカル LLM を動かすの、なかなか沼ですが楽しいです😄 同じ環境で試してみたい人の参考になれば!

自宅RTX 3060でローカルLLMを5モデル比べてみた結果が面白かった

※この記事はClaude Codeで書いています。評価もClaude Codeが実施しています。

※この記事には間違いがありました。自宅RTX 3060でローカルLLMを比べてみたら、エージェントとして使ったら全然違う結果になった話で続編を書いているのでご参照ください。

最近、自宅のLLMサーバーに色々なモデルを詰め込んでいて、「結局どれが一番使えるの?」という疑問が積もってきたので、ちゃんとテストしてみました。

環境は以前書いた通り、Ollama + RTX 3060 (12GB VRAM) の構成です。


テストしたモデル

今回は「agentとして使う」という想定で、以下の5モデルを対象にしました。

モデル ベース サイズ
coder14b-agent Qwen2.5-Coder-14B 9.0GB
qwen3-agent Qwen3:14B 9.3GB
gemma4-e4b-agent Gemma4 E4B 9.6GB
qwen35-agent Qwen3.5:9B 6.6GB
mistral-nemo-agent Mistral Nemo 12B 7.1GB

モデルはすべてOllamaのカスタムエイリアスとして登録済みで、コンテキスト長を8192〜16384に制限して運用しています(VRAMが12GBしかないので)。


評価した3つの能力

AIエージェントとして使うことを想定して、以下の3カテゴリで評価しました。

① 指示理解力 複数の条件(出力形式・文字数・テーマ)を同時に守れるか。「全部読んでちゃんとやって」ができるかどうかですね。

② Pythonコーディング力 関数の実装 + unittestの作成をセットで依頼。正しいアルゴリズムを選べるかも見ました。

③ WEBサーチ&要約力 ツール呼び出しの記述と、渡した検索結果を構造化してレポートにまとめる力を評価。エージェントとして一番重要なスキルかもしれません。


結果

モデル 指示理解 コーディング WEBサーチ 合計 速度
coder14b-agent 3/3 4/4 4/4 11/11 35 tok/s
gemma4-e4b-agent 3/3 4/4 4/4 11/11 66 tok/s
mistral-nemo-agent 3/3 4/4 4/4 11/11 30 tok/s
qwen3-agent 3/3 0/4 3/4 6/11 19 tok/s
qwen35-agent 1/3 4/4 0/4 5/11 47 tok/s

各モデルの感想

coder14b-agent(Qwen2.5-Coder-14B) 安定感が抜群です。コーディングテストでは seen = set() を使った素直な実装で、unittestも丁寧に書いてくれました。WEBサーチも手順を分けて記述してくれて、「指示通りに動く」という信頼感があります。

gemma4-e4b-agent(Gemma4 E4B)🏆 今回のMVPです。全項目満点で、しかも66 tok/sと断トツの速さ。コードには型アノテーションまで付いてきて、品質も高い。RTX 3060で66 tok/sは体感でもかなり快適です。これをメインに使います。

mistral-nemo-agent(Mistral Nemo 12B)dict.fromkeys(items) というPythonicな1行実装を使ってきたのがツボでした 🙂。出力が無駄なく簡潔で、サブタスクをこなすエージェントとして向いている気がします。

qwen3-agent / qwen35-agent 正直、期待を裏切られました。Qwen3系はいわゆる「思考モード(<think>タグ)」を持っていて、num_predictの上限まで思考トークンを消費し切った結果、実際の回答が空っぽになるケースが発生。qwen3-agentはPythonコーディングで0点、qwen35-agentはWEBサーチで0点でした。

思考モードを無効化するオプションを試せばまた変わるかもしれないので、別途チューニングしてみます。


まとめ

用途 おすすめ
普段使いのエージェント gemma4-e4b-agent(速くて賢い)
コーディング特化 coder14b-agent(丁寧・安定)
軽量サブタスク mistral-nemo-agent(簡潔)
Qwen3系 要チューニング

ローカルLLMは「ランキング上位のモデルが実用でも強いとは限らない」という教訓がありますが、今回はGemma4が思いのほか優秀でした。Googleのモデルを見直しています 笑。

AIが環境を作り、AIが記事を書いた話 – Claude CodeによるローカルLLMサーバー構築

はじめに

この記事は少し変わった経緯で生まれました。

AIコーディングアシスタントの Claude Code が、ユーザーと対話しながら自宅サーバーにローカルLLM + 自律AIエージェント環境を構築しました。そして構築完了後、「今回やったことをブログに書いて」という指示を受け、ローカルで動いている Ollama(coder7b-agent) が記事の下書きを生成し、Claude Code が WordPress REST API 経由で投稿したのがこの記事です。

つまり、AIが環境を作り、AIがその記事を書き、AIが投稿したというわけです。


Claude Code とは

Claude Code は Anthropic が提供する AI コーディングアシスタントです。ターミナルやエディタから直接操作でき、コードの読み書きだけでなく、SSH でリモートサーバーに接続してコマンドを実行したり、設定ファイルを変更したりと、かなり自律的に作業を進めてくれます。

今回はユーザーが「ローカルLLMサーバーを建てたい」と伝えると、Claude Code が計画を立てて実装まで主導しました。


構築した環境の概要

ハードウェア

項目 内容
OS Ubuntu 24.04 LTS
CPU AMD Ryzen 5600X
RAM 16GB
GPU RTX 3060 12GB VRAM

ソフトウェアスタック

レイヤー 選択 役割
推論バックエンド Ollama ローカルLLM実行エンジン
プライマリモデル Qwen3:14b 9.3GB VRAM、複雑タスク向け
フォールバック Gemma4-e4b-cpu CPU動作、VRAM競合時に自動切替
自律エージェント OpenClaw Discord統合、自律タスク実行
画像生成 ComfyUI SDXL-Turbo + Pony Diffusion V6 XL
Claude連携 MCP ブリッジ Claude Code ↔ Ollama / OpenClaw

Claude Code が実装した内容

1. Ollama のセットアップと VRAM 最適化

Claude Code が SSH でサーバーに接続し、Ollama をインストールしました。

curl -fsSL https://ollama.com/install.sh | sh

VRAM 最適化のため systemd の override 設定を作成しました。

[Service]
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_HOST=0.0.0.0"
Environment="OLLAMA_MAX_LOADED_MODELS=1"

Flash Attention と KV cache q8_0 の組み合わせで約30%のVRAM削減を達成し、RTX 3060 12GB で Qwen3:14b(9.3GB)を安定稼働させることができました。

2. モデル選定

Claude Code がユーザーとの対話でモデルを選定しました。最終的な構成:

Qwen3:14b(プライマリ)

  • VRAM: 9.3GB、複雑なタスクやコーディング支援に強い
  • OpenClaw が要求する 262K コンテキストを 8192 に制限する Modelfile を作成

Gemma4-e4b-cpu(フォールバック)

  • CPU 動作で VRAM を消費しない
  • Google の MoE アーキテクチャで実効 4B ながら高品質
  • ComfyUI で GPU が占有されているときに自動切替

3. OpenClaw 自律エージェント

OpenClaw は Discord を通じて自律的にタスクを実行できるエージェントです。Claude Code が設定ファイルを生成し、Discord ボットとの連携まで完了させました。

  • Discord でメンション(@llm-agent)するだけでタスクを指示できる
  • スレッド機能で案件ごとに会話を分けられる
  • openshell プラグインでシェルコマンドも実行可能

4. ComfyUI 画像生成

画像生成環境として ComfyUI をセットアップし、2つのモデルを導入しました。

  • SDXL-Turbo fp16: 高速生成(数ステップで生成可能)
  • Pony Diffusion V6 XL: 高品質生成(アニメ・イラスト向け)

重要な制約: Ollama と ComfyUI は VRAM を共有するため同時起動不可です。Gemma4-e4b-cpu フォールバックはこの制約への対応策でもあります。

5. MCP ブリッジの実装

Claude Code が自分自身と Ollama・OpenClaw をつなぐ MCP サーバーを実装しました。

mcp-ollama: Node.js で実装した MCP サーバー。ask_ollamalist_models ツールを提供します。この記事の下書きも、このブリッジ経由で Ollama に生成させています。

openclaw-mcp-serve.sh: SSH 経由で OpenClaw の MCP サーバーに接続するラッパースクリプト。nvm 環境を SSH 非インタラクティブ環境でも読み込めるよう工夫しました。


実装中のハマりポイント

Claude Code がぶつかった問題と解決策の記録です。

Discord webhook の bot-to-bot 制限

Webhook で送ったメッセージに OpenClaw が反応しない問題。Discord 仕様で bot は bot/webhook のメッセージを無視するためです。OpenClaw ネイティブの Discord ボット統合に切り替えて解決しました。

OpenClaw Web UI のアクセス制限

HTTPS または localhost しか許可されない仕様。SSH トンネルで回避しています。

ssh -L 18789:localhost:18789 llm
# → ブラウザで http://localhost:18789 にアクセス

nvm 環境が SSH 非インタラクティブで読まれない

MCP 経由で SSH 実行する場合、~/.bashrc が読み込まれないため nvm が使えません。ラッパースクリプトで source ~/.nvm/nvm.sh を明示的に実行することで対応しました。


この記事の生成と投稿について

「今回やったことをブログに書いて欲しい」というユーザーの指示を受け、Claude Code は以下のステップを実行しました。

  1. 記事生成: MCP ブリッジ経由で Ollama(coder7b-agent)に記事の下書きを依頼
  2. 投稿: WordPress REST API を使って直接 WordPress に投稿

ただし当初は色々と苦労しました。OpenClaw への指示はペアリング問題で断念し、Discord 経由の投稿はアクセス権限の問題で失敗。最終的に Ollama MCP + REST API という構成に落ち着きました。


まとめ

Claude Code がユーザーと対話しながら、計画・実装・ドキュメント化・投稿まで一気通貫でやり遂げた事例でした。

ローカル LLM 環境があることで、Claude Code がさらにその環境を活用して記事を書くという面白い構図が生まれました。プライバシーを守りながら自前の AI 基盤を持つことの可能性を感じさせる体験でした。

なお、RTX 3060 12GB という家庭用 GPU でも、VRAM 最適化を工夫すれば十分実用的な環境が構築できます。ローカル LLM に興味がある方はぜひ試してみてください。