AWS未経験・引き継ぎナシで任された私を救ったAWS Documentation MCP

はじめに

「AWSよく分からないけど、とりあえず運用頼むね」
そんな一言で現場に放り込まれた経験はありませんか？

引き継ぎ資料は断片的、質問できる人はいない、既存環境は誰がどう作ったのかも分からない。
それでも手を止めるわけにはいかない——そんな状況を、私はあるツールで乗り越えました。

それが AWS Documentation MCP Server です。

先に一言で言うと、学んできた知識は”これは間違っている”と気づかせてくれるセンサー、MCPは”じゃあどう直すか”を一次情報ベースで示してくれるエンジン。この2つが噛み合って初めて、1人でも動けるようになりました。

自己紹介

初めまして。Qurated編集部のKと申します。
私は異業種からIT業界へ参入し、運用監視やテスターの経験を経て、独学でAWS認定資格を積み上げて12冠を取得。その後、ようやくAWSの設計構築案件に参画することができました。

ところが、資格で固めた知識は実務ではそのままでは通用しませんでした。
「どの画面のどこを押せば安全なのか」「既存のこの設定は触っていいのか」——動かし方のレベルで手が止まるのです。

ただ、ひとつだけ助けられたことがありました。
「これは明らかに間違っている」という違和感だけは、これまで学んできた知識がきちんと鳴らしてくれるのです。
パブリックサブネットに置かれたRDSを見た瞬間の「これはマズい」や、0.0.0.0/0 のSGを見た瞬間の「これは整理しないと」——その感覚だけは確かに働きました。

でも、センサーが鳴っても、どう直せばいいかは分からない。
頼れる先輩もいない。そんな私を前に進めてくれたのが、AWS Documentation MCP Server でした。

Before：配属1ヶ月目の私は完全に詰んでいた

最初の1ヶ月、私がやっていたことはこんな感じです。

• 既存リソースを眺める → 何がどう繋がっているか分からない
• ドキュメントを読む → 用語が分からなくて読み進まない
• ググる → 古い情報と最新情報が混ざっていて判断できない
• ChatGPTに聞く → それっぽい回答は返ってくるが、公式仕様と食い違うことがある
• 触って壊すのが怖い → 結局、手が止まる

「分からないから触れない」 という無限ループに完全にハマっていました。

転機：1人で試行錯誤して辿り着いたAWS Documentation MCP

相談できる相手がいない以上、頼れるのはAIしかありませんでした。
最初はChatGPTに素直に聞いていたのですが、ある問題にぶつかります。

「この回答、本当に正しいのか検証する術がない」

生成された手順が最新仕様に合っているのか、そもそも公式ドキュメントと整合しているのか——確かめる相手がいない現場では、答えそのものよりも”答えの根拠”が欲しいのだと気づきました。

答えだけを出すAIではなく、公式ドキュメントを直接読みに行ってくれるAIはないか。
そう思って調べていく中で辿り着いたのが、AWS Documentation MCP Server でした。awslabs が公式に公開しているMCPサーバで、AWS公式ドキュメントの検索・取得・推薦を行うツールが揃っています。

MCPサーバを経由すると、AIがAWS公式ドキュメントを直接参照しながら回答してくれます。
つまり、

• 回答の根拠が公式ドキュメントに紐づく
• 参照元URLがセットで返ってくる
• 「最新情報と古い情報の混ざり」が減る

未経験者にとっての本当の価値は、 「ドキュメントの読み方を知らなくても、AIが読んで噛み砕いてくれる」 ことでした。

After：MCPを使うようになって変わった3つのこと

1. ドキュメント検索に時間を溶かさなくなった
   目的のページに辿り着く前に力尽きることがなくなった。
2. 設計判断に”根拠”を持てるようになった
   「なぜこの構成か？」を一次情報ベースで説明できる。
3. 触るのが怖くなくなった
   手順書がAIから降りてくる感覚で、前に進めるようになった。

ここからは、実際にMCPに救われた2つの実体験を紹介します。

実体験①：カオス化したSecurity GroupをAWS Config高度クエリで棚卸し

課題

既存環境のSecurity Group（以下SG）は、完全にツギハギ状態でした。

• 誰が何のために作ったのか分からないSGが大量
• 開発・検証・本番が混在
• 0.0.0.0/0 で全開放されているものが紛れている疑い
• どのリソースにも紐付いていない孤児SGもありそう

「これは整理しないとマズい」というセンサーは鳴るのですが、具体的にどう棚卸しすればいいかは分からない。これが未経験の私のリアルでした。

「とりあえず全部読んで整理します」と言いたいところですが、100個前後のSGを手で追うのは現実的ではない。

やったこと

そこで使うことにしたのが AWS Config の高度なクエリ です。
これは、AWS Config がインベントリしているリソース構成情報に対して、SQLライクな構文で検索できる機能です。

問題はここから。

高度なクエリの構文が分からない。

公式ドキュメントには構文リファレンスがあるのですが、未経験の私には「何ができるか」すら読み取れませんでした。
ここでAWS Documentation MCPの出番です。

やりたいことを具体的に伝えました。

• 「0.0.0.0/0 を許可しているSGを一覧で出したい」
• 「どのENIにも紐付いていないSGを出したい」
• 「同じCIDRを許可している重複ルールを検出したい」

するとMCPは、公式ドキュメントを参照しながらそのまま貼れるクエリを返してくれました。

-- 全ポートを開放しているセキュリティグループを取得するクエリ
-- (AWS Documentation MCPにやりたいことを伝えて生成、実環境で動作確認済み)
SELECT
  resourceId,
  configuration.groupName,
  configuration.ipPermissions
WHERE
  resourceType = 'AWS::EC2::SecurityGroup'
  AND configuration.ipPermissions.fromPort = 0
  AND configuration.ipPermissions.toPort = 65535
  AND configuration.ipPermissions.ipRanges BETWEEN '0.0.0.0'
  AND '255.255.255.255';

結果

100個前後のSGの棚卸しが半日で終わりました。
しかも、ただ終わらせただけでなく、クエリの意味を読んで理解する過程で、私自身が「何を見るべきか」を覚えられたのが大きな収穫でした。

「分からないから書けない」を「書いてもらって読んで覚える」に変えられたのは、未経験者にとって想像以上に大きな一歩でした。

実体験②：RDSをパブリックからプライベートへ

課題

既存環境には、パブリックサブネットに配置されたRDSが存在していました。
「DBはプライベートサブネットに」は教科書レベルの鉄則。さすがにこれは、一目で「マズい」と分かる構成でした。

でも、違和感に気づいたところで次の一歩が踏み出せません。

• 止めていい時間帯が分からない
• どのアプリがそこに接続しているのか把握しきれていない
• 切り替えで接続不能になったら誰がどうリカバリするのか決まっていない

「ヤバいのは分かる、でも直し方が分からない」——典型的な、未経験者が固まる状況です。

やったこと

MCPに聞いたのは「手順」ではなく、 「前提の整理のしかた」 でした。

• プライベート化にあたって考慮すべき観点は何か
• 各観点について、公式ドキュメントではどう言っているか
• ダウンタイムを最小化するアプローチには何があるか

返ってきた内容はどれも公式ドキュメントに根拠が紐付いていたので、 「自分で根拠を説明できる手順書」 として上長レビューに出せました。

結果

• 作業は無事完了
• 何より大きかったのは、 「怖くて触れない作業」が「根拠があるから触れる作業」に変わったこと

この感覚を覚えてから、既存環境に対する心理的ハードルが一気に下がりました。

未経験者がAWS Documentation MCPを使うときに意識していること

ここまでの実体験から、私が日々意識しているポイントを共有します。

1. 曖昧な依頼ではなく、やりたいことを具体的に書く
   「SG整理したい」ではなく「0.0.0.0/0 を許可しているSGを AWS Config で抽出するクエリが欲しい」まで落とす。
2. 出力は鵜呑みにせず、参照元URLを必ず開く
   MCPは一次情報のリンクを返してくれる。そこを読むことが、未経験者にとっての最速の学習でもある。
3. 成功も失敗もメモに残してナレッジ化する
   同じ質問を2度しない。これが属人化解消に直結する。

まとめ

• AWS未経験で引き継ぎゼロの現場は、気合いではどうにもならない
• 必要なのは “正確な一次情報へ辿り着く導線”
• AWS Documentation MCPは、その導線を未経験者にも開いてくれる

ChatGPT単体では届かなかった 「公式ドキュメントを読みながら考える力」 を、MCPは補ってくれました。

そして振り返って思うのは、これまで積み上げてきた知識とAWS Documentation MCPは役割が違っていたということです。
知識は「これは間違っている」と気づかせてくれる センサー、MCPは「じゃあどう直すか」を根拠ベースで示してくれる エンジン。
どちらか一方では前に進めず、 両方が噛み合ったときに初めて1人でも動けるようになった ——これが今の私の実感です。

結論

“分からないから触れない”を”根拠があるから触れる”に変える。

それが、AWS Documentation MCPを使い始めてからの私の実感です。
未経験で属人化した現場に放り込まれた方にこそ、一度試してみてほしいツールです。

参考リンク

• AWS Documentation MCP Server - awslabs/mcp 公式ドキュメント
• awslabs/mcp - Official MCP Servers for AWS (GitHub)
• Querying the Current Configuration State of AWS Resources with AWS Config
• Query Components for AWS Config (高度なクエリ構文リファレンス)
• Example Queries for AWS Config
• Setting up public or private access in Amazon RDS
• Move an RDS DB instance from a public to private subnet in one VPC (AWS re:Post)