市の広報紙とホームページのお知らせを、公開前に表記ルールと日付・曜日、施設や問い合わせ先の電話番号まで台帳と照らして校正する

処理の起点を決める

起案課が SharePoint の「校正依頼」ライブラリに原稿を置いたことを起点にします。 Power Automate の SharePoint コネクタのトリガー「When a file is created (properties only)」を使います。ライブラリに項目が作成されたときに動き、返すのはライブラリの列に保存されたプロパティだけとされています。本文は、返ってきたファイルの識別子を使い「Get file content」の手順で取り出します。

「When a file is created in a folder」は使いません。 非推奨とされ、サブフォルダーに追加されたファイルでは動かないと書かれています。課ごとにフォルダーを切ると、原稿を置いても何も起きない課が出ます。ライブラリは1つにし、課は列で分けます。

列は、置く側に必ず入れてもらいます。 媒体（広報紙／ホームページ）、記事番号、掲載予定日、起案課の4つです。記事番号が、紙版とWeb版を結びつける唯一の手がかりになります。 記事番号の無い原稿は処理せず、起案課へ入力を求める通知だけを返します。

締め切り前にまとめて動かすことはしません。 1本置かれるたびに動かし、原稿を置いた日のうちに指摘が戻るようにします。

入力データを集める

質を決めるのは、施設の一覧と電話番号一覧の2つです。 施設に略称の列が無ければ、原稿の「中央公民館」と一覧の「市立中央公民館」が結びつかず、照合できない施設として毎回人に回ります。 電話番号一覧に機構改革の前の名称と番号が無ければ、古い課名を「知らない課名」としか指摘できず、どの課に直せばよいかが出ません。

表記ルールには「直さなくてよい」例外も書きます。 書かれていないと、AIは見出しまで全部を指摘します。

祝日は、内閣府のページで CSV として提供されています。 現在は昭和30年（1955年）から令和9年（2027年）までが収録され、翌年の分は前年の2月に掲載すると説明されています。広報紙には翌年の日程が載ることがあるため、2月の更新を取り込む作業を年間の予定に入れておきます。

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

本文はテキストにしてから渡します。 講座案内は表に日程が書かれていることが多いため、表は1行を1行のテキストに、セルを区切り文字で残します。 1つの文に流し込むと、どの日付がどの回かが分からなくなります。

施設の一覧と電話番号一覧は、AIに丸ごと渡しません。 渡すのは、照合の処理の側です。AIが拾った名称と番号を、Python の側で一覧と突き合わせます。 一覧を丸ごとプロンプトに入れると、AIが一覧の中から「それらしい番号」を選んで答えを作ってしまいます。

別の媒体の版は、両方がそろったときだけ比べます。 紙版が先に届くことが多いため、後から届いた版の処理のときに、指摘一覧に残した先の版の抽出結果を読み出して比べます。

AIへ渡す前に整形する

1. 形式の確認 … Wordの文書であることを確かめます。PDFで置かれたものは、起案課に元のWordを求めます
2. 本文の取り出し … 本文、見出し、表をテキストにします。表は行ごとに区切ります
3. 全角と半角の揺れの記録 … 数字や記号の全角・半角を、直さずにそのまま残し、どこにどちらが使われているかを記録します
4. 掲載予定日の確認 … 列の掲載予定日が空なら処理を止め、起案課へ入力を求めます
5. 年の補い方を決める … 原稿の日付は「10月18日」のように年が書かれていないことが多いため、掲載予定日を基準に年を決める規則を先に決めておきます（掲載予定日より前の月なら翌年、など）
6. 同じ記事番号の版の検索 … 別の媒体の版があれば、その抽出結果を読み出します
7. 字数の確認 … 極端に長い原稿は、見出しの単位で分けて渡します

3番目で数字を直さないのは、それ自体が指摘の対象だからです。 前処理で半角にそろえてしまうと、表記ルールに外れた全角の数字が、AIに渡る前に消えます。 前処理は、見つけたいものを消さないようにします。

5番目を決めずに進めると、年末年始の記事で誤ります。 12月に掲載する記事の「1月10日」は翌年の1月です。年の補い方をAIに任せると、記事ごとに違う年で曜日を計算します。 規則にしておけば、誤りがあっても同じ規則で直せます。

AIに処理させる

させるのは、次の2つだけです。 本文から照合に使う項目を拾い出すことと、表記ルールに外れた箇所をルールの番号付きで指摘することです。

拾い出しでは、原文の文字列をそのまま返させます。 「10月18日（土）」を「2026-10-18」に直して返させると、原稿に書かれた曜日が消え、食い違いを確かめられなくなります。 月日の値と、書かれた曜日の文字列を、別の項目として返させます。

1行目がいちばん大事です。 誤った曜日もほかの項目と同じ調子で返ってくるため、読む側は計算とAIの推測を見分けられません。曜日の指摘は、すべて計算から出します。

指示内容を固定する

あなたは市の広報係で、各課から届いたお知らせ原稿を校正する立場です。
次の2つの作業だけを行ってください。

【作業1：項目の拾い出し】
本文から、次の項目をすべて拾い出してください。
- 日付（書かれた曜日を含む）。どの催しの何回目の日付かも書く
- 時刻（開始・終了・受付）
- 施設名（会場、窓口、持参先など）
- 課名・係名と電話番号（問い合わせ先、申込先など）
- 金額、定員、対象者
拾い出すときは、原文の文字列をそのまま raw に入れてください。
書き直したり、正しい形に整えたりしないでください。
書かれていない項目は拾わないでください。推測で補わないでください。

【作業2：表記の指摘】
下の表記ルールに外れている箇所を指摘してください。
- 指摘には、必ずルールの番号を付けてください
- ルール表で「直さなくてよい」とされている例外には、指摘を付けないでください
- ルール表に無い好みの言い換えは、style_note として別に書いてください
- 同じ記事の中で、同じものを違う表記で書いている箇所も指摘してください

【してはいけないこと】
- 曜日が正しいかどうかを判断しないでください。曜日は別の処理で計算します
- 電話番号や課名が正しいかどうかを判断しないでください
- 施設が休館日かどうかを判断しないでください
- 年が書かれていない日付に、年を補わないでください
- 原稿全体を書き直した文を返さないでください
- 催しや施策の内容が妥当かどうかを書かないでください

【媒体】{medium}
【掲載予定日】{publish_date}
【表記ルール】{style_rules}
【本文】{body_text}

「曜日が正しいかを判断しない」を明記しないと、AIは善意で曜日を直します。 本文に「10月18日（金）」とあれば、指示が無くても「（土）の誤り」と書き添えることがあります。その指摘が正しくても、誤っていても、計算の結果と二重に出て、どちらを信じるかを人が迷います。 禁じるのは、曜日の判断そのものです。

「年を補わない」も同じ理由で、年は前処理の規則で決めます。

ルールに無い言い換えを別に書かせるのは、同じ一覧に並ぶとルールの指摘まで「好みの問題」として読み飛ばされるからです。

出力形式を固定する

Azure OpenAI の structured outputs を使い、strict を有効にして次の形のJSONで受け取ります。

{
  "article_no": "",
  "medium": "print | web",
  "extracted": {
    "dates": [
      { "raw": "", "month": 0, "day": 0, "weekday_written": "", "event": "", "session": "" }
    ],
    "times": [ { "raw": "", "kind": "start | end | reception", "event": "" } ],
    "facilities": [ { "raw": "", "role": "venue | counter | other" } ],
    "contacts": [ { "dept_raw": "", "phone_raw": "", "role": "inquiry | application" } ],
    "values": [ { "raw": "", "kind": "fee | capacity | target" } ]
  },
  "style_findings": [
    { "text": "", "rule_no": "", "suggestion": "" }
  ],
  "style_notes": [ { "text": "", "note": "" } ]
}

strict を使うのは、後ろの Python が項目名で値を読むからです。 公開されている説明では、structured outputs はモデルが与えた JSON Schema に従うようにする機能で、有効な JSON だけを保証する従来の JSON モードとは違い、スキーマへの厳密な準拠を求められるとされています。

スキーマには決まりがあります。 すべての項目を必須にする必要があり、任意の項目は null との組み合わせで表します。 オブジェクトには必ず additionalProperties: false を付けます。項目の数は全体で100まで、入れ子は5段までとされています。文字列の pattern や format、配列の minItems などのキーワードは使えません。電話番号の形を pattern で縛ることはできないので、形の確認は Python の側で行います。

AIのJSONには「判定」の項目を置いていません。 曜日が合っているか、休館日か、番号が正しいかは、Python が次の形で書き足します。

{
  "check": "weekday | holiday | closed_day | facility_name | phone | dept_name | cross_medium",
  "raw": "10月18日（金）",
  "expected": "土曜日",
  "source": "暦の計算",
  "level": "must_fix | style | ask_owner"
}

ask_owner を別にしているのは、誤りとは限らないからです。 祝日に開く催しや、一覧に無い民間の会場は普通にあります。これを must_fix に混ぜると、毎回「誤りではない」と戻すことになり、指摘一覧が信用されなくなります。

システムへ連携する

CMSへは書き込みません。 この構成が出すのは指摘までで、公開の操作は従来どおり広報係が行います。 校正の仕組みと公開の仕組みがつながっていると、指摘が残ったままの記事が公開される経路ができます。

原稿のWordにも書き込みません。 指摘はリストの行として持ち、原稿に反映するのは起案課か広報係です。 AIが原稿を直接直すと、誰がどこを直したかが分からなくなります。

人が確認する

広報係が見るのは、指摘一覧です。原稿を最初から読み直すことはしません。

1. must_fix を先に見る … 曜日の誤り、休館日の開催、旧番号、紙版とWeb版の食い違い。どれも根拠（暦・一覧・もう一方の版）が行に書いてあるので、確かめて起案課へ戻します
2. ask_owner を起案課に確かめる … 祝日の開催や、一覧に無い会場。広報係では判断できないので、指摘一覧から起案課に回します
3. style の採否を決める … ルールの番号を見て、採るものだけを原稿に反映します
4. 採らなかった指摘に理由を残す … 「見出しのため省略」「固有名詞のため」など

4番目を省かないでください。 採らなかった理由がたまると、表記ルールの例外として書き足すべきものが見えてきます。 同じ指摘を毎月採らないなら、ルール表のほうを直します。

must_fix が毎月同じ課から出ているなら、その課の原稿の下敷きが古いということです。

例外に対処する

上から4行目と最後の行が、運用で一番効きます。 照合の精度は、施設の一覧がどれだけ整っているかで決まります。

記録を残す

• 原稿のファイルと版の履歴（SharePoint の版管理）
• AIに渡した本文と、返ってきたJSONの全文
• Python の照合の結果と、そのとき参照した施設の一覧・電話番号一覧の内容
• 広報係が採った指摘と、採らなかった指摘とその理由
• 起案課に戻した日時と、戻ってきた日時
• 課ごと・指摘の種類ごとの件数

3つ目で「そのときの一覧」を残すのは、一覧が後から変わるためです。 施設の休館日や課の番号が変わった後で、過去の記事の指摘を見直すと、当時は正しかった記載が誤りに見えます。 当時の一覧が残っていれば、その記事が当時正しかったかを確かめられます。