Claude CodeやCursorを使えば、プログラミングの経験が少なくても、動くアプリや社内ツールを短い期間で作れるようになりました。

一方で「動いているけれど、このまま公開して大丈夫なのか」が分からず、手が止まっている方も多いはずです。

この記事は、AIでアプリや社内ツールを作り、これから公開しようとしている方に向けて書いています。

公開前に最低限確認したい項目を「鍵」「データベースと権限」「ログイン」「入力と外部連携」「運用」の5つに分け、IPA（情報処理推進機構）と各サービスの公式ドキュメントをもとにチェックリストにしました。

AIは「動くもの」は作ってくれます。でも「誰に見せないか」は、こちらから頼まないと作られないことがあります！

まず、公開前に確認する場所と、最初に見るべきことを一覧にします。

この表は、各一次ソースの記載をもとに、本記事が5つの確認場所に整理したものです。

この記事ではデータベースの例としてSupabaseを使います。Firebaseなどほかのサービスでも、考え方は同じです。

AIで作ったアプリが「公開前に危ない」と言われる理由

AIでアプリを作ること自体は、悪いことではありません。

ただ、公開する前の確認を飛ばしてしまうと、思わぬところから情報が漏れることがあります。まずは、なぜ確認が必要なのかを整理します。

AIの利用をめぐるリスクが「10大脅威2026」で初めて選ばれた

IPAが毎年発表している「情報セキュリティ10大脅威」の2026年版では、組織向けの3位に「AIの利用をめぐるサイバーリスク」が入りました。

この脅威が選ばれたのは2026年版が初めてです。1位は「ランサム攻撃による被害」、2位は「サプライチェーンや委託先を狙った攻撃」でした。

引用元：IPA「情報セキュリティ10大脅威 2026」 https://www.ipa.go.jp/security/10threats/10threats2026.html

10大脅威は、IPAが選んだ候補をもとに、研究者や企業の実務担当者など約250名の「10大脅威選考会」が審議と投票で決めたものです。

AIを使うこと自体が、組織にとって無視できないリスクとして認識され始めていると言えます。

「動く」と「安全」は別のこと

AIに「予約管理アプリを作って」と頼むと、画面が動き、データが保存されるところまでは作ってくれます。

しかし「このデータは本人だけが見られるようにする」「この操作は管理者だけができるようにする」といった条件は、こちらが伝えなければ入らないことがあります。

画面上はちゃんと動いているので、穴があっても気づきにくいのが特徴です。

当社のセキュリティ顧問サービスのページでは、非エンジニアの社員がAIで作った社内ツール4本を診断した事例を紹介しています。

4本とも「ちゃんと動いている」ツールでしたが、ログインなしで外から呼び出せる処理が6本、ログインなしで開いていた通知の口が5本見つかりました。

引用元：株式会社Last Scene「セキュリティ顧問｜AIで作ったアプリの公開前診断」 https://lastscene.co.jp/security-advisor

さらに「直した」はずの修正が、本番環境に3日間反映されていなかったケースもありました。修正したつもりでも、本番で確かめるまでは安心できません。

公開したアプリの責任は、公開した側にある

AIが書いたコードでも、アプリを公開して運用するのは作った会社や個人です。

お客様の個人情報を扱うアプリであれば、漏えいが起きたときの対応も自社で行うことになります。

個人情報保護委員会は、たとえばシステムの設定ミスでインターネット上から個人データが見られる状態になり、本人の数が1,000人を超える場合を、報告が必要な例として挙げています。

引用元：個人情報保護委員会「漏えい等の対応とお役立ち資料」 https://www.ppc.go.jp/personalinfo/legal/leakAction/

設定ミスひとつで、こうした報告の対象になりうるということです。だからこそ、公開前の確認が大切になります。

AIで作ったアプリ・社内ツールのセキュリティ診断

公開して大丈夫か、第三者の目で確認します

• AIで作ったアプリを公開してよいか判断できない
• 社内にセキュリティを見られる担当者がいない
• 鍵やデータベースの権限設定が正しいか確認してほしい

八木（Last Scene）

AIで作ったアプリや社内ツールの診断に加えて、取引先からのセキュリティ要求への対応や、インシデント発生時の初動整理もご相談いただけます。
「このまま公開して大丈夫？」の一問からどうぞ。

セキュリティ顧問の詳細を見る

公開前チェックリスト1：鍵（APIキー・シークレット）

最初に確認したいのが「鍵」です。ここでいう鍵とは、データベースや外部のAIサービスにアクセスするためのAPIキーやパスワードのことです。

鍵の扱いを間違えると、ほかの対策をすべてしていても、データを丸ごと持ち出されるおそれがあります。

ブラウザに置いていい鍵と、置いてはいけない鍵がある

Supabaseの公式ドキュメントは、鍵を2種類に分けて説明しています。

ブラウザやスマホアプリなど利用者の手元で動く部分には「publishable key」を使います。サーバーなど自分が管理する場所でだけ使うのが「secret key」です。

引用元：Supabase「Understanding API keys」 https://supabase.com/docs/guides/api/api-keys

公式ドキュメントは、publishable keyを「玄関に貼ってある鍵で、ロビーしか開けられない」、secret keyを「ポケットにしまっておくマスターキー」とたとえています。

secret keyが漏れると、プロジェクトのデータすべてが見られる状態になります。公式ドキュメントも、ブラウザや配布するアプリ、ソースコード管理に置かないよう明記しています。

古い「anon」「service_role」キーを使っていないか

AIが書いたコードや古いチュートリアルには、anonキーやservice_roleキーという名前の鍵が出てくることがあります。

Supabaseの公式ドキュメントによると、これらは古い方式の鍵で、2026年末までに廃止される予定です。anonがpublishable key、service_roleがsecret keyの旧版にあたります。

引用元：Supabase「Understanding API keys」 https://supabase.com/docs/guides/api/api-keys

公式ドキュメントは「AIアシスタントなどが、eyJで始まる長い鍵をコピーするよう指示してきたら、それは古い鍵向けに書かれたもの」とも注意しています。

新しい鍵を作っても、古い鍵は自動では無効になりません。ダッシュボードで無効にするまで両方が使える点にも注意しましょう。

.envファイルをGitにコミットしていないか

鍵は、.envというファイルにまとめて書くのが一般的です。このファイルをGitHubなどに上げてしまうと、鍵が外に漏れます。

.gitignoreというファイルに.envを書いておくと、Gitの管理対象から外せます。GitHubの公式ドキュメントでも、コミットしたくないファイルを.gitignoreで指定する方法が説明されています。

引用元：GitHub Docs「ファイルを無視する」 https://docs.github.com/ja/get-started/git-basics/ignoring-files

ただし、すでに一度コミットした鍵は、あとから.gitignoreに書いても履歴に残ります。

GitHubの「シークレットスキャン」は、リポジトリの全ブランチのGit履歴をさかのぼって、APIキーやパスワードなどが含まれていないかを探す機能です。

引用元：GitHub Docs「シークレット スキャン」 https://docs.github.com/ja/code-security/secret-scanning/introduction/about-secret-scanning

鍵が漏れたら、まず鍵を作り直す

鍵が漏れたと分かったら、最初にやるべきことは鍵の作り直し（ローテーション）です。

GitHubの公式ドキュメントは、シークレットスキャンでアラートを受け取ったら、影響を受ける資格情報をすぐにローテーションするよう求めています。Git履歴から消す作業は時間がかかり、鍵を無効にしていれば多くの場合は不要としています。

引用元：GitHub Docs「シークレット スキャン」 https://docs.github.com/ja/code-security/secret-scanning/introduction/about-secret-scanning

Supabaseの公式ドキュメントも、漏れた原因を直したらすぐに鍵をローテーションするよう書いています。部品ごとに別のsecret keyを使えば、漏れたときに作り直す範囲を小さくできます。

引用元：Supabase「Understanding API keys」 https://supabase.com/docs/guides/api/api-keys

鍵のチェック項目

1. ブラウザ側のコードに、secret keyやservice_roleキーが入っていない
2. .envが.gitignoreに書かれていて、リポジトリに上がっていない
3. 過去のコミット履歴にも鍵が残っていない（残っていたら作り直した）
4. 古いanon・service_roleキーを使っていない、または移行の予定がある
5. 鍵が漏れたときの作り直し手順を把握している

AIで作ったアプリ・社内ツールのセキュリティ診断

公開して大丈夫か、第三者の目で確認します

• AIで作ったアプリを公開してよいか判断できない
• 社内にセキュリティを見られる担当者がいない
• 鍵やデータベースの権限設定が正しいか確認してほしい

八木（Last Scene）

AIで作ったアプリや社内ツールの診断に加えて、取引先からのセキュリティ要求への対応や、インシデント発生時の初動整理もご相談いただけます。
「このまま公開して大丈夫？」の一問からどうぞ。

セキュリティ顧問の詳細を見る

公開前チェックリスト2：データベースと権限（Supabaseの例）

次に確認するのはデータベースです。AIで作ったアプリでは、ここに穴が残っていることが少なくありません。

ポイントは「RLS（Row Level Security）」と「grant（テーブルへの権限）」の2つです。

RLSが無いテーブルは、誰でも読み書きできる

RLSは、データベースの行ごとに「誰が読めるか、誰が書き込めるか」を決める仕組みです。

Supabaseの公式ドキュメントは、公開されているスキーマにあるテーブルでRLSが無効になっていると、権限を持つどのロールからでも読み書きできると警告しています。

引用元：Supabase「Row Level Security」 https://supabase.com/docs/guides/database/postgres/row-level-security

そのため、公開されているスキーマのすべてのテーブルでRLSを有効にするよう求めています。

「テーブルを1つ足したときにRLSを付け忘れる」のが、よくある見落としです。AIに機能を追加してもらったあとは、新しいテーブルができていないかを確認しましょう。

ポリシーで「本人のデータだけ」に絞る

RLSを有効にしたら、ポリシー（読み書きの条件）を書きます。

Supabaseの公式ドキュメントでは、ログイン中の利用者のIDを返す auth.uid() を使い、「行の user_id がログイン中の利用者と一致するときだけ読める」といったポリシーの例が示されています。

書き込みについては、既存の行を確かめる条件（using）と、書き込んだ結果の行を確かめる条件（with check）の両方を指定する例が紹介されています。

引用元：Supabase「Row Level Security」 https://supabase.com/docs/guides/database/postgres/row-level-security

AIに作ってもらったポリシーは、「誰が」「どの行を」「読めるのか、書けるのか」を日本語で説明させてみると、意図とずれていないかを確かめやすくなります。

anonとauthenticatedのgrantを見直す

RLSとは別に、テーブルそのものへの権限（grant）があります。

Supabaseの公式ドキュメントは、ポリシーを追加してもgrantは取り消されないと説明しています。ポリシーだけで守っているつもりでも、grantを残したままだと、未ログインの利用者（anon）に書き込みの経路が残る場合があります。

引用元：Supabase「Row Level Security」 https://supabase.com/docs/guides/database/postgres/row-level-security

公式ドキュメントでは、テーブルを守る手順として、まずanonとauthenticatedのgrantを取り消し、必要なものだけを付け直す流れが示されています。

secret keyはRLSを素通りする

先ほどの鍵の話とつながりますが、secret key（旧service_roleキー）を使うと、RLSのポリシーは一切効きません。

Supabaseの公式ドキュメントによると、secret keyはBYPASSRLSという属性を持つservice_roleとして動くためです。

引用元：Supabase「Understanding API keys」 https://supabase.com/docs/guides/api/api-keys

つまり、RLSをどれだけ丁寧に書いても、ブラウザにsecret keyが置かれていれば意味がありません。鍵の確認とデータベースの確認は、必ずセットで行いましょう。

ビュー（view）はRLSを素通りすることがある

見落としやすいのが「ビュー」です。ビューは、テーブルのデータを組み合わせて見せる仕組みです。

Supabaseの公式ドキュメントは、ビューは通常postgresユーザーで作られるため、初期設定ではRLSを素通りすると説明しています。守っているテーブルの上にビューを作ると、ポリシーで隠したはずの行まで見えてしまうおそれがあります。

引用元：Supabase「Row Level Security」 https://supabase.com/docs/guides/database/postgres/row-level-security

Postgres 15以上では、ビューに security_invoker = true を設定すると、元のテーブルのRLSに従わせることができます。

Security Advisorで自動チェックをかける

Supabaseには、データベースの設定を自動で点検する「Security Advisor」があります。公式ドキュメントによると、管理画面（Studio）から実行できるほか、CLIの supabase db advisors コマンドや、MCPサーバーのget_advisorsからも呼び出せます。AIに作業を任せている場合は、MCPから結果を読ませて修正案を出させる、という使い方もできます。

引用元：Supabase「Performance and Security Advisors」 https://supabase.com/docs/guides/database/database-linter

Security Advisorが出す指摘のうち、公開前に必ず見ておきたいものを整理しました。

引用元：Supabase「Performance and Security Advisors」 https://supabase.com/docs/guides/database/database-linter

「ERROR」と表示された指摘は、公開前に必ずゼロにすることをおすすめします。WARNの指摘も、1つずつ「意図した設定か」を確かめてから公開しましょう。

user_metadataで権限を判定してはいけない理由

Supabaseのドキュメントでは、user_metadataはログインしたユーザー本人が書き換えられる、と説明されています。たとえば、ブラウザから updateUser({ data: { is_admin: true } }) のような呼び出しをすれば、自分を管理者にできてしまいます。

そのため、ポリシーの中で「user_metadataのis_adminがtrueなら全件読める」といった条件を書くと、だれでも管理者になれる状態になります。管理者かどうかは、本人が書き換えられない場所（app_metadataや、管理者だけが更新できるテーブル）で判定してください。

引用元：Supabase「Performance and Security Advisors」 https://supabase.com/docs/guides/database/database-linter

SECURITY DEFINERの関数を外から呼ばせない

AIにデータベースの処理を作らせると、「SECURITY DEFINER」という指定の付いた関数ができることがあります。この関数は、呼び出した人ではなく、関数を作った人の権限で動きます。RLSを無視して動くことがあるため、外から呼べると危険です。

公式ドキュメントでは、次のどちらかで直す方法が示されています。

引用元：Supabase「Performance and Security Advisors」 https://supabase.com/docs/guides/database/database-linter

テーブルを公開しない場合のgrantの外し方

ブラウザから直接読ませる必要のないテーブルは、anonの権限そのものを外しておくと安心です。Supabaseのドキュメントでは、既存のテーブルと、これから作るテーブルの両方から権限を外す書き方が紹介されています。

引用元：Supabase「Performance and Security Advisors」 https://supabase.com/docs/guides/database/database-linter

なお、ドキュメントによると、匿名ログイン（anonymous sign-in）を有効にしている場合、匿名のユーザーもauthenticatedのロールになります。「authenticatedなら正式な会員」と考えてポリシーを書くと、匿名ユーザーにも同じ権限が渡る点に注意してください。

データベースのチェック項目

1. 公開されているスキーマのすべてのテーブルでRLSが有効になっている
2. ポリシーが「本人のデータだけ」など意図どおりに絞られている
3. anonとauthenticatedに、必要以上のgrantが残っていない
4. secret keyはサーバー側だけで使っている
5. ビューを作っている場合、security_invokerを設定している

公開前チェックリスト3：ログインと「他人のデータが見えないか」

データベースの設定とあわせて確認したいのが、アプリ側のログインと権限の扱いです。

いちばん大切なのは「ログインした人に、他人のデータや他社のデータが見えないか」です。

「アクセス制御や認可制御の欠落」はIPAも取り上げる脆弱性

IPAの「安全なウェブサイトの作り方」は、ウェブサイトを作る人向けに、届出の多い脆弱性や影響の大きい脆弱性と、その対策をまとめた資料です。

この資料の第1章では11種類の脆弱性が取り上げられており、その1つが「アクセス制御や認可制御の欠落」です。

引用元：IPA「安全なウェブサイトの作り方」 https://www.ipa.go.jp/security/vuln/websecurity/about.html

アクセス制御は「ログインしているか」、認可制御は「その人にその操作をしてよい権限があるか」を確かめる仕組みです。

ログイン画面があっても、ログイン後に「その人が見てよいデータか」を確かめていなければ、ほかの利用者のデータにたどり着けてしまいます。

OWASP Top 10の2025年版でも、1位は「Broken Access Control（アクセス制御の不備）」です。

引用元：OWASP「OWASP Top 10:2025」 https://owasp.org/Top10/2025/

URLのIDを書き換えて確かめる

専門の道具がなくても、自分で確かめられる方法があります。テスト用のアカウントを2つ用意して、次の手順で試してみましょう。

1. アカウントAでログインし、自分のデータの詳細画面を開く
2. URLやアドレスバーに表示されているIDをメモする
3. アカウントBでログインし直す
4. アカウントAのデータのIDをURLに入れて開いてみる
5. 開けてしまったら、権限の確認が抜けている

画面だけでなく、裏側のAPIも確認が必要です。画面でボタンを隠していても、APIを直接呼び出せば操作できてしまう場合があります。

ログインせずに呼び出せる処理が残っていないか

先ほど紹介した診断事例では、ログインなしで外から呼び出せる処理が6本見つかりました。

開発中に「テストしやすいように」とログインの確認を外したまま、本番に残ってしまうことがあります。

引用元：株式会社Last Scene「セキュリティ顧問｜AIで作ったアプリの公開前診断」 https://lastscene.co.jp/security-advisor

AIに「このアプリの中で、ログインしていなくても呼び出せるAPIや処理を一覧にして」と頼むと、確認の出発点になります。ただし一覧が正しいかは、実際に呼び出して確かめましょう。

管理画面とテスト用ページの公開範囲

管理画面や、開発中に作ったテスト用のページも見直しましょう。

「URLを知っている人しか来ないから大丈夫」という考え方は危険です。URLは、ブラウザの履歴や共有したメッセージなどから漏れることがあります。

管理画面には必ずログインを付け、使わなくなったテスト用のページや処理は削除しておきましょう。

APIの視点で見直す（OWASP API Security Top 10）

AIで作ったアプリの多くは、画面の裏でAPI（データをやり取りする窓口）を使っています。OWASPは、APIに特有の危険を「API Security Top 10 2023」として公開しています。小さな会社のアプリで特に関係が深い項目を、確かめ方とあわせて整理しました。

引用元：OWASP「API Security Top 10 2023」 https://owasp.org/API-Security/editions/2023/en/0x11-t10/

特にAPI4は、AIのAPIを使うアプリで影響が大きくなります。外部のAIサービスは使った分だけ料金がかかることが多いため、上限がないと、第三者に連続で呼ばれたときに請求が膨らむおそれがあります。後半の「運用」のチェックとあわせて、1人あたりの回数制限を入れておきましょう。

ログインと権限のチェック項目

1. 2つのテスト用アカウントで、相手のデータが開けないことを確かめた
2. 画面だけでなく、APIを直接呼んでも他人のデータが取れない
3. ログインなしで呼び出せる処理を一覧にし、意図したものだけになっている
4. 管理画面にはログインと権限の確認がある
5. 開発用・テスト用のページや処理が本番に残っていない

AIで作ったアプリ・社内ツールのセキュリティ診断

公開して大丈夫か、第三者の目で確認します

• AIで作ったアプリを公開してよいか判断できない
• 社内にセキュリティを見られる担当者がいない
• 鍵やデータベースの権限設定が正しいか確認してほしい

八木（Last Scene）

AIで作ったアプリや社内ツールの診断に加えて、取引先からのセキュリティ要求への対応や、インシデント発生時の初動整理もご相談いただけます。
「このまま公開して大丈夫？」の一問からどうぞ。

セキュリティ顧問の詳細を見る

公開前チェックリスト4：入力と外部連携（よくある脆弱性）

利用者が入力した文字や、外部から受け取るデータの扱いにも注意が必要です。

ここは専門的な話が多くなるため、全体像をつかみ、AIに確認を頼むときの観点として使ってください。

IPAが取り上げる11種類の脆弱性

IPA「安全なウェブサイトの作り方」の第1章で取り上げられている脆弱性は、次の11種類です。

引用元：IPA「安全なウェブサイトの作り方」 https://www.ipa.go.jp/security/vuln/websecurity/about.html

表の右の列は、各脆弱性の内容をもとに本記事が補ったものです。IPAは、項番は対策の優先順位を示すものではないとしています。

SupabaseやFirebaseの公式の仕組みを使い、入力をそのままSQL文やコマンドに組み込まない作りであれば、1.1や1.2の危険は小さくなります。

一方、AIが「早く動かすため」に文字列をつなげてSQL文を作るコードを書くことがあるため、念のため確認しておきましょう。

OWASP Top 10（2025年版）で全体像を確かめる

OWASP Top 10は、ウェブアプリケーションのセキュリティで特に重大なリスクを、世界の専門家の合意としてまとめた資料です。

2025年版の10項目は次のとおりです。

1. Broken Access Control（アクセス制御の不備）
2. Security Misconfiguration（セキュリティの設定ミス）
3. Software Supply Chain Failures（ソフトウェアのサプライチェーンの不備）
4. Cryptographic Failures（暗号化の不備）
5. Injection（インジェクション）
6. Insecure Design（安全でない設計）
7. Authentication Failures（認証の不備）
8. Software or Data Integrity Failures（ソフトウェアやデータの完全性の不備）
9. Security Logging and Alerting Failures（ログと通知の不備）
10. Mishandling of Exceptional Conditions（例外的な状況の扱いの誤り）

引用元：OWASP「OWASP Top 10:2025」 https://owasp.org/Top10/2025/

日本語の訳は本記事によるものです。1位のアクセス制御と2位の設定ミスは、ここまでの鍵・RLS・ログインのチェックと重なっています。

使っている部品（ライブラリ）を更新する

AIで作ったアプリも、たくさんの外部の部品（ライブラリ）を組み合わせて動いています。

部品に脆弱性が見つかることは珍しくありません。OWASP Top 10の2025年版でも、3位に「ソフトウェアのサプライチェーンの不備」が入っています。

GitHubを使っている場合は、Dependabotなどの機能で、使っている部品の更新を知らせてもらう方法があります。

古いバージョンを使い続けるリスクについては、PHPのサポート終了のリスクでも詳しく解説しています。

外部のAIサービスに渡すデータを決める

アプリの中で、ChatGPTやClaudeなど外部のAIサービスを呼び出している場合は、そこに何を送っているかも確認しましょう。

お客様の個人情報や社外秘の情報を、そのまま外部のAIに送る作りになっていないかがポイントです。

生成AIに渡す情報のルールづくりは、生成AIの情報漏洩対策で詳しく解説しています。

アプリの中でAIを使うときの注意（OWASP Top 10 for LLM）

アプリの機能としてAIを呼び出す場合は、通常の脆弱性とは別の危険があります。OWASPの「Top 10 for LLM Applications 2025」では、次の10項目が挙げられています。

引用元：OWASP「Top 10 for LLM Applications 2025」 https://genai.owasp.org/llm-top-10/

プロンプトインジェクションは「完全には防げない」前提で作る

OWASPは、プロンプトインジェクションについて「確実に防ぐ方法は知られていない」としています。そのうえで、被害を小さくする対策として次のようなものを挙げています。

1. AIの役割と、やってよいことを指示文で絞る
2. AIの出力の形式（決まった項目だけのJSONなど）を決め、プログラム側で確かめる
3. 入力と出力の両方に、不審な内容がないか確かめる仕組みを入れる
4. APIの鍵はAIに渡さず、プログラムの側で扱う（最小権限）
5. メール送信や削除など、影響の大きい操作の前には人が確認する
6. Webページや添付ファイルなど、外から来た内容は指示と分けて扱う
7. 公開前に、わざと悪意のある入力を試してみる

引用元：OWASP「LLM01:2025 Prompt Injection」 https://genai.owasp.org/llmrisk/llm01-prompt-injection/

OWASPの例では、問い合わせ対応のAIが入力欄の指示に従って、本来できないはずのメール送信をしてしまう場面や、要約を頼んだWebページに隠れた指示が書かれていた場面が紹介されています。AIに「何をさせないか」は、指示文ではなく権限で決めるのが基本です。

セキュリティ関連のHTTPヘッダーを設定する

ブラウザに「このページで実行してよいスクリプト」を伝える仕組みとして、Content-Security-Policy（CSP）というHTTPヘッダーがあります。MDNでは、クロスサイトスクリプティングの被害を小さくするために、次のような「厳格なCSP」が紹介されています。

引用元：MDN「コンテンツセキュリティポリシー（CSP）」 https://developer.mozilla.org/ja/docs/Web/HTTP/Guides/CSP

MDNによると、'unsafe-inline' を許可するとCSPの効果が大きく下がります。また、いきなり本番で有効にすると画面が壊れることがあるため、まずは Content-Security-Policy-Report-Only で違反を記録するだけにして、問題がないか確かめる方法が紹介されています。CSPは入力の無害化の代わりにはならないため、IPAの「安全なウェブサイトの作り方」の対策とあわせて使います。

Dependabotで部品の更新を自動で知らせる

GitHubを使っている場合は、Dependabotを有効にすると、使っている部品に新しい版が出たときに更新の提案が届きます。GitHubのドキュメントでは、リポジトリに .github/dependabot.yml を置いて、次のように設定する方法が説明されています。

引用元：GitHub Docs「Dependabot のバージョン アップデートの構成」 https://docs.github.com/ja/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates

届いた更新の提案は、テストが通ることを確かめてから取り込みます。提案を放置すると意味がないため、「毎週月曜に確認する」のように担当と曜日を決めておきましょう。

入力と外部連携のチェック項目

1. 入力をそのままSQL文やコマンドに組み込んでいない
2. 入力した文字が、そのままHTMLとして画面に出ていない
3. 問い合わせフォームなどで、メールの宛先を入力で変えられない
4. 使っている部品の更新を知らせてもらう仕組みがある
5. 外部のAIサービスに送るデータの範囲を決めている

公開前チェックリスト5：運用（バックアップ・利用上限・ログ）

公開したあとに困らないための準備も、公開前に済ませておきましょう。

ここは、攻撃を防ぐ対策というより「何かあったときに被害を小さくする」ための対策です。

バックアップを取り、戻せるか確かめる

IPAの「中小企業の情報セキュリティ対策ガイドライン」は、2026年に第4.0版へ改訂されました。

この改訂で、最初に取り組む「情報セキュリティ5か条」に「バックアップを取ろう!」が追加され、「6か条」になりました。

引用元：IPA「中小企業の情報セキュリティ対策ガイドライン」 https://www.ipa.go.jp/security/guide/sme/about.html

6か条の解説編では、バックアップの対策例として、定期的に取ること、安全な場所に保管すること、戻せるかを定期的に確認することなどが挙げられています。

引用元：IPA「情報セキュリティ6か条（解説編）」 https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/jouhousecurity6kajou(kaisetsuhen)_r16.pdf

解説編では「3-2-1ルール」も紹介されています。データのコピーを本体を含めて3つ以上持ち、2種類の媒体に保管し、そのうち1つは別の拠点などに置くという考え方です。

バックアップは「取っている」だけでなく「実際に戻せる」ことまで確かめましょう。

外部APIの利用上限と請求の通知

外部のAIサービスやクラウドは、使った分だけ料金がかかるものが多くあります。

鍵が漏れたり、処理が無限に繰り返されたりすると、短い期間で想定外の請求が届くおそれがあります。

各サービスの管理画面で、利用額の上限や、一定額を超えたときの通知を設定しておきましょう。

当社の公開前診断でも「お金と通知」として、利用料の上限と異常の通知が入っているかを確認項目にしています。

引用元：株式会社Last Scene「セキュリティ顧問｜AIで作ったアプリの公開前診断」 https://lastscene.co.jp/security-advisor

エラーの通知とログの中身

公開後にエラーが起きたとき、すぐに気づける仕組みも用意しておきましょう。

OWASP Top 10の2025年版では、9位に「ログと通知の不備」が入っています。何かが起きても気づけなければ、被害が広がってしまいます。

引用元：OWASP「OWASP Top 10:2025」 https://owasp.org/Top10/2025/

一方で、ログに鍵やパスワード、お客様の個人情報をそのまま書き出していないかも確認が必要です。ログが漏れたときに、そこから情報が広がってしまいます。

AIに任せている操作に、人の確認を入れる

アプリの中でAIに操作を任せている場合は、その範囲も見直しましょう。

データを消す、メールを送る、お金が動くといった取り消しにくい操作は、実行する前に人が確認する流れにしておくと安心です。

運用のチェック項目

1. バックアップを本体とは別の場所に取り、実際に戻せることを確かめた
2. 外部APIやクラウドの利用上限と、請求の通知を設定した
3. エラーが起きたときに通知が届く
4. ログに鍵・パスワード・個人情報をそのまま書き出していない
5. 消す・送る・お金が動く操作の前に、人の確認がある

公開前の確認を進める順番（半日でできる手順）

ここまでの項目を、どの順番で進めればよいかをまとめました。上から順に進めると、影響の大きいものから潰せます。

1. 鍵を探す：コードと.envを確認し、secret keyやservice_roleキーがブラウザ側やGitに入っていないか確かめる
2. Security Advisorを実行する：ERRORの指摘をゼロにし、WARNを1つずつ確かめる
3. 2つのアカウントで試す：AさんでログインしてBさんのデータのIDを指定し、見えないことを確かめる
4. ログインせずに試す：ログアウトした状態で、APIや管理画面を開けないことを確かめる
5. AIの機能を試す：「指示を無視して」などの入力で、余計な操作をしないか確かめる
6. 上限を設定する：外部APIの利用上限と、請求額の通知を設定する
7. バックアップから戻す：テスト環境で、実際に復元できるか確かめる
8. 記録を残す：確かめた日付と結果を、チェック表に書いておく

手順3と4は、セキュリティの知識がなくても、画面を操作するだけで確かめられます。

自分で確認しきれないときの選択肢

ここまでの25項目をすべて自分で確かめるのは、簡単ではありません。

自社だけで確認しきれないときに使える選択肢を紹介します。

IPAの「セキュリティ実装チェックリスト」を使う

IPAの「安全なウェブサイトの作り方」には、巻末にセキュリティ実装の状況を確かめるチェックリストが付いています。

IPAのページでは、このチェックリストがExcel形式でも配布されています。開発を外部に頼んでいる場合は、このチェックリストを開発会社に渡して確認してもらう使い方もできます。

引用元：IPA「安全なウェブサイトの作り方」 https://www.ipa.go.jp/security/vuln/websecurity/about.html

同じページで配布されている「ウェブ健康診断仕様」は、危険度の高い脆弱性など13の診断項目について、検出パターンと判定基準をまとめた資料です。

ただしIPAは、この診断は検査パターンを絞り込んだもので、脆弱性が見つからなくても安全宣言にはつながらないと注意しています。

AIに確認を頼むときのコツ

AIに「セキュリティを確認して」とだけ頼むと、一般的な注意点が並ぶだけで終わることがあります。

この記事のチェック項目のように、確認する観点を具体的に伝えると、より的を絞った答えが返ってきやすくなります。

1. 「secret keyやservice_roleキーが、ブラウザで動くコードに入っていないか探して」
2. 「RLSが無効になっているテーブルと、anonに付いているgrantを一覧にして」
3. 「ログインしていなくても呼び出せるAPIを一覧にして」
4. 「入力をそのままSQL文やHTMLに入れている箇所を探して」

ただし、AIの答えが正しいとは限りません。最後は、テスト用アカウントで実際に試して確かめましょう。

Claude Codeを使っている場合は、AIが勝手に.envを読んだり外部と通信したりしないよう、Claude Code自体の設定も見直しておくと安心です。

公開前の診断を外部に頼む

ログイン、権限、お金、個人データに関わる部分は、人の目で確認したほうがよい箇所です。

どの段階で外部の専門家に相談すべきかは、セキュリティ顧問が必要なタイミングで詳しく解説しています。

AI開発をこれから外部に頼む場合は、要件定義の段階でセキュリティの条件を書いておくと、あとから直す手間を減らせます。AI開発の要件定義も参考にしてください。

Claudeを会社で使うときのプランやデータの扱いは、Claudeの法人利用で解説しています。

よくある質問

社内だけで使う小さなツールでも、チェックは必要ですか

必要です。社内ツールでも、インターネットに公開されていれば、社外の人がアクセスできる可能性があります。

当社の診断事例も、予約・応募管理・申込フォームといった社内ツールでした。まずは鍵とデータベースのチェック項目だけでも確かめましょう。

AIに「セキュリティを確認して」と頼めば足りますか

足りないことがあります。AIは確認の出発点としては役立ちますが、見落としや誤りもあります。

この記事の観点を具体的に伝えて確認してもらい、最後はテスト用アカウントで実際に試すのがおすすめです。

Supabase以外（Firebaseなど）を使っていても同じですか

考え方は同じです。「ブラウザに秘密の鍵を置かない」「データベースの読み書きを、本人や権限のある人だけに絞る」という2点は、どのサービスでも共通です。

具体的な設定の方法は、使っているサービスの公式ドキュメントで確認してください。

公開したあとに問題が見つかったらどうすればよいですか

まず、鍵が漏れていればすぐに作り直し、データが見える状態になっていれば公開範囲を閉じるなど、被害の拡大を止めましょう。

個人データが漏れた、またはそのおそれがある場合は、個人情報保護委員会への報告が必要になることがあります。報告の要件は個人情報保護委員会のページで確認できます。

引用元：個人情報保護委員会「漏えい等の対応とお役立ち資料」 https://www.ppc.go.jp/personalinfo/legal/leakAction/

Security Advisorの指摘がゼロなら、安全と言えますか

言えません。Security Advisorはデータベースの設定でよくある誤りを見つける仕組みで、アプリのコードやログインの流れ、外部APIの使い方までは確かめません。URLのIDを書き換える確認や、ログインせずに呼び出す確認は、別に行ってください。

AIの機能に入れる指示文に、鍵を書いてもよいですか

書かないでください。OWASPのTop 10 for LLMでは、システムプロンプト（AIへの指示文）の内容が聞き出されるおそれがあるとして、指示文に機密情報を書かないよう求めています。鍵はプログラムの側で扱い、AIには渡さないようにします。

引用元：OWASP「Top 10 for LLM Applications 2025」 https://genai.owasp.org/llm-top-10/

CSPを設定したら、画面が表示されなくなりました

CSPで許可していないスクリプトや画像が止められている可能性があります。MDNが紹介しているように、まずはContent-Security-Policy-Report-Onlyで違反を記録するだけにして、どのファイルが止められているかを確かめてから、本番の設定に移しましょう。

まとめ｜公開前は「鍵」と「権限」から確かめる

AIで作ったアプリは、動いていても、誰に何を見せないかの設定が抜けていることがあります。

公開前は、鍵、データベースと権限、ログイン、入力と外部連携、運用の5つの場所を順に確認しましょう。

特に、secret keyをブラウザに置かないことと、すべてのテーブルでRLSを有効にすることは、最初に確かめたい項目です。

迷ったら「ログインしていない人から何が見えるか」「他人のデータが見えないか」の2つから試してみましょう！

公開前の最低限チェックリスト

1. ブラウザ側のコードにsecret keyが入っていない
2. .envがGitに上がっていない
3. 公開されているすべてのテーブルでRLSが有効
4. 2つのテスト用アカウントで、相手のデータが開けない
5. バックアップを取り、戻せることを確かめた

株式会社Last Sceneは、AIで作ったアプリの公開前診断と、公開後の見守りをセキュリティ顧問として提供しています。

コードが読めなくても、アプリの使い方と扱っているデータを伺えば、確認すべき箇所をこちらで判断します。直し方も、AIに指示できる形でお伝えします。

「公開して大丈夫か不安」という段階でも、気軽にご相談ください。

AIで作ったアプリ・社内ツールのセキュリティ診断

公開して大丈夫か、第三者の目で確認します

• AIで作ったアプリを公開してよいか判断できない
• 社内にセキュリティを見られる担当者がいない
• 鍵やデータベースの権限設定が正しいか確認してほしい

八木（Last Scene）

AIで作ったアプリや社内ツールの診断に加えて、取引先からのセキュリティ要求への対応や、インシデント発生時の初動整理もご相談いただけます。
「このまま公開して大丈夫？」の一問からどうぞ。

セキュリティ顧問の詳細を見る