Mac版Perplexity Computer、完全ローカルAIを追加。クラウドアクセスは任意に
Perplexityによると、Mac版Perplexity Computerは完全ローカル動作に対応し、クラウドでの推論を必要とせず、モデルとエージェントをコンピューター上で実行できるようになった。この発表により、機密性の高い作業をどこで行えるかが変わる。また、ユーザーが理解すべき区別も生じる。ローカルファイルへのアクセスと、そのファイルをローカルで処理することは別の機能だ。
Perplexityは、新モードでは対応するAppleシリコン搭載Mac上で、タスク計画、推論、ファイル処理を維持するとしている。ユーザーの許可があれば、クラウド支援も引き続き利用できる。これにより、中心的な選択は「デスクトップかWebか」よりも具体的になる。ユーザーは、タスクを自分のマシン内にとどめるか、リモートサービスを利用するかを選べる。
Appleは、Apple Intelligence向けにオンデバイスモデルとサーバーモデルを別々に開発しており、有用な比較基準となる。Perplexityはこの実行場所の選択を、行動を計画しツールを使うデスクトップエージェントにもたらす。当面の問いは、ユーザーが求める精度、アプリケーションへのアクセス、監督性を損なわずに、日常的なワークフローのどこまでをローカルで完結できるかだ。
Mac版Perplexity Computerで実際に変わること
この発表は、エージェントの意思決定部分をMacに移し、そこに保存されたファイルへのアクセスを超えるものだ。
Perplexityは完全ローカル動作に関する発表で、モデル、エージェントランタイム、タスク実行をデバイス上で動作させられるとしている。ローカルモデルの選択肢としてQwen 3.6とPPLX Proを挙げている。同社は、対応するAppleシリコン搭載ハードウェアでは少なくとも36 GBのメモリを推奨している。
この推奨には注意を払うべきだ。デスクトップアプリとローカルAIシステムでは、ハードウェアへの要求が異なる。インターフェースをインストールしても、すべてのMacが基盤となるモデルを快適に実行できることにはならない。購入者は、アプリ全般の互換性と完全ローカルモードの要件を区別すべきだ。
Perplexityは、クラウド推論とプライベートな素材のローカル処理を組み合わせるHybrid Computeも維持している。一方、完全ローカルの選択肢では、タスク計画がMac上で始まる。同社によれば、ユーザーはオンライン情報、接続済みアプリケーション、追加の推論のために処理を拡張することを許可できる。
実際の変化は、その拡張を誰が制御するかに関わる。ローカルで始まるタスクには、情報が別のサービスへ到達する前に、明確に理解できる境界が必要だ。インターフェースがその境界をどれほど明示できるかは、モデル選択画面と同じくらい重要になる。
ダウンロード済みのメモ、予算ワークブック、未完成の進捗報告を含む仮想的なプロジェクトレビューを考えてみよう。求められる成果は、それらの資料に基づく正確な下書きだ。ローカルエージェントには、入力を確認し、不整合を調整し、リモート推論なしにレビュー可能な結果を保存する必要がある。
この例は、独自に観測された結果ではなく、約束されている能力を示している。また、チャットボットの回答だけでは証拠として不十分な理由も示す。ワークフローを完了するには、信頼できる読み取り、適切な計画、正しい編集、変更内容の明確な記録が必要になる。
したがって、この発表はより広い評価上の問いを生む。ローカルシステムは、人々がすでに使っているアプリケーション全体で有用な作業を完了できるのか。プロンプトへの回答に成功するモデルは、その課題の一部を乗り越えたにすぎない。
「Wi-Fi不要」という説明に出会った読者にとって、留保は明快だ。オフライン推論は、入力とツールがすでにローカルで利用可能なタスクを支援できる。新たに公開されたWebページを取得したり、切断されたネットワーク経由でメールを配信したりはできない。
初回インストールとモデルのダウンロードも、別の問題だ。セットアップ中に接続を必要とするシステムでも、その後のタスクはオフラインで実行できる。テストでは、インストール、実行、配信を区別のない一連のプロセスとして扱うのではなく、どの段階を測定しているかを特定すべきだ。
ローカルファイルへのアクセスはすでに提供されていた
新たな主張は推論がどこで行われるかに関するものであり、従来のMac版リリースでもローカルアプリケーションとファイルへのアクセスは提供されていた。
Perplexityのデスクトップエージェント公開では、4月にローカル編集、コンピューター操作、Cometブラウジング、音声オーケストレーションが記載されていた。フォルダー整理、メールの下書き、NotesとCalendarでの作業が例として含まれていた。こうした機能は、Mac統合が今回の発表より前から存在していたことを示している。
この履歴が重要なのは、「Mac上で動作する」という表現が複数の構成を指し得るからだ。アプリケーションはローカルでクリック操作を実行しても、そのクリックを選ぶのはリモートモデルである場合がある。ローカルストレージから文書を読んでも、分析のためにその内容を外部へ送信することもある。
インターフェースがメニューバーにあるだけで、どちらの構成も完全ローカルになるわけではない。重要な違いは、タスクの推論がリモートサービスに依存するかどうかだ。この違いが、オフラインテストで何を確認する必要があるかを決める。
ナレッジワーカーにとって、これは利便性と処理場所に対する制御を分けるものだ。便利なアクセスは、アプリケーション間でのコピーを減らす。ローカル推論は別の懸念、すなわち回答やアクションを生み出すために素材がコンピューターを離れる必要があるかどうかに対応する。
この圧力はまず、こうした構成を曖昧にしたメッセージを発するデスクトップエージェントベンダーにかかる。ユーザーが実行場所を選べるようになると、競合製品にも自社のデフォルト設定を説明する必要が生じる。広範なプライバシー表現は、何がどこへ移動するかという具体的な説明よりも情報価値が低くなる。
企業の購入担当者は、関連する文書化の課題にも直面する。アシスタントを評価するチームは、ファイルアクセス、処理場所、外部接続、出力の扱いをそれぞれ別に理解する必要がある。単一の「ローカル」というラベルでは、こうしたすべての問いには答えられない。
これは、組織が既存システムを置き換えるべきだと示すものではない。評価時に尋ねられる質問を変えるものだ。ローカル動作を主張するベンダーは、その主張が成立する条件を説明できるべきだ。
開発者はアプリケーション境界での圧力に直面する。エージェントがローカルで推論できても、有用な文書を確実に確認・更新できなければ、ワークフローは依然として停滞する。アプリケーション統合とモデル能力は、同時に発展する必要がある。
パーソナルナレッジマネジメントにも、関連する区別が見られる。情報を収集しても、それが後で自動的に有用になるわけではない。エージェントが依頼に応じて行動するには、関連性がありアクセス可能な素材が必要だ。処理場所は、この既存の情報課題にさらに要件を加える。
したがって、今回の発表のタイミングは、製品の進展を通じて理解するのが最適だ。PerplexityはすでにComputerをデスクトップへ接続していた。次の主張では推論プロセスもそこへ置き、ユーザーがローカル実行を完全なワークフローとして評価できるようにしている。
ローカルでの制御とクラウドの到達範囲の選択
ローカル動作は作業の既定の場所を変える一方、マシンの外にある情報を必要とするタスクではクラウドアクセスが依然として有用だ。
ローカルタスクには、特定可能な情報境界がある。コンピューター上で既にアクセス可能な文書、メッセージ、その他の素材から作業できる。推論能力がどれほど高くても、その回答はこれらの入力に制限される。
クラウド接続の作業には別の利点がある。最新情報を取り込み、オフラインでは利用できないサービスに到達できる。そのトレードオフには、得られる作業の品質や速度と並んで、その境界を越える情報の扱いが含まれる。
ダウンロード済みのレポートを確認する仮想的なアナリストは、この違いをよく示す。レポートの要約と内部セクションの比較は、閉じたタスクとして維持できる。その前提が現在の出来事となお一致するかを確認するには、外部情報が必要になる。
同じ区別はコミュニケーションにも当てはまる。ローカルで利用可能なやり取りを基に返信を準備することと、その返信を送信することは別だ。特にメッセージにプライベート文書の素材が含まれる場合、有用なインターフェースはその移行を可視化すべきだ。
そのため、ローカルAIを最も適切に捉えるには、接続性を自動的な失敗として扱わないことが重要になる。重要な問いは、外部アクセスが必要か、理解されているか、許可されているかだ。ローカルから始めても、意図的なオンライン手順と共存できる。
Appleは具体的な業界比較を提供する。基盤モデルに関する研究では、約30億パラメーターのローカルモデルを含む、オンデバイスモデルとサーバーモデルを別々に説明している。この研究は、異なる実行環境に合わせて異なるモデルを設計する先例を示している。
Appleのアプローチは、単純な比較に対する注意点も与える。オンデバイス機能向けに設計されたモデルと、アプリケーションを調整するデスクトップエージェントでは、評価上の要求が異なる。ローカル処理への共通した関心は、能力の同等性を示すものではない。
Perplexityの競争上の提案は、ユーザーの作業環境全体でタスクを完了することにある。Appleが公開した研究は、基盤となる実行場所の選択に文脈を与える。どちらの情報源も、それだけで特定のオフィスワークフローをどちらのシステムがより正確に完了するかを示すものではない。
したがって、最も明確な競争は実行アプローチの間にある。すなわち、入力が限定されたローカル推論と、より広い到達範囲を持つクラウド支援の作業だ。個々の製品は両方を提供できる。意味のある比較は、各アプローチが特定のタスクにどれほど適しているかに関わる。
組織にとっては、作業の種類を分けて評価することが示唆される。ダウンロード済み素材の確認、社内文書の下書き、プロジェクトフォルダーの整理には、現在の動向を監視する作業とは異なる要件がある。エージェントの総合スコア1つでは、その差異は隠れてしまう。
ローカルAIは、ハードウェア所有の役割も変える。処理はユーザーが制御するリソースへ移るが、そのリソースには有限のメモリがあり、競合するワークロードもある。評価では、エージェントと並行するコンピューター本来の役割も考慮すべきだ。
許容できる条件の下でより有用な結果を生むなら、クラウド支援は引き続き適切な選択肢となり得る。完全ローカル実行は、ユーザーが意図した境界内で作業を完了する場合に価値を持つ。その価値は、その選択を実用的かつ明示的にすることにある。
エージェントができることは依然として権限で決まる
推論をデバイス上に維持しても処理場所の問題に対応するだけであり、エージェントが行動するには依然として慎重に範囲を定めた権限が必要だ。
PerplexityのMac権限ガイドでは、クリックや入力のためのアクセシビリティアクセス、インターフェースを観察するための画面収録アクセス、ファイルのためのディスクアクセスについて説明している。フォルダーの接続や、機密性の高い操作の承認についても説明している。こうした権限は、処理がローカルにとどまる場合でも重要だ。
各権限は、作業環境の異なる部分を公開する。アプリケーションを閲覧できるエージェントと、その内容を編集できるエージェントでは能力が異なる。評価では、可視性と行動の両方を考慮する必要がある。
アプリケーションをまたぐタスクでは、この違いが特に重要になります。プロジェクトの進捗報告を作成する依頼には、非公開のメモ、スプレッドシート、コミュニケーション用の下書きが関わるかもしれません。そうした入力を読む許可が、結果を公開するための曖昧な指示に転じてはなりません。
ローカルモデルでも依頼を誤解する可能性はあります。古い文書を選んだり、似た名前のファイルを取り違えたり、誤った計算を行ったりすることがあります。モデルをコンピューター上で動かしても、影響の大きい出力を確認する必要性はなくなりません。
セキュリティ上の問いは、意図的な指示の範囲にとどまりません。プロンプトインジェクションは、タスク中に遭遇したコンテンツがエージェントの振る舞いを変更しようとする際に発生します。ローカルに保存された資料にもそのような内容が含まれ得るため、切り離された環境での運用でも、この種のリスクは解消されません。
これは、このリリースに特定の脆弱性があるという指摘ではなく、一般的なリスク評価です。実務上の含意は、処理場所と権限を分けて検討する必要があるということです。非公開の実行環境であっても、エージェントが変更してよい範囲を明確に制限することには利点があります。
たとえば、仮想的なフォルダー整理タスクでは、ファイルを分類することと削除することを区別すべきです。下書き作成タスクでは、文書を保存することと送信することを区別すべきです。こうした境界があれば、結果を確認しやすくなり、誤りも封じ込めやすくなります。
購入を検討する人は、製品が自身の活動をどのように説明するかも確認すべきです。完成した文書だけでは、どの入力が結果に影響したのかが見えない場合があります。作業内容を理解できる形で示すことは、ユーザーが不足している情報源、誤った前提、意図しない編集を特定する助けになります。
ここには使いやすさとの緊張関係があります。頻繁な承認要求は有用な自動化を中断し得る一方、広範な常設権限は重要な操作を見えにくくします。製品は、ユーザーが十分な情報に基づいて判断できる位置にレビューの機会を配置する必要があります。
これは独立したレビュアーに具体的な課題を与えます。権限モデルがタスクに見合っているか、システムが想定された境界で停止するかを検証すべきです。出力が成功したというデモだけでは、こうした問いには答えられません。
ナレッジワーカーにとって、教訓は実践的です。信頼できる実行と理解可能な制御が組み合わされるとき、非公開の処理には価値があります。最も有用な製品は、通常の作業の中でそれらすべての特性を可視化するでしょう。
ハードウェアに関する主張にはワークフローの証拠が必要
モデルがローカルで動作するという証拠だけでは、デスクトップエージェントが実際のタスクを信頼性高く、あるいは効率的に完了できることは示されません。
Perplexityは、ローカル推論への取り組みをより検証可能にする技術的な成果を公開しています。推論とは、学習済みモデルを実行して出力を生成することです。同社の公開されたローカル推論サーバーであるLilyは、対応するAppleハードウェア上で特定のQwenチェックポイントを対象としています。
このリポジトリは、明示的な要件と制限を備えた限定的な実装を文書化しています。ソフトウェアが何を受け付け、どのように動作するかを示しているため、これは有用なエンジニアリング上の証拠です。ただし、消費者向けMacアプリケーションの完全な仕様として扱うべきではありません。
デスクトップエージェントには、推論サーバー以上のものが含まれます。依頼を解釈し、ツールを選び、アプリケーションの状態を扱い、操作が失敗した際に回復する必要があります。1つのコンポーネントにおける性能が、この一連の流れ全体にわたる体験を自動的に予測するわけではありません。
そのため、主な指標としては生成テキストの速度よりもタスク完了のほうが適しています。高速な応答でも、その後に誤った編集が続けば時間の無駄になります。より遅くても、正確でレビュー可能な成果物を生み出す実行のほうが有用な場合があります。
レビュアーは、テストを始める前に成功の条件を定義すべきです。文書タスクでは、指定された事実を保持し、正しい場所に保存することが求められるかもしれません。スプレッドシートのタスクでは、数式が正確で、依頼された範囲外に意図しない変更がないことが必要かもしれません。
ローカル実行とクラウド支援実行を比較する際も、これらの条件は同じに保つべきです。そうしなければ、比較は、より簡単な課題を割り当てられたモードを評価してしまうおそれがあります。同一の入力と期待される出力があれば、結果を解釈できます。
ハードウェアに関する報告にも同様の規律が必要です。有用なレビューでは、タスク中に使用したマシン、利用可能なメモリ、モデルの選択、稼働中の他のアプリケーションを特定します。その文脈がなければ、読者はその体験が自分の環境にも当てはまるかを判断できません。
デスクトップでのデモと並んで、ノートPCでの挙動にも注意を向けるべきです。エージェントの実行中にも通常の作業が快適に反応し続けるかを、読者は知る必要があります。継続的なタスクは、単発の生成成功ではなく、作業セッションとして評価すべきです。
オフラインテストにも、定義された範囲が必要です。セットアップ後に接続を切断すれば、ローカルタスクがリモートの推論を必要とするかは検証できます。しかし、すべての製品機能がオフラインで動作することや、すべてのバックグラウンド活動が把握済みであることを示すものではありません。
ネットワークの観測は、タスク中に試行された接続に関する追加の証拠を提供できます。ただし、アカウント確認、更新、タスク処理はそれぞれ異なる目的を持つため、その証拠の解釈には慎重さが求められます。レビュアーは、裏付けのない説明を付与せず、観測した内容を記述すべきです。
プライバシーに関する主張にも、同じ抑制が必要です。この発表が裏付けるのは、Perplexityがローカルモードについて何をすると述べているかを報じることです。独立した検証には、代表的なタスク、設定、クラウド支援への移行にわたる挙動を調べる必要があります。
最も強い証拠は、正確な出力、理解可能な権限、明示された条件下で再現可能な挙動を組み合わせたものです。そのようなテストが利用可能になるまでは、このリリースは明確な評価手順を伴う、文書化された製品上の主張です。すべてのMacワークフローに対する普遍的な保証ではありません。
ローカルコンピューターがどれほど有用になるかを示す3つの兆候
次に必要な証拠は、オフラインでの完了、可視化されたクラウド移行、対応Macでの再現可能な性能を示すものです。
第1の兆候は、完全なオフラインワークフローに対する独立したテストです。今後数か月にわたり、レビュアーは代表的なタスクについて、入力、期待される結果、生成されたファイルを公開すべきです。それは、もう1本の短いデモよりも強い信頼につながるでしょう。
最も有益なタスクは、エラーを露呈させるだけの複雑さを持つ通常の作業です。矛盾するメモ、改訂された文書、不完全な指示は有用な課題になります。これらは、システムが不確実性を認識するのか、それとも黙って不足を補うのかを明らかにします。
成功した結果は、ローカル実行が自己完結型のチャット応答を超えることを示すでしょう。アプリケーション間の境界で繰り返し失敗するなら、今回のローンチが実用上持つ価値は限定されます。どちらの結果も、ユーザーが適した作業を特定する助けになります。
第2の兆候は、製品がクラウド支援への移行をどのように扱うかです。読者は、外部ステップが必要な理由と、そこでどの情報を使用するのかについて明確な説明があるかに注目すべきです。インターフェースは、タスクの最中に実行方法の選択を理解できるようにすべきです。
その可視性は、ユーザーが処理の境界を制御できるという主張を強めるでしょう。分かりにくい移行や不明確なデフォルトは、それを弱めます。重要なのは、後からシステムの挙動を再構築せずとも、人が十分な情報に基づいて判断できるかどうかです。
これは、混合型のタスクで特に重要です。非公開文書のレビューに続いて最新情報を調べることは、意味のある境界をまたぎます。全体としては1つの連続した依頼に聞こえる場合でも、優れた製品設計はその違いを保つべきです。
第3の兆候は、対応ハードウェアの範囲全体で再現可能な性能です。独立したテストは、開示された条件のもとで、完了品質と作業セッション中の挙動を比較すべきです。高性能なデスクトップでの結果を、すべての対応コンピューターの代表として扱うべきではありません。
一貫した結果が得られれば、チームはこの機能を評価・導入しやすくなります。構成間で大きな差があれば、ハードウェアに関する指針の重要性が増します。どちらの結果も、ローカルAIが到来したという区別のない主張より有用です。
導入は、これらの兆候が交わる点に依存します。ユーザーには、完了する作業、理解できる境界、自分のマシンに適した性能が必要です。1つの領域だけが強くても、体験の重要な部分は未解決のままです。
現時点で、Mac上のPerplexity Computerは実行方法の選択に具体的な変化をもたらします。同社によれば、タスクの推論はローカル入力のそばに留められ、許可された場合にはリモート支援を利用できます。これは、特に文書中心の作業において評価する価値のある重要な機能です。
より広い結論を出す前に、代表的なタスクを選んでください。通常の作業ファイルのコピーを使い、期待する出力を明記し、どの操作にレビューが必要かを決めます。結果を元の資料と比較し、その後、同じ条件で同じ課題を繰り返してください。タスクに最新情報が必要なら、製品がその移行をどのように説明するかを確認してください。評価の全過程で、処理場所、正確性、アプリケーション制御を別々の問いとして扱ってください。有用な問いは、Perplexityのローカルモードが、意図した境界内であなたの作業を完了できるかどうかです。範囲を限定した文書ワークフローから始め、完成した成果物、加えられた変更、承認を求められた判断を評価してください。
