AI利用を前提にしたサイバーセキュリティ点検リスト｜生成AI時代の情シス防衛実務
目次
1. AI利用を前提にしたセキュリティ点検が必要な理由
生成AIは、社内の業務効率化や開発支援に欠かせない道具になりつつあります。文章作成、問い合わせ対応、議事録、社内検索、コード生成、AIエージェントによるワークフロー実行など、利用範囲は広がっています。一方で、AIを導入した会社ほど、従来のサイバーセキュリティ点検だけでは守りきれない領域が増えています。
これまでのセキュリティ対策は、端末、ネットワーク、クラウド、ID、脆弱性、マルウェア、メール攻撃を中心に組み立てられてきました。もちろんそれらは今も重要です。しかし生成AIが社内データを読み、外部サービスへ問い合わせ、ツールを実行し、コードを生成するようになると、「AIに何を入力してよいか」「AIがどの情報を参照できるか」「AIの出力をどこまで信頼するか」「AIが誤った操作をしたときにどう止めるか」もセキュリティの対象になります。
NISTのAIリスク管理フレームワークやOWASPのLLM向けTop 10でも、生成AIは通常のWebアプリとは違うリスクを持つことが整理されています。特にプロンプトインジェクション、機密情報の漏えい、過剰な権限、検索データの汚染、出力の不適切な利用は、AI利用が広がるほど現実的な問題になります。
この記事では、AI利用を禁止するためではなく、安全に使い続けるための点検リストとして、情シス・DX推進担当者が見直すべき項目を整理します。
2. 従来の点検だけでは見落とすAI特有のリスク
AIセキュリティで最初に理解したいのは、AIへの攻撃は「侵入」だけではないという点です。悪意ある入力、外部文書に埋め込まれた指示、汚染されたナレッジ、過剰なツール権限、検証されていない出力が、業務上の事故につながります。
たとえば、社員がAIに社内規程を要約させるだけならリスクは限定的に見えます。しかし、そのAIが社内ファイル検索やSaaS操作までできる場合、外部ページやメール本文に埋め込まれた指示によって、AIが本来読むべきでない情報を参照したり、意図しない処理を実行したりする可能性があります。これは従来のURLフィルタやEDRだけでは十分に見えない領域です。
また、AIコーディングでは、生成されたコードに脆弱性が混ざることがあります。AIが提案したライブラリ、設定、認証処理、入力検証をそのまま採用すると、開発速度は上がってもリスクが残ります。AIによる業務効率化は、レビューとログを省略する理由にはなりません。
AI利用時代の点検範囲は、端末やネットワークだけでなく、入力データ、検索対象、モデル、ツール権限、出力利用、監査ログまで広がります。
3. 情シスがまず確認すべき8つの点検項目
AI利用を前提にした点検では、すべてを一度に完璧にする必要はありません。まずは、社内でどのAIが使われ、どのデータが入り、どの業務に影響しているかを見える化することが出発点です。特に中小企業では、厳密な統制よりも、使われている実態を把握し、危険な使い方を減らすことが現実的です。
| 点検項目 | 確認すること | 放置した場合のリスク |
|---|---|---|
| AI利用状況 | 利用ツール、部署、用途、外部サービスの有無 | シャドーAI、契約外利用、情報管理の抜け漏れ |
| 入力データ | 個人情報、顧客情報、契約情報、ソースコードの入力可否 | 機密情報の外部送信、監査不能なデータ持ち出し |
| アクセス権限 | AIが参照できる文書、SaaS、ファイル、API | 権限外参照、過剰権限、内部情報の誤露出 |
| 出力利用 | AI出力のレビュー、承認、転記先、公開範囲 | 誤情報の業務利用、脆弱なコードの混入 |
| RAG・社内検索 | 検索対象文書、更新頻度、除外文書、権限反映 | 古い規程の回答、検索データ汚染、情報漏えい |
| AIエージェント | 実行できる操作、停止条件、承認フロー | 意図しない実行、外部送信、業務停止 |
| ログ・監査 | 入力、出力、参照文書、実行履歴、閲覧権限 | インシデント調査不能、責任分界の曖昧化 |
| 教育・ルール | 禁止事項、相談窓口、例外申請、更新頻度 | 現場判断に依存し、危険な利用が定着する |
この表は、セキュリティ部門だけのチェックリストではありません。法務、人事、経理、営業、開発など、AIを使う部署と一緒に確認する必要があります。AIのリスクは技術だけでなく、業務データ、社内ルール、承認フローにまたがるためです。
4. AIエージェントとRAGで強化すべき運用設計
AIチャットの利用だけなら、入力ルールと外部サービス管理である程度リスクを抑えられます。しかしAIエージェントやRAGを導入すると、点検すべき範囲は一段広がります。
RAGでは、AIが社内文書を検索して回答します。便利な一方で、検索対象に古い規程や権限外文書が混ざると、誤回答や情報漏えいにつながります。検索対象の文書は、最新版かどうか、部署別の閲覧権限が反映されているか、機密ラベルが付いているか、削除済み文書が残っていないかを確認する必要があります。
AIエージェントでは、AIがSaaS、ファイル、カレンダー、チケット管理、コードリポジトリなどを操作することがあります。この場合、AIに与える権限は「人間と同じ」では広すぎることがあります。読み取り、下書き、申請、承認、実行を分け、実行系の操作には人間承認や停止条件を入れるべきです。
ここで重要なのは、AIを信用するか疑うかという二択ではありません。業務リスクに応じて権限を分け、ログを残し、失敗したときに止められる状態にすることです。低リスクのFAQ回答と、顧客データの更新や外部送信を同じ統制で扱うと、過剰に不便になるか、逆に危険な抜け穴が残ります。
AIエージェント導入前の追加チェック
- AIが利用できるツール一覧を管理している
- ツールごとに読み取り、作成、更新、送信、削除の権限を分けている
- 外部メール送信、ファイル共有、決済、契約、顧客データ更新には人間承認がある
- 外部文書やWebページからの指示をそのまま実行しない設計になっている
- 実行ログ、参照ログ、承認ログをあとから確認できる
- 異常時にAI機能を止める手順と責任者が決まっている
5. インシデント対応をAI利用前提に更新する
AI利用が広がると、インシデント対応の見方も変わります。従来は、不正ログイン、マルウェア感染、情報漏えい、メール誤送信などを中心に調査していました。生成AIやAIエージェントが関わる場合は、AIが何を入力として受け取り、どの文書を参照し、どの出力を生成し、どのツールを実行したかを確認する必要があります。
もしログが残っていなければ、AIが意図しない回答をしたのか、利用者が誤った情報を入力したのか、外部文書の指示に影響されたのか、権限設定が間違っていたのかを判断できません。AIセキュリティでは、事故を完全に防ぐだけでなく、起きたときに原因を特定し、再発防止につなげる証跡が重要です。
AI関連インシデントでは、通常の端末・ID調査に加えて、入力、参照文書、モデル回答、ツール実行、承認ログを時系列で確認します。
インシデント対応手順には、少なくとも四つの観点を追加しておくと実務で動きやすくなります。一つ目は、AI利用ログの保全です。該当ユーザー、対象AI、入力、出力、参照文書、実行ツール、時刻を確認します。二つ目は、影響範囲の把握です。AIが参照した文書や送信したデータが、どの部署や顧客に関係するかを見ます。三つ目は、一時停止です。危険なツール連携、外部送信、RAG検索、該当プロンプトテンプレートを必要に応じて止めます。四つ目は、再発防止です。権限、ナレッジ、プロンプト、教育、レビュー条件を更新します。
AI利用を前提にしたインシデント対応は、特別な大企業だけの話ではありません。社内AI検索、チャットボット、AI議事録、AIコーディングを使い始めた段階でも、最低限のログと停止手順は必要です。
6. OpenBridgeが支援できること
AIセキュリティは、生成AIを止めるための取り組みではありません。安全に使える範囲を広げ、現場が安心してAIを活用できる状態を作るための土台です。AI利用が増えるほど、便利さとリスクは同時に大きくなります。だからこそ、導入前の点検、権限設計、ログ設計、インシデント対応、社員教育をセットで考える必要があります。
OpenBridgeでは、生成AI活用支援、RAG構築、AIエージェント開発、社内AI利用ルール、AI利用ログ設計、業務システム連携まで支援しています。まずは現在使われているAIツールとデータの棚卸しから始め、リスクの高い業務には承認とログを入れ、低リスク業務では現場が使いやすい導線を作るのが現実的です。
AIを導入する企業にとって、サイバーセキュリティ点検は一度きりの作業ではありません。利用範囲、モデル、連携ツール、規制、攻撃手法が変わるたびに更新する運用です。情シスとDX推進担当が一緒に点検リストを持つことで、生成AIは「怖いから使わないもの」ではなく、「安全に育てていく業務基盤」になります。
この記事を書いた人
