生成AIの利用が広がるほど、情報システム部門やセキュリティ部門が承認していないAIを、従業員が業務で使う「シャドーAI」は増えます。
個人アカウントの生成AIへ会議録を貼る。部門が独自にAIエージェントを作る。開発者が個人契約のコーディングAIに業務コードを読ませる。私物端末でローカルLLMを試す。いずれも現実に起こり得る利用です。
この問題を「未承認サービスを見つけて遮断すること」だけで扱うと、AI利用は見えない場所へ移るだけです。IT技術者が作るべきなのは、禁止リストではなく、誰が、どの機能を、どのデータに対し、どの責任で使えるかという運用の仕組みです。
シャドーAIは、責任分担が未設計であることの表れ
現場が未承認AIを使う理由は、必ずしもルール違反をしたいからではありません。公式環境では必要な機能が使えない、申請が遅い、相談先が不明、業務改善を求められている、といった事情があります。
IT部門が全AIサービスを調査し、全ユースケースを設計し、全問い合わせを引き受けることも現実的ではありません。一方で、部門が導入したAIの問題をすべてIT部門へ戻す運用では、管理者不在の「野良AI」が残ります。
必要なのは、全社共通の安全な経路をIT部門が提供し、部門固有の業務利用には利用部門にも運用責任を持ってもらう分業です。NISTのGenerative AI Profileが示す「Govern、Map、Measure、Manage」という考え方も、リスク管理を導入時だけでなく、役割・評価・継続運用までつなげるための枠組みになります。
AIを「全社AI・部門AI・個人AI」に分ける
すべてのAIを同じ審査に通すと、低リスク利用まで遅くなります。反対に、すべてを現場判断にすると、データと権限の統制が崩れます。まず、利用の置き場所を三つに分けます。
| 区分 | 代表例 | 主な責任者 | 必要な統制 |
|---|---|---|---|
| 全社AI | 全社員向けチャット、議事録作成、社内文書検索 | IT部門・セキュリティ部門 | SSO、アカウント管理、監査ログ、データ処理条件、問い合わせ窓口 |
| 部門AI | 営業の提案支援、人事の求人票作成、開発のコードレビュー | 利用部門 + IT部門 | 業務責任者、データ管理者、運用担当、利用範囲、廃止手順 |
| 個人AI | 新モデルの試用、ローカルLLM検証、先端的なコーディング支援 | 利用者・部門長 | 目的・期間・データ範囲の限定、教育、結果の共有、いつでも停止可能な構成 |
部門AIでは、IT部門が認証、ネットワーク、セキュリティ基準を支援し、出力の妥当性、業務手順、日常問い合わせ、部門教育は利用部門が担う、といった線引きを導入前に文書化します。作成者が異動・退職した時に、誰が所有権と管理権限を引き継ぐかも必須項目です。
製品名ではなく、AIが「何をできるか」で判定する
同じ製品でも、文書の下書き、社内検索、外部コネクター、AIエージェントはリスクが違います。「この製品は許可」「この製品は禁止」というだけでは不十分です。
| レベル | 機能 | 主なリスク | 導入時の最低条件 |
|---|---|---|---|
| 1 | 要約、翻訳、文面作成などの補助 | 入力データ、誤出力 | データ利用条件、出力レビュー、権限継承 |
| 2 | 汎用・社内チャット、コーディング支援 | 機密入力、著作権、誤情報 | 入力可否の基準、ログ、個人アカウントの制御 |
| 3 | ノーコードAI、RAG、ワークフロー作成 | 不適切なデータ公開、所有者不在 | データソースごとの認可、公開範囲、作成者と管理者の分離 |
| 4 | Computer Use、メール送信、ファイル更新 | 誤操作、情報送信、破壊的操作 | 隔離環境、操作範囲の制限、人間承認、停止手段 |
| 5 | モデル・データ・APIを組み合わせるAI開発基盤 | 権限昇格、サプライチェーン、監査不能 | IAM、ネットワーク、シークレット、評価・監査・復旧の一体設計 |
とくにレベル4以上は、チャットAIの延長として扱ってはいけません。AIが実行する操作は、誤った相手へのメール送信、データ更新、ファイル削除、外部送信につながります。OWASPのAgentic Applications向けTop 10は、エージェントが計画・判断・ツール実行を行う環境に固有のリスクを整理しています。導入時にはモデルの精度だけでなく、ツール、ID、権限、実行環境を評価対象にする必要があります。
申請で確認するのは「データ・権限・実行・影響」
利用申請者に詳細なセキュリティ設計を求める必要はありません。申請者は業務目的と利用データを書き、IT部門やAI CoEが共通の評価表で判定します。
| 評価軸 | 確認すること |
|---|---|
| データ | 個人情報、顧客情報、ソースコード、未公開設計、認証情報を扱うか。保存地域、削除、学習利用の条件はどうか |
| 認証・権限 | SSO・MFA・管理者機能があるか。個人アカウントを制御できるか。接続先権限は最小か |
| ログ・監査 | 利用者、参照データ、ツール呼び出し、操作結果、承認者を追跡できるか |
| 外部接続 | Web、API、メール、クラウドストレージ、プラグイン、MCPサーバーへ接続するか |
| 自律性 | 提案だけか、実行するか。実行回数・金額・時間に上限を置けるか。緊急停止できるか |
| 業務影響 | 顧客対応、支払い、採用・人事、契約、基幹システム、本番データを扱うか |
AIエージェントは、外部文書やメールに含まれる指示を誤って実行に結び付ける可能性があります。OWASPのExcessive Agencyでも、直接・間接のプロンプトインジェクションと、過剰な機能・権限・自律性の組み合わせが問題として説明されています。RAG文書やコネクター経由の情報も、信頼できない入力として扱います。
判定は4段階にして、利用者へ早く返す
長い審査文書では、現場が次に何をすべきか分かりません。評価結果は次の4段階で返すと、運用に乗せやすくなります。
| 判定 | 意味 | 例 |
|---|---|---|
| 許可 | 標準条件で利用できる | 公開情報の要約、人間が確認する前提のアイデア出し |
| 条件付き許可 | データ・部門・出力用途などを制限して利用できる | 承認済み環境だけでの社内一般情報の要約、外部送信なしのコード支援 |
| 検証環境限定 | 本番利用は認めず、隔離環境で安全性を確認する | Computer Use、顧客データアクセス、自律型エージェント、書き込みAPI連携 |
| 禁止 | リスクを管理できない | 契約・データ利用条件が不明なサービスへの機密入力、秘密鍵の入力、無承認の外部送信 |
大切なのは、禁止だけを通知して終わらせないことです。条件付き許可にできるなら必要な条件を、検証環境限定なら試せる場所と再評価基準を、利用者へ同時に示します。
シャドーAIを可視化し、価値のある利用を公式化する
私物端末やモバイル回線まで含めた完全検知は不可能です。それでも、企業管理下の端末・ネットワーク・SaaSでは、利用状況を相当程度可視化できます。
- SWG、SSE、CASB、DNSフィルタリングで、AIサービスへのアクセスと異常なアップロードを把握する
- EDR・端末管理で、未承認アプリ、ブラウザ拡張、ローカルLLM実行環境、大量ファイル読み取りを把握する
- Microsoft 365やGoogle Workspaceなどの管理機能で、AI機能と外部コネクターの追加状況を確認する
- 四半期ごとの簡易申告で、個人契約のAI、利用目的、扱うデータ、自動化している業務、現場が欲しい機能を集める
検知した利用の扱いは、リスクで分けます。機密情報の外部送信、管理不能なエージェント、個人情報の無承認入力、大量データのアップロードは即時停止してインシデントとして扱います。一方、少人数の試用で明確な業務効果があり、企業向け契約や管理機能が利用できるなら、目的とデータを確認したうえで部門AIまたは全社AIへ移行させます。
可視化の目的は違反者を探すことではありません。現場が必要としているAI利用を把握し、安全な標準環境へ取り込むことです。
エージェントとComputer Useは、読み取り専用から始める
エージェントにいきなり本番書き込み権限を渡してはいけません。検証は次の順番で進めます。
- まずは参照だけを許可し、更新・削除・送信は許可しない。
- 本番の顧客情報ではなく、架空またはマスキング済みのテストデータを使う。
- 接続先のWebサイト、フォルダ、API、コマンドを許可リストで限定する。
- メール送信、ファイル削除、データ更新、支払いなどは、人間の承認を必須にする。
- 1回の処理数、1日の実行回数、APIコスト、処理時間、同時実行数に上限を設ける。
- 実行を直ちに止めるキルスイッチと、トークン失効、ロールバックの手順を用意する。
- 判断材料、ツール呼び出し、実行結果、データ変更、承認者を時刻付きで記録する。
ここで必要なのは「AIが出した回答」の保存だけではありません。AIが何を参照し、どの権限で、どのツールを呼び、何を変更したかを追跡できる操作証跡です。
90日で作る、最初の運用サイクル
完成形を待つと、統制は常に利用実態に遅れます。最初の90日で、最小限のサイクルを動かします。
| 期間 | 実施すること | 成果物 |
|---|---|---|
| 1〜30日 | 責任者の決定、既存契約とアクセス実態の確認、部門アンケート、高リスク利用の一時停止 | AI利用台帳の初版、緊急対応基準 |
| 31〜60日 | 全社・部門・個人の分類、リスク評価表、入力禁止データ、申請と対応フローの確定 | AI利用申請書、4段階の判定基準、責任分担表 |
| 61〜90日 | 公式AIの明示、申請受付、アクセス監視、部門責任者の登録、検証環境、利用者研修 | 承認済みAI一覧、監視・棚卸しの運用、エージェント検証手順 |
その後は四半期ごとに、利用者数、利用目的、入力データ、新しい機能・コネクター、契約コスト、責任者の在籍、インシデント、代替可能な標準サービスを見直します。契約だけ残ったAIや、作成者がいないエージェントを放置しないことが重要です。
IT部門が提供すべき標準テンプレート
責任を部門へ渡すだけでは、実務は回りません。IT部門は、現場が安全に試して育てられる共通部品を用意します。
- AI利用申請書：サービス名、目的、利用者、データ、接続先、実行操作、期間、責任者、停止方法
- AIリスク評価表：データ、権限、外部接続、自律性、業務影響の判定
- 部門AI責任表：部門責任者、管理者、データ管理者、問い合わせ・障害時の連絡先
- AIエージェント設計書：ツール、権限、実行上限、承認点、ログ、キルスイッチ、復旧方法
- プロンプト・データ取扱基準：入力可否を情報区分別に示す
- 出力レビュー表：正確性、個人情報、著作権、偏り、外部公開可否を確認する
- AI廃止手順：アカウント、APIキー、データ、コネクター、エージェント、契約の停止・削除を確認する
結論：IT部門は門番ではなく、安全な通路を作る
シャドーAIをゼロにすることは現実的ではありません。しかし、見えない利用を可視化し、危険な利用を止め、価値のある利用を正式な仕組みに移すことはできます。
そのためには、製品名による一律判断をやめ、データ、権限、実行、業務影響でリスクを評価する必要があります。低リスクな利用は早く進め、高リスクなAIエージェントだけに厳格な隔離、最小権限、承認、操作ログ、停止・復旧を求めます。
AIガバナンスの目的は、AIを使わせないことではありません。現場が安全に、速く、責任を持ってAIを使える運用を設計することです。
作成日: 2026年6月19日
更新日: 2026年7月22日