コーディングエージェントのコスト管理：Claude Code、Codex、Geminiの支出を追跡

最初はコーディングエージェントを1つだけ使っていた。今ではClaude Codeが1つのターミナル、Codexが別のターミナル、Gemini CLIがさらに別のターミナルで動いている。それぞれが独自の方法で課金される。あるものはサブスクリプション、あるものは従量課金のAPIキー、そして先週ひっそりと無料枠から有料利用に切り替わったものもある。月末になると請求書が3通届き、それでも単純な問いに答えられない。先週の機能開発には、実際いくらかかったのか？

コーディングエージェントのコスト管理とは、エージェントの支出を、それを引き起こした作業に紐づけ、チームが使うすべてのツールにわたってその支出を可視化し、レビュー可能な状態に保つ実践のことだ。難しいのは、個々のエージェントのトークン単価ではない。価格は変わるし、各ベンダーが公表している。難しいのは、エージェントを2つ以上動かした瞬間に支出が別々の請求システムに断片化し、誰も金額をタスクやリポジトリ、担当者に結びつけられなくなることにある。

本記事では、各ツールのコストが実際どこから生じるのか、あなたが握るレバーは何か、そしてSharklyのような管理レイヤーが、すでに使っているツールから離れることなくタスク単位の支出をどう可視化し続けるかを解説する。Sharklyはエージェントの上位に位置する。Claude Code、Codex、Geminiのサブスクリプションはそのまま使い続けられ、各実行の記録はそれが属するTaskに戻される。

3つのエージェントを動かすとき、コスト管理とは何を意味するのか

エージェントが1つなら、コストは1つのダッシュボードから読み取れる数字だ。3つになると、コストは調整の問題になる。支出は現実に存在するが、決して突き合わされることのない3つの場所に分散している。AnthropicのClaude Code利用状況、CodexのOpenAI請求ページ、そしてGeminiのGoogle Cloudプロジェクトだ。

ここで明確にしておくべき境界がある。コスト管理はコスト削減とは違う。支出を減らすとは、使うトークンを減らすことだ。支出を管理するとは、トークンがどこへ消えたかを把握し、それが割に合ったかどうかを判断することだ。3つの機能を並行して出荷し、意図的に高額な月にすることも、支出を正しく紐づけ、誰かが承認していれば、依然としてコントロール下にある。

その紐づけこそが、欠けているレイヤーだ。複数のエージェントを動かすほとんどのチームは、AIの請求総額は答えられても、それ以上細かいことは言えない。どのリポジトリ、どのエンジニア、どのタスクがそれを招いたのかを答えられない。タスク単位で支出が見えなければ、コストの議論は推測になり、たいていの反応は、実際に予算を燃やしているツールではなく、たまたま見えやすいツールに上限をかけることになってしまう。

3つのツールのコストは実際どこから来るのか

どのエージェントも、課金対象はおおむね同じで、入力トークンと出力トークンだ。ただし請求モデルが十分に異なるため、予算の組み方も変わってくる。それぞれを最良の条件で比べても、どれかが単純に他より安いわけではない。作業の形によって、安くなるツールが違うのだ。

サブスクリプションモデルは限界費用を隠す。定額の月額プランは限界的には無料に感じられるので、エンジニアはしょっちゅう手を伸ばし、本当の問いは「これはいくらかかったか」から「プランの上限に達していないか」へと移り変わる。従量課金のAPIキーモデルは逆だ。どの実行にも見える価格がつくため、予算管理はすっきりするが、数セントを節約しようと有能なエージェントの使用を控えすぎる誘惑を生む。

1人か2人が日中を通して安定してエージェントを動かし、タスク単位の詳細よりも予測可能な請求を重視するなら、サブスクリプションプランを使うとよい。支出を正確に紐づけたい、自動化の中で動かしたい、あるいは合計に対して誰かが責任を負う必要があるチームに作業を分散させたいなら、従量課金のAPIキーを使おう。多くのチームは最終的に両方を使う。だからこそ、単一の突き合わされたビューが重要なのだ。どのエージェントにどの仕事を任せるかを選ぶなら、ベンダーを切り替えるより、タスクにモデルを合わせることのほうが請求額に効いてくる。

あなたが実際に握る3つのレバー

ベンダーの価格はレバーではない。ターミナルから交渉することはできない。本当にあなたの手の中にあるものは3つあり、それらは表示価格よりずっと重要だ。

コンテキストの規律。 最も大きな回避可能コストは、エージェントがすでに持っていたコンテキストを再送することだ。毎ターン、コードベース全体を読み直すエージェントは、毎ターンそのコードベースの分を支払っている。実行間でコンテキストを永続化し、エージェントがそれを再構築するのではなく現在の状態から始められるようにすることが、たいていは最大の節約になる。これはコードベースメモリとそのトークンコストの背後にあるのと同じ仕組みだ。保持したものは、買い直さずに済む。

モデルとタスクのマッチング。 1行の名前変更を重い推論モデルに回すのは金の無駄で、アーキテクチャのリファクタリングを小さく速いモデルに回すのは午後1日の無駄だ。節約は、あらゆる仕事を最も有能なエージェントにデフォルトで任せるのではなく、モデルをタスクに合わせることから生まれる。

並列性の境界。 エージェントを並列で動かすことが、実際の成果の伸びが最も大きいところであり、同時に支出が最も速く膨らむところでもある。5つのエージェントが同時に働けば、実時間あたりのコストはおよそ5倍になる。5つのタスクが準備できていて、やる価値があるなら問題ないし、そのうち3つが投機的だったなら高くつく。レバーは「エージェントを減らせ」ではない。始める前に、どの作業が並列の枠に値するかを決めることだ。並列で動くコーディングエージェントを監視することが、その決定を当て推量から、擁護できる判断へと変える。

チーム規模別の判断表

コストの方程式は、調整する人数とエージェントの数によって変わる。1人の開発者にとって問題ないことが、プラットフォームチームにとっては負債になる。

もし独りで、1つのターミナルと1つのエージェントで快適にやっているなら、コストを抑えるのに管理レイヤーは必要ない。あなたのダッシュボードがすでに必要なことを教えてくれている。方程式が変わるのは、支出が単一のビューの枠を超えたときだ。複数のエージェント、複数のリポジトリ、そしてあなた以外の誰かが責任を負わねばならない予算。その時点で問いは「どのエージェントが一番安いか」ではなく「全体像を見て判断できるのは誰か」になる。

タスク単位の支出を可視化する

これがSharklyが作られたレイヤーであり、それが何をして何をしないかは正確に述べておく価値がある。Sharklyは請求ツールではなく、Claude Code、Codex、Geminiを置き換えるものでもない。モデルの利用は、それらのツールで設定したサブスクリプションやAPIキーを通じて続く。サブスクリプションは各自で持ち込む。Sharklyが加えるのは、それらを囲む共有の記録だ。すべてのエージェント実行はTaskの中で行われ、実行、進捗、ブロッカー、結果はそのTaskに戻され、チームがそれを見られる。

この共有の記録が、コストを読み解けるものにする。各実行がオーナーとリポジトリを持つTaskに紐づけば、支出は匿名の月次合計ではなくなり、指し示せる一連の意思決定になる。どの作業が、誰のComputer上で、どの予算に対して、リクエストからリリースまで動いているかが見える。コーディングエージェントのダッシュボードで何が動いているかが見えるかどうかは、支出を管理することと、請求書が来てから気づくことの違いだ。

人間とエージェントの契約はここでも成り立つ。エージェントは調査し、実行し、テストし、報告する。人間は方向性を定め、権限を与え、その支出が結果に見合ったかを判断する。自動化はチームの判断が必要なところで止まる。コストにとってそれは、5つのエージェントの並列実行が正当化されるかを、開始前にスクリプトではなく人間が決めるということだ。

請求を単純化するために1つのエコシステムにコミットするのではなく、複数のコーディングエージェントを使い続けたいなら、それこそがSharklyが想定して設計された課題だ。既存のコーディングエージェントをSharkly経由で動かし、各実行のコストを、それを引き起こしたタスクに戻そう。