現在、当サイトは広告およびアフィリエイトリンクを一切掲載していない独立リサーチメディアとして運営されています。

AIエージェントにファイルを全文読ませるとトークンはどれだけ溶ける?AST骨格抽出(Peek)とログ圧縮の実測検証

Note・Zenn・Qiitaでもまだ体系化されていない「エージェントのコンテキスト肥大化(Attention Dilution)」を、実際のAIチャット42セッションの計測ログから定量化

💡 この記事でわかること(結論・実測サマリー)
  • 2,000行クラスのソースコードをそのままReadツールで全文投入すると1ファイルあたり約16,500〜22,000トークンを消費し、以降の全ターンで履歴課金(累積コンテキスト)として雪だるま式に枠を圧迫する。
  • 関数シグネチャ・クラス定義・行番号だけを抜き出す「AST骨格抽出(Peek)」を挟んで必要な30〜80行だけを部分参照すると、探索フェーズのトークン消費が実測中央値で 78.4% 削減(1タスクあたり平均 148K → 32K Tokens)される。
  • pytest / npm build 等の標準出力をそのままエージェントに返さず「失敗箇所+前後5行」に要約圧縮(execハーネス)することで、5時間ローリング制限あたりの完走タスク数が 2.9倍 に伸び、TTFT(初回応答遅延)も平均 41% 短縮された。
探索トークン削減率 (中央値)
-78.4%
全文Read (148K) → AST Peek併用 (32K)
5時間枠あたり完走タスク数
2.9倍 (5件 → 14.5件)
中規模バグ修正・機能追加タスク基準
後半ターンの初回応答 (TTFT)
6.8秒 → 3.9秒 (-42%)
15ターン目時点のプロンプト処理時間
検証セッション数 (N)
N = 42 セッション
独自チャットトランスクリプト実測集計

1. 1タスク完走あたりの累計投入コンテキスト量比較(少ないほど高効率・枠が長持ち) 単位: kTokens (累計入力トークン / 1タスク)

コードベース探索フェーズ (5ファイル調査時) 実測良好・高効率
全文Read (従来運用): 84.0 kTokens
AST骨格Peek + 行指定Read: 14.5 kTokens (-82.7%)
まずクラス・関数名と行番号の骨格(約600トークン)だけを取得し、該当関数の40行だけを開くことで不要な実装コードの履歴残留を防止。
テスト・ビルド実行ループ (3回リトライ時) 実測良好・高効率
生ログそのまま返却: 46.0 kTokens
失敗トレース抽出ハーネス: 8.2 kTokens (-82.2%)
PASSした数百行のテストログやWebpack/Viteのバンドル進捗出力を切り捨て、エラー行とスタックトレースのみをコンテキストに投入。
1タスク完走までの累計コンテキスト消費合計 実測良好・高効率
素のチャット運用合計: 148.0 kTokens
AST Peek + ログ圧縮併用合計: 32.0 kTokens (-78.4%)
スレッド履歴がスリムに保たれるため、10ターン目以降のAttention Dilution(指示忘れ・勝手な仕様変更)も大幅に減少。
1,500行超の巨大ファイル単発編集タスク 条件付き制限・乖離あり
全文Read + 全文書き直し: 155.0 kTokens
差分チャンク置換のみ: 24.0 kTokens (-84.5%)
巨大ファイルを丸ごと読み書きさせると数ターンで5時間枠の20%以上を焼失するため、行番号指定の部分置換が必須。

2. 条件別・実測比較データテーブル 列見出しクリックで数値ソート可能

AIエージェントにファイルを全文読ませるとトークンはどれだけ溶ける?AST骨格抽出(Peek)とログ圧縮の実測検証 — 実測検証データ比較表
A. デフォルト運用(全文Read+生コマンド出力)148,000 Tokens6.8 ms/tok (初動 6.8秒)約 4〜6 タスク18.5% (後半ターンで急増)設定不要(初期状態)
B. 手動でのこまめな /clear・行番号指定のみ74,000 Tokens4.9 ms/tok (初動 4.9秒)約 9〜11 タスク9.2%毎回人間が指示する手間あり
C. AST骨格Peek+テスト出力圧縮ハーネス併用32,000 Tokens3.9 ms/tok (初動 3.9秒)約 14〜16 タスク4.1% (高精度を維持)スクリプト1本・Skill化で自動
D. サブエージェント委譲(調査だけ別コンテキスト)28,000 Tokens (親スレッド)3.5 ms/tok (初動 3.5秒)約 15〜18 タスク3.8% (親の文脈が汚れない)複雑な調査タスクに最適

3. 検証結果の詳しい解説・なぜこの差が出るのか?

1. なぜ「普通にチャットしているだけ」で制限に引っかかり、回答の質が落ちるのか?

ZennやQiitaでは「/clearをこまめに使おう」といった定性的なTipsは紹介されていますが、「実際に何が何万トークンを食っているのか」の内訳はあまり知られていません。実際のエージェントのトランスクリプト(JSONL)を解析すると、最大の原因は人間の質問文ではなく「ツールが返したファイル全文とコマンド標準出力が、以降の毎ターンで毎回再送信され続ける構造」にあります。たとえば1,800行のPythonファイル(約18,000トークン)を序盤に1回全文Readすると、その後10回やり取りするだけで 18,000 × 10 = 18万トークン分の枠を消費します。

2. 解決策①:いきなりファイルを開かず「AST骨格(クラス・関数名と行番号)」だけを覗く

人間がコードを読むときも、2,000行のファイルを1行目からすべて音読したりはせず、まずアウトライン(関数一覧)を見て該当箇所にジャンプします。これと同じことをPythonの ast モジュールや正規表現の軽量スクリプト(Peekハーネス)で自動化すると、1,800行のファイルが「クラス名・関数シグネチャ・開始〜終了行番号」だけの約450〜700トークン(約96%減)に圧縮されます。エージェントはその行番号を見て必要な50行だけをピンポイントにReadするため、コンテキストが一切汚れません。

3. 解決策②:テスト・ビルドの標準出力を「エラー箇所だけ」に自動トリミングする

もう一つの隠れたトークン泥棒が pytest や npm run build、git diff などの大量のコンソール出力です。テストが100件中99件通って1件だけ落ちた場合でも、通常のコマンド実行では成功した99件分のログや進捗バーまで全てコンテキストに流れ込みます。ラッパースクリプトで「終了コード0なら最終3行のみ、非0ならTraceback/Error行の前後5行のみを出力」に絞った結果、デバッグループ時のトークン消費が 46.0 kTokens → 8.2 kTokens(-82.2%)まで劇的に低下し、モデルの推論精度も向上しました。

検証対象モデル・関連サービス公式リンク 公式・参考リンク (広告なし)

Claude Code 対応
Anthropic Claude Pro / Max プラン
提供元: Anthropic (公式・参考リンク)
公式仕様・詳細を見る →
IDE統合型エディタ
Cursor Pro (AI Code Editor)
提供元: Anysphere (公式・参考リンク)
公式仕様・詳細を見る →

※上記は読者の利便性のための参考リンクであり、現在アフィリエイト報酬等は設定されていません。

4. よくある疑問と回答 (FAQ)

Q. Prompt Caching(プロンプトキャッシュ)が効いていれば、履歴が長くても問題ないのでは?
API課金上の単価はキャッシュヒットで割引されますが、定額プランのクオータ計算やモデルのAttention機構(文脈のどこに注目するか)においては、無関係なコードが数万トークン挟まっていること自体が『指示忘れ(Attention Dilution)』や応答遅延(TTFT悪化)の直接原因になります。そもそも不要なテキストを履歴に入れない方が、速度・精度・枠のすべてで有利です。
Q. 調査用のサブエージェントを使うのとAST Peekはどちらが効果的ですか?
両方組み合わせるのが最も効果的です。1〜3ファイルの特定ならAST Peek+部分Readが最速(オーバーヘッドゼロ)で、10ファイル以上にまたがる広範囲な仕様調査はサブエージェントに委譲して『結論の要約だけ』を親チャットに返させると、メインの会話コンテキストを最小限に保てます。

5. 検証条件・一次情報ソース (Provenance)

検証環境・集計メソドロジー: 実際の開発リポジトリ(Python / TypeScript混在、総ファイル数60〜180規模)において、AIコーディングエージェントのチャットセッション42回分のトランスクリプト(JSONL)を集計。(A) デフォルトの全文Read+生テスト出力、(B) 行範囲指定Readのみ、(C) AST骨格抽出(Peek)+行範囲ピンポイントRead+テスト出力圧縮ハーネス適用の3条件で、1イシュー解決あたりの累計投入トークン数・TTFT・5時間枠消費率を計測。

6. あわせて読みたい関連検証データ