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

※2026年8月21日更新

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

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

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

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

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

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

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

また、モデルの選択も重要です。以下はOpen AIのAPI料金表からの引用ですが、GPT 5.6の中でも、性能が高いsolと、性能は劣るものの安価なlunaといったバリエーションが用意されています。キャッシュヒット(Cached input)時は単価がそれぞれ1/10になっているのもわかります。

以下は DeepSeek V4 の料金表からの引用です。価格が2つありますが、左がDeep Seek V4 Flash （軽量モデル）、右がV4 Pro（高機能モデル）です。DeepSeek V4は先日の一般提供開始(GA)時に料金が値上げされたのですが、それでもGPTと比較して安価なことが分かります。一般的には著名企業の最先端モデルの費用は高めで、スタートアップは低めです。もちろんモデルの性能が異なるので、安ければ良いという物ではないのですが、節約コーディングにはモデルの選択が重要であることが分かります。

モデル選択の例

多くの方は従量課金ではなく、月額固定のサブスクリプションを選択されると思います。前述の記事で書いたように、$30/月であれば、ChatGPT Plus ($20)+OpenCode Go ($10)、$10で納めるならOpenCode Goが現時点でのお勧めですので、これを例にします。

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

なお本稿の内容からは外れますが、Claude Codeサブスクリプションのみで利用する場合は以下のような感じで考えると良さそうです。

1. 複雑な作業（プランニング、深い調査）： Opus 5
2. メイン： Sonnet 5
3. 軽量作業：Haiku 4.5

ChatGPT Plus + OpenCode Goの場合

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

1. 複雑な作業（プランニング、深い調査）： GPT-5.6 Sol or GPT-5.6 Luna or Kimi K3
2. メイン： GPT-5.6 Luna or GPT-5.6 Terra or Kimi K2.7 Code
3. 軽量作業： Mimo-V2.5 or DeepSeek v4 Flash

GPTをサブスクリプションで利用すると、以下のサブスクリプションプランのレート表に応じてクレジットが消費されます（数字が大きいほど利用可能枠の消費が速い）。以前は5.4-mini等をうまく使うことで安価に抑えるようにしていたのですが、5.4系は2026年8月末で利用できなくなることが予告されています。一方、これまではGPTのバージョンがあがるごとにAPI単価が上がってきていたのですが、GPT-5.6 SolはGA後に値下げされて5.5と同じになり、5.6 Lunaは大きく値下げされました。このため、現時点ではGPT-5.6 を中心に利用を計画するのが良さそうです。

各モデルは性能があがるにつれて無駄な出力をしなくなりますので、上記クレジットの倍率がそのまま消費に反映するわけではないのですが、値下げされたとはいえ$20/月のPlusプランでGPT-5.6 Solを繰り返し使うと、制限に達しやすい印象です。

そこで(1)では余裕がある時は5.6 Sol、もしくは5.6 LunaのThinkingを大きくして(xhigh等)利用、(2)はGPT 5.6 Luna か Terra を選択しつつ、うまくいかない時にSolやGPT以外のモデルに切り替えています。

なお、GPTやClaudeの各モデルは、Thinking (どれぐらい深く考えるか)を low / medium / high / xhigh / maxといった形で変更できますが、常にxhigh等にして利用するのはお勧めできません。私の限られた経験の範囲ではありますが、長く考えても良い結果が出るとは限りません。むしろ間違った方向で長く考えたことで、応答が遅くなり、トークン消費が大きくなる場合もあります。GPT-5.6 SolはMediumぐらいから試すのが良いでしょう。一方でLunaの方が安価なわりにはThinkingを大きくすることで顕著にクオリティがあがる印象で、(1)ではあえてxhigh等にするのが効果的に感じています。

このように意識して節約してもGPT Plusプランだと制限にあたる事がしばしばあり、その場合は(1)にはKimi K3を、(2)にはKimi K2.7 Codeを利用しています。OpenCode Goは利用できるモデルが多数あるので選択に悩むところですが、個人的にはKimi K2.7 Codeがコスト・パフォーマンスのバランスに優れていると感じました。コンテキストサイズ（どれだけ多くの情報を一度に処理できるか）が256KBで、マルチモーダル対応のため図を読むこともでき、汎用性が高いです。Kimi K3は極めて性能が高く、コンテキストも1Mあり、プランニングや複雑なデバッグに大変有用なのですが、OpenCode Goの中でも最も高い（クレジット消費が速い）モデルの1つなので、必要な時だけ利用する形にしています。

軽量作業(3)には、MiMo-V2.5が極めて安価でありながら、1Mコンテキストウィンドウ、マルチモーダル（画像認識）対応のため便利です。以前はDeepSeek V4 Flashもほぼ同様の費用だったのですが、GA時の価格改定で値上がりしてしました。しかし同時に性能も向上しているため複雑なコーディングやデバッグにも耐えられる性能を提供可能で、引き続きコストパフォーマンスは高いといえそうです。利用するAIコーディングエージェントにもよりますが、スラッシュコマンド、サブエージェント単位で利用するモデルを指定できる場合は、軽量作業には自動的に安価なモデルを適用しておくと良いでしょう。（OpenCodeでの例についてはこちらに少し書きました）。

なおDeepSeek V4の注意点として、（執筆時点では）中国でホストされているため、OpenCode Goの管理コンソールで中国リージョンでの推論を許可にしないと利用できません。また、ピーク時間帯に利用するとさらに費用が倍になります。詳細はこちらのドキュメントを参照してください。

OpenCode Goだけの場合

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

もっと安価なものとして、Muse Spark 1.2 Contributorがありますが、こちらは注意が必要で、このモデルを使う時には自分の入力をモデルの学習に利用することを許可する設定が必要です。これは将来のモデル開発の学習にそのデータをつかうことの対価として、Muse Spark 1.2の費用がディスカウントされているためです。また、Muse Spark 1.1/1.2は、こちらにあるように利用できない地域が設定されているのですが、日本はその制限外のため利用可能です。Muse Spark 1.2は各種ベンチマークでGPT-5.6 TerraやClaude Sonnet 5に匹敵する結果を出しており、価格に似合わぬ高い性能を備えています。学習に使われてもよい用途であれば、極めてコストパフォーマンスが高いモデルです。

補足：図にはOx Alphaという利用量無制限のモデルが記載されていますが、これは期間限定でリリース前のモデルを実質無料で使えるキャンペーンをやっていたためです。

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

1. 複雑な作業（プランニング、深い調査）： Kimi K2.7 Code or MiniMax M3 or GPT-5.6 Luna
2. メイン： DeepSeek V4 Flash or Mimo-V2.5
3. 軽量作業：DeepSeek v4 Flash OR MiMo-V2.5

DeepSeek V4 FlashはGA時に価格があがって以前のようなほぼ使い放題という使い方はできなくなりましたが、小型モデルの中では極めて広い範囲の作業がこなせるモデルです。プランだけはしっかりと別モデルで作成し、その後は全部DeepSeek V4 Flashに割り振ることでかなりの量のコーディングができます。制限が近づいてきた場合、もしくは中国で稼働するモデルが利用できない環境ではMiMo-V2.5を利用するのが良いでしょう。

データが学習に使われるために上記おすすめからは外していますが、利用上問題ないのであれば、1,2,3で全てMuse Spark 1.2 Contributorを使うのも、とても有効です。

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

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

coco-index code

coco-index code (ccc) は、ASTベースのセマンティックコード検索を実現するツールです。事前にコード全体のインデックスを作成しておき、効率的に検索することを実現します。

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

cccで事前にインデックスを作成しておくと、例えば認証ロジックがどこかを検索する場合はgrepするのではなく ccc search "authentication logic" というような形でcccを呼び出すことでロジックの箇所を瞬時に得ることができ、grepを繰り返したり、無駄なファイルを読み込んだりしてコンテキストを消費するという事を減らしてくれます。

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

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

RTK

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

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

一方で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の出力は結構大きいし、エージェントが開発の過程でtestを繰り返すためです。一方でRTKだけで劇的な削減効果が得られるわけではない点には注意が必要です。AIのコンテキスト消費は、コーディング時のファイルの検索と読み返しの方が圧倒的に多く、コマンドライン出力が主ではないためです。

また、強制的にrtkを挿入することによる副作用もゼロではありません。私はプラグインやトリガーでrtkを強制的にいれる方法ではなく、AGENTS.md等で利用を促すようにしています。この方法であればrtkの副作用を見つけた時にエージェントがrtk利用を回避できるためです。

Context7

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

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

MCPを使うとコンテキスト消費が大きいのでは、と思われるかもしれませんが、Context7は2025年末の改善で大幅にコンテキスト消費が抑えられる形にデザイン変更されており、コンテキスト消費をあまり気にせず利用できます。

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

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

SDDはエージェントとの会話を繰り返して仕様を固めるため、そこでトークンを消費するのですが、その後のコーディングのところではエージェントの迷いが減り、品質向上だけでなく、トータルでのトークン削減につながります。

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

SDDのフレームワークはそれぞれ特徴があるので、好みのものを試してみるのが良いと思いますし、最初はコーディングエージェントに付属の”Plan”モードの利用だけでも問題ないと思いますし、シンプルに導入できる”grill-with-docs“のようなスキルを使って計画を資料化するのも良いと思いますが、私が使った範囲でお勧めできるのは以下の2つです。

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

どちらも仕様がファイルとして残り、どこまで対応したか等もファイル上で管理します。そのため、仕様が決まったらいったんセッションを切り替え、新しいセッション（トークン消費していないセッション）で開発をすることができます。

もちろん、常にSDDを適用すれば良いというわけではないです。シンプルな機能追加、修正であれば、仕様を作るコストをかけずにエージェントに指示した方が安く・早く済む場合がありますし、最近のエージェントの性能向上により、プランなしでも十分なクオリティが達成できる用途が増えていますので、使い分けが重要です。

まとめ

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

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

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