プロンプトインジェクションに対するAppleの自社製の答え

Appleはついに、Simon Willison氏の名前を明示的に挙げるようになりました。WWDC 2026のセッション347で、Appleのセキュリティエンジニアは、エージェント的なリスクを、このブログのセキュリティスレッドが1年にわたって示してきたのとまったく同じ枠組みで捉えています。「Simon Willison氏のLethal Trifectaを参照できます。これは、エージェント的なシステムが、プライベートデータへのアクセス、信頼できないコンテンツへの露出、そして外部と通信する能力という3つを併せ持つとき、ユーザーが最も危険な状態に置かれる、という考え方を示すものです」¹。このセッション、Privacy and Securityグループのラボ、そして同じ週に公開されたsecurity.apple.comの発表を合わせると、最大規模のデバイス群を抱えるプラットフォームベンダーがエージェントの保護をどう考えているかについて、これまでで最も完全な全体像が浮かび上がります。すなわち、ベースラインとしての決定論的なガードレール、それを補強する確率論的なガードレール、そしてそのすべての土台となるインフラの構成証明（アテステーション）です。

lethal trifectaは、セッション347の5:55で引用されています。

要点

• セッション347はApple初の自社製プロンプトインジェクション・ドクトリンです。まず脅威モデリングによって信頼できないコンテキストを特定し、その上で「決定論的な緩和策をベースラインとすることに注力します。なぜなら、そのセキュリティ保証は監査しやすく、論理的に説明しやすいからです」とし、spotlightingのような確率論的な緩和策をその上に重ねます¹。
• これらのガードレールは助言ではなく、出荷されるAPIです。Foundation Modelsのライフサイクルイベント修飾子は、決定論的なフックを提供します。.onToolCallはすべてのツール呼び出しを実行前に傍受し、エラーをスローすることでブロックします。.historyTransformは、spotlightingの区切り文字の付与やPIIの墨消しのために、各推論パスの前にトランスクリプトを書き換えます¹。
• App Intentsはリスクを自動的に強制します。インテントは、採用したスキーマからリスクメタデータを継承し、リスク評価システムが文脈に応じた確認を起動します。そしてauthenticationPolicyは、より厳格な方向にのみ上書きできます¹。
• 同じ週に、AppleはPrivate Cloud Computeを自社のデータセンターの外へ、NVIDIAハードウェア上のGoogle Cloudにまで拡張しました。同じ5つのコア要件を維持しつつ、ソフトウェアの構成証明を「独立した複数のベンダーによる、少なくとも2つの別個の信頼の起点」に根ざすものとしています²。
• Privacy and Securityグループのラボが、その細部を補ってくれました。Appleは、この決定論的かつ確率論的なスタックをSiri AI、Safari、Xcodeにわたって使っていると述べており、XcodeのエージェントはXcodeがMCPサーバーとして動作する際にツールのallowlistを用います³。

ドクトリン：まず決定論的に、次に確率論的に

セッション347は、本番環境でエージェントを運用している人なら誰もが見覚えのある脅威モデルに沿って、サンプルアプリを解説していきます。間接プロンプトインジェクションは「制御フローをリダイレクトする意図をもって、モデルに与えられる追加のコンテキストに埋め込まれた指示」と定義され、その帰結を、区別しておく価値のある2つの効果に分けています。すなわち、「攻撃者が、実行されるアクションのパラメータに影響を与える」データポイズニングと、「攻撃者が、どのアクションを実行するかに影響を与える」アクションポイズニングです¹。このセッションは、ベンダーの資料には珍しいほど、技術の現状について率直です。「間接プロンプトインジェクションを解決することは、活発な研究領域です。つまり、現時点での最善のアプローチは、自分のアプリがどれだけリスクにさらされているかを理解し、そのリスクの軽減を目指すことだ、ということです」¹。

順序付けの原則こそ、設計レビューで引用する価値のある部分です。決定論的な緩和策が最初に来るのは「そのセキュリティ保証が監査しやすく、論理的に説明しやすいから」です。確率論的な緩和策も追加する価値があるのは「異なるモデルなら、これらの制約をより効果的に強制できるかもしれないから」ですが、セッションはすぐにその限界を認めます。spotlightingは「プロンプトインジェクションがspotlighting自体を打ち消すように構築されうるため、確率論的な緩和策である」というのです¹。ユーザーの確認やデバイスのロック解除の要求は、決定論的な側の台帳に分類されます。墨消しは、PIIがそもそもモデルに到達しないようにし、「したがって、外部に持ち出されることもありえません」¹。Appleは、Siri AIの設計においてこれらの緩和策を用いてきたと述べています¹。

脅威モデルから読み取れるある微妙な点は、ほとんどのallowlistが見逃すケースを捉えているため、注目に値します。タイマー作成アクションは一見無害に見えますが、そのオプションのラベルパラメータに目を向けると話は変わります。プロンプトインジェクションはラベルを攻撃者が制御するテキストに設定でき、「その後にタイマーの一覧を取得するクエリが、この攻撃者制御下のデータをそのコンテキストに引き込み、新しいコンテキストをも汚染してしまうのです」¹。書き込み可能な文字列フィールドを持つ副作用のないツールは、インジェクションにとっての永続化メカニズムになります。

Foundation Modelsのガードレール API

セッションの実装パートは、このドクトリンを、出荷される2つの面に対応づけます。Foundation Modelsフレームワークにおいて、ライフサイクルイベント修飾子は「セッション実行の特定のライフサイクルポイントで決定論的に起動するコールバック」です¹。

.onToolCallはアクションのチェックポイントです。これは「LLMがツール呼び出しを出力したとき、エグゼキュータがツールを実行する前に起動することが保証されて」おり、その契約こそが有用な部分です。「このコールバックがエラーをスローすれば、そのツールは決して実行されません」¹。セッションの例では、ある一箇所で金銭的影響のあるツールにユーザー確認のゲートをかけ、セッション内のすべてのツール呼び出しに対するカバレッジを得ています。その形は、このブログが承認プロンプトは認可ではないで主張したものと同じです。チェックはモデルへの指示の中ではなく、実行経路の中に存在するのです。

.historyTransformは入力のチェックポイントです。これは「トランスクリプトが推論のためにモデルへレンダリングされる前に起動」し、新規のユーザーリクエスト時にも、ループの各反復時にも発火します。セッションはこれを2つのプロンプト緩和策に使っています。すなわち、信頼できないソースからのツール出力をspotlightingの区切り文字で包むことと、機微なデータを墨消しのプレースホルダーに置き換えることです¹。実装者にとって重要な詳細があります。変換されたエントリは現在の推論パスにのみスコープされるため、変換は各反復で再適用されます。そして@SessionPropertyアノテーションが、コストの高いステートフルな変換のための逃げ道となります¹。

App Intents：書くのではなく継承するリスクメタデータ

Siriに面した側は、そのガードレールをスキーマシステムから得ます。あるインテントがインテントスキーマを採用すると、リスクメタデータがそのスキーマの副作用に基づいて「自動的に割り当てられます」。破壊的なアクション、データを持ち出すアクション、共有コンテンツを更新するアクションはよりリスクが高く、「システムは、リスクの高いツールに対して確認を起動する可能性がより高くなります」¹。リスク評価システムは、その静的なメタデータと動的なシステム状態とを組み合わせ、インテントを実行する前に確認を挟むかどうかを文脈に応じて判断します。確認を拒否すれば、インテントは完全にブロックされます¹。

ロック画面での露出も同じ扱いを受けます。Siriはロックされたデバイス上でも動作するため、物理的に端末を所持している攻撃者があなたのインテントに到達しうるのです。そこでカスタムインテントはauthenticationPolicyを設定し、スキーマは機微度に基づくデフォルト値を持ちます。その制約はまさに適切です。「スキーマのポリシーは上書きできますが、より厳格にする方向にのみ可能です」とされ、もし緩めようとすれば、許可される最小限のポリシーを示すビルドエラーが出ます¹。コンパイラがアクションの保護不足を許さないというのは、想像しうる限り最もApple的なプロンプトインジェクション緩和策です。

インフラの層：PCCがAppleのデータセンターを離れる

セッションが放映される3日前、Appleは自社のセキュリティブログに「Private Cloud Computeの拡張」を公開しました。新しいApple Intelligenceのワークロードは、NVIDIA GPUを備えたGoogle Cloud上で動作するようになり、「業界をリードする当社のPCCのプライバシーへのコミットメントを、初めてサードパーティのデータセンターへと拡張する」ものです²。5つのコア要件はそのまま引き継がれます。「ステートレスな計算、強制可能な保証、特権的なランタイムアクセスの排除、ターゲット不可能性、そして検証可能な透明性」です²。変わるのは実装です。NVIDIA Confidential Computing、Intel TDXを備えたIntel CPU、そしてGoogleのTitanチップです²。

機密計算（コンフィデンシャル・コンピューティング）の現状に照らして、2つの設計上の選択が際立ちます。侵害された場合にユーザーデータを持ち出しうるコンポーネントについては、「ソフトウェアの構成証明は、独立した複数のベンダーによる、少なくとも2つの別個の信頼の起点に根ざしています」。さらにAppleは、サプライチェーン攻撃に対して「PCCフリートの一部であるすべてのGoogle Cloudハードウェアについて、暗号学的に検証可能な追記専用の台帳」を維持しています²。Appleシリコン上のPCCにおけるアーキテクチャパターンも引き継がれます。専用の名前空間化されたプロセスでのリクエストごとのネットワーク解析、短い生存時間（TTL）でリサイクルされる共有推論ソフトウェア、外部入力から隔離された別個の機密VMに保持される構成証明済みの鍵です²。制御は集中化されたままです。「AppleはPCCソフトウェアに対する完全な制御を保持します。Appleのデバイスは、Appleによって暗号学的に承認されたPCCソフトウェアのみを信頼します」とされ、すべてのバイナリは公開され検査可能で、稼働中のリサーチモードのノードにはApple Security Bountyプログラムを通じて到達できます²。ロールアウトは段階的で、「サマープレビュー期間を通じて、完全な保護群へと徐々に拡大していきます」²。

ラボが補ったこと

Privacy and Securityグループのラボは同じ週に行われ、Appleはラボの字幕を公開していません。そのため、以下はローカルで文字起こしした録音からの言い換えであり、引用ではありません³。パネルは、セッションのドクトリンを出荷される面へと結びつけました。決定論的かつ確率論的なスタックは、Siri AI、Safari、そしてXcodeのエージェント的機能にわたって動作しており、XcodeがMCPサーバーとして動作する際には、許可されたツールのallowlistでエージェントを制約します³。Siri AIのアーキテクチャについて、あるパネリストは、専用の堅牢化されサンドボックス化されたデーモンを、エンタイトルメントによるゲーティングと組み合わせて説明しました。これが、データがPrivate Cloud Computeへ送られる前に、ユーザーデータを収集し整形する唯一の経路であり、マルチターンのリクエストでは、会話の途中で新たにアクセスするデータについて改めて許可を求めるとのことです³。

ラボのスレッドのうち、フォローアップする価値のあるものがあと2つあります。パネルは、Foundation Modelsのプライバシー保証は、フレームワークの言語モデルプロトコルを介して到達するサードパーティのモデルには及ばない、と述べました。それらのプロバイダーの規約を読み、それに応じて開示する責任は開発者にあります³。そして、WebAuthnの普及につきまとってきたパスキーのライフサイクルの問題について、あるパネリストはSignal APIを解決済みの答えとして挙げました。Webの標準は今や、リライングパーティと認証器の間でクレデンシャルを同期させるためのsignalUnknownCredential、signalAllAcceptedCredentials、signalCurrentUserDetailsを定義しており、このAPIは現実のものとしてW3C WebAuthn Level 3で出荷されています⁴。

ここから何を持ち帰るか

有用なのは、Appleがプロンプトインジェクションを解決したという点ではありません。セッションは、誰もそれを解決していないとはっきり述べています。有用なのは、プラットフォームベンダーがある順序付けにコミットする様子を見られることです。まず実行経路における決定論的な制御、次にモデルレベルのヒント、そしてその土台にインフラの構成証明という順序です。Appleのプラットフォームの外でエージェントを構築する人にとっても、それぞれの要素には対応物があります。.onToolCallはあなたのツール呼び出しインターセプタであり、.historyTransformはあなたのコンテキスト・サニタイザ、スキーマ継承によるリスクメタデータはあなたのツール分類テーブル、そして「より厳格な方向にのみ」のauthenticationPolicyの上書きは、あなたのポリシーの下限です。フレームワークの名前はApple独自のものですが、アーキテクチャは移植可能であり、このブログが2つの信頼できない入力を持つエージェントとツール拡張エージェントのためのランタイム防御で示した多層防御と一致します。

FAQ

プロンプトインジェクションに対してAppleが推奨する防御は何ですか？

まず脅威モデリングを行い（信頼できないコンテキストのソースとアクションの副作用を特定する）、次に「決定論的な緩和策をベースラインとします。なぜなら、そのセキュリティ保証は監査しやすく、論理的に説明しやすいからです」とし、その上にspotlightingのような確率論的な緩和策を加えます¹。具体的には、リスクの高いアクションにはユーザー確認とデバイスのロック解除の要求を、信頼できないコンテキストにはPIIの墨消しとspotlightingの区切り文字を適用します。

これらのガードレールを実装するAPIは何ですか？

Foundation Modelsでは、ライフサイクルイベント修飾子です。.onToolCall（すべてのツール呼び出しを実行前に決定論的に傍受し、スローすればツールをブロックする）と.historyTransform（各推論パスの前にトランスクリプトの末尾を書き換える）であり、永続的な変換には@SessionPropertyを用います¹。App Intentsでは、スキーマ継承によるリスクメタデータが文脈に応じた確認を駆動し、authenticationPolicyがロック画面へのアクセスを制御します。上書きはより厳格な方向にのみ可能です¹。

Appleは本当にPrivate Cloud ComputeをGoogleのクラウドへ移したのですか？

はい、新しいApple Intelligenceのワークロードについてはそうです。PCCは今や、Intel TDXとGoogleのTitanチップを備えたNVIDIA GPU上のGoogle Cloudへと拡張されており、同じ5つのPCC要件、デュアルベンダーによる構成証明の起点、追記専用のハードウェア台帳、そしてApple限定のソフトウェア承認を維持したまま、サマープレビュー期間を通じて拡大していきます²。PCCの保証は、言語モデルプロトコルを介して到達するGeminiやClaudeのようなサードパーティのモデルには、依然として及びません³。

これらのいずれかは、Appleのプラットフォームの外でも当てはまりますか？

アーキテクチャは当てはまります。実行経路のインターセプタ、コンテキスト・サニタイザ、ツールのリスク分類、そしてポリシーの下限は移植可能なパターンです。Appleのバージョンが注目に値するのは、それが助言としてではなく、決定論的な契約を備えたフレームワークAPIとして出荷されるからです。

Appleの緩和策スタックは、このブログが1年にわたって地図化してきた領域に着地します。2つの信頼できない入力を持つエージェントにおけるtrifectaの枠組み、承認プロンプトは認可ではないにおける実行経路の議論、そしてFoundation ModelsとPrivate Cloud Computeにおけるインフラの物語です。シリーズ全体のハブはApple Ecosystemシリーズにあります。

参考文献