どうも、AI介護士kazeです。介護現場に18年いながら、最近は自社の業務管理を支える仕組み（Company OS）をAIと一緒に作っています。今日はその中の一つ、施設内の情報共有ツール「ケアつなぐ」の開発方針を、途中で大きく切り替えた話を書きます。
結論から言うと、「自施設専用として作り込んでいた設計を、途中でマスター設定化する方向へ舵を切った」という判断の話です。しかもその気づきは自分でもChatGPTでもなく、独立レビューを頼んだClaudeからの指摘がきっかけでした。
そもそも「ケアつなぐ」は何を作っていたのか
ケアつなぐは、施設内の会議・委員会・食事情報・申し送りといった情報を、職種や役職に応じて出し分けるための社内アプリです。もともとは自分の勤める施設の運用に合わせて設計していました。
具体的には、次のような要素を「前提」としてコードや画面設計に埋め込んでいました。
- 会議の種類（ユニット会議、フロア会議、リーダー会議など、自施設の呼び方そのまま）
- 食事区分（常食・きざみ・ソフト食…といった自施設の分類）
- 情報の公開範囲ルール（誰がどの情報を見られるかの階層）
- 委員会構成（褥瘡、感染、給食など、自施設で動いている委員会そのもの）
ここで正直に書いておくと、AIが勝手にこれらを設計したわけではありません。自分が「うちはこういう会議体で、この情報はこの範囲だけに見せたい」と要件を出し、ChatGPTがそれをコードや画面構成に落とし込む案を返し、実際に動かしてみて「あ、この画面だと管理職しか使えない」みたいなズレを見つけては修正する、という反復でした。
ChatGPTとCOO案は「機能追加優先」だった
ある程度動くようになった段階で、次に何をやるべきかをChatGPTに相談しました。同時に、社内のCOO的な役割の視点でも整理してもらいました。返ってきた提案は、ざっくり言うと「機能追加を優先しよう」という方向でした。
通知機能を強化する、記録の検索性を上げる、モバイル対応を進める──どれももっともな提案で、自施設の中で使い続けるならその順番でよかったと思います。自分もその流れで手を動かし始めていました。
Claudeの独立レビューで出てきた別の指摘
ただ、ここ最近ChatGPTとClaudeを使い分けるようになっていて、大きめの判断のときはClaudeにも別視点でレビューを頼むようにしています。今回もケアつなぐの現状の設計と、これからやろうとしている機能追加の計画を渡して、「この方針の穴を教えて」と投げました。
Claudeから返ってきた指摘は、機能の話ではありませんでした。要約するとこういう内容です。
「会議種類・食事区分・公開範囲ルール・委員会構成が、コードの中に前提として埋め込まれている。今のうちにマスター設定として外に出しておかないと、2施設目に導入するときに作り直しのコストが跳ね上がる」
読んだ瞬間、正直ヒヤッとしました。自分でも頭のどこかで「これ、他の施設で使うとしたら食事区分の呼び方から違うよな」と感じていたのに、目の前の機能追加に気を取られて後回しにしていた部分そのものだったからです。
なぜ自分とChatGPTでは気づけなかったのか
これは反省としてメモしておきたいのですが、自分もChatGPTも「今のケアつなぐをどう良くするか」という文脈で会話を続けていました。前提として自施設の運用がずっと乗っかっているので、その前提自体を疑う問いが出てこなかったんです。
Claudeには「複数施設への横展開を見据えている」という背景も一緒に渡した上でレビューさせたので、設計の抽象度そのものに踏み込んだ指摘が出てきたのだと思います。AIの性能というより、誰にどの前提でレビューを頼むかで、返ってくる指摘のレイヤーが変わるという話です。
方針転換：機能追加より先に「設定で吸収できる形」へ
指摘を受けて、いったん機能追加の手を止めました。そして、コードに埋め込まれていた自施設固有の項目を、マスター設定として管理画面から編集できる形に少しずつ移していく作業を始めました。
ここも一気に置き換えたわけではありません。Claudeにまず「どこから外に出すのが影響範囲が小さいか」を相談し、優先順位の案をもらった上で、自分が実際のデータ構造を見ながら「ここは会議マスターと委員会マスターを分けたほうがいい」といった判断を返し、また修正案を出してもらう、という進め方です。
やっている最中に気づいたこともあります。たとえば公開範囲ルールは、単に「役職マスターを外に出せばいい」という話ではなく、役職の階層構造そのものが施設ごとに違うので、階層の深さ自体を設定で持たせる必要がある、といった話です。こういうのは実際にコードをいじってみて初めて見える部分で、AIに丸投げでは出てこなかったと思います。
「汎用アプリとしての完成」は急がない
もう一つ意識を変えたのが、「汎用アプリとして完璧に仕上げてから2施設目に持っていく」という考え方をやめたことです。全施設のあらゆる運用を今の段階で想像しきるのは無理なので、今後出会う運用差を設定で吸収できる余地を残しながら開発を続ける、というスタンスに切り替えました。
言い換えると、「今すぐ汎用化する」のではなく、「後から汎用化しやすい構造で作り続ける」ということです。マスター化するべきものを見極める感度を持ちながら手を動かす、というのが今の自分の作業モードになっています。
この経験から得た教訓
目の前で動いているものを良くする視点だけでは、将来の作り直しコストは見えません。自分と同じ前提を共有していない相手にレビューを頼むことは、機能を一つ足すより先にやる価値のある作業だと痛感しました。
この記事を書いた人
AI介護士kaze運営者。介護福祉士・ケアマネジャー・社会福祉士の資格を持ち、介護現場歴18年。現場のリアルな課題感を起点に、AI×介護の実用性を探求・発信しています。
コメント