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

Claudeの上位モデルは、100万(1M)トークンのコンテキストウィンドウを持ちます。2026年7月時点でこれに該当するのはFable 5、Opus 5、Opus 4.8、Sonnet 5の4つで、Haiku 4.5だけが200Kトークンです。分割せずに大きなリポジトリや長い資料を渡せる、というのが実務上の意味になります。

ただ「1Mまで入る」という一行では、使う判断はできません。実際に何行のコードが入るのか、どの入り口でどう有効になるのか、200Kを超えた分の単価はどうなるのか、長くしたぶん精度はどう動くのか。この4点が具体的にならないと、既存の分割処理を畳んでよいかを決められないからです。

この記事では、分量の換算、モデルと利用形態ごとの条件、コスト構造、長文セッションで実際に踏む落とし穴をまとめます。

1Mコンテキストとは — 一度に渡せる入力の上限

コンテキストウィンドウとは、モデルが1回の推論で参照できる入力量の上限です。1Mコンテキストは、この上限が100万トークンに設定されていることを指します。トークンは文章を機械が扱う単位に切り分けたもので、日本語ならおおむね1文字が1トークン前後になります。

押さえておくと判断が変わるのは、この100万トークンが添付ファイルだけの枠ではないという点です。システムプロンプト、会話履歴、添付した資料、ツールの実行結果、エージェントが読み込んだファイルの中身が、すべて同じ枠を分け合います。長時間のセッションでは、渡した資料より履歴とツール出力のほうが枠を食っている、という状況が普通に起きます。

出力側は別勘定です。Fable 5・Opus 4.8・Sonnet 5の最大出力は128Kトークンで、入力に1Mを積んでも1回の応答が長くなるわけではありません。入力の上限と出力の上限は別の数字として扱います。

1Mトークンに何が入るか — コードと文書の目安

換算の感覚を持っておくと、「この作業は分割が要るか」を渡す前に判断できます。以下は前提を置いた概算で、実際の値は言語・記法・コメント量で上下します。

10万行という数字は、中規模のWebアプリケーションのソースがまるごと収まる水準です。フレームワークを含む大型リポジトリだと足りませんが、その場合もテストと生成物を除いたアプリケーション本体なら射程に入ります。日本語の資料なら、数百ページのPDFを何本かまとめて渡せる計算になります。

対応モデルと、使う場所ごとの条件

コンテキスト長はモデルの属性なので、まずどのモデルを選ぶかで決まります。2026年7月時点の構成は次のとおりです。

Sonnet 5には2026年8月31日までの導入価格($2 / $10)が設定されています。単価あたりで1Mを最も安く回せるのはSonnet 5で、判断の質が要る横断調査ではOpusクラス以上、という段差になっています。4系統の性格の違いはClaudeモデル比較(Fable / Opus / Sonnet / Haikuの使い分け)で扱っています。

同じモデルでも、どこから使うかで条件が変わります。

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

Messages APIでは、対応モデルのIDを指定すれば1Mがそのまま既定で使えます。Fable 5の場合、長いコンテキストのための追加パラメータは不要です。既存の呼び出しでモデルIDを差し替えるだけで、入力の上限が上がります。仕様の細部はClaude Fable 5の解説にまとめてあります。

Claude Code:プラン条件が付く

Claude Codeでは、/modelのピッカーからモデルを選ぶか、Opus系はエイリアスに[1m]を付けて明示します(Sonnet 5は常に1Mのため指定不要)。

/model opus[1m]
/context

Opus 5が既定のOpusモデルになったのはv2.1.219(2026年7月24日)で、この版から/modelピッカーの表示も「Opus (1M context)」に揃いました。Sonnet 5がPro・Team Standard・Enterpriseサブスクリプション枠の既定モデルになり、ネイティブで1Mを扱えるようになったのは約1か月前のv2.1.197です(MaxとAPI経由の既定はv2.1.219までOpus 4.8のままでした)。世代交代の中身はClaude Code v2.1.219の解説で扱っています。

Claude Codeで注意が要るのは、1Mの利用条件がプランで分かれることです。

Sonnet 5は200K版が存在せず[1m]サフィックスの指定も不要で、どのプランでもusage creditなしに常時1Mで動きます。プラン条件が効くのはOpus側だけです。

チーム内でプランが混在していると、同じ設定を配っても1Mが有効な人とそうでない人が出ます。逆に、コストを固定したくて1Mを使わせたくない場合は、環境変数CLAUDE_CODE_DISABLE_1M_CONTEXT=1で完全に無効化できます。Claude Code側の全体像はClaude Code完全ガイドを参照してください。

claude.ai:モデル選択に従う

claude.aiのWeb・デスクトップ・モバイルでは、モデルピッカーからモデルを選ぶ形になります。コンテキスト長そのものを画面から指定する項目は、公開されている情報からは確認できません。1Mを意識して使い分ける運用は、実質的にAPIとClaude Codeが対象になります。

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

長いコンテキストの料金は、以前のような「一定量を超えると単価が上がる」構造とは限りません。Fable 5については、コンテキスト長による追加のプレミアム料金がないことが明示されています。900Kトークンのリクエストも9Kトークンのリクエストも同じ単価で、プロンプトキャッシュとBatch APIの割引も全長に適用されます。Claude Codeでも、200Kを超えた分に追加のトークン単価は乗りません。

API経由のSonnet 5とOpus 5も同じ扱いで、公式の料金ドキュメントは「Claude 4.6以降のモデルは1Mコンテキストを標準単価で含む(90万トークンのリクエストも9千トークンと同じトークン単価)」と明示しています。長文だから単価が上がる、という心配は要りません。

追加プレミアムがないことの実務的な意味は、分割の判断がコストではなく精度の問題になるところです。以前は「単価が上がるから200Kに収める」という理由で分割していた構成も、その理由だけなら畳めます。残るのは、後述する長文での精度と自動圧縮の問題だけになります。

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

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

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

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

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

長文資料の一括分析

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

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

1Mを日常的に回すと、200Kまでの運用では起きなかった問題に当たります。実際に修正が入ってきた箇所を見ると、つまずきの場所がはっきりします。

最初に当たるのが自動圧縮です。Claude Codeには、コンテキストが埋まってきたときに会話を要約して詰めるautocompactがあります。この判定が実際のウィンドウより小さい基準で計算されていると、1Mのうち3割しか使っていないのに要約が走り、必要な詳細が落ちます。Opus 4.7セッションの/contextが200K基準で計算されていた不具合はv2.1.117で修正され、圧縮ウィンドウが小さいままAPI上限の手前でPrompt is too longに当たる問題はv2.1.128で解消されました。長文セッションで様子がおかしいときは、まずClaude Codeを更新するのが早い切り分けになります。

残量の見え方も紛らわしいところです。/contextの使用率は、そのセッションのウィンドウを基準にした割合を示します。累積の入力トークン数とは別物で、後者はウィンドウを超え得ます。ステータス行でコストを監視している場合、この2つを取り違えると判断を誤ります。

周辺機能の予算がウィンドウ比で決まる点も、意外と効きます。たとえばSkillの説明文に割ける文字数はコンテキストウィンドウに連動する設計になっており、1Mのセッションでは切り詰められる量が変わります。同じ設定でもウィンドウの大きさで挙動が変わる箇所がある、と知っておくとデバッグが早くなります。

最後が精度です。ウィンドウに入ることと、入れた全部を等しく参照できることは同じではありません。長いコンテキストの中央付近に置いた情報が拾われにくい傾向は広く知られており、1Mまで積めば分割が全面的に不要になる、とまでは言い切れません。要点を先に書いた索引を添える、重要な制約は指示の直前に再掲する、といった手当ては1Mでも有効です。

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

追加プレミアムがなくても、1Mを毎回埋めれば入力トークンの絶対量は増えます。Sonnet 5の標準単価で1Mを1回丸ごと入力すると$3、Opus 5なら$5、Fable 5なら$10。これを1日100回投げれば、入力だけで$300〜$1,000の水準になります。単価が同じでも、総量の設計は要ります。

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

• プロンプトキャッシュ: 静的な資料束を先頭に置いてキャッシュすると、読み取り分は入力単価の0.1倍になります。Fable 5なら$10が$1です
• Batch API: 即時性が不要な処理は50%割引で、これも全コンテキスト長に適用されます
• モデルの振り分け: 全体把握が要る工程だけ1Mモデル、抽出や分類はHaiku 4.5に降ろす

同じ資料束に何度も質問を投げる分析ワークでは、キャッシュの効きが最も大きく出ます。逆に毎回違う資料を1回ずつ渡す使い方では、キャッシュは効かず単価がそのまま乗ります。1Mを常用する前に、自分のワークロードが前者と後者のどちらに寄っているかを見ておくと、試算が現実に近づきます。

よくある質問

1Mコンテキストに対応しているのはどのモデルですか

2026年7月時点では、Fable 5・Opus 5・Opus 4.8・Sonnet 5が1Mトークンです。Haiku 4.5は200Kトークンで、軽量・高速な処理に振られています。

1Mトークンはどれくらいの分量ですか

ソースコードならおよそ10万行、日本語の文書ならおよそ100万字が目安です。ただし記法や言語でトークン数は変わるため、正確な値はClaude Codeの/contextやトークンカウントのAPIで測るのが確実になります。

200Kを超えると料金が上がりますか

ありません。Fable 5に限らず、Claude 4.6以降のモデルは1Mコンテキストを標準単価で含むと公式の料金ドキュメントに明示されています。Claude Codeでも200Kを超えた分に追加単価は乗りません。

Claude Codeで1Mを使うには何が必要ですか

対応モデルを選んだうえで、Opus系はプランの条件を満たす必要があります。Max / Team / EnterpriseではOpusの1Mがサブスクリプションに含まれ、ProでのOpusの1Mは追加のusage creditが必要です。Sonnet 5はどのプランでも常に1Mで動きます。API従量課金ならいずれもフルアクセスです。

1Mまで入れれば分割処理は不要になりますか

コスト上の理由での分割は畳めますが、精度の理由は残ります。長いコンテキストの中央に置いた情報は相対的に拾われにくく、指示の直前に重要な制約を再掲する、索引を添えるといった手当ては1Mでも効きます。

1Mを無効にできますか

Claude Codeでは環境変数CLAUDE_CODE_DISABLE_1M_CONTEXT=1で無効化できます。コストの上限をチームで固めたい場合や、プロンプトキャッシュの挙動を安定させたい場合の選択肢になります。

まとめ

1Mコンテキストの実務的な価値は、「全体を見ないと正解が決まらない作業」を分割せずに1回で回せるところにあります。おおよそ10万行のコードか100万字の日本語文書が入る計算で、大規模リポジトリの横断調査と、複数資料の突き合わせがはまりやすい2つの型です。

条件は使う場所によって違います。APIはモデルIDを指定するだけ、Claude CodeはOpus系のみプランによってusage creditが要る場合があり、claude.aiではコンテキスト長を指定する操作が確認できません。長文での追加プレミアムは、Claude 4.6以降のモデルには無いと公式に明示されています。

そして、入ることと使い切れることは別です。autocompactの発動、/contextの読み方、長文中央での参照精度という3点は、1Mを常用し始めてから当たる問題になります。既存の分割処理を畳むかどうかは、まず1本の実タスクで完了率と所要時間を比べてから決める形が、無理のない入り方になります。モデルの選び方そのものはClaudeとは — モデルの違いと料金・使い方にもまとめてあります。