アソシエイトまでは、サービスの知識がそのまま点になりました。ところがプロフェッショナル級の問題では、知っているサービスの話なのに選択肢がどれも「動く」ように見えて、2択から絞れなくなります。長文も重なり、読み直しで時間が減っていきます。この記事は、その理由を問題の構造として説明し、自分で使える読み方の手順にします。
この記事の結論
- 長文は「状況・要件・制約・最適化の軸」の4つに分けて読みます。
- 選択肢は「正しいか」ではなく「制約を破っていないか」で落とします。
- 「最も〜」の軸（コスト・運用負荷・可用性・移行の手間など）は設問の最後に出るので、先に読みます。
- 複数選択は、選んだものを組み合わせて要件を満たすかを見ます。
- 軸の言葉は、Well-Architected の柱と、設計の層で学んだトレードオフに対応します。
- 読み方は過去問の暗記ではなく、自分の設計判断を言葉にする練習で鍛えます。
プロフェッショナル級の問題は、アソシエイトと何が違うのか
違いは知識の量というより、問われ方にあります。AWS の公式ページによると、Solutions Architect - Professional の問題形式は、1つを選ぶ multiple choice か、複数を選ぶ multiple response です。形式そのものはアソシエイトと変わりません。変わるのは、選択肢の置き方です。
アソシエイト級では「このサービスは何をするものか」を知っていれば、正解が1つ浮かび上がる問題が多くあります。プロフェッショナル級では、選択肢の多くが実際に動く構成です。動かない選択肢は少数で、本当の分かれ目は「この会社の条件で、どれが一番合うか」にあります。つまり問題は、知識を確かめるというより、要件の中の制約で動くものを落としていく構造をしています。
設計の層で学ぶトレードオフ（可用性とコスト、疎結合と複雑さ、マネージドと自由度）を、問題文の言葉から自分で引き出せるかが問われます。まだ読んでいなければ、先に次の記事で天秤の言葉を持っておくと、このあとの話が読みやすくなります。
READ ALSO — プロフェッショナル向け・段4 設計
トレードオフの考え方｜「なぜそのサービスか」を根拠つきで説明する型と、Well-Architected の6本柱の使い方
試験の問題数・時間・採点の扱いは版で変わります。この記事には書かないので、受ける版の試験ガイドで確認してください。
問題文は「状況・要件・制約・最適化の軸」に分けて読む
長い問題文を頭から順に理解しようとすると、情報が多すぎて、どれが判断に効くのか分からなくなります。そこで、読みながら4つの引き出しに仕分けます。
READ IN FOUR PARTS長文を4つに分けて読む
長い問題文は状況・要件・制約・最適化の軸に仕分ける
-
状況
いまの構成と、会社や業務の背景
選択肢を落とす基準にはならない。読み流してよい
-
要件
新しく満たしたいこと
復旧の目標、公開の範囲、扱うデータの種類など
-
制約
変えられない条件
既存システムを触れない、地域を出せない、期限がある、など
-
軸
「最も〜」に入る言葉
コスト・運用負荷・可用性・移行の手間。設問の最後に出る
| 引き出し | 何が入るか | 選択肢を落とす力 |
|---|---|---|
| 状況 | いまの構成、会社や業務の背景 | ほぼ無い。理解の前提として読む |
| 要件 | 新しく満たしたいこと（復旧の目標、公開範囲、扱うデータの種類など） | 満たさない選択肢を落とせる |
| 制約 | 変えられない条件（既存システムを触れない、地域を出せない、期限がある等） | 強い。破る選択肢は答えにならない |
| 最適化の軸 | 設問の最後の「最も〜」に入る言葉 | 残った選択肢の比べ方を決める |
状況は、読み流してかまいません。一方で、要件と制約は文の言い回しに現れます。「〜しなければならない」「〜は変更できない」「〜を避けたい」といった文は、制約の候補です。読みながら、その文に印を付けるつもりで拾ってください。
注意したいのは、状況と制約の見分けです。「現在はオンプレミスで運用している」は状況ですが、「オンプレミスのシステムは改修できない」は制約です。同じ話題でも、変えられるかどうかで引き出しが変わります。
CHECK 1ここまでの確認
長い問題文のうち、選択肢を落とす基準になる「制約」にあたるのはどれ?
答えと解説
答え: 2. 既存システムを変更できない、という条件の文
制約は変えられない条件で、これを破る選択肢は答えになりません。状況の説明は背景であり、落とす基準にはなりません。「問題文は4つに分けて読む」の章を読み直してください。
選択肢を「制約を破っていないか」で落とす仕組みとは
選択肢を上から順に「これは正しいか」と評価すると、どれも正しく見えて時間を失います。仕組みとしては、選択肢が全部「動く」ので、正しさでは決まらないのです。そこで評価の問いを「制約を破っていないか」に替えます。
NARROW DOWN選択肢の絞り方
正しさで選ばず、制約を破るものから落とす
-
選択肢 4つ
どれも単体では動く
-
制約で落とす
変えられない条件を破るものを外す
-
残り 2つ
どちらも要件と制約は満たす
-
軸で比べる
「最も〜」に近い方が答え
手順は次のとおりです。
- 拾った制約を1つずつ、各選択肢に当てる。
- 1つでも破る選択肢は、構成として優れていても外す。
- 残った選択肢は、どれも要件と制約を満たしている。
- 最後に、最適化の軸でどちらが近いかを比べる。
この順番に意味があるのは、制約の判定は「はい・いいえ」で決まり、軸の比較は程度の話になるからです。判定しやすいものから先に使えば、迷う範囲が早く狭まります。
制約の当て方にも癖があります。選択肢の中に「既存のシステムを作り直す」「別の地域へデータを移す」といった一文があれば、制約と照らす価値があります。新しいサービスの名前を見て「良さそうだ」と思う前に、その構成が条件を破らないかを確かめてください。
CHECK 2ここまでの確認
選択肢を絞るとき、最初にやることとして合っているのはどれ?
答えと解説
答え: 1. 制約を破るものを落とし、残りを最適化の軸で比べる
選択肢はどれも単体では動くので、正しさでは決まりません。まず制約で落とし、残ったものを軸で比べます。「制約を破っていないかで落とす」の章に戻ってください。
「最も〜」の軸が違うと、同じ構成でも正解が変わる理由
設問の最後には、「最も費用対効果が高い」「運用の負荷が最も小さい」のように、比べ方を決める言葉が置かれることがあります。この軸は、設問の最後まで読まないと分かりません。長文を頭から読む前に、先に最後の一文だけを見ておくと、どの情報が効くかが読み取りやすくなります。
軸は、Well-Architected の6本の柱（運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性）の言葉に対応させると整理できます。Well-Architected のフレームワークは、設計判断の長所と短所を理解するための問いの集まりです。柱を「満たす基準」ではなく、「何を優先して何を譲るかの言葉」として使うのがコツです。
SAME DESIGN, DIFFERENT AXIS軸で答えが変わる
同じ要件でも、最適化の軸が変わると選ぶ構成が変わる
コストを最優先
- 平常時の費用を抑える方式
- 復旧に手順と時間がかかる
- パイロットライトのような方式
復旧の速さを最優先
- 平常時から多く動かしておく
- 費用と運用が増える
- ウォームスタンバイのような方式
支点は「設問の最後に書かれた軸」
たとえば災害対策の方式を選ぶ場面を考えます。データは常に別リージョンへ複製しておき、サーバーは障害時に起動する方式（パイロットライト）は、平常時の費用を抑えられます。ただし、復旧には起動の手順と時間がかかります。縮小版を常時動かしておく方式（ウォームスタンバイ）は、平常時から費用がかかる代わりに、復旧が速くなります。
要件も制約も同じなら、設問が「コスト」を軸にするか「復旧の速さ」を軸にするかで、選ぶ方式が変わります。どちらの構成も、それ自体は正しいのです。ここが「知識を問う」問題との違いで、軸の読み落としが、そのまま取り違えになります。設計の層の記事で、方式ごとの違いは詳しく説明しています。
READ ALSO — プロフェッショナル向け・段4 設計
災害対策（DR）の設計｜RTO と RPO から4つの方式を選び、訓練で確かめる
CHECK 3ここまでの確認
設問の最後にある「最も〜」の軸が変わると、変わるのはどれ?
答えと解説
答え: 2. 最も適した構成
制約は問題文に固定されていて、軸が変わるとトレードオフの重みが変わり、選ぶ構成が変わります。「最も〜の軸」の章を確認してください。
複数選択（組み合わせ）の問題は何を見るのか
multiple response の問題では、選んだ複数の選択肢が、組み合わさって要件を満たすことが前提になります。1つずつの選択肢が正しいかではなく、組み合わせとして抜けや重なりが無いかを見ます。
見るのは次の3点です。
- 要件を全部カバーしているか。片方の要件にしか触れない組み合わせは外れます。
- 制約を破る選択肢が混ざっていないか。1つでも混ざれば、その組み合わせは成り立ちません。
- 同じ役割の選択肢が重なっていないか。役割が重なれば、別の要件が手当てされていません。
作業としては、まず要件を箇条書きにし、各選択肢がどの要件を担うかを対応させます。担当の要件が決まれば、残りは軸で比べます。1つずつ選ぶ問題より手順は増えますが、仕分けの型は同じです。
選択肢の数や、何個選ぶかは問題文の指示に従います。指示を読み落とさないよう、設問の最後の文を先に確認してください。
読み方を鍛える練習の回し方と、時間配分
読み方は、問題を解いた数ではなく、解いたあとに何を書き出したかで鍛えられます。1問ごとに、次の3行をメモに残す回し方が効果的です。
- この問題の制約は何だったか（どの文か）。
- 設問の軸は何で、柱のどれに対応するか。
- 落とした選択肢は、どの制約を破っていたか。
正解したときも同じ3行を書きます。偶然当たったのか、制約を拾って当てたのかを、自分で切り分けられるからです。続けるうちに、制約の言い回しと軸の言葉に型が見えてきます。
練習の素材は、公式の試験ガイドと公式のサンプル問題、そしてこの媒体の練習問題のように出所の分かる問題を使います。本試験の問題を再現して出回っているものは、使わないでください。暗記した答えは版の改定で通用しなくなり、読み方の力は残らないからです。
もうひとつの練習は、自分の設計判断を言葉にすることです。実務で構成を選んだとき、何を制約と置き、どの軸で比べたかを書き出します。問題の読み方と設計の判断は、同じ型でつながります。
時間配分をどう組むか
試験時間と問題数は版によって変わるため、この記事では数字を書きません。受験する版の試験ガイドで確認し、そこから逆算して1問の目安を決めてください。
時間の組み方の考え方だけ、ここで整理します。
- 設問の最後の文を先に読み、軸と何個選ぶかを確認する（数秒で済む）。
- 長文は4つの引き出しに仕分けながら1回で読む。2回読みは、制約を拾い損ねたときだけにする。
- 絞れない問題には印を付けて先に進み、見直しの時間に回す。
型にしておくと、迷う時間そのものを減らせます。長文を読むたびに「どこから理解しようか」と考える手間が無くなるからです。
試験の版の移り変わりは、次の記事で扱っています。範囲が変わるときは、読み方の型より先に、問われる分野がどう動くかを確認してください。
まとめ
プロフェッショナル級の問題が解きにくいのは、知識が足りないからというより、選択肢が全部動く構造だからです。長文を「状況・要件・制約・最適化の軸」に分け、制約を破るものを落とし、残りを軸で比べます。軸は Well-Architected の柱の言葉で整理でき、複数選択は組み合わせとして要件を満たすかを見ます。型を決めて、解いたあとに3行のメモを残せば、読み方は暗記よりも長く使えます。
Cloudory 執筆者（AWS 認定 全冠）
読み方の型は、本記事での整理です。公式が定めた手順ではありません。試験の範囲・形式は、受験する版の公式ページで確認してから学習を組んでください。
参照ソース
- AWS Certified Solutions Architect - Professional（公式） — 問題形式が multiple choice または multiple response であることの根拠。問題数・時間は版で変わるため本文には書かず、公式ページへ送った
- AWS Well-Architected Framework（公式ドキュメント） — 設計判断の長所と短所を理解するための問いの集まりであること、6本の柱を「最適化の軸」の言葉として使う根拠
