AWS試験の長文問題を「Must/Better」で解体する手順（SAA/SAP共通）

この記事は、前回反響があった

【AWS未経験】1年でCFP → SAA → SAPに合格した勉強法

の解法に着目したものとなっています。

前回の記事では、勉強順・使った教材・試験スコアなど「全体像」をまとめました。
今回はその中でも質問が多かった 「問題の解き方」 にフォーカスします。

対象は SAA / SAP の長文問題。
長文で点が安定しない原因は、知識不足というより 読み方（処理順）のブレ です。

そこで本記事では、僕が本番で毎回同じように実行していた
Must / Better 分解テンプレ（手順の固定化） を、詳細版として公開します。

狙いはシンプルで、知識量を増やすことではありません。
読解ミスを減らし、4択を2択まで落とし、判断を再現可能にすることです。

注意事項として、ぼくがハマったやり方なので他の人には合わないとかツッコミがあるかもです笑

結論：長文問題は「内容理解」じゃなく「条件の仕分け」で勝つ

長文を読んで悩む原因はだいたいこれです。

**絶対条件（Must）**と、**できれば条件（Better）**と、背景情報が混ざって見える
「すごそうな構成」に引っ張られて、条件より選択肢を見てしまう
4択を1個ずつ吟味して時間が溶ける

なので、最初にやることは **「条件の仕分け」**です。

Must / Better / 制約 / 背景の定義（ここがズレると全部ズレる）

Must（絶対条件）
破ると不正解。問題文の主語になりやすい。
例）「〜しなければならない」「〜を保証する」「〜を満たす必要がある」
Better（できれば条件）
Mustを満たしたうえで優先する“好み”。
例）「可能であれば」「望ましい」「できるだけ」
制約（Constraints）
既存環境・運用・コスト・移行・セキュリティ等で“手段を縛る条件”。
例）「既存の○○を継続利用」「運用負荷を最小化」「コスト最小」
背景（Context）
情報としてはあるが、直接の採点条件ではないことが多い（ただしSAPは背景も刺さる）。
例）業界・規模・現状の課題説明

まずこれをコピペして使う：Must/Better分解テンプレ

試験中は紙（または頭の中）でこの順に並べます。
順番が重要です。

【1】主語（何を最適化したい？）
- コスト / 運用 / 移行 / セキュリティ / 可用性 / 性能 / 拡張性

【2】Must（絶対条件）

Must1:
Must2:
Must3:

【3】制約（手段を縛る条件）

既存環境:
運用:
コスト:
移行:
セキュリティ/コンプラ:

【4】Better（できれば）

Better1:
Better2:

【5】落とし穴（ひっかけポイント候補）

過剰設計になりやすい？
運用が重くなりやすい？
互換性/移行が地雷？

手順：長文を「解体」してから選択肢を見る（超重要）

ここから先は「知ってるかどうか」ではなく、本番で毎回ブレずにやれるかの手順です。
SAAでもSAPでも、長文で崩れる人はだいたい「処理順」が崩れています。

Step 0：選択肢を先に見ない（最優先ルール）

長文問題で一番やってはいけないのはこれ。

問題文を流し読み
なんとなく選択肢を見る
「それっぽい」構成に引っ張られて読む

この時点で、もう勝負が決まります。
選択肢は強いワード（DX、Multi-AZ、Aurora、EKS…）が並ぶので、脳が勝手に「正解探し」モードになります。

やることは1つだけ。

問題文を最後まで読んでから選択肢を見る

Step 1：主語（最適化対象）を1つ決める（10秒）

問題文は必ず「何を優先したいか（主語）」があります。
これを先に決めると、2択で迷ったときの決定打になります。

主語の候補はほぼ固定です。

コスト最小化
運用最小化
低遅延 / 高性能
高可用性 / 耐障害性
セキュリティ / 監査 / コンプラ
移行（ダウンタイム、互換性、段階移行）
スケーラビリティ

迷ったら、「一番強い圧のある制約」を主語にします。

例：

「運用チームが小さい」→ 運用
「厳格な監査要件」→ セキュリティ/監査
「レガシーから段階移行」→ 移行

Step 2：Must（絶対条件）だけ抜き出す（20〜30秒）

ここは機械的にやります。

Mustは、破った瞬間に不正解になる条件です。
文章中の以下の表現はMustの合図です。

〜しなければならない
〜を保証する
〜が必要
〜を満たす
〜を防ぐ
〜を維持する

Mustは多くても3つまでで十分です。
Mustが2〜3個取れた時点で、選択肢は勝手に減ります。

Step 3：制約（手段を縛る条件）を抜き出す（20〜30秒）

SAAよりSAPで差がつくのがここです。
制約は「何を達成するか」ではなく「どうやってもらうか」を縛ります。

典型的な制約はこれです。

既存環境の縛り（OS、DB、ネットワーク、認証）
運用体制（担当人数、スキル、24/365対応の可否）
コスト（最小、予算上限、従量の怖さ）
移行（段階移行、停止不可、データ量、回線）
コンプラ（暗号化、監査ログ、データ所在、鍵管理）

ここを抜き出すと、「技術的には正しいがこの会社では無理」な選択肢を消せます。

Step 4：Better（できれば条件）を拾う（10〜20秒）

Betterは最後の決め手になります。

Betterの合図はこういう表現です。

可能であれば
望ましい
できるだけ
なるべく
将来的に対応したい

注意点は1つ。

BetterのためにMustを壊す選択肢は不正解

Betterは「加点」じゃなく「タイブレーク（同点決勝）」だと思うのが安定します。

Step 5：落とし穴（やられポイント）を1つだけ想像する（10秒）

ここは時間をかけません。
ただ、長文問題の“よくある死に方”を1つだけ警戒します。

過剰設計（やりすぎ）
運用が重い（自前管理が増える）
互換性/移行が地雷（現実的に無理）
コストが爆発（従量課金の罠）
要件の主語がズレてる（性能最適化なのに運用最適化を選ぶ等）

この「警戒フラグ」を立ててから選択肢に入ると、引っかかりにくいです。

Step 6：ここで初めて選択肢を見る（30秒〜）

やっと選択肢を見ます。
ここからの鉄則はこれ。

選択肢を1個ずつ吟味しない
カテゴリで束ねて、グループ単位で消す

4択 → 2択に落とす最大のコツ：「グルーピング」

長文問題で時間が足りなくなる人は、4択を4回レビューしています。
勝つ人は、4択を「2グループ」にしてから潰します。

2-1. まず“技術カテゴリ”で束ねる（正解は考えない）

例（よく使う束ね方）：

接続：Direct Connect / VPN
LB：ALB / NLB
実行基盤：EC2 / ECS / Fargate / Lambda
メッセージング：SQS / SNS / EventBridge
ストリーミング：Kinesis / MSK
DB：RDS / Aurora / DynamoDB
ストレージ：S3 / EFS / EBS / FSx
認証：Cognito / IAM / Federation

この段階では「どれが正解っぽいか」は考えません。
まずは 棚に並べるだけ。

2-2. 次に“判断軸”でグループごと潰す

ここで使う判断軸は、さっき抜き出したこれです。

主語
Must
制約

これを当てると、グループが丸ごと落ちます。

例：

主語：運用最小化
→ 自前運用が増えるグループを落とす
制約：既存DB互換が必要
→ 互換性のないDBグループを落とす
Must：低遅延
→ 非同期で遅延が出る設計グループを落とす

この作業で 4択→2択になります。

2択で迷ったときの最終テンプレ（これで決める）

最後に迷ったら、これだけやります。

主語に強く効く方を選ぶ
「なぜもう片方がダメか」を Must/制約に紐づけて言える方を選ぶ
「設計レビューで説明できるか」を自問する
- 説明できない方は切る

さらに安定する：試験中チェックリスト（30秒）

□ 選択肢を見る前に問題文を最後まで読んだ
□ 主語（最適化対象）を1つ決めた
□ Mustを2〜3個抜き出した
□ 制約（既存/運用/コスト/移行/監査）を拾った
□ Betterを拾った（最後の決め手）
□ 選択肢をカテゴリで束ねた（グルーピング）
□ Must/制約でグループごと消した
□ 2択は「主語に効く方」＋「他がダメと言える方」で決めた

まとめ：Must/Betterは「読解のミス」を減らす仕組み

長文問題は「理解力」より「仕分けの型」
主語 → Must → 制約 → Better → グルーピング の順で処理する
2択は 「主語に効く方」＋「他がダメと言える方」 で決める