Anthropic、請求モデルと異なるモデルを出力

レスポンスオブジェクト内の行

API を呼び出します。パラメータに model: "claude-fable-5" を指定すると、完了結果とトークン数に加え、「model": "claude-opus-4-8」というフィールドが返されます。

エラーもリトライも発生していません。生成が始まる前にリクエストは分類され、特定の機密カテゴリに該当したため、全く異なる重みセットを持つ別のモデルへ振り分けられました。Anthropic は 7 月 1 日に Fable 5 を再公開する際にこの仕組みを文書化しています。ブロックされたリクエストは Opus 4.8 に転送され、ユーザーにはその旨が通知されます。この切り替えは API レベルで行われ、レスポンスオブジェクトには実際に実行されたモデル名が記載されています。

これは「礼儀正しい」バージョンです。私が把握する限り、インバンド（通信経路内）で真実を伝える広範な展開が行われている唯一のケースでもあります。

それから 2 週間後、Cursor は Router をリリースしました。60 万回以上のライブリクエストから学習した分類器で、各クエリの文脈・複雑さ・ドメインを読み取り、最も適していると判断されたモデルへ振り分けます。早期アクセスユーザー 3 名によると、すべてのリクエストを Opus 4.8 にルーティングした場合と比較して 30〜50% のコスト削減が実現しました。Cursor はルーリングルールを公開しましたが、タスクタイプごとの特定モデル名までは明記していません。

さらにその下層にある集約レイヤーでは、OpenRouter が警告を発しています。一部のプロバイダーは低価格で量子化された重みを提供しており、フル精度の重みから得られる出力とは異なる結果になる可能性があること、またログにはこの事実が記録されないことを注意喚起しています。

3 つのプロダクト。3 つの異なる回答。「モデルとは何か」という問いに対して。法廷でどの答えが認められるかを示す事例は、まだ一つもありません。

名前が意味を失う3つのパターン

モデルの正体は、通常区別されない3 つの独立した軸に沿って分断されつつあります。

1. 置換（Substitution）

アーキテクチャも重みも能力プロファイルも異なる別のモデルが、分類器によって差し替えられます。例：Fable 5 が Opus 4.8 に置き換えられたり、Cursor Auto で「今回のラウンドでルーターが選んだもの」に変わったりします。

1. 劣化（Degradation）

同じモデルでも、精度を落として提供されるケースです。OpenRouter が「quantizations パラメータ」を公開しているのは、量子化されたエンドポイントでは特定のプロンプトで性能が低下する可能性があるためであり、デフォルトではリクエストは価格順に並べられたプロバイダ間で負荷分散されます。リクエストには同じ名前が使われていても、裏側で計算される演算は異なります。

1. 漂移（Drift）

同じ名前を指していても、重みが静かに更新され続ける現象です。本番環境にある「-latest」エイリアスは、パッケージマニフェストでは決して許容しないバージョン管理されていない依存関係と同じです。

エンジニアリング界隈はこれら3 つをすべて信頼性の問題として扱います。しかし同時に、これらは正体（アイデンティティ）の問題でもあります。契約、保証、開示、証拠規則といったものは、まさにこの「正体」の上に成り立っているのです。

では、実際にあなたが購入したのは何だったのでしょうか？

まずは商業法で最も古い問いから始めましょう。「その説明は取引の条件の一部であったか？」という問題です。

API 呼び出しが商品の売買とみなされるなら、これはほぼ自明のことになります。米国の統一商法典（UCC）§2-313(1)(b) は、取引の基礎をなす商品に関するあらゆる記述を、「その商品が記述に適合する」という明示的な保証として扱います。同様に、インドの 1930 年売買取引法 §15 も、「説明による売買」の法理を通じて同じ機能を果たしています。

しかし、推論 API が「商品」として扱われることはほぼありません。裁判所は通常、ホスト型ソフトウェアを「サービス」とみなし、これにより製品責任法（warranty statutes）の適用外となり、判例法に基づく契約法の枠組みへと移行します。この場合の判断基準は、ドキュメントに何と記載されていたか、そして購入者が具体的にどのような条件で交渉したかに完全に依存します。まさにここに曖昧さが存在しています。

エンタープライズ契約ではモデルごとに価格が設定され、モデルカードは特定のモデルを対象とし、コンプライアンス文書にはモデルのバージョン名が明記されます。しかし、ルーティング層においては、その名前が単なるヒントとして扱われるに過ぎません。

この問題の本質を最も明確に示すのは、コードが「機能要件」ではなく「モデル ID」を固定している場合です。その場合、エラーが一切発生しなくても、動作が劇的に変化してしまう可能性があります。同じ構造で書かれた契約にも同様の欠陥が存在します。「名前」を交渉の条件としたのであれば、置き換えは契約違反となります。一方、「機能」を条件としたのであれば、置き換えは許容されます。ただしその場合、「フロンティア・クオリティ（最上位品質）」という概念が、厳密な検証に耐えうる定義として存在している必要があります。

しかし、そのような定義を記した文書はまだ誰も作成していません。Cursor の事例が示唆に富んでいます。同社の Router は、ユーザー満足度を報酬信号とするオンライン A/B テストで評価されました。これはエンジニアリング上の妥当な選択ですが、契約論としては奇妙です。「満足」は「仕様への適合」とは異なります。交換に気づかなかったユーザーがいることは、ルーティングが優れていた証拠にはなりますが、仕様が確実に履行された証拠にはなりません。

開示のグラデーション

連邦取引委員会（FTC）の欺瞞禁止規定では、消費者が合理的に行動した場合に誤解を招く可能性が高く、かつ重要な表示であれば、その表現は法的措置の対象となります。特に客観的な性能に関する主張には、公表前に合理的な根拠が必要とされます。今回のケースでは、この二つの要件の両方が当てはまります。

ルートの仕組みについて見ると、3 つの製品はそれぞれ全く異なる位置づけにあります。Anthropic はリクエストに応じたモデルを通知し、レスポンスにその情報を返します。Cursor はルールを公開していますが、タスクごとのモデル割り当てについては明言していません。OpenRouter の場合、量子化の違いはドキュメントで開示されておりパラメータで制御可能ですが、これはオプトアウト方式です。つまり、デフォルトでは最も安価な経路が選ばれます。

ドキュメントの奥深くに隠された開示や、ユーザーにとって不利なデフォルト設定は、他の消費者向け業界において規制当局が「ダークパターン」として問題視してきた典型的な事例そのものです。

根拠の提示について言えば、問題となるのはルートではなく、主張そのものの暴露です。すでに多くの評論家が指摘している通り、「60% 安価で品質低下なし」という主張には、公開された検証方法がありません。一方、Anthropic の開示は「誠実さのコスト」を象徴するものです。同社は明確に、「再訓練された分類器は、通常のコーディングやデバッグの場面では、悪意のないリクエストをより頻繁に検出する」と述べています。この一文こそが、法的責任から身を守るための盾です。逆に、こうした記述を行わないベンダーこそが、今後注視すべき対象となります。

この問題には競争法上の側面も存在します。推論市場における垂直的排除に関する研究論文では、すでにルーティングの透明性、サービス品質の同等性、FRAND 方式に基づく差別的扱いの禁止を柱とした行動指針の枠組みが提案されています。自社モデルベンダーでもあるルーターは、コスト最適化という名目を着た、自社の優遇を行うエンジンにほかなりません。

誰も注目していない部分：認証の問題

こここそが、真の争点が収束する場所です。これは請求書や料金体系とは何の関係もありません。連邦証拠規則 901(b)(9) では、出力を生成したプロセスまたはシステムを説明し、そのプロセスが正確な結果を生み出すことを示すことで、出力の真正性を認めています。また、902(13) と 902(14) はさらに踏み込み、電子システムによって生成された記録や、ハッシュ値で検証されたデータについて、証明書の提出だけで自立的に真正性が認められる道を開いています。インドの 2023 年法「バーラティヤ・サクシャ・アディニヤム」第 63 条も同様の役割を果たしており、電子記録の証拠能力を、その記録の特定と生成方法を明記した証明書に付託しています。

これらすべての規定は、「どのシステムが関与したか」を明確に名指しできることを前提としています。

ここで一つのシナリオを考えてみましょう。弁護士が虚偽の引用を含む簡易書面を提出し、制裁手続きが始まります。裁判所は「これはどのモデルが生成したものか」と問います。ファーム側のログには「fable-5」と記載されています。一方、プロバイダー側のログでは、「分類器が作動し、Opus 4.8 が回答した」と記録されています。あるいは、リクエストが IDE のルーターを経由し、ファーム側が再構築できないモデルが選択され、精度も指定されておらず、すでに廃止されたバージョンが使用されていた可能性もあります。

責任の所在は、モデルやディスパッチャーではなく、ルーターで断絶します。この断絶は双方向に起こります。自らの出力を検証しようとする側は検証できず、他方の出力を攻撃しようとする側は、専門家でも反論できない独立した信頼性の主張を持つことになります。

さらに発見手続の問題も加わります。ルーティングの判断が決定的事実となるため、ベンダーからルーター分類器のログやリクエストごとのモデル割当、精密なメタデータを入手可能になります。しかし現在、ベンダーにはこれらの情報を保持する義務がありません。

解決策は条項ではなく署名です

この問題を契約条文で回避することはできません。必要となるのは実行時の事象に関する保証ですが、契約文書は静的なものだからです。

法が最終的に求めるのは、検証可能なモデルの身元です。各レスポンスに添付される署名付き主張であり、提供されたモデル識別子、重みハッシュ、精度、システムプロンプトハッシュというタプルを、ハードウェアアテステーションに根ざした鍵で署名して完了文書と結びつけます。すでに機密計算 GPU プラットフォームはこれをサポートしています。

この仕組みの基礎部分は半ば完成されています。レスポンスオブジェクトには既に提供されたモデル名が含まれています。欠けているのは、法的に有用にする性質です。つまり、虚偽の主張ができないこと、そして購入者が売り手を信頼しなくても検証できることです。レスポンスヘッダー内のハッシュは、コピーデータに対して FRE 902(14) が果たしているのと同じ役割をモデル身元に対して果たします。争点となる事実質問を証明書へと変えるのです。

ルーティングは優れたエンジニアリングの手法です。しかし現在、それはあなたが契約したモデルを、ログも署名もなく、検証不能な形で置き換える行為となっています。

モデル ID は静かに「法的な識別子」としての役割を果たし始めています。今こそ、それが何を指し示すのかを明確に決める時が来たのです。

出典：

• Cursor, "Introducing Cursor Router" (2026 年 7 月 22 日) — cursor.com/blog/router
• MarkTechPost, "Cursor Releases Cursor Router: A Request-Level Classifier Delivering Frontier Coding Quality at 30–50% Lower Cost" (2026 年 7 月 22 日) — marktechpost.com
• Anthropic, "Redeploying Claude Fable 5" (2026 年 6 月 30 日) — anthropic.com/news/redeploying-fable-5
• Espressio, "Claude Fable 5 Safeguards: The Opus 4.8 Fallback Explained" (2026 年 6 月 22 日) — espressio.ai
• Digital Applied, "Why Claude Just Got More Cautious About Your Code" (2026 年) — digitalapplied.com
• OpenRouter, "Provider Routing — Provider Selection" (ドキュメント) — openrouter.ai/docs
• OpenRouter, "Lowest-Cost LLM Inference: The Complete OpenRouter Guide" (2026 年 6 月 12 日) — openrouter.ai/blog
• OpenRouter, "How OpenRouter Model Routing Works" (2026 年 6 月 12 日) — openrouter.ai/blog

本記事「あなたが支払った AI モデルは手元に来なかった」は、もともと MarkTechPost で公開されたものです。