市役所のホームページのよくある質問を、住民がふだん使う言い方でも引けるようにし、0件だった検索語の記録から同義語辞書の追加案を毎月作る

処理の起点を決める

毎月1日の朝に、前月分をまとめて動かします。 0件の検索語は日々出ますが、1件ずつ動かすと、同じ言い方の別の書き方がまとまらないまま追加案になります。 1か月分を集めてから、表記をそろえて数えます。

承認の締切は、毎月15日に置きます。 承認された分だけをその日に辞書へ反映し、返事の無い課の追加案は翌月に持ち越します。 返事を待って全体を止めないようにします。

臨時の起点も1つ用意します。 大きな制度の始まりや災害のときは、新しい言い方の検索が急に増えます。0件の件数が前の週の数倍になったら、その週の分だけを同じ手順で回します。

入力データを集める

質を決めるのは、4行目の過去の判断です。 一度却下した言い方を、AIは毎月同じように提案してきます。却下の理由と一緒に渡すと、同じ提案が止まります。

5行目の確認用の検索語は、最初に200組ほど作ります。 「住民票」「ごみ 収集日」「保育園 申込」のように、件数の多い検索語と、そのとき出るべきFAQの組です。これが、同義語を足しても他の検索が崩れないことを確かめる物差しになります。

データの取得方法を決める

候補を2つの索引から取るのは、0件の理由が2通りあるからです。 1つは「ごみ大きい」のように語の切れ目が合わないもの、もう1つは「赤ちゃん お金」のように言葉そのものが違うものです。前者は文字の重なりで、後者は言葉の一部の一致で拾います。

文字の重なりで探す項目は、次のように作ります。

PUT /faq
{
  "settings": {
    "index.max_ngram_diff": 1,
    "analysis": {
      "tokenizer": {
        "faq_bigram": { "type": "ngram", "min_gram": 2, "max_gram": 3, "token_chars": ["letter", "digit"] }
      },
      "filter": {
        "faq_synonyms": {
          "type": "synonym_graph",
          "synonyms_path": "analyzers/F111111111",
          "updateable": true
        }
      },
      "analyzer": {
        "faq_ja_index":  { "type": "custom", "tokenizer": "kuromoji_tokenizer" },
        "faq_ja_search": { "type": "custom", "tokenizer": "kuromoji_tokenizer", "filter": ["faq_synonyms"] },
        "faq_ngram":     { "type": "custom", "tokenizer": "faq_bigram" }
      }
    }
  },
  "mappings": {
    "properties": {
      "title": { "type": "text", "analyzer": "faq_ja_index", "search_analyzer": "faq_ja_search",
                 "fields": { "ngram": { "type": "text", "analyzer": "faq_ngram" } } },
      "body":  { "type": "text", "analyzer": "faq_ja_index", "search_analyzer": "faq_ja_search" }
    }
  }
}

min_gram と max_gram の差は、既定で1までです。 差を広げるときは index.max_ngram_diff を上げます。synonyms_path の値は、パッケージを関連付けたときに表示される識別子です。

同義語は search_analyzer の側にだけ入れます。 索引を作るときの解析器に入れると、辞書を変えるたびに全部のFAQを入れ直すことになります。

検索語の記録は、検索の画面の側で1回の検索ごとに残します。 残すのは、検索語・日時・結果の件数・1件目に出たFAQの番号だけです。住民を見分ける情報（IPアドレスや閲覧の履歴）は、この記録に入れません。 振り返りに要るのは「どの言葉で0件だったか」だけだからです。

試験の結果は、追加案ごとに次の形で残します。

{
  "rule": "引っ越し, 転居 => 転入, 転出",
  "checked_queries": 200,
  "broken": [
    { "query": "転出 証明", "expected_faq": "FAQ-0312", "rank_before": 1, "rank_after": 4 }
  ],
  "new_hits": [ { "query": "引っ越し 手続き", "top_faq": "FAQ-0311" } ]
}

broken が空でない追加案は、承認の一覧で赤く表示します。 new_hits は、その追加案で0件だった検索語がどのFAQに当たるようになるかを示し、担当課が承認の前に結果を目で確かめる材料にします。

AIへ渡す前に整形する

1. 表記のそろえ … 全角と半角、大文字と小文字、前後の空白、記号をそろえ、同じ検索語として数えます
2. 個人の情報の除外 … 4桁以上の数字の並び、電話番号やメールアドレスの形、住所の番地らしい並びを含む検索語は、本文を捨てて件数だけを残します
3. 件数の足切り … 前月に1回しか出なかった検索語は、翌月に持ち越して2か月分で数えます
4. 既知の言い方の除外 … いまの同義語辞書と、過去に却下した言い方に当たる検索語を分けておきます
5. 候補の取得 … 検索語ごとに、ngram と kuromoji の2つの項目からFAQの候補を20件ずつ取り、重複を除きます

2番目は、AIに渡す前に必ずプログラムで行います。 検索窓に打ち込まれた氏名や番号は、住民が誤って入れたものです。AIに渡さず、記録の上でも本文を残しません。 除いた件数だけを月の報告に載せます。

3番目を省くと、打ち間違いの検索語が追加案の大半を占めます。 1回きりの打ち間違いを同義語にしても、次に同じ打ち間違いをする住民はほとんどいません。

AIに処理させる

させるのは、0件の検索語ごとに扱いを分け、同義語の追加案と根拠のFAQを書くことです。 扱いは次の6つに分けます。

4行目がいちばん起きやすい失敗です。 「手当」で0件だった検索語に、AIは「手当, 児童手当」と書きます。そうすると、障害や介護の手当を探した住民にも児童手当のFAQが上に出ます。 広い語は one_way で、どの制度にも当てはまる一覧のページへ向けるか、追加しないかを担当課が選びます。

指示内容を固定する

あなたは市役所のホームページの担当で、住民がFAQの検索で0件だった言葉を振り返る立場です。
検索語ごとに扱いを分け、同義語辞書の追加案を作ってください。
追加してよいかは決めないでください。決めるのは担当課です。

【扱いの選び方】
- synonym ...... 住民の言い方が、候補のFAQの言葉と同じ意味
- one_way ...... 住民の言い方のほうが意味が広い。「住民の言い方 => FAQの言葉」の一方向にする
- variant ...... 表記ゆれ・送り仮名・略し方の違い
- typo ......... 打ち間違い。同義語にしない
- no_faq ....... 候補の中に当てはまるFAQが無い
- out_of_scope . 市の業務ではない
迷ったら no_faq を選んでください。synonym を選ばないでください。

【厳守事項】
- FAQの番号は、渡した候補の中からだけ選んでください。
- 規則に書く語は、検索語か、候補のFAQの題名・本文に出てくる語だけにしてください。
  どちらにも無い語を足さないでください。
- 「手当」「申請」「届」「証明」「補助」のように、複数の制度にまたがる語を、
  1つの制度の語と同じ扱い（synonym）にしないでください。one_way か no_faq にしてください。
- 過去に却下した言い方は、却下の理由が変わっていない限り提案しないでください。
- 制度の内容を説明しないでください。理由は、なぜこのFAQだと考えたかだけを書いてください。
- 検索語に数字の並びや人の名前らしい語があれば、扱いを out_of_scope にして、内容に触れないでください。

【0件の検索語と件数】{queries}
【検索語ごとのFAQの候補（番号・題名・本文の冒頭・担当課）】{candidates}
【いまの同義語辞書】{current_synonyms}
【過去に却下した言い方と理由】{rejected}

「迷ったら no_faq」と書いているのは、synonym が増えすぎると辞書が壊れるからです。 no_faq の誤りは、担当課がFAQを見て「あるよ」と返せば直ります。synonym の誤りは、承認をすり抜けると全部の検索に効いてしまいます。 誤るなら、直しやすいほうに誤らせます。

規則に書く語を、検索語とFAQの語に限っているのも同じ理由です。 限らないと、AIは気を利かせて「転居, 引っ越し, 移転, 住所変更, 転籍」のように語を足します。「転籍」は戸籍の手続きで、住所の手続きとは別です。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONを受け取ります。

{
  "month": "2026-09",
  "items": [
    {
      "query": "",
      "count": 0,
      "treatment": "synonym | one_way | variant | typo | no_faq | out_of_scope",
      "rule": "",
      "target_faq_ids": [],
      "owner_sections": [],
      "reason": ""
    }
  ]
}

1つ目の理由は、target_faq_ids を照らせることです。 出てきた番号が、その検索語に渡した候補に含まれているかを、プログラムで確かめます。 含まれていなければ、その追加案を除きます。

2つ目は、rule をそのまま試験にかけられることです。 規則は辞書のファイルと同じ書き方の1行で受け取り、プログラムが形式を確かめてから、試験用の索引の解析器に足して、確認用の検索語を検索します。 上位3件から外れたFAQが出たら、その追加案に印を付けます。

3つ目は、owner_sections で承認の宛先が決まることです。 候補のFAQの担当課をプログラムが入れ、承認の依頼は課ごとにまとめて送ります。 1つの追加案が複数の課のFAQにかかるときは、全部の課の承認を要件にします。

システムへ連携する

人が確認する

1. 広報課が全体を見る … 扱いの分かれ方と、試験で印が付いた追加案を先に見ます
2. 担当課が自分の課の追加案を見る … 住民の言い方を、その制度の言葉と同じに扱ってよいかを決めます
3. 却下の理由を書く … 却下するときは、理由を一言書きます。翌月からAIに渡す材料になります
4. no_faq を課の宿題にする … FAQを足すか、足さないかを決めます
5. 反映の後に確かめる … 反映した翌週に、追加した言い方で実際に検索し、FAQが出るかを見ます

2番目を省かないでください。 「保険証」を「資格確認書」と同じにしてよいか、「はんこ」を「印鑑登録」と同じにしてよいか。制度の担当でないと、言い換えてよい範囲が分かりません。

目標は、600件をならして1件2分です。 typo と out_of_scope は件数を見るだけで終わり、synonym と one_way は候補のFAQと試験の結果を見て数分かかります。

例外に対処する

記録を残す

• 前月の0件の検索語と件数（個人の情報を除いた後のもの）と、除いた件数
• 検索語ごとに渡したFAQの候補
• Claude API の出力と、使った指示の版
• 試験の結果（崩れた確認用の検索語と順位）
• 担当課の承認・却下と理由、承認した日と担当
• 反映した辞書の版と日、パッケージの適用の記録

辞書の版を残すのは、戻せるようにするためです。 反映した後に苦情や問い合わせが増えたら、前の版に戻して、どの規則が原因かを試験用の索引で探します。