
データエンジニアだったりデータアナリストだったりします。 @kazasiki です。
みなさんAgentic Codingしてますか?LLMやAI Agentにコードを生成・調査させる場合、トークンの使い過ぎはなかなか怖いものです。 そこで今回はトークンを節約するための各種ツールや手法について調べましたので、紹介したいと思います。
正直、自分はそこまでトークンを使いすぎることはありません。考え方の整理として調べたもので、節約量の定量比較まではしていません。節約量はユースケースによります。ただ、困りごとに直面したときにどういった手法があるかを知っておくと参考になるので、ぜひこの記事を皆さんの道具箱に入れておいて頂ければと思います。
(本記事で紹介するツールは筆者の個人的な調査・利用体験であり、パーソルキャリアとしての推奨を意味するものではありません。)
この記事では各ツールや手法の詳細には触れず、簡単な説明のみに留めます。使ってみるのが一番早いので、ぜひ個別のリポジトリを開いて、実際に使ってみることをお勧めします。
アプローチの分類
分類は私が勝手に考えたものですが、ここではざっくり以下の5つに分けて説明します。
- ローカル検索の改善
- 機械的な省略
- AIモデルによる要約
- プロンプトキャッシュの改善
- プロンプトの工夫
ローカル検索の改善
基本的に、Coding Agentはまず依頼されたタスクに関係するコードをリポジトリの中から探します。大抵の場合はgrepで難なく探せますが、コードベースが大きくなるほど探しているものを見つけることが難しくなり、それに伴ってトークンの消費量も増えていきます。なので、トークン節約のアプローチとして、まずローカルでのコード検索の改善を検討します。
sembleはCoding Agent向けのコード検索ツールです。概要としては、Tree-sitterを使ってコードをパースして、ローカルで動かせるコード専用の小規模な埋め込みモデルを使って意味的検索を実現します。また、API名などの識別子に対する語彙的一致の検出をBM25を用いて行います。(それぞれの用語や仕組みを解説すると長くなるのでリンクを貼るに留めます)
codegraphも同様にCoding Agent向けのコード検索ツールです。こちらはローカルにコード専用のグラフDBを構築して検索の効率化を図ります。メソッドコールや依存関係などをグラフDBとして構築し、修正時の影響箇所などを高速に検索できる状態にします。
特徴としてはやはりローカルで完結しているところです。上記で紹介した技術は、検索などの技術に明るい方であればお馴染みのものでしょう。ただ、これをCoding Agent向けのツールとしてローカルで動かすのは面白いアプローチです。README上の導入手順は短いので、大規模なリポジトリを日常的に触る方は一度試してみるとよいでしょう。
機械的な省略
例えば、1万行くらいの大きなCSVがある場合、Coding Agentにそれをそのまま渡すのは多くの場合で非効率です。まずは、カラムと先頭50行くらい渡して概要をつかんでもらって、必要に応じてpandasやDuckDBなどで必要な部分や集計値だけ抽出させるのが効率良さそう、というのをイメージしやすいと思います。
このように特にLLMなどを使わずに機械的な方法で情報を省略してCoding Agentに渡し、必要に応じて必要な要素だけクエリなどで抽出してもらうというのはかなり汎用的なアイデアです。
Headroomは、Netflix所属のエンジニアが個人としてOSS公開し話題になったコンテキスト圧縮ツールです(Netflix公式ではありません)。中ではさまざまなことを行っていますが、その一部としてJSONやソースコードの圧縮/省略があります。
JSONについては例えば長い配列であれば最初のN件のみを取得する場合や、配列中の数値データであれば異常値が含まれるレコードを抽出して後は省略するなど様々な工夫がされています。ソースコードについてはTree-sitterを使って関数のシグネチャやimport文のみを抽出するなどを行います。
axは同じような考え方でcurlのレスポンスを省略する機構を持ったツールです。HTMLの繰り返しをN件以降は省略する、セレクタを指定して必要な情報を抽出するなどの機能を備えています。
そんなに省略してよいのか?という気もしますが、Coding Agentが必要に応じて元のデータを参照できれば特に問題ないと判断しているようです。
AIモデルによる要約
機械的な省略が有用なら、AIモデルによる要約も当然に選択肢に入ります。
先ほど紹介したHeadroomはローカルモデルを使ったテキストの要約を機能として備えています。しかも入力プロンプトの内容を加味しつつ、対象のテキストファイルを要約します。これは、ローカルモデルで大きなテキストの必要箇所だけを抽出しているとも言えます。
同様に、Headroomは画像の圧縮も行っています。これは画像の圧縮自体をモデルで行うのではなく、プロンプトを見て、どれくらいの解像度に圧縮するのかを決めているという形です。ドキュメントでは、画像に対して「これは何ですか?」くらいの質問なら小さく圧縮して送ってみて、「文字起こしをして」なら高解像度を維持するといった例が紹介されています。
これも、そんなに省略してよいのか?という気もしますが、先ほどと同様の判断をしているということになります。
プロンプトキャッシュの改善
主要なLLMプロバイダは、入力トークンのキャッシュ(Prompt Caching)を提供しています。これは、プロンプトに対するレスポンスをキャッシュするのではなく、プロンプトをモデルが解釈する際の中間計算結果を再利用する仕組みです。キャッシュヒット時は入力トークン料金が大幅に割引されることが多く、処理時間も短縮されます。方式や割引率、料金体系はサービスによって異なりますが、コストと性能の両面で非常に重要な仕組みです。
OpenAIやAnthropicでは、プロンプト先頭の一致(前方一致)がヒット条件になることが多く、コンテキストに入れる情報の並びを変えないことが重要です。例えば、システムプロンプト、共通ルール、ツール群の定義などはコンテキストの最初の方に入れて、それを頻繁に変更しないなどの工夫が必要です。Googleなど明示的なキャッシュAPIを持つサービスもあり、方式は一様ではありません。基本的にはCoding Agent側でよしなにやってくれていますが、多少は意識しておいたほうが良いでしょう。
Headroomにはキャッシュ最適化の仕組みがありますが、これ自体は最適化というよりは最適化を補助するためのメトリクスを提供するような機能です。
プロンプトの工夫
トークンを無駄遣いしないようにプロンプトで工夫することもできます。細かい話をここに書くと長いので、さくっと以下の記事を参照します。
似たようなアプローチで、プロンプトでCoding Agentの内部的な推論や出力の傾向を弄ることでトークンを節約しようとする方法もあります。有名どころはcavemanとponytailなどのAgent Skillです。
cavemanはその名の通り原始人風に話させることで冗長な文章を減らし、トークンを節約しようとするものです。効果のほどは懐疑的になりがちですが、確かに出力は短くなります。ちなみにSKILL.mdに書かれたプロンプトは "Respond terse like smart caveman. All technical substance stay. Only fluff die." で始まります(賢い原始人のように簡潔に応答せよ。技術的な中身は残し、無駄な言葉だけ消す、という趣旨)。
ponytailも似たようなアプローチで、熟練エンジニアっぽいキャラづけで、特にコーディングにおいて無駄を省き、短く簡潔な実装をするようになります。これは自分も使っていて、ponytail-reviewというAgent Skillで定期的にコードレビューをしてもらい、結果を参考にしています。
どちらもSKILL.mdの内容自体は短く、こんな短いプロンプトで本当に意味があるのか?と思うほどです。一度目を通してみるとよいでしょう。
ただ、cavemanやponytailについては批判もいくつか存在します。まず、『簡潔に』など広範な指示で返答のスタイルを設定することにLLMベンダは注意を促しています。GPT-5.6のプロンプトベストプラクティスにも明確に書いてあります。
GPT-5.6はデフォルトではGPT-5.5よりも簡潔な傾向があります。移行時には、「簡潔に」「短くまとめて」といった広範な簡潔性指示が依然として有用かどうかを確認してください。タスクによっては不要になり、応答が短くなりすぎる場合もあります。(筆者訳)
基本的にはモデルが賢くなれば必要十分の返答をするようになるはずだというのと、特定のスタイルを求める場合はもっと具体的な指示を書く必要があるということです。多くの利用場面では、必要以上に長い出力は求められません。ベンダ側もその前提でデフォルトを調整している、と読むことができます。こういった事情を踏まえたうえで、モデルを移行する際はまずAgent Skillを入れずに試してみて、そのあとにAgent Skillを入れて試してみるというステップを踏むとよいでしょう。
おわりに
これらの概念は様々な応用が考えられます。
例えば、先日自分の個人ブログの記事を分析しようと思って大きなMovable Typeファイルを扱いました。このファイルをそのままCoding Agentに渡すのはよろしくありません。なので、まずは記事毎に分割したり、タイトルを抽出したりするスクリプトを生成してもらいました。タイトル一覧を抽出することも可能ですし、特定のタイトルの本文だけ抜き出すこともできます。そういう風に無駄に全体を読まないように工夫できる土台をまず作るのです。
少しは参考になりましたでしょうか?人間が無意識でやっているような効率化をAIに教え込むみたいで面白そうだなと思っていただければ幸いです。
出典
(2026年8月13日閲覧)
- MinishLab「semble」https://github.com/MinishLab/semble
- colbymchenry「codegraph」https://github.com/colbymchenry/codegraph
- headroomlabs-ai「headroom」https://github.com/headroomlabs-ai/headroom
- Yusuke Wada「ax」https://github.com/yusukebe/ax
- JuliusBrussee「caveman」https://github.com/JuliusBrussee/caveman
- DietrichGebert「ponytail」https://github.com/DietrichGebert/ponytail
- Tree-sitter Project「Tree-sitter」https://tree-sitter.github.io/tree-sitter/
- Wikipedia「Okapi BM25」https://ja.wikipedia.org/wiki/Okapi_BM25
- Headroom Docs「Cache optimization」https://headroom-docs.vercel.app/docs/cache-optimization
- Google Cloud「AI トークノミクス ガイド: トークン効率の高いソフトウェア エンジニアリングのための 11 の原則」https://cloud.google.com/blog/ja/topics/developers-practitioners/guide-to-ai-tokenomics-eleven-principles-for-token-efficient-software-engineering/
- OpenAI「Using GPT-5.6」Prompting best practices https://developers.openai.com/api/docs/guides/latest-model#prompting-best-practices

@kazasikiさんのプロフィール
データ・AIインフラ統括部 AIプラットフォーム部 AIインフラ・アーキテクトグループ シニアエンジニア
バックエンドエンジニア。VRゲームとダンスミュージックが好き。都内のクラブによく行く。
※2026年8月現在の情報です。

