デジタルガーデン

最近の更新

「全部禁止」は安全ではない——禁止の総和がAIの能力と統制を同時に殺す

Properties4
typeidea
confidencemedium
statuspublished
descriptionWeb検索・curl・MCPをすべて禁止するとリスクは消えず、現場のシャドーAIと統制不能に移る。禁止を「段階的許可」に分解するための前提を整理する。

8 min read

概要

オンプレミスでLLMを動かしている。ZDR（Zero Data Retention）契約もある。社内ルールもある。それなのに、Web検索は情報漏洩が怖いから禁止、webfetch はプロンプトインジェクションが怖いから禁止、curl も pip も npm もGitHub連携もMCPも、それぞれに理由があって禁止。結果として、エージェントには「社内文書を読んで要約する」くらいしか許されていない。

この状態を「安全」と呼ぶのは、たぶん間違っている。

禁止によってリスクがゼロになるわけではない。リスクは 「管理された経路から、管理されていない経路へ」 移動するだけだ。現場は個人の無料アカウントに機密を貼り、私物のMCPを入れ、禁止された検索をブラウザで手作業で行う。会社から見れば、ログも承認もインシデント対応もない場所にリスクが出ていく。これは安全ではなく、可視性の放棄 である。

禁止が生む3つの副作用

1. 能力の損失

エージェントの価値は、文脈を集め、外部の情報と突き合わせ、道具を使って手を動かすところにある。検索も取得も実行も奪えば、高価な文章要約器が残る。それなら人間がやったほうが早い。

2. シャドーAI

承認された経路が遅い、使いにくい、制約が多すぎる。すると現場は、より便利な非承認の経路を選ぶ。これは規律の問題ではなく、導線の問題 である。人間は、正しい方法が最も面倒なとき、正しくない方法を選ぶ。

3. 統制不能

シャドーAIの最大の問題は、事故そのものより 事故が起きたことに気づけないこと だ。ログがない、承認履歴がない、どのモデルに何を渡したか分からない。インシデントが起きてから「たぶんあの人が貼った」と推測するしかなくなる。

本当に分解すべきもの

「Web検索を禁止する」は、ひとつの制御であって、リスクの全体像ではない。少なくとも次の4層を分けて考える必要がある。

  1. データ送信: プロンプトやファイルがどこへ出るか
  2. 外部入力: Web、メール、PDF、MCPの返り値など、何が文脈に入るか
  3. 実行権限: シェル、ファイル書込み、外部送信、クラウド操作をどこまで許すか
  4. 供給網: モデル、パッケージ、スキル、MCPサーバーを誰が検査するか

Web検索の禁止が効くのは、主に2層目だけだ。ZDRは1層目、ミラーは4層目、承認ゲートは3層目に効く。ひとつの禁止で全部を守ろうとすると、必ず穴が残る。

禁止を「段階的許可」に変える

必要なのは、禁止の総和ではなく、デフォルト拒否＋明示許可＋観測 の組み合わせだ。

  • データを「公開・社内・機密・制限」に分ける
  • 操作を「読む・加工する・書く・外に送る・実行する」に分ける
  • その組み合わせごとに、許可・承認・禁止を決める
  • 決めたことを、プロンプトではなく実行層で強制する
  • 実行ログを残し、例外をレビューする

これは データ分類×操作リスクのマトリクス で具体化する。ポイントは、禁止を減らすことではなく、禁止する理由と、許可する条件をセットで決めること だ。

個人開発者の場合も同じ

「自分は個人だから関係ない」は成り立たない。個人のほうがむしろ、この構造に陥りやすい。

ローカルLLMは遅い。設定は面倒だ。だからつい、無料のチャットに業務のコードや顧客情報を貼る。ZDR契約があるから大丈夫、学習に使われないから大丈夫、と自分に言い聞かせる。だがZDRは「送らない」ではないし、無料枠が常にZDRとは限らない（ZDRは「データを送らない」ではない）。

個人に必要なのも、根性ではなく導線だ。ローカルモデルを実用的な速度で動かし、検索は許可ドメインに絞り、機密を扱うセッションと公開情報を扱うセッションを分ける。安全な経路が一番楽な経路になるように作る。

まとめ

「全部禁止」は、リスクを消していない。リスクを測れなくしている。

安全とは、危険なものが存在しないことではない。危険なものが、制御された境界の中で、観測可能な形で動いていること だ。禁止はそのための一手段にすぎない。禁止の総和を安全と取り違えると、AIの能力も、現場の信頼も、統制の実効性も同時に失う。

関連ノート

参考資料

最近の更新

グラフビュー

バックリンク

目次