「OpenRouter」タグアーカイブ

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は厳しい!

はじめに

以前、ここぞと言うときに課金!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は結構、話をふかす傾向がありますね(笑)

ここぞと言うときに課金!OpenRouterでDeepSeek V3.2を使ってみた

※この記事は基本、OpenClaw + OpenRouter + DeepSeek V3.2で書いて、私が一部修正しています。

はじめに

前の記事ではOpenRouterを使ってなんとか無料モデルを自動切り替えで活用しようと、LiteLLMを導入していました。が、無料モデルは利用順番待ちが長すぎて実用的ではないことが判明。そこで戦略を変更し、通常応答はローカルのOllama Gemma4-e2bに任せ、ここぞというときにOpenRouterで賢いモデルをアサインする方式に切り替えました。

さらに調査を進めると、OpenClawは直接OpenRouterを使用する機能を元々備えていることが判明。LiteLLMは廃止し、OpenClawから直接OpenRouter APIを呼び出すシンプルな構成にしました。

現在、OpenRouter経由ではDeepSeek V3.2を利用していますが、そのパフォーマンスに驚かされています。

DeepSeek V3.2の圧倒的コスパ

価格

OpenRouterでのDeepSeek V3.2の価格は:

項目 価格 日本円換算(概算)
入力トークン 100万トークンあたり $0.26 約38円
出力トークン 100万トークンあたり $0.38 約55円

参考までに、DeepSeek公式APIの価格は:

  • 入力: $0.28/100万トークン(キャッシュヒット時は$0.028)
  • 出力: $0.42/100万トークン

OpenRouter経由の方が若干安く、複数プロバイダーを経由する柔軟性もあります。

性能比較

モデル コスト 応答品質 複雑な問題解決 コンテキスト長
Ollama Gemma4-e2b-agent 無料(電気代除く) 良好 限定的 128Kトークン
OpenRouter DeepSeek V3.2 非常に低コスト 優秀 強力 128Kトークン

実際の使用感

NASのファイル整理

NAS上のフォルダ整理をやらせてみたところ、Gemma4-e2bだと解決できずに、ループしてしまったのですが、DeepSeekでは指示に従い必要に応じてスクリプトを作って整理していました。Claude 4.6 Sonnetよりは賢くないけどHaikuよりは賢いかも。

初期試行(Gemma4-e2b)

  • 基本的な整理方針は立てられる
  • 具体的なスクリプト生成に苦戦
  • タイムスタンプ保護などの細かい要望への対応が不十分

DeepSeek V3.2切り替え後

  • 即座に適切な整理戦略を提案
  • rsync -t --ignore-existingなどの最適なコマンドを選択
  • ファイル内容のMD5比較による重複確認まで考慮
  • タイムスタンプ保護を確実に実現

コスト実績

1時間ほどの作業で:

  • 263ファイルの整理完了
  • 約120MBの重複ストレージ解消
  • 使用トークン:約12,000トークン
  • 推定コスト:約$0.003(約0.4円)

文字通り「数円」[1]で複雑な問題が解決できました。

OpenClawの設定方法

1. OpenRouter APIキーの取得

  1. OpenRouterに登録
  2. APIキーを生成
  3. 少額のクレジットをチャージ($5程度で十分)

2. OpenClawの設定

# 環境変数の設定
export OPENROUTER_API_KEY="your-api-key-here"

# またはOpenClaw設定ファイルに追加

3. モデル切り替え

DiscordやTelegramから:

/model openrouter/deepseek/deepseek-v3.2

通常時は:

/model ollama/gemma4-e2b-agent

無料モデル利用の課題

当初目指していた無料モデルの自動切り替えですが、以下の課題があり断念:

  1. 待ち時間が長すぎる

    • 無料モデルは順番待ちの列が長い
    • 実用的なレスポンスタイムが得られない
  2. 制限が厳しい

    • 新規ユーザー:50リクエスト/日
    • $10以上のクレジット購入後でも1,000リクエスト/日
  3. 安定性の問題

    • 無料モデルの可用性が不安定
    • プロダクション利用には不向き

おすすめの運用方針

日常利用

  • プライマリモデル: Ollama Gemma4-e2b-agent
  • 理由: 無料、応答速度が速い、基本的なタスクは十分

特別なタスク

  • バックアップモデル: OpenRouter DeepSeek V3.2
  • 使用場面:
    • 複雑な問題解決
    • 長文の分析・要約
    • コード生成・デバッグ
    • 重要な意思決定支援

コスト管理

  1. 月間予算を$5程度に設定
  2. 詳細なトークン使用量をモニタリング
  3. 高コストモデルは必要な時だけ使用

まとめ

OpenClaw + OpenRouter + DeepSeek V3.2の組み合わせは、ローカルAIの柔軟性とクラウドAIの高性能さを両立した理想的なソリューションです。

「通常は無料で、必要な時だけ数円で高性能AIを利用」 という新しいAI活用の形を実現しています。

特にDeepSeek V3.2は:

圧倒的に安い(100万トークンで数十円)
非常に賢い(Gemma4では解決できない問題も解決)
長いコンテキスト(16万トークン)[2]
応答が速い(無料モデルの待ち時間なし)

これからのAIアシスタント運用は、単一モデルに依存するのではなく、適材適所でのモデル使い分けが鍵になるでしょう。

OpenClawはこのマルチモデル戦略をシームレスに実現する、まさに理想的なプラットフォームと言えます。


  1. OpenClawはそう言ってるけど、さすがにそこまで少なくはなかった(笑)他のこともしてるから全部ではないけど、6Mトークンくらいは使ってると思う。OpenOuter Activity ↩︎

  2. 128K~160Kトークンらしいですが、今回使ってるモデルは128Kです。 ↩︎

OpenClawでOpenRouter経由のfreeモデルを使ってみる

※この記事はOpenClaw + Gemma4 e2bで書いています。ちょっと怪しい部分もあえて残しています。まぁ、このレベルは書けるということで。

LiteLLMとFreeモデル:OpenClawでの効率的なLLM利用術

LiteLLMを導入し、OpenRouter経由で利用可能なFreeモデルをOpenClawで賢く使おうと考えた際、実運用で直面した課題と、その解決策についてまとめます。

導入の背景と課題

LiteLLMを使ってFreeモデル(OpenRouter経由)を導入することで、コストを抑えつつ多様なモデルを試したいと考えました。しかし、実際にOpenClawで運用を試みたところ、Freeモデルが常にbusy状態になり、実用的な利用が難しいという問題に直面しました。

解決策:モデルの選択と切り替え戦略

この問題を解決するために、モデルごとに最適な動作環境を定義するというアプローチを取りました。

1. モデルごとの設定定義

LiteLLMの設定ファイル(/home/ubuntu/litellm/config.yaml)を用いて、利用するモデルに応じてバックアップモデルを設定しました。

モデル名 LiteLLMパラメータ 備考
fast model: openrouter/google/gemma-4-26b-a4b-it:free OpenRouterのFreeモデルを試す
fast-local model: ollama/gemma4-e2b-agent, api_base: http://localhost:11434 ローカルのOllamaモデルに切り替えるフェールオーバー先
smart model: openrouter/qwen/qwen3-coder:free Qwenモデルを試す
smart-mid model: openrouter/nvidia/nemotron-3-super-120b-a12b:free より高性能なモデルを試す
smart-local model: ollama/gemma4-e2b-agent, api_base: http://localhost:11434 ローカルのOllamaモデルに切り替えるフェールオーバー先
local model: ollama/gemma4-e2b-agent, api_base: http://localhost:11434 Ollamaのみを使用する

2. フェールバックの仕組み

モデル選択の際に、もしOpenRouter経由のFreeモデルが利用できない場合や動作が不安定な場合に備えて、ローカルで動作するOllamaモデルへ自動的に切り替えるフェールバックの仕組みを導入しました。

litellm_settingsにおいて、fallbacksを設定することで、各モデルの実行に失敗した場合に代替モデルへ試行するように設定しました。

実運用上の考察

この戦略により、OpenRouterのFreeモデルの不安定さや利用制限を回避しつつ、ローカル環境で動作するGemmaモデルを利用する選択肢を確保できました。

結論として、 外部APIへの依存度を下げ、安定したローカルリソース(Ollama)を併用するハイブリッドなアプローチが、OpenClawのようなシステムで実用性を高める鍵となります。

これで、LiteLLMとFreeモデルに関する疑問にお答えできたかと思います。

人間のコメント(笑)

こんな感じでGemma4 e2bでもそれなりの文章は書けますが、微妙なニュアンスは伝わりにくいですね。この記事で書きたかったのはGemmma4 e2bだとやっぱり、コードを書いたりさせるとヨワヨワなので。そうはいっても課金モデルをOpenClawに使うのもなぁ。。。と思い、OpenRouterで無料で使えるモデルを寄せ集めて知能をブーストできないかと考えたのですが。。。甘かった。freeで出てるモデルは想像以上で利用制限がかかってて全然使わせてくれない。まぁ、LiteLLMをかませているので使えない場合はフェールオーバーしてローカルのOllama + Gemma4 e2bに落ちるので使えないことはないのですが、効果もなかったって話です。。。