法律事務所が外部に渡す判決文や書面から、氏名・住所・電話番号を Azure AI Language で拾い、伏せ字の候補を作る

処理の起点を決める

担当の弁護士が、事件管理のシステムで「伏せ字の依頼」を登録した時点を起点にします。 依頼には、書面、目的（依頼者への共有／判例紹介・資料／書式例）、出す先、期限を入れます。保管庫に書面が置かれたことを起点にはしません。 外へ出すかどうか、何の目的で出すかは弁護士が決めることで、置かれた書面を全部処理すると、出す予定の無い書面の候補の一覧が積み上がります。

依頼の登録の直後に、秘匿決定と閲覧制限の確認だけを先に行います。 事件管理のシステムで印が付いている事件なら、読み取りの前に処理を止めて弁護士へ戻します。 民事訴訟法第133条の秘匿決定では、住所や氏名に代わる事項が定められ、第92条では秘密の記載部分の閲覧を当事者に限る決定ができます。そうした事件の書面を外へ出すかは、伏せ字の出来とは別の判断です。

入力データを集める

質を決めるのは、名簿の厚みです。 名簿に「甲野太郎」しか無ければ、本文の「甲野」は名簿の照合では拾えません。名簿に、姓だけ・名だけ・通称・旧姓・読みを持たせます。 事件の受任のときに登録する項目を増やすのが、いちばん効く準備です。

方針表は、目的の数だけ作ります。 同じ「裁判官の氏名」でも、依頼者への共有では残し、判例紹介では残し、書式例では伏せる、というように目的で変わります。表は担当の弁護士が変えられないようにし、事務所の決まりとして管理します。

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

レイアウト モデルを使うのは、語ごとの位置が取れるからです。 公式ページでは、レイアウト モデルは文字を lines と words として取り出し、語ごとに polygon と信頼度を返し、spans が全文（content）の中の位置を指すとされています。PII の検出が返した全文の中の位置と、語の spans を突き合わせれば、どの語の四角を消せばよいかが決まります。

位置の数え方をそろえます。 Language の応答の offset と length は、既定では Unicode 8.0.0 の書記素の単位で数えられ、stringIndexType で unicodeCodePoint（Python 3 の既定）や utf16CodeUnit に変えられるとされています。Python で処理するなら unicodeCodePoint を指定し、レイアウト モデルの側も同じ単位で突き合わせられることを、最初の検証で必ず確かめます。 単位がずれると、隣の語を消します。

ヘッダー・フッターは捨てません。 判決書のヘッダーには事件番号が、フッターには通し番号が入ることがあります。役割を見て、規則の照合の対象に入れます。

AIへ渡す前に整形する

1. 形式の確認 … PDF、画像、DOCX であることを確かめます。パスワード付きの PDF は、ロックを外してから送る必要があります
2. 読み取り … レイアウト モデルで全文と語の位置を取ります。信頼度の低い語が多いページは印を付け、目視の対象にします
3. 分割 … 全文を段落の切れ目で5,000字以下のかたまりに分けます。同期の呼び出しでは1文書5,120字（書記素の数え方）が上限で、1回の要求に5文書までです
4. 言語の指定 … 各かたまりに language: "ja" を付けます。指定しないと英語として扱われます
5. 区分の指定 … piiCategories に、Person、Address、PhoneNumber、Email、Organization、Date と、JPBankAccountNumber・JPDriversLicenseNumber・JPMyNumberPersonal・JPPassportNumber・JPResidenceCardNumber・JPSocialInsuranceNumber などを並べます
6. 名簿の展開 … 名簿の氏名から、姓だけ・名だけ・通称・旧姓・全角半角とスペースの揺れの照合語を作ります
7. 規則の用意 … 事件番号、地番・家屋番号、車両の登録番号、和暦の生年月日の書き方を、正規表現で持ちます

4番目は、忘れると全部が空振りになります。 公式ページでは、言語を指定しない場合は英語として抽出が行われるとされています。日本語の書面を英語として送ると、人名をほとんど拾いません。 エラーにはならないので、気づきにくい失敗です。

3番目の分割は、段落の途中で切りません。 「原告甲野」の途中で切れると、どちらのかたまりでも人名として拾われません。

AIに処理させる

させるのは、全文から個人を特定しうる語を拾い、区分と位置と信頼度を付けて返すことだけです。 ここでいう AI は Azure AI Language の PII の検出で、文章を生成する AI ではありません。

3つを重ねるのは、それぞれの苦手を他が埋めるからです。 同じ箇所を複数の仕組みが拾ったら1つの候補にまとめ、どの仕組みが拾ったかを残します。1つの仕組みしか拾わなかった候補は、確認の画面で目立たせます。

2行目に注意が要ります。 Language の応答には伏せ字を適用した文字列が付いてきますが、これをそのまま使うと、検出した語が全部伏せられます。 裁判官や代理人の名前まで伏せた判決書は、判例紹介には使えません。

指示内容を固定する

PII の検出は文章の指示ではなく、要求の形で何を拾うかを決めます。次の要求を、かたまりごとに送ります。

POST {endpoint}/language/:analyze-text?api-version=<GA の版>
{
  "kind": "PiiEntityRecognition",
  "parameters": {
    "modelVersion": "latest",
    "stringIndexType": "unicodeCodePoint",
    "piiCategories": [
      "Person", "Address", "PhoneNumber", "Email", "Organization", "Date",
      "JPBankAccountNumber", "JPDriversLicenseNumber", "JPMyNumberPersonal",
      "JPPassportNumber", "JPResidenceCardNumber", "JPSocialInsuranceNumber"
    ]
  },
  "analysisInput": {
    "documents": [
      { "id": "p012-c03", "language": "ja", "text": "<段落の切れ目で分けた本文>" }
    ]
  }
}

piiCategories を明示するのは、拾う範囲を事務所で決めるためです。 公式ページでは、区分を指定するとその区分だけが返り、既定で有効でない区分も指定で拾えるとされています。Organization と Date は、既定のまま任せずに明示して拾い、伏せるかは方針表で決めます。 会社名や日付は、目的によっては残すからです。

確認の画面で事務職員に見せる手順書は、次のように書きます。

【候補の確かめ方】
1. 「1つの仕組みだけが拾った」候補から見る
2. Person の候補は、名簿の役割と照らして 伏せる／残す の初期値を確かめる
3. 一覧に無い人名・住所が画像に見えたら「候補を足す」で囲む
4. 姓だけの語は、同じ人の他の出現も一覧に出ているかを確かめる
5. 迷ったものは「要判断」にして、弁護士へ回す
【やらないこと】
- 一覧に無い箇所を、画面上の黒い四角だけで隠さない
- 置き換えの表記（原告A など）を、書面ごとに変えない

4番目が、第3章の（a）の対策です。 名簿で「甲野」を照合していれば全出現が候補に並びますが、名簿に無い人は PII の検出の出来に頼ります。同じ姓が一部だけ拾われていたら、残りを足します。

出力形式を固定する

候補の一覧は、次の形の JSON で持ちます。

{
  "request_id": "",
  "purpose": "client_share | publication | template",
  "candidates": [
    {
      "text": "",
      "category": "Person | Address | PhoneNumber | CaseNumber | LotNumber | ...",
      "sources": ["language_pii", "roster", "rule"],
      "confidence": 0.0,
      "roster_role": "plaintiff | defendant | witness | counsel | judge | none",
      "page": 0,
      "polygons": [[0, 0, 0, 0, 0, 0, 0, 0]],
      "default_action": "redact | keep | review",
      "replacement": "原告A",
      "decided_action": "",
      "decided_by": ""
    }
  ],
  "low_ocr_pages": [0]
}

1つ目の理由は、sources で拾った仕組みが分かることです。 名簿でしか拾えなかった候補が多い区分は、PII の検出が苦手な書き方です。逆に PII の検出でしか拾えなかった人名は、名簿の登録漏れを示します。

2つ目は、default_action と decided_action を分けていることです。 方針表が付けた初期値と、人が決めた値を別に持つので、初期値を人が覆した割合を区分ごとに数えられます。 割合の高い区分は、方針表の見直しの対象です。

3つ目は、replacement で表記をそろえられることです。 同じ人には、書面の最初から最後まで同じ置き換えを使います。置き換えは名簿の役割から機械的に振り、人が書面ごとに考えないようにします。

システムへ連携する

伏せ字の適用は、PDF の文字の層ごと消す処理で行います。 黒い四角を重ねるだけの処理にはしません。DOCX は、該当の文字列を置き換えの表記に差し替え、変更履歴とコメントと文書のプロパティ（作成者など）を消してから PDF にして出します。

伏せ字済みの書面は、原本とは別の場所に保存します。 原本を上書きすると、伏せ過ぎに後から気づいたときに戻せません。

人が確認する

全件、事務職員と弁護士の2段階で確かめます。 自動で伏せて外へ出す経路は作りません。

1. 事務職員が候補を確かめる … 一覧とページの画像を並べ、1つの仕組みだけが拾った候補から見ます
2. 漏れを足す … 一覧に無い個人の記載を画像の上で囲んで足します
3. 読み取りの怪しいページを見る … low_ocr_pages のページは全文を目で読みます
4. 弁護士が要判断を確定する … 方針表で決まらない候補と、事務職員が足した候補を見ます
5. 弁護士が出力を確かめる … 伏せ字済みの書面を読み、目的に合っているかを見ます

3番目を省かないでください。 読み取りが崩れた語は、PII の検出にも名簿の照合にも引っかかりません。読めなかった語は、拾えなかった語です。

弁護士の確認は、25分から10分ほどにする想定です。 全文の読み直しが、要判断の候補と出力の拾い読みに変わります。

例外に対処する

7行目の検査が、この構成の最後の砦です。 伏せ字済みの書面をもう一度レイアウト モデルで読み、decided_action が redact の語が全文に残っていないかを探します。1語でも残っていたら止めます。

記録を残す

• 依頼の内容（目的、出す先、担当の弁護士）と、使った方針表の版
• 読み取りの結果の JSON と、PII の検出の応答の全文
• 候補の一覧（初期値と、人が決めた値、決めた人と日時）
• 人が足した候補と、その区分
• 伏せ字済みの書面と、再読み取りの検査の結果
• 外へ出した日時と出した先

4つ目の「人が足した候補」は、仕組みの弱点の記録です。 同じ型の書き方が何度も足されているなら、規則か名簿の項目を増やします。名簿の照合で拾えた語の割合が低い事件は、受任のときの名簿の登録が薄い事件です。

2つ目の応答の全文は、原本と同じ扱いで保管します。 検出された語の一覧は、それだけで個人情報の一覧です。