結論: Claude Codeを全社導入すると、個人利用では見えなかったコスト超過リスクが一気に顕在化する。原因の大半は「誰がどのタスクでトークンを消費しているか」を可視化できていないことにある。2026年8月時点の公式ドキュメントでは、/usageのLoops内訳、promptCacheTtl設定、Agent Teamsの消費倍率、チーム規模別のTPM/RPM目安が公開されており、これらを組み合わせることで導入前にコスト構造を設計できる。
- ポイント1:
/usageのLoops内訳（要v2.1.242以降）でスケジュールタスクごとの消費量を特定できる - ポイント2:
promptCacheTtl/subagentPromptCacheTtlでキャッシュTTLを用途別に制御できる - ポイント3: Agent Teamsはplanモードのteammate稼働時に通常セッションの約7倍のトークンを消費する（公式ドキュメント確認済み）
対象読者: Claude Codeを10名以上の組織で導入する情報システム部門・エンジニアリングマネージャー。
今日やること: 自組織の契約形態（Claude for Teams/Enterprise・Claude Console・クラウド経由）を確認し、対応するコスト管理機能の窓口を把握する。
ある中堅SaaS企業の情シス担当者が、全社導入から2ヶ月後にAPI利用料の請求書を見て青ざめた——という話は、Claude Codeの全社導入プロジェクトでは決して珍しいパターンではない。個人の検証利用では月数千円だったコストが、50名規模のチーム展開後に想定の3倍に膨らむ。原因を辿ると、深夜に自動実行されていたスケジュールタスクと、複数人が同時に有効化していたAgent Teams機能が主な要因だった、というのは典型的な失敗の構図として語られることが多い。本記事はこうした事例パターンを踏まえ、Claude Code公式ドキュメント（code.claude.com/docs）に基づき、全社導入時に発生しやすいコスト超過を防ぐための可視化・設計手法を解説する。※上記は特定の実在企業を指すものではなく、複数の公開事例・実装パターンから構成した説明用シナリオである。
なぜ全社導入でコストは見えなくなるのか
個人利用のClaude Codeは、使う本人が体感で消費量を把握できる。しかし組織導入では状況が変わる。契約形態によってコストの見え方がまったく異なるためだ。Claude for Teams/Enterprise契約ではシート単位の利用枠（5時間ローリング＋週次ウィンドウ）がClaude chatやCowoverと共有され、Claude Console（API）契約ではワークスペース単位の支出上限、Bedrock/Google Cloud Agent Platform/Microsoft Foundryなどクラウド経由の契約ではクラウド課金コンソール側で上限を管理する。この3系統を混同したまま「なぜか高い」と感じているケースが多い。まず自社がどの契約形態でClaude Codeを使っているかを確定させることが、コスト設計の出発点になる。
/usageのLoops内訳でタスク別消費を特定する
v2.1.242以降のClaude Codeでは、/usageコマンドにLoops（スケジュールタスク）の内訳表示が追加されている。ここでは各スケジュールタスクごとに、消費トークン数・実行回数・1回あたりの平均トークン数・最終実行時刻が一覧できる。全社導入後にコストが膨らんだ場合、まず疑うべきは「誰も見ていない自動実行タスク」だ。
実務では次のようなプロンプトで調査するのが早い。
直近の/usageのLoops内訳を貼るので、
1回あたりのトークン消費が最も大きいスケジュールタスクを3つ挙げて、
実行頻度を落とす、または不要なら削除する提案をしてこの方法で「誰かが検証目的で仕込んだまま放置していた5分間隔のループタスク」が見つかるケースは実装現場で頻繁に報告されている。Loops内訳はコスト超過の原因調査における最初のチェックポイントとして位置づけるとよい。
promptCacheTtl / subagentPromptCacheTtlでキャッシュ戦略を設計する
v2.1.243で追加されたpromptCacheTtlとsubagentPromptCacheTtlは、プロンプトキャッシュのTTL（5分または1時間）を「メイン会話」と「それ以外（サブエージェント・ワークフロー・チームメイト・フォーク・コンパクション・セッションタイトル生成）」で個別に指定できる設定項目である。対応する環境変数はCLAUDE_CODE_PROMPT_CACHE_TTLとCLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL。
優先順位は次の順で決まる。
FORCE_PROMPT_CACHING_5M=1（両バケットを強制的に5分に。デバッグ用途）- 各バケットの環境変数（
CLAUDE_CODE_PROMPT_CACHE_TTL等） - 各バケットの設定値（
promptCacheTtl等） ENABLE_PROMPT_CACHING_1H=1（両バケットに1時間を要求）- バケットごとのデフォルト値
Claudeサブスクリプション契約でプラン利用枠の範囲内であれば、メイン会話は既定で1時間、それ以外は既定で5分のTTLが適用される（一部のサーバー制御ヘルパーリクエストを除く）。ただし1時間TTLはClaudeアプリのゲートウェイ経由では利用できない点に注意が必要だ。利用枠を超えた従量課金・APIキー・クラウドプロバイダ経由の場合は、両バケットとも既定で5分になる。
設定を変更する際は、次のようなプロンプトでClaude Code自身に非破壊的な追記を依頼すると事故が起きにくい。
.claude/settings.jsonにpromptCacheTtlとsubagentPromptCacheTtlの項目を
追加したい。既存の設定は壊さずに、TTLの値だけを追記する差分を提示してキャッシュを無効化する8つの操作・保つ7つの操作
プロンプトキャッシュはコスト効率の要だが、意図せず無効化してしまうと再度フルトークン分の入力コストが発生する。公式ドキュメントが明示する無効化操作は次の8つだ。
| キャッシュを無効化する操作 |
|---|
| モデルの切り替え |
| Effort（推論の強度）レベルの変更 |
| Fastモードの有効化 |
| MCPサーバーの接続・切断（ツールがprefixに読み込まれている場合。deferred設定時は対象外） |
| プラグインの有効化・無効化（読み込まれるMCPサーバー構成が変わる場合のみ） |
ツール全体の拒否設定（ツール名単体やBash(*)等のワイルドカード拒否） |
| 会話のコンパクション |
| Claude Codeのアップグレード |
一方、次の7つの操作はキャッシュを保ったまま実行できる。
| キャッシュを保つ操作 |
|---|
| リポジトリ内のファイル編集 |
| セッション中のCLAUDE.md編集（次回の/clearまたは再起動まで反映されない） |
| 出力スタイルの変更（同上） |
| 権限モードの変更 |
| スキル・コマンドの呼び出し |
| /recapの実行 |
| 会話の巻き戻し（/rewind） |
| サブエージェントの起動（親セッションのキャッシュには影響しない） |
特に見落とされがちなのが「ツール全体の拒否設定」だ。個別ツール呼び出しの拒否ではなく、ツール名単体やワイルドカードでの拒否がキャッシュを壊す点は、運用ルールを設計する際に周知しておく必要がある。
Agent Teamsはなぜ約7倍のトークンを消費するのか
Agent Teams機能（CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1で有効化、既定は無効）は、複数のteammateが並行して作業する構成だが、公式ドキュメントはteammateがplanモードで稼働する場合、標準セッション比で約7倍のトークンを消費すると明記している。全社導入後にAgent Teamsを試験的に有効化したチームが複数存在すると、この倍率がコスト超過の主要因になりやすい。
公式ドキュメントが示す推奨策は次の4点。
- teammateにはSonnetを使う
- チーム規模を小さく保つ
- spawnプロンプトを絞り込む（曖昧な指示を避ける）
- 作業が終わったteammateはシャットダウンする
Agent Teamsを全社解禁する前に、次のようなプロンプトで試験導入の範囲を限定しておくと、想定外の消費増加を防ぎやすい。
Agent Teamsでこのタスクを進めたい。teammateは最大3体まで、
モデルはSonnet固定、作業完了後は必ずシャットダウンする前提で
チーム構成の計画を立ててチーム規模別のTPM/RPM目安表
Rate limit（TPM＝1分あたりトークン数、RPM＝1分あたりリクエスト数）は組織全体で設定するため、人数が増えるほど1人あたりの必要枠は小さくなる。公式ドキュメントが示すユーザー1人あたりの目安は次の通り。
| 組織規模 | TPM/ユーザー | RPM/ユーザー |
|---|---|---|
| 1〜5名 | 20万〜30万 | 5〜7 |
| 5〜20名 | 10万〜15万 | 2.5〜3.5 |
| 20〜50名 | 5万〜7.5万 | 1.25〜1.75 |
| 50〜100名 | 2.5万〜3.5万 | 0.62〜0.87 |
| 100〜500名 | 1.5万〜2万 | 0.37〜0.47 |
| 500名以上 | 1万〜1.5万 | 0.25〜0.35 |
この数値は組織全体の集計上限であり、個々のユーザーが厳密にこの枠内に収まるよう強制されるものではない。一時的に平均を超える利用は起こりうる前提で設計するのが実務的だ。また、大人数がほぼ同時にClaude Codeを使う研修・ハンズオンのような場面では、通常より高めのTPM割当が必要になる、とも公式ドキュメントは補足している。全社導入の初期段階でこの表を目安に申請枠を見積もっておくと、後からのレート制限エラー対応に追われずに済む。
契約形態別のコスト管理機能の違い
コスト管理の具体的な操作方法は契約形態によって大きく異なる。
- Claude for Teams/Enterprise: シート単位の利用枠（5時間ローリング＋週次ウィンドウ、Claude chat/Cowoverと共有）。組織の支出レポートは日次更新のCSVで確認でき、組織・グループ・メンバー単位で利用クレジットと支出上限を設定できる。Enterpriseプランではメンバー別の詳細レポートに
read:analyticsスコープのEnterprise Analytics API（Primary Ownerが発行）を使う。Teamsプランはこの代わりにCSVエクスポートを使う。 - Claude Console（API）: ワークスペース単位の支出上限を設定する。Consoleダッシュボードでメンバーごとの支出・採用行数を確認できるほか、プログラムから日次メトリクスを取得するClaude Code Analytics API（Admin APIキーが必要）がある。初回のConsole認証時に「Claude Code」ワークスペースが自動作成されるが、このワークスペースでは新規APIキーを発行できない点に注意。
- クラウドプロバイダ経由（Bedrock / Google Cloud Agent Platform / Microsoft Foundry）: トークン単位でクラウドアカウントに課金され、支出上限はクラウド側の課金コンソールで設定する。ユーザー単位の帰属を把握するには、OpenTelemetryエクスポート、セルフホスト版Claudeアプリゲートウェイ、またはLiteLLMのようなサードパーティ製LLMゲートウェイ（Anthropic非公式）のいずれかが必要になる。
自社がどの列に該当するかによって、見るべきダッシュボードと発行すべきAPIキーの種類がまったく異なる。導入プロジェクトの初期に、情シス・経理・現場のどこが何を見るのかを1枚の表に整理しておくと、後の問い合わせ対応が減る。
/loopのスケジュールタスクとコスト構造
/loopで作るスケジュールタスクはセッション単位で動作し、最小実行間隔は1分、1セッションあたり最大50個まで登録できる。cron形式（5フィールド）で指定し、繰り返しタスクは実行が最大30分（1時間未満の間隔なら間隔の半分まで）遅れることがある「jitter（ゆらぎ）」の仕組みを持つ。また繰り返しタスクは7日間で自動的に期限切れになる。全社導入後、これらの仕様を知らないまま放置されたループタスクが積み重なると、Loops内訳で見た「消費が大きいのに誰も把握していないタスク」の温床になる。CLAUDE_CODE_DISABLE_CRON=1環境変数でcron機能自体を無効化することも可能だ。
クラウド版のRoutines、デスクトップ版のスケジュールタスク、/loopはいずれも似た機能だが、稼働にマシンの起動が必要か、設定が永続化されるか、ローカルファイルにアクセスできるか、MCP設定を引き継ぐか、権限確認プロンプトが出るか、最小実行間隔（クラウド版は1時間、デスクトップ版・/loopは1分）が違う。この違いを理解せずに複数の仕組みで同じような自動化を二重に組んでしまうケースも、コスト超過の一因として報告されている。
よくある失敗パターン4つ
複数の実装パターンを踏まえると、全社導入時のコスト超過は次の4パターンに集約されることが多い。
❌ 失敗1: Agent Teamsを試験導入したまま、稼働状況を誰も棚卸ししていない
⭕ 対策: teammate数の上限とシャットダウンルールを最初に明文化する
❌ 失敗2: promptCacheTtlを設定せず、デフォルト挙動に任せたままサブエージェントを多用する
⭕ 対策: サブエージェント多用チームはsubagentPromptCacheTtlを明示的に確認し、キャッシュ書き込みコストとのバランスを見る
❌ 失敗3: /loopで組んだ検証用タスクを消し忘れる
⭕ 対策: 7日で自動失効する仕様を前提に、恒久タスクは別の永続化手段（Routines等）に移す
❌ 失敗4: 契約形態（Teams/Enterprise・Console・クラウド経由）を混同したままダッシュボードを探す
⭕ 対策: 導入初期に契約形態を確定し、対応する支出レポートの取得経路を1つに決める
導入チェックリスト
全社導入前後に確認しておきたい項目を次のプロンプトでClaude Codeに実行させると、抜け漏れを減らせる。
以下を順番に確認して:
1. 現在の契約形態（Teams/Enterprise・Console・クラウド経由）を教えて
2. /usageのLoops内訳を確認し、消費上位3タスクを報告して
3. promptCacheTtlとsubagentPromptCacheTtlの現在の設定値を確認して
4. Agent Teamsが有効化されているか、有効なら稼働中のteammate数を報告して- 契約形態を確認し、対応する支出レポート取得経路（CSV / Analytics API / クラウド課金コンソール）を1つに決めたか
- Loops内訳を月次で棚卸しする担当者を決めたか
- promptCacheTtl / subagentPromptCacheTtlを用途別に設定したか
- Agent Teamsのteammate上限とシャットダウンルールを明文化したか
- チーム規模別TPM/RPM目安表を参考に、申請済みレート制限が実態と合っているか確認したか
なお、キャッシュTTLそのものの詳細な設計（1時間TTLと5分TTLの使い分けの基礎）はClaude Codeのトークンコスト最適化ガイドで、gateway側の開発者別支出上限の設定はgateway経由の支出上限設定ガイドで、それぞれ個別に詳しく解説している。全社導入のコスト設計を進める際は合わせて確認するとよい。
Claude Codeの全社導入設計を相談したい方へ
コスト設計・権限設計・運用ルール策定を含む導入支援については、実装パターンの詳細を個別に相談できる。
よくある質問（FAQ）
Q1. promptCacheTtlを1時間に設定すれば必ずコストが下がりますか？
A. 一概には言えない。1時間TTLはキャッシュ書き込み時のコストがやや高くなる一方、再利用の頻度が高い会話ではヒット率が上がり総コストは下がりやすい。逆に短時間で終わるタスクや会話の入れ替わりが激しいサブエージェント用途では、5分TTLの方が無駄な書き込みコストを避けられる場合がある。まずは/usageでキャッシュの読み書き量（cache_creation_input_tokensとcache_read_input_tokens）を確認し、実測に基づいて調整するのが安全だ。
Q2. Agent Teamsは全社的に禁止すべきですか？
A. 禁止までは必須ではない。公式ドキュメントもAgent Teams自体は既定で無効な実験的機能と位置づけつつ、teammateモデルをSonnetに絞る・チーム規模を小さくする・spawnプロンプトを絞り込む・作業後にシャットダウンするという4つの運用ルールを推奨している。全社解禁の前に、これらのルールを適用した小規模チームでの試験運用を挟むと、想定外の消費増加を防ぎやすい。
Q3. TPM/RPMの目安表通りに申請すれば十分ですか？
A. 目安表はあくまで組織全体の集計基準であり、個々のユーザーが厳密にこの枠内に収まる設計にはなっていない。研修やハンズオンのように短時間で多人数が同時にClaude Codeを使う場面では、公式ドキュメントも「より高めのTPM割当が必要になる場合がある」と補足している。定常利用の目安表に加えて、繁忙期のピーク利用を想定した余裕枠を確保しておくことが望ましい。
Q4. 導入初期にコストを見積もる際、参考になる数字はありますか？
A. 公式ドキュメントはエンタープライズ導入の実績値として、開発者1人あたり平均で1日約13ドル、月あたり150〜250ドル程度、利用者の90%は1日あたりの支出が30ドルを下回るという水準を示している。ただしこれはあくまで参考値であり、Agent Teamsの利用有無やスケジュールタスクの多寡によって大きく変動する点には注意したい。
まとめ: 導入前に確認すべき5つの数字
全社導入のコスト設計は、感覚ではなく公式ドキュメントが提示する具体的な数字を起点に進めるべきだ。契約形態別の支出レポート取得経路、Loops内訳での消費上位タスク、promptCacheTtl/subagentPromptCacheTtlの設定値、Agent Teamsの約7倍という消費倍率、チーム規模別のTPM/RPM目安——この5点を導入前チェックリストとして扱えば、請求書を見て青ざめる事態は避けやすくなる。エクスポートした支出CSVをそのままClaudeに渡し、次のようなプロンプトで異常値を洗い出すのも実務上有効だ。
この支出CSVを分析して、直近1ヶ月で突出して支出が多いメンバー・
ワークスペースを3件挙げて、Agent Teamsやスケジュールタスクの
利用が原因になっていないか仮説を立てて
