2回目の書類でデータ消える？！AI入力で「統合」を選んだ理由

介護現場の情報は「一度」では揃わない

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

さて、介護記録AI支援アプリを作る中で、利用者さんの登録作業は現場の大きな負担だと感じていました。そこで、**「書類をドラッグ＆ドロップ（D&D）したら、AIが内容を読み取って自動入力してくれる機能」**を開発しました。

「これで究極の入力簡略化だ！」と喜んでいたのですが……介護業界の業務の流れを知るうちに、これだけでは不十分なことに気づきました。

現場では、情報が最初から完璧な状態で届くわけではないのですね。最初はケアマネジャーさんからざっくりとしたFAXが届き、後になって正式なケアプランの書類が届く、といったように「段階的」に情報がやってきます。

もし、2回目の書類をシステムにD&Dした時、1回目で入力・修正した情報が単純に上書きされて消えてしまったら？ せっかく入力したデータが消えるシステムなんて、現場では絶対に使い物になりません。

「上書き」ではなく「統合」するスマートマージ

そこで、単なる自動入力ではなく、すでにフォームに入力されている値と新しい書類の情報を賢く合わせる「スマートマージ」の仕組みを作ることにしました。

具体的には、入力項目（フィールド）を2つの性質に分類して対応しました。

1. 確定値フィールド（名前、生年月日、住所など） これらは途中で変わるものではないため、「すでに入力済みなら上書きしない」というルールにしました。
2. 記述フィールド（身体状況、疾患など） ここは新しい情報が追加されることが多い部分です。「既存の身体状況」と「新しい書類に書かれた身体状況」の両方を読み込み、AIに自然な文章として統合させることにしました。

丁寧な指示は邪魔？！介護記録フォームを「引き算」で再設計した話でも触れましたが、現場が求めているのは「マニュアル不要で、考える手間が省けるUI」です。

開発中、この文章の統合をシステム側（プログラム）で処理するか、AIへの指示（プロンプト）で処理するか迷いました。しかし、2つの異なる文章を繋ぎ合わせて自然な日本語の文章にするのは、まさにAIにしかできない芸当です。そこで、プロンプト1発で「書類からの情報抽出」と「既存情報とのマージ」を同時にやってもらう設計にしました。

開発の裏側：AIとデータベースの罠にハマる

機能の構想は良かったのですが、実装の裏側ではAIやシステム特有の罠にいくつもハマりました。

1. デフォルト値が邪魔をする

要介護度の項目（careLevel）に、システムの仕様で初期値として「要介護1」が入るようになっていました。すると、AIがこの「要介護1」を「ユーザーがすでに入力した既存値」だと勘違いし、新しい書類に「要介護3」と書いてあっても、既存値を優先して無視してしまう問題が発生しました。初期値（デフォルト値）と、人間が意図して入力した値を明確に区別してAIに伝える必要がありました。

2. 空白の処理でエラー連発

生年月日などの日付（DATE型）の項目で、書類に記載がなく空文字のままデータベース（PostgreSQL）に送るとエラー（invalid input syntax for type date）になってしまいました。空文字は「Null（空っぽというデータ）」に変換して送る処理（|| null）が必要なのですが、認定有効期間の終了日（certificationEndDate）でその処理を見落としていました。

3. 入力中のデータが吹き飛ぶ恐怖

開発中に一番焦ったのがこれです。システムの裏側（Supabase）でセキュリティトークンが更新される際、ユーザーのプロフィール情報を再読み込みする処理を入れていました。しかし、通信が不安定な時にここでエラーが起きると、システムが「ユーザー情報が空（null）になった」と判定してしまい、入力中のフォーム画面ごと強制的に閉じてしまう（アンマウントされる）現象が起きました。入力データがすべて消失するという恐ろしいバグです。トークン更新時のプロフィール再読み込みは不要だと判断し、処理を削ることで解決しました。

余談ですが、エラーの記録方法にも学びがありました。console.errorを使うとNext.jsの開発画面でド派手なエラー画面（オーバーレイ）が発火してしまいます。システムが回復可能な軽いエラーにはconsole.warnを使うべきだと気づきました。

4. データベースの「無限ループ」

組織ごとのデータ管理の裏側でもトラブルがありました。データベースの閲覧権限（RLSポリシー）を設定する際、「組織（organizations）」の設定が「メンバー（org_members）」を参照し、逆に「メンバー」の設定が「組織」を参照するという状態になっていました。 お互いがお互いを確認し合うため、データベースから「無限ループが発生している（infinite recursion detected）」と怒られてしまったのです。最終的に、ユーザープロフィールという第三のテーブル（user_profiles.organization_id）を基準にすることで、この循環を断ち切りました。 サ責の裏技から事業所の公式ツールへ？！アプリを個人用から作り直した理由でお話しした組織単位のシステム再設計の裏側では、こうした地道な権限設定の格闘がありました。

目の前の課題を、一つずつ過去のものに

書類周りの業務は、とにかく確認と転記の手間がかかります。 書類の間違い探しは限界？！AIでサ責の「超人力」を解放するという記事でも書いたように、AIの力を使ってこうした事務負担を少しでも減らしたいと本気で思っています。

今回追加した「AI自動入力＆スマートマージ」機能も、現場の「情報が段階的に届く」というリアルな事情を知らなければ、ただの上書きツールとして現場に迷惑をかけるところでした。

業界の外から来た私だからこそ、先入観を持たずに「こうあるべき」を素直にシステムに落とし込んでいけるのかもしれません。これからも、現場の皆さんが抱える目の前の課題を、一つずつ過去のものにしていきます。