なぜ今か：AIエージェントの全社普及と膨らむトークンコストの壁

ソフトウェア開発の現場では、AIコーディングツールの導入が急速に進んでいます。音楽配信大手のSpotify（スポティファイ）でも全社規模での定着が進みました。同社ではエンジニアの99%以上がAIコーディングツールを毎週利用しています。さらに94%が生産性の向上を実感し、Pull Request（コード変更の統合要求）の作成頻度は76%増加しました[1]。

一方で、開発規模の拡大に伴う新たな課題も表面化しています。Spotifyのプロダクションコードベースは、エンジニア数の増加ペースの7倍の速さで拡大を続けています[2]。同社は自動化基盤のFleet Managementを活用し、累計250万件以上の自動メンテナンスPRをマージして対応してきました[2]。しかし、コード規模の膨張はAIエージェントの実行効率に直接影響を与えます。

エージェントはコードを書く前に、コードベースの探索や依存関係の把握を行います[3]。このオリエンテーション（状況把握）作業自体が大量のトークンを消費します。トークンとは、AIモデルが入出力の文章やコードを処理する最小単位です。複数セッションの並列稼働が進み、50以上のセッションを同時に扱う環境では、各セッションが同じ探索を繰り返してトークンを浪費する問題が生じました[4]。

また、調査会社のGartner（ガートナー）は、AIコーディングのコストがトークン消費量の急増によって予測困難になると指摘しています[5]。Gartnerは単純で頻度の高い作業を小型モデルへ振り分け、先端モデルを高価値な作業に集中させる戦略を推奨しています[5]。最先端のfrontierモデルと小型モデルの間には大きな価格差が存在するためです[6]。

モデル名入力価格（100万トークン当たり）出力価格（100万トークン当たり）
Claude Opus 4.85.00ドル25.00ドル
Claude Sonnet 4.63.00ドル15.00ドル
Gemini 2.5 Flash0.30ドル2.50ドル
Gemini 2.5 Flash-Lite0.10ドル0.40ドル

Spotifyは当初、設定ファイルであるCLAUDE.mdに指示を記述してモデルの動作を制御しようと試みました[7]。CLAUDE.mdは会話開始時にコンテキストへ注入される指示文です[8]。しかし、この記述はモデルに対する助言にとどまり、強制力はありません[8]。Claudeが指示を無視する可能性があり、プロジェクトごとに設定ファイルを複製する保守コストも発生していました[7]。

後輩エンジニアの99%が使っているなら大成功に見えますが、何が問題だったんですか？

先輩ツールを使う人が増えて並列で動かすようになると、コードを探すだけの準備運動でトークンを消費してしまうんだよ。

後輩各エージェントが同じ下調べを別々にやって、高価なモデルの費用を払い続けていたわけですね。

先輩その通りだね。指示ファイルで注意を促しても、モデルが必ず従う保証はないから根本的な解決にならなかったんだ。

何が起きたか：社内ポータル「Portal」と「shunt」による三層委譲モデル

Spotifyはこの課題を解決するため、三層の委譲アーキテクチャを設計しました[9]。中核を担うのは、同社がオープンソースとして公開しているBackstage（バックステージ）を基盤としたノーコード社内開発者ポータル「Portal」です[10]。この基盤上で、専用のエージェント機能を果たす「AiKA Modes（アイカ・モード）」が動作します[11]。

AiKA Modesは、タスク別に特化したworker（作業エージェント）を宣言的に定義する仕組みです[11]。モードごとに指示文、利用可能なツール、モデル、温度パラメータ（出力の多様性を決める数値）、公開範囲を設定できます[11, 12]。Spotifyはこれを利用して、ファイル要約を担う「bulk-reader」や定型コードを生成する「code-writer」といった専用モードを用意しました[11]。

端末側では、Claude Code向けプラグイン「shunt（シャント）」が動作します[9]。shuntはPreToolUseフックという、Claude Codeがツールを実行する直前に割り込む機能を備えています[13]。ファイルの全体読み込みを行おうとすると、フックが介入して処理を遮断します[13]。具体的には、既定値である350行を超えるファイルの全体読み取りをブロックする仕様です[13, 14]。

ファイル読み込みが遮断されると、shuntはPortal CLIの登録アクション経由で処理をAiKA Modeへ転送します[15, 16]。低コストなworkerモデルの割り当てはshuntではなくAiKA Mode側で管理されます[15]。Portalがユーザーやグループの優先順位に基づいてモードとモデルをサーバー側で解決するため、クライアント側の個別設定に依存しません[15, 16]。

委譲時のデータ配置にも工夫が施されています。bulk-read処理では、対象ファイルをXMLタグの境界付きでworkerモデルへ直接送信し、生成された要約結果だけをClaude Codeへ返します[17, 18]。一方のcode-write処理では、仕様と参照ファイルをworkerへ送り、生成されたコードを直接ディスクへ書き込みます[17, 18]。

この設計により、膨大なソースコード本文や生成コードがClaudeの会話コンテキスト（記憶領域）に入りません[17, 18]。一般的なLLMゲートウェイがAPI通信全体のプロキシや認証を担うのに対し、shuntは特定の高負荷なツール呼び出しのみをピンポイントで切り離す点が特徴です[19]。外部連携規格のMCP（Model Context Protocol）ツールも、AiKA Modeのworker側に限定して付与できます[20]。

記事内の具体例では、workerモデルとしてGemini 2.5 Flashが設定されています[21]。Gemini 2.5 Flashは低遅延で大量の処理に適したモデルです[22]。ただし、Portalインスタンスに設定された別のモデルへの切り替えも可能です[21]。思考機能が有効なモデルでは遅延やトークン消費が増える場合があるため、タスク特性に応じた設定が求められます[22]。

後輩Claude Code自体を取り替えるのではなく、ファイル読み込みの瞬間だけ別のモデルに差し替えているんですね。

先輩そうだね。Claudeに大きなファイルをそのまま読ませず、要約だけを渡すことでコンテキストの圧迫を防いでいるんだよ。

後輩生成したコードもClaudeを通さずに直接ファイルへ書き込むなら、Claude側の消費トークンはほとんど増えませんね。

先輩そこが要点だね。ただ、どの処理を誰に任せるかの境界線をしっかり管理しないと意図通りの動作にならないよ。

90%削減の真実：公開ベンチマークの測定値と推定方法の実態

Spotifyの報告で最も注目を集めたのが「Claude Codeのトークン消費量を約90%削減した」という数値です[23]。しかし、この測定値の算出方法を精査すると、いくつかの重要な前提が浮かび上がります[24]。

まず、この「平均約90%削減」という数字は、16万2000行（162K行）規模のJavaモノレポ（単一の統合リポジトリ）で実施された4つの評価シナリオに基づいています[24, 25]。算出対象となったのはbulk-readに属する3つのシナリオの平均値であり、コード生成を行うcode-writeのシナリオはこの平均に含まれていません[24]。

シナリオ分類対象規模shuntなし推定値shuntあり測定・推定値削減率
単一大規模ファイル（SpotifyUri.java）4,014行33,684トークン5,737トークン82%
ソース・テストペア（PromotionRuleRepository）7,408行75,990トークン4,148トークン94%
複数サービス横断（permission handlers）1,281行16,221トークン821トークン94%
コード書き込み（code-write）3,667行40,614トークン＋生成833行をディスク直接出力対象外（非対称）

測定された3つのbulk-readシナリオでは、確かに高い削減率が示されています。単一の巨大ファイルでは82%、ソースとテストのペア読み込みでは94%、複数サービスをまたぐハンドラの読み込みでも94%の削減が記録されました[25, 26, 27]。これら3つの平均を取ると約90%となります[24]。

しかし、ここで用いられたトークン数は、提供元の実トークナイザー（文字列をモデル処理用のトークン列に分割する処理部）を通した厳密な値ではありません[28]。ベンチマーク実装では、コードの文字数を4で割る保守的な近似計算が使われています[28]。コードの記述言語や記号の密度によって実際のトークン数は変動します[28]。

さらに、code-writeシナリオの扱いには注意が必要です。shuntなしの条件では、参照ファイルの入力トークン数に加えて、生成トークンに出力価格比を考慮した5倍の重みを掛けて合算しています[29]。一方のshuntありの条件では、生成物がClaudeのコンテキストに入らないことからClaude側のトークン数を一律「0」とみなして比較しています[29]。

結果として、code-writeでは「833行のコードをディスクへ書き込んだ」という実績値のみが示され、削減率の数値は算出されていません[30]。加えて、公開リポジトリの再実行用ファイルと報告されたJavaモノレポの完全な対応手順は明記されておらず、外部からの完全な再現手順は確認できない状態です[31]。

以上の点から、「90%削減」という表現はClaude Codeの月額請求額や全通信量が90%削減されたことを意味するものではありません[32, 33]。大量のファイル読み込み時において、Claude Codeのコンテキストに投入されるトークン量を試算した結果として理解するのが妥当です[32, 33]。

後輩請求額が90%減るわけではないんですね。どうしてそういう計算になるんですか？

先輩90%という数値はファイル読み込み3件の平均で、文字数を4で割った推定値に基づいているからだよ。

後輩コード生成の評価も、Claude側の消費を0と置いていて計算の前提が揃っていないように見えます。

先輩その通りだね。全体の利用料ではなく、特定の重い処理でClaudeのコンテキスト消費を抑えられた試算値と捉えるべきだね。

何が変わるか：I/O委譲と推論保持の境界線、および運用上の制約

shuntの設計思想は、すべての処理を小型モデルへ置き換えることではありません[34]。Spotifyは「AIコーディングエージェントの作業の大半は思考ではなくI/O（入出力）である」という前提に立ち、入出力負荷の高い作業のみを委譲対象に設定しています[34]。

委譲に適しているのは、大量のファイル群の読み込みと要約、既存の様式に従う設定ファイルや型スタブ（型定義の骨組み）、テストコードの生成といった定型作業です[35]。コード生成を委譲する際は参照ファイルを必須とし、既存の命名規則やスタイルに照合させる必要があります[36]。

一方で、デバッグ作業、コードの精密な編集、アーキテクチャの設計判断、安全性が重視されるコードの最終確認はClaude Code側に残します[34, 37]。workerモデルが生成した要約文をそのままパッチ（修正コード）の作成根拠にしてはならず、精密な文脈判断にはClaude自身の推論能力を維持しなければなりません[37]。

また、shuntによる委譲の強制力にも非対称性があります。ファイルの読み取りに対しては350行を超える全体読み込みをフックで強制遮断します[14, 38]。ただし、特定範囲を指定するoffset（開始位置）やlimit（取得行数）が付与された対象読み取りはそのまま通過させます[14, 38]。対照的に、code-writerにはフックによる強制機構がなく、Claudeがスキルの説明文を自律的に認識して呼び出す設計に依存しています[38, 39]。

実運用における物理的な制約も存在します。委譲を行うたびにネットワーク通信の往復が発生するため、応答には通常10〜30秒の時間を要します[40]。Spotifyの記事ではPortalの単一呼び出し上限が30秒と説明されていました[40]。現在のリポジトリではshuntの既定タイムアウトが180秒に設定されていますが、サイズの小さいファイルであればClaudeが直接読む方が迅速に完了します[41]。

さらに、コマンドライン引数のサイズ上限にも配慮が必要です。macOSの引数上限（ARG_MAX）は約1MB、Linuxでは単一引数が128KiBに制限されます[42]。shuntの既定ペイロード上限はmacOSで400,000バイト、Linuxで120,000バイトに設定されています[42]。極めて大きなファイル群を委譲する際は、リクエストを分割して送信する必要があります[41, 42]。

セキュリティ面では、委譲されたコードはPortal基盤、設定されたLLMプロバイダー、指定されたMCPツールを通過します[43]。Spotify自身が顧客データを学習に利用することはありませんが、利用先プロバイダーのデータ管理規約が適用されます[43]。安全な運用の観点からは、各モードに付与するMCPツールを必要最小限に絞り、書き込み権限を持つツールの付与は避ける設計が求められます[44]。

精度の補助として検証プロセッサを導入できますが、追加の呼び出しによる遅延が発生します[45]。AiKAの標準設定ではエージェントの最大ステップ数が10ステップ、検証ラウンド数が2ラウンドとなっています[45]。実務では上限値を適切に設定し、応答の遅延を抑える調整が不可欠です[45]。

後輩全部安価なモデルに任せてしまえば、もっとコストを削れるんじゃないですか？

先輩それをやると推論の質が落ちてしまうよ。デバッグや設計判断はClaudeの頭脳が必要なんだ。

後輩しかもネットワーク通信で10秒から30秒待つなら、小さな修正まで委譲すると作業が遅くなりそうですね。

先輩その通りだね。コマンドラインの容量制限もあるから、大きな作業だけを賢く切り離す見極めが欠かせないんだよ。

誰に影響するか：他社組織における再現性と自前構築の判断基準

Spotifyが示したアーキテクチャは、大規模な開発組織におけるAIエージェント活用の先行事例として大きな示唆を与えます。しかし、他社がこの仕組みをそのまま導入できるかどうかは、組織の開発環境によって分かれます[46]。

すでにBackstageを運用し、AiKAを有効化したPortalインスタンスを契約している組織であれば、公開されているshuntプラグインを導入することで同様の構成を再現できます[46, 47]。ただし、利用にはPortalドメイン、認証プロバイダーの管理権限、AI Gatewayにおけるモデル設定などの前提条件が揃っている必要があります[48]。

また、前提条件を満たして導入した場合でも、Spotifyが報告した「90%削減」と同じ成果が得られるとは限りません[46]。効果の大きさは、扱うリポジトリの構造、ファイルの平均行数、エージェントに依頼する作業内容の比率に大きく左右されます[46]。

一方、Portalを導入していない組織では、公開されたshuntプラグインをそのまま動作させることはできません[49]。同様の効果を得るには、Claude CodeのPreToolUseフックによる遮断、社内workerの実行環境、要約の返却パイプライン、ディスクへの直接書き込み機構を自前で実装する必要があります[49]。

自前構築を選択する場合、通信タイムアウトの制御やOSごとの引数長制限、さらにはプロバイダーへのデータ送信ポリシーの管理など、Spotifyが直面した技術課題を独自に解決しなければなりません[41, 42, 43]。自社のコード規模とエージェント利用頻度を照らし合わせ、構築と保守に見合う費用対効果が存在するかを慎重に判断する必要があります[46, 49]。

後輩うちのチームでも明日からこのプラグインを入れれば安くなりますか？

先輩残念ながらそう簡単ではないよ。BackstageベースのPortal基盤とAiKAの契約が前提になっているんだ。

後輩なるほど、同じ仕組みを自前で作るとなると、フックや通信の制御まで作り込むコストがかかるわけですね。

先輩そうだね。自分たちのコード規模とエージェントの利用頻度を天秤にかけて、投資に見合うか見極めることが大切だよ。