「暫定だから簡易でいい」が一番危ない — 暫定ケアプラン作成のルール
対象読者: 認定結果が出る前にサービス利用を頼まれ、暫定ケアプランの作り方に迷っている居宅介護支援事業所のケアマネジャー（新人〜中堅） この記事で分かること: 暫定ケアプランの制度上の位置づけ、通常のケアプラン作成プロセスを省略してはいけない理由、CareSpace OSが「暫定」をどう追跡可能にしたか 読了目安: 7分
「結果が出るまで待てない」利用者に、何を作ればいいのか
要介護・要支援認定の新規申請、区分変更申請、更新申請。どの場合も、結果が出るまでには一定の期間がかかる。その間に、利用者や家族から「結果を待たずにサービスを使いたい」と言われる場面は珍しくない。退院直後で在宅生活の立ち上げが急ぐケース、区分変更で状態が悪化しているのにサービス量を増やせないケースなど、待てない理由は現場ごとに具体的だ。
このときに作るのが暫定ケアプランである。要介護・要支援認定の効力は、申請日に遡って発生する。だから暫定プランであっても、後に決定された要介護度等に基づいて有効になる（出典: 稲沢市「暫定ケアプランの取扱いについて」）。制度としては筋が通っている。
ただ現場でよく起きる誤解がある。「暫定だから、通常のケアプラン作成プロセスを一部省略してよい」という思い込みだ。実際にはそうではない。課題分析（アセスメント）からサービス担当者会議、ケアプランの作成・交付、個別援助計画の提出依頼まで、通常のケアプラン作成プロセスは暫定であっても省略してはならない。「暫定」が指しているのは認定確定前という状態であって、手順を簡略化してよいという意味ではない。
もう一つ、事前に利用者・家族へ伝えておくべきリスクがある。想定より軽い要介護度が確定した場合、区分支給限度基準額を超えた分は全額自己負担になる（出典: リハブクラウド「暫定ケアプラン時のデイサービスの対応」）。この構造があるため、暫定ケアプランは「高い確度で見込める要介護度がある場合」に限定して活用するのが実務上一般的とされている。見込みが不確かなまま暫定運用に踏み切ると、利用者に想定外の自己負担を負わせるリスクがケアマネ側に返ってくる。
手順を省略しない、状態だけを追加する
CareSpace OSでは、暫定ケアプランを「別の作成フロー」として用意していない。通常のケアプラン作成と同じ画面、同じ手順（アセスメント反映→第1〜3表作成→サービス担当者会議記録→交付）を通したうえで、「暫定」という状態フラグをオンにするだけの設計にしている。
具体的な動線はこうなる。
- ケアマネが、新規申請中（または区分変更・更新申請中）の利用者からサービス利用の希望を受ける
- 通常どおりアセスメントを実施し、第1〜3表を作成する（暫定だからといって項目を間引かない）
- ケアプラン詳細画面の「暫定」トグルをオンにする
- オンにすると、第1表から第3表まですべての帳票に統一して「暫定」スタンプが表示される。トグルがオフのときはスタンプは出ない
- サービス担当者会議を実施し、記録を残したうえで交付する
- 認定結果が確定したら、内容を必要に応じて見直し、「暫定」トグルをオフにする
ここでのポイントは、「原案／確定」という作成段階と、「暫定」という認定前フラグを、別軸として扱っていることだ。原案の状態で暫定運用することもあれば、内容を確定させた状態のまま暫定運用を続けることもある。この2つの組み合わせは実務上どちらも起こりうるため、CareSpace OSでは両者を独立したフラグとして持たせている。
さらに、ステータス（原案／確定、暫定オン／オフ）が切り替わるたびに、ケースファイルへ新しいファイルとして保存する設計にしている。同一ステータス内での再保存は上書きだが、原案版と確定版は別ファイルとして残る。これは「その時点でこの内容の暫定プランを作成し、交付した」という事実を後から証明するための設計であり、運営指導（実地指導）でプロセスの実施状況を問われた際の備えでもある。
なぜこの設計にしたか — 表記の混同を先に潰した
この設計に至る前、CareSpace OS社内では別の問題を抱えていた。同じ「原案の状態のプラン」なのに、帳票ごとにスタンプの表記が割れていたのだ。第1表には赤字で「【原案】」、第2表には何も表示されない、第3表には枠囲みで「暫定」——という具合に、表ごとにバラバラだった。
原因を遡ると、「原案」と「暫定」という異なる2つの概念を、1つの状態として扱ってしまっていたことに行き着いた。「原案」は作成段階（ドラフトか確定か）を示す言葉であり、「暫定」は認定確定前の仮プランであることを示す言葉だ。本来まったく別の軸なのに、どちらも「まだ正式ではない」という似た語感のせいで、設計上も一つの状態として混同されていた。
そこで、原案／確定をstatus、暫定をis_provisionalという独立したフラグに分離し、直交する2軸のモデルに整理した。暫定×原案、暫定×確定という組み合わせが実際の運用で起こりうるため、3つの値を持つ単一の状態（原案・暫定・確定）にはしなかった。加えて、「暫定は暫定らしく単独で示すべきで、暫定であれば原案のスタンプは不要」という判断から、暫定オン時は「暫定」スタンプのみを表示する形に統一した。
この整理は、机上の仕様検討から出てきたものではない。実際にCareSpace OSを使うケアマネから「原案・暫定の設定がわかりにくい」という声が上がり、そこから遡って設計の矛盾が見つかった経緯がある。Buy First, Build Laterという方針のとおり、現場の運用でつまずいた箇所を仕様の見直しにそのまま反映させている。
暫定運用が多い事業所にこそ効く
暫定ケアプランは、頻度としてはそう多くない事業所も多いだろう。だとすれば、この機能だけを理由にCareSpace OSを選ぶ必要はない。
一方で、退院直後の対応や区分変更が多い利用者層を抱え、暫定運用の頻度が高い事業所には価値がある。原案・暫定・確定の組み合わせを口頭やメモで管理していると、「このプランは今どの状態か」を後から追うのは難しい。ステータスが変わるたびに別ファイルとして残る設計は、暫定から確定までの経緯を後から確認できる状態を作る。
暫定ケアプランは、認定が確定するまでの「仮のプラン」であって、「仮の手順」ではない。そこを取り違えないことが、利用者への説明責任とケアマネ自身を守る備えの両方につながる。
CareSpace OSについて詳しく見る → https://carespace.jp/product
出典・参考
- 稲沢市「暫定ケアプランの取扱いについて」 https://www.city.inazawa.aichi.jp/cmsfiles/contents/0000003/3780/zanntei2.pdf
- リハブクラウド「暫定ケアプラン時のデイサービスの対応」 https://rehab.cloud/mag/3672/
- CareSpace OS社内設計判断ログ（2026-06-15／2026-07-02／2026-07-08）— ケアプラン「原案／確定」「暫定」の2軸モデル化に関する意思決定記録