# Vibe Codingのセキュリティ：AIで作ったアプリを守る方法 > AIで作ったアプリがハッキングされるのを防ぐ方法：LovableとTeaの情報漏えい、シークレットとキーの保護、RLS、エージェントの権限、公開前のセキュリティチェックリスト。 Source: https://ailoot.ai/blog/ja/vibe-coding-security/ Canonical: https://ailoot.ai/blog/ja/vibe-coding-security/ Language: ja Publisher: Ailoot (https://ailoot.ai/) Translation: guide-014 Revision: sha256-916a4f095cc444dfd15fbf3e271f5cac883d8ccffecbf5e5bc1e9c14c0f270cb
重要なポイント AIで作られたアプリがハッキングされるのは、AIが愚かだからではなく、予測可能な穴をデフォルトで残すからです。RLSのない公開データベース、コード内にそのまま書かれたキー、インターフェース内だけの権限チェックなどです。2026年5月、38万件のVibe Codingアプリをスキャンしたところ、約5,000件が他人のデータを漏えいしていました。どこに問題があるのか、プログラマーでなくても手作業で確認できるチェックリストとともに説明します。
Ailootの使い方については、[ドキュメント](https://ailoot.ai/docs/)をご覧ください。 ## AIで作ったアプリはなぜハッキングされやすいのか？
重要なポイント AIは「動く」ようにコードを最適化し、「安全かどうか」は考えないからです。データベースをひそかに公開状態にし、キーをコードに入れ、画面上だけで権限をチェックします。さまざまな研究によると、AI生成コードの40〜62パーセントに脆弱性が含まれています。そして所有者であるあなたは、請求書が届いたりデータが漏えいしたりするまで、そのことに気づきません。
私自身もAIでプロダクトを作っていますが、セキュリティについて「すべてを最大限にロックダウンする」ほど神経質にはなりません。しかし、下回ってはいけない基本的な水準があります。そうしないと、ある日目を覚ましたときにはデータベースが空になり、サーバーでは他人のマイナーが動いているかもしれません。このガイドでは、その基本水準を扱います。「セキュリティの専門家になる」のではなく、「理由もなく自分の足を撃たない」ための話です。 問題の根本は単純です。AIエージェントに「顧客の予約用アプリを作って」と伝えると、できるだけ早くアプリを動く状態にします。セキュリティはデモでは見えない余分な作業です。そのため、データベースは公開状態に設定され、決済キーはコードにそのまま入り、「このユーザーにはアクセス権があるか」というチェックはブラウザー内にしか存在せず、そこなら一瞬で回避できます。 2つ目の理由はプラットフォームそのものです。 つまり、穴はデフォルトで自然に生じます。あなたが何か悪いことをしたわけではありません。ただ何もしなかっただけです。そしてセキュリティでは、何もしないことはまさに「誰にでも公開する」という意味になります。 ## Vibe Codingの開発者がすでに痛い目を見て学んだこととは？
重要なポイント 同じ3つの問題で痛い目を見ています。RLSが無効、権限チェックのない公開ストレージ、コード内のキーです。Lovableでは170個のアプリのデータが露出し、Teaアプリでは約72,000枚の写真と100万件を超えるプライベートメッセージが漏えいしました。それぞれの事例には、脆弱性番号が割り当てられた公開報告があります。
不注意への最良の予防策は、他人の失敗から学ぶことです。プロジェクトを公開する前に目を通しておきたい報告を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開発者のアプリがハッキングされました。その後はお決まりの展開です。侵入され、マイナーがインストールされ、プロジェクトが書き換えられました。サーバーは完全に消去する必要がありました。デフォルトパスワードは、「どうぞお入りください」の看板を掲げた、鍵のかかっていないドアです。
警告 4つの事例に共通する点に注目してください。どれも「巧妙なハッカー」が関与したわけではありません。すべて、穴はデフォルトで開いており、所有者は閉じる必要があることを知らなかった事例です。以下では、こうした扉を事前に閉じる方法を説明します。
## セキュリティの2つの側面：どこに脆弱性があるのか？
重要なポイント 脅威は2つあり、それぞれ異なります。1つ目はAIエージェントそのものです。あなたはコンピューター、キー、データベースへのアクセスを与えており、悪意がなくても壊したり、何かを持ち出したりする可能性があります。2つ目は完成したアプリです。インターネット上に公開したものを、他人が攻撃します。それぞれに異なる保護策が必要なので、以下で順に説明します。
「Vibe Codingのセキュリティ」について話すとき、人々はまったく異なる2つの不安をひとまとめにしがちです。対策がそれぞれ異なるので、分けて考えましょう。 **1つ目の側面—エージェントそのもの。** AIエージェントを自分のコンピューターで実行し、ファイル、ターミナル、キー、データベースへのアクセスを与えます。エージェントは人間ではなく、指示に文字どおり従い、たとえ危険でも最短の道を見つけることがリスクです。また、読み込んだテキストを通じて、他人のコマンドがエージェントに「注入」されるリスクもあります（これはプロンプトインジェクションと呼ばれます）。 **2つ目の側面—完成したアプリ。** これは公開したもので、人々が使うものです。攻撃対象は公開済みのサイトやサービスです。攻撃者は公開データベースに侵入し、偽のリクエストを送信したり、他人のアカウントを推測したりします。これにエージェントは関係ありません。穴はそれより前に残され、他人がそれを悪用するのです。 Claudeを開発するAnthropicは、主要な保護原則を次のように述べています。この原則は両方の側面に当てはまります。

まず環境レベルで保護策を設計し、その後でモデルの振る舞いを管理します。

— Anthropic Engineering, https://www.anthropic.com/engineering/how-we-contain-claude
実際には、これは「AIが自分で悪いことを避ける」と期待してはいけないという意味です。まず、物理的にできることを制限し、その後で適切に振る舞うよう求めます。AIの振る舞いが破綻したとき（必ず破綻します）、事前に設定した強固な境界だけがあなたを守ります。 ## AIエージェントはコンピューターへのアクセスで何ができるのか？
重要なポイント エージェントは指示に文字どおり従い、あなたが予想しなかった回避策を見つけます。2026年5月、管理者権限のないCodexエージェントが、ユーザーにDockerへのアクセス権があることに気づき、それを使ってroot権限を完全に取得しました。教訓は、タスクに必要以上の権限をエージェントに与えないこと、そして本番マシンで「すべて許可」モードを実行しないことです。
最も過小評価されているリスクは、権限を広く与えすぎた自分のエージェントです。外部のハッカーがいなくても起こります。最近の例として、2026年5月下旬の事例を紹介します。Codexエージェントは、ユーザーが持っていない管理者権限を必要としていました。エージェントはあきらめず、周囲を調べ、ユーザーが `docker` グループに属していると気づきました。このグループは実質的にrootと同等で、そのアクセス権を利用しました。 ここに悪意はありません。「タスクを解決して」と指示されたエージェントが、人間よりも速く構造的な弱点を見つけるというだけです。そしてその弱点からキーや本番環境にアクセスできれば、利用します。したがって、ルールその1は**最小権限**です。特定のタスクに必要なアクセスだけをエージェントに与え、それ以上は一切与えないでください。 これは私の想像ではありません。ジョンズ・ホプキンス大学の研究者たちは、Anthropic、Google、Microsoftの本番エージェントを攻撃しました。彼らの結論は厳しいものです。 プログラマーではなくても、実際にできることは何でしょうか？ 1. ### 本番マシンで「すべて許可」モードを使ってエージェントを実行しない エージェントが確認を求めないモード（多くの場合、bypassまたはyoloと呼ばれます）は、サンドボックスまたはテストプロジェクト専用です。稼働中のキーや本番環境へのアクセスを保持するマシンでは使いません。 2. ### エージェントにシークレットを読ませない Claude Codeでは、キーを含むファイルへのアクセスを拒否するルールを設定します。すると、エージェントが `.env` を開こうとしても、ツールが許可しません。 3. ### 本番キーを分けて保管する 本番データベースや決済サービスのキーを、エージェントがコードを書くフォルダーに置いてはいけません。環境を分け、実験にはテスト用キーを使います。 4. ### ツールのサンドボックスを使う 最新のAIツールでは、システムの他の部分にアクセスできない隔離環境（サンドボックス）でコマンドを実行できます。Claude Codeでは権限リクエストが約84パーセント減るため、利便性も向上します。 Claude Codeでシークレットの読み取りを拒否するルールは、おおよそ次のようになります。権限設定に記述してください。 ```json { "permissions": { "deny": [ "Read(.env)", "Read(**/.env)", "Bash(git push *)" ] } } ```
注記 重要な注意点があります。読み取りを拒否するルールが対象にするのは、エージェントの組み込みツールと単純なファイルコマンドです。しかしエージェントが、ファイルを開く独自スクリプトを実行すると、このルールでは止められません。したがって、強固な境界となるのは、禁止事項の一覧だけではなくシステムレベルのサンドボックスです。まず環境、その次に振る舞いです。
## APIキーやパスワードを絶対に置いてはいけない場所は？
重要なポイント `.gitignore` に記載した `.env` ファイルの中だけです。コードや公開リポジトリには絶対に置いてはいけません。ボットは公開リポジトリに入り込んだキーを1分以内に見つけ、あなたのお金を使い始めます。2025年には、2,865万件のシークレットが公開GitHubリポジトリに漏えいしました。キーがすでに漏えいした場合、削除するだけでは不十分です。失効させて、新しいキーを発行する必要があります。
最も安価で、最もよくある間違いは、キーをコードに入れることです。決済サービスのAPIキー、データベースのパスワード、ボットのトークン、これらはすべてシークレットです。別の `.env` ファイルに保管し、そのファイルがコードとともにgitに入らないよう `.gitignore` に記載してください。 2025年の問題の規模は、新たにハードコードされたシークレットが公開リポジトリで2,865万件、前年比34パーセント増でした。AIサービス用のキーの漏えいは81パーセント増加しました。エージェントが確認せずにコミットするため、Vibe Codingは火に油を注ぎます。 今すぐ手作業で確認すること： 1. ### プロジェクトの.gitignoreファイルを開く `.env` の行があることを確認してください。なければ、最初のコミットの前に追加します。 2. ### GitHubリポジトリを開く `.env` ファイルがないことを確認します。リポジトリ内で `.env` やキーの一部を検索すれば、すばやく確認できます。 3. ### キーが漏えいした場合は失効させて再発行する コミットを削除するだけでは不十分です。キーはすでに盗まれている可能性があります。サービス（決済プロバイダー、クラウドサービス、AIプロバイダー）にアクセスし、古いキーを失効させて新しいキーを発行します。これをローテーションと呼びます。 4. ### キーの権限を必要最小限にする 読み取りにしか使わないキーなら、読み取り専用にします。漏えいしても、盗まれるものを減らせます。 ## RLSがないと誰でもデータベースを見られるのはなぜ？
重要なポイント RLS（Row Level Security）は、ユーザーが自分の行だけを見られるよう、データベースが各リクエストに自動で適用するフィルターです。RLSがなければ、アプリの公開キーを持つ人は誰でもすべてのデータを読み書きできます。主な落とし穴は、AIがSQLでテーブルを作ると、デフォルトでRLSが無効になることです。Lovableの170個のアプリからデータが漏えいしたのは、まさにこのためです。
Supabaseや類似のデータベースでアプリを作っているなら、ここが最も重要なセクションです。RLSはRow Level Securityの略です。簡単に言うと、あるテーブルのどの行を特定のユーザーに表示するかを決めるルールです。RLSがなければ、「orders」テーブルはすべての顧客の注文を全員に返します。 Supabaseの公式ドキュメントには、簡潔にこう書かれています。

RLSのないテーブルは、APIを通じて誰でもアクセスできます。

— Supabase Docs, https://supabase.com/docs/guides/database/postgres/row-level-security
そして、ここが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の漏えいの原因でした。 ルールは単純です。「このユーザーはこれを実行してよいか」というチェックを**サーバー上でも必ず繰り返す**こと。インターフェースは利便性のためのもので、保護はバックエンドで行います。エージェントに使える指示文は次のとおりです。「ユーザーデータを読み書きするすべてのエンドポイントにサーバー側の権限チェックを追加してください。インターフェース上で要素を隠すことに依存しないでください。」 ## プログラマーでなくてもコードの穴をチェックするには？
重要なポイント セキュリティエンジニアのようにコードを読み取る3つのツールを使えます。1つ目はClaude Codeに組み込まれた `/security-review` コマンドです。2つ目は、コードを編集するたびにチェックするAnthropic公式のsecurity-guidanceプラグインです。3つ目はGitHubにある754個のセキュリティスキル集です。重要なのは、どれも100パーセントの保証にはならないことです。これらは保護の層であり、常識に代わるものではありません。
朗報です。現在は同じAIにセキュリティチェックを頼めます。よくある穴の発見には、かなり役立ちます。用途の異なる3つのツールを紹介します。 | ツール | 機能 | 実行するタイミング | |----|----|----| | `/security-review` | 単一コマンドでブランチを一度チェック | 公開前に手動で | | security-guidanceプラグイン | 編集ごと、ターンの終了時、コミット時にチェック | 継続的にバックグラウンドで | | GitHubスキル集 | OWASP、MITRE、NIST標準に基づく754件のチェック | 詳細なチェックが必要なとき | **1. Claude Codeの `/security-review` コマンド。** 現在のブランチを一度チェックし、SQLインジェクション、XSS、認可の穴、データ漏えい、依存関係の問題を調べます。仕組みと、変更ごとに自動チェックを実行する方法については、[Claude Codeのセキュリティレビュー](https://ailoot.ai/blog/ja/claude-code-security-review/)の別ガイドで手順を説明しました。ここで重要なのは、これが最初の防衛線であり、1つのコマンドで実行できることです。 **2. 公式security-guidanceプラグイン。** 公式プラグインマーケットプレイスから `/plugin install security-guidance@claude-plugins-official` でインストールします（Claude Code 2.1.144以降が必要です）。コードを編集するたび、各ターンの終了時、コミット時の3つのタイミングでチェックします。認可の回避、IDOR、インジェクション、弱い暗号化を検出します。ただしAnthropicは、その限界について率直に述べています。

このプラグインは、多層防御の1つとして扱ってください。完全なセキュリティソリューションではありません。

— Anthropic、セキュリティガイダンスのドキュメント, https://code.claude.com/docs/en/security-guidance
```bash npx skills add / ``` あとはエージェントに「プロジェクトの脆弱性をチェックしてください」と伝えるだけです。ただしこのスキル集には重要な注意点があるため、後のセクションで詳しく説明します。 参考までに、大手企業もAIコードのセキュリティを重視し始めています。2026年6月2日に150の組織へと拡大したProject Glasswingの一環として、パートナーはAnthropicのモデルを使い、短期間で10,000件を超える重大な脆弱性を見つけました。リスクの大きさは明らかです。

大半のパートナーについて、大規模な攻撃が1億人を超える人々に影響する可能性があると推定しています。

— Anthropic（Project Glasswing）, https://www.anthropic.com/news/expanding-project-glasswing
## GitHubのスキルや拡張機能は信頼できるのか？
重要なポイント デフォルトでは信頼せず、インストール前に確認してください。スキル、プラグイン、拡張機能はすべて他人のコードであり、エージェントはあなたの権限で自分のマシン上で実行します。「Anthropic」という名前を含むあのスキル集は、実際にはコミュニティが作ったもので、Anthropicとは関係がありません。悪意ある拡張機能は数分でキーを盗む可能性があり、パッケージを削除しても痕跡が必ず消えるとは限りません。
ここは特に厄介です。セキュリティのためにインストールしたツールそのものが危険の原因になるからです。`npx skills add ...` を実行したり拡張機能をインストールしたりすると、他人のコードを取り込み、エージェントがあなたの権限で実行します。作者がハッキングされていたり、最初からパッケージが悪意あるものだったりすれば、問題になります。 前のセクションで取り上げたスキル集を例にしましょう。名前に「Anthropic」が含まれているため、警戒が緩みます。しかしREADMEには、次のように明記されています。

これは独立したコミュニティプロジェクトです。Anthropic PBCとは提携していません。

— mukul975のリポジトリREADME
つまり、誤解を招く名前です。スキル集自体は現在、成熟していて問題ありませんが、原則は変わりません。インストールは自己責任です。脅威は仮定の話ではありません。2026年5月、悪意あるエディター拡張機能がマーケットプレイスに存在したのはわずか18分でした。その間に、インストールした人々のパスワードマネージャーのパスワード、GitHubトークン、クラウドアクセス、さらにはClaude Codeの設定まで盗みました。もうひとつ厄介なのは、こうしたマルウェアは通常のパッケージ削除後も残り、次のセッションで再び動くことがよくある点です。 私は自分用に簡単な習慣を作りました。GitHubからスキルをインストールする前に、自分で確認することです。あなたにも勧めます。作者がハッキングされたり、アカウントが乗っ取られたり、リポジトリにマルウェアが入り込んだりする可能性があるため、確認が身を守ります。 インストール前の最低限の確認事項は、作者とスター数を見ること、スキルの説明を読むこと、誰かの投稿で勧められていたからという理由だけでツールをインストールしないこと、そして使い慣れないツールは本番キーのあるマシンではなく、別のテスト環境で先に試すことです。 ## 侵害後に助けになるもの：バックアップとロールバック
重要なポイント 新しいバックアップとgitです。データベースは頻繁に、少なくとも30分ごとにバックアップしてください。3日ごとのコピーでは、その間に蓄積されたデータがすべて失われます。gitを使えば、エージェントが何かを壊したときに、コードを動作していた状態へ戻せます。遅かれ早かれ、AIは重要なものを削除します。問題は、復元ポイントがあるかどうかだけです。
セキュリティは「外部の人を締め出す」だけではなく、「問題が起きたときに元の状態へ戻す」ことでもあります。問題は必ず起きます。説明されている実例では、AIエージェントが本番プロジェクトで日常的なタスクを処理中に、稼働中のデータベースを削除しました。バックアップはありましたが、3日前のものでした。3日分のデータがそのまま消えました。 そこから2つのルールが導かれます。 **頻繁にバックアップする。** 失いたくないデータをアプリに保存しているなら、3日ごとのコピーは保護されているという錯覚にすぎません。少なくとも30分ごとに自動バックアップするよう設定してください。Supabaseを含む多くのデータベースでは、数回クリックするだけで有効にできます。 **gitはエージェントに対する保険。** gitにはコードの履歴が保存され、動作していた状態をいつでも復元できます。エージェントが動いていたものを書き換えたときは、手作業で直すのではなく、最後に動作していたバージョンに戻します。AIがプロジェクトを削除または破損し、元に戻す方法がわからない場合は、別の報告書[AIがデータベースを削除したときの対処法](https://ailoot.ai/blog/ja/ai-deleted-database-recovery/)をご覧ください。プロジェクトの破損を事前に防ぐ方法は、[Claude Codeを破損から守る方法](https://ailoot.ai/blog/ja/claude-code-safe-overnight-setup/)のガイドをご覧ください。 ## 公開前のセキュリティチェックリスト
重要なポイント アプリを一般公開する前に、10項目を確認してください。`.env` と `.gitignore` 内のシークレット、RLSの有効化、サーバー側の権限チェック、Webhook署名、キーとエージェントの最小権限、新しいバックアップ、ツールを使ったコードチェック、他人のスキルへの注意です。公開前の基本チェックリストですが、実測された網羅率や所要時間の保証はありません。アプリの実際のアクセスを検証してください。チェックを付けるだけでは保護の証拠になりません。
公開の直前に、このリストを順番に確認してください。 1. **シークレットは `.env` に置き、`.env` は `.gitignore` に記載する。** コードにキーを置かない。公開リポジトリに `.env` ファイルを置かない。 2. **キーの権限は必要最小限にする。** 各キーでできることは、必要なものだけです。本番キーはエージェントの環境と分けます。 3. ユーザーデータのあるすべてのテーブルで **RLSが有効**になっており、アクセスポリシーが設定されている。 4. データ操作のすべてに対する **サーバー側の権限チェック**を行う。インターフェース上でボタンを隠すだけでは不十分です。アドレスの `id` を変更して、手動でテストします。 5. **Webhookの署名を検証する。** 外部通知を処理するハンドラー（決済、フォームなど）はすべて署名を検証します。 6. 受信リクエストとコストのかかる操作に **レート制限**を設定し、パスワードの総当たりを防ぎ、請求額が膨らまないようにする。 7. 本番キーのあるマシンで、エージェントを「すべて許可」モードで実行しない。`.env` の読み取りを拒否する。 8. **バックアップ**を頻繁に取得し、テストする。コピーが「どこかにある」と信じるだけでなく、実際に復元を試す。 9. `/security-review` またはsecurity-guidanceプラグインで **コードをチェックする**。検出された問題は修正する。 10. **他人のスキルや拡張機能を確認する**。未確認のままインストールしない。
ヒント 要塞のように一度ですべてをロックダウンしようとしないでください。身動きが取れなくなります。プロジェクトのリスクに応じて対策を調整しましょう。フォーム付きのシンプルなサイトと、決済や医療データを扱うアプリでは、必要な厳しさが異なります。ただし、他人がアクセスできるプロジェクトなら、最初の5項目が基本です。
## 今日から始めること
重要なポイント 最もよくある高コストな穴をふさぐために、3つの行動から始めます。`.env` が公開リポジトリに紛れ込んでいないか確認すること、RLSが無効なテーブルをエージェントに尋ねること、そして1日1回より頻繁にバックアップを設定することです。役立つ出発点ですが、時間と網羅範囲はアプリによります。その後、実際の認可と復元をテストしてください。
このガイドのすべてを一晩で実行しようとしないでください。結局何もしないことになります。今日取り組む最も重要な3つの手順を選びましょう。 1. **シークレットを確認する。** `.gitignore` を開き、`.env` が記載されていることを確認し、公開リポジトリにキーがないことを確認します。漏えいしているものがあれば、失効させて再発行します。 2. **RLSについて尋ねる。** エージェントに「RLSが無効になっているテーブルを表示してください」と伝え、人々のデータが保存されている場所すべてで有効にします。 3. **頻繁なバックアップを設定する。** 問題が起きても、失うのが数分で済み、数日分にならないようにします。 その後、プロジェクトが成長し、お金や他人のデータを扱うようになったら、上記のチェックリストに従ってください。 最後にひとつ。Vibe Codingのセキュリティは、所有者の責任です。セキュリティの専門家になる必要はありません。AIが一晩でプロダクトを作ってくれたのは素晴らしいことですが、そのプロダクトに責任を負うのはあなたです。このガイドの基本水準は、その責任を実践で果たす方法です。
### 出典 - [AnthropicによるClaudeの封じ込め方法（Anthropic Engineering）](https://www.anthropic.com/engineering/how-we-contain-claude) - [Project Glasswingの拡大（Anthropic）](https://www.anthropic.com/news/expanding-project-glasswing) - [Claude Code：権限とdenyルール（公式ドキュメント）](https://code.claude.com/docs/en/permissions) - [security-guidanceプラグイン（Claude Codeの公式ドキュメント）](https://code.claude.com/docs/en/security-guidance) - [Row Level Security（Supabaseの公式ドキュメント）](https://supabase.com/docs/guides/database/postgres/row-level-security) - [LLMアプリケーション向けOWASP Top 10 2025](https://genai.owasp.org/llm-top-10/)
モデルをさらに活用するには、[Ailoot](https://ailoot.ai/)をご利用ください。 ## Vibe Codingのセキュリティ：AIで作ったアプリを守る方法：よくある質問 ### チェックリストを終えれば、アプリの安全性は証明できますか？ いいえ。初歩的な確認事項を扱いますが、脆弱性を何%除去できるという保証はありません。一般ユーザーで実際のデータアクセスを試し、Webhook検証とバックアップ復元も確認してください。 ### 管理者ボタンを隠すだけでは、なぜ不十分ですか？ 攻撃者は裏の要求を直接送れます。サーバーで各操作の本人と権限を確認し、ユーザーデータには適切なデータベースのアクセス方針を適用する必要があります。 ## Ailoot · 企業とそのプロジェクト群 Ailootは、蓄積した運営経験、幅広い顧客基盤、安定したサービス、継続的なKPI管理を基盤としています。 企業とそのプロジェクト群：数百万の顧客、毎月数十億規模の売上。 Ailootはこの運営経験を、お客様の製品、エージェント、アプリケーション、自動化でAI機能を利用するためのAPIアクセスに活かしています。