6月のある朝、いつものようにスケジュール実行のログを確認していたとき、ふと手が止まりました。6月15日から、Claude Agent SDK・headless の claude -p・Claude Code GitHub Actions・サードパーティ製エージェントが、サブスクリプションの利用上限から切り離され、API レート準拠の月次クレジット制へ移行する。告知自体は以前から出ていたものの、残り3日という段になって、自分のパイプラインのどの工程がこの変更の影響を受けるのか、正確に答えられない自分に気づいたのです。
私は個人開発で複数の技術サイトを運営しており、記事の生成からビルド前の品質検証まで、かなりの工程を Claude の自動実行に委ねております。今回の変更は、その実行コストの構造が根本から変わる話です。
この3日間で行った棚卸しと再設計の過程を、判断基準と実測値を添えて残しておきます。同じように自動化を運用されている方の参考になれば幸いです。
何が変わるのか。対象範囲の整理
まず変更内容の確認から。2026年6月15日以降、次の実行形態がサブスクリプション上限の対象外となり、月次クレジット制に移行します。
- Claude Agent SDK を使ったプログラム実行
- headless モードの
claude -p（スクリプトや cron からの非対話実行）
- Claude Code GitHub Actions
- サードパーティ製エージェントからの利用
付与されるクレジットはプランごとに月額 $20（Pro）、$100（Max 5x）、$200（Max 20x）。重要なのは繰越がないことです。月内に使い切らなかった分は消滅し、超過したければ API 課金を追加する形になります。
一方で、対話的な Claude Code のセッションや claude.ai の利用は従来どおりサブスクリプションの範囲内です。つまり「人が前に座って使う分」は変わらず、「無人で回す分」だけが従量の世界に移る。この線引きが、今回の再設計の軸になりました。
工程の棚卸し。実行経路で分類し直す
私のパイプラインは、おおまかに次の工程で構成されております。
- 記事ドラフト生成: 参照データを読み込み、日英2本の MDX を生成する重い工程
- 品質ゲート: 生成物をスクリプトで機械検証する軽い工程（Python 製で LLM 呼び出しなし）
- 加筆・リライト: 既存記事の品質改善。中量級
- 整合性チェック: 日英件数・リダイレクト・フロントマターの検証。これも LLM 不要
- 監視レポート: 検索パフォーマンスデータの要約。軽量だが毎週走る
棚卸しをして最初に気づいたのは、「LLM を一切呼ばない工程」が思った以上に多いことでした。品質ゲートと整合性チェックは純粋な Python スクリプトで、課金変更の影響をまったく受けません。影響を受けるのは 1・3・5 の生成系工程だけ。漠然と「パイプライン全体が従量になる」と身構えていたのが、実際に対象を列挙すると半分以下だった。この感覚と実態のずれを数字で埋めるのが、次のステップです。
消費ペースを実測から見積もる
直近30日の実行ログから、工程別の平均トークン消費を集計しました。手元の集計スクリプトを簡略化したものを載せておきます。JSONL 形式の実行ログ（1行に1回の API 呼び出し結果が入っている想定）から月次のクレジット消費を試算するものです。
import json
from collections import defaultdict
from pathlib import Path
# 工程名 -> (入力単価, 出力単価) USD per 1M tokens
# 2026-06 時点の参考値。実際の単価は利用モデルに合わせて更新してください
PRICING = {
"draft_generation": (5.0, 25.0), # Opus 4.8 standard
"rewrite": (5.0, 25.0),
"weekly_report": (1.0, 5.0), # Haiku 4.5 相当の軽量モデル
}
def estimate_monthly_credits(log_dir: str, days: int = 30) -> None:
usage = defaultdict(lambda: {"in": 0, "out": 0, "runs": 0})
for log_file in Path(log_dir).glob("*.jsonl"):
for line in log_file.read_text().splitlines():
rec = json.loads(line)
stage = rec.get("stage", "unknown")
usage[stage]["in"] += rec["usage"]["input_tokens"]
usage[stage]["out"] += rec["usage"]["output_tokens"]
usage[stage]["runs"] += 1
total = 0.0
for stage, u in sorted(usage.items()):
if stage not in PRICING:
continue
price_in, price_out = PRICING[stage]
cost = (u["in"] / 1e6) * price_in + (u["out"] / 1e6) * price_out
monthly = cost * (30 / days)
total += monthly
print(f"{stage:20s} runs={u['runs']:4d} "
f"in={u['in']/1e6:.2f}M out={u['out']/1e6:.2f}M "
f"→ ${monthly:.2f}/月")
print(f"{'合計':20s} → ${total:.2f}/月")
estimate_monthly_credits("./logs")
このスクリプトを書いた理由は単純で、クレジット制の影響を「不安」ではなく「金額」で把握したかったからです。
私の環境での結果を共有します。記事ドラフト生成は1本あたり平均で入力 41,000・出力 12,000 トークン前後。日英セットで1日に複数本を回すと、生成系だけで月 $60〜75 相当という試算になりました。Max 5x の $100 クレジットには収まるものの、リトライや実験を含めると安全余裕は2割程度。「収まるが、無頓着には使えない」という位置です。
3つの実行経路への振り分け基準
試算を踏まえて、各工程を次の3経路に振り分け直しました。
- 月次クレジット枠（headless / Agent SDK）に残すもの: 定時実行が必須で、人の介在なしに完結すべき工程。記事ドラフト生成と週次レポートをここに残しました。クレジットはこの2つのために温存します
- 対話セッションに寄せるもの: 既存記事の加筆・リライトです。もともと生成結果を目視確認してから push する運用だったので、無人実行である必然性が薄い。対話的なセッションはサブスク範囲内のままなので、ここへ移すだけで月 $20 相当の消費が枠の外に出ました
- API 直接呼び出しへ切り替えるもの: 月次クレジットを超過しそうな実験的バッチ処理。クレジット枠を本番系で使い切る前提に立つと、実験系は最初から API 課金で隔離しておくほうが事故がありません。プロンプトキャッシングとバッチ処理の併用で、実験系の単価はかなり抑えられます
判断基準を一行でまとめるなら、「無人であるべきか」「失敗時に再実行が走るか」「月内のどのタイミングで動くか」の3点です。とくに2点目は見落としがちで、リトライ設計のある工程はクレジットを二重三重に消費し得ます。
繰越なしクレジットの運用ルール
繰越なしという性質は、月のペース配分を強制してきます。私は次のルールを設けました。
- 80% ルール: 月の20日時点でクレジット消費が80%を超えていたら、残りの期間は生成系タスクの実行頻度を自動で半減させる
- 月初の前倒し禁止: 「余っているから」と月初に実験を詰め込まない。月末の本番実行分を先に確保する
- 消費ログの日次記録: 上記スクリプトを日次で回し、累積消費を JSON に追記する
頻度半減の判定は、スケジューラ側に薄いフックを入れるだけで実現できます。
#!/bin/bash
# 月次クレジット消費が閾値を超えていたら生成タスクをスキップする前段フック
USAGE_FILE="$HOME/.claude-credit-usage.json"
LIMIT_USD=100 # Max 5x の月次クレジット
THRESHOLD=80 # パーセント
DAY_OF_MONTH=$(date +%d)
USED=$(python3 -c "
import json,sys
try:
print(json.load(open('$USAGE_FILE'))['month_total_usd'])
except Exception:
print(0)
")
PCT=$(python3 -c "print(int(float('$USED') / $LIMIT_USD * 100))")
if [ "$DAY_OF_MONTH" -ge 20 ] && [ "$PCT" -ge "$THRESHOLD" ]; then
# 偶数日のみ実行に間引く
if [ $((10#$DAY_OF_MONTH % 2)) -eq 1 ]; then
echo "credit pace guard: ${PCT}% consumed, skipping today" >&2
exit 0
fi
fi
exec "$@" # 通常実行
スキップの仕方を「奇数日を飛ばす」という単純な間引きにしたのは意図的です。複雑な優先度制御を入れるほど、フック自体の保守が負債になります。守りたいのは「月末に本番タスクが止まらないこと」だけなので、その目的に対して最小の機構に留めました。
公式の告知だけでは読み取れなかった点
実際に移行準備を進める中で気づいた、告知文面からは読み取りにくい運用上の論点をいくつか挙げます。
第一に、リトライとクレジットの相性です。529 過負荷エラーなどで自動リトライが走ると、失敗した呼び出しの分も消費は積み上がります。サブスク時代は「リトライは多めに」で問題ありませんでしたが、クレジット制では最大試行回数を絞り、バックオフを長めに取るほうが合理的になります。私は生成系の最大リトライを3回から2回に下げました。フォールバック設計の考え方は多モデルフォールバックによる高可用性設計で書いた内容がそのまま応用できます。
第二に、軽量工程のモデル降格です。週次レポートの要約に重いモデルを使っていたのは、単に「設定を変えていなかったから」でした。個人開発者の一人運用では、こうした設定は一度決めると見直す機会がありません。軽量モデルに切り替えても出力品質の差は私の用途では検知できず、該当工程の試算コストは約5分の1になりました。クレジット制への移行は、こうした惰性の設定を見直す強制力として機能してくれた面があります。
第三に、6月22日まで併走している Fable 5 の導入期間との段取りです。新モデルの検証はまさに「実験系」の消費なので、私は API 課金側に隔離した上で試しております。無料同梱期間だからといって headless の本番枠で検証を回すと、15日以降のクレジットを検証で削ることになりかねません。
次にやること
もしこれから同じ棚卸しをされるなら、最初の一歩は「LLM を呼んでいる工程と呼んでいない工程を紙に書き出すこと」をお勧めします。対象範囲が明確になるだけで、漠然とした不安のかなりの部分は消えます。その上で30日分のログがあれば、この記事のスクリプトで月額換算まで30分ほどで到達できるはずです。
私自身、この再設計が正解だったかどうかは7月の消費実績を見て判断するつもりです。結果が出たら、数字を添えてまた書きます。