Media > AI活用ユースケース > 総務 > 市役所の広聴担当が住民から届く「市長への手紙」を Claude で論点ごとに分類し、担当課への振り分けと回答の下書きを作る

市役所の広聴担当が住民から届く「市長への手紙」を Claude で論点ごとに分類し、担当課への振り分けと回答の下書きを作る

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

住民から届く「市長への手紙」を、個人を特定する情報を伏せてから Claude に読ませ、論点ごとに回答の型と担当課の候補を付けます。担当課への照会文と、担当課が事実を書き入れる回答の下書きの枠も作り、広聴の担当者が確かめて照会に回します。

サマリー
生成AI
ChatGPT/Claude/Microsoft Copilot
対象業界
自治体
対象部門
総務
対象業務
分類・仕分け/問い合わせ対応
主な課題
問い合わせが多い/属人化している/書類作成に時間がかかる
AIで行う処理
分類
主な効果
品質標準化/対応スピード向上/工数削減
導入難易度
★★☆☆☆
実装レベル
半自動化
費用感
SaaS追加(小)
人間の確認
条件付き
現在工数
100h/月
AI導入後
40h/月
想定削減
60%
年間削減
720h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 届いた手紙を受付台帳に載せる。紙のものは文字に起こす
  2. 広聴の担当者が全文を読み、何について書かれているかを書き出す
  3. 論点ごとに、市の所管か、国・県・警察・民間の所管か、回答を控えるべきものかを考える
  4. 市の所管のものは、組織の事務分掌を見て担当課を決める。迷うものは課に電話で聞く
  5. 担当課ごとに照会文を書き、手紙の写しを添えて庁内のメールで送る
  6. 所管外のものは、案内先を調べて回答の文に書く
  7. 担当課から回答案が届いたら、言葉づかいと形をそろえ、論点ごとの回答を1通にまとめる
  8. 決裁を受けて回答を送り、台帳に回答日を入れる
導入後(After)
  1. 人届いた手紙を受付台帳に載せる。紙のものは文字に起こす
  2. 人本文の氏名・住所・電話番号・メールアドレスを記号に置き換えた写しを作る
  3. 人Claude の「市長への手紙」プロジェクトを開き、伏せた写しと受付番号を貼る
  4. 自動Claude が手紙を論点に分け、論点ごとに回答の型と担当課の候補を付ける
  5. 自動型が「市が回答」の論点は、担当課への照会文の案を作る
  6. 自動型が「所管外の案内」の論点は、プロジェクトの案内先の一覧から案内の文の案を作る
  7. 自動論点を並べた回答の下書きの枠を作る。担当課が書き入れる欄は空欄にする
  8. 人広聴の担当者が、論点の切り方、型、課の候補を確かめて直し、照会を出す
  9. 人担当課が枠の空欄に現状と今後の対応を書き入れて返す
  10. 人広聴の担当者が全体を読み、決裁に回して回答を送る
各工程の詳しい説明を読む
  1. 届いた手紙を受付台帳に載せる。紙のものは文字に起こす
  2. 広聴の担当者が全文を読み、何について書かれているかを書き出す
  3. 論点ごとに、市の所管か、国・県・警察・民間の所管か、回答を控えるべきものかを考える
  4. 市の所管のものは、組織の事務分掌を見て担当課を決める。迷うものは課に電話で聞く
  5. 担当課ごとに照会文を書き、手紙の写しを添えて庁内のメールで送る
  6. 所管外のものは、案内先を調べて回答の文に書く
  7. 担当課から回答案が届いたら、言葉づかいと形をそろえ、論点ごとの回答を1通にまとめる
  8. 決裁を受けて回答を送り、台帳に回答日を入れる

(a)論点の書き出しが担当者の読みに頼っている。 便箋数枚の手紙から論点を拾うのは、慣れた担当者でも数分かかります。怒りの強い手紙ほど、論点が感情の言葉の中に埋もれています。 2つ目、3つ目の論点を拾い損ねると、その論点は照会されないまま回答が出ます。

(b)回答の型の見分けに迷う。 「県道の穴」は県の所管、「信号機の設置」は警察の所管、「隣の家の木」は民事の事柄です。市が回答する形で書くと、市ができないことを約束したように読まれます。 逆に、市の所管なのに「県へお問い合わせください」と書けば、たらい回しと受け取られます。この見分けは、経験の長い担当者の頭の中にしかありません。

(c)照会文と回答の形を毎回書いている。 照会文は「別添の手紙のうち、○○について、現状と今後の対応をご回答ください」という形がほぼ決まっていますが、論点の言い直しと期限の書き入れを毎回手で行っています。 回答の形も、あいさつと結びは決まっているのに、担当者ごとに少しずつ違います。

(d)担当課の回答案をそろえ直す手間が大きい。 課によって「です・ます」と「である」が混ざり、専門用語がそのまま入っています。広聴の担当者が、論点の順に並べ直し、住民に分かる言葉に直しています。

  1. 【人】 届いた手紙を受付台帳に載せる。紙のものは文字に起こす
  2. 【人】 本文の氏名・住所・電話番号・メールアドレスを記号に置き換えた写しを作る
  3. 【人】 Claude の「市長への手紙」プロジェクトを開き、伏せた写しと受付番号を貼る
  4. 【自動】 Claude が手紙を論点に分け、論点ごとに回答の型と担当課の候補を付ける
  5. 【自動】 型が「市が回答」の論点は、担当課への照会文の案を作る
  6. 【自動】 型が「所管外の案内」の論点は、プロジェクトの案内先の一覧から案内の文の案を作る
  7. 【自動】 論点を並べた回答の下書きの枠を作る。担当課が書き入れる欄は空欄にする
  8. 【人】 広聴の担当者が、論点の切り方、型、課の候補を確かめて直し、照会を出す
  9. 【人】 担当課が枠の空欄に現状と今後の対応を書き入れて返す
  10. 【人】 広聴の担当者が全体を読み、決裁に回して回答を送る

8番目が、この設計の分かれ目です。 広聴の担当者は、AIが切り分けた論点に抜けがないかを、原文と見比べて確かめます。 型と課の候補は、そのあとで見ます。論点が1つ抜けていれば、その論点はどの課にも照会されないからです。

9番目で担当課に渡すのを「回答案」ではなく「枠」にしているのも、意図してのことです。 枠には論点の言い直しと、あいさつ・結びが入っていて、担当課は空欄に事実を書くだけになります。 課ごとに書き方が違う問題(第3章の(d))が、枠の側で揃います。

02今回想定するシステム構成

構成図
市長への手紙(Web フォーム・メール・手紙)
   │  紙は文字に起こし、受付台帳に載せる
   ▼【トリガー】受付台帳への登録
広聴の担当者 ── 氏名・住所・連絡先を記号に置き換えた写しを作る
   ▼
Claude(Team プランの「市長への手紙」プロジェクト)
   │   指示:論点の切り方、回答の型、禁止事項
   │   知識:事務分掌の一覧、所管外の案内先の一覧、回答の決まった形
   │   ① 論点の一覧   ② 論点ごとの回答の型と担当課の候補
   │   ③ 照会文の案   ④ 回答の下書きの枠
   ▼
【広聴の担当者が論点・型・課を確かめる】
   ▼
庁内のメールで担当課へ照会 → 担当課が枠に記入
   ▼
広聴の担当者が整え、決裁 → 回答を送付、台帳に記録
役割想定する製品代替候補
処理Claude(Team プランのプロジェクト。指示と知識を広聴担当で共有)ChatGPT(業務用ワークスペース)、Microsoft Copilot
受付の台帳既存の受付台帳(表計算)-
照会の経路庁内のメール-

受付台帳と庁内のメールは、新しく足すものではありません。 この構成から台帳や担当課へ自動で書き込むことはせず、照会を出すのも、台帳に記録するのも広聴の担当者です。 新しく足すのは、業務用の Claude の契約と、プロジェクトに置く3つの一覧だけです。

Claude のプロジェクトを使うのは、指示と知識を担当者の間で共有できるからです。 公式のヘルプでは、プロジェクトは独自のチャット履歴と知識を持つ作業場所で、文書などを知識として加え、応答の書き方を決める指示を置けるとされています。Team と Enterprise のプランでは、プロジェクトをメンバーと共有でき、 「閲覧可」と「編集可」の権限があります。事務分掌の一覧と指示を書き換えられるのを広聴の係長だけにし、 ほかの担当者は閲覧可で使う形にできます。

知識が多くなっても扱えます。 公式のヘルプでは、有料のプランでは知識が大きくなると検索拡張生成(RAG。質問に関係する部分を探してから答える仕組み)に切り替わり、容量を最大10倍に広げるとされています。事務分掌の一覧は60課分になり、案内先の一覧も増えていくので、 この点は運用の途中で効いてきます。

03どうやって実装するのか

Step1

処理の起点を決める

受付台帳に1通を登録したところを起点にします。 広聴の担当者が台帳に受付番号を振ったら、その手紙をプロジェクトで処理します。まとめて夕方に処理する形にはしません。 回答の期限は受付日から数えるので、照会が1日遅れれば担当課の持ち時間が1日減ります。

1通ごとに新しいチャットを開きます。 同じチャットで続けて処理すると、前の手紙の論点や課が次の手紙の分類に混ざります。チャットの名前は受付番号にし、後でどの手紙をどう分類したかをたどれるようにします。

紙の手紙は、文字に起こしたところで台帳に載せます。文字に起こす前の画像をプロジェクトに貼ることはしません。 画像には氏名と住所が書かれており、伏せる手順を通らずに外へ出るからです。

Step2

入力データを集める

データ中身取得元
手紙の本文(伏せた写し)氏名・住所・電話番号・メールアドレスを記号にした本文受付台帳から担当者が作る
受付番号と受付日台帳の番号と日付受付台帳
事務分掌の一覧課ごとに、受け持つ事業・施設・制度の名前と、よく来る言い回しプロジェクトの知識
所管外の案内先の一覧国・県・警察・民間の窓口と、市が案内するときの決まった言い方プロジェクトの知識
回答の決まった形あいさつ、結び、型ごとの言い回し、使わない言葉プロジェクトの知識

質を決めるのは、事務分掌の一覧です。 市の正式な事務分掌は「道路の維持管理に関すること」のような書き方で、住民の言葉の「家の前の側溝のふたががたがたする」とは結びつきません。 そこで、課ごとに「よく来る言い回し」の欄を足します。過去1年の手紙と照会先の組から、課ごとに10〜20の言い回しを拾って書き足すのが最初の準備作業です。

案内先の一覧は、迷いやすいものから作ります。 県道と市道、信号機と道路標示、河川の管理者、国の制度の窓口、消費生活の相談先など、広聴の担当者が過去に課や県に電話で確かめたものを、確かめた結果のまま一覧にします。

Step3

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

本文の取り出しは、広聴の担当者がいまと同じく受付台帳から行います。API もワークフローも組みません。 台帳から本文を写し、伏せる手順を通してから、プロジェクトのチャットに貼ります。

取るものどこから何に使うか
本文受付台帳(Web フォーム・メールはそのまま、紙は文字に起こしたもの)論点の切り分けと分類
回答の希望の有無フォームの選択欄、手紙の記載回答の枠を作るかどうか
同じ人の過去の受付受付台帳の検索(担当者が行う)繰り返しの手紙かの確認
事務分掌と案内先プロジェクトの知識型と課の候補

同じ人の過去の受付は、プロジェクトに渡しません。 台帳を氏名で引くのは担当者が行い、「同じ趣旨の手紙に前回回答済み」の場合だけ、そのことを1行で書き添えます。 個人の受付の履歴を外へ出さないためです。

回答の希望は、本文より先に確かめます。 匿名の手紙や「回答は要りません」と書かれたものは、回答の枠を作らず、論点と課の候補だけを出して担当課への情報提供に回します。

Step4

AIへ渡す前に整形する

  1. 個人を特定する情報を伏せる … 氏名は【差出人】、住所は【住所】、電話番号とメールアドレスは【連絡先】に置き換えます。本文中の家族や近所の人の名前も【人名1】【人名2】に置き換えます
  2. 場所の書き方を残す … 「○○町3丁目の交差点」のような場所は、論点の所管を決める手がかりなので伏せません。 ただし、番地まで書かれたものは丁目までにします
  3. 職員の名前を伏せる … 苦情の中の職員の名前は【職員】にします。職員個人への評価をAIの出力に残さないためです
  4. 同じ手紙の重複を除く … フォームとメールで同じ文が二度届いたものは、台帳で1件にまとめます
  5. 回答の希望と前回の回答の有無を書き添える … 本文の前に「回答希望:あり」「同趣旨の前回回答:あり(受付番号)」を書きます

1番目と3番目を、担当者の目で行う前処理にしています。 置き換えの漏れを機械で見つけるのは難しく、とくに本文の途中に出てくる家族や近所の人の名前は、読まないと拾えません。 1通につき1分ほどかかりますが、ここを省くと構成そのものが成り立ちません。

2番目の「場所を残す」は、伏せすぎの失敗を防ぐためです。 場所を全部伏せると、県道か市道か、どの公園かが分からず、型の分類がほとんど「判断できない」になります。

Step5

AIに処理させる

させるのは、手紙を論点に分け、論点ごとに回答の型と担当課の候補を付け、照会文と回答の枠を書くことだけです。

見るもの分類の仕方判断できないときの扱い
論点の数対応する課や窓口が違えば別の論点にする1つか2つか迷えば分けておく
回答の型city_reply(市が回答)/refer_outside(所管外を案内)/info_only(回答不要・情報提供のみ)/withhold(回答を控える候補)決まらなければ needs_review
担当課の候補事務分掌の一覧にある課の名前だけから選ぶ。最大2つ一覧で決まらなければ候補なし
案内先案内先の一覧にある窓口だけから選ぶ一覧に無ければ案内先なし
急ぎの手がかり危険・けが・命に関わる言葉迷えば立てる

withhold は「回答を控える候補」であって、控える決定ではありません。 裁判や審査請求で市と争っている事柄、特定の職員や個人への批判、選挙に関わる事柄などで、どう扱うかは広聴の係長と担当課が決めます。 AIはその候補に印を付けるだけです。

課の候補を一覧の中からだけ選ばせるのは、存在しない課を作らせないためです。 「交通安全推進課」のような、いかにもありそうな課の名前は、指示が無ければ平気で出てきます。一覧に無い課を書いた論点は、課の候補なしとして扱います。

させないこと理由
回答の中身(市の方針・事実・今後の予定)を書く書けるのは担当課だけ。枠の空欄にする
回答を控えるかの決定広聴の係長と担当課が決める
差出人の意図や人柄の推測回答の文に入ると、住民への評価になる
職員個人への評価苦情の事実だけを論点にする
期限の日付の計算受付台帳の数式で出す

1行目がいちばん起きやすい失敗です。 「歩道を広げてほしい」という論点に、AIは「現在、整備計画の中で検討を進めております」と書きたがります。その一文は、担当課が書けば回答、AIが書けば約束の捏造です。

Step6

指示内容を固定する

プロジェクトの指示に、次の文を置きます。

あなたは市役所の広聴担当として、住民から届いた「市長への手紙」を整理する立場です。
貼り付けられた手紙と、このプロジェクトの知識(事務分掌の一覧、所管外の案内先の一覧、
回答の決まった形)だけを使ってください。

【手順】
1. 手紙を論点に分けてください。対応する課や窓口が違う事柄は、別の論点にします。
   1つか2つか迷ったときは分けてください。論点ごとに、該当する本文をそのまま引用してください。
2. 論点ごとに回答の型を1つ選んでください。
   - city_reply ...... 市の事業・施設・制度についての要望・意見・質問
   - refer_outside ... 国・県・警察・民間など、市以外が所管する事柄
   - info_only ....... 回答希望が「なし」または匿名で、担当課への情報提供にとどめるもの
   - withhold ........ 裁判・審査請求で争っている事柄、特定の個人への批判、選挙に関わる事柄
   - needs_review .... 上のどれか決められないもの
3. city_reply の論点には、事務分掌の一覧にある課の名前だけから担当課の候補を最大2つ挙げてください。
   refer_outside の論点には、案内先の一覧にある窓口だけを挙げてください。
4. city_reply の論点ごとに、担当課への照会文の案を書いてください。
5. 回答希望が「あり」の場合は、回答の下書きの枠を書いてください。

【厳守事項】
- 市の方針、事実、今後の予定、検討の状況を書かないでください。
  担当課が書く部分は「【担当課記入:現状と今後の対応】」のように空欄にしてください。
- 一覧に無い課の名前や窓口を書かないでください。決まらなければ「候補なし」としてください。
- 差出人の気持ちや人柄を推し量る言葉を書かないでください。
- 職員についての苦情は、起きた事実だけを論点にし、職員への評価を書かないでください。
- 【差出人】【住所】【人名1】などの記号を、元の名前に戻そうとしないでください。
- 日付を計算しないでください。
- 危険・けが・命に関わる言葉があれば、論点とは別に「急ぎの手がかり」として挙げてください。

【出力の形】
はじめに論点の一覧を JSON で、続けて照会文の案、最後に回答の下書きの枠を書いてください。

「担当課が書く部分は空欄にする」を明記しないと、枠ではなく完成した回答が出ます。 しかも、それらしい回答ほど広聴の担当者が直さずに担当課へ回しがちで、担当課が空欄を埋める代わりにAIの文を承認するだけの流れができてしまいます。

「論点ごとに本文を引用する」も同じ理由です。 引用があれば、広聴の担当者は原文と見比べるだけで、論点の切り方が正しいかと、抜けた論点がないかを確かめられます。

Step7

出力形式を固定する

論点の一覧は、次の形の JSON で受け取ります。

{
  "receipt_no": "",
  "reply_requested": true,
  "issues": [
    {
      "issue_no": 1,
      "summary": "",
      "quote": "",
      "reply_type": "city_reply | refer_outside | info_only | withhold | needs_review",
      "departments": ["", ""],
      "outside_contact": "",
      "reason": ""
    }
  ],
  "urgent_signals": [""],
  "uncovered_text": ""
}

1つ目の理由は、受付台帳に論点ごとの行を作れることです。 担当者は JSON の issues を台帳の別表に貼り、論点ごとに照会先と回答の状態を管理します。 1通に1行の台帳では、3つの論点のうち1つの回答が遅れていることが見えません。

2つ目は、uncovered_text で抜けを見つけやすくすることです。 どの論点にも引用されなかった本文をここに書かせ、そこに論点が隠れていないかを担当者が読みます。 あいさつや前置きだけなら空のままで、空でなければ見る、という形にします。

3つ目は、reply_type で回答の枠の形が決まることです。 型ごとに、回答の下書きに入る文の形を決めておきます。

reply_type回答の下書きでの扱い照会
city_reply論点の言い直し+【担当課記入】の欄担当課へ照会
refer_outside案内先の一覧の決まった言い方で案内照会しない。案内先の確認だけ
info_only回答の枠を作らない担当課へ情報提供
withhold枠に入れない係長と担当課で相談
needs_review枠に入れない広聴の担当者が決める

照会文の案は、論点ごとに次の形で出します。 「受付番号○○の手紙のうち、論点○(引用:…)について、現状と今後の対応を【担当課記入】欄にご記入のうえ、【期限】までにご返送ください。」期限の日付はAIに書かせず、台帳の数式で出した日付を担当者が入れます。

Step8

システムへ連携する

つなぎ先方式内容
受付台帳担当者がコピーして貼る本文を取り出し、論点の一覧を別表に貼る
Claude のプロジェクト画面での操作論点・型・課の候補、照会文、回答の枠
庁内のメール担当者が送る照会文と回答の枠を担当課へ送る
文書管理システム既存の決裁の経路回答の決裁

この構成は、どのシステムにも自動で書き込みません。 照会を出すのも、台帳を更新するのも、決裁に回すのも広聴の担当者です。システムをつながないので、庁内の情報システムの調達や改修が要りません。

担当課に送るのは、伏せる前の手紙の写しです。 担当課は差出人の住所が分からないと現地を確かめられないことがあるため、庁内の照会には、いまと同じく元の手紙を添えます。 伏せた写しはプロジェクトに貼るためだけに作ります。

Step9

人が確認する

広聴の担当者は、次の順で確かめます。

  1. 論点の抜けを見る … 原文と論点の引用を見比べ、uncovered_text を読みます。抜けていれば論点を足します
  2. 型を確かめる … とくに refer_outside と withhold を確かめます。所管外の案内は、市ができることを本当に含んでいないかを見ます
  3. 課の候補を決める … 候補が2つあるものは、事務分掌で決めます。候補なしは、これまでどおり課に聞きます
  4. 照会文と枠を直して送る … 期限の日付を入れ、照会を出します
  5. 直したことを記録する … 論点を足した、型を変えた、課を変えたことを台帳に残します

2番目の refer_outside の確認を省かないでください。 「県道の歩道」は県の所管でも、その道に面した市の施設の出入口の改善は市の所管、ということがあります。 所管外として案内するだけで終えると、市が受け持つ部分まで返してしまいます。

目標は、1通をならして8分です。 論点が1つで型も課も迷わない手紙は数分で照会に回り、論点が多い手紙や needs_review のある手紙に時間を使います。

Step10

例外に対処する

起きること対応
命や安全に関わる言葉がある処理の順番を待たず、その場で係長と担当課に電話する
論点が1つも切り出せない(意見の表明だけ)info_only として担当課へ情報提供。回答希望があれば受け止めの回答にする
課の候補が一覧に無い候補なしとして、これまでどおり課に聞く。聞いた結果を一覧に足す
案内先が一覧に無い案内先なしとして担当者が調べる。確かめた結果を一覧に足す
同じ人から同じ趣旨の手紙が続く前回の回答を添えて係長と相談。新しい論点が無いかだけを分類で見る
手紙が外国語で書かれている翻訳は別の手順で行い、訳文を伏せてから貼る
差出人の個人情報が本文に残ったまま貼られたそのチャットを削除し、伏せ直して貼り直す。台帳に記録する
子どもからの手紙回答の言葉づかいを分けるため、本文の前に「差出人は子ども」と書き添える

最初の行は、AIの手前で止める例外です。 「死にたい」「倒れそうな塀」のような言葉は、AIの出力を待つ前に、受付の時点で人が気づいて動くものとして決めておきます。AIの urgent_signals は、その見落としを拾う2つ目の網にすぎません。

7行目のチャットの削除について、 公式のプライバシーの案内では、削除した会話はチャットの履歴からすぐに消え、バックエンドの保存からは30日以内に削除されるとされています。貼ってしまった事実は消えないので、記録に残します。

Step11

記録を残す

  • 受付番号、受付日、届いた経路、回答の希望の有無
  • プロジェクトのチャット(名前は受付番号)
  • 論点の一覧の JSON と、担当者が直した後の論点の一覧
  • 論点ごとの照会先、照会日、担当課からの返送日
  • 回答の文、決裁の日付、送付の日付
  • 個人情報を伏せずに貼ってしまった記録
  • プロジェクトの知識(事務分掌・案内先・回答の形)を書き換えた日と内容

3つ目で直した後の一覧を残すのは、知識の一覧を育てるためです。 AIが外した課と、担当者が正した課の組を毎月集め、事務分掌の一覧の「よく来る言い回し」に足します。 これを続けると、候補なしの論点が月ごとに減っていきます。

最後の行は、ある時点の分類がどの一覧で行われたかをたどるためです。 一覧を書き換えると同じ手紙の分類が変わるので、照会先の誤りがあったとき、一覧の誤りかAIの誤りかを分けられます。

04実装レベルの3段階

最小構成:手紙を伏せて Claude のチャットに貼り、論点と型・課の候補を出させる / 論点の切り分けと分類
半自動化:上記+プロジェクトに事務分掌・案内先・回答の形を置き、照会文と回答の枠まで出させ、論点ごとに台帳で管理する / 分類・照会文・回答の枠
本格構成:上記+受付フォームから Claude API へ自動で送り、論点の一覧を台帳に自動で書き込み、照会の期限を知らせる / 受付から照会の準備まで

最小構成では、照会文と回答の枠は手で書きます。 分類が使えるかを確かめる段階です。 半自動化で、1通20分が8分になり、この段階が本記事の想定です。 論点の書き出し、型と課の見分け、照会文と回答の形を書く作業が、確かめて直す作業に変わります。残る8分の大半は、個人情報を伏せる1分と、論点の抜けと型を確かめる時間です。 本格構成に進むかは、個人情報の扱いで決まります。 自動で送る形にすると、伏せる手順も機械で行うことになり、本文の途中の人名を拾いきれるかが問題になります。 半自動化の運用で、伏せ漏れがどれくらい出るかを数か月見てから決めてください。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
3 名
月間件数
300 件
1件あたり現在時間
20 分
1件あたり導入後時間
8 分
現在  300件 × 20分 ÷ 60 = 100 時間/月
導入後 300件 × 8分 ÷ 60 = 40 時間/月
月間削減時間
60h
削減率
60%
年間削減時間
720h
年間金額換算(時間単価3,000円)
216万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 人口10万〜30万人ほどの市・区で、「市長への手紙」や意見メールが月に数百通届き、広聴の担当者が読み分けて担当課へ照会し、回答の文案を整えている場合。1通に複数の論点が書かれていることが多く、照会先を分けるのに時間がかかっている場合。回答の書き方が担当者ごとにばらつき、市の所管でない事柄への案内の仕方が決まっていない場合。業務用の Claude(Team または Enterprise)を契約できる場合。
向いていない
  1. 手紙が月に数十通で、広聴の担当者が読んで足りる場合。住民の個人情報を含む文書を外部の生成AIのサービスで扱うことを、市の個人情報の取扱いの決まりで認めていない場合。手紙の大半が紙の手書きで、文字に起こす手段が無い場合。なお、回答の内容(市の方針・事実・今後の対応)の決定、回答するかどうかの最終判断、公表するかどうかの判断は、この構成では代替できません。

07最小構成で試す方法

  1. 先月届いた手紙から30通を選ぶ(論点が3つ以上あるものと、所管外の事柄を含むものを数通ずつ入れる)
  2. 30通の氏名・住所・連絡先を記号に置き換える
  3. 業務用の Claude で新しいプロジェクトを作り、第7章の指示を置き、事務分掌の一覧を知識に入れる
  4. 1通ずつ新しいチャットで貼り、論点の一覧と型・課の候補を出させる
  5. 当時の照会先と回答と突き合わせる

30通は必ずやってください。 照会の流れを変える前に、「論点の切り方と型の見分けが、広聴の担当者の読みと同じになるか」を確かめます。 回答の枠は、この段階では作らなくて構いません。

出てきた内容判断
当時と同じ論点と照会先が出た照会文と回答の枠まで広げる
論点の数が当時より多い細かく分けすぎか、当時の見落としか。原文で見比べる
課の候補が「候補なし」ばかり事務分掌の一覧の言い回しが足りない。一覧を先に育てる

2行目は、当時の見落としであることが少なくありません。 その場合、これまで照会されずに回答が出ていた論点があったということです。 失敗ではなく、この構成で減らしたかったものが見えたということです。

08実装時につまずきやすいポイント

問題対策
1通に1つの課しか付かず、論点が漏れる論点に分けてから分類する。 迷えば分けるよう指示する
回答の中身をAIが書く「市の方針・事実・今後の予定を書かない」と明記し、空欄の枠にする
存在しない課の名前が出る事務分掌の一覧の中からだけ選ばせ、一覧に無い課は候補なしにする
所管外として市の受け持ち部分まで返すrefer_outside を必ず人が見る。市の施設や事業に関わる部分が無いかを確かめる
個人を特定する情報が残ったまま貼られる伏せる手順を決め、貼る前に読み返す。貼ってしまったら削除して記録する
場所まで伏せて所管が決まらない場所は丁目までは残す
前の手紙の内容が次の分類に混ざる1通ごとに新しいチャットを開く
候補なしが多い事務分掌の一覧の言い回しを足す。担当者が正した課を毎月足す
職員への苦情に評価の言葉が入る事実だけを論点にし、職員の名前は伏せる
期限の日付を間違える日付はAIに書かせず、台帳の数式で出す
回答を控えるかをAIが決めたように扱うwithhold は候補。係長と担当課が決める

上の2行が、この構成の失敗のほとんどです。 どちらも、AIに任せる範囲を「分けて分類する」から広げたところで起きます。 論点を分けずに分類すれば抜けが出て、回答を書かせれば約束の捏造が出ます。

5行目は、運用を始めてから効いてきます。 慣れてくると伏せる作業が雑になり、本文の途中の家族の名前が残ったまま貼られます。 月に一度、チャットを抜き取りで見る時間を係長が取ってください。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 住民の氏名・住所・連絡先、手紙に書かれた生活や家族、近所の人のこと、ときには健康や家庭の事情です。市が持つ個人情報のなかでも、本人が市長あてに書いた私的な内容を含みます。

  1. 伏せた写しだけを貼る … 個人情報保護委員会の注意喚起では、行政機関等が生成AIサービスに個人情報を含むプロンプトを入力する場合には、特定された利用目的のための必要最小限の利用又は提供であることを十分に確認することとされています。分類に要らない氏名・住所・連絡先は、貼る前に伏せます
  2. 機械学習に使われないことを確かめる … 同じ注意喚起では、保有個人情報が応答結果の出力以外の目的で扱われる場合に法の規定に違反する可能性があり、提供事業者が機械学習に利用しないこと等を十分に確認することとされています。公式のプライバシーの案内では、Claude for Work などの商用の製品の入力と出力は、既定ではモデルの学習に使わないとされています
  3. フィードバックの送信を止める … 同じ案内では、評価のボタンで送ったフィードバックは関連する会話全体とともに最長5年保存され、学習に使われうるとされています。Team と Enterprise の管理者は、組織の設定でフィードバックの送信を止められます。 最初に止めます
  4. 回答の中身をAIに書かせない … 市の方針や事実をAIが書いた回答が出れば、市が言っていないことを市長の名前で約束したことになります
  5. 回答を控えるかを人が決める … 裁判や審査請求で争っている事柄への回答は、市の立場に直接ひびきます。 係長と担当課が決めます
  6. 子どもからの手紙を分けて扱う … 子どもからの手紙は、伏せる手順と回答の言葉づかいを分けます。プロジェクトの利用者は広聴の職員に限り、子どもが直接使う仕組みにはしません

誤りが起きた場合のリスクは、論点を落として照会しないことと、所管の見分けを誤って市の受け持ちを返すことの2つです。 どちらも住民からは「市が聞いてくれなかった」と見えます。論点の引用と uncovered_text、refer_outside の確認を人が必ず行う設計にしているのは、この2つを防ぐためです。

10まず何から始めるか

1週目:事務分掌の一覧に言い回しを足す

過去1年の受付台帳から、論点と照会先の組を拾い、課ごとに住民の言い回しを10〜20個書き足します。 照会の多い上位20課から始めます。この20課で照会の大半が埋まります。

2週目:所管外の案内先の一覧と、伏せる手順を決める

過去に課や県に電話で確かめた所管外の事柄を一覧にします。あわせて、氏名・住所・連絡先・本文中の人名・職員の名前を伏せる手順を1枚にまとめ、 3名が同じ形で行えるようにします。

3週目:30通で試す

先月の手紙から30通を選び、プロジェクトで論点と型・課の候補を出させます。当時の照会先と見比べ、論点の抜けと所管外の見分けを最優先で見ます。

4週目:照会文と回答の枠まで出す

回答の決まった形をプロジェクトに置き、照会文と回答の枠を出させます。新しく届く手紙で、いまのやり方と並行して使い、担当課に枠の書き入れ方を説明します。

2か月目: 論点ごとに台帳で管理する別表を作り、照会の状態を論点の単位で追います。3か月目以降: 1通20分が何分になったかを実測し、担当者が直した課を毎月一覧に足します。候補なしの論点が月に数件まで減り、担当課からの回答が枠の形で揃って返ってくるようになった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-15/最終更新:2026-10-23
確認した内容情報源確認日
行政機関等(地方公共団体の機関を含む)が生成AIサービスに個人情報を含むプロンプトを入力する場合には、特定された利用目的のための必要最小限の利用又は提供であることを十分に確認すること。保有個人情報が応答結果の出力以外の目的で取り扱われる場合に個人情報保護法の規定に違反する可能性があり、提供事業者が機械学習に利用しないこと等を十分に確認すること個人情報保護委員会: 生成AIサービスの利用に関する注意喚起等について(令和5年6月2日)2026-10-15
プロジェクトが独自のチャット履歴と知識を持つ作業場所で、文書などを知識に加え、指示を置けること。有料のプランでは知識が大きくなると RAG に切り替わり容量を最大10倍に広げること。Team と Enterprise でメンバーと共有でき、「閲覧可」と「編集可」の権限があることClaude ヘルプセンター: What are projects?2026-10-15
商用の製品の入力と出力を既定ではモデルの学習に使わないこと。フィードバックで送った会話は関連する会話全体とともに最長5年保存され学習に使われうること。Team と Enterprise の管理者がフィードバックの送信を止められることAnthropic Privacy Center: Is my data used for model training?2026-10-15
削除した会話がチャットの履歴からすぐ消え、バックエンドの保存から30日以内に削除されることAnthropic Privacy Center: How long do you store my organization's data?2026-10-15

回答の内容、回答を控えるかどうか、手紙や回答を公表するかどうかは、広聴の担当と担当課、市の決まりに沿って決めてください。 生成AIの利用にあたっては、市の個人情報の取扱いの規程と情報セキュリティの方針を確かめてください。本記事は上記の公開情報で確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-1691)についてのご相談はこちらから。

AI活用について相談する
目次