AI駆動開発のセキュリティ、結局どこまでやればいい？

Posted at 2026-06-15

はじめに
前提：AI駆動開発ならではのリスクを知っておく
レベル1：一般的なセキュリティレベル
レベル2：厳格に情報を管理したい場合
レベル3：最厳格（規制業種）
3レベル早見表
監査・ISMSへの対応
知的財産・ライセンスのリスク
その他に気にすべき観点
導入企業の例（レベル別）
導入の進め方：禁止より統制
まとめ

はじめに

AI駆動開発（AIコーディングアシスタントを前提とした開発スタイル）を導入しようとすると、技術選定よりも先に立ちはだかるのが「セキュリティ、大丈夫なの？」という問いです。特に意思決定者の立場だと、「コードや顧客データが学習に使われたりしないのか」「漏洩したら責任を問われるのは自分」という不安がつきまといます。

ここでよくある失敗が、「不安だから全面禁止」 という判断です。ところがツールを禁止すると、現場のエンジニアは個人アカウントでこっそり使い始めます。いわゆるシャドーAIで、これは統制された利用よりもはるかに危険です。実際、近年は全面禁止よりも、統制された利用を前提とする方針を推奨するガイドラインが増えています。

とはいえ、すべての企業が同じ対策をする必要はありません。社内ツールを作るスタートアップと、患者データを扱う医療システムでは、求められるレベルがまったく違います。

この記事では、AI駆動開発のセキュリティを 3つのレベル に分けて整理します。

レベル1：一般的 ── 個人開発・社内ツール・スタートアップ
レベル2：厳格 ── 受託開発・顧客データを扱うSaaS・中規模以上の企業
レベル3：最厳格 ── 金融・医療・官公庁など規制業種

まず全レベル共通で押さえるべき「AI駆動開発ならではのリスク」を確認し、そのうえでレベルごとの対処法を見ていきます。

そして先に、記事全体を貫く視点を一つ共有しておきます。ここで本当に問われているのは「AIを使うか・使わないか」ではありません。自社がどのレベルに当てはまり、リスクと便益をどうバランスさせながら進めるか ── これはまさに経営判断です。本記事は、その判断を下すための材料を整理することを目的にしています。

※ 本記事のデータ保持期間や各種ポリシーは2026年央時点の一般的な情報です。各ベンダーのポリシーは頻繁に変わるため、導入時には必ず最新の公式ドキュメントと自社の契約内容を確認してください。

前提：AI駆動開発ならではのリスクを知っておく

レベルの話に入る前に、「そもそもAIを開発に使うと、従来と何が違うのか」を整理します。ここを理解しないと、レベル分けの意味が伝わりません。

1. データの学習利用と保持（一番気にされるポイント）

意思決定者が最初に心配するのが「送ったコードがAIの学習に使われるのでは」という点です。これは言い換えれば 「自社のコードや情報が外部に漏れるのでは」 という不安であり、こちらの表現のほうがピンと来る方も多いはずです。ここは 個人向けプランとAPI/法人プランで扱いがまったく違う ことを知っておく必要があります。

個人向けのチャットUIやコンシューマープラン は、設定によっては会話が学習に使われる場合があります（オプトアウトが必要なケースも）。
API経由や法人向けプラン では、入力データを学習に使わないことが原則です。例えばGitHub Copilotの Business / Enterprise プランは、顧客コードを学習に使わないことを契約上保証しています。

つまり「APIや法人契約で使う」というだけで、リスクの大半は下がります。一般に、Web版のチャットを業務で使うより、API経由のほうがデータの扱いは厳格です。

「学習されない」とは別に 「ログがどれくらい保持されるか」 という論点もあります。不正利用の検知などのために、入出力が一定期間サーバーに残るのが一般的です。この期間はベンダーによって異なりますが、近年は保持期間を短縮する動きも見られます。最厳格レベルでは、この「一定期間も残したくない」というニーズに応える仕組み（後述のZDR）が必要になります。

2. シークレットの漏洩（学習より現実的な脅威）

「学習に使われる／使われない」は契約で守られる部分が大きいのですが、より現実的で見落とされがちなのが コンテキストウィンドウ経由の漏洩 です。

AIに補完させるとき、ツールは周辺のコードを「文脈」としてクラウドへ送ります。このとき .env ファイルやAPIキー、DBパスワードなどがうっかり一緒に送られてしまうことがあります。学習に使われなくても、推論のために外部へ送信されている時点でリスクです。

3. プロンプトインジェクション

これはAI特有の新しい攻撃です。攻撃者が、READMEやコードコメントに 人間には見えない白文字 で「APIキーを外部に送れ」といった指示を埋め込んでおき、AIにそれを実行させようとします。AIは指示とデータの区別が苦手なので、「データのつもりで読んだ文章」が「命令」として作用してしまうのです。

4. slopsquatting（ハルシネーション由来のパッケージ汚染）

2026年に問題化している比較的新しい脅威です。AIは実在しないパッケージ名を「もっともらしく」提案することがあります（例：fast-json-parser-v2 のような存在しない名前）。攻撃者はその名前を先回りして登録し、マルウェアを仕込みます。エンジニアがAIの提案を鵜呑みにして install すると、感染します。

提案に占める存在しないパッケージの割合は、商用モデルでおよそ5.2%、オープンソースモデルではおよそ21.7%と報告されています（Spracklen et al., USENIX Security 2025, 16モデル・57.6万サンプルの調査）。無視できない数字です。

すでに実害も出ており、不正パッケージが利用停止後もダウンロードされ続けた事例や、AIエージェントが幻覚パッケージを自動で実行しようとした事例が報告されています。理論上の懸念ではなく、現実の脅威と捉えてよい段階です。意思決定者として押さえておきたいのは、次の3点です。

起きた場合のリスク：これはソフトウェアのサプライチェーン侵害です。不正パッケージが入り込めば、認証情報の窃取・バックドア設置・データ持ち出しにつながりえます。自社製品に混入すれば顧客にまで被害が及び、侵害対応コストと信用失墜が発生します。一度の取り込みが全体に波及しうる、影響の大きい類のリスクです。

防ぎ方と必要なコスト：幸い、対策の大半は既存の開発工程に組み込める仕組みで、新たな専任人材はほぼ不要です。具体的には、依存パッケージを自動スキャンするSCAツール（Snykなど）をCIに組み込む、lockfileでバージョンを固定し許可した社内レジストリ経由でのみ導入する、「AIが勧めたパッケージを検証せず入れない」という運用ルールを徹底する ── この3点が中心です。いずれも初期設定は既存のエンジニアが数日で対応できる範囲で、その後は自動で回るため、ランニングの人件費はほぼ増えません。

どの程度警戒すべきか：対策にかかるコストは小さい一方、起きたときの被害は大きいため、やっておく価値は明確です。特にエージェントにパッケージのインストールまで任せる場合は、自動実行前の検証を必須にしておくべきです。

5. エージェント/MCPの「過剰な権限」

最近の主流は、AIがIDEの外でコードベース全体にアクセスし、ファイルの読み書きやターミナルコマンドの実行、MCP（外部ツール連携の仕組み）を通じた外部システムへの接続まで行う エージェント型 です。便利な反面、AIが過剰な権限を持つと被害も大きくなります。

2025年には、コーディングアシスタントがバックドアをコミットした事例、モデルファイルが読み込まれた瞬間にリバースシェルを実行した事例が報告されています。また、AIコーディングエージェントの事例ではありませんが、AIチャットボット連携（Salesloft Drift）のOAuthトークンが盗まれ、700以上の組織のSalesforce環境が約10日間不正アクセスされていた事件（2025年8月、FINRA・Google Mandiant等が公表）は、「AI連携が持つ権限の大きさ」と「侵害されたとき被害が広範囲に及ぶ」教訓として、エージェント型の権限設計にも直結します。エージェント型を使う場合は「何を実行してよいか」の権限設計が必須です。

レベル1：一般的なセキュリティレベル

想定：個人開発、社内ツール、スタートアップのプロダクト開発。機密性の低いコードが中心で、まずは生産性を取りに行きたいフェーズ。

このレベルでは、「基本を守れば十分」 です。やることはシンプルです。

個人向けプランではなく、API/法人プランを使う。これだけで学習利用のリスクは原則回避できます。可能ならチームの利用は組織アカウントに統一します。
シークレットをリポジトリに置かない。.env や鍵ファイルは .gitignore で除外し、環境変数やシークレットマネージャーで管理する。これはAI以前からの基本ですが、AI時代はより重要になります。
依存パッケージを確認する習慣をつける。AIが提案したライブラリは、install する前に本当に実在するか・正規かを確認する。slopsquatting対策です。
生成コードは必ずレビューする。「AIが書いたコードは、インターンが書いたコードと同じ」と考えるのが鉄則です。動くからといってそのままマージしない。

レベル1はツールの標準機能と最低限の運用ルールでカバーできます。逆にここを飛ばすと、どのレベルに上げても土台が崩れます。

レベル2：厳格に情報を管理したい場合

想定：受託開発、顧客データを扱うSaaS、中規模以上の事業会社。「自社の情報」だけでなく「顧客から預かった情報」が含まれ、漏洩が契約違反や信用失墜に直結するフェーズ。

レベル1の対策に加えて、「契約・設定・プロセス」 の3面で締めていきます。

データの扱いを契約で確認する

データ保持ポリシーを明示的に確認する。「学習に使わない」だけでなく「ログを何日保持するか」「削除できるか」まで契約書（DPA：データ処理契約）で確認します。
保持期間は短く・監査可能に。プロンプトに含めるデータの利用目的と法的根拠を記録し、保持は必要最小限にします。

入口でブロックする（送る前に止める）

Content Exclusion（コンテンツ除外）を設定する。.env、*.pem、internal-config.yaml といった機密ファイルを、そもそもAIの処理対象から除外します。組織・リポジトリ単位で設定できるツールが増えています。
送ってはいけないデータの種別をルール化する。顧客の個人情報、認証情報などを外部モデルに送らないルールを、できれば仕組み（属性ベースのフィルタ）で強制します。人の注意力に頼ると必ず漏れます。

出口を固める（生成物のチェック）

生成コードにSAST/DASTを通す。静的解析・動的解析をマージ前に必ず実行します。
AI生成コードであることをレビューで明示する。プルリクエストに「この変更はAI生成を含むか」「どんな追加チェックをしたか」を書く欄を設けると、レビュアーが警戒すべき箇所に集中できます。
CWE Top 25 など既知の高頻度脆弱性パターンに照らす。AIはよくあるミスを再生産しがちなので、チェックの観点を決めておきます。

エージェントの権限を設計する

エージェント型を使うなら、「AIが何を実行してよいか」を明示的に制御 します。ファイルアクセス・コマンド実行・ネットワークアクセスの範囲を、開発者ごと・プロジェクトごとに設定できる仕組みを選びます。「とりあえず全権限」は禁物です。

統制を継続する

四半期ごとにポリシーを再評価する。ベンダーがデータ保持ポリシーを変更したら、再評価をトリガーする運用にします。AIまわりのポリシーは本当によく変わります。
どのチームがどのツールを使っているか把握する。棚卸しをして、承認済みツール以外の利用（シャドーAI）を検知します。

レベル2のポイントは、「禁止」ではなく「統制された利用」 に倒すことです。ツールを資産として扱い、既存のSDLC（ソフトウェア開発ライフサイクル）やセキュリティ体制の中に組み込みます。

レベル3：最厳格（規制業種）

想定：金融、医療、官公庁、機密性の高い研究開発など。「データが建物の外に出ること自体が許されない」レベル。患者記録、金融取引、法務文書、M&A情報など、低確率の漏洩でも壊滅的な結果を招くデータを扱う。

ここでは「クラウドAIをどう安全に使うか」ではなく、「データをどこまで自社の管理下に閉じ込めるか」 が論点になります。デプロイ方式の選択が中心テーマです。

デプロイ方式は、ざっくり4段階で考えると整理しやすいです。

方式	データの行き先	管理負荷	想定レベル
Cloud SaaS	ベンダーのインフラへ（公衆インターネット経由）	低	レベル1〜2
Private Cloud / VPC	自社のクラウドアカウント内に閉じる	中	レベル2〜3
On-prem（オンプレミス）	自社の物理インフラ内	高	レベル3
Air-gapped（エアギャップ）	外部ネットワークから物理的に隔離	最高	レベル3

主な選択肢

ZDR（Zero Data Retention：ゼロデータ保持）契約。法人向けAPIで、入出力をレスポンス後にサーバーへ保存しない契約形態です（不正利用の検知に必要な最小限を除く）。「学習に使わない」のさらに上で、「そもそも残さない」を実現します。ただし対象は特定のAPI/プランに限られ、Web UIやベータ機能は対象外なのが通常なので、適用範囲を契約で確認することが重要です。
VPC内デプロイ（AWS Bedrock / Google Vertex AI など経由）。モデルを自社のクラウド環境（VPC）内で動かし、推論トラフィックが管理下のネットワーク境界から出ないようにします。VPC Service Controls や Private Endpoint で「外に出さない」を担保します。マネージドSaaSより管理負荷は上がりますが、制御は格段に強くなります。
オンプレ/エアギャップ。Llama や Mistral などのオープンソースモデルを自社の物理インフラ（多くはGPUサーバー）で動かし、外部接続を完全に断ちます。データ主権が絶対条件のとき、または規模が十分大きいときの選択肢です。更新やライセンスのために外部接続が残るVPCとは異なり、エアギャップは更新も含めて隔離するため運用設計が一段難しくなります。

規制対応の仕組み

HIPAA対応（医療）。保護対象保健情報（PHI）を扱う場合、BAA（事業者間契約）を締結してHIPAA対応のAPIアクセスを使う、といった枠組みが用意されています。
監査ログの完全管理。誰がいつどのデータにアクセスしたかを追跡できる、改ざん不能な監査ログを必須とします。
認証・認可の強化。SSO/SAML、RBAC（ロールベースのアクセス制御）、シークレット管理（Vault連携）などを組み合わせます。
ガバナンス用のゲートウェイ。複数チーム・複数プロバイダーをまとめて統制する「LLMゲートウェイ」「MCPゲートウェイ」を間に挟み、仮想キー単位で予算・レート制限・利用可能モデルを制御する構成も、規制業種では一般的になりつつあります。

レベル3は「ツールの設定」の話を超えて、インフラ設計とコンプライアンスの話 になります。重要なのは、プライベートかどうかを決めるのはモデルそのものではなく、その周りのインフラとアクセス制御 だという点です。同じモデルでも、置き方次第でセキュリティレベルはまったく変わります。

補足：現状を正しく捉えるための注意点

「規制業種でも、もう前例があるんでしょ？」という見方は半分正しく、半分は注意が必要です。誤解を避けるために、現状をありのままに整理しておきます。

コンプラ・契約のレイヤーは、すでに整いつつあります。クラウド経由でのHIPAA BAAの締結、FedRAMP認証の取得、SOC 2 Type II やGDPRのDPAといった枠組みは製品化され、規制業種での導入も実際に進んでいます。ベンダー選定も、各種認証や監査ログ、インシデント対応の文書を「あるか」で評価する形が定番化してきました。「コンプライアンスはブロッカーではなく、踏むべき手順が明確になった領域」 と捉えるのが実態に近いです。
ただし「枠組みが用意されている＝自動でクリア」ではありません。標準の公開APIエンドポイントは、原則として規制対応向けに設計されておらず、BAAが付かないのが通常です。BAAなしで保護対象データを外部サービスに送れば、それ自体が違反になります。対応するには、BAA対象・認証取得済みのデプロイ構成（VPC経由など）を選び、正しく設定して初めて要件を満たします。FedRAMPでは、呼び出すAPIエンドポイント自体が認証境界の中にある必要があり、認証取得には1年以上かかることもあります。「先行事例があるから楽」ではなく「踏む手順が明確になった」 という整い方です。
知財・責任のレイヤーは、また別軸でまだ発展途上です。HIPAAやFedRAMPはもともと成熟した枠組みなので前例が整う一方、AI生成コードの著作権・フェアユース・侵害責任については、裁判所がまだ明確な判断を下していません。「規制対応の道は通った」ことと「あらゆる法的論点が解決した」ことは別物 として切り分けておくのが安全です。

まとめると、規制業種でのAI駆動開発は「不可能」ではなく「手順が見えてきた」段階で、業界としても課題を一つずつクリアしていく流れにあります。とはいえ、組み込めばそれなりのリスクを抱えることも事実です。そのリスクと、AI駆動開発で得られる生産性・競争力をどうバランスさせるか ── ここはまさに経営判断が求められる場面 だと言えます。「やる／やらない」の二択ではなく、「自社はどのレベルで、どこまでのリスクを取って進めるか」を経営として決める、という捉え方が現実的です。

3レベル早見表

観点	レベル1：一般的	レベル2：厳格	レベル3：最厳格
想定	個人開発・社内ツール	受託・顧客データ扱うSaaS	金融・医療・官公庁
利用形態	API/法人プラン	API/法人プラン＋DPA確認	ZDR / VPC / オンプレ / エアギャップ
データ保持	標準で可	保持期間を契約で確認・最小化	ZDRまたは外部に出さない
機密ファイル	`.gitignore` で除外	Content Exclusionで強制除外	そもそも外部に出ない構成
生成コード	必ずレビュー	レビュー＋SAST/DAST	同左＋監査ログ
エージェント権限	標準設定で注意	権限を明示的に制御	ゲートウェイで集中統制
認証	通常ログイン	SSO推奨	SSO/SAML＋RBAC＋MFA必須
運用	基本ルールのみ	四半期ごとに再評価・棚卸し	継続監査・コンプライアンス対応

監査・ISMSへの対応 ──「説明できる状態」をつくる（主にレベル1〜2）

日本だと、特に受託開発の会社はISMS認証（ISO/IEC 27001）を持っていることが多く、AIツールの導入で必ず出てくるのが 「これ、監査でどう説明するの？」「ISMSの範囲にどう収めるの？」 という問いです。レベル3（規制業種）は最初からガッチリやるので逆に悩みません。むしろ悩むのはレベル1〜2です。ここを整理します。

大原則：AIツールは「特別なもの」にしない

よくある失敗が、AIだけ別枠の管理体制（専用ポリシー・専用台帳・専用監査）を作ってしまうことです。これは管理が二重化して、いわゆる「監査疲れ（audit fatigue）」を招きます。

そうではなく、AIコーディングツールは「新しく使い始めた外部クラウドサービスの一つ」 として、既存のISMSの枠組み（クラウド利用管理・委託先管理）の延長で扱うのが正解です。新しい箱を作るのではなく、今ある箱に「AIの観点」を足していくイメージです。

監査で説明すべきは、この4点

監査人が知りたいこと、そして自社が即答できるべきことは、突き詰めると次の4つです。

どこで（Where）：どのツールを、どの環境で使っているか
誰が（Who）：どの部署・どのメンバーが使っているか
どのデータに（What）：何の情報をAIに送っているか／送ってはいけない情報は何か
どんな統制下で（Under what controls）：承認・レビュー・ログがどうなっているか

これに自信を持って答えられない状態は、すでに「シャドーAI」に片足を突っ込んでいるサインです。逆に言えば、この4点を文書と記録で示せれば、監査対応の大半は済みます。

具体的に整備しておくもの

レベル1〜2で、監査・ISMS対応のために用意しておきたい最低限はこのあたりです。

利用ツールの台帳と承認プロセス：どのAIツールを誰が使ってよいか、申請・承認のフローを残す。「勝手に個人アカウントで使う」を防ぐ入口です。
送信データの分類ルール：顧客情報・認証情報など「AIに送ってはいけないデータ」を明文化する。前述のContent Exclusionなどの技術的措置とセットにすると強い。
委託先（AIベンダー）評価の記録：データ保持期間・学習利用の有無・第三者提供の有無を、利用規約やDPA（データ処理契約）で確認した記録を残す。「学習に使われない契約であることを確認済み」と示せる状態にしておく。
レビューの証跡：生成コードをレビューした記録（プルリクエストのレビュー履歴など）。AI生成コードを無検査で本番投入していない、という証拠になります。
教育記録：開発者に対し「プロンプトに機密を入れない」「提案パッケージを検証する」といった注意を周知した記録。

これらは多くがすでにISMSで持っている仕組み（委託先管理、変更管理、教育）に乗せられます。ゼロから作るものは意外と少ないはずです。

顧客への「説明責任」も忘れずに（レベル2の肝）

受託開発の場合、監査人だけでなく 発注元の顧客 から「うちのソースコードをAIに学習させていないか？」と問われる場面が増えています。ここで黙ってしまうと信頼を失います。

あらかじめ、

API／法人プランを使っており、入力は学習に使われないこと
顧客の機密情報はAIに送らない運用にしていること
ベンダーとのデータ保持・利用条件を確認済みであること

を 契約や提案資料の中で説明できる状態 にしておくと、むしろ「AIを安全に使いこなしている会社」として差別化になります。守りの話を、攻めの材料に変えられるポイントです。

ISO/IEC 42001（AIマネジメントシステム）は今すぐ必要？

最近よく聞く ISO/IEC 42001 は、AIの利用そのものを管理するための国際規格（AIMS）で、2023年末に発行されました。情報セキュリティの ISO 27001 と並べて使うことを想定した、いわば「AI版のISMS」です。

ただし結論から言うと、レベル1〜2の多くの会社にとって、今すぐ42001を取得する必要は基本ありません。

42001は法的義務ではなく任意規格です（EUのAI規制などとは別物）。
すでにISO 27001を運用しているなら、まずは既存ISMSにAIの観点を組み込むのが現実的です。42001の管理項目はISO 27001と多くが共通しており、後から拡張しやすい構造になっています。
一方で、公共調達や大企業との取引で「42001を持っているか」が条件になり始めている、というトレンドはあります。将来の取引要件として頭の片隅に置いておく のが、ちょうどよい距離感です。

つまりレベル1〜2の現実解は、「まず既存ISMSにAIを組み込んで説明できる状態を作る」→「取引先から求められたら42001を検討する」という順序です。

補足：これはもう前例がある

「AIを使うとISMS認証が通らないのでは」と心配する声がありますが、AIツールを開発実務で使いながらISO 27001の認証を維持している企業はすでに複数存在します。「AIを使うと通らない」のではなく「正しく組み込めば認証は維持できる」というのが実態で、やるべき手順（学習データのオプトアウトをISMSに文書化、個人情報・決済情報のプロンプト投入を禁止して合成テストデータで代替、教育記録の保持、内部監査でAI利用を対象に含める）も収束してきています。本記事で挙げた整備項目と同じ方向です。

ただし注意点として、これはHIPAAのBAAのような「契約すれば対象」という明確な線引きとは違い、認証機関が"AI対応"のお墨付きを出すわけではなく、既存ISMSを拡張して説明できるようにする性質のものです。特に2023年より前に認証を取ったISMSはAIツールを想定していないため、後付けで観点を足す作業が前提になります。「前例がある」とは、法的お墨付きというより、監査人がAIツールの存在を前提に見るのが普通になってきた、という整い方だと捉えてください。

知的財産・ライセンスのリスク（全レベル共通）

情報セキュリティとは別軸で、見落とされがちなのに実務インパクトが大きいのが 知的財産（IP）・ライセンス の問題です。これはレベルに関係なく、AIでコードを書くすべての会社に関わります。

なぜ問題になるのか

AIは学習データに含まれていたコードを「もっともらしく」再生産することがあります。ここから2つのリスクが生まれます。

1. オープンソースライセンスの汚染
AIが、GPLなどのコピーレフト系ライセンスのコードをそのまま出力し、それが自社のプロプライエタリ製品に混入することがあります。コピーレフトは「それを含む成果物全体に同じライセンス義務（ソース開示など）を伝播させる」性質があるため、知らないうちに自社製品全体がライセンス義務を負ってしまう恐れがあります。AIがGPL由来のコードを含むのに、出力時はあたかも制約のないコードのように見せてしまう ── これが「著作権ロンダリング（copyright laundering）」と呼ばれる問題です。

2. 成果物の権利が守られない
多くの法域では、著作権の保護に「人間による創作（人間の著作者性）」が必要とされます。そのため、純粋にAIが生成しただけのコードは、著作権で保護されない＝誰のものでもない状態になりうる、という議論があります。ベンダーの利用規約に「生成物の権利はユーザーに帰属する」と書かれていても、それは契約上の取り決めであって、著作権法上の保護とは別の話です。実務的には、人間が十分にレビュー・修正・判断を加えるほど、自社の成果物として保護されやすくなる と理解しておくとよいです。

そして重要なのが責任の所在です。AIツールを使ったとしても、最終的にその成果物を本番に投入した企業が責任を負う のが原則です。「AIが書いたから」は免責になりません。

対策

ライセンス／類似度スキャンをPRごとにかける：FOSSA、Snyk、GitHub Advanced Security などのツールで、既知のオープンソースと一致するコードが混入していないかを自動チェックします。本番デプロイ前のライセンス監査を、レビュー工程に組み込むのが基本です。
「公開コードとの一致をブロックするフィルタ」を有効にする：ツールによっては、このフィルタを有効にすると公開コードの丸写しを防げます。さらに、これを有効にしている場合に限ってベンダーがIP補償（indemnification）を提供する、という形が一般的です。補償条件は契約で必ず確認してください。
IP補償条項のあるツール／プランを選ぶ：万一の権利侵害クレームに対し、ベンダーが一定の補償を約束しているかを選定基準に入れます。
生成箇所に人間の判断を入れる：丸呑みせずレビュー・修正することで、権利保護の面でも有利になります。
受託の場合は契約で明示する：「成果物のライセンス保証（オリジナリティ保証）」「IP補償」「AI利用の開示」を契約に盛り込むと、発注元・受注側の双方が守られます。

ライセンス汚染は「動くかどうか」とは無関係に潜むので、機能テストだけでは見つかりません。専用のスキャンを工程に入れる ことが唯一の現実的な防御です。

その他に気にすべき観点

会社の業種や取引先によっては、ISMSやIP以外にも見ておくべき観点があります。自社に当てはまるものだけ拾ってください。

プライバシー法・データの越境移転

個人情報を扱う会社では、情報セキュリティとは別に 個人情報保護法（APPI）やプライバシーマーク（Pマーク） の観点が出てきます。特に注意したいのが 越境移転 です。海外で運用されているAI APIに個人データを送ると、それ自体が「個人データの国外移転」に該当しうるため、本人の同意や移転先の確認といった手当てが必要になることがあります。EU市民のデータを扱うならGDPRも関わります。

現実的にいちばんシンプルなのは、そもそも個人情報をAIに送らない運用にする ことです。送らなければ、越境移転の論点の大半は消えます。

業種・取引で求められる規制・認証

該当する会社だけの話ですが、頭出ししておきます。

EU AI Act：EU向けに製品・サービスを出す、またはEU市民のデータを扱う場合。高リスクAIに関する義務が2026年8月から段階的に適用され、全面適用は2027年8月とされています。
金融：FISC安全対策基準など、金融業界固有のガイドライン。
医療：医療情報の3省2ガイドライン（患者データの取り扱い）。
SaaS事業者：SOC 2（特に米国系の取引先から求められやすい）。
クレジットカード情報を扱う：PCI DSS。

自社に該当する枠組みがあれば、その方針の中に「AIツールの利用ルール」も一緒に位置づけておくと、後から監査・取引審査でつまずきません。

運用・組織のリスク

コストのガバナンス：AIツールは便利な分、使われ方が広がると費用が一気に膨らみます（前述のとおり、Uberは年間予算を4ヶ月で使い切っています）。予算上限・レート制限・利用状況の可視化をセットで設計しておきます。
内部不正の容易化：エージェント型は「機密を読む権限」と「外に送る権限（コマンド実行・外部接続）」を同時に持つため、情報を持ち出すパイプラインが最初から揃っているのと同じ状態になります。従来ならスクリプトを書く手間や知識が要った持ち出しも、「顧客情報を全部集めてファイルにして」と頼むだけで多段の作業をこなしてしまうため、一人でできる持ち出しの規模とハードルが跳ね上がります。対策は権限の最小化（読める範囲・実行できるコマンド・接続先を絞る）と、実行内容を後から追えるログです。「とりあえず全権限」が一番危険です。
顧客契約・NDAの確認：発注元との契約やNDAで「AIツールの利用禁止」や「利用時の開示義務」が定められているケースが増えています。使い始める前に、既存契約に抵触しないかを確認しておくと安全です。

導入企業の例（レベル別）

「他社はどうしているのか」は、意思決定の後押しになります。レベル別に、実際にAI駆動開発（社内の開発業務へのAIツール導入）を進めている企業の例を挙げます。

※ 下記は2026年央時点で報じられている例です。「銀行がAI導入」といったニュースでも、社内開発への利用ではなく顧客向けのAIサービスを指すケースが多いため、ここでは 開発業務への導入 に絞っています。

レベル1〜2寄り：事業会社の広い導入

一般的な事業会社では、すでにAIコーディングツールが当たり前の道具になりつつあります。Shopify、Stripe、Duolingo、General Motors、Mercado Libre、Coca-Cola といった企業が導入事例として公表されており、ブラジルの化粧品大手 Grupo Boticário は生産性が大きく向上したと報じられています。

一方で、「統制せずに入れるとコストが暴れる」教訓もあります。Uber は、2026年の年間AIコーディングツール予算をわずか4ヶ月で使い切りました（CTO Praveen Neppalli Naga氏がThe Informationに明かし、Bloomberg、TechCrunch等が報道）。エンジニアの95%がAIツールを利用し、社内リーダーボードで利用を競わせた結果、導入が想定を超えて一気に広がったためです。生産性向上の裏で、予算管理とガバナンスの設計が追いつかないと事故る という典型例です。

レベル3寄り：規制業種の厳格な導入

金融：HSBC は3万人規模のエンジニアにAIコーディングアシスタントを配布したと報じられています。ゴールドマン・サックスは、自律型のAIソフトウェアエンジニアを、人間の開発者に加える形でパイロット導入しています。いずれも厳格な規制環境のなかで、統制を前提に進めている例です。
医療：クリーブランド・クリニックは、ベンダー側がSOC 2 Type II認証の取得とHIPAAのBAA（事業者間契約）締結を済ませたうえで、AIを多数の病院に展開したと報じられています。これは開発というより業務利用寄りですが、「規制業種は認証と契約を固めてから入れる」という順序の手本になります。

注意：企業の採用は半年で変わる

実名事例を見るときに意識したいのが、ツールの採用は驚くほど早く入れ替わる という点です。例えば Microsoft は、2025年12月に社内展開したClaude Codeについて、2026年6月末までにGitHub Copilot CLIへ移行するよう従業員に指示したと報じられています（The Verge）。社内で人気が出すぎて自社製ツールの利用を押しのけてしまった、という皮肉な経緯もありました。

つまり「あの有名企業が使っているから安心」という選び方は危ういということです。大事なのは どのツールを選ぶかよりも、どのレベルで・どんな統制を敷いて使うか。事例はあくまで参考にとどめ、自社の判断軸を持つことをおすすめします。

導入の進め方：禁止より統制

最後に、レベルに関わらず共通する「進め方」のコツをまとめます。

小さく始めて、安全に広げる。まず1チームでパイロットし、問題なければ展開する。最初から全社一斉導入はリスクが高い。
初日からセキュリティを組み込む。後付けではなく、最初から情報セキュリティ部門と足並みを揃える。
生成物を継続的に検証する。AIは「レビューが必須なジュニアエンジニア」。出力を信頼しきらず、必ず人とツールでチェックする。
現場との対話から始める。ネットワークログを調べる前に、まずエンジニアに「何を使っている？」と聞く。多くの場合、正直に教えてくれます。これが時間を節約し、信頼を築き、結果としてシャドーAIを減らします。

「禁止」は一見安全に見えて、実際にはシャドー化を招いて統制を失います。ツールを統制された資産として扱い、自社のレベルに合った締め方をする ── これが、AI駆動開発のセキュリティの基本姿勢です。

まとめ

AI駆動開発のセキュリティは、企業のレベルによって対処が変わる。一律に「全部やる」「全部禁止」は不適切。
全レベル共通で、学習利用・ログ保持・シークレット漏洩・プロンプトインジェクション・slopsquatting・エージェントの過剰権限という新しいリスクを理解しておく。
レベル1は、API/法人プランの利用とシークレット管理、生成コードのレビューという基本で十分。
レベル2は、契約（DPA）・設定（Content Exclusion）・プロセス（SAST/DAST、権限制御、四半期レビュー）の3面で締める。
監査・ISMS対応は、AIを特別扱いせず既存のISMSに組み込み、「どこで・誰が・どのデータに・どんな統制下で」使っているかを説明できる状態を作る。ISO 42001は将来の取引要件として頭の片隅に。
知的財産・ライセンスは全レベル共通の論点。オープンソース汚染と成果物の権利帰属に注意し、ライセンススキャンとIP補償条項で守る。本番投入した企業が責任を負う点も忘れずに。
その他、個人情報の越境移転（APPI/Pマーク）、業種別の規制（EU AI Act/FISC/3省2ガイドライン/SOC2/PCI DSS）、コスト・内部不正・顧客契約上の制約も、自社に該当すれば押さえる。
レベル3は、ZDR・VPC・オンプレ・エアギャップといったデプロイ方式の選択と、監査ログ・規制対応が中心になる。
進め方は「禁止より統制」。小さく始め、現場と対話し、生成物を継続検証する。

自社がどのレベルに当てはまるかを最初に見極めれば、「やりすぎてコストを無駄にする」ことも「足りなくて事故る」ことも避けられます。冒頭でも触れたとおり、AI駆動開発で問われているのは「使うか・使わないか」ではなく、どのレベルで、どこまでリスクを取って進めるか という経営判断です。そこさえ定まれば、あとは本記事の観点を自社のレベルに当てはめていくだけです。

参考

Spracklen et al.「We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs」(USENIX Security 2025)
FINRA「Cybersecurity Alert – Salesloft Drift AI Supply Chain Attack」(2025)
ISACA「Securing the AI Frontier: A Practical Framework for Assessing AI Coding Assistant Vulnerabilities」(2026)
WWT「How to Securely Implement AI Coding Assistants Across the Enterprise」
Coalition for Secure AI (CoSAI)「Addressing what's next in securing enterprise AI」(RSAC 2026)
OpenSSF「Security-Focused Guide for AI Code Assistant Instructions」
ISO/IEC 27001（情報セキュリティ）および ISO/IEC 42001（AIマネジメントシステム）の各規格・解説記事（2026年）
AI生成コードの著作権・オープンソースライセンス・IP補償に関する各種解説（Bloomberg Law、CIO ほか、2025〜2026年）
個人情報保護法・プライバシーマーク、EU AI Act、業種別ガイドライン（FISC／医療情報3省2ガイドライン等）の各公式情報
各AIプロバイダーのデータ保持／ZDR／HIPAA対応に関する公式ドキュメント（導入時に最新版を要確認）
導入企業の例に関する各種報道：Uber予算超過（Bloomberg / TechCrunch / The Information, 2026年4〜6月）、Microsoft Claude Code→GitHub Copilot CLI移行（The Verge, 2026年6月）ほか

※ 本記事は一般的な整理を目的としたものです。具体的な製品名・数値・契約条件は2026年央時点の一般情報であり、実際の導入にあたっては各ベンダーの最新の公式情報と自社の契約・コンプライアンス要件を必ずご確認ください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up