法令・通知からJSONへ:制度を計算と画面に変える設計
掲載内容:2026年10月の当サイトの設計・実装。重度訪問介護の例は2026年6月施行の報酬改定に基づきます
法的文書を、実行できる制度へ
Carecalculateは、厚生労働省の法令・告示・通知を起点に、制度の意味をJSONの構造体へ移し、計算と画面へ展開するサイトです。条文の順序を、人が条件を確かめて操作できる順序へ組み替えます。
原文 → 意味を持つJSON → 計算 → 人が理解できる手順| 層 | 保持するもの | 変換先 |
|---|
| 原文 | 保持するもの対象者・行為・条件・例外・施行日・根拠箇所 | 変換先文脈を読んで構造化する |
|---|
| JSON | 保持するもの区分ID・単位数・算定単位・条件・出典 | 変換先計算定義と説明定義へ分ける |
|---|
| 計算 | 保持するもの入力検証・集計・換算・端数処理・上限 | 変換先内訳と結果を返す |
|---|
| 画面 | 保持するもの必要な入力・操作順序・結果の意味 | 変換先人が選び、確かめられる手順にする |
|---|
このページで追う実装
重度訪問介護の「同じ事業者の1日分を通算する」という条件を、時間区分の定義、日別入力、重複の拒否、費用の計算まで追います。
法令・通知の条件をモデルが読み、JSONの定義から計算と入力画面へつなぐ設計を解説。重度訪問介護の例で、時間区分、処遇改善加算、丸め方、負担上限を追い、制作時のAIと公開後の計算、改定時の検証を分けて説明します。
1. 出発点は、厚労省の法的文書
制度の根拠を、厚生労働省が公開する法令・告示・通知から読み解きます。対象者や支援の範囲、報酬の区分、算定条件、例外を取り出し、当サイトの説明と計算を組み立てています。制度の説明と料金計算を、同じ根拠からたどれるようにするのが設計の出発点です。
法律・省令、報酬告示、留意事項通知、公式Q&Aは役割が異なります。告示の単位数だけで計算を作らず、留意事項にある集計の単位や併算定の制限も読みます。改正資料では改正後の欄と施行日を確認します。
児童分野はこども家庭庁、地域独自の助成は自治体の一次資料も参照します。根拠の発行主体を保持し、当サイトが作る説明・構造体・操作手順は公式文書そのものと区別します。
2. 条文を、条件と操作の意味へ分解する
原文の一文と、プログラムの一つの条件式は一対一とは限りません。「ただし」で示された例外、別項への参照、準用、対象者や事業所の条件を合わせて、どの規定がどの計算に効くかを整理します。
この文脈解析は編集時にモデルが行います。「及び」「又は」の文字で機械的に分割するだけでは、制度名を壊したり、すべて必要な条件を選択条件に変えたりします。原文の該当箇所と解釈を記録し、条件のまとまりごとに照合します。
- 対象:誰に、どの制度で、どの支援をした場合か。
- 条件:すべて必要か、いずれかでよいか。例外はどの条件に掛かるか。
- 量と範囲:1回・1日・1月のどれか。同じ事業者の範囲か。
- 時間:施行日、算定する日・月、時間区分の上端を含むか。
- 根拠:文書ID、条項やページ、原本の取得元とハッシュ。
3. 意味をJSONの構造体に保持する
JSONは制度の意味を保持する中間表現です。以下は当サイトの重度訪問介護の長時間区分定義から、4時間以上8時間未満の帯と、その周辺の項目を抜き出した実例です。ファイル名は intensive-home-care-long-hours.json。
fromMinutes は下限、toMinutesExclusive は上限を含まない境界です。240分の基本821単位を起点に、30分ごとに85単位増えることを別々の値として保持します。aggregation は同じ事業者の1日分をまとめるという設計上の識別子、sources は参照資料と該当箇所です。
この定義を生成処理が30分ごとの選択区分へ展開し、実行用の welfare-base-fees.json にID・表示名・単位数・period・条件・根拠を渡します。6時間の区分は intensive-home-care-minutes-360、1,161単位、period は day です。
説明用JSONと計算用JSONは役割を分けています。また、条件の文章をJSONへ保存しただけでは、その条件を自動判定できるようにはなりません。前提として表示する条件と、プログラムで検査する条件を区別します。
{
"serviceId": "welfare.intensive-home-care",
"validFrom": "2026-06-01",
"aggregation": "same_provider_calendar_day",
"maximumMinutesExclusive": 1440,
"bands": [
{
"fromMinutes": 240,
"toMinutesExclusive": 480,
"baseUnits": 821,
"stepMinutes": 30,
"stepUnits": 85
}
],
"sources": [
{
"sourceId": "mhlw-3f272f9fa2aa4277",
"locator": "印刷2頁・重度訪問介護サービス費イ・基本部分(8)〜(12)"
},
{
"sourceId": "mhlw-7c4d2e645da5c02d",
"locator": "印刷79〜81頁・2(2)④重度訪問介護サービス費の算定について"
}
]
}
根拠・参考:令和8年度 障害福祉サービス費等の報酬算定構造(重度訪問介護は印刷2頁) / 厚生労働省:報酬算定の留意事項(令和8年5月改正後、重度訪問介護は印刷79〜81頁)
4. 構造体を、決まった順序で計算する
6時間は360分なので、821+((360−240)÷30)×85=1,161単位です。この区分の展開は編集・生成時に行います。リクエスト時の WelfareCalculator は、選択された区分IDから確定済みの単位数を読み、数量を掛けて合計します。
地域単価や負担割合は welfare-runtime.json などの定義から読みます。固定の処遇改善加算がある場合は、月内の対象単位の合計に率を掛け、BigDecimalのHALF_UPで整数単位に四捨五入します。その後、地域単価を掛ける段階と負担割合を掛ける段階では、BigIntegerの整数除算で1円未満を切り捨てます。次は当サイトの重度訪問介護に対応する擬似コードです。医療・介護のすべてに同じ式を適用するものではありません。
この例では処遇改善加算Ⅱイ(35.7%)の届出がある事業所を固定の前提とします。実際の届出を照会しているわけではありません。正式な加算の対象は基本報酬と対象となる各加算の合計ですが、この試算で扱わない加減算は加えていません。
基本単位 = Σ(選択区分の単位数 × 数量)
固定の処遇改善加算 = round_HALF_UP(基本単位 × 357 / 1000)
総単位 = 基本単位 + 固定の処遇改善加算
総費用 = floor(総単位 × 地域単価の分子 / 分母)
通常負担 = floor(総費用 × 負担割合の分子 / 分母)
残りの上限 = 月上限 − 他事業所に割り当てる負担額
本人負担 = min(通常負担, 残りの上限)
給付額 = 総費用 − 本人負担
入力した実費を含む小計 = 本人負担 + 実費
根拠・参考:令和8年度 障害福祉サービス費等の報酬算定構造(重度訪問介護は印刷2頁) / 厚生労働省:報酬算定の留意事項・端数処理(第二1(1)①・印刷8頁)
5. 入力から結果までを一つの例で追う
2026年10月に、所沢市の事業所で6時間の支援を10日使い、月上限9,300円、他事業所への割当0円、実費0円とします。入院中ではない人への従業者1人分の基本報酬に、固定の処遇改善加算Ⅱイ(35.7%)を加える例です。
基本単位は1,161×10=11,610単位。処遇改善は11,610×35.7%=4,144.77を四捨五入して4,145単位、合計15,755単位です。地域単価10.36円を掛けると163,221.8円となり、総費用は163,221円。1割の通常負担は16,322円、上限反映後の本人負担は9,300円です。
この例はすでに上限に達するため、処遇改善を加えても本人負担は9,300円のままです。上限に届かない条件では本人負担も変わります。固定の処遇改善以外の加算・減算は含めません。日付をまたぐ支援の時間配分は事業所が整理した算定上の日別時間を入力します。1日24時間ちょうど、2人派遣、入院中の区分も、この計算の範囲には含みません。
6. 計算の依存関係を、人が理解できる手順にする
制度の掲載順と、利用者が入力しやすい順は異なります。地域単価が必要なら「事業所所在地を選ぶ」、日ごとの量が必要なら「利用日と1日の合計時間を選ぶ」という操作へ変換します。利用者に内部IDや級地の判定を要求する必要はありません。
重度訪問介護では午前3時間・午後3時間を別々の3時間報酬として足さず、同じ事業者の1日合計6時間を1行で選びます。画面の案内と、サーバー側の同一日重複・数量2以上の拒否が、同じ日額の算定ルールに対応しています。
選択肢などを定義から供給し、入力の配置や操作順はサービス別テンプレートと共通UI規約で設計します。JSONだけから画面全体を無条件に自動生成する方式ではありません。
計算処理が返す内訳・総単位・総費用・本人負担をSSRでHTMLにし、非同期操作では結果欄を更新します。結果を先に見せ、前提や注記をその下へ置くことで、金額とその意味を続けて確認できます。
- 対象月・事業所所在地 → 使用する定義と地域単価を決める。
- 利用日・区分・数量 → 算定する量を決める。
- 受給者証の月上限など → 本人負担へ反映する。
- 内訳・結果・前提 → 何を計算した金額かを示す。
7. モデルによる解釈と、実行時の計算を分ける
編集時は、モデルが原文を読み、条件の構造化と読者向けの説明を作ります。生成スクリプトは確定した定義を転記・展開し、構造や参照を検査します。定義の意味は別途原文と照合します。
公開後は、保存済みの定義と計算処理で結果を返します。閲覧や計算のたびにモデルへ原文を渡して、料金や説明を生成する処理はありません。同じ入力・同じ定義版なら、同じ計算を再現できる構成です。
8. 改定では、原文・定義・計算・画面を照合する
改定の反映では、単位数だけでなく、対象者、例外、集計範囲、施行日が変わっていないかを読みます。原本と取得記録を保存し、関係する定義・説明・入力・結果の変更を追います。
重度訪問介護なら4時間・8時間などの帯の境界、24時間の範囲外、同一日の重複、月上限の前後が試験の対象です。JSONの構造検査、原文との意味照合、計算試験、実画面の操作確認を分けて実施します。
この設計を別の制度へ応用するときも、まずその制度の対象・条件・量・集計単位を読み解きます。構造体は、原文と計算と人の操作をつなぐためのものです。
原本の取得だけでは公開内容は変わりません。本文を確定した後に、モデルが生成ページを再読してタイトルとdescriptionを編集します。ローカルの検証が終わっても、本番への反映と公開後の応答確認が終わるまでは、公開済みとは扱いません。
編集:当サイト。コードは実装の抜粋または明示した説明用の擬似コードです。制度ごとの算定条件・計算範囲は各算定ページに掲載しています。
この内容のQ&A
法律の条件をJSONに書けば、自動判定できますか?
掲載内容:2026年10月の当サイトの設計・実装。重度訪問介護の例は2026年6月施行の報酬改定に基づきます
JSONは、制度の条件や単位数を項目ごとに保存する形式です。法律の文章を入れるだけで、自動判定ができるわけではありません。誰が対象か、いつの制度か、例外は何か、1回・1日・1か月のどれで数えるかを読み分け、計算処理が使える形に整理します。
たとえば重度訪問介護では、選んだ時間区分の単位数を読み、利用日数を掛けます。同じ日に日額の行を重ねる入力は計算処理で止めます。一方、支給決定や事業所の届出が実際に条件を満たすかは、自動で確かめていません。画面に示す前提を確認して使う試算です。説明に条件が載っていることと、その条件を自動検査できることは別です。
根拠・参考:当サイト:制度を計算の仕組みに変える方法(第3節:JSONの役割と、自動検査する条件・表示する前提の区別。)
この質問のリンク計算するたびにAIが料金や答えを作るのですか?
掲載内容:2026年10月の当サイトの設計・実装。重度訪問介護の例は2026年6月施行の報酬改定に基づきます
いいえ。公開サイトの試算では、サーバーに保存した定義とプログラムで金額を計算します。計算するたびにAIへ法律を読ませたり、AIがその場で料金を作ったりする仕組みではありません。
モデルが原文を読み、条件を整理し、説明文を書くのはサイトの制作・更新の工程です。公開前には、データの形式、原文との意味の一致、計算結果、画面での使いやすさを別々に確認します。同じ入力・対象月・定義なら計算結果は同じになりますが、それだけで実際の請求額や制度の適用が保証されるわけではありません。
根拠・参考:当サイト:制度を計算の仕組みに変える方法(第7節:制作時のモデルによる解釈と、公開後の計算処理。)
この質問のリンク制度が改定されたら、どこを直して確かめるのですか?
掲載内容:2026年10月の当サイトの設計・実装。重度訪問介護の例は2026年6月施行の報酬改定に基づきます
改定された原文と今の掲載内容を比べ、単位数だけでなく、対象者・例外・数え方・適用開始日への影響を確認します。原本と取得記録を残し、必要な定義や計算処理、説明文、入力欄、結果表示を直します。新しい通知を取得しただけで、公開サイトの計算が自動で切り替わるわけではありません。
確認するのは、通常の計算だけではありません。時間区分の境目、上限額の前後、同じ日の重複、対応期間の外なども試します。たとえば重度訪問介護では、時間区分の単位数、月内の処遇改善加算の丸め、負担上限を分けて確かめます。
データの形式が正しいこと、制度の意味に合うこと、画面で使えることをそれぞれ確認し、本文が決まった後にページのタイトルと説明文も読み直します。ローカルでの修正・試験と、本番への反映・公開後の確認は別の工程です。
根拠・参考:当サイト:制度を計算の仕組みに変える方法(第8節:改定の影響確認、定義・計算・画面の検証と公開まで。)
この質問のリンク すべてのFAQ・Q&Aを見る掲載内容・計算について報告する