AIコーディングのモデル切替に強い設計術

モデルは「いつか死ぬ」という前提で設計する

Claude Code や Codex で開発していると、使い慣れたモデルがある日突然非推奨になる。これは事故ではなく仕様だ。GitHub Copilotでは2026年7月24日にClaude Opus 5が追加され、複雑で長時間にわたるコーディング作業向けに投入されたClaude Opus 5 is now available in GitHub Copilot。同じ月の31日には、Gemini 2.5 ProとGemini 3 Flashが非推奨化されたGemini 2.5 Pro and Gemini 3 Flash deprecated。

わずか一週間で、追加と廃止が同時進行する。特定モデルにワークフローを固定するリスクは、こうした速度で現実化する。

Copilotのモデル交代とManifestのルーター撤退、二つの事例が示す構図

Copilotの非推奨化には代替モデルが用意されている。Gemini 2.5 ProはGemini 3.1 Pro（Preview）へ、Gemini 3 FlashはGemini 3.6 Flashへ移行する設計だ。Enterpriseの管理者は、モデルポリシーで代替モデルへのアクセスを有効にする必要が生じる場合があるが、非推奨モデル自体を削除する操作は不要とされている。

一方でManifestは、タスクの複雑度をsimple、standard、complex、reasoningの4段階に自動分類し、最適なモデルへ振り分けるLLMルーターを3月に開始した。7000人のクラウドユーザーに使われたが、6月に非推奨化、9月1日に完全停止しているEveryone is building LLM routers, we deprecated ours。理由は明快だ。タスクの複雑度を決める情報の多くは、ツール呼び出しやウェブ検索を経て、プロンプト送信後に判明する。事前分類は原理的に外れやすい。

Copilotは「モデルを追加・削除する側」、Manifestは「モデルを自動選択する仕組み自体をやめた側」。方向は逆だが、両者とも示しているのは同じことだ。モデル選定を自動化やベンダー任せにするほど、変化に振り回される面積が広がる。

タスク別モデル選定とフォールバック設計の実践

Manifestが行き着いた結論は、各エンジニアが意図に応じて使用モデルと推論努力パラメーターを自分で選ぶという運用だ。自動ルーティングをやめ、判断を人間に戻した。

個人開発でも応用できる。設計フェーズやアーキテクチャ検討には、複雑で長時間のエージェント型コーディングに強いモデル（例えばClaude Opus 5のような上位モデル）を明示的に指定する。単純なリファクタリングや定型的なコード生成には、軽量・高速なモデルを割り当てる。用途とモデルを固定で紐づけておくのが出発点になる。

フォールバック設計で意識すべきはコストだ。システムプロンプトや会話履歴は多くのトークンを占めるが、プロンプト先頭に置けばプレフィックスキャッシュが効きやすい。キャッシュ読み取りはキャッシュされていない入力より75〜90%安価になる。モデルを切り替える際も、この構造を崩さない設計にしておけば、切替コストを抑えられる。

導入すべき人、まだ様子見でいい人

タスク別モデル選定を今すぐ設計すべきなのは、Claude CodeやCodexを日常的に使い、設計・実装・レビューといったフェーズごとに要求品質が変わるチームだ。特に非推奨化の通知を受けて慌てた経験がある人は、モデル固定の危うさを既に体感している。

逆に、単一モデルの単発利用が中心で、切替の必要性を感じていないなら、自動ルーターのような仕組みを今から構築する優先度は低い。Manifestの4カ月の運用実績が示す通り、複雑度分類の自動化は「混在した結果」に終わりやすい。まず自分の手でモデルを選び分ける運用に慣れてから、自動化の要否を考えても遅くない。

まとめ

モデルは追加され、非推奨化され、いつか消える。Copilotの事例もManifestの事例も、その前提を裏付けている。特定モデルへの依存を避け、タスクごとに使うモデルを自分で決め、切替時にキャッシュ構造を崩さない設計を先に組んでおく。それが、次の非推奨通知が来たときに慌てない唯一の準備だ。