はじめに
こんにちは、エンジニア4年目の嶋田です。
この記事を開いていただき、ありがとうございます！
最近、AIの使い方について自分の怠慢に気づきました。
同じチャットをずっと使い続けて、毎回あれこれ話しかける運用です。
新しいチャットで始め直すのは、正直めんどくさい。
前提を説明し直すのも手間だし、会話の途中で決まっていくこともある。
目先のやりやすさや楽さを優先していました。
そんな中、先輩にこう言われました。
「同じチャット使い続けるのやめた方がいいよ。質下がるから」
自分でも薄々気になっていたところを、的確に指摘された感覚でした。
先輩の指摘には、だいたい何かしらの技術的な理由があります。
この機会に、なぜ質が下がるのか、どうすればいいのかをちゃんと調べてみようと思いました。
この記事は、その過程で気づいたことをまとめたものです。
ぜひ最後までお付き合いください。
目次
- 前提：AIが賢くなって、プロンプトを練らなくなった
- 「チャットを分けろ」の裏にあるもの
- 本質は「分ける／分けない」ではなかった
- 対処法①instructionsで共通文脈を外に出す
- 対処法②モデルを使い分ける
- 対処法③プロンプトで文脈を整える
- まとめ
前提：AIが賢くなって、プロンプトを練らなくなった
振り返ってみると、自分のAIの使い方はこの2年でずいぶん変わっていました。
2年ほど前、GPTが流行り始めた頃は、プロンプトの書き方を一生懸命調べていました。
- 「あなたは〇〇のプロです」と役割を与える
- 制約を明示する
- 出力形式を指定する
そういうコツを一つずつ試していた記憶があります。
今はどうかというと、普通に話しかけています。
「ここバグってるから確認して」で済むことが多いし、それでもそれなりに返ってくる。
プロンプトを練る機会は、明らかに減りました。
AIが賢くなったのはありがたいことです。
でもその裏で、自分の中から 「ちゃんと設計して指示を出す」という意識が抜け落ちていたんだと思います。
今回の先輩の指摘は、たぶんその抜け落ちに対するものでした。
「チャットを分けろ」の裏にあるもの
調べてみると、これは単なる好みの問題ではありませんでした。
LLMの仕組み上、長い会話で精度が下がる現象は実在します。
大きく3つの観点から説明できます。
①トークンが毎ターン累積する
LLMは会話の途中で「前の会話を覚えている」ように振る舞いますが、実際には毎回、会話履歴のすべてを入力として再送されています。
ユーザーのメッセージも、AIの応答も、ターンが進むごとに入力トークンとして積み上がっていきます。
Anthropicの公式ドキュメントにもこう書かれています。
As the conversation advances through turns, each user message and assistant response accumulates within the context window. Previous turns are preserved completely.
（会話が進むごとに、ユーザーのメッセージとアシスタントの応答が文脈ウィンドウ内に蓄積される。過去のターンは完全に保持される）
つまり20ターン続く会話は、20ターン目の入力に1〜19ターン目の全文が含まれているということです。
出典：Context windows - Claude API Docs
②長くなると精度が落ちる（Context Rot）
トークンが累積するだけなら、「コンテキストウィンドウに収まる限りは問題ないのでは？」と思うかもしれません。
実際、今のClaudeは100万トークンまで扱えます。
しかし、収まっていても精度は落ちます。
Anthropic自身が、同じ公式ドキュメントでこう書いています。
As token count grows, accuracy and recall degrade, a phenomenon known as context rot.
（トークン数が増えると精度と想起が落ちる。これはcontext rotとして知られる現象である）
AIを作っている会社自身が「長くなると質が落ちる」と認めているというのは、なかなか重い事実だと思います。
出典：Context windows - Claude API Docs
③複数ターン会話で性能が平均39%落ちる
そして、会話の話として一番決定的だったのが、2025年に発表されたLabanらの論文です。
Claude、GPT、Gemini含む15の主要LLMを対象に、20万回以上のシミュレーションで単一ターンと複数ターンの性能が比較されました。結果はこうです。
- 最初に全情報を渡す（FULL）：約90%の性能
- 情報を複数ターンに分けて小出し（SHARDED）：約55%の性能
平均39%の性能低下。
しかもこれは、Claude 3.7 Sonnet、Gemini 2.5 Pro、GPT-4.1といった上位モデルでも変わらず、推論モデル（o3、DeepSeek-R1）でも劣化の幅はほぼ同じでした。
モデルの賢さで解決する問題ではないということです。
論文のタイトルは「LLMs Get Lost In Multi-Turn Conversation」。
まさに先輩が言っていたことそのものでした。
さらに興味深いのが、論文の中で "loss-in-middle-turns phenomenon" として言及されている現象です。
モデルは会話の最初と最後のターンに注意が偏りやすく、中盤で出てきた情報に対する注意が相対的に薄くなる傾向があるとのこと。
会話に置き換えるとこうなります。
序盤で決めた前提も、直近のやり取りも覚えている。でも中盤で出てきた「これ大事だから覚えておいて」が、一番忘れられやすい。
長く使えば使うほど、「言ったはずなのに」が起きやすくなる構造です。
出典：Laban et al., "LLMs Get Lost In Multi-Turn Conversation", arXiv:2505.06120 (2025)
本質は「分ける／分けない」ではなかった
ここまで調べて、先輩の指摘が技術的に根拠のあるものだったことが分かりました。
めんどくさがっていた自分が、単純に勉強不足だったということです。
とはいえ、「毎回新しいチャットで始めよう」を素直に実践しようとすると、今度は別の問題に当たります。
毎回前提を説明し直すのは手間だし、会話の中で決まっていくこともある。
ここでもう一段、考える必要がありました。
問題の立て方を変えてみます。
「分けるか、分けないか」ではなく、「文脈をどう管理するか」。
実は、Labanらの論文自身が対処法としてこう書いています。
- うまくいかなくなったら新しいチャットで始め直す
- 分散した要件を一つの明確なプロンプトに集約する
つまり「毎回分ける」ではなく、長くなりすぎないように文脈を整えるということでした。
先輩が伝えたかったのも、たぶんこっちの本質の方なんだと思います。
そう考えると、やるべきことは3つに整理できます。
- 毎回説明する内容は、会話の外に出しておく（instructions）
- タスクに応じてモデルを使い分ける（軽いタスクに重いモデルを使わない）
- 会話内のプロンプトの書き方を整える
ここからはその3つを見ていきます。
対処法①instructionsで共通文脈を外に出す
「毎回同じこと書きたくない」への一番シンプルな答えがこれでした。
Claudeには、会話の外側に設定を書ける場所があります。
具体的にはこの3階層です。
プロフィール設定（Profile Preferences）
全ての会話に自動で適用される、自分の基本情報や好み。
無料プランでも使えます。
例：
- 技術スタックはLaravel / Rails / AWSが中心
- 説明はジュニアエンジニアにも分かる言葉で
- 根拠がないときは推測せず「分かりません」と答える
一度設定すれば、全チャットで自動的に考慮されます。
プロジェクト指示（Project Instructions）
特定のプロジェクト内の会話だけに適用される指示。
案件ごとに分けたい情報はここに書きます。
例：Aプロジェクト用
- フレームワーク：Laravel 11
- コーディング規約：PSR-12
- レビュー時は必ずテスト観点も提示
スタイル（Styles）
出力の形式を制御する設定。
「markdown形式で」「絵文字は使わない」など。
この3つが重ねて適用されます。
プロフィールが先に読まれて、その上にプロジェクト指示が乗る構造です。
出典：Understanding Claude's Personalization Features - Claude Help Center
Before / After
Before：
今Laravel 11のプロジェクトで〇〇という機能を作っていて、
PSR-12に準拠したコードで、テスト観点も含めて、
ジュニアでも分かる言葉で説明してほしいんだけど...
After：
〇〇という機能を作りたい
「毎回書く」から「一度だけ設定する」への移行です。
対処法②モデルを使い分ける
もう一つの観点が、モデルの使い分けです。
Claudeには現時点で3つのモデルがあります（2026年4月時点）。
| モデル | 入力料金 | 出力料金 | 特徴 |
|---|---|---|---|
| Opus 4.7 | $5 / MTok | $25 / MTok | 最高性能 |
| Sonnet 4.6 | $3 / MTok | $15 / MTok | バランス型 |
| Haiku 4.5 | $1 / MTok | $5 / MTok | 高速・軽量 |
ポイント：全部Opusで投げる必要はない
全てを最高性能のモデルでやると、コストも時間もかかります。
研究でも、クエリの複雑さに応じてモデルを使い分けると、最大50倍のコスト削減が可能と報告されています。
出典：Ong et al., "RouteLLM: Learning to Route LLMs with Preference Data", arXiv:2406.18665 (2024)
実際の使い分け
自分の場合はこんな感じで使い分けています。
- Haikuで十分なタスク：定型的な要約、簡単な変換、軽い壁打ち
- Sonnetが向いているタスク：通常の開発相談、コードレビュー、記事の下書き
- Opusを使うべきタスク：複雑な設計判断、複数ファイルにまたがるリファクタ、長文のコードレビュー
「常にOpus」ではなく、タスクに応じて選ぶという視点が大事でした。
対処法③プロンプトで文脈を整える
最後に、会話の中でのプロンプトの書き方です。
冒頭で書いた通り、AIが賢くなって「適当に話しかける」で済むようになりました。
でも、適当に話しかけた会話ほど、長くなると迷子になりやすいということが分かってきました。
会話が長くなってきたと感じたら
Labanらの論文の推奨にもある通り、要件を一つのプロンプトに集約するというやり方が有効です。
具体的には、こんなプロンプトを途中で投げます。
ここまでの会話で決まったことを整理して、
前提・目的・制約条件の3つにまとめて出力してください。
こうして出てきた整理結果を新しいチャットに渡すと、文脈を保ちつつリセットできます。
この「要約して引き継ぐ」パターンは、研究でも有効性が確認されています。
再帰的に要約することで、長期対話のメモリ能力が改善されるという結果が出ています。
まとめ
先輩に「チャット分けて」と言われたとき、めんどくさがっていた自分に伝えるならこの3つです。
- 目先の楽さを優先して、仕組みを理解しようとしていなかった
- 調べてみたら、指摘には技術的な根拠があった
- 本質は「分ける／分けない」ではなく、文脈をどう管理するかだった
AIが賢くなって、プロンプトを練る習慣が減っていました。
その結果、文脈を管理するという発想自体が抜け落ちていたのだと思います。
先輩の一言がなかったら、たぶんずっと気づかずに使い続けていました。
指摘をもらった時に、めんどくさがらずにちゃんと理由を聞きに行ける人でありたいなと改めて思いました。
同じように「チャットを分けるのめんどくさい」と感じている方の参考になれば嬉しいです。