バイブコーディングとセキュリティ：真実か嘘か

Tue, 30 Dec 2025 10:01:21 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

最近では「AIでコーディングをする」という言葉はもはや特別ではありません。すでにニューノーマルです。コーディングができることは当然の前提となり、現時点のAIツールはビジネスにおいてはるかに多くの仕事をこなします。

それでも多くの企業は導入段階で足踏みします。理由はいつも同じ、セキュリティです。今日はエンタープライズ企業の立場から、AIコーディングエージェント、とりわけプロダクションレベルのバイブコーディングで最も多く選ばれているClaude Codeを取り巻くセキュリティ上の懸念を、真実と嘘に分けてお話ししてみようと思います。

TL;DR

AIコーディングツールのセキュリティは漠然とした不安ではなく、契約条件、データ保存、実行環境、権限統制として具体化すべきです。
Claude Codeのようなエージェント型ツールはオートコンプリートのプラグインより広い攻撃対象領域を持つため、隔離とアップデート管理が必須です。
企業は製品設定だけを見るのではなく、サンドボックス化、ネットワーク統制、DLP、監査ログまで含めた運用モデルを作らなければなりません。

学習データ流出の真実

「AIにコードを入れると学習されて漏れる」という言葉は半分正しく、半分間違っています。エンタープライズ環境で重要なのは、漠然とした「AI」という単語ではなく、具体的な契約条件と製品の区分です。

Anthropicの企業向け製品は原則が明確です。基本的に商用の入力・出力データはモデルの学習には使用されません。Claude Codeのドキュメントでも、デフォルトの30日データ保存ポリシーとともに、適切に構成されたAPIキーを使用する場合はサーバーに会話履歴を保存しないZero Data Retention（ZDR）オプションを提供していると明示されています。

しかし個人向けの領域は話が異なります。2025年8月に変更された消費者向け利用規約によれば、「学習を許可するかどうか」の設定に応じてデータ保存期間が長くなる場合があります。したがって企業は、現在使用しているサービスが商用（Work/API/Gov）の範囲に属するのか、ログ保存ポリシーは標準（30日）なのかZDR（0日）なのか、そしてクライアントのローカルキャッシュをどこまで許容するのかを明確に確認し、統制しなければなりません。セキュリティの出発点は、守るべき資産を特定し保護手段を定義することにあるからです。

認証マークと実質的なセキュリティ

「SOC 2やISO 27001の認証があるから安全だ」という信念もまた、半分の真実にすぎません。もちろん認証は重要です。AnthropicはTrust CenterでSOC 2 Type II、ISO 27001といったコンプライアンスアーティファクトを提供し、組織のセキュリティ管理体系が機能していることを証明しています。

しかし認証は「侵害が絶対に発生しない」ことを保証するものではありません。認証は管理体系の有効性を示すだけであり、製品のあらゆる技術的脆弱性を取り除いてくれる魔法ではないからです。エンタープライズ企業は認証を単なる「安心の判子」と見なしてはいけません。代わりに、これを取引の安全装置として活用すべきです。データ保存期間、アクセス統制、監査ログ、インシデント通知手続き、サブプロセッサー管理、地域規制の遵守といった具体的な項目を契約と運用ポリシーに固定し、実質的な拘束力を確保しなければなりません。

エージェント型ツールの新たな脅威

「Claude Codeは単なるIDEプラグインだから危険ではない」という考えは危険な誤判断です。Claude Codeは単純なオートコンプリートツールではなく、自ら判断して行動する「エージェント型ツール」です。ローカルの実行環境、各種ツールとの連携、そしてユーザー権限が入り混じる地点で、従来とは次元の異なる攻撃対象領域が生まれます。

実際、2025年に報告されたClaude Code関連のCVE事例は、こうした脅威をよく示しています。IDE拡張のWebSocket認証バイパスによる未認可接続の問題（CVE-2025-52882）、ユーザーが信頼ダイアログを承認する前に悪意あるコードが実行されうる脆弱性（CVE-2025-59536）、Yarnプラグインと連動した類似の問題（CVE-2025-65099）、そしてパス検証の不備によるディレクトリ制限バイパスの問題（CVE-2025-54794）などがその証拠です。

これはClaude自体が危険だという意味ではありません。エンタープライズの配布および運用のやり方が危険でありうるという警告です。アップデートが遅れ、開発者PCの環境が断片化しており、ダウンロードフォルダから任意のファイルを実行することが容認される文化であれば、エージェント型ツールの導入は事故の確率を高める起爆剤になりかねません。

防御の速度と自動化

「AIセキュリティは防御側だけの悩みだ」という考えもまた誤りです。攻撃者もすでにAIを武器にしています。Anthropicが2025年8月に公開した脅威インテリジェンス（Threat Intelligence）によれば、Claude Codeを含むツールが大規模な恐喝作戦などのサイバー攻撃に悪用された形跡が捉えられました。さらに2025年11月には、AIを単なる助言者ではなく攻撃の実行者として活用する水準にまで高度化したスパイ活動キャンペーンが公開されもしました。

こうした現実は、防御戦略の根本的な変化を求めます。人が一つひとつ対応する遅い防御のやり方では、AIの速度で攻撃してくるハッカーを止めることはできません。今や検知から対応、復旧に至る全過程に自動化を導入し、防御の速度を攻撃の速度に合わせなければなりません。

エンタープライズへの提言：製品設定を超えて運用モデルへ

結局のところ核心は、単純な製品設定ではなく「運用モデル」の革新です。Anthropicは権限のポップアップを減らしながらも安全を確保するために、ファイルシステムとネットワークの隔離に基づくサンドボックス化を強調しています。企業はこの方向性に合わせて、もう一段具体的な実行戦略を策定しなければなりません。

まず実行環境の隔離が必須です。可能な限りDev Container、VDI、隔離されたVM環境でAIツールを実行するようにし、ローカルPCで動かす場合でもファイルおよびネットワーク隔離のサンドボックス化をデフォルト値として適用すべきです。

ネットワーク統制もまた「デフォルト遮断（Deny-All）」を原則とすべきです。業務に必須のドメインだけをホワイトリストで許可し、残りは遮断しなければなりません。ネットワーク隔離がない状態でのプロンプトインジェクションは、即座のデータ流出につながりかねないからです。

非信頼パスからの実行はシステム的に遮断すべきです。多数のCVEが共通して警告する攻撃シナリオは、ユーザーを騙して非信頼ディレクトリでツールを実行させることです。したがってダウンロードフォルダ、一時フォルダ、共有フォルダなどからの実行は、ポリシー教育ではなくシステム設定を通じて技術的に防がなければなりません。

アップデートの強制も重要です。IDE拡張やCLIツールのアップデートを開発者個人の自律に委ねてはいけません。最小許容バージョンのポリシーを策定し、基準に満たないバージョンは実行自体が不可能になるよう遮断すべきです。

**データ漏洩防止（DLP）**の体系は、プロンプト入力の前段階に構築されなければなりません。シークレットスキャニング（Secret Scanning）とプロンプトDLPを基本設備として備え、AIや人が間違えても事故につながらないようにすることが、エンタープライズセキュリティの核心です。

最後に監査ログと異常兆候の検知の体系を備えなければなりません。誰が、どのリポジトリで、どのツールを呼び出したのかという記録を残し、これをリアルタイムで分析すべきです。攻撃者が自動化されたツールで攻撃してくる以上、防御体系もそれに見合う速度と可視性を確保しなければなりません。

結論：セキュリティがビジネスの足を引っ張らないようにするには

セキュリティはブレーキです。ブレーキがなければ事故が起きます。しかしブレーキだけを踏んでいてはどこにも行けません。エンタープライズがAI導入の前で立ち止まる場面をよく見かけます。「危険かもしれないから、ひとまず保留にしよう」という決定です。保留は現状維持を意味しません。単に競争力が落ちるだけでなく、ハッカーも攻撃にAIを使っているからです。

Claude Codeのようなツールはすでに現場に入ってきています。問題は「使うか使わないか」ではありません。今は、どうすれば安全に使えるかを考えるべき時期です。ここでセキュリティは、ビジネスの足を引っ張る存在ではありません。セキュリティは安全にスピードを出せるようにしてくれるガードレールになります。ルールがあってこそチームは速く動けます。ガードレールがあってこそ人は恐れずに走れるのです。

そこでROBOCOが下した結論は単純です。AIを信じるな。人も信じるな。代わりに、信じられるシステムを作れ。そのシステムの核心は、組織が統制できる自動化されたプロセスとガードレールです。

Security on ROBOCO