Claude Code の MCP plugin が 6/15 課金分離で月の費用を倍に押し上げる前に整備したい 5 つの実行可能なコマンド

Last updated at 2026-06-30Posted at 2026-05-31

2026年6月15日に Anthropic の claude -p と SDK の経路の課金が分離される予定でしたが、施行当日に一時停止されました(再実施に備えます)。公式の文書は淡々と「programmatic billing を Pool 2 に分離」と書いていますが、業界の解析の合図では light な負荷で（公式未確認の倍率）、重い Sonnet の自動の作業で（公式未確認の倍率）の費用の倍率の合図があります。

MCP plugin を業務で使っている方には、この境界で特定の経路の費用が突然伸びる事象が起きる可能性があります。本記事では、 6/15 の境界の前に 5 分以内で実行可能な 5 つのコマンドを整理します。本記事を読み終わった後の段で、自分の MCP plugin の構成が Pool 1 (対話) と Pool 2 (自動) のどちらに該当しているのか、そして6/15以降の費用の見積もりが具体な数字で出る経路を整備できます。

なぜ MCP plugin で費用が増えるのか

Anthropic の 6/15 課金分離の中心の articulate は、「対話の経路」 (Pool 1、 subscription の対象) と「自動の経路」 (Pool 2、公式 API の値段の換算) の分離です。

MCP plugin は2種類に分かれます。 1つめは utility 系の plugin (filesystem、 fetch、 sqlite、 postgres、 brave-search の系統) で、 OAuth の認証が不要、ローカルの実行、 Pool 2 の対象外。 2つめは cloud 系の plugin (Slack、 GitHub、 Gmail、 Shopify、 Linear の系統) で、 OAuth の認証が必須、リモートの実行、 Pool 2 の対象。

なお、6月15日以降の従量課金の具体的な倍率について、Anthropic公式の数値はまだ出ていない。外部のブログでさまざまな倍率が語られているが、出所が公式でない数値は当てにせず、後述のとおり自分のログの実数で測ってほしい。同じ作業の流れの中で、 cloud 系の plugin を持っているか持っていないかで、月の費用の境界が大きく分かれる経路が予想されます。

私の運用の事例で、 5月の月の段で MCP plugin の cloud 系の経路が累計の費用の約 18% を占めていました。同じ作業の流れを 6/15 以降に続けた場合の月の費用の見積もりは、ざっくりの計算で約 14 倍、つまり 5月の月の費用の約 18% の部分が 6/15 以降は約 250% の部分に膨れる経路の可能性があります。

5/30 段で起票されている関連の事案として、起票 #64022 (plugin hooks.json の 1× から 122× への重複の増殖) は、単一の plugin が複数の dispatch の経路で hook を発火する事象を articulate していて、 cloud 系の plugin が複数の同時の自動の経路を作る場面で費用の増殖の合図の補強になります。

5 つの実行可能なコマンド

コマンド 1. 現状の MCP の構成の取得

claude mcp list

このコマンドで、現在の MCP plugin の一覧と各々の認証の状態 (token / OAuth / utility) が表示されます。 cloud 系 ( OAuth ) と utility 系 ( ローカル ) の分類を、「自分の構成では何件が cloud 系なのか」と「累計で何件の MCP plugin が登録されているのか」の2軸で取得してください。

私の事例では、累計 12 件の MCP plugin のうち、 cloud 系が 5 件 (Slack、 GitHub、 Gmail、 Linear、 Shopify) で、 utility 系が 7 件 (filesystem、 fetch、 sqlite、 postgres、 brave-search、 sequential-thinking、 git) の構成です。 cloud 系 5 件が 6/15 以降の Pool 2 の対象。

コマンド 2. 自動の経路の数の確認

ls ~/.claude/projects/ | wc -l

このコマンドで、現在の累計のセッション数が表示されます。各セッションは独立な文脈の窓を持つため、自動の経路の数の合図として利用できます。

加えて、同じ作業の流れを長期間続けている場合は次のコマンドで過去30日の活動の合図を取得してください。

find ~/.claude/projects/ -type f -name "*.jsonl" -mtime -30 | wc -l

過去30日の累計のセッションの記録の数の合図で、自動の経路の継続の量の判定の入力。

コマンド 3. `ccusage` で過去7日の MCP の傾向の取得

ccusage は Claude Code の累計の token 消費の集計の道具です。累計 14,647 stars の経路で、 5月の段で大幅に整備されました。

npx ccusage

このコマンドで、過去7日のセッション別、モデル別、ツール別の集計が表示されます。「MCP plugin に関連の tool が累計の何 % の token を消費しているか」の合図の取得が、 6/15 以降の費用の見積もりの中核の入力。

私の事例では、過去7日の累計 token の中で MCP plugin の tool の経路が約 18% でした。残りは Bash の tool が約 35%、 Read / Edit / Write の tool が約 28%、 Task / Agent の tool が約 14%、その他が約 5% の構成。

コマンド 4. `claude --print` のテストの実行で Pool 2 の対象の確認

claude --print "list 3 recent files in my downloads folder"

このコマンドは --print で実行される対話の経路の単発の合図です。 6/15 以降は --print の経路が Pool 2 の対象になります。自分の自動の作業の流れで --print の経路を使っているかを確認してください。

加えて、 SDK の経路 (Anthropic SDK の npm と Python の package) で実装した自動の経路も Pool 2 の対象です。 cron や launchd や監視の道具から呼び出している SDK の経路の一覧を整備してください。

私の事例では、 4 件の cron の経路 (毎時、日次、週次、月次) と 2 件の launchd の経路 (起動時、 sleep からの復帰時) で、累計 6 件の自動の経路が Pool 2 の対象。各経路の累計の token 消費を ccusage で取得し、 6/15 以降の費用の見積もりの基礎の数字に。

コマンド 5. cc-safe-setup の `cache-creation-drift-detector` の取り込み

cc-safe-setup の examples/cache-creation-drift-detector.sh は、単発のリクエストごとに cache_creation_input_tokens を蓄積して、直近 200 サンプルの平均と比較し、既定の 1.25 倍を超えた時に警告を発火する PostToolUse の hook です。 6/15 以降の Pool 2 の自動の経路の異常な消費の検出の前提の整備。

npx cc-safe-setup
# settings.json に追記:
# {
#   "hooks": {
#     "PostToolUse": [{
#       "matcher": "",
#       "hooks": [{ "type": "command", "command": "bash ~/cc-safe-setup/examples/cache-creation-drift-detector.sh" }]
#     }]
#   }
# }

20 サンプル以上の履歴が必要なため、最初の数日間は警告が発火しません。 6/15 の前に取り込むことで、 6/15 以降の異常の合図の即時の検出の経路が整備されます。

加えて、 quota-anomaly-detector.sh (セッションをまたぐ消費の率の異常の検出) と session-rate-monitor.sh (単一セッションの絶対上限の警告) の 2 件も同時に取り込むと、 3 軸の独立な合図で異常を覆う構造になります。

3 つの利用者の側の対応の経路

5 つのコマンドで現状の構成と Pool 2 の対象の合図を取得した後、以下の 3 つの対応の経路を判断の入力としてご検討ください。

経路 1. cloud 系の MCP を utility 系に切り替える

5 つの cloud 系の plugin のうち、機能の重複と利用の頻度の合図を取得して、 utility 系の代替に置き換え可能な plugin を identify します。例えば、 GitHub の cloud plugin を CLI の gh の経路で utility 系の subprocess に置き換える、 Slack の cloud plugin を Webhook の経路で fetch の utility に置き換える経路。

私の事例では、 5 件の cloud 系のうち 2 件 (GitHub、 Linear) が utility 系の経路に置き換え可能で、残りの 3 件 (Slack、 Gmail、 Shopify) は cloud 系の継続が必要の判定。結果として cloud 系の経路の割合を 18% から約 8% に絞ることで、 6/15 以降の月の費用の見積もりが約 14 倍の倍率の対象部分が小さくなる経路の整備。

経路 2. 自動の経路の数を絞る

6 件の自動の経路の中で、真に必要な経路は何件かの判断。例えば、毎時の cron の経路を日次に変更することで、 24 倍の token 消費の削減の経路。日次の launchd の経路を週次に変更することで、 7 倍の token 消費の削減の経路。

私の事例では、 4 件の cron のうち 1 件 (毎時の monitoring) を 6 時間ごとに変更し、 1 件 (日次の summary) を週次に変更。結果として自動の経路の累計の token 消費が約 60% に減少。 6/15 以降の月の費用の見積もりの直接の縮小。

経路 3. API の直接の鍵への切替の判断の入力の整備

6/15 以降の Pool 2 の月次の枠 (20 米ドルから 200 米ドル) を超過する見積もりの場合、 API の直接の鍵 (Anthropic API key) への切替が費用の経路の整備の候補になります。 API の直接の鍵の利用は subscription の枠と別の経路で、自動の経路の費用の予測の合図が明示的になります。

切替の判断の入力の中核は、過去30日の ccusage の累計と、 API の直接の利用の場合の推定の費用の比較。 Migration Playbook V2 (¥1,500) は、この判断の入力の整備の14段の手順を articulate しています。

まとめ

6/15 の課金分離は、 MCP plugin の cloud 系の経路を持つ利用者の方の月の費用に大きな影響を与える可能性があります。 5 つの実行可能なコマンドで現状の構成を取得し、 3 つの対応の経路の判断の入力を整備することで、 6/15 以降の費用の見積もりの予測と整備の経路が手元に整います。

本記事の 5 つのコマンドは累計 5 分以内で実行可能の経路です。 6/15 まで残り 15 日。早めの整備で、課金分離の発火の段で慌てない経路の整備を。

800時間の Claude Code 運用データから、トークン消費の削減・複数ベンダー(Claude / Codex / Gemini / Copilot)の並行運用・事故の検知と復旧・サブエージェントの沈黙の失敗対策など、主題別の手引きを公開しています。気になる人は著者の本の一覧から、価格と評価を見て選べます。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up