自分用のAWSの資格試験のWeb問題集をClaude Codeで作る
Posted On 2026-06-21
いつもの問題演習サイトが使えなくなったので、Claude Codeで自分専用のAWS資格試験Web問題集を作ってみました。試験ガイドと公式ドキュメント、AWS Knowledge MCP Serverだけで問題生成からデプロイ、複数デバイス同期までできてしまったので、その流れとハマりどころをまとめます。
目次
はじめに
いつも使っている怪しい某サイトが有料会員新規登録停止していたので、自分用のAWSの資格試験の問題集をClaude Codeで作ってみたら普通にできて「もうこれでいいんじゃね？」ってなったので記事にしてみた。
事前準備
- AWSの試験ガイド
- 自分はGenerative AI Developer Professionalだったのでこれ。PDFの場合はローカルファイル直おきかも
- Claude Code
- Opus 4.8 (1M Context)を使用。Codexでもいけるはず
- AWS Knowledge MCP Server
- AWSの公式ドキュメントを引くために使う
やりかた
Claude Codeで以下のように入力（※具体名はマスク）
ク██ウ████イ██ン██みたいなAWSの資格試験の問題演習ができるサイトを作りたいです
対象資格はAWS Certified Generative AI Developer - Professionalで、試験ガイドは以下にあります。
試験の難易度的には、Solution Architect ProfessionalやDevOps Professionalぐらいです。
https://docs.aws.amazon.com/ja_jp/aws-certification/latest/ai-professional-01/ai-professional-01.html
ク██ウ████イ██ン██では、7問ごとに1セットとして、クリック形式でブラウザ上からできる、問題演習を進めていきます
間違った問題を自動的に記憶して再履修できる機能、マーキングしてその問題だけをやる機能があります
問題は試験ガイドをベースに500問程度作成したいです。
試験問題作成の際には、AWS MCPを活用して公式ドキュメントを読み、回答、解説をつけるようにしてください。
こんな感じに進んでいく。
● 試験ガイド全5ドメインの詳細を把握しました。アーキテクチャを決めて進めます。
設計方針:
- 静的サイト（HTML/CSS/JS）。バックエンド不要、ブラウザで直接動作。localStorageで誤答記憶・マーキングを永続化
- 7問1セットのクリック演習、即時採点＋解説、誤答の自動再履修、マーキング演習
- 問題は試験ガイドの全タスク/スキルをベースに、AWS公式ドキュメントをMCPで参照しながら作成（重み配分: D1=155, D2=130,
D3=100, D4=60, D5=55 ≈ 500問）
まずタスクを登録し、アプリの土台を作ります。
● 全ドメインの詳細が揃ったので、問題生成のサブエージェント（長時間タスク）を先にバックグラウンドで起動し、その間にアプリ
本体を構築します。各エージェントは重複しないスキル範囲とID接頭辞を担当し、AWS公式ドキュメントをMCPで参照しながら生成・
ファイル出力します。
Domain 1（155問）の5エージェントを起動します。
サブエージェントを起動して、裏でMCPを呼んで問題を作成するらしい。1エージェントあたり5万トークンぐらい使うので、ここだけ一番下のプランだと引っかかるかもしれない。
20分ぐらいでローカル動作するものが出てくる。
● 完成しました。ク██ウ████イ██ン██風のAWS Certified Generative AI Developer - Professional
問題演習サイトが動作しています。
成果物
ローカルサーバー稼働中 → ブラウザで http://localhost:8000 を開けば演習できます（index.html を直接開いてもOK）。
AWSにデプロイする
ただ、これだとローカルでのみ動作で、そもそもタブレットからは動作しない。欲を言えば、PCの勉強状況をタブレットで同期することができれば、タブレットから寝っ転がって問題ポチポチできるので楽（このUXがあのサイトの売りだったので）。
ブラウザで表示できました。ユーザーは私しか使いませんが、複数デバイスで表示したときに進捗や間違い情報が同期されるように永続化したいです。AWSにデプロイしようかと思っています。個人用なので、コストは最小限の構成で良いですが、インターネットに向けて公開したときに認証（ベーシック認証でいい）は入れようと思います。どういう構成が良さそうですか？
とアーキテクチャを問い合わせる。まあCloudFront++S3あたりで攻めるんだろうなと思ったら、だいたい思った通りのが出てきた。
● デプロイ構成について、個人利用・最小コスト・複数デバイス同期・ベーシック認証を満たす推奨案をまとめます。
推奨構成（フルサーバーレス・実質無料）
┌─────────────────────────────────────┐
ブラウザ ──HTTPS──▶│ CloudFront ディストリ │
(PC / スマホ等) │ + CloudFront Function (Basic認証) │
│ ・viewer-request で Authorization │
│ ヘッダを検証（全パス保護） │
└───────┬───────────────────┬───────────┘
│ デフォルト │ /api/*
▼ ▼
┌──────────────┐ ┌──────────────────┐
│ S3 (非公開) │ │ Lambda Function │
│ 静的サイト │ │ URL (or API GW) │
│ OACで限定 │ │ GET/PUT /state │
└──────────────┘ └────────┬──────────┘
▼
┌──────────────────┐
│ DynamoDB (1テーブル)│
│ PK=userId 固定値 │
│ data=状態JSON │
└──────────────────┘
各コンポーネントの役割
┌────────────────────────┬───────────────────────────────────────────────────────────────┬────────────────────────┐
│ 要素 │ 用途 │ コスト │
├────────────────────────┼───────────────────────────────────────────────────────────────┼────────────────────────┤
│ S3（非公開＋OAC） │ index.html/css/js/data を配信。CloudFront経由のみ許可 │ ほぼ$0 │
├────────────────────────┼───────────────────────────────────────────────────────────────┼────────────────────────┤
│ CloudFront │ HTTPS配信・キャッシュ。/api/*だけ別オリジンへ │ 永久無料枠(1TB/月)内で │
│ │ │ $0 │
├────────────────────────┼───────────────────────────────────────────────────────────────┼────────────────────────┤
│ CloudFront Function │ viewer-requestでベーシック認証を実装（全リクエストをHTTPS上で │ 無料枠内 │
│ │ 検証） │ │
├────────────────────────┼───────────────────────────────────────────────────────────────┼────────────────────────┤
│ Lambda Function URL │ GET /api/state（読込）/PUT /api/state（保存）の2操作だけ │ 無料枠内 │
├────────────────────────┼───────────────────────────────────────────────────────────────┼────────────────────────┤
│ DynamoDB（オンデマンド │ userId="me"の1アイテムに状態JSONを保存。last-write-wins + │ 無料枠内 │
│ ） │ updatedAt │ │
└────────────────────────┴───────────────────────────────────────────────────────────────┴────────────────────────┘
→ 個人利用なら 実質 月$0〜数セント。カスタムドメインを使わなければ Route53 料金も不要（xxxxx.cloudfront.net を利用）。
ポイント
- 静的サイトとAPIを同一CloudFrontディストリの2オリジンにまとめると、(1)同一オリジンでCORS不要、(2)ベーシック認証が静的
・API両方に一括で効く、というメリットがあります。
- 認証は「HTTPS上のベーシック認証」で、個人用ゲートとしては十分。資格情報はリポジトリにコミットせず、CloudFront
Functionのコードに（デプロイ時に注入）持たせます。
- API Gatewayではなく Lambda Function URL にするとAPI Gateway分のコスト・構成を省けます（操作が2つだけなので十分）。
アプリ側の改修（小規模）
- 起動時に GET /api/state → リモート状態を取得し、ローカル(localStorage)とマージ
- 解答/マーク時に変更を デバウンスして PUT /api/state（localStorageは即時＝オフラインキャッシュとして維持）
- 同期競合は「問題ごとに seen が多い/新しい方を採用」する軽いマージで、デバイス切替時のデータ消失を防止
できたもの
こんな感じのアプリになる。タブレットでも状態同期できたのが一番嬉しかった。
開くと択一の問題が出てくる。複数選択肢の問題出てくる。最近のAIFとかで入った順番当て形式とかは対応してないけどまあいいんじゃね感。
即時に正答が表示され、回答解説も出てくる。ドキュメントのMCPから引いているので、関連するAWSドキュメントまで出しているのが実践的で良い（ここらへんは明示しなくてもClaude Code側でやってくれた）
最終的なアーキテクチャ
ブラウザ ──HTTPS──▶ CloudFront ─┬─ (既定) S3(非公開, OAC) … 静的サイト
(Basic認証) └─ /api/* Lambda Function URL(OAC) ─ DynamoDB … 状態同期
※認証は CloudFront Function(viewer-request)で全パスに適用
※API は Function URL を AWS_IAM 化し、CloudFront OAC の SigV4 署名でのみ呼び出し可（完全非公開）
※PUT 時はブラウザがボディの SHA256 を x-amz-content-sha256 で付与（OAC+Lambda の要件）
ハマりどころ（複数デバイスでの状態同期について）
最初のローカル動作のモックまでが30分ぐらい、デプロイまでが1時間ぐらいだったが、複数デバイスで状態を同期するというところがハマる。
APIが全て Forbidden（保存も読込も不可）
- 原因: 2025年10月以降、Lambda Function URL の呼び出しには
lambda:InvokeFunctionUrlとlambda:InvokeFunctionの両方の権限が必須になっていた。Terraformで前者しか付与していなかった。 - 対策:
lambda:InvokeFunction権限を追加（あわせて Function URL を AWS_IAM＋CloudFront OAC にして完全非公開化）。
PUT（保存）だけ署名エラー
- 原因: CloudFront OAC + Lambda では、PUT/POST のボディの SHA256 をクライアントが
x-amz-content-sha256ヘッダーで送る必要がある（Lambda は unsigned payload 非対応）。送っていなかったため署名不一致。 - 対策: ブラウザ側で送信ボディの SHA256 を計算し、
x-amz-content-sha256を付けて PUT するように修正。
「最初は同期、以降は反映されない」
- 原因: アプリが起動時に1回しかリモートを取得していなかった（ポーリング無し）。キャッシュのせいではなく設計上の制限。
- 対策: 開いている間 45秒ごとのポーリング＋タブ復帰時の再取得を追加。更新検知はサーバーの
version（単調増加）で行い、時計ずれに強く・自分の更新では再描画しないようにした。
補足
- 修正後に反映されなかったのは、ブラウザ／CloudFront が古い
app.jsをキャッシュしていたため。ハードリロード＋CloudFront無効化で解消。 - 途中「組織ガードレールでは」と推測しましたが誤りで、実際は①の権限不足でした（公式ドキュメントで確定）。
要するに「権限不足（②の前提が崩れていた）＋ PUTのボディ署名漏れ ＋ ライブ取得の仕組み欠如」の3点が重なっていた、というのが真相です。
シャッフル機能の必要性について
LLMに問題を作らせると、97%が正解A/Bという強い偏りが発生するため、だんだんAかBを選んでおけばいいんじゃね？ってなる。そのためシャッフル機能が必須。ここは最初の要件に入れてなかったため、データ構造や解説シャッフル前提で作らせると良いかもしれない。
この方法のメリット・デメリット
メリット
- 試験対策として何ら違法なやり方ではないこと
- どこから取ってきたかあわらない怪しい系のサイトとは異なり、試験ガイドとClaude Codeと公式MCPしか使っていないため、試験ガイド的には100％合法なやり方。
- 怪しい系とは言ってもガッツリコピーサイトにしてサービス提供とかすると別の問題が発生するため、それは一応注意が必要。
- 対象資格がニッチで、問題サイトがない場合でも、ドキュメントMCPや最悪公式ドキュメントがサイトを作れること。
- デプロイしてもほとんどコストはかからないこと。
デメリット
- LLMの作った問題がどこまで実際の試験で有用かが不明
- 試験ガイドやサンプル問題を少し与えておくと精度が上がりそう。これの覚えゲーで突破できるかというと、やや確信度は下がりそう
- ドキュメントをソースとした関係で、単発の要素を聞いてくる問題が多いこと。Professionalってもっと複合的な問題が多かったので、難易度的なドリフトがありそう。
- プロンプトでDOPやSAPを明示しておいたので、多少そこらへん吸収されるかなと思ったが、解いてた感じだと「これアソシエイトレベルじゃね？」感はあった。
- そのへん気にするなら多少フォローアップ入れるか、難易度別に問題作らせるかとかも有り得そう。
Shikoan's ML Blogの中の人が運営しているサークル「じゅ～しぃ～すくりぷと」の本のご案内
技術書コーナー
北海道の駅巡りコーナー