Claude Code を Claude Pro や Max のサブスクで使い、claude -p や cron、GitHub Actions、n8n から自動で呼び出している方にとって、2026 年 6 月 15 日以降の課金構造はこれまでと別物になります。同じ Claude Code バイナリでも、対話的に使った場合と非対話で呼び出した場合では消費する課金枠が分かれるという、運用上の重要な変更です。
Anthropic は Claude の有料プランで利用できる Agent SDK・claude -p・GitHub Actions の課金枠を、対話的な Claude Code 利用とは別枠の「Agent SDK 月額クレジット」へ分離します。サブスクで API 費用を抑えてきた方ほど、自動化部分の費用が「サブスクに含まれるとは限らない構造」へ変わる影響を受けます。
これ、本当に迷惑な話ですよね。多くの方にも多大な影響を及ぼすのではないでしょうか・・・
本記事は、対話 (Claude Code 対話 CLI) / 非対話実行 (claude -p) / Agent SDK / 自動化運用 (cron, n8n, Actions) の 4 区分マトリクスで「自分の構成のどこが対象になるか」を判別する軸を提示します。その上で、実行範囲・課金範囲・責任範囲を切り分ける設計指針までを整理します。
料金額・開始日・対象範囲は Anthropic の Help Center と Agent SDK ドキュメントの公式情報を根拠とし、トークン換算や「n8n から呼ぶ場合」など公式が明記していない論点は推論レベルとして区別します。「Claude Code が使えなくなる」「サブスクが完全に無意味になる」といった断定や、回避策の推奨は行いません。
ChatGPT 月額・API・ローカル LLM の 3 モデル整理を踏まえた背景として、ChatGPT月額・APIとローカルLLM、何が違うのか：AIの使い方は3種類ある を前提に読むと、本記事の「サブスク内クレジットの分離」軸が把握しやすくなります。
Agent SDK 月額クレジット制度と2026年6月15日からの変化
/ GitHub Actions の課金枠を、対話的な Claude Code 利用とは別枠の「Agent SDK 月額クレジット」へ分離します。本セクションでは、制度の概要と公式情報の所在、6 月 15 日を境に変わる課金経路、公式情報と非公式情報の分け方を整理します。
制度の1行整理と公式情報の所在
制度の核は「対話的 Claude Code はサブスク使用制限を従来通り消費し、claude -p / Agent SDK / GitHub Actions は別枠の月次 Agent SDK クレジットを消費する」という分離です。公式の根拠は support.claude.com の Help Center 記事 (en/articles/15036540) と、code.claude.com 上の Agent SDK ドキュメントにあります。
公式情報を読むときは、サブスク使用制限と Agent SDK クレジットが「別枠」であるという点が出発点になります。これまでサブスクの中で一括していた利用枠を、対話的利用と非対話実行で 2 つに割る変更だと捉えると、自分の構成のどこに影響が出るかを判別しやすくなります。
2026年6月15日を境に変わる課金経路
6 月 15 日以前は対話・非対話を問わず Claude Code 系のすべての利用がサブスク使用制限を消費していましたが、6 月 15 日以降は対話だけがサブスク使用制限の枠に残り、それ以外は別枠のクレジットを消費する構造に変わります。
つまり、同じ Claude Pro / Max を契約していても、自動化フローの中で claude -p を呼んでいた構成は、6 月 15 日を境に「サブスク内クレジット枠」と「Agent SDK クレジット枠」のどちらを消費しているかを意識する必要があります。月内にどれくらい呼び出しているかを把握していないと、月初に静かにクレジットが尽きるという事態が起こり得ます。
この表の「項目」は、Claudeをどの経路で使うか、つまり「Claudeの呼び出し方」を整理したものです。
今回のAgent SDK月次クレジットの対象になるのは、主に人間が画面を見ながら使うClaudeではなく、コマンドやSDKから非対話で実行する使い方です。 Claudeの利用経路と今回の対象範囲
| 項目 | 説明 | 今回の対象 |
|---|---|---|
| Claude Chat | ブラウザやアプリで会話するClaude | |
| Claude Code 対話利用 | ターミナルやIDEで、人間が見ながら操作するClaude Code | |
| claude -p | コマンドから非対話でClaudeに処理させる実行方法 | ● |
| Agent SDK | アプリや自動化処理からClaudeエージェントを動かすための開発者向け仕組み | ● |
| Claude Developer Platform APIキー | APIキーを使う従量課金API |
今回の変更の正体
今回の変更は、APIキーを新しく発行して使う話ではありません。
Claudeサブスクアカウントの中で、対話利用と自動実行の利用枠が分かれる、と見ると整理しやすくなります。
Claudeサブスク内の利用枠
Claudeサブスクアカウント ├─ 対話利用枠 │ └─ Claude / Claude Code 対話利用 │ └─ Agent SDK月次クレジット ├─ claude -p ├─ Agent SDK └─ Agent SDK製サードパーティアプリ
つまり、Claude Codeを人間が見ながら操作する使い方と、claude -p や Agent SDK を使って自動実行する使い方は、同じClaude利用でも料金管理上は分かれていきます。
ここを混同すると、「Claude CodeがAPI課金になる」という誤解につながります。正確には、APIキーを使った従量課金APIそのものになるのではなく、Claudeサブスク内にあるAgent SDK月次クレジットを消費する扱いです。
claude -p はAPI課金になるのか
claude -p は、Claudeサブスクの通常利用枠ではなく、Agent SDK月次クレジットを消費する扱いになります。
そのため、APIキーを使った従量課金APIそのものになるわけではありません。ただ、利用者の感覚としては、対話利用とは別の枠で消費されるため、自動実行の回数や処理量を見ておく必要があります。
Agent SDKクレジットはAPIキーなのか
違います。新しいAPIキーを申請してもらう話ではありません。Claudeサブスクのアカウントに紐づく月次クレジットです。
APIキー利用とAgent SDKクレジットの違い
APIキー利用 └─ Claude Developer Platform の従量課金 Agent SDKクレジット └─ Claudeサブスクアカウントに付く月次クレジット
APIキーを発行して外部アプリや自作処理から使う場合は、Claude Developer Platform側の従量課金として扱います。
一方で、Claudeサブスクアカウントに付くAgent SDK月次クレジットは、claude -p や Agent SDK の利用をサブスク内の別枠で管理するための仕組みです。
どうやって支払うのか
公式情報で確定できるのはここまでです。
Agent SDK月次クレジットの消費と追加利用
Agent SDK月次クレジットが残っている間 └─ クレジットから消費 Agent SDK月次クレジットを使い切った後 ├─ extra usage が有効 │ └─ 標準APIレートで追加使用量として扱われる │ └─ extra usage が無効 └─ 次のクレジット更新まで Agent SDK リクエストが停止
「サブスク時のカードから勝手に引かれる」とは、公式情報だけでは確定できませんが、Agent SDK月次クレジットを使い切った後は、extra usage を有効にしている場合のみ、標準APIレートで追加使用量として扱われるようです。
extra usage を有効にしていない場合、Agent SDKリクエストは次のクレジット更新まで停止します。そのため、「クレジットを超えたら必ず勝手に追加請求される」ということではありません。追加利用を有効にしているかどうかが分岐点になります。
extra usage は、Claude の Settings > Usage から有効化する設定です。
公式情報上、コマンドで extra usage の有効・無効を切り替える仕組みは確認できませんでした。
Agent SDK月次クレジットを使い切った後は、extra usage が有効な場合だけ、標準APIレートで追加使用量として扱われます。extra usage が無効な場合は、次のクレジット更新まで Agent SDK リクエストが停止します。
extra usage の設定場所
extra usage は、Claude Code のコマンドで切り替える設定ではありません。Claude の設定画面から確認します。場所は、左メニューの「使用量」です。
extra usage の確認場所
Claude
└─ 設定
└─ 使用量
└─ 追加使用量
画面下部に「追加使用量」という項目があります。
ここに「制限に達した場合でもClaudeを使い続けられるよう、追加使用量を有効にしてください」と表示されており、右側にトグルがあります。
このトグルが灰色でオフになっている場合、extra usage は無効です。
その状態では、Agent SDK月次クレジットを使い切っても、自動的に追加使用量へ流れず、次のクレジット更新まで Agent SDK リクエストが停止する扱いになります。
追加請求を避けたい場合は、この「追加使用量」を有効にしないことが重要です。
公式情報と非公式情報を分けて読む方針
料金額・開始日・対象範囲は support.claude.com の公式記述に基づいて扱い、Reddit / X / 個人ブログの反応は世間の反応として参照に留めます。本記事ではこの区別を明示しながら進めます。
公式の根拠で確認できているのは「料金額 (プラン別月次クレジット)」「開始日 (2026 年 6 月 15 日)」「対象範囲 (claude -p / Agent SDK / GitHub Actions)」「extra usage の二択 (有効=API 料金で続行 / 無効=月次更新まで停止)」です。一方、$1 あたりのトークン換算、クレジット枯渇時の通知挙動、「n8n の shell ノードから呼ぶ場合」のような第三者ツール固有の挙動は公式に明記されていません。本記事ではこれらを推論レベルとして注記しながら進めます。
対話利用 (Claude Code) と非対話実行 (claude -p) の課金分離
Claude Code 対話 CLI への影響範囲
対話的に Claude Code を使う利用形態 (ターミナルから対話して、コードを書きながらリアルタイムにプロンプトを送る使い方) は、6 月 15 日以降もサブスク使用制限内で動く扱いと公式に明示されています。
つまり、エディタや iTerm から Claude Code を起動し、人間が画面を見ながらプロンプトを送り、レスポンスを読んで次の指示を考えるという通常の使い方は、6 月 15 日以降も従来通りのサブスク枠で動きます。Claude Code を「対話的開発支援」として使う限り、今回のクレジット制度導入による直接の影響は限定的です。
claude -p の用途と非対話実行の位置づけ
claude -p は Claude Code CLI の非対話実行モードで、スクリプトや自動化フローから単発のプロンプトを実行するために使われます。CI / cron / シェルスクリプト経由の利用が代表例です。
具体的には、シェルスクリプトの中で claude -p "<プロンプト>" のように呼び、結果を標準出力で受け取り、後続の処理に渡すといった使い方です。人間が画面を見て次の指示を考える対話モードと異なり、トリガーから完了まで一括で走る点が特徴で、これが「Agent SDK 系」と同じ枠で扱われる根拠になります。
同じバイナリで消費先が変わる構造
同じ Claude Code バイナリでも、対話モードで呼ぶか -p 付きで呼ぶかによって、6 月 15 日以降は消費される課金枠が変わります。同じコマンドの中で消費先が分岐する点が、運用上の主要な落とし穴です。
たとえば、開発時は対話 Claude Code でコードを書き、CI で claude -p を使ってコミットメッセージを自動生成する構成にしている場合、6 月 15 日以降は前者がサブスク使用制限、後者が Agent SDK クレジットを消費します。「同じツールを使っているから同じ枠で課金される」という直感はもう成り立たないため、自動化スクリプトの中で claude コマンドがどう呼ばれているかを 1 行ずつ確認することが第一歩になります。
Agent SDK と third-party アプリ・API キー直叩きの違い
の SDK で、claude -p と同じ Agent SDK クレジットを消費します。本セクションでは Agent SDK の対象範囲、Agent SDK 製 third-party アプリの境界判定、API キー直叩き経路との違いを順に確認します。
Agent SDK の用途と対象範囲
Agent SDK は code.claude.com のドキュメントで「対話 (CLI) / 非対話 (SDK)」の 2 インターフェースとして整理されており、CI/CD パイプラインやプロダクション自動化が主用途と明示されています。GitHub Actions 連携 (Claude Code GitHub Actions) も同じクレジットを消費する対象として公式に挙げられています。
Agent SDK は Python / TypeScript の SDK として提供され、Claude Code バイナリを介さずに直接 SDK 経由で Claude を呼び出す構成です。CI/CD パイプライン内で自動的にレビューやテスト生成、コード変換を行う用途を想定しています。サブスクとひも付いた認証で呼び出している限り、消費される枠は Agent SDK クレジットになります。
Agent SDK 製 third-party アプリの境界判定
Agent SDK で構築されたサードパーティアプリも Agent SDK クレジット対象になりますが、どのアプリが対象になるかは利用者から見ると判別しにくい場合があります。利用しているツールのドキュメントで認証経路を確認するのが安全です。
判定の起点は「そのアプリが何で認証しているか」です。Claude Pro / Max のサブスクアカウントで OAuth ログインして使う場合、内部で Agent SDK を経由していればサブスクの Agent SDK クレジットを消費する可能性が高くなります。一方、ANTHROPIC_API_KEY を入力する形式のツールであれば API 課金体系で動きます。アプリ側のドキュメントで「ログイン方式」「API キー入力欄」の有無を確認するのが実用的な判定方法です。
ANTHROPIC_API_KEY 直叩きが対象外である理由
ANTHROPIC_API_KEY を使って Anthropic API を直接呼ぶ構成 (Claude Platform / Console 経路) はサブスクとは独立した API 課金体系で動いており、Agent SDK クレジットとも対話利用とも別枠で扱われます。サブスクのクレジットを消費しない代わりに、トークン量に応じた API 通常料金が発生します。
ここはサブスク / API / ローカル LLM の 3 モデル整理でいう「API 課金」の領域に該当します。Claude Pro / Max を契約していても、API キー直叩き経路はそのサブスクとは別ラインで請求が立つため、自動化部分を API キー経路にしているとサブスクのクレジット枯渇とは無関係に API 料金が積み上がります。この構造を踏まえると、6 月 15 日以降の自動化運用設計は「サブスク内クレジット枠で回すか / API 課金経路で回すか / どこを対話に残すか」の三択を意識する必要があります。
n8n / cron / GitHub Actions で Claude を呼ぶ自動化運用への影響
自動化運用の中心となる cron / GitHub Actions / n8n / CI から Claude を呼ぶ構成は、認証経路によって 6 月 15 日以降の挙動が変わります。本セクションでは代表的なケース、n8n shell ノードから呼ぶケースの推論レベルの扱い、クレジット枯渇通知が公式未記載であることに伴う運用リスクを整理します。
cron / GitHub Actions で claude -p を呼ぶケース
cron や GitHub Actions から claude -p を呼んでいる構成は、公式に明示された対象範囲に入ります。6 月 15 日以降は Agent SDK クレジットを月内で消費し、枯渇時の挙動は extra usage 設定に依存します。
cron で日次バッチを回したり、GitHub Actions の workflow で PR レビューや CI 内コード変換に claude -p を使っている構成は、6 月 15 日を境にサブスク使用制限ではなく Agent SDK クレジットの消費に切り替わります。Pro プランで月 $20 のクレジット、Max 5x で月 $100、Max 20x で月 $200 という枠内で動く構造になるため、月の使い切り想定量と現在の呼び出し回数の対応をあらかじめ把握しておく必要があります。
n8n shell ノードから呼ぶケースの推論レベル
n8n の shell ノードから claude -p を起動するケースについては、Anthropic 公式は「n8n から呼ぶ場合」と明記していません。claude -p 自体が対象である以上、n8n shell ノード経由でも対象になると推論できますが、公式断定情報ではない点に注意が必要です。
API 直叩きで n8n から AI を呼ぶ場合の課金構造は n8nでAI自動化するとAPI課金が膨らむ理由：構造と用途別の月額試算 で扱った通り、トークン量に応じた API 料金がそのまま積み上がります。これに対し、n8n の shell ノードからサブスクで認証された claude -p を呼んでいる場合は、6 月 15 日以降は Agent SDK クレジット側に乗ると推論できます。ただしこれは公式断定ではないため、運用上は両方の経路を計測できるように準備しておくのが安全側の判断になります。
クレジット枯渇通知が公式未記載という落とし穴
クレジット枯渇時にユーザーへどのように通知されるかは公式に明示されていません。cron や Actions が静かに月初から停止していたという事態を避けるには、自前で利用量モニタリングと通知設計を入れる必要があります。
公式ドキュメントには「extra usage が無効ならクレジット枯渇時に月次更新まで停止する」という記述はある一方、停止前後のアラートやしきい値通知については読み取れる情報がありません。本番運用で cron や Actions に claude -p を組み込んでいる場合、何の通知もないまま自動化が止まり、翌月の更新まで気づかないという落ちが現実的なリスクとして考えられます。自前で呼び出し回数のログを取り、しきい値を超えたら Slack / メール等に通知する仕組みを別系統で用意する設計が求められます。
Pro / Max 5x / Max 20x のクレジット枠と extra usage 判断軸
Max 5x の月次 $100 クレジットがどれだけ自分の用途に足りるかは、$1 あたりのトークン換算が公式未記載のため正確には断定できません。本セクションでは Pro / Max 5x / Max 20x のクレジット枠の意味、サブスクの使用制限と Agent SDK クレジットの違い、枯渇時の extra usage 二択を順に整理します。
プラン別月次クレジット ( / 0 / 0) の意味
公式記載のプラン別月次クレジットは Pro $20 / Max 5x $100 / Max 20x $200 / Team 標準 $20 / Team プレミアム $100 / Enterprise 標準 $20 / Enterprise プレミアム $200 です。繰り越し不可、個人帰属、チーム間共有不可、claim (opt-in) 必須という性質も併記されています。
ここで注意したいのは「クレジット」と書かれていても、$1 あたりのトークン換算は公式に記載されていない点です。同じ $100 でも、どの程度のトークン量を回せるかはモデル選択や呼び出し方によって変動するため、現時点では「自分の月次呼び出し量がこの枠で足りるかどうか」は実機検証でしか確認できません。本記事ではトークン換算の断定は避け、プラン別の枠の大小として捉えます。
subscription limits と Agent SDK credit の違い
サブスクの使用制限 (subscription limits) は対話的 Claude Code の利用量を月単位で管理するもので、6 月 15 日以降も対話利用はこの枠を消費します。Agent SDK クレジットはそれとは別枠で、非対話実行・SDK・Actions の利用量を管理します。両者を「同じ枠の延長」と捉えないことが運用判断の起点になります。
実務的には、対話 Claude Code でコードを書く時間と、自動化フローで claude -p を回す時間を分けて月次の利用量を把握する必要があります。サブスク使用制限が満杯になっても Agent SDK クレジットは別枠で残るし、その逆もあるという関係性です。両者をまとめて「サブスクで足りる / 足りない」という議論に乗せないことが、6 月 15 日以降の運用設計の出発点になります。
クレジット枯渇時の extra usage 二択
クレジットを使い切った場合、extra usage を有効にしていれば API 通常料金で課金が続き、無効にしていれば月次更新まで停止します。本番自動化なら有効化、検証用途なら無効化が安全側の運用と考えられますが、上限設定の有無や課金通知の挙動は公式未記載のため、想定外の料金請求を防ぐ別系統の監視を併設する必要があります。
extra usage を有効にする場合、サブスク枠を超えた分は API 通常料金で課金される構造になります。本番運用で「クレジット枯渇で自動化が止まると業務影響が大きい」場合は有効化が現実的ですが、上限設定 (月内のハードリミット) の挙動が公式に明示されていない以上、自前の利用量モニタリングを併設しないと想定外の請求が発生する余地が残ります。検証用途や個人利用なら、まず無効のまま枠内で運用する選択肢も合理的です。
個人開発者が見直すべき運用設計と blog-agent 型半自動運用
個人開発者が今回の制度変更で取るべき行動は、料金プランを切り替えることよりも、対話・半自動・完全自動の作業を分けて運用設計を見直すことです。本セクションでは設計の切り分け方、blog-agent 型半自動運用で確認すべき項目、そしてサブスクで API 費用を避ける設計の限界と次の設計軸を整理します。
対話作業 / 半自動作業 / 完全自動作業の切り分け
対話作業は人間が画面を見ながら判断を入れる範囲、半自動作業はトリガーが手動で実行が自動の範囲、完全自動作業は cron や CI などで人間の介在なく回る範囲です。それぞれが消費する課金枠が 6 月 15 日以降は別になるため、運用設計の最初に区別が必要です。
対話作業はサブスク使用制限、半自動作業は人間がトリガーするものの実体が claude -p ならば Agent SDK クレジット、完全自動作業は cron / Actions 経由ならば Agent SDK クレジット、API キー直叩きなら API 課金体系という整理になります。同じ仕事の中でも「画面を見て判断する作業」と「走らせるだけの作業」がどう混ざっているかを書き出すと、6 月 15 日以降に費用がどこに流れるかが見えるようになります。
blog-agent のような半自動運用で確認すべき項目
blog-agent のように人間がコマンドを起動し、内部で自動処理が走る構成は、起動経路 (対話 Claude Code か claude -p 経由か API キー直叩きか) によって課金経路が変わります。各処理の認証方式・呼び出し経路を 1 行ずつ洗い出すことが、6 月 15 日以降の挙動を確認する出発点です。
本リポジトリ (blog-agent) は、人間が /blog-plan や /blog-draft を対話 Claude Code 上で起動し、内部で Markdown 生成や画像生成スクリプトを走らせる構成です。対話 Claude Code から起動している限り、現状はサブスク使用制限を消費する側に分類されると考えられます。ただし、内部で claude -p や API キー経由のスクリプトを呼ぶよう拡張すると、その呼び出し経路は別の枠を消費することになります。半自動運用を設計するときは「起動は人間 / 実行は自動」というだけで安心せず、内部の API 呼び出しが何で認証されているかまで確認する必要があります。
サブスクで API 費用を避ける設計の限界と次の設計軸
Claude Pro / Max サブスクを使えば API 課金を完全に回避できる、という設計は 6 月 15 日以降は前提が変わります。自動実行を増やすほど Agent SDK クレジットの使い切り・extra usage 発動・自動停止のいずれかに当たる可能性が高まるため、「実行範囲・課金範囲・責任範囲」を先に切り分ける設計に切り替える必要があります。
「サブスクで API 費用をまるごと避ける」という設計は、対話的利用に限れば 6 月 15 日以降も成立します。一方、自動化部分まで含めて「全部サブスクで賄う」という前提は、Agent SDK クレジットの枠内に収まるかどうかという別の制約に置き換わります。クレジットが尽きたとき、extra usage を有効にして API 課金で続行するのか、無効のまま月次更新まで止めるのか、あるいは一部の自動化を API キー経路に切り分けるのかという判断は、運用上の「責任範囲」の設計問題として現れます。
まとめ
本記事では Agent SDK 月額クレジット制度の概要と、対話 / 非対話実行 / Agent SDK / 自動化運用の 4 区分マトリクス、個人開発者が見直すべき運用設計までを整理しました。AI 自動化は作るだけでなく、実行回数・課金範囲・人間確認の残し方を先に分けて設計することが、6 月 15 日以降に静かな停止と想定外の課金を避ける条件になります。
公式に明示されているのは料金額・開始日・対象範囲・extra usage の二択であり、トークン換算・通知挙動・第三者ツール固有の挙動は公式未記載という前提を保ったまま、自分の構成のどこに今回の制度が乗るかを 1 行ずつ確認することが最初の一歩です。「対話 Claude Code」「claude -p / Agent SDK」「API キー直叩き」の 3 経路がいま自分のフローのどこに分布しているかを見えるようにすることで、6 月 15 日以降の挙動はかなり具体的に予測できるようになります。
