Claude Agent SDKクレジットは一時停止中｜claude -p・GitHub Actionsの課金は今どうなっているか【2026年9月時点】

2026年6月15日から予定されていた「Claude Agent SDK・claude -pの利用を専用の月次クレジットに分離する」変更は、施行当日にAnthropicが一時停止を発表し、2026年9月25日時点でも適用されていません。 Anthropic公式ヘルプの冒頭には6月15日付の更新として「For now, nothing has changed」と明記され、Agent SDK・claude -p・サードパーティアプリの利用は引き続きサブスクの使用量上限から消費されること、発表済みだった月次クレジットは受け取れないことが記載されています（出典: Use the Claude Agent SDK with your Claude plan（Anthropic公式ヘルプ））。

つまり、claude -pやAgent SDKでバックグラウンド自動化を回している開発者にとって、現時点で課金の仕組みは何も変わっていません。 クレジットのopt-inも、「利用クレジット（usage credits）」の設定変更も、今すぐ必要な作業ではありません。ただし公式は「計画を見直しており、更新がある場合は適用前に告知する」としており、新しい施行日や内容は示されていません。

本記事は、「今の扱い」と「当初発表された案」を分けて整理し、再開に備えて今のうちにできる準備をまとめた実務ガイドです。当初案の説明は、再開時の参考として残しています。Agent SDKそのものの実装方法はClaude Agent SDK実装ガイド、Claude Code全体の料金体系はClaude Code料金プラン完全ガイドを参照してください。

2026年6月15日に何が起きたのか

6月15日に施行予定だった変更は、施行当日に一時停止されました。 この変更は2026年5月にAnthropicが発表したもので（ITmediaの報道）、ProやMaxプランの使用量上限を消費していたプログラム経由の利用を、専用の月次クレジットから消費する方式に分離する内容でした。

公式ヘルプの冒頭に追加された6月15日付の更新の要点は次のとおりです。

• Agent SDKの利用に関する変更を一時停止する
• 現時点では何も変わっていない。Agent SDK、claude -p、サードパーティアプリの利用は引き続きサブスクの使用量上限から消費される
• 発表済みだった月次クレジットは受け取れない
• サブスクでの開発利用をよりよく支えられるよう計画を見直している。更新がある場合は、適用前に告知する
• ページ下部の説明は6月15日以前の内容を参照用に残したもので、6月15日には適用されない

2026年9月25日時点で、このページに新しい施行日や改定後の内容は記載されていません。

当初発表されていた内容（参考）

以下は一時停止前に発表されていた案です。現在は適用されていませんが、再開時の議論の出発点になる可能性があるため記録しておきます。

クレジットの対象とされていたのは、次の4つの利用形態でした。

1. 自分のプロジェクトでのClaude Agent SDK利用（Python・TypeScript）
2. claude -pコマンド（Claude Codeの非対話・ヘッドレスモード）
3. Claude Code GitHub Actions（PRレビュー・Issue対応などのCI連携）
4. Agent SDK認証を使うサードパーティアプリ（あなたのClaudeサブスクで認証する外部ツール）

当初案のプラン別月次クレジット額

出典: Use the Claude Agent SDK with your Claude plan（Anthropic公式ヘルプ、6月15日以前の内容として掲載）

当初案のクレジットの5つのルール

1. ユーザー単位で付与（チームでのプール・共有は不可）
2. 繰り越し不可（使い切らなかった分は月次リフレッシュ時に消滅）
3. 毎月の請求サイクルに合わせて自動リフレッシュ
4. 初回は自分でopt-in（クレーム）が必要（以降の更新は自動）
5. クレジット消費は他の課金ソースより先に行われる

当初案はなぜ対話枠と分離しようとしたのか

公式の説明を整理すると、当初案の設計意図は「対話的な利用枠を、バックグラウンド自動化に食い潰されないよう保護する」ことにありました。Agent SDKやclaude -pによる自動実行は、cronやCIで24時間動かせるため、対話利用とは消費量の桁が変わります。

裏返すと、一時停止中の現在は、自動化と対話利用が同じ使用量上限を共有しています。 自動化を多く回した日に、対話的なClaude Codeのセッションが使用量上限に達しやすくなる構造は今も変わっていません。

あなたは影響を受けるか — 利用形態別の判定表

現時点では、どの利用形態も課金の扱いは変わっていません。 下の表は「現在の扱い」と「当初案が再開された場合の扱い」を並べたものです。判定基準は「人間がその場で対話しているか、プログラムが自動で呼んでいるか」です。APIキー（従量課金）での利用はもともとサブスクと別会計のため、どちらの場合も無関係です。

公式の更新文が名指ししているのはAgent SDK・claude -p・サードパーティアプリの3つですが、「現時点では何も変わっていない」とあるため、当初案に含まれていたGitHub Actionsにも変更は適用されていません。

当初案が再開された場合に影響を受けるのは、次の3タイプの開発者です。

タイプ1: cron・スケジューラでclaude -pを回している人。 毎朝のレポート生成、定期的なログ解析、コンテンツの自動作成など。実行頻度×1回あたりの消費量によっては、当初案のPro $20枠では足りなくなる可能性があります（後述の試算参照）。

タイプ2: GitHub ActionsでClaude Codeを使っている人。 PR自動レビューやIssueトリアージをサブスク認証で動かしている場合、その消費がクレジット枠に移ります。クレジット枯渇時にCIが止まる設計リスクが生まれます（PR自動化やテスト自動化をCIに組み込んでいる方は要確認）。

タイプ3: Agent SDKで自社プロダクト・社内ツールを作っている人。 Agent SDKを自社プロダクトに組み込んでいる場合、開発・検証フェーズでサブスク認証を使っているならクレジット枠の対象になります。本番運用でAPIキーを使っているなら影響はありません。サーバー管理型のClaude Managed AgentsはAPIキー前提のため、こちらも対象外です。

逆に、Claude Codeをターミナルで対話的に使うだけの人、hooksで通知や自動フォーマットを入れているだけの人（hooks自体はトークンを消費しない）は、当初案でも何も変わらない位置づけでした。

【手順】自分の自動化コストを実測する

変更が一時停止中の今でも、「自分の自動化が月いくら分のトークンを消費しているか」を把握しておく価値はあります。 自動化は対話利用と同じ使用量上限を共有しているため、上限に達しやすい原因の切り分けに使えます。また公式は再開前に告知するとしているので、実測値があれば告知が出た時点ですぐに影響額を判断できます。

手順1: /costコマンドで直近セッションの消費を見る

Claude Codeのセッション内で/costを実行すると、そのセッションのトークン消費とドル換算の概算が表示されます。claude -pで実行しているスクリプトがあるなら、同じプロンプトを対話セッションで1回流して/costを確認するだけでも、1実行あたりの規模感がつかめます。

手順2: Consoleの使用量画面で月間合計を見る

Claude Consoleの使用量（Usage）画面やClaudeアカウントの使用量設定では、利用履歴を確認できます。現状の使用量画面の場所を把握しておくと、今後の変更後の監視もスムーズです。

手順3: ローカルログをコミュニティツールで集計する

Claude Codeはセッションログをローカル（~/.claude/projects/配下）にJSONL形式で保存しており、これを集計するコミュニティ製CLIツール（npmで配布されているccusageなど）を使うと、日別・モデル別のトークン消費とドル換算を一覧できます。過去1〜2ヶ月分の実績から月間消費を逆算できるのが最大の利点です。

# コミュニティ製ツールの例（日別の消費集計）
npx ccusage@latest daily

手順4: 自動化タスクを「種類別」に仕分ける

合計額だけでなく、どのタスクがいくら食っているかまで分解してください。判断の解像度が変わります。

• タスク名（例: 毎朝のレポート生成、PR自動レビュー、ログ解析）
• 実行頻度（回/日）
• 1回あたりの概算コスト（手順1〜3から）
• そのタスクは止まってもよいか（許容停止時間）

この仕分けが、後述の意思決定フレームの入力になります。

適用例: koromoの毎朝の記事自動作成ルーチンの場合

実例として、koromoでは毎朝9:00にリモートトリガーでヘッドレスセッションを起動し、SEO記事のドラフトPRを自動作成するルーチン（日次1実行）を運用しています。このタイプの自動化に上記手順を適用する場合の進め方はこうなります。

1. 同じ指示を対話セッションで1回流し、/costで1実行分の消費規模を把握する（記事生成のような長文出力タスクは、出力トークンがコストの過半を占めるのが典型です）
2. 「1実行コスト×月間実行回数（日次なら30）」で月額換算する
3. 日次1回・記事1本程度の自動化であれば、後述パターンAの計算が目安になります。ただし記事生成は定型レポートより出力トークンが重いため、パターンAの想定（出力5,000トークン）との差分を上乗せして見積もってください。「1回の実行で複数記事・複数リポジトリを処理する」「Opusを使う」場合は、パターンB/Cの式に自分の実測値を代入するのが確実です

ポイントは、月初に1度この計算をしておけば、残りはペース監視だけで済むことです。計測自体は30分もかかりません。

【試算】当初案のクレジットは何日もつか — プラン別シミュレーション

当初案の金額に当てはめると、軽量なcron自動化ならProの$20枠で十分余裕があり、CI連携を含む中規模運用はMax 5xの$100が分岐点、Opusでヘビーにエージェントを回す場合は$200でも足りない計算です。 再開時に金額が変わる可能性がある点に注意してください。以下は標準API料金（2026年6月時点: Opus 4.8 入力$5/出力$25、Sonnet 4.6 入力$3/出力$15、Haiku 4.5 入力$1/出力$5、いずれも100万トークンあたり。キャッシュ読込は入力の約0.1倍。出典: Anthropic公式料金ページ）を使った計算例です。キャッシュ書込コスト（通常入力の1.25倍）は簡略化のため省略しています。実際の消費はプロンプト設計とキャッシュ効率で大きく変わるため、必ず前節の実測と突き合わせてください。

パターンA: 軽量cron（1日1回・Sonnet 4.6）

毎朝1回、定型レポートを生成する想定。入力5万トークン（うち9割キャッシュ読込）、出力5,000トークン。

• 1回あたり: 新規入力 5K×$3/M + キャッシュ読込 45K×$0.3/M + 出力 5K×$15/M ≈ $0.10
• 月間（30回）: 約$3 → Pro $20枠で余裕（理論上は1日6回まで回せる計算）

パターンB: 中規模CI（1日10実行・Sonnet 4.6）

PR自動レビューを1日10本処理する想定。入力10万トークン（うち7割キャッシュ）、出力8,000トークン。

• 1回あたり: 新規 30K×$3/M + キャッシュ 70K×$0.3/M + 出力 8K×$15/M ≈ $0.23
• 月間（300回）: 約$70 → Pro $20では月の9日前後で枯渇。Max 5x $100が必要ライン

パターンC: ヘビーエージェント（1日20セッション・Opus 4.8）

長時間の自律エージェントを回す想定。入力20万トークン（うち8割キャッシュ）、出力2万トークン。

• 1回あたり: 新規 40K×$5/M + キャッシュ 160K×$0.5/M + 出力 20K×$25/M ≈ $0.78
• 月間（600回）: 約$470 → Max 20x $200でも不足。超過分は従量課金 or APIキー移行を検討

見落としがちなポイント: トークン量とコストは比例しない

エージェント型のワークロードでは、入力トークンの大半がプロンプトキャッシュからの読込です。キャッシュ読込は通常入力の約10分の1の単価のため、「トークン数では9割を占めるキャッシュが、コストでは半分以下」という逆転が普通に起きます。トークン数だけ見て「うちは絶対足りない」と慌てる前に、ドル換算での実測を必ず挟んでください。逆に、キャッシュが効いていない自動化（毎回コンテキストをフルで送り直す設計）は、この試算より大幅に高くつきます。

意思決定フレーム: 再開に備えた4つの選択肢

一時停止中の今は、現状維持で問題ありません。 以下は、当初案に近い形で再開が告知された場合に取れる選択肢です。月間消費の実測値とクレジット枠の差分をもとに、「超過額」と「止まったときの痛み」の2軸で選びます。

診断フロー

1. 実測月間消費 < クレジット枠の80% → 選択肢1。利用クレジットはOFFにして「枠内で止まる」安全設計にするか、保険としてONにするかだけ決める
2. 超過するが月数十ドル以内 → 選択肢2。ただし「利用クレジット」設定と支出上限を必ず確認
3. 超過が大きい・業務クリティカル → 選択肢3。Agent SDKは認証をAPIキーに切り替えるだけでコードはそのまま動く（ANTHROPIC_API_KEYの設定）。CI・本番ワークロードはこちらが本筋
4. 「そういえばこの自動化、要る？」と思ったタスクがある → 選択肢4。1回$0.5のタスクでも、誰も見ていないレポートなら月$15のムダ

重要なのは、タスク種別ごとに選択肢を変えてよいことです。「毎朝のレポートはクレジット内（1）、PRレビューはAPIキー（3）、使っていなかった実験cronは廃止（4）」のような組み合わせが現実解になります。なお選択肢3と4は、一時停止中の今でも、自動化が対話利用の使用量上限を圧迫している場合の対策として有効です。

「Codexに乗り換えれば解決」は本当か

当初の発表を受けて、OpenAIのCodex CLIなど他のコーディングエージェントへの移行を検討する声もありました。結論としては、「料金変更が理由の乗り換え」は多くの場合、割に合いません。変更自体が一時停止されたことに加え、移行には CLAUDE.md・スキル・hooks・MCP設定などの資産の作り直しコストがかかります。月数十ドルの差額のために移行工数を払うより、後述の最適化（モデル格下げ・キャッシュ設計）で消費自体を下げるほうが、ほとんどのケースで合理的です。乗り換えを検討するのは、料金ではなく機能・品質に不満がある場合に限るべきです。

opt-inと「利用クレジット」— 今は設定不要

一時停止中の現在、Agent SDKクレジットのopt-in（クレーム）はできず、そのための設定も必要ありません。 公式ヘルプは、発表済みだった月次クレジットは受け取れないとしています。当初案では次の2つの設定確認が必要とされていたため、再開時の参考として残します。

1. 当初案でのAgent SDKクレジットのopt-in（クレーム）

当初案では、クレジットは自動付与ではなく初回に自分で受け取り操作（opt-in）が必要で、以降の月次リフレッシュは自動とされていました。Team・Enterpriseでは対象ユーザーに案内メールが届く予定でした。

2. 「利用クレジット（usage credits）」のON/OFF

当初案で、クレジット枯渇時の挙動を決めるとされていたのがこの設定です。

• ON（有効）: クレジット枯渇後、超過分が標準API料金で従量課金される。自動化は止まらないが、課金が発生する
• OFF（無効）: クレジットを使い切った時点でAgent SDK経由のリクエストが停止。リフレッシュまで自動化は動かないが、クレジット超過による想定外の課金は発生しない

再開時にどちらを選ぶか — 「止まる」と「青天井」のトレードオフ

個人開発・実験用途ならOFFが無難です。コーディングエージェントの自動実行は、リトライループやコンテキスト肥大で消費が想定の数倍に膨らむ事故が起こり得ます。OFFにしておけば、最悪でも「リフレッシュまで自動化が止まる」だけで、クレジット超過起因の課金は発生しません。

一方、業務でCIや定例処理を止められない場合はONが必要ですが、その場合は支出上限（spending limit）の設定が用意されているかをあわせて確認し、あれば必ず設定して「止まらないが青天井でもない」状態を作ってください。

GitHub Actions・チーム利用の注意点

当初案が再開された場合、チーム運用には個人利用にはない2つの落とし穴があります。

落とし穴1: クレジットはプールできない

当初案のクレジットはユーザー単位で付与され、チーム内での合算・共有はできない仕様でした。「チーム5人で$100ずつ、合計$500の枠」にはならず、CIのジョブを実行する認証ユーザーのクレジットだけが消費されます。つまりGitHub Actionsの認証に使っているアカウントに消費が集中し、そのユーザーのクレジットだけが先に枯渇する構造です。公式も、チームで共有する本番の自動化にはAPIキーでの従量課金を勧めていました。CI用途は特定ユーザーのサブスク認証に相乗りさせるのではなく、APIキー（チームの予算で管理）への移行が設計として素直です。

落とし穴2: クレジット枯渇でCIが止まる

利用クレジットOFFの状態でクレジットが尽きると、Claude Code GitHub Actionsのジョブはリフレッシュまで失敗し続けます。PR自動レビューが「あると便利」レベルなら実害は軽微ですが、マージ条件に組み込んでいる場合はチーム全体の開発が止まります。マージブロックに使っているワークフローは、再開の告知が出た時点で、(1) APIキー認証に移行する、(2) ジョブ失敗時にレビューをスキップ扱いにするフォールバックを入れる、のどちらかを検討してください。

Teamプランのシート別クレジット

当初案では、Teamプランはシート種別でクレジット額が異なっていました（Standard $20／Premium $100）。自動化を動かすアカウントがStandardシートなら、その枠は個人のPro相当（$20）しかない点に注意が必要です。

使用量を長持ちさせる5つの最適化

同じ自動化でも、設計次第で消費は数分の1になります。 一時停止中の今は、自動化の消費がそのまま対話利用と同じ使用量上限を減らしているため、今すぐ見直す価値があります。効果の大きい順に挙げます。

1. モデルを格下げする — 定型処理にOpusは過剰です。Sonnet 4.6はOpus 4.8の4割減（入力$5→$3）、Haiku 4.5なら8割減（$5→$1）。分類・抽出・定型レポートはHaikuで十分なケースが多く、これだけで試算が一変します
2. プロンプトキャッシュを効かせる — システムプロンプトや参照ドキュメントなど不変部分を先頭に固定し、毎回変わる内容を末尾に置く構造にするだけで、入力コストが最大約10分の1になります。cron実行の間隔がキャッシュTTL（5分〜1時間）より長い場合はキャッシュが切れている点にも注意
3. 実行頻度を見直す — 1時間おきのジョブ、本当に1時間おきに必要ですか。日次で十分なものを毎時回していると、それだけで24倍の消費です
4. 出力を絞る — 出力トークンは入力の5倍の単価です。「詳細なレポート」を「変更点のみの差分レポート」に変えるだけで出力コストが激減します
5. コンテキストを渡しすぎない — リポジトリ全体を毎回読ませる設計は、キャッシュが効いていても無駄が大きい。対象ファイルを絞り込んでから渡す前処理を挟んでください

消費を監視する仕組みを最初に作る

最適化と同じくらい重要なのが消費の可視化です。「月の何日目で何%消費しているか」のペースが見えていれば、上限に達する前に気づけます。具体的には、(1) 週1回使用量画面を確認する習慣を作る、(2) 消費ペースが想定を大きく超えたら自動化の頻度を一時的に落とす、という簡単なルールで十分機能します。この仕組みは、将来クレジット制が導入された場合もそのまま残量監視に使えます。

現在の挙動と今後の見通し（2026年9月25日時点）

2026年9月25日時点で公式ヘルプから確認できる状況は次のとおりです。

• claude -p・Agent SDK・サードパーティアプリの利用は、従来どおりサブスクの使用量上限から消費される
• 発表済みだった月次クレジットは受け取れない（opt-inの操作も不要）
• 新しい施行日や改定後の内容は示されていない。公式は、更新がある場合は適用前に告知するとしている

claude -pが突然動かなくなった場合も、現時点ではクレジットの仕組みが原因ではありません。まずサブスクの使用量上限に達していないかを確認し、それ以外のエラーで止まった場合はClaude Codeエラー対処法50種の逆引きインデックスを参照してください。本記事は、公式ヘルプに更新があり次第内容を見直します。

よくある質問

まとめ — 今やること・再開に備えること

6月15日に予定されていた変更は一時停止され、2026年9月時点で課金の仕組みは何も変わっていません。 新しい施行日も示されていないため、慌てて設定や移行をする必要はありません。今やる価値があるのは、自動化の消費を把握して対話利用への圧迫を減らすことと、再開の告知に備えることです。

• 自分の利用形態を確認する（claude -p／Agent SDK／GitHub Actions／サードパーティアプリ）
• /cost・Console・ローカルログ集計で月間消費をドル換算で実測しておく
• モデル選択・キャッシュ・実行頻度を見直し、対話利用の使用量上限への圧迫を減らす
• マージ条件に入っているGitHub Actionsワークフローの認証方式を把握しておく
• 公式ヘルプの更新を定期的に確認する

Claude Codeの基本から運用までを体系的に押さえたい方はClaude Code完全ガイドも参照してください。

社内でのClaude Code・Agent SDK導入、自動化ワークフローのコスト設計やAPI移行の支援が必要な場合は、koromoのAI開発支援サービスまでお気軽にご相談ください。実運用しているからこそわかる落とし穴を含めて、導入から運用設計まで伴走します。