サクティベル氏と共同開発者は、「Claude Code」や「Cursor」「GitHub Copilot」「Codex」など、複数のAIコーディングツールを日常的に利用していた。ある月、開発内容や利用するツールを大きく変えていないにもかかわらず、AIの利用料金が急増したという。

　利用状況を調べると、コストの大部分はAIコーディングツールが回答を生成する処理ではなく、モデルに大量のコンテキストを送信する処理から生じていた。

　あるプロジェクトで一般的な質問を調査したところ、AIコーディングツールは約4万5000トークン分のコンテキストを送っていた。しかし、実際に回答に必要だったのは約5000トークンで、残る約4万トークンは関係の薄いコードやファイルだった。

　同氏は、AIコーディングにかかる費用の約90％が、ファイルや検索結果などの入力に由来し、AIコーディングツールが生成するコードや説明文などの出力は約10％に過ぎないと説明する。

プロンプトや出力の短縮だけでは効果が限定的

　2人はまず、プロンプトに「短く答える」「関連するコードだけを参照する」といった指示を加えた。しかし、AIモデルが指示を読む時点では、既に大量のコンテキストが送信されているため、入力コストは削減できなかった。

　最大出力トークン数や温度などのモデル設定も変更したが、これらは主に出力内容を制御する設定であり、入力トークンの削減にはつながらなかった。

　回答を短くする「出力圧縮」では、出力トークンを75％削減できた。ただし、出力が費用全体に占める割合は小さいため、総費用の削減効果は約8％にとどまるという。

　そこで2人は、コードや検索結果をAIモデルの入力コンテキストとして送信する前の段階で、必要なコードだけを選び出すローカル検索インデックスを構築した。

コードを分割し、2種類の検索で必要な部分を選ぶ

　構築した仕組みでは、最初にコードを関数やクラス、メソッドといった意味のある単位に分割し、ローカル環境にインデックスを作成する。

　AIコーディングツールから質問を受けると、コードの意味を基に探す「意味検索」と、関数名などの文字列を探す「キーワード検索」を同時に実行する。

　意味検索は、表現が異なっていても関連するコードを見つけやすい。一方で、似た役割を持つ別の関数を誤って返すことがある。キーワード検索は関数名などの完全一致に強いが、「login」と「sign in」のように異なる表現を使ったコードを見逃す可能性がある。

　同氏らの検証では、どちらか一方の検索だけでは、必要な検索結果を約4回に1回見逃した。両方の結果を組み合わせることで、見逃しを約10回に1回まで減らせたという。

　さらに、検索結果として関数全体を送るのではなく、関数名や説明などに圧縮する。関数同士の呼び出し関係も記録し、検索で見つかったコードに関連する処理をたどれるようにした。

関連性の低いコードはAIに送らない

　検索結果には関連性を示すスコアを付け、一定の基準を下回るコードはAIモデルに送らない。関連性の低いコンテキストを渡すと、AIが誤った前提を基に、自信を持って間違った回答を生成する恐れがあるためだ。

　当初は、AIモデル自身に検索結果が適切かどうかを判定させた。しかし、質問のたびに2～3秒の遅延が発生した。

　固定のスコア基準を設定する方法も試したが、短い質問では正しい検索結果でもスコアが低くなる問題があった。

　最終的には、意味検索のスコアを50％、キーワード検索のスコアを30％、コードの更新時期を20％の割合で組み合わせ、検索結果に応じて基準値を変える方式を採用した。処理時間は0.4ミリ秒で、追加のAI呼び出しも必要ないという。

1回当たり8万3000トークンを4900トークンに削減

　2人は、オープンソースのWebフレームワーク「FastAPI」を使って効果を検証した。対象は53ファイルで、開発者が実際に尋ねることを想定した20個の質問を用意した。

　構築した仕組みを使わず、関連するファイルをそのまま送った場合、1回の質問当たり約8万3000トークンを使用した。一方、ローカル検索インデックスを利用すると約4900トークンとなり、入力トークンを94％削減できた。

　検索結果をさらに圧縮した場合は、1回当たり523トークンまで減少した。必要なコードを検索結果に含められた割合は90％だったという。

　実際のプロジェクトでは、247回の質問で約1240万トークンを削減した。削減量の84％は検索レイヤーによるもので、残りは検索結果の圧縮による効果だった。

94％削減は「最も差が出る条件」での結果

　ただし、サクティベル氏は、94％という削減率は、毎回ファイル全体をAIに送信する場合と比較した結果だと説明する。既存のAIコーディングツールも参照するコードを絞り込む機能を備えているため、実際の削減率は94％を下回る可能性がある。

　コードベースが大規模で複雑な場合にも課題が残る。396ファイルを含む大規模プロジェクトで検証したところ、検索の再現率は大きく低下した。

　1つのファイルが1つの役割を担うように整理されたコードでは検索しやすいが、1つのファイルに複数の機能が混在している場合は、関連コードを正確に抽出するのが難しくなるという。

　同氏らは検索速度を優先し、小型のモデルを採用した。再インデックスは1秒未満で完了する一方、大型モデルを利用すれば検索精度を高められる可能性がある。

複数のAIツールで同じコード情報を共有

　ローカル検索インデックスには、AIコーディングツール間でコンテキストを共有できる利点もある。

　通常、Claude CodeやCursor、GitHub Copilotなどは、それぞれが独立してコードベースを調べる。ツールを切り替えるたびに、同じコードやプロジェクト構造を再びAIに読み込ませる必要がある。

　同氏らは、複数のAIコーディングツールが同じインデックスに接続できるようにした。あるツールがプロジェクトについて得た情報を記憶し、別のツールや次のセッションでも再利用する仕組みも追加した。

　サクティベル氏は、AIコーディングの費用を抑えるために、より安価なモデルを探すことだけに注目すべきではないと指摘する。

　どのAIモデルを選ぶかを議論する前に、AIにどのコードを、どれだけ送っているのかを確認する必要がある。必要な情報だけをモデルに渡す仕組みを整えることが、コスト削減と回答精度の両方を改善する鍵となる。

本稿は、AI Engineerが2026年6月29日に公開した動画「We Cut 94％ of AI Coding Tokens With a Local Code Index―Rajkumar Sakthivel, Tesco」を基に作成しました。