最近、AIモデルの使い方が大きく変わりつつある。「いちばん賢い高価なモデル1つで全部やる」のではなく、「タスクごとに安いモデルや専用ツールを切り替えて、必要なときだけ高いモデルを使う」という方向だ。
実際、2026年6月30日には Anthropic と Cognition（AIコーディングエージェント「Devin」の開発元）が、ほぼ同時にこの方向の新しい仕組みを発表した。狙いは同じ——フロンティアモデル（最先端の高価なモデル）1枚で殴るのをやめて、賢い「計画役」と安い「実行役」に分けることだ。
ただ、ここで終わると話の半分しか見えない。本当に難しいのは「分ける」ことではなく、「自動で・賢く・キャッシュを壊さずに分ける」ことだ。この記事では、その課題を順番に整理していく。
ベンチマークでは成立する。実運用は別物
「安いモデル ＋ 適切な Skill（その分野用の手順書・専門知識）」という組み合わせは、ベンチマーク（性能テスト）ではちゃんと成立する。小さいモデルでも、正しいモデルを選んで正しい Skill を渡せば、かなりの性能が出る。ここは事実だ。
問題はその先。実運用では、次のことをすべて自動でやらないといけない。
-
どのモデルを使うかの自動判定
-
どの Skill を当てるかの自動判定
-
失敗したら上位モデルへエスカレーション（格上げ）
-
コスト・速度・品質のバランス最適化
ここが自動化できないと、結局「人間が手動で切り替えた方が速いよね」で終わってしまう。 つまり価値があるのは、モデルそのものよりも、それを采配する仕組みの方だ、という話になる。
いちばん熱い戦場は「Router（振り分け役）」
ここ数年でいちばん競争が激しくなるのは、おそらく**Model Router（モデルの振り分け）＋ Skill Router（スキルの振り分け）**だ。
イメージは病院のトリアージ（受付での重症度判定）に近い。
-
軽い症状 → 研修医（激安モデル）
-
手に負えない → 先輩医師（中堅モデル）
-
それでもダメ → 専門医・院長（高価なフロンティアモデル）
入力
│
▼
[分類器] ← まず「種類」と「難しさ」を判定
│
├─ 軽い ──→ Qwen 3B（激安）──成功──→ 完了
│ └─ 失敗 ─┐
├─ 中くらい ─→ Kimi K2 ←────────┘
│ └─ 失敗 ─┐
└─ 重い ───→ Claude Opus ←───────┘ ← 最後の砦（高い）
同時に、タスクの種類に応じて使う「専門知識（Skill）」も切り替える。
コード生成 → Coding Skill
要約 → Summary Skill
契約書 → Legal Skill
この振り分けを人間の介入なしに自動でできる会社が強い。 そして今回発表された2つの仕組みは、まさにこの Router の実装例だ。
同じ週に、2社が「逆向きの答え」を出した
Anthropic：安い方が本流、賢い方は相談役
Anthropic は「アドバイザー戦略」を出した。賢いモデルを 相談役（アドバイザー）、安いモデルを 実行役（エグゼキューター） に分ける。面白いのは、会話の本流を握って文章を書くのは安い実行役で、賢いモデルは要所だけ口を出す点だ。たとえば、いちばん難しいタスクは Fable 5（相談役）＋ Opus 4.8（実行役）という組み合わせになる。
Cognition（Devin Fusion）：賢い方が本流、安い方は助手
Cognition の「Devin Fusion」は逆だ。**賢いフロンティアモデルが本体（メイン）**として計画と最終判断を握り、安いモデルを サイドキック（助手） として下働きに回す。並列で動かし、必要なら助手から本体へ処理を引き戻す。彼らは「従来のモデルルーティングはクソだ。ベンチマークは通るが、実際にマージしたいコードは書けない」と言い切った。結果は——コスト35%減（Fable 5 使用時は41%減）、社内テストでマージされた PR が88%。
ひねり：「ペンを握るのは賢い方か、安い方か」が正反対
Cognition の「ルーティングはクソ」発言は、安い実行役に最終生成を任せると品質が頭打ちになるという、アドバイザー型への暗黙の批判でもある。
ただし共通点が1つある。どちらも「1つの会話の中でモデルを毎ターン切り替えてはいない」。並列の別トラックを走らせ、タスクの区切りで成果を受け渡すだけだ。——これが、次の最大の課題に効いてくる。
最大の壁 ——「モデルを切り替えるとキャッシュが効かない」
ここが今日いちばん伝えたい課題だ。Prompt Cache（プロンプトキャッシュ：同じ前置きを毎回使い回して計算を省く仕組み）は、コスト削減の主役だ。一度温まったキャッシュは、通常の入力の10分の1以下の値段で読める。
ところがこのキャッシュは、
-
モデル
-
tokenizer（文章をモデル用の最小単位＝トークンに刻む変換器）
-
System Prompt（モデルへの土台となる指示）
が一致していることが前提になっている。つまりモデルを切り替えた瞬間、キャッシュは基本的に作り直しだ。Claude Sonnet で貯めたキャッシュは Claude Opus では使えない。ましてや Qwen → Claude のように別ベンダーへ飛べば、完全に別世界になる。
ここで Router の理想と現実がぶつかる。「最安モデルを毎ターン選ぶ」素朴な Router は、切り替えるたびにキャッシュを捨てるので、安いモデルで浮くはずの差額をキャッシュの作り直し代が食い潰す。
しかもこの破綻は、2つの顔で出てくる。
-コストの顔：キャッシュが死んで料金が膨らむ
-品質の顔：安いモデルに最終生成を任せて品質が落ちる（＝ Cognition の「マージできない」）
根っこは同じで、「どのモデルか」を1トークン・1ターンごとの細かい判断として扱っていることにある。だから2社とも、切り替えをタスクの境界に追い出し、各モデルに自分専用のキャッシュを温めさせているのだ。
解き方 —— キャッシュを2層に分ける（Knowledge Cache）
ではどうするか。最近の答えは「キャッシュを2層に分ける」だ。
┌─────────────────────────────────────────┐
│ 共通キャッシュ（モデル非依存） │ ← 高価な処理。
│ ・RAG の検索結果 │ 一度やれば
│ ・ツール実行結果（外部API / DB） │ どのモデルでも
│ ・Embedding 検索の結果 │ 使い回せる
├─────────────────────────────────────────┤
│ モデル別キャッシュ（Prompt Cache） │ ← モデルを変えると
│ ・System Prompt │ 作り直し。
│ ・会話履歴 │ でも中身は軽い
└─────────────────────────────────────────┘
↓ ↓ ↓
Qwen Claude Gemini ← どれに切り替えてもOK
ポイントは、高価な処理ほどモデルに依存しない形で共通キャッシュに置くことだ。
-
RAG（関連文書を検索して引っ張ってくる処理）の検索結果
-
ツール実行の結果（外部 API・データベースアクセス）
-
Embedding（文章を数値ベクトルにして類似検索する処理）の結果
これらは「どのモデルに渡すか」とは無関係に決まる。だから**モデル非依存の共通キャッシュ（Knowledge Cache）**に貯めておけば、Qwen でも Claude でも Gemini でも使い回せる。
一方、モデルに依存する部分——最終的な System Prompt と会話履歴——だけを、各モデル向けに組み立て直す。ここは中身が軽いので、作り直しても痛くない。
こうすると、モデルを切り替えても、いちばん高価な「検索・DBアクセス・埋め込み計算」はやり直さずに済む。Router の理想（賢く切り替える）と、キャッシュの現実（切り替えると死ぬ）を両立させる設計だ。
差別化は「モデル」から「ランタイム」へ
ここまで来ると見えてくるのは、競争の軸がモデル単体の賢さから、その周りのレイヤーへ移っていることだ。
-Agent（自律的に動く実行体）
-Router（モデル・Skill の振り分け）
-Memory（記憶）
-Cache（2層キャッシュ）
-Tool（外部ツール連携）
Anthropic も OpenAI も Cognition も、結局この方向に進んでいる。**「いちばん賢いモデルを持っているか」より、「適切なモデル・適切な Skill・適切な Tool を、適切な瞬間に選べるか」**が差別化点になりつつある。
GraphAI（モデルやツールをグラフでつないでオーケストレーションするフレームワーク）の文脈で言えば、これはまさに anyInput（複数入力をまとめる）・if（条件分岐）・repeatUntil（成功するまで繰り返す＝エスカレーション）・tool・router を組み合わせて、モデルの采配ロジックを宣言的に書く、という話だ。
今後は「LLM そのもの」よりも、「安価なモデル群を賢く使い分けるランタイム」の価値が大きくなっていく可能性が高い。ただし繰り返しになるが、モデルを頻繁に切り替えるとプロンプトキャッシュは効きにくくなる。だからRAG 結果・ツール結果・中間データをモデル非依存でキャッシュし、最終プロンプトだけ各モデル向けに組み立てる——この設計ができるかどうかが、ランタイム勝負の分かれ目になる。
まとめ —— 本当の課題リスト
-
安いモデル ＋ Skill はベンチマークでは成立する。が、自動制御がないと実運用では「手動でいい」に負ける。
-
いちばん熱いのはModel Router ＋ Skill Router。失敗時のエスカレーションまで自動でやれるかが鍵。
-
素朴なルーティングは2つの顔で破綻する——キャッシュが死んでコスト増／安いモデルに任せて品質減。
-
だから切り替えは「毎ターン」ではなく「タスク境界」で。各モデルに自分のキャッシュを温めさせる。
-
最大の障壁＝キャッシュは、2層化（共通の Knowledge Cache ＋ モデル別 Prompt Cache）で乗り越える。
-
競争軸はモデル単体からランタイム（Agent / Router / Memory / Cache / Tool）へ移っていく。
ひとことで言えば——勝負どころは「いちばん賢いモデル」ではなく、「安いモデル群を、キャッシュを壊さずに賢く采配するランタイム」になる。