2026/06/15以降に料金体系が変更されたClaudeをどう使うか考えてみた

こんにちは、せーのです。

2026年6月15日から、Anthropic が Claude Code の料金体系を改定します。「Claude Code がクレジット制になった」と聞いている方も多いと思いますが、半分正解です。

ターミナルで対話しながら使う Claude Code のインタラクティブ部分は、従来どおりサブスクリプション枠のままです。変わるのは Agent SDK や claude -p、GitHub Actions などの自動化部分だけ。ここが月次クレジットの「第2のおさいふ」に分離されます。

私は普段 Claude Max 5x と Codex（ChatGPT Plus） を両方使っています。設計は Claude、コード修正ループは Codex、という使い分けも 以前に書かれている記事 のとおりです。加えて GitHub Actions で Claude の自動レビューや @claude 応答も動かしているので、6/15 の変更は自分にとっても「どのおさいふが減るのか」を整理しておきたいタイミングでした。

本記事では、6/15 から Claude と Codex の料金体系がどう見えるか、そして 両方使うエンジニアがどう使い分ければ効率的か を整理します。Console・CLI・Codex の表示は 2026-06-14（改定前日）に実機で確認しています。

AIサービス課金モデルの3パターン(おさらい)

料金改定の話の前に、AI ツールの「制限の考え方」を3つに分けておきます。

ここで注意したいのは、Claude 公式ドキュメント上では Pro/Max のインタラクティブ利用枠を「rolling window」とは呼んでいないことです。公式には「5時間セッション制限は5時間ごとにリセット」「週次制限はアカウントに割り当てられた固定時刻にリセット」と説明されています。

一方、Codex の公式 pricing では Local Messages / 5h として five-hour window が明示されています。ユーザー検証記事や利用量監視ツールでは、この5時間枠を「ローリング」と説明しているものがあり、実際に「9時に使った分が14時に外れていく」ような説明がされています。加えて Additional weekly limits may apply とも書かれています。ただし、公式 pricing から読み取れるのは「5時間枠がある」「追加の週次上限がかかる場合がある」までで、週次上限が固定時刻リセットなのか、7日間のローリング集計なのかまでは明記されていません。

つまりここで言いたいのは、Claude と Codex はどちらも5時間枠と週次枠を気にする必要があるが、Claude は公式にリセット方式が説明されている一方、Codex の週次枠は公式 pricing だけではリセット方式を断定できない、ということです。

クレジット消費型は、月初に付与されたドル建ての枠を使うたびに減っていきます。未使用分は翌月に繰り越されません。毎日何十回も回す CI 向きではない、というイメージです。

違いを整理すると、Claude のインタラクティブ利用は「サブスクに含まれる時間制限つきのおさいふ」、Claude の自動化部分は「月次クレジットのおさいふ」、Codex は「5時間ウィンドウを基本に、追加の週次上限がかかる場合があるおさいふ」、というイメージです。

「おさいふ2つ」になった Claude Code（6/15〜）

6/15 の変更を一言で言うと、Claude Code の利用枠が2つのおさいふに分かれた ということです。

Agent SDK 月次クレジットの付与額は次のとおりです（公式ヘルプ）。

クレジットはユーザー単位で、チーム間共有はできません。枯渇後の挙動は overflow toggle で選べます（デフォルト OFF = 停止）。

Claude Code のおさいふ1はどうリセットされるのか

Claude Code インタラクティブで使うおさいふ1は、claude.ai や Claude Desktop と同じ利用枠を共有します。公式ドキュメントでは、次のように説明されています。

なので、この記事では Claude Code インタラクティブを ローリングウィンドウ とは呼ばず、5時間セッション + 週次固定リセットのサブスク枠 として扱います。

どのコマンドがどちらのおさいふか

CLI バージョン 2.1.170 で -p / --print / --output-format / ANTHROPIC_API_KEY が有効なことを確認しています。

# おさいふ1: インタラクティブ枠
claude "この diff をレビューして"

# おさいふ2: Agent SDK 月次クレジット（6/15以降）
claude -p "この diff をレビューして" < diff.patch

# おさいふ2を消費しない: APIキー直指定 → 従量課金
ANTHROPIC_API_KEY=sk-ant-xxx claude -p "この diff をレビューして"

API キーを環境変数で渡すと、サブスクの月次クレジットではなく API の従量課金 になります。高頻度 CI ではこちらが本命です。

混同しやすい2点

1. Agent SDK 月次クレジット ≠ 利用クレジット（overflow credits）

6/15 から付与される Agent SDK 月次クレジット は、プランに含まれる自動化向けの枠です。

一方、Console の「利用クレジット」は 自分で購入した上限付きの従量枠 です。6/14 時点の自分のアカウントでは、利用クレジット $13.11 使用 / 上限 $50 / 残高 $35.95 と表示されていました。名前に「クレジット」と付くだけで別物 なので、記事を読むときも Console を見るときも区別してください。

2. Routines（/schedule）はおさいふ1 — Remote も Local も同じ

/schedule や Desktop の [Code] → Remote で作る Remote Routine は Anthropic 管理のクラウドで動きますが、消費先は おさいふ1（サブスクリプション枠） です。Agent SDK 月次クレジットは 消費しません。公式にも Routines draw down subscription usage the same way interactive sessions do と書かれています。

一方、Desktop で Local を選ぶと Routine ではなく Desktop scheduled task になり、自分の PC 上で動きます。こちらもおさいふ1ですが、PC とアプリが起動している必要 があります。

6/14 時点の Console では Routines 0/15（Max プラン）と表示されていました。Remote Routine には 1日あたりの実行回数上限 もあります（Pro 5回、Max 15回、Team/Enterprise 25回）。Routine は接続した GitHub リポジトリをクローンして動くので、Vault 全体を Git 管理して push している なら、デイリーノートの Markdown も Remote から読み書きできます。逆に Git に載っていないローカル専用ファイル（iCloud 上だけに存在するもの等）は Remote では触れません。

「夜中に回したいからおさいふ2」ではなく、GitHub 上で完結する夜間バッチなら Remote Routine（おさいふ1）を先に検討する のが、この記事の結論です。

Codexの課金モデル(おさらい)

Codex 側は、OpenAI の公式 pricing でかなり具体的に書かれています。Plus / Pro 5x / Pro 20x / Business などの各プランに対して、モデル別に Local Messages / 5h が示されています。

公式 pricing で確認できるポイントは次のとおりです。

例えば公式 pricing では、Plus の GPT-5.5 は Local Messages / 5h が 15-80、Pro 5x の GPT-5.5 は 80-400、Pro 20x の GPT-5.5 は 300-1600 とされています。実際に何回使えるかは、モデル、コードベースの大きさ、タスクの複雑さ、ローカルかクラウドかによって変わります。

この5時間枠については、公式は five-hour window という表現に留めていますが、ユーザー検証記事や監視ツールでは ローリング5時間ウィンドウ として扱われています。一方、週次枠については GitHub issue などで window_minutes: 10080（7日）というログ例はありますが、表示の揺れや stale state の報告もあるため、この記事では断定しません。

公式 pricing では、Codex のメッセージ数は固定値ではなく、使うモデル、コーディングタスクのサイズと複雑さ、ローカルで実行するかクラウドで実行するか によって変わると説明されています。小さなスクリプトやルーチン関数なら少ない消費で済みますが、大きなコードベースや長時間走るタスク、広いコンテキストを必要とするセッションでは、1メッセージあたりの消費が大きくなります。

また、上限到達後に使う credits については、input tokens / cached input tokens / output tokens ごとのトークンベース料金として説明されています。なので、読者向けにざっくり言うなら「単純なメッセージ数だけではなく、モデルとタスクの重さで5時間枠の減り方が変わる」と捉えるのが正確そうです。

実機（6/14）の Codex ステータスバーでは GPT-5.5 の 5h 枠 3% 使用（残り約4h30m）、7d 枠 2% 使用（残り約4d18h）でした。まだ余裕がある状態です。

加えて Codex デスクトップアプリには 「使用量をリセット」 機能があり、30日以内に1回 使える、という通知が出ていました。急ぎのタスクで枠が足りないときの逃げ道として覚えておくとよいかもしれません。

ローカルタスクとクラウドタスクでも消費速度が異なります。同じ5時間枠でも、クラウド側の処理が多いほど早く枯渇します。

違いを整理すると、Claude Code インタラクティブは「5時間セッション + 週次固定リセット」、Codex は「5時間ウィンドウ + 追加の週次上限（リセット方式は公式 pricing だけでは未確認）」、Claude の自動化（おさいふ2）は「月次クレジット消費型」、というイメージです。

ClaudeとCodexの最適使い分け

ここからは、6/15 改定を踏まえた 自分の運用方針 を書きます。技術的な整理だけでなく、「いつ・どのおさいふを・何に使うか」の実務的な答えがここです。

基本方針 — 時間帯とおさいふで分ける

自分が意識している軸は3つです。

1. 日中（PC を開いている） → おさいふ1 をメインに使う。/loop、Desktop の Local schedule、Cowork の schedule など、ローカルに触れる手段 を積極的に回す
2. 夜中（PC を閉じることもある） → まず Remote Routine（おさいふ1） を検討。それでも足りない・イベント駆動・CI 連携が必要なものだけ おさいふ2 や API 従量 に回す
3. Claude だけに偏らない → Claude の5時間/週次枠と Codex の5時間/週次枠は別物。容量と精度 を見ながら交互に使い、おさいふ2 を早く使い切らない

「夜＝おさいふ2」と決め打ちしていた時期がありましたが、Remote Routine がおさいふ1 であることが分かってから、夜間バッチの優先順位を組み替えています。

日中（PCオン）
  ├── 対話作業: Claude（設計）↔ Codex（実装ループ）を枠で切替
  ├── セッション内: /loop, CronCreate
  ├── ローカル定期: Desktop Local schedule, Cowork schedule
  └── Cowork 2倍期間中は schedule を多めに（後述）

夜中（PCオフ可）
  ├── 第1候補: Remote Routine（おさいふ1）— GitHub 上で完結する定期タスク
  ├── 第2候補: Codex クラウドタスク — Claude 枠を温存したい実装ループ
  └── 第3候補: GitHub Actions / Agent SDK — イベント駆動・CI 専用

Cowork schedule を日中に多めに使う理由（〜7/5）

2026/6/5〜7/5 までは、Anthropic が Cowork の5時間利用枠を2倍 するキャンペーンを実施しています（公式告知）。Cowork 専用の5時間枠 が倍になるもので、Claude Code ターミナル側の5時間セッションや週次枠そのものが倍になるわけではありません。週次制限も変わらない、と説明されています。

Cowork はローカルファイルや Office アプリに触れるので、Google Drive / Calendar 連携の議事録・定例準備 など「PC 上のローカル連携が必要な定期作業」に向いています。Obsidian Vault 自体は Git 管理して GitHub に push しているので、デイリーノート作成は Remote Routine（おさいふ1）への移行候補 です。現状は OAuth 付き GitHub Actions で回しており、6/15 以降はおさいふ2 を消費します。7/5 までは Cowork schedule を意識的に増やし、7/6 以降は通常枠に戻る前提で量を調整する、という考え方です。

自分が回している夜間・朝イチループ（具体例）

Loop Engineering で語られる Daily Triage を、自分の環境ではもう一段具体化しています。別記事で書いた Loop Engineering 入門 では、リポジトリの CI / Issue / コミットを見回す L1 ループを /schedule で回す話でした。日常運用では、その 入力源をデイリーノート に置いています。

朝起きたら「今日やること」と「夜中に片付いていたもの」がそこそこ揃っている、という体験を目指しています。

フェーズ2の中身をもう少し分解すると、こんなイメージです。

• 議事録作成 — Google Calendar / Drive の Gemini 書き起こしを読み、Markdown 議事録を下書き（L2: 下書きまで自動、公開前は人間が確認）
• 定例準備 — 前回議事録と Backlog / コスト資料を読み、定例スライドのたたき台を更新
• Issue 対応 — GitHub Issue の調査・修正案・draft PR まで（L2/L3: リポジトリとブランチ戦略次第）

ポイントは 「デイリーノート作成」と「そこから派生する実行」を別 schedule に分ける ことです。デイリーノート作成は現状 GitHub Actions（OAuth） で回しており、6/15 以降は おさいふ2 を消費します。Vault が GitHub にあるので、同じ処理は Remote Routine（おさいふ1）に移行する候補 です。おさいふ2 を温存したい定期タスクから先に移す、という優先順位で検討しています。1本のプロンプトに全部詰め込むより、STATE.md や SKILL.md で手順をリポジトリに committed しておき、GHA / Cowork / Routine から同じ手順を呼び出す方が、Loop Engineering の設計論とも噛み合います。

Slack 要約は Remote Routine 向きです。Routine から使える connector は claude.ai アカウントに登録したものに限られ、CLI の claude mcp add だけでは Remote 側に載りません。夜中に回すなら claude.ai/customize/connectors で Slack を登録しておく必要があります。

Codex クラウドで「夜中に仕事させる」

2026年6月に Loop Engineering が話題になった背景には、「夜中に AI が仕事をして、朝起きたらある程度完成している」 という体験があります。Boris Cherny 氏の "I have loops running that prompt Claude" がまさにそれで、設計・実装・レビューを人間が毎ターン握るのではなく、ループに任せて朝確認する という働き方へのシフトです。

料金の話に戻すと、この「夜中ループ」は 必ずしもおさいふ2 である必要はありません。

Codex 公式 pricing では、Local Messages と cloud tasks は同じ five-hour window を共有 すると書かれています。つまり日中に Codex ターミナルで実装ループを回していても、夜のクラウドタスクと 同じ5時間枠・週次枠の中で競合 します。なので自分は、日中は Claude + Codex ローカルで対話し、Claude 枠が減ってきた夜は Codex クラウドに実装ループを逃がす という使い分けをしています。

22:00  Remote Routine   → Daily Triage / Slack 要約（Claude・おさいふ1）
23:00  Codex cloud task  → 蓄積した Issue / PR の修正ループ（Codex 枠）
06:30  GitHub Actions   → デイリーノート作成（OAuth・現状 → Routine 移行候補）
07:00  人間が起床        → デイリーノート・Slack 要約・draft PR を確認
07:30  Cowork schedule  → デイリーノートのタスク実行フェーズへ

朝の確認は L1/L2 の設計にしておくと安全です。完全自律（L3）で夜中にマージまで任せる のではなく、draft PR・下書き議事録・Slack 要約の「仕分け結果」を見て、承認や修正指示だけ人間が入る。Loop Engineering の段階的ロールアウトと、料金の「おさいふ2 を温存する」方針は、ここで同じ方向を向いています。

Claude だけに偏ると、Remote Routine + 日中対話で おさいふ1 の週次枠 が先に減り、さらに GitHub Actions を OAuth に載せると おさいふ2 も減ります。Codex を「夜の実装係」として足すと、2つのサブスク + おさいふ2 温存 というバランスが取りやすくなりました。

「いつ使うか」— 5時間枠と週次枠の設計

Claude と Codex は 別々の5時間枠 を持っています。Claude は5時間セッション制限、Codex は5時間ウィンドウです。公式上の呼び方は違いますが、使う側としては「片方が枯れたらもう一方に切り替える」という 交互活用 が効きます。

Claude 向き: アーキテクチャ、設計、Skill/Sub-agent の orchestration、Plan モードでのディスカッション。

Codex 向き: コード修正、テスト、実装ループ。クロスレビューで「Claude が書いたコードを Codex に直させる」運用も相性がよいです。夜間の実装ループは Codex クラウドタスク に逃がすと、Claude のおさいふ1 を温存しつつ「朝起きたら draft PR がある」体験を作れます（Codex 側の5時間/週次枠を消費）。

Claude 5h枠: [████████░░] 残り20%
    ↓ Codex に切り替え

Codex 5h枠: [████░░░░░░] 残り60%
    ↓ 作業中に Claude 側が回復

Claude 5h枠: [░░░░░░████] 回復
    ↓ 高度な判断を Claude で

「何に使うか」— 自動化の意思決定

6/15 以降、自動化手段を選ぶときは次の表が目安になります。

判断の順番はこうです。

自動化したい
  ↓
GitHub リポジトリ上だけで完結する定期実行？
  Yes → Remote Routine（おさいふ1）。Vault を Git 管理していればデイリーノートも。夜でも OK
  ↓ No
Git 外のローカルファイルが必要？
  Yes → 日中に Cowork schedule / Desktop Local / /loop
  ↓ No
イベント駆動（PR コメント等）？
  Yes → GitHub Actions（API キー優先）
  ↓ No
月数回の重要タスクで Routines に載せにくい？
  Yes → Agent SDK / claude -p（おさいふ2）

Agent SDK 月次クレジットを使う価値があるもの

• 週1〜2回のリリース前チェックなど、1回あたりのビジネス価値が高い自動化
• Routines に向かない複雑な API 連携
• 品質クリティカルで、手動代替が難しい非同期処理

使わない方がよいもの

• 毎日何十回も走る CI
• 試験的スクリプト
• Routines で足りる定期タスク

Agent Team（多エージェント）を使う場合は、各 teammate が独立したコンテキストを持つため トークン消費が約7倍 になり得ます。teammate には Sonnet、チームは小さく、作業後はすぐ clean up、がコスト面の定石です。

設定と実例：自分の GitHub Actions

使用量の確認

# Claude Code 内。インタラクティブ使用量のみ
/usage

/usage は ローカルセッション履歴ベース で、claude -p（ヘッドレス）の使用量は表示されません。Agent SDK 月次クレジットの権威あるデータは claude.ai/settings/usage から確認してください。

Overflow toggle

設定場所: claude.ai → Settings → 使用量（日本語 UI。英語 UI では Billing / Usage）。

自分は OFF にしています。意図せず Agent SDK クレジットを使い切ったあと、overflow 経由で従量課金が走るのを避けたいからです。本番 CI では ON より API キー移行を先 に検討する方が予測しやすい、と感じています。

GitHub Actions：認証方式で消費先が変わる

自分のリポジトリでは Claude Code Action を2パターン使い分けています。

推奨パターン — PR レビュー（API キー）

anthropic_api_key を渡すと API 従量課金 になり、Agent SDK 月次クレジットは消費しません。

- name: Run Claude Code Review
  uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    prompt: '/code-review:code-review ${{ github.repository }}/pull/${{ github.event.pull_request.number }}'

6/15 から要注意 — @claude メンション応答（OAuth トークン）

claude_code_oauth_token を使うと、6/15 以降 おさいふ2（Agent SDK 月次クレジット） を消費します。

- name: Run Claude Code
  uses: anthropics/claude-code-action@v1
  with:
    claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}

@claude への issue/PR コメント応答は イベントドリブン なので Routines では代替できません。Agent SDK クレジットを守りたいなら、こちらも API キー方式への移行を検討する余地があります。PR レビュー側はすでに API キー方式なので、そのパターンを横展開するイメージです。

加えて、デイリーノート作成 も OAuth 付き GHA で動かしている定期タスクです。Vault が Git 管理されているので Remote Routine に載せ替えればおさいふ1 に戻せます。イベント駆動ではない定期実行は、@claude より先に Routine 移行を検討する対象だと感じています。

高頻度 CI を API キー直指定に寄せる例:

name: PR Review

on: [pull_request]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Review with Claude
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          claude -p "このPRをレビューして重要な問題があれば指摘して" \
            --output-format json \
            < git diff HEAD~1

コスト試算：どこまで自動化できるか

Max 5x（$100/月）+ Agent SDK $100

PR レビュー自動化の目安（Sonnet 4.6、1PR あたり入力5万 tok + 出力5,000 tok ≒ $0.225）:

• Agent SDK $100 ≒ 約444 PR/月（1日約14.8 PR）

エンジニアが1日10 PR 以下なら、Max 5x の Agent SDK 枠だけで日常的な PR レビュー自動化は賄える計算です。

Pro（$20/月）+ Agent SDK $20

• Agent SDK $20 ≒ 約88 PR/月（1日約2.9 PR）

Pro で Agent SDK を使うなら 「週数回の重要タスク」 に絞るのが現実的です。1日5 PR 以上の CI は API キー移行が必須に近いです。

高頻度 CI を API キー + Haiku に寄せた場合

前提: 1日10 PR、diff 平均5,000 tok、出力1,000 tok、月22営業日。

精度重視なら Sonnet、コスト最優先なら Haiku。いずれにせよ Agent SDK 月次クレジット（Pro $20）より 予測可能で安い ケースが多いです。

自分の構成例

インタラクティブは Claude と Codex を 容量と精度で振り分け、自動化は Remote Routine を最優先、おさいふ2 は 本当に Routine で代替できないものだけ、という分担です。

まとめ

6/15 の Claude Code 料金改定を整理して感じたのは、「クレジット制になった」は自動化部分の話に限られる ということです。

Claude と Codex を両方使うなら、日中はおさいふ1（対話 + /loop + Cowork）、夜は Remote Routine と Codex クラウドで「朝イチ確認」ループ、Claude と Codex は容量と精度で交互に、おさいふ2 と CI は本当に必要なものだけ、という5層が自分にはしっくりきました。Loop Engineering で語られる「夜中に AI が仕事する」体験は、Remote Routine（おさいふ1）と Codex クラウドの組み合わせで、6/15 以降も現実的に回せる、というのがこの記事の実務的な結論です。

6/15 以降は Console に Agent SDK 月次クレジット欄が表示されるので、公開後にそちらも含めて使用量ページを再確認する予定です。もっとスマートな使い分けを御存知の方がいれば、ぜひ教えてください。

参考資料

• Claude Help Center: Use the Claude Agent SDK with your Claude plan
• Claude Help Center: What is the Pro plan?
• Claude Help Center: What is the Max plan?
• Claude Help Center: Usage limit best practices
• Claude Code Docs: Agent SDK overview
• Claude Code Docs: Routines
• Claude Code Docs: Run Claude Code programmatically (headless)
• Claude Code Docs: Manage costs effectively
• OpenAI Developers: Codex Pricing
• How Codex Usage Limits Work (knightli.com)
• DevelopersIO: Loop Engineering入門 — Claudeで自律ループを6段階で実装する
• DevelopersIO: Claude Code Codexとのクロスレビュー運用