AI・システム開発×セキュリティ　- 明示的な合意がない場合の責任範囲 –

AZX総合法律事務所の弁護士・鶴間です。
ベンチャー企業法務を中心に、資金調達、契約書整備、M&A、コーポレート業務等を支援しています。また、AI・データ利活用やセキュリティ分野にも関心を持ち、基本情報技術者試験やホワイトハッカー育成用のコースを受講するなど、技術理解の深化にも努めています。

こうした実務に携わる中で、システム開発契約における「セキュリティの水準」は、実務上しばしば問題となる論点の一つです。とりわけ、システムの受託開発を実施する場合において、本来はセキュリティの水準等についてもできるだけ契約書や仕様書に定めて合意した方が望ましいものの、契約交渉上の時間的な制約等から現実的に難しいことも多く、セキュリティ水準を含めた非機能要件の詳細について書面等による明示的な合意をしないケースも少なくないと思います。

しかし、開発された成果物等に関連してセキュリティに関するインシデントが発生した際には、ベンダが損害賠償責任等を負う可能性があることから、ベンダとしては、セキュリティ水準等について明示的な合意がない場合であってもどのような義務を負う可能性があるかについて、あらかじめ把握しておくことが重要であると考えられます。

また、「AIの利用をめぐるサイバーリスク」は、「情報セキュリティ10大脅威 2026」[組織]（独立行政法人情報処理推進機構（以下「IPA」といいます。））において第3位に位置づけられており、AIの利用に伴うサイバーリスクが近時とりわけ高まっているところ、このような状況を踏まえると、AIに関するセキュリティ水準等について明示的な合意がない場合であっても、AI開発者やAI提供者側としてはどのようなセキュリティ対策まで必要となるのかを把握しておくことが重要であると考えられます。

そこで、本記事では、セキュリティ対策等について明示的な合意がなされなかった場合を題材として、（1）代表的な裁判例及び（2）基本的な考え方を概観したうえで、これらを踏まえ、（3）AI開発に関するセキュリティの在り方について検討します。

1. 代表的な裁判例から見るベンダの責任

セキュリティ対策等について明示的な合意がなされなかった事例においてベンダの義務内容を検討した代表的な裁判例（東京地判平成26年1月23日判時2221号71頁。）について紹介します。

（1）  事案概要

当該裁判例は、システム開発のベンダがウェブサイトにおける商品受注システムを設計、製作したものの、当該システムの脆弱性に起因して情報漏えいが生じた事案であり、その原因は、SQLインジェクション攻撃によるものであると認定されました[1]。

（2）  攻撃手法に対する対策義務

■SQLインジェクション

裁判所は、以下の事情を考慮して、平成21年（2009年）のシステム開発時点において、情報漏えいを防止するために、ベンダにおいてSQLインジェクション対策として、バインド機構の使用又はエスケープ処理を施したプログラムを提供すべき債務が存在していたことを認定しました。

①経済産業省による注意喚起

『経済産業省は、平成一八年二月二〇日、「個人情報保護法に基づく個人データの安全管理措置の徹底に係る注意喚起」と題する文書において、SQLインジェクション攻撃によってデータベース内の大量の個人データが流出する事案が相次いで発生していることから、独立行政法人情報処理推進機構（以下「IPA」という。）が紹介するSQLインジェクション対策の措置を重点的に実施することを求める旨の注意喚起をしていたこと』

②IPAの公開文書

『IPAは、平成一九年四月、「大企業・中堅企業の情報システムのセキュリティ対策～脅威と対策」と題する文書において、ウェブアプリケーションに対する代表的な攻撃手法としてSQLインジェクション攻撃を挙げ、SQL文の組み立てにバインド機構を使用し、又はSQL文を構成する全ての変数に対しエスケープ処理を行うこと等により、SQLインジェクション対策をすることが必要である旨を明示していたこと』

このように裁判例においては、①経済産業省がSQLインジェクション攻撃について注意喚起を行い、②IPAが具体的なセキュリティ対策の手法を明記した文書を公開していたことを考慮して、具体的なセキュリティ対策の義務が認定されています。

 

■クレジットカード情報の暗号化等

他方で、当該裁判例では、「クレジットカード情報をサーバー及びログに保存せず、若しくは保存しても削除する設定とし、又はクレジットカード情報を暗号化して保存する対策を講ずべき義務」を負っていたかどうかも問題となりました。しかし、（i）当時のIPAの公開文書においては、これらの対策を構築することが「望ましい」とされていたにすぎないこと、（ii）暗号化の設定内容等は暗号化の程度によって異なり、それによって被告の作業量や代金も増減すると考えられることを考慮して、契約で特別に合意していなくとも当然に被告が上記対策を構築すべき義務を負っていた、とは認められない、とされています。

（3）  小括

以上のことから、当該裁判例においては、主要な行政機関等が公表するセキュリティ対策について、①必要性が強調されている部分は契約上の合意がなくても当然にベンダの対応義務があるものと認め、②「望ましい」レベルとなっている部分は一律に判断せず、経済合理性等も踏まえて慎重に判断されているものと考えられます。

2. 明示的な合意がない場合の基本的な考え方

セキュリティ対策等について明示的な合意がなされなかった事例に関し、確立された統一的な法的見解が存在するものではありませんが、内閣官房国家サイバー統括室が比較的最近公開した「サイバーセキュリティ関係法令Q&Aハンドブック」(令和5年9月（誤記訂正 令和6年12月）)Q45では以下のとおり当該事例における考え方について言及がなされています。

（1）  サイバーセキュリティ関係法令Q&Aハンドブック

上記ハンドブックでは、『システム開発の業務委託契約書や発注仕様にセキュリティ対策について記述されている場合はもちろんのこと、記述されていない場合でも、開発当時の技術水準に沿ったセキュリティ対策を施したプログラムを提供することが黙示に合意されていたとされ、特段の事情もなく既知の脆弱性についてセキュリティ対策を講じなかった場合、発注者に生じた損害の賠償義務を負う』ものとされており、上記の裁判例の内容をほぼ踏襲する形で当該Q&Aでは以下のような判断基準が示されています。

①既知の代表的なセキュリティ攻撃手法への対策

『システム開発の業務委託契約書や発注仕様にセキュリティ対策について記述されていない場合でも、既知の代表的なセキュリティ攻撃手法について、行政機関が対策の必要性及び対策の具体的方法を公表している場合、これに従ったプログラムの提供をしなければシステム開発ベンダが債務不履行責任を問われ得る』。

②「望ましい」と指摘するにすぎないセキュリティ対策

『行政機関が単に「望ましい」と指摘するにすぎないセキュリティ対策については、契約で特別に合意していなくとも当然に実施すべきものではない。』

（2）  代表的な裁判例との関係

上記1の裁判例は2014年の判決ですが、システム開発訴訟に関する主要な文献において繰り返し参照されており、同様の考え方が上記ハンドブックにおいて採用されている状況と考えられます。

本来、個々の裁判例における判断内容は基本的には他事例に対する拘束力を有するものではありませんが、上記1の裁判例の考え方は、代表的な行政機関の文書に掲載されていることから事実上の標準的な判断基準として参照され得るものと考えられます。

（3）  補足

なお、上記の判断基準は「行政機関」の公表の有無やその公表内容を考慮対象としているところ、行政機関以外、例えば業界団体の公開文書なども参照される可能性がある点には注意が必要です。実際に、クレジットカード番号等を取り扱うサイトについては、クレジットカード会社が定めるセキュリティの要件（PCI DSS）を充足する必要があると認定した裁判例（東京地判令和4年1月12日 D1-Law.com判例体系29068836）もあり、個別の業界により「技術水準」が変わり得る点に注意が必要となります。

3. AI開発において求められるセキュリティの在り方

上記の代表的な裁判例では、典型的な攻撃手法であるSQLインジェクションへの対策の欠如が問題とされましたが、SQLインジェクションは現在の技術水準に照らせばより一層当然に対策を講ずべきものと考えられます。

それでは、「情報セキュリティ10大脅威 2026」（IPA）にて「AIの利用をめぐるサイバーリスク」が初選出される等、最近、特にサイバーリスクが高まっているAIの利用について、AIモデルの開発者やAIを用いたサービスの提供者としては、どのようなセキュリティ対策を講ずるべき法的義務があるのでしょうか。

（1）  行政機関の資料

「情報セキュリティ10大脅威 2026」[組織]の解説書である『「情報セキュリティ10大脅威 2026」解説書［組織編］』においては、開発者や提供者目線での対策について具体的な言及はなされていませんが[2]、AIセーフティ・インスティテュートが「AIシステムに対する既知の攻撃と影響」（第2版。2026年4月24日）として、攻撃方法の整理を行った資料を公表しており、総務省が令和8年3月27日に当該攻撃に対する技術的対策について「AIのセキュリティ確保のための技術的対策に係るガイドライン」を公表しています。

詳細は割愛いたしますが、同ガイドラインは、主に①プロンプトインジェクション攻撃及び②DoS 攻撃（サービス拒否攻撃）への対策を示しており、AI提供者（AIシステムをアプリケーション等に組み込んだサービスとしてAI利用者等に提供する事業者）における対策として、例えば、（i）システムプロンプトの強化や（ii）ガードレール等による入出力や外部参照データの検証を挙げています。

（2）  位置づけ

同ガイドラインは、「現時点で取り得るとされる一般的な対策例を整理し、提示する」という位置づけで公表されているものであり（同ガイドライン12頁）、必ず講ずべきものとして上記の対策例を提示している趣旨のものではないことから、同ガイドラインに記載された対策が必ず「開発当時の技術水準に沿ったセキュリティ対策」として評価される（明示的な合意がなくとも契約上対策を講ずべき対策となる）ものではないと考えられます。

しかし、少なくとも現時点での技術水準を推測するための重要な資料ではあると考えられることから、AI開発者やAI提供者としては、損害賠償責任を負うリスクを低減する観点から、少なくとも同ガイドラインの内容についてはキャッチアップし、できれば各対策も講じておく方が望ましいと考えられます。

4. まとめ

今回は、セキュリティ対策等について明示的な合意がなされなかった事例における考え方について紹介しました。

本記事では行政機関等が公表する各種資料につき詳細に触れていませんが、例えば、IPAは、ウェブサイト運営者向けに「安全なウェブサイトの作り方」（第7版）を公表しており、SQLインジェクションをはじめとする代表的な脆弱性とその対策を整理しています。こうした文書は「開発当時の技術水準に沿ったセキュリティ対策」が講じられていたかを検討する際、実務上参照される資料の一つになり得ると考えられます。

なお、本記事はシステム開発時のセキュリティ対策について法的な観点からの判断基準に言及したものとなりますが、システム開発における法的リスクへの対応は、技術的対策のみで完結するものではなく、例えば、責任範囲及び保証内容の限定や損害賠償額の上限といった契約条項によるリスクマネジメントも重要となりますので、これらの点については、また別の機会に取り上げたいと思います。

 

[1] なお、この事案においては、そもそもSQLインジェクション攻撃が情報漏えいの原因となるのかどうか（他の原因で情報漏えいが生じたといえないか）、という点も論点となっており、他の原因として、①サーバーへの不正なリモートログイン、②管理機能への不正ログイン、③クロスサイトスクリプティング等が原告から主張されていました。最終的にはSQLインジェクションによって情報漏えいが生じたものと認定されましたが、当該認定の過程で、複数の調査報告書や調停委員による意見書も参考にされており、損害賠償を請求する側においてインシデント発生時の証拠保全（デジタルフォレンジック）が重要であることがうかがわれます。

[2] 「情報セキュリティ10大脅威 2026」解説書［組織編］につき、本文で詳細な言及はしていませんが、セキュリティを巡る最新動向の全体像を把握する上で有用な資料であり、「コラムAIとサイバーセキュリティ～脅威の現在地と見通し～」をはじめ、具体的事例や示唆に富む内容が盛り込まれており一読の価値があると思いますので、日常業務においてセキュリティと直接の関係を有しない方も是非ご一読いただくことをお勧めします。

※本記事のアイキャッチ画像は生成AIを使用して作成しました