設計はGrok、実装はOpenCode経由のOllamaへ：役割分担で個人開発のコストを抑える

個人開発でAIツールを使い分けるとき、「1つのAIに設計から実装まで全部任せる」のと「役割ごとに別のAIを使う」のとでは、コストと品質のバランスが変わってきます。実際にブログのUX改善作業で、Grok CLIに設計の壁打ち、OpenCode CLI経由のOllamaに実装を任せる、という役割分担を試したので、その記録です。

なぜ役割を分けるのか

Claude Codeのようなクラウド型AIは高性能ですが、利用量に応じて課金が発生します。一方、ローカルのOllamaで動くモデルは無料で使い放題ですが、複雑な設計判断や大きなコードベースの一括理解は苦手なことがあります。

そこで、次のように役割を分けました。

設計・壁打ち: Grok CLI
  → コードベースを読み、UX上の課題を分析し、改善案を複数提示する

実装: OpenCode CLI 経由の Ollama（ローカルモデル）
  → 確定した設計指示（仕様書）を渡し、コードの変更だけを行わせる

最終判断・検証: Claude Code
  → 提案の妥当性を検証し、実装を検証し、デプロイする

実際にやってみて分かったこと

Grok CLIは「調査してから提案する」挙動が強い

単純なプロンプトを1回投げただけでは、「確認します」で止まってしまうことがありました。コードベースを実際に読ませた上で「最終的な提案を必ず本文として完結させてください」と明示すると、具体的で実装可能なレベルの提案が返ってきます。壁打ち相手として使う場合、この「調査→提案」の挙動を前提にプロンプトを設計する必要があります。

ローカルモデルへの実装委任は、モデル次第で安定性が大きく変わる

今回、複数のローカルモデルで実装を試したところ、次のような差が出ました。

同じタスクでもモデルによって「まったく動かない」から「意図通りに動く」まで差が大きく、事前に軽いタスクで動作確認してから本番の実装を任せるのが安全だと分かりました。

「委任した結果を鵜呑みにしない」が最重要

ローカルモデルに実装を任せた後は、必ずgit diffで実際の変更内容を確認しています。理由は単純で、ツールの実行が失敗していても「完了しました」という体裁のテキストだけを返してくることがあるためです。出力されたテキストではなく、実際にファイルが変更されたかどうかを毎回確認する必要があります。

この役割分担が向いている場面

• 設計の選択肢が複数あり、トレードオフを整理したい場面：Grokのような「壁打ち相手」に、既存コードを踏まえた複数案を出させる
• 仕様が明確に固まった後の、機械的な実装作業：ローカルモデルに任せてコストを抑える
• 本番反映前の最終検証：クラウド型AIで実際の挙動を確認してからデプロイする

逆に、仕様が曖昧なまま実装だけをローカルモデルに投げると、空応答やタイムアウト、意図とずれた変更といった形で手戻りが発生しやすくなります。設計と実装は別の担当、という考え方は、AIを使い分ける上でも人間のチーム編成と同じ発想が有効だと感じています。

まとめ

「設計はGrok、実装はローカルモデル、検証はClaude Code」という役割分担は、コストを抑えながら品質を保つ現実的なバランスでした。ただし、ローカルモデルは動作の安定性にばらつきが大きいため、事前の動作確認と、実装後の差分確認は省略できません。