なぜPerplexityは過去の検索内容を忘れてしまうのか
現在のPerplexityにおける検索履歴の扱い方
質問するたびに新しいスレッドが開かれるか、既存のスレッドが延長され、それらは保存されます。Library（ライブラリ）をスクロールして、いつでも過去のスレッドを再び開くことができます。しかし、欠けているのは「つながり」です。新しいスレッドは古いスレッドを読み込みません。過去の検索から得られた文脈、情報源、結論はそれぞれのスレッド内に閉じ込められたままであり、今実行している検索からは見えません。
記憶が残らない技術的な理由
Perplexityは「検索ファースト」で構築されています。つまり、リアルタイムのウェブから現在の質問に答えるために最適化された、高速で新鮮な、使い捨てのセッションです。学んだ内容を要約して、エンジンが参照できる記憶として保存する永続化レイヤーは存在しません。Spaces（スペース）を使えば、スペース内のスレッドでファイルや指示を共有できるため問題は和らぎますが、過去のスレッドを検索可能にするわけではありません。
リサーチャーにとっての損失
同じことの繰り返し：すでに絞り込んだ検索を再実行し、すでに検証済みの情報源を再評価することになります。統合の喪失：5つのスレッドにわたって組み立てた結論は、あなた自身の記憶の中にしか存在しません。そして、蓄積はゼロ：100時間のリサーチ履歴があっても、101時間目のリサーチが有利になることはありません。
Perplexityの標準的な回避策（とその限界）
Library（ライブラリ）
スレッドの履歴はすべてそこにあり、スクロールして再度開くことができます。しかし、記憶という観点から見ると、それは「検索機能のないアーカイブ」です。適切なスレッドを見つけるには、それが存在することを覚えている必要があり、そこから新しい検索に自動的に情報が流れることはありません。
Spaces（スペース）
プロジェクトごとにリサーチをSpaceにグループ化すると、内部のすべてのスレッドに共有ファイルとカスタム指示を追加できます。これは最も強力な標準オプションです。しかし、Space内のスレッド同士は依然としてお互いを読み込むことはできず、Spaceの知識は他の検索から隔離されたままです。
古いスレッドの継続
スレッドを再度開くことで文脈を維持できるため、長期にわたるトピックを1つのスレッドにまとめることができます。しかし実際には、そのスレッドは数ヶ月分の様々な質問が混ざり合った、検索不可能なスクロールの山になってしまいます。これは、Perplexityが得意とする迅速な検索ワークフローとは正反対です。
共通の壁：完璧に整理されていたとしても、リサーチ履歴は1つのアプリの中に留まります。ClaudeやChatGPTに、あなたが見つけた内容をベースに作業するよう依頼する場合、手動で要約を貼り付ける必要があります。これは、Perplexityが以前のクエリを忘れる問題と同じ根本的な課題です。
解決策：検索履歴を本物の「記憶」に変える
永続的な解決策は、将来のすべての検索、そして他のすべてのAIが利用できるレイヤーにリサーチ結果を保存しておくことです。MemoryLakeは、蓄積されたリサーチ（調査結果、検証済みの情報源、レポート、データ）を一度保存すれば、解析して検索可能にします。Gitスタイルのバージョン管理により結論の変遷を確認でき、エンドツーエンドの暗号化によりリサーチデータはあなただけのものとして保護されます。
ステップ 1: APIキーを作成する
MemoryLakeにサインインし、キーを生成して最初のリクエストを送信します。これには約30秒しかかかりません。
ステップ 2: 最初の記憶をアップロードする
レポート、データセット、ソースPDFなど、リサーチの背景にあるドキュメント、画像、その他のファイルをドロップします。そして、スレッドの結論を短いテキストの「記憶」としてキャプチャし始めます（質問、回答、信頼できる情報源など）。
ステップ 3: AIとエージェントを接続する
現在、PerplexityにはMCPクライアントがないため、APIを使用します。キーを使って関連する記憶を取得し、それをプロンプトやリサーチワークフローに含めることで、新しい検索をすでに知っていることから開始できます。同じ記憶は、MCPを介してClaude、Codex、OpenClaw、その他のエージェントからも即座に利用可能になり、あらゆるツールでリサーチが蓄積されていきます。
再検索に実際にかかっているコスト
ナレッジワーカーに課される「繰り返し税」
絞り込んだ検索を再実行し、既知の情報源を再検証し、過去の結論を再構築することは、目に見えない作業です。アウトプットはなく、純粋な重複作業にすぎません。定期的にリサーチを行う人にとって、これは毎週静かに何時間もの時間を奪い、古いトピックと重複する新しいトピックが増えるたびにそのコストは膨らんでいきます。
繰り返すのではなく、蓄積する
永続的なレイヤーに調査結果を保存しておくことで、新しい質問はすべて蓄積されたベースから開始できます。以前の結論を取得し、何が変わったかを検証し、それを拡張するのです。また、APIワークフローにおいて、情報の取得（Retrieval）はプロンプトをスリムに保ちます。MemoryLakeのToken Saving Calculator（トークン節約計算ツール）を使えば、実際の数値からその効果を確認できます。
リサーチ記憶を構築するためのベストプラクティス
トランスクリプトではなく、結論をキャプチャする
解決した質問ごとに、日付付きの記憶（調査結果、確信度、情報源）を1つ作成する方が、スレッド全体をアーカイブするよりも価値があります。スレッドを閉じる瞬間に要約を抽出しましょう。
主張に情報源を紐付けておく
結論を裏付ける引用元を一緒に保存します。将来のあなたは、何を見つけたかだけでなく、なぜそれを信頼したのかを知る必要があるからです。
トピックやクライアントごとにスコープを分ける
リサーチの流れごとに1つのメモリ・スコープ（Memory Scope）を設定することで、検索が整理され、同僚にトピックを引き継ぐのもアクセス権を共有するだけで簡単になります。
結論
Perplexityは、今日の質問に見事に答え、明日にはそれを忘れるように作られています。Libraryは検索をアーカイブしますが、アーカイブは記憶ではありません。調査結果を永続的なレイヤーに移行すれば、その関係は逆転します。過去のすべての検索が、Perplexityや他のすべてのAIでの次の検索を高速化します。リサーチは蓄積されるべきです。そして今、それが可能になりました。