はじめに
「AWS Documentation MCP Serverを使ってClaude DesktopにAWSの最新情報を回答してもらう」の記事で使用したAWS Documentation MCP Serverですが、触っているうちに「AWS公式ドキュメントを参照できるのであればAWSの認定試験問題にも回答できるのでは？」と思い、自作問題を作成してみました。
本記事では、AWS Documentation MCP Serverと連携したClaude Desktopに自作したAWS Certified Solutions Architect - Professionalレベルの自作問題を投げかけてみて、どのような回答が返ってくるのか検証したいと思います。
また、逆にAWS公式ドキュメントの情報から試験問題を生成できるのかも検証したいと思います。
準備するもの（前提条件）
今回の検証でもAWS Documentation MCP Serverと連携したClaude Desktopを使用します。
セットアップの手順は前回の記事「AWS Documentation MCP Serverを使ってClaude DesktopにAWSの最新情報を回答してもらう」に記載していますので、そちらをご確認ください。
問題を解かせてみる
早速問題を投げかけてみます。
正解の選択肢と、その根拠となるAWS公式ドキュメントを提示してもらうようにしました。
以下はAWS Certified Solutions Architect - Professionalレベルを想定した自作問題です。 この問題の正解と、その根拠となるAWS公式ドキュメントのURLを提示してください。 ある大規模企業が複数の事業部を持ち、それぞれが独立したAWSアカウントでアプリケーションを運用しています。 現在、各事業部のアカウントは以下のような構成になっています ・事業部A：本番環境とステージング環境（us-east-1） ・事業部B：本番環境とステージング環境（eu-west-1） ・事業部C：本番環境と開発環境（ap-southeast-1） ・共通インフラ部門：ネットワーキングとセキュリティ管理（全リージョン） 各事業部のアプリケーションは、Amazon S3、Amazon DynamoDB、AWS Systems Manager等の複数のAWSサービスを頻繁に利用しており、現在はインターネット経由でアクセスしています。 しかしセキュリティ要件の強化により、すべてのAWSサービスへのアクセスをプライベート接続に変更する必要があります。 またコスト最適化も重要な要件となっています。 上記の要件を満たし、かつ管理の複雑さを最小限に抑える最も適切なソリューションは何でしょうか？ 1. 各事業部のアカウントで個別にVPCインターフェイスエンドポイントを作成する。 Amazon S3、Amazon DynamoDB、AWS Systems Managerなどのサービスごとに、各事業部アカウント内のVPCにインターフェイスエンドポイントを個別に作成する。 それぞれのVPCにおいて、セキュリティグループやルートテーブルの設定を行い、AWS PrivateLinkを用いてサービスへのプライベート接続を構成する。 2. 共通インフラ部門のアカウントに集約されたVPCインターフェイスエンドポイントを作成する。 共通インフラ部門のVPCと各事業部アカウントのVPCはTransit Gatewayで接続し、共通インフラ部門のVPCにRoute 53 Resolver転送ルールを設定する。 転送ルールはAWS Resource Access Manager（RAM）で共有し、AWS Organizationsで統合管理する。 各事業部アカウントのVPCでは共有されたルールを利用してRoute 53 Resolverを構成する。 各事業部アカウントのVPCでゲートウェイエンドポイントを作成する。 3. 各リージョンにNAT Gatewayを配置し、すべてのトラフィックを暗号化する。 各事業部のVPCからインターネットへのアクセスをNAT Gateway経由で行い、プロキシサーバーを介してAWSサービスに接続する。 AWS VPN接続を使用して各事業部アカウント間を接続し、VPCごとに設定された暗号化トンネルを通じて通信を行う。 IAMロールを使用してクロスアカウントアクセスを制御する。 4. AWS Direct Connectを使用してオンプレミス接続を確立する。 各事業部が個別のVIFを使用してAWS Direct Connect経由でAWSに接続し、オンプレミス環境と連携する。 マルチアカウント環境の管理にはAWS Control Towerを利用し、マルチアカウント構成のセットアップやガードレールの適用を自動化する。
正解は2になります。
すべてのAWSサービスへのアクセスをプライベート接続 → インターフェイスエンドポイントを共通インフラ部門に集約し、各VPCからTransit Gateway経由で接続することでインターネットを経由しない通信を実現
コスト最適化 → エンドポイントの集約によりインターフェイスエンドポイント数を削減、S3やDynamoDBには各VPCでゲートウェイ型エンドポイントを使用しTransit Gatewayの転送料金を回避
管理の複雑さを最小限に抑える → Route 53 Resolver転送ルールをRAMで共有し、AWS Organizationsで統合管理することで名前解決と接続構成を一元化
選択肢1は各アカウント内で個別にリソースを作成しており管理コストが高い。
選択肢3はNAT Gatewayを使用しておりプライベート接続ではない。
選択肢4は今回のシナリオでオンプレミス環境は登場していないため無関係。
Claudeの回答は以下でした。
正解：選択肢2 共通インフラ部門のアカウントに集約されたVPCインターフェイスエンドポイントを作成する。共通インフラ部門のVPCと各事業部アカウントのVPCはTransit Gatewayで接続し、共通インフラ部門のVPCにRoute 53 Resolver転送ルールを設定する。転送ルールはAWS Resource Access Manager(RAM)で共有し、AWS Organizationsで統合管理する。各事業部アカウントのVPCでは共有されたルールを利用してRoute 53 Resolverを構成する。各事業部アカウントのVPCでゲートウェイエンドポイントを作成する。 根拠となるAWS公式ドキュメントURL 主要な根拠ドキュメント： https://docs.aws.amazon.com/prescriptive-guidance/latest/rehost-multi-account-architecture-interface-endpoints/solution-2.html 関連する公式ドキュメント： https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing-sharing.html https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html https://docs.aws.amazon.com/prescriptive-guidance/latest/rehost-multi-account-architecture-interface-endpoints/solution-3.html 解説 なぜ選択肢2が正解か コスト最適化: AWS公式ドキュメントでは、複数のアカウントで個別にVPCエンドポイントを作成すると、管理上の負担と各アカウントでの個別VPCインターフェイスエンドポイントのコストが増加すると明記されています。 管理の簡素化: 共通インフラ部門での一元管理により、コストと管理上の負担を削減できます。 複数リージョン対応: 公式ドキュメントのソリューション2では、複数のAWSリージョンに対応するアーキテクチャとして、Transit Gatewayのピアリング接続とRoute 53 Resolverルールの共有を推奨しています。 リソース共有: Route 53 Resolverの転送ルールはAWS Resource Access Managerで共有でき、AWS Organizationsで統合管理できると公式に説明されています。 ゲートウェイエンドポイント: S3とDynamoDBについては、ゲートウェイエンドポイントはAWS PrivateLinkを使用せず、追加料金もかからないためコスト面で有利です。 他の選択肢が不適切な理由 選択肢1: 各アカウントで個別にエンドポイントを作成するとコストが高く、管理負荷も大きくなります 選択肢3: NAT Gatewayを使用してもプライベート接続にはならず、要件を満たしません 選択肢4: AWS Direct Connectはオンプレミス環境との接続用であり、AWSサービス間のプライベート接続には適していません この解決策は、AWS公式ガイダンスで「ソリューション2」として推奨されている、複数アカウント・複数リージョン環境でのベストプラクティスです。
しっかり正解を選んでくれました。
正解の理由もこちらの意図通りで、その根拠となるAWS公式ドキュメントも提示してくれています。
個人的には、それぞれの解説が公式ドキュメントのどの部分に記載されているか明記してくれるとありがたいと思いました。
ただこれでも試験勉強に活用できそうですね。
問題を生成させてみる
続いて問題を生成してもらいます。
AWS Certified Solutions Architect - Professionalの出題分野の1つである「複雑な組織に対応するソリューションの設計」に関する問題を生成してもらいます。
入力したプロンプトは以下になります。
以下の条件に沿って、AWS Certified Solutions Architect - Professional認定試験の出題分野である「複雑な組織に対応するソリューションの設計」に関する問題を1問作成してください。 * 選択肢は4つ * 正解の選択肢および不正解の選択肢を提示 * 正解の理由および不正解の理由をそれぞれAWS公式ドキュメントのURL付きで解説
Claudeの回答は以下でした。
AWS Certified Solutions Architect - Professional認定試験問題 問題分野：複雑な組織に対応するソリューションの設計 問題 大規模な多国籍企業が AWS Organizations を使用して複数の AWS アカウントを管理しています。この企業は以下の要件を満たす組織構造を設計する必要があります： - 本番環境と開発環境を明確に分離する - セキュリティチームが全アカウントのログアクセスを集中管理する - 各部門のチームが独立してリソースを管理できる - 本番環境でのみ高可用性が必要なサービスへのアクセスを制限する この要件を満たすために、最も適切な AWS Organizations の設計パターンはどれですか？ 選択肢 A. 単一のルートOUの下に、各部門に対応する個別のOUを作成し、各OU内に本番用と開発用のアカウントを混在させる。Service Control Policy (SCP) をアカウントレベルで個別に適用する。 B. ルートOUの下に「Production」と「Non-Production」の2つの主要OUを作成し、さらにその下に「Security」「Infrastructure」「Workloads」のOUを作成する。SCPをOUレベルで適用し、セキュリティアカウントを「Security」OU内に配置する。 C. ルートOUの下に部門別のOUを作成し、各部門OU内に「Dev」「Test」「Prod」のサブOUを作成する。セキュリティ関連のアカウントは各部門のOUに分散配置し、SCPはルートレベルでのみ適用する。 D. ルートOUの下に環境別（「Development」「Testing」「Production」）のOUを作成し、各環境OU内に部門別のサブOUを作成する。セキュリティアカウントは「Production」OU内に配置し、管理アカウントのユーザーがすべてのアカウントにアクセスする。 解答と解説 正解：B 正解の理由： 選択肢Bは、AWS Organizations のベストプラクティスに最も適合しています。 階層的な組織構造: 「Production」と「Non-Production」による環境の明確な分離は、AWS が推奨する基本的な設計パターンです。これにより、本番環境と開発環境を明確に分離できます。 機能別のOU設計: 「Security」「Infrastructure」「Workloads」のOUを作成することで、機能に基づいた管理が可能になります。これは、組織の報告構造ではなく、機能や共通の制御に基づいてOUを作成するというAWSの推奨事項に合致します。 セキュリティの集中管理: セキュリティアカウントを専用の「Security」OU内に配置することで、ログアーカイブやセキュリティツールなどの集中管理が可能になります。 効率的なポリシー管理: SCPをOUレベルで適用することで、個別のアカウントではなく、グループレベルでのポリシー管理が可能になり、管理の複雑性を軽減できます。 参考URL: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous_best_practices.html 不正解の理由： 選択肢A - 不正解の理由： この設計には以下の問題があります： - 本番環境と開発環境が同一OU内に混在するため、環境の分離が不十分 - SCPをアカウントレベルで個別に適用するのは管理上非効率的 - セキュリティチームによる集中管理が困難 参考URL: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html 選択肢C - 不正解の理由： この設計の問題点： - セキュリティアカウントが各部門に分散配置されるため、集中管理が困難 - SCPをルートレベルでのみ適用すると、きめ細かい制御ができない - 部門別の構造が主体となり、環境分離が二次的になってしまう 参考URL: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous_best_practices.html 選択肢D - 不正解の理由： この設計の問題点： - 管理アカウントのユーザーがすべてのアカウントにアクセスするのはセキュリティ上のリスク - 環境別の上位構造は適切だが、セキュリティアカウントを「Production」OU内のみに配置すると、非本番環境のセキュリティ管理が困難 - 各チームの独立性が制限される 参考URL: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html 補足情報 AWS Organizations のベストプラクティス: - OUは会社の報告構造ではなく、機能や共通の制御セットに基づいて設計する - セキュリティとインフラストラクチャ用の基本的なOUから始める - 本番ワークロードには異なるポリシー要件があることを考慮して、Production と Non-Production (SDLC) のネストされたOUを作成する - ポリシーはOUレベルで適用することで、個別のアカウントレベルよりも管理を簡素化する 参考URL: https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html
本番の試験に比べると短めの問題文ですが、割としっかりした問題を生成してくれました。
問題内容や解説に明らかな誤りはなく、根拠となるドキュメントも提示してくれているので、試験前に要点（ベストプラクティス）を確認したい場合などに何問か作成してもらう形で使用できるのではないでしょうか。
プロンプトに入力する文章に条件を追加できるので、「○○の分野について」や「○○のサービスに関する問題を」のように自分好みのカスタマイズもできるところが生成AIを活用した学習の強みかと思います。
まとめ
本記事では、AWS Documentation MCP Serverと連携したClaude Desktopに自作問題の回答、問題の生成をしてもらい、生成AIが公式ドキュメントに基づいてどこまで信頼性のある回答ができるのかを検証しました。
回答・生成どちらにおいても一定の実用性があると感じましたが、個人的に生成の方は少し問題が簡単すぎるかなと思いました。
より本番に近い形の問題を解きたい場合、現時点ではUdemyなどの模擬問題集を活用した方が良いかと思います。
将来的には模擬問題集と遜色ないクオリティの問題を生成できるようになることを期待しています。
