自治体向け利用マニュアルの書き方・作り方

行政AIヤマトにおいては「DX・情報」の「自治体システム書類作成」のボタンで、この仕様の通り、AI出力できます。

先に結論：自治体向け利用マニュアルで最も重要なこと

自治体向け利用マニュアルの目的は、職員や住民が目的の操作を迷わず、安全に、アクセシブルに完了でき、エラー時には自力回復または適切な窓口へ到達できるようにすることです。読み手が推測しなくても、対象、前提、責任者、判断基準、実績または手順、例外、証跡、改訂履歴を追跡できるように作ります。分量を増やすことが品質ではありません。意思決定に必要な結論を先に示し、詳細は番号を付けて相互参照できる構造にすることが、自治体向け利用マニュアルの書き方の基本です。

このガイドは、自治体職員、窓口担当、管理者、住民・事業者、コールセンター、研修担当、アクセシビリティ確認者を主な読者とします。実案件へ適用するときは、調達仕様書、契約書、自治体の文書管理規程、情報セキュリティポリシー、個人情報保護関係規程、最新の国のガイドラインを優先してください。

利用マニュアルとは何か

利用マニュアルは、職員や住民が目的の操作を迷わず、安全に、アクセシブルに完了でき、エラー時には自力回復または適切な窓口へ到達できるようにするための正式な成果物です。単なる説明資料ではなく、関係者の責任と判断をそろえる基準、後工程への入力、監査・引継ぎの証跡という三つの役割があります。文書名が同じでも、自治体や契約によって成果物の範囲は異なります。最初に仕様書の成果物定義、検収条件、提出形式、承認経路を確認します。

良い利用マニュアルは、本文を初めて読む職員が「自分は何を確認し、何を判断し、次に何をするか」を理解できます。悪い利用マニュアルは、専門用語が多いのに対象や結論が曖昧で、作成した受託者へ聞かないと使えません。担当者の異動が多い自治体では、第三者が単独で再現・判断できることを品質基準にします。

作成前に集める情報

1. 調達仕様書、契約書、質問回答、提案書、見積条件
2. 要件定義書、基本・詳細設計書、構成図、データ定義、関連台帳
3. 作業・試験・運用の計画、手順、結果、課題、変更履歴
4. 自治体の規程、承認経路、文書番号、保存期間、公開・非公開区分
5. システム、クラウド、回線、外部サービス、再委託先の責任分界
6. 利用者、対象業務、繁忙期、閉庁時、災害時、アクセシビリティの条件
7. 個人情報、機密情報、ログ、証跡、データ移行・廃棄の取扱条件

資料名だけでなく、版、承認状態、基準日、保管場所、所有者を記録します。利用マニュアルでは、利用者の目的達成と安全の観点からこの情報を使います。異なる資料間で数値・用語・対象版が食い違う場合は、勝手に一方へ合わせず、課題として責任者へ確認します。

推奨する章立てと記載内容

冒頭には表紙、文書番号、対象システム、対象版、機密区分、作成・確認・承認、改訂履歴、配布先を置きます。利用マニュアルのレビューでは、利用者の目的達成と安全への影響を確認します。章番号と項目IDは改訂しても変えず、削除項目も履歴から追えるようにします。別紙を使う場合は、本文から別紙名、版、項目ID、保管場所を明示します。

自治体向け利用マニュアルの作り方：7つの手順

1. 目的と判断事項を一文で定義する

「何を記録する文書か」だけでなく、「誰が何を判断するための文書か」を定めます。利用マニュアルでは、結論を利用者の目的達成と安全に結び付けます。目的に関係しない情報を無制限に追加せず、必要な証拠へリンクします。

2. 正本となる情報源を確定する

設計書、台帳、チケット、ログ、契約書のどれを正本とするか決めます。利用マニュアルの承認時には、利用者の目的達成と安全を説明できる状態にします。同じ値を複数文書へ複製する場合は、更新責任者と同期方法を決めます。正本不明は不整合の最大要因です。

3. 読者と権限別に情報を分ける

幹部向けには結論、影響、判断、費用を短く示し、実務担当向けには詳細と証跡を示します。利用マニュアルでは、この記録を利用者の目的達成と安全の証拠として残します。機密情報は本文から分離し、知る必要のある人だけが閲覧できるようにします。

4. IDと基準値で曖昧さをなくす

要件ID、設計ID、試験ID、課題ID、変更ID、成果物IDを使います。利用マニュアルでは、利用者の目的達成と安全の観点からこの情報を使います。「十分」「迅速」「原則」ではなく、数値、条件、期限、担当、完了状態を記載します。数値には単位、測定点、期間、算定式を付けます。

5. 例外と失敗時の行動を書く

正常時だけでなく、承認されない、処理が失敗する、期限を超える、担当者が不在、外部サービスが停止する場合を記載します。利用マニュアルのレビューでは、利用者の目的達成と安全への影響を確認します。停止、切戻し、代替運用、エスカレーションの基準を用意します。

6. 関係者レビューと実地確認を行う

作成者の自己点検だけで完了にしません。利用マニュアルでは、結論を利用者の目的達成と安全に結び付けます。業務、情報政策、運用、セキュリティ、個人情報、契約、アクセシビリティの観点からレビューし、必要なら実機・実データ量・実運用体制で確認します。指摘は修正済み、受容、保留の状態と根拠を残します。

7. 承認・公開・保守へ移す

承認版を固定し、編集原本と閲覧版を区別します。利用マニュアルの承認時には、利用者の目的達成と安全を説明できる状態にします。保管場所、権限、バックアップ、保存期間、公開範囲、次回レビュー日、変更トリガーを登録します。承認後の変更は変更管理を通し、旧版を無断で上書きしません。

書き方のポイント

• 機能名ではなく「転入届を入力する」など利用者の目的で構成する
• 一つの手順に一つの操作を置き、操作後の正常状態を必ず示す
• 画面上のラベルとマニュアルの用語を完全に一致させる
• スクリーンショットには番号と代替テキストを付け、個人情報を載せない
• 職員版では権限、承認、取消、履歴確認、例外処理を厚くする
• 住民版では専門用語を避け、必要時間、準備物、保存・再開、問合せを先に示す

各記述は「対象」「条件」「行動または結果」「責任者」「期限」「証跡」の順に書くと、読み手が判断しやすくなります。利用マニュアルでは、この記録を利用者の目的達成と安全の証拠として残します。表は比較と一覧、文章は理由と例外、図は関係と流れに使い分けます。略語は初出時に正式名称と意味を書き、自治体独自用語・受託者用語の対訳表を設けます。

自治体向け文書として必ず押さえる重要事項

説明責任と意思決定の証跡

自治体のシステム文書は、作成者だけが分かればよい内部メモではありません。利用マニュアルでは、利用者の目的達成と安全の観点からこの情報を使います。契約、検収、監査、情報公開請求、議会や住民への説明、担当者の異動、後継事業者への引継ぎでも判断の経緯を説明できる必要があります。「誰が、いつ、何を根拠に、どの選択肢から、何を承認したか」を版管理とともに残します。決裁文書、課題管理表、変更要求、会議記録、設計・試験IDへ相互参照を張り、本文だけを読んでも結論が分かり、証拠へもたどれる二層構造にします。

個人情報・機密情報の最小化

住民情報、職員情報、認証情報、脆弱性情報、非公開のネットワーク情報を、分かりやすさのために安易に掲載してはいけません。利用マニュアルのレビューでは、利用者の目的達成と安全への影響を確認します。文書本文には必要最小限の識別子を置き、機密別紙やアクセス制御された保管庫へ分離します。保管場所、閲覧権限、持出し、印刷、送付、保存期間、廃棄、事故時連絡を文書区分ごとに決めます。サンプルは架空データを使い、画面画像・ログ・添付ファイルのメタデータまで確認します。

調達の公平性とベンダーロックイン回避

特定製品や特定事業者だけが理解できる表現、非公開仕様、独自形式への過度な依存は、将来の競争性と継続性を損ないます。利用マニュアルでは、結論を利用者の目的達成と安全に結び付けます。製品名を書く必要がある場合は、要求する能力、選定理由、代替可能性を併記します。自治体がデータ、設定、文書、コード、アカウントを管理できる状態を確保し、契約終了時の返却、移行支援、消去証明まで考えます。

セキュリティと利便性の両立

セキュリティは「厳格にする」という抽象語ではなく、認証、権限、暗号化、ログ、脆弱性、バックアップ、インシデント対応などの統制へ分解します。利用マニュアルの承認時には、利用者の目的達成と安全を説明できる状態にします。一方で、過度な統制が窓口業務や住民利用を阻害すると、紙への書き写しやID共有など別のリスクを生みます。脅威、業務影響、利用者特性、費用を評価し、例外が必要な場合は承認条件と期限を設けます。

アクセシビリティと利用者多様性

高齢者、障害のある人、日本語に不慣れな人、スマートフォンだけを使う人、低速回線の人を含め、情報へ到達できるようにします。利用マニュアルでは、この記録を利用者の目的達成と安全の証拠として残します。見出し構造、キーボード操作、読み上げ順、代替テキスト、文字拡大、コントラスト、色以外の識別、やさしい日本語、代替手続を確認します。適用する最新の国・自治体ガイドラインと組織基準は、公開時・改訂時に必ず確認してください。

法令・条例・組織基準の最新版確認

個人情報保護、情報セキュリティ、アクセシビリティ、文書管理、会計、契約、著作権、電子署名などの適用条件は、対象業務や時期、自治体の条例・規程で異なります。利用マニュアルでは、利用者の目的達成と安全の観点からこの情報を使います。本ガイドの記載だけで適法性を断定せず、文書には「確認した規程名、版・改定日、確認者、確認日」を記録します。疑義は法務、契約、情報セキュリティ、個人情報保護の所管へ照会します。

テンプレートに設ける管理項目

文書管理欄

表紙または先頭ページに、文書ID、文書名、自治体名、システム名、対象業務、対象環境、対象リリース、版、作成日、基準日、機密区分を置きます。利用マニュアルのレビューでは、利用者の目的達成と安全への影響を確認します。作成・確認・承認は、氏名だけでなく役割と所属も記載します。電子承認の場合はワークフローの決裁番号へリンクし、紙と電子が混在する場合はどちらを正本とするか決めます。

改訂履歴には、版、日付、変更箇所、変更理由、変更要求ID、作成者、承認者を記録します。利用マニュアルでは、結論を利用者の目的達成と安全に結び付けます。「全面改訂」だけでは差分を追えないため、影響した章と判断の変化を短く示します。軽微な誤字修正と、契約・運用へ影響する変更を同じ承認経路にする必要はありませんが、軽微変更の範囲を事前に定義します。

項目IDとトレーサビリティ

各項目には、文書種別を表す接頭辞と連番を付けます。利用マニュアルの承認時には、利用者の目的達成と安全を説明できる状態にします。例えば、要件REQ、設計DES、試験TST、課題ISS、変更CHG、リスクRSK、証跡EVDなどです。番号は削除しても再利用せず、廃止状態として残します。関連ID欄を設けることで、要求から設計、実装、試験、運用まで縦に追跡できます。

トレーサビリティ表は「リンクがある」だけで完成ではありません。利用マニュアルでは、この記録を利用者の目的達成と安全の証拠として残します。リンク先が承認済みか、対象版が合うか、要求変更が下流文書へ反映されたかを確認します。リリース判定時には未接続IDを抽出し、対象外なら根拠と承認を残します。

未決事項・例外・制約の欄

未決事項は、論点、選択肢、業務・費用・日程・安全への影響、決定者、決定期限、暫定方針を記載します。利用マニュアルでは、利用者の目的達成と安全の観点からこの情報を使います。期限を過ぎたら自動的に暫定方針が正式化する、といった運用は避けます。決定後は結論と根拠を本文へ反映し、未決一覧を完了にします。

例外は、標準から外れる対象、理由、リスク、代替統制、開始日、終了日、承認者を記録します。利用マニュアルのレビューでは、利用者の目的達成と安全への影響を確認します。恒久例外に見えても定期レビュー日を置きます。制約は単なる言い訳ではなく、影響を受ける利用者、回避策、将来の解消条件を説明します。

レビュー会議の進め方

レビュー資料は会議直前に配らず、参加者の役割に応じた確認観点と期限を添えて事前配布します。利用マニュアルでは、結論を利用者の目的達成と安全に結び付けます。会議では文章の好みより、事実、要求、リスク、判断基準の相違を優先します。指摘にはID、対象箇所、重要度、内容、提案、回答者、期限、状態を付け、口頭回答だけで閉じません。

重大な指摘は、修正版を作成した人と別の人が再確認します。利用マニュアルの承認時には、利用者の目的達成と安全を説明できる状態にします。「修正済み」は文字を変えたことではなく、指摘原因が解消し、関連箇所への水平展開が完了した状態です。受容しない指摘には理由とリスク受容者を記録します。レビュー終了条件は、重大指摘ゼロ、未解決指摘の例外承認完了、版と承認経路の確定など、測定可能にします。

文書を運用し続けるための更新ルール

更新トリガーは、システム変更だけではありません。利用マニュアルでは、この記録を利用者の目的達成と安全の証拠として残します。条例・規程改定、組織改編、担当・委託先変更、クラウドサービス仕様変更、証明書更新、障害、訓練、監査指摘、利用者からの問合せ増加も対象です。変更管理プロセスから文書更新タスクを自動または必須で起票すると、完成図書の陳腐化を防げます。

少なくとも定期的に、所有者、最終承認日、次回レビュー日、参照リンク切れ、対象版、連絡先、未決事項を棚卸しします。利用マニュアルでは、利用者の目的達成と安全の観点からこの情報を使います。更新しない判断にも根拠と次回確認日を残します。保管期間が満了した文書は、訴訟・監査・契約上の保留がないか確認し、承認された方法で廃棄します。

重要な禁止事項

• 「適宜」「必要に応じて」「通常どおり」など判断できない表現を多用する
• 旧画面の画像や存在しないボタン名を残す
• 赤色だけで必須・エラーを示す
• 実在住民の氏名、住所、識別番号、メールを画面例に使う
• パスワード、秘密鍵、管理者用URLを掲載する
• 利用者が権限外操作やデータ破壊を行う可能性のある回避策を案内する
• PDFだけを提供し、検索可能なHTMLや代替支援を検討しない

さらに、AIが生成した内容を未確認で正式文書にすること、存在しない法令・規格・機能を引用すること、以前の案件名や他自治体の個人情報を残すこと、レビュー指摘を履歴ごと削除することは禁止です。利用マニュアルのレビューでは、利用者の目的達成と安全への影響を確認します。AIは章立てや初稿作成を補助できますが、事実確認、契約との整合、機密性判断、最終承認は権限を持つ人が行います。

記載例

目的：申請内容を一時保存して後で再開する。前提：ログイン済みで、入力画面を開いている。手順1：画面下部の「一時保存」を選びます。手順2：「保存しました」と表示されたことを確認します。手順3：再開する場合は、ホームの「作成途中の申請」から対象を選びます。注意：共有端末では、保存後に必ずログアウトしてください。表示されない場合は通信を確認し、二重送信を避けるため連続してボタンを押さず、受付番号と発生時刻を窓口へ伝えてください。

この例のポイントは、結論だけでなく、対象、条件、期限、責任者、確認方法まで含むことです。利用マニュアルでは、結論を利用者の目的達成と安全に結び付けます。実際の文書では、関連IDと証跡保管場所を加えます。「問題なし」「対応予定」のような短い結論だけでは、検収や引継ぎで再確認が必要になります。

品質レビューの方法

完全性レビュー

仕様書の成果物要件と章立てを照合し、対象外、未定、未実施を含めて抜けを確認します。利用マニュアルの承認時には、利用者の目的達成と安全を説明できる状態にします。対象外には理由と承認者、未定には決定期限と責任者を付けます。空欄を「該当なし」と解釈させません。

整合性レビュー

名称、件数、日付、環境、バージョン、責任者、要件IDを関連文書と突合します。利用マニュアルでは、この記録を利用者の目的達成と安全の証拠として残します。表の集計と明細、本文と図、本文と別紙の不一致を機械的にも確認します。基準日が違う数字は、時点を明記して比較します。

再現性レビュー

作成に関与していない担当者が文書を読み、目的の判断または作業を再現できるか確認します。利用マニュアルでは、利用者の目的達成と安全の観点からこの情報を使います。質問が発生した箇所は、前提、用語、例外、証跡の不足として改善します。

安全性レビュー

個人情報、認証情報、内部URL、脆弱性、契約上の秘密、著作権物が不必要に含まれていないか確認します。利用マニュアルのレビューでは、利用者の目的達成と安全への影響を確認します。公開版と内部版を分ける場合は、マスキング後の復元可能性やファイルのメタデータも点検します。

実務チェックリスト

• [ ] 文書名、番号、版、基準日、対象システム、対象リリースがある
• [ ] 作成者、確認者、承認者、承認日、配布先、機密区分がある
• [ ] 目的、対象範囲、対象外、前提条件、用語が明確である
• [ ] 契約・仕様書の成果物番号と対応している
• [ ] 数値に単位、条件、測定点、時点、算定式がある
• [ ] 責任者、期限、完了条件、例外時の行動がある
• [ ] 要件・設計・試験・課題・変更・証跡のIDがつながっている
• [ ] 個人情報と機密情報を最小化し、閲覧権限を設定した
• [ ] アクセシビリティと多様な利用環境を確認した
• [ ] 自治体と受託者、外部サービスの責任分界が明確である
• [ ] 未定、未実施、対象外、既知の制約を隠していない
• [ ] 最新の法令、条例、国・自治体ガイドライン、庁内規程を確認した
• [ ] 業務・技術・運用・セキュリティ・契約の関係者がレビューした
• [ ] 編集原本、承認版、旧版、証跡の保管・保存・廃棄方法が決まっている
• [ ] 改訂条件、次回レビュー日、変更時の承認経路が決まっている

SEO・AEOを意識した公開ページの作り方

自治体向け利用マニュアルの解説をWeb公開する場合は、ページタイトルに「自治体向け利用マニュアルの書き方・作り方」を含め、冒頭で結論を短く答えます。見出しには、ポイント、重要事項、禁止事項、テンプレート、チェックリスト、FAQなど検索者の疑問に対応する語を自然に使います。同じキーワードの不自然な連呼は避け、関連語を文脈に沿って説明します。

AEOでは、質問見出しの直後に簡潔な答えを置き、その後に条件や例外を説明します。利用マニュアルでは、結論を利用者の目的達成と安全に結び付けます。構造化データを使う場合も、画面に表示しているFAQと一致させます。公開日・更新日・文責・組織情報を明示し、一次資料へリンクします。制度、法令、組織規模など変わり得る情報には基準日を付け、定期的に更新します。

FAQ：自治体向け利用マニュアルのよくある質問

Q1. 利用マニュアルは誰向けに書きますか？

職員、管理者、住民など役割ごとに必要な操作と知識が違うため、読者を分けて作ります。

Q2. 画面をすべて掲載すべきですか？

全画面の羅列より、迷いやすい判断点と正常結果を優先します。画面変更に弱くならないよう文章でも位置とラベルを示します。

Q3. スクリーンショットは必須ですか？

必須ではありません。画像は理解を助けますが、検索・読み上げ・改版性を考え、文章と代替テキストを併用します。

Q4. 何年生でも読める文章にすべきですか？

住民向けはやさしい日本語を意識し、一文を短くします。専門語が必要なら直後に意味を説明します。

Q5. 動画だけのマニュアルでよいですか？

検索しにくく閲覧できない利用者もいるため、字幕・文字起こし・静止画・文章による代替を用意します。

Q6. エラーコードは掲載しますか？

利用者が行動を選べるコードは掲載します。内部構成や脆弱性につながる情報は公開せず、窓口向け資料で管理します。

Q7. 職員研修とマニュアルは同じですか？

マニュアルは業務中に参照する資料、研修は背景理解と演習を含む学習活動です。相互リンクさせます。

Q8. 更新頻度はどれくらいですか？

画面・業務・問合せ傾向の変更ごとに更新し、定期レビューも行います。対象バージョンと改訂日を必ず表示します。

Q9. アクセシビリティ確認はどうしますか？

キーボード、読み上げ、拡大、コントラスト、見出し構造、リンク文言を実利用環境で確認し、当事者テストも検討します。

Q10. AIで作ったマニュアルをそのまま使えますか？

使えません。実画面、権限、業務規程、例外、窓口を担当者が検証し、機密情報や誤操作につながる記述をレビューします。

まとめ

自治体向け利用マニュアルの書き方で大切なのは、職員や住民が目的の操作を迷わず、安全に、アクセシブルに完了でき、エラー時には自力回復または適切な窓口へ到達できるようにすることです。対象、前提、責任、基準、例外、証跡を明確にし、関連文書とIDでつなぎます。個人情報、セキュリティ、アクセシビリティ、調達公平性、将来移行を後付けにせず、作成段階から組み込みます。

テンプレートを埋めるだけでは完成しません。実際の契約、業務、システム、体制で内容を検証し、権限を持つ担当者が承認し、変更後も更新される状態にして初めて、自治体DXを支える文書として機能します。