自治体・公共機関サイトのAI検索対策。広報紙・要綱のPDF依存への対処、1手続き1ページのHTML化、オープンデータ・FAQ設計、AIクローラー方針までを実装チェックリスト付きで整理。
- 自治体 AI検索 対策の定義、実務判断、確認項目をAI検索時代の情報源設計として整理する。
- 公式情報と一次情報を優先し、表示保証や順位改善の断定を避ける。
- 本文、FAQ、内部リンク、llms.txt、構造化データの整合性を継続確認する。
実務で見る観点
各AI検索サービスのクローラー名とrobots.txtでの扱いを公式情報で確認する。
サービス内容、料金、対象者、事例、会社情報を正規ページに集約して矛盾を減らす。
外部メディア、SNS、比較サイトに出ている説明と自社サイトの記述がずれていないか見る。
結論から言うと、自治体・公共機関サイトのAI検索対策で最初にやるべきことは、広報紙・要綱・案内チラシのPDFに閉じ込めている手続き情報を、「1手続き=1ページ」のHTMLとして公開し直し、対象者・条件・期限・窓口・必要書類を本文のテキストで明記することです。新しいシステムを導入することでも、AI向けの特殊なテクニックを探すことでもありません。
住民は今、「粗大ごみの出し方」「児童手当の申請方法」「引っ越したら何をすればいいか」といった行政手続きを、役所に電話する前にChatGPTやGoogleのAIによる概要(AI Overviews)に聞き始めています。このときAI検索は、公式サイト・ポータルサイト・まとめ記事などの公開情報を材料に回答を組み立てます。自治体・公共機関の公式サイトは「制度の一次情報を持つ発信源」であり、AIの回答の材料として本来もっとも参照されるべき立場にあります。ところが実際には、肝心の情報が広報紙PDFや申請書PDFの中にあり、HTML本文が薄いために、AIが古い情報や第三者サイトのあいまいな記述をもとに回答してしまう構造的リスクを抱えています。
この記事では、自治体・公共機関のWeb担当者、広報担当者、DX推進担当者の方向けに、次の4点を整理します。
- 自治体のAI検索対策の定義と、従来のホームページ運用との違い
- 公共サイト特有の「PDF依存」問題:HTML化すべき情報とPDFのままでよい情報の判断基準
- オープンデータ・機械判読・FAQ設計など、公共分野ならではの強みの活かし方
- 実装チェックリストと、自治体サイトでよくある失敗例
LLMO対策の全体像はLLMO対策とは?AI検索時代に企業サイトが確認すべきことで解説しています。本記事は自治体・公共機関という領域に絞った各論です。
自治体のAI検索対策の定義
自治体・公共機関のAI検索対策とは、行政手続き・制度・施設・防災などの一次情報を、ChatGPT、Gemini、Perplexity、GoogleのAIによる概要(AI Overviews)・AIモードなどのAI検索が取得・理解・引用しやすいHTML中心の形式で公開し、住民がAIに質問したときに正確な行政情報が回答に反映される余地を高める情報設計の取り組みです。広報紙PDFや窓口配布資料に閉じた情報を公式サイトの本文へ展開することが中心で、AIへの引用や表示を保証する施策ではありません。
この定義には2つのポイントがあります。
1つ目は、対策の主戦場が「情報の置き場所と形式」だという点です。自治体は制度の一次情報を独占的に持っています。情報がないのではなく、「AIが取得・切り出ししにくい場所と形式にある」ことが問題の中心です。
2つ目は「保証しない」という点です。HTML化も構造化データも、AIの回答に引用されることを約束しません。Googleは、検索表示の要件やベストプラクティスを満たしてもコンテンツの表示が保証されるわけではないと公式に明言しています。できるのは、正確な一次情報が引用候補として使われるための条件を整えることまでです。
なぜ自治体サイトはAI検索で「有利なのに弱い」のか
自治体・公共機関サイトには、AI検索との関係で見ると相反する2つの性質があります。
有利な点:一次情報の権威性が高い
行政手続き・制度・条例・統計は、自治体自身が唯一の正式な発信源です。「〇〇市 粗大ごみ 申し込み」のような質問に対して、公式サイトより信頼できる情報源は原則存在しません。実際、Googleの構造化データ機能の中には、FAQリッチリザルトのように「よく知られた権威ある政府機関・健康関連サイトに限定して表示する」と明記されているものがあり、行政サイトは検索エンジンから特別に権威性の高い情報源として扱われている数少ないカテゴリです。この「一次情報の発信源としての立場」は、企業サイトが時間をかけて獲得しようとするものを、自治体は最初から持っているということです。
弱点1:手続き情報がPDFに閉じている
多くの自治体サイトは、制度の詳細を「広報〇〇 4月号(PDF)」「実施要綱(PDF)」「案内チラシ(PDF)」で公開し、HTMLページには概要1〜2行と担当課の連絡先だけを置いています。事実として、GoogleはPDF(Adobe Portable Document Format)をインデックス可能なファイル形式として公式に挙げており、公開されているPDFが検索対象にならないわけではありません。しかし、広報紙のような多段組みレイアウトのPDFは本文の順序や表の構造が抽出時に崩れやすく、「第〇条により…」形式の要綱は住民の質問文と語彙がかけ離れているため、AIが回答の材料として使いにくい形式です(各AI検索サービスがPDF処理仕様を公開しているわけではないため、この「使いにくさ」の程度は実務上の仮説として扱ってください)。
弱点2:1ページに複数の手続きが同居している
「子育て支援」1ページの中に児童手当・医療費助成・保育所入所・一時預かりがまとめて書かれている構成では、AI検索が「児童手当の申請期限はいつか」という単位で情報を切り出しにくくなります。Googleは、AIモードやAIによる概要で1つの質問を複数のサブトピックに分解して並行検索する「クエリファンアウト」という手法を使う場合があると説明しています。質問が細かく分解されるほど、手続き単位で独立して立っているページのほうが参照対象になりやすい、というのが実務上の考え方です(この因果自体は公式に保証された仕様ではありません)。
弱点3:例規集・施設予約など外部システムに情報が分散している
条例・規則は例規集システム、施設案内は予約システム、ごみ分別は専用アプリと、情報が別ドメイン・別システムに分散している自治体は少なくありません。外部システム側がクローラーのアクセスを想定していない作りだと、その中の情報はAI検索から見えなくなります。少なくとも「制度の説明と結論」は公式サイト本体のHTMLに置き、外部システムは手続きの実行用と割り切る設計が安全です。
弱点4:更新日と年度が本文から読み取れない
行政情報は年度で内容が変わります。ところが「更新日の記載がない」「本文中の年度表記が『今年度』のまま」というページが多く、AIからも住民からも「この情報はいつ時点のものか」が判定できません。AIが古い制度内容を答える事故の温床であり、後述の失敗例でも最頻出のパターンです。
住民がAIに聞く質問パターンと必要な情報設計
住民の質問は、おおむね次の4タイプに整理できます。タイプごとに、AIが回答を組み立てるために必要な情報の形が異なります。
| 質問タイプ | 質問例 | AIが必要とする情報 | 必要な情報設計 |
|---|---|---|---|
| 手続き型 | 「〇〇市で児童手当を申請するには」 | 対象者・条件・期限・窓口・必要書類・オンライン可否 | 1手続き=1ページのHTML。冒頭に結論、本文に条件を箇条書きで明記 |
| ルール型 | 「〇〇市 粗大ごみ 出し方」「ペットボトルは何ごみ」 | 分別区分・収集日・料金・申込方法 | 品目と区分の対応をHTMLの表で公開。PDF一覧表だけにしない |
| 施設・窓口型 | 「〇〇市役所 開庁時間」「図書館 休館日」 | 所在地・開庁時間・休日・電話・アクセス | 施設ごとに基本情報をテキストで統一フォーマット化 |
| 緊急・防災型 | 「〇〇市 避難所 どこ」「給付金 いつ」 | 最新の指定状況・実施状況・日付 | 更新日を明記したHTMLページ。緊急情報を画像やPDFだけで出さない |
共通しているのは、「住民の言葉で書かれた、単独で意味が通るHTMLの記述」が必要だという点です。要綱の条文体(「規則第〇条に定める者」)ではなく、「〇〇市に住民登録がある中学生以下の子どもを養育している方」のように、質問文と同じ語彙で書かれた本文が、AI検索の回答材料になり得ます。
公共サイトのPDF問題:HTML化の判断基準
すべてのPDFをHTML化する必要はありません。限られた人員で運用する前提で、判断基準を先に決めるべきです。
| 情報の種類 | 推奨 | 理由 |
|---|---|---|
| 手続きの対象者・条件・期限・窓口・必要書類 | HTML必須 | 住民の質問に直接答える情報。AI検索の一次材料になるため |
| ごみ分別・収集日・料金などのルール一覧 | HTML必須(表形式) | 品目単位で切り出される質問が多いため。PDF併置は可 |
| 制度の概要・変更点のお知らせ | HTML必須 | 「広報〇月号参照」ではAIも住民も本文にたどり着けないため |
| 申請書の様式そのもの | PDFのままで可 | 印刷・記入が目的の様式はPDFが適切。ただし記入例・提出方法の説明はHTMLに書く |
| 実施要綱・要領の全文 | PDFのままで可 | 正文はPDFでよい。ただし住民向けの要点(誰が・いつまで・いくら)はHTMLに要約する |
| 広報紙(紙面レイアウト版) | PDFのままで可 | 紙面はアーカイブとして残し、掲載記事の中で手続き・制度に関するものはHTML記事化する |
| 議事録・計画書などの長文資料 | PDF+HTML概要 | 全文HTML化は非現実的。概要・結論・決定事項だけHTMLで公開する |
判断の軸はシンプルで、「住民がAIや検索に質問しそうな情報か」です。質問される情報はHTMLへ、参照・保存用の正文や様式はPDFのまま、と切り分ければ、限られたリソースでも優先順位がつけられます。
なお、公的機関サイトには総務省の「みんなの公共サイト運用ガイドライン」(2024年版)が求めるウェブアクセシビリティ(JIS X 8341-3対応)の取り組みがあります。PDF依存を減らしてHTML本文を充実させる方向性は、アクセシビリティ対応とAI検索対策で完全に一致します。AI検索対策を単独の新規事業として起案するより、「アクセシビリティ改善・サイトリニューアルの設計方針に含める」ほうが、庁内の合意も取りやすいはずです。
オープンデータと機械判読:公共分野だけの追い風
自治体には、企業サイトにはない制度的な追い風があります。オープンデータです。
政府の「オープンデータ基本指針」(2024年7月改正)は、オープンデータを「営利・非営利を問わず二次利用可能なルールが適用され、機械判読に適し、無償で利用できる形で公開されたデータ」と定義しています。また、デジタル庁は自治体に公開を推奨するデータ項目とフォーマットをまとめた「自治体標準オープンデータセット」を公開しており、AED設置箇所、避難所、公共施設、子育て施設などのデータを標準フォーマットのCSVで公開する枠組みが既に存在します。
AI検索対策の観点で重要なのは、この「機械判読に適した形式で公開する」というオープンデータの原則が、AI検索が情報を取得・理解しやすい形式と方向として一致していることです。つまり自治体は、オープンデータ推進という既存の政策文脈の中で、AI検索対策の相当部分を進められます。
実務上の注意点は2つあります。
- オープンデータのCSVを公開するだけでは、住民の質問への回答材料としては不十分です。CSVは位置情報・一覧データとして価値がありますが、「避難所はどこか」という質問に対しては、地区ごとの避難所を記載したHTMLページが併せて必要です。データ公開とHTMLページ公開は補完関係として設計してください。
- オープンデータカタログを外部のポータルだけに置き、公式サイトから辿れない状態にしないでください。公式サイト内に「オープンデータ」ページを置き、データセットの説明をHTMLで書き、カタログへリンクする構成が基本です。
FAQ設計:行政サイトが持つ数少ない特権
前述のとおり、GoogleのFAQリッチリザルトは2023年9月のドキュメント更新で「よく知られた権威ある政府機関・健康関連サイトに限定して表示する」と明記されました。一般企業サイトでは事実上表示されなくなった機能が、行政サイトには残されています。リッチリザルトの表示自体はAI検索の引用と別の機能ですが、「Googleが行政サイトのFAQを特別扱いしている」ことは、FAQコンテンツを整備する優先度を判断するうえで十分な材料です。
FAQ整備の実務ポイントは次のとおりです。
- 質問文は住民が実際に使う言葉で書く。「転入届の提出期限を教えてください」ではなく「引っ越してきたら何日以内に手続きが必要ですか」のように、窓口・電話で実際に受けている質問の言い回しをそのまま使う。
- 回答は単独で意味が通る完結した文で書く。「上記のとおりです」「担当課へお問い合わせください」だけの回答は、AIにとっても住民にとっても材料になりません。結論(期限・金額・窓口)を回答の1文目に書きます。
- FAQは見出しと本文で構成する。質問を見出し、回答を本文として、ページ内で読める形にします。構造化データを併用する場合も、本文に見えている内容と一致させることがGoogleの構造化データポリシーの要件です。
FAQと構造化データの詳しい設計はAI検索に効くFAQと構造化データの作り方と構造化データとAI検索の関係で解説しています。
AIクローラーへの方針:遮断の判断は用途別に
自治体のセキュリティ担当から「AIボットは全部遮断すべきでは」という論点が出ることがあります。ここは用途別に分けて判断すべきです。
OpenAIは、ChatGPTの検索機能でサイトを表示するためのクローラー「OAI-SearchBot」を、基盤モデル学習用の「GPTBot」とは別に公開しており、robots.txtで個別に制御できます。PerplexityもPerplexityBot(検索結果でのサイト表示用で、AI学習用ではない)とPerplexity-User(ユーザーの質問起点の取得)を分けて公開しています。つまり「学習には使わせないが、住民がAIで検索したときには公式情報を参照させる」という制御が技術的に可能です。
公共情報はそもそも広く周知することが目的の情報であり、検索用クローラーまで一括遮断すると、住民がAIに質問したときに公式情報が参照されず、第三者のまとめサイトや古い情報が回答の材料になるリスクを自ら高めることになります。遮断・許可の設計はrobots.txtのAIクローラー設定にまとめています。CDN・WAF側のボット対策設定がrobots.txtより先にアクセスを遮断しているケースもあるため、インフラ担当・委託事業者と設定の実態を確認してください。
AIが古い制度を答える問題への対処
自治体にとってAI検索の最大のリスクは、「引用されないこと」ではなく「古い情報・誤った情報で回答されること」です。終了した給付金、変更前の受付時間、廃止された制度をAIが答えれば、窓口への問い合わせ増加や住民の不利益に直結します。
対処の基本は次の3つです。
- すべての制度・手続きページに更新日と対象年度を明記する。「今年度」ではなく「2026年度(令和8年度)」と書く。
- 終了した制度のページは削除せず、「この制度は2026年3月31日で終了しました」という現在形の結論を冒頭に追記して残す。ページを消すと、AIも住民も「終了した」という事実にたどり着けず、第三者サイトの古い記述だけが残ります。
- 自分の自治体名でAIに質問して、回答を定点確認する。「〇〇市 児童手当 申請」「〇〇市 ごみ 分別」などの代表的な質問をChatGPT・Gemini・Perplexityに投げ、回答の正誤と参照元を記録します。確認の観点はAI検索でブランド名を調べた時に確認すべき回答パターン、誤りを見つけた場合の直し方はAIが自社情報を間違えて答える時の修正方法が自治体名でもそのまま使えます。
情報の鮮度管理・リライト運用の考え方はAI検索時代のコンテンツ更新戦略を参照してください。
実装チェックリスト
自治体・公共機関サイトでまず確認すべき項目です。委託事業者への指示書としても使えるよう、確認方法まで書いています。
| 領域 | チェック項目 | 確認方法 |
|---|---|---|
| 情報設計 | 主要手続きが「1手続き=1ページ」のHTMLで存在するか | 転入・転出、児童手当、ごみ分別、住民票、避難所など問い合わせ上位20手続きのURL一覧を作る |
| 情報設計 | 各手続きページの冒頭に対象者・期限・窓口・必要書類が本文テキストで書かれているか | ページを開いて最初の1画面で「誰が・いつまで・どこで・何を持って」が読めるか確認 |
| 手続きの条件・期限がPDFにしか書かれていないページがないか | 「詳しくは広報をご覧ください」「チラシ参照」だけのページを洗い出す | |
| スキャン画像だけのPDF(テキスト選択不可)が現役の案内に使われていないか | PDFを開いて本文がテキストとして選択・コピーできるか確認 | |
| 鮮度 | 制度・手続きページに更新日と対象年度が明記されているか | 主要ページの更新日表記と本文中の年度表記を確認 |
| 鮮度 | 終了した制度のページに「終了した」旨が冒頭で明記されているか | 終了済み給付金・イベントのページを検索して現状を確認 |
| クローラー | robots.txtとWAFがOAI-SearchBotなど検索用AIクローラーを意図せず遮断していないか | robots.txtの記述確認と、委託事業者へのWAF/CDNボット設定の照会 |
| クローラー | 例規集・施設予約など外部システムにしかない住民向け情報がないか | 外部システム内の情報のうち、質問されやすい結論を公式サイトHTMLに転載する |
| FAQ | 問い合わせの多い質問がFAQとしてHTMLの見出しと本文で公開されているか | コールセンター・窓口の問い合わせ記録の上位から作成する |
| データ | 避難所・施設などのオープンデータが公開され、対応するHTMLページと相互にリンクしているか | 自治体標準オープンデータセットの推奨項目と公開状況を突き合わせる |
| 計測 | AI検索経由の流入を計測する準備があるか | アナリティクスでAI検索サービスからの参照元を確認する(設定方法は本文下のGA4計測記事を参照) |
より汎用的な監査手順はLLMO監査チェックリストに、流入計測の設定手順はGA4でAI検索流入を計測する方法にまとめています。
自治体サイトでよくある失敗例
失敗例1:リニューアルでURLを一斉変更し、リダイレクトを設定しない
CMS更改のタイミングで全ページのURLが変わり、旧URLからの転送(リダイレクト)を設定しないまま公開してしまうケースです。検索エンジンとAIが蓄積してきた「このURLにこの情報がある」という評価が失われ、しばらくの間、古いキャッシュや第三者サイトが回答の材料になりやすくなります。リニューアル時の注意点はサイトリニューアルでLLMO評価を失わない移行手順で詳しく解説しています。
失敗例2:緊急情報を画像・PDFだけで発信する
災害時の避難情報や給付金の案内を、庁内で作ったチラシ画像やPDFをそのまま貼って発信するパターンです。画像の中の文字はテキストとして取得できず、AI検索からも読み上げソフトからも見えません。緊急性が高い情報ほど、まずHTMLのテキストで出すことを運用ルールにしてください。
失敗例3:「詳しくはお問い合わせください」で本文を終わらせる
ページに制度名と担当課の電話番号だけを載せ、条件や金額を書かないパターンです。電話問い合わせを前提とした昭和型の情報設計であり、AIは回答材料を持てず、住民は結局電話することになります。本文に結論を書くことは、問い合わせ対応の負担軽減という庁内メリットとしても説明できます。
失敗例4:構造化データだけ先に実装する
委託事業者の提案で構造化データ(FAQPageなど)だけを実装し、本文の中身を変えないパターンです。Googleの構造化データポリシーは、マークアップの内容がページ本文に見えている内容と一致することを求めており、本文が薄いままの構造化データは効果の前に要件を満たしません。順序は必ず「本文の充実→構造化データ」です。
失敗例5:AI検索対策を単発事業として外注し、運用が残らない
「AI対応リニューアル」を単年度事業で外注し、納品後に更新運用が設計されていないケースです。行政情報は年度ごとに変わるため、更新が止まった瞬間から「古い情報を答えさせるリスク」が増え始めます。内製と外注の分担設計はLLMO対策の内製と外注の分け方が参考になります。
よくある質問
小規模な自治体でも取り組む意味はありますか
あります。むしろ小規模自治体ほど、公式サイト以外にその自治体の手続きを正確に説明する情報源が少ないため、公式サイトの記述がAIの回答を左右する度合いが相対的に大きくなります。問い合わせ上位の手続き20件に絞ってHTMLページを整えるだけでも、対象範囲は十分に意味を持ちます。
広報紙のPDF公開はやめるべきですか
やめる必要はありません。紙面PDFはアーカイブ・閲覧用として残し、その号に掲載した手続き・制度の記事をHTMLページとしても公開する「二層構成」が現実的です。判断基準は本文の判断表のとおり、「住民が質問しそうな情報かどうか」です。
AIに公式情報を必ず引用させる方法はありますか
ありません。どのAI検索サービスも、特定サイトの引用や表示を保証する仕組みを提供していません。できるのは、取得可能な形式で正確な一次情報を公開し、更新日を明示し、引用候補としての条件を満たし続けることまでです。「必ず引用される」とうたう提案は、その時点で根拠を確認すべきです。
効果はどう確認すればよいですか
2つの軸で確認します。1つ目は回答品質の定点確認で、代表的な住民質問をChatGPT・Gemini・Perplexityに定期的に投げ、回答の正誤と参照元を記録します。2つ目は流入計測で、アナリティクス上でAI検索サービスからの参照流入を確認します。どちらも「改善を保証する数値」ではなく、「誤情報リスクと到達状況を把握する運用指標」として扱ってください。
まとめ:自治体サイトは「AIに正しく引用される責任」を持つ
自治体・公共機関サイトのAI検索対策を整理します。
- 自治体は行政情報の唯一の一次発信源であり、AI検索の回答材料として本来もっとも参照されるべき立場にある
- 弱点はPDF依存・ページ分割不足・更新日不明の3つに集約される。対策の中心は「1手続き=1ページのHTML」「結論を本文テキストで明記」「年度と更新日の明示」
- オープンデータの機械判読原則とウェブアクセシビリティ対応は、AI検索対策と方向が一致する。既存の政策文脈に載せて進められる
- 最大のリスクは引用されないことではなく、古い情報で回答されること。終了制度の明示と定点確認を運用に組み込む
企業のマーケティングと違い、自治体にとってこの取り組みは集客ではなく、住民への正確な情報提供という本来業務の延長です。だからこそ、「AIに聞かれたとき、正しい情報が使われる状態か」を一度点検する価値があります。
自組織のサイトがAI検索からどう見えているか、どこから手をつけるべきかを整理したい場合は、AI検索攻略のLLMO診断で現状確認の観点を提供しています。公共サイトの構造的な課題(PDF依存・外部システム分散・更新運用)は外形から診断しやすい領域なので、庁内での起案材料としても活用してください。
公式情報で確認するポイント
AI検索まわりは仕様変更が多いため、記事公開前後に公式情報を確認し、本文の言い切りや実装方針を更新します。
- Google Search Central「Optimizing your website for generative AI features」 生成AI検索に対して、通常のSEO・技術要件・独自性の扱いを確認する公式ガイド。
- Google Search Central「Creating helpful, reliable, people-first content」 人間に役立つ信頼性の高いコンテンツを評価するための公式観点。
よくある質問
この記事の検索意図に対して、相談前に確認されやすい論点を短く整理しています。
この記事では何を確認できますか?
自治体・公共機関サイトのAI検索対策。広報紙・要綱のPDF依存への対処、1手続き1ページのHTML化、オープンデータ・FAQ設計、AIクローラー方針までを実装チェックリスト付きで整理。
どのページから見直すべきですか?
トップ、サービス、事例、FAQ、会社情報、関連メディア記事の順に、読者が確認したい情報と内部リンクのつながりを見ます。
相談前に準備するものはありますか?
主要ページ、問い合わせが多い質問、既存記事、外部掲載情報、現在のllms.txtや構造化データの有無を整理しておくと確認が進めやすくなります。
本体メディアであわせて確認する記事
この記事のテーマを、Uravation本体メディアで検索流入のあるAIツール・モデル解説にもつなげて確認できます。
生成AI・AI検索・SEOの公開情報を確認しながら、企業サイトの情報設計として実務で扱える形に整理しています。仕様変更が多い領域のため、公開前後に公式情報と本文の整合性を確認します。
AI検索診断・情報源設計支援に進める
この記事のテーマを自社サイトに当てはめ、公開情報、根拠ページ、FAQ、内部リンク、構造化データ、llms.txtのどこを確認すべきかを整理します。
AI検索攻略の前後の記事
同じ連載の前後の記事へ進み、LLMO、AIO、GEO、AI検索の論点を順番に確認できます。
関連するUravationの導線
AI検索攻略は、Uravation本体のAI活用メディアとサービス導線につながる専門テーマとして運用します。