「最強のAIはどれ？」をやめてみた——fusion-harnessという新しい発想
最近、AIを使ってアプリ開発をしていると、ずっと同じ問題にぶつかります。
「Claude CodeとCodex、結局どっちがいいんだろう？」
自分もClaude Code、Codex、Cursor、Antigravityなど、いろいろ触ってきました。
あるAIは設計がうまい。あるAIはコードを書くのが速い。別のAIは、エラーの原因を見つけるのが妙にうまい。
そのため新しいモデルが出るたびに、「今度はこっちの方が強いらしい」「いや、コーディングならこっち」と、AIを乗り換える話になりがちです。
ところが最近、この考え方そのものを変えてしまいそうな面白いプロジェクトを見つけました。その名前が、fusion-harness です。
「どのAIが一番強い？」という質問をやめる
fusion-harnessの考え方を一言で表すなら、
「AIを競わせるのではなく、組み合わせる」
です。公式READMEにも、
Fuse frontier models instead of racing them. AND, not OR.
という考え方が掲げられています。つまり、ClaudeかCodexか、GeminiかClaudeか、という「OR」の発想ではありません。Claude AND Codex AND Gemini という発想です。
人間の開発チームでも、設計が得意な人、実装が速い人、レビューが得意な人がいます。だったらAIも同じように、得意な仕事を分担させればいい、というわけです。
fusion-harnessとは？ ——2つのバージョンがある
fusion-harnessは、Pi Coding Agentをベースにしたオープンソースの拡張です。
調べてみると、実はこれには2つの世代があります。
オリジナル版：ARCHITECT（設計）とBUILDER（実装）の2体制。/opinion /fusion /auto-validate という3つのコマンドが用意されています。
拡張版（V2）：ARCHITECT＋Main BUILDER＋最大3体のサブBUILDERまで、2〜5体制を組めるように発展したフォーク。/fh- で始まるコマンド群（後述）が使えます。
例えば、
Claude系モデル → ARCHITECT（設計）
GPT系モデル → Main BUILDER（実装）
Geminiや別のモデル → セカンドオピニオン
といった構成が可能です。しかも「複数AIに同じ質問を投げる」だけではありません。設計、議論、統合、実装、検証までをワークフローとして組めるようになっています。
面白い機能① 複数AIに同時に意見を聞く（/fh-opinion）
まず面白いのが /fh-opinion です。同じ問題を複数のAIモデルに渡し、それぞれ独立して回答させます。
例えば、「このiOSアプリのデータ構造、どう設計する？」という問題に、Claude・GPT・Geminiがそれぞれ回答する。
一つのAIだけ使っていると、そのAIが間違った方向へ進んでも気付きにくい。でも3つのAIが別々に考えて、A案・B案・C案を出してくれれば、かなり比較しやすくなります。
このモードでは各AIが読み取り専用になっているため、勝手に同じコードを書き換えて衝突することを防ぐ設計になっています。
面白い機能② AI同士に議論させる（/fh-debate）
さらに面白いのが /fh-debate です。文字通り、AI同士で議論させます。
最初に各AIが独立して意見を出す。次のラウンドでは、他のAIの意見を読ませる。すると、「こちらの案の方が良い」「その指摘を考慮すると自分の案を修正する」「この部分はA案、こちらはB案が良い」といった形で意見を変えることもできます。
最終的に必ず一つの答えへまとめる必要もありません。少数意見として残ることもできます。一人の天才AIに全部任せるのではなく、AIによる技術検討会を開くようなイメージです。
面白い機能③ 最後に「Fusion」する（/fh-fusion）
そして名前の通り中心になるのが /fh-fusion です。複数モデルが同じ問題について調査・検討したあと、それらの回答をFusion Agentがまとめます。
重要なのは、「多数決で決める」わけではないこと。それぞれのモデルの長所を利用しながら、一つの結果へ統合します。
例えば、Claudeはアーキテクチャ設計が良かった、GPTはSwiftの実装方法が良かった、Geminiはセキュリティ上の問題を発見した、なら、それぞれの良い部分を統合した設計を作ればいい。「どのAIが勝ったか」ではなく、「最終成果物が良ければいい」という発想です。
面白い機能④ AIチームとして共同開発する（/fh-collaborate）
最新版には /fh-collaborate という機能もあります。ここまで来ると、かなり「AI開発チーム」です。
まず全AIが問題を分析。ARCHITECTがそれらをまとめて作業計画を作ります。その後、Task 1・Task 2・Task 3のように仕事を分割。依存関係のない仕事は並列で処理し、順番が必要なものは順番に処理します。
つまり、AIに質問するというより、AIチームにプロジェクトを渡すという感覚に近づいています。
「複数AIが同時にコードを書いたら危なくない？」
ここで一つ疑問が出ます。ClaudeとGPTとGeminiが同時にコードを書いたら、「ファイルがぐちゃぐちゃになるんじゃない？」という問題です。
fusion-harnessでは、この問題にもかなり注意が払われています。基本思想は Single-writer invariant（単一の書き込み者の原則）です。
つまり、同じ作業ディレクトリを書き換えられるAIは基本的に一度に一つ。調査や設計は複数AIが並行して行えますが、実際にコードを書き換える場面では、書き込み権限を厳しく制御する。これによってAI同士が同じファイルを同時編集する事故を防いでいます。
この辺は単なる「複数AIチャット」ではなく、実際のソフトウェア開発をかなり意識した作りです。
さらに面白い「自動検証」（/fh-auto-validate）
もう一つ注目したいのが /fh-auto-validate です。考え方は、作ってから「動くかな？」ではなく、先に合格条件を作る、というものです。
まずVALIDATOR側が「何ができれば完成なのか」というテスト条件を作ります。そのあとBUILDERが実装。テストを実行。失敗。修正。もう一度テスト。成功するまで繰り返す、という流れです。
AIはコードを書くのは非常に速くなりました。でも、「それ、本当に動くの？」という問題は残っています。AIに作らせるだけではなく、AIに検証させる。ここまでを一つの仕組みにしているのが面白いところです。
実はDevinも「Fusion」を始めている
さらに興味深いのは、この「複数モデルを役割分担させる」という考え方がfusion-harnessだけのものではないことです。
Devinを開発するCognitionも「Fusion」を展開しています。2026年9月にはDevin DesktopとCLIにもFusionが導入されました。こちらも考え方は似ていて、高性能なモデルを「Lead」、比較的低コストなモデルを「Sidekick」として組み合わせます。難しい判断はLead、機械的な作業はSidekick、という役割分担です。
Cognitionは、Fable 5.1とSWE-2などを組み合わせたFusionについて、主要なコーディングベンチマークで他のモデルハーネスより最大39％効率的だったと報告しています。第三者評価機関（Artificial Analysis / Vals AI）による検証も行われているとのことです。
面白いのは、その中で見つかった副産物です。Fableを"Lead"にした場合、トークン単価自体は従来モデルの2倍でも、実際のセッションコストは平均9％安く済み、しかもベンチマークスコアは上がったと報告されています。理由は「賢いモデルほど、早い段階で作業を任せる判断ができ、指示の出し方も的確になるから」。これはまさに、fusion-harnessが体現している「得意な仕事を分担させる」という発想を裏付けるデータだと感じました。
もちろんこれはCognition側の評価なので、そのまま一般化するのは注意が必要ですが、「一つの最強モデルですべて処理する」以外の方向へAI開発が進み始めていることは非常に興味深いです。
これから重要になる「Harness」という考え方
最近「Harness Engineering」という言葉を見かけるようになりました。
AIモデルそのものだけを見るのではなく、モデル・プロンプト・ツール・MCP・メモリ・権限管理・テスト・複数エージェント・モデルルーティングなどを組み合わせ、AIをどう働かせるかという仕組みそのものを設計するという考え方です。
fusion-harnessは、まさにそれを体験できるプロジェクトだと思います。
自分のアプリ開発に置き換えて考えてみる
自分の場合、AIを使ってiPhoneやMacアプリを作っています。
これまでは、Claude Codeで作るか、Codexで作るか、Cursorを使うか、Antigravityを使うか、という「ツール選び」をかなり意識していました。
でもfusion-harnessの考え方を見ると、そもそも一つに決める必要があるのか？と思えてきます。
例えば将来的には、
Claude → アプリ全体の設計
Codex → Swift/SwiftUI実装
Gemini → UIや別視点からのレビュー
別の高速モデル → テストや単純修正
最後にClaudeやGPT → コードレビュー
というAI開発チームを組む。人間である自分は、「コードを書く人」ではなく、AI開発チームに何を作らせるか決める人になる。この方向はかなり面白いと思っています。
ただし弱点もある
もちろん良いことばかりではありません。
複数モデルを動かすのでAPIコストが増える可能性がある
環境構築も、Claude CodeやCodexを単体で使うより複雑
複数AIが同じ間違いをすれば、Fusionしても正解にはならない
最終的な成果物について、人間が確認する必要がなくなるわけでもない
fusion-harness自身も、複数モデルによって死角を減らせても完璧になるわけではない、と説明しています。
なので現時点では、「初心者が最初に導入するAIコーディング環境」というより、Claude CodeやCodexをある程度使った人が次に試すもの、という印象です。
「最強AI探し」から「最強チーム作り」へ
AIコーディングを始めた頃は、「どのAIが一番頭がいいんだろう？」と考えていました。
でもモデルの性能が上がり続けると、この質問自体があまり意味を持たなくなるのかもしれません。Claudeが得意なこと、GPTが得意なこと、Geminiが得意なこと。それぞれを組み合わせればいい。
つまり次のAI開発競争は、「最強モデルは何か？」ではなく、「AIをどう組み合わせたら最強の開発チームになるか？」なのかもしれません。
fusion-harnessを見ていると、その未来が少し見えてきた気がします。個人的にはかなり試してみたい仕組みです。
次は実際にMacへfusion-harnessをインストールして、Claude＋GPT＋GeminiのAI開発チームで、本当にiPhoneアプリを作れるのか試してみようと思います。
