2．コスト最適化の第一歩は、AIの利用状況の可視化

コストを最適化するには、まず利用状況を把握する必要があります。ただし、ここで重要なのは「どれだけ使ったか」を知るだけでなく、「何が費用を押し上げているのか」まで分解して捉えることです。

当初、手元にあったのは社内で提供されていた利用者別・モデル別の日次レポートでした。誰の消費量が大きいかは分かりますが、どの作業のどの処理でクレジットを消費しているのかまでは分かりません。この粒度の情報だけで対策を考えると、効果的な改善にはつながりません。

そこで、VS Codeのエージェントデバッグログを解析しました。このログには、モデルに送った情報や応答に加え、入力・出力・キャッシュのトークン数、クレジット消費量などが記録されています。ファイル読み込みやツール実行の前後関係と照らし合わせることで、どの処理で消費が増えたのかを追跡できます。アプリケーションの性能問題を調べる際に、処理の流れをたどってボトルネックを探すのと同じ考え方です。

例えば、あるテストケース生成コマンドは、1回の実行で1,500AIクレジットを消費していました。内訳を調べると、設計書の読み込みやテストケースの出力だけでなく、共通指示の読み込みや会話履歴の要約も費用に影響していました。画面上では1回の依頼に見えても、内部ではモデルが何度も呼び出されていたのです。

このように処理単位で分解することで、成果物の品質を確保するために必要な消費と、削減可能な消費を区別できるようになります。また、各プロンプトが具体的にどのようにAIクレジットを消費するのかの構造も把握することができます。他の開発現場で取り組む場合も、まずは費用の大きい代表的な処理を1つ選び、入力・出力・キャッシュの内訳を分析することで、どの処理でAIクレジットが多く消費されているかを確認することをお勧めします。

3．品質を維持しながらコストを最適化する3つのポイント

ログの分析から見えてきたのは、品質を高めるために重ねてきた工夫や、作業を続けやすくするための機能が、意図せず費用を押し上げていたことです。ここでは、効果のあった改善を3つのポイントに整理して紹介します。

3-1．AIに渡す情報を、作業に必要な範囲に絞る

見直し前のエージェントでは、開発ルールを守らせるため、共通の指示ファイルに多くの注意事項を記載していました。正確な成果物を生成し、テストの抜けを防ぐために、過去に見つかった問題を指示ファイルに書き足していました。品質を重視するうえでは自然な工夫ですが、その結果、指示ファイルは合計約250,000文字まで膨らんでいました。また、指示ファイルの中身は適用対象外の指示もすべて入力トークンとして課金対象になっていました。改善方法について試行錯誤を重ね、個別作業の指示を整理し、それぞれの作業を担うエージェントへ移し、オンライン処理とバッチ処理のように必要な情報が異なる作業ごとにエージェントを分けました。

この対策が有効だったのは、共通指示がすべての呼び出しで毎回入力される情報だからです。1回当たりの消費量は小さくても、モデルの呼び出しを繰り返すことで、トークン消費量が積み上がります。費用を減らす際は、まず「毎回送られている情報」から見直すと効果を得やすくなります。また、ツールの設定が想定どおりに動いているとは限らないため、ログで実際の挙動を確かめることも欠かせません。

なお、何を共通ルールとして残し、何を個別のエージェントに持たせるかの判断には、開発工程と成果物の関係を理解することが必要です。指示を分散させると変更時の管理が複雑になるため、保守性とのバランスは今後の課題です。

3-2．会話履歴と出力の内容を見直す

長い作業を一つの会話で続けると、履歴がモデルの扱える情報量の上限に近づき、履歴を要約して圧縮する処理が行われます。利用者にとっては作業を継続するための機能ですが、要約にもモデルへの入力と出力が発生します。ログを見ると、この要約処理が無視できない消費になっていました。

そこで、渡す情報や出力内容を整理するとともに、モデルが一度に参照できる情報（コンテキスト）の上限を拡大する方法も検証しました。ある検証では、会話履歴の要約処理にかかっていたトークン消費をなくすことができました。ただし、情報を大量に保持するほど安くなるとは限りません。入力の単価、キャッシュの利用状況、処理全体の長さを合わせて評価する必要があります。

出力についても、プロジェクト側と相談し、重複したテスト観点を削除するとともに、後工程で使わない説明の出力を抑えるよう見直しました。ここでのポイントは、個別の処理の削減量ではなく、タスク全体の費用と成果物の品質で効果を判断することです。要約処理の消費が減っても、タスク全体の費用が増えては意味がありません。また、どの出力を残すべきかについては、システムの仕様や品質要件を理解していなければ判断できません。生成AIの設計を担う側と開発現場が一緒に検討することが、品質を落とさない削減につながります。

3-3．エージェントの実行方法を、キャッシュと繰り返し処理の観点で見直す

AIクレジット方式では、入力・出力・キャッシュの3種類のトークンが、それぞれ異なる係数でAIクレジットに換算されます。キャッシュの換算係数は通常の入力よりも小さいため、キャッシュが利用されずに新規の入力として扱われてしまうと、AIクレジットの消費量が増えることになります。

分析の結果、専門のサブエージェントが長時間動作した後に親エージェントへ戻ると、キャッシュが利用されず、再び通常の入力として扱われるケースが見つかりました。そこで、依存関係のないサブエージェントを並列実行し、親エージェントが処理を再開するまでの時間を短くしました。

また、ビルドとエラー修復を自動で繰り返す処理の範囲も見直しました。ビルドの実行自体は単純でも、大量のログをモデルへ渡し、修正して再実行する流れではトークン消費が積み上がります。そこで、定型的な操作を手順化し、どの場面でAIの判断が必要かを整理しました。

エージェントの費用は、役割分担だけでなく、実行順序や待ち時間、繰り返し方によっても大きく変わります。AIに判断させるべき部分と手順で済む部分を切り分け、実行の流れまで含めて設計することが重要です。

これらの改善を組み合わせた結果、個別のコマンドでは次のような削減効果を確認できました。

表1：個別コマンドの改善例

※単位は1回のコマンド実行当たりのAIクレジット。削減率は掲載値から算出。複数の施策を組み合わせた個別の検証結果であり、資材や実行条件によって効果は異なります。

一方で、さらなるコスト削減のために安価なモデルへの切り替えも試しましたが、必要な出力品質を満たさず、採用を見送ったものがあります。1回当たりの費用が下がっても、成果物の確認や修正の手間が増えれば、開発全体では負担が大きくなります。削減率だけで判断せず、品質と生産性への影響を合わせて評価したうえで、採用する対策を選ぶことが大切です。

4．技術的な改善だけでは解決できないコスト管理

エージェントの改善によって一定の削減効果が得られました。しかし、プロジェクト全体の日々の消費量は減少したものの、目標とする水準までは下がりませんでした。

コマンドの実行ログと利用者別のレポートを突き合わせると、AIチームが整備したエージェント（コマンド）以外でも、生成AIの活用が広がっていることが分かりました。開発者は、エラー分析をはじめとする個々の作業で、独自のプロンプトを用いて生成AIを活用していたのです。共通コマンドを改善するだけでは、日々の利用全体をカバーできていませんでした。

また、忙しい開発現場では「念のため、関連する資料を全部見てほしい」「抜けがないように細かく確認してほしい」といった指示を出したくなる場面もあるでしょう。しかし、対象が広すぎると、作業とは関連性の低い情報まで読み込ませることになります。修正を依頼するたびに全体を生成し直す使い方でも、トークン消費は増えます。
そこで、利用者がプロンプトを作成する際の注意事項をプロジェクト内に周知しました。具体的には、参照範囲と依頼内容を明確にすることや、初回の生成物をすべて作り直すのではなく、必要な箇所を修正することなどです。

ただし、利用量の多さだけで使い方の良しあしは判断できません。難しい不具合の調査に高性能なモデルを使い、解決までの時間を短縮できたのであれば、費用をかける理由があります。反対に、同じ作業を何度もやり直しているのであれば、指示や実行方法の改善が必要です。数字だけで判断せず、利用者と一緒に作業内容を確認することが大切です。

この経験から、生成AIのコスト管理には、ツールの改修に加えて、利用者への教育や、用途・モデルの選択ルールの整備を組み合わせる必要があると分かりました。めざすべきは利用を抑えることそのものではなく、費用に見合う効果が得られる使い方を、開発プロセス全体に根付かせることです。

5．生成AIを持続的に活用するために

一連の取り組みを通じて、分析に必要なデータを人手で集め続けることの難しさも見えてきました。日次レポートで消費の増加を見つけると、該当する利用者に用途を確認し、エージェントデバッグログの提出を依頼します。提出されたログは、AIクレジット監視員が1つずつ手作業で解析していました。この方法でも原因は探れますが、数百名規模の利用状況を継続的に把握するには時間がかかり、開発者にも利用状況の説明やログ提供の負担が生じます。

そこで重要になるのが、AI Observabilityです。AIの実行状況を可視化し、問題の原因を分析できるようにする仕組みを指します。1件の依頼について、どのモデルが呼び出され、どのツールが使われ、どこで再試行が発生したかを、トークン消費量や処理時間とともに追跡します。従来のシステムで用いられてきた、処理の流れを追跡する考え方を、AIエージェントにも適用するものです。

例えば、テストケース生成の費用が前週より増えたとします。処理件数が増えたのか、共通指示の変更によって毎回の入力が増えたのか、キャッシュが使われなくなったのか。こうした違いを継続的に確認できれば、対策を講じる箇所を絞れます。さらに、成果物のレビュー結果と結びつければ、「受け入れられた成果物1件当たりの費用」のように、品質・生産性・コストを合わせて評価することもできます。

複数のツールからこうした情報を集める基盤として、OpenTelemetry（OTel）が利用できます。OTelには生成AI向けのSemantic Conventions（※2）が定義されており、モデル名やトークン数、処理の種類などを共通の属性で表せます。同じ意味のデータを同じ名前と定義で扱えるため、製品ごとのログ解析の手間を減らし、横断的に比較しやすくなります。VS CodeのCopilot ChatやGitHub Copilot CLIには、モデル呼び出し、ツール実行、トークン利用量などをOTelで出力する機能があり、Claude CodeもOTelによる利用状況の収集に対応しています。ただし、取得できる項目や属性の定義は製品やバージョンによって異なるため、接続時に確認が必要です。自作エージェントにも、この規約に沿った計測を組み込んでおくことが重要です。

基盤の構成としては、Langfuse（※3）、Grafana（※4）、Datadog（※5）などを役割に応じて組み合わせる方法が考えられます。例えば、Langfuseで個々のエージェントの処理や入出力を詳しく分析し、Grafanaでチーム別の消費推移や予算に対する見通しを表示する構成です。既存の監視でDatadogを利用している場合は、アプリケーションの処理状況とAIの実行状況を合わせて確認する方法もあります。

過去の記事では、AIのコストと価値を捉えるTokenomicsの考え方を紹介しました。今回の経験から、この考え方を開発現場で実践するためのポイントとして、次の4点が挙げられます。

• 費用を利用者単位だけでなく、処理単位まで分解して捉える
• 毎回送られる情報や、繰り返し実行される処理から優先的に見直す
• 削減効果は、個別の処理ではなく、タスク全体の費用と成果物の品質で評価する
• ツールの改善と、利用者への周知や利用ルールの整備を組み合わせて進める

生成AIのコスト最適化は、技術的な改善だけで完結するものではありません。開発プロセス全体を捉え、品質・生産性・コストを総合的に判断することが求められます。そのためには、生成AIの動作と、実際のシステム開発の両方への理解が欠かせません。

私たちのチームでは今後、実行データを自動的に集める仕組みと、開発工程に即した評価を組み合わせ、改善を継続できる運用へとつなげていきます。「AIクレジット監視員」として始めた活動を、開発者が必要なAIを安心して使い、成果物の品質や設計の判断に集中できる環境づくりへと発展させていきたいと考えています。