Perplexity SPACEとは？AIエージェントのセキュリティ基盤とLLMOへの影響

Perplexity SPACEとは？AIエージェントのセキュリティ基盤とLLMOへの影響

この記事の結論: Perplexity SPACE（Sandboxed Platform for Agentic Code Execution）は、Perplexityが2026年7月15日に発表した、エージェント製品「Perplexity Computer」を支える実行基盤である。AWSのオープンソース仮想化技術Firecracker microVMでタスクごとに完全隔離された環境を用意し、セッションの一時停止・再開・分岐、認証情報をサンドボックス外で管理する設計、1分間隔のロールングスナップショットによって、長時間稼働するエージェントタスクを安全に継続できるようにしている。わずか10週間で構築され、発表時点でComputerの本番トラフィックの100%を処理済みだ。技術ニュースとして読み流すべきではない理由は、この基盤が普及するほどユーザーの検索行動が「リンクをクリックする」から「エージェントに代行させる」へ移り、ブランド側は自社情報がエージェントの意思決定プロセスの中でどう扱われるかを管理する必要が出てくる点にある。

最終更新日: 2026年7月27日

はじめに

検索結果一覧からリンクをクリックしてサイトを訪れるという行動そのものが、少しずつ迂回され始めている。Perplexityが2026年2月に発表したエージェント製品「Perplexity Computer」は、ブラウジングや購入代行、フォーム入力といった作業をユーザーに代わって遂行するが、こうしたタスクが数時間から数週間にわたって続く場合、どうやってユーザーの認証情報を守りながら安全に実行させ続けるかという課題が残っていた。その答えとして2026年7月15日にPerplexityが公開したのが、実行基盤「SPACE」である。

本記事執筆時点で、SPACEを扱う日本語の解説記事は検索結果上ほぼ確認できず、情報源は英語圏の一次情報と技術系メディアに限られている。本記事ではその一次情報をもとに、SPACEの技術的な仕組みを整理したうえで、この基盤がなぜLLMO（LLM Optimization、生成AI検索での可視性最適化）に関わる企業にとって無視できないニュースなのかを、エージェンティックコマースの文脈に翻訳して解説する。すでに公開しているPerplexity Computer自体の解説はPerplexity Computerとは？マルチモデルAIエージェントの実像とLLMOへの影響にまとめているため、Computerの機能や提供プランを先に押さえたい場合はそちらを参照してほしい。本記事はComputerを支える「実行基盤」側に焦点を絞る。

Perplexity SPACEとは何か

SPACEは「Sandboxed Platform for Agentic Code Execution」の略で、コードを実行しファイルを編集し複数ステップのタスクを数時間・数日・時には数ヶ月にわたって続けるロングランのAIエージェントを支えるために設計されたランタイムである。ここで重要なのは、SPACEそのものはユーザーが直接操作する機能ではないという点だ。ユーザーが見て使うのはあくまでPerplexity Computerというエージェント製品であり、SPACEはその裏側で「タスクをどこで、どう安全に動かすか」を担う土台にあたる。

Perplexityは2026年6月からComputerの裏側の実行層としてSPACEの展開を始め、公開までに数百万件規模のサンドボックス作成と、数千万件規模の再接続を処理してきたと説明している。エージェントが「検索して答えを返す」だけの存在から、「実際にタスクを完了させるまで動き続ける」存在に変わりつつある今、その裏側を支えるインフラそのものが表舞台のニュースになったという点に、この発表の意味がある。

Firecracker microVMという技術基盤

SPACEの中核にあるのが、AWSがオープンソースとして公開している仮想マシン技術「Firecracker microVM」である。Firecrackerはもともと AWS Lambda や Fargate のようなサーバーレス基盤で、多数のワークロードを厳格に隔離しながら高速に起動するために開発された技術で、通常のVMよりはるかに軽量な一方、コンテナよりも強い隔離境界を提供する。SPACEでは、エージェントが実行する各タスクをこのFirecracker microVM上の独立した環境で動かす設計になっている。

なぜこの技術が選ばれたのか。エージェントが実際にコードを実行しファイルを操作する以上、あるユーザーのタスクが別のユーザーの環境やデータに影響を及ぼさないよう、OSレベルの厳格な隔離が要る。同時に、ユーザーが求めるのは待たされないレスポンスであり、起動に時間がかかる隔離環境では実用に耐えない。Firecracker microVMは、この「強い隔離」と「軽さ・速さ」という本来トレードオフになりやすい二つの要件を両立させる選択肢として採用された。

セッション管理：一時停止・再開・分岐という設計

長時間稼働するエージェントタスクにおいて実務上厄介なのは、「作業の途中でユーザーがブラウザを閉じてしまう」「タスクの一部だけをやり直したい」といった状況だ。SPACEはセッションを「サンドボックス」という単位でグループ化し、一時停止・再開に加えて、あるセッションから枝分かれさせて別の分岐を試す「分岐（フォーク）」実行もサポートしている。

これは、単発のチャットのやり取りとは異なるユーザー体験を前提にした設計だ。従来のブラウザセッションはタブを閉じれば実質的に終わってしまうが、SPACEが支えるエージェントセッションはユーザーが離脱しても状態を保ったまま存在し続け、後で正確に続きから再開できる。購入代行やフォーム入力のような複数ステップのタスクほど、この「セッションが生き続ける」という前提が重要になる。

スナップショットによる状態保存という設計思想

セッションを保持し続けるためには、実行中の状態をどう保存し復元するかという仕組みが要る。SPACEはセッションの状態を最短1分間隔のロールングスナップショットとして記録し、最大1週間分遡って復元できる設計になっている。ファイルシステムの変更を追う通常のディスクスナップショットに加え、稼働中のメモリの状態ごと保存するフルスナップショットも取得しており、クラッシュからの復旧や、任意の時点への巻き戻しにも対応する。

この設計が意味するのは、ユーザーが数日かけて進めていたタスクを一旦離れても、後から正確に同じ状態から再開できるということだ。エージェントに任せるタスクが「その場で完結する短いやり取り」から「長期間にわたって進捗する作業」へと拡張していくほど、こうした状態保存の仕組みは基盤として不可欠になる。

セキュリティ設計：認証情報はサンドボックス内に置かれない

SPACEのセキュリティ設計で最も特徴的なのは、認証情報の扱い方だ。パスワードや鍵といった機微な情報はサンドボックスの中には保存されず、必要になった瞬間だけ外部からサンドボックスに渡される。認証情報の管理そのものはユーザー自身のパスワード・鍵管理システム側にとどまり続ける設計であり、セッションごとに個別管理される。

この「必要な時だけ渡し、常駐させない」という発想は、エージェントに機密性の高いタスクを任せる際の根本的な不安、すなわち「エージェントが自分の認証情報をどこかに保持し続けるのではないか」という懸念に正面から応える設計だと言える。実行環境自体の隔離をFirecracker microVMが担い、認証情報の扱いを別レイヤーで守るという二段構えになっている点が、この基盤の安全性の核にある。

さらに、サンドボックス内に保存されるデータそのものについても、ユーザーが持ち込む暗号鍵で保護する仕組みが用意されており、ユーザー側が鍵を失効させれば、以後どのサンドボックスもそのデータを読み取れなくなるという説明もなされている。実行環境の隔離・認証情報の非常駐化・保存データの暗号鍵管理という三段構えで安全性を積み上げている点が、単なる「隔離環境を用意しました」という発表以上の意味を持たせている部分だ。

わずか10週間の開発、Computerトラフィック100%という稼働実績

Perplexityの説明によれば、SPACEはわずか10週間で構築されたという。発表時点で、Perplexity ComputerにおけるすべてのProduction（本番）トラフィックがすでにこのSPACE基盤上で処理されている。実験段階のインフラではなく、すでに本番の全量を支える基盤として運用されているという事実は、この発表を単なる技術デモではなく、実際に動いているシステムの説明として受け止めるべき根拠になる。

「セキュアな長時間稼働エージェントを5倍高速化」という主張をどう読むか

SPACEの発表を報じた記事の一部は「セキュアな長時間稼働エージェントを5倍高速化した」という趣旨の見出しを掲げている。これはPerplexity側、あるいはそれを報じたメディア側の主張であり、独立した第三者機関によるベンチマーク検証の数字ではないという点は明確にしておく必要がある。

Perplexity自身が公開した情報の中には、サンドボックス作成にかかる時間が本番運用の中で大きく短縮されたという説明が含まれており、5倍という表現はこうした自社計測に基づくものと見られる。もっとも、この数字が具体的にどのベンチマーク条件・どの比較対象に基づくものかを外部が検証できる形では公開されていない。読者としては「Perplexity自身が公表している改善の方向性」として参考にしつつ、独立検証済みの数字と同列に扱わないことが重要だ。技術的な誇張の是非よりも、長時間稼働するエージェントを安全かつ実用的な速度で動かすという課題そのものに、業界の関心が集まり始めているという事実の方に注目する価値がある。

LLMO視点で読み解くPerplexity SPACEの意味

ここまでの内容は純粋にインフラの技術発表だが、LLMOの観点で読み替えると、この発表は単なる裏側の話にとどまらない意味を持つ。

第一に、Perplexity Computerのようなエージェント型のAI検索・購入代行が実用段階に入り、こうした基盤で稼働し続けるほど、ユーザーの行動様式そのものが変わっていく。「検索結果を見てリンクをクリックする」体験から、「エージェントに任せて結果だけ受け取る」体験へのシフトである。この変化が進むほど重要になるのは、自社の商品やサービスがエージェントの意思決定プロセスの中でどう参照され、どう比較され、どう推薦されるか、というエージェンティックコマース時代のLLMO/GEOの視点だ。従来のSEOが「検索結果ページの何位に表示されるか」を問題にしてきたのに対し、この文脈で問われるのは「エージェントが複数の選択肢を比較検討する過程で、自社が候補として俎上に載るかどうか」である。

第二に、こうしたセキュリティ・信頼性基盤が強化されるほど、企業やユーザーがエージェントに決済・予約・比較検討といった機密性の高いタスクを任せる際の心理的なハードルが下がっていく。認証情報を安全に扱う仕組みが整い、セッションが安定して継続できるようになるほど、Perplexity経由のエージェントの行動は、実際の購買行動そのものに近づいていく。つまりブランド側は、自社サイトへの人間の訪問者だけでなく、「エージェントが自社情報をどう取得し、どう扱っているか」に対する可視性を持つ必要が生まれてくる。

第三に、認証情報をサンドボックスの外側で管理するというこの設計は、将来的にエージェントがログインを前提とした会員制ECサイトやサービス内で行動する余地を示唆している。これまでのAI検索対策は主に公開ページの構造化データやコンテンツ品質を対象にしてきたが、会員限定の価格情報や在庫状況、購入手続きの過程そのものが、エージェントの参照対象になっていく可能性がある。会員限定領域のLLMO最適化、すなわち構造化データの整備や、エージェントが安全に読み取れるAPIの公開といった対応が、今後重要性を増していくと考えられる。

第四に、この発表は既存の「AIエージェント」「エージェンティックコマース」関連のニュース、たとえばAP2（Agent Payments Protocol）やMastercard Agent Pay、Visaのエージェント決済対応といった「決済・取引」レイヤーの動きとは異なる切り口を持つ。SPACEが扱うのは決済そのものではなく、エージェントがタスクを安全かつ継続的に実行できるようにする「実行基盤」のレイヤーであり、決済プロトコル群と組み合わさって初めてエージェンティックコマースの全体像が成立する。LLMO担当者としては、決済まわりの動向だけでなく、こうした実行基盤側の進化もあわせて追う必要がある。

日本のブランド企業が今から準備すべきこと

以上を踏まえ、日本のブランド運営者やマーケターが具体的に着手できることを整理する。

1. 公開ページの構造化データ整備を優先する: エージェントが比較検討の材料として参照するのは、まず公開されている価格・在庫・仕様情報である。商品ページのスキーマ構造化やFAQの整備を通じて、エージェントが誤読しにくい形で情報を提示する。
2. 会員限定情報の扱いを見直す: 認証情報がサンドボックス外で管理される設計が普及するほど、ログイン後のページもエージェントの参照対象になっていく可能性がある。会員限定の価格や在庫情報を、将来的にAPIやパートナー連携経由でエージェントに安全に提供できる体制を検討する。たとえば会員ランク別価格やポイント還元率、予約枠の残数といった情報は、現状は人間がログインして初めて確認できる設計になっていることが多いが、こうした情報こそエージェントが比較検討の材料として求める対象になり得る。ログイン後ページのマークアップ整備や、将来的な連携APIの設計を今のうちに検討課題として棚上げしておく価値がある。
3. エージェント経由の参照を計測する仕組みを持つ: 自社ブランドが競合と比べてどの程度AIの回答や比較の中で言及されているかを継続的に確認する。この観点はAI可視性の競合シェアオブボイス分析：測定手順・ツール比較・改善アクション完全ガイドやブランド言及率17%ベンチマーク：AI検索での実測水準と測り方・改善策で扱っている計測手法が参考になる。
4. 決済・取引プロトコル側の動向も並行して追う: エージェンティックコマースはSPACEのような実行基盤と、AP2やMastercard Agent Payのような決済プロトコルの両輪で進む。EC事業者はAP2（Agent Payments Protocol）とは？EC決済の対応と日本事業者の備えやMastercard Agent Pay とは｜EC事業者が今準備すべきこと【2026年】もあわせて確認し、エージェント経由の取引に対応できる体制を準備しておく。
5. 情報の一貫性を担保する: エージェントは複数のページを横断して情報を突き合わせる。価格やスペックの表記がページごとに食い違っていると、エージェントの比較検討の過程で不利に扱われるリスクがある。サイト内の情報整合性を定期的に点検する。

これらはいずれも、SPACEという一つの技術発表に直接反応する話ではなく、Perplexity Computerに代表されるエージェント型AI検索が普及局面に入りつつあるという大きな流れへの備えである。基盤側のセキュリティと信頼性が高まるほど、エージェント経由の行動が実際の商流に近づいていくという前提に立ち、今のうちから準備を進める価値がある。

よくある質問

Q1. Perplexity SPACEとは何ですか?

Perplexityが2026年7月15日に発表した、AIエージェントの長時間タスクを安全に実行するためのサンドボックス型実行基盤です。

正式名称は「Sandboxed Platform for Agentic Code Execution」で、Perplexity Computerというエージェント製品の裏側を支えるインフラにあたります。ユーザーが直接操作する機能ではなく、Computerのタスク実行を陰で支える基盤です。

Q2. Perplexity ComputerとSPACEはどう違うのですか?

Computerはユーザーが使うエージェント製品、SPACEはそのComputerを裏側で動かす実行基盤という関係です。

Computerはブラウジングや購入代行、フォーム入力といったタスクをユーザーに代わって実行する製品であり、ユーザーから見える機能です。一方SPACEは、そのタスクをどの環境で、どう安全に、どれだけ長く継続できるかを担うインフラ層であり、直接操作する対象ではありません。

Q3. Firecracker microVMとは何ですか?

AWSがオープンソースで公開している、軽量かつ高速に起動する仮想マシン技術です。

もともとAWS LambdaやFargateといったサーバーレス基盤の隔離実行を支えるために開発された技術で、通常のVMより軽量でありながら、コンテナよりも強い隔離境界を提供します。SPACEでは各エージェントタスクをこの技術上の独立環境で動かしています。

Q4. なぜAWSのFirecrackerが採用されたのですか?

エージェントがコードを実行する以上、強い隔離と高速な起動の両立が必要だったためです。

あるユーザーのタスクが他のユーザーの環境に影響しないための厳格な隔離が求められる一方、ユーザーを待たせない起動速度も必要です。Firecracker microVMはこの両立を実現できる技術として採用されたと説明されています。

Q5. セッションの一時停止・再開・分岐とは具体的にどんな機能ですか?

エージェントのタスクを離脱後も保持し、後で続きから再開したり、途中から枝分かれさせて試したりできる機能です。

SPACEはセッションを「サンドボックス」単位でグループ化し、一時停止・再開に加えて、あるセッションの状態から分岐して別の実行を試す「フォーク」も可能にしています。長時間タスクの途中でユーザーが離脱しても、状態を保ったまま存在し続ける設計です。

Q6. スナップショットは何のためにありますか?

セッションの状態を定期的に記録し、後から任意の時点に復元できるようにするためです。

SPACEは最短1分間隔でロールングスナップショットを取得し、最大1週間分遡って復元できます。ファイルシステムの変更を追うディスクスナップショットと、稼働中のメモリごと保存するフルスナップショットの両方に対応し、クラッシュ復旧にも使われます。

Q7. 認証情報はどこに保存されるのですか？安全ですか?

パスワードや鍵はサンドボックスの内部には保存されず、必要な瞬間だけ外部から渡される設計です。

認証情報の管理自体はユーザー自身のパスワード・鍵管理システム側にとどまり、セッションごとに個別管理されます。実行環境の隔離をFirecracker microVMが担い、認証情報の扱いを別レイヤーで守るという二段構えになっている点が、セキュリティ設計の核です。

Q8. 「5倍高速化」という主張は信頼できる数字ですか?

Perplexity側・報道側の主張であり、独立した第三者機関によるベンチマーク検証の数字ではありません。

自社の本番運用データに基づく改善の説明である可能性が高いものの、具体的な比較条件が外部から検証できる形では公開されていません。参考情報として受け止めつつ、第三者検証済みの数字と同列には扱わないのが妥当です。

Q9. LLMO担当者はこのニュースをどう受け止めればよいですか?

技術インフラの発表ではなく、エージェント経由の行動が実購買に近づく前触れとして受け止めるべきです。

セキュリティと信頼性の基盤が整うほど、ユーザーや企業がエージェントに機密性の高いタスクを任せる心理的ハードルが下がります。自社の情報がエージェントの比較検討プロセスの中でどう扱われるかという可視性の確保が、今後のLLMO対応で重要になります。

Q10. 日本企業は今から何を準備すべきですか?

公開ページの構造化データ整備と、エージェント経由の参照状況を計測する体制づくりから始めるのが現実的です。

あわせて会員限定情報の将来的なAPI公開の検討や、AP2・Mastercard Agent Payといった決済プロトコル側の動向確認、サイト内の情報整合性の点検も、エージェンティックコマース普及に備える具体的な準備として挙げられます。

関連用語

• llmo
• geo
• structured-data
• brand-mention
• llms-txt

関連記事

• AI検索対策完全ガイド｜ChatGPT/Perplexity/Gemini/Claude/AI Overview 統合戦略【2026年版】
• Perplexity Computerとは？マルチモデルAIエージェントの実像とLLMOへの影響
• Perplexity Personal Computerとは？LLMO引用への影響と対策を解説
• Perplexity Cometブラウザエージェント対策｜引用と訪問を勝ち取る2026年実務ガイド
• AP2（Agent Payments Protocol）とは？EC決済の対応と日本事業者の備え
• Mastercard Agent Pay とは｜EC事業者が今準備すべきこと【2026年】
• AI可視性の競合シェアオブボイス分析：測定手順・ツール比較・改善アクション完全ガイド
• ブランド言及率17%ベンチマーク：AI検索での実測水準と測り方・改善策