ケアマネジャーが作ったケアプランの原案をアセスメントと照らし、抜けている課題と表現の確認点を返す

処理の起点を決める

担当者が点検用のフォルダにファイルを置いたことを起点にします。 介護ソフトのステータスを外から読む方法は製品ごとに違うため、この構成では書き出しと保存を担当者の操作にしています。Google Apps Script の時間主導のトリガーで15分ごとにフォルダを見て、新しいファイルの組がそろったものから処理します。

1件の点検に必要なファイルは4つです。アセスメント、第1表、第2表、支援経過がそろうまでは処理を始めません。1つでも欠けた状態で動かすと、支援経過に書かれている「取り上げない理由」が見えず、抜けでない課題を抜けとして返すことになります。

処理が終わった組は処理済みのフォルダへ移します。移すのは点検結果の書き出しまで成功したときだけです。 点検用フォルダに残っている組の数が、そのまま点検待ちの数になります。

入力データを集める

質を決めるのは支援経過と点検基準です。 支援経過が無いと「本人が口腔の訪問を断った」という記録が見えず、口腔の課題を抜けとして挙げます。点検基準が無いと、AIは一般論で「もっと具体的に」と言うだけになり、2名の点検者の基準をそろえるという目的が果たせません。

点検基準には、事業所で実際に返している指摘を集めます。 「安心して暮らせる」「見守る」のように具体性の無い目標の言い回し、「〜させる」のように主語が事業者側になった書き方、略語や専門用語。過去半年の付箋を集めるだけで、20〜30項目の一覧になります。

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

介護ソフトからの書き出しは、PDFかCSVのどちらかで行います。Claude API は PDF をそのまま読めますが、CSV で出せるならそちらを優先します。 表の行と列が崩れず、第2表のどの行のどの欄かを番号で指せるからです。

PDFしか出せないソフトでも構成は組めます。 ただし表が画像のように書き出される帳票では、行の区切りが読み違えられることがあります。最初の10件は、第2表の行数が元の画面と合っているかを人が見ます。

AIへ渡す前に整形する

1. ファイルの組の確認 … 4つのファイルが同じ利用者のものかを、利用者番号で確かめます
2. 個人を特定する情報の置き換え … 氏名、住所、電話番号、家族の氏名を「本人」「長女」「A事業所」のような記号にします。置き換えの対応表は事業所の中だけに置きます
3. 項目番号と行番号の付与 … アセスメントは標準項目の番号（1〜23）、第2表は行番号、支援経過は記録番号を振ります
4. 規則で見られるものを先に見る … 短期目標の期間が長期目標の期間を超えていないか、期間が認定の有効期間に収まっているか、サービス種別・頻度の欄が空いていないかを、プログラムが確かめます
5. 支援経過の絞り込み … 直近3か月分に絞り、長すぎる場合は古いものから落とします

4番目をAIにさせないのは意図してのことです。 日付の前後や空欄はプログラムで確実に見られます。AIに任せると、たまに見落とすか、計算を誤ります。 AIには、文章を読まなければ分からないことだけを渡します。

5番目で直近3か月に絞るのは、古い記録が今の判断を引きずらないようにするためです。 退院前の記録には「歩行は不可」と書かれていても、今は杖で歩けていることがあります。古い記録を渡すと、すでに解決した課題を抜けとして挙げます。 今回のアセスメントの理由が「退院」のときは、退院日より前の記録を落とします。

2番目は、外へ出す情報を減らすためです。 心身の状態や病歴は要配慮個人情報で、置き換えても内容は残ります。氏名と連絡先を外すのは最低限の手当てで、これで外部に出してよくなるわけではありません。 扱いは第13章で書きます。

AIに処理させる

させるのは、3種類の確認点を根拠付きで挙げることだけです。

右端の列のうち、いちばん大事なのは「取り上げない理由があるか」です。 理由が支援経過に見つかれば reason_found、見つからなければ reason_not_found とします。前者は参考として一覧の下に、後者は確認してほしい点として上に並べます。

3行目を禁じるのがいちばん効きます。 全文の書き直しを出させると、担当者は読まずに貼り替えます。返すのは確認点と、1行ずつの言い換えの例までにします。

指示内容を固定する

あなたは居宅介護支援事業所で、ケアプランの原案を会議の前に点検する立場です。
渡された記録だけを根拠にしてください。記録に無いことを推測で補わないでください。

【点検すること】
A. アセスメントで支障や困りごとが書かれている項目のうち、
   第2表のどのニーズにも対応していないもの
B. 第2表の目標・期間・サービス内容の書き方の確認点
C. 第1表の意向・総合的な援助の方針の書き方の確認点

【Aの扱い】
- 対応していない項目を見つけたら、支援経過に「取り上げない理由」が
  書かれているかを探してください。
- 理由が見つかれば reason_found、見つからなければ reason_not_found とし、
  理由の文を reason_quote にそのまま写してください。
- 見つからないことを「おそらく本人が望まない」などと補わないでください。

【Bの見方】
- 目標が抽象的な言葉だけで、達成したかを確かめられないものを挙げる
- 短期目標が長期目標に向かう段階になっていないものを挙げる
- サービス内容が短期目標と対応していない行を挙げる
- 家族による援助が書かれていない行は「確認」として挙げる
- 福祉用具を位置付けた行で、必要な理由が読み取れないものを挙げる
- 言い換えの例は1行で出し、元の意図を変えないこと

【厳守事項】
- evidence には、根拠にした文を元の記録からそのまま写してください。
  要約したり言い換えたりしないでください。
- どのサービスを入れるべきか、どの課題を優先すべきかは書かないでください。
- 原案の全文を書き直さないでください。
- 期間・日付の計算はしないでください（別の仕組みで確かめています）。
- 判断がつかないものは severity を check にしてください。

【事業所の点検基準】{facility_rules}
【アセスメント（項目番号付き）】{assessment}
【第1表】{plan_1}
【第2表（行番号付き）】{plan_2}
【支援経過（記録番号付き）】{progress_notes}

「見つからないことを補わない」を書かないと、理由を作ります。 支援経過に何も無くても、「本人の意向により」と書いて reason_found にしてしまいます。理由は記録から写すものに限り、写せなければ無いものとして扱わせます。

「期間の計算はしない」と書くのは、前処理で見ているからです。 書かないと、AIも期間を計算して、プログラムと違う結果を出すことがあります。同じことを2か所で判定させないのが、結果を読みやすくするこつです。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "case_id": "",
  "assessment_reason": "初回 | 更新 | 区分変更 | 退院 | その他",
  "uncovered_items": [
    { "item_no": 0, "item_name": "", "evidence": "",
      "reason_status": "reason_found | reason_not_found",
      "reason_quote": "", "reason_record_no": "" }
  ],
  "writing_points": [
    { "table": "1 | 2", "row": "", "category": "goal_abstract | goal_step | service_link | family_support | equipment_reason | intention_mixed | policy_link | wording",
      "severity": "fix | check", "evidence": "", "comment": "", "suggestion": "" }
  ]
}

1つ目の理由は、抜けと書き方を分けて受け取れることです。 uncovered_items は担当者が利用者と話して決め直すことが多く、writing_points は担当者がその場で直せることが多いものです。一覧でも別の欄に並べ、読む順を分けます。

2つ目は、evidence を機械で照合できることです。 AIが写した根拠の文が、元の記録に文字どおりあるかをプログラムが確かめます。見つからない指摘は「根拠未確認」として一覧の最後に回し、そのまま担当者には見せません。 根拠の無い指摘を見せると、担当者はAIの指摘全体を信用しなくなります。

3つ目は、category で傾向が数えられることです。 担当者ごとに goal_abstract が多い、family_support が多い、と分かれば、主任介護支援専門員の個別の助言がそこに絞れます。

システムへ連携する

介護ソフトへは書き込みません。 点検結果を介護ソフトに取り込むと、AIの指摘が記録の一部に見えてしまいます。記録に残すのは、担当者が直した原案と、会議の記録だけです。

通知の本文に利用者の情報を書かないのも、同じ考えです。 メールは転送されます。リンク先は事業所のアカウントでしか開けない場所に置きます。

人が確認する

AIの指摘は、すべて人が読んでから使います。 そのまま担当者へ「直してください」と返す運用にはしません。

1. 担当者が先に読む … 指摘ごとに「直した」「直さない（理由）」「分からない」を書きます
2. reason_not_found は必ず答える … 取り上げない理由が記録に無かったものです。理由があるなら支援経過に書き足し、無いなら計画に入れるかを考えます
3. 主任介護支援専門員が返事を読む … 「直さない」の理由が妥当か、「分からない」に助言が要るかを見ます
4. 気になった行だけ原案に戻る … 原案を最初から読み直すのは、新人の初回の計画と、指摘が10件を超えたものに限ります

2番目を飛ばさないでください。 アセスメントで拾った課題を計画で取り上げないこと自体は誤りではありませんが、理由が記録に無いと、後から見た人には抜けと区別がつきません。 運営指導で問われるのもここです。

主任介護支援専門員の1件あたりの時間は、指摘と返事を読む数分が中心です。 担当者の返事を見て問題がなければ、原案を開かずに終わります。

「分からない」と返ってきた指摘は、助言の機会として扱います。 たとえば「口腔内の状況に義歯の破損とあるが、どのニーズにも対応していない」という指摘に担当者が答えられないときは、アセスメントの取り方そのものに迷いがあることが多いものです。その場で主任介護支援専門員が一緒に記録を読み、どう聞き取るかを話します。 付箋で返していたころには、この会話が生まれる場所がありませんでした。

例外に対処する

最後の行は、送る前に見ます。 家族の名前、近所の人の名前、かかりつけ医の名前は、置き換え表から漏れやすい語です。漏れを見つけたら処理を止め、置き換え表に足してからやり直します。

記録を残す

• 書き出したファイルの名前と日時（置き換え前のファイルは事業所の中だけに置く）
• Claude API に送った内容（置き換え後）と返ってきたJSON
• 規則チェックの結果
• 担当者の返事（直した／直さない理由／分からない）と、主任介護支援専門員のコメント
• 根拠未確認になった指摘の件数
• 使った点検基準の版

4つ目がいちばん役に立つログです。 「直さない」の理由が積み重なると、AIがくり返し外す指摘の型が見えます。 その型を点検基準に「指摘しない例」として書き足すと、翌月から指摘が減ります。

点検基準の版を残すのは、基準が変わるからです。 通知の改正や事業所の方針で基準を直すと、同じ原案でも指摘が変わります。いつの基準で見たかが分からないと、過去の点検結果を比べられません。