- 公開日
シャドーAIを減らすには、未承認の利用を見つけて禁止を知らせるだけでなく、何の作業に必要とされ、公式の手段のどこで困っているかを確かめます。そのうえで、扱う情報と接続を管理できる利用経路へ移します。調査のために私的な会話まで無制限に集めるのではなく、目的を説明し、判断に必要な情報から段階的に把握することが大切です。
英国NCSCは、組織の承認されたシステムや手順に取り込まれていないAI利用を、シャドーAIとして説明しています。この定義に照らすと、無料の個人用サービスだけが対象とは限りません。有料サービスや既存業務アプリのAI機能でも、組織の承認と管理の外で使われていれば、確認の対象になります。
この記事は、シャドーAIの把握の方法（用途の調べ方と、公式の経路へのつなぎ方）を扱います。シャドーAIに気づいた後の最初の対応と、公式AIの利用手順の改善は「公式AIが使いにくいとき、統制を保ちながら利用手順を改善する」で解説しています。
利用者の不注意だけを原因にしない
未承認利用の理由は一つではありません。公式AIに必要なファイルを取り込めない、申請先が分からない、利用権限が届かない、業務アプリに追加されたAI機能を既存契約の一部だと思っていた、といった事情が考えられます。すべてを同じ「ルール違反」にまとめると、設定の問題と説明不足を切り分けられません。
NCSCのShadow ITガイダンスも、シャドーITの多くは悪意ではなく、承認済みの道具や手順で仕事を終えにくいことから生じると説明しています。そのうえで、利用者の要望に応える簡潔な申請手順を整え、非難しない姿勢で相談を受けることを勧めています。これは未承認サービスへの入力を追認する意味ではありません。既に問題のある情報を渡した疑いがある場合は、改善活動と事故対応を分けて進めます。
ここからは架空の営業企画部を例にします。担当者は提案書の構成案を作るため、個人用AIサービスを使っています。社内の公式AIは長い文書の処理方法が分かりにくく、相談先も見つけられなかったという設定です。この原因や利用結果を、実在する会社の調査結果として扱うものではありません。
何を調べ、誰が見るかを先に伝える
業務責任者が困り事を受け付け、情報システム担当が公式AIの制約を調べ、情報管理担当が入力データや接続のリスクを確認する役割にします。利用者から聞き取る前に、調査の目的、対象、閲覧できる担当、記録の保管と削除の方針を説明します。人事評価など別の用途へそのまま転用しない運用も定めます。
この部署への説明例は、「業務で使うAIの用途と、公式サービスで困る点を確認します。まずサービス名、業務目的、入力した情報の種類、接続した機能を教えてください。個人用アカウントのパスワードや私的な会話は提出しないでください。機密情報を入力した可能性がある場合は、一般の回答欄へ原文を貼らず、情報管理の相談窓口へ連絡してください」とできます。
調査目的を「安全のため」とだけ書くより、何を集めないかも具体的に示す方が、報告の範囲を揃えられます。ただし、組織の正式な方針がないのに「報告すれば処分されない」などと約束してはいけません。相談しやすさの確保と、承認された事故対応・服務上の手続は、それぞれ担当者が説明します。
| 最初に確認すること | この例で得た回答 | 次の判断に使う点 |
|---|---|---|
| 業務の目的 | 提案書の構成案を作りたい | 文章案の作成だけか、顧客への送信まで必要か |
| 入力する情報の種類 | 公開製品資料と社内の提案メモ | 個々の情報を当該サービスへ渡せるか |
| 利用経路 | 個人用アカウントのチャット画面 | 組織による契約・設定管理の範囲か |
| 外部連携 | 本人は連携を設定していないと回答 | 自己申告だけでなく必要に応じ設定を照合する |
| 公式AIで困ること | 長い文書をどう分けるか不明 | 機能不足、案内不足、権限不足のどれか |
ここで得たのは回答や記録であり、サービスの実設定や入力内容をすべて確認した結果ではありません。「本人が未設定と回答」と「接続なしを設定で確認済み」は区別します。原文を調べる必要が生じたら、対象資料と理由を限定し、権限のある担当者が管理された場所で確認します。
見つかった利用を、いきなり承認済みにしない
この例では、社内提案メモに顧客の非公開情報が含まれる可能性があり、入力の可否はまだ確認できないとします。情報管理担当は、その種類の情報を個人用サービスへ追加投入することを止め、何が、いつ、どこへ渡ったかを必要な範囲で確認します。サービス名が分かったことだけで漏えいを断定することも、学習利用を無効にしたという説明だけで問題なしにすることも避けます。
確認が済むまでは、当該サービスへの利用が認められると確認した材料だけを使うか、承認済み環境へ作業を戻します。「公開資料ならすべて入力できる」「社内で作ったメモなら会社が自由に使える」とは一律に決めません。資料に含まれる情報と、サービスの契約・設定・保存条件を、実際の用途に照らして確認します。
技術的な把握には、会社が管理する端末や接続の記録を使える場合もあります。しかし、あるサービスへ接続した記録から、どの文章を入力したかまで分かるとは限りません。記録がないことも未利用の証明にはなりません。調査できる範囲と見えていない範囲を記し、私物端末や個人アカウントへ無断で調査範囲を広げないようにします。
業務上必要な確認であっても、収集・閲覧の範囲を無制限にはしません。適用する社内規程や関係する法令・契約を担当部署が確認し、その範囲でログや申告を使います。調査の仕組みそのものが新たな情報集約先になるため、記録に含まれる個人情報と閲覧者も絞ります。
公式AIで実際に仕事が終わる経路を作る
情報システム担当が調べた結果、公式AIには承認済みの文書分割手順があり、営業企画部へ案内されていなかったと仮定します。そこで、利用できる資料、分割の手順、回答後の照合、困ったときの窓口を一つの案内へまとめます。利用者には、個人用サービスの履歴を丸ごと移すよう求めず、移行に必要な資料を承認された保存先から取り直してもらいます。
次に、機密を含まないダミーの提案資料で、構成案の作成から人による確認までを試す計画を立てます。確認するのは、必要な項目が出るか、元資料と一致するか、使い方が理解できるか、支援を求める窓口に到達できるかです。ここでは試験の実施や改善効果は仮定せず、確認する手順だけを示しています。
公式AIの機能では目的を満たせない場合もあります。そのときは申請の受付番号、判断者、回答予定、当面使える作業方法を利用者へ返します。代替手段なしに申請を止めたままにすると、業務の困り事が残ります。新サービスを検討する場合も、例外の用途・データ・期間を限定して審査し、審査中であることを利用許可と混同しません。
公式AIの使いにくさを統制を保ったまま改善する進め方は「公式AIが使いにくいとき、統制を保ちながら利用手順を改善する」で扱っています。ここでは、把握した利用をその改善へつなぐところまでを示します。
利用者が追加情報を待っている間は、資料を人が読み、承認済みの編集ソフトで構成案を作るなど、AIを使わずに進める方法も選べます。公式経路とは、特定のAIへ必ず移すことではなく、業務を管理可能な条件で完了できる手順です。
申告を台帳と標準の更新へ戻す
把握した利用は、サービス名だけでなく、用途、担当部署、業務責任者、扱うデータの種類、承認状態、次の確認を記録します。状態を更新した日と確認根拠も残し、聞き取りだけの項目を設定確認済みに置き換えません。未承認の利用も把握対象に含めますが、台帳へ登録しただけで承認済みにはしません。この例なら「追加利用停止・情報確認中」と「公式AIへの移行準備中」を分け、確認が終わった項目から状態を更新します。
NIST AI RMF PlaybookのGOVERN 1.6には、AIシステムの台帳を作り、維持する責任者や登録範囲を定めるための提案があります。本稿で示す記録は、この管理観点を業務改善へつなぐ例です。詳細な依存関係を最初からすべて埋めようとして、利用者への回答や情報確認を後回しにしないようにします。
移行後は、同じ困り事が解消したかを利用者と確かめます。相談件数が減っても、未承認利用が減ったとは直ちに言えません。相談が難しくなった可能性もあるため、申請が完了した件数、回答待ちの期間、公式手順で作業を終えられたかを、対象期間と範囲を揃えて見ます。個々の会話内容を人事上の評価へ転用して、成果を測る必要はありません。
最後に、分かりにくかった案内や申請手順を更新し、誰が次の変更を管理するかを決めます。新機能、接続先、契約、扱うデータが変わったときは再確認します。現場の利用を知るところから公式経路の改善までを一巡させることで、禁止の通知だけでは残っていた業務上の理由に対処できます。
基本から確認する：この記事の前提になる考え方は、「AIを使う前の安全確認チェックリスト（AIKYで確かめる12項目）」にまとめています。
