◯本ブログ記事は専らAIで作成したものです。
◯東京高裁令和７年９月２５日判決（担当裁判官は４０期の萩本修，４９期の齋藤巌及び５１期の天川博義）はD1-Law版『判例体系』に載っています。
目次
第１ 本判決の意義
１ 複合的な争点に対する包括的な判断
２ 実務家に突きつけられた課題
第２ 事案の概要と詳細な事実経過
１ 当事者および契約の概要
(1) 当事者の属性と役割分担
(2) 対象システムの特性と契約内容
２ プロジェクトの進行と破綻の経緯
(1) 要件定義から基本設計工程における遅延の発生
(2) 詳細設計工程の未完了と製造工程への見切り発車
(3) テスト工程の形骸化と「条件付き合格」の強行
(4) 本稼働延期の繰り返しと現場の疲弊
(5) ハラスメントの激化とベンダーによる現場撤退
第３ 裁判所の判断――法的構成と事実認定の分析
１ 仕事の完成と履行遅滞の成否
(1) システム開発契約における「仕事の完成」の基準
(2) 本件における完成の否定と履行遅滞の認定
２ ベンダーのプロジェクトマネジメント義務違反
(1) ＰＭ義務の具体的内容と本件での適用
(2) 進捗管理および阻害要因への対処義務違反
３ ユーザーの協力義務違反
(1) 公的機関としての高度な協力義務
(2) 仕様変更と不具合修正の境界線に関する判断
(3) ハラスメント言動と協力義務違反の認定
４ 過失相殺と損害賠償の範囲
(1) ６対４という過失割合の算定根拠
(2) 既払報酬の返還範囲と不当利得の精算
(3) 損害の範囲と相当因果関係
第４ AI技術者としての技術的考察
１ 開発プロセスにおける「V字モデル」の崩壊と教訓
(1) 詳細設計承認なき製造着手のリスク評価
(2) 「仕様凍結」の欠如が招くデスマーチの構造
２ Salesforce／PaaS開発特有の技術的論点
(1) 標準機能への適合（Fit & Gap）の失敗要因
(2) 成果物の流用可能性に関する技術的評価の妥当性
３ データ移行と「不整合データ」の実務的課題
(1) データクレンジングの責任分界点と契約実務
(2) レガシーマイグレーションにおける泥沼化の防止
第５ AI特定社会保険労務士としての労務的考察
１ プロジェクト現場におけるハラスメントの法的評価
(1) 協力義務違反を構成するハラスメントの閾値
(2) 「能力不足」発言等の違法性と現場への影響
２ 安全配慮義務の所在と「職場放棄」の法的評価
(1) 現場引き揚げ（撤退）の正当性と法的リスク
(2) メンタルヘルス不調と損害賠償請求の可否
第６ 弁護士としての実務への提言
１ 契約書作成および交渉における具体的留意点
(1) 協力義務の具体化と免責条項の設計
(2) ハラスメント対応条項の導入と運用
２ 紛争予防のためのプロジェクト法務の在り方
(1) 議事録とエビデンスによる自己防衛の重要性
(2) チェンジマネジメント（変更管理）の徹底と法務の介入
第７ 結語
第１ 本判決の意義
１ 複合的な争点に対する包括的な判断
本稿で詳細に検討を行う東京高等裁判所令和７年９月２５日判決（以下「本判決」といいます。）は，大規模なシステム開発プロジェクトが頓挫した事案において，ベンダー（受託者）のプロジェクトマネジメント義務（以下「ＰＭ義務」といいます。）違反と，ユーザー（発注者）の協力義務違反の双方を真正面から認定し，その責任割合を「ベンダー６：ユーザー４」と判示した極めて重要な裁判例です。
システム開発を巡る紛争においては，従来から「仕様の未確定」や「不具合か仕様変更か」といった技術的・契約的な論点が頻出していました。
しかし，本判決はこれらの伝統的な論点に加え，ユーザー側の担当者によるハラスメント言動（パワーハラスメントに類する威圧的言動）を協力義務違反の構成要素として明確に認定した点において，画期的な意義を有しています。
また，Salesforceという世界的なクラウド基盤（PaaS/SaaS）を用いた開発における成果物の流用可能性や，レガシーシステムからのデータ移行における責任分界点についても踏み込んだ判断を示しており，現代のＩＴ実務に即した最新のリーディングケースとしての性格を強く有しています。
２ 実務家に突きつけられた課題
本判決は，単に過去の紛争を解決したというにとどまらず，現在進行形のプロジェクトを抱えるすべてのシステム開発ベンダー，発注者であるユーザー企業・公共団体，そしてその支援者である弁護士，コンサルタント等の専門家に対し，極めて重い課題を突きつけています。
特に，詳細設計が完了しないまま製造工程に進むという，実務上しばしば見られる「見切り発車（ファストトラッキング）」的なプロジェクト進行に対し，裁判所が厳しい法的評価を下した点は見逃せません。納期遵守のプレッシャーの中で行われる現場判断が，法的には「ＰＭ義務違反」と評価されるリスクが浮き彫りになりました。
また，現場で横行しがちな「能力がない」「やる気がない」といった威圧的な言動が，単なる感情的な対立や道義的な問題を超えて，数千万円から億円単位の賠償責任に直結する法的瑕疵（協力義務違反）となることが示されたことで，プロジェクト現場のコンプライアンス意識改革，とりわけハラスメント防止策の徹底が急務となるでしょう。
第２ 事案の概要と詳細な事実経過
１ 当事者および契約の概要
(1) 当事者の属性と役割分担
１審原告（控訴人兼被控訴人。以下「ユーザー」といいます。）は，◯◯◯◯という独立行政法人であり，◯◯企業支援のための高度化事業に係る融資業務等を行っています。
公的機関として，高い公共性と業務の正確性が求められる立場にあります。
また，本件プロジェクトにあたっては，外部からＣＩＯ（最高情報責任者）を招聘し，大手コンサルティング会社である株式会社クニエにＰＭＯ（Project Management Office）業務等の工程管理支援を委託するなど，形式的には人的・物的に十分な体制を整えていました。
１審被告（被控訴人兼控訴人。以下「ベンダー」といいます。）は，ソフトウェアの生産販売等を目的とする株式会社であり，本件システム開発を入札により落札・受注しました。Salesforceを用いたシステム構築に関し，企画提案書において豊富な実績と専門的知見を有することをアピールしていました。
(2) 対象システムの特性と契約内容
本件契約は，ユーザーが行う「高度化事業」に係る貸付管理及び債権管理等の業務システムである「次期高度化システム」の構築を目的とするものでした。
契約形態：請負契約（システム開発契約）。変更契約により期間伸長等がなされました。
開発手法：基本的にはウォーターフォールモデルを想定（要件定義→基本設計→詳細設計→製造→テスト）。
技術基盤：株式会社セールスフォース・ドットコムの提供するクラウド基盤（Salesforce）を利用。
当初の納期：平成３１年３月３１日（システム稼働日は同年３月４日）。
契約金額：２億６６７６万円（税込・当初）。
２ プロジェクトの進行と破綻の経緯
(1) 要件定義から基本設計工程における遅延の発生
プロジェクトは当初から遅延傾向にありました。
要件定義工程においては，先行して作成された「富士ゼロックス要件定義書案」をベースに，ベンダーがフィット＆ギャップ分析（F&G）を行う予定でした。
しかし，実際には同案の業務フローに記載のない業務（大フロー漏れ）が２件発見されたほか，１１５フロー中５７フローにおいて修正が必要となるなど，当初想定を超えた作業が発生しました。ベンダーは人員を増強して対応しましたが，要件定義工程完了報告書は，成果物の一部未定稿や内容の不備を指摘され，第１回中間判定会議では完了判定を得られず，修正後の６月にようやく承認を得るという状況でした。
続く基本設計工程においても，ヒアリングの日程調整が難航しました。ユーザー側の担当者が多忙であり，またユーザー内部での意見調整（各課長の承認等）に時間を要したためです。
ベンダーは，基本設計工程を１か月延長（７月末まで）し，その分システムテストおよび運用・受入テスト期間を短縮するという苦肉の策を提案し，ユーザーの了承を得ました。この時点で，後の品質問題の種（テスト期間の不足）が撒かれていたと言えます。
(2) 詳細設計工程の未完了と製造工程への見切り発車
本件の最大のターニングポイントは詳細設計工程です。
当初の計画では，詳細設計工程完了時に中間判定を行い，仕様を凍結してから製造（プログラミング）に進むはずでした。しかし，ユーザーからの要望事項が膨らみ（帳票６６種類の追加等），合意形成が大幅に遅れました。
そこで，スケジュールの遅れを取り戻すため，平成３０年１１月の全体会議において，「詳細設計工程完了の中間判定を待たず，仕様が固まったものから順次製造に着手する」という方針がベンダーから提案され，決定されました。これはＰＭ用語で「ファストトラッキング」と呼ばれる手法ですが，仕様変更リスクを抱えたまま後工程に突き進む危険な賭けでもあります。
結果として，詳細設計書についてユーザー担当者の全承認が得られないまま製造が進み，仕様の認識祖語が解消されない状態でテスト工程に突入することとなりました。平成３０年１２月２５日時点でも，詳細設計書の合意率は８割弱にとどまっていました。
(3) テスト工程の形骸化と「条件付き合格」の強行
製造工程の見切り発車によるツケは，テスト工程で爆発しました。
単体テスト・結合テストの段階で多数の不具合が発生し，スケジュールはさらに圧迫されました。特に，ユーザーが実施する運用・受入テストの期間は，当初計画の「２か月」からわずか「３週間」にまで短縮されました。これはシステム監査の視点から見れば，テストの網羅性を担保できない致命的な状況です。
平成３１年３月２８日，ベンダーは「稼働判定報告書」を提出しましたが，そこには不具合修正やデータ移行の確認が完了した旨が記載されつつも，実態としては品質リスクが残存する状態での「条件付き合格」でした。
結局，平成３１年３月中の本稼働は断念され，契約期間の延長と稼働時期の延期（７月→１１月→翌年１月）が繰り返されることとなります。
(4) 本稼働延期の繰り返しと現場の疲弊
平成３１年４月以降もベンダーは体制を維持し，不具合修正やデータ移行作業を継続しました。しかし，データ移行において，パッチ適用の誤りによるデータ破壊（違約金データの二重登録等）等のイージーミスが発生し，さらなる遅延を招きました。
一方で，ユーザー側からは，詳細設計が未承認であることを理由に，製造済みの機能に対しても修正要求が出され続けました。ベンダー側はこれを「不具合対応」として処理していましたが，実質的には「仕様変更」の側面が強く，現場は疲弊していきました。
また，稼働延期に伴う既存システムの維持費用負担を巡って，ユーザー幹部がベンダー幹部に対し，念書を書かせるなどの強い圧力をかける場面も見られました。
(5) ハラスメントの激化とベンダーによる現場撤退
プロジェクトが泥沼化する中，ユーザー担当者Ｈらによるベンダー担当者への言動が過激化していきました。
録音や証言によれば，担当者Ｈは「うちの職員が能力ねえから，お前らダメだって言ってんでしょうが」「御社は能力が無いんですよ」「やるやる詐欺をまたやるってことですか」といった，人格否定発言を繰り返しました。
また，Ｎ課長による「町工場以下ですよ」といった企業としての能力を侮辱する発言もありました（なお，「町工場以下ですよ」等の発言については，プロジェクト遅延に対する追及の過程として違法性は否定されています）。
さらに，協議が難航する中，ベンダー役員が，ユーザーからの社内ミーティング参加要請を断る際に，自ら土下座をして断るという場面も見られましたが，裁判所は，これをプロジェクトが大幅に遅延している状況下での折衝過程における一幕であり，ユーザーによる強要やハラスメントには当たらないと判断しました。
もっとも，令和２年１月，ベンダーはついに，担当者Ｈらの交代等を要求し，これが受け入れられるまでは現場要員を引き揚げると通告しました（１月２９日付け通知）。そして同年２月５日，実際に要員を引き揚げ（撤退），作業を停止しました。
これに対し，ユーザーは契約解除（債務不履行解除）を通知し，双方が提訴に至るという最悪の結末を迎えました。
第３ 裁判所の判断――法的構成と事実認定の分析
１ 仕事の完成と履行遅滞の成否
(1) システム開発契約における「仕事の完成」の基準
請負契約における報酬請求権の発生要件である「仕事の完成」について，判例実務は「予定された最後の工程まで終了したか否か」という形式的基準と，「主要な機能が備わっているか」という実質的基準を併用して判断します。
本判決もこの枠組みに従い，本件システムの構築・稼働という目的が達成されたか否かを検討しました。
(2) 本件における完成の否定と履行遅滞の認定
ベンダーは，「成果物を納品し，条件付きながら稼働判定に合格した」として仕事の完成を主張しました。また，Salesforceのアカウントを引き継ぎ，ユーザーが検収して代金を支払った事実も根拠としました。
しかし，裁判所はこれらを以下の理由で退けました。
実際には本稼働に至っておらず，稼働判定後もプログラム修正，設計書整備，マニュアル整備等の開発業務が継続していたこと。
ユーザーが支払った代金は，予算執行上の便宜的なものであり，実質的な完成確認を裏付けるものではないこと（検査調書の形式的作成）。
- ベンダー自身が再三にわたり稼働延期を申し入れていたこと。これらを根拠に，仕事は「未完成」であると認定しました。そして，合意により延長された最終的な期限（令和２年１月６日）を経過しても完成せず，さらにベンダーが一方的に現場から撤退し，作業を停止した点について，裁判所は「履行遅滞の解消に努める意思がないことを明らかにしていた」と厳しく指摘し，ベンダーの履行遅滞（及び債務不履行解除の有効性）を認定しました。
２ ベンダーのプロジェクトマネジメント義務違反
(1) ＰＭ義務の具体的内容と本件での適用
裁判所は，システム開発の専門家であるベンダーに対し，以下のＰＭ義務を課しました。
進捗状況を適切に管理する義務。
開発の阻害要因を把握し，解消に努める義務。
- ユーザーの行為が開発を阻害しないよう働きかける義務。これは，従来の裁判例の潮流に沿ったスタンダードな規範です。特に，ユーザーがＩＴに不慣れな場合だけでなく，本件のように一定の体制を持つユーザーに対しても，ベンダーがプロとしてリードする責任があることを確認しました。
(2) 進捗管理および阻害要因への対処義務違反
本判決は，ベンダーのＰＭ義務違反を厳しく認定しました。
具体的には，安易な「条件付き合格」でお茶を濁し，根本的な品質問題や進捗遅延を解決できないままズルズルとプロジェクトを引き延ばした点や，詳細設計未完了のまま製造を進めるリスクを制御しきれなかった点が重視されました。
また，現場撤退という強硬手段に出たことも，ハラスメントへの対抗措置としての側面はあるものの，プロジェクトを完成させる義務の放棄として，ＰＭ義務違反（ないし債務不履行）の一部を構成すると評価されました。
３ ユーザーの協力義務違反
(1) 公的機関としての高度な協力義務
特筆すべきは，裁判所がユーザー（独立行政法人）に対し「高度な協力義務」を認めた点です。
ユーザーは国が所管する法人であり，専門部署やＣＩＯ，ＰＭＯコンサルタントを擁していました。このような人的・物的に十分な体制を持つユーザーには，単にベンダーの質問に答えるだけでなく，主体的に内部調整を行い，要件を確定させる責任があると判示しました。
これは，「ＩＴはベンダーの仕事」というユーザー側の甘えを許さない，強力なメッセージです。ユーザー内部での意思決定の遅れや，各課長の承認取りまとめをベンダーに丸投げした点などは，協力義務違反（あるいは過失相殺事由）として評価されました。
(2) 仕様変更と不具合修正の境界線に関する判断
詳細設計が完了していない状態で製造が進んだ本件において，後工程での修正指示が「不具合修正（ベンダー責任）」か「仕様変更（ユーザー責任）」かは最大の争点でした。
裁判所は，「製造・結合テスト結果報告書」が提出され，ＰＭＯが品質評価を行った時点（平成３１年２月２７日頃）以降の指示について，協力義務違反（仕様変更）を肯定しました。
すなわち，本来なされるべき詳細設計工程完了報告がなされないまま製造が進んだものの，上記時点までにはベンダーは詳細設計の承認を得て製造結果を報告したとみなされ，これ以降に行われた機能追加や変更の要求は，もはや「仕様変更」にあたると認定しました。
「詳細設計書にハンコがないから仕様は未確定だ」というユーザーの形式論を排し，プロジェクトの実態（製造済み・テスト済み）に即して仕様変更を認めた点は，実務感覚に合致する妥当な判断です。
(3) ハラスメント言動と協力義務違反の認定
本判決の白眉は，ユーザー担当者のハラスメント言動を協力義務違反として認定した点です。
裁判所は，担当者Ｈらの「能力がない」「やるやる詐欺」等の発言を，単なる不適切発言にとどまらず，「実際に作業に従事するベンダー担当者との協力関係に支障を生じさせ，作業の遅延に影響するおそれがある」として，法的な債務不履行（協力義務違反）を構成すると断じました。
一方で，ベンダー経営陣に対する厳しい追及（土下座要求等）の一部については，プロジェクトが大幅遅延している状況下での折衝過程として，違法性を否定したものもあります（前述の「町工場以下」発言や，土下座に至った経緯等）。
裁判所は，納期遅延や虚偽報告疑惑に対する追及は，発注者として正当な権利行使の範囲内であると認めました。この線引きは微妙ですが，少なくとも「現場のＳＥを萎縮させる言動」はＮＧである一方，経営陣同士の厳しい折衝は一定程度許容されるという基準が示されました。
４ 過失相殺と損害賠償の範囲
(1) ６対４という過失割合の算定根拠
裁判所は，プロジェクト破綻の一次的責任は完成義務を負うベンダーにあるとしつつも，ユーザーの責任も相応に重いとして，ベンダー６割，ユーザー４割の過失相殺を行いました。
ユーザーの責任を加重させた要因としては，前述の仕様変更指示の繰り返しに加え，データ移行における不整合データ（Dirty Data）の問題（ユーザーが修正すべきデータをベンダーに丸投げした点を含む）や，ハラスメントによる現場環境の悪化が考慮されています。
(2) 最終的な支払額の計算ロジック（既払金・損害・相殺の３ステップ）
本判決における金銭的な清算は，以下の３つのステップを経て，最終的にベンダーがユーザーに対して約１億１０００万円を支払うという結論に至りました。
① ステップ１：ユーザーへの「既払報酬の返還」（原状回復）
まず，契約解除に伴い，ユーザーがベンダーに支払い済みであった報酬（約２億５６００万円）の返還が検討されました。
裁判所は，要件定義工程（約９７０万円相当）は完了しておりユーザーに利益が残っているとして控除し，残りの「未完成部分（基本設計以降）」について返還を認めました。
ただし，ここでも「ベンダー６：ユーザー４」の過失相殺（信義則上の減額）が適用されたため，実際に返還が認められたのは対象額の６割にとどまりました。
計算式：対象額（約2億4700万円）× ベンダーの責任割合（60%） ≒ 約１億４８００万円 …(A)
② ステップ２：ユーザー及びベンダー双方の「損害賠償請求」
次に，プロジェクト破綻によって双方が被った「損害」の賠償が計算されました。
ユーザー側の損害
無駄になった内部人件費やシステム維持費等（総額約１億６００万円）のうち，ベンダーの責任分（60%）が認められました。
計算式：損害額（約1億600万円）× 60% ≒ 約６３００万円 …(B)
ベンダー側の損害（反訴）
ベンダーは当初，約６億１８００万円余りの損害を主張しましたが，裁判所はそのうち，ユーザーの協力義務違反（仕様変更対応等）により発生した追加工数等（実損害額は約２億５５００万円）を認定し，そのうちユーザーの責任分（40%）のみが認められました。
計算式：損害額（約2億5500万円）× 40% ≒ 約１億２００万円 …(C)
③ ステップ３：対当額での「相殺」と最終結論
最後に，ユーザーが受け取る権利のあるお金（(A)＋(B)）と，ベンダーが受け取る権利のあるお金（(C)）が対当額で相殺されました。
ユーザーの債権合計（(A)＋(B)）：約２億１１００万円
ベンダーの債権合計（(C)）：約１億２００万円
最終支払額：２億１１００万円 － １億２００万円 ≒ １億９００万円（＋遅延損害金）
このように，ベンダー側にも１億円を超える損害賠償請求権が認められたものの，ユーザー側の「既払金の返還請求権」と「損害賠償請求権」の合計額がそれを上回ったため，差引計算の結果として，ベンダーからユーザーへの支払いが命じられました。
(3) 損害の範囲と相当因果関係
ユーザー側の損害として，ＰＭＯ費用や代替ベンダー選定費用の一部が認められましたが，逸失利益や内部人件費の多くは否定されました。
特に，ユーザー職員の人件費については，協力義務の履行として当然負担すべきコストであるとして，原則として損害とは認められませんでしたが，本件では，通常想定される範囲を超えて無益となった労務費等として，約２５００万円の損害が認められました。
一方で，ベンダー側の損害（反訴）については，商法５１２条の報酬請求は否定されましたが，ユーザーの協力義務違反に基づく損害賠償として，追加作業にかかった人件費相当額の一部が認められました。
第４ AI技術者としての技術的考察
１ 開発プロセスにおける「V字モデル」の崩壊と教訓
(1) 詳細設計承認なき製造着手のリスク評価
情報工学の観点から見れば，本件プロジェクトは「V字モデル」の基本原則を逸脱した時点で，失敗が約束されていたと言えます。
ウォーターフォール開発におけるV字モデルでは，上流工程（設計）の品質が下流工程（製造・テスト）の品質を決定づけます。詳細設計が固まらないままコードを書くことは，設計図なしに家を建てるのと同じであり，システム監査の視点では「重大な指摘事項」に該当します。
ベンダーは納期遵守のプレッシャーからこの禁じ手を使いましたが，結果として手戻りが多発し，かえって工数が増大しました。「急がば回れ」というシステム開発の鉄則を無視したことの代償は極めて大きかったと言えます。
(2) 「仕様凍結」の欠如が招くデスマーチの構造
仕様凍結（フリーズ）は，プロジェクト管理における最重要マイルストーンです。本件では，ユーザーが「もっと良くしたい」あるいは「既存システムと同じにしたい」という要望から，テスト段階に至ってもなお変更要望を出し続けました。
技術的には，テストフェーズでの変更は，単なるコード修正だけでなく，影響調査，リグレッションテスト（回帰テスト），ドキュメント修正といった膨大な付帯作業を発生させます。ユーザーには「画面のボタンを一つ変えるだけ」に見えても，裏側では指数関数的に工数が増加する「デスマーチ」が加速します。
本判決が，ある時点以降の要望を「仕様変更」と断じたことは，この技術的真理を法的に追認したものであり，高く評価できます。
２ Salesforce／PaaS開発特有の技術的論点
(1) 標準機能への適合（Fit & Gap）の失敗要因
本件はSalesforceというPaaS（Platform as a Service）を採用していながら，スクラッチ開発のような泥沼に陥りました。Salesforce認定テクニカルアーキテクトの視点で見ると，これは「Fit & Gap」の失敗に他なりません。
Salesforceには強力な標準機能がある反面，マルチテナント環境における「ガバナンス制限（Governor Limits）」等の厳しい制約が存在します。ユーザーの既存業務（特に複雑な融資計算や日本独自の帳票）をそのままSalesforceに乗せようとすれば，無理なカスタマイズ（ApexコードやVisualforceの多用）が必要となり，保守性が低下し，不具合が多発します。
「業務をシステムに合わせる（Fit to Standard）」というPaaS導入の大原則が，ユーザー・ベンダー間で共有されていなかったことが，技術的な敗因の一つです。
また，Ｃ方式といった複雑な計算ロジックについて，ユーザーが詳細設計段階で検討を求めたこと自体が遅延要因となりました。
なお，最終的には実装しないこととし（先送りし），コード値の割り当てのみで対応することとされました。
(2) 成果物の流用可能性に関する技術的評価の妥当性
裁判所は，要件定義書等の成果物について，Salesforce以外のシステムでも流用可能と判断しました。
これは技術的に妥当です。業務要件定義書や概念データモデル（ER図）は，特定の製品に依存しない「業務の論理構造」を記述したものであり，知的資産としての価値があります。ユーザーが「Salesforce前提だからゴミだ」と主張したのを退けた点は，ＩＴ資産の価値評価として適正です。
実際にユーザーはその後，Salesforce以外の基盤で再構築を行っていますが，その際にも本件で整理された業務要件は必ず参照されたはずです。
３ データ移行と「不整合データ」の実務的課題
(1) データクレンジングの責任分界点と契約実務
本件では，旧システムのデータに不整合（Dirty Data）が多く含まれており，その修正作業が遅延の原因となりました。
一般に，データの品質責任（Data Ownership）はユーザーにあるとされることが多いです。しかし，本件では，ベンダーが入札時の提案書において「例外データ等は協議の上対応する」（ベンダーが主体的に実施する）と提案としていたこと等から，ユーザーが不整合データを修正せずに提供したことについての契約違反（協力義務違反）は否定されました。
すなわち，契約書そのものの記述だけでなく，入札段階での「提案書」の記載内容が，後の責任分界点（どちらが汗をかくべきか）の決定的な根拠となったのです。
もっとも，大量の不整合データ（Dirty Data）の存在自体は，ベンダーの作業遅延を正当化する事情（過失相殺の要素）として考慮されました。実務的には，契約時に「データクレンジングはユーザー責任」と明記しておくことが，紛争予防の観点から極めて重要です。
(2) レガシーマイグレーションにおける泥沼化の防止
長年運用されたレガシーシステムには，必ずと言っていいほど仕様書にないデータや矛盾したデータが存在します。これを軽視して「ツールで自動移行できる」と過信したことが，ベンダーの見積もり甘さにつながりました。
システム監査人は，移行計画の監査において，事前のデータ調査（プロファイリング）が十分に行われているかを厳しくチェックする必要があります。ETL（Extract, Transform, Load）プロセスにおいて，エラーデータのハンドリングをどうするか（スキップするか，手動修正するか）のルールを事前に決めておかなければ，本件のように移行リハーサルで毎回止まることになります。
第５ AI特定社会保険労務士としての労務的考察
１ プロジェクト現場におけるハラスメントの法的評価
(1) 協力義務違反を構成するハラスメントの閾値
労務の専門家として，本判決がハラスメントを「契約違反」と認定したことのインパクトは計り知れません。
従来，ハラスメントは不法行為（民法７０９条）として個人の責任が問われることが主でしたが，本判決はこれをこれを「協力義務違反」という企業間の契約（民法４１５条等）の問題へと昇華させました。
ここで重要なのは，「相手の業務遂行を阻害するレベル」か否かという閾値です。単に厳しい口調であるだけでなく，人格否定や，不可能な要求の繰り返しによって，ＳＥ（システムエンジニア）のメンタルヘルスを悪化させ，パフォーマンスを低下させたという「実害」との因果関係が認定のポイントとなりました。
(2) 「能力不足」発言等の違法性と現場への影響
「お前の会社の社員は能力がない」といった発言は，指揮命令権のない発注者が言ってはならない一線を越えています。これは偽装請負の文脈でも問題視される「業務への不当介入」に近い性質を持ちます。
また，このような発言が常態化する現場は，労働安全衛生法上の「快適な職場環境」とは対極にあり，ベンダー企業としては社員を守るために何らかのアクションを起こさざるを得なくなります。本件では，実際に社員の離脱や退職が発生しており，企業の安全配慮義務の観点からも看過できない状況でした。
２ 安全配慮義務の所在と「職場放棄」の法的評価
(1) 指揮命令関係の不在と安全配慮義務の否定
本判決において，ベンダーは「ユーザーは安全配慮義務を負う」と主張しましたが，裁判所は，両社間に指揮命令関係がないことを理由に，ユーザーの安全配慮義務を明確に否定しました。
また，ベンダーが行った現場からの撤退（引き揚げ）についても，「社員を守るため」という主張は認められず，法的には「履行停止を正当化するものではない」として，債務不履行（履行遅滞）と認定されました。 労務管理上の判断であったとしても，契約法上は「職場放棄」とみなされるリスクが現実化したといえます。
実務的には，いきなり撤退するのではなく，まずはハラスメント禁止条項に基づく是正要求，担当者変更要求，そして契約解除の予告といった法的手続きを段階的に踏む必要がありました。「実力行使」は，法的リスクが極めて高いことを銘記すべきです。
(2) メンタルヘルス不調と損害賠償請求の可否
本判決では，ベンダーの反訴において，安全配慮義務違反に基づく損害賠償（慰謝料等）は棄却されました。
しかし，ハラスメント言動が「協力義務違反」の一要素を構成すると認定され，結果として追加作業にかかった人件費相当額の賠償が認められました。
これは，ハラスメントが「不法行為（慰謝料）」としてではなく，「契約違反（実損害）」としてペナルティを受けたことを意味します。
法人としてのベンダーが受けた損害（作業効率低下によるコスト増）は認められやすいですが，従業員個人の精神的苦痛を法人が代位して請求するのはハードルが高いと言えます。
第６ 弁護士としての実務への提言
１ 契約書作成および交渉における具体的留意点
(1) 協力義務の具体化と免責条項の設計
「甲は乙に協力する」という定型的な条項だけでは不十分です。本判決の教訓を活かすなら，以下の条項を検討すべきです。
承認の擬制：「要件定義書等の成果物提出後，〇営業日以内に書面による異議がなければ，承認されたものとみなす」
仕様変更の定義：「承認後の仕様変更は，原則として有償とし，納期および費用の再見積もりを行う」
不具合指摘の期限：「受入テストにおける不具合指摘は，テスト期間終了後〇日以内に行うものとする」
遅延の免責：「ユーザー事由による遅延（承認遅れ，データ不備，ハラスメント等）が生じた場合，納期は自動的に延長され，ベンダーは履行遅滞責任を負わない」
(2) ハラスメント対応条項の導入と運用
本判決を受けて，システム開発契約書には「ハラスメント禁止条項」を標準装備すべきです。
ハラスメントの定義：改正労働施策総合推進法（パワハラ防止法）の定義に準拠し，優越的言動，業務上の必要性・相当性の逸脱，就業環境の阻害を要件とする。
対応プロセス：ハラスメント発生時の通報窓口設置，事実調査への協力義務。
- サンクション：ハラスメントが認定された場合の担当者交代義務，改善されない場合の契約解除権または作業中断権の明記。これらを明記することで，ベンダーは「撤退」という実力行使ではなく，契約に基づく権利行使として身を守ることが可能になります。
２ 紛争予防のためのプロジェクト法務の在り方
(1) 議事録とエビデンスによる自己防衛の重要性
本件において，詳細設計未完了後の仕様変更認定の決め手となったのは，会議の議事録や報告書でした。
「言った言わない」の水掛け論を防ぐため，会議の決定事項，保留事項，誰がボールを持っているか（Action Item）を記録し，相手方の確認を取るプロセスを徹底すべきです。特に，仕様変更の指示があった場合は，「これは仕様変更であり，追加費用と納期延長が必要です」とメール一本でも良いので記録を残すことが，後の裁判での命綱となります。
また，ハラスメントについても，いつ，どこで，誰が，どのような発言をしたかの記録（メモや録音）が，協力義務違反の立証において決定的な役割を果たしました。
(2) チェンジマネジメント（変更管理）の徹底と法務の介入
プロジェクトマネージャー（ＰＭ）は，顧客との関係悪化を恐れて，無理な要求を呑んでしまいがちです。ここで法務部門や外部弁護士が介入し，「契約外の要求については，所定の変更管理プロセスを経て見積もりを出します」とドライに対応する体制を構築することが重要です。
法務は契約締結時だけでなく，プロジェクト進行中もＰＭを支援し，リスクの芽を摘む「ガーディアン」としての役割を果たすべきです。
第７ 結語
東京高裁令和７年９月２５日判決は，システム開発プロジェクトの失敗が，技術，契約，人間関係の複合的な要因によって引き起こされることを鮮明に描き出しました。
ベンダーにはプロとしてのＰＭ能力と完遂責任が，ユーザーには当事者としての主体的な協力とパートナーへのリスペクトが求められます。
本判決が示した「ベンダー６：ユーザー４」という数字は，どちらか一方が悪いのではなく，双方が共に汗をかき，共にリスクを背負ってプロジェクトを成功させる運命共同体であるべきだという，司法からの強いメッセージと受け止めるべきでしょう。
本記事が，現在苦境にあるプロジェクトの正常化や，将来の紛争予防の一助となれば幸いです。