SpotifyのエンジニアがClaude Codeのトークン消費を約90％削減した方法とは?

親愛なる読者の皆さまへ。ご存じの通り価格高騰などの悪影響でサーバー運営がとても苦しい状態です。回線や台数を整理し見直せる部分は全て見直しましたが、やはりまだ危険水域です。このままだと1ページを10分割ぐらいして無理矢理PVを増やさざるを得なくなってしまいます。そこで、GIGAZINEの物理的なサーバーたちを、たった1円でも良いので親愛なる読者の皆さまに支援してもらえればとっても助かります！今すぐ寄付は上のボタンから！ ・ これまでGIGAZINEを支援してくれたメンバーのリスト

音楽ストリーミングサービスのSpotifyが、Claude Codeで大量のトークンを消費する単純作業を別のAIモデルに任せることでトークン消費を大幅に削減する手法を公開しました。Spotifyのディミトリ・マズマノフ氏は、この手法を検証した結果、大量のファイル読み込みを委譲するテストでClaude側のトークン消費を平均約90％削減できたと報告しています。 Portal by Spotify cut my Claude Code token usage by 90% | Spotify Engineering https://engineering.atspotify.com/2026/9/portal-by-spotify-cut-my-claude-code-token-usage-by-90 Spotify Claude Agent SDK case study | Claude by Anthropic https://claude.com/customers/spotify AIコーディングエージェントは、あるメソッドについて答えるために5つのファイルを読み込んだり、既存の20個のテストと同じ形式で新しいテストを書いたりする処理などで多くのトークンを消費します。マズマノフ氏は、こうした作業の多くは高度な推論ではなく単なる入出力(I/O)であり、すべてを性能の高いモデルに任せる必要はないと考えました。

そこでマズマノフ氏が利用したのが、Spotifyの開発者向けプラットフォーム「 Portal by Spotify 」に搭載されている「 AiKA Modes 」です。AiKA Modesでは、AIに与える指示や使用するモデル、temperatureなどのパラメーター、利用可能なMCPツールなどを宣言的に設定でき、設定した内容を1つのエージェントとしてPortal CLIやAPIから呼び出せます。 実行環境は一時的に作られるため、常時稼働するエージェント用サーバーを別途用意する必要もありません。 マズマノフ氏はこの仕組みを使って、「 bulk-reader 」と「 code-writer 」という2つのモードを用意しました。また、どちらのモードにもClaudeより軽量な作業用モデルとしてGemini 2.5 Flashを指定しています。ただし、Gemini 2.5 Flashでなければならないというわけではなく、Portalで設定されている別のモデルに置き換えることもできるそうです。 「bulk-reader」の役割は、Claudeの代わりに大きなファイルを読むこと。例えば、Claude Codeが複数の大きなソースファイルを調べる必要がある場合、ファイルそのものをClaudeのコンテキストへ入れるのではなく、bulk-readerにファイルと質問を渡します。そして、bulk-readerはファイルを読み、質問への回答に必要な情報だけを短く整理してClaudeへ返します。 つまり、何千行ものソースコードではなく、その中から抽出された短い要約だけをClaudeに読ませることで 、Claude側の入力トークンを減らす仕組みです。

一方の「code-writer」はbulk-readerとは逆に、大量のコードを「出力」する作業をClaudeから切り離すための仕組みです。テストコードや設定ファイルのひな型、型定義など、既存コードのパターンをまねれば作れるものについては、Claudeが仕様と参考ファイルを作業用モデルへ渡してコードを生成させます。作業用モデルが生成したコードはファイルへ直接書き込むこともできるため、その場合はClaudeが生成されたコードを受け取る必要さえありません。また、参考ファイルの指定を必須にしているのもポイントで、作業用モデルがプロジェクトと無関係な汎用的なコードを生成するのではなく、既存コードの命名規則や書き方に合わせたコードを生成するようにしています。

ただし、Claudeに「簡単な仕事なら別モデルへ任せて」と指示するだけでは、この仕組みは安定して動かなかったとのこと。マズマノフ氏は当初、各プロジェクトの「CLAUDE.md」に振り分けルールを書いていました。しかし、CLAUDE.mdの記述はあくまで指示にすぎないためClaudeが従わない場合があり、さらにプロジェクトごとに同じルールを用意する必要もあったそうです。 そこで、「 shunt 」というClaude Codeプラグインによって振り分けを強制する方法を採用しています。 「shunt」はClaude Codeの「PreToolUse」フックを利用し、Claudeがツールを実行する直前に処理をチェックします。例えば、ClaudeがReadツールでファイルを開こうとした場合、shuntはデフォルトで350行を超えるファイルの読み込みをブロックし、bulk-readerを使うようClaudeへ指示します。LinuxやmacOSなどでファイルの中身を見るために使われる「cat」「head」「tail」「less」「more」といったコマンドで大きなファイルを読む操作も、同様に検出します。一方、Claudeが読むべき箇所をすでに把握していて、その部分だけを指定して読む場合や、「cat file | grep」のように内容を絞り込んで読む場合はそのまま許可されます。 マズマノフ氏の手法のポイントは、「Claudeに読ませるべき情報」と「Claudeに読ませなくてもよい情報」を機械的に分けていることにあります。具体的には、フックが不必要に大きなファイルの読み込みを止め、Claude CodeのSkillが作業用モデルの呼び出し方をClaudeに教え、シェルスクリプトがPortal CLIを通じて作業用モデルを実際に呼び出すという役割分担になっています 。ClaudeがSkillをうまく参照できなかった場合でも、フック自体は大きなファイルの読み込みを阻止するため、単なるプロンプトによる指示より確実にトークン消費を抑えられます。 さらに、作業用モデルに渡した大量のソースコードはClaudeのコンテキストには入りません。bulk-readerの呼び出しは毎回独立していてサーバー側で会話の状態を保持しないため、同じファイルを再送信する必要が生じる場合もありますが、その大量のトークンを処理するのは作業用モデルです。Claudeが受け取るのは回答だけなので、Claude側のコンテキストを大量のソースコードで埋めずに済むというわけです。

マズマノフ氏はJavaの モノレポ を使い、4種類のシナリオで、Claudeがファイルを直接読む場合とbulk-readerの要約を読む場合を比較しました。その結果、bulk-readerを利用したケースでは、Claude側のトークン消費を平均約90％削減できたとのこと。 一方、code-writerについては、通常ならClaudeが参考ファイルを読む入力トークンとコードを書く出力トークンの両方が発生するの