契約書の定義条項を、用語集ではなくリスク配分と証拠化の仕組みとして設計するための企業法務向け実務解説です。
契約書の定義条項を、用語集ではなくリスク配分と証拠化の仕組みとして設計するための 企業法務 向け実務解説です。
定義条項は用語集ではなく、契約の射程と証拠をあらかじめ固定する設計装置です。
定義条項は、契約書の中で繰り返し使う重要語の意味を特定する条項です。ただし実務上の役割は、単なる言葉の短縮ではありません。契約の対象、当事者の役割、権利義務の範囲、責任の限界、証拠化の方法、紛争時の解釈枠組みを先に固定するための中核的な仕組みです。
将来の紛争は、「何を約束したか」だけでなく、「その言葉がどこまでを含むか」「例外はあるか」「いつの時点を指すか」「本文、別紙、見積書、仕様書、メールのどれが優先するか」という境界線のずれから生じます。このページでは、その境界線を契約締結時に可視化し、後から検証できる形に整える考え方を整理します。
まず、定義条項が契約全体で何を固定するのかを3つの観点に分けます。この整理は、読者が定義条項を「冒頭の形式」ではなく「契約全体に効くリスク配分」として読むために重要です。各項目から、定義語が後続条項にどのような影響を及ぼすかを読み取ってください。
本業務、成果物、秘密情報、顧客データ、重大な違反など、後続条項の適用範囲を決めます。広げすぎても狭すぎても、交渉と運用で問題が生じます。
成果物を広く定義すれば納入義務や権利移転の範囲が広がり、損害や秘密情報をどう定義するかで責任や管理負担が変わります。
契約締結時に当事者が想定していた対象、例外、時間軸、証明方法を本文に残し、将来の第三者にも読み取れる状態にします。
とくに共同開発、システム開発、SaaS、秘密保持、M&A、ライセンス契約では、定義の一語が納入義務、知的財産権、解除、損害賠償、データ利用、表明保証に連動します。定義条項を見直すときは、用語だけを直すのではなく、本文・別紙・仕様書・運用資料まで同時に確認する必要があります。
争点になりやすいのは、約束の存在よりも言葉の境界線です。
企業間取引では、契約を締結した事実そのものよりも、定義語の射程が争われることが少なくありません。「本業務」に追加対応が入るのか、「成果物」にソースコードやデータが入るのか、「検収完了」は明示承認なのか不通知なのか、といった点が請求額や解除権を左右します。
次の一覧は、定義条項で先に境界線を置かない場合に紛争化しやすい領域をまとめたものです。読者にとって重要なのは、各領域が単独で問題になるのではなく、支払、解除、知財、責任制限、証拠提出に連鎖する点です。どの言葉がどの条項に影響するかを読み取ってください。
追加対応、会議、障害調査、教育研修、第三者調整が本業務に含まれるかが争点になります。
成果物に報告書だけでなく、ソースコード、設計資料、設定ファイル、データ加工結果が含まれるかが問題になります。
秘密情報、個人情報、利用データ、ログ、Cookie、仮名加工情報などの扱いが混線しやすくなります。
営業日、通知到達日、検収期間、是正期間、契約期間の始期が不明確だと手続の有効性が揺れます。
不可抗力、外部サービス障害、法令改正、サイバー攻撃、制裁などを含むかで責任の有無が変わります。
本文、別紙、個別契約、発注書、仕様書、見積書の内容がずれたときに、どれを優先するかが問題になります。
将来その契約を読む裁判官、仲裁人、調停委員、外部専門家、後任担当者、監査担当、買収先のデューデリジェンス担当者は、当時の商談や暗黙の了解を知りません。定義条項は、その背景事情を契約本文に移し、後から証拠として確認できる状態にするための仕組みです。
契約自由を前提にしつつ、強行法規や消費者保護、個人情報、データ契約の限界を確認します。
定義条項は当事者が自由に設計できる部分が大きい一方で、法令上の意味や強行規定を名称変更だけで回避することはできません。ここで確認する表は、定義条項を設計するときに前提となる法領域と、定義で注意すべき読み方を整理したものです。契約上の言い換えで法令上の義務が消えない点を読み取ってください。
| 領域 | 定義条項での注意点 | 典型的な定義語 |
|---|---|---|
| 民法 | 契約自由、契約成立、信義則、公序良俗、定型約款のルールを前提にします。強行法規に反する定義は効力が問題になります。 | 本契約、定型約款、営業日、通知、重大な違反 |
| 定型約款 | 利用規約や会員規約では、組入れ、表示、変更のルールに沿って、ユーザーや本サービスの範囲を透明にする必要があります。 | ユーザー、登録ユーザー、本サービス、投稿データ、禁止行為 |
| 消費者契約 | 事業者の責任やユーザーの同意を過度に狭く・広く定義しても、不当条項として無効となる可能性があります。 | 当社の責任、損害、同意、免責、解約 |
| 個人情報・データ | 法令上の個人情報と、契約上管理したい顧客データや利用ログを階層化して分けます。 | 個人情報、個人データ、顧客データ、利用データ、統計データ |
| フリーランス・業務委託 | 給付内容、報酬額、支払期日、修正対応、追加作業などを曖昧にしないことが重要です。 | 本業務、給付、納品物、検収、報酬、追加作業 |
| AI・データ・システム開発 | 完成、精度、学習、生成物、派生成果、保守、障害など抽象的な語を測定可能に近づけます。 | 学習データ、学習済みモデル、生成物、重大障害、SLA |
法令上の定義語を契約で使う場合は、法令の定義をそのまま引用するのか、契約上の管理対象として上乗せするのか、契約独自の便宜的な定義として使うのかを分ける必要があります。たとえば契約上の「顧客データ」を広く定めても、個人情報保護法上の義務が軽くなるわけではありません。
広すぎる、狭すぎる、測れない、別紙とずれる、という失敗を先に潰します。
定義条項の失敗は、文言の美しさではなく、運用時に境界線が読めないことから発生します。次の比較表は、悪い定義と改善の方向を対比したものです。左列では紛争化する理由を、右列では「含む」「含まない」「基準」「優先順位」をどう補うかを読み取ってください。
| 失敗パターン | 問題点 | 改善の方向 |
|---|---|---|
| 本件業務が広すぎる | 「甲が乙に委託する一切の業務」では、追加要望、仕様変更、会議、障害対応、研修、第三者調整が含まれるか不明です。 | 別紙仕様書に含まれる作業を列挙し、運用保守、追加開発、データ移行後の調査、社内研修など対象外も明記します。 |
| 成果物が曖昧 | 報告書だけなのか、ソースコード、設計書、データ、ノウハウ、学習済みモデル、途中成果まで含むのか不明です。 | 納入対象、権利移転対象、既存資産、第三者素材を分け、別紙納品物一覧と連動させます。 |
| 秘密情報が広すぎる | 「一切の情報」では受領者の管理が難しく、紛争時に秘密として管理されていたかが争われやすくなります。 | 秘密表示、口頭開示の通知期限、性質上秘密と分かる情報、例外情報、証明方法を整理します。 |
| 評価語が測れない | 「合理的」「重大」「速やかに」「相当な期間」だけでは、発生条件や期限が曖昧です。 | 支払遅延30日超、主要機能の5営業日以上の利用不能、是正要求後14日以内の未是正など、判断できる基準を置きます。 |
| 別紙と本文が不整合 | 本文、別紙、個別契約、発注書、仕様書、見積書で用語や納期がずれると、どれを優先するかが問題になります。 | 文書間の優先順位を明示し、案件によって仕様書を優先すべきか本文を優先すべきかを意識的に決めます。 |
典型的な失敗に共通するのは、対象範囲だけを書き、対象外範囲や証明方法を書かない点です。交渉上は「含まない」を書くことに抵抗が出る場合もありますが、対象外を明示したうえで追加作業や変更管理の手続に接続するほうが、当事者双方にとって予見可能です。たとえば重大な違反を定義する場合は、秘密情報・個人情報・顧客データの漏えい、30日を超える支払遅延、主要機能を5営業日以上利用不能にする違反、是正要求後14日以内に是正されない違反など、具体的な基準を置きます。
争点候補の洗い出しから、法的効果、時間軸、別紙接続、履歴保存まで順番に確認します。
定義条項は契約書の冒頭から機械的に書くものではありません。次の時系列は、契約の争点候補を先に洗い出し、定義語の法的効果を確認し、最後に交渉履歴まで残す順番を示します。順番に沿って確認すると、重要でない語ばかり定義して肝心の争点を残す失敗を避けやすくなります。
契約対象、対象外、義務者、権利者、地域、顧客、製品、支払・解除・検収のトリガーを先に確認します。
権利義務を左右する語、法令上の意味とずれ得る語、業界で複数の意味を持つ語、責任や解除を発生させる語を優先します。
成果物、秘密情報、損害などが、納入、検収、権利帰属、保証、返還・削除、賠償にどう影響するかを見ます。
対象範囲だけでなく、追加作業、第三者素材、既存知財、外部サービス、法令改正対応など対象外も明示します。
効力発生日、サービス開始日、営業日、暦日、通知到達日、検収期間、タイムゾーンを確認します。営業日を日本の銀行営業日とし、土日祝日、12月29日から1月3日までを除くなど、読む人が同じ計算をできる形にします。
サービス稼働率、重大障害、是正期間、支払遅延日数など、判断できる基準を置きます。主要機能の全部または大部分が連続2時間を超えて利用不能となる障害など、運用記録で確認できる基準にします。
そのまま引用する語、上乗せする語、契約独自の管理対象として使う語を分けます。
別紙番号、添付の有無、改定手続、本文との優先順位、将来追加する対象の承認方法を確認します。
同じ概念に複数語を使っていないか、別概念に同じ語を使っていないか、未使用定義がないかを確認します。
定義語の交渉メモ、削除・追加の経緯、メール、議事録、変更管理票を残し、後から理由を説明できるようにします。
この手順で特に見落としやすいのは、定義語を単独で確認してしまうことです。「成果物」を広げれば、納入義務、検収、所有権移転、著作権譲渡、保証、対価支払、契約終了時の返還・削除まで広がり得ます。検収完了も、受領日から10営業日以内に合格通知または具体的な不合格通知を出すのか、不通知ならみなし検収とするのかで支払時期が変わります。定義語は必ず本文全体との連動で確認します。
中核意味、対象範囲、除外範囲、時間軸、証明方法までを一体で設計します。
強い定義条項は、中心的な意味だけでなく、対象範囲、除外範囲、時間軸、地域・媒体、判断基準、証明方法、他条項との接続を持ちます。次の一覧は、定義語をレビューするときの構成要素をまとめたものです。抜けている要素がある場合、将来の交渉や紛争でどこが不明確になるかを読み取ってください。
その言葉の中心的な意味を置きます。例として、本サービスはクラウド型在庫管理サービスをいう、などです。
Webアプリ、API、管理画面、関連ドキュメントなど、含まれる範囲を示します。
第三者サービス、既存ツール、汎用ノウハウなど、含まれないものを示します。
契約締結日時点、契約期間中に追加される機能、特定基準日などを定めます。
日本国内向け、日本語版、特定システム環境など、適用される場所や媒体を決めます。
軽微な変更、重大な違反、合理的な措置などを判断する基準を置きます。
書面、電子メール、アクセスログ、合理的な証拠など、誰が何で証明するかを示します。
利用許諾、目的外利用禁止、返還・削除、検収、責任制限など、どの条項に効くかを確認します。
次の表は、主要な定義語ごとの実務ポイントです。読者にとって重要なのは、用語の説明ではなく、各定義語がどのリスクに接続するかです。定義語を広げる場合と狭める場合で、納入義務、情報管理、知財、責任の範囲がどう変わるかを確認してください。
| 定義語 | 確認ポイント | 連動する条項 |
|---|---|---|
| 当事者・関係者 | 役員、従業員、派遣社員、再委託先、専門家、グループ会社を含むかを明確にします。 | 秘密保持、再委託、個人情報、反社 |
| 本業務 | 工程、対象外作業、追加作業、発注者側の協力義務を定義または別紙で整理します。 | 報酬、納期、変更管理、解除 |
| 成果物 | 最終成果物、途中成果物、ソースコード、データ、既存資産、第三者素材を分けます。 | 納入、検収、知財、保証 |
| 検収完了 | 開始日、検収期間、不合格通知、再検収、みなし検収、一部検収を定めます。 | 支払、契約不適合、権利移転 |
| 秘密情報 | 秘密表示、口頭開示、例外情報、強制開示、返還・削除、存続期間を検討します。 | 秘密保持、損害賠償、差止め |
| 顧客データ | 個人情報、利用履歴、アクセスログ、端末識別子、加工・分析データを階層化します。 | プライバシー、委託、削除、監査 |
| 知的財産権 | 既存知財、本成果、改良発明、ノウハウ、実施権、再許諾を分けます。 | 権利帰属、利用許諾、保証 |
| 不可抗力 | 自然災害、感染症、戦争、制裁、輸出規制、クラウド障害など現代的リスクを検討します。 | 免責、納期延長、解除 |
契約類型が変わると、同じ「成果物」や「データ」でも意味とリスクが変わります。次の一覧は、契約類型ごとに重点的に定義すべき語を整理したものです。自社の契約がどの類型に近いかを見て、定義条項で先に固定すべき対象を読み取ってください。
業務範囲、成果物、納期、検収、報酬、追加作業、再委託、知財、秘密情報、個人情報を重点的に定義します。
請負準委任要件定義、変更要求、不具合、障害、保守、SLA、セキュリティインシデント、第三者ソフトウェアを整理します。
開発検収本サービス、ユーザー、アカウント、ユーザーデータ、利用データ、サポート、メンテナンス、サービス停止を分けます。
利用規約データ秘密情報、目的、開示許可先、除外情報、返還・削除、存続期間を管理可能な範囲で定めます。
NDA目的外利用研究テーマ、既存技術、本成果、発明、共同発明、改良発明、研究データ、事業化を定義します。
共同開発知財許諾対象、地域、期間、分野、独占性、再許諾、対象製品、ロイヤリティ対象売上、控除項目を定めます。
許諾監査準拠法、正文、Business Day、Force Majeure、Affiliate、Control、Gross Negligence、Sanctionsを確認します。
英文準拠法業務委託では準委任型と請負型の混在、SaaSではユーザーデータと利用データの分離、M&Aでは重大な悪影響の金額・事業影響基準、ライセンスでは売上や控除項目の定義が特に重要です。契約名ではなく、実態に合わせて重点語を選ぶ必要があります。
業務範囲、データ利用、責任制限、重大な悪影響を、争点が残らない形へ近づけます。
抽象的な定義は一見すると便利ですが、紛争時には循環定義や範囲不明の問題を生みます。次の比較表は、悪い定義のどこが争点になるか、改善例では何を補っているかを対比したものです。改善後の文言では、対象、例外、目的、基準、他条項との接続が補われている点を確認してください。
| テーマ | 悪い定義 | 改善の方向 |
|---|---|---|
| 業務範囲 | 「本業務」とは、甲の依頼するコンサルティング業務をいう。 | 対象部門、目的、ヒアリング、課題整理、月4回までの会議、最終報告書を定め、実装作業、研修、専門意見の提供は対象外とします。 |
| データ利用 | 「データ」とは、本サービスで取得される情報をいう。 | ユーザーデータ、利用データ、統計データを分け、入力データ、アクセスログ、操作履歴、識別不能化後の利用範囲を整理します。 |
| 責任制限 | 当社は、いかなる損害についても責任を負わない。 | 通常損害と除外損害を分け、秘密保持違反、個人情報漏えい、知財侵害、故意・重過失を責任制限の例外として別条項に接続します。 |
| 重大な悪影響 | 「重大な悪影響」とは、対象会社に重大な悪影響を及ぼす事由をいう。 | 金額基準、事業継続上の支障、許認可・主要取引関係への影響を定め、市場全体の変動など除外事由も置きます。 |
良い定義は、長ければよいというものではありません。短くても、判断基準と例外が明確で、本文条項に接続していれば強く機能します。反対に、長い定義でも「等」や「一切」が多く、証明方法や対象外がない場合は、争点を先送りしているにすぎません。
定義条項は、表明保証、解除、損害賠償、準拠法、紛争解決と一体で機能します。
定義条項だけでは紛争は防げません。定義された語が、本文条項でどのように義務、権利、責任、手続へつながるかが重要です。次の判断の流れは、ひとつの定義語を確認するときに、後続条項へどう連動させるかを示しています。順番に見ることで、用語だけ直して本文が追いついていない状態を避けられます。
成果物、秘密情報、損害、重大な違反など、契約効果を左右する語を抽出します。
納入、検収、知財、表明保証、解除、損害賠償、返還・削除に使われているかを確認します。
定義を広げることで、義務、保証、責任、管理負担が過度に拡大しないかを見ます。
既存知財、第三者素材、通常損害、責任制限例外などを分けます。
通知、承認、証明方法、保存期間、変更管理まで接続します。
表明保証では、成果物の定義が広ければ保証範囲も広がります。解除では、重大な違反、信用不安、反社会的勢力、不可抗力の継続、サービス停止などの定義が有効性を左右します。損害賠償では、損害、通常損害、除外損害、第三者請求、責任上限、除外事由を一体で設計します。
専門職ごとの確認視点も異なります。法務担当は本文整合性と社内運用、外部専門家は解釈リスクと法令改正、知財担当は既存知財と新規成果、プライバシー担当は法令上の定義との整合性、会計・税務担当は売上や控除項目、労務担当は名称と実態の一致、内部監査は証跡と社内規程との整合性を見ます。
「いう」「含む」「限る」「含まない」を使い分け、循環定義や主観語を避けます。
定義条項は、同じ内容でも表現の選び方で射程が変わります。次の比較表は、実務で使う表現と注意点を整理したものです。読者にとって重要なのは、例示なのか限定なのか、主観判断なのか客観基準なのか、合意形成の証拠が残るのかを読み分けることです。
| 表現技術 | 使い方 | 注意点 |
|---|---|---|
| いう | 定義の基本形として、対象製品とは別紙1に記載する製品をいう、のように使います。 | 中心的な意味を示すだけでは、例外や時間軸が不足することがあります。 |
| 含む | 対象を拡張または例示したいときに使います。 | 例示列挙なのか、同種のものに限るのかを明確にします。 |
| 限る | 地域、媒体、版、期間などを限定したいときに使います。 | 広げた後に限定するのか、限定した後に例示するのかで意味が変わります。 |
| 含まない | 既存資産、第三者素材、追加作業、外部サービスなど対象外を明確にします。 | 対象外を置いたら、追加合意や変更管理の手続につなげます。 |
| 等を使う場合 | 拡張性を残したいときに使われます。 | 重要な定義では、「その他これらに類するもの」「その他別紙で合意するもの」など判断枠を補います。 |
| 別途協議 | 未確定事項を残すときに使われます。 | 協議だけでは合意成立を保証しません。変更申請書、承認者、費用、納期変更を定義します。 |
| 電子的承認 | 電子契約、メール、ワークフロー、チケットシステムでの承認を扱います。 | 承認権限者、保存期間、記録の特定可能性を示し、証拠性を確保します。 |
循環定義は避ける必要があります。「重大な損害とは重大な損害をいう」という文言は、何も定義していません。金額、停止時間、信用や法令遵守体制への影響など、第三者が判断できる基準を置くことが重要です。
基本構造、範囲、時間、成果物、データ、責任、法令、証拠化をまとめて確認します。
定義条項のレビューでは、文章の自然さだけでなく、抜けている観点を機械的に潰すことが有効です。次の表は50項目を領域別に整理したものです。各行の項目を、契約本文、別紙、仕様書、見積書、運用資料と照合して、定義語の不足や矛盾を見つけてください。
| 領域 | 確認項目 |
|---|---|
| 基本構造 | 1 定義条項があるか。2 重要語が定義されているか。3 不要な定義が多すぎないか。4 定義語が本文で一貫して使われているか。5 未定義の重要語が残っていないか。6 定義語と別紙の用語が一致しているか。7 優先順位条項があるか。8 定義条項と本文条項が矛盾していないか。 |
| 範囲・対象 | 9 契約対象が具体的か。10 対象外が明記されているか。11 追加対象の承認手続があるか。12 対象製品・対象地域・対象顧客が明確か。13 当事者・関係会社・再委託先の範囲が明確か。14 役員・従業員・専門家への開示範囲が明確か。 |
| 時間・手続 | 15 契約期間の始期・終期が明確か。16 営業日・暦日・時間帯が明確か。17 通知の到達時点が明確か。18 検収期間が明確か。19 是正期間が明確か。20 みなし承認・みなし検収の要件が明確か。 |
| 成果物・知財 | 21 成果物の範囲が明確か。22 途中成果物を含むか。23 ソースコード・データ・設計書を含むか。24 既存知財を除外しているか。25 第三者素材を定義しているか。26 改良発明・派生成果を定義しているか。27 権利移転対象と納品対象が一致しているか。 |
| データ・秘密情報・個人情報 | 28 秘密情報の定義が運用可能か。29 口頭開示の扱いが明確か。30 秘密情報の例外があるか。31 個人情報と顧客データを区別しているか。32 利用データ・統計データを定義しているか。33 AI学習利用の可否が明確か。34 契約終了時の返還・削除対象が明確か。 |
| 責任・解除 | 35 重大な違反が定義されているか。36 損害の範囲が明確か。37 責任制限の例外が明確か。38 不可抗力が現代的リスクを含んでいるか。39 解除事由と定義が連動しているか。40 補償対象損害が定義されているか。 |
| 法令・規制 | 41 法令上の定義語を契約上再定義していないか。42 強行法規に反する定義がないか。43 消費者契約法上の不当条項リスクがないか。44 個人情報保護法との整合性があるか。45 下請法・フリーランス法・独禁法上の明示事項と整合するか。46 輸出管理・制裁・反社・贈収賄の定義が社内規程と一致するか。 |
| 証拠化・運用 | 47 承認方法が証拠として残るか。48 別紙改定手続があるか。49 契約管理システムで定義語を検索できるか。50 後任担当者が読んでも意味が分かるか。 |
チェックリストは、すべての項目を重く設計するためのものではありません。重要度の高い取引、金額の大きい取引、個人情報・知財・データを扱う取引、継続的な委託関係では、該当項目を優先して深く確認します。
細かすぎる定義は読まれず、変化に弱くなります。運用で更新できる設計が必要です。
定義条項は重要ですが、過剰に設計すると逆効果です。次の一覧は、細かく書くこと自体が目的化した場合に起きる問題を整理したものです。読者は、明確化と硬直化の違い、定義に書くべき内容と本文条項に置くべき内容の違いを読み取ってください。
100個以上の定義がある契約書では、実務担当者が読まずに運用し、重要な定義が埋もれる危険があります。
サービスやプロジェクトが変化する場合、細かく固定しすぎると契約変更が頻発します。別紙や発注書で更新できる構造が必要です。
相手方の義務や免責を定義の中に埋め込むと、不意打ちになりやすく、読み手にも分かりにくくなります。
法令上の該当性を避けるためのラベル付けは危険です。契約上の名称よりも実態が重視される可能性があります。
企業で継続的に定義条項を強くするには、契約類型ごとのテンプレート、紛争事例の反映、契約管理システムでの検索・比較、法令改正時の点検が必要です。次の時系列は、ひな形を作って終わらせず、過去のトラブルと法令改正を反映し続ける運用を示しています。
NDA、業務委託、システム開発、SaaS、販売代理店、ライセンス、共同研究、M&Aなどで重点語を標準化します。
追加作業費、ソースコード帰属、秘密情報の範囲、障害対応、データ利用で揉めた経験を定義テンプレートへ戻します。
同じ取引先との定義差、古いひな形の残存、グループ会社間の不統一、英文契約との用語対応を確認します。
汎用例はそのまま流用せず、契約類型、交渉力、適用法令に合わせて調整します。
ここでは、実務でたたき台になりやすい定義条項の型を整理します。次の表は、各サンプルが何を固定するためのものかを示しています。文言をそのまま使うのではなく、対象外、別紙、承認方法、法令上の定義との関係を案件ごとに調整する必要がある点を読み取ってください。
| サンプル | 文言の骨子 | 調整ポイント |
|---|---|---|
| 基本形 | 本契約、個別契約、本業務、成果物、営業日を定義し、個別契約または別紙で具体化します。 | 契約書本文、別紙、発注書、個別契約をどこまで本契約に含めるかを決めます。 |
| 業務範囲 | 別紙仕様書に定める調査、設計、開発、テスト、報告および合理的に付随する作業を含めます。 | 追加機能、運用保守、第三者システム改修、法令改正対応、データ移行、現地作業を対象外にするか確認します。 |
| 成果物 | 資料、プログラム、データ、報告書、設計書、マニュアル、図面、画像、電磁的記録を定義します。 | 既存ノウハウ、汎用ライブラリ、テンプレート、開発ツール、第三者素材を除外するかを決めます。 |
| 秘密情報 | 技術上、営業上、財務上、人事上、顧客上その他業務上の情報で、秘密表示または合理的に秘密と認識できるものを含めます。 | 公知情報、適法保有情報、第三者取得情報、独自開発情報を例外にし、証明方法を定めます。 |
| 個人情報・顧客データ | 個人情報は法令上の定義を引用し、顧客データには取引情報、利用履歴、アクセスログ、端末識別子を含めます。 | 統計データ、匿名加工情報、仮名加工情報、AI学習利用の可否を別途整理します。 |
| 変更管理 | 本業務、成果物、仕様、納期、報酬、検収基準、作業体制の追加・削除・修正を変更として定義します。 | 変更申請書に、理由、影響範囲、追加費用、納期変更、責任分担、承認者を記載させます。 |
| 不可抗力 | 自然災害、感染症、戦争、内乱、テロ、法令変更、輸出入規制、制裁、通信回線・クラウド基盤・電力供給の広範な障害を含めます。 | 合理的支配を超えること、合理的注意を尽くしても回避・克服できないことを要件にします。 |
サンプル条項は、契約類型と力関係によって調整幅が大きくなります。たとえば発注者側では成果物を広く取りたい一方、受託者側では既存ノウハウや汎用ツールを除外しないと過度な権利移転につながります。どちらの立場でも、後から説明できる合理的な線引きが必要です。
よくある疑問を一般情報として整理します。個別契約の判断は資料により変わります。
一般的には、契約全体で繰り返し使う重要語は冒頭にまとめると読みやすいとされています。ただし、特定条項でしか使わない語は、その条項内で定義したほうが分かりやすい場合もあります。具体的な構成は、契約類型、条項数、別紙の有無、社内運用によって変わるため、弁護士等の専門家に確認する必要があります。
一般的には、「以下『本業務』という。」のように括弧で定義語を示す方法が多く使われます。長文契約では、定義語を一覧化したり、英文契約ではDefined Termsとして管理したりすることもあります。ただし、可読性を高める方法は契約の体裁や社内ルールで変わるため、実際の運用に合わせて決める必要があります。
一般的には、法令上の定義を引用することは有効な出発点とされています。ただし、法令上の定義はその法令の目的に沿ったものであり、契約上はより広い管理対象を設ける必要がある場合があります。個人情報に該当しないログや統計前データでも、契約上は保護対象にする可能性があります。
一般的には、「等」は禁止されるものではありませんが、重要な定義で使う場合には範囲が争われる可能性があります。「その他これらに類するもの」「その他本業務に合理的に必要なもの」「その他別紙で合意するもの」など、判断枠を補う方法が考えられます。
一般的には、細かさ自体が目的ではなく、将来争われる境界線を明確にすることが目的とされています。相手方が負担を懸念している場合は、含むもの、含まないもの、追加手続、費用調整を分けて、実務上運用できる定義に調整することが考えられます。
一般的には、契約上の優先順位条項によって判断されます。優先順位条項がない場合は、契約全体の文言、作成経緯、具体性、後の合意の有無などが問題になる可能性があります。基本契約、個別契約、発注書、仕様書、見積書の関係は、あらかじめ明示しておく必要があります。
一般的には、一概に有利とはいえません。広すぎる定義は、交渉を長期化させ、運用不能になり、消費者契約や定型約款では不当条項リスクを高める可能性があります。自社に有利な表現だけでなく、紛争時に第三者へ説明できる合理的な定義を目指す必要があります。
公的機関・中立的な実務資料を中心に整理しています。