はじめに
こんにちは。GMO Flatt Security株式会社 セキュリティエンジニア(兼Claude Codeオタク)の石川（@ryusei_ishika）です。
Claude CodeやCursorなどのAIエージェントを活用したバイブコーディングが急速に広まっています。私自身、社内ではClaude Codeのリリース（ほぼ毎日）のたびにそのリリースノートの重要なポイントを解説しているほか、Biz職向けに「バイブコーディング講座」を実施するなど、社内でのAI活用の普及にも取り組んでいます*1。
昨今、AIエージェントを日常的に使い込むなかで、従来の開発では起きにくかったセキュリティリスクが顕在化しつつあると感じています。例えば、先日AIエージェント経由で.envの認証情報が漏洩し、外部サービスのアカウントが乗っ取られた事例もSNS上で報告され、大きな反響を呼びました。
この記事では、AIエージェントを用いた開発時のセキュリティリスクを7つ取り上げ、具体的な攻撃シナリオと対策を紹介しながら、開発現場で今日から実践できる内容にまとめました。バイブコーディングを始めた方はもちろん、普段からAIエージェントを使って開発している方にも参考になれば幸いです。
- はじめに
- なぜバイブコーディングでセキュリティリスクが高まるのか
- よくない操作 — 開発時における任意コード実行のリスク
- よくない持ち出し — 開発時における情報漏洩のリスク
- よくない出荷 — 開発段階で防げるリリース後のリスク
- 終わりに
なぜバイブコーディングでセキュリティリスクが高まるのか
具体的なリスクを紹介する前に、なぜAIエージェントを使った開発でセキュリティリスクが高まるのか、その背景を整理しておきます。
バイブコーディングで利用されるAIエージェントは、シェルの実行やファイルの編集、外部サービスとの通信など、開発環境に対する幅広い操作権限を持っています。こうした環境で起こりうる脅威は、大きく3つに分類できます。
- よくない操作 — 意図しないコマンド実行やファイル破壊などの内部操作
- よくない持ち出し — 認証情報や機密データの外部への漏洩
- よくない出荷 — 脆弱性を含んだコードのリリース
この3つの分類自体は、人間が開発する場合と変わりません。違いはその「起こりやすさ」にあります。
LLMは「やってはいけないこと」を暗黙に理解する能力を持たず、ミスへの恐れやキャリアへの影響といった人間が持つ抑止力もありません。それにも関わらず、開発者はAIエージェントを複数同時に動かします*2。バイブコーディングの開発環境は、いわば「悪気もないが責任能力もない内部脅威が大量発生している状態」と言えます。
この記事では「よくない操作」を任意コード実行（リスク1〜5）、「よくない持ち出し」を情報漏洩（リスク6〜7）として紹介し、最後に「よくない出荷」としてリリース後のリスクにも触れていきます。
よくない操作 — 開発時における任意コード実行のリスク
任意コード実行に対する共通の軽減策
任意コード実行とは、コンピュータ上で意図しない様々な操作がされてしまう(マルウェア実行・認証情報の漏洩など)ような攻撃手法です。このリスクは一番発生しやすく、かつ発生した時の影響度も一番高いリスクです。この後様々なパターンをご紹介しますが、どのパターンにも共通する対策・リスク軽減手法があります。この記事を読んで「バイブコーディングのセキュリティリスクってちょっと怖いな...」と感じたら、これだけは優先して実施 してもらえたらと思います。
任意コード実行のリスクに対しては、サンドボックス環境の利用が最も効果的な軽減策の一つです。Claude Sandboxやe2b.dev、Docker Sandboxesなどを活用すれば、危険なコードが実行されてもホストマシンへの影響を限定できます。
ただし、いずれの手法も開発するプロダクトの一部の機能が使用できなくなる場合があります。また、場合によってはソースコードの改ざんや漏洩などを防ぐのは難しいこと、コンテナエスケープ等の脆弱性によるバイパスの可能性がある点にも注意が必要です。さらに、Claude Codeのサンドボックス(/sandbox機能)では、allowUnsandboxedCommandsをfalseに設定しないと、ユーザーが承認した場合に一部コマンドがサンドボックス外で実行されてしまう点にも気をつけてください。
リスク1. 悪意あるAgent Skillの実行
Claude Codeのplugin marketplaceやCursorのmarketplace、VercelのThe Agent Skills Directoryなど、コミュニティが作成したスキルを簡単にインポートできる仕組みが広まっています。これらの機能は便利な一方で、その性質上、他人が作成したプロンプトを自分のPC上で実行しているのと同義です。
スキルは実行時にLLMのコンテキストへ動的に注入されるプロンプトであり、LLMはその内容をある程度信頼された指示として扱います。よって悪意ある内容が含まれている場合にプロンプトインジェクション攻撃として機能し、意図しないコマンドが実行されるおそれがあります。実際、近年公開された論文でも主要マーケットプレイスから悪意のあるスキルが多数公開されていたことが報告されています。
さらに、多くのスキルマーケットは署名検証やマルウェアスキャンといった仕組みが十分に整備されていません*3。そのため、スキルの導入時にはその内容の"注意力"が求められます。
対策としては、サンドボックスの導入のほかに、中身を自分で理解・評価できないスキルは使わないことが基本です。Anthropic自身も公式ドキュメントで警告している通り、公式マーケットや自作のスキルのみを利用し、やむを得ず外部のスキルを利用する場合はプロンプトの内容を十分に丁寧に注意深く確認してください。
リスク2. 悪意のある設定ファイルが含まれるOSSレポジトリ
OSSリポジトリには、.claude/commands/や.cursor/rules/、CLAUDE.mdといったAIエージェント向けの設定ファイルが含まれていることがあります。git cloneした直後にAIエージェントを起動すると、これらの設定ファイルが自動的に読み込まれ、悪意ある指示が実行される恐れがあります。
このリスクが特に顕在化しやすいのは、次のようなケースです。
1. 全権限スキップモード（Claude Codeの--dangerously-skip-permissions相当）: すべての権限確認をスキップするこのオプションを有効にした状態でクローン直後のリポジトリを開くと、悪意ある指示が一切確認なくコンテキストに取り込まれます。
2. 自動承認モード（--permission-mode auto相当）: 自動承認モードでも、ユーザーの目を通さずにコマンドが実行されます。--dangerously-skip-permissions ほど無制限ではないものの、設定ファイルを通じた悪意ある指示が通り抜けるリスクがあります。
3. ツール許可設定（permissions.allow相当）: allowリストは「指定したツール/コマンドをプロンプトなしで許可する」設定で、denyやaskと組み合わせて使います。粒度が粗い許可（例: Bash(*)）を設定していると、悪意ある指示経由で任意コマンドが確認なしに実行されてしまいます。また、適切に絞り込んでいても万全ではありません。弊社の記事であるPwning Claude Code in 8 Different Waysでは、Claude Codeのデフォルト許可リストに含まれるsedやsort等の一見無害なコマンドであっても、引数の組み合わせ次第で任意コマンド実行が可能であることが示されています。
対策としては、サンドボックスの導入のほかに、リポジトリ内の設定ファイル（.claude/、.cursorrules、CLAUDE.md等）の内容をAIエージェントの起動前に確認しておくことが効果的です。
リスク3. サードパーティMCPサーバ
MCP（Model Context Protocol）サーバは、AIエージェントに外部ツールやデータソースへのアクセスを提供する仕組みです。サードパーティのMCPサーバを利用する場合、提供元自体に悪意があるケースと、実装に脆弱性があり攻撃者に悪用されるケース(プロンプトインジェクション経由での任意コード実行など)の両方のリスクがあります。
また、MCPサーバはAIエージェントのサンドボックスとは別プロセスとして起動されることが多いため、サンドボックスの保護が適用されないケースがあります。例えば、エージェント自体はサンドボックス内にありますが、MCPサーバはサンドボックス外で起動されており、両者がHTTPで通信しているケースなどがこれにあたります。
対策として、MCPサーバ自体をサンドボックス環境で実行するほかに、MCPサーバの導入時は信頼できる提供元のものに限定して使用してください。その他、MCPサーバの詳細なセキュリティについては、弊社ブログの「MCPにおけるセキュリティ考慮事項と実装における観点（前編）」「MCPにおけるセキュリティ考慮事項と実装における観点（後編）」でも解説しています。
リスク4. AIが生成した危険な操作へのユーザーの承認
AIエージェントが生成・実行するコードには、意図しない危険な操作が含まれている場合があります。例えば、このようなパターンがあります。
- 指示した意図に反して、ホームディレクトリの設定ファイルを書き換えたり、プロジェクト外のファイルを削除したりする
- 「SQLインジェクションができないか検証して」と依頼した際に、LLMが
OR 1=1のような副作用のないペイロードではなく、DROP TABLEを含む破壊的ペイロードを生成する - 「TerraformでXXのリソースを追加して」と依頼した際に、「一旦全てのリソースを削除してから当該リソースを追加したほうがスムーズです」などと言いながら本番環境の全てのリソースを削除する
対策としては、サンドボックスの導入のほかに、「AIエージェントに本番環境を変更させるような権限を与えない(ステージング環境で実施する)」、「実行するコマンドが何をするコマンドなのかを確認する」などが重要です。特に後者はLLMを使って確認するという方法もあり、例えばClaude CodeのBash Toolは実行するコマンドの下に、それが何をするコマンドなのかを表示してくれます。
リスク5. ソフトウェアサプライチェーン攻撃
AIエージェントがnpm installやpip installなどを実行する際、悪意あるパッケージが紛れ込むリスクがあります。npmの場合はライフサイクルスクリプト等(例: preinstall)を起点として、自身のPC上で任意のコードが実行されてしまう恐れがあります。
このリスクで特に警戒すべきは、普段から利用している正規パッケージが攻撃者に侵害され、マルウェアを含むバージョンが配布されるケースです。例えば、2025年にはメンテナアカウントの乗っ取りを起点として、axiosやlitellmをはじめ、数多くの広く使われるパッケージが侵害される事例が相次ぎました。こうした攻撃は利用者側に落ち度がなくてもインストール時に成立してしまう点で極めて影響範囲が広く、AIエージェントは人間の目を経ずにnpm install等を実行してしまうため、被害に気付くまでの時間も短くなりがちです。
さらに、AIエージェント固有のリスクとしてSlopsquattingも存在します。LLMは検証をせずに存在しないパッケージ名を生成してしまう場合があり、これを見越してLLMが生成しそうな架空のパッケージ名を先回りしてレジストリに登録しておく手法です。例えば、LLMが(正)@anthropic-ai/claude-codeを(誤)@anthropic/claude-codeのように間違えるだろうと見越して、後者にマルウェアを仕込んでおくといった攻撃が考えられます。
対策としては、開発環境やCI/CD環境をサンドボックス環境で実行することに加え、弊社が提供するTakumi Guardを利用すれば、ブロックリストに登録された危険な依存関係はインストール前にブロックされます。先述のaxiosやlitellmなど、侵害された既知のバージョンもブロックリストに含まれており、正規パッケージの侵害・Slopsquattingのいずれも未然に防ぐことができます。
よくない持ち出し — 開発時における情報漏洩のリスク
リスク6. 意図しない外部ドメインへの通信
AIエージェントにAPIのサンプルコードを生成させると、リクエスト先のURLにyour-domain[.]com等のプレースホルダのようなドメインが使用されることがあります。例えば、Claude Codeに「fetchリクエストのサンプルコードを書いて」と指示したとき、以下のようなコマンドが出力されることがあります(.を[.]に変更しています)。
curl -X GET "https://your-domain[.]com/path/to?id=123" \ -H "Authorization: Bearer YOUR_ACCESS_TOKEN"
一見すると無害なプレースホルダに見えますが、your-domain[.]comは実在する第三者のドメインです(※このサイトは開かないでください*4 )。
このコードをそのまま実行したり、ターミナルに表示されたリンクをクリックしてしまうと、リクエストボディやヘッダに含まれる認証情報や機密情報（リリース前の機能のパスなども含む）が外部に送信される可能性があります。evil[.]comやattacker[.]comなども同様に実在する第三者のドメインです。
/etc/hostsにこれらのドメインをブロックリストとして追加すれば、意図しない外部通信を防ぐことができます([.]を.に変更してから保存してください)。
# blocklist 127.0.0.1 your-domain[.]com 127.0.0.1 www.your-domain[.]com 127.0.0.1 evil[.]com 127.0.0.1 attacker[.]com
チームや組織単位では、DNSレベルでのブロックも検討してください。また、AIエージェントにサンプルコードを生成させる際は、プレースホルダとしてRFC 2606で予約されている名前解決されないTLD(.example/.test/.invalidなど)を使うようCLAUDE.md等で指示しておくのも有効です*5。
リスク7. 機密情報の漏洩
AIエージェントは動作確認やデバッグの過程で、.envファイルや実行時のエラーメッセージに含まれる認証情報を読み取ることがあります。Claude Codeではsettings.jsonのdenyリストで.env等の読み取りを禁止できますが、これはファイル読み取りツールの制限にすぎません。つまり、スクリプト内でのファイル読み取りや、実行時のエラーメッセージに認証情報が含まれるケースまでは防ぐことができません。読み取られた認証情報は、エージェントの行動を通じて外部に送信されるリスクもあります。例えば、以下のケースでは、エラーメッセージに含まれるAPIキーがそのままWeb検索に送信されてしまいます。
$ node server.js Error: Authentication failed - Invalid API key (sk-proj-4f8a...7e2d)
↓ エージェントがエラーを解決しようとWeb検索を実行
WebSearch("Authentication failed Invalid API key sk-proj-4f8a7e2d")
対策・軽減策は「LLMのコンテキストに機密情報を入れない」方向と「漏洩時の被害を限定する」方向の2軸で考えます。
1. LLMのコンテキストに機密情報を入れない
方針としては、エージェントの実行環境に平文の機密情報を一切置かないことです。万が一侵害されても、攻撃者が手にするのは参照URIやダミートークンだけにしておきます。
例えば、1Password等のシークレットマネージャーでは、.envにはop://prod/db/passwordのような参照URIを記述しておき、実行時に正規の認証情報へ置換する方法があります。また、.envファイル自体を暗号化するような手法もあります。
API通信についても同様に、エージェントにはダミーのトークンだけを渡し、ローカルプロキシが本物のキーに差し替えてAPIへ転送する構成が有効です。
2. 漏洩時の被害を限定する
AIエージェントには必要最小限の権限のみを持つアカウントのトークンを付与し、有効期限も短く設定しておけば、万が一漏洩しても被害を抑えられます。例えば、AWSであればS3の特定バケットへの読み取りのみを許可した一時的な認証情報を発行してエージェントに渡すといった運用などが考えられます。
よくない出荷 — 開発段階で防げるリリース後のリスク
最後に、リリース後のセキュリティリスクについても触れておきます。AIエージェントが生成するコードにはセキュリティ上の問題が含まれている可能性があり、レビューを経ずにリリースされると本番環境にバグ・脆弱性を持ち込んでしまいます。
こうしたリスクへの対策として、AIエージェントが安全・確実に動くよう、足回り（ツール、フック、テスト、Lintなど）を整える取り組みは「ハーネスエンジニアリング」と呼ばれています。例えばFormatterやLinter、テストフレームワークを導入し、フックやCIで自動実行する構成にしておくのがおすすめです。
セキュリティ面では、AIが生成したデッドコードや不要な依存関係が脆弱性を生み出す要因になるため、定期的なリファクタリングも欠かせません。加えて、手動またはCIでの脆弱性診断（静的・動的解析）のほか、Claude Codeの/security-reviewコマンドや弊社が提供するTakumiによるセキュリティレビューも効果的です。
終わりに
この記事では、バイブコーディングにおけるセキュリティリスクを、任意コード実行と情報漏洩を中心に7つ紹介し、それぞれの攻撃シナリオと対策をまとめました。
危険なことを禁止するのではなく、そもそも機密情報を置かない、漏洩しても被害が限定される設計にする、といった設計思想への転換が、AIエージェント時代のセキュリティ対策において重要になっていくと考えられます。
冒頭でもお伝えした通り、ここまで読んで 「ちょっと怖いな...」と感じた方は、まずサンドボックス環境の導入から始めてみてください。Claude Sandboxやe2b.dev、Docker Sandboxesなどを活用すれば、任意コード実行（リスク1〜5）をまとめて軽減でき、情報漏洩（リスク6〜7）の被害範囲も一定限定できます。万能ではありませんが、何か一つだけ実施するならこれをおすすめします。
この記事が、AIエージェントを使った安全な開発のヒントになればうれしいです。ここまでお読みいただきありがとうございました。
*1:最近はソフトウェアサプライチェーン攻撃の影響もあり、リリースノートはすぐに読むものの、アプデ&検証はリリース後3日くらい空けてから実施しています...
*2:Claude Codeのsubagentのように、メインエージェントが自動的にサブエージェントを呼び出す仕組みもあり、開発者が明示的に起動していなくてもエージェントが並列で動いているケースがあります
*3:全てのマーケットにその機能がないわけではなく、例えば、The Agent Skills Directoryには「Security Audits」機能があります。
*4:このサイトは2026年3月上旬時点ではフィッシングサイトのように見える状態でした。しかし、3月下旬には404 page not foundが表示されていました。
*5:同じく予約済みの example.com および( example.net / example.org )はIANAが実際にDNSレコードを運用しており 93.184.216.34 等に解決されるため、HTTPリクエストを伴うサンプルでは実際の通信が飛んでしまいます。そのため、名前解決されないドメインを使用してください
