共同研究・委託開発の契約から、成果物の権利の帰属と実施条件を台帳にする

処理の起点を決める

契約書PDFが保管フォルダに保存されたことを起点にします。締結後にPDFを所定のフォルダへ置く運用は、多くの会社ですでにあります。

改定にも同じトリガーを当てます。 覚書や変更契約も同じフォルダに入る運用にし、元契約と同じ契約番号で台帳の行を親子にします。 ここを設計しないと、（d）の「台帳が古くなる」が残ります。

入力データを集める

帰属区分の選択肢を先に決めることが、準備作業の中心です。 ここが決まっていないと、抜き出した結果を台帳の列に落とせません。

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

契約書PDF： 保管フォルダから取得します。スキャンしたPDFの場合は、文字が埋め込まれているかを先に確かめます。画像だけのPDFは、この構成の対象外にします。

契約の基本情報： ファイル名の規則（契約番号と相手方を含める）から機械的に取ります。

既存の台帳： 同じ相手方の過去の契約を引き、ひな形が同じなら条番号もほぼ同じという前提で、確認の順序を決めるのに使います。

AIへ渡す前に整形する

1. 本文と別紙の分離 … 知財条項は本文にありますが、実施料や対象特許の一覧は別紙にあることがあります。両方を渡し、どちらから取ったかを記録させます
2. 改定分の突き合わせ … 覚書がある場合は、元契約と覚書の両方を渡します。覚書で上書きされた条項を、元の条文で答えさせないためです
3. ページ番号の付与 … 引用の確認を速くするため、全文にページ番号を残します
4. 契約種別の判定 … 共同研究か、委託開発か、単純な業務委託かで、注目する条項が変わります。ファイル名と表題から判定します
5. 秘密保持契約の除外 … 秘密保持契約だけの文書は、この台帳の対象外です。表題で弾きます

AIに処理させる

抜き出す項目は10種類です。

1回の呼び出しで10項目すべてを取りにいきません。 出典に「複数の情報を同時に探す場合は精度の幅が大きい」とあるためです。「権利帰属」「実施条件」「出願手続」の3つのまとまりに分け、それぞれ別の呼び出しで取ります。 全文は毎回そのまま渡し、聞く内容だけを絞ります。

分け方は、契約書の中で条項がまとまっている単位に合わせます。 帰属の定めは1か所に集まっていることが多く、実施条件はその直後か別紙に、出願の手続はさらに別の条項に置かれます。探す範囲が近い項目どうしをまとめると、1回の呼び出しで見るべき場所が減ります。 逆に、帰属と出願費用を同時に聞くと、離れた条項を同時に探させることになります。

各項目には4つの値を持たせます。

confidence がこの構成の要です。 条文に明記されているのが explicit、書きぶりから読み取ったのが inferred、条項が無いのが not_stated です。inferred と not_stated は必ず人が読みます。

指示内容を固定する

あなたは共同研究契約・委託開発契約から、知的財産に関する条件だけを
抜き出す作業を支援する立場です。以下の契約書の全文を読み、
指定された項目について、条文に書かれている内容を抜き出してください。

【厳守事項】
- 条文に書かれていないことを書かないでください。
  一般的な慣行や、他の契約でよくある内容で補わないでください。
- 該当する条項が見つからない場合は、value を not_stated にし、
  quote と article を空にしてください。
  「おそらく共有だろう」のような推測で埋めないでください。
- value は指定された選択肢の中からのみ選んでください。
  選択肢に当てはまらない書きぶりの場合は other にし、
  条文の原文を quote にそのまま入れてください。
- quote には、条文を要約せず、原文をそのまま入れてください。
  複数の条項にまたがる場合は、該当する条項をすべて入れてください。
- article には条番号を入れてください。項や号まで特定できる場合は
  そこまで書いてください。特定できない場合は空にしてください。
- confidence は次の3つから選んでください。
  explicit（条文に明記されている）
  inferred（条文の書きぶりから読み取った。断定されていない）
  not_stated（該当する条項が無い）
- 覚書または変更契約が添えられている場合は、そちらの定めを優先し、
  上書きされた元の条文を答えとして使わないでください。
- 契約の有効性や、条項が法令に適合しているかを判断しないでください。
  書かれている内容を抜き出すだけにしてください。

【契約書の全文】
{contract_text}

【抜き出す項目と選択肢】
{field_definitions}

上記の契約書について、指定された項目を抜き出してください。

「条文に書かれていないことを書かない」が、この指示のいちばん重要な部分です。 知財条項は世の中に典型的な書きぶりがあるため、放っておくと「よくある内容」で欄が埋まります。 埋まった台帳は、空欄の台帳より危険です。

「有効性を判断しない」も必ず入れます。 この構成は条文を読むものであって、法的な評価をするものではありません。

指示文の最後に、もう一度「抜き出してください」と置いています。 出典にクエリはプロンプトの末尾に置くと性能が上がるとあるためです。契約書の全文を先に置き、聞きたいことを末尾に置く順序にします。

出力形式を固定する

{
  "contract_no": "",
  "counterparty": "",
  "contract_type": "joint_research | commissioned_dev | service",
  "fields": [
    {
      "key": "invention_ownership",
      "value": "own_sole | counterparty_sole | joint | other | not_stated",
      "quote": "",
      "article": "",
      "confidence": "explicit | inferred | not_stated"
    }
  ],
  "amended_by": [],
  "needs_review": []
}

Gemini API の構造化出力は、レスポンス形式に MIME タイプ application/json とJSONスキーマを指定して受け取ります。ここで enum を使い、value を固定の選択肢に縛ります。 出典に、文字列型では分類タスク用に enum で特定の可能な文字列セットを列挙できると書かれています。

これを使わないと、台帳の列がそろいません。 「甲に帰属」「甲単独」「甲の単独所有」が別の値として入ってくると、あとで集計も検索もできません。選択肢に縛ることが、台帳を台帳にします。

スキーマの設計で注意する点があります。出典に、すべてのJSONスキーマ機能がサポートされるわけではなく、非常に大きい、または深くネストされたスキーマは拒否されることがあると明記されています。これも、10項目を一度に取らず3つのまとまりに分ける理由になります。 1回あたりのスキーマを浅く小さく保ちます。

オブジェクトには properties でプロパティ名とスキーマを、required で必須プロパティを指定します。quote と article を required に入れておくと、根拠のない値が返りにくくなります。 値が無い場合は空文字で返させ、confidence と組み合わせて意味を読み取ります。

システムへ連携する

台帳への登録は人が行います。 抽出結果はいったん確認用のシートに出し、人が確認したものだけを台帳の行にします。 自動で台帳を書き換えると、間違いが入ったことに誰も気づけません。

Google Apps Script を使うのは、スプレッドシートを確認画面として使えるためです。 Power Automate や Make でも同じ構成が組めます。

人が確認する

全件、人が確認します。 とくに次の3つは必ず読みます。

• confidence が inferred の項目（条文が断定していない）
• confidence が not_stated の項目（条項が無い）
• value が other の項目（選択肢に収まらない書きぶり）

確認を速くするための設計が重要です。

• quote を項目のすぐ下に展開しておく（契約書PDFを開かせない）
• article から契約書の該当ページへ飛べるようにする
• 同じ相手方の過去の契約の値を横に並べる（ひな形が同じなら値も同じはず）
• inferred と not_stated の項目を上に出す
• explicit の項目は既定でたたんでおく

確認にかかる時間の目標は、1件15分です。 それ以上かかるなら、選択肢の定義が現場の契約に合っていません。

例外に対処する

記録を残す

• 抽出に使った契約書のファイル名とページ数
• 抽出結果の全項目（value quote article confidence）
• 人が直した項目と、直す前の値
• 台帳に登録した日時と担当者
• 覚書による上書きの履歴

3つ目を残すと、この構成の弱点が見えます。同じ項目が毎回直されているなら、選択肢の定義か指示文に原因があります。 直した箇所の傾向が、そのまま改善点になります。

quote は台帳に残します。 開発から問い合わせが来たときに、「契約書のどこにそう書いてあるのか」をその場で示せます。これが台帳の信頼の土台です。