例規の改正案の改め文と新旧対照表を突き合わせ、食い違い・条番号のずれ・引用条項の追随漏れ・用字用語の誤りを審査の前に拾う

処理の起点を決める

起点は、起案した課が改正案を決まったフォルダに保存したことです。 フォルダは例規の種類ごとではなく1つにし、ファイル名に例規の番号（例規データベースの管理番号）を入れる規則にします。例規の番号が無いファイルは処理せず、保存した課に「例規の番号を入れてください」と返します。

改め文と新旧対照表は、同じフォルダに対で保存してもらいます。 片方しか無いときは処理を待ち、24時間たっても揃わなければ、保存した課に知らせます。 片方だけで点検すると、突き合わせの結果が出ません。

法規担当が審査の途中で直した版も、同じ規則で保存し直せば、もう一度点検が動きます。 何度目の点検かは、ファイルの版の番号で残します。

入力データを集める

質を決めるのは、いちばん下の基準の一覧です。 一覧には、内閣法制局の「法令における漢字使用等について」から、常用漢字表にあっても仮名で書くもの（「且つ」は「かつ」、「但し」は「ただし」、「因る」は「よる」など）と、常用漢字表にない漢字を使う言葉の書き方を入れます。そのうえに、法規担当の手元のメモにある自治体独自の決まりを足します。この一覧が、ベテランの職員の観点を文字にしたものになります。

現行の本文は、「最新の改正まで反映したもの」であることを確かめて使います。 例規データベースへの反映が遅れていると、その本文と比べた結果がすべてずれます。取り出した本文に、最後に反映した改正の日付を付けて残します。

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

改め文と新旧対照表は、保存されたファイルをテキストと表に分けて読みます。 新旧対照表は表の形のまま、行ごとに改正前の欄と改正後の欄の文を取り出します。傍線の有無も、文字の範囲として取り出します。

全例規の本文は、毎晩まとめて取り出しておきます。 引用の検索は改正案ごとに行いますが、1,500本の例規を毎回取り出すと時間がかかります。 毎晩の写しと、その日の改正の反映の有無を確かめて使います。

条・項・号は、本文を構造に直してから扱います。 「第○条」「第○項（項番号の2、3…）」「第○号（一、二…）」の区切りで本文を分け、条・項・号の番号で位置を指せる形にします。 操作の一覧を当てるのも、引用を拾うのも、この形の上で行います。

AIへ渡す前に整形する

1. ファイルの対を確かめる … 改め文と新旧対照表がそろっているか、例規の番号が一致しているかを見ます
2. 現行の本文を取り出す … 例規データベースから、最終の改正日付きで取り出します
3. 本文を条・項・号の構造に直す … 現行の本文と、新旧対照表の両欄を同じ形にします
4. 改正前の欄を現行の本文と比べる … ここで食い違えば、改め文の点検に進む前に指摘します
5. 表記をそろえる … 全角・半角、空白、改行の違いを比較の前にそろえます。文字そのものは変えません
6. 改め文を文ごとに分ける … 「第○条中」「第○条を」「附則」などの区切りで分けます

4番目を先に行うのが大事です。 改正前の欄が現行の本文と違えば、その改正案は古い本文をもとに作られています。 そのまま改め文の点検に進むと、指摘が何十件も出て、本当の原因が埋もれます。最初に「改正前の欄が現行の本文と違います」と1件だけ返します。

5番目で文字を変えないのは、 用字用語の誤りまで「そろえて」消してしまわないためです。そろえるのは空白と全角・半角の違いだけにします。

AIに処理させる

させるのは2つです。1つは改め文を改正の操作の一覧に直すこと、もう1つは用字用語と言い回しを基準の一覧に照らして校正することです。

1つ目で「改める前の文字」を必ず書かせるのは、 プログラムがその文字を現行の本文の指定の位置で探すためです。見つからなければ、改め文が存在しない文字を改めようとしていることになり、 それ自体が指摘になります。

3行目がいちばん起きやすい失敗です。 「校正してください」とだけ頼むと、モデルは読みやすさの観点で言い換えを提案します。例規の言葉は、読みやすさより他の例規との統一が優先です。 指摘を基準の一覧に当たるものに限り、一覧のどの項目に当たったかを必ず書かせます。

指示内容を固定する

改め文を操作の一覧に直す指示です（用字用語の校正は、別の指示で呼びます）。

あなたは自治体の法規担当で、例規の一部改正の改め文を読み、
改正の操作を一つずつ書き出す担当です。

【すること】
改め文の各文を読み、次の形で操作を書き出してください。
- target: 対象の条・項・号（例：第5条第2項第3号、附則第2項、別表第1）
- op: replace（改める）／insert（加える）／delete（削る）／
      renumber（繰り上げ・繰り下げ）／replace_all（全部を改める）
- before_text: 改める前の文字（改め文の「　」の中をそのまま）
- after_text: 改めた後の文字（改め文の「　」の中をそのまま）
- new_number: 繰り上げ・繰り下げのときの新しい番号
- source_sentence: 根拠にした改め文の一文

【厳守事項】
- 改め文に書かれた操作だけを書き出してください。
  新旧対照表や、あなたの知識で操作を補わないでください。
- before_text と after_text は、改め文の「　」の中を一字も変えずに写してください。
  表記を直したり、句読点を足したりしないでください。
- 1つの文に複数の操作があるときは、書かれた順に分けて書き出してください。
- 対象や文字が読み取れない文は、op を unparsed にし、
  source_sentence に原文を入れてください。推測で埋めないでください。
- 改正の内容がよいか悪いかを書かないでください。

【改め文】{kaimebun}
【対象の例規の題名と番号】{reiki_title}

「新旧対照表で補わない」を明記しないと、補います。 改め文の操作が足りないとき、モデルは手元の新旧対照表から「本来あるべき操作」を足して一覧を完成させます。それをされると、改め文の書き漏れという、いちばん見つけたかった食い違いが消えます。 新旧対照表は、この呼び出しには渡しません。

「一字も変えずに写す」も同じ理由です。 改め文の「　」の中に誤字があれば、そのまま写させ、本文の中で見つからないという形で指摘に出します。

用字用語と言い回しの校正は、別の呼び出しで次のように指示します。

あなたは自治体の法規担当で、例規の改正案の用字用語と言い回しを、
渡された基準の一覧に照らして点検する担当です。

【すること】
改正後の本文と改め文を読み、基準の一覧のどれかに当たる箇所を書き出してください。
箇所ごとに、位置（条・項・号）、現在の表記、基準の表記、
当たった基準の番号（rule_ref）を書いてください。

【厳守事項】
- 基準の一覧に無い観点で指摘しないでください。
  読みやすさや言い換えの提案をしないでください。
- 改正で変わらない箇所（傍線の無い箇所）は指摘しないでください。
- 引用されている法令の名前や、法令の条文をそのまま引いている箇所は、
  原文の表記を優先し、指摘しないでください。
- 判断に迷う箇所は severity を check にし、must_fix にしないでください。

【基準の一覧】{rules}
【改正後の本文（傍線の範囲付き）】{amended_text}
【改め文】{kaimebun}

「改正で変わらない箇所は指摘しない」は、指摘の数を抑えるためのものです。 古い例規には、現在の基準と違う表記が残っています。改正のたびにそれを全部指摘すると、起案した課は改正と関係の無い直しに追われます。 既存の表記の統一は、改正とは別の機会に行います。

出力形式を固定する

操作の一覧は、次の形のJSONで受け取ります。

{
  "reiki_id": "R-0312",
  "operations": [
    { "seq": 1, "target": "第5条第2項", "op": "replace | insert | delete | renumber | replace_all | unparsed",
      "before_text": "", "after_text": "", "new_number": null, "source_sentence": "" }
  ]
}

プログラムは、操作を当てた結果と比較の結果を、次の指摘の一覧にまとめます。

{
  "reiki_id": "R-0312",
  "base_text_date": "2026-09-01",
  "findings": [
    { "type": "old_column_mismatch | kaimebun_table_mismatch | text_not_found | renumber_gap | citation_not_followed | wording | phrasing | unparsed",
      "location": "", "evidence": "", "rule_ref": "", "severity": "must_fix | check" }
  ]
}

1つ目の理由は、op を列挙型で固定できることです。 操作の種類が決まっていれば、プログラムは種類ごとに当て方を決められます。想定していない操作は unparsed として必ず人に返ります。

2つ目は、指摘の type で起案した課の直し方が分かることです。 old_column_mismatch は新旧対照表を最新の本文で作り直す、text_not_found は改め文の「　」の中を直す、citation_not_followed は引用している箇所の改正を足す、と指摘の種類と直す作業が1対1で対応します。

起案した課の画面では、指摘の一覧を次のように並べます。

3つ目は、base_text_date を残すことです。 比べた現行の本文がいつの改正までを反映していたかが分かれば、後で例規データベースの反映が遅れていたと分かったとき、どの点検をやり直すかが決まります。

システムへ連携する

例規データベースへは書き込みません。 この構成が出すのは指摘の一覧までで、例規の本文を改めるのは、公布の手続きを経たあとの例規データベースの更新作業です。

指摘の一覧は、起案した課ごとに見える範囲を分けます。 他の課の改正案の指摘は、法規担当だけが見られるようにします。

人が確認する

起案した課は、指摘を must_fix から順に直します。 法規担当が確かめる順は次のとおりです。

1. old_column_mismatch を最初に見る … 出ていれば、他の指摘は見ずに課に作り直しを求めます
2. text_not_found と kaimebun_table_mismatch を見る … 改め文と新旧対照表のどちらが正しいかは、起案した課に改正の意図を確かめて決めます
3. citation_not_followed を見る … 他の例規からの引用は、その例規も同時に改正するか、別の改正で対応するかを決めます
4. unparsed を読む … 機械で読めなかった改め文を、目で確かめます
5. wording と phrasing を見る … 基準の出どころ rule_ref を見て、直すかを決めます

2番目を機械で決めないでください。 改め文と新旧対照表が食い違うとき、どちらが起案した課の意図どおりかは、文書の上からは決まりません。 効力を持つのは改め文ですが、意図が新旧対照表の側にあることもあります。

目標は、40件をならして1件30分です。 指摘が用字用語だけのものは10分で済み、引用の追随が要るものは1時間を超えます。

例外に対処する

上から3行目は、AIの問題ではありません。 公布から例規データベースへの反映までの間に次の改正案が上がってくると、比べる本文が古いまま点検されます。 反映の遅れの日数を数えて、反映の段取りを見直す材料にします。

記録を残す

• 改正案のファイル（版の番号付き）と、比べた現行の本文（base_text_date 付き）
• 生成AIに渡した改め文と、返ってきた操作の一覧
• 操作を当てて作った改正後の本文と、比較の結果
• 指摘の一覧と、起案した課・法規担当がそれぞれの指摘をどう扱ったか
• 基準の一覧のどの項目で指摘が出たかの件数

4つ目で「どう扱ったか」を残すのは、指摘の質を測るためです。 直さなかった指摘が多い種類は、基準の一覧か指示のどちらかが実態に合っていません。

最後の行は、各課の研修の材料になります。 毎月同じ基準で指摘が出るなら、その基準を起案の手引きの最初に置きます。