介護施設が職員から毎月集める勤務の希望をフォームで受け、Apps Script と AI で希望の食い違い・夜勤の回数の偏り・人手の足りない日を拾ってシフトの作成者に返す

処理の起点を決める

2つのトリガーを使います。 1つは、フォームの回答がスプレッドシートに記録されたときに動くフォームの送信のトリガー、もう1つは、締切の翌朝に動く時間主導型のトリガーです。どちらもインストール型で作ります。

公式のページでは、フォームの送信のトリガーには Google フォームに付けるものと、フォームの回答を受けるスプレッドシートに付けるものの2種類があるとされています。この構成ではスプレッドシートの側に付けます。 公式のイベントの説明では、スプレッドシートの側のイベントは namedValues（質問の名前と回答の組）と values（スプレッドシートの列の順の配列）、range（記録された範囲）を持つとされており、回答の行をそのまま受け取れます。

インストール型のトリガーは、作った人のアカウントで動きます。 主任個人ではなく、法人本部のシフト受付用のアカウントでトリガーを作ります。 トリガーが失敗すると、Apps Script から失敗のまとめのメールが届きます。その宛先も同じアカウントになり、本部の人事担当が毎朝見る運用にします。

締切の翌朝のトリガーは、時刻がずれうることを前提に朝6時台に置きます。 公式のページでは、9時に設定すると9時から10時のあいだに動くとされています。主任が出勤する前に一覧ができていれば足ります。

入力データを集める

フォームは、回答者のアカウントを記録する設定にします。 名前を手で入れさせると、「佐藤」「佐藤 花子」「さとう」が混ざり、職員台帳と結べません。職員台帳はアカウントで引きます。

日ごとの選択は、日付を行、選択肢を列にした表の形の質問にします。 1日に1つだけ選ぶ形にしておくと、「休み希望」と「夜勤できない」を同じ日に重ねる矛盾がフォームの側で起きません。

必要人数のシートは、主任が月初に入れます。 行事の日や入浴の日は日勤を多めにするなど、施設ごとの事情はこの表に持たせ、スクリプトには書きません。

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

回答は、トリガーのイベントで1行ずつ受け取ります。ただし、受け取った値だけで判断せず、回答のシートからその職員の最新の回答を読み直します。 職員が一度出した後で出し直すことがあり、最新の回答だけを採る必要があるためです。

同時に何人も送信したときに備えて、書き込みは1人ずつにします。 公式のページでは、LockService はコードの一部への同時のアクセスを防ぐもので、getScriptLock() はどの利用者が動かしたかにかかわらず同時の実行を止めるとされています。締切の直前は送信が重なるので、希望の表と確認の一覧に書く部分をスクリプトのロックで囲みます。 ロックは waitLock か tryLock を呼んで初めて取れるとされています。

AIへ渡す前に整形する

1. 回答者を結ぶ … 回答者のアカウントで職員台帳を引きます。台帳に無いアカウントは、確認の一覧に「台帳に無い」と出して止めます
2. 最新の回答を採る … 同じ職員の回答が複数あれば、送信の日時がいちばん新しいものだけを使い、古いものには「差し替え済み」の印を付けます
3. 日ごとの表にする … 日付ごとに「休」「日」「夜×」「可」の1文字にそろえます
4. 決まりと照らす … 希望休の日数、夜勤の希望回数と上限、夜勤ができると答えた日の並び（夜勤の翌日に「日」がないか）を数で確かめます
5. 職員の属性と照らす … 台帳で夜勤をしない職員が夜勤の希望回数を書いている、非常勤の職員の勤務できる日が上限を超えている、などを確かめます
6. 備考を整える … 前後の空白を除き、氏名や家族の名前が書かれていれば記号に置き換えます。備考が空なら AI には渡しません
7. AIに渡す表を作る … 日付と1文字の選択の並び、夜勤の希望回数、備考だけを渡します。職員の番号はその月だけの記号に置き換えます

4番目と5番目は、AI に渡しません。 「希望休が5日ある」は数えれば分かることで、判定の材料に推測が入る余地を残さないためです。

6番目は、備考に書かれやすい事情のためです。 通院、家族の介護、子どもの学校の行事など、職員の私生活に関わることが書かれます。 AIに渡すのは文面だけにし、誰の備考かは分からない形にします。

AIに処理させる

させるのは、備考の1つ1つの記述について、選択の表と合っているかを判定することです。

conditional を分けているのは、主任にとって大事な情報だからです。 「足りなければ出られる」という一言は、人手の足りない日を埋めるときの最初の手がかりです。選択の表には表れないので、AIが拾わないと見落とされます。

4行目がいちばん大事な禁止です。 「通院」と書かれた備考から病気の種類を推し量ったり、「家族の介護」から家庭の事情を書き足したりすると、職員の私生活に関わる推測が、主任の見る一覧に残ります。

指示内容を固定する

あなたは介護施設のシフトの担当を補助する立場です。
職員が翌月の勤務の希望として出した「選択の表」と「備考」を読み、
備考に書かれた記述が選択の表と合っているかを判定してください。

【選択の表の記号】
休 … 休み希望　日 … 日勤のみ　夜× … 夜勤できない　可 … どれでもよい
夜勤の希望回数 … 数字。空欄は「指定なし」

【判定の種類】
- conflict ....... 備考の記述と、その日の選択が食い違う
- not_reflected .. 備考に希望があるのに、選択の表に表れていない
- unclear_date ... 備考の日付が特定できない（「月末」「連休あたり」など）
- conditional .... 条件付きの申し出（「足りなければ出られる」など）
- consistent ..... 備考の記述と選択が合っている
- no_request ..... 勤務の希望と関係のない記述

【厳守事項】
- 備考を記述ごとに分け、1つずつ判定してください。
- 日付は、備考に書かれた日付と、対象の年月から特定できるものだけを
  dates に入れてください。曜日だけの記述は、対象の年月の暦から日付に直し、
  直したことを note に書いてください。特定できなければ unclear_date です。
- 希望を通すべきか、断るべきかを書かないでください。
- 事情の重さを比べたり、優先の順位を付けたりしないでください。
- 健康状態・病名・家庭の事情を推し量って書かないでください。
  備考に書かれた言葉を evidence にそのまま写すだけにしてください。
- 選択の表の値を直した案を出さないでください。
- question には、主任が職員本人に確かめるための短い質問を1文で書いてください。
  事情を詳しく尋ねる質問にしないでください（「理由を教えてください」は不可）。

【対象の年月】{target_month}（暦：{calendar}）
【選択の表】{choices}
【夜勤の希望回数】{night_count}
【備考】{note}

「理由を教えてください」を禁じているのは、聞き直しの文案がそのまま職員に届くためです。 確かめたいのは「10日は休みと勤務のどちらですか」であって、行事の中身ではありません。 事情を聞く文案が出ると、主任が気づかずにそのまま送ってしまいます。

曜日を日付に直すときに暦を渡しているのは、AIに暦を計算させないためです。 「第2週の土日」を正しい日付に直すには、その月の1日が何曜日かが要ります。スクリプトが対象の月の暦を作って渡し、AIはそれを引くだけにします。

出力形式を固定する

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

{
  "request_key": "R-1024",
  "items": [
    {
      "kind": "conflict | not_reflected | unclear_date | conditional | consistent | no_request",
      "dates": ["2026-11-10"],
      "evidence": "10日は子どもの行事で休みたいです",
      "note": "",
      "question": "11月10日は休み希望と勤務できる日のどちらでしょうか。"
    }
  ],
  "needs_review": ""
}

1つ目の理由は、判定を日付で表に戻せることです。 dates を使って、確認の一覧の該当する日の欄に印を付けます。主任は、どの日の希望に確認が要るかを表の上で見られます。

2つ目は、evidence をスクリプトで照合できることです。 evidence が備考の中にそのまま含まれているかを確かめ、含まれていなければ AI が言い換えたか作った記述として、確認待ちにします。

3つ目は、種類の値を決めておけることです。 公式のページでは、列挙型の値は大文字小文字だけ違う形で返ることがあるとされているので、比べるときは大文字小文字を区別しません。 構造化出力は数値の最小値・最大値の制約に対応していないため、夜勤の回数のような数の範囲はスクリプトの側だけで見ます。

システムへ連携する

API の呼び出しでは muteHttpExceptions を true にします。 公式のページでは、これを true にすると失敗の応答でも例外を投げないとされています。失敗したら備考の判定だけを「未判定」にし、決まりとの照合と希望の表への反映は先に済ませます。 AIが動かなくても、希望の受付そのものは止めません。

締切の翌朝の集計は、日ごとに次の3つを並べます。

夜勤の偏りは、職員ごとに「夜勤ができる日の数」と「夜勤の希望回数」を並べます。 夜勤ができる職員が少ない月は、一部の職員に夜勤が集まりやすくなります。誰に何回入れるかは主任が決めますが、偏りの材料は数で出しておきます。

人が確認する

主任が確認の一覧を、回答が届いた日のうちに見ます。

1. 台帳に無い・未判定を先に片づける … アカウントの取り違えや API の失敗です。多くは本部の人事担当が台帳を直せば解決します
2. conflict と not_reflected を聞き直す … 文案を使って職員に確かめます。文案に事情を尋ねる言葉がないかを読んでから送ります
3. 決まりとの合わなさを話す … 希望休が上限を超えている、夜勤の後の休みと合わないなど。通すか断るかは主任が決めます
4. 締切の翌朝、人手の足りない日を見る … conditional の職員から先に相談します
5. 判定が違っていたら記録する … AIが conflict としたが実は合っていた、など。種類と一言を残します

1人4分を目安にします。 聞き直しの要らない職員は一覧で流し見て数十秒、聞き直しが要る職員は文案を確かめて送るまで数分です。4分を超える月が続くなら、フォームの質問の作りに原因があります。

職員本人が出し直せるようにしておきます。 聞き直しへの答えは、職員がフォームを出し直す形にすると、最新の回答だけを採る前処理がそのまま効きます。 主任が手で希望の表を直すと、記録と表が食い違います。

例外に対処する

最後の行は、Apps Script の上限から来ます。 公式の上限の表では、スクリプトの実行時間は1回あたり6分、トリガーで動かした合計の実行時間は個人のアカウントで1日90分、Google Workspace のアカウントで1日6時間です。回答のたびの処理は1人分で短く済みますが、締切の直前に数十人が送ると合計の時間が積み上がります。職員1人あたりの回数が多くならないよう、出し直しは聞き直しへの答えのときに限るよう伝えます。 同時の実行はユーザーごとに30までとされているので、ロックで待たせる形と合わせて収まります。

記録を残す

• 回答の日時、回答者のアカウント、採った回答と差し替えた回答
• 希望の表（職員ごと・日ごと）と、そのとき使った決まりと必要人数
• 決まりとの照合の結果
• AIに渡した選択の表と備考（置き換えた後のもの）、AIが返した JSON の全文
• 検査の結果と、確認待ちにした理由
• 主任が聞き直した日、職員の答え、判定が違っていた記録

2つ目で「そのときの決まり」を残すのは、決まりが変わるためです。 希望休の上限や夜勤の回数は、人手の状況で年に何度か見直されます。後から「なぜこの希望が断られたのか」と聞かれたとき、その月の決まりで説明できます。

ログの保存の期間と、見られる人を決めておきます。 備考には私生活の事情が含まれます。本部の人事担当と、その施設の主任だけが見られるシートに置き、 翌月のシフトが確定して一定の期間が過ぎたら、備考の本文を消します。