自治体・官公庁のAI活用事例

市民からの電話が月12万件に達し、国の調査などがあるたびに専用窓口を用意する必要もあって職員の負担が重かった。

各課が持つFAQは粒度がばらばらで更新漏れも多く、担当部署が変わると誰も手入れしないFAQが残って誤った案内につながる心配があった。

1. 対話型AIエージェントを市民向け問い合わせ対応に置く
2. FAQを作り直さず公式サイトの記事とPDFを回答のもとにする
3. あいまいな質問は聞き返し機能で税や料金の種類まで絞り込む
4. 各課が担当ページを最新に保ち回答の正しさを保つ
5. 導入前に個人情報を入力しないなどのガイドラインを職員に示す

FAQを個別に作って直し続ける運用をやめ、公式サイトの更新がそのまま回答の質につながる形になった。

電話が苦手な人や時間外に調べたい人が自分で解決できる窓口が加わり、将来は対面と電話とチャットを組み合わせた総合コンタクトセンターを目指す。

職員の約半数が生成AIを使ったことがなく、日々の業務のどこで使えるかが分からない状態だった。

1. 対面の初級編カリキュラムで画面の基本操作を確認する
2. 庁内の資料を読ませるプライベートナレッジの使い方を試す
3. 議員からの質問への備えを想定し情報を集める場面を演習する
4. 職員が自分の担当業務に置き換えて質問を入力する
5. 質疑で機能の使い分けやAIモデルの違いを話し合う

約60名が参加し、文書づくりだけでなく情報を集めて整理する場面でも使えることを体験した。

参加者からはここまで高度な情報収集ができるのかという声が上がった。

生成AIを週1回ほど触る職員が半数以上で、QommonsAIを初めて使う職員も多く、業務のどの場面で使えるか分からない状態だった。

1. 対面の初級研修で基本操作を説明する
2. 随意契約の理由づくりや引継書づくりの例を示す
3. 職員が自分で操作しアンケートフォームやあいさつ文を作る
4. 議会対応のデモで議員の質問と再質問を想定し答えを準備する

午前午後で各回約40名が参加し、生成AIは文書を作る道具という思い込みが変わり、再質問を予測して備える使い方に気づいたという声が出た。

ワークでは隣の席の職員同士でモデルやプロンプトの違いを聞き合う場面も生まれた。

職員によってAIの使う頻度に差があり、操作の仕方や応用の幅もそろっていなかった。

基本操作は分かっても実際の業務にどう結びつけるかが見えにくかった。

1. 担当者が市役所を訪れ初級編の対面演習を3回行った
2. 議事録作成と議会対応を題材に選んだ
3. 会議内容の要約や情報整理を職員が手を動かして試した
4. 指示を具体的に書き直し出力の違いを比べた
5. 出力は必ず職員が中身を確かめてから使う手順を確認した

研修には午前36名、午後1回目39名、午後2回目46名が参加した。

館林市ではQommonsAIの利用率が約5割に達し、挙手で確かめたところ毎日または週3回以上使う職員が約半数を占めた。

復興と住民サービスの業務が続くなか、生成AIを入れても職員が自分の担当業務でどう使えばよいか分からない状態だった。

入力してよい情報の線引きもはっきりしていなかった。

1. 対面とオンラインを併用した初級編の研修を開いた。
2. 基本操作を説明し職員が自分の端末で触るワークに移った。
3. 日ごろ書いている身近な文書を題材にAIと文章を整えた。
4. 機密情報の入力範囲や画像生成の広報利用を質疑で確認した。
5. 出た要望や質問を総務課と共有し利用ルールの材料にした。

午前は現地約35名、午後は現地約25名が参加し、AIは分からないと話していた職員も対話を重ねて自分の考えを文章にまとめられた。

庁内に広げるうえでの運用上の論点も共有できた。

生成AIに触れたことがない職員が多く、何ができるのか分からず近寄りがたさを感じていた。

議会答弁の作成も手ほどきのないまま担当することが多かった。

1. 初級編のカリキュラムで対面研修を行う
2. 体験ワークとして挨拶文を作らせる
3. 自分で指示文を組み立てて出力の違いを試させる
4. 迷うときは必要な情報を一問ずつ質問してと頼む
5. 過去の答弁や議員ごとの特徴をふまえた文章作成を操作して確かめる

午前35名、午後は3自治体の34名に加え公開研修に約80名が集まった。

研修後は職員からの利用申込が複数あり、AIへの心理的な抵抗感が下がったという声が出た。

医療保健や健診、妊婦の手続きなどの窓口に同じ内容の問い合わせが電話や来庁で何度も寄せられ、職員が1件ごとに数分から20分ほどかけて答えていた。

人口減少で職員が減る中、行政サービスを保てるかが不安だった。

1. 職員に負担を感じる業務を聞き取り対象を決めた
2. 公式サイトを週1回巡回し文章を分けてRAG化した
3. 質問に関連する部分を探しClaude Sonnetが回答を作る
4. チャットボット画面をVoiceflowで組みAPIで接続した
5. 73日間の実証で精度と反応を確かめ本番運用に移した

実証時の利用が1年続いた場合、年間で約590時間の業務削減になると見込んだ。

利用者アンケート118件のうち83％が役に立ったと答えた。

防災無線やSNS、ホームページで災害情報を流しても、デジタル機器の操作に不慣れな高齢者に届きにくかった。

電話での連絡も一部行っていたが、手間と時間がかかっていた。

1. 一斉架電の仕組み「シン・オートコール」を防災用に転用した
2. 登録済みの電話番号リストへ自動で電話をかけ避難情報を音声で流す
3. プッシュダイヤル方式から音声対話の応答に切り替えた
4. はい／いいえや現在地を声で答えてもらい回答をテキスト化する
5. ケガなどの語から救助の優先度を判断する材料にする

2021年秋に7つの行政区でプロトタイプを試し、2022年3月の市の訓練と10月の県の訓練で実証した。

訓練後のアンケートで有効との評価が集まり、まず市職員の安否確認で運用を始め、住民向けの本格運用へ進んだ。

移住相談用のLINEチャットボットは辞書に登録した質問にしか答えられず会話が続かなかった。

答えられない質問は職員が手作業で返していて早朝や休日の対応が難しく負担も重かった。

1. 外部サービスの提供終了を機にAmazon Bedrockへ移行した
2. 特定の語を含む質問は検証済みの辞書から返す
3. 該当が無ければRetrieve APIで回答データを探す
4. 信頼度が足りない時はClaudeに文案を作らせ職員が直す
5. マスコットの親しみやすい口調を保った

文脈をふまえた自然なやり取りができるようになり、ほとんどの質問にその場で答えられるようになった。

サーバーレス構成をそのまま使い、従来の予算内で運用できている。

粗大ごみの受付センターは電話が集中し、月曜や祝日の翌日はオペレーターにつながるまで時間がかかっていた。

手数料が分からない市民からの電話が多く、つながらないという苦情も寄せられていた。

1. 市民が受付サイトかFAQサイトからチャットボットを開く
2. 撮影した写真か保存済みの写真をチャットに送る
3. SODAI Vision APIが画像を判別し10秒ほどで品目と手数料を答える
4. 判別できないときは有人チャットにつなぎオペレーターが写真を見て答える
5. 全国から6,000件近くの粗大ごみ画像を集めて学習に使った

開発着手から7ヶ月で稼働に至り、夜間も含めて問い合わせに自動で答えられるようになった。

写真だけで手数料が分かると市民から好評で、有人チャットでも写真を見ながら品目を判断しやすいという声が届いている。

会議の議事録づくりなど日常の定型事務がすべて人手で回っており、職員が考える時間を確保できなかった。

先に使い始めたChatGPTは、普段使うMicrosoft 365との間で情報を毎回コピーして貼り付ける手間がかかった。

1. Teamsで会議を録音し要約と決定事項を取り出す
2. 資料の方向性をCopilotと相談し方針を決める
3. WordやPowerPointでドラフトを作らせ職員が編集する
4. 長い調査依頼を要約させ庁内向け依頼文まで作らせる
5. 他区の取り組みを公開情報から検索・要約させる

2024年8月からの実証実験で月平均300時間の削減を確認し、2025年10月に900ライセンスで全庁に広げた。

2026年3月時点で月間約2000時間の業務時間削減になった。

文字起こしツールやTeamsの文字起こしを使っていたが、誤字直しや要約の手直しに時間がかかっていた。

報告書の外注は納品まで約1週間かかり、急ぐときは職員が録音を聞き直して手で書き起こしていた。

1. 専用アプリを入れ、いつもの会議ツールのまま録音を始める
2. 音声認識エンジンが日本語を文字にし、話者を自動で切り分ける
3. 会議後にAIが要点と決まったことをまとめた議事録を出す
4. 職員は原稿の誤りや表現だけを直して仕上げる
5. DX推進課が複数ツールを比べ、試用期間を経て全庁に広げた

2026年6月24日から約5,400人の全職員が人数制限なく使える運用を始め、会議記録づくりの手作業を減らす体制にした。

市販のモデルではシンガポール特有の言い回しや現場の事情をつかめなかった。

外部のネットにつながらない環境で動かす必要があり必要な知識をモデル自体に入れておくしかなかった。

1. 2025年3月からMistralと組み基盤モデルに独自データを足す
2. 追加学習させPhoenixというモデル群を作る
3. Phoenix-VL1.5Mediumは123Bで画像と文章を扱う
4. 学習はAI Forgeで行い運用と評価はAI Studioに乗せる
5. 通報記録やSNSやセンサーの情報を読み込ませて要約させる

Phoenixの小型版と中型版がNGINE上で動き標準的なLLMの評価で上位の成績を出した。

事務作業の負担が減り現場の職員の対応が速くなった。

以前のシナリオ型チャットボットは満足度が約20％にとどまり回答精度が上がらなかった。

Q&Aの追加登録や各部署への確認に手間がかかり続けていた。

1. 公式サイトにタグを入れAIデジタルスタッフを設置した
2. 2025年12月1日から24時間の回答受付を始めた
3. AIがサイトの中身を読み取り回答を作る形にした
4. 国スポ・障スポは質問例文を並べ該当ページへ誘導した
5. 職員はホームページ更新だけ行いQ&A登録をやめた

月間の利用件数は約1,600件から約3,700件へ倍以上に増えた。

運用費は月額約22万円から月額5万円になり7割強減った。

職員が他部署の情報を探す庁内検索としても使われている。

特許の書類は数式や化学構造や表が本文に混ざり普通のOCRでは正しく読み取れなかった。

業界標準のST36のXML形式に沿った出力も必要で大量の書類を正確にさばく仕組みが足りなかった。

1. 3か月の実証で読み取りの仕組みを共同開発した
2. 15万件超のPDFで1BのOCRモデルを追加学習させた
3. 読み取った中身をMarkdownからHTMLへ変換した
4. HTMLをST36のXML形式へ直す流れを組んだ
5. 人は判断が要る特許審査に時間を回した

1日あたり40万ページを読み取れるようになり文字の認識誤りは1%未満に収まった。

書類の処理にかかる時間は最大5日から数分へ短くなった。

熊野町は前年度まで職員が業務で生成AIを使うことを禁じており、参加者の半数ほどは生成AIに触れた経験がなかった。

何にどう使えばよいか分からず、便利さも実感できていなかった。

1. 担当者が役場に出向き初級編の研修を実施した
2. 午前と午後に分け職員が参加しオンラインでも加わった
3. あいさつ文をAIに書かせるワークに取り組んだ
4. 隣の席の職員と生成文を見比べ指示の違いを確かめた
5. 最後に担当課が今年度の方針を伝えた

午前と午後で合わせて約90名が参加し、短い時間で文章ができたことに驚く声が出た。

使ってみたい、業務に使えそうという受け止めに変わり、この研修をきっかけに全庁への展開が始まった。

過去の議会議事録や直近の取り組みから必要な情報を探し出すのに手間がかかっていた。

現場の仕事に合う形のアプリも無かった。

1. 手元の環境で公開データを使って作り操作感と役立ち方を早く見る。
2. 検証用のクラウド環境を職員が自分で立てる。
3. その環境にAgentic AIの仕組みを載せ一部の職員に使ってもらう。
4. 質問に応じてAIが議事録や直近の取り組みを自分で参照する。
5. 参照した中身から回答文を作らせ意見を反映して試作を直す。

現場の声を取り入れて改善を重ねた結果として実務に使えるという評価が得られる水準まで届いた。

環境の構築や運用も外部に任せず自分たちで進められた。

業務の課題を解くアプリを試すには外部のベンダーに開発を任せるのが通例だった。

職員だけで試作を形にする手立てが無かった。

1. 職員が自分で考えた構想をコーディング支援AIへ伝える。
2. AIが書いたコードを職員が読んで確認し手直しする。
3. そのうえで次の指示を出す流れを繰り返して機能を組み上げる。
4. 個別の要素技術を組み合わせて業務の流れに合うアプリの形にまとめた。

外部のベンダーに頼らず短期間でプロトタイプを作れた。

小さく試して直していく進め方を続けるための土台ができた。

法面の危険な箇所を見つける点検は人の目に頼っていた。

専用の深層学習モデルを一から作ると学習データの用意や計算資源の手配に費用と時間がかかる。

1. 法面を撮った画像をo3とGPT-5へ渡す。
2. 追加学習はせずプロンプトの書き方だけを詰める。
3. モルタルのクラックや植生といった変状を見つけさせる。
4. 判定した中身をテキストで出させる。

追加学習をしなくても法面の変状を高い精度で見つけられることを確認した。

専用のモデルを作る場合と比べて費用と時間を大きく減らせる形になった。

県庁には多くのデータがあるものの分析にはデータベースの操作や統計の専門知識が必要だった。

職員が自分で集計して読み解くのは難しかった。

1. チャット画面に普通の日本語で質問を入れる。
2. LLMが庁内のデータベースへ集計をかける。
3. 足りない場合は集計をやり直して分析を続ける。
4. 回答の文章やグラフをまとめてチャットに返す。
5. 集計の単位や表示の形はAIが質問の意図から判断する。

データベースの操作や統計の知識がなくても質問するだけで分析できるようになった。

あらかじめ想定していなかった幅広い質問にも答えられた。

県民から届く自由記述の意見は量が多く、手作業の分類と報告資料づくりに数日かかっていた。

CSVやExcelで1行ずつ読む作業は職員の負担も大きかった。

1. 自由記述を広聴AIに読み込ませて分類させた。
2. 結果を意見の地図のような配置で見られるようにした。
3. 想定から外れる回答を除く指示をプロンプトへ書き足した。
4. ラベルの文言を短く分かりやすい言い方へ整えた。

手作業で数日かけていた3,000件の分類が30分に満たない時間で終わった。

同じデータでもプロンプトの中身で出力が大きく変わることも確かめられた。

SNSに出る県民の声は数が多く人が読んで整理するのは手間がかかる。

意見の入っていない投稿も多く混ざっていた。

1. 知事選の期間にXへ出た投稿4,924件を集めた。
2. 投稿を広聴AIに読み込ませ意見の抽出から分類と要約まで任せる。
3. 裏側のLLMにはAzure OpenAIサービスのGPT-4oを使った。
4. 埋め込みモデルは同じサービスのtext-embedding-3-largeにする。
5. 意見を含まない投稿は除外の対象として落とした。

4,924件を約15分で処理し3,570件の意見が抽出された。

選挙結果や投票率の低下への心配や候補者選びの議論や地域課題への提案といったテーマが見えた。

道路の法面が崩れる兆しをどう早く見つけるかが課題だった。

落石などの規制情報は残っていても、写真から危ない状態を判定する仕組みは無かった。

1. 生成AIプラットフォームのDifyで法面診断のアプリを組んだ。
2. 画面の操作だけで流れを作りプログラムは書いていない。
3. 法面の画像を入れると複数のマルチモーダル生成AIが同時に動く。
4. 植生とクラックをそれぞれ検出し個別のレポートにまとめた。
5. 最後に1つに統合して総合的な評価を出す流れにする。

写真を1枚入れるだけで、植生とクラックの検出から総合評価までを一続きで出せる診断システムができた。

バス利用者が減って路線の赤字と運転手不足が進み、高齢者が移動できなくなる心配があった。

便数が少ないことやバス停が遠いことへの不満も出ていた。

1. 網走市が実証運行の全体を取りまとめた。
2. バスの運行はバス会社が担いシステムは通信会社が作った。
3. 利用者から出る乗降のリクエストはその場でシステムへ届く。
4. AIが効率のよい車両とルートを計算し乗り合わせる形を決める。
5. 運行は2020年8月から2023年3月まで続けた。

時刻表どおりに走る形ではなく、リクエストに合わせて走る運行を2023年3月まで試した。

地域の公共交通を保ちつつ車両の運用を効率よくする狙いで進めた。

インターネット経由の生成AIでは扱える情報が限られ、庁内の資料を踏まえた回答を出せなかった。

全職員が使える環境も整っていなかった。

1. LGWANで使えるexaBase 生成AI for 自治体を入札で選び使い始めた
2. まちづくりの基本計画や市長挨拶をRAGに読み込ませた
3. 議会会議録や契約などの庁内マニュアルも登録した
4. 国の計画と市の計画の差を抽出させ表の形でまとめさせる
5. 過去の答弁から再質問の想定案を複数出させ職員が答弁を用意する

2024年10月から2025年1月までの約4か月間で約1,745時間の業務時間を削減した。

資料の出典探しも問いかけるだけで該当ページまで示されるようになり、探す手間がなくなった。

会議の資料づくりから議事録を配るまでに9時間ほどかかっていた。

1. 2024年度からAI機能付きのGoogleワークスペースを使う
2. 会議の前に参加者から意見を集めておく
3. 会議中は自動の文字起こしを回す
4. 終わったらまとめを作って参加者へ送る
5. 議事録も同じ流れで作っている

会議の資料作成から議事録の共有までで9時間ほどかかっていた作業が50分ほどになった。

ごみの出し方や施設の場所を尋ねる電話が一日中鳴り続け、職員の手が取られていた。

1. Geminiでごみの分け方と出し方のガイドを作った
2. 品名を入れると出すときの注意点が出る形にした
3. 施設名を押すとGoogleマップが開くようにした
4. 中身はごみ処理施設の職員と話しながら詰めた

ガイドは30分ほどで仕上がった。

市民が自分で調べられる形になり、庁内へ小さな成功の例として示せた。

土地や家屋の現況を確かめるには現地へ出向く手間が大きかった。

外部に丸ごと頼むと開発の費用もふくらむ。

1. 無料のQGISで衛星画像を緯度と経度から地図に並べた。
2. PythonとExcel VBAからChatGPTのAPIを呼び出す。
3. 2つの時点の画像を見比べて変化を拾う仕組みを作る。
4. コードはChatGPTとやり取りしながら職員が自分で書いた。
5. 有料はChatGPT-4oのAPIだけで他は無料のソフトでそろえた。

開発を始めて3か月ほどである程度の結果が出るようになった。

委託料は約120万円で作れて、現地を見るべき場所を絞り込めるようになる見込み。

町のホームページでは住民が知りたいことを検索ワードに置き換えないと目的のページへたどり着けなかった。

Webでの情報提供の力を上げる必要があった。

1. ホームページの検索をCogmo Enterprise 生成AIに替えた
2. 文章のまま打ち込んでも意味を読み取る形にした
3. ChatGPT連携のRAGで回答文を検索結果の先頭に出した
4. 担当者は管理画面の操作だけで出る順番を整えた

2025年8月5日から9月30日の検索結果画面の閲覧数が前年の同じ期間と比べて約1.5倍に増えた。

住民の使いやすさと運用の負担軽減を両方進められた。

職員の負担を減らしたいが、生成AIは入れただけでは現場に根づかない。

自分の仕事のどこで使えるのかを職員が思い描きにくい状態だった。

1. LGWANでつながる環境に対応した生成AIを庁内に入れた。
2. 導入の直後に90分の研修を2日間にわたって開いた。
3. 前半は生成の仕組みと他の自治体の使い方を紹介した。
4. ワークで日々の仕事を書き出しAIに任せられる作業を探した。
5. 条件を決める・役割を与える指示のコツを手を動かして試した。

研修後のアンケートで93%が満足・大変満足と答えた。

業務に活かせると答えた人も93%だった。

会議の記録を作るために文字起こしへ多くの時間と人手を取られていた。

業務を軽くする方法を探していた。

1. 2019年にその場で文字にするAI議事録の仕組みを試験導入した
2. まず25件の会議で作業時間の削減幅を測った
3. 職員に機能と変換の正しさが実務に耐えるか確かめてもらった
4. 集めた意見から機能追加や精度向上の要否を判断した
5. 判断をもとに本格運用へ進んだ

対象とした25件の会議で作業時間が4割減った。

変換の正確さについても職員からよい評価が得られ、本格運用に移った。

住民や事業所から届く課税資料をまとめる処理で不整合が出るたび、職員が資料の画像を1枚ずつ見て直す必要があった。

経験の浅い職員ほど判断に時間がかかっていた。

1. 住民税の賦課業務で資料の併合処理にAIシステムを組み込む
2. 不整合が見つかった納税者ごとのデータをAIに渡す
3. AIが見直すべき資料と直し方を候補として示す
4. 職員が候補を見て修正の要否を最後に判断する

賦課修正の作業時間が約5割減った。

機械的な直しでは課税資料の画像を開かずに済むようになり、ベテランには答え合わせとして働き、経験の浅い職員の作業速度もベテランに近づいた。

職員が電話対応に多くの時間を取られていた。

市のホームページにチャットボットを載せたあと、電話応答まで生成AIで担えるか確かめる必要があった。

1. 有人の総合案内の隣に個別ブースを設けた
2. 生成AIの音声案内端末を置き来庁者の顔を認識して先に声をかける
3. マイクへの問い合わせに音声と庁舎の案内図の表示で答える
4. マイナンバーカードや運転免許証をカメラで読み取り申請書に氏名や住所を印刷する
5. 回答のもとを市のホームページと既存のガイドブックにした

音声でのやり取りが実務に使えることを確認でき、電話対応の自動化の検討につながった。

有人窓口では聞きにくい細かな問い合わせにも端末が答えられるようになった。

特定健診の受診率が伸び悩み、とくに40〜50代の現役世代で受診が少なかった。

団塊の世代が後期高齢者健診へ移るため、全体の受診率がさらに下がると見込まれていた。

1. 国保加入者の過去5年分の健診記録やレセプトをAI事業者に渡す
2. データの受け渡しはLGWAN回線を使い安全を保つ
3. AIで受診確率の高い住民を抽出する
4. 受診頻度や生活習慣の改善意向や体重増加で住民を分ける
5. 分類ごとに文面を変えた受診勧奨の通知を送る

コロナ禍で下がっていた特定健診の受診率が上向き、これまで低かった40〜50代の受診率が改善した。

人手では時間のかかる抽出作業が減り、住民への対応にあてる時間が増えた。

県職員から寄せられるICTの問合せが年間1万件ほどあり、回答のノウハウが担当者個人に溜まりやすかった。

離島が多く、その場ですぐ答えてほしいという要望も強かった。

1. ネットワーク一括調達でベンダーのAI提案を採用した
2. 過去の問合せと回答をためて検索できるようにした
3. 新しい問合せを自然文のまま解析させ回答候補を並べた
4. 運用前に専門用語を学習させた
5. 情報システム担当が回答状況を確認する体制にした

庁舎に常駐するICT問合せ担当者の人数が減った。

ITに詳しくない職員と業務に詳しくない担当者の間をAIが橋渡しし、質問の意図がかみ合わない対応が減った。

ごみの分別についてチャットボットでの自動応答を進めていたが、電話での相談が減らず職員の負担が続いていた。

時間外や休日は電話に出られず市民を待たせていた。

1. ごみ分別の電話をAIが音声で受けて答える仕組みを入れた
2. 品名別の分け方や地区別収集日や年末年始の予定まで答えられるようにした
3. 回線を複数同時につなぎ24時間365日応対する形にした
4. 問い合わせ音声を集めて答えられない固有名詞を後から追加した
5. 案内文や説明の順番は人が手を入れて調整した

ごみ分別ガイドのチャットボットと並行して動かしたところ、電話相談の件数が約15％減った。

時間外の応対が約50％を占め、休日や夜間も電話で答えられるようになった。

介護認定を受けていない人の中から将来的に介護度が上がりやすい人を早めに見つけたいが、本人に用紙を書いてもらう方法では正確さも速さも足りなかった。

後期高齢者だけで約5万人おり全員の状況把握は難しかった。

1. 庁内の複数の課が持つ住民情報や介護認定情報を集める
2. 障がいの情報や特定健診の受診有無も対象に加える
3. 新規介護認定者約3,000件をAIに学習させ条件をモデル化する
4. 65歳以上の全市民の情報と突き合わせリスクを点数にする
5. 絞り込んだ後は職員が個別訪問して介護予防につなげる

職員がこれまで気付けなかった潜在的なリスクの高い人を見つけられるようになった。

経験や勘に頼っていた判断の基準が整理され、広い市域での訪問にかかる職員の負担も軽くなる見通しとなった。

年間3万件ほどある建築許可の審査で、職員と申請者の間で確認と修正のやり取りが何度も続いていた。

書類審査が終わるまで最大4週間ほどかかり、双方の負担が大きかった。

1. 申請書類をAIが読み取り条例や規制の文書と突き合わせる
2. 適合か非適合かを申請後すぐに申請者へ返す
3. 非適合なら直すべき箇所を具体的に伝える
4. 申請者は指摘をもとに書き直して再提出する
5. 職員は人の目が要る部分の確認に回る

書類に不備がなければ数分で審査が終わるようになった。

職員の人為的なミスと審査の負担が減り、申請者側は承認される割合が上がった。

2024年1月に始めた試行では生成AIへの個人情報の入力を一切禁じていた。

そのため職員から入力できる情報の範囲を広げてほしいという要望が出ていた。

1. 庁内ネットワークと専用線でつないだ閉域のAzure環境を用意した
2. その上にAzure OpenAI Serviceを置き入力が学習に回らない設定にした
3. マイナンバーは対象外とし要配慮個人情報までを入力可とした
4. 一連の処理で1,000人分までという上限を運用ルールにした
5. 2024年4月から本格利用に切り替えた

少数の個人情報が入る議事録の要約や市民の相談記録表づくりにも生成AIを使えるようになった。

令和6年7月のアンケートでは、使った職員の約80％が仕事が効率よくなったと答えた。

虐待による児童の死亡が2012年度に2件起き、対応の見直しが必要になった。

職員ごとに判断の根拠がそろわず、経験の差も出ていた。

1. 検討会をつくり県版リスクチェックリストを2013年度に作成した
2. 作成したチェックリストを翌年度から現場で運用した
3. 約6年分の対応事例データをAIに学習させリスク度と類似事例を出す
4. システムをタブレットに載せ県内6か所の児相に配布した
5. 入力データは閉域回線で専用サーバに貯め1日1回csvで移す

過去の事例から出たリスク度や特徴を、一時保護の判断の参考にできるようになった。

シミュレーション機能で経験の浅い職員が自分から学ぶようになり、人材育成にもつながった。