大規模な基幹刷新プロジェクトでは、SOW（作業指示書）や個別注文を積み重ねる“多段階・分割契約”のかたちが常識となりました。フェーズや領域ごとに契約を細分化すれば、進行管理や予算統制は格段にやりやすくなります。しかしその一方で、ひとたび紛争となれば、ユーザーが「重大な不履行を理由に全体を解除したい」と主張しても、裁判所がそれをどこまで認めるのか——ここに、実務上の最大の難関が待ち構えています。
本稿は、Z会対日立ソリューションズ事件と、野村HD対日本IBM事件という、対照的な結論に至った二つの判例を取り上げます。分割された契約群のどこまでを“一つの運命共同体”として解除できるのか、そして「責任限定条項」という名の防波堤が、その結論をいかに左右するのか。裁判所が描く緻密な判断の地図を、実務の羅針盤として読み解いていきましょう。結論を先に示せば、司法は「密接関連性」という事実の網の目をもって解除の範囲を慎重に選別し、当事者が契約を分けた意思を尊重しながら、解除も損害も個別に判断していくのです。
二つの巨大プロジェクト、二つの異なる運命
現代のシステム開発紛争を象徴する二つの事件があります。一つはZ会事件、もう一つは野村vsIBM事件。どちらも巨大プロジェクトを複数の契約に分割して進めるという、今日ではごく当たり前の手法が採られました。しかし、プロジェクトが暗礁に乗り上げたとき、その運命は契約のあり方によって大きく分かれたのです。
Z会事件の舞台は、通信教育大手の基幹システム刷新プロジェクトでした。計38本の個別契約で進められ、2017年1月11日に本番稼働を迎えたものの、その二日後の1月13日に深刻なシステム障害が発生し、事業に甚大な打撃を与えました。この事態を受け、Z会はベンダである日立ソリューションズを提訴。東京地裁（2022年2月24日判決）はベンダの責任を広く認め、既払契約代金の返還（原状回復）として約11億円及び遅延損害金の支払を命じました。続く東京高裁（2022年10月5日判決）もこの判断を支持し、判決は確定しました。この事件では、プロジェクトの中核における失敗が、密接に関連する契約群にまで影響を及ぼすことが示されました。
一方、野村HD・野村證券と日本IBMが17本の個別契約で進めた大規模プロジェクトに対しては、全く異なる判決となります。プロジェクトの頓挫をめぐる訴訟で、東京地裁（2019年3月20日判決）は最終段階の3契約に限りIBMの不履行を認め、約16.2億円の支払いを命じました。しかし、その後の東京高裁（2021年4月21日判決）で地裁判決は覆され、野村側の本訴請求は全部棄却。逆にIBMの反訴請求が約1.12億円認容されるという逆転判決が下されたのです。この高裁判決は、2021年12月に野村側が上告を取り下げたことで確定しています。
なぜ、これほどまでに結論が分かれたのか。その謎を解く鍵は、裁判所が用いた「密接関連性」という物差しと、契約書に仕組まれた「責任限定」、そして「全体の完成義務」の有無という名の防衛線にあります。
解除の網はどこまで広がるか？——Z会事件が示した「密接関連性」という物差し
Z会事件の論点の一つは、「一つの契約の失敗が、どこまでの契約の命運を絶つのか？」という点にありました。この論点に対し、裁判所は「すべて連帯責任」か「個別の責任」かという単純な二元論では答えませんでした。Z会事件で裁判所は“密接関連性”を基準に、総合試験や最終修正など“完成に直結する工程”に密接な契約について解除・原状回復の射程を広めに認めました。一方、周辺的・独立価値のある契約は一律には巻き込まないという“選別的”アプローチを採っているのです。
この物差しの基準は、極めてシンプルです。解除の原因となった契約と、他の契約は、目的や内容においてどれほど強く結びついているかー裁判所は38本の契約群を一つの塊として見るのではなく、一つひとつの契約がプロジェクトという大きな物語の中でどのような役割を担っていたかを、丁寧に読み解いていきました。
例えば、プロジェクトの初期段階である要件定義や、本体システムとは独立して機能するサブシステムの移行に関する契約は、それ単体でも一定の価値があり、本体の完成と必ずしも運命を共にするわけではないと評価されました。そのため、本体開発の契約が失敗したからといって、これらの契約まで自動的に解除することは認められませんでした。
しかし、システムの品質を最終的に担保する「総合試験」や、そこで見つかった不具合を修正する作業など、システムの完成に不可欠なクライマックスを担う契約群には、全く異なる判断が下されました。裁判所は、これらの工程を「実質的にシステムを完成させるための契約」と位置づけ、開発本体の契約とは切っても切れない運命共同体であると認定。したがって、本体契約が解除されるならば、この最終工程に関する契約もまた、その運命を共にすべきだと判断したのです。
このアプローチは、当事者がなぜ契約を分けたのか、その意思を深く尊重する姿勢の表れです。Z会事件は、分割された契約群の中からプロジェクトの「核」となる部分を見出し、そこを選択的に解除の網にかけるという判断モデルを私たちに示しています。
契約という名の防波堤——野村vsIBMが教える「分割契約×責任限定」の防御術
Z会事件が「事実上の結びつき」を重視したのに対し、野村vsIBM事件は「契約上の設計」がいかに強力な防波堤となり得るかを教えてくれます。この事件では、ユーザーが期待したであろう「システムが完成しなかった」という事態に対する包括的な責任追及が、契約書の構造そのものによって、最終的に阻まれました。
まず地裁段階では、各個別契約ごとの責任限定条項の適用が認められ、裁判所が算定した損害額約19.1億円が、「個別契約13〜15に対応する代金・代金相当額の合計」を上限として、認容額約16.2億円へと圧縮されました。この時点では、責任限定条項が有効に機能したと言えます。
しかし、高裁はIBMの契約上の完成義務自体を否定して野村側請求を棄却したため、そもそも賠償責任が発生せず、責任限定条項の射程に実質的に踏み込む必要がありませんでした。高裁の判断の核心は、「個々の契約は、それぞれの段階的な目的を達成するためのものであり、プロジェクト全体の最終的な成功までを法的に約束したものではない」という点にあります。ユーザー側から見れば、17本の契約はすべて、一つの壮大なシステムを完成させるための部品だったかもしれません。しかし、高裁は契約書の文言を厳格に解釈し、そこに「全体の完成義務」までは書かれていないと判断したのです。
この高裁の判断は、極めて実践的な教訓を示しています。プロジェクトを段階ごとに分割し、その都度の対価と責任を個別の契約単位で「個別完結」させる設計は、紛争時にリスクの延焼を防ぐ強力な防火壁となり得ます。野村事件は、そもそも「全体の完成義務」という概念を契約設計の段階で法的に発生させないことで、責任追及の根幹を揺るがすことに成功したのです。これは、契約設計がいかに強力なリスク管理ツールであるかを示す、見事な事例と言えるでしょう。
矛を研ぐユーザー、盾を固めるベンダ——実務に活かす二つの教訓
二つの事件が描く裁判所の見取り図は、今や明らかです。それは、「事実」の積み重ねと「条項」の設計という二つの軸で成り立っています。この地図を手にすれば、ユーザーは解除という鋭い「矛」を研ぎ、ベンダは責任限定という堅い「盾」を固めることができます。
まず、ユーザーが「全体解除」という矛を手にしたい場合、焦点を当てるべきは事実の側面です。Z会事件が示すように、プロジェクトの中核、すなわち「これがなければシステムは完成しない」と言える工程は何かを見極め、その重要性を客観的な証拠で固めていく必要があります。総合試験や最終的な欠陥修正といった工程が、まさにその「核」にあたります。これらの工程がプロジェクト全体の運命を握っていることを、議事録、課題管理票、テスト計画書といった日々の記録を通じて立証していくのです。この事実の積み重ねが、「密接関連性」を強め、解除の網を広げる力となります。
条項面では、基本契約の段階で布石を打つことが不可欠です。第一に、プロジェクト全体の最終目的を明確にうたうこと。第二に、各個別契約がその全体目的を達成するために相互に依存している関係にあることを条文で宣言すること。そして第三に、一つの契約で重大な不履行があれば、関連する他の契約も解除できるという「クロスデフォルト条項」を設けることです。
一方で、ベンダがリスクの防波堤という「盾」を固めたいのであれば、野村vsIBM事件の高裁判決に倣い、条項の設計に全力を注ぐべきです。戦略の核は、各契約の「個別完結性」を徹底し、「全体の完成義務」を負わないことを明確にすることです。契約ごとに明確な成果物、独立した検収手続き、そして個別の支払条件を定め、一つの契約が終われば、その範囲では完全に責任関係が清算される構造を作り上げます。そして、その盾を補強するのが、責任限定条項です。これにより、万が一責任が認められた場合でも、損害を限定することができます。
転ばぬ先の杖——解除後の「後始末のルール」を設計する
契約解除の議論で、見落とされがちながら極めて重要なのが、解除が認められた“後”の世界、すなわち「原状回復」のルールです。壊れた契約関係をどう清算し、後始末をするのか。このルールを事前に設計しておくことは、まさに転ばぬ先の杖となります。
Z会事件でも、支払った代金の返還を求める原状回復請求は、大きな争点となりました。分割契約では、この後始末がさらに複雑になります。すでに検収・支払いが終わった多数の契約について、どこまで遡って代金を返還させるのか。納品済みのソースコードやライセンスの扱いはどうするのか。この設計を怠れば、紛争は出口のない迷路に迷い込みます。
ユーザーとしては、プロジェクト全体の目的が達成されなかった場合には、たとえ一部の工程で検収を済ませていたとしても、それらを含めて代金返還や成果物の使用停止が認められるよう、クロスデフォルト条項と連動した設計を目指すべきです。
逆にベンダは、リスクを限定するため、後始末の範囲を明確に区切る必要があります。検収が完了した部分については、法的に「完成した部分」として原状回復の対象外となることを明記します。また、ハードウェアや第三者のライセンスなど、物理的に返還が不可能なものについては、あらかじめ例外として定めておくべきです。どちらの立場であっても、これらのルールを支えるのは日々の運用記録であり、客観的なドキュメントが最終的な判断の拠り所となるのです。
結論：“分けたなら、繋ぎ方も決めよ”——分割契約時代の鉄則
プロジェクトを分割して契約することは、複雑な航海を安全に進めるための優れた航海術です。しかし、いざ嵐に見舞われたとき、その船がバラバラになるか、一つの船として乗り切れるかの運命を分けるのは、「分割された部品をどう結合させるか」という、あらかじめ定められた“結合ルール”に他なりません。
Z会事件は、契約書という形式を超えて、プロジェクトの「実質」を見抜き、「密接関連性」という網目で解除の範囲を選別する司法の姿勢を示しています。一方、野村vsIBM事件は、緻密な契約設計がいかに強力な防波堤となり、リスクの連鎖、ひいては責任追及そのものを断ち切るかを教えてくれます。
分けて契約するのならば、それらがどう繋がり、どう切れるのか、そのルールも同じだけの熱意をもって設計する。これこそが、多段階契約が当たり前となった現代において、巨大プロジェクトを成功に導き、万一の紛争を乗り切るための、唯一にして最短の設計思想と言えるでしょう。
