Vibe Codingのセキュリティ：AIで作ったアプリを守る方法

Ailootの使い方については、ドキュメントをご覧ください。

AIで作ったアプリはなぜハッキングされやすいのか？#

私自身もAIでプロダクトを作っていますが、セキュリティについて「すべてを最大限にロックダウンする」ほど神経質にはなりません。しかし、下回ってはいけない基本的な水準があります。そうしないと、ある日目を覚ましたときにはデータベースが空になり、サーバーでは他人のマイナーが動いているかもしれません。このガイドでは、その基本水準を扱います。「セキュリティの専門家になる」のではなく、「理由もなく自分の足を撃たない」ための話です。

問題の根本は単純です。AIエージェントに「顧客の予約用アプリを作って」と伝えると、できるだけ早くアプリを動く状態にします。セキュリティはデモでは見えない余分な作業です。そのため、データベースは公開状態に設定され、決済キーはコードにそのまま入り、「このユーザーにはアクセス権があるか」というチェックはブラウザー内にしか存在せず、そこなら一瞬で回避できます。

2つ目の理由はプラットフォームそのものです。

つまり、穴はデフォルトで自然に生じます。あなたが何か悪いことをしたわけではありません。ただ何もしなかっただけです。そしてセキュリティでは、何もしないことはまさに「誰にでも公開する」という意味になります。

Vibe Codingの開発者がすでに痛い目を見て学んだこととは？#

不注意への最良の予防策は、他人の失敗から学ぶことです。プロジェクトを公開する前に目を通しておきたい報告を4つ紹介します。

Lovableと無効化されたRLS。 Lovableプラットフォームは、テキストの説明からアプリを作成します。2025年、そのアプリにシステム上の穴が見つかり、CVE-2025-48757が割り当てられました。原因は、生成されたアプリにデータベースの行レベルアクセスルール（RLS、後述）がなかったことです。研究者がサンプルを調べたところ、170個のアプリで303か所のアクセスポイントが露出していました。名前、電話番号、決済状況、他人のAPIキー、さらには自宅住所まで公開されていました。調査対象の約70パーセントのアプリで、行レベル保護が完全に無効になっていました。

Teaと機微データ。 人々について匿名でレビューするTeaアプリでは、2025年7月に約72,000枚の画像が失われました。そのうち13,000枚は自撮りや書類の写真でした。その後、100万件を超えるプライベートメッセージも漏えいしました。技術的な原因は、公開状態のストレージと弱いアクセスチェックでした。セキュリティコミュニティは、Teaを鮮明な事例として挙げています。権限の確認より迅速な公開が優先されると、機微データが最初に漏えいします。

もうひとつの実例。 原著者が説明した事例では、AIがデータベース作成時に自動で推測できるデフォルトパスワードを設定したため、あるVibe Coding開発者のアプリがハッキングされました。その後はお決まりの展開です。侵入され、マイナーがインストールされ、プロジェクトが書き換えられました。サーバーは完全に消去する必要がありました。デフォルトパスワードは、「どうぞお入りください」の看板を掲げた、鍵のかかっていないドアです。

セキュリティの2つの側面：どこに脆弱性があるのか？#

「Vibe Codingのセキュリティ」について話すとき、人々はまったく異なる2つの不安をひとまとめにしがちです。対策がそれぞれ異なるので、分けて考えましょう。

1つ目の側面—エージェントそのもの。 AIエージェントを自分のコンピューターで実行し、ファイル、ターミナル、キー、データベースへのアクセスを与えます。エージェントは人間ではなく、指示に文字どおり従い、たとえ危険でも最短の道を見つけることがリスクです。また、読み込んだテキストを通じて、他人のコマンドがエージェントに「注入」されるリスクもあります（これはプロンプトインジェクションと呼ばれます）。

2つ目の側面—完成したアプリ。 これは公開したもので、人々が使うものです。攻撃対象は公開済みのサイトやサービスです。攻撃者は公開データベースに侵入し、偽のリクエストを送信したり、他人のアカウントを推測したりします。これにエージェントは関係ありません。穴はそれより前に残され、他人がそれを悪用するのです。

Claudeを開発するAnthropicは、主要な保護原則を次のように述べています。この原則は両方の側面に当てはまります。

実際には、これは「AIが自分で悪いことを避ける」と期待してはいけないという意味です。まず、物理的にできることを制限し、その後で適切に振る舞うよう求めます。AIの振る舞いが破綻したとき（必ず破綻します）、事前に設定した強固な境界だけがあなたを守ります。

AIエージェントはコンピューターへのアクセスで何ができるのか？#

最も過小評価されているリスクは、権限を広く与えすぎた自分のエージェントです。外部のハッカーがいなくても起こります。最近の例として、2026年5月下旬の事例を紹介します。Codexエージェントは、ユーザーが持っていない管理者権限を必要としていました。エージェントはあきらめず、周囲を調べ、ユーザーが docker グループに属していると気づきました。このグループは実質的にrootと同等で、そのアクセス権を利用しました。

ここに悪意はありません。「タスクを解決して」と指示されたエージェントが、人間よりも速く構造的な弱点を見つけるというだけです。そしてその弱点からキーや本番環境にアクセスできれば、利用します。したがって、ルールその1は最小権限です。特定のタスクに必要なアクセスだけをエージェントに与え、それ以上は一切与えないでください。

これは私の想像ではありません。ジョンズ・ホプキンス大学の研究者たちは、Anthropic、Google、Microsoftの本番エージェントを攻撃しました。彼らの結論は厳しいものです。

プログラマーではなくても、実際にできることは何でしょうか？

1. 本番マシンで「すべて許可」モードを使ってエージェントを実行しない

   エージェントが確認を求めないモード（多くの場合、bypassまたはyoloと呼ばれます）は、サンドボックスまたはテストプロジェクト専用です。稼働中のキーや本番環境へのアクセスを保持するマシンでは使いません。

2. エージェントにシークレットを読ませない

   Claude Codeでは、キーを含むファイルへのアクセスを拒否するルールを設定します。すると、エージェントが .env を開こうとしても、ツールが許可しません。

3. 本番キーを分けて保管する

   本番データベースや決済サービスのキーを、エージェントがコードを書くフォルダーに置いてはいけません。環境を分け、実験にはテスト用キーを使います。

4. ツールのサンドボックスを使う

   最新のAIツールでは、システムの他の部分にアクセスできない隔離環境（サンドボックス）でコマンドを実行できます。Claude Codeでは権限リクエストが約84パーセント減るため、利便性も向上します。

Claude Codeでシークレットの読み取りを拒否するルールは、おおよそ次のようになります。権限設定に記述してください。

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

APIキーやパスワードを絶対に置いてはいけない場所は？#

最も安価で、最もよくある間違いは、キーをコードに入れることです。決済サービスのAPIキー、データベースのパスワード、ボットのトークン、これらはすべてシークレットです。別の .env ファイルに保管し、そのファイルがコードとともにgitに入らないよう .gitignore に記載してください。

2025年の問題の規模は、新たにハードコードされたシークレットが公開リポジトリで2,865万件、前年比34パーセント増でした。AIサービス用のキーの漏えいは81パーセント増加しました。エージェントが確認せずにコミットするため、Vibe Codingは火に油を注ぎます。

今すぐ手作業で確認すること：

1. プロジェクトの.gitignoreファイルを開く

   .env の行があることを確認してください。なければ、最初のコミットの前に追加します。

2. GitHubリポジトリを開く

   .env ファイルがないことを確認します。リポジトリ内で .env やキーの一部を検索すれば、すばやく確認できます。

3. キーが漏えいした場合は失効させて再発行する

   コミットを削除するだけでは不十分です。キーはすでに盗まれている可能性があります。サービス（決済プロバイダー、クラウドサービス、AIプロバイダー）にアクセスし、古いキーを失効させて新しいキーを発行します。これをローテーションと呼びます。

4. キーの権限を必要最小限にする

   読み取りにしか使わないキーなら、読み取り専用にします。漏えいしても、盗まれるものを減らせます。

RLSがないと誰でもデータベースを見られるのはなぜ？#

Supabaseや類似のデータベースでアプリを作っているなら、ここが最も重要なセクションです。RLSはRow Level Securityの略です。簡単に言うと、あるテーブルのどの行を特定のユーザーに表示するかを決めるルールです。RLSがなければ、「orders」テーブルはすべての顧客の注文を全員に返します。

Supabaseの公式ドキュメントには、簡潔にこう書かれています。

そして、ここがVibe Codingの開発者にとっての主な落とし穴です。Supabaseのダッシュボードをクリックしてテーブルを作成すると、保護機能は自動で有効になります。しかしAIがテーブルを作成すると（ほとんどの場合、SQLコマンドを直接書きます）、RLSはデフォルトで無効のままです。つまり、エージェントが生成したテーブルは、ほぼ確実にインターネット全体に公開されています。Lovableの170個のアプリで漏えいが起きたのも、まさにこれが原因でした。

対処法：

1. エージェントに直接聞く

   「RLSが無効になっているテーブルをすべて表示してください」と書きます。AIがリストを作成するので、それを作業リストとして使います。

2. ユーザーデータがあるすべてのテーブルでRLSを有効にする

   そして、少なくとも1つアクセスポリシーを追加します。たとえば、「ユーザーは自分の行だけを見られる」というポリシーです。

3. ダッシュボードを確認する

   Supabaseのダッシュボードで、すべてのテーブルに「RLS enabled」と表示されている必要があります。灰色または赤色なら、テーブルは公開状態です。

4. 実際にテストする

   一般ユーザーとしてサインインし、他人のデータをリクエストしてみます。アクセスが拒否されれば、ポリシーは機能しています。

インターフェース上の権限チェックでは守れないのはなぜ？#

よくある思い込みは、「一般ユーザーには管理ボタンが見えないようにした」というものです。問題は、ボタンがブラウザーに表示された画像にすぎないことです。ボタンを使わなくても、リクエストをサーバーに直接送信できます。サーバーが権限を再度チェックしなければ、他人のコマンドを実行してしまいます。

典型例はIDORと呼ばれます。id=123 のアドレスで自分の注文を開いたとします。id=124 に変えると、サーバーがそれが自分の注文かどうかを確認していなかったため、他人の注文が見えてしまいます。これはVibe Codingアプリで最もよくある穴のひとつで、弱い権限チェックがTeaの漏えいの原因でした。

ルールは単純です。「このユーザーはこれを実行してよいか」というチェックをサーバー上でも必ず繰り返すこと。インターフェースは利便性のためのもので、保護はバックエンドで行います。エージェントに使える指示文は次のとおりです。「ユーザーデータを読み書きするすべてのエンドポイントにサーバー側の権限チェックを追加してください。インターフェース上で要素を隠すことに依存しないでください。」

プログラマーでなくてもコードの穴をチェックするには？#

朗報です。現在は同じAIにセキュリティチェックを頼めます。よくある穴の発見には、かなり役立ちます。用途の異なる3つのツールを紹介します。

1. Claude Codeの /security-review コマンド。 現在のブランチを一度チェックし、SQLインジェクション、XSS、認可の穴、データ漏えい、依存関係の問題を調べます。仕組みと、変更ごとに自動チェックを実行する方法については、Claude Codeのセキュリティレビューの別ガイドで手順を説明しました。ここで重要なのは、これが最初の防衛線であり、1つのコマンドで実行できることです。

2. 公式security-guidanceプラグイン。 公式プラグインマーケットプレイスから /plugin install security-guidance@claude-plugins-official でインストールします（Claude Code 2.1.144以降が必要です）。コードを編集するたび、各ターンの終了時、コミット時の3つのタイミングでチェックします。認可の回避、IDOR、インジェクション、弱い暗号化を検出します。ただしAnthropicは、その限界について率直に述べています。

npx skills add <author>/<repo>

あとはエージェントに「プロジェクトの脆弱性をチェックしてください」と伝えるだけです。ただしこのスキル集には重要な注意点があるため、後のセクションで詳しく説明します。

参考までに、大手企業もAIコードのセキュリティを重視し始めています。2026年6月2日に150の組織へと拡大したProject Glasswingの一環として、パートナーはAnthropicのモデルを使い、短期間で10,000件を超える重大な脆弱性を見つけました。リスクの大きさは明らかです。

GitHubのスキルや拡張機能は信頼できるのか？#

ここは特に厄介です。セキュリティのためにインストールしたツールそのものが危険の原因になるからです。npx skills add ... を実行したり拡張機能をインストールしたりすると、他人のコードを取り込み、エージェントがあなたの権限で実行します。作者がハッキングされていたり、最初からパッケージが悪意あるものだったりすれば、問題になります。

前のセクションで取り上げたスキル集を例にしましょう。名前に「Anthropic」が含まれているため、警戒が緩みます。しかしREADMEには、次のように明記されています。

つまり、誤解を招く名前です。スキル集自体は現在、成熟していて問題ありませんが、原則は変わりません。インストールは自己責任です。脅威は仮定の話ではありません。2026年5月、悪意あるエディター拡張機能がマーケットプレイスに存在したのはわずか18分でした。その間に、インストールした人々のパスワードマネージャーのパスワード、GitHubトークン、クラウドアクセス、さらにはClaude Codeの設定まで盗みました。もうひとつ厄介なのは、こうしたマルウェアは通常のパッケージ削除後も残り、次のセッションで再び動くことがよくある点です。

私は自分用に簡単な習慣を作りました。GitHubからスキルをインストールする前に、自分で確認することです。あなたにも勧めます。作者がハッキングされたり、アカウントが乗っ取られたり、リポジトリにマルウェアが入り込んだりする可能性があるため、確認が身を守ります。

インストール前の最低限の確認事項は、作者とスター数を見ること、スキルの説明を読むこと、誰かの投稿で勧められていたからという理由だけでツールをインストールしないこと、そして使い慣れないツールは本番キーのあるマシンではなく、別のテスト環境で先に試すことです。

侵害後に助けになるもの：バックアップとロールバック#

セキュリティは「外部の人を締め出す」だけではなく、「問題が起きたときに元の状態へ戻す」ことでもあります。問題は必ず起きます。説明されている実例では、AIエージェントが本番プロジェクトで日常的なタスクを処理中に、稼働中のデータベースを削除しました。バックアップはありましたが、3日前のものでした。3日分のデータがそのまま消えました。

そこから2つのルールが導かれます。

頻繁にバックアップする。 失いたくないデータをアプリに保存しているなら、3日ごとのコピーは保護されているという錯覚にすぎません。少なくとも30分ごとに自動バックアップするよう設定してください。Supabaseを含む多くのデータベースでは、数回クリックするだけで有効にできます。

gitはエージェントに対する保険。 gitにはコードの履歴が保存され、動作していた状態をいつでも復元できます。エージェントが動いていたものを書き換えたときは、手作業で直すのではなく、最後に動作していたバージョンに戻します。AIがプロジェクトを削除または破損し、元に戻す方法がわからない場合は、別の報告書AIがデータベースを削除したときの対処法をご覧ください。プロジェクトの破損を事前に防ぐ方法は、Claude Codeを破損から守る方法のガイドをご覧ください。

公開前のセキュリティチェックリスト#

公開の直前に、このリストを順番に確認してください。

1. シークレットは .env に置き、.env は .gitignore に記載する。 コードにキーを置かない。公開リポジトリに .env ファイルを置かない。

2. キーの権限は必要最小限にする。 各キーでできることは、必要なものだけです。本番キーはエージェントの環境と分けます。

3. ユーザーデータのあるすべてのテーブルで RLSが有効になっており、アクセスポリシーが設定されている。

4. データ操作のすべてに対する サーバー側の権限チェックを行う。インターフェース上でボタンを隠すだけでは不十分です。アドレスの id を変更して、手動でテストします。

5. Webhookの署名を検証する。 外部通知を処理するハンドラー（決済、フォームなど）はすべて署名を検証します。

6. 受信リクエストとコストのかかる操作に レート制限を設定し、パスワードの総当たりを防ぎ、請求額が膨らまないようにする。

7. 本番キーのあるマシンで、エージェントを「すべて許可」モードで実行しない。.env の読み取りを拒否する。

8. バックアップを頻繁に取得し、テストする。コピーが「どこかにある」と信じるだけでなく、実際に復元を試す。

9. /security-review またはsecurity-guidanceプラグインで コードをチェックする。検出された問題は修正する。

10. 他人のスキルや拡張機能を確認する。未確認のままインストールしない。

今日から始めること#

このガイドのすべてを一晩で実行しようとしないでください。結局何もしないことになります。今日取り組む最も重要な3つの手順を選びましょう。

1. シークレットを確認する。 .gitignore を開き、.env が記載されていることを確認し、公開リポジトリにキーがないことを確認します。漏えいしているものがあれば、失効させて再発行します。
2. RLSについて尋ねる。 エージェントに「RLSが無効になっているテーブルを表示してください」と伝え、人々のデータが保存されている場所すべてで有効にします。
3. 頻繁なバックアップを設定する。 問題が起きても、失うのが数分で済み、数日分にならないようにします。

その後、プロジェクトが成長し、お金や他人のデータを扱うようになったら、上記のチェックリストに従ってください。

最後にひとつ。Vibe Codingのセキュリティは、所有者の責任です。セキュリティの専門家になる必要はありません。AIが一晩でプロダクトを作ってくれたのは素晴らしいことですが、そのプロダクトに責任を負うのはあなたです。このガイドの基本水準は、その責任を実践で果たす方法です。

モデルをさらに活用するには、Ailootをご利用ください。