Claude Code を使い始めてしばらく経ちますが、その性能は疑いようもなく強力です。しかし、一つだけ気に入らない点があります。それはファイルの読み込み方があまりにも乱暴だということです。
関数の修正を依頼すると、まずファイル全体を読み込み、依存関係が別のファイルにあると分かると、そのファイルも読み込みます。さらにあるクラスの定義を確認する必要があると分かると、3 つ目のファイルまで読み込んでしまいます。
シンプルな要件なのに、3 つも 4 つものファイルを丸ごと読み込まされ、トークンが瞬く間に消えていきます。さらにOpenAI が週に 3 つの製品を削減し、Claude も利用枠を再厳格化：AI の黄金時代は終わりか？という状況下では、公式の 20 ドルサブスクリプションなど、ほんの少し試すだけですぐに使い果たしてしまいます。
これは別に Claude Code だけの問題ではなく、すべての AI コーディングエージェントに共通する持病です。
エージェントには「ディレクトリ構造を把握する」という概念が欠けています。デフォルトの動作は「分からない？ならファイルを読む。それでも分からない？ならもう 1 つ読む」というものです。
最近、この問題に特化した「cx」というツールを見つけ、使用したところ非常に効果的だったので、皆さんと共有します。
なぜエージェントはこれほどまでにファイルを読みまくるのか？
まず、問題の本質を理解することから始めましょう。
人間が新しいプロジェクトに取り組む際、まずはディレクトリ構造を確認し、関数名を検索し、定義元へジャンプして、必要な数行だけを確認します。
このプロセスは極めて正確で、ファイル全体を最初から最後まで通読することなどありません。
AI エージェントにはこれができません。
エディタを持たず、LSP（Language Server Protocol）も持たない彼らにとって、唯一の手段が「Read File（ファイル読み込み）」だけだからです。
その結果、Cx の開発者が 73 件の Claude Code セッションデータを分析したところ、以下のことが判明しました。
読み込みの 66% が連鎖的であり、B を見つけるために A を読み、C を見つけるために B を読んでいます。また、37% は重複読み込みで、1 つのセッション内で同じファイルが何度も読まれています。
ファイル 1 回あたりの平均消費トークンは約 1200、1 セッションあたりの平均読み込み回数は 21 回にも及びます！
つまり、何も作業を始める前に、1 セッションあたりコード読み込みだけで 2 万トークン以上が消費されてしまうのです。
cx とは何か？
cx は Rust で記述されたコマンドラインツールで、tree-sitter をベースにした構文解析を行います。これはエージェントに対し、「コストの階段」を提供するものです。
cx overview src/fees.rs 約 200 トークン このファイルには何がある？ cx definition --name calc 約 200 トークン この関数を見せて cx symbols --kind fn 約 70 トークン プロジェクト全体にどんな関数がある？ cx references --name calc 極微量 このシンボルはどこで使われている？ファイルを直接読み込む場合、中規模のファイルで 1200 トークンかかるのに対し、cx overview なら 200 トークン、cx definition で関数本体のみを直接取得する場合も 200 トークンで済みます。
エージェントがこのツール群を使用することで、まず overview で構造を把握し、必要に応じて definition で正確に関数を取得できるようになり、多くの場合でファイル全体の読み込みが不要になります。
実測データでは、Read 呼び出しが 58% 減少し、トークン消費量は 40〜55% カットされました。
なぜ LSP を使わないのか？
もっともな疑問です。Language Server でも「定義元へ移動」や「参照箇所を探す」といったことは可能です。なぜ、あえて cx などというものを新たに作る必要があるのでしょうか？
それは、LSP が人間用であり、エージェント用ではないからです。
LSP を使用するには常駐バックグラウンドプロセスが必要で、言語ごとに個別の設定が求められ、メモリも 1〜2GB も消費します。さらに、使用可能になるまでプロジェクトのコンパイルやインデックス作成が完了するのを待つ必要もあります。
エージェントは 1 つのセッションでそれを 1 回しか使わないかもしれないのに、この重厚な仕組みを起動させる価値はありません。
cx はステートレス（状態を持たない）です。
初回実行時に tree-sitter を使用して全ソースファイルを解析し、軽量なローカルインデックス「.cx-index.db」を作成します。その後は変更のあったファイルのみを差分更新します。
バックグラウンドプロセスも不要で、コンパイルの依存関係もなく、実行するだけで使えます。
インストール方法と Claude Code への組み込み方
インストールは非常に簡単です。
curl -sL https://raw.githubusercontent.com/ind-igo/cx/master/install.sh | shあるいは Cargo を使用します。
cargo install cx-cli次に、Claude Code 用の「取扱説明書」をインストールします。
cx skill > ~/.claude/CX.mdさらに、~/.claude/CLAUDE.md の 1 行目に以下を追加します。
@CX.mdこれで完了です！
cx skill は、いつ cx overview を使い、いつ cx definition を使うべきか、またどのような場合にのみファイル全体の読み込みが必要かを示すプロンプトを出力します。
Claude Code はこの説明書を読み込むと、自動的に cx のコマンドを「Read File」よりも優先して実行するようになります。
言語サポートの追加:
cx lang add rust typescript pythoncx はプロジェクトで使用されている言語を自動検出しますが、対応する文法（grammar）がインストールされていない場合は、その旨を通知してきます。
実際の使用感は？
Rust プロジェクトで試してみました。
あるモジュールのリファクタリングを Claude Code に依頼した際、以前ならエントリーポイントファイルを読み込み、次に依存ファイルを読み込み、いくつかのファイルを読んだところでコード作成に取りかかる、という流れでした。
現在では、まずcx overviewを実行して全体構造を把握し、目的の関数を見つけたらcx definitionで関数本体を取得し、わずか 2 ステップで作業に取り掛かります。
対話履歴における「Read File」の呼び出し回数は明らかに減少し、セッション終了後のトークン使用量を確認しても、確実に大幅に低減していることが分かりました。
いくつか注意点があります。cx は構文解析に tree-sitter に依存しているため、理論的には多くの言語をサポートしていますが、それぞれに対応する文法を手動でインストールする必要があります。
cx が解決するのは非常に具体的な問題、つまり AI エージェントに対し「ファイル全体を読む」よりも安価なコード検索インターフェースを提供することです。ツール自体は複雑ではなく、導入も簡単ですが、その効果は疑いようのないものです。
プロジェクトURL:
https://link.bytenote.net/msDCNa