法律事務所で、過去の準備書面・調査メモ・裁判例の整理メモから争点の近い書面を探し、該当箇所を案件番号付きで返す

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは、案件管理システムで書面が「提出済み」、調査メモが「確定」になったことを起点にします。 提出済みの書面だけを取り込むのは、起案の途中で消した主張や、依頼者との打ち合わせで取り下げた主張を、検索結果に出さないためです。 状態の変更を受けたら Lambda が動き、案件番号のフォルダからファイルを取り出します。案件管理システムが通知を出せない場合は、状態が変わった案件の一覧を毎晩取りに行きます。

判決・和解・取下げのときも、もう一度動かします。 案件が終わった時点で、その案件の節に争点ごとの結果を書き足します。結果は担当の弁護士が案件管理システムに入れたものを使い、AIには判断させません。

過去15年分の約4万通は、別に一括で取り込みます。 このときはパラリーガルの確認が取れないので、節に「未確認」の印を付けます。検索結果では未確認の節を区別して表示し、弁護士が使うと決めたときに、その場で節の分け方と争点の名前を確かめてもらいます。

検索は、弁護士が検索画面で「探す」を押したときに動きます。 起案の途中で、争点の書き方を変えて何度でも探せるようにします。

入力データを集める

質を決めるのは、いちばん下から2つ目の閲覧の制限です。 これが案件管理システムにまとまっていなければ、誰にどの案件の書面を見せてよいかを検索基盤に教えられません。検索の構成より先に、遮断の記録を案件番号で引ける形にそろえます。

節の項目は、最初に固定します。 案件番号、書面の種類（準備書面・答弁書・意見書・調査メモ・整理メモ）、提出日、審級、当方の立場（原告・被告・申立人・相手方）、見出し、争点の名前、本文、ページの範囲、裁判例の表示の一覧、結果（adopted／rejected／settled／pending／unknown）、確認の状態です。項目が決まらないうちに取り込みを始めると、後から全件を作り直すことになります。

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

本文は、Word と文字の入った PDF から取り出します。スキャンした画像だけの古い書面は、この構成の対象外にします。 取り出せなかったファイルは一覧にして、別に読み取りの作業を回します。

本文はページ番号を付けたまま持ちます。 検索結果で「案件 2019-0412 の被告第2準備書面の8ページ」と示せなければ、弁護士は原文を確かめられません。ページが失われる取り出し方は使いません。

検索は2回に分けて問い合わせます。 1回目はハイブリッドクエリで候補の節を集めます。サブクエリは、争点の名前と検索語の語の一致、争点の説明の埋め込みによる近さの2つにし、filter で分野と、検索から外す案件を絞ります。ハイブリッドクエリのドキュメントにはハイライトについての記載がないため、2回目に、上位の節の ID で絞った語の一致の問い合わせを投げ、そこでハイライトを取ります。

ハイライトの設定は、次のように置きます。

AIへ渡す前に整形する

1. 節への分割 … 見出しの番号で書面を節に分けます。番号の付け方は事務所の書式で決まっているので、規則で分け、規則で分けられないものだけを Claude に任せます
2. ページの範囲の付与 … 各節に、始まりと終わりのページを付けます
3. 当事者の名前の置き換え … 埋め込みに渡す本文では、依頼者と相手方の名前を「原告」「被告」「A社」のような呼び方に置き換えます。名前が似ているだけの案件が近いと出るのを防ぎます
4. 用語の言い換えの表 … 「瑕疵」と「契約不適合」、「解雇権の濫用」と「解雇の有効性」のような組を、分野ごとに表にします。検索語の言い換えに使います
5. 長さの確認 … 埋め込みの入力は最大8,192トークンまたは50,000文字です。これを超える節はまずありませんが、超えたものは段落で分けます
6. 重複の検知 … 同じ主張が第1準備書面と最終準備書面に繰り返し出る場合は、後の書面を正とし、前の書面の節に印を付けます

3番目を軽く見ないでください。 当事者の名前を残したまま埋め込むと、同じ依頼者の別の案件が、争点が違っても上位に並びます。 名前は索引の項目として持ち、絞り込みにだけ使います。

AIに処理させる

AIの仕事は3か所です。取り込み時の節の整理、検索語の言い換え、検索結果の一言です。

3行目がいちばん起きやすく、いちばん重い失敗です。 生成AIは、もっともらしい裁判所名・日付・事件番号を書くことがあります。検索結果の一言に、索引のどこにもない裁判例が混ざると、それが書面に引用されるおそれがあります。 AIが触れてよい裁判例は、節に取り出した裁判例の表示の一覧にあるものだけにし、出力の後に、一覧にない表示が含まれていないかを機械で照合します。

指示内容を固定する

取り込み時（節の整理）：

あなたは法律事務所で、提出済みの書面を整理する担当です。
書面の本文だけを根拠にしてください。推測で埋めないでください。

【やること】
書面を見出しで節に分け、それぞれについて次を取り出してください。
- 見出し（本文の見出しをそのまま写す）
- 争点の名前（20字以内。本文の言葉を使う）
- 当方の立場：原告 / 被告 / 申立人 / 相手方 / 不明
- 本文に書かれている裁判例の表示（裁判所、判決日、事件番号、掲載誌）
- ページの範囲

【厳守事項】
- 本文に書かれていない裁判例を足さないでください。
  裁判例の表示が一部しか書かれていなければ、書かれている部分だけを写し、
  incomplete を true にしてください。補わないでください。
- 争点の名前は本文の言葉で付けてください。
  一般的な法律用語に置き換えないでください。
- 見出しが無く節に分けられない部分は、1つの節とし、split_uncertain を true にしてください。
- 主張の当否、勝ち筋、判決の見込みを書かないでください。

検索時（近さの一言）：

あなたは弁護士の調査を助ける担当です。
渡された検索結果だけを根拠に、入力された争点と各節を比べてください。

【入力された争点】{issue}
【相手方の主張の要旨】{opponent}
【検索結果の節（上位10件）】{hits}
  各節には、案件番号、書面名、ページ、当方の立場、結果、ハイライト、
  裁判例の表示の一覧が付いています。

【書くこと】
各節について、
1. 入力された争点と近い点（1文）
2. 入力された争点と違う点があればその点（1文。無ければ「なし」）

【厳守事項】
- 主張や反論の文案を書かないでください。
- 該当箇所を要約・言い換えしないでください。原文はハイライトで示されます。
- 裁判例に触れるときは、その節の裁判例の表示の一覧にあるものだけにしてください。
  一覧にない裁判例を書かないでください。
- 結果（採用・不採用など）は渡された値をそのまま書いてください。
- 「未確認」の印のある節は、その旨を書いてください。
- 近い節が1件もなければ「争点の近い書面は見つかりませんでした」と書いてください。

「一覧にない裁判例を書かない」を両方の指示に書かないと、取り込み時に表示を補い、検索時に関連する裁判例を足してきます。 どちらも善意の補完ですが、事務所の書面に書かれていなかった裁判例が、「過去の書面にあったこと」として扱われます。 指示で禁じたうえで、出力を一覧と照合する二重の守りにします。

「違う点」を書かせるのも意図してのことです。 近い点だけを並べると、弁護士は似ている理由ばかりを読みます。当方の立場が逆、審級が違う、事実関係の前提が違う、という点が先に見えると、使えない節を早く外せます。

出力形式を固定する

検索結果は、次の形のJSONで画面に返します。

{
  "query_id": "",
  "issue": "",
  "expanded_terms": [""],
  "hits": [
    {
      "matter_no": "2019-0412",
      "document": "被告第2準備書面",
      "doc_type": "brief | answer | opinion | research_memo | case_memo",
      "filed_on": "",
      "position": "plaintiff | defendant | applicant | respondent | unknown",
      "heading": "",
      "issue_name": "",
      "pages": { "from": 0, "to": 0 },
      "highlights": [""],
      "cases_cited": [
        { "court": "", "date": "", "case_no": "", "reporter": "", "incomplete": false }
      ],
      "outcome": "adopted | rejected | settled | pending | unknown",
      "verified": true,
      "why_close": "",
      "how_different": ""
    }
  ],
  "not_found": false
}

1つ目の理由は、AIが書いた部分と原文を分けて持てることです。 highlights は OpenSearch が原文から切り出したもの、why_close と how_different は Claude が書いたものです。画面では両者の見た目を変え、弁護士が原文とAIの一言を取り違えないようにします。

2つ目は、cases_cited を照合に使えることです。 検索時の一言に裁判所名や事件番号が出てきたら、その節の cases_cited と突き合わせます。一覧にない表示があれば、その一言を捨てて「近さの説明なし」として表示します。

3つ目は、outcome と position で並びを変えられることです。 「被告の立場で、判決で採用された主張だけ」に絞れるのは、この2つを決まった値で持つからです。自由文の結果では、この絞り込みができません。

システムへ連携する

閲覧の制限は、細かなアクセス制御の文書レベルのセキュリティで掛けます。 Amazon OpenSearch Service のドキュメントでは、文書レベルのセキュリティは、役割に指定したクエリに合う文書だけを、その役割に対応付けた利用者に見せるものとされています。案件ごとの遮断の対象者を役割に写し、検索画面からの問い合わせは、検索した弁護士の権限で投げます。

案件管理システムとファイルサーバーには書き込みません。 調査メモへの書き出しは、弁護士が選んだ節を下書きに写すところまでです。

人が確認する

確認は2か所です。取り込み時のパラリーガルと、検索時の弁護士です。

1. パラリーガルが節を確定する … 提出の直後に、節の分け方と争点の名前を確かめます。split_uncertain と incomplete の付いた箇所を優先して見ます
2. 弁護士が原文を開く … 使う節は、ハイライトの前後を含めて原文のページを必ず開きます。ハイライトは断片なので、前後の文脈で意味が変わることがあります
3. 裁判例は原典で確かめる … 節に書かれていた裁判例を使うときは、判例データベースで原典を確かめます。過去の書面に書かれていたことは、正しいことの保証になりません
4. 未確認の節を確かめる … 一括取り込みで作った節を使うときは、その場で節の分け方を確かめ、「確認済み」に変えます

1件の調査あたり30分を目安にします。 検索結果の10件を読み、うち数件の原文を開いて確かめ、調査メモに書き出す時間です。ハイライトとAIの一言だけを読んで調査メモを書く運用にはしません。

例外に対処する

上から2行目と6行目が、運用の大半を占めます。 2行目は書面の書式の問題、6行目は利益相反の管理の問題で、どちらもAIの問題ではありません。6行目を「とりあえず全員に見せる」で埋めないでください。

記録を残す

• 取り込んだ書面の案件番号、書面名、提出日、取り込んだ日時
• Claude が返した節のJSONと、パラリーガルが確定した時に直した項目
• 検索のたびの争点の説明、検索語と言い換え、候補の節、ハイライト
• Claude の一言と、一覧との照合で捨てた一言
• 弁護士が調査メモに書き出した節と、書き出さなかった節
• 検索した人と、文書レベルのセキュリティで外れた件数

4つ目で「捨てた一言」を残すのは、指示の効き方を測るためです。 一覧にない裁判例を書いた回数が減らなければ、指示を直すか、一言を書かせる範囲を狭めます。