Red Hatによる219件の実世界のセッション分析によると、Claude Codeはトークン予算の4分の3をコードベースの読み取りだけに費やしています。この結果は、AI駆動のコーディングエージェントはコード生成に時間を浪費しているという従来の想定を覆すものであり、開発者は単にモデルの速度を追求するのではなく、コンテキスト管理の問題に取り組むべきであることを示唆しています。

根拠となるデータ

Red HatはAnthropicのClaude Codeとの219件のやり取りを調査し、ターンごとのトークン使用量を算出しました。サンプル全体を通じて、中央値のターンでは、トークンの75%が周囲のコードやドキュメントの取り込みに割り当てられ、新しい行の生成に充てられたのはわずか25%でした。ほとんどのAIプロバイダーは入力トークンと出力トークンを同じレートで請求するため、トランザクションの「読み取り」部分がコストの大部分を占めることになります。

なぜ読み取りコストが重要なのか

最適化戦略

多くのチームは、生成速度を向上させて数秒を短縮することを期待して、より高速または大規模なモデルにリソースを投入しています。しかし、作業の4分の3が単にコンテキストを取り込むことであるならば、モデルを高速化しても全体の時間のわずかな部分しか節約できません。真のレバーとなるのは、モデルが各ターンで処理しなければならないコンテキストの量です。

コスト管理

AIアシスタントがリクエストのたびに同じリポジトリの状態を読み直すと、入力トークンが膨れ上がります。コンテキストウィンドウが大きいプロジェクトでは、生成されるコードの量が控えめであっても、請求額が劇的に増加する可能性があります。

エンジニアリングの焦点

ツール開発者は、プロンプトがどのように構築されているかを見落としがちで、モデルの品質向上ばかりを追い求めています。この分析は、モデルに供給するコードをトリミング、キャッシュ、要約する「コンテキスト・エンジニアリング」が、モデルの段階的なアップグレードよりも大きなROI（投資対効果）をもたらすことを示唆しています。

読み取りのオーバーヘッドを抑えるための実践的なステップ

  • 不要なファイルを削る – 現在のタスクに必要のないファイルをプロンプトから削除します。プロンプトが小さくなれば、入力トークンも減少します。
  • 繰り返しの読み取りをキャッシュする – コードベースの安定した部分に対するモデルの解釈を保存し、同じテキストを再送する代わりに、ターンをまたいで再利用します。
  • ツールの出力を圧縮する – 外部ツールが大きなデータ（例：lintレポート）を返す場合、Claudeにフィードバックする前に要約します。
  • インクリメンタルな差分を使用する – ファイル全体の内容ではなく、前回のターンからの変更点のみを送信します。

これらの戦術は、AIがやり取りのたびに同じリポジトリのスナップショットを読み直すのを防ぎ、レイテンシとコストの両方を削減することを目的としています。

反論：速度も依然として重要である

一部の開発者は、生成される25%のトークンのレイテンシを低減できるため、モデルの高速化は依然として重要であると主張しています。即時の応答が求められるIDEプラグインのような、レイテンシに敏感な環境では、1ミリ秒が重要です。読み取りが支配的なプロファイルであっても、高速なモデルのメリットがなくなるわけではなく、単にその相対的な影響力が低下するだけです。

今後の注目点

Red Hatの研究は限定的なセッションに基づいているため、より広範なサンプリングを行えば、他の言語やプロジェクト規模では異なるトークン分布が明らかになる可能性があります。もし将来のデータが「読み取り75%」という数字を裏付けた場合、コンテキストを自動的にトリミングおよびキャッシュするツールや、迅速なコンテキスト取り込みに特化したモデルアーキテクチャへのシフトが見られるかもしれません。

まとめ: AI支援コーディングにおいて、最も安価なパフォーマンス向上策は、モデルに書かせる速度を上げることではなく、モデルに与える情報を減らすことです。Red Hatの数値は明確なケースを示しています。プロンプトをトリミング、キャッシュ、要約すれば、時間とコストの両面で具体的な節約を実現できるでしょう。