～情報システム・モデル取引・契約書～
第二版の公表にあたって2020 年 12 月 22 日
独立行政法人情報処理推進機構
経済産業省

はじめに
経済産業省は、平成 30 年 9 月 7 日に「DX レポート～IT「2025 年の崖」克服と DX の本格的な展開～」（「DX レポート」）1を公表し、各企業が競争力維持・強化のために新たなデジタ
ル技術を利用してこれまでにないビジネスモデルを展開する、デジタルトランスフォーメーション（DX：Digital Transformation）を推進している。
DX を円滑に進めるには、ユーザ企業、ベンダ企業がそれぞれの役割を変化させていく中で、双方の間で新たな関係を構築していく必要がある。DX レポートにおいては、その構築のためには、契約のあり方について見直しを行う必要があると提言している。
そこで、経済産業省は独立行政法人情報処理推進機構（IPA）に依頼し、経済産業省が公開している「情報システム・モデル取引・契約書」（第一版及び追補版）及び IPA が公開している「非ウォーターフォール型開発用モデル契約書」2について、IPA において、「モデル取引・
契約書見直し検討部会」（「部会」）を設置し、その下にワーキンググループ（WG）を置いて、見直しを検討することとした。
DX に関する多くの取り組みは 2020 年 4 月 1 日から施行される改正民法下で行われることから、部会下に設置した「民法改正対応モデル契約見直し検討 WG」（「WG1」。構成員は別紙の通り。
）において、この課題を検討することとなった。
WG1 では、① 民法改正に直接かかわる論点② 民法改正には関係しないものの、現行のモデル契約の公表以降の情勢変化に応じて見直した方がよいと考えられる論点に大別した上で、それぞれ検討することとした。
上記のうち、①の論点を反映したものについては、第一版及び追補版それぞれの民法改正を踏まえた見直し整理反映版として公表した3ところではあるが、今回②の論点を反映したものを第二版として公表するものである。
本書は、今回の見直しの内容及び趣旨を解説するとともに、必要に応じて当該見直しに至るまでの議論の内容に触れることで、内容の理解に資するものである。
なお、本書では、「情報システム・モデル取引・契約書」を「モデル契約」と呼称し、モデル契約<民法改正を踏まえた、第一版の見直し整理反映版>を「第一版」、モデル契約<民法改正を踏まえた、追補版の見直し整理反映版>を「追補版」と呼称することとする。

1

https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html

2

https://www.ipa.go.jp/archive/digital/iot-en-ci/process/ent02-c.html

3

https://www.ipa.go.jp/digital/model/model20191224.html

2

第１章 議論した論点
WG1 では、第一版及び追補版の民法改正を踏まえた見直し整理反映版を公表した以降、主に第一版を念頭に置いた上で、以下の論点について議論を行った。
１ セキュリティ
２ プロジェクトマネジメント義務及び協力義務
３ 契約における「重大な過失」の明確化
４ システム開発における複数契約の関係
５ 再構築対応
上記の議論を踏まえた見直しを第一版で行った上で、追補版においても妥当する部分については見直しを行った。
第２章 セキュリティ
１

議論の内容
第一版のソフトウェア開発委託基本モデル契約書においては、セキュリティについては、第 50 条において「乙(ベンダ)が納入する本件ソフトウェアのセキュリティ対策について、甲（ユーザ）及び乙は、その具体的な機能、遵守方法、管理体制及び費用負担等を協議の上、別途書面により定めるものとする。
」と簡単な規定を置いているだけであったが、近時のセキュリティの重要性に鑑みると、より踏み込んだ規定が必要なのではないかという議論がなされた。議論の結果、ユーザとベンダとは、それぞれの立場に応じて必要な情報を示しつつ、リスクやコスト等について相互に協議することにより，システムに実装する「セキュリティ仕様」を決めることが必要である、ということで一致をみて、その観点でどのように見直していくかを検討した。
２

条項の見直し（１）定義条項の見直し
まず契約書におけるセキュリティの位置づけを明確にするための修正を行った。すなわ
ち、第 2 条第 2 号の「要件定義書」の定義としてセキュリティ要件が非機能要件の一つであることを明記した上で、同条第 15 号として、サイバーセキュリティ基本法第 2 条におけるサイバーセキュリティの定義4を参照しつつ、この契約で対応しなければならないセキ
ュリティの射程を明らかにするべく、「セキュリティ」自体の定義を置くこととした。

4

サイバーセキュリティ基本法第 2 条では、
「この法律において『サイバーセキュリティ』とは、電子的方式、磁気的方式その他人の知覚によっては認識することができない方式（以下この条において「電磁的方式」という。
）により記録され、又は発信され、伝送され、若しくは受信される情報の漏えい、滅失又は毀損の防止その他の当該情報の安全管理のために必要な措置並びに情報システム及び情報通信ネットワークの安全性及び信頼性の確保のために必要な措置（情報通信ネットワーク又は電磁的方式で作られた記録に係る記録媒体（以下『電磁的記録媒体』という。
）を通じた電子計算機に対する不正な活動による被害の防止の3

（２）セキュリティ条項の見直し（１）の見直しによって契約書にセキュリティを明確に位置付けた上で、第 9 条（責任者）の規定でユーザ及びベンダの責任者が本件ソフトウェアに具備する具体的機能、すな
わちセキュリティ仕様を決定する権限と責任を有することを明記した。また、第 50 条のセキュリティ条項について大幅な見直しを行った。
見直し後の条項では、ユーザ及びベンダが求めるセキュリティ仕様についてクリアすべき基準及び開発プロジェクトを進める上での提案や合意についての手順が確立されているかどうかによって A 案と B 案に分けて規定を置いている。
A 案は、上記基準・手順が確立されていないことを前提とするもので、セキュリティに関するユーザ及びベンダのセキュリティに関するコミュニケーションに関する規律を細かく定め、ベンダがどこまでセキュリティに関する義務を負うのかを明確にしている。また、A 案では、オプション条項として、セキュリティ仕様策定のために双方が特定のガイ
ドライン（例としては後述するようなセキュリティ検討 PT が策定したガイドライン等が考えられる。
）を念頭に置いて仕様を作成する場合に当該ガイドラインの内容を盛り込む手続及び当該ガイドラインに示されたセキュリティ対策の一部を講じない判断をした場合の手続について規定をしている。
一方、B 案では、ユーザ及びベンダが求めるセキュリティ仕様についてクリアすべき基準及び開発プロジェクトを進める上での提案や合意についての手順が確立していることを前提に、A 案で細かく定めた規律については、両者の合意により別途契約書本体以外のドキュメント（当該記載内容も契約の一部を構成することは前提である）に盛り込まれることを前提に、簡素な規定とした。
なお、A 案・B 案のいずれも、確定したセキュリティ仕様がシステム仕様書（第 2 条第4 号）の一部を構成し、第 37 条の変更管理手続によってのみ変更ができること、そして、ベンダとしては当該仕様に基づいてセキュリティ対策を行う義務を負うにとどまるのであって、セキュリティインシデント（こちらについてもセキュリティの定義について規定した第 2 条第 15 号において定義している。
）が生じないことを保証するものではないことを明記し、責任分界点を明確にしている。
３

セキュリティに関するプロセスに関する解説の加筆ために必要な措置を含む。
）が講じられ、その状態が適切に維持管理されていることをいう。」と定義されている。ただし、この定義はサイバーセキュリティの確保に関わる基本理念や国等の責務を明らかにするという意味での基本法としてのものであり、その後半部分は、ソフトウェア開発委託基本契約を締結する目的である本件ソフトウェアの外側で調達が行われる情報システム全体（ハードウェアを主な構成要素とする）及
び情報通信ネットワーク、並びに運用保守のフェーズにも言及していることから、本件ソフトウェアの開発に関するモデル契約の範囲外と考えられるため、第 2 条第 15 号には反映させていない。

4

上記１の通り、契約書本体でセキュリティに関する条項を充実させたが、セキュリティ
に関するトラブルの予防のためには、契約の外におけるユーザとベンダのコミュニケーシ
ョン等のプロセスも重要であることから、今回の見直しでは各フェーズにおいてユーザとベンダが履践することが望ましいプロセスについての解説についても加筆を行った。
４

セキュリティ検討 PT による「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」及び「セキュリティ仕様策定プロセス」の策定
今回の見直しに際して、WG1 での検討と並行して、WG1 の下部に設置されたセキュリ

ティの専門家から構成されるセキュリティ検討プロジェクトチーム（以下「セキュリティ
検討 PT」）において、Windows Active Directory 環境を対象に、セキュリティ仕様を作成する際の脅威分析とその対策を検討するための OS、デスクトップアプリ、ブラウザーのセキュリティ設定を検討するためのガイドライン及び当該ガイドラインを前提としたセキ
ュリティ仕様策定プロセスの検討が進められ、それぞれ「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」（以下「セキュリティ GL」）及び「セキュリティ
仕様策定プロセス～「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」対応～」（以下「セキュリティプロセス」）として策定された。
第３章 プロジェクトマネジメント義務及び協力義務
１

議論の内容
第一版及び追補版の公表以後、システム開発に関する裁判例は集積しており、その中でもベンダのプロジェクトマネジメント義務及びユーザの協力義務がよく問題になっている
ところ、これらの義務について契約書上に手当をすることによって紛争の予防に資することはできないかという点について議論を行った。
議論においては、裁判例で問題とされているプロジェクトマネジメント義務及び協力義務については、それぞれの個別事案におけるベンダとユーザの役割を踏まえた上で判示されているのであって、汎用性の高いモデル契約の中に裁判例で示されていた文言を最大公
約数的な形で入れるのは難しいのではないかという意見や、また、改めて第一版のモデル
契約及びドキュメントを見てみると、第 8 条の役割分担や第 12 条の連絡協議会など、各条項で定められたプロセスを適切に運用すればプロジェクトマネジメント義務違反や協力義務違反が問題となるような事案は一定程度防げるのではないかという意見があった。また裁判例では、その用語法からあたかもベンダだけがプロジェクトマネジメントを行わなければならないかのような印象を受けるが、ユーザも（システム開発プロセス一般で意味するところの）プロジェクトマネジメントを行う必要があり、ユーザの義務をしばしば「協力義務」と表現する裁判例を説明するだけではユーザがシステム開発において従たる役割しか負わないという誤ったメッセージが伝わってしまうのではないかという意見も出された。

5

また、東京高判平成 25 年 9 月 26 日金融・商事判例 1428 号 16 頁（以下「平成 25 年
東京高判」という。
）では、ベンダのプロジェクトマネジメント義務の一環として一定の場合における中止提言義務が判示されているところ、現在のモデル契約では第 38 条において変更協議を経てもユーザ側からしか一方的に解除できないため、中止提言をしたとしてもユーザが応じなければベンダはうまくいかないとわかっていながら業務を進めなければいけないという酷な状況となるので、このような場合にはベンダ側からも解約権を認めた方がよいのではないかという意見が出た。
２

見直しの内容（１）裁判例の追加
上記議論を踏まえ、今回の見直しではプロジェクトマネジメント義務や協力義務を条項の形で追記することは見送ることとし、その代わりに裁判例で問題となったケース等について、それぞれ関連する条項・箇所において紹介をすることで注意喚起を行うこととした。
（２）役割分担・プロジェクトマネジメントに関する記述の見直し
第一版においてはモデル契約プロセスにおいて「プロジェクトマネジメントの重要性」という項が独立して設けられているところ、そこでの「プロジェクトマネジメント」の用語はシステム開発プロセス一般における意味で使われており、裁判例における「プロジェクトマネジメント義務」とは意味合いが異なる。ユーザ及びベンダは、システム開発プロ
セス一般における意味では双方ともにプロジェクトマネジメントをしなければならず、適切なプロジェクトマネジメントを進めるためには、双方が各フェーズにおいて自らが果たすべき役割を踏まえることが重要である。今回の見直しでは、「プロジェクトマネジメン
トの重要性」の項及び「ユーザとベンダの協力の重要性、役割分担」の項の記述を全面的に修正し、上記のメッセージがユーザ及びベンダにバランスよく伝わるようにした。
（３）マルチベンダ形式における用語法の修正
第一版においては、「プロジェクトマネジメント」という用語が第 13 条のマルチベンダ
形式の際の調整業務を意味する文言でも使われていることから、今回の見直しにおいては、混同を防ぐために正面から「マルチベンダの調整」と言い換えることとした。
（４）ベンダの中止提言を踏まえた解約権の条項
ベンダが中止提言義務を負うようなケースの場合の解約権については、当初事務局より、第 38 条第 3 項として、第 37 条の協議の結果、個別契約の続行をしても当該個別契約の目的を達成できないと客観的に認められる場合には、ベンダがユーザに中止を提言するものとし、それでもユーザが合理的な理由なく応じない場合にはベンダが個別契約の解約ができるものという条項が提案されたが、この条項の追加についてはユーザ側から異論が唱えられた。ユーザ側からは、

6

①システム開発におけるベンダの説明義務は一般的に認められているし、求められるところではあるが、ユーザとしては、平成 25 年東京高判で言及されているような中止の提言までは常に求めているわけではないので、そのような中止提言義務を前提にする条項を置くべきではない②裁判例で繰り返し言及されているプロジェクトマネジメント義務や協力義務について規定することは見送ったことのバランスからも、プロジェクトマネジメント義務の一環としての中止提言義務だけを取り出して規定することはバランスを欠く③プロジェクトを継続するか否かについて最終的に決定する権限は、プロジェクトのオーナーたるユーザにあって、ベンダは説明義務を果たした上でユーザと誠実に協議することが求められており、プロジェクトを続行することは最終的にはユーザの責任で判断できるようにしておくべきである④上記条項案では、個別契約の目的を達成できなくなったことがベンダの責めに帰すべ
き事由がある場合においても解約ができるように読めるが、民法では、履行不能となった場合に、債権者の責めに帰すべき事由である場合には解除できないので、民法で規定された権利以上の権利をベンダに認めることになり相当でない⑤第一版では第 37 条第 4 項によって、作業を中断しても債務不履行に陥らないための手当がなされていることから、ベンダからの解約権を認める必要はない⑥個別契約の目的を達成できるかは究極的にはユーザの主観を考慮せざるを得ず、ベンダが客観的な観点から判断することは実務的には困難ではないか⑦「合理的な理由なくユーザが応じない」という箇所の「合理的な理由」が具体的に何を指すのかが明確ではなく、ベンダによる当該条項の濫用のおそれがあるのではない
か、また、ベンダの帰責性を「合理的な理由」の中で斟酌するといっても、実際にはユーザ・ベンダいずれかにまったく帰責性がないケースは稀であり、結局、いかなる場合に「合理的な理由」が認められるか不明であるなどの意見が出された。
これに対しては、他の委員から①中止提言義務に言及している裁判例は今のところ平成 25 年東京高判１つであり、中止提言義務がどこまで認められるのかは今後の裁判例の動向を注視する必要がある
し、いずれにしても、中止提言を一般的義務とするのはベンダにとっても過度な負担となる。一方で、変更協議が不調となったときに、ユーザ・ベンダそれぞれの従業者
が不毛なデスマーチに巻き込まれないように、ユーザの迅速かつ適切な意思決定を促進するために、ユーザ・ベンダ間のコミュニケーションを促進する必要があり、そのためにベンダからの中止提言を起点とした一定の解約権を設けることはユーザ・ベン
ダ双方にとって有益ではないか

7

②ベンダとしても、プロジェクトを継続することが困難となったことについてベンダに帰責事由がある場合に、必ずこの条項に基づく解約が許されるべきとは考えていない
し、その点はユーザが中止に応じない「合理的な理由」の中で斟酌されるべきである③第 37 条第 4 項は「中断」について定めたものであり、プロジェクトそのものを解散する状況ではなく、再開も予定されていると考えるべき状況であるから、ベンダとしてはプロジェクトが何も進んでいない状態で当該プロジェクトのための人と設備を維持しなければならず、コストがかかり続ける。もちろん、その後最終的に解除になった時点でユーザ・ベンダ双方が当該コストの負担について協議することになるが、早い段階でプロジェクトの継続が相当に困難であることは見えているのであれば、その段階でベンダからしかるべき説明をして一定の場合に解約できる方が結局ユーザとベンダ双方にとって合理的なではないか④「個別契約の目的を達成することができない」場合がどういう場合を指すのかはイメージしにくいし、目的が達成できるかどうかを判断できるのが究極的にはユーザであるということであれば、特に目的達成の可否という基準に拘泥する必要もなく「個別契約を続行することが困難となる事情が客観的に認められる場合」というように修正すれば足りるのではないか⑤「合理的な理由」というような幅のある表現を使うのは、一般的な話であるし、シス
テム開発においてはそれぞれの案件が個別具体性を持っているのであるから、モデル
契約書においてこのような内容を入れることは適切である。この局面での解約権は、一定の客観的な状況のもとで、ベンダが中止すべきであるという提言をしっかり行う
ことが前提で、それでもなおユーザが合理的な理由なく応じない場合に限って認められるのであるから、相当要件が限定されている⑥ベンダとしても、プロジェクトを続けて最後までシステムを作りたいと考えており、
途中でやめるモチベーションは基本的にはなく、解約権を濫用しようとは思わないといった意見が出された。議論の結果、一定の修正をした上で当該条項を第 38 条第 3 項という形で常置する条項として新設すべきだという意見が多数ではあったものの、WG1 としてコンセンサスを得るまでには至らず、ベンダからの解約権を定めない A 案と、ベンダからの解約権を定める B 案を併記することとした。
B 案では、第 37 条の協議の結果、作業期間又は納期、委託料及びその他の契約の条件に重大な影響を及ぼす等の理由により、個別契約を続行することが困難となる事情が客観的に認められる場合は、ベンダが当該事情及びその理由を明示したうえで書面により中止を提言することができるものとし、その提言にもかかわらず、ユーザが合理的な期間内に合理的な理由を提示することなくこれに応じない場合、ベンダは、個別業務の未了部分について個別契約を解約することができることとした。この場合、ベンダは解約時点までに遂行した個別業務についての委託料を請求することができるとしているが、最終的なコス

8

ト分担は「個別契約を続行することが困難となる事情」に至らしめた双方の帰責性を勘案した損害賠償によってなされるものとしている。
B 案の逐条解説では、ユーザから示された懸念点を踏まえ、どのような場合に「合理的な理由」があると言えるのかについての具体例を提示するとともに、帰責事由の所在によってどのような処理になるのかを場合分けをすることで示している。
第４章 契約における重過失の明確化
１

議論の内容
第一版においては「重大な過失」（「重過失」）の有無が損害賠償の責任制限条項の適用の分水嶺となっており、また、民法改正に対応した見直しによって、ソフトウェア開発業
務等の請負型の業務における契約不適合責任においても、重過失の有無が客観的起算点による期間制限の適用の分水嶺となっていることから、この重過失について、双方当事者の予測可能性の担保の観点からより明確化することはできないかという点について議論を行った。
議論においては、そもそもシステム開発の局面において重過失が認められた例がほとん
どないことから（ベンダが SQL インジェクション対策を講じなかったことが重過失とされた東京地判平成 26 年 1 月 23 日判例時報 2221 号 71 頁くらいであると思われる）、条文の形で落とし込むのは難しいのではないかという意見が出された。
２

見直しの内容そこで、今回の見直しでは、契約条項として重過失について特段の定義をすることはせず、重過失概念に関する一般的な理解とシステム開発に関する裁判例のうち重過失についての判示を第 53 条の逐条解説に追記することで、重過失を考える上での手がかりを提供することとした。
第５章 システム開発における複数の個別契約の関係
１

議論の内容
システム開発においては、特定の個別契約に債務不履行がある場合に、一連の流れの中にある別の個別契約を解除したり、その個別契約に基づいて支払った委託料を損害として請求できるかが問題となることがある。このような紛争の予防・解決のためにモデル契約
上何らかの手当ができないか議論を行った。
この論点については、最判平成 8 年 11 月 12 日民集 50 巻 10 号 2673 頁が「同一当事者間の債権債務関係がその形式は甲契約及び乙契約といった二個以上の契約から成る場合であっても、それらの目的とするところが相互に密接に関連付けられていて、社会通念
上、甲契約又は乙契約のいずれかが履行されるだけでは契約を締結した目的が全体としては達成されないと認められる場合には、甲契約上の債務の不履行を理由に、その債権者が9

法定解除権の行使として甲契約と併せて乙契約をも解除することができるものと解するのが相当である。
」と判示して、システム開発における紛争にどれほど射程が及ぶのか、システム開発関係で複数契約の関係が問題となった裁判例をもとに議論が行われた。
議論では、従前システム開発の関係で紛争となっている裁判例は、①同時並行的な履行によって達成されることが予定されていた複数の契約間で問題となるケース（「並列型」）と、②本モデル契約のような多段階契約における前工程の契約と後工程の契約との間で問題となるケース（「直列型」）に大きく分けられており、上記最判は①を念頭においたものであり（このケースではリゾートマンションの会員権契約とリゾートマンションの売買契約との関係が問題となっている）①のケースには射程が及ぶ一方、②のケースには当然にはその射程は及ばないのではないかという共通認識を得た（特に、②のケースについて
は、東京地判平成 31 年 3 月 20 日公刊物未掲載（平成 25 年（ワ）第 31378 号・平成 26
年（ワ）第 9591 号）において、明確に上記最判との関係について検討が加えられており、当該事案について各個別契約の共通の契約目的は各契約の締結と履行の終了の積み重ねを通じて、順次段階的に達成されていくことが予定されているものであって、数個の契約の同時並行的な履行によって達成されることが予定されていた上記最判の事案とは異なる旨判示している）。
また、②のケースにおいて、下流工程におけるトラブルで上流工程における個別契約を解除したり、当該個別契約に基づく委託料を損害として請求したものが認められているケースというのは、結局上流工程自体について債務不履行があると判断しているという、それが下流工程まで進んだあとに露見するということであって、下流工程の債務不履行で上流工程の契約に影響を及ぼしているといったものではないのではないか、という点についても共通理解を得た。
その上で、複数の個別契約の処理がどうなるかは、結局当該個別契約の関係や問題となった債務不履行次第であることから、何か契約条項として手当をするのではなく、上記のような整理を解説で追記するのがよいのではないかということで一致した。
２

見直しの内容上記の議論をもとに、今回の見直しでは第 52 条（解除）の逐条解説に、上記の整理に関する解説を追記して、利用者の理解に資することとした。
第６章 再構築を念頭においた解説の追加
DX レポートにおいて、既存の IT システムには、事業部門ごとに構築されているために、全社横断的なデータ活用ができない、過剰なカスタマイズがなされているなどにより、複雑化・ブラックボックス化しているという問題があり、これを解決できない場合、DX が実現できないのみでなく、2025 年以降、最大 12 兆円／年（現在の約３倍）の経済損失が生じる可能性が指摘された（2025 年の崖）
。そして、2025 年までの間に、既存シス

10

テムについて、廃棄や塩漬けにするもの等を仕分けしながら、必要なものについて刷新しつつ、DX を実現するというシナリオが示された。
長年運用・保守を続けてきた IT システムを刷新（再構築）する場合、関係者の退職や異動により、対象システムが実現する業務内容やシステムの仕様について理解する人材がいない、対象システムに関するドキュメントが散逸していることや、改良内容のドキュメ
ントへの反映がされず動作しているシステムと設計書やソースコードとが整合していないことがある、といった問題があることが少なくない。そのため、既存機能（の一部または全部）を移行する場合（一般に「現行踏襲」と言われる）において、要件定義に入る前に、再構築対象の現行システムについての調査を行い、その仕様を明らかにした上で再構築を行う必要がある。この現行システム調査を十分に行わずにシステム再構築に着手し、後のシステム開発段階でトラブルに陥った事例が多数報告されている。
ところが、企画プロセスにおける現行システム調査には、専門的な技術も必要であり、コストと時間を要する。すなわち、システム再構築では、企画支援サービス業務の内容が重要であり、作業量も大きい。必要に応じ、ベンダとの間で、現行システム調査・分析と再構築方法の検討、想定されるリスク対策等の支援業務を内容とする準委任契約としてのコンサルティング契約を締結し、これらの作業のための支援を受けることになる。しかし、現在動作している通りのシステムを再構築するだけ（現行踏襲）、と考えるユーザにはこの意識が薄い。IT システム部門向けには再構築に関するガイドブック類が公表されているものの、業務マネジメント層や契約に関わる部署に向けたものは少なく、モデル取引・契約書の中で注意喚起することが重要とされた。
なお、第一版では、モデル契約書・逐条解説は要件定義フェーズ以降を対象としている。企画支援サービス業務のモデル契約書・逐条解説はなく、その内容はごく一般的・抽象的なものになるとと想定されることから、システム再構築に関しては、個別契約書等の作成時の参考となること等を想定し、モデル契約プロセスの中で解説することとした。
第７章 追補版への反映
第一版と追補版で大きく異なるのは、その前提であり、第一版では情報の非対称性がありつつも企業同士の交渉力としては対等なユーザ・ベンダ間の契約であり、重要インフ
ラ・企業基幹システムの受託開発を念頭に置いていたのに対し、追補版では IT の専門知識を有しないユーザを業として情報サービスを提供するベンダ間の契約であって、必ずしも
基幹システムのような大きいシステムの開発を想定していない。
第一版で議論したもののうち、重過失及び複数契約間の関係の論点に関しては、ある意
味で純粋な法的論点であり、上記の前提の差異に影響しないことから、これらについては第一版と同様の追記を行った。また、プロジェクトマネジメント義務・協力義務に関しては、追補版が想定するユーザに第一版が想定するユーザほどのプロジェクトマネジメントを要求することはできないものの、追補版のモデル契約書でも規定がされている役割分担を適11切に行うことや連絡協議会において進捗管理報告等を適切に行っていることが、紛争の予防に資するということ自体は第一版と変わりないことからその限りで解説に追記を行っている。
なお、セキュリティに関しては、追補版が想定するシステム開発取引においても重要であることは疑いないものの、セキュリティについてどう考えるかは、上記の前提の違いが大きく影響するところ、今回の見直しにおける議論においては対等なユーザ・ベンダという第一版を前提における議論に時間を要し、前記セキュリティ GL の中に、追補版が想定するシステム開発取引において参考となる、最低限検討するべきデフォルト緩和策について記載
したものの、追補版におけるセキュリティについての議論を十分に行えなかったため、追補版そのものの大きな見直しは見送った。2019 年 12 月に公表した「～情報システム・モデル
取引・契約書～第一版及び追補版 DX 推進のための見直しにおける民法改正を踏まえた整理にあたって」においても言及したように、追補版については、主に中小企業が利用するという観点からより分かりやすくするための見直しが必要であるという意見も出ていることから、セキュリティ関連のみならず、中小企業向けとして適切なモデル取引・契約書の在り方を含め，現状の取引状況等に関する関係者の意見を踏まえた検討が期待される。
第８章 第一版・追補版策定時の課題について
１

ドキュメントからの削除
第一版及び追補版にはそれぞれ策定時に検討された検討課題が記載されている。これらについては、下記に示す通り対応が進んでいるものも多い。一方で、これらの課題の中には引き続き検討する必要がある事項もあるものの、今回公表する第二版において引き続きそれぞれ 10 年以上前に策定された当時の内容の記載を継続することは適切ではないように思われる。
そこで、今回の第二版のドキュメントからは検討課題等を削除することとしたが、今後の検討に資するため、それぞれの課題の現況及び今後の対応について本章において示す。なお、下記で「課題」と記載しているものは、第一版及び追補版に記載している内容をそのまま引用している。
２

第一版の検討課題の状況及び今後の対応（１）システムライフサイクルプロセスの体系化【課題】
経済産業省及び IPA（独立行政法人 情報処理推進機構）は、ユーザ・ベンダ間のシス
テムライフサイクルプロセスの共有化に向けて、研究会の成果を踏まえつつ、保守・運用プロセスの可視化を含めた共通フレームの体系化を行うことが望まれる。
【状況】
現在は「共通フレーム 2013」として体系化されており、完了している。

12

（２）モデル取引・契約書の定期的な見直し・多様な契約のあり方についての検討【課題】
経済産業省は、研究会で策定されたモデル契約プロセス、モデル契約書、モデルドキ
ュメントの定期的な見直しを行う。また、保守・運用プロセスの体系化を踏まえた保守・運用サービスのモデル取引・契約書、パッケージ活用型開発の契約のあり方、中小企業
ユーザとの契約のあり方、ソフトウェアモジュールの再利用を促進する契約のあり方及びパフォーマンスベース契約等の多様な契約のあり方についても検討を行う。
【状況】
今回、民法改正を契機に、第一版公表以降の裁判例等に関する論点を含め、見直しを実施した。また、アジャイル開発版を作成・公表した。なお、第一版公表後に検討を行い、追補版を公表している。
【今後の対応】
時代の流れに応じて、引き続き、必要となった時点で見直しを行うこととする。
（３）多様な開発モデルにおける契約のあり方についての検討【課題】
経済産業省は、ウォーターフォールモデル以外の開発モデルが活用されている実態を踏まえて、反復繰り返し型等の開発モデルに基づいた契約のあり方について、信頼性の向上・取引の可視化の観点から検討を行う。
【状況】
2020 年 3 月にアジャイル開発版のモデル取引・契約書を作成・公表し、完了している。
（４）ADR（裁判外紛争処理）の活用【課題】
ユーザ・ベンダの責任分担とその履行等について、専門的・技術的視点による詳細な事実認定、並びに当事者間の話し合い及び調整といった機能・プロセスが必要となる場
合、紛争処理を迅速かつ柔軟に行うことが可能である ADR の活用・促進が望まれる。な
お、モデル契約書においては、紛争処理方法について、仲裁によることを原則としている。
【状況】
裁判外紛争解決手続の利用の促進に関する法律（いわゆる ADR 法）が 2007 年 4 月 1日に施行された後、システム開発の分野においては、一般財団法人ソフトウェア情報センター(SOFTIC)におけるソフトウェア紛争解決センター設置5 など、ADR 活用の取組みが行われている。なお、効率的・効果的な紛争解決が行われるよう、経済産業省は、2007
年 3 月に模擬 ADR に関する動画6を作成・公開している7。
5

http://www.softic.or.jp/adr/index.htm

6

http://www.meti.go.jp/policy/it_policy/softseibi/index.html#05

7

http://www.softic.or.jp/seminar/2007-ADR/index.html#top13

【今後の対応】
モデル取引・契約書の検討とは別の施策ではあるが、利用・促進に向けた施策を検討する。
（５）政府調達におけるモデル契約の活用【課題】
経済産業省は、研究会の成果を踏まえて、積極的に調達に活用することに加え、政府調達における活用方策を検討する。
【状況】
フェーズの分割を前提とした工程管理、当事者の合意形成を図るためのコミュニケー
ション管理、協働関係にある当事者間の作業範囲、役割、スケジュール、作業の進め方
等の計画及び変更管理手続の明確化など、基本的な考え方が政府調達に反映されている（「デジタル・ガバメント推進標準ガイドライン」(平成 30 年 3 月 30 日各府省情報化統括責任者(CIO）連絡会議決定）及びその解説書)。モデル契約書そのものについては、総務省「情報システムに係る政府調達の基本指針実務手引書」（2007 年）に盛り込まれた契約条項に多くの部分が取り入れられたが、現時点では政府調達に活用されていない。
【今後の対応】
経済産業省内で引き続き検討する。
（６）信頼性評価指標への活用【課題】
経済産業省及び IPA は、現在策定中の情報システムの信頼性評価指標において、モデル契約書に定める主要事項の準拠に対する取組レベルを診断し、可視化することが望まれる。
【状況】
IPA は、「スタンドアロン型信頼性自己診断ツール8」を開発・公開し、完了した。なお、
現在このツールは現在、国会図書館のアーカイブスに移されている。
（７）保険制度の創設の検討【課題】
モデル契約の活用・普及によるユーザ・ベンダの情報システムに関するリスク認識の向上、顕在化するリスクへの対応のために、モデル契約書及び前述の信頼性評価指標等を被保険者の個別審査に活用した保険商品が設計されることが望まれる。
【状況】
IT 保険一般に関してはある程度普及しているが、モデル契約書及び前述の信頼性評価指標等を被保険者の個別審査に活用したものは見当たらない。
【今後の対応】

8

https://www.ipa.go.jp/archive/digital/iot-en-ci/kousinrai/dependability.html

14保険関係者にも状況をさらに確認の上、必要に応じて保険会社に働きかけを行う。
（８）業界団体等における普及・啓発【課題】
ユーザ・ベンダを代表する各業界団体においては、「信頼性ガイドライン」において定められた対策及び留意事項の実施、研究会での議論を最大限尊重した取引慣行の確立に向けて、啓発活動を行うことが望まれる。
また、パッケージを中心としたシステム導入の場合や反復繰り返し型の開発の場合、中小企業ユーザにおける活用の場合等、本モデル取引・契約書で十分カバーできていな
い論点について、業界団体を中心としてさらに議論が深められることが望まれる。
【状況】
一般社団法人コンピュータソフトウェア協会（CSAJ）、一般社団法人電子情報技術産業協会（JEITA） 、一般社団法人情報サービス産業協会（JISA） などの業界団体において、啓発活動が行われている。また、パッケージを中心としたシステム導入等に関して
は、追補版において検討されている。なお、今回の見直しにおいては、関連業界団体に声掛けして部会/WG 委員を推薦・派遣していただいており、第二版公表後に、それらの業界団体による普及・啓発が期待できる。
【今後の対応】
経済産業省・IPA から関係団体に対して、モデル契約書について改めて周知を図る。
３

追補版検討課題の状況及び今後の対応（１）E-Learning 等を活用した普及【課題】
経済産業省及び関係業界団体は、E-Learning のトレーニングプログラムの整備、セミナーの開催等を通じてモデル取引・契約書追補版に基づく取引慣行の普及に努める。
【状況】
モデル取引・契約書追補版に基づく取引慣行の普及については、経済産業省より、モデル取引・契約書活用ツールが公表されている。また CSAJ 等の関係業界団体において、普及活動が行われている。
【今後の対応】
経済産業省・IPA が DX 等についての講演を行う場合等に、モデル契約の説明を極力入れるようにする。
（２）IT 取引の適正性を担保するための資格制度の検討【課題】
IT の専門知識を有しないユーザと業として情報サービスを提供するベンダの間では、モデル取引・契約書追補版に基づき契約事項・取引内容について真に合意に至ることが重要である。他方で、モデル取引・契約書追補版を形式的にしか利用せず、IT の専門知

15

識を有さないユーザが実質的に合意していないにも関わらず、合意しているとの外観を整え、ベンダ側の免責の材料として使われる恐れもある。そうした慣行を防止する観点
から、経済産業省及び関係業界団体はユーザの視点からのモデル取引・契約書追補版の活用のガイドの整備や、十分な IT と法務の知識を有し第三者としてモデル取引・契約書
追補版に基づき取引を適正に行われることを担保する専門家を認定する資格制度の創設を含めた総合的な環境整備・制度設計の検討を進める。
【状況】
現時点で検討は行われていない。
【今後の対応】
取引・契約の実情を踏まえ、必要に応じて、既存の民間資格の中でモデル契約について活用や普及を働きかける。
（３）ユーザ・ベンダ間の役割・責任分担の明確化【課題】
情報システムの信頼性の向上のためには、契約等によるユーザ・ベンダ間の役割・責任分担の明確化が重要である。他方で、IT を巡る紛争については、裁判例及び判例が十分に蓄積されておらず、契約上の文言の個別事例への適用についての予見可能性が小さいとの指摘がある。このような状況を改善するために、経済産業省及び業界団体は指針や準則の策定等も含めた取組について検討する。
【状況】
ユーザ・ベンダ間の役割・責任分担に関しては、その重要性も含め、今回の見直しによってより明確に説明されることになった。また、官民の公表する関連文書類 においても適宜説明されている。なお、情報システム・ソフトウェア取引に関わる方々に、適切な契約を結ぶことの重要性を再確認していただくとともに、曖昧な契約等によってユー
ザ・ベンダが被る損害の大きさを認識していただくため、経済産業省委託事業にて、「情報システム・ソフトウェア取引高度化コンソーシアム委員会」を組織し、実際に発生したトラブル事例を参考とした「情報システム・ソフトウェア取引トラブル事例集」 を策定し、2010 年 3 月に公表している。したがって、課題対応は完了している。なお、当該トラブル事例集の公表後に生じた新たなトラブルに関する裁判例についての研究が一般
財団法人ソフトウェア情報センターにおいて実施されている。
（４）再委託先を含めた品質保証体制の確立【課題】
我が国のソフトウェア産業の生産性については、欧米と比較して高くないといわれており、その原因として「労働集約的な受注ソフトウェア比率が高いこと」「中小企業等が中心で重層的な下請け構造」との指摘がある。モデル取引・契約書追補版においては、
パッケージソフトウェアでの開発であることから、再委託先についてはベンダの裁量を認めることで、柔軟なプロジェクトの推進を確保した。他方、ユーザは、開発形式を問

16

わずプロジェクトに参画する情報サービス企業の品質保証、個人情報保護、情報セキュ
リティ等の管理体制について、重大な関心があるところであるが、再委託に関する開示
情報は一律でなく、品質保証基準も定めがない。今後、業界団体を中心とした元請けと再委託先の品質保証体制の確立及び情報開示について議論が望まれる。
【状況】
モデル取引・契約書第二版では、第一版を踏襲し、再委託について、原則禁止と原則自由の両案併記となっているが、追補版では、原則自由のみとしている。ただし、ユー
ザが要求するときには再委託先を開示し、ユーザは合理的な理由があるときには再委託を中止できることとしている。官民の契約の実態としては、さらに踏み込んで、再（々）委託に際して、ユーザから元請けに課されたものと同等の義務を課すことを条件とし、ユーザからの要求に応じて、再（々）委託先における品質保証や秘密/個人情報保護、情報セキュリティ等に関する管理状況の情報開示や視察受入れを義務付けているものもある。しかしながら、より詳細な開示情報項目リストや品質保証基準にまで言及した例は見当たらず、そこまでのレベルで、業界団体を中心とした元請けと再委託先の品質保証体制の確立及び情報開示について議論が行われてはいないものと思われる。また、FOSS(Free and Open Source Software)の利用が拡大している一方で、サプライチェーンでのFOSS の脆弱性管理や配布/サポート終了（EOL; End of Life）への対応などが不明確との指摘もあり、ソフトウェアコンポーネントの管理やソフトウェアコンポーネントの透明性の在り方について日米9で検討が行われている。
【今後の対応】
関係者の話を伺いつつ、業界団体を中心とした元請けと再委託先の FOSS の管理を含めた品質保証体制の確立及び情報開示についての議論を促すこととする。
（５）システム性能の適正性及びシステムライフサイクルを担保するための情報開示【課題】
システムの応答や処理速度などのシステム性能を確保するためには、ハードウェアの適正な選択が重要である。一方、OS、ミドルウェア、パッケージソフトウェア、デスクトッ
プアプリケーションがそれぞれ、CPU 速度、必要メモリ、ディスク容量などの動作環境を提示しているところであるが、これらは、ベンダの独自裁定によるものであって、一定基準に沿った応答性能を保証するものなのか、最低限の動作を保証するものなのかは明らかでない。さらに近年、OS、ミドルウェアの様々なバージョンが混在する状況であり、アプ
リケーションソフトウェアの動作に適切なハードウェアを選択する方法論は確立されてい
ない。
9

経済産業省

https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_seido/wg_bunyaodan/software/pdf/
001_04_00.pdf
米国商務省 https://www.ntia.doc.gov/SoftwareTransparency

17

他方、システム構築からシステムの廃棄に至る期間は、ユーザの企画するビジネスモデ
ルなどに深く影響する。激しい市場競争によって、高機能化、多機能化を重ねる情報シス
テム製品、OS、ソフトウェアは、短期間で世代が交代する場合もあり、その結果、補修用部品の提供やサポート期間が、ユーザが想定する償却期間よりも短い期間で打ち切られ、システムの維持が困難となるケースが見受けられる。
今後、メーカーや業界団体等において、ソフトウェアの適正な動作基準の策定とそれに基づくハードウェア要件の開示、また、サポート期間等を考慮したうえで適切にシステムの企画・構築ができるよう、サポート・保守に関する情報の開示等の検討が望まれる。
【状況】
ニーズが高まっているクラウドの SLA (Service Level Agreement)に関しては、官民からガイドライン等 が公表されている。
【今後の対応】
関係者の話を伺いつつ、メーカーや業界団体等における情報開示等に関する検討を促す
こととする。

以上

18

モデル取引・契約書見直し検討部会委員名簿
主

査

平野高志

ブレークモア法律事務所

弁護士

委

員

大谷和子

株式会社日本総合研究所

執行役員法務部長

〃

高岡詠子

上智大学

〃

坂東直樹

アップデートテクノロジー株式会社

〃

松原真弓

富士通株式会社〃

三宅 晃

一般社団法人日本情報システム・ユーザー協会

〃

森田宏樹

国立大学法人東京大学

〃

吉田正夫

スクワイヤ外国法共同事業法律事務所

理工学部情報理工学科

政策渉外室

教授
代表取締役社長

エキスパート

大学院法学政治学研究科

理事・事務局長
教授

弁護士

オブザーバー
経済産業省、一般社団法人コンピュータソフトウェア協会、一般社団法人電子情報技術産業協会、一般社団法人情報サービス産業協会

民法改正対応モデル契約見直し検討WG名簿
主

査

森田宏樹

国立大学法人東京大学

委

員

伊藤雅浩

シティライツ法律事務所

弁護士

〃

大谷和子

株式会社日本総合研究所

執行役員法務部長〃

荻野朋美

東京海上日動火災保険株式会社

〃

加藤智巳

株式会社ラック

サイバー・グリッド・ジャパン 主席研究員

〃

木内里美

株式会社オラン

代表

〃

高柳祐治

株式会社日立製作所
法務部

大学院法学政治学研究科

教授

IT企画部企画グループ 担当課長

システム＆サービスビジネス統轄本部

担当部長

〃

野々垣典男

プロメトリスト

代表

〃

坂東直樹

アップデートテクノロジー株式会社

〃

藤田美雄

株式会社大塚商会〃

松島淳也

松島総合法律事務所

専門委員

村田和希

東京丸の内法律事務所

社長室経営企画課

代表取締役社長
副参事

弁護士
弁護士

オブザーバー
経済産業省、一般社団法人コンピュータソフトウェア協会、一般社団法人電子情報技術産業協会、一般社団法人情報サービス産業協会、一般社団法人日本情報システム・ユーザー協会

19セキュリティ検討 PT 名簿
主

査

加藤智巳

株式会社ラック

サイバー・グリッド・ジャパン

委

員

阿部恭一

ANA システムズ株式会社

主席研究員

品質・セキュリティ管理部

エグゼクティブマネージャー〃

伊藤 昇

株式会社大塚商会 たよれーるマネージメントサービスセンター
センター長

〃

江原悠介

PwC あらた有限責任監査法人 システムプロセスアシュアランス
シニアマネージャー〃

大谷和子

株式会社日本総合研究所

〃

小川隆一

独立行政法人情報処理推進機構
セキュリティ対策推進部

執行役員法務部長
セキュリティセンター

セキュリティ分析グループ

グループリーダー〃

垣内由梨香

マイクロソフトコーポレーション セキュリティレスポンスチーム
セキュリティプログラムマネージャー

〃

金森直樹

株式会社 TKC

栃木本社

システムエンジニアリングセンター

IT 投資企画部長〃

田上利博

サイバートラスト株式会社

マーケティング本部

プロダクトマーケティング部

担当部長

〃

坪井正広

株式会社野村総合研究所

〃

中尾康二

国立研究開発法人情報通信研究機構 サイバーセキュリティ研究所
主管研究員

〃

萩原健太

グローバルセキュリティエキスパート株式会社

CSO

Software ISAC 代表〃

板東直樹

アップデートテクノロジー株式会社

〃

深津 博

愛知医科大学病院

代表取締役社長

医療情報部 医療情報部長・特任教授

一般社団法人医療 ISAC 代表理事〃

丸山満彦

PwC コンサルティング合同会社

〃

山崎文明

情報安全保障研究所合同会社

〃

山根義則

三菱自動車工業株式会社

パートナー

首席研究員

情報セキュリティ室 マネージャー

オブザーバー
経済産業省、一般社団法人コンピュータソフトウェア協会、一般社団法人電子情報技術産業協会、一般社団法人情報サービス産業協会、一般社団法人日本情報システム・ユーザー協会

20