生成AIを日常的に使っている技術者なら、一度はこんな経験があるはずです。最初はかなり正確に動いていたのに、ある時点から急に雑になる。さっきまで守っていた制約を忘れる。前提を取り違える。修正を頼むたびに、別の部分が壊れる。「いや、そこはもう直したはず」と何度も言いたくなる——これは単なる気のせいではありません。
AIとの会話には、長く続けることで便利になる面もあります。同時に、長くなりすぎることで推論の品質が落ちるという問題もあります。最近ではこの現象を Context Rot（文脈の劣化） と呼ぶことが増えています（Context Rot: How Increasing Input Tokens Impacts LLM Performance（Chroma Research））。
この記事では、ChatGPTの Memory や Projects、Cursorの Rules と Skills といった「新しめの機能」を、製品紹介で終わらせず、Context Rotを抑えるためのコンテキスト設計として整理します。四つのレイヤー（型・前提・部屋分け・手順化）の全体像は、考えず手を動かさない——AI活用の仕組み化、具体例で学ぶ設計のコツで触れています。本稿はそこから一歩進め、「いつチャットを切るか」「何をどこに置くか」 に焦点を当てます。記憶の三層分解や擬人化の話は「覚えている」の正体——IT技術者のためのAI記憶と擬人化、履歴が抜けにくい研究視点はLLMは会話履歴に捕まる？——「持ち越し効果」とgeometric trapをIT技術者向けに読み解くに譲ります。
はじめに——問題は「忘れた」だけではない
多くの人が最初に気にするのは、「AIはどこまで覚えているか」です。実務上の痛みは、それだけでは説明しきれません。長いチャットで起きる劣化は、過去の発言を単に忘れるだけでなく、推論そのものの品質低下として現れます。
最初に与えた仕様を守らなくなる。コード修正で既存機能を壊す。以前の決定と矛盾する提案をする。回答が冗長になり、焦点がぼやける。「この制約を守って」と再指示しても、別の制約を落とす。プロンプトへの追従性が、はっきり下がる——技術者の感覚で言えば、長い会話はだんだん 汚れたグローバル状態 を抱えた実行環境のようになります。
初期状態ではきれいに動いていた処理が、過去のやり取り、修正履歴、途中で捨てた案、古い前提、部分的な仕様変更を抱え込み、次第に予測しにくくなる。ソフトウェア開発でいう 状態管理の失敗 に近い問題です。会話履歴が内部表現に「幾何学的トラップ」として残る、という研究も、この肌感と重なります（Old Habits Die Hard: How Conversational History Geometrically Traps LLMs）。
Context Windowは「無限の記憶」ではない
AIとの会話では、過去のやり取りがコンテキストとしてモデルに渡されます。この一度に参照できる範囲が context window（コンテキストウィンドウ） です。ウィンドウの長さは年々伸びていますが、長い入力を受け取れることと、長い入力全体を高精度に扱えることは同じではありません。
Chromaの2025年研究では、18の主要モデルで、入力トークンが増えるほど性能が落ちる context rot が広く観測されました。Needle in a Haystackのような単純検索では高得点でも、会話履歴全体を載せるタスクでは精度が落ちる、といった結果が報告されています（Context Rot（Chroma Research））。別系統の研究では、長い文脈の中央付近の情報が参照されにくい Lost in the Middle 現象も知られています（Lost in the Middle: How Language Models Use Long Contexts）。
長い会話を続けると、現在も有効な仕様、すでに破棄された案、一時的なメモ、過去のエラー、修正済みの指摘、今回のタスクには不要な雑談、似ているが別件の依頼——こうしたものが同じコンテキスト内に混在します。人間なら「もう関係ない」と切り捨てられますが、モデルにとってはすべてが入力の一部です。
つまり長いチャットの問題は、情報が多いことそのものではなく、必要な情報と不要な情報が同じ場所に積み上がること にあります。ウィンドウが広がっても、設計を変えなければ劣化は起き得ます。読みながら染み込ませる——推論時学習TTT-E2EとAIエージェントの設計地図で触れた「外側に積むだけでは足りない」という話とも、同じ根っこでつながります。
Memory——チャットの外に「ユーザー設定」を置く
Memory は、ひとつの長いチャットに頼らず、ユーザーに関する継続的な情報を保持する仕組みです。ChatGPTでは Saved memories（保存されたメモリ） と Reference chat history（過去チャットの参照） を分けて管理できます（Memory FAQ | OpenAI Help Center）。Cursorでは User Rules が、全プロジェクトにまたがる個人の前提に近い層です（Rules | Cursor Docs）。
Memoryに向いているもの
よく使う文体、想定読者、出力形式の好み、よく扱うテーマ、毎回説明しなくてよい基本情報——こうした 比較的安定したユーザー設定 が向いています。技術者であれば、「Pythonは型ヒント付きで」「フロントはReact + TypeScript前提で」「セキュリティ設計ではゼロトラストと監査ログを重視」といった グローバルな好み です。
Memoryの価値は、チャットを長くしなくても基本的な文脈を引き継げる点にあります。毎回のプロンプトを短くでき、コンテキストウィンドウを本題に使えます。OpenAIの説明でも、Memoryは高レベルな好み向けで、巨大なテンプレートや長文の逐語保存には向かない とされています（同FAQ）。
Memoryに向いていないもの
特定案件の詳細仕様、ある機能の細かな実装方針、今週だけ有効な制約——これらをMemoryに詰め込むと、古い案件の前提が別タスクに漏れやすくなります。Memoryは ユーザープロファイル であり、Gitで言えば .gitconfig に近い層です。リポジトリごとの作業内容は、次の Projects 側に置きます。
Projects——作業単位ごとに文脈を隔離する
Projects は、特定のテーマや目的ごとに作業空間を分ける機能です。ChatGPTの Projects in ChatGPT では、関連ファイルや指示をまとめ、会話をプロジェクト単位で整理できます。Claudeのプロジェクト、Geminiのジェム（Gems）も、同じ発想の入口です。
Cursorに近い世界観で言えば、リポジトリ＋.cursor/rules＋AGENTS.md がプロジェクト層に相当します。ルールはバージョン管理でき、パスごとに適用範囲を切れます（Rules | Cursor Docs）。通常のチャットが一時的なREPLだとすれば、Projectsは リポジトリ です。README、設計方針、関連ドキュメント、命名規則、目的がそこに置かれ、個々のチャットはその中の 作業ブランチ のように扱えます。
ProjectsがContext Rot対策として効く理由
第一に 文脈の再利用 です。毎回同じ資料や前提を貼り直す必要が減ります。第二に 文脈の隔離 です。別プロダクトの仕様が混ざりにくくなります。第三に チャットを短く保てる ことです。長い会話で文脈を保持するのではなく、プロジェクトに必要な情報を置き、会話は目的別に切ります。
プロダクト開発、ドキュメント整備、長期調査、記事連載、研修設計、コードベース理解、社内ルール整備——継続案件はProjects向きです。プロジェクト側には目的、想定読者、制約、関連資料、命名規則、出力フォーマット、確定した決定事項 を置き、作業ごとに新しいチャットを立てます。「第1章の構成を作る」「この関数の責務分離を考える」「FAQだけ作る」のように、チャット単位を小さくする のがコツです。
エージェント基盤の話では、長時間タスクでセッションをまたぐ ハーネス側の継続性 が課題になります（モデルの外側が勝負——ハーネスエンジニアリングを現場言語でつかむ）。Projectsやルールは、その「外骨格」のうち、人間が読める仕様として残す層 に当たります。
Skills——うまくいった手順をチャットの外へ
Skills は、特定の作業手順や判断基準を再利用可能な形にまとめる考え方です。Cursorでは .cursor/skills/ や .agents/skills/ に SKILL.md を置き、Agentが必要に応じて読み込みます（Agent Skills | Cursor Docs）。Agent Skillsはオープン標準としても整理されており（agentskills.io）、手順のポータビリティが上がっています。
長いチャットを使い続ける理由のひとつは、「このスレッドにはうまくいった流れが残っているから」です。しかしそれを続けると、スレッドはどんどん長くなり、Context Rotの温床になります。うまくいった手順をチャット内に残すのではなく、Skillとして外出し する——これが次の一手です。
Skillに入れるべきなのは、完成物そのものではなく 再現可能な手順 です。想定読者、出力形式、作業ステップ、チェックリスト、品質基準、よくある失敗、禁止事項、最後に確認する観点。開発にたとえれば、属人的な作業メモを RunbookやCIジョブ に昇格させる作業です。長い会話に溜まった暗黙知を、明示知に変える という整理になります。
考えず手を動かさない——AI活用の仕組み化、具体例で学ぶ設計のコツでは、スキル化を「AIの迷いを減らす」観点で紹介しました。本稿では、チャットを切っても品質を維持する 観点を足します。毎回同じ指示で技術記事を書いている、コードレビューの観点を毎回説明している——そうしたパターンは、長いスレッドの再利用ではなくSkill化の候補です。
長いチャットはアンチパターンではない
ここまで読むと、「長いチャットは使わない方がよい」と感じるかもしれません。正確には、常に悪いわけではありません。
ひとつの文章を段階的に推敲する、短時間で同じテーマを掘り下げる、直前のやり取りを踏まえて微調整する、数ターンの仕様相談、ひとつのバグの原因調査——このような用途では、同じチャットを続ける方が自然です。
問題は、ひとつのチャットを 作業場所・記憶装置・ナレッジベース・履歴管理・テンプレート のすべてにしてしまうことです。巨大なREADMEに、仕様、議事録、コード、課題、過去の失敗、現在の依頼、テンプレートを全部書き込むようなもので、短期的には便利でも、長期的には保守不能になります。
実務での使い分け——三つの判断軸
技術者向けに、判断を三つに絞って整理します。
単発作業は新しいチャットで短く
エラー文の解釈、SQLの修正、正規表現の作成、小さなコードレビュー、短い文章の改善、設計方針の壁打ち、ライブラリの使い方確認——こうした作業は、新しいチャットで短く 終えるのが基本です。長い履歴はほとんど不要で、むしろ過去の文脈が混ざると回答がズレやすくなります。
継続案件はProjects（とルール）に入れる
プロダクト開発、ドキュメント整備、長期調査、教材作成、記事連載、社内ルール整備——ここではプロジェクト側に文脈を置き、作業ごとにチャットを分ける 運用が効きます。
繰り返す手順はSkills化する
同じパターンの作業を何度もしているなら、長いチャットの使い回しではなく、手順を定義した方が安定します。Skill化の骨子は、次のような形で十分です。
目的：
このSkillは、○○向けの技術記事を作成するために使う。
想定読者：
実務経験のあるエンジニア。基礎用語は理解しているが、対象技術には詳しくない。
出力方針：
- 導入で課題を明確にする
- 技術背景を説明する
- 実装例を入れる
- 落とし穴を示す
- 最後に実務上の判断基準をまとめる
禁止事項：
- 宣伝調にしない
- 抽象論だけで終わらせない
- 根拠のない断定をしない
Cursorでは SKILL.md の frontmatter に name と description を書き、必要なら paths で対象ファイルを限定します（Agent Skills | Cursor Docs）。動作条件：Cursor 2.4以降でAgent Skillsが有効な環境、プロジェクトに .cursor/skills/ または .agents/skills/ が存在すること。
四層モデル——チャットにすべてを背負わせない
技術者がAIを安定して使うなら、次の四層で考えると整理しやすくなります。Memory（User Rules）は グローバル設定、Projects（Project Rules / プロジェクト指示）は リポジトリ、Skillsは 再利用可能な処理、Chatは 一時的な実行環境 です。
| 層 | 置くもの | 開発でのたとえ |
|---|---|---|
| Memory | 文体、技術スタック、読者像、出力方針 |
.gitconfig、エディタのグローバル設定 |
| Projects | 目的、要件、制約、資料、確定した決定 | Gitリポジトリ、ワークスペース |
| Skills | 記事作成、レビュー、リスク分析の手順 | Runbook、CIジョブ、テンプレート |
| Chat | この関数を直す、この章を推敲する | REPL、作業ブランチ、一時セッション |
賢いモデルを探す競争は終わった——次世代AIで勝つ「権限・検証・観測・状態」の設計と運用で触れた 状態（コンテキスト）のエンジニアリング は、この四層の上に、権限・検証・観測が載ります。本稿の四層は、そのうち 「何をどこに置くか」 の地図です。
「会話が劣化してきた」ときのサイン
どこで新しいチャットに移るべきか迷うときの目安です。指示を何度も守れなくなる、前提を取り違える、修正した箇所を再び壊す、回答が妙に冗長になる、「違います」と言う回数が増える、直前の会話を踏まえていないように見える、古い案と新しい案を混ぜる——この状態でさらに指示を積み増すと、チャットはますます重くなります。続けるより、いったん整理して新しいチャットへ移る方がよいです。
新しいチャットへ移るときの引き継ぎメモ
長い会話から移るときは、過去の全履歴ではなく、現在有効な情報だけを渡します。リファクタリングと同じで、不要な状態を削り、いまの処理に必要な入力だけを残します。
目的：
今から行いたい作業は○○です。
背景：
これまでに○○を検討しました。
現在の決定事項：
- ○○
- ○○
守るべき制約：
- ○○
- ○○
不要になった案：
- ○○は採用しません
- ○○の方針は破棄しました
次にしてほしいこと：
○○を作成してください。
OpenAI APIで会話状態を扱う場合も、履歴の丸ごと送信ではなく、要約済みの状態や確定事項だけを渡す設計が推奨されます（Conversation state | OpenAI API）。
大きな資料を扱うとき——工程をチャットで分ける
論文、仕様書、議事録、コードベース、動画の文字起こしなど、大きな資料を同じチャットで何十回もやり取りすると、コンテキストは急速に肥大化します。このときは、読み込み・分析・修正・統合・レビュー をひとつのチャットに背負わせない方がよいです。
まず資料全体の構造を把握し、章ごとに要約する。論点ごとに別チャットで深掘りする。最終統合は要約済みメモだけを使う。完成物のレビューはさらに別チャット——という 工程分割 が、回答品質を安定させます。RAGやAgentic Searchの設計とも接続できますが、詳細は筆者のQiita記事一覧の検索・エージェント関連稿を参照してください。
本質は「良いプロンプト」よりコンテキスト設計
AIをうまく使う技術は、単に「良いプロンプトを書くこと」だけではありません。より本質的には、コンテキストをどう設計するか です。どの情報をMemoryに置くか、どの情報をProjectに置くか、どの作業をSkill化するか、どの単位でChatを切るか、どのタイミングで会話を捨てるか。
責務を分ける。スコープを限定する。不要な状態を持たない。再利用する処理は抽象化する。グローバル状態に頼りすぎない。履歴ではなく、現在有効な仕様を参照する——ソフトウェア設計の原則が、そのままAI活用にも効きます。DeNAのAI社員が突きつける——プロンプトより環境設計で触れた エンバイロメントエンジニアリング も、同じ系譜の話です。
まとめ——会話は「伸ばす」のではなく「設計する」
長いチャットは便利です。しかし、それを記憶装置として使い続けると、文脈が肥大化し、Context Rot で性能が落ちることがあります。これからの実務的なAI活用では、次の整理が効きます。
長期的な好みはMemoryへ。案件ごとの文脈はProjectsへ。繰り返す手順はSkillsへ。個々の作業は短いChatへ。
AIの性能を引き出す鍵は、モデルそのものだけではありません。ユーザー側が、どの情報をどこに置き、どの単位で会話を切るか にあります。技術者にとって、これは新しいプロンプト術というより、AI時代のコンテキスト設計 です。安定して使える人は、長い会話を続ける人ではなく、必要な文脈だけを整理し、不要な文脈を捨て、作業単位を適切に分けられる人です。
Memory、Projects、Skillsは、AIを「賢くする機能」というより、AIとの作業を保守可能にする機能 として捉えると、その価値が見えやすくなります。まずはいま伸びきっているスレッドを一つ選び、「これはMemoryか、Projectか、Skillか、それとも捨てて新規Chatか」を分類するだけでも、体感は変わりやすいです。
作成日：2026年5月17日