Claude Codeさんに作ってもらいました。 これでいつも、残りtokenを見られるぜ!
Claude Codeさんに作ってもらいました。 これでいつも、残りtokenを見られるぜ!
最近、Hermes AgentとOpenClawの両方を触って比べてみたのですが、いくつか明確な違いがあって、個人的にはかなり衝撃を受けました。
両方とも ローカルの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は長期記憶の必要な部分の抽出が得意ではない感じがしますね。 まぁ、「前に教えたよ」って言えば、メモリーを漁って思い出してくれるんですが、結構物忘れの激しい子ってイメージはありますね(笑)
このツイートを見てHermes Agentに興味を持ったんですが、楽しい時代になりましたね。 → @swarm_japan さんのツイート
最近は、AI がどんどんと進化してきて、LLM と Agent フレームワークを組み合わせて自分でカスタムできるようになってきました。まさにPCの自作みたいな楽しさがそこにはあります。 自分で構成を選んで、パーツを組み合わせて、性能を調整して…といった体験が、もうAIの世界でできているんですよね。これはとてもワクワクします。
| 項目 | Hermes Agent | OpenClaw |
|---|---|---|
| 自走力 | ◎ (30分タスクもこなす) | △ |
| バグの少なさ | ◎ (安定感が高い) | △ |
| 記憶の引き継ぎ | ◎ (スレッド間でインテリジェント) | △ |
同じバックボーンモデルを使っていても、フレームワークの設計次第でこれだけ違ってくるんですね。Hermes Agent はその辺りの実装が非常に良くできていて、日常的に使えるレベルの高いAgentだなという印象です。
Agentフレームワークの比較とかカスタム体験に興味がある方は、ぜひ両方触ってみてください。面白い発見があるはずです。
最近はやりのObsidianで外部脳を作ろうというkarpathyさんのアイデアをちょっと違う形でAI Agent向けの外部脳を作ってみました。私は、ClaudeCodeがメインでOpenCalw、kiro、Antigravity、OpenCladeなど。。。節操なく使ておりり、各エージェント事にコンテキストがバラバラという課題がありまして、これをNAS+Obsidianで効率的に共有できないかと考えました。 私はRedmineでプロジェクト管理しているので、Redmineをベースに、Obsidian Vaultを全AIエージェント共通の外部記憶として整備するプロジェクト「redobrain」を始めました。
一言で言うと、Redmineに書いた情報を自動的にObsidian Vaultに取り込み、AIが読みやすい形に統合するパイプラインです。基本的にはOpenClawのSKILLSで、スクリプトを実行させたりマージはLLMにやらせてます。この仕組み自体、私がアイデアを出しClaudeCodeで作成したものです。
人間 → Redmineにチケットを書く
↓ (自動同期)
Sources/Redmine/ に1チケット1ファイルで保存
↓ (ルールベース分類)
classify-state.json に分類結果を記録
↓ (OpenClawが直接マージ)
Merged/ に統合ドキュメントとして出力
↑
他のAI Agentが ENTRY.md 経由で参照
人間がやることは「Redmineにチケットを書く」だけ。あとは全自動です。
このシステムの核となる設計原則は:
Sources が唯一の真実。Merged はビルド成果物。
プログラマーなら馴染みのある考え方ですね。ソースコードとビルド成果物の関係と同じです。
Sources/ = ソースコード(Redmineチケット、手動投入ドキュメント)Merged/ = ビルド成果物(AIが読む統合ドキュメント)Sources/ から Merged/ を再生成できるこれにより「マージ済みだからスキップ」という判断が不要になります。ルールが変わった、情報が更新された → 再生成すればいい。シンプルです。
分類はLLMを使いません。純粋なルールベースです。
parent_id を辿ってルートチケットを特定def _find_root(self, ticket_id, parent_map):
"""parent_idチェーンを辿ってルートを見つける(循環検出付き)"""
visited = set()
current = ticket_id
while current in parent_map and parent_map[current] is not None:
if current in visited:
break
visited.add(current)
current = parent_map[current]
return current
最初は分類もOpenClawにやらせようと思ったのですが、いまいちだったのでRedmineのプロジェクトをベースにClaudeCodeで先に仕分けルールを作らせました。
SKILLS.mdでスクリプト実行とその結果で判断させ、マージの仕方を指示しています。
## マージ作業(あなたが直接行う — スクリプト不要)
**重要**: マージは2フェーズに分けて行う。1回の処理を小さく保つこと。
### 「マージして」と言われたら即座にこれを実行する
**⚠️ 絶対に聞き返さない。追加情報を求めない。以下をそのまま実行する。**
何をマージするか、どこにマージするかは聞かなくてよい。classify コマンドが自動判定する。
```bash
# Step 1: 分類(自動)— 何をマージすべきか自動判定される
cd ~/.openclaw/workspace/skills/redobrain
set -a; source systemd/openclaw.env; set +a
python3 -m scripts.main --config /mnt/share/Obsidian/_openclaw/config.yaml classify
```
```bash
# Step 2: 次のマージ対象を確認 — これが「何をマージするか」の答え
python3 -m scripts.main --config /mnt/share/Obsidian/_openclaw/config.yaml next-merge
```
**Step 2 の出力を見て、そこに書かれた core_doc と sources に従って作業する。**
ユーザーに何も聞く必要はない。
Step 3以降はあなたが直接ファイルを読み書きして行う:
**⚠️ 1回のセッションで処理するのは1コアドキュメントのみ。**
```
Step 3: next-merge の出力を確認 → core_doc と sources 一覧を把握する
Step 4: その core_doc に属する Sources を1件ずつ読む(一度に全部読まない)
Step 5: 内容を理解し、コアドキュメントを作成・更新する
- 既存ファイルがあれば先に Archive に退避
cp /mnt/share/Obsidian/Merged/xxx.md /mnt/share/Obsidian/Archive/Merged/xxx_YYYY-MM-DD_HHmm.md
- /mnt/share/Obsidian/Merged/{category}/{name}.md に書き込む
Step 6: マージ完了したら mark-merged で記録する
python3 -m scripts.main --config /mnt/share/Obsidian/_openclaw/config.yaml mark-merged "Merged/xxx/yyy.md"
Step 7: Discord に完了を報告する(例:「Merged/Trading/daytrade-bot.md をマージしました」)
Step 8: /mnt/share/Obsidian/00-Entry/ENTRY.md を更新する
- 統合ドキュメント一覧のパスは Obsidian wiki-link で記載する
- 例: `[[Merged/Trading/daytrade-bot]]` (.md は省略)
- テーブル形式: `| タイトル | [[Merged/Trading/daytrade-bot]] | 概要 | 日付 |`
Step 9: /mnt/share/Obsidian/_openclaw/logs/YYYY-MM-DD.md にログを記録する
```
/mnt/share/Obsidian/
├── 00-Entry/
│ └── ENTRY.md ← 全AIエージェントの入口
├── Sources/
│ ├── Redmine/ ← チケットごとに1ファイル
│ └── Other/ ← 手動投入ドキュメント
├── Merged/ ← 統合ドキュメント(カテゴリ別)
│ ├── Trading/
│ ├── Projects/
│ ├── Infrastructure/
│ └── ...
├── Archive/
│ └── Merged/ ← 過去バージョン(自動退避)
└── _openclaw/
├── config.yaml
├── merge_rules.yaml ← 分類ルール定義
├── classify-state.json ← 分類結果キャッシュ
└── logs/
ポイントは 00-Entry/ENTRY.md の存在です。どのAIエージェントも、このファイルを1つ読めば全情報にアクセスできる。設定ファイルに1行追加するだけ:
プロジェクト情報は /mnt/share/Obsidian/00-Entry/ENTRY.md を参照。
毎回全チケットを再分類するのは無駄なので、classified_at と last_synced を比較して変更があったものだけ処理します。
# 増分処理: 前回分類済みで変更なしならスキップ
existing = sources.get(source_path)
if existing and existing.get("classified_at", "") >= last_synced:
continue
マージ前に既存の Merged/ ファイルがあれば、自動的に Archive/ にタイムスタンプ付きでコピーします。git的な発想ですが、Obsidianのプレーンマークダウンという制約の中では十分実用的です。
NAS上のVaultに複数プロセスが同時アクセスしないよう、シンプルなロックファイル機構を実装しています。タイムアウト付きで、デッドロックも防止。
利用環境
「なぜNotionやConfluenceではなくObsidianか?」という疑問があるかもしれません。理由は明確です:
AIエージェントにとって最も低摩擦なインターフェースは「ファイルを読む」こと。それ以上でもそれ以下でもない。
redobrainは「AIエージェントに長期記憶を持たせる」という課題に対する、実用的な解答です。
設計のポイントは:
ぶっちゃけ、これClaude Codeに課金してやらせたら簡単に終わると思います。それをケチって(いや、実験として)OpenClaw + Ollamaで実行させるためには、JOBを細かく切るとかちょっとお馬鹿でも実行できるようにするとか一部、スクリプトを作るとかってことをしてる訳ですね。まぁ、不毛っちゃ不毛です(笑)
環境: OpenClaw v2026.5.4 / Ollama 0.20.5 / Qwen3.6-35b-a3b / RTX 3060 12GB / Ryzen 5600X / RAM 32GB / Obsidian on NAS (SMB)
前回の記事では、Qwen3.6-35b-a3bでOpenClawが実用化したと報告しました。しかし運用を続けていると、タイムアウト問題という壁にぶつかりました。
今回は、OpenClawのタイムアウト設定を調査した結果、設定では解決できないハードコードされたバグに行き着いた顛末を記録します。
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に切り替わってしまう。
まず timeoutSeconds を600→900に変更して様子を見ました。すると別のログが出現:
11:36:55 embedded run timeout:
timeoutMs=600000
durationMs=600667
こちらは正しく600秒でタイムアウトしている。つまり timeoutSeconds の設定自体は効いている。
では122秒のタイムアウトは何なのか?
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エラーを返しているが、これはクライアント切断が原因。
ログを時系列で整理すると、全体像が見えてきました:
| タイムアウト | 設定 | 効果 |
|---|---|---|
| embedded run timeout | agents.defaults.timeoutSeconds: 900 |
エージェント実行全体の制限時間。設定可能 |
| LLM HTTP fetch timeout | ハードコード(~120秒) | 個別LLMリクエストの待機時間。設定不可 |
timeoutSeconds はエージェントの「1回の実行全体」のタイムアウト。一方、個別のHTTPリクエスト(OllamaのAPIを叩く1回のfetch)には、別のハードコードされたタイムアウトが存在していました。
35B MoEモデルをCPU/GPU分割(15/41レイヤーのみGPU)で131Kコンテキストで動かすと、prefill(プロンプト処理)だけで120秒以上かかることがあります。
ストリーミングモードは有効ですが、prefill中は最初のトークンすら生成されないため、HTTPレスポンスとして1バイトも返りません。OpenClawのHTTPクライアントは「レスポンスが来ない」と判断してabortします。
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 は未実装。 設定に入れるとバリデーションエラーで拒否され、設定全体がロールバックされます。
GitHub Issuesを調査すると、同じ問題が複数報告されていました:
ソースコード上は DEFAULT_TIMEOUT_MS$2 = 3e4(30秒)がハードコードされているとの報告もあり、バージョンによって30秒〜120秒の範囲で異なるようです。
結論:現時点でユーザーが変更する手段はない。
| 対策 | 有効性 | 理由 |
|---|---|---|
timeoutSeconds を伸ばす |
△ | embedded run全体には効くが、個別リクエストには効かない |
timeoutMs を設定する |
❌ | 未実装。設定するとconfig拒否 |
| モデルを常時ロード | ❌ | 問題は稼働中に発生。ロード済みでもprefillが遅い |
| コンテキストを下げる | ❌ | 128K未満ではエージェントとして実用にならない |
| ストリーミングで回避 | ❌ | 既にstream:true。prefill中はデータが返らないので無意味 |
| フォールバックに任せる | ○ | OpenRouterが成功するので実用上は動く |
結局、フォールバックが正しく動いているので、実用上は問題なく動作しています:
ただし、ローカルモデルが使われる頻度が下がり、OpenRouterのAPI費用が発生するのが残念なポイントです。
agents.defaults.timeoutSeconds はエージェント実行全体のタイムアウト。個別HTTPリクエストには効かないtimeoutMs パラメータは未実装(Feature Requestとして存在するのみ)教訓: ローカルLLMでOpenClawを使う場合、「モデルの推論速度」だけでなく「prefill時間(最初のトークンが出るまでの時間)」も重要な指標です。VRAM不足でCPUオフロードが多いほどprefillが遅くなり、ハードコードタイムアウトに引っかかりやすくなります。
環境: OpenClaw v2026.5.4 / Ollama 0.20.5 / RTX 3060 12GB / Ryzen 5600X / RAM 32GB
OpenClaw を 2026.4.29 から 2026.5.2 に更新したら、Discord bot が繋がらなくなった。実は2026.4.26->2026.4.29に上げたときもDiscordに繋がらなくなったのですが、今回も繋がりませんでした(苦笑)
こういう時は openclaw doctor –fixが推奨なんですが、最近私はClaudeCode様任せです(笑)ClaudeCodeさんにお願いして調べてみたところ、OpenClaw 2026.5.1 で大きなアーキテクチャ変更があったそうで。Discord を含む多くのチャンネルプラグインが、コアパッケージから外部 npm パッケージへ externalized されたのだそうだ。え。。。て感じだけど。「 bundled plugin → 独立パッケージ 」への cutover 最中に openclaw update を実行すると、プラグインの依存関係が解決されず、Discord プラグインが missing になる。結果として Gateway は起動しても Discord チャンネルが接続できず、bot が「オンラインなのに返事しない」状態になる。とのことだった。。。
CHANGELOG を見ると、2026.5.1 の Plugins/beta セクションにこうある:
prepare Google Chat, LINE, Matrix, Mattermost, …, Discord, …, WhatsApp, Brave, Codex, … for2026.5.1-beta.1/2026.5.1-beta.2npm and ClawHub publishing
つまり Discord プラグインは @openclaw/channel-discordcode>@openclaw/channel-discord</code などの独立パッケージとして npm に公開されることになり、コアに含まれなくなった。update 時にこの移行が中途半端だと、プラグインがインストールされていないままになる。
2026.5.2 にはこの問題への対応が Doctor/plugins セクション で行われた:
run a one-time 2026.5.2 configured-plugin install repair based onmeta.lastTouchedVersion, update stale configured plugin manifests that still declare channels withoutchannelConfigs, install actively used downloadable OpenClaw plugins through the configured external source
要するに、update 時に missing プラグインを自動検出して再インストールする repair が追加された。これで 2026.5.2 以降に update しても同じ事象は起きにくくなっている。
openclaw doctor --fix を実行するのが安全openclaw update の前に CHANGELOG を一瞥するだけで、こんな事象は避けられたopenclaw status で確認: 更新後に openclaw status を実行してチャンネルの状態を確認するOpenClaw は気軽に openclaw update すると 100% ハマるよねぇ(笑)。でもそれはつまり、開発が活発で頻繁に更新されている証拠でもある。プラグインの外部化はスケーラビリティ向上のためなので、ある意味必要な進化。update 後は doctor を実行する癖をつけましょう。
この記事はOpenClaw + Ollama Qwen3.6-35b-a3bで書かれた原稿を元にしています。
OpenClawはClaudeCodeに比べるとまだまだ不安定で色々いじるとすぐ動かなくなる。それにローカルLLMを使っているのでClaudeほど賢くない。そこで、Claude CodeにOpenClawの管理者・先生となってもらって、OpenClawを育てれ見ようと思った。
相互補完の関係
実現した機能
この構成により、AIアシスタント同士の協調作業と、人間からの柔軟な操作インターフェースを実現しました。
OpenClawは強力なAIアシスタントですが、以下のような課題がありました:
これらの課題を解決するために、OpenClawを補助するClaude Codeセッションを常駐化し、相互に監視・制御するシステムを構築しました。
graph TB
subgraph "サーバ (a10)"
O[OpenClaw Gateway] -->|スキル管理| TM[tmux セッション
claudecode-discord]
TM --> C[Claude Code
--channels server:openclaw-discord]
C -->|remote-control URL| URL[https://claude.ai/code/session_XXX]
end
subgraph "リモートアクセス"
DISC[Discord
#claude-claw] -->|/claudecode-bot コマンド| O
IPH[iPhone Claude App] -->|ブラウザから
初回アクセス| URL
IPH -->|セッション一覧| SESH[セッション管理画面]
end
TM -->|管理コマンド| MNG[OpenClaw スキル
start/stop/restart/status]
役割: OpenClawの補助・管理
claude --channels常駐方式の構成従来のワンショット方式から常駐方式に変更:
tmux new-session -d -s claudecode-discord \
'claude --channels server:openclaw-discord \
--dangerously-load-development-channels server:openclaw-discord'
設定のポイント:
tmuxセッションを使用して端末接続が切れても継続--channelsフラグで特定のDiscordサーバーに接続OpenClawのスキルとしてclaudecode-botを実装し、Discordから直接管理可能にしました:
# Discordでのコマンド例
/claudecode-bot status # 稼働状態確認
/claudecode-bot start # 起動
/claudecode-bot stop # 停止
/claudecode-bot restart # 再起動
スキルの特徴:
Claude Codeのremote-control機能を活用:
# remote-control URLの例
https://claude.ai/code/session_abc123def456?token=xyz789
セットアップ手順:
ClaudeCodeBot-a10として表示されるメリット:
# セッション起動スクリプト(自動応答付き)
tmux new-session -d -s claudecode-discord \
'claude --channels server:openclaw-discord \
--dangerously-load-development-channels server:openclaw-discord' && \
sleep 3 && tmux send-keys -t claudecode-discord "1" Enter && \
sleep 3 && tmux send-keys -t claudecode-discord "1" Enter
~/.openclaw/workspace/skills/claudecode-bot/SKILL.mdに管理ロジックを実装:
---
name: claudecode-bot
description: Manage the ClaudeCodeBot-a10 Claude Code session
---
# ClaudeCodeBot-a10 セッション管理
## 状態確認
tmux list-sessions | grep claudecode-discord
## 起動・停止・再起動
自動的にtmuxセッションを制御
| 項目 | 効果 | 実現機能 |
|---|---|---|
| 相互監視 | 一方がダウンしても他方で再起動可能 | 自己修復システム |
| コンテキスト維持 | 長期的なプロジェクト管理が可能 | 継続的な作業フロー |
| 多様なインターフェース | ユーザーの状況に合わせた操作 | Discord + モバイルアプリ |
| 常時待機 | 即時応答による迅速なトラブル対応 | 24時間監視体制 |
| メンテナンス相互補完 | OpenClawの不安定状態をClaude Codeで修復 | 相互依存関係 |
# セッション一覧確認
tmux list-sessions
# 強制再起動
tmux kill-session -t claudecode-discord 2>/dev/null
/claudecode-bot restart
tmux capture-pane -t claudecode-discord -p | grep -E "remote-control|Listening"ClaudeCodeBot-a10システムの構築により、以下の相互補完関係を実現しました:
この構成は、AIアシスタント同士の相互補完と、人間との柔軟なインタラクションを両立する効果的なパターンとして、同様のユースケースに適用可能です。
最終更新: 2026年5月3日構成バージョン: Claude Code 2.1.126 + OpenClaw 2026.4.x + tmux 3.3a
OpenClawの導入とは別の話として、最近「Claude Code Proのトークン不足を補う方法」を探していました。
Claude Code Proは優秀ですが、トークンが足りない。かといって全てをローカルLLMに任せるのも限界がある。そこで注目したのが、OpenClaudeというアプローチでした。
OpenClaudeはClaude Codeのリソースをそのまま利用できる設計になっています。Claude Codeが持っているリソースをOpenClaw側からも使えるようにするもので、シームレスに作業を引き継げる可能性があるということです。
検討していた内容はこんな感じ:
具体的には、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
期待していたのは、「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.json に model キーが書き込まれていたら手動で削除する必要がありました。
もっと気づいておくべき点了——本家のClaude Code自体が既にLLMの切り替えに対応しているんです。
OpenClaude経由で頑張らなくても、Claude Code上で /model コマンドかエイリアスで十分モデルを切り替えられます。OpenClaudeを挟む意味がそもそもないことに気づきました。
正直に言うと、OpenClaudeのメリットを実感できませんでした。
/model コマンドが設定を破壊する、エイリアスの管理が面倒OpenClaude経由のモデル切り替えは断念しました。
あともう一つ、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の使い分け戦略を探求したのは良い経験でした。得られた教訓:
OpenClawのマルチモデル戦略はまだ途中ですが、「適材適所」というキーワードは揺るぎません。次はサブエージェントを挟んだ自動モデル選択に挑戦してみたいですね。
この記事は、OpenClaw + Ollama Qwen3.6-35b-a3b によって作成され、人間が微調整しました。失敗も記録に残すのがエンジニアの誠実さ。
OpenClaw は AI エージェントプラットフォームとして Discord との連携が非常に便利です。しかし、2026-04-26 に v2026.4.26 にアップデートしたところ、想定外のトラブルに遭遇しました。Discord チャンネルで無限ループが発生し、OpenClaw が自分自身のメッセージに延々と応答し続ける状態になりました。
この記事では、発生した問題の詳細、その原因、そして効果的な解決策について共有します。
2026-04-26 に OpenClaw を v2026.4.26 にアップデートした後、#blog チャンネルで奇妙な現象が発生しました。
無限応答ループ
リソース消費の急増
openclaw-gateway プロセスが CPU を 19% ずっと使い続ける手動介入が必要
openclaw-gateway の再起動でとりあえず納まった問題の原因を深堀りしていくと、いくつかの設定の組み合わせが影響していることがわかりました。
allowBots: true 設定"channels": {
"discord": {
"allowBots": true
}
}
この設定は以前から使用していました。Claude CodeとOpenClawの連携のために、Bot からのメッセージも OpenClaw に処理させるために有効にしていました。
requireMentionデフォルト値の変更おそらく、v2026.4.26 で requireMention のデフォルト値が変更されたんじゃないかと思います。私は、requireMentionを定義していなかったのですが、動きとしてはtrueでした。
requireMention のデフォルト値は true(メンション必須)
requireMention のデフォルト値が false に変更
明示的にrequireMention: true を追加
"channels": {
"discord": {
"allowBots": true,
"requireMention": true
}
}
この記事は、OpenClaw + Ollama Qwen3.6-35b-a3b によって作成され、人間が微調整しました。
前回の記事では「ローカルLLMでOpenClawは厳しい!」と結論づけましたが、諦めるのは早かったことがわかりました。
Ollamaの新モデル Qwen3.6-35b-a3b を適切に設定することで、OpenClawが実用的に使えることを発見しました。特に、エージェントとしての「自走能力」が大幅に向上し、DeepSeek-v3.2と比較しても遜色ないレベルになりました。
[2026-04-28 修正] 公開後に実測値の誤りと設定の記載ミスが見つかったため、本記事を修正しました。
私の環境は以下の通りです。
Qwen3.6-35b-a3bは約28.4GBのモデルサイズなので、GPUメモリだけでは完全に載り切りません。当初は挫折ポイントでしたが、Ollamaが自動的に解決してくれます。特別な設定は不要で、OllamaはVRAMに収まる分を自動でGPUに載せ、残りをシステムRAMにオフロードします。
実際の配分(実測値):
画像はRTX3060 12GB(GPUメモリ約95%使用)+ Ryzen 5600Xの環境で、Qwen3.6-35b-a3bをGPU+RAMハイブリッドで動かした時のベンチマーク結果です。
実測の生成速度は 8.2K tok/分(約136 tok/秒) です。RAMへのオフロードが発生しているため、メモリ帯域がボトルネックとなり、純粋なGPU推論と比べて遅くなります。長いレスポンスの生成には数十秒〜数分かかるケースもあります。
即レス前提の用途には向きませんが、エージェントとして複数ステップのタスクを自律的にこなす用途では十分実用的です。
ローカルモデルの応答時間を考慮し、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はエージェントとして動作する際、以下のような大量の情報をコンテキストに保持します:
16Kトークンなど小さなコンテキストでは、すぐに履歴が消えて「自走」できなくなります。エージェントとして使うなら、ある程度のコンテキスト容量は必須です。
なぜ128K(131072)なのか?
KVキャッシュはVRAMの空きがないためRAMにオフロードされます。このKVキャッシュのサイズはコンテキスト長に比例して増加します。
当初はRAMが16GBと思い込んでいましたが、実際は32GB搭載していることが判明。128KのKVキャッシュ(約12.4GB)はシステムRAMに余裕をもって収まります。
また、compactionが余裕をもって起動するよう reserveTokensFloor も合わせて設定します:
{
"agents": {
"defaults": {
"contextTokens": 131072,
"compaction": {
"reserveTokensFloor": 20000
}
}
}
}
reserveTokensFloor はコンテキスト残量がこの値を下回ったときにcompaction(要約・圧縮)が走る閾値です。大きくするほど早めに圧縮が起動し、溢れを防ぎます。
興味深いことに、特定のタスクではDeepSeek-v3.2より自走能力が高いケースがありました:
| 比較項目 | Qwen3.6-35b-a3b (ローカル) | DeepSeek-v3.2 (API) |
|---|---|---|
| 初期思考時間 | 数十秒〜数分 | 1-3秒 |
| 複数ツール連携 | ◎(文脈維持力が高い) | ○ |
| エージェント継続性 | ◎(コンテキスト保持) | ○ |
| コスト | 電気代のみ | $0.20/100万トークン |
| プライバシー | ◎(完全ローカル) | △(API送信) |
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
}
}
}
}
}
}
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円)程度」と報告しましたが、今は電気代のみになりました。
95%以上のタスクをローカルで処理でき、残り5%の難しいタスクだけDeepSeek-v3.2に任せる。これが理想的な構成です。
この構成で気づいたのは、エージェント向きモデルを選択することが重要だということです。同じ35B級パラメータでも:
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化・モデル名・タイムアウト設定の誤りを修正
以前、ここぞと言うときに課金!OpenRouterでDeepSeek V3.2を使ってみたでは普段使いをローカルLLM、ここぞと言うときにDeepSeek-v3.2でやってみましたが、無理です(笑)
やっぱり、OpenClawで使うこと前提だと、話の文脈を理解し、必要な情報を集め、必要なコードを書く。ができないと始まらない。
そんなわけで、無償利用は完全に諦めて、DeepSeek-v3.2をプライマリモデルとして運用し、gemini-1.5-flashとローカルのGemma4-e2bをフェールオーバー(バックアップ) とする構成に変更しました。
/model openrouter/deepseek/deepseek-v3.2/model google/gemini-1.5-flash または /model google/gemini-1.5-pro/model ollama/gemma4-e2b-agent または /model ollama/qwen2.5:32b# 環境変数設定
export OPENROUTER_API_KEY="sk-or-..."
export GOOGLE_AI_STUDIO_API_KEY="your-gemini-key"
export OLLAMA_HOST="http://localhost:11434"
# OpenClawのモデルプリファレンス設定
# ~/.openclaw/config.yaml または環境変数
export OPENCLAW_DEFAULT_MODEL="openrouter/deepseek/deepseek-v3.2"
export OPENCLAW_FALLBACK_MODELS="google/gemini-1.5-flash,ollama/gemma4-e2b-agent"
通常使用:
/model openrouter/deepseek/deepseek-v3.2
画像解析が必要な場合:
/model google/gemini-1.5-flash
インターネット接続悪い時:
/model ollama/gemma4-e2b-agent
この構成でここ一週間ガリガリ使ってみた結果:
$8/週 *4 = $32/月くらいですかね。Claude Code Proより多く処理できるのは間違いないですが、やっぱりClaude Code 4.6 Sonnetの方がだいぶ賢いですねぇ~。お金を気にしないならMax入るのがベストです。

現在の構成は非常に安定していますが、さらに最適化する方向として:
「DeepSeek-v3.2をメイン、GeminiとOllamaをフェールオーバー」という構成は、以下のメリットを実現します:
✅ コスパ最適化: 月5000円程度で高性能AI
✅ 可用性向上: いずれかのサービスがダウンしても運用継続
✅ 柔軟性: タスクに最適なモデルを選択可能
✅ プライバシー: 機密データはローカルモデルで処理
でもまぁ、やっぱりClaude Codeの方が賢い!
*記事作成者: この記事はOpenClaw + DeepSeek-v3.2 が作成したものを私は適宜修正しています。DeekSeek-v3.2は結構、話をふかす傾向がありますね(笑)