訪問介護のヘルパーが手書きするサービス提供記録を読み取り、提供時間・内容を予定と突き合わせて、実績の食い違いと記入漏れを拾う
ヘルパーが手書きしたサービス提供記録を読み取り、訪問日・時刻・サービス内容を実績の形にそろえます。訪問予定と突き合わせ、時刻のずれ、予定にない訪問、記入漏れ、確認欄の空欄を週のうちに拾います。
- 生成AI
- ChatGPT/Claude
- AIサービス
- Azure AI/Google Document AI
- 連携・自動化
- Google Apps Script/Python
- 対象業界
- 介護
- 対象部門
- 総務
- 対象業務
- データ入力・転記/内容確認・チェック
- 主な課題
- 入力作業が多い/期限・対応漏れが起きる/確認ミスが多い
- AIで行う処理
- 読み取り(OCR)
- 主な効果
- 入力漏れ削減/対応スピード向上/工数削減
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- ヘルパーが週に1回、記録票の控えを事業所の箱に入れる
- 事務の担当が控えを利用者ごとに分け、日付の順に並べる
- 介護ソフトの予定表を印刷し、記録票と1枚ずつ見比べる(訪問日、担当、開始と終了の時刻、サービスの区分)
- 時刻やサービス内容が予定と違うもの、記入の漏れ、確認欄の空欄に付箋を貼る
- 付箋の付いた記録票をまとめ、ヘルパーに電話かメッセージで確かめる
- 特記事項に気になる記述があれば、サービス提供責任者の机に回す
- 確かめの済んだものから、介護ソフトの予定を実績に直す
- 人事務の担当が、提出された記録票の控えを複合機でスキャンし、Google ドライブの「受付」フォルダに保存する
- 自動Google Apps Script が15分おきに「受付」フォルダを確かめ、新しいPDFを Google Document AI の Form Parser に送る
- 自動Form Parser が、記録票の欄のキーと値、サービス内容の□の印、特記事項の文字、それぞれの信頼度を返す
- 自動Claude API が、読み取り結果を1訪問1件の実績の形(訪問日・時刻・担当・サービス内容・特記事項)にそろえ、特記事項に印を付ける
- 自動Apps Script が、介護ソフトから出した予定のシートと突き合わせ、時刻のずれ・予定にない訪問・担当の違い・記入漏れを規則で拾う
- 自動「確認待ち」のシートに1件1行で書き込み、印の付いた行に記録票の写しのリンクを付ける
- 人事務の担当が印の付いた行を記録票の写しと見比べ、ヘルパーに確かめる
- 人サービス提供責任者が、特記事項の印の付いた行を読み、必要な連絡をする
- 人確かめの済んだものから、事務の担当が介護ソフトの予定を実績に直す
各工程の詳しい説明を読む
- ヘルパーが週に1回、記録票の控えを事業所の箱に入れる
- 事務の担当が控えを利用者ごとに分け、日付の順に並べる
- 介護ソフトの予定表を印刷し、記録票と1枚ずつ見比べる(訪問日、担当、開始と終了の時刻、サービスの区分)
- 時刻やサービス内容が予定と違うもの、記入の漏れ、確認欄の空欄に付箋を貼る
- 付箋の付いた記録票をまとめ、ヘルパーに電話かメッセージで確かめる
- 特記事項に気になる記述があれば、サービス提供責任者の机に回す
- 確かめの済んだものから、介護ソフトの予定を実績に直す
(a)見比べが1枚ずつ。 1,800枚の記録票を、予定表の行と1枚ずつ合わせます。ほとんどの記録票は予定どおりで、合っていることを確かめるために時間の大半が使われています。 合っている記録票と違う記録票が、見た目では区別できないからです。
(b)記入漏れに気づくのが月末になる。 控えが週に1回しか届かないうえ、見比べが追いつかないと、付箋の付いた記録票が月末にまとめて見つかります。 締めの直前に35名のヘルパーへ問い合わせが集中し、3週間前の訪問の終了時刻をヘルパーが思い出せないことも起きます。
(c)予定にない訪問を見落とす。 体調の変化で訪問を延ばしたり振り替えたりすることがあります。予定表の側から見比べると、予定に無い訪問の記録票は、合わせる行が無いまま束の最後に残ります。
(d)特記事項が埋もれる。 6番目は、見比べのついでに気づいた記述だけが回ります。「足をかばっていた」の一文は、時刻のずれを探している目には入りにくいのです。回ってくるのが遅れると、ケアマネジャーへの連絡も遅れます。
- 【人】 事務の担当が、提出された記録票の控えを複合機でスキャンし、Google ドライブの「受付」フォルダに保存する
- 【自動】 Google Apps Script が15分おきに「受付」フォルダを確かめ、新しいPDFを Google Document AI の Form Parser に送る
- 【自動】 Form Parser が、記録票の欄のキーと値、サービス内容の□の印、特記事項の文字、それぞれの信頼度を返す
- 【自動】 Claude API が、読み取り結果を1訪問1件の実績の形(訪問日・時刻・担当・サービス内容・特記事項)にそろえ、特記事項に印を付ける
- 【自動】 Apps Script が、介護ソフトから出した予定のシートと突き合わせ、時刻のずれ・予定にない訪問・担当の違い・記入漏れを規則で拾う
- 【自動】 「確認待ち」のシートに1件1行で書き込み、印の付いた行に記録票の写しのリンクを付ける
- 【人】 事務の担当が印の付いた行を記録票の写しと見比べ、ヘルパーに確かめる
- 【人】 サービス提供責任者が、特記事項の印の付いた行を読み、必要な連絡をする
- 【人】 確かめの済んだものから、事務の担当が介護ソフトの予定を実績に直す
7番目が、この設計の分かれ目です。 事務の担当が見るのは、印の付いた行だけです。印の無い行は、利用者ごとの件数を流し見て確認済みにします。 予定どおりかの見比べは、規則に移します。
介護ソフトへの実績の入力は、これまでどおり人が行います。 この構成は介護ソフトに書き込みません。読み取りの誤りが、そのまま実績として確定する経路は作りません。
02今回想定するシステム構成
サービス提供記録の控え(手書き、複写式) │ 事務の担当が複合機でスキャン ▼【トリガー】Apps Script の時間主導型トリガー(15分おき) Google Apps Script ── 「受付」フォルダの新しいPDFを探す ▼ Google Document AI(Form Parser) │ 欄のキーと値、□の印、特記事項の文字、信頼度 ▼ Google Apps Script ── 利用者名を利用者コードに置き換える ▼ Claude API ── 1訪問1件の実績の形にそろえ、特記事項に印を付ける ▼ Google Apps Script ── 訪問予定との突き合わせ(時刻・担当・区分・記入漏れ) ▼ 「確認待ち」シート(印と記録票の写しのリンク) ▼ 【事務の担当が印の付いた行を確かめ、ヘルパーに問い合わせる】 【サービス提供責任者が特記事項の印を読む】 ▼ 介護ソフトの予定を実績に直す(人の操作)
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| OCR | Google Document AI(Form Parser) | Azure AI Document Intelligence |
| 生成AI | Claude API(記録票の欄を実績の形にそろえ、特記事項に印を付ける) | OpenAI API |
| 連携 | Google Apps Script(フォルダの確認、各APIの呼び出し、シートへの書き込み) | Python |
| 差異計算 | Google Apps Script(訪問予定との突き合わせ) | Python |
| 保管 | Google ドライブ(記録票のPDFと読み取り結果) | 社内のファイルサーバー |
新しく足すのは、「確認待ち」のシートと、ヘルパーの呼び名の一覧の2つです。 記録票の担当欄には、フルネーム、名字だけ、ひらがな、と書き方がまちまちです。介護ソフトのヘルパーのコードに引き当てるための呼び名の一覧を、事務の担当が作ります。
土台は Document AI の Form Parser です。 公式のプロセッサ一覧では、OCRのテキストに加えてキーと値のペア、チェックボックス、表、一般的なエンティティを抽出するとされ、言語の一覧で日本語(ja)は手書きに対応する言語として示されています。記録票の「訪問日」「開始」「終了」はキーと値のペアとして、サービス内容の□はチェックボックスとして読めます。
Form Parser の注意書きのうち、この題材で効くのは3つです。 値が空のキーと値のペアは確実には読み取れないこと、チェックボックスのモデルはラジオボタンに対応しないこと、ラテン文字でない言語ではキーと値の読み取りの質が下がることがあることです。記録票の「身体介護/生活援助」が○で囲む形なら、□に印を付ける形に書式を変えるほうが確実です(第7章)。
処理する場所は、リージョンの一覧から選びます。 マルチリージョンの us と eu、シンガポール(asia-southeast1)などがあり、日本のリージョンはありません。 記録票には利用者の名前と心身の状態が書かれているので、国外のリージョンで処理してよいかを、導入前に自社の決まりと利用者との取り決めに照らして確かめます(第13章)。
03どうやって実装するのか
処理の起点を決める
Apps Script の時間主導型トリガーで、15分おきに「受付」フォルダを確かめます。 公式のページでは、時間主導型のトリガーは毎分から月1回までの間隔で設定でき、実行の時刻はわずかにずれることがあるとされています。インストール型トリガーの一覧には、ドライブにファイルが置かれたことを起点にするものは無いので、一定の間隔で新しいファイルを探す形にします。
スキャンは、ヘルパーが控えを提出したその日に行います。 週に1回の提出をためずにスキャンすれば、食い違いの確かめが、訪問から1週間以内に始まります。 ヘルパーが訪問を覚えているうちに問い合わせられるかどうかで、1件の確かめにかかる時間が大きく変わります。
処理が終わったPDFは「処理済み」フォルダへ移します。移すのは、確認待ちのシートに書き込みが終わったときだけにします。途中で止まったPDFは次の実行で拾い直され、「受付」フォルダに残っている数が、そのまま未処理の数になります。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 記録票のPDF | スキャンした画像。スキャンした日時 | 「受付」フォルダ |
| 読み取り結果 | 欄のキーと値、□の印、特記事項の文字、各要素の信頼度と位置 | Google Document AI |
| 訪問予定 | 利用者コード、訪問日、予定の開始・終了時刻、担当ヘルパーのコード、サービスの区分 | 介護ソフトから出した予定のCSV(シートに貼る) |
| 利用者の一覧 | 利用者コード、氏名、よみ | 介護ソフトの利用者の一覧 |
| ヘルパーの呼び名の一覧 | 記録票に書かれうる呼び方と、ヘルパーのコードの対応 | 新しく作る一覧 |
| 突き合わせの決まり | 時刻のずれを印にする分数、必須の欄 | 事業所で決める表 |
質を決めるのは、訪問予定のシートの鮮度です。 予定は、利用者の入院やケアマネジャーからの変更連絡で週に何度も変わります。介護ソフトの予定を変えたのに、シートの予定が古いままだと、正しい記録票がすべて「予定と違う」になります。 予定のCSVは、突き合わせの前日に貼り直す決まりにします。
突き合わせの決まりの表には、何分のずれを印にするかを書きます。 何分からを確かめの対象にするかは、サービス提供責任者と事業所の管理者が決めます。この構成は、決めた分数で機械的に印を付けるだけです。
データの取得方法を決める
Apps Script は、「受付」フォルダの getFiles() で新しいPDFを探し、Form Parser のプロセッサに送ります。オンラインの処理は1回の要求で最大15ページなので、20枚、30枚とまとめてスキャンしたPDFは、15ページ以内に分けて送るか、上限が100ページのバッチ処理に回します。
| 取るもの | どこから | 何に使うか |
|---|---|---|
| 欄の値 | 各ページの formFields(fieldName/fieldValue) | 訪問日、利用者名、担当、開始と終了の時刻 |
| サービス内容の印 | fieldValue の valueType(filled_checkbox/unfilled_checkbox) | 身体介護・生活援助の内容 |
| 全文 | 応答の text | 特記事項の自由記述と、欄として取れなかった値 |
| 信頼度 | 各要素の layout の confidence | 読めた値と、読めなかった値の区別 |
| 位置 | layout の boundingPoly | 確認のときに、写しの該当箇所を示す |
1ページ1訪問として扱います。 記録票は1枚1訪問の書式なので、ページの番号で訪問を分けます。裏面に続きを書いた記録票は、裏面も同じ訪問としてまとめます(前処理の4番目)。
空欄と読めない欄は、信頼度と全文で分けます。 「終了」の項目名があって値が取れないとき、全文の中で項目名の近くに時刻らしい文字が検出されているかを見ます。何も無ければ空欄、検出されていて信頼度が低ければ読めない欄です。
AIへ渡す前に整形する
- 形式の確認 … 公式の対応形式は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。複合機の出力はPDFにそろえます
- 解像度の確認 … 公式のページでは、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよいとされています。複写式の控えは元の紙より文字が薄いので、300dpiで取ります
- ページの分割 … 15ページを超えるPDFは、オンラインの処理に送る前に分けます
- 裏面の確認 … 裏面に特記事項の続きが書かれたページは、表のページと同じ訪問にまとめます。白紙の裏面は外します
- 利用者名の置き換え … 読み取った利用者名を利用者の一覧で引き、Claude API に渡す前に利用者コードに置き換えます
- 重複の確認 … 同じ利用者・同じ訪問日・同じ開始時刻の記録票が2枚あれば、二重のスキャンか書き直しかを担当に確かめる印を付けます
2番目が、この構成の精度をいちばん左右します。 複写式の控えは、ボールペンの筆圧で写った文字で、元の紙より線が細く、かすれます。 解像度が足りないと、「3」と「8」、「1」と「7」の見分けがつかず、時刻が読めない欄が増えます。
5番目は、生成AIに渡す情報を減らすためのものです。 実績の形にそろえるのに、利用者の名前は要りません。引き当てられなかった名前は置き換えずに user_unknown の印を付け、Claude API には名前の欄を空にして渡します。
AIに処理させる
させるのは、読み取り結果を実績の項目に書かれたとおりに写すことと、特記事項の記述に印を付けることです。 予定との突き合わせは、Apps Script の規則で行います。
| させること | 中身 | 判断できないときの扱い |
|---|---|---|
| 見出しの写し | 訪問日、担当(書かれたとおり)、開始と終了の時刻 | 読めなければ unreadable、空欄なら blank |
| サービス内容の写し | 印の付いた□の項目と、区分(身体介護・生活援助) | 印が読み取れなければ unclear |
| 時刻の書き方の印 | 「2:00」のように午前か午後かが分からない書き方 | ampm_unclear を付け、書かれたとおり写す |
| 確認欄の有無 | 利用者・家族の確認欄に、署名か印があるか | 判断できなければ unclear |
| 特記事項の写し | 自由記述の全文 | 読めない文字は〓で残す |
| 特記事項の印 | 体調の変化/事故・ヒヤリ/苦情・要望/その他 | 迷えば印を付ける側に倒す |
6行目が、AIを使う大きな理由です。 「食べる量が少ない」「いつもより口数が少ない」は、決まった言葉を探す規則では拾いにくい書き方です。迷ったら印を付ける側に倒すのは、見逃した記述は誰にも読まれず、印を付けすぎた記述はサービス提供責任者が数秒で外せるためです。
| させないこと | 理由 |
|---|---|
| 時刻を予定に合わせて読む | 書き間違いと、実際に早く終えた訪問の区別が消える |
| 午前・午後を補う | 予定を見て補うのは Apps Script の規則。補ったことを印で残す |
| 担当の名前を似たヘルパーに寄せる | 呼び名の一覧で引く。引けなければ人が決める |
| 特記事項を要約する・言い換える | サービス提供責任者は原文で読む |
| サービスが適切だったかの判断 | 計画との関係はサービス提供責任者が見る |
1行目がいちばん大事です。 つぶれた「10:50」を予定の「11:00」に寄せて読むと、記録票と予定は一致し、ヘルパーが早く引き上げた日があったという事実は誰の目にも触れなくなります。
指示内容を固定する
あなたは訪問介護事業所の事務の担当で、ヘルパーが手書きした
サービス提供記録の読み取り結果を、実績の項目に写す立場です。
OCRが返した結果だけを見て、書かれていることを写してください。
【写す項目】
visit_date(訪問日)、helper_text(担当。書かれたとおり)、
start_time(開始)、end_time(終了)、service_category(身体介護/生活援助)、
service_items(印の付いた内容)、confirmation(確認欄)、note(特記事項)
【厳守事項】
- 時刻は書かれたとおりの文字列で写してください。
読みにくい数字を、ありそうな時刻に直さないでください。
- 「2:00」のように午前か午後か分からない書き方は、そのまま写し、
ampm_unclear を true にしてください。午後と決めないでください。
- 欄が空欄なら status を blank、文字はあるが読めなければ
unreadable にしてください。空欄と読めない欄を混ぜないでください。
- 担当は書かれたとおりに写してください。フルネームに直さないでください。
- □の印が判別できないときは unclear にしてください。
- 確認欄に署名や印が見当たるかだけを書いてください。誰の署名かは書かないでください。
- 特記事項は全文を写してください。要約や言い換えをしないでください。
読めない文字は〓にしてください。
- 特記事項に、体調の変化(health)、転倒・けが・ヒヤリ(incident)、
苦情・要望(request)に当たりそうな記述があれば note_flags に入れ、
その部分を note_evidence に写してください。迷ったら入れてください。
- サービスが適切だったか、計画と合っているかは書かないでください。
- サービス提供記録でない書類と判断した場合は、document_type に種類を書いてください。
【読み取り結果】{ocr_result}
予定をAIに渡していないことが、このプロンプトのいちばんの工夫です。 予定を見せると、読みにくい時刻を予定の時刻に合わせて写します。照らす相手を見せなければ、合わせることもできません。
「午後と決めない」も同じ考え方です。 訪問介護の時刻は「2:00」「4:30」と12時間の書き方で書かれることがよくあります。午後と補うのは Apps Script が予定を見て行い、補ったことを ampm_inferred として残します。 AIが黙って補うと、補ったかどうかが後から分かりません。
出力形式を固定する
次の形のJSONで受け取ります。 Claude API の構造化出力(output_config.format に JSON スキーマを渡す方式)を使い、形を固定します。
{
"document_type": "service_record",
"page": 0,
"user_code": "",
"fields": [
{ "item": "visit_date | helper_text | start_time | end_time | service_category",
"value": "", "status": "read | blank | unreadable | unclear" }
],
"ampm_unclear": false,
"service_items": [""],
"confirmation": "present | absent | unclear",
"note": "",
"note_flags": ["health | incident | request"],
"note_evidence": [""]
}
1つ目の理由は、記録票1枚がそのまま確認待ちのシートの1行になることです。 fields の status を列にすれば、空欄と読めない欄を、シートの上で色を分けて見せられます。
2つ目は、突き合わせを Apps Script の規則で持てることです。
| 条件 | 印 |
|---|---|
| 同じ利用者・訪問日の予定が無い | no_schedule |
| 予定があるのに記録票が届いていない(提出の期日を過ぎた) | missing_record |
| 開始か終了の時刻が、予定から決めた分数以上ずれる | time_diff |
| 担当が予定の担当と違う | helper_diff |
| サービスの区分が予定と違う | category_diff |
訪問日・時刻・担当のどれかが blank、または確認欄が absent | incomplete |
該当の欄が unreadable、unclear、または利用者を引けない | check_image |
note_flags がある | note(サービス提供責任者へ) |
note は他の印と別の列に出します。 事務の担当が見る印と、サービス提供責任者が見る印を分けておくと、体調の変化の記述が、時刻の確かめの順番を待たずに届きます。
公式のページでは、列挙の値の大文字・小文字までは保証されないとされているので、status などは Apps Script で小文字にそろえてから使います。stop_reason が max_tokens のときは出力が途中で切れているので、シートに書かずに呼び直します。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| Google ドライブ | Apps Script の getFiles() | 「受付」フォルダの新しいPDFを探し、処理済みへ移す |
| Google Document AI | REST API の呼び出し | 欄、□の印、特記事項の文字、信頼度を返す |
| Claude API | REST API の呼び出し | 記録票を実績の形に写し、特記事項に印を付ける |
| 訪問予定・利用者の一覧 | スプレッドシートの読み取り | 介護ソフトから出したCSVを貼ったシート |
| 確認待ちのシート | 書き込み | 1訪問1行、印、記録票の写しのリンク |
介護ソフトには、この構成から書き込みません。 予定を実績に直すのは、確かめが済んだ記録票を見た事務の担当です。読み取りの誤りが、そのまま実績や月末の確定に入ることはありません。
ヘルパーへの問い合わせも、この構成からは送りません。 誰に何を確かめるかは、印の付いた行を見た事務の担当が決めます。
人が確認する
事務の担当が見るのは、印の付いた行だけです。 印の無い行は、利用者ごとの件数を流し見て確認済みにします。
noteはサービス提供責任者が先に見る … 原文を記録票の写しで読み、ケアマネジャーや家族への連絡が要るかを決めますmissing_recordとno_scheduleを見る … 提出漏れか、予定にない訪問かをヘルパーに確かめます。予定にない訪問は、理由をサービス提供責任者が聞きますcheck_imageを見る … 写しの該当箇所を開いて読みます。読めないものは推測せず、ヘルパーに確かめますtime_diff・helper_diff・category_diffを見る … 書き間違いか、実際に予定と違ったのかをヘルパーに確かめ、理由を残しますincompleteを見る … 空欄の時刻や確認欄をヘルパーに確かめます
目標は、1,800件をならして1件0.5分です。 印の無い行は流し見で数秒、印の付いた行は写しを開いて確かめるので数分かかります。
例外に対処する
| 起きること | 対応 |
|---|---|
| 複写の文字が薄く、読めない欄が多い | check_image。300dpiでスキャンし直す。直らなければヘルパーに確かめる |
| 午前・午後が分からない時刻 | Apps Script が予定から補い、ampm_inferred を残す。予定と大きく違えば time_diff |
| 利用者名が引き当てられない | check_image。事務の担当が利用者を決める |
| 担当の呼び名が一覧に無い | check_image。担当が決め、呼び名の一覧に足す |
| 1枚に2回分の訪問が書かれている | 1枚1訪問として読めないので、AIが document_type に書き、人へ回す |
| 記録票でない書類が混ざる | document_type を見て、記録票でないページを外す |
| 書き直した記録票が2枚ある | 重複の印を付け、どちらを正とするかを担当が決める。古いほうを自動で消さない |
| OCR・AIが応答しない | PDFを「受付」フォルダに残す。次の実行で拾い直す |
上の2行が大半を占めます。 どちらもAIの問題ではなく、複写式の紙と、時刻の書き方の問題です。読めない欄が多いヘルパーには、筆圧の強いペンを配るか、時刻を24時間で書いてもらうよう相談するほうが、判定を工夫するより効きます。
記録を残す
- 元の記録票のPDFと、スキャンした日時
- OCRが返したJSONの全文と、Claude API の応答の全文
- 突き合わせに使った訪問予定の版(貼った日時)と、突き合わせの決まりの版
- 付いた印と、確かめた結果・ヘルパーの説明・確かめた日時と担当
- サービス提供責任者が
noteを読んだ日時と、取った対応 - ヘルパーごとの
check_imageとincompleteの件数
記録票の原本は、紙で残します。 指定訪問介護の基準では、提供した具体的なサービスの内容等の記録を整備し、完結の日から2年間保存しなければならないとされています。PDFやAIの写しは原本の代わりにせず、保存の期間と方法は、事業所の指定を受けている自治体の条例も確かめて決めます。
最後の行は、ヘルパーとの面談の材料になります。 特定のヘルパーだけ読めない欄や空欄が多いなら、ペンか書き方に理由があります。
04実装レベルの3段階
半自動化で、1件2分が1分程度になります。 書き写しは無くなりますが、予定表との見比べと、特記事項の仕分けは目で行う作業として残ります。 本格構成で0.5分になり、この段階が本記事の想定です。 差が大きいのは、見比べが規則に移り、人が見るのが印の付いた行だけになるためです。 段階を飛ばさないでください。 半自動化のシートを1か月見ると、読めない欄の多い書き方と、呼び名の一覧に無い担当の書き方が分かります。
05工数削減シミュレーション
導入後 1,800件 × 0.5分 ÷ 60 = 15 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 登録ヘルパーが直行直帰で利用者の自宅を回り、複写式の紙のサービス提供記録を手書きしている訪問介護事業所。月に千件を超える記録を、事務の担当とサービス提供責任者が予定表と1枚ずつ見比べてから実績を確定している場合。記入漏れや予定との食い違いに気づくのが月末の締めの直前になり、ヘルパーへの問い合わせが集中している場合。
- ヘルパーがすでにスマートフォンの記録アプリで訪問の開始・終了とサービス内容を入力しており、紙の記録がほとんど無い場合。月の訪問が数百件で、事務の担当が目で見て足りる場合。利用者の心身の状態が書かれた記録を国外のリージョンで処理することを、自社の決まりや利用者との取り決めで認められない場合。なお、記録の内容が適切なサービスの提供に当たるか、計画を見直すかの判断は、この構成では代替できません。
07最小構成で試す方法
- 先月の記録票の控えから30枚を選ぶ(時刻が予定とずれていたもの、特記事項の多いもの、文字の薄いものを必ず入れる)
- その30枚について、当時の付箋と、ヘルパーに確かめた結果を用意する
- 利用者名を黒く塗ってからスキャンし、手元のAIサービスの画面に1枚ずつ貼り付ける
- 「この記録票の訪問日、担当、開始と終了の時刻、印の付いたサービス内容、特記事項を、書かれたとおりに写してください。数字を直さないでください。読めない欄は『読めない』、空欄は『空欄』としてください。特記事項に体調の変化や転倒の記述があれば示してください」と指示する
- 写された値を当時の予定表と比べ、付箋の位置と同じ記録票が拾えるかを見る
| 出てきた内容 | 判断 |
|---|---|
| 当時の付箋と同じ記録票で、同じ食い違いが見つかった | OCRと Apps Script の連携に進む |
| 読みにくい時刻をそれらしく直した | 指示の書き方で直る。構成は有効 |
| 特記事項の体調の変化を拾えなかった | 印を付ける側に倒す指示を強める |
| 読めない欄が多い | スキャンの解像度と、記録票のペンが先 |
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 読みにくい時刻をAIが予定に合わせる | 予定をAIに見せない。 書かれたとおりに写させる |
| 午前・午後を黙って補う | 補うのは Apps Script。ampm_inferred を残す |
| 複写の文字が薄く、読めない欄が多い | 300dpiでスキャンする。 筆圧の強いペンを配る |
| ○で囲む区分が読めない | ラジオボタンには対応しない。□に印を付ける書式に変える |
| 空欄と読めない欄が混ざる | 値が空のキーと値は確実に読めない。全文と信頼度で分ける |
| 担当が引き当てられない | 呼び名の一覧を作り、確認のたびに足す |
| 予定のシートが古い | 突き合わせの前日に貼り直す決まりにする |
| 特記事項が要約されて届く | 全文を写させ、印の根拠だけを抜き出させる |
| 実績が自動で確定する | 介護ソフトへは書き込まない。実績に直すのは人 |
| 国外での処理を確かめていない | 日本のリージョンが無い。自社の決まりと利用者との取り決めを先に確かめる |
上の2行が、この構成の失敗のほとんどです。 どちらも、AIが予定の側に寄せて読んでしまうという同じ型の失敗です。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 利用者の氏名、訪問の日時、受けたサービスの内容、そして特記事項に書かれた体調の変化、食事や排せつの様子、転倒やけがです。利用者の心身の状態に関わる情報で、事業所の中でも見る人を絞るべき情報です。
- 国外で処理することを確かめる … Document AI のリージョンの一覧に日本はありません。記録票を国外のリージョンで処理してよいかを、自社の個人情報の取扱いの決まりと、利用者・家族への説明の内容に照らして確かめます。 認められない場合は、日本のリージョンで処理できる製品を検討します
- 生成AIに渡す情報を絞る … Claude API には、利用者名を利用者コードに置き換えてから渡します。訪問予定や利用者の一覧そのものは渡さず、突き合わせは Apps Script の側で行います
- 実績を自動で確定しない … 介護ソフトの実績に直すのは、確かめの済んだ記録票を見た事務の担当です
- 特記事項の扱いを決めておく …
noteの印は、サービス提供責任者が読むための目印です。AIが付けた印を、事故の報告や苦情の記録の代わりにしません。 報告の要否は、サービス提供責任者と管理者が決めます - 確認待ちのシートの共有範囲を絞る … 利用者の心身の状態が1枚に並ぶため、事務の担当、サービス提供責任者、管理者だけが見られるようにします
- 原本を残す … 記録の拠り所は紙の記録票です。PDFやAIの写しは、原本の代わりにしません
誤りが起きた場合のリスクは、実際と違う実績が確定することと、体調の変化の記述が届かないことの2つです。 予定を見せないことと、迷ったら印を付ける指示で、設計の側から防ぎます。
10まず何から始めるか
1週目:呼び名の一覧と突き合わせの決まりを作る
先月の記録票を見て、担当欄にヘルパーがどう書かれているかを書き出し、介護ソフトのヘルパーのコードと対応させます。あわせて、何分のずれを印にするか、どの欄を必須とするかをサービス提供責任者と決めます。
2週目:30枚で試す
利用者名を塗った記録票30枚を手元のAIサービスに貼り付けて、欄と特記事項を写させます。読みにくい時刻を直していないか、特記事項の体調の変化を拾えているかを最優先で見ます。
3週目:国外での処理を確かめ、書式を見直す
記録票を国外のリージョンで処理してよいかを、自社の決まりと利用者・家族への説明の内容で確かめます。 あわせて、○で囲む書き方の欄を□に変える、24時間で書いてもらうなど、記録票の書式とペンを見直します。
4週目:フォルダから確認待ちのシートまでをつなぐ
Apps Script で「受付」フォルダを確かめ、OCRを呼び、写した値を確認待ちのシートに書き出すところまで作ります。この時点では印を出さず、事務の担当がこれまでどおり見比べながら、シートの値が合っているかを見ます。
2か月目: 訪問予定との突き合わせと印を足し、印の付いた行だけを見る運用を始めます。3か月目以降: 1件2分が何分になったかを実測します。問い合わせが訪問から1週間以内に済み、特記事項がその週のうちにサービス提供責任者に届くようになった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| 指定訪問介護事業者が、提供した具体的なサービスの内容等を記録しなければならないこと(第19条第2項)。その記録を整備し、完結の日から2年間保存しなければならないこと(第39条第2項) | e-Gov 法令API: 指定居宅サービス等の事業の人員、設備及び運営に関する基準 | 2026-10-13 |
Form Parser がOCRのテキストに加えてキーと値のペア、チェックボックス、表、一般的なエンティティを抽出すること。言語の一覧で日本語(ja)が手書きに対応する言語として示されていること。オンラインの処理が最大15ページ、バッチ処理が最大100ページであること | Google Cloud: Processor list | 2026-10-13 |
| 値の入っていないキーと値の組を確実には読み取れないこと。チェックボックスのモデルがラジオボタンに対応しないこと。ラテン文字でない言語ではキーと値の読み取りの質が下がることがあること | Google Cloud: Form Parser | 2026-10-13 |
項目名と値の組が formFields の fieldName/fieldValue で返ること。チェックボックスの valueType が filled_checkbox/unfilled_checkbox であること。信頼度と位置が layout の confidence・boundingPoly に入ること | Google Cloud: Handle the processing response | 2026-10-13 |
| 対応形式が PDF、GIF、TIFF、JPEG、PNG、BMP、WebP であること。スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよいこと | Google Cloud: Supported files | 2026-10-13 |
マルチリージョンが us と eu で、単一リージョンにシンガポール(asia-southeast1)などがあり、日本のリージョンが一覧に無いこと | Google Cloud: Regional and multi-regional support | 2026-10-13 |
output_config.format に JSON スキーマを渡して応答の形を固定できること。列挙の値の大文字・小文字は保証されないこと。max_tokens で打ち切られたときはスキーマに合わない出力になりうること | Claude API: Structured outputs | 2026-10-13 |
| 時間主導型のトリガーが毎分から月1回までの間隔で設定でき、実行の時刻がわずかにずれることがあること。インストール型トリガーの種類に、ドライブへのファイルの保存を起点とするものが無いこと | Apps Script: Installable triggers | 2026-10-13 |
Folder.getFiles() でフォルダ内のファイルを取得できること | Apps Script: Class Folder | 2026-10-13 |
何分のずれを確かめの対象にするか、予定と違った訪問をどう扱うか、記録票を外部のサービスで処理してよいかは、事業所の管理者とサービス提供責任者が、自社の決まりと指定を受けている自治体の定めに沿って決めてください。 本記事は各製品の公式ページと法令で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-1399)についてのご相談はこちらから。
