実家の母は、毎晩「戸締まりした」と言っていました。
玄関は厳重でした。鍵が2つ付いていて、チェーンがありました。その家には、もうひとつルールがありました。「勝手口から外に出ないで」。家族は、わりと素直に守っていました。ただ、僕が中学生の頃に夜中にこっそり外出するたびに勝手口の鍵は開けられていました。
ルールは、効いてはいたんです。効く相手には。家族は勝手口を使わなくなりました。でも、そのルールを守らない僕には、何の効き目もありません。そこから先は、鍵の仕事です。
では勝手口が開かないようになればければよかったのかというと、そうでもない。勝手口は物置への通路となっていて、物置に向かうときに通れなくなる。
ルール（統制）と、鍵（機構）。この2つは、効き方が違います。片方はもう片方の代わりにならず、しかも鍵は「かける・かけない」の二択でもない。
今日は、生成AIのセキュリティの話をしていこうと思います。
先に結論を書きます。AIセキュリティの設計とは、ルールと鍵を連動させることです。ルールを外れた経路は通れず、ルールを守っている人はセキュアなまま外の情報を取り込める。その状態をどう作るか、という話をします。
①ガイドラインを作ったのに、そこから先へ進まない理由
生成AIのセキュリティ対策として、まず社内ガイドラインを作る。これは正しい順番です。
何を入力してよいか、何を入れてはいけないか。生成AIの情報漏洩は、社員が機密を入力欄に貼り付けることで実際に起きますし、そこは規程で縛れます。
問題は、その次です。
ガイドラインを配り終えた会社が、次に何を検討し始めるかというと、たいてい「もっと安全な使い方」の比較です。法人向けプランにするか、社内に基盤を立てるか、自社のデータを学習させるか、オンプレミスにするか。
ここで議論が止まります。
止まる理由は、比較する軸が定まっていないからです。ある人は「情報システム部が利用状況を把握できること」を安全と呼び、別の人は「そもそも外に通信が出ないこと」を安全と呼んでいる。どちらも正しいのに、質の違うものを同じ言葉で呼んでいるので、候補を並べても優劣がつかない。
そして、ガイドラインを配り終えた状態というのは、ルールの側だけを作った状態です。家族に「勝手口は使わないで」と言った段階で止まっている。
②ルール（統制）と鍵（機構）は、効き方が違う
分けると、こうなります。
ひとつ目は、ルールで閉じることです。統制の側。
誰がどこから使うかを、規程と運用で決める。会社が用意した経路を通ることにする、機密は入れないことにする、違反したら報告してもらう。情報システム部やガバナンスの担当者が「閉じる」と言うとき、多くはこちらを指しています。
ふたつ目は、鍵で閉じることです。機構の側。
そもそも通れないようにする。通信が出ない、権限がない、経路が存在しない。法務や、規制産業の担当者が「外に出さない」と言うとき、多くはこちらを指しています。
ここが今日いちばん言いたいところなのですが、この2つは、効き方が違います。
→ ルールは、効く相手が決まっています。聞いた相手、守る意思のある相手にだけ効く。外部の提供者にも、来期の規約改定にも、急いでいる誰かにも効きません。そして重要なのは、破った人を咎めても、破るハードル自体は1ミリも変わらないことです。統制の分類でいえば、規程や教育は「抑止」と「発見」の統制であって、「予防」の統制ではありません。事後に気づいて是正するための道具です。
→ 鍵は、相手を選びません。通れないなら、誰が何を企てても通れない。予防に効くのはこちらだけです。その代わり、内側で誰が何に使っているかは、何も記録してくれない。
→ だから、片方はもう片方の代わりになりません。ルールだけを厚くすると、破る能力が残ったままになります。鍵だけをかけると、内側の使われ方が野放しになります。
ここまでは、たぶん多くの人が納得するところだと思います。問題は次です。
③鍵を「かける・かけない」の二値にすると、更新まで止まる
「じゃあ鍵をかけよう」となったとき、多くの議論はかける／かけないの二択に向かいます。外に出さない、通信させない、遮断する。
ここに落とし穴があります。
完全に遮断すると、外から来る有益なものまで止まります。モデルの更新、脆弱性の修正、新しい知識、社外の一次情報。AIの領域はこれが特に重い。使っているモデルが半年で古くなる世界で、更新経路を物理的に断つというのは、性能を今日の水準で固定するという判断とほぼ同義です。
そしてもうひとつ。遮断は、内側について何も教えてくれません。外との線を切っただけなので、内側で誰が何に使っているかは相変わらず見えない。ルール側の穴は、そのまま残ります。
完全遮断にはエアギャップという名前があります。極めて強力で、そして極めて不便な構成です。
だから工学の側は、二値をやめる方向に進んできました。段階でいうと、こうです。
→ エアギャップ。物理的に線がない。最強で、更新も止まる。
→ データダイオード（一方向ゲートウェイ）。入ってくる方向だけを通し、出ていく方向を物理的に不可能にする。原子力や重要インフラで実際に使われています。「外の情報は取り込みたいが、こちらの情報は絶対に出したくない」への工学的な答えです。
→ 関所。通す条件を決めて、越境のたびに判定する。条件を満たすものは通り、外れたものは止まる。猫は通れて、人は通れない勝手口。
3つ目が本命です。そして、ここには名前があります。
④「ルールを外れたら止まる」には、半世紀前からの名前がある
通り道の上に判定を置いて、ルールを外れたものだけを止める。この設計は、完全媒介（complete mediation）と呼ばれます。すべてのアクセスを、毎回、権限に照らして検査する、という原則です。1975年に整理された情報保護の設計原則8つのうちの1つで、いまも生きています。
同じ流れで、リファレンスモニタという概念があります。判定を行う機構が満たすべき条件は3つです。
→ 常に呼ばれること。迂回路があってはいけない。
→ 改竄できないこと。判定される側が、判定を書き換えられてはいけない。
→ 検証できるほど小さいこと。複雑すぎる関所は、正しさを確認できない。
実装の言葉でいうと、ポリシー決定点（PDP）とポリシー実施点（PEP）の分離になります。ルールは一箇所で定義し（決定点）、実際の通り道の上に置かれた実施点が、要求のたびにそこへ問い合わせる。ルールと鍵が連動する、というのは構造としてはこれです。
この考え方を、境界防御の否定として現代的に整理したのがゼロトラストです。米国の標準文書（NIST SP 800-207、追補の800-207A）で定式化されていて、要点は、社内ネットワークの内側を信頼するのをやめ、内外にかかわらず要求ごとに、文脈込みで判定すること。城と堀のモデルを否定している理由は、まさに前節の2点――堀は正当な往来まで止め、堀の内側は無検査になる――です。
そして、8原則のうちもう2つが、ここで効いてきます。
→ フェイルセーフ既定値。判定に迷ったら通さない。既定は拒否。
→ 心理的受容性。保護の仕組みは、使う人にとって自然でなければならない。使いにくい保護は、迂回される。
この最後の1つが、実務では決定的です。
正しい経路が遅くて面倒だと、人は必ず別の道を通ります。個人のアカウントで、自宅の端末で、スマホで。そうやって生まれるのが、いわゆるシャドーAIです。統制を厳しくした結果、統制が効かなくなるという逆転が、ここで起きます。
だから、連動の設計はこうなります。
→ ルールを外れた経路は、通れない（完全媒介・既定は拒否）。
→ ルールを守っている経路は、いちばん速くて便利（心理的受容性）。
守っている人が、セキュアなまま外の情報を取り込めて、しかも一番快適である。そこまで作って初めて、ルールと鍵が連動したと言えます。
⑤実務でこの接続が切れるのは、ほぼ一つの理由
ここまでは設計論です。では、なぜ多くの会社で連動しないのか。
理由はほとんど一つだと思っています。ルールが、機械に渡せる形になっていない。
社内ガイドラインは、たいてい人間向けの散文で書かれています。「機密情報は入力しないこと」「業務上必要な範囲で利用すること」「不適切な用途に使用しないこと」。
これらは、どの実施点にも接続できません。機械は「業務上必要な範囲」を判定できないからです。
連動させるには、ルールを機械が判定できる述語に翻訳する必要があります。この宛先へは通す、この分類のデータは通さない、この条件を満たさない要求は既定で拒否する。翻訳できたぶんだけが鍵になり、翻訳できなかったぶんは、ルールのまま――つまり抑止と発見の統制のまま残ります。
そして翻訳するときに、必ず一度は踏む罠があります。
判定の材料を、判定される側に作らせてしまうことです。
具体例を挙げます。AIに自分の目標そのものを書き換えさせる、という危ういことをやっている現場の話です。当然、安全弁を置きます。AIが「この方向に変えるべきです」と提案してきたとき、確信度が高いと自己申告した場合にだけ通すという関所です。
ここに実戦的な穴がありました。AIの出力を「確信度: 高」というフィールドで構造として読もうとすると、AIが理由説明の本文中に、行頭で「確信度: 高」と一行書くだけで、関所を通過できてしまう。読み取り側が、先に見つけた行を勝たせてしまうからです。
誰も攻撃していません。仕様を淡々と埋めようとした結果、安全弁が開きました。
→ この関所は、リファレンスモニタの条件のうち改竄できないことを満たしていませんでした。判定される側が、判定の入力を書けたからです。
→ 塞ぎ方も、原則どおりでした。自己申告を材料にするのをやめ、引用したと主張する根拠が実在するかを機械で照合する。実在しない、あるいは中身が空なら、申告が何と言っていようと確信度を強制的に降格させる。判定に使う事実を、判定される側が動かせない場所へ移したわけです。
要点はひとつ、自己申告は信頼境界にならない。ルールを機械に渡すというのは、判定に使う事実を、判定される側の外側に置くということです。
⑥ルールの外側で起きること — 共有サーバーに立てて、全員で使う
もうひとつ、自社のルールが届かない領域の話をします。
コストを試算すると、必ず誰かが思いつく構成があります。社内に共有のサーバーを立て、そこにAIの開発ツールやクライアントを入れて、社員全員がそこから使う。個人がすでに持っている月額プランの認証情報を使えば、従量課金より圧倒的に安く見える。
そして実際、統制の観点ではよくできています。
利用は一箇所を通るので監視できます。誰が何に使ったかも把握できる。個人が思い思いのサービスを契約してバラバラに使う状態より、統制はむしろ強い。実施点を置く場所としても、悪くありません。
ただ、足りないものが2つあります。
1つ目。鍵にはなっていません。サーバーが社内にあっても、そこから外部のサービスへ通信が出て、処理は外で走ります。置き場所が自社になっただけです。ここを「サーバーに入れたからローカル化した」と受け取ってしまう会話が、わりと頻繁に起きます。ローカルLLMは、モデル本体が自社の中にあって推論まで完結する構成のことで、外部サービスのクライアントを自社サーバーに置くことではありません。
2つ目。この構成は、自社のルールが届かない場所で止まります。個人向けプランの認証情報を、共有のサーバー側で預かって実行する構成は、用途外として明確に閉じられた例があります。2026年2月には個人向けプランの認証情報の用途を公式クライアントに限る旨が明文化され、同年4月にはサーバー側で実際に締め出す措置が実施されました。
これは、前節の裏返しです。自社の統制は、自社の権限が届く範囲にしか効きません。他社の規約は、こちらのルールでは動かせない一行です。
⑦では、関所をどこに置くか — 4つの構成
ここまでの整理で、選択肢は「どこに関所を置くか」で並べ直せます。
①提供側の中に置く（法人向けプラン）。入力を学習に使わないことは契約で定められ、管理者が利用状況を把握できる仕組みも付いてきます。統制の道具は買えます。ただし判定の主導権は提供側にあり、モデルの更新も廃止も向こうの都合で起きる。監査のために挙動を固定することはできません。データの流出は防げても、挙動の主導権は戻ってこない。
②自社に置いて、外を呼ぶ（共有サーバー）。前節のとおり、実施点としては機能しますが、その先は外です。鍵にはなりません。
③自社の中で完結させる（ローカルLLM／オンプレミス）。モデル本体が自社のサーバーか端末の中にあり、推論までそこで終わる。通信が発生しないので、相手を選ばずに効く鍵になります。他社の規約に事業が左右されることもなくなる。場所で保証する、いちばん古典的で確実なやり方です。
代わりに、提供側が黙ってやっていた仕事が全部来ます。モデルの更新。問題が出たときの停止。動かないときに戻る場所。そして③節の問題――外から来る更新をどう安全に取り込むか――が、そのまま自社の課題になります。
④外部だが、中身は見せない（機密計算）。そして、いま前線が動いているのがここです。
ハードウェアが用意した保護された実行環境の中でだけデータを復号して処理し、事業者の管理者からも中身が見えないようにする。さらにリモート・アテステーションという仕組みで、「本当に想定どおりの環境で動いているか」を利用する側が検証できます。主要なクラウドはこの構成を提供していますし、端末で保証していたプライバシーをサーバー側の推論まで延長し、その実装を第三者が検証できるように公開する、という設計も現れています。
ここで起きているのは、保証の根拠が「場所」から「検証できる証明」へ移りつつあるということです。
「外に出したか、出していないか」は、長らく信頼の代理指標でした。中が見えないから、せめて場所で判断する。アテステーションは、その代理指標を本物に置き換えようとしています。
とはいえ、これは③を不要にしません。検証できる保証は、検証の連鎖をどこかで信じることを要求します。ハードウェアの製造元と、証明の発行元を。そこまで含めて自分で持ちたいなら、答えは今でも③です。
最後の判断軸は、性能でもコストでもありません。比較表は半年で無効になります。半年後も変わらないのは一つだけで、その事業に統制権が要るか――モデルと土台とデータについて、更新の時期も、挙動の固定も、廃止の判断も、自分で決める必要があるか、です。
そしてこの軸で並べると、常識的な順位が反転します。試行が速く、やり直しがきき、誰にも説明義務がない事業ほど、借りる側が有利です。規制があり、顧客と長期の約束を交わし、監査で挙動を説明する必要がある事業ほど、自分で持つ側が有利になる。体力のある大企業ほど手軽にクラウドへ、ではありません。逆です。
⑧補足 — 「知識をどこに置くか」は、鍵とは別の軸です
比較検討の場では、必ずここに混ざってくる話があるので、分けておきます。
「自社のデータを学習させる」は、鍵の選択肢ではありません。自社の知識をどこに持たせるかという、別の軸の話です。混ぜると議論が壊れます。
その上で、実地の話を少しだけ。ある現場では、50件ほどの文章しかない状態でファインチューニングに取り組んでいました。数千件を用意するのが普通だと思っていた側からすると、明らかに少ない。
そこで採られたのが、文章を2つの層に分けるやり方です。元の文章を一度中立的な文章――特徴のない、内容だけの状態――に変換し、「中立的な文章」を入力、「自社の文章」を出力とするデータセットを組む。こうすると、モデルが学ぶのは内容ではなく、その間にある変換の癖だけになります。
→ 効くのは、文体・判断の癖・様式。少ないデータでも移せます。
→ 効きにくいのは、事実。内容が変わるたびに学習をやり直すことになるので、事実に基づいて答えさせたいなら、覚えさせるのではなく答えるたびに検索して見せる方（RAG）が向いています。
そして、どちらを選んでも推論がどこで走るかは別問題として残ります。外部で学習させ外部で動かすなら、知識は自社のものになりましたが、鍵は一つもかかっていません。
マクロな考察 — 「守る」を禁止事項の数で測るのをやめる
最後に、少しだけ引いて考えます。
なぜ生成AIのセキュリティが、ガイドラインの話にばかり寄るのか。
僕が思うに、禁止事項は数えられるからです。
何項目のルールを整備した、何回研修をした、誰が誓約書に署名した。これは稟議に書けます。ところが「ルールのうち何割を機械が判定できる形にして、実際の通り道に置いたか」は、数えにくい。効果も見えにくい。事故が起きなかったことは、成果として報告できません。
→ だから、測れる方が選ばれます。
→ 測れる方だけをやると、玄関の鍵が増えます。
→ そして現場は、面倒になった正しい経路を避けて、別の道を通り始めます。
厳しくするほど迂回される、というのは根性の問題ではなく、設計原則として半世紀前から知られていることです。守れているかどうかは、ルールの数ではなく、ルールのうちどれだけが鍵に接続されているかでしか測れません。
ルールを書く。そのうち機械が判定できるものを翻訳する。通り道の上に置く。翻訳できなかったぶんは、抑止として残っていると認める。
順番はこれだけです。
よくある質問（と僕の答え）
Q. 生成AIのセキュリティ対策は、何から始めればいいですか？
ガイドラインの整備からで正しいです。ただし、それはルール（統制）の側を作っただけです。ルールは守る人にしか効かず、破った人を咎めても破るハードルは変わりません。次の一歩は、書いたルールのうちどれを機械が判定できる形に書き直せるかを洗い出し、それを実際の通り道の上に置くことです。
Q. 完全に遮断すれば、情報漏洩は防げますか？
漏洩は防げますが、外から来る有益なもの――モデルの更新、脆弱性の修正、新しい知識――まで止まります。しかも内側で誰が何に使っているかは相変わらず見えません。完全遮断はエアギャップと呼ばれ、更新を止められない領域では成立しません。入る方向だけを通すデータダイオードという中間解もありますが、実務でより現実的なのは、遮断ではなく越境のたびに判定する関所を置くことです。
Q. 違反者を罰する規程を作れば、抑止になりませんか？
抑止にはなりますが、予防にはなりません。規程や教育は抑止的・発見的な統制で、事後に気づいて是正するためのものです。行為そのものを不可能にはしません。予防に効くのは、通り道の上に置かれた機構だけです。
Q. ゼロトラストは、要するに何を変えるのですか？
境界の内側を信頼するのをやめます。社内に基盤を立てたから安全、社員が使っているから安全、という前提を全部やめて、要求ごとに文脈込みで判定する。米国の標準文書では、ポリシーの決定点と実施点を分けた構成として定式化されています。
Q. ローカルLLMにすれば万全ですか？
鍵の側の要件は満たせます。ただし、提供側が担っていた更新・停止・代替経路の運用が自社の仕事になり、誰が何に使ったかを把握する統制は別に作ることになり、外から来る更新をどう安全に取り込むかという問いはそのまま残ります。場所で閉じることは強力ですが、それ自体は統制ではありません。
Q. 外部を使いながら、事業者にも中身を見せないことはできますか？
機密計算がその方向です。保護された実行環境の中でだけ復号して処理し、事業者の管理者からも中身が見えない構成にします。リモート・アテステーションで、想定どおりの環境かを利用する側が検証できる。外に出すか出さないかという場所の二値が、検証できる保証があるかという軸に置き換わりつつある、と捉えると分かりやすいと思います。
今日は、鍵を二値で考えるのをやめよう、という話をしました。
そう言えば、うちの実家の勝手口はドアを開ける時に大きく「キー」っと音がします。それが鍵を突破した後に一階に眠る両親にバレずに夜遊びするための最大の難関でした。
鍵を突破された後の、「フェイルセーフ設計」が効いていたということです。
さようなら。
KOHEI YANAGIDA
susai
