ビルメンテナンス会社の点検員が Google フォームで出す設備点検の結果と写真を集め、記入漏れと基準外の値を拾って、オーナー向けの月次の点検報告書の下書きを作る

処理の起点を決める

トリガーは2つです。 1つ目はフォームの送信で、点検員が送信するたびに1件ずつ動きます。2つ目は毎月1日の朝の時間主導型で、前の月の記録から建物ごとの報告書を作ります。

1つ目は、記入漏れを返すためのものです。 送信から数十秒で点検員のスマートフォンにメールが届けば、まだ建物の中にいるうちに測り直せます。 1日の終わりにまとめて確かめる形にすると、点検員はもう次の建物に移っています。

2つ目は、毎月1日の朝6時ごろに設定します。 公式のページでは、時間主導型のトリガーの時刻は少しばらつくことがあり、9時に設定すると9時から10時の間に動く例が示されています。担当者が出社する前に終わっていればよいので、ばらつきは問題になりません。

45棟を1回の実行で処理しません。 Apps Script の1回の実行は6分までで、1棟あたり Claude API の呼び出しと文書の作成に数十秒かかると、45棟では足りないことがあります。未処理の建物を記録しておき、5分を過ぎたら次の実行に回す作りにします。トリガーで動く時間の合計は、Google Workspace のアカウントで1日6時間までです。

入力データを集める

質を決めるのは、基準のシートの「比べ方」の列です。 建築物における衛生的環境の確保に関する法律の施行規則では、浮遊粉じんの量、一酸化炭素の含有率、二酸化炭素の含有率は、1日の使用時間中の平均値を基準の数値と比べることとされています。一方、温度や相対湿度は測った値で見ます。1回の測定値が1,000ppm を超えたからといって、それだけで「基準外」とは言えません。 比べ方をシートに持たせ、平均で比べる項目は、1日の測定がそろってから判定します。

空調の方式も、比べる項目を変えます。 施行令では、空気調和設備を設けている場合と機械換気設備を設けている場合で、基準を当てはめる項目が分かれています。機械換気設備の建物では、温度と相対湿度の基準は当てはめません。 建物の台帳の空調の方式から、比べる項目を選びます。

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

フォームの側のトリガーのイベントから response を受け取り、そこから回答のIDを取ります。回答のIDとフォームのIDで Forms API の回答の取得を呼び、ファイルのアップロードの回答からファイルIDを取ります。

写真は、ファイルIDだけを点検記録のシートに書きます。 写真そのものをシートに貼ると重くなり、月初めの処理が6分に収まりません。報告書を作るときに、ファイルIDから画像を読み出して文書に足します。 1項目に貼る写真は2枚までと決めておきます。

AIへ渡す前に整形する

1. 建物コードを台帳と照らす … フォームの選択肢から選ぶので外れることは少ないですが、台帳に無いコードは処理を止めて業務管理課に知らせます
2. 必須の欄の空きを数える … 点検項目の結果と、その建物で測るべき測定値（空調の方式で決まる）が全部入っているかを見ます
3. 「異常あり」に写真があるかを見る … 結果が「異常あり」なのに写真が無い項目に印を付けます
4. 測定値の単位と桁を確かめる … 二酸化炭素を ppm ではなく％で入れた、温度に小数点を打ち忘れた、といった誤りを、あり得ない範囲（例：二酸化炭素が10未満）で拾います
5. 基準と比べる … 測った値で見る項目はその場で、1日の平均で比べる項目は、その日の測定がそろってから平均を出して比べます
6. 前月からの続きを付ける … 前月に基準外だった項目に、今月の値を並べます

4番目は、AIに頼まずルールで拾います。 あり得ない範囲を外れた値は、記入漏れと同じく点検員にその場で返します。「1.2」が1,200ppm の打ち間違いかどうかを、AIに推測させないでください。 点検員本人に聞けば一言で分かります。

5番目の平均は、Apps Script の中で計算します。 AIに平均を計算させると、測定の回数を数え違えることがあります。数を扱う処理は、全部ルールの側に置きます。

6番目の前月からの続きは、建物コードと項目名で前月の印を引きます。 前月に基準外だった項目が今月は基準内に戻っていれば「改善」、続いていれば「継続」の印を付けて渡します。オーナーがいちばん気にするのは、前月に指摘されたことがどうなったかです。

AIに処理させる

させるのは、ルールで印を付けた点検記録をもとに、報告書の本文の4つの部分を書くことです。

AIに渡すのは、ルールの結果を含めた記録で、判定の材料ではありません。 「この値が基準外か」はルールが決めて out_of_range: true として渡し、AIはそれを文章にするだけです。

最後の行が、いちばん起きやすい失敗です。 「フィルターの汚れ（注意）」とだけある記録から、「清掃を実施しました」と書いてしまいます。 点検員が清掃をしていなければ、報告書が事実と違うことになります。

指示内容を固定する

あなたはビルメンテナンス会社の業務管理課で、オーナー向けの月次の点検報告書の
本文の下書きを書く立場です。渡す点検記録だけをもとに書いてください。

【書く部分】
1. summary ........ その月の点検の全体の状況（3〜4文）
2. out_of_range ... 基準外の値ごとに、項目・場所・値・その場の対応・今後の対応
3. findings ....... 結果が「注意」「異常あり」の項目ごとに、状態と推奨する対応
4. carry_over ..... 前月に指摘した項目の今月の状態

【厳守事項】
- 基準に合っているかどうかは、記録の out_of_range の値に従ってください。
  自分で基準と比べて判定し直さないでください。
- 数値は記録のとおりに写してください。平均を計算し直したり、
  単位を換算したりしないでください。
- 記録に書かれていない対応（清掃した、交換した、調整した）を書かないでください。
  その場の対応が記録に無ければ「記録なし」としてください。
- 不具合の原因は断定しないでください。点検員の特記事項にある内容だけを
  「点検員の所見では」として書いてください。
- 推奨する対応は「〜をお勧めします」「〜の確認が必要です」の形にし、
  修繕の費用や業者の手配には触れないでください。
- 写真に触れるときは、記録の photo_files のファイル名だけを使ってください。
- オーナーに向けた丁寧語で書き、社内の略語は使わないでください。

【建物の情報】{building}
【この月の点検記録（ルールの結果を含む）】{records}
【前月に指摘した項目】{prev_findings}

「自分で基準と比べて判定し直さない」を明記しないと、AIは数値を見て独自に判定します。 二酸化炭素の1回の測定値が1,050ppm と書かれていれば、平均では基準内でも「基準超過」と書きます。判定はルールが決めたものに従わせ、文章を書く役に徹させます。

「記録なし」と書かせるのは、空欄をAIが埋めないようにするためです。 空いていると、それらしい対応を書き足します。「記録なし」が報告書に残れば、担当者が点検員に確かめるきっかけになります。

出力形式を固定する

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

{
  "building_code": "B-031",
  "month": "2026-10",
  "summary": "",
  "out_of_range": [
    { "item": "相対湿度", "location": "5階 事務室", "value": "36%",
      "onsite_action": "記録なし", "next_action": "" }
  ],
  "findings": [
    { "item": "空調機フィルター", "status": "注意", "location": "屋上 AHU-2",
      "observation": "", "recommendation": "", "photo_files": [""] }
  ],
  "carry_over": [
    { "item": "", "last_month": "", "this_month": "" }
  ]
}

公式のページでは、構造化出力は output_config.format に type: "json_schema" の形でスキーマを渡し、オブジェクトの additionalProperties は false にする必要があります。数値の minimum・maximum のような制約は使えず、使うと400のエラーになります。値の範囲の確かめは、もともとルールの側で行うので、スキーマには型だけを書きます。

1つ目の理由は、文書の決まった場所に流し込めることです。 summary は冒頭、out_of_range と findings は表、carry_over は末尾に入れます。自由文で返させると、毎回見出しの位置が変わり、体裁を直す時間が残ります。

2つ目は、onsite_action を後から確かめられることです。 「記録なし」が入っている件数を数え、多い点検員には、その場の対応を書く欄の使い方を伝えます。

システムへ連携する

オーナーへのメールは、この構成からは送りません。 下書きの文書ができたことを業務管理課の担当者に知らせるところまでです。PDF にしてオーナーへ送るのは課長が行います。 確認の前の報告書がオーナーに届く経路を作らないためです。

UrlFetchApp の呼び出しは、Google Workspace のアカウントで1日10万回までです。45棟の月1回の報告書と、点検員の送信ごとの Forms API の呼び出しでは、上限の心配はありません。

人が確認する

担当者は、建物ごとの報告書の下書きを、次の順で確かめます。

1. 基準外の値の表 … 値・場所が点検記録のシートと合っているか。平均で比べる項目が、平均で書かれているか
2. 「記録なし」の欄 … 点検員に確かめ、その場の対応を書き足すか、「記録なし」のままにするかを決めます
3. 所見と推奨する対応 … 記録に無い対応が書かれていないか。推奨の書きぶりがオーナーにとって的確か
4. 写真 … 所見と写真が対応しているか。テナントの名札や書類が写り込んでいないか
5. 直した箇所を残す … どの部分をどう直したかを、点検記録のシートの「確認」の列に書きます

例えば、5階の事務室の相対湿度が36％で基準外と出た建物です。 下書きの onsite_action は「記録なし」です。担当者が点検員に確かめると、加湿器の給水の弁が閉じていたので開けた、と分かります。担当者はその対応を書き足し、next_action に「翌週の再測定」を入れます。 記録に無かった対応を書けるのは、点検員に確かめた人だけです。

4番目の写り込みは、必ず人が見ます。 居室の測定の様子を撮った写真には、テナントの社員や机の上の書類が写ることがあります。オーナーに渡す前に、写真を差し替えるか、使わないかを決めます。

例外に対処する

上の3行は、すべて点検員の側で直せるものです。 メールには、空いている欄の名前と、フォームを出し直すためのリンクを入れます。 送信の直後に返すので、月初めに担当者が点検員を追いかける時間が無くなります。

記録を残す

• フォームの回答の全項目と、写真のファイルID（点検記録のシート）
• ルールが付けた印（記入漏れ・写真なし・範囲外・基準外）と、そのとき使った基準のシートの版
• Claude API に渡した記録と、返ってきた JSON の全文
• 担当者が直した箇所と、課長の確認の日時
• オーナーへ送った PDF のファイル
• 点検員への記入漏れの知らせの件数（点検員ごと・月ごと）

2つ目の「基準のシートの版」を残すのは、基準が変わることがあるためです。 基準の数値は政令の改正で変わることがあり、施行令にも改正の履歴が重なっています。当時の基準が残っていないと、過去の報告書の「基準外」が何に照らしたものか分からなくなります。

最後の行は、点検員への教育の材料になります。 件数は月初めの処理のついでに数えます。 知らせの件数が減らない点検員には、フォームの欄の意味を個別に説明します。