「AIに仕事を任せたら、請求書が給料並みになった」。海外では、そんな話が現実になりつつあります。そんな中、Spotifyのエンジニアが自分のClaude Code（＝かんたんに言うと、コードを書いてくれるAIの道具）の使用量を大きく減らした方法を公開しました。やったことは、たった2つの「係」を作っただけ。しかも、コードは1行も書いていません。結果、ファイルを読む作業で使う量は、平均で約90%減りました。この記事では、その中身と、あなたが真似できる考え方を順番に説明します。※2026年9月時点の情報です。一部は記事の著者や関係者の見立てに基づきます。
AIへの支払いが「人ひとりの給料」に近づいている
まず、お金の話からです。ここを知らないと、なぜみんな必死なのかが分かりません。
記事によると、エンジニアの責任者の4分の1が、すでに開発者1人あたり月$200〜$500を「トークン代」に使っています。トークンとは、＝かんたんに言うと、AIが文章を読んだり書いたりするときに消える燃料のことです。読んだ量・書いた量に応じて課金されます。
さらに、一部の会社では月$2,000を超えているそうです。1人分でこの金額です。そして記事は、2028年までにAIコーディングのコストが平均的な開発者の給料を上回る見込みだと書いています。
ここで大事なのは、痛いのが「席の利用料」ではないという点です。月額の定額分ではなく、使った分だけ増えるトークン代が効いてくる。たとえるなら、車の購入費より、毎日のガソリン代のほうが家計を圧迫している状態です。
AIの仕事の大半は、実は「頭を使わない雑用」
記事の著者は、自分の使い方を見つめ直してこう気づきます。「AIがやっていることの多くは、考えることじゃない。ただの出し入れだ」と。
具体的には、こんな作業です。
- ひとつのメソッド（部品）について質問しただけなのに、5つのファイルを全部読む
- 隣に並んでいる20個のテストと、まったく同じ形のテストを1個書く
- 打ち合わせのあとに、説明書きを更新する
どれも大量のトークンが消えます。でも、頭を使う部分はほぼゼロです。それを、いちばん賢くていちばん高いAIにやらせている。オーバースペック、つまり実力が余りすぎているんです。
たとえるなら、社長に段ボールの開梱を頼んでいるようなもの。開梱は誰がやっても結果は同じです。なら、安い手に回して、社長には本当に難しい判断だけを残せばいい。この発想が今回の話の全部です。
「2つの係」を作るだけ。コードは1行も書かない
著者が使ったのが、Portal by Spotify の「AiKA Modes」という仕組みです。
Modes（モード）とは、＝かんたんに言うと、宣言を書くだけで作れるAIの分身です。プログラムは書きません。書くのは4つだけ。指示文、使うモデル、答えのブレ具合などの設定、そして外部ツールとの連携です。
動く場所は「エフェメラルなランタイム」。＝かんたんに言うと、呼ばれたときだけ立ち上がって、終わったら消える使い捨ての実行場所です。サーバーを常に動かしておく必要も、鍵の管理も要りません。Portal CLI（＝端末から打つコマンド）またはAPIから呼び出せて、全社に公開するか自分だけにするかも選べます。
作った係は2つです。
係その1：bulk-reader（まとめ読み係）
Claudeが「1つの質問に答えるために、大きなファイルを何個も読もうとする」場面の担当です。
指示文の中身はこうなっています。あなたは正確なコードの分析係です。渡されたファイルを読み、質問に短く答えてください。出力は箇条書きだけ。あいさつも前置きも書かない。各行の先頭には必ず名前・種類・行番号を置く。細かい話は入れ子の箇条書きにする。聞かれていないことは書かない。
係その2：code-writer（定型コード書き係）
テスト、設定ファイルのひな形、型の下書きなど、「隣のファイルを見れば形が決まっている」作業の担当です。
こちらの指示文には大事な一文があります。「コードだけを出力すること。説明文も、囲みの記号も書かない」。これを入れないと、AIは丁寧に囲み記号と解説を付けてきます。すると、その解説をClaudeが読む羽目になり、節約したはずのトークンが戻ってきてしまう。地味ですが、ここが効きます。
記事の例では、どちらの係も働き手のモデルにGemini 2.5 Flashを指定し、答えのブレ具合（temperature）を0.2にしています。ただしモデル欄は自由で、自分のPortalに設定済みのモデルなら何でも受け付けます。
「読むな」と実際に止める、3階建てのからくり
ここが、この事例のいちばん面白いところです。
最初、著者はCLAUDE.md（＝AIへの指示書ファイル）に「重い読み込みはPortalに回してね」と書いていました。一応は動いた。でも問題が2つありました。ルールがお願いでしかなく無視できること。そして、プロジェクトごとに同じ指示を書き写す必要があることです。
そこで作ったのが、Claude Code のプラグイン「shunt」です。3階建てになっています。
1階：フック（先回りして止める）
フックとは、＝かんたんに言うと、AIが道具を使う直前に割り込む引っかけです。shuntは2つ登録します。
- check-file-size：ファイルを読もうとするたびに動く。決めた行数を超えていたら読み込みをブロックし、「まとめ読み係を使って」と伝える
- check-bash-read：cat、head、tail、less、more といった、端末から中身を覗くコマンドを捕まえる
行数の初期値は350行です。SHUNT_MIN_LINES という環境変数で変えられます。記事では500に設定する例が載っています。
2階：スクリプト（呼び出しを包む）
Portal CLI の呼び出しを包んだ、小さなスクリプトが2本あります。Claudeは名前付きの引数を渡すだけ。中では、依頼文の組み立て、実行、エラーの取り出し、使った量の報告まで全部やってくれます。
bulk-read は、渡されたファイルを1つずつタグで包んで境界をはっきりさせ、質問と一緒にまとめ読み係へ送ります。code-write は、仕様と参考ファイルを書き係へ送り、余計な囲み記号を取り除いて、そのままディスクに保存できます。Claudeは生成されたコードを一度も見ません。
なお、参考ファイルの指定は必須です。お手本がないと、書き係はプロジェクトのどこにも馴染まない、宙に浮いたコードを作ってしまうからです。
3階：スキル（使い方を教える）
スキルは、説明と使用例が書かれた文章ファイルです。フックが読み込みを止めたとき、その拒否メッセージがスキルへ案内し、そこに正しい呼び出し方が書いてある、という流れです。
中級者向け：ここが一歩踏み込んだ肝
この3階建ての設計思想は「崩れても最低限は守る」です。仮にClaudeがスキルの説明を読み飛ばしても、1階のフックが高いコストの読み込みを物理的に止めます。お願いベースではなく、通せんぼだからです。
同時に、止めすぎない工夫も入っています。パイプでつないだコマンド（例：ファイルを開いて特定の語だけ抜き出す）は通します。狙いを絞った読み取りだからです。同じ理由で、位置と行数を指定した部分読みも通ります。
係の名前の解決順も覚えておくと便利です。大文字小文字は区別せず、自分のもの→チームのもの→全社公開のもの、の順で選ばれます。公開されている係を自分用に作り変えれば、設定なしで自分のほうが優先されます。
任せてはいけない3つ。線引きが成功を決める
著者は「効かなかったこと」も正直に書いています。むしろここが一番の学びです。
1つめ、編集は任せられない。 安い係が返す要約には、信頼できる行番号が入りません。だから修正が必要な場面では、Claudeが該当箇所を自分で読む必要があります。丸投げが効くのは「理解する」段階まで、ということです。
2つめ、考えることは任せられない。 著者の検証では、安い係は表面的なパターンは見つけたものの、複数の処理が同時に動くときの微妙な不具合を見逃しました。Claudeは正しい材料を渡されると数秒で気づいたそうです。そのため、バグ調査・設計の判断・安全性が重要なコードは、はっきり対象外にしています。
3つめ、待ち時間が積み上がる。 丸投げは毎回ネットワークを往復します。返答はだいたい10〜30秒。Portalは1回の呼び出しを30秒で打ち切るため、大きな生成は小分けにする必要があります。大きい読み込みなら十分おつりが来ますが、小さい読み込みでは逆に損です。行数のしきい値があるのは、まさにこのためです。
日本の読者は、これをどう真似るか
Portal by Spotify は社内向けの仕組みなので、そのまま使うことはできません。でも、真似るべきなのは道具ではなく考え方です。「高い頭脳」と「安い手足」を分ける。この一点だけで効きます。
しかも、これはコードを書く仕事に限りません。あなたが今、高性能AIに「長い資料を全部貼って質問する」使い方をしているなら、それがまさに丸読みです。
やることは3つだけ。(1) 雑用と判断を紙に書き出して仕分ける。(2) 雑用側に、安いモデルで動く「係」の指示文を1つ用意する。(3) 判断が必要なものだけ、高いモデルに回す。
そのまま使える「安い係」の指示文
まとめ読み係の指示文を、日本語の仕事向けに書き直したものです。安いモデルにそのまま貼って使えます。
あなたは正確な資料の分析係です。渡された資料を読み、質問に短く答えてください。 出力は箇条書きだけにする。あいさつ、前置き、感想は書かない。 各行の先頭には、必ず該当する名前・番号・日付のどれかを置く。 細かい話は入れ子の箇条書きにする。 聞かれていないことは書かない。 資料に書かれていないことは「資料になし」と書く。 囲みの記号や装飾は使わない。 質問：（ここに質問を1つだけ書く） 資料：（ここに本文を貼る。複数あるときは「資料1」「資料2」と見出しを付ける）
穴埋め例1：EC（ネット通販）の在庫発注
質問：来週、在庫が切れそうな商品はどれ？ 行の先頭に型番、次に残数を書いて。 資料：直近8週間の販売数の一覧、いまの在庫の一覧、仕入先ごとの納品にかかる日数の表。
穴埋め例2：問い合わせの一次対応
質問：この問い合わせは「返品」「不具合」「使い方」のどれ？ 判断のもとになった一文をそのまま引用して。 資料：問い合わせの本文、返品のきまり、よくある質問集。
うまくいかないときの打ち手
- 出力が長すぎる → 「箇条書きだけ。1行30字以内」と字数の上限を足す
- 前置きやあいさつが消えない → 「あいさつ禁止」を指示文の1行目に移す
- 答えがぼやける → 質問を1回1つに割る。2つ聞くと両方が薄くなる
- 資料にないことを書く → 「資料になし」と書かせる行を必ず残す
- 記号や飾りが混ざる → 「囲みの記号は使わない」を明記する
- 遅い、途中で切れる → 資料を半分に分けて2回投げる
- そもそも安くならない → 資料が短い場合は分けないほうが速い。長いものだけ回す
まとめ：今日・1週間・1か月でやること
高いAIを止めるのではありません。高いAIに、高い仕事だけをさせるんです。
今日（30分） 自分がAIに投げている作業を10個書き出し、「雑用」と「判断」に丸を付けて分ける。それだけで、どこが漏れているか見えます。
1週間 雑用のうち、いちばん量が多い1つを選ぶ。上の「資料まとめ係」の指示文を貼り、安いモデルで試す。うまくいかない点は、上の打ち手を1行ずつ足して直していく。
1か月 安い係に回す作業を2〜3個に増やす。同時に、任せない線引きも決めて書き残す。記事の著者と同じく、原因さがし・設計の判断・お金や安全に関わる部分は、必ず高い頭脳の担当に残しておくこと。ここを曖昧にすると、節約したお金より大きな事故が起きます。
丸読みを止めるだけで、まとめ読みのトークンは平均で約90%減った。この数字は、Javaの大きなコード置き場で4つの場面を測った結果です。あなたの環境の数字ではありません。だからこそ、まずは1つ、小さく測ってみるのが近道です。
