自治体の庁内申請FAQは、件数を増やしても見つからなければ役に立ちません。検索されやすくする近道は、FAQを「資料置き場」ではなく、「職員が実際に打ち込む言葉に答える小さなページ群」として設計することです。具体的には、職員が使う言葉で書く、1FAQを1論点に分ける、検索結果で意味が分かるタイトルにする、PDFだけに閉じ込めない。この4点を押さえると、庁内ポータル検索でもFAQ内検索でも当たりやすくなります。政府系のデザインガイドでも、利用者の言葉、説明的なタイトルや見出し、明確なリンクテキスト、HTML優先が見つけやすさと使いやすさの土台とされています。 (GOV.UK)
「FAQはあるのに電話やTeamsの質問が減らない」「各課で呼び方が違って検索に引っかからない」「制度改正のたびに古い回答が残る」。こうした悩みは珍しくありません。実際、自治体業務では、起案から決裁までの流れや権限設定、用語の定義が自治体ごとに異なり、表記の共通化自体が大きな論点になります。 (デジタル庁)
この記事では、自治体の庁内申請FAQを検索されやすく設計するコツを、情報設計、検索語の作り方、システム選定で見るべき仕様差、向く運用、FAQでは解決しきれない場合の代替策まで、実務目線で整理します。
自治体の庁内申請FAQでいう「検索されやすい」とは
庁内FAQで大事なのは、Google向けのSEOより先に、庁内検索・ポータル検索・FAQ内検索で見つかることです。つまり、職員が思いつく語でヒットし、結果一覧で迷わず選べ、開いた直後に答えが分かる状態が合格ラインです。説明的なページタイトルは検索結果やタブで内容を見分けやすくし、説明的な見出しやリンクテキストは目的の情報への到達を助けます。 (w3.org)
| 段階 | 合格ライン | よくある失敗 |
|---|---|---|
| 検索語 | 「残業申請」「旅費精算」など現場語でヒットする | 正式名称でしかヒットしない |
| 結果一覧 | タイトルだけで内容が分かる | 「申請について」のような抽象タイトルが並ぶ |
| ページ冒頭 | 最初の数行で結論と対象者が分かる | 前置きが長く、答えが後ろにある |
| 次の行動 | 関連FAQや申請先にすぐ進める | 読んだ後に何をすべきか分からない |
ここでいう「検索されやすさ」は、単に検索順位を上げる話ではありません。職員が迷わず自己解決できることまで含めて設計するのがポイントです。
自治体の庁内申請FAQが見つからない5つの原因
| 原因 | 現場で起きがちな状態 | 直し方 |
|---|---|---|
| 正式名称偏重 | 「超過勤務命令」はあるが「残業申請」でヒットしない | 利用者語を優先し、正式語は補足に回す |
| 1ページに詰め込みすぎ | 1本のFAQに期限・書類・承認・例外が全部入っている | 1FAQを1論点に分割する |
| タイトルが抽象的 | 「申請について」「操作方法」だけで内容が読めない | 質問文または具体的な作業名にする |
| PDFや巨大アコーディオン依存 | 答えが資料の中に埋もれる | HTML本文を基本にし、必要なら補助資料を添える |
| 運用責任が曖昧 | 制度改正後も古い回答が残る | オーナー、更新条件、見直し周期を決める |
公的サービスの設計では、利用者の言葉を使い、シンプルで分かりやすくし、実際の利用者で確かめることが重視されます。また、質問ページでは1ページ1質問が理解を助けるとされ、アコーディオンは有効性の根拠があるときだけ使い、必要な情報を隠しすぎないよう求められています。FAQでもこの発想がそのまま効きます。 (GOV.UK)
検索語から逆算して庁内申請FAQを設計する
FAQ名やタイトルを内向きの制度名で決めると、検索語とずれます。公的サービスの設計指針でも、名称は利用者の言葉を使い、分析やユーザーリサーチに基づき、技術名ではなくタスクを表すのがよいとされています。自治体の文脈でも、業務用語が自治体ごとに異なるため、表記の共通化が重要な論点でした。 (GOV.UK)
まず作るべきは、FAQ本文ではなく検索語の設計表です。
| 利用者が打つ語 | 正式用語 | FAQタイトル案 | 補助タグ例 |
|---|---|---|---|
| 残業申請、超勤、時間外 | 超過勤務命令 | 超過勤務の申請はいつまでに出す？ | 時間外、期限、承認 |
| 旅費精算、出張精算 | 旅費請求 | 出張後の旅費精算はどの手順で行う？ | 出張、精算、手順 |
| 備品申請、物品購入 | 物品購入依頼 | 物品購入申請で見積書が必要になるのはどんな場合？ | 物品、見積書、添付 |
| 代理承認、代理決裁 | 代理処理 | 所属長が不在のとき代理承認はできる？ | 承認、代理、例外 |
実務では、次の3つを同時に集めると精度が上がります。
- 電話、メール、チャット、窓口で実際に出た質問
- ワークフロー画面やマニュアルに書かれている正式用語
- 旧システム名、略称、課内での通称
ここで重要なのは、正式用語を捨てることではなく、検索の入口を利用者語にすることです。タイトルは利用者語寄り、本文冒頭やタグ、同義語辞書には正式語も入れる。この二層構造にすると、検索語のぶれに強くなります。
1FAQを1論点に分ける
公的サービスの質問ページ設計では、1ページ1質問にすると、利用者が何をすべきか理解しやすく、焦点も定まります。FAQはフォームそのものではありませんが、1FAQを1論点に寄せるほど検索語とタイトルを一致させやすく、結果一覧の選びやすさも上がります。 (GOV.UKデザインシステム)
「1論点」とは、たとえば次のどれか1つです。
- できるか
- いつまでか
- 何が必要か
- どこで操作するか
- 例外時にどうするか
悪い例は、「出張申請Q&A」のように広すぎるページです。これでは「見積書」「承認」「精算」「締切」など検索意図が混在し、どの語で検索しても中途半端にしか当たりません。
分け方の例はこうです。
- 出張申請はいつまでに提出する？
- 出張申請で見積書が必要になるのはどんな場合？
- 所属長が不在のとき出張申請を代理承認できる？
- 出張後の旅費精算で必要な添付書類は何？
FAQを分けると更新が面倒に見えますが、実際は逆です。制度改正で「期限」だけ変わったとき、1ページ丸ごと直すより、期限FAQだけ差し替える方が安全で速くなります。
FAQタイトル・見出し・回答本文の作り方
タイトルは「質問文」か「やること」で書く
W3Cは、説明的なページタイトルが検索結果やサイトマップの一覧で目的の情報を見つけやすくすると説明しており、リンクテキストと遷移先タイトルが近いことも良い実践としています。デジタル庁のデザインシステムでも、見出しはページを構造化する要素として扱われています。 (w3.org)
タイトルの基本形は、次のどちらかです。
- 質問文で書く
例：物品購入申請で見積書が必要になるのはどんな場合ですか - やることで書く
例：財務会計システムで支出負担行為を起票する手順
避けたいタイトルは、次のようなものです。
- 申請について
- 操作方法
- 財務会計システム
- 人事関係FAQ
タイトルだけ見て内容が想像できないものは、検索結果でも選ばれません。
見出しは答えの骨格にする
見出しは飾りではなく、答えの構造そのものです。W3Cは、見出しやラベルが主題や目的を表すほど、利用者が情報を見つけやすくなると説明しています。デジタル庁のデザインシステムでも、見出しレベルを飛ばさず、セクションの主題を具体的に書くことが求められています。 (w3.org)
庁内申請FAQなら、見出しは次の順番にすると崩れにくいです。
| セクション | 書く内容 |
|---|---|
| 結論 | 必要・不要、できる・できないを最初に示す |
| 対象者 | 誰に当てはまる話かを書く |
| 条件・判断基準 | どんな場合に当てはまるかを整理する |
| 手順 | 実際の操作や提出の流れを書く |
| 例外 | 代理、締切後、紙申請などを分ける |
| 関連FAQ | 次に迷いやすい論点へつなぐ |
回答は冒頭2〜3行で結論を出す
長い説明を積み上げて最後に結論を書くと、読まれません。公的UIの文言設計でも、利用者の言葉で直感的に理解できること、余計な説明を増やしすぎないことが重視されています。 (GOV.UK)
冒頭は、次の形にすると読みやすくなります。
結論：原則として必要です。
対象：物品購入申請のうち、比較検討が必要な案件。
例外：定型購入や既契約の範囲内で処理する場合は不要なことがあります。
この3行で概要がつかめれば、その下の詳細条件や手順も読まれやすくなります。
リンク文言も検索語の一部と考える
リンク文言は「詳細はこちら」「もっと見る」ではなく、遷移先をそのまま言い当てる表現にします。デジタル庁のガイドでは、リンクテキストは利用者がリンク先の情報が必要かどうかを判断する手掛かりであり、「ここ」「こちら」だけをリンクにしないよう示されています。 (デジタル庁デザインシステムβ版)
たとえば関連記事へのリンクは、次のように書きます。
- 悪い例：詳細はこちら
- 良い例：
代理承認できない場合の差戻し手順を見る
関連FAQ同士のリンク文言まで具体化すると、検索結果だけでなくページ内回遊も改善します。
PDFとアコーディオンの使いどころを間違えない
FAQ本文はHTMLを基本にし、PDFは補足資料の位置づけに留めるのが無難です。デジタル庁のアクセシビリティガイドでは、見出しや箇条書きが正しく記されたHTMLページが最もアクセシビリティの高い形式とされ、PDFを使う場合もHTML版の用意や構造化が推奨されています。 (デジタル庁)
特に避けたいのは、次の状態です。
- 回答がPDFマニュアルの中にしかない
- PDFがスキャン画像で、本文検索できない
- 「申請全般」のアコーディオン1ページに全部押し込む
- アコーディオンを何段も入れ子にする
アコーディオン自体は悪くありません。デジタル庁やGOV.UKのガイドでも、同種の項目を一覧で見せる用途には向くとされています。反対に、全員が読むべき情報を隠す用途には向かず、長い内容はページ分割や見出し構造で見せる方がよいとされています。 (デジタル庁デザインシステムβ版)
実務上の判断はシンプルです。
- 日常的に検索される質問は、独立したHTMLページ
- 印刷前提の様式や通知は、PDFを添付しつつHTMLで要点も記載
- カテゴリ一覧は、必要に応じてアコーディオン
- 全員が確認すべき条件は、隠さず本文に出す
分類・タグ・導線で取りこぼしを減らす
FAQの検索性は、タイトルだけでなく分類設計でかなり変わります。入り口を「総務課」「人事課」「財政課」のような組織名に寄せすぎると、利用者は自分がどこを見るべきか判断しづらくなります。導線は部署起点より、やりたいこと起点で作る方が迷いにくくなります。名称は利用者の言葉で、技術名よりタスクを表す方がよいという考え方とも相性がよいです。 (GOV.UK)
| 分類軸 | 例 | 効く場面 | 注意点 |
|---|---|---|---|
| 申請種別 | 休暇、出張、物品購入、契約 | 最初の入口 | 課名やシステム名だけにしない |
| 利用者属性 | 一般職員、承認者、経理担当 | 権限や役割でルールが違うとき | 細かく分けすぎない |
| 工程 | 起票、承認、差戻し、精算、完了後 | 操作系FAQに強い | システム固有語だけに寄せない |
| 例外 | 代理申請、締切後、紙申請、システム停止時 | 問い合わせが増えやすい論点 | 更新漏れに注意 |
| 添付物 | 見積書、請求書、委任状 | 必要書類検索に強い | 名詞タグを増やしすぎない |
タグは多ければよいわけではありません。1ページあたり3〜5個程度の主要タグに絞り、旧称や通称は同義語辞書か本文冒頭で拾う方が運用しやすくなります。
システム選定で確認したい検索仕様の差
FAQシステムや庁内ポータルは、画面の見た目よりも検索仕様の差が大きいです。ここを見落とすと、運用で吸収しきれません。
| 確認項目 | 見るポイント | 運用への影響 |
|---|---|---|
| 索引対象 | タイトル、本文、タグ、PDF、添付のどこまで検索対象か | PDF中心運用が成立するか変わる |
| 同義語辞書 | 旧称、略称、言い換えを登録できるか | 用語ぶれに強くなる |
| 権限連動 | 閲覧権限のないFAQが結果に出ないか | 情報漏えい防止に直結する |
| 絞り込み | 申請種別、役割、工程などで絞れるか | 件数が増えたときに効く |
| スニペット表示 | ヒット箇所や要約が結果に出るか | タイトルが似たときの選びやすさが変わる |
| 更新反映速度 | 公開後どのくらいで検索に反映されるか | 制度改正や締切変更時に影響する |
| 検索分析 | ゼロ件検索、人気語、検索後離脱が見られるか | 改善の回転速度が変わる |
| 重複対策 | 同内容ページの整理や正本管理ができるか | 検索結果のノイズを減らせる |
特に、自治体の庁内申請FAQで優先度が高いのは、同義語辞書・権限連動・検索分析です。ここが弱いと、結局は「正式名称を覚えてもらう」「部署別に検索し直してもらう」「改善点が分からない」という運用になります。
自治体の庁内申請FAQに向く運用体制
運用は、全ページを中央で抱えるか、各課に丸投げするかの二択ではありません。デジタル庁の事例では、運用担当が利用者目線で文面を点検する仕組みと、閲覧データやフィードバックを組み合わせて改善優先度を決める仕組みが使われています。自治体間で用語差が大きいことを踏まえると、表記ルール・分類・検索語辞書は中央で持ち、制度内容の正しさは各課が責任を持つハイブリッド型が最も回しやすいです。 (デジタル庁)
| 運用方式 | 向くケース | 強み | 弱み |
|---|---|---|---|
| 中央集約型 | FAQ件数がまだ少ない、担当者を絞りたい | 表記や品質を揃えやすい | 更新が詰まりやすい |
| 各課分散型 | 専門領域が多く、更新頻度が高い | 内容更新が速い | 用語ぶれ、重複、品質差が出やすい |
| ハイブリッド型 | 多くの自治体におすすめ | 品質統一と更新速度の両立がしやすい | ルールと役割分担の設計が必要 |
おすすめの役割分担は、次の形です。
- 中央担当
テンプレート、分類、同義語辞書、検索ログ分析、品質チェック - 各課の回答責任者
制度内容の正確性確認、改正時の差し替え - 定例レビュー
月1回で、ゼロ件検索語、問い合わせ増加テーマ、古いFAQを確認
この形にすると、「言い回しは揃っているのに中身が古い」「中身は正しいのに検索で出ない」という両方の失敗を避けやすくなります。
FAQで解決しにくいケースと代替策
FAQだけで解こうとすると、複雑な適用条件や長い手続きで読み手が迷います。公的サービスの設計では、適否判定が複雑なら「簡単な質問に答えると結論が出る」流れ、開始から完了まで順序があるならステップ型ナビゲーション、順不同で長期にわたる作業ならタスクリストが向くと整理されています。 (GOV.UKデザインシステム)
| ケース | FAQだけでは弱い理由 | 向く代替策 |
|---|---|---|
| 適用条件が複雑 | 長文条件を読まないと結論が出ない | yes/no形式の判定フロー |
| 手順が長く順序が重要 | 途中で迷子になりやすい | ステップ型ガイド |
| 複数の作業を別日に進める | どこまで終わったか分かりにくい | タスクリスト |
| 個別事情で回答が分かれる | FAQでは答えが抽象化されすぎる | 問い合わせフォーム、チケット |
| 画面操作の理解が必要 | 文章だけでは伝わりにくい | 画面付き手順書、短い解説動画 |
生成AIチャットを使う場合も、まず先に正本となるFAQページを整えるのが先です。チャットは入口として便利ですが、一次情報が曖昧なままだと、回答の再現性も更新管理も崩れます。AIを入れる前に、タイトル・見出し・正本ページを整える。順番を間違えないことが大切です。
公開後に追うべき指標
公開後はPVだけで判断しないことが重要です。デジタル庁のウェブ運用事例では、「探していた情報が見つかったか」の簡潔なフィードバックと閲覧データを組み合わせ、閲覧数が多く不満の多いページを優先改善していました。庁内FAQでも、ゼロ件検索語、検索語の言い換え回数、ページの見つかった率、同テーマの問い合わせ件数をセットで追うと改善点が見えやすくなります。 (デジタル庁)
| 指標 | 何が分かるか | まず打つ手 |
|---|---|---|
| ゼロ件検索語 | FAQが足りない、言い換えを拾えていない | 新規FAQ作成、同義語追加 |
| 同じ意味の検索語の乱立 | タイトルや分類が伝わっていない | タイトル修正、ページ分割 |
| 検索後すぐ離脱 | 結果一覧で選べていない、答えが弱い | タイトル、冒頭要約、スニペット見直し |
| 「見つからなかった」率 | 内容不足か導線不足かの判断材料 | 関連FAQ追加、本文改善 |
| 同テーマの問い合わせ件数 | FAQが読まれていない、信用されていない | 申請画面や通知文から直接リンク |
| 高閲覧なのに更新が古いページ | 事故の起点になりやすい | 優先レビュー対象にする |
制度改正、申請様式変更、承認フロー変更、締切時期の到来。この4つは、FAQ見直しの自動トリガーとして決めておくと運用が安定します。
まず着手したい30日プラン
最短で成果を出すなら、最初の30日で次の順番に進めるのがおすすめです。
- 直近の問い合わせ上位20件と、検索ゼロ件語を集める
- 利用者語、正式語、旧称をまとめた同義語表を作る
- 上位10件のFAQを、1FAQ1論点に分割してタイトルを書き換える
- PDFしかない重要FAQにHTML要約ページを付ける
- 「見つかった／見つからなかった」の簡易フィードバックを付け、月次レビューを始める
自治体の庁内申請FAQを検索されやすくするコツは、難しい機能を増やすことではありません。職員が打つ言葉で、1論点ずつ、結果一覧で選べる形に直すことです。そこに分類、権限、更新運用を重ねれば、FAQは「読まれない置き場」から「問い合わせを減らす業務資産」に変わります。最初の一歩は、新しいFAQを量産することではなく、今あるFAQを検索語ベースで並べ替えることから始めてください。
コメント