はじめに

AWSインフラの現場に入ると、いきなりいろいろな言葉が出てきます。

要件定義
基本設計
詳細設計
実装
検証
外部設計
内部設計
PoC
責任分界

言葉だけ知っていても、「いま何を決める場面なのか」が分からないと、会議でも作業でも迷子になります。

この記事では、AWSインフラ工程を5ステップで整理します。

動画版

この記事は、YouTubeで公開済みの内容をQiita向けに再構成したものです。

AWSインフラ工程入門【前編】｜レストランで学ぶ工程5ステップ・要件定義と責任分界・設計書とPoC

前提

対象読者: AWSインフラの工程や設計レビューで使う言葉を整理したい人
扱う範囲: 要件定義、設計、実装、検証の考え方
扱わない範囲: 個別AWSサービスの詳細な構築手順、料金見積もり、可用性設計の正解
仕様確認日: 2026-07-28

この記事は、特定の本番構成をそのまま作る手順ではなく、AWSインフラ作業を進めるときの工程整理として読んでください。具体的な料金、上限、サービス仕様は変わるため、実作業では公式ドキュメントを確認します。

先に結論

AWSインフラ工程は、次の順番で考えると迷いにくくなります。

工程	決めること	具体例	成果物
要件定義	何を満たすか	月次メンテは許容、障害は15分以内に検知したい	要件一覧、責任分界
基本設計	どんな構成にするか	CloudFront、ALB、ECS、RDSを使う	全体構成図、サービス選定
詳細設計	具体値をどうするか	CIDR、サブネット、SG、IAM、バックアップ保持	パラメータ表、IaC設計
実装	環境へどう反映するか	CloudFormationやTerraformでデプロイする	テンプレート、デプロイ手順
検証	約束どおり動くか	障害検知、復旧、権限、負荷を確認する	テスト結果、運用確認

大事なのは、各工程で「何を決める場面か」を混ぜないことです。

用語の短い説明

この記事で出てくるAWSインフラ用語を、先に短く整理します。

用語	短い説明
VPC	AWS上に作る自分用の仮想ネットワーク
CIDR	ネットワークのIPアドレス範囲を表す書き方。例: `10.0.0.0/16`
サブネット	VPCの中を用途やAZごとに分けた小さなネットワーク
SG	Security Groupの略。どこからどの通信を許すかを決める仮想ファイアウォール
IAM	AWS上のユーザー、ロール、権限を管理する仕組み
ALB	Application Load Balancer。Webアクセスを複数のアプリへ振り分ける入口
ECS	コンテナをAWS上で動かすためのサービス
RDS	AWSが管理してくれるリレーショナルデータベース
IaC	Infrastructure as Code。インフラ構成をコードで管理する考え方
PoC	Proof of Concept。分からない点を小さく試す検証

5ステップの全体像

まず全体像です。

# 工程の大きな流れ
1. 要件定義
2. 基本設計
3. 詳細設計
4. 実装
5. 検証

この順番は、単なる用語の並びではありません。

後戻りを減らすための、決める順番です。

レストランを開く例で考えると分かりやすいです。

# レストランに置き換えた例
要件定義: どんな店を出すのか
基本設計: 店の大まかな形を決める
詳細設計: 工事や調理に必要な具体値へ落とす
実装: 実際に作る
検証: プレオープンして約束どおり動くか確認する

AWSでも同じです。いきなりコンソールを開いて作り始めるのではなく、何を満たすべきか、どんな構成にするか、具体値は何か、順に決めます。

例えば、シンプルなWebアプリでも、工程ごとに見るものは変わります。

# AWSのWebアプリで考えた例
要件定義:
  何時まで止められるか、誰が障害対応するか

基本設計:
  CloudFront + ALB + ECS + RDS にするか

詳細設計:
  VPC CIDR、subnet、security group、RDS backup、alarm threshold

実装:
  IaCで作成し、change set / plan を確認する

検証:
  HTTPS疎通、DB接続、ログ、監視、復旧手順を確認する

1. 要件定義

要件定義は、「どんなシステムにしたいのか」を、設計できる言葉に変える工程です。

大きく分けると、機能要件と非機能要件があります。

# 要件の種類
機能要件
  -> 何ができるか

非機能要件
  -> どんな品質で動くか

インフラでは、特に非機能要件が重要です。

可用性
性能
セキュリティ
バックアップ
監視
運用
復旧
コスト

例えば、「Webサイトを公開する」だけでは要件として弱いです。

どれくらい止まってはいけないのか
ピーク時にどれくらいのアクセスを想定するのか
誰がバックアップを確認するのか
障害時に何分以内に気づきたいのか
どこまでをAWSに任せ、どこからを自分たちが持つのか

ここを曖昧にしたまま進むと、後で「それは誰の責任なのか」で揉めます。

要件定義で最低限聞きたい質問は、次のようなものです。

観点	確認する質問
可用性	どれくらいの停止なら許容できるか
性能	普段とピーク時のアクセス量はどれくらいか
セキュリティ	誰が管理画面へ入れるか、多要素認証は必要か
バックアップ	何日前まで戻せればよいか
監視	何分以内に誰へ通知したいか
コスト	月額上限や優先順位はあるか

責任分界を決める

AWSには共有責任モデルがあります。

ざっくり言えば、AWSはクラウド基盤側を守り、利用者はその上での設定、データ、アクセス制御などに責任を持ちます。

ただし、どこまでが利用者側の責任かは、使うサービスで変わります。

EC2なら、OSやミドルウェアの運用が利用者側に寄りやすくなります。RDSのようなマネージドサービスでは、OS管理などはAWS側へ寄ります。

さらに現場では、AWSと利用者の境界だけでなく、インフラ担当とアプリ担当の境界も大事です。

# 責任の分け方を先に言葉にする
インフラ担当
  -> アプリが動く箱を用意する

アプリ担当
  -> 箱の中で業務ロジックを動かす

もちろん、コンテナ、IAM、DBスキーマ、環境変数など、どちらが持つか曖昧になりやすい領域もあります。

だからこそ、要件定義の段階で「誰がどこまで持つか」を確認します。

2. 基本設計

基本設計は、システムの大きな形を決める工程です。

レストランで言えば、客席、厨房、入口、レジ、導線の大枠を決める段階です。

AWSなら、例えば次のようなことを決めます。

どのAWSサービスを使うか
VPCをどう分けるか
public / private subnetをどう置くか
DBをマルチAZにするか
CloudFrontを前段に置くか
監視とログの大枠をどうするか
外部公開する入口はどこか

ここでは、細かいパラメータよりも、全体の形と関係者との約束を固めます。

この段階の図は、細かいIPアドレスよりも、責務が伝わることを優先します。

# 基本設計ではサービス同士のつながりを描く
User
  -> CloudFront
  -> ALB
  -> ECS / EC2 / Lambda
  -> RDS

Operator
  -> CloudWatch Logs / Alarm

「なぜそのサービスを選んだか」を1行で説明できる状態にしておくと、後のレビューが楽になります。

3. 詳細設計

詳細設計は、基本設計を実装できる具体値に落とす工程です。

例えば、以下のような値を決めます。

CIDR
サブネットごとのルーティング
セキュリティグループのルール
インスタンスタイプ
RDSのバックアップ保持期間
CloudWatch Alarmのしきい値
IAMポリシー
環境変数
デプロイ手順

基本設計が「どんな構成にするか」なら、詳細設計は「その構成をどう作るか」です。

この段階まで来ると、CloudFormationやTerraformのコードに落としやすくなります。

詳細設計は、例えば次のような表にします。

項目	例	注意点
VPC CIDR	`10.0.0.0/16`	既存ネットワークと重複しないか
public subnet	`10.0.1.0/24`, `10.0.2.0/24`	AZを分けるか
private subnet	`10.0.11.0/24`, `10.0.12.0/24`	DBやアプリを置く場所
Security Group	ALBからアプリへ許可	`0.0.0.0/0`を不用意に使わない
RDS backup	例: 要件に応じて保持期間を決める	DB種類や構成で設定範囲が変わるため公式仕様で確認
Alarm	5xx、CPU、DB接続数	通知先まで決める

サンプルコード: 詳細設計をCloudFormationへ落とす

過去記事では、CloudFormationテンプレート、パラメータファイル、実行コマンドをセットで載せる形が多くありました。

ここでも同じように、詳細設計の値を小さなCloudFormationテンプレートに落としてみます。

以下は概念例です。本番利用する場合は、CIDR、AZ、タグ、命名、通信元、料金、リージョンを自分の環境に合わせて見直してください。

sample-vpc.yml

AWSTemplateFormatVersion: '2010-09-09'
Description: Sample network resources for explaining design-to-IaC flow.

Parameters:
  # 環境ごとに変わる値は Parameters に出して、テンプレート本体と分ける
  VpcCidr:
    Type: String
    Default: 10.20.0.0/16
    Description: VPC全体のCIDR。既存ネットワークと重複しない値にする。

  AppSubnetCidr:
    Type: String
    Default: 10.20.1.0/24
    Description: アプリ用サブネットのCIDR。VPCの範囲内に収める。

  AllowedHttpCidr:
    Type: String
    Default: 203.0.113.0/24
    Description: HTTPを許可する検証用CIDR。本番ではALBや社内IPなどに絞る。

Resources:
  # VPCはネットワーク全体の入れ物。DNS設定は多くのAWSサービス連携で必要になる
  SampleVpc:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VpcCidr
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: sample-vpc

  # サブネットはVPC CIDRの中から切り出す。ここでは説明用に1つだけ作る
  AppSubnetA:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref SampleVpc
      CidrBlock: !Ref AppSubnetCidr
      AvailabilityZone: !Select [0, !GetAZs '']
      MapPublicIpOnLaunch: false
      Tags:
        - Key: Name
          Value: sample-app-subnet-a

  # Security Groupは通信許可のルール。検証でも通信元を広げすぎない
  WebSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allow HTTP for a small sample workload.
      VpcId: !Ref SampleVpc
      SecurityGroupIngress:
        - Description: 検証用HTTP。実運用では通信元をさらに絞る。
          IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: !Ref AllowedHttpCidr
      SecurityGroupEgress:
        - Description: HTTPSで外部APIやパッケージ取得を行う想定。
          IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: 0.0.0.0/0
      Tags:
        - Key: Name
          Value: sample-web-sg

Outputs:
  # 作成後に確認したいIDをOutputsに出すと、レビューや後続作業で追いやすい
  VpcId:
    Description: 作成したVPCのID
    Value: !Ref SampleVpc

  AppSubnetId:
    Description: 作成したアプリ用サブネットのID
    Value: !Ref AppSubnetA

パラメータを別ファイルにすると、環境ごとの差分をレビューしやすくなります。

dev-parameters.json

[
  {
    "ParameterKey": "VpcCidr",
    "ParameterValue": "10.20.0.0/16"
  },
  {
    "ParameterKey": "AppSubnetCidr",
    "ParameterValue": "10.20.1.0/24"
  },
  {
    "ParameterKey": "AllowedHttpCidr",
    "ParameterValue": "203.0.113.0/24"
  }
]

実行前は、まずテンプレートの構文を確認します。

# 実リソースを作る前に、CloudFormationテンプレートの構文を確認する
aws cloudformation validate-template \
  --template-body file://sample-vpc.yml

実際に作る場合は、スタック名、リージョン、AWS CLIプロファイル、料金影響を確認してから実行します。

# サンプル用スタックを作成する。実行前にリージョンと認証先を必ず確認する
aws cloudformation create-stack \
  --stack-name sample-network \
  --template-body file://sample-vpc.yml \
  --parameters file://dev-parameters.json

# 検証が終わったら、不要な課金や残置を避けるために削除する
aws cloudformation delete-stack \
  --stack-name sample-network

このサンプルの目的は、VPCを完璧に作ることではありません。

要件定義で出た「何を満たすか」が、詳細設計の値になり、最後にIaCのコードへ落ちる流れを掴むことです。

4. 実装

実装は、設計した内容を実際の環境へ反映する工程です。

AWSでは、手作業でコンソールを触るより、IaCで再現できる形にすることが多いです。

# IaCで反映するときのレビューの流れ
CloudFormation / Terraform
  -> review
  -> deploy
  -> change set / plan確認

実装中に新しい方針を決め始めると、設計と実装が混ざります。

もちろん、実装中に設計漏れが見つかることはあります。その場合は、設計へ戻って合意し直す方が安全です。

5. 検証

検証は「作ったものが起動するか」だけではありません。

要件定義や設計で決めた約束を満たしているかを見る工程です。

通信できるか
権限が強すぎないか
ログが出るか
監視できるか
バックアップできるか
復旧できるか
想定したアクセスに耐えられるか
障害時にどこで気づけるか

レストランで言えば、プレオープンです。

料理が出せるだけでなく、ピーク時に回るか、レジ締めできるか、スタッフが動けるかまで確認します。

戻るほど高くつく

工程で一番大事なのは、後ろに行ってから前に戻るほど高くつくという感覚です。

詳細設計中に基本設計へ戻るなら、まだ傷は浅いです。

しかし、リリース直前に要件定義へ戻ると、設計、実装、検証、関係者調整、スケジュールが一気に崩れます。

# 後工程で要件漏れに戻ると、関係者調整まで巻き戻る
要件定義の漏れ
  -> 基本設計の変更
  -> 詳細設計の変更
  -> IaC修正
  -> 再デプロイ
  -> 再テスト
  -> 関係者再説明

だから、最初に時間をかける価値があります。

基本設計・詳細設計・外部設計・内部設計のズレ

現場によって、用語の使い方は少し違います。

一般的には、基本設計は外から見える大きな方針、詳細設計は実装できる具体値に近いです。

一方、外部設計と内部設計は、アプリ開発寄りの文脈で使われることも多いです。

# アプリ開発で使われやすい外部設計・内部設計の整理
外部設計
  -> 画面、帳票、API、入出力、ユーザー操作など

内部設計
  -> DB、処理ロジック、クラス、モジュールなど

AWSインフラでは、これらが完全に1対1で対応するとは限りません。

用語だけで決め打ちせず、「いま話しているのは、外から見える約束なのか、内部の具体値なのか」を確認すると安全です。

設計書は厚ければよいわけではない

設計書の粒度に、絶対の正解はありません。

重要なのは、関係者が合意でき、後から運用できることです。

書くべきことは、例えば以下です。

何を満たすための構成か
どのサービスを使うか
責任分界はどこか
重要な設定値は何か
なぜその値にしたか
変更するときの注意点は何か
検証観点は何か

逆に、誰も読まないほど細かい転記だけの設計書は、更新されずに古くなりやすいです。

PoCは「分からないこと」を小さく試す

PoCは、なんとなく触ってみることではありません。

不確実な点を小さく試すためのものです。

# PoCは不明点を小さく試して設計へ戻すために行う
不明点
  -> 小さく試す
  -> 結果を確認
  -> 要件や設計へ戻す

例えば、次のような疑問があるならPoCの対象になります。

想定レスポンス時間を満たせるか
外部APIと安全に連携できるか
権限設計が運用に耐えるか
既存データ量で検索が遅くならないか
新しい構成で費用が跳ねないか

PoCの結果は、やりっぱなしにせず、要件定義や設計書に反映します。

現場で使える確認フレーズ

工程が曖昧な会議では、次のように確認すると進めやすいです。

# 会議で工程を揃えるための聞き方
これは要件として合意したい話ですか？
それとも設計方針の相談ですか？

この基本設計では、どこまでを決める想定ですか？

この値は詳細設計で確定する理解で合っていますか？

インフラ担当とアプリ担当の責任境界はどこに置きますか？

PoCの結果は、どの設計書に反映しますか？

大事なのは、強く言うことではなく、いま何の工程の話をしているかを揃えることです。

まとめ

AWSインフラ工程は、次の5ステップで整理できます。

要件定義: 何を満たすか、誰がどこまで責任を持つかを決める
基本設計: 大きな構成方針を決める
詳細設計: 実装できる具体値へ落とす
実装: 設計を環境へ反映する
検証: 約束どおりに動くか確認する

工程は、難しい言葉を覚えるためのものではありません。

手戻りを減らし、関係者の認識を揃え、安心して作るための順番です。

関連記事

工程の全体像を押さえたあとに読むとつながりやすい記事です。

AWS CloudFormation前編 IaC・YAML・スタック・疎結合（今後公開予定）
AWS構成図をテンプレートで作る手順（今後公開予定）

参考・確認先

この記事はYouTube台本をQiita向けに再構成したものです。AWSの仕様、料金、上限、責任範囲は変わるため、実作業では必ずAWS公式ドキュメントを確認してください。

おわりに

工程名を覚えるだけでなく、「いま何を決める場面か」をそろえると、設計レビューや実装の会話がかなり進めやすくなります。
Wealthy Designでは、Webシステム開発、クラウド活用、AIを使った業務改善に取り組んでいます。

会社の取り組みは、会社サイトにまとめています。
https://wealthy-design.com/