市役所の各課から届く物品の購入依頼メールから、品名・数量・予算科目・納期を抜き出して購入台帳にそろえ、見積の要否と予算の残りを知らせる

処理の起点を決める

共有メールボックスへのメールの到着を起点にします。 対象は受信トレイではなく、仕分けのルールで「購入依頼」フォルダへ移したメールにします。件名に「【購入依頼】」を含むもの、または各課の担当者が依頼の様式から送ったものをルールで移します。トリガーは設定したフォルダの中だけを見るので、問い合わせや業者からの連絡を巻き込みません。

ここで注意が1つあります。 公式の説明では、フォルダへ移したメールについて、古いメールにも断続的にトリガーが動くことがあるとされています。トリガーが受信日時をもとに動き、移しても受信日時は変わらないためです。メッセージIDで台帳を引き、すでに行があれば止める処理を最初に置きます。

添付の依頼票は、本文と同じ扱いにはしません。 Word や Excel の依頼票の中身を読むには別の処理が要るので、この構成では本文に書かれた項目だけを抜き出し、添付があることを台帳に印として残します。 添付にしか書かれていない依頼は、第7章の例外処理で扱います。導入に合わせて、依頼はメール本文の様式で送るよう各課に案内します。

入力データを集める

質を決めるのは、予算科目の一覧の「各課での呼び方」の列です。 各課は「消耗品費」「事務用品」「需用費で」とさまざまに書きます。呼び方の一覧が無いと、AIが科目を当て推量で決めます。 呼び方と正式な科目の対応を、財政課の担当と作ります。

予算の残りは、出力した日と一緒に持ちます。 週1回の出力なので、その後の執行は反映されていません。連絡の文面にも「〇月〇日時点」と必ず書きます。 残額を最新の数字として扱わないことが、第3章の（d）を防ぐうえで逆に大事です。

金額の区分は、市の契約規則の値を入れます。 地方自治法施行令は、予定価格が別表第五の額の範囲内で、地方公共団体の規則で定める額を超えないときに随意契約によることができるとしています。別表第五で財産の買入れの市町村の額は150万円です。市の規則の額はこの範囲内で市が決めるので、一覧には規則の値をそのまま入れます。 見積を何者から取るかの金額も、市の規則や要領の値を入れます。

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

Get items は Filter Query に OData の条件式を書けます。 課のコードと科目のコードで1行に絞ってから残額を読みます。台帳を全件読んでからフローの中で絞ると、年度の後半に遅くなります。

予算の残りの一覧は、財務会計システムから直接つなぎません。 財務会計システムは別の系統にあり、系統をまたぐデータの持ち出しは、市の情報セキュリティポリシーで決まった手順で行います。 週1回の出力を決まった担当が SharePoint のリストへ取り込む運用にし、この構成からは財務会計システムに触れません。

本文の暗号化に気をつけます。 公式の説明では、暗号化されたメールではトリガーの出力に本文が入らず、保護されている旨の注記になるとされています。暗号化して送られた依頼は、例外処理で人へ回します。

AIへ渡す前に整形する

1. 重複の確認 … メッセージIDで購入台帳を引き、すでに行があれば止めます
2. 依頼課の特定 … 送信者のアドレスを課の一覧と照らし、課のコードと既定の納品場所を決めます。一覧に無いアドレスは課を推測しません
3. 本文の整形 … 署名、過去のやり取りの引用、定型の注意書きを落とします
4. 添付だけの依頼の判定 … 本文が数行で、添付がある依頼は「添付のみ」の印を付けます
5. 予算科目の呼び方の一覧を渡す … 予算科目の一覧の「各課での呼び方」をプロンプトに渡します
6. 金額の区分は渡さない … 区分への当てはめはフローで行うので、AIには区分の値を見せません

6番目が、この構成の要です。 区分の境目の金額をAIに見せると、境目の近くの依頼で、予定金額を区分に合わせた数字に寄せることがあります。 AIには金額を写させるだけにし、区分はAIが見えないところで当てはめます。

AIに処理させる

させるのは、依頼の本文から決まった項目を写し出し、書かれていない項目と原文の該当箇所を示すことと、確認済みの項目から連絡の文面の下書きを作ることです。

not_stated と ambiguous を分けるのは、聞き返しの文面が違うからです。 書かれていないなら「ご記入ください」、曖昧なら「〇〇とありますが、具体的な数量をお知らせください」と返します。依頼課にとって、何を直せばよいかが一目で分かる聞き返しになります。

1行目と2行目が、この構成の中心です。 「前回と同じものを10箱」と書かれた依頼で、AIは前回の金額をそれらしく埋めがちです。埋まった数字が区分の境目の下にあれば、見積が要らない依頼として流れます。

指示内容を固定する

あなたは市役所の契約管財課で、各課からの物品の購入依頼を受け付ける立場です。
依頼メールの本文に書かれていることだけを使って、決まった項目を写してください。
推測で埋めないでください。

【写す項目】品目ごとに次を写してください。
- item_name：品名　- spec：規格・型番・色・サイズ
- quantity：数量　- unit：単位
- unit_price：単価　- amount：予定金額　- tax：税込／税抜／不明
- budget_item：予算科目（下の「予算科目の呼び方の一覧」から正式名を選ぶ）
- due_date：納期　- delivery_place：納品場所

【status の付け方】各項目に status を付けてください。
- ok ........... 値が書かれており、そのまま写せた
- not_stated ... 書かれていない
- ambiguous .... 書かれているが、値として確定できない
                 （「くらい」「前回と同じ」「なるべく早く」「適量」など）
- not_matched .. 予算科目の書き方が一覧のどれにも当たらない

【厳守事項】
- 金額が書かれていなければ not_stated です。過去の依頼や相場から
  金額を埋めないでください。「前回と同じ」は ambiguous です。
- 単価×数量の計算をしないでください。amount は書かれていれば写し、
  書かれていなければ not_stated にしてください。
- 品名や規格を、似た品や一般的な名前に置き換えないでください。
- 見積が要るか、どの契約方法になるかは書かないでください。
- 予算の残りについては何も書かないでください。
- 各項目の evidence に、根拠にした本文の文をそのまま写してください。
- 本文が「添付のとおり」などで、項目が本文に無い場合は
  attachment_only を true にしてください。
- 購入依頼ではないメールなら、項目を写さず is_request を false に
  してください。
- Don't include JSON markdown in your answer.

【予算科目の呼び方の一覧】{budget_aliases}
【依頼課】{dept_name}（既定の納品場所：{default_place}）
【件名】{subject}
【本文】{body}

「前回と同じ」を名指しで ambiguous にしているのは、いちばん多い書き方だからです。 一般的な指示だけでは、文脈から前回を「推定」して埋めます。例に出した書き方は、そのとおりに扱われやすくなります。

最後の英文の1行は、公式の案内に合わせたものです。 JSON が作れないというエラーが出るとき、この一文を足すよう案内されています。

出力形式を固定する

次の形のJSONで受け取ります。 AI Builder のプロンプトの出力を JSON にし、例を書き換えて Custom の形に固定します。

{
  "is_request": true,
  "attachment_only": false,
  "items": [
    {
      "item_name": { "value": "", "status": "ok | not_stated | ambiguous", "evidence": "" },
      "spec": { "value": "", "status": "", "evidence": "" },
      "quantity": { "value": "", "status": "", "evidence": "" },
      "unit": { "value": "", "status": "", "evidence": "" },
      "unit_price": { "value": "", "status": "", "evidence": "" },
      "amount": { "value": "", "status": "", "evidence": "" },
      "tax": "税込 | 税抜 | 不明"
    }
  ],
  "budget_item": { "value": "", "status": "ok | not_stated | not_matched", "evidence": "" },
  "due_date": { "value": "", "status": "", "evidence": "" },
  "delivery_place": { "value": "", "status": "", "evidence": "" }
}

1つ目の理由は、金額の区分への当てはめをフローに任せられることです。 amount が ok ならその値を、not_stated で単価と数量が ok ならフローで掛け算した値を使います。どちらも無ければ区分を当てはめず、「金額未記載」として聞き返しに回します。

2つ目は、品目が複数ある依頼をそのまま台帳の複数行にできることです。 items は品目ごとの要素を並べた配列で、キーのある要素の配列なので、プロンプトの JSON の形として定義できます（キーの無い配列は定義できないとされています）。

3つ目は、evidence で確認が速くなることです。 契約担当は、承認の画面で項目と原文の該当箇所を並べて見られます。メールを開き直さずに確かめられます。

システムへ連携する

文面の下書きは、2つ目のプロンプトで作ります。 渡すのは、契約担当が確かめる前の抜き出しの結果ではなく、フローが当てはめた区分と、リストから引いた残額と出力日です。数字はすべてフローが差し込んだものにし、AIには数字を作らせません。

財務会計システムと電子決裁には書き込みません。 予算の執行の手続きは、依頼課と契約管財課がこれまでどおり行います。この構成が出すのは、台帳の行と、依頼課への連絡までです。

人が確認する

依頼課へ出す連絡は、すべて契約担当が確かめてから送ります。 承認の画面で見るのは次の4つです。

1. 品目・数量・金額が原文と合っているか … evidence と値を並べて見ます
2. 予算科目が合っているか … 呼び方の一覧で選ばれた科目が、依頼の用途と合うかを見ます
3. 見積の区分と、今月の同じ品目の合計 … 区分の境目の近くの依頼と、合計で区分が上がる依頼を重点に見ます
4. 文面 … 聞き返しの内容が依頼課に分かるか、残額の日付が入っているかを見て、直して承認します

3番目で分割に当たるかを決めるのは契約担当です。 同じ品目でも、別の事業の予算で別の時期に要る依頼は分割ではありません。構成は「ほかにもあります」と示すだけにし、判断の言葉を書きません。

目標は、360件をならして1件3分です。 項目がそろった依頼は承認の画面で1分ほどで済みますが、聞き返しと区分の境目の依頼は確かめることが多くなります。3分を大きく超える月は、呼び方の一覧が足りていないか、本文の様式が各課に浸透していません。

例外に対処する

上の3行目がいちばん多い例外です。 導入の直後は、添付の依頼票で送ってくる課が残ります。件数を課ごとに数え、多い課から本文の様式を案内します。

記録を残す

• メッセージID、受信日時、送信者、件名、本文の原文
• AIが返したJSONの全文と、そのとき渡した呼び方の一覧の版
• 当てはめた金額の区分と、今月の同じ品目の合計の値
• そのとき使った予算の残りの一覧の出力日と残額
• 承認した人、承認した時刻、承認前の文面と送った文面の違い
• 契約担当が直した項目（品名・数量・金額・予算科目）

3つ目で今月の合計を残すのは、後から分割の扱いを問われたときのためです。 当時どの依頼が合算の対象として示されていたかが、台帳の行だけで説明できるようにします。