Claude Code 1Mコンテキストの落とし穴｜セッション管理の実践法

Claude Codeの1Mトークンコンテキストが2026年3月に正式に一般提供されてから、X上では「自律実行が長く続けられる」と歓迎する声と「コンテキストを詰め込みすぎて精度が落ちた」という嘆きが同時に飛び交っています。1Mコンテキスト時代のClaude Codeを実務で活かすには、セッションをどう区切り、どんな情報を残すかという「セッション管理」の設計が決定的に効きます。本記事では、私自身がClaude CodeをMax 20xプランで業務全般に使い込んできた中で見えてきた、1Mコンテキスト時代の実践的なセッション管理術を整理します。

Claude Code 1Mコンテキストとは何か

Anthropicは2026年3月13日に、Claude Opus 4.6 / Sonnet 4.6の1Mトークンコンテキストウィンドウを一般提供化しました。Claude CodeのMax・Team・Enterpriseプランでは、Opus 4.6セッションが自動的に1Mコンテキストを使えるようになっています（出典: Anthropic公式ドキュメント）。

1Mトークンは日本語にして数十万文字相当のボリュームで、コードベースまるごと・長い設計ドキュメント・大量の議事録などを一度に読ませながら作業させられる規模です。Anthropicによれば、1Mコンテキスト導入後はコンパクション（履歴圧縮）の発生回数が約15%減ったとされています。

「両刃の剣」と呼ばれる理由

X上で「double-edged sword（両刃の剣）」と表現されるのは、文脈を多く持たせるほど自律実行が長続きする一方、コンテキスト量が増えるほどモデルの精度がじわじわ低下するという現象が無視できないからです。私自身も、長時間のセッションで「読んだはずのファイルを参照していない」「ガイドラインに沿わない出力が増える」場面を何度も経験しています。

これは私だけの感覚ではなく、複数のリサーチで「コンテキストが大きいほどモデルは編集優先になり、ファイルを読まずに修正に飛びつく傾向が強まる」と指摘されています。1Mコンテキストは武器であると同時に、運用次第で諸刃の剣になります。

1Mコンテキスト時代に多発する3つの落とし穴

私が実務で繰り返し遭遇している失敗パターンは、おおむね3つに集約されます。

1. セッションを切らずに走らせ続ける

Claude Codeは長時間動けるようになりましたが、私の体感では同一セッションで作業を続けると、約3時間を超えたあたりから明らかに出力品質が落ちます。LP改修＋SEO記事14本を1セッション内で並列処理した際は、大量のテキスト読み込みとリライトが重なって5時間制限に一瞬で到達したこともあります。

1Mコンテキストがあるからといって「走らせっぱなし」にすると、トークン消費が膨らむうえ、後半の出力ほど精度がブレるという二重コストを支払うことになります。

2. 何でも読み込ませてコンテキストを膨張させる

「コンテキストが大きく持てる＝何でも入れていい」ではありません。実際には、関係の薄いファイルやログまで読ませると、モデルが「いま注目すべきこと」を見失います。私の運用では、Claude Codeに渡す情報は意図的に絞り込み、関係のないMCPはオフにする方針を徹底しています。

3. 思考予算（thinking budget）の設定を放置する

2026年3〜4月にかけて、Claude Codeのデフォルト思考予算がmediumに変更され、複雑なタスクの品質低下が広く報告されました。GitHubのissueでは数千セッション規模の分析で「思考が浅くなるほどファイルを読まずに編集に走る」という傾向が裏付けられています。私も同時期、簡単なタスクでは差を感じないものの、複雑なコーディングや重めのコンテキスト下でガイドラインから外れるミスが増えたと感じていました。

settings.jsonに "effortLevel": "high" を入れてデフォルト化したところ、「また間違えてる」という場面はほぼ消えました。Max 20xプランでは、highに上げてもトークン消費が目に見えて増えた印象はありません。

1Mコンテキスト時代のセッション管理術5つ

これらの落とし穴を踏まえ、私が日々実践しているセッション管理の方針を5つにまとめます。

1. セッションは「コンテキストが溜まる前」に切る

セッション内のコンテキスト量で精度を上げるアプローチは本質的でないと考えており、私はあえて早めに新しいセッションを立ち上げるようにしています。1つのテーマが終わったら、次のテーマは新しいセッションへ。1Mあるからといって連続させない判断が、結果的にトータルの品質と速度を高めます。

2. 知見はセッション外のMarkdownに切り出す

セッション内に知見を抱え込ませず、プロジェクト単位のdataフォルダにMarkdownで蓄積していく方式に切り替えてから、セッション間のコンテキスト維持の問題はほぼ解消しました。Notion・Obsidianなど外部ツールと連携する案も検討しましたが、各ツールのフォーマットに縛られるためGitHubプライベートリポジトリ＋Markdownの自由形式が結果的に最も扱いやすいです。

• data/: 業務ドメインの一次情報（実績DB・ツール知見DB等）
• learnings/YYYY-MM.md: その月に出た発見の一時置き場
• rules/: 全セッションで自動ロードしたいガイドライン

この3層を分けておくと、新しいセッションでもコンテキストの再現性が一気に高まります。

3. 繰り返し業務はSkill化してコンテキストから外す

毎回のセッションに「同じ手順」を書くのはコンテキストの無駄遣いです。SEO記事執筆・QAチェック・MicroCMS投稿など繰り返し行う業務は、すべてSkill化して必要時のみロードするようにしています。実数値としては、SEO記事1本（約5,000文字）の執筆時間が30〜40分から4〜5分へ、サムネ・挿絵込みでも1時間が約5分まで短縮されました。

4. 単純作業は別セッション・別AIに逃がす

大量のテキストを読ませてのリライト・並列修正は、コンテキストを最も食う作業です。コンテキスト量が大きくなりそうな単純作業は、別セッションに分離するか、Codexなど別のAIに委譲しています。画像生成についてもGeminiに完全に逃がしてClaude Codeのトークンを温存しています。

5. ピーク時間帯を意識して使う

体感として、日本の深夜帯（＝米国のピーク時間帯）はトークン制限の減りが明らかに早いです。日本でのピーク時間ではなく、世界規模・特にアメリカのピーク時間を時差換算して意識すると、同じ作業でも快適に走らせられる時間帯が見えてきます。

長時間タスクを安定させる「ハーネス」の発想

1Mコンテキストの恩恵を最大化するには、モデル単体に頼るのではなく、ハーネス（制御の枠組み）でモデルの暴走を制限する設計が要になります。私は次の3レイヤーを軸に組み立てています。

• 明確なガイドライン: CLAUDE.mdとルールファイルで、判断基準と禁止事項を最小限の文量で示す
• 明確なルール設定: SkillsとCommandsで、繰り返し作業の手順そのものを切り出す
• 強制的な監視: Hooksで、公開・コミット直前にチェックリストと照合して品質を担保

レースカーで強大なエンジンを積んでいてもボディが追いつかなければ走らないのと同じで、Claude Codeも1Mコンテキストというエンジンに見合う「躯体」がないと能力を引き出せません。むしろ「制限することで本質的な価値を高める」方向に振った方が、実務ではアウトプットが安定します。

CLAUDE.mdは「肥大化させない」が正解

つい何でもCLAUDE.mdに書きたくなりますが、ある研究ではCLAUDE.mdの記載量が一定以上になると、コンテキスト量増加で逆に精度が下がる傾向が指摘されています。私も、CLAUDE.mdは目次的な役割に徹し、詳細はrules/やskills/に分散させる方針です。

明日からできるセッション管理チェックリスト

最後に、Claude Codeのセッション管理を見直すための実践チェックリストを置いておきます。

• 1セッションで複数テーマを混ぜていないか（混ざっていれば分割）
• 関係のないMCP・拡張・ファイルを読み込ませていないか
• effortLevel をhighに設定しているか（複雑タスクで体感差大）
• 繰り返し業務をSkill化できていないか（毎回同じプロンプトはSkill候補）
• 業務知見をdata/フォルダのMarkdownに切り出せているか
• 長時間タスクの後半で精度が落ちる前にセッションを切れているか

1Mコンテキストは、雑に使えばトークンを焼き、丁寧に設計すれば1人＋AIで複数人分の業務を回せる強力な武器になります。Claude Codeで成果が頭打ちになっていると感じている方は、まずセッション管理の前提から見直してみるのがおすすめです。

「セッションを長く保つ工夫」よりも「セッションを切る前提でナレッジを外に出す設計」のほうが、1Mコンテキスト時代の実務にはずっと相性が良い、というのが私の現時点での結論です。