コスト圧力から、組織が検証の甘いモデルに傾くなか、コードが増えるほどリスクへの露出も増えます。
従来のサイバーセキュリティ上のリスクであれば、決定論的なツールでペネトレーションテストを実施できます。ソフトウェアがどう反応するかも予測でき、悪用される前に脆弱性を見つけられる可能性も十分にあります。
ところが今、私たちが向き合っているのは新しいタイプのリスクです。LLMやAIモデルには、従来のセキュリティ手法ではスキャンできず、事実上検出も困難な「見えないリスク」が存在します。攻撃者は、現在のテスト手法では容易に見抜けない形で、悪意のある挙動や意図しない挙動をモデルの内部に埋め込めるのです。
その影響はツールの限界にとどまらず、あまり目立たない領域、つまりベンダーとの関係にも及びます。当社が取引するサイバーセキュリティベンダーは、いずれも「思考のパートナー」を自認しています。その主張が試されるのが今です。「これをどうスキャンするのか」という問いに対する正直な答えは、完全にできる者は誰もいない、というものだからです。契約の更新は、これまでどおり、統制の有効性、アーキテクチャ、エビデンス、対応能力に基づいて判断します。それは当然のことです。私がここに加えたいのは、失格条件です。私たちの誰もがまだ描き切れていない脅威モデルについて、こちらに何も教えられないベンダーは、他の評価項目でいかに高得点であっても、この課題に取り組むパートナーとして望ましくありません。
最先端の有償AIモデルにするか、検証の甘いオープンウェイトモデルにするか。この判断は容易ではありません。料金体系、隠れたオーバーヘッド、運用リスクには大きな差があります。有償モデルを選ぶか否かにかかわらず、コスト圧力は現実のものです。しかし、出自を確認できないモデルを導入する場合には、看過できない脅威があります。
オープンウェイトの「謎のレシピ」に潜む固有のリスク
オープンウェイトモデルは、ローカルで実行したりファインチューニングしたりできる完成品のモデルを提供します。一方、モデルの作成に使われた学習データやスクリプトの透明性は、通常は確保されていません。多くの場合、オープンウェイトAIのレシピには重要な材料が欠けています。
オープンソースモデルには、より高い基準が課されます。Open Source Initiativeの定義は、データに関する詳細な情報、学習・推論のコード、パラメーター、そして利用・調査・改変・共有の自由を認めるライセンスを求めています。学習データをすべて再公開する必要まではありませんが、有能な第三者がモデルの成り立ちを検証できるだけの情報は必要です。ソースが入手できることと、テストできることは別の話です。大規模モデルの監査が簡単だと言う人はいないでしょう。それでも、情報に基づいた問いを立てられるようになります。オープンウェイトでは、まさにそれができません。
この区別は、業界のあいまいな用語法が示唆する以上に重要です。「オープンソースAI」と呼ばれるものの大半は、実際にはオープンウェイトであり、出自の分からないダウンロード可能な成果物にすぎません。私たちはレシピを検査しているのではなく、できあがった料理を信用しているだけです。
オープンウェイトモデルは普及が進んでいますが、そこにはトレードオフがあります。データの透明性が欠けることで、リスクが高まるのです。リスクの形は、バックドアとデータポイズニングです。オープンウェイトモデルの数値パラメーターの中に隠されたキーフレーズのような単純なものが、悪意ある挙動の引き金になるかもしれません。エンドユーザーにとっては意図しない挙動ですが、モデルの公開者にとっては十分に意図したものである可能性があります。
ここでは、エビデンスの現状を正確に述べておきたいと思います。この点で議論が雑になりがちだからです。実環境で確認されているのは、リポジトリ上のマルウェアです。JFrogは、Hugging Face上に、読み込み時にコードを実行する悪意あるpickleシリアライズ形式のモデルがあることを報告しました。これは現実の攻撃ですが、すでに対処法が分かっているパッケージングの問題です。一方、パラメーターにトリガーフレーズが潜む潜在的な挙動バックドアは、AnthropicのSleeper Agents研究のような管理された研究や、PoisonGPTのような概念実証で実証されているにとどまります。本番環境での侵害として報告された例はまだありません。
とはいえ、研究がすでに何を実現しているかを見てみましょう。Winter Soldierでは、研究チームが事前学習トークンの0.005%未満、つまり64件のドキュメントを汚染し、学習データには一切登場しない隠れたプロンプトと応答のペアをモデルに学習させました。コーパスを監査しても見つかりません。そもそもどこにも書かれていないからです。本番規模の脅威にはまだなっていませんが、この手法が機能することは示されており、あとは誰かが巧妙に隠蔽する手段を見つけるのを待つ状態です。
この点こそ、備える価値があります。検出の非対称性は防御側に不利に働きます。こうした挙動は安全性トレーニングを生き延びますし、重みの中から探し出すには、私たちの大半が割ける以上の計算資源が必要です。私たちは今、仮に届いても見えないものについて、供給元を選んでいるのです。米国に有力なオープンモデルが十分になければ、中国製モデルに頼ることになります。それはまさにこの不確実性の下で張る賭けです。
Metaは最近、Apache 2.0ライセンスの300億パラメーターのモデル「Muse Glimmer」を発表し、フラッグシップの「Muse Spark 1.2」についても重みを公開する計画です。報道の多くはGlimmerをオープンソースと呼んでいましたが、実際にはオープンウェイトです。Metaが公開したのはパラメーターであり、学習データや学習コードではありません。業界メディアに見られるこの混同は、私たちのアーキテクチャレビューにも現れるものと同じで、どちらの場でも正す価値があります。この動きは、OpenAIやAnthropicを意識し、中国製モデルの相次ぐ公開に対して米国のモデルを強化する狙いがあるように見えます。
サイバー面の責任を考える
重大なサイバーインシデントが起きたとき、誰に責任があるのでしょうか。OpenAIやAnthropicの有償モデルを使っているのであれば、サイバー侵害の責任の所在は比較的はっきりしています。これは、主要なフロンティアモデルを選ぶ利点の一つです。
では、代替策はどうでしょうか。Hugging Faceからオープンウェイトモデルを取得し、サイバー上の災厄が起きた場合、誰が責任を負うのでしょうか。その契約の向こう側にベンダーはいません。オープンウェイトモデルは、有償モデルにはない形で賠償責任を生む余地があり、その責任はCSOにのしかかります。
地政学的な含意の微妙な違いを見極める
データ主権は昔から難題でした。昨年末のある時点で、TikTokは、米国の膨大なデータを中国に流出させているとの懸念から、米国で禁止される予定でした。2026年1月、TikTokが米国事業の過半数の所有権を米国主導の投資家グループに移す合弁事業を完了したことで禁止は回避されましたが、同じ懸念の一部は今も残っています。
検証の甘いオープンウェイトモデルをめぐる問題は、TikTokの状況と重なります。相手は普通の企業ではなく、地政学上の敵対国と結びついた企業です。違いは技術面にあります。バックドアやデータポイズニングの脅威は、実行方法がはるかに巧妙で、はるかに見えにくいのです。中国政府の機関にハッキングされなかったとしても、モデルに悪意ある挙動を埋め込める攻撃者は他にいくらでもおり、手遅れになるまで気づけない可能性があります。
Metaが新たなオープンウェイトモデルを公開したことで、米国でオープンな取り組みがさらに広がることを期待したいところです。しかし、悩ましい計算は残ります。自社の知的財産を預けるうえで、Metaを中国政府以上に信頼できるのか、という問いです。
有償モデルとオープンモデルを切り分ける
解決策は、より厳格なガードレールです。現時点で選択肢は二つあります。有償モデルを選んでオープンウェイトを避けるか、オープンウェイトモデルを採用してこうした脅威への防御を構築するかです。後者には、相応の時間とリソースが必要です。
フロンティアモデルを選ぶほうが簡単に思えますが、代償もあります。AnthropicやOpenAIを使う場合、オープンウェイトの提供元と比べて10倍程度の料金を払うことになりそうです。高額な初期費用は、誰もが負担できるわけではありません。
では、オープンウェイトを選ぶ場合、悪意ある挙動をどう防げばよいのでしょうか。一つは、トリガーそのものは防げなくても、その結果としてのアクションは防げると理解することです。重みをスキャンできないのであれば、対策の焦点は、モデルに何を許可するかという下流に移ります。
具体的には、特定のアクションはユーザーの承認なしにモデルが実行できないよう指定することです。これは難しい作業です。悪意ある活動が、Webサイトにアクセスしてハートビートを送り、その後に有害な挙動を起動するといった単純なものである可能性があるからです。モデルがアクセスできるのを検証済みのドメインだけに限定すれば、リスクは絞り込めます。ただし、どれも完全な対策ではありません。だからこそ、取引するすべてのサイバーベンダーとの対話で取り上げるべきなのです。
サイバーをめぐる対話をCSOの好機に変える
こうした検出しにくい脅威が迫っていても、リスクの状況は悲観一色ではありません。リスクを軽減し、悪意ある結果を防ぐ機会は確かにあります。その大半は、すでに費用を払っているベンダーを通じて実現されます。
サイバーセキュリティ契約を見直す際には、攻撃ベクトルが根本的に変わったことを考慮すべきです。これまで考えられなかった規模でコードを生成すれば、かつてないほどリスクへの露出が増えます。その規模は、過去の脅威とは比べものになりません。
ベンダーは、人間にかつて可能だった量を上回るコードを分析できるかもしれません。しかし、コードレビュー監査やペネトレーションテストといった人間の手法を、AIによるコード生産の規模に合わせて拡大するには限界があります。人間がやることを、ただ高速に自動システムにやらせても、ギャップは埋まりません。
別の道は、これらのシステムが根本的に異なる能力を持つと受け入れることです。非構造化で非決定論的なデータを処理できるのであれば、サイバーセキュリティをどう考え直すべきでしょうか。決定論的な出力を測るだけでなく、システムの行動の背後にある意図をどう評価すればよいのでしょうか。
これこそ、ベンダーに投げかけるべき問いです。AIを追加する、規模を拡大する、より多くをより速くこなすといった答えでは不十分です。それは量の問題に、さらなる量で答えているだけだからです。本当に難しい問題は、もはや成果物を読むだけでは挙動を保証できないことにあります。モデルを本番環境に投入する前に、何を要件としているかを尋ねてください。検証済みの公開者、固定されたバージョンとハッシュ、安全なシリアライズ、実際に稼働しているものの一覧などです。さらに、モデルが重大な結果を招く操作を要求したとき、ランタイムで何が起き、モデルの外部で誰が許可するのかも尋ねてください。答えを聞けば、ベンダーがこの問題を真剣に考えているのか、単にスキャナーを包装し直しただけなのかが分かります。
こうした問いは、通常の更新判断の基準に取って代わるものではありません。しかし、この対話ができないベンダーは、それ自体が何かを物語っており、私は真剣に受け止めます。これらの重要な問いに満足な答えが返ってこないなら、そのサイバーベンダーとの契約は更新しません。
