3月19日の「JDLA Connect x CDLE All Hands」や、その後の飲み会などで、AI時代の最新のサイバーセキュリティについて、非常に興味深く、素晴らしい内容のお話を拝聴し、有意義な時間を過ごさせていただきました。
CDLEサイバーセキュリティグループの皆さん、本当にありがとうございました。
そこでのお話は、ひとつひとつが非常に納得感のある有用なものでしたが、私の理解が追い付いていないのか、どうしても全体として腹の中に落ちてこない、そんな感覚が残りました。
それを払拭するために、私なりの切り口で、「AI時代のセキュリティについての大前提」を整理してみました。この前提があることがスタートだとすると、少しずつ見えるものがあるのではないか？と感じています。
ひょっとしたら当たり前に、どこの企業も出来ているものなのかもしれません。
もしくは、私の考えが偏っていたり、考え違いをしている部分もあるかもしれません。
言っても仕方がない理想論を語っているだけかもしれません。
そんなご意見を、ぜひ！いただければと思います！
-------- ⚡ 🛡 ⚡ 🛡 ⚡ 🛡 ⚡ 🛡 ⚡ 🛡 ⚡ 🛡 ⚡ --------
⚡ 序文 🛡
AIのセキュリティについて、インターネットなどで調べていると、まず目に入るのは技術的な対策です。
・プロンプトインジェクションをどう防ぐか？
・ガードレール（制御）をどのように追加するか？
・ログをどのように取得して監視するか？
AIは新しい技術なので、その性質や振る舞いを十分に理解していない人も多く、こうした議論が多いのは自然な流れだと感じます。とくに自律型AIエージェントのような仕組みは、まだ実装や評価の知見が蓄積している途中にあり、その実装や評価に関する議論が主題となるのは当然だと思います。
ただ、企業でAIのセキュリティを考えるとき、技術的な対策から入ると危険ではないか？と感じます。技術的な対策は、表面に見えている問題に対応することはできます。
しかしAIは、内部がブラックボックスになっていることが多く、厳密にいつも同じように動く仕組みではありません。そのため、特定の挙動を抑える対策を積み上げても、まだ表面化していない漏洩の仕方や、想定していなかった情報の露出まで網羅できるとは限りません。
たとえば、プロンプトインジェクション対策は発生確率を下げることはできても、完全に発生しないことを保証するものではありません。ガードレールも、既知の危険な入出力を抑える補助にはなっても、許可条件を完全に定義しきれるわけではありません。監視やログ取得も、起きたことを追跡しやすくはしますが、それ自体が漏洩を防ぐ保証にはなりません。どれも必要な技術ではありますが、それだけで「100%安心です！」とは言い切れないものです。
個人の実験であれば、こうした不確実さは自己責任であり、試行錯誤している途中だから仕方ない…で済みます。しかし企業では、そうはいきません。失敗は単なる実験失敗では終わらず、情報漏洩、信用失墜として表面化します。
そして一度失われた情報や信頼は、「後から気付いて対応する」だけでは取り戻せません。
私としては、この考え方が根底にあり、それを前提として「AIセキュリティ」について考察していきたいと思います。
⚡セキュリティの前提：特定の条件下で100%信頼できる境界を作ることを目指す🛡
セキュリティを「漏洩確率をどこまで下げられるか？」という話として考えると、議論の焦点がぼやけます。99%安全、99.9%安全といった表現は一見合理的ですが、守る対象によっては意味を持ちません。漏洩してはいけない情報において重要なのは、確率の大小ではなく、漏洩する構造になっているかどうかです。
たとえば、認証情報、秘密鍵、権限トークン、管理者権限のようなものは、「ほぼ安全」という前提では扱えません。一度でも到達されれば重大な問題になるからです。必要なのは、漏れる可能性を下げる工夫ではなく、そもそも、漏洩してはならない「もの」に到達できないこと、使えないこと、越えられないことです。セキュリティとは、その状態を設計することです。
ここで言いたいのは、すべてを絶対安全にしろということではありません。少なくとも守るべき境界については、確率ではなく「構造」で語るべきだということです。秘密であれば「偶然漏れなかった」では足りませんし、権限であれば「普段は誤作動しない」では足りません。想定した条件のもとで、必ず守られることが必要になります。
この視点に立つと、セキュリティは事故率を減らす対策ではなくなります。何を見せてよいのか、誰が触れてよいのか、どこで止めるのか、どこから先には進めないのか。先に定義すべきなのは、こうした「境界」です。対策や技術はその後に来ます。順番が逆になると、防御策を積み上げても肝心の境界は開いたままです。
つまり、セキュリティとは曖昧な安心感を積み上げることではありません。守るべき条件を先に定め、その条件の中で確実に破れない境界を作ることです。そこを外せば、その後の議論は枝葉になります。
⚡クレジットカード情報やパスワード漏洩のレベルでAIセキュリティを語るのは適切ではない🛡
クレジットカード情報やパスワード漏洩のような話を、そのままAIセキュリティの論点としていること自体、考え方の順番が逆です。問題は、AIが危険かどうかではありません。そうした情報をAIが参照できる状態に置いている設計そのものです。
パスワードは典型です。まず、平文や復号可能な状態で扱うこと自体が不適切であり、AIに入力してよいかどうかを議論する以前に、可逆な形で使われないよう設計されていなければなりません。クレジットカード情報も同じです。業務上どうしても必要な場面を除き、見える場所、共有される場所、加工される場所を厳しく制限するべき情報です。つまり、これらは「AIに入れると漏れるかもしれない」という種類の話ではなく、そもそもAIに見せる前提を作ってはいけない情報です。
ここで問うべきなのは、AIの安全性ではありません。情報の取り扱い方です。どの情報を誰が見られるのか。どの処理系に渡してよいのか。どの形式なら許されるのか。こうした条件が先に定義されていないなら、問題はAIではなく情報設計の欠落です。
AIセキュリティの話としてクレジットカード情報やパスワード漏洩を持ち出すと、論点がずれます。本来は、入力してよい情報と、入力以前に排除されるべき情報を分けなければなりません。その区別がないままAIの危険性だけを論じても、設計の不備を別の言葉で言い換えているだけです。
つまり、クレジットカード情報やパスワード漏洩をAIセキュリティとして語ること自体が、すでに前提を誤っています。そこで露呈しているのはAIの問題ではなく、見せてはならない情報を見せうる形で保持し、流通させ、処理しようとしている側の問題です。
⚡プロンプトインジェクションは防げないので、発生することを前提に設計しなくては意味がない🛡
プロンプトインジェクションは、工夫すれば防げる種類の問題ではありません。
悪意ある入力に対して、入力チェックや追加コンテキストを加えても、その影響を完全に排除することはできません。これは、LLMが入力を解釈に取り込みつつ、振る舞いが固定されていない仕組みであるためです。そのため、出力を常に意図した通りに保証することはできません。
ここで重要なのは、プロンプトインジェクションが起きるかどうかを争点にしないことです。起きることを前提にしなければ、設計は成立しません。防げるかどうかに議論を寄せると、対策は入力の監視や禁止表現の追加に偏ります。しかし、それでは入力の違いやその時の振る舞いによって結果が左右されてしまいます。問題は入力そのものではなく、その入力によって重要な情報が漏洩してしまう構造になっているかです。
したがって、設計で先に決めるべきなのは、プロンプトインジェクションをなくす方法ではありません。たとえ起きても、秘密が見えないこと、権限外の操作が成立しないこと、禁止された情報経路が開かないことです。LLMが入力に引きずられることは避けにくくても、その結果として越えてはならない境界が守られていれば、被害は成立しません。
逆に言えば、プロンプトインジェクションが重大な問題になるのは、LLMの出力や判断がそのまま情報取得や権限行使につながる設計になっている場合です。そのとき露呈しているのは、入力対策の弱さではなく、境界設計の弱さです。AIがだまされることではなく、だまされたAIでも被害を出せることが問題なのです。
プロンプトインジェクションは、資産としてのプロンプトを守ることや、不正な利用を防ぐことから注目されてきました。しかし、企業で利用する場合は、それだけでは不十分です。
つまり、必要なのは、プロンプトインジェクションを防ぐことではなく、発生しても重要な情報が守られる設計です。その前提を考慮しないまま個別の対策を積み上げても、守るべきものは守れません。
⚡セキュリティはAI入力以前の人間への情報開示も含めたサプライチェーン設計である🛡
セキュリティをAIへの入力可否だけで考えると、議論は行き詰ります。問題は、その情報をAIに入れるかどうかだけではありません。その前に、そもそも人間に見せてよいのか？
共有してよいのか？保存してよいのか？外部基盤に置いてよいのか？を決めなければなりません。それは、「AI」も「情報を扱う人間」も完全に信頼できると保障できないからです。
たとえば、AIに入力するのは危険だと言いながら、同じ情報をメールで広く共有し、クラウドストレージに置き、複数人が自由に閲覧できる状態にしているなら、設計として一貫していません。どこに見せてよいのか、誰に触れさせてよいのか、どの段階で加工してよいのかという基準が先に必要です。AIはその後に位置づけられる対象です。
つまり、AIは情報流通の一工程にすぎず、そこだけを切り出して安全性を語っても意味がないのです。
ここで考えるべきなのは、単体のツールの安全性ではなく、情報がどこから来て、誰を通り、どこに保存され、どの形に変換され、どこまで届くのかという流れ全体です。人間、共有基盤、委託先、クラウド、ログ、検索、要約、AIは、すべて同じ流通経路の中にあります。セキュリティとは、その経路のどこで何を許し、どこで止め、どこから先を越えさせないかを定義することです。
この意味で、AIセキュリティはAIだけの話ではありません。情報流通全体の設計であり、より正確には「サプライチェーンの設計」です。入力元、保存先、処理系、利用者、外部連携先まで含めて設計しなければ、どこか一箇所だけを厳しくしても全体は守れません。AIだけを危険物として切り離しても、他の経路が開いたままなら結果は同じです。
つまり、セキュリティとは、AIに何を入れるかを決める話ではありません。その前に、情報を誰に知らせてよいのかを決める話です。そこが整理されていなければ、AIの安全性だけを論じても、設計の不備を見落とすだけです。
⚡すべての情報について漏洩リスクをゼロにしろと言うなら、AIは使えない🛡
「すべての情報について漏洩リスクをゼロにしなければならない」ことを前提とするなら、AIは実用に耐えません。なぜなら、AIは入力された情報を処理し、要約し、再構成し、文脈として保持しながら応答する仕組みだからです。そこに一切の漏洩可能性を認めないのであれば、利用そのものが成立しません。
ただし、ここで重要なのは、だから何でもAIに入れてよいという話ではない、ということです。「ゼロリスク」を前提にすれば使えない。しかし「無制限にリスクを受け入れる」であれば当然破綻します。必要なのは、その二択ではありません。情報の性質ごとに、どのリスクを許容し、どのリスクを禁止するかを設計することです。
情報には差があります。漏れた瞬間に重大な被害が確定するものもあれば、限定された範囲であれば実務上許容できるものもあります。さらに重要なのは、何が漏れるかだけではなく、「どこに漏れるか？」です。同じ情報でも、管理された内部環境で限定的に参照される場合と、悪意ある第三者に到達する場合では意味がまったく異なります。したがって、情報の取り扱いは、内容、利用目的、漏洩先、被害範囲まで含めて設計しなければなりません。
この問題はAIだけに特有ではありません。メール、クラウドストレージ、共有ドライブ、会議、委託、人間による閲覧も同じです。もしあらゆる情報に対して完全な漏洩ゼロを求めるなら、AIだけでなく、現代の情報業務そのものが成立しなくなります。つまり、問うべきなのはAIを使うか否かではなく、どの情報を、どの条件で、どこまで流通させてよいのかという基準を持っているかどうかです。
AIの利用判断も、その基準の上に置かれるべきです。禁止すべき情報は最初から入れない。条件付きで使える情報は、加工、匿名化、限定利用、保存制御などを前提に扱う。そこまで整理できて初めて、AIは業務の中で現実的に使えるものになります。逆に、それができないままゼロリスクだけを掲げるなら、結論は全面禁止しかありません。
つまり、すべての情報に漏洩ゼロを求める議論は、厳格に見えて、実際には設計を放棄しています。必要なのは、禁止と許容の境界を定めることです。AIを使えるかどうかは、その境界を引けるかどうかで決まります。
⚡境界を引けない企業は、AIを使う以前に情報が漏洩する🛡
ここまで述べてきたように、先に整理すべきなのは、AIの挙動そのものではありません。何を守るのか、誰に見せるのか、どこに保存するのか、どの条件で処理させるのかという設計です。これが定まっていない企業が、AIだけを特別に危険として扱っても意味はありません。問題はAIではなく、情報の扱い方そのものにあります。
情報漏洩は、AIがあるから起きるのではありません。共有範囲が曖昧で、権限管理が粗く、保存先の基準がなく、委託や外部基盤への持ち出し条件も整理されていない。そのような状態であれば、漏洩はAI以前に起こります。メールでも起こります。クラウドストレージでも起こります。会議資料でも起こります。人間の口頭共有でも起こります。AIは、その脆さを別の形で露呈させているだけです。
にもかかわらず、AIセキュリティだけを切り出して論じると、問題の所在を見誤ります。AIに何を入力してよいかが決められない企業は、そもそも人に何を見せてよいかも整理できていない可能性が高いのです。AIにどこまで処理させてよいかが決められない企業は、共有基盤や外部サービスにどこまで置いてよいかも定義できていない可能性が高いのです。それはAI運用の未熟さではなく、情報設計の未整備です。
この点を曖昧にしたまま、「AIは危険だ」「AIのセキュリティが難しい」と語るのは適切ではありません。そうした議論の多くは、AI特有の問題を指摘しているようでいて、実際には以前から存在していた管理不備を別の言葉で言い換えているだけです。AIを外せば安全になるわけではありません。危険なのはAIではなく、整理されていない情報流通です。
したがって、AIを使う資格があるかどうかは、モデルの精度や最新技術の導入状況で決まりません。情報を分類し、共有範囲を定め、権限を分け、保存先を選び、禁止と許容の境界を明確にできているかで決まります。そこができていない企業は、AIを使わなくてもいずれ情報漏洩します。AIの導入は、その事実を早く露出させるにすぎません。
つまり、AIセキュリティを語る前に問うべきなのは、AIを安全に制御できるかではありません。情報を安全に流通させる設計が、そもそも企業の中にあるかどうかです。そこが整理されて初めて、権限制御、監査、ログ、分離、アクセス制御、外部連携制御といった技術の議論が意味を持ちます。設計が曖昧なまま技術を積み上げても、守るべき境界は定まりません。順番は逆にできません。
⚡まとめ🛡
このような情報の整理は、日本においては非常に進みにくいという構造があります。
技術者の側から見ると、厳密な権限制御や統制は、通常時には仕事を円滑に進めにくくする制約として働き、障害時や緊急対応時には即応性を下げる要因となります。
しかも、その必要性を判断する管理側に十分な技術理解がなければ、申請や承認の過程だけが増え、現場の負担はさらに大きくなります。技術理解を伴わずに統制のみを強めることは、安全性を高めるのであればまだしも、不必要に自分の動きを鈍らせるだけの行為にもなりやすいので、積極的に動く理由にはなりません。
一方、管理側から見れば、セキュリティ設計はコストがかかり、運用も複雑になり、すぐに利益を生むものには見えません。しかもシステムが内製ではなく外注であれば、細かな制御や権限設計を自社の判断だけですぐ変えられるわけでもありません。必要性が十分に理解できないまま、費用と手間だけが先に見えれば、優先順位が下がるのは自然です。その結果、「現場でうまくやってほしい」「そこまで難しいなら新しいことはしないで欲しい」という判断に流れやすくなります。
また、今までの日本では人材の流動性が低く、業務が特定の人に固定されやすいため、暗黙の了解によって運用が成立しやすくなっていました。その結果、内部の人間を前提とした信頼の上で業務が成り立ちやすく、外部の存在に対しては強い警戒が働きます。AIもその延長で外部のものとして捉えられやすく、結果としてローカル環境での利用を志向する動きにもつながります。
しかし、現在では派遣社員や転職、外注の増加によって、その前提はすでに崩れています。それにもかかわらず、内部の人間を前提とした信頼の意識だけが残っており、実態とのズレが生じています。その結果、構造としてのセキュリティではなく、「内部であれば安全」という前提に依存したままになりやすく、リスクに気づきにくい状態が続いています。
だからこそ、必要であれば外部の専門家を入れてでも、整理を進めなければなりません。ただし、それは請負として丸投げすれば済む話ではありません。何を守り、どこに境界を引き、どの運用を引き受けるのかは、企業自身が決めるべきことだからです。とくに管理職が責任を持ってそこに積極的に関わらなければ、適切か不適切かの整理が進みません。
そのため、管理職の技術が不足している場合は、それを補う必要があります。
そして、立場上、社員が補うのは難しい状況にあります。
まず、日本の文化として管理職が技術に積極的に関わらない傾向があります。
その結果、社員である技術者に丸投げされます。
さらに、決裁権を持つ技術に明るくない管理職に対して説明責任まで負わされるため、時間ばかりがかかり、意思決定が進みません。
この状態では整理は進みません。
この理由から、この整理は管理職が耳を傾けざるを得ない外部の専門性なしには進まないと考えられます。
そこまでやって初めて、AIのセキュリティは現場任せでも禁止論でもない、実際に機能する仕組みになると思うのです。