政府の公共サービス情報ポータルの作り方

目標、利用者、成功指標を定義する

公共サービスポータルは初日から「誰にでも全部」を目指すべきではありません。調達やリーダーシップ、最前線の職員が読めるワンページの目的文をまず書いてください。

ポータルの目的を明確にする

ポータルが主にどちらかを決めます：

• 情報（方針、適格性、窓口時間、必要要件）
• トランザクション（申請、支払い、予約、状況確認）
• 両方、ただしローンチ時に提供する高優先度サービスを定義する

この決定はコンテンツ構造から本人確認、サポート体制に至るまでその後の全てに影響します。

主な利用者（と彼らのニーズ）を名付ける

主要グループと彼らが完了すべきトップタスクを列挙します：

• 住民: 給付を見つける、書類を更新する、問題を報告する
• 訪問者: 許可、交通、安心・安全の情報
• 事業者: 営業許可、税務ガイダンス、コンプライアンス手順
• 内部スタッフ: コンテンツ更新、リクエストの仕分け、サービス変更の管理

実務的に：利用者は人口統計ではなく「何をしようとしているか」で定義します。

実際に追える成功指標を選ぶ

小さなセットの測定可能な成果に合意します。例えば：

• 上位ジャーニーのタスク完了率（例：「駐車許可を申請する」）
• ポータルで解決すべき質問による通話・窓口数の減少
• 更新の公開時間（緊急通知や方針変更など）
• 検索成功率（ユーザーが繰り返し検索せずに正しいページを見つけられるか）

これらをどう測るか（解析、短いフィードバック、コールセンターのタグ付け）も計画してください。

制約を早めに文書化する

範囲を形作る現実を記録します：

• 予算とスケジュール（承認を含む）
• 調達ルールとベンダー要件
• 法的/コンプライアンス要件と内部レビュー手順

シンプルな目標と指標のブリーフがあれば、後で優先順位が競合しても公共の価値に集中できます。

人々がサイト上で何をする必要があるかを調査する

良い政府ポータルは「人々は何を達成しようとしているか」を起点にします。内部部門を基準に設計すると、住民が官僚制を平易な目的に翻訳しなければならなくなります。調査はそこを逆転させます。

実際の需要シグナルから始める

既に持っている情報源から「トップタスク」を集めます：

• コールセンターと窓口ログ（問い合わせ理由、繰り返される質問）
• サイト内検索クエリとゼロリザルト検索
• サービス利用後の短いアンケート（オンライン・対面）

「更新」「申請」「支払う」「通報」「状況確認」といった動詞に着目し、これらがナビゲーションラベル、ランディングページ、フォームフローを形作ります。

影響の大きいサービスのジャーニーをマップする

優先サービス（例：許可、給付、支払い）をいくつか選び、ユーザー視点でジャーニーをマップします：

• ニーズを引き起こすトリガー（ライフイベント、締切、通知）
• 集めるべき情報
• つまずきやすい場所（適格性、書類、本人確認）
• 「完了」の定義（確認、受領、所要期間、次のステップ）

これにより、方針を説明するだけで完了に導けないポータルを防げます。

ニーズに焦点を当てたペルソナを作る

ペルソナはシンプルかつ実務的に：「初めて支援を申請する人」「手数料を支払う小規模事業者」「英語が不自由な住民」など。制約（時間、ストレス、デバイス、識字、アクセシビリティの必要性）に焦点を当ててください。

コミットする前に素早く検証する

短いインタビューや軽量のユーザビリティテストをプロトタイプやスケッチで行い、参加者に主要タスクを完了して期待を語ってもらいます。曖昧な用語、欠けている手順、信頼の問題を早期に発見でき、コンテンツや構築が固まる前に高コストな手戻りを避けられます。

情報アーキテクチャとナビゲーションを計画する

公共サービスポータルは、どの部署が所有しているかを知らない人でも必要な情報を素早く見つけられると成功します。情報アーキテクチャ（IA）はサイトの「地図」です：どんなコンテンツがあり、どうグループ化され、ユーザーがどう移動するか。

正直なコンテンツインベントリから始める

メニューを描く前に既存資産を収集します：

• 既存のウェブページ、マイクロサイト、キャンペーンページ
• PDF、ダウンロードフォーム、スキャンされた書類
• サービス説明、適格ルール、手数料、処理時間

各アイテムにトピック・対象・サービス種別・最終更新日・所有チームといった基本メタデータを付けます。これで既にあるページを無駄に作り直すことを防ぎ、古くなったり重複したコンテンツを浮き彫りにできます。

組織図ではなく利用者タスクで整理する

多くの住民は「運転免許を更新する」「給付を申請する」「問題を報告する」といった意図を持って到達します。カテゴリは部局名ではなくそのタスクを中心に構成してください。簡単なテスト：誰かが政府の構造を知らなくても正しいメニューを推測できなければ、そのグルーピングは見直すべきです。

複数の機関が一つのジャーニーに関与する場合は、1つのサービスとして扱い、単一のサービスハブから要件、必要書類、連絡先へのリンクを提供します。

ナビゲーションは予測可能に短くする

ホームから主要サービスへ2～3クリックで到達できることを目標にします。トップレベルカテゴリは少数に抑え、需要の高いタスクへのショートカットを目立たせます。内部用語であふれる「メガメニュー」は避け、実際に口に出すような平易なラベルを使います。

サイト検索は単なる機能ではなく公共サービスとして設計する

検索は主要なナビゲーションになることが多いので意図的に設計します：

• ユーザーが期待するフィルタ（場所、サービス種別、適格性、ライフイベント）
• 同義語や一般表現（例：「ゴミ回収」対「廃棄物収集」）
• 「結果なし」の時の有益な案内（推奨語句、人気サービス）

良いIAとナビゲーションは通話や苦情、離脱を減らし、ポータルを落ち着いて信頼できるものにします。

アクセシビリティと包括的利用のために設計する

アクセシビリティは政府サイトの「おまけ」ではなく、サービスへの平等なアクセス提供の一部です。目標はWCAG（通常はWCAG 2.2 AA）を満たすことで、アクセシビリティを最終レビューではなく設計要件として扱ってください。

人とツールが理解できる構造から始める

明確なページ構造を使います：一つの主見出し（H1）、論理的な副見出し（H2/H3）、記述的なリンクテキスト（「ここをクリック」等は避ける）。一貫したナビゲーションと予測可能なページレイアウトは、認知障害のある人やスクリーンリーダー利用者を含め誰にとっても助けになります。

読みやすさを容易にする：高コントラストの配色、適切な行長、極小フォントを避ける。インタラクティブ要素は一貫したフォーカス状態を持ち、キーボード利用者が現在位置を常に確認できるように。

実際の支援技術でテストする

自動チェックは有用ですが全ては検出できません。完了定義の一部として手動テストを含めます：

• キーボードのみで主要ジャーニーを操作する
• スクリーンリーダーでテスト（NVDA, JAWS, VoiceOverなど）
• モバイルで200%ズームとリフローをチェック

平易な言葉で書く

包括的設計は言葉にも関係します。平易な言語を使い、必要な手順を説明し、専門用語や略語は避けるかその場で定義します。

フォームは端から端までアクセシブルにする

フォームはつまずきの原因になりがちです。全てのフィールドに可視のラベル、混乱が予想される箇所には明確なヘルプテキスト、エラーメッセージは具体的で支援技術に伝わるようにします（例：「国民保険番号を入力してください」）。エラー表示に色だけを使わないでください。

アクセシビリティ声明とフィードバック経路を公開する

準拠状況、既知の問題、報告手段を説明するアクセシビリティ声明をフッターの一貫したリンク（例：/accessibility）に置き、報告経路を監視して対応してください。

コンテンツガバナンスと編集ワークフローを整備する

公共サービスポータルは情報が正確に保たれるかで成功が決まります。コンテンツガバナンスは「何を、誰が、どうやって、どうチェックして、どう更新するか」という現実的な仕組みです。これがないとページは陳腐化し、重複回答が現れ、信頼が損なわれます。

明確なコンテンツモデルから始める

タスクを割り当てる前に、サイトが公開する主な「モノ」を定義します。多くのポータルでシンプルなモデルは：サービス（手順）、ニュース、アラート、拠点情報、連絡先。各タイプについて必須フィールド（例：適格性、手数料、処理時間、必要書類、窓口時間）を決め、部門間でコンテンツの一貫性を保ちます。

所有権と編集ルートを定める

ガバナンスは責任が明確なときに機能します。以下を定義してください：

• 執筆者（主題のオーナー）
• レビュー者（方針/法務/広報）
• 承認者（最終責任者）
• 公開者（ウェブチーム）と、公開後に編集できる人
• 更新担当（所属組織ではなく名指しの役割）

ターンアラウンドの期待値と、緊急アラートや時間敏感な更新のためのルートも文書化します。

実際に使われるスタイルガイドを定める

平易で一貫した言葉遣いが必要です。スタイルガイドにはトーンや読みやすさ、承認済み用語と禁止用語、日付・時刻・住所・数字の表記方法、リンクのルール（例：「ここをクリック」は避ける）を含め、内部ワークフロー文書から参照できるよう一箇所にまとめます。

ライフサイクルルールをプロセスに組み込む

全てのページにレビュー日を設定し、「担当者が退職した」場合のフラグ付けを行います。コンテンツのアーカイブ時期、バージョン保存方法、変更ノートの記録方法を定義してください。バージョニングは役所仕事ではなく、何がいつなぜ変わったかを証明する手段です。

多言語かつ文化的に明確なコンテンツをサポートする

ポータルは主要言語で読めるかどうかに関わらず同等に使えるべきです。多言語対応は単なる翻訳ではなく、同じトップタスクを同じ自信で完了できるようにすることです。

まずは人々が必要とするサービスから始める

初日に全てを翻訳しようとしないでください。優先すべきページは：

• 適格性と「誰が申請できるか」のページ
• ステップバイステップの手順とチェックリスト
• 締切、手数料、必要書類
• フォームガイダンス、エラーメッセージ、確認ページ

この「トップタスク優先」アプローチで価値を早く提供し、重要なサービスの翻訳が部分的で古くなるリスクを減らせます。

重要な指示に自動翻訳を使わない

機械翻訳は発見用コンテンツには有用ですが、法的・安全・財務・コンプライアンスに関わる指示にはリスクがあります。締切を逃したり誤った書類を提出したり権利を誤解させる可能性があるものは、専門翻訳とレビューを行ってください。

非重要ページに機械翻訳を提供する場合は明示的に表示し、元の言語にワンクリックで戻れるようにします。

言語切替は利用者の位置を保つ

言語切替はコンテキストを保持すべきです：言語を変えたときに同じページ（理想は同じセクション）に留まるようにしてください。切替は見つけやすく予測可能に：

• 言語名は自国語で表示（例：「Español」「العربية」）
• サイトの一貫した場所に置く
• キーボードアクセスとモバイル対応を確保する

テキストだけでなくフォーマットもローカライズする

文化的明瞭さは細部にも関わります：

• 日付（例：26/12/2025 vs 12/26/2025）
• 通貨・数値の表記
• 住所・氏名入力欄のローカル慣習への対応
• 電話番号のフォーマットと例

フォームがある場合は各言語でプレースホルダ、検証メッセージ、ヘルプテキストが翻訳され文化的に理解できるかをテストしてください。

翻訳をワークフローに組み込む

翻訳が更新から遅れないようにガバナンスルールを追加します：

• 公開前に翻訳が必須なページをマークする
• ページごとの翻訳ステータスを追跡する
• 重要ページのレビューをスケジュールする

プラットフォーム選定時に、情報アーキテクチャとCMSがバージョン管理や言語別のコンテンツ関係をサポートしているか確認してください。

適切なCMSとコンテンツ構造を選ぶ

ポータルは、正確な情報を大規模に安定して公開できるかで成否が決まります。CMSは編集者にとって「安全な道」を最も簡単にする一方で、コンテンツを再利用可能な形で構造化するべきです。

必要なCMS機能

明確な権限と説明責任をサポートするCMSを選びます。最低でも、役割ベースのアクセス（例：執筆者、レビュー、承認者、管理者）、承認ワークフロー、誰がいつ何を変えたかを追える監査ログが必要です。

バージョン履歴と簡単なロールバックも同様に重要です。方針が速く変わるとき、チームは以前のリビジョンに戻せるので安心して更新できます。

表示とコンテンツを分離する

重要な情報を一回限りのページデザインに埋め込まないでください。構造化フィールド（タイトル、サマリ、適格性、必要書類、手数料、処理時間、連絡チャネル）を使い、同じコンテンツが：

• サービスページ
• 検索結果や「関連サービス」ブロック
• PDFや印刷ビュー
• 将来のチャネル（アプリ、キオスク、チャットサポート）

などで一貫して表示できるようにします。このアプローチは翻訳でも役立ち、フィールド単位で翻訳を同期できます。

市民のニーズに合った標準テンプレート

少数のページテンプレートを定義して、利用者が期待できる形にします：

• サービスページテンプレート： 概要、対象者、手順、必要書類、費用、所要時間、申請方法
• FAQテンプレート： 短い質問と平易な回答、公式サービスページへのリンク
• お知らせテンプレート： 何が変わったか、影響する人、発効日、支援先

連携は早めに計画する

ポータルが接続すべきシステムを洗い出します：オンラインフォーム、支払いプロバイダ、ケース管理、地図/位置情報、予約、解析。どのコンテンツがCMSにあり、どのコンテンツを外部から引くかを決めてください。

プロトタイプ段階やジャーニー検証のために実装詳細を固める前に素早く試作したい場合、vibe-codingのような手法が役立ちます。例えばKoder.aiはチャットで市民向けフローを下書きし、動作するウェブアプリ（React）とバックエンド（Go + PostgreSQL）を生成して「計画モード」で反復できます。アプローチが検証できたら、ソースコードをエクスポートしてセキュリティレビューや調達要件に合わせて適合させられます。

安全な公開手順を文書化する

命名規則、レビュー規則、アクセシビリティチェック、緊急更新の手順を含む短い「編集者プレイブック」を作り、オンボーディングの一部にして中心的な場所（例：/content-guidelines）に置いて更新してください。

セキュリティとプライバシーを最初から組み込む

セキュリティとプライバシーは政府サイトの「追加機能」ではなくサービス品質の一部です。人々はポータルを安全だと感じ、扱いが明確で個人情報が丁寧に扱われるときだけ利用します。

収集を最小限に、説明を明確に

データ最小化から始めます。各フォームフィールドについて、平易に「なぜ必要か」と「ユーザーが提供しない場合にどうなるか」を答えられるようにしてください。「あると便利」なら削除するか任意にします。

データを収集する場合はフィールド横に短いヘルパーテキストを置き、埋めやすくして信頼を築きます。

セキュアなデフォルトを必須にする

全ページでHTTPSを使い、HTTPは自動でリダイレクトします。管理画面へのアクセスを厳格に：

• スタッフに強力なパスワードと多要素認証（MFA）を義務付ける
• 役割ベースの権限（ほとんどの編集者は管理者であるべきではない）
• プラグインやテーマは最小にし、定期的に更新する

フォームのスパム・悪用対策

公開フォームは自動化されやすく、最悪のタイミングで利用不能になります。単一のツールに頼らず複数の防御を組み合わせます：

• サーバーサイドの検証（ブラウザのみのチェックは信用しない）
• 送信のレート制限とスロットリング
• 実際のユーザーが修正できる明確なエラーメッセージ

分かりやすいプライバシー通知とクッキー方針を書く

地域のルールに合わせたプライバシー通知を住民向けに分かりやすく書きます。何を収集し、なぜ、誰がアクセスでき、どれくらい保存するかを示します。クッキーは簡潔な同意方式にし、不必要なトラッカーは避けてください。

アップロードと機微データの安全な扱いを計画する

身分証明書などを受け取る場合は高リスクと見なし、ファイル種別の制限、アップロードのスキャン、安全な保存、アクセス制限を行います。削除プロセスを定義してテストし、要求があればデータを削除できることも確認してください。

パフォーマンスと信頼性を不可欠にする

人々は迅速な回答を求めてポータルに来ます—多くは古い端末や低容量の回線、不安定なネットワークを使っています。ページが重いかサイトが落ちていると信頼は即座に失われます。

遅い接続をまず想定する

「遅いが使える」を基準にします。デフォルトでページ重量を低く保つ：画像を圧縮し、自動再生メディアを避け、そのページのタスクに直接関係するスクリプトだけを読み込みます。

実務的なルール：ページが市民のサービスジャーニーを助けないなら、そのページでジャーニーを遅くしてはいけません。

公開コンテンツにキャッシュとCDNを使う

全員に同じコンテンツ（ガイド、適格基準、拠点情報）がある場合、キャッシュは読み込み時間とサーバー負荷を劇的に下げます。CDNは資産をユーザーに近い場所から配信し、急激な需要も吸収します。個人化されたページはキャッシュしないように注意してください。

パフォーマンス予算を明確にする

デザインやコンテンツ更新時に守る単純で測定可能な予算を定義し、施行します：

• 最大ページ重量（特にランディングページ）
• ミドルレンジのモバイル機でのTime to Interactive
• サードパーティスクリプトやフォントの制限

これらの目標を内部で公開し、コンテンツ・デザインチームにトレードオフを理解させます。

トラフィックスパイクに備える

締切、更新、気象イベント、緊急事態は大きなアクセス集中を生みます。ロードテスト、スケーラブルなホスティング、コアタスクは維持する「劣化モード」を用意しておきます（ステータス更新、主要フォーム、連絡手段など）。

公開前日から監視を行う

稼働監視、パフォーマンス追跡、アラートを公開前に組み込みます。実ユーザーパフォーマンスを追跡し、オンコール体制と対応手順を文書化して、問題に迅速かつ一貫して対処できるようにします。

動作するフォームとサービスジャーニーを設計する

人々はポータルに「何かをしに」来ます：申請、更新、通報、要請、支払い。フォームの仕事は彼らを最小限の努力で確実に完了させることです。

組織図ではなくユーザーのタスクから始める

ジャーニーを明確なステップに分けて設計します（例：適格性 → 詳細入力 → 書類 → レビュー → 提出）。現在地を示すシンプルな進行指標を表示し、各ステップで「今何をすべきか」を平易に示します。

エラーは有益で修正可能にする

日付、ID番号、ファイルサイズ制限、必須項目などの一般的な問題はインラインで検証し、離脱を減らします。問題がある場合はフィールド横に実行可能なメッセージを表示し（例：「生年月日はDD/MM/YYYYで入力してください」）、既に入力した内容は保持します。曖昧な「無効な入力」は避けます。

下書きと確認で離脱を減らす

長文の申請は下書きを保存して後で戻れるようにしてください。提出後は明確な受領を提供します：参照番号、提出内容、状況追跡方法。適切なら確認メール/SMSを送り、受取がない場合の対処法も案内します。

重要情報をPDFに隠さない

どうしてもPDFを出す場合はアクセシブルなHTML版を主要なオプションとして提供し、ダウンロード文書もアクセシビリティ要件を満たすようにします。これによりモバイル利用者とスクリーンリーダー利用者をサポートできます（参照：/accessibility）。

次に何が起こるかを説明する

提出直後に期待値を設定します：通常のタイムライン、審査段階、決定の伝え方、修正や異議申し立て方法。明確な次のステップは再度の問い合わせを減らし信頼を築きます。

信頼を測定し、改善し、維持する

公共サービスポータルは「完了」するものではありません。ニーズは変わり、方針は変わり、小さな使いにくさが大きな問題になります。継続的な測定と改善のルーチンで重要な問題を直し、説明責任を示し、公共の信頼を守ります。

人々が何をしようとして失敗しているかを追う

見せかけの指標ではなく成果に結びつくシグナルから始めます：

• サイト検索（上位クエリ、ゼロリザルト、検索の絞り込み）
• 上位タスクとその完了率（例：「申請」「更新」「状況確認」）
• 壊れたリンクと404（特に外部サイトからのリンク）
• フォーム離脱（どのステップで離脱するか、共通の検証エラー）

プライバシーに配慮した解析を使う

収集はサービス向上に最小限必要なデータに留めます。集計レポートを優先し、保存期間は短くする。URLや検索ログ、イベント名に機微な情報を入れないでください。セッション録画やヒートマップを使う場合は公開理由と厳格な管理を持つか、使わない選択も検討してください。

行動できるインサイトを関係者に見せる

コンテンツ担当やサービスチーム向けにシンプルなダッシュボードを作ります：「どのページが失敗しているか？」「どのコンテンツが古いか？」「どのフォームがサポートコールを引き起こしているか？」ダッシュボードは単なる報告で終わらず意思決定につながるべきです。

定期的にテストし最大の阻害要因から直す

四半期ごとに最もトラフィックの多いタスクで軽量なユーザビリティテストを実施し、エラー、混乱、繰り返しの問い合わせを減らす修正を優先します。

明確なトリアージを伴うフィードバックループを維持する

主要ページにフィードバックチャネルを設けます（例：「このページは役に立ちましたか？」と任意のコメント）。誰が読んでいるか、問題をどう分類するか（コンテンツバグ、技術バグ、方針の質問）、目標応答時間を定義し、フィードバックが改善につながるようにします。

ローンチと長期運用の準備をする

ポータルのローンチはゴールではなく実利用の始まりです。スムーズなローンチはサポートコールを減らし、信頼を守り、チームに安全に改善する余地を与えます。

実務的なローンチチェックリストを作る

非技術担当のローンチ責任者が実行できるチェックリストを作り、明確な合格/不合格基準を含めます。少なくとも以下を含めてください：

• アクセシビリティ: キージャーニーをキーボードのみ、スクリーンリーダー、コントラストチェックでテストし、最終的なWCAG監査の要約を用意する
• セキュリティ & プライバシー: TLS/HTTPS確認、クッキー確認、権限チェック、管理アカウントの整理、プライバシー通知の確認
• コンテンツ準備: トップタスク対応、古いページの削除、連絡先確認、PDFの最小化またはアクセシブル化、平易な言語でのレビュー
• リダイレクト & 継続性: 旧URLのリダイレクト、404ページのテスト、内部リンクチェック、解析タグの検証

編集者とサービスオーナーを訓練する

ローンチ前に訓練を行ってください。役割別の短いセッションを用意します：

• 編集者：ページの更新方法、テンプレート利用、アクセシブルな見出し/リンクの追加、レビュー依頼方法
• サービスオーナー：変更承認方法、ユーザーフィードバックの追跡、緊急更新のエスカレーション方法

訓練には実用的なハンドブックを添え、イントラネットや/helpなどで実際に見つけられる場所に保管します。

維持できる運用スケジュールを定める

定期タスクと担当を決めます：

• 週次：エラーレポートと壊れたリンクの確認
• 月次：パッチ適用、アクセス権確認、バックアップテスト
• 四半期：トップページと重要ジャーニーのコンテンツレビュ

インシデント対応を文書化する

停止やセキュリティ事象のワンページのランブックを作ります：オンコールは誰か、公開更新の方法、取得すべきデータ、法務/広報をいつ巻き込むか。ローンチ前に一度演習してください。

継続的改善の予算を確保する

ローンチ後の修正、ユーザー要望の改善、アクセシビリティ向上のための時間と資金を確保してください。小さな定期的な改善予算は数年ごとの大規模な作り直しに勝ります。