自治体向け運用設計書の書き方・作り方

行政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. 承認・公開・保守へ移す

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

書き方のポイント

• 監視項目ごとに検知後の行動と完了条件まで設計する
• SLAは測定点、測定時間、除外、報告方法を含める
• 自治体の閉庁時間、災害対応、選挙、税・福祉の繁忙期をカレンダー化する
• クラウド責任共有モデルを自組織の作業へ翻訳する
• 特権操作、個人情報アクセス、データ出力に証跡と定期レビューを設ける
• 運用費用を人員、回数、容量、件数と結び付けて見積可能にする

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

文書管理欄

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

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

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

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

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

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

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

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

レビュー会議の進め方

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

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

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

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

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

重要な禁止事項

• 「適切に監視する」「速やかに対応する」だけで担当や時間を定めない
• 契約先と再委託先の責任境界を口頭合意のままにする
• バックアップ成功通知だけで復元可能性を確認しない
• 本番の特権IDを複数人で共有する
• 緊急変更を理由に承認、記録、事後レビューを省略する
• ログへ個人情報や認証情報を無制限に記録する
• 契約終了時のデータ移行・消去・証明を設計しない

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

記載例

重大度1：住民向け主要手続が全面停止、個人情報漏えいの疑い、または庁内基幹連携が停止した状態。監視担当は5分以内に一次窓口へ通報し、運用責任者は15分以内に対策本部を招集する。30分以内に影響と代替手段を広報責任者へ報告し、復旧または縮退移行を判断する。復旧後5営業日以内に原因・再発防止・証跡を報告する。

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

品質レビューの方法

完全性レビュー

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

整合性レビュー

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

再現性レビュー

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

安全性レビュー

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

実務チェックリスト

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

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

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

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

FAQ：自治体向け運用設計書のよくある質問

Q1. 運用設計書はいつ作りますか？

要件定義から作り始め、基本設計で具体化し、試験と引継ぎの結果を反映して本番移行前に承認します。

Q2. 運用手順書との違いは何ですか？

運用設計書は方針、体制、基準、プロセスを定め、手順書は個々の操作を実行順に記載します。

Q3. SLAとSLOはどう使い分けますか？

契約上の約束をSLA、内部の運用品質目標をSLOとする例があります。名称よりも測定式と責任を合意することが重要です。

Q4. 24時間365日の監視は必須ですか？

業務影響と費用を評価して決めます。閉庁時も住民サービスが動く場合は、自動検知と連絡・復旧体制を設計します。

Q5. RPOとRTOとは何ですか？

RPOは許容できるデータ損失時点、RTOは許容復旧時間の目標です。業務継続要求と技術・費用を整合させます。

Q6. クラウドなら運用設計は不要ですか？

必要です。基盤の一部を事業者が運用しても、設定、ID、データ、監視、障害連絡、契約管理は利用者側に残ります。

Q7. 障害連絡先は個人名でよいですか？

異動に弱いため役割や当番窓口を基本とし、連絡網は別管理で定期確認します。

Q8. パッチは公開後すぐ適用しますか？

緊急度、悪用状況、影響、試験、停止可能時間を評価し、期限と例外承認を定めます。

Q9. 運用台帳は何を管理しますか？

構成、アカウント、証明書、ライセンス、変更、障害、問合せ、バックアップ、ジョブなどを対象にします。

Q10. 契約終了時に重要なことは何ですか？

移行可能な形式でのデータ返却、知識移転、アカウント廃止、媒体・バックアップの消去証明、後継支援を事前に契約化します。

まとめ

自治体向け運用設計書の書き方で大切なのは、本番稼働後の監視、障害、問合せ、変更、アカウント、データ保護、継続性を役割とサービス水準に落とし込み、属人化せず安定運用できる状態にすることです。対象、前提、責任、基準、例外、証跡を明確にし、関連文書とIDでつなぎます。個人情報、セキュリティ、アクセシビリティ、調達公平性、将来移行を後付けにせず、作成段階から組み込みます。

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