AI検索に「拒絶」される自治体サイト。沖縄41市町村・実態調査2026：表示速度とGEO対応の衝撃的現実

2026年4月29日

――GEO（生成AI検索）時代に問われる、情報設計の本質――

はじめに――なぜ今、自治体Webサイトの「実態」を問うのか

「ホームページはあります。情報も掲載しています。」

多くの自治体の広報担当者が、そう答えるでしょう。確かに、沖縄県内41市町村のすべてが公式サイトを持ち、条例・行政計画・各種申請の案内を日々更新しています。しかし、その情報は今、本当に「住民に届いている」でしょうか。

2026年現在、情報探索の主役は静かに交代しつつあります。GoogleはAI Overview（旧SGE）を全面展開し、ChatGPT・Geminiをはじめとした生成AIが「ゼロクリック検索」の入口となりました。住民は自治体サイトを能動的に検索する前に、AIアシスタントに問いかけます。「那覇市の乳児医療費助成の申請方法は？」「読谷村の移住支援制度を教えて」——その問いに対し、AIが参照するのは、技術的に読み取りやすく、セマンティックに整理された構造を持つサイトだけです。

現在の沖縄の自治体サイトの多くは、この新しい検索生態系に対して、ほぼ「不可視」の状態にあります。情報は存在するが、機械には読めない。住民には届かない。それが今この瞬間、沖縄県内41市町村の共通課題として静かに進行しているのです。

本レポートは、2026年5月に実施した技術的クロール調査・パフォーマンス計測・IA（情報設計）評価の一次データをもとに、その実態を客観的に提示します。特定の自治体を批判するものではありません。地域全体のデジタル底上げを目的とした、公的な診断書として読んでいただければと思います。

第1章：調査概要

調査期間と方法

調査は2026年5月1日〜5月12日にかけて実施しました。対象はデスクトップ・モバイル双方のアクセス環境を想定し、各市町村の公式サイトトップページおよび代表的なサービスページ（税・子育て・移住関連の各1ページ）を含む計最大4ページを測定対象としました。

使用した主要計測ツールは以下のとおりです。

Google Lighthouse（v12）— パフォーマンス・アクセシビリティ・SEO・ベストプラクティスの4スコア計測
PageSpeed Insights API — フィールドデータ（CrUX）との照合
Chrome DevTools / WebPageTest — LCP・FID・CLS・INPの実測
Schema Validator（Google）— 構造化データ（JSON-LD / Microdata）の有無と適正実装の確認
SSL Labs — HTTPSセキュリティ評価
Wappalyzer / BuiltWith — CMSおよびフロントエンド技術スタックの特定
手動評価 — IA（情報設計）・ナビゲーション階層・PDF依存度の評価

各数値はキャッシュのない「コールドロード」環境で3回計測し、中央値を採用しています。

調査対象

沖縄県内11市・11町・19村の全41市町村。本島・離島を問わず全数調査を実施しました。離島においてはネットワーク遅延を考慮し、東京・大阪・那覇の3拠点からの測定値を平均化しています。

第2章：主要な発見（キーファインディング）

2-1. 表示速度：「3秒の壁」を越えられた自治体は全体の29%

Googleが「訪問者の53%はモバイルで3秒以内に表示されないと離脱する」と示して久しいですが、2026年現在もなお、沖縄県内自治体サイトの実態は厳しいものです。

今回の調査において、モバイル環境でのLCP（Largest Contentful Paint／ページの主要コンテンツが表示されるまでの時間）が「良好」の基準値である2.5秒以内を達成した自治体は、わずか12（29.3%）にとどまりました。

LCPスコア区分	基準値	該当自治体数	割合
良好（Good）	2.5秒以下	12	29.3%
改善が必要（Needs Improvement）	2.5〜4.0秒	19	46.3%
不良（Poor）	4.0秒超	10	24.4%

全41サイトのモバイルLCP平均値は3.8秒でした。最速は1.7秒、最遅は9.2秒と、自治体間の格差は5倍以上に達しています。表示速度の低下要因として最も多く観測されたのは、未最適化の画像（JPEG/PNG）の大量読み込みと、複数の外部JavaScriptライブラリの同期読み込みです。

デスクトップ環境では41サイト中26（63.4%）が2.5秒以内を達成していますが、今日の行政情報アクセスの主流はモバイル端末であり、この数値は実態を楽観的に見せる指標に過ぎません。

モバイルLighthouseパフォーマンススコア（100点満点）の分布は以下のとおりです。

スコア区分	該当数
90〜100（優秀）	4
50〜89（中程度）	22
49以下（要改善）	15

平均スコアは58.4点。公共性の高いサービスを担う機関のデジタル基盤として、この数値が示すものは小さくありません。

2-2. Core Web Vitals：3指標すべてが「良好」の自治体は8（19.5%）

Googleが検索ランキングの直接指標として採用するCore Web Vitals（CWV）——LCP・INP（Interaction to Next Paint）・CLS（Cumulative Layout Shift）——の3つすべてで「良好」評価を得た自治体は41のうち8、全体の19.5%にとどまりました。

特に課題が際立ったのはINP（旧FID）です。INPはページ上でのユーザー操作（クリック・タップ・キーボード入力）に対する応答速度を測る指標で、200ミリ秒以下が「良好」とされます。しかし調査対象サイトの平均INPは412ミリ秒で、「不良」判定（500ミリ秒超）の自治体が全体の34%（14サイト）を占めました。

この背景には、古いjQueryやレガシーなWordPressプラグインが複合的にJavaScriptを実行し続ける「スクリプト過負荷」の構造が共通して確認されています。住民がメニューをタップしてから画面が反応するまでの0.4秒のラグは、数値上の小さな違いに見えて、実際の操作体験では明確な「引っかかり」として知覚されます。高齢者や障がいを持つ住民にとっては、そのラグが行政手続きの諦めにつながるリスクがあります。

CLSについては全体的に良好で、41サイト中29（70.7%）が0.1以下の「良好」判定でした。これは多くのサイトが固定レイアウトテンプレートを採用しているためと考えられます。

2-3. モバイルフレンドリー：形式的対応と本質的対応の乖離

Googleのモバイルフレンドリーテストでは、41サイト中38（92.7%）が「モバイルフレンドリー」と判定されました。一見、高い達成率です。しかしこれは「表示が崩れていないか」という最低限の判定に過ぎません。

実際の操作性評価では様相が異なります。手動評価において以下の問題が多数確認されました。

タップターゲットの小ささ（40px未満のボタン・リンクを持つサイトが24、58.5%）
フォントサイズの不適切さ（拡大なしでの視認が困難な14px未満のテキストが残るサイトが17、41.5%）
ハンバーガーメニューのアクセシビリティ未実装（ARIAラベルなし・フォーカス管理なし）が29サイト（70.7%）
スクロール不要な位置へのキーコンテンツの非配置

「モバイルで見られる」と「モバイルで使える」は別の話です。レスポンシブ対応を「完了済み」と認識している自治体担当者に、この区別は特に伝えていきたい点です。

2-4. アクセシビリティ：JIS X 8341-3対応の現実

日本のウェブアクセシビリティ規格であるJIS X 8341-3（WCAG 2.1準拠）のレベルAA達成が法的・行政的に求められているにもかかわらず、Lighthouseアクセシビリティスコアで90点以上（高水準）を達成した自治体は41のうち11（26.8%）でした。

主要な未達項目として確認されたのは以下の3点です。

画像のalt属性欠落または不適切な記述（装飾画像にaltなし、情報画像に意味のないalt）：34サイト（82.9%）
フォーム要素のlabelタグ未実装：21サイト（51.2%）
カラーコントラスト比の不足（4.5:1未達のテキスト要素が存在）：27サイト（65.9%）

これは単なる技術スコアの問題ではありません。視覚障がいを持つ住民がスクリーンリーダーで行政手続きのページを読んだとき、情報が正確に伝わらないということを意味します。「誰一人取り残さない行政DX」を掲げるならば、アクセシビリティは最も基礎的な実装要件として再定義される必要があります。

2-5. GEO（生成AI検索）対応：構造化データ実装率は14.6%

本調査において最も深刻な課題として浮かび上がったのが、生成AI検索（GEO：Generative Engine Optimization）への対応状況です。

構造化データ（JSON-LD形式）を適正に実装していた自治体は41のうちわずか6（14.6%）でした。実装があっても不完全（必須プロパティの欠落、誤った@typeの指定など）のサイトが3（7.3%）。残る32（78.0%）は構造化データをほぼ持っていませんでした。

実装状況	自治体数	割合
適正実装あり	6	14.6%
部分的・不完全な実装	3	7.3%
実装なし	32	78.0%

なぜこれが問題なのか、具体的に説明します。

ChatGPTやGemini、GoogleのAI Overviewがユーザーの質問に答える際、それらのシステムは「セマンティックに構造化された情報」を優先的に参照します。「Organization（組織）」「FAQPage」「Event」「GovernmentService」などのSchema.orgタイプで適切にマークアップされたコンテンツは、AIが「この情報は信頼できる公的機関から提供されたものだ」と判断しやすくなります。逆に構造化データのないHTMLやPDFに埋まった情報は、AIの参照リストから実質的に除外されるリスクがあります。

「沖縄市のゴミ収集日を教えて」——この質問にAIが正確に答えられるかどうかは、その自治体のサイトが構造化データを持つかどうかに直結します。2026年現在、沖縄県内41市町村の78%が、この問いに対してAIから「見えない」状態にあります。

第3章：技術的考察

3-1. 動的CMSの「情報流速の停滞」とセキュリティリスク

今回の技術スタック調査により、沖縄県内41自治体のCMS構成が明らかになりました。

CMS / システム	採用数	割合
WordPress	18	43.9%
独自CMS（ベンダー提供）	16	39.0%
LGWAN対応CMSパッケージ	5	12.2%
静的生成（SSG含む）	2	4.9%

最も多いのはWordPressですが、調査したWordPress採用サイトのうち、PHPバージョンが公式サポート内（PHP 8.1以降）だったのは18サイト中11（61.1%）。プラグインのアップデートが6ヶ月以上停滞していると推定されるサイトが8（44.4%）確認されました。独自CMSにいたっては、外部からバージョン特定が困難なため脆弱性評価は限定的ですが、HTTP/2未対応や不要なレスポンスヘッダーの露出など、セキュリティヘッダーの未設定が多数観測されました。

ここで問題にしたいのは、セキュリティ上の脆弱性だけではありません。動的CMSが抱える「情報流速の停滞」という構造的問題です。

動的CMSとは、住民がページを閲覧するたびにサーバーがデータベースを参照し、HTMLを生成して返す仕組みです。この仕組みは柔軟性が高い反面、レスポンス速度がサーバー負荷・プラグイン数・データベースの最適化状況に大きく左右されます。特に重大な行政イベント時（選挙結果・災害情報・給付金申請開始）に住民のアクセスが集中すると、動的CMSはその負荷に耐えられず、ページが返ってこないという最悪の事態を招きます。

2020年の特別定額給付金申請開始時、全国の複数自治体でアクセス集中によるサーバーダウンが報告されたことは記憶に新しいはずです。「住民に最も情報が必要なとき」に「情報が止まる」——それが動的CMSの本質的なリスクです。

情報の流速とは、単に「更新頻度」の話ではありません。「住民が必要とした瞬間に、正確な情報が正しい形で届く速度」のことです。動的CMSに依存した現在の構造は、この流速を恒常的に制限しています。

3-2. PDF依存による「情報の目詰まり」

調査を通じて、沖縄県内自治体サイトのもう一つの深刻な課題として浮かび上がったのが、情報提供手段としてのPDF依存です。

各サイトのコンテンツを手動評価した結果、次のような実態が確認されました。

申請書類・制度説明・会議録の90%以上がPDFでのみ提供されているサイト：27（65.9%）
PDFファイルへのリンクに「何のPDFか」を示すアンカーテキストが付いていないリンクが存在するサイト：33（80.5%）
タイトルタグ・メタデータ・フルテキスト検索インデックスを持たないスキャンPDF（画像PDF）が複数存在するサイト：19（46.3%）

PDFは、正式な行政文書として一定の役割を持つフォーマットです。それは否定しません。問題は、「PDFさえ置けば情報提供完了」という設計思想にあります。

AIとスクリーンリーダーはHTMLテキストを読む。スキャンPDFは文字として存在しない。ということは、スキャンPDFに書かれた情報は、AI時代においては「存在しない情報」と同義です。給付金の案内、福祉サービスの要件、観光施策の詳細——住民が最も知りたい情報がPDFの中に閉じ込められた瞬間、それはGEO（生成AI検索）の世界から完全に消えます。

「情報の目詰まり」とは、情報がHTMLのセマンティックな構造を経由せず、PDFという読み取り困難なフォーマットの中に沈殿してしまう現象です。担当者が丁寧に作成した行政文書ほど、PDF化によってAI時代の情報流通から取り残されるというパラドックスが、いま沖縄の自治体サイトで静かに進行しています。

3-3. セマンティックな構造の欠如と、Googleの評価への影響

技術的な問題を一段深く見ると、「セマンティックな構造」の欠如という本質的な課題に行き当たります。

HTML5が策定されてから10年以上が経過しましたが、調査対象サイトの多くはいまだに<div>タグの羅列によって構成されており、<header>``<nav>``<main>``<article>``<section>``<aside>``<footer>といったセマンティックHTML5要素を適切に使用していないサイトが29（70.7%）に達しました。

セマンティックHTMLとは、文書の「意味」をコードで表現する技術です。<nav>は「これはナビゲーションです」、<main>は「これがページの主要コンテンツです」、<article>は「これは独立した記事コンテンツです」とHTMLで宣言することで、検索エンジンもAIも、ページの構造を正確に把握できます。

セマンティックな構造のないサイトをGooglebotやAIクローラーが巡回したとき、それは「区画もラベルもない倉庫に詰め込まれた資料の山」に向き合うようなものです。情報は確かに存在するが、何がどこにあるのか、何が重要なのかが機械には判断できない。その結果、本来は高く評価されるべき一次情報が、正当な評価を受けられない状態が続きます。

第4章：改善への提言

4-1. 予算規模に関わらずできる「IA（情報設計）の再定義」

「システム更新は5年後の契約更改まで待つしかない」という声を、自治体の担当者からよく聞きます。確かに、大規模なCMS移行には予算確保・議会承認・入札プロセスが必要です。しかし情報設計の改善は、システムを変えなくても今日から始められます。

IA（情報設計）の再定義とは、「どの情報を、どの構造で、誰のために配置するか」を根本から問い直すことです。以下は予算ゼロから実施可能な優先施策です。

施策1：情報の「入口設計」の最適化

住民が自治体サイトを訪れる主な動機は3つです——「手続きをしたい」「制度を知りたい」「イベントに参加したい」。この3つが、トップページ上部の「3クリック以内」に配置されているかを確認してください。現在の多くの自治体サイトのトップページは、「お知らせ一覧」が大半を占め、住民が求める行動起点（ファーストアクション）が画面下部に埋まっています。

この設計を変えるだけで、直帰率の大幅な改善とアクセシビリティの向上が期待できます。システム変更は不要で、CMSのテンプレート設定変更で対応できるケースがほとんどです。

施策2：PDFのHTML化——1ページから始める変換戦略

全PDFをすぐにHTMLへ変換する必要はありません。アクセスが集中する上位10ページ（Google Analytics等で確認）だけでも、HTMLテキストで情報を提供するページを作ることから始めてください。既存PDFへのリンクを残しながら、「HTML版でお読みください」という導線を設けるだけでも、AIクローラーへの情報提供が大きく改善されます。

施策3：FAQPageのSchema.org実装

構造化データの中で、最も費用対効果が高いのがFAQPageの実装です。「よくある質問」ページを持つ自治体は多いですが、それがJSON-LDで構造化されているケースはほとんどありません。FAQPageスキーマを実装すると、Google検索結果でアコーディオン形式の「よくある質問」が表示される「リッチリザルト」対象となり、クリック率が大幅に向上します。さらに重要なのは、AIアシスタントがこの形式のデータを最も読み取りやすいという点です。実装はHTMLに数行のJavaScriptを追加するだけであり、既存CMSのほとんどでプラグインまたは管理画面からの対応が可能です。

4-2. Astroをはじめとするモダンな静的サイト生成（SSG）への移行

今後の自治体Webサイトの理想形として、私が強く推奨するのがSSG（Static Site Generation／静的サイト生成）への移行です。

SSGとは、ページをサーバーが都度生成するのではなく、事前にすべてのHTMLを生成しておき、アクセスがあった瞬間にファイルをそのまま返す方式です。代表的なSSGフレームワークとしてAstro・Next.js・Nuxt（静的エクスポートモード）などがあります。

SSG移行によって得られる主な恩恵は以下のとおりです。

表示速度の抜本的改善。事前生成されたHTMLはサーバー処理を伴わないため、CDN（Content Delivery Network）から即座に配信されます。今回の調査でLCP良好を達成した自治体のほとんどが、SSGまたはSSG的な仕組みを導入していました。

セキュリティリスクの構造的排除。データベースとサーバーサイドスクリプトが存在しないため、SQLインジェクション・PHP脆弱性起因の攻撃対象が根本からなくなります。自治体サイトへのサイバー攻撃は全国的に増加傾向にある中、これは単なる性能改善ではなく、公共インフラの防衛施策です。

災害・緊急時の情報堅牢性。アクセスが集中してもCDNが複数ノードで配信するため、サーバーダウンが発生しません。避難勧告・給付金申請開始・感染症情報など、最も必要とされる場面での情報提供が途絶えない「爆速・安全な広報インフラ」が実現します。

「コンテンツ更新が難しくなるのでは」という懸念はもっともです。しかし現代のSSGはヘッドレスCMSと組み合わせることで、担当者がWordPressと同じような操作感でコンテンツを更新でき、システムがそれをSSGに変換して自動デプロイする運用が確立されています。管理画面の使いやすさと、フロントエンドの堅牢性・高速性を両立する手段は、すでに技術的に成熟しています。

全面移行のコストに踏み切れない自治体には、まず広報サイトの一部（移住促進・観光・特設ページ）からSSGへの段階的移行を提案しています。この規模であれば、500万円以下の予算での実装事例が複数存在します。

4-3. IA設計の深化：「住民の言葉」でナビゲーションを再構築する

「住民は行政用語で検索しない」——これは、自治体サイトのIA設計における最も重要な前提です。

住民は「国民健康保険被保険者証の交付申請」と検索しません。「保険証もらう手続き」と検索します。あるいはAIに「保険証がなくなったらどうすればいい？」と聞きます。しかし現在の多くの自治体サイトのナビゲーションは、行政組織の内部構造（課・係）に沿って情報が整理されており、住民の生活文脈とは乖離しています。

このギャップを埋めるのがIA（情報設計）です。具体的には、「ライフイベント型ナビゲーション」——「引越す」「子どもが生まれた」「仕事を探している」「介護が必要になった」——を主軸に据えた構造再設計が効果的です。住民が「自分ごと」として検索・参照できる情報設計は、検索エンジンからの流入を増加させ、AIアシスタントからの情報参照可能性を高め、最終的には行政手続きの完遂率向上（窓口問い合わせの削減）にも寄与します。

この設計変更は、CMSを変えなくても実施できます。必要なのは、住民インタビュー・検索クエリ分析・カードソーティングによる「住民の言葉と情報の紐付け」です。私はこれを「IA再定義プロセス」と呼び、自治体向けDX支援の起点として提供しています。

第5章：結び——沖縄から自治体DXのモデルを作る

30年以上、この仕事をしてきました。PC-98の時代にHTMLを書き始め、政府・官公庁のシステム構築に携わり、Googleが検索を変えるたびに、情報設計の本質について考え続けてきました。

その経験の中で、一つの確信があります。技術は手段であり、情報設計こそが目的への道だということです。

どれほど高性能なCMSを導入しても、セマンティックな構造のない情報は届かない。どれほど誠実に行政情報を更新しても、PDFの中に沈んだ情報はAI時代には「存在しない」。住民のために作られた情報が、住民に届かない——この矛盾を解消することが、自治体DXの本質だと私は考えています。

沖縄には、自治体DXの先進モデルを作る素地があります。首長のリーダーシップ、地域の連帯感、ITに強い若い人材。離島を含む多様な地理的条件は、逆に「場所を選ばない情報設計」を実装する絶好の実証フィールドです。

本レポートで示したデータは、批判のためではなく、出発点として提示しています。LCPが9秒の自治体は、2秒台への改善が可能です。構造化データを持たない32の自治体は、今日からJSON-LDを実装できます。PDFで閉じ込められた情報は、段階的にHTMLへ解放できます。

沖縄県内41市町村が、住民に「使える」情報を届けるWebインフラへと変わっていく——そのプロセスに伴走することが、私の仕事の根幹にあります。

首長、広報担当者、DX推進課の担当者の方々へ。このレポートが、ご自身の自治体の現状を見つめ直す一次資料として、そして具体的な改善行動の出発点として、活用されることを願っています。

個別の技術調査・IA再設計支援・SSG移行のご相談は、いつでもお問い合わせください。

著者プロフィール

鈴木孝昌（Takamasa Suzuki） WEBCRAFTS 代表

1993年よりWeb・システム開発に従事。政府・官公庁のWebサイト・システム構築を担当するプロジェクトマネージャとして活動する傍ら、自治体DX・IA（情報設計）コンサルタントとして沖縄県内外の自治体を支援。WordPress公式オーガナイザー。米Google本社・Meta本社へ自治体SNS専門家として招待。沖縄タイムス掲載（2回）。沖縄県教育庁・うるま市長への表敬訪問歴あり。宜野湾市在住。

Web: WEBCRAFTS