LINE申請の住所表記揺れをAIで吸収する — 自治体水道システムの実装事例

1. はじめに

C-tableでは、市役所向けにLINEから水道の開閉栓申請ができるシステムを開発・提供しています。住民の方が引っ越しのたびに窓口へ行く必要がなくなり、スマートフォンから手軽に申請できる仕組みです。

しかし運用開始後、ひとつ大きな課題が顕在化しました。利用者が入力した住所と、市役所側が保持する水道マスタの住所がほとんどマッチしないのです。自動突合のヒット率はわずか1%程度で、残る99%は水道課職員が目視で突合する手作業に頼っていました。

この課題を、ベクトル検索とLLMを組み合わせた2段構えのアプローチで解決し、ヒット率を約80%まで引き上げることができました。さらに、1件あたりの突合時間は 3〜5分から1分へ短縮、今年3月には LINE申請率が7割に達し、対面申請（3割）を初めて大きく上回る という成果にもつながっています。本記事では、その設計判断と実装の勘所を共有します。

2. 背景：水道開閉栓申請と住所突合の業務

水道の開閉栓申請は、引っ越しや長期不在などのタイミングで必要になる手続きです。従来は窓口や電話での受付が主流でしたが、LINE申請に切り替えることで住民の利便性は大きく向上します。

一方、市役所側の業務フローは次のようになります：

利用者がLINEで開閉栓申請
    ↓
申請住所と水道マスタを突合
    ↓
お客様番号を特定
    ↓
水道課職員が開閉栓処理

このなかで 「お客様番号の特定」 が自動化のボトルネックでした。自動で特定できなければ、申請が来るたびに職員が住所を見比べてマスタから該当者を探すことになります。申請件数が増えるほど職員の負荷が積み上がり、せっかくのデジタル申請が業務改善に直結しない、というジレンマが生じていました。

自治体DXの文脈では、既存の基幹システム（水道マスタ）はそのままに、住民接点だけを新しくすることがよくあります。その際、「既存マスタを活かしたまま、新しい入力経路と繋ぐ」 という地味ながら重要な工程が、プロジェクトの成否を分けます。

3. なぜ住所突合は難しいのか

実際の申請データと水道マスタを並べてみると、課題の本質が見えてきます。

人間が見れば「同じ住所だな」と判断できます。しかし、表記揺れのパターンは多岐にわたり、全角半角、記号、丁目・番地、建物名、棟・号室、スペースの有無など、挙げればきりがありません。

これらをルールベースの正規化で網羅しようとすると、例外処理が無限に発生します。建物名の英数字・カタカナ・ローマ数字の揺らぎまで考え始めると、ルールだけで解決するのは現実的ではありません。

人間なら一瞬で判断できるこの「意味的な同一性」を、いかに機械に委ねるか。ここが設計の出発点でした。

4. 解決アプローチ：なぜ「ベクトル検索 × LLM」の2段構えにしたか

検討したアプローチを整理します。

採用の決め手は、次の2点です。

1. LLMに全件は渡せない
水道マスタには数万件の住所が登録されています。これを毎回LLMに渡して判定させるのは、コストもレイテンシも現実的ではありません。

2. ベクトル検索だけだと誤マッチが怖い
ベクトル検索は「似ている住所」を高速に見つけてくれますが、類似度スコアだけで最終判断をさせると、番地だけ違う別の住所を誤って選んでしまうリスクがあります。水道の開閉栓は誤操作が許されない業務なので、このリスクは看過できません。

そこで、安くて速いベクトル検索で候補を絞り込み、意味理解が必要な最終判断だけLLMに任せる という2段構えに行き着きました。それぞれの得意領域を活かす設計です。

5. 実装の仕組み

全体フロー

利用者入力住所
    ↓
① ベクトル化（Embedding）
    ↓
② ベクトルDBで水道マスタと類似度検索
    ↓
③ 上位100件を候補として抽出
    ↓
④ LLMのプロンプトに候補100件を渡す
    ↓
⑤ LLMが最も妥当な1件（またはマッチなし）を返す
    ↓
お客様番号を特定

事前準備：水道マスタのベクトル化

システム稼働前に、水道マスタの全住所をEmbeddingモデルでベクトル化し、ベクトルDBに格納します。マスタが更新されたタイミングで再インデックスできるよう、バッチ処理も組み込んでおきました。

ポイントは 「マスタ側のデータをどう整形してからベクトル化するか」 です。生のマスタデータをそのまま投入するよりも、住所・建物名・部屋番号といった構成要素を意識した形で埋め込むほうが、後段の検索精度が安定します。

ステップ①②：ベクトル検索で100件に絞る

申請が届いたら、入力住所をEmbeddingし、ベクトルDBに対して類似度検索を実行します。ここで上位100件を候補として取得します。

なぜ100件なのか？ これはチューニングの末にたどり着いた数字です。

• 件数が少なすぎると、正解候補が漏れる（Recallが落ちる）
• 件数が多すぎると、LLMに渡すトークンが増えてコスト・レイテンシが悪化し、かつLLMの判定精度も落ちる

過去の申請データで検証しながら、「正解がこの件数に含まれる確率」と「LLMが正しく選べる確率」のバランスが取れる点として100件に設定しました。

ステップ③④：LLMに最終判断させる

絞り込んだ100件をLLMのプロンプトに並べ、「この入力住所に最も合致するものを1件選べ。該当がなければ『該当なし』と返せ」という形で判定を依頼します。

プロンプト設計で特に意識したのは次の点です：

• 候補の並べ方：類似度順に並べつつ、番号をつけてLLMが参照しやすくする
• 「該当なし」を返させる余地：無理にマッチさせず、怪しければ人手に回す
• 出力フォーマットの厳密化：JSONで返させ、パース失敗をなくす
• 判断根拠の出力：なぜその候補を選んだかを短く書かせ、後から検証可能にする

「惜しい候補」が並んだときほど誤マッチが起きやすいので、プロンプトで慎重さを促す設計 が肝になります。

ステップ⑤：ヒットしなかった場合のフォールバック

LLMが「該当なし」を返した場合、あるいは信頼度が閾値を下回る場合は、職員の手作業キューに回す ようにしています。

ここが重要な設計判断で、「AIで100%自動化する」ことを目指していません。80%を自動化して、残り20%は人が判断する。このハイブリッドが、自治体業務で求められる確実性とのバランス点だと考えています。

6. 検証結果

過去900件の実申請データで検証したところ、次の結果が得られました：

職員の処理時間が最大1/5に

特に現場でインパクトが大きかったのは、1件あたりの処理時間の短縮です。導入前は職員が水道マスタを目視で探し、表記揺れを頭のなかで吸収しながら該当者を特定していたため、1件につき 3〜5分 を要していました。

AIによる突合を導入したことで、職員の作業は「AIが提示した候補の確認」に変わり、1件あたり 約1分 で完了するようになりました。申請件数が多い月は、この差が業務全体の余裕を大きく左右します。

住民側の利用率にも変化

業務効率化と並行して、住民側の行動にも変化が現れました。今年3月、LINEからの申請率が7割に達し、対面申請（3割）を初めて大きく上回った のです。

LINE申請が始まった当初は対面が主流でしたが、処理のスムーズさ・折り返し連絡の速さといった体験が口コミ的に広がり、住民が自然とLINEを選ぶようになっていったと考えています。裏側の突合精度が上がることで、表側の住民体験も滑らかになる という好循環が生まれた形です。

ヒットしなかった20%の傾向

ヒットしなかった20%については、次のような傾向が見られました：

• 建物名が水道マスタと大きく異なる（通称名で入力されている等）
• 新築物件でマスタ未登録
• 入力ミス（番地の桁違いなど）

これらは住所情報だけでは解決しづらく、マスタ側のメンテナンスや入力UIの改善と組み合わせて対応していく領域です。

7. ハマりどころ・学び

実装を通じて見えてきたハマりどころも共有しておきます。

1. 100件という数字の決定に時間がかかった
50件、100件、200件と振ってみて、それぞれのヒット率とコストを比較する検証をしました。データセットによって最適値は変わるので、似たシステムを組む際も実データでチューニングすることをおすすめします。

2. 「惜しい候補」の誤マッチが最後まで残る
番地だけ違う、棟だけ違う、といったケースは人間でも迷います。プロンプトで慎重さを促しても完全には防げないので、最終的には信頼度閾値で人手に回す設計にしました。

3. マスタ側のデータ品質が精度の天井を決める
どれだけAIを工夫しても、マスタ側の表記が統一されていなければ精度は頭打ちになります。AI導入と並行して、マスタデータのクレンジングも進める価値があります。

8. まとめと今後

本事例で得られた知見は、住所突合以外の業務にも応用可能です。

• 顧客マスタの名寄せ
• 問い合わせの自動振り分け
• 商品マスタと受注データの突合
• 類似文書の検索・紐付け

いずれも 「ベクトル検索で絞る → LLMで最終判断」 の2段構えが効く領域です。全件をLLMに投げるのは現実的でない、かつ類似度だけでは判断しきれない、という制約がある業務には特に有効だと感じています。

C-tableでは、こうした 「既存システムを活かしながら、住民・利用者との接点をAIで滑らかにする」 アプローチで、自治体や中小企業のDXを支援しています。同様の課題をお持ちの自治体・企業のご担当者様は、ぜひお気軽にお問い合わせください。

本事例についてのお問い合わせは、C-tableまで。