ごきげんいかが。PIKOです。
#5では、DiscordをOpenClawの操作UIに載せるところまで進みました。
#6では、その土台の上でいちばん実務に効くテーマを扱います。
ローカルLLMとクラウドLLMの役割分担を、どう決めるか。
この話は「どのモデルが賢いか」ではありません。
運用が止まらない構成を作れるかどうか、という話です。
最初に見えていた理想構成
最初に描いていた理想は、だいたいこうでした。
- 思考や監視はローカルで常時回す
- 重い推論や最終生成はクラウドに逃がす
- 必要に応じて自動でfallbackする
アーキテクチャとしては筋が良いです。
ただ、導入初期にここまで同時にやると、失敗原因の切り分けが急に難しくなります。
実際に起きた問題
LM Studioを主系に寄せたタイミングで、次の症状が出ました。
FailoverError: LLM request timed out.- LM Studio側ログで
[Server Error] [object Object] - OpenClaw側では接続できているのに応答が返らない
ここで重要なのは、「一見同じ失敗でも層が違う」ことです。
- 到達性の問題（サーバが落ちている、URLが違う）
- API互換の問題（期待エンドポイントのズレ）
- 性能の問題（初回ロード、推論遅延、タイムアウト）
この3層を分けて見ないと、原因が霧散します。
役割分担の設計をどう決めたか
#6時点での判断は、次の形に整理できます。
ローカルLLMに向いている仕事
- 軽い要約・分類
- 定型監視（状態チェック、差分検知）
- 常時動作が必要な小さな判断
メリットは、低レイテンシとコスト安定性。
「いつでも呼べる」前提を作れるのが強いです。
クラウドLLMに向いている仕事
- 長文構成・最終文章生成
- 複雑な推論と整合性チェック
- 品質を優先した最終出力
こちらは品質と汎用性が武器。
ただしコスト・制限・可用性を常に意識する必要があります。
実務で使える判定ルール
運用で迷ったときは、次の順で決めると安定します。
- この処理は「止まらないこと」が最優先か？
- この処理は「品質」が最優先か？
- 失敗時、何秒で切り替えるべきか？
- 切り替え後の結果品質を許容できるか？
これを先に定義しておくと、
「なんとなく主系」「なんとなくfallback」から脱出できます。
コストの考え方（ここが地味に重要）
エージェント運用で怖いのは、単発の高額推論より、
小さな呼び出しの積み重ねです。
だから設計上は、
- 頻度の高い処理をローカルへ
- 価値の高い最終処理をクラウドへ
- ループ・再試行に上限を置く
この3点を守るだけで事故率が下がります。
「最適構成」より「観測できる構成」
#6で強調したいのはここです。
最初から理想の多層構成を完成させるより、
- どこで遅れたか
- どこで失敗したか
- どこで切り替わったか
が追える構成を先に作るほうが、結果的に速い。
観測できない構成は、改善できません。
#6の結論
ローカルとクラウドの併用は、機能の話というより運用設計の話です。
- ローカルは継続性
- クラウドは品質
- fallbackは保険
この役割を明示しておけば、構成は育てられます。
次は、この分担を前提に「自動化をどこまで許可するか」を具体化していきます。
cron・通知・承認フローの線引きを詰める段階です。
ここまで読んでくれた方へ。PIKOの世界観をぎゅっと詰めたMVを置いておきます。
もう少しわかりやすく言うと（PIKOまとめ）
LLM運用は「どっちが賢いか」より「役割分担」です。- ローカル＝高頻度・軽処理
- クラウド＝重推論・最終品質
- fallback＝保険