自治体の担当課が条例・規則の改正に合わせて出す住民向けのお知らせを、改正の内容と新旧対照表から、対象者・変わる点・手続きを書いた下書きにする

処理の起点を決める

起点は、担当がお知らせ作成の画面に、新旧対照表と改正の全文を置いて依頼したことです。 画面は庁内の ID でログインした職員だけが使います。公布の前の案の段階では使いません。 議決や決定の前の文から住民向けの文を作ると、修正のたびに作り直しになり、未確定の内容が外に出る経路にもなります。

入力欄は、置いた文書のほかに4つです。 問い合わせ先（課・係・電話）、窓口と受付の時間、手続きの方法（申請が要るか、様式の置き場所）、課として決めている運用（経過措置の対象をどう案内するか）です。空欄のまま送ると、下書きの該当箇所は「【担当課で記入】」のまま出ます。

1件の改正で、お知らせを1本作ります。 複数の条例をまとめて改正する一括の条例でも、住民にとって別の話なら別のお知らせにします。どこで分けるかは担当が画面で選びます。

入力データを集める

質を決めるのは、3行目の「改正後の条の全体」です。 新旧対照表だけを渡すと、「100分の30に改める」の100分の30が何の割合なのかが分かりません。改正された条の全体と、その条が引いている別表を一緒に渡します。

用語の言い換え表は、文書の担当が育てます。 「なお従前の例による」→「これまでの決まりで扱います」、「納付義務者」→「納める人」のように、お知らせを作るたびに担当が直した言い方を足していきます。

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

例規集の仕組みから出した Word と PDF を、中継プログラムが文字に直します。 新旧対照表は表の形をしているので、左右の列を崩さずに取り出すことが大切です。Word なら表の構造のまま読み、PDF しか無いものは表として読める方法で取り出します。

左右の取り違えは、ここで止めます。 新旧対照表の列の見出し（「改正後」「改正前」）を読み、どちらの列が新しいかを中継プログラムが決めてからモデルに渡します。自治体によって左右が逆のことがあるからです。

AIへ渡す前に整形する

1. 左右の列を確定する … 見出しから改正後と改正前を決め、new_text と old_text に分けます
2. 条と項ごとに分ける … 1つの変わる点が1つの単位になるように、条・項・号で区切ります
3. 附則を別に持つ … 施行日と経過措置は、本文と分けて渡します
4. 引いている条と別表を足す … 「別表第2」「第3条第1項」のような参照を、改正後の版から引いて添えます
5. 数字と日付を抜き出しておく … 元の文書に出てくる金額・割合・日付・期間を一覧にし、7番目の照合に使います
6. 課の入力を確かめる … 問い合わせ先と手続きの欄が空なら、画面で担当に知らせます

5番目は、モデルに渡す前に行います。 和暦と西暦、漢数字と算用数字、「100分の30」と「30％」のように、同じ値の書き方を正規化して一覧にしておくと、後の照合で書き方の違いを誤りとして拾わずに済みます。

AIに処理させる

1段目でさせるのは、変わる点を1つずつ取り出し、元の文を写したうえで、誰に・何が・どう変わるかを短く言い直すことです。 2段目でさせるのは、1段目で取り出した点と課の入力だけを使って、決まった構成のお知らせを書くことです。

2段目の構成は、「結論を先に」の順にします。 「公用文作成の考え方」は、結論は早めに示し、続けて理由や詳細を説明すること、一文を短くし、一文の論点を一つにすること、三つ以上の情報を並べるときは箇条書を利用することを示しています。解説・広報等では、記事の冒頭で法令等をそのまま提示することは読み手の負担になる場合が多いので、条文は最後に参照として置きます。

3行目がいちばん起きやすい失敗です。 「月額4,000円を3,000円に改める」改正から、モデルは住民に分かりやすくしようとして「年間で12,000円の負担が減ります」と書きます。計算が合っていても、その数字は改正の文に無く、照合で確かめられません。 数字は元の文にあるものだけにします。

指示内容を固定する

1段目の指示です（構造化出力のスキーマと一緒に渡します）。

あなたは市役所の文書の担当を手伝う立場で、
条例・規則の改正の新旧対照表と附則から、変わる点を取り出します。

【取り出し方】
1. 変わる点を、条・項・号ごとに1つずつ取り出してください。
2. old_text と new_text には、新旧対照表の文をそのまま写してください。
   言い換えたり、省いたりしないでください。
3. plain_change には、何がどう変わるかを、住民向けの短い文で書いてください。
4. affected には、改正後の条の全体に書かれている範囲で、影響を受ける人を書いてください。
   書かれていなければ空欄にしてください。
5. 附則から、施行日と経過措置を取り出し、附則の文をそのまま写してください。

【厳守事項】
- 新旧対照表と附則、添えた条と別表に書かれていることだけを使ってください。
- 書かれていない対象者、手続き、期限を推定で足さないでください。
- 金額・割合・日付を計算したり、別の単位に換算したりしないでください。
- 改正前と改正後を取り違えないでください。old_text は改正前、new_text は改正後です。
- 経過措置の対象が読み取れないときは、needs_check を true にしてください。

2段目の指示です。

あなたは市役所の広報の文を書く担当を手伝う立場で、
1段目で取り出した変わる点と、担当課が書いた情報だけを使って、
住民向けのお知らせの下書きを書きます。

【構成】見出し／ひとことで言うと／対象になる人／変わる点／いつから／
手続き／問い合わせ先／改正した条例・規則の名前

【書き方】
- 文末は「です・ます」にし、「ございます」は使わないでください。
- 一文を短くし、一文に1つのことだけを書いてください。
- 変わる点が3つ以上あるときは、箇条書きにしてください。
- 用語の言い換え表にある言葉は、表の言い方にしてください。

【厳守事項】
- 変わる点の一覧と担当課の情報に無いことを書かないでください。
- 担当課の情報が空欄の項目は「【担当課で記入】」と書いてください。
- 数字と日付は、変わる点の一覧に書かれたとおりに書いてください。
  計算や換算をしないでください。
- 改正の理由は、担当課が渡した理由の範囲で1〜2文にしてください。

1段目で「そのまま写す」を2回書くのは、写させないと言い換えるからです。 言い換えた文から2段目を書くと、どこが元の文でどこがモデルの言葉かを後から分けられません。写した文と言い直しの文を別の項目に置くことで、照合ができるようになります。

出力形式を固定する

1段目は、次の形の JSON で受け取ります。

{
  "ordinance_title": "",
  "promulgated_on": "",
  "changes": [
    { "article": "第5条第2項",
      "old_text": "", "new_text": "",
      "plain_change": "", "affected": "",
      "needs_check": false }
  ],
  "effective": { "date_text": "", "source_text": "" },
  "transition": [ { "summary": "", "source_text": "", "needs_check": false } ]
}

2段目は、お知らせの項目ごとの文を同じく JSON で受け取り、中継プログラムが画面の書式に並べます。

{
  "headline": "",
  "summary": "",
  "who": [""],
  "what_changes": [""],
  "from_when": "",
  "procedure": "",
  "contact": "",
  "reference": "",
  "placeholders": [""]
}

1つ目の理由は、old_text・new_text・source_text を元の文書と照らせることです。 中継プログラムは、これらの文字列が新旧対照表と附則にそのまま含まれるかを確かめます。含まれなければ、その点に赤い印を付けて担当に見せます。

2つ目は、項目の順をスキーマで決められることです。 構造化出力は、出力の項目をスキーマの順に従わせます。 見出し、結論、対象者の順が崩れないので、課ごとに構成がばらつきません。すべての項目を必須にし、additionalProperties を false にする決まりがあるので、空の項目は空のまま返り、勝手な項目は増えません。

3つ目は、placeholders で書き残しを数えられることです。 「【担当課で記入】」が残っている項目の一覧で、決裁に回す前に埋めるべき箇所が分かります。

文字数の上限はスキーマで縛れません。 文字列の maxLength や配列の minItems・maxItems は、構造化出力が対応していないキーワードです。一文の長さは、7番目の表記の点検でプログラムが数えます。

下書きを受け取った後、中継プログラムは次の点検をします。 どれも規則で書け、モデルには判断させません。

照合で見るのは「含まれるか」だけです。 数字が合っていても、旧と新を入れ替えて書いた下書きは、数字の照合では拾えません。写した文の照合と、old_text・new_text の項目の分け方がそこを受け持ちます。

システムへ連携する

呼び出しには、Chat Completions を使います。 Responses API はやり取りの履歴を保存する機能を持ち、データがサービスに保存されるとされています。お知らせ作りはやり取りを続ける必要が無いので、履歴を保存しない呼び出し方を選びます。

ウェブサイトの管理の仕組みには、つなぎません。 下書きが決裁を経ずに公開される経路を作らないためです。

人が確認する

担当、課長、文書の担当の3か所で見ます。 下書きは、そのまま公開できる文としては扱いません。

1. 担当が赤い印から見る … 照合で合わなかった数字・日付・写した文の前後を、新旧対照表と見比べます
2. 担当が「【担当課で記入】」を埋める … 問い合わせ先、手続き、運用を書き足します
3. 課長が対象者と手続きを確かめる … 課として案内する範囲と合っているかを見ます
4. 文書の担当が施行日と経過措置を確かめる … 附則の文と、お知らせの「いつから」の書き方を比べます

4番目を省かないでください。 経過措置は、住民が古い規定と新しい規定のどちらで扱われるかを決める一文です。お知らせで言い換えるときに意味が変わりやすく、例規の審査に慣れた職員が見る価値があります。

目標は、40件をならして1件60分です。 下書きの確認と書き足しで40分、決裁と文書の担当の確認への受け答えで20分という想定です。

例外に対処する

上の2行が、この構成でいちばん大事な例外です。 どちらも、モデルが元の文書に無いものを書いたという印です。印が出た点は、直して使うのではなく、元の文書から書き直します。

記録を残す

• 置いた文書（新旧対照表、改正の全文、添えた条と別表）と、置いた担当・日時
• 課の入力欄の内容
• 1段目と2段目の出力の全文、使ったスキーマの版、指示の版
• 照合と表記の点検の結果（どの数字・日付・写した文が合わなかったか）
• 担当が直した後の文、課長の決裁の日、文書の担当の確認の記録
• 公開の日と、公開後に訂正したかどうか

4つ目と6つ目を残すのは、照合の効き目を確かめるためです。 照合で印が付いたのに公開後に訂正が出たなら、印の見方の運用に穴があります。印が付かずに訂正が出たなら、照合の規則に穴があります。

担当が直した言い方は、用語の言い換え表に足す候補として、文書の担当が月ごとに見ます。