「在庫管理を自動化したい」とChatGPTやClaudeに伝えたら、あっという間に動くコードが出てきた——そんな経験をした方も増えているのではないでしょうか。便利な時代になったものです。
こうした、会話的な指示だけでAIにコードを書かせて開発を進める手法を「バイブコーディング（vibe coding）」と呼びます。専任のプログラマーがいなくても、思いついたその日にツールが動く。これ自体はとても良いことだと私は感じています。
ただし、「動いた」ことと「安全に動かし続けられる」ことは、実は別の話です。この記事では、バイブコーディングで実際に何が危ないのか（特にライブラリ経由の情報漏洩）、AIへの「安全プロンプト」文例、そして今日からできる基本対策をお伝えします。読み終える頃には、動くコードの裏に潜むリスクを人に説明できるようになり、AIが提案したpip installを実行する前に何を確認すればよいか、判断できるようになっているはずです。
バイブコーディングとは——非エンジニアにも広がる「会話で作る」開発
バイブコーディングとは、「こんな感じで動いてほしい」という会話的な指示だけで、AIにコードを書かせて開発を進める手法のことです。細かい文法やコマンドを知らなくても、やりたいことを日本語で伝えるだけでプログラムが完成します。
たとえば「請求書をお客様ごとに自動で振り分けるツールが欲しい」とAIに話しかけるだけで、実際に動くコードが数分で出てくる。私自身、こうした場面に立ち会うことが増えました。専任のプログラマーがいない会社でも、経営者や総務担当者が自分専用のツールを持てる時代です。これは素直に評価してよい変化だと思います。
一方で、AIが出したコードは「動く」ことを確認しただけで、それ以上のチェックをせずに使い続けているケースも目立ちます。動くことと、安全に動かし続けられることは、実は別の軸で考える必要があります。ここから、その理由を具体的に見ていきましょう。
危険その1——ライブラリが勝手に外部と通信するリスク
バイブコーディングで生成されるコードの多くは、「外部ライブラリ」に依存しています。外部ライブラリとは、誰かが作った便利な部品を、pip installのようなコマンドで自分のPCに取り込んで使う仕組みのことです。ゼロから全部を書かなくても、既存の部品を組み合わせれば早く動くコードができる——これがAIがコードを速く生成できる理由のひとつでもあります。
問題は、この「部品」自体が安全とは限らない点です。ここでいくつか、非エンジニアの方にも知っておいてほしい仕組みをご紹介します。
テレメトリ送信とは、ソフトウェアが利用状況などのデータを自動的に開発元へ送る仕組みのことです。一部のライブラリはこうした機能を標準で持っている場合があり、必ずしも悪意があるわけではありませんが、知らないうちに情報が外部に送られている可能性がある、という点はまず押さえておく必要があります。
より深刻なのがタイポスクワッティング（typosquatting）です。これは、正規のライブラリ名にわざと似せた偽物を登録しておき、利用者の打ち間違いやAIの誤生成によってインストールさせる手口を指します。この手口は古くから現在まで繰り返し発生しており、決して過去だけの話ではありません。実際に確認された事例をいくつかご紹介します。
- 2019年に発見された事例では、正規のライブラリ
jellyfishに酷似したjeilyfishという偽パッケージが、SSHキーやGPGキー（本人確認や暗号化に使う重要な鍵データ）を盗み出す機能を持っていたことが報告されています。同時に見つかったpython3-dateutilという偽パッケージは、このjeilyfishを内部で読み込む（依存する）ことで悪意のあるコードを実行する仕組みでした（出典：Sysdig「悪意のあるPythonライブラリjeilyfishおよびpython3-dateutilからの保護」） - 2025年5月には、正規のcoloramaや、別のエコシステム（NPM）の類似パッケージ名に似せた偽パッケージが、Windows Defenderの検知定義を削除し、遠隔操作を可能にするアクセスを確立していたことが報告されています（出典：Checkmarx Zero「PyPI Supply Chain Attack: Colorama and Colorizr Name Confusion」）
こうした偽パッケージは特別なものではなく、Check Pointは2024年3月、500件を超える偽パッケージが短期間に集中して投稿された攻撃を報告しています（出典：Check Point Blog「PyPI Inundated by Malicious Typosquatting Campaign」）。
さらに厄介なのが、依存パッケージ経由の侵入です。依存パッケージとは、自分が直接指定したライブラリが、さらに内部で使っている別の部品のことを指します。自分では名前すら見たことのない「孫請けの部品」に悪意あるコードが紛れ込むケースもあり、利用者側からは気づきにくいのが実情です。
ここで一番お伝えしたいのは、AIが提案するpip installのコマンドを、無検証で実行することの危険性です。AIは「これを入れれば動きますよ」と自然にインストールコマンドを提案してきますが、AI自身はそのライブラリが安全かどうかを保証してくれるわけではありません。動作させるために最短の道を示しているだけ、と考えたほうが実態に近いでしょう。
とはいえ、すべてのライブラリが危険というわけでは決してありません。世の中で使われているライブラリの大半は安全に運用されています。だからこそ大切なのは、「どれが定番で信頼できる部品か」を確認する習慣を持つことです。次の章で、その具体的な方法をお伝えします。
AIへの「安全プロンプト」文例集——コピペでそのまま使えます
ここからが本記事の目玉です。AIにコードを書いてもらう際、指示文に一言添えるだけでリスクの多くを事前に可視化できます。以下の文例を、そのままコピペしてAIへの指示に使ってみてください。それぞれ、なぜ効くのかも一言添えました。
1. 外部通信の有無を確認させる
外部と通信するライブラリやAPIを使う場合は、その旨を必ず教えてください。→ AIに「隠れた通信」を自己申告させることで、気づかないまま外部にデータを送るコードを防ぎます。
2. 標準ライブラリを優先させる
可能な限り、追加インストールが不要な標準ライブラリだけで書いてください。→ 標準ライブラリ（プログラミング言語に最初から付属している部品）だけで済めば、そもそも怪しい外部部品を入れるリスク自体がなくなります。
3. 定番の部品だけを提案させる
外部ライブラリを使う場合は、パッケージ名・提供元・ダウンロード数の目安が分かる、広く使われている定番のものだけを提案してください。→ 名前が似た偽パッケージではなく、実績のある部品を優先させる指示です。
4. 機密情報の扱いを明示させる
APIキーやパスワードなどの機密情報は、コードに直接書かず、環境変数や設定ファイルから読み込む形にしてください。→ うっかりコードに書き込んだ機密情報が、そのまま外部に流出する事態を防ぎます。
5. 通信先を洗い出させる
このコードが送信・保存・アップロードする外部通信先をすべてリストアップしてください。→ コードを実行する前に、どこに何が送られるのかを一覧化させます。
6. 実行前に説明させる
実行する前に、このコードが何をするかを箇条書きで説明してください。→ 「動くから良し」で終わらせず、内容を理解してから実行する習慣づけになります。
毎回6つ全部を打ち込むのは面倒だと思いますので、最初の指示文の末尾にそのまま貼り付けられる「コピペ用プロンプトセット」もご用意しました。
【安全確認のお願い】
・外部と通信するライブラリやAPIを使う場合は、その旨を必ず教えてください。
・可能な限り、追加インストールが不要な標準ライブラリだけで書いてください。
・外部ライブラリを使う場合は、パッケージ名・提供元・ダウンロード数の目安が分かる、
広く使われている定番のものだけを提案してください。
・APIキーやパスワードなどの機密情報は、コードに直接書かず、
環境変数や設定ファイルから読み込む形にしてください。
・このコードが送信・保存・アップロードする外部通信先をすべてリストアップしてください。
・実行する前に、このコードが何をするかを箇条書きで説明してください。一つ、正直にお伝えしておきたいことがあります。このプロンプトを入れたからといって、リスクがなくなるわけではありません。AIも間違えることがありますし、聞かれたことに気づかず答えてしまう場合もあります。あくまで「見落としを減らす」ためのものと捉え、次にお伝えする「確認する習慣」とセットで使ってください。
pip installする前の確認ポイント——実行前チェックリスト
安全プロンプトを使っても、最終的にインストール・実行するかどうかを決めるのは人間です。AIが「これを入れてください」と言ってきたときに、実行前に確認したいポイントをチェックリストにしました。
- パッケージ名のスペルを、公式サイト（pypi.org）や公式ドキュメントで再確認したか（タイポスクワッティング対策）
- そのライブラリが広く使われている定番のものか（月間ダウンロード数やGitHubのスター数などの目安を一目見る）
- 見慣れない・聞いたことのない名前のライブラリが含まれていないか
- AIに「このライブラリは何をするものか」を説明してもらってから実行しているか
- 仮想環境（venv）の中で試しているか（次の章で説明します）
「全部を毎回チェックするのは非現実的」と感じた方もいると思います。正直、毎回すべてを完璧に確認するのは大変です。現実的な落としどころとして、せめて「聞いたことのない名前のライブラリが出てきたときだけは、一度立ち止まって確認する」というルールだけでも、リスクの大部分は防げます。
その他、今日からできる基本対策
ライブラリ以外にも、押さえておきたい基本の防御線があります。難しいものではないので、今日から順に取り入れてみてください。
機密情報をコードに直接書かない
APIキーやパスワード、顧客データをコードの中に直接書き込む（ハードコードする）のは避けましょう。代わりに、環境変数や.envという設定ファイルに切り分けて、コードからはそれを読み込む形にするのが基本の考え方です。こうしておけば、コードそのものを誰かに見せたり共有したりしても、機密情報だけは漏れずに済みます。
仮想環境（venv）を使う
仮想環境とは、PC本体の環境を汚さずに済む「実験用の隔離された部屋」を作る仕組みです。バイブコーディングで試したライブラリが万一トラブルを起こしても、影響をその部屋の中だけに閉じ込められます。作成は次のコマンドひとつで十分です。
python -m venv myenvコードレビューの習慣を持つ
一人で完結させず、別のAIに「このコードに危険な点はないかレビューしてください」と聞き直す、あるいは信頼できる人に見てもらう。この「ダブルチェック」の発想を持つだけで、見落としはかなり減らせます。
実行前に必ず内容を確認する
「動くかどうか」だけでなく「何をするコードか」を理解してから実行する、という基本姿勢に立ち返ることが、最後にして最大の防御線です。
なお、AIに指示を出す際に顧客情報などの機密情報をどこまで書き込んでよいか、という「入力側」の注意点については、姉妹記事生成AIの社内ルールの作り方で詳しく解説しています。あわせてご覧いただくと、AI活用の入口から出口まで一通りの防御線が見えてきます。
まとめ
この記事の要点を振り返ります。
- バイブコーディングは非エンジニアにも開発の扉を開く便利な手法である
- 危険の多くは「AIそのもの」より「AIが呼び出す外部ライブラリ」に潜んでいる
- 安全プロンプトをAIへの指示に添えるだけで、リスクの多くは事前に可視化できる
pip install前の一呼吸と、機密情報を書かない・仮想環境を使う習慣が最後の防波堤になる
次にAIにコードを書いてもらうときは、まずこの記事の「コピペ用プロンプトセット」を指示文の最後に貼り付けてみてください。それだけで、見えていなかったリスクの多くが可視化されるはずです。
「バイブコーディングを社内で安全に使いこなしたい」「AIに何をどこまで任せていいか判断に迷う」という方には、TechnoBridgeの無料相談やセミナーもご用意しています。神奈川・東京・山梨を中心に、商工会議所での勉強会や個別のご相談に対応していますので、お気軽にお声がけください。
また、「そもそも機密データを外部のAIサービスに渡したくない」という場合は、社内で完結するAI環境という選択肢もあります。詳しくはローカルLLM入門をご覧ください。日頃のセキュリティ対策の基本を見直したい方は、中小企業のセキュリティ対策5選もあわせてどうぞ。
コメント