JUSTWIT
000
← ブログ一覧に戻る
技術解説

生成AIでストア審査ドキュメントを「実装と矛盾なく」作る方法

#生成AI#アプリ審査#プライバシーポリシー#モバイルアプリ#Flutter

はじめに

モバイルアプリのストア公開で意外と重いのが、プライバシーポリシーと審査フォーム(App Privacy / データセーフティ)の整備です。ここで実装と記述が食い違うと、審査リジェクトや公開後の指摘につながります。

最近リリースしたタイマーアプリでは、この工程を生成AIで半日まで圧縮できました。ポイントは「文章を書かせる」のではなく、実装から逆引きさせることです。


ありがちな失敗: テンプレ流用

プライバシーポリシーをテンプレートや他アプリからの流用で済ませると、次のような食い違いが起きます。

  • 「Cookie を使用します」→ アプリに Cookie は存在しない
  • 「取得した情報を第三者に提供しません」→ 広告SDKが入っていて実際は送信している
  • 「アカウント削除でデータを消去できます」→ アカウント機能がない

審査は年々厳しくなっており、書いてあるのに実装がない/実装があるのに書いていないの両方向で指摘されます。

手順1: 「技術的に収集し得る情報」を洗い出させる

まず、生成AIに実装情報を渡して棚卸しさせます。渡すのは次の3点です。

  1. pubspec.yaml(依存パッケージ一覧)
  2. AndroidManifest.xml / Info.plist(権限宣言)
  3. ネットワーク処理の有無(lib/ に http クライアントがあるか)
この情報から、本アプリが技術的に収集・送信し得る情報を
「実際に収集している / 収集し得るが実装していない / 技術的に不可能」
の3分類で表にしてください。推測で断定せず、根拠のファイルを添えること。

この3分類が肝です。「収集し得るが実装していない」を明示できると、審査フォームの回答とポリシーの文言に一貫した根拠ができます。

手順2: 「何をしないか」を明文化する

収集する情報がないアプリでも、「何も集めていません」の一文で済ませるのは危険です。審査側・ユーザー側の疑問に先回りして、しないことを構造的に書くとレビューがスムーズでした。

実際に採用した章立ては次の形です。

  • 収集しない情報の列挙(氏名・位置情報・連絡先・カメラ等を明示的に否定)
  • 端末内にのみ保持する情報とその寿命(アプリ終了で破棄 等)
  • 権限を要求する理由(振動: タイマー通知のため、など権限ごとに1行)
  • 分析・広告SDKを組み込んでいないことの明言
  • 収集しない設計のため、開示・削除請求に対応すべきデータを保有しない旨

生成AIには手順1の表を渡し、「この表と矛盾する記述を一切含めないこと」を制約として章立てごとに書かせます。

手順3: ストアの審査フォーム回答を同じソースから作る

App Store の「App のプライバシー」、Google Play の「データセーフティ」は、ポリシー本文と同じ棚卸し表から回答を生成させます。ソースを分けると食い違いの温床になります。

手順1の表をもとに、Google Play データセーフティの設問に回答してください。
- 回答は「収集していない」を選べる場合は必ず選ぶ
- 「収集し得るが実装していない」項目は、収集していない扱いで良いか
  設問の定義を引用して判定すること

設問の定義(「収集」の定義にオンデバイス処理は含まれない、など)を引用させると、判定根拠が残って後から見直せます。

手順4: 実装変更時の差分チェックを仕組みにする

ポリシーは書いて終わりではなく、依存を1つ足すたびに崩れます。うちでは次の運用にしました。

  • 依存追加の PR に「データ収集への影響: あり/なし」の欄を必須化
  • 「あり」の場合は手順1の表を更新してからマージ
  • リリース前チェックリストに「棚卸し表とポリシー・審査フォームの三点照合」を追加

生成AIには差分レビュー時に「この依存追加はプライバシー記述に影響するか」を必ず聞きます。SDK のドキュメントに送信先が書かれていることも多く、人力より見落としが減りました。


日英二言語対応のコツ

ポリシーを日英で用意する場合、翻訳ではなく同じ棚卸し表から各言語で書き起こすほうが品質が安定します。法律用語の対訳(開示請求 → disclosure request 等)は用語集を先に固定してから生成させると、章ごとの揺れがなくなります。

まとめ

  • プライバシー記述は「文章生成」ではなく「実装からの逆引き」タスクとして扱う
  • 「収集し得るが実装していない」の3分類が一貫性の土台になる
  • ポリシー本文と審査フォームは同一ソースから生成して食い違いを防ぐ
  • 依存追加のたびに崩れる前提で、差分チェックを PR フローに組み込む

収集しない設計を最初から選べるなら、それが審査コストの最小化としては最強です。設計段階でこの観点を持てるかどうかで、リリース直前の負荷が大きく変わります。