Media > AI活用ユースケース > 総務 > 訪問看護ステーションに主治医から届く訪問看護指示書を読み取り、指示期間・病名・指示内容を利用者ごとの台帳にそろえて、期限切れ間近と記載の欠けを拾う

訪問看護ステーションに主治医から届く訪問看護指示書を読み取り、指示期間・病名・指示内容を利用者ごとの台帳にそろえて、期限切れ間近と記載の欠けを拾う

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

主治医から紙やFAXで届く訪問看護指示書を読み取り、指示期間・主たる傷病名・医療機器・指示事項を利用者ごとの指示書台帳にそろえます。期限が近い指示書と、記載が欠けている指示書を一覧にして、主治医への依頼に回します。

サマリー
生成AI
ChatGPT/Claude
AIサービス
Azure AI/Google Document AI
連携・自動化
Google Apps Script/Python
対象業界
介護/医療
対象部門
総務
対象業務
データ入力・転記/台帳・マスタ管理
主な課題
入力作業が多い/期限・対応漏れが起きる/確認ミスが多い
AIで行う処理
読み取り(OCR)
主な効果
入力漏れ削減/工数削減/機会損失防止
導入難易度
★★★☆☆
実装レベル
本格構成
費用感
API連携(中)
人間の確認
必須
現在工数
24h/月
AI導入後
9h/月
想定削減
63%
年間削減
180h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. FAXで届いた指示書を複合機から取り出し、利用者名を見て仮のトレイに分ける
  2. 郵送で届いた原本を開封し、先に届いていたFAXと突き合わせる
  3. 指示書台帳のスプレッドシートを開き、利用者の行に指示期間・主たる傷病名・医療機器・指示事項の要点を書き写す
  4. 前回の指示書の終了日と、今回の開始日がつながっているかを目で見る
  5. 空欄や読めない箇所があれば付箋を貼り、管理者に回す
  6. 月末に台帳を期限の順に並べ替え、翌月に切れる利用者を拾い出して、主治医への依頼の文書を作る
  7. 記録・請求のソフトにも指示期間を入力し、原本を利用者のファイルに綴じる
導入後(After)
  1. 人FAXで届いた指示書と、郵送で届いた原本をスキャンし、受付フォルダに保存する
  2. 自動数分おきに動く仕組みが新しいファイルを見つけ、形式・ページ数・解像度を確かめる
  3. 自動OCRが欄のキーと値、表、各要素の信頼度を返す
  4. 自動生成AIが、台帳の項目に合わせて値をそろえる。読めない値と書かれていない値を分けて印を付ける
  5. 自動利用者台帳と照らして利用者を特定し、前回の指示書との期間のつながりを計算する
  6. 自動期間の長さ、指示日、種類ごとの期間の上限を規則で確かめ、印を付ける
  7. 自動「確認待ち」のシートに1通1行で書き出す。画像へのリンクを添える
  8. 人事務の担当が、印の付いた行だけを画像と見比べて確かめ、指示書の種類を確定する
  9. 人管理者が、記載の欠けと期間の切れ目の行を見て、主治医への依頼を決める
  10. 自動確定した行を指示書台帳へ移し、期限の30日前と14日前に一覧を出す
  11. 人記録・請求のソフトへの入力は、確定した台帳を見ながら行う
各工程の詳しい説明を読む
  1. FAXで届いた指示書を複合機から取り出し、利用者名を見て仮のトレイに分ける
  2. 郵送で届いた原本を開封し、先に届いていたFAXと突き合わせる
  3. 指示書台帳のスプレッドシートを開き、利用者の行に指示期間・主たる傷病名・医療機器・指示事項の要点を書き写す
  4. 前回の指示書の終了日と、今回の開始日がつながっているかを目で見る
  5. 空欄や読めない箇所があれば付箋を貼り、管理者に回す
  6. 月末に台帳を期限の順に並べ替え、翌月に切れる利用者を拾い出して、主治医への依頼の文書を作る
  7. 記録・請求のソフトにも指示期間を入力し、原本を利用者のファイルに綴じる

(a)期間の切れ目に気づくのが遅い。 6番の並べ替えは月末にしか行わないため、月の途中で切れる指示書は、切れた後に気づくことがあります。主治医の外来は予約制のことが多く、依頼してから新しい指示書が届くまでに日数がかかります。

(b)指示書の種類と期間を取り違える。 1枚の用紙に「訪問看護指示期間」と「点滴注射指示期間」の2つの期間欄があり、どちらかだけが書かれていることもあります。急いでいると、点滴の期間を訪問看護の期間として台帳に書き写します。 特別訪問看護指示書が重なる時期は、どれが今有効なのかが台帳の上で分からなくなります。

(c)空欄なのか、読めないのかが分からない。 FAXでは細い手書きの線が消えたり、印影と文字が重なったりします。付箋の「不明」には、書かれていないものと読めないだけのものが混ざっています。

(d)書き写しが2重になっている。 台帳と記録・請求のソフトの両方に入れるため、一方だけ直して他方が古いままということが起きます。

  1. 【人】 FAXで届いた指示書と、郵送で届いた原本をスキャンし、受付フォルダに保存する
  2. 【自動】 数分おきに動く仕組みが新しいファイルを見つけ、形式・ページ数・解像度を確かめる
  3. 【自動】 OCRが欄のキーと値、表、各要素の信頼度を返す
  4. 【自動】 生成AIが、台帳の項目に合わせて値をそろえる。読めない値と書かれていない値を分けて印を付ける
  5. 【自動】 利用者台帳と照らして利用者を特定し、前回の指示書との期間のつながりを計算する
  6. 【自動】 期間の長さ、指示日、種類ごとの期間の上限を規則で確かめ、印を付ける
  7. 【自動】 「確認待ち」のシートに1通1行で書き出す。画像へのリンクを添える
  8. 【人】 事務の担当が、印の付いた行だけを画像と見比べて確かめ、指示書の種類を確定する
  9. 【人】 管理者が、記載の欠けと期間の切れ目の行を見て、主治医への依頼を決める
  10. 【自動】 確定した行を指示書台帳へ移し、期限の30日前と14日前に一覧を出す
  11. 【人】 記録・請求のソフトへの入力は、確定した台帳を見ながら行う

8番目で、指示書の種類を人が確定させるのがこの設計の要です。 種類によって期間の上限も、台帳の列も変わります。

10番目の一覧が、月末の並べ替えを置き換えます。 月の途中で切れる指示書も、切れる前に依頼できます。

02今回想定するシステム構成

構成図
指示書(FAX・郵送の原本)
   │  事務がスキャンし、受付フォルダへ保存
   ▼【トリガー】Apps Script の時間主導型トリガー(数分おき)
Google Apps Script ── 新しいファイルを見つけ、処理待ちへ
   ▼
Google Document AI(Form Parser)
   │   欄のキーと値、表、各要素の信頼度
   ▼
Claude API ── 台帳の項目にそろえる(読めない/書かれていないを分ける)
   ▼
Google Apps Script ── 利用者台帳との照合/期間のつながり/上限の確認
   ▼
「確認待ち」シート(印と画像へのリンク)
   ▼
【事務が種類を確定、管理者が依頼を判断】
   ▼
指示書台帳(期限の30日前・14日前の一覧)
役割想定する製品代替候補
OCRGoogle Document AI(Form Parser)Azure AI Document Intelligence
生成AIClaude API(読み取り結果を台帳の項目にそろえる)OpenAI API
連携Google Apps Script(フォルダの確認、OCRとAIの呼び出し、シートへの書き込み)Python
差異計算Google Apps Script(期間のつながりと上限の確認)Python
保管Google ドライブ(指示書の画像と読み取り結果)事業所のファイルサーバー

新しく足すのは、「確認待ち」のシートと「主治医の書式の表」の2つです。 記録・請求のソフトにはこの構成から書き込みません。

土台は Document AI の Form Parser です。 公式のプロセッサ一覧では、OCRのテキストに加えてキーと値のペア、チェックボックス、表を抽出するとされ、Form Parser の言語の一覧で日本語(ja)は手書きに対応する言語として示されています。「患者氏名」「主たる傷病名」「訪問看護指示期間」のような欄は、キーと値のペアとして返ります。

Form Parser の注意書きのうち、この題材に効くのは3つです。 1つ目は、値が空のキーと値のペアは確実には読み取れないとされていること。空欄の検出を Form Parser だけに頼れない理由です。2つ目は、チェックボックスのモデルはラジオボタンの読み取りに対応しないとされていること。様式の「○で囲む」選択や寝たきり度の選択肢は、チェックボックスとしても拾えないと考えておきます。3つ目は、表はセルが行や列にまたがらない単純なものだけが対象とされていることです。

処理する場所は、us・eu やシンガポール(asia-southeast1)などから選び、日本のリージョンはありません。 国外で処理してよいかを導入前に確かめます(第13章)。

03どうやって実装するのか

Step1

処理の起点を決める

受付フォルダへの保存を、Apps Script の時間主導型トリガーで数分おきに見に行きます。 インストール型トリガーの一覧には、スプレッドシートの編集やフォームの送信を起点とするものはありますが、ドライブのフォルダへのファイルの追加を起点とするものはありません。 そのため、最短1分ごとから設定できる時間主導型のトリガーで、新しいファイルを探します。実行の時刻はわずかにずれることがあるとされています。

数分の遅れは問題になりません。 期限の管理は日単位です。

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

FAXと原本は別のファイルとして扱います。 同じ指示書が2回入ってくることを前提にし、重複は後段で見つけます(前処理の6番)。

Step2

入力データを集める

データ中身取得元
指示書の画像FAXの受信画像、または原本のスキャン。受け取った日と経路(FAX/郵送)受付フォルダ
読み取り結果欄のキーと値、表、全テキスト、各要素の信頼度Google Document AI
利用者台帳利用者番号、氏名、生年月日、主治医、医療機関、保険の区分(医療/介護)事業所のスプレッドシート
指示書台帳利用者ごとの、これまでの指示書の種類・期間・状態事業所のスプレッドシート
主治医の書式の表医療機関ごとの書式の型、期間の欄の位置、印字か手書きか事業所で用意する表

質を決めるのは、下の3つです。 利用者台帳に生年月日が無いと、同姓同名の利用者を分けられません。指示書台帳に前回の期間が無いと、つながりを計算する相手がありません。 主治医の書式の表が無いと、独自書式の指示書で期間の欄を取り違えます。

Step3

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

取るものどこから何に使うか
欄のキーと値pages[].formFields(fieldName/fieldValue)氏名、生年月日、病名、期間、指示日、医師名の値の候補
表pages[].tables(headerRows/bodyRows の cells)投与中の薬剤、装着・使用医療機器の欄
全テキストtext と、各要素の textAnchorキーと値として出なかった欄を本文から拾う
信頼度と位置各要素の layout(confidence・boundingPoly)読めない値の判定と、画像の該当箇所の切り出し

文字の唯一の置き場所は text です。 処理結果の説明では、text が文書の文字の source of truth とされ、ほかの要素は textAnchor の開始・終了の位置でそこを指します。値を写すときは、必ず textAnchor から text を引いて写し、別の要素の文字を組み合わせて作らないようにします。

チェックボックスは、フォームのフィールドの中なら valueType が filled_checkbox/unfilled_checkbox として返ります。 ただし、この様式の多くは□ではなく選択肢を○で囲む書き方です。○の位置は信頼度の低い文字の重なりとして返るか、何も返らないことがあるため、選択の欄は「要目視」として扱い、AIに値を決めさせません。

Step4

AIへ渡す前に整形する

  1. 形式の確認 … PDF、TIFF、JPEG、PNG などの対応形式であることを確かめます。複合機の既定の保存形式を先に確かめておきます
  2. 解像度の確認 … 公式のページでは、スキャンは最低200dpi、300dpi以上が一般に最もよいとされています。FAXの受信画像はこれを下回ることが多いため、FAXの画像は「仮の読み取り」として扱います
  3. ページ数の確認 … Form Parser のオンラインの処理は1回の要求で15ページまでです。指示書は1〜2枚ですが、まとめてスキャンされたものは分けます
  4. ファイルサイズの確認 … オンラインの処理は40MBまでです
  5. 向きと傾きの補正 … FAXは横向きや逆さで届くことがあります。向きを直してから渡します
  6. 重複の検知 … 同じ利用者・同じ指示日・同じ医療機関のものが直近にあれば、FAXと原本の組として結び付けます
  7. 個人情報の範囲の確認 … 指示書以外の書類(診療情報提供書など)が混ざっていないかを、1ページ目の題名の文字で確かめます

2番目と6番目は組で考えます。 FAXで先に読み取った値は、原本が届いたら原本の読み取り結果で上書きし、どの欄が変わったかを記録します。 FAXの段階では「仮」の印のまま台帳に載せず、期限の拾い出しにだけ使います。

Step5

AIに処理させる

させるのは、OCRの結果を台帳の項目に当てはめ、それぞれに状態の印を付けることです。 期間の計算や上限の確認はさせません。

台帳の項目させること判断できないときの扱い
指示書の種類(候補)題名の文字と○の位置から、訪問看護/点滴注射/特別訪問看護の候補を挙げる候補が2つ以上なら ambiguous
訪問看護指示期間開始日と終了日を、書かれた年号のまま写す片方だけなら、もう片方を missing
点滴注射指示期間同上。訪問看護の期間と別の項目として写す書かれていなければ missing
患者氏名・生年月日書かれたとおりに写す信頼度が低ければ unreadable
主たる傷病名(1)〜(3)を順に写す略語は書かれたまま
装着・使用医療機器等番号に印のあるもの、サイズや交換の間隔を写す印の有無が判定できなければ ambiguous
留意事項及び指示事項要点ではなく原文を写す長文は全文を写し、要約しない
緊急時の連絡先・不在時の対応写す書かれていなければ missing
指示日・医療機関名・医師氏名写す書かれていなければ missing

状態の印は4つです。 ok は値が読めて項目として解釈できるもの、missing は値が無いもの、unreadable は文字は検出されたが信頼度が低いもの、ambiguous は候補が複数あるものです。missing は主治医への確認、unreadable は原本の到着待ちか送り直しに回ります。

させないこと理由
期間の計算・上限の判定日付の計算は規則で行う。AIの計算は確かめようがない
病名の言い換え・標準病名への置き換え主治医の書いた病名を変えない
指示事項の要約要約で落ちた一文が訪問の注意点のことがある
薬剤の用量の補完前回の指示書から埋めない
指示の内容が適切かの評価管理者と主治医が判断すること

3行目は特に守らせます。 「特記すべき留意事項」には薬の相互作用やアレルギーの既往が書かれます。

Step6

指示内容を固定する

あなたは訪問看護ステーションの事務で、主治医から届いた指示書を
台帳の項目に書き写す立場です。
OCRが返した読み取り結果だけを見て、書かれているとおりに写してください。

【写す項目】
1. 指示書の種類の候補(訪問看護指示書/在宅患者訪問点滴注射指示書/特別訪問看護指示書)
2. 訪問看護指示期間(開始日・終了日)
3. 点滴注射指示期間(開始日・終了日)
4. 患者氏名・生年月日
5. 主たる傷病名(1)〜(3)
6. 装着・使用医療機器等(番号と、サイズ・交換の間隔)
7. 留意事項及び指示事項(原文のまま)
8. 緊急時の連絡先・不在時の対応
9. 指示日・医療機関名・医師氏名

【status の選び方】
- ok ......... 値が読み取れており、その項目として解釈できる
- missing .... 値が無い。項目名だけがあって値が空の場合も missing
- unreadable . 文字は検出されているが信頼度が低く、値として確定できない
- ambiguous .. 値の候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 記載がなければ「不明」とし、status を missing にしてください。
  前回の指示書や他の欄から補って埋めないでください。
- 訪問看護指示期間と点滴注射指示期間を混ぜないでください。
  どちらの欄に書かれた日付かが分からないときは ambiguous です。
- 日付は書かれた年号・書き方のまま value に入れてください。
  西暦への変換、終了日の計算、期間の長さの計算はしないでください。
- 病名・薬剤名・用量は書かれた文字のまま写してください。
  言い換え、略語の展開、誤字と思われる箇所の修正をしないでください。
- 留意事項及び指示事項は要約せず、全文を写してください。
- ○で囲む選択(指示書の種類、寝たきり度、認知症の状況、要介護認定の状況)は、
  候補を candidates に挙げるだけにし、status を ambiguous にしてください。
- evidence には、判定の根拠にした文字列をそのまま写してください。
- confidence は OCR が返した値をそのまま入れてください。
- 指示の内容が適切かどうか、訪問を続けてよいかは書かないでください。
- 指示書でない書類と判断した場合は、写さずに document_type に種類を書いてください。

【読み取り結果】{ocr_result}
【この医療機関の書式の型】{form_profile}

「期間を計算しない」を明記しないと、終了日が空欄の指示書に「開始日から6か月後」を入れてきます。 上限は6か月でも、主治医が6か月と書いたとは限りません。書かれていない終了日は missing として主治医に確かめるもので、埋めた瞬間にその確認が消えます。

○で囲む選択を ambiguous に固定しているのも同じ理由です。 AIに選ばせると、もっともらしい1つを選びます。選択の欄は、人が画像で1回見れば済む欄です。

Step7

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力では、output_config.format に json_schema を渡してこの形に固定します。オブジェクトには additionalProperties: false が必要です。

{
  "file_id": "",
  "document_type": "home_nursing_order",
  "order_type_candidates": ["visit_nursing", "iv_infusion", "special_visit"],
  "patient": {
    "name": { "status": "ok", "value": "", "confidence": 0, "evidence": "" },
    "birth_date": { "status": "ok", "value": "", "confidence": 0, "evidence": "" }
  },
  "fields": [
    { "item": "visit_period_start", "status": "ok | missing | unreadable | ambiguous",
      "value": "", "confidence": 0, "evidence": "", "candidates": [] }
  ],
  "instructions_fulltext": "",
  "source_channel": "fax | original"
}

fields の item は visit_period_start / visit_period_end / iv_period_start / iv_period_end / diagnosis_1〜diagnosis_3 / devices / emergency_contact / absence_response / order_date / institution / physician などです。

構造化出力を使う理由は3つあります。 1つ目は、期間の欄を別々の項目に固定できることです。自由文で返させると、訪問看護と点滴の期間が1つの文に混ざります。2つ目は、status を後段の規則がそのまま読めることです。3つ目は、evidence と confidence で確認が速くなることです。

公式のページでは、列挙の値の大文字・小文字が変わることがあるとされているため、status の比較は大文字・小文字を区別せずに行います。 max_tokens で打ち切られたときはスキーマに合わない出力になりうるので、検証に通らない出力は確認待ちに回します。

後段の Apps Script が付ける印は次のとおりです。

印条件
期間の切れ目前回の終了日の翌日と、今回の開始日が一致しない
上限超え訪問看護指示書で、期間が6か月を超える。特別訪問看護指示書で、交付の日から14日を超える
指示日の後付け指示日が期間の開始日より後(事業所の決まりとして確かめる)
期限間近終了日まで30日以内/14日以内
記載の欠け期間・指示日・医師氏名・病名のいずれかが missing
要目視unreadable または ambiguous を含む/FAXの仮の読み取り
Step8

システムへ連携する

つなぎ先方式内容
受付フォルダApps Script の時間主導型トリガー新しいファイルを見つける
Google Document AIAPI呼び出し欄のキーと値、表、信頼度を返す
Claude APIAPI呼び出し台帳の項目へのあてはめと状態の印
利用者台帳・指示書台帳スプレッドシートの読み取り利用者の特定、前回の期間
確認待ちのシートスプレッドシートへの書き込み1通1行と画像へのリンク
指示書台帳確定した行だけを書き込み期限の一覧の元になる

指示書台帳へは、人が確定した行しか書き込みません。 確認待ちのシートと台帳を分けるのは、未確認の値が期限の一覧に混ざらないようにするためです。 FAXの仮の読み取りだけは、期限間近の拾い出しにだけ使い、台帳の値は原本で確定させます。

記録・請求のソフトには書き込みません。 請求に関わる値を自動で書き換える経路を持たないことで、読み取りの誤りが請求まで進むことを防ぎます。 事務は、確定した台帳を見ながらソフトに入力します。2重入力は残りますが、どちらが正しいかは台帳で決まるようになります。

Step9

人が確認する

人が開くのは、印の付いた行と、指示書の種類の確定だけです。

  1. 指示書の種類を確定する … 全件で行います。○の位置を画像で見て、候補から選びます。1通あたり数秒の作業です
  2. 要目視の行を見る … unreadable と ambiguous の欄を、画像の該当箇所と見比べて値を直します
  3. 期間の切れ目と上限超えを管理者が見る … 切れ目がある場合、その間に訪問の予定が入っていないかを確かめます
  4. 記載の欠けを主治医に確かめる … 依頼の文面の下書きを見て、管理者が送るかを決めます
  5. 直した欄を記録する … どの欄を、何から何に直したかを残します

3番目は管理者が見ます。 訪問の計画に関わる判断だからです。

目標は、90通をならして1通6分です。 種類の確定は数秒、印の無い行は流し見で終わり、時間を使うのは要目視と主治医への確認が要る行だけという想定です。

Step10

例外に対処する

起きること対応
FAXの画像が粗く、多くの欄が unreadable仮の読み取りとして期限の拾い出しにだけ使い、原本の到着を待つ
原本が届かない受付から一定日数で一覧に出し、医療機関に確認する
利用者台帳に該当者がいない新規の利用者か、氏名の表記違いかを事務が確かめる。自動で行を作らない
同姓同名の利用者がいる生年月日で分ける。生年月日が unreadable なら要目視
独自書式で期間の欄が見つからない主治医の書式の表に型を足し、次回から位置を指定する
特別訪問看護指示書が通常の指示書と重なる両方を台帳に持ち、どちらの期間かを列で分ける
点滴注射の期間だけが書かれている訪問看護の期間を missing とし、別の指示書があるかを確かめる
指示書以外の書類が混ざるdocument_type を見て、写さずに事務へ戻す
OCRやAIが応答しない受付フォルダに残し、次の回で再実行する

上から3行目は、自動で行を作らないことが大事です。 氏名の読み違いで新しい利用者の行ができると、本来の利用者の期限の一覧から、その指示書が抜けます。

Step11

記録を残す

  • 指示書の画像(FAXと原本の両方)と、受け取った日・経路
  • OCRが返したJSONの全文
  • AIの出力(fields、status、evidence、confidence)
  • 人が直した欄の記録 … どの欄を、何から何に直したか、誰が確定したか
  • 期間の切れ目と上限超えについて、管理者が行った判断と主治医への依頼の日付
  • 医療機関ごとの unreadable の発生率

4つ目が、AIの使い方を直す材料になります。 同じ医療機関の同じ欄で直しが続くなら、主治医の書式の表にその欄の位置を書き足します。

最後の行は、医療機関に送信の解像度を上げてもらう相談の材料になります。

04実装レベルの3段階

最小構成:黒塗りの写しを手でAIの画面に貼り、期間と病名を写させる / 1通ごとの読み取りの確認
半自動化:上記+OCRのAPIを呼び、確認待ちのシートに1通1行で書き出す / 読み取りと台帳の項目へのあてはめ
本格構成:上記+受付フォルダを起点に自動で動かし、前回の期間との照合、上限の確認、期限の一覧まで出す / 読み取りから期限の管理まで

最小構成は、読み取りが使えるかを確かめる段階です。 半自動化で、書き写しの8分がほぼ無くなります。 照合と期限の拾い出しは手作業のまま残ります。本格構成で照合と拾い出しが自動になり、1通6分になります。 この段階が本記事の想定です。 半自動化で1か月回し、主治医の書式の表を埋めてから本格構成に進むほうが、要目視の行が減ります。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
3 名
月間件数
90 件
1件あたり現在時間
16 分
1件あたり導入後時間
6 分
現在  90件 × 16分 ÷ 60 = 24 時間/月
導入後 90件 × 6分 ÷ 60 = 9 時間/月
月間削減時間
15h
削減率
63%
年間削減時間
180h
年間金額換算(時間単価3,000円)
54万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 利用者が百数十名から数百名いて、複数の病院・診療所の主治医から訪問看護指示書が紙やFAXで毎月数十通届き、事務の担当が1通ずつ読んで台帳や表計算に書き写している訪問看護ステーション。指示期間の切れ目に気づくのが訪問の直前になり、主治医への再発行の依頼が後手に回っている場合。特別訪問看護指示書や点滴注射の指示書が混ざり、期間の管理を別々にしている場合。
向いていない
  1. 利用者が数十名で、指示書が月に十通前後しか届かない場合。主治医とのあいだで指示書を電子的にやり取りする仕組みがすでにあり、項目がデータで受け取れる場合。法人の規程で、利用者の病名や医療の情報を国外のリージョンで処理することが認められない場合。なお、指示の内容が適切か、訪問を続けてよいかの判断は管理者と主治医が行うもので、この構成では代替できません。

07最小構成で試す方法

  1. 先月届いた指示書から20通を選ぶ(FAXと原本の組、独自書式、特別訪問看護指示書を必ず混ぜる)
  2. 氏名・住所を黒塗りにした写しを作る
  3. 手元のAIサービスの画面に1通ずつ画像を貼り付ける
  4. 「この指示書の、指示書の種類、訪問看護指示期間、点滴注射指示期間、主たる傷病名、指示日、医師氏名を書かれたとおりに写してください。書かれていない欄と読めない欄を分けてください。期間の計算はしないでください」と指示する
  5. 出てきた値を、当時台帳に書き写した値と並べる

黒塗りを省かないでください。 試す段階でも、氏名と病名を組で外部に渡すことになります。

出てきた内容判断
期間と病名が台帳と一致したOCRのAPIとシートの連携に進む
訪問看護と点滴の期間が混ざった指示の書き方で直る。種類の確定を人に残す設計で吸収できる
FAXの写しで読めない欄が多い原本で確定させる運用が前提になる。 AIの問題ではない

08実装時につまずきやすいポイント

問題対策
点滴注射の期間を訪問看護の期間として写す別の項目として固定する。 どちらの欄か分からなければ ambiguous
空欄の終了日を「6か月後」で埋める期間の計算を禁じる。書かれていない終了日は主治医に確かめる
○で囲む選択をAIが1つに決める選択の欄は候補を挙げるだけにし、人が画像で確定する
空欄が ok になる値が空のキーと値のペアは確実には読み取れない。 値の有無で判定する
FAXの値がそのまま台帳に載るFAXは仮の読み取り。原本で確定させる
氏名の読み違いで新しい利用者の行ができる自動で行を作らない。生年月日と組で照合する
独自書式で期間の欄を取り違える主治医の書式の表に、医療機関ごとの欄の位置を書く
特別訪問看護指示書が通常の期間を上書きする種類ごとに列を分け、上書きせずに並べて持つ
留意事項が要約されて落ちる全文を写させ、要約させない
期間の切れ目を事務の判断で閉じる管理者が見る。 訪問の計画に関わる判断
国外のリージョンで処理していることを知らずに使う導入前に法人の規程と照らす

上の3行が、この構成の失敗のほとんどです。 どれも「書かれていないものを、もっともらしく埋める」ことから起きます。

下から2行目は、運用が回り始めてから効いてきます。 切れ目の印を閉じる権限を管理者に置いておくと、一覧が形だけになりません。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 利用者の氏名・生年月日・住所・電話番号、主たる傷病名、投与中の薬剤、装着している医療機器、要介護認定の状況、主治医と医療機関の情報です。病歴に当たる情報で、個人情報のなかでも特に慎重な扱いが要るものです。

  1. 処理する場所を確かめる … Document AI のリージョンは us・eu と一部の単一リージョンで、日本のリージョンはありません。 利用者の病名を国外で処理してよいかを、法人の規程と、医療・介護の情報の取り扱いについての方針に照らして、導入前に決めてください
  2. 外部に渡す範囲を絞る … 利用者台帳はAIに渡さず、照合は Apps Script の側で行います
  3. 試す段階でも黒塗りにする … 最小構成で手元のAIサービスを使うときは、氏名・住所・電話番号を黒塗りにした写しを使います
  4. 台帳への書き込みは人の確定の後 … 未確認の値が期限の一覧や訪問の準備に使われないよう、確認待ちのシートと台帳を分けます
  5. AIは指示の内容を評価しない … 指示が適切か、訪問を続けてよいかは、管理者と主治医が判断することです。この構成が出すのは、書かれていることと書かれていないことの区別だけです
  6. 原本の保管を変えない … 指示書の原本は、これまでどおり利用者ごとに綴じて保管します
  7. 閲覧できる人を絞る … 受付フォルダ、確認待ちのシート、台帳は、事務と管理者と担当の看護師に限ります

誤りが起きた場合のリスクは、期限の切れ目の見落としと、指示の取り違えの2つです。 どちらも「埋めない」「混ぜない」で防ぎます。

10まず何から始めるか

1週目:処理する場所と、確定の手順を決める

指示書を国外のリージョンで処理してよいかを確かめ、FAXと原本のどちらで確定させるか、切れ目を誰が判断するかを決めます。

2週目:20通で試す

先月の指示書から20通を選び、黒塗りの写しを手元のAIサービスに貼り付けて、期間と病名を写させます。訪問看護と点滴の期間が混ざらないか、空欄の終了日を埋めていないかを最優先で見ます。

3週目:台帳を整える

利用者台帳の生年月日と、指示書台帳の前回の期間を確かめます。指示書の多い医療機関から、書式の表を作ります。

4週目:受付フォルダから確認待ちのシートまでをつなぐ

Apps Script の時間主導型トリガーで受付フォルダを見に行き、OCRとAIを呼んで、確認待ちのシートに1通1行で書き出すところまで作ります。この時点では期限の一覧を出さず、読み取りと種類の確定だけを回します。

2か月目: 期間の照合、上限の確認、期限間近の一覧を足します。3か月目以降: 1通16分が何分になったかを実測します。月の途中で切れる指示書を切れる前に依頼できるようになった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-12/最終更新:2026-10-13
確認した内容情報源確認日
Form Parser がキーと値のペア、チェックボックス、表を抽出し、日本語(ja)が手書きに対応する言語として示されていること(原文を取得して確認)Google Cloud: Processor list2026-10-12
値の入っていないキーと値のペアを確実には読み取れないこと。チェックボックスのモデルがラジオボタンの読み取りに対応しないこと。表はセルが行や列にまたがらない単純なものが対象であることGoogle Cloud: Form Parser2026-10-12
text が文字の source of truth で、ほかの要素は textAnchor で指すこと。formFields、表の cells、layout の信頼度。チェックボックスが filled_checkbox/unfilled_checkbox で返ることGoogle Cloud: Handle the processing response2026-10-12
Form Parser のオンラインの処理が1回の要求で15ページまでであること。オンラインの処理のファイルサイズが40MBまでであることGoogle Cloud: Document AI quotas and limits2026-10-12
対応形式に PDF、TIFF、JPEG、PNG などが含まれること。スキャンは最低200dpiが望ましく300dpi以上が一般に最もよいことGoogle Cloud: Supported files2026-10-12
マルチリージョンが us と eu で、単一リージョンにシンガポール(asia-southeast1)などがあり、日本のリージョンが一覧に無いことGoogle Cloud: Regional and multi-regional support2026-10-12
output_config.format に json_schema を渡して応答の形を固定できること。オブジェクトに additionalProperties: false が必要なこと。列挙の値の大文字・小文字が変わりうること。max_tokens で打ち切られたときはスキーマに合わない出力になりうることClaude API: Structured outputs2026-10-12
時間主導型のトリガーが最短1分ごとから月1回まで設定でき、実行の時刻がわずかにずれることがあること。インストール型トリガーの一覧にドライブのフォルダへのファイルの追加を起点とするものが無いことApps Script: Installable triggers2026-10-12
訪問看護基本療養費が指示書に記載された有効期間内(6か月を限度)の訪問について算定されること。特別訪問看護指示書の交付の日から14日を限度とすること。令和8年6月1日から適用(保発0305第19号。原文を取得して確認)厚生労働省: 訪問看護療養費に係る指定訪問看護の費用の額の算定方法の一部改正に伴う実施上の留意事項について2026-10-12
様式が訪問看護指示書と在宅患者訪問点滴注射指示書を兼ね、該当する方を○で囲む作りであること。2つの期間の欄、主たる傷病名、医療機器、留意事項及び指示事項、緊急時の連絡先、指示日・医師氏名などの欄(原文を取得して確認。最新の様式は厚生労働省の公表で確かめること)厚生労働省: 別紙様式16 訪問看護指示書・在宅患者訪問点滴注射指示書2026-10-12

指示の内容が適切か、期間の切れ目にどう対応するか、指示書を外部のサービスで処理してよいかは、管理者と主治医、法人の規程に沿って決めてください。 本記事は各製品と厚生労働省の公開資料で確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-1255)についてのご相談はこちらから。

AI活用について相談する
目次