アディザイン・Web事業部の吉田です。
AIで自作したシステムは、画面の上でちゃんと動いていても、そのまま社外に出して安全とは限りません。公開する前に、APIキーの置き場所、ログインや料金の判定をどこでしているか、データベースで読める人を絞る設定、他人のデータが見えないか、誰が開けるかの5つを確かめてください。
AIのセミナーや研修で伺っている会社では、社長さんや担当の方が、AIを使って自分の作りたいシステムをどんどん作られています。仕事をよく知っている人がAIで仕組みを作っていく、FDE思考と呼ばれる動きが、まさにこれに当たります。ただ、楽しみながら作られたあとに僕のところへ来る相談で多いのが、「この作り方でいいですか」という質問なんです。
見せていただくと、残念ながら、そのまま外に出すのはおすすめしにくい作りになっていることが少なくありません。皆さんが気にされるのも、やはりセキュリティの面です。
この記事では、相談でよく見る作りと、公開前に確かめたい5つのこと、AIに安全面を見てもらうサービス、どこからプロに見てもらうかを紹介します。
相談で多いのは「動くけど、この作り方でいいですか」
AIに話しかけながらプログラムを作ってもらうやり方は、バイブコーディングと呼ばれます。研修先でそうやって作られたシステムを見せていただくと、よく似た作りが目に付きます。作られた方ご自身が気づかれないまま使われているところが、多くのシステムに共通しています。
1つ目は、全部をブラウザで動くプログラムだけで組んでいる作りです。ブラウザで動くプログラムの言語を JavaScript（ジャバスクリプト）といい、全部をこれで動かすと、画面の表示だけでなく、計算やログインの確認まで、この中に書くことになります。
2つ目は、データベースで動いていない作りです。データベースは、データをためておき、必要な分だけ素早く取り出すための仕組みを指します。これを使わないと、データは1つのファイルや、使っているパソコンのブラウザの中にまとめて置くことになり、データが増えるほど動きがもっさりしてきます。
3つ目は、1つ目の結果として、プログラムの中身が外から全部見えている作りです。ブラウザで動くプログラムは、利用者のパソコンに送られてから動くので、ブラウザに付いている開発者向けの機能を使えば、誰でも中身を読めます。
ブラウザだけで動く作りは、ファイルを開けばすぐ動くので、作って試すまでがとても早く進みます。自分ひとりで試す段階なら、悪い作りではありません。困るのは、それをそのまま社外の人や社員みんなに使ってもらうときです。
全部をブラウザで動かす作り（自分で試す段階）プログラムの中身は、ブラウザの機能で誰でも読める
画面・サーバー・データベースに分けた作り（社外に出す段階）大事な処理はサーバーの中で動き、利用者からは見えない
全部をブラウザで動かす作り（自分で試す段階）APIキーやパスワードがプログラムに書かれていると、読めば分かる
画面・サーバー・データベースに分けた作り（社外に出す段階）APIキーやパスワードはサーバーにだけ置き、画面には送らない
全部をブラウザで動かす作り（自分で試す段階）データは1つのファイルや、そのパソコンの中に置かれる
画面・サーバー・データベースに分けた作り（社外に出す段階）データはデータベースに入り、必要な分だけ取り出す
全部をブラウザで動かす作り（自分で試す段階）データが増えるほど、開くたびに重くなる
画面・サーバー・データベースに分けた作り（社外に出す段階）データが増えても、読むのは必要な分だけで済む
全部をブラウザで動かす作り（自分で試す段階）ログインの確認は画面の上だけで、書き換えれば通れてしまう
画面・サーバー・データベースに分けた作り（社外に出す段階）ログインはサーバーが確かめ、本人のデータだけを渡す
サーバーは、会社の側で動いていて、利用者からは中身が見えないコンピューターのことです。画面（ブラウザ）・サーバー・データベースの3つに役割を分けておけば、見せてはいけないものを利用者のパソコンに送らずに済みます。
バイブコーディングで作ったら、公開前に確かめたい5つのこと
相談でよく見る作りから考えると、公開前に確かめたいのは次の5つです。どれも、作った本人が画面を見ているだけでは気づきにくいところなので、上から順に確かめてみてください。
1. APIキーやパスワードが、画面のプログラムに書かれていないか
APIキーは、AIや地図、決済などの外部のサービスを、自分のシステムから使うための専用の文字列です。これが画面のプログラムに書かれていると、中身を読んだ人が同じキーを使えてしまい、使われた分の請求が自分に来ることがあります。Google も OpenAI も、APIキーをブラウザやアプリのプログラムに書かないよう案内しています。
確かめ方は、自分のシステムをブラウザで開き、画面の上で右クリックして「ページのソースを表示」を選ぶところからです（Chrome や Edge の場合）。出てきた文字の中を、キーボードの「Ctrl＋F」（Mac は「command＋F」）で検索します。サービスの管理画面に表示されているキーの最初の数文字で検索すると、関係のない文字に引っかからずに見つけやすくなります。
プログラムが別のファイルに分かれていて、この画面だけでは見つからないときは、作るのに使ったAIに「利用者のブラウザに送られるファイルに、APIキーやパスワードが入っていないか調べて」と指示するのが早いです。
見つかったら、プログラムから消すだけでは足りません。一度でも公開したキーは、サービスの管理画面で無効にして作り直し、新しいキーはサーバーの側にだけ置いてください。GitHub の案内でも、漏れたキーはすでに使われたものとして扱い、発行元で無効にするのが一番大事な手当てだとしています。
ただし、Supabase のようなデータベースのサービスには、画面に置く前提で作られた公開用のキーもあります。この種類のキーは見えても構わない代わりに、3つ目の「誰がどのデータを読めるか」の設定で守る作りなので、そちらを必ず確かめてください。
2. ログイン・料金・権限の判定を、画面のプログラムだけでしていないか
「この人は管理者だから、この画面を見せる」「会員なので1割引きにする」といった判定を、ブラウザのプログラムの中だけでしていると、プログラムを書き換えれば誰でも管理者になれてしまいます。MDN（Webの技術の解説書）にも、画面側の確認はすり抜けられることがあるので、サーバーでも確かめる必要がある、という説明があります。
確かめるときは、AIに「ログイン、権限、料金の計算は、どこで確かめているか」と聞いてください。答えが「ブラウザの側」なら、その判定をサーバーの側へ移すように作り直します。
全部をブラウザだけで作っていて、そもそもサーバーが無い場合は、サーバーとデータベースのある作りへ移すところから始めます。どう組むかの案はAIにも出させられますが、ここはシステムの土台を決める部分になります。僕が、最初の設計にはプロに入ってもらうのがいいと思うのは、この部分があるからです。
3. データがデータベースに入っていて、読める人が絞られているか
お客さまの名前や注文、在庫のような毎日の仕事のデータは、会社の財産です。1つのファイルにまとめて公開の場所に置いていると、ファイルの場所を知った人が全部を持ち帰れてしまいます。
AIでシステムを作ると、Supabase や Firebase のようなデータベースのサービスを使った作りになることも多いです。これらは、画面のプログラムからデータベースにつなぐ作りを前提にしていて、「誰がどのデータを読めるか」の設定でデータを守ります。この設定が入っていないと、つなぎ方を知った人が全部のデータを読み書きできてしまうので、ここは必ず確かめてください。
Supabase の公式の説明では、公開する前に、データを入れているすべての表で、行ごとの読み書きの制限（Row Level Security）を有効にするよう書かれています。Firebase の説明でも、誰でも読み書きできる設定は、本番では使わないようにと注意があります。
使っているデータベースのサービスが分かれば、AIに「このデータベースで、ログインしていない人や別の人が、ほかの人のデータを読み書きできないか、設定を確かめて」と指示すれば確かめられます。データベースを使っていない作りなら、データベースに移すことを考えてください。必要な分だけ取り出す仕組みなので、データが増えても動きが重くなりにくくなります。
4. 別の人のアカウントで、他人のデータが見えないか
ログインのあるシステムなら、テスト用のアカウントを2つ作って、実際に試してみてください。Aさんのアカウントで登録したデータが、Bさんでログインしたときに見えたり、直せたりしたら、その作りのまま公開するのはやめておきましょう。
もう1つ試したいのが、画面の上のURL（アドレス）です。URLの最後に「id=12」のような番号が付いているなら、その番号を1つ変えて開き直してみてください。他人のページが開いてしまう作りは、AIで作ったシステムに限らず起きていて、Webの安全の指針として世界中で使われている「OWASP Top 10」の2025年版でも、こうしたアクセスの制御の不備が1位に挙がっています。
見つかったら、AIに「ログインしている本人のデータだけを返すように直して」と指示し、直したあとにもう一度2つのアカウントで試します。お客さまの情報が入っているシステムなら、直したあとにプロにも見てもらってください。
5. 誰に公開しているかを決めているか
社内だけで使うつもりのシステムを、URLを知っていれば誰でも開ける場所に置いていることがあります。ファイルを置くだけでWebに公開できるサービスは手軽ですが、何も設定しなければ、世界中の誰でも開けてしまいます。
確かめるには、ログインしていない状態のブラウザ（Chrome のシークレットウィンドウなど）や、会社のWi-Fiにつないでいないスマホで、そのURLを開いてみてください。開けてしまったら、誰でも開ける状態になっています。
使う人が社内だけなら、パスワードをかける、会社のアカウントでログインした人だけが開けるようにする、といったアクセスの制限を先に付けてください。どこで設定するか分からなければ、AIに「このシステムを、社内の人だけが開けるようにする方法を、今の公開の仕方に合わせて教えて」と指示すると、手順を出してくれます。社外の人に使ってもらうなら、ここまでの1〜4をすべて確かめてから公開します。
AIで作ったアプリの事故は、実際に起きている
5つの確認がなぜ大事かは、実際に起きた事故を見ると分かりやすいです。AIのエージェントどうしが投稿しあうSNS「Moltbook」では、セキュリティの会社 Wiz の調査で、データベースが外から読み書きできる状態だったことが分かりました。
Wiz によると、ブラウザで動くプログラムに Supabase のキーが書かれていたうえに、読める人を絞る設定（Row Level Security）が入っていませんでした。そのため、認証用のトークン約150万件、メールアドレス約3万5,000件、非公開のやり取り4,060件が、外から見られる状態になっていたそうです。Wiz の記事では、創業者が「コードを1行も書いていない」と話していたことにも触れています。報告を受けて、2026年2月1日には修正されました。
Wiz は、読める人の設定が正しく入っていれば、画面に置いた公開用のキーは見えても安全だとも書いています。画面に置いたキーを、読める人の設定（3つ目）で守れていなかったのが、この事故の中心です。
2025年には、AIでアプリを作るサービス Lovable で作られた1,645件のアプリを調べたところ、170件でデータベースで読める人を絞る設定が足りず、個人情報やAPIキーが見える状態だったという報告もありました。この件は脆弱性の番号（CVE-2025-48757）が付いていて、Lovable 側は「データを守る設定は利用者の責任」と異議を唱えています。
AIが書いたプログラムそのものを調べた検証もあります。検査ツールを作っている Veracode が、4年間で100を超えるAIのモデルを試した結果をまとめた「2026 GenAI Code Security Report」によると、およそ44%の課題で危ない脆弱性が入りました。画面に悪いプログラムを差し込まれる攻撃（XSS）を防げた割合は、15%にとどまっています。
日本でも、JPCERT/CC（国内のセキュリティの事故に対応する機関）が2026年10月8日に、一般公開しているスマートフォンアプリを解析して、APIの接続先やキーを特定する手口が使われていると注意を呼びかけています。
AIに安全面を見てもらうサービスも出てきた
作ったプログラムの安全面は、AIに見てもらうこともできます。Anthropic は2026年2月に、プログラム全体の脆弱性を探して直し方の案を出す「Claude Code Security」（今の名前は Claude Security）を発表し、10月15日には、変更を元のプログラムに取り込む前に複数のAIでレビューする「Code Review」の一般提供を始めました。
どれも、作ったプログラムのファイルが手元にあって、Claude Code や GitHub（プログラムのファイルと変更の履歴を預けておくサービス）で扱っていることが前提です。主なものを、使う場面ごとに並べてみます。
| サービス | いつ・何を見てくれるか | 使える人・前提 |
|---|---|---|
| Claude Code の security-guidance プラグイン | Claude がプログラムを書いているそばで安全面を確かめ、その場で直す | Claude Code の全プランで使える。作業フォルダの変更の履歴を Git（変更の履歴を残す仕組み）で残していることが前提 |
| Claude Code の「/security-review」 | 指示したときに1回、作業中の変更を見て、問題と直し方を出す | Claude Code の利用者 |
| Claude Code の Claude Security プラグイン | 指示したときに、プログラム全体を複数のAIで深く調べ、問題と直し方の案を出す | Claude Code の有料プラン（Pro プランは設定で有効にする）か、APIの従量課金での利用 |
| Claude Security（管理つきのサービス） | GitHub などに預けたプログラムを見張り、定期的に調べる | Enterprise プラン |
| Code Review（Claude Code） | GitHub に上げた変更を、元のプログラムに取り込む前に、複数のAIで不具合と脆弱性をレビューする | Team・Enterprise プランで、GitHub を使っていること |
| GitHub Copilot code review | GitHub に上げた変更をレビューし、脆弱性も指摘する | GitHub Copilot の有料プラン |
自分で作っている方なら、まずは使っているAIでできる範囲から試すのが手軽です。Claude Code を使っているなら、security-guidance（Claude Code に後から足せる機能の1つ）を入れておくと、書いている途中の問題をその場で直してくれます。
ただ、どのサービスも「これを通せば安全」とは言っていません。Code Review の説明には、指摘が1つも無くても、プログラムに誤りが無い・安全だという意味ではない、と書かれています。直す内容は人が確かめて決める作りで、Claude Security も、直しの案を自動で取り込むことはありません。
もう1つ知っておきたいのが、こうしたレビューが読むのは手元のプログラムで、動いているサイトや本番の設定ではない、という点です。データベースで読める人を絞る設定（3つ目）と、公開の範囲（5つ目）は、AIのレビューとは別に確かめる必要があります。
最初から安全な土台の上で作るという選び方もある
安全面を後から確かめるのではなく、最初から守られた土台の上でAIにアプリを作らせる、という選び方も出てきました。Cloudflare が2026年8月に公開した「Cloudflare OS」は、開発者でない社員も、ブラウザの上でAIに話しかけて自分用のアプリを作れる仕組みです。
この仕組みでは、作ったアプリは最初、会社のどのデータにも触れない状態から始まります。外のサービスにつなぐためのキーは、間に立つ仕組み（Gatekeeper）が預かり、AIが作ったプログラムには渡りません。誰が使えるかも、Cloudflare のアクセスの管理（Cloudflare Access）で決めます。
5つの確認のうち、1つ目のキーの置き場所と、5つ目の公開の範囲を、作る人が気をつける前に土台の側で守ってくれる形です。
今公開されているのは、GitHub で公開されている仕組みを、自分の Cloudflare のアカウントに設置して使う形です。設置から運用までを Cloudflare に任せられる形は、2026年10月1日に順番待ちの受付が始まったところで、料金もまだ出ていません。すぐに誰でも使える段階ではないので、土台を選ぶときの選択肢の1つとして覚えておいてください。
どこからプロに見てもらうか
自分たちで確かめたあと、どこからプロに見てもらうかは、誰が使うか、何のデータを扱うかで分かれます。
あなたの場合
5つの確認とAIのチェックから始める
社内だけで使い、個人情報も入らないなら、まずはこの記事の5つの確認とAIのチェックから始められます。それで安全が保証されるわけではないので、アクセスの制限（5つ目）は必ず付けてください。
「バイブコーディングで作ったら」の章を読む
あなたの場合
公開する前に、プロに見てもらう
社外の人が使う、または個人情報やお金の記録を入れるなら、5つの確認とAIのチェックのあとに、プロの確認を入れてから公開してください。
「アディザインに相談する場合」の章を読む
僕は、作るところまではAIで一気に進めて、最初の設計と最後のチェックにだけプロに入ってもらう形がいいと思っています。データベースの組み方やサーバーの選び方を最初に決めておけば、AIはその上で動くところまで作れます。最後に、セキュリティやサーバーの設定をプロが確かめてから公開します。
プロに見てもらう前に、自分でも全体を眺めておきたい方には、IPA（情報処理推進機構）の「安全なウェブサイトの作り方」がまとまっています。よくある脆弱性の種類ごとに、確かめるためのチェックリストも付いているので、気になるところから読めます。
AIでの開発に慣れてきたら、その最後のチェックも、AIのレビューの仕組みで自動にしていけます。プログラム未経験の社長さんが、動くところまでAIで作り、最後にエンジニアさんに確認してもらってからサービスを始められた例は、ピークスキャリアさんの1on1レクチャーの記事で書いています。
自分で確かめるなら、この依頼文をAIに貼る
自分のシステムを作るのに使ったAI（Claude Code・Codex・Cursor など、作ったファイルを読めるもの）に、次の依頼文をそのまま貼ってみてください。チャットの画面だけで作った場合は、作ったファイルを全部渡したうえで貼ります。いきなり直させず、先に調べた結果を報告してもらうのがポイントです。
このシステムを社外に公開する前に、安全面を確かめたいです。
プログラムはまだ直さずに、次の5つを調べて、結果を専門用語を使わずに報告してください。
1. APIキー・パスワード・秘密の値が、利用者のブラウザに送られるファイルに書かれていないか（画面に置く前提の公開用のキーなら、そう書いてください）
2. ログイン・権限・料金の計算を、ブラウザの側だけで判定していないか
3. データはどこに保存されているか。データベースなら、ログインしていない人や別の人が、ほかの人のデータを読み書きできる設定になっていないか
4. URLの番号などを変えると、他人のデータやページが見えてしまう作りになっていないか
5. 今の公開の仕方で、誰がこのシステムを開けるか
それぞれ「問題なし／問題あり／分からない」で答え、問題ありのものは、何が起きうるかと、直し方の案を書いてください。
3と5のように、プログラムを読むだけでは分からないものは「分からない」とし、どの画面で何を確かめればいいかを書いてください。
直してよいかは、報告を読んでから私が決めます。報告で「分からない」が残ったものや、AIに直させても直ったかを自分では確かめられないものは、プロに見てもらうところです。社外の人が使うシステムなら、直したあとにもプロの確認を入れてください。
アディザインに相談する場合
研修やセミナーで伺ったときにも、作られたシステムを見せていただいて、「この作り方でいいですか」の相談に乗っています。作ったものを社外に出せる作りに直したいときも含めて、状況に合わせて次のページをご覧ください。
- 作ったシステムを、社外に出せる作りに直したい・作り直したいWebアプリ・システム開発（AIでの開発の代行と、社内への引き継ぎにも対応しています）
- 自社の困りごとを題材に、AIで作るところから一緒に進めたい課題解決型セミナー
- 社員みんなで、AIの使い方と気をつけたいことを知りたいAI基礎講座
- セミナー・研修の全体を見て決めたいAI活用・セミナー
最新の内容と料金は、各ページで確認してください。
よくある質問
Q. AIにセキュリティを確かめてもらえば、プロの確認はいりませんか？
社内だけで使い、個人情報も入らないシステムなら、まずはAIのチェックと5つの確認から始められます。ただ、それで安全が保証されるわけではありません。社外の人が使う、または個人情報やお金の記録を入れるなら、AIのチェックのあとにプロの確認を入れてください。AIのレビューのサービスを出している会社も、最後は人が確かめる前提で作っています。
Q. 社内だけで使うシステムなら、気にしなくていいですか？
社内だけでも、URLを知っていれば誰でも開ける場所に置いていれば、外から見えます。少なくとも、パスワードや会社のアカウントでのログインのようなアクセスの制限は付けてください。
Q. ブラウザだけで動く作りは、使ってはいけないのですか？
自分ひとりで試す段階や、秘密の値もお客さまのデータも扱わないツールなら、ブラウザだけで動く作りでも問題になりにくいです。社外の人に使ってもらう段階になったら、画面・サーバー・データベースに分けた作りへ移すことを考えてください。
