訪問介護のヘルパーが訪問先を出たあとに話した音声を文字にして、サービス内容・様子・申し送りを介護記録の項目に分けて登録する

処理の起点を決める

アプリで音声が保存されたことを起点にします。 ヘルパーは話す前に、アプリの画面でその日の予定から訪問を1件選びます。音声には必ず訪問IDが付いた状態で保存されます。 訪問を選ばずに録音を始めることはできないようにします。

保存された音声は、アプリから中継の処理へ送られます。電波が届かないときはスマートフォンの中にとどめ、つながった時点でまとめて送ります。 送った音声には受付の番号を返し、アプリに「送信済み」と出します。

訪問の終了から2時間たっても音声が届かない訪問は、ヘルパーに通知します。 話し忘れは、記録漏れの最大の原因です。翌日に気づいても、前日の訪問の様子は思い出せません。

入力データを集める

質を決めるのは、下の2つです。 サービス項目の一覧に言い方のゆれが無ければ、「お風呂の手伝い」が入浴介助のどれ（全身浴か部分浴か）に当たるかが決まりません。決まらないものは決まらないとして返させ、ヘルパーに選んでもらいます。

利用者ごとの語句は、音声認識の聞き違いを減らすために使います。 家族の名前やデイサービスの名前は、一般の辞書には載っていません。

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

文字起こしは、高速文字起こしのAPIに音声とその定義を送ります。

フレーズリストは、認識を始める直前に渡す語句の一覧で、モデルの学習は要りません。 公式の案内では2,000語句を超えないようにし、長いほど品質と待ち時間に影響するとされています。事業所の全利用者の語句をまとめて渡さず、その訪問の利用者の語句だけを渡します。 他の利用者の家族の名前が候補に入ると、取り違えの元になります。

送る定義は、たとえば次のような形です（語句は一部）。

POST https://{リソース名}.cognitiveservices.azure.com/speechtotext/transcriptions:transcribe?api-version=2025-10-15
audio      = 訪問IDを名前にした音声ファイル
definition = {
  "locales": ["ja-JP"],
  "phraseList": { "phrases": ["排泄介助", "部分浴", "清拭", "口腔ケア",
                              "見守り的援助", "ひまわりデイ", "<長女の呼び名>"] }
}

語句の一覧には、項目名だけでなく、その事業所で使う略し方も入れます。 「見守り的援助」を「見守り」と略すヘルパーが多いなら、両方を入れます。

訪問の予定と訪問介護計画は、介護記録のシステムから訪問IDで引きます。APIが無いシステムなら、毎朝その日の予定と計画を書き出したファイルを中継の処理が読む形でも足ります。

AIへ渡す前に整形する

1. 音声の長さを確かめる … 10秒未満は録音の失敗として、アプリで録り直しを促します。3分を超えるものは話しすぎとして、そのまま処理しつつ印を付けます
2. 形式をそろえる … アプリが録る形式（AAC など）のまま送れます。変換はしません
3. 語句の一覧を作る … サービス項目の一覧と、その利用者の語句を合わせます
4. 文字起こしの後で、信頼度の低い文に印を付ける … confidence が事業所で決めたしきい値を下回る文を、画面で色を変えて見せます
5. 利用者の氏名を置き換える … 文字起こしに利用者や家族の氏名が出てきたら、<利用者> <家族1> に置き換えてから生成AIへ渡します
6. 計画の項目を並べる … その訪問で計画されているサービス項目を、照合用の一覧として用意します

5番目は、話し方の決まりとあわせて効かせます。 ヘルパーには「利用者の名前は言わない」と決めてありますが、家族の呼び方などは自然に出ます。生成AIに渡すのは、記録の項目を取り出すのに要る範囲だけです。

AIに処理させる

させるのは、文字起こしから記録の項目を取り出し、それぞれに根拠の文を付けることだけです。

計画との照合は、AIにさせません。 AIが返すのは「話に出たサービス」と「断られたサービス」だけです。計画にあって話に出なかったものを not_mentioned にするのは、中継の処理の機械的な比較です。 AIに計画を渡して照合までさせると、計画にあるものを「実施した」と補ってしまいます。

最後の行は、記録の信頼に関わります。 「半分残した」と「食欲不振」では、読む人の受け取り方がまったく違います。介護記録は、見たまま聞いたままを残すのが原則です。

指示内容を固定する

あなたは訪問介護事業所で、ヘルパーが訪問のあとに話した内容から
介護記録の項目を取り出す立場です。
文字起こしに書かれていることだけを使ってください。推測で補わないでください。

【取り出す項目】
1. services_done … 提供したサービス。下の「サービス項目の一覧」の名前で書く
2. services_refused … 断られた・できなかったサービスと、その理由
3. observations … 利用者の様子（食事、水分、体調、気分、睡眠、皮膚、排泄など）
4. handover … 次の担当やサービス提供責任者への申し送り。1件ずつ分ける
5. health_flags … 転倒、発熱、痛み、息苦しさ、食欲や水分の低下などに触れた文

【厳守事項】
- 話に出てこないサービスを、提供したことにしないでください。
- サービス項目の一覧のどれに当たるか決められないときは、候補をすべて
  candidates に並べ、service を null にしてください。
- 様子は、話された言葉のまま書いてください。
  「半分残した」を「食欲不振」のように言い換えないでください。
- 状態の評価（安定、悪化など）や、受診が必要かどうかを書かないでください。
- 各項目に、根拠にした文字起こしの文を evidence としてそのまま写してください。
- <利用者> <家族1> などは置き換えた記号です。中身を推測しないでください。
- 時刻と利用者は書かないでください。別に決まっています。
- 信頼度が低いと印の付いた文から取り出した項目には、low_confidence を true にしてください。

【サービス項目の一覧】{service_master}
【文字起こし】{transcript}

「話に出てこないサービスを、提供したことにしない」を最初に置くのが要です。 生成AIは、訪問介護らしい流れを知っています。排泄介助と食事介助が話に出れば、口腔ケアも当然したものとして足すことがあります。計画を渡さないのも、同じ理由です。

「言い換えない」も明記します。 記録の文体に整えようとすると、話し言葉を専門用語に置き換えます。置き換えた瞬間に、ヘルパーが見たものではなく、AIの解釈が記録になります。

出力形式を固定する

Azure OpenAI の構造化出力で、次の形のJSONを受け取ります。 構造化出力では、すべての項目を必須にし、省略したいものは null との共用体型で表します。オブジェクトには additionalProperties: false を付けます。

{
  "visit_id": "V-20261007-0412",
  "services_done": [
    { "service": "排泄介助", "candidates": [], "evidence": "", "low_confidence": false }
  ],
  "services_refused": [
    { "service": "入浴介助（部分浴）", "reason": null, "evidence": "" }
  ],
  "observations": [
    { "category": "meal", "text": "", "evidence": "" }
  ],
  "handover": [
    { "to": "next_helper | coordinator | unspecified", "text": "", "evidence": "" }
  ],
  "health_flags": [
    { "text": "", "evidence": "" }
  ]
}

1つ目の理由は、計画との照合を機械で行えることです。 services_done と services_refused の service は、サービス項目の一覧の名前で返ります。中継の処理はこれを計画の項目と並べ、次のように区分します。

たとえば、計画が「排泄介助・食事介助・口腔ケア」の訪問で、ヘルパーが「トイレの介助と昼食の介助をしました。お昼は半分残されました。玄関の段差で少しふらつかれたので、次の方は手を添えてください」と話したとします。取り出されるのは、排泄介助と食事介助が services_done、「半分残された」が observations、手を添える件が handover、ふらつきが health_flags です。 口腔ケアはどこにも無いので、照合で not_mentioned になり、アプリが「口腔ケアは実施しましたか」と聞き返します。

2つ目は、health_flags を記録と別に流せることです。 体調に触れた文は、記録の登録を待たずにサービス提供責任者へ知らせます。重さを判断するのは人ですが、知らせるのは早いほどよいからです。

3つ目は、evidence で確認が速くなることです。 ヘルパーは、取り出された項目と、その根拠になった自分の言葉を並べて見られます。

システムへ連携する

介護記録のシステムへの登録は、ヘルパーが確定したものだけです。 確定前のものは中継の処理の側に置き、システムには入れません。登録できない形式のシステムなら、確定した記録を取り込み用のファイルに書き出し、事務所が1日1回取り込みます。 それでも打ち直しは無くなります。

人が確認する

1. ヘルパーが画面で確かめる … 取り出された項目と根拠の文を見て、直してから確定します。not_mentioned には「実施した」「実施しなかった（理由）」のどちらかを選びます
2. 信頼度の低い文を確かめる … 色の変わった文は、聞き違いの可能性があります。特に食事の量や薬の名前は、目で確かめます
3. サービス提供責任者が refused と unplanned を見る … 断られたサービスが続く利用者、計画外のサービスが続く利用者を見つけます
4. health_flags を受けて判断する … ケアマネジャーや医療職に伝えるかを決めます。伝えるかどうかを決めるのは人です

1番目の確定は、訪問のあと30分以内を目安にします。 次の訪問先に着く前に済ませる想定です。確定されないまま夕方になった記録は、事務所から声をかけます。

目標は、1,500件をならして1件3分です。 ヘルパーが話して確かめるのに2分、事務所とサービス提供責任者の確認がならして1分という想定です。

例外に対処する

再試行の考え方は、公式の案内に合わせます。 高速文字起こしには利用の上限があり、同時に多く送ると429が返ります。夕方に音声がまとまって届く時間帯に起きやすいので、受付の番号だけ先に返し、処理は順に回します。

記録を残す

• 音声の控え（保存期間を短く決め、記録の確定後に消す運用も検討する）
• 文字起こしの全文と、文ごとの信頼度
• 生成AIが返したJSONと、照合の結果
• ヘルパーが直した差分 … どの項目を、どう直したか
• 確定した日時と、介護記録のシステムへ登録した日時
• health_flags を知らせた日時と、サービス提供責任者の対応

記録そのものの保存は、介護記録のシステムの側で行います。 運営基準では、提供した具体的なサービスの内容等の記録を、その完結の日から2年間保存することとされています。この構成の控えは、それとは別に、誤りを追うために持つものです。

ヘルパーが直した差分は、語句の一覧を直す材料です。 同じ言葉の聞き違いが続くなら、その利用者の語句に足します。