シャドーAIの対策は利用禁止ではない
目次
はじめに
社内で生成AIの利用ルールを作ったのに、現場では個人アカウントのAIツールが使われている。情シスが聞くと「ちょっと要約しただけです」「機密は入れていません」と返ってくる。けれど、どの情報を入れたのか、何を出力したのか、誰が確認したのかは残っていない。
これがシャドー AIの怖さだ。悪意があるから起きるのではない。仕事を速くしたい人ほど、先に便利な道具へ流れる。だから「禁止」と書くだけでは止まらない。むしろ、公式に使える道と、使ってはいけない境界を先に用意しないと、利用は見えない場所へ潜っていく。
総務省・経済産業省のAI事業者ガイドライン は、人間中心、安全性、透明性、アカウンタビリティを共通の考え方として示している。シャドーAIの対策も同じだ。現場を縛る話ではなく、AIを業務に入れるときの責任線を見える形にする話だ。
シャドー AIで最初に見るべき論点
シャドー AIの論点は、ツール名ではない。「ChatGPTを使ってよいか」「このサービスは許可するか」だけで議論すると、すぐに詰まる。新しいサービスは毎週出るし、同じツールでも使い方でリスクは変わるからだ。
先に見るべきなのは、次の4つだ。
| 論点 | 見るもの | 例 |
|---|---|---|
| 入力 | 何をAIに渡すか | 顧客情報、契約条件、議事録、ソースコード |
| 出力 | 何を業務に戻すか | 要約、返信案、設計案、コード |
| 権限 | どこまで実行するか | 読むだけ、下書きまで、外部送信は不可 |
| 記録 | 後から追えるか | 利用目的、入力種別、確認者、出力の採否 |
この4つがないままツール許可リストだけを作ると、現場は「これは許可ツールだから大丈夫」と考える。だが、許可ツールでも顧客の未公開情報を入れれば危ない。反対に、未承認ツールでも公開資料の要約だけならリスクは小さい。ツール単位では、業務上のリスクを切り分けられない。
OWASP Top 10 for Large Language Model Applications でも、機密情報漏えい、不十分なプラグイン設計、過剰な自律性が主要リスクとして整理されている。つまり、見るべきは「AIを使ったか」ではなく、「何を渡し、何をさせ、どこで止めたか」だ。
禁止で止めるほど、利用は見えなくなる
シャドーAIの対策で一番やりがちな失敗は、最初から禁止で固めることだ。もちろん、個人情報、認証情報、未公開の契約条件を外部サービスに入れてはいけない。この線は明確にする必要がある。
ただし、禁止だけでは足りない。現場には締切がある。提案書を今日中に直したい。長い議事録をすぐ読みたい。コードのエラーを早く見たい。公式の選択肢がないと、現場は「少しだけなら」と個人判断で使う。
だから、最初に作るべきなのは利用禁止リストではなく、公式に逃がす導線だ。
たとえば、次のように分ける。
- 公開情報の要約は、会社指定のAI環境で使える
- 社内文書の要約は、保存先とログが残る環境だけで使える
- 顧客情報を含む文書は、匿名化または承認後に使う
- 外部送信、契約条件、金額変更はAIに実行させない
- 判断に迷うときの相談先を決める
こうすると、現場は「AIを使うな」ではなく「この範囲なら使える」と理解できる。利用をゼロにするより、見える場所へ寄せる方が現実的だ。
AIエージェントを業務に入れる場合も同じで、社内AIエージェントは権限設計から で触れたように、読める範囲と動かせる範囲を分ける必要がある。シャドーAIの対策は、この権限設計の前段にある。
公式利用へ逃がす5つの設計
シャドーAIの対策は、重い規程から始めるより、5つの設計に落とした方が動きやすい。
1. 業務別に「使ってよい入力」を決める
全社共通で「機密情報は禁止」と書いても、現場では迷う。営業、採用、開発、法務で扱う情報が違うからだ。
営業なら商談メモ、提案書、見積条件。採用なら応募者情報、評価コメント。開発ならソースコード、障害ログ、設計書。業務ごとに、AIへ渡してよい入力と、渡してはいけない入力を分ける。
この整理は、AI要件定義ツールの選び方 に近い。ツールを選ぶ前に、誰が何を見られるべきかを決める。シャドーAIの対策でも、まず入力の境界を決める。
2. 出力をそのまま採用しない
AIの出力は、たたき台としては速い。だが、業務判断としてそのまま採用すると危ない。特に、契約、見積、採用評価、セキュリティ判断は人間の確認が必要だ。
OpenAIのエージェント安全性ガイド でも、リスクの高い操作では人間確認やガードレールを置く考え方が示されている。 シャドーAIの対策では、AIが出したものを「草案」「確認済み」「承認済み」に分けるだけでも事故を減らせる。
3. 個人アカウントから公式環境へ移す
現場が個人アカウントを使う理由は、だいたい速いからだ。会社の申請が重い、使えるツールが分からない、相談先がない。ここを放置すると、シャドーAIは減らない。
最小構成でよいので、会社指定の入口を作る。Slackから使える社内AI、会社契約の生成AI、ログが残るチャット環境。大事なのは、完璧な基盤を最初から作ることではない。迷った人が個人アカウントへ行く前に、公式の逃げ道を出すことだ。
4. ログは監視ではなく再発防止に使う
ログを取ると言うと、現場は監視される感覚を持ちやすい。だから目的をはっきりさせる。誰かを責めるためではなく、危ない使い方を早めに見つけ、ルールを直すために使う。
NIST AI Risk Management Framework は、AIリスクをGovern、Map、Measure、Manageの観点で扱う。シャドーAIの対策でも、見えない利用をゼロにするより、見える利用を測り、ルールへ戻す方が続く。
5. 相談先を1つにする
「これはAIに入れていいですか？」の相談先が曖昧だと、現場は聞かない。聞くより試した方が速いからだ。
相談先は、情シス、法務、AI推進チームのどれでもよい。ただ、入口は1つにする。Slackチャンネルでもフォームでもよい。迷ったときに聞ける場所があるだけで、シャドーAIは減る。
導入前のチェックリスト
シャドーAIの対策を始めるなら、まず次の10問に答える。
- 会社として許可するAI環境は決まっているか
- 業務別にAIへ渡してよい入力が分かれているか
- 顧客情報、個人情報、契約条件の扱いが明文化されているか
- AI出力を草案、確認済み、承認済みに分けているか
- 外部送信や確定更新をAIに任せない線があるか
- 個人アカウントを使いたくなる理由を把握しているか
- 公式環境の使い方が現場に伝わっているか
- 利用ログを何のために見るか説明できるか
- 迷ったときの相談先が1つに決まっているか
- ルール違反を責める前に、公式導線の使いづらさを直す仕組みがあるか
全部を初日に満たす必要はない。だが、この10問に答えられないまま全社展開すると、現場は各自の判断でAIを使い始める。すると、便利さは広がるが、責任線は薄くなる。
AIエージェントをチームに組み込む前に考えるべきガバナンス設計 でも、技術実装より前にプロセスと責任を決める必要があると書いた。シャドーAIの対策も同じだ。AIの利用を止めるのではなく、組織で扱える形に変える。
Atsumellの視点
シャドーAIは、現場が勝手に動いた結果だけではない。会社側が、AIを安全に使うための仕様をまだ用意できていないサインでもある。
使ってよい入力、出してよい成果物、人間に戻す判断、ログの残し方。これらが構造化されていれば、AIは現場の味方になる。逆に、ここが曖昧なままなら、どれだけ高性能なツールを入れても、利用は見えない場所へ散る。
株式会社Atsumellでは、AIが読める要件定義と、業務に組み込めるAIエージェントの設計を支援している。シャドーAIを禁止で押さえ込むのではなく、公式に使える業務フローへ変える。そのために、入力、権限、停止条件、評価の順番を一緒に整理する。
シャドーAIの対策の第一歩は、強い禁止文を書くことではない。現場が安心して使える道を作り、危ない利用を自然にそこへ戻すことだ。
