バイブコーディングのリスクとは？APIキーの流出から本番運用まで

AIに指示するだけで、業務アプリが動く時代になりました。ただし、動くことと、安全に・効果的に使い続けられることは別の話です。この記事では、バイブコーディングで自社開発を始める前に押さえておきたいリスクを、4つの領域に分けて整理します。

バイブコーディングのリスクは、どこにあるのか

リスクは、コードそのものよりも、コードの周りにあります。主な領域は次の4つです。

画面の要望はAIに伝わりますが、要望に書かれていない守りは抜けやすくなります。使う環境ごとの具体的な設定は、「バイブコーディングに最適な環境とは？VercelとSupabaseで社内ツールを作る構成」で解説しています。

① 鍵の管理：APIキーは、どこから流出するのか

流出の経路は、主に3つです。

• GitHubへの公開：設定ファイル（.env など）や認証ファイルを、コードと一緒にリポジトリへ上げてしまう
• チャットへの貼り付け：AIや同僚とのチャットに、キーをそのまま貼って渡してしまう
• 画面側への埋め込み：ブラウザやスマートフォンで動くコードにキーを書き、誰でも読める状態にしてしまう

APIキーは、外部サービスを自社の名義で使う鍵です。OpenAIは、流出したキーで想定外の利用料が発生しうると注意し、キーを自社のサーバー経由で使うよう求めています。

GitHubには、コードに含まれるキーを検出する「シークレットスキャン」があり、公開リポジトリでは無料で過去の履歴まで調べます。ただし、検出できるのは決まった形式のキーだけです。チャットや画面側のコードに置いたキーは守れません。また、privateにしているからといって、シークレットキーをリポジトリに上げるのも危険です。 先日GitHubの内部リポジトリへの不正アクセスも報告されています。

https://www.itmedia.co.jp/news/article/2605/20/1260520085

対策は、キーを環境変数に置いてコードから切り離すこと、google cloud などでシークレットマネジャーを利用すること、人ごとに別のキーを発行することです。貼ってしまった、上げてしまったと気づいたら、消すだけでなく、すぐに再発行（ローテート）します。

② コードと設定：AIが書いたコードは、どこに穴が出やすいのか

穴が出やすいのは、「誰が、どのデータに触れてよいか」を決める部分です。Webアプリの代表的なリスクをまとめたOWASP Top 10（2025年版）では、1位がアクセス制御の不備、2位が設定の不備、3位が外部の部品を含むサプライチェーンの不備です。

これらは、画面を触るだけでは見つかりません。動作の確認とは別に、IPAの「安全なウェブサイトの作り方」などを基準に、権限と入力を確認する必要があります。依存パッケージは、GitHubのDependabotで既知の脆弱性を通知させられます。

③④ 本番運用とデータ：公開前に、何を決めておくのか

公開の前に、運用の担当とデータの扱いを決めておきます。作った人しか直せない状態で公開すると、止まったときに業務も止まります。

③ 本番運用で決めること

※ 確認項目の例です。

④ データと規約で確かめること

個人情報保護委員会は、生成AIに個人情報を入力する場合、利用目的の範囲内かを確認するよう注意を促しています。入力したデータが学習などに使われないかの確認も求めています。外部サービスの利用規約では、商用利用とデータの扱いの条件を確かめます。

まとめ

• バイブコーディングのリスクは、鍵の管理、コードと設定、本番運用、データと規約の4つの領域にあります。
• APIキーは、GitHubへの公開、チャットへの貼り付け、画面側への埋め込みの3つの経路で流出します。
• 課金アラートは利用を止めません。利用の上限と、流出時の再発行を前提にします。
• AIが書いたコードは、権限・入力・設定・外部の部品に穴が出やすく、画面の確認だけでは見つかりません。
• 公開前に、バックアップ・監視・障害対応の担当と、個人情報や利用規約の確認を済ませます。

作ること自体のハードルは下がりました。一方で、作った後に守るべき範囲は変わっていません。しかも、どれも一度決めれば終わりではなく、使い続ける間ずっと続きます。自社で作る場合は、この4つの領域を誰が担うかを先に決めてから始めてください。