ベンダーから届いたシステム開発委託契約書のドラフトを読み進めていたら、「表明及び保証」という見慣れない条項に行き当たった。過去の契約書には同じ条項がなく、社内に前例もない。しかも読んでみると、ベンダーだけでなく自社（発注者）も何かを保証する側として書かれている——このような状況で、この記事にたどり着いた方が多いのではないでしょうか。
そこで「表明保証とは」と検索してみると、上位に並ぶのはM&Aの解説記事ばかりです。株式譲渡契約、デューデリジェンス、売り主と買い主、キャップ条項とバスケット条項。どれも丁寧に書かれてはいるのですが、目の前にある開発委託契約書とは前提が違いすぎて、自社のケースに翻訳できません。社内に専任の法務担当がいない場合、そもそも「何を論点として立てればいいのか」の段階でつまずいてしまいます。
しかし、表明保証という仕組み自体は、契約類型が変わっても構造は同じです。「誰が」「いつの時点の」「どんな事実を」保証し、「それが真実でなかったときにどうなるのか」——この4つを押さえてしまえば、M&A契約の解説で語られている考え方は、そのままシステム開発契約にも適用できます。逆にいえば、この翻訳ルールを知らないまま条項を読んでも、どこを直すべきかは見えてきません。
本記事では、システム開発契約における表明保証の意味と役割、既にある契約不適合責任・知的財産権侵害責任との違い、発注者がベンダーに保証させるべき項目、逆に自社が保証を求められたときに飲んでよい範囲、違反時に実際どこまで救済されるのか、そして「知る限り」「重要な点において」といった限定表現の読み方までを整理します。最後に、契約ドラフトを受け取ってから修正依頼を出すまでの確認手順を5ステップにまとめました。読み終えたときに、手元の契約書に赤を入れられる状態になることを目指しています。
システム開発における基本契約書の雛形
この資料でわかること
システム開発を依頼する際にシステム開発会社と締結する基本契約書の雛形をご紹介します。
こんな方におすすめです
- システム開発を発注する際にどのような基本契約を結ぶのか興味がある
- システム開発会社がきちんと契約の取り交わしをしてくれるのか不安
- システム開発を発注する側にどのような義務が生ずるのか気になる
入力いただいたメールアドレスにPDFをお送りします。
表明保証とは？システム開発契約での意味と役割
まず、表明保証という言葉が指しているものを正確に押さえます。ここを曖昧にしたまま個別の条項を読み始めると、後のセクションで扱う「既存条項との違い」が理解できなくなります。
表明保証とは「一定時点の事実が真実かつ正確である」と保証すること
表明保証（representations and warranties、実務では「レプワラ」とも呼ばれます）とは、契約の当事者が、一定の時点における一定の事実が真実かつ正確であることを相手方に対して表明し、保証する契約条項です。
ここで決定的に重要なのは、表明保証の対象が「事実」であって「債務」ではないという点です。契約書に並んでいる他の条項の多くは、「〜しなければならない」「〜を納入する」といった、これから当事者が果たすべき義務を定めています。一方で表明保証は、「〜である」「〜は存在しない」という、すでにそうなっているはずの状態を保証します。
たとえばシステム開発契約であれば、次のような書き分けになります。
- 義務（債務）の条項: 「乙は、第三者の権利を侵害しないように本件成果物を制作するものとする」
- 表明保証の条項: 「乙は、本契約締結日において、本件成果物が第三者の知的財産権を侵害しないことを表明し、保証する」
一見すると同じことを言っているようですが、違いは「相手の落ち度を問う必要があるか」という点に現れます。義務違反（債務不履行）を主張する場合、相手方が果たすべき義務を果たさなかったことを示す必要があり、帰責事由が争点になり得ます。これに対して表明保証違反は、保証された事実が客観的に真実でなかった時点で成立します。ベンダーがどれだけ注意を払っていたか、知っていたか知らなかったかは、原則として問いません（後述するように「知る限り」といった限定が付くと話は変わります）。
この「無過失でも責任が発生し得る」という性質こそが、表明保証をわざわざ契約書に入れる実務的な意味です。発注者から見れば、事故が起きたときに「ベンダーに落ち度があったか」を立証する負担を負わずに済むことになります。
M&A契約の解説が多い理由と、システム開発契約での位置づけ
「表明保証」で検索するとM&Aの記事ばかり出てくるのには、はっきりした理由があります。表明保証は、英米法の契約実務から日本に持ち込まれた概念であり、日本ではまずM&A（株式譲渡・事業譲渡）の分野で定着したためです。
M&Aでは、買い手が売り手の会社の内情をすべて調べ尽くすことはできません。デューデリジェンス（買収監査）には時間もコストも限界があり、簿外債務や係争案件が隠れている可能性を完全には排除できません。そこで「調べきれない部分については、売り手が『そのような問題はない』と保証し、後で嘘だと判明したら補償する」という仕組みが必要になりました。表明保証は、情報の非対称性を埋め、調査しきれないリスクを相手方に引き受けさせるための道具なのです。
この構造を、システム開発契約に置き換えてみてください。発注者は、ベンダーが納品してくるソースコードの中身を1行ずつ検証することはできません。使われているOSS（オープンソースソフトウェア）のライセンス条件をすべて洗い出すことも、生成AIがどの程度コーディングに使われたかを事後に把握することも、現実的には困難です。再委託先の労務管理状況にいたっては、発注者から見えるはずもありません。
つまり、システム開発契約はM&Aと同じく情報の非対称性が大きい取引であり、表明保証が機能する土壌がそもそも整っています。M&Aの解説記事を読むことは無駄ではなく、「売り手＝情報を持っている側＝ベンダー」「買い手＝調べきれない側＝発注者」と読み替えれば、考え方の骨格はそのまま使えます。
ただし、保証させるべき「事実」の中身はまったく異なります。M&Aの表明保証事項が財務諸表の正確性や簿外債務の不存在であるのに対し、システム開発契約では成果物の権利関係、データの取扱い、再委託体制などが中心になります。この中身の翻訳が、本記事の後半で扱う内容です。
表明保証条項が置かれる場所（基本契約・個別契約・NDA・保守契約）
自社の契約書のどこに表明保証が書かれているかを把握しておくことも、意外と重要です。システム開発の取引は複数の契約書に分かれていることが多く、表明保証条項も分散して置かれます。
契約書 | 置かれやすい表明保証事項 |
|---|---|
基本契約書 | 契約締結権限、許認可の保有、反社会的勢力の排除、法令遵守、財務状態、係争の不存在 |
個別契約書（発注書・仕様書に紐づく） | 個別案件の成果物に関する第三者権利非侵害、納入物に含まれるOSSの適法性、支給資料の正確性 |
秘密保持契約書（NDA） | 開示情報について正当な開示権限を有していること、第三者の秘密保持義務に違反しないこと |
保守・運用契約書 | 保守対象システムに関する情報の正確性、作業者の資格・体制 |
複数の契約書にまたがって書かれている場合、基本契約と個別契約で表明保証の内容が食い違っていないか、そしてどちらが優先するか（優先関係条項）がどう定められているかを確認してください。基本契約で広く保証させているつもりが、個別契約の特約で実質的に骨抜きにされているケースもあります。
なお、システム開発契約全体でどの条項を確認すべきかについては、システム開発の契約書｜発注者が確認すべき7条項とAI特有条項で整理しています。本記事はそのうち「表明及び保証」条項だけを深掘りする位置づけです。
表明保証と契約不適合責任・知的財産権侵害責任の違い
契約ドラフトを読み込んでいる方が最初に抱く疑問は、おそらく「これ、他の条項と重複していないか？」でしょう。契約書にはすでに契約不適合責任の条項があり、知的財産権侵害の責任条項もある。その上で表明保証まで入れる意味はどこにあるのか——ここを整理しておくと、条項の取捨選択がぐっと楽になります。
契約不適合責任との違い（対象・基準時・救済手段）
契約不適合責任は、2020年4月施行の改正民法で、従来の瑕疵担保責任に代わって導入された制度です。引き渡された目的物が種類・品質・数量に関して契約の内容に適合しない場合に、買主（発注者）が追完請求・代金減額請求・損害賠償請求・契約解除をできるとするものです（民法第562条以下、e-Gov法令検索）。
表明保証と契約不適合責任は、次の4つの軸で性質が異なります。
比較軸 | 表明保証 | 契約不適合責任 |
|---|---|---|
対象 | 一定時点の事実（成果物が第三者の権利を侵害していないこと、など） | 引き渡された目的物が契約内容に適合しているか（仕様・品質） |
基準時 | 契約で定めた時点（契約締結日・納品日・検収日など、当事者が設計する） | 原則として引渡し時 |
主張に必要なこと | 保証された事実が真実でなかったこと（原則として相手の帰責事由は不要） | 目的物が契約内容に適合しないこと |
期間制限 | 契約で定めた請求期間（定めがなければ一般の消滅時効） | 不適合を知った時から1年以内の通知が必要（民法第566条） |
救済手段 | 損害賠償・補償請求、解除（契約の定めによる） | 追完請求・代金減額請求・損害賠償・解除 |
実務上の使い分けとして押さえておきたいのは、契約不適合責任は「仕様どおりに動くか」を守る制度であり、表明保証は「仕様とは別次元の前提事実」を守る制度だという点です。
たとえば、納品されたシステムが仕様どおり完璧に動作していても、その中に使われているライブラリのライセンス条件に違反していれば、それは「契約不適合」とは言いにくい一方で、「第三者の権利を侵害していない」という表明保証には明確に違反します。逆に、権利関係はクリアだが仕様どおりに動かない場合は、契約不適合責任の出番です。両者は重複ではなく、カバー範囲が異なる補完関係にあります。
また、契約不適合責任には「不適合を知った時から1年以内の通知」という期間制限があります。OSSライセンス違反や権利侵害は、リリースから数年後に権利者から警告を受けて初めて発覚することも珍しくありません。表明保証条項で独立した請求期間を設計しておけば、この時間軸のずれをカバーできます。
契約不適合責任そのものの詳細は瑕疵担保責任・契約不適合責任とは｜システム開発での違いと発注者の対処法で解説しています。
知的財産権侵害の責任条項との重複と使い分け
システム開発契約には、たいてい「知的財産権侵害の責任」という独立した条項が置かれています。IPA（独立行政法人情報処理推進機構）が公開している情報システム・モデル取引・契約書にも、第三者の知的財産権侵害に関する責任分担を定めた条項が含まれており、多くのベンダーがこれを下敷きに自社の契約書を作成しています。
では、知的財産権侵害の責任条項があるのに、表明保証で同じことを保証させる意味はあるのでしょうか。実務的な違いは主に次の2点です。
1. 責任が発生する条件の違い
モデル契約をベースにした知財侵害責任条項は、しばしば「ベンダーの責めに帰すべき事由により第三者との間に紛争が生じた場合」といった形で、帰責事由を要件にしていることがあります。この場合、発注者は「ベンダーに落ち度があった」ことを主張する必要が出てきます。一方、表明保証は事実が真実でなければ違反が成立するため、この立証負担が軽くなります。
2. 発動のタイミングの違い
知財侵害責任条項の多くは、「第三者から請求を受けた場合」に、ベンダーが防御・解決・費用負担を行うという紛争対応の枠組みとして書かれています。これに対し表明保証は、紛争が起きる前でも、事実と異なることが判明した時点で違反を主張できます。たとえば、納品後の内部監査でGPLライセンスのコードが混入していると分かったが、まだ権利者からの請求は受けていない——このような段階で、改修費用を誰が負担するかを議論する根拠になります。
つまり、知財侵害責任条項は「事故が起きた後の対応ルール」、表明保証は「そもそも事故要因が存在しないという前提の確認」です。両方を残すのが発注者にとっては安全側の設計になります。
損害賠償の上限条項との関係
表明保証を契約書に入れるかどうかを議論する際、実は最も影響が大きいのが損害賠償の上限（キャップ）条項との関係です。ここを見落とすと、条項は入っているのに実際には機能しない、という事態になりかねません。
システム開発契約では、「乙の損害賠償責任は、本個別契約に定める委託料の総額を上限とする」といった責任制限条項が置かれるのが一般的です。これ自体はベンダー側のリスクコントロールとして合理性のあるもので、全面的な削除を求めるのは現実的ではありません。
問題は、表明保証違反に基づく請求がこの上限の内側に入るのか、外側に置かれるのかです。
たとえば、権利侵害が発覚してシステム全体の作り直しが必要になった場合、損害額が委託料を大きく超えることは十分あり得ます。開発費1,000万円のシステムで、ライセンス違反により差止請求を受け、代替実装と業務停止による損失が数千万円に及ぶ、といったケースです。このとき賠償上限が委託料総額に張り付いていれば、回収できるのは1,000万円までとなります。
そのため実務では、次のような設計を検討します。
「前項の責任の上限は、乙が第○条（表明及び保証）に違反した場合、および乙の故意または重大な過失による場合には適用しないものとする。」
M&A実務でも、責任限度額の設定と併せて、特定の重要な表明保証違反については上限の適用除外を交渉することが行われています。システム開発契約でも、すべての表明保証事項を上限の外に出すのは交渉が難航しやすいため、第三者権利非侵害・個人情報の適法取扱いなど、事故が起きたときの損害が青天井になりやすい項目に絞って例外扱いを求めるのが現実的です。
損害賠償条項全体の読み方についてはシステム開発の損害賠償・リスク管理ガイド｜契約書の読み方と発注者のトラブル対処フローも併せてご覧ください。
発注者がベンダーに表明保証させるべき項目
ここからは、発注者が「保証させる側」に立つときの具体的な確認項目を見ていきます。単に項目を並べても契約書には落とし込めないため、それぞれ「なぜ必要か（どんな事故を想定しているか）」から始めて、条項に入れる文言の方向性まで示します。
なお、以下に示す条項例はあくまで一般的な文言の方向性であり、個別の案件でそのまま使えることを保証するものではありません。実際の契約書に反映する際は、後述する社内判断／弁護士相談の線引きを参考にしてください。
成果物が第三者の権利を侵害しないこと（OSSライセンス含む）
想定される事故: 納品されたソースコードに、コピーレフト型のライセンス（GPL等）が適用されるOSSが組み込まれており、自社システムのソースコード開示義務が発生してしまう。あるいは、他社製品からの流用コードが混入しており、著作権侵害を主張される。
現代のシステム開発でOSSをまったく使わないことはあり得ません。問題は「使っているかどうか」ではなく、「どのライセンスのものを、どのような使い方で組み込んでいるか」です。MITライセンスやApache License 2.0のような寛容型ライセンスであれば影響は限定的ですが、GPLのようなコピーレフト型では、組み込み方によって自社の独自コードまで開示対象になる可能性があります。
発注者から見ると、この判定は納品後のソースコードを専門的に監査しない限り不可能です。だからこそ表明保証の対象として最優先で押さえるべき項目になります。
条項に入れる文言の方向性としては、以下の3点を分けて書くことが実務的です。
「乙は、本件成果物が第三者の著作権、特許権、商標権その他一切の知的財産権を侵害しないことを表明し、保証する。」 「乙は、本件成果物に組み込まれたオープンソースソフトウェアの名称、バージョンおよび適用ライセンスの一覧を甲に書面により提示するものとし、当該一覧が正確かつ網羅的であることを表明し、保証する。」 「乙は、本件成果物に、甲の事前の書面による承諾なく、コピーレフト条項を含むライセンスが適用されるソフトウェアを、本件成果物のソースコード開示義務が生じる態様で組み込んでいないことを表明し、保証する。」
一覧の提示義務とセットで保証させるのがポイントです。「侵害していない」という抽象的な保証だけでは、違反があったときに何が違反なのかを特定する作業が発注者側の負担になります。OSS一覧（SBOM: ソフトウェア部品表に相当するもの）を成果物の一部として納品させ、その正確性を保証させれば、検証可能性が一気に上がります。
生成AI・学習データに起因する権利侵害がないこと
想定される事故: 開発中にコーディング支援AIが使われ、学習データ由来のコードがほぼそのまま出力されて成果物に取り込まれていた。後日、元コードの権利者から権利主張を受ける。あるいは、AI機能を組み込んだシステムで、学習に使ったデータの権利処理が済んでおらず、サービス公開後に問題化する。
生成AIによるコーディング支援は開発現場で広く使われるようになりましたが、契約書のテンプレートがこの変化に追いついていないのが実情です。数年前に作られた契約書の雛形をそのまま使っている場合、生成AIに関する条項は存在しない可能性が高いといえます。
経済産業省の「AI・データの利用に関する契約ガイドライン」でも、データの提供・利用にあたって、知的財産権の非侵害やパーソナルデータの適法性について表明保証条項を活用し、責任範囲を契約で明確にすることが望ましいと整理されています（出典: 経済産業省「AI・データの利用に関する契約ガイドライン」1.1版、2019年）。
発注者として押さえておきたいのは、次の2つの論点です。
開発プロセスにおける生成AIの利用
生成AIの利用を一律に禁止する条項は、開発効率を落とすうえに実効的な確認手段もないため、現実的とはいえません。代わりに、利用の事実を開示させ、権利処理の責任を明確にする方向で設計します。
「乙は、本件成果物の制作過程において生成AIを利用する場合、事前に甲に通知するものとし、生成AIの出力に起因して第三者の権利を侵害しないことを表明し、保証する。」
納品物に組み込まれるAI機能・学習データ
AI機能そのものを開発対象に含む場合は、学習データの取得経路とライセンス条件が争点になります。
「乙は、本件成果物に含まれる学習済みモデルの学習に用いたデータについて、適法に取得し、本件における利用について必要な権利処理を完了していることを表明し、保証する。」
生成AIをめぐる法解釈は今後も動く可能性が高い領域です。だからこそ、「現時点の法解釈で問題ない」ではなく「事実として何をしたか」を保証させる形にしておくと、後から状況が変わっても事実関係の確認から議論を始められます。
個人情報・データを適法に取得・取り扱っていること
想定される事故: 移行作業や検証環境の構築のために、ベンダーが本番相当の個人データを取り扱う。その過程で安全管理措置が不十分だったことが後から判明する。あるいは、ベンダーが再委託先の海外拠点にデータを渡していた。
個人情報保護法では、個人データの取扱いを委託する場合、委託元には委託先に対する必要かつ適切な監督義務があるとされています（個人情報保護委員会「法令・ガイドライン等」）。つまり、ベンダーが問題を起こしたとしても、発注者側の監督責任が問われる構造になっています。
契約上の秘密保持条項や個人情報取扱条項で義務を課すのは当然として、表明保証としては「現に適法な状態である」ことを保証させる意味があります。
「乙は、本契約に基づき甲から提供を受ける個人データについて、個人情報の保護に関する法律その他関係法令および甲の指示に従って取り扱っていること、ならびに必要な安全管理措置を講じていることを表明し、保証する。」
保証させる範囲を検討する際は、データが物理的にどこに置かれるか（保管場所・利用するクラウドのリージョン）、誰がアクセスできるか（再委託先・海外拠点を含むか）の2点を条項に落とし込めているかを確認してください。ここが曖昧なままだと、違反があったときに「その取扱いは想定内だった」という主張の余地を残してしまいます。
再委託先の管理と労務コンプライアンス
想定される事故: 契約上は再委託が禁止されているのに、実際には別会社の技術者が作業に入っていた。あるいは、実態としては労働者派遣に該当する働き方になっており、偽装請負を指摘される。
システム開発では多重下請け構造が珍しくなく、発注者が把握しているベンダーの先に、複数の協力会社が連なっているケースは日常的にあります。ここでの問題は、発注者が「誰が作っているのか」を把握できないまま検収を迎えてしまうことです。
「乙は、本契約締結日において、本件業務に従事する要員の所属および再委託の有無を甲に開示した内容が正確であることを表明し、保証する。」 「乙は、本件業務の遂行にあたり、労働関係法令を遵守していること、および本件業務が労働者派遣事業の適正な運営の確保及び派遣労働者の保護等に関する法律に違反する態様で行われていないことを表明し、保証する。」
労務コンプライアンスに関する保証は、ベンダー側が難色を示しやすい項目です。交渉が難航する場合は、保証させる範囲を「本件業務に関して」に限定する（会社全体の法令遵守までは求めない）ことで、着地点が見つかることがあります。
契約締結権限・許認可・反社会的勢力の排除
これらは基本契約書に定型的に入っていることが多い項目です。すでに書かれている場合、あらためて追加を求める必要は通常ありません。
- 契約締結権限: 契約を締結する権限を有し、社内で必要な手続を完了していること
- 許認可: 業務遂行に必要な許認可・登録を有していること（労働者派遣事業許可など、業態により該当）
- 反社会的勢力の排除: 自社および役員等が反社会的勢力に該当せず、関係を有していないこと
- 係争の不存在: 本契約の履行に重大な影響を及ぼす訴訟・紛争が存在しないこと
これらが記載されていない場合は追加を依頼しますが、優先度としては前述の4項目より低いと考えてよいでしょう。限られた交渉機会をどこに使うかという観点では、成果物の権利関係とデータの取扱いを優先すべきです。
発注者側が求められる表明保証と、飲んでよい範囲の見極め方
ここまでは発注者が「保証させる側」に立つ場面を扱ってきました。しかしシステム開発契約における表明保証条項は、多くの場合、双方向に書かれています。つまり発注者も「保証する側」になります。
M&Aの解説記事が売り主／買い主で役割を分けて説明しているのに対し、システム開発契約では同じ当事者が両方の立場を同時に持つという点が、読解を難しくしています。契約書を読むときは、その条項がどちらの立場のものかを常に意識してください。
発注者が保証を求められる典型項目（支給資料・既存システム情報の正確性）
発注者が保証を求められるのは、主に自社が提供する情報や素材に関する事項です。
保証を求められる典型項目 | ベンダー側の意図 |
|---|---|
支給資料・要件定義書の記載内容が正確であること | 誤った前提で設計・実装した場合の責任を回避したい |
既存システムの仕様書・設計書が最新かつ正確であること | 連携先の仕様が違っていた場合の手戻り責任を回避したい |
移行元データの内容・形式が提示したとおりであること | データ移行の想定工数が崩れるリスクを回避したい |
提供する素材（画像・フォント・ロゴ等）について必要な権利を有すること | 発注者由来の権利侵害の責任を負いたくない |
業務要件が関係法令に適合していること | 違法なシステムを作らされるリスクを回避したい |
これらの要求自体は、必ずしも不当ではありません。ベンダーから見れば、発注者しか知り得ない情報について責任を負わされるのは理不尽だからです。問題は、保証の範囲が「自社が現実に検証できる事実」を超えていないかという点にあります。
判断の軸はシンプルです。
この事実が真実かどうかを、自社が合理的な手間で確認できるか。
確認できるなら、保証しても大きなリスクはありません。確認できないなら、その保証は「事実上、無限定の賠償責任を引き受ける」ことと同義になります。
たとえば「既存システムの仕様書が正確であること」を無条件に保証するのは危険です。10年前に別のベンダーが作ったシステムの仕様書が現在の実装と一致している保証は、発注者自身にもありません。一方で「提供する素材について必要な権利を有すること」は、自社が調達した素材であれば確認可能な範囲であり、保証しても不自然ではありません。
支給素材・第三者ライセンスの権利処理
発注者が提供する素材のうち、特に注意が必要なのが第三者から調達したものです。
- ストックフォトサービスから購入した画像（利用範囲がWebのみか、印刷物も含むか）
- 有償フォント（Webフォントとしての利用が許諾されているか）
- 過去に別のベンダーに制作を依頼したデザイン素材（著作権が自社に移転しているか）
- 他社から提供を受けたロゴ・商標（利用許諾の範囲）
これらについて「必要な権利を有していること」を保証する場合、保証する前に社内で権利関係を確認できているかどうかが分かれ目になります。過去の契約書が見つからない、購入時のライセンス条件が不明といった状態のまま保証するのは、リスクを取りすぎです。
現実的な対応としては、次のいずれかになります。
- 権利関係を確認できた素材に限定して保証する（別紙で素材リストを特定する）
- 主観的限定を付ける（「甲が知る限り」）
- 保証の対象から外し、代わりに「疑義が生じた場合は甲乙協議のうえ対応する」旨の協議条項に置き換える
1が最も望ましく、時間的制約で難しい場合に2、それも折り合わない場合に3、という順で検討します。
過大な保証を負わないための修正案（条項例）
ベンダーのドラフトが無限定な保証を求めている場合の、典型的な修正の方向性を示します。
修正前（無限定な保証）
「甲は、甲が乙に提供する一切の資料および情報が正確かつ完全であることを表明し、保証する。」
この条文の問題点は、(1)「一切の資料および情報」と対象が特定されていない、(2)「正確かつ完全」と要求水準が最大限、(3) 発注者が検証していない過去資料も含まれる、の3点です。
修正案A：対象を限定する
「甲は、甲が乙に提供する別紙記載の資料について、甲が把握する限りにおいて正確であることを表明し、保証する。ただし、甲が第三者から取得した資料および本契約締結前に第三者が作成した資料については、この限りではない。」
修正案B：責任の帰結を調整する
保証の範囲を狭める交渉が難しい場合、違反時の効果側で調整する方法もあります。
「甲が前項の表明保証に違反した場合、乙は当該違反に起因して追加的に必要となった作業について、甲乙協議のうえ、追加の委託料および納期の変更を請求することができる。」
この形であれば、発注者の責任は「追加費用と納期調整」に収まり、損害賠償という重い帰結を避けられます。ベンダー側にとっても、実際に困るのは手戻り工数の負担であることが多いため、双方の実質的な利害が一致しやすい着地点です。
前提資料の不正確さが後の紛争につながる構造については、要件定義段階のリスク管理と地続きの問題でもあります。契約段階で「どこまでを保証できるか」を整理しておくことは、プロジェクト後半のトラブル防止にも直結します。
システム開発における基本契約書の雛形
この資料でわかること
システム開発を依頼する際にシステム開発会社と締結する基本契約書の雛形をご紹介します。
こんな方におすすめです
- システム開発を発注する際にどのような基本契約を結ぶのか興味がある
- システム開発会社がきちんと契約の取り交わしをしてくれるのか不安
- システム開発を発注する側にどのような義務が生ずるのか気になる
入力いただいたメールアドレスにPDFをお送りします。
表明保証違反が起きたときの効果と発注者のリスク
条項を入れる意味があるかどうかは、結局「違反されたときに何が起きるか」で決まります。ここを理解すると、赤入れの優先順位が付けられるようになります。
損害賠償・補償請求
表明保証違反があった場合の中心的な救済は、金銭による填補です。ここには2つの構成があります。
債務不履行に基づく損害賠償
表明保証条項を「保証内容が真実であることを担保する債務」と捉え、それに違反したとして損害賠償を請求する構成です。契約書に特段の定めがない場合、この構成が基本になります。
契約上の補償条項に基づく請求
契約書に「表明保証に違反した場合、相手方に生じた損害を補償する」という補償条項（インデムニティ条項）を置いておく構成です。M&A実務ではこちらが一般的で、システム開発契約でも同様の設計は可能です。
発注者から見た違いは、請求できる損害の範囲を契約で明示的に広げられる点にあります。たとえば、次のような費用を補償対象として列挙しておくことができます。
- 第三者からの請求に対応するために要した弁護士費用
- 権利侵害部分を代替実装するために要した費用
- 権利者との和解金・ライセンス料
- サービス停止期間中の逸失利益（範囲の明示が必要）
これらを列挙せずに一般的な損害賠償条項だけで処理しようとすると、「その費用は通常生ずべき損害に含まれるのか」という争点が生じます。補償対象を具体的に書き出しておくこと自体が、紛争を予防する効果を持ちます。
契約解除・検収拒否
金銭賠償のほかに、契約関係そのものを解消する手段もあります。
契約解除
重大な表明保証違反があった場合に契約を解除できる旨を定めておく構成です。ただし、システム開発では解除の実効性が限定的な場合があります。開発が最終段階まで進んでいれば、解除して別のベンダーに一から作り直させるコストのほうが大きいためです。したがって、解除権は「最終手段としての交渉カード」として位置づけるのが実務的です。
なお、解除時にすでに支払った委託料の返還や、それまでの成果物の取扱いをどう定めるかは、解除条項本体で確認してください。ここが曖昧だと、解除できても支払った費用が戻らないという事態になり得ます。
検収拒否
表明保証違反が検収前に判明した場合、検収を拒否して修正を求めることが考えられます。この経路を確保するには、検収条件のなかに表明保証事項への適合を含めておく必要があります。
「甲は、本件成果物が検収基準を満たし、かつ乙の第○条（表明及び保証）に違反する事実が存在しないことを確認したうえで、検収を行うものとする。」
検収条件が「仕様書記載の機能が動作すること」のみに絞られている契約書は少なくありません。この場合、OSSライセンス違反が判明しても「仕様は満たしている」として検収拒否が難しくなる可能性があります。表明保証条項を追加する際は、検収条項との連動を必ず確認してください。
責任上限・請求期間の制限で救済が形骸化するケース
表明保証条項を入れたのに実際には機能しない、という状況は主に次の3パターンで発生します。
パターン1：責任上限の内側に取り込まれている
前述したとおり、損害賠償の上限が委託料総額に設定されており、表明保証違反もその内側に入る設計になっているケースです。権利侵害のように損害が委託料を大幅に超えうる事象では、救済が上限で頭打ちになります。
パターン2：請求期間が短すぎる
「本契約終了後6ヶ月以内に請求されたものに限る」といった期間制限が置かれているケースです。OSSライセンス違反や権利侵害は、リリースから年単位の時間を経て発覚することが多いため、この期間設定では実質的に使えません。最低でも1年、権利関係に関する保証については3年程度を目安に交渉することを検討してください。
パターン3：損害の範囲が限定されている
「通常生ずべき直接かつ現実の損害に限る」「逸失利益は含まない」といった限定が置かれているケースです。権利侵害でサービス停止に至った場合、損害の大部分は逸失利益になり得るため、この限定があると回収額は大きく減ります。
これら3点は、表明保証条項そのものではなく、責任制限条項の側に書かれていることに注意してください。表明保証の条文だけを読んでいると見落とします。契約書を確認するときは、必ず「表明及び保証」と「損害賠償」「責任の制限」をセットで読んでください。
すべてを発注者有利に修正するのは現実的ではありません。優先順位を付けるなら、パターン1（上限の適用除外）を、第三者権利非侵害と個人情報の項目に絞って交渉するのが、費用対効果の高いアプローチです。
「知る限り」「重要な点において」— 限定表現と基準時の読み方
契約交渉の実務で最も議論になるのが、表明保証に付される限定表現です。ここを理解していないと、条項の実効性を大きく損なった状態で締結してしまいます。
「知る限り」（主観的限定）が付くと何が変わるか
「乙の知る限り」「乙が知り得る限り」といった限定を主観的限定（ナレッジ・クオリフィケーション）と呼びます。
この限定が付くと、表明保証の性質が根本的に変わります。限定なしの表明保証は「事実が真実でなければ違反」ですが、主観的限定が付くと「相手が知っていたのに真実でなかった場合にのみ違反」となります。つまり、発注者側が「ベンダーは知っていた」ことを主張する必要が生じ、立証のハードルが大きく上がります。
「知る限り」と「知り得る限り」の違いにも注意が必要です。
表現 | 意味 | 発注者への影響 |
|---|---|---|
知る限り | 現に認識していた事実に限る | 最も限定が強い。相手が「知らなかった」と言えば違反にならない |
知り得る限り／合理的な調査の上で知る限り | 相応の調査をすれば認識できた事実を含む | 限定は緩む。調査義務が実質的に課される |
削除を求めるべきケース
- 第三者権利非侵害（OSSライセンス含む）: ベンダーがどのライブラリを組み込んだかは、ベンダー自身が最もよく知る事実です。「知らなかった」で免責される設計は不合理です
- 再委託の有無・要員の所属: 自社の体制に関する事実であり、知らないはずがありません
- 契約締結権限・許認可: 自社の内部事情です
残してよい、あるいは残さざるを得ないケース
- 第三者から取得したライブラリの、そのさらに先の権利関係
- 「係争の不存在」のうち、将来提起される可能性がある紛争
- 発注者が提供した資料の内容に依存する事項
つまり、その事実を保証する側が自ら把握しているべき事項かどうかが判断基準です。自ら把握しているべき事項に主観的限定が付いている場合は、削除を求める合理性があります。
なお、自社が保証する側の条項に付いている「甲の知る限り」は、発注者にとって有利な限定です。すべての限定表現を機械的に削除しようとすると、自社を守っている限定まで外すことになりかねません。
「重要な点において」（重要性限定）の読み方
「重要な点において」「重大な」といった限定を重要性限定（マテリアリティ・クオリフィケーション）と呼びます。軽微な不正確さで違反を主張されることを防ぐための限定です。
この限定は、主観的限定ほど一律に警戒する必要はありません。細かな記載ミスまで表明保証違反として扱うのは、双方にとって現実的ではないためです。
ただし、次の2点は確認してください。
「重要」の判断基準が契約書内で定義されているか
定義がない場合、何が重要かは事後の解釈に委ねられます。金額基準（「○○万円を超える影響が生じるもの」）や具体例を条文または別紙で示せると、争点を減らせます。
重要性限定を付けるべきでない項目に付いていないか
第三者権利非侵害、個人情報の適法な取扱い、反社会的勢力の排除については、重要性限定はなじみません。「重要でない権利侵害」という概念自体が成立しにくいためです。これらの項目に重要性限定が付いている場合は、削除を求める余地があります。
基準時は契約締結日か、納品日か、検収日か
限定表現と並んで見落とされやすいのが、表明保証の基準時です。表明保証は「一定時点の事実」を保証するものなので、その時点がいつかによって実効性が大きく変わります。
システム開発契約では、次の選択肢があります。
基準時 | 特徴 | 適した保証事項 |
|---|---|---|
契約締結日 | 最も一般的。締結時点の事実のみを保証 | 契約締結権限、許認可、係争の不存在、反社会的勢力の排除 |
納品日／検収日 | 成果物の完成時点で保証。開発中の変化を捕捉できる | 第三者権利非侵害、OSSライセンス、生成AI由来のリスク |
契約期間中の継続保証 | 期間を通じて保証が継続する。最も発注者に有利 | 個人情報の適法な取扱い、労務コンプライアンス、再委託の状況 |
ここに、システム開発契約特有の落とし穴があります。成果物に関する保証を「契約締結日」基準にしてしまうと、条項がほとんど機能しません。契約締結日の時点では、成果物はまだ存在していないからです。
契約書のドラフトで「乙は、本契約締結日において、本件成果物が第三者の権利を侵害しないことを保証する」といった書き方になっていたら、これは修正対象です。
「乙は、本契約締結日および本件成果物の納入日のそれぞれにおいて、以下の事項が真実かつ正確であることを表明し、保証する。」
このように複数の基準時を設定する（M&A実務でいうブリングダウン）のが、システム開発契約でも有効な設計です。個別契約が複数ある案件では、「各個別契約に基づく成果物の納入日において」という形で、案件ごとに基準時が更新されるようにしておきます。
システム開発契約のドラフトを受け取ったときの確認手順
ここまでの内容を、実際の作業手順に落とし込みます。契約ドラフトを受け取ってから修正依頼を出すまでの流れです。
表明保証条項を読むときの5ステップ
ステップ1：表明保証条項の所在と主体を特定する
契約書一式（基本契約書・個別契約書・NDA・保守契約書）に目を通し、「表明」「保証」「〜でないことを確認する」といった表現が使われている箇所をすべて洗い出します。条項のタイトルが「表明及び保証」でなくても、実質的に事実の保証をしている条項は同じ扱いになります。
洗い出したら、各項目について「甲（発注者）が保証するもの」「乙（ベンダー）が保証するもの」「双方が保証するもの」に分類します。この仕分けを最初にやっておかないと、以降のステップで自社に有利／不利の判断を誤ります。
ステップ2：自社が保証する側か、させる側かで読み分ける
保証する側の項目については「飲めるか」を、させる側の項目については「足りているか」を検討します。両者は逆方向の作業なので、混ぜずに進めてください。
ステップ3：保証事項を「検証可能な事実か」でふるいにかける
自社が保証する項目を、次の3つに分類します。
- A: 自社が現に確認できている事実 → そのまま保証してよい
- B: 確認しようと思えば確認できるが、まだ確認していない事実 → 締結前に確認する。時間がなければ限定を付ける
- C: 自社には確認する手段がない事実 → 対象から外すか、主観的限定を付けるか、協議条項に置き換える
Cが残ったまま無限定の保証をしている場合、それが最優先の修正対象です。
ステップ4：限定表現と基準時を確認する
ベンダーが保証する項目については、主観的限定・重要性限定が付いていないか、基準時が適切かを確認します。特に成果物に関する保証の基準時が契約締結日のみになっていないかは必ずチェックしてください。
自社が保証する項目については、逆に限定が付いているかを確認します。付いていない場合は追加を求めます。
ステップ5：違反時の効果と責任上限の関係を確認する
損害賠償条項・責任制限条項を並べて読み、表明保証違反がどう扱われるかを確認します。確認する観点は次の3点です。
- 責任上限の適用対象に入っているか。入っている場合、上限額はいくらか
- 請求期間の制限はあるか。何年か
- 損害の範囲に限定はあるか（逸失利益の除外など）
そのうえで、第三者権利非侵害と個人情報に関する保証について、上限の適用除外を求めるかどうかを判断します。
社内で判断できる範囲と、弁護士に相談すべき範囲
社内に専任法務がいない場合、すべてを自力で処理しようとするのは危険ですが、逆にすべてを外部に投げるのも非効率です。線引きの目安を示します。
社内で判断・対応してよい範囲
- 表明保証条項がどこにあるか、誰が保証する側かの整理（ステップ1〜2）
- 自社が保証を求められている事実を、社内で確認できるかどうかの調査（ステップ3）
- 提供する素材・資料の権利関係の棚卸し
- OSS一覧の提示をベンダーに求めること
- 基準時が成果物の納入日を含んでいるかの確認
これらは事実確認と情報整理であり、法的判断を伴いません。むしろ社内でしか実施できない作業です。
弁護士に相談すべき範囲
- 責任上限の適用除外をどこまで求めるか、その条文をどう書くか
- 表明保証違反と債務不履行・契約不適合責任の請求構成の設計
- 補償条項（インデムニティ）の要否と、補償対象の範囲設定
- 生成AI・学習データに関する条項の具体的な文言
- ベンダーが強く抵抗している条項について、代替案をどこに求めるか
- 契約金額が大きい、または基幹システムなど事業継続への影響が大きい案件全般
社内でステップ1〜3までを済ませ、「何が論点か」を整理した状態で相談すると、弁護士の作業時間が短縮され、費用も抑えられます。「この契約書を見てください」と丸投げするより、「この5項目について、自社は確認手段がありません。どう限定すべきでしょうか」と聞くほうが、実効的な回答が得られます。
なお、本記事は一般的な考え方を整理したものであり、個別の契約に対する法律上の助言ではありません。実際の契約内容の判断にあたっては、案件の事情を踏まえて弁護士にご確認ください。
ベンダーへの修正依頼の伝え方
最後に、修正依頼の伝え方について触れておきます。契約交渉は、その後のプロジェクトの協力関係にも影響するためです。
避けたい伝え方: 「この条項は当社として受け入れられません」
推奨する伝え方: 「この項目について、当社側で事実を確認する手段がないため、そのまま保証するのが難しい状況です。◯◯という限定を付けるか、対象から外していただくことは可能でしょうか」
違いは、「拒否」ではなく「懸念事象の共有」として伝えている点です。表明保証に関する修正依頼は、突き詰めると「どちらがそのリスクを引き受けるか」の分担の話です。相手を疑っているわけではなく、リスクの所在を明確にしたいのだという文脈で伝えると、建設的な議論になりやすくなります。
また、修正依頼は優先順位を付けて提示することをおすすめします。10項目を並列で出されるとベンダー側も判断に困りますが、「必須で対応いただきたいのは2項目、可能であれば検討いただきたいのが3項目」と整理されていれば、交渉が進みます。優先度の高いものは、成果物の第三者権利非侵害と、自社が無限定の保証を負っている項目です。
まとめ｜表明保証はシステム開発の文脈に読み替えて確認する
システム開発契約における表明保証について、持ち帰っていただきたい判断軸を整理します。
1. M&Aの一般論は、翻訳すればそのまま使える
表明保証は「一定時点の事実が真実かつ正確であること」を保証する仕組みです。情報の非対称性を埋めるための道具という本質はM&Aと共通しており、「情報を持っている側＝ベンダー」「調べきれない側＝発注者」と読み替えれば、考え方の骨格は流用できます。ただし保証させる事実の中身は、成果物の権利関係・データの取扱い・再委託体制へと入れ替わります。
2. 既存条項との関係は「重複」ではなく「補完」
契約不適合責任は仕様への適合を守る制度、知的財産権侵害の責任条項は紛争が起きた後の対応ルール、表明保証は前提事実そのものの確認です。カバー範囲が異なるため、表明保証を削る理由にはなりません。一方で、責任上限条項の内側に取り込まれていると実効性が大きく下がるため、両者をセットで読むことが不可欠です。
3. 「保証させる側」と「保証する側」を分けて読む
システム開発契約では、発注者は同時に両方の立場に立ちます。させる側では第三者権利非侵害・生成AI由来のリスク・個人情報・再委託体制の4項目を優先し、する側では「自社が現に確認できる事実か」を基準に、確認できないものは限定を付けるか対象から外します。
4. 限定表現と基準時が交渉の焦点
「知る限り」は保証の性質を根本から変えるため、ベンダー自身が把握しているべき事項に付いている場合は削除を求めます。基準時については、成果物に関する保証が契約締結日のみになっていると条項が機能しないため、納入日を含める修正が必要です。
契約ドラフトを前に手が止まってしまったときは、まず「表明保証条項がどこにあり、誰が保証しているか」の洗い出しから始めてみてください。この整理ができた時点で、論点の大半は見えてきます。そのうえで、自社では判断しきれない部分を弁護士に相談すれば、限られた時間とコストで実効的な契約に近づけられます。
関連情報
システム開発契約の全体像を条文レベルで確認したい場合は、システム開発における基本契約書の雛形をご用意しています。表明保証を含む各条項がどのような文脈で配置されるかを、実際の契約書の形でご確認いただけます。
システム開発の発注準備や契約条件の整理段階でお困りのことがありましたら、お問い合わせフォームからご相談ください。要件の固まっていない段階からのご相談も承っています。
参考資料
- 情報システム・モデル取引・契約書（独立行政法人情報処理推進機構）
- 民法（e-Gov法令検索）
- 法令・ガイドライン等（個人情報保護委員会）
- 経済産業省「AI・データの利用に関する契約ガイドライン」1.1版、2019年
システム開発における基本契約書の雛形
この資料でわかること
システム開発を依頼する際にシステム開発会社と締結する基本契約書の雛形をご紹介します。
こんな方におすすめです
- システム開発を発注する際にどのような基本契約を結ぶのか興味がある
- システム開発会社がきちんと契約の取り交わしをしてくれるのか不安
- システム開発を発注する側にどのような義務が生ずるのか気になる
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- ベンダーが零細企業で資力に乏しい場合、表明保証条項を入れても意味がないのでは？
表明保証は「事実に反していれば違反が成立する」仕組みであり、相手の資力とは別の論点です。回収可能性への不安は損害賠償条項（上限・遅延損害金等）側の設計問題であるため、資力が不安な相手には損害賠償の実効性を別途確認してください。
- 準委任契約の場合も表明保証条項は必要ですか？
記事は請負中心の想定ですが、準委任でも成果物やAI生成物、個人情報の取扱いなど「事実」を保証する性質は変わらず有効です。ただし納品日基準の保証などは、準委任の業務性質に合わせて基準時を調整する必要があります。
- 表明保証条項の交渉で、ベンダーが「他社では入れていない」と抵抗してきた場合はどう判断すればいいですか？
業界の一般的な慣行より、自社が負うリスクの大きさで判断してください。第三者権利非侵害や個人情報のように、事故時の損害が委託料の上限を超えて青天井になりやすい項目は、他社事例の有無に関わらず優先して交渉する価値があります。損害賠償の上限適用除外まで求められるかも併せて検討してください。
- 契約締結までの時間がなく、表明保証条項を全て確認する余裕がない場合、最低限どこを見ればいいですか？
記事のステップ3にある「自社に確認手段がない事実」に無限定の保証をしていないかを最優先で確認してください。次に成果物に関する保証の基準時が契約締結日のみになっていないかを見れば、時間が限られていても主要リスクは押さえられます。
- 表明保証違反が発覚しても、まだ実損害が出ていない段階でベンダーに何か請求できますか？
損害が発生する前でも、事実と異なることが判明した時点で表明保証違反を主張できます。たとえば納品後の監査でGPLライセンスのコードの混入が分かったが、まだ権利者からの請求は受けていない、という段階でも、改修費用の負担や再発防止策について契約上の補償条項や協議条項を根拠に早期に協議を申し入れることが可能です。
