「営業はこの AI で議事録を要約し、開発は別の AI にコードを貼り、マーケはまた違うツールに顧客リストを読ませている。誰がどの AI に何を渡したのか、会社としては把握できていない」——AI 活用が現場に浸透した企業で、いま静かに広がっているのがシャドー AIです。便利だから現場が勝手に使い始める。それ自体は悪いことではありません。問題は、会社が「何が起きているか」を見えていないことです。機密情報が外部 AI に渡り、利用料が部署ごとに膨らみ、いざ問題が起きても経路を追えない。
この課題に対し、InfoQ の Governing AI in the Cloud: A Practical Guide for Architects は、シャドー AI の発見、データ分類、IAM による制御、ポリシー・アズ・コードといった実務的な打ち手を整理しています。要点は明快で、AI を禁止して統制するのではなく、見えるようにして統制すること。禁止すればシャドー化はむしろ地下に潜ります。
統制の出発点は「禁止」ではなく「発見」
ガバナンスというと利用制限を思い浮かべますが、順序が逆です。まず「いま何が使われているか」を可視化しないと、制限も評価もできません。受託で AI ガバナンスを設計するとき、私たちは次の順で積み上げます。
| 段階 | やること | 目的 |
|---|---|---|
| 発見 | 通信ログ・課金・SaaS連携からAI利用を棚卸し | シャドーAIを地図化する |
| 分類 | どのデータがどのAIに渡っているかを機微度で仕分け | 守るべき優先順位を決める |
| 制御 | IAM・ゲートウェイで誰が何に使えるかを制御 | リスクの高い経路だけ締める |
| 運用 | 利用状況とコストを継続的に監視 | 暴走と逸脱を早期に検知する |
最初の「発見」を飛ばして「制御」から入ると、現場の反発を招くだけで、結局抜け道が使われます。現状の地図を作ることが、ガバナンスの 8 割だと考えてよいです。AI 導入が成果に結びつかない構造的な理由は GenAI Divide 95%失敗の罠（GH Media） でも整理しました。可視化が効くのはセキュリティだけでなく、投資対効果の面でも同じです。
「入り口を一本化する」ゲートウェイ型の制御
発見と分類ができたら、次は制御です。ここで有効なのが、社内から外部 AI への通信を一つのゲートウェイに集約する設計です。各アプリ・各部署が直接 AI サービスを叩くのではなく、間にゲートウェイを挟むことで、次がまとめて実現できます。
- 可視化：どのチームがどのモデルをどれだけ使ったかが一望できる
- コスト制御：部署・アプリ単位で利用上限を設け、請求の暴走を止める
- アクセス制御：機密データを扱う経路にだけ、追加の認証・ログ・マスキングをかける
- モデルの差し替え：将来モデルを乗り換えるとき、入り口の設定だけで切り替えられる
コスト面の制御は、ツール単位でも踏み込めます。利用上限で「AI コストの暴走」を止める具体策は Cloudflare AI Gatewayの利用上限設定（GH Media） にまとめました。ゲートウェイ型は、セキュリティとコストガバナンスを同じ入り口で両取りできるのが利点です。
「ポリシーを文書ではなくコードにする」
ガバナンスが形骸化する典型は、ルールが PDF やスプレッドシートに書かれただけで、実際の運用とずれていくパターンです。これを防ぐのがポリシー・アズ・コード——「機密データを外部 AI に渡してはいけない」「本番環境からはこのモデルしか呼べない」といったルールを、人手の運用ではなく仕組みとして強制する考え方です。
実際にあるクライアント（社名は伏せます）では、社内データを扱う AI 経路だけにマスキングとログ取得を必須化し、その条件をデプロイパイプラインのチェックに組み込みました。ルールを守るかどうかが個人の判断ではなく、通らなければデプロイできない仕組みになったことで、後から「知らずに機密を渡していた」が起きにくくなりました。社内 AI を権限制御つきで安全に公開する設計は、自作MCPサーバーをOAuth 2.1で守る（GH Media） とも通じます。
まず、現状のAI利用を地図にすることから
AI ガバナンスは、規程を作ることからではなく、いま誰が何の AI に何を渡しているかを見えるようにすることから始まります。そこが見えれば、締めるべき経路と放っておいてよい経路が分かれ、過剰な禁止で現場を止めずに済みます。私たちは受託で、この発見・分類から、ゲートウェイ集約とポリシーの仕組み化までを段階的にお手伝いしています。
