OWASP「LLM Top 10 2025」と法務――『安全』がセキュリティに化ける瞬間雑感

0　はじめに

　年越しに書き溜めたAIに関して役立つ資料について雑感を付して7点掲載する。今年も皆さんにとっていい年であることを心より祈念する。

　AIの議論は、しばしば性能や倫理から始まる。しかし、組織にとって刺さり方が一番早いのはセキュリティである。というのも、生成AIは“賢い道具”である前に、ネットワークにつながり、データを吸い、権限を持ち、行為を起こすシステムだからである。

　この点を雑に扱うと、AIは一気に便利な機能から事故の起点へと変化する。しかも、その事故は、誤回答のような分かりやすい失敗にとどまらない。情報漏えい、権限濫用、サプライチェーン汚染、コスト爆発、そして説明責任である。

1　問題の所在

　Open Worldwide Application Security Project（OWASP）が公表する「Top 10 for LLMs and Gen AI Apps」は、生成AI／LLMアプリの主要なリスクと緩和策を整理したものである（注1）。同プロジェクトは、2023年にコミュニティ主導で始まった旨を明示しており（注2）、いわゆる“現場の知”が、分類学として結晶化したものだといえる。

　法務の観点から重要なのは、これが「法律」ではないにもかかわらず、実務ではしばしば“準・基準”として機能する点である。事故が起きたとき、裁判所や監督当局がまず問うのは「当時の合理的な安全措置は何だったか」であり、その答えは、法令の条文だけからは出てこない。技術標準、ガイドライン、業界慣行が、過失判断や契約解釈の足場になる。OWASPのTop 10は、その足場の候補である。

2　OWASP LLM Top 10 2025の輪郭

　2025年版のTop 10は、LLM01 Prompt InjectionからLLM10 Unbounded Consumptionまでの10項目で構成される（注1）。個別の中身を全部なぞるのは本稿の目的ではないが、輪郭だけでも、法務が刺されるポイントが見えてくる。

　第一に、対象がモデルではなくアプリケーションである点である。たとえば、ベクトルDBや埋め込み（embedding）を用いるRAG（Retrieval Augmented Generation）に固有の弱点（LLM08）が独立の項目として立っている（注10）。第二に、「エージェント化」を前提とした統制論が前面に出ている。過剰な代理（Excessive Agency）は、ツール／プラグイン等を呼び出して行為する設計そのものの危うさを問題化する（注8）。第三に、虚偽情報（Misinformation）や、推論の乱発によるDoS・経済損失・モデル窃取等（Unbounded Consumption）が、明確にセキュリティ問題として位置づけられている（注11・注12）。要するに、生成AIの失敗は、品質問題でも倫理問題でもあるが、それ以前にセキュリティ問題として扱われ始めた、ということである。

3　断片化という問題と因果関係の特定

　LLMアプリの事故対応で最も厄介なのは、原因が「断片化」することである。モデルの不具合なのか、プロンプトの設計なのか、RAGの参照元なのか、ツール呼出しの権限設計なのか、ログ設計なのか。どれか一つが単独で悪いというより、断片が噛み合ったところで事故が起きる。

　この断片化は、責任の断片化でもある。基盤モデル提供者、API提供者、アプリ開発者、追加学習データの提供者、運用者、そして利用部門が、それぞれ別の合理性で“正しいこと”をしても、接続点で破綻する。法務の仕事は、事故後に「誰が悪いか」を探すことではなく、事故前に「どこが壊れるか」を契約と統制で先に塞ぐことである。

　象徴的なのがPrompt Injectionである。OWASPは、ユーザ入力がLLMの挙動や出力を意図しない形で変えてしまう脆弱性だと定義し（注3）、外部のウェブページやファイル等を取り込むことで起きる「間接」型も含むとする（注3）。しかも、RAGや微調整（fine-tuning）は有効な手当でありつつ、これだけではPrompt Injectionを完全には防げない、とされる（注3）。さらに、生成AIの性質上、完全無欠な予防策が存在するかは不明であり、影響を減じる方策が中心になる、という含意も読み取れる（注3）。

　ここで法務が困るのは、事故の因果関係の特定が、技術説明にとどまらない点である。誰が、どの権限で、何を接続し、どのログを残し、どの段階で止められたのか。つまり、統治（ガバナンス）の説明になる。LLM05のImproper Output Handlingが、LLM出力を十分に検証・無害化せずに下流のシステムへ渡すことを問題化し、「ユーザに間接的に追加機能へのアクセスを与えるのと似ている」と述べるのは（注7）、まさにこの接続点の危うさを言い当てている。

4　法的含意――「合理的安全措置」はどこに宿るか

　法は、万能のセキュリティ仕様書ではない。そこで実務上は、(i) 事故の予見可能性、(ii) 採るべき措置の合理性、(iii) 措置の実施状況を示す証跡、という三点セットが問われることになる。OWASPのTop 10は、この三点セットを作るためのパーツを提供する。

　たとえば、機微情報の漏えい（LLM02）は、個人情報、財務情報、医療情報、機密の業務データ、認証情報、法務文書等を含むとされ（注4）、アプリに組み込まれたLLMがそれらを出力で露出させ得ると指摘する（注4）。さらに、利用規約による透明化やオプトアウト、入力のサニタイズ等を挙げつつも、システムプロンプト上の制約はPrompt Injection等で迂回され得る、とする（注4）。ここから導かれるのは、「ルールを書いた」だけでは足りず、設計上、漏れない・漏れても拡大しない構造が必要だということである。

　同様に、システムプロンプト漏えい（LLM07）は、モデルの挙動を誘導するための指示（system prompt）自体に、意図せず秘密が含まれ得て、それが露見すると他の攻撃を容易にし得る、と説明する（注9）。これは、プロンプトを「単なる文章」ではなく、秘密情報や統制情報を含む構成要素として扱え、という実務的メッセージである。情報管理・秘密管理の論点が、プロンプトにまで降りてきた、と言ってよい。

5　実務への示唆――法務がいま手を入れられるところ

　OWASPのTop 10は技術文書であるが、法務が関与できる余地は大きい。むしろ、ここを放置すると、現場が勝手に接続し、勝手に権限を渡し、勝手にログを捨てる。後から「責任の所在」を探しても遅い。

　第一に、「権限設計」を契約と統制で固定することである。LLM06のExcessive Agencyは、拡張機能（tools／plugins等）を呼び出して行為する能力を与えること自体がリスクであり、どの拡張を呼ぶかの判断をエージェントに委ね得る点まで含めて問題にする（注8）。ここは、最小権限、二重承認、不可逆行為の隔離、ログ、といった古典的な内部統制で殴れる領域である。法務は、設計原則を社内規程・委託契約・SLA・インシデント条項に落とし込み、「やっていなかった」を防ぐ役割を持つ。

　第二に、「供給網」を見える化することである。LLM03のSupply Chainは、学習データ、モデル、デプロイ基盤などの外部要素が改ざんや汚染の対象になり得るとし（注5）、オープンなLLMやLoRA／PEFT等の微調整、Hugging Faceのようなプラットフォームの普及が新しい供給網リスクを持ち込むと指摘する（注5）。LLM04のData and Model Poisoningも、データ操作によるバックドアや偏りの注入を問題化し、特に外部データソースの危うさを強調する（注6）。ここは、ベンダ選定、成果物検収、変更管理、そしてモデル／データの来歴（provenance）を文書化する統治の問題である。

　第三に、「出力を信用しない」ことを制度化することである。LLM09は、幻覚（hallucination）等により、もっともらしい虚偽情報が生じ、レピュテーション毀損や法的責任につながり得ると述べる（注11）。LLM10は、過剰で制御されない推論が、DoS、経済損失、モデル窃取、サービス劣化等を招き得るとする（注12）。この二つは、品質管理にも見えるが、実態は「運用の安全保障」である。重要な意思決定に使う場面では、出力形式の検証、根拠（参照元）提示、レート制限、監視、停止権限の所在、といった仕組みが不可欠になる。

6　雑感

　生成AIをめぐる法の議論は、抽象論に寄りがちである。しかし、OWASPのTop 10を読むと、現場で起きるのは驚くほど俗っぽい。「誰にどこまで権限を渡したか」「どのデータを食べさせたか」「その接続を誰が承認したか」「何をログに残したか」。要するに、データと権限の統治である。

　そして、事故が起きた瞬間、セキュリティは説明責任に化ける。法務がやるべきことは、技術を代替することではない。断片化したシステムの中で、責任の断片化を防ぐ設計、つまり、権限・証跡・契約・規程の接着剤を入れることである。OWASP Top 10は、その接着剤をどこに塗るべきかを教えてくれる地図の一つである。

（マガジン）「AIと法-雑感」

　※目次は以下を参照

note総則規約3条2項前段
3.2 クリエイターが制作したデジタルコンテンツの著作権は、クリエイターに帰属します。