生成AIコーディングツールの利用料が想定より膨らみ、導入判断や予算計画に頭を悩ませている情報システム部門の方に向けた内容です。今回は音楽ストリーミング大手Spotifyのエンジニアが公開した、Claude Code（Anthropic社が提供するAIコーディングエージェント。開発者の指示に応じてファイル読み込みやコード生成を自律的に行う）のトークン消費（AIモデルが処理する文字列の単位で、API利用料の課金対象になる量）を約90%削減した手法を、ベンダー管理とコスト評価の観点から整理します。
単なる技術Tipsの紹介ではなく、この事例は「高機能・高コストなAIモデルを一律に使い続けるべきか」という、複数ベンダーのAIサービスを比較検討する立場の方にとって示唆のある判断材料です。実際にどこを見直せば同様の効果が狙えるのか、確認ポイントとあわせてまとめました。
何が起きていたのか、なぜ注目に値するか
Spotifyのエンジニア、ディミトリ・マズマノフ氏が直面していた課題は明快です。
AIコーディングエージェントが1つのメソッドの意味を調べるために、関連する5つのファイルを丸ごと読み込んだり、既存の20個のテストと同じ形式で新しいテストを書いたりする作業で、大量のトークンを消費していました。
こうした処理の多くは、高度な推論を必要としない単純な入出力（I/O）作業だとマズマノフ氏は指摘しています。
つまり、ファイルを読んで情報を整理する、既存のパターンをまねてコードを書く、といった作業に、最も高性能で高価なモデルを使い続ける必要はないという発想です。
検証の結果、大量のファイル読み込みを別モデルに任せたケースでは、Claude側のトークン消費を平均約90%削減できたと報告されています。
この数字はコスト評価の指標として、非常に具体的で参考になります。
技術的な仕組みを段階的に見る
仕組みを理解するために、まず前提となる考え方を押さえます。
AIコーディングエージェントは、質問に答えるために必要な情報を「コンテキスト」と呼ばれる入力領域に読み込みます。
コンテキストに大きなソースファイルを何本も詰め込むと、入力トークンが膨らみ、それに比例して課金額も増えます。
マズマノフ氏が使った「Portal by Spotify」というSpotify社内の開発者向けプラットフォームには、「AiKA Modes」という機能があり、AIへの指示内容・使用モデル・利用可能なツールなどを宣言的に設定し、1つのエージェントとして呼び出せるようになっています。
この仕組みを使って、2つの役割が用意されました。
- bulk-reader: Claudeの代わりに大きなファイルを読み、質問への回答に必要な情報だけを短く要約してClaudeへ返す役割
- code-writer: テストコードや設定ファイルのひな型など、既存パターンを模倣すれば作れるコードを、Claudeの代わりに生成する役割
どちらのモードでも、Claudeより軽量な作業用モデルとしてGemini 2.5 Flash（Google社の高速・低コスト向けモデル）が指定されていますが、これは固定ではなくPortal上で別モデルに置き換え可能とされています。
重要なのは、この振り分けを「指示」だけに頼らなかった点です。
当初はプロジェクトごとの設定ファイル「CLAUDE.md」にルールを書いていましたが、AIが必ず従うとは限らず、安定しませんでした。
そこで導入されたのが「shunt」というClaude Codeプラグインです。
Claude Codeの「PreToolUse」フック（AIがツールを実行する直前に処理を横取りする仕組み）を利用し、350行を超えるファイルの読み込みを機械的にブロックし、bulk-readerの利用を強制する設計になっています。
背景・関連技術との比較で見る位置づけ
この手法は、AI業界で「モデルルーティング」や「マルチモデル戦略」と呼ばれる考え方の一種です。
単一の高性能モデルに全処理を任せるのではなく、タスクの難易度に応じて複数のモデルを使い分ける発想は、クラウドインフラのオートスケーリングでリソースを最適配分する考え方に近いものがあります。
日本の開発現場でも、ChatGPT・Gemini・Claudeなど複数のAIサービスを部署ごと・用途ごとに契約しているケースは珍しくありません。
違いは、Spotifyの事例が「1つの開発フロー内で、タスクの性質に応じて自動的にモデルを切り替える」仕組みを持っている点です。
単に「安いモデルも契約する」だけでは効果は出ません。
どの作業を軽量モデルに渡すかの判断基準（今回はファイル行数のしきい値や、参考ファイルの指定必須化など）を、システムとして組み込む必要がある点が、導入検討時の見落としがちなポイントです。
またSpotifyは、Claudeの利用そのものを縮小しているわけではありません。
大規模なコード変更基盤「Fleet Management」にはClaude Agent SDKを統合し、バックグラウンドで動くコーディングエージェントが毎月650件以上のプルリクエストを生成、複雑なコード移行に必要な作業時間を最大90%短縮したとAnthropic社は報告しています。
つまり、高度な判断が必要な作業には高性能モデルを維持しつつ、単純作業だけを切り出して安価なモデルに委譲する、という併用戦略です。
全面移行でも全面拒否でもない、段階的な最適化として捉える方が実態に近いといえます。
読者への影響と今日確認できること
AIコーディングツールの導入・運用コストを見直す立場にある方は、次の点を確認してみる価値があります。
- 利用しているAIコーディングツールが、モデルごとの使い分け設定（複数モデル・複数パラメーターを宣言的に定義する機能）を持っているか、管理コンソールやドキュメントで確認する
- 現在のAI利用ログやコスト明細で、単純なファイル読み込みや定型的なコード生成が、トークン消費のどの程度を占めているか可視化できるか確認する
- 契約中のベンダーが、フックやプラグインのような「機械的な制御」の仕組みを提供しているか、それとも指示（プロンプト）ベースの制御しかできないか比較する
- 軽量モデルへの委譲によって、スレッドセーフティーのような専門判断が必要な問題を見逃すリスクがどの程度あるか、対象業務の性質から見積もる
特に4点目は導入判断で軽視されがちです。
マズマノフ氏の検証でも、軽量モデルは表面的なコードパターンは見つけられても、並行処理の安全性に関わる問題を見逃したケースがあったと報告されています。
このため、デバッグやアーキテクチャ判断、安全性が重要なコード作成は高性能モデルに残し、単純な読み込み・雛形生成だけを委譲する、という切り分けの基準を自社の業務にも当てはめて検討する必要があります。
また、別モデルの呼び出しには10秒から30秒程度の待ち時間が発生するとされており、小さなファイルでは委譲しないしきい値が設けられています。
コスト削減と処理速度はトレードオフの関係にあるため、業務の性質（バッチ処理か対話的作業か）によって最適なしきい値は変わってくる点も、導入検討時の評価軸に加えておく価値があります。
まとめ
Spotifyの事例が示すのは、単一の高性能AIモデルに全処理を任せる運用が、必ずしもコスト効率の面で最適とは限らないという点です。
約90%というトークン削減幅は、複数モデルの使い分け設定と、指示だけに頼らない機械的な制御(フック)を組み合わせた結果として報告されています。
自社でAIコーディングツールの費用対効果を見直す際は、まず現状のトークン消費の内訳（単純作業か高度な判断作業か）を可視化することが出発点になります。
そのうえで、契約中のベンダーがモデル切り替えや制御の仕組みをどこまで提供しているか、管理画面や技術資料で確認してみることをおすすめします。
全面的な安価モデルへの切り替えではなく、タスクの性質に応じた併用設計こそが、コストとリスクのバランスを取る現実的な選択肢だといえそうです。