Claude Codeがプロンプトの80%をばっさり削除した、AnthropicがFable 5で見本を示した:AI業界の「コスト削減」はまだ始まったばかりだ

“Fable 5 这个价格远高于中国程序员一天工资。写代码一天烧几百万 token 已经很节约了,然后一看账单几千 rmb。”

これは現実に起こっていることだ。最新のデータによれば、Anthropic 自社が計算リソースに費やす金額は、すでに給与支出の 2.3 倍に達している。シニアエンジニアの完全コスト 22 万 4000 ドルを基準にすると、Anthropic のエンジニア 1 人あたりの年間計算リソース支出は約 51 万 5000 ドルとなる。つまり、人よりもモデルの方が高価なのだ。

こうした請求書を前に、Claude 自身もトークンを節約せざるを得なくなっている。

Claude Code:トークンを燃やして「自分は生産的だ」という錯覚を得る

最近、業界では新たな言葉が登場した:Token Apocalypse(トークン終末)。

token maxing から token apocalypse へ、これは AI 業界で本当に大きなパラダイムシフトが起きていることを示している。今年の 3 月から 4 月にかけて、人々は自分がどれだけのトークンを使ったかを誇示し、それをランキングのように扱っていた。しかし、AI を使うことが自動的にコスト削減を意味するわけではないと気づき、人々は単一トークンのコストをより重視するようになった。

さらに微妙な点として、大規模モデルはもともと AI を使う必要のなかった多くの仕事を拡大している。私たちは今、PDF を自分で読むのを嫌い、長文を自分で見るのを嫌い、すべてを AI に要約させようとする。あるいは、それらを AI でスライドに変換して他の人に送り、相手もまた AI でそのスライドを読むかもしれない……AI は、もともと空虚な仕事にさらに無理やり価値を注入し、同時に請求書をひそかに押し上げている。

今や、コストの制御不能は常態化している。Amazon、Adobe、Atlassian、Citigroup などの企業は、AI の使用に厳格な管理を導入し始めている:

  • モデルレベルの制限:一部の企業の従業員は Claude Opus などのハイエンドモデルを使用することを禁止され、より安価なバージョンへのダウングレードを強いられている;

  • 個人上限の設定:Uber はエンジニア 1 人あたり月額 1500 ドルのトークン上限を設定;

  • アクセス権限の完全停止:Citibank などの機関はすでに高度な AI ツールへのアクセスを完全に制限しており、使用目標に達しない従業員は企業アカウントを取り消される。これに先立ち、Uber の CTO は、数ヶ月で年間の AI 予算を使い切ったと認めている。Walmart も最近、一部のツールの使用を停止した。

大企業は節約方法をあちこち探すか、トークンの浪費に急ブレーキをかけている。そのため、従業員が受け取るメッセージは極めて矛盾している:一方で「AI を使えば効率が 100 倍になる、使わなければならない」と言われ、他方で「会社を破産させるな」と言われる。

これは AI ツールの第一波の普及において最も典型的な問題でもある:ツールがリリースされる際、企業が大規模言語モデルに数百万ドルを費やすのを防ぐ十分なガードレールがなく、チームにトークンが急速に燃え尽きていることを警告する仕組みもなかった。チャットボットであれコーディングツールであれ、多くの製品はまず「使える」ことを優先し、コストガバナンス、使用クオータ、モデル階層化、コンテキスト管理は後回しにされた。

しかし Claude Code は本質的に効率ツールではなく、マーケティングツールだ。

その設計目標は明確:自分が生産的だと感じさせること。Boris、Claude Code のプロジェクト責任者は、この製品を作るにあたって最初に考えたのは: 「もしモデルが十分に賢くなったら、コードはどうなるのか? 私はこれらをどのように使いたいのか?」——出発点は「どのように開発者にトークンを節約させるか」ではなく、「どのようにモデルの賢さを示すか」だった。

Anthropic はこの「感覚」のために大量のトークンを燃やす覚悟がある——それがあなたの金であれ、自分たちの金であれ。5 分で 200 ドルを使うことは、Claude Code にとって事故ではなく、設計だ。その根底にあるロジックは:トークンを多く燃やして解決できる問題には、決してトークンを節約する方法を探さない。 すべてのサブエージェント、すべての派手な UI アニメーション、すべての冗長な reasoning trace は、効率のためではなく、あなたが画面を見つめて「このモデルは本当に賢い、本当にできる」と感じさせるためだ。

その背後には、注意深く設計されたマーケティングのループがある:あなたは大量のトークンを燃やし、「生産的」という感覚を得る。それで Claude が良いと感じ、使い続ける。 Anthropic は自ら大量のトークンコストを負担してでも、この感情的な承認を得ようとしている。これが、デスクトップアプリへの投資が明らかに不足している理由でもある——Claude Code の目標は良いツールを作ることではなく、Anthropic のモデル能力の「最良のショーケース」になることだ。

そしてまさにこの「トークンを燃やして体験を得る」という設計哲学が、Claude をトークン効率で OpenAI に引き離されている理由だ。

OpenAI は常にトークンを削減しようと努力してきた。reasoning trace の圧縮からモデル自体の効率最適化まで、その哲学は:より少ないトークンで同じ仕事をすること。Codex 5.5 はその最良の例だ。

Fable 5 のようなモデルは確かに賢いが、他のモデルと比較すると効率は高くない。Deep SWE のこのグラフがその問題をよく示している。同じバッチのモデルを比較すると、さらに明らかになる:GPT-5.5 medium はわずか 2 万トークンで驚くべきスコアを獲得したのに対し、Opus 4.8 は 5 万トークンを使ってスコアはむしろ低かった。

これが二つの路線の最も直接的な描写だ:業界はパニックに陥り、Claude は燃やし、OpenAI は節約する。そして次の問題は——コスト削減のために、最初に切るべきものは何か? 答えは:長く積み上げられたプロンプトだ。

Claude Code のプロンプト負債:積めば積むほど、借金が増える

最新の講演で、Anthropic は Claude Code のシステムプロンプトの 80% を削除したと述べている。

Anthropic の技術チームメンバー Tariq Shihipar は、これは AI モデルの誘導方法における根本的な変化を反映していると説明する——かつては、指示が多ければ多いほど、例が多ければ多いほど、モデルのパフォーマンスが向上すると考えられていた。しかし今、その論理はもはや成り立たない。新しいモデル Fable 5 は、彼ら自身が提供する例よりも想像力に富んでおり、例がむしろ制約となっている。

これにはマーケティング要素もある。彼は Fable の能力を誇張して「例はむしろモデルを制限する。なぜなら、実際にモデルは私たちが提供する例よりも想像力に富んでいるからだ」と述べた。しかし、一つの事実は避けられない:Anthropic 自身も system prompt にメスを入れ始めているのだ。

では、なぜ以前はこれほど多くのプロンプトが必要だったのか?

過去 1 ~ 2 年、AI コーディングの世界では慣性思考が形成されていた:コンテキストは大きければ大きいほど良い、ツールの説明は多ければ多いほど良い、system prompt は完全であればあるほど良い。モデルがプロジェクトの構成を理解していない? Agents.md を書け。モデルがツールの使い方を知らない? tool descriptions を書け。モデルが十分に積極的でない? 行動ガイダンスを書け。モデルが不安定? さらに system prompt に制約を追加しろ。

否定できないのは、system prompt はかつて AI コーディングツールの中核的な競争力だったことだ。LLM のプロンプトに小さな調整を加えるだけで、顕著なパフォーマンス向上が得られる可能性がある。同じモデルが Codex、Cursor、OpenCode、Copilot で異なって感じられる場合、ほぼ間違いなくプロンプトの微妙な違いが原因だ。

これこそが、Cursor が system prompt のテストに多くの時間を費やし、A/B テストを行い、異なるモデルに対してプロンプトの方法を微調整した理由でもある。Claude Code で Opus を使用する場合と比較して、Cursor のハーネスはモデルのパフォーマンスを大幅に向上させ、一部のベンチマークでは 10% から 30% もの向上が測定されている。 その違いの核心は、多くの場合、あの数行のプロンプトにある。

しかし問題は、プロンプトが役立つ限り、チームはどんどん追加していくことだ。あるモデルがツールを乱用するからルールを追加する。あるモデルが積極的でないから励ましを追加する。あるモデルが検索しすぎるから制限を追加する。あるモデルがプロジェクトコンテキストを理解しないからマークダウンファイルを追加する。それぞれの追加には理由があるが、長期間積み重ねると、system prompt は巨大な常駐コンテキストの重荷になる。

問題は:system prompt は無料ではない。 呼び出しのたびに読み込まれ、課金され、コンテキストを占有する。

Claude Code はすべてのツールと機能を内蔵した後、system prompt は一時 65,000 トークンにまで膨れ上がった。ほとんどの機能をオフにしても、まだ 12,000 トークンある。 つまり、モデルがまだ一行のコードも書いていないうちに、すでに説明書を背負っていることになる。比較として、Pi の起動時コンテキストは 1,000 トークン未満だ。

さらに厄介なのは、プロンプト負債はコード負債よりも隠れていることだ。

コードが古くなると、通常は機能変更、テスト実行、バグ修正の際に明らかになる。プロンプトが古くなると、モデルが静かに劣化するだけかもしれない。ユーザーは「最近 Claude Code は以前ほど賢くない」とか「新しいモデルは宣伝ほど強くない」と感じるかもしれないが、本当の理由は古い system prompt が新しいモデルに追いついていないことかもしれない。

プロンプトが競争力から負担に変わったとき、Anthropic は 80% を削除することを選び、さらにトークン効率を向上させた。

Claude の「おしゃべり税」:一言多く言うごとに、一銭多く支払う

Claude Code のおしゃべりは本当に多すぎる。

今年、Caveman というプラグインが急速に人気を博し、この問題を専門に解決している。その名前の直訳は「穴居人」で、原始人のように話すことを意味する——礼儀を省き、余分な文法を加えず、フィラーワードを入れず、核心だけを残す。

一見すると冗談のように聞こえる。しかし理解すると、LLM における非常に現実的な問題を解決していることに気づく:おしゃべりが多すぎる、トークンが多すぎる、コストが不必要に高くなっている。

そしてその起源は、まさに Claude Code にある。

「4 月初めに Caveman を作りました。その頃、Claude Code をヘビーに使っていて、多くのトークン費用が不要なテキストに浪費されていることに気づいたからです:挨拶、曖昧な表現、つなぎ言葉、エージェントループでは実際には重要ではないおしゃべりな表現。」と Caveman の作成者 Julius Brussee は言う。

Brussee の評価によると、Caveman はデフォルト出力と比較して出力トークンを 65% から 75% 削減し、効果は通常の「簡潔に」指示を上回る。 主に周囲の言語を圧縮し、コード、コマンド、パス、URL、関数名など正確さが必要な部分には影響を与えない。

報道によると、OpenAI のエンジニアリングディレクター Shayne Sweeney もこのプロジェクトにコードを提供し、Codex をサポートした。

さらに興味深いのは、OpenAI がすでにこのような言語モードを思考プロセスに適用していることだ。

いくつかのリークされた reasoning trace(外部に表示される reasoning summary ではない)が外部にヒントを与えた。内容は普通の英語ではなく、圧縮されたエンジニアリング速記のように見える:

"Use core new nodes. Need infer. Need add VAE encode for images. Try. Try period."

これらの文は一見おかしく、少し乱れているように見えるが、その重点は可読性ではなく、トークン効率にある。モデルは内部推論時に、ユーザーに話すときのように礼儀正しく、完全で、流暢である必要はない。アクション、オブジェクト、判断、次のステップだけを保持すればよい。言い換えれば、最終的な答えが正常である限り、モデル内部ではより短く、より粗く、よりトークンを節約する言語で思考を完了し、狂ったようにトークン効率を追求できる。

これはプロンプトを書く段階よりもさらに有用だ。reasoning token を圧縮するメリットはより大きい。なぜならエージェントは複数ステップで実行され、前のステップの思考が次のステップの入力になるからだ。モデルが「考える」のを少し減らせば、節約できるのはその場の数トークンだけでなく、その後の実行チェーン全体における繰り返しのオーバーヘッドだ。

これこそが OpenAI と Claude の路線における明らかな違いだ。

Claude は常により話しやすく、完全な言語で考え表現するアシスタントだ。その reasoning trace がはるかに長いことから、おそらく普通の英語を使っていると推測できる。その出力と reasoning はしばしば長く、そのためより大きなコンテキストウィンドウに依存してそれらを収容する。

これが Claude がデフォルトで 100 万トークンのコンテキストウィンドウを使用する理由でもある。多くの人は大きいコードベースを収容するためだと思うが、実際の理由はより単純だ:Claude が生成するものが長すぎて、このウィンドウがなければ収容できないからだ。 それらは圧縮にも弱く、古いスレッドを復元するとき、Claude は完全なコンテキストを保持せず、代わりに compact を試みるよう提案する。なぜなら、reasoning trace を保持しないからだ——実際、10 分から 20 分後にそれらを消去する。reasoning token の効率が悪すぎて、保持し続ける価値がなく、そうしないとコストが馬鹿げたほど受け入れられなくなるからだ。

一方、OpenAI のモデルのトークンコンテキストウィンドウはおそらく 20 万以下だが、最初からこの短い言語で圧縮を実現しているからだ。

一つの味わうべき細部:もし Anthropic が「おしゃべりが多すぎる」問題を修正すれば、彼らの収入は顕著に減少するだろう。もし開発者がモデルを使って同じ仕事をこなしながら、生成するトークンが少なければ、それは彼らが稼げないお金だからだ。

出典:InfoQ

リスク注意事項及び免責条項

        市場にはリスクが伴い、投資には注意が必要です。本文は個人投資のアドバイスを構成するものではなく、個別のユーザーの特別な投資目標、財務状況、ニーズを考慮したものではありません。ユーザーは本文中の意見、見解、結論が自身の特定の状況に適合するかどうかを検討する必要があります。これに基づく投資は自己責任です。
原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • リポスト
  • 共有
コメント
コメントを追加
コメントを追加
コメントなし
  • ピン留め