データ保護影響評価 (DPIA)
QR Branding API — AI機能
| 項目 | 内容 |
|---|---|
| 日付 | 2026-03-08 |
| 管理者 | QR Branding (Quartzon) |
| バージョン | 1.0 |
| 状況 | 承認済み |
| 次回の見直し | 2026-09-08 |
1. 処理の説明
1.1 処理の性質
QR Brandingは、AIによるQRコード生成を2つのモードで提供しています。
- QR Branding自社のLLMプロバイダーアカウントによる生成: qr-branding.comのAIデザイナーと、マーケットプレイスのマネージドエンドポイント（
POST /api/qr/ai/generate-managed）。プロバイダー（Groq、Google Gemini、OpenAI）の内部フォールバックチェーンが各リクエストを処理する。 - 顧客自身のキーによる生成（BYOK）: マーケットプレイスのエンドポイント
POST /api/qr/ai/generate。顧客が自身のAPIキーを提供し、プロバイダー（OpenAI、Anthropic、Google、Mistral、Cohere、Groq、xAI、DeepSeek、Qwen、または顧客自身のOpenAI互換エンドポイント）を選択する。
どちらのモードでも、ユーザーは自然言語のデザインのプロンプト（例: 「テック企業向けのモダンな青いQRコード」）を、QRコンテンツ（URL、テキスト、vCardなど）とともに送信します。システムは次のことを行います。
- 外部のLLMプロバイダー（QR Brandingのフォールバックチェーンでリクエストを処理するプロバイダー、またはユーザーが選択したプロバイダー（BYOK））に、デザインのプロンプトと生成パラメータのみを送信する。
- LLMからJSON形式のデザイン設定を受け取る。
- 提供されたコンテンツと提案されたデザインでQRコードを生成する。
- QR画像をユーザーに返す。
1.2 範囲
- 処理されるデータ: デザインのプロンプト（自由記述）、生成パラメータ（スタイルのプリセット、創造性、厳格なスキャン可能性）、QRコンテンツ（URL、テキスト、vCardの連絡先情報、WiFiの認証情報、位置情報）、顧客のAPIキー（BYOKのみ、一時的）。
- 推定量: IPごとに1分あたり最大15件のAIリクエスト、全体で1分あたり100件の生成。
- 影響を受けるデータ主体: qr-branding.comサイトのユーザー、APIのユーザー（開発者、企業）、および間接的に、QRコンテンツにデータが含まれる人々（vCardの連絡先）。
- 地理的範囲: 全世界（RapidAPI Marketplace上の公開API）。
1.3 背景
- ステートレスなサービス: データベースはなく、QRコンテンツは永続化されない。
- QR Branding自社のアカウント（サイトとマネージドエンドポイント）: QR BrandingはGroq、Google（Gemini）、OpenAIに自社のAPIキーを保有しており、これらのプロバイダーはその処理者として行動し、副処理者のページに掲載されている。メールアドレス、請求データ、IPアドレス、顧客の識別子はこれらに送信されない。
- BYOK（Bring Your Own Key）モデル（
POST /api/qr/ai/generate）: 顧客がリクエストごとに自身のAPIキーを提供する。QR Brandingは、これらのリクエストに自社のアカウントを使用しない。 - QRコンテンツがAIプロバイダーに送信されることは決してなく、送信されるのはデザインのプロンプトのみである。
- LLMが生成した機密性のあるフィールド（URL、base64）は、レンダリング前にnullにされる。
- サービスはAzure Functions（Consumption Plan）上で稼働する。
- BYOKエンドポイントでは、LLMプロバイダーとの契約関係は、顧客とプロバイダーの間の直接の関係である。
1.4 目的
ユーザーが自然言語による説明からカスタマイズされたQRデザインを生成できるようにし、パラメータを手動で設定する手間をなくすこと。
2. 必要性と比例性
2.1 法的根拠
契約の履行（GDPR第6条(1)(b)）: 処理は、ユーザーが要求した具体的なサービスを提供するために必要である。
2.2 データの最小化
| 原則 | 実装 |
|---|---|
| 必要なデータのみ | LLMに送信するのはプロンプトのみで、QRコンテンツは送信しない |
| 保存なし | メモリ内で処理し、プロンプトのテキストとQRコンテンツはHTTPレスポンスの後に破棄する。生成されたデザイン設定のみ、プロンプトとパラメータのSHA-256ハッシュから導出したキーのもとで最大30日間キャッシュされることがある |
| プロファイリングなし | ユーザーのプロファイルやリクエスト履歴は作成しない |
| 匿名化 | ログ内のIPアドレスを匿名化する（最後のオクテットをマスク） |
| 分離 | データフロー内でQRコンテンツとAIのプロンプトを分離して扱う |
2.3 比例性
処理が比例的である理由:
- ユーザーはAI機能の使用を能動的に選択している（別のエンドポイント）。
- BYOKエンドポイントではユーザーがLLMプロバイダーを選択している。サイトとマネージドエンドポイントでは、プロバイダーは副処理者のページに掲載された処理者のいずれかである。
- 移転されるのはデザインのプロンプトのみである（QRコンテンツの個人データは移転されない）。
- 自然言語からデザインを生成するための、より侵害の少ない代替手段は存在しない。
3. リスクの特定と評価
3.1 特定されたリスク
| # | リスク | 発生可能性 | 影響 | レベル | 軽減策 |
|---|---|---|---|---|---|
| R1 | プロンプトインジェクション: ユーザーがプロンプトに悪意のある指示を注入する | 中 | 中 | 中 | <user_request> 区切り文字、システムプロンプト内の漏洩防止の指示、LLM処理後のURL/base64フィールドのnull化 |
| R2 | プロンプト内のPII: ユーザーがデザインの説明に個人データを含める | 中 | 低 | 低 | プロンプトのテキストは保存しない（キャッシュは、ハッシュから導出したキーのもとで生成されたデザインのみを保持する）。プロンプトはユーザーの識別子を一切付けずに送信される。利用ポリシーを文書化 |
| R3 | システムプロンプトの流出: 攻撃者がシステムの指示を抜き出す | 低 | 低 | 低 | システムプロンプトの漏洩防止フッター、出力のサニタイズ（HTMLタグの除去） |
| R4 | 国際移転: プロンプトがEEA域外のプロバイダーに転送される | 中 | 低 | 低 | QR Brandingのアカウント: Groq、Google、OpenAI（米国）が各プロバイダーのデータ処理規約に基づき処理者として行動する。送信するのはデザインのプロンプトとパラメータのみ。BYOK: 顧客がプロバイダーと直接の関係と独自のDPAを持つ。QR Brandingは技術的な仲介者としてのみ行動する。プライバシーポリシーと副処理者のページで開示 |
| R5 | LLMプロバイダーによる保持: プロバイダーが自社のポリシーに基づいてデータを保持する | 中 | 低 | 低 | QR Brandingのアカウント: 各プロバイダーとQR Brandingの間のデータ処理規約に従う。BYOK: プロバイダーとの顧客自身の規約に基づく顧客の責任 |
| R6 | 悪意のある内容を含むLLMの応答: XSS、悪意のあるURL | 中 | 中 | 中 | タイムアウト付きのHTMLサニタイズ用正規表現、URL/base64フィールドのnull化、デシリアライズ時のMaxDepth=32 |
| R7 | Denial of wallet: コストを膨らませるためのAIエンドポイントの濫用 | 中 | 高 | 高 | レート制限（IPごとにAI 15件/分、全体で100件/分）、セマフォ付きのRenderThrottle、functionTimeout 1:30 |
| R8 | ログへのAPIキーの漏洩 | 低 | 高 | 中 | SanitizeForLog()によるAPIキーのパターンのマスキング、PIIを含まないエラーメッセージ |
3.2 データフロー図
User → qr-branding.com or RapidAPI Proxy → Azure Functions
↓
[Design prompt + parameters only]
↓
LLM provider (QR Branding's fallback chain,
or the user's choice on BYOK)
↓
[Design JSON config]
↓
QR Rendering (SkiaSharp)
+ QR content (never leaves the server)
↓
QR image → User
4. 軽減措置
4.1 実施済みの技術的措置
| 措置 | 軽減するリスク | 状況 |
|---|---|---|
プロンプトの区切り文字（<user_request>） | R1 | ✅ 実装済み |
| システムプロンプトの漏洩防止フッター | R1、R3 | ✅ 実装済み |
| LLMのURL/base64フィールドのnull化 | R1、R6 | ✅ 実装済み |
| タイムアウト（3秒）付きのHTMLサニタイズ用正規表現 | R6 | ✅ 実装済み |
| JsonSerializerのMaxDepth=32 | R6 | ✅ 実装済み |
| AIのレート制限（IPごとに15件/分、全体で100件/分） | R7 | ✅ 実装済み |
| RenderThrottle（セマフォ、同時実行4） | R7 | ✅ 実装済み |
| functionTimeout 1:30 | R7 | ✅ 実装済み |
| SanitizeForLog(): APIキーのマスキング | R8 | ✅ 実装済み |
| IPの匿名化（最後のオクテット） | R2 | ✅ 実装済み |
| PIIを含まないエラーメッセージ | R2 | ✅ 実装済み |
| すべてのLLM呼び出しでの出力トークン上限 | R7 | ✅ 実装済み |
| Content-Length + 読み込み後のサイズチェック（1MB） | R7 | ✅ 実装済み |
| GoogleのsystemInstructionの分離 | R1 | ✅ 実装済み |
4.2 組織的措置
| 措置 | 軽減するリスク | 状況 |
|---|---|---|
| プライバシーポリシーの公開 | R4、R5 | ✅ 実装済み |
| ドキュメントと副処理者のページでのLLMプロバイダーの開示 | R4 | ✅ 実装済み |
| QR Brandingのアカウントで使用するLLMプロバイダー（Groq、Google、OpenAI）とのDPA | R4、R5 | ⚠️ 確認待ち |
| BYOKエンドポイントにおけるLLMプロバイダーとのDPA | R5 | 顧客の責任 |
| DSR対応手順の文書化 | 全般 | ✅ 文書化済み |
| インシデント対応計画 | 全般 | ✅ 文書化済み |
5. 結論
5.1 残存リスク
すべての技術的・組織的措置を講じた結果、残存リスクは低と評価されます。
- 処理はステートレスであり、QRコンテンツもプロンプトのテキストも永続化されない（プロンプトのキャッシュは、ハッシュから導出したキーのもとで生成されたデザインのみを保持する）。
- QRコンテンツ（機密性が高い可能性がある）がAzureのインフラの外に出ることは決してない。
- 第三者に移転されるのはデザインのプロンプト（PIIを含むことはまれ）のみである。
- 大規模監査で挙げられたすべての技術的な軽減策が実装され、検証済みである。
5.2 決定
✅ 現在の措置のもとで処理を進めることができます。
残存リスクが低いため、監督機関への事前協議（GDPR第36条）は不要です。
5.3 見直し
このDPIAは次の場合に見直します。
- 少なくとも6か月ごと。
- 新しいLLMプロバイダーが追加されたとき。
- AIエンドポイントのデータフローが変わったとき。
- 機密性のあるデータを含みうる新しい種類のQRコンテンツが導入されたとき。
2026-03-08に作成された文書。次回の定期見直し: 2026-09-08。