社会・産業のデジタル変革

「情報システム・モデル取引・契約書」からの見直しのポイント

公開日：2025年6月17日

独立行政法人情報処理推進機構
デジタル基盤センター

「民法改正整理反映版」における見直しのポイント

「民法改正整理反映版」では、主にモデル契約に直接かかわる請負及び準委任に関する改正民法への対応について検討が行われました。主な論点としては、以下の通りです。詳細及び対応した他の事項については「全体の解説」をご覧ください。

主な論点

請負契約における契約不適合責任
- (1) 「報酬減額請求権」が救済方法として追加されたことへの対応
- (2) 契約不適合責任における「損害賠償」と「解除」の位置づけ
- (3) 契約不適合責任における「権利行使の期間制限」への対応
請負契約・準委任契約における報酬請求権
- (4) 成果報酬型準委任契約の位置づけ
- (5) 中途解除の場合の報酬請求権の帰趨

一例：「権利行使の期間制限」（上記1.(3)）に関する見直しの概説

(a) 現行のモデル契約における規律: ソフトウェア開発業務における瑕疵担保責任の期間制限は検収完了時から○ヶ月以内

(b) 民法改正の概要: 改正前の瑕疵担保責任の存続期間は目的物の引渡時／仕事の終了時から1年以内に権利を行使する必要があったが、改正後の契約不適合責任では契約不適合を知った時から1年以内にその旨の通知をすればよいことになり、注文者（ユーザ企業）が契約不適合を「知る」までの間は消滅時効一般の規定に基づき、10年間権利の行使がされ得ることとなった。

(c) モデル契約見直し検討における主な議論

（引き続き起算点を検収完了時とすべき意見）

責任が追及されうる期間が延びれば人員維持のコストが上がり、そのコストが報酬に転嫁される結果、ユーザ企業に不利益になるのではないか
現状の「検収完了時から1年は瑕疵担保責任、それ以降は保守契約での対応」はユーザ企業にとっても経済的ではないか
開発環境は日々変化していくのであって、検収完了から長期間経過後に修正を求められても当時の開発環境が再現できないのではないか
ユーザ企業が権利を行使できる期間の進行が契約不適合を認識するまで開始しないのであれば、適切な検査を行うインセンティブがユーザ企業に生じないのではないか

（現行の規律を変更すべきという意見）

責任が追及されうる期間が延びた際のコスト増の見積もりの適切さに疑問がある
民法上のデフォルトルールでは契約不適合責任に基づき無償対応すべきであるはずの期間にもかかわらず、保守契約で有償対応するのはおかしいのではないか
仮に民法から期間を短縮するとしても、ベンダに大きな落ち度がある契約不適合も保護対象になるのはおかしいのではないか
適切な検査を行うインセンティブを考えて起算点を検収完了時とする規律を維持するのであれば、性質上検査で発見することは難しい契約不適合についてはその規律の適用を外すべきではないか

(d) 「民法改正整理反映版」での見直し結果

期間制限の起算点を検収完了時という客観的なものとする規律は維持する
契約不適合がベンダの故意・重過失に起因する場合には、客観的な起算点からの期間制限を適用除外にする
改正民法下では期間が1年以上に設定されることもあり得ることから、モデル契約上の期間制限の表記は「〇ヶ月／〇年」とする

また、見直しについての解説では、ユーザ企業とITベンダの間で具体的な期間を決定するために対話による共通理解を得ることが望ましいポイントもあわせて紹介している。

「第二版」における見直しのポイント

民法改正に直接かかわらない5つの論点について検討が行われました。

(1) セキュリティ

概要: 近年重要性を増しているセキュリティに関して、システム開発の段階においてユーザとベンダがリスクやそれに対応するためのコストについての共通理解をした上で、適切な責任分界点を設定するためのプロセス及び契約条項上の手当をモデル契約で提案できないか。

見直しの観点・内容

ユーザとベンダとは、それぞれの立場に応じて必要な情報を示しつつ、リスクやコスト等について相互に協議することにより、システムに実装する「セキュリティ仕様」を決めることが必要である。その観点から以下の見直しを行った。

条項の見直し（定義条項、責任者条項、セキュリティ条項）
セキュリティの実装プロセスに関する解説の加筆
セキュリティ検討PTによる「セキュリティ仕様関連文書」の策定

見直しの対象: 条項解説関連文書

(2) プロジェクトマネジメント義務及び協力義務

概要: 近年特に問題となっている、ベンダのプロジェクトマネジメント義務及びユーザの協力義務について、モデル契約上の手当てによって、紛争の予防に資することはできないか。また、それぞれの義務について裁判例を踏まえて一定の整理ができないか。

見直しの観点・内容

裁判例で示されたプロジェクトマネジメントや協力義務は、それぞれ個別事案における判断であり、汎用性の高いモデル契約の中にこれらの義務を規定することは難しいことから、条項の形で追記することは見送り、以下のような見直しを行った。

新たな裁判例を当該事案に関連する箇所における紹介
ユーザ及びベンダの役割分担・プロジェクトマネジメントに関する記述の見直し
マルチベンダ形式における用語法の修正
ベンダの中止提言を踏まえた解約権のオプション条項としての追加

見直しの対象: 条項解説

(3) 契約における「重大な過失」の明確化

概要: 従前のモデル契約においては、「重大な過失」の有無が損害賠償の責任制限条項の適用の分水嶺となっており、また、昨年12月に公表した民法改正に対応した見直しによって、ソフトウェア開発業務等の請負型の業務における契約不適合責任においても、「重大な過失」の有無が客観的起算点による期間制限の適用の分水嶺となった。この「重大な過失」について、ベンダ側の予測可能性の担保の観点からより明確化することはできないか。

見直しの観点・内容: 契約条項として重過失については特段の定義をすることはせず、重過失概念に関する一般的な理解とシステム開発に関する裁判例のうち重過失についての判例を逐条解説に追記することで、重過失を考える上での手がかりを提供する。

見直しの対象: 解説

(4) システム開発における複数契約の関係

概要: 多段階契約においては、しばしば下流工程でトラブルが生じた際にユーザが上流工程まで遡って解除に基づく代金返還請求をしたり、損害賠償責任を追及するという紛争が頻発しているが、そのような紛争の予防・解決のためにモデル契約上何らかの手当ができないか。

見直しの観点・内容: 複数の個別契約がどのような処理になるのかは、個別契約の関係や問題となった債務不履行次第であることから、契約条項として手当するのではなく、裁判例を整理して得られた共通理解を解除条項の逐条解説に追記し、利用者の理解に資する。

見直しの対象: 解説

(5) 再構築対応

概要: 現行のモデル契約はスクラッチ型の新規開発を念頭においたものであるが、デジタルトランスフォーメーションの実行に向けた既存システムの再構築をも念頭に置いたものになるような見直しが必要ではないか。

見直しの観点・内容: 要件定義に入る前に、再構築対象の現行システムについての調査を行い、その仕様を明らかにした上で再構築を行う必要があるが、現行システム調査には、専門的な技術も必要で、コストと時間を要する。現在動作している通りのシステムを再構築するだけ（現行踏襲）と考えるユーザにはこの意識が薄い。ITシステム部門向けには再構築に関するガイドブック類が公表されているものの、業務マネジメント層や契約に関わる部署に向けたものは少なく、モデル取引・契約書の中で注意喚起する。

見直しの対象: 解説

セキュリティ仕様書の作成プロセス

「第二版」では、セキュリティ仕様書の作成プロセスを明確化し、その内容を解説に記載するとともに、そのプロセスを前提とする契約書の条項を整理しました。

セキュリティに関しては、公的機関や業界団体、セキュリティ関連企業等が提供する、脅威分析を行い攻撃への影響と対策（緩和策）等を検討するための参照情報（ここでは「セキュリティ基準等公表情報」と総称）を使用して、ユーザとベンダが以下のような協力をすることにより、セキュリティ仕様書を作成します。

必要な情報を相互に出し合う。
セキュリティ基準等公表情報を参照し、セキュリティの脅威を把握する。
開発対象のシステムについて考慮しつつ、脅威の影響についてリスク評価を行う。
対策の実装有無を決定・合意し、その結果をセキュリティ仕様書に反映する。

対策を実装しない場合にも、その旨を記録することが重要です。そのため、システム開発の各段階において、ユーザおよびベンダのそれぞれが提供すべき情報や検討すべき事項は何か、各段階の成果物は何か、どの段階でセキュリティ仕様を確定するのか等について整理します。

セキュリティ基準等公表情報を使用した一般的なセキュリティ仕様書の作成イメージは次の通りです。

脚注1

セキュリティ基準等公表情報は唯一ではなく、システム稼働環境等に応じて多種が存在し得る（1つの文書にまとめられていない場合もある）
脚注2

実装する場合には、対策内容をコピーしてカスタマイズ
脚注3

実装しない場合には、その理由等を記載（議事録への記載ケースもあり）

このようなプロセスにおいて参照するセキュリティ基準等公表情報の一例として、今回、「情報システム開発契約のセキュリティ仕様作成のためのガイドライン～Windows Active Directory編～」を作成しました。また、対応するプロセスについて、「セキュリティ仕様策定プロセス～「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」対応～」に整理しました。

システム再構築における企画プロセス

長年運用・保守を続けてきたシステムを再構築する場合、現行システムに関する業務知識（ドキュメントと有識者）が失われていることが多く見られます。そのため、現行システムの状態を正しく認識した上で再構築の方針を決め、実行計画を立てることが肝要です。システム再構築におけるこのような課題と、特に企画段階のプロセスについて、「第二版」では次のような解説を追加しました。

再構築の流れとしては、まず、企画段階・システム化の方向性フェーズにおいて、再構築の目的・要求事項や現行システムの状況から最適な再構築手法を選択しリスクを洗い出します。次に、企画段階・システム化計画フェーズにおいて、選択した手法とそのリスクをもとにリスクの予防策を検討します。

ユーザは、必要に応じて、ベンダとの間で、これらの支援業務（後のシステム開発契約の範囲外）を内容とする準委任契約としてのコンサルティング契約を締結し、これらの作業のための支援を受けることになります。

このようなシステム開発プロセスにおける再構築特有の検討の位置づけは、下図の通りとなります。