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

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

はじめに――作業設計書の結論

自治体向け作業設計書は、単なる作業一覧ではありません。住民サービスを止めず、個人情報を守り、誰が実施しても同じ品質で作業を完了できるように、目的、対象、役割、前提条件、実施順序、承認、証跡、停止基準、ロールバック、連絡経路を一つの統制文書にまとめるものです。よい作業設計書は、担当者の経験に依存せず、「開始してよい条件」「続けてよい条件」「中止すべき条件」「元に戻す方法」を第三者が判断できます。

自治体システムの作業では、平日窓口、夜間バッチ、税・福祉・住民記録等の繁忙期、議会日程、災害対応、庁内ネットワーク、LGWAN接続系、マイナンバー利用事務系などの制約が重なります。そのため、自治体向け作業設計書の書き方では、技術的に可能かだけでなく、業務上実施してよいか、条例・規程・契約上許されるか、住民への影響を説明できるかを確認します。

要点：作業設計書は「作業者のためのメモ」ではなく、「自治体と受託者が安全な実施条件に合意するための設計成果物」です。

想定読者

• 自治体の情報政策部門、原課、個人情報保護担当、情報セキュリティ責任者
• プロジェクト責任者、運用責任者、変更管理者、承認者
• 受託事業者のPM、インフラ・アプリ・ネットワーク・セキュリティ担当
• データ移行、保守、監視、サービスデスクの担当者
• 監査担当、調達担当、再委託先管理担当、第三者評価者

読者ごとに必要な粒度は異なります。作業者にはコマンドや確認値、承認者には影響とリスク、原課には業務停止時間と代替手段、監査担当には承認・実施・確認の証跡が必要です。一冊で読み分けられるよう、本文、詳細手順への参照、チェックリスト、判定記録を分けます。

標準的な章立て

1. 文書の目的、適用範囲、関連文書
2. 作業の背景、達成条件、対象外事項
3. 対象システム、環境、機器、データ、拠点
4. 実施体制、役割分担、承認経路、連絡網
5. 前提条件、依存関係、実施可能期間
6. 現状確認、バックアップ、事前試験
7. 作業方式、作業単位、順序、所要時間
8. リスク、影響、セキュリティ、個人情報保護
9. 開始条件、継続条件、停止基準、再開条件
10. ロールバック方針、復旧目標、判断者
11. 検証方法、完了条件、業務確認
12. 証跡、成果物、保管、廃棄
13. 周知、問い合わせ、障害・事故対応
14. チェックリスト、承認欄、改訂履歴

1. 目的と適用範囲の書き方

目的は「サーバーを更新する」のような手段ではなく、「脆弱性を解消し、対象サービスを継続可能な状態にする」のように達成状態で書きます。対象範囲は、本番・検証・開発の別、自治体コード、拠点、ネットワークセグメント、ホスト、アプリケーション、データ、連携先を明示します。対象外も明記し、暗黙の期待を残しません。

関連文書には、要件定義書、基本・詳細設計書、パラメータシート、構築手順書、試験計画書、運用設計書、契約仕様書、SLA、自治体情報セキュリティポリシーを挙げ、版番号と承認日を記載します。「最新版参照」だけでは、後で再現できません。

記載例

2. 体制と責任分界

自治体向け作業設計書では、会社名や部署名だけでなく役割を定義します。最低限、作業責任者、実施者、相互確認者、自治体承認者、業務確認者、セキュリティ連絡先、障害時エスカレーション先を記載します。実施者と承認者を分離し、重要操作は二者確認とします。

RACI表を使う場合は、R（実行）、A（最終責任）、C（協議）、I（報告）を一作業につき明確にします。外部クラウドや回線事業者が関係する場合、障害切り分けの責任分界、連絡受付時間、チケット番号の共有方法も設計します。再委託先には、契約上認められた範囲、アクセス権、個人情報の取扱い、作業場所を限定します。

3. 前提条件と依存関係

前提条件はチェック可能な文にします。「準備が完了していること」ではなく、「変更申請CHG-2026-015が承認済みであること」「バックアップのリストア試験が過去30日以内に成功していること」と書きます。

• 承認済みの変更申請・作業依頼がある
• 対象構成と資産台帳が一致している
• バックアップの取得先、暗号化、保持期間、復元方法が確認済み
• 作業アカウントは記名式で、必要最小権限かつ期限付きである
• 時刻同期が正常で、ログを突合できる
• 監視抑止と解除の時間・担当が決まっている
• 連携先、原課、ヘルプデスクへの周知が完了している
• 災害・選挙・税繁忙期等の作業禁止期間に該当しない
• 検証環境で同等手順を実施し、結果が承認されている

依存関係はネットワーク、DNS、証明書、ID管理、バッチ、外部API、バックアップ、監視、庁内端末まで洗い出します。構成図と突合し、片方向の矢印だけでなく、認証・名前解決・時刻同期・ログ転送等の基盤依存を忘れないことがポイントです。

4. 作業方式と手順粒度

作業を「準備」「開始判定」「変更」「中間確認」「切替」「業務確認」「監視強化」「終了判定」に分けます。各作業には、ID、予定時刻、所要時間、担当、入力、操作、期待結果、確認者、証跡、異常時処置を付けます。詳細なコマンドは構築手順書に委ねてもよいですが、作業設計書には方式選定の理由と統制点を残します。

一括切替、段階切替、ブルーグリーン、ローリング、カナリア等から方式を選びます。自治体の住民向けサービスは利用者を限定しにくいため、カナリア実施時の対象選択や公平性にも注意します。オンライン停止を伴う場合は、代替受付、紙運用、後続入力、問い合わせ案内を原課と合意します。

作業単位テンプレート

作業ID：W-120
作業名：新バージョンへのトラフィック切替
開始予定／上限時間：22:20／10分
実施者／確認者：インフラ担当A／担当B
開始条件：W-110正常、自治体承認者がチャットで実施許可
操作概要：負荷分散装置の接続先を新系へ段階的に変更
期待結果：新系ヘルスチェック正常、5xx率0.5%未満
証跡：変更前後画面、設定差分、監視グラフ、承認ログ
停止基準：5xx率1%以上が3分、認証失敗、個人情報誤表示
異常時：切替比率を0%へ戻しW-R10を実行、責任者へ連絡

5. リスクと自治体特有の影響

リスクは「発生可能性×影響度」で評価し、予防策、検知方法、発生時処置、所有者を記載します。住民の生命・身体、給付、課税、選挙、戸籍、災害情報に関わる場合、短時間の停止でも影響度を高く判定します。

自治体特有の観点として、閉庁後にもオンライン申請やコンビニ交付が動くこと、翌朝の窓口開始時刻が厳格であること、議会・首長・報道への説明が必要になり得ること、地域住民にデジタル弱者が含まれることを考慮します。多言語、アクセシビリティ、電話窓口、休日夜間連絡も設計対象です。

共同利用、広域連合、都道府県経由、国機関との連携では、一自治体だけで変更できない場合があります。各団体の承認期限と連絡経路、データ責任の境界を明示します。標準準拠システムやガバメントクラウドを扱う場合は、その時点の国の標準仕様、移行手順、クラウド責任共有モデルを公式資料で確認してください。

6. 個人情報・マイナンバー・機密情報

個人情報を含むデータを使うか、ログや画面キャプチャに氏名・住所・個人番号が映るかを事前評価します。本番データを試験に流用することを原則禁止し、やむを得ない場合は目的、法的根拠、承認、最小化、マスキング、保管、消去を定めます。個人番号は特定個人情報として、通常の個人情報より厳格に取り扱います。

作業端末へのローカル保存、私物端末、個人クラウド、無許可の生成AI、メール添付、公開チャットへの貼付を禁止します。画面証跡は必要箇所だけを取得し、個人情報を黒塗りするか、識別子を置換します。ただし改ざんと誤解されないよう、マスキング方法と原本の保管責任を記録します。

法令・ガイドライン・自治体規程は改定されます。個人情報保護法、番号法、総務省の自治体情報セキュリティ関連ガイドライン、当該自治体の条例・規則・ポリシーについて、作業実施時点の最新版を法務・情報セキュリティ担当と確認してください。本書の例を法的判断の代替にしてはいけません。

7. 開始条件、停止基準、再開条件

開始判定は会議や通話で行い、判定時刻、参加者、確認項目、決定を記録します。「問題がなければ開始」という黙示承認は禁止です。自治体承認者が明示的に開始を許可してから変更操作へ進みます。

停止基準は数値・事象・時間で客観化します。例は、エラー率、応答時間、監視アラート、データ件数不一致、連携遅延、個人情報誤表示、権限逸脱、予定超過、担当者との連絡断です。個人情報漏えいまたはそのおそれを検知した場合は、作業を停止して証拠保全し、自治体の事故対応手順に従います。

再開条件も必要です。原因が不明のまま同じ操作を繰り返してはいけません。責任者による原因仮説・影響範囲・追加対策の承認、バックアップの健全性、残存時間、関係者の再招集を確認します。時間切れの場合は安全な状態で終了し、別日程を申請します。

8. ロールバック設計

ロールバックは「バックアップがある」だけでは不十分です。戻す対象、戻す起点、実行判断者、所要時間、データ整合性、連携先への影響、復元後試験を記載します。アプリだけ旧版に戻すとDBスキーマが不整合になる、外部へ送信済みのデータは取り消せない、といった不可逆点を洗い出します。

ロールバック可能期限を時刻で示します。切替後に新系で受け付けた申請をどう扱うか、差分データをどう退避・再投入するかを決めます。RTO・RPOと現実の復旧所要時間が合わなければ、方式を見直します。少なくとも一度は検証環境で復元し、手順、権限、媒体、鍵、担当者が実際に利用可能であることを確認します。

ロールバック判断例

9. 検証、完了条件、証跡

技術確認と業務確認を分けます。技術確認はプロセス、ポート、ログ、性能、監視、バックアップ、冗長化を対象とし、業務確認は原課が代表的な申請、検索、帳票、決裁、外部連携を確認します。単に画面が開くことを正常としません。

完了条件は、全手順完了、重大エラーなし、必須試験合格、監視解除、暫定権限削除、原課確認、残課題登録、自治体承認を含めます。口頭の「大丈夫」ではなく、チェック欄と証跡番号で結びます。

証跡は、作業前後の設定、コマンド結果、変更差分、監視グラフ、チケット、承認記録、試験結果を含みます。ファイル名、取得者、取得時刻、対象、ハッシュ値、保管場所、閲覧権限、保存期間を定義します。ログ時刻のタイムゾーンも統一します。個人情報を必要以上に残さず、契約・規程に基づき安全に廃棄します。

10. 変更・版管理

作業設計書は、レビュー版、承認版、実施版、実績反映版を区別します。版番号、変更理由、変更箇所、作成者、レビュー者、承認者、承認日を記録します。承認後にコマンド、対象、時刻、停止基準を変える場合は、軽微な誤記訂正を除き再承認します。

当日変更は口頭だけで進めません。変更内容、理由、追加リスク、代替案、判断者、時刻を記録し、緊急変更プロセスに従います。作業後に実績時刻、差異、発生事象、暫定対応を追記し、次回の作業設計へフィードバックします。

書き方のポイント

1. 一文一判断にし、「適切に」「必要に応じて」を避ける。
2. システム名、環境名、日時、閾値、責任者を具体化する。
3. 操作と確認を分離し、重要操作にはダブルチェックを置く。
4. 正常系だけでなく異常系、時間切れ、連絡不能を設計する。
5. 業務影響を技術用語だけでなく住民目線で記載する。
6. 図表、ID、関連手順を使い、追跡可能性を確保する。
7. 既存の運用設計、構成図、パラメータシートと矛盾させない。
8. 作業後にアクセス権・監視抑止・保守モードを必ず戻す。

重要事項

• 自治体の正式な承認前に本番変更を実施しない。
• バックアップだけでなく、復元可能性と復元時間を確認する。
• 個人情報を含む証跡の範囲・保管・廃棄を設計する。
• 停止基準とロールバック判断者を作業開始前に確定する。
• 住民への周知、代替手段、問い合わせ体制を準備する。
• 委託先・再委託先を含むアクセスと持出しを管理する。
• 法令、国の標準、自治体規程は実施時点の最新版を確認する。

禁止事項

• 承認されていない対象、コマンド、時間帯への変更
• 共用ID、他人のID、恒久的な特権IDによる作業
• 本番個人情報の無断コピー、私物媒体への保存、無許可持出し
• 停止基準に達した後の独断継続や、同一操作の漫然とした再実行
• 証跡の削除、改変、都合のよい画面だけの選別
• バックアップ取得未確認での不可逆なデータ変更
• チャットやメールにパスワード、秘密鍵、個人番号を平文記載
• 監視抑止、メンテナンス表示、暫定ルールの戻し忘れ
• 実績と異なる完了報告、未試験項目の合格扱い
• 法令やガイドラインの古い版を無確認で引用すること

実務チェックリスト

設計・レビュー時

• [ ] 目的、成功条件、対象、対象外が明確である
• [ ] 構成図・台帳・設計書と対象情報が一致する
• [ ] 自治体、受託者、再委託先の責任分界が明確である
• [ ] 作業者と確認者、最終承認者が指定されている
• [ ] 個人情報・特定個人情報の取扱いを評価した
• [ ] 業務繁忙期、選挙、議会、災害体制と競合しない
• [ ] 外部連携、バッチ、バックアップ、監視への影響を確認した
• [ ] 数値化した停止基準と再開条件がある
• [ ] ロールバック手順を検証し所要時間を測定した
• [ ] 住民・職員への周知と代替手段を用意した

作業開始前

• [ ] 承認済みの版を全員が参照している
• [ ] 変更凍結、他作業との競合、障害発生状況を確認した
• [ ] バックアップ成功と復元に必要な鍵・権限を確認した
• [ ] 記名式の期限付きアカウントで接続できる
• [ ] 連絡網と会議・チャット・電話の代替経路が使える
• [ ] 監視値と業務件数のベースラインを保存した
• [ ] 自治体承認者が開始を明示承認した

作業中・完了時

• [ ] 各工程を実績時刻・実施者・確認者とともに記録した
• [ ] 停止基準を継続監視し、異常を隠さず報告した
• [ ] 変更前後の差分と必要な証跡を取得した
• [ ] 技術試験と原課による業務試験が合格した
• [ ] 監視抑止、暫定権限、保守画面を解除した
• [ ] 未解決事項を課題票に登録し、所有者と期限を決めた
• [ ] 個人情報を含む一時ファイルを規程どおり消去した
• [ ] 完了承認と関係者への終了連絡を記録した

完成イメージ：短縮テンプレート

# ○○作業設計書
文書番号／版／機密区分／作成・レビュー・承認

## 1. 目的と成功条件
## 2. 対象・対象外・関連文書
## 3. 日時・業務影響・代替運用
## 4. 体制・RACI・緊急連絡網
## 5. 前提条件・依存関係・禁止期間
## 6. 作業方式と工程表
## 7. 個人情報・セキュリティ対策
## 8. リスク一覧
## 9. 開始／継続／停止／再開の判定基準
## 10. ロールバック方式と復旧確認
## 11. 試験・完了条件・証跡
## 12. 周知・問い合わせ・事故対応
## 13. チェックリスト・承認記録・改訂履歴

FAQ――自治体向け作業設計書の作り方

Q1. 作業設計書と構築手順書の違いは何ですか。

作業設計書は、なぜ、何を、どの条件・体制・方式で安全に実施するかを定めます。構築手順書は、個々の操作を再現可能な粒度で示します。前者が統制と判断、後者が操作と確認を中心にし、相互参照させます。

Q2. 小さな設定変更にも必要ですか。

影響とリスクに応じて簡略版を使えます。ただし、対象、承認、バックアップ、確認、停止基準、ロールバック、証跡は省略しません。小規模であることと無リスクであることは同義ではありません。

Q3. 停止基準はどこまで具体的にしますか。

担当者によらず同じ判断になる程度に、監視項目、閾値、継続時間、対象範囲を記載します。「性能が悪化したら」ではなく「95パーセンタイル応答が3秒超で5分継続」のように書きます。

Q4. ロールバックできない変更はどう扱いますか。

不可逆点を明示し、その前に最終承認を置きます。代替復旧、データ再作成、段階適用、追加バックアップを設計し、許容できない場合は方式自体を変更します。

Q5. 本番データを確認に使えますか。

目的達成に必要な最小範囲に限り、自治体の承認と規程に従います。試験では匿名化・仮名化したデータを優先し、取得した証跡に個人情報を残さない設計が基本です。

Q6. 夜間作業なら住民周知は不要ですか。

不要とは限りません。オンライン申請、コンビニ交付、予約、緊急情報等は夜間も利用されます。影響、停止時間、代替手段、問い合わせ先を評価して周知要否を自治体が決定します。

Q7. クラウド事業者の作業は誰が記録しますか。

自治体側の変更記録に、事業者チケット、実施日時、影響、結果、証跡への参照を残します。責任共有モデルに沿っても、自治体の説明責任が消えるわけではありません。

Q8. 緊急作業では承認を省略できますか。

通常手続を短縮しても、緊急変更の承認者、理由、影響、作業、結果を記録します。事後承認の期限を定め、緊急性を通常変更の抜け道にしてはいけません。

Q9. AIで作業設計書を作ってよいですか。

補助利用は可能ですが、機密情報・個人情報を未承認サービスへ入力せず、生成内容を人が設計書・現行構成・法令と照合します。架空のコマンド、存在しない規程、古い基準の混入に注意し、責任者が承認します。

Q10. いつ更新すべきですか。

対象構成、法令・規程、連携仕様、担当体制、停止許容時間、ロールバック方法が変わったときに更新します。定例作業でも定期レビューし、実績差異とインシデントの教訓を反映します。

レビュー会議の進め方と記録例

作業設計書のレビューは、技術チームだけで完結させません。自治体の情報政策部門、対象原課、運用、セキュリティ、個人情報保護の担当が、自分の責任範囲を確認します。会議前に承認候補版、構成図、変更差分、リスク一覧を配布し、会議では「対象は正しいか」「翌朝業務へ影響しないか」「個人情報が残らないか」「切戻し時間を確保できるか」を順番に判定します。

指摘は、指摘ID、対象章、重要度、内容、理由、対応者、期限、対応結果、確認者で管理します。「当日相談」として残さず、開始前に解消するか、残存リスクとして自治体承認を得ます。口頭合意も議事録へ記録し、承認済み本文との矛盾がないことを確認します。

判定議事録の例

会議：本番作業開始判定会議
日時・参加者：2026年○月○日 21:30／自治体責任者、原課、受託者責任者ほか
確認：障害発生なし、バックアップ成功、リストア確認済み、周知済み
残存リスク：軽微な監視警告1件。業務影響なし、監視継続を条件に受容
決定：承認済み手順v1.3で22:00開始
停止条件：認証失敗1件、エラー率1%超3分、22:40までに切替未完了
切戻し最終開始：22:45
承認者・時刻：○○課長／21:42

この記録は作業チケットとひも付け、作業後レビューで計画と実績の差を確認します。開始が遅れた、想定より警告が多かった、原課確認に時間を要した等の差異は、次回の標準時間と停止基準へ反映します。

まとめ

自治体向け作業設計書の書き方で最も重要なのは、作業手順を増やすことではなく、住民サービスと情報を守る判断点を明文化することです。目的と成功条件、責任分界、個人情報保護、承認と証跡、客観的な停止基準、検証済みのロールバックを一貫して記載してください。自治体向け作業設計書の作り方を標準化すると、担当者交代や再委託があっても、同じ統制と品質で作業できます。実施直前には、適用される法令、政府・所管省庁のガイドライン、自治体の条例・規程、契約、クラウド仕様の最新版を必ず確認しましょう。