Claude Codeの請求書に頭を抱える開発現場に、新しい処方箋が届いた。公開わずか3日で322スターを集めたOSS「Pilotfish」は、高額なフロンティアモデルに設計だけを任せ、実装は安価モデル、最後に検証モデルが品質を守る3層アーキテクチャを提案する。単なるコスト削減ツールではなく、AI開発の分業構造そのものを塗り替える設計思想として読み解きたい。
何が起きたか
GitHubに公開された「Nanako0129/pilotfish」が、公開3日で322スターを獲得した。Claude Codeを軸にしたマルチモデル・オーケストレーション層で、役割分担は明快だ。フロンティアモデル（Claudeの上位モデル想定）が要件分解と実装計画を立て、コード生成はより安価なモデルに委譲、最後に検証役のモデルがdiffやテスト結果をレビューして品質ゲートを通す。導入はワンプロンプトで済むとされ、既存のClaude Code運用に薄く被せる形で動作する。背景には、Claude Codeを日常的に叩き続けるチームでAPI費用が青天井に膨らむという、現場の切実な悩みがある。「計画・実行・検証」というソフトウェア工学の古典的な三分割を、LLMのコスト特性に沿って再定義した点が、短期間で支持を集めた最大の理由だ。
claude codeのコスト構造は何が変わるか
Claude Codeの料金構造を分解すると、支出の大半は「大量トークンを吐き出す実装フェーズ」に集中する。設計フェーズは思考の密度こそ高いが、出力トークンは意外と少ない。ここに、料金レンジが1桁違うモデルを混在させる余地が生まれる。ナレーションで示された「3〜5割削減」は、推定として妥当なレンジだ。仮に月間APIコストが100万円の開発チームであれば、実装フェーズを安価モデルに逃がすだけで30〜50万円が浮く計算になる。
さらに重要なのは、Pilotfishが「検証役」を独立させたことだ。従来のマルチモデル構成は「賢いモデル1つ＋安いモデル1つ」の2層が主流で、安価モデルのハルシネーションを人間のレビューで吸収してきた。検証層をLLMで自動化すれば、レビュー工数という隠れコストにもメスが入る。Claude単体運用が持つ「賢いが高い」というトレードオフを、アーキテクチャで解消しに来ている点が本質的な差分だ。
技術的な深掘り
エンジニア視点で気になるのは、3層間の「文脈受け渡し」の設計である。計画モデルが出した実装プランを、安価な実装モデルが正しく解釈できるかは、プロンプト設計の質に大きく依存する。ここが甘いと、実装モデルが計画を誤読して的外れなコードを吐き、検証モデルがそれを弾き、再実行でトークンが二重に消費される——という「逆に高くつく」パターンに陥る。Pilotfishが322スターまで一気に伸びた事実は、この受け渡しフォーマットが実用水準に達していることを示唆する。
もう一点、検証モデルの選定が肝になる。検証は「間違いを検出する」タスクであり、生成より必要な知能水準が低いという通説があるが、実際にはコードのセマンティクスを追う必要があり、あまりに軽量なモデルではフォールスネガティブ（見逃し）が増える。中位モデルを検証に置き、下位モデルを実装に置く「Y字型」の配置が現実解だと推定する。単純な「安いモデル一択」ではなく、タスク×モデル特性のマッピングを丁寧に組んだチームが、この3層構造の恩恵を最大化できる。
経営者として次に取るべき動き
第一に、自社のClaude Code利用ログを引き出し、「計画・実装・検証」のトークン比率を可視化することだ。多くの現場で実装トークンが7割以上を占めているはずで、そこが即座のコスト削減余地になる。
第二に、Pilotfishのような3層構造を、小規模プロジェクトでPoC導入する。ワンプロンプトで入るなら、1週間で費用対効果は測定できる。並行して、検証モデルの精度ログを取り、人間レビュー工数の削減幅を数値で押さえておきたい。
第三に、この思想を開発以外の業務にも展開する。企画・実行・検証の3層は、マーケティング施策、顧客対応、経理処理にもそのまま写像できる。「賢いAIに全部任せる」思考をやめ、業務を三分割してモデルを割り当て直した企業が、コストと品質の両面で先行する。Pilotfishが示したのは、ツールではなく組織設計のテンプレートである。