なぜAIケアプランは現場で使えないのか？DDDとRAGで構築する「制御可能な」自動生成システム

ヘルスケアや介護領域のAI導入には、「AIモデルの性能さえ良ければ、良いケアプランが作れる」という誤解が存在します。

現在、GPT-4o（ChatGPT UIでの提供を終了し、GPT-5.2や推論特化のoシリーズへ移行）やClaude 3といった旧モデルから、より高度な推論能力や複雑な思考プロセスを備えた最新モデルへの移行が進んでいます。また、AIの活用方法自体も、単純なプロンプトによる一問一答から、詳細なコンテキスト指定やタスク分割を伴うエージェント的なワークフローへと進化しています。しかし、最新モデルで完璧な指示を与えても、出力されたケアプランが「教科書的」で、現場のケアマネジャーから「使えない」と判断されるケースは珍しくありません。

理由は明確です。どれほど汎用的な推論能力が向上しても、AIは本質的に「言葉」を確率で繋いでおり、裏にある固有の「介護のロジック（因果関係）」を深く理解しているわけではないからです。アセスメント情報から課題を抽出し、目標を設定して具体的なサービスに落とし込むプロセスは、高度な専門的推論の連続です。これを単なるテキスト生成タスクとして扱うと、個別の利用者の生活実態に即していないプランが生成されるリスクが残ります。

本記事では、この課題を根本から解決するため、ドメイン駆動設計（DDD）のアプローチと生成AI技術を融合させた実践的なシステム構築手法を解説します。プロトタイプを素早く構築して検証を繰り返すアジャイルな思考を取り入れ、プロンプトエンジニアリングだけに依存するのではなく、データ構造とアーキテクチャを根本から整え、制御可能で高品質なケアプラン自動生成システムを目指すための道筋を示します。

対象読者は、介護テック企業のバックエンドエンジニアやDX推進リーダーです。PythonとLLMの基礎知識を前提に、現場で役立つシステムの実装論を論理的に紐解いていきます。

1. アセスメントデータとケアプランの論理構造解析

まず、扱う「ドメイン（領域）」を深く理解する必要があります。AIの論理構造を定義せずに実装を始めるのは、設計図なしに高層ビルを建てるようなものです。まずは本質を見抜き、確固たるデータモデルのプロトタイプを描くことから始めましょう。

LLMが苦手とする「介護の文脈」とは

大規模言語モデル（LLM）は一般的な知識は豊富ですが、特定の利用者の文脈を「行間」から読み取ることは苦手です。

例えば、「独居で転倒歴あり」という情報に対し、一般的なLLMは「手すりの設置」や「見守りサービスの導入」を提案します。しかし、熟練のケアマネジャーなら、転倒が「足腰の弱り」「服薬によるふらつき」「部屋の片付けができていない環境要因」のどれから来ているのかをアセスメント情報全体から読み解き、全く異なるアプローチを提案します。

この「情報Aと情報Bを組み合わせて、隠れた要因Cを特定する」推論プロセスこそが介護の専門性です。これをAIエージェントに再現させるには、入力データを意味のある構造体として渡す必要があります。

ICF（国際生活機能分類）に基づくデータモデリング

ここで有効なのが、ICF（国際生活機能分類）の考え方をデータスキーマに落とし込むことです。ICFは、人間の生活機能を「心身機能・身体構造」「活動」「参加」などの要素と、それに影響を与える「環境因子」「個人因子」の相互作用として捉えるモデルです。

エンジニアの視点で見れば、これは非常に優れたグラフ構造と言えます。

• Node（ノード）: 利用者の状態（麻痺がある、意欲低下、家族同居など）
• Edge（エッジ）: 因果関係（麻痺がある だから 歩行が困難、歩行困難 だから 外出頻度が減る）

アセスメントデータをフラットなテキストではなく、このような関係性を持った構造化データとして定義すべきです。

入力（アセスメント）と出力（第2表）のマッピング戦略

ケアプランの第2表（居宅サービス計画書）を作成するプロセスは、以下のデータ変換パイプラインとして定義できます。

1. Input: アセスメントデータ（主訴、認定調査結果、基本情報など）
2. Transformation (Logic):
   • 生活全般の解決すべき課題（ニーズ）の抽出
   • 長期目標・短期目標の設定
   • サービス内容の選定
3. Output: 第2表フォーマットへのレンダリング

ここで重要なのは、「ニーズ」と「目標」と「サービス」が一貫したストーリー（論理的整合性）で繋がっていることです。AIには、この「繋がり」を意識させる制約を与える必要があります。

2. セキュアで高精度なAIアーキテクチャ設計

論理構造が明確になったところで、実際のシステムアーキテクチャ設計に踏み込みます。要配慮個人情報を扱う介護システムにおいて、最もクリティカルな要件は「厳格なセキュリティの担保」と「ハルシネーション（情報の捏造）の徹底的な抑制」です。この2つの壁を越えなければ、現場で実用化されるシステムにはなり得ません。経営者視点でも、ここは絶対に妥協できないポイントです。

Azure OpenAI vs Bedrock：コンプライアンス視点での選定

機微な介護データを扱う以上、パブリックなAPI（一般的なWebブラウザ経由のAIサービスなど）にデータを直接送信することは、情報漏洩の観点から非常に高いリスクを伴います。

コンシューマー向けのAIサービスは、業務システムとして要求される厳格な統制を適用することが困難です。そのため、企業向けにデータガバナンスが確実に機能するクラウド環境の選定が前提となります。

現時点での有力な選択肢は、MicrosoftのAzure OpenAI、あるいはAWSのAmazon Bedrockです。これらのエンタープライズ向けサービスは、入力されたデータが基盤モデルの再学習に利用されないことが規約で明記されており、VPC（仮想プライベートクラウド）内でのセキュアな閉域網接続も容易に構築できます。

プラットフォーム選定にあたっては、以下のポイントを慎重に評価してください。

• モデルのライフサイクル管理と推奨ワークフロー: 前述の通り、AIモデルの進化と非推奨化のサイクルは非常に早いため、スムーズな移行計画が不可欠です。例えば、Claude 3.5 Sonnetなどの最新モデルを活用する場合、単なる一問一答のプロンプト送信といった古い使い方から、より高度なワークフローへの移行が求められます。システムのガイドライン（コンテキスト）で介護特有の制約を明確に定義し、ケアプラン作成という複雑なタスクを「アセスメントの分析」「課題の抽出」「目標設定」へと分割して計画・実行させるエージェント型の設計を取り入れることで、出力の精度と制御性が飛躍的に高まります。
• データレジデンシー（データの保存場所）: 「データの処理と保存を国内リージョンに限定できるか」という点は、日本の介護現場や監査部門から信頼を得るための絶対条件となります。
• 監査証跡の確保: どのようなプロンプトが送信され、どのような結果が生成されたのか。すべてのログが改ざん不可能な状態で確実に保存され、後から監査できる仕組みが備わっているかを確認します。

RAG（検索拡張生成）の進化：GraphRAGとハイブリッド検索

AIにゼロベースでケアプランを考案させると、実在しない架空の介護サービス名を捏造したり、介護保険の適用外となるプランを作成したりする危険性があります。この致命的なリスクを防ぐためにRAG（Retrieval-Augmented Generation：検索拡張生成）アーキテクチャを採用しますが、単一のベクトル検索に依存する従来の手法では、すでに精度の限界が見え始めています。

現在の技術トレンドは、GraphRAG（グラフRAG）やハイブリッド検索を用いた、より高度な文脈理解への移行です。

初期のRAGは、ドキュメントを単純に断片化（チャンク化）し、意味的な類似度だけで検索を行っていました。しかしこの手法では、断片化された情報同士の「関係性」が欠落してしまいます。一方、GraphRAGではナレッジグラフ（知識グラフ）を構築し、情報と情報のつながりをネットワークとして保持します。これにより、「この疾患を持つ利用者には、どのようなサービスが組み合わされる傾向があるか」といった複雑な関係性を伴うクエリに対しても、精緻な回答を引き出すことが可能です。

実践的なシステム構成案として、以下のアプローチを推奨します。

• 検索方式の高度化: 従来のキーワード検索とベクトル検索を掛け合わせた「ハイブリッド検索」を基盤としつつ、介護報酬改定のルールや事業所独自のノウハウなど、複雑なドメイン知識をグラフ構造で管理するGraphRAGの導入を検討します。
• マルチモーダル対応の組み込み: 実際のケアプラン作成業務では、手書きのアセスメントシートや医療機関からの図表入り情報提供書の読み取りが求められます。最新のRAG構成においては、テキストだけでなく画像や図表も検索対象として統合するマルチモーダル対応が主流になりつつあります。
• Embedding Modelの最適化: 汎用的なモデルではなく、医療・介護領域の専門用語に強いドメイン特化型のモデルや、多言語対応の高性能なEmbedding Modelを選定することで、検索の土台となる品質を底上げします。

「過去に類似の課題を抱えた利用者に対して、どのようなプランが提供され、どのような効果をもたらしたか」という実績データを、関係性を含めてプロンプトに注入することで、AIの生成結果は劇的に安定し、実務に耐えうる水準へと引き上げられます。

個人情報保護（PII）フィルタリングの実装設計

システムアーキテクチャにおいて絶対に欠かせないのが、LLM（大規模言語モデル）へデータを送信する直前での個人情報（PII）マスキング処理です。Microsoftがオープンソースで提供しているPresidioなどのデータ保護ツールをパイプラインに組み込むことで、この要件を自動化できます。

安全なデータ処理パイプラインの流れは、以下のように設計します。

1. User Input（入力受付）: 「特定の利用者名、実年齢、具体的な居住地域」を含む生のケア記録やアセスメントデータを受け取ります。
2. PII Masking（匿名化処理）: 解析エンジンが個人情報を検知し、「、、」などのプレースホルダー（代替文字列）に自動で置換します。
3. LLM Processing（推論実行）: 完全に匿名化された安全な状態のテキストデータのみをクラウド上のLLMに送信し、ケアプランの素案を生成させます。
4. PII Deanonymization（再識別化）: 生成されて戻ってきたテキスト内のプレースホルダーを、システム内部で元の個人情報に復元し、最終的な出力結果としてユーザーに提示します。

LLMの手前にこの堅牢なフィルタリング層を挟み込むことで、万が一クラウド側の設定ミスや予期せぬ挙動が発生した場合でも、個人が特定される重大なセキュリティインシデントのリスクを最小限に封じ込めることが可能です。

3. データ前処理：非構造化テキストの構造化パイプライン

現場のアセスメント記録は、ほとんどが自由記述のテキストです。「右麻痺あり。食事は自力摂取可能だがムセが見られる」といった文章を、システムが扱えるデータに変換します。まずは小さなスクリプトでプロトタイプを作り、挙動を確かめながら進めるのが得策です。

自由記述テキストからのエンティティ抽出（NER）

ここでは、LLM自体を「パーサー（解析器）」として使います。PythonのPydanticライブラリとLangChainを組み合わせることで、テキストから特定のスキーマに沿ったJSONを抽出できます。

以下は、アセスメント情報から利用者の状態を構造化して抽出するためのクラス定義例です。

from typing import List, Optional
from pydantic import BaseModel, Field

# ドメインモデル定義
class HealthCondition(BaseModel):
    condition_name: str = Field(..., description="具体的な症状や状態（例：右片麻痺、嚥下障害）")
    severity: Optional[str] = Field(None, description="重症度や頻度")
    impact_on_adl: Optional[str] = Field(None, description="日常生活動作への影響")

class AssessmentStruct(BaseModel):
    patient_id: str
    physical_conditions: List[HealthCondition] = Field(..., description="身体状況のリスト")
    mental_conditions: List[str] = Field(..., description="精神・心理状態のリスト")
    current_services: List[str] = Field(..., description="現在利用中のサービス")
    caregiver_burden: Optional[str] = Field(None, description="介護者の負担状況")

型を厳格に定義することで、後続の処理で「データが存在しない」「型が違う」といったエラーを防ぐことができます。

LangChain OutputParsersを用いたJSON形式への変換

次に、LangChainを使ってLLMにこのスキーマに従うよう指示します。

from langchain.output_parsers import PydanticOutputParser
from langchain.prompts import PromptTemplate
from langchain_openai import ChatOpenAI

# パーサーの初期化
parser = PydanticOutputParser(pydantic_object=AssessmentStruct)

# プロンプトテンプレート
prompt = PromptTemplate(
    template="Answer the user query.\n{format_instructions}\n{query}\n",
    input_variables=["query"],
    partial_variables={"format_instructions": parser.get_format_instructions()},
)

# チェーンの実行（例）
model = ChatOpenAI(temperature=0, model="ChatGPT")
chain = prompt | model | parser

raw_text = "利用者ID: U12345. 右片麻痺があり、歩行は杖を使用。妻が介護しているが腰痛があり負担を感じている。"
result = chain.invoke({"query": raw_text})

print(result.physical_conditions)
# Output: [HealthCondition(condition_name='右片麻痺', impact_on_adl='歩行は杖を使用'), ...]

このコードにより、曖昧なテキストデータがプログラムで扱いやすいオブジェクトに変換されました。これが「制御可能なAIシステム」の第一歩です。

4. プロンプトエンジニアリング：CoTとFew-Shotの実装

データが構造化できたら、ケアプランの生成ロジックを構築します。単に「プランを作って」と頼むのではなく、熟練ケアマネジャーの思考プロセスを模倣させます。

Chain-of-Thought（思考の連鎖）による推論精度の向上

Chain-of-Thought (CoT) は、AIに「答え」を出す前に「考え方」を出力させる手法です。ケアプラン作成においては、以下のステップを踏ませます。

1. 現状分析: 構造化されたアセスメントデータから、何が問題（生活上の支障）かを特定する。
2. 原因推論: その問題がなぜ起きているのか（身体機能、環境、意欲など）を分析する。
3. 解決策の仮説: どのような支援があれば解決可能か、複数の選択肢を挙げる。
4. プラン策定: 具体的な目標とサービス内容に落とし込む。

プロンプト例（抜粋）：

あなたはベテランのケアマネジャーです。以下の手順で思考し、最終的な第2表案を出力してください。

Step 1: 利用者の「強み（ストレングス）」と「課題（ニーズ）」を洗い出してください。
Step 2: 課題の根本原因をICFの視点で分析してください。
Step 3: 本人の意向を踏まえ、実現可能な長期目標を設定してください。
...

類似症例を動的に挿入するFew-Shot Promptingの実装

さらに精度を高めるのが、Few-Shot Promptingです。RAGを使って検索した「過去の成功事例」をプロンプトに含めます。

参考情報（過去の類似事例）:
事例1: [アセスメント概要] -> [作成されたプラン]
事例2: [アセスメント概要] -> [作成されたプラン]

上記の事例を参考に、今回の利用者に対する最適なプランを作成してください。

これにより、AIは「この事業所らしい書き方」や「地域特有のサービス資源の活用方法」まで模倣できるようになります。

5. 実装チュートリアル：LangChainによる自動生成フロー

これまでの要素を統合し、実際に動作するチェーンを構築します。最新のLangChain (LCEL: LangChain Expression Language) 記法を用いた実装例です。まずは動くものを作り、そこから洗練させていくアプローチを取りましょう。

RetrievalQAチェーンの構築とカスタマイズ

from langchain_core.runnables import RunnablePassthrough
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

# 1. 検索機能（Retriever）の定義
# 事前に構築したVectorStoreからRetrieverを取得
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

# 2. プロンプトテンプレートの定義
system_template = """
あなたは専門的なケアマネジャー支援AIです。
以下のコンテキスト（過去の事例やガイドライン）を参考に、入力されたアセスメント情報に基づいたケアプラン第2表の案を作成してください。

コンテキスト:
{context}
"""

human_template = """
アセスメント情報:
{assessment_data}

出力形式:
- 生活全般の解決すべき課題
- 長期目標（期間）
- 短期目標（期間）
- サービス内容
"""

prompt = ChatPromptTemplate.from_messages([
    ("system", system_template),
    ("human", human_template)
])

# 3. チェーンの構築 (LCEL)
# input -> retriever -> context + input -> prompt -> model -> output
rag_chain = (
    {"context": retriever, "assessment_data": RunnablePassthrough()}
    | prompt
    | model
    | StrOutputParser()
)

# 4. 実行
assessment_text = "...（構造化されたアセスメントデータ）..."
plan_draft = rag_chain.invoke(assessment_text)

print(plan_draft)

このコードはシンプルですが、バックグラウンドではベクトル検索による知識注入と、システムプロンプトによる役割定義が機能しています。実運用では、ここに入力前のPIIマスキング処理や、出力後のJSONパース処理が結合されます。

6. 品質評価とHuman-in-the-Loop（人間参加型）運用

システムが動き出しても、AIが出力したプランが適切かどうかを継続的に評価・改善する仕組みが必要です。技術の本質を見抜き、ビジネス価値へ直結させるためには、この運用フェーズが鍵を握ります。

LLM出力の自動評価指標（Ragas等）の導入

生成されたプランの品質を毎回人間がチェックするのはコストがかかります。開発フェーズでは、Ragas (Retrieval Augmented Generation Assessment) などのフレームワークを用いて自動評価を行います。

• Faithfulness（忠実性）: 生成されたプランが、コンテキスト（ガイドラインや過去事例）に基づいているか。
• Answer Relevance（回答関連性）: アセスメント情報の課題に対して、プランが的確に応えているか。

これらのスコアをモニタリングすることで、プロンプトの修正やモデルのパラメータ調整の効果を定量的に判断できます。

専門職によるフィードバック収集UIの設計

最も重要なのは、現場のケアマネジャーによるフィードバックです。これをHuman-in-the-Loop（人間参加型ループ）と呼びます。

アプリケーションのUIには、AIが生成した案に対して「採用」「修正して採用」「却下」を選択できるボタンと、修正内容を入力できるフィールドを用意してください。

1. AIがドラフトを作成。
2. ケアマネジャーがそれを微修正して完成させる。
3. 「修正後の完成データ」と「元のアセスメントデータ」のペアを保存する。

このデータペアこそが、次世代のAIモデルをファインチューニングするための「宝の山」となります。システムを使えば使うほど、その組織のケア方針に最適化されたAIへと進化していきます。

まとめ

AIによるケアプラン自動生成は、ケアマネジャーの仕事を奪うものではありません。事務的な文書作成作業から解放し、本来注力すべき「利用者との対話」や「深い洞察」に時間を使えるようにするための強力なサポーターです。

今回解説したアプローチを振り返ります。

1. ドメイン駆動設計: 介護の論理構造（ICF）をデータスキーマに落とし込む。
2. セキュアな基盤: 閉域網とPII保護で信頼性を担保する。
3. RAGとCoT: 過去の知見と論理的推論を組み合わせ、ハルシネーションを防ぐ。
4. Human-in-the-Loop: 専門職の修正を学習し、進化し続けるサイクルを作る。

技術的なハードルは決して低くありませんが、これらを実装できたとき、システムは単なる「便利ツール」を超え、介護現場の質を変革するインフラとなるはずです。まずは小さなプロトタイプから始め、現場のフィードバックを取り入れながら、アジャイルにシステムを育てていきましょう。