最近プラットフォームチームに配属され、AWSを触る機会が増えました。
ただ、インシデント調査などで「どの要件で、どのサービスを触るべきか」を判断できず、毎回手探りでした。
そこでAWS-SAAの学習を、合格だけでなく実務で使える理解を目的に進めました。
本記事では、公式教材とAIを使って“体系的に理解しながら”合格まで持っていった手順をまとめます。
TL;DR
- 公式教材（試験ガイド / サンプル問題 / 模擬試験 / AWS Labs）+ AIだけで合格しました
- AIは「答えを教えてもらう」より、理解のためのテキスト化・問題化・整理に使うと強い
- 暗記ではなく、要件→サービス選定の判断を言語化できる状態を目指しました
この記事で得られること / 得られないこと
✅ 得られること
- 公式教材を中心にした学習の組み立て方（再現しやすい形）
- AIの具体的な使い方（プロンプト付き）
- つまずいた時の復帰方法（技術→サービスへ戻る）
対象読者
- AWS-SAAに興味がある方
- 合格だけじゃなく、実務に通用する知識を積み上げたい方
自己紹介
- 職種：プラットドームエンジニア
- エンジニア歴：新卒１年目
- AWS経験：約２〜３ヶ月ぐらい
- 勉強期間：1~2週間
- 学習時間（平日/休日）：平日→1h / 休日→5h
- 受験日：2026/01/25
- 結果（合否 / スコア）：合格 / 737
なぜAWS-SAAを選んだか
最近プラットフォームチームに配属されて、AWSを触る機会が一気に増えました。
特にインシデント調査でログや設定を追う場面が多かったんですが、
- いま目の前の事象に対して 「どのサービスを見にいくべきか」
- そのサービスの中でも 「何が正常で、何が怪しいのか」
- そもそも 「この要件ならどういう構成が素直なのか」
この判断ができず、毎回「先輩の言ってる単語を検索して追いかける」状態でした。
なので今回は、点の知識ではなく、要件と構成がつながった理解を作る目的でSAAを選びました。
（合格が目的というより、仕事の判断材料を増やしたかった）
使ったもの（公式教材・AI・学習環境）
公式教材
- サンプル問題（20問）
- 模擬試験（65問）
- 試験ガイド（試験範囲・ドメイン/タスクが書かれているもの。公式サイトで取得可能）
- AWS Labs（公式のハンズオン教材）
AI
- Claude Code（テキスト化・問題化・整理・理解補助に使用）
学習の全体設計
自分の中での方針はこれでした。
- 試験ガイドの構造（Domain → Task）に沿って
理解の地図をAIに作らせる
AWSの試験はDomainごとに試験領域が分かれていて、そのDomainはTaskによって構成されています
AWS Certified Solutions Architect - Associate (SAA)
└─ 試験ガイド（Exam Guide）
├─ Domain 1: 〇〇（例：Secure Architectures）
│ ├─ Task 1.1: 〇〇を設計する
│ ├─ Task 1.2: 〇〇を実装する
│ └─ Task 1.3: 〇〇を評価/改善する
│
├─ Domain 2: 〇〇（例：Resilient Architectures）
│ ├─ Task 2.1: 〇〇を設計する
│ ├─ Task 2.2: 〇〇を実装する
│ └─ Task 2.3: 〇〇を評価/改善する
│
├─ Domain 3: 〇〇（例：High-Performing Architectures）
│ ├─ Task 3.1: 〇〇を設計する
│ ├─ Task 3.2: 〇〇を実装する
│ └─ Task 3.3: 〇〇を評価/改善する
│
└─ Domain 4: 〇〇（例：Cost-Optimized Architectures）
├─ Task 4.1: 〇〇を設計する
├─ Task 4.2: 〇〇を実装する
└─ Task 4.3: 〇〇を評価/改善する
学習フローはこんな感じです。
- 試験ガイドをAIに読み込ませて、Domainごとのテキスト（体系）を作らせる
- そのテキスト + 試験ガイド + サンプル問題を材料に、Taskごとに20問くらい問題を作らせる
- AWS LabsでHands-on（“机上の理解”を“実務の理解”に寄せる）
- 最後に模擬試験（65問）で仕上げ
1) 試験ガイド → Domainごとの“理解テキスト”をAIに作らせる
AWSの試験って、Domainで大枠の領域が分かれていて、その下にTaskがぶら下がってますよね。
ここをそのまま目次にして、「理解の教科書」をAIに作らせました。
うまく行くとこんな感じになります
ここで意識したこと
テキストを作るときは、説明の粒度をサービス名の暗記にしないように、毎回こういう問いで固定しました。
- それは何？（一言で）
- どういった技術をサービス化したもの？
- なぜ必要？
- 使い方は？（典型的な流れ）
- いつ使う？/ いつ使わない？（判断基準）
- トレードオフは？
実際のプロンプト例（テキスト化）
あなたはAWS試験対策の有名講師です。
AWS_SAAのdomain○の学習ノートを作成してください。
(保存先：<ファイルパス>)
下記の試験範囲を参考してください。
その際に下記のルールに従って記述してください
# ルール
- 読者は新卒エンジニアであるため専門用語や複雑な仕組みはわかりやすく丁寧に説明してください
- 試験範囲は網羅しつつ、不足もなく過剰でもない分量で
- 初学者が理解しやすい、構成でまとめてください
- 情報の羅列だけではなく、技術的な背景や仕組みのわかりやすい説明も含めてください
- 技術的な説明をするときは、What(それは何？どういった技術をサービス化したもの？),Why(なんで必要なの？), How(どうやって使うの？使われているの？)を意識して丁寧に説明してください
- 試験対策を意識しつつも、実務でも使える知識(例えばユースケースなど)を意識してまとめてください
- 表やグラフなどを適切に扱い、 **過剰でもなく不足でもない適切な量** で見やすくまとめてください
- フローチャートとシーケンス図だけはmermaid
- それ以外の自由な可視化は全てASCII図
- 情報の整理などは表
- 表の際はその表に理解しやすい、または覚えやすいような情報を扱うカラム(特性の分類やグルーピングなど)を追加し理解がしやすいようにしてください
- グラフや表は情報をまとめる分にはいいですが、**理解を深めるために文字でわかりやすく説明することも怠らないでください**
- 出力は1つのファイルにまとめてください
# 試験範囲
<ファイルパス>
ポイント：
AIに“丸暗記用の要約”をさせると楽だけど弱いです。
「背景技術」「判断基準」「トレードオフ」を固定で出させると、理解が積み上がりやすかったです。
2) テキスト + 試験ガイド + サンプル問題 → Taskごとに20問ずつ作らせる
テキストを作った後、各Taskごとに20問くらい「理解チェック問題」を作らせて、こんな感じで解いていました。
なぜサンプル問題も読み込ませた？
理由は単純で、問題の雰囲気と難易度を寄せたかったからです。
（AIに勝手な世界観で問題を作られるとズレるので、公式のトーンを混ぜる）
ここで意識したこと
よくある「試験に出そうな予想問題を作って」ではなく、
- テキストを体系的に理解できているか
- 混同しやすい比較ができるか
- 要件を読んで判断できるか
この辺りをチェックできる問題に寄せました。
実際のプロンプト例（問題化）
AWS_SAAのdomain○の問題を作成して欲しいです
その際にまとめノートと試験範囲、サンプル問題を参考にしてください
# まとめノート
<ファイルパス>
# 試験範囲
<ファイルパス>
# サンプル問題
<ファイルパス>
タスクステートメントごとに20問前後作って欲しいです
問題の形式や問題文や回答文の長さや言葉遣い、雰囲気、問題の意図、難易度はサンプル問題を参考にしてください
ただし、 **サンプル問題と同じ問題は作成しないでください**
問題は試験範囲の内容を網羅し、1問1答の様な感じではなく、体系的で理解が問われるような問題を作成してください
各選択肢の間には改行を入れてください
また、解説は必ずノートのどの部分が解答の根拠になっているかを明示してください
作成した問題はタスクステートメントごとに
<ファイルパス>
にマークダウン形式で作成してください
回答部分は<details> <summary>解答と解説</summary> で囲んでください
この20問は「点数を取るため」より、理解の穴を見つける診断として使いました。
間違えたら、そのTaskのテキストに戻って「判断軸が欠けてる」部分を補強する感じです。
3) AWS LabsでHands-on（実務理解を深める）
テキストと問題だけだと、どうしても“机上”になりがちでした。
なので、AWS Labsでハンズオンして、
- コンソールの導線
- 設定項目の意味
- 何が怖い設定で、何が安全寄りなのか
この辺りを体で掴むようにしました。
4) 最後に模擬試験（65問）
最後に模擬試験を解いて、ここで初めて「試験形式での耐性」を見ました。
ここは勉強のためというよりも、本当に試験を意識して取り組みました
つまずきポイントTop3
1) サービス以前に“技術”がわからない
VPCとかIAMがつらい時って、「AWSの機能が難しい」より先に
ネットワークや認証認可の前提が曖昧なことが多かったです。
その場合は一旦サービス名を捨てて、背景技術をAIに解説させました。
腹落ちしてからサービスに戻すと、急に楽になりました。
2) 似たようなサービスが出てきてこんがらがる
SAAは「比較」が多いので、似たサービスが積み重なると崩壊します。
ここはAIに マップ（整理図） を作らせて、知識を整列させました。
3) 問題文が読みづらい
これは自分だけかもしれませんが、なんかAWSの試験問題って絶妙に読みにくいんですね...
これの対策は慣れだと思うので、AIに似たような文体の問題を作らせたのが効きました
やらなかったこと（アンチパターンとリスク）
問題集を回し続けるだけの暗記はやりませんでした。
- 暗記自体が楽しくない
- 実務に生きない（判断ができるようにならない）
- そもそも合格が目的じゃない
問題は使うとしても、「覚える」じゃなくて「穴を見つける」用途に寄せました。
試験当日の戦い方
当日はとにかくこれを意識しました。
- 問題文をしっかり読む
- キーワードだけ拾って回答しない
- 要件を頭の中でイメージして、「この構成なら何を選ぶか」を考える
SAAは「雰囲気で選ぶ」より、「要件を満たす構成を選ぶ」ゲームだと思ってます。
合格して“実務で効いた”こと
正直、受かったばかりなので「これが劇的に変わった！」みたいな実感はまだ薄いです。
ただ、すでに感じているのは、
- 先輩の話（構成・用語）がイメージできる
- 「それって何のため？」が自分の中で繋がりやすい
- 実際に 「こういうデータはあのサービスを見にいけばいいんだ！」 と考えられるようになった
この状態になったのは大きいです。
少なくとも、AWSを触るときの“怖さ”はかなり減りました。
まとめ
- 公式教材を軸にして、AIで 体系化（テキスト）→ 問題化（理解チェック）→ 整理（マップ） を回すと強い
- つまずいたらサービス名を捨てて、背景技術に戻る
- 暗記ではなく、要件→判断の言語化を積むと、試験にも実務にも効く