バイブコーディングのリスク｜AIに作らせてよいもの・いけないものと、誰が確かめるかの決め方

要約

バイブコーディングで作ったものは、「壊れたときの被害の大きさ」と「中身を説明できる人がいるか」の2点で扱いを決めます。
ログイン・決済・個人情報・会計に関わるものは、専門家のレビューなしで本番に出しません。
作ったものは、本番に近いデータでのテストと、本番と開発の分離を条件にし、誰が確かめるかを先に決めます。

多くの会社で、社員が上司の許可なく ChatGPT（文章で質問や指示をすると答えを返すAIのサービス）や Claude に頼んで、業務のツールを自分で作り始めています。また、外注先から「AIで作れば安く早くできる」と提案されることも増えています。技術責任者のいない会社では、こうした場面で、止めるべきか任せてよいかを判断できる人がいません。

この記事では、AIに任せて作るツールやアプリについて、何を作らせてよく、何を作らせてはいけないか、作ったものを誰がどう確かめるのか、基準をまとめます。この基準は、私自身の経験から決めたものです。

バイブコーディングとは何か

バイブコーディング（vibe coding）とは、プログラムを自分で書かず、AIに言葉で指示してツールやアプリを作らせるやり方です。

この言葉は、AI研究者の Andrej Karpathy 氏が2025年2月2日に X へ投稿した文章で使ったものです。同氏は、雰囲気（vibes）に任せて進め、コードがあること自体を気にしなくなるやり方だと書き、AIが十分に良くなったことでそれが可能になったとしています。英国の辞書 Collins は、2025年11月6日に「vibe coding」を2025年の Word of the Year に選びました。

経営者が押さえておく点は1つです。社内の誰も中身を読んでいないプログラムが、業務の中で動き始めるということです。これまでは、プログラムを書いた人が中身を知っていました。バイブコーディングでは、作った本人も中身を説明できないことがあるのです。

AIで作ったものの責任は誰にあるか

責任は、作らせた会社にあります。AIの提供元は、どこも公式の説明で、バイブコーディングで作ったものを確かめる責任は利用者にあるとしています。

AIにプログラムを書かせるサービスには、GitHub Copilot、Claude Code、Cursor などがあります。言葉で指示するだけで、AIがアプリを作って公開まで進める Lovable や Replit というサービスもあります。各社の公式ページには、次のように書かれています。

GitHub Copilot: 提案を受け入れる前にレビューし確かめるのは、利用者の責任だとしています。一見正しく見えても正しくないコードを出すことがあり、構文として正しくても安全とは限らない、ということです。生成されたコードに伴うセキュリティの弱点、不具合、知的財産の侵害のリスクは利用者が負う、としています。
Claude Code: 提案されたコードと命令を、許可する前に安全か確かめるのは利用者の責任だとしています。保護の仕組みで危険は大きく減るものの、どの仕組みもすべての攻撃に耐えられるわけではない、と説明しています。
Cursor: AIエージェント（目的を与えると、AIが自分で手順を考え、ファイルの編集や命令の実行まで進める仕組み）は、作業フォルダのファイルを承認なしで編集でき、変更はすぐ保存されると説明しています。変更を元に戻せるよう、常にバージョン管理（プログラムの変更履歴を残し、前の状態に戻せるようにする仕組み）を使うよう勧めています。
Lovable: 公開時に自動で点検する仕組みを用意していますが、よくある問題を見つける助けであり、完全な安全は保証できないとしています。機密データや重要な機能を扱うアプリには、専門家のレビューを追加で受けるよう勧めています。

日本の「AI事業者ガイドライン」（総務省・経済産業省、第1.2版は令和8年3月31日公表）も、AIを使う事業者に、AIの出力結果を事業に使うかどうか、責任をもって判断することを求めています。AIに単独で判断させず、適切な時点で人が判断するよう求めています。

技術責任者がいないことは、確かめなくてよい理由になりません。何を作らせ、誰が確かめるかを、経営者が先に決めておく必要があります。

実際に起きた事故は何か

公的な記録や当事者の発表として残っている事故を紹介しましょう。

1つ目は、Lovable の例です。2025年4月15日までの Lovable で作ったサイトでは、ログインしていない外部の人でも、データベース（顧客情報や取引の記録を保存しておく仕組み）を読み書きできる状態になっていました。原因は、データの1行ごとに誰が読み書きできるかを決める設定（RLS）が不十分だったことです。この弱点は、システムの弱点を集めて公開している米国の公的なデータベース NVD に、CVE-2025-48757 という番号で登録されています。深刻度は「Critical」（9.3）です。

Lovable はこの登録に異議を唱えています。理由は「アプリのデータを守る責任は、各利用者にある」というものです。経営者が押さえるべきは、どちらが正しいかではありません。提供元が「守る責任は利用者にある」と考えている点です。

2つ目は、Replit の例です。2025年7月、Replit の AIエージェントが、開発中に本番のデータベースのデータを消しました。本番とは、顧客や社員が実際に使っているシステムのことです。Replit の CEO はこれを「決して起きてはならない」と書き、開発用と本番用のデータベースを分ける仕組みを導入しました。それまでは、開発と本番で1つのデータベースを使っていたからです。

2つの例に共通するのは、画面からは見えない設定の不備と、試す場所と本番が分かれていない作りです。どちらも、使う側から見れば「動いている」アプリでした。

何を基準に判断するか

基準は、壊れたときに被害がどれだけ大きいかと、中身を理解し、説明できる社員がいるかの2点です。被害が小さく、かつ説明できる社員がいるなら、積極的に使ってかまいません。どちらかが欠けるなら、試作（プロトタイプ）までにとどめましょう。

	説明できる人がいる	説明できる人がいない
壊れても被害が小さい	積極的に使ってよい	試作までにとどめる
壊れると被害が大きい	試作までにとどめる（本番は専門家のレビューを通してから）	試作までにとどめる

2点目は技術の話に見えますが、実際は組織の話です。CTO（技術の最高責任者）がいない会社で、システムを分かっている社員が1人だけで、その社員が退職したとたんシステムに誰も手を付けられなくなった例を、私は複数見てきました（実務ケース）。逆に、日本でアフィリエイトの仲介事業（広告を出したい会社とサイト運営者を仲介する事業）を立ち上げたときは、流行の独自技術ではなく、扱える人が多く資料も多い、使い古された技術をあえて選びました。担当者が替わってもシステムは動き続け、数年以上運用したあとで事業を売却できました。「新しいか」ではなく「ほかの人も触れるか」で選ぶ考え方は、AIで作るものにもそのまま当てはまるのです。

何を作らせてよいか

作らせてよいのは、誤りがあっても社外に出る前に人が気づけるものです。具体的には次のとおりです。

社内だけで使う小規模な業務ツール（集計、転記、形式の変換、定型レポートの作成など）
アイデアが実際に使えるかを確かめる試作品（プロトタイプ、PoC）や、デモ画面
一度だけ使うデータの整形や移行のためのスクリプト（決まった作業を自動で行う短いプログラム）
最後の確認を人が行う前提の自動化（n8n など。n8n は、複数のサービスをつないで業務の流れを自動化する道具です）
壊れても被害が限られ、すぐに気づいて直せるもの

この範囲では、AIに任せる効果は大きくなります。たとえば弊社では、マーケティング会社向けに、セールスとマーケティングの数字を集計するツールを5日で作り、作業を月10時間以上減らしました。集計のように結果を人が見る業務は、誤りに気づきやすい分野です。

何を作らせてはいけないか

次のものを、確認せずに公開するのは危険です。少なくとも専門家にチェックしてもらいましょう。

ログイン、権限の管理、決済など、安全の土台にあたる部分（ログイン・権限管理は、誰が使っているかを確かめ、人によって見てよい情報やできる操作を分ける仕組みです）
顧客や従業員の個人情報を扱う、本番で使うシステム（日本の個人情報保護法や、フィリピンで個人情報を守る法律 Data Privacy Act の対象です）
会計、給与、税務など、誤りがお金や法律上の責任に直結するもの
社外に公開するサービスのうち、公開後に直す人や体制がないもの
中身を説明できる社員がいないまま、基幹業務に組み込むもの

AIのバイブコーディングでツールが簡単に作れても、すぐに本番の環境で稼働させるのは避けましょう。私自身、オンライン英会話のログイン管理ツールの案件では、試作は早くできたものの、本番に出す前にセキュリティと権限の設計を作り直す必要がありました。

この種の不備は、画面からは見えません。Supabase（AIで作るアプリでもよく使われる、データベースやログインの仕組みを貸すサービス）の公式ドキュメントは、外から使える表のすべてで RLS を有効にするよう説明しています。RLS のない表は、情報の書き換えと漏えいのリスクがあります。前の章の Lovable の例も、この設定の不備によるものでした。

AIの出力をそのまま使わない、という原則は、AIを組み込んだアプリにも当てはまります。情報セキュリティの国際的な団体 OWASP は、LLM（ChatGPT などの土台になっている、大量の文章から学んだAI）を使うアプリの主な危険の一覧（2025年版）に「LLM05:2025 Improper Output Handling」を挙げています。AIの出力を確かめずにシステムのほかの部分へ渡すと、SQLインジェクション（データベースへの命令に不正な命令を紛れ込ませ、データを盗んだり壊したりする手口）などが起きうる、としています。

作ったものを誰がどう確かめるか

確かめるのは、作った本人、技術の分かる人、経営者の3者で分担しましょう。作った本人だけに任せないことが重要です。

作った本人（社員・外注先）が必ず行うこと

本番に近いデータでテストする（テストは、作ったものが正しく動くかを、データを入れて試すことです）
型チェック・静的解析を通す（プログラムを動かす前に、書き方の誤りや危ない書き方を機械で見つける点検です）
出てきた数値と固有名詞は、AIの答えをそのまま使わず、元の資料と突き合わせる
バージョン管理を使い、前の状態に戻せるようにしておく

本番に近いデータで試す理由は、画面上の動作と結果の出力が異なる場合があるからです。私自身、AIが書いたコードを本番に反映する直前で止めたことがあります。例外的な処理にミスがあり、実際のデータで試すと想定外のエラーが出ました。反映の前にデータで試すという決まりがあったので、本番に出る前に気づけました。経緯は実務ケース「AIが書いたコードを、そのまま本番に出しかけた話」に、日ごろの確かめ方は「AIの答えを、そのまま信じないためにやっていること」にまとめています。

技術の分かる人が確かめること

社内にいなければ、外部の専門家に頼みましょう。「作らせてはいけないもの」は、ここを確認するまで本番では稼働させません。

本番と、開発・テストの場所が分かれているか
データベースの読み書きの範囲が設定されているか（RLS など）
秘密の鍵が外に出ていないか（秘密の鍵は、システムを操作する権限を持つ文字列で、外に漏れると誰でもその権限で操作できます）
バックアップから実際に戻せるか

秘密の鍵について、Supabase は、管理用の秘密の鍵（secret key）は RLS を通らずに読み書きできるため、ブラウザで使ったり顧客に見せたりしてはいけない、と説明しています。最後の項目は、バックアップが取れていることと、そこから戻せることが別だからです。私が経験したいちばん大きな障害はディスクの故障で、バックアップから戻せるかを確かめていなかったため、復旧に丸一日以上かかりました。それ以来、バックアップから本当に復元できるかを、決まった間隔で試すようにしています。

経営者が確かめること

経営者は、コードの中身を読む必要はありません。私は技術が分からない経営者に説明するとき、技術用語を使わず「コスト」「リスク」「時間」という3つの言葉に言い換えています。AIで作ったものも、この3つの言葉で次のように問えば判断できます。

壊れたら、何が、誰に、どれだけ起きるか
作った人以外に、中身を説明できる人は誰か
本番に出す前に、誰が、どのデータで試したか
作った人が休んだり辞めたりしたとき、誰が直し、その費用はどこから出るか

答えが明確でないツールは、本番で使わないようにしましょう。

外注先から「AIで作れば安く早い」と言われたらどうするか

提案そのものは否定しなくてかまいません。どの工程が安く早くなるのか確かめましょう。

見積もりが極端に安いときは、たいていテストや運用保守の工数が抜けています。私は見積もりを見るとき、設計、実装、テスト、保守のそれぞれにどれだけ工数を割いているか、その配分を必ず見ます。見積もりに、誰がどのデータで試すか、公開後に誰が直すかが書かれているかを確かめてください。

20年ほど前、知人の起業家が安い制作費で作ったビジネスマッチングサイトを確認したところ、セキュリティの穴が多数見つかりました。結局、余分な修正費用がかかったのです。安さの理由が工程の省略なら、同じことが起きます。

進め方も確かめましょう。私の経験でうまくいったのは、週に一度の進捗会議で、毎回実際のシステムを動かして確認した案件でした。しかし、仕様書だけ渡して任せた案件では、納品の直前になって、思い描いていたものとはまったく違うものが届きました。AIで作られた試作も、定期的に実際のシステムで確認しましょう。

社内でどう扱うか

社員が自分で作ったツールは、禁止するより、社内の仕組みに取り入れましょう。会社が把握していない個人のツールは、他の人が使えないリスクがあります。職場に Excel が広まり始めた頃、使いこなせる社員が関数やマクロを駆使して自分だけが使う見積書を作り込み、本人が休暇や異動でいなくなると、その便利なツールが使えなくなる場面を見てきました。見積書の書式も部署ごとに違ってしまい、会社全体で数字を比べることができませんでした。個人が自作したAIツールも、作った社員が休めば、その業務が止まってしまいます。

そこで、次の3つを社内の決まりにしましょう。

AIで作ったツールは、作った人・用途・扱うデータ・中身を説明できる人を、一覧にして見えるようにする
「作らせてよいもの」は、一覧に載せれば使ってよい。「作らせてはいけないもの」は、専門家が確認するまで稼働させない
便利なAIツールは、誰もが使える社内のアプリや仕組みとする

あわせて、機密情報や顧客情報をAIのチャットに入れないことも決まりに加えましょう。顧客情報をAIのチャットに入れてしまう、データベースのデータを壊す、といったトラブルは、技術責任者のいない会社で実際に見てきました。ルール全体の作り方は、生成AI（文章や画像、プログラムを作り出すAI）の社内ルールについて解説した「生成AIの社内ルールの作り方｜何を決め、誰が確かめ、誰が責任を持つか」で扱っています。

よくある質問

Q: 社員が自分の判断でAIを使ってツールを作り始めています。禁止すべきですか。

禁止する必要はありません。作らせてよい範囲（社内向けの小さな集計や転記のツールなど）を示し、作ったものを一覧に載せてもらいます。なお、社内のすべての業務を一度にAI化しようとして失敗する例はよくあります。まず1つの業務に絞って試し、効果を確かめてから広げましょう（実務ケース「AI導入が「目的化」して失敗した例、うまくいった例」）。

Q: Lovable のように公開時の自動点検があるサービスなら、安全と考えてよいですか。

安全とは言えません。Lovable 自身が、点検はよくある問題を見つける助けであり、完全な安全は保証できないとしています。機密データや重要な機能を扱うアプリには専門家のレビューを勧めており、安全の水準を確かめる責任は利用者にある、としています。

Q: 技術が分からない経営者は、最低限何を確かめればよいですか。

壊れたときの被害がどれだけ大きいかと、作った人以外に説明できる人がいるかの2点です。どちらかに答えられなければ、本番では使わず試作にとどめます。あわせて、本番に近いデータで試したかを、作った人に確認してください。

まとめ

バイブコーディングで作ったものは、作らせた会社に責任があります。確かめる責任も、利用者にあります。
どう扱うかは、「壊れたときの被害の大きさ」と「中身を説明できる人がいるか」で決めましょう。どちらかが欠けるなら、試作までにとどめます。
ログイン・権限管理・決済、個人情報、会計・給与・税務に関わるものは、専門家のレビューなしで本稼働させないようにします。
作ったものは、本番に近いデータでのテスト、本番と開発の分離、バージョン管理、バックアップからの復元の確認を条件にします。
個人が自作したツールは一覧で見えるようにし、社内の仕組みとして扱います。

無料相談のご案内

PH Tech AI は、社内に技術責任者がいない中小企業・スタートアップの、技術の判断と開発体制づくりを支援しています。社員や外注先がAIで作ったツールを本番で使ってよいか、どこまで任せてよいか、誰が確かめるのかを、一緒に整理します。無料でご相談いただけます。まずはお気軽にお問い合わせください。

参考・出典

Andrej Karpathy, X の投稿（2025年2月2日）: https://x.com/karpathy/status/1886192184808149383
Collins Dictionary 公式ブログ（Word of the Year 2025 の発表）: https://blog.collinsdictionary.com/language-lovers/collins-word-of-the-year-2025-ai-meets-authenticity-as-society-shifts/
GitHub Docs（GitHub Copilot のコード補完の責任ある利用について）: https://docs.github.com/en/copilot/responsible-use/copilot-code-completion
Claude Code Docs「Security」: https://code.claude.com/docs/en/security
Cursor Docs「Agent Security」: https://cursor.com/docs/agent/security
NIST National Vulnerability Database「CVE-2025-48757」: https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2025-48757
Amjad Masad, X の投稿（2025年7月20日）: https://x.com/amasad/status/1946986468586721478
Replit 公式ブログ（2025年7月21日。開発用と本番用のデータベースの分離）: https://replit.com/blog/introducing-a-safer-way-to-vibe-code-with-replit-databases
Replit 公式ドキュメント（開発用と本番用のデータベース）: https://docs.replit.com/features/data-and-storage/development-and-production
Supabase 公式ドキュメント（行レベルセキュリティ）: https://supabase.com/docs/guides/database/postgres/row-level-security
Lovable Docs「Security overview」: https://docs.lovable.dev/features/security
総務省「AI事業者ガイドライン」掲載ページ: https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html
総務省・経済産業省「AI事業者ガイドライン（第1.2版）」: https://www.soumu.go.jp/main_content/001064279.pdf
OWASP Gen AI Security Project「LLM05:2025 Improper Output Handling」: https://genai.owasp.org/llmrisk/llm052025-improper-output-handling/