生成AIのセキュリティ｜入力・出力・悪用のリスクと7つの対策

実家の母は、毎晩「戸締まりした」と言っていました。

玄関は厳重でした。鍵が2つ付いていて、チェーンがありました。その家には、もうひとつルールがありました。「勝手口から外に出ないで」。家族は、わりと素直に守っていました。ただ、僕が中学生の頃に夜中にこっそり外出するたびに勝手口の鍵は開けられていました。

ルールは、効いてはいたんです。効く相手には。家族は勝手口を使わなくなりました。でも、そのルールを守らない僕には、何の効き目もありません。そこから先は、鍵の仕事です。

では勝手口が開かないようになればければよかったのかというと、そうでもない。勝手口は物置への通路となっていて、物置に向かうときに通れなくなる。

ルール（統制）と、鍵（機構）。この2つは、効き方が違います。片方はもう片方の代わりにならず、しかも鍵は「かける・かけない」の二択でもない。

今日は、生成AIのセキュリティの話をしていこうと思います。

先に結論を書きます。AIセキュリティの設計とは、ルールと鍵を連動させることです。ルールを外れた経路は通れず、ルールを守っている人はセキュアなまま外の情報を取り込める。その状態をどう作るか、という話をします。

先に、生成AIのセキュリティを教科書どおりに整理しておきます。どこにリスクがあり、何で塞ぐのか。入力・出力・悪用の3方向に分けて並べます。

生成AIにセキュリティ対策が必要な理由

生成AIは、渡した情報を外部のサービスへ送り、返ってきた文章を人がそのまま使うという形で業務に入ります。入口と出口の両方が、これまでのシステムと違います。

そして、導入の意思決定を待たずに現場が使い始めます。規程の整備が後追いになりやすく、気づいたときには把握できない利用が広がっているのが典型です。

生成AIの仕組みから見る、リスクの出どころ

生成AIは、大量のデータから規則性を取り込む学習と、入力を受けて答えを組み立てる推論の2段階で動きます。

段階	何が起きるか	ここから出るリスク
入力	渡した文章が外部へ送られる	機密情報の漏えい、学習への流用
推論	もっともらしい続きが組み立てられる	ハルシネーション、著作権、バイアス
連携	外部の文書や道具とつながる	プロンプトインジェクション、サプライチェーン

対策を並べる前に、この3つに分けてください。一覧で覚えようとすると抜けますが、入口・出口・つなぎ目の3方向で見ると、漏れが分かります。

「禁止」ではなく「管理」すべき理由

全面禁止は、いちばん確実に見えて、いちばん危険な選択です。業務で必要な人は、個人のアカウントで使い始めます。

会社が用意した環境なら、ログが残り、設定を管理できます。個人利用に移った瞬間、何が入力されたのかを誰も知り得なくなります。禁止事項を並べる前に、使ってよい環境を用意してください。

入力リスク①｜機密情報の漏えい

顧客情報、未公開の資料、ソースコード、個人情報。下書きを作らせたいという動機から、実データをそのまま貼り付けてしまうのが最も多い経路です。

手当ては、入れてよい情報を先に列挙することです。禁止事項だけを書くと、「これは書いていないから大丈夫」という判断が現場で起きます。

入力リスク②｜学習データへの流用と、二次利用

個人向けの設定のままだと、入力した内容が学習に使われる場合があります。法人向けの契約やAPI利用では、学習に使わない設定を選べます。

契約書の条項まで確認してください。画面の設定と、契約上の取り扱いが一致していないことがあります。

入力リスク③｜従業員の不注意と、データが残り続けること

悪意ではなく、急いでいるときに起きます。メールの下書きを頼むために、受け取った本文をそのまま貼る、といった形です。

あわせて、一度入力したデータが、サービス側にどれだけの期間保存されるのかを確認してください。削除依頼の手段があるかどうかも、選定時の確認項目です。

出力リスク①｜ハルシネーション（もっともらしい誤り）

存在しない出典や誤った数値を、自信のある文体で出します。誤りが「正しい文章の形」で出てくるのが厄介な点です。

対策は、根拠を渡すことと、外に出る手前に人を置くことの2つです。「渡した資料の中に無い場合は、無いと答える」と指示に書くだけでも量が変わります。

出力リスク②｜著作権・知的財産権の侵害とバイアス

生成物が既存の著作物に似る可能性は残ります。公開する制作物では、生成AIを使った箇所と確認した人を記録に残してください。

あわせて、学習データに含まれる偏り（バイアス）が出力に現れます。採用、評価、与信のように人を選別する用途では、この点だけで使えないことがあります。

出力リスク③｜誤情報の拡散とディープフェイク

社外向けの文章や画像をそのまま出すと、誤りが自社の発信として拡散します。音声や映像を合成したディープフェイクは、なりすましによる送金指示など、詐欺の手口としても使われます。

社内側の備えとしては、「音声や映像だけで重要な指示を受け付けない」という取り決めが有効です。

悪用リスク①｜プロンプトインジェクションとプロンプトリーキング

	何をされるか	どこから来るか
プロンプトインジェクション	意図しない動作をさせられる	利用者の入力、読ませた文書やWebページ
プロンプトリーキング	システム側の指示文を吐き出させられる	巧妙な問いかけ
ジェイルブレイク	制限を回避させられる	役割設定の悪用など

いちばん実害が出やすいのは1行目の「読ませた文書」経由です。社外から届くメールやWebの内容を処理させる仕組みでは、その文書自体が指示として解釈され得ます。外部の入力は「データであって命令ではない」と設計で分けてください。

悪用リスク②｜AI生成コードと、サプライチェーンの脆弱性

生成されたコードには、脆弱性を含む書き方や、存在しないライブラリの参照が混ざります。

後者はそれ自体が攻撃経路になります。実在しない名前のライブラリが提案され、攻撃側が先にその名前で悪意ある部品を公開しておく、という手口です。依存関係の一覧（SBOM）を持ち、更新を追ってください。

悪用リスク③｜モデル汚染・データ改ざん・推論APIの悪用

• データポイズニング（モデル汚染） — 学習や参照に使うデータへ、誤った情報を混ぜ込まれる
• 推論APIの悪用 — 鍵が漏れると、費用を負担させられ、社内データにも触れられる
• 大量アクセスによる費用の膨張 — 攻撃されなくても、ループする実装だけで起きる

APIの鍵は、人ではなく用途ごとに発行してください。止めるときに、その用途だけを止められます。

悪用リスク④｜シャドーAIと、規制・コンプライアンス

シャドーAIとは、会社が把握していないところで生成AIが使われている状態です。禁止すると増えます。

規制面では、個人情報の取り扱い、業種ごとの表示規制、データの保管国、監査に応じられる記録の有無を確認します。これらはツールを選ぶ前に、社内側で決める項目です。

OWASP Top 10 for LLM で全体像を確認する

LLMを使うアプリケーションの脅威を体系立てた一覧が公開されています。プロンプトインジェクション、機密情報の漏洩、不適切な出力処理、システムプロンプトの漏洩、ベクトルと埋め込みの脆弱性などが並びます。

自社で作る場合は、この一覧を要件定義の段階でチェックリストとして使ってください。RAG（社内文書を参照させる仕組み）を使うなら、参照範囲そのものが権限の境界になる点に注意が要ります。

対策①｜入力ルールを設ける

• 入力してよい情報を、先に列挙する
• 個人情報・顧客情報・未公開情報の扱いを区分する
• 判断に迷ったときの相談先を書いておく

1行目が抜けている規程は、読まれても守られません。「だめなもの」より「いいもの」を書くほうが、現場は動けます。

対策②｜アクセス権限を、部門・用途ごとに分ける

全社で同じ設定にすると、いちばん厳しい部門に合わせるか、いちばん緩い部門に合わせるかの二択になります。

用途ごとに環境を分け、参照できるデータの範囲を、その業務に必要なぶんだけにしてください。

対策③｜学習に使われない契約と、閉じた環境

構成	中身	向いているとき
法人向けサービス	学習に使わない設定で契約する	一般的な業務。すぐ始めたい
API利用	学習に使われない条件で組み込む	自社システムに入れる
プライベートな環境	閉じたネットワークの中で動かす	社外に出せないデータがある

3行目を選ぶ前に、運用を持つ人がいるかを確認してください。閉じた環境は安全ですが、止まったときに直すのは自社になります。

対策④｜ログの取得と、利用状況の可視化

誰が、いつ、何に使ったかを残します。ログが取れない製品は、事故が起きたときに範囲を確定できません。

あわせて、「正しく使われているか」を定期的に確認する場を決めてください。取っただけで見ないログは、無いのと同じです。

対策⑤｜出力のファクトチェックと、入出力の制限

• 外部に出る文書、金額の確定、契約に関わる判断は人が確認する
• 入出力に制限（ガードレール）を置き、個人情報や禁止表現が通らないようにする
• 出典を示せない内容は、そのまま使わない
• 生成物の作成過程を記録に残す

2行目は、入口の対策を全部やり切れないことへの備えです。新しい手口は次々に出るので、出口に検査を置いておくほうが確実です。

対策⑥｜ガイドラインの策定と、従業員教育

ガイドラインには、入力してよい情報の区分、出力を使ってよい範囲、記録の残し方、相談先と連絡経路を書きます。

1ページに収まらないガイドラインは読まれません。詳細版とは別に、1枚の要約を配ってください。教育では、出力をそのまま使わないことを、心構えではなく手順として教えます。

対策⑦｜定期的なリスク評価とインシデント対応

業務が増えれば、扱うデータも変わります。年に一度は、使っている業務の一覧とリスクを見直してください。

あわせて、入力してはいけない情報を入れてしまったときの連絡経路と、止め方を決めておきます。事故は起きる前提で、報告しやすい形にしておくのが実務です。

業界ごとに異なる法規制への対応

金融、医療、公共のような規制産業では、データの保管場所、監査への対応、説明できる記録の保持が要件になります。

この場合、選定の順番が逆になります。性能から選ぶのではなく、要件を満たす構成を先に絞り、その中で比べてください。

生成AIのセキュリティに関するよくある質問

Q. 生成AIのセキュリティリスクには、どんなものがありますか。
入力（機密情報の漏えい、学習への流用、データが残り続けること）、出力（ハルシネーション、著作権侵害、バイアス、誤情報の拡散）、悪用（プロンプトインジェクション、AI生成コード、サプライチェーン、モデル汚染、シャドーAI）の3方向に分けて整理できます。

Q. 生成AIは禁止したほうが安全ではないですか。
逆効果になることが多いです。業務で必要な人は個人のアカウントで使い始め、何が入力されたのかを会社が知り得なくなります。使ってよい環境を先に用意してください。

Q. まず何から手をつければよいですか。
入力してよい情報を先に列挙することです。禁止事項だけを書くと、「これは書いていないから大丈夫」という判断が現場で起きます。あわせて、学習に使われない設定の環境を用意します。

Q. 入力した内容が学習に使われないようにするには。
法人向けの契約やAPI利用で、学習に使わない条件を選びます。画面の設定と契約上の取り扱いが一致していないことがあるので、条項まで確認してください。データの保存期間と削除依頼の手段も、選定時の確認項目です。

Q. プロンプトインジェクションは、どう防ぎますか。
外部から来る文書を「データであって命令ではない」と設計で分けます。ただし入口を全部塞ぐことはできないため、出口に検査（ガードレール）を置いてください。個人情報や外部送信の指示が出力に混ざっていないかを確かめます。

Q. シャドーAIを防ぐには、どうすればよいですか。
禁止ではなく、使ってよい環境の用意と、利用状況の可視化です。誰がいつ何に使ったかのログが取れる製品を選び、定期的に確認する場を決めてください。

ここまでが、生成AIのセキュリティの教科書どおりの整理です。入力・出力・悪用の3方向でリスクを並べ、規程を作り、権限を分け、ログを取り、教育する。対策の一覧としては、ここに出そろっています。

この記事の後半で扱うのは、その先です。この一覧どおりにガイドラインを作り終えた会社が、そこから先へ進めなくなるのは、なぜなのか。

①ガイドラインを作ったのに、そこから先へ進まない理由

生成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. 外部を使いながら、事業者にも中身を見せないことはできますか？

機密計算がその方向です。保護された実行環境の中でだけ復号して処理し、事業者の管理者からも中身が見えない構成にします。リモート・アテステーションで、想定どおりの環境かを利用する側が検証できる。外に出すか出さないかという場所の二値が、検証できる保証があるかという軸に置き換わりつつある、と捉えると分かりやすいと思います。

今日は、鍵を二値で考えるのをやめよう、という話をしました。

そう言えば、うちの実家の勝手口はドアを開ける時に大きく「キー」っと音がします。それが鍵を突破した後に一階に眠る両親にバレずに夜遊びするための最大の難関でした。

鍵を突破された後の、「フェイルセーフ設計」が効いていたということです。

さようなら。