シャドーAIは、禁止するほど見えなくなる

生成AIの社内ルールを作るとき、最初の一行は禁止になりがちです。会社が許可していないAIサービスの利用を禁じる。書きやすく、承認も通りやすい一文です。

ただ、禁止を先に置いて減るのは、利用ではなく申告です。使う人が減るより先に、使っていると言う人が減る。申告されなくなったシャドーAIは、管理も対策もできません。

2026年7月に、IPA産業サイバーセキュリティセンターの中核人材育成プログラム9期生がまとめた手引書があります。生成AIおよびAIエージェントを安全に活用するための手引書、第1版で全99ページ。シャドーAIへの対応方針の節は、こう始まります¹。

この記事は、セキュリティの手引書がなぜそう書くのか、対策の順番をどう置いているのか、そして公式なAIを配ったあとに残る分をどう扱っているのかを、原文で追います。

止めるための文書ではない、と自分で書いている

手引書の目的は1.2節にあります。

加速させる、が目的です。執筆の出発点として挙げている問題意識は3つ。

漠然とした懸念から導入に慎重になる会社と、リスクを理解しないまま活用が進む会社がある。リスクを並べるだけでは利活用は加速せず、理想の対策を並べるだけではコストとリソースを食い、利活用へのハードルを過剰に引き上げる。そして、各企業が明確な根拠を持ってビジネス影響を評価し、受容か低減かのリスク管理方針と低減施策を自分で判断する必要がある。

第2章の冒頭には、著者の考えとしてこう書かれています。AIガバナンスの要諦は、単に利用を制限することではない。実態を把握し、技術進化への機敏な適応を両立させながら、ビジネス価値を最大化しつつリスクを許容範囲内に管理することにある。

出自には注意が要ります。これはIPAが組織として出した公式ガイドラインではありません。表紙にあるとおり、中核人材育成プログラムの9期生が、セキュリティ担当者のための生成AIセキュリティというプロジェクトの成果としてまとめた文書です²。

免責事項には、IPAおよび産業サイバーセキュリティセンターの意見を代表するものではなく著者の見解に基づく、と明記されています。国やIPAが定めた方針ではなく、セキュリティ担当者の視点で書かれた実務の手引き。だからこそ、禁止を先に置かない理屈が、セキュリティ側の言葉で書かれています。

一手目は禁止ではなく、組織公認AIの提供

用語を手引書に合わせます。組織が利用を推奨するAIシステムが組織公認AI。組織が利用を許可したAIシステムが組織承認AI。組織が利用を許可していないAIシステムを従業員が利用する行為がシャドーAIです。

2.3.2節は、対応を並べる前に順番を一つ置いています。まず自組織のシャドーAIの実態を把握する。その状況に応じて、利用禁止とするか条件付きで許可するかを、CAIOを中心に合意する。

そのうえで挙げる対応は3つで、番号が振られています。禁止に近いものほど後ろにあります。

1. 組織公認AIの提供

理由はこうです。シャドーAIが発生する大きな要因として、業務に使いたいのに公式な手段がない、という状況が考えられる。IT部門が安全性を検証した組織公認AIを全社に、または情報漏洩リスクの高い部署から優先的に提供することが、シャドーAI対策の有効な前提条件の一つ。組織公認AIの利便性が現場のニーズを満たせれば、シャドーAIの動機自体を低減できる。

言われているのは、需要の側を先に片付ける、ということです。使いたい理由が残ったまま入口だけ塞げば、変わるのは出口だけです。

2. ルールの明文化と教育

組織承認AIの一覧と、それ以外のサービスの利用禁止をガイドラインに明文化し、周知する。新しいAIシステムを使いたいときの審査プロセスを整え、現場の要望を吸い上げる仕組みを設ける。禁止はここで初めて出てきますが、申請の道とセットです。

ガイドライン策定の節と教育の節にも、同じ向きの留意点があります。過度に厳格なルールは回避、つまりシャドーAIの増加を招き、かえってリスクを高める。禁止一辺倒ではなく代替手段とセットで策定する。順守率を高めるのは禁止事項の伝達だけではなく、組織公認AIには安全策があり安心して使えると伝えることも要る、と続きます。

3. 技術的な検知・遮断

CASBやSWGで、未許可のAIシステムへの通信を検知・遮断する。AI DLP製品で、AIサービスへの機密情報の入力を検知・制御する。有効だと書いたうえで、限界も同じ段落に書いてあります。

続く段落はこうです。

ここが効きます。三手目だけでは届かない範囲がある、と手引書自身が書いています。届かない分は、一手目と二手目の組み合わせで受ける。

順番の理由までは書かれていません。ただ、組み立てはそう読めます。使いたい理由を減らし、ルールを守る動機を作り、そのうえで遮断を重ねる。

配っても、ゼロにはならない

組織公認AIを配れば終わり、とは書いてありません。原文は、シャドーAIの動機自体を低減できる、と書いています。減らせる、であって、なくせる、ではない。

2.3.2節の最後にも、シャドーAI対策は一度整備すれば終わりではない、とあります。新たなAIシステムの登場や利用実態の変化に応じて、組織公認AIの利便性向上、組織承認AIの拡充、ルールの見直しを続ける。実態の把握も、最低でも年1回を目安に繰り返す活動だと2.4.1節に書かれています。

手引書は、対策を講じても残る分を残存リスクと呼び、第6章で扱っています。シャドーAIの残りをそこに重ねて読むのは、手引書ではなくこの記事です。

保険の節は、こう書き出します。生成AIのリスクは、本章に記載のガバナンス体制やルールの整備、および第6章に示す対策によって低減できるが、完全に排除することはできない、と。ゼロにしない前提が、この文書全体に通っています。

そして、全部やれとも書いていません。第6章の冒頭に、対策の選び方がリスクの高さごとに書かれています¹。

固有リスクとは、対策を講じる前の時点で、利用目的や扱う情報から決まるリスクのことです。第5章はその尺度に、発生可能性ではなく影響度を採用しています。企画段階で発生可能性を正確に見積もることは容易ではない、という理由です。

つまり手引書の言う管理とは、リスクを一つ残らず潰すことではありません。高いものには重ねる。中程度なら選び、講じられない分は残存リスクとして明示し、管理する。低ければ受容する。

保険は最後に出てきますが、リスクの移転手段であってリスクそのものを低減するものではなく、残存リスクへの備えとして位置付ける、と念を押されています。

残る分を見る手段も、手引書は求めています。運用対策の一つに、AIシステムの全操作ログを記録できる状態にせよ、とあります¹。記録するのは、いつ、誰が、どのサービスに、何を送ったか。ログ監査の節は、どのレベルでも検知漏れは起こりうるとして、ログ監査を他の対策との多層防御の一部に置いています。

受容も、明示も、管理も、備えも、そのリスクがそこにあると分かっていて初めてできることです。

申告されないものは、残存リスクに載らない

手引書は、残存リスクを明示して管理せよ、受容も合理的な選択だ、と書いています。ここからは手引書の直接の記述ではなく、この記事側の読みです。

そこには前提が一つ隠れています。明示するには、何が残っているかを知っていなければならない。受容するには、何を受け入れるのかが見えていなければならない。

禁止を先に置くと、減るのは申告です。申告されなくなったシャドーAIは、残存リスクの一覧に載りません。載らないものは、受容もできず、管理もできず、保険で備えることもできません。

禁止で見えなくするのは、リスクを消すことではなく、リスクを管理の外に出すことです。使う人は残り、入力される情報も残り、それが一覧から消える。消えたのはリスクではなく、リスクの居場所を知る手段です。

手引書が一手目を禁止にしなかった理由は、ここに戻ります。動機を減らし、ルールを守る理由を作り、そのうえで検知と遮断を重ねる。それでも残る分に名前を付けて管理する。この順番は、残る分が見えていることを前提にしています。

禁止で消えるのは、申告だけです。