政府ウェブサイトは一般企業サイトと何が違うのか？
結論
政府ウェブサイトは、情報の提示や機関のイメージづくりに加えて、公共情報とデジタルサービスを提供することがより重要な役割です。そのため企画時には、利用者、ユーザビリティ、アクセシビリティ、情報セキュリティ、データの継続性、公開後の運用を同時に考える必要があります。
企業サイトは、ブランド紹介、製品、サービス、ビジネス上のコンバージョンを主な目的とすることが多いでしょう。一方、政府ウェブサイトの利用者は、一般市民、特定のサービス対象者、企業、外国人、研究者、他の機関などに及び、利用目的も単なる情報検索から、法規の照会、書類のダウンロード、オンライン申請、案件照会、意見の提出、フォーム入力、データ検索、その他の公共サービスまで多岐にわたります。
そのため、政府ウェブサイトの開発は「トップページにどのブロックを置くか」から始めるのではなく、「市民はこのサイトに来て何を済ませたいのか」から問い始める必要があります。
デジタル発展部が現在公表している「政府ウェブサイトサービス管理規範」は、ウェブサイトのライフサイクルを基礎とし、政府ウェブサイトサービスを6つの実行段階に分けています。
- 01
サイトの位置づけ
- 02
設計企画
- 03
開発構築
- 04
データ移行
- 05
公開準備
- 06
運用管理
同規範は、サイトの位置づけ、ユーザビリティ、開発環境、セキュリティ、データ移行、公開、公開後の運用など11の管理原則も定めています。つまり政府ウェブサイトプロジェクトが本当に納品するのは「新しいウェブページ」ではなく、公共サービスを継続的に提供できるウェブサイト環境なのです。
政府ウェブサイトの企画で先に確認すべき利用ニーズは？
結論
政府ウェブサイトの情報構造は、サービス対象と利用タスクから出発すべきであり、機関の組織図をそのままメニューに移すべきではありません。
政府機関の内部では、処・室・科・組といった業務単位で仕事を捉えるのが普通です。しかし一般市民がサイトに来たとき、最初に考えるのは「この件はどの科の担当か」ではなく、次のようなことです。
- どこで申請すればよいのか？
- どの資料を探せばよいのか？
- この補助金はどう手続きするのか？
- 自分の案件の進捗はどこで確認できるのか？
サイト構造が完全に内部組織に沿って設計されていると、利用者はまず機関の分担を理解しなければ必要な情報にたどり着けません。そのため、企画の初期段階で次のことを確認しておく必要があります。
- 利用者は誰か？
- 最も頻繁に済ませたいタスクは何か？
- どの情報が利用者にとって最も重要か？
- トップページから何ステップで必要なサービスにたどり着けるか？
- 異なるデバイスでも操作は一貫しているか？
「政府ウェブサイトサービス管理規範」は現在、ユーザー中心設計を明確に強調しており、ユーザーリサーチを通じてサービス対象のニーズと課題を把握したうえでサイトの位置づけと設計を行うことを推奨しています。また、分かりやすく一貫したインターフェース、使いやすい検索、レスポンシブウェブデザイン（RWD）などモバイルに適した設計も推奨しています。
これは、リニューアルが旧サイトの「見た目を整える」だけでは済まないことも意味します。本当の問題が、情報が見つからない、メニュー分類が市民の理解と合わない、検索結果が使いにくい、スマートフォンで操作しづらい、といった点にあるなら、ビジュアルデザインを新しくしただけではこれらの問題は残ったままです。
| 確認項目 | 開発前に確認しておきたいこと |
|---|---|
| サイトの目的 | このサイトは主にどの公共情報やサービスを提供しますか？ |
| 利用者 | 誰が使いますか？利用者ごとの主なニーズは何ですか？ |
| 利用タスク | 市民が最も頻繁に済ませたいことは何ですか？ |
| 情報構造 | 利用者はメニューと分類をすぐに理解できますか？ |
| モバイル対応 | スマートフォンで主要機能を問題なく閲覧・操作できますか？ |
| アクセシビリティ | UI・コンテンツ・操作は設計段階からアクセシビリティを考慮していますか？ |
| セキュリティ | ログイン、個人情報、フォーム、申請、システム連携を含みますか？ |
| データ移行 | 旧サイトのどのコンテンツを残し、廃止し、再整理しますか？ |
| 公開 | 本番環境、データ、機能、検査をどのように確認しますか？ |
| 運用 | 公開後、誰がコンテンツ・システム・セキュリティ更新を管理しますか？ |
これはすべての政府ウェブサイトが法令上採用しなければならない固定の要件表ではなく、外部委託で構築する前にサイトの範囲が漏れなく整理されているかを確認するための企画上の手法です。
政府ウェブサイトのアクセシビリティはいつから始めるべきか？
結論
ウェブアクセシビリティは、情報構造、UI／UX、フロントエンド開発の段階から組み込むのが最善であり、サイト完成後に修正を始めるべきではありません。
アクセシビリティが影響する範囲は「文字の拡大」よりはるかに広いからです。たとえば次のような点です。
- ボタンはキーボードだけで操作できるか？
- フォーカスの順序は妥当か？
- 画像内の重要な情報に適切な代替テキストがあるか？
- フォームの入力ミス時に、利用者はどこが間違っているか分かるか？
- インタラクティブなメニューを展開したとき、支援技術の利用者は現在の状態を理解できるか？
- 見出しレベルとHTML構造は情報の関係を正しく表しているか？
これらはいずれもUI／UXとプログラム開発に直結します。現在、デジタル発展部の政府ウェブサイト管理規範は、機関に対しウェブアクセシビリティ規範に基づき障害のある人が使いやすいサイト環境を提供することを明確に求めています。現行のウェブアクセシビリティ規範では、たとえば「キーボード操作可能」の項目で、サイト機能をキーボードインターフェースで操作できることを求めており、その目的は異なる入力方法や支援技術を使う利用者もサイト上のタスクを完了できるようにすることにあります。
2026年、政府ウェブサイトのアクセシビリティ規範は版の切り替え中
この点は、いま発注準備中または開発中の政府ウェブサイトにとって特に重要です。
デジタル発展部は2026年5月29日に新版「ウェブアクセシビリティ規範」を改正公布し、2026年11月30日から「ウェブアクセシビリティ規範（115.11）」を認証マーク検測に正式に使用すると公告しました。同日以降、「ウェブアクセシビリティ規範（110.7）」に基づく新規マーク申請は受け付けられなくなりますが、2026年11月29日以前に取得した旧版の認証マークの有効期間は引き続き3年間維持されます。
したがって、2026年末以降に公開してマークを申請する予定のプロジェクトでは、要件定義と開発方法を、新規申請の受付が間もなく終了する旧版規範だけに基づいて進めるのは適切ではありません。これは政府ウェブサイト開発で見落とされやすい点です。開発の根拠は入札時点だけで判断するのではなく、検収と本番公開の時点で適用される版も考慮する必要があります。
また、現行の「各級機関・機構・学校ウェブサイトアクセシビリティ検測及び認証マーク発行弁法」の関連説明によれば、各級政府とその付属機関（機構）・学校は、情報サービスウェブサイトのアクセシビリティ機能を自ら検測し、主管機関に登録する必要があります。個々のプロジェクトがA・AA・AAAのどの等級を取得すべきかは、プロジェクトの要件、入札書類、適用規定に基づいて確認すべきであり、「すべての政府ウェブサイトはAAでなければならない」を通則として扱うべきではありません。
政府ウェブサイトのセキュリティと個人情報で注意すべきことは？
結論
政府ウェブサイトが静的コンテンツにとどまらず、ログイン、オンライン申請、個人情報、データベース、システム連携に関わり始めた時点で、セキュリティはサイトの要件とシステムアーキテクチャに直接影響します。
たとえば、機関の情報を提供するだけのサイトと、会員登録、書類アップロード、個人情報の入力、案件進捗の照会、ログイン後の個人情報閲覧ができるサイトは、どちらも「政府ウェブサイト」と呼ばれますが、実際に対処すべきセキュリティリスクはまったく異なります。そのため、開発前に次のことを確認します。
- サイトはどのデータを収集するか？
- どの情報はログインしないとアクセスできないか？
- どのような利用者ロールがあるか？
- 管理画面機能は存在するか？
- 他のデータベースやAPIと連携するか？
- システムが攻撃や停止に遭った場合、どのような影響が出るか？
現行の「サイバーセキュリティ管理法」第10条は、その適用範囲において、公務機関または特定非公務機関が情報通信システムの構築・運用または情報通信サービスを外部委託する場合、適切な受託者を選任し、受託者に有効なサイバーセキュリティ管理体制の構築を求めてその実施を監督し、関連する権利義務と契約違反時の責任を書面の契約に明記しなければならないと定めています。
現行の「サイバーセキュリティ責任等級区分弁法」第11条も、各機関が自ら開発または外部委託で開発する情報通信システムについて、規定に基づき情報通信システムの防護要件の等級区分を完了し、対応する防護基準に従って管理措置を実施しなければならないと定めています。
ただし、これはすべての政府ウェブサイトを同じセキュリティ要件で扱えるという意味ではありません。本当に必要なのは、まずサイトにどのシステムとデータが含まれるかを確認し、そのうえでそのプロジェクトに実際に適用されるセキュリティ要件を確認することです。「政府ウェブサイトサービス管理規範」も現在、「サイバーセキュリティ管理法」「個人情報保護法」「政府情報公開法」およびウェブアクセシビリティ規範を、政府ウェブサイト開発構築時に確認すべき関連規定として挙げています。
つまり、セキュリティと個人情報は、サイトが完成してから追加する「検収項目」ではなく、もともと開発要件の一部なのです。
政府ウェブサイトの技術とシステムアーキテクチャはどう計画するか？
結論
政府ウェブサイトの技術選定は開発スピードだけで判断すべきではなく、互換性、ライセンス、セキュリティ、将来の運用、拡張のしやすさも考慮する必要があります。
政府ウェブサイトは通常、1年だけ使われるものではありません。そのため開発時に本当に避けるべきなのは、公開後になって次のようなことに気づく事態です。
- 元のベンダーしか修正できない
- フレームワークのメンテナンスがすでに終了している
- サードパーティ製パッケージのライセンスが不明確
- ブラウザ更新後に機能が異常になる
- プログラム構造を引き継ぐのが難しい
現行の「政府ウェブサイトサービス管理規範」は、「オープンソースのツールとシステムを優先し、国際的な共通標準と互換性のある開発構築環境を採用すること」を管理原則の一つに挙げています。また、クロスブラウザと機能拡張の互換性を備え国際標準を採用すること、サードパーティ製パッケージ・開発フレームワーク・ライブラリを使用する場合はその内容・出所・ライセンスを棚卸しし、アクセシビリティ・プライバシー・セキュリティ要件を継続的に満たすことも推奨しています。
これは、すべての政府ウェブサイトが同じCMS、プログラミング言語、フレームワークを使わなければならないという意味ではありません。より重要なのは、開発前に次の点をはっきりさせておくことです。
- その技術はいまも継続的にメンテナンスされているか？
- 将来、他のチームが合理的に引き継げるか？
- 使用するパッケージとライセンスは明確か？
- サイトは主要ブラウザと異なるデバイスに対応できるか？
- システムアーキテクチャは今後の機能拡張に耐えられるか？
- ソースコード、ドキュメント、デプロイ方法は最終的にどう引き渡されるか？
こうした問いは、「どの人気フレームワークを使うか」よりも、政府ウェブサイトの今後5年あるいはそれ以上の運用コストに大きく影響することが多いのです。
リニューアル時のデータ移行と公開で注意すべきことは？
結論
政府ウェブサイトのリニューアルは、旧サイトのデータをすべて新サイトへコピーすることではなく、どの情報を残しどう変換するかをまず決め、新サイトがサービスを正式に引き継ぐ際にデータ・機能・URLが途切れないようにすることです。
長年運用された政府ウェブサイトには、大量のプレスリリース、お知らせ、法規文書、PDF、イベント資料、画像、過去の特設コーナーが蓄積されていることがあります。リニューアル時にこれらをそのまま新サイトへ移すのが最善とは限りません。すでに古くなったコンテンツもあれば、保存は必要でも主要ナビゲーションに残す必要のないもの、新サイトで再分類が必要なものもあるからです。したがって、データ移行の前に棚卸しを行う必要があります。
現行の「政府ウェブサイトサービス管理規範」は「データ移行」をウェブサイトのライフサイクルにおける独立した実行段階として位置づけ、データとサービスの継続性への配慮を求めています。既存サイトの移行については、旧サイトのデータ構造とデータ量の棚卸し、移行リストの確定、新旧サイトのディレクトリとデータの対応関係の定義も推奨しています。
データ移行にはもう一つの問題があります。URLです。市民、検索エンジン、他の政府サイト、外部文書からすでに参照されているURLがリニューアル後にすべて無効になれば、利用者は元の資料を見つけられなくなる可能性があります。そのため、新旧サイトの切り替え前には、データ自体に加えて重要なURLとコンテンツの対応関係を棚卸しし、必要に応じてリダイレクトやその他の移行措置を計画します。アクセシビリティマークの公式FAQも現在、新旧サイトの移行期間がある場合、旧サイトはリダイレクトまたは案内を提供すべきだと注意喚起しています。
政府ウェブサイトの公開前に何を再確認できるか？
本番公開は「DNSを切り替えれば完了」ではありません。政府ウェブサイト運営交流プラットフォームも現在、公開準備を独立した段階と位置づけ、公開前に本番環境の安定性、性能、セキュリティ、データベースとデータ同期などの問題を考慮する必要があると指摘しています。したがって、少なくとも次の点を再確認します。
- 機能は完成しているか？
- 本番データは正しいか？
- データ移行は完了しているか？
- 利用者権限は正しいか？
- モバイル端末と主要ブラウザで正常に動作するか？
- アクセシビリティ関連の要件は満たされているか？
- 実施すべきセキュリティ作業は完了しているか？
- 本番環境の設定は正しいか？
- 旧サイトと新サイトをどう切り替えるか？
- 問題発生時の復旧・対応手段はあるか？
成熟した公開計画が考えるのは「切り替え当日に問題が起きたらどう対処するか」であり、「何時に公開できるか」だけではありません。
政府ウェブサイトの要件が開発に進める状態とは？
結論
すべての画面を描き終えるまで開発評価を始められないわけではありませんが、少なくともサイトの目的、利用者、情報構造、主要機能、データ、アクセシビリティ、セキュリティ、移行、検収の方向性について基本的な合意が必要です。
いくつかの問いで素早く判断できます。
なぜリニューアルまたは新規構築するのか？
答えが「今のサイトが古いから」だけなら、さらに問いを続けます。本当の理由は次のどれでしょうか。
- スマートフォンで操作しづらい？
- 市民が資料を見つけられない？
- CMSの保守が難しい？
- 新しいオンラインサービスを提供できない？
- 技術とセキュリティが要件を満たさなくなった？
問題が異なれば、プロジェクトの範囲もまったく異なります。
利用者は何を済ませたいのか？
主なサービス対象は誰で、サイトに来てから最も重要な3〜5つのタスクは何でしょうか。
情報と機能の境界は明確か？
- コンテンツだけのものはどれか？
- 検索が必要なものはどれか？
- フォームが必要なものはどれか？
- ログインが必要なものはどれか？
- 実はすでに情報システムであるものはどれか？
規範は要件に組み込まれているか？
アクセシビリティ、セキュリティ、個人情報、そして案件固有のその他の適用要件は、初期段階で洗い出されていますか。
旧サイトのデータはどう扱うか？
どのコンテンツを移行、廃止、アーカイブ、再整理しますか。
最終的にどう検収するか？
「画面がデザイン案と一致している」以外に、どの機能、互換性、データ、アクセシビリティ、セキュリティ要件を確認する必要がありますか。
これらの問いにおおむね答えられるなら、プロジェクトはもはや「新しい政府ウェブサイトを作りたい」という段階ではなく、見積もり、設計、開発へ進める構築範囲が形になり始めています。まだ未確認の問いが多くても、すべての技術的な答えを先に自分で考え切る必要はありません。まず利用者ニーズ、情報構造、既存コンテンツとシステムの棚卸しを完了し、そのうえで段階的に正式なサイト仕様を形にしていくのが適切です。
よくある質問
「すべての政府ウェブサイトは一律AAを取得しなければならない」を通則として扱うことはできません。現行制度にはA・AA・AAAの等級があり、各級政府とその付属機関（機構）・学校は関連弁法に基づいて情報サービスウェブサイトのアクセシビリティ検測と登録を行う必要があります。個々のプロジェクトが達成すべき等級は、機関の要求、入札書類および適用規定によって確認します。
ウェブサイト開発は、完成後に規範を補うものではない
政府ウェブサイトは、サービス対象、情報構造、UI／UX、ウェブアクセシビリティ、セキュリティから、既存データの移行と本番公開まで、どの要件もサイトの設計と技術アーキテクチャに直接影響しうるものです。
プロジェクトの早い段階でこれらの条件をはっきりさせるほど、サイト完成後にインターフェース、プログラム、データ構造を作り直すリスクを下げることができます。
本文で引用した法令・基準
- 政府ウェブサイトサービス管理規範政府ウェブサイト運営交流プラットフォーム
- ウェブアクセシビリティ規範デジタル発展部
- 各級機関・機構・学校ウェブサイトアクセシビリティ検測及び認証マーク発行弁法デジタル発展部
- サイバーセキュリティ管理法 第10条現行法規
- サイバーセキュリティ責任等級区分弁法 第11条現行法規
上記は執筆時点で引用した法令・基準です。改正される場合がありますので、実際の適用は所管官庁の最新の公告をご確認ください。