Perplexityが発表したPortable Computerは、同社のエージェント型Computerプラットフォームを、NVIDIAのDGX Spark上でローカル実行できるようにした製品です。単なる「手元で動くチャットAI」ではなく、エージェントを動かすためのハーネス、オーケストレーター、プランナー、ツールルーター、後処理済みモデルまでを、ひとまとまりのシステムとして端末内に載せる点が特徴です。企業利用で問題になりやすいデータの持ち出し、クラウド推論の従量課金、ツール連携時の制御といった論点に、かなり正面から向き合った設計だといえます。



原文が強調しているのは、すべてのタスクがまず手元のデバイス上で始まることです。ローカルモデルで処理できるステップにはトークン単位の追加料金がかからず、必要な場合にだけクラウド側の高性能モデルへ相談する仕組みになっています。この「必要な場合にだけ外へ出す」という設計は、クラウドAIの利便性とオンプレミスに近い統制を両立しようとするものです。

日本の読者向けに補足すると、DGX SparkはNVIDIAのAIワークロード向け小型コンピューティング環境であり、一般的なノートPCや標準的なオフィスPCで気軽に使う製品ではありません。つまりPortable Computerは、生成AIを業務に使いたいすべての企業向けというより、すでに高性能GPU環境を持つ企業や、機密性の高いデータを扱う部門に向けた選択肢として見るべきです。

原文は、Portable Computerが出荷済みソフトウェアであり、プレビュー版ではないと説明しています。ただし、導入には明確なハードウェア要件があります。GB10クラスのマシン、または24GB以上のVRAMを備えたRTX GPU搭載環境が必要で、企業が既にNVIDIAワークステーションを保有している場合に現実的な選択肢になります。一般的な中小企業がすぐに導入するには、機材そのものが参入コストになるという指摘も原文にあります。



想定される企業層としては、大企業、中堅企業のAI活用部門、資金力のあるAIネイティブなスタートアップが挙げられています。用途としては、金融、法務、医療、政府・防衛、知的財産を多く扱うエンジニアリング領域など、クラウド推論にデータを出すことが契約上または規制上難しい分野が中心です。日本でも、個人情報、営業秘密、研究開発文書、契約書、ソースコードを扱う業務では、クラウドAIに何を送ってよいのかという判断が常に問題になります。

Portable Computerが狙うのは、こうした「AIは使いたいが、データを簡単には外に出せない」領域です。原文では、文書群にまたがる手数料や開示内容のレビュー、個人情報を含む可能性がある調査、リポジトリ規模の移行、ローカル文書コーパスの一括要約、Slackまでつながるプルリクエストのトリアージなどが用途例として示されています。いずれも、単発のチャット回答ではなく、複数のファイルやツールをまたいで作業する「業務エージェント」的な使い方です。

Portable Computerの重要な点は、ローカルLLMだけを提供しているわけではないことです。原文は、ローカルモデル、推論エンジン、エージェントハーネス、ツールサンドボックス、アプリコネクターが一体のシステムとして提供されると説明しています。通常、企業がローカルAIエージェントを作ろうとすると、推論サーバーを立て、モデルを選び、ツール呼び出しを設計し、権限管理や監査の仕組みを別途組み合わせる必要があります。Portable Computerは、この面倒な配線作業を製品側でまとめようとしているわけです。



利用できるモデルとして、Qwen 3.8 27Bと、Perplexityが自社のハーネス向けに後処理したPPLX 27Bが示されています。さらに、NVIDIA Nemotron 3.5 Lightningというオープンな30B MoEモデルが近日対応予定とされています。MoEはMixture of Expertsの略で、複数の専門的なサブモデルを状況に応じて使い分ける考え方です。原文では、Bring-your-own model、つまり自社で選んだモデルや推論サーバーを持ち込む構成もサポートされるとされています。

ツール実行については、OSが強制するサンドボックス内で行われます。プロセス、ファイルシステムのパス、ネットワークアクセスを制限し、サンドボックスが利用できない場合には、密かに制限を緩めるのではなくツール実行そのものを無効にする設計です。Gmail、Outlook、Slack、GitHubのコネクターもローカルのオーケストレーターを経由します。企業にとっては、この「どのツールに、どの権限で、どこまで触れるのか」を制御できることが、単なる性能以上に重要になります。

Portable Computerはローカルファーストですが、ローカルオンリーではありません。原文で最も設計思想が表れているのは、ライブWebの情報やフロンティアモデル級の推論が必要な場合に、オーケストレーターがいったん停止し、ユーザーに確認を求める点です。つまり、AIエージェントが勝手にクラウドへ情報を送るのではなく、そのステップごとに承認を挟む作りになっています。



クラウド呼び出しの前には、ハーネスが必要な文脈を選び、その内容に対してPII分類器を実行します。PIIはPersonally Identifiable Informationの略で、個人を識別できる情報を指します。そのうえで、端末外へ送られる内容をユーザーに表示し、承認されたステップだけが15以上のクラウドモデルのいずれかへ送られます。リモート側のアドバイザーはテキストによる助言を返すだけで、ローカルファイル、ローカルツール、会話全体へ直接アクセスするわけではないと説明されています。

この設計は、日本企業にとっても理解しやすい利点があります。クラウドAIを業務に使う際、問題になりやすいのは「データを送るか送らないか」という二択だけではありません。実務では、契約書の一部だけならよいのか、個人名を含む部分は除外できるのか、外部モデルに渡した文脈が過剰ではないか、といった細かな判断が必要になります。Portable Computerの承認ゲートは、そうした判断をワークフローに組み込もうとするものです。ただし、最終的に承認するのは人間であり、社内ポリシーや監査ルールの整備は別途必要です。

原文では、ローカルモデルのコンテキスト長に関する現実的な制約にも触れています。Qwen 3.8 27Bは260Kトークンのウィンドウを掲げているものの、約100Kトークンを超えると性能が落ちるとされています。ここでいうコンテキストウィンドウは、モデルが一度に参照できる入力範囲のことです。長い文書や大量のコードを扱う企業用途では、単に「長文対応」と書かれているだけでは不十分で、長く入れたときにも精度が保たれるかが問題になります。



Perplexityはこの制約を避けるため、システムプロンプトとツールセットを小さく保ち、必要な専門スキルをオンデマンドで読み込む設計にしていると原文は説明しています。また、コネクターは大きなMCP定義として露出するのではなく、コンパクトなCLIツールとして扱い、古くなったコンテキストは実行中に圧縮します。MCPはModel Context Protocolの略で、AIモデルと外部ツールやデータソースをつなぐためのプロトコルとして知られていますが、定義が大きくなると、それ自体がコンテキストを圧迫する要因になります。

このあたりは、生成AIエージェントを実運用するうえでの地味だが重要なポイントです。業務AIの失敗は、モデル性能そのものだけでなく、余計なツール定義を詰め込みすぎる、古い文脈が残り続ける、必要なファイルをうまく選べない、といった運用上の設計ミスから起きることがあります。Portable Computerの工夫は、ローカルGPUという限られた計算資源の中で、エージェントに必要な情報だけをできるだけ効率よく渡す方向の設計だと読めます。

原文では複数のベンチマーク結果が紹介されています。Perplexityがオープンソース化を予定しているという53タスクのLocal Knowledge Work Benchでは、深い調査、金融分析、文書作成などを対象に、DGX Spark上でQwen 3.8 27Bを動かしたComputerが82.6%を記録したとされています。同じモデルを使ったオープンソースのPiハーネスは77.6%、Hermesは74.0%で、PerplexityのPPLX 27Bでは85.4%まで上がったとされています。



BrowseCompでは、Computerが66.7%、Piが50.2%、Hermesが43.9%で、Piと比べて処理時間を51%、トークン数を70%削減したと原文は述べています。視覚的な文書理解を測るParseBench-100では、Computerが65.1%、比較対象が34.6%と13.9%だったとされています。これらの結果は、同じモデルでも、ハーネスやツール連携、文脈管理の設計によって業務タスクの成果が変わることを示す材料になります。

最も示唆的なのは、Terminal Bench 2.1のハイブリッド結果です。完全ローカル実行では59.6%で、限界費用は実質ゼロに近い一方、アドバイザーへのエスカレーションを使うと73.0%まで上がり、1回のロールアウトあたり約0.415ドルとされています。Claude Opus 5単独では82.4%、約0.65ドルと比較されています。ここから読めるのは、ローカルとクラウドの組み合わせはフロンティアモデルとの差を縮めるが、完全に埋めるわけではないということです。コスト、統制、性能のどこを重視するかで評価は変わります。

Portable Computerの経済性は、ローカルモデルで処理される作業にトークン単位の追加料金がかからない点にあります。リポジトリ規模の移行や、長い検証ループ、大量文書の一括要約では、クラウド推論の従量課金が積み上がりやすくなります。すでにGPU機材を保有している組織であれば、限界費用を抑えながら長時間のAI処理を回せることは大きな意味を持ちます。ただし、ハードウェア購入費、運用管理、電力、セキュリティ設定、社内サポートのコストが消えるわけではありません。



原文のハードウェア要件では、DGX SparkのインストールにGB10スーパーチップ、128GBメモリ、少なくとも1TBのストレージが必要とされています。Qwen 3.8 27Bのオーケストレーターは3ビット量子化で、ダウンロードサイズは17.4GB、必要RAMは32GBです。Nemotron 3.5 Lightningは4ビット、19GBで、36GBのRAMを必要とします。その他の環境では、DGX OSまたはARM/x64上のUbuntu、24GB以上のVRAMを備えたRTX GPUが必要です。インストールは標準的なaptリポジトリ追加として説明されています。

対応OSはLinuxが先行し、Pro、Max、Enterprise Pro、Enterprise Maxの加入者向けに提供されます。Windows版は9月予定、macOSはロードマップにないと原文は述べています。また、ローンチ時点でサポートされるDGX Sparkは1台のみで、クラスタリングはロードマップ上の項目です。したがって、現時点では大規模な分散処理基盤というより、強力な1台を業務用AIワークステーションとして使う製品と見るのが自然です。

Portable Computerの登場は、生成AI活用の設計が「クラウドAPIをどう呼ぶか」だけではなくなってきたことを示しています。これまで企業AIの議論では、高性能な外部モデルをどう安全に使うかが中心でした。しかし、機密性の高い業務では、そもそも外部送信を最小化し、必要な部分だけを明示承認でクラウドに出すという考え方が重要になります。これは、日本企業が重視する稟議、監査、情報管理の文化とも相性があります。



ただし、Portable Computerを導入すれば自動的に安全になるわけではありません。社内のデータ分類、個人情報の扱い、外部モデル利用時の承認権限、ログ保存、監査証跡、ツールコネクターの権限設計を決める必要があります。特にSlackやGitHub、メールと連携する場合、AIが参照できる範囲を広げすぎると、便利さと引き換えに情報漏えいリスクも高まります。ローカル実行はリスクを減らす手段であって、ガバナンスを不要にするものではありません。

企業が検討するなら、まずはクラウドに出しにくいが自動化効果の高い業務を選ぶのが現実的です。たとえば、社内文書の要約、契約書レビューの下準備、ソースコード移行の調査、過去チケットの分類などです。そのうえで、どの処理を完全ローカルに閉じ、どの処理を承認付きでクラウドに送るのかを明確にします。原文のベンチマークが示すように、ローカル実行は費用面で魅力がある一方、最高性能モデルとの差は残ります。だからこそ、性能が必要なステップだけ外部モデルに相談するハイブリッド設計が、今後の企業AI導入で有力な選択肢になりそうです。