コーディングエージェントの請求書が倍増した。修正方法はこちら。

先週、ある中堅スタートアップのエンジニアリングリーダーが、チームのコーディングエージェント請求書が2四半期で6倍に増加したと語りました。作業が6倍難しくなったわけではなく、誰も監視していなかったからです。Uberは2026年のAI予算全体を4ヶ月で使い切り、Microsoftは部門をまたいでClaude Codeのライセンスをキャンセルし、Salesforceは3億ドルのAnthropic請求書に直面しています。

2026年初頭、コーディングエージェントの使用が爆発的に増加し、チームは支出を進歩の証として祝い始めました。より多くのトークンを消費することは、より多くの作業が完了し、より多くのレバレッジが得られ、AIへの賭けが報われている証拠を意味していました。しかし、わずか数ヶ月後には、請求書が急騰し、コスト管理がAIワークロードの拡大にとって重要になるにつれて、状況は一変しました。

では、支出をどこで削減するかを見極めるにはどうすればよいでしょうか？単一の機能でも、Claude Codeによる初期実装、Cursorによるインライン編集、Copilot Chatによるチームメイトのレビューなど、複数のツールが関与する可能性があり、各ツールは独自の形式でアクティビティを記録します。「この機能を構築するのに実際にいくら使ったのか、そしてそれは価値があったのか？」と尋ねると、ほとんどのチームは答えることができません。これこそが「トークンマキシング」がフェーズから負債に変わる瞬間です。支出に見合った成果が得られているかを確実に評価する方法がなく、測定単位が相互に通信しないツール間で分散しているからです。

実際の問題は断片化であり、データの欠如ではありません。すべてのコーディングツールは何らかのコスト可視性を提供します。CopilotはOpenTelemetryスパンを出力し、OpenCodeはセッションフックを提供し、Piには拡張機能があり、Cursorはフックを使用します。しかし、Claude Codeでのツール呼び出しとCursorでのツール呼び出しは同じように記録されないため、それらを並べて比較し、どちらが同じコストでより多くの作業をしているかを判断することはできません。

可視性から制御へ：チームと詳細に検討した結果、パターンが浮かび上がりました。解決策は単一の問題ではなく、サイクルの一部であるということです。まず、支出の可視化：5つの異なる形式のダッシュボードの代わりに、チームが実際に使用しているすべてのコーディングエージェントにわたる一貫したビューが必要です。LangSmithは現在、Claude Code、Codex、Cursor、GitHub Copilot Chat、Pi、OpenCodeからのセッションを同じトレースモデルにトレースします。同じメタデータ、同じクエリ構文で、どのツールがセッションを実行したかに関係なく使用できます。「どのセッションが高コストだったか？」という質問に対して、1つの答えを得ることができ、5つの部分的な答えを得る必要はありません。

次に、ツール間のコスト標準化：セッションを並べて比較できるようになれば、正直に比較できます。トークン使用量、セッションあたりのコスト、ツール呼び出し数、サブエージェントアクティビティがツール間で正規化され、特定のワークフローでCursorやClaude Codeが同じコストでどれだけの作業をしているかをようやく把握できます。

第三に、使用の最適化：データを確認することで最適化が可能になりますが、ほとんどのチームは、すべてのセッションを手動でレビューして無駄を発見する余裕がないため、行動に移しません。ここでEngineが登場します。Engineはエージェントのセッションを分析し、具体的なスキル改善の提案を提示します。これは、シニアエンジニアがエージェントが生成したすべてのPRをレビューする時間があれば提案するであろう改善です。たとえば、エージェントが同じコンテキストを取得するために複数回冗長なツール呼び出しを行っている場合、Engineはそれをフラグし、統合を推奨します。支出が高いことを示すダッシュボードの代わりに、何を変更すべきかという具体的な推奨事項が得られます。

第四に、支出のガバナンス：当社のLLM Gatewayは、ユーザー、チーム、組織レベルでコスト上限とガバナンスを実施し、まもなくオープンソースモデルへのルーティングを可能にします。オープンソースモデルは十分に優れており安価になったため、すべてのエージェントハーネスにおいてオプションとして存在すべきです。フロンティアモデルをすべての場所で置き換えるのではなく、フロンティアインテリジェンスを必要としないほとんどの作業のデフォルトとして。サブエージェントについても同様で、安価なモデルが範囲の明確なサブタスクを処理することで、スマートモデルが単純作業にフロンティアレベルのコストを費やすのを防ぎます。

各段階が次の段階を可能にします。可視性は最適化すべき場所を示し、最適化はガバナンスが最も厳しくあるべき場所を示し、ガバナンスは利益を保護し、次の可視性ラウンドが新しい無駄ではなく実際の進歩を示すようにします。

このソリューションは、複数のコーディングエージェントを実行するチーム向けに設計されています。顧客からのフィードバックに基づくと、ほとんどのチームは導入後数ヶ月以内に複数のツールを使用するようになります。組織が完全に単一のツールに標準化しており、そのツールのネイティブダッシュボードがすでに質問に答えている場合は、まだ第2層は必要ないかもしれません。しかし、2番目のツールが追加された瞬間、ネイティブダッシュボードは「すべてのツールにおいて、お金はどこへ行っているのか？」という質問に答えられなくなります。

LangSmith for Coding Agents：初日から4つの部分すべてが必要なわけではありません。チームが初期導入段階にある場合、可観測性から始めるのが適切です。どのエージェントが実行され、何を費やし、どこでセッションが失敗しているかを把握してから、何を修正するかを決定する必要があります。その段階を過ぎて請求書のプレッシャーを感じ始めている場合、EngineとLLM Gatewayは同じトレースデータにプラグインできるため、「見える」から「修正して制限できる」への移行に際して、既存のインフラを解体する必要はありません。

設定後、コーディングエージェントのセッションは、他のプロダクションエージェント実行と同様に、LangSmithにトレースとして表示されます。統合に応じて、セッションには以下を含めることができます：ユーザーとアシスタントのターン、トークン使用量とコストを含むモデル呼び出し、ツール呼び出しとシェルコマンド、MCPアクティビティとサブエージェント呼び出し、エラーとタイミング。トレースは共通モデル（ルートセッション、ターン、ツール呼び出し、メタデータ）に正規化されるため、同じフィールドを使用してエージェント間でクエリを実行できます。session_id、thread_id、model、provider、ツール名でフィルタリングできます。高コストのセッション、失敗したツール呼び出しを見つけ、コンテキストを切り替えることなくCursorとCopilotの動作を比較できます。

はじめに：ツールごとに設定が異なります。Claude Code、Codex、OpenCode、Cursor、GitHub Copilot、Pi、dcodeの手順を見つけてください。私たちはこの問題を自ら経験したからこそ、これを構築しました。請求書は増え続け、どの作業が実際に支出に見合う価値があるのか明確な感覚がありませんでした。あなたのエンジニアリングチームは決して単一のエージェントに標準化することはありません（そして標準化すべきでもありません！）。なぜなら、彼らはタスクに最も適したものを選び続けるからです。可観測性は、彼らがいる場所で彼らに会わなければなりません：異なるエージェント、異なるイベント形式、しかしそれらすべてを理解するための一つの場所。LangSmithは、チームにすべてのコーディングエージェントにわたるセッションをデバッグおよび測定するための一つの場所を提供します。ツールを見つけて始めましょう。