職員からの例規や事務手続きの質問に、例規集と事務マニュアルを根拠に条文付きで答える

処理の起点を決める

処理の起点は2つあります。 1つは職員が検索画面に質問を入力したとき、もう1つは例規や事務マニュアルが改正・更新されたときです。

質問の入力は、そのたびに1件ずつ処理します。 職員は事務の途中で聞いているので、待たせません。同じ職員が続けて聞く質問は、前の質問の文脈を引き継げるように、セッションとして扱います。 answer メソッドには、会話の文脈を踏まえた複数回のやり取りのためのセッションの指定があるとされています。

索引の取り込み直しは、例規集の更新に合わせます。 例規の改正は毎月のように公布され、施行日もまちまちです。提供事業者から更新されたデータが届いた日に、取り込みをやり直します。 データストアの自動の定期取り込み（1日、3日、5日ごと）もありますが、この方式では元のデータの権限の制御に対応していないとされています。例規と全職員向けのマニュアルだけを入れる前提なので支障はありませんが、特定の課だけが見るべき文書をこの索引に入れないことを運用の規則にします。

施行日をまたぐ日にも取り込み直します。 公布済みで施行前の改正は、施行日になった時点で「現行」に切り替わります。施行日の朝に、メタデータの「現行か」を付け替えて取り込み直す予定を、改正の公布のたびに登録しておきます。

入力データを集める

質を決めるのは、メタデータの「現行か」と「根拠にしている例規の番号」です。 「現行か」が無いと、改正前の条文と改正後の条文が同じ重みで検索に出ます。第3章の（c）は、ここで防ぎます。 マニュアルに根拠の例規の番号が無いと、例規が改正されたときに、どのマニュアルを見直すべきかが分かりません。

マニュアルの登録は、所管課が行います。 法規担当が各課のフォルダから集めると、どれが最新版かを判断できません。最新版だけを、根拠の例規の番号を付けて登録してもらうのが、マニュアルの側の最初の作業です。

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

例規と事務マニュアルは、Cloud Storage に置いてデータストアに取り込みます。 取り込みの際、文書ごとのメタデータを structData または jsonData として、文書の置き場所と一緒に書いた形式で渡します。

メタデータは、絞り込みに使えるよう「索引可能」にします。 ドキュメントでは、メタデータで絞り込むには、スキーマの設定でその項目を索引可能にする必要があるとされています。絞り込みの式は、status: ANY("current") のように書けます。 日付の項目には比較の演算子も使えるとされており、施行日で絞ることもできます。

検索のたびに付ける絞り込みは、中継プログラムが決めます。 職員が「改正前の扱いを知りたい」と明示したときだけ、施行前・廃止の文書も含めます。既定は、現行のものだけです。

AIへ渡す前に整形する

1. 例規の単位で1文書にする … 例規集のデータを、1つの例規を1つの文書にそろえます。別表と附則は、その例規の文書に含めます
2. 現行・施行前・廃止を付ける … 法規担当の管理表から、例規ごとの状態と施行日を付けます
3. 改正前の条文を分ける … 改正履歴として残っている旧条文は、「廃止」の別の文書として分けます
4. マニュアルの版を確かめる … 同じマニュアルの古い版は取り込みません。最新版だけにします
5. 根拠の例規の番号を付ける … マニュアルに、根拠にしている例規の番号をメタデータとして付けます
6. スキャンのマニュアルを確かめる … テキストの無いPDFは、OCR パーサーで読めますが、先頭の500ページまでとされています。長いものは分けます
7. 個人の情報を含む文書を除く … 様式の記入例に実在の職員の氏名が入っていないかを確かめます

1番目と3番目を分けて考えてください。 例規集のデータには、1つの例規の中に改正の履歴が並んでいることがあります。そのまま取り込むと、同じ条の新旧の条文が1つの文書の中に並び、絞り込みでは分けられません。 旧条文は別の文書にして「廃止」を付けます。

6番目のOCR パーサーとレイアウトパーサーは、Document AI の料金がかかるとされています。例規集のデータがテキストで受け取れるなら、例規の側はテキストのまま取り込み、パーサーの費用はマニュアルの側に限られます。

AIに処理させる

させるのは、索引の中の条文とマニュアルを根拠に、質問に答える文を作ることです。 答えの形は、次の4つの要素に決めます。

左から2列目の「根拠の条文」が、この構成で最も大事な要素です。 職員が確かめるのは、回答の文ではなく条文です。条文の場所が付かない回答は、正しくても使えません。 中継プログラムは、根拠の中に例規の文書が1つも無い回答を、職員に表示せず法規担当へ回します。

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

3行目が最も起きやすい失敗です。 地方自治法や地方公務員法の一般的な知識は、回答を生成するモデルが持っています。それを使って答えると、本市の規則で上乗せや別の定めがある事項で誤ります。 索引の中の文書だけで答えることを、指示で明記します。

指示内容を固定する

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

あなたは市役所の職員からの、例規と事務手続きの質問に答えます。
答えを読むのは市の職員で、答えの根拠の条文を開いて確かめてから
事務を進めます。

【答え方】
1. 最初に、質問への答えを1〜2文で書いてください。
2. 次に、根拠にした例規の名称と、条・項・号、別表の番号を書いてください。
3. 事務マニュアルに具体的な手順があれば、その手順を書いてください。
4. 例規とマニュアルで記載が違う点があれば、両方を書き、
   「例規と事務マニュアルの記載が異なります」と明記してください。

【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
  地方自治法、地方公務員法などの一般的な知識で補わないでください。
- 金額、日数、期間、決裁の区分は、別表や条文に書かれているとおりに
  書いてください。計算や言い換えをしないでください。
- 条文の解釈が分かれる点や、個別の事案に当てはめた可否は書かないでください。
  「個別の事案の判断は法規担当または所管課に確認してください」と書いてください。
- 例規とマニュアルが食い違うとき、どちらが正しいかを決めないでください。
- 根拠になる条文が見つからないときは、答えを作らないでください。
- 施行前の改正や、改正前の条文について聞かれたときは、
  その旨と施行日を明記してください。
- 質問者の所属や氏名を答えに書かないでください。

「計算や言い換えをしない」は、別表の金額のためです。 旅費の日当は、職の区分と行き先で金額が分かれた表になっていることが多く、生成された文が表を読み違えて別の区分の金額を書くことがあります。 表のとおりに写させ、職員には表そのものを開かせます。

「個別の事案の判断は確認を」を定型の文にしているのは、職員が次の一歩を迷わないためです。 答えられないことを答えないだけでは、職員は結局また誰かに聞きます。誰に聞けばよいかまで書かせます。

出力形式を固定する

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

{
  "query_id": "",
  "session": "",
  "status": "answered | skipped | escalated",
  "skipped_reasons": [],
  "answer_text": "",
  "citations": [
    { "doc_type": "reiki | manual", "title": "", "article": "",
      "effective_date": "", "status": "current", "uri": "" }
  ],
  "support_score": 0,
  "conflict": { "found": false, "reiki": "", "manual": "" },
  "route_to": "none | houki | shokan"
}

1つ目の理由は、status で表示の仕方を分けられることです。 answered は回答と根拠を表示し、skipped は回答しなかった理由（answerSkippedReasons の内容）に応じて文面を変え、escalated は法規担当へ送る画面を出します。回答しなかったことを隠さず、次にどうするかを示します。

2つ目は、citations の doc_type で判定できることです。 中継プログラムは、citations の中に reiki が1つも無い回答を escalated に書き換えます。マニュアルだけを根拠にした回答は、例規の改正に追いついていないマニュアルからの答えかもしれないからです。

3つ目は、support_score で根拠の強さを使えることです。 支持スコアは0から1の値で、一定の値に届かない回答は、根拠が弱いとして法規担当へ送るボタンを目立たせます。 境の値は、最初の1か月の記録を見て法規担当が決めます。

4つ目は、conflict を記録として集められることです。 食い違いが見つかった回答は、月次の集計で所管課へ返します。

システムへ連携する

例規集のWeb版には、書き込みません。 回答の根拠のリンクは、Web版の該当の例規を開くものにします。職員が確かめる条文は、いつも正式な例規集のほうです。

法規担当への送付には、職員が入力した質問と、回答の候補と根拠をそのまま添えます。 法規担当は、AIがどの条文を見て答えられなかったかから始められるので、①の見当付けの時間が減ります。

人が確認する

この構成では、すべての回答を人が事前に確かめることはしません。 質問は事務の途中で、待たせられないからです。その代わり、確かめる責任を2か所に置きます。

1. 職員が根拠の条文を開く … 画面には回答の文より条文へのリンクを大きく出し、「条文を開いて確かめた」を押さないと回答を閉じられないようにします
2. 法規担当が、送られた質問に答える … escalated と、職員が「法規担当へ送る」を押したものです
3. 法規担当が、回答を抜き取りで見る … 毎週、answered の回答から20件を選び、根拠と答えが合っているかを確かめます
4. 所管課が、食い違いの指摘を見る … 月次の集計で返された食い違いについて、マニュアルを直すか法規担当と相談します

3番目の抜き取りを省かないでください。 職員は根拠の条文を開いても、それが自分の質問に当てはまる条文かまでは分からないことがあります。誤った根拠で答えた回答は、職員の側では気づかれません。抜き取りで見つかった誤りは、前処理の文書の分け方か、指示の書き方の問題として直します。

目標は、1件あたり4.5分です。 職員が根拠の条文を確かめる時間と、法規担当が送られた質問に答える時間、抜き取りの時間をならした値です。送られる質問が全体の2割という想定で、2割を大きく超える月は、索引に入っていない文書があるか、メタデータの付け替えが漏れています。

例外に対処する

下から3行目の「最終の取り込み日」を画面に出すのは、改正の反映が遅れたときのためです。 職員が、回答がいつ時点の例規にもとづくかを知っていれば、直近の改正の有無を自分で確かめられます。

記録を残す

• 質問の文、質問者の所属、日時、セッション
• answer メソッドに渡した絞り込みの条件と、応答の全文
• 回答しなかった理由、支持スコア、根拠の文書の一覧
• 法規担当へ送られた質問と、法規担当の回答
• 抜き取りで見つかった誤りと、その原因
• 例規とマニュアルの食い違いの指摘と、所管課の対応
• 索引の取り込みの日時と、そのときの文書の一覧

4つ目が、この構成を育てる材料になります。 法規担当の回答がたまると、どの種類の質問が索引で答えられず、どの例規の条文が探しにくいかが見えてきます。 マニュアルに1段落足すだけで次から答えられる質問が、毎月いくつも見つかります。

最後の行は、後から回答を確かめるための記録です。 職員から「この回答は正しかったのか」と問われたとき、そのときどの版の例規が索引に入っていたかが分からないと、確かめようがありません。