【アプリエンジニア監修】Claude Codeで作ったアプリ、そのまま公開して大丈夫？ストアに出す前のセキュリティ診断を、Claude Codeにやってもらうスキル（Flutter × Firebase / Supabase）

Claude Code でアプリができた。動いた。あとはストアに出すだけ。

その前に、ひとつだけ確かめてほしいことがあります。そのアプリ、他人が中身を開けても困らない作りになっていますか。

AI は「動くもの」を最短で作ってくれます。ただ、最短の道は、安全な道と同じとは限りません。決済や AI の秘密の鍵をアプリの中に直接書く。データベースを「誰でも読み書きできる」設定のまま動かす。どちらも、動作確認では何も困らないので、気づかないまま公開されます。

僕はアプリエンジニアとして、システム開発の仕事を5年やってきました。今は Claude Code で作ったぬりえアプリ「いろつな」を App Store に出して、1人で運用しています。

この記事では、ストアに出す前のセキュリティ診断を Claude Code にやってもらうためのスキル（Claude Code に読み込ませる手順書と診断プログラムのセット）を配布します。入れて /security-check と打つと、危ないところを日本語で教えてくれて、安全に直せるものは1件ずつ確かめながら直します。

こんな人のための記事です

• Claude Code（や Cursor など）で、Flutter のアプリを作っている

• バックエンドは Firebase か Supabase

• プログラミングは勉強中、または AI に任せている

• 「セキュリティ」と言われても、何を見ればいいのか分からない

• ストアの審査や、公開後のトラブルが正直こわい

逆に、セキュリティの専門家の監査の代わりにはなりません。そこは最後にはっきり書いています。

AI で作ったアプリで、よく起きていること

海外では「バイブコーディング（AI に任せてアプリを作ること）で作ったアプリから、鍵や個人情報が漏れている」という調査が何本も出ています。数千件単位で、ChatGPT の API キーがそのまま公開されていた、という報告もあります。

難しい攻撃ではありません。だいたい、次のどれかです。

1. 秘密の鍵がアプリに直接書いてある
Stripe（決済）や OpenAI の鍵を、AI が「とりあえず動くように」コードに書いてしまうパターン。アプリの中身は、配布した時点で誰でも取り出せます。鍵を使われると、決済を操作されたり、AI の利用料を勝手に使われたりします。

2. データベースが「誰でも読み書きできる」まま
Firebase の「テストモード」や、Supabase で RLS（行ごとの見せる・見せないのルール）を入れていないテーブル。ログインしていない人も含めて、全員のデータを読めて、消せる状態です。

3. 「.env に入れたから安全」という思い込み
.env にまとめて、アプリの assets に入れる書き方をよく見ます。でも、アプリに同梱したファイルは配布物の一部です。中身は取り出せます。

4. 秘密の値やログイン情報を print でログに出している
動作確認のために入れた print が、そのまま残る。リリース版でも端末のログに出ます。

どれも、アプリは普通に動きます。だから気づけません。

このスキルでできること

入れたら、Claude Code にこう打つだけです。

/security-check

すると、こう進みます。

1. 診断：プロジェクトの中を調べて、危ないところを重大な順に、日本語で説明する（ここでは何も書き換えない）

2. 直す範囲を選ぶ：安全に直せるもの（.gitignore への追記など）は自動で。それ以外は番号で選んで、OK したものだけ

3. 1件ずつ直して確かめる：直すたびに、アプリが壊れていないか（静的解析とテスト）を確かめる。だめなら、その修正だけ取り消す

4. レポート：直したこと、あなたが手でやること（鍵の作り直し、Firebase の画面での設定など）、調べていないことをまとめる

テスト用のアプリで実行した例です（鍵は偽物です）。

調べるのは、たとえばこういうところです。

• 秘密の鍵：Stripe・OpenAI・Anthropic・GitHub・AWS の鍵の直書き、Supabase の service_role キー、サービスアカウントの鍵ファイル

• Git：.env や署名鍵が Git に記録されていないか、.gitignore に入っているか

• .env：アプリに同梱していないか（どの変数が秘密らしいかも名前で教える）

• データベース：Firestore / Storage のルールが全開放・テストモードでないか、Supabase の RLS が有効か

• Android / iOS：暗号化しない通信の許可、バックアップ設定、本番ビルドの署名、権限の説明文が空でないか（空だと審査で却下される）

• アプリのコード：ログイン情報を暗号化せずに保存していないか、秘密をログに出していないか、http:// の通信

「壊さない・消さない」を一番大事にしました

AI に自動で直させるのは便利です。ただ、非エンジニアの方にとって一番こわいのは、直してもらったら動かなくなった、元に戻し方が分からないことだと思います。なので、そこを一番作り込みました。

• 秘密の値を AI に読ませません。 .env や鍵ファイルの中身は開きません。結果に出てくる鍵は伏せ字です

• 作業用の別のブランチで直します。 直す前に今の状態を保存して、security-check/日付 という場所で作業します。元の状態はそのまま残ります

• 作業を消すコマンドを使いません。 git reset --hard のような、まだ保存していない作業ごと消えるコマンドは使わない決まりにしています

• 1件ずつ確かめます。 直したらテストを回して、だめならその修正だけ戻します

• 大きな変更は勝手にしません。 パッケージの大きな更新、データベースのルールの本番への反映、ストアへの提出はしません

実際に試した結果

作った本人が試すと、手順書に書いていないことを無意識に補ってしまいます。なので、このスキルの手順書だけを渡した別の Claude に、テスト用のアプリで最初から最後まで実行してもらいました。

用意したのは、性格の違うアプリです。

• Firebase で作った、危ない書き方を詰め込んだアプリ

• まだ .env を Git に記録していないアプリ（直す前の保存で、秘密を巻き込まないかの確認用）

• Supabase で作ったアプリ（service_role キーの混入、RLS の入れ忘れ）

• 問題のないアプリ（余計なことをしないかの確認用）

• そして、実際に App Store に出している自分のアプリ「いろつな」

テスト用の4つのアプリは、手順書を直すたびに作り直して、2回ずつ（計8回）通しで実行しました。最後の回の結果です。

• Firebase（危ない書き方を詰め込んだもの）：見つかった問題：17件（重大4） ／ スキルが直したもの：8件（ルールのテストモード、ログへの秘密の出力、ログイン情報の暗号化保存など） ／ 手作業として残したもの：鍵の作り直し、.env の Git からの除外、http の相手先の確認など

• .env を記録していないもの：見つかった問題：16件（重大3） ／ スキルが直したもの：8件 ／ 手作業として残したもの：同上。.env は一度も Git に記録されませんでした

• Supabase：見つかった問題：10件（重大1） ／ スキルが直したもの：6件（RLS を2つのテーブルに、http→https など） ／ 手作業として残したもの：service_role キーの作り直し、署名の設定

• 問題のないもの：見つかった問題：1件（低） ／ スキルが直したもの：1件 ／ 手作業として残したもの：なし

最後の回では、4つのアプリすべてで次のことを確かめました（1回目で守れていなかった点は、手順書を直してから2回目を実行しています）。

• 直したあとも、アプリの静的解析とテストがすべて通った（だめだった修正は、その分だけ戻す決まりです。最後の回は戻すものがありませんでした）

• 元のブランチには修正が1つも入っていない（入ったのは、作業中だった変更の保存だけ）

• 秘密の値を AI が読んでいない（鍵は最初から最後まで伏せ字でした）

• 鍵を平文で送っている相手先に「http を許す例外」を作らなかった

「いろつな」は、重大・高の問題はゼロでした。

途中で見つかった弱点もあります。たとえば最初の版では、直す前の保存のときに、まだ記録していない .env まで一緒に保存してしまう可能性がありました。今の版では、保存の前に必ず確かめて、秘密のファイルは保存しないようにしています。ほかにも、1回目では「直したものが元のブランチにも入ってしまう」「鍵を平文で送っている相手先に、http を許す例外を作ってしまう」「Supabase のテーブルを誰が読めてよいかを AI が勝手に決めてしまう」といった点が見つかりました。どれも手順書を直し、2回目で起きないことを確かめています。

診断の部分には、テスト用のアプリをその場で作って確かめる自動テストも付けています（74項目）。

よくある誤解も、ちゃんと説明します

診断していて一番多いのが、Firebase の API キー（AIza で始まるもの）を「漏れている」と思ってしまうケースです。

これは漏洩ではありません。Firebase の API キーはアプリに入るのが正常で、守りはルールと App Check でやります。英語の無料のツールの中には、これを「危ない」と出すものもあって、慌てて消すとアプリが動かなくなります。このスキルは「これは秘密ではありません。代わりにこれを設定してください」と案内します。

同じように、「.env に入れれば安全」「問題なしと出たら絶対安全」も誤解です。レポートでは、調べていないことも必ず書くようにしています。

この記事で手に入るもの

• security-check スキル一式（ダウンロード）（Claude Code が従う手順書）（診断プログラム（Flutter に入っている Dart だけで動きます。追加のインストールはいりません））（項目ごとの説明と直し方のガイド）（安全なルールのひな形（Firestore / Storage））

• 導入手順（3分）と、うまく動かないときの直し方

• 結果の読み方：重大・高・中・低・情報の意味と、どれから手をつけるか

• 手作業の項目の進め方：Stripe / OpenAI / Supabase / Firebase の鍵の作り直し、Firestore のルールの安全な反映のしかた、Supabase の RLS の入れ方

• 元に戻す方法

• よくある質問

価格は 1,980円 です。

自分で1つずつ調べると、何を見ればいいかを知るところからで、丸1日はかかると思います。それを Claude Code に打つ1行にまとめました。