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

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

要約・結論

自治体向け基本設計書は、承認済み要件を、利用者・業務担当者・運用担当者が確認できるシステムの外部仕様へ変換する文書です。画面、帳票、業務処理、データ、外部連携、権限、非機能、運用の全体像を示し、詳細設計、開発、試験、移行、マニュアル作成の共通基準になります。

自治体向け基本設計書の書き方の結論は、「要件を満たす理由」と「利用者から見える振る舞い」を、図表と一貫した用語で具体化し、設計IDから要件ID・試験IDへ追跡可能にすることです。正常時だけでなく、誤入力、権限不足、連携停止、災害、取消し、訂正まで設計します。個人情報保護、セキュリティ、アクセシビリティ、デジタルが苦手な住民への代替手段、運用引継ぎを横断的に反映します。技術や制度は変化するため、適用する法令、条例、国のガイドライン、自治体規程、製品仕様の最新版を設計時点で確認してください。

想定読者

• 自治体の業務原課、DX・情報政策、運用、セキュリティ担当者
• 基本設計を作成・レビューするSE、業務分析者、アーキテクト、PM
• 詳細設計、開発、試験、移行、教育、保守を担当する事業者
• 受入試験や稼働判定を行う自治体職員
• アクセシビリティ、個人情報保護、監査等の専門担当者

自治体向け基本設計書の推奨章立て

1. 文書目的、対象範囲、用語、参照文書、版・承認
2. 設計方針と制約
3. 業務・システム全体構成
4. 機能構成、業務フロー、ユースケース
5. 画面設計、帳票設計、通知設計
6. 権限・組織・認証設計
7. 論理データ設計
8. 外部インターフェース設計
9. 非機能設計
10. セキュリティ・個人情報保護設計
11. アクセシビリティ・ユーザビリティ設計
12. 運用・監視・バックアップ設計
13. 移行、切替、教育、引継ぎ設計
14. エラー・障害・例外設計
15. 要件・設計・試験トレーサビリティ
16. 前提、未決事項、リスク、変更履歴

1. 基本設計の開始条件と完了条件

開始前に、要件定義書の承認状態、未決事項、優先度、予算・納期への影響を確認します。未承認要件を暗黙に設計へ取り込むと、後で手戻りになります。未決事項を設計上の仮定として扱う場合は、仮定、責任者、決定期限、変更影響を記録します。

設計計画では、文書体系、章ごとの責任者、レビュー参加者、承認者、設計ツール、記法、版管理、変更手続を定めます。業務原課は業務と画面、情報政策は構成と運用、セキュリティ担当は権限やログ等を確認するなど、レビュー観点を割り当てます。

完了条件は、単に文書が埋まったことではありません。全要件が設計へ割り当てられ、画面・データ・連携間の整合が取れ、未決事項の扱いが承認され、詳細設計と試験設計を開始できる状態です。見積やスケジュールに影響する設計変更も反映します。

2. 設計方針の書き方

設計方針には、住民中心、標準機能優先、設定による変更、疎結合、オープンなデータ形式、最小権限、プライバシー保護、アクセシビリティ、運用自動化などを記載します。ただし標語だけで終わらせず、具体的な設計判断へつなげます。

例：「標準機能優先」は、現行業務をそのまま追加開発するのではなく、法令・政策上必須でない差異は標準業務へ合わせることを意味します。「個人情報最小化」は、入力項目、ログ、検証環境、バックアップに同じ方針を適用します。

技術制約には、ネットワーク区分、利用端末、ブラウザ、認証基盤、クラウド利用方針、既存連携、調達済み製品、保守可能時間を示します。自治体ごとに環境が異なるため、一般的な構成を決めつけません。

3. 全体構成設計

全体構成図には、住民・職員・管理者、端末、ネットワーク境界、認証、Web・アプリ、データベース、外部サービス、連携先、監視、バックアップ、管理経路を記載します。矢印には通信方向、方式、主要データを付けます。信頼境界を示し、どこで認証・暗号化・検査を行うか明確にします。

論理構成と物理構成を分けると、業務機能と製品配置を混同しません。クラウドでは、事業者と自治体の責任共有、リージョン、可用性ゾーン、管理者アクセス、ログ保管、鍵管理を説明します。製品名やIP等の詳細を公開版へ記載する場合は、情報管理区分を確認します。

インターネット系、LGWAN接続系、マイナンバー利用事務系等の扱いは、自治体の実際の構成と最新方針に従います。「自治体なら必ずこの接続」と断定せず、承認されたネットワーク設計を参照します。

4. 機能構成と業務フロー

機能一覧には、機能ID、名称、利用者、概要、関連要件、画面、帳票、データ、権限を記載します。階層化し、同じ処理を複数機能へ重複定義しません。標準機能、設定、追加開発、外部サービスを区別します。

業務フローは、住民、自治体、外部機関、システムのスイムレーンで表現します。開始・終了、判断、手作業、自動処理、通知、データ保存、例外を示します。画面遷移だけでは、承認や差戻しなど業務上の責任が分かりません。

ユースケースは、主アクター、目的、事前条件、基本フロー、代替フロー、例外、事後条件を記載します。代理申請、取下げ、訂正、重複、期限切れ、通信断を含めます。住民が途中で支援を求めたときに、どの情報を職員が閲覧できるかも個人情報保護と合わせて設計します。

5. 画面設計の書き方

画面一覧には、画面ID、名称、利用者、目的、入口、遷移先、関連要件を記載します。画面レイアウトには項目、部品、操作、表示条件、活性・非活性、初期値、入力制約、エラー、権限を定義します。

画面ID：SCR-APP-010
画面名：申請内容確認
目的：提出前に入力内容と同意事項を確認する。
表示条件：入力チェック済みの申請を対象とする。
主要操作：修正へ戻る／申請する／一時保存する。
二重送信対策：申請ボタン押下後は処理中を表示し、同一要求を重複登録しない。
エラー：送信失敗時は入力内容を保持し、再実行方法と問い合わせ先を表示する。
アクセシビリティ：見出し構造、フォーカス順、読み上げ、エラー関連付けを定義する。
関連要件：FUN-APP-020、ACC-004、SEC-LOG-003

一覧画面では検索条件、初期表示、ソート、ページング、最大件数、CSV、マスキングを定義します。個人情報を一覧に過剰表示せず、業務に必要な項目に絞ります。画面モックは見た目だけでなく、状態変化とエラーをレビューします。

レスポンシブ対応では、想定幅、タップ領域、横スクロール、ソフトウェアキーボードを確認します。特定の色、画像、マウス操作だけに意味を依存させません。

6. 帳票・通知設計

帳票一覧には、帳票ID、用途、出力者、出力契機、形式、保存、配布、個人情報区分を記載します。項目定義、編集、改ページ、空欄、合計、日付、文字溢れ、二次元コード、押印欄を設計します。PDFを公開・配布する場合は、読み上げ順、タグ、代替テキスト等も検討します。

通知設計は、通知ID、契機、宛先、チャネル、件名、本文テンプレート、差込項目、再送、失敗時対応を定義します。メールやSMSへ機微情報を直接書かず、安全な画面で確認させる方式を選べます。誤送信を防ぐ宛先確認、配信停止、古い連絡先の扱いも重要です。

テンプレート変更の権限、承認、履歴を設計します。自治体が文面を変更できる場合、HTML崩れや不正なスクリプトを防ぐ入力制約を設けます。多言語は言語ごとの更新責任と未翻訳時の表示を決めます。

7. 権限・認証・組織設計

役割ごとに、閲覧、登録、更新、削除、承認、出力、設定、ログ閲覧の権限マトリクスを作ります。組織階層、兼務、代理承認、期間限定権限、異動、休職、退職、委託先を扱います。役割名称と実際の権限を混同せず、最小権限を基本とします。

認証設計には、認証方式、多要素認証、セッション、ロック、再認証、パスワードを使う場合の管理、アカウント回復を記載します。住民向け認証は、必要な本人確認強度を業務リスクに合わせます。過剰な本人確認がサービス利用を妨げる場合と、不十分な確認でなりすましが起きる場合の両方を評価します。

特権IDは、通常業務との分離、申請・承認、使用記録、保管、定期棚卸し、緊急利用を設計します。共用IDを原則避け、やむを得ない場合は利用者を追跡できる代替統制を設けます。

8. 論理データ設計

ER図、エンティティ一覧、データ辞書、コード一覧を作成します。データ項目には、名称、意味、型、桁、必須、制約、初期値、更新者、機密区分、保持期間を付けます。画面、帳票、連携の項目名とデータ辞書を統一します。

履歴管理では、何を履歴として残すか、現行値との関係、訂正、取消し、監査ログとの違いを定義します。論理削除を採用する場合、検索対象、保存期限、物理削除、復元の扱いを決めます。無期限に残すことは安全策ではなく、漏えい時の影響を増やし得ます。

住所、氏名、外字、日付、コード、添付ファイルの扱いは自治体業務で問題になりやすい部分です。文字コード、正規化、旧字体、最大サイズ、ウイルス検査、拡張子、実体形式を設計します。テストデータには本番の個人情報を安易に使いません。

9. 外部インターフェース設計

インターフェース一覧には、IF ID、連携先、目的、方向、同期・非同期、方式、頻度、データ、認証、責任者を記載します。API設計では、エンドポイント、要求・応答、状態コード、タイムアウト、再試行、冪等性、レート制限、バージョンを定義します。

ファイル連携では、ファイル名、形式、文字コード、区切り、ヘッダー、暗号化、圧縮、配置場所、受領確認、再送、保管、削除を定義します。項目マッピングには変換、必須、コード差、欠損時処理を記載します。

連携障害は、検知、通知、再処理、手動代替、データ整合確認を設計します。送信元が成功でも受信側の業務処理が失敗する場合を考慮します。相手システムの仕様変更通知と互換期間も運用設計につなげます。

10. 非機能基本設計

要件で定めた目標を、構成と運用でどう達成するかを書きます。可用性では冗長化、切替、単一障害点、計画保守を設計します。性能では想定利用者、ピーク、データ量、キャッシュ、バッチ競合を整理し、性能試験条件へつなげます。

バックアップは対象、方式、頻度、保持、保管場所、暗号化、監視、復元手順を設計します。バックアップ取得の成功だけでなく、定期的な復元試験を計画します。RTO・RPOと整合しない構成にしないでください。

監視は、死活、リソース、アプリケーション、ジョブ、連携、証明書期限、セキュリティイベントを対象にし、しきい値、通知、一次対応を定義します。アラート過多で重大通知が埋もれないよう、優先度と抑制を設計します。

11. セキュリティ・個人情報保護設計

脅威分析を行い、なりすまし、改ざん、情報漏えい、サービス妨害、権限昇格等への対策を配置します。入力検証、出力時エスケープ、認証・認可、暗号化、秘密情報管理、セキュアな通信、脆弱性対応を設計します。

監査ログは、対象操作、記録項目、保存、改ざん防止、アクセス、検索、監視を定義します。個人情報への参照や一括出力、権限変更、管理操作は重要です。ログへパスワード、秘密鍵、不要な本文を記録しません。

データライフサイクルとして、収集、利用、共有、保管、バックアップ、アーカイブ、削除を図示します。再委託や外部サービスへデータが渡る場合、範囲と管理策を記載します。開発・試験環境へはマスキングまたは合成データを用いる方針を示します。

脆弱性診断、コードレビュー、依存部品管理、パッチ適用、インシデント対応の設計も必要です。「完全に安全」と断定せず、予防・検知・封じ込め・復旧・改善を多層化します。

12. アクセシビリティ・ユーザビリティ設計

アクセシビリティ方針を画面部品の共通設計へ落とします。見出し、ラベル、フォーカス、キーボード操作、コントラスト、拡大、読み上げ、状態通知、エラー、時間制限、動画字幕を定義します。共通部品で担保しつつ、個別画面でも確認します。

エラーは色だけで示さず、問題のある項目と理由、修正方法を文章で伝えます。入力例と形式を入力前に示し、エラー時に入力値を失わせません。制限時間がある場合は事前通知と延長を検討します。

やさしい日本語、多言語、ふりがな等は対象利用者に基づき設計します。自動翻訳を使う場合は、誤訳の確認、原文表示、問い合わせ先を定めます。窓口や電話など代替手段への導線を分かりやすく示します。

13. エラー・障害・例外設計

エラーコード体系を作り、利用者向けメッセージと運用者向け詳細を分けます。住民へ内部構成や個人情報を表示せず、次にできる行動と問い合わせ識別番号を示します。ログには調査に必要な相関IDを残します。

業務エラー、入力エラー、認証・権限エラー、連携エラー、システムエラーを分類します。再試行可能か、処理は確定したか、二重登録を防げるかを設計します。障害中の受付、紙への切替、復旧後の追加入力など代替業務も記載します。

障害復旧後は、未処理・重複・不整合を確認する手順が必要です。復旧しただけでサービス再開とせず、データ整合と関係部署の承認を稼働再開条件にします。

14. 運用・移行・引継ぎ設計

運用設計では、日次・月次・年次作業、ジョブ、監視、問い合わせ、障害、問題、変更、リリース、アカウント、容量、証明書、報告を整理します。自治体と事業者の役割分担、実施証跡、承認者を定義します。

移行設計は、抽出、受領、診断、変換、投入、照合、リハーサル、切替、戻しを記載します。移行中の個人情報を暗号化し、アクセスを限定し、作業後に安全に消去します。件数、項目、関連、添付、権限を照合します。

引継ぎ設計では、構成、設定、手順、アカウント、証明書、障害・変更履歴、未解決課題、データ辞書を継続的に更新します。契約終了時のデータ出力形式、後継事業者説明、並行期間、消去証明も設計対象です。

15. トレーサビリティとレビュー

レビューは作成者の説明会だけにせず、事前配布、観点別確認、指摘記録、対応、再確認を行います。業務担当には業務用語と画面、技術担当には構成と連携、運用担当には障害・監視を確認してもらいます。

設計変更は、要件、詳細設計、試験、移行、マニュアル、費用、納期への影響を分析します。承認された基準版を明確にし、古い版で開発や試験が進まないよう版管理します。

重要事項

1. 全設計に根拠となる要件IDを紐づける。
2. 利用者から見える振る舞いと例外を具体化する。
3. 画面、データ、連携、権限の用語と項目を統一する。
4. 正常系だけでなく、取消し、訂正、障害、災害を設計する。
5. 個人情報を画面、ログ、検証環境で最小化する。
6. アクセシビリティを共通部品とレビュー工程へ組み込む。
7. 運用・監視・復元・引継ぎを開発と同時に設計する。
8. 自治体と事業者の責任境界を明示する。
9. 未決事項へ責任者と期限を付ける。
10. 最新の法令、条例、国のガイドライン、製品仕様を確認する。

禁止事項

• 要件との対応を示さず、設計者の好みで機能を追加する。
• 画面イメージだけで業務ルール、エラー、権限を省略する。
• 本番の個人情報を設計書やサンプル画面へ掲載する。
• パスワード、秘密鍵、実IP等を閲覧範囲の広い文書へ記載する。
• すべての失敗を同じエラーメッセージで処理する。
• アクセシビリティを納品前のチェックだけにする。
• クラウド事業者が全セキュリティ責任を負うと誤認する。
• 外部連携先の停止、再送、重複を設計しない。
• 運用者が手作業で補えばよいとして手順・負荷を記載しない。
• 未承認の変更を口頭指示だけで設計へ反映する。

具体的な基本設計テンプレート

設計ID：［一意なID］
設計名称：［機能・画面・データ・運用等の名称］
目的：［利用者価値・業務目的］
関連要件：［要件ID］
対象利用者・権限：［役割］
事前条件：［開始状態］
基本処理：［入力→処理→出力］
代替・例外：［誤入力、取消し、障害、期限切れ等］
データ：［参照、登録、更新、削除、履歴］
ログ・監視：［記録、アラート］
セキュリティ・個人情報：［対策］
アクセシビリティ：［操作・表示・試験観点］
運用：［担当、頻度、手順へのリンク］
試験観点：［正常、境界、例外、権限等］
未決事項：［内容、責任者、期限］

実務チェックリスト

文書と追跡

• [ ] 文書目的、対象範囲、参照版、用語を明記した
• [ ] 全要件が一つ以上の設計へ紐づいている
• [ ] 設計IDと画面・帳票・IF・データIDが重複していない
• [ ] 未決事項に責任者と期限がある
• [ ] 自治体と事業者の承認記録がある

機能・データ・連携

• [ ] 正常、代替、例外、取消し、訂正を設計した
• [ ] 画面項目とデータ辞書と連携項目が一致する
• [ ] 権限マトリクスと画面・機能制御が一致する
• [ ] 連携停止、再送、重複、タイムアウトを設計した
• [ ] 帳票と通知の個人情報表示を最小化した

非機能・公共性

• [ ] 性能、可用性、復旧目標を構成へ反映した
• [ ] バックアップの復元試験を設計した
• [ ] 認証、権限、ログ、暗号化、脆弱性対応を設計した
• [ ] アクセシビリティを共通設計と個別画面へ反映した
• [ ] デジタル以外の代替業務と障害時手順を設計した
• [ ] 移行、教育、運用、契約終了時引継ぎを設計した
• [ ] 最新の条例、ガイドライン、自治体規程を確認した

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

Q1. 基本設計書と詳細設計書の違いは何ですか。

基本設計書は利用者や業務担当者が確認できる外部仕様と全体方式を示します。詳細設計書は内部処理、物理データ、プログラム等、実装に必要な仕様を具体化します。境界は案件の文書体系で合意します。

Q2. パッケージやSaaSでも基本設計書は必要ですか。

必要です。標準機能の説明を転記するだけでなく、設定値、業務フロー、権限、連携、データ、運用、対象外を自治体の利用方法に合わせて記録します。

Q3. 画面設計はどこまで作り込みますか。

レイアウトだけでなく、項目、入力制約、表示条件、遷移、権限、エラー、アクセシビリティを確認できる粒度にします。視覚デザインの細部は別ガイドへ分けても構いません。

Q4. 基本設計書に製品名やIPアドレスを書きますか。

製品配置は必要に応じ記載しますが、IPや秘密情報は情報区分と閲覧範囲を考慮し、詳細構成書やパラメータシートへ分離します。

Q5. セキュリティ設計は別冊でもよいですか。

別冊でも構いませんが、画面、データ、連携、運用の各章から参照し、抜けを防ぎます。別冊化しても要件とのトレーサビリティは維持します。

Q6. アクセシビリティは画面設計にどう書きますか。

共通部品の規則と、個別画面の見出し、ラベル、フォーカス、エラー、読み上げ等を記載します。試験観点と不適合時の修正方法にもつなげます。

Q7. 未決事項が残っていても基本設計を完了できますか。

影響が限定され、仮定、責任者、期限、変更手続が承認されていれば可能な場合があります。重大な費用・安全・業務判断に関わる未決事項は完了前に解消します。

Q8. AI機能の基本設計で必要なことは何ですか。

入力可能情報、プロンプト等の管理、出力の利用範囲、人の確認、誤回答、ログ、モデル変更、停止、評価を設計します。確率的性質を利用者へ伝え、最終判断の責任を明確にします。

Q9. 基本設計レビューに住民は参加すべきですか。

全設計への参加が必須とは限りませんが、住民向け手続では対象利用者によるプロトタイプ確認が有効です。参加者の多様性、安全、同意、個人情報に配慮します。

Q10. 基本設計の承認後に変更が出たらどうしますか。

変更理由と、要件、費用、納期、試験、運用への影響を分析し、権限者の承認後に基準版を更新します。関連文書とトレーサビリティ表も同時に更新します。

まとめ

自治体向け基本設計書の作り方は、要件を実装可能な形へ落としながら、業務担当者にも検証できる外部仕様を保つことです。画面、帳票、データ、連携、権限、非機能を個別に書くだけでなく、相互の整合性を確認してください。個人情報保護、セキュリティ、アクセシビリティ、障害時の代替業務、移行、運用引継ぎを設計の中心に置きます。最新の法令、条例、国のガイドライン、自治体規程、製品仕様を案件時点で確認し、要件から試験まで追跡できる自治体向け基本設計書に仕上げることで、安全で継続可能な住民サービスにつながります。