「情報の設計図」介護DX、その個人情報の扱い大丈夫ですか?
介護DXは「便利なツールを入れる」だけでは進まない
私はこれまで介護・福祉の現場で実務に携わってきました。現在は職業訓練で業務改善やシステム開発、AI活用について学んでいます。現場にいた側と、いま技術を学んでいる側、その両方の目線から介護DXについて考えてみると、便利なツールを導入するだけでは解決できない問題が見えてきました。
介護現場のDXやAI活用について、「何ができるのか」「どこから始めればいいのか」という情報は、ここ数年で急速に増えています。
記録のデジタル化、申し送りや情報共有、ヒヤリハット・事故報告、シフトや勤怠、集計、請求業務、会議資料の作成。さらに生成AIを使えば、文章の整理や要約、報告書の下書き、蓄積されたデータの分析など、これまで人が時間をかけて行ってきた仕事のかなりの部分を支援できるようになっています。
国もこの方向を明確に進めています。
厚生労働省は、介護分野の「生産性向上」を単なる人員削減ではなく、「一人でも多くの利用者に質の高いケアを届ける」ための取組と位置づけ、ICTや介護テクノロジーの導入をマネジメントする「デジタル中核人材」の養成を進めています。
デジタル庁も、ICTや介護ロボット等を活用して業務効率化を進め、そこで生まれた時間を直接的なケアへ振り向けることで、「介護人材の定着」と「介護サービスの質の向上」につなげる考え方を示しています。
2040年には約57万人の介護人材が新たに必要になるという推計も、この政策を急ぐ背景にあります。
しかし、ここに介護DXの難しさがあります。
今はGoogle Workspace、Microsoft 365、LINE WORKSなどのクラウドサービス、ノーコードツール、生成AIを組み合わせれば、小規模な事業所でもかなりの業務改善ができます。
以前なら外部の開発会社に依頼しなければ作れなかった仕組みでも、AIに相談しながらGoogleフォームやスプレッドシート、GASなどを組み合わせ、現場の職員自身が作ることさえ可能になりました。
これは大きな前進です。
一方で、介護事業所が扱う情報には、利用者氏名、住所、顔写真、障害や疾病、服薬、家族情報、日々の支援内容、事故の状況、さらに虐待、不正、公益通報、その証拠となる写真や記録まで含まれることがあります。
業務を便利にしようとすると、同時に非常に機微性の高い一次情報をどう扱うのかという問題が必ずついてきます。
厚生労働省の生産性向上に関する資料でも、情報共有について「何を、誰に、いつ共有するのか」だけでなく、緊急度、重要度、個人情報の有無などに応じて、適切な共有手段を検討しルール化することが示されています。
「紙をGoogleフォームに変える」
「LINEで写真を共有する」
「AIに記録を入れて文章を整理する」
どれも便利な方法です。
ただし、その情報を最初にどこへ入れるのかまで設計しなければ、業務効率化と引き換えに情報管理のリスクを広げることがあります。
小規模事業所にとってのハードル
大規模法人であれば、情報システム部門を置き、ITコンサルタント、システムエンジニア、セキュリティ専門家などに設計・構築・保守を依頼することもできます。
しかし、小規模な介護事業所では簡単ではありません。
システムの初期構築費だけでなく、ライセンス料、クラウド利用料、端末管理、保守、セキュリティ対策、障害対応などの費用は継続的に発生します。
そのため、「できるところから自分たちで」となりやすい。
それ自体は悪いことではありません。むしろ、現場を最もよく知っている人が業務改善に関わることは重要です。
問題は、システム全体の設計図がないまま、仕組みを順番に継ぎ足していくことです。
フォームを作る。
通知を自動化する。
写真も添付できるようにする。
AIもつなぐ。
その後になって、「これは個人情報だから保存先を分けよう」「アクセスログが必要だった」「退職者の権限はどうする」「バックアップは」「虐待通報は管理者からも分離しなければならない」と条件が増えていく。
こうなると、小さな業務改善だったものが、後になってシステム全体の改修につながります。
制度やガイドラインが変わるたびに作り直す構造では、長期的なコストも高くなります。
実装より先に「情報の設計図」が必要になる
介護DXを考えるとき、最初に決めるべきなのは、
「Google Workspaceを使うか」
「LINE WORKSを使うか」
「どのAIを使うか」
ではありません。
先に考えるのは、
どの情報を、どこで受け取るのか。
どこに原本を保存するのか。
誰がアクセスできるのか。
何を共有用データとして切り出すのか。
何を外部クラウドへ渡さないのか。
AIには何を渡してよいのか。
万一のときにどう復旧するのか。
という「情報の扱い」そのものです。
こうした安全設計は、専門のシステム会社やコンサルタントに依頼して本格的に導入する場合には、通常は先に検討されます。
そこで、特に小規模な事業所がGoogle WorkspaceやAIなどを使いながら自分たちで業務改善を進める場合の、最低限の設計として考えてみたのが、
「一次情報分離型セキュアアーキテクチャ」です。
介護現場のデジタル化では、今ある業務をそのままデジタルツールに置き換える方法がまず思い浮かびます。
たとえば、
現場職員
↓
Googleフォームへ入力
↓
Googleスプレッドシートへ集約
↓
GASで管理者へ通知
↓
集計・可視化
↓
必要に応じてAIで文章整理
という流れです。
個人情報を含まないアンケート、備品管理、社内の簡単な申請などであれば、非常に便利です。
実際、厚生労働省の「デジタル中核人材養成研修」でも、LINE WORKSを題材に導入時の課題を検討したり、Googleスプレッドシートを使って導入計画を作成したりする演習が行われています。
同時に、デジタル中核人材には、ネットワーク環境、導入・運用コスト、セキュリティ対策、個人情報保護などの理解も求められています。
つまり、問題はクラウドサービスを使うことではなく、どの情報をそこで扱うのかです。
利用者の氏名、顔写真、医療・介護情報、具体的な支援記録、家族情報、通報内容や証拠資料などは、単なる集計用データではなく、本人を特定し得る一次情報です。
そのため、
写真を撮る
↓
LINEへ送る
事故内容を書く
↓
Googleフォームへ送る
支援記録を書く
↓
そのまま生成AIへ渡す
という流れには慎重になる必要があります。
ツールより先に、「どの情報をどこへ流すのか」を考える。
そこで、先に次のような構造を作ります。
現場職員
↓
法人管理端末
↓
安全な業務入口
↓
一次情報受付
↓
原本を安全に保管
↓
分類・分離・匿名化
↓
必要な情報だけを後段へ
├ Google Workspace
├ AI
└ 限定された通報管理領域
一次情報を先に保護・分離し、必要な情報だけを後段へ流します。
一次情報保護・分離保管・安全共有の標準モデル

この図で表している仕組みを上から順番に見ていきます。
1.職員が使う入口は、できるだけ一つにする
現場職員が、
「事故はこのアプリ」
「申し送りはLINE」
「写真は別のサービス」
「記録は介護ソフト」
「通報だけ別フォーム」
と使い分けるほど、業務は複雑になります。
そこで、職員から見える入口はできるだけ一つにします。
図ではこれを「セキュア介護業務ポータル」と呼んでいます。販売されている特定の商品名ではありません。
ヒヤリハット、事故報告、写真付き報告、支援記録、申し送り、虐待・不正・公益通報などを入力するための、法人専用の業務入口を表す概念名称です。
重要なのは、その入口がどのように守られ、入力された情報がどこに保存されるかです。
2.入口の裏側で、認証と端末確認を行う
図では、入口を守る仕組みの一例としてCloudflare Zero Trustを置いています。
職員から見れば一つのアプリを開いているだけですが、その裏側で、
誰がアクセスしているのか
法人が許可した端末なのか
その職員に必要な権限があるのか
不審なアクセスではないか
を確認します。
Cloudflareは一例であり、同じ要件を満たす別のZero Trust、SASE、ID管理、端末管理の仕組みでも構いません。
3.一次情報は、まず安全な領域に保管する
入力された情報のうち、原本は一次情報の保管領域に残します。
個人特定情報: 利用者氏名、顔写真、家族情報
医療・介護情報: 病歴、障害情報、服薬詳細、詳細な支援記録
証拠資料: 事故写真、通報内容
保存先には、専用クラウドデータベース、オブジェクトストレージ、既存の介護記録システム、社内サーバーなどが考えられます。
保存先は「クラウドか社内サーバーか」だけで判断せず、認証、暗号化、閲覧権限、ログ、バックアップ、復旧方法、保守体制まで含めて設計します。
4.原本を保存した後で、情報を分ける
ここが、この設計の中心です。
たとえば転倒事故が発生した場合、原本には、
山田太郎さん
82歳
○○疾患
服薬○○
居室内で転倒
右腕に擦過傷
事故現場写真あり
詳細な対応記録
といった情報が含まれるかもしれません。
一方、法人全体の事故管理や集計に必要なのは、
事故ID:A-1024
発生日:8月15日
事業所:○○ホーム
分類:転倒
対応状況:管理者確認待ち
写真原本:あり
程度の場合もあります。
原本を共有するのではなく、共有に必要なデータを原本から切り出す。
「情報を閉じ込める」か「共有して活用する」かの二択ではなく、原本を守りながら必要な情報だけを安全に流すという考え方です。
5.Google Workspaceは「二次処理」に使う
分離された情報は、管理者への通知、進捗・期限管理、集計、分析、資料作成、他部署との共有などに活用します。
6.AIも一次情報の直接の送り先にはしない
AIには、文章整理、要約、報告書の下書き、分類、傾向分析などを担わせます。
利用者氏名、病歴、顔写真、詳細な支援情報などをそのまま投入せず、必要な情報だけに絞り、必要に応じて匿名化・最小化します。
原文
↓
必要部分を抽出
↓
匿名化・最小化
↓
AIで文章整理
↓
職員が最終確認
最終確認は人が行います。
7.虐待・不正・公益通報は、さらに別にする
虐待、不正、公益通報では、通報対象者が通常の管理者本人である可能性があります。
そのため、通報本文、証拠写真、証拠資料、通報者情報、調査記録などは、通常の事故報告とは別の閲覧権限で管理します。
8.保存しただけでは終わらない
実際の運用では、
バックアップをどこに置くか
何世代残すか
保存期間をどうするか
誤削除時にどう復旧するか
ランサムウェアや障害時にどう復旧するか
退職・異動した職員の権限をどう失効するか
誰がどの情報を見たかログを残すか
制度変更時にどこを見直すか
まで決める必要があります。
システムを作ることと、安全に使い続けることは別です。
9.この図は「完成システム」ではなく、設計のたたき台
この図は、介護現場の一次情報をどのように受け取り、守り、分離し、必要な場所へ流すかという基本構造を可視化した参考モデルです。
実際の構成は、法人規模、事業形態、既存システム、使用端末、取り扱う情報、職員数、予算、保守体制、法令やガイドラインによって変わります。
そのため、各事業所で業務や情報の流れを整理し、AIも活用しながら設計図を作ったうえで、実際の導入前にはITアーキテクトや情報セキュリティの専門家に設計レビューを依頼する。
すべてを外部コンサルタントへ丸投げするのではなく、設計の重要な部分だけ専門家の診断を受ける方法も、小規模事業所にとって現実的な選択肢だと思います。
AIによって、システムを作れる時代になりました。
だからこそ、実装を急ぐのではなく、最初に情報の流れと安全性を含めた設計図を持つことが重要です。
介護DXは、利用者の情報を守りながら、現場の負担を減らし、必要な情報を安全に共有できる仕組みをつくること。
その土台として、一次情報を分離して扱うアーキテクチャを先に設計しておくことは、今後の介護現場のデジタル化における重要な選択肢の一つだと考えています。
#介護DX
#介護
#DX
#AI活用
#業務改善
#個人情報保護
#情報セキュリティ
#GoogleWorkspace
#生成AI
#福祉
