---
title: "介護ソフトの選び方｜サービス種別・規模で決める要件と2026年度の制度対応【2026年版】"
url: "https://www.issoh.co.jp/column/details/16046/"
published: 2026-08-02
updated: 2026-09-30
categories: ["介護・医療"]
publisher: "株式会社一創"
---

# 介護ソフトの選び方｜サービス種別・規模で決める要件と2026年度の制度対応【2026年版】

介護ソフトの選び方でつまずく事業所は、製品カタログを開く順番が早すぎます。デモを3社見た時点で判断軸が製品側の言葉に引きずられ、自事業所に必要だった条件が抜け落ちるからです。この記事で扱うのは、製品を見る前に確定させる要件を、サービス種別・事業所規模・職員のIT習熟度という3つの入口から組み立てる手順です。

あわせて、請求特化型から経営管理型までの4類型の選び分け、令和8年度の期中改定と2027年1月のケアプランデータ連携システム統合を受けてベンダーに確認する項目、圏外での記録やBCPを理由にクラウド型を外す条件、候補製品を点数で比べる評価シートの作り方、乗り換え時に過去データをどこまで持ち出せるかまで、受託開発会社の立場で判断を示します。介護ソフトそのものの定義や機能の全体像は[介護ソフトの定義と機能・提供形態を整理した記事](https://www.issoh.co.jp/column/details/16041/)にまとめてあります。

## まとめ：介護ソフトの選び方を要件確定・種類選択・移行可否の3段で決める順序

結論を先に置きます。介護ソフトの選び方は、製品比較の前に「自事業所の条件を要件へ翻訳する」段階でほぼ決まるものです。ここを飛ばした選定は、どの製品を選んでも同じ理由で失敗します。

順序は3段です。第1段は要件確定。サービス種別（施設系・通所系・訪問系・居宅介護支援）、事業所数、算定している加算、職員のIT習熟度の4項目を書き出し、必須要件を3つまでに絞ります。第2段が種類の選択で、請求特化型・記録特化型・統合型・経営管理型のどのスコープを買うかを決めます。第3段が提供形態と移行可否の判断。クラウド型を選ばない条件に自事業所が当てはまるか、既存ソフトからデータを持ち出せるかを確認します。

必須要件は3つまで。10個並べると全製品が落ち、結局は営業担当の印象で決めることになります。逆に必須が1つだと候補が絞れません。優先度をつけたうえで、残りは加点要件へ落としてください。

2026年度に選ぶ場合は、この3段に制度対応の確認を重ねます。令和8年度の期中改定で処遇改善加算の上乗せ区分が新設され、訪問・通所系ではケアプランデータ連携システムの利用が算定要件に入りました。さらに同システムは2027年1月に介護情報基盤の入口となる介護WEBサービスへ統合される予定です。介護ソフトがこの2つに追随できるかは、どのサービス種別でも必須要件の候補になります。

| 段階        | 決めること         | 判断の材料            |
| --------- | ------------- | ---------------- |
| 第1段 要件確定  | 必須要件3つと加点要件   | 種別・事業所数・加算・習熟度   |
| 第2段 種類選択  | 買う機能スコープ      | 手作業で最も時間を取る業務    |
| 第3段 形態と移行 | クラウド型の適否と移行範囲 | 通信環境・契約制限・書き出し形式 |
| 横断 制度対応   | 改定と基盤統合への追随   | ベンダーの書面回答        |

## サービス種別と事業所規模から介護ソフトの必須要件を確定させる分岐の切り方

介護ソフトは「介護事業所向け」という括りでは選べません。同じ言葉で呼ばれていても、施設系と訪問系では必要な機能の中心がずれます。

### 施設系・通所系・訪問系・居宅介護支援で分かれる必須要件の具体的な差

サービス種別が違えば、記録を取る場所も、請求で通す単位も変わります。施設系は24時間の記録が連続し、夜勤帯の申し送りとバイタル記録が中心になります。通所系は送迎と当日キャンセルの振替処理、訪問系は移動中の入力とサービス提供責任者のスケジュール調整、居宅介護支援はケアプラン作成と給付管理が軸です。

| サービス種別      | 選定で最初に確認する要件    | 外せない周辺機能       |
| ----------- | --------------- | -------------- |
| 施設系（特養・老健等） | 24時間記録と申し送りの連続性 | 夜勤シフト・バイタル・食事量 |
| 通所系（デイ等）    | 送迎管理と当日変更の振替    | 加算算定判定・入浴記録    |
| 訪問系（訪問介護等）  | 圏外・移動中の入力手段     | 実績確認・サ責のスケジュール |
| 居宅介護支援      | 給付管理とケアプラン様式    | ケアプランデータ連携対応   |

表の右列は、カタログでは「標準搭載」と書かれていても実務で使えるかは別問題になる箇所です。デモでは必ず自事業所の様式で操作させてもらってください。居宅介護支援と、居宅介護支援とやり取りする訪問・通所の事業所で最初に聞くのは、国民健康保険中央会が運営する[ケアプランデータ連携システム](https://www.kokuho.or.jp/system/care/careplan/)への介護ソフトの対応です。ライセンス料は1事業所番号あたり年額21,000円ですが、2025年6月に始まったフリーパスキャンペーンは、2026年9月時点の[大阪府の案内ページ](https://www.pref.osaka.lg.jp/o090100/careplan/index.html)によれば介護WEBサービスへの統合日まで延長され、令和8年度中は利用料が無料、統合後も利用料の負担は発生しない扱いと示されています。システムの利用要件や導入手順の細部は[ケアプランデータ連携システムの利用要件と導入手順を整理した記事](https://www.issoh.co.jp/column/details/16528/)で扱っています。

### 事業所数と職員のIT習熟度で変わる要件の重み付けと妥協できる範囲

1事業所で運営しているなら、経営管理機能は不要です。管理者が数字を見たい場面は月次の請求額と稼働率くらいで、それは請求機能の帳票で足ります。ここに横断分析やダッシュボードを求めると、使わない機能に月額を払い続けることになりました。

分岐は3事業所です。3事業所を超えると、事業所ごとに集計をExcelへ書き出す作業が管理者の負担として表面化します。この規模から経営管理機能の価値が出ます。

職員のIT習熟度は、要件ではなく妥協ラインの設定に効きます。平均年齢が高く、私物スマートフォンの操作に不安がある職員が半数を超える現場では、入力画面の階層が3階層を超える製品は定着しません。多機能な製品を入れて紙の記録が残った事業所を、私たちは何度も引き継いできました。機能の豊富さより、1記録あたりのタップ数を優先してください。

### 複数サービス種別を1法人で運営する場合に先に決める統合の範囲

特養とデイと居宅を同一法人で運営している場合、選び方の論点は「1製品で全種別を賄うか」に移ります。全種別対応をうたう統合型は確かに存在しますが、種別ごとの作り込みの深さには差があります。訪問系に強い製品が施設系の夜勤記録では薄い、といった製品ごとの偏りはごく一般的です。

判断の基準は利用者数の重心です。全利用者の7割以上が1つの種別に集中しているなら、その種別に強い製品を主軸に据え、残りは別製品か手作業で回すほうが総合的な使い勝手は上がります。逆に3割ずつ分散しているなら、統合型を選んで種別ごとの不足をカスタマイズで埋める設計が妥当です。金額の比較まで進む段階に来たら、[課金方式ごとの月額と5年総額を整理した記事](https://www.issoh.co.jp/column/details/16045/)で、種別を分けた場合の合計を先に出しておくと判断が早くなります。

障害福祉サービスを併設している法人は、もう1段の注意が要ります。介護保険と障害福祉では報酬体系も請求先の様式も別で、介護ソフトの障害福祉対応は「オプションで請求だけ出せる」水準の製品も混ざります。併設事業所の比重が大きいなら、[障害福祉ソフトと介護ソフトの制度差を整理した記事](https://www.issoh.co.jp/column/details/16879/)で線引きを先に確かめてください。

## 介護ソフトの種類を機能スコープの4類型で選び分ける判断基準と適合条件

介護ソフトの「種類」は、クラウド型かインストール型かという提供形態の話に流れがちです。実務で先に決めるべきは、どこまでの業務を1つの製品で持つかという機能スコープのほうでした。

### 請求特化型・記録特化型・統合型・経営管理型で異なる守備範囲の線引き

機能スコープで分けると、介護ソフトは4類型に整理できます。請求特化型は国保連への介護給付費請求と加算算定に絞った構成で、翌月10日の締切を確実に通す役割です。請求特化型と国保連の伝送ソフトの違い、返戻が出たときの対応範囲は[介護請求ソフトと伝送ソフトの違いをまとめた記事](https://www.issoh.co.jp/column/details/16050/)で別に扱いました。記録特化型は介護記録とLIFEへのデータ提出が中心で、請求は別製品に任せる構成です。電子化する記録の範囲をどこで切るか、入力端末をどう決めるかは[介護記録システムの導入判断をまとめた記事](https://www.issoh.co.jp/column/details/16048/)で扱っています。統合型は請求・記録・計画・シフトを1つに束ねた構成、経営管理型はそこへ複数事業所の横断集計と収支分析を足したものです。

選び分けの基準は、いま手作業で最も時間を取られている業務がどこかという1点です。月末月初の請求作業が残業の主因なら請求特化型で足りますし、日中の記録転記が主因なら記録特化型から入るほうが投資対効果は出ます。全部を一度に入れ替える判断は、既存製品の契約更新が近い場合か、複数事業所を同時に立ち上げる場合に限ります。

### 単機能の組み合わせが成立する条件と連携部分で詰まりやすい箇所

請求特化型と記録特化型を組み合わせる構成は、月間の請求件数がおおむね100件を下回る規模なら成立します。記録から実績への転記が手作業で残っても、100件程度なら月に数時間で終わるからです。

詰まるのは連携部分です。記録側で入力したサービス提供実績を請求側へ渡す経路がCSVの手動書き出ししかない場合、様式が変わるたびに手作業が増えます。特に加算の算定根拠となる記録（機能訓練の実施記録、口腔・栄養関係の記録など）は、請求側が求める粒度と記録側の保存形式が一致しないことが多くありました。組み合わせを選ぶなら、この受け渡しを誰がいつやるかを決めてから契約してください。

### 種類の選択を誤った事業所に共通して現れる運用上の症状と手戻り

スコープを間違えた事業所には、共通した症状が出ます。統合型を入れたのに記録だけ紙が残っている、経営管理型を入れたのに分析画面を誰も開いていない、請求特化型で足りたはずが統合型の月額を払っている、の3つです。

症状が出るまでの期間はおおむね3か月から6か月。導入直後は「慣れの問題」として扱われ、半年経って初めて定着していないと判明します。ここから別製品へ乗り換えると、データ移行費と職員の再教育で初期投資がほぼ二重になりました。だからこそ、スコープの決定は要件確定の段階で終わらせておく必要があります。候補製品を実際に落としていく手順は[比較の進め方とトライアル評価をまとめた記事](https://www.issoh.co.jp/column/details/16043/)に分けて書いています。

## 2026年度の制度変更から逆算する介護ソフトの選び方と確認する対応項目

2026年度に介護ソフトを選ぶ事業所は、2つの制度変更を選定条件へ組み込む必要があります。1つは令和8年度の期中改定、もう1つはケアプランデータ連携システムの介護情報基盤への統合です。どちらもソフト側の対応が遅れると、事業所側の努力では埋められません。

### 令和8年度期中改定で処遇改善加算の上乗せ区分に入った連携の利用要件

厚生労働省の[令和8年度介護報酬改定の概要資料](https://www.mhlw.go.jp/content/12300000/001647819.pdf)によると、期中改定の改定率はプラス2.03％です。介護従事者を対象に月1.0万円（3.3％）の賃上げ措置を講じ、生産性向上や協働化に取り組む事業者の介護職員には月0.7万円（2.4％）を上乗せする設計になっています。上乗せを受ける区分として処遇改善加算に「加算Ⅰロ」「加算Ⅱロ」が新設され、訪問看護・訪問リハ・居宅介護支援なども新たに処遇改善加算の対象へ加わりました。

選び方に直結するのは、上乗せ区分の特例要件です。同資料では、訪問・通所サービス等はケアプランデータ連携システムへの加入と実績報告、施設サービス等は生産性向上推進体制加算ⅠまたはⅡの取得と実績報告、あるいは社会福祉連携推進法人への所属のいずれかを満たすこととされています。申請時点では加入・取得の誓約で算定できる配慮措置があるものの、実績報告で問われるのは利用の実態です。様式や通知の最新版は[厚生労働省の令和8年度介護報酬改定のページ](https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000188411%5F00073.html)に集約されています。

ここから導かれる確認項目は明快です。訪問・通所系なら「ケアプランデータ連携システムの標準仕様でCSVを出し入れできるか」、施設系なら「生産性向上推進体制加算で求められる見守り機器等の導入効果のデータを出せるか」を、デモの前に書面で聞いてください。見守りセンサーとの接続を含めた機器構成は[介護IoTシステムの構成と介護ソフト連携を扱った記事](https://www.issoh.co.jp/column/details/16673/)が参考になります。

### 2027年1月のケアプランデータ連携システム統合と介護WEBサービスへの移行準備

厚生労働省が2026年8月に示した[ケアプランデータ連携システムの統合に関する説明資料](https://www.mhlw.go.jp/content/12306000/001742527.pdf)では、2027年（令和9年）1月予定で、ケアプランデータ連携システムが介護保険資格確認等WEBサービス（以下、介護WEBサービス）の中に構築されると示されています。同資料は2026年7月から12月を事業所の引っ越し準備期間と位置づけ、事業所側の準備として次の4工程を挙げています。

- 介護情報基盤ポータルのユーザ登録（電子請求受付システムのIDとパスワードで認証）
- 電子証明書のインストール（発行者が「e-seikyuu CA」のものを、使う端末ごとに入れる）
- 閲覧に使う端末とカードリーダーの用意（マイナンバーカードでの本人確認をパソコンで行う場合）
- マイナ資格確認アプリのインストールと利用申請、介護WEBサービスでの認証とログイン

このうち端末の準備は、介護ソフトの選び方と直接絡む工程です。電子証明書は端末ごとに必要なので、クラウド型の介護ソフトをタブレット中心で運用する事業所は、証明書を入れる端末を何台にするかを先に決めておかないと、ソフトの端末計画と二重に揃えることになります。助成金を使って導入支援事業者に作業を依頼できる旨も同資料に記載があり、端末や周辺機器の費用は[介護テクノロジー導入支援事業の対象経費を整理した記事](https://www.issoh.co.jp/column/details/17224/)とあわせて見積もると抜けが減ります。

### 介護情報基盤で共有される情報と介護ソフトのAPI対応版をベンダーに問う方法

厚生労働省の[介護情報基盤を紹介するWebマガジン](https://www.mhlw.go.jp/web%5Fmagazine/series/20260501.html)では、介護情報基盤は2026年4月から準備が完了した自治体で順次使えるようになると説明されています。集約されるのは介護保険証等情報、要介護認定情報、住宅改修費利用等情報、ケアプラン情報、LIFE情報の一部などです。LIFEそのものの提出様式やフィードバックの仕組みは[厚生労働省の科学的介護のページ](https://www.mhlw.go.jp/stf/shingi2/0000198094%5F00037.html)で確認できます。

前述の統合説明資料には、自治体が介護情報基盤の運用を始めると、介護ソフト（API5.0版）からケアプランが介護情報基盤へ格納されるという流れが示されています。つまり介護ソフト側がこの版に追随しないと、事業所は介護WEBサービスの画面へ手で登録し直す運用になります。ベンダーには「対応予定」ではなく、次の3点を書面で求めてください。

- 介護WEBサービスとの連携に対応する版の提供予定月と、追加費用の有無
- 所在地の市町村が運用を始める前後で、画面や操作がどう変わるか
- 令和9年度の報酬改定（2027年4月施行見込み）と統合作業が重なったときの対応の優先順位

統合の月と次期改定の施行月は3か月しか離れていません。ベンダーの開発体制に余裕がないと、どちらかの対応が後ろへずれる可能性があります。回答が曖昧な製品は、他の条件がよくても必須要件で落とす判断が妥当だと考えます。

## クラウド型の介護ソフトを選ぶ条件と選ばない条件を分ける通信環境の前提

2026年時点で、新規に導入される介護ソフトの多くはクラウド型です。初期費用0円で月額5,000円台から始められる製品が主流になり、法改正時の更新作業がベンダー側で完結する点も選ばれる理由になっています。前述の期中改定や基盤統合のように制度側の変更が続く時期ほど、更新作業を自前で抱えないクラウド型の利点は大きくなります。ただし、全事業所に当てはまる選択ではありません。

### 訪問系のオフライン入力と圏外での記録から見たクラウド型の適否

訪問系で真っ先に確認するのは、通信が届かない場所での挙動です。マンションの地下駐車場、山間部、鉄筋の建物内では電波が落ちます。ここで入力中のデータが消える製品は、現場が使うのをやめます。

確認する言い回しは具体的にします。「オフライン対応していますか」ではなく、「機内モードで記録を入力し、アプリを閉じて再度電波が入ったとき、その記録は保存されていますか」と聞いてください。前者にはほぼ全社が「対応しています」と答えますが、実際には閲覧のみキャッシュされる製品と、入力データをローカル保持して後で同期する製品が混在しています。訪問系ならローカル保持が必要です。

### タブレットとスマートフォンの前提条件と見守り機器との接続可否

入力端末をどれにするかは、選定条件そのものです。iPad前提の製品をAndroidタブレットで動かそうとして、カメラ連携や手書き入力が使えなかった事例があります。ブラウザ対応をうたう製品でも、実機での動作確認済みOSバージョンは限定されているのが実情です。

すでに見守りセンサーやインカムを導入している事業所では、そちらとの接続可否も先に確認します。センサーの検知履歴を介護記録へ自動で書き込めるかどうかで、夜勤帯の記録工数は変わります。接続できない場合、センサーの管理画面と介護ソフトを職員が二重に見る運用になり、導入した機器の効果が相殺されました。

### 個人情報の取り扱いとBCPを理由にクラウド型を外す3つの具体条件

クラウド型を選ばない判断が正しい場面は、はっきりしています。次の3条件のいずれかに当てはまるなら、インストール型を残すか、専用線を引いたうえでの導入を検討してください。

- 事業所の所在地が慢性的に回線品質の低い地域で、代替の回線契約も現実的でない場合
- 自治体や委託元との契約で、利用者情報の保管場所や外部委託先が具体的に制限されている場合
- 災害時に一定期間の孤立が想定され、通信断中も記録の入力と参照を継続する必要がある場合

逆に言えば、この3条件に当てはまらないならクラウド型を外す理由はありません。「情報漏えいが不安だから」という理由だけでインストール型を選ぶのは、判断として弱いと考えます。事業所内のPCで管理するほうが、端末の紛失・盗難とバックアップ不備という別のリスクを抱え込むからです。介護記録の保存義務は完結の日から2年間、自治体の条例で5年としている地域もあり、その期間の保全責任を自前で持てるかを冷静に見てください。

3つ目の条件に当たるかどうかは、事業所の業務継続計画と突き合わせると判断しやすくなります。通信断の想定時間、紙の記録へ切り替える手順、復旧後にどこまで転記するかが計画に書かれていれば、それがそのまま介護ソフトへの要件になります。計画の策定手順は[介護BCPの義務化と策定手順をまとめた記事](https://www.issoh.co.jp/column/details/10939/)を参照してください。

## 現場が使わなくなる介護ソフトの選び方の失敗型と選定体制の組み直し方

失敗した選定には型があります。製品の性能ではなく、選ぶ体制のほうに原因が集中していました。

### 管理者だけで決めた選定が3か月で形骸化する場面と現場を入れる工程

施設長と事務長だけで製品を決め、稼働後に現場へ下ろす。この進め方は、記録業務の負荷が現場に偏る介護の職場では機能しません。判断者が日々の記録を入力しないため、1記録あたりの手数という最大の評価軸が選定に反映されないからです。

現場を入れる工程は2箇所だけです。1つはデモの立ち会いで、記録を最も多く入力する職員を1名から2名、必ず同席させます。もう1つはトライアル期間の評価で、実際に1週間入力してもらい、紙の記録に戻りたいと感じた場面を書き出してもらいます。全職員の合議で決める必要はありません。人数を増やすほど結論が出なくなります。入力担当者の代表2名の評価を、選定の必須要件として扱えば足ります。

### 機能数の多さを基準に選んだ結果として増える入力工数とその削り方

機能が多い製品を選ぶ判断は、ほとんどの中小規模事業所で外れます。理由は単純で、使わない機能の入力欄が画面に残り、1記録あたりのタップ数と迷いを増やすからです。

回避策は、契約前に「初期表示から隠せる項目の範囲」を確認することです。項目の表示・非表示を事業所ごとに設定できる製品と、全項目が固定表示の製品があります。後者を選ぶなら、自事業所が使う項目の比率が7割を超えているかを見てください。半分も使わない製品を入れて、現場が空欄を飛ばしながら入力する運用は、記録の抜けを構造的に生みます。

### 加算算定とLIFE提出の確認を後回しにした選定で起きる手戻り

算定している加算への対応確認を、契約後に回してはいけません。ここは減収に直結します。処遇改善関係の加算、入所系の各種体制加算、科学的介護推進体制加算などは要件が細かく、製品側の対応が「様式は出せるが判定はしない」という水準にとどまる場合があります。

確認の手順は、算定している加算を全て書き出し、各加算について「算定要件の判定を自動で行うか」「必要な帳票を出力できるか」「LIFEへ提出するデータを作成できるか」の3点を製品ごとに◯×で埋めてもらうことです。口頭ではなく書面で受け取ります。介護報酬改定は3年周期で、直近の定期改定が令和6年度、令和8年度には期中改定が入り、次期の定期改定は令和9年度（2027年4月）の施行が見込まれています。2年続けて改定をまたぐ前提で、対応方針を契約前に文書で確認しておくのが安全です。

## 介護ソフトの選び方を点数で比べる評価シートの作り方と集計の手順

候補が3社まで絞れたら、印象ではなく同じ物差しで比べます。ここで使うのが評価シートです。表計算ソフト1枚で作れますが、列の設計を誤ると必須要件を満たさない製品が合計点で上位に来る、という逆転が起きます。

### 必須要件と加点要件を分けて重みを付ける評価シートの列の設計方法

評価シートは「1行＝1製品×1項目」の縦持ちで作ります。列は製品、項目、区分、重み、判定の5つ。区分は「必須」と「加点」の2種類に限り、必須は重みを持たせません。必須を1つでも落とした製品は、加点の合計にかかわらず候補から外すためです。

| 項目の例                  | 区分 | 重み |
| --------------------- | -- | -- |
| 機内モードの入力が再接続後に残る      | 必須 | なし |
| ケアプランデータ連携のCSV入出力     | 必須 | なし |
| 介護WEBサービス連携版の提供月を書面回答 | 必須 | なし |
| 入力項目を事業所ごとに非表示にできる    | 加点 | 3  |
| 見守りセンサーの記録を自動取込       | 加点 | 2  |
| 既存ソフトからの移行支援が契約に含まれる  | 加点 | 2  |

判定欄は◯か×だけにします。「△」を許すと、営業担当の説明を好意的に解釈した△が積み上がり、比較の意味が薄れます。迷う項目はトライアルで実際に操作し、できたかできなかったかで埋めてください。

### 評価シートのCSVから必須未達の製品を除外して加点を集計するスクリプト

シートをCSVで保存すれば、集計は短いスクリプトで片付く作業です。次のPythonは、必須を1つでも落とした製品を「除外」と表示し、残った製品を加点の合計順に並べます。Python 3.12系以降で、標準ライブラリだけで動きます。

```
製品,項目,区分,重み,判定
A社,機内モードの入力が再接続後に残る,必須,0,◯
A社,ケアプランデータ連携のCSV入出力,必須,0,◯
A社,入力項目を事業所ごとに非表示にできる,加点,3,◯
B社,機内モードの入力が再接続後に残る,必須,0,×
B社,ケアプランデータ連携のCSV入出力,必須,0,◯
B社,入力項目を事業所ごとに非表示にできる,加点,3,◯
```

```
# hyouka.py：評価シート（1行=1製品×1項目）を集計する
import csv

with open("hyouka.csv", encoding="utf-8-sig", newline="") as f:
    rows = list(csv.DictReader(f))

products = {}
for r in rows:
    p = products.setdefault(r["製品"], {"score": 0, "failed": []})
    ok = r["判定"] == "◯"
    # 必須の未達は加点に関係なく除外理由として記録する
    if r["区分"] == "必須" and not ok:
        p["failed"].append(r["項目"])
    elif r["区分"] == "加点" and ok:
        p["score"] += int(r["重み"])

for name, p in sorted(products.items(), key=lambda x: -x[1]["score"]):
    if p["failed"]:
        print(f"{name}: 除外（未達: {'、'.join(p['failed'])}）")
    else:
        print(f"{name}: {p['score']}点")
```

上のサンプルで実行すると、B社は加点が同じ3点でも「除外（未達: 機内モードの入力が再接続後に残る）」と出力される仕組みです。Excelで保存したCSVは先頭にBOMが付くことがあるため、文字コードを utf-8-sig で開いています。合計点が並んだら、上位2社をもう一度現場の代表2名に触ってもらい、最終決定とします。点数は判断を置き換えるものではなく、判断の根拠を後から説明できる形で残すための道具です。

## 乗り換えで介護ソフトの選び方が変わる要件とデータ移行の可否判断

新規導入と乗り換えでは、選び方の前提が変わります。乗り換えでは「移行できるか」が要件の最上位に来るためです。

### 既存ソフトから移行できるデータ範囲を選定条件へ組み込む具体手順

最初にやるのは、既存ベンダーへの照会です。利用者基本情報、サービス提供実績、介護記録、ケアプラン、請求履歴の5区分について、どの形式で書き出せるかを確認します。ここで「CSVで出せます」という回答だけを受け取ると失敗します。項目の並びと文字コード、1ファイルあたりの件数上限まで聞いてください。

移行できる範囲には現実的な限界があります。利用者基本情報と請求履歴は移せることが多い一方、日々の介護記録は自由記述の構造が製品ごとに違うため、移行対象外となる場合もあるのが実情です。記録が移せないなら、旧システムを参照専用で一定期間残すか、PDFで書き出して保管するかを決めます。保存義務の期間を満たせる方法かどうかが判断基準です。

書き出しのサンプルを受け取ったら、移行先ベンダーへ渡す前に自分たちで中身を確かめます。次のスクリプトは、文字コードを判定し、見出し行と列数が合わない行を列挙します。介護記録の自由記述には改行が含まれるため、行単位で分割せずCSVとして読む作りにしました。

```
# check_export.py：旧ソフトの書き出しCSVを検査する（使い方: python check_export.py riyousha.csv）
import csv
import io
import sys

raw = open(sys.argv[1], "rb").read()
for enc in ("utf-8-sig", "cp932"):
    try:
        text = raw.decode(enc)
        break
    except UnicodeDecodeError:
        continue
else:
    sys.exit("文字コードを判定できません")

rows = list(csv.reader(io.StringIO(text)))
header, body = rows[0], rows[1:]
print("文字コード:", enc, "列数:", len(header), "件数:", len(body))
bad = [i + 2 for i, r in enumerate(body) if len(r) != len(header)]
print("列数が合わない行:", bad[:20] or "なし")
```

cp932で読めた場合は、旧字体や機種依存文字が利用者の氏名に含まれていないかも目で確認してください。移行先がUTF-8前提だと、ここで文字化けが起きます。列数が合わない行が出たら、区切り文字のカンマが自由記述の中に紛れて引用符で囲まれていない可能性があり、旧ベンダーに書き出し設定を直してもらう必要があります。

### 並行稼働の期間と契約更新月から逆算して決める切り替え時期の目安

切り替え時期は、月初の請求作業を避けて設計します。国保連への請求は翌月10日が締切のため、月初は現場も事務も動かせません。切り替えは月の中旬から下旬に置き、最低1か月は新旧を並行稼働させます。

逆算の起点は既存契約の更新月です。多くの製品が年間契約のため、更新月の2か月前には新製品を決めておく必要があります。要件確定に2週間、候補の絞り込みとデモに1か月、トライアルに2週間と見ると、更新月の4か月前には動き出す計算になりました。介護報酬改定を挟む年度は、改定対応が終わった6月以降に切り替えるほうが混乱は少なくなります。

2026年度から2027年度にかけては、この逆算にもう1つの山が加わります。2027年1月予定のケアプランデータ連携システムの統合と、同年4月施行見込みの次期改定です。この2つの間に介護ソフトの切り替えを重ねると、3つの変更を同時に抱えることになります。更新月が2026年12月から2027年4月の間に来る事業所は、切り替えを2026年秋までに前倒しするか、2027年6月以降へ送るかを先に決めてください。

### 既製品で埋まらない要件を連携開発で補う判断の分かれ目と発注範囲

必須要件のうち1つが、どの製品でも満たせない。この状況は珍しくありません。独自の帳票様式、自治体固有の書式、既存の勤怠システムや会計システムとのデータ連携などが典型です。

判断の分かれ目は、その要件が「毎月発生する定型作業」かどうかに置きます。毎月の作業なら、既製品を主軸に据えたうえで連携部分だけを開発するほうが、5年で見た総コストは下がります。年に数回の作業なら、手作業で回して開発しないのが正解です。発注範囲も限定してください。介護ソフト本体を作り直すのではなく、既製品のAPIやCSV出力を受けて自社の様式へ変換する部分に絞れば、開発規模は小さく収まります。この形の[医療機関向けシステム開発・連携開発](https://www.issoh.co.jp/service/business%5Fsystem/medical/)は、既存パッケージを残したまま不足分だけを埋める進め方が取れます。業種を問わない業務システム全体の考え方は[業務システムの種類と導入形態を整理した記事](https://www.issoh.co.jp/column/details/12886/)を参照してください。

## よくある質問

介護ソフトの選び方について、事業所からの相談で繰り返し受ける質問をまとめました。

### 介護ソフトの選び方で最初に決めることは何ですか？

製品ではなく、自事業所の必須要件を3つに絞ることです。サービス種別、事業所数、算定している加算、職員のIT習熟度の4項目を書き出し、そこから「これを満たさない製品は候補から外す」という条件を3つ立てます。必須要件を10個並べると全製品が落ち、結局は営業担当の印象で決めることになります。2026年度に選ぶなら、ケアプランデータ連携システムと介護WEBサービスへの対応予定も必須要件の候補に入れてください。

### 介護ソフトの種類はどう分ければよいですか？

クラウド型かインストール型かという提供形態より先に、機能スコープで分けてください。請求特化型、記録特化型、統合型、経営管理型の4類型です。選び分けの基準は、いま手作業で最も時間を取られている業務がどこかという1点に置きます。月末月初の請求が残業の主因なら請求特化型、日中の記録転記が主因なら記録特化型から入ると投資対効果が出ます。

### クラウド型とインストール型のどちらを選ぶべきですか？

原則としてクラウド型を選び、外す条件に当てはまる場合だけインストール型を検討します。外す条件は、回線品質が慢性的に低く代替回線も現実的でない場合、契約で情報の保管場所や委託先が制限されている場合、災害時の孤立を想定して通信断中も記録を継続する必要がある場合の3つです。漠然とした不安だけを理由にインストール型を選ぶと、端末の紛失やバックアップ不備という別のリスクを抱えます。

### 小規模な事業所でも統合型の介護ソフトを選ぶ意味はありますか？

1事業所で運営しているなら、経営管理機能まで含む構成は過剰です。管理者が見たい数字は月次の請求額と稼働率程度で、請求機能の帳票で十分です。経営管理機能の価値が出るのは3事業所を超えたあたりからで、そこから事業所ごとの集計をExcelへ書き出す手間が管理者の負担として表面化します。小規模なら請求と記録に絞り、浮いた月額を端末整備へ回すほうが現場は動きます。

### 介護ソフトを乗り換えるとき、過去の記録は引き継げますか？

区分によって変わります。利用者基本情報と請求履歴は移せることが多い一方、日々の介護記録は自由記述の構造が製品ごとに違うため、移行対象から外れる場合があります。既存ベンダーへ、5区分それぞれの書き出し形式・項目の並び・文字コード・件数上限を照会し、受け取ったサンプルは文字コードと列数を自分たちでも検査してください。記録が移せない場合は、旧システムを参照専用で残すかPDFで保管するかを決め、保存義務の期間を満たせるかで判断します。

## 関連記事

- [介護ソフトとは？機能・種類とクラウド／オンプレの選び方](https://www.issoh.co.jp/column/details/16041/)：介護ソフトの定義、機能5系統、提供形態の全体像を先に押さえたい場合はこちらから読んでください。
- [介護ソフトの比較｜候補を3社へ絞り込む選定軸と打ち切り条件](https://www.issoh.co.jp/column/details/16043/)：本記事で要件を固めたあと、実際に製品を落としていく手順をまとめています。
- [介護ソフトの費用相場と5年総額｜課金方式別の月額と隠れコスト](https://www.issoh.co.jp/column/details/16045/)：課金方式ごとの実額と、見積書に載らない運用コストの試算を扱っています。
- [ケアプランデータ連携システムとは｜利用要件と導入手順、介護ソフト連携の確認点](https://www.issoh.co.jp/column/details/16528/)：処遇改善加算の特例要件に関わる連携システムの手続きを確認できます。
- [介護請求ソフトとは｜国保連伝送ソフトとの違いと返戻対応](https://www.issoh.co.jp/column/details/16050/)：請求特化型を選ぶ場合の守備範囲と連携開発の判断を扱っています。
- [介護施設の勤怠管理システムとは｜夜勤シフトと法定要件](https://www.issoh.co.jp/column/details/15382/)：シフト・勤怠を介護ソフトから分ける構成を検討する際の判断材料になります。
- [業務システムとは？種類と導入形態の選び方](https://www.issoh.co.jp/column/details/12886/)：業種を問わない業務システムの分類と、パッケージと開発の線引きを整理しています。

---

出典: [介護ソフトの選び方｜サービス種別・規模で決める要件と2026年度の制度対応【2026年版】](<https://www.issoh.co.jp/column/details/16046/>)（株式会社一創）