はじめに
AI の出力品質が下がる主要因はコンテキスト（文脈）であり、不足でも過剰でもどちらでも下がります。今回は過剰の方、つまり 余計なコンテキストが混ざっているせいで品質が落ちる問題 の対策を取り上げます。
細かい解説は省いて、理屈は知っている前提で、すぐ使える TIPS を 10 個並べます。
※Claude を想定します。ChatGPT や Codex など他の手段をお使いの方は適宜読み替えてください。
1: 新しい会話セッションを使う
- ブラウザ利用の場合は「新しいチャット」から
- Claude Code の場合は /new にて
とりあえず今使ってる会話セッションに何でも書く、だとコンテキストが混ざります。そのセッションには、それまでの会話が全部入っているので、LLM が混乱してしまいます。
ですので、話題が変わったと思ったら、その都度、明示的に新しいセッションを始めるのが良いと考えます。
これはある種好みの問題でもあって、たぶん「デスクトップにファイルを散らかしたままの人」vs「フォルダなどで分類する人」と同じ構図です。TIPS 1 の主張は、後者の分類派に寄っています。私は後者側というのもありますが、エンジニアとして 「与えてるコンテキストをきちんと把握しておく」方が何かとコントロールしやすい と日々感じているので、こうしています。
2: メモリー機能を切る
- ブラウザから使う対話チャットの設定から、過去チャット横断とメモリーを両方オフにする
- Claude Code のメモリー機能もオフにする
Claude では過去の会話を横断して読み込んだり、印象的なやりとりを覚えさせて（グローバルに保存させて）以後自動で使うようにしたりできます。便利ですし、使っている人も多いと思いますが、私は全部オフにしています。
理由は単純で、いつどんなコンテキストが混ざっているかを自身で把握しきれない からです。仕事や性格にもよると思いますが、私は「目的」や「前提」を与えて、それを満たす形で出力を出してほしいという 問題の解決 的な使い方をします。入力を掌握できないと、管理の主導権を握れません。
※逆に目的や前提は適当にして、とりあえず AI に出力させたのを見て融通を利かせる使い方もあります。私も探索的な状況ではそうします。
もう一つあって、私は第三者を演じて自分の出力を評価させることがよくあります。AI 時代のボトルネックは第三者レビューですが、みんな忙しいし、人間的な認知能力は変わらないのでボトルネックになります。しかし、メモリー前提でチェックさせるとマッチポンプ的になって AI が忖度します。私自身だとバレない形で、第三者としてレビューさせる ためには、私という痕跡につながるメモリーや過去会話横断をオフにするしかないと思っています。
無論、これらをオフにすると「普段心がけてほしいこと」も毎回言い直さないといけなくなりますが、それはそういうものだと思ってます。ブラウザでの対話の場合は毎回コピペすれば良い（辞書登録や定型文コピーなど省力化ツールもある）。開発その他ローカルで作業する際は、CLAUDE.md などハーネスファイルを使えば良い……とまあ、これも好みだとは思います。面倒くさいのは間違いないです。
3: Claude Code の /context をチェックして、余計なものは消す
- /context を実行すると、MCP や Skills などデフォでロードされるものを確認できる
- 要らないものがあれば消す
昔からプログラミングは名前空間との戦いであり、グローバルを無闇に汚染しないよう神経を張ったものでした。同じ構図は LLM 時代でもあって、名前空間というよりコンテキスト空間だとは思いますが、グローバルには気を配った方がいいと思います（思うようになってきました）。
私自身、何度か痛い目を見てきました。思うように動作せず、トラシューをして、何十分もかけた後に「余計なスキルや MCP がロードされている」と気づく。あるいは最近なんか品質が悪いよなぁと思っていて、あるとき「ああ！あのとき試したやつがロードされてる！！」と気づく、など。仕事柄、新しいものを試すことも多く、コンセプトや哲学が全く違うものが混在したりもします（SDD のようなウォーターフォール型 vs インタビューベースで雑につくっていくアジャイル型など）。
そういうわけで、グローバルな分には気を配るようになって、なるべくミニマムに保つようにしています。
この議論は、発展すると なるべく素の Claude を使うマンになる とも言えるでしょう。便利な MCP やスキルをグローバルにじゃんじゃん入れるのではなく、むしろほとんど何も入れない。必要な分は、プロジェクトごとに入れる。利便性は損なわれますし、毎回入れるのも面倒くさいですが、そのかわりコンテキストは綺麗ですし、私自身には合っているようで生産性や品質も上がりました。
4: CLAUDE.md に何でも詰め込まず、 .claude/rules/xxxx.md に分ける
- CLAUDE.md に詰め込むと何を入れたか忘れがちだし、目に入りにくい
- 代わりに .claude/rules/xxxx.md をつくる
ハーネスファイル CLAUDE.md は便利ですが、AI につくらせることも多く肥大化しがちです。また直接手を加えたりもしないので、別のプロジェクトのファイルをコピペしてとりあえず使ったり、なんてこともしがちだと思います。
しかし CLAUDE.md に気を配るのはやりづらい——というわけで、私は同等の機能を持つ rules/ ディレクトリを使ってます。ここには複数ファイルを置けるので、指定したい文脈を話題ごとにファイルで区切って置いてます。10 ファイル以上になることもあります。CLAUDE.md 一本派からすると気持ち悪いでしょうが、どうせ内部的にはマージされるので一緒です。
※このあたりの動作仕様は将来的に変わる可能性があります。2026-06-24 現在、私の認識は「どちらも同じ」「CLAUDE.md の方が結合タイミングが早いだけ」です。
これにより、ハーネスとして何を与えているかに気を配りやすくなりました。よく使うハーネスは xxxx.md の形で管理しておいて、必要なプロジェクトに追加すればいい。
5: 目的が異なる会議は新しく開催し直す（文字起こしを分ける）
- ある会議 A が終わった後、ちょうどいいからと B や C もやる、ということをしない
- 代わりに会議 B、会議 C を新しく立ち上げる
会議の文字起こしを LLM に与える使い方はあるあるだと思います。というより、現場のエンジニアであっても、チームの構造や組織戦略といった議論を自由にできます（できるようになりました）。もちろん、全員が読む議事録をつくらせる用途は、言うまでもなく王道の使い方でしょう。
私は仕事柄、文字起こしと一時間以上格闘することもざらにありますが、その経験から痛感したのは 会議の目的が混ざっていると、文字起こしを与えた LLM の対話品質が落ちる ことです。「いや A さんはそんなこと言ってないだろ……」みたいなうんざりがよく起きます。調べてみて、文字起こしデータが「複数の会議が混ざっている」がゆえに LLM が錯乱しやすいのかなと思いました。実際、目的ごとにファイルを分けてから会話してみると、明らかに精度が上がります。
とはいえ、セレンディピティじゃないですが、予期せぬつながりも大事なので、このスタンスは一概に良いとも言えません。私も正直あまり使っていません。というより使えてません。この動きは明らかに面倒くさすぎるからです。私は一度も定着させたことがないですし、できる気がしません。
※余談。副次的なメリットは大きいと思ってます——一度休憩をはさみやすい、その上で頭を切り替えて議論できるので体験と質が上がる（文字起こし自体のデータの質も上がる）など。ただ、入退室や会議の切り替えをもっとシームレスにできるツールが発明されない限り、この状況は変わらない気がします。
6: 「エクスポート可能なワークスペース」に異なる活動を混ぜない
- 一番わかりやすいのは Miro
- Miro を例にするなら、1-目的 1-ボードを心がける
Miro のような「多人数が使える」「広い」ワークスペース的なツールがあります。LLM 時代ですが、ここでのアウトプットも当然 LLM に渡したいです。そのためにエクスポートをするのですが、いろんな活動のアウトプットが混ざっていると使いづらくなります。
この問題の対処方法は一つで、1-目的 1-ワークスペースを心がけることです。シングルタスクというか、シングルトピックというか、一つのワークスペースでは一つのことだけしよう、みたいな。プログラミングでも単一責務の話はよく出てきますが、まさにそうです。
※余談：LLM は自然言語を処理できる存在ですが、プログラム側の仕組みではあるので、この手の原則は効きます。エンジニアとして、プログラマーとして、きれいな設計を行ってきた人は、まさにその感覚が生きると思っています。というより、そういう人でないとなかなか身につかない感覚のようにも感じます。
これを行うためのポイントは 3 つあります:
- ボードはどんどん作っても良い、という富豪的な使い方に慣れる
- ボードをどんどんつくれるだけのプランを用意する
- ボードをつくる権限の人がちゃんとつくるか、できないならつくれる人に権限を渡す
7: /compact は使わない
- 一つの会話セッションを続けたいがゆえに、 /compact で圧縮をしがち
- しかしそれは「中途半端」だし、汚染に変わりはないため、いっそのこと使わない
好みが分かれると思いますが、私は /compact は使わなくなりました。
コンテキスト管理のスタンスが中途半端だと思うからです。同じセッションで、できるだけ楽をしたいという中途半端さが透けて見えます。そうするくらいなら、いったん新しいセッションで仕切り直して、引き継ぎたい文脈は自分でつくって持ってくる方が良い。実際、/compact をしたところで、たぶんそんなに品質は良くならないと思うんですよね。まさにそうだったので私はやめました。コンテキストが汚染されてる（いろんな話題が混ざってる）こと自体が問題であり、圧縮して残したところで汚染に変わりはない のかもしれません。あくまで体感です。
もちろん、汚染ではなく、単にコンテキストが長くなってきた場合に、できるだけ粘りたいという意味では有用です。しかし今は 1M コンテキストウィンドウがサポートされており、そもそもこの意図でも使う機会は減ったのではないかと思います。
※余談：もっと言えば、機械学習の技術的な限界もあって、1M レベルのコンテキストをちゃんと踏まえること自体が現時点では無謀だと思ってます。1M に至る前に品質が落ちる的な論文もよくある印象（1 2）。無論、今後はわかりません。
8: エージェントは個人のマシンではなく専用の環境で動かす
- Agentic Engineering といわれるとおり、99% をエージェントに任せた成果物、はあるある
- しかし個人マシンで動かすと（コンテキストの汚染具合が人によって違うため）、動作が安定しない
- 代わりに、正式にエージェントを動かす環境を用意する
ビルドの文脈でも、どこでも同じブツをつくれるように気を配って整備するようになりました。パッケージ管理ファイルにバージョン番号を厳密に書いたり、ビルドスクリプトで環境チェックを入れたり、npm でインストールするときも npm ci を使うようにしたり、などこの手の気遣いはありきたりです。
同じ構図が AI エージェントの生成物にも当てはまると思います。
99% を AI に任せる（監督する）ことを Karpathy は Agentic Engineering と呼びました。問題は、そうしてつくらせた 生成物の品質が「どこでつくらせたか（どこで動かしたか）」によって変わってくる ことです。
この問題の一因も、ここまで読めばわかりますね。コンテキストが汚染されているからです。極端な話、コンテキストに無頓着で、新しいセッションも滅多に区切らず、MCP やスキルも何十何百と試したままにしている A さんと、周囲から「潔癖」とあだ名されるくらい Clean Context に忠実な B さんとでは、同じエージェントを動かしても、その品質は大きく変わることがあります。与えたコンテキストが全然違うのだから当然といえば当然です。
この世界は現状も過渡期と思いますが、品質をレビューし、管理し、トラブルをシューティングし、といったことを考えると、ビルドと同様、冪等——は無理にしても、極力安定させた方がいいでしょう。
9: コンテキストがどう組み立てられるかを理解する
- 4 にて .claude/rules/xxxx.md の話をしたが、これもコンテキスト構築の仕組みの一つ
- 実際に LLM サービスに投げられる「コンテキストウィンドウの中身」がどう組み立てられるかを理解する
結局のところ、コンテキストウィンドウに何が入っているかをちゃんと理解できれば良いとも言えます。このあたりを扱う技術は Context Engineering と呼ばれたりします（原義は「必要なコンテキストを全部提供する技術」のようですが）。これはもっと言えば、使っているものやつくっているものをちゃんと理解する、という（エンジニアとして）至極普通のことだと思います。 ※余談ですが、AI エージェントまわりのエンジニアリングは過去記事にて整理しています: Prompt/Agentic/Context/Harness/Loop Engineering ← これらの違いを理解する - Qiita
たとえば Claude Code にはシステムプロンプトの概念があって、CLAUDE.md や .claude/rules/xxxx.md などもここに入ります。ドキュメントで言えば、たとえばここが詳しいです:
また Miro や Notion といったサービスの AI を使う場合、内部的なプロンプトもあるはずですし、コンテキストに情報を載せる独自の仕組みもあるはずです。利用者が知ることはできないでしょうが、少なくとも素ではないことはわかりますし、「たぶんシステムが注入するコンテキストのせいで上手くいかない気がする」のような判断もできるようになります。実際、私も高精度な会話や要約が欲しいときは、これらの AI 機能は使わず、データだけエクスポートしてから Claude を使っていますし、その方が品質も明らかに上がると感じます。
※余談：前提として、LLM のモデルの性能は上がっているはずで、必要なコンテキストを最低限だけ与える方が上手くいくとの体感があります。ただしこれは単発のタスクの話だと思います。開発のように、大きな仕事をある程度長時間任せて自律させる場合は、私自身が把握しきるには無理があるので違った戦略が要るでしょう（TIPS 2 で述べたようなメモリー、特に覚えるべきコンテキストそのものを LLM にメンテさせる仕組みなど）。
さらに、自身が AI エージェントや関連機能を作っている場合、コンテキストウィンドウに何をどう詰めるかの処理も当然つくっているはずです。実際どうやっているか、また動かしたときに実際何が入っているかは見えるようにしておきたいです。でないと品質の作り込みやその他トラシューで泣きを見ます（見ました）。
10: コンテキストは Markdown その他文法を使ってある程度丁寧に区切る
- 雑にテキストを書き殴るのではなく、形式を指定して区切る
- 一部関連: LLM Readable かつ Friendly
LLM は賢いので、コンテキストウィンドウの中に複数の話題が入っていても区別をしてくれます。ただし、その精度は与える形式次第だと感じます。
たとえば LLM と濃い議論を行うために、直近の議事録3本を与えたいとします。
以下のようにただコピペするよりも、
(議事録1)
(議事録2)
(議事録3)
以下のような区切りを入れた方が良いでしょう:
# 会議1
(議事録1)
# 会議2
(議事録2)
# 会議3
(議事録3)
# 上記を受けて、やりたいこと
...
ここで生きてくるのが Markdown です。LLM は Markdown 記法を知っている ので、この書き方（# 大見出し）で意味的な違いを認識してくれます。会議1では〜〜、会議2では〜〜、のような区別や整理くらいは勝手に認識してくれます。
もっとも実際、特にブラウザから使う場合だと、こういう形式は指定しづらいです。そもそも利用者のAIのやりとり自体がラップされていますし、Claude は長文をコピペするとファイルとして添付されます（ので勝手に区別される）。
しかし Claude Code や API から使う場合はその限りではなく、生の Markdown を一気に与える機会が増えるはず。こういうときに、話題に応じた区切りを明示的につくってあげると良いです。LLM が勝手に話題を混ぜて混乱する率が減ると感じます。
余談: 性能の良いモデルを使う
10 選には入らず、直接関係もないので余談として書いておきます。
コンテキストを適切に判断する能力はモデルの性能に依存すると思います。おそらく高性能なモデルほど判断も上手いはずです。私の体感としてもそうです。ですので、そもそも なるべく普段から性能の高いモデルを使うのが良い と考えています。Claude で言えば、基本的に Opus を使えば良く、Sonnet を使う必要はないと思います。
ゲーム（マインクラフト）でたとえますが、鉄のツルハシがあるのに石のツルハシをケチケチ使う人が多い気がしますが、多くの場合、鉄で十分です。これは極端にはラストエリクサー症候群と名付けられていて、もったいぶる心理としてよく知られています。
石のツルハシ（Sonnet）を使うのは、大量の実行が必要なときにコストや速度がほしいときくらいではないでしょうか。あるいは AI 機能が内部的に使うモデルとして採用するくらい（利用者がたくさん使うので安価なモデルでないと辛い＆その上で高価モデルは上位プランで使わせるのがビジネスモデル上も王道）。
おわりに
Clean Context と題して、余計なコンテキストを混ぜずに LLM を使うための TIPS を整理しました。
常に Clean であればいいというほど万能ではないと思いますが、性能が上がってきた現在であれば意外と効いてくると思っています。LLM の品質に悩まれている方は、ぜひ一度お試しください。
それではまた！