AnthropicがOpenClawを切った理由 — Claudeサブスクリプション方針転換と開発者のコスト現実

4月4日、Anthropicは静かに利用規約を変更した。変更内容はシンプルだ: Claude ProやMaxのサブスクリプションでOpenClawなどのサードパーティエージェントフレームワークを動かすことができなくなった。これからはAPI直接課金だ。

私はこのニュースをOpenClawコミュニティで最初に目にした。最初は「また規約の文言整備か」と思ったが、実際に何を意味するのか計算してみると、思ったより大きな話だった。Pythonでコスト計算スクリプトを書いてシナリオ別の数値を出してみた。結論から言えば — 最適化なしにそのまま使うと最大10倍の値上げ、設計をきちんと変えれば逆に安くなる、ということだ。

この記事は数値ベースの分析だ。「Anthropicが悪い」「理解できる」という定性的な意見よりも、今何が起きているのか、数字で見るとどれだけ変わるのか、そして私ならどう対応するかを整理した。

AnthropicがサブスクリプションをブロックしたのはなぜかQ

Anthropicの公式見解は「容量は慎重に管理するリソースだ」というものだ。この説明は正直、十分に納得できる。

$200のClaude Maxサブスクリプションを持ってOpenClawで自律エージェントを動かすとどうなるか — エージェントは人間ではないので休まない。24時間、分に数十回APIを呼び出すことができる。人間がOpusを1日2時間会話に使うのではなく、サーバーが1日24時間Opusを呼び出す構造だ。Anthropic側の内部計算では「$200サブスク利用者が$1,000〜$5,000相当のコンピューティングリソースを使う」という結論が出たと言われている。これが誇張かどうか私の計算で直接確認したが — 誇張ではない。

500セッション/日、セッションあたり2,000入力 + 500出力トークンをOpus 4.7で30日動かすと$337.50だ。$200サブスクでカバーするにはすでに1.7倍を超えている。エージェントがより長く動き、より頻繁に呼び出されると、この比率はすぐに上がる。

OpenClaw創業者のPeter Steinbergerはこの決定に即座に反発した。「API単価への移行では感当不可能なコストになる」と述べ、AnthropicがOpenClawの主要機能を自社製品に内製化してから外部アクセスをブロックしたのではないかという疑惑も公開した。開発者コミュニティの一部からは「これなら競合モデルに移行する」という反応も出た。

率直に言うと、Anthropicの決定が完全に間違っていると言い切るのは難しい。定額サブスクをAIエージェントに無制限に適用するのは構造的に持続不可能だ。その点は正しい。ただし、既存ユーザーに移行準備時間を十分に与えなかったこと、そしてFast Modeという新たな高コスト機能を同時期にリリースして混乱を増幅させたタイミングは良くなかった。

Fast Mode: 6倍課金の構造と隠れた落とし穴

同じ時期にAnthropicはFast Modeを導入した。これが単なる「より速い応答」ではなく、まったく異なる課金構造であることを指摘しておく必要がある。

標準Claude Opus 4.7の価格は入力$5、出力$25（100万トークン基準）だ。Fast Modeをオンにすると入力$30、出力$150に跳ね上がる。6倍だ。200K入力トークンを超えると入力が$60にさらに上がる。公式ドキュメントはこれを「プレミアム速度機能のプレミアム価格」と説明しているが、数字の前では説明はあまり意味がない。

さらに厄介なのがセッション遡及適用の問題だ。Fast Modeを会話の途中でオンにすると、すでに積み上げられたコンテキスト全体がFast Mode単価で遡及適用される。長い会話を続けた後に誤ってFast Modeをオンにしたり、コードの条件分岐が誤ってFast Modeをオンにしたりすると、請求書が予測不可能に跳ね上がる。

もう一つの制約: Fast ModeはAWS Bedrock、Google Vertex AI、Microsoft Azure Foundryでは使用不可だ。Anthropic直接APIでのみ使える。クラウドコンソールで統合管理している企業はこの機能をまったく使えないということでもある。

私の判断では、Fast Modeはごく特殊な状況 — ユーザーが待っているインタラクティブUIでレイテンシがビジネスKPIに直接連動する場合 — にのみ使う機能だ。自動化エージェントにデフォルトでオンにするのは財政的に危険だ。

実際のコスト計算: ケース別シナリオ

Pythonスクリプトを書いて公式価格表をもとにシナリオを検証した。すべての数値はplatform.claude.comの公式価格に基づく。

ケース1: ヘビーOpenClawユーザー（500セッション/日、既存サブスク$200/月）

前提: 1セッションあたり入力2,000トークン + 出力500トークン、30日間

Opus 4.7 標準（最適化なし）:    $337.50/月
Opus 4.7 Fast Mode（6倍）:     $2,025.00/月
Opus 4.7 + 70%キャッシュ:       $243.00/月
Sonnet 4.6 + 70%キャッシュ:     $145.80/月
Haiku 4.5 + 70%キャッシュ:       $48.60/月
既存Maxプラン比率:              1.7x〜10.1x

最悪の場合（Fast Mode無防備）は10倍の値上げだ。しかしSonnet 4.6にモデルを下げてキャッシュヒット率を70%まで引き上げると$145.80となり、元々の$200 Maxプランより逆に安くなる。Haikuを使えば$48.60だ。

ケース2: 中規模開発者（1日50セッション、ブログ自動化、文書分析など）

Sonnet 4.6 最適化なし:   $20.25/月
80%キャッシュヒット:      $13.77/月
キャッシュ + Batch API:   $6.88/月

この規模ではサブスクブロックによってむしろコストが下がる。$200 Maxプランでブログ自動化程度しか動かしていなかったなら、API直接課金のほうがずっと合理的だ。

Claude APIプロンプトキャッシング最適化パターンでキャッシュヒット率を70〜80%に引き上げる実際の実装方法を確認できる。今回の方針転換でキャッシングは単なる最適化ではなく生存戦略だ。

コストを下げる3つの実践的戦略

戦略1: モデルティア分離（ルーティングレイヤーの追加）

エージェントワークフローをタスクの種類に応じて分離するのが最初だ。すべてのタスクをOpus 4.7に送ることがコスト爆発の主な原因だ。

def route_to_model(task_type: str) -> str:
    """モデルルーティング — タスクの複雑さに応じて分離"""
    routing = {
        # 複雑な推論、コード生成 → Opus
        "code_generation":    "claude-opus-4-7",
        "complex_reasoning":  "claude-opus-4-7",
        "multi_step_agent":   "claude-opus-4-7",
        # 中程度の複雑さ → Sonnet
        "summarization":      "claude-sonnet-4-6",
        "translation":        "claude-sonnet-4-6",
        "draft_review":       "claude-sonnet-4-6",
        # 単純な分類、ルーティング → Haiku
        "classification":     "claude-haiku-4-5-20251001",
        "routing":            "claude-haiku-4-5-20251001",
        "simple_extraction":  "claude-haiku-4-5-20251001",
    }
    return routing.get(task_type, "claude-sonnet-4-6")

戦略2: プロンプトキャッシングの積極活用

システムプロンプトや繰り返し使うコンテキストにキャッシュマーカーをつけると入力トークンのコストが90%下がる。キャッシュTTLは5分なので短いセッションでも効果がある。

AIエージェントのコスト現実分析で取り上げたように、エージェントコストが人件費を上回るシナリオはキャッシングなしにOpusを全方位で使うときに現実になる。キャッシュヒット率をロギングして追跡することがコスト可視化の第一歩だ。

戦略3: リアルタイム不要なワークロードはBatch APIで分離

リアルタイム応答が不要な作業 — 文書分析、翻訳、分類バッチ、夜間レポート生成 — はBatch APIを使うとすべてのコストが50%下がる。バッチ結果は通常24時間以内に返ってくる。

この3つを組み合わせれば — ルーティング + 70〜80%キャッシュ + バッチ処理 — 大半の自動化エージェントワークロードを既存の$200 Maxプラン水準かそれ以下で運営できる。

エンタープライズユーザーの状況はさらに複雑だ

エンタープライズアカウント構造も同時期に変わった。以前はエンタープライズ契約で一定の料金を払えば使用量上限が柔軟だった。2026年からは「請求を無効にすることはできません」が公式ポリシーになった。座席あたり$20基本料金にすべての使用量が標準API単価で課金される。

これが意味するのは — 大企業ITチームが部門別のClaude使用量を予算内で管理するのが大幅に難しくなったということだ。以前は月定額で予測可能な支出が可能だったが、今はエージェント使用量のモニタリングなしには四半期コストの予測が不可能だ。

実際にOpenTelemetryを使ったLLMパイプラインの観測可能性が重要になったのもこの文脈からだ。トークン消費量、モデル別コスト、キャッシュヒット率をリアルタイムで監視しないと、請求書が届くまでコストがわからない。

競合モデルに乗り換える理由ができたか

これが正直、最も現実的な質問だ。Anthropicがサブスクリプション構造に手を加えてFast Mode 6倍課金を導入した時点で、別のモデルに移行することが合理的かどうか真剣に検討する必要がある。

DeepSeek V4-Flashは入力基準でClaude Sonnet 4.6の約10分の1以下の価格だ。MITライセンスでオープンソースだ。コーディングベンチマークで競争力のある性能を示している。デメリットは中国企業というデータ主権の問題、SLAレベル、そしてレイテンシがAnthropicに比べて不安定な可能性があることだ。

GPT-5.5はClaude Opus 4.7と価格が似ている。SWE-benchなどのコーディングベンチマークではOpus 4.7に劣る。わざわざ乗り換える経済的理由がない。

私の推奨はコアエージェントはClaude APIを維持、ボリュームが多い単純タスクはHaikuまたはDeepSeekを混用することだ。すでにLLM API価格比較でシナリオ別の詳細計算をしてあるので、自分のワークロードパターンに合わせて比較してほしい。

Anthropic Managed Agentsは真剣な代替案か

同じ時期にパブリックベータとして公開されたManaged Agentsがある。セッションあたり$0.08/時間課金だ。これがどれだけ合理的か計算してみよう。

エージェントセッションが平均20分なら1セッションあたり$0.027だ。500セッション/日 × 30日 = 15,000セッションならセッションコストだけで$400だ。ここにトークンコストは別途かかる。ただしManaged Agentsは状態管理、ツール呼び出し、エラー回復、セッション再起動などのインフラをAnthropicが処理してくれる。

直接エージェントインフラを運営するときの隠れたコスト — DevOps時間、モニタリングツール、エラー通知、セッション状態保存 — を時間あたりに換算すると$0.08/時間は思ったより高くないかもしれない。

私はManaged Agentsが「エージェントインフラを素早く検証したいチーム」に適しており、すでに複雑なカスタムエージェントを運営しているチームは相当なリファクタリングなしには移行が難しいと見ている。最も現実的なシナリオはハイブリッドだ。

今すぐやるべきこと

Anthropicの今回の決定を単純に悪いとは言い切れない。定額サブスクをAIエージェントに無制限に適用するのは構造的に持続不可能だ。その点は正しい。

残念なのは転換の方法だ。既存ユーザーに十分な猶予期間がなく、Fast Modeという高コスト機能を同時にリリースして混乱を増幅させた。「容量保護」という論理と「Fast Mode 6倍課金の導入」が同じ月に起きたのは偶然ではないだろう。

即時（今週中）:

• OpenClawやサードパーティエージェントでClaude Maxを動かしているならすぐにAPI直接課金体系に移行する
• Fast Modeがコードのどこかでデフォルトでオンになっていないか確認してオフにする
• 現在の月間トークン消費量を測定する（Anthropicコンソールのタブで確認可能）

短期（今月中）:

• モデルルーティングレイヤーを追加する：複雑さに応じてOpus/Sonnet/Haikuを分離する
• システムプロンプトと繰り返しコンテキストにキャッシュマーカー（cache_control）を追加する

中期（来四半期中）:

• リアルタイム不要なバッチ作業をBatch APIで分離する
• Managed Agentsベータをテストして自社インフラコストと比較する

今回の方針転換は不便なのは事実だ。しかし結果的に「何も考えずにOpusをあらゆる場所に注ぎ込んでいた」開発パターンを強制的に修正する効果もある。コスト意識のないエージェント設計はいずれにせよいつか問題になっていたのだから。