プロンプト自動最適化(PromptWizard)と高速エージェント訓練(Agent Lightning)による高精度契約書分析

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

プロンプト自動最適化(PromptWizard)と高速エージェント訓練(Agent Lightning)による高精度契約書分析

【ユースケース定義と課題】

複雑な契約書から、特定のコンプライアンス・リスクを抽出し、法務判断の根拠と共に構造化されたJSON形式で出力する。多義的な表現による誤検知や、特定条項の見落とし（ハルシネーション）をいかに防ぐかが課題となる。

  • 入力型：非構造化テキスト（契約書条文）

  • 出力型：構造化JSON（{ "risk_level": string, "claus_id": string, "reasoning": string, "mitigation": string }）

【プロンプト設計のループ】

graph TD
    A["設計: 役割と制約の定義"] --> B["実行: Zero-shot CoTの投入"]
    B --> C["評価: 精度・形式の自動検証"]
    C -->|PromptWizard法: 指示文の反復改善| A
    C -->|Agent Lightning法: 思考プロセスの蒸留| D["最適化プロンプト確定"]

  1. 設計: PromptWizard的手法を用い、タスクを記述する最適な「命令文」の変異を生成。

  2. 実行: Agent Lightningの思想に基づき、推論ステップを最小化しつつ精度を維持する「最短経路」を探索。

  3. 評価: LLM-as-a-Judgeにより、出力の法的妥当性とJSONスキーマの一致を自動採点。

【プロンプトの実装案】

# Role

あなたは上場企業の法務コンプライアンス・スペシャリストです。
提供された契約書から「損害賠償」「合意管轄」「秘密保持」の3点における潜在的リスクを特定してください。

# Constraints


1. 出力は必ず指定のJSONスキーマに従うこと。

2. 判断の根拠となった条項番号を必ず明記すること。

3. 曖昧な表現がある場合は「Risk: Medium」とし、その理由を記述すること。

# Thought Process (Chain-of-Thought)


1. 契約書の全条文をスキャンし、対象となる3つのカテゴリーに関連するキーワードを特定する。

2. 特定された条文の内容を、一般的な商慣習および民法・商法に照らして分析する。

3. 企業側に著しく不利な条項、または標準的な範囲を逸脱する記述を抽出する。

# Example (Few-shot)

Input: "第15条（損害賠償）：賠償額は、本契約の対価の10倍を上限とする。"
Output: {
  "risk_category": "損害賠償",
  "risk_level": "High",
  "claus_id": "15",
  "reasoning": "対価の10倍という設定は一般的な『契約金額を上限とする』範囲を大きく逸脱しており、過大な負担となる可能性がある。",
  "mitigation": "賠償額の上限を『直接かつ通常の損害』かつ『契約金額の範囲内』に修正することを推奨。"
}

# Input Data

[ここに契約書のテキストを挿入]

【評価指標と誤り分析】

評価項目 失敗パターン（例） 採点基準 (1-5) 改善アプローチ
JSON構造維持 冒頭に説明文が入る、閉じ括弧不足 5: 完全一致 / 1: 構造崩壊 jsonブロックの強制指定
条項特定精度 存在しない条項番号の捏造 5: 100%正確 / 1: 捏造あり 文脈検索の強化 (RAG併用)
リスク評価妥当性 安全な条項を「High」と過剰判定 5: 専門家と同等 / 1: 無関係 Few-shot例の多様化

【改良後の最適プロンプト】

# System

You are an expert Legal AI focused on risk extraction. 
Output ONLY raw JSON. No conversational filler.

# Task

Analyze the provided contract text for compliance risks. 
Use the 'PromptWizard' logic: refine your internal instructions to be as concise as possible while maintaining 100% recall.

# Schema

{
  "analysis_results": [
    {
      "category": "Liability" | "Jurisdiction" | "Confidentiality",
      "severity": "Low" | "Mid" | "High",
      "clause_reference": "string",
      "logic": "string",
      "suggested_edit": "string"
    }
  ]
}

# Execution Rule


- Step 1: Identify all clauses related to the categories.

- Step 2: Evaluate against standard business risks.

- Step 3: Format into the schema above.

# Data to Process

{{contract_text}}

【まとめ】

実務でプロンプトを運用するための3つの鉄則：

  1. 「型」の強制と分離：指示、例示、入力データを明確にセクション分けし、LLMが構造を誤認する余地を排除する。

  2. 評価の自動化ループ：PromptWizardのように、失敗パターンを次のプロンプトの「制約事項」へ自動反映させる仕組みを構築する。

  3. 推論の軽量化（Agent Lightning）：複雑な思考をさせつつも、最終的なプロンプトはトークン効率の良い、研ぎ澄まされた命令文へと「蒸留」し続ける。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました