【AWS×生成AI連載｜ガバクラ運用の効率化～前編】ガバクラ運用の司令塔にBedrock Agentを。精度を極めるAPI設計とJSONL正規化で挑むインフラ自律化

はじめに

NTT西日本 1年目社員の野村です。私は現在、生成AIを活用したインフラ運用の高度化に取り組んでいます。生成AIは業務効率化の「有効な手段」として期待されていますが、ハルシネーション（情報の誤り）への懸念から、特に正確性と透明性が求められるガバメントクラウド（ガバクラ）環境では導入のハードルが高いのが現状です。本稿では、この「信頼性の壁」を技術で突破する実践事例として、Amazon Bedrock Agentを「司令塔」に据え、設定の自動化から視覚的な正当性検証までを実現した自律型運用モデルについて、その全貌を詳説します。

前編：ガバクラ運用の司令塔にBedrock Agentを。精度を極めるAPI設計とJSONL正規化で挑むインフラ自律化（本記事）
後編：「AIを疑う」ことで信頼を築く。Step Functionsと視覚的答え合わせによる自律型デプロイの完成

※本記事は2025年12月18日時点の情報に基づきます。

対象読者

生成AIの「精度・信頼性の壁」を突破したい実務家
ガバメントクラウドなどの高信頼インフラを運用するエンジニア
Amazon Bedrock Agentの具体的な活用例を知りたい開発者

目次

1. 背景・課題：ガバメントクラウド運用の現場から
2. Phase 1：Amazon Bedrock Agentによる自律型ワークフローの構築
　2.1 RAGからエージェント指向への転換
　2.2 構造化の要：JSONL中間変換による抽出精度の担保
　2.3 司令塔の「言語」を定義する：OpenAPIスキーマ設計の苦労
3. 直面した「自動化の壁」：効率化を阻む手作業の連鎖
　3.1 「紐づけ作業」が手作業のまま
　3.2 「AIが作ったコード」を誰も信じられない問題
4. Phase 2：アーキテクチャの再設計と「視覚的な答え合わせ」の実装
　4.1 「紐づけ作業」が手作業のまま➔IDマッピングの自動解決
　4.2 「AIが作ったコード」を誰も信じられない問題➔Mermaidによる「答え合わせ」の実装
5. 性能評価：従来比70%削減と信頼性担保の実証
6. まとめと今後の展望：自律型運用の完成に向けて

1. 背景・課題：ガバメントクラウド運用の現場から

ガバメントクラウド（ガバクラ）運用管理環境では、現在ASP事業者からのTransit Gateway（TGW）接続要求が急増しており、現場の大きな課題となっています。特にVPCアタッチメントによる接続は全体の過半数を占めています。

これら膨大な接続要求を、厳格なセキュリティ・コンプライアンス環境下でAWSコンソールから手作業で行う運用には、極めて深刻なリスクが潜んでいました。

設定ミスのリスク: Transit Gateway Route Table（TGW-RTB）におけるAssociation（関連付け）やPropagation（伝播）の定義ミスは、各自治体共通基盤の通信障害や、本来隔離されるべき環境間の意図しない疎通といったセキュリティ事故に直結します。
リードタイムの長期化: 手作業によるミスを防ぐための二重チェック、三重チェック、そして多くのエビデンス作成作業がボトルネックとなり、1つの接続設定に多大な工数を要していました。

図1. ガバメントクラウドにおけるApplication Service Provider（ASP）の接続例

本プロジェクトのゴールは、正確性が極めて重要となるこの定型業務に対し、Bedrock Agentを「司令塔」として適用し、「AWSコンソールのGUI操作からの脱却」と「人間が確信を持ってデプロイできる可視化された運用」を確立することです。

2. Phase 1：Amazon Bedrock Agentによる自律型ワークフローの構築

まず取り組んだのが、Excelベースの設定シートからYAMLコードを自動生成する仕組みの構築です。

2.1 RAGからエージェント指向への転換

当初はRetrieval-Augmented Generation（RAG、Knowledge Bases）にExcelの設定シートを読み込ませる構成を試みました。しかし、Claude 3.5 Sonnet v2を使用しても、結合セルや多層構造を持つ実務用Excelの文脈を十分には理解できず、誤った値を抽出するケースが見られました。

図2. KBでのテストプロンプト実行結果

そこで私は、「AIにすべての判断を任せるのではなく、厳格なロジックを持つLambdaをAgentが適切に使い分ける（オーケストレーション）」という設計思想に切り替えました。実際に設計/構築したアーキテクチャを下に示し、各リソースの役割を端的にまとめます。

図3. Phase 1 アーキテクチャ概略図

現環境のコード化
- Lambda（TG-1）⇔Transit Gateway：Transit Gatewayの現在の状況をboto3で取得
- Lambda（TG-1）⇔S3：取得した情報をCloudFormationに対応したYAML形式に変換し、S3に保存
VPCアタッチメント依頼時のコード化
- Lambda（BR-1）⇔S3：非構造化データである設定シートの内容をJSONLに構造化し、S3に保存
- Lambda（BR-2）⇔S3：JSONLを元に、最新のYAMLファイルを作成し、S3に保存

2.2 構造化の要：JSONL中間変換による精度の担保

本プロジェクトで最もこだわった技術的工夫が、「非構造データであるExcelを、信頼性の高いプログラムで構造データへと正規化し、それをAIに繋がせる」プロセスです。

AIが推論によってYAMLを直接生成しようとすると、パラメータの読み飛ばしなどのリスクを排除できません。そこで、データ変換の核心部分は信頼性の高いLambda（BR-1）に担当させました。

図4. ExcelからJSONLへの抽出プロセスのイメージ

以下は、Lambda（BR-1）内で行っている抽出・構造化処理の核心部です。

# Lambda (BR-1): Excelから設定を抽出しJSONLへ構造化する核心ロジック
def extractTGWConfig(event, context):
    # 1. 接続先TGWオーナーアカウントへの権限昇格 (Assume Role)
    # VPCオーナーアカウントIDを特定するために、TGWを管理する別アカウントへ接続
    vpc_owner_account_id, error = resolve_tgw_attachment_owner_account(
        tgw_owner_account_id, target_tgw_id_e, dynamic_prefix
    )

    # 2. 動的なリソース命名（aspXX-YY）の生成
    # 既存のマッピング状況をS3から読み込み、次に採番すべき名前をロジックで決定
    new_rtb_name = generate_new_rtb_name(
        dynamic_prefix, vpc_owner_account_id, rtb_naming_status
    )

    # 3. 厳格なJSONLレコードの生成
    # 純粋な設定値のみに正規化
    new_record = {
        'account-id': vpc_owner_account_id,
        'tgw-attach-id': target_tgw_id_e,
        'rtb-name': new_rtb_name
    }
    # コンパクトなJSONL形式で出力し、後続のオーケストレーションへ引き継ぐ
    new_jsonl_lines.append(json.dumps(new_record, separators=(',', ':')))

2.3 司令塔の「言語」を定義する：OpenAPIスキーマ設計の苦労

AgentにLambdaを正しく「道具」として使わせるためには、両者のコミュニケーションルールであるOpenAPIスキーマの精密な定義が不可欠でした。開発初期に直面したのが図5の矢印で示す箇所のreturnの欠落です。

図5. Agent認識に必須であるLambdaの出力形式

通常のLambda開発とは異なり、Bedrock Agentでは functionResponse 構造に厳格に従う必要があります。

レスポンスのネスト: application/json の中にデータを正しくカプセル化しないと、Agentは「Lambdaは実行されたが結果が空だ」と誤認します。
Descriptionの重要性: 各APIの description に「このAPIはS3からJSONLを読み、設定を抽出するものである」と明確に記述しなければ、Agentはどのタイミングでどのツールを使うべきか判断できません。

この「厳格なプロトコル設計」を乗り越えたことで、Agentが自律的にLambdaを呼び出し、データを繋ぐ「司令塔」としての役割をこなせるようになりました。

3. 直面した「自動化の壁」：効率化を阻む「手作業の連鎖」

Phase 1により、正確なコード生成には成功しましたが、実運用への投入には2つの「壁」がありました。ここからが本プロジェクトの真の挑戦でした。

3.1 「紐づけ作業」が手作業のまま

生成したYAMLをCloudFormationで適用する際、既存リソースをスタックの管理下に置くには、物理ID（tgw-rtb-xxxx）と論理IDを紐づけるマッピング作業がGUI上の手作業として残っていました。これでは十分な自動化とは言えません。

図6. 手動CloudFormationインポートにおける識別子マッピングの画面

3.2 「AIが作ったコード」を誰も信じられない問題

最大の壁は、「AIが出力した成果物を、人間がどうやって検品するか」でした。数百行以上のYAMLに1箇所のミスがあれば重大な通信事故になります。しかし、コードを一行ずつ目視確認しては自動化のメリットが相殺されます。人間が「この設定は正しい」と瞬時に確信を持てる仕組みが必要でした。

4. Phase 2：アーキテクチャの再設計と「視覚的な答え合わせ」の実装

私は、「AIによるオーケストレーションの結果を、別の独立したプログラムで答え合わせ（可視化）すればいい」と考え、下に示すアーキテクチャに進化させました。図の下部に追加リソースの役割を端的にまとめます。
※Lambda（BR-3/4）, Lambda（TG-2）が追加リソースになります。

図7. 改修したPhase 2 アーキテクチャ概要

現環境のコード化
- Lambda（TG-2）⇔S3：Lambda（TG-1）によって作成されたリソースインポート/マッピングファイルを取得
- Lambda（TG-2）⇔CloudFormation：取得したファイルをCloudFormationにデプロイ
VPCアタッチメント依頼時のコード化
- Lambda（BR-3）⇔S3：S3にあるYAMLファイルを取得し、通信状況を示すMermaidファイルに変換し、S3に保存
- Lambda（BR-4）⇔S3：作成されたMermaidファイルをレンダリングし、図としてS3に保存

4.1 「紐づけ作業」が手作業のまま➔IDマッピングの自動解決

物理IDと論理IDの紐づけを自動化するため、Lambda（TG-1/2）に「リソース走査ロジック」を実装しました。

# AWSリソースを走査しインポート用マッピング情報を自動生成するロジック（抜粋）
def generate_import_mapping(tgw_id):
    ec2 = boto3.client('ec2')
    rtbs = ec2.describe_transit_gateway_route_tables(
        Filters=[{'Name': 'transit-gateway-id', 'Values': [tgw_id]}]
    )['TransitGatewayRouteTables']
    
    mapping_list = []
    for rtb in rtbs:
        resource_id = rtb['TransitGatewayRouteTableId']
        # 物理IDの末尾を使い、CloudFormation命名規則に合わせた論理IDを動的に生成
        logical_id = f"TgwRouteTable{resource_id[-8:]}"
        mapping_list.append({
            "ResourceType": "AWS::EC2::TransitGatewayRouteTable",
            "LogicalResourceId": logical_id,
            "ResourceIdentifier": {"TransitGatewayRouteTableId": resource_id}
        })
    return mapping_list

4.2 「AIが作ったコード」を誰も信じられない問題➔Mermaidによる「答え合わせ」

生成されたYAMLから、Lambda（BR-3）が通信構造を抽出してMermaidに変換し、Lambda（BR-4）上のPuppeteerでPNG画像としてレンダリングする機能を構築しました。

# Lambda (BR-3): 単なる図解ではなく「疎通の成立」を判定する核心ロジック
def parse_cfn_and_generate_mermaid(yaml_data, asp_mapping):
    # ... (前略) ...
    # Association(入口)とPropagation(出口)が双方向で成立しているか判定
    for node_a, node_b in all_combinations:
        a_to_b = node_b in propagations.get(rtb_a_assoc)
        b_to_a = node_a in propagations.get(rtb_b_assoc)
        
        if a_to_b and b_to_a:
            # 両方の経路が確立されている場合のみ「疎通成立」として描画
            mermaid_lines.append(f"{node_a} <-- 疎通成立 (Reachability) --> {node_b}")

図8. 自動レンダリングされた構成図（例）

5. 性能評価：従来比70%削減とAI活用の信頼性担保の実証

2つのVPC接続を同時に設定するシナリオで、本システムの性能を従来の手作業と比較計測しました。合計リードタイムとは、設定変更操作開始から完了するまでの時間を指し示します。

評価ステップ	従来法（GUI/目視）	本システム（Agent活用）
パラメータシート作成時間	12分	2.5分
設定変更時間	11分	4.5分
合計リードタイム	23分	7分（70%削減）
手作業の回数	>40回	12回（70%削減）

※これは後述するStep Functions導入前の暫定値です。

またBedrock Agent自体の実行時間（Mermaidレンダリング完了まで）を下に示します。 VPCアタッチ数の増加に対し、生成されるYAMLファイルは増えますが、Bedrock Agentの実行時間は概ね一定であり、拡張性のある仕組みだと分かります。データ量が増大しても、推論（オーケストレーション）時間は2~3分で安定しており、大規模なガバクラ環境ほどその真価が発揮されます。

図9. 試験結果（実行時間と生成データ量）

6. まとめと今後の展望：自律型運用の完成に向けて

本プロジェクトの前編では、ガバクラ環境特有の「正確性」という壁に対し、Amazon Bedrock Agentを単なる回答者ではなく「オーケストレーター」として定義することで、複雑なインフラ設定を自動化する道筋を立てました。

Excelという非構造データを、確実なロジックを持つLambdaで構造化し、AIに繋ぐ。この「AIとプログラムの役割分担」こそが、ハルシネーションを抑え込み、実務で使える生成AI基盤を構築する鍵であると確信しています。

今回の成果と次なる課題

成果: 設定ミスが許されないTGW接続において、YAML生成から物理IDのマッピング、さらには視覚的なエビデンス（Mermaid図解）の生成までを自動化。
残された課題: 正確なコードが作れても、最後は人間が「確信」を持ってデプロイのトリガーを引かなければなりません。この「確認」と「デプロイ」の工程が分断されていることが、自動化のラストワンマイルにおけるボトルネックとなっていました。

次回予告：後編へ

「AIが生成した成果物を、エンジニアはいかにしてシームレスに承認し、安全に本番環境へ反映させるのか？」
次回の後編では、AWS Step Functionsを導入し、メール通知からワンクリックで「構成図の確認」と「自動デプロイ」を完結させるHuman-in-the-loop（人間が介在する自律サイクル）の実装について詳説します。

執筆者

野村稜武 NTTビジネスソリューションズサービス開発担当。新卒入社1年目。
クラウドインフラの高度/自動化と生成AIの実用化に情熱を注いでいます。
現在は現場への技術還元を加速させるべく、AWSの「Kiro」や「MCP」の学習、そして最新技術のキャッチアップとアウトプットに日々尽力しています。