Perplexity は 2026 年 10 月 12 日、公式エンジニアリングブログで、Perplexity Computer にすでに搭載されている Projects 機能の土台が、通常の共有フォルダではなく、人とエージェントの協働のために作られた Git リポジトリの仕組みであることを明らかにした。各プロジェクトは 1 つの Git リポジトリに対応し、ユーザーの対話型エージェント、定期実行のエージェント、他の協力者のエージェントが、同じリポジトリへ変更をコミットしていく。新しいモデルの発表ではないが、エージェントが長期の仕事を引き受けるようになったとき避けて通れない問題、つまり成果をどこに保存し、誰が何を変えたのか、誤った変更をどう戻すのかに正面から答えた内容だ。
なぜ Git なのか
Perplexity の理由は実務的だ。数か月にわたる協働には 3 つの条件が要る。成果がセッションを越えて残り、サンドボックスの消滅とともに消えないこと。複数人と複数のエージェントが同時に編集しても、互いの変更を黙って上書きしないこと。そして全ての変更を追跡し、巻き戻せること。これらは Git が数十年にわたって解いてきた問題そのものだ。違いは、従来のコードホスティングが人間のために設計され、レビュー画面やブランチ管理、通知といった要素がエージェントには不要だという点にある。Perplexity は Git の保存と検証の仕組みだけを残した。エージェントは人間の承認を待たず、Git サービスがリポジトリの契約に照らして提出を機械的に検査し、合格したものだけを最新版として受け入れる。競合が起きれば、古い版を土台にした後の提出は明示的に拒否され、そのエージェントは新しい版の上に自分の変更を載せ直して再提出する。本番環境ではこうした拒否は提出全体の 2% 未満で、提出遅延の中央値は 1.7 秒未満、99 パーセンタイルでも 8 秒未満だという。
5 つの部品の役割分担
システムは 5 つで構成される。各エージェントは独立したサンドボックスで動き、内部のコマンドラインツールがリポジトリを手元に同期し、意味のある作業単位ごとに成果をコミットする。コントロールプレーンはリポジトリの所在を探し、短期間だけ有効な認証情報を発行するだけで、データ自体には触れない。Git サービスはクローンや取得、提出の受け付けといった Git 本来の操作を実行し、どの提出を最新のコミットにするかを決める。状態は DynamoDB に記録される。リポジトリのデータ自体は AWS S3Files が提供する共有ファイルシステムに置かれ、サービス側の複製は状態を持たず交換可能に保たれる。コミットが受け入れられると、バックグラウンド処理が変更された文書からテキストとメタデータを抽出し、次にプロジェクトを開いたときエージェントが検索できるようにする。通信量を抑えるため、サンドボックスは最初からリポジトリ全体を落とさない。大きなファイルはまず Git LFS のポインタとして現れ、エージェントは抽出済みテキストを読み、必要なときだけ実ファイルを取る。FUSE を使った仮想ファイルシステムも試したが、ファイル操作の多い作業では約 400 倍遅く、断念したという。履歴も無限には伸びず、保持するコミットが上限を超えると古い履歴は 1 つの開始スナップショットに圧縮される。
数字が示すことと、主張の限界
Perplexity が公表した内部テストは、この設計の狙いをよく表している。同じ文書群に対する金融分野の 150 問で、ファイルを探索しながら答えるエージェントは、正しい文書の検索で 0.867、正答で 0.627 を記録し、意味検索の約 0.39 と 0.37 を上回った。正答は約 1.7 倍で、遅延は約 25% 低い。開いたことのあるプロジェクトへの再接続は約 2.9 秒、初回は約 8 秒だ。Computer の長期記憶である Brain も同じリポジトリ基盤の上にあり、知識ページはプロジェクトファイルと競合しないよう別リポジトリにコミットとして保存される。ただし注意が要る。これらの数字は全て Perplexity の自己測定で、第三者の再現はなく、テスト用文書も同社が選んだものだ。現時点では設計の自己証明と受け取るべきで、業界の結論ではない。それでも方向性には意味がある。エージェントが一回きりの回答から数か月単位の協働へ移るにつれ、競争の焦点はモデルそのものから、作業場の永続性と監査可能性へ移っている。数十年前に人間の協働のために生まれたバージョン管理が、エージェント協働の最速の土台になる——その層を先に固めた側のエージェントほど、長い仕事を任されやすくなるはずだ。
