Claude Codeのコストを考えるとき、モデルの入力・出力単価だけを見ても実態はつかみにくい。
大規模なコードベースでは、質問に答えるために複数のファイルを読み込み、既存パターンを確認し、定型コードを生成するだけで大量のトークンが使われるからだ。
Spotifyが2026年9月に公開した「shunt」は、このI/O寄りの作業を高性能モデルから切り離す。
大きなファイルを読む仕事や定型コード生成を、PortalのAiKA modeで動く安価なworkerモデルへ渡し、Claudeには要約や本当に必要な部分だけを戻す構成だ。
注目を集めたのは「平均90%」という数字だが、ここは慎重に読む必要がある。
Spotifyの公式READMEでは、162K行のJavaモノレポを使ったbulk-readの複数シナリオで82〜94%の削減、平均90%と報告している。
つまり、Claude Codeのすべての処理や請求額が一律90%下がるという意味ではない。
shuntはSpotifyのportal-ai-pluginsに含まれるClaude Code向けプラグインで、I/O負荷の大きい処理をAiKA modeへ迂回させる。
公式GitHubでは、Claude Code向けの機能としてbulk file readsとboilerplate generationを安価なworkerモデルへルーティングするものと説明されている。
仕組みは3層に分かれる。
第一層はHooksで、大きなReadを実行する前に検査し、条件に当てはまれば直接読み込みを止める。
第二層はScriptsで、Portal CLI経由のworker呼び出しや出力整形を担当する。
第三層はSkillsで、Claudeにどの場面でbulk-readerやcode-writerを使うべきかを伝える。
単にCLAUDE.mdへ「大きなファイルは安いモデルで読んで」と書く方法との違いは、hookによる強制力だ。
プロンプト上の指示は状況によって無視される可能性があるがPreToolUse hookでRead自体をブロックすれば、高コストな読み込みを構造的に避けられる。
AIコーディングでは、最終回答が短くても、その前段で大量のコードがコンテキストへ入る。
たとえば「このメソッドはどこから呼ばれているか」を調べるために数千行のファイルを複数読むと、推論そのものより読み込みがコストの中心になることがある。
shuntのbulk-readerは、この全文をClaudeへ入れずworker側で読み、質問に必要な情報だけを構造化して返す。
Claude側のコンテキストには圧縮された結果だけが入るため、フロンティアモデルへ投入するトークンを減らせる。
code-writerはさらに踏み込んでいる。
既存テストや設定ファイルを参照し、パターンに沿ったボイラープレートをworkerが生成して直接ディスクへ書けば、Claudeは長い生成物そのものを受け取らずに済む。
ただし、code-writerはbulk-readerほど強制されず、Claudeが適切に使うことに依存する点は公式READMEでも制約として挙げられている。
Spotify公式READMEのベンチマークは162K行のJavaモノレポで行われた。
・単一の4,014行ファイルでは33,684 tokensから5,737 tokensへ減り82%
・ソースとテストを合わせた7,408行では75,990から4,148へ減り94%
・複数サービスをまたぐ1,281行では16,221から821へ減り94%
bulk-readの平均が約90%である。
ここで比較しているのは「Claudeが直接ファイルを読む場合のトークン」と「workerの要約をClaudeが受け取る場合のトークン」だ。
worker側で消費するトークンや利用料金が消えるわけではない。
workerに何を使うか、Portal環境でどのモデル料金が発生するかによって、実際の金額削減率は変わる。
HTML比較表（掲載位置：セクション3の直後）
Spotify公式記事では、Claude Codeのplugin marketplaceへspotify/portal-ai-pluginsを追加し、portalとshuntをインストールしたうえで、新しいClaude Codeセッションから /portal:setup を実行する流れが案内されている。
bulk-readerとcode-writerのmodeは公開済みで、利用者がゼロからmodeを作る必要はない。
既定のファイル行数しきい値は350行。
SHUNT_MIN_LINES環境変数で変更できるため、500行などへ引き上げることもできる。
小さなファイルまでworkerへ送ると、ネットワーク往復と起動時間の方が大きくなりやすい。
自社リポジトリのファイルサイズ分布に合わせて調整するのが現実的だ。
現在の公式READMEでは、shuntはPortal CLI actions registry経由でAiKAを呼び出す。
workerは固定ではなく、Portal側で設定したモデルへ差し替えられる。
Spotifyの記事例ではGemini 2.5 Flashが使われているが、「shunt＝Gemini専用」という設計ではない。
委譲しやすいのは、大量ファイルの横断読解、既存パターンに沿うテスト生成、設定ファイルの雛形、型定義などだ。
これらは入力・出力量が多い一方、難しい推論を必要としないケースが多い。
反対に、編集箇所を正確に特定する作業、高度なデバッグ、アーキテクチャ判断、安全性に関わるレビューは本体モデルへ残した方がよい。
Spotifyの記事でも、workerが微妙なthread-safety bugを見落とし、Claudeが適切なコンテキストを得ると発見できた例が紹介されている。
また、編集そのものをworkerへ任せる設計にも注意が必要だ。
要約結果は正確な行番号を保持しない場合があるため、修正段階ではoffset/limitを使ったtargeted readでClaudeが該当箇所を読み直す。
つまり「最初の探索は安いworker、最終判断と局所編集は高性能モデル」という分担が基本になる。
トークンを減らしても、作業時間が伸びれば開発体験は悪化する。
Spotify Engineeringの記事ではdelegationにネットワーク往復が加わり、典型的には10〜30秒程度の遅延が発生すると説明している。
一方、現在のGitHub READMEではinvocation timeoutの既定値など実装詳細が更新されているため、公開時にはREADMEを優先して確認したい。
精度面では、workerの要約が重要な細部を落とす可能性がある。
したがって、削減率だけで評価せず、「workerの結果を受けてClaudeが追加Readを何回したか」「手戻りが増えたか」まで見る必要がある。
企業利用ではコードの送信先も確認項目になる。
workerへ委譲する以上、Claudeとは別のモデル・基盤へソースコードが渡る構成になり得る。
Portal/AiKAの契約条件、接続先モデルのデータ保持、ログ、リージョン、機密コードの扱いは組織のポリシーと照合する必要がある。
導入判断では、Spotifyの90%をそのまま期待値にしない方がよい。
まず1〜2週間、同じ種類のタスクをshuntあり・なしで比較する。
見るべきなのはClaude側の入力トークン、worker側の利用量、総料金、完了時間、追加Read回数、修正回数の6項目だ。
大規模モノレポで横断検索が多いチームは効果が出やすい。
一方、小さなリポジトリや、最初からgrepやtargeted read中心で作業している環境では差が小さい可能性がある。
しきい値を350行から500行へ変えたときの総コストと待ち時間も比較すると、自社に合う境界を見つけやすい。
shuntの価値は「安いモデルに全部任せる」ことではない。
高性能モデルが読むべき情報量を減らし、推論が必要な場面へ予算を集中させる点にある。
モデル単価の比較だけでなく、タスク分解そのものをコスト設計として扱う発想が重要になる。
Spotifyのshuntは、Claude Codeのコスト最適化をモデル選びだけでなく「どの作業をどのモデルに渡すか」というルーティング問題として捉え直した実装だ。
公式ベンチマークの平均90%削減は魅力的だが、対象は特定のJavaモノレポにおけるbulk-readであり、総請求額の保証ではない。
大規模コードベースで全文Readが多いなら試す価値を検証しやすい。
逆に、小規模プロジェクトや高度な推論中心の作業では、遅延や運用複雑性が上回ることもある。
Claude側、worker側、作業時間、品質を同じ表で計測し、自社の実データで判断するのが適切だ。
.png){kind=logo}
