01. AI生成コードをそのまま公開して大丈夫？

ここまでのフェーズで、あなたのアプリはストアに並び、実際のユーザーの手に届きました。

ここで一度立ち止まって考えたいのが、「そのコード、中身を自分で確認しましたか？」という問いです。

バイブコーディングの気持ちよさは、コードを読まなくても動くものができてしまう点にあります。しかしアプリを公開した瞬間から、そのコードは他人の端末で、他人のデータを扱って動くようになります。動くことと、公開してよいことは別の話です。

この記事では、AIが書いたコードをそのまま出すことの何が危ないのか、そして個人開発者が現実的にどこまで見ればよいのかを整理します。

1. 「動いている」と「安全である」は別物

AIエージェントが最適化しているのは、「あなたの指示どおりに動くこと」です。「安全であること」は、明示的に頼まない限り優先されません。

そのため、次のような状態がふつうに発生します。

画面には正しくデータが出るが、他人のデータも取れてしまう権限設定になっている
ログイン機能は動くが、パスワードの扱いが雑
APIは呼べるが、キーがアプリ本体に埋め込まれている
エラーは出ないが、失敗を握りつぶしているだけ

どれも「テストしたら動いた」を通過してしまいます。実機で触って確認できる範囲と、危ないコードの範囲は重なっていません。

2. AI生成コードで実際に起きやすい4つの問題

① 秘密情報のハードコード

APIキー、トークン、パスワードをソースコードに直接書いてしまうパターンです。「とりあえず動かす」ためにAIがやりがちで、そのまま公開リポジトリにpushされます。詳しくは「04. APIキーや秘密情報を漏らさないための基本」で扱います。

② 権限・アクセス制御の穴

Firestoreのセキュリティルールが allow read, write: if true; のままになっている、といったケースです。開発中は便利ですが、そのまま公開すると全世界の誰でもデータベースを読み書きできます。「05. 認証・権限・データベース設定のセキュリティチェックリスト」で扱います。

③ 入力の検証不足

ユーザーが入力した文字列をそのまま使ってしまう問題です。空文字でクラッシュする程度なら可愛いほうで、外部サービスに渡す値の検証が抜けていると、想定外の動作を引き起こします。

④ 古い書き方・非推奨APIの温存

AIは学習時点の書き方を出してくるため、すでに非推奨になったライブラリや、既知の脆弱性を抱えたバージョンを平気で選ぶことがあります。AIの提案がそのまま「現在の推奨」だとは限りません。

3. 個人開発者が現実的に見るべき優先順位

個人開発で本格的な監査をするのは非現実的です。労力に対して効果の大きい順に並べると、次のようになります。

優先度	見るところ	なぜ
1	秘密情報がコードとGit履歴に入っていないか	漏れたら回収不能。金銭被害に直結する
2	データベース・ストレージの権限ルール	他人のデータが読まれる。取り返しがつかない
3	依存パッケージの既知の脆弱性	`npm audit` で機械的に分かる。コストが低い
4	入力の検証とエラーハンドリング	クラッシュと低評価レビューに直結する
5	コードの可読性・構造	安全性そのものではないが、直せない状態を防ぐ

上の2つだけでも潰しておけば、個人開発で起こりうる事故の大半は避けられます。

まず打つべき1コマンド

依存パッケージの既知の脆弱性は、ツールが機械的に教えてくれます。

npm audit

high や critical が出たら、その内容をそのままAIに貼り付けて、影響範囲と対処方針を聞くのが早道です。

4. AI自身にセキュリティレビューをさせるプロンプト

コードを書いたAIに、役割を切り替えてレビューさせる方法が有効です。「書いた本人」ではなく「攻撃者」の視点を与えるのがコツです。

【タスク: セキュリティレビュー】

あなたは経験豊富なセキュリティエンジニアです。
これから渡すExpo (React Native) アプリのコードを、
「悪意のある第三者ならどう悪用するか」という視点でレビューしてください。

### レビューしてほしい観点
1. ソースコードや設定ファイルに、APIキー・トークン・パスワードなどの
   秘密情報が直接書かれていないか。
2. ユーザー入力をそのまま外部サービスやストレージに渡している箇所はないか。
3. データベースやストレージの権限設定に、認証チェックの抜けはないか。
4. エラーを握りつぶしていて、失敗に気づけない箇所はないか。
5. 非推奨・サポート終了のライブラリやAPIを使っていないか。

### 出力形式
- 指摘ごとに「深刻度（高・中・低）」「該当ファイルと行」「何が起きうるか」
  「具体的な修正案」の4点を書いてください。
- 深刻度の高い順に並べてください。
- 問題がない場合は「問題なし」と明記し、無理に指摘を作らないでください。

### 対象コード
[ここにレビューしたいファイルの内容を貼り付ける]

5. ライセンスと著作権という別の落とし穴

セキュリティとは別に、公開時に問題になりやすいのがライセンスです。

依存パッケージのライセンス：AIが勝手に追加したライブラリが、商用利用に制約のあるライセンス（GPL系など）である可能性があります。
アイコン・画像・フォント：AIが「これを使ってください」と示した素材が、実際には有料または再配布不可の場合があります。
生成された文章・画像：ストア掲載文やアイコンをAIに作らせた場合、そのサービスの利用規約で商用利用が認められているかを確認してください。

package.json の依存関係をAIに渡し、「各パッケージのライセンスと、商用アプリに組み込む際の制約を一覧にしてください」と頼むと、まとめて確認できます。

6. 公開前セルフチェックリスト

ソースコードとGit履歴に、APIキーやトークンが含まれていないことを確認した
データベース・ストレージの権限ルールを自分の目で読んだ
npm audit を実行し、high 以上の指摘に対応または内容を把握した
AIにセキュリティレビューをさせ、指摘内容を1件ずつ判断した
依存パッケージのライセンスに、商用利用を妨げるものがないことを確認した
アイコン・画像・フォントの利用条件を確認した

7. まとめと次のステップ

AIが書いたコードは、動くことは保証しますが、安全であることは保証しません。そして公開したアプリの責任は、コードを書いたAIではなく、公開したあなたにあります。

とはいえ、完璧を目指す必要はありません。この記事で挙げた優先度の上位2つ（秘密情報と権限設定）を潰すだけで、個人開発で起こりうる事故のほとんどは防げます。

次の記事では、セキュリティの前提となる「そもそも壊れていないか」を機械的に確認する「02. バイブコーディングで作ったExpoアプリの品質チェックリスト」に進みましょう。