自治体向けシステム構成図の書き方・作り方

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

はじめに　要約と結論

自治体向けシステム構成図は、機器やクラウドサービスを並べた絵ではありません。住民、自治体職員、委託事業者、他団体、外部サービスが、どの経路で、どの情報に、どの権限でアクセスするかを一枚ずつ明らかにする設計・説明・監査の基礎資料です。よい自治体向けシステム構成図は、非技術者が全体像と責任分界を理解でき、技術者が通信経路、冗長化、監視、バックアップを確認でき、情報セキュリティ担当者が境界防御とデータ保護を検証できます。

結論は、目的別に図を分け、各図に凡例、対象範囲、版、基準日、データ区分、通信方向、責任主体を付けることです。一枚にすべてを書き込まず、全体構成図、論理構成図、ネットワーク構成図、物理構成図、データ連携図、セキュリティ構成図、運用監視構成図、災害対策構成図へ段階的に分解します。自治体向けシステム構成図の書き方では、見栄えよりも、要件・設計・試験・運用の間で同じ対象を追跡できる正確さが重要です。

想定読者と利用場面

想定読者は、情報政策部門、業務主管課、個人情報保護・情報セキュリティ担当、契約・調達担当、運用担当、監査担当、首長部局、受託事業者、クラウド事業者、ネットワーク事業者です。利用場面は、予算要求、調達仕様の検討、提案評価、要件定義、設計審査、変更審査、障害対応、監査、引継ぎ、住民説明などです。

1　自治体向けシステム構成図の章立て

構成図資料は、次の順で作ると読み手が迷いません。

1. 文書情報と改訂履歴
2. 目的、対象範囲、対象外、前提条件
3. 用語・略語・記号・色の凡例
4. 全体構成図
5. 利用者・拠点・端末構成
6. 論理構成図と機能配置
7. ネットワーク・通信構成図
8. 認証・権限・セキュリティ構成図
9. データ連携・ファイル連携構成図
10. 物理・クラウドリソース構成図
11. 監視・ログ・バックアップ構成図
12. 冗長化・災害対策・復旧構成図
13. 責任分界、運用主体、保守接続
14. 構成要素一覧、関連文書、未決事項

構成図番号は「ARC-01」、構成要素IDは「CMP-001」、通信経路IDは「FLOW-001」のように一意にします。要件定義書、詳細設計書、パラメータシート、試験項目、資産管理表でも同じIDを使うと、自治体向けシステム構成図が変更管理の中心になります。

2　書き方・作り方の手順

2.1　目的とスコープを一文で固定する

最初に「本図は、住民申請サービスから庁内審査、外部通知までの本番環境の論理構成と責任分界を示す」のように目的を定義します。開発環境を含むか、端末を含むか、回線を含むか、既存共通基盤を含むかも明記します。「自治体システム全体」のような曖昧な範囲は避けます。

2.2　登場主体と情報を洗い出す

住民、職員、管理者、コールセンター、保守員、連携先団体を列挙します。続いて、個人情報、本人確認情報、申請添付、決済情報、通知文書、統計情報、監査ログなど、流れる情報を分類します。機器から描き始めるのではなく、誰が何を扱うかから始めることが自治体向けシステム構成図の作り方の基本です。

2.3　信頼境界を決める

インターネット、住民向け公開領域、クラウド内の公開・非公開領域、庁内ネットワーク、運用管理領域、外部連携先を区切ります。境界を越える矢印には、通信元、通信先、方向、プロトコル、ポート、暗号化、認証方式、送信データ、制御機器、ログ取得の有無を対応付けます。

2.4　粒度の異なる図に分ける

全体構成図は十数個程度の主要ブロックに絞り、詳細は別図へ送ります。ネットワーク構成図ではセグメントと経路、データ連携図では情報とタイミング、物理構成図では台数と配置、運用図では監視・通知・保守経路を中心にします。同じ対象の名前が図ごとに変わらないよう、構成要素台帳を正本にします。

2.5　正常系と例外系を確認する

住民の通常申請だけでなく、認証失敗、外部連携停止、回線断、AZ障害、バックアップ取得失敗、運用端末故障、証明書期限切れ、災害時切替を図上でたどります。例外系をたどれない構成図は、運用設計と試験設計に使えません。

2.6　レビューと承認を行う

業務、基盤、ネットワーク、アプリ、セキュリティ、運用、調達の各担当が共同でレビューします。レビュー記録には指摘、回答、対応図番号、対応版、承認者を残します。図の更新後は、構成要素一覧、通信一覧、パラメータシート、試験項目も同時に更新します。

3　図ごとの書き方とポイント

3.1　全体構成図

全体構成図は、利用者から業務処理、外部連携、運用管理までを俯瞰する入口です。製品名やIPアドレスを詰め込まず、「住民向けWeb」「認証基盤」「業務API」「業務データベース」「文書保管」「外部連携」「監視」の役割で表します。主要な信頼境界、データの向き、別契約の範囲を見せます。

3.2　論理・ネットワーク構成図

論理構成図はWeb、API、バッチ、帳票、通知、キュー、キャッシュ等の機能配置と単一障害点を示します。ネットワーク構成図には、区分、サブネット、ルート、FW、WAF、ロードバランサ、DNS、プロキシ、VPN・閉域接続、管理経路を記載します。公開経路と保守経路を分け、経路IDを付けます。IPアドレス等は公開版と管理版を分けます。

3.4　データ連携構成図

データ連携構成図は、何を、誰が、いつ、どの形式で、どこへ送るかを示します。API、ファイル、メッセージ、手動媒体を区別し、リアルタイム・定時、再送、重複排除、タイムアウト、文字コード、暗号化、エラー通知を連携一覧に記載します。自治体間や国のシステムとの連携は、相手方仕様と責任分界を特に明確にします。

3.5　セキュリティ構成図

認証基盤、多要素認証、権限管理、秘密情報管理、鍵・証明書、マルウェア対策、WAF、EDR、ログ集約、時刻同期を配置します。アクセス制御は「FWあり」だけで済ませず、入口、出口、管理、データ、ログの各経路に統制を対応付けます。ゼロトラストの名称だけを使い、端末状態、認証強度、最小権限、継続評価を説明しない表現は避けます。

3.6　監視・バックアップ・災害対策構成図

監視対象、ログ転送先、通知先、一次対応者をつなぎます。バックアップは対象、保存先、世代、暗号化、隔離、復元経路を表します。冗長化方式、自動・手動切替、復旧目標との関係を示し、災害対策は同期、切替、データ差分、復帰を別図にします。

4　テキストで表す構成図の具体例

特定の描画ツールやMermaidが使えない場面でも、次のようなテキスト表現ならレビューできます。

[住民PC・スマートフォン]
        |
        | FLOW-001 HTTPS／住民認証
        v
【インターネット境界】
        |
   [DNS]--[DDoS対策]--[WAF]
        |                    監視ログ ----+
        v                                 |
  [公開ロードバランサ]                    v
        |                         [ログ集約・監視]
        v                                 |
  [住民向けWeb 2台相当]                   +--> [運用担当通知]
        |
        | FLOW-010 内部TLS／サービス認証
        v
【非公開アプリ領域】
  [業務API 2台相当] ---> [メッセージキュー] ---> [通知サービス]
        |
        | FLOW-020 TLS／最小権限DBユーザー
        v
【データ領域】
  [主DB] === 同期レプリケーション === [待機DB]
        |
        +---暗号化バックアップ---> [別領域保管]
        |
        +---監査ログ--------------> [改変防止保管]

[職員端末] -- FLOW-030／庁内接続・職員認証 --> [職員Web] --> [業務API]
[保守端末] -- 承認済み時間帯・MFA・踏み台 --> [管理領域]

図の直下には、次の補足を付けます。

5　構成要素一覧と通信一覧のテンプレート

構成図だけでは検索、差分確認、試験設計が難しいため、一覧を必ず併設します。

構成要素一覧

通信一覧

実案件では、採用する暗号方式、TLS設定、製品仕様、政府・自治体の方針、クラウドの責任共有モデルを最新版の公式資料で確認します。例の値をそのまま本番へ転記してはいけません。

6　自治体特有の重要事項

個人情報と情報区分

構成図上で、個人情報を含むデータがどこに保存され、どの境界を越え、どこへ複製されるかを追えるようにします。本番データを開発・検証環境へ持ち込む経路は原則として想定せず、必要な場合は匿名化、承認、記録、削除を別途設計します。ログにも氏名、住所、識別番号、添付内容が意図せず含まれないか確認します。

ネットワークとクラウド利用

自治体のネットワーク区分、庁内端末の接続条件、インターネット利用、クラウド接続、外部サービス連携は、当該自治体の情報セキュリティポリシーと現行の国のガイドラインを確認して設計します。団体ごとに現行環境や例外手続が異なるため、過去案件の図を流用して確定してはいけません。

窓口・住民対応とアクセシビリティ

オンライン経路だけでなく、窓口代理入力、郵送受付、支援が必要な利用者、外国語利用、障害時の代替手段も対象にします。システム停止が住民サービスに与える影響を図の注記または業務継続資料へつなげます。

調達と責任分界

庁内基盤、共通認証、回線、クラウド、SaaS、運用監視、ヘルプデスクが別契約になりやすいため、管理境界を実線、別主体を点線などで示します。「クラウド事業者が全部守る」「自治体が回線を用意する」のような粗い記載では、障害時の空白が生まれます。設定、監視、一次切分け、復旧、証跡提出まで役割を分けます。

保存期間・開示・監査

文書、ログ、バックアップ、申請添付、統計データごとに保存・削除の考え方を整理し、構成図から保管先を追跡できるようにします。保存期間や公開・開示の取扱いは、条例、規則、文書管理、個人情報保護、契約条件などの最新版を所管部門と確認します。

7　重要なポイント

処理方向、形、色、線種の意味を統一し、凡例を置きます。製品名だけでなく役割名を書き、矢印には方向と経路IDを付けます。本番・検証・開発・災害対策を混在させず、管理、保守、ログ、バックアップ経路も省略しません。外部サービスの責任境界、単一障害点、容量・ライセンス・レート上限を注記します。図と台帳は同じ版で管理し、公開版と機密情報を含む管理版を分けます。

8　禁止事項

1. 目的の異なる情報を一枚へ詰め込むこと。 読めない図は正確でも使えません。
2. 矢印だけを引き、データ、方向、認証、暗号化を説明しないこと。
3. 構成図と実環境が不一致のまま承認・納品すること。 完成時点の実機確認が必要です。
4. 本番のIPアドレス、秘密情報、鍵、パスワードを一般配布版へ載せること。
5. 既存図を団体名だけ変更して流用すること。 方針、回線、運用体制は団体ごとに確認します。
6. 「セキュア」「冗長」「自動復旧」など検証不能な言葉だけで済ませること。
7. クラウド事業者と受託者、自治体の責任を曖昧にすること。
8. 設計変更後に構成図を更新しないこと。 変更管理票と同時に改訂します。
9. 将来構想と確定構成を同じ線種で描くこと。 未契約・未決定部分を明確に分けます。
10. 法令・条例・ガイドラインの名称や版を確認せず適合を断定すること。

9　自治体案件で使える図面台帳の記入例

構成図は、図面台帳と組み合わせると配布先、承認状態、機密性を管理できます。各図の右下にも図番号、版、基準日を表示し、台帳と照合します。

図面注記テンプレート

図の目的：本番環境における住民申請から職員審査までの通信と責任分界を示す。
基準日：20XX年X月X日
対象：住民端末、公開領域、アプリ領域、データ領域、庁内接続、監視
対象外：庁内LAN内部、クラウド事業者の物理設備、外部認証内部
前提：職員は自治体管理端末を使用し、管理操作は承認済み経路に限定する。
未決事項：外部連携先の本番接続情報。課題ISS-032でX月X日までに確定する。
責任分界：点線枠の外側は別契約。障害時の一次切分けは運用設計OP-INC-01による。
関連資料：通信一覧NW-FLOW-01、パラメータPAR-NW-01、試験NET-TST-01。

設計審査での問いかけ例

自治体側は、住民がアクセスする入口はどこか、本人確認が失敗したとき何が表示されるか、職員が閲覧できる情報は所属・担当で制限されるか、個人情報が国外を含むどの場所へ複製される可能性があるか、契約終了時にデータを取得・削除できるかを確認します。受託者側は、接続元の制約、名前解決、時刻同期、証明書更新、監視通知先、障害連絡、保守時間帯など自治体が提供・承認する条件を確認します。

セキュリティ審査では、インターネットからデータ領域へ直接到達できないか、管理経路が一般利用経路と分離されているか、外向き通信が必要先へ限定されるか、ログが改変されにくい保管先へ送られるか、バックアップが本番と同時に破損・削除されにくいかを図上でたどります。回答が口頭説明に依存する場合は、構成図または関連一覧へ追記します。

運用審査では、構成要素停止を誰が検知し、誰へ通知し、何をもって復旧とするかを確認します。冗長化されていても、認証、DNS、証明書、監視、運用端末などに単一障害点が残ることがあります。災害時に外部連携を止めるのか、溜めて後送するのか、住民へどう案内するのかも業務継続計画と照合します。

変更時の差分記録例

「Webサーバーを二台から三台へ変更」とだけ記録せず、変更前後の図、構成要素ID、変更理由、費用、監視、ライセンス、性能試験、バックアップ、運用手順への影響を変更票へ記載します。図では追加箇所を一時的に変更表示してレビューし、承認後の確定版では通常表記へ戻します。削除要素は台帳から消去せず、廃止日、データ消去、監視停止、契約・資産処理の証跡を履歴に残します。

完成図と現場の照合

構築完了時には、クラウドや機器の構成出力、ネットワーク設定、稼働サービス、監視対象、バックアップ対象をサンプリングまたは自動取得で照合します。図にあるが実在しないもの、実在するが図にないもの、名称・冗長数・接続方向が違うものを差分一覧へ記録します。許容差分は理由と承認を付け、解消期限がある例外は課題管理します。最終承認日と構成基準日が大きく離れた場合は、納品直前に再確認します。

10　レビュー観点と実務チェックリスト

範囲・表記

• [ ] 目的、対象、対象外、前提条件、基準日がある
• [ ] 図番号、版、作成者、承認者、改訂履歴がある
• [ ] 凡例、略語、色、線種、境界の意味が一意である
• [ ] 構成要素IDと名称が各図・各台帳で一致する
• [ ] 本番・検証・開発・災害対策の違いが分かる

業務・データ

• [ ] 住民、職員、管理者、保守員の利用経路を追える
• [ ] 個人情報・機密情報の保存先と通過経路を追える
• [ ] 外部連携の送受信、再送、エラー時の動きを確認できる
• [ ] 手作業、媒体搬送、窓口代替も必要に応じて表している
• [ ] データの複製、バックアップ、ログへの派生が分かる

セキュリティ・運用

• [ ] 信頼境界ごとにアクセス制御がある
• [ ] 認証、認可、多要素認証、特権操作の経路が分かる
• [ ] インターネット向け入口と外向き通信を確認できる
• [ ] ログ収集、監視、通知、一次対応者がつながっている
• [ ] 保守接続は通常利用と分離され、承認と記録がある
• [ ] 鍵、証明書、秘密情報の管理主体を示している

可用性・移行・契約

• [ ] 単一障害点、冗長化、バックアップ、復元経路が分かる
• [ ] 障害・災害時の切替、縮退運転、移行・切戻しを追える
• [ ] 調達範囲、別契約、自治体支給、事業者責任が分かる
• [ ] 構成要素から見積、ライセンス、試験項目へ追跡できる

11　FAQ　自治体向けシステム構成図の書き方

Q1　一枚の構成図で十分ですか

十分ではありません。意思決定用の全体図と、ネットワーク、データ連携、セキュリティ、運用・災害対策などの目的別詳細図を分けます。全体図から各詳細図へ図番号で参照できるようにします。

Q2　製品名とサービス名は書くべきですか

役割名を主にし、確定済みの製品・サービス名を属性として併記します。役割名がないと、製品変更時に設計意図が失われます。選定前は候補を確定構成のように描かないでください。

Q3　IPアドレスやポートはどこまで載せますか

全体図には原則として載せず、管理版のネットワーク構成図、通信一覧、パラメータシートで管理します。資料の配布先と機密区分に応じ、公開版では伏せます。

Q4　クラウドなら物理構成図は不要ですか

物理サーバーの図は不要な場合がありますが、リージョン、可用性区画、アカウント・契約単位、ネットワーク、マネージドサービス、保存場所、責任分界は必要です。抽象化されたサービスでも可用性と制約を説明します。

Q5　構成図は誰が承認しますか

文書管理上の責任者に加え、業務、情報政策、セキュリティ、運用、受託者の確認者を定めます。図の種類に応じたレビュー責任を承認ルート表へ記載します。

Q6　自治体向けシステム構成図を見積にどう使いますか

構成要素IDを、クラウドリソース、機器、ライセンス、回線、構築、監視、保守の見積明細へ対応させます。図にあるのに見積にない項目、見積にあるのに図にない項目を差分確認します。

Q7　セキュリティ対策をどこまで図示しますか

主要な防御、認証、権限、ログ、鍵管理、保守経路は図示します。細かな設定値はパラメータシートへ分離し、対策IDで対応付けます。

Q8　災害対策環境は同じ図に描きますか

全体図には位置関係と切替方向を示し、同期方式、切替、復帰は別図にします。通常時と災害時でDNS、認証、外部連携、運用体制がどう変わるかを確認します。

Q9　納品時に何を確認すべきですか

完成図が実環境、構成要素一覧、通信一覧、資産台帳、パラメータ、試験結果と一致するかを確認します。編集可能な原本、閲覧版、使用フォント・凡例、変更履歴も納品対象に含めます。

Q10　法令やガイドラインへの適合は図だけで証明できますか

できません。構成図は統制の配置とデータ経路を示す証拠の一部です。規程、設計値、手順、設定証跡、試験結果、運用記録と合わせて確認します。適用法令、条例、政府・自治体ガイドライン、標準仕様は、案件の基準日時点の最新版を必ず公式情報で確認してください。

まとめ

自治体向けシステム構成図の書き方で最も大切なのは、図をきれいに描くことではなく、住民サービス、データ、通信、責任、障害対応を誰でも同じように追跡できる状態にすることです。目的別の複数図、共通ID、凡例、通信一覧、構成要素一覧、責任分界を一体で管理すれば、自治体向けシステム構成図は、提案説明の絵から、設計・試験・運用・監査を支える実務資料へ変わります。