自治体の職員から出る「この支出はどの節・細節か」「どの方法で支払うか」の質問に、財務規則・予算の執行の手引き・過去の回答を根拠にチャットで答える

処理の起点を決める

起点は、職員が会計チャットに質問を送ったことです。 チャットは職員番号でログインした人が使え、所属から、回したときにどの審査担当の待ち行列に載せるかを決めます。 会計課の担当は、所管する課ごとに分けている自治体が多いからです。

節の質問では、1件の金額と、何を買うか・頼むかを必須にします。 金額の分からない段階の質問もあるので、「見積の前」を選べるようにし、その場合は区切りの値の前後で答えを分けて返します。 相手方の種類（個人／法人／官公署）も選ばせます。報酬と報償費、前金払の対象かどうかが、相手方で変わるからです。

1件の質問は、1つのセッションで最後まで続けます。 「では交通費の分だけなら」のような続けての質問も同じセッションでつなぎ、別の経費の話は新しいセッションで始めます。 前の経費の金額が言い換えの中に残るからです。

入力データを集める

質を決めるのは、区切りの表と過去の回答の整理です。 区切りの表には「備品：取得価格○万円以上で、耐用年数が1年以上」のように、自治体の物品の規則にある値をそのまま書きます。 過去の回答は、年度と、新しい版で置き換えたかどうかの印を付けてから取り込みます。印の無い過去の回答は、取り込みません。

質問の文に、個人の名前を書かせないようにします。 講師や委員の名前は節の判断に要りません。画面に「相手方の名前は書かず、個人／法人／官公署を選んでください」と出します。

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

手引き・財務規則・条文・過去の回答は、Cloud Storage に置いてデータストアに取り込みます。 文書ごとのメタデータに、文書の種類、年度、節の番号、改訂日を持たせます。

条文は、e-Gov 法令検索の法令API（laws.e-gov.go.jp/api/2/law_data/…）から取り込みます。 地方自治法と施行令は条ごとに取り、節の区分の表は施行規則の別記の図として付いているので、表を文字に起こして1節ずつに分けます。 施行規則は改正が多いので、年度の初めに会計課が改正の情報を確かめます。

絞り込みの式は、年度と文書の種類と節で書きます。 項目を索引可能にしておけば、fiscal_year: ANY("2026", "ALL") AND setsu: ANY("10", "17") AND superseded: ANY("false") のように、今年度の手引きと、候補の節の記載と、置き換えられていない回答だけを引けます。ALL は年度によらない条文と規則に付けます。

AIへ渡す前に整形する

1. 手引きを節ごとに分ける … 細節の一覧と例示を、節の見出しの単位で分け、節の番号を付けます
2. 節の区分の表を文字に起こす … 別記の図から27節の名前・説明・備考を起こし、1節を1文書にします
3. 財務規則を条ごとに分ける … 条の見出しが付いた形で取り込みます
4. 過去の回答を整える … 年度、置き換えの有無を付け、相手方の個人名と金額の端数を消します
5. 区切りの表を作る … 物品の規則と工事の規定から、金額の区切りを書き出します
6. 年度の切り替えを決める … 4月1日に新年度の手引きを有効にし、出納整理期間は前年度の版も引けるようにします
7. 見出しを断片に含める … データストアの作成時に分割を有効にし、includeAncestorHeadings を有効にします

6番目が、この構成でいちばん効きます。 4月と5月は、前年度の支出と新年度の支出が同時に起票されます。 年度を聞き返しの選択肢に入れ、前年度の支出なら前年度の版で答えます。

7番目は、データストアを作る前に決めます。 分割はデータストアの作成のあとでは有効にも無効にもできず、見出しを含める設定は既定では無効です。 手引きの細節の表は、見出しが無いとどの節の細節か分かりません。 分割の大きさは100〜500トークンで、既定は500です。

AIに処理させる

させるのは、聞き取った経費と絞った候補の節に当たる手引き・規則・条文の記載を見つけ、何節のどの細節で起票し、どの方法で払えるかを、根拠を付けて短く返すことです。 候補の節を絞ること、回すかどうかは、中継プログラムが行います。

answer メソッドの設定は次のようにします。

1行目がいちばん起きやすい失敗です。 区分の表には「備品の程度に至らない」とあり、手引きに金額の例示があると、モデルは区切りの前後を両方説明して「金額によります」と書きます。 候補は先に絞って検索の文に入れ、絞った節の記載だけを引かせます。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたは市の会計課の審査担当として、
各課の職員から、支出の節・細節と支払の方法の質問に答えます。
読むのは、起票の手を止めてチャットを見ている職員です。短く答えてください。

【前提】
検索の文の最初に、執行する年度、経費の中身、1件の金額、相手方の種類、
中継プログラムが絞った候補の節が並んでいます。
候補の節はすでに決まっています。その節の記載だけを使って答えてください。

【答え方】
1. 最初に、起票する節と細節を、手引きの細節の名前のとおりに書いてください。
2. 次に、使える支払の方法と、その根拠の条と号を書いてください。
3. 手引きに起票の注意（添付書類、精算の期限）があれば書いてください。
4. 根拠にした手引きの頁、財務規則の条、施行令の条を書いてください。

【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
  他の自治体の例や一般的な会計の知識で補わないでください。
- 候補の節の外の節を答えないでください。「金額によって異なる」と書かないでください。
- 細節の名前を言い換えたり、新しく作ったりしないでください。
- 予算の流用・充用ができるかを書かないでください。
- 「起票してよい」「支出できる」と書かないでください。
- 該当する記載が見つからないときは、
  「手引きと規則に該当する記載が見つかりません。会計課へ回します」
  とだけ書いてください。

支払の方法の質問では、候補の節の代わりに、施行令の条を候補として渡します。 相手方が官公署なら第161条第1項第9号・第162条第2号・第163条第1号、旅費なら第162条第1号のように、相手方の種類と経費から条の候補を表で引き、その条と財務規則の手続きだけを根拠にさせます。

「候補の節の外を答えない」「金額によって異なると書かない」が、この指示の要です。 候補を検索の文で渡すだけでは、検索結果に隣の節の記載が混ざったときに、モデルは親切のつもりで両方を説明します。 書き方そのものを禁じ、取り違えは後段の検査でも拾います。

検索の文は、中継プログラムが組み立てます。 例えば「年度：2026、経費：講演会の講師への謝礼、金額：50,000円、相手方：個人、候補の節：7 報償費。この経費の節・細節と、当日に現金で渡せるか」のように、条件を先に並べ、職員の質問の文を最後に足します。

出力形式を固定する

answer メソッドの応答を、中継プログラムが次の形に整えて、チャットと記録に渡します。

{
  "inquiry_id": "",
  "session_id": "",
  "fiscal_year": "2026",
  "category": "setsu | payment_method | other",
  "conditions": { "item": "", "amount": 0, "payee_type": "individual | corporation | public_office", "recurring": false, "before_quote": false },
  "candidate_setsu": ["7"],
  "answer": { "setsu": "", "saisetsu": "", "payment_methods": [""] },
  "status": "answered | escalated | skipped",
  "escalate_reason": "budget_transfer | cross_year | not_in_guide | already_paid | saisetsu_not_in_list | out_of_candidates | skipped | user_request | none",
  "answer_text": "",
  "refs": [ { "doc_type": "table | rule | guide | statute | qa", "title": "", "section": "", "fiscal_year": "", "uri": "" } ],
  "feedback": "resolved | escalated_after | wrong | none"
}

1つ目の理由は、answer.setsu と answer.saisetsu を回答の文と別に持てることです。 中継プログラムが回答の文から節と細節の名前を拾ってここに入れ、candidate_setsu の外の節か、今年度の細節の一覧に無い名前なら、回答を出さずに回します。 去年の細節で答えた回答を、文の読み方に頼らずに止められます。

2つ目は、conditions を残せることです。 金額と相手方の種類を残しておけば、同じ経費でも金額で答えが変わった理由を、後から並べて見られます。

3つ目は、escalate_reason で回った理由を数えられることです。 not_in_guide が多い経費は手引きの例示に足すべきもの、saisetsu_not_in_list が多ければ過去の回答の置き換えが追いついていないことが分かります。

システムへ連携する

財務会計システムには、書き込みません。 起票は職員が自分で行い、審査は会計課が行います。チャットが起票の画面を開いて値を入れる形にすると、根拠を確かめる手順が消えます。

人が確認する

職員は、回答を読んだあと、根拠の手引きの頁を開いてから起票します。 回答の上には、選んだ年度と金額と相手方の種類を並べて表示します。

1. 条件が合っているかを見る … 金額が1件の金額か、まとめた金額かを確かめます
2. 根拠を開く … 手引きの頁を開き、例示が自分の経費と同じかを見ます
3. 評価を付ける … 解決した／会計課へ回した／誤りを選びます

1番目を軽く見ないでください。 備品の区切りは1件ごとの金額で見ることが多いのに、職員はまとめて買う総額を入れがちです。 画面に「1点あたりの金額」と書き、総額と分けて入れさせます。

会計課の審査担当は、回ってきた質問だけを見ます。 budget_transfer は財政課へつなぎ、already_paid はその日のうちに担当課と話して事実を確かめます。

目標は、360件をならして1件3分です。 チャットで解決した質問の記録の確認と、回ってきた質問を担当者が判断する時間の平均です。

例外に対処する

5行目は、運用の約束として各課に伝えておきます。 すでに払ってしまったことを相談できる窓口だと分かっていないと、職員は「これから払うなら」という形で聞き、起票の差し戻しを受けてから気づきます。

記録を残す

• 質問の文、選んだ聞き返しの値、日時、所属
• 区切りの表のどの行で候補の節を絞ったか
• 中継プログラムが組み立てた検索の文と、使った絞り込みの式
• answer メソッドの応答の全文（回答、出典、根拠のスコア、回答しなかった理由）
• 回す・回さないの判定と、その理由、会計課が最終的に答えた内容
• そのとき効いていた手引きの年度と、区切りの表の版

最後の行は、監査で効きます。 手引きが改訂されたあとで、当時なぜその節で答えたかを並べて見られるようにしておきます。

2行目も、区切りの表を直すときに効きます。 物品の規則の金額が改められたとき、どの質問がその行で絞られていたかを拾えれば、影響する過去の回答に置き換えの印を付ける範囲がすぐに決まります。