最終確認日：2026年8月22日
実装パターン解説：以下は自治体窓口の住民問い合わせ対応でよくある構造をもとに一般化した実装パターンです。特定の自治体の実績数値ではありません。自団体の情報セキュリティポリシー・個人情報保護条例に照らして適用してください。
自治体の住民問い合わせは、電話・窓口・メール・SNSなど複数チャネルから届き、内容も「ゴミの分別」「転入転出手続き」「子育て支援制度」「税金の納付方法」など多岐にわたります。担当課が明確でない問い合わせは、まず総合窓口や代表電話で受け、内容を読み取って適切な課へ振り分ける作業が発生します。この振り分け作業に時間がかかると、住民をたらい回しにしてしまうリスクが高まります。
Claude Codeは、住民対応の判断そのものを代替するのではなく、問い合わせテキストを読み込み、内容分類・担当課の候補提示・返信草案の作成・既存FAQとの照合をコードとして実装する用途に向いています。実際の回答内容・担当課への正式な振り分けは職員が行う前提です。
問い合わせ振り分けが窓口の負担になる理由
住民の問い合わせは行政の縦割り構造を意識せずに寄せられるため、1つの問い合わせに複数の担当課が関係することも珍しくありません。また、季節性（確定申告時期、転入転出シーズンなど）によって特定の問い合わせが急増し、窓口が繁忙期に集中する構造もあります。既存のFAQページと問い合わせ内容が実は重複しているのに、住民がFAQにたどり着けず個別に問い合わせているケースも多く見られます。
実装の前提とスコープ
| フェーズ | 対象 | Claude Codeの役割 | 人（窓口職員）が担う判断 |
|---|---|---|---|
| データ整形 | メール・フォーム問い合わせのテキスト | 内容分類スクリプトの生成 | 分類結果の妥当性確認 |
| 担当課振り分け | 分類結果と担当課マッピング | 候補提示スクリプト、表記ゆれ対応 | 最終的な担当課の決定 |
| 返信草案 | よくある問い合わせへの回答 | FAQベースの回答草案生成 | 送信前の内容確認 |
| FAQ更新候補 | FAQにない新しい問い合わせパターン | 頻出パターンの抽出 | FAQへの追加判断 |
Claude Codeへの指示例（プロンプト）
自治体業務は担当課の名称や制度名が独自であることが多いため、自団体の組織構造と制度情報を正確に伝えることが重要です。以下は実装で使えるプロンプト例です。
1. 「以下は住民からの問い合わせテキストと、担当課一覧（課名・
担当業務の説明）です。問い合わせ内容から該当しそうな担当課の
候補を上位2つまで提示するスクリプトを書いてください。個人名・
住所などの個人情報はログに出力しないでください。」
2. 「既存のFAQデータ（質問と回答のペア）と、新しく届いた問い合わせ
の類似度を比較し、既存FAQで回答できそうな問い合わせを検出する
スクリプトを書いてください。」
3. 「FAQで回答できる問い合わせについて、丁寧語での返信草案を
生成してください。これは職員が内容を確認してから送付する
前提の下書きであることを明記してください。」
4. 「週次で『問い合わせ件数の推移』『担当課別の内訳』『FAQでは
カバーできていない頻出パターン』を集計するレポート生成
スクリプトを書いてください。」
5. 「このスクリプトの実装にあたり、担当課の区分けやFAQの範囲に
不明な点があれば、実装前に質問してください。仮定した点は
コメントに明記してください。」段階的導入のロードマップ
Phase 1（1〜2ヶ月）: 特定チャネル（例：メール問い合わせ）に限定し、分類・振り分け候補の提示を読み取り専用で検証し、既存の職員判断と突き合わせます。
Phase 2（3〜4ヶ月）: 精度が安定した段階で対象チャネルを広げ、FAQベースの返信草案生成を追加します。送信は引き続き職員が行います。
Phase 3（5〜8ヶ月）: 週次レポートの自動生成、FAQ更新候補の抽出フローとの連携まで対象を広げます。
【要注意】よくある失敗パターンと回避策
失敗1：担当課の振り分けを確定処理として自動化してしまう
❌ AIが提示した担当課候補をそのまま正式な振り分け先として扱う
⭕ 候補提示にとどめ、職員が最終的な振り分け先を確認・決定する
複数課にまたがる問い合わせや、制度変更直後の判断など、AIだけでは対応しきれないケースがあります。
失敗2：個人情報を含む問い合わせ内容をそのまま検証に使う
❌ 実際の住民氏名・住所を含むテキストでプロンプトを試す
⭕ ダミーの氏名・架空の事案で動作確認してから本番データに適用する
住民からの問い合わせには個人情報が含まれるため、検証段階では必ず匿名化・仮名化します。
失敗3：FAQベースの回答をそのまま送信する仕組みにしてしまう
❌ 類似度が高いFAQの回答をそのまま自動返信する
⭕ 草案を生成し、職員が内容・最新性を確認してから送信する
制度変更や特例対応により、FAQの内容が古くなっている場合があります。
失敗4：分類精度を検証せずに複数チャネルへ一気に展開する
❌ 検証なしに電話・窓口・SNSすべてのチャネルへ同時導入する
⭕ 1チャネルで精度を確認してから、段階的に対象を広げる
チャネルによって問い合わせの傾向や表現の丁寧さが異なり、分類精度も変わります。
効果の考え方（試算モデル）
正直にお伝えすると、削減効果は問い合わせ件数、担当課の細分化度合い、既存FAQの整備状況によって変わるため、一律の削減率は提示できません。ここでは考え方の枠組みだけを示します。
例えば「1日50件のメール問い合わせがあり、1件の振り分け判断に平均5分かかっている」という想定モデルを置くと、1日あたりの振り分け作業は約4時間相当になります（あくまで試算のための仮の数値です）。分類・候補提示・FAQ照合をコード化できれば、職員の作業は「確認」と「例外対応」に絞られます。実際の効果は、Phase 1の並行運用期間に自団体のデータで実測することを推奨します。
個人情報の扱いと安全設計
住民からの問い合わせには氏名、住所、家族構成など機微な個人情報が含まれることがあります。検証段階では匿名化・仮名化したサンプルデータを使い、本番データを扱う前には自団体の情報セキュリティポリシー・個人情報保護条例を必ず確認してください。個人情報の取り扱いに関する最新の考え方は個人情報保護委員会、行政のデジタル化に関する取り組みはデジタル庁の公式情報を参照することをおすすめします。
公式ソース
関連して読む記事
FAQ
Claude Codeに本番更新まで任せてよいですか？
初期段階では任せず、読み取り専用と人の承認を挟む設計にします。担当課の最終決定と返信送信は必ず職員が行います。
個人情報を含むデータで検証できますか？
検証時は匿名化し、必要最小限のサンプルだけを使います。自団体の個人情報保護条例の確認も必要です。
最初に自動化するなら何が安全ですか？
問い合わせ内容の分類やFAQとの類似度照合など、読み取り中心の処理が安全です。送信を伴う処理は最後に回します。
効果はどう測りますか？
振り分けにかかる時間、たらい回し件数、FAQでの自己解決率で測ります。一律の削減率を仮定せず、自団体のデータで実測することが重要です。
既存の総合案内システムを置き換える必要がありますか？
通常は置き換えず、既存システムやメールデータを読み込む周辺処理として組み込みます。
電話問い合わせにも使えますか？
電話の場合は、職員が作成した対応メモをテキスト化してから同じフローに載せる運用が現実的です。
複数課にまたがる問い合わせはどう扱いますか？
候補として複数の担当課を提示し、最終的にどの課が主担当になるかは職員間の調整で決定する運用が安全です。
