企業AIプロジェクトの最初の100日 — セキュリティ・チェックリスト10項目
企業AIプロジェクトのPoCが「成功」と判定され本番化の号砲が鳴った瞬間、セキュリティ統制の空白地帯が生まれる。最初の100日間に整備すべき10項目を見落としたまま進んだプロジェクトが、データ漏洩・コンプライアンス違反・インシデント対応不能という三重苦に陥る構造を、CISOが実装可能な粒度で解体する。
背景
多くの企業では2023〜2024年にかけてChatGPT Enterprise・Azure OpenAI Service・Google Vertex AIなどのAPIを利用したPoCを走らせ、2025年前後に本番移行フェーズへ突入している。PoCはサンドボックス環境・限定ユーザー・匿名化済みデータで動かすため、セキュリティ上のリスクが顕在化しにくい。ところが本番化に際してリアル業務データが投入され、API連携が社内基幹システムへ伸び、利用者が数人から数百人へ拡大する。この「0日〜100日」の移行期は、ガバナンス文書の整備が追いつかないまま技術実装だけが先行するフェーズであり、業界横断のインシデント報告でも同期間への集中が確認されている。CISOがプロジェクトオーナーと対等に議論できる体制を最初の100日以内に確立できるかどうかが、以後の運用リスクを大きく左右する。
リスクの全体像
脅威モデルは四層で整理できる。①データ持込み層：社員が顧客PII・契約書・財務データをプロンプトに直接貼り付けるインシデントは、監査ログが存在しないと事後検知すら不可能になる。②ベンダー契約層：LLMプロバイダーとのDPA（Data Processing Agreement）が未締結のままAPI利用を開始すると、GDPRおよび個人情報保護法上の「第三者提供」が無断で発生しうる。③権限境界層：RAGパイプラインにおけるベクトルDB・ドキュメントストアのアクセス制御が甘い場合、本来参照不可の部署データを別部署のユーザーが間接的に取得できるプロンプトインジェクション経路が生じる。④インシデント対応層：AIシステム固有の異常（ハルシネーション起因の誤意思決定・モデル出力の改ざん）に対応できるPlaybookが未整備のまま本番化されるケースが大半である。
チェックリスト
- ①データ分類ポリシーのAI適用宣言：既存の情報資産分類規程（社外秘・機密・極秘）をLLMプロンプト投入可否に直接マッピングし、「機密以上はマスキング必須」等の条件を書面化する。PoCで使った匿名化ルールをそのまま引き継がずに再審査すること。
- ②LLMプロバイダーとのDPA・利用規約の法務確認：Azure OpenAI ServiceのData Privacy Addendum、Google CloudのData Processing Addendum等、各社固有の契約文書を法務と共同でレビューし、学習利用オプトアウト設定が有効化されているかをAPIキー単位で確認する。
- ③社内AIシステムのRBAC設計とRAGアクセス制御監査：ベクトルDBへのクエリはエンドユーザーの既存権限を継承する設計になっているか。Azure AI SearchであればDocument-level security trimming、PineconeであればNamespace分離の実装状況を確認し、権限昇格経路がないことをペネトレーションテスト相当の検証で担保する。
- ④プロンプト・レスポンスの完全ログ保管と保管期間定義：SOC 2・ISO 27001対応の観点からAPI呼び出しのinput/outputを最低90日（業種によっては7年）保管するパイプラインを構築する。Azure Monitor・CloudWatch Logsへの転送設定とSIEM連携を本番Go-Live前に完了させる。
- ⑤AIインシデント対応Playbook（IRP）の整備とTable-Top演習：既存のCyber IRPとは別に、「モデル出力に起因した誤判断が業務損害を生じた場合の第一報連絡先・エスカレーション先・ベンダー緊急連絡先・モデル差替え手順」を明文化し、Go-Live後30日以内にTable-Top演習を1回実施する。
- ⑥シャドーAI利用の検知体制（DLP・Proxy監視）：承認されていないOpenAI.com直接アクセスやClaude.aiへの業務データアップロードをProxyログおよびCASBで検知するルールを有効化する。検知後の通知・教育フローをHRと合意しておく。
- ⑦モデルバージョン管理と変更管理プロセスへの組込み：LLMのモデルバージョン更新（GPT-4oからGPT-4.1へ等）は出力品質・安全フィルタ挙動の変化を伴うため、既存のChange Advisory Boardの審査対象に明示的に追加する。自動アップデート設定が有効な場合は固定バージョン指定に切り替える。
- ⑧サードパーティプラグイン・Function Calling連携先の棚卸し：AIエージェントがFunction Callingで呼び出す外部API（社内ERP・CRM・メール等）を全列挙し、各連携先のOAuth Scopeが最小権限原則に従っているかを確認する。不要なWrite権限が付与されたままのケースが散見される。
- ⑨プロンプトインジェクション対策の実装確認：ユーザー入力をシステムプロンプトに直接連結する実装はインジェクション攻撃の温床になる。入力バリデーション・システムプロンプト分離・出力フィルタリングの3層が実装されているかをコードレビューで確認し、OWASP LLM Top 10（LLM01）への対応状況を文書化する。
- ⑩従業員向けAIセキュリティトレーニングの実施記録：「どのデータをAIに入力してよいか」を明示した社内ガイドラインを全ユーザーに周知し、受講記録を保管する。個人情報保護法・不正競争防止法（営業秘密）の観点から、トレーニング未実施者のシステムアクセスを本番Go-Liveの条件にすることが望ましい。
打ち手
優先順位は①契約・法務（②DPA確認）→②データ統制（①⑥）→③技術制御（③④⑧⑨）→④運用プロセス（⑤⑦⑩）の順で整備する。Go-Live前に必達とすべきは②③④⑨の4項目で、残りは本番稼働後60日以内の完了をマイルストーンに設定する。CISOはプロジェクトマネージャーと共同で各項目にオーナーを割り当て、週次ステアリングコミッティで未完了項目のリスク受容・猶予期限を経営層と合意する体制を構築する。
PoCの成功体験がセキュリティ統制の先送りを正当化する。
Omamori AI の結論
- 事実: 企業AIプロジェクトの最初の100日は、データ分類・ベンダーDPA・RAGアクセス制御・ログ保管・インシデントPlaybookという5つの統制基盤が未整備のまま本番稼働するケースが多く、この空白期間にセキュリティインシデントが集中している。
- 判断軸: 10項目のうち②⑨は法的義務（個人情報保護法・GDPRの第三者提供規制・OWASP LLM Top 10）に直結するため、リスク受容の余地がない。残りの項目はビジネスインパクトと実装コストのバランスで優先順位を付けてよいが、すべてGo-Liveから60日以内に完了させることを取締役会承認事項として扱う。
- 打ち手: CISOはGo-Live判定会議にセキュリティゲートチェックリスト（本記事の10項目）を正式な承認条件として提出し、未完了項目が存在する場合は経営者署名付きのリスク受容書を取得する。これにより善管注意義務上の説明責任を担保しつつ、事業スピードとセキュリティ統制のバランスを透明な形で経営層と共有できる。
経営者視点で考えるべきこと
取締役会がAI投資を承認する際、PoCの精度・コスト削減効果だけでなく、本番化後のセキュリティ統制コストをROI計算に含めているかが問われる。個人情報保護法違反（勧告・命令・公表）やGDPR違反（売上高4%または2,000万ユーロの制裁金）が現実のダウンサイドシナリオとして存在する以上、DPA未締結のままAPIを利用し続けることは善管注意義務違反の問題になりうる。また、AIシステム由来の誤意思決定が顧客・取引先に損害を与えた場合、製造物責任ではなくサービス提供責任として会社が問われるリスクも整理が必要である。事業継続性の観点では、LLMプロバイダーの障害・モデル廃止・利用規約変更が業務停止に直結する依存度になっていないかを四半期ごとにレビューする体制を取締役会レベルで要請することが、経営者としての実質的なリスク管理に相当する。
