自治体向け構築手順書の書き方・作り方

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

はじめに――構築手順書の結論

自治体向け構築手順書は、担当者が迷わず操作できるだけでなく、第三者が事前レビューし、当日の実績を追跡し、異常時に安全に停止・復旧できる文書でなければなりません。必要なのは、一操作一確認、実施者と確認者、承認、期待結果、証跡、停止基準、ロールバックです。コマンドを羅列しただけの手順書では、対象誤り、権限逸脱、個人情報流出、設定戻し忘れを防げません。

自治体システムでは、住民記録、税、福祉、戸籍、選挙、給付など、停止や誤処理の影響が住民の権利・生活に直結します。庁内ネットワーク、LGWAN接続系、マイナンバー利用事務系、インターネット接続系の分離や、共同利用、国・都道府県との連携にも配慮が必要です。自治体向け構築手順書の書き方では、安全な操作だけでなく、業務を再開できる状態の確認までを手順に含めます。

要点：よい構築手順書は「何を入力するか」と同じ精度で、「何が出れば正常か」「何が出たら止めるか」「誰が続行を承認するか」を書きます。

想定読者

• 構築作業を行うインフラ、クラウド、ネットワーク、アプリ担当
• 作業の相互確認者、作業責任者、変更管理者
• 自治体の情報政策部門、業務原課、セキュリティ担当
• データ移行、監視、運用、サービスデスク担当
• 再委託先、監査担当、受入・検収担当

作業者が製品に詳しくても、自治体固有の命名、接続経路、承認、証跡ルールを知っているとは限りません。逆に自治体承認者はコマンドの詳細を知らなくても、影響と判定条件を確認できる必要があります。概要、詳細手順、判定表、記録欄を分けて読みやすくします。

標準的な章立て

1. 文書情報、目的、対象、関連文書
2. 構築内容、方式、成功条件、対象外
3. 実施日時、場所、体制、連絡網
4. 対象環境、構成、識別方法
5. 前提条件、権限、ツール、媒体
6. バックアップ、事前確認、開始承認
7. 詳細手順、期待結果、証跡
8. 中間判定、停止基準、異常時対応
9. ロールバック手順、復旧確認
10. 構築後試験、業務確認、完了承認
11. 暫定設定の解除、情報・媒体の消去
12. 実績、差異、課題、改訂履歴

1. 文書管理と対象の識別

表紙には、文書番号、案件名、対象環境、版、機密区分、作成者、レビュー者、承認者、承認日を記載します。「本番用」「検証用」が見た目で区別できるようにし、誤使用を防ぎます。作業当日は承認済み版を読み取り専用で配布し、個人のローカルコピーを正本にしません。

対象は、システム名、環境、テナント、サブスクリプション、リージョン、ホスト名、資産番号、IPアドレス、クラスタ、データベース名等で識別します。ただし公開範囲に応じて機密情報を別紙に分けます。画面の色や担当者の記憶だけで本番・検証を識別してはいけません。

対象外を明示し、同一クラスタ上の別自治体、別業務、共通基盤への影響を確認します。マルチテナントサービスでは、テナントIDと自治体名の対応を二者確認します。構成図、パラメータシート、資産台帳の版番号も参照します。

2. 前提条件と作業環境

前提条件は当日にチェックできる文章にします。「必要な準備が済んでいる」ではなく、「変更申請CHG-001が承認済み」「検証環境で手順v1.2が完走」「前日バックアップの復元試験成功」などとします。

• 作業設計書、詳細設計書、パラメータシートが承認済み
• 検証環境で同じ手順を実行し、差異を反映済み
• 対象構成が台帳・構成図と一致
• 作業用アカウントは記名式、最小権限、期限付き
• 多要素認証、踏み台、接続元制限が有効
• バックアップ取得とリストア可能性を確認
• ロールバックに必要な媒体、鍵、旧版が利用可能
• 監視抑止の範囲・時間・解除担当が確定
• 原課、連携先、サービスデスクへの周知が完了
• 自治体承認者が開始判定に参加可能

ツールの名称、承認済みバージョン、入手元、ハッシュ値、ライセンスを記載します。持込み端末やUSB媒体は自治体規程に従い、ウイルス検査と授受記録を行います。私物端末、無許可ツール、公開ファイル共有、未承認の生成AIへの設定貼付を禁止します。

3. バックアップと復元準備

バックアップは、対象、方式、取得時刻、保管先、暗号化、保持期間、結果、復元手順を記録します。仮想マシンのスナップショットだけでアプリケーション整合性が保てるか、データベースとファイルの時点が合うかを確認します。

「バックアップ成功」の画面だけでなく、可能な範囲でリストア試験を行います。暗号鍵、パスワード、ライセンス、DNS、証明書など、復元後に必要な要素を含めます。RTO・RPOと実測復旧時間を比較し、作業枠内にロールバックできなければ方式を見直します。

バックアップに個人情報が含まれる場合、アクセス権、保管地域、再委託、暗号化、削除期限を定めます。本番作業のために取得した臨時コピーは、完了・安定確認後に承認を得て消去し、消去証跡を残します。

4. 一操作一確認の書き方

各ステップに、手順ID、予定時刻、実施者、確認者、入力、操作、期待結果、判定、証跡、異常時処置を持たせます。一つの番号に複数の不可逆操作を詰め込まず、確認点で分割します。画面操作ではメニュー階層、選択値、押下ボタン、確認画面を示します。

コマンド例には、プロンプトと出力を混同しないよう区別します。パスワード、秘密鍵、個人情報は埋め込みません。変数は、<TENANT_ID>のように明示し、値の取得元と確認方法を書きます。破壊的なコマンドの直前には、カレント対象の表示、件数確認、二者承認を置きます。

詳細手順テンプレート

5. 値とパラメータの管理

手順書に値を重複記載すると、パラメータシートとの不一致が起きます。固定値は承認済みパラメータシートを正とし、手順IDとパラメータIDを結びます。当日入力値は二者で読み合わせ、入力後に取得コマンドや画面で再確認します。

パスワード、APIキー、秘密鍵、証明書秘密鍵は本文に書かず、承認済みの秘密情報管理基盤から作業時に取得します。画面録画や端末ログに秘密が残らないよう、表示抑止を使います。クリップボード、チャット、メールでの共有を禁止します。

自治体コード、業務コード、文字コード、タイムゾーン、和暦・西暦、外字、住所、個人番号等の取り扱いは特に誤りやすい項目です。ゼロ埋め、桁数、NULL、改行、機種依存文字を明記し、サンプル値に実在住民のデータを使いません。

6. 個人情報とログ・証跡

手順実施中に個人情報が表示される箇所を事前に特定します。必要以上のデータを表示しないクエリやフィルタを使い、スクリーンショットではマスキングします。原本が必要な場合は機密区分、閲覧者、保管期限を指定します。

端末操作ログ、クラウド監査ログ、変更履歴、チケット、画面証跡を手順IDにひも付けます。証跡には対象、実施者、時刻、結果、ハッシュ値を付け、改ざん防止された保管先へ保存します。時刻同期とタイムゾーンを確認し、証跡間の時系列を追えるようにします。

個人情報保護法、番号法、自治体の条例・規程、情報セキュリティポリシー、委託契約は改定され得ます。実施時点の最新版を公式情報と担当部署で確認してください。手順書の記載は法的判断の代替ではありません。

7. 開始・中間・完了承認

作業開始前に、参加者、対象、障害・災害状況、他変更との競合、バックアップ、連絡経路を読み合わせます。開始承認者の氏名、時刻、承認方法を記録します。無応答を承認とみなしてはいけません。

不可逆操作、サービス停止、トラフィック切替、データ投入の直前に中間承認を置きます。中間判定では、それまでの結果、残り時間、監視状態、ロールバック可能期限を確認します。予定より遅れている場合、次へ急ぐのではなく、切戻しに必要な時間を確保して判断します。

完了承認では、技術試験、原課の業務確認、監視解除、暫定権限削除、課題登録、証跡格納を確認します。翌営業日の窓口・バッチ・帳票まで確認が必要なら、暫定完了と正式完了を区別します。

8. 停止基準と異常時対応

停止基準は定量化します。例として、対象不一致、想定外の警告、戻り値非ゼロ、データ件数差、エラー率、性能悪化、個人情報誤表示、権限逸脱、予定超過、連絡断があります。「異常があれば相談」では遅すぎます。

停止時は、追加操作を止め、対象の安全状態を確認し、ログ・画面・時刻を保存します。証拠を消す可能性のある再起動や再実行を独断で行いません。作業責任者、自治体承認者、セキュリティ窓口へ報告し、事故対応か通常障害対応かを判断します。

個人情報漏えいまたはそのおそれがある場合は、アクセス遮断、証拠保全、影響範囲の限定を優先し、自治体の事故対応手順に従います。外部への報告や本人通知は所管部署が法令・規程に基づき判断します。

9. ロールバック手順

ロールバック手順は本番手順と同じ粒度で事前作成します。「問題があれば戻す」では実行できません。判断条件、判断者、開始最終時刻、対象、順序、データ整合、外部連携、DNS・キャッシュ、復旧試験を記載します。

新環境で更新されたデータを旧環境に反映できるか、二重受付をどう防ぐか、送信済み通知を取り消せるかを検討します。不可逆操作は明示し、その直前に最終判定を置きます。データ損失が避けられない可能性は、作業前に自治体へ説明し承認を得ます。

切戻し後は、旧系が起動しただけで完了にせず、ログイン、検索、登録、帳票、バッチ、外部連携、監視を確認します。住民・職員へ障害案内を出した場合は、復旧案内と問い合わせ対応も行います。

10. 構築後試験と引継ぎ

構築後は、設定値照合、疎通、認証・認可、冗長化、バックアップ、監視、性能、セキュリティ、業務機能を確認します。期待値と合否基準を手順内または試験手順書への参照で示します。正常系だけでなく、誤権限、接続断、フェイルオーバー等の異常系を含めます。

運用引継ぎでは、構成図、パラメータシート、監視項目、アカウント、証明書期限、バックアップ、既知課題、保守窓口を更新します。実構成と文書の差分をなくし、暫定設定・作業用ルール・保守モード・監視抑止を解除します。

書き方のポイント

1. 一つの手順には一つの目的と一つの判定を置く。
2. 「確認する」だけでなく、確認方法と期待値を書く。
3. 本番と検証、自治体テナントを複数識別子で確認する。
4. 実施者と確認者を分け、重要操作を読み合わせる。
5. 手順IDと証跡、パラメータ、試験項目をひも付ける。
6. 正常系、異常系、時間切れ、連絡不能を準備する。
7. 画面や製品版の変更を実施直前に再確認する。
8. 実績時刻と差異を書き込める余白を設ける。

重要事項

• 自治体承認済みの版だけを本番で使用する。
• バックアップ取得だけでなく復元可能性を確認する。
• 停止基準、ロールバック最終時刻、判断者を事前合意する。
• 個人情報・秘密情報を手順書や証跡へ不要に残さない。
• 重要操作は二者確認し、記名式アカウントで実施する。
• 作業後に権限、監視抑止、一時データ、媒体を確実に処理する。
• 製品仕様、法令、ガイドライン、自治体規程は最新版を確認する。

禁止事項

• 未承認版、個人メモ、古い手順の本番使用
• 対象確認を省いた破壊的コマンドや一括更新
• 共用ID、他人のID、恒久特権による操作
• 手順逸脱を口頭だけで承認して続行すること
• エラーを無視するオプション、結果未確認での次工程移行
• 個人情報を含む画面・CSV・ログの無断持出し
• パスワード、APIキー、秘密鍵の本文・チャットへの記載
• 停止基準到達後の独断継続、根拠のない再実行
• 証跡の改変、削除、実績と異なる完了記録
• 監視抑止、暫定FW、作業アカウントの戻し忘れ

実務チェックリスト

作成・レビュー

• [ ] 目的、対象、対象外、成功条件が明確
• [ ] 構成図・設計書・パラメータと整合
• [ ] 全手順に期待結果と異常時処置がある
• [ ] 個人情報が表示・保存される箇所を特定
• [ ] 重要操作に二者確認と承認点がある
• [ ] 停止基準と再開条件が客観的
• [ ] ロールバックを同じ粒度で記載
• [ ] 検証環境で完走し所要時間を実測
• [ ] 法令・規程・製品マニュアルの版を確認

実施前・実施中

• [ ] 承認済み版と対象環境を読み合わせ
• [ ] バックアップ・鍵・復元権限を確認
• [ ] 記名式の期限付き権限で接続
• [ ] 開始承認の氏名と時刻を記録
• [ ] 一操作ごとに期待結果を確認
• [ ] 実績時刻、実施者、確認者、証跡を記録
• [ ] 想定外事象で停止し、追加操作を保留
• [ ] ロールバック可能残時間を監視

完了時

• [ ] 構築後試験と原課業務確認が合格
• [ ] 監視、バックアップ、バッチ、連携が正常
• [ ] 暫定権限・設定・監視抑止を解除
• [ ] 一時ファイル・媒体を規程どおり消去
• [ ] 実構成を設計書・台帳へ反映
• [ ] 差異と課題に担当・期限を設定
• [ ] 完了承認と終了連絡を記録

短縮テンプレート

# ○○構築手順書
文書番号／版／対象環境／機密区分／承認

## 1. 目的・範囲・成功条件
## 2. 日時・体制・緊急連絡
## 3. 対象識別・構成・関連文書
## 4. 前提条件・権限・ツール
## 5. バックアップ・開始判定
## 6. 詳細手順
### 手順ID／入力／操作／期待結果／証跡／異常時
## 7. 中間判定・停止基準
## 8. ロールバック手順
## 9. 構築後試験・業務確認
## 10. 暫定設定解除・消去・完了承認
## 11. 実績・差異・改訂履歴

FAQ――自治体向け構築手順書の作り方

Q1. 製品マニュアルを参照するだけでは不足ですか。

不足です。製品マニュアルには自治体固有の対象、値、承認、停止基準、証跡、ロールバック、業務確認が含まれません。必要箇所を版付きで参照し、案件固有の統制を補います。

Q2. コマンドをすべて記載すべきですか。

再現性とレビューに必要なコマンドを記載します。ただし秘密情報は埋め込まず、承認済みスクリプトはハッシュ値と保管先を示します。実行対象と期待結果を必ず併記します。

Q3. 手順変更が当日必要になったらどうしますか。

作業を止め、変更理由、影響、リスク、代替、ロールバックを評価し、定めた変更承認者の明示承認を記録します。現場判断だけで続行しません。

Q4. 画面キャプチャは多いほどよいですか。

必要な判定を裏づける範囲に限定します。個人情報や秘密が映らないようにし、ファイル名と手順IDを統一します。大量取得は漏えいリスクと確認負荷を増やします。

Q5. 作業者と確認者を同じ人にできますか。

低リスク作業で規程上許される場合を除き、重要操作は分離します。人員制約がある場合は、画面共有、録画、事前承認などの代替統制を自治体と合意します。

Q6. ロールバックはバックアップ復元だけですか。

いいえ。設定切戻し、旧系へのトラフィック復帰、差分データ処理、外部連携、業務確認、周知まで含みます。復元後の整合性確認が不可欠です。

Q7. 個人情報を試験用に表示してよいですか。

必要最小限に限定し、承認・権限・記録・マスキング・消去を行います。原則として匿名化したデータを使用し、実在住民情報を例示に使いません。

Q8. 自動化スクリプトなら手順書は不要ですか。

必要です。入力、対象、版、ハッシュ、事前確認、dry-run、期待結果、停止条件、ログ、再実行可否、ロールバックを記載します。自動化は誤りも高速に拡大し得ます。

Q9. 夜間作業の完了承認は誰が行いますか。

作業設計で指定した自治体承認者が行います。原課確認が翌朝なら暫定完了とし、正式完了の条件と時刻を分けます。連絡不能時の安全停止も決めます。

Q10. AIで手順書を作成できますか。

下書き補助には使えますが、機密や個人情報を未承認サービスへ入力せず、生成コマンドを検証環境で確認します。存在しないオプションや古い製品仕様が混入し得るため、公式マニュアルの最新版と有資格者のレビューが必要です。

実践例：データベース変更を伴うリリース

データベース変更はアプリだけの切戻しができないことがあるため、手順を細かく分けます。最初に対象DB、スキーマ版、レプリケーション、バックアップ、空き容量を確認し、更新処理を止める時刻を原課と合意します。変更SQLは承認済みファイルのハッシュ値を照合し、dry-runまたは実行計画で対象件数を確認します。

実行前の判定では、バックアップ時刻、復元実測時間、現在件数、残り作業枠、切戻し最終時刻を読み上げます。SQL実行後は戻り値だけでなく、変更件数、制約、インデックス、代表データ、アプリログを確認します。予定件数との差が一件でも許容されない業務では、直ちに更新を止め、追加SQLで帳尻を合わせず原因を調査します。

新旧アプリの同時稼働ができないスキーマ変更では、不可逆点を明示し、その直前に自治体責任者の承認を置きます。新系で更新が始まった後のロールバックは、差分データ抽出、旧スキーマへの変換、二重登録防止まで検証します。切戻し後は、件数一致、代表業務、バッチ、帳票、外部連携を原課と確認します。

当日記録の具体例

22:03 B-010 対象DB名とテナントIDを二者確認／合格／証跡E010
22:08 B-020 バックアップ完了、復元所要18分を再確認／合格／E020
22:15 B-030 更新停止、キュー残0件／合格／E030
22:21 B-040 SQLハッシュ一致、想定更新12,480件／実施承認
22:27 B-050 実績12,480件、エラー0、制約正常／合格／E050
22:40 B-080 原課シナリオ3件合格／継続承認

レビューで見落としやすい点

レビューでは、コマンドの文法だけでなく、実行ディレクトリ、権限昇格、対象変数、ワイルドカード、改行、文字コードを確認します。クラウド管理画面はUI変更があるため、実施直前に画面名称とAPI代替を確認します。証明書更新では、中間証明書、秘密鍵対応、SNI、失効、監視期限も確認します。

ジョブやバッチを停止した場合、再開だけでなく未処理分、重複実行、翌日処理との競合を確認します。監視抑止は、対象を広げ過ぎず、解除予定時刻を設定します。構築成功後に作業端末へ残ったログ、ダウンロードファイル、クリップボード、接続履歴も後処理の対象です。

ネットワーク変更では、通信元・先、方向、ポート、名前解決、経路、タイムアウトを明示し、広すぎる許可を設定しません。変更前後のルール差分と疎通を記録し、暫定許可には自動失効日時を付けます。冗長系は片系だけで終えず、待機系への同期、切替、復帰を確認します。確認作業自体が住民サービスへ負荷を与えない時間・方法を選びます。

まとめ

自治体向け構築手順書の書き方で中心となるのは、再現可能な操作と安全な判断の両立です。対象識別、一操作一確認、個人情報保護、二者確認、承認と証跡、客観的な停止基準、検証済みのロールバックを一貫して組み込みます。自治体向け構築手順書の作り方を標準化すれば、担当者交代や緊急時にも品質を保てます。実施前には、法令、政府ガイドライン、自治体の条例・規程、契約、製品・クラウド仕様の最新版を必ず確認してください。