書類の書き直しをなくす？！AIへの「捏造厳禁」で気づいたプロンプトの罠

AIに「安全」を求めすぎた結果

こんにちは！「Lily∞Care」を開発している、えーちゃんです。 コードは1行も書けないのですが、「何を作るか」「なぜ作るか」を決めるのが自分の仕事。１人の構想とAIという実行力で、現場の声を拾い「こうあるべき姿」を設計しています。余計な工程を省き、思考と実装を直結させながら、目の前の課題を一つずつ過去のものにしていく。Lily∞シリーズを１人で企画・設計・運営しています。

さて、介護業界未経験の私がアプリを開発していく中で、いつも「へえ！」と驚かされるのが、書類によって求められる「文体」や「視点」の違いです。

以前、「書類の間違い探しは限界？！AIでサ責の「超人力」を解放する」というテーマでも触れましたが、今回は「ケアプラン」と「サ責（サービス提供責任者）のアセスメント」の文体の違いと、それをAIでどう乗り越えたかについてお話しします。

ケアマネ文体とサ責文体の大きな壁

最近、ケアプランから抽出したアセスメント情報を、AIを使ってサ責視点の文章に自動変換する機能を追加しました。

なぜこんな機能を作ったか。それは、同じ利用者の情報を扱っていても、ケアプランとサ責のアセスメントでは文章の役割が全く違うからです。

ケアプランはケアマネジャーさんが書く計画書なので、「〜を支援する」「〜の充実を図る」といった「計画・方針的な文体」になります。 一方、サ責さんが作成するアセスメントで求められるのは、現在の状態や観察に基づいた事実です。「〜が困難」「〜は自立」「〜に介助が必要」という書き方になります。

つまり、ケアプランの内容をAIでただ抽出するだけでは、ケアマネ文体のままで出力されてしまい、結局サ責さんが「〜が困難」という文体に全部書き直す必要があったのです。これでは全く業務の負担軽減になりません。

そこで、抽出と同時に「サ責文体」に自動変換するようAIのプロンプト（指示）を組んでみました。

「実態と乖離するのは困る、でも踏み込んでほしい」葛藤

初期バージョンを現場で試してもらったところ、こんな率直な反応が返ってきました。

「現場感が物足りない気もするんだけど、まあいい塩梅な気もする。わざわざ翻訳し直す必要はあるかなっていうレベル。ただ、これ以上話を飛躍させると実態と乖離しすぎると困る。でも、こういう症状だったらこうだろうなっていうのはだいたい想像がつくものだったら、もっと踏み込んで書いた方がいい気もする」

現場の生々しい葛藤です。AIが勝手に想像を膨らませて嘘を書いてしまう（ハルシネーション）のは絶対に避けたい。でも、あまりに無難すぎると役に立たない。

実際、初期のアウトプットは「入浴動作の全工程において介助が必要な状態」といった、やたらと抽象的で薄っぺらい文章になっていました。

「なぜこんなに薄っぺらいのか？」と原因を探ると、私がプロンプトに書いた「情報の捏造は厳禁」という強い制約が原因でした。AI（今回はGemini 3 Flashを使用しています）に対して安全側に振りすぎた指示を出した結果、AIが萎縮してしまい、当たり障りのない抽象的な表現しか出さなくなっていたのです。

同じモデルを使って指示書を翻訳する別の機能では、「浴槽またぎが困難」「右下肢の支持性不足」といった具体的な出力ができていたので、これはAIの能力不足ではなく、完全に私の指示の出し方の問題でした。

例示か、ルールか。AIに「思考プロセス」を教える

では、どうやって「安全を担保しながら、具体的に踏み込んだ文章」を書かせるか。

プロンプトの改善にあたり、2つの案で悩みました。 B案は「脳梗塞後遺症・右片麻痺であれば右上肢の巧緻性低下……」のように、疾患別の例をプロンプトにたくさん書いて教える方法。 A案は「疾患・要介護度・福祉用具から臨床的に妥当な推論で具体化せよ」と、思考プロセスそのものを教える方法です。

B案のように特定の例を追加しようとしたとき、現場から鋭い指摘がありました。 「その例しか適用されないってことはないですかね？汎用化しないとキツそう」

その通りです。パーキンソン病、認知症、大腿骨骨折後……介護現場で出会うケースは無数にあり、すべてを例示することは不可能です。プロンプトが無限に長くなり、トークンコストも跳ね上がってしまいます。

そこで採用したのが、A案の「思考プロセスを教える」というアプローチです。 AIに対して「麻痺がある場合は、健側と患側の機能差に注目する」「歩行器を使用している場合は、支持性の状況をベースに書く」といったように、「どういう視点で具体化すればいいか」という状況ベースの推論ルールを教え込みました。

結果として、このアプローチは大成功でした。疾患を問わず、様々なケースに対して汎用的に「サ責視点のアセスメント」を出力できるようになったのです。

以前、「2回目の書類でデータ消える？！AI入力で「統合」を選んだ理由」というテーマでAIへの指示の出し方について触れた際もそうでしたが、LLM（大規模言語モデル）に具体化を求めるときは、「この入力にはこう出力しろ」というパターンを覚えさせるよりも、「こういう思考プロセスで具体化しろ」と思考の枠組みを教える方が、圧倒的に汎用性が高くなります。

業界の外からだからこそ見える「面倒くささ」を潰す

ケアマネの文章と、サ責の文章。同じ利用者の状態を共有しているのに、立場が違うだけで書き直さなければならない。業界に長くいると「そういうものだ」と受け入れてしまうかもしれませんが、外から来た私にとっては「なんで同じことを二度書くんだろう？」と不思議で仕方ありませんでした。

コードは書けなくても、「何を作るか」「なぜ作るか」をとことん考え抜き、AIと一緒に実装して検証する。現場からの「これ以上飛躍すると困るけど、もっと踏み込んでほしい」という絶妙な要求に、思考プロセスの設計で応えていく。

これからも、そんな「現場の理想の塩梅」を一つずつ形にしていきたいと思います。