Claude Code向けのマルチモデル・オーケストレーション層「pilotfish」が、GitHub公開からわずか1週間で352スターを獲得した。高性能モデルが計画を立て、安価なモデルが実装し、検証用モデルが品質を守る——この三層分業アーキテクチャは、単一モデル依存の開発フローを過去のものにしつつある。コードと仕様書から、この構造変化の本質を読み解く。
何が起きたか
Nanako0129氏が公開したOSSツール「pilotfish」が、Claude Codeユーザーの間で急速に拡散している。公開1週間で352スターというペースは、開発者向けツールとしては明確に「刺さっている」水準だ。
コンセプトはシンプルで、Claude Codeの実行フローに「モデル役割分担レイヤー」を差し込む。フロンティアモデル（想定：Claude Opus級）がタスク分解と設計を担当し、実装フェーズは安価なモデル（Haiku級を想定）に委譲、生成コードは別モデルが検証（verification guards）する。コマンド一発で導入可能で、Claude Code本体のAPI課金構造を大きく変えずに、実効コストを圧縮できる点が拡散の起点になっている。
「1モデルにフル権限」から「モデル群を役割で束ねる」への移行を、非常に薄いラッパーで実現している点が技術的なポイントだ。
claude codeは何が変わるか
Claude Codeは登場以来、単一のエージェントに計画から実装、修正までを一任するUXが売りだった。だがコンテキストが伸びるほどOpus級モデルのトークンコストは指数的に膨れ上がり、月額数万円〜十数万円の課金報告が国内外のエンジニア間で常態化していた。
pilotfishが刺さっている理由はコスト削減だけではない。本質は「計画と実装は要求される知能が違う」という当たり前の事実を、ようやくツールチェーンが認めた点にある。設計判断には長期記憶と抽象化が要るが、確定した仕様のコード化はパターンマッチング寄りのタスクだ。ここに同じ単価のモデルを張り付けるのは、シニアエンジニアにコピペ作業をさせるのと同義だった。
さらに検証層の分離は、LLMの自己一貫性バイアス——自分が書いたコードを自分でレビューすると欠陥を見逃す傾向——への構造的な対抗策になる。単一モデル完結型のAIコーディングは、品質面でも上限に達しつつあったと解釈すべきだ。
技術的な深掘り
オーケストレーション層としてのpilotfishが興味深いのは、Claude Code本体をフォークせず「サブエージェント呼び出し」の抽象を差し替える設計だと推定される点だ。Claude CodeはすでにTaskツール経由で子エージェントを起動できるが、そこに投入するモデル選択がハードコード寄りだった。pilotfishはこの選択をポリシー化し、タスク種別（plan / implement / verify）ごとにモデルを切り替える。
ここで注視すべきは「verification guards」の実装粒度だ。単なるdiffレビューなのか、テスト生成と実行までを含むのか、はたまた仕様書との照合まで踏むのか——リポジトリのREADMEレベルの情報から断定はできないが、検証層が「別モデル・別コンテキスト」で走る時点で、単一モデルの盲点は確実に減る。
一方で懸念もある。三モデル間の情報受け渡しは自然言語プロンプトを介する以上、計画→実装の翻訳ロスは不可避だ。フロンティアモデルが「察してほしい」を残した設計書を渡せば、Haiku級実装は破綻する。分業アーキテクチャの成否は、計画層が出す中間表現の厳密さに完全に依存する。ここに構造化フォーマット（TypeScript型定義やJSON Schema）を挟むツールが次に勝つ、と読む。
経営者として次に取るべき動き
第一に、社内のAI開発コストを「モデル別」に可視化せよ。Claude Code一括請求のまま放置している組織は、Opus級で書かなくてよいコードにOpus単価を払い続けている。タスク種別ごとのトークン消費を把握するだけで、圧縮余地が数十パーセント単位で見える。
第二に、AIコードレビューの一段目を人間から剥がす体制を今四半期中に設計する。pilotfish的な検証層を前置すれば、シニアエンジニアのレビュー工数は仕様確認と設計判断に集中できる。開発サイクルの短縮は、エンジニア採用より確実で速いROIを生む。
第三に、「単一AIベンダー依存」を戦略リスクとして経営会議の議題に載せる。Claude、GPT、Geminiを役割別に組み合わせられる組織と、1社に全乗せの組織では、来年時点でコスト構造も品質保証も別次元になる。マルチモデル設計能力は、もはやインフラ選定と同じ経営マターだ。