結論

検収後の紛争(このシステムは使い物にならない、いや仕様どおりだ)で発注側が負ける典型パターンは、主張の中身ではなく証跡の欠落です。要件がどこで合意されたか特定できない、検収で何を確認したか記録がない、不具合の再現手順と業務影響を示せない、協議の経緯が口頭で消えている、の4つが揃うと、法的には正しい主張でも立証できません。紛争証跡ワークフローとは、紛争が起きてから慌てて証拠を集めるのではなく、プロジェクトの各フェーズで「後日争いになったらこれが要る」という文書を型どおり残していく平時の運用のことです。

紛争で問われる4つの立証点

検収後クレームの多くは、契約不適合責任(通知期間内か)、性能不満(合意した性能基準は何か)、追加費用(合意した範囲はどこまでか)のいずれかに帰着します。どの類型でも、立証の骨格は同じ4点です。

AI開発では特に「性能の合意」の立証が難所です。精度目標が努力目標(SLO)だったのか合格基準だったのか、評価データセットは何だったのかが文書で特定できないと、性能不満のクレームは根拠を失います。逆に、固定評価データセットと検収時の評価結果が残っていれば、劣化の立証は比較的容易です。

フェーズ別の証跡ワークフロー

平時のワークフローは、各フェーズの既存文書に「紛争でも使える形式」の要件を足すだけで構築できます。契約フェーズでは、契約書と別紙(成果物明細、性能基準、前提条件)の最終版を電子署名または双方押印で確定し、メールでの「では、この内容で」という合意も含めて保管場所を一元化します。開発フェーズでは、変更管理台帳と週次議事録を双方確認の運用にし、口頭合意の当日中の書面化を徹底します。検収フェーズでは、テスト結果と残課題リスト、条件付き検収の場合の条件を検収書に添付します。運用フェーズでは、不具合の発生記録(日時、事象、ログ、業務影響)と通知の送達記録を残します。

このワークフローの大半は、健全なプロジェクト管理の文書とそのまま重なります。紛争準備のための特別な作業はほとんどなく、必要なのは「双方確認」と「版の確定」という形式面の規律です。

クレーム発生時の初動

実際に対立が表面化したら、初動で次を行います。第一に、証跡の凍結: 関連するメール、チケット、ログ、チャット履歴の削除・改変を止め、時系列表(いつ何が起きたか)を作成します。第二に、通知の書面化: 契約不適合の主張には通知期間があるため、事象を特定した書面(内容証明である必要はまだない)を期間内に送ります。第三に、要求の特定: 追完(修正)、減額、損害賠償、解除のどれを求めるのかを社内で決めます。感情的な「誠意を見せろ」型の交渉は、記録上も不利に働きます。

交渉段階では、協議の議事録を毎回残し、相手の回答期限を切ります。解決しない場合の選択肢として、ソフトウェア紛争の専門的なADR(裁判外紛争解決)があり、IPAが公表するモデル取引・契約書でも紛争解決条項の設計が扱われています。契約の紛争解決条項(協議→調停→仲裁または訴訟、管轄)を確認し、エスカレーションの費用と期間を見積もった上で、ビジネス判断として落とし所を決めます。

反対側の視点: 発注側の義務違反を作らない

紛争証跡は、発注側自身の行動も記録します。システム開発の裁判例では、ベンダーのプロジェクトマネジメント義務と並んで、発注側の協力義務(要件の確定、データ・環境の提供、意思決定の遅延)が争点になります。データ提供の遅れ、レビューの放置、担当者の頻繁な交代といった発注側起因の事象は、相手の反論材料になるため、自社のタスク遅延も台帳上は正直に記録し、遅延時の合意(スケジュール調整の覚書)を残すことが、結果的に自社を守ります。

記録の保管と体制

証跡の保管期間は、契約不適合の通知期間と時効を考慮して、検収後最低5年(できれば10年)を目安にします。プロジェクト終了時に、契約書類・議事録・検収記録・台帳類を1つのアーカイブにまとめる「クローズ処理」を型にすると、数年後に担当者が異動していても証跡が引き出せます。紛争の兆候(支払い留保の検討、ベンダーの窓口が営業から管理職に変わる等)を感じた時点で、法務・外部弁護士へ早期相談することも、初動の質を大きく変えます。

実務チェックリスト

• 契約・別紙・変更覚書の最終版を双方確定で一元保管しているか
• 性能基準と評価データセットが文書で特定できるか
• 検収書にテスト結果と残課題リストを添付したか
• 不具合の再現手順・ログ・業務影響を定量記録しているか
• 契約不適合の通知期間を把握し、通知の送達記録を残しているか
• 口頭合意の当日書面化と議事録の双方確認を運用しているか
• 発注側タスクの遅延と調整合意も記録しているか
• プロジェクト終了時のアーカイブ化(5-10年保管)を行ったか

図解で確認するポイント

この記事の画像は、プロジェクトの各段階で生まれた記録が時系列に束ねられ、協議の場へ提出される流れを文字なしで図解しています。紛争対応力が事後の弁論ではなく平時の記録から生まれることを示しています。

AllAI内での次の行動

検収段階の記録は受入テスト不合格時の是正期限ポリシー設計、担保責任の切り分けは保守開始前の欠陥担保確認、振り返りの型はポストモーテムテンプレートが関連します。紛争リスクの低い発注は要件の質から始まるため、AI発注診断で要件を構造化し、AI開発パートナーで契約実務のしっかりした会社を選んでください。

FAQ

Q. チャットツールでのやり取りは証拠になりますか? A. なります。ただし編集・削除が可能なツールでは、重要な合意はエクスポートして保全し、正式な合意は覚書・議事録へ昇格させる運用が安全です。「チャットで言った」だけの合意は、文脈の切り取りをめぐって争いになりがちです。

Q. 紛争になりそうな時、支払いを止めてよいですか? A. 一方的な支払い留保は、自社側の債務不履行を構成するリスクがあります。同時履行の抗弁が成立する場面かは契約構造によるため、留保の前に必ず法務・弁護士へ相談してください。減額を求めるなら、契約不適合の手続きに乗せるのが筋です。

Q. ベンダーが証跡(ログ、チケット)を出してくれません。 A. 契約に監査権・資料提出義務があれば、それを根拠に書面で請求します。訴訟になれば文書提出命令の制度もありますが、平時から「運用記録の写しは発注側にも保管される」構成(チケットシステムへの発注側アカウント、月次レポートの添付資料)にしておくことが根本対策です。

Q. 小さな不満の段階から紛争準備をするのは大げさでは? A. このワークフローは紛争専用ではなく、良好な取引の管理記録と9割が共通です。記録がしっかりしている発注者にはベンダーも誠実に対応するため、証跡運用はむしろ紛争の発生自体を減らします。

出典と確認日

• 法務省「民法(債権関係)改正」: https://www.moj.go.jp/MINJI/minji06_001070000.html (確認日: 2026-07-10)
• IPA「情報システム・モデル取引・契約書」: https://www.ipa.go.jp/digital/model/index.html (確認日: 2026-07-10)
• 経済産業省「AI・データの利用に関する契約ガイドライン」: https://www.meti.go.jp/press/2018/06/20180615001/20180615001.html (確認日: 2026-07-10)
• 法務省「かいけつサポート(認証ADR)」: https://www.moj.go.jp/KANBOU/ADR/index.html (確認日: 2026-07-10)