AIコーディングエージェントを使うとき、最初に考えがちなのは「どのモデルを使うか」です。
精度を上げたいなら高性能モデル。
コストを下げたいなら安価なモデル。
この二択で考えると、AI活用はすぐに詰まります。
高性能モデルを常に使えば、品質は安定しやすい一方でコストが膨らみます。安価なモデルに寄せれば、単純作業では十分でも、設計判断、曖昧な仕様の解釈、最終レビューで失敗しやすくなります。
Cognitionが発表したDevin Fusionは、この問題を「モデルを一つ選ぶ」発想ではなく、「作業の途中でモデルの役割を切り替える」発想で解こうとしています。
ポイントは、安いモデルに置き換えることではありません。
高性能モデルに考えさせる場面と、低コストモデルに任せる場面を分け、さらに作業の途中で切り替えることです。
Devin Fusionは何をしているのか
Devin Fusionは、CognitionがDevin向けに公開したマルチモデル構成です。
公式ブログでは、Devin Fusionを「frontier-level coding intelligenceを保ちながら、sidekick agentsとdynamic routingでコストを下げるhybrid-model harness」と説明しています。
大きな仕組みは次の通りです。
1. 高性能モデルのメインエージェントが全体方針を持つ
2. 低コスト寄りのsidekickエージェントが定型作業を担当する
3. 両者はそれぞれ独自のキャッシュ済みコンテキストを持つ
4. 作業中に軽量な分類器が難易度を見て、担当モデルを切り替える
5. 切り替えはコンテキスト圧縮のタイミングに合わせ、キャッシュ損失を抑える
つまり、Devin Fusionは単純な「高いモデルから安いモデルへの置換」ではありません。
メインエージェントとsidekickエージェントを並行して動かし、計画、判断、レビューは高性能モデルが握り、実装補助、調査、テスト実行、機械的な変更などはsidekickに渡す設計です。
FrontierCodeで示されたのは「安い」より「保つ」こと
Cognitionは、Devin Fusionの評価にFrontierCodeを使っています。
FrontierCodeは、単にコードが動くかだけでなく、実際にマージしたい品質かを見るためのコーディングベンチマークとして紹介されています。Cognitionの説明では、従来のコーディングベンチマークが「正しいコードを書けるか」を示してきた一方で、FrontierCodeは「よいコードを書けるか」を問うものです。
Devin Fusionの公式記事では、GPT-5.5やClaude Opus 4.8のようなfrontier modelと比べ、FrontierCode上で同等水準の性能を保ちながら、コストを35%改善したとしています。
ここで見るべきなのは、35%という数字だけではありません。
重要なのは、コスト削減を「品質を落として安くする」形ではなく、「判断すべき場面に高性能モデルを残す」形で実現している点です。
AIエージェントの現場利用では、単純な正答率よりも、次のような品質が重要になります。
- 仕様の曖昧さを正しく扱えるか
- 既存コードの設計意図を壊さないか
- 変更範囲を広げすぎないか
- テスト失敗の意味を誤解しないか
- 最終的にレビューできるPRになっているか
この品質を残したままコストを下げるには、モデル単価ではなく、作業の分解とルーティングが重要になります。
sidekickは「下請けモデル」ではなく、役割を絞った実行担当
Devin Fusionで面白いのは、sidekickの扱いです。
sidekickは、メインモデルに助言するだけの補助役ではありません。公式記事では、メインエージェントとsidekickエージェントの両方が、ツールセットを持ち、自分でコンテキストを集め、行動できるエージェントとして説明されています。
ただし、役割は同じではありません。
メインエージェントが持つべき仕事:
- 全体の作業計画
- 仕様の曖昧さの解釈
- どの作業を委譲するかの判断
- sidekickの成果物の確認
- 最終レビュー
sidekickに渡しやすい仕事:
- 関連ファイルの調査
- 機械的な置換
- テスト実行
- lintや型チェック
- ログやCI結果の確認
- 影響範囲が限定された修正
この分け方は、開発チームにそのまま応用できます。
AIに全部任せるのではなく、判断と実行を分ける。さらに、実行の中でも「判断が必要な実装」と「機械的に進められる作業」を分ける。
この分解ができていないと、安いモデルを使ってもコストは下がりません。むしろ、手戻り、レビュー負荷、事故調査のコストが増えます。
なぜキャッシュが重要なのか
マルチモデル構成で見落としがちなのが、コンテキストキャッシュです。
AIエージェントは、長い作業の中で大量の情報を読みます。
- 要件
- 既存コード
- テスト結果
- エラーログ
- ユーザーとのやり取り
- 途中で立てた仮説
- すでに試した修正
モデルを切り替えるたびに、この文脈を別モデルへ渡し直すと、コストが跳ねます。しかも、文脈の再構築に失敗すると、作業品質も落ちます。
Devin Fusionが工夫しているのは、メインとsidekickがそれぞれキャッシュ済みの文脈を持つ点です。さらに、モデル切り替えをコンテキスト圧縮のタイミングに合わせることで、もともとキャッシュミスが起きやすい場面を利用し、切り替えの追加負担を抑えています。
これは、AIエージェント基盤を作る側にとってかなり重要です。
「どのモデルを呼ぶか」だけを設計しても不十分です。
実際には、次の設計が必要になります。
| 設計項目 | 考えること |
|---|---|
| コンテキスト保持 | どの情報を、どのエージェントが持つか |
| キャッシュ戦略 | どの単位で再利用できるようにするか |
| 圧縮タイミング | 長い作業をどこで要約・整理するか |
| 切り替え条件 | どの兆候が出たらモデルを上げるか |
| 委譲範囲 | どの作業ならsidekickに渡せるか |
| 最終確認 | 誰が成果物の品質を保証するか |
AIエージェントのコスト最適化は、API単価表を見るだけではできません。
実行中の文脈管理まで含めて設計する必要があります。
動的ルーティングは「最初の分類」だけでは足りない
多くのモデルルーティングは、最初のプロンプトを見て判断します。
簡単そうなら安いモデル。
難しそうなら高性能モデル。
しかし、開発タスクではこれがうまくいかないことがあります。
最初は簡単に見えても、途中で難しくなるからです。
たとえば、最初の依頼がこうだったとします。
検索画面にチーム選択を追加してください。
一見するとUIの小変更に見えます。
しかし、実際には次のような判断が必要になるかもしれません。
- 権限によって見えるチームを変える必要がある
- ReduxやURLパラメータとの整合性が必要
- 既存の検索仕様を壊してはいけない
- feature flag配下でのみ動かす必要がある
- テストが複数レイヤーにまたがる
この場合、最初に「簡単」と分類して安いモデルへ固定すると、途中で破綻します。
Devin Fusionが導入しているdynamic mid-session routingは、この問題への対応です。作業中に軽量な分類器が難易度を見て、メインモデルへ戻したり、sidekickのモデルを上げたりします。
現場で考えるなら、AIエージェントに次のような昇格ルールを持たせるイメージです。
次の条件に当てはまる場合は、高性能モデルまたは人間レビューに戻す。
- 変更ファイルが想定より増えた
- テスト失敗の原因が一意に説明できない
- セキュリティ、課金、個人情報に触れた
- 既存仕様と矛盾する判断が必要になった
- UIだけでなく状態管理やAPI仕様に影響した
- sidekickの修正をメインが理解できない
ルーティングは、最初の振り分けではなく、作業中に何度も見直すものです。
88%の merged PR が示す現実性
Cognitionは、社内利用でFusionを有効にしたユーザー群について、merged PRの88%が自動Fusion routerだけで進められたと述べています。
この数字も、単体で過信するべきではありません。対象タスク、チームの慣れ、Cognition社内の開発環境、Devinとの相性に依存するからです。
ただし、示唆はあります。
マルチモデル運用は、ベンチマーク上のアイデアに留まらず、実際のPR作成フローに入り始めているということです。
つまり、これからのAIコーディング活用では、次の問いが重要になります。
どのモデルが一番強いか
ではなく、
どの作業を、どのタイミングで、どのモデルに渡すか
です。
IT技術者が設計すべき5つの観点
Devin Fusionの話を、自社の開発現場に引き寄せるなら、見るべき観点は5つあります。
1. タスク分類を先に作る
まず、開発タスクをモデル単価ではなく、判断の重さで分けます。
| タスク | 向いている担当 |
|---|---|
| 軽微な文言修正 | 低コストモデル |
| lint、format、単純なテスト修正 | 低コストモデル |
| 影響範囲の調査 | sidekick |
| 機械的な一括置換 | sidekick |
| 設計方針の決定 | 高性能モデル + 人間 |
| セキュリティ判断 | 高性能モデル + 人間レビュー |
| 課金、個人情報、権限変更 | 人間承認必須 |
最初から完璧な分類器を作る必要はありません。
まずは、チームで「これはAIに任せてもよい」「これは人間が見る」を表にするだけで十分です。
2. 委譲できる作業を小さくする
sidekickに渡す作業は、小さいほど安定します。
悪い依頼:
この機能全体を実装してください。
よい依頼:
次の条件で調査だけしてください。
- 関連しそうなファイルを列挙する
- 変更候補を3つ以内に絞る
- まだ編集しない
- 判断が必要な点を最後に分けて書く
AIに実装を任せる前に、調査、候補整理、テスト実行、機械的修正へ分けます。
これだけで、高性能モデルが全作業を抱え込む必要が減ります。
3. 昇格ルールを明文化する
安いモデルに任せるなら、戻す条件も必要です。
たとえば、次のようなルールです。
AI作業の昇格ルール:
- 変更対象が5ファイルを超えたら設計レビューへ戻す
- DBスキーマ変更が出たら人間承認へ戻す
- 認証・認可に触れたら高性能モデルで再レビューする
- テスト失敗が2回続いたら原因分析を切り替える
- 仕様にない判断を始めたら作業を止める
大事なのは、安いモデルを使うことではありません。
安いモデルから戻れることです。
4. レビュー責任をモデルに渡さない
Devin Fusionでも、メインエージェントは計画、曖昧さの解釈、最終レビューを担います。
開発組織で使うなら、さらに人間レビューの位置づけを明確にする必要があります。
特に次の領域は、AIの出力をそのまま通さない方がよいです。
- 権限設計
- 個人情報の扱い
- 監査ログ
- 課金処理
- データ削除
- 外部API連携
- 障害時の復旧手順
AIエージェントの導入で必要なのは、レビューをなくすことではありません。
レビューすべき場所を濃くすることです。
5. コスト指標を「1回の呼び出し」ではなく「1PR」で見る
モデル費用を比較するとき、1リクエストあたりの単価だけを見ると判断を誤ります。
開発現場では、次の単位で見るべきです。
- 1つのPRを作るまでの総コスト
- レビューで戻った回数
- CI失敗の調査時間
- 人間が修正した行数
- マージ後の不具合率
- 仕様確認に戻った回数
安いモデルを使っても、レビューで何度も戻れば高くつきます。
高性能モデルを使っても、必要な場面だけなら総コストは下がるかもしれません。
見るべきなのは、モデル単価ではなく、開発フロー全体のコストです。
導入前に使えるチェックリスト
自社でDevin Fusion的な考え方を取り入れるなら、いきなり高度なルーターを作る必要はありません。
まずは、次のチェックリストで十分です。
AIエージェント運用チェックリスト
[ ] タスクを「判断」「調査」「実装」「検証」に分けている
[ ] 低コストモデルに任せてよい作業を定義している
[ ] 高性能モデルへ戻す条件を定義している
[ ] 人間承認が必要な領域を明文化している
[ ] AIが読んだ情報と判断根拠を残している
[ ] PR単位でコストと手戻りを見ている
[ ] CI失敗時の対応方針を決めている
[ ] 最終レビューの責任者を決めている
このチェックリストを作るだけでも、AI活用は「便利ツールの試用」から「開発プロセスの設計」に変わります。
これから重要になるのはモデル運用エンジニアリング
Devin Fusionの本質は、特定のモデル名ではありません。
Fable 5、GPT-5.5、Opus 4.8といった名前は今後も変わります。価格も、性能も、利用条件も変わります。
しかし、次の設計課題は残ります。
- どの作業を高性能モデルに任せるか
- どの作業を低コストモデルに渡すか
- いつ切り替えるか
- どの文脈を保持するか
- どこで人間が止めるか
- 何をもって「品質を保った」と判断するか
AIコーディングエージェントの活用は、モデル選定の話から、モデル運用設計の話へ移っています。
これからのIT技術者に必要なのは、「一番強いモデルを知っていること」だけではありません。
開発タスクを分解し、判断と実行を分け、コストと品質のバランスを設計できることです。
Devin Fusionは、その方向をかなり分かりやすく示しています。
AIにコードを書かせる時代の次は、AIエージェントの働かせ方を設計する時代です。
作成日: 2026-07-02