「守り」で活用するオンデバイスLLM 〜写ってはいけないを総力戦で防ぐ〜 / iOSDC Japan 2026

iOSDC Japan 2026 での発表資料です。 https://iosdc.jp/2026/
Track C - 2026/09/12 16:10 - 16:30

1. 「守り」で活用するオンデバイスLLM 〜写ってはいけないを総力戦で防ぐ〜 1
2. 自己紹介 中村 恵太 SmartBank, Inc. iOS / Android Application Developer @chickmuuu @nakamuuu 2
3. X
4. 今日お話しするのは… 画像アップロード機能での防御機構の構築
5. 画像アップロード機能における課題意識
6. 画像アップロード機能における課題意識 ワンバンクには画像アップロードを伴う多くの機能が存在 6
7. 画像アップロード機能における課題意識 カード発行事業者に求められる PCI DSS への準拠 • クレジットカード業界の国際的なセキュリティ基準である PCI DSS（Payment Card Industry Data Security Standard）への準拠が求められる • ネットワークのセキュリティ担保、データ保護、アクセス制御など、 カード情報を取り扱う上での多岐にわたるルールが存在する カード情報の取り扱いを伴うシステムには 開発・運用に厳しい制約 7
8. 画像アップロード機能における課題意識 PCI DSS 準拠 / 非準拠環境を分けることで開発・運用コストの削減 準拠 : Mobile BFF 準拠 : Issuing API PCI DSS準拠環境 カード情報の保持や 決済電文の処理 バックエンドの 複数APIの呼び出しと レスポンスの合成 非準拠 : Core API ワンバンクの 大半の機能を実装 8
9. 画像アップロード機能における課題意識 • 画像アップロードを伴う多くの機能の存在 • PCI DSS 準拠 / 非準拠環境を分けることでの 開発・運用コストの削減 想定されるリスク PCI DSS 準拠環境 での 取り扱いが要求される情報（≒カード番号）が アップロードされる画像に含まれうる 9
10. 画像アップロード機能における課題意識 PCI DSS 非準拠環境へのカード番号を含む画像を伝送・保存を防ぎたい 準拠 : Mobile BFF 準拠 : Issuing API PCI DSS準拠環境 カード情報の保持や 決済電文の処理 バックエンドの 複数APIの呼び出しと レスポンスの合成 非準拠 : Core API ワンバンクの 大半の機能を実装 10
11. 「守り」で活用するオンデバイスLLM 今日お話しすること オンデバイスLLMを活用した サーバーサイドとの総力戦での理想的な防御機構の実現 ① サーバーサイドでの防御機構の作り込みと限界 ② GenAI Prompt APIを用いた防御機構の実装 (Android) ③ iOS 27のFoundation Modelsの拡張を踏まえた思索 11
12. サーバーサイドでの防御機構の作り込みと限界
13. サーバーサイドでの防御機構の作り込みと限界 画像内の “写ってはいけないもの” を 弾きたい @minisera / PHPカンファレンス 原 2026 https://speakerdeck.com/minisera/i-want-to-play-the-things-that-shouldnt-be-in-the-picture ⽥ ⼩ 13
14. サーバーサイドでの防御機構の作り込みと限界 “カード番号を含む画像” にもさまざまなバリエーション • カード券面が写り込んだ写真 • カード番号を含むスクリーンショット • 古い決済端末や一部の加盟店で発行される カード番号が適切にマスクされないレシート 検出ロジック次第で漏れが生じやすい 🤔 14
15. サーバーサイドでの防御機構の作り込みと限界 物体認識とOCRの二層構造でカード番号を含む画像を検出 アップロードされた画像 物体認識 OCR (Rekognition DetectLabels) (Rekognition DetectText) いずれかの検出判定で処理を中断 15
16. サーバーサイドでの防御機構のみで充分？ 16
17. サーバーサイドでの防御機構の作り込みと限界 サーバーサイドでの防御機構には3つの観点で改善幅 💰 金銭コスト Amazon Rekognition の物体認識 / OCRの実行毎に料金 🧮 実行コスト 画像アップロード毎に外部通信を伴う非同期処理が介入 🛜 伝送の防御 画像の保存だけでなくアプリからの伝送を防げるとより強固 iOS / Androidアプリ側での機構との組み合わせで改善を模索する 17
18. サーバーサイドでの防御機構の作り込みと限界 サーバーサイドと同等の二層構造をアプリに持ち込むには 主に物体認識（多ラベル分類）側の機能に不足 • 物体認識には iOS は Vision Framework (ClassifyImageRequest) 、 Android では ML Kit Image Labeling が利用できる • ラベル分類は画像全体に対して分類ごとの確度を返す（＝写り方の影響を受ける） • 例) [ (credit̲card: 0.9), (gift̲card: 0.8), (coupon: 0.6), …] • “物体検出” 寄りなソリューションの Rekognition DetectLabels での確度の解釈を そのままアプリに持ち込むのは難しい ※ ML Kit Image Labeling には2026年9月時点でクレジットカード相当の分類ラベルが存在しない 18
19. GenAI Prompt APIを用いた防御機構の実装 （Android） 19
20. GenAI Prompt APIを用いた防御機構の実装 MLKit GenAI Prompt API (Beta) https://developers.google.com/ml-kit/genai/prompt/android 20
21. GenAI Prompt APIを用いた防御機構の実装 • GenAI Prompt APIを用いてカード券面の検出を実装 • マルチモーダル（画像入力）に対応するため リクエストに渡すだけで防御機構をライトに組める Android での実装 val request = GenerateContentRequest.Builder( ImagePart(imageUri), TextPart("Is a payment card number visible? Answer ̀yes̀ or ̀nò.") ).build() val answer = Generation.getClient().generateContent(request) 21
22. GenAI Prompt APIを用いた防御機構の実装 GenAI Prompt API の直近のリリースから構造化出力にも対応？ Android での実装 @Generable data class Schema( @Guide(description = "Whether the credit card number is readable in the image") val isCardNumberReadable: Boolean, ) val request = GenerateContentRequest.Builder(ImagePart(…), TextPart(“…”)).build() val typedRequest = generateTypedContentRequest(request, Schema::class) val schema = Generation.getClient().generateContent(typedRequest).candidates. rstOrNull()?.response fi 22
23. GenAI Prompt APIを用いた防御機構の実装 GenAI Prompt API の直近のリリースから構造化出力にも対応？ • Beta 4（2026年7月）でアルファ版扱いでありながらも構造化出力に対応 • Prompt APIと独立した利用可否のフラグ（isStructuredOutputFeatureAvailable）が存在 • 明示されていないが Prompt API に対応するすべての環境で利用できる わけではない？ • 手元の Prompt API の対応デバイス2種で試した限り動作を確認できてない 😢 ※ Pixel 10 Pro (nano-v3) / Galaxy Z Fold8 (nano-v4) で AI Core Developer Preview を有効化した上で検証 isStructuredOutputFeatureAvailable が常に false を返す振る舞いをする 23
24. GenAI Prompt APIを用いた防御機構の実装 GenAI Prompt API の活用によって解決する課題と新たな課題 ✅ 🤔 💰 金銭コスト 📱 対応端末の数 利用されているAndroidデバイスの 15%〜20%前後のみが対応 🧪 出力の安定性 構造化出力の対応がアルファ版かつ 対応する環境も現時点では不明瞭 🧮 実行コスト 🛜 伝送の防御 ※ 対応端末のシェアは『ワンバンク』の2026年9月時点のアクティブユーザーの利用デバイスから推定 24
25. Foundation Modelsの拡張を踏まえた思索 25
26. Foundation Modelsの拡張を踏まえた思索 iOS 27 で Foundation Models がマルチモーダル（画像入力）に対応 • リクエスト時に Attachment オブジェクトを付与するI/F • GenAI Prompt APIと同様にカード券面の検出も動作 let prompt = Prompt { "Is a payment card number visible? Answer ̀yes̀ or ̀nò." Attachment(image) } let response = try await session.respond(to: prompt) 26
27. Foundation Modelsの拡張を踏まえた思索 Foundation Models の構造化出力は iOS 26 から対応 @Generable private struct CardDetection { @Guide(description: "Whether the credit card number is readable in the image”) let isCardNumberReadable: Bool } let prompt = Prompt { "Is a payment card number visible? Answer ̀yes̀ or ̀nò." Attachment(image) } let response = try await session.respond(to: prompt, generating: CardDetection.self) 27
28. Foundation Modelsの拡張を踏まえた思索 GenAI Prompt API での課題は？ 📱 対応端末の数 利用されているiOSデバイスのうち 45%〜50% 前後が対応 マルチモーダル（画像入力）は iOS 27 の普及率次第 🧪 出力の安定性 Foundation Models の登場時から構造化出力に対応 Foundation Models の対応シェアはもうすぐ半数 ”ごく少数の最新端末でのみ利用できる” 状況からはすでに脱している ※ 対応端末のシェアは『ワンバンク』の2026年9月時点のアクティブユーザーの利用デバイスから推定 28
29. オンデバイスLLMの選択肢がある中で どの技術を選択すべきか / 組み合わせるか？
30. オンデバイスLLMの活用と選択 LLMの活用にふさわしいのは 「毎回タスクが変わる、意味理解や自然言語的な解釈が必要なケース」 • WWDC26 の「Whatʼs new in image understanding」「Coding Intelligence, Machine Learning & AI Group Lab」でも同様の言及 30
31. オンデバイスLLMの活用と選択 サーバーサイド モバイルアプリ OCR 物体検出 OCR 物体検出 ラベル分類 LLM ラベル分類 オンデバイスLLM 既存の他のソリューションを補完する手札として オンデバイスLLMを認知しておくと活用できる幅が広がるはず 31
32. オンデバイスLLMの活用と選択 多くの技術の選択肢がある中で 1つだけの仕組みで目的を達成する必要は必ずしもない オンデバイスLLMの可用性のフォロー例 • サーバーサイドにコストはかかるが堅牢な仕組みがあることを前提とする • オンデバイスLLMに非対応のデバイスでは機能性が劣る他の技術を用いる コストやリスクを最小化するための一つの手札として オンデバイスLLMを組み合わせられる 32
33. まとめ
34. まとめ 今日お話ししたこと オンデバイスLLMを活用した サーバーサイドとの総力戦での理想的な防御機構の実現 ① サーバーサイドでの防御機構の作り込みと限界 ② GenAI Prompt APIを用いた防御機構の実装 (Android) ③ iOS 27のFoundation Modelsの拡張を踏まえた思索 34
35. ここで聞いた事例は… カード発行事業者特有の話であまり参考にならない？
36. まとめ 曖昧さの伴うデータの入力 直接的な価値提供とならない出力 ・不定形のテキスト入力 ・画像アップロード ・アプリの操作ログ ・セキュリティ要件対応 ・ユーザーの行動分析 ・詐欺や不正に対するユーザー保護 「新しい価値を作るLLM活用」ではなく「守りとしてのLLM活用」として 考え方を転用できるプロダクトは多いはず 36
37. ご清聴ありがとうございました！ 37