結論から言うと、claude -p（ヘッドレスモード）だから課金方式が変わる、ということはありません。サブスク枠かAPI従量課金かを決めるのは -p の有無ではなく認証方法 です。ただしここには重要な経緯があります。実は2026年6月に「claude -p をサブスク枠から切り離す」変更が発表され、その後保留されています（第3章で詳述）。この記事では、認証方式と課金の関係とその経緯を整理したうえで、筆者が実際にcronで無人運用して踏んだ「API課金が優先される罠」「SIGTERMで成果物が欠ける事故」への対策設計まで解説します。

claude -p "プロンプト" は、対話UIを開かずにプロンプトを1回実行して結果を標準出力に返す、Claude Codeの非対話（ヘッドレス）モードです。中身は普段使っているCLIとまったく同じで、スキルやツールもそのまま動きます。

「-p を使うとAPI課金になるのでは？」という疑問をよく見かけますが、これは誤解です。ヘッドレスかどうかと課金方式は独立していて、どの認証情報でCLIが動いているかだけが課金を決めます。

（上表は2026年7月時点の内容です。この前提には一度変更が発表されて保留された経緯があるため、次章で触れます。）

サブスクにログインしていれば、claude -p もサブスク枠で動きます。API従量課金は発生しませんが、その代わり5時間／7日単位のレート上限を消費します。逆にAPIキー認証なら上限の心配は減りますが、ループやcronで回した分だけ確実に請求されます。

ここが本記事でいちばん注意してほしいところです。実はAnthropicは2026年6月、Claude Agent SDK・claude -p・サードパーティアプリ経由の利用をサブスクリプションの利用枠から切り離し、別枠の月額クレジット（標準APIレートで消費）に移行すると発表していました。プラン別のクレジット額まで示された、具体的な変更計画です。つまり「claude -p はサブスク枠で動く」という前提そのものが、一度は覆される予定だったわけです。

ただしこの変更は、予定日だった2026年6月15日付けで保留（paused）されました。 公式のヘルプセンターには次のように明記されています。

We're pausing the changes to Claude Agent SDK usage described below. For now, nothing has changed: Claude Agent SDK, claude -p, and third-party app usage still draw from your subscription's usage limits.

（訳: 下記のClaude Agent SDKの利用に関する変更は保留します。現時点で変更はありません。Claude Agent SDK、claude -p、サードパーティアプリの利用は引き続きサブスクリプションの利用枠から消費されます。）

「サブスク枠から外れるらしい」という話を見かけたことがある方は、記憶違いではありません。発表は実在し、そして保留された——という経緯を押さえておくと、今後アナウンスがあったときに落ち着いて対応できます。なお、自動化用途をサブスクで回すこと自体が禁止されたという事実は確認できませんでした。論点はあくまで「どの枠から消費されるか」です。

ここで紛らわしいのが Claude Agent SDK の扱いです。前述のヘルプセンターは「Agent SDK もサブスク枠から消費される」としている一方で、Agent SDK の公式ドキュメントはセットアップ手順としてAPIキーの取得を案内し、次の注記を置いています。

Unless previously approved, Anthropic does not allow third party developers to offer claude.ai login or rate limits for their products, including agents built on the Claude Agent SDK.

一見矛盾していますが、Legal and compliance のページを読むと整理できます。両者は用途で使い分ける前提で書かれています。

そのうえで、次の行為は明確に禁止されています。

Anthropic does not permit third-party developers to offer Claude.ai login or to route requests through Free, Pro, or Max plan credentials on behalf of their users.

（訳: Anthropicは、サードパーティ開発者による claude.ai ログインの提供や、ユーザーに代わってFree/Pro/Maxプランの認証情報経由でリクエストを送ることを許可していません。）

つまりヘルプセンターの記述は「サブスク枠から消費される場合の課金の仕組み」の話、Agent SDKドキュメントの記述は「どの認証方式を使うべきか」の話で、レイヤーが違います。自分のサブスクで自分のためにAgent SDKを動かすのと、自社プロダクトのユーザーに claude.ai ログインさせるのは別問題、と理解すると筋が通ります。

筆者が実際に踏んだ罠がこれです。環境変数 ANTHROPIC_API_KEY がセットされていると、サブスクにログインしていてもAPIキー側が優先されて従量課金になることがあります。

サブスクで回しているつもりが、過去の実験で .bashrc や .env に書いたキーが残っていて、気づいたらAPIの請求が立っていた——という事故が起こり得ます。ヘッドレス運用を始める前に、必ず確認しましょう。

# 何も表示されなければOK。キーが表示されたら要注意
echo $ANTHROPIC_API_KEY

# cron用スクリプトの冒頭で明示的に外しておくのも有効
unset ANTHROPIC_API_KEY

特にcronは対話シェルと環境変数の読み込み元が違うため、「ターミナルでは未設定なのにcronでは設定されている」（またはその逆）が普通に起こります。cronから env | grep ANTHROPIC をログに吐かせて、実行環境そのものを一度確認しておくと安心です。

なお、サブスク枠で回す場合はループ・cronの連続実行で枠を食い尽くしやすいので、消費ペースの監視も有効です。筆者は自作の監視ツールで実行回数と枠の残りを見える化しています。

cronで claude -p "/スキル名" を毎朝実行してレポート類を自動生成する構成を運用していたところ、ある日プロセスがSIGTERM（終了コード143）で途中終了し、生成されるはずのファイルのうち一部だけが欠落する事故が起きました。

厄介なのは「全部失敗」ではなく「一部だけ成功」という中途半端な状態になる点です。終了コードだけ見て成否判定していると、そもそもLLMのステップは「正常終了したのに期待した出力がない」ことも「異常終了したのに途中まで出力がある」こともあり、判定を誤ります。

この事故から得た設計原則は、LLMステップの成功は終了コードではなく、期待する成果物ファイルが実在するかで判定することです。具体的には次の3段構えにします。

1. 実行後に、期待する成果物ファイルの存在を確認する
2. 欠けていれば 1回だけ 自動再実行する（処理は冪等に設計しておく）
3. それでも欠けたらSlack通知等で人に知らせる

flowchart TD
    cronJob["cronが claude -p を実行"] --> verify1{"成果物ファイルは<br/>すべて存在する？"}
    verify1 -- "はい" --> finish["正常終了"]
    verify1 -- "いいえ" --> retryOnce["1回だけ自動再実行<br/>（冪等な処理）"]
    retryOnce --> verify2{"成果物は揃った？"}
    verify2 -- "はい" --> finish
    verify2 -- "いいえ" --> alertSlack["Slack通知で人に知らせる"]

ラッパースクリプトにするとこうなります。

#!/bin/bash
# daily_report.sh — cronから呼ぶラッパー
OUT="$HOME/reports/daily_$(date +%Y%m%d).md"

run_task() {
  claude -p "/daily-report" >> "$HOME/logs/daily_report.log" 2>&1
}

# 既に成果物があればスキップ（再実行しても安全＝冪等）
if [ ! -s "$OUT" ]; then
  run_task
fi

# 成果物の実在で成否判定。欠けていれば1回だけ再実行
if [ ! -s "$OUT" ]; then
  run_task
fi

# それでも欠けたら人に通知
if [ ! -s "$OUT" ]; then
  curl -s -X POST "https://slack.com/api/chat.postMessage" \
    -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
    -H "Content-Type: application/json" \
    -d "{\"channel\":\"$SLACK_CHANNEL_ID\",\"text\":\"daily-report の成果物が欠落しています\"}"
  exit 1
fi

ポイントは、再実行を無限リトライにしないこと（サブスク枠やAPI課金を食い潰します）と、「既に成果物があれば作り直さない」冪等設計にしておくことです。

もうひとつ見落としがちなのが、常時起動サーバーではなくPCで運用する場合の挙動です。cronは電源OFFで時刻を過ぎた回をキャッチアップ実行しません。 朝7時のジョブは、7時にPCが寝ていればその日はただ実行されないだけです。

後追い実行したいなら anacron などの仕組みが必要です。ただ筆者のおすすめは、前節の「既に成果物が存在すればスキップ」設計を活かして、cronの実行間隔を細かめにしておき、生成漏れを後から自然に補える運用にすることです。たとえば毎朝の生成ジョブを7時・9時・12時の3回仕掛けておけば、7時に寝ていても9時に起きていれば生成され、既に生成済みの回は冪等チェックで即スキップされます。

このあたりのマルチエージェント構成やCLI環境の作り込みは、Claude CodeからCodexを呼び出す構成の記事や、Windows WSLでClaude Codeを動かすセットアップ記事でも扱っているので、環境づくりから始める方は合わせてどうぞ。

なりません。-p はヘッドレス（非対話）モードのスイッチであって、課金方式のスイッチではありません。サブスク認証で動いていれば -p もサブスク枠で動きます。課金を決めるのは認証方法だけです。

記憶違いではありません。2026年6月、Agent SDK・claude -p・サードパーティアプリの利用をサブスク枠から切り離し、別枠の月額クレジット（APIレート消費）に移行する変更が発表されました。ただしこの変更は予定日の2026年6月15日付けで保留され、現在もサブスク枠から消費されます（第3章）。保留であって撤回ではないので、重要な運用なら定期的に公式情報を確認してください。

公式情報が一見食い違って見える部分ですが、用途で分けて考えるのが正解です。公式のLegal and complianceは、OAuth（サブスク認証）を「購入者本人による通常利用」向け、APIキー認証を「製品・サービスを構築する開発者（Agent SDK利用者を含む）」向けと位置づけています。サードパーティ開発者が claude.ai ログインを提供したり、ユーザーに代わってPro/Maxの認証情報でリクエストを送るのは明確に禁止。詳しくは第3章の補足をご覧ください。

環境変数 ANTHROPIC_API_KEY がセットされていると、サブスクにログインしていてもAPI課金が優先されることがあります。サブスク枠で回したいなら echo $ANTHROPIC_API_KEY でキーが残っていないか確認し、残っていれば unset してください。

実行頻度とタスクの重さ次第ですが、5時間／7日のレート上限を消費するため、ループや高頻度cronは枠を食い尽くしやすいのは事実です。消費ペースを監視しつつ、頻度を落とす・軽いタスクに絞る・上限を気にしたくない用途はAPIキー認証に切り替える、といった調整をおすすめします。

LLMステップに関してはおすすめしません。筆者の環境ではSIGTERM（rc=143）による途中終了で成果物が一部だけ欠ける事故がありましたし、逆に終了コード0でも期待した出力が揃っていないケースはあり得ます。成功判定は「期待する成果物ファイルが実在するか」で行うのが確実です。

• claude -p は同じCLIのヘッドレスモード。課金方式を決めるのは -p ではなく認証方法
• サブスク（Pro/Max）認証なら -p もサブスク枠で動き、API従量課金は発生しない
• ただし2026年6月に「claude -p・Agent SDKをサブスク枠から切り離す」変更が発表され、6月15日付けで保留された経緯がある。撤回ではなく保留なので、運用に組み込むなら公式情報の定期確認を
• 環境変数 ANTHROPIC_API_KEY が残っているとサブスクよりAPI課金が優先されることがある。無人運用前に echo $ANTHROPIC_API_KEY で確認
• LLMステップの成功判定は終了コードでなく成果物の実在で行う。①実行後にファイル存在確認 → ②欠けていれば1回だけ再実行（冪等設計）→ ③それでも欠けたらSlack通知
• PCのcronは電源OFF中の回をキャッチアップしない。後追いには anacron 等が必要。「成果物があればスキップ」設計＋複数回スケジュールで生成漏れを自然に補うのが実用的