トップ > AWS > Amazon BedrockでCloudFormationを読み解く 〜〜ゼロ/ワン/フューショットをAWS実運用で検証してみた〜

Amazon BedrockでCloudFormationを読み解く 〜〜ゼロ/ワン/フューショットをAWS実運用で検証してみた〜

AWS Amazon Bedrock AWS CloudFormation 生成AI
記事タイトルとURLをコピーする

こんにちは。CS部の山科です。

生成 AI を業務で使い始めると、 「それっぽいけど、そのまま成果物には使いづらい」 という壁にぶつかることが多いのではないでしょうか。

本記事では、ゼロショット／ワンショット／フューショットという考え方が AWS の実運用でどのように効くのかを、 CloudFormation で定義した EC2 リソースを題材に検証します。

検証には Amazon Bedrock（Playground） を使用し、 同一リソースに対してプロンプトのみを変えて比較しました。

ゼロショット・ワンショット・フューショットのおさらい

  • ゼロショット : 例を与えず、指示のみで出力させる方法

  • ワンショット : 例を1件与えてから出力させる方法

  • フューショット : 複数の例を与えてから出力させる方法

どちらもモデルを再学習させるものではなく、 プロンプト内で文脈を与えるだけという点が特徴です。

検証対象

  • CloudFormation で定義した EC2 インスタンス
  • Security Group / IAM Instance Profile / UserData / Tags を含む構成
  • 実務に近い最小構成

使用したCloudFormation（EC2）

WebInstance:
  Type: AWS::EC2::Instance
  Properties:
    ImageId: !Ref LatestAmiId
    InstanceType: !Ref InstanceType
    SubnetId: !Ref PublicSubnetId
    SecurityGroupIds:
      - !Ref WebSecurityGroup
    IamInstanceProfile: !Ref Ec2InstanceProfile
    MetadataOptions:
      HttpTokens: required
    UserData:
      Fn::Base64: !Sub |
        #!/bin/bash
        dnf -y update
        dnf -y install nginx
        systemctl enable nginx
        systemctl start nginx
        echo "Hello from CloudFormation" > /usr/share/nginx/html/index.html
    Tags:
      - Key: Name
        Value: sample-web-ec2
      - Key: Environment
        Value: dev
      - Key: Owner
        Value: platform-team
      - Key: CostCenter
        Value: 1234
      - Key: ManagedBy
        Value: CloudFormation

ゼロショットで EC2 リソースを説明させてみた

まずは、例（お手本）を与えずにゼロショットで EC2 リソースの説明を生成しました。 EC2 インスタンスの CloudFormation 定義のみを入力しています。

使用したプロンプト

あなたはAWSインフラエンジニアです。
以下のCloudFormationリソース（EC2 Instance）を読み取り、
役割、配置、通信、権限、初期設定、運用上の注意点を
日本語で説明してください。

（ここにブログのWebInstanceのYAMLを流し込む）

出力結果（一部抜粋）

このEC2インスタンスはNginxウェブサーバーとして構成されています。

1. 基本設定
 - インスタンスタイプは変数「InstanceType」から参照
 - AMIは変数「LatestAmiId」から最新のAMIを使用
 2. ネットワーク配置
 - パブリックサブネットに配置（PublicSubnetId参照）
 - WebSecurityGroupセキュリティグループを適用
 3. セキュリティ設定
 - IMDSv2が必須（HttpTokens: required）で、より安全なメタデータアクセスを強制
 - IAMロール（Ec2InstanceProfile）が割り当てられている
 4. 初期設定（UserData）
 - システムパッケージの更新
 - Nginxのインストールと自動起動設定
 - 簡単なHTMLページの作成
 5. 運用管理
 - 体系的なタグ付け：
  - 環境識別（Environment: dev）
  - 所有者管理（Owner: platform-team）
  - コスト管理（CostCenter: 1234）
  - 管理ツール識別（ManagedBy: CloudFormation）
6. 運用上の注意点
 - パブリックサブネットに配置されるため、適切なセキュリティグループ設定が重要
 - インスタンスプロファイルの権限範囲の定期的な見直しが必要
 - 本番環境では静的コンテンツの内容を適切に管理する必要あり
 - システムアップデートによる影響を考慮した運用計画が必要

ゼロショットでは、EC2の構成要素を広く拾い上げる出力となりました。

  • Nginxサーバーであること
  • IMDSv2必須であること
  • タグ構成
  • 運用上の注意点

など、テンプレートに含まれる情報を網羅的に言語化できています。

一方で、

  • 出力形式は固定されていない
  • 観点の優先度はモデル任せ
  • 「設計レビュー視点」というよりは「構成説明」に近い

という特徴がありました。

つまりゼロショットは、

構成理解・初期把握には十分 しかし設計書のドラフトとしては粒度が安定しない

という位置づけになります。

ワンショットで EC2 リソースを説明させてみた

次に、出力の観点と形式を指定したワンショットで同じリソースを説明させました。

ここでは、出力形式だけでなく、 踏み台サーバーという具体的なEC2の説明例を1件与えています。 この「例」が、生成AIにとっての思考の型として機能します。

使用したプロンプト

あなたはAWSインフラエンジニアです。 
以下の形式でCloudFormationリソース（EC2 Instance）を読み取り、日本語で説明してください。

リソース名：
役割：
配置/ネットワーク：
通信：
権限：
初期設定：
セキュリティ観点：
運用/注意点：


【例】
リソース名：BastionInstance（踏み台サーバー）
役割：外部からプライベートサブネット内のリソースにアクセスするための管理用サーバー
配置/ネットワーク：パブリックサブネット、Elastic IPを付与
通信：特定の拠点IPからの22番ポート(SSH)のみを許可
権限：管理者用のIAMロールが付与され、S3へのログ出力権限を持つ
初期設定：SSMエージェントの最新化と、接続ログの転送設定
セキュリティ観点：IMDSv2の有効化、および不要なパブリックアクセスの制限を確認
運用/注意点：踏み台が必要な時だけ起動する運用を検討

では、次のCloudFormationリソースを説明してください。

（ここにブログのWebInstanceのYAMLを流し込む）

出力結果（一部抜粋）

- リソース名：WebInstance（Webサーバー）

- 役割：
  - Nginxをインストールした基本的なWebサーバー
  - 静的なHTMLコンテンツを提供する
 
- 配置/ネットワーク：
  - パブリックサブネットに配置（PublicSubnetIdパラメータを参照）
  - インスタンスタイプはパラメータで指定可能 

- 権限：
  - Ec2InstanceProfileで定義されたIAMロールが付与 （具体的な権限は IAM ロールの定義による）

- 初期設定：
  - システムパッケージの更新
  - Nginxのインストールと自動起動設定
  - 簡単なテストページの配置

- 運用/注意点：
  - 環境はdev（開発環境）として設定
  - プラットフォームチームが管理
  - コストセンター1234に紐付け
  - タグベースの管理が可能（Name, Environment, Owner, CostCenter, ManagedBy）
  - システムアップデートが自動実行されるため、初回起動時に時間がかかる可能性あり

ワンショットでは、出力形式が明確に揃い、構造化された説明になりました。

特に、

  • 「役割」「配置」「権限」「初期設定」「運用/注意点」
  • パラメータ参照の明示

ゼロショットとの差は、

「何を書くか」をモデルに委ねるのではなく、 「どう整理するか」の型を与えたこと

にあります。

ただし、

  • 可用性設計（HA）
  • 監視・バックアップ戦略
  • セキュリティ設計の深掘り

といった“設計レビューの軸”はまだ弱い印象です。

ワンショットは、

整った説明文を安定して出すための方法 ドキュメント整形用途には十分有効

という位置づけと言えます。

フューショットで EC2 リソースを説明させてみた

次に、複数の例を与えたフューショットで同じリソースを説明させました。

今回のプロンプトでは、

  • 踏み台サーバー（管理用途）

  • アプリケーションサーバー（ALB配下）

  • バッチサーバー（内部処理系）

といった役割の異なるEC2例を複数提示しています。

これにより、生成AIは

  • ネットワーク観点

  • 通信設計観点

  • IAM権限観点

  • 運用・監視観点

といった「設計レビューの軸」を反映しやすくなります。

使用したプロンプト

あなたはAWSインフラエンジニアです。 
以下の形式でCloudFormationリソース（EC2 Instance）を読み取り、日本語で説明してください。

リソース名：
役割：
配置/ネットワーク：
通信：
権限：
初期設定：
セキュリティ観点：
運用/注意点：


【例1】
リソース名：BastionInstance（踏み台サーバー）
役割：外部からプライベートサブネット内のリソースにアクセスするための管理用サーバー
配置/ネットワーク：パブリックサブネット、Elastic IPを付与
通信：特定の拠点IPからの22番ポート(SSH)のみを許可
権限：管理者用のIAMロールが付与され、S3へのログ出力権限を持つ
初期設定：SSMエージェントの最新化と、接続ログの転送設定
セキュリティ観点：IMDSv2の有効化、および不要なパブリックアクセスの制限を確認
運用/注意点：踏み台が必要な時だけ起動する運用を検討


【例2】
リソース名：AppInstance（社内Webアプリ）
役割：社内向けWebアプリケーションをホストするアプリケーションサーバー
配置/ネットワーク：プライベートサブネットに配置し、ALB（別リソース）からのアクセスを前提
通信：ALBのセキュリティグループからの80/443のみ許可、管理はSSMを利用（SSHは原則閉塞）
権限：アプリ用IAMロールが付与され、Parameter Store/Secrets Managerの参照やCloudWatch Logs出力を許可
初期設定：アプリのデプロイ準備（必要パッケージ導入）、ログのCloudWatch転送設定、定期パッチ適用の前提
セキュリティ観点：パブリックIPを付与しない、最小権限IAM、IMDSv2必須、OS更新の運用を前提
運用/注意点：Auto Scalingの導入余地、パッチ適用手順、ログ/メトリクス監視（CPU/メモリ/ディスク）を整備


【例3】
リソース名：BatchInstance（夜間バッチ処理）
役割：夜間に集計・ETL等のバッチ処理を実行するワーカーサーバー
配置/ネットワーク：プライベートサブネットに配置し、外部通信はNAT Gateway経由（またはVPCエンドポイント）を前提
通信：インバウンドは原則不要（必要時のみ社内CIDRからの限定SSH/管理はSSM）、アウトバウンドはS3や外部API向け
権限：S3の入出力、CloudWatch Logsへの出力、必要に応じてDynamoDB等へのアクセス権限を持つIAMロールを付与
初期設定：ジョブ実行ユーザー作成、実行スクリプト配置、ログ出力（/var/log等）とローテーション、時刻同期
セキュリティ観点：インバウンド最小化、権限の絞り込み、IMDSv2必須、機密情報はSecrets Manager等で管理
運用/注意点：実行スケジュール（EventBridge等）、失敗時リトライ/通知、処理時間の監視、スケール（並列実行）設計


では、次のCloudFormationリソースを説明してください。

（ここにブログのWebInstanceのYAMLを流し込む）

出力結果（一部抜粋）

- リソース名：WebInstance（Webサーバー）

- 役割：
  - Nginxをホストする基本的なWebサーバー
  - 静的なHTMLコンテンツを提供（初期設定では "Hello from CloudFormation" を表示）
 
- 配置/ネットワーク：
  - パブリックサブネットに配置（SubnetId: !Ref PublicSubnetId）
  - WebSecurityGroupによるネットワークアクセス制御

- 権限：
  - AMインスタンスプロファイル（Ec2InstanceProfile）が付与
  - 具体的な権限はIAMロールの定義に依存

- 初期設定：
  - システムパッケージの更新（dnf -y update）
  - Nginxのインストールと自動起動設定
  - 基本的なHTMLコンテンツの配置

- 運用/注意点：
  - 環境はdev（開発環境）として タグ付け
  - コスト管理（CostCenter）とオーナー情報（Owner）がタグで明確化
  - 単一インスタンスのため、可用性に懸念（Auto Scalingなし）
  - パッチ管理戦略の検討が必要
  - メトリクスやログ監視の設定が必要
  - バックアップ戦略の検討が必要

フューショットでは、出力の「視点」が明確に変わりました。

今回の出力では、例えば以下のような観点が含まれました。

  • Auto Scaling未導入による可用性リスク
  • パッチ管理戦略の必要性
  • 監視（メトリクス・ログ）の検討
  • バックアップ戦略の必要性

ただし、これは「フューショットで例を増やしたから自動的に深くなる」というより、 例の中に可用性・監視・運用といった観点を埋め込んでいた影響が大きいと考えられます。

踏み台・アプリサーバー・バッチサーバーといった役割の異なる例を提示したことで、 「EC2をどういう観点で語るべきか」という枠組みが、 出力に反映されやすくなったと整理できます。

これは、例に埋め込んだ観点がそのまま出力に影響しているためです。

フューショットは単なる整形というより、 例を工夫することで、出力の観点（レビュー観点）を揃えやすくできる手法だと感じました。

比較して見えた違い

観点 ゼロショット ワンショット フューショット
例の有無 なし 1件 複数件
出力形式 モデル任せ 指定形式で安定 指定形式で安定
粒度 毎回変わる ある程度揃う 揃いやすい
情報整理 説明寄り 項目に沿って整理 例に含めた観点に沿って整理
観点漏れ 起きやすい 減る 例の観点が反映されやすい
思考の傾向 構成説明レベル 整理された説明 例に引っ張られた説明
運用視点 弱い傾向 最低限含まれる 例に含めれば反映される
可用性・監視への言及 ほぼ出ない 出る場合もある 例に含めた場合は出やすい
実務利用 構成理解・壁打ち ドキュメント整形 観点を揃えたドラフト生成
安定性 低い 中 高い（例の設計に依存）
コントロール性 低い 中 高い（例と指示の設計に依存）

フューショットはモデルを賢くする手法ではない。 しかし、与えた例の“思考の型”を出力に反映させやすい。

実運用での使い分け

  • ゼロショット
    • 構成理解
    • 初期把握
    • 壁打ち用途
  • ワンショット
    • 出力形式を揃えたいとき
    • 設計書のドラフト整形
    • チーム共有前の文章整理
  • フューショット
    • 特定の観点（例：可用性・監視・セキュリティ）を含めたいとき
    • 設計レビュー観点を揃えたいとき
    • 論点の抜け漏れを減らしたいとき

生成 AI の出力は、人のレビューを前提に使うことで初めて実務に耐えると感じました。

また、

フューショットの本質は「例の量」ではなく、 「どの観点を例に埋め込むか」にある。

補足：生成AIが出力する「リソース名」の扱い

なお、生成AIは CloudFormation の論理ID を 「リソース名」として出力する傾向がありました。

一方で、実運用では Name タグでリソースを識別することが多いため、 設計書用途では両者を併記する方が実用的だと感じました。

<例>

リソース名：
- 論理ID：
- Nameタグ：

まとめ

  • CloudFormation の EC2 リソース説明は Amazon Bedrock で十分に生成できる
  • ゼロショットは理解補助として有効
  • ワンショットは出力形式を安定させるのに有効
  • フューショットは、例に含めた観点を反映させたドラフト生成に有効

AWS 運用に生成 AI を取り入れる際は、 モデル選択よりも「どの観点を与えるか」が重要だと感じました。

今回はEC2を題材にしましたが、 同じ考え方を使えば、複雑な構成図の読み解きや、 引き継ぎ資料・設計レビュー用ドキュメントの自動生成にも応用できそうです。

生成AIは「答えを出すツール」というよりも、

設計観点を整理するための補助装置

として使うのが、実運用では現実的だと感じました。

お客様の環境をより深く、素早く理解し、価値ある提案に繋げるための武器として、今後もBedrockを使い倒していきたいと思います。

山科 椋 (記事一覧)

2025年10月中途入社

IX2部所属

ガジェット関連が好きです