導入 — なぜオンデバイスAIは新たな攻撃面になるのか
スマートフォン、IoT、産業エッジ機器に搭載されるオンデバイスAI（軽量化されたNN/LLM）は、遅延削減やプライバシー向上の利点がある一方で、新しい攻撃面を提供します。外部APIと異なり「端末側で推論が完結する」ため、攻撃者は推論結果・応答挙動を繰返し観察してモデルの振る舞いを再構成（モデル抽出）したり、出力を誘導するプロンプト注入や返答乱用を試みます。近年の調査でもモデル抽出攻撃は依然として重大なリスクであり、ブラックボックスAPIへのクエリを通じた機能盗用が報告されています。
脅威モデルと代表的攻撃ベクトル
まず、守るべき資産（モデルパラメータ、トレーニングデータ、推論の機密性・完全性・可用性）を定義した上で、以下の攻撃ベクトルを想定します：
- モデル抽出（Model extraction）：クエリ応答を用いて近似サロゲートモデルを学習される。
- 推論攻撃（Inference attacks）：メンバーシップ推定、トレーニングデータ推定による個人情報漏洩。
- プロンプト注入／出力操作：入力を工夫して意図しない機能や機密出力を引き出す。
- モデル改ざん／流出：端末やOTA経路の弱点を突いたモデルファイルの改ざん・窃盗。
これらに対する実務的な抑止・検出パターンは次章で整理します。
設計パターン：推論攻撃とモデル抽出を抑止する実務技術
以下は実運用で効果的な設計パターンと実装上の注意点です。
1) API/推論インターフェースのハードニング
- レート制限とクエリレピュテーション：短時間内の類似クエリを検知し段階的に制限・チャレンジ（CAPTCHA/チャレンジ応答）を入れる。
- 出力ランダマイズと応答スムージング：決定論的な出力をそのまま返さず小幅な確率的変動やノイズを導入して、サロゲート学習の効率を下げる（ユースケースで許容できる程度に調整）。
- コンテキスト分離：機密情報を含むコンテキストはクラウド側でのみ解決し、端末側のモデル出力に機密データが含まれないよう設計する。
2) プライバシー保護と出力制御
- 差分プライバシー（DP）：トレーニング／微調整段階にDPを導入し、個別データの漏洩リスクを下げる。
- 出力フィルタとポリシーエンジン：機密パターンや予期しない長文出力を検出するポストプロセッサを導入。
3) モデル透かし（Watermarking）と帰属
出力に検出可能な特徴を埋め込むことで、盗用された生成物や外部で再生成された出力の帰属を検証可能にします。近年はテキスト出力向けの統計的ウォーターマークや、モデル内部に埋め込むブラックボックス水印など実用的手法が報告・実装されつつあります。研究・実装の進展により、実務での検出精度向上やパラメータコスト低減が進んでいます。
4) 検出とテレメトリ
- 異常クエリパターンのログ化（類似度高いクエリの高頻度発生など）
- エッジからのサンプリング応答をクラウドで相関解析して抽出攻撃の兆候を検出
- 誤検知を抑えるためのホワイトリスト/ヒューリスティックの運用
安全な更新（OTA）と実装のプラクティス
端末上モデル／ファームウェアの更新は、モデル窃盗や改ざんの主要な侵入口になり得ます。安全なOTAチェーン設計の核となる要素は以下の通りです：
- 署名チェーンとコード署名：配布するバイナリ/モデルに対して強力な署名検証を必須化し、検証に失敗した更新は拒否する。署名キーの管理（HSM/キー分割）とキー輪替（Key rotation）を運用で規定することが重要です。NISTのコード署名に関するガイダンスは実務設計で参照すべき基準となります。
- プラットフォームアテステーション（TEE/ハードウェアルート）：更新を適用する先が正当な実行環境（ブート済み・改ざんされていない）であることをリモートアテストする。TPM/TEE（Intel SGXやARM TrustZone相当）を用いた証明は有効です。
- ロールバック防止とバージョン検査：古い（脆弱な）バージョンへの巻き戻しを防ぐために、バージョンの上書き制御と反復検証を実装する。
- 差分署名と小型パッチ配布：ネットワーク負荷と露出を最小化するために差分署名を利用し、配布量を削減する一方で署名検証を厳密にする。
- OTA経路の監査とフォレンジック：更新失敗・不正更新のサインを早期検知するため、更新ログ・署名検証ログ・ネットワークログを安全に保管し、インシデント発生時に迅速に追跡できる体制を整備する。
運用チェックリスト・KPI・テスト
技術設計だけでなく運用指標と検証プロセスを定義することが成功の鍵です。
実務チェックリスト（短縮版）
- 脅威モデルを定期更新（四半期）して主要資産を再評価
- 推論APIに対するレート制限と異常検知ルール導入
- モデルに対するウォーターマーク／署名検証の実装と定期検査
- OTA署名鍵はHSMで保管、キー輪替手順を文書化
- TEE/アテステーションの導入検討と端末能力評価
- 赤チーム演習：モデル抽出シナリオ、プロンプト注入、OTA改ざんの模擬
- フォレンジック用ログの保持期間・暗号化・アクセス制御を確立
推奨KPI
| KPI | 目的 | 目安 |
|---|---|---|
| 疑わしいクエリの検出率 | 抽出試行の早期検出 | 発見から24時間以内のアラート |
| OTA署名検証失敗率 | 配布/署名問題の指標 | <1% |
| モデル盗用検知（ウォーターマーク） | 外部での不正利用検出 | 検出までの平均時間を短縮 |
テスト・検証
定期的な赤チーム演習（モデル抽出、プロンプト注入、悪意あるOTA）と、ウォーターマークの検出試験、差分プライバシーの有効性評価をCI/CDパイプラインに組み込み、自動化されたリグレッションで回帰テストを行います。
最後に、技術的対策は法務（ライセンス・契約条項）と組み合わせることで効果が高まります。モデルAPIの利用条件、データ使用の許諾、違反時のテイクダウン手順を契約に明記してください。
まとめ：オンデバイスAIの防御は単一技術ではなく、出力ハードニング、プライバシー技術、署名チェーン、TEEによるプラットフォームアテステーション、そして運用（監視・検証・赤チーム）を組み合わせて初めて実効性を持ちます。まずは脅威モデル化と最も被害が大きい資産を定め、上記チェックリストから優先度をつけて段階的に導入してください。