定額のClaudeサブスクリプションを使い、お気に入りのサードパーティ製AIエージェントからClaude APIを呼び出していた開発者にとって、2026年4月4日は一つの区切りになりました。同日昼（PT）を境に、Claude Pro / Maxのサブスク認証でサードパーティツールからAPIを利用する経路が止まったためです。本記事では、Anthropicが挙げた技術的理由であるプロンプトキャッシュのヒット率に焦点を当て、なぜ遮断に至ったのか、どんな代替手段があるのか、そして自前でエージェントを組む開発者が押さえるべきコスト設計の勘所までを、一次情報をもとに整理します。

何が起きたのかサブスク経由のサードパーティ利用が止まった

変更の内容はシンプルです。2026年4月4日の12pm PTから、Claude Pro（月額20ドル）およびClaude Max（月額100〜200ドル）のサブスクリプションを使って、OpenClawをはじめとするサードパーティのAIエージェントツールからClaude APIを利用することができなくなりました。これまでサブスクの認証情報をバックエンドに流用してAPIを叩いていたツールや自作スクリプトは、この日を境に同じ経路では動かなくなったわけです。

発表はAnthropicでHead of Claude Codeを務めるBoris Cherny氏がX（旧Twitter）で行いました。公式ブログの整ったアナウンスではなく、開発を率いる当人がソーシャル上で直接語ったかたちで、それだけにコミュニティの受け止めも速く、賛否を含めて大きな反応を呼びました。

タイミングも議論を呼びました。Claude Codeが、サードパーティツールが先行して提供していたDiscordやTelegram連携といった機能を取り込んだ直後の遮断だったためです。価格やプラン名は記事執筆時点のもので、今後変わる可能性があります。まずは「サブスク認証を使ったサードパーティ経由のAPI利用が止まった」という一点を押さえておきましょう。

なぜ遮断されたのかプロンプトキャッシュという技術的理由

Anthropicが公式に挙げた理由は、課金や規約ではなく技術にありました。サードパーティのツールがAnthropicのプロンプトキャッシュのヒット率最適化を回避しており、コンピュートとエンジニアリングのリソースに過大な負荷をかけている、というものです。Cherny氏は「Third party services are not optimized in this way, so it's really hard for us to do sustainably（サードパーティのサービスはこのように最適化されておらず、持続可能なかたちで提供するのが本当に難しい）」と述べています。鍵になるのは sustainably、つまり持続可能性という言葉です。

ここで前提となるプロンプトキャッシュの仕組みを簡単に整理します。プロンプトキャッシュとは、リクエストの先頭から共通する部分、たとえばシステムプロンプトやツール定義、それまでの会話履歴といった安定した接頭辞をサーバー側で再利用する仕組みです。一度キャッシュに載った接頭辞は、次のリクエストで再計算せずに読み出せます。一般にキャッシュから読み出したトークンは通常の入力トークンより大幅に安価で、サーバーの計算負荷も小さくなります。

このキャッシュがどれだけ効いたかを示す指標がキャッシュヒット率です。ヒット率が高いほど、同じ会話を続けるなかで再計算される部分が減り、応答も速く、コストも下がります。逆にヒット率が低いと、リクエストのたびに長い接頭辞をフルで計算し直すことになり、サーバーの計算資源を多く消費します。エージェントのように同じコンテキストを何度も往復させる用途では、この差が積み重なって大きくなります。なお、キャッシュ読み出しの具体的な割引率や内部実装の数値は公開情報で確定していないため、ここでは定性的な説明にとどめます。

ファーストパーティとサードパーティで何が違うのか

では、なぜサードパーティだけが問題になったのでしょうか。Anthropicのファーストパーティであるツール群は、このキャッシュ最適化を前提に設計されています。リクエストの接頭辞を安定させ、変化しやすい内容を末尾に置き、キャッシュの境界を適切に指定することで、ヒット率が高く保たれるよう作り込まれているわけです。

一方でサードパーティのツールは、内部のプロンプトの組み立て方が異なります。ツールごとに独自のシステムプロンプトや会話の差し込み方を持ち、リクエストの並びが安定しなかったり、動的な内容が前方に混ざったりすると、同じような会話でもキャッシュミスが起こりやすくなります。キャッシュミスが増えれば、そのたびにフルの計算が走り、サーバー側の負荷が跳ね上がります。ファーストパーティとサードパーティで体験は似ていても、裏側の計算コストはまったく違う、ということが起こり得るのです。

ここに料金体系の問題が重なります。サブスクは月額固定の「使い放題」に近いモデルです。キャッシュミスの多い高負荷な利用が大量に走ると、提供側の計算コストが受け取る定額収益を上回り、持続が難しくなります。これがCherny氏の言う sustainably の含意です。実際、観察者のAakash Gupta氏は今回の変更を「all-you-can-eat buffet just closed（食べ放題ビュッフェが閉店した）」と表現し、1日1エージェントを回すだけでAPI換算で1,000〜5,000ドル相当を消費していたケースがあると指摘しました。これはあくまで同氏の概算ですが、定額モデルにかかっていた負荷の大きさを感覚的に伝えています。

代替手段と緩和措置Extra UsageとAPIへの移行

サブスク経由が使えなくなったあと、開発者に示された移行先は大きく2つです。1つはサブスクとAPIの中間に位置づけられるExtra Usageバンドル、もう1つはトークン従量課金のAnthropic APIです。どちらもフラットな定額ではなく、使った分に応じてコストが積み上がる構造になります。

移行にあたっては、いくつかの緩和措置も用意されました。内容を整理すると次のとおりです。

注意したいのは、これらが恒久的な救済ではなく、移行期間を支えるための一時的な措置だという点です。クレジットには期限があり、割引も事前購入が前提です。なお、Claude TeamやEnterprise契約のユーザーへの影響については、記事執筆時点で未確認です。VentureBeatもAnthropicへ問い合わせ中としており、個人向けプランと同じ扱いになるとは限らないため、組織で利用している場合は契約条件を改めて確認することをおすすめします。

開発者が押さえるべきコスト設計とキャッシュ最適化

今回の件は、自前でエージェントを組む開発者にとっても示唆に富みます。料金がフラットから従量課金へ移ると、稼働パターンによって費用が大きく変動するようになります。だからこそ、提供側が重視したのと同じプロンプトキャッシュの最適化が、そのまま自分のコスト最適化に直結します。押さえるべき勘所は次の3点です。

動的に変わる情報、たとえば現在時刻やユーザーごとの差分は、できるだけリクエストの末尾に寄せるのが基本です。前方に混ぜると、それ以降の接頭辞が毎回別物と判定され、キャッシュエンジニアブログが効きにくくなります。エージェントは同じコンテキストを何度も往復させるため、ここを丁寧に設計するだけで、応答速度とコストの双方に効いてきます。

Cherny氏は、OpenClaw向けにキャッシュヒット率を改善するプルリクエストを提出済みだとも述べています。サードパーティが最適化に取り組む余地が残されていることを示すと同時に、エージェントを実装する側にとってキャッシュ最適化が避けて通れないテーマであることも物語っています。ファーストパーティと同等に最適化された体験をそのまま得たいのであれば、現時点では公式のClaude Code経由が最も無理のない選択肢になります。

エコシステムの転換点をどう読むか

今回の遮断は、定額で大量のエージェント処理を回せた「使い放題」に近い時代の区切りを示しています。コミュニティの反応も割れました。Gupta氏が食べ放題の閉店にたとえた一方、OpenClawの創業者でのちにOpenAIに加わったPeter Steinberger氏は「Funny how timings match up（タイミングが一致しているのが面白い）」と述べ、機能の取り込みと遮断が近い時期に重なったことに批判的なニュアンスを示しました。ただし、このタイミング一致はあくまで批判側の解釈であり、Anthropicの意図として断定できるものではありません。

技術的に見れば、根っこにあるのはプロンプトキャッシュのヒット率という、エージェント基盤の経済性を左右する地味で本質的な指標です。定額モデルの持続可能性と、サードパーティを含むエコシステムの広がりをどう両立させるかは、Anthropicに限らず大規模言語モデルを提供する各社が向き合い続けるテーマでしょう。開発者の立場では、料金体系の変化を前提にコストを設計し、キャッシュ最適化を当たり前の作法として組み込んでおくことが、こうした転換に振り回されないための備えになります。