Perplexityが発表した企業向けAIエージェント「Computer for Enterprise」は、単なる“社内検索”や“チャットボット”の延長ではありません。Slackを起点に、社内外データと複数AIモデルを束ねて「仕事そのものを完了させる」設計に踏み込み、MicrosoftやSalesforceが築いてきた業務アプリの主戦場へ正面から入りにいくプロダクトです。本稿では、仕組み・導入設計・現場インパクトから、差別化とリスク、価格とセキュリティまでをB2B視点で整理します。
Computer for Enterprise登場：検索企業からMicrosoft・Salesforceの競合へ
PerplexityはAI検索の文脈で語られることが多い企業ですが、「Computer」を企業向けに展開したことで立ち位置が変わります。狙いは“検索の置き換え”ではなく、既存の業務ソフトウェア群（Microsoft 365/Copilot、Salesforce/Einstein、Google Workspace、各種レガシーSaaS）の上に乗る実行レイヤーになることです。
背景には、消費者向けにComputerを公開してから短期間で「ダッシュボード作成」「マーケツール群の代替」「複雑な業務自動化」といったデモが拡散し、企業からアクセス要望が殺到したという“バイラルな需要検証”があります。Perplexity側も、社内での生産性向上が過去最大級だったと述べており、企業展開は機能追加というより事業ドメインの拡張に近い動きです。
重要なのは、Computerが「答えるAI」ではなく「成果物を作り、手順を進め、次のアクションまでつなぐAI」として設計されている点です。ここに到達すると競合は検索エンジンではなく、業務の入口を握るプラットフォーム企業になります。
仕組みの要点：20種モデルを束ねるオーケストレーションとVM分離
Computerの中核はオーケストレーション（指揮・分解・割り当て）です。ユーザーが「今夜の会食参加企業のブリーフを、WebとSlackとメールとNotionから集めて作って」など目的を自然言語で渡すと、Computerがタスクを分解し、サブエージェントに委任し、調査・推論・生成・ファイル化までをまとめて返します。セッションをまたいだ文脈保持も前提に置かれています。
特徴的なのは、単一モデル前提ではなく、複数プロバイダーの約20モデルを用途で使い分ける“マルチモデル戦略”です。主推論にAnthropic系、深い調査にGoogle系、速度重視にxAI系、長文コンテキストや検索にOpenAI系、画像・動画生成に専用モデル、といった具合に最適配分する思想で、企業側から見れば「ベンダーロックインを避けつつ、タスクごとに性能を取りにいく」構造です。
加えて企業利用で重要になるのが分離設計です。各ComputerセッションはFirecrackerベースのマイクロVMで隔離され、他ユーザーのデータや本番環境へ横断的にアクセスできない前提を作っています。AIエージェントは“外部コネクタを通じて社内データに触れる”ため、アーキテクチャ段階で分離・権限・監査を組み込むことが、導入可否を左右します。
- 目的入力→タスク分解→サブエージェント委任→成果物生成までを一気通貫
- 約20モデルを状況に応じて自動ルーティング（モデル非依存）
- セッション単位のマイクロVM隔離でデータ境界を明確化
業務に埋め込む導入設計：Slack起点の普及と主要コネクタ（Snowflake等）
企業導入で効くのは「どこで使わせるか」です。Computer for EnterpriseはSlack内で@computerとして呼び出せ、チャンネルやスレッドでの対話を起点に、そのままWebやモバイルへ継続できます。これは“新しいツールを開かせる”のではなく、“すでに開いている場所に埋め込む”設計で、導入の摩擦を下げます。
さらにSlack起点には普及メカニズムがあります。共有チャンネルでのやり取りが可視化されることで、同僚の使い方がそのまま学習素材になり、トレーニング資料より強い「周囲からの観察によるオンボーディング」が起きやすい。Perplexity自身、Computerが社内Slackボットとして生まれ、部門横断で使い方が伝播したことを成功要因として強調しています。
業務接続の要はコネクタです。既存の100以上の連携に加え、企業向けとしてSnowflake、Datadog、Salesforce、SharePoint、HubSpotなどのビジネスコネクタが前面に出ています。加えてModel Context Protocolにより、管理者がカスタムコネクタを追加できる余地も用意されており、標準連携にない社内システムへ接続する“最後の1マイル”を埋めにいく構えです。
- Slackで呼び出し→スレッドで共有→Web/モバイルへ継続の導線
- 主要コネクタ：Snowflake、Datadog、Salesforce、SharePoint、HubSpot
- カスタムコネクタ（Model Context Protocol）で拡張可能
現場インパクト：非エンジニアが自然言語でデータ活用・ワークフロー自動化
現場で最も破壊力が出やすいのは「ボトルネックの解消」です。典型はデータ活用で、SnowflakeのようなDWHに対して、非エンジニアが自然言語で質問し、必要な集計・分析を即時に得られると、SQL作成待ちやダッシュボード改修待ちが減ります。経営層や営業、企画が“思いついた瞬間に検証できる”状態は、意思決定速度を変えます。
もう一つは、複数部門・複数手順をまたぐ業務の短縮です。従来は「Slackで聞く→誰かが探す→別ツールで抽出→資料化→レビュー」という多段の流れが、Computerへの依頼で2〜3ステップに圧縮される。ここで価値になるのは“回答”ではなく、“次の業務が進む形で返る成果物”です。ブリーフ、提案書の下書き、監査支援の整理、サポートチケットのトリアージなど、テンプレート化されたワークフローが用意されている点も、現場適用を早めます。
結果として、AI活用が一部のデータチームや情シスの専売特許でなくなり、業務部門が自走しやすくなります。一方で、現場が自走できるほど、権限設計・共有範囲・ログ監査の重要度も上がるため、利便性と統制を同時に設計する必要があります。
- 自然言語→DWH/監視基盤→分析結果までの時間短縮
- 部門横断の“人待ち・手順待ち”をエージェントで圧縮
- 成果物（資料・ファイル・要約・次アクション）として返る設計
差別化とリスク：単一ベンダー対抗、API依存・ガバナンス課題
差別化の核は「単一ベンダーのAIスタックに閉じない」ことです。MicrosoftはM365内の文脈とCopilotを武器にし、SalesforceはCRM上のデータと業務プロセスを握ります。これに対しPerplexityは、複数モデルと多数コネクタを束ねる“横串レイヤー”として、既存スタックの上で価値を出す戦略を取ります。モデル利用比率が特定2モデルへの集中から分散へ移ったというデータは、マルチモデルの実需を示唆します。
ただしリスクも構造的です。第一にAPI依存です。基盤モデル提供者（Anthropic、Google、OpenAI、xAIなど）は協力者であると同時に競合でもあり、API条件変更・価格改定・優先度低下が起きれば、オーケストレーションの優位性が揺らぎます。第二に、モデルがコモディティ化して差が縮まると「切り替え価値」が薄れ、オーケストレーション層の差別化はコネクタ品質・運用統制・UXに寄っていきます。
第三にガバナンスです。Slackの共有チャンネルで使えることは普及に効く一方、情報の取り扱いを誤ると漏えい・過共有につながります。管理者がコネクタの利用権限、共有/プライベート実行、監査ログを設計し、部門ごとのデータ分類と運用ルールを整備することが前提になります。
- 強み：マルチモデル＋多コネクタで“最適な組み合わせ”を提供
- 懸念：外部モデルAPIへの依存（価格・制限・品質変動）
- 課題：Slack普及と情報統制のトレードオフ（権限・共有範囲）
価格と導入判断：従量課金のROI、セキュリティ/信頼（SOC2・監査ログ等）
価格は従量課金（クレジット）を軸にした設計で、組織全体のクレジットプールを管理者が配賦し、超過分を追加購入するモデルです。タスクによって計算コストが大きく変動する（テキスト生成と動画生成では桁が違う）ため、席課金より合理的という主張は理解できます。ROIは「人の時間の削減」と「待ち時間の圧縮」で算定しやすく、例えば数時間かかる調査・資料化が数分に短縮されるなら、少額の推論コストは投資として成立しやすい。
一方、調達・経理の観点では“予測可能性”が論点になります。Slack起点で利用が爆発すると、想定外にクレジット消費が増え、現場は便利でもコスト管理が追いつかない事態が起こり得ます。導入時は、部門別上限、ユースケース別の推奨プロンプト、重い処理（動画等）の利用制限など、運用設計とセットで進めるべきです。
最後に最大の壁は信頼です。設立の浅い企業が、Snowflakeの機密データや契約書、顧客情報に触れる経路になるため、セキュリティ要件が厳しく問われます。Computer for EnterpriseはSOC 2 Type II、SSO/SAML、SCIM、細かな管理者権限、監査ログ、ゼロデータ保持オプションなどを用意し、企業の統制要件に寄せています。導入判断では、技術要件だけでなく「監査で説明できるか」「データがどこへ流れるか（モデルへの送信範囲）」「ログが誰に見えるか」を具体で確認する必要があります。
- 従量課金はROIに直結しやすいが、予算統制の設計が必須
- SOC 2 Type II、監査ログ、SSO/SCIM、ゼロデータ保持などが評価軸
- モデルへのデータ送信範囲・保持・権限境界を監査目線で確認
Computer for Enterpriseは、AIを“業務の外側の便利ツール”から“業務の中で手を動かす実行主体”へ引き上げる提案です。Slackという分配チャネル、Snowflake等のコネクタ、マルチモデルのオーケストレーション、VM隔離と監査ログによる統制を組み合わせ、MicrosoftやSalesforceが押さえてきた業務導線に割り込もうとしています。
導入を検討する企業は、まず「待ちが発生している業務」（データ抽出、一次調査、提案書作成、監査準備、サポート分類など）に絞って小さく始め、Slackでの共有範囲と権限、コネクタ接続、監査ログ運用、クレジット上限をセットで設計するのが現実解です。成果が出れば横展開は速い一方、速く広がるほどガバナンスとコスト管理が難しくなる。そこまで含めて“業務に埋め込むAIエージェント”として評価することが、Computer導入の成否を分けます。
