WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Trust Insights に出会う

Trust Insights に出会う

プライバシーセキュリティ機械学習iOS 27
元の動画を見る

ハイライト

Trust Insights は iOS 27 で導入された新しいフレームワークです。プライバシーを保護する機械学習によって、ユーザーが高リスクな操作へ「誘導」されている可能性を検出します。App がソーシャルエンジニアリング攻撃を識別する助けになり、同時にデバイス側のデータはすべてローカルで処理され、送信されません。

主要内容

ソーシャルエンジニアリング攻撃は、近年のサイバーセキュリティにおける新しい課題です。この種の攻撃はシステム脆弱性を悪用するのではなく、人の心理的な弱点を利用します。

典型的な例には、技術サポートを装ってユーザーにリモートアクセスを許可させる、銀行や政府機関を装って機密情報を聞き出す、AI ディープフェイクで「家族の緊急事態」を偽装して金銭をだまし取る、といったものがあります。

攻撃者は電話やチャット App を通じて、被害者をリアルタイムで「指導」します。操作しているのはユーザー本人であり、認証も通過し、操作自体も正当です。App には、それが本当の意思なのか、脅迫や誘導の結果なのかを区別できません。

多要素認証や生体認証など既存のセキュリティ機構は、この状況では有効ではありません。実際に操作しているのはユーザー本人だからです。

必要なのは新しいシグナルです。「誰か」を検証するだけでなく、「自由意思で行われているか」を判断する必要があります。そして、そのシグナルはユーザーのプライバシーも保護しなければなりません。

Trust Insights フレームワークは、このために作られています。ユーザーの行動パターン、タイミング、コンテキスト、基本的なセンサーデータを分析しますが、Photos、Messages、Mail の内容には触れません。すべてのデバイス側データはローカルで処理され、処理後すぐに破棄されます。デバイスを離れるのは単一の出力値だけです。

詳細

フレームワーク統合

(02:11) Trust Insights は iOS 27 で導入されたフレームワークで、Swift API だけで統合できます。サーバー側コードは不要です。

権限設定

(02:52) Trust Insights を使うには、Xcode で対応する entitlement を宣言する必要があります。

評価リクエストを作成する

(03:02) 最初の手順は、要求するインサイトの種類を指定するパラメータパッケージを作成することです。

import TrustInsights

let request = IsLikelyBeingCoachedInsight.request(
    schema: .version1,
    modelVersion: .current
)

重要な点：

  • schema はインサイトのスキーマバージョンを指定する必須パラメータです。
  • modelVersion は任意で、モデルのガバナンスと検証に使えます。
  • 現在バージョンと以前のバージョンを同時に指定し、比較検証に使うこともできます。

評価コンテキストを設定する

(03:28) InsightContext を作成し、ユーザーがどの種類の操作を行っているかをシステムに伝えます。

let context = InsightEvaluator.InsightContext(
    operationCategory: .resourceUse,
    requestedEvaluations: request
)

重要な点：

  • operationCategory はどのモデルロジックを適用するかを決めます。
  • InsightEvaluator は複数のインサイトリクエストを受け取れます。

5つの操作カテゴリ

(03:44) フレームワークは5つの定義済み操作カテゴリを提供します。

カテゴリ説明
.paymentアセット、コンテンツ、金銭の交換。アプリ内課金を含む
.accountアカウント詳細やセキュリティ情報の更新
.resourceUseAI 推論など、高価または制限されたインフラへのリクエスト
.communicationメッセージ送信、フォーム送信、ドキュメント署名
.other上記カテゴリに当てはまらない操作のフォールバック

ユースケースが .other に当てはまる場合は、Feedback Assistant で Apple にフィードバックすることが推奨されます。

権限を要求して評価を実行する

(03:36) Trust Insights の使用はユーザーが完全に制御します。統合前に認可状態を確認します。

let evaluator = InsightEvaluator()
guard try await evaluator.requestAuthorization(for: context) == .authorized else { return }

let assessment = try await evaluator.requestEvaluation(context: context)

重要な点：

  • ユーザーが App に Trust Insights の使用を許可しているか、必ず確認します。
  • requestEvaluation は非同期呼び出しで、数秒かかる場合があります。
  • 評価にはクラウドサービスが関与するため、ネットワーク接続が必要です。
  • 開発環境ではサンドボックスを使い、App Store 公開後は本番モデルを使います。

テストのコツ

(05:18) カスタム Xcode build scheme を使うと、インサイト値やエラーを上書きして、異なる意思決定ロジックや UX バリエーションをテストできます。利用可能な launch arguments は開発者ドキュメントを参照してください。

評価結果を処理する

(05:37) IsLikelyBeingCoachedInsight には3つの結果値があります。

func handleAssessment(_ assessment: InsightEvaluation<IsLikelyBeingCoachedInsight>) throws {
    switch try assessment.insight.outcome.get() {
    case .unknown:
        // システムには詐欺リスクの証拠がない
        // ただし低リスクと解釈すべきではない
    case .medium:
        // 誘導されているリスクを示す証拠が一部ある
        // 摩擦の追加、追加検証、リスクスコア調整を検討する
    case .high:
        // 誘導されているリスクを示す強い証拠がある
        // ユーザーが続行する前にリスクを伝えるべき
    @unknown default:
        break
    }
}

重要な点：

  • .unknown は低リスクを意味しません。証拠がないという意味だけです。
  • .medium では追加の検証ステップを入れることが推奨されます。
  • .high ではユーザーにリスクを明確に伝えることが推奨されます。
  • Trust Insights の結果だけを理由に操作を直接ブロックしないでください。
  • 評価レベルとインサイトレベルのエラーを独立して処理する必要があります。

フィードバックを送信する

(07:05) フィードバックには、リアルタイムの消費フィードバックと、オフラインの詐欺ラベルの2種類があります。

リアルタイム消費フィードバック

インサイト結果に対して App がどう対応したかをシステムに伝えます。これは各評価リクエストで必須です。

assessment.reportConsumption(.usedIncreasedFriction)

6つの消費値：

値説明
.usedReducedFrictionインサイトにより操作が簡単になった
.usedUnchangedFrictionインサイトを評価したが体験は変えなかった
.usedIncreasedFrictionインサイトにより追加チェックまたは摩擦が発生した
.notUsedNotNeededユーザーがキャンセルしたため判断不要だった
.notUsedError技術的失敗により使用できなかった
.usedEvaluationOnly内部評価とベンチマーク目的だけに使用した

重要な点：

  • 各評価リクエストで reportConsumption を呼ぶ必要があります。
  • 省略すると App がレート制限される可能性があります。

オフライン詐欺ラベル

(07:22) 後から取引が詐欺だと確認された場合、このシグナルはモデル改善に重要です。

// Apple Business Register を通じて送信する
// サーバー間 API を使用する
// 元の評価の insight identifier を含める

重要な点：

  • 送信は数日後、数週間後、場合によっては数か月後になることがあります。
  • Apple Business Register のサーバー間 API を使います。
  • PII やフィンガープリントに使える情報を含めないでください。
  • 必須ではありませんが、エコシステム改善に役立ちます。

プライバシーアーキテクチャ

(09:27) データ最小化は Trust Insights の中核原則です。

  • 必要なデータだけを処理します。
  • 入力は評価後すぐに破棄されます。
  • すべてのデバイス側データはデバイス上に残ります。
  • デバイス側シグナルは Apple や第三者と共有されません。
  • ユーザーは設定で Trust Insights を完全に無効化できます。

無効化後には、ユーザー自身が「指導」されて無効化してしまうことを防ぐため、クールダウン期間が設けられる場合があります。

App の例

(11:43) 家族を治療している医師だと主張する相手に、ユーザーが高額送金しようとしている場面を考えます。

  1. App がバックグラウンドで Trust Insights を要求します。
  2. .medium の結果を受け取ります。
  3. App はフローを調整し、警告を表示して取引遅延を追加します。

ユースケースに応じて、次のような選択もできます。

  • 結果をサーバー側で処理する。
  • 人手によるレビュー手順を追加する。
  • ユーザーを邪魔せずリスクを調整する。

重要な示唆

  1. 高額送金の警告：P2P 決済 App で、しきい値を超える取引に Trust Insights を要求します。高リスクまたは中リスクの場合、追加の安全警告と受取人確認ステップを表示します。

  2. 機密操作の二次確認：アカウント削除、データ書き出し、リモートアクセス許可など不可逆操作をユーザーが実行する場合、Trust Insights を要求し、確認フローの厳格さを動的に調整します。

  3. カスタマーサポート場面の保護：App にカスタマーサポートのリモート支援機能がある場合、画面共有やリモート操作をユーザーが許可する前に Trust Insights を要求し、偽の技術サポート詐欺を防ぎます。

  4. 高リスクログインの保護：新しいデバイスからのログインや機密情報変更を検出したとき、Trust Insights と組み合わせて追加の本人確認が必要か判断します。

  5. AI サービス呼び出しの摩擦：画像生成や長文処理などリソース負荷の高い AI 操作では、ユーザーが開始する前に Trust Insights を要求します。中高リスクの場合は、追加確認を入れるかサービスレベルを下げます。

関連セッション

  • App Attest — サーバーリクエストが正当な App インスタンスから来ていることを検証し、Trust Insights と組み合わせて多層防御を構築する
  • エージェント型 App のセキュリティ — エージェント型 App のセキュリティ実践と、AI 時代における信頼メカニズムの拡張
  • プライバシー保護 ML — Core AI のプライバシー保護機械学習と、Apple のオンデバイス ML 全体の戦略
  • In-App Purchase — Trust Insights と組み合わせて高価値取引を保護できる、アプリ内課金の最新実践
  • デバイス管理 — エンタープライズデバイス管理と、企業環境でセキュリティポリシーを展開する方法

コメント

GitHub Issues · utterances