郵便受付で撮った封筒の写真から宛名・差出人・郵便の種類を読み取り、受付台帳に記録して宛先の部署へ知らせる

処理の起点を決める

時間主導型のトリガーを10分おきに置きます。 平日の8時から18時のあいだだけ処理し、それ以外の時刻は何もせずに終わるようにします。郵便が届く時刻に合わせて、届いた直後の30分だけ5分おきにすることもできます。

写真の保存を直接のきっかけにしないのは、ドライブへの保存を起点にするトリガーが無いためです。 フォルダを一定の間隔で見に行き、新しいファイルを処理する形にします。10分の遅れは、受付が仕分けを終えるまでの時間とほぼ同じで、部署への知らせとしては十分です。

1回の実行で処理するのは、20枚までにします。 1枚あたり Gemini API の呼び出しと一覧の照合で数秒かかるため、20枚なら6分の上限に余裕があります。残った写真は、次の実行で処理します。 郵便が届いた直後に50枚入っても、30分ほどで処理が終わります。

処理が終わった写真は、処理済みのフォルダへ移します。 移すのは、台帳への記録と部署への知らせが終わったときだけにします。受付のフォルダに残っている写真の数が、そのまま未処理の数になります。

入力データを集める

AIに渡すのは、封筒の写真だけです。 社員と部署の一覧はAIに渡しません。照合はスクリプトの側で行います。 一覧を渡して「どの部署か選んで」と頼むと、AIは一致しない宛名でも一覧の中からいちばん近いものを選んでしまいます。

旧部署名の対応表が、この構成の質を決めます。 組織変更のたびに、旧部署名と今の部署名の対応を1行ずつ足します。取引先は数年前の部署名で送ってくることがあるため、古い対応も消しません。

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

受付のフォルダの中のファイルを一覧にし、撮影の日時の古い順に処理します。フォルダのファイルの一覧は getFiles() で取れ、ファイルの中身は getBlob() でバイナリとして取り出せます。 取り出したバイナリを Utilities.base64Encode() で base64 の文字列にし、MIME の種類と一緒に Gemini API の要求に入れます。

社員と部署の一覧は、1回の実行の最初に1度だけ読みます。 写真1枚ごとに読み直すと、それだけで実行時間を使います。一覧を読んだ時刻を台帳に残し、異動の当日に一覧の更新が遅れた場合に、どちらの版で照合したかを後で確かめられるようにします。

AIへ渡す前に整形する

1. 形式の確認 … PNG・JPEG・WEBP・HEIC・HEIF のどれかであることを確かめます。それ以外は台帳に「形式外」と記録し、撮り直しを頼みます
2. サイズの確認 … 要求の全体が20MBに収まるかを確かめます。大きすぎる写真は、スマートフォンの撮影の設定を変えて撮り直します
3. 重複の確認 … 同じ写真が2回保存されていないか、ファイルの中身のハッシュ値（Utilities.computeDigest()）で確かめます
4. 撮影の日時の記録 … 写真の保存の日時を、受付の日時として台帳に入れます
5. 一覧の準備 … 社員の氏名・よみ、部署名、旧部署名の対応表を、照合しやすい形（空白・全角半角・「株式会社」の有無をそろえた形）にします

3番目を軽く見ないでください。 スマートフォンのアプリで保存がうまくいかなかったとき、受付が同じ封筒を撮り直すと、同じ郵便が台帳に2行入り、部署に2回知らせが届きます。 ハッシュ値が同じなら、2枚目は処理しません。

5番目の正規化は、AIの出力にも同じものをかけます。 一覧の側と読み取った側を同じ形にそろえてから比べないと、「第一営業部」と「第1営業部」が一致しません。

AIに処理させる

させるのは、封筒の表面に書かれている文字を、欄ごとに分けて読み取ることだけです。

宛先の欄で「書かれていない」と「読めない」を分けるのが、この構成でいちばん大事な区別です。 部署名が書かれていない郵便は「会社あて」として総務が受けるもの、部署名が読めない郵便は撮り直すか受付が目で見るものです。混ぜると、部署名の書かれた郵便が総務の保留の箱に入ります。

2行目がいちばん起きやすい失敗です。 手書きの宛名で1文字が読めないとき、AIは前後から推測して社員の氏名らしい文字列を作ります。その文字列が別の社員の名前と一致すれば、郵便は違う人に届きます。 読めない文字は読めないとして返させ、受付が封筒を見て決めます。

指示内容を固定する

あなたは会社の総務の郵便受付で、届いた封筒の表面の写真を読み取る係です。
封筒に書かれている文字を、欄ごとに分けてそのまま書き出してください。
宛先の部署を決めたり、中身を推測したりする必要はありません。

【書き出す欄】
- recipient_company … 宛先の会社名・団体名
- recipient_department … 宛先の部署・課・係の名前
- recipient_person … 宛先の個人名。「ご担当者様」「御中」などもそのまま
- sender … 差出人の会社名・団体名・個人名（表面に見える場合のみ）
- markings … 親展、書留、簡易書留、速達、特定記録、
  「〜在中」などの朱書きや印字・スタンプの有無

【厳守事項】
- 写真に見える文字だけを、表記を変えずに書き出してください。
  略称を正式名に直す、漢字を補う、表記をそろえる、をしないでください。
- 書かれていない欄は空にし、not_written に欄名を入れてください。
- 文字はあるが読めない欄は空にし、unreadable に欄名を入れてください。
  一部の文字だけ読めない場合も、推測で補わずに unreadable にしてください。
- 部署がどこか、誰あてかを推測しないでください。
- 封筒の中身や、急ぎかどうかを書かないでください。
- 複数の封筒が写っている場合は、multiple_envelopes を true にし、
  ほかの欄は空にしてください。
- 封筒でない物（荷物の伝票、はがきの裏面など）が写っている場合は、
  item_type に何が写っているかを書いてください。
- 宛名のラベルと、封筒に印刷された差出人の住所を取り違えないでください。
  差出人の情報は、封筒の印刷・スタンプ・裏面の記載から判断してください。

「一部の文字だけ読めない場合も推測で補わない」を明記しないと、AIは補います。 「営業〇部」の〇がかすれていれば、文脈から「第一」と書き足します。その会社に第一営業部と第二営業部があれば、半分の確率で違う部署に届きます。

最後の項目は、窓付きの封筒への対策です。 窓付きの封筒は、窓から見える宛名と、封筒に印刷された差出人の住所が同じ面に並びます。取り違えると、差出人の会社あての郵便として処理されます。

出力形式を固定する

次の形のJSONで受け取ります。 Gemini API の構造化出力を使い、response_format に mime_type を application/json、schema に下の形のスキーマを入れて渡します。画像は、同じ要求の input に type を image とし、base64 の data と mime_type を付けて入れます。指示の文を画像より前に置きます。

{
  "item_type": "envelope",
  "multiple_envelopes": false,
  "recipient_company": "",
  "recipient_department": "",
  "recipient_person": "",
  "sender": "",
  "markings": {
    "confidential": false,
    "registered": false,
    "simple_registered": false,
    "express": false,
    "recorded": false,
    "enclosed_note": ""
  },
  "not_written": [],
  "unreadable": []
}

1つ目の理由は、照合をスクリプトで行えることです。 部署名と氏名が別の欄で返るので、部署名は一覧と旧部署名の対応表に、氏名は社員の一覧に、それぞれ照らせます。両方が一致し、かつ同じ部署を指していれば「一致」です。

2つ目は、markings で扱いを規則で分けられることです。 スクリプトは次の表で台帳の区分と知らせの文面を決めます。

3つ目は、not_written と unreadable で受付の作業が分かれることです。 部署名が not_written なら「会社あて」として総務で受け、unreadable なら受付が封筒を見ます。台帳の「要確認」の理由の欄に、どちらかを書き分けます。

構造化出力は JSON の形を守りますが、値が正しいかはアプリケーションで確かめるよう公式の説明にあります。 読み取った部署名や氏名が一覧と一致しないことは、それ自体が「確かめる」仕組みになっています。

システムへ連携する

UrlFetchApp.fetch() は、method に post、contentType に JSON、headers に API キー、payload に要求の本文を入れて呼びます。muteHttpExceptions を true にすると、失敗の応答でも例外を投げずに応答を返します。 状態コードを見て、写真を受付のフォルダに残したまま次の実行に回すかを決めます。

Chat の Webhook は、部署のスペースごとに1つ作ります。 Webhook の投稿はスペースあたり毎秒1回までで、同じスペースの Webhook で共有されます。郵便が届いた直後は同じ部署あての知らせが続くことがあるため、1回の実行の中で部署ごとにまとめ、「3通届いています」の1件にします。

API キーと Webhook の URL は、コードに書かずスクリプト プロパティか連絡先のシートに置きます。 スクリプト プロパティはスクリプトのすべての利用者で共有されます。連絡先のシートとスクリプトの編集権限は、総務の担当者に限ります。 Webhook の URL を知っていれば誰でもそのスペースに投稿できるためです。

人が確認する

受付の担当者が確かめるのは、台帳の「要確認」の行だけです。 「一致」の行は、仕分けのときに封筒と台帳の行番号が合っているかを見るだけにします。

1. 書留の行を先に見る … 配達員から受け取ったときの記録と、台帳の行数が合っているかを確かめます。書留の知らせは、受付が確かめてから送ります
2. 宛先が一致しない行を見る … 写真と封筒を見て、行き先の部署を台帳に入れます。入れると、スクリプトが次の実行で知らせを送ります
3. 退職者あて・誤配の疑いを見る … 退職者あては総務の規則に沿って扱い、誤配は差し戻しの箱に入れます
4. 封筒に行番号の付箋を貼り、棚に仕分ける … 部署の担当者が棚から取るときに、台帳と照らせます
5. 書留の受け取りを記録する … 部署の担当者が取りに来たら、台帳のシートの受け取りの欄に氏名と日時を入れます

2番目で受付が決めた行き先は、旧部署名の対応表を育てる材料になります。 同じ旧部署名が月に何度も「要確認」になるなら、対応表に1行足します。対応表が育つほど、「要確認」の行は減っていきます。

目標は、1,800通をならして1通1分です。 1分には、撮影・仕分け・付箋を貼る時間と、「要確認」の行を確かめる時間が入っています。「要確認」が全体の2割を超える日は、組織変更があったか、撮影の写真がぼけているかのどちらかです。

例外に対処する

上から3行目までは、撮り方の問題です。 受付の机に、明るさのそろった撮影の位置を決めておくのがいちばん効きます。

記録を残す

• 封筒の写真（処理済みのフォルダ）と、受付の日時
• Gemini API が返したJSONの全文
• 照合の結果（一致した社員・部署、旧部署名の読み替えの有無）と、そのとき使った一覧を読んだ時刻
• 受付が「要確認」の行で決めた行き先と、決めた人
• 部署への知らせを送った日時と、再送の日時
• 書留の受け取りの記録 … 受け取った人の氏名と日時

最後の行は、紙の台帳でサインをもらっていた部分です。 シートに移しても、受け取った人が自分で入力するか、受付が本人の前で入力する運用にします。誰がいつ受け取ったかを後で確かめられることが、書留の台帳の役目です。

写真の保存の期間を先に決めます。 封筒の表面には、社員の氏名と取引先の名前・住所が写っています。台帳の記録は残し、写真は一定の期間が過ぎたら削除する運用が考えられます。期間は社内の文書の保存の規程に合わせます。