ChatGPTが製品要件を忘れてしまう理由
現在のChatGPTによるPRDの扱い方
PRDを貼り付けたりアップロードしたりすると、ChatGPTはその会話のコンテキストにそれを読み込み、適切に推論します。しかし、チャットが終了すると、そのドキュメントも一緒に消えてしまいます。削ったスコープ、列挙したエッジケース、「v1ではSSOを実装しない」という決定――これらすべてはそのセッションの中だけに存在していました。次のチャットでは、プロダクトの蓄積された定義ではなく、あなたが再び貼り付けたものだけが参照されます。
定着しない技術的な理由
ChatGPTの永続化機能は、生きた仕様書を保持するようには作られていません。Memoryはコンパクトな事実や好みを保存します（「私はPMです。ユーザーストーリーはGherkin形式で書いてください」といった用途には便利です）。しかし、要件定義書を保存するには小さすぎますし、その変更履歴を管理することなど到底不可能です。Projectsはアップロードされたファイルを保持できますが、それらは永続的な知識になるのではなく、会話ごとに再読み込みされるだけであり、スプリントごとに変化する要件のバージョン管理を行う仕組みはありません。「このプロダクトが何であるか、そして何を構築しないと決定したかを記憶する」役割を持つレイヤーが存在しないのです。
プロダクトチームが支払うコスト
決定済みのスコープの再議論：モデルはすでにカットした内容を提案し、あなたは毎セッション、なぜそれをカットしたのかを再説明することになります。成果物間のズレ：火曜日に書かれたユーザーストーリーが、木曜日に変更された要件を前提としてしまっていても、その不一致を指摘するものは何もありません。そして、失われる根拠：エンジニアリングチームから「なぜこの挙動がこのように指定されているのか」と聞かれたとき、その理由は誰も見つけられないチャットの中に埋もれてしまっているため、決定事項がゼロから再議論されることになります。
ChatGPTの組み込みの回避策（とその限界）
Memory
執筆フォーマット、フレームワーク、役割など、永続的な好みを設定するのに適しています。しかし、その限界は明確です。仕様書ではなく、短いテキストエントリしか保存できません。要件を「どのように書くか」を教えることはできても、要件が「何であるか」を教えることはできません。
Projects
プロダクト領域ごとにプロジェクトを作成することで、関連するチャットやファイルをまとめることができ、整理には非常に役立ちます。しかし、ファイルは会話ごとに再読み込みされる静的な添付ファイルにすぎず、プロジェクトの知識が他のプロジェクトやチームメンバーに共有されることはありません。また、要件の変更履歴を追跡する仕組みもありません。
PRDの再貼り付け
デフォルトの回避策（すべてのセッションに現在の仕様を貼り付ける）は機能しますが、これは毎セッションの前に繰り返される手動のコストです。また、古いコピーを誤って貼り付けてしまった場合、気づかないうちに破綻してしまいます。これは何も貼り付けないことよりも事態を悪化させます。
共通の壁：要件は、使い捨てのチャット、個人ごと、アプリごとに存在し、プロダクトが実際に構築される場所から切り離されています。これは、ChatGPTがプロジェクトのコンテキストを忘れてしまう理由と同じ根本原因であり、忘れてしまった決定事項がバグとしてリリースされてしまう原因になります。
解決策：ChatGPTに永続的なプロダクトメモリを提供する
永続的なアプローチは、仕様とその決定事項を、単一のチャットの外部にあるメモリレイヤーに保持することです。MemoryLakeは、PRD、スコープの決定、エッジケースを一度保存すれば、解析されて検索可能になり、Gitスタイルのバージョン管理によって要件の履歴を追跡できます。また、エンドツーエンドで暗号化されているため、未公開のロードマップの詳細も社内に安全に保たれます。
ステップ 1: APIキーの作成
MemoryLakeにサインインし、キーを生成して、最初のリクエストを送信します。所要時間は約30秒です。
ステップ 2: 最初のメモリのアップロード
仕様策定セッションに必要なもの（PRD、ユーザーリサーチの要約、デザインドキュメント、APIコントラクトなど）を投入します。ドキュメント、画像、その他のファイルすべてに対応しています。流動的な部分をテキストメモリとしてキャプチャ（例：「v1のスコープからSSOを除外 — エンタープライズ向けはQ4に延期」、「通知は1時間ごとにバッチ処理、コスト面からリアルタイム処理は見送り」）することで、決定事項がドキュメントとともに永続化されます。
ステップ 3: AIとエージェントの接続
MemoryLakeのChatGPT統合またはAPIを介してChatGPTを接続することで、すべてのセッションが現在の仕様やスコープ外の事項をすでに把握した状態で始まります。同じメモリは、MCPまたはAPIを介してClaude、Codex、OpenClaw、その他のエージェントからも利用できます。これにより、PMツールが参照する要件と、コーディングエージェントが参照する要件が完全に一致します。
仕様の再定義が実際にもたらすコスト
再議論のコスト
各セッションの前にPRDを再貼り付けし、カットしたスコープを再説明することは、実際のプロダクト思考に充てるべき時間を奪います。さらに深刻なコストは、決定事項が静かにずれていくことです。2つのセッションがそれぞれ異なるバージョンの「真実」に基づいて進められ、レビューの段階になるまで誰もそのズレに気づかないという事態が発生します。
再貼り付けに代わる情報取得（Retrieval）
永続レイヤーを使用すると、ドキュメント全体を再読み込みする代わりに、各セッションが必要に応じて現在の要件とその背景にある理由をオンデマンドで取得します。仕様の一貫性が保たれ、根拠が追跡可能になり、プロンプトを軽量に維持できます。MemoryLakeのToken Saving Calculator（トークン削減計算ツール）を使用すると、実際の使用状況からその効果を予測できます。
プロダクトメモリのベストプラクティス
「構築しない」と決めたことを記録する
カットされたスコープは、プロダクト開発において最も再提案されやすいものです。「Yという理由により、v1ではXを行わない」という1行を記録しておくだけで、毎セッション同じ提案が繰り返されるのを防ぐことができます。
要件は上書きせず、バージョン管理する
要件が変更されたときは、黙って上書きするのではなく、日付を付けて改訂履歴を追加します。バージョン履歴があれば、過去のチャットを掘り返すことなく、「6月に合意した内容は何か？」という疑問にすぐに答えることができます。
プロダクト領域ごとにスコープを分ける
プロダクトラインや領域ごとにメモリのスコープを分けることで、関連性の高い情報のみを取得できるようになり、ある領域の制約が別の領域の仕様に混入するのを防ぎます。
結論
PRDは生きたドキュメントですが、ChatGPTはそれを1回限りのセッションの添付ファイルとして扱います。目の前に貼り付けられた内容には鋭く反応しますが、プロダクトがこれまで決定してきたすべてのことについては白紙の状態です。MemoryやProjects機能は作業を整理するのには役立ちますが、仕様を保持することはできません。要件とその根拠を永続的なメモリに移行しましょう。そうすれば、すべてのセッションが現在の真実から始まり、カットされたスコープはカットされたまま維持され、エンジニアリングチームはなぜその挙動がそのように指定されているのかを追跡できるようになります。自社プロダクトの仕様を何度も再定義するのは、もう終わりにしましょう。