AI活用レビュー

Claude Code /clearの使い方｜200k超えで手抜きするAIの対処法

この記事の結論（3行）

  • Claude Codeは箱が1Mでも、200kを超えたあたりから私の肌感では応答が怪しくなる
  • /compactのお任せは地獄。/clearで能動的に捨てて、進捗は別メモに私が書いて貼り直す運用が安定
  • 私はMax 20x $200/月で回してる。1M Opus自動昇格と高い使用上限が前提だと/clear運用の効きが更に上がる

Claude Codeを毎日使ってると、
「あれ、
こいつさっきまでできてたことできなくなってる」って瞬間、
ありませんか。
私は週3回くらいある。
指示したはずの確認プロセスが抜ける、
触るなと言ったファイルに手を出す、
さっき決めた仕様を忘れる。
これ正直しんどい。

原因のかなりの部分が「コンテキスト肥大」にあると気付いてから、
私は運用をガラッと変えました。
具体的には、
/clearで能動的に履歴を捨てて、
進捗は別メモに私が書き出して貼り直すという方式です。
Opus 4.7が出た2026年4月16日以降も、
私はこの運用を続けてる。
箱が大きくなっても、
劣化は別の話だからです。

本記事はClaude Codeを毎日メインで回してる3ヶ月分の運用ログ。
公式仕様と私の体感は分けて書きます。
プラン選びに迷ってる人も、
この運用を覚えてから額面を決めた方がコスパの判断を間違えません。

そもそも何が起きてる？コンテキスト肥大でClaude Codeが馬鹿になるメカニズム

Anthropic公式ブログ（Session Management and 1M Context）には、
こう書いてあります。

Context rot is the observation that model performance degrades as context grows because attention gets spread across more tokens.

要するに、
箱が大きくても注意が薄まる。
1Mまで詰め込めるから賢さが1M分維持されるわけではない、
という話です。
個人的にはこの率直さは好感が持てます。
Anthropic自身が「箱は大きい、
でも劣化はする」と明記してる。

公式の但し書きでは「300K〜400Kあたりから性能が落ちる」という表現が出てきます。
ただ私の肌感だと200kを超えたあたりから怪しい。
誰かの投稿で「200k以下のほうが賢い」という指摘を見て、
私の運用ログを振り返ったら、
確かに200k越えの回で事故が増えてました。

具体的な症状はこんな感じ。

  • 指示した確認プロセスが途中から省略される
  • 「このファイルは触らないで」が忘れられる
  • デバッグ後に話題を切り替えた瞬間、前半の結論まで吹き飛ぶ
  • 5本続けて記事執筆をさせると、5本目で異様に作業が速くなる（＝手を抜いてる）

特に5本目の件は、
私が実地で遭遇したやつです。
試しにClaudeに「手抜いただろ」って聞いたら、
「確認を省きました」「一部の検証をはしょりました」と本人が認めた。
正直笑えない。
これがコンテキスト劣化の実態です。

/clearと/compactの違いは？私が/clear運用に倒してる理由

Claude Codeには履歴を軽くするコマンドが2系統あります。
/compactと/clear。
両方とも「軽くする」系ですが、
思想が真逆です。
ここを混同すると事故ります。

コマンド 動作 向いてる場面 リスク
/compact 会話全体をClaudeが要約して、その要約の上に続きを積む。70,000トークンが約4,000に圧縮された実例あり 同じ話題を延々続けたいとき。文脈を丸ごと捨てたくないとき 要約の粒度が合わないと重要な決定が抜ける。長いデバッグ後の切替で特に外れやすい
/clear 履歴を全削除して新セッションを開く。要約は作らない。/reset、/newは同じ動作のエイリアス 話題が切り替わるとき。200k超えたとき。新しいタスクを始めるとき 人間が進捗を別途メモしないと文脈が完全に消える

公式ブログには「With /clear you write down what matters...and start clean.」と書いてある。
これ直訳すると「/clearは人間が何が重要かを書き出して、
綺麗な状態で始める」ですね。
私はこの思想に倒してます。

理由は単純で、
/compactは要約を作るタイミングで既にClaudeが劣化してるからです。
公式ブログの別の箇所にこうあります。

Due to context rot, the model is at its least intelligent point when compacting.

要約させる時点で頭が一番鈍ってる。
その要約に乗っかって続けたら、
そりゃ劣化は加速する。
私は過去にこれで何度も事故りました。
「進捗を保存してから次のセッションにいく」みたいな運用をしてても、
コンパクトが途中で動くと、
保存してた内容まで忘れてる。
あれは地獄。

なので今は、
200k超えたら数字関係なく/clear、
話題が変わったら50kでも/clear、
という2本立てです。
進捗は私が手で書いたmdファイルを新セッションに貼る。
面倒ですが、
ミスの量が桁で減りました。

200k vs 1M context、結局どっち使うべき？

2026年4月時点で、
1M context GAの公式発表によると、
1M contextが有効なのはOpus 4.7、
Opus 4.6、
Sonnet 4.6。
Max / Team / EnterpriseプランではOpusが自動で1Mにアップグレードされます。
Pro $20/月は200kのまま。

「じゃあ1Mのほうが賢いんでしょ」と思いがちですが、
私はここで一度立ち止まるべきだと思ってます。
正直、
1Mが効くシーンは限定的です。

私の使い分けはこう。

  • 200kで十分な作業：単発の記事執筆、1ファイルのバグ修正、API叩くだけのスクリプト。むしろ1Mに広げると注意が薄まって劣化する
  • 1Mが効く作業：巨大なコードベースの解析、複数ファイル横断のリファクタ、長い仕様書を丸ごと読ませたい場合

ここが肝。
箱を大きくすれば賢くなるわけじゃない。
むしろ箱を満杯にしようとすると劣化が早まる。
SitePointの解説では「Target 60% context utilization, well before the ~80% threshold where auto-compact activates.」（60%で手動介入、
80%閾値に触れる前に動け）と明記されてました。
これは私の体感とも合う。

つまり1M contextは「保険」として見ておくのが健全。
毎回1Mを埋める前提で使うと、
むしろ馬鹿になります。

auto-compactは使えるのか（結論：私は切りたい）

Claude Codeには、
コンテキスト使用率が約83.5%に達すると自動でコンパクトが走る仕組みがあります（ClaudeLogの解説、
200K contextなら約167Kトークンで発火）。
環境変数CLAUDE_AUTOCOMPACT_PCT_OVERRIDEで閾値を変えることもできます。

親切な機能に見えます。でも私は信用してません。理由を並べます。

まず公式自身が弱点を認めてる。公式ブログから引用します。

Bad compacts can happen when the model can't predict the direction your work is going.

「次にどっち向かうか予測しにくい場面ではコンパクトが外れる」と言ってる。
長いデバッグ後に「じゃあ次は別の話」って切り替える瞬間が、
まさにこれ。
私は何度もやられました。

GitHubのIssueもかなり積み上がってます。
Issue #10948は「Auto-compact triggers mid-task causing context loss and hallucinations」というタイトル。
コミュニティではこういう声も見ました。

After compaction, Claude Code is definitely dumber, doesn't know which files it was looking at, and will make mistakes that were specifically corrected earlier in the session.

出典はclaudefa.stの解説記事。
auto-compact後は「どのファイル見てたかすら忘れる」「セッション初期に修正したミスをまたやる」。
私も同じ経験があるので、
これは誇張じゃないです。

あと、
2026年初頭にauto-compactの予備バッファが45K → 33Kトークン（16.5%）に削減された、
という報告もあります。
バッファが減った分、
発火してから実際に要約が完了するまでの余裕が削られた形。
個人的には改悪寄りの変更だと感じてます。

なのでauto-compactは、
発火する前に/clearで先回りするのが私の運用。
/contextコマンドで使用量を表示して（このコマンドの存在は複数のコミュニティ記事で確認できますが、
公式ドキュメントの直接記述は私が確認した範囲では取れてないので、
厳密な仕様は要確認）、
200kに近づいたら即/clear、
話題が変わっても即/clear。

ちなみにClaude Code v2.1.100以降、
Efficienistの記事とGitHub Issue #46917で「リクエストに約20,000トークンの不可視膨張がある」という報告が出てます。
/contextには出てこない不可視分とのこと。
これは現在進行形の報告で、
真相は要確認ですが、
そういう報告があるということだけは頭に入れておいたほうがいいと思ってます。

他ツール（Cursor / Windsurf / Copilot / Aider）との違いは哲学の差

Claude Codeは「/clearで人間が能動的に捨てる」哲学のツール。
他ツールは真逆の思想のものが多いです。

ツール コンテキスト管理の思想 最大ウィンドウ
Claude Code 大きく使って、人間が/clearで捨てる 1M（Opus 4.7 / 4.6 / Sonnet 4.6）
Cursor @codebase / @fileで人間が明示的にマウント 最大1M（モデル依存）
Windsurf グラフ依存モデルでAIが自動選択 最大1M
GitHub Copilot @workspaceで検索、単一ファイル前提 64K（1/15）
Aider repo-map（PageRank + tree-sitter）でトークン予算内に圧縮 デフォルトmap-tokens 1K

Aiderは公式docsを読む限り「最初から小さく保つ」思想で、
Claude Codeと真逆。
Windsurfは「AIが自動で読むファイルを決める」ので、
人間の介入が少ない。
Cursorは中間で、
人間が@codebaseタグで指定する。

正直どれが正解という話じゃないです。
私はClaude Codeの「大きく使って人間が捨てる」哲学が、
今の私の作業には合ってる。
記事執筆・バグ修正・設計相談を1日に5〜10セッション回すので、
セッション単位で区切って捨てる運用がフィットする。

逆に「AIが全部判断して読んでほしい」人にはWindsurf、
「最初から最小限で動かしたい」人にはAiderが向くと思います。
ここは哲学の相性。

料金とコスパ：私はMax 20xで回してる。Proから乗り換える判断基準はどこか

公式の料金ページ（2026年4月時点）によると、こんな構成です。

プラン 価格（月払） 特徴
Pro $20/月 Claude Code含む。Opusは200k contextのみ
Max 5x $100/月〜 Proの5倍の使用上限。Opusが1M contextに自動昇格
Max 20x $200/月〜 Proの20倍。重めのエージェント運用者向け
Team 標準 $25/seat/月 Claude Code含む。チーム運用

私はMax 20x $200/月で回してます。
理由は2つ。
複数プロジェクトを並行で走らせるのでProの使用上限ではすぐ止まる、
そしてOpus 4.7が自動で1M contextにアップグレードされる恩恵が効く。
ただし/clearで200kに戻す運用は崩さず、
Maxの箱はあくまで保険です。

Proからの乗り換えは、以下に該当し始めたら検討タイミング。

  • 1日に長時間Claude Codeを回す（目安：平日5時間以上）
  • 並行プロジェクトが3つ以上あって、/clearしても使用上限で止まる
  • 巨大モノレポで1M contextが実際に効く作業が増えてきた

Max 5xと20xの差は、
Pro比の5倍か20倍の使用上限。
個人の記事執筆＋コーディング中心ならMax 5xでも足りる、
というのが私の見立てです。
私はエージェント並行運用＋記事量産で20x側に寄せてる。

API直叩きはまた別の話で、
Opus 4.7は入力$5 / 1M tokens、
出力$25 / 1M tokens（4.6と同額）。
1M入力をフルで使うとクエリ1発で$5。
これは税金感がやばい。
個人レベルでAPI直叩きで1M使うならサブスクのほうが安い、
というのが私の結論です。

ちなみにOpus 4.7（2026-04-16リリース）の発表では、
Anthropic公式が93タスクのコーディングベンチで4.6比+13%と出してます。
デフォルトのeffort levelも全プランでxhighに引き上げられた。
体感でも、
/clear運用と合わせるとミスの量が更に減った印象です。
但しリリース翌日時点の感想なので、
長期評価はまだ要確認。

誰が向いてるか？黒い画面で勝手に苦手意識もつのは損です

「ターミナル＝エンジニア専用」みたいな前提で最初から避けてる人、
多いと思うんですが、
正直それは損してます。
やってることはAIとの会話で、
黒い画面かどうかはただの見た目の話。
たぶん10分で慣れます。

私自身、
非エンジニアから始めました。
違和感らしい違和感は「右クリックでペーストされる」「Ctrl+Cで中断される」みたいな仕様差だけ。
本質的な使い方は、
ChatGPTに話しかけるのとほぼ変わりません。

AIを触るなら、
今いちばん学びがあって使いやすいのはClaude Codeだと思ってます。
理由は3つ。

  • 機能追加のペースが毎週・毎日レベルで速く、触るたびに何かが増えてる。hooks／skills／agentsなどを組み合わせて自分好みにカスタマイズできる
  • 公式ドキュメントと活用事例記事が分厚いから、「これやりたい」と思ったことの実現方法がだいたい見つかる
  • 現時点で活用事例がいちばん多いAI。真似できる運用が山ほど転がってる

強いて「最初に戸惑う」ポイントを挙げるなら、
/clearを押す勇気と、
進捗を別メモに書き出す手間。
どちらも数日で慣れます。
/clearに至っては、
慣れた後のほうが押さないと気持ち悪い。

「黒い画面に抵抗がある」を理由にClaude Codeを外すのは、
AI活用のいちばん美味しいところを食べ損ねてる状態です。
10分だけ試す価値はあります。

FAQ

Q1. /clearと/compact、どう使い分ければいい？

話題を続けたいなら/compact、
話題が切り替わるなら/clear。
ただし私は/compactの要約精度を信用してないので、
基本は/clearに倒してます。
/compactは「長いデバッグを終えて、
まだ同じデバッグ話題を続ける」みたいな限定場面だけ。

Q2. 200kと1M、毎日の作業ではどっちを選ぶべき？

単発の作業なら200kで十分。
むしろ1Mに広げて埋めようとすると、
context rotで劣化が早まります。
1Mは「巨大コードベース解析」「長文仕様書の一括読込」のような、
本当に必要なときの保険として使うのがいいです。

Q3. auto-compactを無効化することはできる？

完全無効化の公式手段は私が確認した範囲では見つかってません。
ただし環境変数CLAUDE_AUTOCOMPACT_PCT_OVERRIDEで閾値を上げる（例：95%）と、
事実上ほぼ発火しない運用は作れます。
私はauto-compactに頼らず、
その前に/clearするほうを選んでます。

Q4. Pro $20で足りる？Maxにすべき？

/clear運用の基本は Pro $20 でも習得できるので、
まずはProで始めるのがおすすめです。
Maxに上げる判断は「Pro上限で止まる頻度が週何回あるか」で決めればいい。
私はエージェント並行＋記事量産でMax 20x $200に倒してます。
個人の記事執筆＋コーディング中心ならMax 5x $100で足りる、
というのが乗り換え経験からの見立てです。

Q5. Claude Code v2.1.100の「不可視20Kトークン膨張」って何？

GitHub Issue #46917とEfficienistの報告で「v2.1.100以降、
毎リクエストに約20,000トークンの不可視分が乗ってる」とされている件です。
/contextには表示されないため、
使用上限を知らぬ間に削られている可能性がある、
という話。
現時点では報告ベースで、
Anthropic公式の確定回答は私が確認した範囲では出ていません。
要確認。

関連リンク

※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。

-AI活用レビュー
-

← 戻る