MCPサーバー×StrandsエージェントでAWS構成を自動生成

クラウドアーキテクチャとAI駆動開発が急速に進化するなか、AWSソリューションの構築・デプロイのあり方を一変させつつある2つの技術があります。Model Context Protocol(MCP)サーバーとStrandsエージェントです。

MCPサーバーは、大規模言語モデル(LLM)を外部のデータソースやツールに接続するための標準化された仕組みです。AIモデルとさまざまなサービスの橋渡し役となり、ドキュメント、API、クラウドリソースをシームレスに連携させます。AWSの文脈では、AWSドキュメント、サービスAPI、アーキテクチャ関連ツールへ直接アクセスする手段を提供します。

Strandsエージェントは、LLMを活用して複雑なワークフローを自動化するインテリジェントなオーケストレーションフレームワークです。タスクを推論し、判断を下し、最小限の人手で複数ステップの処理を実行できます。MCPサーバーと組み合わせれば、クラウドアーキテクチャと自動化のための強力なツールへと進化します。

この組み合わせは、従来のエージェント開発手法から大きく前進した存在です。API呼び出しやエラー処理、ワークフローのオーケストレーションのために冗長なコードを書く必要はもうありません。開発者は意図を自然言語で記述するだけで、実装の詳細はインテリジェントなエージェントが引き受けてくれます。これにより開発時間は劇的に短縮され、より幅広い開発者がクラウドアーキテクチャに取り組めるようになります。

以下は、S3でホスティングする静的サイトの裏側でAWS Lambdaを使うWebサイトのアーキテクチャ図の例です。MCPサーバーとStrandsエージェントを組み合わせて生成しました。

プロンプト:「AWS Lambdaのドキュメントを取得し、S3でホスティングする静的WebサイトでAWS Lambdaを利用する構成図を作成してください」

上記の図を生成したコードを見ていきましょう。AWS構成図の生成において、MCPサーバーとStrandsエージェントがいかに強力かがわかります。

from mcp import StdioServerParameters, stdio_client
from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp import MCPClient

aws_docs_client = MCPClient(
    lambda: stdio_client(
        StdioServerParameters(
            command="uvx", args=["awslabs.aws-documentation-mcp-server@latest"]
        )
    )
)
aws_diag_client = MCPClient(
    lambda: stdio_client(
        StdioServerParameters(
            command="uvx", args=["awslabs.aws-diagram-mcp-server@latest"]
        )
    )
)
bedrock_model = BedrockModel(
    model_id="us.anthropic.claude-3-5-haiku-20241022-v1:0",
    temperature=0.7,
)
SYSTEM_PROMPT = """
You are an expert AWS Certified Solutions Architect. Your role is to help customers understand best practices on building on AWS. You can query the AWS Documentation and generate diagrams. Make sure to tell the customer the full file path of the diagram.
"""
with aws_diag_client, aws_docs_client:
    all_tools = aws_diag_client.list_tools_sync() + aws_docs_client.list_tools_sync()
    agent = Agent(tools=all_tools, model=bedrock_model, system_prompt=SYSTEM_PROMPT)
    response = agent(
        "Get the documentation for AWS Lambda then create a diagram of a website that uses AWS Lambda for a static website hosted on S3"
    )

MCPクライアントの初期化:

aws_docs_client = MCPClient(
    lambda: stdio_client(
        StdioServerParameters(
            command="uvx", args=["awslabs.aws-documentation-mcp-server@latest"]
        )
    )
)

ここでは、AWS公式ドキュメントサーバーに接続するMCPクライアントを生成します。uvxコマンドがAWSドキュメントMCPサーバーの最新版を動的に取得・実行するため、常に最新のAWSドキュメントを参照できます。

図生成クライアント:

aws_diag_client = MCPClient(
    lambda: stdio_client(
        StdioServerParameters(
            command="uvx", args=["awslabs.aws-diagram-mcp-server@latest"]
        )
    )
)

同様に、AWS構成をプログラムから図示できるAWS図生成MCPサーバー用のクライアントを生成します。

モデル設定:

bedrock_model = BedrockModel(
    model_id="us.anthropic.claude-3-5-haiku-20241022-v1:0",
    temperature=0.7,
)

ここではAWS BedrockのClaude 3.5 Haikuモデルを基盤LLMとして設定しています。temperatureを0.7にすることで、アーキテクチャ判断における創造性と一貫性のバランスをうまく取れます。Strandsエージェントはデフォルトでは Bedrock に接続しますが、Gemini、Anthropic、OpenAIなど多くのサードパーティプロバイダも利用可能です。

エージェントのオーケストレーション:

with aws_diag_client, aws_docs_client:
    all_tools = aws_diag_client.list_tools_sync() + aws_docs_client.list_tools_sync()
    agent = Agent(tools=all_tools, model=bedrock_model, system_prompt=SYSTEM_PROMPT)

ここがStrandsエージェントの真骨頂です。エージェントは2つのMCPサーバーから利用可能なツールをすべて自動的に検出し、シームレスに統合します。システムプロンプトでエージェントの役割をAWS Solutions Architectと定義することで、的確なアーキテクチャ判断に必要な前提知識を与えています。

自然言語による実行:

response = agent(
    "Get the documentation for AWS Lambda then create a diagram of a website that uses AWS Lambda for a static website hosted on S3"
)

このたった1行に、このアプローチの威力が凝縮されています。ドキュメントAPIへの問い合わせ、レスポンスの解析、図の生成といった処理を自前で書く必要はなく、欲しいものを自然言語で伝えるだけ。複雑な処理はすべてエージェントが裏で引き受けてくれます。

従来のエージェント開発では、以下のような重要領域で大量の定型コードが必要でした。

API連携の手作業: 連携したいサービスごとにHTTPクライアントの実装、認証処理、レスポンス解析、レート制限管理に多くの時間を費やしていました。

エラー処理とリトライ制御: 安定して動作するエージェントには、洗練されたエラー処理、指数バックオフ、サーキットブレーカー、リトライ機構が欠かせません。

ワークフローのオーケストレーション: 複数ステップの処理を制御するには、複雑な状態管理、条件分岐、タスクスケジューリングのロジックが必要です。

ツールの検出と管理: 従来は利用可能なツールとそのインターフェースをハードコーディングするしかなく、システムが硬直化して拡張も困難でした。

これに対してStrands + MCPのアプローチには、次のような大きなメリットがあります。

定型コードの削減: 低レベルなインフラ周りはフレームワーク任せにできるため、開発者はビジネスロジックとアーキテクチャ判断に集中できます。

動的なツール検出: MCPサーバーは自身の機能を動的に公開でき、Strandsエージェントはコードを変更せずに新しいツールを発見・利用できます。

自然言語インターフェース: 手続き型コードを書く代わりに自然言語で意図を記述できるため、システムは扱いやすく、保守もしやすくなります。

標準装備の信頼性: 堅牢なエラー処理、リトライロジック、リカバリ機構が最初から組み込まれています。

モジュール性と再利用性: MCPサーバーはプロジェクトやチームをまたいで共有でき、コードの再利用と一貫性を促進します。

多様なデプロイ方法: StrandsエージェントはLambda、ECS、EKS、EC2インスタンスなど、さまざまな環境にデプロイできます。

このアプローチは、宣言的な設定、自動スケーリング、マネージドインフラを重視する、現代のcloud-nativeおよびサーバーレス設計の原則とも合致しています。

mcp_arch_diagram.pyスクリプトを実行するには、以下のPythonパッケージのインストールが必要です。

pip install mcp strands boto3 anthropic

パッケージの内訳:

• mcp: Model Context Protocolのコア実装
• strands: エージェントのオーケストレーションフレームワーク
• boto3: Python向けAWS SDK(Bedrock連携に必要)
• anthropic: AnthropicのPythonクライアントライブラリ

その他の前提条件:

• 動的なパッケージ実行のため、uvxをグローバルにインストールしておくこと
• Bedrockアクセス用のAWS認証情報を設定すること
• AWS Bedrock利用に必要なIAM権限を適切に付与すること

MCPサーバーとStrandsエージェントの柔軟性は、静的Webサイトにとどまりません。このアプローチで生成できるAWSアーキテクチャの例をいくつか紹介します。

response = agent(
    "Create a diagram for a RESTful API using API Gateway, Lambda functions, and DynamoDB with proper security using IAM roles"
)

適切な認証とデータ永続化を備えたサーバーレスAPIアーキテクチャの構成図を生成できます。

response = agent(
    "Design an event-driven pipeline that processes files uploaded to S3, triggers Lambda functions via EventBridge, and stores results in RDS"
)

リアルタイムイベントに反応するスケーラブルなデータ処理ワークフローの図を作成するのに役立ちます。

response = agent(
    "Create a diagram for a three-tier web application with ALB, EC2 instances in multiple AZs, RDS with read replicas, and ElastiCache"
)

高可用性とパフォーマンス最適化を備えた、伝統的なマルチティアアーキテクチャの構成図を作成できます。

response = agent(
    "Generate a diagram for an ML pipeline using SageMaker for training, Lambda for inference, S3 for data storage, and CloudWatch for monitoring"
)

適切なデータ管理とモニタリングを備えた、エンドツーエンドの機械学習ワークフローの構成図を作成できます。

いずれの例も、複雑なインフラコードを書かずに自然言語の説明だけで包括的なAWSアーキテクチャを描き出せることを示しています。

ここまで新規workload向けの構成図を作成する方法を見てきました。では、現行のworkloadに潜む問題や非効率の根本原因はどう突き止めればよいのでしょうか。Cloud Diagramsはクラウド環境全体をほぼリアルタイムで可視化し、各サービス間のつながりを明らかにしたうえで、実行可能なインサイトを提示します。これにより障害やトラブルシューティングの工数が減り、運用コストの削減にもつながります。