法務に届いた新しい相談について、過去の法律相談と顧問弁護士の意見書から似た相談を探し、当時の回答と根拠を相談番号付きで返す

処理の起点を決める

トリガーは2つあります。 1つは索引を育てるための相談の完了、もう1つは検索を動かすための新しい相談の受付です。

索引への取り込みは、夜間にまとめて行います。 相談台帳に完了日が入った相談と、その日に共有フォルダへ格納された意見書を拾い、記録にまとめて索引に入れます。完了した相談だけを入れ、検討中の相談は入れません。 回答が固まっていない記録が候補に出ると、まだ誰も確かめていない見解が過去の回答のように扱われます。

検索は、相談受付のフォームの送信ごとに1件ずつ動かします。 部長が担当を割り当てる前に一覧ができていれば、「この相談は過去に誰が受けたか」を見て担当を決められます。

担当者が画面から言葉を足して検索し直すこともできるようにします（「業務委託　指揮命令　常駐」など）。この再検索も、担当者自身の権限で行います。

入力データを集める

質を決めるのは、下の3つです。 根拠の欄が空だと、一覧に出た回答が何に基づいていたかが分からず、今回にも使えるかを確かめる手がかりがありません。 見直しの印が無いと、古い回答と今も使える回答の区別がつきません。閲覧区分が無いと、検索の段階で権限を絞れません。

見直しの印は、法務部が付けるものです。 どの改定がどの回答に影響するかは、担当者が改定を読んで決めることで、生成AIには判定させません。

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

過去の記録は、相談番号を軸に3か所から集めます。

回答の本文は、メールのスレッドから「法務部が最後に送った回答」だけを取ります。 途中の確認のやり取りや、事業部門からの追加の質問まで入れると、索引の文面が長くなり、どの部分が回答なのかが分からなくなります。 最後の回答を本文にし、相談の要旨は受付のフォームの文面から取ります。

過去分の取り込みは、最初の1回だけ手間がかかります。 直近3年分から始め、古い記録は参照される頻度を見て足します。 意見書は、結論の段落を別の項目に分け、全文はPDFへのリンクで開く形にします。

AIへ渡す前に整形する

1. 符号への置き換え … 新しい相談の文面に含まれる社員の氏名、取引先や個人の顧客の名前を、検索用の符号に置き換えます。名簿と取引先マスタにある名前を照合して置き換え、生成AIに渡す文面には実名を残しません
2. 定型文の除去 … フォームの決まり文句（「お疲れさまです」「よろしくお願いします」）と署名を除きます。more_like_this が拾う語にこれらが入ると、中身と関係なく似た相談になります
3. 文面の長さの確認 … 文面が極端に短いもの（「至急確認したい件があります」だけなど）は、検索をせず担当者に回します。特徴となる語が取れない文面では、検索結果が当てになりません
4. 分野の推定と言葉の補い … フォームで選ばれた分野（契約・広告表示・労務・個人情報など）を検索の重み付けに使います。分野の選択は絞り込みには使いません。 事業部門が選び間違えていると、正しい分野の相談が出なくなるためです
5. 取り込み時の記録の整形 … 過去の記録は、相談の要旨・回答の本文・意見書の結論を別々の項目に入れます。相談の要旨だけで似ているかを見る検索と、回答の中の言葉で引く検索を分けられるようにします
6. 閲覧区分の付与の確認 … 区分が空の記録は索引に入れません。空のまま入れると、誰の権限でも見える記録になってしまいます

1番目と6番目は、どちらも見せてはいけないものを守る処理です。 1番目は生成AIへ渡す範囲を、6番目は検索で返す範囲を絞ります。どちらか一方だけでは足りません。

AIに処理させる

検索そのものは OpenSearch が行います。 新しい相談の文面を like に入れた more_like_this と、法令名・制度名の言葉の一致を組み合わせ、上位の相談を返します。

more_like_this の既定値は、そのままでは短い相談に合いません。 公式のドキュメントでは、入力の中で出現回数が min_term_freq（既定は2）より少ない語は無視され、出現する文書の数が min_doc_freq（既定は5）より少ない語も無視されます。選ぶ語の数は max_query_terms（既定は25）、一致させる語の割合は minimum_should_match（既定は30%）です。フォームの相談は数行のことが多く、大事な語ほど1回しか出ません。 min_term_freq を1にしないと、肝心の語が落ちます。

unlike に渡した文章の語は、検索に影響させないために使えます。 定型の相談（ひな形の場所を聞くだけなど）が上位を占めるなら、その典型の文面を入れます。

生成AIにさせるのは、検索で見つかった記録の並べ直しだけです。

いちばん起きやすいのは、2行目と3行目の失敗です。 生成AIは「改正されている可能性があります」と書き添えたり、回答に無い条文を補ったりします。どちらも根拠の無い文が一覧に混ざります。

指示内容を固定する

あなたは法務部の担当者を手伝う立場です。
新しい法律相談に対して、検索で見つかった過去の相談の記録を、相談番号付きで並べ直してください。
今回の相談への回答は書かないでください。

【使ってよい情報】
- 下の「検索で見つかった記録」に書かれていることだけ
- 記録に書かれていない法令・条項・判例・ガイドラインを持ち出さないでください

【1件ごとに書くこと】
1. 相談番号、相談日、回答日（記録の値をそのまま）
2. 当時の相談の要旨（2文以内）
3. 当時の回答の要点（回答の本文から、結論にあたる部分を2文以内で）
4. 根拠（回答の本文に書かれた法令・条項・ガイドライン・社内規程の名前を、表記を変えずに写す）
5. 顧問弁護士の意見書の番号と、意見書の結論（記録にあれば。なければ「なし」）
6. 見直しの印（印があれば「見直し要の印あり」と印の日付。なければ「印なし」）
7. 今回の相談との前提の違い（両方の文面に書かれている事実だけを比べる）

【厳守事項】
- 記録に書かれていない項目は「記載なし」としてください。推測で埋めないでください。
- 当時の回答が現在も通用するかどうかを書かないでください。
  「改正されている可能性があります」のような一般論も書かないでください。
- 根拠の欄には、回答の本文に書かれていたものだけを書いてください。
  関係しそうな条文を補わないでください。
- 前提の違いは、今回の相談の文面と過去の相談の要旨の両方に書かれている事実だけで比べてください。
  片方にしか書かれていないことは「今回の文面からは不明」としてください。
- 似ている理由を説明する必要はありません。順位も変えないでください。
- 符号（P001、C001 など）は符号のまま書いてください。
- 記録が0件のときは、一覧を作らず「該当なし」とだけ返してください。

【新しい相談】{new_consultation}
【検索で見つかった記録（順位順）】{search_hits}

「改正されている可能性がありますのような一般論も書かない」を明記しないと、ほぼ必ず書き添えます。 一般論として書かれた注意は、印の付いた記録にも付いていない記録にも同じように付くため、見直しの印の意味が薄れます。 注意は印の有無だけに任せます。

「片方にしか書かれていないことは不明とする」も同じ理由です。 書かれていない事情を「おそらく法人」と補うと、担当者は事業部門に確かめるべき点を見落とします。不明と出れば、それが確認事項になります。

順位を変えさせないのは、検索の結果を検証できるようにするためです。 順位は OpenSearch の点数のままにします。

出力形式を固定する

次の形のJSONで受け取り、画面では表にして見せます。

{
  "intake_no": "",
  "status": "listed | no_hits | input_too_short",
  "hits": [
    {
      "rank": 1,
      "consult_no": "",
      "consult_date": "",
      "answer_date": "",
      "summary": "",
      "answer_point": "",
      "grounds": [""],
      "opinion": { "no": "", "conclusion": "" },
      "review_flag": { "flagged": false, "flag_date": "" },
      "differences": [
        { "point": "", "past": "", "current": "" }
      ]
    }
  ],
  "unknown_in_current": [""]
}

JSONで受け取る理由は3つあります。

1つ目は、相談番号と日付を機械で照合できることです。 consult_no、consult_date、answer_date を索引の値と突き合わせ、一致しない行があれば一覧ごと出さずに担当者へ知らせます。 生成AIが相談番号を写し間違えると、担当者は別の相談の回答を読むことになります。

2つ目は、見直しの印を先頭に出せることです。 review_flag.flagged が真の行は、画面で色を変え、回答の要点よりも先に印の日付を表示します。

3つ目は、unknown_in_current を事業部門への確認事項にできることです。 前提の違いを比べる中で「今回の文面からは不明」となった点を集め、担当者が事業部門に聞き返す質問の一覧として使います。

システムへ連携する

検索は、担当者の権限で行います。 Lambda が自分の強い権限で検索してから結果を絞るのではなく、担当者のロールに対応する権限で OpenSearch に問い合わせます。 公式のドキュメントでは、ロールの割り当てがなければクラスターへの要求はすべて権限のエラーになるとされています。

相談台帳への書き込みは、参考にした相談番号の列だけです。 回答の本文も、見直しの印も、この構成からは書きません。記録の中身を変えるのは、いつも人です。

人が確認する

担当者は、一覧を答えとして使いません。 一覧は、どの過去の記録を開くべきかを決めるためのものです。

1. 見直しの印を先に見る … 印のある記録は、印を付けた理由（改定の内容）を確かめてから読みます。印のある回答を下敷きにするときは、改定後の内容で一から確かめます
2. 元の回答を開く … 一覧の要点ではなく、メールの回答の本文を読みます。要点は2文に縮めたもので、条件や留保が落ちていることがあります
3. 意見書は結論だけで判断しない … 意見書がある記録は、PDFの全文を読める担当者が前提と結論の両方を確かめます
4. 前提の違いを事業部門に確かめる … unknown_in_current の項目を、事業部門への質問として送ります
5. 参考にした相談番号を記録する … どの記録を下敷きにしたか、使わなかったならその理由を、台帳の列に書きます

2番目を省かないでください。 過去の回答には「ただし、〜の場合は別途ご相談ください」という留保が付いていることが多く、要点の2文にはそれが入りません。

目標は、120件をならして1件10分です。 多くは「前提が違うので一から検討」と判断することになりますが、過去の判断を知ったうえで始められます。

例外に対処する

6行目は意図した動きです。 担当者の権限で読めない記録は、近い相談があっても検索結果に出ません。「権限が無いため表示できない記録があります」と出すと、その種類の相談が過去にあったこと自体が伝わってしまいます。 内部通報や人事の処分の相談では、それだけで秘密が漏れます。限られた役割の担当者は、自分の権限で検索すればその記録を見られます。

4行目で出力を捨てるのは、どこが正しいかを担当者が確かめるより、検索結果の表だけを出すほうが速く確実だからです。

記録を残す

• 新しい相談の受付番号と、符号に置き換えた後の文面（実名の文面は相談受付のフォーム側にだけ残す）
• 検索の条件（more_like_this の設定値、言葉の検索の語、担当者のロール）と、返った相談番号と点数
• 生成AIに渡した記録と、返ってきた一覧のJSON
• 照合の結果（一致・不一致）
• 担当者が参考にした相談番号と、使わなかった記録とその理由
• 見直しの印の付与と解除の履歴（誰が、いつ、どの改定を理由に）

5つ目が、この構成を良くしていく材料になります。 上位に出たのに使われなかった記録が多い分野は、検索の設定か記録の書き方に問題があります。「前提が違う」で使われない記録が続くなら、相談の要旨の書き方に前提を入れるように台帳の運用を直します。

6つ目は、過去の回答を誰がいつ「古い」と判断したかの記録です。 改定のたびに印を付けた理由が残っていれば、後から改定がもう一度あったときに、どの回答を見直すべきかが分かります。