LLM利用の最低限ルール -- 秘密情報の扱い、社内LLMの使い分け、必須チェック項目
LLMの利用で直面するリスクは大きく5つに分類できる。どれかひとつでも見落とすと、導入後にプロジェクト停止や社会的信用の失墜につながりかねない。
リスクの大きさは「発生確率 x 影響度」で評価する。情報漏洩と攻撃は影響度が高く、優先的に対策すべき領域となる。
社内データを4段階に分類し、利用するLLMの形態ごとに可否を判断する。この表を社内に掲示しておくだけでも、不用意な情報漏洩を防げる。
| 機密度レベル | データ例 | 外部API (GPT, Claude等) |
社内LLM (Private Endpoint) |
ローカルLLM (Ollama等) |
|---|---|---|---|---|
| 極秘 | 顧客個人情報、パスワード、APIキー、財務データ（未公開） | 禁止 | 条件付可 | 利用可 |
| 社外秘 | 社内戦略文書、契約書ドラフト、人事評価 | 禁止 | 利用可 | 利用可 |
| 社内限定 | 社内マニュアル、議事録、設計文書 | 条件付可 | 利用可 | 利用可 |
| 公開 | 公開ドキュメント、OSSコード、一般的な質問 | 利用可 | 利用可 | 利用可 |
外部APIを「条件付可」とする場合、以下をすべて満たす必要がある。
| 条件 | 確認事項 | 確認方法 |
|---|---|---|
| 学習データ不使用の契約 | API利用規約にオプトアウト条項があるか | 利用規約の該当条文を法務に確認 |
| データ保持期間の明示 | 入力データが何日保持されるか | プロバイダーのDPA（Data Processing Agreement）を確認 |
| PII除去の実施 | 送信前に個人情報をマスキングしているか | DLPツールまたはプリプロセッサのログ確認 |
| 管理者承認 | 上長またはセキュリティ担当の承認を得ているか | 承認フロー（メールまたはチケット）の記録 |
LLMアプリケーションへの攻撃手法は急速に進化している。守る側は攻撃パターンを理解し、多層的な防御を構築する必要がある。
| 攻撃種別 | 手法 | 目的 | 深刻度 |
|---|---|---|---|
| Direct Prompt Injection | ユーザー入力にシステムプロンプトを上書きする指示を埋め込む | システムプロンプトの漏洩、指示の改ざん | 高 |
| Indirect Prompt Injection | 外部データソース（Webページ、ドキュメント）に悪意ある指示を仕込む | RAGやブラウジング経由で間接的にLLMを操作 | 高 |
| Jailbreak | ロールプレイや仮定の質問で安全フィルタを迂回 | 禁止されたコンテンツの生成 | 中 |
| Training Data Extraction | 特定のプロンプトパターンで学習データを引き出す | 学習データに含まれる機密情報の漏洩 | 中 |
| Unbounded Consumption | 極端に長い入力、大量リクエスト、計算量の多い指示を投入 | リソース枯渇によるサービス停止、予期しないコスト暴走 | 中 |
単一の防御策では突破される。入力、処理、出力の3層で対策を重ねることが必須。
どのLLM環境を使うべきかは、データの機密度、予算、求める精度の3軸で決まる。以下のフローに沿って判断すれば迷わない。
4つのデプロイ形態をコスト、セキュリティ、精度、運用負荷の4軸で比較する。自社の要件に合った形態を選ぶ判断材料として使ってほしい。
GPUサーバーの調達が必要なVPC内/オンプレミスは、初期投資が数百万円~数千万円規模になる。一方でランニングコストは大量利用時にはAPIよりも安くなるケースがある。損益分岐点を試算してから判断すべき。
AI生成物の著作権は国・地域によって法解釈が異なり、判例も発展途上にある。現時点で取るべきスタンスを整理した。
| 観点 | 現状の主流的見解 | 対応方針 |
|---|---|---|
| AI生成物の著作権帰属 | 人間の創作的関与がなければ著作権は発生しない（日米共通の傾向） | 人間が実質的に関与した記録を残す |
| 学習データの適法性 | 日本の著作権法30条の4で一定の機械学習は許容。ただし「享受目的」は不可 | 利用するモデルのトレーニングデータポリシーを確認 |
| 出力のライセンス汚染 | GPLやCopyleftライセンスのコードが混入するリスクあり | 出力コードのライセンスチェックツールを導入 |
| 社内ポリシーとの整合 | 多くの企業がAI利用ポリシーを策定中 | 法務部門と連携し、自社ルールを明文化 |
以下のテンプレートをベースに、自社の状況に合わせてカスタマイズすることを推奨する。法務・情シス・事業部門の三者で合意を取って策定する。
LLM経由で情報漏洩が発覚した場合、速度が勝負になる。初動の遅れが被害を拡大させる。以下は発覚から再発防止までの一連の流れ。
| フェーズ | 目標時間 | 実施事項 | 担当 |
|---|---|---|---|
| 検知・報告 | 即時 | 異常を発見した時点でセキュリティチームに一報。ログを保全。当事者へのヒアリング開始 | 発見者 + セキュリティチーム |
| 初動対応 | 30分以内 | 対象サービスの利用停止。APIキーの無効化。影響を受けた可能性のあるアカウントの一時凍結 | セキュリティチーム + 情シス |
| 影響調査 | 24時間以内 | 送信データの特定。影響を受けた顧客・データの範囲確定。LLMプロバイダーへのデータ削除要請 | セキュリティチーム + 法務 |
| 報告 | 72時間以内 | 経営層への報告。個人情報保護委員会への報告（該当する場合）。顧客への通知判断 | CISO + 法務 + 広報 |
| 再発防止 | 1-2週間 | 原因分析（RCA）の実施。利用規程の改訂。技術的対策の追加導入。全社周知と再教育 | 全関係部門 |
以下の項目を四半期に1回確認する。チェック結果は記録として残し、経営層にレポートする。
OWASPがLLMアプリケーション固有のセキュリティリスクをTop 10として整理している。2025版は2023年の初版から大幅に改訂され、LLMエージェントの普及やRAGの一般化を反映した内容に刷新された。自社のLLMアプリケーションがこれらに対応できているか、定期的に確認すべき。
OWASP Top 10 for LLM Applications は2025版（v2025）が最新。2023年の初版から、System Prompt Leakage と Vector and Embedding Weaknesses が新たに追加され、Model DoS は Unbounded Consumption（コスト暴走を含む）にリネームされた。LLMの進化に伴い項目は更新されるため、年次での見直しを推奨する。