保護者へ配るお知らせを、日付と曜日・持ち物・連絡先の食い違いまで配布前に点検する

処理の起点を決める

事務室の担当者が、点検台帳のメニューから点検を実行したときに動かします。 台帳のスプレッドシートに紐づけたスクリプトは、ファイルを開いたときにメニューを追加でき、項目から任意の関数を呼べます。「提出フォルダを点検」という項目を1つだけ置きます。

ファイルが入るたびに自動で動かす形にはしません。 担当教員は同じお知らせを何度も差し替えます。保存のたびに点検すると、書きかけの原稿への指摘が台帳に積み上がり、どれが最新か分からなくなります。

点検を終えたPDFは点検済みフォルダへ移し、移すのは台帳への書き込みが成功したときだけにします。 提出フォルダに残った数が、そのまま未点検の数になります。

入力データを集める

質を決めるのは、下の3つです。 今年度の設定が無ければ、書かれた「令和7年度」が古いのかどうかを決められません。連絡先一覧に有効な期間の列が無ければ、前年まで正しかった番号が今も正しいように見えます。

年間行事予定は、日付そのものの誤りを拾うために持ちます。 曜日の計算で分かるのは「日付と曜日が合っているか」までで、「10月17日（土）」と正しく書かれていても、運動会が10月24日なら誤りです。 行事名で年間行事予定を引き、日付が一致するかを台帳で見ます。

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

スクリプトは提出フォルダのPDFを読み出し、base64にして Claude API に渡します。Claude API のPDF対応は、URLでの参照、base64でエンコードしたPDF、Files API のファイルIDの3つの渡し方があり、この構成ではbase64を使います。共有ドライブのファイルは外から見えるURLにしないためです。

API の呼び出しは、Google Apps Script の UrlFetchApp で行います。method を post、contentType をJSON、headers にAPIキー、payload に要求の本文を入れます。muteHttpExceptions を true にしておくと、応答が失敗を示しても例外で止まらずに応答が返るので、失敗したPDFだけを飛ばして次へ進めます。

表の右端に書いたとおり、連絡先一覧と年間行事予定はAIへ渡しません。 照合は台帳の数式で行い、AIには文書だけを渡します。AIに一覧を渡すと、文書の番号を一覧の番号に「直して」返すことがあり、見つけたかった食い違いが消えます。

AIへ渡す前に整形する

1. 形式の確認 … PDF以外（ドキュメント、.docx、画像）はPDFにしてから提出するよう差し戻します。.docx はこの渡し方では受け付けられません
2. パスワードの確認 … パスワードや暗号化のあるPDFは読めません。保護を外して提出し直してもらいます
3. サイズの確認 … 1リクエスト32MBが上限です。写真を多く入れた行事の報告は、写真を縮めてから提出してもらいます
4. 児童・生徒の氏名の確認 … 表彰や係分担など、個人名の入ったお知らせかどうかを提出時の区分で見ます。入っているものは氏名を伏せた版を点検に回します（第13章）
5. 同じお知らせの差し替えの確認 … 同じファイル名で提出日時が新しいものがあれば、古いほうの点検結果に「差し替え済み」の印を付けます
6. 年度の設定の読み込み … 設定シートから今年度と、年度の始まりの西暦を読みます

4番目を後回しにしないでください。 表彰や大会結果、班分けのお知らせには生徒の氏名が並びます。提出フォルダを「氏名なし」と「氏名あり」に分けます。

AIに処理させる

させるのは、文書から項目を拾い、書かれた場所とともに一覧にすることと、誤字と文書内の食い違いを指摘することです。 正しいかどうかの判定の多くは、台帳の側に置きます。

AIだけにしかできないのは、「何の日付か」「何の時刻か」を付けることです。 本文の「当日は8時20分に正門へ」と、日程表の「集合 8:30」が同じ集合時刻だと分かるのは、文を読めるからです。この「何の」が付いていれば、値の比較は台帳の数式でできます。 同じ「集合」の行に値が2種類あれば、それが食い違いです。

1行目と2行目が、この構成の中心です。 曜日を書かせると、AIは文書に書かれた「（土）」に引きずられて「土曜日で正しい」と返しがちで、前年の残りという、いちばん拾いたい誤りを見逃します。 年を書かせると、1月の行事を今年の1月として計算してしまいます。AIには「書かれている曜日の文字」を写させるだけにし、正しい曜日は台帳が出します。

指示内容を固定する

あなたは学校の事務室で、保護者へ配るお知らせを配布前に点検する立場です。
添付のPDFだけを読み、書かれていることを項目ごとに書き出してください。
推測で補わないでください。

【書き出す項目】
1. 日付：書かれた文字列をそのまま、月と日を数値で、書かれた曜日の文字を1字で。
   何の日付か（例：運動会の実施日、申込の締切）と、書かれた場所も書く
2. 時刻：書かれた文字列をそのまま、時と分を数値で。何の時刻か（集合、開始、
   解散、受付など）と、書かれた場所も書く
3. 持ち物：品名を1つずつ。書かれた場所も書く
4. 連絡先：電話番号とメールアドレスを書かれたまま。添えられた部署名と担当者名
5. 年度と担当者名：書かれた年度、署名や担当欄の氏名
6. 誤字と言い回し：該当箇所、指摘、直した案
7. 文書内の食い違い：同じことを指しているのに値が違う記載の組

【書かれた場所の書き方】
「本文」「日程表」「持ち物欄」「申込票」「欄外」のどれか。
表や枠の中は、その枠の見出しを使ってください。

【厳守事項】
- 曜日が日付と合っているかを判断しないでください。計算もしないでください。
  書かれた曜日の文字を写すだけにしてください。曜日が書かれていなければ空欄です。
- 年を補わないでください。書かれていない年は空欄にしてください。
- 電話番号やメールアドレスを直さないでください。桁、ハイフン、全角半角も
  書かれたまま写してください。
- 担当者名が正しいかを判断しないでください。書かれた氏名を写すだけにしてください。
- 同じ行事の同じ時刻（例：集合時刻）が2か所にあれば、値が同じでも両方を
  書き出し、「何の時刻か」に同じ名前を付けてください。
- 記載がなければ「不明」とし、推測で埋めないでください。
- 持ち物や時刻が妥当かどうかは書かないでください。
- 「〇〇」「未定」など書きかけの箇所は、誤字の欄に「未記入」として書いてください。
- お知らせ以外の書類と判断した場合は、点検をせず document_type に種類を書いてください。

【今年度】{fiscal_year}
【学校の正式名称】{school_name}

「曜日を判断しない」を明記しないと、正誤を書いてきます。 しかも文書に書かれた曜日をそのまま正しいと返すことが多く、台帳の計算と食い違った結果が並ぶと、人はAIのほうを信じがちです。 判断をさせなければ、比べる相手は計算の1つだけになります。

「値が同じでも両方を書き出す」も同じ理由です。 食い違ったときだけ書かせると、AIが読み違えた組は台帳に上がってきません。

出力形式を固定する

次の形のJSONで受け取ります。 構造化出力でスキーマを指定し、この形以外で返らないようにします。

{
  "notice_id": "",
  "document_type": "notice",
  "dates": [
    { "label": "運動会の実施日", "text": "10月18日（土）",
      "month": 10, "day": 18, "weekday_written": "土", "location": "申込票" }
  ],
  "times": [
    { "label": "集合", "text": "8時30分", "hour": 8, "minute": 30, "location": "日程表" }
  ],
  "items": [
    { "name": "水筒", "location": "本文" }
  ],
  "contacts": [
    { "value": "03-xxxx-1234", "kind": "phone", "dept": "事務室", "person": "" }
  ],
  "fiscal_year_written": "令和7年度",
  "signers": [""],
  "typos": [
    { "where": "", "issue": "", "suggestion": "" }
  ],
  "conflicts": [
    { "label": "集合", "values": ["8時20分（本文）", "8時30分（日程表）"] }
  ]
}

1つ目の理由は、日付を年月日の数値に分けて受け取れることです。 台帳では、月が4以上なら年度の始まりの年、1〜3月ならその翌年として年を決め、数値の年・月・日から日付を組み立てて WEEKDAY 関数に渡します。月が1〜12、日がその月の日数の範囲にあるかも、組み立てる前に台帳で確かめます。構造化出力は数値の最小・最大の制約に対応していないため、範囲の確認はスキーマではなく台帳の側に置きます。

2つ目は、label で同じ項目の記載をまとめられることです。 times の中で同じ label を持つ行の値が2種類以上あれば、台帳が「要確認」を付けます。items は location ごとに品目を並べ、ある場所にだけある品目に印を付けます。conflicts はAIが気づいた食い違いの一覧で、台帳の判定と重なっていれば確度が高く、AIだけが挙げたものは人が原稿で確かめます。

3つ目は、contacts を書かれたままで受け取れることです。 台帳の側で全角を半角に、ハイフンを除いた形にそろえてから連絡先一覧と照合し、一覧に無い番号、有効な期間が切れた番号に印を付けます。fiscal_year_written は今年度と比べ、signers の氏名は連絡先一覧の在籍中の担当者と照合します。

システムへ連携する

原稿は書き換えません。 点検台帳に出すのは指摘と照合の結果までで、直すのは担当教員です。 原稿を自動で直す経路を足すと、AIの読み違いがそのまま保護者に届きます。

連絡先一覧も読むだけです。 一覧に無い番号が見つかっても書き足しません。番号が変わったのか原稿の誤りなのかは、担当者に確かめてから一覧を直します。

人が確認する

人が確かめるのは、台帳で「要確認」の付いた行と、AIの誤字の指摘だけです。 一致した行は件数を見て終わりにします。全行を原稿と照らし直すと、第10章の10.0時間には収まりません。

1. 曜日の「要確認」を先に見る … 計算した曜日のほうが正しいのが原則です。原稿のどちらの日付を直すべきか（日付が違うのか曜日が違うのか）は、年間行事予定と照らして決めます
2. 連絡先と年度の「要確認」を見る … 一覧に無い番号は、担当者に今の番号を確かめます
3. 時刻と持ち物の食い違いを原稿で見る … どちらが正しいかは書き手に聞きます。事務室で決めません
4. 誤字の指摘に目を通す … 直した案をそのまま採るかは、書き手の意図を見て決めます
5. 戻した内容を台帳に記録する … 何を指摘し、書き手がどう直したかを残します

1番目で、計算を疑わないでください。 原稿を見て「土曜で合っている気がする」と感じるのが、第3章の（a）です。 疑うべきは設定シートの年度のほうです。

例外に対処する

上から4行目と5行目が、曜日の確認で起きやすい例外です。 曜日の無い日付は誤りではないので印の色を分け、範囲外の日付は組み立てる前に止めます。

「連絡先が一覧に無い」の多くは、一覧のほうが古いことが原因です。 年度初めの異動の時期に続いたら、一覧の更新を先に済ませます。

記録を残す

• 点検したPDFと、提出者・提出日時・点検日時
• Claude API が返したJSONの全文
• 台帳の判定結果と、そのとき使った今年度の設定と連絡先一覧の版
• 人が指摘を採らなかった記録 … どの行を、なぜ採らなかったか
• 書き手へ戻した内容と、直った版の提出日時
• お知らせの種類ごとの「要確認」の件数

3つ目で「そのときの設定と一覧の版」を残すのは、一覧が年度の途中で変わるためです。 番号が変わった後で過去の点検を見直すと、当時は正しかった番号が誤りに見えます。

最後の行は、下敷きにする前年の文書を直す材料になります。 毎年同じお知らせで同じ印が出るなら、原稿を書く前に、下敷きのほうから古い年度と番号を消しておきます。