Claude Codeに調査タスクを投げて席を外し、戻ってきたらコンテキストの大半が数千行のファイル読み込みで埋まっていた——月次のAPI請求を見て、コードを書いた分よりも「読んだ分」に課金されていたことに気づく瞬間は、エージェント運用者なら一度は経験があるはずです。実際、大きなリポジトリで作業するAIコーディングエージェントは、推論ではなくI/O（ファイル読み込みやボイラープレート生成）に大量のトークンを費やします。この「読むだけの仕事」を安いモデルに委譲して入力トークンを大幅に削減した、というのがSpotifyエンジニアリングブログの記事「Portal by Spotify cut my Claude Code token usage by 90%」です。2026年9月3日公開、Hacker Newsで244ポイント・154コメントを集めました（参照日: 2026-09-06）。
2026年9月現在の要点を先にまとめると、Spotifyは社内開発者プラットフォームPortalの「AiKA Modes」（宣言的に定義できる軽量エージェント実行環境）に、ファイル一括読み込み用のbulk-readerとボイラープレート生成用のcode-writerという2つのモードを用意し、Claude CodeのPreToolUseフックで350行を超えるファイル読み込みを検知して安価なモデル（既定はGemini 2.5 Flash）へ委譲するshuntプラグインを公開しました。Javaモノレポでの計測では、bulk-read委譲による入力トークン削減は平均で約90%と報告されています。プラグインはGitHubのspotify/portal-ai-pluginsで公開されており、Claude Codeのプラグインマーケットプレイス経由でインストールできます。
Spotifyが公開した「shunt」とは何か
まず発表の事実関係を整理しましょう。執筆者はSpotifyのPrincipal Product ManagerであるDimitri Mazmanov氏で、公開日は2026年9月3日です。記事の主役は2つあります。
- AiKA Modes: Spotifyの開発者ポータル「Portal」上で動く宣言的エージェントの仕組み。指示文（インストラクション）を書き、モデルを選び、temperatureなどのパラメータを設定し、必要ならMCPツールをアタッチするだけで、インフラやAPIキーを自分で管理せずにエフェメラルな実行環境でエージェントが動きます。記事内ではAWS Lambdaのエージェント版に例えられています。
- shuntプラグイン: Claude Code側に入れるプラグインで、大きなファイル読み込みやボイラープレート生成といったI/O偏重の仕事を検知し、Portal CLI経由でAiKA Modes上の安価なワーカーモデルへ横流し（shunt）します。
委譲先として定義されたモードは2つです。
| モード名 | 役割 | 既定モデル | 設定 |
|---|---|---|---|
| bulk-reader | 複数・大容量ファイルを読み、質問に答える形で要約を返す | Gemini 2.5 Flash（変更可） | temperature 0.2、公開モード |
| code-writer | 参照ファイルのパターンに合わせてボイラープレートコードを生成 | Gemini 2.5 Flash（変更可） | 公開モード |
ポイントは、Claude Code本体（高価な推論モデル）には「要約された結果」だけが返ってくる設計になっていることです。数千行のファイルをClaudeのコンテキストに丸ごと積む代わりに、安いモデルが読んで絞った情報だけを受け取る。推論の質が問われる部分はClaudeに残し、読むだけ・写すだけの仕事を外に出す分業です。
3層のルーティング設計を読み解く
shuntの実装は3つの層で構成されています。Claude Codeの拡張機構（フック・スクリプト・スキル）をフルに使った構成なので、自前で同種の仕組みを作りたい人にも参考になります。
| 層 | 実体 | 役割 |
|---|---|---|
| 第1層: フック | PreToolUseフック | 350行（環境変数SHUNT_MIN_LINESで変更可）を超えるファイル読み込みを検知してブロックし、委譲を促す |
| 第2層: スクリプト | bulk-read / code-writeのBashラッパー |
Portal CLIを呼び出してAiKA Modeにリクエストを投げ、消費トークンをstderrに報告 |
| 第3層: スキル | Markdownファイル | 「いつ・どうやって委譲するか」をClaudeに指示する |
この設計で注目すべきは、第1層がLLMの判断に依存しない機械的なゲートになっている点です。「大きいファイルは直接読まずに委譲してね」とプロンプトで頼むだけでは、エージェントは高確率で無視します。PreToolUseフックで読み込み自体を物理的に止めるからこそ、委譲が確実に発動します。エージェントの行動制御は「お願い」ではなく「フックで強制」が原則、という設計思想が読み取れます。この考え方は長文ポリシー文書ではエージェントを縛れないという検証記事で扱った論点とも一致します。
90%はどう測られたか
削減率の計測方法も記事に明記されています。Javaモノレポを対象に4つのシナリオを用意し、「Claudeが直接ファイルを読んだ場合に消費するトークン数」と「bulk-reader経由で要約を受け取った場合のトークン数」を比較したところ、bulk-read委譲の平均削減率が約90%だった、という報告です。つまりこの90%は読み込みタスクにおける入力トークンの削減率であって、月額請求全体が90%下がるという意味ではありません。この区別は後述するHacker Newsの反応でも最大の論点になっています。
Hacker Newsの反応: 評価と懐疑の分かれ目
この記事はHacker Newsで244ポイント・154コメントを集めました（参照日: 2026-09-06）。コミュニティの反応は、アイデア自体への一定の評価と、数字の見せ方への懐疑に分かれています。以下はコミュニティの意見であり、本記事の事実認定とは区別してください。
- 「入力トークン90%削減 ≠ コスト90%削減」: 最も多かった指摘です。LLM APIの料金は一般に出力トークンの方が入力より高く、入力側だけを削っても請求全体のインパクトは90%にならない、という趣旨のコメントが上位に入っています。
- 「Claude Codeはすでに似たことをやっている」: Claude Code自体が大規模コードベースの探索をサブエージェントに委譲する仕組みを持っており、手法として新しくないのでは、という指摘もありました。Claude Codeのサブエージェント機構についてはサブエージェントfork既定化の解説記事で詳しく扱っています。
- 品質面の不安: 安いワーカーモデルは表層的なパターンは拾えても微妙なバグを見落とす、という懸念です。これは実はSpotify自身が記事内で認めている制約（後述）と重なります。
技術論以外では、記事本文の文体がAI生成特有の言い回し（いわゆる「Claudism」）だらけだという批判や、ブログサイトのスクロール挙動が読みにくいという不満も目立ちました。エージェントで書いた記事をエージェント実務者コミュニティに出すと文体まで査読される、という点は情報発信側にとっても示唆的です。
一方で興味深いのは、批判的なコメントも「委譲そのものが無意味」とは言っていないことです。争点は削減幅の解釈と適用範囲であって、「I/O仕事を高価なモデルにやらせるのは無駄」という前提自体はおおむね共有されています。数字の解釈には注意しつつ、設計パターンとしては学ぶ価値がある、というのがコミュニティ全体の温度感と言えます。
日本企業のエージェント運用にとっての意味
ここからは、このニュースを日本のAIエージェント実務にどう引き付けるかを考えます。
エージェントのコスト構造が「読み込み偏重」になっていないか
Spotifyの記事は、エンジニアリング組織が開発者1人あたり月200〜500ドル以上、場合によっては2,000ドルを超えるトークンコストを支払っている現状に触れ、「2028年までにAIコーディングのコストは平均的な開発者の給与を上回ると予想されている」という見立てを紹介しています（いずれもSpotify記事内の記述で、参照日: 2026-09-06）。国内でもClaude CodeやCodex系エージェントをチーム導入した企業から「思ったより請求が伸びる」という声は珍しくなく、その主因の一つが大規模リポジトリの読み込みです。まず自社のトークン消費のうち、推論とI/Oの比率がどうなっているかを可視化するのが出発点になります。可視化の具体的な方法はAIエージェントのコスト監視ガイドで解説しています。
なお、Claude Codeを定額サブスクリプション（Pro/Maxプラン）で使っているチームでは「請求額」の代わりに「レート制限への到達速度」がボトルネックになりますが、構図は同じです。大容量ファイルの読み込みで使用枠を溶かせば、その分だけ推論に使える枠が減ります。入力トークンの削減は、従量課金なら請求額に、定額なら実効的な作業量に効いてくるわけです。
「どの仕事をどのモデルに割り当てるか」の設計問題
shuntの本質は、モデルのルーティング設計です。高価な推論モデル（Claude）と安価なワーカーモデル（Gemini 2.5 Flash等）の分業を、プロンプトの工夫ではなくフックとスクリプトで機械的に強制する。このパターンはPortalがなくても再現可能です。Claude CodeのPreToolUseフックは公開機能ですし、委譲先はAiKA Modesである必要はなく、安価なモデルを呼ぶ自前のCLIやAPIラッパーでも成立します。「委譲の判断をLLMに任せず、しきい値ベースで強制する」という設計だけ持ち帰っても価値があります。
プラグインという配布形態
もう一つ見逃せないのは、SpotifyがこれをClaude Codeのプラグインマーケットプレイスで配布した点です。フック+スクリプト+スキルの組み合わせを1コマンドで配れる形にしたことで、社内ツールの外部公開が容易になっています。エージェント拡張の標準化の流れはAgent Pluginsの標準化解説もあわせて確認してください。
手元で試す手順
プラグインはGitHubのspotify/portal-ai-pluginsで公開されています。Claude Code上でのインストールは次の3コマンドです（Spotify公式記事およびリポジトリ記載のコマンド。参照日: 2026-09-06）。
# 1. マーケットプレイスとしてリポジトリを追加
claude plugin marketplace add spotify/portal-ai-plugins
# 2. Portal CLI連携プラグインをインストール
claude plugin install portal@portal
# 3. I/O委譲プラグインshuntをインストール
claude plugin install shunt@portal
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。動作環境: Claude Code（プラグイン機能対応バージョン）+ Portal CLI。bulk-reader / code-writerの両モードは公開設定になっているため、自分でモードを作成する必要はありません。フォークして独自版を作った場合は、そちらが自動的に優先される仕様です。
委譲のしきい値は環境変数で調整できます。
# 既定の350行より小さい/大きいしきい値に変更する例
export SHUNT_MIN_LINES=500
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。導入後は、まず削減効果を自社リポジトリで測ることをおすすめします。shuntは委譲ごとの消費トークンをstderrに報告する設計なので、「委譲しなかった場合の推定読み込みトークン」との差分を数日分記録すれば、Spotifyの90%という数字が自社のリポジトリ構成でどの程度再現するかを判断できます。言語構成やファイルサイズ分布が違えば削減率も変わる、という前提で見るのが安全です。
導入前に知っておく3つの制約
Spotify自身が記事内で明記している制約があります。ここを読み飛ばして全面導入すると失敗します。
| 委譲できない仕事 | 理由 |
|---|---|
| コードの編集 | ワーカーモデルが返す行番号が信頼できず、編集の委譲は成立しなかった |
| 推論・レビュー | ワーカーモデルは微妙なバグ（例: スレッドセーフティの問題）を見落とした |
| 安全性が重要なコード | 品質リスクが許容できないため対象外 |
加えて、委譲1回あたり10〜30秒のレイテンシオーバーヘッドがあり、小さなファイルの読み込みまで委譲すると逆に非効率になると記事は述べています。350行というしきい値は、このオーバーヘッドと削減効果のバランス点として置かれているわけです。
ありがちな失敗と回避策
失敗1: 「90%削減」を請求額の削減率だと思って稟議を書く
❌「shuntを入れればAIコーディング費用が90%下がります」
⭕「大容量ファイル読み込みの入力トークンが平均約90%減るという報告です。出力トークンや推論は対象外なので、自社での請求インパクトは1〜2週間の実測で見積もります」
入力と出力の単価差を無視した試算は、導入後に「話が違う」となる典型パターンです。
失敗2: 編集やレビューまで安いモデルに委譲する
❌ ファイル読み込みで効果が出たので、コード編集やバグ調査も同じワーカーモデルに任せる
⭕ 委譲はI/O仕事（一括読み込み・定型コード生成)に限定し、編集・推論・安全性重視のコードは上位モデルに残す
Spotify自身が「編集は行番号が不安定で成立しない」「推論は微妙なバグを見落とす」と報告している領域です。
失敗3: しきい値を下げすぎて逆に遅く・高くなる
❌ 効果を最大化しようとSHUNT_MIN_LINESを50行などに設定する
⭕ 既定の350行から始め、委譲1回あたり10〜30秒のレイテンシと削減トークンを比較しながら調整する
小さな読み込みまで委譲すると、待ち時間と委譲先の呼び出しコストで割に合わなくなります。
失敗4: 委譲先モデルの出力を無検証で本番コードに反映する
❌ code-writerが生成したボイラープレートをレビューなしでマージする
⭕ 生成コードは通常のコードレビューとCIを必ず通す。安価なモデルの出力ほど検証ゲートを厚くする
委譲はコスト最適化であって品質保証ではありません。
よくある質問
Q1. Portal by Spotifyとは何ですか？
Spotifyが提供する開発者ポータル製品・社内プラットフォームで、今回の記事ではその上で動く「AiKA Modes」（モデル・指示・パラメータ・MCPツールを宣言的に定義して動かす軽量エージェント実行環境）が主役です。shuntプラグインがClaude CodeからこのAiKA Modesへ仕事を委譲します。
Q2. 90%削減されるのは何のトークンですか？
大容量ファイル読み込みをbulk-readerに委譲した場合の入力トークンで、Javaモノレポ・4シナリオでの平均値として報告されています。出力トークンや請求総額が90%減るという意味ではありません。
Q3. Claude Codeのトークン使用量はどうやって確認しますか？
Claude Code本体の使用状況表示に加えて、shuntは委譲ごとの消費トークンをstderrに報告します。組織としてはAPIの請求ダッシュボードやログ集計と突き合わせ、推論とI/Oの比率を継続的に見るのが実務的です。
Q4. Portalを使っていなくても意味がありますか？
プラグインの委譲先はPortal CLI経由のAiKA Modesなので、そのまま使うにはPortal環境が必要です。ただし「PreToolUseフックで大きな読み込みを止め、安価なモデルへ委譲する」という3層設計自体は、自前のスクリプトと任意の安価なモデルAPIで再現できます。
Q5. 委譲先のモデルは変更できますか？
できます。bulk-reader / code-writerの既定はGemini 2.5 Flashですが設定で変更可能で、モードをフォークして独自版を作れば、そちらが自動的に優先されます。
最後に確認すべきこと
Spotifyの発表を自社に活かすなら、確認すべきは次の3点です。
- 自社のトークン消費の内訳: 推論とI/O（読み込み・定型生成）の比率を実測する。読み込み偏重でなければshunt型の委譲は効きません。
- 削減率の自社実測: 90%はSpotifyのJavaモノレポでの平均値です。自社リポジトリで1〜2週間実測してから投資判断をしてください。
- 委譲の境界線: I/Oは委譲、編集・推論・安全性重視コードは上位モデルに残す。この線引きを崩すと品質事故につながります。
「より大きなモデル」を買う前に「エージェントに何を読ませないか」を設計する——この視点の転換が、今回の発表の一番の持ち帰りだと考えています。
あわせて読みたい:
- AIエージェントのコスト監視｜トークン可視化と暴走対策 — 委譲を検討する前提となる消費の可視化手法
- AIエージェントのコスト管理｜API従量とサブスク徹底比較 — 課金モデル別のコスト最適化の考え方
参考・出典
- Portal by Spotify cut my Claude Code token usage by 90% — Spotify Engineering（2026年9月3日公開、参照日: 2026-09-06）
- spotify/portal-ai-plugins — GitHub（プラグイン本体・インストール手順、参照日: 2026-09-06）
- Hacker News: Portal by Spotify cut my Claude Code token usage by 90% — Hacker News（244ポイント・154コメント、参照日: 2026-09-06）
- AiKA x Portal — Spotify for Backstage（AiKA Modesの製品情報、参照日: 2026-09-06）
- AI Gateway – Spotify for Backstage — Spotify公式ドキュメント（参照日: 2026-09-06）
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
