社内規程を改定したときに、改定された条項だけを英語版の規程に訳し直し、用語集と既存の訳にそろえた差分訳の案を作る

処理の起点を決める

規程ライブラリの状態の列が「施行確定」に変わったことを起点にします。 SharePoint コネクタのトリガー「ファイルが作成または変更されたとき (プロパティのみ)」で受け、トリガーの条件で状態の列を絞ります。このトリガーはライブラリの列に格納されたプロパティだけを返すので、ファイルの中身は後の手順で取り出します。

保存しただけでは動かしません。 規程の主管部署は、改定の検討中にも何度もファイルを上書きします。そのたびに差分訳を作ると、確定していない改定の英訳が確認リストにたまり、どれが施行される版か分からなくなります。 施行が決まった版だけを対象にします。

あわせて、月に1回、英語版の反映が終わっていない規程を一覧にする定時実行を置きます。確認リストに「未承認」の行が残っている規程と、日本語版の施行日から英語版の改定日までの日数を並べ、反映の遅れを見える状態にします。

入力データを集める

質を決めるのは、改定前の版です。 改定後の版だけを渡すと、どこが変わったかを判断するのがAIになります。改定前の版を版の履歴から取り出せることが、この構成の前提です。 規程ライブラリで版管理を有効にし、施行した版を「主要な版」として残す運用にします。

用語集の「使わない訳」の列が効きます。 「従業員」なら employee を使い、staff や worker は使わない、といった形で並べます。使ってほしい訳だけでなく、使ってほしくない訳を書いておくと、後段の点検が機械でできます。

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

「アイテムまたはファイルの変更を取得する (プロパティのみ)」は、リストのバージョン管理が有効になっている必要があります。 開始には版ラベル（例：3.0）や日付を指定でき、マイナー（下書き）の版を含めるかも選べます。下書きの版は含めない設定にします。 含めると、検討中に上書きされた版との差分を計算してしまいます。

前の版のファイルの中身は、SharePoint の REST API で版の履歴から取ります。 「SharePoint に HTTP 要求を送信する」はアクセス権のある SharePoint の REST API を実行できる操作で、公式にも注意して使うよう書かれています。 フローの接続に使うアカウントには、規程ライブラリの読み取りと確認リストへの書き込みだけを与えます。

呼び出しの回数にも上限があります。 SharePoint コネクタは接続ごとに60秒あたり600回が上限です。組織変更のように何十本もの規程が同時に「施行確定」になる日は、規程ごとに順番に処理するよう、フローの同時実行を絞ります。

AIへ渡す前に整形する

1. 本文の取り出し … Word ファイルから段落を順に取り出し、表と注記は別に分けます
2. 条・項・号への分割 … 「第N条」「（見出し）」「2」「(1)」の並びで分け、条項ごとに art12-2-1 のような識別子を付けます。英語版は Article 12 (2) (i) の並びで同じ識別子を付けます
3. 差分の計算 … 改定前後の条項の並びを SequenceMatcher で比べ、get_opcodes() のタグで「変更」「追加」「削除」を決めます
4. 番号だけの変更の判定 … 本文が同じで条番号だけがずれた条項は「番号のみ」とし、AIには渡しません
5. 参照の洗い出し … 本文中の「第N条」「前条」「別表N」を拾い、番号がずれた条を参照している条項に印を付けます
6. 用語の拾い出し … 変わった条項の日本語に用語集の語が出てくるかを文字列で照合し、該当する行だけを集めます
7. 今の英文の取り出し … 識別子で英語版の該当条項を引きます。引けない条項は「英語版に対応なし」とします

4番目と5番目を、AIに任せないでください。 条を1つ挿入すると、それ以降の条はすべて「番号が変わった」ことになります。これを全部AIに渡すと、番号を直すついでに本文まで訳し直されます。 番号のずれと参照の書き換えは、規則で直せる作業です。

6番目で用語集を丸ごと渡さないのも同じ理由です。 数百語の用語集を毎回渡すと、その条項に関係のない語の訳に引きずられます。その条項に出てくる語だけを渡します。

AIに処理させる

させるのは、変わった条項について、今の英文を最小限だけ直した案を作ることです。 新しく追加された条項は新しく訳し、削除された条項は AI に渡さず、英語版からも削除する印だけを付けます。

1行目がいちばん起きやすい失敗です。 生成AIに英文を渡すと、頼まなくても言い回しを整えます。整った英文になっても、その変更は日本語の改定とは関係がありません。 英語版の改定履歴に、改定していない変更が混ざります。

指示内容を固定する

あなたは、日本語の社内規程の英語版を管理する法務部の担当者です。
日本語の規程が改定されました。英語版を、改定と同じ範囲だけ直してください。

【渡すもの】
- 改定前の日本語の条項：{ja_before}
- 改定後の日本語の条項：{ja_after}
- 差分の種類：{change_type}（modified / added）
- 今の英語版の条項：{en_current}（added のときは空）
- この条項に出てくる用語集の語：{glossary}
- 同じ規程のほかの条項の英文（文体の参考）：{en_context}
- 書き方の決まり：{style_rules}

【厳守事項】
- 改定前と改定後の日本語で、変わっていない部分に当たる英文は、
  1語も変えないでください。言い回しの改善もしないでください。
- 変えた部分は、changes に「日本語のどの変更に合わせて、
  英文のどこをどう直したか」を1件ずつ書いてください。
- 用語集にある語は、用語集の英訳を必ず使ってください。
  「使わない訳」の列にある訳は使わないでください。
- 用語集に無い語で、規程の中で意味を持つ語（役職名、制度名、
  手続きの名前など）が出てきたら、訳を確定させずに new_terms に
  入れ、候補を2つまで挙げてください。本文には第1候補を入れてください。
- 数字、日数、金額、割合、日付は、日本語のとおりに書いてください。
  単位の換算や丸めをしないでください。
- 条番号と、ほかの条項への参照（第N条、前条、別表）は直さないでください。
  そのまま残してください。
- 日本語に書かれていない説明、注釈、例を足さないでください。
- 日本語の意味が2通りに読めて、英文を1つに決められないときは、
  ambiguity にその箇所と2通りの読み方を書いてください。
- added のときは、同じ規程のほかの条項の文体（shall の使い方、
  主語の書き方）に合わせてください。

「1語も変えない」を最初に置き、「言い回しの改善もしない」を重ねて書いています。 「変わった部分だけ直す」とだけ書くと、変わった部分を直したうえで、ほかの文も「ついでに」整えます。禁じるのは、頼まれていない改善そのものです。

用語集に無い語を本文に入れさせたうえで new_terms にも出させるのは、空欄の英文を確認リストに並べないためです。第1候補が入った文を読みながら、担当者が訳を決められます。決めた訳は用語集に足し、次の改定からは用語集の語として渡します。

出力形式を固定する

次の形のJSONで受け取ります。 構造化出力で strict: true を指定し、スキーマどおりに返させます。

{
  "clause_id": "art12-2",
  "change_type": "modified",
  "en_proposed": "",
  "changes": [
    { "ja_change": "", "en_before": "", "en_after": "" }
  ],
  "glossary_applied": [
    { "ja": "", "en": "" }
  ],
  "new_terms": [
    { "ja": "", "candidates": ["", ""], "used_in_text": "" }
  ],
  "ambiguity": [
    { "ja_text": "", "reading_1": "", "reading_2": "" }
  ]
}

1つ目の理由は、changes があると確認が速くなることです。 英文を最初から読まなくても、日本語のどの変更に合わせて英文のどこを直したかが1行ずつ並びます。changes に無い箇所の英文が変わっていれば、それは頼んでいない変更です。

2つ目は、後段のプログラムで機械的に点検できることです。 構造化出力では、すべての項目を必須にし、オブジェクトには additionalProperties: false を付ける決まりがあります。項目が欠けた出力が来ない前提で、点検を組めます。 オブジェクトの項目は合計100個まで、入れ子は5段までなので、上の形で十分に収まります。

ただし、文字数や形式の制約はスキーマに書けません。 文字列の minLength、maxLength、pattern、format、配列の minItems、maxItems は使えないキーワードです。「en_proposed が空でないこと」や「候補が2つまで」は、受け取った後にプログラムで確かめます。

後段の点検は次の4つです。

システムへ連携する

英語版の Word ファイルへは、この構成からは書き込みません。 承認された英文の反映は担当者が行います。英語版は外国籍の社員が日々読んでいる文書で、誤って書き換えると、そのまま読まれます。 反映まで自動にするのは、確認リストの運用が半年ほど安定してからです。

確認リストの列は、左から「規程名」「条項」「差分の種類」「改定前の日本語」「改定後の日本語」「今の英文」「案の英文」「変更の説明」「点検の印」「状態」です。 状態は「未確認」「修正して承認」「そのまま承認」「差し戻し」の4つにします。

人が確認する

1. 点検の印が付いた行から見る … over_rewrite、number_mismatch、glossary_violation が付いた行は、案の英文をそのまま使えない可能性が高い行です
2. changes と、今の英文・案の英文の違いを見比べる … 確認リストには差分を色付けして表示します。changes に書かれていない色付きの箇所があれば、元に戻します
3. new_terms の訳を決める … 候補から選ぶか、別の訳を決めます。決めた訳は用語集への追加の欄に入れます
4. ambiguity のある行は、主管部署に日本語の意図を確かめる … 英文を決める前に、日本語の規程のほうが2通りに読めることを主管部署に伝えます
5. 承認した英文を英語版に反映する … 反映の後、英文の規程を書き慣れた担当者が、改定された条項だけを最終確認します

4番目は、この構成の副産物です。 英訳しようとして初めて、日本語の規程が2通りに読めることに気づく場面があります。それを英語版の側だけで解決しないでください。 日本語の規程を直すべきかは、主管部署が決めることです。

最終確認は全文ではなく、改定された条項だけです。 これまで1名に集まっていた全体の読み直しを、条項単位の確認に変えることで、最終確認の負荷を減らしつつ、英文の質の基準は1名が持ち続けます。

例外に対処する

1行目の線引きは先に決めておきます。 全面改定の規程を差分訳の仕組みで処理すると、変更が多すぎて changes の確認が全文を読むより重くなります。差分訳が向くのは、改定が規程の一部にとどまる場合です。

記録を残す

• 処理した規程と、改定前・改定後の版ラベル、英語版の版ラベル
• 条項ごとの差分の種類（変更／追加／削除／番号のみ）
• AIに渡した入力（日本語、英文、用語）と、返ってきたJSONの全文
• 点検の結果（over_rewrite、number_mismatch、glossary_violation）
• 担当者が案をどう直したか（案の英文と、承認した英文の両方）
• 用語集に足した語と、その語が初めて出た規程・条項
• 日本語版の施行日と、英語版の改定日

5つ目が、この構成を育てる材料です。 担当者が直した箇所を月に1回見直すと、AIが繰り返し外す言い回しが分かります。多くは用語集か書き方の決まりに1行足せば直ります。

最後の行で、英語版の遅れを数字で追えます。 日本語版の施行日から英語版の改定日までの日数を規程ごとに並べ、30日を超えているものを月次の一覧に出します。