本文へスキップ
KNOWLEDGE — AI NEWS
Perplexity Computer｜AIに渡す権限の線引き
Perplexityが2026年8月6日、AIエージェント「Perplexity Computer」向けの新しいツール群「Computer for Builders」を公式ブログで発表しました。GitHub・Datadog・Stripe・Supabase・Slackに接続し、コードの作成から本番環境の監視、決済の追跡、週次レポートの送信までを1つの対話画面から行えると記載されています。提供対象はComputerを利用するPro・Maxの購読者です。
Summary
この記事の要点
この発表は開発チーム向けの機能ですが、EC事業者にとっても読む価値があります。理由を3つに整理します。
AIの接続先が「決済」と「本番データ」へ広がった
これまでAIエージェントの接続先は、資料・カレンダー・メールといった業務ファイルが中心でした。今回はStripe（決済）とSupabase（データベースに加え認証・ストレージまで含むバックエンド基盤）が正面から入っています。お金と顧客データに触れる領域へ踏み込んだ発表だと読めます。
読み取りだけの機能ではない
Supabaseのテーブル照会は「読み取りクエリ」、GitHubはプルリクエストの作成（人がレビューして反映する形）と記載されています。一方で同じ発表文には、ストレージバケットの管理、エッジ関数の実行、Slackへのメッセージ送信、Vercel経由の本番デプロイ、Stripeでの商品・価格・チェックアウトフローの設定も並んでいます。読み取り専用の製品ではない前提で見る必要があります。
EC事業者が今すぐ導入する対象ではない
接続先はソフトウェア開発の道具立てで、自社で開発を抱えていないEC事業者が明日から使うものではありません。ただし同じ形が受注・在庫・CSの管理画面へ来たときに、何を渡して何を渡さないかは今のうちに決められます。
Basics
前提：エージェント・コネクタ・本番環境とは
今回の発表を読むために必要な用語を先に整理します。すでに把握している方はこの節を飛ばして構いません。
| 用語 | 意味 | 実務での意味合い |
|---|---|---|
| AIエージェント | 指示を受けて、複数の手順を自分で進めるAI。文章を書くだけでなく操作も行う | 「下書きを作る」から「作業を終わらせる」へ役割が変わる。誤りの影響範囲も広がる |
| コネクタ | AIを外部サービスへ接続する仕組み。接続時に許可する操作の範囲を決める | ここで与えた権限がそのままAIにできることの上限になる |
| 本番環境 | 実際の顧客が使っているシステム。試験用の環境と区別する | 本番での誤操作は売上・顧客対応に直結する。試験環境での失敗とは重みが違う |
| 可観測性 | システムの内部状態を外から把握できるようにする仕組み。Datadogはこの領域の製品 | 不具合が起きたときに「どこで何が起きたか」を追えるかどうかを決める |
AIエージェントが商取引に関わってくる流れ全体はエージェンティックコマースで、業務側への組み込み方は生成AIのEC活用で整理しています。
Announcement
公式発表の要点
Perplexityは2026年8月6日、公式ブログでComputer for Buildersを発表しました（出典: Perplexity公式ブログ「Computer for Builders」）。公式に記載されている内容は次のとおりです。
| 項目 | 公式に記載されている内容 |
|---|---|
| 発表日・発表主体 | 2026年8月6日、Perplexity |
| 対象 | 創業者や小規模なエンジニアリングチーム |
| 提供範囲 | Computerを利用するProおよびMaxの購読者 |
| 前提 | Perplexity Computerは2月に公開済み（発表文の表記は「2月」で、年の明記はない）。15を超えるモデルを束ね、タスクごとに最適なものを選ぶと記載 |
| GitHub | リポジトリとコードの調査、プルリクエストの作成とレビュー、issueの検索と管理 |
| Datadog | メトリクスの照会、ログの検索と分析、分散トレース・ダッシュボード・アラートの確認 |
| Stripe | 顧客の照会、支払いとサブスクリプションの確認、請求書・入金・不正シグナルの調査 |
| Supabase | テーブルに対する読み取りクエリ、ユーザーの確認、ストレージバケットの管理、エッジ関数の実行 |
| Slack | チャンネルの検索、メッセージ履歴の読み取り、ワークスペースへのメッセージ送信 |
| その他の接続 | App Connectors経由でGoogle Drive・Google Calendar・Gmailに加え、400を超えるその他のファイルやツールに接続 |
公式ブログには、想定される流れとして「GitHubのissueを読んで不具合をまとめ、再現に必要なデータを取得し、テスト付きのプルリクエストを開き、Vercel経由でデプロイし、Slackへ完了を投稿する」といった例が挙げられています。また定期実行として、毎週月曜に成長レポートをSlackへ自動送信する使い方が示されています。
日本での提供可否、日本語での動作、企業向けの管理機能については、今回の発表文に記載がありません。日本から利用できるかどうかを示す記述は、公式には確認できていません。
Analysis
セルフプラスの見解 — 論点は機能ではなく「権限」
ここからは公式発表を踏まえたセルフプラスの分析で、事実の要約とは分けて記載します。この発表を「開発者向けの話」として読み飛ばすと、次に同じ形が自社の管理画面へ来たときに判断材料がありません。EC事業者が持ち帰るべきは、AIに何をどこまで許すかという線引きの型だと考えています。
1. 決済を見に行くAIは、EC事業者にとって他人事ではない
公式発表でStripeについて挙げられているのは、解約・支払い失敗・不正シグナルの監視です。これは定期購入を運用しているEC事業者が、毎日人手で見ている項目とほぼ同じです。決済の失敗を検知して連絡する、解約の兆候を拾って施策につなげる、といった作業です。今回はStripeという範囲ですが、同種の監視を求める需要はカートの種類を問いません。
ここで重要なのは、こうした作業が「見るだけ」で完結するという点です。決済の状態を読み取って知らせるところまでは、書き込み権限を一切渡さなくても成立します。AIに任せる範囲を検討するとき、最初に切り出すべきはこの読み取りだけの仕事です。CRM設計・リピート施策で扱っている解約率の改善も、まずは状態が見えていることが前提になります。
2. 権限は3段階に分けて考える
AIエージェントの導入で事故が起きるのは、多くの場合「読ませるつもりが書き込めてしまった」ときです。今回の発表では、Supabaseのテーブル照会が読み取りクエリ、GitHubがプルリクエストの作成と書き分けられている一方で、本番デプロイや決済商品の設定までが同じ製品の中に並んでいます。プルリクエストは提案であって反映は人が決めますが、どこまでが提案でどこからが実行かは、使う側が意識しないと区別されません。
自社で検討するときは、次の3段階に仕分けると判断しやすくなります。
| 段階 | AIに許すこと | ECでの例 |
|---|---|---|
| 読み取りのみ | 状態を見て報告する。変更は一切しない | 受注状況の集計、レビューの分類、在庫の推移レポート、決済失敗の一覧化 |
| 提案まで | 変更案を作るが、反映は人が承認する | 商品説明文の改稿案、配信メールの下書き、値付けの候補、FAQの追加案 |
| 実行まで | 変更を反映する。事後に人が確認する | 在庫連動の更新、定型の問い合わせ返信。導入前に取り消し手順を用意する |
実務では、読み取りのみの段階だけでも十分な効果が出る作業がかなりあります。逆に、いきなり実行まで許してしまうと、誤りが顧客に届いてから気づくことになります。AIエージェント一括支援で導入を進めるときも、この段階分けを最初の設計に置いています。
3. 個人情報と決済情報は、線引きの前に確認が要る
読み取りのみであっても、渡す情報の中身は別の論点です。氏名・住所・電話番号・購買履歴は個人情報にあたり、外部サービスへ渡すことは第三者提供や委託の扱いになりえます。カード情報については、そもそも自社で保持していない構成（決済代行側で保持する形）が一般的で、その場合はAIに渡す以前に自社に存在しません。
実務上の順番としては、AIに接続する前に「そのデータは外部へ出してよいか」を確認します。判断が難しい場合は、個人が特定できる項目を除いた集計値だけを扱う設計にすると、多くのケースで問題が小さくなります。たとえば「誰が解約したか」ではなく「今週の解約件数と理由の内訳」であれば、施策の検討には足ります。
4. いま自社のカートでできること
今回発表された接続先はいずれも開発向けで、Shopify・Shopify Plus・ecforceの管理画面に直接つながるものではありません。ただし、同じ考え方で今日から始められる範囲はあります。
| 環境 | 読み取りのみで始めやすいこと | 注意点 |
|---|---|---|
| Shopify／Shopify Plus | 注文・在庫のデータを書き出して、集計や傾向の整理をAIに任せる | 書き出したファイルに顧客の個人情報が含まれていないかを確認してから渡す |
| ecforce | 定期購入の継続率や解約理由の集計をAIに整理させる | 解約理由の自由記述に個人が特定できる記述が混ざることがある |
| 共通 | 問い合わせ内容の分類、レビューの傾向整理、FAQ候補の抽出 | 本文をそのまま渡す場合、氏名・注文番号・連絡先を除いてから渡す |
この発表は、EC事業者向けの製品発表ではありません
Computer for Buildersの対象は創業者と小規模なエンジニアリングチームで、接続先もGitHub・Datadog・Stripe・Supabase・Slackといった開発の道具立てです。自社で開発体制を持たないEC事業者が導入して効果が出る性質のものではなく、本記事もそれを勧めていません。本記事で扱っているのは、AIエージェントに本番環境の権限を渡す形が具体的な製品として出てきたという事実と、そこから読み取れる権限設計の考え方です。また、日本での提供可否や日本語での動作は公式に確認できておらず、利用を検討する場合は自社の契約画面で確認してください。
Action
明日から何をすべきか
Perplexity Computerを契約する必要はありません。3つとも、どのAIツールを選ぶ場合にもそのまま使える準備です。
いまAIに渡している情報を書き出す
社内で使っているAIツールと、そこへ貼り付けている情報を洗い出します。問い合わせ本文、注文データ、レビュー、社内資料のどれが含まれているかを確認します。個人が特定できる項目が入っているものに印を付けます。ここが把握できていない状態で新しいツールを増やすと、どこから漏れたかを追えなくなります。
業務を「読み取り・提案・実行」の3段階に仕分ける
AIに任せたい作業を一覧にし、それぞれがどの段階まで必要かを決めます。読み取りのみで足りる作業から始めると、誤りが顧客へ届く経路がありません。実行まで許す作業には、取り消しの手順と、誰が事後確認するかをセットで決めておきます。
外部へ出せないデータの基準を1枚にまとめる
氏名・住所・連絡先・カード情報・未公開の売上といった項目について、外部サービスへ渡してよいかの基準を書き出します。判断に迷う項目は「集計値なら可、個票は不可」のように条件付きで決めます。1枚あれば、新しいツールが出るたびに議論をやり直さずに済みます。
同じくPerplexityの動きとして、チームでの利用に関する話はPerplexity Projectsの記事で扱っています。業務へのAI組み込み全体は生成AI業務効率化、AIエージェントを前提にしたEC運用の考え方はAIコマースにまとめています。
FAQ
この発表に関するよくあるご質問
Computer for Buildersは日本でも使えますか。
公式発表にはComputerを利用するProおよびMaxの購読者に提供されると記載されていますが、対象地域や日本語での動作についての記載は見当たりません。日本から利用できるかを断定できる情報は確認できていないため、自社の契約画面で確認してください。
EC事業者も導入したほうがよいですか。
今回発表された接続先はGitHubやSupabaseなど開発向けのため、自社で開発体制を持たないEC事業者がすぐ導入する対象ではありません。先に整えるべきは、AIに読ませてよい情報と触らせない情報の線引きを社内で決めることです。
AIエージェントに決済データを見せても問題ありませんか。
扱う情報の種類と契約内容によります。カード情報や氏名・住所を含む顧客データを外部サービスへ渡す場合は、個人情報保護法と各社の利用規約の確認が先です。まず読み取り専用の範囲から始め、書き込みは人の承認を挟む設計をおすすめします。
