2026-09-22 発行（読了 6 分）
実プロダクトのアーキテクチャ・使用例から AI 開発の現在地を週 3 回・1 号 1 テーマで深掘り
2026年に入り、複数のAIコーディングツールが『どのモデルを使うか』をユーザーの選択から切り離した。GitHub Copilotは9月にコスト/品質の3段階ティアを追加し、Cursorは60万件超の実利用データで学習した分類器にモデル選定を任せるCursor Routerを投入した。背景にあるのは、開発者の多くが単一モデルを固定して使い続け、単純な作業まで最上位モデルの価格で処理しているという非効率だ。ただし『どの基準で振り分けるか』の設計は各社で割れており、満足度を学習する方式と、品質差分の許容範囲を管理者が数値で設定する方式が併存している。
従来、開発者はチャットUIやCLIでモデルを1つ選び、単純な補完にも複雑なバグ診断にも同じモデルを使い続けてきた。GitHub CopilotとCursorはこの前提を崩し、リクエストごとにタスクの複雑さを評価してモデルを割り当てる層を標準機能として組み込んだ。
転換の理由は非対称なコスト構造にある。単純なファイル検索や定型的な補完に最上位モデルを使っても品質は大差なく、コストと待ち時間だけが増える。逆に複雑なバグ診断を安価なモデルに回すと品質が落ちる。この非対称性を人間が都度判断するのは非効率なため、判定自体をモデル選択の外側、つまりシステム側に出す設計へ収束した。
モデルを振り分ける基準の作り方には、少なくとも2つの流儀がある。Cursor Routerはユーザーの実利用ログから『どちらのモデルの出力が好まれたか』を学習し、満足度を目的関数にする。一方Amazon Bedrock Intelligent Prompt Routingは、同一モデルファミリー内の2モデル間で許容する『応答品質の差』をパーセンテージで管理者が指定し、その閾値内なら安いモデルへ倒す。
この違いはプロダクトの立ち位置を反映している。開発者向けエージェントは出力の『体感の良さ』が離脱に直結するため主観指標を最適化する。一方クラウド基盤は多数のテナントが多様な用途で使うため、管理者が数値で制御できるノブを用意する方が運用しやすい。同じ『安いモデルに倒す』という結論でも、判定基準の設計は製品が誰向けかで変わる。
モデル振り分けは1リクエスト単体の損得では決まらない。プロンプトキャッシュはモデルごとに管理されており、会話の途中でモデルを切り替えるとそれまで蓄積したキャッシュ済みプレフィックスが失効し、次のリクエストは丸ごとキャッシュミスとして課金される。安いモデルへの切り替えで得るはずのコスト削減が、キャッシュ再構築のコストで相殺される場合がある。
GitHub CopilotとNot Diamond Codeは、この『切り替えの得失』をルーティング判断そのものに組み込んでいる。単発のリクエストではなく、セッション全体でのコストを最小化する設計に踏み込んでいる点で、リクエストごとに最安モデルを選ぶだけの初期の実装とは一段階違う。