インフラ担当のクラウドエンジニアが作成する成果物を解説 ─「基本設計書」編

近年、クラウドの普及により、企業のITインフラ構築の在り方が大きく変化しています。その中で、クラウドエンジニアは、最適なインフラ環境を設計・構築し、安定したシステム運用を支える重要な役割を担うようになりました。

システム設計の初期段階で作成される「基本設計書」は、クラウド基盤の構築において重要な成果物の一つです。

本記事では、クラウドエンジニアが作成する基本設計書の内容や目的、具体的な項目について解説し、より効率的で堅牢なインフラ設計を行うためのポイントを紹介します。クラウド環境の設計に関わる方はぜひ参考にしてください。

基本設計書とは？

基本設計書は、システムの設計を具体化し、開発・構築・運用フェーズに必要な情報を整理した文書です。特にクラウドインフラエンジニアにとっては、クラウド環境の設計方針や構成を明確にし、開発者や運用チームと共有するための重要なドキュメントとなります。

基本設計書は、システムの全体像を示し、「どのようにインフラを構築するのか」を技術的な観点から記述したものです。これにより、構築後のシステムが設計通りに動作するか、運用フェーズで問題が発生しないかを事前に検討できます。

基本設計書を作成する目的

基本設計書を作成する目的は、要件定義で定められた「クライアントが欲しい機能」の抽象的な部分を具体化することです。要件定義では「どのような機能が必要か」が決まりますが、基本設計書ではそれを「どのように実現するか」に落とし込むことが求められます。

その他、基本設計書を作成する目的には以下の要素があります。

システムの構成や使用するリソースを明確にする
関係者間の認識を統一する
構成変更時の手戻りを少なくする
セキュリティ要件、コスト要件など要件定義では定義しづらい部分を明確にする

基本設計書に盛り込む内容

基本設計書の目的は、先ほど解説した通り要件定義で定められた「クライアントが欲しい機能」をどのように実現するかを具体的に記すことです。

機能の具体化のために、基本設計書に記載するべき内容を1つずつ解説します。

表紙

基本設計書の表紙には、ドキュメントの正式なタイトルや作成者情報を明記します。そのほか、表紙には以下の内容を記載します。

基本設計書のタイトル
作成日
作成者
プロジェクト名
システム名

どのプロジェクトのインフラ基本設計書なのかをわかるようなタイトルを記載しましょう。

基本情報

基本情報としては、以下の項目を記載します。

基本設計書の目的

（例：〇〇プロジェクトにおけるインフラ環境を明確にするものである）

目次
作成履歴（バージョン、変更内容、変更者）
関連文書（基本設計書に関連する文書を一覧にする）

基本設計書には多くの情報を記載します。関係者が必要な情報に素早くアクセスできるようにするため、目次は必要不可欠です。また、変更履歴で、いつ、誰が、どのような変更を加えたかを明確にすることで、ドキュメントの整合性が保てます。

システム概要

システム概要では、以下を記載します。

インフラの構成図
利用するクラウドサービスの一覧

要件定義の段階で全体の構成図も作成するケースが多いです。その全体構成図からインフラ部分のみを抽出して、インフラ単体の構成図を作成しましょう。

構成案については、「構成図は別紙に示す」として、関連文書に構成図が書かれているファイル名を記載するケースも多いです。

利用するクラウドサービスの項目では、構成図に記載しているサービスを全て記載します。その際、構成図に図示していないサービスも含めて記述するとよいでしょう。また、リソースの利用用途も合わせて記述しましょう。

システム設計

システム設計では、以下の3つの項目を記載します。

命名規則
SLA（Service Level Agreement）
スペック一覧

命名規則

Ops-Today-Web-(リソースの略称)

管理のしやすさ向上のため、上記のように、システム内の各リソースに統一した命名規則を適用しましょう。具体的には、「環境名-サービス名-リソースの略称-連番」という形式を採用し、リソースの用途を一目で識別できるようにします。

SLA（Service Level Agreement）

システムの可用性目標を設定し、例えば「99.9% の可用性を保証する」などの指標を定めましょう。また、障害発生時の復旧目標として、RTO（目標復旧時間）とRPO（目標復旧時点）を明確にし、「RTO 4時間」「RPO 15分」といった具体的な数値を設定します。

これにより、万が一のシステム障害時にどの程度の時間内に復旧すべきかを明確にし、事前の準備を整えます。運用時間についても、24時間365日稼働するのか、または平日9:00-18:00のように限定するのかを明記し、サポート体制との整合性を考慮しましょう。

スペック一覧

利用するサービスによっては、無料プラン、スタンダードやプレミアムといったプランの選択をするものがあります。

例えば、AWSのEC2（仮想マシン）の支払い方法はオンデマンドにするのか、長期継続利用割引ができるリザーブドインスタンスにするのかを決定し、基本設計書に明記しましょう。そのほか、AWS WAF（Web Application Firewall）を利用する場合は、Standardプランにするか、マネージドルールを付与するのかも明記します。

ネットワーク設計

ネットワーク設計では、システムとインターネットとの接続が発生するのか、インターネット接続が必要な場合の接続方法やファイアウォールなどのセキュリティはどのように設定するのかを記述します。

仮想マシンやデータベースがサブネット内外のリソースとどのように接続するのかを定義する必要があります。HTTPS接続とするのか、アクセス制限を設けるのかなどを決定し、基本設計書に記載します。

ネットワークやサブネットに設定するIPアドレスやIPアドレス範囲については、詳細設計書（パラメータシート）で記載するため基本設計書では概要部分のみを記載します。ネットワーク設計の項目で、DNS設計やドメイン設計についても記載しましょう。

DNS設計

システム内で使用するドメイン名とその管理方法を定義します。例えば、「example.com」をルートドメインとし、DNSはAWSのRoute 53で管理すると決定します。さらに、「api.example.com」や「app.example.com」のようなサブドメインが必要な場合はそれも記述します。

セキュリティ設計

セキュリティ設計では、システムの機密性・完全性・可用性を確保するためのルールや仕組みを定めます。ゼロトラストアーキテクチャの考え方を取り入れ、最小権限の原則を適用することが重要です。

具体的には、以下の項目を設定するとよいでしょう。

アカウントへの権限設定
パスワードの設定規則や有効期限などの規定を定める
各アカウントのログ取得規則を定める
各リソースの認証設定を明記する
認証情報の管理方法を定める

バックアップ・可用性・拡張性設計

システムの安定稼働とデータ保護を目的として、バックアップ戦略、可用性の確保、拡張性の設計も基本設計書に記載するべき内容です。

バックアップ設計

バックアップ設計で記載するべき内容は、バックアップの対象、取得頻度と保持期間、復旧手順の3点です。

データベースのスナップショットを1日1回取得し、30日間保持
仮想マシンのスナップショットは日次取得、7日間保持（重要システムは週次・月次も検討）
オブジェクトストレージのデータは、一定期間後にアーカイブストレージへ移動しコスト最適化

上記のように、バックアップするべきリソースや取得方法、保持期間を明記します。さらに、各リソースで復旧目標（RTO）と復旧可能時点（RPO）を決定して記載しましょう。

拡張施設計では、各リソースの水平スケーリングと垂直スケーリング設定をどのように設定するか決定し記述しますまた、冗長化設定については、リージョン間の冗長や可溶性ゾーン間の冗長設定をどのように設定するか記述します。

運用・監視設計

運用・監視設計では、システムの正常な稼働を維持し、障害発生時に迅速な対応ができるようにするための監視・ログ管理・運用ポリシーを記述します。

運用、監視設計については、インフラ設計チームから運用チームに委託するケースもあるため、基本設計書に記載せず「インフラ運用設計書」、「インフラ監視設計マニュアル」のように個別に作成される場合もあります。

各クラウドのモニタリングツールを紹介します。

AWS：Amazon CloudWatch, AWS X-Ray, AWS Security Hub
Azure：Azure Monitor, Application Insights, Azure Security Center
Google Cloud：Cloud Monitoring, Cloud Logging, Security Command Center

上記のリソースを利用するのか、それ以外の外部の監視サービスを活用するのかを決定し、監視項目や監視対象も合わせて記載します。

監視対象と監視項目

各コンポーネントごとに監視項目を定義し、適切な監視ツールを利用します。

監視対象	監視項目	閾値/しきい値	対応方法
仮想マシン / コンテナ	CPU使用率	80%	インスタンスのスケールアウト
仮想マシン / コンテナ	メモリ使用率	90%	メモリ割り当て増加またはスケールアウト
データベース	接続数	最大接続数の80％	アプリの接続管理を見直し
データベース	クエリ遅延	1秒	クエリ最適化またはリードレプリカ追加
ネットワーク	帯域使用率	85％	通信負荷の分散、CDN活用
セキュリティ	異常ログイン	5回以上/10分	IAMアクセス制限、WAF適用

上記の表のように、監視対象や監視項目を定めた際の、基本設計書に記載する内容の例を紹介します。

例）

本システムでは、CPU・メモリ・ネットワーク負荷を監視し、閾値を超えた場合に自動対応を実施する。具体的には、CPU使用率80%超過時にインスタンスをスケールアウトし、負荷分散を行う。また、セキュリティログを定期的に監視し、不正アクセス試行が5回以上検出された場合はアラートを発生させる。

運用設計

運用設計を記載する際は、以下のように、運用時間、運用体制、障害発生時の対応方法を記載しましょう。

運用時間: 24時間365日 / 平日9:00～18:00 など
運用体制: システム管理者、アプリケーション運用担当、サポート窓口
対応レベル:
- 重大障害（P1）: 影響範囲が広く、システムが利用不能 → 1時間以内に対応開始
- 中程度の障害（P2）: 一部機能に影響 → 4時間以内に対応
- 軽微な障害（P3）: 小規模な影響や警告 → 翌営業日対応

システムの変更管理

システムの変更管理は、クラウドインフラの変更を安全かつ効率的に行うためのルールやプロセスを定めます。これにより、構成の一貫性を保ち、変更による障害やリスクを最小限に抑えることができます。

CICD構成
Infrastructure as Code（IaC） の導入
- Terraform / CloudFormation / ARM Templates の活用
- Git によるコード管理（ブランチ戦略）
バージョン管理
- IaC の変更履歴を Git / GitHub / GitLab / Bitbucket で管理
- 過去の構成との差分確認（Terraform Plan、CloudFormation Change Set）
タグ管理
- リソースの所有者、環境（開発 / 本番）、コスト管理のためのタグポリシー
- AWS Config / Azure Policy / GCP Organization Policies によるタグルールの適用