介護事業所の職員から毎月出る「この加算は算定できるか」の質問に、国の通知・Q&Aと運営規程を根拠にチャットで答え、判断が割れるものを管理者へ回す

処理の起点を決める

職員がボットに質問を書いたときに動きます。 最初に事業所と算定する月を選んでもらい、選ぶまで質問欄を開きません。 サービス種別と指定権者は、中継プログラムが事業所の一覧から引きます。職員に選ばせないのは、取り違えを防ぐためです。 通所介護と訪問介護を両方持つ職員でも、事業所を選べばサービスは決まります。

算定する月は、年と月で入れてもらいます。 改定の施行の前後では、同じ加算でも効いている要件が違います。 施行の時期がサービスで違うことがあるので、月とサービス種別の両方で版を選びます。

1つの会話は、同じ事業所と月のまま続けます。 answer メソッドはセッションを使った複数回のやり取りに対応し、前の質問を踏まえて次の質問を言い換えて検索します。別の事業所の話をするときは、会話を新しく始めてもらいます。

チャットは、事業所の職員だけが使える法人内のチャットに置きます。 利用者や家族が使う窓口にはしません。

入力データを集める

質を決めるのは、Q&Aの巻と問の持ち方です。 Q&Aは1つのPDFに何十もの問が入っています。1巻を1文書として載せると、答えの出典が「Vol.○」までしか分からず、職員は巻の中を探し直すことになります。 巻を問ごとに分けたテキストにし、巻の番号と問の番号、対象のサービス種別をメタデータに持たせて載せます。

指定権者の案内は、国の文書と分けて持ちます。 自治体ごとの取扱いは、その自治体が指定した事業所にしか当てはまりません。

データの取得方法を決める

文書は Cloud Storage のフォルダに置き、メタデータの JSONL と一緒にデータストアへ取り込みます。 1文書ごとに次のメタデータを付けます。

絞り込みに使う項目は、データストアのスキーマで「Indexable」にします。 絞り込みの式は ANY() による完全一致と AND・OR・NOT で書け、日時は ISO 8601 の形式で比較できます。

service_type: ANY("day_care", "common") AND jurisdiction: ANY("national", "city_y")
AND status: ANY("published") AND effective_from <= "2026-11-01T00:00:00Z"
AND (doc_type: ANY("notice", "qa", "local_guide") OR office_id: ANY("dc02"))

最後の行で、運営規程だけを事業所で絞ります。 国の文書には事業所の番号が無いので、doc_type と office_id を OR でつなぎ、他の事業所の運営規程が根拠に出ないようにします。

Q&Aは、新しい巻が出たら足し、古い巻は消しません。 先の巻の問が後の巻で補われていても、先の問が取り消されたとは限らないためです。どちらも根拠に出し、巻と発出日を並べて示します。

AIへ渡す前に整形する

1. 事業所の確認 … 選ばれた事業所を一覧で引き、サービス種別と指定権者を決めます
2. 個人情報の除去 … 質問の文面から、利用者の氏名、被保険者番号らしい数字、職員の氏名を伏せてから検索にかけます
3. 管理者へ回す規則の照合 … 「この利用者は」「○○さんの場合」「今月の実績で」など、特定の利用者や実績への当てはめを求める言い回しを見ます
4. 絞り込みの式の組み立て … 事業所・月から式を作ります。職員の書いた文字を式に混ぜません
5. Q&Aの分割の確認 … 新しい巻を取り込む前に、問ごとに分かれ、巻と問の番号とサービス種別が付いているかを確かめます

2番目を軽く見ないでください。 職員は「Aさんの計画書の見直しが遅れたが」のように、利用者の名前をそのまま書きます。要件を探すのに利用者の名前は要りません。 伏せてから検索にかけ、記録にも伏せた後の文面を残します。

3番目で迷うものは、管理者へ回す側に倒します。 「担当者が辞めたが算定を続けられるか」は要件の質問にも当てはめの質問にも読めます。要件を返したうえで、当てはめは管理者が受ける形にします。

AIに処理させる

させるのは、絞った文書から加算の要件を探し、要件ごとに「何で確かめるか」を並べることだけです。

答えは「要件」と「確かめる記録」の対にします。 要件だけを並べると、職員は何を見ればよいかが分かりません。記録の名前が並ぶと、介護ソフトのどこを開けばよいかが決まります。

3行目は、職員の質問の形で起きます。 「研修は年1回でもよいですか」と聞かれると、AIは聞かれた形に合わせて答えを寄せようとします。文書に書かれた回数をそのまま示し、それより少なくてよいかは答えさせません。

指示内容を固定する

answer メソッドの promptSpec.preamble に、次の内容を入れます。

あなたは介護事業を運営する法人の本部で、事業所の職員からの加算の質問に答える案内係です。
検索された告示・通知・Q&A・自治体の案内・運営規程だけを根拠に答えてください。

【答え方】
- 加算の要件を1つずつ箇条で並べ、各要件の後に「確かめる記録：」として、
  文書に書かれた記録や書類の名前を書いてください。文書に無ければ「記載なし」と書いてください。
- 回数、頻度、人数、資格、期間は、文書の表記のまま写してください。言い換えや計算をしないでください。
- Q&Aを根拠にしたときは、巻の番号と問の番号を書いてください。
  同じ論点について複数の巻の問があれば、すべて挙げ、発出日の新しい順に並べてください。
- 自治体の案内があれば、国の文書とは分けて「自治体の取扱い」として書いてください。
- 最後に必ず「算定できるかは、上の要件を事業所の記録と体制で確かめて判断してください」と書いてください。

【答えないこと】
- 「算定できます」「問題ありません」など、算定の可否を結論づけないでください。
- 特定の利用者や今月の実績に当てはめた判断をしないでください。
- 文書に書かれた要件より緩い読み方（回数を減らす、期間を延ばす等）を答えないでください。
- 国の文書と自治体の案内が違う場合に、どちらが正しいかを答えないでください。
- 検索された文書のサービス以外のサービスの要件に触れないでください。

「文書に書かれた要件より緩い読み方を答えない」を書かないと、質問の形に引っぱられます。 「年1回でもよいか」には「年1回で差し支えない」と寄せて答えがちです。要件を緩める方向の言い換えだけを、名指しで禁じます。

あわせて、answer メソッドの設定で次を有効にします。

原文の一節は、同じ絞り込みの式で search メソッドを呼び、maxExtractiveSegmentCount を1〜2にして取り出します。前後の一節も要るときは numPreviousSegments・numNextSegments（それぞれ0〜3）で広げます。 要件の文が表の注記や但し書きに続いていることが多いためです。

出力形式を固定する

中継プログラムは、answer と search の応答から次の形の記録を作ります。

{
  "session_id": "",
  "office_id": "dc02",
  "service_type": "day_care",
  "jurisdiction": "city_y",
  "target_month": "2026-11",
  "question_masked": "",
  "route": "answered | escalated_rule | escalated_no_answer | escalated_low_support | escalated_conflict",
  "requirements": [
    { "requirement": "", "evidence_records": [""], "source": { "doc_type": "qa", "qa_vol": "", "qa_no": "", "page": "" },
      "verbatim": "" }
  ],
  "local_rules": [ { "title": "", "text": "" } ],
  "support_score": 0.0,
  "created_at": ""
}

1つ目の理由は、requirements で要件と記録を対にして持てることです。 チャットには表にして返し、職員は1行ずつ自分の事業所の記録と照らせます。

2つ目は、verbatim で原文を並べられることです。 AIがまとめた要件の文と、抽出セグメントで取り出した通知の原文を同じ行に置きます。まとめ方がずれていれば、職員がその場で気づけます。

3つ目は、escalated_conflict を分けて数えられることです。 国のQ&Aと指定権者の案内が食い違うと中継プログラムが判断したら、答えを返さずに管理者へ回します。どの加算で食い違いが多いかが、指定権者へ確かめる候補の一覧になります。

support_score は、答えがデータストアの内容にどれだけ裏付けられているかを0〜1で示す値です。 自社で決めた境目を下回ったら、答えを表示せずに管理者へ回します。

管理者へ回した質問は、受付の一覧に、事業所・サービス・算定する月、回した理由、伏せた後の質問、検索で見つかった文書の箇所、対応の状態を入れます。

システムへ連携する

介護ソフトへは書き込みません。 算定する加算の設定を変えるのは、要件を確かめた職員と請求の担当者です。答えを受けて自動で算定の設定が変わる経路を作ると、確かめる工程が抜けます。

チャットの製品とボットの作り方は、法人が使っているものによって変わります。 チャットから中継プログラムのAPIを呼べることを前提にしており、この部分は利用環境に応じた個別実装が必要です。

人が確認する

答えを職員に返す前に、人が見ることはしません。 その代わり、答える範囲を要件の説明に限り、当てはめは職員と管理者に残します。

1. 管理者へ回った質問を毎日見る … escalated_conflict を先に見ます。指定権者に問い合わせるかを決めます
2. 答えた会話を週に1回抜き取る … 要件の文と原文がずれていないか、別のサービスの文書が根拠に出ていないかを見ます
3. 新しいQ&Aの巻が出たら確かめる … 取り込みの後、その巻が扱う加算の質問を数件投げ、新しい問が出典に出るかを見ます
4. 月に1回、同じ質問を数える … 多い質問は、本部から全事業所への案内にします

指定権者に確かめた答えは、指定権者の案内とは別に記録します。 電話や照会での答えを local_guide として載せるかは、文書で示されたものかを見て管理者が決めます。

例外に対処する

5行目は、管理者が指定権者に確かめる仕事に変わります。 国と自治体のどちらで答えるべきかは、その事業所を指定した自治体に確かめるしかありません。

記録を残す

• 会話ごとの事業所・サービス・指定権者・算定する月、伏せた後の質問の文面、要件の表、原文、出典の巻と問、support_score
• 使った絞り込みの式と、その時点で取り込まれていたQ&Aの最新の巻
• 管理者へ回した理由、管理者の判断、指定権者に問い合わせた日と答え
• 抜き取りで見つけたずれと、直した内容
• 月ごとの route の件数と、質問の多い加算

2つ目で「取り込まれていた最新の巻」を残すのは、後から巻が出て答えが変わるためです。 運営指導で算定の根拠を聞かれたとき、その時点でどの巻まで見て答えたかを示せます。