居宅介護支援事業所のKPIは「件数」だけじゃない — 収益・業務負荷・紹介元を統合可視化するダッシュボード設計

対象読者: 居宅介護支援事業所の経営者、複数拠点を運営する管理者、データドリブン経営を目指す事業者 この記事で分かること: 居宅事業の経営判断に本当に必要なKPIは何か、CareSpace OSがダッシュボードでどう統合したか 読了目安: 7分

居宅の経営者が「数字で見えていない」3つのこと

居宅介護支援事業所の経営者に話を聞くと、ほぼ全員が同じことを言う。「うちの事業所は黒字。たぶん」。

なぜ「たぶん」か。理由は単純だ。経営判断に必要な数字が、月単位でも見えていないから。

具体的に何が見えていないか。

1. 拠点・サービスごとの収益

居宅介護支援事業所が小規模多機能や訪問介護を併設している場合、サービスごとの収支が分離されていないケースが多い。「全体で黒字」は分かるが、「居宅は黒字だが訪問介護は赤字」「特定の拠点だけ赤字」が見えない。経営判断（撤退・縮小・拡大）の根拠が定性的になる。

2. ケアマネ1人あたりの業務負荷

ケアマネA: 担当35件、月の残業40時間。 ケアマネB: 担当32件、月の残業10時間。 これは何を意味するか。Aは利用者対応に時間がかかる重度利用者を多く持っているのか、業務効率が悪いのか、件数の偏りなのか。原因を切り分けるには、件数・残業・サービス担当者会議の頻度・新規受け入れ数・離脱数を統合して見る必要がある。

3. 紹介元別の貢献度

「あの病院の連携室から月2件来ている」「あの包括から月1件来ている」。これは把握している。ただ、「その後の継続率」「平均利用期間」「離脱理由」まで紹介元ごとに集計できているか。これが見えないと、「どの紹介元との関係を強化すべきか」の判断ができない。

これらが見えない結果、経営判断は「経験と勘」に依存する。それでも回るのが介護事業の良いところでもあり、限界でもある。

CareSpace OSのKPIダッシュボードが統合したもの

CareSpace OSの /analytics/ ダッシュボードは、上記3つを含む居宅経営の重要KPIを統合可視化している。

主なタブ構成:

1. 収益ダッシュボード

サービスごと・拠点ごとの月次収益。介護報酬の請求実績ベース。サンプル値ではなく、service_records / service_plans / regional_unit_prices テーブルからの実データ接続。

?year=&month= のクエリパラメータで任意月を指定可能。前月比・前年同月比の自動算出。

2. 業務負荷ダッシュボード

ケアマネ1人あたりの担当件数、月の訪問件数、サービス担当者会議の開催数、新規受け入れ・離脱数。assigned_care_manager_id でケアマネごとに集計。

注: この機能は2026年4月時点で実装は完了しているが、assigned_care_manager_id のデータ蓄積待ちのため、本格稼働は1号店の実データ蓄積後（2026年5月以降を想定）。

3. 紹介元（営業）ダッシュボード

紹介元組織ごとの紹介件数、成約率、平均利用期間、離脱理由。/referral/ の営業ツールと連携。

4. かいごの窓口 専用KPI（madoguchi-kpi）

1号店「かいごの窓口」用の専用ビュー。立ち上げ期特有のKPI（開業からの経過月数、初期利用者の獲得チャネル、損益分岐点までの距離）を可視化。FC展開時には各拠点用にコピーして運用予定。

5. 管理者用 KPIタブ（admin KPITab）

複数拠点を運営する場合の本部用ビュー。拠点間比較、グローバルKPI、異常値の自動検知。

これら5つのタブが、利用者管理・記録・書類生成と同じCareSpace OSの中で動く。経営判断のためにExcelに書き出す必要がない。

なぜそう設計したか — 「サンプル値を出さない」という固い決定

CareSpace OSのKPIダッシュボードには、強い設計判断がある。サンプル値・固定値を出さない。

これは2026年3月の改修時に、明確に決定した方針だ。

設計判断ログ（decisions.md）にこう記載されている:

収益ダッシュボードを実データ接続に切り替え。データ0件なら正直に0を返す。 理由: サンプル値が残っていると実運用で誤解を招く。1号店の実データで磨くフェーズに入ったため。

つまり、利用者データがない状態でデモのダッシュボードを表示するのではなく、データがなければ「0」と表示する。仮データで「動いているように見せる」演出を排除した。

理由はシンプルだ。介護事業者の経営者が、CareSpace OSのダッシュボードを見て意思決定する。そのとき、数字がサンプル値だったらどうなるか。誤った経営判断を引き起こす。

この「正直に0を返す」設計は、UIとしては地味だ。導入直後の経営者は「何も表示されない」状態を見ることになる。デモ感がなくて、寂しい。

しかし、データが蓄積され始めた瞬間から、ダッシュボードが動き始める。それは仮データが消えて実データが出るのではなく、最初から実データが反映されるという正確な体験になる。

これは、誠実さの話だ。介護事業者の経営判断を支援するシステムは、データの真偽について妥協してはいけない。

拠点間アクセス制御という地味な機能

KPIダッシュボードでもう1つ重要な機能がある。facility_id ベースのアクセス制御だ。

複数拠点を運営する事業者の場合、各拠点の管理者は自分の拠点のKPIだけを見られる。本部権限のユーザーは全拠点を統合して見られる。これがDBレベルで分離されている（facility_id フィルタ）。

なぜこれが重要か。

• 拠点Aの収益が悪いとき、拠点Bの管理者が見る必要がない（むしろ士気に影響する）
• FC加盟事業者の場合、自拠点のKPIは加盟者のもの。本部が全部見ることが正しいわけではない
• 個人情報保護の観点でも、拠点を超えてデータを参照させない設計が必要

技術的には、createServiceClient() でRLSをバイパスする処理の後、必ず .eq('organization_id', profile.organization_id) を付ける運用ルールがある。これにより、誤ってマルチテナント境界を越える事故が起きない。

地味な機能だが、FC展開時に死活的に効く。

介護事業者のKPI設計に関する誠実な意見

最後に、KPI設計についての意見を書く。

KPIダッシュボードは万能ではない。

ダッシュボードの数字を毎日眺める経営者ほど、施策が場当たり的になる。「今月の収益が前月比5%下がった、何かしないと」と即座に動く。本当はその5%が季節変動なのか、特定の利用者が亡くなった一時的な減少なのか、トレンドとしての構造的問題なのか、判断にはもっと長い時間軸が必要だ。

CareSpace OSは、ダッシュボードを毎日見る運用を推奨しない。週次・月次で見る運用を推奨している。日次の変動はノイズが多すぎる。

KPIの本当の使い方は、「異常値を機械が検知して、人間に知らせる」ことだ。経営者が毎日見るのではなく、システムが毎日見て、変調があれば人間に通知する。これが正しい役割分担。

この方向の機能拡張は、現在進めている。今後、KPIダッシュボードに「異常値検知のSlack通知」「月次レポートの自動生成」を統合する予定。

介護事業者へのメッセージ

「うちは黒字、たぶん」から、「うちはこの拠点・このサービス・この月で、これだけ黒字」に変わる。

これは規模の大小を問わず、すべての居宅事業者にとって意味のある変化だ。1拠点運営でも、3年後に拡大を考えるなら、今からデータ基盤を作っておく価値がある。

向くケース:

• 複数拠点・複数サービスを運営している事業所
• FC展開を検討している事業所
• ケアマネ間の業務負荷を平準化したい
• 紹介元別の貢献度を可視化したい

向かないケース:

• 1拠点・1サービスで、経営者の頭の中ですべて把握できている事業所
• 数字を見たくない、感覚で経営したい方針の事業所

CareSpace OSのKPIダッシュボードは、現在「かいごの窓口」で実データ接続のまま運用検証している。データが揃い始めると何が見えるか、別記事で公開する予定。

▼ CareSpace OSの試用相談はこちら → app.carespace.jp ▼ KPI設計の詳細は decisions.md として社内記録、一部公開予定