デイサービスのシフト表と勤務の実績から人員配置基準を満たしているかを日ごとに点検し、足りない日と理由の候補を管理者に返す
デイサービスの前の月の勤務の実績と利用者の数から、提供日ごとに介護職員・生活相談員・看護職員の配置を計算して基準と比べます。足りない日には、勤務の備考から理由の候補を添えて管理者に返します。
- 生成AI
- ChatGPT/Claude/Gemini
- 連携・自動化
- Google Apps Script/Make/Power Automate/Python
- 対象業界
- その他/介護/医療
- 対象部門
- 人事/総務
- 対象業務
- 内容確認・チェック/集計・分析
- 主な課題
- 属人化している/期限・対応漏れが起きる/確認ミスが多い
- AIで行う処理
- 判定
- 主な効果
- 入力漏れ削減/判断支援/工数削減
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 半自動化
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 本部の労務担当が、勤怠システムから前の月の出退勤のCSVを書き出し、事業所ごとに分けて管理者に送る
- 管理者が、介護ソフトから日別の利用者の数を書き出し、シフト表と並べる
- 提供日ごとに、利用者の数から介護職員の必要な時間数を電卓で計算する
- 出退勤の時刻とシフト表の割り振りから、介護職員・生活相談員・看護職員の時間を数える
- 兼務の職員について、備考を読んで職種ごとの時間を分ける
- 足りない日があれば、その日の事情を思い出してメモし、本部に報告する
- 本部が3か所分をまとめ、減算の要否を検討する
- 人本部の労務担当が、月初の1日に勤怠のCSVと介護ソフトの利用実績のCSVを決まったフォルダの決まったシートに貼る
- 自動毎月2日の朝、Apps Script が事業所ごと・提供日ごとに、利用者の数から必要な時間数を計算する
- 自動出退勤とシフト表の割り振りから、職種ごとの勤務時間を数える
- 自動打刻の漏れ、提供時間の中の空白、1割の境目に近い日を規則で拾う
- 自動足りない日と境目の日について、その日の勤務の備考を Gemini API に渡す
- 自動Gemini API が、数え方の確認が要る記録と理由の候補を JSON で返す
- 自動点検の一覧のシートに書き、管理者ごとに自分の事業所の要点をメールで送る
- 人管理者が、確認が要る記録と理由の候補を確かめ、打刻の漏れを直し、確認した理由を書き込む
- 人本部の労務担当が、直した記録で再計算した結果を見て、指定権者への相談や届出の要否を検討する
各工程の詳しい説明を読む
- 本部の労務担当が、勤怠システムから前の月の出退勤のCSVを書き出し、事業所ごとに分けて管理者に送る
- 管理者が、介護ソフトから日別の利用者の数を書き出し、シフト表と並べる
- 提供日ごとに、利用者の数から介護職員の必要な時間数を電卓で計算する
- 出退勤の時刻とシフト表の割り振りから、介護職員・生活相談員・看護職員の時間を数える
- 兼務の職員について、備考を読んで職種ごとの時間を分ける
- 足りない日があれば、その日の事情を思い出してメモし、本部に報告する
- 本部が3か所分をまとめ、減算の要否を検討する
(a)数え方が管理者ごとに違う。 兼務の職員の時間を、ある管理者はシフト表の割り振りどおりに分け、別の管理者は備考を見て15分単位で分けています。同じ勤務でも、事業所によって足りる日と足りない日が分かれます。 本部はその違いに気づけません。
(b)打刻の漏れが不足に見える。 退勤の打刻を忘れた職員は、勤怠システムの上では勤務時間が0時間です。管理者は「この日は足りない」と計算してから、打刻の漏れに気づいて数え直します。 月に何件も起きるので、計算を2回することになります。
(c)理由を思い出せない。 足りない日の事情は、その日のうちなら管理者が覚えていますが、月初に数えるときには3〜4週間が過ぎています。 「たぶん急な休みがあった」というメモでは、本部は減算の要否を判断できません。
(d)気づくのが遅い。 栃木県の実地指導の資料によれば、看護職員などの人員基準欠如は、1割を超えて減少した場合は翌月から、1割の範囲内なら翌々月から減算の対象になるとされています(翌月の末日に満たしていれば除く)。月初の集計が月の半ばまでずれ込むと、手当てを打つ時間が残りません。
- 【人】 本部の労務担当が、月初の1日に勤怠のCSVと介護ソフトの利用実績のCSVを決まったフォルダの決まったシートに貼る
- 【自動】 毎月2日の朝、Apps Script が事業所ごと・提供日ごとに、利用者の数から必要な時間数を計算する
- 【自動】 出退勤とシフト表の割り振りから、職種ごとの勤務時間を数える
- 【自動】 打刻の漏れ、提供時間の中の空白、1割の境目に近い日を規則で拾う
- 【自動】 足りない日と境目の日について、その日の勤務の備考を Gemini API に渡す
- 【自動】 Gemini API が、数え方の確認が要る記録と理由の候補を JSON で返す
- 【自動】 点検の一覧のシートに書き、管理者ごとに自分の事業所の要点をメールで送る
- 【人】 管理者が、確認が要る記録と理由の候補を確かめ、打刻の漏れを直し、確認した理由を書き込む
- 【人】 本部の労務担当が、直した記録で再計算した結果を見て、指定権者への相談や届出の要否を検討する
8番目が、この設計の分かれ目です。 AIが返すのは読み分けと理由の「候補」で、どの時間を介護職員として数えるかを決めるのは管理者と本部です。 管理者は印の付いた数行だけを見れば足ります。
2番目から4番目を規則で行うのは、すべて式で決まるからです。 式で決まることをAIに任せると、数字がぶれたときに誰も説明できません。
02今回想定するシステム構成
勤怠システムの出退勤CSV + 介護ソフトの日別の利用実績CSV │ 本部が月初に点検用のスプレッドシートへ貼る ▼【トリガー】毎月2日 7時台(時間主導型) Google Apps Script ├──▶ 提供日ごとの必要な時間数の計算(利用者の数と提供時間) ├──▶ 職種ごとの勤務時間の集計(出退勤×シフト表の割り振り) ├──▶ 規則による検出(打刻の漏れ/常時1名の空白/1割の境目) ├──▶ Gemini API(構造化出力) │ 足りない日・境目の日の備考 → 確認が要る記録・理由の候補 ├──▶ 点検の一覧のシートに書く └──▶ MailApp で管理者ごとに要点を送る ▼ 【管理者が記録を直し、確認した理由を書く】 ▼ 本部が再計算の結果を見て、指定権者への相談・届出の要否を検討
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 実行環境 | Google Apps Script | Power Automate、Make、Python |
| 生成AI | Gemini API(構造化出力。有料の枠で使う) | Claude API、OpenAI API |
| 保管 | Google スプレッドシート(出退勤、利用実績、シフト表、職員の一覧、数え方の表、点検の一覧) | - |
| 通知 | Gmail(MailApp) | Google Chat |
新しく足すのは、Apps Script と、職員の一覧・数え方の表・点検の一覧のシートだけです。 勤怠システムと介護ソフトにはつながず、書き出したCSVを貼るだけにします。
根拠にする基準は、指定居宅サービス等の事業の人員、設備及び運営に関する基準(平成11年厚生省令第37号)の第93条です。 介護職員については、単位ごとに、提供している時間帯に介護職員が勤務している時間数の合計を提供時間数で割った数が、利用者が15人までなら1以上、15人を超えるなら15人を超える部分を5で割った数に1を加えた数以上とされています。また、単位ごとに介護職員を常時1人以上従事させること、生活相談員は提供日ごとに勤務時間の合計を提供時間帯の時間数で割った数が1以上、看護職員は単位ごとに1以上とされています。実際の基準は事業所の所在地の条例で定められるので、本部が指定権者の資料もあわせて確かめます。
Apps Script は、点検用のスプレッドシートに付けるスクリプトとして書きます。 公式のページでは、インストール型のトリガーは作った人のアカウントで動き、メールもその人のアカウントから送られるとされているので、本部の共有のアカウントで作ります。
AIの処理は Gemini API の構造化出力で行います。 公式のページでは、/v1beta/interactions に送る要求の response_format に mime_type: "application/json" と schema を指定すると、スキーマに沿った JSON が返るとされています。スキーマでは enum と required が使えます。利用規約では、無料の枠では人が入力と出力を読むことがあり、有料の枠ではプロンプトと応答を製品の改善に使わないとされています。 職員の勤務の記録なので、有料の枠で使います。
03どうやって実装するのか
処理の起点を決める
点検は、毎月2日の7時台に動く時間主導型のトリガーを起点にします。 ScriptApp.newTrigger() に timeBased()・onMonthDay(2)・atHour(7) を続けて作ります。公式のページでは、時刻は少しずれることがあり、9時に設定すると9時から10時のあいだで選ばれ、その時刻が保たれるとされています。管理者の始業までに届けば足りるので、7時台にします。
2日にするのは、末日の打刻の修正がそろうのを待つためです。 本部は1日のうちにCSVを貼り、「貼付済」の欄に印を付けます。スクリプトは最初にこの印を見て、無ければ点検をせずに本部へ知らせます。 古いCSVのまま点検する事故を防ぐためです。
月の途中でも、メニューから期間を指定して手動で動かせるようにします。 手動の実行ではメールを送らず、一覧のシートだけを書き換えます。月の半ばに一度回せば、月末を待たずに偏りが見えます。
記録を直したあとの再計算もメニューから行います。 再計算ではAIを呼ばず、規則の計算だけをやり直し、確認した理由の列は上書きしません。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 出退勤 | 職員番号、日付、出勤・退勤の時刻、休憩、備考 | 勤怠システムのCSV |
| 利用実績 | 事業所、日付、その日の利用者の数(通所介護と、一体的に運営する第一号通所事業の合計) | 介護ソフトのCSV |
| シフト表 | 職員番号、日付、時間帯ごとの割り振り(介護・相談・看護・機能訓練・送迎・事務) | シフト表のシート |
| 職員の一覧 | 職員番号、所属の事業所、持っている職種(介護職員・生活相談員・看護職員など)、常勤・非常勤、常勤の所定の時間 | 職員の一覧のシート |
| 事業所の設定 | 提供時間帯、単位の数、定員 | 事業所の設定のシート |
| 数え方の表 | 割り振りや備考の言葉ごとに、どの職種の時間として数えるか・数えないか | 数え方の表のシート |
質を決めるのは、いちばん下の数え方の表です。 「送迎」「事務」「相談」のような言葉ごとに、どの職種に数えるか、数えないかを決めた表です。中身は本部が指定権者の資料と問い合わせから作り、AIにもスクリプトにも決めさせません。 表が無いと、第3章の(a)の数え方の違いがそのままスクリプトに写ります。
利用者の数は、通所介護と第一号通所事業を合わせた数を使います。 省令の第93条は、両方の指定を併せて受けて一体的に運営している場合、利用者の数を両方の利用者の合計で数えるとしています。介護ソフトの書き出しが事業ごとに分かれていれば、スクリプトで足します。利用者の名前は使わず、日別の人数だけを書き出します。
データの取得方法を決める
| 取るもの | どこから | どう取るか |
|---|---|---|
| 前の月の出退勤 | 出退勤のシート | 日付の列で前の月の行に絞る |
| 日別の利用者の数 | 利用実績のシート | 事業所と日付で引く |
| 時間帯ごとの割り振り | シフト表のシート | 職員番号と日付で引く |
| 職種・常勤の区分 | 職員の一覧 | 職員番号で引く |
| 数え方 | 数え方の表 | 割り振りの言葉で引く |
シートは実行の最初に getValues() でまとめて読みます。 公式の割り当てでは、1回の実行は6分までです。3事業所・月20日・職員70名なら、出退勤は月に1,500行ほどで、読み込みと計算は数秒で終わります。
処理は、次の順で行います。
1. 出退勤の時刻を15分単位の枠に分ける(提供時間帯の中だけを数える)
2. 各枠に、シフト表の割り振りと数え方の表から職種を付ける
3. 提供日ごとに、職種ごとの勤務時間の合計を出す
4. 介護職員の必要な時間数を出す
利用者15人まで:提供時間数 × 1
15人超:提供時間数 ×((利用者の数 − 15)÷ 5 + 1)
5. 規則で検出する
R1 介護職員の時間数が必要な時間数に届かない日
R2 提供時間帯の中に介護職員が0人の枠がある日
R3 生活相談員の時間数が提供時間数に届かない日
R4 看護職員が0人の日(月の平均の人数も別に出す)
R5 打刻の漏れ(出勤のみ・退勤のみ・勤務0時間なのにシフトあり)
R6 足りてはいるが、必要な時間数の110%未満の境目の日
6. R1〜R4・R6 の日について、その日の備考とシフトとの差を Gemini API に渡す
7. 一覧のシートに書き、管理者ごとにメールを送る
4番目の式は、第93条の文言をそのまま式にしたものです。 たとえば利用者22人、提供時間7時間の日は、(22−15)÷5+1=2.4 で、介護職員の勤務時間の合計が16.8時間以上必要になります。端数は丸めません。
R5 の打刻の漏れは、AIに渡す前に規則で拾います。 漏れのある日は R1 の計算が信用できないので、R1 に「打刻の漏れあり」と注記し、AIには「記録の欠け」として渡します。
R6 の境目の日を拾うのは、兼務の15分を数え直すだけで結果が変わる日だからです。
AIへ渡す前に整形する
- 提供時間帯の外を落とす … 9時15分より前、16時15分より後の勤務は、配置の計算に数えません。送迎で早く出勤した時間などがここに入ります
- 休憩を引く … 出退勤のあいだの休憩の時間を、勤怠の記録どおりに引きます。休憩の時刻が無いときは、シフト表の休憩の枠を使い、そうしたことを一覧に注記します
- 常勤の所定の時間を超えた分を分ける … 栃木県の資料では、常勤の従業者が勤務すべき時間数を超えて勤務した時間数は勤務延時間数に含めることはできないとされています。超えた分は別の列に分けて持ち、含めるかどうかは数え方の表の設定に従います
- 職員番号を記号に置き換える … AIに渡すのは、「職員A」「職員B」のような記号と、持っている職種、その日の割り振り、備考だけです。名前と職員番号は渡しません
- 備考に番号を振る … 「N-0312」のように、備考の1件ごとに番号を付けます。AIには根拠をこの番号で返させます
- 数字は規則で計算したものを渡す … 必要な時間数、職種ごとの時間数、不足の時間数はスクリプトで出した値を渡し、AIに計算させません
3番目は、栃木県の資料では生活相談員の指導のポイントとして書かれています。 介護職員にも同じ扱いをするかは、本部が指定権者に確かめてから表に入れます。
4番目で名前を外すのは、「職員〇〇の欠勤が多い」のような人に紐づいた理由を書かせないためです。
AIに処理させる
させるのは、足りない日と境目の日について、勤務の備考を数え方の表と照らし、「数え方の確認が要る記録」と「足りなかった理由の候補」を判定することです。
| 見るもの | させること | 例 |
|---|---|---|
| 割り振りと違う備考 | 数え方の確認が要るかの判定 | 割り振りは「介護」、備考は「13:00-14:00 相談対応」 → needs_review |
| 数え方の表に無い言葉 | 表に無い言葉として印を付ける | 備考「家族対応」 → not_in_table |
| 欠勤・早退の記述 | 理由の候補 | 「体調不良で早退 11:30」 → sudden_absence |
| 送迎の記述 | 理由の候補 | 「送迎延長 10:00-10:40」 → transport_delay |
| 打刻の漏れの印 | 記録の欠けとして扱う | R5 の職員 → record_missing |
理由の区分は、本部が決めた語彙から選ばせます。 急な欠勤・早退、送迎の延長、兼務の振替、利用者の急な増加、打刻・記録の欠け、研修・会議、備考からは分からない、の7つです。区分をそろえると、3事業所の不足を同じ物差しで並べられます。
| させないこと | 理由 |
|---|---|
| 基準を満たしているかの結論 | 規則の計算と、指定権者の解釈で決まる |
| 時間数の計算・数え直し | スクリプトで計算した値を使う |
| 数え方の表に無い言葉の扱いを決める | 本部が指定権者に確かめて表に足す |
| 減算や届出についての意見 | 本部と法人の判断 |
| 特定の職員の勤務ぶりの評価 | 人の評価に使わない |
| 備考に無い理由を推し量って書く | 事実として報告に持ち込まれる |
3行目が、この構成でいちばん守るべきことです。 「家族対応」のような表に無い言葉を渡すと、AIは「利用者の家族との面談は相談業務に当たるため生活相談員の時間です」と、もっともらしい解釈を書きます。 その解釈が指定権者のものと違えば、一覧の全部の日の数え方が誤ります。表に無い言葉は not_in_table とだけ返させ、扱いは人が決めます。
指示内容を固定する
あなたは通所介護事業所の法人本部で、前の月の勤務の記録を点検する担当です。
人員配置基準を満たしているかは判断しません。それは規則の計算と、
指定権者の解釈で決まります。あなたの仕事は、勤務の備考を読み分けることです。
【入力】
- 事業所、日付、提供時間帯、その日の利用者の数(計算済み)
- 必要な介護職員の時間数、職種ごとの勤務時間数、不足の時間数(計算済み)
- 規則で立った印(R1〜R6)
- その日の職員ごとの記録:記号(職員A など)、持っている職種、
時間帯ごとの割り振り、備考(note_id 付き)、打刻の漏れの印
- 数え方の表:割り振りや備考の言葉ごとの数え方
【してほしいこと】
1. 割り振りと備考が食い違っている記録を探し、review_items に入れる
- 数え方の表にある言葉なら status を needs_review にし、
表のどの行に当たるかを table_row に書く
- 表に無い言葉なら status を not_in_table にする
2. 不足や境目の理由の候補を1〜3つ、各60字以内で書く
3. 各候補に、根拠にした note_id を必ず付ける
4. 各候補に、次の区分から1つを付ける
sudden_absence / transport_delay / role_shift / user_increase /
record_missing / training_meeting / unknown
【厳守事項】
- 数え方の表に無い言葉について、どの職種に数えるべきかを書かないでください。
not_in_table とだけ返してください。
- 時間数を計算し直したり、丸めたりしないでください。
- 基準を満たしている・いない、減算になる・ならない、を書かないでください。
- 根拠の note_id が付けられない候補は書かないでください。
手がかりが無ければ区分を unknown にし、本文を
「備考からは理由が分かりません」としてください。
- 打刻の漏れの印がある職員の記録は、record_missing として扱い、
その職員の時間が足りないことを理由にしないでください。
- 特定の職員の勤務ぶりについての記述を書かないでください。
【その日の記録】{day_json}
【数え方の表】{rule_table}
解釈を禁じたうえで、not_in_table という返し方を用意しておくのが要点です。 返し方が無いと、AIは何かしらの職種を選んでしまいます。打刻の漏れの職員を理由にしない指示も同じで、言わなければ「職員Bの不在により不足」と、記録の欠けを事実のように書きます。
出力形式を固定する
構造化出力で、次の形の JSON を受け取ります。
{
"office": "",
"date": "",
"review_items": [
{ "staff_code": "",
"note_id": "",
"status": "needs_review | not_in_table",
"table_row": "",
"summary": "" }
],
"candidates": [
{ "reason": "",
"category": "sudden_absence | transport_delay | role_shift | user_increase | record_missing | training_meeting | unknown",
"note_ids": [""] }
]
}
スキーマでは status と category を enum で縛り、note_ids を required にします。返った note_id が渡した備考の番号に本当にあるかは、受け取ったあとにスクリプトで確かめます。 無い番号の候補は落とし、本部に知らせます。
理由の1つ目は、数字とAIの判定を別の層に置けることです。 必要な時間数、不足の時間数、R1〜R6 の印は、一覧のシートの列に規則が書きます。AIの JSON には数字を返させません。 メールの文の中の数字と、一覧の数字が食い違うことがありません。
2つ目は、review_items を数え直しの入口にできることです。 管理者が needs_review の記録を見て「この1時間は相談員の時間」と決めたら、シフト表の割り振りを直して再計算します。not_in_table は本部に集まり、本部が指定権者に確かめて数え方の表に行を足します。 表が育つほど、not_in_table は減っていきます。
管理者に届くメールは、一覧の該当する行をそのまま文にしたものです。
【前月の配置の点検:第2事業所(不足3日・境目2日・打刻の漏れ4件)】
■ 9月11日(金)利用者22名 介護職員 必要16.8h/実績15.5h(不足1.3h)[R1]
確認が要る記録:職員C「13:00-14:15 家族対応」→ 数え方の表に無い言葉
候補1[急な欠勤・早退]体調不良で11:30に早退した記録がある 根拠:N-0312
■ 9月18日(金)利用者26名 介護職員 必要22.4h/実績22.9h[R6 境目]
確認が要る記録:職員A 割り振り「介護」、備考「10:00-10:40 送迎延長」
■ 打刻の漏れ:9月4日 職員F(退勤なし)ほか3件 → 先に記録を直してください
※ 理由は備考からの候補です。確かめて一覧の「確認した理由」に書き込んでください。 システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 出退勤・利用実績のシート | SpreadsheetApp(読み取り) | 本部が貼ったCSVの中身 |
| シフト表・職員の一覧・数え方の表 | SpreadsheetApp(読み取り) | 割り振り、職種、数え方 |
| Gemini API | UrlFetchApp | 確認が要る記録と理由の候補の JSON |
| 点検の一覧のシート | SpreadsheetApp(書き込み) | 日ごとの計算、印、候補、確認した理由の空欄 |
| Gmail | MailApp | 管理者ごとの要点、本部への失敗の知らせ |
API キーはスクリプトのプロパティに置きます。 公式のページでは、スクリプトのプロパティはスクリプトのすべての利用者がアクセスできるとされているので、スクリプトの編集の権限は本部の数名に絞ります。 公式の割り当てでは、URL Fetch の呼び出しは Google Workspace のアカウントで1日10万回、MailApp の宛先は1日1,500で、月に一度、数通を送るこの構成では余裕があります。
勤怠システムと介護ソフトには書き込みません。 打刻の漏れは、管理者が勤怠システムで修正の申請をします。AIの呼び出しは事業所ごと・日ごとに1回で、月に十数回です。
人が確認する
管理者が見るのは、自分の事業所の印の立った日だけです。
- 打刻の漏れを先に直す … R5 の記録を勤怠システムで修正申請し、本部に貼り直しを頼みます。直すまでは、その日の不足は信用しません
needs_reviewの記録を確かめる … どちらが実際の勤務かを決め、割り振りを直しますnot_in_tableを本部に上げる … 自分で数え方を決めず、本部に「この言葉の扱い」を問い合わせます- 確認した理由を書き込む … 候補が合っていれば写し、違えば書き直します
本部は、再計算で不足が残った日を指定権者の資料と照らします。 一覧は材料で、結論ではありません。
目標は、60件をならして1件5分です。 印の立たない日は数字を流し見るだけ、印の立った日は記録の確認に数分、not_in_table の問い合わせは本部で数十分です。not_in_table が多い月は、数え方の表を育てる時期です。
例外に対処する
| 起きること | 対応 |
|---|---|
| 貼付済の印が無い | 点検をせず、本部に知らせる |
| 利用実績に無い日に勤務がある | 休業日の勤務として一覧の末尾に載せる。配置の計算はしない |
| 職員の一覧に無い職員番号 | unknown_staff として載せ、本部が職員の一覧を直す |
| シフト表に割り振りが無い勤務 | 職種を付けずに数え、no_assignment と注記する。介護職員の時間に勝手に数えない |
| 休憩の時刻が無い | シフト表の休憩の枠を使い、そうしたことを注記する |
| Gemini API が応答しない・形が違う | 一度だけやり直し、だめなら数字と印だけで送る。本部に知らせる |
返った note_id が存在しない | その候補を落とし、本部に知らせる |
| 6分を超えそう | 終わった事業所をスクリプトのプロパティに記録し、続きのトリガーで残りを処理する |
4行目を省かないでください。 割り振りの無い勤務を介護職員に数えると、不足の日が足りているように見え、誰も見に行きません。
記録を残す
- 点検の一覧のシート:月ごとのタブに、提供日ごとの利用者の数、必要な時間数、職種ごとの時間数、印、AIの候補、管理者が確認した理由
- その月に使った数え方の表の版(いつ、どの行を足したか)
- AIに渡した記録の番号の一覧と、返った JSON の全文
- 再計算の実行日時と、直した記録の一覧
- メールの送信日時と宛先
表の版を残すのは、表が後から育つからです。 当時の表が残っていないと、実地指導で過去の月の計算を説明できません。
04実装レベルの3段階
最小構成では、計算の時間は減りますが、備考を貼る手間が残ります。 境目の日がどれだけあり、数え方の表がどこまで足りないかを知る段階です。 半自動化で1件20分が5分になり、この段階が本記事の想定です。 計算と突き合わせ(①)は自動になり、兼務の時間の振り分け(②)は確認が要る記録だけを見る作業に、事情のメモ(③)は候補を写すか直す作業になります。 本格構成は、数え方の表が半年ほど安定してから考えます。 固まらないうちに予防の点検を始めると、予定と実績で数え方がずれます。
05工数削減シミュレーション
導入後 60件 × 5分 ÷ 60 = 5 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 通所介護(デイサービス)の事業所を2〜10か所ほど運営する法人。シフト表と勤怠の打刻を Google スプレッドシートや勤怠システムの書き出しで持っており、提供日ごとの配置を管理者が月末に電卓と目で数えている場合。兼務の職員(生活相談員と介護職員、看護職員と機能訓練指導員)が多く、どの時間をどの職種に数えるかが管理者ごとに違っている場合。Google Workspace を使っている場合。
- 事業所が1か所で、利用者の数が毎日ほぼ同じで配置に余裕がある場合。勤務の実績が紙の出勤簿だけで、時刻の記録が無い場合。すでに介護ソフトの勤務形態一覧表の機能で提供日ごとの配置を計算できている場合。なお、人員基準を満たしているかの最終的な判断と、減算の届出をするかどうかは、この構成では代替できません。指定権者(都道府県・市町村)の解釈に従ってください。
07最小構成で試す方法
- 先月の勤務から、管理者が「足りなかったかもしれない」と感じた日を5日選ぶ
- その5日の出退勤、シフト表、利用者の数を、職員の名前を記号に置き換えて書き出す
- 必要な時間数と職種ごとの時間数を、スプレッドシートの式で計算する
- 有料の枠で契約した Gemini の画面に、5日分の記録と数え方の表の下書きを貼り、第7章の指示の要点(表に無い言葉は解釈しない、根拠の番号を付ける、計算しない)を伝える
- 出てきた確認が要る記録と理由の候補を、管理者の記憶と突き合わせる
ここで見るのは、not_in_table の出方です。 表に無い言葉にAIが勝手な解釈を付けずに印だけを返すなら、構成は有効です。
| 出てきた内容 | 判断 |
|---|---|
| 管理者が覚えている事情と同じ候補が、根拠付きで出た | Apps Script で計算とつなぐ段階に進む |
| 表に無い言葉に職種の解釈を付けた | 指示の書き方で直る。返し方を用意する |
ほとんどの記録が not_in_table になった | 数え方の表が先。 AIの問題ではない |
3行目が出たら、管理者の頭の中の数え方が表になっていなかったということです。 表を作り、同じ5日で試し直します。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 打刻の漏れが不足に見える | R5 で先に拾い、記録の欠けとして注記する |
| 表に無い言葉にAIが解釈を付ける | not_in_table という返し方を用意し、解釈を禁じる |
| 割り振りの無い勤務を介護職員に数える | 職種を付けずに数え、no_assignment と注記する |
| 一体的に運営する第一号通所事業の利用者を数え忘れる | 利用者の数は両事業の合計にする |
| 提供時間帯の外の勤務を数える | 15分の枠に分け、提供時間帯の中だけを数える |
| 常勤の所定の時間を超えた分の扱いが決まっていない | 別の列に分けて持ち、指定権者に確かめて表に設定する |
| 古いCSVのまま点検する | 貼付済の印を見て、無ければ止める |
| 再計算で確認した理由が消える | 書き込みの列をスクリプトが上書きしない列に分ける |
| 要約に職員の名前が出る | 記号に置き換えてから渡す |
| 一覧を減算の結論として使う | 一覧は材料。届出の要否は本部が指定権者の資料で決める |
上の2行が、この構成の信用を決めます。 打刻の漏れのたびに「不足」と出れば、管理者は一覧を読まなくなります。AIが数え方を勝手に決めれば、一覧の数字そのものが根拠を失います。
最後の行も重要です。 結論を一覧に任せると、数え方の表の1行の誤りが、そのまま届出の誤りになります。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 職員の出退勤の時刻、職種、常勤・非常勤の区分、勤務の備考(体調不良や家庭の事情が書かれることがある)、事業所ごとの日別の利用者の数です。
- 有料の枠で使う … Gemini API の利用規約では、無料の枠では人が入力と出力を読むことがあるとされています。職員の勤務の記録は無料の枠に流しません。 手元の画面で試すときも同じです
- 名前と職員番号をAIに渡さない … 記号に置き換えます。備考に名前が書かれていることもあるので、渡す前に職員の一覧の名前で置き換えます
- 体調の記述を広げない … 「体調不良で早退」のような記述は、理由の区分に置き換えて一覧に載せます。備考の原文は、本部と該当の管理者だけが見られるタブに置きます
- 人の評価に使わない … 一覧は配置の点検のためのものです。欠勤や早退の回数を職員ごとに数える使い方をしないことを、管理者に伝えます
- 一覧を基準の結論として扱わない … 基準を満たしていたか、減算の届出が要るかは、本部が指定権者の資料と照らして判断します
- API キーの管理 … スクリプトのプロパティに置き、スクリプトの編集の権限を本部の数名に絞ります
利用者の個人情報は、この構成に入れません。 必要なのは日別の人数だけです。
誤りが起きた場合のリスクは、足りない日を見落とすことと、足りていた日を足りないと報告することの2つです。 前者は割り振りの無い勤務を数えると起き、後者は打刻の漏れを不足と取り違えると起きます。どちらも規則の側で防ぎ、AIには読み分けだけを任せます。
10まず何から始めるか
1週目:数え方の表の下書きを作る
3事業所の管理者に、シフト表の割り振りの言葉と、勤怠の備考によく書く言葉を出してもらいます。本部がそれを1つの表にまとめ、言葉ごとに「介護職員に数える/生活相談員に数える/数えない/未定」を付けます。 未定の行は、指定権者の資料で確かめるか、問い合わせます。
2週目:5日で試す
先月の気になる5日について、式で計算し、名前を記号に置き換えた記録を有料の枠の Gemini の画面に貼ります。表に無い言葉にAIが解釈を付けていないかを最優先で見ます。
3週目:書き出しの手順を決める
勤怠システムと介護ソフトから、何を、どの形で書き出して、どのシートに貼るかを決めます。利用者の一人ひとりの記録を書き出さない手順にします。
4週目:計算と規則の検出までを作る
Apps Script で、15分の枠への分割、職種の付与、必要な時間数の計算、R1〜R6 の検出、一覧のシートへの書き込みまでを作ります。この時点ではAIを呼ばず、数字と印だけの一覧を本部が見ます。
2か月目: Gemini API の呼び出し、根拠の番号の照合、管理者へのメールを足します。3か月目以降: 月の半ばの手動の点検を始め、not_in_table の件数を数えます。not_in_table がほぼ出なくなり、3事業所の一覧が同じ数え方で月の2日にそろうようになった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| 指定通所介護の従業者の員数。生活相談員は提供日ごとに勤務時間数の合計を提供時間帯の時間数で除して1以上。看護職員は単位ごとに1以上。介護職員は単位ごとに、勤務時間数の合計を提供時間数で除した数が利用者15人までは1以上、15人超は超える部分を5で除した数に1を加えた数以上。介護職員を常時1人以上従事させること。第一号通所事業と一体的に運営する場合は両方の利用者を数えること(2025年4月1日施行の版) | e-Gov 法令API: 指定居宅サービス等の事業の人員、設備及び運営に関する基準 第93条 | 2026-10-12 |
| 看護職員の数は1月間の平均を用いること。人員基準上必要な員数から1割を超えて減少した場合は翌月から、1割の範囲内なら翌々月から減算の対象となること(翌月末に満たしていれば除く)。常勤の従業者が勤務すべき時間数を超えた時間数は勤務延時間数に含められないこと(生活相談員の指導のポイント) | 栃木県: 実地指導・指導事例(通所介護)令和3年度版 | 2026-10-12 |
| インストール型のトリガーが作った人のアカウントで動き、メールもその人のアカウントから送られること。時間主導型のトリガーの時刻が9時なら9時から10時のあいだで選ばれ保たれること | Google Apps Script: Installable Triggers | 2026-10-12 |
onMonthDay() で月の日付を、atHour() で時刻を指定できること | Google Apps Script: Class ClockTriggerBuilder | 2026-10-12 |
| 1回の実行が6分まで。URL Fetch が Google Workspace で1日10万回、メールの宛先が1日1,500であること | Google Apps Script: Quotas for Google Services | 2026-10-12 |
| スクリプトのプロパティはスクリプトのすべての利用者がアクセスできること | Google Apps Script: Properties Service | 2026-10-12 |
/v1beta/interactions の response_format に mime_type: "application/json" と schema を指定すると JSON で返ること。enum・required が使えること | Gemini API: Structured output | 2026-10-12 |
| 無料の枠では人が入力と出力を読むことがあり、有料の枠ではプロンプトと応答を製品の改善に使わないこと | Gemini API Additional Terms of Service | 2026-10-12 |
人員配置基準の解釈と、減算の届出の要否は、事業所の指定権者(都道府県・市町村)の資料と問い合わせで確かめてください。 本記事は上記の公式のページと自治体の資料で確認できた範囲だけを扱っています。栃木県の資料は令和3年度版で、留意事項通知の引用を含みます。最新の通知は指定権者で確かめてください。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-1271)についてのご相談はこちらから。
