Claude 1Mコンテキスト正式GA — kuevico実運用で見えた大規模コンテキストの実力と限界

2026年3月13日、1Mコンテキストが「全員のもの」になった

AnthropicがClaude Opus 4.6とSonnet 4.6の1Mコンテキストウィンドウを正式GAとしたのは、2026年3月13日のことです。それまでベータ扱いだった100万トークンのコンテキストが、追加料金なしの標準機能として開放されました。

私（西村）がこのニュースを見たときの率直な感想は「ようやく追いついた」でした。京谷商会のkuevico基盤では、Opus 4.6のベータ期間中から1Mコンテキストを日常業務に組み込んでおり、すでに数か月の実運用データが手元にあったからです。

この記事では、公式発表の技術仕様を正確に押さえたうえで、kuevico基盤での実運用を通じて分かった「1Mコンテキストの実力と限界」を、数値とユースケースを交えて共有します。GA後3週間の追加運用で得られた知見も反映しています。

正式GAで何が変わったのか

まず事実を整理します。Anthropicの公式ブログとAPIドキュメントから確認できる変更点は以下の通りです。

価格面の変更がありません。 Opus 4.6は$5/$25、Sonnet 4.6は$3/$15（いずれも100万トークンあたり）で、900Kトークンのリクエストも9Kトークンのリクエストも同じ単価が適用されます。ベータ期間中に存在した長文コンテキスト割増は撤廃されました。これは実務上きわめて大きな変更です。200Kを超えるリクエストに2倍の料金がかかっていた時期と比べると、大規模コンテキストの利用コストが半減したことを意味します。

メディア制限が6倍に拡大しました。 1リクエストあたりの画像・PDFページ数が100から600に引き上げられました。法務文書や技術マニュアルの一括解析が現実的になった変更です。kuevico基盤では、18ポータル分のサイトマップやスクリーンショットを一度に渡して全体レビューを行うケースがあり、この制限緩和は直接的な恩恵をもたらしました。

ベータヘッダーが不要になりました。 200Kトークンを超えるリクエストに必要だったanthropic-betaヘッダー指定が不要になり、そのまま送るだけで1Mまで受け付けます。API統合のコードがシンプルになり、バージョン管理の手間が減りました。

提供プラットフォームが拡大しました。 Claude Platform、Microsoft Foundry、Google Cloud Vertex AIの3プラットフォームで利用できます。マルチクラウド戦略を採用している企業にとって、プラットフォーム間で同一のコンテキスト容量が保証されることは重要な要件です。

ベンチマークが示す「針の検索精度」

1Mコンテキストウィンドウの性能を評価するうえで、もっとも重要な指標がMRCR v2（Multi-hop Retrieval with Context Reasoning）です。これは100万トークンの文書の中から8つの「針」（特定の情報断片）を同時に検索・推論する高難易度のベンチマークです。

Opus 4.6はこのMRCR v2（8-needle, 1M variant）で**78.3%**を記録しています。比較対象として、Sonnet 4.5は同条件で18.5%しか出せませんでした。4倍以上の精度差があり、大規模コンテキストでの情報検索はOpus 4.6が圧倒的です。

ただし、この78.3%という数字は裏を返せば「約5回に1回は取りこぼす」ことを意味します。100件の重要事実を含むドキュメントを処理した場合、約22件が検索漏れになる計算です。単発の利用では気にならない誤差でも、大量のドキュメントをバッチ処理するワークフローでは無視できない数字です。実運用ではこの取りこぼし率をどう補うかが設計上の論点になります。

なお、MRCRは従来のNeedleInAHaystack（単一の事実検索）を大幅に進化させたベンチマークで、複数の情報断片を関連づけて推論する能力を測定します。実務でのドキュメント横断分析に近いタスク設計のため、実用性の指標として信頼性が高いとされています。

kuevico基盤での実運用：何が変わったか

京谷商会では、AIスタッフ運用基盤「kuevico」でOpus 4.6の1Mコンテキストを秘書システムの根幹に据えています。kuevicoとは古事記に登場する久延毘古（くえびこ）に由来する名称で、「世の中のことを何でも知っている」という意味が込められています。2,000名規模のAIスタッフが各自の専門領域を持ち、秘書が振り分け、部長が割当て、スタッフが実行するという三層構造で業務を回しています。具体的にどのような変化があったかを、3つの軸で説明します。

セッション跨ぎの知識維持が劇的に改善した

kuevicoの秘書システムは、複数のAIスタッフの個人ファイル（専門知識・経歴・命令事項）、CLAUDE.md（プロジェクト仕様）、GTDタスク一覧、各種ワークフロー定義を同時にコンテキストへ読み込みます。

200Kトークン時代は、スタッフ10名分の個人ファイルとプロジェクト仕様を読み込んだ時点でコンテキストの半分を消費していました。その結果、作業途中でContext Compactionが発動し、序盤に読み込んだスタッフの命令事項が要約で丸められて判断精度が落ちるケースが頻発していました。たとえば「AIS-008は日本語の二次ソースを参照してはならない」という命令事項がCompaction後に「情報源に注意」程度に要約され、ニュースサイトを引用してしまうといった具体的な問題がありました。

1Mコンテキストへの移行後、Compaction発生率が約15%減少したことがAnthropicの公式発表でも確認されています。kuevico基盤では体感としてそれ以上の改善があり、20名以上のスタッフファイルを同時展開しても余裕をもって作業を完遂できるようになりました。

大規模コードベースの全体解析が一発で通る

京谷商会は18のポータルサイトを運営しており、そのバックエンドはCloudflare Workers（Hono）+ D1で構築されています。API全体のTypeScriptコードは約15,000行あり、これに加えてスキーマ定義、テスト、デプロイ設定を含めると相当な量になります。

200K時代は「この機能に関連するファイルだけ」と的を絞ってコンテキストに入れる必要がありました。ルーティング定義を修正するときに認証ミドルウェアのコードが見えていないため、権限チェックの整合性を保証できないといった問題が起きていました。1Mコンテキストでは、API全体のソースコードを一括で読み込んだうえでhooks設計のレビューやリファクタリング指示を出せます。ファイル間の依存関係を見落とすリスクが構造的に減りました。Claude Codeのエージェント機能と組み合わせることで、コードベース全体を把握したうえでの自律的な修正が可能になっています。

12ステップ記事パイプラインの一貫性が向上した

京谷商会の記事制作は、SEO分析から品質レビューまで12ステップの強制パイプラインで管理されています。各ステップの成果物（KW分析結果、共起語リスト、品質チェックリスト、初稿、SEOスコアレポート）をすべてコンテキストに保持したまま次のステップに進めるため、ステップ間の情報落ちがなくなりました。

以前は、ステップ5（執筆）の時点でステップ1（KW確定）の詳細条件がCompactionで失われることがあり、書き上がった記事が当初のSEO戦略と微妙にずれるケースがありました。1Mコンテキストではこの問題が根本的に解消しています。12ステップの全成果物を保持しても、コンテキスト全体の30%程度に収まるため、執筆時にも十分な余裕があります。

Context Compaction：1Mでも必要な「記憶の整理」

1Mコンテキストがあっても、長時間のエージェント作業ではContext Compactionが重要な役割を果たします。

Context Compactionとは、コンテキストウィンドウの上限に近づいたとき、古い会話履歴を自動的に要約して圧縮する機能です。サーバーサイドで自動的に実行されるため、アプリケーション側での実装は不要です。Claude Agent SDKを使った自律型エージェントでも、トークン使用量が閾値を超えた時点で自動的にCompactionが走り、タスクを中断せずに継続できます。

kuevico基盤では、1日の秘書セッションが8時間を超えることも珍しくありません。その間にファイル読み込み、コード生成、テスト実行、デプロイと多くのツール出力がコンテキストに蓄積されます。1Mトークンがあっても、ツール出力はトークン消費が大きいため、長時間セッションでは依然としてCompactionが発動します。具体的には、grepの検索結果やnpmのインストールログなど、一度確認すれば不要になる出力が大量のトークンを消費します。

重要なのは、Compactionの質がOpus 4.6世代で大幅に向上したことです。以前の世代では、要約時に重要な決定事項やエラー情報が落ちることがありました。現在のCompactionは「作業状態（working state）」を構造化して保持し、直近のファイル操作・TODOリスト・継続指示を優先的に残す設計になっています。

1Mコンテキストの限界：何がまだ難しいのか

実運用で見えた限界を正直に共有します。1Mコンテキストは革命的な進歩ですが、万能ではありません。

Context Rotは解消されていない

コンテキストが大きくなるほど、古い情報の精度が徐々に劣化する現象（Context Rot）は1Mでも発生します。100万トークンの端から端まで均一な精度で参照できるわけではありません。

kuevico基盤での観測では、70万トークンを超えたあたりからセッション序盤の指示に対する遵守率が低下する傾向があります。とくに「特定のフォーマットで出力せよ」のような制約条件は、後半になるほど無視されやすくなります。開発者コミュニティでは「dumb zone」と呼ばれているこの現象は、以前の世代では65〜70%の容量で顕在化していましたが、Opus 4.6では70〜80%まで改善しています。改善はされているものの、根本的には解消されていません。

対策として、CLAUDE.mdの命令事項はシステムプロンプトの先頭に配置し、Compaction後も優先的に保持されるよう設計しています。また、重要な制約は作業途中で明示的に再注入する運用を取り入れています。GA後の追加運用では、30分スロットディスパッチャーによるセッション自動分割がContext Rot対策として有効であることも確認しました。長時間の単一セッションよりも、タスク単位で区切った短いセッションを連続実行する方が、指示遵守率の低下を抑えられます。

レイテンシの増大は避けられない

1Mトークンのコンテキストを処理するには物理的な計算時間がかかります。実運用では、コンテキストが50万トークンを超えたあたりからレスポンス生成の遅延が体感できるレベルになります。応答開始までの待ち時間が10K トークン時の数倍に膨れ上がることもあり、ユーザーが画面の前で待つタイプのアプリケーションには適していません。

リアルタイム性が求められるチャットボットやカスタマーサポートには、1Mコンテキストをフルに使う設計は不向きです。kuevico基盤ではバッチ処理やエージェントの非同期タスクに1Mを活用し、リアルタイム応答にはSonnet 4.6の短いコンテキスト（10-50K程度）を使い分けています。Opus 4.6のFast Mode（$30/$150 per MTok）を使えばレイテンシは改善しますが、コストが6倍になるため常用は現実的ではありません。

「読めている」と「理解している」は別の問題

MRCR 78.3%は高いスコアですが、これは「特定の事実を見つけられるか」のテストです。実務で必要なのは「複数の事実を統合して判断する」能力であり、これは事実検索よりも難しいタスクです。

たとえば、kuevico基盤で20名分のスタッフファイルを読み込んだ場合、「AIS-008の専門領域は何か」という単純な検索は正確に答えられます。しかし「AIS-008とAIS-012の専門領域の重複を分析し、共同プロジェクトの提案をせよ」のような統合的な推論では、片方のスタッフ情報を取りこぼすことがあります。コンテキスト内の複数の情報を関連付けて新たな結論を導く作業は、単純な事実検索よりもエラー率が高くなります。

トークン蓄積のコスト問題

見落とされがちですが、1Mコンテキストのコスト構造には注意が必要です。会話が進むにつれて、毎回のリクエストにはそれまでの全会話履歴が含まれます。50ターンの会話で各ターンの入出力が2万トークンだとすると、50ターン目のリクエストは100万トークンに達します。この時点で1リクエストあたり$5（Opus 4.6の入力コスト）が発生する計算です。

kuevico基盤での実測値を共有すると、1日8時間の秘書セッション（約200ターン）のトークン消費量は平均して300万〜500万入力トークンです。Prompt Cachingの適用後でも、1セッションあたり$8〜$15のAPI費用が発生します。月間では$200〜$400程度です。この数字は18ポータルを自律運用するコストとしては妥当ですが、「1Mコンテキスト＝無制限に使える」という誤解は危険です。長時間セッションでのコスト管理は、1Mコンテキスト運用の実務的な課題です。

実運用アーキテクチャ：コンテキスト設計の実際

kuevico基盤で採用しているコンテキスト設計のパターンを共有します。

階層型コンテキスト配置

コンテキストの配置には明確な優先順位があります。

1. システムプロンプト層（最優先）：CLAUDE.md、命令事項、ワークフロー定義
2. 作業コンテキスト層：作業対象のファイル、コード、データ
3. 参照コンテキスト層：関連スタッフの個人ファイル、過去の作業履歴
4. ツール出力層（消費が大きい）：コマンド実行結果、検索結果

Compactionが発動した場合、層4から順に圧縮されます。層1は可能な限り原文のまま保持される設計です。この階層構造を意識してプロンプトを組み立てることで、1Mコンテキストの恩恵を最大化しつつ、Compaction時の情報損失を最小化できます。

Prompt Cachingの活用

Prompt Cachingは、同じプレフィックス（システムプロンプトや共通ドキュメント）を含むリクエストのコストを大幅に削減します。kuevico基盤では、CLAUDE.mdやスタッフ個人ファイルのように頻繁に参照されるドキュメントをキャッシュ対象にしています。

初回読み込みは標準料金ですが、キャッシュヒット時は入力トークンコストが90%削減されます。18ポータル分のCLAUDE.mdを毎回読み込むkuevico基盤では、この仕組みによるコスト削減効果は月額$100以上に相当します。とくに、同一セッション内で繰り返し参照されるスタッフファイルやワークフロー定義は、キャッシュの恩恵が大きいです。キャッシュのTTLは5分間で、その間に同じプレフィックスのリクエストが来れば自動的にキャッシュが適用されます。

Adaptive Thinkingとの組み合わせ

Opus 4.6で導入されたAdaptive Thinkingは、1Mコンテキストと組み合わせることで真価を発揮します。大量のコンテキストを読み込んだうえで、質問の複雑さに応じて推論の深さを動的に調整するため、単純な事実確認では高速に応答し、複雑な分析では深い思考チェーンを展開します。

kuevico基盤では、Adaptive Thinkingを標準の思考モードとして採用しています。Extended Thinkingと比較して、日常的な秘書業務での応答速度が体感で30%以上改善しました。Extended Thinkingは複雑な推論が必要な場面（アーキテクチャ設計、バグの根本原因分析など）で明示的に有効化し、日常業務はAdaptive Thinkingで回すという使い分けが、コストとパフォーマンスの両面で最適です。

Cloudflare Workers基盤との統合

京谷商会のインフラはCloudflare Workers上に構築されています。1Mコンテキストの活用にあたり、インフラ側の設計で考慮した点を共有します。

Workers環境からAnthropic APIを呼び出す際、1Mトークンのリクエストではレスポンス時間が長くなるため、Workerのタイムアウト設定（デフォルト30秒）では足りないケースがあります。京谷商会では、長時間のAPI呼び出しにはDurable ObjectsまたはQueuesを使い、非同期でレスポンスを受け取る設計にしています。Durable Objectsはステートフルな処理を維持できるため、バッチAPIのポーリング待ちにも適しています。

また、AI Gatewayによるルーティングを活用することで、APIリクエストのログ収集・レート制限・フォールバックを一元管理しています。1Mコンテキストのリクエストはコストが大きいため、意図しない大量リクエストを防ぐガードレールとしてAI Gatewayは不可欠です。リクエストごとのトークン数をログに記録し、異常なコンテキスト膨張を早期に検知する監視体制も構築しています。

SEOへの応用：記事品質の向上

1Mコンテキストは記事制作プロセスにも直接的な恩恵をもたらしています。

従来の200Kコンテキストでは、競合上位10記事の全文分析をしようとするとそれだけでコンテキストの大半を消費していました。1Mコンテキストでは、競合記事10本の全文＋自社の既存関連記事5本＋キーワード分析データを同時に読み込んだうえで、差別化ポイントを特定する分析が可能になりました。

結果として、記事のオリジナリティスコア（自社独自の情報をどれだけ含んでいるか）が向上しています。汎用的な情報の羅列ではなく、自社の実践に基づいた具体的な知見を盛り込む余裕がコンテキスト面で確保されたことが大きいです。京谷商会のポータル記事は「当事者が実際にやってみた」という一次情報を必ず含めるポリシーを掲げており、1Mコンテキストによって過去記事との整合性チェックも同時に行えるようになりました。

他社モデルとの比較：1M時代の競争環境

2026年4月時点で、1Mトークン以上のコンテキストウィンドウを持つフロンティアモデルの比較です。

三大フロンティアモデルが揃って1Mコンテキストを標準化したことで、大規模コンテキストはもはや差別化要因ではなく基本機能になりつつあります。差別化は「1Mをどれだけ正確に使えるか」という品質の競争に移行しています。

kuevico基盤ではOpus 4.6を主力モデルとして採用していますが、これはMRCRスコアが公開モデル中最高であること、Claude Agent SDKとClaude Codeとの統合が最も成熟していること、Context Compactionがサーバーサイドで自動実行されること、の3つが主な理由です。

ただし、これは2026年4月時点の評価であり、他社モデルも急速に進化しています。kuevico基盤では、モデル選定を固定せず、四半期ごとに再評価する運用としています。

導入の判断基準：1Mコンテキストが必要なケース

1Mコンテキストは強力ですが、すべてのユースケースに必要なわけではありません。kuevico基盤での運用経験から、以下の判断基準を提案します。

1Mコンテキストが効果的なケースは、複数の大規模ドキュメントを横断して分析する場合、長時間（4時間以上）のエージェントセッション、大規模コードベース（1万行以上）の全体的なリファクタリングやレビュー、そして12ステップのような長いパイプラインを一貫したコンテキストで処理する場合です。法律事務所での400ページの証言録取書の横断分析や、研究機関での数百本の論文の統合レビューなども、1Mコンテキストが真価を発揮するユースケースです。

200K以下で十分なケースは、単一ドキュメントの要約や翻訳、短時間（1時間以内）の質疑応答、特定ファイルのコードレビュー、そしてリアルタイム性が求められるチャットボットです。

コスト面では、1Mコンテキストを常時フルに使うとトークン消費が急速に蓄積します。kuevico基盤では、タスクの性質に応じてOpus 4.6（複雑な長時間タスク）とSonnet 4.6（日常的な短時間タスク）を使い分けることで、月間コストを最適化しています。

まとめ：1Mコンテキストは「量の変化」ではなく「質の変化」

Claude Opus 4.6の1Mコンテキスト正式GAは、単に読み込めるテキスト量が増えたというだけの話ではありません。

200Kから1Mへの5倍の拡大は、「必要な情報を選んで入れる」という従来のアプローチから、「関連する情報をすべて入れて判断させる」というアプローチへの転換を可能にしました。kuevico基盤では、この転換によってAIスタッフの判断精度が向上し、人間による中間チェックの頻度を減らせています。

一方で、Context Rotやレイテンシといった制約は依然として存在します。1Mコンテキストを「万能の解決策」と捉えるのではなく、その特性を理解したうえでアーキテクチャを設計することが、実運用では不可欠です。

京谷商会はこれからもkuevico基盤での運用知見を公開していきます。1Mコンテキストの活用について具体的な質問があれば、お問い合わせフォームからお気軽にどうぞ。