「APサーバはインターネットに公開しつつ、DBサーバはインターネットから完全に隔離したい」——これが実際のAWSシステム設計でよく使われる AP+DB 2層構成 です。

この記事では、AWSコンソール（GUI）のみを使って、カスタムVPCを設計し、パブリックサブネット（APサーバ）とプライベートサブネット（DBサーバ）に分離した2層アーキテクチャをゼロから手動構築するハンズオンを紹介します。

インターネット
  ↓ HTTP(80) / SSH(22)  ← 自分のIPのみ
[インターネットゲートウェイ（my-igw）]
  ↓
[VPC: my-vpc（10.0.0.0/16）]
  │
  ├─ [パブリックサブネット: 10.0.1.0/24]
  │    └── APサーバEC2（my-ap-instance）
  │          ├── Apache（ポート80）   ← インターネットから直接アクセス可
  │          └── my-ap-sg
  │                ↓ SSH(22) / MySQL(3306) ← APサーバSGのみ許可（SG参照）
  └─ [プライベートサブネット: 10.0.2.0/24]
       └── DBサーバEC2（my-db-instance）
             ├── MariaDB（ポート3306）
             ├── パブリックIPなし       ← インターネットから隔離
             └── my-db-sg

このハンズオンで体験できること：

• カスタムVPC・サブネット・インターネットゲートウェイ・ルートテーブルを一から設計・構築
• パブリックサブネット（APサーバ）とプライベートサブネット（DBサーバ）の分離
• DBサーバにパブリックIPを付与せずインターネットから隔離する設計
• APサーバを踏み台（Bastion）としてDBサーバにSSH接続する方法
• S3 VPC Gateway Endpointでプライベートサブネットからパッケージをインストールする方法

このハンズオンのポイント：

Phase 1-3（MySQL）まではデフォルトVPCを使っていましたが、今回はカスタムVPCを一から設計します。実際のAWS本番環境に近いネットワーク設計を体験できます。

この記事は CloudFormation版ハンズオン の比較記事です。
コンソール操作でVPCリソースの依存関係・設定手順を視覚的に学び、CloudFormationとの違いを比較したい方向けです。

-->

キーワード解説

前フェーズとの違い

使用するAWSサービス

注意: EC2を2台同時に稼働させるため、無料枠の消費が2倍になります。ハンズオン後は必ず2台とも削除してください。

構築するリソース一覧

全体の作業順序

ネットワーク系リソースはEC2より先に作成する必要があります。

⓪ 自分のIPアドレスを確認する
      ↓
① キーペアを作成する
      ↓
② IAMロールを作成する
      ↓
③ VPCを作成する
      ↓
④ インターネットゲートウェイを作成・アタッチする
      ↓
⑤ サブネットを作成する（パブリック・プライベート）
      ↓
⑥ ルートテーブルを設定する（S3 VPC Endpoint作成を含む）
      ↓
⑦ セキュリティグループを作成する（APサーバSG → DBサーバSGの順）
      ↓
⑧ APサーバEC2を起動する（パブリックサブネット）
      ↓
⑨ DBサーバEC2を起動する（プライベートサブネット）
      ↓
⑩ 動作確認
      ↓
⑪ リソースを削除する

【重要】⓪ 自分のIPアドレスを確認する

curl https://checkip.amazonaws.com

またはルーター管理画面（http://192.168.0.1 など）の「WAN IPアドレス」で確認します。

控えておく情報: 自分のIPアドレス（例: 203.0.113.1）

① キーペアの作成

APサーバとDBサーバの両方で使用します。1つのキーペアを共用します。

AWSコンソール → EC2 → キーペア → 「キーペアを作成」

C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem

② IAMロールの作成

AWSコンソール → IAM → ロール → 「ロールを作成」

「ロールを作成」をクリック。

③ VPCの作成

AWSコンソール → VPC → 仮想プライベートクラウド → 「お使いのVPC」→ 「VPCを作成」

VPCとは: AWS上に作るプライベートなネットワーク空間。この中にEC2などを置きます。CIDR（サイダー）でIPアドレスの範囲を指定します。10.0.0.0/16 は 10.0.0.0 〜 10.0.255.255 の65536個のIPアドレスを表します。

「VPCを作成」をクリック。

控えておく情報: 作成された VPC ID（vpc-xxxxxxxxxx）

④ インターネットゲートウェイの作成・アタッチ

インターネットゲートウェイ（IGW）とは: VPCとインターネットを接続する出入り口です。これをVPCにアタッチすることで、VPC内のEC2がインターネットと通信できるようになります。

4-1. インターネットゲートウェイを作成する

AWSコンソール → VPC → インターネットゲートウェイ → 「インターネットゲートウェイの作成」

「インターネットゲートウェイの作成」をクリック。

4-2. VPCにアタッチする

作成直後の画面から「アクション」→「VPCにアタッチ」をクリック。

「インターネットゲートウェイのアタッチ」をクリック。

ステータスが 「Attached」 になることを確認します。

⑤ サブネットの作成

サブネットとは: VPC内をさらに分割したネットワークです。パブリックサブネットはインターネットと通信でき、プライベートサブネットはVPC内部とのみ通信します。

AWSコンソール → VPC → サブネット → 「サブネットを作成」

VPC ID で my-vpc を選択します。

5-1. パブリックサブネット

5-2. プライベートサブネット

「新しいサブネットを追加」をクリックして2つ目のサブネットを設定します。

「サブネットを作成」をクリック。

5-3. パブリックサブネットのパブリックIP自動割り当てを有効化

サブネット一覧 → my-public-subnet を選択 → 「アクション」→「サブネットの設定を編集」

「パブリック IPv4 アドレスの自動割り当てを有効化」にチェックを入れる → 「保存」。

APサーバEC2を起動したときに自動でパブリックIPが割り当てられるようになります。プライベートサブネットはこの設定をしません（DBサーバにパブリックIPを付与しない）。

⑥ ルートテーブルの設定

ルートテーブルとは: サブネット内のEC2がパケットを送るときの「経路表」です。パブリックサブネットはインターネット向けのルート（→IGW）を持ち、プライベートサブネットは持ちません。

6-1. パブリックルートテーブルを作成する

AWSコンソール → VPC → ルートテーブル → 「ルートテーブルを作成」

「ルートテーブルを作成」をクリック。

インターネット向けルートを追加します:

my-public-rt を選択 → 「ルート」タブ → 「ルートを編集」→「ルートを追加」

「変更を保存」をクリック。

0.0.0.0/0 とは: 「それ以外のすべての宛先」を意味します。VPC内向けのルートはデフォルトで存在するため、インターネット向けのルートだけ追加すれば OKです。

パブリックサブネットを関連付けます:

my-public-rt の「サブネットの関連付け」タブ → 「サブネットの関連付けを編集」→ my-public-subnet にチェック → 「関連付けを保存」。

6-2. プライベートルートテーブルを作成する

VPC → ルートテーブル → 「ルートテーブルを作成」

「ルートテーブルを作成」をクリック。

インターネット向けルートは追加しません。プライベートサブネットからインターネットへの経路を意図的に持たせないことで、DBサーバをインターネットから完全に隔離します。

プライベートサブネットを関連付けます:

my-private-rt の「サブネットの関連付け」タブ → 「サブネットの関連付けを編集」→ my-private-subnet にチェック → 「関連付けを保存」。

6-3. S3 VPC Gateway Endpointを作成する（重要）

なぜ必要か: プライベートサブネットはインターネットに出られないため、EC2起動時の dnf install でパッケージをダウンロードできません。Amazon Linux 2023のパッケージリポジトリはS3上にあるため、S3だけインターネットを経由せずアクセスできるGateway Endpointを作成することで解決します。Gateway Endpointは無料です。

AWSコンソール → VPC → エンドポイント → 「エンドポイントを作成」

「エンドポイントを作成」をクリック。

確認: my-private-rt の「ルート」タブを開くと、S3向けのルートが自動追加されていることを確認します。

⑦ セキュリティグループの作成

注意: APサーバSGを先に作成します。DBサーバSGがAPサーバSGをSG参照するためです。

7-1. APサーバSGの作成

EC2 → セキュリティグループ → 「セキュリティグループを作成」

インバウンドルール:

アウトバウンドルール: 「すべてのトラフィック / 0.0.0.0/0」があることを確認します。

「セキュリティグループを作成」をクリック。

7-2. DBサーバSGの作成

EC2 → セキュリティグループ → 「セキュリティグループを作成」

インバウンドルール（「ルールを追加」で2つ追加します）:

ルール1: SSH（APサーバ経由の踏み台接続）

ルール2: MySQL（APサーバからのDB接続）

アウトバウンドルール: 「すべてのトラフィック / 0.0.0.0/0」があることを確認します。

「セキュリティグループを作成」をクリック。

⑧ APサーバEC2の起動（パブリックサブネット）

EC2 → インスタンス → 「インスタンスを起動」

8-1. 基本設定

8-2. ネットワーク設定

「ネットワーク設定」→「編集」をクリックして以下を設定します。

8-3. IAMロール・UserDataの設定

「高度な詳細」を開きます。

「ユーザーデータ」に以下を貼り付けます。

#!/bin/bash
dnf update -y
dnf install -y httpd
systemctl start httpd
systemctl enable httpd
cat > /var/www/html/index.html << 'HTMLEOF'
<!DOCTYPE html>
<html>
<head><meta charset="UTF-8"><title>AP Server - Phase 1-4</title></head>
<body>
<h1>AP Server (Public Subnet)</h1>
<p>This AP server is in the PUBLIC subnet and can reach the DB server in the PRIVATE subnet.</p>
</body>
</html>
HTMLEOF

「インスタンスを起動」をクリック。

控えておく情報: APサーバのパブリックIPアドレス

⑨ DBサーバEC2の起動（プライベートサブネット）

EC2 → インスタンス → 「インスタンスを起動」

9-1. 基本設定

9-2. ネットワーク設定

パブリックIPを付与しない: DBサーバはインターネットから直接アクセスされる必要がありません。プライベートサブネットに置き、パブリックIPを持たせないことで、インターネットから完全に隔離します。

9-3. IAMロール・UserDataの設定

「ユーザーデータ」に以下を貼り付けます。

#!/bin/bash
dnf update -y
dnf install -y mariadb105-server mariadb105
systemctl start mariadb
systemctl enable mariadb
sudo mysql -u root << 'SQLEOF'
SET PASSWORD FOR root@localhost = PASSWORD('Admin1234!');
CREATE USER IF NOT EXISTS 'handson'@'%' IDENTIFIED BY 'Handson1234!';
GRANT ALL PRIVILEGES ON *.* TO 'handson'@'%' WITH GRANT OPTION;
CREATE DATABASE IF NOT EXISTS sampledb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
FLUSH PRIVILEGES;
SQLEOF

⑥-3でS3 VPC Endpointを作成済みの場合: dnf install はS3経由で正常に動作します。Endpointを作成せずにEC2を起動した場合はMariaDBがインストールされないため、踏み台SSH接続後に手動で sudo dnf install -y mariadb105-server mariadb105 を実行してください。

「インスタンスを起動」をクリック。

控えておく情報: DBサーバのプライベートIPアドレス（パブリックIPはありません）

インスタンス詳細 → 「プライベート IPv4 アドレス」（例: 10.0.2.xxx）を確認してメモします。

⑩ 動作確認

待機時間: EC2起動後、UserDataの完了まで数分かかります。APサーバは2〜3分、DBサーバは5〜8分待ちます。

10-1. APサーバのWeb確認

ブラウザで以下にアクセスします。

http://（APサーバのパブリックIP）

AP Server (Public Subnet) が表示されれば成功です。

10-2. APサーバへのSSH接続

ssh -i C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem ec2-user@（APパブリックIP）

10-3. キーペアをAPサーバにコピーする（踏み台SSH準備）

APサーバを踏み台としてDBサーバにSSH接続するために、ローカルPCからAPサーバにキーペアをコピーします。

ローカルPCの別ターミナルで実行します:

scp -i C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem ^
  C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem ^
  ec2-user@（APパブリックIP）:~/.ssh/

APサーバ上でキーペアのパーミッションを設定します。

chmod 400 ~/.ssh/my-ec2-2tier-key.pem

10-4. APサーバ経由でDBサーバにSSH接続（踏み台接続）

APサーバのSSHセッションから実行します:

ssh -i ~/.ssh/my-ec2-2tier-key.pem ec2-user@（DBプライベートIP）

[ec2-user@ip-10-0-2-xxx ~]$ のプロンプトが表示されれば踏み台接続成功です。

sudo systemctl status mariadb

# MariaDBに接続
mysql -u root -pAdmin1234!

MariaDBのプロンプトで確認します。

SHOW DATABASES;
EXIT;

DBサーバから切断します。

exit

10-5. APサーバからMySQLに接続（AP→DB通信確認）

APサーバのSSHセッションで実行します。

# mysqlクライアントのインストール
sudo dnf install -y mariadb105

# DBサーバのプライベートIPにMySQL接続
mysql -h （DBプライベートIP） -u handson -pHandson1234! sampledb

接続成功すれば MariaDB [sampledb]> が表示されます。

CREATE TABLE IF NOT EXISTS messages (id INT AUTO_INCREMENT PRIMARY KEY, text VARCHAR(100));
INSERT INTO messages (text) VALUES ('Hello from AP server!');
SELECT * FROM messages;
EXIT;

APサーバから切断します。

exit

⑪ リソースの削除

課金を止めるために、ハンズオン完了後は必ず削除してください。削除する順番が重要です。

CloudFormation版と比較: コンソール版はリソースの依存関係を意識して手動で削除する必要があります。CloudFormation版は delete-stack 1本で全て自動削除できます。

削除順序

1. EC2インスタンスを終了する（2台）

EC2 → インスタンス → my-ap-instance と my-db-instance を選択 → 「インスタンスを終了」

「終了済み」になるまで待ちます（2〜5分）。

2. セキュリティグループを削除する（DBサーバSG → APサーバSGの順）

DBサーバSGがAPサーバSGを参照しているため、DBサーバSGを先に削除します。

① my-db-sg を選択 → 「アクション」→「セキュリティグループを削除」

② my-ap-sg を選択 → 「アクション」→「セキュリティグループを削除」

3. S3 VPC Endpointを削除する

VPC → エンドポイント → my-s3-endpoint を選択 → 「アクション」→「エンドポイントを削除」

4. ルートテーブルの関連付けを解除・削除する

① my-public-rt を選択 → 「サブネットの関連付け」タブ → 「サブネットの関連付けを編集」→ チェックを外す → 「保存」

② my-private-rt も同様に関連付けを解除する

③ my-public-rt を選択 → 「ルート」タブ → 「ルートを編集」→ 0.0.0.0/0 のルートを削除 → 「保存」

④ my-public-rt を選択 → 「アクション」→「ルートテーブルの削除」

⑤ my-private-rt も同様に削除する

5. サブネットを削除する（2つ）

VPC → サブネット → my-public-subnet → 「アクション」→「サブネットを削除」

同様に my-private-subnet も削除します。

6. インターネットゲートウェイをデタッチ・削除する

VPC → インターネットゲートウェイ → my-igw → 「アクション」→「VPCからデタッチ」

デタッチ完了後、「アクション」→「インターネットゲートウェイの削除」。

7. VPCを削除する

VPC → お使いのVPC → my-vpc → 「アクション」→「VPCを削除」

8. IAMロールを削除する

IAM → ロール → my-ec2-2tier-role → 「削除」

9. キーペアを削除する（任意）

EC2 → キーペア → my-ec2-2tier-key → 「削除」

C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem

CloudFormation版との比較

コンソール版で実感できたポイント:

• VPC・IGW・サブネット・ルートテーブルの依存関係が視覚的に理解できる
• プライベートサブネットにEC2を置くとパブリックIPが付かないことを実感できる
• 踏み台接続（APサーバ経由でDBサーバにSSH）の意味と手順が身につく
• S3 VPC Endpointがなければ dnf install が失敗することを体験できる

CloudFormation版でも試してみる: CloudFormationでAP+DB 2層構成（VPC設計）を自動デプロイする手順

トラブルシューティング

まとめ

今回のハンズオンで体験できたこと：

20ステップ以上の手動作業でリソースを一つひとつ作ると、CloudFormationが裏で何を自動化しているかが理解できます。ぜひ次は CloudFormation版 でコマンド1本の差を体感してみてください。

関連記事

-->

The post AWSコンソールでVPC設計からAP+DB 2層構成を構築する手順【踏み台SSH / CloudFormation版との比較付き】 first appeared on CayTech Lab.

「コンソールで20ステップかかったVPC設計をコードで再現したい」——それを実現するのが AWS CloudFormation です。

この記事では、template.yaml 1ファイルにVPC・サブネット・ルートテーブル・セキュリティグループ・EC2（2台）を定義し、コマンド1本でAP+DB 2層構成を一括構築するハンズオンを紹介します。コンソール版（AWSコンソール版ハンズオン）と全く同じ構成を、CloudFormationで自動化します。

ローカル環境（VSCode）
  └── template.yaml + AWS CLI
        ↓ スタック作成（コマンド1本）
AWS環境
  └── VPC（10.0.0.0/16）
        ├── インターネットゲートウェイ
        │
        ├── [パブリックサブネット 10.0.1.0/24]
        │     ├── パブリックルートテーブル（0.0.0.0/0 → IGW）
        │     └── APサーバEC2（Apache / パブリックIP あり）
        │
        └── [プライベートサブネット 10.0.2.0/24]
              ├── プライベートルートテーブル（VPC内のみ）
              ├── S3 VPC Gateway Endpoint（dnf用・無料）
              └── DBサーバEC2（MariaDB / パブリックIP なし）

このハンズオンで体験できること：

• VPC・サブネット・IGW・ルートテーブルを template.yaml 1ファイルで定義する方法
• S3 VPC Gateway Endpoint の DependsOn による起動順序制御
• SubnetId でEC2の配置サブネットを明示する方法
• aws cloudformation create-stack コマンド1本での17リソース一括デプロイ
• delete-stack による複雑な依存関係を持つVPCリソースの一括削除

このハンズオンの特徴：

• コンソール版では20ステップ以上・30〜40分かかった作業が、コマンド1本（8〜12分）で完了
• delete-stack 1本でVPC・サブネット・IGW・RTの依存関係を自動解決して削除

-->

CloudFormation vs コンソール：どれだけ違うか

キーワード解説

前提条件

AWS認証確認:

aws sts get-caller-identity

template.yaml の全文

以下が今回使用する template.yaml の全文です（17リソース）。プロジェクトフォルダ（ec2-2tier-web/）直下に配置します。

⚠️ コピー前に確認: Default: '123.456.78.901/32' の箇所はダミーIPです。このまま使うとスタック作成は成功しますが、SSHもWebもアクセスできません。--parameters でIPを上書きするか（推奨）、Defaultを自分のIPに書き換えてから使ってください。

AWSTemplateFormatVersion: '2010-09-09'
Description: 'EC2 2-tier Architecture (AP + DB) with VPC public/private subnet separation (Phase 1-4)'

Parameters:
  KeyName:
    Type: String
    Default: 'my-ec2-2tier-key'
    Description: Name of an existing EC2 KeyPair

  MyIP:
    Type: String
    Default: '123.456.78.901/32'
    Description: Your IP address to allow SSH and HTTP access (CIDR format e.g. 203.0.113.1/32)

Resources:

  # VPC and Network
  # ============================================================

  # VPC: isolated network space for this hands-on
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: 'my-vpc'

  # Internet Gateway: connects the VPC to the internet
  InternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: Name
          Value: 'my-igw'

  # Attach Internet Gateway to VPC
  IGWAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGateway

  # Public Subnet: AP server goes here (internet accessible)
  PublicSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: 10.0.1.0/24
      AvailabilityZone: !Select [0, !GetAZs '']
      MapPublicIpOnLaunch: true
      Tags:
        - Key: Name
          Value: 'my-public-subnet'

  # Private Subnet: DB server goes here (no direct internet access)
  PrivateSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: 10.0.2.0/24
      AvailabilityZone: !Select [0, !GetAZs '']
      MapPublicIpOnLaunch: false
      Tags:
        - Key: Name
          Value: 'my-private-subnet'

  # Public Route Table: routes internet traffic via Internet Gateway
  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
        - Key: Name
          Value: 'my-public-rt'

  # Default route for public subnet: all traffic -> Internet Gateway
  PublicRoute:
    Type: AWS::EC2::Route
    DependsOn: IGWAttachment
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway

  # Associate public subnet with public route table
  PublicSubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTable

  # Private Route Table: no internet route (local traffic only)
  PrivateRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
        - Key: Name
          Value: 'my-private-rt'

  # Associate private subnet with private route table
  PrivateSubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PrivateSubnet
      RouteTableId: !Ref PrivateRouteTable

  # S3 VPC Gateway Endpoint: allows private subnet to reach S3 (for dnf package downloads)
  # Gateway endpoints are FREE - no hourly charge
  S3VPCEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      VpcId: !Ref VPC
      ServiceName: !Sub 'com.amazonaws.${AWS::Region}.s3'
      VpcEndpointType: Gateway
      RouteTableIds:
        - !Ref PrivateRouteTable

  # ============================================================
  # IAM
  # ============================================================

  # IAM Role: allows EC2 to use Session Manager
  EC2Role:
    Type: AWS::IAM::Role
    Properties:
      RoleName: 'my-ec2-2tier-role'
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: 'sts:AssumeRole'
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
      Tags:
        - Key: Name
          Value: 'my-ec2-2tier-role'

  EC2InstanceProfile:
    Type: AWS::IAM::InstanceProfile
    Properties:
      InstanceProfileName: 'my-ec2-2tier-profile'
      Roles:
        - !Ref EC2Role

  # ============================================================
  # Security Groups
  # ============================================================

  # AP Server Security Group: SSH and HTTP from MyIP
  APSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: 'my AP server SG (public subnet)'
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: !Ref MyIP
          Description: SSH from my IP
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: !Ref MyIP
          Description: HTTP from my IP
      Tags:
        - Key: Name
          Value: 'my-ap-sg'

  # DB Server Security Group: MySQL from AP SG only, SSH from AP SG (via bastion)
  DBSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: 'my DB server SG (private subnet)'
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          SourceSecurityGroupId: !GetAtt APSecurityGroup.GroupId
          Description: SSH from AP server only (bastion access)
        - IpProtocol: tcp
          FromPort: 3306
          ToPort: 3306
          SourceSecurityGroupId: !GetAtt APSecurityGroup.GroupId
          Description: MySQL from AP server only (SG-to-SG control)
      Tags:
        - Key: Name
          Value: 'my-db-sg'

  # ============================================================
  # EC2 Instances
  # ============================================================

  # AP Server: Apache in public subnet
  APInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: '{{resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64}}'
      InstanceType: t2.micro
      KeyName: !Ref KeyName
      SubnetId: !Ref PublicSubnet
      SecurityGroupIds:
        - !GetAtt APSecurityGroup.GroupId
      IamInstanceProfile: !Ref EC2InstanceProfile
      UserData:
        Fn::Base64: |
          #!/bin/bash
          dnf update -y
          dnf install -y httpd
          systemctl start httpd
          systemctl enable httpd
          cat > /var/www/html/index.html << 'HTMLEOF'
          <!DOCTYPE html>
          <html>
          <head><meta charset="UTF-8"><title>AP Server - Phase 1-4</title></head>
          <body>
          <h1>AP Server (Public Subnet)</h1>
          <p>This AP server is in the PUBLIC subnet and can reach the DB server in the PRIVATE subnet.</p>
          </body>
          </html>
          HTMLEOF
      Tags:
        - Key: Name
          Value: 'my-ap-instance'

  # DB Server: MariaDB in private subnet (no public IP)
  DBInstance:
    Type: AWS::EC2::Instance
    DependsOn:
      - S3VPCEndpoint
      - PrivateSubnetRouteTableAssociation
    Properties:
      ImageId: '{{resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64}}'
      InstanceType: t2.micro
      KeyName: !Ref KeyName
      SubnetId: !Ref PrivateSubnet
      SecurityGroupIds:
        - !GetAtt DBSecurityGroup.GroupId
      IamInstanceProfile: !Ref EC2InstanceProfile
      UserData:
        Fn::Base64: |
          #!/bin/bash
          dnf update -y
          dnf install -y mariadb105-server mariadb105
          systemctl start mariadb
          systemctl enable mariadb
          sudo mysql -u root << 'SQLEOF'
          SET PASSWORD FOR root@localhost = PASSWORD('Admin1234!');
          CREATE USER IF NOT EXISTS 'handson'@'%' IDENTIFIED BY 'Handson1234!';
          GRANT ALL PRIVILEGES ON *.* TO 'handson'@'%' WITH GRANT OPTION;
          CREATE DATABASE IF NOT EXISTS sampledb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
          FLUSH PRIVILEGES;
          SQLEOF
      Tags:
        - Key: Name
          Value: 'my-db-instance'

Outputs:
  VPCId:
    Description: VPC ID
    Value: !Ref VPC

  APPublicIP:
    Description: AP server public IP (open in browser or SSH)
    Value: !GetAtt APInstance.PublicIp

  DBPrivateIP:
    Description: DB server private IP (connect via AP server bastion)
    Value: !GetAtt DBInstance.PrivateIp

  WebsiteURL:
    Description: AP server website URL
    Value: !Sub 'http://${APInstance.PublicIp}'

  APSSHCommand:
    Description: SSH command to AP server
    Value: !Sub 'ssh -i C:\Users\username\.ssh\${KeyName}.pem ec2-user@${APInstance.PublicIp}'

  DBSSHCommand:
    Description: SSH command to DB server (run this FROM the AP server)
    Value: !Sub 'ssh -i ~/.ssh/${KeyName}.pem ec2-user@${DBInstance.PrivateIp}'

  MySQLConnectCommand:
    Description: MySQL connect command (run this FROM the AP server)
    Value: !Sub 'mysql -h ${DBInstance.PrivateIp} -u handson -pHandson1234! sampledb'

template.yaml の重要ポイント:

1. VpcId を指定した SecurityGroup

カスタムVPCを使う場合は VpcId を明示します。VpcId を指定することで !GetAtt APSecurityGroup.GroupId が確実にSG IDを返します。

APSecurityGroup:
  Type: AWS::EC2::SecurityGroup
  Properties:
    VpcId: !Ref VPC      # ← カスタムVPCを指定（必須）

DBSecurityGroup:
  SecurityGroupIngress:
    - SourceSecurityGroupId: !GetAtt APSecurityGroup.GroupId  # ← !Refではなく!GetAtt

2. S3 VPC Gateway Endpoint（無料）

プライベートサブネットのEC2は直接インターネットに出られませんが、Amazon Linux 2023のパッケージリポジトリはS3上にあります。S3 VPC Gateway EndpointをプライベートルートテーブルにアタッチするとS3経由で dnf install が動作します。

S3VPCEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcEndpointType: Gateway     # Gatewayタイプは無料
    ServiceName: !Sub 'com.amazonaws.${AWS::Region}.s3'
    RouteTableIds:
      - !Ref PrivateRouteTable   # プライベートRTにS3ルートが追加される

3. DBInstance の DependsOn

DBサーバEC2のUserDataが dnf install を実行するとき、S3 VPC Endpointが有効になっている必要があります。

DBInstance:
  DependsOn:
    - S3VPCEndpoint
    - PrivateSubnetRouteTableAssociation

4. SubnetId でサブネットを指定

EC2インスタンスがどのサブネットに配置されるかを明示します。

APInstance:
  SubnetId: !Ref PublicSubnet   # パブリックサブネットに配置

DBInstance:
  SubnetId: !Ref PrivateSubnet  # プライベートサブネットに配置

構築されるリソース一覧（17個）:

作業順序

⓪ 自分のIPアドレスを確認する
      ↓
① キーペアを作成する（コンソールで実施）
      ↓
② プロジェクトフォルダに移動する
      ↓
③ スタックを作成する（aws cloudformation create-stack）
      ↓
④ 作成完了・Outputsを確認する
      ↓
⑤ 動作確認（Web・踏み台SSH・MySQL接続）
      ↓
⑥ スタックを削除する（aws cloudformation delete-stack）

⓪ 自分のIPアドレスを確認する

curl https://checkip.amazonaws.com

控えておく情報: 自分のIPアドレス（例: 203.0.113.1）

① キーペアの作成（コンソールで実施）

キーペアのみコンソールで作成します。

AWSコンソール → EC2 → キーペア → 「キーペアを作成」

C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem

② プロジェクトフォルダに移動する

cd C:\my-aws\aws-learning-projects\ec2-2tier-web

dir template.yaml

③ スタックの作成

203.0.113.1 は⓪で確認した自分のIPアドレスに置き換えてください。

aws cloudformation create-stack ^
  --stack-name my-ec2-2tier-stack ^
  --template-body file://template.yaml ^
  --region ap-northeast-1 ^
  --capabilities CAPABILITY_NAMED_IAM ^
  --parameters ^
    ParameterKey=KeyName,ParameterValue=my-ec2-2tier-key ^
    ParameterKey=MyIP,ParameterValue=203.0.113.1/32

各オプションの説明:

成功するとStackIdが表示されます。

{
    "StackId": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/my-ec2-2tier-stack/xxxxx"
}

④ 作成完了・Outputsの確認

スタック作成完了まで約8〜12分かかります（VPCリソース×10個 + EC2×2台 + MariaDBインストールの時間）。

作成状況の確認

aws cloudformation describe-stacks ^
  --stack-name my-ec2-2tier-stack ^
  --query "Stacks[0].StackStatus" ^
  --output text

Outputs の確認

aws cloudformation describe-stacks ^
  --stack-name my-ec2-2tier-stack ^
  --query "Stacks[0].Outputs" ^
  --output table

以下のような出力が表示されます。

--------------------------------------------------------------------------------------
|                                  DescribeStacks                                    |
+--------------------+---------------------------------------------------------------+
|  OutputKey         |  OutputValue                                                  |
+--------------------+---------------------------------------------------------------+
|  VPCId             |  vpc-xxxxxxxxxx                                              |
|  APPublicIP        |  x.x.x.x                                                    |
|  DBPrivateIP       |  10.0.2.xxx   ← APサーバからの接続に使用                    |
|  WebsiteURL        |  http://x.x.x.x                                             |
|  APSSHCommand      |  ssh -i ...pem ec2-user@x.x.x.x                            |
|  DBSSHCommand      |  ssh -i ~/.ssh/...pem ec2-user@10.0.2.xxx                  |
|  MySQLConnectCommand| mysql -h 10.0.2.xxx -u handson -pHandson1234! sampledb     |
+--------------------+---------------------------------------------------------------+

控えておく情報:

• APPublicIP: APサーバのパブリックIP
• DBPrivateIP: DBサーバのプライベートIP（10.0.2.xxx 形式）
• APSSHCommand: APサーバへのSSHコマンド
• DBSSHCommand: APサーバからDBサーバへのSSHコマンド
• MySQLConnectCommand: APサーバから実行するMySQL接続コマンド

⑤ 動作確認

5-1. APサーバのWeb確認

WebsiteURL をブラウザで開きます。AP Server (Public Subnet) が表示されれば成功です。

5-2. APサーバへのSSH接続

APSSHCommand を実行します（パスを実際のパスに修正します）。

ssh -i C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem ec2-user@（APPublicIP）

5-3. キーペアをAPサーバにコピーする（踏み台SSH準備）

ローカルPCの別ターミナルで実行します:

scp -i C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem ^
  C:\Users\ユーザー名\.ssh\my-ec2-2tier-key.pem ^
  ec2-user@（APPublicIP）:~/.ssh/

APサーバのSSHセッションでパーミッションを設定します。

chmod 400 ~/.ssh/my-ec2-2tier-key.pem

5-4. APサーバ経由でDBサーバにSSH接続（踏み台接続）

APサーバのSSHセッションから実行します:

ssh -i ~/.ssh/my-ec2-2tier-key.pem ec2-user@（DBPrivateIP）

[ec2-user@ip-10-0-2-xxx ~]$ が表示されれば踏み台接続成功です。

# DBサーバ上でMariaDBの状態を確認
sudo systemctl status mariadb

# MariaDBに接続
mysql -u root -pAdmin1234! -e "SHOW DATABASES;"

exit

5-5. APサーバからMySQLに接続（AP→DB通信確認）

APサーバのSSHセッションに戻り、MySQLConnectCommand をそのまま実行します。

# mysqlクライアントをインストール
sudo dnf install -y mariadb105

# OutputsのMySQLConnectCommandをそのまま使う
mysql -h （DBPrivateIP） -u handson -pHandson1234! sampledb

CREATE TABLE IF NOT EXISTS messages (id INT AUTO_INCREMENT PRIMARY KEY, text VARCHAR(100));
INSERT INTO messages (text) VALUES ('Hello from AP server!');
SELECT * FROM messages;
EXIT;

exit

⑥ スタックの削除

課金を止めるために、ハンズオン完了後は必ず削除してください。

CloudFormationはVPC・サブネット・IGW・RT・SG・EC2の依存関係を自動解決して正しい順序で削除します。

aws cloudformation delete-stack ^
  --stack-name my-ec2-2tier-stack ^
  --region ap-northeast-1

削除完了まで約8〜12分かかります。

aws cloudformation describe-stacks ^
  --stack-name my-ec2-2tier-stack ^
  --query "Stacks[0].StackStatus" ^
  --output text

削除完了の確認（以下のエラーが表示されれば削除完了）。

aws cloudformation describe-stacks ^
  --stack-name my-ec2-2tier-stack ^
  --region ap-northeast-1

An error occurred (ValidationError) when calling the DescribeStacks operation:
Stack with id my-ec2-2tier-stack does not exist

キーペアは手動で削除します。

EC2 → キーペア → my-ec2-2tier-key → 「削除」

コンソール版との比較

コンソール版で20ステップ以上かかった作業が、CloudFormationでは template.yaml に定義されています。

トラブルシューティング

まとめ

今回のハンズオンで実現できたこと：

CloudFormationのメリットを実感できたポイント

• コンソール版では20ステップ以上・30〜40分かかった作業がコマンド1本（8〜12分）で完了
• VPC・サブネット・RT・SGの複雑な削除順序をCloudFormationが自動管理
• template.yaml をGitで管理することで、ネットワーク設計の変更履歴が残せる

コンソール版と比較してみる

CloudFormationが裏で何をやっているか、同じ構成をAWSコンソールのみで構築する手順をまとめました。VPCリソースの作成・削除順序や依存関係を視覚的に確認できます。

AWSコンソールでVPC設計からAP+DB 2層構成を構築する手順

関連記事

-->

The post CloudFormationでAP+DB 2層構成（VPC設計）を自動デプロイする手順【踏み台SSH / コンソール版との比較付き】 first appeared on CayTech Lab.

「EC2サーバでデータベースを動かしたい」「EC2同士の通信をセキュアに制御したい」——そのステップがこのハンズオンです。

この記事では、AWSコンソール（GUI）のみを使って、MySQL互換のDBサーバー（MariaDB）が動作するEC2インスタンスをゼロから手動構築するハンズオンを紹介します。

インターネット
  ↓ SSH(22)              ← 自分のIPのみ
  ↓ MySQL(3306)          ← 自分のIPのみ（初期テスト用）
my-ec2-mysql-db-sg（DBサーバSG）
  ↓ MySQL(3306)          ← my-ec2-mysql-client-sg に属するEC2のみ ★SG参照
EC2インスタンス（DBサーバ）       EC2インスタンス（クライアント）
  └── MariaDB 10.5              └── mysqlコマンド（接続テスト用）
        └── sampledb（DB）             ↑
                           my-ec2-mysql-client-sg（クライアントSG）
                             ↓ SSH(22) ← 自分のIPのみ
                           インターネット

このハンズオンで体験できること：

• セキュリティグループの SG参照（SG-to-SG） による EC2間通信制御
• EC2サーバへの MariaDB（MySQL互換）インストールと初期設定
• 2台のEC2（DBサーバ + クライアント）を使った実際のDB接続確認
• IPアドレス指定 vs SG参照の違いを体感

このハンズオンのポイント：

DBサーバのMySQLポート（3306）を「特定のIPアドレス」ではなく「特定のセキュリティグループに属するEC2」だけに開放します。これが SG参照（SG-to-SG） と呼ばれる設定方法で、IPが変わっても自動的に制御できる、本番環境でも使われるセキュアな設計です。

この記事は CloudFormation版ハンズオン の比較記事です。
コンソール操作でSG参照の仕組みを視覚的に学び、CloudFormationとの違いを比較したい方向けです。

-->

キーワード解説

IPアドレス指定 vs SG参照

今回のハンズオンで学ぶ「SG参照」がなぜ重要かを確認します。

前フェーズとの比較

使用するAWSサービス

注意: EC2を2台同時に稼働させるため、無料枠の消費が2倍になります。ハンズオン後は必ず2台とも削除してください。

構築するリソース

全体の作業順序

依存関係があるため、必ずこの順番で作成します。

⓪ 自分のIPアドレスを確認する（重要）
      ↓
① キーペアを作成する
      ↓
② IAMロールを作成する
      ↓
③ クライアントSGを作成する（先に作成する必要がある）
      ↓
④ DBサーバSGを作成する（③のSGを参照する）
      ↓
⑤ DBサーバEC2を起動する
      ↓
⑥ クライアントEC2を起動する
      ↓
⑦ 動作確認（DBサーバ・クライアント）
      ↓
⑧ リソースを削除する

【重要】⓪ 自分のIPアドレスを確認する

セキュリティグループで自分のIPだけを許可するために、正確なIPアドレスを事前に確認します。

方法A: ルーター管理画面で確認（推奨）

1. ブラウザで以下のURLにアクセスします（ルーターによって異なります）

   http://192.168.0.1  または  http://192.168.1.1

2. 「ネットワークマップ」または「インターネット」項目を開く
3. **「インターネットIPアドレス」または「WAN IPアドレス」**の値を控えます

方法B: コマンドで確認

curl https://checkip.amazonaws.com

控えておく情報: 自分のIPアドレス（例: 203.0.113.1）

① キーペアの作成

DBサーバとクライアントEC2の両方のSSH接続に使います。1つのキーペアを共用します。

AWSコンソール → EC2 → ネットワーク＆セキュリティ → キーペア → 「キーペアを作成」

「キーペアを作成」をクリックすると my-ec2-mysql-key.pem がダウンロードされます。

C:\Users\ユーザー名\.ssh\my-ec2-mysql-key.pem

注意: .pem ファイルは再ダウンロードできません。紛失した場合は新しいキーペアを作成する必要があります。

② IAMロールの作成

AWSコンソール → IAM → ロール → 「ロールを作成」

「ロールを作成」をクリック。

③ クライアントSGの作成

なぜ先に作るか: DBサーバSGの設定でクライアントSGを「参照先」として指定する必要があるため、先に作成しておく必要があります。

AWSコンソール → EC2 → セキュリティグループ → 「セキュリティグループを作成」

インバウンドルール（「ルールを追加」）:

アウトバウンドルールを確認します:

SG作成画面の「アウトバウンドルール」欄に以下のルールが自動設定されていることを確認します。

重要: このアウトバウンドルールがないとEC2がインターネットに出られず、dnf install でパッケージをダウンロードできなくなります。自動設定されていない場合は「ルールを追加」で追加してください。

「セキュリティグループを作成」をクリック。

④ DBサーバSGの作成（SG参照の設定）

AWSコンソール → EC2 → セキュリティグループ → 「セキュリティグループを作成」

インバウンドルール（「ルールを追加」で3ルール追加します）:

ルール1: SSH（管理用）

ルール2: MySQL（クライアントSGからの接続）← このハンズオンの核心

ここがSG参照: ソースとして「IPアドレス」ではなく「セキュリティグループ」を指定しています。my-ec2-mysql-client-sg に属するEC2からのMySQL接続のみを許可し、インターネットからは接続できません。

ルール3: MySQL（自分のIPからの接続）← 初期テスト・確認用

アウトバウンドルールを確認します:

「アウトバウンドルール」欄に「すべてのトラフィック / 0.0.0.0/0」が設定されていることを確認します（クライアントSGと同様）。

「セキュリティグループを作成」をクリック。

⑤ DBサーバEC2の起動

AWSコンソール → EC2 → インスタンス → 「インスタンスを起動」

5-1. 基本設定

5-2. セキュリティグループの設定

「ネットワーク設定」→「既存のセキュリティグループを選択する」→ my-ec2-mysql-db-sg を選択します。

注意: 「セキュリティグループを作成する」ではなく「既存のセキュリティグループを選択する」を選びます。④で作成済みの my-ec2-mysql-db-sg を指定します。

5-3. IAMロールの設定

「高度な詳細」→「IAM インスタンスプロファイル」→ my-ec2-mysql-role を選択します。

5-4. UserDataの設定（MariaDBの自動インストール）

「高度な詳細」の一番下「ユーザーデータ」に以下を貼り付けます。

#!/bin/bash
dnf update -y
dnf install -y mariadb105-server mariadb105

systemctl start mariadb
systemctl enable mariadb

sudo mysql -u root << 'SQLEOF'
SET PASSWORD FOR root@localhost = PASSWORD('Admin1234!');
CREATE USER IF NOT EXISTS 'handson'@'%' IDENTIFIED BY 'Handson1234!';
GRANT ALL PRIVILEGES ON *.* TO 'handson'@'%' WITH GRANT OPTION;
CREATE DATABASE IF NOT EXISTS sampledb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
FLUSH PRIVILEGES;
SQLEOF

各コマンドの説明:

sudo mysql -u root について: MariaDB インストール直後の root は unix_socket 認証（OSのrootユーザーとして接続）が有効になっています。-p でパスワードを指定すると ERROR 1698 Access denied になるため、初回設定は sudo mysql -u root（パスワードなし）で接続します。

パスワードについて: このハンズオンでは学習用として Admin1234! / Handson1234! を使用しています。本番環境では必ず強力なパスワードに変更してください。

5-5. インスタンスを起動する

「インスタンスを起動」をクリック。起動後2〜3分待ちます。

控えておく情報:

• DBサーバのパブリックIPアドレス
• DBサーバのプライベートIPアドレス（クライアントEC2からの接続に使用）

インスタンス詳細 → 「プライベート IPv4 アドレス」を確認してメモします。

⑥ クライアントEC2の起動

AWSコンソール → EC2 → インスタンス → 「インスタンスを起動」

6-1. 基本設定

6-2. セキュリティグループの設定

「ネットワーク設定」→「既存のセキュリティグループを選択する」→ my-ec2-mysql-client-sg を選択します。

6-3. IAMロールの設定

「高度な詳細」→「IAM インスタンスプロファイル」→ my-ec2-mysql-role を選択します。

6-4. UserDataの設定（mysqlクライアントのインストール）

#!/bin/bash
dnf update -y
dnf install -y mariadb105

mysqlコマンド（クライアントツール）のみをインストールします。DBサーバ機能（mariadb105-server）はインストールしません。

6-5. インスタンスを起動する

「インスタンスを起動」をクリック。起動完了まで約2〜3分待ちます。

控えておく情報: クライアントEC2のパブリックIPアドレス

⑦ 動作確認

7-1. DBサーバの動作確認

DBサーバにSSH接続します。

ssh -i C:\Users\ユーザー名\.ssh\my-ec2-mysql-key.pem ec2-user@（DBサーバのパブリックIP）

接続後に以下を実行します。

sudo systemctl status mariadb

# MariaDBのバージョン確認
mysql --version

# rootでログイン（パスワード: Admin1234!）
mysql -u root -pAdmin1234!

MariaDBのプロンプト（MariaDB [(none)]>）が表示されたら以下を実行します。

-- ユーザー一覧を確認
SELECT User, Host FROM mysql.user;

-- データベース一覧を確認（sampledb が存在することを確認）
SHOW DATABASES;

-- sampledbに接続
USE sampledb;

-- テスト用のテーブルを作成
CREATE TABLE users (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(50) NOT NULL,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

-- データを挿入
INSERT INTO users (name) VALUES ('Alice'), ('Bob'), ('Charlie');

-- データを確認
SELECT * FROM users;

-- MariaDBから切断
EXIT;

DBサーバから切断します。

exit

7-2. SG参照の確認：クライアントEC2からMySQL接続

クライアントEC2に接続します。

ssh -i C:\Users\ユーザー名\.ssh\my-ec2-mysql-key.pem ec2-user@（クライアントのパブリックIP）

クライアントEC2からDBサーバのプライベートIPに向けてMySQL接続します。

# DBサーバのプライベートIPに接続（XXX.XXX.XXX.XXX はDBサーバのプライベートIP）
mysql -h XXX.XXX.XXX.XXX -u handson -pHandson1234! sampledb

接続成功すると MariaDB [sampledb]> が表示されます。

-- DBサーバで作成したデータが見えることを確認
SELECT * FROM users;

EXIT;

exit

プライベートIPを使う理由: EC2間の通信は同じVPC内なのでプライベートIPで通信できます。パブリックIPを使うとインターネットを経由してしまい、セキュリティ上も効率上も好ましくありません。

7-3. SG参照の効果を確認する（任意・スキップ可）

前提: ローカルPCに mysql クライアントがインストールされている場合のみ実施します。7-2でクライアントEC2からの接続が成功していれば、このハンズオンの学習目的（SG参照によるEC2間通信制御）は達成済みです。

ローカルPCに mysql コマンドがある場合、ローカルターミナルで以下を実行します。

mysql -h （DBサーバのパブリックIP） -u handson -pHandson1234! sampledb

補足: 今回のSGにはルール3（自分のIPからのMySQL許可）を追加しているため接続できます。ルール3を削除すると、インターネットからの接続は完全に遮断されます。本番環境ではルール3を削除し、クライアントSG参照のみにするのがベストプラクティスです。

⑧ リソースの削除

課金を止めるために、ハンズオン完了後は必ず削除してください。削除する順番が重要です。

1. EC2インスタンスを終了する（2台）

EC2 → インスタンス → my-ec2-mysql-db-instance と my-ec2-mysql-client-instance を両方選択 → 「インスタンスの状態」→「インスタンスを終了」

状態が「終了済み」になるまで待ちます（2〜5分）。

2. セキュリティグループを削除する（2つ）

注意: 先にDBサーバSGを削除します。クライアントSGはDBサーバSGから参照されているため、先にDBサーバSGを削除しないとエラーになります。

① DBサーバSGを先に削除します:

EC2 → セキュリティグループ → my-ec2-mysql-db-sg を選択 → 「アクション」→「セキュリティグループを削除」

② クライアントSGを削除します:

EC2 → セキュリティグループ → my-ec2-mysql-client-sg を選択 → 「アクション」→「セキュリティグループを削除」

3. IAMロールを削除する

IAM → ロール → my-ec2-mysql-role を選択 → 「削除」→ ロール名を入力して確認

4. キーペアを削除する（任意）

EC2 → キーペア → my-ec2-mysql-key を選択 → 「アクション」→「削除」

ローカルの .pem ファイルも手動で削除します。

C:\Users\ユーザー名\.ssh\my-ec2-mysql-key.pem

CloudFormation版との比較

コンソール版を体験したら、次は同じ構成をCloudFormation（コード）で再現してみましょう。特にSGの依存関係管理が自動化される点を体験できます。

コンソール版で実感できたポイント:

• SGを削除する際にDBサーバSG → クライアントSGの順番が必要なことを体験できる
• SG参照の設定でソースにIPではなくSGを指定する操作の意味が視覚的に理解できる
• プライベートIPで通信している様子を直接確認できる

CloudFormation版でも試してみる: EC2サーバ構築をIaC化：CloudFormationでEC2 MySQLのDBサーバを自動デプロイする手順

トラブルシューティング

まとめ

今回のハンズオンで体験できたこと：

SG参照を手動で設定・確認することで、CloudFormationが裏で何を自動化しているかが理解できます。ぜひ次は CloudFormation版 で同じ構成をコードで再現してみてください。

関連記事

-->

The post EC2サーバ構築ハンズオン：AWSコンソールでEC2 MySQLのDBサーバを構築する手順【SG参照 / CloudFormation版との比較付き】 first appeared on CayTech Lab.

「コンソールで手動構築したSG参照の構成を、コードで再現したい」——それを実現するのが AWS CloudFormation です。

この記事では、template.yaml 1ファイルにリソース構成を定義し、コマンド1本でEC2 MySQL（MariaDB）環境を一括構築するハンズオンを紹介します。コンソール版（AWSコンソール版ハンズオン）と全く同じ構成を、CloudFormationで自動化します。

ローカル環境（VSCode）
  └── template.yaml + AWS CLI
        ↓ スタック作成（コマンド1本）
AWS環境
  ├── IAMロール（SSM接続用）
  ├── ClientSecurityGroup（クライアントSG）
  │     └── 適用先: クライアントEC2
  ├── DBSecurityGroup（DBサーバSG）
  │     ├── MySQL(3306) ← ClientSecurityGroup を参照  ★SG参照
  │     └── 適用先: DBサーバEC2
  ├── DBサーバEC2（MariaDB）
  └── クライアントEC2（mysqlコマンド）

このハンズオンで体験できること：

• SG参照（SG-to-SG）を SourceSecurityGroupId でtemplate.yamlに記述する方法
• 2台のEC2・2つのSGを template.yaml 1ファイルで一括管理
• aws cloudformation create-stack コマンド1本での全リソース一括デプロイ
• delete-stack によるSGの依存関係を自動解決した一括削除

このハンズオンの特徴：

• コンソール版では順番を意識しながら手動で作成・削除していたSGの依存関係を、CloudFormationが自動管理
• 2台分のEC2を並列で起動するため、コンソール版より短時間で構築完了

-->

CloudFormation vs コンソール：どれだけ違うか

キーワード解説

前提条件

AWS認証確認:

aws sts get-caller-identity

アカウントIDが表示されれば認証設定済みです。

template.yaml の全文

以下が今回使用する template.yaml の全文です。プロジェクトフォルダ（ec2-mysql-db/）直下に配置します。

⚠️ コピー前に確認: Default: '123.456.78.901/32' の箇所はダミーIPです。このまま使うとスタック作成は成功しますが、SSHもMySQLもアクセスできません。--parameters でIPを上書きするか（推奨）、Defaultを自分のIPに書き換えてから使ってください。

AWSTemplateFormatVersion: '2010-09-09'
Description: 'EC2 + MySQL (MariaDB) DB Server Hands-on (Phase 1-3) - SG-to-SG inter-EC2 communication control'

Parameters:
  KeyName:
    Type: String
    Default: 'my-ec2-mysql-key'
    Description: Name of an existing EC2 KeyPair

  MyIP:
    Type: String
    Default: '123.456.78.901/32'
    Description: Your IP address to allow SSH and MySQL access (CIDR format e.g. 203.0.113.1/32)

Resources:
  EC2Role:
    Type: AWS::IAM::Role
    Properties:
      RoleName: 'my-ec2-mysql-role'
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: 'sts:AssumeRole'
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
      Tags:
        - Key: Name
          Value: 'my-ec2-mysql-role'

  # Instance Profile: wrapper that attaches the IAM role to EC2
  EC2InstanceProfile:
    Type: AWS::IAM::InstanceProfile
    Properties:
      InstanceProfileName: 'my-ec2-mysql-profile'
      Roles:
        - !Ref EC2Role

  # Client Security Group: attached to the AP server (client side)
  # The DB server SG references this SG to allow MySQL access only from this group
  ClientSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: 'my MySQL client SG (AP server role)'
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: !Ref MyIP
          Description: SSH from my IP
      Tags:
        - Key: Name
          Value: 'my-ec2-mysql-client-sg'

  # DB Server Security Group: allows MySQL ONLY from the client SG (not from the internet)
  # This is the key concept of SG-to-SG inter-EC2 communication control
  DBSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: 'my MySQL DB server SG'
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: !Ref MyIP
          Description: SSH from my IP (admin only)
        - IpProtocol: tcp
          FromPort: 3306
          ToPort: 3306
          SourceSecurityGroupId: !GetAtt ClientSecurityGroup.GroupId
          Description: MySQL from client SG only (EC2-to-EC2 control - NOT open to internet)
        - IpProtocol: tcp
          FromPort: 3306
          ToPort: 3306
          CidrIp: !Ref MyIP
          Description: MySQL from my IP (for initial testing from local)
      Tags:
        - Key: Name
          Value: 'my-ec2-mysql-db-sg'

  # DB Server EC2: MariaDB (MySQL compatible) installed via UserData
  DBInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: '{{resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64}}'
      InstanceType: t2.micro
      KeyName: !Ref KeyName
      SecurityGroupIds:
        - !Ref DBSecurityGroup
      IamInstanceProfile: !Ref EC2InstanceProfile
      # UserData: install MariaDB and configure initial users and database
      UserData:
        Fn::Base64: |
          #!/bin/bash
          dnf update -y
          dnf install -y mariadb105-server mariadb105

          systemctl start mariadb
          systemctl enable mariadb

          sudo mysql -u root << 'SQLEOF'
          SET PASSWORD FOR root@localhost = PASSWORD('Admin1234!');
          CREATE USER IF NOT EXISTS 'handson'@'%' IDENTIFIED BY 'Handson1234!';
          GRANT ALL PRIVILEGES ON *.* TO 'handson'@'%' WITH GRANT OPTION;
          CREATE DATABASE IF NOT EXISTS sampledb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
          FLUSH PRIVILEGES;
          SQLEOF
      Tags:
        - Key: Name
          Value: 'my-ec2-mysql-db-instance'

  # Client EC2: represents the AP server - has mysql client installed to test DB connection
  ClientInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: '{{resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64}}'
      InstanceType: t2.micro
      KeyName: !Ref KeyName
      SecurityGroupIds:
        - !Ref ClientSecurityGroup
      IamInstanceProfile: !Ref EC2InstanceProfile
      # UserData: install mysql client only (no server)
      UserData:
        Fn::Base64: |
          #!/bin/bash
          dnf update -y
          dnf install -y mariadb105
      Tags:
        - Key: Name
          Value: 'my-ec2-mysql-client-instance'

Outputs:
  DBInstanceId:
    Description: DB server EC2 Instance ID
    Value: !Ref DBInstance

  DBPublicIP:
    Description: DB server public IP (SSH access for admin)
    Value: !GetAtt DBInstance.PublicIp

  DBPrivateIP:
    Description: DB server private IP (use this to connect from client EC2)
    Value: !GetAtt DBInstance.PrivateIp

  ClientInstanceId:
    Description: Client EC2 Instance ID
    Value: !Ref ClientInstance

  ClientPublicIP:
    Description: Client EC2 public IP (SSH to test DB connection)
    Value: !GetAtt ClientInstance.PublicIp

  DBSSHCommand:
    Description: SSH command to connect to DB server
    Value: !Sub 'ssh -i C:\Users\username\.ssh\${KeyName}.pem ec2-user@${DBInstance.PublicIp}'

  ClientSSHCommand:
    Description: SSH command to connect to client EC2
    Value: !Sub 'ssh -i C:\Users\username\.ssh\${KeyName}.pem ec2-user@${ClientInstance.PublicIp}'

  MySQLConnectCommand:
    Description: MySQL connect command (run this from client EC2)
    Value: !Sub 'mysql -h ${DBInstance.PrivateIp} -u handson -pHandson1234! sampledb'

SG参照の書き方：IPアドレス指定との違い:

SecurityGroupIngress:

  # 通常のIPアドレス指定（前回までのやり方）
  - IpProtocol: tcp
    FromPort: 22
    ToPort: 22
    CidrIp: !Ref MyIP           # ← IPアドレスを指定

  # SG参照（このハンズオンの核心）
  - IpProtocol: tcp
    FromPort: 3306
    ToPort: 3306
    SourceSecurityGroupId: !GetAtt ClientSecurityGroup.GroupId  # ← SGのIDを取得
    Description: MySQL from client SG only (EC2-to-EC2 control)

!Ref vs !GetAtt ... .GroupId の違い: VpcId を明示していないSGに対して !Ref するとSGの名前が返るため SourceSecurityGroupId（IDを期待）でエラーになります。!GetAtt ClientSecurityGroup.GroupId を使うことで常にSGのID（sg-xxx）を確実に取得できます。

構築されるリソースと論理ID:

作業順序

⓪ 自分のIPアドレスを確認する
      ↓
① キーペアを作成する（コンソールで実施）
      ↓
② プロジェクトフォルダに移動する
      ↓
③ スタックを作成する（aws cloudformation create-stack）
      ↓
④ 作成完了・Outputsを確認する
      ↓
⑤ 動作確認（MariaDB・SG参照の確認）
      ↓
⑥ スタックを削除する（aws cloudformation delete-stack）

⓪ 自分のIPアドレスを確認する

curl https://checkip.amazonaws.com

またはルーター管理画面（http://192.168.0.1 など）の「WAN IPアドレス」で確認します。

控えておく情報: 自分のIPアドレス（例: 203.0.113.1）

① キーペアの作成（コンソールで実施）

キーペアのみコンソールで作成します。CloudFormationではキーペアのダウンロードが行えないためです。

AWSコンソール → EC2 → キーペア → 「キーペアを作成」

ダウンロードされた my-ec2-mysql-key.pem を保存します。

C:\Users\ユーザー名\.ssh\my-ec2-mysql-key.pem

② プロジェクトフォルダに移動する

VSCodeのターミナル（CMD）を開き、プロジェクトフォルダに移動します。

cd C:\my-aws\aws-learning-projects\ec2-mysql-db

template.yaml があることを確認します。

dir template.yaml

③ スタックの作成

以下のコマンドを実行します。203.0.113.1 は⓪で確認した自分のIPアドレスに置き換えてください。

aws cloudformation create-stack ^
  --stack-name my-ec2-mysql-stack ^
  --template-body file://template.yaml ^
  --region ap-northeast-1 ^
  --capabilities CAPABILITY_NAMED_IAM ^
  --parameters ^
    ParameterKey=KeyName,ParameterValue=my-ec2-mysql-key ^
    ParameterKey=MyIP,ParameterValue=203.0.113.1/32

各オプションの説明:

^ について: Windowsのコマンドプロンプトで長いコマンドを複数行に分けるための改行エスケープ文字です。

成功すると以下のようなStackIdが表示されます。

{
    "StackId": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/my-ec2-mysql-stack/xxxxx"
}

④ 作成完了・Outputsの確認

スタック作成は完了まで約5〜8分かかります（EC2×2台の起動 + MariaDBインストールの時間）。

作成状況の確認

aws cloudformation describe-stacks ^
  --stack-name my-ec2-mysql-stack ^
  --query "Stacks[0].StackStatus" ^
  --output text

Outputs（接続情報）の確認

CREATE_COMPLETE になったら以下を実行します。

aws cloudformation describe-stacks ^
  --stack-name my-ec2-mysql-stack ^
  --query "Stacks[0].Outputs" ^
  --output table

以下のような出力が表示されます。

---------------------------------------------------------------------------------------
|                                   DescribeStacks                                    |
+---------------------+---------------------------------------------------------------+
|  OutputKey          |  OutputValue                                                  |
+---------------------+---------------------------------------------------------------+
|  DBInstanceId       |  i-0xxxxxxxxxxxxxxx1                                         |
|  DBPublicIP         |  x.x.x.x                                                     |
|  DBPrivateIP        |  172.31.x.x      ← クライアントEC2からの接続に使用            |
|  ClientInstanceId   |  i-0xxxxxxxxxxxxxxx2                                         |
|  ClientPublicIP     |  y.y.y.y                                                     |
|  DBSSHCommand       |  ssh -i ...pem ec2-user@x.x.x.x                             |
|  ClientSSHCommand   |  ssh -i ...pem ec2-user@y.y.y.y                             |
|  MySQLConnectCommand|  mysql -h 172.31.x.x -u handson -pHandson1234! sampledb     |
+---------------------+---------------------------------------------------------------+

控えておく情報:

• DBPrivateIP: DBサーバのプライベートIP（クライアントEC2からの接続に使う）
• DBSSHCommand: DBサーバへのSSHコマンド
• ClientSSHCommand: クライアントEC2へのSSHコマンド
• MySQLConnectCommand: クライアントEC2から実行するMySQL接続コマンド

⑤ 動作確認

5-1. DBサーバの動作確認

Outputsの DBSSHCommand を実行してDBサーバに接続します。

ssh -i C:\Users\ユーザー名\.ssh\my-ec2-mysql-key.pem ec2-user@（DBPublicIP）

# MariaDBのサービス状態を確認（active (running) と表示されれば正常）
sudo systemctl status mariadb

# rootでログイン
sudo mysql -u root

MariaDBのプロンプト（MariaDB [(none)]>）が表示されたら以下を実行します。

-- ユーザー一覧（handsonユーザーが作成済みか確認）
SELECT User, Host FROM mysql.user;

-- データベース一覧（sampledbが存在するか確認）
SHOW DATABASES;

-- テスト用テーブルとデータを作成
USE sampledb;
CREATE TABLE users (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(50) NOT NULL,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
INSERT INTO users (name) VALUES ('Alice'), ('Bob'), ('Charlie');
SELECT * FROM users;

EXIT;

exit

5-2. SG参照の確認：クライアントEC2からMySQL接続

Outputsの ClientSSHCommand を実行してクライアントEC2に接続します。

ssh -i C:\Users\ユーザー名\.ssh\my-ec2-mysql-key.pem ec2-user@（ClientPublicIP）

Outputsに表示された MySQLConnectCommand をそのまま実行します。

mysql -h （DBPrivateIP） -u handson -pHandson1234! sampledb

接続成功すると MariaDB [sampledb]> が表示されます。

-- DBサーバで作成したデータが見えることを確認
SELECT * FROM users;

EXIT;

exit

5-3. SG参照の効果を確認する（任意・スキップ可）

前提: ローカルPCに mysql クライアントがインストールされている場合のみ実施します。5-2でクライアントEC2からの接続が成功していれば、このハンズオンの学習目的（SG参照によるEC2間通信制御）は達成済みです。

ローカルPCに mysql コマンドがある場合、ローカルターミナルで以下を実行します。

mysql -h （DBPublicIP） -u handson -pHandson1234! sampledb

本番環境でのベストプラクティス: DBサーバSGからMyIP指定のルールを削除し、SG参照のみにすることで、DBサーバをインターネットから完全に遮断できます。DBサーバにパブリックIPを付与しないことも有効です。

⑥ スタックの削除

課金を止めるために、ハンズオン完了後は必ず削除してください。

CloudFormationはスタック削除で全リソースを一括削除できます。SGの依存関係（DBサーバSG → クライアントSGの削除順序）も自動的に解決されます。

aws cloudformation delete-stack ^
  --stack-name my-ec2-mysql-stack ^
  --region ap-northeast-1

削除の進行状況を確認します（完了まで約5〜8分）。

aws cloudformation describe-stacks ^
  --stack-name my-ec2-mysql-stack ^
  --query "Stacks[0].StackStatus" ^
  --output text

削除完了の確認（以下のエラーが表示されれば削除完了）。

aws cloudformation describe-stacks ^
  --stack-name my-ec2-mysql-stack ^
  --region ap-northeast-1

An error occurred (ValidationError) when calling the DescribeStacks operation:
Stack with id my-ec2-mysql-stack does not exist

このメッセージが表示されれば削除完了です。キーペアはCloudFormationで管理していないため、手動で削除します。

EC2 → キーペア → my-ec2-mysql-key を選択 → 「アクション」→「削除」

ローカルの .pem ファイルも削除します。

コンソール版との比較

コンソール版でSGを手動で依存関係順に作成・削除していた手順が、CloudFormationではすべて自動管理されます。

CloudFormationのSG削除順序の自動管理: コンソール版ではDBサーバSG → クライアントSGの順で手動削除が必要でしたが、CloudFormationはリソース間の依存関係を自動的に解決して正しい順序で削除します。

トラブルシューティング

まとめ

今回のハンズオンで実現できたこと：

CloudFormationのメリットを実感できたポイント

• コンソール版では複数リソースの作成・削除に順番の意識が必要だったが、CloudFormationが自動管理
• MySQLConnectCommand がOutputsとして自動生成されるため、手動でコマンドを組み立てる必要がない
• template.yaml をGitで管理することで、SG参照を含む複雑な構成の変更履歴が残せる

コンソール版と比較してみる

CloudFormationが裏で何をやっているか、同じ構成をAWSコンソールのみで構築する手順をまとめました。特にSGの依存関係管理とSG参照の設定手順を視覚的に確認できます。

EC2サーバ構築ハンズオン：AWSコンソールでEC2 MySQLのDBサーバを構築する手順

関連記事

-->

The post EC2サーバ構築をIaC化：CloudFormationでEC2 MySQLのDBサーバを自動デプロイする手順【SG参照 / コンソール版との比較付き】 first appeared on CayTech Lab.

「EC2サーバ上でJavaアプリを動かしたい」——ApacheでHTMLを返せるようになったら、次はJavaが実行できるAPサーバー（Tomcat）に挑戦しましょう。

この記事では、AWSコンソール（GUI）のみを使って、Tomcat APサーバーが動作するEC2インスタンスをゼロから手動で構築するハンズオンを紹介します。

インターネット
  ↓ TCP 8080（Tomcat HTTP）← ブラウザでアクセス
  ↓ TCP 22（SSH）          ← ターミナルで接続
セキュリティグループ（ファイアウォール）
  ↓ 自分のIPのみ通過させる
EC2インスタンス（t2.micro / Amazon Linux 2023）
  ├── Java 17（Amazon Corretto）← Tomcatの実行基盤
  ├── Tomcat 10.1（APサーバー）← UserDataで自動インストール
  │     └── /opt/tomcat/latest/webapps/ROOT/index.jsp を返す
  └── IAMロール（Session Manager接続用）

このハンズオンで体験できること：

• EC2サーバーへのJava 17（Amazon Corretto）とTomcat 10のインストール
• セキュリティグループによるポートアクセス制御（SSH:22 / Tomcat:8080）
• UserDataを使ったJava + Tomcatの初回起動時自動インストール
• JSPが実行されていることをブラウザで確認（Apacheの静的HTMLとの違い）

このハンズオンの特徴：

• Apache版（Phase 1-1）の次のステップとして、APサーバーとWebサーバーの違いを体験できる
• 手動操作を通じて、各リソースの役割と依存関係を視覚的に理解できる

この記事は CloudFormation版ハンズオン の比較記事です。
コンソール操作でEC2 Tomcatサーバー構築の全体像を学び、CloudFormationとの違いを比較したい方向けです。

-->

キーワード解説

Apache（Webサーバー）と Tomcat（APサーバー）の違い

使用するAWSサービス

注意: 無料枠はAWSアカウント開設から12ヶ月間です。期間終了後はEC2インスタンス稼働時間に課金されます。ハンズオン後は必ずリソースを削除してください。

構築するリソース

全体の作業順序

依存関係があるため、必ずこの順番で作成します。

⓪ 自分のIPアドレスを確認する（重要）
      ↓
① キーペアを作成する
      ↓
② IAMロールを作成する
      ↓
③ EC2インスタンスを起動する
  （セキュリティグループ・UserDataも同時に設定）
      ↓
④ 動作確認（ブラウザ・SSH）
      ↓
⑤ リソースを削除する

【重要】⓪ 自分のIPアドレスを確認する

セキュリティグループで自分のIPだけを許可するために、正確なIPアドレスを事前に確認します。

注意: curl https://checkip.amazonaws.com で表示されるIPと、EC2への実際の接続元IPが一致しない場合があります（ISPやプロキシの経路の違いによる）。最も確実な方法はルーター管理画面での確認です。

方法A: ルーター管理画面で確認（推奨）

1. ブラウザで以下のURLにアクセスします（ルーターによって異なります）

   http://192.168.0.1  または  http://192.168.1.1

2. 「ネットワークマップ」または「インターネット」項目を開く
3. **「インターネットIPアドレス」または「WAN IPアドレス」**の値を控えます

方法B: コマンドで確認

curl https://checkip.amazonaws.com

控えておく情報: 自分のIPアドレス（例: 203.0.113.1）

① キーペアの作成

キーペアはSSHでEC2に接続するための鍵です。EC2起動時に指定する必要があるため、最初に作成します。

AWSコンソール → EC2 → ネットワーク＆セキュリティ → キーペア → 「キーペアを作成」

「キーペアを作成」をクリックすると、自動的に my-ec2-tomcat-key.pem がダウンロードされます。

ダウンロードしたキーペアを保存する

ダウンロードされた my-ec2-tomcat-key.pem を以下の場所に移動します。

C:\Users\ユーザー名\.ssh\my-ec2-tomcat-key.pem

注意: .pem ファイルは再ダウンロードできません。紛失した場合は新しいキーペアを作成する必要があります。

前回のキーペアの流用について: EC2 + Apacheハンズオンで作成した my-ec2-apache-key を流用しても動作します。その場合この手順はスキップします。

② IAMロールの作成

Session Manager（ブラウザからEC2に接続できるAWS機能）を使えるようにするためのIAMロールを作成します。

なぜIAMロールが必要か: EC2がAWSのサービス（Session Manager）を利用するには、そのEC2自身に「このサービスを使う権限」を付与する必要があります。この権限の設定がIAMロールです。

AWSコンソール → IAM → ロール → 「ロールを作成」

ステップ1: エンティティタイプとユースケースの選択

「次へ」をクリック。

ステップ2: 許可ポリシーのアタッチ

検索ボックスに AmazonSSMManagedInstanceCore と入力してチェックを入れます。

「次へ」をクリック。

ステップ3: ロール名の設定

「ロールを作成」をクリック。

③ EC2インスタンスの起動

キーペアとIAMロールを作成したあと、EC2インスタンスを起動します。
セキュリティグループとUserData（Java + Tomcat自動インストール）も同時に設定します。

AWSコンソール → EC2 → インスタンス → 「インスタンスを起動」

3-1. 基本設定

3-2. セキュリティグループの設定

「ネットワーク設定」→「セキュリティグループを作成する」を選択します。

セキュリティグループ名と説明を設定:

「インバウンドセキュリティグループのルールを追加」ボタンで以下の2ルールを追加します。

ルール1: SSH接続の許可

ルール2: Tomcat HTTPアクセスの許可

ポート8080について: TomcatはデフォルトでHTTP 8080番ポートをListenします。Apacheの80番とは異なるため、セキュリティグループでも8080を明示的に開ける必要があります。

/32 とは: 「このIPアドレス1つだけ」という意味のCIDR表記です。0.0.0.0/0 は全世界に開放することになりセキュリティリスクが高いため、必ず自分のIPのみに制限します。

3-3. IAMロールの設定

「高度な詳細」を開く → 「IAM インスタンスプロファイル」→ my-ec2-tomcat-role を選択します。

3-4. UserDataの設定（Java + Tomcatの自動インストール）

「高度な詳細」の一番下にある「ユーザーデータ」に以下を貼り付けます。

#!/bin/bash
dnf update -y
dnf install -y java-17-amazon-corretto

useradd -m -d /opt/tomcat -U -s /bin/false tomcat

TOMCAT_VERSION="10.1.25"
cd /tmp
wget -q "https://archive.apache.org/dist/tomcat/tomcat-10/v${TOMCAT_VERSION}/bin/apache-tomcat-${TOMCAT_VERSION}.tar.gz" \
  -O apache-tomcat.tar.gz
tar xzf apache-tomcat.tar.gz
mv "apache-tomcat-${TOMCAT_VERSION}" /opt/tomcat/latest
chown -R tomcat:tomcat /opt/tomcat
chmod -R u+x /opt/tomcat/latest/bin

cat > /etc/systemd/system/tomcat.service << 'SVCEOF'
[Unit]
Description=Apache Tomcat Web Application Container
After=network.target

[Service]
Type=forking
User=tomcat
Group=tomcat
Environment="JAVA_HOME=/usr/lib/jvm/java-17-amazon-corretto"
Environment="CATALINA_HOME=/opt/tomcat/latest"
Environment="CATALINA_BASE=/opt/tomcat/latest"
Environment="CATALINA_PID=/opt/tomcat/latest/temp/tomcat.pid"
Environment="JAVA_OPTS=-Xms256m -Xmx512m"
ExecStart=/opt/tomcat/latest/bin/startup.sh
ExecStop=/opt/tomcat/latest/bin/shutdown.sh
Restart=on-failure

[Install]
WantedBy=multi-user.target
SVCEOF

systemctl daemon-reload
systemctl enable tomcat
systemctl start tomcat

cat > /opt/tomcat/latest/webapps/ROOT/index.jsp << 'JSPEOF'
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head><meta charset="UTF-8"><title>Tomcat on EC2</title></head>
<body>
<h1>Hello from Tomcat on Amazon Linux 2023!</h1>
<p>Java Version: <%= System.getProperty("java.version") %></p>
<p>Tomcat Version: <%= application.getServerInfo() %></p>
</body>
</html>
JSPEOF
chown tomcat:tomcat /opt/tomcat/latest/webapps/ROOT/index.jsp

各コマンドの説明:

Amazon Corretto（コレット）とは: AWSが提供するOpenJDKのディストリビューション。無償・本番利用可能で、Amazon Linux 2023のパッケージリポジトリから直接インストールできます。

JAVA_OPTS=-Xms256m -Xmx512m: Javaの使用メモリを制限する設定です。t2.microは1GBのメモリしかないため、最小256MB・最大512MBに制限して他のプロセスと共存できるようにしています。

UserDataはインスタンスの初回起動時のみ実行されます。Tomcatのダウンロードを含むため、完了まで約5〜10分かかります。

3-5. インスタンスを起動する

「インスタンスを起動」ボタンをクリック。

起動完了まで約2〜3分待ちます。インスタンスの「状態」が「実行中」になったことを確認します。

控えておく情報: インスタンスのパブリックIPアドレス

インスタンス一覧 → 作成したインスタンスをクリック → 「パブリック IPv4 アドレス」を確認してメモします。

④ 動作確認

重要: UserDataでのJava + Tomcatインストールが完了するまで約5〜10分かかります。インスタンスが「実行中」になってもすぐには接続できません。

ブラウザで確認

ブラウザで以下のURLにアクセスします。ポート番号 8080 を忘れずに入力してください。

http://（パブリックIPアドレス）:8080

以下のように表示されれば成功です。

Hello from Tomcat on Amazon Linux 2023!
Java Version: 17.x.x
Tomcat Version: Apache Tomcat/10.1.25

JSPが実行されている証拠: Java Version や Tomcat Version はJavaコード（<%= ... %>）がサーバー側で実行されて表示されています。ApacheのHTMLと違い、TomcatがJavaを動かして動的にページを生成しています。

表示されない場合: UserDataのインストールが完了していない可能性があります。5〜10分待ってからリロードしてください。それでも表示されない場合はSSHで接続してログを確認します。

SSHで接続して確認

ローカルPCのターミナル（VSCode CMD）で実行します。

ssh -i C:\Users\ユーザー名\.ssh\my-ec2-tomcat-key.pem ec2-user@（パブリックIPアドレス）

初回接続時に以下の確認が出ます。yes を入力します。

Are you sure you want to continue connecting (yes/no)? yes

接続できたら以下を実行します。

java -version

# Tomcatサービスの動作状態を確認（active (running) と表示されれば正常）
sudo systemctl status tomcat

# TomcatのメインログでERRORがないか確認
sudo tail -50 /opt/tomcat/latest/logs/catalina.out

# Tomcatが8080番ポートをListenしているか確認
sudo ss -tlnp | grep :8080

# EC2から切断
exit

Tomcatのディレクトリ構成:

UserDataのインストール状況を確認する方法

インスタンスにSSHで接続できた場合、UserDataの実行ログで進捗を確認できます。

# UserDataのログを確認（インストールの進捗・エラーを確認できる）
sudo cat /var/log/cloud-init-output.log

【接続できない場合】IPアドレスが異なる可能性

curl で確認したIPを設定したが接続できない場合、実際の接続元IPが異なる可能性があります。

一時的に全開放して真のIPを確認する方法:

コンソール → EC2 → セキュリティグループ → my-ec2-tomcat-sg → 「インバウンドルールを編集」

SSHのルールを一時的に 0.0.0.0/0 に変更してSSH接続し、以下を実行します。

echo $SSH_CLIENT
# 出力例: 203.0.113.1 17508 22
# 先頭の値が真の接続元IP

このIPをメモしてSSH接続を切断し、セキュリティグループのSSHルールを 真のIP/32 に戻します。

⑤ リソースの削除

課金を止めるために、ハンズオン完了後は必ず削除してください。削除する順番が重要です。

1. EC2インスタンスを終了する

EC2 → インスタンス → my-ec2-tomcat-instance を選択 → 「インスタンスの状態」→「インスタンスを終了」

確認ダイアログで「終了」をクリック。状態が「終了済み」になるまで待ちます（2〜5分）。

「停止」と「終了」の違い: 「停止」は一時停止（EBSストレージ課金は続く）。「終了」は完全削除（課金停止）。学習後は「終了」を選びます。

2. セキュリティグループを削除する

EC2 → セキュリティグループ → my-ec2-tomcat-sg を選択 → 「アクション」→「セキュリティグループを削除」

インスタンス終了が完了している必要があります。「使用中」エラーが出る場合はインスタンスが「終了済み」状態になるまで待ってください。

3. IAMロールを削除する

IAM → ロール → my-ec2-tomcat-role を選択 → 「削除」→ ロール名を入力して確認

4. キーペアを削除する（任意）

他のEC2でも使い回す場合は残してよいです。不要な場合は削除します。

EC2 → キーペア → my-ec2-tomcat-key を選択 → 「アクション」→「削除」→ 確認テキストを入力

ローカルの .pem ファイルも手動で削除します。

C:\Users\ユーザー名\.ssh\my-ec2-tomcat-key.pem

CloudFormation版との比較

コンソール版を体験したら、次は同じ構成をCloudFormation（コード）で再現してみましょう。何が自動化されるのかがよくわかります。

コンソール版で実感できたポイント:

• Java + Tomcatのインストール手順が長く、手動では設定ミスが起きやすいことを実感できる
• ポート8080の開放やTomcatユーザーの作成など、セキュリティ設定の重要性が身につく
• UserDataの完了を待つ間に、コンソール版とCloudFormation版の差が体感できる

CloudFormation版でも試してみる: EC2サーバ構築をIaC化：CloudFormationでEC2 Tomcatを自動デプロイする手順

トラブルシューティング

まとめ

今回のハンズオンで体験できたこと：

手動操作でひとつひとつ作ると、CloudFormationが裏で何を自動化しているかが理解できます。ぜひ次は CloudFormation版 で同じ構成をコードで再現してみてください。

関連記事

-->

The post EC2サーバ構築ハンズオン：AWSコンソールでTomcatを構築する手順【EC2 Tomcat / CloudFormation版との比較付き】 first appeared on CayTech Lab.

「コンソールで手動構築できた構成を、コードで再現したい」——それを実現するのが AWS CloudFormation です。

この記事では、template.yaml 1ファイルにリソース構成を定義し、コマンド1本でEC2 Tomcat環境を一括構築するハンズオンを紹介します。コンソール版（AWSコンソール版ハンズオン）と全く同じ構成を、CloudFormationで自動化します。

ローカル環境（VSCode）
  ├── template.yaml（CloudFormationテンプレート）
  └── AWS CLI コマンド
        ↓ スタック作成（コマンド1本）
AWS環境
  ├── IAMロール（SSM接続用）                       ← template.yamlで定義
  ├── セキュリティグループ（SSH:22・Tomcat:8080）    ← template.yamlで定義
  └── EC2インスタンス（t2.micro / AL2023 + Java17 + Tomcat10）← template.yamlで定義

このハンズオンで体験できること：

• template.yaml へのリソース定義（IAMロール・セキュリティグループ・EC2インスタンス）
• !Ref / !Sub / !GetAtt を使ったリソース間参照
• aws cloudformation create-stack コマンド1本での全リソース一括デプロイ
• aws cloudformation delete-stack コマンド1本での全リソース一括削除

このハンズオンの特徴：

• コンソール版では20〜30分かかった手動作業が、コマンド1本（約5〜10分）で完了する
• delete-stack 1本で依存関係を考慮した順番で全リソースを自動削除できる

-->

CloudFormation vs コンソール：どれだけ違うか

キーワード解説

前提条件

AWS認証確認:

aws sts get-caller-identity

アカウントIDが表示されれば認証設定済みです。

template.yaml の全文

以下が今回使用する template.yaml の全文です。プロジェクトフォルダ（ec2-tomcat-web/）直下に配置します。

⚠️ コピー前に確認: Default: '123.456.78.901/32' の箇所はダミーIPです。このまま使うとスタック作成は成功しますが、SSHもブラウザもアクセスできません。--parameters でIPを上書きするか（推奨）、Defaultを自分のIPに書き換えてから使ってください。

AWSTemplateFormatVersion: '2010-09-09'
Description: 'EC2 + Tomcat Application Server Hands-on (Phase 1-2)'

Parameters:
  KeyName:
    Type: String
    Default: 'my-ec2-tomcat-key'
    Description: Name of an existing EC2 KeyPair

  MyIP:
    Type: String
    Default: '123.456.78.901/32'
    Description: Your IP address to allow SSH and Tomcat access (CIDR format e.g. 203.0.113.1/32)

Resources:
  EC2Role:
    Type: AWS::IAM::Role
    Properties:
      RoleName: 'my-ec2-tomcat-role'
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: 'sts:AssumeRole'
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
      Tags:
        - Key: Name
          Value: 'my-ec2-tomcat-role'

  # Instance Profile: wrapper that attaches the IAM role to EC2
  EC2InstanceProfile:
    Type: AWS::IAM::InstanceProfile
    Properties:
      InstanceProfileName: 'my-ec2-tomcat-profile'
      Roles:
        - !Ref EC2Role

  # Security Group: allow SSH(22) and Tomcat(8080) from MyIP only
  EC2SecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: 'my EC2 Tomcat hands-on SG'
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: !Ref MyIP
          Description: SSH access from my IP
        - IpProtocol: tcp
          FromPort: 8080
          ToPort: 8080
          CidrIp: !Ref MyIP
          Description: Tomcat HTTP access from my IP
      Tags:
        - Key: Name
          Value: 'my-ec2-tomcat-sg'

  # EC2 Instance: Amazon Linux 2023 + Java 17 + Tomcat 10 (installed via UserData)
  EC2Instance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: '{{resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64}}'
      InstanceType: t2.micro
      KeyName: !Ref KeyName
      SecurityGroupIds:
        - !Ref EC2SecurityGroup
      IamInstanceProfile: !Ref EC2InstanceProfile
      # UserData: shell script executed automatically on first boot
      UserData:
        Fn::Base64: |
          #!/bin/bash
          dnf update -y
          dnf install -y java-17-amazon-corretto

          useradd -m -d /opt/tomcat -U -s /bin/false tomcat

          TOMCAT_VERSION="10.1.25"
          cd /tmp
          wget -q "https://archive.apache.org/dist/tomcat/tomcat-10/v${TOMCAT_VERSION}/bin/apache-tomcat-${TOMCAT_VERSION}.tar.gz" \
            -O apache-tomcat.tar.gz
          tar xzf apache-tomcat.tar.gz
          mv "apache-tomcat-${TOMCAT_VERSION}" /opt/tomcat/latest
          chown -R tomcat:tomcat /opt/tomcat
          chmod -R u+x /opt/tomcat/latest/bin

          cat > /etc/systemd/system/tomcat.service << 'SVCEOF'
          [Unit]
          Description=Apache Tomcat Web Application Container
          After=network.target

          [Service]
          Type=forking
          User=tomcat
          Group=tomcat
          Environment="JAVA_HOME=/usr/lib/jvm/java-17-amazon-corretto"
          Environment="CATALINA_HOME=/opt/tomcat/latest"
          Environment="CATALINA_BASE=/opt/tomcat/latest"
          Environment="CATALINA_PID=/opt/tomcat/latest/temp/tomcat.pid"
          Environment="JAVA_OPTS=-Xms256m -Xmx512m"
          ExecStart=/opt/tomcat/latest/bin/startup.sh
          ExecStop=/opt/tomcat/latest/bin/shutdown.sh
          Restart=on-failure

          [Install]
          WantedBy=multi-user.target
          SVCEOF

          systemctl daemon-reload
          systemctl enable tomcat
          systemctl start tomcat

          cat > /opt/tomcat/latest/webapps/ROOT/index.jsp << 'JSPEOF'
          <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
          <!DOCTYPE html>
          <html>
          <head><meta charset="UTF-8"><title>Tomcat on EC2</title></head>
          <body>
          <h1>Hello from Tomcat on Amazon Linux 2023!</h1>
          <p>Java Version: <%= System.getProperty("java.version") %></p>
          <p>Tomcat Version: <%= application.getServerInfo() %></p>
          </body>
          </html>
          JSPEOF
          chown tomcat:tomcat /opt/tomcat/latest/webapps/ROOT/index.jsp
      Tags:
        - Key: Name
          Value: 'my-ec2-tomcat-instance'

Outputs:
  InstanceId:
    Description: EC2 Instance ID
    Value: !Ref EC2Instance

  PublicIP:
    Description: Public IP Address
    Value: !GetAtt EC2Instance.PublicIp

  TomcatURL:
    Description: Tomcat URL (open in browser)
    Value: !Sub 'http://${EC2Instance.PublicIp}:8080'

  SSHCommand:
    Description: SSH command (update the .pem path as needed)
    Value: !Sub 'ssh -i C:\Users\username\.ssh\${KeyName}.pem ec2-user@${EC2Instance.PublicIp}'

!Ref と !Sub の使い分け:

Apache版との主な違い（template.yaml）:

構築されるリソースと論理ID:

作業順序

⓪ 自分のIPアドレスを確認する（重要）
      ↓
① キーペアを作成する（コンソールで実施）
      ↓
② プロジェクトフォルダに移動する
      ↓
③ スタックを作成する（aws cloudformation create-stack）
      ↓
④ 作成状況・Outputsを確認する
      ↓
⑤ 動作確認（ブラウザ・SSH）
      ↓
⑥ スタックを削除する（aws cloudformation delete-stack）

【重要】⓪ 自分のIPアドレスを確認する

セキュリティグループで自分のIPのみを許可するために、正確なIPアドレスを事前に確認します。

注意: curl https://checkip.amazonaws.com で表示されるIPと、EC2への実際の接続元IPが一致しない場合があります（ISPやプロキシの経路の違いによる）。

方法A: ルーター管理画面で確認（推奨）

1. ブラウザで以下のURLにアクセスします

   http://192.168.0.1  または  http://192.168.1.1

2. 「ネットワークマップ」または「インターネット」項目を開く
3. **「インターネットIPアドレス」または「WAN IPアドレス」**の値を控えます

方法B: コマンドで確認

curl https://checkip.amazonaws.com

控えておく情報: 自分のIPアドレス（例: 203.0.113.1）

① キーペアの作成（コンソールで実施）

キーペアのみコンソールで作成します。CloudFormationではキーペアのダウンロードが行えないためです。

AWSコンソール → EC2 → キーペア → 「キーペアを作成」

ダウンロードされた my-ec2-tomcat-key.pem を保存します。

C:\Users\ユーザー名\.ssh\my-ec2-tomcat-key.pem

前回のキーペアの流用について: Apacheハンズオンで作成した my-ec2-apache-key を流用する場合、この手順はスキップし、後続コマンドの KeyName の値を my-ec2-apache-key に変更します。

② プロジェクトフォルダに移動する

VSCodeのターミナル（CMD）を開き、プロジェクトフォルダに移動します。

cd C:\my-aws\aws-learning-projects\ec2-tomcat-web

template.yaml があることを確認します。

dir template.yaml

③ スタックの作成

以下のコマンドを実行します。203.0.113.1 は⓪で確認した自分のIPアドレスに置き換えてください。

aws cloudformation create-stack ^
  --stack-name my-ec2-tomcat-stack ^
  --template-body file://template.yaml ^
  --region ap-northeast-1 ^
  --capabilities CAPABILITY_NAMED_IAM ^
  --parameters ^
    ParameterKey=KeyName,ParameterValue=my-ec2-tomcat-key ^
    ParameterKey=MyIP,ParameterValue=203.0.113.1/32

各オプションの説明:

^ について: Windowsのコマンドプロンプトで長いコマンドを複数行に分けるための改行エスケープ文字です。1行で書いても動作します。

template.yamlのコメントは英語のみ: 日本語コメントが含まれているとWindows上のAWS CLIがエンコードエラーを起こすため、コメントはすべて英語で記述しています。

成功すると以下のようなStackIdが表示されます。

{
    "StackId": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/my-ec2-tomcat-stack/xxxxx"
}

④ 作成完了・Outputsの確認

スタック作成は完了まで約3〜5分かかります。ただし、Tomcatのインストール（UserData）はさらに5〜10分かかるため、スタック完了後もすぐにブラウザでアクセスできないことがあります。

作成状況の確認

aws cloudformation describe-stacks ^
  --stack-name my-ec2-tomcat-stack ^
  --query "Stacks[0].StackStatus" ^
  --output text

Outputs（接続情報）の確認

CREATE_COMPLETE になったら以下を実行します。

aws cloudformation describe-stacks ^
  --stack-name my-ec2-tomcat-stack ^
  --query "Stacks[0].Outputs" ^
  --output table

以下のような出力が表示されます。

------------------------------------------------------------------------------------------
|                                    DescribeStacks                                      |
+----------------+-----------------------------------------------------------------------+
|  OutputKey     |  OutputValue                                                          |
+----------------+-----------------------------------------------------------------------+
|  InstanceId    |  i-0123456789abcdef0                                                 |
|  PublicIP      |  x.x.x.x                                                             |
|  TomcatURL     |  http://x.x.x.x:8080                                                 |
|  SSHCommand    |  ssh -i C:\Users\...\.ssh\my-ec2-tomcat-key.pem ec2-user@x.x.x.x     |
+----------------+-----------------------------------------------------------------------+

控えておく情報: PublicIP と TomcatURL

⑤ 動作確認

ブラウザで確認

Outputsに表示された TomcatURL（http://x.x.x.x:8080）をブラウザで開きます。

Hello from Tomcat on Amazon Linux 2023!
Java Version: 17.x.x
Tomcat Version: Apache Tomcat/10.1.25

が表示されれば成功です。

表示されない場合: UserDataのインストール完了まで5〜10分かかります。スタックが CREATE_COMPLETE になった後も少し待ってからアクセスしてください。

SSHで接続して確認

Outputsに表示された SSHCommand を実行します（パスは実際のパスに修正します）。

ssh -i C:\Users\ユーザー名\.ssh\my-ec2-tomcat-key.pem ec2-user@（PublicIP）

初回接続時の確認には yes を入力します。

# Javaのバージョン確認
java -version

# Tomcatサービスの状態確認（active (running) と表示されれば正常）
sudo systemctl status tomcat

# TomcatのログでERRORがないか確認
sudo tail -50 /opt/tomcat/latest/logs/catalina.out

# UserDataの実行ログ確認（インストール状況を詳細に確認できる）
sudo cat /var/log/cloud-init-output.log

# 8080番ポートのListen確認
sudo ss -tlnp | grep :8080

exit

【接続できない場合】真のIPアドレスを確認する

curl で確認したIPを設定したが接続できない場合、実際の接続元IPが異なる可能性があります。

セキュリティグループIDを取得:

aws cloudformation describe-stack-resources ^
  --stack-name my-ec2-tomcat-stack ^
  --query "StackResources[?ResourceType=='AWS::EC2::SecurityGroup'].PhysicalResourceId" ^
  --output text

SSH全開放（一時的・テスト用）:

aws ec2 authorize-security-group-ingress ^
  --group-id sg-XXXXXXXXX ^
  --protocol tcp ^
  --port 22 ^
  --cidr 0.0.0.0/0 ^
  --region ap-northeast-1

SSH接続して真のIPを確認します。

echo $SSH_CLIENT
# 出力例: 203.0.113.1 17508 22
# 先頭の値が真の接続元IP
exit

確認後、全開放を削除して真のIPで制限し直します。

rem 全開放を削除
aws ec2 revoke-security-group-ingress ^
  --group-id sg-XXXXXXXXX ^
  --protocol tcp ^
  --port 22 ^
  --cidr 0.0.0.0/0 ^
  --region ap-northeast-1

rem 真のIPで再制限
aws ec2 authorize-security-group-ingress ^
  --group-id sg-XXXXXXXXX ^
  --protocol tcp ^
  --port 22 ^
  --cidr 真のIP/32 ^
  --region ap-northeast-1

⑥ スタックの削除

課金を止めるために、ハンズオン完了後は必ず削除してください。

CloudFormationはスタック削除で全リソースを一括削除できます。手動でリソースを1つ1つ削除する必要はありません。

aws cloudformation delete-stack ^
  --stack-name my-ec2-tomcat-stack ^
  --region ap-northeast-1

削除の進行状況を確認します（完了まで約3〜5分）。

aws cloudformation describe-stacks ^
  --stack-name my-ec2-tomcat-stack ^
  --query "Stacks[0].StackStatus" ^
  --output text

削除完了の確認（以下のエラーが表示されれば削除完了）。

aws cloudformation describe-stacks ^
  --stack-name my-ec2-tomcat-stack ^
  --region ap-northeast-1

An error occurred (ValidationError) when calling the DescribeStacks operation:
Stack with id my-ec2-tomcat-stack does not exist

このメッセージが表示されれば削除完了です。キーペアはCloudFormationで管理していないため、手動で削除します。

EC2 → キーペア → my-ec2-tomcat-key を選択 → 「アクション」→「削除」

ローカルの .pem ファイルも削除します。

コンソール版との比較

コンソール版でIAMロール・セキュリティグループ・EC2を手動作成した手順が、CloudFormationではすべて template.yaml に定義されています。

コンソール版で詰まりやすいポイント:
UserDataのTomcatインストールが5〜10分かかるため、コンソール版では「インスタンスが動いているのにアクセスできない」状態が続きます。
CloudFormationでも待ち時間は同じですが、デプロイ自体はコマンド1本で完了します。

トラブルシューティング

まとめ

今回のハンズオンで実現できたこと：

CloudFormationのメリットを実感できたポイント

• コンソール版では20〜30分かかった作業がコマンド1本（5〜10分）で完了した
• delete-stack で依存関係を気にせず全リソースを一括削除できた
• template.yaml をGitで管理することで、環境構成の変更履歴が残せる

コンソール版と比較してみる

CloudFormationが裏で何をやっているか、同じ構成をAWSコンソールのみで構築する手順をまとめました。コンソール版ではキーペア・IAMロール・セキュリティグループ・EC2を依存関係順に手動で作成する必要があり、各リソースの役割と繋がりが視覚的に理解できます。

EC2サーバ構築ハンズオン：AWSコンソールでTomcatを構築する手順

関連記事

-->

The post EC2サーバ構築をIaC化：CloudFormationでEC2 Tomcatを自動デプロイする手順【コンソール版との比較付き】 first appeared on CayTech Lab.

「ターミナル型AIエージェントが乱立していて、どれを選べばいいか分からない…」

Claude Code（Anthropic）、Gemini CLI（Google）、Codex CLI（OpenAI）——三大AI企業がそれぞれターミナル型エージェントをリリースし、2026年3月現在、どれを使うべきか迷っているエンジニアが急増しています。

どれも「ターミナルから自律的にファイルを編集・コマンドを実行できる」という点は同じです。しかし設計思想・得意分野・コストが大きく異なります。

本記事では3つのツールを同じ観点で徹底的に比較します。「どれを選ぶべきか」の判断材料として、ぜひ参考にしてください。

Amazon検索[本 Claude Code]

Amazon検索[本 Gemini]

基本スペック比較

まずは数値で比べます。

ベンチマークについての補足

SWE-bench Verifiedはコーディングタスク全般の能力評価です。一方、Terminal-Bench 2.0はターミナル操作・シェルスクリプト実行に特化した評価です。Codex CLIはターミナル特化のベンチマークで最高スコアを記録しています。

※OpenAIはSWE-bench Verifiedにトレーニングデータ汚染が発見されたとして報告を停止。Codex CLIの現行モデル比較にはSWE-bench ProとTerminal-Bench 2.0が使われています。

料金の詳細

Claude Code:

Proプラン: $20/月（5時間ごとに約10〜40プロンプト制限）
Max 5x:   $100/月（5倍の使用量）
Max 20x:  $200/月（20倍の使用量）
※ Web版・Desktop版・Claude Codeで使用量を共有

Gemini CLI:

無料枠:   0円（Googleアカウントのみ）
          └→ 60リクエスト/分、1,000リクエスト/日
          └→ デフォルト: Gemini 2.5 Flash
API利用:  従量課金（Google AI Studio経由）
          └→ Gemini 3 Flash: 高コスパ（SWE-bench Verified 78%）

Codex CLI:

無料枠:   なし（APIキー or ChatGPT Plus必須）
Plus:     $20/月（30〜150メッセージ/5時間）
Pro:      $200/月（300〜1,500メッセージ/5時間）
API従量:  gpt-5.4-mini: 入力 $1.25/Mトークン
          → 使いすぎると青天井になる点に注意

Claude Codeの強み——他2ツールにできないこと

1. 高い自律性と粘り強いデバッグ

Claude Codeの最大の強みは**「テストを回す→エラーが出る→自分で修正する→またテストする」** というループの粘り強さです。

Claude Codeのデバッグループ:
1. エラーを検知
2. 原因を深く推論（Thinkingモード）
3. 修正案を実装
4. テストを再実行
5. 成功するまで繰り返す（ほとんど手動介入不要）

実際のベンチマーク比較（あるコーディングタスク）：

Claude Code: 1h17m で完了、コスト $4.80（全自動）
Gemini CLI: より長い時間、コスト $7.06（途中で手動介入が必要なケースも）

Gemini CLI・Codex CLIの課題: どちらも修正を繰り返すと同じ間違いをループしたり、指示を無視して大幅な書き換えをしてしまうことがあります。

2. 洗練されたコードの品質

Claudeは「コーディングの職人気質」が評価されており、生成されるコードが非常に洗練されています。

Claude Code: 簡潔で読みやすいコード
             冗長な記述を避ける傾向
             命名規則やスタイルに一貫性がある

Gemini CLI:  実用的だが、時に冗長なボイラープレートを出力
Codex CLI:   gpt-5.4使用時は高品質だが、モデル選択に依存する

3. 深い思考（Thinkingモード）による自己修正

Claude Codeは、コードを書く前に**「なぜその設計にするのか」を深く自問自答**します。

Claudeの思考プロセス:
1. 要件の本質を理解
2. 複数の実装パターンを検討
3. トレードオフを評価
4. 最適解を選択してから実装

→ 結果: 一発で動くコードを書く確率が高い
   SWE-bench Verified: Opus 4.6 で 80.8%（3ツール中最高）

4. 音声入力モード（2026年3月〜）

2026年3月のアップデートで、Claude Codeに音声入力モードが追加されました。

/voice コマンドでプッシュトゥトーク方式の音声入力が可能
→ ターミナルでの長い指示も音声で素早く入力できる
→ ハンズフリーでのコーディングが可能に

Gemini CLI・Codex CLIでは現時点でネイティブ音声モードは未搭載です。

5. VS Code + JetBrains 両方に公式IDE統合

Claude Code:  VS Code拡張機能（公式）+ JetBrains拡張機能（公式）
Gemini CLI:   VS Code拡張機能あり
Codex CLI:    ターミナル中心（公式IDE統合なし）

IntelliJ・WebStorm等のJetBrains系IDEを使う開発者には特に優位です。

6. 定額制による費用の予測しやすさ

Claude Code Pro: $20/月で使用量の上限がある
                 → 月の予算が読みやすく、予算オーバーが起きない

Codex CLI:       APIキー従量課金で青天井になる可能性
Gemini CLI:      無料枠を超えると従量課金に

Gemini CLIの強み——他2ツールにできないこと

1. 完全無料から始められる

これがGemini CLIの最大のアドバンテージです。

Gemini CLI:
✅ Googleアカウントだけで今日から無料でスタート
✅ 1,000リクエスト/日で日常的な開発には十分
✅ SWE-bench Verified 78%（Sonnet 4.6の72.7%を上回る）という高精度が無料で使える

Claude Code: 別途サブスク（$20/月〜）が必要
Codex CLI:   APIキー or ChatGPT Plus（$20/月〜）が必要

2. 超大規模プロジェクトの「一括」把握

Gemini CLIのコンテキスト: 最大100万トークン
  └→ 数万行のコードベースを丸ごと読み込める
  └→ ファイル間の依存関係や矛盾を一括検出可能

Claude Code: 約20万トークン
  └→ 大規模プロジェクトでは記憶を圧縮（Compaction）
  └→ 圧縮により細部の記憶が抜け落ちることがある

Codex CLI:  gpt-5.3-codexで100万トークン対応
  └→ ただし gpt-5.4（デフォルト）は100万トークン未対応
  └→ モデルを指定変更する必要がある

Gemini CLIはデフォルトのモデルから100万トークンが使える点が優位です。

実際の活用例:

# 数万行のコードベースを丸ごと分析
> このプロジェクト全体を俯瞰して、
> アーキテクチャ上の矛盾点と将来の拡張に向けた改善提案を教えて

3. Google検索とのリアルタイム統合

# 昨日リリースされたライブラリの最新仕様を調べながらコードを書く
> /search React 19 useOptimistic の使い方

# 最新のAWSサービスを使った実装
> 最新のLambda関数URLの仕様を確認して、このコードに組み込んで

Claude Code・Codex CLIはいずれも学習データに基づく推論がメインで、最新情報へのリアルタイムアクセスではGemini CLIが優位です（Codex CLIもWeb検索機能はあるが、Googleほど検索精度が高くない）。

4. Plan Mode（v0.30.0〜デフォルト有効）

Gemini CLI:
✅ 実行前に必ず「実装計画」を提示し、ユーザーが承認してから動く
✅ v0.30.0以降はデフォルト有効
✅ 外部エディタでプランを編集してから実行する機能もあり

Claude Code: 近い機能はあるが、Plan Modeとして独立していない
Codex CLI:   /plan コマンドで呼び出せるが、デフォルトではない

5. スキル（Skills）機能——ワークフローのチーム共有

Gemini CLI独自の拡張機能です。

スキルとは:
- 定型的なワークフローや複雑な手順を「スキル」として定義・共有できる
- タスクに適合するスキルをGemini CLIが自動検出して起動
- チーム全体での開発標準化が容易になる

管理コマンド:
/skills list    → 利用可能なスキルを一覧表示
/skills enable  → スキルを有効化
/skills disable → スキルを無効化

6. マルチモーダル（動画・音声）の優位性

Gemini CLI（Geminiモデル）:
✅ 動画ファイルを渡してバグを修正させることが可能
✅ 画像・音声・PDFなど多様なメディアに対応

Claude Code: スクリーンショット（画像）解析は得意
Codex CLI:  画像入力に対応。動画・音声はGeminiが先行

7. コスト効率（大規模タスク）

Gemini 2.5 Flash（デフォルト）:
- SWE-bench Verified スコア: 78%（3ツール中最高水準）
- 無料枠: 1,000リクエスト/日
- → 品質を保ちながら大量処理できる

Codex CLIの強み——他2ツールにできないこと

1. ターミナル作業能力が業界最高水準

Terminal-Bench 2.0（ターミナル操作・シェルスクリプトの実行能力を評価するベンチマーク）での比較：

Terminal-Bench 2.0:
Codex CLI (gpt-5.3-codex): 77.3%  ← 最高
Claude Code (Opus 4.6):    65.4%
Gemini CLI:                未公開

シェル操作・コマンドライン作業が本職のツールです。

2. OSネイティブのサンドボックス実行

Codex CLIにしかない最も特徴的な機能です。

Codex CLI:
✅ OSネイティブのサンドボックスでコマンド実行を完全隔離
✅ approval-policy=never でも安全な完全自動化が可能
✅ ワークスペース内に操作範囲を限定できる

Claude Code: サンドボックスなし
Gemini CLI:  サンドボックスなし

これにより、他2ツールが「安全のためにfull-autoは危険」なのに対し、Codex CLIはサンドボックスが有効な状態でfull-autoが実現できます。

3. 承認モードの細かい制御（4段階）

Codex CLI の承認モード:
on-request（デフォルト）: ワークスペース外の操作のみ確認
untrusted:               変更・破壊的操作を全て確認（読み取りは自動）
never:                   全ての承認をスキップ（サンドボックスは有効）
dangerously-bypass:      全制限を解除（隔離環境専用）

Claude Code・Gemini CLI: On/Off 程度の制御しかない

4. CI/CDパイプラインへの最適設計

Codex CLI:
✅ never + sandbox の組み合わせで安全な完全自動化
✅ GitHub Actionsに直接組み込める
✅ 夜間バッチ・定期タスクの自動実行に最適

Claude Code・Gemini CLI:
△ CLIとして動作はするが、CI/CD前提の設計ではない

5. Apache-2.0ライセンスで社内カスタマイズが自由

Codex CLI（Apache-2.0）:
✅ ソースコードを完全に改変・再配布可能
✅ 社内セキュリティポリシーに合わせたカスタマイズが可能
✅ 社内MCPサーバーと組み合わせた専用エージェント構築

Gemini CLI（Apache-2.0）: 同様にオープンソース
Claude Code:              クローズドソース

6. マルチエージェントv2による並列タスク実行

v0.117.0から本格化した機能です。

Codex CLI マルチエージェントv2:
✅ パスベースアドレスで複数のサブエージェントを管理
✅ 構造化メッセージングで各エージェントが協調
✅ フロントエンド・バックエンドを別エージェントが並列で担当

→ 大規模なリファクタリングや複数モジュールの同時実装に効果的

7. 高速処理（Cerebras統合）

Codex CLI (Cerebras統合): 1,000トークン/秒超
Claude Code:              約200トークン/秒
→ 約5倍の処理速度

大量のファイルを素早く処理する際に特に有効です。

設定ファイルの比較

3つのツールともに、プロジェクトのルールを記述したMarkdownファイルを自動読み込みします。

配置パスの比較

書き方の違いと特徴

CLAUDE.md（Claude Code）：

# プロジェクトルール

## コミュニケーション
- すべてのやり取りは日本語で行うこと

## コーディング規約
- コードの右側にコメントを書くこと
  例: `const x = 1; // 値を初期化`

## プロジェクト固有のルール
- npm scripts 実行時は -- を使って引数を渡すこと

GEMINI.md（Gemini CLI）：

# プロジェクト概要
このプロジェクトは Next.js + TypeScript で構築したブログシステムです。

# コーディングルール
- すべてのやり取りは日本語で行うこと
- コメントはコードの右側に記述すること

# 開発コマンド
- ビルド: npm run build
- テスト: npm test

AGENTS.md（Codex CLI）：

# プロジェクト概要
Next.js + TypeScript のブログシステム

# コーディング規約
- すべてのやり取りは日本語で行うこと
- TypeScript strict モードを厳守

# 開発コマンド
- ビルド: npm run build
- テスト: npm test

# セキュリティポリシー（full-autoモードでの暴走防止）
- .envファイルは絶対に読み取らないこと
- node_modules は絶対に編集しないこと
- 本番環境のDBに接続するコマンドは実行しないこと

書き方のポイント:

• CLAUDE.md: 制約・スタイルガイドの記述が効果的（指示への忠実さが高いため）
• GEMINI.md: 開発コマンドの記述が効果的（CLIコマンドを自律実行するため）
• AGENTS.md: 禁止事項・セキュリティポリシーの明記が特に効果的（full-autoモードの安全性確保のため）

設定の確認コマンド

UI・操作感の違い

Claude Code

• ステップを細かく逐次表示（「ファイルAを読み込みました」「ファイルBを編集しました」など、各アクションを個別に報告）
• ツリー形式でアクションを表示
• 変更内容の差分表示が明確
• 承認プロンプトのUXが洗練されている

Gemini CLI

• 複数のアクションをまとめてボックスで表示（「3つのファイルを確認して修正しました」のようにサマリー形式）
• Plan Modeで作業前に確認ステップを挟める（v0.30.0〜デフォルト有効）
• Verboseモードへの切り替えで、Claude Codeのような逐次ログ表示も可能
• 外部エディタでプランを開いて編集する機能も追加（v0.30.0〜）

Codex CLI

• シンプルなターミナルUI（3ツールの中で最もミニマル）
• 承認プロンプトは機能的だが、視覚的な洗練度は低め
• /plan コマンドでプランモードを呼び出せるが、デフォルトではない
• マルチエージェントv2では複数スレッドを agent コマンドで切り替えて管理

「何をやっているか全部見たい」派            → Claude Code
「結果だけ教えてくれればいい」派            → Gemini CLI
「CIに組み込んで完全自動化したい」派        → Codex CLI

実際の使い分け戦略

ケース別おすすめ

プロの3ツール使い分け

Gemini CLI を使う場面:
✅ ブログ記事100本を一度にスキャンしてSEO課題を見つける
✅ 新しいフレームワークで「まず動くもの」を速攻で作る
✅ コードベース全体の依存関係を把握する
✅ チーム共通のスキル（Skills）を定義してワークフローを標準化する
✅ Plan Modeで実行前に全工程を確認・承認してから安全に作業する
✅ 無料枠の範囲で日常のちょっとした作業を済ませる

Claude Code を使う場面:
✅ 複雑なロジックをバグなしで一発で実装したい
✅ Geminiが書いた「動くけど汚いコード」を清書する
✅ 特定のバグを粘り強くデバッグしたい
✅ 音声入力で手をふさがずにコーディング指示を出したい
✅ VS Code / JetBrains の両方を使った IDE統合で作業したい

Codex CLI を使う場面:
✅ GitHub ActionsなどのCI/CDに組み込んだ安全な自動化
✅ 夜間バッチで大量ファイルの処理を完全自動実行
✅ シェルスクリプト・インフラコードの高度な自動化
✅ Apache-2.0ライセンスで社内ツールに改造・組み込み
✅ マルチエージェントで複数モジュールを並列で開発

最適な分担:

「全体像を把握させる」          → Gemini CLI（デフォルトで100万トークン）
「一か所のバグを徹底的に詰める」 → Claude Code（粘り強い自律デバッグ）
「自動化・CI/CDに組み込む」     → Codex CLI（サンドボックス + full-auto）

機能比較まとめ表

Amazon検索[本 Claude Code]

Amazon検索[本 Gemini]

まとめ

Claude Code・Gemini CLI・Codex CLIの3ツールは、三すくみの補完関係にあります。

3ツールの立ち位置

Claude Code  → 「精密に・確実に・高品質で」
Gemini CLI   → 「広く・大量に・無料で」
Codex CLI    → 「自動化・CI・ターミナル最強で」

あなたに合うのはどれか

Gemini CLIが向いている方:

• まず0円でAIエージェントを試してみたい
• 大規模なコードベース全体をAIに把握させたい
• Google検索と連携した最新情報を使いたい
• チームでワークフローを標準化したい（Skills機能）

Claude Codeが向いている方:

• コードの品質を最優先にしたい
• 複雑なバグを自律的に修正させたい
• 定額制で費用を予測しやすくしたい
• JetBrains系IDEで使いたい
• 音声入力でハンズフリー開発したい

Codex CLIが向いている方:

• CI/CDパイプラインにAIエージェントを安全に組み込みたい
• シェル・ターミナル作業を高度に自動化したい
• Apache-2.0ライセンスで社内ツールに改造・組み込みしたい
• マルチエージェントで大規模タスクを並列処理したい

最もコスパの良い使い方

STEP 1: Gemini CLIの無料枠から試す（0円）
  ↓ 物足りなくなったら
STEP 2: Claude CodeのProプランを追加（$20/月）
  ↓ CI/CD自動化が必要になったら
STEP 3: Codex CLIをCI/CDに組み込む（従量課金・少額）

この3段階のアプローチが、2026年現在でコスト面でも最も賢い選択です。

関連記事：

• Claude Code完全ガイド｜ターミナルで動くAIコーディングアシスタントの全貌【2026年3月版】

Claude Code完全ガイド｜ターミナルで動くAIコーディングアシスタントの全貌【2026年3月版】

はじめに「AIにコードを書かせたいけど、ブラウザとエディタを行き来するのが面倒…」そんな悩みを解決するのがClaude Codeです。2026年3月時点で、Anthropicが提供するターミナル型AIエージェントとして、開発者の間で急速に注...

caymezon.com

2026.02.14

• Gemini CLI完全ガイド｜ターミナルで動くGoogleのAIエージェントの全貌【2026年3月最新】

Gemini CLI完全ガイド｜ターミナルで動くGoogleのAIエージェントの全貌【2026年3月最新】

はじめに「Claude CodeみたいなAIコーディングエージェントを試したいけど、費用を抑えたい…」「Googleが出しているターミナル版AIエージェントって何ができるの？」そんな疑問を持つエンジニアに向けて、Gemini CLIの全貌を...

caymezon.com

2026.02.21

• OpenAI Codex CLI完全ガイド｜ターミナルで動くOpenAIのAIエージェントの全貌【2026年3月最新】

OpenAI Codex CLI完全ガイド｜ターミナルで動くOpenAIのAIエージェントの全貌【2026年3月最新】

はじめに「Claude CodeやGemini CLIみたいなAIエージェントを、OpenAIのモデルで使いたい…」「ターミナルで動くAIエージェントの中で、OpenAIが出しているものって何？」そんな疑問を持つエンジニアに向けて、Open...

caymezon.com

2026.03.28

• 【まとめ記事】Claude Code完全攻略ロードマップ｜全記事まとめ

【2026年版】Claude Code完全攻略ロードマップ｜セットアップからVSCode活用・コマンド習得まで全記事まとめ

はじめに「Claude Codeに興味があるけど、何から始めればいいかわからない」「Claude Codeを使い始めたけど、もっと使いこなしたい」この記事は、Claude Codeに関するすべての記事を体系的にまとめたロードマップです。初心...

caymezon.com

2026.03.21

タグ: #CodexCLI #ClaudeCode #GeminiCLI #AI比較 #OpenAI #Google #Anthropic #ターミナル #開発効率化

The post Claude Code vs Gemini CLI vs Codex CLI｜できること・できないことを徹底比較【2026年3月版】 first appeared on CayTech Lab.

「Claude CodeやGemini CLIみたいなAIエージェントを、OpenAIのモデルで使いたい…」

「ターミナルで動くAIエージェントの中で、OpenAIが出しているものって何？」

そんな疑問を持つエンジニアに向けて、OpenAI Codex CLIの全貌を徹底解説します。

OpenAIが2025年4月に公開したCodex CLIは、2026年3月時点でバージョンv0.117.0に達し、単なるコード補完ツールから本格的なターミナル型AIエージェントへと進化しました。特にTerminal-Bench 2.0（ターミナル作業能力のベンチマーク）で**77.3%**というスコアは、同カテゴリのツールの中で最高水準です。

本記事では、2026年3月時点の最新情報をもとに、Codex CLIの全体像から実践的な活用方法まで徹底解説します。

この記事で分かること

• Codex CLIとは何か（Claude Code・Gemini CLIとの違い）
• できること・主な機能
• メリット・デメリットの詳細分析
• 承認モード（Approval Policy）とサンドボックスの使い方
• AGENTS.mdによるプロジェクト設定
• 料金体系と使い分け
• インストール手順（Windows/Mac/Linux対応）
• 実践的な活用シーン

こんな人におすすめ

• OpenAIのモデル（GPT-5系）でターミナルAIエージェントを使いたい開発者
• CI/CDパイプラインにAIエージェントを組み込みたいエンジニア
• 完全自動化に安全なサンドボックスを使いたい人
• Claude CodeやGemini CLIとの比較で選択肢を広げたい人
• オープンソースのAIエージェントをカスタマイズして使いたい人

Codex CLIとは

基本概念

Codex CLIは、OpenAIが開発・オープンソース公開しているコマンドライン型のAIエージェントです。

■ターミナルネイティブ
└→ コマンドラインから直接OpenAIモデルとやり取り
└→ エディタとシームレスに統合

■ローカルファイルアクセス
└→ プロジェクトファイルを直接読み書き
└→ ディレクトリ全体を丸ごと解析

■エージェント機能
└→ ファイル編集・シェル実行・Git操作を自律実行
└→ 複数ステップのタスクを自動的に処理

GitHubリポジトリはApache-2.0ライセンスで公開されており、誰でもソースコードを確認・改変・貢献できます。

他のAIエージェントとの違い

2026年3月時点の最新バージョン

Codex CLIでできること

1. ファイル操作（作成・編集・削除）

ローカルファイルを直接操作できます。

# Codex CLIを起動
codex

# 指示例（プロンプトで入力）
> main.py のバグを修正して保存して

> 新しいファイル utils.ts を作成して、日付フォーマット関数を実装して

> src/ フォルダ内の全 .ts ファイルにエラーハンドリングを追加して

2. コードの理解と分析

プロジェクト全体を読み込み、深い分析が可能です。

> このプロジェクト全体のアーキテクチャを分析して、セキュリティ上の問題点を指摘して

> src/components/ フォルダの全コンポーネントを確認して、重複している処理をリストアップして

gpt-5.3-codexモデル使用時は100万トークンのコンテキストに対応しており、大規模なコードベースを丸ごと保持したまま会話できます。

3. シェルコマンドの実行

> テストを実行して、失敗したケースがあれば原因を分析して修正して

> npm run build してエラーがあれば解決して

> git log を確認して、今週のコミット内容をまとめて

4. Git操作の自動化

> 今の変更を feature/fix-bug ブランチにコミットしてプッシュして

> git の差分を確認して、適切なコミットメッセージを作成してコミットまで完了させて

5. Web検索との連携

デフォルトで有効化されており、最新情報をリアルタイムに取得しながらコードを生成できます。

# 最新ライブラリ情報を調べながらコードを書く
> React 19 の新しいフック useOptimistic を使った実装例を見せて

# セキュリティアドバイザリを参照しながら修正
> この依存パッケージに既知の脆弱性がないか確認して

6. 大規模ドキュメント・コードの一括処理

> content/ フォルダ内の全記事をスキャンして、古いAPIの呼び出し箇所を
> 新しいバージョンに一括置換して保存して

主要機能の詳細

承認モード（Approval Policy）【安全のために重要】

Codex CLIの最大の特徴が細かく制御できる承認ポリシーです。--approval-policy フラグまたは config.toml で設定します。

# デフォルト（on-request）: ワークスペース外の操作のみ承認を求める
codex

# 読み取り専用: 状態変更・破壊的操作は全て承認
codex --approval-policy untrusted

# 完全無効: 全ての承認プロンプトをスキップ（サンドボックスは有効）
codex --approval-policy never

# 危険モード: サンドボックス・承認を完全無効化（隔離環境専用）
codex --dangerously-bypass-approvals-and-sandbox

最初は on-request（デフォルト）で使うことを強く推奨します。

サンドボックス実行【Codex CLI独自の安全機能】

Codex CLIはOSネイティブの機能でコマンド実行を隔離します。macOS/Linux/WSL/Windows Nativeで実装が異なります。

■ read-only（読み取り専用）
└→ ファイル閲覧のみ。編集・コマンド実行は承認必要

■ workspace-write（デフォルト）
└→ ワークスペース内のファイル読み書き・通常コマンドは自動許可
└→ ネットワークアクセスやワークスペース外への変更は制限

■ danger-full-access
└→ ファイルシステム・ネットワーク境界を完全解除

Claude CodeやGemini CLIにはないサンドボックス機能により、--approval-policy never と組み合わせても安全な完全自動化が実現できます。

AGENTS.md（プロジェクト設定ファイル）【Claude CodeのCLAUDE.mdに相当】

Codexが起動時に自動読み込みするMarkdown形式の指示ファイルです。

# プロジェクト概要
このプロジェクトはNext.js + TypeScriptで構築したブログシステムです。

# コーディング規約
- すべてのやり取りは日本語で行うこと
- コメントはコードの右側に記述すること
- TypeScript strict モードを厳守すること
- 不要なboilerplateコードは書かないこと

# 開発コマンド
- ビルド: npm run build
- テスト: npm test
- Lint: npm run lint

# セキュリティポリシー
- .envファイルは絶対に読み取らないこと
- node_modules は絶対に編集しないこと
- 本番環境のDBに接続するコマンドは実行しないこと

読み込み順序（優先度が高い順）：

AGENTS.mdのポイント:

• 禁止事項の明記が特に効果的（full-autoモードでの暴走防止）
• 正確なビルド・テストコマンドを記述しておくと精度が上がる
• セキュリティポリシーを明記することで機密情報の漏洩を防止

config.toml（設定ファイル）

AGENTS.mdがプロンプトの指示なら、config.tomlはCLI自体の動作設定です。

# ~/.codex/config.toml（ユーザーレベル）
model = "gpt-5.4"                    # デフォルトモデル
sandbox_mode = "workspace-write"      # サンドボックスモード
approval_policy = "on-request"        # 承認ポリシー

[features]
multi_agent = true                    # マルチエージェントv2を有効化
web_search = true                     # Web検索を有効化

MCP（Model Context Protocol）連携【拡張性が魅力】

MCP対応により、外部ツールとの連携を自由に追加できます。

# ~/.codex/config.toml でMCPサーバーを設定
[mcp_servers.github]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-github"]
enabled = true

[mcp_servers.postgres]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-postgres"]
enabled = true

設定後は /mcp コマンドで接続済みツールを確認できます。GitHubのIssue読み書きやPostgreSQLへの問い合わせを、Codexに自然言語で指示できるようになります。

マルチエージェントv2【v0.117.0〜】

v0.117.0で追加された機能で、複数のサブエージェントを並列実行できます。

> /agent
# パスベースでサブエージェントを管理
# /root/agent_a でフロントエンド担当
# /root/agent_b でバックエンド担当
# → 両エージェントが並列で作業し、構造化メッセージで通信

大規模なリファクタリングや複数モジュールの同時実装に威力を発揮します。

スラッシュコマンド

会話の再開

# ローカル保存されたセッションを復元（長時間タスクに便利）
codex resume

前回の作業状態をそのまま引き継いで続きから始められます。

使用モデル

Terminal-Bench 2.0（ターミナル作業能力）: gpt-5.3-codex で 77.3%

※OpenAIはSWE-bench Verifiedにトレーニングデータ汚染が発見されたとして報告を停止。現在はSWE-bench Pro（56.8%）とTerminal-Bench 2.0が実質的な比較指標となっています。

/model コマンドでセッション中にいつでもモデルを切り替えられます。タスクの複雑さに応じてgpt-5.4とgpt-5.4-miniを使い分けることでコストを最適化できます。

料金体系

前提：APIキーが必須

Codex CLIを使うにはOpenAI APIキーまたはChatGPTのサブスクリプションが必要です。完全無料枠はありません。

ChatGPTサブスクリプション経由

APIキー（従量課金）

⚠️ APIキー従量課金の注意点
└→ 使用量が増えると青天井になる
└→ プロジェクトごとに予算上限を設定することを推奨
└→ gpt-5.4-mini（低コストモデル）を日常タスクに使うことでコスト削減可能

コスト最適化の考え方

gpt-5.4-mini を使う場面:
✅ 単純なファイル編集・コメント追加
✅ ドキュメント生成
✅ 簡単なリファクタリング

gpt-5.4 を使う場面:
✅ 複雑なアーキテクチャ設計
✅ 難易度の高いバグ修正
✅ セキュリティ審査

gpt-5.3-codex を使う場面:
✅ 大規模コードベース（数万行）の全体分析
✅ モノレポの依存関係解析

インストール手順

前提条件

• Node.js 22以上
• OpenAI APIキー または ChatGPT Plus以上のアカウント

Step 1: Node.jsのインストール確認

# バージョン確認
node -v
# v22.x.x 以上が表示されればOK

バージョンが表示されない場合は、Node.js公式サイトからLTS版をインストールしてください。

Step 2: Codex CLIのインストール

npm install -g @openai/codex

Step 3: APIキーの設定

OpenAI APIキーを使う場合（推奨）：

# Mac / Linux
export OPENAI_API_KEY="sk-..."
# または .bashrc / .zshrc に追記して永続化

# Windows (PowerShell)
[System.Environment]::SetEnvironmentVariable("OPENAI_API_KEY", "sk-...", "User")

ChatGPTアカウントを使う場合：

# 起動時にブラウザが開き、ChatGPTアカウントでログイン
codex
# → デバイスコードサインイン（v0.116.0〜）

Step 4: 初回起動と動作確認

# 起動
codex

# 動作確認
> このディレクトリの構造を教えて

これだけで準備完了です。

Windowsネイティブでの使用（実験的）

Windowsでのネイティブ実行は実験的サポートです。WSL（Windows Subsystem for Linux）の使用を強く推奨します。

# WSL（Ubuntu等）内で実行
npm install -g @openai/codex
export OPENAI_API_KEY="sk-..."
codex

メリット

1. ターミナル作業能力が最高水準

Terminal-Bench 2.0（ターミナル操作・シェルスクリプトの実行能力評価）で**77.3%**という業界最高水準のスコアを達成しています。

Terminal-Bench 2.0 比較:
Codex CLI (gpt-5.3-codex): 77.3%  ← 最高
Claude Code (Opus 4.6):    65.4%

シェル操作・コマンドライン作業が得意なのが最大の強みです。

2. サンドボックス実行による安全な完全自動化

Codex CLI:
✅ OSネイティブのサンドボックスでコマンド実行を隔離
✅ approval-policy=never でも安全な自動化が可能
✅ CI/CDパイプラインへの組み込みに最適

Claude Code・Gemini CLI:
❌ サンドボックス機能なし

3. モデルを柔軟に使い分けられる

gpt-5.4-mini: 低コストの日常タスク用
gpt-5.4:      高精度の複雑タスク用
gpt-5.3-codex: 100万トークンの大規模解析用

→ タスクに応じてコストと品質を最適化できる

4. Apache-2.0のオープンソース

✅ ソースコードを完全に確認・改変可能
✅ 社内環境への組み込みが容易
✅ コミュニティによる機能拡張が活発
✅ ベンダーロックインのリスクが低い

5. 高速処理（Cerebras統合）

Cerebras社との統合により、1,000トークン/秒超の高速推論が可能です（Claude Codeの約200トークン/秒と比較して5倍以上）。大量のファイルを素早く処理する際に特に有効です。

6. ChatGPT統合による統一体験

ChatGPT Web UI
    ↓ 同一アカウント
ChatGPT iOSアプリ
    ↓ 同一アカウント
VS Code拡張機能
    ↓ 同一アカウント
Codex CLI
→ どこでも同じ会話履歴にアクセス可能

7. マルチエージェントによる並列タスク実行

v0.117.0から本格化したマルチエージェントv2により、複数のサブエージェントが並列で作業できます。大規模なリファクタリングや複数モジュールの同時実装の効率が大幅に向上します。

デメリット・注意点

1. 完全無料枠がない

Codex CLI:   APIキー or ChatGPT Plus（$20/月〜）が必須
Gemini CLI:  Googleアカウントのみで0円から始められる

→ まず試してみたいだけの場合はGemini CLIの方が手軽

2. ターミナル操作が必須

GUIに慣れている方には学習コストがあります。

基本操作の習得: 1〜2時間
日常的な使いこなし: 1週間程度

3. Windowsネイティブのサポートが実験的

公式にはWSL経由の使用が推奨されており、Windowsネイティブでの動作は完全保証されていません。Windows環境で本格的に使う場合はWSLの導入が必要です。

4. コスト管理が必要

APIキー利用の場合、使用量に上限がないため予算管理が必要です。

⚠️ リスクケース:
- gpt-5.4で大規模コードベースを何時間も分析する
- マルチエージェントを多数起動する

✅ 対策:
- OpenAIダッシュボードで予算上限（Usage Limits）を設定
- 日常タスクはgpt-5.4-miniで処理する
- gpt-5.3-codexは大規模解析の時だけ使う

5. ChatGPT・Claude Codeほど日本語コミュニティが充実していない

日本語の情報や事例がまだ少ないため、問題が発生した際に日本語で解決策を探しにくい場面があります。

実践的な活用シーン

シーン1: CI/CDパイプラインへの組み込み

Codex CLIの最も得意な活用法です。

# GitHub Actions での使用例
- name: Codex でコードレビュー
  run: |
    codex --approval-policy never \
      "このPRの変更をレビューして、セキュリティ上の問題を報告して"

サンドボックス付きで完全自動化できるため、CI/CD環境への組み込みが安全です。

シーン2: 大規模コードベースの一括分析

# gpt-5.3-codexモデルで100万トークンを活用
codex
> /model gpt-5.3-codex

> このモノレポ全体を解析して、循環依存のあるモジュールを
> すべてリストアップして、解消の優先順位を提案して

シーン3: ターミナル作業の高度な自動化

> システムのログを解析して、過去24時間のエラーパターンを
> カテゴリ別に集計し、緊急度の高い問題から優先順位をつけてレポートを作成して

> 本番サーバーのデプロイ前チェックリストを実行して、
> 問題があれば詳細を報告して（実際のデプロイはしないこと）

Terminal-Bench 2.0スコア77.3%の実力が発揮される領域です。

シーン4: 夜間バッチ処理の自動化

# 夜間に安全な完全自動モードで実行（サンドボックスは有効）
codex --approval-policy never \
  "todayリリース候補のブランチをテストして、問題があればissueを作成して"

シーン5: 社内ツールへのカスタム組み込み

Apache-2.0ライセンスのため、社内ツールへの改造・組み込みが自由です。

# 独自のワークフローをAGENTS.mdで定義
# 社内のコーディング規約・セキュリティポリシーを強制適用
# 社内MCPサーバーと連携してDBや社内APIにアクセス

Amazon検索[本 Claude Code]

まとめ

Codex CLIは、2026年3月時点でClaude Code・Gemini CLIと並ぶ主要なターミナル型AIエージェントです。

主要なポイント：

✅ メリット

• ターミナル作業能力（Terminal-Bench）が業界最高水準（77.3%）
• サンドボックスによる安全な完全自動化が可能
• CI/CDパイプラインへの組み込みに最適な設計
• Apache-2.0オープンソースで社内カスタマイズが自由
• gpt-5.3-codexの100万トークンで大規模コードベースに対応
• Cerebras統合で1,000トークン/秒超の高速処理

⚠️ デメリット・注意点

• 完全無料枠はなし（APIキー or ChatGPT Plus必須）
• WindowsネイティブはWSL推奨
• 日本語コミュニティがまだ発展途上
• APIキー利用時は予算管理が必要

🎯 こんな方に特におすすめ

• CI/CDパイプラインにAIエージェントを安全に組み込みたい方
• シェル操作・ターミナル作業を高度に自動化したい方
• Apache-2.0ライセンスで社内ツールにカスタム組み込みしたい方
• gpt-5系モデルでターミナルエージェントを使いたい方

次のステップ：

まずは npm install -g @openai/codex でインストールして、簡単なファイル操作からお試しください。APIキーのコスト管理に注意しながら、日常的な開発タスクで効果を体感してみてください。

関連記事：

• Claude Code完全ガイド｜ターミナルで動くAIコーディングアシスタントの全貌

Claude Code完全ガイド｜ターミナルで動くAIコーディングアシスタントの全貌【2026年3月版】

はじめに「AIにコードを書かせたいけど、ブラウザとエディタを行き来するのが面倒…」そんな悩みを解決するのがClaude Codeです。2026年3月時点で、Anthropicが提供するターミナル型AIエージェントとして、開発者の間で急速に注...

caymezon.com

2026.02.14

• Gemini CLI完全ガイド｜ターミナルで動くGoogleのAIエージェントの全貌

Gemini CLI完全ガイド｜ターミナルで動くGoogleのAIエージェントの全貌【2026年3月最新】

はじめに「Claude CodeみたいなAIコーディングエージェントを試したいけど、費用を抑えたい…」「Googleが出しているターミナル版AIエージェントって何ができるの？」そんな疑問を持つエンジニアに向けて、Gemini CLIの全貌を...

caymezon.com

2026.02.21

• Claude Code vs Gemini CLI vs Codex CLI｜できること・できないことを徹底比較【2026年3月版】

Claude Code vs Gemini CLI vs Codex CLI｜できること・できないことを徹底比較【2026年3月版】

はじめに「ターミナル型AIエージェントが乱立していて、どれを選べばいいか分からない…」Claude Code（Anthropic）、Gemini CLI（Google）、Codex CLI（OpenAI）——三大AI企業がそれぞれターミナル...

caymezon.com

2026.03.28

タグ: #CodexCLI #Codex #OpenAI #AI #コーディング #開発効率化 #ターミナル #エージェント

The post OpenAI Codex CLI完全ガイド｜ターミナルで動くOpenAIのAIエージェントの全貌【2026年3月最新】 first appeared on CayTech Lab.

「Claude Coworkって面白そうだけど、具体的に何ができるの？」

この記事では、Coworkを実際に使ってみて「これは便利だ」と感じた利用シーンを10パターン厳選して紹介します。実際に入力するプロンプト例と得られる効果をセットで解説するので、読んだその日から試せます。

Coworkの概要・セットアップ方法については先にこちらをご覧ください。

【2026年最新】Claude Coworkとは？完全ガイド - PCデスクトップ作業でAIを使ってできること

はじめに「この繰り返し作業、AIに任せられたらいいのに」と思ったことはありませんか？Claude Coworkは、その願いをそのまま実現する機能です。ファイル整理・レポート作成・ブラウザ操作まで、あなたのPCを自律的に操作してタスクを完了し...

caymezon.com

2026.03.28

📋 10パターン一覧

パターン1：スクリーンショット・写真の自動整理

こんな状況に

デスクトップや特定フォルダに大量の画像ファイルが溜まっていて、整理する気力がない。

プロンプト例

「C:\Users\あなた\Pictures\Screenshots フォルダにある画像を、
 ファイルの作成日ごとに「2026-01」「2026-02」のような
 年月フォルダに分類して整理してください。
 さらに各月のファイル数をカウントして一覧表をExcelで出力してください」

得られる効果

• 手作業で数時間かかる分類が数分で完了
• ファイル数の集計表も自動作成（Excelで見やすく整形）
• 整理後のフォルダ構成をレポートとして出力することも可能

ポイント

日付ベースの分類は最も成功率が高い操作です。まずここから試してみてください。

パターン2：複数CSVを集計してExcelレポート作成

こんな状況に

各部署や取引先から届いたCSVファイルを毎月まとめて集計表を作っている。

プロンプト例

「C:\work\monthly-data フォルダ内にある
 2026年3月分のCSVファイル（接頭辞: sales_202603_）を全て読み込んで、
 部門別の売上合計と前月比を計算し、
 グラフ付きのExcel集計表として output\2026-03-report.xlsx に保存してください」

得られる効果

• 10ファイルの集計が手作業30分→数分に短縮
• グラフまで自動生成（棒グラフ・折れ線グラフ等）
• 計算ミスがなくなる

ポイント

「ファイル名のパターン」を伝えると、必要なファイルだけを正確に絞り込んでくれます。

パターン3：週次作業ログからレポートを自動生成

こんな状況に

毎週テキストやメモに作業記録を残しているが、上司や顧客への報告書に整形するのが手間。

プロンプト例

「C:\work\logs\2026-03-24-week.txt を読んで、
 以下のテンプレート（C:\work\templates\weekly-report.docx）に沿って
 週次報告書を作成し、C:\work\reports\2026-03-28-weekly.docx として保存してください。
 完了事項・進行中・来週の予定の3セクションに整理してください」

得られる効果

• 毎週30〜60分かかっていたレポート作成が5分以内に
• テンプレートのフォーマットを崩さずに整形してくれる
• 記録の書き方が雑でも、適切にまとめ直してくれる

ポイント

テンプレートファイルをあらかじめ用意しておくと仕上がりが安定します。

パターン4：フォルダ内の重複・古いファイル整理

こんな状況に

「○○_最終版」「○○_最終版2」「○○_本当の最終版」みたいなファイルが散乱している。

プロンプト例

「C:\work\documents フォルダ内のファイルを確認して、
 ファイル名に「_old」「_backup」「_旧」「_コピー」を含むファイルと、
 同じファイル名（番号違い）が複数あるものを一覧化してください。
 削除せずにリストとして archive-candidates.txt に書き出してください」

得られる効果

• 整理候補の一覧が自動作成される
• 削除はせずリストだけ作ってもらうことで、誤削除のリスクゼロ
• 一覧を確認した後、改めて削除を依頼できる

ポイント

削除操作はまず「一覧化だけ」に留めるのが安全。確認してから削除の2ステップにしましょう。

パターン5：Webページの情報収集→比較表・まとめ資料作成

こんな状況に

競合他社の料金ページや製品スペックを調べて比較表を作る仕事がある。

プロンプト例（Claude in Chrome拡張機能が必要）

「以下の3社のサービスページを順番に開いて、
 プラン名・月額料金・主な機能・無料トライアルの有無を確認して、
 Markdownの比較表を作成し C:\work\compare.md として保存してください。

 ・サービスA: https://example-a.com/pricing
 ・サービスB: https://example-b.com/pricing
 ・サービスC: https://example-c.com/pricing」

得られる効果

• 複数サイトを手作業でタブを行き来しながらメモする作業がゼロに
• 比較表が自動生成され、そのままWordやスライドに貼れる形に

ポイント

ブラウザ操作にはClaude in Chrome拡張機能のインストールが必要です（詳細は後述のパターン10）。

パターン6：ログイン済みWebサービスのデータ確認・操作

こんな状況に

毎朝・毎週、決まったWebサービスを開いてデータを確認するルーティン作業がある。

プロンプト例（Claude in Chrome拡張機能が必要）

「Chromeを起動してアクセス解析ツールのダッシュボードを開き、
 今週のページビュー数・ユニークユーザー数・直帰率を確認して、
 C:\work\analytics\2026-03-28.txt にメモしてください」

得られる効果

• 毎朝の「確認して記録する」ルーティンが完全自動化
• 確認し忘れや記録漏れがなくなる
• PCから離れている間に実行できる（Dispatch経由で）

ポイント

すでにログイン済みのブラウザプロファイルを使うのが鍵。ログイン作業をCoworkにさせる必要がなくなるため、2段階認証で止まるリスクがなくなります。

パターン7：メールの下書きを複数件まとめて作成

こんな状況に

複数の取引先へ似たような内容のメールを送る必要があるが、一件ずつ書くのが面倒。

プロンプト例

「C:\work\mail-list.csv を読み込んでください。
 各行には会社名・担当者名・送付内容が入っています。
 それぞれに合わせた件名と本文を含むメールの下書きを作成し、
 C:\work\mail-drafts\ フォルダに会社名.txt として保存してください」

得られる効果

• 10件のメール下書きが一度に生成される
• 担当者名や内容を個別にカスタマイズしてくれる
• 確認してから送信するだけの状態に整えてくれる

ポイント

CSVに「カスタマイズしたい情報」を列として入れておくと、パーソナライズ度が上がります。

パターン8：プロジェクトフォルダ内のドキュメント整備

こんな状況に

開発プロジェクトのフォルダ内にREADMEがなかったり、ファイル構成が把握しにくい状態になっている。

プロンプト例

「C:\projects\my-app フォルダの構成を確認して、
 プロジェクトの概要・ディレクトリ構造・主要ファイルの説明・
 環境構築手順を含むREADME.md を生成してください。
 既存のコードやpackage.jsonの内容を参考にしてください」

得られる効果

• コードを読みながらREADMEを手書きする作業がゼロに
• 新しいメンバーが参加したときにすぐ共有できる資料が整う
• 複数プロジェクト分を一気に処理できる

ポイント

package.json や設定ファイルを読み込んでもらうことで、より正確な内容が生成されます。

パターン9：外出中にスマホからタスクを投げてPC側で実行（Dispatch活用）

こんな状況に

移動中に「あ、あの資料整理しておきたい」と思いついた。PCは起動したまま。

使い方の流れ

1. スマホのClaudeアプリを開く
2. Coworkの「Dispatch」機能からタスクを送信
   例:「Documents/提案書フォルダのPDFを
       取引先名ごとにサブフォルダに整理して」
3. 帰宅するとPC上での整理が完了している

得られる効果

• 移動中・休憩中に思いついたタスクをその場で投げられる
• 帰宅時には作業完了状態になっている
• PCを操作する必要がない時間を有効活用できる

ポイント

PCは起動・ログイン状態である必要があります。 スリープ設定はオフにしておくか、「電源オプション」でスリープまでの時間を長く設定しておきましょう。

パターン10：Claude in Chrome拡張機能を活用したWebサービスの自動操作

Claude in Chrome拡張機能とは

CoworkがChromeブラウザを操作するためのブリッジ役となる公式拡張機能です。

セットアップの仕組み

Cowork（デスクトップアプリ）
    ↓ 操作指示
Claude in Chrome拡張機能（Chromeにインストール）
    ↓ 有料プランアカウントでサインインが必要
Chrome上のWebページを操作
    ↓ Webサービスのアカウントは別でOK
各種WebサービスのページをCoworkが操作

重要: 拡張機能のサインインに使うClaudeアカウント（有料プラン）と、開くWebサービスのアカウントは別々に設定できます。

応用できるシーン

プロンプト例（広告レポート確認）

「Chromeで広告管理ツールを開いて、
 今週のインプレッション数・クリック数・収益を確認し、
 C:\work\ad-reports\2026-03-28.txt に記録してください」

ポイントと注意

✅ ログイン済みのブラウザプロファイルを使う → ログイン不要で操作できる
✅ 2段階認証なしのサービスから試す → 止まるリスクが低い
⚠️ 重要な操作（削除・送信など）は確認ステップを入れる
⚠️ 初めての操作は「確認だけ」から始める

💡 うまく使うための共通のコツ

1. 許可フォルダを事前に登録する

作業させたいフォルダは必ず事前にCoworkのプロジェクトに追加しておきます。登録していないフォルダへのアクセスはできません。

2. 「削除」より「移動」や「一覧化」から始める

❌ 「古いファイルを削除して」
✅ 「古いファイルを一覧化して」→ 確認後 →「一覧のファイルをarchiveフォルダに移動して」

3. 出力先を明示する

「保存して」だけでなく「〇〇フォルダにXXX.xlsxとして保存して」のようにファイル名と場所を指定すると迷子になりません。

4. 段階的に依頼する

複雑な作業は一度に全部頼まず、ステップごとに確認しながら進めると安全です。

5. ブラウザ操作は「ログイン済み状態」を前提に

事前に必要なWebサービスにログインしておくことで、認証で止まるリスクを最小化できます。

📊 パターン別 難易度・効果まとめ

📚 関連記事

• 【2026年最新】Claude Cowork完全ガイド - PCデスクトップ作業をAIに丸投げする方法

【2026年最新】Claude Coworkとは？完全ガイド - PCデスクトップ作業でAIを使ってできること

はじめに「この繰り返し作業、AIに任せられたらいいのに」と思ったことはありませんか？Claude Coworkは、その願いをそのまま実現する機能です。ファイル整理・レポート作成・ブラウザ操作まで、あなたのPCを自律的に操作してタスクを完了し...

caymezon.com

2026.03.28

• 【2026年版】Claude Desktop 効果的な活用ガイド - ベストプラクティス完全版

【2026年版】Claude Desktop 効果的な活用ガイド - メリット・デメリット・ベストプラクティス完全版

はじめにClaude Desktopは、Claudeをネイティブアプリとして利用できる強力なツールです。本記事では、Web版との違い、効果的な使い方、トークン消費を最小化するテクニック、そして今後の展望まで、実践的な知見を完全網羅します。(...

caymezon.com

2026.01.24

📝 まとめ

Claude Coworkは「やりたいことを日本語で伝えるだけ」で動いてくれる、まさにデジタル秘書です。

今回紹介した10パターンのうち、まず試してほしいのは**パターン1（ファイル整理）とパターン2（CSV集計）**です。特別な準備不要で、効果を実感しやすい操作です。

慣れてきたらChrome拡張機能を使ったブラウザ操作に挑戦してみてください。定型的なWeb確認作業が自動化されると、「なんであれを手作業でやっていたんだろう」と感じるはずです。

Coworkの概要・セットアップ方法はこちら：

【2026年最新】Claude Coworkとは？完全ガイド - PCデスクトップ作業でAIを使ってできること

はじめに「この繰り返し作業、AIに任せられたらいいのに」と思ったことはありませんか？Claude Coworkは、その願いをそのまま実現する機能です。ファイル整理・レポート作成・ブラウザ操作まで、あなたのPCを自律的に操作してタスクを完了し...

caymezon.com

2026.03.28

参考リンク

• Claude公式 - Coworkを始める
• Claude Desktop ダウンロード

更新履歴

• 2026-03-28: 初版公開

The post 【実践編】Claude Cowork 活用事例10パターン - プロンプトの使い方と得られる効果まとめ first appeared on CayTech Lab.

「この繰り返し作業、AIに任せられたらいいのに」と思ったことはありませんか？

Claude Coworkは、その願いをそのまま実現する機能です。ファイル整理・レポート作成・ブラウザ操作まで、あなたのPCを自律的に操作してタスクを完了してくれます。コーディングスキルは一切不要。日本語で指示するだけです。

本記事では、Coworkの概要・機能・セットアップ方法・できること/できないことを初心者にもわかるよう徹底解説します。

🤖 Claude Coworkとは？

「チャット」との違い

Claude Desktopには3つのタブがあります。

チャットが「会話しながら一緒に作業する」のに対し、**Coworkは「指示したら自分でPCを操作して完了まで持っていく」**モードです。

チャット:
あなた → 指示 → Claude → 回答 → あなた → 次の指示 → ...（往復）

Cowork:
あなた → 指示 → Claude が自律的にPCを操作して完了まで実行

登場の背景

2026年1月にProプランユーザー全員に開放され、同年3月23日のアップデートでWindows/Mac両対応のコンピュータ操作機能が追加されました。それまで「開発者向け」だったAIエージェント機能が、誰でも使えるデスクトップツールとして進化したのがCoworkです。

💰 料金プランと機能差

全プランで同じ機能が使えます。 違いはレート制限（連続して使える量）のみです。まずはProプランで十分です。

無料プランではCoworkは使えません。 有料プランへのアップグレードが必要です。

🔧 セットアップ方法

必要なもの

1. Claude Desktopアプリ（最新版） — 古いバージョンにはCoworkタブがありません
2. Proプラン以上のアカウント
3. Windows 10以上 または macOS Sonoma以上

Windows Homeをお使いの場合: 一部機能が制限される報告があります。Windows Pro/Enterpriseを推奨します。

インストール手順

Step 1. 最新版のClaude Desktopをダウンロード

https://claude.com/download にアクセスしてWindows/Mac版をダウンロードします。

すでにClaude Desktopを入れている場合でも、上書きインストールを推奨します。古いバージョンではCoworkタブが表示されないことがあります。

Step 2. インストーラーを実行

ダウンロードしたファイルを実行し、追加ファイルの自動ダウンロードが完了するまで待ちます。

Step 3. サインインして「Cowork」タブへ

アプリ起動後、アカウントにサインインして上部の「Cowork」タブをクリックします。

Step 4. プロジェクト（フォルダ）を登録

左サイドバーの「最初のプロジェクトを作成」からアクセスを許可するフォルダを指定します。Coworkは許可したフォルダ内のファイルのみ操作します。

ブラウザ操作に必要な追加設定（Claude in Chrome拡張機能）

ブラウザを自動操作させたい場合は、「Claude in Chrome」拡張機能のインストールが別途必要です。

1. ChromeウェブストアでClaude in Chrome拡張機能をインストール
2. 拡張機能を有料プランのアカウントでサインイン
3. これによりCoworkがChromeを操作できるようになります

ポイント: 拡張機能へのサインインと、ブラウザで開くWebサービスのアカウントは別々でOKです。たとえば、拡張機能は有料プランのアカウントAでサインインしつつ、開くサービス（Google Analytics・AdSenseなど）は別のアカウントBでログイン済みの状態でも問題なく動作します。

✅ できること

1. ファイル操作

✅ 許可したフォルダ内のファイルを読み込み・作成・編集・保存
✅ フォルダの作成・ファイルの移動・コピー・名前変更
✅ 複数ファイルを横断して情報を収集・集計
✅ ExcelやWordファイルの作成（見栄えよく整形も可能）

2. コンピュータ操作（2026年3月〜）

✅ ブラウザ（Chrome等）の起動・ページ遷移・クリック・フォーム入力
✅ デスクトップアプリの起動・操作
✅ PowerShell・コマンドプロンプトの実行
✅ スクリーンショットの撮影・保存

3. マルチステップタスク

✅ 「〇〇して、次に△△して、最後に××して」という連続作業
✅ 条件分岐を含む処理（「もし〜なら〜して」）
✅ 複数のアプリをまたいだ作業

4. Dispatch（スマホからの遠隔操作）

✅ スマホのClaudeアプリからタスクを送信
✅ PCが起動していれば外出中でもタスクを実行
✅ 帰宅時に作業が完了している状態にできる

5. マーケットプレイス連携

✅ Google Drive・Gmail・Notion・Asana・DocuSign など
✅ 12種類以上のMCPコネクタ
✅ 企業向けプライベートマーケットプレイス

❌ できないこと・注意が必要なこと

考え方:

「人間がマウスとキーボードで操作できることはほぼできる」
「人間の判断・認証が必要な割り込み」が来ると止まる

🎯 こんな人・場面に特に向いている

✅ 毎週同じ作業を繰り返している（レポート・集計・整理）
✅ 複数のファイルやアプリをまたぐ作業が多い
✅ PC操作は自分でできるが、時間がもったいない
✅ プログラミングはわからないが自動化したい
✅ 外出中でも作業を進めておきたい

❌ 単純な質問や相談 → チャットで十分
❌ コードを書く・レビューする → Claude Code（コードタブ）向け
❌ ブラウザ上だけで完結する作業 → Web版Claudeで可能

⚠️ 使うときの注意点

セキュリティ

• Coworkに許可するフォルダは必要最小限に絞る
• 重要なファイルを含むフォルダは許可しない
• 操作前に「何をするか」の確認画面が表示されるので、必ず内容を確認してから承認する

失敗に備える

• 大量のファイル操作を行う前はバックアップを取っておく
• 初めての操作は小さなフォルダで試す
• 削除操作は特に慎重に（ゴミ箱経由にするよう指示するとよい）

レート制限

• Proプランはレート制限があるため、大量のタスクを連続で投げると制限に達することがある
• 重い処理はMax 5x/20xプランが快適

🔮 今後の展望

• スマホアプリとの連携強化（Dispatch機能の拡充）
• マーケットプレイスの対応サービス増加
• 企業向け機能（プライベートマーケットプレイス）の充実

📊 メリット・デメリットまとめ

メリット ✅

デメリット ❌

📚 関連記事

• 【2026年版】Claude Desktop 効果的な活用ガイド - ベストプラクティス完全版

【2026年版】Claude Desktop 効果的な活用ガイド - メリット・デメリット・ベストプラクティス完全版

はじめにClaude Desktopは、Claudeをネイティブアプリとして利用できる強力なツールです。本記事では、Web版との違い、効果的な使い方、トークン消費を最小化するテクニック、そして今後の展望まで、実践的な知見を完全網羅します。(...

caymezon.com

2026.01.24

• 【実践編】Claude Cowork 活用事例10パターン - プロンプト例と得られる効果まとめ

【実践編】Claude Cowork 活用事例10パターン - プロンプトの使い方と得られる効果まとめ

はじめに「Claude Coworkって面白そうだけど、具体的に何ができるの？」この記事では、Coworkを実際に使ってみて「これは便利だ」と感じた利用シーンを10パターン厳選して紹介します。実際に入力するプロンプト例と得られる効果をセット...

caymezon.com

2026.03.28

📝 まとめ

Claude Coworkは、「PCでやっている繰り返し作業を丸投げしたい」すべての人に刺さる機能です。

プログラマーでなくても、専門知識がなくても、日本語で「〇〇して」と指示するだけで、ファイル整理・レポート作成・ブラウザ操作まで自律実行してくれます。

まずはスクリーンショット整理やファイル集計など、失敗しても困らない小さなタスクから試してみてください。「こんなことも任せられるの？」という驚きがきっとあります。

具体的なプロンプト例と活用シーンは以下の記事で10パターン紹介しています。

【実践編】Claude Cowork 活用事例10パターン - プロンプトの使い方と得られる効果まとめ

はじめに「Claude Coworkって面白そうだけど、具体的に何ができるの？」この記事では、Coworkを実際に使ってみて「これは便利だ」と感じた利用シーンを10パターン厳選して紹介します。実際に入力するプロンプト例と得られる効果をセット...

caymezon.com

2026.03.28

参考リンク

• Claude公式 - Coworkを始める
• Claude Desktop ダウンロード

更新履歴

• 2026-03-28: 初版公開

The post 【2026年最新】Claude Coworkとは？完全ガイド - PCデスクトップ作業でAIを使ってできること first appeared on CayTech Lab.