議会の質問通告を受けて、過去の答弁と施策資料を根拠に答弁書の下書きを作る

処理の起点を決める

総務課が答弁管理リストに質問項目を登録したことを起点にします。 質問通告を受け取ったときではありません。通告はそのままでは複数の質問が1つの文書にまとまっており、担当課も決まっていないからです。担当課の割り振りは人が行い、割り振りが済んだ項目から1件ずつ動かします。

登録する項目は、議員名、会議の種類（本会議／委員会）、質問の要旨、担当課、答弁者（首長・部長など）、提出期限です。答弁者を持たせるのは、首長が答える項目と部長が答える項目で、文の踏み込み方が違うためです。

同じ項目を二度動かさないよう、リストの状態の列で管理します。 「登録」から「下書き作成中」「下書き済み」へ移し、失敗したときは「登録」に戻します。リストの「登録」のまま残っている数が、そのまま未処理の数です。 定例会の月は通告の締切の翌日に数十件がまとめて登録されるので、1件ずつ順に処理し、同時に何十件も生成AIを呼ばないようにします。

入力データを集める

質を決めるのは、下の3つです。 過去の答弁書に「使った資料の一覧」が無いと、前回の数字がどこから来たのかが分かりません。施策資料に時点が無いと、古い年度の実績を最新として書きます。 答弁の書き方の約束事が無いと、文は整っていても、庁内の誰もが違和感を持つ下書きになります。

約束事の一覧は、課長段階で直された箇所から作ります。 過去の原稿と確定版を比べると、「前向きに」を削った、「させていただく」を直した、といった修正が何度も出てきます。同じ直しが繰り返されている箇所が、そのまま約束事です。

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

会議録と答弁書の原稿は、索引に写してから使います。 会議録検索システムのテキストを定期的に書き出し、答弁書のWord文書とあわせて、質疑・答弁の単位に切って索引に入れます。索引の1件には、議員名、会議名、日付、担当課、答弁者を項目として持たせます。

検索は、論点ごとに分けて行います。 質問の要旨全体で引くと、長い質問ほど焦点がぼけ、関係の薄い答弁が上位に来ます。論点に分けてから、論点ごとに上位の数件を取ります。 絞り込みの条件として担当課と期間を付け、10年前の答弁が上位に来るのを防ぎます。

施策資料は、担当課が登録したものだけを使います。 庁内の共有フォルダ全体を検索にかけると、検討段階の資料や、公表前の数字が混ざります。 どの資料を答弁の根拠にしてよいかは、担当課が決めることです。

AIへ渡す前に整形する

1. 論点への分割 … 質問の要旨を、答えるべき問いの単位に分けます。「現状は」「課題は」「今後の方針は」と3つ聞かれていれば、3つの論点にします
2. 答弁書の原稿の最終版の選別 … 同じ答弁の原稿が何版もある場合、確定版だけを索引に入れます
3. 会議録と原稿の対応付け … 同じ答弁の会議録と原稿を同じ番号で結び、議場で読まれた文を優先します
4. 資料の時点の付与 … 施策資料のそれぞれに「いつ時点の数字か」を付けます。付いていないものは使いません
5. 根拠の番号付け … 生成AIに渡す過去答弁と資料の断片に、A1、A2、M1 のような番号を付けます
6. 個人の情報の除去 … 過去の質疑に出てくる住民の氏名や個別の事案は、渡す前に伏せます
7. 渡す量の調整 … 論点ごとに過去答弁は上位5件、資料は関係する箇所だけに絞ります

5番目が、この構成の要です。 番号を付けて渡すと、生成AIは下書きの各文に番号を付けて返せます。番号があれば、後段で「その番号の資料に本当に書いてあるか」を機械で照合できます。 番号の無い資料を渡すと、どの文がどこから来たのかを、人が読み比べて探すことになります。

3番目を省くと、同じ答弁が2回出てきます。 会議録と原稿の両方が上位に来て、しかも細部が違うため、どちらが正しいのかを起案者が調べることになります。

AIに処理させる

させるのは、渡した資料を組み立てて、答弁の材料と文案を作ることです。 項目は次の5つです。

右端の列が、この構成で最も大事な区別です。 答弁書は、根拠の無い文を書いてはいけない文書です。「根拠が無いので書けない」を、空欄ではなく要確認の項目として明示的に返させます。 空欄のままだと、起案者は埋め忘れと区別できません。

2行目と3行目が最も起きやすい失敗です。 生成AIは、国の制度の一般的な説明や、全国の傾向を知っています。知っていることを書くと、文は充実して見えますが、その一文が本市の資料のどこにも無い、という答弁書になります。 渡した資料以外を使わせないことを、指示の中で何度も明記します。

指示内容を固定する

あなたは市役所の担当課で、議会答弁書の下書きを作る職員を補助します。
下書きは起案者が確認・修正してから、課長・部長・答弁調整に回ります。

【使ってよい情報】
渡した【過去の答弁】（番号 A1〜）と【施策資料】（番号 M1〜）だけです。
それ以外の知識（国の制度の一般的な説明、他の自治体の事例、
全国の統計など）は、正しいと思っても書かないでください。

【作るもの】
1. 論点の整理：質問が問うていることを、論点ごとに一文で。
2. 前回答弁との差分：同じ論点の過去の答弁があれば、その要点と、
   今回の施策資料で変わった点・変わっていない点を並べる。
3. 答弁の骨子：論点ごとに、答える順番と要素を箇条で。
4. 下書き：答弁者（{answerer}）の口調で。1文ごとに根拠の番号を付ける。
5. 要確認の一覧：資料に無い数字、方針の書かれていない点、
   他の課の所管に関わる点。

【厳守事項】
- 下書きの各文には、根拠にした番号（A1、M2 など）を必ず付けてください。
  根拠にできる番号が無い文は、status を needs_check にしてください。
- 数字は、施策資料に書かれているとおりに写してください。
  計算し直したり、四捨五入したり、年度を読み替えたりしないでください。
  資料に無い数字は書かず、要確認の一覧に入れてください。
- 施策資料の時点（as_of）を、数字と一緒に書いてください。
- 今後の方針が資料に書かれていない場合は、方針を作らないでください。
  「方針未定」とし、要確認の一覧に入れてください。
- 前回の答弁で「検討する」「研究する」とした件は、その後の経過が
  資料にあるかを確かめ、無ければ要確認の一覧に入れてください。
- 前回の答弁と今回の資料が食い違う場合は、どちらかに合わせず、
  差分として両方を示してください。
- 言い回しは【答弁の約束事】に従ってください。
- 質問の背景や議員の意図は推測しないでください。
- 過去の質疑に出てくる個人の氏名や個別の事案は書かないでください。

【答弁者】{answerer}
【質問項目】{question}
【論点】{issues}
【過去の答弁】{past_answers}
【施策資料】{materials}
【答弁の約束事】{style_rules}

「正しいと思っても書かない」をあえて書いています。 「渡した資料だけを使う」とだけ指示すると、生成AIは国の制度の説明のような一般に正しいことは例外として書いてよいと扱いがちです。正しいかどうかではなく、本市の資料に無いことが問題だと明記します。

「年度を読み替えない」も同じ理由です。 資料に「令和6年度実績」とあれば、今が令和7年度でも「昨年度」とは書かせません。読み替えは人が行います。 年度の境目の定例会で、読み替えの誤りが最も起きやすいからです。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "question_id": "",
  "issues": [
    { "issue_id": "I1", "summary": "" }
  ],
  "diff_from_previous": [
    { "issue_id": "I1", "previous_ref": "A2",
      "previous_point": "", "changed": "", "unchanged": "" }
  ],
  "outline": [
    { "issue_id": "I1", "points": [""] }
  ],
  "draft": [
    { "issue_id": "I1", "sentence": "", "refs": ["M1"],
      "numbers": [{ "value": "", "ref": "M1", "as_of": "" }],
      "status": "grounded | needs_check" }
  ],
  "to_check": [
    { "issue_id": "I1", "type": "missing_number | no_policy | other_dept | pending_followup",
      "detail": "" }
  ]
}

構造化出力を使うのは、機械で照合するためです。 Azure OpenAI の構造化出力は、指定した JSON Schema にモデルを従わせる機能で、Chat Completions API では response_format、Responses API では text.format にスキーマを渡すとされています。すべての項目を必須にし、additionalProperties を false にする必要があります。スキーマ全体で100個までのプロパティ、5階層までの入れ子という制限もあります。上の形はこの範囲に収まります。

1つ目の理由は、draft を文の単位で持てることです。 1文ごとに refs と status が付くので、中継プログラムは「refs に書かれた番号が、渡した資料の番号の中にあるか」を1文ずつ確かめられます。無い番号が付いていれば、その文は needs_check に書き換えます。

2つ目は、numbers を分けて持てることです。 下書きの文に数字が入っていれば、その数字と根拠の番号を別に返させます。中継プログラムは、その数字の文字列が、その番号の資料の本文に含まれるかを照合します。 含まれなければ、文が正しく見えても要確認に回します。

3つ目は、to_check の種類で担当を分けられることです。 missing_number は事業担当へ、no_policy は課長へ、other_dept は総務課へ、pending_followup は前回「検討する」とした件の経過の確認です。起案者は、誰に何を聞けばよいかが分かった状態で下書きを受け取ります。

構造化出力は、Azure OpenAI の「独自のデータを使う（Bring your own data）」の機能とは一緒に使えないとされています。 そのため、この構成では検索を中継プログラムの側で行い、結果を番号付きでプロンプトに入れて渡します。 検索の結果を人が後から確かめられる点でも、この形のほうが向いています。

システムへ連携する

下書きは、答弁書の様式そのものには書き込みません。 答弁管理リストの項目に、下書きと根拠の一覧、差分表、要確認の一覧を並べて置きます。起案者は、それを見ながら自分で様式に起こします。 様式に直接書き込むと、確かめないまま上へ上げる経路ができます。

施策資料は読み取りだけです。 数字が古いと分かっても、資料を書き換えるのは事業担当です。中継プログラムは、資料の時点が古いことを要確認として伝えるだけにします。

人が確認する

この業務では、すべての下書きを人が確かめます。 答弁書は議場で読まれ、公開され、次の答弁の根拠になります。低信頼のものだけを人に回す、という設計はとりません。

1. 起案者が根拠を開く … refs の番号を開き、その資料に本当にそう書いてあるかを確かめます。数字は必ず資料の該当箇所と見比べます
2. 要確認を埋める … to_check の種類ごとに、事業担当・課長・総務課へ確かめます。埋まらない項目は、埋まらないまま課長へ上げます
3. 前回答弁との差分を課長が見る … 変わった点をどう説明するかは課長が決めます
4. 答弁調整で直された箇所を記録する … 下書きから最終版までに、どこがどう直されたかを残します

1番目を省かないでください。 構成上、根拠の番号と数字の文字列は機械で照合していますが、照合できるのは「その資料にその文字列があるか」までです。 文脈として正しく使われているか、たとえば「計画値」を「実績」として書いていないかは、人が読まないと分かりません。

目標は、1件あたり75分です。 下書きの確認と修正に50分、根拠と要確認の確かめに25分という想定です。材料集めの時間はほぼ無くなり、残るのは中身の判断です。 75分を大きく超える件が続くなら、施策資料の登録が足りていないか、約束事の一覧が古くなっています。

例外に対処する

上の3行が大半を占めます。 どれもAIの問題ではなく、質問通告の書き方と、資料の登録の問題です。 施策資料の登録が遅れている課ほど、下書きの質が落ちます。

記録を残す

• 質問項目の登録内容と、総務課が割り振った担当課
• 検索に使った論点と、取り出した過去答弁・資料の番号と本文
• 生成AIが返したJSONの全文と、使ったモデルのデプロイ名
• 中継プログラムの照合結果（根拠の番号の実在、数字の照合の成否）
• 起案者が直した箇所と、課長・部長・答弁調整で直された箇所
• 確定した答弁書と、そのとき使った資料の一覧

5つ目が、この構成を育てる材料になります。 課長段階で同じ種類の直しが続くなら、それは約束事の一覧に足すべき項目です。起案者に返らなかった「直された理由」が、次の下書きの指示として残ります。

6つ目は、翌年の自分のための記録です。 確定した答弁書と使った資料を結んでおけば、次に同じ質問が来たとき、前回の数字の出どころがすぐに分かります。 第3章の（b）は、この1行で解消します。