ケアマネジャーが新しい利用者のケアプランを作る前に、仮名にした過去のケアプランとモニタリングの記録から状態像と生活の課題が近い事例を探し、目標とサービスの組み方の例を示す

処理の起点を決める

検索は、ケアマネジャーが画面で実行したときに1回ずつ動きます。 アセスメントを終えて原案に取りかかる前が、使う場面です。事務所に戻ってから使うことを想定し、訪問先のタブレットからは使わせません。 本人や家族の前で過去の事例の画面を開くと、他の利用者の暮らしが見えてしまうからです。

事例の索引は、毎晩介護ソフトの書き出しから作り直します。 その日に確定したケアプランとモニタリングの記録を、仮名加工してから追加します。未確定の原案は索引に入れません。 合意を取る前の原案が、他のケアマネジャーの例として出てくるのを避けるためです。

事例に付けるモニタリングの結果は、月に一度まとめて更新します。 目標の達成の具合は数か月かけて分かるもので、毎日変わるものではありません。

入力データを集める

質を決めるのは、第2表の課題の書き方と、モニタリングの記録の書き方です。 課題が「ADL低下」のように短い言葉だけだと、言葉でも意味でも探せません。「夜間に1人でトイレへ行き、ふらついて転びそうになる」のように、生活の場面で書かれている課題ほど、近い事例が引けます。

モニタリングの記録に「目標ごとの達成の具合」の欄が無い事業所は、そこから始めます。 文章で「おおむね順調」とだけ書かれていると、事例の結果として並べられません。達成・一部達成・未達成・目標を変更、の4つの区分を付ける運用を先に決めます。

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

介護ソフトからは、毎晩CSVで書き出したものを Lambda が読みます。 介護ソフトのデータベースへ直接つなぐことはしません。

アセスメントとケアプランは、作った日で結び付けます。 同じ利用者でも、更新のたびに状態像も課題も変わります。最新のアセスメントを古いケアプランに付けると、状態像と組み方がずれた事例になります。

元の利用者の番号と仮名の番号の対応表は、Lambda の外に置きます。 対応表は情報システムの担当だけが見られる場所に保管し、検索の側からは引けないようにします。 元の記録へのリンクは、閲覧の権限を持つケアマネジャーが介護ソフトの側で開く形にします。

AIへ渡す前に整形する

1. 仮名加工 … 氏名、住所、生年月日、電話番号、家族の氏名、主治医と事業者の名称を外すか置き換えます。年齢は5歳刻みの帯にします
2. 文の中の固有名詞を置き換える … 課題や意向の文に書かれた「長男の○○さん」「△△病院」を、「長男」「入院していた病院」に置き換えます
3. 事例を課題ごとに分ける … 第2表の課題1つと、その目標・サービス内容・モニタリングの結果を1件にします
4. 区分の項目をそろえる … 要介護度、自立度、世帯の状況（独居・高齢者のみ・同居）、主な傷病の区分を、決まった値にそろえます
5. 状態像の文を作る … アセスメントの要点を、決まった並びの短い文にまとめてから、課題の文と合わせてベクトルにします
6. 少ない事例を外す … 特定の地域にしか無い病気や、ごく珍しい家族構成など、数件しか無い状態像は索引に入れないか、区分をまとめます

1番目と2番目の仮名加工は、この構成で最も手間のかかる処理です。 決まった欄の氏名や住所は外せますが、自由に書かれた文の中の固有名詞は、規則だけでは取り切れません。 置き換えの結果を、索引に入れる前に抜き取りで人が確かめます。

6番目を省くと、仮名にしても誰の事例か分かります。 同じ法人のケアマネジャーが読むので、「珍しい病気の独居の90代の男性」というだけで本人が浮かぶことがあります。

AIに処理させる

AIにさせることは2つです。 課題の文と状態像の文をベクトルにすることと、検索で上がった5件の事例を比べて傾向をまとめることです。どの事例を上げるかは、検索の点数と区分の絞り込みで決まります。

検索は、hybrid クエリに次の3つを入れます。 全体にかける filter には、要介護度（前後1段階まで）、認知症の日常生活自立度、世帯の状況を入れます。句の1つ目は、Sudachi で解析した課題の文への match、2つ目は状態像と課題のベクトルへの k-NN です。重みは言葉の句を0.3、意味の句を0.7から始めます。 言葉の句を軽くしすぎると、「福祉用具」「訪問看護」のようにケアマネジャーが確実に一致させたい言葉が外れます。

まとめは、Claude に検索結果のブロックとして渡します。 検索結果のブロックは、自分の文書を出典付きで引用させるための形で、source と title と本文の content を持ちます。引用を有効にするかどうかは、1回の依頼の中の全部の検索結果でそろえる必要があり、混ぜると誤りになります。 事例の番号を source に入れ、まとめの一文ずつがどの事例から来たかを画面に出します。

まとめで比べさせるのは、5件の間の共通点と違いだけです。 「5件中4件で、短期目標に夜間のトイレの動作を置き、福祉用具の貸与と訪問リハビリを組んでいる」「残る1件は家族の介護の負担を先に課題に置き、短期入所を組んでいる」のような整理です。新しい利用者に何を勧めるかは書かせません。

1行目がいちばん起きやすい失敗です。 5件の傾向をまとめさせると、生成AIは自然に「この方にも〜を検討するとよいでしょう」と書き足します。一文でも勧める言い方が入ると、経験の浅いケアマネジャーほどそれを原案の起点にします。 指示で禁じ、後段でも言い回しを検知します。

指示内容を固定する

あなたは居宅介護支援事業所で、ケアマネジャーが過去の事例を読むのを手伝う立場です。
渡す検索結果（過去の事例）だけを根拠に、まとめを書いてください。

【渡すもの】
- 今回の利用者の状態像の要点（区分の項目と、生活の課題の文）
- 過去の事例 最大5件（検索結果のブロック。source は事例の番号）
  各事例：状態像の要点／生活全般の解決すべき課題／長期目標／短期目標／
          サービス内容と種別・頻度／モニタリングでの目標の達成の具合と変更

【書くこと】
1. 5件の事例で、課題をどう書いているかの共通点と違い
2. 目標（長期・短期）の立て方の共通点と違い
3. サービスの組み方（種別と頻度）の共通点と違い
4. モニタリングで目標が「未達成」「目標を変更」となった事例で、記録に書かれている変更の内容
5. 今回の利用者の状態像と、各事例の状態像の違い（区分の項目と課題の文から分かる範囲）

【厳守事項】
- 今回の利用者に、どの目標やサービスがよいかを書かないでください。
  「検討するとよい」「おすすめです」「望ましい」のような勧める言い方をしないでください。
- 事例に書かれていないことを補わないでください。記録に無ければ「記録に無い」と書いてください。
- 目標が達成された・されなかった理由を推し量らないでください。
  記録に理由が書かれている場合だけ、その記録を引用してください。
- 事例を良い・悪いで評価しないでください。
- 事例の利用者が誰かを推し量る書き方をしないでください。
- 医学的な判断（病状の見通し、薬の効果など）を書かないでください。
- 5件のうち、今回の利用者と区分が大きく違う事例があれば、最初にそのことを書いてください。

【今回の利用者の状態像の要点】{query_profile}

「勧める言い方をしない」に、具体的な言い回しを並べているのには理由があります。 「提案しない」とだけ書くと、「〜という選択肢もあります」と言い方を変えて同じことを書きます。禁じたい言い回しを例として並べ、後段の検知の一覧と同じ言葉にそろえます。

「区分が大きく違う事例を最初に書く」は、検索の側の限界への備えです。 絞り込みで要介護度を前後1段階まで広げているので、区分の境目にいる利用者では、状態がかなり違う事例が混ざります。 読む人がそれに最初に気づけるようにします。

出力形式を固定する

画面に出すのは、事例の一覧とまとめの2つです。 事例の一覧は検索結果から Lambda が組み立て、まとめは Claude の引用付きの文をそのまま出します。

{
  "search_id": "CS-2026-1008-031",
  "query_profile": {
    "care_level": "要介護2",
    "dementia_independence": "IIa",
    "household": "独居",
    "main_condition_class": "脳血管疾患",
    "assessment_reason": "退院・退所",
    "need_text": "夜間に1人でトイレへ行き、ふらついて転びそうになる"
  },
  "cases": [
    {
      "case_id": "C-00412-03",
      "score": 0.00,
      "profile_diff": ["要介護度が1段階重い"],
      "need": "",
      "long_term_goal": "",
      "short_term_goal": "",
      "services": [ { "type": "", "frequency": "" } ],
      "monitoring": { "status": "achieved | partly | not_achieved | changed", "note": "" }
    }
  ],
  "summary": [ { "text": "", "cited_case_ids": [] } ],
  "flags": []
}

1つ目の理由は、profile_diff で事例と今回の利用者の違いを先に見せられることです。 検索の点数が高くても、要介護度や世帯の状況が違えば読み方が変わります。違いを区分の項目で機械的に並べ、読む前に目に入るようにします。

2つ目は、monitoring.status を区分で持つことです。 事例の一覧を「達成」「未達成」「目標を変更」で並べ替えたり、色を分けたりできます。うまくいかなかった事例ほど、読む価値があることが多いからです。

3つ目は、summary の一文ずつに cited_case_ids が付くことです。 まとめのどの文がどの事例から来たかが分かり、引用の無い文は画面で印を付けます。 引用の無い文は、検索結果の外から来た文だからです。

システムへ連携する

介護ソフトへは書き込みません。 検索の結果を原案に取り込むボタンも作りません。事例から写すのではなく、自分のアセスメントから書き起こす手順を守るためです。

元の記録は、介護ソフトの側で開きます。 検索の画面には仮名の番号しか出しません。主任ケアマネジャーなど、他の事業所の利用者を見る権限を持つ人だけが、対応表を通じて元の記録を開けるようにします。

人が確認する

ケアマネジャーは、事例の一覧を先に、まとめを後に読みます。

1. profile_diff を見る … 今回の利用者と区分が違う事例を、読み方を変えて読みます
2. 事例の第2表とモニタリングの結果を読む … 少なくとも上位3件は、まとめではなく事例そのものを読みます
3. まとめを読む … 引用の無い文と、勧める言い方が検知された文には印が付いています
4. 自分のアセスメントに戻る … 本人と家族の意向から原案を書き起こします
5. 迷うときは事例を添えて主任に相談する … 相談の結果を、検索の記録に一言残します

2番目を省かないでください。 まとめは5件の共通点を拾うので、1件だけにあった工夫が落ちます。その1件の工夫が、今回の利用者に一番近いことがあります。

目標は、90件をならして1件14分です。 状態像がはっきりした利用者は事例を数件読んで10分前後で済み、区分の境目にいる利用者や事例の少ない状態像では、主任への相談を含めて20分以上かかります。

例外に対処する

2行目で、無理に事例を出さないことが大事です。 状態像が珍しい利用者ほど、遠い事例を似ているものとして読んでしまいます。事例が少ないこと自体が、主任に相談すべきという合図です。

記録を残す

• 検索の日時、検索した人、検索の条件（仮名の状態像の要点）
• 上がった事例の番号と点数、絞り込みを広げたかどうか
• Claude に渡した事例と、返ってきたまとめ、引用の対応
• 勧める言い方の検知と、引用の無い文の記録
• ケアマネジャーが残した一言（主任に相談したか、どの事例が役に立ったか）
• 仮名加工の抜き取りの確認の結果と、置き換えの規則の版

「どの事例が役に立ったか」の一言は、重みの見直しに使います。 役に立ったと書かれた事例が下位に多いなら、言葉の句と意味の句の重みが合っていません。

検索の記録には、元の利用者を特定できる情報を入れません。 検索の条件は仮名の状態像の要点だけにし、今回の利用者の氏名や番号は残しません。