病院の環境ラウンドで撮った病棟・処置室の写真から、物品の床置きや手指衛生剤の欠品などの不備を拾い、部署への指摘の下書きにする

処理の起点を決める

フォームの送信を起点にします。 ICTの担当者は、部署を回りながら場所ごとに写真を送ります。1回の送信が「1部署の1つの場所」の写真のまとまりで、病室、ナースステーション、汚物処理室のように場所を分けて送ります。

Google Apps Script のインストール型のトリガーで、フォームの送信のたびに処理を動かします。インストール型のトリガーは、作った人のアカウントで動きます。 送ったのが誰であっても、処理はトリガーを作ったアカウントの権限で動くので、作るのは個人ではなく、ICTの共用のアカウントにします。 担当者が異動すると、トリガーが止まります。

部署ごとの指摘票は、ラウンドの日の夕方にまとめて作ります。 場所ごとの確認は送信のたびに動かし、指摘票の下書きは時間主導のトリガーで毎日17時に、その日に確認が済んだ部署について作ります。撮り直しの返事は送信のたびに返すので、ラウンドの途中で撮り直せます。

入力データを集める

質を決めるのは、チェック表の「写真で確かめられるか」の列です。 手指衛生剤が設置されているか、物品が床に置かれているかは写真で見えます。一方、手指衛生剤の使用期限、消毒薬の希釈の濃度、床の清掃の頻度は写真では分かりません。 この列が「不可」の項目は、AIに渡さず、ラウンドの場で印を付けたものをそのまま使います。

チェック表の項目は、院内の感染対策マニュアルから取ります。 手指衛生剤の設置の場所、清潔と不潔の置き分け、廃棄物の容器の扱いは、病院ごとに決め方が違います。AIに一般論で見させず、自院のマニュアルの言葉で項目を書きます。

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

フォームの送信のイベントから、回答の部署・場所と、アップロードされたファイルのIDを取ります。ファイルは Google ドライブから読み、撮影の日時はフォームの送信の日時で代えます。 写真の撮影情報（Exif）は、端末によって残ったり消えたりするので頼りません。

チェック表は、撮影の場所で絞ってから渡します。 全項目を渡すと、病室の写真に汚物処理室の項目まで当てはめ、「写真で確かめられない」項目が増えます。場所で絞ると、1回に渡す項目は10前後になります。

写真は、リクエストに直接入れて渡します。 1つの場所の写真は数枚で、縮めれば指示と合わせて20MBに収まります。同じ写真を写り込みの確認と項目ごとの確認の2回に使うので、枚数の多い場所では Files API で一度上げて使い回す方法もあります。どちらにするかは、写真の大きさが決まってから選びます。

API キーは、Apps Script のスクリプトのプロパティに置きます。 コードに直接書くと、スクリプトを共有したときにキーも共有されます。

前回の指摘は、AIには渡しません。 続いているかの判定は、今回の結果と前回の指摘を項目番号で突き合わせる、Apps Script の規則で行います。AIに前回の指摘を見せると、前回と同じ不備を探しにいき、今回の写真に無いものを「続いている」と書くことがあります。

AIへ渡す前に整形する

1. 形式の確認 … PNG、JPEG、WEBP、HEIC、HEIF のいずれかであることを確かめます
2. 大きさの確認 … 指示と合わせて20MBに収まるよう、長い辺を決めた画素数に縮めます
3. 枚数の確認 … 1つの場所で多すぎる写真は、担当者に分けて送ってもらいます
4. 写り込みの確認 … 人物・患者の情報が写っていないかを、Gemini API に先に確かめさせます
5. 場所とチェック表の照合 … 送られた場所に対応するチェック表の行が無ければ、確認に進めず担当者に返します

4番目を、項目ごとの確認と分けて先に行います。 1回の呼び出しで両方をさせると、写り込みがあっても項目の確認の結果が返り、写り込んだ写真の結果が確認の一覧に残ります。 写り込みの確認を通った写真だけを、次の呼び出しに渡します。

写り込みの確認で見るのは、人物の顔と姿、ベッドネームや名札の文字、電子カルテや検査の画面、点滴や薬袋のラベルです。どれか1つでもあれば blocked とし、写真はドライブの保留のフォルダに移して、担当者に撮り直しを返します。 保留の写真は、担当者が撮り直しを済ませた後に削除します。

AIに処理させる

させるのは、チェック表の項目ごとに、写真で確かめられたかと、不備の候補があるかを返すことです。

右端の列がいちばん大事です。 not_visible は、写真にその場所が写っていないということで、不備ではありません。 手指衛生剤の設置台が写っていない写真から「欠品」と返すと、置いてある部署に指摘が届きます。

位置の枠は、不備の候補にだけ付けさせます。 枠を付けるのは、床置きの箱、混在している物品、ふたの開いた容器などです。担当者は写真に重ねた枠を見て、本当にそれが不備かを一目で確かめます。

2行目が、いちばん起きやすい失敗です。 「手指衛生剤の設置」の項目を渡すと、AIは写真の中にボトルを探し、見つからなければ「設置なし」と書きがちです。 写真の画角の外は、AIにも人にも分かりません。

指示内容を固定する

あなたは病院の感染制御チームで、環境ラウンドの写真を点検する担当です。
渡された写真と、この場所のチェック表の項目だけを見て判定してください。
写真に写っていないことを推測しないでください。

【写真】{images}（部署：{dept}、場所：{location}）
【チェック表の項目】{checklist}（項目番号、見る内容）

【項目ごとの status の選び方】
- ok ............. 確かめるべき場所が写っており、不備は見当たらない
- issue .......... 確かめるべき場所が写っており、不備の候補がある
- not_visible .... 確かめるべき場所が写っていない、または小さすぎて見えない
- uncertain ...... 写ってはいるが、不備かどうかを写真から決められない
写っていないときに issue を選ばないでください。迷ったら uncertain です。

【厳守事項】
- issue の項目には、不備の候補の位置を box_2d に入れる。
  形式は [ymin, xmin, ymax, xmax] で、0〜1000 に正規化した座標。
- evidence には、写真のどこに何が写っているかを短く書く。
- 物品が何かを特定できないときは「物品」と書き、名前を推測しない。
- 汚れの程度、清掃の状態を評価しない。
- 人の行動や態度を評価しない。
- 感染のリスクの高さや、改善の方法を書かない。
- チェック表に無い気づきは other_notes に1〜2件まで書いてよい。
  ただし不備と断定しない。

「写っていないときに issue を選ばない」を明記しないと、欠品の指摘が増えます。 「手指衛生剤」「廃棄物の容器」のように、あるべき物が決まっている項目ほど、写っていないことを「無い」と読みます。

写り込みの確認は、別の短い指示で先に行います。 「この写真に、人物の顔や姿、名札やベッドネームの文字、画面に表示された情報、薬袋や点滴のラベルが写っているか。写っていれば blocked、無ければ clear。迷ったら blocked」と指示し、迷ったら止める側に倒します。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "round_id": "",
  "dept": "",
  "location": "",
  "privacy": "clear",
  "items": [
    { "item_no": "", "status": "ok | issue | not_visible | uncertain",
      "image_index": 0, "box_2d": [0, 0, 0, 0], "evidence": "" }
  ],
  "other_notes": [""]
}

スキーマでは status を enum にし、items の各要素の additionalProperties を false にします。

写り込みの確認は、別の小さなJSONで受け取ります。 privacy は clear か blocked、reasons は person（人物）／screen（画面）／label（薬袋・点滴のラベル）／name_tag（名札・ベッドネーム）から選ばせ、写っていた写真の番号を添えさせます。 撮り直しの依頼には、この reasons を日本語にして添えます。項目ごとの確認のJSONに privacy の欄を残しているのは、clear を通った写真だけが確認に進んだことを、記録の上でも示すためです。

1つ目の理由は、not_visible を不備と分けて数えられることです。 1つの場所で not_visible が多ければ、撮り方が足りていません。撮り方のほうを直す材料になります。

2つ目は、続いている不備を規則で決められることです。 Apps Script は、今回の issue と前回の指摘を項目番号で突き合わせます。

4行目が要です。 前回指摘した場所が今回写っていなければ、改善したかは分かりません。「改善を確認」と書かず、次回のラウンドで撮る場所として印を付けます。

3つ目は、box_2d で確認が速くなることです。 担当者は指摘票の下書きで、写真に枠を重ねた画像を見ます。枠の中を見て、採るか外すかを選ぶだけです。

システムへ連携する

部署の責任者への送付は、人が行います。 下書きはスプレッドシートの部署ごとのシートに作り、ICTの医師が確認してから送ります。 送った指摘は確認の一覧に「指摘」として残り、次回の前回の指摘になります。

撮り直しの依頼は、撮った担当者だけに返します。 写り込みの理由（人物／画面／ラベル）を添え、写真そのものは添付しません。

人が確認する

下書きは全件をICTの看護師が確かめます。 部署に届く指摘で、部署との関係に響くためです。

1. 続いている不備を先に見る … 前回も指摘した項目です。枠を見て、本当に同じ不備かを確かめます
2. 新しい不備の候補を採るか決める … 枠を見て、採るか外すかを選びます。ラウンドの場で事情を聞いていれば（搬入の直後で一時的に床に置いていた、など）、その事情を踏まえます
3. uncertain を決める … ラウンドの記憶と、必要なら元の写真で決めます
4. not_visible が多い場所を次回の撮影に回す … 撮り方の指示を担当者で共有します
5. ICTの医師が読み、送る

目標は、1件をならして12分です。 候補の無い部署は枠付きの写真を流し見て終わり、時間は続いている不備と uncertain に使います。それを大きく超える月は、写り込みの撮り直しが増えているか、チェック表の項目が写真向きでないかのどちらかです。

2番目で外した理由を残します。 「一時的な置き方」「写真の誤認」「チェック表の対象外」のどれかを選ばせると、誤認が多い項目は指示を直し、対象外が多い項目はチェック表を直します。

例外に対処する

1行目は、件数が少なくても止めます。 写り込みの確認で迷った写真は blocked に倒しているので、撮り直しが多い時期は、撮り方の説明をやり直します。

記録を残す

• ラウンドの写真（写り込みの確認を通ったものだけ。保留の写真は撮り直しの後に削除）
• 写り込みの確認の結果と、blocked の理由
• 項目ごとの確認のJSONの全文と、呼び出した日時
• 指摘票の下書きと、ICTが直した後の指摘票
• 担当者が候補を外した記録と理由
• 場所ごとの not_visible の発生率

最後の行は、撮り方を直す材料です。 汚物処理室の not_visible が多ければ、部屋が狭くて全体が1枚に入らないのかもしれません。撮る位置を決めて共有すると、確認の質が上がります。