AIエージェントと一緒にコードを書いていると、こんな経験はないでしょうか。
「さっき合意した設計方針、もう忘れてない？」
LLMは本質的にステートレスです。セッションをまたぐと記憶を失い、まっさらな状態からやり直しになる。アーキテクチャの方針、ライブラリの選定理由、議論の末に決めた誓約事項──こうしたプロジェクト固有のコンテキストが揮発するたびに、同じ説明を繰り返すことになります。
この問題への現在もっとも一般的なアプローチが、CLAUDE.mdへの記録です。プロジェクトルートにコンテキストファイルを置き、コーディングエージェントが毎回それを読み込むことで、セッション間の文脈を引き継ぐ。シンプルで導入も簡単、多くの開発者が実践しています。
ただ、プロジェクトが進むにつれてCLAUDE.mdは肥大化していきます。方針が増え、例外が増え、「あれもこれも書いておこう」と情報が積み重なっていく。ここに落とし穴があります。
コンテキストは長いほど良い、わけではない
Chroma Researchの調査（"Context Rot"）では、18のLLMモデルを横断した評価で、タスクの複雑性を一定にしたまま入力トークン数だけを増やすと、出力品質が劣化することが示されています。
さらに示唆的なのが、ACL Findings（EMNLP 2025）の報告です。Retrievalが正しく機能し必要な情報がコンテキストに含まれていたとしても、周囲のトークン量が多いだけで推論品質が下がる。つまり「正しい情報を持っていること」と「それを活用できること」は別の問題なのです。
コンテキストを持ち続けることと、コンテキストに埋もれて精度が劣化すること。この2つは本質的にトレードオフの関係にあります。
「全部渡す」から「必要なものだけ渡す」へ
CLAUDE.mdが静的な「全量投入」だとすれば、もうひとつのアプローチは「必要なタイミングで必要な文脈だけを渡す」という動的な参照です。
sqlewは、開発中の設計方針や誓約事項を構造化して蓄積し、AIエージェントがMCP経由で必要な文脈だけをJust-in-Timeで取得できるようにするツールです。RAGやエンベディングのセットアップは不要、導入後30秒で稼働します。
コンテキストの永続化は大切です。でもそれは「量」ではなく「S/N比」の勝負。必要な情報を、必要なときに、必要なだけ届ける。私たちはその仕組みづくりに取り組んでいます。
参考文献
- "Context Rot: How Increasing Input Tokens Impacts LLM Performance" — Chroma Research — https://research.trychroma.com/context-rot
- "Context Length Alone Hurts LLM Performance Despite Perfect Retrieval" — ACL Findings (EMNLP 2025) — https://aclanthology.org/2025.findings-emnlp.1264.pdf
