公民館・集会所の利用日誌を月ごとに集計し、利用の偏りと設備の不具合・利用者の要望を施設ごとの月報にまとめる

処理の起点を決める

月次の処理は、毎月1日の朝に動く時間主導型のトリガーを起点にします。 ScriptApp.newTrigger() に timeBased()・onMonthDay(1)・atHour(6) を続けて作ります。公式のページでは、atHour() で指定した時刻はその1時間のあいだのどこかで動き、nearMinute() を使っても前後15分の幅があるとされています。朝6時台に動けば、担当者が出勤するまでに終わります。

月末の夜の利用は、翌朝に入力されることがあります。 そこで、月報の下書きを作ったあとに前月分の行が追加されたら、その施設に「追加の入力あり」の印を付け、担当者が再実行のメニューから作り直します。

安全に関わる記述の知らせは、フォーム送信のトリガーで行います。 回答1件ごとに動き、不具合の欄に語の一覧の語があれば、その場でメールを送ります。 この処理は AI を呼びません。語の一覧との突き合わせだけなので、速く、確実です。

1回の実行は6分までです。 公式の割り当てでは、スクリプトの1回の実行時間は6分で、トリガーの1日の合計の実行時間は一般のアカウントで90分、Google Workspace のアカウントで6時間です。24施設を1回でまとめて処理すると、API の待ち時間で6分を超えることがあります。月次の処理は施設を数件ずつに分け、どこまで終わったかをスクリプトのプロパティに書き、続きは10分後の1回限りのトリガーで動かします。

入力データを集める

質を決めるのは、部屋の名前の一覧と修繕の一覧です。 部屋の名前がそろわなければ、稼働率が「和室1」と「和室①」に割れます。修繕の一覧が無ければ、AI は先月からの続きかどうかを判断する材料を持ちません。

時間帯ごとの貸し出しの枠の数も一覧に持たせます。 稼働率は「使われた枠の数 ÷ 貸し出せる枠の数」で、分母は施設と部屋ごとに違います。休館日と、点検で貸し出さなかった日も枠から外すので、休館日の一覧も同じシートに置きます。

団体の区分は、利用の偏りの所見に使います。 「夜間の利用の7割がサークル」という所見は、団体の区分が無ければ出せません。

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

月次のトリガーで動く関数は、回答のシートを先月の範囲で読みます。 シート全体を毎回読むと、行が増えるほど遅くなります。利用日の列で先月の範囲に絞り、施設の列で分けてから処理します。

API キーはスクリプトに直接書きません。 スクリプトのプロパティに置き、実行時に読みます。

施設ごとの処理は、次の順で行います。

1. その施設の先月分の行を取り出す（0行なら「利用なし」の月報を作って終わる）
2. 部屋の名前を正式な名前にそろえる（一覧に無い名前は「未登録の部屋」として数える）
3. 部屋×時間帯ごとの使われた枠の数と稼働率、団体ごとの回数、区分ごとの割合を数える
4. 自由記述が空でない行だけを取り出し、行の番号を付ける
5. 修繕の一覧から、その施設の対応済みでない不具合を取り出す
6. Claude API を呼び、JSON を受け取る（失敗したら施設に「要再実行」と書いて次へ）
7. 所見に出てくる数字が、3番目の集計値にあるかを確かめる
8. 月報の雛形を複製して下書きを作り、修繕の一覧に新しい不具合と続きの印を書く
9. 処理済みの施設をスクリプトのプロパティに書く

7番目が、この構成の安全装置です。 AI が書いた所見の「夜間の和室の稼働率は82％」という数字が、3番目で数えた値に無ければ、その文に「数字を確認」の印を付けて下書きに残します。 AI に計算させないと指示しても、言い換えのついでに数字を丸めたり作ったりすることがあるためです。

Claude API は UrlFetchApp で呼びます。 公式の割り当てでは、URL Fetch の呼び出しは一般のアカウントで1日2万回、Google Workspace のアカウントで1日10万回で、月24回の呼び出しには十分です。

AIへ渡す前に整形する

1. 部屋の名前をそろえる … 別名の一覧で正式な名前に直します。AI に直させません
2. 時間帯に分ける … 開始の時刻で午前・午後・夜間に分けます。枠をまたぐ利用は、またいだ枠すべてに数えます
3. 自由記述の空と「特になし」を除く … 「特になし」「異常なし」「なし」だけの欄は渡しません
4. 個人の名前と連絡先を落とす … 管理人のメモに書かれた利用者の個人の名前と電話番号を、記号に置き換えてから渡します。団体名は残します
5. 行の番号を付ける … 自由記述の1件ごとに L0123 のような番号を付け、AI にはこの番号で根拠を返させます
6. 先月の不具合にキーを付ける … 修繕の一覧の各行に R-07-012 のようなキーがあることを確かめます
7. 長さを確かめる … 施設の自由記述の合計が極端に多いとき（たとえば300件を超えるとき）は、部屋ごとに分けて2回に分けて渡します

4番目は、日誌の性質のために要ります。 管理人のメモには「△△さん（090-…）から苦情」のように、個人の名前と電話番号が書かれることがあります。 正規表現で電話番号を、団体の一覧に無い「〜さん」を記号に置き換えます。

AIに処理させる

させるのは3つです。不具合をまとめること、要望をまとめること、集計値をもとに利用の偏りの所見を書くことです。

不具合の続きの判断は、AI に任せる部分のうち最も間違えやすいところです。 先月の「和室2のエアコンが効かない」と、今月の「和室2 冷房が弱い」は同じものですが、「和室2のエアコンから水が垂れる」は別の症状かもしれません。 そこで、AI には同じと言える根拠の文を書かせ、迷ったら新しいものとして扱わせます。 新しいものとして重複して載るのは担当者が見れば分かりますが、別の症状を同じものとしてまとめると、2つ目の症状が月報から消えます。

安全に関わる記述には、safety の印を付けさせます。 月報の上でも目立つようにするためで、範囲は語の一覧と同じにします。

指示内容を固定する

あなたは市の公民館・集会所を所管する課で、施設ごとの月報の下書きを作る立場です。
渡された利用日誌の自由記述と集計値だけを使ってください。

【作るもの】
1. repairs：設備の不具合の一覧
   - 同じ部屋・同じ設備・同じ症状の記述は1件にまとめる
   - 先月までの不具合の一覧に同じものがあれば、そのキーを previous_key に入れる
   - 同じと言える根拠を match_reason に書く。迷ったら previous_key は空にする
   - 漏電・焦げ臭い・ガス・水漏れ・けが・転倒に関わる記述は safety を true にする
2. requests：利用者からの要望・苦情の一覧
   - category は booking／equipment／noise／cleaning／rules／other から選ぶ
   - 同じ趣旨の記述は1件にまとめ、件数を mentions に入れる
3. usage_notes：利用の偏りの所見を3つまで
   - 渡された集計値の中から、偏りが目立つところを選ぶ
   - 文に入れる数字は、集計値に書かれている値をそのまま写す
   - 使った集計値のキーを stat_keys に入れる
4. unclear：不具合か要望か判断できない記述

【厳守事項】
- 数字を計算しないでください。合計・割合・前月との差を自分で出さないでください。
- 集計値に無い数字を所見に書かないでください。
- 日誌に「修理済み」「直った」とあっても、不具合を解決済みとして扱わないでください。
  status_in_log に reported_fixed と書くだけにしてください。
- 修繕の優先順位、急ぐかどうかは書かないでください。
- 根拠の行の番号を必ず entry_ids に入れてください。番号の無いまとめは作らないでください。
- 個人の名前を書かないでください。記号に置き換えられた部分はそのままにしてください。
- 書かれていない事情（原因、経過、利用者の気持ち）を足さないでください。

【施設】{facility_name}
【部屋の一覧】{rooms}
【集計値】{stats_json}
【先月までの不具合の一覧】{open_repairs}
【自由記述（行の番号つき）】{entries}

「数字を計算しないでください」と「集計値に無い数字を書かないでください」を分けて書くのは、別の失敗だからです。 前者は割合を自分で出す失敗、後者は「約8割」のように丸めて書く失敗です。どちらも、スクリプトの突き合わせで印が付きますが、指示の側でも減らしておきます。

「修理済みと書かれていても解決済みにしない」も要ります。 管理人が「業者が来て直した」と書いても、別の部屋の話だったり、応急の処置だったりします。修繕の一覧の状況を変えるのは担当者だけにします。

出力形式を固定する

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

{
  "facility_id": "",
  "repairs": [
    { "room": "", "equipment": "", "symptom": "",
      "status_in_log": "new | continuing | reported_fixed",
      "previous_key": "", "match_reason": "",
      "safety": false, "entry_ids": [""], "mentions": 0 }
  ],
  "requests": [
    { "category": "booking | equipment | noise | cleaning | rules | other",
      "summary": "", "entry_ids": [""], "mentions": 0 }
  ],
  "usage_notes": [
    { "note": "", "stat_keys": [""] }
  ],
  "unclear": [
    { "entry_id": "", "reason": "" }
  ]
}

スキーマでは status_in_log と category を enum で縛り、すべてのオブジェクトに additionalProperties: false を付けます。公式のページでは、minimum や maximum などの数値の制約は使えず、使うと 400 が返るとされています。mentions を0以上に縛りたくなりますが、スクリプトの側で確かめます。

entry_ids を必ず返させる理由は、担当者の確認の速さです。 月報の下書きでは、不具合の1件ごとに根拠の行の番号が並び、番号をたどれば日誌の元の記述にすぐ行けます。 根拠の無いまとめは、確かめようがありません。

不具合の並べ方は、続いている月数の長いものを上にします。 修繕の一覧の「初めて書かれた月」から月数を出し、3か月以上続いているものには、その月数を太字で添えます。 第3章の（c）を月報の形で解く部分です。

システムへ連携する

修繕の一覧には追記だけをします。 新しい不具合の行を足し、続いている不具合の行に「今月も記述あり」と行の番号を書きます。状況の列（未対応・依頼済み・対応済み）は、担当者だけが変えます。

メールの量は少なく収まります。 公式の割り当てでは、MailApp の1日の宛先の数は一般のアカウントで100、Google Workspace のアカウントで1,500です。月報の知らせは月に1回、安全の語の知らせも月に数回です。

人が確認する

担当者は、施設ごとの下書きを次の順で見ます。

1. safety の不具合 … 根拠の行を開き、記述を読みます。すでに知らせが届いているはずなので、営繕の担当が動いているかを確かめます
2. continuing の不具合 … match_reason を読み、本当に同じ不具合かを根拠の行で確かめます。 別の症状なら分けます
3. 「数字を確認」の印の付いた所見 … 集計表と見比べ、直すか消します
4. unclear の記述 … 不具合か要望かを決め、必要なら施設の管理人に聞きます
5. 要望 … まとめ方が趣旨とずれていないかを見ます

2番目に時間をかけてください。 続いている不具合は、月報で最も目を引く部分です。続いていないものを続いているとすると、営繕の担当が直したはずの不具合を探しに行くことになります。

例外に対処する

最も多いのは1行目と3行目です。 どちらも AI の問題ではなく、入力の仕方の問題です。

記録を残す

• 月次の実行ごとの、施設ごとの集計値の JSON
• AI に渡した自由記述（置き換えたあと）と、返ってきた JSON
• 「数字を確認」「根拠不明」の印の数
• 担当者が直した箇所 … 続きの判断を分けた・まとめた、所見を消した、など
• 修繕の一覧の状況の変更の履歴（誰が、いつ、どう変えたか）
• 安全の語の知らせを送った日時と宛先

4つ目が、指示を直す材料になります。 続きの判断を担当者が何件分けたかを月ごとに数え、多ければ、指示の「迷ったら空にする」を強めます。