Return on Tokenで見直すClaude運用｜サブエージェントで消費半減の3層構成

先日、お客様とClaude Code の運用について雑談していたときに、こんなアドバイスをしました。「これからは Return on Token の時代だと思う」「Claude の使い方は、いま節約フェーズに入っている」。

トークンめっちゃ使うのが偉いみたいな議論は一理ある。ただし、B2Bにおいては、ROIのようにROT（Return on Token）が求められるだろう。…
— Itaru Tomita / 冨田到 (@itarutomy) May 22, 2026

ちょっと前まで「とにかく Opus を使えば正解」という空気があった気がします。ところが最近は、社内の DX 担当や情シスの方から「チームで Claude を導入したら、あっという間にレートリミットに到達してしまった」という相談を受ける機会が急に増えてきました。予算が青天井なら気にしなくてよかった話が、いよいよ現場の運用課題になってきた印象です。

この記事では、この「Return on Token（略して ROT）」という考え方を軸に、Claude Code のサブエージェントを使ってトークン消費を半分にする実装の勘所を、初学者の方にも追える言葉で整理していきます。中学生でも読み進められるように、専門用語はそのつど噛み砕きます。ただし専門性は落としません。今週から現場で試せるチェックリストまでを、ひとつながりのお話として書いていきますね。

この記事の結論
「節約フェーズ」が始まった Claude 運用の現状
Return on Token（ROT）という新しい物差し
Haiku・Sonnet・Opus の3層構成をどう組むか
サブエージェントを立てて消費を半減させる実装パターン
情シス・DX担当が今週から着手する 4 週間チェックリスト
今後の展望とリサーチ AI Snorbe の使い所
FAQ
調査手法について

この記事の結論

Claude Code のトークン消費は、Return on Token（ROT）という指標で役割分担するだけで、体感で半分近くまで落とせます。要点は次の3つです。

Return on Token（ROT）とは、投じたトークンあたり返ってきた価値を測る指標のこと。ROI の AI 版と考えると分かりやすい
Haiku（雑務）・Sonnet（実装）・Opus（設計）の3層 + サブエージェント委譲で、同じ品質をより少ないトークンで出せる
情シス・DX 担当は「1週目：/context で見える化 → 2週目：Haiku 委譲 → 3週目：Prompt caching → 4週目：役割分担のルール化」の順で着手する

「節約フェーズ」が始まった Claude 運用の現状

結論を先に置いておくと、Claude Code は Max 5x プランでも「3時間で5時間枠に到達」の事例が出始めており、Anthropic のピーク時間帯強化（2026年3月）と相まって、「使えるだけ使うツール」から「トークン配分を設計するツール」への移行フェーズに入っています。

まず現場の実感からお話しします。

なぜ Max プランでも 3 時間で上限に届くのか

Claude Code の Max 5x プラン（月額$100、日本円で約1万5千円）は、ヘビーユースを想定した上位プランです。ところが実際にがっつり使ってみると、LP改修と SEO 記事14本を1セッションで並列処理したら約3時間で5時間ローリング上限に到達した、という実務レポートが上がっています。5時間の枠の中で3時間しか動けないという体感ですね。

なぜこんなに早く上限に届いてしまうのでしょうか。理由はシンプルで、Claude は「メッセージの回数」ではなく「トークンの累積量」で使用量を測っているからです。トークンというのは AI がテキストを処理するときの最小単位で、日本語だと1文字が約1〜3トークンに相当します。

会話履歴の 98.5% は過去の再読み込みに消える

さらに厄介なのが、Claude は返答するたびに会話履歴の全部を読み直しているという点です。会話が長くなればなるほど、1回のやりとりで消費されるトークンが雪だるま式に増えます。ある開発者の測定では、100メッセージを超えるチャットではトークンの98.5%が過去履歴の再読み込みに使われていたそうです。新しい回答のために使われるのはわずか1.5%。極端な例ではありますが、長い会話がいかに非効率かを端的に示しています。

追い打ちをかけるように、2026年3月26日から Anthropic はピーク時間帯の消費速度を引き上げました。太平洋時間の午前5〜11時、日本時間だと午後9時〜翌午前3時が対象で、この時間帯は同じ使い方でも枠の減りが早くなります。夜に集中して作業する日本のユーザーからすると、ちょうど痛いところに刺さる変更です。

節約テクニックの寄せ集めでは限界がある

ここまでの話を整理すると、Claude Code は「使えるだけ使えるツール」から「トークンをどこにいくら使うかを設計するツール」に、暗黙の前提が変わってきたのだと思います。冨田の言う「節約フェーズ」というのは、この空気の変化を指しています。

もちろん、節約テクニック集はネット上にすでにたくさんあります。/compact を使う、CLAUDE.md を薄くする、Skills を分ける、といった各論はそれぞれ有効です。ただ、それらを束ねる「なぜそれで効くのか」という軸が抜け落ちがちなのが実情でした。この「なぜ効くのか」を貫くための物差しとして、私が最近しっくり来ているのが Return on Token という考え方です。

Return on Token（ROT）という新しい物差し

Return on Token（ROT）とは、投じたトークンあたりどれだけの価値を返せたかを測る指標です。ROI（投資収益率、投じたお金あたりの儲け）の AI 版と考えると分かりやすいと思います。ごくシンプルな考え方なのですが、これを持っているかどうかで意思決定の質が大きく変わってきます。

ROT は「量」と「配分」の二軸で捉える

なぜこの指標が必要なのでしょうか。それは、トークンには「量」と「配分」の二軸があるからです。

トークンの量については、Anthropic 自身が興味深い分析を出しています。「複数エージェントが並列で情報を集めるタスク（BrowseComp：Web 上の情報を横断的に集めて調べる能力を測るベンチマーク）の性能差を統計的に分解すると、性能分散の80%はトークン使用量そのものだけで説明できる」と、engineering blog で明言しているのです。つまり、AI の出力品質は「モデルの賢さ」ではなく「どれだけトークンを使ったか」でかなりの部分が決まる、ということですね。

一方で同じ記事は、こうも書いています。「複数エージェントを走らせる構成は、チャットの約15倍のトークンを消費する」。品質を上げるにはトークンの量が要ります。でも量には限度があります。この矛盾を解くのが「配分」の視点、つまり ROT の役割です。

英語圏では既に KPI として扱われ始めている

英語圏の AI プラットフォーム企業では、この考え方がじわじわ広がっています。エンタープライズ検索の Glean は『AI システムの token 効率を評価する主要 KPI』を整理し、AI インフラの Weka は「GPU コストではなく token ROI で AI 投資を判断すべき」だと主張しています。

ただ、日本語で「Return on Token」という言葉を軸に据えた記事は、私が Tavily で検索した範囲ではほぼ見当たりませんでした。トークン節約テクニックの記事は無数にあるのに、指標として扱っているものがほとんど見当たりません。この空白地帯こそが、いま情シス・DX 担当の方が動きにくい根本原因のような気がしてきました。

日本の実務者は 2026 年初頭に同じ問いを立てていた

海外だけの議論かというと、そうでもありませんでした。私自身が deskrex.ai を運営しながら回している X アカウント（@itarutomy）でも、2026 年初頭に同じ問いを短く投げていました。

トークンめっちゃ使うのが偉いみたいな議論は一理ある。ただし、B2B においては、ROI のように ROT（Return on Token）が求められるだろう。人間は、このリターン・オン・トークンの最終調整弁になるということになる。それはハーネスであったりだとか、営業・マーケティングだとかそういう部分にはなるだろうね。

トークンめっちゃ使うのが偉いみたいな議論は一理ある。ただし、B2Bにおいては、ROIのようにROT（Return on Token）が求められるだろう。…
— Itaru Tomita / 冨田到 (@itarutomy) May 22, 2026

いま読み返すと、Anthropic engineering や Glean が KPI として整理する前から、B2B 実務の温度感としては同じ地点を見ていたのだと思います。特に「人間は ROT の最終調整弁になる」というフレーズは、この記事で言う3層構成やサブエージェント設計、そしてハーネス（AI エージェントに道具や実行環境を渡すための骨格）から営業・マーケティングまで含めた運用設計そのものです。ここから先は、その「最終調整弁」をどう具体的に組むかの話に進んでいきます。

タスクの性質・単価・品質を三点セットで見る

具体的にどう使う指標かというと、こんなふうに考えます。あるタスクを Sonnet で走らせたら5万トークン消費して、内容は満点でした。同じタスクを Haiku（Sonnet の1/3の値段で走る軽量モデル）で走らせたら4万トークン消費して、内容は90点でした。単純なコストは Haiku の方が安いのですが、「1トークンあたり何点返せたか」で見ると、実は Sonnet の方が ROT が高いこともあり得ます。逆に、単純な文字列抽出タスクなら Haiku が満点を出してくれるので、ROT では明確に Haiku 有利になります。

タスクの性質、モデルの単価、返ってくる品質を三点セットで見ます。この目線が入ると、「どのモデルで走らせるか」の判断が、根拠のある意思決定になります。では、この三点セットを実際にどう組み合わせれば、日々の業務が回るのでしょうか。次のセクションで、具体的な3層構成として組み立てていきましょう。

Haiku・Sonnet・Opus の3層構成をどう組むか

組み立ての骨格を先に示すと、Haiku で雑務、Sonnet で実装、Opus で設計判断という3層分業が、いま最も ROT の高い構成です。特に2025年10月にリリースされた Haiku 4.5 が Sonnet 4 と同等の性能を約1/3の価格で提供するようになり、雑務を上位モデルに任せる合理性がほぼ消えました。

3 モデルの価格・性能・立ち位置を並べる

Claude には現在、3つの階層のモデルが用意されています。名前だけ見ると単純に「上・中・下」の関係に見えるのですが、価格と性能を並べて眺めてみると、思っていた以上に興味深い関係が見えてきます。

モデル	入力単価	出力単価	SWE-bench Verified	位置づけ
Claude Opus 4.5	$5 / 100万トークン	$25 / 100万トークン	80.9%	深い設計・複雑な推論
Claude Sonnet 4.5	$3 / 100万トークン	$15 / 100万トークン	77.2%	日常の会話・実装
Claude Haiku 4.5	$1 / 100万トークン	$5 / 100万トークン	73.3%	定型雑務・大量並列

SWE-bench Verified というのは、AI が実際の GitHub の Issue（開発現場で報告される不具合や改善要望のチケット）をどれだけ解けるかを測るベンチマークで、コーディング能力の目安として広く参照されています。数字を眺めてみると、Opus と Sonnet の差はわずか3.7ポイントしかない一方、価格差は入力単価で1.66倍、出力単価で1.67倍あります。性能はほぼ横並びなのに価格差だけが1.7倍近く開いている、というこの構図の意味を、ROT の目線で読み解いていきましょう。

Haiku 4.5 の登場で分業ルールが変わった

さらに大きな変化として、2025年10月にリリースされた Haiku 4.5 が Sonnet 4 と同等の性能を約1/3の価格で提供しているというのは、押さえておきたい事実です。私が最初にこの数字を見たときは、正直目を疑いました。ほんの数カ月前までトップティアだった性能が、いまや最も安いティアで手に入る、というわけですから。しかも Haiku 4.5 は Extended thinking（回答前に考えるモード）、Computer use（画面を操作する機能）、Context awareness（コンテキストの使用量を自覚する機能）を全て備えています。「安いモデルは機能も削られている」という前提は、どうやら過去のものになりつつあるようです。

準備は Haiku・実装は Sonnet・設計は Opus

このモデル構成をどう使い分けるか。海外コミュニティで広く共有されている実務者の言い回しに、私はいちばん共感します。準備は Haiku、実装は Sonnet、レビューは Opus という組み合わせが効く、というものです（原文：“Haiku for setup, Sonnet for builds, Opus for reviews”）。つまり、準備の雑務は Haiku、実装は Sonnet、設計判断とレビューは Opus、という役割分担ですね。

これを ROT の視点で言い直すとこうなります。

まず、コード探索、grep、パターン抽出、JSON の型合わせ、単純な要約、定型的な文字列整形。この手のタスクは、Haiku で十分満点が出せます。それを Sonnet や Opus で走らせるのは、単価が3〜5倍のモデルに雑務を任せている状態で、ROT が最悪です。

次に、実装、コードレビュー、PR コメント、日常的な壁打ち。この領域はいまや Sonnet 4.5 が Opus 4 相当の品質を出せるので、Sonnet で回すのが単価と品質のバランス点になります。全部を Opus で走らせている場合は、ここが最大の節約ポイントです。

そして、設計判断、複雑な依存関係のデバッグ、アーキテクチャの議論、初見の技術領域の探索。ここは Opus で走らせる価値があります。単価は高いけれど、Sonnet だと10ターン迷って出せない答えを Opus は3ターンで出すことがあるので、累計トークンでは Opus の方が安く済むケースが多いのです。SIOS Tech Lab の実務記事も、この「計画は Opus、実行は Sonnet」という構成が最適だと結論づけています。

ここでひとつ注意点があります。先ほど触れたように、複数エージェントを立てる構成はチャットの15倍のトークンを消費します。ということは、雑務を Haiku に投げるにしても、Haiku サブエージェントへの委譲設計をきちんと組まないと、単に並列化した分だけ請求書が増える、という結末になりかねません。この委譲設計の具体像が、次のサブエージェントの実装パターンです。

サブエージェントを立てて消費を半減させる実装パターン

実装のコツを先に挙げておきます。ビルトインの Explore（Haiku 固定）を最大限に活かすこと、.claude/agents/ にカスタムサブエージェントを Markdown 1枚で追加すること、そして Planner・Generator・Evaluator の3分離パターンと Prompt caching を組み合わせること。この3手を打つだけで、入力トークンのコストは60〜90%まで落ちる事例が報告されています。

ビルトインの Explore（Haiku 固定）を最大限に使う

Claude Code には、実は最初から3つのサブエージェントが組み込まれています。表にするとこうなります。

ビルトインエージェント	使うモデル	使えるツール	自動起動のタイミング
Explore	Haiku 固定	読み取り専用	コード探索・検索が必要なとき
Plan	会話から継承	読み取り専用	プランモードでのリサーチ
General-purpose	会話から継承	全ツール	探索と修正の両方が絡む複雑タスク

注目したいのは、Explore が Haiku 固定という設計になっている点です。Anthropic 自身が「コードの探索なら Haiku で十分」と判断している証拠ですね。しかも Explore が集めた情報はメインの会話に流し込まれず、要約だけが返ってきます。実測では、「サブエージェントが6100トークン分のファイルを読んで、420トークンの要約を返す」というパターンが観測されており、これが本当の意味でメインコンテキストを守っています。作業机の上に生資料を積み上げず、必要な結論だけをメモにして持ち帰ってくれる、優秀な調べ物担当のような役回りです。

カスタムサブエージェントを Markdown 1 枚で作る

自分のプロジェクトに合わせたカスタムサブエージェントを作るのも簡単です。~/.claude/agents/ または .claude/agents/ に Markdown ファイルを置くだけです。ファイルの中身はこんな形になります。

---
name: code-reviewer
description: コードの品質・セキュリティ・ベストプラクティスをレビューする。コード変更後に自動的に使用する。
tools: Read, Glob, Grep
model: sonnet
maxTurns: 15
---
あなたはシニアコードレビュアーです。コードを分析し、品質・セキュリティ・ベストプラクティスの観点から具体的で実行可能なフィードバックを提供します。

model の欄で haiku sonnet opus を指定します。tools で使えるツールを絞ると、そのエージェントに読み書きの制限がかかります。maxTurns は無限ループの暴走を防ぐ安全弁ですね。書き終えたら、Claude Code の中で「コードレビューして」と話しかけるだけで、Claude が「あ、これは code-reviewer の仕事だな」と自動で判断して、code-reviewer エージェントに委譲してくれます。毎回同じレビュー観点を書き直す必要がなくなるので、それだけでも会話のトークンが減ります。

Planner・Generator・Evaluator の 3 分離パターン

もう一段深い設計として、Anthropic が公式に紹介している Planner・Generator・Evaluator の3分離パターンがあります。GAN（敵対的生成ネットワーク）にヒントを得た構造で、こんな流れです。

まずユーザーの要件を Planner が仕様書に展開します。Planner の役割は Opus に任せて、野心的な設計を書かせます。仕様書はメイン会話に戻さず、ファイルに書き出します。次に Generator が Sonnet でその仕様書を読み、機能を1つずつ実装します。実装の前に Generator は Evaluator と「これができたら完了」というテスト可能な合意（sprint contract：スプリントの完了条件を明文化した契約書のようなもの）を結びます。最後に Evaluator が、Generator の成果を懐疑的にチェックします。Evaluator を独立したエージェントで走らせるのが肝で、自分の書いたコードを自分で評価させても甘い自己採点になりがちだからです。Anthropic は engineering blog で「エージェントに自分の作ったものを評価させると、人間から見れば明らかに凡庸な品質でも自信満々に褒めてしまう傾向がある」と正直に書いています。

このパターンが ROT にどう効くかというと、まず3つのエージェントがそれぞれ独立したコンテキストを持つので、片方のエージェントが調査で汚したコンテキストが他方に流れ込みません。かつ、通信はファイル経由なので、メインスレッドのトークンを消費しません。しかもファイルはセッションをまたいで共有記憶になるという副次効果まであります。

Prompt caching と /compact を組み合わせる

もう1つ、ぜひ知っておいてほしいテクニックが Prompt caching です。システムプロンプトやツール定義、大きなドキュメントは、多くの場合セッション中に変わりません。Anthropic はこの「変わらない部分」をキャッシュに置いておく機能を提供していて、読み込み単価は通常の1/10、書き込み単価は通常の1.25倍になります。MindStudio の分析では、この機能を使うことで入力トークンのコストを 60〜90%削減した事例が紹介されています。長い CLAUDE.md や、繰り返し読み込む仕様書がある方は、真っ先に試す価値があります。

コンテキスト管理でひとつコツをお伝えします。Claude Code には /compact（会話履歴を要約して圧縮するコマンド）と /clear（履歴を全部消すコマンド）があります。ただ、自動 /compact は会話ウィンドウの95%になったところで発動するのですが、その時点ではコンテキスト・ロット（context rot：会話履歴が長くなりすぎてモデルが古い情報に引きずられ、理解力が徐々に低下する現象）のピークに達しているため、うまく要約できないケースがあります。実践者の間では、60%くらいの時点で手動で /compact を呼ぶ運用が推奨されています。あるいは、いっそ /clear で切り替えて、要約だけ貼り直して次のセッションを始める方が、精度もトークン消費も改善するそうです。

情シス・DX担当が今週から着手する 4 週間チェックリスト

着手の順序を先に示しておくと、「1週目：/context で見える化 → 2週目：Haiku サブエージェント作成 → 3週目：Prompt caching 有効化 → 4週目：役割分担のドキュメント化」の4段階です。この順で回すのが失敗が少なく、効果も早く見えてきます。

ここまでの話を、月曜日から動ける具体ステップに落とし込みます。順番も含めて意味があるので、頭から順に手をつけていただくと迷わないと思います。

1 週目：/context でトークン消費を見える化する

まず1週目は「見える化」から始めます。Claude Code なら /context を打つと、いま何が読み込まれていて、どこにトークンを使っているかが見えます。想像より CLAUDE.md や既定の Skills、MCP サーバの定義が重かった、というケースが多いので、まずそこを削るだけで初期消費が2〜3割減ることがあります。

具体的なアウトプットとしては、/context の実行結果をチーム内の運用メモに貼り付けて、「CLAUDE.md：18k トークン」「MCP 定義：22k トークン」「Skills：15k トークン」のように内訳が分かる状態にしておくと便利です。その中から「触っていない Skills を無効化する」「読み込ませなくても支障がない MCP 定義を外す」といった打ち手が自然に見えてきます。

2 週目：Haiku サブエージェントを 1 つ作る

2週目は「Haiku 委譲」です。日々の作業のうち、コード探索、grep、JSON 抽出、要約、簡単な分類のタスクを洗い出して、.claude/agents/ に Haiku 指定のカスタムサブエージェントを1つ作ります。1つ運用してみて手応えが分かったら、レビュー用、テスト用、ドキュメント整形用と、少しずつ増やしていくと安全です。

情シス・DX 担当の方向けだと、たとえば「社内 wiki の記事ドラフトを箇条書きに要約する」「稟議申請書の下書きから金額と決裁者情報を JSON で抜き出す」「ログファイルからエラー行だけ抽出する」といったタスクは Haiku で十分満足のいく品質が出ます。まずはご自身のチームで反復頻度が高い雑務を1つだけ選んで、そこから始めてみてください。

3 週目：Prompt caching を有効化する

3週目は「Prompt caching」です。頻繁に読み込む仕様書、コーディング規約、CLAUDE.md の変わらない部分をキャッシュに乗せます。この設定は Anthropic API 側の機能で、API から Claude を叩いている場合は自然に使えます。Claude Code そのものもキャッシュに対応していて、有効化するだけで反映されます。

具体的にキャッシュ対象にすると効きやすいのは、5000トークンを超える固定コンテンツです。CLAUDE.md、社内コーディング規約、業務ドメインの用語集、API 仕様書、ペルソナ設定などが該当します。API を直接叩いている場合は、システムプロンプトのブロックに "cache_control": {"type": "ephemeral"} を付けるだけで、次回以降の同じ内容の読み込みが1/10単価になります。1日100回同じ CLAUDE.md を読み込んでいるチームなら、この設定だけで月末の請求書が目に見えて変わります。

4 週目：役割分担ルールを 1 枚にまとめる

4週目は「役割分担の運用ルール化」です。誰がどのタスクをどのモデルで走らせるかの目安を、チームで簡単なドキュメントにまとめます。Opus のフル解放は「アーキ設計のレビュー」「複雑デバッグ」に限る、日常は Sonnet、雑務は Haiku サブエージェント、というレベルで十分です。

1枚のルールブックのイメージを提示しておくと、こんな骨格になります。「Opus：アーキ設計の壁打ち、複雑デバッグ、初見の技術領域の初期調査」「Sonnet：日常の実装、コードレビュー、PR 説明、SQL チューニング」「Haiku サブエージェント：ログ抽出、JSON 整形、社内文書の要約、初回下書き」。この3行を Notion や社内 Confluence のトップに貼り、新メンバーが迷ったら見に来る運用にすると、モデル選択のばらつきが揃ってきます。あわせて「毎週金曜に /context のスクリーンショットを共有」「Opus 常用者は月初にレビューを受ける」といった簡単な運用ルーティンを添えると、より効果が続きます。

今後の展望とリサーチ AI Snorbe の使い所

モデル階層の下降と自動ルーティング標準化

今後の展望も少しだけ触れておきます。上位モデルの性能が下位ティアに降りてくるスピードは加速しています。2025年10月に Haiku 4.5 が Sonnet 4 相当になった変化を受けて、2026年後半には Haiku 5 が現行 Sonnet 4.5 相当まで来る、と Caylent や MindStudio といった AI インフラ系メディアの分析陣が予測しています。そうなると「日常タスクはほとんど Haiku で足りる」という時代がやってきて、Opus の出番はさらに絞られていきます。

もう一つの流れは「モデルルーティングの標準化」です。タスクの内容を見て自動で最適モデルに振り分けるレイヤーが、Morph の Router や LiteLLM のようなプロダクトから登場してきています。企業の情シス部門が FinOps（IT 財務ガバナンス、つまり IT 支出を投資対効果の目線で管理する枠組み）の一環として「AI 支出の可視化」を求めるようになっており、Anthropic 自身も GitHub Issue #10164 で「サブエージェントのトークン消費を /context に表示する」機能を検討中です。

ビジネス視点でひとつ言い添えるなら、単一エージェントを Opus に全振りする運用は 2025 で一区切りついて、2026 は「ROT を最大化する 3層構成」が主流になっていきそうな気がしています。情シス・DX 部門としては、トークン支出の可視化とモデル役割分担のルール化を、運用ガバナンスの標準項目として組み込んでおくと、後から効いてくるはずです。個別テクニックを追いかける立場のままでいるか、それとも指標を持って意思決定する側にまわるか。この立ち位置の違いが、来年の運用コストにそのまま跳ね返ってくるのではないでしょうか。

反復リサーチは Snorbe に切り出す

最後にひとつだけ、私たちが開発しているリサーチ AI の Snorbe（https://lp.snorbe.deskrex.ai/）の使い所も紹介させてください。ROT の観点で悩ましいのは、リサーチのように「幅広く探索して、深掘りして、また戻ってきて統合する」タイプのタスクです。この手の反復ループを Claude Code の会話上で回すと、コンテキストが膨らみやすく、意外なところでトークンを食います。Snorbe は複数のサブエージェント的な役割を内部で自動振り分けする設計で、ユーザーは自然な日本語で問いを投げるだけです。完全記憶型ナレッジグラフで過去の調査が積み上がるので、同じテーマを再訪するときも履歴を毎回読み直す必要がありません。「Claude 本体は実装と会話に集中させて、リサーチは Snorbe に切り出す」という分担ができると、ROT はぐっと上がります。月曜日の1タスクから試していただけると、体感が早いはずです。

Return on Token を軸に意思決定する

冨田が言っていた「節約フェーズ」は、単に安いモデルに切り替える話ではありません。トークンをどこに配分すれば1トークンあたりの価値が最大になるか、その意思決定軸を持つ、ということです。Return on Token という視点を持つと、雑務は Haiku、実装は Sonnet、設計は Opus、探索はサブエージェント、リサーチは Snorbe、といった役割分担が自然と決まっていきます。中盤で引いた「人間は ROT の最終調整弁になる」というフレーズは、まさに情シス・DX 担当や現場のマネージャーが、この役割分担の設計と再点検を担うという意味です。今週の1タスクからでも、少しずつ試してみてください。

FAQ

Return on Token（ROT）とは何ですか？

投じたトークンあたりどれだけの価値を返せたかを測る指標です。ROI（投資収益率）の AI 版と考えると分かりやすく、モデル選択・エージェント設計・キャッシュ運用の意思決定軸として使います。日本語での定着した訳語はまだありませんが、英語圏では Glean や Weka のような AI プラットフォーム企業が指標化を提唱しています。

Claude Code のサブエージェントは自動で使い分けられますか？

はい、自動で使い分けられます。Claude Code には Explore、Plan、General-purpose の3つのビルトインサブエージェントが最初から入っていて、Claude 本体が状況を見て自動で委譲します。カスタムサブエージェントも .claude/agents/ に Markdown ファイルを置くだけで作成できて、description に「いつ使うか」を書いておくと Claude が自動判定してくれます。

Haiku に任せて品質は落ちませんか？

タスクを選べば落ちません。JSON 抽出、分類、コード探索、要約のような「入力が明確で出力形式が決まっている」タスクは Haiku で十分な精度が出ます。逆に多段推論、微妙な判断、新規の設計といったタスクは Sonnet か Opus に振り分けるのが安全です。実業務では、代表的なタスクで Haiku と Sonnet を両方走らせて出力を比較してから、本番の振り分けを決めるのが確実です。

Prompt caching はどれくらい効きますか？

大きな CLAUDE.md や固定のツール定義を持つ運用では、入力トークンのコストが60〜90%減った事例が報告されています。読み込み単価は通常の10分の1、書き込み単価は通常の1.25倍なので、同じコンテンツを何度も読み込む場面ほど効果が出ます。まずシステムプロンプトと変わらない仕様書から乗せていくのがおすすめです。

個人ではなくチームで導入するときの注意点は？

支出の可視化と役割分担ルールの明文化を、最初の2週間で終わらせておくのがおすすめです。チームで動くとレートリミットの当たり方が個人と全く違ってくるため、まずは誰がどのタスクをどのモデルで走らせているかを見える化してください。そのうえで Opus は設計レビュー限定、日常は Sonnet、雑務は Haiku サブエージェント、といった基準を1枚の運用ルールにまとめると、新メンバーが迷わずに使い始められます。