障害者のグループホームで世話人が日々フォームに残す記録から、利用者ごとの月次の支援記録の要約を作り、モニタリングの材料にする

処理の起点を決める

トリガーは2つ置きます。 1つ目は、フォームの送信のたびに動くトリガーです。Apps Script のインストール型のトリガーには、フォームそのものに付けるものと、フォームの回答先のスプレッドシートに付けるものの2つの版があるとされています。ここでは回答先のスプレッドシートに付けます。 記録に番号を振り、「至急」の印があれば管理者に知らせるだけの短い処理です。

2つ目は、毎月1日の朝6時台に動く時間主導型のトリガーです。時間主導型のトリガーは毎分から月に1回までの間隔で動かせ、公式のページでは、9時に設定すると9時から10時のあいだのどこかで動くとされています。サービス管理責任者が出勤する前に、確認の一覧ができているようにします。

インストール型のトリガーは、作った人のアカウントで動きます。 公式のページにそう書かれています。トリガーはサービス管理責任者個人ではなく、事業所の記録を管理する共用のアカウントで作ります。 担当が異動したり退職したりしてアカウントが止まると、トリガーも一緒に止まるためです。トリガーが失敗すると失敗のまとめのメールが届くので、その宛先も共用のアカウントになります。

入力データを集める

質を決めるのは、目標の一覧です。 計画の目標が文書の中にしか無いと、AI は記録をどの目標に結び付けてよいか分かりません。計画を作るたびに、目標を1行1目標でシートに写すことを、最初の準備作業にします。

不在の予定を入れているのは、④の確認を自動にするためです。 記録の無い日が外泊の期間に入っていれば「不在」、入っていなければ「記録の抜け」として数えます。この区別をしないと、帰省の多い利用者ほど記録が少ないと出てしまいます。

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

シートは範囲を一度に読み、スクリプトの中で利用者ごとにまとめます。 月に3,000件の記録を1行ずつ読むと、1回の実行時間に収まりません。フォームの送信のたびに振る記録の番号は、「住居の記号＋年月日＋連番」の形で、後から人が見ても分かるものにします。

フォームの送信のイベントからは、質問の名前と回答の組（namedValues）と、スプレッドシートの並びどおりの回答（values）が受け取れるとされています。 公式の例では、1つの回答でも配列に入って返る形になっているので、値は配列の1つ目を取り出してから使います。

AIへ渡す前に整形する

1. 期間の確認 … 前月の1日から末日までの記録だけに絞ります。送信が遅れて翌月にずれ込んだ記録は、記入の日付の欄で前月に戻します
2. 氏名の置き換え … 記録の中の利用者の氏名と呼び名を利用者番号に置き換えます。ほかの利用者の名前は【他の利用者A】のような記号に、職員の名前は【世話人】【生活支援員】のような役割に置き換えます
3. 連絡先などの除去 … 自由記述に書かれた電話番号、住所、銀行の口座の番号を、決まった形で見つけて伏せます
4. 欄ごとの数え上げ … 食事・睡眠・服薬・体調の欄で「いつもと違う」を選んだ日の数、服薬の欄の「飲み忘れ」「拒否」の回数をスクリプトが数えます
5. 記録の無い日の区別 … 記録が1件も無い日を拾い、不在の予定に入る日は「不在」、入らない日は「記録の抜け」とします
6. 至急の記録の扱い … 「至急」の印が付いた記録は、要約の材料に含めたうえで、管理者の対応の記録が付いているかを確認の一覧に出します
7. 記録の並べ方 … 1件ずつ「記録の番号｜日付｜時間帯｜欄｜記入の内容」の1行にして、日付の順に並べます

2番目を省かないでください。 グループホームの記録には、同じ住居のほかの利用者のことが必ず出てきます。「【他の利用者A】とテレビのチャンネルで言い合いになった」という記録を、ほかの利用者の名前のまま外に出す理由はありません。 置き換えの対応表はスプレッドシートの中だけに置きます。

4番目の数え上げを AI に任せないのは、数を誤ると支援の判断を誤るからです。 「服薬の拒否が月に何回あったか」は、医療機関に相談するかどうかの手がかりになります。数はスクリプトが数え、AI には渡しません。 要約の中では【服薬拒否の回数】のような記号で書かせ、差し込みはスクリプトが行います。

AIに処理させる

させるのは、利用者1人の1か月分の記録を、計画の目標ごとに要約し、本人の言葉と記録の抜けを書き出すことです。

本人の言葉は、言い換えさせません。 「仕事がつらい」と書かれていれば「仕事がつらい」のまま写させます。本人の意向は、計画の見直しのときに本人に確かめる事柄で、その手がかりは本人の言い方そのものです。

「記録が薄かった点」を書かせるのは、記録の偏りを見えるようにするためです。 「週に1回は自分で買い物に行く」という目標に関係する記録が月に1件も無ければ、行かなかったのか、行ったのに誰も書かなかったのかが分からないということです。それを要約の側から知らせ、翌月の記録の書き方を見直す材料にします。

2行目は、とくに強く禁じます。 「こだわりの強さから」のような説明は、要約しようとすると AI が自然に足してきます。

指示内容を固定する

あなたは障害者のグループホームで、サービス管理責任者が月次の支援記録を
まとめるのを手伝う担当です。以下の「記録の一覧」だけを使って、
利用者1人の1か月の様子を、計画の目標ごとに要約してください。

【書き方】
- goals：目標の一覧の目標ごとに、関係する出来事を2〜4文で書く。
    1文ごとに、根拠にした記録の番号を record_ids に入れる。
    関係する記録が無い目標は、summary を空にし、thin を true にする。
- daily_life：目標に入らない食事・睡眠・余暇・人との関わりを2〜3文で。
- own_words：本人が話したこととして「」で書かれたものを3つまで、
    記録に書かれたとおりに写す。言い換え・要約をしない。
- 文は「〜していた」「〜と話していた」のように、出来事として書く。

【厳守事項】
- 記録に書かれていないことを書かないでください。推測で補わないでください。
- 本人の状態を評価する言葉（落ち着いた、不安定、意欲、改善、悪化など）を
  使わないでください。
- 出来事の理由を、障害・病名・性格で説明しないでください。
- 回数・日数・割合を書かないでください。数を述べるときは、
  数え上げの記号（【服薬拒否の回数】など）をそのまま置いてください。
- 計画の見直し、支援の変更、受診をすすめる文を書かないでください。
- 事故・けが・虐待の有無を判断しないでください。該当しそうな記録があれば
  flagged_records に番号だけを入れてください。
- 【他の利用者A】【世話人】などの記号は、そのまま使ってください。
  記号を名前に戻したり、人物を推測したりしないでください。
- 1文ごとに record_ids を付けてください。根拠の無い文は書かないでください。

【利用者番号】{resident_id}
【計画の目標】{goals}
【数え上げの記号】{count_tokens}
【記録の一覧】{records}

「理由を書かない」と「評価の言葉を使わない」を分けて書いているのは、片方だけでは足りないためです。 評価の言葉を禁じても、「疲れからか、夕食を残していた」のように理由の形で解釈が入ります。解釈は形を変えて入ってくるので、入り口を2つとも閉じます。

flagged_records を設けているのは、AI に判断させずに目を向けさせるためです。 転倒やけが、金銭の貸し借りのような記録は、要約に溶かすと埋もれます。番号だけを返させて、確認の一覧の先頭に出します。

出力形式を固定する

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

{
  "resident_id": "R-0412",
  "goals": [
    { "goal_no": 1, "summary": [
        { "text": "", "record_ids": ["B3-20261008-02"] } ],
      "thin": false }
  ],
  "daily_life": [ { "text": "", "record_ids": [] } ],
  "own_words": [ { "quote": "", "record_id": "" } ],
  "flagged_records": [],
  "needs_review": ""
}

1つ目の理由は、根拠の番号をスクリプトで検算できることです。

3行目が、本人の言葉を守る検査です。 文字列の一致で見るので、言い換えは必ず見つかります。

2つ目は、thin で記録の偏りを数えられることです。 毎月 thin が付く目標は、記録の書き方か、目標そのものの立て方に見直す余地があります。それを決めるのは計画の見直しの会議で、 一覧はその材料になります。

公式のページでは、構造化出力は数値の最小値・最大値や文字列の長さの制約に対応しないとされているので、文の数や長さの確かめはスクリプトの側で行います。スキーマは最後の利用から24時間保たれるとされているので、60人分を同じ朝に続けて作る形が合っています。

システムへ連携する

API の呼び出しでは muteHttpExceptions を true にします。 公式のページでは、これを true にすると失敗の応答でも例外を投げず、応答を返すとされています。応答のコードを見て、混み合いなら時間をおいてやり直し、それ以外の失敗はその利用者を確認待ちに回します。 API キーはスクリプトのプロパティに置きます。公式のページでは、スクリプトのプロパティはそのスクリプトの利用者全員で共有され、スクリプトの間では共有されないとされています。

至急の通知には、記録の本文を入れません。 住居と記録の番号だけを知らせ、管理者は回答のスプレッドシートで本文を読みます。 通知のメールが転送されたり、個人のスマートフォンに残ったりしても、利用者の様子が外に出ないようにするためです。

確定版は、人が確認の一覧から事業所の記録の様式に写します。 請求のソフトには書き込みません。

人が確認する

60人分の全件を、担当のサービス管理責任者が読みます。 確認の一覧には、利用者ごとに目標ごとの要約、本人の言葉、数え上げ、記録の抜け、検査の結果、flagged_records が並びます。

1. flagged_records を先に見る … 転倒やけが、金銭の出来事など。管理者の対応の記録が付いているかを確かめます
2. 確認待ちを片づける … 根拠の番号が合わないもの、言い換えのあったもの
3. 目標ごとの要約を読み、根拠の記録を1つずつ開く … 要約の文が記録の内容とずれていないか。1文に1つは開きます
4. 記録の抜けと thin を見る … 抜けの多い住居と曜日を、翌月の職員会議の議題にします
5. 直して確定する … 月次の記録の様式に写し、確定の日と確定した人を残します

3番目が、この構成でいちばん時間を使うところです。 要約は記録の番号でたどれるので、読み返すのは要約の根拠になった十数件だけで足ります。 50件を全部読み返していた①の15分が、ここで短くなります。

1人8分を目安にします。 根拠を開いて確かめるのに5分、直して写すのに3分です。入居したばかりの利用者や、計画の見直しの月に当たる利用者は、もう少し丁寧に読みます。

例外に対処する

最後の行は、Apps Script の上限から来ます。 公式の上限の表では、スクリプトの実行時間は1回あたり6分で、トリガーで動かした合計の実行時間は個人のアカウントで1日90分、Google Workspace のアカウントで1日6時間です。60人分を1回で作ると6分を超えうるので、10人ずつ作り、残りがあれば数分後に動く1回きりのトリガーで続きを作ります。 トリガーはユーザー・スクリプトごとに20個までとされているので、続きのトリガーは動いたら消します。 API のやり直しは1人あたり3回までにします。

記録を残す

• 実行の日時、対象の月、利用者ごとの記録の件数
• 前処理で置き換えた名前の件数と、伏せた連絡先の件数（置き換えの対応表そのものはログに書かない）
• AI に渡した記録の一覧と、AI が返した JSON の全文
• 検査の結果と、確認待ちにした理由
• サービス管理責任者が直した箇所と、確定の日・確定した人
• flagged_records と、それに対する管理者の対応の記録への参照

日々の記録そのものは、回答のスプレッドシートが原本です。 運営の基準では、サービスの提供の記録を提供した日から5年間保存することとされています。要約を作ったあとも、元の記録は消さず、書き換えません。 要約は原本に添える下書きで、原本の代わりにはなりません。

3つ目で AI の返した JSON を残すのは、後から要約の出どころを示すためです。 家族や相談支援専門員から「この記録はどこから書いたのか」と聞かれたとき、根拠の記録の番号をたどって見せられます。