「Qwen」タグアーカイブ

Hermes Agent + Qwen36-35B-A3B に「自律修正」を任せてみた

VPS上で動かしているFXボット群の監視・改善を、Hermes AgentにQwen3-35B-A3Bを載せて自律的にやらせてみた。指示は「問題を見つけたら自分で直せ」。結果は「発見はできる。修正は荷が重かった」。


何をやらせたか

VPS上で複数のFXボット(bot_pattern、bot_gmo、bot_ha_ema など)が稼働している。
Hermes Agentに「ログやコードを見て、問題を自発的に発見・修正せよ」という自律タスクを与えた。

モデルはQwen36-35B-A3B(Mixture-of-Experts、アクティブ3B/総35B)。
ローカルで動かせるサイズ感でエージェントに使うには悪くない選択肢のはず…だった。


Hermes Agentが出した報告

「GMO APIにレートリミットが出ている」

Hermes Agentが真っ先に報告してきた内容がこれ。「HTTPステータス429が大量発生している」と。

実際にVPS上のログを精査すると――

18:15:34,429 [INFO] ...

ログのタイムスタンプのミリ秒部分だった。34,429,429 を HTTP 429 と読み間違えた。

実際のAPIアクセス数は約500〜700回/日。GMO公式制限(GET 6回/秒 ≒ 518,000回/日)の0.1%以下で、レートリミットは欠片も発生していなかった。

ERR-5218(取引時間外発注)の連続発生

429誤報の調査中に、今度は本物の問題を見つけてきた。

bot_mtf_tb_eurusd が週末(土曜07:00〜月曜07:00 JST)にもGMO APIへ発注リクエストを送り続け、ERR-5218: The order was rejected for trading close. が4時間おきに9回連続発生していた。

2026-05-16 20:30 [ERROR] 発注失敗: ERR-5218
2026-05-17 00:30 [ERROR] 発注失敗: ERR-5218
2026-05-17 04:30 [ERROR] 発注失敗: ERR-5218
...(9回)

dry-runのため実損はないが、無駄なAPI呼び出しとログ汚染が続いていた。これは正真正銘の問題


修正フェーズで何が起きたか

「修正せよ」と指示していたので、Hermes Agentはコードに手を入れた。

しかし確認すると、Git管理外で直接ファイルを書き換えていたgit status には何も出ないが、実ファイルは変更済みという状態。発見後、git stash で退避して git pull で正しいリビジョンに戻した。

修正内容の方向性は間違っていなかった(取引時間チェックを入れるべき、という判断は正しい)。ただし実装をGitフローに乗せられなかった。コミットもなく、レビューも通っていない変更がVPSに存在している状態は困る。

実際の修正は自分でやった。_is_market_open() を追加して run_once 冒頭でスキップ処理を挟むだけなので5分で終わった。

def _is_market_open(now_jst: datetime) -> bool:
    wd = now_jst.weekday()  # 0=月 … 5=土, 6=日
    if wd == 6:  # 日曜は終日クローズ
        return False
    if wd == 5:  # 土曜06:55以降はクローズ
        return now_jst.hour < 6 or (now_jst.hour == 6 and now_jst.minute < 55)
    return True

わかったこと

発見は得意、修正は荷が重い。

タスク 結果
ログの異常パターン検出 △(誤認あり)
本物のバグ発見 ○(ERR-5218を発見)
修正方針の立案 ○(方向性は正しかった)
Gitフローに沿った実装 ✗(管理外変更)

Qwen36-35B-A3Bのサイズでエージェントとして動かすと、「何かを見つけて報告する」は回るが、「コードの文脈を保ちながら適切に変更を加えてGitに乗せる」はまだ確率が低い。ツール呼び出しの連鎖が長くなるほど途中でコンテキストが崩れる感覚がある。


次の方針

Hermes Agentの役割を「発見専門」に絞る。

  • 発見 → Hermes Agentがチケットを起票して終了
  • 修正 → 人間(または別途レビューを通したエージェント)が実施

「自律修正」はまだ早かった。でも「自律発見」は普通に役立つ。今回もERR-5218は放置していたら次の週末まで気づかなかったと思う。


検証環境: VPS (Ubuntu) / Hermes Agent / Qwen36-35B-A3B / GMO クリック証券 FX API

Hermes Agentにも手を出してみました(笑)

最近、Hermes AgentOpenClawの両方を触って比べてみたのですが、いくつか明確な違いがあって、個人的にはかなり衝撃を受けました。

同じモデルでも「自走力」が全然違う

両方とも ローカルのQwen3.6 35B-A3B を使っているにも関わらず、指示に対する自走力に大きな差がありました。 OpenClaw は、ちょっとしたタスクを指示しても「次の一手を教えてもらわないと動けない」印象でしたが、Hermes Agent は30分程度の長時間タスクも普通にこなせるんですよね。

OpenClawでよくあるのがコンテキストを使い果たして回答できなくなるって現象なんですが、足りなくなりそうなら先に手を打つとか、そもそも大量な出力を出すようなコマンドを叩かない、あるいは叩いた後にプレ処理をするといったことをしてくれないので、よくこのメッセージが出てました。

Agent couldn't generate a response. Note: some tool actions may have already been executed — please verify before retrying.

Hermes Agentでは

⏳ Still working... (3 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (6 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (9 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (12 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (15 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (18 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (21 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (24 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (27 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (30 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (33 min elapsed — iteration 1/90, receiving stream response)
⚠️ Model returned empty after tool calls — nudging to continue
⏳ Still working... (36 min elapsed — iteration 2/90, waiting for stream response (60s, no chunks yet))
💻 terminal: "cd /home/ubuntu/.hermes/hermes-agent ..."
🐍 execute_code: "import subprocess result = subprocess..." 
⏳ Still working... (39 min elapsed — iteration 3/90, receiving stream response)
⏳ Still working... (42 min elapsed — iteration 4/90, receiving stream response)・・・

と処理を続けて何とか回答を出してくれるんですよね。

例えば、コードのレビューを指示した際にも、自ら手順を組み立てて実際にツールを呼び、結果を確認し、さらなる改善を提案する。こうした流れが、まるで一人の開発者が傍にいてくれたように進みます。

バグが圧倒的に少ない

実務レベルで使っていると、ツール呼び出しの失敗や出力の破損、意図しない状態遷移などがたまに起こるのですが、Hermes Agent はその点非常に安定していると感じます。エラーが出てもしっかりとしていて対処能力も高いです。OpenClawはほぼ毎日アップデートがリリースが出てて、当てると結構な確率で動かなくなったりするのですが(笑)、Hermes Agentは今のところそういうことはないですね。大体、週1回のアップデートくらいでしょうか。当てても問題なく起動してきます :-)

スレッド間で記憶を引き継ぐのが上手い

これが特に驚いた点なのですが、スレッドを変えても、他のスレッドで知り得た情報をちゃんと保持しているんです。

例えば、前のスレッドで自分のGitHubユーザー名を共有したあと、別スレッドで関連する指示を出しても、ちゃんと文脈が引き継まれていました。

これは、単なるセッションスコープの文脈保持だけでなく、永続的なメモリを駆使したインテリジェントな記憶管理によって実現されているんだろうなと感じます。

発想としてはOpenClawも同じはずなんですが、OpenClawは長期記憶の必要な部分の抽出が得意ではない感じがしますね。 まぁ、「前に教えたよ」って言えば、メモリーを漁って思い出してくれるんですが、結構物忘れの激しい子ってイメージはありますね(笑)

AI + LLM の「PC自作」時代

このツイートを見てHermes Agentに興味を持ったんですが、楽しい時代になりましたね。 → @swarm_japan さんのツイート

最近は、AI がどんどんと進化してきて、LLM と Agent フレームワークを組み合わせて自分でカスタムできるようになってきました。まさにPCの自作みたいな楽しさがそこにはあります。 自分で構成を選んで、パーツを組み合わせて、性能を調整して…といった体験が、もうAIの世界でできているんですよね。これはとてもワクワクします。

まとめ

項目 Hermes Agent OpenClaw
自走力 ◎ (30分タスクもこなす)
バグの少なさ ◎ (安定感が高い)
記憶の引き継ぎ ◎ (スレッド間でインテリジェント)

同じバックボーンモデルを使っていても、フレームワークの設計次第でこれだけ違ってくるんですね。Hermes Agent はその辺りの実装が非常に良くできていて、日常的に使えるレベルの高いAgentだなという印象です。

Agentフレームワークの比較とかカスタム体験に興味がある方は、ぜひ両方触ってみてください。面白い発見があるはずです。

OpenClaw+Ollamaでどうしてもフェールオーバーする

はじめに

前回の記事では、Qwen3.6-35b-a3bでOpenClawが実用化したと報告しました。しかし運用を続けていると、タイムアウト問題という壁にぶつかりました。

今回は、OpenClawのタイムアウト設定を調査した結果、設定では解決できないハードコードされたバグに行き着いた顛末を記録します。

症状:120秒で勝手にフォールバックする

OpenClawのログに以下のエラーが頻発するようになりました:

10:50:13 error diagnostic lane task error:
  lane=session:agent:main:discord:channel:...
  durationMs=122139
  error="FailoverError: LLM request timed out."

timeoutSeconds: 600(10分)に設定しているのに、約122秒(2分)でタイムアウトしてフォールバック先のOpenRouterに切り替わってしまう。

調査その1:設定は効いているのか?

まず timeoutSeconds を600→900に変更して様子を見ました。すると別のログが出現:

11:36:55 embedded run timeout:
  timeoutMs=600000
  durationMs=600667

こちらは正しく600秒でタイムアウトしている。つまり timeoutSeconds の設定自体は効いている

では122秒のタイムアウトは何なのか?

調査その2:Ollamaのログを確認

Ollamaのjournalctlログを確認すると、決定的な証拠が見つかりました:

12:00:54 loading model: KvSize:131072, GPULayers:15/41
12:00:59 model weights: GPU=7.6GiB, CPU=14.7GiB
12:01:10 llama runner started in 16.28 seconds
12:02:53 [GIN] 500 | 1m59s | POST "/api/chat"

Ollama側は処理中なのに、クライアント(OpenClaw)が約2分で接続を切っている。 Ollamaは500エラーを返しているが、これはクライアント切断が原因。

調査その3:2種類のタイムアウトが存在する

ログを時系列で整理すると、全体像が見えてきました:

タイムアウト 設定 効果
embedded run timeout agents.defaults.timeoutSeconds: 900 エージェント実行全体の制限時間。設定可能
LLM HTTP fetch timeout ハードコード(~120秒) 個別LLMリクエストの待機時間。設定不可

timeoutSeconds はエージェントの「1回の実行全体」のタイムアウト。一方、個別のHTTPリクエスト(OllamaのAPIを叩く1回のfetch)には、別のハードコードされたタイムアウトが存在していました。

なぜ120秒で切れるのか

35B MoEモデルをCPU/GPU分割(15/41レイヤーのみGPU)で131Kコンテキストで動かすと、prefill(プロンプト処理)だけで120秒以上かかることがあります。

ストリーミングモードは有効ですが、prefill中は最初のトークンすら生成されないため、HTTPレスポンスとして1バイトも返りません。OpenClawのHTTPクライアントは「レスポンスが来ない」と判断してabortします。

timeoutMs を試したが…

OpenClawのGitHub Issuesで timeoutMs というパラメータの要望を見つけたので試してみました:

"models": {
  "providers": {
    "ollama": {
      "timeoutMs": 900000
    }
  }
}

結果:

config reload skipped (invalid config):
- models.providers.openrouter: Unrecognized key: "timeoutMs"
Config auto-restored from last-known-good

v2026.5.4では timeoutMs は未実装。 設定に入れるとバリデーションエラーで拒否され、設定全体がロールバックされます。

OpenClawの既知バグだった

GitHub Issuesを調査すると、同じ問題が複数報告されていました:

  • #61487 — “LLM HTTP request timeout hardcoded at ~60s”
  • #46049 — “LLM request timeout ignores configured timeout settings”
  • #45637 — “Add timeoutMs config support for LLM Providers”

ソースコード上は DEFAULT_TIMEOUT_MS$2 = 3e4(30秒)がハードコードされているとの報告もあり、バージョンによって30秒〜120秒の範囲で異なるようです。

結論:現時点でユーザーが変更する手段はない。

ワークアラウンドの検討

対策 有効性 理由
timeoutSeconds を伸ばす embedded run全体には効くが、個別リクエストには効かない
timeoutMs を設定する 未実装。設定するとconfig拒否
モデルを常時ロード 問題は稼働中に発生。ロード済みでもprefillが遅い
コンテキストを下げる 128K未満ではエージェントとして実用にならない
ストリーミングで回避 既にstream:true。prefill中はデータが返らないので無意味
フォールバックに任せる OpenRouterが成功するので実用上は動く

現状の運用

結局、フォールバックが正しく動いているので、実用上は問題なく動作しています:

  1. Ollama(qwen36-35b-agent)にリクエスト
  2. ~120秒でタイムアウト → abort
  3. OpenRouter(deepseek-v4-flash)にフォールバック → 成功

ただし、ローカルモデルが使われる頻度が下がり、OpenRouterのAPI費用が発生するのが残念なポイントです。

まとめ

  • agents.defaults.timeoutSeconds はエージェント実行全体のタイムアウト。個別HTTPリクエストには効かない
  • OpenClawのLLM HTTPクライアントには~120秒のハードコードタイムアウトがある(バグ)
  • timeoutMs パラメータは未実装(Feature Requestとして存在するのみ)
  • 35B MoE + 131Kコンテキスト + CPU/GPU分割の環境では、prefillだけで120秒を超えることがある
  • 根本修正はOpenClaw側のアップデート待ち

教訓: ローカルLLMでOpenClawを使う場合、「モデルの推論速度」だけでなく「prefill時間(最初のトークンが出るまでの時間)」も重要な指標です。VRAM不足でCPUオフロードが多いほどprefillが遅くなり、ハードコードタイムアウトに引っかかりやすくなります。


環境: OpenClaw v2026.5.4 / Ollama 0.20.5 / RTX 3060 12GB / Ryzen 5600X / RAM 32GB

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のタイムアウトを延長しました:

"timeoutSeconds": 600

デフォルトより大幅に延ばし、現在は600秒(10分)に設定しています。これにより、長い思考プロセスや複雑なコード生成でも確実に完走します。

モデル設定の最適化

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

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

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

コンテキスト設定の秘訣

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

{
  "agents": {
    "defaults": {
      "contextTokens": 131072,
      "models": {
        "ollama/qwen36-35b-agent": {
          "params": {
            "num_ctx": 131072
          }
        }
      }
    }
  }
}
  • contextTokens: 131072 – 128Kトークンのコンテキスト(OpenClaw側の設定)
  • num_ctx: 131072 – Ollama側への明示的な指定(モデルに渡すパラメータ)

なぜこれが重要なのか?

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

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

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

なぜ128K(131072)なのか?

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

  • 131072トークン時のKVキャッシュ: 約12.4GB → RAM 32GBなら余裕あり ✅
  • モデルの対応コンテキスト上限(131K)で動作確認済み

当初はRAMが16GBと思い込んでいましたが、実際は32GB搭載していることが判明。128KのKVキャッシュ(約12.4GB)はシステムRAMに余裕をもって収まります。

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

{
  "agents": {
    "defaults": {
      "contextTokens": 131072,
      "compaction": {
        "reserveTokensFloor": 20000
      }
    }
  }
}

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消費を考慮して128K(131072)が利用可能(32GB RAM環境の場合)
  2. maxTokensも大きく – 8192程度あると長いコード生成が可能
  3. compactionの閾値も設定するreserveTokensFloor: 20000 でコンテキスト溢れを防止

実践的な設定例

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "ollama/qwen36-35b-agent",
        "fallbacks": [
          "openrouter/deepseek/deepseek-v3.2",
          "ollama/gemma4-e2b-agent"
        ]
      },
      "contextTokens": 131072,
      "compaction": {
        "reserveTokensFloor": 20000
      },
      "timeoutSeconds": 600,
      "models": {
        "ollama/qwen36-35b-agent": {
          "params": {
            "num_ctx": 131072
          }
        }
      }
    }
  }
}

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メモリ環境では128K(131072トークン)まで利用可能です。

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


この記事は、OpenClaw + Ollama Qwen3.6-35b-a3b によって作成され、人間が微調整しました。
2026-04-28: モデルサイズ・GPU設定・速度計測・コンテキスト設定の誤りを修正
2026-05-04: RAM 32GB確認に伴いコンテキスト128K化・モデル名・タイムアウト設定の誤りを修正

自宅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のモデルを見直しています 笑。