Claude Code、Codex CLI、OpenCode等のAIを使ったコーディングはすっかり一般的になりました。（※なおタイトル画像はAIに作ってもらいましたが、この文章は100%人間が書いています。）

一方でAIコーディング活用の壁は大規模言語モデル(LLM)利用のコストでしょう。私の周辺には$100/月(1.6万円)や$200(3.2万円)/月といったLLMのサブスクリプションにプライベートで加入している人がたくさんいますが、これはかなり例外的で、業務ならともかく趣味のコーディングならせいぜい数千円/月ぐらいが現実的な範囲だと思います。

この投稿ではOpenCodeで安価にAIコーディングをはじめる – おすすめ構成($0～$30/月)で紹介したパターンのうち、$10/月、$30/月のパターンを例に、どのように節約する(＝トークンの消費を抑える）のが良いかというのを自分の経験（実践）の範囲で説明します。

また、昨今はサブスクリプションの値上げ、もしくは利用量の縮小の傾向があり、$100/月プランを利用の方でもトークンを節約する方法を知ることはメリットがあるかと思います。

費用を抑えるための考え方

費用を抑える方法としては、トークンを無駄にしないことと、LLM（モデル）の選択が考えられます。

従量課金のLLM APIサービスではトークン（≒LLMとの間でInput/Outputする情報量）に比例してコストが発生します。これはサブスクリプションでも同じで、多くのトークンを利用すると、5時間・週次といった制限に到達するのがより早くなります。そのためトークンを無駄に消費しないことは重要です。

ただし、キャッシュの考慮は必要です。多くの推論プロバイダ(LLMをサービスとしてAPIで提供している企業）ではキャッシュの仕組みがあり、キャッシュヒットした部分は安価に利用できます。つまりトークンが倍になったからといって費用が倍になるわけではありません。一般的にコーディングはキャッシュヒット率が概ね90%以上と言われています（私の経験上も90%以上になっていることが多いです）。

また、モデルの選択も重要です。以下はOpen AIのAPI料金表からの引用ですが、同じGPTでも、5.4と5.5では単価が異なりますし、5.4でもminiやnanoといった、性能は劣るものの安価なモデルが用意されています。キャッシュヒット時は単価が1/10ぐらいになっているのもわかります。

以下は DeepSeek V4 の料金表からの引用です。価格が2つありますが、左がDeep Seek V4 Flash （軽量モデル）、右がV4 Pro（高機能モデル）です。右は取り消し線があって読みづらいですが、これは本稿執筆時（2026/5/7)は、リリース直後のディスカウントが行われているためです。ただ、ディスカウント前の価格で（取り消し線の方で）見ても、GPTとは値段が全然違うことが分かると思います。一般的には著名企業の最先端モデルの費用は高めで、スタートアップの単価は低めです。もちろんモデルの性能が異なるので、安ければ良いという物ではないのですが、節約コーディングにはモデルの選択が重要であることが分かります。

モデル選択の例

基本的にはシンプル・簡単な処理には安価なモデルを積極的に利用し、複雑でどうしても必要な部分にだけ高度（高価）なモデルを利用するという考え方で利用するのが良いでしょう。多くの方は従量課金ではなく、月額固定のサブスクリプションを選択されると思います。前述の記事で書いたように、$30/月であれば、Chat GPT Plus ($20)+OpenCode Go ($10)、$10で納めるならOpenCode Goが現時点でのお勧めです。

利用可能な範囲で、1/複雑な作業（後述するプラン作成等）、2/メイン(コーディング)作業、3/軽量作業に分けてモデルを選択するのが良でしょう。つまり基本的には2のモデルを使い、必要なところだけ1を利用、小さい範囲のファイル修正といった軽量作業には3を利用します。

ChatGPT Plus + OpenCode Goの場合

この組み合わせの場合のお勧めは、以下の通りです。

1. 複雑な作業（プランニング、深い調査）： GPT-5.3-Codex OR GPT 5.4
2. メイン： GPT-5.3-Codex OR Kimi K2.6
3. 軽量作業：DeepSeek v4 Flash

複雑な作業はできるだけ最先端のモデルを活用したいところです。ただ以下のサブスクリプションプランのレート表からわかるように、5.3-Codexと5.4では消費クレジットが1.4倍違います。5.5との比較では2.85倍です。

各モデルは性能があがるにつれ、無駄な出力をしなくなりますので、この倍率がそのままクレジット消費に反映するわけではないのですが、個人的には$20/月のPlusプランでGPT-5.5を使うとあっという間にリミットに達してしまう印象の一方で、GPT-5.3-Codexは性能・価格比がとても良い印象です。5.3-Codexでうまくいかない時には5.4に切り替えています。

なお、GPTやClaudeの各モデルは、thinking (どれぐらい深く考えるか)を low / medium / high / xhighといった形で変更できますが、なんでもxhighにするのはお勧めできません。経験上ですがよっぽど複雑なケース出ない限りデフォルト(medium)で十分なケースが多いですし、長く考えた分だけトークン消費が大きくなる点にも注意が必要です。

また、意識して節約してもGPT Plusプランだと5時間制限にあたる事も多く、その場合はOpenCode GoのKimi K2.6を利用しています。OpenCode Goは利用できるモデルが多数ありますが、個人的にはKimi K2.6がコスト・パフォーマンスのバランスに優れていると感じました。コンテキストサイズ（どれだけ多くの情報を一度に処理できるか）が256KBで、マルチモーダル対応のため図を読むこともでき、汎用性が高いです。次の候補としてはDeepSeek V4 Proも良いですね。こちらはマルチモーダルではないのですが、コンテキストサイズが1MBあり、Kimi K2.6より安価です（より多く利用できます）。

軽量作業(3)は、OpenCode GoからDeepSeek V4 Flashが最適です。驚くほど安いので使っても全然Goの利用量が減っていかないのに、結構複雑なコーディングやデバッグにも耐えられる性能を持っています。利用するAIコーディングエージェントによりますが、スラッシュコマンド、サブエージェント単位で利用するモデルを指定できるものもありますので、それを活用して軽量作業には自動的に安価なモデルを適用しておくと良いでしょう。（OpenCodeでの例についてはこちらに少し書きました）。

なお、GPT PlusやGPT Proのみで利用する場合はGPT 5.4-miniを、Claude Pro/Maxを利用する場合はHaikuをこういった軽量作業に適用するのが良いでしょう。

OpenCode Goだけの場合

$10/月だけで本当にコーディングできるの？と思われるかもしれませんが、割り切って安価なモデルを積極的に使うことで十分にコーディングを楽しむことができます。以下はOpenCode Goホームページからの引用ですが、DeepSeek V4 Flashの単価の安さが光ります（バーが長いほどたくさん使える）。

$10/月の場合のお勧めは、以下の通りです。

1. 複雑な作業（プランニング、深い調査）： Kimi K2.6 OR DeepSeek V4 Pro
2. メイン： DeepSeek V4 Flash
3. 軽量作業：DeepSeek v4 Flash

DeepSeek V4 Flashは軽量モデルという扱いですが、驚くほどの範囲の作業がこなせます。プランだけはしっかりと別モデルで作成し、その後は全部DeepSeek V4 Flashに割り振ることでかなりの量のコーディングができます。

トークンを節約するためのツール

モデルの選択とは別に無駄なトークンを減らすことも重要です。世の中にはトークン消費（コンテキスト）をコンパクトにするためのツールやフレームワークが多数ありますが、個人的に利用していて効果を実感しているツールを紹介します。

coco-index code

coco-index code(ccc)は、ASTベースのセマンティックコード検索を実現するツールで、簡単にいうと事前にコードの構造を(Embeddingのモデルを使って)インデックスを作成しておき、効率的にコードを検索することを実現するものです。

経験上、ある程度コードベースができてくると、コンテキストの中はTool callの結果で埋まるようになってきます。これはコードを修正・追記するためにエージェントがgrepでコードを検索し、読み込むという行為を繰り返すことが理由の１つです。

cccは、事前にインデックスを作成しておくことでエージェントが ccc search "authentication logic" というようにインデックスから必要なロジックの箇所を瞬時に得ることができ、grepを繰り返してコンテキストを消費するという事を減らしてくれます。

昨今のAIコーディングツールはこういった検索をサブエージェントにやらせることで、メインエージェントのコンテキストを消費しない工夫がされているものが多いですが、それでもメインエージェントがgrepをすることをゼロにできませんし、何より検索速度があがることで全体の処理自体が短くなる効果があります。

インデックスの作成にはEmbeddingという処理を行えるLLMが必要なのですが、ごく軽量な（CPUで動く）モデルが内蔵されていますし、AWSやOpenAIがEmbed用のモデルを安価に提供しているので、費用面はほとんどかかりません。同様のツールは複数ありますが、個人的にはこのcccが使い始めるのも簡単でお勧めです。

RTK

RTK は、対応しているコマンドラインの出力からAIの処理に必要ない部分をカットすることで、tool callのコンテキスト消費自体を抑えるツールです。

多くのコーディングツールには/compactコマンドがあり、これを使うことでコンテキスト自体を要約してサイズを削減することができるのですが、あくまで要約なので細かい部分が失われます。また、キャッシュが効かなくなる点も不利です。

一方でRTKはAIに必要ない情報を与える前にカットするというアプローチなので、副作用が少ないところがメリットです。例えばgit statusを例にすると、以下のようになります。必要な意味だけにそぎ落とした感じになっているのが分かりますね。

#rtkなし
> git status
On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean
#rtkあり
>rtk git status
* main...origin/main
clean — nothing to commit

私の利用範囲だと (Rustの) cargo で節約効果が大きいです。cargo testの出力は結構大きいし、繰り返すためです。一方でRTKだけで劇的な削減効果が得られるわけではない点には注意が必要です。AIのコンテキスト消費は、コーディング時のファイルの検索と読み返しの方が圧倒的に多く、コマンドライン出力が主ではないためです。

Context7

後で書くSDDにもつながる話ですが、エージェントに無駄な処理をさせないことは、コーディング品質を上げるだけでなく節約の面でも重要です。つまり、適切な参考情報にすぐアクセスできるようにしておくという事ですね。

そういった事を補助するツールは多数ありますが、Context7は以前からの定番であり、現在でもとても有用なツールです。MCPを設定するだけでエージェントが最新の(OSSの)ドキュメントやAPI仕様を把握し、正確なコードを短時間で出力できるようになります。

MCP=コンテキスト消費が大きいと思われるかもしれませんが、Context7は去年末ぐらいの改善で大幅にコンテキスト消費が抑えられる形になっており、その意味でもお勧めです。

Spec-driven Development (仕様駆動開発)を適用する

Spec-driven Development (SDD)は、先に仕様（プラン）をしっかり固めたうえで、エージェントにその仕様そって開発させることで、安定した品質のコード生成を行うための手法です。AWSがKiroをリリースした事をきっかけに広く知られるようになり、多くのSSDフレームワーク・ツールが利用可能になっています。

どのSDDツール・フレームワークでも良いのですが、開発にSDDを適用することは結果的にトークン削減につながります。SDDは先に仕様を固めるためにそこでトークンを消費するのですが、その後のコーディングのところでエージェントの迷いが減ることで、コーディングの品質向上だけでなく、トータルでのトークン削減につながります。

また、前述の用途に応じたモデル切り替えとも相性が良いです。つまり仕様固め（プランニング）は、高性能なモデル(1)で行い、実際のコーディングやデバッグは(2)や(3)のモデルで行うという方法で、モデルを頻繁に切り替える必要もなくなります。

SSDのフレームワークは多数あるのでお好みのものをと思いますし、最初はコーディングエージェントに付属の”Plan”モードの利用でも問題ないと思いますが、私が使った範囲でお勧めできるのは以下の2つです。

• OpenSpec : コンパクトで理解がしやすく、すでに構築が進んでいるプロジェクトに途中から適用することにも柔軟に対応できます。
• cc-sdd:kiroを意識した形で作られたフレームワークです。やや重めのフレームワークですが、仕様固めの中でしっかりとバウンダリー（どこまで作るか作らないか）を定義し、TDDスタイルでの開発を行う形になっています。

どちらも先に仕様をしっかり固めるところでトークンを消費しますので、なんでも適用すれば良いという訳ではないです。シンプルな機能追加、修正であればいきなりエージェントに指示した方が、コストが安く済む場合があるため、使い分けが重要です。

まとめ

想定より長くなってしまいました。現在空前のAIブームということもあり、毎日のように便利なツールが生まれています。上記はあくまで私の経験の範囲でしかないので、ぜひ色々と試してみてください。

個人的にはもう少し踏み込んだトークン削除（剪定）ツールも今後試そうと思っています。キャッシュが無効化されることとのバランスではあるのですが、上記ツールを入れていてもやはりtool callの量がコンテキストの多くを占めているためです。

なにか良い効果を発見したら本稿を更新しようと思います。