Home
Get Started
実践ガイド
外部仕様設計
バッチ処理仕様設計
UAC 仕様設計
データ仕様設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
インフラ システム環境・エコロジー設計
システムインフラの環境制約と持続可能性を考慮し、法令遵守と効率的運用を実現するための設計ガイドです。
🎯 概要
- 目的: システムが稼働する物理的・論理的な環境の制約、特性、および環境負荷への配慮を明確にし、法令遵守と持続可能性を考慮した効率的なインフラ運用を実現する
- スコープ: システム制約・前提条件、システム特性(ユーザー数、拠点数、地域的広がり等)、適合規格、機材設置環境条件をカバーする。個別のサーバー・ネットワーク機器の詳細設計は対象外
- 推奨する実施タイミング: インフラ構築設計の初期段階、物理・クラウド環境の選定時
- 関連するステークホルダー: インフラチーム、プロジェクトマネージャー、法務・コンプライアンス部門、環境管理部門、運用チーム、調達部門
📥 重要な前提知識・インプット
- 前提知識:
- データセンターの物理環境要件(耐震性、電源供給、空調、セキュリティ設備)
- クラウドサービスの地域・リージョン特性、データ主権の概念
- 法令・規制(個人情報保護法、J-SOX、業界特有の規制)
- 製品安全規格(UL、CE等)、環境保護規格(RoHS、エネルギースター等)
- システムの地域分散設計と冗長性の基本概念
- 容量計画・キャパシティプランニングの基礎
- インプット:
- 非機能要件定義書(可用性、拡張性、保守性等の要件)
- 適用される法令・規制の一覧と要求事項
- 既存インフラ環境の構成情報(オンプレミス、クラウド、ハイブリッド)
- 想定ユーザー数、同時接続数、拠点数、地域的広がり
- 特定製品・技術の指定有無と選定理由
- データセンター選定基準(物理環境要件)
- 社内セキュリティポリシー、運用ポリシー
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]インフラ システム環境・エコロジー設計書
- 必須要素: システム環境・エコロジー仕様書(システム制約・前提条件、システム特性、適合規格、機材設置環境条件)、環境要件チェックリスト、リスク管理表
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| 法令・規制の網羅性 | 適用される全ての法令・規制が特定され、遵守方法が明確か |
| システム特性の妥当性 | ユーザー数、拠点数等の想定が根拠を持って設定されているか |
| 適合規格の確認 | 必要な製品安全規格・環境保護規格への適合が確認されているか |
| 物理環境条件の充足 | データセンター要件(耐震性、スペース等)が満たされているか |
| 環境負荷への配慮 | 省電力化、リソース効率化等の環境配慮が考慮されているか |
👁️🗨️ レビュー観点:
- 法令・規制遵守: 個人情報保護法、J-SOX、データ主権等の要求事項が満たされているか
- 環境制約の妥当性: 既存インフラとの整合性、運用プロセスとの整合性が確保されているか
- 容量計画の妥当性: ユーザー数、拠点数等の想定に基づく適切なキャパシティが確保されているか
- リスク管理: 環境起因のリスク(災害、法令違反等)が特定され、対策が講じられているか
- 持続可能性: 環境負荷への配慮、リソース効率化の方針が明確か
🧪成果物のサンプル
# システム環境・エコロジー(System Environment & Ecology)
## システム環境・エコロジーの基本方針
システムが稼働する環境に関する制約、特性、および環境負荷への配慮を明確にし、持続可能で効率的なインフラ運用を実現するための戦略を以下に示す。
### 環境制約・前提条件方針
- **法令・規制遵守**: 適用される全ての法令、業界ガイドライン、社内規程を遵守したインフラ構築・運用を行う
- **既存環境との整合性**: 既存のインフラ環境や運用プロセスとの整合性を確保し、スムーズな導入・運用を目指す
### システム特性への対応方針
- **地域分散と冗長性**: ユーザーの地域的広がりや拠点数に応じて、適切な地域分散と冗長構成を設計
- **特定の製品・技術への対応**: ユーザー指定の製品や技術がある場合は、その特性を理解し、サポート体制や互換性を考慮したインフラ設計を行う
### 適合規格への対応方針
- **製品安全・環境規格の確認**: 使用するハードウェアやミドルウェアが、必要な製品安全規格や環境保護規格に適合していることを確認
- **クラウドプロバイダーの認証活用**: クラウドサービスを利用する場合は、クラウドプロバイダーが取得している各種認証(ISO27001、SOCなど)を活用し、要件を満たす
### 機材設置環境条件方針
- **データセンター選定基準**: 物理的な設置環境が必要な場合は、耐震性、セキュリティ、電源供給などの条件を満たすデータセンターを選定
- **リソース効率化**: 仮想化技術やクラウドサービスを最大限活用し、物理リソースの利用効率を高め、省電力化を推進
---
## システム環境・エコロジー要件の実現方式
### F1. システム制約/前提条件 (System Constraints/Prerequisites)
#### F1.1 構築時の制約条件 (Construction Constraints)
##### F1.1.1 構築時の制約条件
- **要件**: 以下の社内基準、法令、ガイドラインに準拠したインフラ構築を行うこと
- 社内情報セキュリティポリシー
- ISO/IEC 27001 (ISMS) 認証取得
- クラウドセキュリティガイドライン (NIST SP 800-145)
- 特定の地域(例: EU)におけるデータ主権要件
- **実現方式・仕様**:
- クラウド環境のリージョン選定は、データ主権要件を満たす地域(例: 日本国内)に限定
- IaC(Infrastructure as Code)で定義されたインフラ構成は、社内セキュリティポリシーに準拠していることを自動チェック
- 構築作業は、ISO/IEC 27001に準拠した変更管理プロセスを経て実施
#### F1.2 運用時の制約条件 (Operational Constraints)
##### F1.2.1 運用時の制約条件
- **要件**: 以下の社内基準、法令、ガイドラインを遵守した運用を行うこと
- J-SOX法におけるIT統制要件
- 個人情報保護法
- リモートからの運用は、社内セキュリティポリシーで許可された範囲に限定
- **実現方式・仕様**:
- 運用担当者のアクセス権限は最小限に制限し、J-SOX法に準拠したアクセスログを記録
- 個人情報を含むデータの取り扱いは、暗号化、アクセス制御、監査ログ取得を徹底
- リモート運用は、VPN接続と多要素認証を必須とし、許可されたIPアドレスからのみアクセス可能とする
### F2. システム特性 (System Characteristics)
#### F2.1 ユーザー数 (Number of Users)
##### F2.1.1 ユーザー数
- **要件**: 最大アクティブユーザー数 50,000人
- **実現方式・仕様**:
- 認証基盤として、50,000ユーザー規模に対応可能なIDaaS(Identity as a Service)を選定
- ロードバランサー、Web/APサーバーは、このユーザー数に対応できるキャパシティプランニングに基づき設計
#### F2.2 クライアント数 (Number of Clients)
##### F2.2.1 クライアント数
- **要件**: 最大同時接続クライアント数 15,000
- **実現方式・仕様**:
- ロードバランサーの最大同時接続数を15,000以上で設定
- データベースのコネクションプール設定は、最大同時接続数に対応できるよう最適化
#### F2.3 拠点数 (Number of Sites)
##### F2.3.1 拠点数
- **要件**: 国内3拠点(東京、大阪、福岡)からのアクセスに対応
- **実現方式・仕様**:
- クラウドの複数アベイラビリティゾーン(AZ)または複数リージョン(例: 東京リージョン、大阪リージョン)にシステムを分散配置
- 各拠点からのアクセスは、CDNやDNSルーティングにより最適なサーバーに誘導
#### F2.4 地域的広がり (Geographical Scope)
##### F2.4.1 地域的広がり
- **要件**: 国内全域からのアクセスに対応し、海外からのアクセスは制限する
- **実現方式・仕様**:
- WAFやファイアウォールを用いて、海外からのアクセスをIPアドレスベースで制限
- CDNのエッジロケーションは国内に限定し、国内ユーザーへの高速なコンテンツ配信を優先
#### F2.5 特定製品指定 (Specific Product Designation)
##### F2.5.1 特定製品の採用有無
- **要件**: データベースにはPostgreSQL、メッセージキューにはApache Kafkaを使用すること
- **実現方式・仕様**:
- データベースは、クラウドプロバイダーが提供するマネージドPostgreSQLサービス(例: AWS RDS for PostgreSQL)を利用
- メッセージキューは、クラウドプロバイダーが提供するマネージドKafkaサービス(例: Amazon MSK)または自社で管理するApache Kafkaクラスタを構築
- これらの製品のサポート体制、バージョンアップ計画、セキュリティパッチ適用方法を事前に確認し、運用計画に組み込む
### F3. 適合規格 (Applicable Standards)
#### F3.1 製品安全規格 (Product Safety Standards)
##### F3.1.1 規格取得の有無
- **要件**: 使用する全てのハードウェア(物理サーバー、ネットワーク機器)は、UL60950または同等の製品安全規格を取得していること
- **実現方式・仕様**:
- データセンター提供の物理機器については、データセンター事業者が取得している安全規格の証明書を確認
- クラウドサービス利用の場合、クラウドプロバイダーが準拠しているデータセンターの安全基準を確認(例: SOC 2 Type IIレポート)
#### F3.2 環境保護 (Environmental Protection)
##### F3.2.1 規格取得の有無
- **要件**: 使用する全てのハードウェアは、RoHS指令に準拠していること
- **実現方式・仕様**:
- データセンター提供の物理機器については、データセンター事業者が調達する機器のRoHS指令準拠を確認
- クラウドサービス利用の場合、クラウドプロバイダーの環境保護に関するポリシーやレポート(例: サステナビリティレポート)を確認
### F4. 機材設置環境条件 (Equipment Installation Environment Conditions)
#### F4.1 耐震/免震 (Earthquake Resistance/Isolation)
##### F4.1.1 耐震震度
- **要件**: 物理的な設置場所は、実効震度6強に耐えうる耐震構造であること
- **実現方式・仕様**:
- システムを設置するデータセンターは、耐震構造(例: 免震構造)を有し、震度6強以上の地震に耐えられる施設を選定
- ラックマウント機器は、耐震ラックに固定し、転倒防止対策を徹底
#### F4.2 スペース (Space)
##### F4.2.1 設置スペース制限(マシンルーム)
- **要件**: マシンルームへの設置は、最大10ラック(W600mm x D1000mm)に収まること
- **実現方式・仕様**:
- 物理サーバー、ネットワーク機器の選定は、高密度実装が可能なモデルを優先
- 将来的な拡張を考慮し、初期段階では7ラックに収め、3ラック分の予備スペースを確保
##### F4.2.2 設置スペース制限(事務所設置)
- **要件**: 事務所内へのサーバー設置は行わないこと
- **実現方式・仕様**:
- 全てのシステムコンポーネントは、データセンターまたはクラウド環境に配置
- 開発・テスト用の機器も、仮想環境またはクラウドサービスを利用し、物理的な事務所設置を回避
---
## テスト計画(システム環境・エコロジー関連)
### 環境適合性確認
- **実施時期**: 構築フェーズ初期、および環境変更時
- **テスト項目**:
- 選択したクラウドリージョンがデータ主権要件を満たしているか
- ファイアウォール設定が地域的アクセス制限要件を満たしているか
- 特定製品(PostgreSQL, Kafka)が指定バージョンで正しく動作するか
- **合格基準**: 全ての環境制約・前提条件が満たされていること
### 物理環境監査(オンプレミスの場合)
- **実施時期**: データセンター選定時、および定期監査(年1回)
- **テスト項目**:
- データセンターの耐震構造、電源供給、空調設備が要件を満たしているか
- 設置スペースが計画通り確保されているか
- 使用機器の安全規格・環境保護規格の証明書確認
- **合格基準**: 物理環境が全ての設置条件を満たしていること
### リソース効率性評価
- **実施時期**: 性能テストと並行して実施、および定期的な見直し(四半期ごと)
- **テスト項目**:
- 仮想化環境におけるCPU、メモリ、ディスクの利用効率
- クラウドサービスのインスタンスタイプがワークロードに対して最適か
- 消費電力(物理環境の場合)
- **合格基準**: リソース利用率が目標値(例: CPU平均利用率50%以上)を達成し、無駄なリソース消費がないこと
---
## リスクと対策
| No | リスク | 影響 | 発生確率 | 対策 |
|----|--------|------|---------|------|
| 1 | 法令・規制違反 | 罰金、事業停止、企業イメージ失墜 | 中 | 法務部門との連携強化、定期的な法令遵守チェック、クラウドプロバイダーのコンプライアンスレポート確認 |
| 2 | 特定製品のEOL/サポート終了 | システムの脆弱性、運用コスト増大、リプレース費用発生 | 中 | 製品のライフサイクル管理、EOL情報の早期収集、代替製品の検討と評価 |
| 3 | 物理環境の災害(地震など) | システム停止、データ損失 | 低 | 耐震・免震構造のデータセンター選定、複数リージョンへのシステム分散、DR計画の策定 |
| 4 | 地域的アクセスの誤設定 | サービス提供範囲外からのアクセス許可、または必要なアクセスが遮断される | 中 | ファイアウォール、WAF、CDNの地理的フィルタリング設定の厳密なレビューとテスト |
| 5 | リソースの過剰消費 | 運用コスト増大、環境負荷増大 | 中 | 定期的なリソース利用状況の監視と最適化、オートスケーリングの適切な設定、省電力型機器の選定 |
| 6 | 既存システムとの互換性問題 | 移行失敗、運用非効率化 | 中 | 既存システムとのインターフェース仕様の明確化、互換性テストの徹底、段階的移行計画 |
--- 🔄 設計の進め方・プロセス
🏗️ プロセス1: システム制約・前提条件の特定
設計対象:
システム構築・運用時に遵守すべき法令、規制、社内基準、および既存環境との整合性を明確にする。
具体例:
- 適用される法令・規制(個人情報保護法、J-SOX、業界特有の規制等)の特定
- 社内セキュリティポリシー、運用ポリシーの確認
- データ主権要件(特定地域へのデータ配置制約)の特定
- 既存インフラ環境(オンプレミス、クラウド、ハイブリッド)との整合性確認
- 構築・運用時のアクセス制限、承認プロセス等の制約確認
設計原則:
- 法令遵守の最優先: 全ての法令・規制要件を漏れなく特定し、遵守方法を明確にする
- 早期の制約特定: 構築着手前に全ての制約を特定し、後工程での手戻りを防ぐ
- 法務部門との連携: 法令解釈が不明確な場合は、法務・コンプライアンス部門と連携する
- 文書化の徹底: 特定した制約と遵守方法を明確に文書化し、チーム内で共有する
文書化の推奨表現:
- 制約一覧表の作成: 構築時・運用時の制約を区分し、制約内容と遵守方法を一覧化する
- 法令要件マッピング: 各法令・規制の要求事項と、システムでの実現方法を対応付ける
- リスク評価: 制約違反時のリスク(罰金、事業停止等)を評価し、優先度を明確にする
🏗️ プロセス2: システム特性の定義
設計対象:
システムのスケール(ユーザー数、拠点数、地域的広がり等)と、特定製品・技術の指定有無を明確にする。
具体例:
- 最大アクティブユーザー数、最大同時接続クライアント数の想定
- 対象拠点数(国内・海外)、地域的広がり(国内のみ、グローバル等)の定義
- アクセス元の地域制限(国内のみ許可、特定国からの遮断等)の定義
- 特定製品・技術の指定有無(データベース、ミドルウェア等)の確認
- 特定製品指定の理由、サポート体制、ライフサイクルの確認
設計原則:
- 根拠のある想定: ユーザー数等の想定は、ビジネス計画や市場調査に基づく根拠を持つ
- 将来の拡張性考慮: 初期想定に加え、将来の成長を見込んだ拡張性を確保する
- 地域特性の理解: アクセス元の地域特性(ネットワーク環境、法規制等)を理解する
- 製品依存のリスク評価: 特定製品への依存度とEOLリスクを評価する
文書化の推奨表現:
- システム特性一覧表: ユーザー数、拠点数、地域的広がり等を一覧化する
- スケーリング計画: 初期想定と将来の拡張計画を明記する
- 特定製品一覧: 指定製品、選定理由、サポート体制、EOL情報を記載する
🏗️ プロセス3: 適合規格の確認
設計対象:
使用するハードウェア、ミドルウェアが適合すべき製品安全規格、環境保護規格を特定し、適合状況を確認する。
具体例:
- 製品安全規格(UL60950、CE等)への適合確認
- 環境保護規格(RoHS指令、エネルギースター等)への適合確認
- クラウドサービス利用時のプロバイダー認証(ISO27001、SOC2等)の確認
- 業界特有の認証・規格(医療機器、金融等)の確認
設計原則:
- 適合規格の早期特定: 調達・構築前に必要な規格を特定し、適合製品を選定する
- 証明書の確認: データセンター事業者、クラウドプロバイダーから証明書を入手する
- 定期的な見直し: 規格の改訂、新規規格の追加に対応するため、定期的に見直す
文書化の推奨表現:
- 適合規格一覧表: 必要な規格、適合状況、証明書の保管場所を一覧化する
- 規格遵守証跡: データセンター、クラウドプロバイダーの証明書・レポートを保管する
🏗️ プロセス4: 機材設置環境条件の定義
設計対象:
物理的な機材設置が必要な場合、設置場所の環境条件(耐震性、スペース、電源、空調等)を定義する。
具体例:
- 耐震・免震要件(実効震度6強等)の定義
- 設置スペース制限(ラック数、サイズ等)の確認
- 電源容量、UPS、非常用電源の要件定義
- 空調・温湿度管理要件の定義
- 物理セキュリティ要件(入退室管理、監視カメラ等)の定義
設計原則:
- データセンター選定基準の明確化: 環境条件を満たすデータセンターを選定する
- クラウド優先の検討: 物理環境管理の負担を軽減するため、クラウドサービスを優先検討する
- 将来の拡張余地確保: 初期段階で必要なスペースに加え、拡張余地を確保する
文書化の推奨表現:
- 設置環境条件一覧表: 耐震性、スペース、電源、空調等の条件を一覧化する
- データセンター評価表: 候補データセンターの環境条件適合状況を評価する
- リソース効率化計画: 仮想化、クラウド活用による物理リソース削減計画を記載する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考文献:
- NIST SP 800-145『クラウドコンピューティングの定義』
- ISO/IEC 27001(情報セキュリティマネジメントシステム)
- 経済産業省『システム管理基準』
- 『データセンター設計・構築ガイドブック』
- 関連する他のガイド:
- 法令・規制参考:
- 個人情報保護委員会『個人情報の保護に関する法律についてのガイドライン』
- 金融庁『金融商品取引業者等向けの総合的な監督指針』(J-SOX対応)
- 環境規格参考:
- RoHS指令(EU)
- エネルギースター(米国EPA)
- グリーングリッド(データセンター電力効率)
テンプレートサイト: 📄テンプレート集