DX対応・民法改正で変わる情報システム取引に関する契約④

株式会社シナプスイノベーション法務室です。

本連載企画では、経済産業省のDXレポートや民法改正を受けて、
同省が2007年に発表した「情報システム・モデル取引・契約書」に、2017年の民法改正を反映したモデル契約の内容
新規に策定されたアジャイル開発版のモデル契約の内容等を解説してきました。

モデル契約第2版について

前者のモデル契約の改訂内容に関しては、2019年12月に経済産業省・IPAが連名で発表したものをベースとしてご説明しておりましたが、その後2020年12月に、民法改正以外の見直しを反映した「情報システム・モデル取引・契約書」第2版（以下、「モデル契約第2版」といいます）が発表されました。
モデル契約第2版の主な改訂ポイントは、以下の5つとなります。

A セキュリティ
B プロジェクトマネジメント義務及び協力義務
C 契約における「重大な過失」の明確化
D システム開発における複数契約の関係
E 再構築対応

このうち、モデル契約の条項改訂があったのがA セキュリティと、B プロジェクトマネジメント義務及び協力義務の2点で、他の3つ（C、D、E）は解説の見直しのみとなっております。

本稿では、モデル契約第2版の改訂点のうち、A セキュリティにつき、モデル契約の改訂のポイントを説明した後、改訂が前提としていると思われる「考え方」につき、若干補足させていただければ、と思います。

セキュリティ条項改訂の背景

2007年発表の「情報システム・モデル取引・契約書」（モデル契約2007年版）では、セキュリティにつき第50条で

• ベンダが納入する本件ソフトウェアのセキュリティ対策について、ユーザ及びベンダは、その具体的な機能、遵守方法、管理体制及び費用負担等を協議の上、別途書面により定めるものとする。
  ※甲、乙という当事者表記をユーザ、ベンダに置き換え。

と、シンプルな定めを置くだけにとどめられておりました。¹

ただ、モデル契約2007年版の発表後、社会の情報化が進展していくに伴い、情報システムの位置づけは、ERPに代表されるバックオフィス業務での情報統合にとどまらなくなってきました。近時発展が著しい電子決済サービスに代表されるように、今や情報システムは、ユーザにおける事業活動の根幹に必然的に組みこまれるようになっています。²

そのような動きが進むにつれ、電子決済サービスに対する不正アクセス等、サイバー攻撃や情報の不正取得による被害も残念ながら増加する傾向にあります。その被害を防止するためには、情報システムの運用段階にとどまらず、そもそも情報システムの企画・構想段階からセキュリティの観点を組みこむ「セキュリティ・バイ・デザイン」という観点が必要、という考え方が、徐々に浸透してきました。

モデル契約第2版では、このようなセキュリティを意識した情報システムの企画・構築といった流れを受け、セキュリティについての定めを契約書の本文でも詳細化するようになっております。

セキュリティ条項改訂の内容とその前提

実際の情報システム開発においては、ユーザとベンダ間でセキュリティ仕様を策定する手順が確立している場合とそうでない場合のいずれも想定されます。
そこで、モデル契約第2版（第50条）では、セキュリティ仕様の策定手順が未確立な場合に、その策定がなされるべき時期等を詳細に定めたA案と、セキュリティ仕様の策定手順が確立している場合において、必要なポイントを簡潔に定めたB案の2つが用意されています。

もっとも、A案、B案のいずれについても、セキュリティにつき以下のような考え方で条文が定められていることは、共通しています。

• 納入される情報セキュリティの仕様については、遅くともソフトウェア開発時点までには、「セキュリティ仕様」としてユーザ・ベンダ双方協議の上で確定させ、書面化する必要がある。³
• 「セキュリティ仕様」はシステム仕様書の一部を構成するものとし、これを変更しようとする場合には、別途基本契約で定める変更管理手続をとる必要がある。⁴
• 「セキュリティ仕様」が確定された場合、ベンダは当該「セキュリティ仕様」に従ってソフトウェアのセキュティ対策を講じる義務を負うにとどまる。「セキュリティ仕様」で想定されず、記載がなされなかったインシデントについてまでは、ベンダは責任を負わない。⁵

このように、モデル契約第2版の条文の文言上は、「セキュリティ仕様」はシステム仕様書（要件定義・外部設計書）の一部として、両当事者の合意のもとに確定されるべきものであることを明確にし、ベンダにセキュリティを踏まえたシステムの構築を当然に義務付ける、という建付けにはしていません。

上記のような建付けでの整理となったのは、「情報システムの運用を運用し、事業活動を行っていくのは、あくまでもユーザ自身である」という考え方が前提にあるものと思われます。

そもそもどのような事業を行うか、その事業活動において生じるリスクにはどのようなものがあり、そのリスクに対しどのような対策（回避／低減／保有／移転）を取るのかは、最終的にはその事業活動を行うユーザ自身の責任において決定されるべき事柄です。また、リスクへの対策にはコストも当然生じます。経営を考えたときに「どこまでのコストで、どこまでの対策を取るか」といった点についても、最終的にはユーザ自身の判断によらざるを得ない、という一面もございます。

もちろん、ベンダがセキュリティにつき一切考慮をしなくてもよい、ということではありません。SQLインジェクション対策を講じなかったことで個人情報が流出した事案で、業務委託契約書や発注仕様にセキュリティ対策が記載されていなかったとしても、既知の代表的なセキュリティ攻撃手法について、行政機関が対策の必要性及び対策の具体的方法を公表している場合にこれに従ったプログラムの提供をしなかったベンダに対し、債務不履行責任を認めた裁判例もあります。⁶

この裁判例のように、行政機関やIPA等の複数の公的機関が広く注意喚起し、広く知られたセキュリティ対策につき、かつその対策に多大な労力や費用がかからないような場合には、そのようなセキュリティ対策を取ることは契約上の当然の義務とされるケースもありうる点、ベンダにおいても留意が必要です。

また、モデル契約第2版の解説においても、「セキュリティ仕様」の確定に当たり

• セキュリティの脅威毎にリスク評価を行い、その対策を実装するか否かをユーザとベンダ双方で決定・合意すること。
• リスク評価でのユーザ／ベンダでの双方協議の土台として、公的機関や業界団体、セキュリティ関連企業等が提供するセキュリティ基準等公表情報を参照することができること。⁷
• 対策を実装しない場合であっても、仕様書にその旨を記録することが重要であること。

が示されています。⁸

このような運用がソフトウェア開発の現場において定着していくのか、法的責任追及の前提となる業界標準となっていくのかどうかについてはなお未確定なところはありますが、ベンダとしては「セキュリティ仕様」としてどこまで決定・合意するのが「あるべき／望ましい姿」なのか、を改めて考えなければならない、と感じております。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

1. なお、モデル契約2007年版においてもセキュリティについての重要性等は解説の各所で言及されており、添付資料として別紙「セキュリティ要求仕様書サンプル」が提示されるなどしておりました。
2. 余談ですが、DXレポートに端を発する近時の「DX」ブームは、従前からのこの動きを、さらに加速させようとするもの、とみることができます。
3. A案第1項。なお、B案第1項では「セキュリティ仕様」確定の時期は明記されていませんが、同第3項で「セキュリティ仕様」がシステム仕様書の一部を構成することとしており、ソフトウェア開発工程に入る前に「セキュリティ仕様」が確定・合意されていることを当然の前提にしているものと考えられます。
4. A案第3項及びB案第3項。
5.  A案第6項及びB案第4項。
6. 東京地判平成26 年1 月23 日判時2221号71 頁。当該事案に関連して、2006（平成18）年に経済産業省からSQLインジェクション攻撃に関する注意喚起文書が発行され、それを受けてIPAからも、2007（平成19）年にSQL インジェクション攻撃に対するバインド機構の使用及びエスケープ処理という対策が示されていました。事案の当時においてもこれが広く知られており、また、対策も過大な工数・費用を要するものではなかった、という点が当該裁判例において事実認定されていた事には留意が必要です。なお、内閣サイバーセキュリティセンター「サイバーセキュリティ法令Q&Aハンドブック Ver1.0」（2020（令和2）年3月2日）のQ41（158頁～160頁）も参照。
7. なお、A案では、セキュリティ基準等をセキュリテ仕様で参照することを基本契約書で明記する場合の条項案、オプション条項として示されています。また、どのようなものがセキュリティ基準等公表情報として活用できるかについては、モデル契約第2版の別紙3「セキュリティ仕様書作成のための参考情報」等を参照いただければ、と存じます。
8. モデル契約第2版解説24頁～25頁参照。