自治体GEO（Generative Engine Optimization）完全体系化ガイド AI時代の自治体情報インフラ設計学 ― 「検索される」から「AIに引用される」への転換

はじめに ― なぜ今、「自治体GEO」なのか

「市役所のホームページに載っているはずなのに、AIに聞いたら全然違う情報が返ってきた。」

2025年以降、こうした声が自治体窓口の職員から、市民から、そして行政DX担当者から急速に増えている。ChatGPTやGoogle AI Overviews、Perplexityといった生成AIサービスが市民の「調べる」行動を根底から変えた結果、行政情報の「届け方」は新たな危機に直面している。

これは単なるWebサイトのデザイン問題でも、SEO対策の不足でもない。AI時代における「公共情報インフラの構造的欠陥」の問題だ。

本ドキュメントは、その構造的問題を解決する新しい概念「自治体GEO（Generative Engine Optimization）」を日本で初めて本格的に体系化したものである。GEOとは、AIによる情報生成・要約・引用のプロセスに最適化された情報設計の総体だ。SEOが「Googleの検索結果で上位表示されること」を目的としたとすれば、GEOは「AIが市民の質問に回答する際に、その自治体の正確な情報が引用・参照されること」を目的とする。

自治体のWebサイトがいくら充実していても、AIに読み取られなければ市民に届かない時代が来た。本書はその危機を乗り越えるための、実務に直結する理論書・ガイドラインとして機能することを目指している。

---

第1章　自治体GEOとは何か ― 定義と射程

1-1　GEO（Generative Engine Optimization）の定義

GEO（Generative Engine Optimization）とは、ChatGPT・Gemini・Claude・Perplexityなどの「生成AIエンジン」が情報を検索・要約・回答する際に、特定の情報源が正確に引用・参照されるよう最適化する設計手法の総称である。

従来のSEO（Search Engine Optimization）が「Googleなどの検索エンジンのランキングアルゴリズムに最適化し、検索結果の上位表示を目指す」ものであったのに対し、GEOは「生成AIが自然言語で質問に回答する際の情報参照プロセス」に最適化するものだ。

行政情報の文脈でGEOを定義するならば、次の通りになる。

「市民がAIに行政サービス・手続き・防災情報等を質問した際に、当該自治体が公開している正確・最新の情報がAIによって正しく引用・回答されるよう、Webコンテンツの構造・語彙・更新設計を最適化する実践的方法論」

1-2　SEO・AEO・LLMOとの違い

混同されやすい概念との違いを明確にしておく。

概念	最適化対象	目的	主な手法
SEO	Googleなど検索エンジン	検索結果上位表示	キーワード、被リンク、ページ速度
AEO（Answer Engine Optimization）	FAQ・構造化データ	音声検索・スニペット対応	schema.org、明快な定義文
LLMO（LLM Optimization）	大規模言語モデル全般	LLMの学習・引用対象になること	権威あるソース整備、明解な構造
GEO	生成AIエンジンのRAGプロセス	AIによる回答での引用率向上	構造化・FAQ化・定義型文章・API化
自治体GEO	上記全てを行政情報に特化適用	市民へのAI回答の正確性確保	全手法＋公共情報固有の設計原則

SEOとGEOは対立するものではなく、SEO対策が施されたページはGEO対応の土台になる。ただし、GEOはSEOの上位互換ではなく、別次元の最適化だ。検索エンジンは「どのページが上位か」を返すが、生成AIは「何が正しい答えか」を返す。その判断プロセスは根本的に異なる。

1-3　なぜ自治体で特に重要なのか

民間企業のWebサイトとは異なり、自治体情報は次の特徴を持つ。

第一に、「情報の公共性」だ。市民が誤った行政情報に基づいて行動した場合、申請漏れ・期限切れ・避難行動の誤り等、実害が生じる。民間の製品情報と異なり、行政情報の誤引用は市民の権利侵害に直結する。

第二に、「情報の複雑性と量」だ。一般的な自治体のWebサイトは数千ページを超える。国民健康保険・介護保険・育児支援・生活保護・建設許可・選挙など、専門的かつ相互参照が多い情報が膨大に存在する。AIがこれを正確に処理するためには、構造化された情報設計が不可欠だ。

第三に、「情報更新の頻度」だ。補助金の締め切り・避難指示の発令・条例改正など、リアルタイムに更新が必要な情報が多い。AIが古い情報を引用することの危険性は、自治体情報において特に深刻だ。

第四に、「デジタルデバイドの問題」だ。高齢者・障害者・外国人住民など、AIを主な情報アクセス手段として使う層が拡大している。AIが正しい自治体情報を提供できるかどうかが、社会的弱者の行政サービス到達率に直結する。

1-4　「検索される自治体」から「AIに引用される自治体」への転換

GoogleのAI Overviews導入以降、検索結果の上位に表示されても「ゼロクリック」のケース、すなわちAIが検索結果ページ上で直接回答してしまいユーザーがサイトを訪問しないケースが急増している。これは自治体サイトにとって深刻な問題だ。

従来：市民が「宜野湾市 子育て支援金 申請方法」と検索 → 市のWebページへアクセス → 情報取得
AI時代：市民がChatGPTに「宜野湾市の子育て支援金の申請方法を教えて」と質問 → AIが回答 → 市のWebページへアクセスしない（またはしにくい）

この構造変化において、「自治体サイトに良い情報がある」だけでは不十分になった。「AIが正しく引用できる形で情報が整備されている」ことが新たな必須条件になったのだ。これが自治体GEOの本質的な問題意識である。

---

第2章　なぜ今重要なのか ― AI検索時代の変化と行政情報への影響

2-1　生成AIエンジンの台頭と行政情報アクセスの変容

2023年のChatGPT急拡大から3年が経過した2026年現在、生成AIは市民の情報アクセス行動を根底から変えた。主要プラットフォームの状況を整理する。

ChatGPTは月間ユーザー数が5億人を超え、「ちょっと調べる」行動の主要窓口となった。「〇〇市の粗大ゴミ収集の申し込み方法」「育児休業中の保険料はどうなる？」といった行政情報への質問が、日常的に投げかけられている。

Google AI Overviewsは、Google検索結果の最上部にAIによる回答要約を表示する機能だ。自治体公式サイトの情報が正しく構造化されていなければ、AI Overviewsに誤情報が掲載されるリスクがある。逆に正しく最適化されていれば、検索ページ最上部に公式情報が表示される。

Perplexityは「回答に引用元を明示するAI検索」として急速に普及しており、情報リテラシーの高い20〜40代に使われやすい。引用元として自治体公式サイトが選ばれるためには、権威性と構造的明確さが求められる。

Claudeは長文読解・法律文書・手続きの複雑な解釈など、行政に関する高度な質問への回答に多用されている。

さらにAIエージェントの登場により、市民が「育児支援の申請書を記入して提出する」という一連の作業をAIが代行する時代が近づいている。この段階では、自治体のシステムがAPI経由でAIと連携できるかどうか、GEO対応は情報設計を超えてシステム設計の問題になる。

2-2　分野別の影響：何が変わるか

災害情報

最も深刻な影響が生じる分野だ。台風接近時に「〇〇市の避難所はどこか」「今すぐ避難が必要か」をAIに問い合わせる市民が増えている。AIが古いPDF情報をもとに誤った避難所情報を返した場合、人命に関わる。

実例として、2025年の台風シーズンに複数の自治体で、AI検索に表示された避難所情報と実際の開設情報が一致しないケースが報告されている。これはAIが古いページをキャッシュしていたこと、かつ自治体のリアルタイム更新情報がAIに読み取りにくい形式（JavaScript動的描画等）で提供されていたことが原因だ。

子育て支援

「保育園の申し込み方法」「児童手当の金額」「育休中の社会保険はどうなる」といった質問は、AIへの問い合わせが最も多い行政情報のひとつだ。これらは年度ごとに改定されることが多く、AIが古い情報を引用するリスクが高い。

福祉・介護

高齢者本人ではなく家族や介護事業者がAIを使って情報収集するケースが多い。「要介護認定の申請方法」「デイサービスの補助はいくら出るか」などの情報が不正確にAIから提供されると、制度利用の機会損失につながる。

観光・移住促進

観光客が旅行前に「〇〇市の観光スポット」「移住支援金の条件」を生成AIで調べるケースが増加している。自治体の移住促進担当者からは「移住相談の問い合わせ自体は増えているが、AIが伝えた条件と実際の制度が違うと言う人が増えた」という声が聞かれる。

補助金・給付金

「〇〇市で使える補助金は何があるか」という質問は、AIにとって最もリスクの高い行政情報だ。補助金は予算年度で変わり、申請期限が厳格で、要件も複雑だ。AIが古いまたは誤った補助金情報を回答することで、市民が申請機会を逃すケースが現実に起きている。

---

第3章　自治体サイトの根本問題 ― なぜAIが理解しにくいのか

3-1　PDF依存の構造的問題

日本の自治体サイトの最大の問題は「PDF依存」だ。申請書・手続き案内・制度説明のほとんどがPDFで提供されており、HTMLページとして整備されていない。

AIがRAG（Retrieval-Augmented Generation / 検索拡張生成）プロセスで情報を取得する際、PDFは原則としてテキスト抽出が必要になる。スキャンPDF（紙をスキャンした画像PDF）はテキスト抽出自体が不可能な場合が多く、AIはその内容を読み取れない。

さらにPDFは更新履歴が不透明だ。「いつ作られた情報か」「最新版かどうか」が外部から判断しにくく、AIは新旧の区別ができない。

3-2　情報分断と縦割り構造

多くの自治体サイトは「部署ごとのWebサイト」の集合体になっている。子育て支援の情報は子育て支援課、保育施設の情報は保育幼稚園課、教育関係は教育委員会、と情報が縦割りで分断されている。

市民の目線では「子どもの保育・教育に関する支援を全部教えてほしい」という総合的な知りたいがある。AIが横断的な回答を返すためには、情報の統合・相互参照が設計されている必要がある。

3-3　更新日・所管の不明確さ

多くの自治体ページには「最終更新日」が記載されていない、または更新の実態と乖離している（「リンクを直しただけで更新日を変えた」等）。AIはページの鮮度を判断する際にメタデータ・更新日を参照する。更新日が不明確なページは「古い情報かもしれない」として引用優先度が下がりやすい。

また「この情報の問い合わせ先」が明記されていないページが多い。問い合わせ先の存在は、情報の信頼性（Trustworthiness）を示すシグナルとしてAIが参照する重要な要素だ。

3-4　行政文書特有の長文・難解表現

行政文書は「一文が長い」「受動態が多い」「法律用語が混じる」「見出しが不適切」という特徴がある。AIの自然言語処理にとって、明快な主語・述語・定義文が構造的に整理されたコンテンツの方が引用精度が高い。

例として、「国民健康保険税の減額・免除に関するご案内」というページが以下のような文体で書かれているとする。

「被保険者の属する世帯の世帯主の前年の総所得金額等が一定金額以下の場合において、当該保険税のうち均等割額及び平等割額についてはその規定する割合により減額されるものとする」

これをAIが要約・引用しようとすると、主語が不明確で条件が複雑なため、誤った要約が生じるリスクが高い。

3-5　AI非対応のシステム構造

自治体サイトには以下のような「AI非対応」の技術的問題が多い。

• JavaScriptによる動的描画：クローラーやAIがコンテンツを取得できない
• Flash（廃止済みだが移行していないページが残存）
• ログイン必須コンテンツ：AI経由のアクセスが不可能
• 複雑なURL体系：情報のまとまりが分かりにくい
• 構造化データ（schema.org）の未実装：AIへの意味的情報付与ができていない
• サイトマップの不整備：AIのクロール効率が低下

3-6　CMS老朽化とコンテンツ断絶

多くの自治体CMSは5〜10年前に導入されたシステムで、現代的なAPI提供・Headless対応・構造化データ出力に対応していない。CMSの更新サイクルと情報の更新サイクルが合わず、担当者が変わるたびにコンテンツの品質が劣化するという問題も深刻だ。

3-7　FAQ不足とコンテンツの分散

市民が本当に知りたいことは「よくある質問（FAQ）」形式で整理されているが、多くの自治体サイトではFAQが「一部のページにしか存在しない」「複数の部署がバラバラに作成している」「質問と回答の対応が明確でない」という問題がある。

FAQはAI引用において最も相性の良いコンテンツ形式だ。質問＝ユーザーの検索意図、回答＝明快な定義・手順として構成されたFAQは、AIが直接引用しやすい。この点においても自治体サイトは大きく遅れている。

---

第4章　自治体GEOの5層モデル

自治体GEOを実践するためには、理論から実装・評価まで体系的なフレームワークが必要だ。ここでは「自治体GEO 5層モデル」を提唱する。

┌──────────────────────────────────────────────────┐
│  Layer 5: 運用評価層（KPI・モニタリング・改善サイクル）      │
├──────────────────────────────────────────────────┤
│  Layer 4: 実装技術層（schema.org・RAG・API・CMS）       │
├──────────────────────────────────────────────────┤
│  Layer 3: AI最適化層（FAQ・定義文・構造化テキスト）         │
├──────────────────────────────────────────────────┤
│  Layer 2: 情報構造層（IA・カテゴリ設計・URL・ページ設計）    │
├──────────────────────────────────────────────────┤
│  Layer 1: 理論層（GEO原則・AI理解モデル・情報倫理）         │
└──────────────────────────────────────────────────┘

Layer 1：理論層

定義： 自治体GEOの設計思想・倫理原則・AI理解の基礎理論を扱う層。

目的： GEO対応の方向性を規定し、担当者の意思決定の拠り所とする。

構成要素：

• AI検索の仕組みの理解（RAG・ベクトル検索・コンテキスト参照の基礎）
• 「AIが引用しやすい情報とは何か」の原則整理
• 公共情報の倫理：正確性・中立性・最新性の担保
• 情報アクセシビリティの原則（誰もがAI経由で正確な情報を得られること）

実務上の課題： 多くの自治体では「GEOとは何か」という理論的理解そのものが存在しない。まず担当者教育から始める必要がある。

Layer 2：情報構造層

定義： 情報アーキテクチャ（IA）・URL設計・ページ構造・カテゴリ体系を扱う層。

目的： AIがサイト全体の情報の意味的構造を把握できるよう設計する。

構成要素：

• 論理的なURL体系（例：city.xxx.lg.jp/kurashi/kosodateshien/jidoteate/）
• 関連情報への内部リンク設計
• パンくずリストの整備
• サイトマップ（XML）の適切な管理
• ページの「目的」「対象者」「更新頻度」の明確化

具体例： 子育て支援ページを「課の組織」ではなく「ライフステージ」「利用者の状況」で分類・設計することで、AIが横断的な情報提供をしやすくなる。

Layer 3：AI最適化層

定義： AIによる情報引用・要約・回答を最適化するコンテンツ設計を扱う層。

目的： AIが読みやすく引用しやすいコンテンツ形式を実現する。

構成要素：

• FAQ形式の整備（質問文＝ユーザーが実際に入力する言葉、回答＝明快な定義・手順）
• 定義型文章（「〇〇とは△△のことです。」という明快な定義から始まる文章）
• 見出し（H2/H3）の設計：AIへの構造的シグナル
• 要約ブロック（TL;DR）の挿入
• 問い合わせ先・担当部署・最終更新日の明記

Layer 4：実装技術層

定義： schema.org構造化データ・JSON-LD・RAG連携・API・CMSを扱う層。

目的： 技術的にAIと行政情報を接続する。

構成要素：

• schema.org FAQPage・GovernmentOrganization・Event・LocalBusiness
• JSON-LD実装
• RAGシステムとの連携設計
• オープンデータAPI化
• Headless CMS導入
• サイト速度・モバイル対応

Layer 5：運用評価層

定義： GEO施策の効果測定・KPI設計・継続改善サイクルを扱う層。

目的： GEO対応が実際にAI引用率・市民サービス到達率向上につながっているかを可視化する。

構成要素：

• AI引用率の計測（後述のKPI設計参照）
• FAQアクセス解析
• 問い合わせ件数とAIアクセスの相関分析
• 定期的なAI回答品質チェック（主要質問をAIに投げて回答をモニタリング）

---

第5章　新しい専門用語の定義 ― 自治体GEO語彙体系

自治体GEOを実践・評価するために、以下の専門用語を定義する。これらは従来のSEO用語では表現できない「AI時代の公共情報設計」に固有の概念だ。

AI引用率（AI Citation Rate / ACR）

定義： 特定の行政情報に関するAIへの質問に対して、当該自治体の公式情報が正確に引用・参照された割合。

測定方法： 主要な行政サービス・手続きに関する代表的な質問30〜100件をサンプリングし、ChatGPT・Gemini・Perplexity等に投げかけ、回答内容に公式情報が反映されているか・引用元が公式サイトかを人手またはツールで評価。

活用例： 「育児支援系の質問に対するAI引用率は60%だが、防災情報の引用率は15%だ。防災GEO対応を優先する」という意思決定基準として使う。

公共AI可読性（Public AI Readability / PAR）

定義： 自治体のWebコンテンツが、生成AIによって正確に読み取り・理解・引用できる程度を示す指標。

評価軸：

• テキスト構造の明快さ（見出し・定義文・FAQ形式の有無）
• 更新情報の透明性（最終更新日・バージョン管理）
• 意味的マークアップの充実度（schema.org実装率）
• PDF依存度（PDFのみで提供されていない情報の割合）

スコア化： 各評価軸を0〜25点の100点満点でスコア化し、「公共AI可読性スコア」として管理する。

行政LLMO（Administrative LLMO）

定義： 大規模言語モデル（LLM）の学習データとしても自治体情報が正しく取り込まれるよう最適化する施策。AIのファインチューニングや学習データクオリティに関わる長期的な情報整備戦略。

背景： ChatGPTなどのLLMは、Web上のデータを学習して知識を持つ。自治体の公式情報がLLMに正しく学習されていれば、「リアルタイム検索」なしでも基本的な行政情報を正しく回答できる可能性が上がる。

災害GEO（Disaster GEO）

定義： 避難情報・防災マップ・緊急連絡先など、災害時に参照される情報を、AIが即時・正確に引用できるよう最適化する設計手法。

特性： 通常のGEOと異なり、リアルタイム更新対応・多言語対応・アクセシビリティ対応が必須要件として加わる。

行政RAG適性（Government RAG Suitability / GRS）

定義： 特定の行政ページ・文書が、RAG（Retrieval-Augmented Generation）システムのコンテキストとして適切に機能できるかを示す評価指標。

評価観点：

• テキストの密度と明確さ（回答に必要な情報が集約されているか）
• チャンクサイズの適切さ（RAGでは情報をチャンク=塊に分割して処理する。300〜500トークンが目安）
• 他ページとの重複・矛盾の有無
• 機械読み取り可能な構造

AI情報到達率（AI Information Reachability / AIR）

定義： 市民がAIを通じて行政情報にアクセスしようとした際に、目的の情報に正確にたどり着けた割合。

測定方法： ユーザーテストまたはシミュレーション。市民が持つ行政情報ニーズをAI経由で充足しようとした際の成功率を計測。

類似概念との違い： AI引用率は「AIが公式情報を引用したか」だが、AI情報到達率は「市民が求める情報を正確に得られたか」という成果指標だ。

公共情報構造化指数（Public Information Structuring Index / PISI）

定義： 自治体が提供する全情報のうち、schema.org・JSON-LD・FAQ形式等で構造化されている情報の割合。

目標値： 主要な市民サービス（上位50件程度）の情報について、構造化指数80%以上を目標とする。

---

第6章　AIが引用しやすい自治体情報設計

6-1　AIはどのように情報を「読む」か

AIが情報を処理するプロセスを理解することは、GEO設計の基礎だ。

現在の生成AIの多くは、情報検索にRAG（Retrieval-Augmented Generation）を使っている。RAGとは、AIが回答を生成する際に「まずWebや知識ベースから関連情報を検索し（Retrieval）、その情報をコンテキストとして与えた上で回答を生成する（Generation）」仕組みだ。

このプロセスで重要なのは、「Retrieval」の精度だ。AIは質問の意味をベクトル化し、それに最も意味的に近いコンテンツを検索する。ここで選ばれたコンテンツが「回答の材料」になる。つまり、意味的に明快で、質問との関連性が高く、構造化されたコンテンツが選ばれやすい。

6-2　FAQ設計

FAQはGEO最適化において最も即効性の高いコンテンツ形式だ。理由は明確だ。

市民がAIに「〇〇はどうすればいいですか？」と質問する文体は、そのままFAQの質問文に近い。FAQとして整備されていれば、AIは質問と回答のペアを直接引用できる。

効果的なFAQ設計の原則：

• 質問文は市民が実際に使う言葉で書く（行政用語ではなく話し言葉）
• 回答は200〜400字以内でまとめる
• 回答の冒頭に結論を置く（「はい、申請できます。手続きは以下の通りです」）
• 関連ページへのリンクを入れる
• 最終更新日を明記する
• schema.org FAQPageのマークアップを実装する

6-3　Hタグ設計とコンテンツ構造

見出し（H1〜H3）は、AIがページの構造を理解するための「目次」として機能する。

推奨設計：

H1: [自治体名]の[サービス名]について
H2: [サービス名]とは
H2: 対象者
H2: 申請方法
  H3: 申請に必要なもの
  H3: 申請窓口・受付時間
  H3: オンライン申請の方法
H2: よくある質問（FAQ）
H2: お問い合わせ先

このような構造化されたH2/H3により、AIはページ内の特定セクションを「チャンク」として抽出しやすくなる。

6-4　定義型文章の重要性

AIが最も引用しやすいコンテンツは「定義型文章」だ。

良い例：「児童手当とは、中学校修了前（15歳の誕生日後の最初の3月31日まで）の子どもを養育する保護者に対して支給される給付金です。月額は子どもの年齢・所得に応じて異なり、3歳未満は一律15,000円、3歳以上小学校修了前は10,000円（第3子以降は15,000円）、中学生は一律10,000円です。」

悪い例：「児童手当については、関係する法令等に基づき、対象となる方々に対して所定の金額が給付されることになっております。詳細については担当窓口にお問い合わせください。」

前者は「誰に」「何が」「いくら」が明確だ。後者は情報密度がゼロで、AIが引用しても意味のある回答が生成されない。

6-5　構造化データ（schema.org / JSON-LD）

schema.orgは、Webページの意味をGoogleなどの機械（AIを含む）に伝えるための標準語彙だ。JSON-LDは、そのschema.orgの情報をWebページのHTMLに埋め込むための記述形式だ。

自治体サイトで特に重要なschema.orgタイプ：

タイプ	用途
FAQPage	FAQ形式のページ
GovernmentOrganization	自治体・部署の情報
GovernmentService	行政サービスの詳細
Event	イベント・説明会
LocalBusiness	公共施設（図書館・公民館等）
EmergencyHelpCenter	災害時の避難所・緊急連絡先
HowTo	手続き・申請の手順

FAQ用JSON-LD実装例：

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "児童手当の申請はいつまでにすればよいですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "出生・転入等の翌日から15日以内に申請が必要です。期日内に申請した場合、出生日・転入日の翌月分から支給されます。"
      }
    }
  ]
}

このマークアップを実装することで、GoogleのAI Overviewsや構造化データ対応の検索・AIエンジンが直接回答として使いやすくなる。

6-6　API化・Headless CMSの意義

行政情報をAPI経由で提供できるようにすることは、GEO対応の最終形の一つだ。

API（Application Programming Interface）化により、市民向けアプリ・AIエージェント・外部サービスが自治体の最新情報をリアルタイムで取得できるようになる。例えば「今日の粗大ゴミ収集地区はどこか」を市民がAIに聞き、AIが自治体APIからリアルタイムデータを取得して回答する、というシナリオが実現可能になる。

Headless CMSとは、コンテンツ管理とコンテンツ表示を分離したCMSの設計形式だ。コンテンツをAPIとして配信できるため、Webサイト・スマホアプリ・AIエージェント等に同一の情報ソースから配信できる。情報の一元管理・更新反映の即時性・AI対応の容易さという三点で、従来の自治体CMSに対して大きな優位性を持つ。

---

第7章　災害GEO ― 人命に関わる情報設計

7-1　なぜ災害情報はGEO対応が最優先か

災害GEOは自治体GEOの中で最も緊急度が高い分野だ。その理由は単純だ。「避難情報をAIが誤って伝えた場合の代償は、人命だ」。

2026年現在、スマートフォンを持つ市民の多くは、緊急時にまずスマートフォンで情報を検索する。その検索行動にAIが介在することで、AIが提供する避難情報の正確性が直接的な避難行動に影響する。

7-2　避難情報の構造化設計

避難情報のGEO対応で最も重要なのは「リアルタイム更新」と「明確な構造化」だ。

推奨設計：

[避難情報ページのH構造]
H1: 〇〇市 避難情報（リアルタイム更新）
H2: 現在の避難情報（最終更新: YYYY/MM/DD HH:MM）
  H3: 避難指示（緊急）
  H3: 避難勧告
  H3: 高齢者等避難
H2: 現在開設中の避難所一覧
H2: 避難するときの持ち物
H2: お問い合わせ先（24時間対応）

重要なのは「最終更新時刻」をページの目立つ場所に表示することだ。AIはコンテンツの鮮度を判断する際にこの情報を参照する。更新時刻が明記されていない避難情報は、AIから見て「古い情報かもしれない」と判断されるリスクがある。

7-3　避難所情報のschema.org実装

{
  "@context": "https://schema.org",
  "@type": "EmergencyHelpCenter",
  "name": "〇〇小学校 避難所",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "〇〇市〇〇1-2-3",
    "addressLocality": "〇〇市",
    "addressRegion": "〇〇県"
  },
  "telephone": "098-XXX-XXXX",
  "openingHours": "Mo-Su 00:00-23:59",
  "maximumAttendeeCapacity": 500,
  "amenityFeature": [
    {"@type": "LocationFeatureSpecification", "name": "車椅子対応", "value": true},
    {"@type": "LocationFeatureSpecification", "name": "ペット受け入れ", "value": false}
  ]
}

7-4　多言語対応と災害GEO

外国人住民・観光客への災害情報提供においても、GEO対応は重要だ。AIは多言語での質問に対応するため、多言語化された構造化データが存在すれば、外国語ユーザーの質問にも正確な自治体情報を返せる。

推奨：主要な避難情報・緊急連絡先を英語・中国語・韓国語でも構造化データとして提供する。特に沖縄県などの観光地自治体では、外国語対応の災害GEOは急務だ。

7-5　AIチャットボットと災害情報

自治体がAIチャットボットを独自に整備している場合、チャットボットのナレッジベースと公式Webサイトの情報が一致しているかを確認する必要がある。矛盾が生じると、「市のAIチャットボット」と「外部AI（ChatGPT等）」が異なる情報を提供するという混乱が生じる。

7-6　台風・津波情報の特殊性

台風情報・津波情報は「数時間単位」での更新が必要だ。この更新頻度に対応するためには、以下の技術的措置が必要だ。

• Webページのキャッシュ設定を最短（1〜5分）に設定する
• Google Search ConsoleのURL再クロール申請を緊急時に活用する
• 構造化データ内の更新日時（dateModified）をリアルタイムで更新する
• Twitter/X・LINE公式アカウントと連動して情報拡散の速度を上げる（AIはSNSも参照するため）

---

第8章　実装技術詳説 ― 自治体GEOの技術スタック

8-1　schema.orgの全体像

schema.orgは2011年にGoogle・Bing・Yahoo!が共同で整備を開始した、Web上のコンテンツに意味を付与するための語彙標準だ。2026年現在、900を超えるタイプが定義されており、自治体情報に関連するタイプも充実している。

自治体サイトで使うべき主要タイプ：

タイプ	自治体での使用例	主な属性
GovernmentOrganization	市役所・各部署	name, address, telephone, url
GovernmentService	行政サービス全般	name, description, provider, areaServed
FAQPage	FAQ形式のページ	mainEntity（Question+Answer）
HowTo	申請手順ページ	step, tool, supply
Event	説明会・イベント	name, startDate, location, organizer
LocalBusiness	図書館・公民館	name, address, openingHours
EmergencyHelpCenter	避難所	name, address, telephone
Dataset	オープンデータ	name, description, distribution
NewsArticle	お知らせ・プレスリリース	headline, datePublished, author

8-2　RAGシステムの仕組みと自治体GEO

RAG（Retrieval-Augmented Generation）は現代の生成AIの中核技術だ。仕組みを理解することで、「AIに読まれやすいコンテンツ設計」の意味が明確になる。

RAGのプロセス：

1. ユーザーが質問を入力する
2. AIが質問をベクトル（数値の配列）に変換する
3. ベクトルDBから意味的に近いコンテンツのチャンクを検索・取得する
4. 取得したチャンクをコンテキスト（文脈情報）としてAIに与える
5. AIがコンテキストを参照しながら自然言語で回答を生成する

ここで重要なのは「チャンク（塊）」の概念だ。RAGでは、Webページやドキュメントを一定サイズのテキストの塊に分割してベクトルDBに格納する。このチャンクサイズが適切であることが重要で、一般的には300〜600トークン（約200〜400文字）が実用的とされる。

自治体情報の観点では、「1つのFAQ項目（質問＋回答）が1チャンクとして機能する」設計が理想的だ。FAQ形式の整備は、GEOとRAG対応の両方に効果を発揮する。

8-3　ベクトルDBと自治体情報活用

自治体が独自のAIチャットボット・内部検索システムを整備する場合、ベクトルDB（ChromaDB・Pinecone・Weaviate等）の活用が現実的選択肢となっている。

自治体ベクトルDB構築の基本ステップ：

1. 全公式Webページのテキストをクロール・テキスト抽出する
2. PDFはOCR処理でテキスト化する（スキャンPDFには限界あり）
3. テキストをチャンクに分割する（セクション単位が理想）
4. 各チャンクをEmbeddingモデルでベクトル化してDBに格納する
5. ユーザーの質問をベクトル化し、最も近いチャンクを検索して回答の文脈に使う
6. 定期的にDBを更新し、情報の鮮度を保つ

8-4　MCPとAIエージェント連携

MCP（Model Context Protocol）は、Anthropicが提唱する「AIと外部ツール・データソースの接続標準」だ。2025年以降急速に普及しており、自治体システムとのAIエージェント連携において重要な技術となっている。

自治体でのMCP活用シナリオ：

• 市民がAIエージェントを通じて各種申請書を入力・送信する
• AIエージェントが住民票・証明書発行サービスと連携する
• 職員向けAIが庁内システムから必要な情報をリアルタイムで取得して回答する

MCPに対応するためには、自治体の基幹システムがAPIを公開している必要があり、セキュリティ設計も重要な課題となる。

8-5　Headless CMS導入の実際

Headless CMSとは「コンテンツ管理機能（バックエンド）」と「表示機能（フロントエンド）」を分離したCMSだ。コンテンツはAPIとして配信されるため、Webサイト・スマホアプリ・AIシステムなど複数の「表示先」に同一情報を配信できる。

代表的なHeadless CMS：Contentful・Strapi・microCMS（日本語対応）・Sanity

自治体での導入メリット：

• コンテンツ更新がAPI経由でリアルタイムに全チャンネルへ反映される
• JSON形式でコンテンツが配信されるため、AIが構造化データとして取り込みやすい
• ページの表示形式に縛られず、「情報それ自体」の質向上に集中できる

導入の課題：既存CMSからの移行コスト、職員への操作教育、セキュリティ設計。

8-6　WCAG対応とGEOの関係

WCAG（Web Content Accessibility Guidelines）はWebアクセシビリティの国際標準だ。WCAG対応とGEO対応は多くの点で重なる。

共通の改善ポイント：

• 画像へのalt属性付与 → AIが画像の意味を理解しやすくなる
• コントラスト比の確保 → ページ品質の向上はAI評価にも影響
• 見出し構造の整備 → AIのコンテンツ理解に直結
• リンクテキストの明確化 → 「こちら」「詳しくは」を具体的なアンカーテキストに変える

WCAG Level AA（日本の行政サイトに求められる基準）への対応は、GEO対応の土台としても機能する。

---

第9章　AI時代の自治体サイト設計 ― 比較と転換

9-1　従来の自治体サイト vs GEO対応自治体サイト

【従来の自治体サイト】            【GEO対応自治体サイト】

情報の単位: 部署・ページ           情報の単位: サービス・ユーザーニーズ
─────────────────────────────────
更新方式: 手動・不定期             更新方式: 自動通知・定期サイクル
─────────────────────────────────
コンテンツ形式: HTML + PDF多用     コンテンツ形式: 構造化HTML・FAQ・schema.org
─────────────────────────────────
内部リンク: バラバラ               内部リンク: ライフステージ・テーマ別に設計
─────────────────────────────────
FAQ: ほぼなし・一部のみ           FAQ: 全主要サービスにFAQ設計
─────────────────────────────────
更新日: 不明・または形骸化         更新日: 明確・コンテンツと連動
─────────────────────────────────
API: なし                         API: オープンデータAPI整備
─────────────────────────────────
アクセシビリティ: 最低限           アクセシビリティ: WCAG AA準拠
─────────────────────────────────
AI対応: 未考慮                    AI対応: GEO 5層モデル全体を設計

9-2　移行の優先順位

すべてを一度に変えることは不可能だ。以下の優先順位で段階的に対応する。

フェーズ1（3ヶ月以内）：クイックウィン

• 主要ページ（子育て・福祉・防災・観光）にFAQセクション追加
• schema.org FAQPage実装
• 全ページに「最終更新日」「問い合わせ先」を明記
• PDFのHTMLページ代替版を作成（主要10〜20件）

フェーズ2（6ヶ月以内）：構造整備

• 情報アーキテクチャの見直し（ライフステージ・ニーズ別の分類）
• GovernmentService・HowToのschema.org実装
• サイトマップXMLの整備・Google Search Consoleへの登録
• 災害GEO対応（避難所・緊急情報ページの構造化）

フェーズ3（1年以内）：システム刷新

• Headless CMS検討・導入
• オープンデータAPIの整備
• 独自RAGシステムの構築（庁内検索・市民向けチャットボット）
• WCAG AA準拠の確認・修正

---

第10章　KPI設計 ― 自治体GEO効果測定

10-1　なぜ自治体GEOに専用KPIが必要か

従来のWebアクセス解析KPI（PV数・セッション数・直帰率等）は、GEO時代には不十分だ。AIが「ゼロクリック」で回答する場合、サイトへのアクセス数は減少しても情報到達率が向上するという逆転現象が起きる。

自治体GEOに必要なKPIは「市民が行政情報に正確にたどり着けたか」という成果指標だ。

10-2　自治体GEO KPI体系

AI引用率（AI Citation Rate）

測定方法：四半期ごとに主要行政サービス（上位50件）に関する代表的な質問をChatGPT・Gemini・Perplexityに投げかけ、公式情報が引用されているかを評価するAI引用率テストを実施。
目標値：60%以上（初期）→ 80%以上（1年後）

AI流入率（AI Referral Rate）

測定方法：Google Analytics等でリファラーを分析し、ChatGPT・PerplexityなどのAIサービスからの流入数を計測。
活用：どのコンテンツがAI経由で訪問されているか、逆にAIで引用されているのにサイト訪問につながっていないページはないか（正常な「ゼロクリック」と問題のある「誤引用」の区別）を分析。

FAQ解決率（FAQ Resolution Rate）

測定方法：FAQページのアクセス数に対して「そのままサイトを離脱した数」と「次のページ（申請ページ等）へ進んだ数」の比率を計測。
目標値：FAQ閲覧後の次ステップ遷移率50%以上。

AI回答精度（AI Answer Accuracy）

測定方法：代表的な行政サービス質問30〜50件について、複数のAIに月次で同一質問を投げ、「正確な情報が回答されているか」を1〜5点でスコアリング。
活用：スコアが低いカテゴリのコンテンツGEO対応を優先する。

行政情報到達率（Administrative Information Reachability）

測定方法：年1〜2回のユーザーテストで、「AIを使って申請情報・手続き情報を調べてもらい、目的の情報に正確にたどり着けたか」を計測。
目標値：80%以上（主要10サービス平均）。

従来SEO KPIとの比較

従来KPI	自治体GEO KPI
PV数	AI引用率
検索順位	AI回答精度
直帰率	FAQ解決率
セッション数	AI情報到達率
流入キーワード数	AI流入率

---

第11章　自治体GEOチェックリスト100項目

A. テクニカル基盤（20項目）

•  A01. 全ページにHTTPS（SSL/TLS）が設定されている
•  A02. Core Web Vitals（LCP・FID・CLS）が合格水準にある
•  A03. モバイルフレンドリー対応が完了している
•  A04. XMLサイトマップが最新の状態でSearch Consoleに送信されている
•  A05. robots.txtが適切に設定されており、重要ページのクロールが許可されている
•  A06. ページ速度（PageSpeed Insights）でスコア75以上を達成している
•  A07. JavaScriptに依存しない（あるいはSSR対応している）主要コンテンツがある
•  A08. 404エラーページが整備されており、リダイレクトが適切に設定されている
•  A09. 重複コンテンツが存在せず、canonicalタグが適切に使われている
•  A10. hreflang属性が多言語ページに設定されている（多言語対応の場合）
•  A11. Open Graph / Twitter Cardが設定されており、SNS共有時の情報が正確だ
•  A12. AMP（Accelerated Mobile Pages）または高速静的ページが検討されている
•  A13. Webフォントの読み込みが最適化されている
•  A14. 画像がWebP形式に変換・圧縮されている
•  A15. CDN（コンテンツ配信ネットワーク）が使われており、国内アクセスが高速だ
•  A16. サーバーエラーログを定期的に確認している
•  A17. ブラウザキャッシュが適切に設定されている
•  A18. OGP（Open Graph Protocol）画像が主要ページに設定されている
•  A19. リンク切れチェックを月次で実施している
•  A20. セキュリティヘッダー（X-Content-Type-Options等）が設定されている

B. 情報構造・UX（15項目）

•  B01. URL体系が「課の組織」ではなく「サービス・利用者ニーズ」で設計されている
•  B02. パンくずリストが全ページに正確に実装されている
•  B03. サイト内検索が主要ページから利用でき、精度が確認されている
•  B04. トップページから主要サービスへ3クリック以内で到達できる
•  B05. ライフステージ別・状況別（妊娠・出産・子育て等）のナビゲーションがある
•  B06. 関連情報への内部リンクが文脈に沿って適切に配置されている
•  B07. ページ内の見出し（H1〜H3）が論理的な階層構造を持っている
•  B08. 読みやすいフォントサイズ（本文16px以上）が確保されている
•  B09. テキストと背景のコントラスト比がWCAG AA基準（4.5:1以上）を満たしている
•  B10. 重要な申請・手続きページへのCTA（Call to Action）が明確に設置されている
•  B11. フッターに緊急連絡先・主要サービスへのリンクが集約されている
•  B12. 404ページからサイトトップ・主要コンテンツへ誘導している
•  B13. ページの最上部に「このページで分かること（要約）」が設置されている
•  B14. 印刷用スタイルシートが整備されており、申請書等が正しく印刷できる
•  B15. フォームのエラーメッセージが具体的で修正方法が分かる

C. コンテンツ品質（20項目）

•  C01. 全主要サービスページに「最終更新日」が明記されている
•  C02. 全主要サービスページに「問い合わせ先（電話・メール・担当部署）」が明記されている
•  C03. 全主要サービスページに「対象者（誰が使えるか）」が明確に記載されている
•  C04. 申請手続きが「手順・ステップ形式」で記載されている
•  C05. 各サービスの「費用」「期間」が明記されている
•  C06. 難しい行政用語には括弧内で平易な説明が付いている
•  C07. 一文が長くなりすぎず、読みやすいリズムで書かれている
•  C08. 「詳しくはこちら」のみのリンクテキストが排除され、具体的なアンカーが使われている
•  C09. 重要な情報がPDFのみで提供されておらず、HTMLページとしても整備されている
•  C10. スキャンPDF（OCRなし）が残っていない
•  C11. 各ページのH1が1つだけ存在し、ページの主題を正確に表している
•  C12. 英語・他言語の主要ページ（観光・移住・防災等）が整備されている
•  C13. 掲載期限が過ぎた情報（終了した補助金等）が適切に削除・更新されている
•  C14. 保護者・子育て世代向けコンテンツが分かりやすい言葉で書かれている
•  C15. 外国人住民向けのやさしい日本語ページが整備されている
•  C16. ページの冒頭200文字以内に「このページで解決できる問い」が含まれている
•  C17. 重要な変更事項（条例改正・制度変更）がお知らせとして掲載されている
•  C18. 地図・アクセス情報がGoogle Maps等と連携して正確に提供されている
•  C19. 事業者向け・市民向けのコンテンツが混在せず適切に分離されている
•  C20. 各ページが「なぜこの情報が必要か」という文脈から始まっている

D. AI最適化・構造化データ（20項目）

•  D01. 主要サービスページにFAQセクションが設置されている
•  D02. FAQの質問文が「市民が実際に使う言葉」で書かれている
•  D03. FAQの回答が200〜400字以内で、冒頭に結論がある
•  D04. schema.org FAQPageのJSON-LDが主要FAQページに実装されている
•  D05. schema.org GovernmentOrganizationが自治体トップページに実装されている
•  D06. schema.org GovernmentServiceが主要サービスページに実装されている
•  D07. schema.org HowToが申請手順ページに実装されている
•  D08. schema.org Eventがイベント・説明会ページに実装されている
•  D09. schema.org LocalBusinessが公共施設（図書館・公民館等）ページに実装されている
•  D10. 避難所・防災施設ページにschema.org EmergencyHelpCenterが実装されている
•  D11. お知らせ・ニュースページにschema.org NewsArticleが実装されている
•  D12. オープンデータページにschema.org Datasetが実装されている
•  D13. JSON-LDが正しい構文で実装されており、Googleのリッチリザルトテストで検証済みだ
•  D14. ページのdatePublished・dateModifiedが正確に設定されている
•  D15. AI向けの要約ブロック（TL;DR・まとめ）が主要ページに設置されている
•  D16. 定義型文章（「〇〇とは△△です」形式）がサービス説明冒頭に使われている
•  D17. 避難情報ページのリアルタイム更新の際にdateModifiedが自動更新される仕組みがある
•  D18. AIクロールのためのサイトマップが整備されており、全FAQページが含まれている
•  D19. 構造化データに矛盾・誤記がなく、ページ本文と内容が一致している
•  D20. Googleのサーチコンソールで構造化データのエラーを定期確認している

E. 災害・緊急対応（10項目）

•  E01. 避難情報ページに最終更新時刻がリアルタイムで表示される
•  E02. 現在開設中の避難所一覧が常時更新・機械可読な形式で公開されている
•  E03. 防災マップがGeoJSON等の機械可読形式でも公開されている
•  E04. 緊急連絡先（代表番号・担当部署）が全ページのヘッダー・フッターから到達できる
•  E05. 多言語（英・中・韓等）での緊急情報ページが整備されている
•  E06. 避難情報のRSSフィードが提供されており、AI・外部システムが購読できる
•  E07. ハザードマップが最新版に更新されており、PDFのみでなくWebページでも閲覧できる
•  E08. 平時と緊急時でページのデザイン・ナビゲーションが切り替えられる仕組みがある
•  E09. 音声読み上げソフトで避難情報が正確に読み取れることを確認している
•  E10. 停電・システム障害時のバックアップ情報配信手段（LINE・メール等）が整備されている

F. アクセシビリティ（5項目）

•  F01. 全画像にalt属性が適切に設定されている
•  F02. フォームのラベルが適切に関連付けられている
•  F03. キーボードのみで全機能が操作できる
•  F04. 動画コンテンツに字幕・テキストスクリプトが付いている
•  F05. WCAG 2.1 Level AA適合を自動チェックツールで定期確認している

G. 運用・評価（10項目）

•  G01. GEO担当者が指定されており、四半期ごとのKPIレビューを実施している
•  G02. AI引用率テストを四半期ごとに実施している
•  G03. AIへの主要質問（月次）をモニタリングしており、誤情報を早期発見できる体制がある
•  G04. コンテンツの鮮度チェック（更新期限切れ通知）のワークフローが存在する
•  G05. 市民からの「AIで間違った情報を得た」という苦情を収集・分析している
•  G06. SEO改善とGEO改善の両方を網羅したコンテンツ改善ロードマップが存在する
•  G07. 構造化データの追加・修正手順が担当者に周知されている
•  G08. FAQの追加・更新が担当部署から申請できる仕組みがある
•  G09. 年次でのGEO完全監査（外部専門家を含む）が計画されている
•  G10. GEO対応の進捗を首長・部長クラスが確認できる形で可視化されている

---

第12章　2030年への未来予測 ― AI行政インフラの進化

12-1　2030年の自治体ポータルの姿

2030年には、「自治体のWebサイトを訪問する」という行動自体が少数派になっている可能性が高い。市民の大多数は、スマートフォン上のAIアシスタントに話しかけることで、行政手続きのほぼすべてを完結させる。

「子育て支援金の申請書を出したい」とAIに言えば、AIが市民の情報（マイナンバーカード連携）を確認し、必要書類を収集し、申請書に自動記入し、市の電子申請システムに送信するまでを一気通貫で行う。

このシナリオでGEOが重要なのは「AIが参照する情報の正確性」が行政サービスの品質そのものになるからだ。

12-2　音声行政の実現

スマートスピーカー・AIイヤホン・カーナビとの音声連携により、「音声での行政情報アクセス」が日常化する。

「おい、来月のゴミ収集日を教えて」「新型ウイルスのワクチン接種の予約方法を教えて」——こうした音声質問に対して自治体の正確な情報がリアルタイムで返ってくるためには、音声対応のGEO設計（定義型文章・FAQ・構造化データ）が必須だ。

高齢者・障害者・外国人住民にとっては、音声AIが行政情報へのアクセスを根本的に改善する可能性がある。

12-3　AIエージェント行政

AIエージェントとは、複数のツール・システムを自律的に操作して特定のタスクを完遂するAIだ。2026年の技術水準では実験段階にあるが、2030年には実用化が進む見込みだ。

行政向けAIエージェントの想定シナリオ：

• 介護サービスの申請：要介護認定の申請書作成から面談予約・必要書類の収集まで
• 転入手続き：住民票・健康保険・子どもの転校手続きを一括でエージェントが代行
• 補助金申請：利用可能な補助金の検索→資格確認→申請書記入→提出まで自動化

これらを実現するためには、自治体のAPIと情報の機械可読性が絶対条件だ。GEO対応はAIエージェント行政の土台だ。

12-4　行政RAGの標準化

2030年には、自治体共通の「行政情報RAGプラットフォーム」が整備されているかもしれない。デジタル庁が主導し、全国の自治体情報を統一フォーマットで収集・ベクトルDB化し、国民向けAI問い合わせサービスとして提供するというシナリオだ。

このプラットフォームに自治体情報が正確に取り込まれるためには、各自治体の公式サイトがGEO対応済みであることが前提になる。

12-5　「Webサイト」という概念の変容

2030年には「市のWebサイト」の役割が大きく変わっている。市民がブラウザでサイトを閲覧するケースは減り、AIを通じた情報アクセス・APIを通じたシステム間連携が主流になる。

この変化は「WebサイトをAIに向けて作る」ことを意味する。人間が読む美しいデザインよりも、AIが読める構造的な情報設計が優先される。GEOはその設計思想の中核だ。

12-6　自治体GPT・ローカルLLMの可能性

特定自治体の情報に特化した「地域版LLM（自治体GPT）」が整備される可能性がある。「〇〇市専用AI」が市民の問い合わせに正確・即時に回答し、24時間365日の行政サービスを実現する。

これは単なるチャットボットの高度化ではなく、自治体の職員文化・方言・地域特性を反映した真に市民に寄り添うAIだ。その基盤となるのは、GEO対応済みの質の高い行政情報だ。

---

第13章（最終章）　自治体GEOはAI時代の公共情報インフラだ

「サイトを最適化する」を超えた次元の問い

本ドキュメントを通じて、自治体GEOがSEOの延長線上にある「テクニカルな最適化テクニック」ではないことは明らかだ。

自治体GEOは「誰がAI時代に正確な公共情報の発信者たり得るか」という、行政の存在意義に関わる問いだ。

市民がAIに「近くの避難所はどこか」と聞いた時に、正確な情報が返ってくることは社会インフラの機能だ。市民がAIに「保育園の申し込み方法を教えて」と聞いた時に、正確な手順が返ってくることは市民の権利の問題だ。

その情報が自治体から正しく発信されていなければ、市民はAIが生成した「それらしい、しかし誤った情報」を受け取る。それは行政の失敗だ。

情報設計は政策だ

道路を整備するのが行政インフラの整備であるように、AIに読まれる形で情報を整備するのも「情報インフラの整備」だ。

これはIT部門だけの問題ではない。首長・部長・各課の政策担当者・広報担当・窓口職員——自治体のすべての階層が「AI時代に情報はどう届けるべきか」を理解し、GEOを組織の優先事項として位置づける必要がある。

予算・人材・時間がかかることは事実だ。しかし問うべきは「GEO対応にかかるコスト」ではなく「GEO対応しないことで市民が払うコスト」だ。誤情報に基づいて申請期限を逃す市民、誤った避難行動をとる市民——その「見えないコスト」がGEO未対応のリスクだ。

アクセシビリティとGEOの一致

自治体GEOが目指すものは、実はWebアクセシビリティが長年目指してきたものと本質的に重なる。「すべての市民が、どんな手段を通じても、正確な行政情報に到達できること」。

スクリーンリーダー利用者・キーボード操作ユーザー・スマートスピーカーユーザー・AIエージェントユーザー——これらは全て「標準ではないアクセス手段」であり、GEOとアクセシビリティは同じ設計原則で対応できる。

構造化・定義型文章・FAQ・明確な見出し・更新日の明記——これらの施策はGEOにもアクセシビリティにも同時に機能する。「誰に対しても、どんな手段を通じても届く情報設計」が自治体GEOの究極の目標だ。

日本の自治体への提言

日本には1741の自治体がある。そのほとんどが、AI時代への対応を意識した情報設計に着手できていない。本ドキュメントが提唱する「自治体GEO 5層モデル」「100項目チェックリスト」「KPI体系」「専門用語体系」は、その対応を組織的に始めるための出発点だ。

特に緊急性が高いのは以下の5点だ。

第一に、災害GEO対応。避難情報・緊急連絡先・ハザードマップのAI最適化は、人命に直結するため最優先で着手すべきだ。

第二に、子育て・福祉情報のFAQ化。これらは市民からの問い合わせが最も多く、AIへの依存度も高い分野だ。構造化FAQの整備だけで大きな改善が見込める。

第三に、schema.org実装。技術的には難しくなく、実装工数に対して効果が大きい。特にFAQPage・GovernmentServiceから着手すべきだ。

第四に、PDF依存からの脱却。主要な申請案内・手続きガイドをHTMLページとして整備することで、AIの可読性が劇的に向上する。

第五に、GEO KPIの設定と定期モニタリング。「AIが何を言っているか」を定期的に確認する仕組みを設けることで、問題を早期発見・修正できる。

結語

「自治体GEOは単なるSEOではない。これはAI時代における公共情報インフラ設計そのものである。」

この命題を繰り返すことで本書を閉じたい。

Webの誕生以来30年、情報の届け方は何度も変わった。検索エンジンの登場、スマートフォンの普及、SNSの台頭——そして今、生成AIという変革が来た。

それぞれの変革において、行政は常に「後手」に回ってきた。民間よりも5年・10年遅れて対応するのが常だった。

しかし今回ばかりは、後手に回ることが許されない。AIが誤った避難情報を伝える社会は、もはや情報インフラが機能していない社会だ。

自治体GEOへの対応は、技術の問題ではなく、行政の責任の問題だ。

この認識が、日本全国の自治体担当者・行政DX担当者・SIer・コンサルタントに届くことを、著者は切に願っている。

---

参考資料・関連リンク

• schema.org 公式ドキュメント: https://schema.org/
• Google 構造化データドキュメント: https://developers.google.com/search/docs/appearance/structured-data
• WCAG 2.1 日本語訳: https://waic.jp/translations/WCAG21/
• デジタル庁 Webアクセシビリティ導入ガイドブック: https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook/
• Google Search Central（SEO・構造化データ）: https://developers.google.com/search/docs
• Anthropic Claude API（RAG連携参考）: https://docs.anthropic.com/

---

著者プロフィール

鈴木孝昌（すずき たかまさ）

WEBCRAFTS代表。1993年よりPC-98時代からWeb・システム開発に携わり、約30年の実務経験を持つ現役エンジニア・プロジェクトマネージャー。政府・官公庁のWebサイト・システム構築を多数担当。自治体SNS専門家として米Google本社・Meta本社から招待実績あり。WordPress公式オーガナイザー。沖縄マイクラ部プログラミングスクール「クロスウェーブ」代表として第6回・第7回マイクラカップ沖縄代表チームを指導（第7回TBS賞受賞）。DX伴走支援・SEO/GEOコンサルタントとして自治体・企業の情報設計に携わる。

公式サイト: https://webcrafts.jp/