Claude Agent SDKクレジット完全ガイド｜6月15日からclaude -p・GitHub Actionsの課金はこう変わる【2026年】

2026年6月15日から、Claude Agent SDK・claude -p・Claude Code GitHub Actionsの利用は、Claudeプランの使用量上限にカウントされなくなり、専用の月次クレジット（Agent SDKクレジット）から消費される方式に変わります。 Agent SDKクレジットとは、Claudeの有料プランに付与される「プログラムからのClaude利用」専用の月次利用枠で、Pro $20／Max 5x $100／Max 20x $200相当が毎月付与されます。サブスクの使用量上限自体は変わらず、Claude Code・Claude Cowork・Claudeアプリの「対話的な利用」のために引き続き確保されます（出典: Anthropic公式ヘルプ）。

この変更で影響を受けるのは、claude -pやAgent SDKでバックグラウンド自動化を回している開発者です。これまでサブスクの定額枠でまかなえていた自動実行が、6/15以降はクレジット枠から消費され、使い切ると「標準API料金で従量課金」または「停止」のどちらかになります。どちらになるかは、あなたのアカウントの「利用クレジット（usage credits）」設定次第です。

本記事は発表の解説に留まらず、**「6/15までに何を確認し、6/15以降どう運用するか」**の実務ガイドとして書いています。Agent SDKそのものの実装方法はClaude Agent SDK実装ガイド、Claude Code全体の料金体系はClaude Code料金プラン完全ガイドを参照してください。

2026年6月15日に何が変わるのか

変わるのは「プログラムからのClaude利用」の課金枠だけです。 2026年5月14日にAnthropicが発表し（ITmediaの報道）、6月15日に施行されるこの変更で、これまでProやMaxプランの使用量上限を消費していたプログラム経由の利用が、専用の月次クレジットから消費される方式に分離されます。

クレジットの対象となるのは、次の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公式ヘルプ）

クレジットの5つのルール

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

なぜ対話枠と分離されたのか

公式の説明を整理すると、設計意図は「対話的な利用枠を、バックグラウンド自動化に食い潰されないよう保護する」ことにあります。Agent SDKやclaude -pによる自動実行は、cronやCIで24時間動かせるため、対話利用とは消費量の桁が変わります。同じ枠を共有していると、自動化を回した日の午後にClaude Codeの対話セッションが使用量上限に達する、という事態が起きます。2つの枠は完全に分離され、相互に融通されません。自動化がクレジットを使い切っても対話的なClaude Codeは止まりませんし、逆も同様です。

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

判定基準はただ1つ、「人間がその場で対話しているか、プログラムが自動で呼んでいるか」です。 APIキー（従量課金）での利用はもともとサブスクと別会計のため、今回の変更と無関係です。

影響を受けるのは、具体的には次の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自体はトークンを消費しない）は、何も変わりません。

【手順】自分の自動化コストを6/15前に実測する

最初にやるべきは、対策の検討ではなく「自分の自動化が月いくら分のトークンを消費しているか」の実測です。 クレジット額はUSD建てのため、消費量をドル換算で把握できて初めて「$20枠に収まるのか」を判断できます。6/15より前なら、現行の運用をそのまま続けながら計測できます。

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

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

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

Claude Consoleの使用量（Usage）画面やClaudeアカウントの使用量設定では、利用履歴を確認できます。6/15以降のクレジット残量・消費履歴の表示場所は施行後に確定するため（本記事で確認次第追記します）、施行前に現状の使用量画面の場所を把握しておくと移行後の監視がスムーズです。

手順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つの選択肢

月間消費の実測値とクレジット枠の差分が出たら、取れる選択肢は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）」のような組み合わせが現実解になります。

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

今回の変更を受けて、OpenAIのCodex CLIなど他のコーディングエージェントへの移行を検討する声もあります。結論としては、「料金変更が理由の乗り換え」は多くの場合、割に合いません。第一に、各社のサブスクリプションも自動実行・ヘッドレス利用には何らかの制限や別枠を設ける傾向にあり、「定額で無制限にバックグラウンド実行できる」サービスは構造的に持続しません。今回のAnthropicの変更は、他社も遅かれ早かれ通る道と見るのが自然です。第二に、移行には CLAUDE.md・スキル・hooks・MCP設定などの資産の作り直しコストがかかります。月数十ドルの差額のために移行工数を払うより、後述の最適化（モデル格下げ・キャッシュ設計）で消費自体を下げるほうが、ほとんどのケースで合理的です。乗り換えを検討するのは、料金ではなく機能・品質に不満がある場合に限るべきです。

【手順】opt-inと「利用クレジット」のON/OFF確認

6/15までにやるべき設定確認は2つです。 どちらもClaudeアカウントの設定画面から行います。

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

クレジットは自動付与ではなく、初回は自分で受け取り操作（opt-in）が必要です。opt-inしないまま6/15を迎えると、claude -pやGitHub Actionsのジョブが動かなくなる可能性があります。Anthropicからの案内メールまたはアカウント設定からクレームしてください。一度opt-inすれば、以降の月次リフレッシュは自動です。

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の認証に使っているアカウントに消費が集中し、そのユーザーのクレジットだけが先に枯渇する構造です。メンバー間の消費バラつきを均す手段は現状ないため、CI用途は特定ユーザーのサブスク認証に相乗りさせるのではなく、APIキー（チームの予算で管理）への移行が設計として素直です。

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

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

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

Teamプランはシート種別でクレジット額が異なります（Standard $20／Premium $100）。誰がどのシートかを把握し、自動化を動かすアカウントがStandardシートなら、その枠は個人のPro相当（$20）しかない点に注意してください。

クレジットを長持ちさせる5つの最適化

同じ自動化でも、設計次第でクレジット消費は数分の1になります。 6/15を機に見直す価値のある順に挙げます。

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) 週1回Consoleの使用量画面を確認する習慣を作る、(2) 月の消費ペースが「経過日数の割合+20%」を超えたら自動化の頻度を一時的に落とす、という簡単なルールで十分機能します。逆に監視ゼロの運用では、月末のクレジット枯渇でCIが落ちて初めて気づくことになり、原因調査に余計な時間を使います。止まってから調べるのではなく、止まる前に気づく設計にしておきましょう。

6/15以降の実際の挙動（施行後に随時更新）

このセクションは6月15日の施行後、実環境で確認した挙動・画面文言・エラーメッセージを随時追記します。 現時点（6/13）で公式情報から確定しているのは次のとおりです。

• opt-in済みの場合: claude -p・Agent SDK・GitHub Actionsの消費が自動的にクレジットから引かれる（コード変更は不要）
• opt-in未了の場合: プログラム経由の利用が制限される可能性がある（具体的なエラー文言は施行後に確認）
• クレジット枯渇＋利用クレジットOFF: リクエストが停止する（CLIにどんなエラーが出るかは施行後に確認・追記予定）

claude -pが突然動かなくなった場合は、まず「クレジット未opt-in」「クレジット枯渇」の2つを疑ってください。残量はアカウント設定内の使用量画面で確認できます（正確な表示場所は施行後に追記します）。その他のエラーで止まった場合はClaude Codeエラー対処法50種の逆引きインデックスを参照してください。

よくある質問

まとめ — 6/15までのチェックリスト

今回の変更は「値上げ」ではなく、対話枠の保護と引き換えに、自動化に明確な天井が付いたという構造変化です。やるべきことを整理します。

• 自分の利用形態が対象か判定する（claude -p／Agent SDK／GitHub Actions／サードパーティアプリ）
• /cost・Console・ローカルログ集計で月間消費をドル換算で実測する
• タスク種別ごとに4つの選択肢（クレジット内／従量許容／APIキー／縮退）を割り当てる
• Agent SDKクレジットを**opt-in（クレーム）**する
• 「設定 → 使用量 → 利用クレジット」のON/OFFを方針どおりに設定する（個人はOFF推奨、ONなら支出上限も確認）
• マージ条件に入っているGitHub Actionsワークフローの認証方式を見直す

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

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