結論：上位モデルを「スループット確保」のために選ぶ理由が薄れた
AnthropicがClaude APIの利用階層をStart / Build / Scaleの3階層（および専任チームが管理するCustom）に再編し、Haiku・Sonnet・Opusといった主要モデルのレートリミット（RPM／ITPM／OTPM）が階層ごとに横並びになりました（出典：Anthropic公式ドキュメント「Rate limits」Claude Platform Docs、2026年6月30日閲覧）。
この変更が実務に与える意味は、料金そのものの値下げではありません。「処理量（スループット）を確保するために、より上位で高価なモデルを選ぶ」という従来の判断軸が成立しなくなったことです。Haiku 4.5でもOpus 4.xでも、同じ階層なら同じ1分あたり処理上限が割り当てられます。つまりモデル選定は、これまで以上に「タスクに必要な知能の質」と「トークン単価」だけで決められるようになりました。AI機能を内製・外注する情シス、開発責任者、購買担当にとっては、調達設計（どの階層・どのモデルを前提に見積もるか）を見直す好機です。
時系列の出典について補足すると、3階層への再編はAnthropic公式ドキュメントで確認できる事実です。具体的な切り替え日を「2026年6月26日前後」とする情報は報道によるもので、本記事では公式に確認できた階層構成・数値のみを根拠として扱います。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
何が変わったのか：3階層の構成と上限
公式ドキュメントに基づく3階層の月間スペンドキャップ（月間の利用上限額）と、主要モデルのレートリミットは次のとおりです。RPMは1分あたりリクエスト数、ITPMは1分あたり入力トークン数、OTPMは1分あたり出力トークン数を表します。
| 利用階層 | 月間スペンドキャップ | 主要モデル RPM | 主要モデル ITPM | 主要モデル OTPM |
|---|---|---|---|---|
| Start | 500ドル | 1,000 | 2,000,000 | 400,000 |
| Build | 1,000ドル | 5,000 | 5,000,000 | 1,000,000 |
| Scale | 200,000ドル | 10,000 | 10,000,000 | 2,000,000 |
| Custom | 上限なし（個別調整） | 個別 | 個別 | 個別 |
ここでの「主要モデル」とは、Claude Opus 4.x（Opus 4.8／4.7／4.6／4.5の合算）、Claude Sonnet 4.x（4.6／4.5の合算）、Claude Haiku 4.5を指します。この3グループは、いずれの階層でもRPM・ITPM・OTPMが完全に同一です（出典：Anthropic「Rate limits」、2026年6月30日閲覧）。たとえばStart階層では、HaikuもSonnetもOpusも一律で2,000,000 ITPM・400,000 OTPMが割り当てられます。
ただし最上位モデルのClaude Fable 5だけは別枠で、上限は低めに設定されています（Start階層で500,000 ITPM／100,000 OTPM）。最も高度な長時間エージェント処理向けの位置づけであり、横並びの対象外である点は調達時に押さえておくべきです。
モデル別の単価：横並びの上限の下で効いてくる差
レート上限が横並びになった一方で、トークン単価はモデルごとに明確な差があります。Anthropic公式の料金体系（2026年6月時点）では、100万トークン（MTok）あたりの入力／出力単価は以下のとおりです。
| モデル | 入力（$/MTok） | 出力（$/MTok） |
|---|---|---|
| Claude Opus 4.8 | 5 | 25 |
| Claude Sonnet 4.6 | 3 | 15 |
| Claude Haiku 4.5 | 1 | 5 |
| Claude Fable 5 | 10 | 50 |
注目すべきは、Start階層でHaiku 4.5とOpus 4.8の処理上限（ITPM／OTPM）が同一であるにもかかわらず、入力単価はHaikuがOpusの5分の1、出力単価も5分の1である点です。
独自分析：判断軸が「容量の確保」から「品質×コスト」へ移った
ここから導ける実務上の含意は明確です。従来は「Opusのほうが処理上限の余裕がありそうだから」といった理由で上位モデルを既定にする設計が珍しくありませんでしたが、その理由は今回の再編で消えました。
同一階層で上限が等しい以上、分類・要約・抽出・定型回答といった、Haikuで品質要件を満たせるタスクは、Opusと同じスループット天井を持ちながら5分の1のトークンコストで運用できます。逆に言えば、これらのタスクを上位モデルで処理し続けることは、性能上の必然性がないまま単価を数倍払っている状態になりかねません。
この変化は、AI機能のコスト構造を「どの階層を買うか」「どのモデルで容量を確保するか」という調達・容量の問題から、「タスクごとに最小十分なモデルへ振り分け、キャッシュで実効スループットを引き上げる」という設計の問題へと移します。生成AIのコスト最適化（FinOps）の主戦場が、契約段階から実装・運用段階へ降りてきた、と捉えるのが妥当です。AIの内製可否やモデル選定の妥当性を一度棚卸ししたい場合は、AI導入可否アセスメントで現行のモデル配分とコスト構造を点検することをおすすめします。
キャッシュを効かせる設計がコストを左右する
もう一つ、再編後のコスト設計で見落とせないのがプロンプトキャッシュとレートリミットの関係です。公式ドキュメントによれば、多くのClaudeモデルではキャッシュから読み出された入力トークン（cache_read_input_tokens）はITPMの上限に算入されません（出典：Anthropic「Rate limits」、2026年6月30日閲覧）。さらにキャッシュ読み出しは課金単価も入力基本価格の約10%に抑えられます。
つまり、システムプロンプト・ツール定義・長い参照文書・会話履歴といった繰り返し送る内容をキャッシュに載せれば、レート上限を増やさずに実効的な処理量を引き上げつつ、トークン課金も圧縮できます。公式の例では、2,000,000 ITPMの上限とキャッシュヒット率80%の組み合わせで、実効的に1分あたり1,000万トークン（うち800万はキャッシュ）を処理できるとされています。
このため、再編後のコスト最適化は「上位階層を契約して容量を買う」より先に、「キャッシュ設計を整え、安定する内容を前方に固定する」ほうが費用対効果が高い場面が増えます。
自社への翻訳：見直しチェックリスト
再編を踏まえ、AI機能を運用・調達する立場で確認すべき項目を整理します。
- 現在Opusで処理しているタスクのうち、Haiku／Sonnetで品質要件を満たせるものを棚卸ししたか
- モデル選定の根拠が「スループット確保」になっていないか（再編で無効化）
- 見積もり・予算は、3階層のどの月間スペンドキャップ（500／1,000／200,000ドル）を前提にしているか
- システムプロンプト・ツール定義・参照文書をプロンプトキャッシュに載せ、cache_read分をITPMから外せているか
- 安定する内容を前方、変動する内容（タイムスタンプ・可変の質問）を後方に置き、キャッシュ前方一致を壊していないか
- 最上位のFable 5を使う場合、別枠の低めの上限を見積もりに反映しているか
- 階層が自動で上がる仕組みを理解し、Custom階層への移行要否を判断しているか
いつGXOに相談すべきか
次のような状況にある場合は、外部の知見を入れてモデル配分とコスト構造を設計し直す価値があります。
- 生成AIのAPI費用が想定より膨らんでいるが、どのタスクを下位モデルへ移せるか判断材料がない
- PoCは動いたが、本番運用時のレート上限・コスト・キャッシュ設計まで詰められていない
- 内製チームのリソースが足りず、モデル選定とFinOps設計を伴走してほしい
モデル選定とコスト最適化の妥当性検証はAI導入可否アセスメントが起点になります。設計だけでなく実装・本番運用までを成果ベースで伴走してほしい場合は、FDE+による成果まで伴走する開発支援が選択肢です。自社のAI活用がどの段階にあるかを先に把握したい場合は、AI導入適性診断から着手するとよいでしょう。
FAQ
Q. 今回の再編で料金は安くなったのですか。 A. トークン単価そのものの変更ではありません。利用階層がStart／Build／Scaleの3つに整理され、Haiku・Sonnet・Opusのレートリミットが階層ごとに横並びになった点が主な変化です（出典：Anthropic「Rate limits」、2026年6月30日閲覧）。
Q. すべてのモデルでレート上限が同じになったのですか。 A. Opus 4.x・Sonnet 4.x・Haiku 4.5は同一階層で上限が同じです。最上位のClaude Fable 5だけは別枠で、上限は低めに設定されています。
Q. どのモデルを既定にすべきですか。 A. 用途によります。レート上限が横並びになった以上、容量を理由に上位モデルを選ぶ必要は薄れました。タスクに必要な知能の質を満たす最小のモデルを選び、繰り返し送る内容をキャッシュに載せるのが基本方針です。
Q. キャッシュはコストにどう効きますか。 A. 多くのモデルでキャッシュ読み出し分（cache_read_input_tokens）はITPMに算入されず、課金も入力基本価格の約10%に抑えられます。安定する内容を前方に固定すると効果が出ます。
