エンジニアが押さえるAIリスク7分類 情報漏洩対策と社内ガバナンスの作り方

禁止しても現場は使います。VPNの外から個人アカウントで使うだけなので、禁止令はリスクを見えない場所に移すだけ。だから最初にやることは、止めることではなく「どこまでなら安全か」の線を引くことです。

そしてその線は、法務ではなくエンジニアにしか引けません。どのデータがどのテナントに流れ、どのログに残るかを理解しているのは実装側だけだからです。

エンジニアのAIリスクとは何か

エンジニアのAIリスクとは、AIツールの利用によって「機密情報が社外に出る」「壊れた成果物が本番に入る」「法規制や契約に違反する」の3つが起きる可能性のことです。営業部門のリスクが主に1つ目に集中するのに対し、開発現場は3つ全部を同時に踏みます。

理由は単純で、エンジニアが扱う入力が重いから。ソースコード、DBスキーマ、本番ログ、顧客の個人情報を含むテストデータ。どれも「AIに貼れば早い」ものばかりです。

しかも出力もそのまま資産になります。営業資料の誤字は直せば済みますが、生成コードの脆弱性は数年残る。

ここを分けて考えないと、対策が「入力を禁止する」だけの片肺になります。次のセクションで、実務で起きる形に分解します。

現場で起きるリスクの7分類

まずは全体像を1枚で押さえます。以下は開発組織で実際に報告されやすい順に並べた分類表です。

つまり、7つのうち技術的に手を打てるものが5つあります。規程だけで解決するのは1と7の半分だけ。

以降は影響の大きい順に、実装レイヤーの話へ降りていきます。

情報はどこから漏れるのか？

漏洩経路は「入力」だけではありません。エンジニアが見落とすのは、むしろ入力以外の3経路です。

• 入力: 指示文（AIへの指示文のこと）に貼った本番データ
• 保持: ベンダー側に残る会話履歴とその保存期間
• 拡張: ブラウザ拡張やIDE拡張が読み取るファイル範囲
• 連携: 社内資料を読ませる仕組み（RAG、社内文書をAIに読ませて答えさせる方式）が拾いすぎる権限

3つ目と4つ目が厄介です。エディタ拡張は開いているファイルだけでなく、リポジトリ全体を文脈として送る設定を持つことがあります。既定値のまま入れると、.envや鍵ファイルが文脈に混ざる。

社内文書を読ませる仕組みも同じ穴を持ちます。人事フォルダの権限設定を継承していない検索基盤を作ると、平社員の質問に給与テーブルが答えとして返る。権限の継承漏れは、AI導入で初めて表面化する典型例です。

対策は3行で済みます。学習への利用を既定でオフにする、保持期間を最短にする、拡張の読み取り範囲を明示的に絞る。

漏れる経路が分かったところで、コード生成に固有の落とし穴へ進みます。

コード生成AIだけが持つ固有のリスク

コード生成には、文章生成にはない3つの固有リスクがあります。ライセンス、依存関係、そしてレビュー崩壊。

ライセンスから。学習データに含まれるOSSと似た出力が生成されると、コピーレフト条項（改変物も同じライセンスで公開する義務）を持つコードが混ざる可能性が残ります。主要な法人向けサービスは著作権侵害の申し立てに対する補償制度を用意していますが、補償の条件に「提供元のフィルタ機能を有効にしていること」が入るのが通例。フィルタをオフにした状態は保護の対象外になります。

次に依存関係。AIが実在しないパッケージ名を自信満々に提案することがあり、攻撃者がその名前を先回りして公開する手口が知られています。提案された名前をそのままinstallすると、悪意あるコードを自分で招き入れる形になる。

対策は導入前の実在確認だけです。公開日、メンテナ、ダウンロード数の3点を見れば大半は弾けます。

3つ目のレビュー崩壊が、いちばん静かに効きます。生成量が増えるとPRの行数が膨らみ、レビュー時間が週数時間では追いつかなくなる。読み切れないPRは形式承認になり、結果として品質ゲートが実質的に消えます。

つまり、生成速度を上げた分だけレビュー側に投資しないと、品質は必ず下がります。速度の利得をレビュー体制に再投資する。ここが分岐点。

プロンプトインジェクションとエージェントの暴走

指示の乗っ取り（プロンプトインジェクション）とは、AIに読ませた文章の中に指示文を仕込み、本来の命令を上書きする攻撃です。メール本文、Webページ、PDF、Issueのコメント。AIが読むものすべてが攻撃面になります。

危険度が跳ね上がるのは、AIに「手」を持たせたときです。ファイル操作、コマンド実行、外部APIの呼び出し。読むだけなら誤答で済んだものが、実行権限を持つと実害に変わります。

ここまでの整理: 情報漏洩は入力・保持・拡張・連携の4経路。コード生成はライセンスと依存関係とレビュー崩壊。エージェントは権限の大きさがそのまま被害の上限になります。ここまでが技術側の話で、ここから先が規制と社内ルールの話です。

実装で守るべき線は3本あります。外部から取り込んだ文章を命令として解釈しない構造にすること。実行できるコマンドを許可リスト方式にすること。外部送信を伴う操作には人の承認を挟むこと。

3本目を省いた自動化は、監視のない本番権限と同じ意味を持ちます。エージェント設計の考え方はAIエージェントのカテゴリ一覧で扱っているツール群の設計思想が参考になります。

権限の話が済んだので、外側の規制へ移ります。

規制は現場に何を要求してくる？

新しいAI規制より先に、既存法が効きます。エンジニアが最初に確認すべきは個人情報保護法と不正競争防止法です。

個人情報を含むデータをAIサービスに入れる行為は、多くのケースで「委託」または「第三者提供」に当たります。海外事業者のサービスなら越境移転の論点も乗る。ここで必要になるのは、委託先の安全管理措置の確認と記録です。

営業秘密のほうはもっと直接的。不正競争防止法で保護される営業秘密には「秘密として管理されている」ことが条件になります。誰でも自由に外部AIへ貼れる状態は、この秘密管理性を自ら崩す行為になりかねません。

つまり、国内企業の大半にとって当面の実務は「既存法の体制をAI利用にも延長する」ことに尽きます。ゼロから作る話ではありません。

EU向けにサービスを出しているなら話は別です。EUのAI法は公式の適用スケジュール上、2026年8月から高リスク用途への義務が段階的に効く局面へ入っています（2026年8月時点）。自社プロダクトが採用選考や与信に関わるなら、用途分類の棚卸しは待ったなしです。

法令の輪郭が見えたので、判断に迷いやすい3領域の線引きへ進みます。

個人情報・営業秘密・著作権の線引き

現場で毎日発生する判断は、この3つに集約されます。基準を1枚にしておくと、都度の相談が消えます。

個人情報: 顧客の氏名・メール・IPアドレスを含むログは、そのままでは外部AIへ入れない。マスキング済みか、法人契約でデータ保持と学習利用が止まっているテナントのみ許可する。

営業秘密: 未公開の設計、価格ロジック、アルゴリズムのコアは承認ツール以外に出さない。ここは例外を作らないほうが運用が楽です。

著作権: 生成物そのものより、素材の出所が問題になります。画像生成なら特に。学習元の権利処理を公表しているサービスかどうかで、商用利用時のリスクが変わります。判断材料はAIイラスト生成ツールの比較記事にツールごとの商用利用条件をまとめてあるので、社内素材の方針を決める前に読むと早いです。

外に出せない素材を扱うなら、そもそも社外に送らない選択肢もあります。ローカル環境で動かす構成の実像はComfyUIとStable Diffusionの比較が分かりやすい。GPUコストと引き換えに、データが社外へ出る経路をゼロにできます。

3領域とも、線引きの原則は同じ。「出した後に取り消せるか」で判断する。取り消せないものは出さない。

線が決まったら、それを組織で回す仕組みが要ります。

社内ガバナンスは何から作れば動く？

分厚いAI利用規程から作ると、まず読まれません。最初の90日で置くべきは4点だけです。

1. データ分類: 貼ってよい情報と、絶対にだめな情報の2択にする
2. 承認ツール一覧: 使ってよいサービスを名指しで列挙する
3. 監査ログ: 誰がどのツールを使ったかを管理側で見られる状態にする
4. 事故報告経路: 「やらかした」を30秒で報告できる窓口

分類を5段階にした瞬間に運用は死にます。現場が覚えられる粒度は2段階。

利用ルールに最低限書く項目を表にしました。これ以上増やすと形骸化します。

つまり、規程の厚さではなく「例外申請の受け皿があるか」が定着を決めます。逃げ道のないルールは、隠れて破られるだけ。

監査側の視点も入れておくと通りが早くなります。内部監査部門がAIをどう見ているかは内部監査向けAIツールの記事が参考になります。監査が求めるのは技術的な完璧さではなく、記録が残っていること。ここを最初から満たしておくと後で楽です。

ルールが決まれば、あとはツール選定の技術要件です。

ツール選定で技術者が見るべき項目

営業資料の機能一覧ではなく、管理画面と契約条件を見ます。判断を分ける項目は次の10個。

つまり、無料プランで検証して法人プランで本番運用する流れが基本形になります。無料と有料でデータの扱いが変わる点を見落とさないこと。

コーディング支援ならGitHub CopilotやCursor、汎用の対話ならClaudeやChatGPT、既存のOffice環境と揃えるならMicrosoft 365 Copilot。どれも法人プランに管理者向け機能が揃っています。選定基準の考え方はAIセキュリティ関連ツールのランキング側の評価軸と合わせて見ると精度が上がります。

社外情報を調べる用途を分けるのも有効です。調査は出典が追えるサービスに寄せると、誤情報の混入が減ります。出典表示型の使い勝手はFeloの完全ガイドが詳しい。

ツールを決めたら、決めた枠の外で起きていることに目を向けます。

シャドーAIはなぜ止まらないのか？

会社が承認したツールが遅い、または使いにくいから。理由の9割はこれです。

国内ITエンジニア435人を対象とした2026年5月の調査では、生成AIに月15,000円以上を自費で払う層が前年の約2.7倍に増えていました。自腹を切ってでも使いたい人がこれだけいる状況で、禁止だけを積み上げても意味がない。

個人契約が広がると何が起きるか。会社は利用実態を一切見られなくなり、退職時にアカウントも履歴も回収できません。会話ログに設計の中身が残ったまま、管理外の場所に置かれ続けます。

消費者向けのAIが業務端末に混ざるのも同じ構図です。SNSやメッセージアプリに統合されたAIは、業務の話を私的な文脈へ持ち込む入口になります。統合型AIの挙動はMeta AIのガイド記事で整理しているので、端末ポリシーを決める前に一読しておくと判断が早い。

止め方は3手。承認ツールを現場が本当に使いたいレベルのプランで配る。個人利用のニーズを聞いて承認リストを毎月更新する。それでも足りない分は例外申請で吸い上げる。

取り締まりではなく供給。ここを間違えると、可視性は永久に戻りません。

事故が起きたときの初動48時間

漏らした事実より、初動の遅れのほうが後で高くつきます。手順を先に決めておくこと。

最初の2時間でやるのは範囲の特定です。誰が、どのサービスの、どのアカウントに、何を入れたか。スクリーンショットではなく、管理画面の利用ログで確認します。

次の6時間はベンダー対応。会話履歴の削除要請、保持期間の確認、学習に使われたかどうかの回答取得。法人契約なら窓口が用意されています。

24時間以内に法務判断へ渡します。個人データが含まれるなら報告義務の検討に入る。個人情報保護委員会への報告は、速報がおおむね3〜5日以内、確報が原則30日以内という枠組みで運用されています（2026年8月時点）。この期限から逆算すると、社内での判断に使える時間は実質2日しかありません。

つまり、48時間の枠を先に切っておけば、事故は事件になりません。準備がない組織だけが、報告期限の直前に慌てます。

AI PICKS編集部の判定

エンジニアのAIリスク対策として、いま投資効果が圧倒的に高いのは「監査ログが取れる法人プランへの一本化」です。ここに尽きます。規程の作り込みは後でいい。

理由は3つ。まず、可視化されていないリスクには手の打ちようがないから。次に、法人プランなら学習利用オフとデータ保持期間の設定がまとめて片づくから。そして退職者のアカウント回収がSSO側で自動化できるから。1人あたり月数千円の追加費用で、この3つが同時に解決します。

逆に正直イマイチなのが、全面禁止と分厚い利用規程の2つ。禁止は個人契約への地下化を招くだけで、リスクの総量は変わりません。むしろ見えなくなる分だけ悪化します。20ページの規程も同じで、読まれない文書は統制ではなく免罪符です。

技術者として譲ってはいけない線は1本だけ。AIに実行権限を渡すときは、外部送信と破壊的操作の前に人の承認を挟むこと。ここを省いた自動化は、いずれ必ず高い授業料を払わされます。

順序としては、承認ツールの整備が先、ルールの明文化が後。この順番を逆にした組織が、いちばん長く迷走します。

よくある質問（FAQ）

Q. 社内でAI利用を全面禁止するのは有効ですか？

有効ではありません。個人端末や個人アカウントでの利用に移るだけで、会社側の可視性がゼロになります。承認ツールを配って利用を集約するほうが、結果的にリスクは下がります。

Q. 無料プランを業務で使ってはいけない理由は？

無料プランは会話内容が学習に使われる設定が既定になっているサービスがあり、管理者が利用ログを確認する手段もありません。検証目的なら問題ありませんが、業務データを入れる用途には向きません。

Q. 生成したコードの著作権は誰のものになりますか？

生成物そのものの権利より、既存コードとの類似が実務上の論点になります。法人向けサービスの多くが著作権侵害の申し立てに対する補償を用意していますが、提供元のフィルタ機能を有効にしていることが条件になるのが通例です。設定をオフにしないこと。

Q. AIが提案したパッケージをそのまま入れても平気ですか？

平気ではありません。存在しないパッケージ名が提案されることがあり、その名前を狙って悪意あるパッケージが公開される手口が知られています。公開日、メンテナ、利用実績の3点を確認してから入れてください。

Q. 個人情報を含むデータをAIに入れるとどうなりますか？

多くの場合、委託または第三者提供に当たります。委託先の安全管理措置の確認と記録が必要になり、海外事業者なら越境移転の整理も加わります。マスキングして入れるのが実務上いちばん安全です。

Q. 小規模なチームでもガバナンスは必要ですか？

必要です。ただし作るのは4点だけでいい。データ分類、承認ツール一覧、監査ログ、事故報告経路。10人のチームなら1日で作れます。

Q. AIエージェントに本番環境の権限を渡してもよいですか？

読み取り専用までにしてください。書き込みや削除を伴う操作、外部への送信は人の承認を挟む設計が原則です。権限の大きさが、そのまま事故の被害額の上限になります。

Q. 規制対応は法務に任せておけばよいのでは？

任せきりにすると判断がずれます。どのデータがどのテナントへ流れ、どこにログが残るかを説明できるのは実装側だけです。法務が判断できる材料を出すところまでが、エンジニアの仕事になります。

あわせて見たいツール・カテゴリ

社内のAI利用を安全側に寄せるとき、次に見ておきたい入口をまとめました。

• AIセキュリティ関連ツールのランキング — 監査ログや権限管理の実装状況を評価軸ごとに比較できます
• セキュリティ系AIカテゴリ — 検知・監視・脆弱性診断まわりの選択肢を一覧で確認できます
• AIコーディング支援カテゴリ — 法人プランの管理機能を持つ開発支援ツールが揃っています
• Claude — 長い設計文書やコードレビューの読み込みに向いた対話型AI
• GitHub Copilot — 組織単位のポリシー設定と重複コードフィルタを備えた実装支援
• Cursor — リポジトリ全体を文脈にする分、読み取り範囲の設定確認が要るエディタ
• Microsoft 365 Copilot — 既存の権限設計をそのまま引き継ぐ社内文書向けの選択肢
• AIエージェントカテゴリ — 権限設計を検討する前に、実行系ツールの挙動を把握しておくと安全です

次に読むならこれ。監査の目線でAI利用の記録を整える話は内部監査向けAIツールの記事にまとまっています。ガバナンスを作る側に回るなら、監査が何を見るかを先に知っておくほうが、手戻りが減ります。

各ツールの公式サイト（一次情報）

料金・機能・対応範囲は各社公式が一次情報です。本記事は公開時点の検証に基づきますが、最新かつ正確な条件は必ず各公式ページで確認してください。

• GitHub Copilot — 公式サイト（AI PICKSの詳細）
• Cursor — 公式サイト（AI PICKSの詳細）
• Claude — 公式サイト（AI PICKSの詳細）
• ChatGPT — 公式サイト（AI PICKSの詳細）
• Microsoft 365 Copilot — 公式サイト（AI PICKSの詳細）