AWS SAP の出題範囲｜設問が長い理由と読み方

SAPの出題範囲は試験ガイドから確認する

AWS SAP（Solutions Architect – Professional）の出題範囲を把握するには、AWSが公開している公式試験ガイドを参照するのが確実です。試験ガイドにはSAPで問われる4つの分野、各分野の比率（出題割合）、対象スキルの説明が記載されています。

この記事では、公式試験ガイドで公開されている情報をもとに分野構成を整理します。また、SAPの設問が長い理由と、実際の読み方の工夫も合わせてまとめます。

なおNDA（秘密保持契約）の関係上、試験で出題された設問や選択肢を具体的に再現することはしていません。「こういう種類のことが問われる」という抽象的な説明にとどめています。

SAPの全体的な難しさについてはSAPの難易度とSAAとの差に書いています。勉強時間についてはSAPの勉強時間と期間を参照してください。

4つの出題分野と比率の概要

SAPの試験ガイドに記載されている4つの分野は次の通りです。分野名は日本語版試験ガイドの表記に従っています（2026年8月1日時点で確認）。

分野1：複雑な組織への対応

複数アカウント・複数リージョン・複数チームが関わる組織規模での設計が問われます。AWS Organizationsを使ったマルチアカウント設計、ネットワーク設計、セキュリティポリシーの一元管理といった内容が含まれます。

SAAでは主に単一アカウント・単一リージョンの設計が中心でしたが、SAPではアカウント横断のリソース管理や、組織全体のポリシー適用が問われます。組織構造の違いによってどのアーキテクチャが適切かという判断が必要です。

分野2：新しいソリューションのための設計

新規システムやサービスを設計する際の判断が問われます。AWSのサービスを組み合わせて、コスト・パフォーマンス・可用性・セキュリティのバランスを取った設計を選ぶ問題が多くなります。

複数の設計案があり、それぞれのトレードオフを判断するという形式の設問がこの分野に多く含まれます。「コストを抑えつつ高可用性を実現する」「最小限のオペレーション負荷で要件を満たす」といった制約条件付きの設計判断が問われます。

分野3：既存ソリューションの継続的な改善

稼働中のシステムをどう改善するかという観点の設問が含まれます。コスト削減・可用性向上・パフォーマンス改善・セキュリティ強化といった改善目的が設問に明示され、既存の構成から何を変えるかを選ぶ問題です。

「現在はこういう構成で動いている。以下の要件を満たすために変更するとしたら？」という形式で、既存構成の説明が設問に含まれます。このため設問が長くなります。

分野4：ワークロードの移行とモダナイゼーション

オンプレミスからAWSへの移行、または既存のAWSシステムをより適切な形に移行・更新する内容が問われます。移行の計画策定・ツールの選択・データ移行の方法・移行後の検証といった一連のプロセスに関する問題が含まれます。

モダナイゼーションとは、古いアーキテクチャや技術スタックを現代的な方法に置き換えることを指します。モノリスからマイクロサービスへの移行、コンテナ化、サーバーレス化といった方向性の判断が問われます。

分野比率の考え方

各分野の比率は試験ガイドに数値で記載されています。最新の比率は公式試験ガイドで確認するのが確実です。

試験ガイドの比率はおおまかな目安であり、実際の試験で必ず比率通りに出題されるとは限りません。特定の分野に偏らず、4分野すべてを均等に学ぶことが安全です。

実際に勉強してみると、分野をまたぐ複合的な設問も多く、「この問題はどの分野か」という分類が難しい場合もありました。試験中は分野の分類より設問の要件に集中するほうが実用的です。

設問が長い理由：実務シナリオの再現

なぜSAPの設問はSAAより長いのか

SAPの設問が長くなる理由は、実務での設計判断を再現しようとしているためです。

実際のシステム設計では、「この機能を実現するにはどうするか」だけでなく、「既存の環境はこうなっていて、こういう制約があって、コストはこれくらいで、可用性はこのレベルが必要で、移行は段階的にやりたい」という複数の条件を同時に考慮します。

試験でその設計判断の質を測るには、条件を設問に含める必要があります。SAAは比較的シンプルな条件での判断を問うことが多いのに対し、SAPは複数の制約が並立する条件での判断を問います。このため設問に含まれる情報量が多くなり、文章が長くなります。

設問に含まれる要素

SAPの設問に含まれる要素を整理すると、おおむね次のようなパターンがあります。

背景・現状の説明： 企業の規模・業種・現在の構成・運用体制の説明が含まれます。「グローバルに展開するeコマース企業が、現在はオンプレミスで○○というシステムを運用している」という形です。

要件： 何を実現したいか、何を改善したいかの説明です。可用性・スループット・コスト・セキュリティ・コンプライアンスなど、満たすべき要件が含まれます。

制約： 何を変えてはいけないか、何が使えないか、どういう前提があるかの説明です。「移行は段階的に行う必要がある」「既存のシステムは変更できない」「特定のリージョンのみ使用可能」といった制約です。

問い： 上記の条件を満たすためにどうするかという設問本体です。

SAAとの設問の質の違い

SAAでは、特定のサービスの機能を知っていれば解ける問題が多く含まれます。「AutoScalingで対応できるか」「S3のアーカイブ機能はどれか」という形で、知識が直結します。

SAPでは、サービスの知識は前提として、複数の選択肢のどれがより適切かを条件の中で判断する問題が増えます。A・B・C・Dの4択が全部動く構成だとしても、「このシナリオの制約条件では」どれが最善かを選ぶ問題です。

長文設問の読み方

設問末尾を先に読む

長文設問を読む際に私が実践した方法は、設問の末尾（最後の1〜2文）を先に読むことです。

試験の設問は「○○という状況があります。○○が必要で、○○という制約があります。この場合に最も適切な対応はどれですか？」という構成になっています。最後の「問い」の文を先に読むと、「何を答えるか」が明確になってから背景を読めます。

背景から順番に読むと、「この情報はどこで使うのか」という不確かさを持ちながら読むことになります。問いを先に知ってから背景を読むと、「この情報はこの問いに関係する」という目的意識が持てます。これだけで読む速度と理解の効率が変わりました。

制約条件を拾う

設問を読む際に特に意識したのは、制約条件を意識して拾うことです。

要件（○○を実現したい）だけを読んでいると、複数の選択肢がすべて要件を満たしているときに迷います。制約（○○はできない、○○は変えない）を見落とすと、制約に引っかかる選択肢を選んでしまいます。

制約条件は「ただし」「しかし」「一方で」「現在は○○のため」「○○という前提のもと」といった接続表現や留保表現の後ろに書かれることが多いです。こういった表現を見たら、制約が来ると意識して注意を向けるようにしました。

選択肢の差分を読む

4択の選択肢を読む際に、各選択肢を最初から全部読もうとすると時間がかかります。選択肢AとBの差分だけに注目する読み方が効率的です。

例えば、A・B・Cが「Amazon Auroraを使う」という点で共通していて、D だけ「Amazon DynamoDBを使う」という場合、まずAurora vs DynamoDBという軸で比較します。そのあとAとBの差分（例えばAurora MultiAZかAurora Serverlessか）を見る、という手順です。

全部を平等に読もうとしすぎると、共通部分の読み直しに時間を使います。「選択肢の何が違うか」という差分を先に把握すると、比較が速くなります。

見直しフラグを使う

180分75問は、1問あたり2分24秒が平均です。特定の問題で時間をかけすぎると後半に余裕がなくなります。

迷った問題は3分を目安に見直しフラグを立てて次に進む方法を練習で習慣にしました。試験システムにはフラグ機能があるので、「後で戻る」と決めて先に進めます。全問を解いた後に残り時間でフラグ付き問題を再確認する流れです。

時間を多く使ってでも解いたほうがいい問題と、一旦スキップして後に回す問題の判断は、練習問題で通しのタイム計測を繰り返すことで身につきました。

出題範囲の勉強のアプローチ

試験ガイドで分野の全体像を把握する

勉強を始める際に試験ガイドを一通り読むことをすすめます。ガイドには各分野でどういう知識・スキルが求められるかの記述があり、学習の方向性を決める参考になります。

試験ガイドは無料でAWS公式サイトから入手できます。ガイドを見ながら「自分はどの分野が薄いか」をチェックリスト的に使うと、学習計画が立てやすくなります。

分野ごとに重点を変える

4分野すべてを同じ密度で学ぶのが理想ですが、時間が限られている場合は苦手分野に重点を置く調整が必要になります。

苦手分野の判断には模擬問題が有効です。分野ごとの正解率を把握すると、時間配分の参考になります。ただし前述のとおり分野をまたぐ設問もあるため、分野ごとの正解率だけを過信しないほうが安全です。

深いサービス理解を積み上げる

SAPの学習では、個々のサービスの理解をSAAよりも深める必要があります。「このサービスは○○ができる」という知識から、「このサービスは○○の条件では適切で、○○の条件では別のサービスが適切」という比較・判断まで理解を深める必要があります。

この理解を積み上げる方法としては、問題演習で間違えた際に公式ドキュメントに戻って「なぜ正解がこれなのか」を確認する方法が有効でした。公式ドキュメントには各サービスの制限・比較・ユースケースが記載されており、選択肢の根拠を確認するのに役立ちます。

SAPの教材を使って読み方を練習する

長文設問の読み方は、知識として理解するだけでは身につきません。SAPの問題形式に慣れるためには、実際の設問を使った練習が必要です。

SAPの対策問題集や公式模擬試験を使って、設問末尾から読む・制約を拾う・選択肢の差分を比較するという読み方を意識して繰り返すことで、習慣として定着します。

教材の選び方はSAPの教材の選び方に詳しく書いています。日本語の教材が少ないSAPでどう教材を揃えるかについても整理しています。

SAPの合格体験記（取得した後どうだったか）については今後SAP合格体験記にまとめる予定です。

出題範囲の把握と試験全体のコンテキスト

AWS認定資格全体の中のSAPの位置づけ

SAPはAWSの認定資格の中でもプロフェッショナルレベルに位置します。他の認定資格との関係やどの順番で取るべきかはAWS認定資格はどれから取るべきかに整理しています。

SAAとの差という観点ではSAPの難易度とSAAとの差で詳しく分解しています。SAAをステップとして取得してからSAPに進むパターンが一般的で、私もその順序で取得しました。

SAPを取ることの意味

SAPを取るまでの過程で、自分がどれくらいAWSの設計に慣れているかを測る機会になりました。出題範囲の4分野は、実際のシステム設計で必要になる視点と重なる部分が多くあります。

取得後にどんな意味があるかという点についてはSAPを取る意味と価値に書いています。転職や評価への影響についてはAWS資格が転職でどう評価されるかも参考になります。

実際の練習を通じた設問の読み方の習得

読み方を学ぶ前に必要なこと

設問の読み方を知識として理解することと、実際の問題で使えることは別のことです。「末尾から読む」「制約を拾う」という方法は、聞けば理解できますが、意識せずに動けるようになるには練習での繰り返しが必要です。

私が読み方の習慣を定着させるのに使ったのは、問題演習のたびに読み方のプロセスを意識することでした。設問を読むたびに「最後の文を読んだか」「制約を確認したか」「選択肢の差分はどこか」を自問するステップを踏みました。最初は時間がかかりましたが、2〜3か月続けると自然に動くようになりました。

練習でよく起きた読み間違いのパターン

設問を読み間違えるときのパターンはある程度決まってきました。私の場合は次の3つが多かったです。

条件の見落とし： 「コスト最小化」を条件だと認識せず、動く構成を選んでしまうケース。設問の冒頭にある制約を「背景の説明」として流し読みしてしまっていました。

動詞の重みを間違える： 「最小化する」と「減らす」では強さが違います。「最小化」はその条件を最優先にすることを意味しますが、「減らす」はある程度許容できる余地があります。この違いを意識するようになってから、優先順位の判断がしやすくなりました。

否定表現の見落とし： 「○○を使わない設計で」「○○に依存しない方法で」という制約を見落とすと、制約に引っかかる選択肢を正解に選んでしまいます。否定表現は設問の中でも目立ちにくい場所に置かれることがあるため、意識して探すようにしました。

制約の強さによる選択肢の絞り方

設問の制約を把握できたら、その制約に違反する選択肢を先に排除する方法が有効でした。4択のうち1〜2つは必ずどこかの制約に引っかかっていることが多く、それを排除すると残り2択の比較に絞れます。

残った2択の比較では、「どちらがより制約を満たしているか」ではなく「どちらがより設問の最優先条件を満たしているか」という観点で選びます。両方が動く構成なら、設問が最も強調している条件（コスト・可用性・運用の手間）に沿ったほうを選ぶ判断です。

SAPと他のAWS認定の比較

SAPはどのレベルに位置するか

AWS認定資格は3つのレベル（Foundational・Associate・Professional）で構成されています。SAPはProfessionalレベルで、Associate（SAAがここに含まれる）の上位に位置します。

Professionalレベルには、SAPのほかにAWS Certified DevOps Engineer – Professional（DOP）があります。SAPとDOPはそれぞれ対象ドメインが異なりますが、どちらもプロフェッショナルレベルの難しさです。

各認定資格の詳細な位置づけや取得順序についてはAWS認定資格はどれから取るべきかに整理しています。

SAA取得者がSAPに進む際の注意点

SAAを取得してからSAPに進む際に意識しておくと良い点をまとめます。

まずSAAで学んだ知識は前提として使えますが、SAPで初めて問われる分野（組織設計・マルチアカウント・移行の深い部分）がSAAとのギャップになります。SAAの復習をしながら同時にSAPの新しい分野を学ぶという二段構えが必要な時期があります。

次に、設問の読み方の転換が必要です。SAAで機能したパターンマッチングの延長では正答率が上がりにくい設問が増えるため、早い段階でトレードオフ判断の練習に切り替えることをおすすめします。

SAPの難しさを体験する方法

SAPを受けるか迷っている場合、AWSが提供している公式のサンプル問題を解いてみることが最も正確な判断材料になります。数問解くだけでSAAとの差が体感できます。サンプル問題はAWS公式サイトから無料で確認できます。

SAPの受験に向けた最初の一歩と教材の選び方についてはSAPの教材の選び方に詳しく書いています。

各分野の学習で意識したサービスの理解の深め方

SAPの4分野を学ぶうえで、サービスの知識をどう深めるかはSAAとは異なるアプローチが必要です。SAAでは「このサービスは○○ができる」という知識で解ける問題が多かったのに対し、SAPでは「このサービスとあのサービスのどちらを選ぶか、その理由は何か」という判断まで求められます。

サービスの比較表を自分で作る

私が使った方法のひとつは、よく出題されるサービスの組について自分で比較表を作ることでした。例えば、Amazon SQSとAmazon SNSとEventBridgeの使い分け、Amazon S3とEFSとEBSの使い分け、といった組み合わせです。

比較する観点は、用途・スケーラビリティ・コスト構造・制限事項・典型的なユースケースです。この比較をノートに書き出す作業自体が理解を整理する効果があり、問題演習でもその比較の視点が使えるようになりました。

間違えた問題のサービス理解を必ず深める

問題演習で間違えたとき、「なぜこの選択肢が正解か」だけでなく「なぜ他の選択肢は不正解か」を調べることが重要です。この「不正解の理由」を確認するためには、公式ドキュメントの制限事項や他のサービスとの比較のページを参照します。

正解の根拠が理解できると、似た条件でも服した問題に対応する力がつきます。間違いノートに「この選択肢はこの制限のため不正解」という形でメモを残しておくと、後の復習で参照しやすくなります。

まとめ

• SAPの出題分野は「複雑な組織への対応」「新しいソリューションのための設計」「既存ソリューションの継続的な改善」「ワークロードの移行とモダナイゼーション」の4つ
• 設問が長くなるのは、実務シナリオの背景・要件・制約を含む形式のためです
• 効率的な読み方として「設問末尾を先に読む」「制約条件を意識して拾う」「選択肢の差分を見る」の3つを習慣にしました
• 長文の読み方は知識ではなく習慣なので、練習問題で繰り返すことで定着します
• SAPの試験対策の全体像はSAPの難易度とSAAとの差にまとめています