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

Obsidian頭脳化計画:AIエージェントの外部記憶をObsidian Vaultで実現する

はじめに

最近はやりの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が唯一の真実

このシステムの核となる設計原則は:

Sources が唯一の真実。Merged はビルド成果物。

プログラマーなら馴染みのある考え方ですね。ソースコードとビルド成果物の関係と同じです。

  • Sources/ = ソースコード(Redmineチケット、手動投入ドキュメント)
  • Merged/ = ビルド成果物(AIが読む統合ドキュメント)
  • いつでも Sources/ から Merged/ を再生成できる

これにより「マージ済みだからスキップ」という判断が不要になります。ルールが変わった、情報が更新された → 再生成すればいい。シンプルです。

2フェーズ・アーキテクチャ

Phase 1: Classify(ルールベース、LLM不要)

分類はLLMを使いません。純粋なルールベースです。

  • Redmineチケットの 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で先に仕分けルールを作らせました。

Phase 2: Merge(OpenClawが直接実行)

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 にログを記録する
```

Vault構造

/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_atlast_synced を比較して変更があったものだけ処理します。

# 増分処理: 前回分類済みで変更なしならスキップ
existing = sources.get(source_path)
if existing and existing.get("classified_at", "") >= last_synced:
    continue

アーカイブ自動退避

マージ前に既存の Merged/ ファイルがあれば、自動的に Archive/ にタイムスタンプ付きでコピーします。git的な発想ですが、Obsidianのプレーンマークダウンという制約の中では十分実用的です。

ロックファイル

NAS上のVaultに複数プロセスが同時アクセスしないよう、シンプルなロックファイル機構を実装しています。タイムアウト付きで、デッドロックも防止。

技術スタック

  • Python 3.11+ — パイプラインスクリプト
  • OpenClaw — LLMエージェント基盤(Qwen3.6-35b-a3b on Ollama)
  • Redmine — 情報の入力元(人間が書く場所)
  • Obsidian — 情報の出力先(AIが読む場所)
  • Discord — 承認フロー・通知
  • NAS (SMB/NFS) — Vault の物理ストレージ(複数マシンからアクセス可能)

技術スタック

利用環境

  • Windows 11 (Claude Code/kiro/Antigravity) 普段使うPC
  • Ubuntu Linux 24.04(Openclaw/Claude Code/kiro-cli) Openclawマシン
  • Mac mini(まだ届いてない(笑))

現在の稼働状況

  • Redmine sync: 稼働中(329チケット同期済み)
  • Classify: 稼働中(273ソース分類済み → 157コアドキュメント)
  • Merge: OpenClawによる実行が進行中
  • systemdタイマーで15分ごとに自動実行

なぜObsidianなのか

「なぜNotionやConfluenceではなくObsidianか?」という疑問があるかもしれません。理由は明確です:

  1. プレーンマークダウン — APIもDBも不要。ファイルを読むだけ
  2. ローカルファイルシステム — AIエージェントが直接アクセスできる
  3. NASマウント — 複数マシン(Windows/Linux/Mac)から同じVaultにアクセス
  4. Obsidianのwiki-link — ドキュメント間のリンクが簡潔に書ける
  5. 人間も読める — Obsidianアプリで普通にブラウズ・編集できる

AIエージェントにとって最も低摩擦なインターフェースは「ファイルを読む」こと。それ以上でもそれ以下でもない。

今後の展望

  • マージ品質の改善(現在はOpenClawの出力をそのまま使っているが、フォーマットの一貫性にばらつきがある)
  • 定期的な全再マージ(ルール変更時に一括再生成)
  • 他のAIエージェント(Claude Code、Kiro等)からの参照実績を積む
  • Sources/Other/ への手動投入ワークフローの整備

まとめ

redobrainは「AIエージェントに長期記憶を持たせる」という課題に対する、実用的な解答です。

設計のポイントは:

  • 人間はRedmineに書くだけ(既存ワークフローを変えない)
  • 分類はルールベース(LLMの気まぐれに依存しない)
  • 統合はLLMが直接実行(エージェントの強みを活かす)
  • 出力はプレーンマークダウン(どの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)

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

OpenClaw 2026.5.2 Discord 切断事件

何が起きたのか

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, … for 2026.5.1-beta.1/2026.5.1-beta.2 npm and ClawHub publishing

つまり Discord プラグインは @openclaw/channel-discordcode>@openclaw/channel-discord</code などの独立パッケージとして npm に公開されることになり、コアに含まれなくなった。update 時にこの移行が中途半端だと、プラグインがインストールされていないままになる。

2026.5.2 の修正

2026.5.2 にはこの問題への対応が Doctor/plugins セクション で行われた:

run a one-time 2026.5.2 configured-plugin install repair based on meta.lastTouchedVersion, update stale configured plugin manifests that still declare channels without channelConfigs, install actively used downloadable OpenClaw plugins through the configured external source

要するに、update 時に missing プラグインを自動検出して再インストールする repair が追加された。これで 2026.5.2 以降に update しても同じ事象は起きにくくなっている。

教訓

  1. メジャー cutover の直後は注意: プラグインの externalization のような大きな変更があるバージョンでは、update 後に openclaw doctor --fix を実行するのが安全
  2. CHANGELOG を読む癖をつける: openclaw update の前に CHANGELOG を一瞥するだけで、こんな事象は避けられた
  3. openclaw status で確認: 更新後に openclaw status を実行してチャンネルの状態を確認する

まとめ

OpenClaw は気軽に openclaw update すると 100% ハマるよねぇ(笑)。でもそれはつまり、開発が活発で頻繁に更新されている証拠でもある。プラグインの外部化はスケーラビリティ向上のためなので、ある意味必要な進化。update 後は doctor を実行する癖をつけましょう。


この記事はOpenClaw + Ollama Qwen3.6-35b-a3bで書かれた原稿を元にしています。

OpenClaw+ClaudeCodeで補完する

概要

OpenClawはClaudeCodeに比べるとまだまだ不安定で色々いじるとすぐ動かなくなる。それにローカルLLMを使っているのでClaudeほど賢くない。そこで、Claude CodeにOpenClawの管理者・先生となってもらって、OpenClawを育てれ見ようと思った。

相互補完の関係

  • ClaudeCodeBot-a10 1 → OpenClawの不安定な状態のメンテナンスや指示出しを担当
  • OpenClaw → ClaudeCodeBot-a10の再起動や状態監視を担当

実現した機能

  1. Discordを通じた人間とのコミュニケーション: Discordチャンネルから直接操作
  2. Remote Control機能を使ったオペレーション: iPhoneアプリからリモート操作
  3. 常駐化による安定運用: コンテキスト維持と即時応答

この構成により、AIアシスタント同士の協調作業と、人間からの柔軟な操作インターフェースを実現しました。

背景: AIアシスタントの相互補完システム

OpenClawは強力なAIアシスタントですが、以下のような課題がありました:

  1. 不安定な状態の回復: 設定変更やトラブル発生時の自己修復
  2. 継続的な監視: 24時間のヘルスチェックとアラート
  3. 人間とのインターフェース: Discordやモバイルからの直感的な操作

これらの課題を解決するために、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]

構築内容

1. ClaudeCodeBot-a10の概要

役割: OpenClawの補助・管理

  • OpenClawの設定変更やトラブルシューティングの支援
  • Discordチャンネルでの指示受け取りと実行
  • 定期的なヘルスチェックとメンテナンス

2. claude --channels常駐方式の構成

従来のワンショット方式から常駐方式に変更:

tmux new-session -d -s claudecode-discord \
  'claude --channels server:openclaw-discord \
   --dangerously-load-development-channels server:openclaw-discord'

設定のポイント:

  • tmuxセッションを使用して端末接続が切れても継続
  • --channelsフラグで特定のDiscordサーバーに接続
  • 開発チャンネルも読み込むオプション付与
  • 起動時の確認プロンプトを自動応答

3. OpenClawスキルによるリモート管理

OpenClawのスキルとしてclaudecode-botを実装し、Discordから直接管理可能にしました:

# Discordでのコマンド例
/claudecode-bot status    # 稼働状態確認
/claudecode-bot start     # 起動
/claudecode-bot stop      # 停止  
/claudecode-bot restart   # 再起動

スキルの特徴:

  • tmuxセッションの状態を自動検出
  • 起動時の確認プロンプトを自動応答
  • エラーハンドリングとログ取得
  • ユーザーフレンドリーな日本語応答

4. remote-controlでアプリから操作できる仕組み

Claude Codeのremote-control機能を活用:

  1. 自動URL生成: Claude Code起動時にremote-control URLが表示される
  2. 初回アクセス: ブラウザでこのURLを開くとiPhone Claudeアプリのセッション一覧に登録
  3. 常時接続: 以後はアプリから直接セッションに接続可能
# remote-control URLの例
https://claude.ai/code/session_abc123def456?token=xyz789

5. iPhoneアプリとの連携

セットアップ手順:

  1. Claude Codeを起動しremote-control URLを取得
  2. iPhoneのブラウザでURLを開く
  3. 「Claudeアプリで開く」を選択
  4. セッション一覧にClaudeCodeBot-a10として表示される
  5. 以後はアプリから直接操作可能

メリット:

  • モバイルからもOpenClawの補助AIにアクセス可能
  • セッション状態が維持される(コンテキスト保持)
  • 通知やアラートの受信が可能

技術的詳細

tmuxセッション構成

# セッション起動スクリプト(自動応答付き)
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スキル実装

~/.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セッションを制御

セキュリティ考慮事項

  1. 環境変数使用: APIトークンは環境変数で管理
  2. 制限付きアクセス: 特定のDiscordチャンネルのみ許可
  3. 監視ログ: tmuxセッションの出力を定期的に監視

運用メリット

相互補完システムの効果

項目 効果 実現機能
相互監視 一方がダウンしても他方で再起動可能 自己修復システム
コンテキスト維持 長期的なプロジェクト管理が可能 継続的な作業フロー
多様なインターフェース ユーザーの状況に合わせた操作 Discord + モバイルアプリ
常時待機 即時応答による迅速なトラブル対応 24時間監視体制
メンテナンス相互補完 OpenClawの不安定状態をClaude Codeで修復 相互依存関係

実際のユースケース

  1. 深夜の緊急対応: モバイルからOpenClawのトラブルシューティングを指示
  2. 定期的なメンテナンス: ヘルスチェックとログ監視の自動化
  3. プロジェクト管理: 長期的な開発プロジェクトのコンテキスト維持
  4. チーム連携: Discordチャンネルを通じた複数メンバーからの指示受け付け

トラブルシューティング

よくある問題と解決策

  1. tmuxセッションが見つからない
    # セッション一覧確認
    tmux list-sessions
    
    # 強制再起動
    tmux kill-session -t claudecode-discord 2>/dev/null
    /claudecode-bot restart
    
  2. remote-control URLが表示されない
    • Claude Codeの起動ログを確認
    • tmux capture-pane -t claudecode-discord -p | grep -E "remote-control|Listening"
    • ネットワーク接続を確認
  3. iPhoneアプリにセッションが表示されない
    • 初回アクセスでブラウザからURLを開く必要あり
    • 「Claudeアプリで開く」オプションを選択
    • アプリの再起動を試す

まとめ

ClaudeCodeBot-a10システムの構築により、以下の相互補完関係を実現しました:

  1. 相互監視・制御: OpenClawの不安定状態をClaude Codeでメンテナンスし、Claude Codeの再起動をOpenClawで実行
  2. 多様な操作インターフェース: Discordを通じた人間とのコミュニケーションと、Remote Control機能によるモバイルオペレーション
  3. 常駐化による安定性: コンテキスト維持と即時応答可能な常駐システム
  4. 自己修復システム: AIアシスタント同士の協調による高い信頼性

この構成は、AIアシスタント同士の相互補完と、人間との柔軟なインタラクションを両立する効果的なパターンとして、同様のユースケースに適用可能です。


最終更新: 2026年5月3日構成バージョン: Claude Code 2.1.126 + OpenClaw 2026.4.x + tmux 3.3a


  1. a10というのは動いてるサーバの名前です。他にもClaudeCodeBotが居るので後ろに-サーバ名書いてます。 

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 によって作成され、人間が微調整しました。失敗も記録に残すのがエンジニアの誠実さ。

OpenClaw v2026.4.26 アップデートで起きた無限ループとその解決策

はじめに

OpenClaw は AI エージェントプラットフォームとして Discord との連携が非常に便利です。しかし、2026-04-26 に v2026.4.26 にアップデートしたところ、想定外のトラブルに遭遇しました。Discord チャンネルで無限ループが発生し、OpenClaw が自分自身のメッセージに延々と応答し続ける状態になりました。

この記事では、発生した問題の詳細、その原因、そして効果的な解決策について共有します。

起きたこと

問題の発覚

2026-04-26 に OpenClaw を v2026.4.26 にアップデートした後、#blog チャンネルで奇妙な現象が発生しました。

  1. 無限応答ループ

    • OpenClaw が自分自身の Discord 出力メッセージを新しいユーザー入力として認識
    • そのメッセージに対し、さらに応答を生成
    • 生成した応答をまた入力として認識……と際限なく続く
  2. リソース消費の急増

    • セッションファイルが 657KB まで膨れ上がり(通常は数十KB程度)
    • openclaw-gateway プロセスが CPU を 19% ずっと使い続ける
    • 応答が止まらず、チャンネルがスパム状態に
  3. 手動介入が必要

    • openclaw-gateway の再起動でとりあえず納まった

原因調査

問題の原因を深堀りしていくと、いくつかの設定の組み合わせが影響していることがわかりました。

1. allowBots: true 設定

"channels": {
  "discord": {
    "allowBots": true
  }
}

この設定は以前から使用していました。Claude CodeとOpenClawの連携のために、Bot からのメッセージも OpenClaw に処理させるために有効にしていました。

2. requireMentionデフォルト値の変更

おそらく、v2026.4.26 で requireMention のデフォルト値が変更されたんじゃないかと思います。私は、requireMentionを定義していなかったのですが、動きとしてはtrueでした。

  • 以前のバージョン: requireMention のデフォルト値は true(メンション必須)
    • 明示的に書かなくてもメンションが必要だった
    • 自己メッセージにはメンションがないので自然に無視されていた
  • v2026.4.26 以降: requireMention のデフォルト値が false に変更
    • 明示的に設定しない限り、メンションなしでも反応するようになった
    • これが無限ループの直接的な原因

解決策

明示的にrequireMention: true を追加

"channels": {
  "discord": {
    "allowBots": true,
    "requireMention": true
  }
}

これで、現在は安定してます。

この記事は、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化・モデル名・タイムアウト設定の誤りを修正

やっぱりローカルLLMでOpenClawは厳しい!

はじめに

以前、ここぞと言うときに課金!OpenRouterでDeepSeek V3.2を使ってみたでは普段使いをローカルLLM、ここぞと言うときにDeepSeek-v3.2でやってみましたが、無理です(笑)

やっぱり、OpenClawで使うこと前提だと、話の文脈を理解し、必要な情報を集め、必要なコードを書く。ができないと始まらない。

そんなわけで、無償利用は完全に諦めて、DeepSeek-v3.2をプライマリモデルとして運用し、gemini-1.5-flashとローカルのGemma4-e2bをフェールオーバー(バックアップ) とする構成に変更しました。

現在のOpenClawモデル構成

プライマリモデル(メイン)

  • DeepSeek-v3.2 via OpenRouter
  • 使用コマンド: /model openrouter/deepseek/deepseek-v3.2
  • 用途: 日常のすべてのタスク
  • 成功率: 約95%のタスクで問題なく完了

フェールオーバー1(API系バックアップ)

  • Gemini via Google AI Studio
  • 使用コマンド: /model google/gemini-1.5-flash または /model google/gemini-1.5-pro
  • 用途: OpenRouterの障害時、または特定のタスク(マルチモーダル推論)

フェールオーバー2(ローカルバックアップ)

  • Ollama + Gemma4-e2b または Qwen2.5:32b
  • 使用コマンド: /model ollama/gemma4-e2b-agent または /model ollama/qwen2.5:32b
  • 用途: インターネット接続問題時、極端なコスト制約時

設定方法

OpenClaw設定例

# 環境変数設定
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"

Discord/Telegramからの切り替え

通常使用:
/model openrouter/deepseek/deepseek-v3.2

画像解析が必要な場合:
/model google/gemini-1.5-flash

インターネット接続悪い時:
/model ollama/gemma4-e2b-agent

コスト実績

この構成でここ一週間ガリガリ使ってみた結果:

  • DeepSeek-v3.2: 約44Mトークン使用 → 約$8.26(約1321円)
  • Gemini flash: 約290Kトークン使用 → 約$0.01(約1.6円)
  • Ollama: 電気代のみ

$8/週 *4 = $32/月くらいですかね。Claude Code Proより多く処理できるのは間違いないですが、やっぱりClaude Code 4.6 Sonnetの方がだいぶ賢いですねぇ~。お金を気にしないならMax入るのがベストです。

OpenRouter費用

各モデルの得意分野

DeepSeek-v3.2が最強な分野

  1. コード生成&デバッグ: 実際のプロダクションコード品質
  2. 長文分析: 128Kトークンで長いドキュメントを一気に
  3. 論理的推論: 複雑な条件分岐の理解
  4. 日本語の自然さ: 日本語での会話が非常に自然

Geminiに任せる分野

  1. 画像解析: スクリーンショットからの情報抽出
  2. マルチモーダルタスク: 画像+テキストの複合理解
  3. クリエイティブ: アイデア生成、ストーリーテリング

Ollamaに任せる分野

  1. プライベートデータ: APIに送信したくない情報
  2. オフライン作業: インターネット接続がない環境
  3. 実験的タスク: 新しいモデル機能のテスト

今後の展望

現在の構成は非常に安定していますが、さらに最適化する方向として:

  1. 動的モデル選択: タスク内容に応じて自動で最適モデル選択
  2. コスト予測: タスク実行前にコストを見積もり
  3. モデル混合: 複数モデルの回答を比較・統合

まとめ

「DeepSeek-v3.2をメイン、GeminiとOllamaをフェールオーバー」という構成は、以下のメリットを実現します:

コスパ最適化: 月5000円程度で高性能AI
可用性向上: いずれかのサービスがダウンしても運用継続
柔軟性: タスクに最適なモデルを選択可能
プライバシー: 機密データはローカルモデルで処理

でもまぁ、やっぱりClaude Codeの方が賢い!


*記事作成者: この記事はOpenClaw + DeepSeek-v3.2 が作成したものを私は適宜修正しています。DeekSeek-v3.2は結構、話をふかす傾向がありますね(笑)

徒然なるままに。。。