7月23日、MarkTechPostが「You Didn't Get the AI Model You Paid For」と題した記事を公開した。この記事では、AIモデルのルーティングによってAPIリクエストが指定外のモデルで処理される問題と、それが契約・証拠法上に持つ法的含意について詳しく論じられている。

「指定したモデル」が実際には動いていない

model: "claude-fable-5" を指定してAPIを呼び出す。レスポンスが返ってくる。エラーはない。しかしレスポンスオブジェクトの "model" フィールドには "claude-opus-4-8" と書いてある。

これはAnthropicが2025年7月1日にFable 5の提供を開始した際に公式に文書化した挙動だ。ブロックされたリクエストはOpus 4.8へ転送され、レスポンスには実際に動いたモデル名が返る。著者によればこれは「レスポンス内でその事実を伝える唯一の実装」でもある。

その2週間後、Cursorは「Router」を出荷した。60万件以上のライブリクエストで訓練されたクラシファイアで、クエリのコンテキスト・複雑さ・ドメインを読んで最適なモデルへ振り分ける。早期アクセスの3アカウントではOpus 4.8へ全件ルーティングする場合と比べ30〜50%のコスト削減が報告されている。ルーティングルールは公開されているが、タスクタイプごとに具体的にどのモデルが使われるかは明示されていない。

さらにその下のアグリゲーション層では、OpenRouterが「一部プロバイダーは低価格の量子化（quantized）ウェイトを提供しており、出力はフルプレシジョンと異なる場合がある、しかしログにはその旨が記録されない」と警告している。

3つのプロダクト、3つの異なる「モデル」の定義。そしていずれも、法的にどれが有効かは未解決のままだ。

モデルの「名前」が壊れる3つの経路

記事は、モデルのアイデンティティが崩壊するパターンを3つに整理している。

• 代替（Substitution） ── 別アーキテクチャ・別ウェイトのモデルへクラシファイアが振り分ける。Fable 5 → Opus 4.8、あるいはCursor AutoがそのターンのルーターPick先へ。
• 劣化（Degradation） ── 同じモデル名で、量子化された精度の低いウェイトが提供される。OpenRouterはデフォルトで価格順に負荷分散するため、ユーザーは気づかないまま精度の落ちた推論を受け取る。
• ドリフト（Drift） ── 同じ名前が、サイレントにアップデートされたウェイトを指す。-latest エイリアスをプロダクションで使うことは、パッケージマニフェストでは絶対に許容しないはずの「バージョン非固定の依存関係」を使うことと同義だ。

エンジニアコミュニティはこれらを信頼性の問題として扱いがちだが、著者はこれらがアイデンティティ（同一性）の問題でもあると指摘する。契約・保証・開示・証拠規則はすべてアイデンティティを前提に構築されているからだ。

「何を買ったのか」という契約法上の問題

英米商法の古典的な問い：「その記述は取引の条件だったか？」

APIコールを物品の売買と見なせば話は単純だ。米国UCC（統一商事法典）§2-313(1)(b)では、取引の基礎を形成する商品の記述は明示的保証となる。しかし推論APIはほぼ確実に「物品」ではなくサービスとして扱われるため、保証法規ではなく通常のコモンロー契約に落ちる。そこでは「何を約束したか」が全てを決める。

問題の核心はここにある。エンタープライズ契約はモデルごとの価格体系で設計され、コンプライアンス文書にはモデルバージョンが明記される。しかしルーティング層はその名前を「ヒント」として扱う。

モデルIDをコードにピン留めしても、ルーターの判断次第で実際の挙動は変わる。エラーは発生しない。契約を同じように書けば、同じ欠陥を抱えることになる。

Cursorのアプローチは象徴的だ。RouterはユーザーSatisfactionを報酬シグナルとしたオンラインA/Bテストで評価されている。エンジニアリング的には合理的な選択だが、契約的には奇妙だ。「満足した」ことは「仕様通りのものを受け取った」ことを意味しない。

最大の論点：証拠としての認証問題

著者が「本当の戦いはここだ」と指摘するのが、電子証拠の認証（authentication）の問題だ。

米国連邦証拠規則（FRE）901(b)(9)は、電子システムの出力を認証するために「そのシステムを特定し、正確な結果を生成することを示す」ことを求める。インドの2023年Bharatiya Sakshya Adhiniyam §63も同様に、電子記録の証拠能力は「どのシステムがどのように生成したか」の証明に依存する。

これらの規定はすべて「システムを特定できること」を前提にしている。

次のシナリオを考えてほしい。弁護士が架空の引用を含む準備書面を提出し、制裁手続きが始まる。裁判所が「どのモデルが生成したか」を問う。事務所のログには fable-5 とある。プロバイダーのログには「クラシファイアが起動しOpus 4.8が回答した」とある。あるいはIDEのルーターが選んだモデルは再現不可能で、すでにリタイアしたバージョンだった。

カストディチェーン（証拠の管理連鎖）はモデルではなく、ルーターで切れる。 自分の出力を認証しようとする側も、相手の出力の信頼性を攻撃しようとする側も、ルーター層で詰む。

解決策は「条項」ではなく「署名」

著者の結論は明快だ。

ルーティングは優れたエンジニアリングだ。しかし現時点では、あなたが契約した対象の、ログもなく、署名もなく、検証もできない代替物でもある。

契約の文言でこの問題を解決することはできない。必要なのはattestable model identity（証明可能なモデル同一性）だ。具体的には、各レスポンスに対して：

• 提供されたモデルの識別子
• ウェイトのハッシュ
• 精度（precision）
• システムプロンプトのハッシュ

をハードウェアアテステーションに根ざした鍵で署名したattestationを返す仕組みが必要だということだ。ハードウェアアテステーションとは、GPUやCPUなどのハードウェアが「自分が正規のプラットフォームであること」を暗号学的に証明する仕組みで、コンフィデンシャルコンピューティングと呼ばれる技術領域がその基盤を提供している。IntelのTDXやNVIDIAのHopper世代GPUがすでにこの用途に対応しており、プリミティブとしては半分完成している状態だ。

レスポンスオブジェクトはすでにモデル名を返す。欠けているのは「偽って申告できない」「買い手が売り手を信頼せずに検証できる」という性質だ。FRE 902(14)がコピーデータのハッシュ認証に対してやることと同じことを、モデルのアイデンティティに対して行うイメージだ。

モデルIDはいつの間にか法的識別子になった。それが何を識別するのかを、誰かが決める時期に来ている。

詳細はYou Didn't Get the AI Model You Paid Forを参照していただきたい。