介護職員が手書きするバイタルと食事・排泄のチェック表を読み取り、介護記録へ転記して、基準を外れた値を看護職員に知らせる

処理の起点を決める

SharePoint の受付用フォルダにファイルが作成されたことを起点にします。 Power Automate の SharePoint コネクタのトリガー「ファイルの作成時 (プロパティのみ)」を使います。このトリガーはライブラリの列に格納されたプロパティだけを返すので、続けて「ファイル コンテンツの取得」の手順を置き、返ってきたファイル識別子で中身を取ります。

「フォルダーにファイルが作成されたとき」のトリガーは使いません。 コネクタの説明で非推奨とされており、サブフォルダーに追加されたファイルでは起動しないとされています。ユニットごとにフォルダを分けたくなりますが、受付用は1つのライブラリにまとめ、ユニットはファイル名か列で区別します。

スキャンは1日2回です。 1回目は朝のバイタルと昼食の記入が終わった時点、2回目は勤務の終わりです。2回目は1回目の結果を上書きする扱いにし、 値が変わった欄は書き直しとして確認画面に出します。

処理が終わったファイルは、確認用のリストへの書き込みまで成功したときだけ処理済みフォルダへ移します。受付用フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、3つ目と4つ目です。 表の行と利用者の対応が決まっていなければ、読み取れた値を誰のものにするかが決まりません。チェック表は、介護記録ソフトの利用者一覧から毎日印刷し、そのとき行の並びを一覧として残します。 手で利用者名を書き込む表にすると、名前の読み違いがそのまま記録の取り違えになります。

基準の一覧は、 「Aさんは平熱が35.6℃なので37.0℃以上で知らせる」といった看護職員の取り決めを、利用者ごとの行に書き出したものです。

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

チェックボックスの欄は、選択マークとして読みます。 排便の有無を「○」で書かせると文字として読まれ、丸の大きさや線のかすれで迷います。表の側で四角い枠にしておけば、レイアウトモデルが選択マークとして selected ／ unselected と信頼度を返します。

SharePoint のコネクタには接続ごとに60秒あたり600回の呼び出しの制限があります。過去の表をまとめて読み込むときは、数を区切って流します。

AIへ渡す前に整形する

1. ページの確認 … 1ファイル1枚であることを確かめます。複数枚をまとめてスキャンしたものは、ページで分けて1枚ずつ流します
2. 形式と寸法の確認 … PDFまたは画像であること、50×50から10,000×10,000ピクセルの間であることを確かめます
3. 解像度の確認 … 抽出するテキストの最小の高さは、1024×768の画像で12ピクセルです。150dpiで約8ポイントの文字に当たります。小さい欄に書かれた数字はこの下限に近いので、スキャンは300dpiに固定します
4. 向きの確認 … 応答の angle で回転を確かめ、大きく傾いたものは確認画面に回します
5. ユニットと日付の確認 … ファイル名と表の見出しが一致するかを見ます。食い違えば止めます（前日の表の取り違えが典型）
6. 2回目のスキャンかどうかの確認 … 同じユニット・同じ日付の結果がすでにあれば、上書きの扱いにします
7. 表の並びの取り出し … その日・そのユニットの利用者の並びを SharePoint から引きます

3番目を軽く見ないでください。 体温の小数点は表の中でいちばん小さい書き込みで、読めずに「368」と返ると確認画面に出る欄が増えます。

AIに処理させる

させるのは、表のセルを「利用者 × 項目 × 時間帯」の値にそろえ、欄ごとに状態を付けることだけです。 OCRが返すのはセルの位置と文字で、それが「Cさんの夕の上の血圧」であることは知りません。セルの位置と見出しの文字から、その対応を決めるのがAIの役目です。

分ける材料は、OCRが返した信頼度と、セルに文字があるかどうかです。

4行目がいちばん起きやすい失敗です。 生成AIは前後の値を見て読みを寄せますが、見つけたいのは、まさにその「いつもと違う値」です。

指示内容を固定する

あなたは介護施設で、手書きのチェック表の読み取り結果を記録用のデータにそろえる担当です。
OCRが返した表のセルと信頼度だけを見て、値を写してください。推測で埋めないでください。

【表の並び】
{row_map}   ← 行の番号と利用者ID・氏名の対応。氏名で行を探さず、この対応を使う
【表の見出し】
{header_map} ← 列の番号と項目・時間帯の対応（例: 列3＝朝の体温）

【status の選び方】
- filled ......... 値が読み取れている
- blank .......... セルに文字が無い
- not_measured ... 「拒否」「外泊」「入院」「受診」など、測らなかった理由が書かれている
- unreadable ..... 文字はあるが、信頼度が低いか形が崩れていて値として確定できない
迷ったときに filled を選ばないでください。

【厳守事項】
- 値は書かれたとおりに写してください。前後の時間帯や他の利用者の値から、
  ありそうな数字に直さないでください。読めない数字は unreadable です。
- 空欄を埋めないでください。前の日や朝の値で補わないでください。
- 血圧は「上/下」を systolic と diastolic に分けてください。
  どちらか一方でも読めなければ、両方とも unreadable にしてください。
- 体温の読点（36,8）は小数点として写し、note に「読点を小数点とした」と書いてください。
- 摂取量は、10割に置ける書き方（10、8、半分、全量）だけを数値にし、
  それ以外（「少し」「ほぼ」など）は数値にせず note に書いたまま残してください。
- 値が高い・低い、熱がある、脱水の疑いなど、状態の評価を書かないでください。
- 基準を外れているかどうかを書かないでください。
- 行と利用者の対応は【表の並び】だけで決めてください。表の中の氏名の読みで決めないでください。
- evidence には、根拠にしたセルの行・列の番号と、OCRが返した文字をそのまま入れてください。
- confidence は OCR が返した値をそのまま入れてください。

【読み取り結果】{layout_result}

「推測しない」を値の写し方と空欄の2か所に書くのは、 片方だけだと読みにくい数字は寄せる、という動き方をするためです。

「氏名の読みで行を決めない」は取り違えを防ぐためで、行の対応は印刷したときの一覧という機械的な根拠に置きます。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力で、このスキーマに従わせます。構造化出力は、指定した JSON スキーマに従った応答を返す仕組みで、有効なJSONを返すだけだった JSON モードとは違い、スキーマに厳密に準拠させられます。

{
  "sheet": { "unit": "", "date": "", "scan_round": 1 },
  "residents": [
    {
      "row": 1,
      "resident_id": "",
      "entries": [
        { "item": "temp_morning", "status": "filled | blank | not_measured | unreadable",
          "value": "", "reason": "", "note": "", "confidence": 0, "evidence": "" }
      ]
    }
  ]
}

item は、temp_morning ／ bp_morning_systolic ／ bp_morning_diastolic ／ pulse_morning と夕の同じ項目、meal_main_breakfast ／ meal_side_breakfast と昼・夕の同じ項目、fluid_ml ／ urine_count ／ stool_present ／ stool_type です。

スキーマの書き方には決まりがあります。 すべてのフィールドを必須にし、省略可能な値は null との共用体型で表します。オブジェクトには常に additionalProperties: false を設定します。オブジェクトのプロパティは最大100個、入れ子は5レベルまでとされているので、項目ごとに列を立てず、entries の配列に並べる形にしています。 10名 × 20前後の項目を1つのオブジェクトに並べると、上限に届きます。

JSONにする理由は、status と基準の照合を別の層に置けることです。 entries はAIが埋め、基準を外れたかどうかはワークフローが規則で決めます。基準が変わっても、直すのは基準の一覧だけです。 evidence があれば、確認画面では画像の該当箇所だけを見れば済みます。

基準の照合は、次の規則で行います。

数値は施設の看護職員と配置医が利用者ごとに決めるもので、この表は条件の形の例です。 共通の行が大事で、読めなかった値を照合に使わないことで、誤った値で知らせることも、知らせるべき値を流すことも防ぎます。

システムへ連携する

介護記録ソフトへの取り込みは、製品ごとに方法が違います。 項目の並びと取り込みの手順は利用中の製品で確かめる必要があり、この部分は個別の確認が要ります。 取り込みの経路が無い製品では、確認画面を記録ソフトの画面と同じ並びにして、人が見ながら入力する形にとどめます。

取り込むのは、確認画面で確定した値だけです。 読み取りの直後に書き込むと、読み違いがそのまま公式の記録になります。一方、Teams への知らせは確定を待ちません。 基準を外れた filled の値は読み取りの直後に「未確定」と書いて知らせ、画像の該当箇所へのリンクを添えます。

人が確認する

ユニットの職員が見るのは、unreadable と blank の欄だけです。 filled の欄は一覧で流し見て終わりにします。全部の欄を見直す設計にすると、打ち込みの時間が見直しの時間に置き換わるだけです。

1. unreadable を確定する … 画像の該当箇所を見て、正しい値を入れるか、本当に読めなければ書いた職員に聞きます
2. blank を確定する … 測り忘れなら「未測定」として確定し、まだ間に合う時間なら測り直します
3. 書き直しの欄を見る … 1回目と2回目で値が変わった欄を確かめます
4. 確定して取り込む … 確認画面で確定ボタンを押すと、介護記録ソフトへの取り込みに回ります

看護職員が見るのは、Teams の知らせです。 利用者のもとへ行くかどうかは看護職員が決め、対応したかを返信で残すと次の勤務へ引き継げます。 昼の時点で空欄が分かれば、その日のうちに測り直せるのも2回スキャンの効果です。

目標は、1枚あたり4分です。 表1枚の約200欄のうち、unreadable と blank が十数欄という想定です。それより多い日は、スキャンの解像度か、表の書式を見直すべきです。

例外に対処する

上から3行目が、この構成でいちばん重い例外です。 行と利用者の対応が取れないまま値を書き込むと、別の利用者の記録に体温が入ります。 対応が取れないときは、値を読み取れていても止めます。

記録を残す

• スキャンした画像と、受け取った日時、ユニット、日付、何回目のスキャンか
• OCRが返したJSONの全文（セル、単語の信頼度、手書きかどうか、選択マーク）
• 生成AIが返した entries の全文と、そのとき使った表の並びの一覧
• 確認画面で人が直した記録 … どの欄を、何から何に変えたか、誰が確定したか
• 基準の照合の結果と、そのとき使った基準の一覧の内容
• Teams に知らせた日時、看護職員の返信
• 介護記録ソフトへ取り込んだ日時と件数

5つ目で「そのときの基準」を残すのは、基準が後から変わるためです。 利用者の状態が変わって基準を直すと、過去の知らせが妥当だったかを後から確かめられなくなります。

4つ目は改善の材料です。 特定の欄がいつも直されているなら、書式を変えるほうが指示を直すより効きます。