この記事について
MCP というワードは、2025年では聞かない日がないほど広く使われるようになってきました。
AWS 公式からも、多くの MCP サーバーが提供されています。
今回は、これらの MCP サーバーを活用して業務改善につなげられないかを考え、その内容をブログとしてまとめました。
プロジェクトの中で、インフラ利用料の見積もりを行う場面がたびたびあるため、
本記事ではその作業に着目し、MCP を使って改善できるのかを試してみます。
今回使うMCPサーバー
AWSから提供されている以下MCPサーバーを使うこととします。
設定
任意の MCPクライアントを準備します。（Claude Code, Kiro,,,etc）本記事ではGemini CLIを使用します。
MCPサーバーの設定
以下のようにMCPサーバーの設定を行います
.gemini/settings.json
"mcpServers": {
"aws-mcp": {
"type": "stdio",
"command": "uvx",
"args": [
"mcp-proxy-for-aws",
"https://aws-mcp.us-east-1.api.aws/mcp"
],
"env": {}
},
"awslabs.billing-cost-management-mcp-server": {
"command": "uvx",
"args": [
"awslabs.billing-cost-management-mcp-server@latest"
],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR",
"AWS_PROFILE": "your-aws-profile",
"AWS_REGION": "us-east-1"
},
"disabled": false,
"autoApprove": []
},
"awslabs.aws-documentation-mcp-server": {
"command": "uvx",
"args": ["awslabs.aws-documentation-mcp-server@latest"],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR",
"AWS_DOCUMENTATION_PARTITION": "aws",
"MCP_USER_AGENT": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36"
},
"disabled": false,
"autoApprove": []
},
"awslabs.aws-pricing-mcp-server": {
"command": "uvx",
"args": [
"awslabs.aws-pricing-mcp-server@latest"
],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR",
"AWS_PROFILE": "your-aws-profile",
"AWS_REGION": "us-east-1"
},
"disabled": false,
"autoApprove": []
}
}
スラッシュコマンドの作成
Gemini CLIでは、.gemini/commands/<コマンド名>.tomlというファイルを作成することで、カスタムコマンドが使用できます。
本記事では、analyze_aws_architectureというコマンドを作成してみました。
analyze_aws_architecture.toml
# 役割
# あなたはAWSのWell-Architectedアドバイザーであり、コスト最適化の専門家です。ユーザーが自然言語で提供する提案されたAWSアーキテクチャについて、そのコストへの影響とベストプラクティスを理解する手助けをすることがあなたの目標です。
#
# このコマンドは、以下のツールセットを活用するように設計されています:
# - awslabs.aws-pricing-mcp-server
# - awslabs.aws-documentation-mcp-server
# - awslabs.billing-cost-management-mcp-server
# - search_documentation
# - get_bedrock_patterns
prompt = """
# 役割
あなたはAWSのWell-Architectedアドバイザーであり、コスト最適化の専門家です。ユーザーが自然言語で提供する提案されたAWSアーキテクチャについて、そのコストへの影響とベストプラクティスを理解する手助けをすることがあなたの目標です。
# ルール
1. **初期の明確化（対話型）:** ユーザーから最初のアーキテクチャ記述を受け取ったら、*最初*かつ*最も重要*なステップとして、明確化のための対話を開始してください。正確なコスト見積もりとアーキテクチャの健全性のために不可欠な、曖昧なまたは不足している詳細を特定する*必要があります*。特定された各AWSサービスに対して具体的な質問をしてください。
2. **最新情報の調査:** 初期対話で得られた情報に基づき、**`awslabs.aws-documentation-mcp-server`、`search_documentation`、および `get_bedrock_patterns` ツールを積極的に使用し、関連する最新のAWSドキュメントやアーキテクチャパターンを検索し、理解を深めてください。**
**上記ツールが最新または十分な情報を提供できない場合に限り、`google_web_search` ツールを活用し、各AWSサービスの最新の仕様、料金、ベストプラクティスに関する情報を補足的に検索してください。**
3. **反復的な洗練:** ユーザーの回答と調査した最新情報を基に、必要に応じて追加の質問をしながら、すべてのコンポーネントについて具体的な仕様のセットが揃うまで、アーキテクチャの詳細を洗練し続けてください。
4. **コスト計算:** 十分な詳細が集まったら、提供された仕様に基づき、各AWSサービスコンポーネントの推定月額コストを計算してください。**まず`awslabs.aws-pricing-mcp-server` ツールを使用し、包括的なデータが得られない（特にAmazon Bedrockなどの場合）場合は、`chrome_devtools` ツールを使用して公式のAWS料金ページにアクセスし、関連する料金詳細を直接抽出して計算の主要なソースとしてください。**
5. **アーキテクチャレビュー:** 収集した情報全体を基に、以下を特定してください。
* 提案されたサービス/アーキテクチャのベストプラクティス。
* 一般的な落とし穴、運用上の考慮事項、および潜在的な「隠れたコスト」（例：リージョン間/AZ間のデータ転送、NAT Gateway料金、EBS IOPS）。
* コスト、パフォーマンス、信頼性、セキュリティを最適化するための推奨事項（例：Gravitonインスタンスの提案、適切なストレージクラス、高可用性のためのマルチAZ）。
6. **包括的なレポート:** 最終的に、以下の内容を含む構造化されたレポートを提示してください。
* 各AWSサービスコンポーネントの推定月額コストを明確に項目別に記載した内訳。**`awslabs.aws-pricing-mcp-server`ツール、または`chrome_devtools`から取得した情報源（特にAmazon Bedrockなど、後者を使用した場合）を明確に記載してください。**
* アーキテクチャ全体の推定月額合計コスト。
* `awslabs.billing-cost-management-mcp-server` ツールも活用し、アーキテクチャに関する考慮事項、警告、コスト最適化とベストプラクティスに関する具体的な推奨事項の箇条書きリストを作成します。
* さらに詳しく調べるためのAWSドキュメントまたはアーキテクチャパターンへの関連リンク。
7. **インタラクティブなエンゲージメント:** プロセス全体を通してインタラクティブで役立つトーンを維持し、ユーザーが導かれ、情報を提供されていると感じられるようにしてください。
"""
詰まったところと工夫
プロンプト設計が原因だった可能性もありますが、
Bedrock の料金体系について、Claude 3.5 Sonnet までの情報しか回答されないケースがありました。
そこで、Chrome DevtoolsMCPサーバーを使い、Bedrockの料金ページを確認させるようにしました。
方法については以下の記事を参考にさせていただき、リモートデバッグモードでChromeを開き、そこでBedrockの料金ページを開き、そこから各基盤モデルの料金を確認させるようにしました。
.gemini/settings.jsonに以下を追加します。
"mcpServers": {
"aws-mcp": {
"type": "stdio",
"command": "uvx",
"args": [
"mcp-proxy-for-aws",
"https://aws-mcp.us-east-1.api.aws/mcp"
],
"env": {}
},
"awslabs.billing-cost-management-mcp-server": {
"command": "uvx",
"args": [
"awslabs.billing-cost-management-mcp-server@latest"
],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR",
"AWS_PROFILE": "your-aws-profile",
"AWS_REGION": "us-east-1"
},
"disabled": false,
"autoApprove": []
},
"awslabs.aws-documentation-mcp-server": {
"command": "uvx",
"args": ["awslabs.aws-documentation-mcp-server@latest"],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR",
"AWS_DOCUMENTATION_PARTITION": "aws",
"MCP_USER_AGENT": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36"
},
"disabled": false,
"autoApprove": []
},
"awslabs.aws-pricing-mcp-server": {
"command": "uvx",
"args": [
"awslabs.aws-pricing-mcp-server@latest"
],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR",
"AWS_PROFILE": "your-aws-profile",
"AWS_REGION": "us-east-1"
},
"disabled": false,
"autoApprove": []
},
+ "chrome-devtools": {
+ "type": "stdio",
+ "command": "npx",
+ "args": [
+ "chrome-devtools-mcp@latest",
+ "--browserUrl=http://localhost:9222"
+ ],
+ "env": {}
+ }
+ }
}
実際に使ってみる
以下のような質問をしてみます。
analyze_aws_architecture 生成AIを活用した帳票管理アプリケーションを作成したい。 サービスはAmplify、DynamoDBを使う想定。 モデルはAmazon Bedrockで利用可能な Claude Sonnet 4を使う想定
いきなりコスト算出、ではなく想定ユーザー、データ量などヒアリングしてくれるので、見積もりだけでなく、実際に具体的な設計に落とし込んでいく際の考慮事項についてもここで気づきを得られそうです。
その後、以下のように追加で質問をされるので、回答し、対話を繰り返します。
試算が始まると、実際に接続されているMCPサーバーが利用されていることがわかります。
Bedrockについては、指示通りchrome-devtoolsが使われ、別で開いているBedrockの料金ページを確認してくれています。
以下は、get_pricing_service_attributesを使いDynamoDBの料金を調べているところです。
問答を繰り返して、最終的に得られたコスト試算がこちらです。
見積もりについては、無料利用枠についての考慮もしてくれていそうでした。
※awslabs.billing-cost-management-mcp-serverにはfree-tier-usageと言うtoolがあるためそれを確認してくれていた模様
アーキテクチャレビューと推奨事項についてはおまけ的な形でプロンプトに添えてみましたが、それっぽいことは言ってくれていそうです。
---
生成AIを活用した帳票管理アプリケーション - コスト分析とベストプラクティスレポート
1. はじめに
本レポートは、提案されている生成AIを活用した帳票管理アプリケーションのAWSアーキテクチャについて、初期のコスト分析とAWS Well-Architected
Frameworkに基づくベストプラクティスの推奨事項を提供します。
2. アーキテクチャの概要
提案されたアーキテクチャは、以下のAWSサービスを中心に構築されています。
* AWS Amplify: Next.jsフロントエンドのホスティング、ユーザー認証、API（GraphQL/REST）、ファイルストレージ、Lambda関数（バックエンドロジック）。
* Amazon DynamoDB: 帳票のメタデータ管理。
* Amazon Bedrock (Claude Sonnet 4): 帳票内容の要約機能。
* Amazon S3: 帳票ファイルの保存。
3. 前提条件と利用量の仮定
* デプロイリージョン: 米国東部（バージニア北部: us-east-1）
* Amplify (Next.jsアプリケーション):
* ユーザー数: 約100名
* 月間APIコール数: 10,000回
* ホスティングデータ転送: 100GB/月
* Amplify Functions (Lambda): 10,000回/月、128MBメモリ、1秒実行
* DynamoDB (帳票メタデータ):
* 月間登録帳票数: 300件
* メタデータサイズ: 1KB/件
* 月間書き込み操作: 300回
* 月間読み込み操作: 1,500回
* キャパシティモード: オンデマンド
* Amazon Bedrock (Claude Sonnet 4 - 帳票内容の要約):
* 月間要約処理回数: 300件
* 1回あたりの入力トークン数: 50,000トークン
* 1回あたりの出力トークン数: 2,000トークン
* 料金モデル: オンデマンド
* S3 (帳票ファイル保存):
* 1ファイルあたりのサイズ: 10MB
* 月間アップロード量: 300件（合計3GB/月）
* 1年後のストレージ総量: 36GB
* 月間ダウンロード量: 300件（合計3GB/月）
* ストレージクラス: S3 Standard
4. 推定月額コストの内訳
以下のコストは、上記仮定および公式のAWS料金API（`awslabs.aws-pricing-mcp-server`）およびAmazon
Bedrock公式料金ページ（`chrome_devtools`経由）から取得した最新の料金情報に基づいています。無料利用枠を考慮した後の費用です。
┌────────────────────────────┬────────────────────────┬────────────────────────────────┬────────────────────┬────────────────┬─────────────────────────────────────┐
│ サービス │ 項目 │ 単価/単位 │ 利用量/月 │ 推定月額コスト │ 情報源 │
├────────────────────────────┼────────────────────────┼────────────────────────────────┼────────────────────┼────────────────┼─────────────────────────────────────┤
│ AWS Amplify │ ホスティングデータ転送 │ $0.15/GB │ 85GB │ $12.75 │ 料金API │
│ │ ビルド時間 │ $0.01/分 │ 15分 │ $0.00 │ 料金API (無料枠内) │
│ │ 小計 │ │ │ $12.75 │ │
│ Amplify Functions (Lambda) │ リクエスト │ $0.20/100万リクエスト │ 10,000回 │ $0.00 │ 料金API (無料枠内) │
│ │ コンピューティング │ $0.0000166667/GB-秒 │ 1,250GB-秒 │ $0.00 │ 料金API (無料枠内) │
│ │ 小計 │ │ │ $0.00 │ │
│ Amazon DynamoDB │ 書き込みリクエスト │ $0.625/100万書き込みリクエスト │ 300回 │ $0.00 │ 料金API (無料枠内) │
│ │ 読み込みリクエスト │ $0.125/100万読み込みリクエスト │ 1,500回 │ $0.00 │ 料金API (無料枠内) │
│ │ ストレージ │ $0.25/GB-月 │ 300KB │ $0.00 │ 料金API (無料枠内) │
│ │ 小計 │ │ │ $0.00 │ │
│ Amazon Bedrock │ 入力トークン │ $0.003/1,000トークン │ 15,000,000トークン │ $45.00 │ Bedrock料金ページ (chrome_devtools) │
│ (Sonnet 4) │ 出力トークン │ $0.015/1,000トークン │ 600,000トークン │ $9.00 │ Bedrock料金ページ (chrome_devtools) │
│ │ 小計 │ │ │ $54.00 │ │
│ Amazon S3 │ ストレージ │ $0.023/GB-月 │ 36GB │ $0.83 │ 料金API │
│ │ PUTリクエスト │ $0.005/1,000リクエスト │ 300回 │ $0.00 │ 料金API (無料枠内) │
│ │ GETリクエスト │ $0.004/10,000リクエスト │ 300回 │ $0.00 │ 料金API (無料枠内) │
│ │ データ転送 (Out) │ $0.09/GB │ 3GB │ $0.00 │ 一般的なAWS料金 (無料枠内) │
│ │ 小計 │ │ │ $0.83 │ │
│ 推定月額合計コスト │ │ │ │ $67.58 │ │
└────────────────────────────┴────────────────────────┴────────────────────────────────┴────────────────────┴────────────────┴─────────────────────────────────────┘
注記: 上記のコストは仮定に基づいた推定値であり、実際の利用状況、AWSの料金変更、無料利用枠の適用状況によって変動します。
5. アーキテクチャレビューと推奨事項
AWS Well-Architected Frameworkの主要な柱に沿って、アーキテクチャのレビューと最適化の推奨事項を以下に示します。
##### 5.1. コスト最適化
* Bedrockトークン使用量の最適化が最重要課題です。 現在の構成では、Bedrockがコストの大部分を占めます。
* プロンプトエンジニアリングの改善: 入力トークンを最小限に抑えつつ、必要な出力を得るためのプロンプト設計を徹底します。不要な情報をBedrockに送らないようにします。
* モデル選定の柔軟性: Claude Sonnet 4の高い性能が常に必要か評価し、よりコスト効率の良いモデル（例: Claude Sonnet
3.5、または他のBedrock対応モデル）で十分な精度が得られるタスクにはそちらを使用することを検討します。
* 入力の前処理: 帳票内容をBedrockに送る前に、関連性の低い情報や冗長なテキストを除去する前処理ステップを導入し、入力トークンを削減します。
* 要約結果のキャッシュ: 頻繁にアクセスされる帳票や、同一内容の帳票の要約結果は、DynamoDBやS3にキャッシュすることでBedrockへの重複したAPIコールを削減します。
* S3ライフサイクルポリシーの活用: 長期間アクセスされない帳票データは、S3
Standard-IAやGlacierなどの低コストストレージクラスへ自動的に移行するようにライフサイクルポリシーを設定し、ストレージコストを最適化します。
* Amplify Consoleのデータ転送監視: 今後の利用状況によってはデータ転送量が増加する可能性があります。Amplify
Consoleに統合されているCloudFrontのキャッシュヒット率を定期的に監視・最適化し、データ転送コストを抑制します。
##### 5.2. パフォーマンス効率
* Bedrock呼び出しの非同期処理:
帳票の要約処理は、特にファイルサイズが大きい（10MBのテキスト処理）場合、レイテンシーが発生する可能性があります。ユーザー体験を損なわないよう、要約処理はLambdaの非同期呼び出しやStep
Functionsなどを利用してバックグラウンドで実行し、処理結果は後でユーザーに通知するメカニズムを導入することを検討します。
* DynamoDBインデックスの最適化:
帳票メタデータへのアクセスパターン（検索条件など）を分析し、最適なプライマリキー設計およびセカンダリインデックス（グローバルセカンダリインデックス/ローカルセカンダリインデックス）を作成するこ
とで、高速なデータアクセスを保証します。
* S3とCloudFrontの連携: ユーザーが保存された帳票ファイルにアクセスする際のパフォーマンスを向上させるため、Amplify Consoleに統合されているAmazon
CloudFrontを最大限に活用し、エッジロケーションからの高速なコンテンツ配信を実現します。
##### 5.3. 信頼性
* Bedrock呼び出しのリトライ処理: BedrockのAPI呼び出しが一時的な障害やスロットリングで失敗した場合に備え、指数バックオフ（Exponential
Backoff）付きのリトライメカニズムをLambda関数に実装し、アプリケーションの耐障害性を向上させます。
* S3バージョニングの有効化: 誤操作による帳票ファイルの上書きや削除から保護するため、S3バケットでバージョニングを有効にすることを強く推奨します。
* DynamoDBのバックアップ: DynamoDBのPoint-in-Time Recovery (PITR) を有効にし、過去35日間の任意の時点にデータを復旧できるようにすることで、不慮のデータ損失に備えます。
##### 5.4. セキュリティ
* Amplify認証の強化: Amazon Cognitoと統合されたAmplify認証を活用し、多要素認証（MFA）を強制することでユーザーアカウントのセキュリティを強化します。
* 最小権限の原則 (Least Privilege):
* Amplify Functions (Lambda) からDynamoDB、S3、Bedrockへのアクセスは、各サービスで必要最小限の操作のみを許可するIAMロールとポリシーを使用します。
* DynamoDBテーブル、S3バケット、Bedrockモデルへのアクセスは、許可されたエンティティ（ユーザー、ロール）のみに限定します。
* S3バケットセキュリティ: S3バケットへのパブリックアクセスは完全にブロックし、機密性の高い帳票データを保護します。サーバーサイド暗号化 (SSE-S3またはSSE-KMS) をデフォルトで有効にします。
* 通信の暗号化: すべての通信（フロントエンドからバックエンドAPI、AWSサービス間）がTLS/SSLを使用して暗号化されていることを確認します。AmplifyおよびAWSサービスはこれをデフォルトでサポートします。
##### 5.5. 運用上の優秀性
* モニタリングとアラート:
* すべてのAWSサービスに対してAmazon CloudWatchでキーメトリクスを監視します（例: Bedrockの呼び出し数、レイテンシー、スロットリング; DynamoDBの読み書きキャパシティ使用率; Lambdaのエラー率）。
* 異常を検出した場合、担当者に自動的に通知するアラートを設定します。
* ログ記録:
* AWS CloudTrailを有効にしてAWSアカウント内のAPIアクティビティを監査し、セキュリティ分析、リソース変更の追跡、およびトラブルシューティングに役立てます。
* S3アクセスログを有効にし、バケット内のオブジェクトに対するアクセスリクエストを記録します。
* CI/CDの活用: AWS
Amplifyの組み込みCI/CD機能は、コード変更のテスト、ビルド、デプロイを自動化し、開発プロセスの効率性と信頼性を向上させます。開発、ステージング、本番環境の分岐戦略を明確にし、デプロイメントを自
動化します。
* Infrastructure as Code (IaC): DynamoDBテーブル定義、Lambda関数、S3バケット設定など、バックエンドインフラストラクチャをAWS CloudFormationやAWS
CDKなどのIaCツールで定義・管理することで、環境の一貫性を保ち、手動設定によるエラーを削減します。Amplify自身がCloudFormationを利用しています。
6. 参考資料
* Amazon Bedrock 料金: https://aws.amazon.com/jp/bedrock/pricing/ (https://aws.amazon.com/jp/bedrock/pricing/)
* AWS Amplify 料金: https://aws.amazon.com/jp/amplify/pricing/ (https://aws.amazon.com/jp/amplify/pricing/)
* Amazon DynamoDB 料金: https://aws.amazon.com/jp/dynamodb/pricing/on-demand/ (https://aws.amazon.com/jp/dynamodb/pricing/on-demand/)
* Amazon S3 料金: https://aws.amazon.com/jp/s3/pricing/ (https://aws.amazon.com/jp/s3/pricing/)
* AWS Well-Architected Framework: https://aws.amazon.com/jp/architecture/well-architected/ (https://aws.amazon.com/jp/architecture/well-architected/)
---
まとめ
料金の見積もり作業は、課金体系を確認するためにさまざまなドキュメントを参照する必要があり、何かと時間がかかる作業です。
本記事では、その作業を少しでも効率化できないかというアイデアのもと、MCP サーバーを活用したアプローチを試してみました。
AI にすべてを丸投げするのはもちろん御法度で、人間による確認は必須ですが、
見積もりの初期段階でまずは粗くコスト感を把握したい場合など、補助的な位置付けとしては十分に活用できるのではないかと感じています。
本記事で紹介した内容は、業務改善のほんの一例に過ぎませんが、
「日々の細かい作業を、どうすれば楽にできるか」という問題意識を持ちながら、
今後も MCP サーバーをうまく使いこなしていきたいと思います。
参考
※追記※
調査を進める中で、get_pricing_attribute_values を利用すれば、
Claude Sonnet 3.5 より後のモデルについても料金情報を取得できそうだ、ということが分かりました。（以下はスラッシュコマンドではなくClaude Sonnet 4について料金を調べてとシンプルな質問をした例）
今回のケースでは、analyze_aws_architecture.toml に記述したプロンプト設計がおそらく原因で、
意図したツールがうまく使われていなかった可能性がありそうです。
シンプルに、どのツールを使うのかを明確に指示するプロンプトにしてあげることが重要だと感じました。
そのため、結果的には Chrome DevTools MCP は必須ではなかったかもしれません。
ただし、料金情報の取得方法や MCP の仕組みそのものを理解する良い機会にもなったため、
本記事ではそのまま紹介しています。
このあたりのプロンプト設計についても、今後しっかり学んでいきたいところです。