自治体向けパラメータシートの書き方・作り方

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

はじめに　要約と結論

自治体向けパラメータシートは、サーバー、クラウド、ネットワーク、データベース、ミドルウェア、アプリケーション、監視、バックアップ、認証、外部連携に適用する設定値を、設計根拠、環境差分、変更履歴、確認証跡とともに管理する文書です。設定値を並べた表ではなく、「なぜこの値か」「どこに適用したか」「誰が確認したか」「変更時に何へ影響するか」を説明できる構成管理の正本です。

結論は、一つのパラメータに一意なIDを付け、設計上の標準値、環境ごとの実値、秘密情報の参照先、適用結果、検証結果を分離することです。自治体向けパラメータシートの書き方では、パスワードや秘密鍵をシートへ直接記載せず、値の管理方式と安全な保管先の識別子だけを示します。また、手入力で実環境とずれないよう、可能な範囲で設定エクスポートや構成管理ツールと照合します。

想定読者

想定読者は、自治体の情報政策部門、情報セキュリティ担当、システム管理者、運用・監査担当、受託事業者の基盤、ネットワーク、クラウド、データベース、アプリケーション、監視、構築、試験、保守担当です。業務主管課は全値を読む必要はありませんが、保存期間、受付時間、通知、業務上限など業務パラメータを確認します。

1　パラメータシートの章立て

1. 文書情報、適用システム、版、基準日、承認
2. 目的、対象範囲、対象外
3. 環境、構成要素、命名、単位、状態の定義
4. パラメータ共通一覧
5. 環境別設定値
6. ネットワーク・通信設定
7. OS・クラウド・コンテナ設定
8. ミドルウェア・データベース設定
9. アプリケーション・業務設定
10. 認証・認可・セキュリティ設定
11. ログ・監視・バックアップ設定
12. 外部連携・バッチ・通知設定
13. 秘密情報・証明書の管理情報
14. 適用、検証、差分、ロールバック
15. 変更履歴、レビュー、承認、棚卸し

一つの巨大な表にまとめず、対象別シートへ分けます。ただし共通項目、ID、環境名、構成要素名は統一し、索引シートから各対象へ移動できるようにします。

2　書き方・作り方の手順

2.1　構成要素を確定する

システム構成図と構成要素一覧を入力にし、Web、API、DB、ネットワーク、監視、バックアップなどへ構成要素IDを付けます。パラメータ行は必ず構成要素IDへひも付けます。存在しない機器や廃止済み環境の行を残さないよう、構成図と同時に更新します。

2.2　設計値と実値を分ける

設計値は、要件や詳細設計で決めた推奨・必須の値です。実値は、開発、検証、本番、災害対策など各環境に適用された値です。違いがある場合は、差分理由、承認、期限を記載します。「本番は後で設定」などの未確定値には、責任者と確定期限を付けます。

2.3　値の意味と根拠を書く

パラメータ名だけでは、担当交代後に変更判断ができません。目的、許容範囲、単位、初期値、選択肢、依存関係、変更影響、根拠設計IDを記載します。「timeout=30」だけでなく、「外部API応答待ち、30秒、再試行2回、住民画面の総待ち時間要件から設定」のように書きます。

2.4　秘密情報を分離する

パスワード、秘密鍵、APIキー、トークン、個人情報をシートへ記載しません。秘密管理サービスや保管庫の参照ID、管理責任者、ローテーション期限、利用主体のみを記載します。参照先へのアクセス権は、パラメータシートの閲覧権限と分けます。

2.5　適用と検証を記録する

値を決めただけでは完了ではありません。適用者、適用日時、対象環境、変更申請ID、適用方法、検証コマンドまたは画面、期待値、結果、確認者、証跡、ロールバック結果を記録します。自動化した場合もパイプラインやジョブの実行IDを残します。

2.6　実環境との差分を定期確認する

設定エクスポート、クラウド設定一覧、構成管理ツール、監視情報などとパラメータシートを照合します。許可された差分、未承認差分、ツールが生成する値を区別し、差分検出時は変更管理またはインシデント管理へつなげます。

3　共通項目テンプレート

日付はYYYY-MM-DD、時刻はタイムゾーンを含むなど表記ルールを決めます。容量単位はMBとMiB、時間は秒とミリ秒を混同しないよう列の単位を固定します。真偽値は「有・無」「true・false」等を統一します。

4　環境差分表の具体例

この数値は説明用であり、本番の推奨値ではありません。実際は要件、容量計画、脅威、運用時間、製品公式資料、自治体の方針を確認して決定します。

5　分類別の書き方と重要項目

5.1　ネットワーク・通信

管理対象は、ネットワーク・サブネット識別、ルート、DNS、NTP、プロキシ、ロードバランサ、FW・WAF、VPN・閉域接続、送信元・先、プロトコル、ポート、タイムアウト、ヘルスチェックです。通信経路IDを構成図・通信一覧と共通化します。

IPアドレスや内部DNS名は機微情報になり得るため、詳細版の閲覧権限を限定します。FWルールは「any-any」を安易に設定せず、用途、方向、期間、申請IDを記録します。臨時開放には自動失効または削除期限を設けます。

5.2　OS・クラウド・仮想化・コンテナ

OS版、タイムゾーン、時刻同期、更新方針、不要サービス、監査、ファイル権限、リソース制限を管理します。クラウドでは、アカウント・プロジェクト、リージョン、可用性区画、タグ、暗号化、公開設定、サービス制限、削除保護、予算アラートを対象にします。

コンテナでは、イメージ参照、実行ユーザー、CPU・メモリ要求と上限、ヘルスチェック、再起動、環境変数、マウント、ネットワーク、ログを管理します。イメージの可変タグだけに依存せず、再現できる識別情報を残します。

5.3　ミドルウェア・Web・API

製品・版、ワーカー、接続数、キュー、タイムアウト、要求サイズ、アップロード上限、TLS、セッション、キャッシュを管理し、各層の上限を整合させます。タイムアウトは呼出順に総時間を計算し、再試行の回数、間隔、対象処理を設計と対応付けます。

5.4　データベース・ストレージ

文字コード、照合、接続、プール、タイムアウト、メモリ、ログ、監査、バックアップ、レプリケーション、索引保守、統計、容量、自動拡張、暗号化を管理します。DBユーザーごとの用途、権限、認証方式、秘密参照IDを記載します。

ストレージでは、公開可否、暗号化、版管理、保持、ライフサイクル、削除保護、アクセスログ、容量警告を管理します。個人情報を含む領域の公開設定は、個別オブジェクトとコンテナ双方を確認します。

5.5　アプリケーション・業務

受付開始・終了、年度、上限件数、添付形式・容量、通知テンプレート、機能フラグ、コード表、問い合わせ先、メンテナンス表示などを対象にします。業務主管課の承認が必要な値を区別し、技術担当だけで変更しません。

設定値をソースへ埋め込まず、環境別設定または管理画面で制御する場合も、誰が変更できるか、変更が即時反映か再起動か、履歴が残るかを記載します。機能フラグには所有者、開始・終了条件、削除期限を付けます。

5.6　認証・認可・セキュリティ

認証先、トークン有効期間、セッション、再認証、多要素認証、アカウントロック、権限ロール、管理者制御、暗号化、証明書、鍵ローテーション、脆弱性スキャン、外向き通信制限を管理します。

数値や方式は、自治体の情報セキュリティポリシー、採用製品の公式資料、基準日時点の政府等の最新ガイドラインを確認します。古い暗号方式や過去案件の設定を無条件で流用しません。例外設定にはリスク評価、代替策、承認、解消期限が必要です。

5.7　ログ・監視・通知

ログレベル、出力先、ローテーション、保持、マスキング、相関ID、監査イベントを管理します。監視は、メトリクス、閾値、継続時間、評価回数、通知先、重要度、抑止時間、エスカレーションを一組で記載します。

閾値は根拠のない一律80%などにせず、増加速度、対応可能時間、容量追加所要時間を考慮します。通知先には個人アドレスだけでなく、役割・当番・連絡網を使い、人事異動時に漏れなく変更します。

5.8　バックアップ・災害対策

対象、方式、時刻、頻度、世代、保存先、暗号化、削除保護、整合性、復元試験を管理します。災害対策では同期、切替、DNS、外部連携、バッチ、復帰を対象にします。保持期間は、業務要件、文書・データ保存、個人情報の削除、契約、費用を調整して決めます。

5.9　外部連携・バッチ・通知

接続先、認証方式、証明書、タイムアウト、再試行、レート制限、ファイル名、授受場所、文字コード、実行時刻、休日、終了コード、再実行点を管理します。通知サービスでは送信元、テンプレート、URL、失敗判定、再送、抑止を管理します。

外部接続先の本番情報が納期直前に確定する場合でも、仮値を本番値のように残しません。状態を「仮」「確定」「適用済」「検証済」に分け、確定責任者と期限を付けます。

6　秘密情報・証明書管理のテンプレート

秘密情報を伏字で貼り付けても、元データが表計算ファイルの履歴、コメント、旧版、共有キャッシュに残ることがあります。最初から実値を入力しない運用が必要です。証明書は、主体、用途、発行者、有効期限、更新責任、秘密鍵保管、チェーン、更新試験を管理します。

7　適用・検証・ロールバック手順

パラメータ変更は、次の流れで行います。

1. 変更理由と対象パラメータIDを起票する。
2. 依存、停止、セキュリティ、費用、住民影響を評価する。
3. 変更前値と設定エクスポートを安全に保存する。
4. 検証環境で適用し、機能・性能・監視・ログを確認する。
5. 承認された時間帯に本番へ適用する。
6. 設定値、サービス状態、主要業務、外部連携を確認する。
7. 異常時は定義済み条件でロールバックする。
8. 実値、証跡、変更履歴、関連手順を更新する。

適用手順には、前提、権限、コマンドまたは画面、期待応答、確認方法を記載します。パラメータシートへ危険なコマンドを無説明で貼らず、構築・変更手順書を参照します。変更が再起動を伴うか、複数ノードへ順次適用できるか、反映遅延があるかを確認します。

8　構成管理と自動化

構成管理コードを使う場合、コードを実装上の正本、パラメータシートを説明、承認、環境差分、秘密参照、証跡の索引にできます。項目ごとに正本を決め、二重に手入力しません。自動取得値には取得日時、対象、API版を付け、生成値・一時値と固定値を区別します。ドリフト検知後は、緊急対応や正当な変更でないか確認します。

9　自治体特有の観点

組織・年度変更

課名、窓口、通知先、年度、受付期間、休日、帳票文言は定期的に変わります。業務パラメータを抽出し、主管課が安全に確認できる一覧と承認期限を用意します。年度切替は事前設定、切替時刻、旧年度処理、戻し方を試験します。

ネットワーク・共通基盤

庁内ネットワーク、共通認証、端末、名前解決、時刻、プロキシ、メール等は別管理主体の場合があります。自治体側・受託者側の設定値、変更申請、試験責任を分け、相互の問い合わせ番号を残します。

情報公開と機密管理

パラメータシートには、セキュリティ構成、内部アドレス、アカウント識別などが含まれます。公開用成果物と管理用詳細版を分け、閲覧、持出し、複製、納品、廃棄を管理します。一方で機密指定を理由に、自治体の必要な運用・監査情報を納品しないことも避けます。

10　重要なポイント

• 設定キーだけでなく、目的、根拠、単位、許容範囲を書く。
• 設計値、初期値、現行実値、変更後予定値を混同しない。
• 開発、検証、本番、災害対策の列を固定し、差分理由を残す。
• 構成図、詳細設計、試験、運用手順と共通IDで結ぶ。
• 秘密情報の実値を記載せず、安全な保管先の参照だけを扱う。
• 手動変更にも変更ID、適用者、確認者、証跡を付ける。
• 製品の既定値に依存する場合も、版と採用理由を記録する。
• 設定値の競合、上書き順、再起動、反映時間を確認する。
• 納品前と定期的な棚卸しで実環境との差分を確認する。

11　禁止事項

1. パスワード、秘密鍵、APIキー、トークンを直接記載すること。
2. 実在する個人情報や本番データを例示に使うこと。
3. 単位、型、環境、対象構成要素がない数値を記載すること。
4. 開発値をコピーして本番値として未確認で適用すること。
5. 製品の既定値を確認せず「デフォルト」とだけ書くこと。
6. 承認前に値を変更し、履歴を後付けすること。
7. 本番画面を手動変更してシートや構成管理コードを更新しないこと。
8. 臨時のFW開放、デバッグログ、管理者権限を無期限で残すこと。
9. 証明書期限、ライセンス期限、秘密情報の交換期限を管理しないこと。
10. 値の変更影響、試験、ロールバックを確認しないこと。
11. 法令、条例、方針、ガイドラインの最新版を確認せず適合を断定すること。

12　パラメータの記入例と統制例

タイムアウト設定の完成形例

パラメータID：PAR-API-031
構成要素：CMP-API-02 外部連携クライアント
名称：接続先応答タイムアウト
設定場所：外部連携設定／responseTimeout
型・単位：整数・秒
許容値：1から60
設計値：10
根拠：画面応答要件と接続先の通常応答実績。詳細設計DD-EXT-12参照。
依存：再試行二回、待機一秒・三秒。画面側総待ち時間は三十秒未満。
異常時：結果不明として照会処理へ移し、即時の新規要求を重複送信しない。
変更影響：住民画面応答、同時接続、接続先負荷、監視閾値。
検証：遅延五秒は成功、十一秒はタイムアウトし保留キューへ一件登録される。

監視閾値の完成形例

容量警告を一律の割合で設定するのではなく、現在使用量、日次増加量、容量追加に要する日数から逆算します。例えば七十パーセントで注意、八十パーセントで担当通知、九十パーセントで責任者へ上申とし、短時間の一時増加を誤検知しない継続時間を定めます。監視画面に表示するだけではなく、夜間・休日の通知先、通知失敗時の代替、対応手順IDを記載します。

証明書更新の統制例

証明書台帳には、対象FQDN、用途、発行者、証明書識別子、有効開始・終了、秘密鍵保管先、更新責任者、更新開始期限、対象ロードバランサ・API・連携先、疎通試験を記載します。期限通知は一つのメールだけに依存せず、複数時点で監視します。更新時はチェーン、秘密鍵との組合せ、全ノードへの反映、再起動要否、相手先の証明書固定設定を確認します。旧証明書と秘密鍵は規程に従って失効・削除します。

業務パラメータ変更の例

受付終了日時を変更する場合、表示文言だけでなく、新規作成、下書き保存、提出、職員代理入力、外部連携、予約バッチへ同じ基準が適用されるかを確認します。締切直前に操作を開始した住民の扱い、保守停止、時刻ずれ、再提出も決めます。主管課の承認を変更IDへ添付し、変更前後の画面、DB値、監査ログを検証します。

本番反映の相互確認

作業者が設定し、別の確認者が対象、値、環境、変更ID、全ノードへの反映を照合します。画面表示の目視だけでなく、可能なら設定エクスポートやAPI取得結果を証跡とします。クラウド管理画面で似た名称の開発環境を誤操作しないよう、アカウント、色、タグ、承認済み作業対象を確認します。緊急変更でも、実施後の相互確認と正式記録の期限を省略しません。

納品時の差分一覧例

納品時点で暫定値が残る場合、空欄や「TBD」のまま渡さず、パラメータID、暫定値、確定条件、責任者、期限、影響、代替策を一覧化します。自治体または次期運用者が値を取得できない事業者内部の参照先は、移管可能な保存先へ置き換えます。設定を復元する順序、依存する証明書・秘密情報、取得に必要な権限も引継ぎます。

13　実務チェックリスト

作成時

• [ ] 構成要素IDとパラメータIDが一意である
• [ ] 目的、型、単位、許容値、設計値、根拠がある
• [ ] 環境別実値と差分理由がある
• [ ] 依存関係、停止、再起動、反映時間を記載した
• [ ] 秘密情報の実値を記載していない

適用前

• [ ] 変更申請と承認がある
• [ ] 変更前値と設定証跡を取得した
• [ ] 検証環境で試験した
• [ ] 監視、連絡、作業時間、ロールバックを準備した
• [ ] 自治体・別事業者の作業分担を確認した

適用後

• [ ] 実値とサービス状態を確認した
• [ ] 主要機能、外部連携、ログ、監視を確認した
• [ ] 全ノード・全領域へ適用された
• [ ] パラメータシートと構成管理コードを更新した
• [ ] 適用者、確認者、日時、証跡を残した

定期棚卸し・納品

• [ ] 実環境とのドリフトを確認した
• [ ] 臨時設定と期限切れ例外を除去した
• [ ] 証明書、秘密情報、ライセンスの期限を確認した
• [ ] 廃止環境・要員の権限・通知先を削除した
• [ ] 編集可能形式、機密区分、保管・引継ぎ手順がある

14　FAQ　自治体向けパラメータシートの作り方

Q1　詳細設計書との違いは何ですか

詳細設計書は設定の目的、処理、制約、設計判断を説明し、パラメータシートは環境ごとの実値、適用、確認、変更を管理します。設計IDとパラメータIDで対応付けます。

Q2　すべての設定値を手入力すべきですか

いいえ。自動取得・構成管理できる値は機械的に生成し、手入力は根拠、承認、例外、業務値などへ絞ります。生成方法、取得日時、対象版を記録します。

Q3　パスワードを伏字で載せてもよいですか

原則として実値を一度も入力しません。伏字表示でも履歴や旧版に実値が残る恐れがあります。秘密管理先の参照ID、責任者、更新期限だけを記載します。

Q4　開発・検証・本番で同じ値なら列を省略できますか

省略せず「同一」または実値を明示する方が、適用漏れを発見しやすくなります。共通値の継承を使う場合は、継承元と上書き規則を定義します。

Q5　クラウドの管理画面があればシートは不要ですか

不要ではありません。管理画面は現行値を示しても、設計根拠、承認、環境差分、関連試験、変更履歴を十分に説明できない場合があります。エクスポートとシートを役割分担させます。

Q6　製品のデフォルト値はどう記載しますか

「デフォルト」だけでなく、製品名、版、具体値、確認元、採用理由を記載します。アップデートで既定値が変わる可能性があるため、更新時に再確認します。

Q7　パラメータ変更はどこまで試験しますか

直接機能だけでなく、依存処理、性能、監視、ログ、バックアップ、外部連携、ロールバックをリスクに応じて確認します。変更管理票に試験範囲と省略理由を残します。

Q8　業務パラメータは誰が承認しますか

受付期間、上限、通知文、制度コードなどは主管課が意味を確認し、技術担当が形式・適用を確認します。費用、情報セキュリティ、個人情報へ影響する場合は関係部門も加えます。

Q9　棚卸しはいつ行いますか

リリース前後、定期保守、年度切替、障害・変更後、事業者交代、納品前を契機にします。セキュリティ上重要な設定や期限物は、より短い周期で監視します。

Q10　完成の条件は何ですか

対象構成要素を網羅し、未確定値が正式に管理され、秘密情報を含まず、実環境と一致し、適用・検証証跡があり、自治体と受託者の定めた承認を得た状態です。

まとめ

自治体向けパラメータシートの書き方で重要なのは、数値を埋めることではなく、設定の意味、根拠、環境差分、秘密管理、適用、検証、変更を追跡できることです。自治体向けパラメータシートを構成図、詳細設計、変更、試験、運用と共通IDで結び、実環境との差分を定期確認すれば、安全な構築と長期的な保守・事業者引継ぎを支える資料になります。