Claude Fable 5の"Kettle"リーク：署名付き思考に隠された内部モデルID — これまでに判明していること

8月16日午後11時29分45秒PDTに、X上の研究者が、An​thropicのAPIの目立たない一角を「これまでに判明していること」の記事に変える主張を投稿した：すべてのClaude思考ブロックに付随するサーバー署名の「シグネチャ」をデコードすれば、フィールド6が実際に応答したモデルの名前を明らかにする、と。彼らの解釈によれば、公にclaude-fable-5と表示された応答、つまりAn​thropicが2026年6月9日から100万トークンあたり10ドル/50ドルで広く提供してきたMythosクラスのClaude Fable 5は、An​thropicの公開ドキュメントのどこにも現れない内部識別子を持つようになった：claude-kettle-e2c95a10-v2-prod。応答ラベルは何も変わらなかった。課金、APIの最上位モデルフィールド、An​thropicの固定スナップショット保証についても、何かが変わったとは示されなかった。変わったのは、ドキュメントが開発者に解析しないよう明示的に指示しているフィールドに埋め込まれた文字列だけだった。

これはリーク報告であり、判決ではありません。この発見は4日前のもので、単独の研究者による解読に基づいており、独立した再現はされていません。また、An​thropicは「Kettle」— あるいはそれに付随するラベルMYCRO_MODEL_MANATEE — が何を指すのかについてコメントしていません。有益な問いは「An​thropicがFable 5をすり替えたのか？」ではありません。証拠はそれを立証していません。有益な問いは、公開モデルIDの下に現れる内部モデルIDが、もし本物だった場合に何を意味するのか、そして何を意味しないのか、ということです。以下が、これまでに分かっていることです。

リークが実際に明らかにしたもの

シグナルは、@chetaslua による単一の X 投稿（ステータス 2089783170896179632、2026年8月16日投稿）で、このアカウントのいつもの「証拠付きで一番乗り」スタイルで書かれています。要約すると、主張は次の通りです：

Claudeの思考ブロックは、signatureフィールドにサーバー署名されたprotobufを保持しています。

• 研究者によると、そのprotobufの6番目のフィールドは、実際に応答を生成したモデルの識別子を保持している。

• 8月16日午後11時29分45秒（PDT）から、サンプリングされた2,582件の署名のうち2,582件が同じ値（claude-kettle-e2c95a10-v2-prod）を持っていました。

• 同じメタデータには、2つ目の内部ラベルであるMYCRO_MODEL_MANATEEも含まれていました。

「2,582件中2,582件」という数字は修辞的な働きをしている。研究者にとってこれは、一回限りの事例やA/Bテストの一部分ではなく、識別子が指す対象そのものが全面的に切り替わったことを示す証拠なのだ。しかし、この投稿には解読の手法が一切示されていない。生の署名も、解読スクリプトも、推定されたprotobufスキーマも、完全なレスポンスメタデータもない。公開されたエビデンスは要約グラフィックのみである。それゆえ、この発見はもっともらしい一方で、同時に現時点では検証不能でもある。

なぜ署名にそもそも「field six」があるのか？

Every thinking block Claude returns carries a signature field. Per An​thropic's thinking documentation, that signature is "an encrypted copy of the full reasoning" that you are supposed to pass back unchanged in multi-turn and tool-use conversations, and the API uses it "to verify that thinking blocks were generated by Claude." On Claude Fable 5 the default behavior makes the signature the only visible trace: with display set to "omitted" — the default on Fable 5, Mythos 5, Opus 5, and Sonnet 5 — the thinking block comes back with an empty thinking field and just the signature populated. --- Claude が返す各 thinking block には署名フィールドが含まれています。An​thropic の thinking ドキュメントによると、この署名は「完全な推論の暗号化コピー」であり、マルチターン会話やツール使用の会話ではそのまま変更せずに返すことが求められています。また、API はこの署名を「thinking block が Claude によって生成されたことを検証する」ために使用します。Claude Fable 5 では、デフォルトの動作により署名だけが目に見える痕跡となります。display が "omitted"（Fable 5、Mythos 5、Opus 5、Sonnet 5 のデフォルト）に設定されている場合、thinking block は thinking フィールドが空の状態で返され、署名のみが入力された状態になります。

ドキュメントには、このフィールドに基づくあらゆるリークにとって重要な一文が続く：「署名フィールドは不透明（opaque）である。解釈や解析をしてはならない。」Kettleの主張は、まさにその署名を解析することである。それは主張が誤りであることの証明ではない——署名はAn​thropic自身のサービングスタックが機械可読でなければならないからだ——しかし、それはデコードがベンダーの明示的な指示に反して、文書化されていないプロトコルに対して実行されたことを意味し、そして研究者によるそのプロトコルの再構築は公表されていない。「フィールド6はサービングモデルを意味する」に基づくすべての推論は、その不確実性を受け継ぐ。

それが証明しないこと

まず、証拠が実際に何であるかから始めよう。それは、公に claude-fable-5 とラベル付けされたレスポンスが、これまで報告されていなかった内部識別子を保持していた、というものだ。それがすべてである。識別子だけでは、An​thropic が Fable 5 の重みを置き換えたこと、より高性能な後継モデルが存在すること、レスポンスが良くなったか悪くなったか、あるいは何らかのリクエストがより小さいモデルにルーティングされたことのいずれも立証できない。「Kettle」は、まさに同じ Fable 5 スナップショットに対する内部サービングデプロイ名かもしれないし、ルーターコンポーネントの名前かもしれないし、セーフティスタック内の分類器かもしれない。コードネームは、それらの間を区別することはできない。

An​thropic自身のバージョン管理ポリシーが、そのリークが何も変更されていないことと矛盾しない理由を説明している。「Model IDs and versioning」のドキュメントには、2つの記述が並んで記載されている。

Anthropicは既存のモデル ID の重みや構成を更新しません。更新版が利用可能になった場合、新しいモデル ID で提供されます。

モデルの重みは特定のIDに対して固定されていますが、モデルを囲むサービング基盤は時間の経過とともに変更される可能性があります。この基盤には、リクエストルーター、安全分類器、サンプリングロジックなどのコンポーネントが含まれます。

その2番目の文が、「Kettleはスキャンダルだ」と「Kettleはありふれた月曜日だ」の間にある概念的な隔たりのすべてだ。ドキュメントは挙動のドリフトさえ予期している。「時折、インフラストラクチャの更新によって、モデルIDと重みが変更されていない場合でも、観測可能な挙動に小さな差異が生じることがある。」Kettleという名前の新しいルーターやサービングデプロイメントは、その文にぴったり当てはまる。リークが本当に決定的な証拠となるには、ポリシーに反してIDの背後に新しいモデルがあることを示すか、下記の可視性ルールに違反する仕組みを示す必要があるだろう。

文書化されたフォールバックルーティングFable 5はすでに持っています

Claude Fable 5には、実在し、文書化され、可視化されることを意図したモデル切り替えメカニズムがすでに搭載されています。セーフティ分類器がリクエストを検査し、一部（An​thropicが挙げる攻撃的サイバーセキュリティ、デュアルユース生物学、モデル蒸留、および一部のフロンティアチップ開発作業など）をClaude Opus 5モデルにルーティングできます。コンシューマー向けサーフェスでは、フォールバックは目立つことが想定されています：通知、回答に表示される提供モデル名、そしてOpusに切り替わるモデルピッカーです。APIでは、レスポンスがトップレベルのmodelフィールドと専用のフォールバックコンテンツブロックを通じて提供モデルを公開します。

{{1}}Kettleに関する主張は別のことを述べており{{/1}}{{2}}、その違いこそが重要となる部分です。{{/2}}{{3}}すなわち、公開されたFable 5ラベルを保持したレスポンスの下に現れる内部識別子のことです。{{/3}}{{4}}研究者の投稿には、フォールバック通知、変更されたAPIモデルフィールド、フォールバックブロックのいずれも示されていません。{{/4}}{{5}}もしそれらがあれば、その話は「文書化されたフォールバックが作動した」というものになり、「An​thropicが黙ってルーティングしている」というものにはならなかったでしょう。それがなければ、このリークは可視性の保証が侵害されたことを示していません。なぜなら、Kettleが何であるかを示していないからです。{{/5}}

何も変わらなくても、それが重要な理由

固定されたモデルIDは信頼の仕組みである。Anthropicのドキュメントは、「APIリクエストでモデルIDを使用する場合、そのIDの存続期間中は基盤となるモデルが一定に保たれる」と約束している。チームがclaude-fable-5に対してベンチマークを実施し、その結果が次の四半期にも意味を持つと期待できるのは、まさにこのためだ。そのIDの下に隠された識別子が何であれ、それは保証がカバーするのが重みと設定であり、リクエストからトークンに至る経路全体ではないということを思い出させる。もし開示なしにまったく別のモデルが公開IDの下で実行されたなら、そのIDに紐づくすべての評価、すべてのコスト予測、すべての品質回帰テストが、静かに無効になるだろう。

課金の観点が、この問題を一層際立たせる。Claude Fable 5は、入力トークン100万件あたり10ドル、出力トークン100万件あたり50ドルで、An​thropicが公表している料金としては最高額である。もし提供されたモデルが請求対象のIDと異なっていた場合、どの料金が適用され、誰がそれを決定するのかという問題が生じる。リーク情報は、そのようなことが実際に起きたという証拠を何も示していない。重要なのは、署名フィールドこそが、その兆候を最初に確認すべき場所だということだけである。

タイミングも注目に値する。これは9日間で3回目のAn​thropicシグナルだ。8月7日、同社はFable 5の生物分類器を再トレーニングし、社内テストで生物学関連のフォールバックを約85%削減したと発表した。8月14日には、Responsible Scaling Policy Risk Reportが、Claude Mythos 5よりも「顕著な改善」であり、リリース予定のない未公開の内部向け「Model 2」を認めた。どちらもベンダーの声明に過ぎないが、合わせると、claude-fable-5 IDを固定したまま、An​thropicがClaude Fable 5を巡るシステムを積極的に変更していることが分かる。すなわち、7日には分類器を、14日には内部後継機の存在を認めた。Kettleも同じ形の話になるだろうが、開示がないだけだ。

それについてどうすればいいか

API呼び出し側にとって、実際的な立場は退屈だが正しいものです。単一の識別子はスワップの証拠にはならず、リークにはまだ実行可能なものはありません。あなたにできることは、自分自身の証拠を作ることです。実際に受信したレスポンスのトップレベルmodelフィールドとフォールバックブロックをログに記録し、固定ワークロードでのトークンとコストの差分を監視してください。文書化されたフォールバックが発動した場合、それはまさにそれらの場所に表示されます。それがあなたのワークロードにとって重要となる唯一のテストであり、誰かがAn​thropicの署名形式をデコードすることに依存しません。

OrcaRouter経由でClaude Fable 5にルーティングする場合、Anthropicが返すのと同じレスポンス形式が返ってきます。また、プロバイダーのリスト価格をマークアップなしでそのまま通しているため、照合すべき価格のセットが2つ生じることはありません。AnthropicがFable 5の料金を変更した場合、新しい数字は同じ日に当社側でも反映されます。 このような未検証の状況では、噂に本番パスを賭けずにモデルを使い続けるための低リスクな方法は、実際のトラフィックの一部をClaude Fable 5にルーティングし、実績のあるフォールバック（100万トークンあたり$5/$25のClaude Opus 5、またはより安価なコーディング向けモデル）への自動フェイルオーバーを設定することです。そうすれば、品質の低下はインシデントではなくルーティングの判断になります。同じキーで追加契約も不要、フェイルオーバーも書き直しではなくルーティングDSLの変更で対応できます。

私たちが注目しているもの

• Anthropic がコメントするかどうか。最も明確な解決策は、Kettle と Manatee が何であるかを一文で認めることだ。沈黙自体が情報を伝える。

• 独立した再現。誰かが生の署名、復号方法、そして推測された{{KEEP}}protobuf schema{{/KEEP}}を公開すれば、これは一個人の図から検証可能な主張へと変わる。それまでは、これは「これまでに判明していること」であり、発見ではない。

• 可視性の表面。claude-fable-5 のレスポンスにフォールバック通知、変更されたAPIモデルフィールド、またはフォールバックブロックが表示され始めた場合、「文書化されたフォールバック」という解釈が強くなります。そうでない場合は、「文書化されていないルート」という解釈が強くなります。

• 新しいモデルID。An​thropicのバージョニングポリシーでは、真に新しいバージョンは新しいIDでリリースされる。したがって、Kettleが真の後継であることを最も明確に確認する方法は、An​thropicが何かをリリースすることであり、既存のルーティングを変更することではない。claude-fable-5.1または類似のものに注目してください。

• 「Manatee」が説明されるかどうか。2番目のラベルは、まだ誰も引いていない糸だ。

よくある質問

Anthropicは実際にClaude Fable 5を別のモデルにルーティングしているのですか？

証明されていない。リークによれば、claude-fable-5 とラベル付けされたレスポンスには、署名された思考シグネチャ内に内部識別子 claude-kettle-e2c95a10-v2-prod が含まれていた。しかし、これによって重みが変更されたこと、後継がデプロイされたこと、または何らかのリクエストがダウングレードされたことが示されるわけではない。「Kettle」は、同じ Fable 5 スナップショットに対する内部サーブ用デプロイメントの名前である可能性もある。

Kettle identifierはどのようにして見つかったのですか？

研究者の@chetaslua氏は、Claudeの思考ブロックの署名フィールド内のprotobufをデコードし、フィールド6からモデル識別子を読み取ったと述べています。An​thropicのドキュメントはその署名を「不透明」と呼び、開発者にそれを解析しないよう指示しています。また、研究者のデコード方法は公開されておらず、その主張はまだ独立に再現可能ではありません。

これはAn​thropicの固定モデル保証に違反しますか？

不明です。Anthropicのバージョニングドキュメントによると、既存のモデルIDの重みや設定を更新することは決してなく、新しいバージョンは新しいIDでリリースされます。しかし、モデル周辺のサービス基盤（リクエストルーター、安全性分類器、サンプリングロジック）の変更は明示的に許可されています。Kettle識別子はまさにその種の変更であり、その保証に違反するものではありません。

自分にサービスを提供しているモデルが変わったかどうかは、どうすれば分かるのでしょうか？

APIレスポンスのトップレベルのmodelフィールドを監視し、フォールバックコンテンツブロックを探し、固定ワークロードでのトークンとコストの差分を追跡します。An​thropicの文書化されたフォールバックは、それらの場所に表示されることを意図しています。Kettle識別子を公開するパブリックAPIフィールドは存在しません。

正直に読むならば、リークは何かに名前を付けただけで、それが何であるかを証明したわけではない。Kettleという識別子が実在するのは、リークされた文字列が実在し得る唯一の意味においてである。つまり、研究者が8月16日の夜以降、2,582回のうち2,582回、それがそこに存在したと述べている、ということだ。それが指し示すもの——新モデルか、名称変更されたデプロイメントか、ルーターコンポーネントか、分類器か——は未検証のままであり、An​thropic自身のドキュメントは、この件全体について極めてありふれた説明を提示している。それが本稿の価値であり、限界でもある。生のシグネチャが公開されるか、An​thropicがKettleとは何かを明言するまで、適切な姿勢は、これを「現時点で判明している事柄」として扱うことだ。すなわち、注視に値し、自身のトラフィックをログに記録する価値はあるが、モデルの選択を変える価値はない——特に、ルーティングレイヤーがあれば、どちらにせよ選択肢を開いたままにできるのだから。