個人開発でスケジュール実行を組み、毎晩記事を生成する仕組みを回していると、2026年6月15日という日付がずっと頭の片隅にありました。この日から、Claude Agent SDK・headless の claude -p・Claude Code GitHub Actions・サードパーティ製エージェントが、これまでのサブスクリプション上限から外れ、API レート準拠の月次クレジットへ移行するからです。
最初にこの告知を読んだとき、正直なところ「自分のパイプラインの何が、いつ、どれだけ値段に変わるのか」がすぐには像を結びませんでした。同じように、対話で使う Claude Code は今までどおりなのか、バックグラウンドで走らせている処理だけが対象なのか、線引きが曖昧なまま不安だけが残っている方も多いのではないでしょうか。残り2日というこのタイミングで、自分の手元の構成を点検しながら整理した内容を共有します。
何が「月次クレジット」に変わるのか
変更の核心は、課金の単位が「サブスクリプションの利用上限」から「月ごとに配られるクレジット」に切り替わる点です。対象は次の4つです。
- Claude Agent SDK で書いた自作エージェント
claude -p（headless モード）でのワンショット実行- Claude Code GitHub Actions
- サードパーティ製のエージェント連携
逆に言えば、ターミナルや IDE で対話的に開く通常の Claude Code セッションは、この変更の直接の対象ではありません。私が最初に取り違えていたのはここでした。「Claude Code が全部値上がりする」と身構えていたのですが、実際に線が引かれたのは「人間が画面の前にいない、自動で走る実行」の側だけだったのです。
月次クレジットは、報じられている範囲では Pro が $20、Max 5x が $100、Max 20x が $200 に相当する枠で、繰り越しはありません。ここが運用設計に効いてきます。使い切れなかった分は翌月に持ち越せないので、「月初にまとめてバッチを回す」「月末に余ったら検証を回す」といった偏らせ方は、これまで以上にもったいない構造になります。
まず把握すべきは「無人で走る工程」がいくつあるか
課金体系の話を読む前に、私が手を動かしたのは構成の棚卸しでした。値段の前に、自分が一日に何回、人間不在で Claude を起動しているのかを数えていなかったからです。
判断軸はシンプルで、「その実行は、人が画面を見ながら指示しているか、それとも自動で起動しているか」の一点です。後者だけが今回の対象になります。crontab や CI の定義ファイルを開いて、claude -p を含む行、Agent SDK を呼ぶスクリプト、GitHub Actions のワークフローを洗い出してみてください。
# headless 実行を呼んでいる箇所を一覧する
grep -rn "claude -p" ~/scripts ~/.config 2>/dev/null
# crontab に登録された自動実行を確認する
crontab -l | grep -v '^#'
# GitHub Actions で Claude を起動しているワークフローを探す
grep -rln "anthropics/claude-code-action\|claude -p" .github/workflows/ 2>/dev/null私の場合、自分でも忘れていた検証用のスクリプトが2本ぶら下がっていました。動いていることに気づいていなかったのは、それが「失敗しても誰も困らない」処理だったからです。月次クレジットに移ると、こういう「動いているが価値を生んでいない無人実行」が、静かにクレジットを削っていく側に回ります。棚卸しの第一目的は、止めるべきものを見つけることでした。
工程ごとに「headless のままでよいか」を決める
棚卸しで実行の一覧ができたら、次は一つずつ「これは自動で走り続ける価値があるか」を判断していきます。私が使った基準は3段階です。
一つ目は、頻度と価値が見合っているか。毎日走らせているが成果物をほとんど使っていない処理は、週次に落とすか止めます。月次クレジットは繰り越せないので、頻度を下げた分はそのまま余裕になります。
二つ目は、失敗時に人の確認が要るか。確認が必須な工程は、そもそも完全無人に向いていません。headless で走らせて結果だけ後で見るより、対話セッション側に寄せたほうが、結果的にクレジットの無駄打ちが減ります。私のパイプラインでは、生成そのものは headless に残し、品質ゲートで弾かれた記事の作り直しは人が判断する側に移しました。
三つ目は、実行モデルが意図したものか。自動実行は人の目が届かないぶん、知らないうちに高価なモデルで延々と回り続けるリスクがあります。クレジット制ではこれが直接コストに跳ね返るので、自動実行で使うモデルは固定しておくのが安全です。具体的な固定方法はモデルの自動アップグレードでクレジットを使い切らないためにで詳しく書いていますが、要点は「無人実行こそモデルを明示する」ことに尽きます。
残量を「見えるところ」に置いておく
繰り越しがない月次クレジットで一番こわいのは、月の途中で枠を使い切って自動実行が止まることです。サブスク上限の時代は上限に近づいても体感しにくかったのですが、クレジット制では「あといくら残っているか」を常に意識できる状態にしておきたいところです。
私はステータスラインに残量と利用ペースを出すようにしました。設定の詳細はClaude Code ステータスライン — rate_limits 表示とカスタムスクリプトの実践設定にまとめてあります。数字が常に視界にあるだけで、「今週は検証を回しすぎているな」と早めに気づけるようになりました。
あわせて、どのモデルをどの工程に割り当てるかを一度きちんと決めておくと、クレジットの減りが予測しやすくなります。工程ごとのモデル選択はClaude Code のモデル選択戦略の考え方が参考になります。
6/15 までの2日で、最低限やっておきたいこと
残り時間が短いので、優先順位をつけて挙げます。まず、上の grep で無人実行を全部洗い出すこと。次に、価値を生んでいない自動実行を止めること。そして、残し続ける工程については実行モデルを固定し、残量が見える状態にしておくこと。この3つだけでも、移行当日に慌てずに済みます。
同じ日に Sonnet 4 と Opus 4 が API から引退する点も、頭の隅に置いておくとよいと思います。自動実行のスクリプトでこれらのモデル名を直書きしていると、6/15 を境に動かなくなります。grep で洗い出すときに、モデル名のハードコードも一緒に確認しておくと安心です。
私自身、まだ移行後の実コストを見届けたわけではありません。月次クレジットが自分の運用にどう効くかは、来月の数字を見てまた振り返るつもりです。同じように自動化を回している方の、当日の段取りの足しになれば嬉しいです。