マンション管理会社のフロント担当が、毎月の理事会に出す収支・修繕・苦情対応の報告を記録から組み立て、報告文の下書きを作る

処理の起点を決める

毎朝、時間主導型のトリガーで動かし、8日後に理事会がある組合だけを処理します。 Apps Script の時間主導型のトリガーは毎分から月1回までの間隔で動かせますが、理事会の日は組合ごとにばらばらなので、月に1度まとめて作るより、毎朝その日の分だけ作るほうが合います。公式のページでは、毎朝の決まった時刻に設定してもその時刻から1時間のあいだのどこかで動くことがあるとされているので、担当者の出勤前に終わる時刻に置きます。

8日前にしているのは、担当者が直して理事長に送り、理事長の意見を受けて直す時間を取るためです。 理事長に資料を送るのは理事会の5日前、という決まりの会社なら、3日を担当者の手直しに使えます。

記録がそろっていないと止まります。 収支の月次は月初の数日で確定するので、前月の収支が「確定」になっていなければ、その組合は作らずに担当者へ知らせ、翌朝もう一度見ます。 修繕と苦情の記録は日々入るので、作った時点までのものを使います。

トリガーは担当者個人のアカウントではなく、部署で共有しているアカウントで作ります。 公式のページでは、インストール型のトリガーは作成者のアカウントで実行されるとされています。

入力データを集める

質を決めるのは、苦情の記録の「分類」と「状態」と、宿題の「進み具合のメモ」です。 分類と状態が入っていれば、報告文の骨組み（何の苦情が何件、うち何件が対応済み）はスクリプトでも作れます。AIに任せるのは、その骨組みに対応の要点を添える部分です。 進み具合のメモが空の宿題は、報告文に「進み具合の記録なし」と出し、担当者が書き足します。

部屋番号と申出者の列は、取得はしても AI には渡しません。 同じ部屋から同じ苦情が続いているかを数えるためにスクリプトの中でだけ使い、報告文の材料からは外します。

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

すべて同じスプレッドシートの別のシートにあるので、Apps Script から範囲をまとめて読み、組合と月で絞ります。

苦情は、前月に受けたものに加えて、それより前に受けて「対応中」のままのものも取ります。 理事会が気にするのは、先月の件数より片づいていない苦情がいくつ残っているかです。

差の計算はスクリプトで行います。 科目ごとに「前月との差」「予算との差」「予算に対する比率」を出し、組合の設定のシートにある幅（たとえば予算比で10％、かつ金額で5万円）を超えた科目に印を付けます。AIに渡すのは、印の付いた科目の名前、計算済みの差、その科目の前月の修繕と点検の記録だけです。

AIへ渡す前に整形する

1. 確定の印を確かめる … 前月の収支が確定していなければ作りません
2. 苦情の列を外す … 部屋番号と申出者の列を材料から外します
3. 本文の中の部屋番号を伏せる … 「305号室」「3階の東側」のような文字列を、決まった記号に置き換えます
4. 件数を数える … 苦情の分類ごとの件数、対応済みと対応中の件数をスクリプトで数えます
5. 同じ部屋からの続く苦情に印を付ける … 部屋番号は渡さず、「同じ申出が3か月続いている」という印だけを付けます
6. 差の大きい科目に修繕の記録を結ぶ … 修繕費が予算を超えたなら、前月の修繕の完了の記録を並べます
7. 組合の決まりを読む … 節の順番、入れない節（小規模で苦情の節を設けない組合など）を設定から読みます

3番目は、AIの指示と別に持つ防ぎです。 管理員の記録には「305の方から」のように部屋番号が書かれていることが多く、列を外しただけでは本文に残ります。 渡す前に伏せ、さらに第7章の出力の検査で、報告文に部屋番号らしい文字列が無いかをもう一度見ます。

5番目の印は、理事会が知るべきことです。 同じ申出が何か月も続いているのは、対応の方法を理事会で決める必要がある合図です。どの部屋かは出さず、「続いている」ことだけを伝えます。

AIに処理させる

させるのは、4つの節それぞれを、理事が数分で読める報告文に縮めることです。

収支の節では、差の理由を記録から探すだけにします。 修繕費が予算を超えた月に、修繕の完了の記録に「給水ポンプの部品交換」があれば、それを理由として書きます。記録に理由が見当たらなければ、「理由は確認中」と書かせます。

2行目と3行目が、この題材で特に気を付けるところです。 苦情の記録には、申出者の感情的な言葉や、相手の住人についての推測が書かれていることがあります。それをそのまま縮めると、理事会の資料に一方の言い分だけが載ります。 指示で、事実（何の申出が、いつ、何件）と対応（管理会社が何をしたか）だけを書かせます。

指示内容を固定する

あなたはマンション管理会社のフロント担当で、管理組合の理事会に出す
月次の報告文を書く立場です。以下の材料だけを使い、4つの節の報告文を
それぞれ数文で書いてください。理事が数分で読める長さにしてください。

【節ごとの書き方】
- finance：「差の大きい科目」の各科目について、関連する記録から分かる
  理由を1〜2文で書く。金額・差・比率は【差1】のような記号で書き、数字を
  直接書かない。記録から理由が分からなければ「理由は確認中」と書く。
- maintenance：前月の点検・見積・工事の内容と、次の予定を書く。
- complaints：分類ごとの件数は【件数_音】のような記号で書く。主な対応と、
  「続いている申出」がある場合はそのことを書く。
- followups：前回の宿題ごとに、進み具合と次の予定を書く。
  進み具合のメモが空なら「進み具合の記録なし」と書く。

【厳守事項】
- 部屋番号、階と方角、氏名、家族構成、ペットの種類など、
  部屋や人が分かる表現を書かないでください。
- 苦情の申出者・相手方を評価する言葉を書かないでください。
  書くのは申出の内容と、管理会社が行った対応だけです。
- 理事会への提案や、理事会が決めるべきことの結論を書かないでください。
- 材料にない経緯・理由・予定を補わないでください。
- 金額・件数・日付以外の数字も、材料にあるものだけを使ってください。
- used_tokens には、本文で使った記号をすべて並べてください。

【組合名】{association}（材料の中の固有名は書いてよいのは組合名と業者名のみ）
【差の大きい科目】{finance_flags}
【修繕と点検の記録】{maintenance}
【苦情の記録（伏せた後）】{complaints}
【前回の宿題】{followups}

「階と方角」を書き足しているのは、部屋番号を伏せても残るからです。 管理員の記録には「5階の北側」「角部屋」のような書き方がよく出てきます。小さなマンションでは、これだけで部屋が分かります。

「評価する言葉を書かない」も外せません。 何も言わないと、記録の中の「何度言っても改善しない」を「改善の意思が見られない」と縮めることがあり、管理会社がその住人を評価した文になります。

出力形式を固定する

Claude API の構造化出力で、次の形の JSON を受け取ります。 公式のページでは、output_config.format に json_schema を指定し、オブジェクトには additionalProperties: false を付けることとされています。

{
  "association_id": "M-0213",
  "finance": "",
  "maintenance": "",
  "complaints": "",
  "followups": "",
  "used_tokens": ["【差1】", "【件数_音】"],
  "unknown_reasons": ["修繕費"],
  "needs_review": ""
}

1つ目の理由は、節ごとにひな形へ差し込めることです。 ひな形の文書には節ごとの見出しと差し込みの記号を置いておき、本文の replaceText で記号を置き換えます。 公式のページでは、replaceText は検索の文字列を正規表現として扱い、文字のまとまりごとに照合するとされているので、ひな形の記号は書式を変えずに1度で入力しておきます。

2つ目は、記号の使い方を検算できることです。 本文の記号が used_tokens と一致するか、すべてが渡した記号かを確かめてから、スクリプトが記号を計算済みの値に置き換えます。

3つ目は、unknown_reasons で担当者の手を向けられることです。 「理由は確認中」と書いた科目が並ぶので、担当者は会計の担当に問い合わせる科目がすぐ分かります。

出力の検査は、置き換えの前にまとめて行います。

3行目の言い回しの一覧は、運用で育てます。 担当者が書き換えた箇所を処理ログに残し、同じ言い回しが続けば一覧に足します。構造化出力は文字列の長さの制約に対応していないため、節の長さもスクリプトで数え、長すぎれば確認待ちにします。

システムへ連携する

下書きは組合ごとのフォルダに置きます。 ドライブのファイルの makeCopy は、名前を付けて指定のフォルダにコピーを作るので、「2026-10 理事会報告（下書き）」のような名前で組合のフォルダに作ります。 理事長に送るときは、担当者が直した後で getAs('application/pdf') で PDF にするか、文書の共有で送ります。

記録のシートにも会計の仕組みにも書き込みません。 この構成が出すのは下書きまでです。

知らせは、担当者ごとにまとめて送ります。 同じ朝に複数の組合の下書きができた担当者には、1通のメールに組合名と下書きへのリンク、確認待ちの節を並べます。組合ごとに1通ずつ送ると、確認待ちの知らせが埋もれます。

人が確認する

1. 確認待ちを先に見る … 検査で止まった下書きは、該当の節に印が付いています。多くは部屋が分かる言い回しの書き換えです
2. 苦情と対応の節を読む … 部屋や人が分かる書き方が無いか、一方の言い分だけになっていないかを見ます
3. 収支の節を収支状況の書面と見比べる … 差し込まれた数字が書面と一致するか、「理由は確認中」の科目を調べて書き足します
4. 宿題の節を直す … 進み具合の記録が無い宿題を書き足します
5. 管理会社からの提案を書き足す … 理事会で決めてほしいことは、担当者が自分の言葉で書きます
6. 理事長に送る … 収支状況の書面と合わせて送ります

1件30分を目安にします。 白紙から90分かけて書いていたものを、30分で読んで直す形です。5番目の提案は、AIに書かせていない分、担当者の時間が残ります。 理事会で何を決めてほしいかを考えることは、フロント担当の仕事の中心だからです。

理事長から返ってきた意見も、次の月の材料にします。 「苦情はもっと短くてよい」「修繕は金額も並べてほしい」のような意見は組合ごとに違います。担当者が組合の設定のシートに一言書いておけば、翌月から指示に足して渡せます。 担当替えのときも、この欄を読めば、その理事会が何を求めているかが分かります。

例外に対処する

最後の行は、Apps Script の上限から来ます。 公式の上限の表では、スクリプトの実行時間は1回あたり6分です。1日に理事会が重なる組合は数組合なので普段は収まりますが、月初の土日に理事会が集中する週は、組合ごとに処理済みの印を付けながら作ります。 作成できる文書は Google Workspace のアカウントで1日1,500なので、下書きの数で困ることはありません。

記録を残す

• 組合ごとに、作った日時、使った記録の範囲（月、行の番号）
• 差の計算の結果と、印を付けた科目と幅
• AIに渡した材料（伏せた後のもの）と、返ってきた JSON の全文
• 検査の結果と、確認待ちにした理由
• 担当者が書き換えた箇所（部屋が分かる言い回しを書き換えたものは必ず）
• 理事長に送った日と、送った版

3つ目で「伏せた後の材料」を残すのは、伏せ方の漏れを後から見つけるためです。 報告文に部屋が分かる書き方が出たとき、材料の段階で残っていたのか、AIが書き足したのかを分けられます。材料の段階なら前処理の伏せ方を、AIなら指示を直します。

6つ目の「送った版」は、理事会の後に効きます。 理事会で「資料にこう書いてあった」と言われたとき、担当者が直す前の下書きか、直した後の版かをすぐに確かめられます。