Definitions条項は単なる用語集ではなく、義務、責任、例外、金銭条件、データ利用、知財帰属まで左右する契約リスクの制御装置です。このページでは、定義語を本文条項へ代入し、波及範囲と反転リスクまで確認する読み方を体系化します。
Definitions条項は単なる用語集ではなく、義務、責任、例外、金銭条件、データ利用、知財帰属まで左右する契約リスクの制御装置です。
定義語を「辞書」ではなく、契約全体のリスク配分として読むための入口です。
英文契約のDefinitions条項は、契約全体の適用範囲、義務の主体、責任の限界、補償の対象、情報管理の範囲、支配権変更、M&A、知財、データ、税務、労務、コンプライアンス上のリスクを圧縮しています。Definitions条項の読み方を誤ると、本文条項を正しく読んだつもりでも、実際には義務、責任、禁止事項、例外の射程を読み違える可能性があります。
中心となる考え方は、Definitions条項を契約書の「辞書」として扱うのではなく、契約リスクを割り付けるための「制御盤」として扱うことです。定義語の意味を確認するだけでなく、その定義語が本文条項の効果をどのように拡張し、限定し、迂回し、隠し、または転換しているかを検証します。
次の重要ポイントは、Definitions条項が何を表し、なぜ契約レビューで重要になり、どこを最初に読み取るべきかを整理しています。中央の結論から、以後の本文で扱う実務上の読み方へつなげて確認してください。
定義語を本文条項に代入し、義務の主体、対象、期間、例外、責任上限、補償範囲、社内運用の可否まで確認することで、契約の実質的なリスク配分が見えてきます。
このページは一般的な情報提供を目的としています。準拠法、裁判管轄、契約類型、当事者属性、交渉経緯、業法規制によって結論は変わる可能性があります。個別案件の判断は、資料を整理したうえで弁護士等の専門家に相談する必要があります。
次の三つの観点は、Definitions条項の読み方で最初に押さえるべき入口を表しています。各項目が本文条項にどう接続するかを読み取ることが、契約全体の理解に直結します。
定義は日常語の説明ではなく、権利義務、免責、補償、価格調整、解除、監査、情報管理の範囲を動かします。
Definitions条項だけを読んでもリスクは確定しません。定義語が使われる本文条項へ戻り、効果を代入して読みます。
大文字語、本文条項、契約解釈、日本法との関係を一体で確認します。
Definitions条項とは、契約書で用いられる特定の語句について、その契約における意味を定める条項です。英文契約では、通常、契約の冒頭または第1条付近に置かれ、Definitions、Defined Terms、Interpretation、Definitions and Interpretation などの見出しが付されます。
"Confidential Information" means all non-public information disclosed by or on behalf of Disclosing Party to Receiving Party, whether before or after the Effective Date, in oral, written, electronic or any other form.この例では、Confidential Information という大文字で始まる語が、契約上の定義語として機能します。一般英語としての秘密情報ではなく、この契約で特別に定義された概念として読みます。
NDAで Confidential Information の定義が広ければ秘密保持義務の範囲が広がります。M&A契約で Indebtedness の定義が広ければ、クロージング時の価格調整や補償の対象が広がります。SaaS契約で Customer Data の定義が広ければ、利用権、保管義務、削除義務、漏えい通知義務、監査対応義務が広がります。
そのため、Definitions条項の読み方は「この語は何を意味するか」から始めるだけでは足りません。「この定義語は、契約のどの条項で使われ、誰に、どの行為を、どの範囲で、どの期間、どの例外付きで義務づけ、または免責しているのか」を確認します。
初心者向けには、まずDefinitions条項を読むという説明がされることがあります。この助言は有益ですが、定義語は本文条項に接続されて初めて意味を持ちます。したがって、契約全体の構造、Definitions条項、本文条項、例外、制裁、もう一度Definitions条項という往復が必要です。
次の判断の流れは、Definitions条項と本文条項をどの順番で往復するかを示しています。この順番を守ることが重要なのは、定義だけを読んだときの印象と、本文へ代入した後の責任範囲がずれることがあるためです。
契約類型、別紙、SOW、DPA、注文書、ポリシーの有無を確認します。
大文字語、除外、但書、証明要件、時点、主体を拾います。
義務、権利、免責、補償、解除、価格調整に定義語を代入します。
広すぎる定義、狭すぎる定義、別紙との不整合、社内運用の可否を確認します。
Agreement、Affiliate、Business Day、Confidential Information、Effective Date、Losses、Taxes のように頭文字が大文字の語は、定義語であることが多いです。ただし、見出し、固有名詞、法令名、文頭語、役職名、製品名も大文字になるため、すべてが定義語とは限りません。
契約条項は孤立して読むものではありません。契約の目的、取引類型、当事者の業種・規模・専門性、交渉経緯、定義語が使われる条項の位置、他の定義語との関係、別紙・仕様書・注文書・SOW・DPAとの関係、取引慣行、準拠法上の強行法規・任意規定を合わせて確認します。
文言が明確であれば、まずその文言を尊重します。ただし、定義語だけを切り出さず、契約全体の構造に照らします。複数の意味があり得る場合は、商業的に自然な意味を検討しますが、「その方が合理的だから」という理由だけで明確な定義を無視することはできません。
日本法が準拠法となる場合、契約自由の原則、定型約款、信義則、公序良俗、消費者契約法、個人情報保護法、独禁法、下請法、労働法、業法規制との関係を確認する必要があります。利用規約、SaaS約款、プラットフォーム規約、EC規約、金融・通信・運送・保険・電力等の標準約款では、定義を通じて相手方に不意打ち的な義務加重が生じていないかを検討します。
定義の形式、包含、除外、時間軸、主体、対象概念を分解して確認します。
独立型定義は、Definitions条項にまとめて置かれる形式です。組込型定義は、本文条項の中で初出時に定義される形式です。重要な定義が本文中や別紙に隠れていることも多いため、Definitions条項だけでなく、本文内の括弧定義、別紙、SOW、DPA、注文書、ポリシーも拾います。
"Affiliate" means, with respect to any Person, any other Person that directly or indirectly controls, is controlled by, or is under common control with such Person.
The services described in Schedule 1 (the "Services") shall be provided by Supplier.means 型と includes 型次の比較表は、定義で使われる代表的な英語表現が何を表し、なぜ外延確認で重要かを整理しています。列ごとの違いから、限定列挙なのか例示列挙なのか、交渉で明確化すべき曖昧さがあるのかを読み取ってください。
| 表現 | 基本的な読み方 | 注意点 |
|---|---|---|
X means ... | Xは原則として列挙・記述された内容に限定されます。 | 文脈や準拠法によって読み方が変わる可能性があります。 |
X includes ... | Xは少なくとも列挙内容を含みます。 | 列挙に限られない可能性があり、範囲が開きやすいです。 |
X means and includes ... | 限定と例示が混在します。 | 曖昧になりやすく、交渉で明確化する必要があります。 |
including without limitation | 例示列挙であり、列挙に限定しない趣旨です。 | 補償、禁止、法令遵守、監査権限では広すぎないか確認します。 |
including, but not limited to | 上記と同様に例示列挙として読みます。 | 日本語訳では「含むがこれに限られない」と扱われることが多いです。 |
定義は、含むものを列挙するだけではありません。除外事由、但書、カーブアウト、証明要件が重要です。たとえば Confidential Information の除外事由に can demonstrate が入っていれば、受領者側が公開情報、既知情報、独自開発情報、第三者から適法に受領した情報であることを示す必要があります。
Effective Date、Commencement Date、Closing Date、Term、Initial Term、Renewal Term、Survival Period、Lookback Period は、いつの時点を基準にするかを動かします。契約締結前に開示された情報、クロージング直前の債務状態、過去3年の重要契約など、時間軸の読み落としは典型的な事故原因です。
Party、Company、Seller、Buyer、Customer、Supplier、Affiliate、Representative、Permitted Recipient、Subcontractor、User、Authorized User、Personnel は、誰を含むかを決めます。特に Affiliate と Representative は、共有可能範囲と責任範囲の両方に関わります。
次の比較表は、Definitions条項でよく出る対象概念を領域別に整理しています。どの領域の定義語かを見分けることが重要なのは、情報管理、知財、損害、法令遵守、取引対象、金銭条件では、読み方の焦点がそれぞれ異なるためです。
| 領域 | 典型的な定義語 | 読み方の焦点 |
|---|---|---|
| 情報 | Confidential Information、Personal Data、Customer Data | 取得元、形式、時期、除外、再利用、削除を確認します。 |
| 知財 | Intellectual Property Rights、Background IP、Foreground IP、Improvements | 既存権利、成果物、改良、派生物、利用許諾を確認します。 |
| 損害 | Losses、Damages、Claims、Liabilities | 直接・間接、弁護士費用、第三者請求、罰金を確認します。 |
| 法令 | Applicable Law、Sanctions Laws、Anti-Corruption Laws | 法律だけか、規則、行政指導、ガイドライン、業界基準まで含むかを確認します。 |
| 取引対象 | Products、Services、Deliverables、Specifications | 別紙との整合、変更管理、検収、不適合対応を確認します。 |
| 金銭 | Fees、Taxes、Net Sales、Revenue、Indebtedness | 控除項目、税、返金、価格調整、ロイヤルティを確認します。 |
契約類型の特定から、定義語一覧、本文代入、逆引き、連鎖確認まで進めます。
次の時系列は、Definitions条項を実務で読む順番を表しています。上から下に進むほど、単なる意味確認から、本文条項への代入、隠れた義務、定義間の連鎖へ深まるため、限られた時間でも優先順位を付けやすくなります。
定義語、定義場所、使用箇所、接続される効果、リスク方向、修正案を一覧化し、未使用定義語、未定義語、重複定義、別紙との不整合を見つけます。
金銭、責任、義務範囲、情報・データ、主体、終了・存続、法令遵守に関わる定義語を優先します。
補償、責任制限、秘密保持、データ処理、知財、解除、表明保証、価格調整などの条項へ、定義の範囲を入れて読み直します。
本文の重要条項からDefinitions条項へ戻り、責任上限が実質的に機能するか、例外が広すぎないかを確認します。
shall、must、may not、provided that、subject to、deemed などが定義内にある場合、意味定義を超えた効果が含まれる可能性があります。
複雑な契約では、定義の中に別の定義語が入ります。階層が深いところで読み落としが起きやすいため、ツリー状に整理します。
次の表は、レビュー時に作る定義語一覧の基本項目を表しています。各列が重要なのは、定義の意味だけでなく、どの条項に接続し、自社に有利か不利か、どのように修正するかまで一体で判断するためです。
| 項目 | 内容 |
|---|---|
| 定義語 | Affiliate、Losses などを記録します。 |
| 定義場所 | Definitions条項、本文、別紙、SOW、DPAなどを記録します。 |
| 使用箇所 | 条番号、別紙番号、注文書、ポリシーなどを記録します。 |
| 接続される効果 | 義務、権利、免責、補償、解除、価格調整などを整理します。 |
| リスク方向 | 自社に有利、不利、中立、不明のいずれかを記録します。 |
| 修正案 | 削除、限定、例外追加、別条項化などを検討します。 |
Supplier shall indemnify Customer from and against all Losses arising out of any Claim relating to the Services.この条項では、Losses が弁護士費用、調査費用、罰金、間接損害、逸失利益を含むか、Claim が第三者請求だけか当事者間請求も含むか、Services がSOW上の業務だけか付随業務、助言、サポート、ベータ機能、第三者サービスを含むかを確認します。Customer が契約当事者だけか、関連会社、顧客、エンドユーザーまで含むかも重要です。
"Permitted Purpose" means the evaluation of a potential business relationship between the Parties, provided that Receiving Party shall not use Confidential Information for any competitive analysis or reverse engineering.この例では、provided that 以下に禁止義務が入っています。本文の秘密保持条項だけを読んでいると見落とす可能性があります。義務や禁止は本文条項へ移すと、社内展開と履行管理がしやすくなります。
Company Material Adverse Effect
├─ Effect
├─ Business
├─ Company
└─ Subsidiaries
└─ Control複雑なM&A契約では、Company Material Adverse Effect の中に Effect、Business、Company、Subsidiaries が入り、さらに Subsidiaries が Control に接続することがあります。階層を追うことで、重大な悪影響の判断対象がどこまで広がるかを確認できます。
主体、情報、損害、法令、データ、知財、M&A、税務の定義を優先して確認します。
次の一覧は、Definitions条項で特に重点確認すべき定義語を表しています。領域ごとに責任、価格、情報管理、知財、税務へ波及するため、各項目がどの本文条項に接続しているかを読み取ってください。
Affiliate企業グループの範囲を決めます。利益を受ける主体だけでなく、義務や違反責任を負う主体に含まれるかを確認します。
主体責任範囲Control議決権50%超だけでなく、取締役選任権、契約上の支配、実質支配を含むかを確認します。
主体Business Dayどの国・地域の銀行営業日か、祝日、電子送信、通知到達、支払期限、タイムゾーンとの関係を確認します。
期限Confidential Information開示者、受領者、口頭情報、締結前情報、派生情報、秘密表示、除外事由、証明責任、存続期間を確認します。
情報NDARepresentatives役員、従業員、専門家、投資家、金融機関、関連会社、再委託先を含むかを確認し、共有可能範囲と違反責任を分けて読みます。
共有範囲Applicable Law法律、政令、省令、規則、命令、行政ガイドライン、業界基準、証券取引所規則、域外適用法を含むかを確認します。
法令遵守次の比較表は、補償・責任条項で中心になる定義語を並べています。似た語でも対象範囲が異なるため、どの語が第三者請求、当事者間請求、偶発債務、費用、罰金まで含むかを読み取ることが重要です。
| 定義語 | 典型的な意味 | 読み方の焦点 |
|---|---|---|
Losses | 損失、損害、費用、債務等を表します。 | 弁護士費用、調査費、罰金、間接損害を含むかを確認します。 |
Damages | 損害を表します。 | 法的損害に限定されるか、広い経済損失を含むかを確認します。 |
Claims | 請求、訴訟、手続を表します。 | 第三者請求だけか、当事者間請求も含むかを確認します。 |
Liabilities | 債務、責任を表します。 | 確定債務だけか、偶発債務も含むかを確認します。 |
Personal Data は、GDPR、CCPA/CPRA、日本の個人情報保護法、その他地域法に合わせて定義が変わります。Customer Data は、顧客がサービスに投入するデータ全般を指すことが多く、個人情報に限られません。ログ、派生データ、集計データ、AI学習、削除・返還義務、漏えい通知、DPAとの整合性を確認します。
Intellectual Property Rights では、特許、著作権、商標、意匠、営業秘密、ノウハウ、データベース権、半導体回路配置権、出願権、登録権、更新権、将来権利、世界中の権利を含むかを確認します。Background IP、Foreground IP、Developed IP、Improvements、Derivative Works との関係が重要です。
Material Adverse Effect は、対象会社または事業に重大な悪影響を与える事象を指すことが多いですが、一般経済状況、業界全体の変化、法令変更、会計基準変更、戦争、災害、パンデミック、契約公表による影響などのカーブアウトが重要です。さらに、対象会社に不均衡に重大な影響がある場合にカーブアウトから除外される例外の例外も確認します。
Knowledge は、誰の知識か、実際の知識だけか、合理的調査をすれば知り得た知識も含むかを確認します。Taxes は、所得税、法人税、消費税、VAT、GST、売上税、源泉税、関税、印紙税、加算税、延滞税、利息、罰金、源泉徴収税の負担、税法変更時の価格調整まで確認します。
NDA、業務委託、SaaS、ライセンス、M&A、共同開発、販売代理店、労務で重点語が変わります。
次の一覧は、契約類型ごとに重点確認すべき定義語と読み方の焦点を表しています。契約類型によって危険な定義語は変わるため、自社の取引実態に近い列から重点的に確認してください。
Confidential Information、Disclosing Party、Receiving Party、Representatives、Permitted Purpose、Residuals、Exclusions を確認します。秘密情報の範囲、利用目的、共有可能者、除外情報、返還・削除、存続期間、差止救済が中心です。
Services、Deliverables、Specifications、Acceptance Criteria、Change Request、Fees、Expenses、Personnel、Subcontractor を確認します。業務範囲、検収、知財帰属、支払条件、不適合対応が不安定にならないかを見ます。
Service、Subscription、Authorized User、Customer Data、Usage Data、Aggregated Data、Personal Data、Security Incident、Service Level、Downtime、Maintenance Window を確認します。AI機能がある場合は Input、Output、Training Data、Model Improvement も重要です。
Licensed IP、Licensed Product、Field、Territory、Net Sales、Royalties、Improvements、Sublicensee、Affiliate、Patent Rights を確認します。Field と Territory はライセンスの経済的範囲です。
Purchase Price、Closing、Closing Date、Working Capital、Indebtedness、Cash、Transaction Expenses、Material Adverse Effect、Knowledge、Permitted Liens、Ordinary Course of Business、Tax、Losses を確認します。Definitions条項が価格そのものになることがあります。
Background IP、Foreground IP、Project IP、Joint IP、Improvements、Results、Confidential Information、Purpose、Field を確認します。試作品、データ、ノウハウ、発明、ソフトウェア、失敗データまで含むかが重要です。
Products、Territory、Customers、Channel、Exclusive、Net Sales、Competing Products、Minimum Purchase Commitment を確認します。オンライン販売や越境ECでは、販売地、出荷先、利用地域の違いが問題になります。
Cause、Good Reason、Confidential Information、Company Property、Inventions、Restricted Period、Restricted Territory、Competing Business、Solicit を確認します。競業避止、非勧誘、職務発明、解除に関する合理性を見ます。
未定義、未使用、重複、循環、隠れた義務、擬制、翻訳ずれを確認します。
次の一覧は、Definitions条項に潜む典型リスクを表しています。各項目は契約解釈や履行管理の不安定さにつながるため、自社に不利な条項だけでなく、ドラフト全体の品質を読む手掛かりとして確認してください。
本文で大文字語が使われているのに定義がない場合、解釈争いが生じます。金銭、解除、補償、検収、SLA、表明保証に関わる語は明確化します。
定義があるのに本文で使われていない語は、削除された条項の名残である可能性があります。契約全体の整合性に疑問を生じさせます。
同じ語が本体契約、別紙、DPA、SOW、注文書で異なる意味に定義されると、優先順位がなければ紛争化しやすくなります。
Services をSOWで定義し、SOWを Services の説明文書として定義するだけでは、実質的な内容が確定しません。
shall、must、shall not などが定義内にあると、営業・開発・運用部門へ伝わりにくい義務が生じます。
including without limitation が補償、責任、禁止事項、法令遵守、監査権限に関わると、外延が過度に広くなる可能性があります。
deemed による擬制実際にはそうでないものを契約上そう扱う表現です。開示主体、通知到達、承認、検収、違反、損害発生、知識の帰属が変わることがあります。
英文が正文の場合、日本語訳は理解の補助です。Affiliate、Control、Indemnify、Losses などは日本語の感覚だけで読まないようにします。
次の比較表は、英文契約の定義語を日本語訳で読むときの注意点を表しています。安易な訳語だけで判断すると、会社法上の概念、日本法上の損害、努力義務の水準と混同しやすいため、右列の焦点を読み取ってください。
| 英語 | 安易な訳 | 注意点 |
|---|---|---|
Affiliate | 関連会社 | 日本の会社法上の関係会社と一致しないことがあります。 |
Control | 支配 | 議決権支配か実質支配かを確認します。 |
Indemnify | 補償する | 日本法上の損害賠償、保証、免責とは完全一致しません。 |
Losses | 損害 | 費用、債務、弁護士費用、罰金を含む場合があります。 |
Best Efforts | 最善努力 | 準拠法と文脈により義務水準が変わります。 |
Material | 重要な | 重要性の基準が未定義だと争点化します。 |
Reasonable | 合理的な | 誰から見て合理的かが問題になります。 |
次の比較表は、Definitions条項レビューで確認する項目を全体、内容、交渉の三つに分けています。分類ごとに見ることで、文言の整合性、定義の外延、実際の交渉方針を切り分けて判断できます。
| 分類 | 確認する項目 |
|---|---|
| 全体 | Definitions条項、Interpretation条項、本文内定義、別紙・SOW・注文書・DPA・ポリシー内定義、大文字・小文字の一貫性、未定義語、未使用定義語、重複定義、本文条項での効果を確認します。 |
| 内容 | means と includes の使い分け、除外事由、但書、証明責任、時間軸、地理的範囲、主体範囲、定義内の義務、法令・ガイドライン・業界基準の範囲、金銭定義、責任制限条項との整合性を確認します。 |
| 交渉 | 定義を狭めるか、本文条項で例外を入れるか、定義語を分割するか、定義内の義務を本文へ移すか、取引実態と合うか、自社が履行管理できるか、グループ会社や外部専門家へ義務を伝達できるかを確認します。 |
定義を狭める、分割する、本文へ移す、条項限定にする、優先順位を明確にする方法です。
次の一覧は、Definitions条項を交渉で修正するときの代表的な方法を表しています。どの方法を選ぶかが重要なのは、定義だけを直すと契約全体に波及し、本文だけを直すと同じ定義語の他の使用箇所が残るためです。
Confidential Information を非公開情報、目的関連情報、秘密表示または合理的に秘密と理解される情報に限定するなど、外延を管理可能な範囲に整えます。
Customer Data を Customer Content、Customer Personal Data、Usage Data、Aggregated Data、Anonymized Data に分け、削除義務、機密保持、AI学習、統計利用、漏えい通知を分けて設計します。
定義内の shall や禁止文言を本文条項へ移すことで、契約の可読性と履行管理を高めます。
For purposes of Section 8 only のように、補償専用の Indemnifiable Losses や責任制限専用の Excluded Claims を置くと、意図しない波及を防げます。
MSA、Order Form、SOW、DPA、SLA、ポリシーで定義が衝突する場合に、どの文書の定義が優先するかを定めます。
整合性Before:
"Confidential Information" means all information disclosed by Disclosing Party.
After:
"Confidential Information" means non-public information disclosed by Disclosing Party to Receiving Party in connection with the Purpose, which is marked confidential or would reasonably be understood to be confidential given the nature of the information and circumstances of disclosure.この修正により、公開情報、目的外情報、偶然得た情報、秘密性の低い情報を除外しやすくなります。もっとも、秘密表示の要否や口頭情報の扱いは、実際の開示運用と整合させる必要があります。
次の一覧は、Definitions条項を読む専門職ごとの視点を表しています。同じ定義語でも、紛争時の主張可能性、社内運用、コンプライアンス、知財、プライバシー、会計・税務、内部統制、経営判断のどこに影響するかが異なるため、関係部門の読み方を重ねて確認してください。
契約解釈、責任制限、補償、紛争化時の主張可能性、準拠法、裁判管轄、証拠構造から読みます。
法的有効性だけでなく、社内で履行可能かを確認します。24時間通知、委託先管理、海外営業日基準などの運用負荷を見ます。
テンプレート管理、定義語の標準化、契約類型別プレイブック、リスクスコアリングを意識します。
Applicable Laws、制裁、輸出管理、汚職防止、行動規範、取引制限対象者の定義を確認します。
既存技術、成果物、改良、派生物、利用許諾、Field、Territoryが自社の事業自由度を制限しないかを見ます。
Personal Data、Customer Data、Controller、Processor、Subprocessor、Security Incident、越境移転を確認します。
Working Capital、Cash、Indebtedness、Transaction Expenses、Taxes、Knowledge を重点的に確認します。
Territory、Field、Customer、Competing Business、Change of Control、Exclusivity を事業戦略と資本政策から読みます。
NDA、SaaS、M&A、ライセンスの一文を、定義語から読み直します。
Receiving Party shall not disclose Confidential Information to any third party except to its Representatives who need to know such information for the Permitted Purpose.この条項では、Confidential Information の範囲、third party が関連会社を含むか、Representatives が誰か、need to know の判断者、Permitted Purpose の範囲、代表者の違反について受領者が責任を負うかを確認します。潜在的投資家や競合会社への共有を制限したい場合、定義と本文の両方を確認します。
Provider may use Customer Data to provide, maintain, improve and develop the Services.Customer Data に個人情報、入力データ、ログ、成果物、機密情報が含まれる場合、ベンダーの利用権は広くなります。improve and develop にAIモデル学習や新製品開発が含まれるかも問題になります。利用目的を顧客へのサービス提供・サポートに限定し、集計データの改善利用を別定義に分ける方法があります。
Purchase Price shall be reduced by the amount of Indebtedness outstanding as of immediately prior to Closing.Indebtedness が買収価格に直結します。銀行借入、社債、ファイナンスリース、未払利息、未払ボーナス、退職給付債務、未払税金、関連者間債務、保証債務、デリバティブ債務、期限前返済手数料、クロージングに伴う解約違約金を含むかを確認します。
Licensee shall pay Licensor royalties equal to 5% of Net Sales of Licensed Products in the Territory.この一文では、Net Sales、Licensed Products、Territory の三つを読みます。返品、値引き、税、輸送費、保険、リベート、関連者間取引、バンドル販売、無償提供、改良品、後継品、組込品、販売地、出荷地、使用地、顧客所在地を確認します。ロイヤルティ条項では、Definitions条項が収益分配の計算式になります。
単数・複数、including、優先順位、参照先文書の固定性を確認します。
英文契約では、Definitions条項とInterpretation条項が一体化していることが多いです。単数は複数を含み、複数は単数を含む、性別を示す語は他の性別を含む、見出しは便宜上のもので解釈に影響しない、including は without limitation を意味する、or は文脈により包括的に読む、法令への参照は改正後法令を含む、契約・文書・ポリシーへの参照は改訂版を含む、という規定が置かれることがあります。
including ルールInterpretation条項で including means including without limitation と定められている場合、本文中の including はすべて例示列挙として働く可能性があります。ある定義で including としか書かれていなくても、Interpretation条項によって範囲が広がることがあります。
MSA、Order Form、SOW、DPA、SLA、Support Policy、Acceptable Use Policy、Security Addendum、Data Transfer Addendumがある場合、どの文書の定義が優先するかが重要です。クラウド契約ではオンラインポリシーが随時変更されることもあります。as updated from time to time と書かれていれば、相手方が後日ポリシーを変更できる可能性があります。
Policy や Documentation が定義される場合、それが契約締結時点の文書を指すのか、将来更新される文書を指すのかを確認します。as of the Effective Date、as updated from time to time、as made available at [URL]、subject to change upon notice、provided that such updates shall not materially reduce the protections といった文言は、一方的変更リスクに関わります。
日本語の感覚、契約管理、社内展開、外部専門家への依頼方法を整理します。
日本語では「関係会社」「秘密情報」「損害」「合理的努力」などの語が柔軟に読まれがちです。しかし英文契約では、定義語が本文へ機械的に代入される構造が強く働きます。「ここまでは含まれないはず」と考える前に、定義の文言と本文への接続を確認します。
次の一覧は、契約締結後に社内の契約管理へ残すべき定義リスクを表しています。締結後の運用部門が定義内容を知らないと、通知期限、データ利用、秘密情報管理、補償対象、解除原因を誤る可能性があるためです。
定義上の関連会社がどこまで含まれるかを登録し、グループ会社の利用、義務、違反責任を管理します。
秘密情報の範囲、返還・削除義務、存続期間を登録し、営業・開発・CSへ伝達します。
顧客データ、個人情報、ログ、集計データ、AI学習利用の可否を管理します。
Business Dayの地域、タイムゾーン、通知到達、支払期限、解除通知期限を登録します。
Material Breach、Cause、Survival Period の範囲を登録し、更新・解除判断に使います。
Affiliate を「関連会社」とだけ訳すと、日本法上の関連会社と誤解される可能性があります。Losses を「損害」とだけ訳すと、費用や弁護士費用を含むことが伝わりません。社内向けには、英語の定義語を残したうえで、実務上の意味を説明するのが有効です。
Representatives は、当社の役員・従業員だけでなく、弁護士、会計士、コンサルタント、親会社、関連会社、外部委託先を含むことがあります。これらの者にNDA情報を共有する場合、当社が違反責任を負う可能性があります。レビューを依頼する場合、Definitions条項の確認だけを依頼するのではなく、どの業務で、どの社内部門が、どのように契約を履行するかを伝えることが重要です。SaaS契約なら、ログをサービス改善に使うか、AI学習に使うか、サポート部門が顧客データを閲覧するか、海外子会社に処理を委託するかによって、Customer Data や Usage Data の読み方が変わります。
5W1H、代入・波及・反転、契約後の運用、品質評価で確認します。
次の表は、定義語を5W1Hで分解する方法を表しています。観点ごとに質問へ変換することで、誰が対象か、何が対象か、いつ・どこで・なぜ・どのように適用されるかを漏れなく確認できます。
| 観点 | 問い |
|---|---|
| Who | 誰が含まれるか。関連会社、代表者、再委託先、顧客、エンドユーザーは含まれるかを確認します。 |
| What | 何が対象か。情報、データ、製品、サービス、損害、権利、法令はどこまで含むかを確認します。 |
| When | いつの時点か。契約締結前、効力発生日後、クロージング前、存続期間中かを確認します。 |
| Where | どの地域か。国、州、営業日、販売地、利用地、データ所在地はどこかを確認します。 |
| Why | どの目的のためか。評価、提供、改善、販売、研究、法令遵守かを確認します。 |
| How | どの方法で適用されるか。通知、証明、承認、合理的努力、監査、削除かを確認します。 |
次の三つの項目は、Definitions条項を実務で読むときの思考順序を表しています。定義を本文へ入れ、どこへ影響するかを見て、自社に有利に見える広さが別場面で不利に働かないかを読み取ります。
定義語を本文条項へ入れて読みます。補償、責任制限、秘密保持、データ処理、知財、解除、価格調整で特に重要です。
定義を修正した場合、どの条項、別紙、SOW、DPA、注文書、社内運用へ影響するかを確認します。
この定義どおりに社内で分類できるか、データを分別できるか、通知期限を管理できるか、関連会社や委託先を管理できるか、損害・費用を証明できるか、ロイヤルティや価格調整を計算できるかを確認します。契約は読めるだけでは足りず、履行できる定義である必要があります。
良いDefinitions条項は、一貫性があり、必要十分で、本文条項と接続し、例外と証明責任が明確で、社内運用でき、準拠法・業法・取引実態と整合し、別紙や関連契約と矛盾しません。悪いDefinitions条項は、定義語が過剰で、未使用定義語が多く、似た定義語が乱立し、本文内に重要義務が隠れ、例示表現が多用され、時点・地域・主体が不明で、別紙・SOW・DPAと矛盾し、自社の履行体制と合っていません。
契約レビュー時に確認事項を再現可能にするための20項目です。
次の表は、契約レビュー時にそのまま使える簡易レビューシートです。20項目を順番に埋めることが重要なのは、Definitions条項の読み方を属人的な経験ではなく、再現可能な確認手順に変えるためです。
| No. | 確認項目 | 記入する内容 |
|---|---|---|
| 1 | 契約類型 | NDA、SaaS、M&A、業務委託などを記入します。 |
| 2 | 準拠法 | 日本法、ニューヨーク法、英国法などを記入します。 |
| 3 | 定義語総数 | Definitions条項と本文内定義の数を記入します。 |
| 4 | 高リスク定義語 | 金銭、責任、情報、知財、主体、法令遵守に関わる語を記入します。 |
| 5 | 未定義語 | 本文で使われる大文字語のうち、定義がない語を記入します。 |
| 6 | 未使用定義語 | 定義されているのに本文で使われない語を記入します。 |
| 7 | 重複・矛盾定義 | 本体、別紙、DPA、SOW、注文書で意味がずれる語を記入します。 |
| 8 | 本文内定義 | 括弧定義や条項内で定義された語を記入します。 |
| 9 | 別紙・SOW・DPA内定義 | 関連文書内の定義を記入します。 |
| 10 | 金銭に影響する定義 | Fees、Taxes、Net Sales、Indebtednessなどを記入します。 |
| 11 | 責任・補償に影響する定義 | Losses、Claims、Liabilities、Damagesなどを記入します。 |
| 12 | 情報・データに影響する定義 | Confidential Information、Personal Data、Customer Dataなどを記入します。 |
| 13 | 知財に影響する定義 | Background IP、Foreground IP、Improvementsなどを記入します。 |
| 14 | 関連会社・第三者に影響する定義 | Affiliate、Representatives、Subcontractor、Authorized Userなどを記入します。 |
| 15 | 社内運用上の懸念 | 通知期限、データ分類、外部共有、監査対応などを記入します。 |
| 16 | 修正必須事項 | 受け入れにくい定義、本文との矛盾、法令上の懸念を記入します。 |
| 17 | 交渉可能事項 | 限定、例外追加、条項限定、定義分割の候補を記入します。 |
| 18 | 受容可能事項 | リスクを把握したうえで受け入れられる定義を記入します。 |
| 19 | 外部専門家確認事項 | 準拠法、業法、税務、知財、個人情報の確認事項を記入します。 |
| 20 | 事業部門への確認事項 | 取引実態、利用データ、納品物、販売地域、委託先管理を記入します。 |
一般的な制度・実務上の考え方として整理しています。
一般的には、最初に一読することは有益とされています。ただし、Definitions条項だけを単独で精読するより、本文条項との往復が重要です。高リスク定義語を優先し、本文に代入しながら読む方法が実務的です。具体的な対応は、契約類型や交渉状況に応じて弁護士等の専門家に相談する必要があります。
一般的には、必ず定義語とは限らないとされています。見出し、固有名詞、法令名、文頭語も大文字になります。ただし、契約本文中で不自然に大文字化されている語は、定義語である可能性があります。定義が見つからない場合は、未定義語として確認する必要があります。
including without limitation は常に危険ですか。一般的には、常に危険というわけではないとされています。例示列挙として合理的な場合もあります。ただし、責任、補償、禁止、データ利用、法令遵守、監査権限に関わる定義で使われる場合、範囲が過度に広くならないか確認する必要があります。
一般的には、必ずしも悪い契約とは限らないとされています。M&A、金融、ライセンス、SaaS、建設など複雑な契約では、多数の定義語が必要になることがあります。ただし、定義語が多いほど、読み手の負担、履行管理の負担、矛盾リスクが高まる可能性があります。
一般的には、定義の修正は本文条項全体に波及するとされています。本文の意図と合う場合は効率的ですが、特定条項だけに影響させたい場合は、条項限定の定義にするか、本文側で例外を設ける必要があります。具体的な修正方針は契約全体を確認して判断します。
一般的には、英文契約の構造として英米法系の定義設計を理解する必要があります。ただし、法的効力は準拠法によって判断されます。日本法準拠の場合は、民法、商法、会社法、消費者契約法、個人情報保護法、独禁法、下請法、労働法、各業法との関係を検討する必要があります。
一般的には、未定義語、未使用定義語、重複定義、用語の不一致、本文使用箇所の抽出などは自動化しやすいとされています。一方、定義が事業実態に合うか、価格条件に与える影響、準拠法上の有効性、社内運用可能性、交渉上の優先順位は、人間の専門判断が必要です。
言葉の意味ではなく、現実のビジネスリスクの割付けを読みます。
Definitions条項の読み方は、英文契約レビューの基礎でありながら、高度な技術でもあります。定義語は契約全体を横断し、本文条項の意味を変え、義務、責任、権利、例外、金銭条件、運用負荷を左右します。
最終的に、Definitions条項の読み方とは、言葉の意味を読む技術ではなく、契約がどのように現実のビジネスリスクを割り付けるかを読む技術です。企業法務に関わる場合、Definitions条項を契約書の入口ではなく、契約全体を制御する中枢として扱うことが重要です。
契約解釈、平易なドラフティング、定型約款、国際売買に関する資料です。