AWS CLF-C02 を Claude Code と自作サイトで取った話

AWS Certified Cloud Practitioner（CLF-C02）に合格した。SES のインフラエンジニアとして本業でオンプレ寄りの運用はやっていたが、AWS はほとんど触ったことがなかった。インフラの感覚はあるのに AWS の語彙が無い、というところからのスタートだ。

合格体験記は山ほど出ているので、この記事ではテーマを 3 つに絞って技術者向けに残しておく。

1. 教材の役割分担表（=「どの教材で、何を、いつ学ぶか」の設計）
2. 自作の AWS 学習サイトを「作る側」で構築したら、各 AWS サービスの手触りが定着した話
3. Claude Code を勉強パートナーとして使い倒したときの実プロンプト（試験対策の効率化）

学習プロセス全体の振り返り（「なぜ AWS の資格を取ろうと思ったのか」・教科書を入れ替えた話・AIF-C01 への接続）は note 側の合格体験記事に詳しく書いた。Qiita 側は実装ハンズオン色を強めに寄せる。

教材の役割分担表

CLF-C02 の合格体験記を読んでいて、一番違和感があったのは「使った教材リスト」が並ぶだけで、教材の 役割分担 がほとんど書かれていない記事が多かったことだった。同じ範囲を別教材で重複して学ぶのは時間の無駄だし、逆に 1 教材で全部やろうとすると抜けたときのリカバリが効かない。

実際に使った教材を、学習設計のなかでの置き場所 で表にすると次のようになる。

教材	置き場所（=役割）	学習フェーズ	カバーする CLF-C02 ドメイン
『AWSの基本・仕組み・重要用語が全部わかる教科書』（SBクリエイティブ）	体系学習・章ごとの知識構造化	着手 1〜3 週目	全 4 ドメイン（章順に追う）
『AWSネットワーク入門 第2版』（大澤文孝 / インプレス）	VPC・サブネット・ルーティングの体系補強	中盤	クラウドテクノロジー（ネットワーク）
AWS Skill Builder（無料コンテンツ範囲）	公式ストーリー・サービス分類のリファレンス	全期間 / 補強	全ドメイン（公式定義の確認）
Ping-t（AWS CLF-C02 対応問題集 / 約 500 問 / 全問無料）	演習量・誤答パターン蓄積	中盤以降	クラウドコンセプト・請求系に強い
aws-cert-roadmap-lab.com（自作 / サーバーレス構成）	実装で覚える AWS サービスの手触り	全期間 / 並走	サービス構築・統合系
Claude Code（AI エージェント / 学習パートナー）	模擬試験の作成・採点・弱点分析・ノートフィードバック	中盤〜直前	全ドメイン（理解の歪み検出）
模試（複数本）	到達度測定・弱点炙り出し・本番リハ	中盤〜直前	全ドメイン（本番形式）

ポイントは、同じ単元を複数の角度から踏める ようにしたことだ。

たとえば「IAM のロール / ポリシー」という単元なら、メイン教科書で章として読み、Skill Builder の公式分類で位置づけを確認し、Ping-t の問題で誤答パターンを蓄積し、自作サイトの GitHub Actions OIDC 設定で実装する。同じ単元を 4 回、別の角度から踏むことになる。これが定着につながった感覚がある。

Skill Builder は無料でカバレッジは足りる。ただし「確実に取りに行く」なら教科書で肉付けする

AWS Skill Builder は有料の Enhanced 個人プラン（Individual Subscription）の存在が目立つせいで「有料前提」と思われがちだ。実際には、CLF-C02 向けには無料の学習プラン・Module・個別コースだけで、合格ラインには届くカバレッジがある。私は最終的に Enhanced を契約せずに合格した（有料プランの最新価格は AWS Skill Builder 公式ページを参照）。

ただし率直に言うと、Skill Builder 単体で 「もう少し確実に点を取りに行きたい」と思うと少し物足りない 場面があった。公式の分類・用語定義は網羅されているが、章ごとに深掘りする密度は本のほうが上だった。そこを メイン教科書『AWSの基本・仕組み・重要用語が全部わかる教科書』（SBクリエイティブ）で補強する 二段構えにすると、抜けが目に見えて減った。

Skill Builder = リファレンス（骨格）/ メイン教科書 = 体系書（肉付け）、という補強関係で使い分けるのがおすすめだ。

Ping-t は「演習量」担当として組み込んだ

Ping-t の AWS CLF-C02 対応問題集は約 500 問あり、しかも全問無料（2025-03-31 リリース）。これを「演習量の主軸」として組み込んだ。

ただし Ping-t だけだと、誤答パターンを蓄積する効果は強いが、サービス選定軸やアーキテクチャ全体像の把握はカバーできない。そこはメイン教科書と Skill Builder で別途補強する前提で使う必要がある。

サイトを「作る側」にまわって覚えた AWS サービスの手触り

学習のため aws-cert-roadmap-lab.com という AWS 学習サイトを構築し、運営している（GitHub）。構成は次の通り。

• フロントエンド: Next.js（静的エクスポート）+ TypeScript + Tailwind CSS v4
• バックエンド: Python の AWS Lambda
• 使用 AWS サービス: S3・CloudFront（OAC 付き）・API Gateway・Lambda・DynamoDB・IAM・Budgets の 7 サービス + Route 53・ACM（us-east-1）・CloudWatch
• CI/CD: GitHub Actions + OIDC（長期アクセスキー不要）

CLF-C02 の学習中にいちばん効いたのは、このサイトを 「作る側」にまわっていた経験そのもの だった。教科書で「CloudFront は CDN です」「IAM は認可です」と読んでもピンとこないが、構築の手順を踏むだけで関係性ごと定着する。

構築で手触りが特に深まった主要サービスは以下。

• CloudFront（CDN）: Origin に S3 を指定、キャッシュビヘイビア、カスタムエラーレスポンスで 403 / 404 を index.html にフォールバック。「静的サイトの公開と認可の最前線」として体で覚えた
• S3 + OAC: バケットポリシーで OAC からの GetObject のみを許可。パブリック公開ではなく OAC を経由させる理由は、構築しないと腹落ちしなかった
• ACM（us-east-1 必須の制約）: CloudFront に紐づける証明書は東京リージョンではなく us-east-1 で発行する必要がある。これは教科書で読むより、実装で詰まったほうがはるかに記憶に残った
• Route 53: A レコード（Alias）で CloudFront のディストリビューションを指す。Alias レコードが AWS リソース専用である理由は、構築しないと言葉が浮いてしまう
• IAM + OIDC: GitHub Actions から OIDC を使い、長期アクセスキーを持たずに AWS にデプロイ。信頼ポリシーで Principal を絞り、許可ポリシーで Action を絞る二段階構造として頭に残った
• Lambda: 問い合わせ API を Python で受け、DynamoDB に書く。実行ロール、API Gateway 統合、CloudWatch Logs、コールドスタートの体感を通じて自然と覚えた

実際にいちばんハマった話: GitHub Actions OIDC の IAM 設計

長期アクセスキー（AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY）を GitHub Secrets に置く方式を捨てて、GitHub Actions から OIDC 経由で AWS の一時クレデンシャルを引き受ける 構成に切り替えた。設定は 4 ステップで済むように見えて、信頼ポリシーの sub 条件で小一時間詰まった。以下が実際に動いた設定の骨子だ。

1. IAM に OIDC ID プロバイダーを登録

• Provider URL: https://token.actions.githubusercontent.com
• Audience: sts.amazonaws.com

2. IAM ロールを作成（信頼ポリシー）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:vincentmango-wen/aws-cert-roadmap-lab:*"
        }
      }
    }
  ]
}

ハマったのはここ。sub を repo:vincentmango-wen/aws-cert-roadmap-lab:ref:refs/heads/main のように厳格に絞ろうとしたら、Pull Request 起点のワークフローが assume できなくなった。私の場合は「リポジトリ単位で許可 + 許可ポリシー側で最小権限を絞る」方針に倒して、sub は repo:vincentmango-wen/aws-cert-roadmap-lab:* で緩めに置いた。

3. 許可ポリシーで最小権限を絞る

デプロイに必要なのは実質「S3 sync + CloudFront invalidation」だけ。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:DeleteObject", "s3:ListBucket"],
      "Resource": ["arn:aws:s3:::<BUCKET>", "arn:aws:s3:::<BUCKET>/*"]
    },
    {
      "Effect": "Allow",
      "Action": ["cloudfront:CreateInvalidation"],
      "Resource": ["arn:aws:cloudfront::<AWS_ACCOUNT_ID>:distribution/<DIST_ID>"]
    }
  ]
}

4. GitHub Actions ワークフローから引き受ける

permissions:
  id-token: write   # OIDC の一時トークン取得に必須
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::<AWS_ACCOUNT_ID>:role/<ROLE_NAME>
          aws-region: ap-northeast-1
      - run: aws s3 sync ./dist s3://<BUCKET>/
      - run: aws cloudfront create-invalidation --distribution-id <DIST_ID> --paths "/*"

この 4 ステップで、長期キーを GitHub に置かない構成が完成する。教科書だと「IAM はロールとポリシー」で 1 行で片付く話が、詰まったあとには「信頼ポリシーで Principal（誰が引き受けるか）を絞り、許可ポリシーで Action（何をしていいか）を絞る」という 二段階の権限モデル として頭のなかに別々の箱ができた。試験本番で IAM 系の問題文を読むスピードが上がったのは、たぶんこの詰まりが直接効いている。

CLF-C02 知識と自作サイト実装の対応表

CLF-C02 で扱う主要サービスと、自作サイトでの実装場所をマッピングしておく。

CLF-C02 で学ぶサービス	自作サイトでの実装位置	実装で学べた追加知識
S3	静的サイトのオリジン / 非公開バケット + OAC	バケットポリシー / OAC の設定差
CloudFront	CDN として S3 の前段	キャッシュビヘイビア / カスタムエラーレスポンス
Lambda	問い合わせ API のバックエンド（Python）	コールドスタート / IAM 実行ロール
API Gateway	Lambda への HTTP 入口	スロットリング / CORS 設定
DynamoDB	問い合わせ内容の保存先	パーティションキー設計 / オンデマンドモード
IAM	全サービスの権限制御	最小権限 / OIDC によるロール引き受け
Budgets	コスト上限の通知	個人開発の課金事故防止
Route 53	独自ドメインの DNS	A レコード（Alias）/ ホストゾーン
ACM	HTTPS 化（us-east-1 必須）	証明書の AWS リージョン制約

サイトを 作る側 にまわると、各サービスを単体の知識として覚えるのではなく、「組み合わせで動くインフラ」として理解できる。CLF-C02 の出題範囲はサービス単体の理解で足りるが、構築経験は試験本番の問題文を読むスピードに直結する。

Claude Code に、勉強パートナーになってもらった

Claude Code をコード生成ツールではなく 対話型の学習メンター として使うのが、CLF-C02 学習で一番効いた工夫だった。

具体的に頼んでいたタスクは大きく四つ。

1. 模擬試験の作成（Claude Code に問題そのものを生成してもらう）
2. 模擬試験の採点
3. 弱点分析（採点結果から領域別に薄いところを構造化してもらう）
4. 私が取っていたノートへのフィードバック（用語の使い方 / 抜けている論点の指摘）

なかでも一番効いた工夫は、私の正答率に合わせて Claude Code が難易度を調整してくれた ことだった。一回目は正答率 73.8%、二回目は 89.2% と伸びてきたところで、三回目は 63.08% まで一気に落ちて合格ラインを下回った。見た瞬間は正直、少し落ち込んだ。ただ、そこで外した問題群は 自分の学習の穴 をピンポイントで炙り出してくれていて、難易度調整の副次効果として弱点が可視化された。

そこから直前期にかけて、Claude Code が採点結果と外した問題からまとめてくれた 弱点ノート を、少しずつ読み返した。試験当日、テストセンターに向かう 本番前 30 分、その弱点ノートをざっと通しで読めたのが、実は一番助かった。

主張したい core はここだ。理解を深めたいなら、間違いなく自分で弱点ノートをまとめたほうがいい。手を動かして書くことで定着する量は多い。この事実は認める。ただし、試験対策の効率という一点でいえば、Claude Code に採点 → 弱点分析 → ノートまとめを任せてしまうやり方のほうが、少なくとも私にとっては効率的だった、と私は思う。

Claude Code の使い方深掘り

ここからは、Claude Code を 勉強パートナー として使ったときの実物を、入力（自分のノート）→ 出力（フィードバック / 弱点ノート）→ 発注プロンプト の順で見せる。読者が「この粒度でノートを渡して、この粒度で返してもらえばいい」まで再現できることを狙う。

1. 私が取っていたノート（Claude Code への入力）

Claude Code に「フィードバックして」と投げていたノートは、Markdown で書いた素朴なメモだ。特別なテンプレートは使っていない。以下にサンプルを 1 章分だけ、ざっくり動画でスクロールしながら見せる。

2. Claude Code から返ってきたノートフィードバック

ノートフィードバックのプロンプトは 1-2 行で十分だった。

以下は私が書いた IAM のノートだ。用語の使い方が間違っていないか / 抜けている論点はないか / CLF-C02 の試験観点で強化すべきポイントはどれか、を指摘してほしい

これを投げれば、Claude Code がノート原文の該当箇所を引用しながら「ここは用語が逆」「ここは Principal と Resource の違いに触れておくと安全」と返してくれる。プロンプト側は変数が少ないので、成果物のほうを見せておく。

3. Claude Code がまとめてくれた弱点ノート

弱点分析側のプロンプトも 1-2 行で十分だった。

上記の模試採点結果から、ドメイン別・トピック別に弱点を集計して、次に補強すべき順で並べてほしい

これを投げれば、Claude Code が採点データから領域分類・優先度付けをして返してくる。前述の通り、直前期の頭のリソース配分としてこの弱点ノートが実際いちばん効いた素材の 1 つだった。プロンプトそのものより成果物のほうが再現イメージが湧きやすいので、実際の出力を動画で見せる。

4. Claude Code に発注していた模擬試験作成プロンプト

模擬試験作成だけはプロンプトが構造化されている（フィードバックや弱点分析と違って、指示が多層になる）ので、実プロンプトの骨子を貼っておく。実際にはプロジェクト固有の CLAUDE.md にコンテキストを積んでいるので、ここに載せるのはコア部分だ。

私の場合は「弱点診断 → 模試生成 → 分離納品」の 3 段階に分けて Claude Code に投げていた。以下は実際に使っていた発注書の骨子（CLF-C02 向けに具体化してあるが、他資格でも枠だけ流用できるはず）。

弱点診断フェーズ（Phase A）:

以下のディレクトリの学習ノート + 既存の弱点メモを Read してほしい。

- 学習ノート ディレクトリ: {ノートの正本パス}
- 既存の弱点メモ: aws-clf-weak-points.md
- 直近の公式模擬試験 / Practice Exam の誤答集

Task:
1. 各章の理解度を「高 / 中 / 低」で推定する
2. 弱点章 Top 3 を抽出し、学習ノートから
   具体引用 1 件以上で必ず根拠付ける
3. 憶測での判定は禁止。引用がなければ「不明」と返す

模試生成フェーズ（Phase B）:

AWS CLF-C02 の本番形式（65 問 / 90 分）で模試を生成してほしい。

# 仕様
- 単一選択 (4 択) + 複数選択 (5 択 / 2-3 個選択) の混合
- 公式試験ドメイン配分:
  - Cloud Concepts: 24%
  - Security and Compliance: 30%
  - Cloud Technology and Services: 34%
  - Billing, Pricing, and Support: 12%

# 弱点配分カスタム
- Phase A で抽出された弱点 Top 3 章に +30〜50% 増配
- 配分変更の根拠を冒頭に 1 段落で明記

# 前回模試との重複回避（2 本目以降で必須）
- 直近の模試（問題ファイル + 弱点ノート）が既に存在する場合は、
  必ず Read してから生成に入る
- 同じ論点は「角度変更」を必須とし、シナリオ・選択肢・
  固有のキーワードが前回と一致しないようにする
- 各問に「前回シナリオ grep 0 ヒット」の自己保証を付記させる
- この一節がないと 2 本目以降で「見覚えのある問題」が混ざり、
  復習ではなく暗記のトレーニングになってしまう

# 解答・解説の付与
- 各問題に「解答 + 解説」（AWS 公式 docs / FAQ /
  Whitepaper / Well-Architected を出典として優先）
- 解説には「弱点章へのジャンプリスト」
  （学習ノート側の該当章）を含める

納品フェーズ（Phase C / 重要）:

問題ファイルと解答ファイルを分離して 2 ファイルで納品してほしい。

- 問題ファイル: 65 問の問題本文のみ (選択肢含む)
  / 解答・解説は含めない
- 解答ファイル: 採点シート + 全問題の解答 + 解説 + 出典
  + 弱点章ジャンプリンク

分離理由: 
- 「先に解答を見てしまう」事故を構造的に防ぐ
- iPad などの別端末で問題側だけ開いて解ける運用にする

3 段階に分けた理由は、Phase A（診断）を先に返してもらうことで、Phase B の弱点配分が私の実際の穴とズレていないかを目視で確認できるからだ。Claude Code の推定が明らかに違うときは、Phase B に進む前に「この章は診断より理解が浅いから配分を厚くして」と割り込めた。前回模試との重複回避 は 2 本目以降で必ず効くので、初回に走らせるときの発注書テンプレに最初から入れておくことをおすすめする。

使い方の勘所

四つのタスクを回してみて分かった勘所を、最後に短くまとめておく。

• 難易度調整は Claude Code に任せる: 自分で「難しい問題を作って」と細かく指示するより、直近の正答率を渡して「次はもう一段上げていい」と伝えるほうが、結果として意地悪な問題が返ってきた
• 採点は必ず理由付きで返してもらう: 「正解 / 不正解」だけでなく「なぜその選択肢が正解で、あなたが選んだ選択肢のどこが引っかけか」を出させる。ここが弱点分析の一次資料になる
• 弱点ノートは短く、直前用に: フルの解説を Claude Code に書かせると長くなりすぎる。「本番前 30 分で読み切れる量」を明示的に指定すると、必要十分な粒度に絞ってくれる
• 自分のノートを読ませるときは章単位で: 全部を一気に投げると指摘が薄くなる。IAM 章 / VPC 章 / 請求管理章、と単位を絞って複数回投げるほうが密度の高いフィードバックが返ってきた

まとめ

CLF-C02 の学習で見えたのは、教材リストを持つことと、教材の役割分担を設計として言語化することは別物 だ、ということだった。

同じ範囲を別の角度から複数回踏めるように教材を組み合わせ、自作の AWS 学習サイトを 作る側 にまわって各サービスの手触りを覚え、Claude Code に勉強パートナーになってもらって模試作成・採点・弱点分析・ノートフィードバックを任せる。資格を取ること以上に、この学習プロセスごと次の試験にコピーできる状態になったことが、長い目で見ると効いてきそうだと感じている。

次は AIF-C01（AWS AI Practitioner）を狙っていて、自作サイト aws-cert-roadmap-lab.com も AIF-C01 向けに Bedrock / SageMaker / Comprehend の比較ページや構成図を拡張していく予定だ。CLF と AIF を両方扱うサイトに育っていく過程を、同じ試験を狙う人が横で眺められる形にしておく。

よくある質問

Q: AWS 未経験のインフラ経験者がまず固めるサービスは？

A: 私の場合は IAM と VPC を最優先にした。オンプレのネットワーク・権限管理の感覚があると、IAM のロール / ポリシーと VPC のサブネット設計は「既知の語彙への翻訳」として入る。ここを固めてから S3 / EC2 / Lambda 等のサービスに進むと、認可と疎通の地図ができている状態で各サービスを覚えられる。

Q: Ping-t と AWS Skill Builder はどちらを優先すべきですか？

A: 役割が違うので併用が前提。Ping-t は約 500 問の演習量と誤答パターン蓄積に効き、Skill Builder の無料コンテンツは AWS 公式の用語定義・サービス分類のリファレンスとして効く。CLF-C02 向けには Skill Builder Enhanced（有料の Individual Subscription）を契約しなくても、無料コンテンツ + Ping-t で演習量は確保できる（有料プラン価格は公式ページ参照）。

Q: 自作の AWS 学習サイトを構築する過程で得られるメリットは何ですか？

A: 各 AWS サービスの単体知識ではなく、「組み合わせで動くインフラ」として理解できるようになる。S3 + CloudFront + Lambda + API Gateway + DynamoDB の 5 サービス構成だけでも学習サイトとして公開できるレベルのポートフォリオが作れるので、資格学習とポートフォリオ整備が同じ作業になる。教科書で読むだけより、設定で詰まった経験のほうが定着率が高い。

Q: AWS CLF-C02 と SAA で、自作サイトの構成は使い回せますか？

A: 使い回せる。私の自作サイトは S3 + CloudFront + Lambda + API Gateway + DynamoDB + IAM + Budgets + Route 53 + ACM + GitHub Actions OIDC の構成で、CLF-C02 の出題範囲をほぼ網羅しつつ、SAA の試験範囲（IAM・短期トークン・最小権限・OAC・us-east-1 制約など）にも自然に踏み込める。CLF と SAA の差は「主要サービスを知っている」レベルから「設計判断ができる」レベルへの深化で、同じ構成のままパーティションキー設計や Lambda の並列処理の検討を足していけば SAA 学習にもそのまま使える。

Q: Claude Code を勉強パートナーとして使うとき、どんな頼み方が効きますか？

A: 「模擬試験を作る / 採点する / 弱点分析する / 自分のノートにフィードバックをもらう」の四つが効いた。特に、正答率を渡して難易度を調整してもらう頼み方だと、簡単すぎず難しすぎない試験を作ってくれる。難しめの回で崩したときは落ち込むが、そこで見えた弱点を「本番前 30 分で読み切れる量」で短くまとめてもらえると、直前の頭のリソース配分としてかなり効率がいい。

参考リンク

• AWS Certified Cloud Practitioner 公式ページ
• AWS CLF-C02 試験ガイド（日本語 PDF）
• AWS Skill Builder
• Ping-t
• 自作 AWS 学習サイト: aws-cert-roadmap-lab.com
• GitHub: vincentmango-wen/aws-cert-roadmap-lab

参考書籍

本記事で言及した書籍は以下の通り。

• 川畑光平 / 菊地貴彰 / 真中俊輝『AWSの基本・仕組み・重要用語が全部わかる教科書』（SBクリエイティブ / 526p）— AWS サービス個体を体系的に扱う教科書。CLF-C02 全範囲を 1 冊で広く押さえるのに向く
• 大澤文孝『AWSネットワーク入門 第2版』（インプレス）— AWS 上のネットワークを体系的に説明する補強本。VPC / サブネット / ルーティング / Route 53 章のカバレッジを厚くしたい場合に