申請書の様式を改定したときに、記入例と記入の手引きが様式の欄とずれていないかを、画像と文で照らして校正する

処理の起点を決める

1時間ごとの定時の処理を起点にします。 ファイルを置いた瞬間には動かしません。1つ目を置いた直後に動くと、記入例が無いと誤って返してしまうためです。

「そろった」の目印は、ファイル名で決めます。 01_様式.pdf、02_記入例.pdf、03_手引き.pdf の3つがあり、最後のファイルを置いてから10分以上たった案件を拾います。改定前の様式は 00_旧様式.pdf として任意で置きます。

処理が終わった案件は、フォルダ名の先頭に [済] を付けます。 直した版を置き直したら、担当課に外してもらいます。

1回の実行で拾う案件は、3件までにします。 Apps Script の実行時間は1回6分までで、1件のアップロードとAIの応答で1〜2分かかることがあるためです。

入力データを集める

質を決めるのは、表記の基準の一覧です。 基準が無いと、AIは一般的な書き方を正しいとして指摘してきます。「生年月日は和暦で、元号を丸で囲む選択式」が庁内の基準なら、その一覧が無いと西暦への統一を勧めてきます。 基準は、文書法制係がこれまで指摘してきたことを20〜30行に書き出したもので足ります。

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

ファイルは、Apps Script で共有ドライブから読みます。 案件フォルダの中のファイルを名前で探し、PDFであることとページ数を確かめてから、Gemini API の Files API へ上げます。 上げたファイルは、返ってきた参照をリクエストに入れて使います。

Files API を使うのは、PDFを何度も参照するためです。 担当者が「この欄だけもう一度見て」と聞き直すことがあり、同じPDFを送り直すより参照で済ませたほうが速く済みます。 公式のページも、やり取りを重ねる場合には Files API を勧めています。

Files API に上げたファイルは48時間で消え、ダウンロードし直すこともできません。 1ファイル2GB、1つのプロジェクトで20GBまでです。原本はいつも共有ドライブの側に置き、 48時間を過ぎた案件の聞き直しは上げ直します。

Apps Script の URL Fetch は、1回の送受信が50MBまでです。 1日の呼び出しは一般のアカウントで20,000回、Google Workspace で100,000回で、月40件では届きません。

AIへ渡す前に整形する

1. ファイル名の確認 … 01_様式.pdf、02_記入例.pdf、03_手引き.pdf がそろっているかを見ます。足りなければ照合せず、担当課へ不足を知らせます
2. 形式の確認 … PDFであることを確かめます。ワープロ・スプレッドシートの原本が置かれていたら、PDFにして置き直すよう返します
3. ページ数とサイズの確認 … 1ファイル50MB、1,000ページが上限です。記入例が50MBを超える場合は、解像度を下げて書き出し直してもらいます
4. 記入例の解像度の確認 … 吹き出しの小さな字が読めることが要ります。ページの画像は最大3072×3072ピクセルに縮小されるため、A4の記入例は、余白を詰めて1ページに1枚で書き出します
5. 旧様式の有無の確認 … あれば改定点の要約も出させ、無ければ省きます
6. 表記の基準の読み込み … 基準の一覧のシートを毎回読み、プロンプトに差し込みます

3番目と4番目を軽く見ないでください。 圧縮しすぎると吹き出しの字が潰れ、「記入例に説明が無い」という誤った指摘が出ます。 試行の段階で書き出し方を変えて照合し、指摘が安定する設定を決めます。

AIに処理させる

させるのは、様式の欄を基準にして、記入例と手引きがそれぞれの欄をどう扱っているかを表にし、ずれを指摘することです。

指摘の種類は、次の8つに決めておきます。

種類を決めておくと、担当者が見る深さを種類ごとに変えられます。 guide_wrong_number はほぼ機械的に正誤が決まり、sample_violates_note は注意書きの読み方で分かれます。

1行目がいちばん起きやすい失敗です。 どちらが新しいかを知らないと、AIは「記入例に合わせて様式の欄名を直す」ことも提案します。

指示内容を固定する

あなたは市役所の文書担当として、窓口で配る申請書の様式と、
その記入例・記入の手引きが互いに合っているかを確かめる立場です。

【基準にするもの】
ファイル「01_様式.pdf」が、担当課が決裁を取った改定後の確定版です。
比べる基準は常に様式です。様式を直す提案はしないでください。
記入例（02_記入例.pdf）と手引き（03_手引き.pdf）が、
様式に合っているかだけを見てください。

【手順】
1. 様式の欄を上から順に一覧にしてください。
   欄の番号（①、1、(1) など様式に書かれているとおり）、欄の名前、
   記入の形式（自由記入／選択／チェック）、欄に付いた注意書きを書いてください。
   番号が書かれていない欄は、上から順の仮番号を付け、numbered を false にしてください。
2. 欄ごとに、記入例にその欄の見本の値があるかを見てください。
   値の位置を、記入例のページ番号と box_2d（[ymin, xmin, ymax, xmax]、0〜1000）で示してください。
3. 欄ごとに、手引きにその欄の説明があるかを見てください。
   手引きが番号で欄を指している場合、その番号が改定後の様式の同じ欄を指しているかを確かめてください。
4. ずれを、決められた種類（kind）のどれかで指摘してください。
5. 旧様式（00_旧様式.pdf）がある場合だけ、増えた欄・消えた欄・名前が変わった欄を書いてください。

【厳守事項】
- 記入例の字が読めない場合は、推測せず status を unreadable にしてください。
- 手引きの番号が合っているか確信が持てない場合は、needs_review を true にしてください。
- 表記の点検は、下の「表記の基準」に書かれていることだけにしてください。
  基準に無い書き方の好みは指摘しないでください。
- 項目が法令上必要かどうか、欄を増やすべきか減らすべきかは書かないでください。
- 記入例や手引きの直した文を書かないでください。何がずれているかだけを書いてください。
- evidence には、判断の根拠にした文字列を、PDFに書かれているとおりに写してください。

【表記の基準】{style_rules}
【様式の名前と担当課】{form_name} / {section}

「様式を直す提案はしない」を手順より前に書くのは、後ろに置くと、食い違いを見つけた時点で両方を直す方向に書き始めるためです。 基準がどちらかを先に固定します。

「直した文を書かない」を入れるのは、 直した文があると担当課へ転送したくなり、住民が読む文の書き手がAIになるためです。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。 Gemini API の構造化出力は、/v1beta/interactions へのリクエストの response_format に、mime_type を application/json とし、JSON スキーマを入れて指定します。

{
  "form_name": "",
  "fields": [
    { "no": "⑤", "numbered": true, "label": "連絡先電話番号",
      "input_type": "free | choice | check", "note": "",
      "sample": { "status": "ok | missing | unreadable", "page": 1,
                  "box_2d": [0, 0, 0, 0], "value": "" },
      "guide": { "status": "ok | missing | wrong_number", "ref_text": "", "page": 2 } }
  ],
  "findings": [
    { "kind": "guide_wrong_number", "field_no": "⑥", "file": "03_手引き.pdf",
      "page": 2, "evidence": "", "needs_review": false }
  ],
  "revision_summary": { "added": [], "removed": [], "renamed": [] }
}

kind は第7章の8種類のどれかを enum で縛り、status も enum で縛ります。公式のページでは、構造化出力のスキーマに enum、required、配列の minItems・maxItems などが使えるとされています。

1つ目の理由は、全欄の対応表（fields）と、ずれだけの指摘（findings）を別に持てることです。 迷ったら fields で前後の欄を確かめます。

2つ目は、スクリプトで点検できることです。 公式のページは、スキーマに沿ったJSONが返っても中身が正しいとは限らないので、アプリケーションの側で確かめるよう案内しています。この構成では、次の3つをスクリプトで見ます。

3つ目は、box_2d で記入例に枠を描けることです。 画像理解の公式のページでは、物の位置を [ymin, xmin, ymax, xmax] で、画像の大きさに対して0〜1000に正規化した値で返すとされています。スクリプトでもとの寸法に戻し、記入例のページの画像に赤い枠を描いて一覧に添えます。 担当者は、指摘の文を読む前に、どの欄の話かを画像で見られます。

システムへ連携する

ホームページのCMSへは何もつながず、照合の結果で公開を止めたり進めたりもしません。 担当課への返送は、採った指摘だけを並べた下書きまでにし、担当者が読んで送ります。

人が確認する

人が見るのは findings の全件です。 fields の対応表は、迷ったときにだけ開きます。指摘の件数は1件あたり平均5〜10件という想定で、 1件ずつ採る・採らない・書き直すを決めます。

1. needs_review の付いた指摘を先に見る … AIが確信を持てなかったもの。記入例の画像を開いて、枠の中を目で確かめます
2. sample_violates_note を見る … 注意書きの読み方で正誤が分かれる種類です。担当課の意図を想像せず、注意書きの文だけで判断します
3. 残りの指摘を見る … guide_wrong_number と sample_extra_field は、根拠の文字列を見ればほぼ決まります
4. 採否を記録する … 採らなかった指摘には理由を一言残します

同じ理由で採らない指摘が続いたら、表記の基準の一覧に「この書き方は可」と1行足します。

目標は、指摘を見て採否を決め、下書きを整えて送るまでを1件30分にすることです。

例外に対処する

上から4行目までが、ほとんどを占めます。 どれもAIの問題ではなく、担当課のファイルの作り方と置き方の問題です。

記録を残す

• 案件ごとの、照合に使ったPDFのファイル名と更新日時（原本は共有ドライブに残る）
• Gemini API に送ったプロンプトと、返ってきたJSONの全文
• スクリプトの点検の結果（連番・件数・根拠）
• 担当者の採否と、採らなかった理由
• 担当課へ返した日時と、直した版が置き直された日時
• 担当課ごと・指摘の種類ごとの件数

採らなかった理由は、外れ方で直す場所を決めるために残します。 「基準に無い好み」なら表記の基準を、「読み違い」なら記入例の書き出し方を見直します。

最後の行は、担当課への説明の材料になります。 ある課で guide_wrong_number が毎回出るなら、手引きを欄の名前で参照する書き方に変えてもらいます。