windschord IPA非機能要求グレード準拠 運用設計書生成スキル
IPA（独立行政法人情報処理推進機構）の「非機能要求グレード2018」に基づく非機能要件定義書から、運用設計書を自動生成します。デジタル庁「デジタル・ガバメント推進標準ガイドライン」第9章（運用）への準拠も組み込みます。
概要
このスキルは以下の機能を提供します:
- IPA非機能要求グレード2018（6カテゴリ、238項目）の要件値読み取り・解析
- 各カテゴリから運用設計項目へのマッピング（references/ipa_nfr_mapping_ja.md 参照）
- 不明・未記入項目のヒアリング（AskUserQuestionツール使用）
- 運用設計書の生成（assets/templates/operations_design_ipa_ja.md ベース）
- デジタル庁ガイドライン第9章（運用計画書・運用実施要領・主な運用作業）の要件を統合
入力・出力・責務
入力（Inputs）
| 入力 | 必須/任意 | 説明 |
|---|---|---|
| IPA非機能要件ドキュメント | 必須 | 記入済みの非機能要求グレードシート（ファイルパスまたはテキスト） |
| モデルシステム分類 | 必須 | 社会的影響度（「殆ど無い」「限定される」「極めて大きい」） |
| システム名 | 必須 | 対象システム・サービスの名称 |
| 出力先パス | 任意 | 運用設計書の保存先（未指定時はカレントディレクトリ） |
出力（Outputs）
| 出力 | 形式 | 説明 |
|---|---|---|
| 運用設計書 | Markdown | IPA非機能要求グレード2018・デジタル庁ガイドライン準拠の運用設計書 |
責務
このスキルが行うこと:
- IPA非機能要件の6カテゴリを読み取り、運用設計項目に変換
- 必須の空欄・不明項目のみをヒアリングし、記入済み項目は確認なしで使用（重要/任意項目は[要確認]として出力）
- デジタル庁ガイドライン第9章の運用作業一覧（21項目）を運用設計に反映
- テンプレートに基づいた運用設計書の生成
このスキルが行わないこと:
- 非機能要件の定義・策定
- 業界トレンド調査
- システム構成・アーキテクチャの設計
IPA非機能要求グレード2018の6カテゴリ
このスキルは以下の6カテゴリを処理します:
| カテゴリ | 記号 | 主な要件項目（4階層ID例） | 対応する運用設計セクション |
|---|---|---|---|
| 可用性 | A | A.1.3.2 RTO, A.1.3.1 RPO, A.2.1.1 稼働率 | SLO/SLA定義、障害対応、BCP |
| 性能・拡張性 | B | B.1.2.1 応答時間, B.1.2.3 同時接続数, B.4.1.2 HW専有 | キャパシティ管理、監視 |
| 運用・保守性 | C | C.1.2.5 バックアップ間隔, C.1.3.1-C.1.3.9 監視 | 定常運用、バックアップ、変更管理 |
| 移行性 | D | D.1.1.1 移行期限, D.3.2.1 切戻し | 運用移管計画 |
| セキュリティ | E | E.1.1.1 認証, E.11.1.1 CSIRT | セキュリティ運用 |
| システム環境・エコロジー | F | F.1.1.1 稼働環境, F.2.2.1 廃棄管理 | インフラ運用基準 |
3つのモデルシステムと稼働率レベル
IPA非機能要求グレード2018はシステムの社会的影響度に応じて3つのモデルを定義します。
モデルシステム分類
| モデル | 社会的影響度 | 適用例 |
|---|---|---|
| モデルシステム1 | 社会的影響が殆ど無いシステム | 社内限定ツール、部門内業務システム |
| モデルシステム2 | 社会的影響が限定されるシステム | 企業間取引システム、中規模業務システム |
| モデルシステム3 | 社会的影響が極めて大きいシステム | 公共インフラ、金融基幹システム、行政サービス |
稼働率レベル定義（A.2.1.1）
| レベル | 稼働率 | 月間ダウンタイム上限 | 年間ダウンタイム上限 | 適用モデル目安 |
|---|---|---|---|---|
| L0 | 95%未満 | — | — | モデルシステム1 |
| L1 | 95% | 約36時間 | 約438時間 | モデルシステム1 |
| L2 | 99% | 約7時間18分 | 約87時間36分 | モデルシステム2 |
| L3 | 99.9% | 約43分48秒 | 約8時間45分 | モデルシステム2 |
| L4 | 99.99% | 約4分22秒 | 約52分36秒 | モデルシステム3 |
| L5 | 99.999% | 約26秒 | 約5分15秒 | モデルシステム3 |
RTO・RPOのレベル別推奨値
| レベル | RTO（A.1.3.2） | RPO（A.1.3.1） | RLO（A.1.3.3） |
|---|---|---|---|
| L0 | 72時間超 | 24時間超 | — |
| L1 | 72時間以内 | 24時間以内 | データ消失許容 |
| L2 | 24時間以内 | 8時間以内 | 業務再開可能 |
| L3 | 4時間以内 | 1時間以内 | 主要機能継続 |
| L4 | 1時間以内 | 15分以内 | 全機能継続 |
| L5 | 15分以内 | 5分以内 | 無停止継続 |
Excel形式（活用シート）の扱い
IPA非機能要求グレード2018の公式形式はExcelシート（活用シート）です。
Excelシートが提供された場合の処理方針:
1. ファイルパスを確認し、Readツールでファイルを読み込む試みる
2. Excelファイルが直接読めない場合（フォールバック優先順）:
- まず「稼働率・RTO・RPO・サービス稼働時間・認証方式等の主要10項目のみ口頭で伝える」を依頼
→ 未伝達の項目はIPAモデルシステム推奨値を使い `[要確認]` 付きで出力
- 全項目が必要な場合のみ「テキスト/CSV/Markdownに変換して貼り付け」を依頼
3. テキスト形式で受け取った場合: 項目IDと値を対応付けて解析
4. グレード番号（L0-L5）が記入されている場合: 上表の値に変換して使用
重複項目（○マーク）の処理規則:
重複項目の一覧と優先ルールの詳細は references/ipa_nfr_mapping_ja.md の「重複項目（○マーク）の処理規則」セクションを参照。
重複項目で値が矛盾する場合:
→ ユーザーに確認: 「A.1.1.1（可用性カテゴリ）とC.1.1.1（運用保守性カテゴリ）の値が
異なります。どちらが正しいですか？」
確認が取れるまで当該項目を [要確認] として保留する。
ワークフロー
flowchart TD
A[1. IPA非機能要件の読み込み] --> B[2. モデルシステム確認・6カテゴリの要件値抽出]
B --> C[3. 不明・未記入項目のヒアリング]
C --> D[4. 運用設計書の生成]
D --> E[5. 整合性チェック]
E --> F[6. 運用設計書の出力]
A -.- A1[Excelシート、Markdown、<br/>テキスト入力から受け取る]
B -.- B1[4階層ID（A.X.X.X形式）で<br/>要件値を抽出・整理]
C -.- C1[AskUserQuestionで<br/>必要最小限の補完]
D -.- D1[IPA要件＋デジタル庁ガイドライン<br/>第9章を統合して生成]
E -.- E1[SLO/SLA・RTO/RPO・<br/>監視閾値の整合確認]
詳細な実行手順
ステップ1: IPA非機能要件の読み込み
スキル: IPA非機能要求グレード準拠の運用設計書を生成します。
まず、以下を確認します:
1. モデルシステム分類（社会的影響度）
2. 非機能要件ドキュメントの場所
入力形式に応じた処理:
- Excelシートのパスが指定された場合: Readツールで読み込みを試みる。読めない場合は、まず主要10項目の口頭取得を依頼し、全項目が必要な場合のみテキスト/CSV/Markdown変換を依頼（詳細は「Excel形式（活用シート）の扱い」セクション参照）
- Markdown/テキストが提供された場合: 4階層ID（A.X.X.X形式）を基に解析
- 口頭で要件を伝えられた場合: 項目名からIDに対応させて解析
モデルシステムが未指定の場合:
スキル: （AskUserQuestionツールを使用）
対象システムの社会的影響度を教えてください。
A) モデルシステム1: 社会的影響が殆ど無いシステム（社内ツール等）
B) モデルシステム2: 社会的影響が限定されるシステム（中規模業務システム等）
C) モデルシステム3: 社会的影響が極めて大きいシステム（公共インフラ・行政等）
SLAの要否確認（Step1で必ず確認）:
スキル: （AskUserQuestionツールを使用）
SLAを外部に対して正式合意として定めますか？
A) はい（外部顧客・利害関係者との正式なSLAを定める）
→ §3.1にSLO/SLA双方を定義し、付録CにSLA用語を含めます
B) いいえ、内部SLOのみ（外部SLAは設けない）
→ §3.1はSLO定義のみとし、付録CのSLA用語は除外します
C) 未定（プロジェクトで後日決定）
→ SLOのみ定義し、SLAは `[要確認: SLA設定の要否が未定]` として出力します
ステップ2: 6カテゴリの要件値抽出
読み込んだドキュメントから、各カテゴリの要件値を4階層IDで抽出・整理します。
抽出対象（詳細は references/ipa_nfr_mapping_ja.md 参照）:
A. 可用性
抽出項目（IPA 4階層ID）:
- A.1.1.1 通常時のサービス継続性（連続稼働時間） ← C.1.1.1と重複
- A.1.1.2 業務継続性（システム継続稼働要件）
- A.1.1.3 障害時のサービス継続性（縮退継続） ← C.2.1.1と重複
- A.1.2.1 サービス稼働時間（運用スケジュール）
- A.1.2.2 サービス切替え時間（フェイルオーバー時間）
- A.1.2.3 業務継続レベル（縮退時の業務継続率）
- A.1.3.1 目標復旧時点（RPO）
- A.1.3.2 目標復旧時間（RTO）
- A.1.3.3 目標復旧レベル（RLO）
- A.2.1.1 稼働率（L0-L5のレベル値）
- A.2.2.1 計画停止の可否
- A.2.2.2 計画停止の許容時間
- A.2.3.1 縮退稼働の可否
- A.2.3.2 縮退稼働のレベル
- A.2.5.3 機器更改計画（2018追加）
- A.2.6.1 ヘルプデスク要件 ← C.1.2.7と重複
- A.2.6.2 ドキュメント整備要件 ← C.1.2.1と重複
- A.3.3.1 BCP方針（事業継続計画）
- A.4.1.1 計画停止要件 ← C.3.1.1と重複
B. 性能・拡張性
抽出項目:
- B.1.1.1 通常時の業務量（リクエスト数）
- B.1.1.2 ピーク時の業務量
- B.1.2.1 通常時応答時間
- B.1.2.2 ピーク時応答時間
- B.1.2.3 同時接続数（通常時/ピーク時）
- B.2.1.1 スループット目標
- B.2.2.1 データ容量（現在/将来）
- B.3.1.1 スケールアップ/スケールアウト方式
- B.3.2.1 ピーク時対応方針
- B.4.1.1 リソース共有方式
- B.4.1.2 HWリソース専有要否（2018追加）
C. 運用・保守性
抽出項目:
- C.1.1.1 サービス提供時間 ← A.1.1.1と重複
- C.1.1.2 運用・監視時間帯
- C.1.2.1 ドキュメント管理要件 ← A.2.6.2と重複
- C.1.2.5 バックアップ取得間隔
- C.1.2.7 ヘルプデスク要件 ← A.2.6.1と重複
- C.1.3.1 ジョブ監視方式
- C.1.3.2 死活監視方式
- C.1.3.3 性能・負荷監視方式
- C.1.3.4 リソース監視方式
- C.1.3.5 障害監視方式
- C.1.3.6 ログ監視方式
- C.1.3.7 セキュリティ監視方式
- C.1.3.8 クラウド構成監視方式
- C.1.3.9 外形監視方式
- C.2.1.1 フォールバック時の継続性 ← A.1.1.3と重複
- C.2.1.2 バックアップ世代数・保管期間
- C.2.1.3 バックアップ保管場所
- C.2.1.4 リストア確認要件
- C.3.1.1 計画停止要件 ← A.4.1.1と重複
- C.3.2.1 ジョブネット定義
- C.3.2.2 ジョブエラー対応
- C.3.2.3 リラン方針
- C.4.1.1 パッチ適用方針
- C.4.1.2 パッチ適用窓
- C.4.1.3 パッチ適用後テスト範囲
- C.5.1.1 ログ取得粒度
- C.5.1.2 ログ保管期間
- C.5.1.3 ログ分析要件
- C.6.1.1 インシデント管理プロセス
- C.6.2.1 問題管理プロセス
- C.6.3.1 変更管理プロセス
- C.6.4.1 リリース管理プロセス
- C.6.5.1 構成管理プロセス
- C.6.6.1 キャパシティ管理プロセス
- C.6.7.1 サービスレベル管理プロセス
D. 移行性
抽出項目:
- D.1.1.1 移行期限
- D.1.1.2 移行方式（ビッグバン/段階的）
- D.1.1.3 移行中の許容停止時間
- D.2.1.1 移行対象データ量・種類
- D.2.1.2 データクレンジング要否
- D.3.1.1 並行稼働期間・方式
- D.3.2.1 切戻し手順
E. セキュリティ
抽出項目:
- E.1.1.1 認証方式（パスワード/MFA/SSO、GDPR対応含む）
- E.1.1.2 多要素認証（MFA）要否
- E.1.1.3 認可方式（RBAC等）
- E.1.1.4 アクセスログ取得要件
- E.2.1.1 通信暗号化（TLS版等）
- E.2.1.2 保存データ暗号化
- E.3.1.1 脆弱性診断の頻度・種別
- E.3.1.2 ペネトレーションテスト要否
- E.4.1.1 監査ログ取得要件
- E.4.1.2 監査ログ保管期間・改ざん防止
- E.5.1.1 適用法規制・認証（個人情報保護法、GDPR、PCI DSS等）
- E.11.1.1 CSIRTセキュリティインシデント対応体制（2018追加）
F. システム環境・エコロジー
抽出項目:
- F.1.1.1 稼働環境（データセンター/クラウド）
- F.1.1.2 電源・ネットワーク冗長化
- F.2.1.1 省エネ目標（PUE等）
- F.2.2.1 ハードウェア廃棄・リサイクル方針
抽出結果の整理:
スキル: 非機能要件から以下の値を抽出しました。
【可用性（A）】
- モデルシステム: [モデルシステム1/2/3]
- 稼働率(A.2.1.1): [レベル][値]%（例: L3 = 99.9%）
- RTO(A.1.3.2): [抽出値]
- RPO(A.1.3.1): [抽出値]
- RLO(A.1.3.3): [抽出値 or 未定義]
- サービス稼働時間(A.1.2.1): [抽出値]
- サービス切替え時間(A.1.2.2): [抽出値]
- 業務継続レベル(A.1.2.3): [抽出値]
【性能・拡張性（B）】
- 応答時間(B.1.2.1): [抽出値]
- 同時接続数(B.1.2.3): [抽出値]
- HWリソース専有(B.4.1.2): [抽出値]
【運用・保守性（C）】
- 監視時間帯(C.1.1.2): [抽出値]
- バックアップ間隔(C.1.2.5): [抽出値]
- 監視方式(C.1.3.1-9): [抽出値]
- ログ保管期間(C.5.1.2): [抽出値]
- ITIL管理プロセス(C.6.x): [抽出値]
【移行性（D）】
- 移行期限(D.1.1.1): [抽出値]
【セキュリティ（E）】
- 認証方式(E.1.1.1): [抽出値]
- CSIRT体制(E.11.1.1): [抽出値 or 未定義]
【システム環境（F）】
- 稼働環境(F.1.1.1): [抽出値]
重複項目の整合確認: [矛盾あり/なし]
不明または未記入の項目: [リスト]
ステップ3: 不明・未記入項目のヒアリング
未記入・不明な項目がある場合のみヒアリングします。
【重要】記入済みの要件値は確認なしで使用すること。ヒアリングは必要最小限に留める。
スキル: （AskUserQuestionツールを使用）
以下の項目が非機能要件に記載されていませんでした。
運用設計書に反映するために確認させてください。
Q1: 監視ツールのカテゴリを教えてください（具体的なツール名があれば括弧内に記入）
A) オープンソース系（Prometheus/Grafana 等）
B) SaaS型（クラウドベンダー提供以外の監視SaaS）
C) クラウドネイティブ（クラウドベンダー標準の監視機能）
D) オンプレ自前構築
E) 未定
Q2: インシデント通知の方式を教えてください
A) チャットツール連携（ツール名: ______）
B) メールのみ
C) 電話・オンコールシステム
D) 未定
[未記入項目の数に応じて追加]
ヒアリング対象の優先順位:
必須（ヒアリングなしでは生成不可）:
- モデルシステム分類（未指定の場合）
- サービス稼働時間（A.1.2.1 が未記入の場合）
- 稼働率（A.2.1.1 が未記入の場合）
重要（品質向上のため確認）:
- 監視ツール（C.1.3.x が未記入の場合）
- インシデント通知方式
任意（未定の場合は[要確認]として出力）:
- 移行スケジュールの詳細
- CSIRT体制の詳細（E.11.1.1 が未記入の場合）
ステップ4: 運用設計書の生成
assets/templates/operations_design_ipa_ja.md を Readツールで読み込み、抽出した要件値を埋め込んで運用設計書を生成します。
生成ルール:
| 状況 | 処理 |
|---|---|
| 要件値が明示されている | その値をそのまま使用 |
| グレードレベル（L0-L5）で指定されている | 上記変換表の具体的な値を記載し、根拠（IPA要件ID・レベル）を注記 |
| 未記入でヒアリング回答あり | ヒアリング回答を使用 |
| 未記入かつ未定 | `[要確認: 非機能要件X.X.X.Xが未定義]` と記載 |
デジタル庁ガイドライン要件の統合:
生成時に以下のデジタル庁要件を運用設計書に組み込む:
| デジタル庁要件 | 反映先セクション |
|---|---|
| 運用計画書（作業概要・体制・スケジュール・成果物・形態・SL） | §4 運用体制 |
| 9種監視（ジョブ・死活・性能・稼働状況・セキュリティ・防犯・データ処理・バックアップ・障害復旧） | §5 監視 |
| 問題管理・変更管理・リリース管理（台帳含む） | §8 変更管理 |
| 大規模災害等対応訓練（年1回）・情報漏洩対応訓練（年1回） | §10 BCP/DR |
| 運用改善プロセス・KPI計測 | §9 定常運用 |
| CSIRT体制・セキュリティインシデント対応訓練 | §13 セキュリティ運用 |
| アカウント管理（払出・削除・棚卸） | §13 セキュリティ運用 |
スキル: 非機能要件から運用設計書を生成しています...
[1/6] A（可用性）→ SLO/SLA・障害対応・BCP/DRセクション
[2/6] B（性能・拡張性）→ キャパシティ管理・監視セクション
[3/6] C（運用・保守性）→ 定常運用・バックアップ・変更管理セクション
C.1.3.1-C.1.3.9（9種監視）→ §5 監視
C.6.1.1-C.6.7.1（ITILプロセス）→ §8 変更管理
[4/6] D（移行性）→ 運用移管計画セクション
[5/6] E（セキュリティ）→ セキュリティ運用セクション
E.11.1.1（CSIRT）→ §13 セキュリティ運用
[6/6] F（システム環境）→ インフラ運用基準セクション
＋ デジタル庁ガイドライン第9章 → 全セクションに統合
生成完了: [出力ファイルパス]
ステップ5: 整合性チェック
生成した運用設計書の整合性を自動チェックします。
チェック項目:
✅ 稼働率とRTO/RPOの整合（IPA レベル対応表に基づく）
→ L3（99.9%）の場合、RTO=4時間以内、RPO=1時間以内であることを確認
✅ バックアップ取得間隔（C.1.2.5）とRPO（A.1.3.1）の整合
→ バックアップ間隔 ≤ RPO であることを確認
✅ 監視インターバルとRTO（A.1.3.2）の整合
→ （監視間隔 + §6.2「一次確認・重大度判定」の所要時間）≤ RTO となることを確認
→ 目安として監視間隔はRTOの1/10以下から設計し、インシデント対応フロー（§6.2）の
一次確認時間との合算でRTOを超過しないか検証する
✅ オンコール体制とサービス稼働時間（A.1.2.1）の整合
→ 24時間365日稼働の場合、オンコール体制が定義されていることを確認
✅ パッチ適用窓（C.4.1.2）と計画停止（A.4.1.1/C.3.1.1）の整合
→ 計画停止許容の場合、パッチ適用窓が設定されていることを確認
✅ CSIRT体制（E.11.1.1）とセキュリティ監視（C.1.3.7）の整合
→ CSIRT体制が定義されている場合、監視・通知フローが整合していることを確認
✅ 重複項目（○マーク）の値一致確認
→ A.1.1.1＝C.1.1.1、A.4.1.1＝C.3.1.1 等の値が一致していることを確認
問題が検出された場合:
スキル: 整合性チェックで以下の問題が検出されました。
⚠️ 問題1: RPO（A.1.3.1）とバックアップ間隔（C.1.2.5）の不整合
- RPO要件(A.1.3.1): 1時間以内
- バックアップ間隔(C.1.2.5): 日次（24時間毎）
- 影響: 最大23時間のデータ損失が発生する可能性があります
対応案:
A) バックアップ間隔を1時間以内に変更する
B) RPO要件を「24時間以内」に修正する
C) そのまま出力し、[要調整]注記を付ける
どの対応を希望しますか？
ステップ6: 運用設計書の出力
整合性チェック後、運用設計書を出力します。
スキル: 運用設計書を生成しました。
【生成ファイル】
- ファイル: [システム名]-operations-design-[YYYY-MM-DD].md
- セクション数: [N]セクション
- [要確認]マーカー: [N]箇所（非機能要件が未定義の項目）
- デジタル庁ガイドライン準拠: 第9章（運用）統合済み
【サマリー】
- モデルシステム: [分類]
- 稼働率目標(A.2.1.1): [レベル][値]%
- RTO(A.1.3.2): [値] / RPO(A.1.3.1): [値] / RLO(A.1.3.3): [値]
- 監視体制(C.1.3.x): [採用する監視種別]
- バックアップ(C.1.2.5): [値]
- CSIRT体制(E.11.1.1): [あり/なし/要確認]
- セキュリティ: [主要設定]
[要確認]マーカー一覧付録の生成:
[要確認]マーカーが1件以上ある場合は、運用設計書の末尾に付録D（未確認事項一覧）を必ず生成すること:
### 付録D: 未確認事項一覧（[要確認]マーカー集計）
後工程のレビューで確認漏れを防ぐため、本書中の[要確認]項目を集約しています。
| # | 箇所（セクション） | IPA要件ID | 内容 | 確認担当 | 確認期限 |
|---|-----------------|----------|------|---------|---------|
| 1 | §X.X [セクション名] | X.X.X.X | [未定義の内容] | [担当者] | [YYYY-MM-DD] |
※ 確認完了後は本表から削除し、対象箇所の[要確認]マーカーを実際の値に更新してください。
SLA条件付き出力:
Step1でSLA要否の確認を実施済みの場合:
SLA「あり」の場合:
→ 付録C（用語集）にSLA定義を含める
→ §3.1見出しを「稼働率目標（SLO/SLA）」とし、SLO・SLA双方の値を記載
SLA「なし」の場合:
→ 付録C（用語集）からSLA用語を除外する
→ §3.1見出しを「稼働率目標（SLO）」とし、SLOのみ記載
SLA「未定」の場合:
→ §3.1はSLOのみ記載し、SLAは `[要確認: SLA設定の要否が未定]` として追記
→ 付録C（用語集）のSLA行はそのまま残し、`[要確認]` を維持する（削除しない）
制約事項
実施しないこと
- 要件値の変更: 明示された非機能要件の値は変更しない（整合性問題がある場合はユーザーに確認）
- 推測による補完: 未記入項目を推測で埋めない（
[要確認: 非機能要件X.X.X.Xが未定義]として出力） - 業界調査: 業界トレンドの調査は行わない（operations-designスキルを使用すること）
情報不足時の対応
必須項目（モデルシステム分類・稼働率・稼働時間）が未記入の場合:
→ ヒアリングを実施（スキップ不可）
重要項目（RTO・RPO・バックアップ間隔）が未記入の場合:
→ `[要確認: 非機能要件X.X.X.Xが未定義]` として出力し、後で補完できるようにする
任意項目（移行スケジュール詳細・CSIRT詳細等）が未記入の場合:
→ `[要確認: 非機能要件X.X.X.Xが未定義]` として出力し、値は補完しない
リソース
references/
ipa_nfr_mapping_ja.md: IPA非機能要求グレード2018の6カテゴリ → 運用設計項目 詳細マッピング表（4階層ID対応）
assets/templates/
operations_design_ipa_ja.md: IPA非機能要求グレード2018・デジタル庁ガイドライン準拠の運用設計書テンプレート
準拠規格
- IPA 非機能要求グレード 2018（独立行政法人情報処理推進機構）
- デジタル・ガバメント推進標準ガイドライン 第9章（デジタル庁）