Media > AI活用ユースケース > 総務 > 市役所が公民館の部屋の予約をフォームで受け、Apps Script と AI で利用目的を使用許可の基準に照らして、営利・政治・宗教の確認が要る申込を拾う

市役所が公民館の部屋の予約をフォームで受け、Apps Script と AI で利用目的を使用許可の基準に照らして、営利・政治・宗教の確認が要る申込を拾う

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

公民館の部屋の使用の申込をフォームで受け、定員と予約の重なりを規則で確かめ、利用目的を市の使用許可の基準に照らします。確認の要る申込を拾い、職員が許可するかを決めます。

サマリー
生成AI
ChatGPT/Claude
連携・自動化
Google Apps Script/Power Automate
対象業界
その他/教育/自治体
対象部門
総務
対象業務
内容確認・チェック/分類・仕分け
主な課題
判断に時間がかかる/属人化している/確認ミスが多い
AIで行う処理
判定
主な効果
判断支援/品質標準化/工数削減
導入難易度
★★☆☆☆
実装レベル
半自動化
費用感
API連携(中)
人間の確認
条件付き
現在工数
60h/月
AI導入後
20h/月
想定削減
67%
年間削減
480h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 職員が回答のスプレッドシートで新しい申込を開き、館・部屋・日時・人数を読む
  2. 予約の台帳を開き、その部屋の時間が空いているか、定員を超えていないかを見る
  3. 利用目的と催しの内容、参加費と物品の販売の記載を読み、取扱方針のどの区分に当たるかを考える
  4. 分からない点があれば、申込者にメールか電話で聞く
  5. 許可・条件付き・不許可を決め、台帳に書いて申込者に知らせる
導入後(After)
  1. 自動フォームに申込が届くと、Apps Script が動く
  2. 自動予約の台帳で、部屋の時間の重なり、定員、受付期間、連続使用の上限を規則で確かめる
  3. 自動前回までに許可した同じ団体・同じ利用目的の申込があるかを、許可の記録で引く
  4. 自動AIが利用目的と催しの内容を取扱方針の区分と例に照らし、区分の候補と確認の要る点を原文付きで挙げる
  5. 自動結果を確認の一覧に書き、確認の要る点があれば申込者への問い合わせの文案を Gmail の下書きにする
  6. 人職員が確認の一覧を見て、許可・条件付き・不許可を決める。問い合わせの下書きを直して送る
  7. 【人/自動】 職員の決定を台帳に書き、許可の記録に足す
各工程の詳しい説明を読む
  1. 職員が回答のスプレッドシートで新しい申込を開き、館・部屋・日時・人数を読む
  2. 予約の台帳を開き、その部屋の時間が空いているか、定員を超えていないかを見る
  3. 利用目的と催しの内容、参加費と物品の販売の記載を読み、取扱方針のどの区分に当たるかを考える
  4. 分からない点があれば、申込者にメールか電話で聞く
  5. 許可・条件付き・不許可を決め、台帳に書いて申込者に知らせる

(a)利用目的の読み方が職員で違う。 3番は職員の経験に寄ります。同じ「ヨガ教室」でも、ある職員はサークルの活動として無料で受け、別の職員は月謝の有無を聞きます。 申込者からは「前は何も聞かれなかった」と言われます。

(b)営利の判断に時間がかかる。 取扱方針の区分は、誰が会費を決めて集めるか、利益を誰の収入にするかで分かれます。申込の文から読み取れないことが多く、1件の判断のために方針の文書を何度も読み返します。

(c)確認の要る申込を見落とす。 毎月同じサークルの申込が大半なので、読み流す癖がつきます。 その中に「最後に商品の説明会を行います」のような一文があっても、気づかずに許可することがあります。

(d)予約の重なりと定員の確かめ漏れ。 2番は単純ですが、申込が多い週は省かれます。同じ部屋を2つの団体に許可してしまい、当日に気づくことがあります。

  1. 【自動】 フォームに申込が届くと、Apps Script が動く
  2. 【自動】 予約の台帳で、部屋の時間の重なり、定員、受付期間、連続使用の上限を規則で確かめる
  3. 【自動】 前回までに許可した同じ団体・同じ利用目的の申込があるかを、許可の記録で引く
  4. 【自動】 AIが利用目的と催しの内容を取扱方針の区分と例に照らし、区分の候補と確認の要る点を原文付きで挙げる
  5. 【自動】 結果を確認の一覧に書き、確認の要る点があれば申込者への問い合わせの文案を Gmail の下書きにする
  6. 【人】 職員が確認の一覧を見て、許可・条件付き・不許可を決める。問い合わせの下書きを直して送る
  7. 【人/自動】 職員の決定を台帳に書き、許可の記録に足す

3番目で、前回と同じ申込を見分けます。 毎月同じ日に同じ内容で使うサークルの申込は、前回の決定と、今回の申込の文の違いだけを見れば足ります。 文が変わっていなければ、確認の一覧の「前回と同じ」の欄に入れ、職員は流し見ます。

4番目のAIは、区分を決めません。 区分の候補を挙げ、その根拠にした申込の文と、取扱方針の例の文を並べるだけです。決めるのは職員です。

6番目は省けません。 使用の許可は公の施設の利用の判断で、申込者に不許可を伝えるのは市の決定です。

02今回想定するシステム構成

構成図
Google フォーム(部屋の使用の申込)
   ▼【トリガー】スプレッドシートの側のフォーム送信のトリガー
Google Apps Script(公民館の受付用のアカウント)
   ├──▶ 規則の点検(重なり/定員/受付期間/連続使用)
   │       └ スプレッドシート:予約の台帳、部屋の一覧
   ├──▶ 許可の記録を引く(同じ団体・同じ利用目的)
   ├──▶ Claude API:取扱方針の区分と例に照らす(構造化出力)
   ├──▶ スプレッドシート:確認の一覧
   └──▶ Gmail:問い合わせの文案の下書き(createDraft)
   ▼【人】職員が決定し、下書きを直して送る
役割想定する製品代替候補
実行環境Google Apps ScriptPower Automate
生成AIClaude API(構造化出力)OpenAI API
受付Google フォームMicrosoft Forms
保管Google スプレッドシート(回答、予約の台帳、部屋の一覧、許可の記録、確認の一覧、取扱方針の区分と例の表)-
メールGmail(公民館の受付用のアカウント)-

新しく足すのは、Apps Script と、確認の一覧・許可の記録・区分と例の表のシートだけです。 フォームと予約の台帳はいまのものを使い、フォームの欄を少し足します。

きっかけは、スプレッドシートの側のフォーム送信のトリガーです。 公式のページでは、このトリガーのイベントには、質問の名前と回答を持つ namedValues と、書き込まれた行の range が入ります。インストール型のトリガーは作った人のアカウントで動くので、職員の個人のアカウントではなく、公民館の受付用のアカウントで作ります。

AIは Claude API を UrlFetchApp で呼びます。 公式のページでは、構造化出力は output_config.format に type: "json_schema" を渡し、オブジェクトの additionalProperties を false にします。数値の minimum・maximum は使えません。

代替候補から Gemini API を外しているのは、申込者に18歳未満が混ざりうるからです。 申込者は18歳以上の決まりですが、フォームは誰でも送れます。Gemini API の規約は、18歳未満に向けた、または18歳未満が使いうる API クライアントの一部として使うことを禁じています。公民館は子どもも使う施設なので、この構成では使いません。

03どうやって実装するのか

Step1

処理の起点を決める

フォームの送信で、スプレッドシートの側のトリガーを動かします。 申込が届いたその時に、規則の点検とAIの照合が済みます。職員が朝に確認の一覧を開けば、前日の申込がそろっています。

フォームの側ではなく、スプレッドシートの側のトリガーを使うのは、行の位置が要るからです。 range で回答が書き込まれた行が分かるので、結果をその行の右の列と確認の一覧の両方に書けます。 職員は回答のシートからも結果を追えます。

同じ申込者の送り直しを見分けます。 送信を二度押した、内容を直して送り直した、という形です。同じメールアドレス・同じ館・同じ日時の申込が24時間以内にあれば、後の申込を「送り直し」として確認の一覧に入れ、 職員がどちらを残すかを決めます。

Step2

入力データを集める

データ中身取得元
使用の申込団体名、代表者、連絡先、館と部屋、利用日と時間、人数、利用目的、催しの内容、参加費・材料費の有無と額、誰が額を決めて集めるか、物品の販売の有無、参加者の範囲フォームの回答
予約の台帳館・部屋・日時ごとの予約と状態(許可・仮・取消)スプレッドシート
部屋の一覧館・部屋・定員・使える時間・連続使用の上限スプレッドシート
許可の記録団体名、利用目的、決定(区分・許可・条件)、決定日、決定した職員スプレッドシート
区分と例の表取扱方針の区分(A〜D)、区分の説明、「営利を主目的とする」とみなす例とみなさない例を1行1例でスプレッドシート

フォームに「誰が額を決めて集めるか」の欄を足します。 取扱方針では、サークルの話し合いで講師の謝礼や材料の実費を集めるのと、講師が会費や月謝を決めて集めるのとで、区分が分かれます。 この欄が無いと、申込の文からは読み取れず、ほぼすべての有料の申込に問い合わせが要ります。

区分と例の表は、取扱方針の文をそのまま1行1例に分けます。 例えば「自主サークル、地域団体等が会員の話し合いで決定した講師への謝礼や、会の運営実費、お茶代、材料実費等を扱うもの」で1行、「直接的な宗教活動(伝道所、普及所としての恒常的な使用、宗教儀式等での使用、特定の宗教の布教、勧誘活動等)」で1行です。行ごとに例の番号を振り、AIにはその番号で返させます。

Step3

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

取るものどこから何に使うか
申込の回答トリガーのイベントの namedValues と range点検と照合の材料、結果を書く行
その部屋のその日の予約予約の台帳の読み取り時間の重なり
部屋の定員と上限部屋の一覧の読み取り定員と連続使用の点検
前回までの決定許可の記録を団体名で引く前回と同じ申込の見分け
区分と例区分と例の表の全行AIへの入力

AIに渡すのは、利用目的・催しの内容・費用・物品の販売・参加者の範囲の欄だけです。 団体名、代表者、連絡先は渡しません。団体名を渡さないのは、名前で判断させないためでもあります。 政党や宗教団体の名前が入っていると、AIは活動の中身より名前に引っ張られます。

前回の決定は、団体名とメールアドレスの両方で引きます。 団体名だけだと、表記ゆれ(「〇〇体操の会」「〇〇体操会」)で引けません。メールアドレスで引けた前回の決定を優先します。

Step4

AIへ渡す前に整形する

  1. 送り直しの確認 … 同じメール・館・日時の申込が24時間以内にあれば印を付けます
  2. 規則の点検 … 予約の重なり、定員、受付期間、連続使用の上限を確かめます
  3. 前回との比べ … 前回の決定があれば、利用目的と催しの内容の文が前回と同じかを見ます
  4. AIへの入力を組む … 照合に使う欄と、区分と例の表の全行を並べます
  5. 空の欄の印 … 費用・物品の販売・参加者の範囲が空なら「未記入」と書いて渡します

2番目の規則は、AIに渡さずに決めます。

規則確かめ方当たったとき
予約の重なり台帳のその部屋の同じ日の予約と、開始と終了を比べる確認の一覧に「重なり」
定員人数が部屋の定員を超えるか「定員超過」
受付期間利用日が受付の始まりと締切の間か「受付期間外」
連続使用同じ団体の連続の日数が部屋の上限を超えるか「連続使用の上限」

3番目で文が前回と同じなら、AIを呼びません。 毎月同じ内容のサークルの申込は、前回の決定をそのまま候補にして確認の一覧に入れます。 文が1文字でも違えば、AIを呼びます。月600件のうち、AIを呼ぶのは半分ほどという想定です。

5番目を省くと、費用の欄が空の申込が「費用なし」として読まれます。 空の欄は、聞くことの一覧に入るべき欄です。

Step5

AIに処理させる

させるのは、申込の文を区分と例の表に照らして、区分の候補と、当てはまりうる例と、確認の要る点を挙げることだけです。

させること中身
区分の候補A(目的に沿った使用)・B(目的外使用)・C(内容と目的で判断が分かれる)・D(使用不可)のどれに近いか。決められなければ undetermined
当てはまりうる例区分と例の表の例の番号と、根拠にした申込の文の原文
確認の要る点区分を決めるのに要るが書かれていないこと
問い合わせの文案確認の要る点を申込者に聞く文(区分や許否には触れない)

区分の候補に undetermined を必ず置きます。 「ヨガ教室」とだけあって費用の欄が「未記入」なら、A とも C とも決められません。決められないことを決められないと返す値が無いと、AIはどれかに寄せます。

させないこと理由
許可・不許可を決める公の施設の使用の許可は市の決定
団体の名前や種類で判断する基準は活動の中身で見る。団体名は渡さない
書かれていない費用や販売を推し量る「教室」という言葉から月謝を決めつけない
表に無い例で判断する基準は市の取扱方針。AIの一般的な知識で足さない
問い合わせの文で許否を示す「不許可となる可能性があります」と書かない

3行目がいちばん起きやすい失敗です。 「書道教室」とあると、AIは「講師が月謝を徴収する教室と考えられるため、区分C」と書きます。サークルが先生を招いている場合は区分Aです。費用の欄が空なら undetermined にし、誰が額を決めて集めるかを聞かせます。

5行目も早く効いてきます。 問い合わせの文に「営利目的の場合はご利用いただけません」と書くと、ふつうのサークルの人が疑われたと感じます。 聞くのは事実だけにします。

Step6

指示内容を固定する

あなたは市の公民館の受付を手伝う立場で、部屋の使用の申込の利用目的を、
市の公民館の使用許可の取扱方針の区分と例に照らします。
許可するかどうかは職員が決めます。あなたは候補と根拠を挙げるだけです。

【区分と例の表】(各行の先頭は例の番号。区分は A/B/C/D)
{category_rows}

【申込】
利用目的:{purpose}
催しの内容:{content}
参加費・材料費:{fee}
誰が額を決めて集めるか:{fee_owner}
物品の販売:{sales}
参加者の範囲:{audience}
(空の欄は「未記入」と書かれています)

【やること】
1. 申込の文が当てはまりうる例を、表の中から選び、例の番号と、
   根拠にした申込の文をそのまま写す。
2. 当てはまりうる例から、区分の候補を A/B/C/D の1つにする。
   決められなければ undetermined にする。
3. 区分を決めるのに要るが書かれていないことを、questions に入れる。
4. questions を、申込者に聞くていねいな文にして inquiry_draft に入れる。

【厳守事項】
- 許可・不許可・条件を書かないでください。
- 団体の種類(政党、宗教団体、企業など)だけを理由に区分を選ばないでください。
  活動の中身として書かれていることだけで選んでください。
- 「教室」「講座」などの言葉から、月謝や販売があると推し量らないでください。
  費用や販売が「未記入」なら、questions に入れてください。
- 表に無い例を新しく作らないでください。
- inquiry_draft では、区分や、利用できない可能性に触れないでください。
  分からない事実を聞くだけにしてください。
- quote には申込の文をそのまま写し、言い換えないでください。

「団体の種類だけを理由に選ばない」を書くのは、取扱方針の考え方がそうだからです。 基準の例では、政党の市民向けの報告会は目的外使用として有料で使え、不可なのは選挙運動としての集会や特定の政党への勧誘です。宗教団体の勉強会も、勧誘など直接的な宗教活動を行わないものは判断が分かれる区分に入ります。名前で D に寄せると、基準と違う答えになります。

「未記入なら questions に」を、推し量りの禁止と並べて書くのも同じ理由です。 禁止だけだと、AIは費用なしの側に倒して A を返します。

Step7

出力形式を固定する

次の形のJSONで受け取ります。 構造化出力のスキーマで、各オブジェクトの additionalProperties を false にします。

{
  "category_candidate": "A | B | C | D | undetermined",
  "matched_examples": [
    { "example_no": "A-1-ア",
      "quote": "会員で話し合って講師の先生にお礼を出しています" }
  ],
  "questions": ["参加者から集める額と、その額を決めている方"],
  "inquiry_draft": "",
  "has_concern": true
}

1つ目の理由は、example_no で表の原文を並べられることです。 確認の一覧には、例の番号から表の文を引いて、申込の原文と取扱方針の原文を左右に並べます。 職員は2つの文を読んで決めます。

2つ目は、quote を申込と照合できることです。 Apps Script で quote が申込の欄の中にそのまま含まれるかを確かめ、含まれなければ「根拠の照合に失敗」と書きます。

3つ目は、has_concern で確認の一覧の並びを決められることです。 has_concern が true、または候補が C・D・undetermined の申込を上に並べ、A や B で問いの無い申込は下にまとめます。 職員は上から読みます。

問い合わせの文案は、questions が空でないときだけ Gmail の下書きにします。 公式のページでは、createDraft は宛先・件名・本文と、差出人の名前や返信先などの追加の項目を指定して下書きを作ります。差出人の名前を「〇〇市中央公民館」にし、返信先を受付のアドレスにします。

Step8

システムへ連携する

つなぎ先方式内容
フォームの回答のシートフォーム送信のトリガー申込を受け取り、結果をその行に書く
予約の台帳・部屋の一覧SpreadsheetApp の読み取り規則の点検。台帳には書き込まない
許可の記録SpreadsheetApp前回の決定を引き、職員の決定を足す
Claude APIUrlFetchApp(構造化出力)区分と例への照合
GmailGmailApp の createDraft申込者への問い合わせの下書き

予約の台帳には、Apps Script から書き込みません。 台帳に「許可」と書くのは、職員が決めたときだけです。AIの候補が A でも、台帳に仮の予約を入れません。 申込の時点で仮に押さえるかは、いまの運用どおり職員が決めます。

メールは送らず、下書きまでにします。 申込者への知らせは市の名前で出るので、職員が読んでから送ります。

Step9

人が確認する

職員が、確認の一覧を上から読みます。

  1. 規則に当たった申込を先に見る … 重なりと定員は、申込者に日時か部屋を変えてもらう連絡をします
  2. 区分の候補が C・D・undetermined の申込を見る … 申込の原文と表の例の原文を並べて読み、決めます
  3. 問い合わせの下書きを直して送る … 聞くことが事実だけになっているかを見ます
  4. 前回と同じ申込を流し見る … 前回の決定のとおりでよいかだけを見ます
  5. 決定を記録に書く … 区分、許可・条件付き・不許可、条件の中身、決めた職員を書きます

D の候補は、必ず係長以上が見る決まりにします。 不許可は申込者の使用を断る決定で、理由を説明できる必要があります。 表の例の番号と申込の原文が並んでいれば、説明の文が書けます。

条件付きの許可は、条件を文で記録に残します。 「チラシの配布は可、商品の説明と申込の受付は不可」「参加費は材料の実費まで」のように、当日に館の職員が見て分かる書き方にします。条件の文は、同じ団体の次の申込で、確認の一覧の前回の決定の欄に並びます。条件を守れなかった団体は、次の申込で職員が気づけます。

目標は、600件をならして1件2分です。 前回と同じ申込は数秒、確認の要る申込は申込者とのやり取りを含めて10分以上かかります。

Step10

例外に対処する

起きること対応
予約が重なる後の申込の申込者に、日時か部屋の変更を連絡する
送り直し確認の一覧で前後の申込を並べ、職員がどちらを残すかを決める
利用目的がほとんど空undetermined で問い合わせの下書きを作る
申込者が18歳未満と読める照合をせず、保護者か責任者からの申込を案内する
根拠の照合に失敗確認の一覧で申込の原文を職員が読む
AIの呼び出しが失敗する規則の点検だけを済ませ、「照合は未実施」として確認の一覧に入れる
区分と例の表を改めた表の版を変え、前回の決定との比べで「前回と同じ」にしない

4行目は、AIを呼ぶ前に Apps Script で止めます。 フォームの「申込者は18歳以上ですか」の欄が「いいえ」なら、AIに申込の文を渡しません。

別の書類が要る申込も、確認の一覧で分かるようにします。 基準の例では、物品の宣伝や販売を伴う集会やバザーには物品販売許可申請書を出させ、入場料や多額の受講料を集める講座や音楽会には予算書や企画書を求めて判断するとされています。フォームの「物品の販売:あり」「参加費:あり(額)」の欄から、Apps Script が要る書類の印を付けます。AIにさせるのは区分の照合だけで、書類の要否は欄の値で決めます。

欄の値確認の一覧に付ける印
物品の販売:あり物品の販売の申請書が要るかを確認
参加費:あり(決まりの額を超える)予算書・企画書の提出を依頼するかを確認
飲食:酒類あり館ごとの決まりを確認
参加者の範囲:一般に公開広報のちらしの案を見せてもらうかを確認

印は職員への知らせで、申込者への依頼ではありません。 申込者に書類を頼むかは、職員が区分を決めてからにします。

最後の行を忘れると、方針を改めても前回の決定が引き継がれます。 許可の記録に表の版を書いておき、版が違う前回の決定は「前回と同じ」として扱いません。

Step11

記録を残す

  • 申込の行と、規則の点検の結果
  • AIに渡した欄と、区分と例の表の版
  • 返ってきたJSONの全文(区分の候補、例の番号、根拠の原文、問い合わせの文案)
  • 職員の決定(区分、許可・条件付き・不許可、条件、決めた職員、日時)
  • 問い合わせの下書きを作った日時と、職員が送った日時
  • AIの候補と職員の決定が違った申込

4つ目は、市として説明を求められたときの記録です。 不許可や条件付きの理由を聞かれたとき、どの例に当たると判断したかを示せます。

最後の行は、区分と例の表を直す材料です。 AIの候補と職員の決定が同じ方向にずれ続けるなら、表の例の書き方が足りないか、職員の判断が方針から離れています。 どちらかを直します。

04実装レベルの3段階

最小構成:区分と例の表と申込を手でAIの画面に貼り、候補を挙げさせる / 1件ごとの利用目的の照合
半自動化:上記+Apps Script がフォームの送信で規則の点検とAIの照合をし、確認の一覧と問い合わせの下書きを作る / 申込の点検と照合の全体
本格構成:上記+職員の決定から予約の台帳への書き込みと、許可の通知の下書きまでを流す / 申込から許可の通知の下書きまで

最小構成は、確かめるための段階です。 600件には使えません。 半自動化で、1件6分が2分になります。この段階が本記事の想定です。 台帳を開いて空きを見る作業と、方針を読み返す作業がなくなり、職員は確認の一覧の上の方だけに時間を使います。 本格構成は、台帳の運用が整っている館向けです。 決定から台帳への書き込みまでを流せば、書き写しの手間は減ります。ただし、台帳への書き込みを自動にすると、誤った決定がそのまま予約になります。 半自動化で決定の記録が安定してから進めます。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
4 名
月間件数
600 件
1件あたり現在時間
6 分
1件あたり導入後時間
2 分
現在  600件 × 6分 ÷ 60 = 60 時間/月
導入後 600件 × 2分 ÷ 60 = 20 時間/月
月間削減時間
40h
削減率
67%
年間削減時間
480h
年間金額換算(時間単価3,000円)
144万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 市区町村の公民館・地区センター・生涯学習センターで、部屋の使用の申込をフォームで受け、月に数百件の申込を数名の職員で受け付けている場合。使用許可の基準(営利・政治・宗教の扱い、有料の目的外使用の区分)を取扱方針や要綱で文書にしているが、申込の利用目的をそれに照らす目が職員ごとに違う場合。Google Workspace を使っている、または使える場合。
向いていない
  1. 公民館が1館で、申込が月に数十件の場合。申込を紙と窓口だけで受けていて、電子で受ける見込みがない場合。使用許可の基準を文書にしておらず、館長の判断だけで決めている場合(先に基準を文書にする)。なお、使用の許可・不許可の決定と、公の施設としての利用の拒否に当たるかの判断は、この構成では代替できません。

07最小構成で試す方法

  1. 先月の申込から30件を選ぶ(職員が申込者に問い合わせた申込と、条件付き・不許可にした申込を必ず入れる)
  2. 取扱方針を、区分と例の番号を付けた1行1例の表にする
  3. 手元のAIサービスに表と1件分の申込の欄(団体名と連絡先を除く)を貼り、「当てはまりうる例を番号と根拠の原文で挙げ、区分の候補を出して。決められなければ決められないと答えて。許否は書かないで。書かれていない費用を推し量らないで」と指示する
  4. 出てきた候補を、当時の職員の決定と並べて読む

30件は必ずやってください。 スクリプトを書く前に、「表の書き方で、職員と同じ申込に確認の印が付くのか」を確かめます。

出てきた内容判断
当時問い合わせた申込に確認の印が付き、根拠も合っているスクリプトを書く段階に進む
「教室」から月謝を決めつける指示の書き方で直る。構成は有効
職員の決定と候補が大きく食い違う表の例の書き方が先。 方針の文を1行1例に分け直す

3行目は、職員どうしの判断の違いが見つかったということでもあります。 当時の決定が職員で分かれていた申込は、AIの候補ではなく、方針の読み方をそろえる話し合いの材料になります。

08実装時につまずきやすいポイント

問題対策
「教室」から月謝を決めつける推し量りを禁じ、未記入は問いに回す
団体の名前で D に寄せる団体名を渡さず、活動の中身だけで選ばせる
候補がどれかに寄せられるundetermined を置く
問い合わせの文が申込者を疑う許否と区分に触れず、事実だけを聞かせる
毎月のサークルでもAIを呼ぶ前回の決定と文を比べ、同じなら呼ばない
方針を改めても前回の決定が引き継がれる表の版を記録し、版が違えば比べない
送り直しで確認の一覧が二重になる同じメール・館・日時を24時間で見分ける
個人のアカウントで作ったトリガーが止まる受付用のアカウントで作る
構造化出力で400が返る数値の minimum・maximum は使えない。 スキーマから外す

上の2行が、この構成の失敗のほとんどです。 どちらも、AIが言葉の印象で判断することから起きます。取扱方針は活動の中身と費用の扱いで区分を分けているので、AIに渡す欄と指示を、その考え方にそろえます。

下の方の行は、毎月の運用で効いてきます。 前回と同じ申込でAIを呼ばないことは、費用と、職員が読む量の両方を減らします。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 団体名、代表者の氏名と連絡先、利用の日時と人数、利用目的と催しの内容です。団体の中には、政党、宗教団体、思想・信条に関わる活動をする団体があります。

  1. 団体名と代表者をAIに渡さない … 照合に要るのは活動の中身だけです。団体名を渡さないことは、名前で判断させないための設計でもあります
  2. 思想・信条で区別しない … 基準の例は、政党や宗教団体を公平かつ平等に扱うとしたうえで、活動の中身で不可を決めています。AIの候補で D が出ても、団体の性格ではなく、表の例の番号と申込の原文で説明できるかを職員が確かめます
  3. 許否をAIに決めさせない … 社会教育法は公民館が営利・特定の政党・特定の宗教を支援することを禁じていますが、個々の申込がそれに当たるかは市の判断です
  4. 18歳未満の申込をAIに渡さない … フォームの欄で18歳以上かを聞き、「いいえ」なら照合をしません。18歳未満が使いうるサービスでの利用を規約で禁じている Gemini API は使いません
  5. メールを自動で送らない … 問い合わせは下書きまでにし、職員が読んで送ります
  6. API キーをスクリプトのプロパティに置く … コードに直接書かず、受付用のアカウントの管理者だけが見られるようにします

誤りが起きた場合のリスクは、使えるはずの団体を断ることと、使えない活動を許可することの2つです。 前者は団体名を渡さないことと undetermined で、後者は表の例を1行1例にして漏れなく照らすことで抑えます。どちらも、職員が原文を並べて読むことが最後の止めになります。

10まず何から始めるか

1週目:取扱方針を表にする

市の公民館の使用許可の取扱方針を、区分(A〜D)と例の番号の付いた1行1例の表にします。職員4人で読み合わせ、同じ例を違う区分に読んでいないかを確かめます。

2週目:30件で試す

先月の申込30件を手元のAIサービスに貼り、表に照らして区分の候補と問いを出させます。「教室」から月謝を決めつけていないか、団体の種類で寄せていないかを最優先で見ます。

3週目:フォームを直す

「誰が額を決めて集めるか」と「申込者は18歳以上か」の欄を足します。費用と物品の販売の欄を選択肢にし、自由記入の欄は残します。

4週目:規則の点検から確認の一覧までをつなぐ

フォーム送信のトリガーで、規則の点検と前回との比べを確認の一覧に書きます。この時点ではAIを呼ばず、 職員がいまのやり方で照らします。

2か月目: AIの照合と問い合わせの下書きを足します。AIの候補と職員の決定が違った申込を毎週数えます。3か月目以降: 違いの多い例の行を書き直し、1件6分が何分になったかを実測します。職員どうしで決定が分かれる申込がほぼ無くなった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-15/最終更新:2026-10-23
確認した内容情報源確認日
公民館が、もっぱら営利を目的として事業を行い営利事業を援助すること、特定の政党の利害に関する事業を行い特定の候補者を支持することをしてはならないこと(第23条第1項)。市町村の設置する公民館が特定の宗教を支持し、特定の教派等を支援してはならないこと(同条第2項)。公民館の事業に、施設を住民の集会その他の公共的利用に供すること(第22条第6号)があることe-Gov 法令API: 社会教育法2026-10-15
使用の区分(A 目的に沿った使用・無料、B 目的外使用・有料、C 内容と目的で判断が分かれる使用、D 使用不可)と、区分ごとの「営利を主目的とする」とみなす例・みなさない例。政党等の市民向けの報告会が B の例であること、宗教団体の勉強会(勧誘など直接的な宗教活動を行わないもの)が C の例であること、選挙活動・直接的な政治活動・直接的な宗教活動が D の例であること(令和8年3月)君津市公民館の使用許可に関する取扱方針(PDF)2026-10-15
すべての政党・政治団体、すべての宗教団体を公平かつ平等に取り扱うこと。宗教団体の儀式を伴う集会、定員を超える集会を許可しないこと。18歳未満のグループは保護者又は責任者が申請し同席する場合に許可すること。連続使用が原則7日を限度とすること盛岡市公民館使用許可基準(PDF)2026-10-15
インストール型のトリガーにフォーム送信と時間主導型があること。作った人のアカウントで動くことApps Script: Installable Triggers2026-10-15
スプレッドシートの側のフォーム送信のイベントに namedValues と range が入ることApps Script: Event Objects2026-10-15
createDraft が下書きを作り、オプションに差出人の名前 name・返信先 replyTo などがあることApps Script: GmailApp2026-10-15
Google Workspace のアカウントで1回の実行が6分まで、URL Fetch が1日10万回までであることApps Script: Quotas2026-10-15
構造化出力で output_config.format に type: "json_schema" を渡すこと。オブジェクトの additionalProperties を false にし、数値の minimum・maximum が使えず400になることClaude: Structured outputs2026-10-15
API の利用者が18歳以上である必要があり、18歳未満に向けた、または18歳未満が使いうる API クライアントの一部として使ってはならないことGemini API: Additional Terms of Service2026-10-15

使用の許可・不許可は、市の取扱方針と条例に基づき、市が決めてください。 本記事の区分と例は君津市・盛岡市の公開の基準を参考にした構成例で、各市の基準は異なります。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-1741)についてのご相談はこちらから。

AI活用について相談する
目次