英文契約書を読み始めたとき、最初に目に入るのが「Definitions」や「Article 1: Interpretation」といったセクションです。「ただの用語集でしょ？」と読み飛ばしてしまうと、後で大きな落とし穴にはまることがあります。定義条項は、契約書全体の解釈を支配する”設計図”とも言える、最優先でチェックすべき箇所です。この記事では、定義条項の役割・構造・読み方を徹底的に解説します。
定義条項とは何か？契約書全体における役割と位置づけ
なぜ定義条項が「契約書の土台」と呼ばれるのか
定義条項（Definitions Clause）とは、契約書内で使用する特定の用語に対して、その意味・範囲・内容を明確に規定するセクションです。一般的な辞書的意味とは異なる意味を持たせることも多く、「この契約においてXXXとは〇〇を指す」という形で記述されます。
重要なのは、定義条項が単なる用語集ではないという点です。たとえば「Products」という用語の定義を変更するだけで、納品義務・保証範囲・損害賠償の対象がすべて連動して変わります。定義1か所の修正が契約全体に波及するため、レビュー時の優先度は最高クラスと理解してください。
定義条項は「後続条項の解釈範囲を直接コントロールする装置」です。ここで定められた言葉の意味が、義務・権利・免責・違約金のすべての条項に自動的に適用されます。
定義条項の典型的な配置パターン（冒頭集約型 vs. 分散型）
英文契約書における定義の配置方法は、大きく2つのパターンに分かれます。それぞれ読み方のコツが異なるため、まずどちらのスタイルかを見極めることが大切です。
| パターン | 特徴 | メリット | デメリット・注意点 |
|---|---|---|---|
| 冒頭集約型（Article 1にまとめる） | 契約書冒頭のArticle 1などに定義を一括記載 | 定義の一覧性が高く、参照しやすい | 条文が長くなりがち。読み飛ばされやすい |
| 分散型（インライン定義） | 各条項内で初出時に定義を記載 | 文脈と定義がセットで確認できる | 定義の全体像が把握しにくい。見落としリスクあり |
大文字表記（Capitalized Terms）のルールを理解する
英文契約書では、定義済みの用語は文中でも大文字（または頭文字大文字）で書かれるのが慣例です。たとえば “the Agreement”、”Confidential Information”、”Effective Date” のように表記されます。
- 大文字で始まる用語を見たら「どこかに定義がある」と判断する
- 必ず定義箇所に戻り、その用語の正確な意味・範囲を確認する
- 定義が見当たらない場合は、交渉・修正が必要なリスクサインと捉える
大文字用語を「なんとなく意味がわかる」と読み飛ばすのは危険です。日常英語と異なる特殊な意味が定義されているケースが頻繁にあります。
定義条項の基本構造を読み解く：英文例で徹底解剖
定義条項を正確に読むには、まず「どの構文パターンが使われているか」を見抜くことが重要です。英文契約書で使われる定義文には大きく3つのパターンがあり、パターンが違えば法的効果も異なります。ここでは英文例とともに、それぞれの違いを丁寧に解説します。
定義文の典型的な構文パターン（’means’型・’includes’型・’excludes’型）
定義文の構文パターンは主に3種類です。それぞれ意味の広さと法的な拘束力が異なるため、まずこの3つを区別できるようにしましょう。
- means（完全定義）：定義された語の意味をその内容に完全に限定する。「Xとは、Yである」という閉じた定義。
- includes（例示定義）：定義された語にYが含まれることを示すが、それ以外の要素を排除しない。意味が広がる可能性がある。
- excludes / does not include（除外定義）：特定の要素を明示的に除外する。スコープを意図的に絞り込む。
[means型]
“Confidential Information” means any information disclosed by one party to the other in written or oral form that is designated as confidential.
[includes型]
“Confidential Information” includes trade secrets, financial data, and customer lists disclosed by either party.
上の2つを比べると、means型は「書面または口頭で開示され、かつ機密と指定されたもの」だけが対象です。一方、includes型は「営業秘密・財務データ・顧客リスト」を例示しているに過ぎず、それ以外の情報も含まれうると解釈されます。自社に不利な広解釈を避けるなら、means型の方が安全です。
スコープを広げる表現 vs. 狭める表現の見分け方
契約書では、スコープを意図的に調整するための定型フレーズが頻出します。特に注意すべきは以下の2表現です。
| フレーズ | 意味・効果 |
|---|---|
| including but not limited to | 例示列挙であり、列挙以外の要素も含む（スコープを広げる） |
| including without limitation | 同上。制限なく含むことを強調した表現（実質的に同義） |
| excludes / does not include | 特定要素を明示的に除外（スコープを狭める） |
[excludes型の例]
“Losses” means all damages, costs, and expenses, but excludes indirect or consequential damages.
excludes型は一見シンプルに見えますが、除外された要素が実際に大きな損害をカバーしていることがあります。「間接損害・結果的損害を除く」という定義があると、損害賠償請求の際に回収できる金額が大幅に制限されるリスクがあります。
インライン定義（条項内定義）の読み方と注意点
定義条項にまとめられていない「インライン定義」も見逃せません。これは、本文の条項中に括弧書きで定義が埋め込まれるスタイルです。
This Agreement (the “Agreement”) shall be governed by the laws of Japan. The parties agree that the term “Effective Date” as used herein means the date first written above.
このように、条文を読み進める中で突然定義が登場します。インライン定義は読み飛ばされやすく、後の条項で重要な意味を持つことが多いため、初読時にマーキングする習慣をつけることが不可欠です。契約書レビューの際は、定義条項だけでなく本文全体を「定義が埋め込まれていないか」という視点でスキャンするようにしましょう。
実務では、定義条項を読む際に「means / includes / excludes」のどれが使われているかを最初に確認し、インライン定義はマーカーや付箋でメモしながら読み進めるのが鉄則です。
実務で頻出する『危険な定義』4パターンと見抜き方
定義条項の「危険」は、一見すると問題なく見える文言に潜んでいます。英文契約書のレビューで見落とされやすい4つの危険パターンを知っておくだけで、リスクの見抜き方が大きく変わります。それぞれの典型例とチェックポイントを順番に確認していきましょう。
定義の範囲が必要以上に広く設定されているケースです。典型例は秘密保持契約（NDA）における “Confidential Information” の定義です。
“Confidential Information” means any and all information disclosed by either party, whether in writing, orally, or by any other means, including but not limited to all oral communications.
「口頭情報すべて」が含まれると、日常の会話や雑談まで秘密保持義務の対象になりかねません。チェックポイントは 「oral」「any and all」「without limitation」 といった無制限を示すキーワードの有無です。
定義が別の定義を参照し、その定義がまた元の定義に戻るという無限ループです。
“Affiliate” means a Related Entity. “Related Entity” means an Affiliate or a Subsidiary.
この構造では “Affiliate” の実質的な意味が確定できません。チェックポイントは定義を辿ったとき、最終的に具体的な内容（数値・行為・属性など）に到達できるかを確認することです。
列挙した項目の後に曖昧な包括条項を加えることで、スコープを無制限に広げるパターンです。
“Business” means the sale of products, provision of services, and any other matter related to the business of the Company.
「any other matter related to」は何でも取り込める魔法の文言です。チェックポイントは 「including without limitation」「any other」「whatsoever」 などの後ろに続く内容が具体的かどうかを確認することです。
同じ用語でも、開示側と受領側で適用範囲が異なるように設計されているケースです。NDAで「秘密情報」の定義が開示側（相手方）の情報には広く、自社の情報には狭く設定されていると、一方的に不利な義務を負わされます。チェックポイントは定義が「どちらの当事者の行為・情報に適用されるか」を当事者ごとに読み比べることです。
- 「any and all」「without limitation」「whatsoever」などの無制限表現が含まれている
- 定義を追いかけても具体的な内容にたどり着かない（循環している）
- 列挙の末尾に「その他一切」型の文言が付いている
- 同じ用語の定義が当事者ごとに読むと意味合いが変わる
これら4パターンは単独で現れることもあれば、複合して登場することもあります。定義条項を読む際は「広すぎないか」「ループしていないか」「抜け穴がないか」「非対称でないか」の4点を常に意識するクセをつけましょう。
定義条項の交渉術：修正提案の具体的な英文フレーズと戦略
定義条項の交渉は、単に「言葉を変える」作業ではありません。定義を1つ修正するだけで、契約全体の責任範囲・費用負担・リスク配分が大きく変わります。ここでは「定義を狭める」「定義を広げる」という2方向の交渉アプローチと、実務で即使える英文フレーズを整理します。
定義を「狭める」交渉：除外規定・例外リストの追加アプローチ
相手方が提示する定義が広すぎる場合、「shall not include」や「provided that」を使って除外規定を追加するのが定石です。典型例は秘密保持契約（NDA）における「Confidential Information」の定義です。相手方の草案が広範な場合、以下のような除外規定を追加することで自社のリスクを限定できます。
【Before】”Confidential Information” means all information disclosed by one party to the other.
【After】”Confidential Information” means all information disclosed by one party to the other, provided that Confidential Information shall not include information that: (i) is or becomes publicly available through no fault of the receiving party; (ii) was rightfully known to the receiving party prior to disclosure; or (iii) is independently developed by the receiving party without use of the disclosing party’s information.
定義を「広げる」交渉：包括的カバレッジを確保するための表現
逆に、自社に有利な定義を広げたい場面では「including but not limited to」や「any and all」を活用します。ライセンス契約で「Products」の定義に将来開発品を含めたい場合は次のように修正します。
【Before】”Products” means the software products listed in Exhibit A.
【After】”Products” means the software products listed in Exhibit A, including but not limited to any updates, upgrades, new versions, and derivative works thereof developed by Licensor during the Term.
定義の修正を提案する際の英文メール・コメント例
契約レビューコメントや修正提案メールでは、丁寧かつ明確な表現を使うことが重要です。以下のフレーズをそのまま活用できます。
- We propose to revise the definition of [X] as follows: [revised text].
- We would like to add the following carve-out to the definition of [X]: “provided that [X] shall not include…”
- The current definition of [X] appears overly broad. We suggest narrowing its scope by adding the following exclusions.
- To ensure comprehensive coverage, we propose to expand the definition of [X] to include future developments.
- Please confirm whether the definition of [X] is intended to cover [specific scenario].
相手方が定義変更を拒否した場合の代替アプローチ
定義の変更が認められなくても、別条項で手当てする代替戦略があります。諦める前に以下の3つのアプローチを検討してください。
- 解釈条項での手当て：「For the avoidance of doubt, the term [X] shall be interpreted to exclude…」と解釈条項（Interpretation Clause）に明記し、定義条項を変えずに解釈の方向性を固定する。
- 個別条項での限定：定義は広いままにして、問題となる条項（例：秘密保持義務条項）の中だけで「for the purposes of this Section X only」と適用範囲を限定する。
- 準拠法・紛争解決条項の見直し：定義の曖昧さが残る場合、自社に有利な解釈がなされやすい準拠法を選択することで、リスクを間接的に軽減する。
代替アプローチはあくまで次善策です。定義条項の修正が理想であることを念頭に置き、交渉の優先順位を下げすぎないようにしましょう。
定義条項を『書く』実践：良い定義・悪い定義の作り方
定義条項を読む力と書く力は別物です。レビューで危険な定義を見抜けるようになったら、次は自分で「良い定義」を書けるようにしましょう。定義の質は契約全体のリスク管理に直結するため、書き方の原則を体系的に押さえておくことが不可欠です。
明確な定義を書くための5つの原則
良い定義には共通する5つの特徴があります。ドラフト時のチェック軸として活用してください。
- 一義性：1つの用語に1つの意味だけを割り当てる。複数の解釈が生じる余地をなくす。
- 完全性：定義のスコープ（範囲の境界）を明確にする。何が含まれ、何が含まれないかを示す。
- 一貫性：契約書全体で同じ概念には同じ用語を使う。表記ゆれを排除する。
- 簡潔性：冗長な修飾語や重複表現を避け、必要最小限の言葉で定義する。
- 整合性：他の条項（支払い条項・解除条項など）と矛盾しない内容にする。
定義の一貫性チェック：契約書全体で用語が統一されているか確認する方法
定義条項を書いたら、必ず契約書全体を通して一貫性の確認を行いましょう。以下のチェックリストを活用してください。
- 定義条項で定義した用語が、本文中で必ず大文字（例: “Territory”）で使われているか
- 本文中に大文字の用語が出てきたとき、必ず定義条項に対応する定義があるか
- 同じ概念を指す用語が複数混在していないか（例: “Agreement” と “Contract” の混在）
- 定義条項で定義した用語が、本文で小文字のまま使われている箇所がないか
- 定義条項に実体的な義務・権利の規定が紛れ込んでいないか
定義条項ドラフト時のよくあるミスと修正例
実務でよく見られる3つのミスパターンを、悪い例・良い例の対比で確認しましょう。
ミス1：定義した用語を本文で小文字で使ってしまう
定義済みの用語を小文字で使うと、「定義された意味で使っているのか、一般的な意味で使っているのか」が曖昧になります。大文字表記は定義済み用語のシグナルとして徹底しましょう。
ミス2：同じ概念を複数の用語で表現してしまう
ミス3：定義条項に実体的な義務を紛れ込ませてしまう
定義条項は「意味を確定する場所」であり、「義務・権利を規定する場所」ではありません。定義の中に義務を紛れ込ませると、その義務が見落とされやすくなり、後の交渉でも修正が困難になります。義務・期限・条件は必ず対応する実体条項（履行条項・支払い条項など）に明記してください。
定義条項レビューの実践チェックリスト：契約書を受け取ったら最初にやること
契約書を受け取ったとき、いきなり本文を読み始めていませんか？定義条項を体系的に整理してから本文を読むだけで、レビューの精度と速度が劇的に上がります。ここでは3つのステップで実践的なレビュー手順を解説します。
STEP1：定義条項を全件リストアップし「定義マップ」を作る
まず定義条項に登場するすべての定義済み用語を一覧化した「定義マップ」を作成します。定義マップとは、定義済み用語・定義箇所（条項番号）・主な使用条項を横断的に整理したシンプルな表です。これを作ることで、後のレビューで「この用語はどこで定義されていたか」を探し回る手間がなくなり、抜け漏れを防げます。
| 定義済み用語 | 定義箇所 | 主な使用条項 | 確認ステータス |
|---|---|---|---|
| Confidential Information | Section 1.1 | Section 3, 5 | 要確認 |
| Products | Section 1.2 | Section 4, 6, 8 | OK |
| Deliverables | Section 1.3 | Section 7, 9 | 要確認 |
| Territory | Section 1.4 | Section 2, 10 | OK |
STEP2：契約類型別に必ず確認すべき重要定義（NDA・売買・ライセンス・業務委託）
契約の種類によって、特に注意すべき定義が異なります。以下のチェックリストを活用してください。
- 【NDA】”Confidential Information” のスコープは適切か／除外規定（公知情報・独自開発など）は明記されているか
- 【売買契約】”Products” の定義が検収対象を網羅しているか／”Defect” の定義が保証条項と整合しているか／”Delivery” の定義（場所・時点・リスク移転）が明確か
- 【ライセンス契約】”Licensed IP” の範囲は特定されているか／”Field of Use” と “Territory” で権利行使できる領域が明確か
- 【業務委託】”Deliverables” と “Work Product” の定義が知的財産の帰属条項と矛盾していないか
STEP3：定義と本文の整合性を3ステップで確認する方法
契約書の本文を通読し、大文字で始まる用語（例: “Products”、”Territory”）をすべて書き出します。これらが定義済み用語の候補です。
STEP1で作成した定義マップと照合し、各用語の定義内容が本文の文脈と整合しているかを確認します。定義が狭すぎる・広すぎると本文の義務範囲がずれます。
定義マップに存在しない大文字用語を発見したら、必ずフラグを立てて相手方に確認を求めます。「定義なき大文字用語」は解釈の余地を生み、紛争の火種になります。
よくある質問（FAQ）
- 定義条項は必ず契約書の冒頭に置かなければいけませんか？
-
法的な義務はありません。ただし、冒頭に集約する「冒頭集約型」が最も参照しやすく、レビューミスを防ぎやすい構成です。特定の条項内でしか使わない用語は、その条項内でインライン定義するハイブリッド型も実務では広く採用されています。
- 英文契約書の定義条項で「means」と「refers to」はどう違いますか？
-
実務上はほぼ同義として使われますが、「means」の方がより完全定義（閉じた定義）のニュアンスが強いとされます。「refers to」は参照・指示のニュアンスがやや強く、解釈の余地が生じる場合があります。重要な用語の定義には「means」を使うのが無難です。
- 定義条項に「shall」を使った義務規定が混入していた場合、どう対処すればよいですか？
-
定義条項内の「shall」は義務規定が紛れ込んでいるサインです。その義務を定義条項から切り出し、対応する実体条項（履行条項・支払い条項など）に移動させることを相手方に提案してください。定義条項はあくまで「意味を確定する場所」であり、義務・権利の規定は実体条項に集約するのが原則です。
- 相手方が提示した定義が曖昧で、どう修正すればよいかわからない場合はどうすればよいですか？
-
まず「この定義は具体的にどのようなケースを想定していますか？」と相手方に確認することが有効です。意図を確認したうえで、means型の完全定義に書き直すか、除外規定（shall not include）を追加して範囲を明確化する方向で交渉を進めましょう。曖昧な定義を残したまま署名することは避けてください。
- 定義条項のレビューに特別なツールや知識は必要ですか？
-
基本的には本記事で解説した「means / includes / excludes の区別」「危険な4パターンの把握」「定義マップの作成」という3つの知識と習慣があれば、実務レベルのレビューは十分に行えます。複雑な国際契約や高額案件では、弁護士や法務専門家への相談を組み合わせることをおすすめします。
