AI開発のセキュリティ対策1：APIキーを書いた.envファイルを、GitHubに上げない
Git（ファイルの変更履歴を記録する仕組み）で記録したファイルは、GitHubの公開リポジトリ（誰でも見られる保管場所）に上げると、誰でも中身を読めます。
APIキーやデータベースのパスワードは、.env（秘密の設定をまとめるファイル）に書きます。
その .env を、.gitignore（Gitに含めないファイルの一覧）に入れておきます。
AIは、ファイルをGitから外す作業を人間任せにすることがあります。
論文にも、AIが作ったバックアップ機能のファイルが、そのまま公開リポジトリにコミットされた例がありました。
やることは2つです。
- ターミナルでプロジェクトのフォルダを開いて
git status を実行し、表示された一覧に .env やバックアップのファイル名が無いか見る。あれば、AIに「.envを.gitignoreに入れて」と頼む - GitHubのアカウントの Settings → Code security で、「Push protection for yourself」がオンになっているか確かめる
Push protectionは、公開リポジトリにAPIキーを含むpushをしようとしたとき、GitHubが止めてくれる機能です。
非公開のリポジトリや、GitHubが形式を知らないキーは止まらないので、git status の確認は省けません。
また、過去に一度でもコミットした .env は、git status には出てきません。
履歴まで調べるなら、対策12のプロンプトを使います。
すでに公開リポジトリに上がっていた鍵は、Gitから外すだけでは足りません。
各サービスの管理画面で無効にして、作り直してください。
AI開発のセキュリティ対策2：APIキーなどの秘密の鍵を、ブラウザから見えるコードに置かない
Webアプリのコードには、利用者のブラウザに送られて動く部分と、サーバーの中だけで動く部分があります。
ブラウザに送られた部分は、開発者ツールを開けば誰でも読めます。
.envに書いた設定値（環境変数）のうち、Next.jsで NEXT_PUBLIC_、Viteで VITE_ が付いたものは、公開用のファイルを作るときにブラウザ側のコードに埋め込まれます。
「.envに入れたから安全」ではありません。
Supabaseを使っているなら、鍵の種類にも注意が必要です。
- anonキー（publishableキー）：ブラウザに置いてよい前提の鍵。データは、データベース側で行ごとに読み書きできる人を決める設定（RLS。対策5で説明）で守る
- service_roleキー（secretキー）：RLSを素通りする鍵。ブラウザに置くと全データが丸見えになる
ここは自分で全部探すより、AIに洗い出させたほうが早いです。
Claude CodeやCursorの入力欄に、そのまま貼ってください。
このプロジェクトで、ブラウザに配られるコードに秘密の鍵が含まれていないか調べてください。
コードは変更せず、一覧だけ出してください。
・NEXT_PUBLIC_ や VITE_ が付いた環境変数と、その中身の種類
・Supabaseの service_role キー、外部APIのキーが使われている場所
・それぞれ、ブラウザから見えてしまうかどうか
「見える」と出た鍵は、サーバー側（Next.jsのAPI RouteやSupabaseのEdge Functionsなど）に移すよう、続けて頼みます。
すでにブラウザに出ていた鍵は、移したうえで作り直します。
AI開発のセキュリティ対策3：APIとクラウドに「止まる」利用上限をかける
鍵が漏れても、請求が青天井にならないようにするための備えです。
よくある勘違いが、予算アラートを設定したから大丈夫、というものです。
AWSやGoogle Cloudの通常の予算、OpenAIの「Spend alert」は、通知が来るだけで利用は止まりません。
止めたいなら、止まる設定を明示的に選びます。
- OpenAI：Project settings → Limits → Spend の「Edit spend limit」で「Enforce a hard limit」をオン
- Anthropic（Claude API）：Settings → Billing → Spend limits
- Google Cloud：spend cap budgets（Gemini APIやCloud Runなどを、上限で自動停止）
- AWS：Budget actions（上限で新しい利用を止めるポリシーを自動で適用）
- Vercel（Proプラン）：Settings → Billing → Spend Management で「Pause Production Deployments」をオン
- Supabase（Proプラン）：組織の Billing → Cost Control で Spend Cap をオン
VercelとSupabaseは、無料プランなら上限を超えた時点で止まり、追加で請求されません。
OpenAIやVercelは、反映が即時ではなく、上限を少し超えることがあると公式に書いています。
上限は、払ってもいい額より少し低めに置いてください。
公式LINEで「AIに貼るだけのセキュリティ点検プロンプト」を無料配布中
対策12で紹介するプロンプトは問題を一覧にするところまでですが、LINEで配っているプロンプトは、この記事の12個すべてを順に確認します。コードで直せるものはAIが直し、利用上限や2段階認証のような管理画面の設定は、手順を案内します。受け取り方法は、SiiDの公式LINEに登録して、メッセージで「セキュリティ」と送ってください。
AI開発のセキュリティ対策4：別アカウントで、他人のデータが見えないか試す
AIで作られた公開アプリ200本を調べた論文で、一番多かったのがアクセス制御の不備です。
ログインしていない人や他人が、見てはいけないデータを見たり書き換えたりできてしまうセキュリティホールで、調べたアプリの64%にありました。
これは、画面を触るだけでできる検査で確かめられます。
- テスト用のアカウントを2つ作る（AとB）
- Aでログインして、自分のデータのページを開く（URLが
/orders/123 のようにIDつきになっていることが多い） - そのURLをコピーして、Bでログインし直して開く
- IDが数字なら、1つずらしても開いてみる
自分以外のデータが見えたらアウトです。
AIは「本人のデータだけを見せる」を、頼まれない限り入れないことがあります。
原因の1つ目、「頼まれていない対策を入れない」の典型です。
ただし、この検査で分かるのは画面に出る範囲だけです。
画面側で自分のデータだけに絞って表示していると、データベース側の守りが甘くても、ここでは見つかりません。
そこは対策5と対策6で確かめます。
AI開発のセキュリティ対策5：データベース側で、データごとに読み書きできる人を制限する
SupabaseやFirebaseで作ったアプリは、多くの場合ブラウザから直接データベースを読み書きします。
この作りでは、データベースに設定する「誰がどのデータを読み書きできるか」の決まりが唯一の守りです。
自分のアプリがこの作りか分からなければ、AIに「ブラウザから直接Supabase（またはFirebase）を読み書きしている箇所はある？」と聞けば分かります。
自分のサーバーを挟んでいる場合は、対策6で守ります。
Supabaseでこの役割を担うのが、RLS（行レベルセキュリティ）です。
行ごとに、誰が読み書きできるかをデータベース側で決める設定で、Firebaseではセキュリティルールがこれに当たります。
テーブル（データを表の形でしまっておく単位）のうち、ブラウザから直接読み書きできるようにしてあるものにRLSが無いと、ブラウザに置いたanonキーさえあれば、誰でも中身を読み書きできます。
2026年1月には、AIエージェント向けのSNS「Moltbook」で、まさにこれが起きました。
セキュリティ企業のWizによると、ブラウザ側のコードにSupabaseのキーがあり、RLSが未設定でした。
その結果、約475万件のデータ（APIキー150万件を含む）がログインなしで読めて、一部は書き換えもできる状態だったそうです。
AIで作ったと、創業者本人が明言していたアプリです。
確認する場所は次のとおりです。
- Supabase：ダッシュボードの Security Advisor で、RLSが無効なテーブルの警告が出ていないか見る
- Firebase：ルールに
allow read, write: if true; が残っていないか見る（公式が「本番では絶対に使わない」と書いている設定）
Supabaseのダッシュボードで作ったテーブルはRLSが最初からオンですが、SQLやマイグレーション（データベースの構造を変更する手順をファイルにしたもの）で作ったテーブルはオフのことがあります。
AIはSQLやマイグレーションでテーブルを作ることが多いので、ここは要注意です。
警告が出たら、AIに「このテーブルのRLSを有効にして、読み書きできる人を絞って」と頼みます。
マイページのデータなら本人だけ、掲示板の投稿なら読むのは全員で書くのは本人だけ、のように、誰に何を許すかを一緒に伝えます。
また、RLSは「オンになっている」だけでは足りません。
「ログインしていれば誰でも全部読める」のようなルールでも、オンはオンです。
ルールの中身は、対策12のプロンプトの6番で洗い出します。
なお、Supabaseは2026年10月30日から、既存のプロジェクトでも、新しく作ったテーブルを自動ではAPIに公開しなくなります。
このあと「テーブルがAPIから見えない」というエラーが出てAIに直させると、テーブルをAPIに公開し直すときにRLSを付け忘れることがあります。
直したあとは、Security Advisorをもう一度見てください。
AI開発のセキュリティ対策6：ログインと本人確認のチェックを、サーバー側の全APIに入れる
ここで言うAPIは、アプリの画面がデータの読み書きを頼むときに、サーバー側で受け付ける窓口のことです（/api/orders のようなURL）。
冒頭の論文では、アクセス制御の不備の77%がこのバックエンド（サーバー側）にありました。
新しく作った窓口にだけ「正しい鍵を持っているか」の確認を入れて、前からある11個は誰でも呼べるまま、という例も出てきます。
原因の3つ目、「前に決めたことを忘れる」の例です。
自分で全部の窓口を調べるのは大変なので、AIに表にしてもらいます。
このプロジェクトのAPI（エンドポイント）を全部一覧にしてください。コードは変更しないでください。
それぞれについて、次の2つがサーバー側で確認されているかを表にしてください。
・ログインしているか
・リクエストしたユーザー本人のデータか（または、その操作をしてよい権限があるか）
確認が無いAPIが出てきたら、「このAPIに、サーバー側でログインと本人の確認を入れて」と続けて頼みます。
AI開発のセキュリティ対策7：フォームの入力欄から不正な命令を送り込まれる「インジェクション」を防ぐ
インジェクションは、冒頭の論文で2番目に多く、54%のアプリにありました。
AIが書いたコードの中では、検索欄などに入力された文字が、データベースへの命令文（SQL）や画面のHTMLにそのままつなげられていることがあります。
そうなっていると、入力欄に命令を書き込まれたときに、それが命令として実行されてしまいます。
コードを読んで探すのは難しいので、AIに次の2点を調べさせます。
- SQL：入力された文字を、文字列でつなげてSQLを組み立てていないか（Supabaseのクライアントや、Prismaなどのライブラリ経由で読み書きしていれば、基本は大丈夫）
- HTML：
dangerouslySetInnerHTML や innerHTML に、入力された値をそのまま入れていないか
Claude Codeなら、公式の security-guidance プラグインを入れておくと、こうした書き方を見つけて指摘してくれます。
ターミナル版のClaude Codeの入力欄で、次を実行します。
/plugin install security-guidance@claude-plugins-official
指摘はClaudeに返り、Claudeがその場で直す仕組みです。
見逃しもあるので、何を直したかには目を通してください。
Cursorを使っているなら、対策12のプロンプトで同じ箇所を洗い出せます。
AI開発のセキュリティ対策8：ログイン機能は一から作らず、認証サービスの標準機能を使う
ログインの仕組みに抜けがある「認証の不備」は、同じ論文で3番目に多く、51.5%のアプリにありました。
論文には、こんな例もありました。
- ログイン状態を示す文字列（OAuthトークン）を、base64（ただの変換で、暗号ではない）にしただけでブラウザに保存（誰でも元に戻せるので、盗まれればそのままログインされる）
- Supabaseのログインが動かないので、AIが「固定のIDとパスワードならログインを通す処理」を足して直した
どちらも、原因の2つ目「目の前の目的を優先する」から生まれています。
ログインの仕組みは、Supabase AuthやFirebase Authenticationのような、ログイン機能を部品として提供するサービス（認証サービス）に任せます。
すでに作ったアプリなら、AIに「ログインは認証サービスの標準機能だけで動いている？独自に書いた処理はある？」と聞き、独自の処理があれば標準機能に置き換えるよう頼みます。
それでも、固定のIDとパスワードで通すような直し方は起きるので、ログイン周りのエラーをAIに直させたら、対策12のプロンプトの5番で、制限を緩めていないか確かめてください。
AI開発のセキュリティ対策9：入れたパッケージが実在するか確かめる
AIは、存在しないパッケージ名を提案することがあります。
独立研究者による査読前の再検証では、2026年時点の主要なAIモデル5つで、提案したパッケージ名の4.6〜6.1%が実在しないものでした。
この名前を攻撃者が先に登録して、悪いコードを仕込んでおく手口があり、IPAの「情報セキュリティ10大脅威 2026」の解説書でも取り上げられています。
やることは3つです。
- 知らないパッケージは、npmのページで公開日とダウンロード数を見てから入れる
- GitHubのアカウントの Settings → Code security で、Dependabot alerts を「Enable all」にする（既知の脆弱性があるパッケージを知らせてくれる）
npm audit で確認し、警告が出たら npm audit fix を実行する（大きな更新まで入れる --force は付けない）
それでも残った警告は、AIに「この警告が自分のアプリに影響するか」を聞いてから判断します。
AI開発のセキュリティ対策10：自分のアカウントは、パスキーか2段階認証で守る
アプリをどれだけ固めても、GitHubのアカウントが乗っ取られたら、コードもホスティングもデータベースの設定も持っていかれます。
IPAに届け出のあった不正アクセスの実被害85件でも、原因として最も多かったのは「ID・パスワード管理の不備」でした。
守るのは、次のアカウントです。
- メールアカウントとGoogleアカウント（パスワード再設定が届き、ほかのサービスのログインにも使うので、いちばん先に）
- GitHub
- Vercelなどのホスティング、Supabaseなどのデータベース
- OpenAIなどAPIの管理画面
- ドメインの管理画面
パスキーが使えるサービスは、パスキーにします。
指紋や顔認証でログインでき、偽のログイン画面に入力させられる心配もありません。
パスキーが無いサービスは、Google Authenticatorなどの認証アプリを使った2段階認証にします。
SMSは電話番号を乗っ取られると破られることがあるので、避けたほうが安心です。
AI開発のセキュリティ対策11：アプリの利用者にも、2段階認証などの安全なログイン方式を用意する
作るアプリの利用者のログインも、同じように守れます。
対策8のとおりログインを認証サービスに任せたら、次は、どの方式でログインさせるかを選びます。
- マジックリンク：メールに届くリンクを開くだけでログインできる。パスワードを盗まれる心配がなく、利用者も楽。ただし、守りの強さは利用者のメールアカウント次第。Supabase AuthもFirebase Authenticationも標準で使える
- 2段階認証：パスワードに加えて、認証アプリに出るコードを求める。Supabase Authは標準で使える。Firebase Authenticationは「Identity Platform」へのアップグレードが必要
- パスキー：指紋や顔認証でログインできて、偽のログイン画面にも引っかからない。Supabase Authは2026年5月からベータ提供中。Firebase Authenticationには標準機能が無い
迷ったら、どちらのサービスでも標準で使える2段階認証を入れます。
利用者の手間を減らしたいなら、マジックリンクにします。
AIに頼むときは、「Supabase Authの標準機能で、認証アプリの2段階認証を入れて」のように、使うサービスと方式を名指しします。
AI開発のセキュリティ対策12：AIへの頼み方を、作るときと見直すときで変える
AIへの頼み方は、次のように変えます。
- 作らせるとき：細かい技術指示を並べず、「本番運用に耐えるものを」と一言足す
- 見直させるとき：「変更を見直して」で済ませず、見る場所を指定する
根拠は、論文の実験です。
実際にセキュリティホールが入った機能を、入る前の状態に戻し、頼み方を変えてAIにもう一度作らせました。
同じセキュリティホールがまた入った割合が、次の図です。
何も足さないと25.7%で、「本番運用に耐えるものを」と一言足すと11.0%まで下がりました。
細かい技術指示を書き込むと、逆に45.7%に増えています。
上位のモデルに替えても26.2%で、ほぼ変わりませんでした。
ただ「変更を見直して」と足すだけでも23.8%で、ほとんど下がっていません。
この実験はOpenAIのGPT-5.6系のモデルで行ったもので、ほかのモデルで同じ数字になるとは限りません。
細かい指示があると、AIは書かれた仕様を文字どおりに実装して、自分で安全を判断する余地が減る、と論文は分析しています。
ここで言う「細かい技術指示」は、コードの書き方や処理の手順を一つひとつ指定することです。
誰に何を見せるか、どのログイン方式にするか、どの認証サービスを使うかといった「何を作りたいか」は、これまでどおり具体的に伝えてください。
対策11の頼み方は、こちらに当たります。
論文も、公開前に「後回しにしたTODO・ログインと権限の流れ・入力の扱い・秘密の鍵」を確かめるよう勧めています。
それを、そのまま頼む形にしたのが次のプロンプトです。
Claude CodeやCursorの入力欄に貼ってください。
このアプリを本番公開する前のセキュリティ確認をしてください。
コードは変更せず、問題点を一覧にしてください。
1. TODO・FIXME・仮実装のまま残っている処理（特にログイン・パスワード・権限まわり）
2. すべてのAPIで、ログインの確認と「本人のデータか」の確認がサーバー側で行われているか
3. ユーザーの入力を、そのままSQL・HTML・コマンドに使っている箇所
4. ブラウザに配られるコードやGitの履歴に、秘密の鍵が含まれていないか
5. エラーを直すために、ログインやアクセスの制限を緩めた箇所
6. Supabaseを使っている場合、RLSで「誰でも」「ログインしていれば誰でも」読み書きできるテーブル
それぞれに、重要度（致命的／高／中／低）と、該当するファイルと行を付けてください。
プロンプトの1番のTODOは、件数こそ少ないものの、論文では9割が「致命的」か「高」でした。
「あとで追加」と書いたまま公開されたログイン処理は、ほぼそのままセキュリティホールになります。
一覧が出たら、「致命的」と「高」から順に、1件ずつ直すよう頼みます。
なお、Claude Code標準のセキュリティ確認コマンド /security-review は、GitHubに上げたmainとの差分しか見ません。
プロジェクト全体を点検したいときは、上のプロンプトを使ってください。
AI開発のセキュリティ対策は、まずこの4つから始める
12個を一度にやるのが大変なら、設定と確認だけで済む次の4つから始めてください。
- 対策1：.envがGitに入っていないか見る
- 対策3：「止まる」利用上限をかける
- 対策4：別アカウントで他人のデータが見えないか試す
- 対策10：自分のアカウントにパスキーか2段階認証をかける
残りは、対策12のプロンプトを1回流して、出てきたものから直していきます。
12個の対策を、AIに貼るだけで進められるプロンプトにしました
この記事の12個を、AIにそのまま渡せるプロンプト1本にまとめて配っています。12個を順に確認し、コードで直せるものはAIが直し、管理画面の設定は手順を案内するので、コードが読めなくても進められます。直した内容には目を通してください。SiiDの公式LINEに登録して、メッセージで「セキュリティ」と送ると、無料で受け取れます。
AI開発のセキュリティ対策の出典
AIプログラミングスクール「SiiD」について
AIプログラミングスクール「SiiD」は、未経験からITエンジニア転職を目指す方向けのオンラインスクールです。
SiiDの特徴
- 現役エンジニアでYouTube登録者約13万人の「セイト先生」が代表兼主任講師
- 採用側の実務知見（2,000人以上の選考・150名以上のエンジニア採用）にもとづく指導
- 生成AIを取り入れた学習設計と、実務レベルのフルスタックWeb開発スキル
- Workship CAREER（株式会社GIG）と連携した無料の転職伴走支援
- 経済産業省認定のReスキル講座で、給付金の条件を満たせば実質105,600円〜
- 学割あり（35%オフ）
こんな方におすすめ
- 未経験・文系・社会人からITエンジニア転職を本気で目指したい方
- 独学に限界を感じている方
- 費用を抑えながら実務スキルと転職サポートを両立したい方
「未経験だから」とあきらめる必要はありません。採用する側を知り尽くしたプロが、給付金で負担を抑えながら内定まで伴走します。
.png&w=3840&q=75)
