契約書に書いておくべきトラブル条項

開発会社との契約書にサインする直前、「著作権のこと」「検収の条件」は気にして確認したのに、気づいたら残りのページをほとんど読まずに判を押していた——そんな経験はないでしょうか。実際にトラブルが起きるのは、たいてい契約からしばらく経った運用フェーズです。納期が守られなかった、保守契約を打ち切られたのに開発中のデータが返ってこない、業務データを扱っていた開発会社が第三者にそれを漏らしていた、あるいは不具合のせいで自社が取引先から損害賠償を求められた——。こうした場面で実際に自社を守ってくれるのは、著作権条項でも検収条件でもなく、契約書の後半にひっそり置かれていることが多い「遅延損害金」「解除条件」「秘密保持」「損害賠償の上限」といった条項です。

結論から言うと、これらの条項は民法や個別の法律で最低限のルールが定められているものの、契約書に何も書かなければそのまま自社に不利な形で運用されてしまう可能性が高い項目です。法律の原則がそのまま適用されるだけならまだしも、実務では開発会社が用意したひな形の契約書に、開発会社側に有利な特約が最初から書き込まれているケースも珍しくありません。「特に何も書いていないから安全」という思い込みが、最も危険な状態です。

なお、似たタイトルの記事に「ソースコードの著作権は誰のもの？契約書の確認ポイント」がありますが、あちらは主にソースコードの著作権が誰のものになるかという権利の帰属を扱ったものです。この記事はそれとは別の切り口で、運用フェーズで実際にトラブルが起きたときに、契約書のどの条項が自社を守ってくれるかにしぼって解説します。また、感情的にならずに交渉する進め方そのものについては、別記事「トラブル時の交渉術」で扱っていますので、条項の中身を先に押さえたい方はこちらの記事から読み進めてください。

この記事では、遅延損害金・解除条件・秘密保持・損害賠償の上限という4つの条項を軸に、それぞれ何が問題になるのか、契約書のどこをどう確認すればよいのか、民法や不正競争防止法の条文に基づいて整理します。専門用語は初出の箇所で言い換えを添えますので、契約書に不慣れな方でも、自社の契約書を横に置きながら読み進めていただければ、確認すべきポイントが具体的に分かるようになっています。

この記事で分かること

外部の開発会社とシステム開発・保守の契約を結ぶ際、あるいはすでに結んでいる契約書を見直す際に、実際にトラブルが起きたときの対応を左右する4つの条項（遅延損害金、契約解除条件、秘密保持、損害賠償の上限）について、それぞれの法律上の原則と、契約書で確認・交渉すべきポイントを解説します。あわせて、これらの条項が実際にどう機能するのかを、納期遅延・保守契約の一方的な解除・情報漏えい・損害賠償請求という4つの具体的な場面に当てはめて説明します。読み終える頃には、自社の契約書のどのページのどの条項が、どのトラブルに対応しているのか（あるいは対応していないのか）を、具体的にチェックできる状態を目指します。

なぜ「トラブル条項」は後回しにされやすいのか

契約書を確認する際、多くの担当者がまず目を通すのは、契約金額・支払い条件・納期・成果物の内容といった、契約の「本体」にあたる部分です。これは自然なことで、そもそも何にいくら払うのかが分からなければ契約自体が成立しません。

一方、遅延損害金・解除条件・秘密保持・損害賠償の上限といった条項は、契約書の後半、しばしば「一般条項」「その他」といった見出しの下にまとめて置かれています。これらは「何も起きなければ一生読まれない条項」であるがゆえに、確認作業の優先順位が下がりがちです。しかし実際には、この優先順位こそが逆転しています。

• 契約金額や納期の条項は、トラブルが起きなくても毎回参照される条項です
• 遅延損害金・解除条件・秘密保持・損害賠償の上限は、トラブルが起きたときにだけ参照される条項ですが、まさにそのときにこそ、自社を守れるかどうかが決まります

火災保険に入るとき、保険料の額だけでなく「どんな場合に、いくら支払われるのか」という約款を確認するのと同じ発想です。平時には目立たない条項ほど、有事に効いてきます。この記事で扱う4条項は、いずれも「トラブルが起きた後」に初めて意味を持つという共通点があります。

契約書レビューの優先順位を見直す視点: 「この条項は、何も起きなければ読まれない」という条項ほど、実際にトラブルが起きたときの影響が大きい傾向があります。契約書を受け取ったら、本体条項と同じくらいの時間をかけて、後半の一般条項にも目を通してください。

条項1: 遅延損害金——納期が守られなかったとき何が起きるか

システム開発でもっとも頻繁に起きるトラブルの一つが、納期の遅延です。開発会社側の事情で予定していた納品日が延び、自社の業務開始やキャンペーン開始のスケジュールに影響が出た、というケースは珍しくありません。

契約書に何も書かれていない場合の原則

契約書に遅延損害金の条項がない場合、どうなるのでしょうか。まず理解しておきたいのは、納期遅延は民法上の「準委任契約」や「請負契約」における債務不履行の一種であり、損害賠償を請求できる可能性がある、という原則です。

民法では、債務不履行による損害賠償の範囲について次のように定めています。

債務の不履行に対する損害賠償の請求は、これによって通常生ずべき損害の賠償をさせることをその目的とする。特別の事情によって生じた損害であっても、当事者がその事情を予見すべきであったときは、債権者は、その賠償を請求することができる。

—— 民法第416条

つまり、納期が守られなかったことで実際に生じた損害（「通常生ずべき損害」）については、契約書に何も書かれていなくても、原則として損害賠償を請求できます。ただし、ここで問題になるのが立証の難しさです。「納期が3週間遅れたことで、具体的にいくらの損害が発生したか」を客観的な資料で示すのは、実務上かなりの手間がかかります。機会損失（本来得られたはずの売上）のように、金額を厳密に算定しにくい損害であればなおさらです。

遅延損害金条項があるとどう変わるか

これに対して、契約書に「遅延損害金」の条項があらかじめ定められていれば、実際の損害額を個別に立証しなくても、契約で合意した計算式（多くは「遅延日数×契約金額×年率」）に基づいて金額を請求できます。これは民法上の金銭債務の特則とも関係しています。

金銭の給付を目的とする債務の不履行については、その損害賠償の額は、債務者が遅滞の責任を負った最初の時点における法定利率によって定める。ただし、約定利率が法定利率を超えるときは、約定利率による。この損害賠償については、債権者は、損害の証明をすることを要しない。

—— 民法第419条1項・2項

この条文はもともと金銭の支払いが遅れた場合（発注者が代金を払わない場合など）を主に想定したものですが、契約書に遅延損害金の利率（「約定利率」）を明記しておけば、実際の損害を立証する手間なく、合意した利率に基づいて請求できるという発想は、システム開発の納期遅延に関する特約にも応用されています。なお、法定利率は民法第404条により変動制で、2026年8月時点では年3%です。契約書に約定利率が明記されていない場合、この法定利率が目安になります。

契約書で確認すべきポイント

遅延損害金条項について、契約書では次の点を確認してください。

なお、遅延損害金条項が「発注者が支払いを遅延した場合」だけを想定して書かれており、「開発会社が納品を遅延した場合」については何も触れていない契約書もあります。これは開発会社にとって都合の良い片務的な条項になっている典型例なので、両方向の遅延に対応した条項になっているかを確認してください。

条項2: 解除条件——契約をいつ、どう終わらせられるか

保守契約や準委任契約で特に重要になるのが、「どのような場合に、どちらから契約を解除できるか」という解除条件の条項です。ここが曖昧だと、開発会社の対応が著しく悪化しても契約を切れない、あるいは逆に、開発会社から一方的に保守契約を打ち切られて困る、という事態が起こり得ます。

民法上の解除の原則

まず民法上の原則を確認します。契約の一方が債務を履行しない場合、相手方は次の2つのルートで契約を解除できます。

当事者の一方がその債務を履行しない場合において、相手方が相当の期間を定めてその履行の催告をし、その期間内に履行がないときは、相手方は、契約の解除をすることができる。ただし、その期間を経過した時における債務の不履行がその契約及び取引上の社会通念に照らして軽微であるときは、この限りでない。

—— 民法第541条（催告による解除）

これは「催告解除」と呼ばれるルートで、相当な期間を定めて履行を求め（催告）、それでも履行されない場合に初めて解除できるという、いわば通常のルートです。

一方、次のような重大なケースでは、催告をせずに直ちに解除できる例外規定もあります。

次に掲げる場合には、債権者は、前条の催告をすることなく、直ちに契約の解除をすることができる。一　債務の全部の履行が不能であるとき。二　債務者がその債務の全部の履行を拒絶する意思を明確に表示したとき。（中略）五　前各号に掲げる場合のほか、債務者がその債務の履行をせず、債権者が前条の催告をしても契約をした目的を達するのに足りる履行がされる見込みがないことが明らかであるとき。

—— 民法第542条1項（催告によらない解除）

これらは民法上のデフォルトルールであり、契約書に特約がなくても適用されます。ただし、「相当の期間」がどのくらいか、「軽微」かどうかの判断は、条文だけでは一義的に定まりません。実際に紛争になった場合、これらの評価をめぐって当事者間の見解が対立しやすい部分です。

契約書の解除条項で確認すべきポイント

このあいまいさを減らすため、契約書には民法の原則を前提としつつ、より具体的な解除条件が定められているのが通常です。確認すべきポイントを整理します。

• 催告なしで即時解除できる事由が列挙されているか：「重大な契約違反があった場合」「監督官庁からの許認可取消しがあった場合」「破産・民事再生等の申立てがあった場合」など、具体的な事由が列挙されているか
• 催告期間の日数：「◯日以内に是正されない場合」のように、猶予期間の日数が明記されているか（明記がないと民法の「相当の期間」の解釈に委ねられ、双方の認識がずれやすい）
• 中途解約の条件：準委任契約の保守契約などで、双方が任意に解約できる中途解約条項がある場合、予告期間（「解約希望日の◯か月前までに書面で通知」等）が定められているか
• 解除後の引き継ぎ義務：解除に至った場合、開発会社側にデータ・ソースコード・アカウント情報等の引き継ぎ義務が課されているか

特に最後の「解除後の引き継ぎ義務」は見落とされがちですが、実務上もっとも困る場面です。契約を解除できても、稼働中のシステムのデータやアカウント情報が手元に戻ってこなければ、業務が止まってしまいます。解除条項とセットで、システム管理台帳に記載すべき情報（アカウント、契約、データの所在）が引き継ぎ対象に含まれているかを確認しておくと安心です。

保守契約の一方的な打ち切りへの備え

もう一つ実務上多いのが、開発会社側の経営判断や体制変更により、保守契約の更新を拒否される、あるいは契約期間の途中で打ち切りを通告されるケースです。この場合に備え、契約書には次のような条項が入っているかを確認してください。

1. 契約更新を拒否する場合の事前通知期間（「契約満了の◯か月前までに通知」等）
2. 中途解約する場合の事前通知期間と、通知が不十分な場合のペナルティ（違約金等）
3. 解約時点での未完了作業・未払い費用の精算方法

これらが契約書に明記されていないと、ある日突然「来月から保守を打ち切ります」という通告を受けても、法律上明確に対抗する根拠が乏しく、次の開発会社を探す時間的猶予もないまま、システムが放置される事態につながりかねません。

条項3: 秘密保持——業務データの取り扱いをどう縛るか

システム開発を外注すると、顧客リスト、取引条件、社内の業務フロー、場合によっては人事情報や財務情報まで、開発会社に開示する場面が出てきます。これらの情報が意図せず外部に漏れたり、開発会社の他の案件に流用されたりしないようにするのが秘密保持条項です。

秘密保持契約（NDA）と契約書内の秘密保持条項の違い

秘密保持については、契約の初期段階で個別に「秘密保持契約（NDA、Non-Disclosure Agreementの略）」を締結するケースと、開発委託契約や保守契約の中に秘密保持条項として組み込むケースの両方があります。どちらの形式であっても、確認すべき内容は基本的に同じです。

契約書に何も定めがない場合でも、不正競争防止法上、「営業秘密」に該当する情報については一定の法的保護があります。同法では営業秘密を次のように定義しています。

この法律において「営業秘密」とは、秘密として管理されている生産方法、販売方法その他の事業活動に有用な技術上又は営業上の情報であって、公然と知られていないものをいう。

—— 不正競争防止法第2条6項

ここで重要なのは、不正競争防止法による保護を受けるには、「秘密として管理されている」という要件（秘密管理性）を満たす必要がある点です。つまり、社内で誰でも見られる状態になっている情報や、開発会社に渡す際に「これは秘密情報です」という扱いが明確にされていない情報は、たとえ実質的に重要な情報であっても、法律上の「営業秘密」として保護されにくくなります。この意味でも、契約書やNDAで秘密情報の範囲と取り扱いを明文化しておくことには、単なる念のため以上の実務的な意味があります。

契約書で確認すべきポイント

秘密保持条項については、次の項目を確認してください。

最後の「生成AIの取り扱い」は、近年の契約書レビューで新たに注目されるようになった観点です。開発会社の担当者が、コーディング支援や議事録作成のために生成AIツールを日常的に使っている場合、意図せず自社の機密情報がAIサービスへの入力データとして送信されてしまうリスクがあります。この点をどう管理するかは、自社側で機密情報をAIに入力しないための社内ルールを検討する際にも参考になります。社内ルール整備とあわせて、外部委託先にも同様の水準を求められるかを確認しておくとよいでしょう。

再委託先まで気を配る理由

秘密保持条項の中でも見落とされがちなのが、再委託先への適用範囲です。多くのシステム開発案件では、元請けの開発会社がすべての工程を自社だけで完結させるのではなく、一部の工程（デザイン、インフラ構築、テストなど）を別の会社やフリーランスに再委託していることがあります。

元請けの開発会社との間でどれだけ厳格な秘密保持条項を結んでいても、再委託先にはその義務が及ばない、あるいは再委託自体が契約書で禁止・制限されていない場合、自社の情報が想定より広い範囲の関係者に共有されてしまう可能性があります。契約書に「乙（開発会社）は、再委託先に対しても本条と同等の秘密保持義務を課すものとする」といった一文が入っているか、あるいは再委託そのものに事前の書面承諾を必要とする条項があるかを確認しておくことをおすすめします。

条項4: 損害賠償の上限——「青天井」を避けられているか

最後に扱うのが、損害賠償の上限（責任制限）条項です。これは4つの条項の中でも特に、発注者・開発会社の双方にとって利害が真っ向から対立しやすい項目です。

なぜ開発会社は上限を設けたがるのか

システムの不具合が原因で、発注者側に大きな損害が発生する場合があります。例えば、ECサイトの決済処理にバグがあり、二重課金が大量発生して顧客対応・返金コストが膨らんだ、業務システムの停止により営業機会を逃した、といったケースです。

このとき、発注者としては「実際に生じた損害はすべて開発会社に賠償してほしい」と考えるのが自然です。一方、開発会社側からすると、数十万円〜数百万円の開発委託料に対して、青天井（上限のない）の損害賠償責任を負うことは、事業継続上のリスクが大きすぎます。そのため、多くの契約書のひな形には、次のような損害賠償の上限を定める条項が入っています。

「乙（開発会社）の甲（発注者）に対する損害賠償責任は、本契約に基づき甲が乙に支払った委託料の総額を上限とする」

この種の条項自体は、契約自由の原則のもとで有効に成立するのが一般的です。問題は、この上限額が自社にとって実質的に見合っているかどうかです。

上限条項を確認する際の視点

損害賠償の上限条項については、次の観点で確認してください。

• 上限額の水準：「委託料の総額」を上限とする条項は広く使われていますが、委託料が数十万円規模の小規模開発で、システムの不具合による想定損害額（顧客対応コスト、機会損失等）がそれをはるかに上回る可能性がある場合、この上限では実質的に「賠償されないに等しい」状態になり得ます
• 上限が適用されない例外の有無：多くの契約書では、開発会社側に故意または重過失があった場合には、この上限を適用しないという例外規定が置かれています。この例外規定があるかどうかは重要な確認ポイントです。例外規定がないと、開発会社が明らかな手抜き作業をしていた場合でも、賠償額が委託料の範囲に固定されてしまいます
• 秘密保持義務違反への適用有無：損害賠償の上限条項が、秘密保持義務違反（情報漏えい）による損害にも一律に適用されるのか、それとも秘密保持義務違反は別枠として上限の対象外とされているのかを確認してください。情報漏えいの実害は、開発委託料をはるかに超える規模になり得るため、この点を分けて交渉できないか検討する価値があります

上限額をめぐる交渉の現実的な落としどころ

上限額そのものを撤廃する交渉は、多くの場合、開発会社側の抵抗が強く、簡単には応じてもらえません。現実的な交渉の選択肢としては、次のようなものがあります。

1. 上限額を「委託料の総額」ではなく「委託料の◯倍」に引き上げてもらう
2. 故意・重過失の場合の上限適用除外を明記してもらう
3. 秘密保持義務違反による損害は上限の対象外とする特約を追加してもらう
4. 損害賠償責任保険（開発会社側が加入するIT賠償責任保険等）への加入状況を確認する

これらの交渉がどこまで通るかは、案件の規模、開発会社との力関係、業界の商慣習によって大きく変わります。特にシステムが取り扱うデータの機微性が高い場合（個人情報、決済情報、医療情報等）や、システム障害の影響範囲が大きい場合は、契約締結前の段階で弁護士等の専門家に契約書案を確認してもらい、自社のリスクに見合った上限額になっているかを検討することを強くおすすめします。

4つの条項が実際にどう働くか、場面別に確認する

ここまで条項ごとに解説してきましたが、実際のトラブルでは複数の条項が同時に関わってくることも珍しくありません。4つの典型的な場面に当てはめて、どの条項がどう機能するかを整理します。

場面1：システムの納品が2か月遅れた

このケースでは、まず遅延損害金条項の有無と内容を確認します。条項があれば、契約で定めた計算式に基づいて損害額を算定できます。条項がなければ、民法第416条に基づき、実際に生じた損害を個別に立証する必要があります。あわせて、遅延が著しく、今後も履行の見込みがないと判断される場合は、解除条件（民法第541条・第542条）に基づく契約解除も選択肢になります。

場面2：保守契約を一方的に打ち切られた

このケースでは解除条件の条項、特に事前通知期間と解約時の引き継ぎ義務が焦点になります。通知期間が守られていない、あるいは引き継ぎ義務が果たされていない場合、契約違反として対応を求める根拠になります。あわせて、打ち切りによって発生した実害（緊急対応の外注費用増加など）については、損害賠償の上限条項の範囲内で請求を検討することになります。

場面3：開発会社の担当者が顧客データを外部に漏らした

このケースでは秘密保持条項が中心的な争点です。契約書に秘密情報の定義や目的外使用の禁止が明記されていれば、契約違反を理由とした損害賠償請求の根拠になります。契約書に定めがなくても、漏えいした情報が不正競争防止法上の「営業秘密」（秘密管理性・有用性・非公知性の3要件を満たす情報）に該当すれば、同法に基づく差止請求・損害賠償請求も選択肢に入ります。ただし、この判断は専門的な法律知識が必要な領域のため、弁護士に相談することをおすすめします。

場面4：システムの不具合で自社が取引先から損害賠償を求められた

このケースでは、まず不具合が契約不適合責任（契約不適合責任）に該当するかを確認し、開発会社に修補や損害賠償を求められるかを検討します。そのうえで、開発会社に請求できる金額が損害賠償の上限条項によってどこまで制限されるかを確認する必要があります。取引先への賠償額が、開発会社への請求上限を上回ってしまうと、差額を自社で負担せざるを得なくなるため、この条項の水準は特に重要です。

契約締結前にできること、締結後にできること

4つの条項の確認・交渉は、契約締結前と締結後とで、できることの幅が大きく異なります。

契約締結前であれば、次のような行動が現実的に取れます。

• 相見積もりの段階で、複数の開発会社の契約書ひな形を比較し、遅延損害金・解除条件・秘密保持・損害賠償上限の水準を見比べる
• 気になる条項について、契約締結前の交渉で修正を依頼する（応じてもらえるかは開発会社次第ですが、交渉の余地は締結後より格段に大きい）
• SLA（サービス品質保証）（サービス品質保証）やエスカレーションのルートとあわせて、保守契約の対応水準を具体的に取り決めておく
• 判断に迷う条項があれば、契約締結前に弁護士等の専門家へレビューを依頼する

すでに契約を締結してしまっている場合は、選択肢は限られますが、次のような対応が考えられます。

• まずは契約書を読み返し、4つの条項が実際にどう書かれているかを正確に把握する（「たぶんこうだろう」ではなく、条文そのものを確認する）
• 保守契約の更新タイミングや、追加の発注が発生するタイミングで、条項の見直しを交渉する
• トラブルが実際に発生した場合は、感情的な対応を避け、事実を記録しながら、契約書に基づいた交渉を進める（具体的な進め方は関連記事「トラブル時の交渉術」を参照してください）
• 契約書の解釈に迷う場合、あるいは実際に紛争に発展しそうな場合は、早めに弁護士に相談する

いずれの場合も、「知らなかった」まま時間が経過するのが最もリスクの高い状態です。まずは自社の契約書を開き、4つの条項がどう書かれているか（あるいは書かれていないか）を確認するところから始めてください。

まとめ：トラブル条項は「読まれないからこそ」先に読む

この記事で扱った4つの条項を振り返ります。

1. 遅延損害金：納期が守られなかった場合、実際の損害を個別に立証しなくても請求できる仕組みがあるか
2. 解除条件：どのような場合に、どちらから、どのような手続きで契約を解除できるか。解除後の引き継ぎ義務は明記されているか
3. 秘密保持：秘密情報の範囲、目的外使用の禁止、再委託先への適用、契約終了後の存続期間が定められているか
4. 損害賠償の上限：上限額の水準は自社のリスクに見合っているか、故意・重過失の場合の例外規定はあるか

これらはいずれも、平時には目立たない条項です。しかし、実際にトラブルが起きたとき、自社がどれだけ守られるかは、契約金額や納期の条項ではなく、まさにこの4つの条項によって決まります。

次にシステム開発や保守の契約書を受け取る機会があれば、本体条項の確認と同じくらいの時間を使って、これら4条項にも目を通してみてください。すでに契約を結んでいる場合も、まずは契約書を読み返すところから始められます。また、トラブルが実際に起きてしまい、感情的にならずに交渉を進める具体的な手順を知りたい方は、関連記事「トラブル時の交渉術：感情的にならずに解決する」もあわせてご参照ください。