バイブコーディングのセキュリティ｜業務アプリを作る前に、誰が・何で・どのデータとつながるかを決める

バイブコーディングの基本と失敗例は既存記事で説明しています。この記事では、中小企業の非エンジニアが業務アプリを開発するときのセキュリティに絞り、コードの脆弱性と業務上の決めごとを分けて扱います。

動く画面ができても、安全とは限りません。AIへの指示に書いていない入力値の検証や公開設定まで自動的に整うとは限らないため、人に渡す前にコードレビューと動作検証を行います。

バイブコーディングで起きやすいセキュリティのリスク4つ

ここで挙げる4つは、脆弱性の網羅的な分類ではありません。中小企業の非エンジニアが業務アプリを作る場面で、作る前の判断によって減らしやすいリスクを、ログインと権限、パスワードやAPIキー、実データ、AIに渡す情報に分けたものです。

リスク	起きること	先に打つ手
ログインと権限が抜ける	誰でも開ける画面、他の人のデータまで見える画面ができる	誰が・何を見てよいかを、作る前に役割ごとに書く
パスワードやAPIキーが漏れる	コードの中に鍵が直接書かれ、共有や公開で外に出る	鍵はコードの外に置き、名義は会社にする
実際の顧客データが入る	試しに入れた実データが、人に見せた画面にそのまま残る	試す間はダミー、本番の前にコピーで確かめる
AIに渡す情報が出ていく	顧客名や契約内容を、そのままAIの入力欄に貼る	渡してよい情報を先に決め、名前は伏せる

この4つとは別に、コードそのものにはSQLインジェクション、XSS、認証・認可の不備、古い依存パッケージ、公開設定の誤りなどが含まれる可能性があります。IPAの「安全なウェブサイトの作り方」も、SQLインジェクション、XSS、アクセス制御や認可制御の欠落などを個別に挙げています。

SQLインジェクションは、入力された文字列がデータベースへの命令として解釈される問題です。XSSは、入力された内容が画面に表示されるとき、意図しないスクリプトまで実行される問題です。どちらも画面を普通に操作するだけでは見落とせるため、入力欄ごとのテストとコードレビューを行います。

コードを読める人に、少なくとも次の内容を確認してもらいます。

入力値がデータベースへの命令として扱われず、画面へ出す文字列が適切に処理されているか。
ログインしていない人や別の役割の人が、URLを直接開いてもデータを読んだり直したりできないか。
使っている依存パッケージに既知の脆弱性がなく、開発用の設定や不要な画面が公開環境に残っていないか。

セキュリティは「誰が・何で・どのデータ」を決めるところから始まる

セキュリティの対策は、コードを書かせてから足すものではなく、作る前の3つの決めごとから出てきます。AIにコードを書かせる前に、誰が使うか・何で使うか・どのデータとつながるかを決めておくと、守る対象が先に見えるからです。

セキュリティの項目は、作る前の3つの決めごとから出てきます。決めずに始めると、守る対象が見えないまま画面だけが増えます。

決めごとの書き方は、バイブコーディングの始め方と要件定義をAIで進める方法で説明しています。データの箱と線はER図をAIで作成する方法で下書きできます。

ログインと権限｜画面を作る前に、役割ごとに書く

ログインと権限は、AIに「ログイン機能も付けて」と頼むだけでは足りません。誰がどの項目を見てよく、どの項目を直してよいかが決まっていないと、AIは全員が全部見られる形で作るからです。

作る前に、役割ごとの表を書きます。たとえば、営業担当は自分の案件だけ見られる、事務は入力できるが経営数字は見られない、経営者は全部見られる、といった形です。この表をAIに渡して作らせ、できあがったら、役割を変えて実際にログインし、見えてはいけない画面が見えていないかを自分の目で確かめます。

画面のURLを知っていれば開ける作りになっていないかも、ここで見ます。ログインなしで開ける画面を一覧にさせると、抜けている画面が見つかります。

パスワードとAPIキー｜コードの外に置き、名義は会社にする

パスワードやAPIキーは、コードの中に直接書かず、利用するサービスの秘密情報用の保管先に置きます。OWASPのSecrets Management Cheat Sheetは、平文の秘密情報がソースコードや設定ファイルに直接書かれている実態を挙げ、一元的な保管とアクセス管理を勧めています。コードに直接書いた鍵は、コードを共有または公開した相手から読めるため、共有前に取り除きます。見つけ方と直し方はAPIキーの直書きを確かめる方法で説明しています。

鍵には、置き場所のほかに名義の問題もあります。収益物件の仕入れ査定表で外部の不動産データを呼び出していた支援先では、試作中はこちらのキーで動かし、運用を始める定例で、先方の担当者にその場でキーを発行してもらって切り替えました。最初から、使う会社の名義で発行してもらうのが筋です。担当者が替わっても鍵の持ち主が分かり、止めたいときに会社として止められます。

AIに、ログインを任せない

業務システムや素材サイトの作業を、AIのブラウザ操作に任せる使い方が始まっています。AI用のIDを作ってパスワードも渡せば楽だ、という発想が出てきますが、ログインは人が行います。パスワードを渡すと、鍵の管理が増えるだけでなく、あとから誰の操作だったかが分からなくなります。ログインしたあとの作業を任せる、という分け方にします。

実際の顧客データ｜試す間はダミー、本番の前にコピー

試す間はダミーのデータを使い、実際の顧客データは、アプリの確認が済んでから入れます。試しに入れた実データは、画面やサンプルに残ったまま、人に見せてしまうことがあるからです。

実際の業務で試したいときは、本物を直接使わず、氏名や連絡先を伏せたコピーを作って使います。伏せ方は個人情報の匿名化の方法にまとめています。本番に切り替えるときは、元のデータを壊さないよう、前日の状態へ戻す手順を先に書いておきます。

AIに渡す情報｜渡してよいものを先に決める

AIに渡す情報は、作る前に「渡してよいもの」と「渡さないもの」を分けます。顧客名や契約内容をそのまま貼る癖がつくと、あとから取り消せないからです。名前は記号に置き換える、金額は桁だけ残す、といったルールにします。

不動産売買仲介の会社では、自社の成約データを使った相場マップをAIで作っていたところ、AIから「お客様に正直さを掲げているのに、ここでそれをやるのか」と指摘され、本人の判断でそのマップを削除しました。AIが止めてくれる場面もありますが、頼りにするのではなく、渡してよい範囲と使い方の線を先に引いておくほうが確実です。

人に渡す前の確認表｜AIに一覧を出させ、人が決める

人に渡す前の確認は、ログイン、権限、鍵・パスワード、実データ、公開範囲、戻し方の6項目です。AIに各項目の一覧を出させ、直す内容は業務を知っている人が決めます。AIの回答だけで完了にせず、実際の画面、設定、コードで直ったことを確かめます。

項目	AIへの頼み方（例）	人が見ること
ログイン	ログインなしで開ける画面を一覧にして	一覧のうち、開いてよい画面だけが残っているか
権限	役割ごとに、見られる項目と直せる項目を表にして	表が業務の実態と合っているか。事務の人が経営数字を見られないか
鍵・パスワード	コードの中に直接書かれた鍵やパスワードを一覧にして	一覧が空か。残っていれば、置き場所を変えて鍵を発行し直す
実データ	実際の氏名・電話番号・金額が入っていないか探して	画面、サンプル、ログのどこにも実データが残っていないか
公開範囲	このアプリを開けるURLと、開ける人の条件を書いて	条件が「社内の決まった人だけ」になっているか
戻し方	データが壊れたときに、前日の状態へ戻す手順を書いて	手順を読んで、実際に戻せそうか

レビューを頼むときは、アプリの使われ方も伝えます。

6項目が済んだら、開発者やコードを読める人に、権限、入力、データの持ち方を中心に見てもらいます。「セキュリティを確認してください」だけでは範囲が曖昧です。誰が使うアプリか、扱う機密情報は何か、外部とつながる箇所はどこか、公開後に困ることは何かも伝えると、レビューする人が確認の優先順位を決められます。

レビュー後は、直したという説明だけで終えず、ログインしていない状態、権限が異なる利用者、想定外の長さや記号を含む入力でも試します。エラー画面にデータベース名や設定値が表示されないか、削除や更新の前に確認が入るかも見ます。公開範囲や依存パッケージは、コードとは別の設定にあることが多いため、検証の対象に含めます。

チェックの観点は、公式のIPA「安全なウェブサイトの作り方」が参考になります。より広く脆弱性の種類を知りたいときは、OWASP Top 10があります。公開前の段階の見分け方は社内利用と本番公開の境目、導入前の確認はAIで作った社内ツールの本番導入前チェックリストにあります。

AIに確定させない工程を、1つ決めておく

AIに任せる範囲を決めるときは、AIに確定させない工程を最低1つ決めておきます。確定の操作まで任せると、間違いが外に出てから気づくことになるからです。

メールの返信準備を自動化した例では、AIの担当は候補の一覧と下書きまでにしました。どれに返すかを選ぶのと、送信は人がやります。アプリでも同じで、鍵の発行、ログイン、公開、送信、データの削除は人が確定する工程に置きます。

AIは候補と下書きまで、確定は人です。境目を決めておくと、間違いが外に出る前に止められます。

セキュリティの面で、バイブコーディングだけで進めない場面

請求金額や給与の計算、社外の人が触れる画面での個人情報、止まると業務が止まるアプリ、保管場所が規程や契約で決まっている情報を扱う場合は、バイブコーディングだけで進めず、作る内容を決める段階から経験のある人に入ってもらうほうが安全です。

請求金額や給与のように、間違いが金銭に直結する計算を扱う。
顧客の個人情報を、社外の人が触れる画面で扱う。
止まると、その日の業務が止まる。
社内の規程や取引先との契約で、情報の持ち出しや保管場所が決まっている。

会社としての情報の扱いの決め方は、中小企業のセキュリティポリシーの記事にあります。

備えができているかを、来週から測る

備えができているかは、次の3つを記録すると数字で分かります。

確認表6項目のうち、人に渡す前に済んでいた数：毎回6項目になれば、手順が定着しています。
コードの中から見つかった鍵やパスワードの数：渡すたびに減り、0になるのが目標です。
実データが画面やサンプルに残っていた回数：見つかるたびに記録し、減っているかを見ます。

4週間たっても見つかる数が減らないなら、決めごとの1枚が足りないか、1回の依頼が大きすぎる可能性があります。依頼を小さくして、作る前の1枚を書き直します。

まとめ｜守る対象を先に決めてから、AIに作らせる

ログインと権限の抜け、鍵の漏れ、実データの混入、AIへの情報流出といった、業務上の決めごとに由来するリスクは、コードを書かせる前に誰が使い、何で使い、どのデータとつながるかを決めることで減らせます。SQLインジェクションやXSSなどコード自体の脆弱性は、コードを読める人のレビューとテストが別に必要です。

SalesDockは、コードの前に業務の流れを文章にする進め方で、経営管理基盤づくりを支援しています。まずは自分だけが使う小さな業務を1つ選び、誰が、何で、どのデータとつながるかを書いてから、確認表の6項目を通してください。

作る前の1枚と確認表を一緒に見るところから相談できます

作りたい業務アプリの、誰が使うか・何で使うか・どのデータとつながるかを、いまの業務を聞きながら整理します。人に渡す前に何を確認すべきかも、その場でお伝えします。

30分の無料相談を予約する

一次情報・公式情報

バイブコーディングのセキュリティに関するよくある質問

バイブコーディングのセキュリティは、何から確認すればよいですか？

最初に、SQLインジェクションやXSS、認証・認可の抜けなど、コード自体の脆弱性をコードレビューとテストで確認します。並行して、ログインと権限、APIキーの置き場所、実データの混入、AIに渡す情報を確認します。AIには候補を一覧にさせ、直せたかどうかは人が検証します。

AIが書いたコードは、そのまま使うと危険ですか？

動いたことと安全なことは別です。ログインや入力値のチェックが抜けたまま動くことがあり、動作確認だけでは見つかりません。自分だけが使い、ダミーデータだけを入れる範囲なら影響は小さく、ほかの人に渡す前や顧客の情報を扱う前に、コードを読める人が確認すると安全側に寄せられます。

業務アプリを作るとき、AIにAPIキーやパスワードを渡してもよいですか？

渡さないのが基本です。AIに作業の中でログインさせたい場合も、ログインや認証は人が行います。AI専用のIDを作ってパスワードを渡す方法は、鍵の管理が増えるうえ、誰の操作か分からなくなります。

セキュリティが不安な場合、バイブコーディングはやめたほうがよいですか？

やめる必要はありません。請求金額のような金銭に直結する計算、社外の人が触れる画面での個人情報、止まるとその日の業務が止まるアプリは、設計の段階から経験のある人に入ってもらいます。それ以外の小さな業務は、備えを決めたうえで進められます。