新しい会話を始めたら、前の会話の内容は完全に消えてしまうのですか？
claude.aiのウェブ版やアプリを通じた通常の利用の場合、新しい会話は前の会話の内容を自動的に引き継がない——各会話はそれぞれ独立したコンテキストウィンドウを持つ。前の会話の要点を手動でコピー＆ペーストするか、特定の機能（Project内の共有背景資料など）を使って意図的に参照できるようにしない限り、新しい会話はまっさらな状態から始まる。
これは実は欠陥ではなく利点である。もし新しい会話が自動的にすべての過去の会話内容を蓄積していくとしたら、コンテキストウィンドウは無関係な古い情報ですぐにいっぱいになり、本記事で説明した容量の問題により早く直面することになる。新しく始めて、必要に応じて本当に関連性のある背景を手動で持ち込むことは、長期的な利用体験を管理する正常なやり方であり、システムの欠陥ではない。
アップロードした文書はコンテキストウィンドウの容量を使いますか？直接入力するのと何が違いますか？
はい。アップロードした文書の内容はトークンに変換され、その会話の容量にカウントされる。チャット欄に直接タイプしたり貼り付けたりするのと、「容量を使う」という点で本質的な違いはない——長いPDFやコードベースは、トークンに変換するとかなりの割合の容量を消費することがある。
実務上の違いは効率にある。長い文書の一部の章節だけが必要な場合、文書全体をアップロードしてClaudeに関連部分を探させるのは、本当に必要な段落だけを正確にコピー＆ペーストするより容量を無駄に使う。ウィンドウ容量を超える大規模な文書コレクションを頻繁に扱う必要があると気づいたら、そのような場合により適したやり方は、通常、文書の内容を外部に保存しておき、必要なときに関連する断片だけをClaudeに与えることであり、毎回一括ですべてのデータを一つの会話に詰め込むことではない。
Extended Thinking（高度な推論）機能は、コンテキストウィンドウの容量を追加で消費しますか？
はい。ClaudeがExtended Thinkingを使って内部推論を行うとき、生成される思考プロセス自体もトークンで計算され、同様にその会話のコンテキストウィンドウの容量を消費する。しかもこの部分は通常、出力トークンの課金範囲に含まれ、「無料」の追加思考ではない。
複雑な多段階推論を必要とするタスクにとって、これは合理的なトレードオフである——より深い推論プロセスは通常より正確な答えをもたらすが、同時に容量上限により早く近づくことも意味する。特に同じ会話の中で深い推論を必要とするタスクを連続して実行する場合はなおさらだ。会話の容量消費が予想より速いと感じたら、Extended Thinkingが頻繁にトリガーされていないか確認することは、原因を調べる際に注目する価値のある方向である。
長期プロジェクトに取り組んでいる場合、途中でコンテキストウィンドウが破裂しないよう、実際にどう管理すればいいですか？
最も実用的な習慣は「タスクを切り替えたらクリアする」ことだ。現在の会話とは全く無関係な新しい作業を始めようとしているなら、同じ会話を続けるより新しい会話を始める方が通常は良い——古い会話に蓄積された無関係な内容は容量を消費するだけでなく、現在のタスクに対するClaudeの判断を妨げる可能性もある。
同じタスク内で、途中で文脈を保持し続ける必要がある場合は、（使用しているインターフェースがこの機能をサポートしていれば）能動的に要約・圧縮をトリガーし、システムに以前の詳細を簡潔な要約に圧縮させてスペースを空け、自動的にトリガーされるかエラーになるまで会話を無制限に蓄積させ続けるのを避けるとよい。Claude Codeで大規模なコードベースを扱っているなら、大量のファイル読み込み作業をサブタスクに任せ、本当に必要な結果だけをメインの会話に持ち帰るのも、容量消費を制御する一般的なやり方だ。全体的な原則としては、能動的にコンテンツを管理する方が、システムの処理を受動的に待つより、通常はより安定した利用体験をもたらす。
長い会話の中で、Claudeが以前伝えた詳細を「忘れ」始めたり、回答の質が理由もなく下がったりしたことに気づいたことがあるなら、その現象の背景にはほぼ常に同じ原因がある——コンテキストウィンドウが容量の上限に近づいたか超えたのだ。これはClaudeが選択的に忘れているわけでも、賢くなくなったわけでもなく、構造的な容量制約が働いているのである。
コンテキストウィンドウとは、Claudeがその会話を処理する際に同時に参照できるテキストの最大量であり、トークンで計算される。これはいくつかの要素で構成される——システムプロンプト、会話内のすべてのメッセージ、アップロードした文書や画像、そしてClaudeが現在生成している応答自体。これらすべてを合計したものが、この上限を超えることはできない。
より適切な比喩は「机の天板の広さ」であり、「人間の脳が記憶できる容量」ではない。机の上にはたくさんの資料を広げて参照できるが、天板の広さには限りがあり、いっぱいになれば新しいものを置く余地はなくなる——机の上の古い資料を片付けて空間を空けない限りは。これが「Claudeが以前言ったことを忘れた」という現象の本質が、通常はモデルが能動的に忘れているのではなく、蓄積された会話がすでに机が保持できる範囲を超え、その結果として古い内容が押し出されている、という理由である。
言語モデルが各単語を生成する際、実際には入力全体を「振り返って」、次に来るべき最も妥当な単語を判断している。この「振り返り」の計算コストは、入力の長さが増えるにつれて急速に膨張し、しかも単純な線形増加ではない——これこそが、コンテキストウィンドウを拡大することが技術的には「設定を変える」ほど簡単ではなく、モデルが妥当な時間とコストでより長い入力を処理できるようにするために、大量のエンジニアリング上の最適化が必要となる理由である。
これを理解することは、よくある期待のズレを修正する助けになる——「Claudeは数ヶ月前に話した内容をすべて覚えているべきだ」ではなく、「この会話には実際の容量上限があり、その容量を使い切る前から古い内容が犠牲になり始める」という理解だ。
この数字はモデルと使用しているインターフェースによって異なり、Anthropicが新しいモデルをリリースするたびに変動し続ける。概念的にはおおよその換算を覚えておくとよい——英語の千単語はおおよそ800トークンに相当する。
実務上、claude.aiのウェブ版会話でのウィンドウサイズは、使用しているモデルとプランによって決まる。一部の新しいモデルはすでにウェブチャットで500Kトークン以上をサポートしており、Claude CodeやAPIを通じて使用する場合、一部のモデルは100万トークン規模のウィンドウをサポートしている。この数字はかなり頻繁に更新されるため、現在使っているモデルの実際の上限を確認したい場合、固定の数字を覚えるよりも、Anthropic公式ドキュメントページに掲載されているその時点での仕様を直接確認する方が信頼できる。
これまでの一般的な理解は「容量がいっぱいになれば、会話はエラーになるか打ち切られる」というものだったが、この挙動は新世代のモデルで明らかに変化している。Anthropic公式ドキュメントによると、新しいモデルは特定の状況下で自動圧縮メカニズムをサポートするようになった——蓄積された会話内容が容量の閾値に近づくと、システムは自動的に以前のメッセージを要約・圧縮し、会話が中断されることなく続けられるようにする。しかもユーザーの完全な会話履歴は、単純に破棄されるのではなく、モデルが参照できるよう保持され続ける。
ウェブ版を使っていて、長い会話の中でClaudeが「考えを整理している」かのような短い一時停止を見せることに気づいたら、それは通常この自動コンテンツ管理が背後で動作している結果であり、システムの不具合ではない。Claude Codeを使って長期的なプロジェクト開発を行っているなら、コマンドを通じてこの圧縮のタイミングを能動的に制御することもでき、システムが自動的にトリガーするのを完全に受動的に待つ必要はない。
ここに見落とされがちな重要な点がある——ウィンドウサイズそのものは使用効果とイコールではない。ある分析によると、巨大なウィンドウをあらゆるデータで埋め尽くすことが、本当に関連性のある情報だけを入れた小さく焦点を絞ったウィンドウより優れているとは限らない——本当に関連性のあるコードに焦点を当てた20万トークンのウィンドウが、プロジェクト全体のソースコードを詰め込んだものの大半が使われない100万トークンのウィンドウより、時にはむしろ良い結果を出すことがある。言い換えれば、ウィンドウサイズが決めるのは容量の上限であり、使用の品質ではない。回答の質を実際に左右するのは、多くの場合、入れた内容がどれだけ正確に関連性があるかである。
長文書の分析、長時間にわたるコードのリファクタリング、あるいは数週間続くプロジェクトの議論に日常的にClaudeを使っているなら、コンテキストウィンドウを理解することで、実際にかなりの無駄なやり取りの時間を節約できる。ほぼ満杯になった同じ会話の中で「前に言ったじゃないですか」と繰り返し尋ねるより、新しい会話を始めて本当に必要な背景を簡潔に改めて提供する方が通常は効率的であり、古い会話で格闘し続けるより、安定した質の高い結果をより早く得られることが多い。APIやClaude Codeを通じて長時間稼働するアプリケーションを構築しているなら、ウィンドウサイズとコストの関係を理解することも、「一度にすべてのデータを詰め込む」と「関連性の高い内容を段階的に正確に提供する」の間で、コストと効果の両面でより賢い選択をする助けになる——これはしばしば、長時間の会話を扱うアプリケーションの実際の使い心地の良し悪しを決める重要な細部である。