6月15日に発効した課金変更の翌朝、ダッシュボードを開いて最初に思ったのは「思っていたより読めない」でした。Agent SDK・headless の claude -p・GitHub Actions・他社製エージェントが、これまでのサブスク上限から外れて別枠の月次クレジット（full API レート・繰越なし）で課金される——告知の文面は何度も読んでいたのに、実際の数字が並ぶと印象が変わります。
私は個人開発でアプリを作りながら、Dolice Labs として複数のサイトを自動投稿で運用しています。記事の生成・品質ゲート・push までを工程に分けて回しているのですが、これまでは「全部サブスク枠の中」という前提でざっくり組んでいました。発効から2日目、初日の実測値がようやく出そろったので、線引きを引き直した記録をそのまま残しておきます。同じように「とりあえず headless で回している」方の判断材料になればと思います。
なぜ初日ではなく2日目に測ったのか
結論から言うと、初日の数字は信用しないことにしました。発効当日はクレジット計上のタイミングがまだ安定せず、私の環境でも午前と午後で単価の出方が揃いませんでした。課金体系が切り替わった直後は、こうした過渡的なブレが必ず混じります。
代わりに、丸一日（0時〜24時 JST）の実行が一巡した2日目の朝を、最初の信頼できる基準点にしました。スケジュール実行は曜日や時間帯で内容が変わるので、本当は1週間ぶん見たいところですが、それを待っていると線引きの見直しが後手に回ります。「2日目の一巡」を暫定の物差しにして、週末にもう一度補正する——その二段構えにしました。
工程を「クレジット消費」と「サブスク内」で色分けした
最初にやったのは、パイプラインの工程を1枚の表に並べて、どれが新しい月次クレジットを食うのかを色分けすることです。頭の中では分かっているつもりでも、書き出すと想像と違いました。特に「記事を1本生成するだけ」と思っていた工程が、実際にはサブエージェントを複数呼んでいて、その分が丸ごとクレジット側に乗っていたのは見落としでした。
色分けの基準はシンプルにしました。
- headless・非対話で動く工程（スケジュール実行の本体、
claude -p経由の生成、GitHub Actions 上の検証）→ クレジット消費 - 自分が手元の対話セッションで動かす工程（記事の手直し、設計の相談、原稿のレビュー）→ サブスク枠
この2列に分けるだけで、「どこを減らせば効くか」がはっきりします。私の場合、クレジットを最も消費していたのは品質ゲートの前段で走らせていた下調べ用のサブエージェント群でした。生成本体より、その周辺の自動リサーチの方が重かったのです。
測り方は「ログに使用量を吐かせる」だけ
実コストを測ると言っても、特別な計装は要りませんでした。headless 実行のラッパースクリプトに、終了時の使用量を1行追記するだけです。私が足したのはこれだけの処理です。
#!/usr/bin/env bash
# 自動投稿ラッパー: 1工程ぶんの使用量をログに残す
# 使い方: ./run_step.sh <工程名> -- claude -p "..."
STEP_NAME="$1"; shift
[ "$1" = "--" ] && shift
LOG="$HOME/cost_log/$(date +%Y-%m-%d).tsv"
mkdir -p "$(dirname "$LOG")"
START=$(date +%s)
# 実コマンドを実行（標準出力はそのまま下流へ流す）
"$@"
STATUS=$?
END=$(date +%s)
# 工程名・所要秒・終了コード・時刻をタブ区切りで1行追記
printf '%s\t%s\t%ds\t%d\t%s\n' \
"$STEP_NAME" "$(TZ=Asia/Tokyo date +%H:%M)" "$((END-START))" "$STATUS" \
>> "$LOG"
exit $STATUSこれで1日ぶんが cost_log/2026-06-16.tsv に溜まります。工程名・実行時刻・所要秒・成否が1行ずつ並ぶので、あとは工程名で集計すれば「どの工程が何回・どれだけ時間を食ったか」が見えます。クレジットの実額はダッシュボード側で確認しつつ、こちらのログで「どの工程に偏っているか」を突き合わせる、という使い分けです。所要秒はコストそのものではありませんが、重い工程ほど秒数も伸びるので、当たりをつける一次指標としては十分でした。
集計はワンライナーで足ります。
# 工程ごとの実行回数と合計秒数を降順で
awk -F'\t' '{c[$1]++; s[$1]+=$3+0} END{for(k in c) printf "%-28s %3d回 %5ds\n", k, c[k], s[k]}' \
"$HOME/cost_log/2026-06-16.tsv" | sort -k3 -rn線引きをどう引き直したか
実測を見て決めたのは、3つだけでした。
ひとつ目は、下調べ用のサブエージェントを「常時起動」から「必要時だけ」に変えたことです。これまでは生成前に毎回リサーチを走らせていましたが、すでに参照データが手元にある日はその工程を丸ごと飛ばしました。クレジット消費の山がここで一番下がりました。
ふたつ目は、対話で十分な工程をサブスク枠に戻したことです。記事の最終レビューは、私自身が手元のセッションで読みながら直す方が結局速く、品質も上がります。headless に押し込んでいたのは「自動化した方がえらい」という思い込みで、コストと品質の両面で割に合っていませんでした。自動化は目的ではなく道具だと、数字を見て改めて思いました。
みっつ目は、GitHub Actions 上の検証を「push 時の全部入り」から「変更があった部分だけ」に絞ったことです。これは課金変更そのものより、クレジットが有限だと意識した副産物でした。制約があると、無駄に気づきやすくなります。
このあたりのコスト設計の考え方は、以前まとめたAnthropic API のコスト最適化の実践メモや、月次トークンコストの見積もりの立て方とも地続きです。今回の課金変更で、その前提を一度棚卸しした格好になります。GitHub Actions まわりはCI/CD に AI 検証を組み込む手順で触れた構成を、そのまま絞り込みました。
明日からどう続けるか
まず手を動かすなら、自分のパイプラインの工程を「headless で動くか／対話で動かすか」の2列に書き出してみてください。それだけで、新しいクレジットを食っている工程が浮かび上がります。私自身はこの週末にもう一度1週間ぶんで測り直して、暫定の線引きを本決めにするつもりです。
課金体系が変わるたびに身構えてしまいますが、今回は「自分のパイプラインのどこが重かったか」を初めて数字で見られた良い機会になりました。制約は、見直しのきっかけをくれます。同じ移行期を過ごしている方と、手応えを交換できたら嬉しいです。