筆者は仕事でAWS環境を使用している。これまでは AWS Certified Cloud Practitioner のみ取得していたが、今月上旬にその上級である AWS Certified Solutions Architect – Associate（SAA）を受験し、合格した。
ただ、試験が終わった瞬間の感想は正直こうだった。
「ダメかもしれない」
問題文は想定より長く、見慣れない文脈（ハイブリッド、DNSフェイルオーバー、移行戦略、AI/ML周辺）が混ざる。読解に時間を取られ、回答がギリギリになって「できた感じがしなかった」。なのに結果は合格だった。
体感として強かったのは、「広くやった」感覚よりも、AIと一緒に“弱点だけ”潰していった手応えの方だった。
この記事では、SAA合格までの学習プロセスを「根性論」ではなく、弱点の見つけ方と潰し方にフォーカスしてまとめる。
そして最後に、この学び方をどう実務（非機能設計・運用）へ接続するかまで落とし込む。
筆者について（前提：AWS以前からインフラを触ってきた）
筆者は、もともとAWS以前からインフラを触ってきたタイプだ。 OS・ネットワーク・冗長化・監視・ログ・バックアップ──いわゆる”非機能”の話は、クラウド以前から現場で揉まれてきた。
一方でAWSは、仕事で触れるだけでなく、個人でもがっつり使い込んでいる。 たとえば仮想通貨の自動売買を題材に、仕組みをサーバレスで組み直して運用してきた。
- 価格データの収集、保存
- 監視・アラート、例外系の潰し込み
- 発注の自動化（必要に応じて手動に切り替え）
- ログの整備と、後から検証できる形への整形
- 不要な常時稼働を避けたスケーラブルな構成
サーバレス化の狙いはシンプルで、常時稼働の固定費を抑えつつ、必要なタイミングだけ確実に動かすこと。 イベント駆動で定期実行し、データを溜め、条件を判定し、通知と発注を分離する。 運用面では「失敗しても壊れない設計」と「あとから追えるログ」を優先した。
要するに、**”AWSで動くものを作って運用する”**経験はそれなりに積んでいた、という前提がある。
とはいえ、触っている領域に偏りがあるのも事実で、試験ではその”穴”がはっきり見えた。 だからこそ、弱点だけを短時間で潰す学び方が必要だった。
AI学習の2段階：ChatGPT 65問 → Claude 45問
試験前、まずChatGPTで65問を解いた。 目的は「知識の穴を広く見つけること」。
ただ、解き終えた時点で、何かが足りない感覚があった。 正答率は6-7割程度で安定していたが、 「なぜこの選択肢が正解なのか」が腹落ちしていない問題が多かった。
そこでClaudeに切り替えた。 Claudeでやったのは、ChatGPTで間違えた分野に絞った45問。
違いは明確だった。
ChatGPT（広く浅く）:
- 正解は教えてくれる
- でも「なぜ他がダメか」の説明が薄い
- 理解というより、暗記に寄ってしまう
Claude（深く詰める）:
- 「なぜ他の選択肢が不適切か」を構造的に説明してくれる
- トレードオフ（コストvs可用性、新機能vs既存機能）の視点が入る
- 対話を重ねると、設計判断の「型」が見えてくる
結果として、Claudeでの45問で正答率が77.8%まで上がり、 「これなら本番でも戦える」という手応えが生まれた。
つまり、ChatGPTで穴を見つけて、Claudeで穴を埋めた形だ。
数字で見る学習成果
Claude演習45問を解き終えた時点での正答率は77.8%（35問正解）。 この数字は、最初から最後までほぼ一定で推移していた。
つまり、「知識を積み上げた」というより、 「最初から持っている経験（サーバレス運用）で7割取れて、残り3割を弱点補強で埋めた」形だ。
分野別で見ると：
- ネットワーク・VPC: 90%以上（実務で触れている）
- サーバレス・イベント駆動: 85%以上（自動売買で経験済み）
- DR戦略・マルチリージョン: 70%前後（実務経験が薄い）
- データ移行・ハイブリッド: 65%前後（オンプレ混在の経験なし）
この「守備範囲の偏り」が可視化されたことで、 間違えた領域だけを集中的に潰す戦略が立てられた。
AIは「答え代行」じゃなく、弱点潰しの参謀にした
AIを使うと伸びるかどうかは、使い方で決まる。
- 伸びない使い方：質問→回答→満足（検索の延長）
- 伸びる使い方：前提→制約→トレードオフ→代替案→運用（腹落ちするまで詰める）
自分がやったのは後者。
AI学習の実例：「間違えた問題」の深掘り方
たとえば、「DMS vs DataSync」の使い分けを間違えた。
間違えた理由: DataSyncは大量データ転送に強いから、データベース移行にも使えると思った。
Claudeとの対話で腹落ちしたこと:
- DataSyncは「ファイルベースの転送」用
- DMSは「データベースの継続的レプリケーション（CDC）」用
- 「継続的レプリケーションが必要 = DMS」という判断軸
この理解が腹落ちした後、Claudeに 「DMSとDataSyncの使い分けを問う類似問題を5問出して」 と指示し、Oracle→PostgreSQLの移行、MySQLのクロスリージョン移行など、 異なる文脈で同じ判断軸を使う練習をした。
これを5問やると、もう「DMS vs DataSync」では迷わなくなった。
「間違えた問題の類似問題」だけを5-10問で補強する
ポイントは、闇雲に新しい問題を増やさないこと。 弱点が浮いたら、そこだけを5-10問くらいの類題で叩く。 そして解説は「正解の理由」より、「なぜ他の選択肢がダメか（トレードオフ）」を重視する。
このやり方だと、暗記ではなく”設計判断の筋肉”がついてくる。
たとえば、以下のような「腹落ちしてなかったところ」は、類題を数回やるだけで解像度が上がった。
- Private SubnetとIGWの経路の話（なぜ出られないのか、NATはどこで何をしているのか）
- SQSの使いどころ（疎結合、リトライ、DLQ、バースト吸収）
- Secrets Manager vs Parameter Store（自動ローテーション機能の有無が決定打）
- Step Functionsの組み込み機能（Retry/Catch）vs カスタム実装
分からないまま進むのを許さず、腹落ちするまでAIに壁打ちする。 これが今回の勝ち筋だった。
本番は「長文×時間制限」の別ゲームだった
実際の試験は、模擬試験よりも問題文が長いと感じた。 設計の背景、制約条件、既存構成、要件の優先順位が一問の中に詰め込まれていて、読解に時間を吸われる。 体感として難易度が上がっていた気がするのは、この”文章の密度”が原因だと思う。
だから当日は、知識勝負というより時間配分の戦術で戦った。
本番での2分ルール運用
実際の試験では、65問を130分で解く。 1問あたり2分が目安だが、最初から2分で解けるわけではない。
自分の運用ルール：
- 1周目（90分）：全問を2分以内で判断、迷ったら印をつけて次へ
- 2周目（30分）：印をつけた問題だけ再検討
- 3周目（10分）：それでも迷うものは「最も無難な選択肢」で埋める
結果として、印をつけた問題は約15問。 2周目でそのうち10問は確信を持って解答できた。 残り5問は「たぶんこれ」で埋めたが、完璧主義を捨てたことで時間切れを回避できた。
試験は「100点を取る競技」ではなく、「72%を確実に取る競技」だと割り切るのが大事だった。
判断の優先順位も決めていた：
- まず要件（可用性/コスト/性能/運用/セキュリティ）を拾う
- “絶対に外せない制約”を見つける（例：RTO/RPO、オンプレ混在、データ移行しない、グローバル冗長など）
- 選択肢を「要件に合わない理由」で落としていく
- 2分を超えて迷うものは一旦印を付けて前に進む（最後に戻る）
このやり方に徹したことで、焦って読み飛ばして事故るより、確実に一問ずつ前進できた。
本番で一番怖いのは、難問そのものより「1問に時間を溶かして、後半の易問まで巻き添えで落とす」こと。 2分ルールは、それを防ぐための安全装置だった。
合格して思ったこと：「経験があっても穴は出る」
AWSを使って実運用していても、試験は”普段の守備範囲の外側”を突いてくる。 だから、広く薄く積むよりも、「弱点をデータで炙り出して潰す」方が効率がいい。
そしてAIは、その弱点潰しの速度を上げるのに向いている。 ただし、AIを”答え代行”にすると、伸びない。 AIを”設計参謀”にすると、腹落ちが起きる。 自分は今回、それをはっきり体感した。
再現するためのAI学習テンプレ（これだけで回せる）
最後に、今回の学習ループをテンプレとして置いておく。 Claude、ChatGPT、LMStudioなど、どのツールでも使えるはずだ。
1）出題モード（解答を出させない）
重要なのは、AIに解答を先に見せないこと。 解答が見えると、「理解した気」になって終わる。
だから出題時は、こう指示する：
5問出して。解答と解説は絶対に出さない。
各問A/B/C/Dの選択肢のみ。
最後に「回答を入力してください」とだけ表示して止まってこうすることで：
- 自分で考える時間が確保される
- 間違えた時の「なぜ?」が強く残る
- 採点時の解説が深く刺さる
AIは便利だが、考える過程を奪われると伸びない。 だから”止まらせる”指示が肝になる。
2）採点モード（間違いだけ深掘り）
私の回答を採点して。
間違いだけ、なぜ誤りか／正解がなぜ正しいか／判断のコツを説明して。
最後に類題を3問出して（解答はまだ出さない）この”出題→回答→採点→類題”を回す。 重要なのは、学習を増やすのではなく、弱点だけを濃くすることだ。
次の一手：AI Practitioner → SAP → ML Engineer
今回の合格でAWSの地図はかなり見えた。次は興味範囲であるAIもやっておきたい。AIの共通言語を整えるAI Practitioner、設計判断力を証明するSAP（Solutions Architect – Professional）、そして機械学習を実務で回すためのML Engineerを狙っていく。
G検定は2023年に取得しているが、復習は必要だろう。時代はAIなので「AWSでAIを回せる人材」は求められる。先に手を付けておきたい。
自動売買のサーバレス基盤は、機械学習の教材としても相性がいい。ただし、いきなり発注ロジックを置き換えるのではなく、まずはNOTIFY_ONLYで予測を出して検証ログを溜める。AIもクラウドも、最後は“運用できて価値が出る”ところまで持っていくのが本番だ。
おわりに
SAAは「知識をどれだけ暗記したか」より、「設計判断をどれだけ積み上げられるか」を問う試験だったと思える。 そして合格の近道は、広くやることではなく、弱点を可視化して、類題で潰すことだった。
AIは、そのサイクルを高速化するための最高の相棒になったと思う。
ただし、使い方を間違えなければ、の話だ。
ChatGPTで広く穴を見つけて、Claudeで深く埋める── この2段階が、今回の学習の核心だった。
この方法が何かの参考になれば幸いである。
