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

事業の許認可は紙とスキャンしたPDFで処理され、職員が項目ごとに手で転記して複数のシステムを突き合わせていた。

1件に14〜30日かかり、繁忙期には滞留が膨らんでいた。

1. 国内のデータセンターにサーバーを置いた
2. 自国語だけの追加学習で国産のLLMを作った
3. OCRが申請書類から項目を抜き出す
4. 書類の種類を判定して政府の記録と突き合わせる
5. おかしな点は人の確認に回す

申請の処理は14〜30日から約90秒になった。

これまでに130件以上の許可を出し、今後1年で1,500件を見込む。

話者の少ない言語で書かれた証拠が大量に集まっていた。

捜査と証拠の扱いに期限があるのに訳せる人が足りず立件が危うくなっていた。

1. 専門ではない職員が機械翻訳で大量の文書をざっと訳す
2. APIでまとめて翻訳に回し重要そうな内容を選り分ける
3. 翻訳者が予測型のCATツールで証拠用の文書を仕上げる
4. 翻訳者が直した内容をモデルの学習に戻した
5. 変わり続ける言い回しにも訳を追いつかせる

大きな捜査でこの流れが使われ数百件の逮捕と違法な薬物や銃器の押収につながった。

期限内に大量の証拠を訳して確認できるようになった。

会議のメモを人が読み直し報告を毎回ゼロから書いていた。

案件の情報があちこちに散らばり全体像をつかむだけで一日の多くが消えていた。

1. 範囲を絞った試験導入から始めた
2. ClickUpのAIに会議の内容を短くまとめさせる
3. 案件の資料から必要な情報を抜き出し報告の下書きを作らせる
4. 長い議論をやるべきことと共有用の更新に分ける
5. 担当者とアシスタントが中身を確かめてから関係者へ配る

話し合いから経営層向けの報告を出すまでの時間が大きく縮んだ。

案件の情報が1か所に集まり担当同士の引き継ぎもしやすくなった。

英語以外を話す住民へ危険な気象の情報を届けるには、高い正確さと素早い多言語化の両方が要る。

これまで扱えていない言語もあり担当者の負担が重かった。

1. 気象の文書をLILTの翻訳画面へ通す
2. 機械が出した訳の候補を職員が見る
3. 候補をそのまま通すか手で直す
4. 直した内容はその場で学習され次の候補に反映される
5. 専門の用語がたまるほど自動の訳も精度が上がる

これまで数時間かかっていた警報の翻訳が数分で出せるようになった。

訳し間違いの危険が下がり、対応できる言語も増えた。

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

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

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

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

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

3,400万人以上の本人確認を175か所を超える窓口で抱えていた。

チャネルごとに仕組みが分かれ住民は同じ説明を何度も繰り返していた。

1. 古い基幹システムをSalesforceのクラウド基盤へ移した。
2. 問い合わせの入口をdmv.ca.govにまとめた。
3. よくある質問はAIチャットボットが答え必要なら有人チャットへつなぐ。
4. やり取りをService Cloudの個人の記録に残した。
5. 申請書類をAIや機械学習とつないだ仕組みで読み取った。

REAL IDの申請にかかる時間は35分から7分になった。

電話の推定55%が職員の手を借りずに自動の流れで解決した。

システムやアプリが入り組んでいて、職員が必要な情報にたどり着きにくくなっていた。

自前で囲い込んだLLMも試したが、全部のデータと仕組みを1つにまとめて安全に扱うには足りなかった。

1. 役割ごとの権限の仕組みをGleanにそのまま映した。
2. Glean Protect +で100以上のデータ元を見張る。
3. 個人情報を含むファイルに印を付け共有しすぎを直した。
4. 職員が自分でエージェントを作れるようにした。
5. 人事評価の下書きは必ず人が確認して仕上げる。

パイロットの4週目には1人あたり週4〜6時間が浮いたと報告された。

財務や人事や研修へ広げても使われ続け、最後は1,500人の全職員へ展開した。

職員の約半数が生成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回以上使う職員が約半数を占めた。

2014年に作った翻訳ツールは文法の規則にもとづく仕組みで、短い文はうまく訳せても長い文では誤りが出た。

スペイン語・フランス語・英語とバスク語を双方向で訳せる質の高い仕組みが必要だった。

1. 翻訳の仕組みをマイクロサービスの形で作った
2. GPUをコンテナから使えるようにした
3. GPU operatorで組み込みを簡単にした
4. 外部の技術担当と学びながら進めた
5. 市民向けと専門版の2種類を公開した

1日に3万人以上が翻訳ツールを使うようになり、多い日は26万件を超える問い合わせが入る。

3年で利用が300%増え、行政の公式サービスからの翻訳依頼は40%減った。

復興と住民サービスの業務が続くなか、生成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％が役に立ったと答えた。

信号の周期を決めるための交通量を職員が現地で数えていた。

担当は2.5人分しかおらず、必要なデータがそろわないまま判断するしかなかった。

1. NVIDIA MetropolisのDeepStreamを交差点カメラにつないだ
2. 車両の台数と右左折の動きを自動で数えさせた
3. 通った軌跡も追跡させて結果を集めた
4. 結果をArcGISの3D模型に重ねて立体の地図で見た
5. 停止した車などの異変を文章で知らせる形にした

車両の検知と軌跡の精度は95%になり、2.5人の担当でも分析の速さが4倍になった。

市はCapital Blvdなど10か所の交差点で信号1回あたり4.5秒を短縮できれば、通勤者の時間と燃料を年間970万ドル分減らせると見込む。

市が持つ文書が増え続けて、人事やICTの窓口の担当者がキーワード検索では必要な答えにたどり着けなくなっていた。

1. Oracleのパートナーと組み市の文書の知識ベースを作った
2. OCI Enterprise AIで文書から案件や人物の関係を取り出した
3. 取り出した関係をAutonomous AI DatabaseのGraphに入れた
4. 言葉が一致しなくても意味で探せるAI Vector Searchも使った
5. 職員がOracle APEXのチャット画面から質問できるようにした

窓口に来る質問のうち約85%にこの仕組みが答えられるようになった。

関連する情報もまとめて出るので、探す手間が減って判断も早くなった。

カリフォルニア州の新しい法律で、起訴を決める前に警察の報告書から人種の情報を消す必要が出た。

年に1万7,000件を手作業でさばくのは無理で、検察官の負担も増えるため対応に困っていた。

1. 事務の担当者が報告書やPDFをシステムへ上げる
2. Amazon Textractが書類から文字を取り出す
3. 取り出した文章をAmazon Bedrockへ渡す
4. 人種や民族など個人が分かる記述を自動で伏せる
5. 検察官が伏せ字の資料を見て起訴を判断する

設計から本番まで6か月で終わり、見込みの10か月より早く法律の期限に間に合った。

年1万7,000件の資料の伏せ字が自動になり、人を増やさずに回せるようになった。

防災無線や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ヶ月で稼働に至り、夜間も含めて問い合わせに自動で答えられるようになった。

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

脱税や不正を追うには何十年ぶんのデータをたどって人と取引を結び付ける必要があった。

3テラバイトを超えるデータをCPUの群れで一晩動かしても処理が終わらず、担当者が分割したデータを手でつなぎ直していた。

1. ClouderaをNVIDIAのGPU上で動かした
2. CPUに残っていた複雑な処理を調べて見つけた
3. その部分をGPU向けに書き直しSparkへ組み込んだ
4. Sparkとグラフ解析で巨大なつながりの図を作る
5. 機械学習とボットが図をたどり調査員が確かめる

データサイエンティストの実験は20倍速くなった。

数週間から数か月かかっていたデータの結合と処理が数時間か数分で終わり、基盤の費用は50%下がった。

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

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

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

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

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

契約の中には予算を使い切らないものがあり、余った資金に気づくのが遅れていた。

担当官が手で探す方法では優先度の高い事業へ資金を回すのが間に合わなかった。

1. 過去の契約データをDataRobotに読ませる
2. 資金が余りそうな契約を予測するモデルを作る
3. 予測の扱いに決まりを設けて根拠と精度をそろえる
4. 結果をダッシュボードに並べリスクの高い順に絞り込む
5. 担当官は一覧を見て資金の拘束を解き別の事業へ振り分ける

担当官だけで探す場合と比べて高リスクの契約を3〜5倍見つけられるようになった。

2020年7月以降に22億ドルを超える余剰資金を見つけて振り分け、利用者は1,500人を超えた。

700を超える取引先と600以上の給油拠点を抱えるのに、燃料の動きを追うのも需要の見通しを作るのも別々のシステムと手作業に頼っていた。

全体が見えないため何か起きてから動く形になり、代わりの手を試す計算もできなかった。

1. C3 AI Contested Logisticsを16週間で本番導入した
2. 7つに分かれたシステムのデータを1か所に集める
3. 世界の燃料供給網を写したデジタルツインを作った
4. 地図と数字でリスクのある場所を画面に表示する
5. 輸送が止まった場合を試して備えの案を確かめた

供給網の状況がその場で見えるようになり、最大120日先の混乱まで見通せるようになった。

年間2万時間以上の作業が減り、重要な場面での判断も早まった。

これまでの予知保全の仕組みは空軍が自分たちで持てず、データを自動で取り込む許可も無かった。

B-1Bのセンサーデータは符号化されていて、世界各地の担当者がすぐに中身を見られなかった。

1. B-1Bの過去5,000回の出撃分のセンサーデータを取り込んだ。
2. 取り込んだデータを1つのデータの形にそろえた。
3. 正常なときのデータだけでモデルを学ばせて本来の数値を当てさせる。
4. 実測と予想のずれからシステムの異常と部品の異常を切り分けた。
5. 警報を見る画面も作り技術者が根拠を確かめてから指示を出す形にする。

以前は数週間から数か月かかっていた監視モデルの開発が、数日で終わるようになった。

出撃の直後にデータを上げれば自動で読み取って警報が出るので、警報を見るまでの時間も短くなった。

郡内で16の法執行機関がばらばらのシステムを使っていて、捜査や犯罪統計の報告を作るたびに複数のシステムからデータを取り出して突き合わせていた。

1件で数時間かかり現場の人手も取られていた。

1. C3 AIと組んでC3 Law Enforcementを入れた
2. 6か月で記録管理システムや指令システムなど主なデータ元をつないだ
3. 担当者はパトロールに同乗して現場の困りごとを直接つかむ
4. アプリはAWS上で動かしAmazon SageMakerなどを使う
5. 捜査員は1つの画面から近隣の管轄の事件記録まで引ける

関連するデータを集める時間が数日から数秒に短くなった。

近隣の管轄の事件記録も1つのアプリから安全に見られるようになり、いまは複数の機関で本番の標準になっている。

子どもを狙うネット犯罪の令状づくりが手作業で、捜査員はばらばらのシステムから情報を集めて法的な根拠を書き起こしていた。

書式もそろわず差し戻しや承認待ちが起き、手つかずの通報が3,000件以上たまっていた。

1. C3 AIと組み事件記録や捜査員のメモを1つにつないだ
2. 過去の令状1,000件超と添付資料も読み込ませた
3. 形の整っていない捜査資料から必要な記述を探せるようにした
4. 法令に沿った令状の文面を自動で作らせた
5. 対象をネット事業者向けと住居の捜索の2種類に絞った

令状を1件仕上げるまでの時間が50%以上短くなった。

捜査員は事件の分析や被害者の特定といった仕事へ時間を回せるようになった。

チョクトー語を第一言語として話す人は300人ほどまで減り、言語と文化が失われる恐れがあった。

翻訳は手作業で、部族の各事業から届く依頼に追いつかなかった。

1. OCI Data Science上でLlamaを言語データで微調整した
2. Oracle APEXで翻訳アプリを作り依頼を取り込む形にした
3. AIエージェントが辞書と検証済みの対訳を参照して下訳を出す
4. 言語学者が下訳を直して承認する流れにした
5. 直した内容はモデルの精度上げに回した

言語学者が1日にさばける翻訳の依頼が2倍になった。

19世紀の新聞のPDFなど手作業ではほぼ無理だった資料からも対訳を取り出せるようになった。

フランスの行政は年間1億件を超える文書を扱い職員は変わり続ける規則を追いながら根拠の条文を示して答える必要があった。

機密のデータを外部の環境に出せない縛りもあった。

1. NVIDIAのGPUを土台に複数エージェントの基盤を組んだ。
2. 職員が自分用のアシスタントを作り庁内の資料につなぐ。
3. NIMでLLMを庁内のサーバーに載せる。
4. NeMo Retrieverで数百万件のファイルを横断して探した。
5. NeMo Guardrailsで偏った出力や有害な出力を止めた。

必要な記述を探す作業は2日から2分になった。

100人規模の導入で月1,000時間が浮き、経済・財務省は1万人に広げて200万ユーロを削減した。

ブラジルの裁判所には2023年の終わりの時点で8,200万件を超える案件が滞っていた。

リオグランデドスル州だけで年6万件ほどの警察の捜査記録が保管され、判断の遅れが続いていた。

1. NVIDIA NeMo Retrieverで社内データベースのRAGを組んだ。
2. 埋め込みと並べ替えをNVIDIA NIMのマイクロサービスとして動かした。
3. 同じ答えが返るようNVIDIA NeMo Guardrailsで動きを縛った。
4. 記録の打ち切りの理由をAIAがやさしい言葉で説明する形にした。
5. 市民の相談内容から案件の種類と担当先をAIに見分けさせた。

巨大なデータベースの中の食い違いを数分で見つけられるようになった。

数か月から数年かかっていた手続きや捜査が1日以内に片づくか前へ進むようになり、州内497の市町村に住む800万人以上が使える形になった。

前例の無い事業の公募要綱を作るとき古いファイルや他の自治体の公開資料を何枚も開いて見比べていた。

使えそうな文言を手で写し法令の名前やつじつまを読み直すため骨組みだけで丸1日以上かかっていた。

1. 他の自治体の公募要綱をPDFなどで何件か集める。
2. 自治体の法務担当者の役割をChatGPTへ与える。
3. 対象の施設と期間と目的を条件で渡す。
4. 章立てと解説文を行政文書の硬い調子で出させる。
5. 自分の役所の条例や規則を当ててドラフトを直す。

公募要綱や長文の仕様書のドラフトができるまでが約6時間〜8時間から1件約2時間程度になった。

週に換算すると約4〜5時間の事務が減った。

過去5〜10年分の工事の復命書や国の補助金交付要領をフォルダから1つずつ目で確認していた。

表記のゆれで検索が効かず起案書のもとを作るだけで丸一日つぶれていた。

1. 今回の修繕に関わる過去の仕様書と補助金基準をCopilotへ読み込ませる
2. 自治体の施設管理の専門家という役割を与える
3. 施工業者の資格要件と再発防止策を3点ずつ箇条書きで出させる
4. 公文書のトーンを指定し資料の中の事実だけを根拠にさせる
5. 出た内容を関係法令と照らし起案書の理由や仕様の欄へ入れる

1件あたり約240分かかっていた仕様書の大枠づくりと決裁文書の準備が約60分になった。

部署全体では週に約6〜9時間分のデスクワークが減っている。

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

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

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

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

重要なインフラ事業の計画と認可の手続きは書類が多く規則も細かい。

法律で決まった期限を6か月以上超えて遅れることが多かった。

1. 担当職員に認可手続きで手間取る点を聞き取った
2. 聞き取りをもとに6社の技術パートナーが機能ごとのモジュールを作った
3. 書類準備から審査や行政文書の下書きまでをAIが支える形にした
4. 既存の行政システムと標準の接続方式でつないだ
5. 出てきた内容は職員が確かめて法的な正しさを保つ

初期の検証では認可の手続きが速くなり質や説明のしやすさも保たれた。

仕組みはオープンソースとして公開し、ノルトライン＝ヴェストファーレン州の手続きから使い始める。

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

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

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

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

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

行政サービスの一覧はサイトにそろっていたが手続きの数と仕組みが複雑で市民はどこから始めればよいか分からなかった。

省庁をまたぐ手続きも多く目的のページを探すだけで手間がかかった。

1. RasaのCALMとStudioで60件分の会話の流れを作った
2. 市民へ短い質問を順に投げて目的の手続きを絞り込む
3. 絞り込んだ手続きの該当ページへ直接送る
4. 言葉の読み取りをAzure環境に置いたGPT-4oに担わせた
5. RAGを組み込み締め切りの細かい質問にも答える

パスポートの更新予約や身分証の更新など60件のサービスに会話から進めるようになった。

市民が省庁ごとのサイトを回らずに目的の手続きへ届くようになり役所側に来る誤った振り分けや書きかけの問い合わせも減った。

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

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

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

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

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

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

住民はサイトを何ページも見て回り、フォームを自分で埋めないと用が済まなかった。

高齢の住民や障害のある住民には入力や検索の負担が大きかった。

1. 公式サイトで認めた情報だけを元にAIに答えさせる
2. Yellow.aiを裏側のシステムとAPIにつなぐ
3. 住民が会話で伝えると311のチケットを自動で作る
4. 英語とスペイン語の両方で始める
5. 窓口が閉まった後は音声AIが電話を受ける

住民はフォームを埋めずに会話だけで通報でき、チケット番号もすぐ受け取れるようになった。

窓口が閉まった後も24時間いつでも受け付けられるようになり、英語とスペイン語の住民にも対応できる。

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

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

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

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

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

10を超えるサイトに数千ページが散らばり住民が欲しい答えにたどり着けなかった。

見つからない人は担当部署へメールするか311の電話窓口にかけていた。

1. Elasticsearchを全サイトの検索と索引の土台に据えた。
2. 外部の技術者と組みRAGで職員向けの対話アシスタントを用意した。
3. 質問ごとに関連する中身を集めGeminiに渡して回答を作らせる。
4. 半年あまり庁内で使ったうえで住民向けの公開版を出した。
5. 公開版は要約と出典リンクを並べて見せる。

対話アシスタントは6か月ででき当初の見込みより30%早く完了した。

311の窓口に置いた公開エージェントは毎日フルタイム4人分を超える量をさばいている。