[AWS re:Invent 2025] AWS MCP Serverで変わるAWS管理 - 複雑化する運用の救世主になるか

Posted at 2025-12-03

はじめに

AWS re:Invent 2025がラスベガスで開催され、今年も多くの革新的な発表がありました。

今回紹介するのは以下の3つのセッションです:

これらのセッションから、AWS管理が困難な企業に対してMCPがどのような価値を提供できるのか、実践的な視点でまとめていきます。

AWS MCP Serverとは - re:Invent 2025での発表

AWS re:Invent 2025で、AWSは公式のMCP Serverを発表しました。MCPはAnthropicが開発したオープンソースプロトコルで、AIモデルと外部データソースやツールを標準化された方法で接続する仕組みです。

AWS MCP Serverは、AWS APIサポート、最新のAWSドキュメント、APIリファレンス、What's New投稿、Getting Started情報へのアクセスを組み合わせた、AWSがホストするリモート管理型のMCPサーバーです。コマンド検証やセキュリティコントロール機能も備えており、自然言語を通じてAWSリソースの管理や探索、操作の実行が可能になります。

従来のUSB規格がデバイス接続を標準化したように、MCPはAIアシスタントとさまざまなシステムの接続を標準化するものだと理解しています。これにより、個別のAPI統合を都度実装する必要がなくなり、開発効率が大幅に向上する可能性がありますね。

現時点で、AWSからは50以上のMCP Serverが公開されており、CloudWatch、Lambda、EC2、S3、RDS、DynamoDBなど、主要なAWSサービスをカバーしています。これらはすべてオープンソースとして公開されており、コミュニティからの貢献も受け付けています。

ネットワーク管理の複雑さ - 実際の課題

NET331セッションでは、AWSのネットワークエンジニアであるAndyとJoseが、実際に直面したネットワークトラブルシューティングの課題から話が始まりました。

セッションで紹介されたネットワークは、デュアルコアネットワーク、複数リージョン、Inspection VPC、Network Function Groupsなど、あらゆる要素が含まれた複雑な構成でした。このような環境で「AからBへの通信がなぜ失敗するのか」を調査するには、膨大な時間と労力が必要になります。

従来の調査方法として以下が挙げられていました:

AWSコンソール: クリック操作は学習には良いが、手順を記憶しにくく再現性が低い
AWS CLI: スクリプト化は可能だが、複雑なコマンドをシェルスクリプトでつなぎ合わせると脆弱になりがち
Python + Boto3: 強力だが、コーディングスキルが必要で学習コストが高い

これらの方法でも調査は可能ですが、時間がかかり、エラーも発生しやすいという課題がありました。特に、ネットワークエンジニアにとっては当たり前の「traceroute」のような機能が、AWSの複雑なネットワーク環境では簡単には実現できないという点が印象的でした。

Cloud WAN MCP Serverによる解決アプローチ

AndyとJoseは、この課題を解決するために「AWS Network MCP Server」(当初はCloud WAN MCP Serverという名称でした)を開発しました。

開発の経緯

最初は個別のPythonスクリプトとして機能を実装していったそうです。例えば:

グローバルネットワークとコアネットワークの発見
各リージョンのルートテーブル取得
セキュリティルールの確認

これらを段階的にMCPツールとして統合していき、最終的には包括的なネットワークMCPサーバーとして完成させました。

Demoでは「Please use the aws-network-mcp-server to trace the path between 10.10.0.40 and 10.2.0.41」と自然言語で指示して動作デモを行っていました。(41分ごろ）

実際の活用例

セッションで印象的だったのは、コアネットワークポリシーの解説機能です。ユーザーが「コアネットワークポリシーを説明して、Network Function Groupの設定も含めて、Mermaid図で表示してください」とプロンプトすると、MCP Serverは:

すべてのセグメントを特定
分離されているセグメントを明示
ルート共有が設定されている接続性を矢印付きで表示
接続マトリックスを生成
特定のルートがブロックされている理由を説明
Network Function Groupの設定をMermaid図で視覚化

これらをMarkdown形式で出力してくれます。

JSON形式のCloud WANポリシードキュメントから、これだけの情報を人間が手作業で読み取るのは非常に困難です。MCP Serverを活用することで、学習時間の短縮やトラブルシューティングの効率化が期待できそうだと感じました。

データベース運用の自動化 - AgenticAI時代の到来

INV208セッションでは、AWSのデータベースサービス担当VP G2 Krishnamoorthyが、AgenticAI時代におけるデータベース運用の変革について語っていました。

データベース管理の現状と課題

2028年までに13億以上のAIエージェントが本番環境で稼働すると予測されており、これは控えめな見積もりかもしれないとのことです。10年前には数百から数千のデータベースを管理することが大きな課題でしたが、今後はその規模がさらに桁違いに増加していく可能性があります。

従来のデータベース管理では、パッチ適用やアップグレードがアプリケーションの可用性に大きな影響を与えていました。開発環境、テスト環境、本番環境と順番にアップグレードを適用していく作業は、リスク管理の観点から慎重に行う必要があり、多くの時間と人的リソースを必要としていました。

新機能による改善

セッションでは、いくつかの重要な改善が発表されていました:

パッチ適用の高速化
Amazon Auroraのパッチ適用が数秒で完了するようになり、Blue-Green deploymentからの切り替えも30秒未満で実行可能になりました。また、Aurora Global Databasesにも対応し、セキュリティに重要なデータベース管理作業をアプリケーションへの影響をほぼゼロにして実行できるようになったとのことです。

Upgrade Rollout Policy機能
複数のアカウントとクラスターにわたってデータベースのパッチ適用とアップグレードを一元的かつ柔軟に管理できる機能が追加されました。開発・テスト環境を先にアップグレードし、通常の本番アプリケーション、最後にミッションクリティカルなアプリケーションという順序を設定できます。

この機能は、データベース管理を複数のチームで行っている企業にとって、非常に実践的な改善だと感じました。特に、「開発環境を本番より先にパッチ適用する」という当たり前のことを、システマティックに実現できる点が良いですね。

MCPとデータベースの統合

Amazon Connectで MCP(Model Context Protocol)サポートが開始され、AIエージェントがエンドカスタマーのセルフサービスと従業員支援のために、標準化されたツールを使用して情報取得やアクション実行が可能になりました。例えば、注文ステータスの確認、返金処理、顧客レコードの更新などが、人間の介入なしに自動実行できるようになっています。

また、S3 TablesとMCP Serverの統合により、レコメンデーション結果などをアプリケーションが簡単に取得できる仕組みも紹介されていました。

データベース操作をAIエージェントに任せるというのは、セキュリティやデータ整合性の観点から慎重に検討する必要がありそうです。ただし、読み取り専用の操作や、ビジネスルールが明確な定型作業については、自動化のメリットが大きいのかなと思います。

AWSチーム自身の開発ストーリー - 実践から生まれたツール

AWS She Builds Tech Skillsのエピソードでは、PACEチーム(Prototyping and Cloud Engineering)のメンバーが、MCP開発の裏側を語っていました。このセッションで印象的だったのは、MCPが「顧客のため」だけでなく「AWS自身の生産性向上」から始まったという点です。

PACEチームとは

PACEチームは、AWS内で顧客向けのプロトタイプを迅速に構築するチームです。単なる概念実証ではなく、実際の問題を解決する実用的なプロトタイプを作成しています。また、CDK ConstructsやTerraform Modulesなどの再利用可能なアセットも開発しており、最近ではMCP Serverの開発にも注力しているとのことでした。

対談の風景

ハッカソンから始まったMCP開発

PACEチーム内でMCPハッカソンを実施し、わずか1週間で12のMCP Serverプロトタイプが誕生したそうです。その中には:

IAM Policy Autopilot: コードを分析して適切なIAMポリシーを自動生成
CloudWatch MCP Server: メトリクス、ログ、アラームへの標準化されたアクセス
S3 MCP Server: バケット操作とオブジェクト管理

これらのツールは、まずAWSチーム自身が使って効果を実感し、それをオープンソースとして公開するという流れで開発されています。

実践的な開発のベストプラクティス

セッションでは、MCP Server開発で学んだ教訓も共有されていました:

モジュラー設計の重要性
当初、すべてのツールを単一のserver.pyファイルに実装していたそうですが、Cloud WANやVPC、ネットワークファイアウォールなど多くのサービスに対応していくと、ファイルが巨大になりすぎて拡張性が低下したとのこと。そこで、サービスごとに論理的なディレクトリ構造に分割し、将来的な機能追加を容易にしたそうです。

実際のインフラでのテスト
モックデータでのテストは開発初期には便利ですが、実際の環境で動作させると想定外の問題が発生することがあったそうです。そのため、実際のAWSインフラを使って頻繁にテストすることを推奨していました。

エラーハンドリングの重要性
LLMは可能な限り役立とうとするため、適切なエラーハンドリングがないと、実際には失敗しているのに「すべて正常です」と報告してしまうことがあるそうです。各ツールに詳細なエラー情報を返す仕組みを実装し、必要に応じて次のステップを指示することが重要だと強調されていました。

この点は特に注意が必要だと感じました。AIエージェントの自律性が高まるほど、エラー時の適切な情報提供と制御が重要になってきますね。

企業の管理困難さへの対応 - 実践的な活用シーン

ここまでの内容を踏まえて、AWS管理が困難な企業がMCP Serverをどのように活用できるか、いくつかのシーンを想定してみました。

シーン1: 複雑なネットワークのトラブルシューティング

マルチリージョン、マルチVPC環境で通信障害が発生した場合:

従来: 各種コンソールやCLIコマンドを駆使して、ルートテーブル、セキュリティグループ、NACLを一つずつ確認。数時間から半日かかることも
MCP活用: 「VPC-AからVPC-Bへの通信パスを調査して」と指示すると、関連するすべての設定を自動収集し、問題箇所を特定

特に、オンコール対応時の初動調査が大幅に効率化できそうです。深夜の障害対応で、眠い目をこすりながらAWSコンソールを行き来する苦労が減るかもしれません。

シーン2: 大規模なデータベースフリートの管理

数百のRDSインスタンスやAuroraクラスターを管理している場合:

従来: 各インスタンスのパッチステータス確認、アップグレード計画の立案、段階的な適用を手動で管理
MCP活用: Upgrade Rollout Policyと組み合わせて、AIエージェントがパッチ適用状況を監視し、問題があれば通知

ただし、データベースの変更は影響範囲が大きいため、完全自動化よりも「推奨アクションの提示」と「承認後の実行」という段階的なアプローチが現実的かなと思います。

シーン3: インフラコード生成とレビュー

新しいAWSリソースをプロビジョニングする際:

従来: CloudFormationやTerraformのドキュメントを確認しながら、テンプレートを作成。IAMポリシーの作成も時間がかかる
MCP活用: 要件を自然言語で記述すると、適切なIaC テンプレートとIAMポリシーを生成。IAM Policy Autopilotは、コードを分析して有効なIAMポリシーを生成し、AIコーディングアシスタントに最新のAWSサービス知識と信頼性の高い権限推奨を提供します

セキュリティの観点では、生成されたIAMポリシーを盲目的に信頼するのではなく、必ずレビューを行うプロセスが必要だと感じました。「最小権限の原則」が守られているか、不要な権限が含まれていないかのチェックは人間が行うべきですね。

シーン4: オペレーショナルインサイトの取得

CloudWatchとCloudWatch Application Signals用のMCPサーバーは、AIアシスタントとエージェントが観測データと自然に対話できるようにします。メトリクス、ログ、アラーム、トレース、サービスヘルスデータへの標準化されたアクセスを提供し、自律的な運用ワークフローの構築が可能になります。

例えば、「過去1週間でエラー率が上昇しているサービスを特定して、関連するログを分析して」といった複合的な調査を、一つのプロンプトで実行できる可能性があります。

技術者としての考察 - 導入時の考慮点

MCPは非常に魅力的な技術ですが、実際にプロダクション環境で活用するには、いくつか慎重に検討すべき点があると感じました。

セキュリティと権限管理

MCPサーバーは強力な操作を実行できるため、適切な権限管理が不可欠です。セッションでも強調されていましたが:

読み取り専用モードの実装: 破壊的な操作が可能なツールには、必ず読み取り専用フラグを用意し、ユーザーが明示的に書き込み権限を許可する設計にする
最小権限の原則: MCPサーバーに付与するIAMロールは、必要最小限の権限に制限する
監査ログの取得: すべてのMCP経由の操作をCloudTrailなどで記録し、後から追跡可能にする

特に、複数のチームメンバーが同じMCP Serverを使用する場合、誰がどのような操作を行ったかを追跡できる仕組みが重要になりそうです。

信頼性と検証

AIエージェントの出力を盲目的に信頼するのは危険です:

重要な操作には承認フローを挟む: データベースのスキーマ変更やインフラの削除など、影響範囲が大きい操作は、人間の承認を必須にする
生成されたコードのレビュー: IaCテンプレートやIAMポリシーは、自動生成された後も必ず人間がレビューする
段階的なロールアウト: まずは開発環境やステージング環境で試し、問題がないことを確認してから本番環境に適用する

エラーハンドリングの重要性については、セッションで繰り返し強調されていました。LLMが「すべて問題ありません」と報告しても、実際には設定の一部が失敗している可能性があるため、各ツールが詳細なエラー情報を返すことが重要です。

コストとパフォーマンス

MCPを活用すると、LLMへのAPI呼び出しが増加します:

プロンプトの最適化: 必要最小限の情報だけをLLMに送信し、トークン使用量を抑える
キャッシングの活用: 頻繁にアクセスする情報(AWSドキュメントなど)はキャッシュして再利用する
コスト監視: Bedrockなどの利用状況を定期的にモニタリングし、予想外のコスト増加に早期に気づく

特に、大規模な組織では、複数のチームが同時にMCPを使用することで、予想以上にLLM APIコストが発生する可能性があります。事前にコスト試算を行い、適切な予算を確保しておくことが重要だと思います。

学習コストと組織への展開

新しい技術を組織に導入する際の課題:

ドキュメントの整備: どのMCPサーバーがどのような機能を提供するのか、内部ドキュメントを作成する
ベストプラクティスの共有: 効果的なプロンプトの書き方や、よくある問題の解決方法を社内でナレッジ共有する
段階的な導入: 最初は限定的なユースケースから始め、効果を実証してから徐々に範囲を拡大する

PACEチームの事例のように、社内ハッカソンを開催して、実際に使ってみる機会を作るのも良いアプローチかもしれません。

オープンソースとの向き合い方

AWSのMCP Serverはオープンソースとして公開されています:

コードレビューの実施: 使用前にソースコードを確認し、セキュリティリスクがないか検証する
コミュニティへの貢献: 自社で改善や機能追加を行った場合、プルリクエストを送ることで、コミュニティ全体に貢献できる
公式リポジトリの利用: サードパーティのMCPサーバーではなく、AWS公式のものを優先的に使用することで、セキュリティベストプラクティスへの準拠を確保する

ただし、セッションでも指摘されていましたが、「公式だから安全」と盲目的に信頼するのではなく、READMEやコードを実際に読んで、どのように実装されているか理解することが大切です。

まとめ - AWS管理の新しい可能性

AWS re:Invent 2025で発表されたMCP Serverは、AWS管理の複雑さに対する実践的なアプローチを提供してくれると感じました。特に印象的だったのは以下の点です:

実際の課題から生まれた: AWSのエンジニア自身が直面した問題を解決するために開発され、その後オープンソース化された経緯
包括的なカバレッジ: ネットワーク、データベース、IAM、CloudWatchなど、主要なAWSサービスをカバーする50以上のMCP Serverが提供されている
コミュニティドリブン: オープンソースとして公開され、誰でも貢献できる仕組みになっている

AWS管理が困難な企業にとって、MCPは単なる「便利なツール」ではなく、運用効率を大幅に改善する可能性を秘めた技術だと思います。ただし、セキュリティ、信頼性、コストの観点から慎重に導入を進める必要がありますね。

まずは自分の開発環境で試してみて、どのようなプロンプトが効果的か、どこまで自動化できるかを実験してみたいと思います。特に、ネットワークのトラブルシューティングやIAMポリシーの生成など、日常的に時間がかかっている作業から始めてみるのが良さそうです。

今後、AWSからさらに多くのMCP Serverがリリースされることを期待していますし、コミュニティからの貢献も活発になっていくと良いですね。