Grok・OpenCode・Codex・ローカルLLMの役割分担で開発を進める
調査・実装・統合検証・限定実装で4つのAIツールを役割分担させた個人開発の運用記録。広い依頼を失敗させない5点セットの渡し方まで。
複数のAIツールを併用する開発では、「誰に何を任せるか」を決めないまま作業を始めると、出力の品質にムラが出たり、同じ調査を何度もやり直したりしがちです。ある個人開発の実装記録から、Grok CLI・OpenCode CLI・Codex・ローカルLLMを役割分担させた運用を紹介します。
4者の役割分担
| 担当 | 役割 | やらせなかったこと |
|---|---|---|
| Grok CLI | 設計の壁打ち、ツールの使い方調査 | 個別の最終判断・原因の断定 |
| OpenCode CLI | 小さな実装タスク、ローカルLLMの実験 | 広い仕様決定、無検証の大量変更 |
| Codex | 仕様固定、プロンプト作成、差分レビュー、テスト、統合 | LLM出力をそのまま採用すること |
| ローカルLLM | 限定されたコード作成・レビュー | 数値確率の生成、最終採否 |
ポイントは、Grokの調査結果を「仮説」として扱い、最終的な根拠にはプロセスログ・テスト結果・実際のCLI応答を使っていることです。Web検索を伴う調査は観測時間内に調査計画だけで終わることもあり、調査結果をそのまま実装計画の根拠にしないという運用ルールが記録されています。
広い依頼は失敗しやすい。渡し方を変える
OpenCode・ローカルLLMへタスクを渡す際、「〇〇を実装して」という広い依頼は失敗しやすいことが分かっています。そこで、次の5点を必ず渡す運用にしています。
- 目的：何を満たすための変更か
- 対象ファイル：読んでよい／変更してよいファイル
- 変更禁止範囲：触らない層・API・生成物
- 受け入れ条件：具体的な入出力・境界条件
- 実行テスト：focused pytest、Ruff、mypyなど
例えば「walk-forward foldsを実装して」ではなく、対象ファイルを1〜2本に絞り、分割日数などの具体的な数値と受け入れ条件を渡す形にしたところ、限定実装ではテストが通過するようになりました。
ローカルLLMに大きな仕事を渡すほど、モデルの知識量より「探索・思考・ツール呼び出しの予算配分」が問題になります。対象を狭め、テストを先に置くと、実装ループへ入りやすくなります。
LLMの出力を無検証で採用しない
4者のうちCodexの役割は「統合・検証」であり、他のLLMが書いたコードをそのまま採用しません。テスト結果を見た上で、失敗している論点を1つずつ、対象ファイルだけを再読させて反復修正する、という流れが徹底されています。編集が始まった＝完成ではない、という前提を運用ルールとして固定しているのが特徴です。
この分担の考え方が使える場面
- 調査系AI（Web検索付き）と実装系AI（ローカル・CLI）を両方使っている
- 複数のAIエージェントに実装を任せているが、品質にムラがある
- 「AIが書いたから正しい」という前提で採用してしまいがちだと感じる
- タスクの粒度が大きすぎて、AIエージェントが迷走することが多い
AIツールが増えるほど、「何を、どのAIに、どこまで任せるか」を先に固定しておく設計が効いてきます。