Media > AI活用ユースケース > 法務 > 特許・技術のライセンス交渉の前に、過去の実施許諾契約と交渉記録から技術分野・地域・独占性の近い契約を探し、料率・一時金・条件の幅を根拠付きで示す

特許・技術のライセンス交渉の前に、過去の実施許諾契約と交渉記録から技術分野・地域・独占性の近い契約を探し、料率・一時金・条件の幅を根拠付きで示す

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

特許・技術のライセンス交渉の前に、過去の実施許諾契約と交渉記録から、技術分野・地域・独占性の近い契約を探します。料率・一時金・最低実施料の幅と、その条件に至った経緯を、契約書と記録の該当箇所付きで交渉の担当者に示します。

サマリー
生成AI
ChatGPT/Claude/Gemini
AIサービス
Azure AI/Google Vertex AI/OpenSearch
対象業界
IT・SaaS/医療/製造
対象部門
法務/知財
対象業務
情報検索/比較検討
主な課題
判断に時間がかかる/属人化している/情報が見つからない
AIで行う処理
検索(RAG)
主な効果
判断支援/属人化解消/検索時間短縮
導入難易度
★★★★☆
実装レベル
本格構成
費用感
RAG・個別開発(大)
人間の確認
条件付き
現在工数
60h/月
AI導入後
16h/月
想定削減
73%
年間削減
528h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 交渉の担当者が、対象の技術・地域・独占性・相手の区分をメモにまとめる
  2. 契約管理の台帳で、相手方の業種や契約名から近そうな契約を探す
  3. 当たった契約書を開き、料率・一時金・最低実施料・独占性・地域・期間・サブライセンス・改良技術の条項を読む
  4. 案件のフォルダで交渉記録を開き、最初の提示から合意までの経緯を読む
  5. 読んだ内容を比較表にまとめ、交渉の方針の稟議に添える
導入後(After)
  1. 自動契約管理の仕組みに新しい契約書が登録されると、生成AIが料率・一時金・独占性などの条件を原文の引用付きで切り出す
  2. 人知的財産部の担当者が切り出された値を契約書と見比べて確かめ、確定する
  3. 自動確定した値と、契約書・交渉記録の本文を、契約の索引に入れる
  4. 人交渉の担当者が、対象の技術の概要・技術分野・地域・独占性・許諾の向き・相手の区分を依頼の画面に入れる
  5. 自動契約の索引を、技術の意味の近さ・技術分野の語の一致・地域と独占性の一致を組み合わせて検索する
  6. 自動上位の契約を、料率の基準(売上高の何%か、1個あたりか)と独占性・地域で分け、比べられる組ごとに料率と一時金の幅を出す
  7. 自動生成AIが、各契約が近い理由と、交渉記録から条件に至った経緯を、引用付きでまとめる
  8. 人交渉の担当者が根拠の箇所を開いて確かめ、交渉の方針を決める
  9. 人法務部が、引き継ごうとする条件に審査の要るものがないかを見る
各工程の詳しい説明を読む
  1. 交渉の担当者が、対象の技術・地域・独占性・相手の区分をメモにまとめる
  2. 契約管理の台帳で、相手方の業種や契約名から近そうな契約を探す
  3. 当たった契約書を開き、料率・一時金・最低実施料・独占性・地域・期間・サブライセンス・改良技術の条項を読む
  4. 案件のフォルダで交渉記録を開き、最初の提示から合意までの経緯を読む
  5. 読んだ内容を比較表にまとめ、交渉の方針の稟議に添える

(a)近い契約が見つからない。 台帳の契約名は「技術実施許諾契約書」のような書き方で、どの技術の契約かは開かないと分かりません。 担当者は、自分が関わった契約か、先輩から聞いた契約を起点に探します。

(b)数字の比べ方が人によって違う。 売上高の3%の契約と製品1個あたり50円の契約、一時金が大きい代わりに料率が低い契約を、同じ表にどう並べるかは担当者次第です。 稟議を見る側は、どの契約と比べたのかが分かりません。

(c)経緯が引き継がれない。 「この相手には最初に高めに出したら、独占を外す代わりに下げてきた」という経緯は、交渉記録を読み込んだ担当者の頭の中にあります。 異動があると、次の担当は同じ相手との交渉をゼロから始めます。

(d)比較表づくりに時間がかかる。 1件の依頼で契約書を5〜10件読み、1時間半ほどかかります。 相手の提案に早く返したい場面ほど、この時間が交渉の遅れになります。

準備として、契約を結ぶたびに一度だけ行うこと

  1. 【自動】 契約管理の仕組みに新しい契約書が登録されると、生成AIが料率・一時金・独占性などの条件を原文の引用付きで切り出す
  2. 【人】 知的財産部の担当者が切り出された値を契約書と見比べて確かめ、確定する
  3. 【自動】 確定した値と、契約書・交渉記録の本文を、契約の索引に入れる

交渉のたびに行うこと

  1. 【人】 交渉の担当者が、対象の技術の概要・技術分野・地域・独占性・許諾の向き・相手の区分を依頼の画面に入れる
  2. 【自動】 契約の索引を、技術の意味の近さ・技術分野の語の一致・地域と独占性の一致を組み合わせて検索する
  3. 【自動】 上位の契約を、料率の基準(売上高の何%か、1個あたりか)と独占性・地域で分け、比べられる組ごとに料率と一時金の幅を出す
  4. 【自動】 生成AIが、各契約が近い理由と、交渉記録から条件に至った経緯を、引用付きでまとめる
  5. 【人】 交渉の担当者が根拠の箇所を開いて確かめ、交渉の方針を決める
  6. 【人】 法務部が、引き継ごうとする条件に審査の要るものがないかを見る

2番目で人が確かめた値だけを、幅の計算に使います。 検索のたびに契約書を読ませないので、同じ契約の数字が依頼ごとに違って出ることがありません。

6番目の幅は、プログラムが計算します。 AIには計算させず、どの契約を幅に入れ、どの契約を外したかを、理由付きで表に出します。

02今回想定するシステム構成

構成図
【契約の登録時】契約書のPDF ──▶ Claude API(条件の切り出し)──▶【担当者が確定】
                                                         ▼
                                            契約の索引(確定した値+本文)
【交渉の依頼時】
依頼の画面(技術の概要・分野・地域・独占性・許諾の向き・相手の区分)
   ▼【トリガー】依頼の送信
AWS Lambda ── 技術の概要を埋め込み(Amazon Titan Text Embeddings V2)
   ▼
Amazon OpenSearch Service(契約の索引)
   │   ハイブリッドクエリ:意味の近さ + 技術分野の語 + 社内の技術分類
   │                     + 地域 + 独占性
   │   filter:閲覧できる契約の区分
   ▼
AWS Lambda ── 料率の基準・独占性・地域で組に分け、組ごとの幅を計算
   ▼
Claude API ── 近い理由と、条件に至った経緯の要約(引用付き)
   ▼
【交渉の担当者と法務部が確認】──▶ 交渉の方針の稟議
役割想定する製品代替候補
検索基盤Amazon OpenSearch Service(ハイブリッドクエリ、ベクトル検索、日本語の解析)Vertex AI Search(Agent Search)、Azure AI Search
埋め込みAmazon Titan Text Embeddings V2(Amazon Bedrock)Cohere Embed
生成AIClaude API(条件の切り出し、近い理由と経緯の要約)OpenAI API、Gemini API
連携AWS Lambda(依頼を起点に検索と幅の計算を動かす)AWS Step Functions
保管Amazon S3(確定した値、検索と要約の記録)契約管理の仕組み

契約管理の仕組みと交渉記録のフォルダは、新しく足すものではありません。 索引は検索のための写しで、索引から契約管理の仕組みへは書き込みません。 新しい契約の登録を知らせる方法は、仕組みごとに違うため、利用環境に応じた個別の作りになります。

検索の土台は、Amazon OpenSearch Service です。 日本語の解析のためのプラグイン(kuromoji、ICU、日本語向けに勧められている Sudachi)と、ベクトル検索の k-NN、ニューラル検索のプラグインが使えます。技術の説明の意味の近さと、地域や独占性のような決まった値の一致を、1回の検索で組み合わせられることが、この構成に合っています。

組み合わせには、ハイブリッドクエリを使います。 複数の問い合わせの点数を1つにまとめる問い合わせで、中に入れられる問い合わせは最大5つです。 点数のまとめ方は検索パイプラインの正規化プロセッサーで決め、問い合わせごとの重みを0〜1の値(合計1)で付けられます。

埋め込みには、Amazon Titan Text Embeddings V2 を使います。 入力は最大8,192トークン・50,000文字、出力は既定で1,024次元です。英語に最適化され、日本語を含む多言語に対応しています。 英文の契約と日本語の契約が混ざるので、技術の概要は日本語に、英文の契約は英語の概要もあわせて持たせます。 言語をまたいだ検索は結果が劣るとされているためです。

03どうやって実装するのか

Step1

処理の起点を決める

トリガーは2つあります。 1つは契約管理の仕組みに新しい契約書が登録されたときで、条件の切り出しと担当者の確定を経て索引に入れます。もう1つは交渉の担当者が依頼の画面から送信したときで、検索と幅の計算と要約を動かします。

交渉記録は、案件が終わった時点で索引に入れます。 交渉中のメモは日々書き換わるため、合意して契約書が登録された時点で、その案件のフォルダをまとめて写します。 交渉が決裂した案件も、決裂の時点で入れます。合意しなかった条件の経緯も、次の交渉の材料になるからです。

過去の約600件は、最初に一度だけまとめて切り出します。 担当者の確定は、最近5年の契約と、よく参照される技術分野の契約から順に進めます。

Step2

入力データを集める

データ中身取得元
依頼技術の概要、社内の技術分類、地域、独占性、許諾の向き(出す・受ける)、相手の区分(同業・顧客・大学など)依頼の画面
契約の確定値料率とその基準、一時金、最低実施料、独占性、地域、期間、サブライセンスの可否、改良技術の条項の有無、契約の年担当者が確定した値
契約書の本文条項ごとに分けた本文と、その埋め込み契約管理の仕組み
交渉記録提示と対案の日付と内容、合意の経緯のメモ案件のフォルダ
閲覧の区分契約ごとに、誰が見てよいか契約管理の仕組み

質を決めるのは、契約の確定値です。 料率の基準(売上高の何%か、1個あたりか、利益の何%か)と、料率に含まれるもの・含まれないもの(一時金を料率の前払いとして差し引くか、など)までを確定値に持たせます。ここが曖昧だと、幅の計算で比べられないものを比べることになります。

閲覧の区分は、必ず持たせます。 実施許諾契約には、契約の条件を第三者や社内の関係者以外に開示しない条項が付いていることがあります。検索の結果に、その契約の担当でない人が見てはならない契約が出ないようにします。

Step3

データの取得方法を決める

検索は、ハイブリッドクエリ1本で行います。 中に入れる5つの問い合わせは次のとおりです。

問い合わせ対象の項目何を拾うか
ベクトル検索(k-NN)技術の概要の埋め込み言い方は違うが中身の近い技術
match技術の概要と対象製品(日本語の解析をかけたもの)技術の用語の一致
term社内の技術分類のコード同じ分類の契約
term地域同じ地域の契約
term独占性同じ独占性の契約

文書は、どれか1つの問い合わせに当たれば結果に入ります。 地域と独占性を filter で絞らず問い合わせに入れているのは、完全に同じ条件の契約が無い場合に、近い条件の契約を落とさないためです。重みは、意味の近さと技術分類を高く、地域と独占性を低く置きます。

filter には、閲覧の区分を入れます。 フィルターは5つの問い合わせすべてにかかるので、依頼した人が見てはならない契約は、どの問い合わせからも返りません。

交渉記録は、契約の番号で引きます。 検索で上位に来た契約の番号で、その案件の交渉記録の段落を取り出し、要約の材料にします。交渉記録を全文検索の対象にはしません。 メモの中の別の技術の話で、無関係な契約が上位に来るのを避けるためです。

Step4

AIへ渡す前に整形する

  1. 契約書を条項ごとに分ける … 条の番号で区切り、条項ごとに埋め込みを作ります。1つの埋め込みに契約書全体を入れません
  2. 技術の概要を作る … 契約の対象の特許の要約と対象製品から、200〜400字の概要を作り、担当者が確定します
  3. 英文の契約には英語の概要も持たせる … 日本語と英語の両方で検索できるようにします
  4. 金額の通貨と年をそろえる … 一時金と最低実施料は、元の通貨と金額をそのまま持ち、比べるときだけ、契約の年と通貨を表に添えます
  5. 料率の基準を区分にする … net_sales_pct / per_unit / profit_pct / other のどれかに寄せます。寄せられないものは other にします
  6. 依頼の技術の概要も同じ形にする … 依頼の画面で入れた説明を、契約の概要と同じ長さと書き方にそろえてから埋め込みます

1番目を省くと、意味の近さが効かなくなります。 契約書の大半は、定義・秘密保持・解除・準拠法といったどの契約にも同じように書かれている条項です。全体を1つにすると、技術の違いより書式の似かたで近さが決まります。

4番目で換算しないのは、換算の前提が増えるからです。 10年前の一時金を今の円に直すには、為替と物価の前提が要ります。その前提を選ぶのは交渉の担当者で、表には元の値と年を並べます。

Step5

AIに処理させる

AIの仕事は2か所です。 契約の登録時に条件を切り出すことと、交渉の依頼時に近い理由と経緯をまとめることです。

場面させること判断できないときの扱い
登録時料率・基準・一時金・最低実施料・独占性・地域・期間・サブライセンス・改良技術の条項を、条の番号と原文の引用付きで切り出す書かれていなければ「不明」
依頼時各契約が依頼と近い点と違う点を、確定値の項目で書く確定値に無い項目は書かない
依頼時交渉記録から、最初の提示・対案・合意の流れを、記録の引用付きで書く記録に無ければ「経緯の記録なし」
依頼時改良技術・非係争などの条項がある契約に印を付ける条項の有無だけを書く
させないこと理由
料率・一時金の幅の計算プログラムが確定値から計算する
提示すべき料率の提案交渉の方針は担当者が決める
条件が適法かの判断法務部と、必要に応じて外部の専門家が見る
確定値に無い数字の言及契約書の本文から数字を拾い直させない

4行目が、この構成でいちばん守りたい線です。 依頼時にAIが契約書の本文から料率を読み直すと、確定値と違う数字が要約に出て、どちらが正しいかを人が確かめ直すことになります。 数字は確定値だけ、と決めておきます。

Step6

指示内容を固定する

依頼時の指示の例です。

あなたは知的財産部で、ライセンス交渉の担当者に渡す
「類似の契約の比較」の説明を書く立場です。
渡すのは、依頼の条件、検索で選ばれた契約ごとの確定値、
その契約の交渉記録の段落です。
そこに書かれたことだけを使ってください。

【書くこと】
1. 契約ごとに、依頼と同じ点と違う点(技術・地域・独占性・
   許諾の向き・相手の区分・料率の基準)
2. 契約ごとに、交渉の流れ(最初の提示、対案、合意)を日付の古い順に
3. 改良技術の譲渡・独占的ライセンスの義務、非係争の義務、
   技術の利用範囲の制限の条項がある契約は、その条項の有無と条の番号

【厳守事項】
- 料率・一時金・最低実施料の数字は、確定値に書かれたものだけを
  書いてください。交渉記録や本文から数字を拾い直さないでください。
- 幅や平均を計算しないでください。
- 「この料率で提示すべき」など、交渉の方針を書かないでください。
- 条項が適法か、問題があるかを書かないでください。有無だけを書いてください。
- 交渉の流れの各行には、根拠にした記録の番号と、記録の文を
  そのまま写した引用を付けてください。
- 記録に無いことは「経緯の記録なし」と書き、推測で補わないでください。

【依頼】{request}
【契約ごとの確定値】{contracts}
【交渉記録の段落】{negotiation_records}

「数字を拾い直さない」を書かないと、交渉記録の数字を混ぜます。 交渉記録には「当初4%で提示」「先方は2%を希望」のような、合意しなかった数字が並んでいます。合意した数字と提示した数字が同じ文の中で混ざると、読む側が取り違えます。提示の数字は経緯の引用の中だけに置きます。

Step7

出力形式を固定する

幅の表はプログラムが作り、AIの出力はその下に並べます。 Claude API の構造化出力で、次の形のJSONを受け取ります。

{
  "request_id": "",
  "contracts": [
    {
      "contract_id": "",
      "same": [ "" ],
      "different": [ "" ],
      "negotiation": [
        { "date": "", "event": "first_offer | counter | agreed | broke_off",
          "record_id": "", "quote": "" }
      ],
      "review_flags": [ { "clause_type": "", "article": "" } ]
    }
  ]
}

quote は、プログラムが記録の原文と照らします。 原文に同じ文字列が無い引用は、その行を出さずに「引用を確かめられなかった」と示します。 引用が言い換えられていると、記録を開いても該当の箇所が見つかりません。

幅の表は、比べられる組ごとに出します。

組契約の数料率(最小〜中央〜最大)一時金外した契約と理由
売上高の%・非独占・アジア6確定値から計算契約ごとに元の通貨と年で並べる1件(相互許諾で料率なし)
売上高の%・独占・全世界2同上同上-
1個あたり・非独占3同上(単位を併記)同上-

中央の値は、プログラムが確定値から直接計算します。 OpenSearch の集計にも百分位を出す機能がありますが、値は近似とされています。 1つの組に数件しか無いこの用途では、近似の値を使う理由がありません。契約が2件以下の組は、幅を出さずに契約ごとの値を並べます。 2件の「幅」は、相場ではなく2つの例にすぎないからです。

Step8

システムへ連携する

つなぎ先方式内容
契約管理の仕組み新しい契約の登録の通知、契約書と閲覧の区分の取り出し利用環境に応じた個別の作り
案件のフォルダ案件の終了時の書き出し交渉記録の取り込み
Amazon BedrockTitan Text Embeddings V2 の呼び出し技術の概要と条項の埋め込み
Amazon OpenSearch Serviceハイブリッドクエリ(検索パイプライン付き)類似の契約の検索
Claude APIAPI呼び出し(構造化出力)条件の切り出し、近い理由と経緯の要約
依頼の画面結果の表示幅の表、契約ごとの説明、根拠へのリンク

稟議の仕組みへは書き込みません。 交渉の担当者が結果を読み、自分で比較表を選んで稟議に添えます。どの契約と比べたかを選ぶのは担当者の判断で、その選び方自体が稟議で問われる内容だからです。

Step9

人が確認する

  1. 登録時の確定値を確かめる … 知的財産部の担当者が、切り出された値と契約書の該当の条を並べて確かめます。料率の基準と、料率に含まれるものを最優先で見ます
  2. 依頼時に、幅に入った契約を確かめる … 交渉の担当者が、組ごとの契約の一覧を見て、外すべき契約(特殊な事情で結んだもの)がないかを見ます
  3. 経緯の引用を開いて読む … 交渉の方針に使う経緯は、必ず元の記録で前後を読みます
  4. 印の付いた条項を法務部に回す … 改良技術や非係争の条項を、今回の契約に引き継ぐかを法務部と決めます

1番目は、この構成でいちばん時間をかける確認です。 契約1件あたり十数分かかりますが、一度確かめれば、その後のすべての依頼で同じ値が使われます。 逆にここで誤った値は、何度でも交渉の材料に出ます。

目標は、40件をならして1件24分です。 時間は、幅に入った契約の確かめと、経緯の引用を元の記録で読むことにかかります。

Step10

例外に対処する

起きること対応
近い契約が見つからない「類似の契約なし」と出し、技術分類だけで当たった契約を参考に並べる
料率の基準が other の契約幅に入れず、契約ごとの条件を文で並べる
相互に許諾し合う契約で料率がない幅から外し、「相互許諾」と理由を付ける
確定前の契約が上位に来る確定値の欄を空にし、「未確定」と示す。幅には入れない
閲覧の区分の無い契約索引に入れない。区分を付けてから入れる
交渉記録が見つからない「経緯の記録なし」と示す。推測で補わない
引用が原文と照らせないその行を出さず、照らせなかったことを示す
検索が応答しない依頼の画面に「未実施」と出し、時間をおいて再実行する

4行目を軽く見ないでください。 過去の約600件の確定には数か月かかり、その間は確定値の無い契約が検索に出ます。 確定前の値を幅に入れると、まだ誰も確かめていない数字が相場として扱われます。

Step11

記録を残す

  • 依頼の条件と、依頼した人
  • 検索で返った契約と点数、組ごとに入れた契約と外した契約と理由
  • AIが返したJSONと、引用の照合の結果
  • そのとき使った確定値の版
  • 法務部に回した条項と、その結論

確定値の版を残すのは、確定値を後から直すことがあるためです。 料率の基準の読み違いが見つかって直すと、過去の依頼で出した幅が変わります。 どの版の値で交渉の方針を決めたかを、後から確かめられるようにします。

04実装レベルの3段階

最小構成:契約書を手でAIの画面に貼り、条件を書き出させる / 1件ごとの条件の切り出し
半自動化:上記+確定値の表を作り、表の絞り込みで近い契約を探し、組ごとの幅を表計算で出す / 確定値の蓄積と、決まった値による絞り込み
本格構成:上記+契約の索引とハイブリッドクエリで意味の近い契約を探し、経緯の要約と条項の印まで出す / 依頼から比較の材料までの全体

本記事の想定は本格構成です。 1件90分が24分になります。半自動化の確定値の表だけでも、②の「同じ契約を読み直す時間」はなくなります。 本格構成で減るのは、①の「近い契約を探す時間」と③の「経緯を読む時間」です。 段階を飛ばさないでください。 確定値の表を半年使うと、料率の基準の区分が足りているか、外すべき契約がどんな契約かが分かります。それを決めてから索引を作るほうが、幅の表の組み方で迷いません。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
6 名
月間件数
40 件
1件あたり現在時間
90 分
1件あたり導入後時間
24 分
現在  40件 × 90分 ÷ 60 = 60 時間/月
導入後 40件 × 24分 ÷ 60 = 16 時間/月
月間削減時間
44h
削減率
73%
年間削減時間
528h
年間金額換算(時間単価4,500円)
238万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 自社の特許・技術を他社に許諾し、他社の特許の許諾も受ける製造業・IT企業・医療機器メーカーの知的財産部と法務部。過去の実施許諾契約が数百件以上あり、交渉のたびに担当者が契約書のフォルダと交渉のメモを読み返して、料率や一時金の相場を手で調べている場合。過去の交渉の経緯が担当者の記憶に頼っており、異動で引き継がれていない場合。
向いていない
  1. 実施許諾契約が数十件で、担当者が全件を把握している場合。ライセンスの多くが標準規格の特許プールを通じたもので、条件が一律に決まっている場合。契約書と交渉記録が紙だけで、電子化の予定がない場合。なお、提示する料率の決定、契約条件が独占禁止法上問題とならないかの判断は、この構成では代替できません。

07最小構成で試す方法

  1. 最近2年の実施許諾契約から、技術分野の近い10件を選ぶ
  2. 10件の料率・基準・一時金・独占性・地域を、担当者が表に書き出しておく
  3. 契約書のPDFを1件ずつ手元のAIサービスに貼り付ける(秘密保持の条項で外部のサービスに出せない契約は、社内で使える環境に限る)
  4. 「この契約書から、料率とその基準、一時金、最低実施料、独占性、地域、期間を、条の番号と原文の引用付きで書き出してください。書かれていない項目は『不明』としてください」と指示する
  5. 出てきた値を、担当者の表と突き合わせる

生成AIの検索は、まだ作りません。 最初に確かめたいのは、契約書から条件を同じ形で取り出せるかです。ここができなければ、幅の計算の材料がそろいません。

出てきた内容判断
担当者の表とほぼ同じ値が出た確定値の運用と索引づくりに進む
料率の基準を取り違えた基準の区分を指示に足す。構成は有効
別紙や覚書に条件があり、本体から取れない契約書の束ね方の見直しが先。 別紙と覚書を同じ契約の番号で持たせる

3行目は、古い契約ほど起きます。 料率を改定した覚書が別のファイルになっていると、本体だけを読んでも今の料率が分かりません。契約の番号で束ねる作業が、索引づくりの前の準備になります。

08実装時につまずきやすいポイント

問題対策
条件の違う契約の料率を1つの平均にする料率の基準・独占性・地域で組に分け、組ごとに出す
検索のたびにAIが契約書から数字を読み直す数字は確定値だけ。 指示で拾い直しを禁じる
交渉中の提示の数字が合意の数字に混ざる提示の数字は経緯の引用の中だけに置く
契約書全体を1つの埋め込みにする条項ごとに分ける
閲覧してはならない契約が検索に出る閲覧の区分を filter に入れる
2件の契約から「幅」を出す2件以下の組は契約ごとの値を並べる
覚書で改定された料率が反映されない別紙と覚書を同じ契約の番号で束ねる
英文の契約が日本語の依頼で見つからない英語の概要もあわせて持たせる
過去の契約の条項をそのまま引き継ぐ改良技術・非係争などの条項に印を付け、法務部に回す

上の3行が、この構成の失敗のほとんどです。 どれも、数字がどの条件のもとの数字かという文脈を失うことから出ています。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 実施許諾契約の条件(料率、一時金、独占性、地域)、相手方の名前、交渉の経緯です。相手方との秘密保持の義務がかかる情報で、社内でも見てよい人が限られます。

  1. 閲覧の区分で検索を絞る … 区分の無い契約は索引に入れません。OpenSearch の security プラグインと filter の両方で、依頼した人が見てよい契約だけが返るようにします
  2. 外部のサービスに出してよい契約かを確かめる … 生成AIに契約書の本文や交渉記録を渡す前に、契約の秘密保持の条項がそれを許すかを法務部と確かめます
  3. 過去の条項を無条件に引き継がない … 公正取引委員会の「知的財産の利用に関する独占禁止法上の指針」は、ライセンシーが開発した改良技術をライセンサーに帰属させる義務や独占的ライセンスの義務を課す行為を、原則として不公正な取引方法に該当するとしています。非係争の義務も、公正競争阻害性を有する場合には問題になるとしています。過去の契約にあった条項でも、今回の交渉に持ち込む前に法務部が見ます
  4. 技術の利用範囲の制限と区別する … 同じ指針は、技術を利用する範囲を限定してライセンスをする行為を、通常はそれ自体では問題とならないとしています。印を付けるのは、法務部の確認が要る条項に絞ります
  5. 交渉の方針をAIに決めさせない … 出すのは過去の事実と幅までで、提示する数字は担当者が決めます

誤りが起きた場合のリスクは、条件の違う契約の数字で相場を見誤ることと、問題のある条項を引き継ぐことの2つです。 前者は組の分け方で、後者は条項の印と法務部の確認で防ぎます。

10まず何から始めるか

1週目:確定値の項目を決める

知的財産部と法務部で、料率の基準の区分、一時金と料率の関係、最低実施料、独占性、地域、改良技術の条項をどう持つかを決めます。閲覧の区分の付け方もここで決めます。

2週目:10件で試す

社内で使えるAIサービスで、契約書から条件を書き出させます。料率の基準を取り違えていないか、覚書の改定を見落としていないかを最優先で見ます。

3週目:確定値の表を作り始める

最近5年の契約から、確定値を表に入れていきます。この表だけで、②の読み直しの時間は減り始めます。

4週目:組の分け方を決める

表の確定値で、依頼を1〜2件試しに組に分けてみます。外すべき契約の条件と、2件以下の組の扱いを決めます。

2〜3か月目: 契約の索引とハイブリッドクエリを作り、検索で選ばれた契約と担当者の選んだ契約を比べます。4か月目以降: 経緯の要約と条項の印を足し、1件90分が何分になったかを実測します。交渉の担当者が、記憶ではなく幅の表から交渉の準備を始めるようになった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-08/最終更新:2026-10-08
確認した内容情報源確認日
ハイブリッドクエリが複数の問い合わせの点数を1つにまとめ、文書はどれか1つの問い合わせに当たれば結果に入ること。点数は検索パイプラインでまとめること。中に入れられる問い合わせが最大5つであること。filter がすべての問い合わせにかかることOpenSearch Documentation: Hybrid query2026-10-08
正規化プロセッサーが問い合わせごとの点数を正規化してまとめること。weights で問い合わせごとの重み(0〜1、合計1)を指定できることOpenSearch Documentation: Normalization processor2026-10-08
百分位の集計が数値の項目の百分位を推定するもので、値が近似であることOpenSearch Documentation: Percentile aggregation2026-10-08
Amazon OpenSearch Service で Japanese (kuromoji) Analysis と ICU Analysis が使え、Sudachi Analysis が日本語向けに勧められていること。OpenSearch k-NN、Neural Search、OpenSearch security のプラグインがあることAWS: Plugins by engine version in Amazon OpenSearch Service2026-10-08
Amazon Titan Text Embeddings V2(amazon.titan-embed-text-v2:0)の入力が最大8,192トークン・50,000文字、出力が既定1,024次元(512・256も可)であること。英語に最適化され、日本語を含む多言語に対応し、言語をまたいだ検索は結果が劣るとされていること。文書を段落や節に分けることが勧められていることAWS: Amazon Titan Text Embeddings models2026-10-08
Claude の構造化出力を output_config.format に type: "json_schema" を指定して使うこと。enum が使えることClaude Docs: Structured outputs2026-10-08
ライセンシーの改良技術をライセンサーに帰属させる義務・独占的ライセンスの義務を課す行為が原則として不公正な取引方法に該当するとされること(一般指定第12項)。非係争の義務が公正競争阻害性を有する場合に不公正な取引方法に該当するとされること。技術の利用範囲を限定したライセンスが通常はそれ自体では問題とならないとされること公正取引委員会: 知的財産の利用に関する独占禁止法上の指針2026-10-08

提示する条件の決定と、契約条件が独占禁止法上問題とならないかの判断は、自社の法務部と、必要に応じて外部の専門家の助言に従ってください。 本記事は上記の公開情報で確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-0953)についてのご相談はこちらから。

AI活用について相談する
目次