2026年9月1日、Perplexity は Mac 向けに Hybrid Compute という機能をリリースしました。要点を言えば、一つのタスクを二つの場所に分けて処理するというものです。Web 検索、計画立案、長期的な推論といった重い処理は、クラウド上のフロンティアモデルで実行されます。一方、機密データに触れる処理は、あなた自身のマシン内で動く小型モデルに引き渡され、そのデータはデバイスの外に一切出ません。

表面的には Mac ユーザー向けの製品ニュースです。しかし経営者が注目すべきなのは製品ではなく、その背後にあるアーキテクチャのパターンです。つまり、データが届いた後ではなく、送信する前に分類するということです。そしてこのパターンは、Perplexity とも Mac とも関係なく、自社のシステムに適用できます。

実際に何が発表されたのか

分析に入る前に、発表された事実と解釈を分けておく価値があります。

  • 日付:2026年9月1日。
  • 仕組み:すべてのタスクはクラウドで始まり、途中で文脈を失うことなく、機密性の高い処理をローカルモデルに引き渡します。
  • プライバシーゲート:デバイス上の分類器が送信前に各タスクを読み取り、氏名、住所、口座番号を代替文字列に置き換え、回答が戻ってきたときに元に戻します。
  • 動作要件:Apple silicon 搭載の Mac、macOS 15 以降、ユニファイドメモリは最低 24GB、推奨 32GB。
  • サブスクリプション:Pro および Max の契約者と法人顧客が利用可能。
  • コスト:ローカルモデルが処理した作業はクラウドクレジットを消費しません。
  • ローカルモデル:リリース時点で複数の選択肢があり、Google の Gemma 4 E4B、Alibaba の Qwen3.6 35B-A3B、そして Perplexity が独自にトレーニングしたモデルが含まれます。

発表されていないこと、そして想定してはならないことは、サウジアラビアの個人データ保護法への準拠に関する契約上の約束や、ゲートの性能を証明する独立監査です。発表されたのは、技術的な仕組みと、企業が自社について公表した性能の数値です。

これまで耳にしてきた「ローカル AI」と何が違うのか

従来の考え方は二者択一でした。すべてをクラウドに送って強力なモデルを使うか、ローカルで小型モデルを動かし、プライバシーと引き換えに品質の低下を受け入れるかです。実際には、ほとんどの組織でプライバシーがこの議論に負けてきました。チームが仕事をこなすには、回答の品質が必要だからです。

このアーキテクチャは、その二者択一を拒否します。一つのタスクが両方の場所で実行されます。推論はクラウドで、データに触れる処理はデバイス上で行われます。さらに重要なのは、その判断が手作業ではなく、社員の注意力に委ねられてもいないことです。テキストが外に出る前に読み取る自動分類器が判断を下します。

そして注目に値する点があります。Perplexity はこの分類器の性能数値を、弱点も含めて異例の率直さで公表しました。テキストがおよそ一万文字を超えると再現率(recall)が目に見えて低下すること、そしてモデルの再トレーニングではなくデコーディング手法でこれに対処したことを明らかにしています。さらに、分類器をオープンソースとして公開しました。

Perplexity を使わなくても自社が学べる教訓

現在 AI を利用しているサウジアラビアの組織の多くは、ゲートを一切設けずに使っています。社員が顧客からのメッセージ、契約条項、口座明細をコピーし、要約や返信の下書きを求めて公開ツールに貼り付けます。その瞬間、データは組織の外に出ました。記録は何も残らず、誰も判断を下していません。

経営陣がそれに気づいたとき、反応はたいてい二つのうちのどちらかで、どちらもうまくいきません。ツールを全面禁止すれば、社員は個人のデバイスで禁止をすり抜けます。あるいは、事故が起きるまで見て見ぬふりをします。三つ目の道こそ、今回の発表が示しているものです。AI を使っているかどうかを問うのをやめ、何を自社システムの外に出してよいのか、誰がそれを決めるのか、その判断がどこに記録されるのかを問い始めることです。

自社システムにこのゲートを組み込む方法

実際に私たちが顧客のシステムに実装しているものは、四つのレイヤーに基づいており、いずれもプロバイダーに依存せずに機能します。

  • 機能を作る前に項目を分類する。システムにモデルを接続する前に、データベースの項目を分類します。何が公開情報で、何が商業的に機密で、何が個人データなのか。この分類は技術的な判断ではなく経営判断であり、その後のすべてがこれに依存します。
  • システム境界での匿名化レイヤー。外部プロバイダーへのすべての送信リクエストが通過する単一のポイントを設け、そこで個人識別子をプレースホルダーのトークンに置き換え、応答が戻った後に復元します。重要なのは、画面ごとに繰り返されるロジックではなく、一か所であることです。
  • 外に出せないもののローカル処理。すべてのタスクにフロンティアモデルが必要なわけではありません。メッセージの分類、請求書からの数値の抽出、保守依頼の優先順位付けといった処理は、自社サーバー上の小型モデルが十分な品質とほぼゼロのコストでこなします。
  • 残り続けるログ。どのリクエストが送信され、どの項目がマスクされ、誰がいつ依頼したのか。ログがなければ、監査人の質問にも顧客の質問にも答えられません。

四つのレイヤーのどれも特定のプロバイダー名を挙げていない点に注目してください。これは意図的です。今年ずっと見てきたように、モデルは数週間ごとに入れ替わり、今日構築するゲートは、その背後にあるモデルが変わっても有効であり続ける必要があります。

個人データ保護法の文脈で何を意味するのか

サウジアラビアの個人データ保護法は、サウジデータ・人工知能庁が監督しており、処理目的の特定や、収集するデータを必要な範囲に最小化することなどの原則に基づいています。組織は、第三者に処理を委託する場合でも、自ら処理する個人データについて引き続き責任を負います。

今回説明したようなアーキテクチャは、両方の原則に直接役立ちます。タスクが必要としない場合、個人データは第三者にまったく送られず、送られるのは作業を完了するのに必要な最小限のものだけです。しかし、技術だけでは準拠したことにはなりません。処理の法的根拠、プライバシーポリシー、データ主体からの請求に対応する手続きが引き続き必要です。技術的なゲートは準拠を容易にしますが、その代わりにはならず、何らかの約束をする前に唯一の拠り所となるのは、法律とその施行規則です。

今週から始められる三つのステップ

始めるにあたって、大規模なプロジェクトは必要ありません。

  • チームに一つだけ質問する:業務システムの内容を公開 AI ツールに最後に貼り付けたのはいつですか? その答えから、一時間以内に実際の問題の大きさが見えてきます。
  • 一枚の文書を書く:三つのカテゴリーを定義します。決して外に出してはならないもの、匿名化した後なら出してよいもの、そのまま出してよいもの。実際に運用される一枚の文書は、誰も読まない二十ページのポリシーに勝ります。
  • 定型業務を一つ選ぶ:個人データに関わるもの、たとえば顧客との会話の要約などを選び、四つのレイヤーを試作として適用します。一つのタスクで学んだことは、残りのタスクにも応用できます。

まとめ

Perplexity の発表は Mac ユーザー向けのものですが、その背後にある考え方は、実際のデータで AI を動かすすべての組織に関わります。正しい判断はクラウドかデバイスかの選択ではなく、外に出る前に何を出すかを決めるゲートが存在するかどうかです。今このゲートを構築する企業は、どんな新しいモデルでも数日のうちに安全に導入できます。先送りする企業は、最悪のタイミング、つまり事故の前ではなく後になって、それが必要だったと気づくことになるでしょう。

出典