介護施設で下膳の前に撮った食事の写真を厨房の基準の写真と比べ、主食・副食ごとの摂取量の下書きを作って、食事量が落ちている利用者を拾う

処理の起点を決める

トリガーは2つです。 1つはフォームの送信で、写真のファイルと、フロア・食事の区分・送信の時刻を処理待ちの一覧に1行ずつ積みます。ここでは Gemini API を呼びません。 もう1つは5分おきの時間主導型のトリガーで、一覧から「未処理」の行を古い順に最大8件取り出して処理します。

1件は2回の呼び出しで数秒から十数秒かかるので、1回の件数を決めて6分の上限の中で終わらせます。 時間切れが近づいたら、残りは次の回に回します。

厨房の基準の写真は、毎食の配膳の前に送ってもらいます。 献立日・食事区分（朝・昼・夕）・食形態を選び、1枚ずつ送ります。基準の写真が無い食事は、比較をせずに「基準なし」で止めます。 基準なしで見込ませると、AIが「普通の量」を想像して埋めてしまいます。トリガーは作った人のアカウントで動くので、施設で管理する専用のアカウントで作ります。

入力データを集める

質を決めるのは、基準の写真と献立表です。 基準の写真が無ければ「何割残ったか」の分母がありません。献立表が無ければ、どの器が主菜でどの器が副菜かを、AIが器の見た目から推測することになります。 品名を渡せば、「鯖の味噌煮が主菜」と決めた上で比べられます。

利用者の一覧に欠食と外出の予定を持たせるのは、空のお膳と写っていないお膳を区別するためです。 通院で昼食を食べていない利用者のお膳が無いのは正常です。予定が無いのに写真が無ければ、撮り漏れとして一覧に出します。

利用者の名前は渡しません。 食札には番号を大きく印字し、名前は小さくするか裏に回します。写真に名前が写らなければ、外部に渡るのは番号とお膳だけです。

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

フォームの送信のイベントから、アップロードされたファイルのIDが取れます。Apps Script で Google ドライブからファイルを読み、画像のバイト列をそのまま Gemini API に渡します。 1回の呼び出しで渡すのは、お膳の写真1枚と基準の写真1枚です。

直近の記録をAIに渡さないのは、見込みが過去に引っぱられるのを防ぐためです。 「この人はいつも10割」と知らせると、残りがあっても10割と答えやすくなります。1食分の見込みは写真だけから出させ、過去との比較はスクリプトが行います。

基準の写真は、同じ日の同じ食事のものを使います。 前の週の同じ献立で代用すると、盛り付けの量が違うことがあります。その日の基準が無ければ「基準なし」です。

AIへ渡す前に整形する

1. 形式の確認 … PNG、JPEG、WEBP、HEIC、HEIF のどれかであることを確かめます。それ以外は撮り直しです
2. 大きさの確認 … 2枚と指示を合わせて20MBを超えないようにします。タブレットの設定で、写真の大きさを中程度にしておきます
3. 向きの確認 … 横向きで撮られた写真は、向きの情報を見て直します
4. 重複の確認 … 同じ食事で同じ食札の写真が2枚あれば、後のものを使い、前のものに印を付けます
5. 欠食の照合 … 利用者の一覧で欠食・外出の予定がある利用者は、写真が無くても「欠食」として一覧に出します
6. 撮り漏れの確認 … 予定が無いのに写真が無い利用者を、そのフロアの一覧の先頭に出します

2番目を軽く見ないでください。 20MBを超えると呼び出しそのものが失敗し、小さくしすぎると小鉢の中が潰れます。最初の1週間で、見込みが崩れない大きさを決めます。

画像は768×768ピクセルのタイルごとに258トークンと数えられ、media_resolution で1枚あたりの上限を決められます。 器の中が見える最小の大きさにそろえます。

AIに処理させる

させるのは2つの段階です。 1つ目は写り具合の確認と食札の番号の読み取り、2つ目は基準の写真との比較です。1つ目で止まったものは、2つ目に進めません。 ぶれた写真で比較をさせると、それらしい割が返ってきてしまいます。

1つ目の段階

2つ目の段階

確かさは3段階で付けさせます。 器の中がはっきり見えて基準との差が分かるものは high、見えるが量の見積もりに幅があるものは medium、器の一部しか見えないものや重ねられているものは low です。low の品が1つでもあれば、その利用者の行に印を付けます。

4行目がいちばん起きやすい失敗です。 汁椀に蓋が閉じていると、AIは「汁物は飲み干した」か「手つかず」かのどちらかを答えがちです。どちらも根拠がありません。 not_visible にさせ、職員が一覧で埋めます。

水分の量は、上から撮った写真では見込めません。 この構成では、今までどおり職員が書きます。

指示内容を固定する

あなたは介護施設で、下膳の前のお膳の写真から食事の摂取量の下書きを作る立場です。
1枚目は食べる前の基準のお膳、2枚目は利用者が食べた後のお膳です。
2枚の写真に写っているものだけを見て判断してください。推測で埋めないでください。

【この食事の献立】
主食：{staple}（{staple_type}）
主菜：{main_dish}
副菜：{side_dishes}
汁物：{soup}
食形態：{texture}

【見込み方】
- 品ごとに、基準のお膳と比べて「食べた割合」を0〜10の整数（割）で答えてください。
  10は残りが無い、0は手をつけていない、5は半分程度です。
- 器の中が見えない品は、ratio を null にし、status を not_visible にしてください。
  蓋が閉じた汁椀、重ねられた器、手やタオルで隠れた器が当たります。
- 見えない品を「いつもどおり」や「完食」で埋めないでください。
- 品が別の器に移されている、お膳の外にこぼれている、と見える場合は、
  notes にそのまま書いてください。こぼれた分を食べた量に数えないでください。
- 量の見込みに幅がある場合は confidence を medium、器の一部しか見えない場合は low にしてください。
- evidence には、判断の根拠にした見た目を短く書いてください（例：「茶碗の底に三分の一ほど残る」）。

【書かないこと】
- 食べた理由、体調、好みの推測は書かないでください。
- 食事量が落ちているかどうかの判断は書かないでください。
- 飲み物の量は見込まないでください。
- 写真に人の顔や名前が写っていても、それを出力に書かないでください。

【食札】
写真の食札に印字された番号を tray_id に入れてください。
読めない場合は tray_id を空にし、tray_status を unreadable にしてください。
番号を推測で補わないでください。

「見えない品を埋めない」を独立させて書いているのは、何も言わないと埋めるからです。 写真に器が写っていて中が見えないと、AIは周りの器の残り具合から「同じくらい」と答えがちです。埋めた値が正しいかどうかではなく、見えなかったという事実が消えることが問題です。

「こぼれた分を数えない」も同じです。 こぼれて空になった器を10割とすると、実際より多く食べたことになります。

出力形式を固定する

次の形のJSONで受け取ります。 Gemini API の構造化出力では、response_format に mime_type: "application/json" と JSON Schema を渡します。ratio は minimum: 0・maximum: 10 の整数、status と confidence は enum で選択肢を決めます。公式の案内では、出力はJSONとして正しくても、値はアプリケーションの側で必ず検証するようにとされているので、スクリプトで確かめます。

{
  "tray_id": "",
  "tray_status": "ok | unreadable",
  "photo_quality": "good | retake",
  "dish_count_match": true,
  "items": [
    { "dish": "staple | main | side | soup",
      "status": "ok | not_visible",
      "ratio": 0,
      "confidence": "high | medium | low",
      "evidence": "" }
  ],
  "notes": ""
}

1つ目の理由は、見込みと確定を別の列に持てることです。 一覧には ratio をAIの見込みとして書き、隣に職員が確定させる列を置きます。職員が直したかどうかが、列を比べるだけで分かります。 直した割合が多い品は、指示か写真の撮り方を見直す材料になります。

2つ目は、スクリプトで検証できることです。

3つ目は、職員の確認の順番を決められることです。 photo_quality が retake、tray_status が unreadable、confidence が low の品があるもの、dish_count_match が false のものを一覧の上に並べます。それ以外は、写真と割を並べて流し見るだけにします。

システムへ連携する

低下の判定は、確定した記録だけで行います。 見込みの段階の値で判定すると、AIの見込みの揺れがそのまま知らせになります。職員が確定させた行がそろってから、規則を当てます。

規則の値は、看護職員と管理栄養士が決めます。 ここに書いた値は例です。知らせのメールには、確定した割の並びとお膳の写真へのリンクを付け、「低栄養のおそれ」のような判断の言葉は入れません。 判断するのは受け取った人です。

メールの送信には1日の上限があります。 Google Workspace のアカウントで1日あたり1,500名の受信者まで、とされています。利用者ごとに1通ずつ送らず、1日1回、拾った利用者をまとめて1通にします。

人が確認する

フロアの職員は、食事ごとに1回、その食事の一覧を開きます。 開く時間は、下膳と口腔ケアが終わった後です。記録が確定するまでは、介護記録のシステムに入りません。

1. 一覧の上から見る … 撮り直し、番号の確認、確かさが low の品、器の数が合わないものが先に並びます。写真を開き、割を直すか、撮り漏れを撮り直します
2. not_visible の品を埋める … 蓋が閉じていた汁物や、重ねられた器です。下膳のときに見た記憶で埋めるか、「不明」のままにします
3. 残りを流し見る … 写真と割を並べた行を見て、明らかに違うものだけ直します
4. 確定する … フロアの一覧の確定のボタンを押すと、確定の列に値が写ります

2番目で「不明」を残せるようにしておくのが大事です。 記憶があいまいなまま割を書くと、元の紙の記録と同じ問題に戻ります。「不明」が多い品は、撮り方か食器の置き方を見直す材料にします。

看護職員と管理栄養士は、知らせを受けた利用者だけを見て、必要なら食事の様子を直接確かめます。

例外に対処する

代替食と個別の対応食は、最初から比較の対象から外します。 嚥下の状態に合わせた個別の盛り付けは、基準の写真と器も量も違います。比べると、見当違いの割が返ります。 利用者の一覧で「個別」の印を付けた利用者は、写真は残しますが割は職員が入れます。

下膳を手伝ってくれる利用者のお膳は、器を重ねる前に先に撮ります。

記録を残す

• お膳の写真と基準の写真の元のファイル（Google ドライブ。保存の期間は施設の記録の決まりに合わせる）
• Gemini API に渡した指示の全文と、返ってきたJSONの全文
• AIの見込みの割と、職員が確定させた割（別の列で残す）
• 誰がいつ確定させたか、どの品を直したか
• 低下の知らせを、いつ、誰に、どの規則で送ったか
• 品ごとの「直した割合」と「不明」の数の推移

見込みと確定を別の列で残すのは、AIの精度を後から測るためです。 職員が直した割合が品ごとにどれくらいかを見れば、汁物はAIに任せられない、主食はほとんど直さない、といった傾向が分かります。 直す割合が高い品は、撮り方か指示を直すか、見込みの対象から外します。写真をいつまで残すかは、総務が施設の規程に合わせて決めます。