海外子会社の社内規程を訳して、本社の規程と条項どうしを突き合わせる

処理の起点を決める

受領フォルダにファイルが保存されたことを起点にします。 月15件と少ないので常時の監視は要りません。Make のシナリオは既定で15分ごとに実行され、「At regular intervals」では間隔を分で指定します（最小はプランによるとされています）。ここでは1日1回とし、急ぎのものは「On demand」（run once button）で届いた日に回します。

ファイルを置くだけでは始めません。受付フォームで人が、子会社・種類・版・施行日を選びます。版を自動で判定させないでください。 取り違えると全部やり直しです。フォームは10秒、やり直しは90分です。

処理済みフォルダへ移すのは成功したときだけにし、受領フォルダに残っている数を未処理の数とします。

入力データを集める

質を決めるのは、真ん中の2つです。 必須事項の一覧が無ければ、何を探すのかが決まりません。対訳表が無ければ、同じ現地語が月ごとに違う日本語になり、前版と比較できません。

必須事項は10件から15件で始めます。 贈収賄の禁止、機密情報の持ち出しの禁止、労働時間の上限、懲戒の種類と手続、購買の相見積り、内部通報の窓口など。それぞれに本社規程の条番号と、必須か推奨かを付けます。対訳表は30語程度から始め、「使ってはいけない訳語」の列を持たせます。

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

本社規程は、条ごとに1件のレコードにして検索インデックスへ入れます。 全文を1件にすると、どの条が当たったかが返ってきません。

セマンティック構成には、フィールドの優先順位を付けます。 要約モデルは1件あたり最大2,000トークンを受け取り、title と keywords がそれぞれ128トークン、残りが content とされます。条の見出しを title、コードを keywords、本文を content に置きます。

検索は、1つの現地条項につき訳文で1回、原文で1回行います。 訳語のぶれで訳文から当たらない条項が、原文の側から当たります。候補を束ね、上から10件程度を判定へ渡します。

AIへ渡す前に整形する

1. 形式の確認 … Word はPDFに変換します。非PDFは通常のテキストとして扱われ、書式の文脈が失われるためです
2. ページ数とサイズの確認 … 50MBまたは1,000ページが上限です。超えるものは章で分割します
3. 条項への切り分け … 条、項、号に切ります。原文の条番号は表記のまま文字列で持ちます
4. 版の記録 … 受付フォームで選んだ版と施行日を、全レコードに付けます
5. 個人情報の除去 … 起草者の氏名、署名欄、押印欄、連絡先を落とします
6. 前版との照合 … 前版と本文が同一の条には印を付け、判定の対象から外します
7. 画像だけのPDFの検知 … 文字が取り出せなければ、現地へ元ファイルを依頼します

6番目が、改訂の処理時間を決めます。 届くのは全文でも、変わっているのは数条です。外さないと、毎回すべての条を判定し直すことになります。

3番目は、国によって形が違います。 条が無く箇条書きだけの規程、章と条の二段構えの規程、別表が本体と同じ重さを持つ規程があります。原文の見出しを識別子に使います。

AIに処理させる

させるのは、条項に切ること、訳すこと、対応の有無を3値で判定することの3つです。 中心は3つ目です。

1行目がいちばん守らせにくく、候補ゼロは absent の既定にします。

4行目が、最も起きやすい失敗です。 言葉の上で近い条項は、どの規程にも見つかるからです。

指示内容を固定する

あなたは本社法務の担当者で、海外子会社の社内規程を本社規程と条項単位で
突き合わせる立場です。渡された「現地の条項」と「本社規程の候補条項」だけを
見て判定してください。

【match_status の選び方】
- matched ..... 候補の本社条項と同じ事項を規定し、内容も食い違わない
- divergent ... 同じ事項を規定しているが、数値・期間・手続の主体・適用の
                範囲のいずれかが違う
- absent ...... その事項の規定が、この現地の条項に無い

【厳守事項】
- 候補が1件も渡されていない場合は、必ず absent にしてください。
  原文に書かれていない規定を「あるはずだ」と補わないでください。
- matched と divergent を選ぶときは、evidence_src に現地の原文をそのまま
  写してください。写せないときは absent です。
- local_article_no には、原文の条番号の表記をそのまま入れてください。
  訳す、振り直す、本社の条番号に合わせることをしないでください。
- 見出しが似ているだけで matched にしないでください。
  見るのは見出しではなく、規定されている中身です。
- divergent のときは、difference に「何が」「本社ではどう」「現地ではどう」
  を事実として書き、どちらが正しいかは書かないでください。
- 現地法に適合しているか、違法かどうかを書かないでください。
- 訳語は用語集の語だけを使い、無い語は訳さず原文の表記を残して
  note に「用語集に無い」と書いてください。

【グループ必須事項】{control_item}
【本社規程の候補条項】{hq_candidates}
【用語集】{glossary}
【現地の条項】{local_article}
上の現地の条項に、グループ必須事項が規定されているかを判定してください。

「候補がゼロなら absent」を厳守事項の先頭に置いているのは、これが判定の既定だからです。 「無い」は探した結果ではなく、検索で当たらなかったという事実から出します。

「見出しが似ているだけで matched にしない」も外せません。 現地の規程にも「Confidentiality」や「Disciplinary Action」といった見出しは並びます。見出しがあることを、中身があることとして扱わせないのが、この一行の役目です。

資料を先に、問いを最後に置いています。 長い文脈では、問いを他の文脈のすべての後ろに置いたほうが性能が上がるとされています。

出力形式を固定する

次の形のJSONで受け取ります。 必須事項1件と現地条項1件の組で1レコードです。

{
  "subsidiary_code": "",
  "policy_type": "work_rules | expense | procurement | infosec",
  "version": "",
  "control_item": "G-05",
  "hq_article_no": "",
  "local_article_no": "",
  "local_article_title_src": "",
  "translation_ja": "",
  "match_status": "matched | absent | divergent",
  "evidence_src": "",
  "evidence_ja": "",
  "difference": [{ "aspect": "", "hq": "", "local": "" }],
  "glossary_missing": [],
  "note": ""
}

訳と原文（translation_ja と evidence_src）を同じレコードに持たせ、local_article_no に原文の条番号を残します。 人が原文に戻る経路を、データの形の側で確保するためです。形の固定には response_format（type ／ mime_type ／ schema）を使い、match_status を enum で3値にします。

ただし、スキーマに頼りきらないでください。スキーマに沿っていながら意味の上では誤っていることがあるため、アプリケーション側で値を必ず検証するよう案内されています。 Python 側で次を見ます。

3行目を必ず入れてください。 写された原文が元のファイルに実在するかを確かめます。ここを見ないと、それらしい引用が付いた誤った matched が通ります。 なお、非常に大きい、深く入れ子になったスキーマは拒否されうるとされるため、規程全体を1つのJSONで返させません。

システムへ連携する

本社規程の検索インデックスには書き込みません。子会社の規程もここに入れないでください。 混ぜると、現地の条項を引いたときに別の子会社の条項が候補に出ます。

対応表の列は、判定、本社条番号、原文の条番号、原文、訳、差分です。12社分を縦に積んだ集計表も別に作ります。 「贈収賄の禁止がどの子会社に入っているか」が、そこで一覧になります。

人が確認する

人が開くのは absent と divergent のものだけです。 matched は一覧で流し見ます。全件を開く設計にすると、第10章の8.0時間には収まりません。

1. absent を先に見る … 本当に無いのかを、原文の目次と該当しそうな章で確かめます。ここが対応表の成果です
2. divergent の差分を確かめる … difference の数値や期間を、訳ではなく原文の該当箇所で見ます
3. 現地法による差かどうかを仕分ける … 現地の規制で本社どおりにできない事項は、その旨を記録します。適否の判断はしません
4. 判定を覆したら記録し、本社法務へ回す … 必要なものは現地の弁護士に照会します

3番目を対応表の上で終わらせないでください。 差があることと不備であることは違い、判断は現地の弁護士に確かめます。

目標は、15件をならして1件30分です。 absent と divergent が1件あたり数件に収まる想定で、それより多い月は、必須事項の書き方が広すぎるか、対訳表に語が足りていません。

例外に対処する

上から3行目が、この構成の守りどころです。 候補ゼロを absent に固定すれば、検索を直す作業と判定を直す作業が分かれます。

最後から2行目について補足します。 @search.rerankerScore の分布は若干変動しうるとされ、しきい値を細かくしすぎないよう案内されています。

記録を残す

• 原文ファイルと、子会社・種類・版・施行日・受け取った日
• 条項に切った結果（原文の条番号の表記をそのまま含む）
• 検索で出した候補の一覧と、そのときのスコア
• AIが返したJSONの全文と、Python 側の検証の結果
• 人が判定を覆した記録 … どの事項を、どちらに変えたか
• 参照した本社規程の版と、必須事項の一覧の版、対訳表の版
• 本社法務へ回した日と、現地の弁護士への照会の有無

下から2つ目が、いちばん重要なログです。 本社規程が改訂されると、過去の対応表の意味が変わります。 「当時どの版と突き合わせたか」が残っていないと、やり直す範囲が決まりません。必須事項の一覧も同じで、項目を1つ足せば、それ以前の対応表は「その事項を見ていない表」になります。

人が覆した記録は、対訳表と検索の改善に使います。 absent を matched に覆すものが続くなら、検索で候補が出ていません。