すべての Perplexity Project は Git リポジトリ — チームのファイル、履歴、Brain メモリにとっての意味とは (2026)

「Building shared workspaces for people and agents（人とエージェントのための共有ワークスペースの構築）」と題されたこの投稿は、プロダクトの紹介から始まります。Projects は「Perplexity Computer において、人とエージェントが長期にわたるタスクで共同作業を行う場所」であり、「各プロジェクトは、セッション、エージェント、ユーザー間でコンテキストを蓄積するファイルシステムを備えた共有ワークスペース上に存在」します。

そして、そのワークスペースに対する3つの要件を挙げています：

• 永続性（Persistence）: 「作業は、個々のエージェントセッションやサンドボックスを超えて耐久性を持つ必要があり、将来の作業を同じユーザーやエージェントが継続し、共同作業者がそれを基に構築できるようにする。」
• 並行性（Concurrency）: 「同じプロジェクト内の複数のユーザーが、それぞれ複数のエージェントを並行して編集させ、互いに上書きするのではなく、共有された状態を前進させることができる。」
• 追跡可能性（Traceability）: 「ユーザーとエージェントの両方が履歴を確認できるようにし、前回のセッション以降に誰が何を変更したかをプロジェクト全体を読み直すことなく確認でき、必要に応じて編集をロールバックできるようにする。」

Git はすでにソフトウェアチーム向けにこれらの課題を解決しているため、Perplexity はそれを基盤に構築しました。「すべての Computer プロジェクトは、5つのコンポーネントによって提供される Git リポジトリによって支えられています」。それらは、各エージェントのサンドボックス内にある小さなコマンドラインツール、コントロールプレーン、Git サービス、AWS S3 上のストレージ、そしてドキュメントからテキストを抽出するダウンストリーム処理ステップです。

また、この投稿では、エージェントには「レビュー画面、ブランチ管理、通知」は不要であるとも述べています。リポジトリは共有された状態であり、コードレビューツールではありません。

リポジトリはプロジェクトのファイルを保持します。Perplexity のヘルプセンターでは、Project を「検索、Perplexity Computer タスク、ファイル、指示、接続されたツールをまとめるもの」と説明しており、Git レイヤーが保存するのはこれらのファイルです。Computer はあなたに代わってこれらを作成・更新でき、編集権限を持つプロジェクトメンバーはこれらをアップロードおよび削除できます。

各エージェントは独自のコピーで作業します。「各エージェントは独自の隔離されたサンドボックスを持っています。」その内部で、エージェントはローカルのチェックアウトを使用して作業し、「エージェントによって行われた意味のある作業の単位ごとに、変更をコミットとして送信します。」サンドボックスは一時的なものであり、ストレージは永続的であるため、クラッシュによる損失はほとんどありません。「サンドボックスがクラッシュした場合、送信されていない作業のみが危険にさらされます。」

2つのエージェントが同時に編集できます。Git サービスは最後に承認されたコミットを追跡し、「送信を受け取ると、その送信がそのヘッドに基づいて構築されている場合にのみ承認します。」別のエージェントが先に到達していた場合、遅れたエージェントは stale-base（古いベース）の応答を受け取り、「新しいヘッドの上に変更をリプレイして再送信」する必要があります。Perplexity の要約：「この設計により、並行するエージェントが互いに黙って上書きし合うことがなくなります」。

エージェントはまた、開発者のようにプロジェクトを読み取ります。「エージェントは、標準的なファイルシステムツールを使用して、サンドボックスにロードされたリポジトリのバージョンを探索」し、固定された検索パイプラインを実行するのではなく、フォルダをリストアップしてファイル内容を検索します。これには実用的な影響があります。明確な見出しを持つ明確に命名されたファイルは、長いセッションに埋もれた同じ事実よりも、エージェントが見つけやすくなります。

ヘルプセンターはスペースのサイズを規定しています。「すべての Project は最大 10,000 個のファイルと合計 5 GB のストレージを保持でき、各ファイルは最大 100 MB です。」2026年8月より前に作成されたプロジェクトは、すでにそのストレージ制限を超えている可能性があります。それらは引き続き機能しますが、新しいファイルをアップロードすることはできません。

承認されたすべての変更が記録されます。「承認された書き込みごとに、リポジトリ、新しいコミット、変更を行ったユーザー、および変更されたパスをリストしたログであるアウトボックスにエントリが追加されます。」これが、実際に「誰が何を変更したか」という追跡可能性の要件です。

ただし、履歴は無制限ではありません。Perplexity はこれについて率直に述べています。「コンパクション（Compaction）は、リポジトリのサイズを制限しながら、最近の履歴を利用可能な状態に保ちます。」送信後、Git サービスはリポジトリのコンパクションが必要かどうかを確認し、「保持されているコミットの数がしきい値を超えると、Git サービスは最新のコミットの小さなセットのみを保持します。古い履歴は単一の開始スナップショットに置き換えられ、最近のコミットがリプレイされてコミット識別子が更新されます。」

ファイル自体はこれによって影響を受けません。投稿の図には「新しいヘッドは同じファイルを保持する」と記されています。変わるのは、どこまで遡って確認できるかです。保持期間を超えると、誰がどのファイルを変更したかという段階的な記録はスナップショットに折りたたまれます。投稿ではこのしきい値は公開されていません。

また、インフラストラクチャとインターフェースの間にも違いがあります。投稿では、履歴はユーザーが表示してロールバックできるべきものとして説明されています。Perplexity の Projects に関するヘルプセンターの記事では、ファイル、制限、共有、Brain について説明されていますが、プロジェクトファイルのバージョン履歴ビューや復元ボタンについては説明されていません。これらがドキュメント化されるまでは、履歴は閲覧可能なアーカイブではなく、Perplexity の安全メカニズムとして扱ってください。

実用的な解釈：リポジトリは現在のファイルのための信頼できる場所であり、履歴は短期的な保護です。チームが何かを決定した理由の記録は、コミットログではなくファイルに属します。バージョン管理されたメモリの一般的なケースについては、AI メモリのすべての変更に履歴が必要な理由をご覧ください。

ここで、Git という枠組みが誤解を招く可能性があります。Project における Computer の回答を形成するいくつかのコンテキストは、プロジェクトファイルではまったくありません。

ドキュメントから解析されたテキスト

PDF や Office ファイルを追加すると、バックグラウンドのパーサーがそのテキストを抽出します。「解析された出力はリポジトリの外部にあり、ソースドキュメントのハッシュをキーとするストアに保存されます。これらのアーティファクトがリポジトリにコミットされることはありません」。エージェントはチェックアウトと同時に解析されたテキストを受け取り、「PDF などのドキュメントの場合、エージェントはまず解析されたテキストを読み取り、必要な場合にのみソースファイルをダウンロードします。」

投稿では、「解析は非同期で行われる」と付け加えられており、エージェントのチェックアウト時ではなくバックグラウンドで実行されます。Computer が大きなドキュメント内の何かを見落としているように見える場合は、Perplexity がアップロードされたファイルを忘れる理由に関するガイドで一般的な原因を確認してください。

Brain のメモリ

Brain は、人々がプロジェクトと一緒に保存されていると最も想定しがちな部分です。しかし、投稿では次のように述べられています。「Computer のナレッジ wiki である Perplexity Brain は、独自の履歴とポリシーを持つナレッジリポジトリにメモリを保存します。ナレッジをプロジェクトファイルと分離しておくことで、バックグラウンドでのメモリ更新がそれらのファイルへの編集と競合しなくなります。両方を必要とするセッションは、両方のリポジトリをロードします。」

つまり、Project のメモリと Project のファイルは、一緒にロードされる2つのストアです。バックグラウンドエージェントがメモリ側を維持します。彼らは「既存のナレッジを読み取り、新しい情報を組み込み、更新されたページをコミットとして保存」します。

ヘルプセンターでは、Brain を2つのコンテキストで説明しており、これらを区別しておく価値があります。アカウントレベルでは、Brain は「Computer を使用している Max および Enterprise Max サブスクライバー向けにリサーチプレビューとして展開中」であり、「Brain はあなた自身の活動からのみ学習します。他人のデータを取得することはなく、シークレットセッションは完全に無視します。」Project 内部では、Perplexity の Memory に関する記事で共有レイヤーについて説明されています。「プロジェクト内の全員が同じ Brain を見ます。これは wiki です。共同編集者は編集でき、閲覧者は閲覧でき、プロジェクトオーナーがメモリの切り替えを制御します。」さらに、「Brain は Computer セッションでのみ利用可能です。検索は Brain にアクセスしません」と付け加えられています。

これには2つの結果が伴います。Brain のエントリは編集可能であり、これは良いことです。「各エントリはソースにリンクしているため、確認や修正が可能です。」また、Brain は実行ごと「何が古いかをマーク」し続けるため、固定された記録ではなく、変化する実用的なモデルです。請求はオーナーに従います。「自動 Brain 更新は、Project オーナーのクレジットを使用します。」

個人メモリ

あなた自身のメモリは3つ目のストアであり、それが Project に適用されるかどうかは設定に依存します。Projects の記事では、オーナー専用のコントロールである「セッション作成者のメモリを使用する（Use session creator's memory）」について説明されており、これによりクエリが「セッションを開始した人の個人メモリから取得」できるかどうかが決定されます。Memory の記事では、その効果が明確に示されています。「これがオンの場合、プロジェクト内の各セッションは、そのセッションを開始した人の個人メモリも利用します。オフの場合、プロジェクト内のセッションは共有の Brain のみを使用します。」

これがどのように機能するかはプランによって異なります。個人アカウントでは、「Project に他のメンバーが加わると、メンバーの個人メモリは使用できなくなります。」Enterprise プランでは、「組織のメモリ設定で禁止されていない限り、共有 Project で個人メモリを使用できます。」そこでは、同じ Project 内で同じ質問をしている2人のチームメイトが、誰がセッションを開始したかに応じて、異なるコンテキストを受け取る可能性があります。

Enterprise のメモリに関する記事では、これを異なる表現（「このプロジェクトで個人セッションを参照する（Reference personal sessions in this project）」オプション）で説明しており、Project 内部で記録されたメモリは「その Project にスコープされ、グローバルメモリには流れません」と記されています。Enterprise をご利用の場合は、Project の設定にどのコントロールが表示されているかを確認してください。

コネクタからのファイル

接続されたアプリから取り込んだファイルは、元のファイルとリンクされたままにはなりません。「接続されたソースから追加したファイルは、1回限りのコピーです。接続されたアプリでオリジナルを更新または削除しても、Project 内のコピーは変更されません。」ヘルプセンターでは、コネクタを介して Perplexity に最新バージョンを取得させるか、ファイルを再度追加することを推奨しています。

履歴が完全なアーカイブであると仮定すること。 コンパクションは古いコミットを1つのスナップショットに折りたたみます。現在のファイルは残りますが、誰が何をいつ変更したかという長期的な記録は残りません。

Brain がプロジェクトファイル内に存在すると仮定すること。 それは、ファイルと一緒にロードされる別のナレッジリポジトリです。

共有 Project 内の全員が同じ回答を得られると仮定すること。 Enterprise では、セッション作成者のメモリがオンになっている場合、各セッションは異なる人のメモリを利用できます。

コネクタがファイルを最新の状態に保つと仮定すること。 コネクタファイルは1回限り作成されるコピーです。

ステップ 1: チームが依存する決定事項をプロジェクトファイルに保存する

Project 内の全員にとって真実であり続ける必要があるものは、セッションに残すのではなく、Project 内 of ファイルに書き込んでください。決定事項、決定日時、決定者、およびその理由を記載した、短い決定事項ファイルを1つ作成します。フォルダを検索するエージェントが見つけられるよう、明確な名前を付けたプレーンな Markdown で保存します。

Project の指示（instructions）は、調査結果ではなく、Computer がどのように動作すべきかのために使用してください。ヘルプセンターでは「最大 8,000 文字」の指示が許可されており、「好ましい回答形式や、更新し続けるステータスファイル」などの用途が提案されています。ステータスファイルは、まさにリポジトリに属する種類のものです。

ステップ 2: Brain と個人メモリが Project に何を追加しているかを確認する

プランに Brain が含まれている場合は、Brain タブ、または新しいレイアウトの「Sources > Brain」を開き、現在保持されている内容を確認します。誤りがあれば修正してください。ヘルプセンターによると、修正内容は次回の実行に反映されます。次に、Project の Memory 設定を確認します。Brain は自動または手動で更新されていますか？また、セッション作成者のメモリはオンになっていますか？

Enterprise で Project が共有されており、チーム全体で回答の一貫性を保つ必要がある場合は、セッション作成者のメモリをオフにすることを検討してください。これにより、すべてのセッションが同じ共有 Brain と同じファイルから動作するようになります。これは判断の分かれるところです。主に1人で使用する Project では、個人メモリが役立つ場合があります。

ステップ 3: コネクタのコピーを更新し、理由の記録をコミットログの外部に保持する

コネクタから取得した Project 内のファイルをリストアップし、どれを最新の状態に保つ必要があるかを決定します。ソースが変更されたときにそれらを再追加するか、依存する前に Perplexity に最新バージョンを取得するよう依頼してください。

そして、重要な決定の背後にある理由を、保持コミットの期間に依存しない場所に保管してください。Project 内部では、決定事項ファイルがこの役割を果たします。複数の Projects やツールにまたがって必要なコンテキストについては、別のストアを使用する方が適しています。古い Perplexity の作業を同時に整理している場合は、Perplexity のチャット履歴を移行するためのガイドでエクスポート方法を説明しています。

Project のファイル、履歴、Brain はすべて Perplexity の内部に存在し、各 Project は独自のスペースです。1つの Project よりも長生きする決定事項には、独自のホームが必要です。MemoryLake は、それらをあなたが管理する1つのリストに保持し、Perplexity や他のアシスタントから利用できるようにするためのメモリレイヤーです。

エントリはあなた自身が自分の言葉で書き込みます。Perplexity の Projects、Brain、個人メモリ、またはベンダーのストアから何かが読み取られたり、書き込まれたり、削除されたりすることはありません。Project にクライアントや会社の業務が含まれている場合は、詳細を他の場所にコピーする前に組織のポリシーを確認してください。

ステップ 1: API キーを作成する

サインインし、ダッシュボードからキーを生成します。このキーは MemoryLake ワークスペースに属し、Perplexity アカウントとは別個のものです。

ステップ 2: 最初のメモリをアップロードする

Project の決定事項ファイルから始めましょう。1つのエントリに1つの決定事項を記載し、日付、理由、およびそれが由来する Project を含めます。

ステップ 3: AI とエージェントを接続する

使用しているアシスタントを接続します。これにより、1つの Project の Brain や履歴に依存することなく、新しい Perplexity Project や他のツールで同じ決定事項を利用できるようになります。

最初の違いは、何に依存できるかを知ることです。Project 内の現在のファイルは耐久性があり、黙って上書きされることから保護されています。その背後にある履歴は短期的なものです。

2つ目は、共同作業における予期せぬ事態が減ることです。Brain と個人メモリが別々のストアであることを知っていれば、あるチームメイトのセッションが知っていたことを、別のチームメイトのセッションが知らなかった理由を説明しやすくなります。同様の分離は他の場所でも見られます。Claude Code Projects もプロジェクトメモリをリポジトリとは別に保持しており、Devin のメモリは独自の Git リポジトリに存在します。

決定事項をファイルに書き込む。 セッションや履歴は記録ではありません。

定期的に Brain を確認する。 ソースを確認しながらエントリを修正します。

Project ごとに個人メモリの使用を決定する。 共有 Project ではオフにする必要がある場合が多いです。

コネクタファイルを更新する。 これらは1回限り作成されるコピーです。

ストレージ制限に注意する。 制限を超えた古い Project には新しいアップロードができません。

Project 間のナレッジは別の場所に保管する。 各 Project は独自のスペースです。古い Spaces のコンテンツでも同様の問題が発生します。詳細は Perplexity が Spaces のコンテンツを忘れることに関するガイドで説明しています。

Perplexity の10月12日の投稿は、すべての Project が Git リポジトリによって支えられていることを裏付けています。エージェントは独自のサンドボックスからコミットし、他の変更と衝突した変更は、黙って上書きされるのではなくリプレイされ、承認されたすべての変更は誰がそれを行ったかとともにログに記録されます。

2つの重要な条件があります。履歴はしきい値を超えるとコンパクションされ、古いコミットは単一のスナップショットに折りたたまれます。そして、解析されたドキュメントテキスト、Brain のナレッジリポジトリ、個人メモリ、コネクタコピーのオリジナルなど、いくつかの種類のコンテキストはリポジトリの外部に存在します。

リポジトリを現在のファイルのためのホームとして扱い、決定事項をそれらのファイルに書き込み、将来必要となる推論プロセスはコンパクション処理が及ばない場所に保管してください。