ソフトウェア開発のためのマルチモデルAIオーケストレーション：Claude、Codex、Geminiで10倍速く出荷する方法

私は2つのnpmパッケージに19個のツールを配備し、レビューして、10個のバグを直して、すべてを1晩で公開しました。より速くタイピングしたわけではありません。小さな開発チームを調整するのと同じやり方で、複数のAIモデルをオーケストレーションしたからです。

この変化は、ソフトウェア作業におけるAIの使い方を変えました。1つのモデルにすべてをやらせる代わりに、役割を割り当てます。つまり、あるモデルは計画し、別のモデルは調査し、別のモデルはコードを書き、別のモデルはレビューし、さらに別のモデルは大規模な分析を担当します（コードベースが広すぎて他のみんなでは扱いきれないときに備えて）。

The Problem

ほとんどの開発者は、最初にシンプルなパターンから始めます。チャットを1つ開いて、いくらかのコードを貼り付け、同じモデルに対して同じやり取りを繰り返して、いろいろ手伝ってもらう。これは小さなタスクには機能します。しかし実際のプロジェクトでは崩れます。

最初の問題は文脈（コンテキスト）の圧迫です。会話が大きくなるにつれて、モデルのコンテキストウィンドウは古くなった情報でいっぱいになります。すでに役に立たない詳細、行き止まりの探索、コピーしたログ、途中で終わったコードなどです。ウィンドウが技術的に十分大きくても、モデルが一度に抱え込む関心事が多すぎるため、品質が劣化することがよくあります。

2つ目の問題は、現代のコードベースは整然とした、単一言語だけのシステムではないことです。私が取り組むプロジェクトはしばしば、TypeScript、Python、C#、シェルスクリプト、READMEドキュメント、テストスイート、CI設定、パッケージメタデータにまたがります。TypeScriptのAST変換をレビューするのに必要な頭のモデルは、UnityのC#エディタコードを調べたり、信頼できるPythonのテストを書いたりするのに必要なものとは同じではありません。

3つ目の問題は、ソフトウェア開発は1つのタスクではないことです。さまざまな異なるタスクの束です：

• 実装コードを書くこと
• プロジェクトの慣習を調査すること
• 欠陥のレビューをすること
• ビルドとテストを実行すること
• アーキテクチャを比較すること
• 大規模なファイル横断分析を行うこと
• 素早い参照の質問に答えること

これらすべてを1つのモデルに任せるのは、1人のエンジニアにプロダクトデザイン、コーディング、テスト、ドキュメント作成、DevOps、コードレビューを同時にやらせるようなものです。

The Architecture: Each Model Has a Role

私は今、マルチモデル構成を使っています。各モデルには明確な仕事があります。

重要な制約はこれです：Opusは、直接読むのが3ファイルをほとんど超えず、また2ファイルをまたぐコードは書きません。

Opusは私の貴重なリソースです。コンテキストウィンドウは、意思決定、トレードオフ、調整のために確保したい。もしOpusに、10個の実装ファイルを読ませたり、テストフィクスチャをパースさせたり、リポジトリの半分にわたるコードを編集させたりしてしまうなら、システム内で最も価値のある推論の“表面積”を浪費してしまいます。

そこで私は意図的に、Opusに“ハンズオンの個人貢献者”というより“テックリード”として振る舞わせています：

• 何を作るべきかを決める。
• サブエージェントに証拠集めを依頼する。
• 調査結果を実装仕様に統合する。
• Codexにその仕様へ挑戦させる。
• 意見の食い違いを解消する。
• 実装を適切な実行エージェントへ送る。

The Core Principle: Preserve the Orchestrator

最適なモデルは、ファイル読み取り係、ログパーサ、バルクのコード生成係であるべきではありません。

もし次のような質問に答える必要があるなら：

• このリポジトリは新しいツールにどんな慣習を使っている？
• どんなヘルパー・ユーティリティがすでに利用可能？
• 既存のテストはエッジケースをどう構成している？
• プラットフォーム固有のフォーマットはどこで行われる？

私はOpusをそこに使いません。それよりSonnetエージェントにコードベースを調べさせ、構造化された知見を返してもらいます。質問が非常に多数のファイルにまたがる場合は、Geminiで広範囲スキャンを行い、パターン、アーキテクチャのつなぎ目（seams）、制約を要約させます。

その後Opusは、生のノイズではなくクリーンな入力をもとに意思決定します。

Real-World Example 1: Building 4 Platform Mappers in One Session

最も分かりやすい例の1つはfigma-spec-mcpです。これは、FigmaのデザインをコードのプラットフォームへブリッジするオープンソースのMCPサーバです。このパッケージにはすでにReactのマッパーがありました。そこで、共通の慣習を維持しつつ、正規化されたUI ASTを再利用して、React Native、Flutter、SwiftUIの対応を拡張したいと思いました。

しかし、作業は分割しました。

Workflow

1. Sonnetのサブエージェントがコードベースを調査しました。ツールの慣習、型のパターン、既存のReactマッパー設計、共有ヘルパー、そして正規化されたASTがシステム内をどう流れているかです。
2. Opusがそれらの知見を統合して、詳細な実装仕様を作りました。
3. 私はCodexに1つのプロンプトだけ送りました。正規化されたUI ASTを再利用し、見つかった慣習に従って、3つの新しいマッパーをすべて作成してください、と。
4. Codexは、新しいマッパー用の各“サーフェス”にわたって2,000行以上を書きました。
5. 別のCodexレビューセッションで、元の作者のようではなく、懐疑的なシニアエンジニアのように出力をレビューするよう依頼しました。
6. そのレビューで、10個のプラットフォーム固有のバグが見つかりました。
7. 3つのSonnetサブエージェントが、並行してそれらのバグを修正しました。
8. ツール一式はTypeScript、ESLint、Prettier、そしてpublintをすべて通過しました。

What the review caught

レビューで明らかになったのは、見た目が“緑（成功）”な実装からは分かりにくいバグでした：

• Flutterの色の出力で、間違ったバイト順序が使われていました。
• React NativeではshadowOffsetがオブジェクトではなく文字列として表現されていました。
• SwiftUIの出力は、欠けている色の初期化子に依存していました。
• 生成されたいくつかのプラットフォームプロパティが、あるフレームワークの慣習には一致する一方で、実際の対象プラットフォームのAPIとは一致していませんでした。

Result

私はそのセッションを、4つのプラットフォームマッパーをそろえ、レビュー済みで、修正済みで、lintがクリーンになり、本番投入可能な状態で終えました。約2時間でした。速さの理由は「1つのモデルに“より賢くなれ”と頼んだ」からではなく、専門化と並列化によるものです。

Real-World Example 2: Contributing to CoplayDev/unity-mcp

2つ目の例は、CoplayDev/unity-mcpへの一連のオープンソースへの貢献です。これはスターが1,000以上あるUnityのMCPサーバです。最も大きなものは、execute_codeツールを追加したことでした。これにより、AIエージェントがUnityエディタの中で任意のC#コードを直接実行できるようになります。Roslynによるインメモリコンパイル、安全チェック、実行履歴、リプレイ対応も備えています。

面白いのは、この機能ギャップがどうして見つかったかです。私はすでに、自分のプロジェクトでは別のUnity MCPサーバ（AnkleBreaker）を使っていました。そして、CoplayDevにない能力があることに気づいたのです。78のツールを手作業で34と比較する代わりに、AIエージェントに体系的に比較させました。

Workflow

1. 私は毎日2つのMCPサーバを両方扱うことで自分自身がギャップを特定しました。そのうえで、Sonnet探索エージェントを使い、AnkleBreakerの78ツールのセットにあるすべてのツールを、CoplayDevの34ツールに対して体系的にマッピングしました。エージェントは、どの機能が欠けているのかを正確に示す構造化された比較表を返してきました。
返却形式: {"translated": "翻訳されたHTML"}
2. そのギャップ分析から、最もインパクトの大きい貢献としてexecute_codeを選びました。これにより、AIエージェントがライブなUnityの状態を調査し、エディタの自動化を実行し、手作業の手順を必要とせずに前提を検証できる一連のワークフロー全体を解放できます。
3. SonnetエージェントがCoplayDevのデュアルコードベースの慣習（PythonのMCPサーバー＋C# Unityプラグイン）を深掘りしました。ツール登録のパターン、パラメータの扱い、レスポンスのエンベロープ形式、テスト構造を調査しました。
4. Opusは調査結果を、4つのアクション（execute、get_history、replay、clear_history）をカバーする詳細な実装仕様へと統合しました。危険なパターンに対する安全チェック、Roslyn/CSharpCodeProviderのフォールバック、実行履歴の管理も含めています。
5. Codexがフル実装を書きました：ExecuteCode.cs（インメモリコンパイルを備えたC# Unityハンドラ）、execute_code.py（PythonのMCPツール）、test_execute_code.py（ユニットテスト）。追加は1,600行以上。
6. Opusが出力をレビューし、PRが出る前に問題を見つけました。
7. レビューフィードバックを反映した後、PRはマージされました。

レビューで見つかったこと

• System.IOとProcessの利用に関するエッジケースで、安全チェックのパターンをより厳密にする必要がありました
• エラーレンチ数の正規化は、ラッパークラスのオフセットを考慮する必要がありました
• コンパイラ選択ロジックには、よりクリーンなフォールバック経路が必要でした

結果

execute_codeツールは、プロジェクトにおけるより重要な貢献の1つになりました。AIエージェントがシーンの階層を実行時に調査したり、コンポーネント参照をプログラム的に検証したり、エディタの自動化スクリプトを実行したりできるようになったためです。この貢献は思いつきではなく、実際のギャップ分析に基づいていました。さらにマルチモデルのワークフローにより、2つの言語にまたがるプロジェクトの慣習に実装が一致することが保証されました。

実世界の例3：roblox-shipcheck シューター監査拡張

3つ目の例はroblox-shipcheckで、オープンソースのRobloxゲーム監査ツールです。私は、シュータージャンル固有のツールを6つ追加し、それらを中心にパッケージを拡張したいと考えました。テスト、ドキュメント、例、リリースノートも一緒に整備しました。

ワークフロー

1. 背景のSonnetエージェントが並行して作業しました。READMEの書き換え、CHANGELOG、使用例、ユニットテストです。
2. Codexが6つすべてのシューター用ツールを書きました。武器設定の監査、ヒットボックスの監査、スコープUIの監査、モバイルHUDの監査、チーム基盤の監査、アンチチートサーフェスの監査です。
3. 別のレビューセッションで、Codexは生成された実装をレビューし、8つの問題を見つけました。
4. Sonnetエージェントがそれらの問題を修正し、124件のテストを通過させました。
5. Sourcery AI（自動レビュアーとして動作）が、さらに3つの問題を見つけました。
6. 別のSonnetエージェントがレビューのフィードバックに対応し、残っていたエッジケースを引き締めました。

レビューで見つかったこと

最初のレビューの波では、次が見つかりました：

• ESLint違反
• 実世界のプロジェクトに対して厳しすぎるヒューリスティック
• フリーフォーオールのゲームモードに対する誤検知

続いて、自動レビュアーでは次が見つかりました：

• 共通のテストヘルパーを統合できる可能性
• 監査スイートにおけるエッジケースの欠落
• 再利用と一貫性に関する実装詳細のところどころが粗い

結果

最終的にパッケージは合計49個のツール、通過124件のテスト、より分かりやすいREADME、更新された使用例、リリースノート、そしてTypeScript、ESLint、Prettier、SonarCloudでグリーンになったCIを備える形で仕上がりました。これは「コードを少し足した」ことと「保守可能なリリースを出荷した」ことの違いです。

トークン予算ルール：重要な洞察

この一連から得られる最も重要な教訓はシンプルです：オーケストレータのコンテキストウィンドウが、システム内で最も乏しいリソースです。

私は今、次のルールに従っています：

1. Opusは各タスクで3ファイル以下しか読みません。 それを超える必要がある場合は、SonnetまたはGeminiに読ませて、構造化された要約を依頼します。
2. Opusは2ファイル以下でコードを書きます。 タスクが2ファイルを超えるなら、詳細な仕様とともにCodexに渡します。
3. どんなタスクを始める前にも「サブエージェントができる？」と問い直します。 答えが「はい」ならそこで止めて委譲します。
4. Codexはすべてをレビューします。 Codex自身が書いたコードであってもです。レビューは別セッションで行い、自分の前提に異議を唱えられるようにします。
5. 独立した作業には並列エージェントを使います。 ドキュメント、テスト、使用例、changelogの更新が互いに依存していないなら、同時に進めるべきです。

私が使っている考え方のモデルはこれです：

Opus = 貴重な戦略的バンド幅
Sonnet = 安価な並列調査
Codex = 分離された実装とレビュー
Gemini = 大規模コンテキストの調査パス

コンテキストを「無限のバッファ」ではなく「予算」として扱い始めてから、セッションの信頼性が劇的に高まりました。

対話（ディベート）パターン

このセットアップで最も効果的なテクニックの1つが、私がディベート（討議）パターンと呼んでいるものです。

1つのモデルに解決策を聞いて、そのまま実装してしまうのではなく、私は「不一致（反対意見）」のフェーズを強制します。

手順

1. Opusが問題を分析し、解決策を提案します。
2. Codexはその分析を受け取り、対抗分析を作成します。合意する点、反対する点、そして自分なら何を変えるかです。
3. 衝突があれば、それを解消するためにフォローアップの1ラウンドだけ行います。
4. コンセンサスが得られたら、それを実装計画に変換します。
5. Codexが実装します。
6. 別のCodexセッションが結果をレビューします。

うまくいく理由は、不一致が隠れた前提を露わにするからです。

あるセッションでは、そのディベートによって次が見つかりました：

• FlutterのColor書式の混乱：0xRRGGBBAAと0xAARRGGBB
• variantが正しいのに、modeを使ってReact Native Paperのpropが一致していない
• 存在しないSwiftUIのColor(hex:)イニシャライザ

これらはいずれも、広範なアーキテクチャ上の失敗ではありませんでした。マージ後に時間を浪費してしまう、プラットフォーム固有の「正しさ」系のバグの類です。だからこそ、早期に捕まえる必要があります。

ディベートパターンは、AI支援を「高速なオートコンプリート」から「敵対的な設計レビュー＋実装」へと変えます。

結果

パフォーマンスの差が十分大きいため、私は今ではデフォルトでオーケストレーションする前提で考えています。

始めるには

このワークフローを試したいなら、まずはシンプルに始めてください。初日から大規模な自動化スタックは不要です。必要なのは、役割の分離と、いくつかの明確なルールだけです。

実践的なセットアップ

• Claude Code CLI（オーケストレータとしてOpusを使用）：計画、意思決定、ユーザー向けの調整のため
返却形式: {"translated": "翻訳されたHTML"}
• Codex MCP server (npm: codex) は、実装、サンドボックス化されたコード変更、そしてレビューのため
• Gemini MCP (npm: gemini-mcp-tool) は、大規模なリポジトリ分析と、多数のファイルにまたがる幅広いリサーチのため
• Claude Code の Agent ツール経由の Sonnet サブエージェント は、コードベース調査、ビルド、テスト、パターン抽出、ドキュメント作成、サポート作業のため

最も重要な運用上の詳細は、ルールを書き出して CLAUDE.md に記載することです。オーケストレータが毎セッション、あなたの好みを再発見しなければならないなら、整合性が失われ、トークンも無駄になります。

私の CLAUDE.md には、たとえば次のようなルールがあります：

- Opus は 3 ファイル以下を直接読み取る
- Opus は 2 ファイル以下を直接書き込む
- コードベースの探索は Sonnet に委任する
- 複数ファイルにまたがる実装には Codex を使う
- 公開前に必ず別のレビュー・パスを実行する
- 独立したタスクには並列のサブエージェントを優先する

この 1 つのファイルによって、場当たり的なプロンプトが再現可能な運用モデルに変わります。

最初の良いワークフロー

手間をかけずに始めたいなら、これを試してください：

1. Sonnet を使ってリポジトリを調査し、慣習（コンベンション）を要約する。
2. Opus を使って短い実装仕様（implementation spec）を書く。
3. Codex を使って、影響を受けたファイル群に対して実装する。
4. 新しい Codex セッションで欠陥（defects）についてレビューする。
5. Sonnet を使って問題を修正し、テストを実行する。

実践的な教訓

私にとって最も大きな差を生んだのは、3つの習慣でした。

まず、AI の出力を「完成物」として扱うのをやめ、管理されたワークストリームとして扱うようにしました。意味のあるコード変更には、リサーチ、実装、レビュー、検証のフェーズがあります。異なるモデルは、フェーズごとに得意・不慣れが違います。

次に、独立したコンテキストは「制約」ではなく「機能」だと学びました。Codex が別のセッションからコードをレビューする場合、実装パスでの仮定をすべて引き継ぎません。この距離が、バグを見つけられる理由そのものです。

第三に、「最高のプロンプト」を最適化するのをやめ、「最高のルーティング」を最適化するようにしました。より良い問いはこうです：この特定のタスクに、どのモデルがトークンを使うべきか？

結論

AI 支援開発の未来は、1つの巨大なチャットの中に鎮座する単一の万能モデルではありません。必要なのはオーケストレーションです。つまり、適切なタスクに適切なモデルを使い、意思決定のためにあなたの最も強いモデルのコンテキストを保持し、専門のエージェントにリサーチ、実装、レビュー、検証を任せることです。

すでに開発で AI を使っているなら、私の実践的な助言はシンプルです。1つのモデルにすべてをやらせるのをやめましょう。それぞれのモデルに役割を与え、オーケストレータのコンテキストウィンドウを守り、そして本当のレビュー・パスを追加してください。そこに 10 倍の改善が生まれます。