他の自治体が公表する新しい施策・条例・計画をエージェントが毎月見回り、自分の市の重点課題と照らして参考になる事例を選び、概要と問い合わせ先の一覧を企画担当へ出す

処理の起点を決める

毎月1日と16日の朝7時に、Schedule Trigger で動かします。 題材は毎月の見回りですが、月に2回にするのは、月初に公表された事例を翌月まで知らないままにしないためです。 工数の試算は月の件数で数えているので、回数を増やしても件数は変わりません。

Schedule Trigger は、ワークフローのタイムゾーンが無ければインスタンスのタイムゾーンを使い、セルフホストの既定は America/New York とされています。ワークフローのタイムゾーンを Asia/Tokyo にします。Schedule Trigger を使うワークフローは、保存して公開する必要があるとされています。月単位の間隔では日付を1〜31で指定でき、その日が無い月には動かないとされているので、29日以降は指定しません。

見回りのページは、URLの一覧として Data table に持ちます。 列は自治体名、ページの種類（報道発表／新着情報／条例／計画・意見募集）、RSS の有無、見る見出しの CSS セレクター、比較の対象に選んだ理由です。追加も削除も、表を直すだけで済みます。 第3章の（a）は、この表で解きます。

入力データを集める

質を決めるのは、重点課題の表の「言い換えの語」です。 他の自治体は、同じ取り組みを違う言葉で呼びます。移住・定住は「関係人口」「二地域居住」「お試し移住」、空き家は「住宅ストック」「管理不全」と書かれます。言い換えの語が無いと、一次の仕分けで落とします。 最初は課の4人で、それぞれの分野で見かける言葉を出し合って作ります。

自分の市の事業の表は、第3章の（d）を解くために持ちます。 事業名だけでなく内容の要約を入れておくと、名前の違う同じ事業にエージェントが気づけます。予算書の事業名は短く、それだけでは中身が分からないので、事務事業の一覧の説明から要約を作ります。

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

リンクの比較は、リンク先のURLと見出しの文字の組で行います。 自治体のページでは、同じ資料が更新されるとURLはそのままで見出しの日付だけが変わることも、URLが変わって見出しはそのままのこともあります。どちらか片方が変わったものは「更新」として拾い、一覧では新しい公表と分けて示します。

ページは、決まったURLだけを月2回取ります。 サイト全体を巡回しません。HTTP Request の Batching の Batch Interval で、1件ずつ間を空けて取ります。 自治体のサイトは住民のためのもので、見回りの負荷をかけないことが前提です。

取得の失敗は、Response のオプションで扱います。 Include Response Headers and Status を有効にすると、本文だけでなくステータスコードも受け取れます。 404 や 503 は「本日取得なし」として記録し、前回の一覧を今回とみなしません。

AIへ渡す前に整形する

1. ページの共通部分を外す … メニュー、フッター、関連リンクは毎回同じなので、CSS セレクターで見る見出しの下だけに絞ります
2. 関係の無い種類を落とす … イベントの開催報告、職員の採用、入札の結果、選挙の告示など、見出しの決まった言葉で分かるものは規則で落とします
3. 一次の仕分けをする … 残った見出しと冒頭の文を生成AIに渡し、重点課題のどれに関わるか、関係が無いかだけを返させます
4. 同じ公表の重複を除く … 新着情報と報道発表の両方に同じものが出ることがあります。リンク先のURLで1つにまとめます
5. PDFの文字が取れるかを確かめる … 画像だけのPDFは文字が取れません。取れた文字数が少なければ「資料の中身は未確認」として人に回します

2番目と3番目は、落としたものの数を残します。 規則で落とした件数、一次の仕分けで「関係なし」とした件数と見出しを、実行ごとに記録します。関係のある事例を落としていないかは、この記録を月に1回、人が流し読みして確かめます。

AIに処理させる

させるのは、新しい公表1件ごとに、施策の中身と問い合わせ先を書かれたとおりに取り出し、重点課題と自分の市の事業に照らして関係と重なりを付けることです。

国の制度との関係は、本文に書かれた名前だけで記録させます。 「国の○○交付金を活用し」のように本文に制度の名前があれば、それを写します。書かれていなければ「記載なし」で、独自の施策だと決めつけません。 一覧では、制度の名前が同じ事例をまとめて1つの塊にし、塊の外にあるものを先に並べます。 第3章の（b）は、ここで解きます。

1行目がいちばん起きやすい失敗です。 報道発表の本文に担当課しか書かれていないと、生成AIはその自治体の代表電話や、よくある課の名前を補って書きます。補った電話番号に所管課が電話をかけると、相手の自治体の別の課の手を止めます。 書かれていなければ空欄にし、ページのURLを添えるだけにします。

指示内容を固定する

AI Agent ノードの System Message に、次のように書きます。

あなたは市の企画政策課で、他の自治体の新しい施策・条例・計画の公表を、
本市の総合計画の重点課題と照らす担当です。入力は、新しく見つかった
公表1件（自治体名、見出し、URL、一次の仕分けで付いた重点課題）です。

【やること】
1. 道具でページと添付の資料を取り、施策名、種類（条例／計画／事業／実証）、
   対象、内容、開始時期、予算を取り出す。
2. 本文に国・県の制度や交付金の名前があれば、そのまま写す。
3. 担当課、電話番号、メールアドレスを、本文に書かれたとおりに写す。
4. 重点課題の表を引き、関わる重点課題と、根拠にした本文の文を挙げる。
5. 本市の事業の表を引き、内容の近い事業があれば、どこが同じで
   どこが違うかを書く。
6. これまでの参考事例の表を引き、同じ制度・同じ施策の事例があれば挙げる。

【厳守事項】
- 施策名、対象、開始時期、予算、実績の数字は、本文と資料に書かれた
  文言をそのまま写してください。書かれていなければ「記載なし」です。
- 担当課・電話番号・メールアドレスは、本文に書かれていないとき空欄に
  してください。推測で補わないでください。contact_in_source を false に
  してください。
- 国・県の制度の名前は、本文に書かれているときだけ書いてください。
  書かれていないことを理由に「独自の施策」と書かないでください。
- 施策を「先進的」「効果が高い」などと評価しないでください。
- 本市に取り入れるべきかを書かないでください。本市の事業との重なりは、
  事実だけを書いてください。
- 重点課題に関わらないと判断したときは relevant を false にし、
  取り出しをしないでください。

【出力】指定のJSONの形で返してください。

「問い合わせ先を補わない」と「contact_in_source」を組にしているのが、この指示の要です。 補わないよう指示するだけだと、本文にあった連絡先と、補った連絡先の区別が出力から消えます。 本文にあったかどうかを項目として持たせれば、後段の規則でfalse の事例は一覧で「問い合わせ先は元のページで確認」と表示する、と決められます。

「書かれていないことを理由に独自と書かない」も同じ考えです。 制度の名前が本文に無いのは、書いていないだけのことが多くあります。独自かどうかの見立ては、企画担当が資料と問い合わせで確かめます。

出力形式を固定する

Structured Output Parser で、次の形のJSONを返させます。

{
  "municipality": "",
  "source_url": "",
  "title": "",
  "relevant": true,
  "measure": {
    "name": "", "type": "ordinance | plan | project | pilot",
    "target": "", "summary_quote": "",
    "start": "", "budget": ""
  },
  "national_scheme": { "name_in_source": "", "in_source": false },
  "contact": { "section": "", "tel": "", "email": "", "contact_in_source": true },
  "priority_issues": [ { "issue": "", "evidence_quote": "" } ],
  "own_overlap": [ { "project": "", "department": "", "same": "", "different": "" } ],
  "past_cases": [ { "municipality": "", "name": "", "date": "" } ],
  "unverified": [""]
}

1つ目の理由は、national_scheme で一覧の並べ方を変えられることです。 制度の名前が同じ事例は1つの塊にまとめ、件数と自治体名だけを見せます。塊の外にある事例、つまり制度の名前の無い事例と、制度に乗りながら対象や中身が他と違う事例を先に並べます。

2つ目は、own_overlap で紹介の前に重なりが見えることです。 自分の市の事業と重なる事例は、所管課へ回す前に「本市の○○事業と対象が同じで、違うのは申請の方法」と書き添えられます。 第3章の（d）は、ここで解けます。

3つ目は、contact_in_source で補った連絡先を締め出せることです。

5行目も消さずに残します。 「関係なし」も、見回りをした記録だからです。

システムへ連携する

参考事例の表への書き込みは、ワークフローの側で行います。 エージェントの道具には、重点課題・本市の事業・これまでの参考事例を引くための読み取りだけを渡します。エージェントが表を書き換える経路を作りません。

生成AIのノードは Anthropic Chat Model ノードを使います。 Claude のモデルを会話型のエージェントで使うためのノードとされ、最大トークン数やサンプリングの温度を設定できます。取り出しの段では温度を低くし、同じ公表から同じ取り出しが返るようにします。

人が確認する

1. 並べ順の1と2を読む … 重点課題ごとに、新しい事例の取り出しと根拠の文を読みます。ここが企画担当の仕事の中心です
2. 元のページを開く … 参考にしそうな事例は、取り出しと元のページを見比べます
3. 本市の事業との重なりを確かめる … own_overlap がある事例は、所管課に回す前に重なりの書き方を確かめます
4. 参考にするかを決める … 参考事例の表に、判断（所管課へ回す／課内の記録に留める／対象外）と理由を残します
5. 所管課へ回す … 問い合わせ先は、contact_in_source が false なら元のページで確かめてから伝えます
6. 振り落とした見出しを流し読む … 月に1回、並べ順の5を見ます

4番目の判断の記録は、次の見回りで生きます。 「対象外」と判断した理由が残っていれば、同じ制度の事例が別の自治体から出たときに、エージェントがこれまでの事例として引きます。

目標は、1件をならして12分です。 取り出しと根拠の確認に6分、参考にするかの判断に4分、一覧の確認と回付に2分という見込みです。

例外に対処する

上から2行目は、自治体のサイトの改修のときに起きます。 改修は年度の替わり目に多く、メニューや見出しの作りが変わると、すべてのリンクが新しく見えます。件数の上限を決めておき、超えたら止めるのが、同じ話を数百件並べないための仕組みです。

記録を残す

• 実行ごとの、ページの取得の成否とステータスコード
• 新しく拾った公表と、規則で落とした件数、一次の仕分けで関係なしとした見出し
• エージェントのJSON出力と、呼んだ道具の順番（Return Intermediate Steps）
• 企画担当の判断 … 事例ごとの判断と理由、所管課へ回した日
• 所管課からの反応（問い合わせた、事業の検討に入った、など）

3つ目の道具の順番は、Tools Agent の Return Intermediate Steps を有効にして残します。 エージェントが取った中間の手順を最終の出力に含めるかを選べるとされ、本市の事業の表を引かずに「重なりなし」と書いていないかを後から確かめられます。