Claude 1Mコンテキストの実務活用 — 対応モデル・入る分量の目安・コスト設計

Claudeの1Mコンテキストは、100万トークンを1回のリクエストで扱える枠です。Anthropic APIでは、Fable 5.1・Fable 5・Opus 5.5・Opus 5・Sonnet 5.5・Sonnet 5が既定で1Mです。Opus 4.8・4.7・4.6とSonnet 4.6も1Mで動きます。ベータヘッダーは要りません。Haiku 4.5とSonnet 4.5は200Kトークンです。

ただし「1Mまで入る」だけでは、既存の分割処理を畳んでよいか決められません。入る分量、使う場所ごとの条件、200Kを超えた分の単価、長くしたときの挙動。この4点を、公式docsと料金ページ、Claude Code v2.1.287の--helpで突き合わせます。

1Mコンテキストとは — 入力だけでなく応答も分け合う枠

コンテキストウィンドウは、モデルが1回の推論で参照できる量の上限です。上限を超えたときのAPIの挙動は、入力が長すぎる場合と生成中に達する場合とで分かれます。詳細はコンテキストウィンドウがオーバーフローしたときのClaude APIの挙動で扱っています。

この枠は添付ファイルだけのものではありません。システムプロンプト、messagesの全履歴、ツール結果、画像、文書、ツール定義がすべて入ります。さらに、応答そのものと拡張思考のトークンも枠に数えられます。

見落としやすいのが思考ブロックです。Opus 4.5以降のOpus、Sonnet 4.6以降のSonnet、Fableでは、過去ターンの思考ブロックがAPIの既定で残り、後続リクエストの入力として枠を占めます。それ以前のモデルとHaikuは自動で取り除かれます。長い対話で枠の減りが早いときは、会話の文量だけでなく、この残り方も効いてきます。

プロンプトキャッシュも枠の外には出ません。キャッシュされた接頭辞が変えるのは課金で、枠を占める量は同じです。

出力側は別の上限です。1M対応モデルの1リクエストあたりの出力は最大128Kトークンで、入力に1Mを積んでも応答が長くなるわけではありません。画像とPDFのページは1リクエストで600枚までで、200Kのモデルでは100枚までです。大量の画像や大きな文書では、トークン数より先にリクエストサイズの上限に当たることがあります。

1Mトークンに何が入るか — 語数・文字数・コードの目安

換算は、渡す前に分割要否を判断するための物差しです。公式のモデル比較表は、現行のトークナイザー(Opus 4.7で導入)での目安を次のように示しています。

同じ1Mでも、4.6以前と4.7以降では入る語数が約26%少なくなります。Opus 4.6から4.7以降へ替えると、同じ資料が「入らなくなる」ことがあるのはこのためです。増加の仕組みはClaudeの新トークナイザーでトークン数が30%増える仕組みと対処で扱っています。

コードの行数は、1行10トークン前後という仮定を置くと約10万行になります。この10トークンは筆者の仮定で、公式の値ではありません。日本語も文字種で比率が変わるので、実際の消費はClaude Codeの/contextか、APIのトークンカウント用エンドポイントで測るのが確実です。

10万行は、中規模のWebアプリケーションのソースが収まる水準です。テストと生成物を除いたアプリケーション本体なら、大型のリポジトリも射程に入ります。

対応モデルと単価

コンテキスト長はモデルの属性なので、まずモデルで決まります。料金ページと比較表の値は次のとおりです。

Opus 4.5は200Kです。Opus 5.5の仕様はClaude Opus 5.5の仕様解説にあります。

Sonnet 5の$2 / $10は導入価格として始まりましたが、9月1日に$3 / $15へ上がる予定は取り消され、標準価格になりました。1Mを単価あたりで最も安く回せるのはSonnet 5.5とSonnet 5です。判断の質が要る横断調査は、Opus以上に段差があります。4系統の違いはClaudeモデル比較(Fable / Opus / Sonnet / Haikuの使い分け)で扱っています。

Haiku 4.5は200Kのままで、公式の廃止時期は2026年10月15日より前にはならないとされています。抽出や分類を安く回す役の置き場所は、当面ここです。

使う場所ごとの条件

同じモデルでも、どこから使うかで枠が変わります。統合後のアプリでMax 5xのOpus 4.6が200K相当で動くという報告は、Opus 4.6が200Kになる報告の整理にあります。

API:モデルIDを指定するだけ

Messages APIでは、対応モデルのIDを指定すれば1Mが既定で使えます。長いコンテキストのための追加パラメータはありません。仕様の細部はClaude Fable 5の解説にあります。

API側には、長いセッションを支える仕組みが2つあります。サーバー側コンパクションは、Claude 4.6以降のモデルでベータとして使えます。古い会話を要約して詰める機能で、枠を超えて会話を続ける用途に向きます。コンテキスト編集は、古いツール結果や思考ブロックを消します。

もう1つがコンテキスト認識です。Sonnet 5とSonnet 4.6、Sonnet 4.5、Haiku 4.5は、残りトークンをAPIが注入するタグで把握します。Opus 4.7以降とSonnet 5.5、Fableにはこのタグが入りません。この世代では、ベータのタスク予算で上限を明示する形になります。同じ「1M」でも、残量の伝わり方が世代で違います。

Bedrock・Google Cloud・Microsoft Foundry:v2.1.287から[1m]が要るのは旧世代だけ

Claude Codeをこれらのプロバイダー経由で使うときの枠は、v2.1.287(2026年10月1日)で変わりました。

v2.1.286以前では、Opus 4.8以降はこの3つで200Kで動きました。1Mにするには、環境変数でモデルIDを固定するときに[1m]を付けます。v2.1.287以降は、Opus 4.7以降とFableが、この3つとClaude appsゲートウェイで[1m]なしのまま既定1Mです。CLAUDE_CODE_DISABLE_1M_CONTEXT=1を設定すると200Kのままになります。

model-configページには、Opus 4.8以降がBedrockなどで200Kで動く例が今も載っていて、changelogのv2.1.287と食い違っています。手元のバージョンで/contextを見れば、実際の枠が分かります。

Opus 4.6とSonnet 4.6は、v2.1.287以降も[1m]が要ります。

export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-6[1m]'

[1m]は変数ごとに読まれます。同じモデルでも、[1m]を付けていない変数で呼ぶとOpus 4.6は200Kです。Sonnet 5もこれらのプロバイダーで常に1Mです。エイリアスの解決先もプロバイダーごとに違い、Microsoft FoundryのopusはOpus 4.6、sonnetはSonnet 4.5です。Foundryのopusは、[1m]なしでは200Kで動きます。

自前のLLMゲートウェイをANTHROPIC_BASE_URLで挟む場合は、Claude Codeが認識したモデルにAPIと同じ枠を割り当てます。ゲートウェイ側が200Kを超えるリクエストを拒否するなら、/autocompact 200kで圧縮の境界を合わせます。ゲートウェイ側の上限をClaude Codeは検知できません。

Claude Code:Fableの課金とOpus 4.6の[1m]だけがプランで変わる

Claude Codeでは、/modelのピッカーでモデルを選ぶか、エイリアスに[1m]を付けて明示します。Sonnet 5.5とSonnet 5は常に1Mのため、sonnet[1m]は何も変えません。

/model opus[1m]
/context

Anthropic APIに直接つなぐ場合、Fable 5.1・Fable 5・Sonnet 5以降・Opus 4.7以降は、Proを含む全プランで1Mが既定です。[1m]の選択もusage creditsも要りません。プランで分かれるのは、[1m]指定が必要な旧世代の2つです。

Teamは、StandardとPremiumのどちらの席でも同じ扱いです。1Mの枠とは別に、Fable自体の利用がプランによってusage creditsで課金されることがあります。claude.comの料金ページのモデル欄では、FableがFreeでは使えず、Proではusage creditsです。usage creditsで課金される場合、ピッカーのFable行に「Requires usage credits」と出ます。対話セッションでは、課金の前に同意画面も出ます。

既定のモデルの動きも1Mに影響します。Sonnet 5はv2.1.197(2026年6月30日)でClaude Codeの既定になり、ネイティブ1Mを持ち込みました。Opus 5はv2.1.219(2026年7月24日)で既定のOpusになり、ピッカーの表示も「Opus (1M context)」に揃いました。v2.1.280(2026年9月22日)でOpus 5.5へ更新され、ProとTeam Standardの既定モデルもSonnetからOpusに変わっています。経緯はClaude Code v2.1.280の解説とClaude Code v2.1.219の解説にあります。

チーム内でプランが混在すると、同じ設定を配っても旧世代の1Mが有効な人とそうでない人が出ます。1Mを使わせたくないときは、環境変数CLAUDE_CODE_DISABLE_1M_CONTEXT=1が使えます。1Mの変種がピッカーから消え、ネイティブ1Mのモデルも200Kとして扱われます。自動圧縮が有効なら200Kの境界で圧縮され、無効なら200Kでコンテキスト上限のエラーで止まります。

claude.aiの対話・Claude Code・Coworkで枠が違う

Claudeのヘルプセンターは、有料プラン(Pro・Max・Team・Enterprise)の枠を、使う場所ごとに分けて載せています。

「Claudeは1M」と一括りにせず、使う場所の列を見る必要があります。

対話ではモデルを選ぶと枠が決まります。code executionを有効にした有料プランでは、枠に近づくと古いメッセージが自動で要約されます。この自動管理が走った長い会話は、使用量の枠を多く消費します。

200Kを超えた分に追加単価は乗らない

料金ページは「Claude 4.6以降のモデルは、1Mコンテキストの全体を標準単価で含む」と明記しています。90万トークンのリクエストも、9千トークンのリクエストと同じトークン単価です。プロンプトキャッシュとバッチ処理の割引も全長で標準どおりです。Claude Codeでも、200Kを超えた分に追加の単価は乗りません。

Fable 5・Opus 5.5・Opus 5・Sonnet 5.5・Sonnet 5はこの扱いです。その分、分割の判断はコストよりも精度の問題になります。「単価が上がるから200Kに収める」という理由だけの分割は畳めます。残るのは、後述する圧縮と精度の問題です。

実務で1Mが効く2つの型

効果が出やすいのは、全体を見ないと正解が決まらないタスクです。独立した小タスクの繰り返しでは効きません。

大規模リポジトリの横断調査と移行

1つ目は、コードベース全体を前提にする作業です。関数の削除が安全かは、呼び出し元、テスト、設定ファイル、移行スクリプトを同時に見ないと決まりません。200Kだと探索と要約を挟んで読むことになり、要約で落ちた情報が判断を狂わせます。

1Mなら、アプリケーション本体を積んだまま調査を始められます。フレームワーク移行、命名規約の一括変更、廃止APIの追跡のような、影響範囲の見落としが致命的な作業が当たります。1Mに収まらない規模でも、機能ドメイン単位で切り出せば、その中は分割なしで扱えます。境界をどこに引くかが設計の勘所です。

長文資料の一括分析

2つ目は、複数資料の突き合わせです。契約書・仕様書・議事録を同時に渡して、仕様書にあって契約書に反映されていない条件を出す。四半期分の障害報告から、再発している原因を抽出する。1本ずつ処理すると、横断的な矛盾が見えません。

長文セッションで引っかかること

1Mを日常的に回すと、200Kまででは起きなかった問題に当たります。

自動圧縮はいつ走るか

ネイティブ1Mのモデルは、枠が埋まる手前の約967Kトークンで自動圧縮します。これが既定です。200Kの境界で走るのは、次の場合です。

• 1Mの変種を使わないSonnet 4.6・Opus 4.6
• v2.1.286以前のBedrock・Google Cloud・Foundryで、[1m]なしのOpus 4.8以降
• CLAUDE_CODE_DISABLE_1M_CONTEXT=1を設定したセッション

1Mのうち必要な範囲だけで運用したいときは、圧縮の境界を自分で決められます。

指定できる値は100Kから1Mトークンで、モデルの枠を超えることはできません。v2.1.287のclaude --helpでは、フラグが次のように出ます。

--autocompact <auto|tokens>           Auto-compact window size (auto, or
                                      100k–1M tokens)

過去の不具合から見えること

圧縮まわりの判定は、1M対応の初期に何度も直されています。Opus 4.7のセッションで/contextの使用率が膨らみ、早く圧縮される不具合は、200Kの枠で計算していたのが原因で、v2.1.117で修正されました。小さい圧縮ウィンドウを設定した1Mモデルが、API上限の手前でPrompt is too longと誤って止まる問題は、v2.1.128で解消されました。長文セッションの様子がおかしいときは、まずClaude Codeを更新するのが早い切り分けです。

残量表示の読み方

ステータス行のused_percentageは、常にモデルの枠全体を分母にします。CLAUDE_CODE_AUTO_COMPACT_WINDOWを設定すると、この数字は圧縮が走る位置を示さなくなります。500Kに設定した場合、表示が50%になる前に圧縮が走ります。

周辺機能の予算も枠に連動する

Skillの説明文の一覧は、枠の1%を文字数の予算にします。予算を超えると、Claude Codeは一部のskillの説明文を削ります。説明文が削られると、Claudeがskillを呼び出すためのキーワードが落ちます。同じskillの構成でも、1Mのセッションと200Kのセッションで挙動が分かれ得ます。

精度の問題

入ることと、入れた全部を等しく参照できることは別です。公式docsは、トークン数が増えると正確さと再現率が下がる現象をcontext rotと呼び、入れる内容を選ぶことは空き容量と同じくらい大事だと述べています。根拠と/clearの目安はClaudeの長い会話は精度が落ちる — context rotの根拠と/clearの目安にあります。1Mまで積めば分割が全面的に不要になる、とはなりません。索引を先に付ける、重要な制約を指示の直前に再掲する、といった手当ては1Mでも効きます。

コスト設計 — 単価は同じでも総量が効く

追加プレミアムがなくても、1Mを毎回埋めれば入力の量は増えます。1Mを1回丸ごと入力すると、Sonnet 5.5は$2、Opus 5.5は$4、Fable 5は$10です。1日100回なら、入力だけで$200から$1,000になります。

効かせどころは3つです。

• プロンプトキャッシュ: 静的な資料束を先頭に置くと、読み取りは入力単価の0.1倍です。Fable 5.1は0.025倍($10が$0.25)、Opus 5.5は0.05倍($4が$0.20)、Sonnet 5.5も0.05倍($2が$0.10)で、いずれも通常より低くなっています
• Batch API: 即時性が不要な処理は50%割引で、全コンテキスト長に適用されます
• モデルの振り分け: 全体把握が要る工程だけ1Mモデルにして、抽出や分類はHaiku 5.5に降ろします

効きを具体的な数字で見ます。Opus 5.5で1Mの資料束に20回質問すると、キャッシュなしでは入力だけで$4×20=$80です。5分キャッシュを使うと、書き込みが$5、読み取りが$0.20×19=$3.80で、合計$8.80です。質問の間隔が5分以内に収まり、読み取りでキャッシュが更新され続ける前提で、出力トークンは含みません。

同じ資料束に何度も質問する分析では、キャッシュの効きが最も大きく出ます。毎回違う資料を1回ずつ渡す使い方では、キャッシュは効かず、単価がそのまま乗ります。自分のワークロードがどちらに寄るかが、試算の出発点です。

まとめ

分割をやめるかどうかは、1本の実タスクで完了率と所要時間を比べてから決めると無理がありません。モデルの選び方そのものはClaudeとは — モデルの違いと料金・使い方にもあります。