[DevOps-Agent開発 Vol.3] AWS SAMでエージェントに特定プロジェクトのデプロイ・リソース削除機能を持たせてみた

1．はじめに

Vol.1 では，GitHubリポジトリを解析してデプロイ計画を立てるエージェントのAIを作成し，Vol.2 ではエージェントの信頼性をできるだけ高めるために Hadolint や Trivy, cfn-lintなどを使用して　「AI⇔静的解析ツール」間での「自己修正ループ」 を実装しました．

今回の Vol.3 では，いよいよ AWS SAM を用いて実際に特定プロジェクトのデプロイ・リソース削除機能を実装します．

ここでポイントとなるのが，AWS SAMを採用することでエージェントの実装を「手順（How）の実行」から「あるべき姿（What）の宣言」へとシフトさせた点です．これで複雑なインフラ操作をAWS側に委譲しシンプルかつ堅牢な完全自律デプロイを実現する過程を解説します．

全記事の内容は以下のようになってます．興味のある方はぜひ読んでみてください！

1．[DevOps-Agent開発 Vol.1] FastMCPとAWS Bedrockで「コードを読んで勝手にデプロイ計画を立てるAI」を作ってみた

2．[DevOps-Agent開発 Vol.2] AI⇔静的ツールでの「自己修正ループ」を作成してみた

3．[DevOps-Agent開発 Vol.3] AWS SAMでエージェントに特定プロジェクトのデプロイ・リソース削除機能を持たせてみた

本アプリケーションのコード（Vol.1, Vol.2, Vol.3統合版）は Github にて公開しているので，興味のある方はぜひ使用してみてください！

2．実装部

2.1．システム構成図

Vol.3 ではAWS SAMを用いてMCPサーバーからAWS Lambdaにデプロイすることができるような実装を行いました．具体的には，エージェントが生成したSAMテンプレート（template.yaml）をもとに、AWS SAM CLI がDockerfileの Build (コンテナ構築) と Deploy (AWSへの展開) を一括で行います．エージェントは「どのような構成にしたいか」を宣言するだけでよく，実際のリソース作成や依存関係の解決はすべてAWS側に任せるようなアーキテクチャとなっています．そのため，エージェントは複雑なAWS APIの操作手順（どの順序でリソースを作るか等）を管理する必要がなく，かつ純粋に 「正しい設計図（SAMテンプレート）を作ること」だけに集中 できるような設計となりました．

2.2．全体フロー

Vol.1，Vol.2，Vol.3を全て統合しユーザーが入力 -> 入力されたGithubリポジトリのコードとドキュメントに沿ってAgentがAWS 環境を生成 -> AWS Lambdaにデプロイの流れを実現できます．

3．実装

3.1．作成した環境をLambdaにデプロイする機能

Dockerfileを作成しイメージ化した後 AWS Lambda にデプロイを行います．ここではユーザに許諾を得たうえでデプロイすることを想定しているため，デプロイ環境作成 -> デプロイ を一括の処理として扱わずにわざと機能を分けています．出力としては，ClaudFundationからデプロイ先のURLを得ることができるように実装しています．AWS SAM CLIをsubprocessで叩き，ECRリポジトリの自動作成・管理やコンテナイメージのプッシュをするといった形でデプロイの自動化を実現しています．

src/engines/execution_engine.py

def deploy_to_lambda(self, project_name: str) -> str:
    """AWS SAMを使ってデプロイを実行"""
    print(f"🚀Deploying to AWS Lambda with SAM...", file=sys.stderr)
    
    cmd = [
        "sam", "deploy",
        "--stack-name", project_name,
        "--resolve-s3",
        "--resolve-image-repos", 
        "--capabilities", "CAPABILITY_IAM",
        "--no-confirm-changeset"
    ]
    
    subprocess.run(cmd, cwd=str(settings.WORK_DIR), check=True)
    # デプロイ後にCloudFormationからURLを取得して返す
    return self._fetch_stack_output(project_name, "FunctionUrl")

3.2．デプロイ後の環境を削除する機能

一旦，デプロイした後にそのまま稼働状態にしていると，無駄なリソースを使用してしまう可能性があります．そのため，今回はデプロイ後に命令文一つでデプロイ環境を削除することができるような機能を追加しました．AWS SAM CLIをPythonのsubprocessを通して実行し，デプロイ時に作成したスタックを全て削除するような形で実装しました．

src/engines/execution_engine.py

def cleanup_lambda(self, project_name: str) -> str:
    """スタックごとリソースを削除"""
    print(f"Destroying Stack: {project_name}")
    cmd = [
        "sam", "delete",
        "--stack-name", project_name,
        "--no-prompts"
    ]
    try:
        subprocess.run(cmd, cwd=str(settings.WORK_DIR), check=True)
        return f"✅ Stack '{project_name}' destroyed."
    except subprocess.CalledProcessError:
        return "⚠️ Delete failed or stack not found."

4．動作確認

4.1．作成した環境をLambdaにデプロイする機能

Dockerfileを作成しイメージ化した後 AWS Lambda にデプロイを行います．ここではユーザに許諾を得たうえでデプロイすることを想定しているため，デプロイ環境作成 -> デプロイ を一括の処理として扱わずにわざと機能を分けています．出力としては，デプロイ先のURLを得ることができるようにしているため，わざわざブラウザを介さずに確認できるようになっています．

実際にURLをクリックすると，以下のように"Hello,Smart Deploy Agent"と返ってきました．

4.2．デプロイ後の環境を削除する機能

一旦，デプロイした後にそのまま稼働状態にしていると，無駄なリソースを使用してしまい．そのため，今回はデプロイ後に命令文一つでデプロイ環境を削除することができるような機能を追加しました．

5．DevOps-Agentの使用方法

ここからは，実際にDevOps-Agentを動かす方法について説明します．大きく分けて事前準備と動作方法について説明します．

5.1．事前準備

まずは，本アプリケーションを使用するために必要なものを準備します．以下では，それぞれについて簡単に説明します．

• Docker のインストール
  Dockerがインストールされていない場合は，以下のリンクのサイトを参考にインストールしてください．

  • Windwos/Mac参考サイト
  • Linux(Ubuntu)参考サイト
    　

• エージェント用のIAMユーザーの作成
  続いて，エージェントがAWSリソースを操作するための権限を付与するために，エージェント用のIAMユーザーを作成します．また，今回はLLMとして AWS Bedrock 内のモデルを使用します．そのため，IAMのロールとして以下を許可するようにしてください．

  

  AWS Bedrockのモデルですが，アップデートでモデル解除が必要ないため，IAMユーザーのみの作成でOKです

　

• Claude for Desktop のインストール
  MCPサーバーの接続先として，今回はClaude Desktopをインストールします．インストール時には以下のサイトを参考にしてみてください．
  • Claude for Desktop 参考サイト
    　
• [必要な人のみ]Github Tokenの取得
  読み込みたいリポジトリがPrivateの場合は repo 権限が必要です．Publicなら権限なしでも可ですが，APIレート制限回避のために設定を推奨します．GitHub Settings から Personal Access Token (Classic) を取得します．
  • Github Token参考サイト

5.2．使用方法

• .envファイルの準備
  以下の.envファイルを作成します．また，AWSの credential情報を含んだファイルのパスを指定し忘れないようにしてください．

  .env

  # 各環境変数
  AWS_PROFILE=your_profile
  AWS_REGION=your_region
  LLM_MODEL=your_using_model_name # 私は anthropic.claude-3-5-sonnet-20241022-v2:0 を使用しました
  GITHUB_TOKEN=your_github_token # 必要な人のみ設定してください
  

　

• MCPサーバーのイメージの作成
  以下のコマンドを実行して，リポジトリのクローンとイメージの作成を行ってください．

  bash

  git clone https://github.com/kz-ow/AWS-DevOps-Agent.git
  cd AWS-DevOps-Agent
  docker build -t smartdeployagent-smart-deploy-agent .
  

　

• Claude for Desktopの設定ファイル変更
  設定ファイル（claude_desktop_config.json）を開き，以下を追加します．作成したイメージをインタラクティブモード（-i）で動かす部分はVol.1．とは変わりませんが，AWS認証情報（/.aws）とDockerソケット（/var/run/docker.sock）をコンテナ内にマウントしている点が異なります．これにより，コンテナ内のエージェントがホスト側のDockerを使ってビルドしたり，AWSへのデプロイ権限を行使したりできるようになります．

  claude_desktop_config.json

  {
    "mcpServers": {
      "devops-partner": {
        "command": "docker",
        "args": [
          "run",
          "-i",
          "--rm",
          "-v", "/var/run/docker.sock:/var/run/docker.sock",
          "-v", "C:\\Users\\ユーザー名\\.aws:/root/.aws:ro",
          "-v", "出力のマウント先の絶対パス:/app/__output__",
          "--env-file", ".envファイルのある絶対パス",
          "smartdeployagent-smart-deploy-agent"
        ]
      }
    }
  }
  

  設定ファイルを変えタスクマネージャーでClaudeのプロセスを切った後に Claude for Desktop を開くとMCPサーバーを経由してエージェントモードで使用する事ができるようになります．

6．おわりに

今回は DevOps-Agent を作成してみました．全体を通してMCPサーバがとても万能でありシステムとして実現できる幅がとても広がっていることを実感することができました．

今回は使いやすいインターフェイスとしてClaude for Desktop を使用しましたが，設定周りであったりわざわざインストールする手間やVSCodeから使えない点などがあるので，Github Actions で実行できるようにしたいと思っています．

また，デプロイ環境として AWS Lambda のみを今回は対象としていますが，今後は AWS EC2 へのデプロイやロードバランサー，証明書の発行回りをTerraformを使って追加で自動化できるようなエージェントにしてみたいなと思っています．

3つの記事にまたがってしまいましたが，最後まで読んでいただきありがとうございました！

7．参考文献

Python subprocessの使い方

AWS SAM CLIについて