地方自治体とkintone 住民問い合わせと部局横断の振り分け（概念）

地方自治体のDX（デジタルトランスフォーメーション）において、最も市民が変化を実感しやすく、かつ職員の業務負荷軽減に直結するのが「住民問い合わせ対応」のデジタル化です。しかし、自治体組織特有の「縦割り構造」が、スムーズな情報共有と迅速なレスポンスの障壁となっているケースが少なくありません。

本記事では、kintone（キントーン）を活用し、住民からの問い合わせを適切な部局へ自動的かつ正確に振り分け、進捗を全庁で可視化するための具体的なシステムアーキテクチャと実務上の設計指針を徹底解説します。

地方自治体の問い合わせ対応における「部局横断」の壁

多くの自治体では、住民からの問い合わせを電話、メール、あるいは窓口で受け付けています。これらを集計・管理する際、いまだに多くの現場で「Excel」や「共有フォルダ」が主役となっていますが、そこには構造的な限界が存在します。

なぜ従来のExcel管理では限界が来るのか

Excelによる管理では、一つのファイルを複数人で同時に編集することが難しく、最新の進捗状況が分からなくなる「情報の先祖返り」や「二重入力」が頻発します。また、部局をまたぐ回答が必要な場合、メールにExcelファイルを添付して送付するというアナログな「回送」作業が発生し、結果として以下のような問題を引き起こします。

• どの部局で対応が止まっているのか、全体像が見えない。
• 過去の類似回答を探すのに時間がかかり、対応の質が属人化する。
• 住民への回答漏れや、二重回答といった致命的なミスを誘発する。

住民の利便性と職員の負担軽減を両立する「kintone」の役割

kintoneは、プログラミングの知識がなくても業務アプリを構築できるノーコードツールですが、自治体においては単なる「データベース」以上の役割を果たします。特に「プロセス管理（ワークフロー）」と「アクセス権限」の柔軟性は、組織構造が複雑な自治体にとって極めて有効です。

問い合わせ内容に応じて、自動的に福祉課、道路課、教育委員会といった担当部局へタスクを割り振り、それぞれの進捗をリアルタイムで監視できる環境を構築することが、自治体DXの要となります。

kintoneによる問い合わせ振り分けシステムの全体設計図

効率的な運用を実現するためには、場当たり的にアプリを作るのではなく、情報の流れ（データフロー）を正しく設計する必要があります。

フロントエンド（住民入力）からバックエンド（kintone）への導線

住民が直接kintoneの画面を操作することはありません。通常は外部のフォームサービスを利用して、住民が入力したデータをkintoneへ飛ばす形をとります。

• 住民側: Webサイト上の問い合わせフォーム（フォームブリッジやGraffer等）に入力。
• kintone側: 入力されたデータが即座に「問い合わせ管理アプリ」にレコードとして登録される。

ここで重要なのは、フォーム側で「問い合わせカテゴリー」を正しく選択させることです。このカテゴリーが、後の自動振り分けの「トリガー」となります。

「振り分け用マスタ」を活用した自動アサインの仕組み

kintoneの標準機能でも、ドロップダウンの選択肢に応じて担当者を変えることは可能ですが、自治体のように組織変更や担当替えが激しい環境では、アプリ内に直接設定を書き込むのは得策ではありません。

「部局マスタアプリ」を別途作成し、カテゴリーと担当部局を紐付けておくことで、メンテナンス性を高めることができます。住民が「道路の補修」を選べば、マスタを参照して自動的に「建設課」のグループに通知が飛ぶ、といった設計が理想的です。

こうした業務のデジタル化を推進する際、多くの自治体が直面するのが「既存ツールとの棲み分け」です。例えば、現場の業務改善だけでなく、バックオフィス全体の最適化を検討されている方は、以下の記事も参考になるでしょう。

Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド

住民問い合わせ・部局横断管理を実現するためのステップバイステップ

具体的な構築手順を4つのステップで解説します。

Step 1：問い合わせ受付アプリの作成と項目定義

まず、基本となる「問い合わせ管理アプリ」を作成します。必要なフィールドは以下の通りです。

• 自動採番: 問い合わせID（「2026-0001」など）
• 住民情報: 氏名、メールアドレス、電話番号（フォームから自動連携）
• 問い合わせ内容: タイトル、詳細内容、発生場所（地図連携プラグインを使うと便利です）
• カテゴリー: ドロップダウン形式（「ゴミ・環境」「福祉・健康」「道路・公園」など）

Step 2：部局・担当者マスタの整備とルックアップ設定

次に、別のアプリとして「組織マスタアプリ」を用意します。ここには「カテゴリー」と「担当部局名」、そして「担当者（グループ）」を登録しておきます。

問い合わせ管理アプリ側で、カテゴリーが選択された際に、このマスタから「担当部局」を「ルックアップ」または「プラグインによる自動取得」で反映させます。

Step 3：プロセス管理機能によるワークフローの構築

kintoneの「プロセス管理」機能を有効にします。ステータスの例は以下の通りです。

1. 未着手: フォームから投稿された直後の状態。
2. 担当部局確認中: 総合窓口が内容を確認し、担当課を確定した状態（自動振り分けが可能な場合はスキップ可）。
3. 対応中: 担当部局が調査や回答作成を行っている状態。
4. 承認待ち: 課長等の決裁を仰いでいる状態。
5. 完了（回答済み）: 住民へ回答を送り、記録を閉じた状態。

Step 4：通知機能とダッシュボードのカスタマイズ

自分の部局に案件が割り振られた際、kintone内の通知だけでなく、メールやチャットツール（Microsoft TeamsやSlack、LINE WORKS等）へ通知を飛ばす設定を行います。これにより、kintoneを常時開いていない職員も即座に対応を開始できます。

自治体でのLINE活用については、こちらの解説が実務の参考になります。住民との双方向コミュニケーションを強化したい場合に最適です。

【完全版】LINEとLINE WORKSを連携する方法！できること・できないこと

自治体向けkintone連携サービスの比較検討

住民からの入力を受け付けるフォームツールは、セキュリティやコストの観点から慎重に選定する必要があります。

※各サービスの最新料金や仕様は、必ず公式サイト（FormBridge / Graffer / SmartPost）をご確認ください。

実務で直面する3つの課題と解決策

実際に運用を開始すると、システム設計だけでは解決できない「運用上の課題」が必ず浮上します。

課題1：担当部局が不明確な案件の「保留・再割り当て」

住民からの問い合わせが複数の課にまたがる場合や、どこの課が担当すべきか曖昧な場合があります。このとき、アプリ側で「差し戻し」や「協議中」といったステータスを用意しておかないと、データの行き先がなくなり「放置」される原因となります。

解決策: 総合窓口（広聴課など）を「ハブ」として定義し、担当不明案件は一度総合窓口に戻す、というルールをプロセス管理に組み込みます。

課題2：庁内ネットワーク（LGWAN）からのアクセス制限

自治体の業務端末は、多くの場合LGWAN環境にあり、インターネット接続が制限されています。kintoneはパブリッククラウドサービスであるため、庁内からアクセスできない、あるいは非常に低速であるという問題が発生します。

解決策: LGWAN接続サービス（「R-PiCS」や「Alpha SSL」等）を経由してkintoneを利用するか、あるいは三層の対策（αモデル・βモデル等）に基づき、特定端末からのみインターネット接続を許可する運用を検討してください。

課題3：個人情報保護とアクセス権限の厳格な運用

問い合わせには、住民の氏名や住所だけでなく、健康状態や生活困窮状況など、極めて機密性の高い情報が含まれることがあります。

解決策: kintoneの「レコード閲覧権限」を活用し、「自部局の案件のみ閲覧可能」という制限をかけます。全庁でデータを共有しつつ、詳細な中身は担当者以外見られないようにする設計が不可欠です。また、ログインには2要素認証を必須とし、IPアドレス制限をかけることで、外部からの不正アクセスを徹底的に排除します。

こうしたセキュリティ基盤の整備や、アカウント管理の自動化については、エンタープライズ向けの知見が役立ちます。特にSaaSの乱立に悩むIT担当者の方は、以下の記事をご一読ください。

SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

まとめ：持続可能な自治体DXへの第一歩

kintoneを用いた住民問い合わせ管理は、単なる「デジタル化」ではありません。それは、部局間の壁を取り払い、「住民に最適な回答を届ける」という自治体本来の目的を再定義するプロセスです。

最初は小さな部局（スモールスタート）から始め、徐々に全庁へ広げていくことができるのがkintoneの強みです。まずは現行のExcel管理をアプリ化することから始め、今回ご紹介した「自動振り分け」や「組織マスタ」の概念を取り入れて、強固な運用体制を構築してください。

もし、既存のオンプレミス環境や古いSaaSからの脱却を検討されている場合は、より広範なインフラ設計の視点も必要になります。その際は、現実的な「剥がし方」を解説したリソースもぜひ活用してください。