ごみ収集の作業員が撮った不適正排出の写真から品目と違反の種類を見分けて集積所別の台帳にし、町内会への啓発文の案を毎月作る

処理の起点を決める

起点は2つです。 写真の受付と、月初の集計です。

1つ目は、Apps Script のインストール可能なトリガーの「フォーム送信時」です。 作業員がフォームを送るたびに1件ずつ動きます。帰庁後にまとめて処理する形にはしません。 作業員が現場にいるうちに処理が終われば、写真が暗くて見分けられなかったときに、次の集積所へ移る前に撮り直しを頼めます。

2つ目は、時間主導型のトリガーです。 時間主導型のトリガーは、最短で1分ごと、最長で月1回の間隔で動かせるとされています。毎月1日の早朝に、前月分の集計と啓発文の案づくりを動かします。

インストール可能なトリガーは、作成した人のアカウントで動くとされています。担当者の個人のアカウントで作ると、異動のときに止まります。清掃事務所の共用の管理用アカウントで作ります。 トリガーが失敗したときは、作成者にメールが届くとされているので、そのメールが事務所の誰かに届くようにしておきます。

入力データを集める

質を決めるのは、分別の区分の一覧です。 市によって区分が違います。スプレー缶を「危険ごみ」とする市もあれば、「燃やさないごみ」に穴を開けずに出すとする市もあります。 AIに一般的な分け方で答えさせると、自分の市の区分とずれます。一覧をそのままAIに渡し、その中からだけ選ばせます。

収集日程の例外を持つのは、祝日の振替で収集の区分が変わる日があるためです。 曜日だけで照らすと、振替の日に正しく出されたごみを「収集日の誤り」と記録してしまいます。

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

集積所の番号は、フォームで入力させ、台帳に無い番号は受け付けないようにします。番号の打ち間違いは、そのまま別の町内会の記録になります。台帳に無ければ、その回答は台帳に載せず、担当者の確認のシートに回します。

写真はドライブから取り出してBase64にし、インラインで渡します。 スマートフォンの写真は1枚で数MBあり、Base64にすると大きさが増えます。フォームの側で枚数を3枚まで、1枚の大きさに上限を設けておき、 合計が20MBに近づくときは1枚ずつ別のリクエストで渡します。

AIへ渡す前に整形する

1. 集積所の番号を確かめる … 台帳に無い番号は、確認のシートに回す
2. その日の収集の区分を決める … 送信の日付の曜日と、収集日程の例外から、その集積所のその日の区分を出す
3. 写真の形式を確かめる … JPEG、PNG、WEBP、HEIC、HEIF のいずれかであること。それ以外は確認のシートへ
4. 写真の大きさを確かめる … 合計がリクエストの上限に近ければ、1枚ずつに分ける
5. 重複を除く … 同じ集積所から同じ日に10分以内に2回送られたものは、続きとしてまとめる
6. 分別の区分の一覧を添える … AIに選ばせる区分と、代表的な品目の一覧を入れる

2番目が、第1章で書いた「写真で分からないことを規則で決める」の材料です。 AIには、その日がどの区分の収集日かを渡しません。渡すと、AIが写真を見ずに「収集日の誤り」と答えるようになります。 区分の照らし合わせは、AIの答えが返ってきた後に Apps Script で行います。

写真の大きさは、費用にも効きます。 画像は、縦横とも384ピクセル以下なら258トークン、それより大きければ768×768ピクセルのタイルに分けて1タイルごとに258トークンと数えるとされています。また、media_resolution のパラメータで、1枚の画像に割り当てる最大のトークン数を決められるとされています。品目を見分けるのに細かい解像度は要らないことが多いので、試す段階で精度と費用の釣り合いを見ます。

AIに処理させる

表のいちばん下の行は、AIの選択肢に入れません。 写真に写っているのは「今日ここにあるごみ」だけで、今日がそのごみの日かどうかは写っていないからです。

2行目がいちばん起きやすい失敗です。 写真に郵便物が写っていると、AIは親切のつもりで「○○様宛の封筒」と根拠に書きます。根拠の欄は台帳にそのまま残るので、指示で禁じ、写り込みは印だけにします。

指示内容を固定する

あなたは市の清掃事務所で、収集できなかったごみの写真を記録する担当者です。
渡された写真だけを見て、品目と違反の種類を記録してください。推測で埋めないでください。

【品目の選び方】
- 品目は、下の「分別の区分の一覧」の区分から選んでください。一覧に無い区分を作らないでください。
- 写っている品目を最大5つまで、目立つものから順に挙げてください。
- 各品目について、写真のどこにどう見えるかを evidence に短く書いてください（例：袋の右下に缶が透けて見える）。
- 袋の中身が見えない場合は、中身を推測せず「中身不明」としてください。

【違反の種類の選び方】
- 次の6つから、写真で確かめられるものだけを選んでください。
  wrong_sorting, non_designated_bag, hazardous_mixed, bulky_item,
  appliance_recycling, business_waste_suspected
- 収集日を間違えたかどうかは、写真から判断しないでください。選択肢にもありません。
- スプレー缶、電池、ライター、刃物が見えた場合は、必ず hazardous_mixed を選んでください。
- business_waste_suspected は「疑い」です。断定する書き方をしないでください。

【厳守事項】
- 宛名、氏名、住所、電話番号、車のナンバーなど、写真に写った文字を書き写さないでください。
  写っていた場合は personal_info_visible を true にするだけにしてください。
- 誰が出したか、どの家から出たかを推測しないでください。
- 不法投棄にあたるかどうかを書かないでください。
- 写真が暗い、ぶれている、ごみが写っていない場合は photo_usable を false にし、
  品目と違反の種類を空にしてください。
- 作業員の選んだシールの区分に合わせて答えを変えないでください。写真から見えたとおりに答えてください。

【分別の区分の一覧】{sorting_categories}
【作業員のメモ】{worker_note}

「シールの区分に合わせて答えを変えない」と書いているのは、照らし合わせの意味を守るためです。 作業員の選んだ区分は、指示の中に入れていません。入れると、AIはそれに寄せて答え、第5章の6番目の照らし合わせが空振りになります。 作業員のメモだけは、写真の角度で見えない事情（「袋の底にびん」など）が書かれることがあるので渡します。

「中身不明」を明記しないと、袋の色から中身を決めます。 燃やすごみの指定袋なら燃やすごみ、と答えるのが自然だからです。見えていないものを見えたことにしないのが、この記録の最低限の約束です。

月初の啓発文の案は、別の指示で作ります。 渡すのは写真ではなく、Apps Script が集計した町内会ごとの数字だけです。

あなたは市の清掃事務所で、町内会に回覧してもらう、ごみの出し方のお知らせを書く担当者です。
渡された「先月の集計」だけを根拠に、回覧用のお知らせの案を400字以内で書いてください。
- 件数の多かった品目と違反の種類を、多い順に2つまで具体的に書いてください。
- それぞれについて、市の正しい出し方を「分別の区分の一覧」から1文で添えてください。
- 数字は集計に書かれた値だけを写し、計算しないでください。
- 特定の集積所の利用者や家を責める書き方、「違反者」という言葉を使わないでください。
- 集計に無い品目や、前の月との比較を書かないでください。
【先月の集計】{monthly_counts}　【分別の区分の一覧】{sorting_categories}

写真を渡さないのは、啓発文に写り込みが入り込む経路を断つためです。 集計の数字だけなら、個人の情報が文書に混ざることはありません。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。

{
  "photo_usable": true,
  "items": [
    { "category": "", "label": "", "evidence": "" }
  ],
  "violations": [
    { "type": "wrong_sorting | non_designated_bag | hazardous_mixed | bulky_item | appliance_recycling | business_waste_suspected",
      "evidence": "" }
  ],
  "sticker_visible": true,
  "personal_info_visible": false,
  "unclear_points": ""
}

JSONで受けるのは、台帳の列にそのまま入れるためです。 Gemini API の構造化出力は JSON Schema の一部に対応していて、enum で分類の値を固定できます。category を分別の区分の一覧で、type を6つの値で固定すれば、 第3章の（b）の書き方のばらつきが起きません。

ただし、形が正しいことと、値が正しいことは別です。 公式の説明でも、出力は構文として正しいJSONになるが、値はアプリケーションの側で必ず確かめるようにとされています。Apps Script の側で、category が一覧にあるか、photo_usable が false なのに品目が入っていないかを確かめます。

AIの答えを受けた後、Apps Script が次の列を足して台帳に書きます。

システムへ連携する

Apps Script には実行の上限があります。 1回の実行は6分まで、トリガーの合計の実行時間は Google Workspace のアカウントで1日6時間まで、外部へのURLの呼び出しは1日10万回までとされています。1件ずつの処理は数十秒で終わるので、ふだんは届きません。届きうるのは、月初の啓発文の案づくりです。 町内会が百を超えると6分に収まらないので、15町内会ずつに区切り、処理した町内会に印を付けて、次のトリガーで続きから動かします。 トリガーの数は1つのスクリプトで1人20個までとされているので、区切りごとにトリガーを足していく作り方はしません。

メールの通知は、件数を絞ります。 メールの受信者数にも1日の上限があります。通知は危険物と写真不可に限り、 それ以外は台帳の「要確認」の列で見ます。

人が確認する

人が見るのは「要確認」の行です。 次の順で見ます。

1. 危険物 … 収集車の火災の原因になる品目です。その日のうちに集積所の掲示と、町内会への連絡を検討します
2. 写真不可 … 作業員に撮り直しか、メモでの補足を頼みます
3. シールとの不一致 … 写真を開き、どちらが正しいかを決めて直します
4. 写り込み … 写真の閲覧の範囲を限り、啓発の資料に使わない印を付けます
5. 事業系の疑い … 事業系のごみの担当に回します。この構成では断定しません

「要確認」でない行は、週に一度、件数と品目の並びを流し見ます。 AIと作業員の見立てが一致した行なので、1行ずつ写真は開きません。全件を開く運用にすると、第10章の18.0時間には収まりません。

直したときは、直す前の値と並べて残します。 どの品目で見誤りが多いかが分かれば、分別の区分の一覧に代表的な品目を足して直せます。

例外に対処する

最後の行は、年に何度か必ず起きます。 年末年始と大型連休の前に、収集日程の例外の一覧を更新する作業を、年間の予定に入れておきます。

記録を残す

• フォームの回答と、写真のファイルのID
• AIに渡した指示と、返ってきたJSONの全文
• 規則で足した列（収集日の誤り、シールとの不一致、確認の要否）
• 担当者が直した値と、直す前の値
• 月ごとの集計と、啓発文の案と、実際に送った文書
• 写り込みの印と、その写真の閲覧の範囲

写真そのものは、保存の期間を決めて消します。 取り残しの記録として要るのは品目と違反の種類で、写真をいつまでも残すと、写り込んだ宛名もいつまでも残ります。 保存の期間は、庁内の文書の取り扱いの決まりに合わせて決めます。