はじめに
Linux/ThinkPad環境での実運用を通じて、OpenClaw単体でLLMモデルを選ぶ時代から、複数のAIエージェントを連携させて「役割分担（オーケストレーション）」させる時代へと移行しました。
本記事では、速度、コスト、品質のバランスを考慮し、OpenClawの思考管理モデルと、実作業を担う強力な無料モデル群（Kilo Code連携）をどう組み合わせて運用すべきか、実践的なアーキテクチャとその最適解を解説します。
目次
- Linux/ThinkPad環境での実運用経験
- OpenClawのアーキテクチャ進化：Kilo Codeへの委任
- 主要なLLMプロバイダとモデルの特性比較
- 強力なKilo提供の無料モデル群（実作業用）
- 速度・コスト・品質のトレードオフ分析と役割分担
- OpenClawでのハイブリッドモデル管理実践例
- 用途別推奨モデル構成
- トラブルシューティング
Linux/ThinkPad環境での実運用経験
実環境構成
# 実際の環境情報
$ cat /proc/cpuinfo | grep "model name" | head -1
model name : Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz
$ free -h
total used free shared buff/cache available
Mem: 30Gi 18Gi 2.6Gi 560Mi 11Gi 12Gi
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 468G 140G 305G 32% /
実運用で得た知見
- ローカルモデル: Ollamaでの実行が基本
- メモリ管理: 30GB搭載だが、ローカルLLMの常時稼働にはリソース配分を最適化する必要あり。7B〜13Bクラスが現実的
- アーキテクチャの変更: 上記の制限から、OpenClaw自身にはコードを書かせず、外部エージェントに実装を委任するハイブリッド構成が現在の最適解となっています。
実運用から導き出した「ハイブリッド構成」への変遷
かつてのOpenClawは、思考からコード生成まですべてを一つのLLMで担おうとしていました。しかし、実運用の中で以下のような「トークン制限とコストの壁」に直面し、現在の構成へと進化しています。
失敗と試行錯誤の歴史
-
初期（OpenRouterの無料モデル期）
- 最初はOpenRouterの
z-ai/glm-4.7-flash:freeを使用。 - 結果: 無料で手軽だったが、OpenClawの自律動作による大量のリクエストですぐにレートリミット（リクエスト制限）に引っかかった。（※OpenRouterは1,000円分ほどクレジットチャージしておくと、使用できる無料トークン枠が大幅に増える仕様ですが、当時はそれに気づかず実務に耐えないと判断）
- 最初はOpenRouterの
-
中期（Zhipu AI Lite 年間契約期）
- 制限を回避するため、Zhipu AI (z.ai) のLiteプランを年間契約し、
glm-4.7をメインに据える。 - 結果: 制限はなくなったが、OpenClawの複雑な思考・計画タスクにおいて反応が鈍く、精度に不満が残った。
- 制限を回避するため、Zhipu AI (z.ai) のLiteプランを年間契約し、
-
後期（ChatGPT Plus 契約期）
- 圧倒的な推論力を求めてChatGPT Plusを契約（API経由での利用）。
- 結果: 反応速度・精度ともに最高で非常に使いやすかった。しかし、OpenClawが凄まじい勢いでコードを書き直すため、すぐに週あたりの使用制限上限に到達してしまった。（※現在は最先端のGPT-5.4等を利用）
-
現在（ハイブリッド・オーケストレーション期）
- これまでの反省から、「思考（高精度・低頻度）」と「実装（大容量・高頻度）」を分離する設計に行き着く。
- 現在は、Z.aiの
glm-4.7（Liteプランによる安定稼働）をOpenClawの「頭脳（マネージャー）」としてメインにすえ、重いコーディング等の実作業はKilo Code CLIへ完全に委任するアーキテクチャを採用している。
そもそも「Kilo Code」「Opencode」とは？
本アーキテクチャの核となる外部エージェントについて簡単に解説します。
- Opencode (オープンソース版): ターミナルやIDE（VS Code等）で動作するオープンソースのAIコーディングエージェントです。75以上のLLMプロバイダに対応しており、プライバシーと拡張性に優れています。
-
Kilo Code (SaaS/高機能版): Opencodeをベースに構築された強力なAIコーディングエージェント（CLI/拡張機能）です。400以上のモデルにアクセス可能であり、特に特筆すべきは最新かつ最強クラスのAIモデル群（独自チューニングされた
glm-5やstep-3.5-flashなど）を**強力な無料枠（:free）**で提供している点です。
OpenClawは自らの手でコードを書くのではなく、この 「コーディングに特化した最強のCLIツール（Kilo Code）」を外部からプログラム的に操作（オーケストレーション）する というアプローチをとっています。
kilo-controller スキルの導入
私が運用している環境では、OpenClawに kilo-controller という専用のスキルを実装しています。
※このスキルは、元々存在する opencode-controller（OSSのAIコーディングエージェント「Opencode」をOpenClawから操作するための公式スキル）をベースにして、Kilo Code用にOpenClaw自身に作成してもらったものです。
📝 kilo-controller のコア・ルール
OpenClawはコードを書かない。すべてのコーディングはKilo Codeに委任する。
OpenClawの主な役割は、日々のHeartbeat（生存確認）、スケジューリング、タスクの切り出しといった**「プロジェクトマネージャー（Coordinator）」**業務に専念することです。
実際のプログラミングやファイル編集といった重い実作業は、CLIツールである kilo run をキックすることでKilo Codeへ完全にオフロードします。
主要なLLMプロバイダとモデルの特性比較
用途（マネージャーかワーカーか）によって、選ぶべきモデルプロバイダが大きく変わります。
プロバイダ別比較表（マネージャー・分析用途向け）
| プロバイダ | 代表モデル | 特徴 | 最適用途 | コスト |
|---|---|---|---|---|
| OpenAI | ChatGPT Plus (GPT-5.4等) | 圧倒的な推論力と反応速度 | 高負荷な複雑タスク（※ただしすぐ使用制限にかかる点に注意） | 高 |
| Zhipu AI | GLM-4.7 (Liteプラン) | 安定稼働、十分なコンテキスト | 現在のOpenClawのメイン頭脳（安定した司令塔） | 中 |
| OpenRouter | glm-4.7-flash:free | クレジット入金で枠拡大 | 少しクレジットを入れれば大量テストに使える | 実質無料〜微少 |
| Meta (ローカル) | Llama 3.1 8B | 完全無料、セキュア | シンプルなスケジューリング（Heartbeat等の裏方処理） | ゼロ |
強力なKilo提供の無料モデル群（実作業用）
OpenClawから委任された実作業（コーディング）を担うのが、Kilo Codeが提供する以下の強力な無料化モデル群です。これらはコーディング能力においてトップクラスの性能を誇りながら、コストを気にせず叩けるため、開発作業を劇的に加速させます。
モデル指定 (-m) |
特長 | おすすめ用途 |
|---|---|---|
kilo/stepfun/step-3.5-flash:free |
新登場・爆速＆エージェント特化。独自のMoE技術により推論時11Bで動作し、ピーク時350tok/sというフラッシュスピードを誇る | プロジェクト全体のコード解析、自律的な連続ファイル修正、超長文コンテキストの読み込み |
kilo/arcee-ai/trinity-large-preview:free |
高い論理推論能力を持つプレビュー版 | 複雑なアルゴリズムや新規機能の設計実装 |
kilo/corethink:free |
コードの思考プロセスが深い | リファクタリング、難解なエラーの解決 |
kilo/minimax/minimax-m2.5:free |
軽量かつ高速 | 簡単なスクリプト作成、設定ファイルの編集 |
※なお、以前まで優秀だった kilo/z-ai/glm-5:free は現在無料枠での利用ができなくなっているため、上記のモデルをタスクに応じて使い分けます。
速度・コスト・品質のトレードオフ分析と役割分担
賢いハイブリッド分業
- OpenClaw (マネージャー): 月額契約（GLM-4.7 Liteプラン等）で通信制限を気にせず安定稼働するモデルを使い、賢く設計やタスク分解を行う。ここでのトークン消費やリクエスト数は「指示書を作るだけ」なので最小限で済む。
- Kilo Code (ワーカー): 無料で使える高性能新モデル（step-3.5-flash:free等）を使い、実際のコードをゴリゴリ書かせる。大量にファイルを出力しても料金はかからない（コスト＝ゼロ優先）。
OpenClawでのハイブリッドモデル管理実践例
kilo-controller を利用した実装指示スクリプト
OpenClawからKiloにコーディングを委任する場合、以下のフォーマットでCLIコマンドを発行させています。
重要なのは、タイムアウトを設定してCLIのハングアップを防ぐことです。
# 基本的なKiloへの委任コマンド（OpenClawが自動生成して実行する）
timeout 600 kilo run "Pythonでフィボナッチ数列を計算する関数を実装して" \
--format json \
--auto \
--cwd /path/to/project \
-m kilo/stepfun/step-3.5-flash:free
用途別推奨モデル構成
現在のアーキテクチャに基づくベストプラクティス構成です。
1. プロジェクト管理・設計・Heartbeat処理（OpenClaw側）
| タスク | 推奨モデル | 理由 |
|---|---|---|
| 全体の要件定義・設計 | Zhipu AI GLM-4.7 (Lite) | ChatGPT Plusのように早々に制限にかかることなく、安定して司令塔を担えるため |
| 定期Heartbeat・メモリ整理 | Llama 3.1 8B (Ollama) | 毎時実行してもAPIコストがゼロで済むため |
| 複雑なトラブルシューティング | ChatGPT Plus (GPT-5.4) | 短期的でも圧倒的な推論力が必要な場面で最強のパフォーマンスを発揮するため |
2. コーディング・実環境構築タスク（Kilo Code側）
| タスク | 推奨モデル (-m) | 目安のタイムアウト |
|---|---|---|
| 超高速な自律修正や大規模機能実装 | kilo/stepfun/step-3.5-flash:free |
timeout 600 (10分) |
| 新規機能の実装・複数ファイル跨ぎ | kilo/arcee-ai/trinity-large-preview:free |
timeout 600 (10分) |
| 大規模なリファクタリング | kilo/corethink:free |
timeout 1200 (20分) |
トラブルシューティング
よくある問題と解決策
1. Kilo Codeの実行がハングアップする
# 原因: Kiloのプロセスが内部でブロックしているか、応答が遅延している
# 解決策: 必ず `timeout` コマンドでラップして実行させるようにOpenClawに指示する
# 修正後の実行イメージ
timeout 600 kilo run "..." --auto -m kilo/stepfun/step-3.5-flash:free
2. Kiloが指定したモデルを見つけられない (Model not found)
# 原因: Kiloのモデルアップデートにより古いモデル名が使えなくなっている
# 解決策: OpenClawのプロンプト（SKILL.mdなど）を更新し、最新の無料モデル名（例: step-3.5-flash:free）を正確に指定させる
3. OpenClawのAPIコストが高騰する
# 原因: OpenClaw本体に重いコード生成タスクを投げている
# 解決策: コーディングは絶対にKiloに任せる。OpenClawには「あなたはプロジェクトマネージャーです。コードはKilo Controllerに書かせてください」とシステムプロンプトで徹底する。
まとめ
LLMモデルの選定は、「どれか一つ最強のモデルを選ぶ」時代から、「用途に合わせて最適なプロバイダとエージェントを組み合わせる（ハイブリッド・オーケストレーション）」時代へと進化しました。
新たな選定のポイント
- 役割分担: 「考える（OpenClaw）」と「書く（Kilo Code）」を分離する。
- コストの最適化: 賢い指示出しには有料モデル（GLM-4.7/GPT）を、大量のアウトプット（コード）には強力な無料モデル（Kiloのstep-3.5-flash等）を使う。
- ローカル環境の活用: Heartbeatや定期監視などのバックグラウンド処理は、Ollama等を使ったローカルモデルでランニングコストを抑える。
- 自律エコシステムの構築: OpenClaw自身にKilo用のアダプタ（controller）を開発させることで、エージェント同士が連携する強力な自律環境を構築する。
この実践ガイドと構成が、皆様のローカルAI開発環境やオープンソースエージェント運用の参考になれば幸いです。