AWSマルチアカウント横断のインフラ情報をAIで分析 -- EOL対応の経験から生まれたMCPサーバー構築

はじめに

こんにちは、技術本部、技術戦略ディビジョン VGM の天津です。

社内横断的なSREチームで、現在は主にEOL対応および保守に役立つプラットフォームの拡充・エンジニアリングに取り組んでいます。

今回は、EOL対応およびインフラ調査の効率化を目的に構築した、インフラ情報をAIに提供する仕組み ――愛称「a2m」（aws analysis mcp）―― について紹介します。

はじめに
背景 -- EOL対応で感じた問題点
あるべき姿と現実のギャップ
課題への解決策
システム全体像
- サーバーレス構成を選んだ理由
- OAuth 2.1認証の実装
Before/After: インフラ調査の進め方が変わった
開発で遭遇した技術課題と工夫
活用例の紹介
社内展開 -- ハンズオンの実施
- 参加者の反応
- フィードバック→改善のサイクル
おわりに

背景 -- EOL対応で感じた問題点

きっかけは、あるEOL対応での経験です。

EOL対応のためにはそのシステムの現状を把握する事が必要で、下記のような作業を実施していました。

情報収集
- 対象アカウントのAWSリソース
- 各EC2内の情報（netstat や ps、cron の結果）
情報整理
- スプレッドシートに手動で転記、紐づけ実施
- 図表化して全体像を把握

非常に地道かつ時間のかかる作業であり、結果的に全体把握には至ったもののこの作業を通じて3つの問題を痛感しました。

1. 現状把握が困難

プロセスや通信ポートなど、AWS CLIだけでは見えないサーバー内部の情報が想像以上に多いです。EC2のメタデータは取れても、その中で何が動いているかまではわかりません。

2. 調査に時間がかかる

手動でのアプローチは数時間から数日かかります。サーバーにログインして情報を集め、構成図に書き起こす作業まで含めると、1台あたりでもかなりの工数になります。

また当社は40超のAWSアカウントを運用しており、プロダクトによってはテスト系・本番系など複数のAWSアカウントを調べる必要があり、さらに時間がかかります。

3. 調査結果・品質のばらつき

手動での調査はベテランの経験や知識に依存する部分が大きく、担当者のスキルレベルによって調査結果やその品質にばらつきが出ていました。

あるべき姿と現実のギャップ

理想は「誰でも即座に」インフラの状況を把握できることですが、現実はまったく違っていました。

あるべき姿	現状の課題
リソース情報・OS内部情報が集約済み	データベース化されていない、EC2内部情報は未取得
必要な時にすぐ取り出せる検索性	AWSアカウントごとにデータをAWS CLI で取得
AI活用により自然言語で分析可能	AWSアカウントごとに AWS CLI を AIエージェントに使わせる状態
誰が調べても一定の調査結果	上記の状況から、属人的な手動調査に依存

また、当初EOL対応時に感じた問題点ではありませんが、当社では40を超えるAWSアカウントを運用しており、今後、複数アカウントや全体を横断して分析したいというニーズもありました。

課題への解決策

前章で挙げた課題に対して、2つのアプローチで解決を図ることにしました。

データの整備とそれをAIエージェントにつなぐMCPサーバーの構築です。

1. データ整備

まず、各AWSアカウントに散在していた情報を1箇所に集めます。

AWS Config
- EC2、RDS、SecurityGroupなどの構成情報
SSM Inventory
- インストール済みパッケージ、ネットワーク情報
カスタムインベントリ
- プロセス一覧、crontab、netstat、lsof、Linuxユーザー・グループ

カスタムインベントリの収集は、各EC2にシェルスクリプトを配布し、SSM State Managerで日次実行させます。その結果をSSM経由でS3に蓄積する構成としました。これらをS3に集約することで、40超のアカウントの情報を横断的に検索できる土台ができます。例えば、 netstat コマンドの結果が日次で蓄積されるような仕組みです。

2. AIとの連携基盤（MCPサーバー）

次に、集めたデータとAIエージェントをつなぐ「MCPサーバー」を構築しました。

今回は、AIエージェントが「今この瞬間のデータ」を動的に取得できる点を重視しました。
AIが状況に応じてSQLクエリを組み立て、結果を見てさらに深掘りするといった振る舞いが、インフラ調査のような探索的なタスクに適していると考え、MCPサーバーを構築することにしました。

このサーバーを介することで、AIエージェントが自然言語でインフラ情報を取得できるようになります。

AWS公式MCPとの違い

課題解決について、「AWS公式のMCPサーバーを使えばいいのでは？」と思われるかもしれません。

確かに、AWS公式が提供するMCPサーバー群は、各AWSサービスのリソース情報が取得できるものもあります。

ただし、以下の制約がありました。

単一アカウント・単一リージョンでの操作が前提
- 複数アカウントを横断してデータをJOINする仕組みがない
EC2のOS内部は見えない
- インスタンス設定は取得できても、その中で動いているパッケージ、プロセス、crontab、ネットワークの接続情報、Linuxユーザー・グループ等は取得できない

これらの制約から、複数のアカウントを横断して、かつOS内部の情報まで含めて分析したいというニーズには対応できません。

また、Datadog の Live Process 等の監視SaaSでも同等のことは可能ですが、コスト面での課題がある状況で、自分たちの環境に合った仕組みを自分たちで作る必要がありました。

システム全体像

データの流れは4つのステップで構成されています。

データ収集
- 40超のAWSアカウントからConfig・SSM・カスタムインベントリの情報を日次で収集
蓄積・加工
- S3に蓄積し、Lambdaで分析用に加工
検索基盤
- AthenaでSQLクエリ可能な状態に
AI連携
- MCPサーバーがAIからのリクエストを受けてAthenaに問い合わせ、結果を返す

収集対象はEC2やRDSなどのAWSリソースから、OS上のプロセスやcrontab、ネットワーク接続情報まで幅広いです。初回リリース後にはElastiCacheの情報やCURコストデータも追加しています。

なお、a2mが提供するのは構成情報（リソース設定、パッケージリスト、ネットワーク接続情報等）であり、パスワードなどの機密データは含みません。
AIエージェントに情報を渡すことによるセキュリティリスクは最小限と判断しています。

サーバーレス構成を選んだ理由

MCPサーバーの実装には、サーバーレス構成（Lambda + API Gateway）を採用しました。主な理由は運用コストの最小化です。

利用頻度が予測しにくい
- 常時稼働のサーバーを持つのは非効率。Lambdaの従量課金で使った分だけのコスト
マネージドサービスの活用
- API Gateway + Cognito で認証を含め運用負荷が最小限
技術的な相性
- MCPフレームワーク（FastMCP）がLambda Web Adapterと組み合わせてLambda上で動作

利用者側はClaude CodeやGitHub Copilotから自然言語で質問するだけです。認証は社内のSSO（EntraID）と連携しているため、追加のログイン操作は不要です。

OAuth 2.1認証の実装

MCPプロトコル仕様では、リモートMCPサーバーの認証にOAuth 2.1を使用することが推奨されています。a2mでは、API Gateway + Cognito を使ったサーバーレス構成で実装しました。

利用者は、初回にサーバーURL設定と認証操作を行うだけです。以降は、AIエージェントが自動的にMCPサーバーと連携します。

内部では以下の仕組みを採用しています。

Device Authorization Grant
- デスクトップアプリ向けの認証フロー
Dynamic Client Registration
- 初回接続時にクライアントを自動登録
OAuth Discovery
- 認証エンドポイント情報を自動取得
PKCE
- 認証コード横取り攻撃の防止

API Gatewayでは、OpenAPI定義とVTLマッピングテンプレート（リクエスト/レスポンス変換機能）を活用し、Lambdaを介さずにCognitoのAPIを直接呼び出す構成にしています。

※ この実装は、manaty226さんの記事「AWSマネージドサービスだけでリモートMCPサーバを構築する」を参考にさせていただきました。
また、OAuth/OIDCの基礎については、過去記事「EntraIDを使ったOIDC認証の実装」で解説していますので合わせてご覧ください。

Before/After: インフラ調査の進め方が変わった

この仕組みの導入で、インフラ調査の進め方が大きく変わりました。

Before	After
専門知識が必要な手動調査	自然言語での問い合わせ
数時間〜数日のリードタイム	数分〜数時間で完了
1アカウントずつの個別確認	40超アカウントの横断分析
OS内部の情報は見えない	プロセスや接続情報も取得可能
担当者のスキルで品質にばらつき	属人性を大幅に低減

特に効果を実感したのは、調査工数の削減です。

EOL対応時に1台あたり2〜3時間かかっていた調査が、ものによっては数分から30分程度で完了するようになり、成果物の品質も合わせて大きな向上が見られています。

開発で遭遇した技術課題と工夫

システム構築の過程では、いくつかの技術的な課題に直面しました。同じような環境を構築する方の参考になればと思い、主な課題と対応の工夫を紹介します。

Cognito禁則文字とmitmproxyでのデバッグ

OAuth 2.1認証の実装で、苦労したのがCognitoにClaude CodeからのDynamic Client Registrationリクエストが通らない問題でした。

当初は原因がわからず苦戦しましたが、最終的にリクエストを mitmproxy でキャプチャして解析することで原因が判明し解決しました。

詳細な原因は以下の通りです。

Claude Code は DCR リクエストで client_name に括弧付きの文字列（例: "Claude Code (oauth-verification)"）を送信する。
一方で Cognito は ClientName に括弧を含む文字列を受け付けない（禁止文字）。

解決策として、API GatewayのVTLマッピングテンプレートでサニタイズ処理を実装することで無事解決しています。

#set($clientName = $input.path('$.client_name'))
#set($sanitized = $clientName.replaceAll('[^\w\s+=,.@-]', '_'))
{
  "ClientName": "$sanitized",
  ...
}

Config最適化でクエリ時間を98%削減

AWS Configスナップショット（10MB/日、JSON形式）を単純にAthenaでクエリすると、毎回全データスキャンで10秒以上かかっていました。

明らかに時間がかかることから、改善のために以下の3つの方式を改めて実測し比較検討しました。

方式	クエリ時間	スキャン量	削減率
v1（元のJSON/gzip）	9.9秒	34.73MB	-
v2（INSERT INTO Parquet）	3.4秒	11.88MB	65%削減
v3（CTAS + カラム全展開）	1.1秒	0.10MB	98.9%削減

最終的にCTAS（Create Table As Select）でカラムを全展開し、Parquet形式で保存する方式を採用しました。実ビューのクエリ時間も88〜113秒から1.0〜1.5秒に改善しています。

AIエージェントへの配慮

技術的な課題への対応だけでなく、AIエージェントが効率的に動作するための工夫もいくつか施しています。

段階的なツール設計

a2mは、AIエージェントに3つのツールを提供しています。

search -- キーワードでテーブル・viewを検索
explore -- テーブル・viewのスキーマやサンプルデータ、クエリ例を確認
query -- SQLクエリを実行

DB系MCPサーバーではよくある構成ですが、実際に運用してみると、AIエージェントがexploreを飛ばしていきなりクエリを書こうとし、カラム名を間違えるケースが頻発しました。
そこで、クエリ実行ツールの説明文に「まずsearch → exploreの順で確認してから実行してください」というワークフローを明記し、AIエージェントが適切な順序でツールを使うように誘導しています。

コンテキスト消費への配慮

テーブルやview情報の取得時に状況に応じて情報を取捨選択できるよう、下記の項目についてオプション化しています。

サンプルデータ
クエリ例
パフォーマンスヒント

これにより、AIエージェントがその都度必要な情報だけを取得できるようにし、コンテキストを圧迫しないようにしています。

また、ツールの説明文やエラーメッセージはすべて英語で記述しています。日本語に比べてトークン消費が少なく、コンテキストの節約に寄与します。

AIへのガイド・エラーメッセージの充実

実際に使ってみると、AIが思うようにクエリを組み立てられなかったり、データを見つけられなかったりすることがありました。

例えば、カラム名を間違えてAthenaエラーになる、テーブル名の命名規則を理解せずに存在しないテーブルを参照する、といったケースです。こうした失敗を減らすため、Athenaのエラーをパースして「次に何をすべきか」をAIに提示し、カラム名のサジェストや命名規則のヒントも提供しています。

データ鮮度情報の提供

各データには「いつ時点のデータか」を付与しています。
これにより、AIエージェントが古いデータを参照して誤判断をすることを防ぐことができるようになりました。

活用例の紹介

実際に社内で使われているユースケースを4つ紹介します。

ケース1: 複数アカウントのEC2環境差異を分析

Before:

本番とステージングのSGやパッケージバージョンの差異確認は、各アカウントに個別ログインして手作業で突き合わせが必要でした。IaCで管理していない環境では全容把握すら困難です。

After:

例えば「本番と検証環境のパッケージバージョン差分をまとめて」と指示するだけで、複数アカウントのデータを同時取得し差異を自動抽出。環境間の差異を即座に発見できます。

ケース2: レガシーサーバーの依存関係を可視化

Before:

依存関係把握には、SSH接続してnetstat/psの結果を手動整理し、IPアドレスを1つずつ調べて構成図に起こす必要がありました。

After:

netstat情報からLISTENポートとESTABLISHED接続先を自動分析し、プライベートIPをENI情報からRDSやElastiCache等に紐付けます。また、mermaid などでの構成図の書き起こしまでAIが対応可能になりました。

ケース3: 不要IP許可の調査

Before:

セキュリティグループで許可しているIPアドレスが、現在も必要なものか確認するには、一つひとつのアカウントやドキュメントを手動で調査していました。

After:

a2mでSGルール情報を取得し、ドキュメントの参照用 MCPサーバー(Confluence等)で情報を参照して、AIが横断的に調査します。

こういった複数MCPサーバーの組み合わせもMCPアーキテクチャの強みです。

ケース4: コスト分析と削減余地の特定

Before:

複数アカウントの利用料金を横断分析自体はこれまでも可能でしたが、実際のリソース状況と紐づけて分析するのは非常に手間がかかっていました。

After:

a2m にOrganization全体の利用料金データ（CURデータ）を統合しました。

「対象アカウントの先月の利用料金に削減余地はあるか」と問い合わせるだけで、実際のリソース利用状況も加味したサービス別コスト比較や削減提案が得られます。

社内展開 -- ハンズオンの実施

構築したシステムを実際に使ってもらうため、リリースノートと設定ガイドを配布し、その上でプロダクト担当のエンジニアを対象にハンズオンを開催しました。

ハンズオンは、概要説明と設定の後にデモを実施し、その後は各種ユースケースから自由に体験してもらう形式です。

参加者の反応

アンケート（22名回答）では、理解度は全員が「理解できた」以上で、約60%が「十分に理解できた」と回答。実務での活用イメージも約80%が持てたという結果でした。

フィードバック→改善のサイクル

ハンズオンで得たフィードバックは順次改善しています。

フィードバック	対応
コスト分析がほしい（最多要望）	CURデータ収集機能を追加
Linuxユーザー/グループを見たい	カスタムインベントリに追加
GCPでも同じものがほしい	開発検討中