国や都道府県から届く照会のメールを、エージェントが読んで担当課の候補を付け、期限つきの台帳に載せて期限前に確認する

処理の起点を決める

2つのトリガーを持ちます。 1つは依頼の受信、もう1つは毎朝の期限の見回りです。

受信は Email Trigger (IMAP) で、共有メールボックスを見張ります。 Mailbox Name で受付用のフォルダを指定し、Action で受け取ったメールを既読にするかを選びます。Download Attachments を有効にしないと、鏡文と調査票が取れません。 処理が重くなるとされていますが、この業務では添付が本体です。Custom Email Rules で、照会元のドメインや件名の決まった語で絞れます。

見回りは Schedule Trigger で、平日の朝8時30分に動かします。 Custom（Cron）で曜日を指定します。Schedule Trigger はワークフローのタイムゾーン、無ければインスタンスの既定を使い、自前で立てたインスタンスの既定は America/New York です。 ワークフローの設定で Asia/Tokyo を指定し、保存して公開（publish）します。 公開しないと定時に動きません。

入力データを集める

質を決めるのは、過去の照会の記録の「断られた履歴」です。 件名だけを見ると担当課が明らかに見える照会でも、実際には別の課が回答していたものがあります。前年度に一度断られた課を候補の1番目に出すと、同じやり取りを毎年繰り返します。

事務分掌は、条文ごとに1行の表にします。 規則の全文をそのまま渡すと、AIは条文の言い回しが近いだけの課を候補に挙げます。課の名前、条文の番号、所掌事務の文の3列にしておくと、根拠として条文の番号を返させられます。

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

添付の文字は、エージェントの外で先に取り出します。 Extract From File ノードは、PDFや表計算のファイルなどのバイナリをJSONに変えるノードです。鏡文のPDFは本文の文字、調査票は設問の行を取り出し、メールの本文とまとめてエージェントに渡します。

search_past_inquiries を先に、search_duties を後に呼ばせます。 事務分掌から先に探すと、条文の上では当たるが実際には回答していない課が出ます。庁内の実際の分担は、規則より過去の記録のほうに出ています。

過去の照会の検索は、照会元と件名の語の両方で行います。 照会の名称は年度ごとに「令和○年度」の部分や調査の副題が変わるため、件名の完全一致では当たりません。道具の側のワークフローで、年度の表記と括弧書きを落とした件名の語で引き、照会元が同じものを上位に並べて返します。 照会元が国から都道府県経由に変わっただけの照会も、同じ照会として拾えます。

AIへ渡す前に整形する

1. 差出人の確認 … 照会元のドメインの一覧に無い差出人は、エージェントに渡さず「要確認」として文書係へ回します
2. 重複と差し替えの検知 … 文書番号と件名で台帳を引き、同じ照会の再送や「訂正」「差し替え」の版を見分けます
3. 添付の取り出し … PDFと調査票から文字を取り出します。パスワード付きのファイルや取り出せないファイルは、その旨を記録します
4. 本文の整理 … 署名、転送の履歴、自動で付く注意書きを落とします
5. 長さの制限 … 調査票の設問が長いものは、表題と最初の設問、提出先の記載だけを渡します

2番目を省かないでください。 照会元が期限を延ばしたり、様式を差し替えたりすると、同じ照会がもう一度届きます。別の照会として台帳に載ると、期限の古い行が残り、催促が二重に飛びます。

AIに処理させる

させるのは、照会の項目を読み取り、担当課の候補を根拠付きで出すことです。 期限の日付への変換と、残りの営業日の計算はさせません。

「通知（回答不要）」を分けるのは、台帳を汚さないためです。 周知だけの通知まで期限つきで載せると、回答の要らない行に毎朝催促が飛びます。

指示内容を固定する

System Message に次の内容を入れます。

あなたは市役所の文書担当で、国や都道府県から届いた照会・調査の依頼を
読み、庁内の担当課の候補を探す担当です。担当課は決めず、候補と根拠を
返してください。

【読み取る項目】
照会元、文書番号、発出日、件名、照会の種類、期限の文字列、提出先、
提出の方法、様式の名前、照会元の問い合わせ先

【期限の扱い】
- 期限は、書かれている文字列をそのまま deadline_text に写してください。
- 日付に直さないでください。曜日や時刻もそのまま写してください。
- 「別途連絡」「調査票に記載」のように日付が無いときは、そのまま写し、
  questions_for_clerk に「期限が読み取れない」と書いてください。
- 期限が複数ある場合（一次回答と最終回答など）は、すべてを配列で返してください。

【道具の使い方】
1. まず search_past_inquiries で、照会元と件名の語が近い過去の照会を探してください。
2. 過去の記録が無いとき、または記録の担当課に断られた履歴があるときだけ、
   search_duties で事務分掌の条文を探してください。
3. 候補が決まったら get_section_contact で受付先を確認してください。
4. route_inquiry は、文書係の承認を求めるために呼んでください。
   否認された場合は、否認の理由を questions_for_clerk に書き、
   別の課で route_inquiry を呼び直さないでください。
同じ道具を同じ引数で2回呼ばないでください。

【厳守事項】
- 根拠の無い課を候補にしないでください。
  根拠は、過去の照会の識別子か、事務分掌の条文の番号で示してください。
- 断られた履歴がある課を主の候補にするときは、その理由を書いてください。
- 調査票の設問が複数の課の所掌にまたがる場合は、needs_coordination を true にし、
  取りまとめ役の課は決めないでください。
- 照会への回答の中身を書かないでください。
- 照会の種類が通知（回答不要）と読める場合は、その根拠の文字列を写してください。

【依頼のメールと添付】{inquiry}
【台帳で見つかった同じ文書番号の行】{duplicates}

「期限を日付に直さない」を書かないと、AIは親切に変換します。 「10月20日正午」を 2026-10-20 にし、時刻を落とします。「今月末」を月末の日付にします。変換そのものが合っていても、文字列が残らないと、文書係が読み違いを確かめられません。 変換は計算のノードの規則で行い、変換できなかったものを人に見せます。

「否認されたら別の課で呼び直さない」も大事です。 書かないと、否認された直後に2番目の候補で route_inquiry を呼び、文書係の承認待ちが同じ照会で何件も並びます。

出力形式を固定する

Require Specific Output Format を有効にし、Structured Output Parser をつなぎます。 次の形のJSONで受け取ります。

{
  "message_id": "",
  "issuer": "",
  "doc_no": "",
  "issued_date_text": "",
  "subject": "",
  "kind": "inquiry | opinion | notice_only | correction",
  "deadline_text": [ { "label": "", "text": "" } ],
  "submit_to": "",
  "form_name": "",
  "candidate_sections": [
    { "section": "", "role": "primary | related",
      "basis": [ { "type": "past_inquiry | duty_clause", "id": "", "quote": "" } ],
      "declined_before": false }
  ],
  "needs_coordination": false,
  "questions_for_clerk": [],
  "confidence": "high | low"
}

Structured Output Parser は、JSONの例から形を作る方法と、JSON Schema を書く方法から選べます。例から作ると、すべての項目が必須として扱われます。 通知（回答不要）では candidate_sections が空になるので、JSON Schema で書き、必須の項目を自分で決めます。 $ref による参照は使えないとされているので、入れ子はその場に展開します。

1つ目の理由は、期限の文字列と日付を別の層に置けることです。 deadline_text はAIが写し、日付は計算のノードが決めます。

曜日と日付が合わないものを「要確認」にしているのは、照会元の誤記が実際にあるからです。 どちらが正しいかは照会元に確かめるしかなく、AIにも計算にも決めさせません。

2つ目は、basis で文書係の確認が速くなることです。 候補の課ごとに、どの過去の照会、どの条文を根拠にしたかが並ぶので、台帳や規則を開き直さずに承認できます。

システムへ連携する

期限前の確認は、Send Email ノードの Send and Wait for Response で送ります。 メールを送って受け手の返事を待つ操作で、承認のボタン、自由記述、項目を決めたフォームの3つの返し方があります。ここではフォームにし、「回答済み」「作業中（期限までに出せる）」「期限の延長を照会元に相談したい」の3つから選ばせます。 待つ時間は、間隔か日時で区切れます。

注意点が1つあります。 Send Email（SMTP）ノードは In-Reply-To や References のヘッダーを設定できず、返信のスレッドとしてはつながりません。 担当課へ回すメールの件名に台帳の番号を入れ、スレッドの代わりにします。

人が確認する

1. 承認の依頼を見る … 文書係は、候補の課と basis を読み、承認するか、課を直して承認します
2. declined_before が true の候補を見る … 前に断られた課です。電話で確かめてから承認します
3. needs_coordination が true のものを企画政策課へ回す … 取りまとめ役の課を決めます
4. 「期限未確定」と「要確認」を見る … 照会元の問い合わせ先に確かめ、台帳の期限を人が入れます
5. 「期限の延長を相談したい」の返事を見る … 照会元への相談は、担当課が行うか文書係が行うかを決めます

承認の画面で見るのは、候補の課の名前より根拠のほうです。 根拠が前年度の同じ照会なら承認は速く、条文だけが根拠なら、その課に電話で確かめてから承認します。

目標は、1件をならして6分です。 前年度と同じ照会で根拠がはっきりしているものは承認だけで1分、取りまとめが要るものや断られた履歴があるものは、電話を含めて15分を超えます。

例外に対処する

1行目は、セキュリティの対策でもあります。 照会を装ったメールは、「担当課へ回す」という流れに乗った瞬間に、庁内の職員が開く添付になります。

記録を残す

• 受信したメールと添付の原本、受信日時
• エージェントの出力の全文と、Return Intermediate Steps で残した途中の過程
• 承認の結果（承認／課を直して承認／否認）と、直した課、承認した職員
• 期限の文字列と、計算のノードが決めた日付、「要確認」とした理由
• 期限前の確認の送信日時と、担当課の返事
• 担当課が回答した日と、照会元への提出の方法

3つ目が、翌年度の候補の質を決めます。 文書係が課を直した記録と、断られた記録が台帳に残り、search_past_inquiries の材料になります。直した記録が残らないと、エージェントは同じ誤りの候補を毎年出します。