Claude CodeやOpenCode、Cursorなどのコーディングエージェントを日常的に使っているエンジニアに向けた内容です。トークン単価が下がっているのに月々のAI利用コストが増えている、実行のたびに結果が微妙に変わって困る、という状況に心当たりがあれば読み進めてみてください。
この現象には共通の原因があります。エージェントの「制御ループ」を誰が握っているかという設計判断です。制御ループとは、次に何をするか・いつ処理を終えるかを決める仕組みのことです。この主導権をLLM（大規模言語モデル）側に渡し切っている構成が、コスト増と再現性の低さの主因になっています。
何が起きるか：トークン単価は下がるのにコストは減らない
LLMのAPI料金は各プロバイダーの競争で年々下がっています。ところが、実際の運用コストが下がったと感じている現場は多くありません。
原因は「ハーネス」と呼ばれる仕組みの挙動にあります。ハーネスとは、LLMの周りに用意されたソフトウェア・UI・組み込みツール群のことです。Claude Codeのようなツールが提供する、ユーザーとLLMの間を取り持つ実行環境がこれにあたります。
ハーネスがトークン単価の低下を検知すると、より多くのトークンを消費する方向に振る舞いを変えることがあります。エージェントを追加で生成したり、モデルを呼び出すステップ数を増やしたりする形です。単価が下がった分を消費量の増加が相殺し、総コストはむしろ横ばいか増加する、という逆説が起こります。
もう一つの影響が再現性の低下です。同じ指示を与えても、LLMが自律的に手順を組み立てるため、実行のたびに異なる経路をたどることがあります。デバッグやレビューの再現が難しくなり、CI（継続的インテグレーション）に組み込みにくいという声にもつながります。
なぜ起きるか：制御ループの所有権という設計問題
この現象を理解するには「LLM-as-runtime」と「software-as-runtime」という2つの構成を区別すると分かりやすくなります。
LLM-as-runtimeは、スキルやコマンド、エージェント定義をLLM自身が解釈し、次に呼ぶツールや処理の終了タイミングまで判断する構成です。個々のツールは決定的（同じ入力なら同じ出力になる）でも、それを組み合わせる順序や回数はLLMの判断に委ねられます。現在市場に出回っているエージェント型ツールの多くがこの形です。
software-as-runtimeは逆に、通常のソフトウェアが全体の流れを制御し、判断が本当に必要な箇所だけLLMを呼び出す構成です。システム全体のトポロジー（処理の流れの構造）は決定的で、内部で使うモデルを変えても構造自体は変わりません。従来型のユニットテストや監視の仕組みをそのまま適用できます。
たとえるなら、LLM-as-runtimeはレストランの経営を天才シェフに丸ごと任せる状態です。接客も調理も会計もシェフの裁量で進みます。腕は良くても、日によって段取りが変わり、コストの見積もりが難しくなります。
software-as-runtimeは、マネージャー（従来型コード）が接客と会計を仕切り、調理が必要な場面だけシェフ（LLM）を呼ぶ形です。手前の設計コストはかかりますが、動きは予測可能でシェフ（利用するモデル）の交換も容易です。
業務用のエージェント基盤であるLangGraphやMastra、Salesforceの Agentforceなどは、この決定性と非決定性を使い分ける設計を既に採用しています。開発者が「どこでLLMを呼ぶか」を明示的に選べる構成です。一方でローカル開発者向けのハーネス選びの議論は、いまだに「どのハーネスが一番賢いか」というベンチマーク比較に偏りがちです。本来問うべきは「そもそも制御をLLMに渡すべきかどうか」という設計判断です。
自分のプロジェクトが該当するか確認する方法
手元の開発環境がどちらの構成に寄っているか、次の観点で確認できます。
- 使っているツールの設定ファイル（Claude Codeなら
CLAUDE.mdやエージェント定義、OpenCodeなら設定用のYAML）を開き、処理の分岐や終了条件がLLMへの自然言語指示だけで書かれていないか確認する - ログや実行トレースを見て、同じタスクを2回実行した際にツール呼び出しの回数や順序が毎回異なるかどうかを比較する
- 月次のAPI利用料の推移を確認し、単価改定があった月の前後でトークン消費量（リクエスト内のトークン数）が増えていないかを見る
- CIパイプラインにエージェントを組み込んでいる場合、同一コミットに対する実行結果が毎回同じ差分になるかを確認する
- エージェントが呼び出すサブエージェントや自動生成タスクの数に上限設定があるかを確認する（上限がなければLLMが際限なくステップを増やせる状態）
これらのうち複数に心当たりがあれば、制御ループの大部分をLLMに委ねているLLM-as-runtime寄りの構成だと判断できます。
対策の手順
対策は「全部を作り直す」のではなく、部分的にsoftware-as-runtime側へ寄せていく形が現実的です。
# 1. 現状のエージェント実行ログをエクスポートし、
# ツール呼び出し回数の分布を確認する（ツールが対応していれば）
claude --print --output-format=json "タスク内容" > run1.json
claude --print --output-format=json "タスク内容" > run2.json
diff run1.json run2.json実行結果の差分が大きい場合、判断を要する箇所とルーチン処理の箇所を切り分けます。
- ファイル操作・APIコール・テスト実行など決定的にできる処理は、通常のスクリプトやCIジョブに切り出す
- コードレビューの観点出し、設計方針の提案など判断力が要る部分だけをLLM呼び出しとして残す
- LangGraphやMastraのようなオーケストレーション用フレームワークを使い、ステップごとに決定的な処理とLLM呼び出しを明示的に分離する
- サブエージェントの生成数やステップ数に上限を設定できる設定項目がないか、使用ハーネスのドキュメントを確認する
- 月次コストをトークン単価だけでなく「タスクあたりの総トークン消費量」で追跡し、単価低下時に消費量が増えていないかを継続的に見る
ハーネスの乗り換えを検討する際も、単純な性能比較ではなく「制御ループをどこまで自分のコード側に残せるか」を選定基準に加えると判断がぶれにくくなります。OpenCodeのようなオープンな実装は、内部の制御フローを確認・改造できる点で、この観点からの評価がしやすいツールです。
まとめ
トークン単価の低下が総コスト削減に直結しない背景には、ハーネスがLLMに渡す制御ループの広さがあります。
まず自分の開発環境の設定ファイルと実行ログを見直し、LLM-as-runtimeとsoftware-as-runtimeのどちらに寄っているか確認してみてください。
決定的に処理できる部分は通常のコードやCIジョブに切り出し、判断が必要な箇所だけLLM呼び出しとして残す設計に寄せていくと、コストと再現性の両方を改善しやすくなります。
ハーネスの選定基準を「賢さの比較」から「制御ループの所有権」に切り替えることが、次の一歩になります。