Claude Codeの料金、結局どれが安い?Pro/Max/API使い分けの判断軸
ProとMaxとAPI、どれが得かは作業内容で変わる。僕が3日のログで決めた選び方と、月額費用を概算するコードを置きました。最新額は公式で。
「Maxにしたら速くなるんですか?」
知人にそう聞かれて、僕は即答できませんでした。Claude Codeを毎日使っているのに、です。理由はあとで分かりました。速さや得かどうかは、プランの名前じゃなくて、その人が何をやらせているかで決まるからです。同じMax 20xでも、週末に小さなアプリを触る人にはオーバースペック。逆に毎日でかいリポジトリを相手にする人には、Proだと上限待ちで仕事が止まる。
僕も最初は「とりあえず一番安いのから」で始めて、毎日のように上限に当たって舌打ちしていました。逆に勢いでAPIに切り替えたら、巨大ログを丸ごと読ませた日だけ請求が跳ねて青ざめた。どっちも、自分の使い方を測らずに名前で選んだのが原因でした。
この記事では、料金表の暗記ではなく**「どの作業のために、どの財布から払うか」**の決め方を書きます。具体的な金額は変わるので、最新は公式で確認する前提で進めます。
この記事の要点
- プランは「安さ」ではなく**「どの作業の時間を買うか」**で選ぶ。安さから入ると上限待ちか請求跳ねのどちらかにハマる。
- 個人はまずProで1週間だけ実測。毎日上限に当たるならMaxへ。決め打ちしない。
- API従量課金は回数と入力量を測れる作業(夜間ジョブ・CI要約・分類)向き。人と試行錯誤する作業はサブスクのほうが予算が読める。
ANTHROPIC_API_KEYが環境変数に残っていると、サブスクのつもりがAPI課金になる。作業前に/statusで認証先を確認する。- 下に置いたNode.jsコードで月額APIを概算できる。最新の単価は公式の料金ページで上書きして使う。
まず、財布が2つあると知る
最初につまずいたのが、ここでした。Claude Codeの支払いには経路が2つあります。
ひとつはサブスクリプション。Pro / Max / Team といった月額プランの枠内でClaude Codeを使う形です。もうひとつはAPI従量課金。APIキーやConsoleのクレジットで、使ったトークンの分だけ払う形です。
同じ「Claude Code」を起動していても、どっちの財布から引かれているかは認証方法で決まります。ここを混同すると、「月額払ってるのに、なぜか別で請求が来た」が起きます。実際、僕が最初にやらかしたのがこれでした。
| 経路 | 払い方 | 予算の読みやすさ | 向く使い方 |
|---|---|---|---|
| サブスク(Pro/Max/Team) | 月額固定 | 読みやすい(定額) | 人が試行錯誤する開発・学習 |
| API従量課金 | トークン単価 | 使い方次第で変動 | 回数と量を測れる自動処理 |
トークンとコンテキスト、ここだけ押さえる
料金の話にトークンとコンテキストが必ず出てくるので、先に一言で。
トークンは、Claudeが読む文字と返す文字を細かく区切った課金の単位です。日本語の文字数とぴったり一致はしませんが、ざっくり「長いログ・長い設計書・大きな差分・長い回答ほどトークンが増える」と思えば十分です。
コンテキストは、Claudeが今この瞬間に抱えている材料です。会話履歴、読ませたファイル、CLAUDE.md、ツールの定義、要約。ここがふくらむと、ちょっとした修正でも毎回ぶ厚い入力を払うことになります。別の作業に移ったのに前の会話を残したまま、というのが地味に効いてきます。
この2つが分かると、なぜ「巨大ログを丸投げすると高い」のか、なぜ「タスクを変えたら整理すべき」なのかが腑に落ちます。
2026-06時点の料金メモ(最新は公式で)
金額は変わるので参考値として置きます。執筆時点で公式ページから読み取れた範囲では、こんな並びでした。
- Pro: 年払いだと月あたり17ドル前後、月払いで20ドル前後。Claude Codeが含まれる。
- Max: 個人向けの上位。Max 5xが月100ドル前後、Max 20xが月200ドル前後と案内。
- Team: 5〜150人向け。標準席が1席あたり月20〜25ドル、プレミアム席が月100〜125ドルあたり。
- Enterprise: 席料金に加えて利用量がAPI料金で伸びる構成。
API側の単価(100万トークン=MTok あたり)は、おおよそ次の関係でした。
| モデル | 入力 / MTok | 出力 / MTok | キャッシュ読み取り / MTok | 普段の使いどころ |
|---|---|---|---|---|
| Haiku 4.5 | 1ドル | 5ドル | 0.10ドル | 分類・ログ要約など軽い処理 |
| Sonnet 4.6 | 3ドル | 15ドル | 0.30ドル | 開発の基準。まずこれ |
| Opus 4.8 | 5ドル | 25ドル | 0.50ドル | 難しい設計判断だけ上げる |
税・地域差・キャンペーンは別なので、契約前は必ず最新を見てください。一次情報はここです。
普段の開発はSonnetを基準に、軽い分類やログ要約はHaiku、難しい設計判断だけOpusに上げる。この三段使いが、僕の財布にはいちばん優しかったです。
どれを選ぶ? 5パターンの早見表
名前で迷うより、自分の使い方を一行で当てはめるのが速いです。
| 選択肢 | こんな人 | 切り替えの合図 |
|---|---|---|
| Pro | 週数回の実装・学習・軽いレビュー | 上限待ちが月に数回で済んでいる |
| Max 5x | 毎日Claude Codeを開く個人開発者 | 待ち時間の損が月100ドルを超えてくる |
| Max 20x | 長いレビュー・大規模修正・複数案件 | 上限待ちが納期リスクになっている |
| Team標準席 | 5人以上で請求をまとめたいチーム | SSO・管理・利用分析がほしい |
| Teamプレミアム/API | 重い開発・CI・研修・社内自動化 | 1人あたりの月次利用を測れる |
基本操作から固めたい人はClaude Code 始め方ガイドを、会話が重くて返答が雑になってきた人はトークン節約の実践を先に読むと、同じプランでも体感がだいぶ変わります。
判断の流れを図にすると
flowchart TD
A["やりたい作業を一行で書く"] --> B{"人が試行錯誤する作業か"}
B -->|はい| C["Pro/Maxで上限と待ち時間を実測"]
B -->|いいえ| D{"回数と入力量を見積もれるか"}
D -->|はい| E["APIでトークン単価を計算"]
D -->|いいえ| C
C --> F["3日以上連続で上限なら上位プランへ"]
E --> G["月次上限・auto-reload・承認者を決める"]
この図の肝は、最初に「どの作業の時間を買うのか」を決めることです。安いプラン探しから入ると、レビューしきれない大きな差分を量産するか、上限待ちで作業が止まるか、どちらかに転びます。料金は、時間・品質・納期を同じ机に並べて決める。これだけで判断がぶれなくなりました。
効く場面を3つ+1つ
1. 個人開発:週末のアプリや記事サイト
週末だけ触る人は、まずProで十分です。CRUD画面、テスト追加、README整備、記事内コードの動作確認を1週間試して、週末ごとに上限で止まるならMax 5xを検討。いきなりAPI従量課金で長い試行錯誤をすると、会話がふくらんだ日だけ請求が跳ねて、初心者には予算が読めません。
2. 小規模チーム:レビューとテストを標準化
5人以上ならTeam標準席で、中央請求と管理を先に整えます。全員をいきなりプレミアム席にせず、重いリファクタリング担当・レビュー担当・CI整備担当だけ利用状況を測る。CLAUDE.mdにレビュー観点・禁止コマンド・最小テストを固定すると、毎回の説明が消えて、トークンも人間のレビュー時間も減ります。
3. CIと自動化:測れる仕事だけAPIへ
CIで失敗ログを要約する、夜間に依存更新PRの下書きを作る、問い合わせを分類する。このあたりはAPI向きです。回数・入力サイズ・モデルを自分で決められるから。逆に「原因が分からないから一緒に探す」作業は、人が途中で止めたり方針を変えたりするので、サブスクのほうが予算を読みやすいです。
4. 研修・導入:ROIは時間で語る
研修では「利用料いくら」より「人のレビュー時間が減ったか」「新人がコードを把握する時間が縮んだか」を測ります。10人が週に各2時間を浮かせたら、20時間ぶんの価値。プラン比較に時間を使うより、標準プロンプト・レビュー手順・失敗時の戻し方をチームに根付かせるほうが、よほど効きます。
月額APIを概算するコード
口で言うより数字を見たほうが早いので、1日あたりの入力・出力・キャッシュ読み取り量から、月額APIをざっくり出すコードを置きます。MTokは100万トークンの意味。単価は参考値なので、運用前に公式で上書きしてください。
// estimate-claude-code-api-cost.mjs
// 1日あたりの利用量から月額APIを概算する。単価は最新を公式で上書きすること。
const rates = {
sonnet46: { input: 3, output: 15, cacheRead: 0.30 },
haiku45: { input: 1, output: 5, cacheRead: 0.10 },
opus48: { input: 5, output: 25, cacheRead: 0.50 },
};
const [daysArg, inputArg, outputArg, cacheArg, modelArg] = process.argv.slice(2);
const usage = {
days: Number(daysArg ?? 20), // 稼働日数
inputMTokPerDay: Number(inputArg ?? 0.8), // 1日の入力(MTok)
outputMTokPerDay: Number(outputArg ?? 0.15), // 1日の出力(MTok)
cacheReadMTokPerDay: Number(cacheArg ?? 0.4),// 1日のキャッシュ読み取り(MTok)
model: modelArg ?? "sonnet46",
};
const rate = rates[usage.model];
if (!rate) {
throw new Error(`知らないモデル: ${usage.model}(sonnet46 / haiku45 / opus48 から選ぶ)`);
}
const dailyUSD =
usage.inputMTokPerDay * rate.input +
usage.outputMTokPerDay * rate.output +
usage.cacheReadMTokPerDay * rate.cacheRead;
const monthlyUSD = dailyUSD * usage.days;
console.log(JSON.stringify({
model: usage.model,
activeDays: usage.days,
dailyUSD: Number(dailyUSD.toFixed(2)),
monthlyUSD: Number(monthlyUSD.toFixed(2)),
}, null, 2));
実行はこれだけ。
node estimate-claude-code-api-cost.mjs 20 0.8 0.15 0.4 sonnet46
この例は20営業日、1日あたり入力0.8MTok・出力0.15MTok・キャッシュ読み取り0.4MTokを置いています。現実には、でかいログや長い会話を読ませた日だけ入力がはね上がる。だからまず3日記録して、平均だけでなく最大値も見てください。最大値を見ておかないと、跳ねた日に足元をすくわれます。
サブスクの損益分岐も出しておく
月額プランは、トークン単価ではなく待ち時間と人の工数で考えます。月額料金・自分の時間単価・浮いた時間から、プラン変更が見合うかを粗く見るコードです。
// plan-roi-check.mjs
// 月額プランが工数削減に見合うかを粗く判定する。
const [planName = "Max 5x", priceArg = "100", hourlyArg = "50", hoursArg = "3"] =
process.argv.slice(2);
const monthlyPriceUSD = Number(priceArg); // 月額(ドル)
const hourlyValueUSD = Number(hourlyArg); // あなたの時間単価(ドル)
const hoursSaved = Number(hoursArg); // 月に浮いた時間(h)
const valueUSD = hourlyValueUSD * hoursSaved;
const netUSD = valueUSD - monthlyPriceUSD;
const breakEvenHours = monthlyPriceUSD / hourlyValueUSD;
console.log(`${planName} の月額: $${monthlyPriceUSD.toFixed(2)}`);
console.log(`浮いた価値の概算: $${valueUSD.toFixed(2)}`);
console.log(`差し引き: $${netUSD.toFixed(2)}`);
console.log(`損益分岐: 月 ${breakEvenHours.toFixed(1)} 時間の節約で元が取れる`);
実行例。
node plan-roi-check.mjs "Max 5x" 100 50 3
時間単価を外注費や時給だけで見ると、低めに出がちです。納期遅延・レビュー待ち・障害調査・学習時間まで含めると、MaxやTeamが妥当になるケースが普通にあります。逆に、Claudeの出力を読む時間がむしろ増えているなら、上位プランに上げる前に、依頼文と検証手順を直すのが先です。トークン課金そのものの仕組みをもっと知りたい人はLLM APIの料金とトークン課金の仕組みに詳しく書きました。
僕がはまった落とし穴5つ
正直に書きます。請求まわりは何度かヒヤッとしました。
ひとつ目。ANTHROPIC_API_KEYを環境変数に残したまま、ProやMaxの枠内のつもりで使っていた。公式ヘルプでは、環境変数のAPIキーがあるとサブスクよりAPIキー認証が優先され、API従量課金になると説明されています。サブスク内に収めたい日は、Claude Code内の/statusで認証先を確認するのが鉄則です。
ふたつ目。/usageの金額を請求額そのものだと思っていた。公式コスト管理ページは、/usageのSession欄はAPIユーザー向けのローカル見積もりで、正式な確認はClaude ConsoleのUsageページを見るよう案内しています。
みっつ目。巨大ログ・PDF・長いWebページをそのまま読ませた。Web fetchに追加料金がなくても、取り込んだ中身は会話の入力トークンになります。ログは先にrgやgrep、小さなスクリプトで絞り、Claudeには失敗箇所と周辺だけ渡す。これだけで入力がぐっと軽くなりました。
よっつ目。サブエージェントを常用していた。調査やテスト作成を分担できて便利ですが、それぞれが別のコンテキストを抱えます。公式ドキュメントも、エージェントチームは標準セッションよりトークンを多く使う場合があると説明しています。使うなら、小さい依頼・短い時間・明確な終了条件で。
いつつ目。何でもOpusや拡張思考で投げていた。深い設計や難しい障害調査には効きますが、簡単な修正や分類ならSonnetやHaikuで足ります。モデルは「高いほうが安心」ではなく、「この判断に追加コストを払う価値があるか」で選ぶ。これに切り替えてから、月末の数字が落ち着きました。
1日の予算ループ(これが一番効いた)
朝、今日の成果物を1つだけ書きます。「認証バグを直す」「PRを2本レビューする」「記事内コードを動作確認する」のように、終わりが見える単位で。開始時に/statusと/usageを見て、サブスク利用かAPI利用か、前のコンテキストが残っていないかを確認します。
作業中は、小さいファイルから読ませて、広い探索の前に計画を出させる。テストは最小ケースから始めて、通ったら範囲を広げる。タスクが変わるときは/clearか/compactでコンテキストを整理する。終業時に、作業名・使ったモデル・上限に当たったか・浮いた時間・レビューで戻った箇所を、CSVかスプレッドシートに一行残す。
3日続けて上限待ちが起きたらMaxやTeamプレミアムを検討。逆に、上限には当たっていないのに成果が薄いなら、それはプランではなく運用の問題です。要件・変更範囲・検証コマンド・禁止事項を最初に渡すだけで、同じ料金でも成果はかなり変わります。
よくある質問
Q. ProとMax、結局どっちが得ですか? A. 使ってみるまで分かりません。まずProで1週間。毎日のように上限で止まるならMax 5x、長いレビューや大規模修正で納期が危ういならMax 20x。決め打ちより1週間の実測が安いです。
Q. APIとサブスク、どっちが安いですか? A. 作業の種類で逆転します。回数と入力量を測れる自動処理(CI要約・夜間ジョブ・分類)はAPIが読みやすく、人と試行錯誤する開発はサブスクが読みやすい。安さは「読みやすさ」とセットで考えてください。
Q. 月額を払っているのに別で請求が来ました。なぜ?
A. ANTHROPIC_API_KEYが環境変数に残っていると、サブスクよりAPIキー認証が優先されてAPI課金になります。/statusで認証先を確認してください。
Q. /usageの金額が請求額と合いません。
A. /usageのSession欄はローカルの見積もりです。正式な金額はClaude ConsoleのUsageページで確認します。
Q. コストを今すぐ下げたいです。最初の一手は?
A. 巨大ログの丸投げをやめて失敗箇所だけ渡す、タスク変更時に/clearか/compactで整理する、難しい判断以外はSonnet/Haikuに下げる。詳しくはトークン節約の実践に。
実際に試した結果
僕の運用では、プランを先に決めるより、3日分の作業ログを取ってから判断するほうが圧倒的に失敗が少なかったです。とくに効いたのは、巨大ログを渡す前に失敗行だけに絞ること、タスク変更時にコンテキストを整理すること、作業前にANTHROPIC_API_KEYと/statusを確認すること。この3つだけで、月末の「えっ」が消えました。
この記事の2つのNode.jsコードは、サンプル値で構文と出力を確認済みです。金額は必ず公式を優先してください。ここに書いたのは、暗記用の料金表ではなく、「どの作業のために、どの財布から払うか」を自分で決めるための手順です。
型を増やして毎回ゼロから依頼文を書く手間を減らしたい人はClaudeCodeLabの教材一覧にCLAUDE.mdやレビュー観点のテンプレを置いています。権限・レビュー・CI・導入までまとめて整えたいチームはClaude Code研修・導入相談へ。実リポジトリ前提で一緒に設計します。
無料PDF: Claude Code はじめてのチートシート
まずは無料PDFで基本コマンドと最初の使い方をまとめて確認してください。登録後はそのままテンプレート集や導入相談にも進めます。
スパムは送りません。登録情報は厳重に管理します。
Claude Codeを仕事で使える形にしませんか?
まず無料PDFで基本を固め、繰り返し使う作業はGumroad教材へ、チーム導入や権限設計は導入相談へ進めます。
この記事を書いた人
Masa
Claude Codeの実務活用、導入設計、収益導線改善を検証しているエンジニア。10言語の技術メディアを運営中。
関連書籍・参考図書
この記事のテーマに関連する書籍を楽天ブックスで探せます。
※ 当サイトは楽天市場のアフィリエイトプログラムに参加しています。上記リンクから商品をご購入いただくと、運営者に紹介料が支払われる場合があります。
関連記事
Claude Codeのコマンドを覚えたのに手が止まる人へ、最初の一手を安全に出す型
コマンド表を覚えたのに何を頼めばいいか分からない。読むだけで終わらず、初めての一手を安全に通すまでの手順とプロンプト雛形を紹介します。
Claude Codeで既存リポジトリの最初の1編集を安全にする導入手順
他人が書いた既存コードにClaude Codeを入れる初日に、触らせる範囲・禁止領域・検証コマンドを先に決めて事故を防ぐ実践手順。
Claude Codeに最初の1タスクを任せる依頼文の書き方
Claude Codeへの最初の依頼で事故らないために、目的・触ってよい範囲・検証・戻し方を1枚にまとめる依頼文の型を、コピペ例つきで紹介します。