介護記録と訪問時のメモから、ケアプランのモニタリング記録の下書きを利用者ごとに作る

処理の起点を決める

毎日22時に、その日に訪問記録が入った利用者だけを対象に動かします。 月末にまとめて240件を処理するのではなく、訪問のあった日の夜に下書きを作ります。 翌朝には、前日に訪ねた利用者の下書きがそろっています。

毎日にするのは、記憶が新しいうちに確認させるためです。 訪問から2週間たってから下書きを読むと、書かれていない出来事を思い出せず、下書きをそのまま通してしまいます。翌日なら、メモに書き漏らしたことを足せます。

月末には、もう一度だけ全員分を回します。 月の後半に届いたサービス事業所の実績報告を足して、下書きを更新するためです。更新したときは、担当者が確認した後の版を上書きしません。 差分だけを「追加の記録」として別枠に出します。

訪問記録が月内に1件もない利用者は、月の20日に一覧にします。 下書きを作る対象ではなく、訪問の予定を確かめる対象です。月1回の訪問と記録が求められているので、ここを先に拾います。

入力データを集める

質を決めるのは、いちばん上とそのすぐ下の2つです。 ケアプランの短期目標がCSVで取れなければ、目標ごとに整理できません。訪問記録の「方法」の欄が空だと、居宅訪問なのかテレビ電話装置等なのかを区別できず、後で確かめる手段が無くなります。

前月の記録を入れるのは、変化を拾うためです。 「今月は歩行器で近所のスーパーまで行けた」という記述は、前月に「玄関先までしか歩けない」とあって初めて意味を持ちます。前月の担当者の評価は、比較の材料として渡すだけで、そのまま写させません。

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

介護ソフトからは、ケアプラン、支援経過、訪問記録の3つをCSVで出力します。 多くの介護ソフトには帳票や一覧のCSV出力がありますが、項目の名前と並びはソフトごとに違います。最初に、自社のソフトが出せる列を一覧にして、この構成の入力の項目と対応させる表を作ります。

サービス事業所の記録は、届き方が一様ではありません。 ケアプランデータ連携システムを使っている事業所からはデータで届きますが、FAXや紙の連絡帳のままの事業所もあります。紙のものは、スキャンしたPDFを利用者ごとのフォルダに入れる運用にし、読み取りは下書きの対象外にします。 下書きには「紙の記録あり（未読込）」とだけ出して、担当者に原本を見てもらいます。

CSVの取得は、最初は担当者が夕方に手動で出力して共有ドライブに置くだけでも回ります。

AIへ渡す前に整形する

1. 発言者の付与 … 記録の1文ごとに、本人 ／ 家族 ／ 事業所 ／ 介護支援専門員 のどれの記述かを付けます。支援経過に「本人より」「長女より」と書かれていればその語で、事業所の記録は出どころで決めます
2. 日付の付与 … 記録ごとに、出来事の日付と記録の日付を分けて持たせます。後から書いた記録を、その日の出来事として扱わないためです
3. 目標との対応 … ケアプランのサービス内容と事業所の対応から、記録ごとに関係しそうな短期目標の候補を付けます。候補が決まらない記録は 未分類 のまま渡します
4. 氏名と住所の置き換え … 利用者、家族、ヘルパーの氏名を 利用者 「長女」「ヘルパーA」のような役割名に置き換えます。住所、電話番号、被保険者番号は削ります
5. 病名と服薬の扱いを決める … 目標に関係する範囲で残し、それ以外の既往歴は削ります
6. 重複の除去 … 同じ内容の連絡票がメールとFAXの両方で届いていれば、1件にまとめます
7. 長さの確認 … 1人あたりの材料が多すぎる月は、事業所の記録を日付順に並べて古いものから要点だけにします

1番目と4番目を軽く見ないでください。 発言者の付与が無いと、AIは文章の中身から誰の言葉かを推測します。推測が外れると、家族の心配が本人の訴えとして記録に残ります。 氏名の置き換えは外部に渡す情報を減らすためで、要配慮個人情報にあたる病歴などを扱う以上、渡す前に必ず通す工程にします。

AIに処理させる

させるのは、短期目標ごとに、その月の記録を6つの欄に振り分けて短く要約し、根拠の記録を示すことだけです。

右端の列が、この構成でいちばん大事な決まりです。 記録が無い欄を、AIは文章として自然になるように埋めようとします。「本人は意欲的に取り組んでいる」のような、どの記録にも無い一文が入るのが最も起きやすい失敗です。 無い欄は「記録なし」と書かせ、埋めさせません。

いちばん下の「材料が足りない点」は、下書きの中でいちばん役に立つ欄です。 「歩行の目標について、デイサービスからの報告が今月は1件も無い」と出れば、担当者は評価の前に、何を確かめればよいかが分かります。

4行目がいちばん起きやすい失敗です。 「夜間のトイレの回数が増えた」という家族の話から、AIは原因をもっともらしく書き足そうとします。原因の推測は、記録ではなく診断です。

指示内容を固定する

あなたは居宅介護支援事業所で、介護支援専門員がモニタリング記録を書くための
下書きを作る立場です。渡された記録だけを材料にしてください。推測で補わないでください。

【やること】
ケアプランの短期目標ごとに、今月の記録を次の6つの欄に振り分け、短く要約してください。
1. implementation ... サービスの実施状況（休んだ回とその理由を含む）
2. user_voice ....... 本人の発言
3. family_voice ..... 家族の発言
4. provider_report .. サービス事業所の報告
5. change ........... 前月の記録と比べて変わったこと
6. evidence_gap ..... この目標を振り返るのに、今月の記録に無いこと

【厳守事項】
- 記録に無いことは書かないでください。材料が無い欄は「記録なし」としてください。
- 各記録に付いている speaker（本人／家族／事業所／介護支援専門員）を変えないでください。
  家族の発言を本人の発言の欄に入れないでください。
- 発言は、記録の言葉にできるだけ近い形で書いてください。言い換えて意味を強めないでください。
- 目標が達成できたか、計画を変えるべきかは書かないでください。評価の欄はありません。
- 症状の原因や病状の見通しなど、医学的な解釈を書かないでください。
- 訪問日、面接の相手、面接の方法は書かないでください。別の処理で記入します。
- 要約の各文には、根拠にした記録の record_id を付けてください。
  根拠の記録が無い文は書かないでください。
- どの目標にも当てはまらない記録は unassigned に入れ、無理に目標へ振り分けないでください。
- 前月の記録は比較の材料です。前月の文章を今月の記録として写さないでください。
- 各欄は200字以内を目安にしてください。

【ケアプランの短期目標】{goals}
【今月の記録（record_id・日付・speaker・本文）】{records}
【前月のモニタリング記録】{last_month}

「根拠の記録が無い文は書かない」を明記しないと、つなぎの一文が入ります。 「全体として安定した1か月だった」のような文は読みやすいのですが、どの記録にも根拠がありません。文ごとに record_id を求めると、根拠の無い文は書きようがなくなります。

「言い換えて意味を強めない」も、書かないと起きます。 本人の「ちょっとしんどい」が「強い倦怠感を訴えている」になると、次の月の見立てが変わります。 記録の言葉を残すことを、はっきり求めます。

出力形式を固定する

次の形のJSONで受け取ります。 スキーマは構造化出力の output_config.format に渡します。

{
  "user_ref": "U-0123",
  "month": "2026-09",
  "goals": [
    {
      "goal_id": "G2",
      "goal_text": "",
      "implementation": [{ "text": "", "record_ids": ["R-0456"] }],
      "user_voice": [{ "text": "", "record_ids": [] }],
      "family_voice": [{ "text": "", "record_ids": [] }],
      "provider_report": [{ "text": "", "record_ids": [] }],
      "change": [{ "text": "", "record_ids": [] }],
      "evidence_gap": [""]
    }
  ],
  "unassigned": [{ "text": "", "record_ids": [] }]
}

goals にはケアプランの短期目標の数だけ要素を並べます。材料が無い欄は text に「記録なし」を入れ、record_ids を空にします。

1つ目の理由は、文ごとに根拠の記録を持てることです。 record_ids が付いていれば、担当者は下書きの1文をクリックして元の記録を開けます。根拠が空の文が混ざっていないかは、後段の検査で機械的に見ます。 空の文があれば、その下書きは needs_review として一覧の上に出します。

2つ目は、評価の欄が無いことをスキーマで決められることです。 スキーマに achievement や plan_change の項目を置かないので、AIが評価を書き込む場所がありません。 評価は、様式に流し込んだ後に担当者が書く欄として、別に用意します。

3つ目は、様式への流し込みを固定できることです。 事業所の様式の「実施状況」「本人・家族の意向」「サービス事業所からの情報」「変化」の欄に、JSONの項目をそのまま対応させます。

要は、スキーマで守れることと、指示で守ることを分けることです。 項目の有無や型はスキーマが守り、文字数や言い換えの禁止は指示と後段の検査で守ります。

システムへ連携する

介護ソフトへは書き込みません。 確定した記録を介護ソフトに登録するのは担当者です。自動で登録すると、確認していない下書きが正式な記録として残ります。 記録は運営基準の点検で見られる書類で、後から直すと直した経緯まで問われます。

下書きの一覧には、確認の状態を持たせます。 draft（未確認）、reviewed（担当者が確認）、registered（介護ソフトに登録済み）の3つです。月末に draft のまま残っている利用者が、記録の遅れの候補になります。

人が確認する

担当者は、自分の利用者の下書きを全件読みます。 下書きを使うかどうかは担当者が決め、読まずに登録することはしません。

1. evidence_gap を先に読む … 材料が足りない目標から見ます。足りない材料は、記録を探すか、事業所に問い合わせるかを決めます
2. 発言者を確かめる … user_voice と family_voice の文を、根拠の記録と照らします。本人の発言の欄に家族の言葉が入っていないかを見ます
3. 言い回しを直す … 意味が強まっている箇所、記録の言葉から離れている箇所を直します
4. 評価を書く … 目標の達成度と計画変更の要否を、自分の判断で書きます。ここは下書きに何も書かれていません
5. 介護ソフトに登録する … 確定した記録を登録し、一覧の状態を registered にします

1番目を先にするのは、評価の前に材料をそろえるためです。 材料が足りないまま評価を書くと、下書きが判断の範囲を狭めてしまいます。

管理者は、needs_review と evidence_gap の多い利用者を抜き取りで見ます。 全件を見る必要はありません。材料が足りない利用者が続いていれば、その利用者の事業所との連絡の取り方を見直します。

例外に対処する

テレビ電話装置等の行は、制度の条件に直結します。 令和6年度の改定で、利用者の同意、サービス担当者会議等での主治医や担当者との合意、少なくとも2月に1回は居宅を訪問することなどを要件に、テレビ電話装置等を使ったモニタリングが可能になりました。条件を満たしているかの判断は担当者と管理者が行い、この構成は材料を並べるだけです。

記録を残す

• AIに渡した入力（置き換え後の記録、目標、前月の記録）と、渡した日時
• AIが返したJSONの全文と、使ったスキーマの版
• 担当者が直した後の下書きと、直す前との差分
• 確認の状態（draft ／ reviewed ／ registered）が変わった日時と担当者
• 置き換えの対応表（役割名と実名の対応）は、下書きとは別の場所に、アクセスできる人を絞って保存
• 利用者ごとの evidence_gap の件数の推移

3つ目の差分は、指示を直す材料です。 担当者が毎回同じ種類の言い換えを直しているなら、指示に書き足します。5つ目を別に置くのは、下書きのログだけが漏れても個人が分からないようにするためです。