自治体の担当課が庁内の各課へ出した照会への回答を集め、回答の要点を一覧に要約して、未回答の課と内容の確認が要る回答を担当に示す

処理の起点を決める

フロー①は、照会用の共有メールボックスに回答のメールが届いたことを起点にします。 担当者の個人のメールボックスではなく、総務課の共有メールボックスを宛先にしてもらいます。担当が休んでも、異動しても、回答の受け口が変わらないようにするためです。

件名に照会番号の書き方を決めます。 「【照会2026-031】」のように、照会を出すときの件名にそのまま入れておき、各課には返信の形で返してもらいます。 フローは件名からこの番号を取り出し、照会台帳と結びます。番号の無いメールは、照会への回答として扱いません。

フロー②は、毎朝8時の繰り返しのトリガーで動かします。 スケジュールされたクラウド フローは、「毎日午前10時」のような定期的なスケジュールで実行でき、作ると繰り返しのトリガーがフローに入ります。メールの着信のトリガーがまれに取りこぼすことがあるので、毎朝、共有メールボックスにある照会番号付きのメールと回答一覧を突き合わせ、一覧に無いものをフロー①に回し直します。

入力データを集める

質を決めるのは、照会台帳の「問いの文」です。 AIが回答を問いごとにまとめるには、問2が何を聞いているかを知っている必要があります。照会の文書の問いを、番号つきでそのまま写して登録します。

前回の回答は、毎年くり返す照会にだけ使います。 件数が前回の10倍になっている、前回は「該当あり」だったのに今回は「該当なし」、といった変化は確認点の候補になります。ただし、変化が正しいかどうかはAIに判断させません。 「前回と大きく違う」と示すだけです。

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

添付は、トリガーで一緒に取らずに、Get Attachment (V2) で取ります。 コネクタの説明では、トリガーで添付を含める設定にすると、添付のある多くのメールが同時に届いたときに、添付のダウンロードで時間切れになることがあるとされ、添付を含めずに Get Attachment (V2) で取る方法が示されています。

様式を SharePoint に保存してから読むのは、コネクタがドキュメント ライブラリのファイルを扱うためです。 保存した様式は、そのまま照会ごとの回答の原本になります。なお、コネクタの説明では、Excel のファイルはコネクタが最後に使ってから最大6分ロックされることがあるとされています。担当が保存直後の様式を開いて直すと、ぶつかることがあります。

AIへ渡す前に整形する

1. 照会番号の取り出し … 件名から「【照会2026-031】」の形を取り出します。無ければ、照会への回答ではないとして終わります
2. 送り主の課の特定 … 送り主のアドレスを課の一覧で引きます。庶務担当の個人のアドレスから届くこともあるので、課のアドレスと庶務担当のアドレスの両方で引きます
3. 様式の確認 … 添付の形式と、決まった名前のテーブルがあるかを確かめます。無ければ、様式を使っていない回答として扱います
4. 表の行を文にする … 「問2｜該当あり｜件数 12｜単位 件｜内容 …」のように1行1問の文にして、プロンプトに渡します
5. 本文の整理 … 引用された照会の本文と署名を除き、その課が新しく書いた部分だけを残します
6. 同じ課からの2通目 … 同じ照会番号で同じ課から2通目が届いたら、「差し替え」として扱い、前の行を残したまま新しい行を正にします

5番目を省くと、要点に照会の文書の文言が混ざります。 返信の形で返してもらうので、本文の下には総務課が書いた照会の文がそのまま付いています。その文を回答として要約すると、どの課の要点も同じ文になります。

AIに処理させる

させるのは、1課の回答を問いごとに短くまとめることと、問いとずれた回答・確かめが要る回答を見つけて理由を書くことだけです。

確認点の理由は、次の6つに限ります。

3行目が、いちばん起きやすい失敗です。 件数の欄が空で、自由記述に「年に10件程度」と書いてあると、AIは親切に件数を10として返します。集計に入るのは様式の欄の値だけにし、自由記述の数字は要点の文の中にだけ残します。

指示内容を固定する

あなたは市役所の総務課で、庁内の各課へ出した照会の回答を取りまとめる担当です。
1つの課の回答を、照会の問いごとに整理してください。
書かれていないことを補わないでください。

【照会の問い】{questions}
【この課の回答（様式の表）】{answer_rows}
【この課のメール本文】{mail_body}
【前回の同じ照会でのこの課の回答】{previous_answer}

【やること】
1. 問いごとに、回答の区分を「該当あり」「該当なし」「検討中」「回答なし」から選ぶ
2. 問いごとに、自由記述の要点を80字以内でまとめる
3. 件数と単位は、様式の欄の値をそのまま写す
4. 確認が要る回答があれば、理由のコードを選び、根拠にした文をそのまま写す

【理由のコード】
no_answer：問いの欄が空、または問いに答えていない
off_question：別の問いのことを書いている
unit_unclear：件数はあるが単位が分からない
pending：「確認中」「後日回答」とだけ書いてある
refer_other：ほかの課に振っている
big_change：前回と比べて該当の有無や件数が大きく変わっている

【厳守事項】
- 件数は様式の件数の欄の値だけを写してください。
  自由記述にある数字を件数の欄に移さないでください。
- 件数の合計や平均を計算しないでください。
- 単位が書かれていないときは、単位を推測せずに空にし、unit_unclear を付けてください。
- 回答の内容が正しいかどうか、望ましいかどうかの意見を書かないでください。
- 要点には、照会の問いの文をそのまま書かないでください。この課が書いたことだけをまとめてください。
- 様式が無く本文だけの回答も、本文から同じように整理してください。
- 回答に JSON マークダウンを含めないでください。

「照会の問いの文をそのまま書かない」を入れているのは、要点が問いの言い換えになるのを防ぐためです。 回答が短いと、AIは「〇〇の実施状況について、該当があると回答」のように、問いを言い直して80字を埋めます。一覧で読むと、どの課の要点も同じに見えます。

プロンプトの温度は、既定の0のまま使います。 公式の説明では、温度は0から1の範囲で、低いほど予測可能で保守的な出力になるとされています。同じ回答を2回まとめさせて要点が変わると、差し替えのたびに一覧の文が揺れ、どこが変わったのかを担当が追えなくなります。 要点に言い回しの工夫は要りません。

最後の1行は、公式の説明にある対策です。 プロンプトのテストで「JSON を生成できませんでした」と出るとき、モデルが JSON をメタデータで囲んでいることがあり、この指示を加える方法が示されています。

出力形式を固定する

次の形のJSONで受け取ります。 プロンプトの出力を JSON にし、形式をカスタムで保存します。

{
  "inquiry_no": "2026-031",
  "section": "道路維持課",
  "answers": [
    {
      "question_no": "2",
      "category": "該当あり | 該当なし | 検討中 | 回答なし",
      "count": "12",
      "unit": "件",
      "summary": "",
      "flags": [
        { "code": "unit_unclear", "evidence": "" }
      ]
    }
  ],
  "needs_check": true
}

JSONで受け取る1つ目の理由は、問いごとに列へ分けて書き込めることです。 回答一覧のリストに、1課1行で「問1の区分」「問1の要点」「問2の区分」…と列を並べ、問いごとに縦に読める表にします。国・県への回答を作るときは、この列を上から読むだけです。

2つ目は、needs_check で印を付けられることです。 flags が1つでもあれば needs_check を真にし、一覧の「要確認」の列に印を付けます。担当は、この列で絞り込んだ行だけを開きます。

3つ目は、形式が変わらないことです。 公式の説明では、プロンプトを保存すると形式が固定され、フローで使うときは保存された形式が使われ、変わらないとされています。照会ごとに問いの数が違っても、answers の配列の長さが変わるだけで、フローの側は直しません。

なお、JSON の形式の定義には制限があり、フィールドのキーの無い配列（["abc", "def"] のような形）はサポートされません。 flags をコードの文字列の配列にせず、キーを持つ要素の配列にしているのはこのためです。

システムへ連携する

各課へは何も送りません。 督促も問い合わせも、フローは下書きまでにします。同じ課に同じ日に2回督促が届くと、照会そのものの信頼が落ちます。 送るのは担当です。

フロー②が Teams に流すのは、照会ごとの3行です。 「照会2026-031：回答22課／未回答8課（期限まで2日）／要確認5課」。未回答の課の名前と、督促の文の下書きは、そのメッセージから回答一覧の絞り込みの画面に飛べるようにします。

人が確認する

担当が開くのは、要確認の印が付いた回答と、未回答の課だけです。 印の無い回答は、一覧の要点を読んで終わりにします。

1. 要確認の回答を、理由のコードごとに見る … pending と refer_other は、問い合わせの先が決まっているので先に片付けます
2. unit_unclear と off_question は様式を開く … 一覧の根拠の文と、保存された様式を見比べます
3. big_change は、前回の回答と並べて見る … 変化に理由があるか、記入の誤りかを課に聞きます
4. 督促の下書きを直して送る … 期限まで2日を切った課から送ります
5. 確かめた結果を一覧に残す … 問い合わせて直った値と、確かめて問題が無かった印を付けます

3番目を省かないでください。 前回と大きく違う回答は、記入の誤りであることもあれば、事業が始まった・終わったという本当の変化であることもあります。どちらかを決められるのは回答した課だけです。

要点が回答の中身とずれていないかは、最初の1か月だけ全件を見ます。 1か月見て、要点の書き方に問題が無ければ、印の無い回答を開くのはやめます。

例外に対処する

上から3行目までで、例外のほとんどを占めます。 どれもAIの問題ではなく、回答の返し方の決まりの問題です。 照会の文書に「件名を変えずに返信してください」「様式の表の形を変えないでください」と1行ずつ書くほうが、フローの例外処理を増やすより効きます。

記録を残す

• 回答のメールの受信日時、送り主、件名と、保存した様式のファイル
• プロンプトに渡した文（表の行を文にしたものと、整理した本文）
• プロンプトが返した JSON の全文
• 回答一覧に書き込んだ行と、差し替えの履歴
• 未回答の通知を流した日時と、督促を送った日時
• 担当が確かめた結果（問い合わせて直った値、問題が無かった印）

3つ目の JSON の全文を残すのは、要点と元の回答を後から見比べるためです。 国・県へ回答した後に数字の誤りが見つかったとき、どの課の様式のどの欄から来た数字かを、ファイルと JSON でたどれます。

照会ごとのフォルダと回答一覧は、文書の保存年限の規程に合わせて残します。 照会の取りまとめは、国・県への回答の根拠になる文書です。