トップ > AI > 【re:Inent 2025】Builders' Session「Landing Zone: Deploy Smarter with AI」参加レポート

【re:Inent 2025】Builders' Session「Landing Zone: Deploy Smarter with AI」参加レポート

AI AWS re:Invent 2025
記事タイトルとURLをコピーする

はじめに

エンタープライズクラウド本部の小林です。

今回、AWS re:Invent 2025 現地参加しており、動画なりあとから見られるセッションは弊社の強つよな先輩方に譲って、まずは現地ならではの Builders' Session で開催されたセッション「Landing Zone: Deploy Smarter with AI」に参加しましたので、どんなものだったのか、ハンズオンを通して構築した仕組みのアイディアなどを記載します。

なお、Builders' Session とは何ぞや？などについては（これも）過去の記事に譲ります。

Landing Zone: Deploy Smarter with AI

このセッションでは、AI を活用して、AWSのランディングゾーン（クラウド利用の土台）を対話形式で設計し、自動生成されたテンプレートを用いてデプロイするまでの一連の流れを体験するものでした。

1. システムアーキテクチャと動作フロー

環境は、「設計・生成を行う管理環境」と「実際にインフラが稼働する環境」 が分離。
ユーザーは管理アカウント内のIDE（コックピット）から、別アカウントへインフラを展開する構成となっていました。

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#000000',
    'primaryBorderColor': '#232F3E',
    'lineColor': '#FF9900',
    'tertiaryColor': '#f2f3f3',
    'clusterBkg': '#f2f3f3',
    'clusterBorder': '#888888',
    'fontSize': '14px'
  }
}}%%
flowchart TD
    %% --- スタイル定義 ---
    %% 線（リンク）の色をAWSオレンジ(#FF9900)で太く統一
    linkStyle default stroke:#FF9900,stroke-width:2px;

    %% クラス定義: AWSらしい色分け
    classDef default fill:#ffffff,stroke:#232F3E,stroke-width:1px,color:#000;
    classDef mgmt fill:#ffffff,stroke:#0073BB,stroke-width:3px,color:#000;
    classDef net fill:#ffffff,stroke:#1A8934,stroke-width:3px,color:#000;
    classDef compute fill:#ffffff,stroke:#FF9900,stroke-width:3px,color:#000;

    %% --- 構成図本体 ---
    
    %% 管理アカウント
    subgraph MgmtAccount ["管理 AWS アカウント"]
        direction TB
        User("ユーザー / 開発者") -->|"ブラウザ経由<br>でアクセス"| IDE_EC2["IDE ワークステーション EC2<br>(VS Code + Amazon Q)"]
        
        subgraph IDE_Internal ["IDE 内部プロセス"]
            IDE_EC2 -->|"実行"| Titanium_MCP["Titanium MCP サーバー"]
            Titanium_MCP -->|"生成"| Titanium_YAML("Titanium.yaml")
            Titanium_MCP -->|"生成"| CFn_Templates("CloudFormation<br>テンプレート")
        end
    end

    %% ネットワークアカウント
    subgraph NetAccount ["ネットワークアカウント"]
        direction TB
        CFn_Templates -->|"デプロイ"| Net_Stack["ネットワーク<br>インフラ スタック"]
        
        subgraph Net_Components ["ネットワーク コンポーネント"]
            TGW["AWS Transit<br>Gateway"]
            IPAM["VPC IPAM"]
            R53["R53 Resolver"]
            
            subgraph Insp_VPC ["検査用 VPC"]
                FW["Network Firewall"]
                IGW["インターネット<br>ゲートウェイ"]
            end
        end
    end

    %% アカウント間の連携
    IDE_EC2 -..->|"デプロイ操作"| Net_Stack

    %% --- クラスの適用 ---
    %% 管理アカウント系は青枠
    class MgmtAccount,IDE_Internal mgmt;
    %% ネットワーク系は緑枠
    class NetAccount,Net_Components,Insp_VPC net;
    %% コンピュート系はオレンジ枠
    class IDE_EC2,Titanium_MCP compute;
    %% その他はデフォルト（黒枠・白背景）
    class User,Titanium_YAML,CFn_Templates,Net_Stack,TGW,IPAM,R53,FW,IGW default;

Phase 1: AIによる設計とコード生成 (管理アカウント)

ユーザーはブラウザからIDE Workstation（EC2）へアクセス。
このEC2は VS Code、Amazon Q、Titanium Agent、そして安全のためのガードレールがセットアップされた専用の開発環境となり、ここでの対話により、設計図（Titanium.yaml）と実装コード（CloudFormationテンプレート）が生成されていました。


Phase 2: クロスアカウントデプロイ (ネットワークアカウント)

生成されたテンプレートを使用し、IDEからネットワーク専用アカウントへリソースを展開。これにより、組織全体の通信ハブとなる Transit Gateway や、通信を一元的に検査する Network Firewall (Inspection VPC) が構築され、セキュアな環境が完成しました。


2. なぜAIを使用するのか

AWS 環境をガイドラインに則って複数作成する場合、これまでは例えば CloudFormation テンプレートを準備しておく・ServiceCatalog に登録し起動するなどの方法をとっていたかと思います。

今回、AI を単なる自動化ツールとしての利用ではなく、「人間の曖昧な意図を翻訳し、膨大な選択肢から最適な組み合わせを推奨する『専門家の副操縦士（Expert Co-pilot）』」として位置づけ、以下のような情報に基づく専門知識を集約し提供させていました。

  • 顧客業界のコンプライアンス要件
  • 顧客の地理的範囲とデータ保存場所のニーズ
  • セキュリティ体制とリスク許容度
  • 組織構造とチームのワークフロー
  • 運用上の設定

3.「生成AI」と「決定論的コード」による役割分担

具体的には MCP サーバ内のスクリプトで実装。先述の Phase 1 は下記 2 つの役割に分かれていました。

  • 1A：翻訳と正規化
    ユーザーの曖昧な「ビジネス要件」を自然な対話で受け取り、それを技術的な仕様に変換（翻訳）。
  • 1B：決定論的エンジン
    AIが解釈した要件に基づき、事前に検証されたテンプレートをパラメータ化して出力。

AIを使用する際、「ハルシネーション（もっともらしい誤情報）」が特に懸念されますが、今回、ここでは下記 3 点により「同じ入力からは、何度実行しても同じ成果物が出力される」ことをコードレベルで担保していました。

  1. 入力の正規化: 自然言語をプログラムで定数化。
  2. ロジックの固定: AIの推論ではなく、条件分岐コードで構成を決定。
  3. 原本の固定: 検証済みの静的ファイルを使用。

MCP サーバ内の具体的な処理を図示してみます

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#000000',
    'primaryBorderColor': '#232F3E',
    'lineColor': '#FF9900',
    'tertiaryColor': '#f2f3f3',
    'clusterBkg': '#f2f3f3',
    'clusterBorder': '#888888',
    'fontSize': '14px'
  }
}}%%
graph TD
    %% --- スタイル定義 (AWS High Contrast Style) ---
    %% 全体共通: 線をAWSオレンジで太く
    linkStyle default stroke:#FF9900,stroke-width:2px;

    %% クラス定義: 背景は白(#ffffff)で統一し、枠線で意味を表す
    %% Input: 汎用的なグレー枠
    classDef input fill:#ffffff,stroke:#333,stroke-width:2px;
    %% Process: 青枠 (AWS Compute/Logic color)
    classDef process fill:#ffffff,stroke:#0073BB,stroke-width:2px;
    %% StaticData: 濃い黄色/ゴールド枠 + 点線 (Original intention preserved but darker)
    classDef staticData fill:#ffffff,stroke:#F58E00,stroke-width:2px,stroke-dasharray: 5 5;
    %% Output: 緑枠 (Success color)
    classDef output fill:#ffffff,stroke:#1A8934,stroke-width:4px;
    %% AI: 紫枠 + 点線 (AWS ML color)
    classDef ai fill:#ffffff,stroke:#8C4FFF,stroke-width:2px,stroke-dasharray: 2 2;

    %% --- グラフ本体 ---

    User("ユーザー入力 (回答)<br>自然言語: '予算は少なめで'"):::input

    subgraph Advisor_Phase ["Phase 1A: 翻訳と正規化 (AI)"]
        direction TB
        AI_Trans("AIによる翻訳<br>意図理解・パラメータ抽出"):::ai
        YAML("中間定義ファイル"):::output
    end

    subgraph Generator_Phase ["Phase 1B: 決定論的エンジン (AI不使用)"]
        direction TB
        
        %% プロセス
        RuleMapping("ルールベースのマッピング<br>(YAML値 → テンプレート引数)"):::process
        TemplateRender("テンプレートレンダリング<br>(Jinja2 変数置換)"):::process
        
        %% 静的データ
        Patterns[("静的業界パターン<br>(固定JSON)")]:::staticData
        Templates[("静的スケルトン<br>(固定CloudFormation)")]:::staticData
        
        %% エンジン内のフロー
        Patterns --> RuleMapping
        RuleMapping --> TemplateRender
        Templates --> TemplateRender
    end

    Result("一意の CFn テンプレート"):::output
    
    %% 全体の接続
    User --> AI_Trans
    AI_Trans --> YAML
    YAML --> RuleMapping
    TemplateRender --> Result

Phase 1A: 翻訳と正規化

AI を「ユーザーインターフェース」として利用。しかし最終的な構成値の決定権はプログラムコードが保持します。

  • AIへの厳格なガードレール:
    • システム内部でAIに対して「独自の構成を作成せず、必ず定義されたツールを介して出力すること」という厳格な制約を定義。これにより、AIが勝手にリソースを捏造するハルシネーションを防止していました。
  • ロジックによる入力正規化
    • ユーザーの曖昧な自然言語（例: "予算はあまりない"）は、そのまま使われるのではなく、内部のマッピング関数によって処理されていました。

    • プログラム上で「予算区分が『低』なら、設定値Aを適用する」といった条件分岐がハードコーディングされており、AIの揺らぎを排除してパラメータに変換。

      # Map budget to cost controls
    if budget == "under_1m":  # ← 「予算はあまりない」という意図に対する条件分岐
        # Adjust budgets for cost-conscious organizations
        variables["budgets"] = [{
            "accounts": ["Management"],
            "name": "monthly-budget",
            "time_unit": "MONTHLY", 
            "type": "COST",
            "amount": 3000,           # ← パラメータ（3000）をハードコード
            "include_upfront": True,
            "include_tax": True,
            # ... (以下固定パラメータが続く)
            "unit": "GBP",
            "notifications": [{"type": "ACTUAL"}]
        }]

        # Enable cost optimization
        variables["cost_optimization_solutions"]["InstanceScheduler"] = True
  • 業界標準定義の適用
    • 業界ごとのベストプラクティス（医療、金融、公共など）は、外部JSONデータとして管理。AIの知識ベースではなく、この静的ファイルを読み込むことで、常に最新かつ正確なデフォルト値が適用されます。

Phase 1B: 決定論的エンジン

AI は含まれず、完全にプログラム的なロジックのみで構成されます。

  • ルールベースのマッピング
    • 中間定義ファイル（YAML）を受け取り、具体的なAWSリソースの構成を決定します。
    • ネットワーク、セキュリティ、ID管理などでそれぞれで専用の処理を実装。入力値に基づき、「どのテンプレートを使用するか」「どのオプションを有効化するか」を機械的に判定。
  • テンプレートレンダリング
    • 判定された値を、実際のコードに埋め込みます。
    • 一般的なテンプレートエンジン（Jinja2等）を使用し、値をスケルトンファイルに流し込みます。ここには推論は使用されず、単なる文字列置換処理が行われていました。
  • 検証済みスケルトン
    • システム内部には、事前にセキュリティ検証を済ませた「ゴールデンテンプレート（IaCの原本）」が静的ファイルとして格納。
    • AIがゼロからコードを書くのではなく、この検証済みテンプレートを組み合わせて出力。

5. 実際の動作イメージ

はじめに利用者より「ランディングゾーンの設計を手伝って」とチャットで問い合わせ。

AIより「セキュリティやコンプライアンスのベストプラクティスを備えた、基盤を準備するので、業種を教えて」とヒアリング開始

ユーザからは「小さい組織なので、今のところはシンプルなランディングゾーンにしたい」と、選択肢にない回答を提示。

AIはより詳細なヒアリングを実施

ユーザとしては全部まとめて回答はたいへんなので、「一度に全部答えるのは大変なので、1問ずつ順番に聞いて」とリクエスト

リクエストに応えて、AIとユーザの間で、一つずつ対話的にヒアリングと回答を実施

以下、画面キャプチャはありませんが、この結果をもとに CloudFormation テンプレートを一意に作成
→　このチャット画面からデプロイ指示、デプロイ時に問題があった場合は都度自動修正と再デプロイを実施していました

まとめ

わずか 1時間のセッションで、この間はひたすらに環境構築と理解でいっぱいいっぱいでしたが、あとで振り返ってみるとかなりいろいろとやっていました。

また特にセッション中、普段からランディングゾーンの設計・構築・運用を行っている方（英語圏の方）がおり、AWSの方と会話していたのが印象的でした。
私ももう少し英語力があればその場で理解して、より有意義な場にできたのかも、、と思えました。

英語あまりよくわからない身としてはそれでも何か聞き覚えのある単語が多いので何とかなる・構築はドキュメントを元に進められました。
怖がらずに参加してみて、あとで振り返ってみても十分な勉強になりましたので、気になるセッションがあればまずは出てみるとよいかと思います。


クラウド活用の「ちょっとした不安」や
「もっと良くしたい」に応えます
サーバーワークスは、AWSの構築から運用まで
幅広く支援しています
資料ダウンロード相談する


【12月1日から5日まで AWS re:Invent 2025 開催中！】
公式サイトはこちら
reinvent.awsevents.com

swx-takao-kobayashi