I – はじめに｜2026–2027年、ケアプランデータ連携が大きな転換期へ

介護現場ではこれまで、ケアプランやサービス提供票の共有に、紙・FAX・CSVなどが広く利用されてきました。しかし、こうした運用では、データの再入力や送受信確認など多くの手作業が発生しています。

2026年4月からは、介護情報基盤の利用が自治体ごとに順次開始され、介護情報を電子的に共有する環境の整備が進んでいます。さらに、2027年1月には、現在の ケアプランデータ連携システムが 介護WEBサービスへ移行する予定です。
（厚生労働省：介護情報基盤について／介護保険最新情報 Vol.1529）

また、介護ソフトとの API連携に向けた仕様も公開されており、今後は ケアプランデータ連携標準仕様第4.1版・第5.0版への対応も重要になります。
（厚生労働省：介護保険最新情報 Vol.1505）

つまり、2026～2027年は、ケアプラン連携が「ファイルを人が送る仕組み」から「システム同士がデータを連携する仕組み」へ移行する大きな転換期です。

本記事では、これまでのケアプランデータ連携の変遷、2026～2027年に変わるポイント、そして既存システムで必要となる移行対応について整理して解説します。

II – ケアプランデータ連携はこれまでどう進化してきたのか？

ケアプランの情報共有は、紙やFAXを中心としたアナログな運用から、データ標準化、共通プラットフォーム、そしてAPI連携へと段階的に進化してきました。

① 紙・FAXによる情報共有(2000年〜)

従来、ケアプランやサービス提供票は、紙、FAX、郵送などを使って事業所間で共有されていました。送信後は、受け取った事業所が内容を確認し、自社の介護ソフトへ再入力する必要があり、入力作業や確認作業が大きな負担となっていました。紙を「人」が運ぶ時代だったといえます。

② PDF・CSVによる電子化(2013年〜)

その後、PDFやExcel、CSV、メールなどを利用した電子的な情報共有が広がりました。紙を印刷する必要は減りましたが、ファイルの作成、メール送信、ダウンロード、インポートなどは依然として人が行う必要がありました。つまり、電子化は進んだものの、業務そのものはまだ手作業中心でした。

③ データ形式の標準化(2019年~)

次の大きな変化が、ケアプランデータ連携標準仕様の整備です。介護ソフトごとに異なっていたデータ形式を共通化することで、異なるベンダーの介護ソフト間でもケアプランデータをやり取りできる基盤が整えられました。

ここで初めて、「書類を共有する」から「データを共有する」という考え方への転換が進みました。

④ 共通プラットフォームによるデータ連携(2023年~)

2023年には、ケアプランデータ連携システムの運用が開始されました。介護ソフトから標準形式のデータを出力し、専用クライアントを通じて安全に送受信することで、異なる介護ソフトを利用する事業所間でもデータ連携が可能になりました。これにより、FAXや郵送と比べて、再入力作業や送付ミスの削減、送受信履歴の管理などが可能になりました。一方で、CSVの出力・アップロード・ダウンロード・インポートといった操作は依然として残っています。

⑤ WEB・APIを中心としたシステム連携へ(2026年~)

2026～2027年からは、さらに次の段階へ移行します。ケアプランデータ連携システムは 介護WEBサービス (Dịch vụ WEB Kaigo) へ移行し、さらに 介護情報基盤 との統合やAPI連携が進められます。API対応が進めば、従来のように人がCSVを出力してアップロードするのではなく、介護ソフトから直接データを送受信できるようになります。

つまり、ケアプランデータ連携は、

紙・FAX → 電子ファイル → 標準データ → 共通プラットフォーム → API連携

という流れで進化してきました。

これまでの「人がファイルを送る仕組み」から、これからは「システム同士が直接データをやり取りする仕組み」へ。2026～2027年は、ケアプランデータ連携におけるDXの大きな転換点といえます。

III – 2026–2027年に何が変わるのか？

3.1 介護情報基盤の利用開始

2026年4月1日から、システム標準化などの準備が完了した自治体より順次、介護情報基盤の利用が開始されています。厚生労働省は、2028年4月1日までに全市町村で介護情報基盤へのデータ移行を完了し、活用を開始することを目標としています。

介護情報基盤は、これまで自治体、介護事業所、医療機関などに分散していた介護情報を集約し、本人の同意のもとで関係者が電子的に閲覧・共有できる仕組みです。対象となる情報には、要介護認定情報、LIFE情報、ケアプランなどが含まれます。

これにより、これまで紙や個別システムを通じて行われていた情報共有を電子化し、情報確認の迅速化、再入力の削減、事業所間・多職種間の連携強化などが期待されています。

ただし、2026年4月から全国一斉に切り替わるわけではありません。自治体ごとに準備状況が異なるため、一定期間は新旧の運用が並存することになります。介護事業所やシステムベンダーにとっては、自社が関係する自治体の開始時期を確認しながら、段階的に移行対応を進めることが重要です。自治体ごとの対応状況は「介護情報基盤ポータル」で確認できます。

3.2 – ケアプランデータ連携システムが介護WEBサービスへ移行

現在の ケアプランデータ連携システムは、2027年1月を予定として 介護WEBサービス へ移行します。移行後は、従来の専用クライアントソフトではなく、WEBシステム上で ケアプランデータ連携機能 を利用できるようになります。具体的な移行日は今後改めて公表される予定です。

また、現在のシステムは移行後も一定期間は稼働しますが、その後終了する予定です。継続してケアプランデータ連携を利用する事業所は、事前に 介護WEBサービス への利用登録が必要です。この準備は、各市町村の 介護情報基盤の利用開始時期にかかわらず必要とされています。

WEB化により、データの再ダウンロード、複数端末での利用、パスワード入力、画面操作などの利便性も改善される予定です。また、移行後は 介護WEBサービスの一機能としてケアプランデータを送受信できるため、従来の年額21,000円の利用料は発生しない予定です。

つまり今回の移行は、単なる画面変更ではなく、ケアプランデータ連携を 介護情報基盤 の共通サービスへ統合していくための重要なステップです。介護事業所だけでなく、介護ソフトベンダーにとっても、既存のクライアントソフトを前提とした運用から、WEB・APIを前提とした新しい連携方式への対応が必要になります。

3.3 – ケアプランデータ連携標準仕様4.1 / 5.0への対応

ケアプランデータ連携標準仕様は、異なる介護ソフト間でケアプランデータを正しく送受信するために、データ項目、ファイル構造、コード、出力単位などを共通化した仕様です。これまでのケアプランデータ連携システムでは、主に標準仕様に準拠したCSVファイルを介護ソフトから出力し、専用システムを通じて送受信する方式が採用されてきました。

一方、介護情報基盤との統合後は、この標準仕様の位置づけも変わります。厚生労働省は、統合後のケアプランデータ連携機能について、標準仕様第4.1版または第5.0版に対応した介護ソフトのみ利用可能としています。

第4.1版と第5.0版の違い

第4.1版は、現在のケアプランデータ連携システムで利用されているCSVベースの連携方式を前提とした仕様です。第4.0版では、第3表のCSVレイアウト追加、複数サービス提供事業所への対応、福祉用具に関する項目追加、介護予防支援に関するデータ連携などが拡張され、第4.1版ではファイル名称規約などの修正が行われています。

これに対し、第5.0版（暫定版）は、介護WEBサービスとのAPI連携を前提とした新しい標準仕様として整理されています。

主な変更点は以下の通りです。

項目	第4.1版	第5.0版（暫定版）
主な連携方式	ファイル連携	API連携
主なデータ形式	CSV	JSON
事業所間連携	対応	APIによる連携に対応
介護情報基盤への登録	基本的に対象外	対応
交付用ケアプラン登録	―	対応
同意・確認用データ登録	―	対応
システム連携の自動化	限定的	より高度な自動化が可能

第5.0版では、従来の事業所間でのケアプラン送受信だけでなく、APIを利用した介護情報基盤への「交付用登録」「同意・確認用登録」に関する仕様が追加されています。また、APIで扱うデータ形式はJSON形式とされています。

つまり、4.1から5.0への変更は単純なCSVレイアウトの更新ではなく、

「ファイル交換を前提とした標準仕様」から「API・介護情報基盤を前提とした標準仕様」への拡張

と見ることができます。

第5.0版では介護情報基盤へのケアプラン登録も対象に

第5.0版（暫定版）では、ケアプランを単に事業所間で送受信するだけでなく、介護情報基盤へ登録するためのインターフェースも定義されています。

例えば、施設介護サービスについては、確定した施設サービス計画書第1表～第4表を、介護ソフトから介護WEBサービスを経由したAPI連携によって介護情報基盤へ登録する仕組みが示されています。

また、登録時には、介護情報基盤に登録されている介護被保険者証情報との照合が行われます。照合には、保険者番号、被保険者番号、生年月日、性別などが利用される想定です。なお、対象となる被保険者が所属する保険者が、すでに介護情報基盤へ移行していることが登録の条件となります。

これまでのケアプランデータ連携が、

事業所A → 事業所B

を中心とした仕組みだったのに対し、今後は、

事業所 → 介護情報基盤

という新しいデータ連携も加わることになります。

4.1と5.0は移行期間中に共存する

重要なのは、すべての介護ソフトが一斉に5.0へ移行する必要はないという点です。厚生労働省のAPI仕様書（暫定版）では、送信側と受信側の標準仕様バージョンが異なる場合に、介護WEBサービス側でバージョン変換を行う仕組みが示されています。

例えば、

4.1対応ソフト → 5.0対応ソフト

の場合は、4.1版のCSVデータを介護WEBサービス側で5.0版のJSON形式へ変換します。

反対に、

5.0対応ソフト → 4.1対応ソフト

の場合は、5.0版のJSONデータを4.1版のCSVファイルへ変換して受信側へ提供する仕組みが想定されています。これにより、移行期間中は、

といった異なるバージョン間での連携が可能になります。

これは、全国の介護事業所や介護ソフトベンダーが同時にシステム改修を完了させる必要をなくし、段階的な移行を可能にするための重要な仕組みです。

介護ソフトベンダーに必要となる対応

既存の介護ソフトでは、まず現在どの標準仕様に対応しているかを確認する必要があります。

主な確認・改修ポイントとしては、以下が考えられます。

• 現在のCSV出力・取込機能が第4.1版に準拠しているか
• 既存データベースと第4.1版／第5.0版の項目とのマッピング
• 第5.0版JSONフォーマットへの変換処理
• 介護WEBサービスAPIとの送受信機能
• 標準仕様のバージョン管理
• 送信・受信・登録・削除などのステータス管理
• APIエラー、タイムアウト、再送処理
• 利用者情報と介護情報基盤上の被保険者情報との照合
• 旧方式と新方式が共存する期間の運用設計
• ベンダー試験、結合試験、移行試験への対応

特に、既存システムの内部データ構造が標準仕様と一致しているとは限らないため、単純にAPIを追加するだけではなく、既存DBと標準仕様とのデータマッピングが重要な作業になります。

既存システムでは「共通データモデル＋変換レイヤー」も有効

既存システムを改修する場合、4.1用と5.0用の処理をそれぞれ独立して実装すると、今後の仕様改定のたびに保守負担が増える可能性があります。

そのため、システム設計上は、内部に共通のケアプランデータモデルを持ち、

既存DB
   ↓
共通Care Plan Data Model
   ├── 4.1 CSV Adapter
   └── 5.0 JSON / API Adapter

のように、標準仕様ごとの変換レイヤーを分離する構成も有効です。

この方式であれば、4.1と5.0を並行してサポートしながら、将来の仕様改定にも比較的対応しやすくなります。

なお、これは厚生労働省が指定するシステム構成ではなく、既存システムを段階的に移行する際の設計アプローチの一例です。

第5.0版はまだ暫定仕様であることに注意

2026年5月27日に公開された第5.0版は、API仕様書とともに公開された暫定版です。厚生労働省は、介護ソフトベンダーの開発検討を早期に開始できるよう暫定仕様を公開しており、ベンダー試験の開始時期や具体的な実施方法、API機能のリリース時期などについては別途周知するとしています。

そのため、介護ソフトベンダーは現時点からGap Analysisやデータマッピング、アーキテクチャ設計を進めつつ、今後公開される確定仕様との差分を確認しながら実装を進める必要があります。

2026～2027年の対応では、単に「最新バージョンへアップデートする」のではなく、CSV中心のファイル連携を継続するのか、APIを活用した5.0対応へ進むのかという、製品アーキテクチャそのものの判断が求められることになります。

IV – 介護事業者には何が変わるのか？

介護情報基盤や介護WEBサービスの導入によって、介護事業者にとって最も大きく変わるのは、「情報を受け取り、確認し、別のシステムへ入力する」という業務のあり方です。これまで紙・FAX・CSVなどで行われてきた情報連携が、WEBやAPIを活用したデータ連携へ移行することで、日常業務の効率化が期待されます。

4.1 ケアプランの送受信がWEB中心へ

現在のケアプランデータ連携システムでは、専用クライアントソフトを利用してデータを送受信しています。2027年1月を予定している介護WEBサービスへの移行後は、専用クライアントではなく、WEBブラウザからケアプランデータ連携機能を利用する方式へ変わります。これに伴い、介護事業者は介護WEBサービスへの利用登録や、新しい操作方法・業務フローへの対応が必要になります。

一方、WEB化によって専用クライアントのインストールや更新が不要となり、複数端末から利用しやすくなるなど、運用面での利便性向上も期待されています。

4.2 CSVを扱う作業を減らせる可能性

API対応の介護ソフトを利用する場合、さらに大きな変化が期待できます。

従来は、

介護ソフト → CSV出力 → 送信 → 受信 → CSV取込 → 介護ソフト

というように、職員がファイルを操作する工程が必要でした。

API連携では、

介護ソフト ⇄ 介護WEBサービス

という形でシステム間連携が可能になるため、介護ソフト側の実装によっては、職員がCSVファイルを意識することなく、普段利用している介護ソフト上で送受信を完結できるようになります。これにより、ファイルの出力・保存・選択・取込といった手作業や、誤ったファイルを送信するリスクの削減が期待できます。

4.3 利用者情報を電子的に確認・共有しやすくなる

介護情報基盤では、ケアプランだけでなく、要介護認定情報や介護保険被保険者証等情報、LIFE情報など、介護に関する情報を電子的に共有する仕組みが整備されます。

これまで紙の被保険者証や自治体から提供される情報などを確認し、介護ソフトへ入力していた業務についても、介護情報基盤との連携によって効率化できる可能性があります。

また、API対応ソフトでは、職員が介護WEBサービスを別途開くのではなく、普段利用している介護ソフト上から必要な情報を確認できる仕組みも想定されています。

4.4 「確認して転記する業務」から「確認して活用する業務」へ

これらの変化によって期待されるのは、単なるペーパーレス化ではありません。

従来は、

情報を受け取る → 内容を確認する → 自社システムへ転記する

という作業に多くの時間が必要でした。

データ連携が進めば、

情報を受信する → システムへ反映する → 職員が確認・活用する

という業務フローへ移行できます。

特に、複数の居宅介護支援事業所やサービス事業所と日常的にケアプランをやり取りしている事業者では、再入力や確認作業の削減による効果が大きくなると考えられます。

4.5 すべてが一度に自動化されるわけではない

一方で、介護情報基盤や介護WEBサービスが開始されたからといって、すべての事業所間連携がすぐにAPIへ切り替わるわけではありません。

自治体ごとに介護情報基盤への移行時期が異なるほか、利用する介護ソフトや事業所によって、新しい仕組みへの対応状況も異なります。

そのため、移行期間中は、

WEB・APIによる連携

と、

既存のファイル連携やその他の運用

が一定期間並存する可能性があります。

介護事業者にとって重要なのは、「新しいシステムが始まるから対応する」だけではなく、自社が利用している介護ソフトがどこまで対応しているのか、取引先事業所とはどの方法でデータをやり取りするのかを整理することです。

4.6 介護事業者が今確認すべきポイント

今後の移行に向けて、介護事業者はまず以下を確認しておくことが重要です。

• 自社が利用している介護ソフトは標準仕様4.1／5.0に対応しているか
• 介護ソフトベンダーはAPI対応を予定しているか
• 介護WEBサービスへの利用登録はいつ必要になるか
• 自治体の介護情報基盤への移行時期はいつか
• ケアプランの送受信業務が現在どのような手順になっているか
• WEB・API移行後にどの作業を削減・自動化できるか
• 移行期間中に旧方式と新方式をどのように使い分けるか

今回の変化は、介護事業者に新しいシステムへの対応を求める一方で、これまで職員が行ってきた「送る・受け取る・転記する・確認する」業務を見直す機会でもあります。介護情報基盤やAPIを単なる制度対応として捉えるのではなく、現在の業務フローそのものを見直し、介護現場の事務負担を削減するDXの機会として活用することが重要です。

V – 介護ソフトベンダーには何が求められるのか？

2026～2027年の変化は、介護ソフトベンダーにとって単なる制度改正対応ではありません。

介護WEBサービスへの移行、ケアプランデータ連携標準仕様4.1／5.0への対応、さらにAPI連携を見据えると、既存システムのデータ構造、外部連携、画面、セキュリティ、運用まで含めた影響範囲を整理する必要があります。特に重要なのは、最初から大規模な改修を始めるのではなく、まず現行システムと新仕様との差分（Gap）を明確にすることです。

5.1 現行システムと標準仕様のGap Analysis

まず確認すべきなのが、現在の介護ソフトがケアプランデータ連携標準仕様4.1／5.0に対して、どこまで対応できているかです。

例えば、以下のような観点で調査する必要があります。

• 現在対応している標準仕様のバージョン
• CSVの出力・取込仕様
• 必須項目・コード体系への対応状況
• 現行DBと標準仕様のデータ項目の差分
• 介護予防支援など対象サービスへの対応状況
• 第5.0版で追加・変更されるデータへの対応

この調査によって、既存機能をそのまま利用できる部分と、新たに改修が必要な部分を切り分けることができます。

5.2 データマッピングと変換処理

既存システムのデータ構造が、標準仕様と完全に一致しているとは限りません。

そのため、

既存DB ⇄ 標準仕様4.1／5.0

のデータマッピングが重要になります。

特に第5.0版では、API連携を想定したJSON形式が利用されるため、既存の内部データを標準形式へ変換する処理が必要になります。

例えば、

既存DB → 共通データモデル → CSV／JSON変換

という変換レイヤーを設けることで、4.1と5.0の双方を扱いやすい構成にすることも考えられます。

これは将来の標準仕様改定への対応コストを抑える上でも重要な設計ポイントです。

5.3 介護WEBサービスとのAPI連携

API対応を選択する場合は、介護WEBサービスとの通信機能を新たに実装する必要があります。

公開されている暫定仕様では、ケアプランデータ連携について、送信、受信、送受信一覧取得、交付用登録などのAPIが示されています。

そのため、単に「APIを呼び出す機能」を追加するだけではなく、

• APIリクエスト・レスポンス処理
• 認証・認可
• 送受信ステータス管理
• エラー処理
• タイムアウト処理
• 再送制御
• 重複送信の防止
• 通信ログ・監査ログ

などを含めた設計が必要になります。

特に外部基盤との通信では、一時的な通信障害や処理失敗を前提として、「失敗したデータをどのように検知し、再処理するか」まで設計しておくことが重要です。

5.4 UI・業務フローの見直し

API対応の価値を最大化するには、バックエンドの連携だけでなく、介護職員が利用する画面も見直す必要があります。

例えば、介護ソフト上で、

ケアプラン作成 → 内容確認 → 送信 → 送信結果確認

まで完結できれば、職員がCSVを出力して別システムへアップロードする必要がなくなります。

また、

• 未送信
• 送信中
• 送信済み
• 受信済み
• エラー
• 再送待ち

などの状態を画面上で分かりやすく表示することも重要です。

つまり、API対応はバックエンドだけの改修ではなく、既存の業務フローそのものを再設計する機会でもあります。

5.5 新旧方式が共存する移行期間への対応

2026～2027年の移行で特に注意すべきなのが、すべての自治体・介護事業所・介護ソフトが同時に新方式へ移行するわけではない点です。

そのため、一定期間は、

CSV／WEB／APIなど複数の連携方式

を考慮した運用が必要になる可能性があります。

例えば、相手先事業所ごとに利用可能な連携方式を管理し、

API対応事業所 → API連携

API未対応事業所 → WEB・ファイル連携

のように送受信方法を切り替える設計も考えられます。

このようなハイブリッド運用を想定せず、新方式だけを前提としてシステムを改修すると、移行期間中の実運用で問題が発生する可能性があります。

5.6 セキュリティ・監査への対応

介護情報基盤では、利用者の介護保険情報やケアプランなど、重要な個人情報を扱います。

そのため、API連携を実装する際には、

• 認証・認可
• アクセス権限管理
• 通信の保護
• 操作ログ
• API通信ログ
• 不正アクセス対策
• インシデント発生時の追跡性

などを含めたセキュリティ設計が重要になります。

「APIが正常に接続できるか」だけではなく、誰が・いつ・どの利用者の情報に対して・どの操作を行ったのかを追跡できる設計が求められます。

5.7 テスト・移行計画も早期に準備する

外部基盤との連携では、自社システム内の単体テストだけでは十分ではありません。

今後公開される確定仕様やベンダー試験に合わせて、

仕様確認 → 開発 → 内部テスト → 接続試験 → 移行試験 → 本番切替

というロードマップを準備しておく必要があります。

特に第5.0版やAPI仕様は暫定版として公開されているため、現時点ではデータマッピングやアーキテクチャ設計など、仕様変更の影響を受けにくい部分から先行して検討し、確定仕様公開後に差分を反映できる開発計画が現実的です。

介護ソフトベンダーにとっての対応範囲

今回の移行で想定される主な対応を整理すると、以下のようになります。

対応領域	主な対応内容
標準仕様	4.1／5.0への対応、バージョン管理
データ	DBとのマッピング、CSV／JSON変換
API	送受信・登録・一覧取得などの連携
セキュリティ	認証・認可、アクセス制御、ログ
UI/UX	送受信・エラー・ステータス確認画面
エラー処理	Retry、重複防止、障害復旧
互換性	旧方式と新方式の並行運用
テスト	接続試験、ベンダー試験、移行試験
運用	Monitoring、問い合わせ・障害対応

つまり、今回の対応は「CSVのフォーマットを変更する」「新しいAPIを追加する」だけではありません。

既存の介護ソフトを、これからの介護情報基盤を中心としたデータ連携環境へどのように適応させるかという、製品アーキテクチャ全体の課題として捉える必要があります。

そのため、まず現行システムを調査し、標準仕様・API仕様とのGapを整理した上で、自社製品に適した移行方式を選択することが重要になります。

VI – 既存システムはどのように移行すべきか？

介護情報基盤や介護WEBサービスへの移行に伴い、介護ソフトベンダーは既存システムをどこまで改修するかを検討する必要があります。

ただし、すべてのシステムを最初からAPI対応へ全面改修する必要があるとは限りません。既存システムの構成、利用事業所数、開発コスト、今後の製品戦略などによって、最適な移行方法は異なります。

ここでは、既存介護ソフトの移行方法を大きく3つのパターンに整理します。

6.1 WEB利用型 ― 最小限の改修で移行する

最もシンプルなのは、既存介護ソフトの大規模な改修を避け、介護WEBサービスを利用してデータを連携する方法です。

既存ソフトでは、ケアプランデータ連携標準仕様4.1などに準拠したデータを出力・取り込みできるようにし、実際の送受信は介護WEBサービス上で行います。

既存介護ソフト → CSV出力 → 介護WEBサービス → CSV取得 → 既存介護ソフト

この方式では、既存システムのアーキテクチャを大きく変更する必要がなく、比較的短期間・低コストで新しい環境へ対応しやすいことがメリットです。

一方、CSVの出力、アップロード、ダウンロード、取り込みなど、人による操作は残ります。そのため、制度・環境変更への対応を優先する場合には有効ですが、業務自動化の効果は限定的です。

特に、API対応の優先度が低い製品や、既存システムへの影響を最小限に抑えたい場合に検討しやすい方式です。

6.2 Adapter / Middleware型 ― 既存システムを活かしながらAPI対応する

2つ目は、既存介護ソフトと介護WEBサービスの間に、連携アダプターやMiddlewareを設ける方法です。

既存介護ソフト → Adapter / Middleware → API → 介護WEBサービス

既存システムの内部構造を大幅に変更する代わりに、外部連携に必要な処理を専用レイヤーへ分離します。

Adapter / Middleware側では、例えば以下の機能を担当します。

• 既存データと標準仕様4.1／5.0のマッピング
• CSV／JSONなどのデータ形式変換
• APIリクエスト・レスポンス処理
• 認証・認可
• データバリデーション
• 送受信ステータス管理
• エラー処理・再送制御
• 通信ログ・監査ログ

この方式の大きなメリットは、長年運用してきた既存システムへの影響を抑えながら、API連携を実現できることです。

特に、オンプレミス型や長期間運用されている介護ソフトでは、Core Systemを全面的に改修すると開発・テスト範囲が大きくなります。外部連携機能をAdapterとして切り離すことで、既存資産を活用しながら段階的に新しい仕組みへ移行できます。

また、将来的に標準仕様やAPI仕様が変更された場合でも、変換・連携ロジックをAdapter側へ集約しておけば、Core Systemへの影響を抑えやすくなります。

一方で、新たな連携レイヤーを追加するため、Adapter自体の監視、障害対応、バージョン管理などが必要になります。既存システムとのデータ同期や整合性についても十分な設計が必要です。

6.3 API Native型 ― 介護ソフト自体をAPI連携に最適化する

3つ目は、介護WEBサービスとのAPI連携を介護ソフト本体へ組み込み、ユーザーが普段利用している画面からデータ連携を完結できるようにする方法です。

介護ソフト ⇄ API ⇄ 介護WEBサービス

例えば、介護ソフト上でケアプランを作成した後、そのまま「送信」を実行し、送信結果や受信データ、エラー状況なども同じシステム内で確認できるような構成です。

API Native型では、CSVファイルをユーザーが意識する必要がなくなり、

ケアプラン作成 → 確認 → 送信 → 受信 → システム反映

までを一つの業務フローとして設計できます。

これにより、手動操作や転記作業の削減だけでなく、送受信状況の自動確認、エラー通知、データ反映など、より高度な業務自動化へ発展させることが可能になります。

一方、既存システムをAPI Native化する場合は、API通信だけでなく、データモデル、業務ロジック、UI/UX、ステータス管理、認証・認可、エラー処理など広い範囲の改修が必要になる可能性があります。

そのため、初期開発コストやテスト範囲は3つの方式の中で最も大きくなりますが、中長期的に介護DXを製品戦略の中心に置くベンダーにとっては、有力な選択肢となります。

特に、新規SaaSやクラウドネイティブな介護ソフト、今後も介護情報基盤との連携機能を拡張していく製品では、API Nativeを前提としたアーキテクチャを検討する価値があります。

3つの移行方式の比較

比較項目	WEB利用型	Adapter / Middleware型	API Native型
基本方針	WEBサービスを活用	既存システムに連携層を追加	ソフト本体へAPI連携を統合
既存システムの改修範囲	小	中	大
初期開発コスト	低	中	高
導入期間	比較的短い	中程度	比較的長い
Core Systemへの影響	小	小～中	大
CSV等の手動操作	残りやすい	大幅に削減可能	原則として最小化可能
APIによる自動化	低	高	非常に高い
ユーザー体験	従来運用に近い	改善可能	最も統合しやすい
Legacy Systemとの相性	◎	◎	△～○
将来の機能拡張	△	○～◎	◎
運用・保守	比較的シンプル	Middlewareの管理が必要	製品全体で管理
適しているケース	まず新環境へ対応したい	既存資産を維持しながらDXしたい	長期的に製品を高度化したい

どの方式を選択すべきか？

重要なのは、「API Nativeが最も優れているから、すべてのシステムをAPI Nativeへ移行する」という考え方ではありません。

例えば、既存システムの利用期間が長く、大規模な改修リスクを避けたい場合には、WEB利用型やAdapter / Middleware型の方が現実的な場合があります。

一方、今後も継続的に介護情報基盤との連携機能を拡張し、データ連携や業務自動化を製品の競争力としていくのであれば、API Native型への投資価値は高くなります。

そのため、移行方式を決定する前に、

現行システム調査 → Gap Analysis → 移行方式比較 → PoC → 本開発

という順序で検討することが重要です。

また、必ずしも3つの方式から1つだけを選ぶ必要はありません。

例えば、短期的にはWEB利用型で制度・環境変更に対応し、その後AdapterによるAPI連携を追加し、将来的には主要機能をAPI Native化するという段階的なロードマップも考えられます。

WEB利用型 → Adapter / Middleware型 → API Native型

という段階的な移行は、既存システムのリスクを抑えながら、介護情報基盤を中心とした新しいデータ連携環境へ移行するための一つの現実的なアプローチです。

※上記3パターンは、厚生労働省が定める公式な移行区分ではなく、既存介護ソフトの移行方法をシステムアーキテクチャの観点から整理したものです。

VII – 特に注意すべき移行リスク

介護情報基盤・介護WEBサービスへの移行では、新しいAPIを実装するだけでなく、既存データとの互換性や新旧システムの並行運用、外部サービスとの通信障害など、さまざまなリスクを考慮する必要があります。特に、長期間運用されてきた介護ソフトでは、既存のデータ構造や業務フローが標準仕様と一致していないケースも想定されるため、開発前の影響調査が重要です。

7.1 既存データと標準仕様の不一致

最初に確認すべきなのが、既存システムのデータとケアプランデータ連携標準仕様4.1／5.0との整合性です。例えば、以下のような問題が考えられます。

• 標準仕様の必須項目が既存DBに存在しない
• 同じ情報でもデータ型やコード体系が異なる
• 1つの項目を複数項目へ分割する必要がある
• 既存システム独自の項目が存在する
• 過去データと現在データで保存形式が異なる

そのため、API開発を開始する前に、「既存DB → 標準仕様4.1／5.0」のデータマッピングを行い、変換できない項目や不足データを明確にする必要があります。

7.2 標準仕様・API仕様のバージョン変更

2026年5月に公開されたケアプランデータ連携標準仕様5.0およびAPI仕様は暫定版であり、今後変更される可能性があります。そのため、暫定仕様を前提として連携処理をシステム全体へ直接組み込むと、確定仕様との差分が発生した際に広範囲な改修が必要になる可能性があります。

例えば、「Core System → 共通データモデル → API Adapter」のように外部仕様への依存部分を分離し、仕様変更の影響範囲を限定できる構成を検討することが重要です。

7.3 新旧方式が共存する移行期間

全国の自治体や介護事業所、介護ソフトが同じタイミングで新方式へ切り替わるわけではありません。そのため、移行期間中は相手先によって利用可能な連携方法が異なる可能性があります。

例えば、

事業所A → API連携
事業所B → WEB／CSV連携
事業所C → 従来の運用

という状況も想定しておく必要があります。システム側では、相手先ごとの連携方式や対応バージョンを管理し、適切な送受信方法を選択できる仕組みを検討する必要があります。移行の難しさは、単に「新しいAPIを実装すること」ではなく、旧運用と新運用が一定期間並存することにあります。

7.4 二重送信・二重登録

複数の連携方式を並行して利用すると、同じケアプランをCSVとAPIの両方から送信してしまうなど、二重処理が発生する可能性があります。

特に、送信 → タイムアウト → 結果不明 → 再送 のようなケースでは、実際には最初の送信が成功しているにもかかわらず、再送によって同じデータが複数回処理されるリスクがあります。

そのため、

• 一意なデータ識別
• 送信履歴管理
• 重複チェック
• 再送制御
• 処理結果の照合

など、冪等性を考慮した設計が重要になります。

7.5 API障害・通信エラーへの対応

API連携では、介護ソフトだけでなく、ネットワークや介護WEBサービスなど外部環境の状態にも影響を受けます。そのため、APIが利用できない＝業務が完全に停止するという設計は避ける必要があります。

例えば、

• タイムアウト
• 一時的な通信障害
• 認証エラー
• データValidation Error
• 外部サービスのメンテナンス
• API側の一時的な処理失敗

などを想定し、エラー内容の保存、Retry、手動再送、管理者への通知などの仕組みを設計することが重要です。

7.6 データ同期・ステータス不整合

API連携では、「データを送信した」ことと「相手側で正常に処理された」ことは必ずしも同じではありません。

例えば、

未送信 → 送信中 → 送信済み → 受信済み

といった状態をシステム側で管理する必要があります。通信途中でエラーが発生した場合、自社システムでは「送信中」のままでも、外部側では処理が完了している可能性があります。そのため、送受信一覧APIなどを利用した結果確認や、定期的なステータス照合を前提とした設計が重要になります。

7.7 利用者・事業所情報の照合エラー

介護情報基盤との連携では、既存システムに登録されている利用者情報や事業所情報が、外部側の情報と正しく一致することが重要です。表記揺れや古い情報、入力ミスなどが残っている場合、データ登録・連携時のエラーにつながる可能性があります。そのため、移行前には単なるシステム改修だけでなく、既存マスターデータの確認・クレンジングも検討する必要があります。

7.8 セキュリティ・アクセス権限

ケアプランや要介護認定情報などは、利用者の重要な個人情報です。API化によってシステム間で情報を取得できる範囲が広がるほど、

「接続できるか」だけでなく「誰が何を閲覧・操作できるか」

を適切に管理することが重要になります。認証・認可、権限管理、通信ログ、操作ログなどを整備し、問題発生時に「誰が・いつ・どのデータへアクセスしたのか」を追跡できる仕組みが必要です。

7.9 本番切替時の業務停止リスク

介護現場ではケアプランの送受信が日常業務として継続するため、システム移行のために長期間業務を停止することは現実的ではありません。

そのため、

旧環境 → 並行運用 → 新環境

という段階的な切替を検討することが重要です。本番移行前には、実際の業務を想定したデータで送受信・エラー・再送・復旧まで確認し、新システムで問題が発生した場合のFallback方法も準備しておく必要があります。

移行リスクは「API開発」だけではない

今回の移行で特に注意すべきポイントを整理すると、以下のようになります。

リスク	主な対策
データ仕様の不一致	Gap Analysis・Data Mapping
仕様変更	Adapter化・Version管理
新旧方式の共存	連携方式の切替管理
二重送信・登録	ID管理・冪等性・重複チェック
API・通信障害	Retry・Fallback・エラー管理
ステータス不整合	結果照合・同期処理
マスターデータ不整合	Data Cleansing・Validation
セキュリティ	認証・認可・Audit Log
本番移行障害	Parallel Run・Rollback Plan

VIII – まとめ｜「ファイル連携」から「システム連携」へ

2026～2027年は、ケアプランデータ連携にとって大きな転換期となります。

介護情報基盤の利用開始、介護WEBサービスへの移行、ケアプランデータ連携標準仕様4.1／5.0への対応、そしてAPI連携の導入により、これまでの「人がファイルを送受信する仕組み」から「システム同士がデータを連携する仕組み」へと移行していきます。

介護事業者にとっては、データ入力や送受信などの業務負担を見直す機会となり、介護ソフトベンダーにとっては、既存製品のデータ構造や連携方式、システムアーキテクチャを見直す重要なタイミングとなります。

一方、既存介護ソフトでは、現在のデータ構造や連携方式によって必要な改修範囲が大きく異なります。そのため、まずは現行システムと新標準／API仕様との差分を整理し、WEB利用型、Adapter／Middleware型、API Native型のどの方式が適しているかを判断することが重要です。

介護情報基盤・介護WEBサービスへの移行対応をはじめ、既存システムの調査、Gap Analysis、データマッピング、API連携などについてご相談がございましたら、お気軽にお問い合わせください。

お問い合わせ：[email protected]

日本国内にも担当スタッフがおりますので、オンラインでのお打ち合わせはもちろん、ご要望に応じて直接お伺いしてご相談することも可能です。