AWS資格の勉強だけではもったいないので、ChatGPTをシニアエンジニアにして学習サイトをAWS上に構築してみた
AWS の Cloud Practitioner（CLF-C02）を勉強していて、二つの不満があった。暗記中心だと数週間で忘れること、そして面接で「触りました」と言えても見せられる成果物がないこと。そこで、AWS の学習内容そのものを Web サービスにして AWS 上に公開した。それが AWS Cert Roadmap Lab（GitHub: vincentmango-wen/aws-cert-roadmap-lab）である。この記事で一番伝えたいのは、ChatGPT に「コードを書かせた」のではなく「テックリードをやらせた」という使い方だ。
はじめに — 勉強したものが残らない問題
AWS 資格の勉強は、Amazon Skill Builder の動画を見て、問題集を解いて、模試を回す、という流れになりがちだ。私もその流れで進めていた。ただ、Domain ごとに用語を覚えても、手を動かしていないサービスは「名前は知っているが何ができるか説明できない」状態のまま頭から抜けていく。
もう一つ困ったのは、ポートフォリオがないことだった。SES でインフラ運用をやっているが、「AWS を勉強しています」と「AWS でサービスを設計・実装・公開しました」は、面接で出せる重みがまったく違う。前者は意欲、後者は実績だ。
この二つを一度に解決する方法として、AWS の学習で覚えるサービスを実際に使って、AWS 学習サイトそのものを AWS 上に公開することにした。覚えるべきサービス（S3・CloudFront・Lambda・API Gateway・DynamoDB・IAM・Budgets）を、学習サイトの構成要素としてそのまま組み込めば、勉強と実装が一本につながる。
作ったもの: AWS Cert Roadmap Lab
作ったのは、AWS 学習者向けの情報サイトだ。AWS の用語集、問題演習、サービス比較記事、構成図、学習ブログをまとめている。コンセプトは「AWS の学習内容をサイト化して、実装経験に変える」こと。
- 本番 URL: https://www.aws-cert-roadmap-lab.com （独自ドメイン稼働中）
- GitHub: https://github.com/vincentmango-wen/aws-cert-roadmap-lab
- フロントエンド: Next.js（静的エクスポート）+ TypeScript + Tailwind CSS v4
- バックエンド: Python の AWS Lambda
- 使用 AWS サービス: S3・CloudFront・API Gateway・Lambda・DynamoDB・IAM・Budgets の 7 つ
初心者向けの AWS ポートフォリオとして見ると、この構成は再現しやすい部類だと思う。サーバーレス 3 点セット（Lambda・API Gateway・DynamoDB）に静的ホスティング（S3・CloudFront）を足しただけで、特殊なサービスは使っていない。CLF と SAA の学習範囲にきれいに収まる構成にしてある。
実際に使ってみて一番気に入っているのは AWS 構成図 のページだ。「何をどう組むか」を図で並べると視覚的・直感的に全体像が頭に入りやすく、自分で構成図を作る過程がそのまま SAA（Solutions Architect Associate）の予習にもなる。試験勉強で一番見返しているのが、自分で作ったこの構成図ページだった ── というのは、サイトを公開してから気付いた副産物だ。
なぜ作ろうと思ったのか
きっかけは、問題集を 2 周目に入ったときの違和感だった。1 周目で「分かった」と思った S3 のストレージクラスやライフサイクルの話を、2 周目で同じように間違えた。動画と問題集だけでは、知識が「読んだことがある」止まりで、自分の手の感覚になっていなかった。
私はもともと、座学より手を動かす方が定着するタイプだ。SES の現場でも、ドキュメントを読むより一度設定を壊して直す方が早く覚える。だから AWS も、覚えるサービスを実際に組み合わせて動くものを作れば、忘れにくくなるはずだと考えた。
加えて、面接で話せる成果物が欲しかった。「勉強しました」では弱い。「このサービスを S3 + CloudFront で配信して、問い合わせ機能を Lambda + DynamoDB で作りました」と URL を見せながら話せる状態を、資格取得と同時に手に入れたかった。
決め手になったのは、自分のキャリアを少し引いた目線で考えてみた瞬間だった。仮に CLF や SAA を取れたとして、実務経験ゼロの状態で「AWS できます」と自信を持って言えるだろうか、と問い直したら、やっぱり手を動かして成果物を一つ残すほうが圧倒的に説得力があると思った。
「じゃあ、何を作るか」と ChatGPT に相談したとき、提案された中で一つだけ光ったのが、この AWS 学習サイトのアイデアだった。学習しながらのアウトプットにもなり、ポートフォリオにもなる ── これなら一石二鳥だ、と思った瞬間に、その場で即決していた。
ChatGPT をシニアエンジニアとして使った
ここがこの記事の核心だ。誤解のないように書いておくと、コードの生成自体は ChatGPT にやってもらっているし、出てきたコードを貼り付けて動かすこともある。違うのは、生成されたコードを「なぜそう設計するのか」まで説明してもらい、ジュニアの自分が理解してから次へ進むようにした点だ。やらせたのは、コードを書く作業そのものではなく、テックリードの仕事だ。
最近よく見る「AI に作ってもらった」系の開発記事は、プロンプトを投げてコードを生成させ、貼り付けて動けば終わり、という流れが多い。私がやりたかったのは、そこからもう一歩踏み込むことだった。自分が成長するために、どう設計し、なぜそう書くのかを「教えてもらいながら」進める伴走の形にしたかった。生成されたコードをただ貼り付けるだけだと、動くものはできても、自分の中には何も残らない。それでは資格勉強と同じで「読んだことがある」止まりになる。
だから ChatGPT には、シニアエンジニア（テックリード）の役割を背負ってもらった。具体的には、次の設計フェーズを一緒に進めた。
- 要件定義（誰の何を解決するサイトか）
- 基本設計（画面構成・機能一覧）
- API 設計（問い合わせエンドポイントの入出力）
- データ設計（DynamoDB のテーブル設計）
- AWS 設計（どのサービスをどう組むか）
- WBS（実装タスクの分解と順序）
プロジェクトのカスタマイズ指示プロンプトの一部。
ChatGPT が出してくるのは「設計の選択肢」と「その理由」だ。それに対して、採用するかどうかを判断し、実際に手を動かして実装したのは私自身だ。たとえば DynamoDB のパーティションキー設計で複数案が出てきたとき、自分のアクセスパターンに照らしてどれを採るか決めたのは私だった。設計書ができたら、そこから先のコードは自分で書いた。分からないところは「なぜこの設計なのか」を質問して、納得してから実装に移した。
この使い方の良いところは、AI を「答えを吐く機械」ではなく「設計判断を一緒に考えて、自分のスキルを引き上げてくれるテックリード」として扱える点だ。ジュニアエンジニアに丸投げするより、シニアエンジニアに壁打ちしてもらう方が、自分の理解が深くなる。ChatGPT はその「シニアの壁打ち相手」として機能した。
この「シニアの壁打ち」を安定させるために、ChatGPT のプロジェクト機能にカスタム指示を設定した。「あなたは設計書を根拠にユーザーを導くテックリードで、ユーザーはジュニアエンジニア」と役割を固定したうえで、回答に必ず以下のセットを含めるよう指定した。
- 実装手順・コードと「なぜその設計なのか」の理由
- 初心者が間違えやすい点
- CLF / SAA の試験観点とのつながり
- 「適切に」「いい感じに」「よしなに」のような曖昧語の禁止と、判断ごとの具体的な基準
この指示を一度作っておくと、一つ実装するごとに「動くコード」と「なぜその設計なのか」と「どの試験範囲とつながるか」が同時に積み上がる。コードだけもらって終わり、にならない仕組みを先に用意したわけだ。
実際の出力例。コードの説明、AWS 用語の解説、GitHub の管理操作まで構造化されている。
設計のレベルでは、ChatGPT の提案を「丸ごと却下」したものは実はほとんどない。要件定義から API 設計・データ設計までは、ジュニアの自分が「なるほどそうなるのか」と納得しながら順番に採用していった。違ったのはコードのレベルだ。修正コードを出してもらうと、前のセクションで組み込んだ関数を import し忘れている、というような typecheck エラーがちらほら起きる。だからコード提案には必ず軽く目を通し、おかしいと感じたら現状のソースコード全体を渡して「これに合わせて出し直して」と再確認させる、という一手間を毎回はさむようにした。設計判断ではテックリードとして信頼し、実装出力では先輩エンジニアのレビュー目線で受け取り直す。この使い分けが、丸投げにならない境界線となっている。
一方、「提案をそのまま採用して助かった」代表例は GitHub Actions OIDC で長期アクセスキーを持たない構成 だ。長期キーを GitHub Secrets に保存する従来のやり方ではなく、IAM ロールを引き受ける形にする提案が、設計の流れの中で自然に出てきた。これは SAA の試験範囲（IAM・短期トークン・最小権限）とも直接重なっていて、サイトのセキュリティを上げながら、そのまま試験対策にもなるという一石二鳥の選択になった。
AWS 構成 — サーバーレスで組んだ
サイトの構成は、大きく二つのレイヤーに分かれている。フロントエンドの配信レイヤーと、API 処理のレイヤーだ。
フロントエンド（Next.js の静的エクスポート）は S3 に置き、CloudFront を CDN として前段に立てて配信している。問い合わせ機能だけは動的処理が必要なので、API Gateway → Lambda（Python）→ DynamoDB という流れで実装した。MVP（最小構成）の段階では、サイト本体は静的サイト、サーバーが必要な処理は問い合わせのみ、という割り切りにしている。
なぜ EC2 を使わなかったのか
AWS 構成を考えるときに、EC2 と RDS を使う選択肢もあった。あえて使わなかった理由は三つある。
まず、コストだ。EC2 は起動している間ずっと課金される。個人開発のポートフォリオで 24 時間サーバーを立てておくのは、アクセスがほぼ無い段階では割に合わない。Lambda なら「リクエストが来たときだけ実行・課金」なので、動いていない時間にお金がかからない。
次に、運用コストだ。EC2 を使うと、OS のパッチ当て、ミドルウェアの管理、スケーリングの設定まで自分で見ることになる。サーバーレスにすれば、そのあたりは AWS 側が見てくれる。学習サイトを作るのが目的であって、サーバー運用そのものは今回の目的ではなかった。
最後に、学習目的との一致だ。CLF と SAA の学習範囲には S3・Lambda・API Gateway・DynamoDB がしっかり含まれている。これらを実際に組み合わせることが、資格の勉強と直結する。EC2・RDS は今回の MVP の対象外と決めた。
AWS 資格学習との対応表
このサイトで一番効いたのは、勉強で覚えたサービスが、サイトのどの部品に対応しているかが一目で分かることだった。試験で「S3 はオブジェクトストレージ」と覚えた知識が、実際に静的ファイルを置いて CloudFront で配信する実装で、感覚として定着した。
| サービス | サイトでの用途 | 主に学べる試験 |
|---|---|---|
| S3 | 静的サイトのファイル保存・ホスティング | CLF |
| CloudFront | CDN（配信・キャッシュ） | CLF / SAA |
| Lambda | 問い合わせ API の処理（Python） | SAA |
| API Gateway | API の公開エンドポイント | SAA |
| DynamoDB | 問い合わせデータの保存 | SAA |
| IAM | 各サービスの権限制御 | CLF / SAA |
| Budgets | 課金監視・上限アラート | CLF |
※ この対応表は私自身の学習体験に基づく主観的なマッピングだ。各サービスがどの試験で何問出るかは AWS 公式の試験ガイドが正確なので、レベル感の参考として見てほしい。
CLF の知識で全体像（どのサービスが何をするか）を把握し、SAA の知識で詳細設計（Lambda の処理・API Gateway の使い方・DynamoDB のテーブル設計）を詰める。この二段構えが、サイト構築でそのまま使えた。
苦労したポイント
順調に進んだわけではない。資格の参考書には載っていない、実装ならではのハマりどころがいくつかあった。
ACM の証明書は us-east-1 でしか発行できない
独自ドメインで HTTPS 配信するには、ACM（AWS Certificate Manager）で SSL 証明書を発行して CloudFront に紐付ける必要がある。ここで落とし穴がある。CloudFront 用の証明書は、必ず us-east-1（バージニア北部）リージョンで発行しないと紐付けられない。
東京リージョン（ap-northeast-1）で発行した証明書は、CloudFront のディストリビューションに設定しようとしても候補に出てこない。AWS 公式ドキュメントにも「To use a certificate in ACM to require HTTPS between viewers and CloudFront, make sure you request (or import) the certificate in the US East (N. Virginia) Region (us-east-1).」と明記されている。知っていれば一瞬だが、知らないと「証明書は作ったのに CloudFront で選べない」で時間を溶かす。
S3 を公開しないための OAC
S3 で静的サイトをホスティングするとき、バケットを「パブリックアクセス可能」にする方法が手軽だが、セキュリティ的には避けたい。私は OAC（Origin Access Control） を使って、S3 バケットは非公開のまま、CloudFront 経由でのみアクセスできる構成にした。
OAC は、以前使われていた OAI（Origin Access Identity）の後継で、AWS 公式ドキュメントでも「recommended」とされている方式だ。バケットポリシーで CloudFront のサービスプリンシパルからのアクセスだけを許可することで、S3 の URL を直接叩かれても見えないようにできる。
GitHub Actions の OIDC で長期アクセスキーを持たない
デプロイは GitHub Actions で自動化した。ここで使ったのが OIDC（OpenID Connect） だ。
従来のやり方だと、AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY を GitHub Secrets に保存して使う。ただ、この長期アクセスキーは漏洩すると被害が大きい。OIDC を使うと、GitHub Actions が実行のたびに短期トークンを取得して AWS に認証するので、長期的なアクセスキーを保存する必要がなくなる。
設定としては、ワークフローに permissions: id-token: write を付け、aws-actions/configure-aws-credentials で IAM ロールを引き受ける形にする。GitHub 公式ドキュメントでも、AWS 認証情報を長期的なシークレットとして保存する必要がなくなる方式として案内されている。
私の場合、「ハマった」というより「これで合っているのか、ちょっと不安になった」のが、まさにこの ACM のリージョン問題だった。設計の段階では東京リージョン中心でサービスを並べていたところに、ACM だけ us-east-1 で作るという指示が出てきたので、「CloudFront 側の設定と矛盾しないのか？」と引っかかった。
こういう「手順は分かったけれど、念のため確認したい」という小さな質問のときに重宝したのが、ChatGPT の 会話の分岐機能 だった。本流のスレッドを汚さずに、横道で「CloudFront はグローバルサービスだから us-east-1 の証明書で問題ないんだっけ？」と聞いて、納得してから本流に戻れる。Claude Code の /btw スキル（メインの作業を中断せず横道質問するための仕組み）と似た役割で、設計書ベースで会話を積み上げているときの不安コストをかなり下げてくれた。結局この戸惑いは 約 30 分 で解けて、本流の手順に戻れている。
実際に得られた学び
サイトを一通り作って、AWS の参考書を読んでいるだけでは気づけなかったことがいくつかあった。箇条書きで整理する。
- AWS は触らないと覚えない。 問題集で覚えた知識は、実際にコンソールやコードで操作して初めて「自分の感覚」になる。S3 にファイルを置いて CloudFront で配信する一連を手でやると、用語が一気に立体的になった。
- IAM が一番重要で、一番つまずく。 どのサービスを使うにも権限設計がついて回る。Lambda が DynamoDB に書き込む、CloudFront が S3 を読む、GitHub Actions が AWS にデプロイする。すべて IAM の許可がいる。「最小権限」を実感したのは、参考書ではなくエラーログだった。
- CloudFront は思ったより奥が深い。 キャッシュの挙動、OAC の設定、ACM の紐付け、独自ドメインの設定。CLF では概要しか出ないが、実際に組むと SAA レベルの判断が必要になる場面が多い。
- AI 時代は、コードを書く力より設計を判断する力が価値になる。 ChatGPT が設計案を出せる以上、差がつくのは「どの案を採るか」を判断できるかどうかだ。資格の知識は、その判断の土台になる。
- ChatGPT はジュニアより、テックリードに向いている。 コードを書かせるより、設計の選択肢と理由を出させて自分が判断する方が、学びも質も高くなった。実感したのは DynamoDB のパーティションキー設計で複数案が出てきたときで、ChatGPT に最終決定を委ねるより、自分のアクセスパターンに照らして採否を決めることで、設計判断の感覚が手に残った。
次にやること
公開してしばらく運用していて、想定外のことが起きた。Google Analytics を入れてアクセスを見たら、海外からのアクセスが思ったより多かったのだ。最初は日本語で日本の AWS 学習者向けに作ったつもりだったが、データを見ると違う層が来ていた。
これを見て、なんとなくではなく根拠を持って、ローカライゼーション（英語・中国語対応）に踏み切ると決めた。/en /zh のような URL 構造で多言語化し、グローバル向けの SEO も整えていく。データを見て意思決定する、というのを自分のサイトで実践できたのは、副産物として一番大きかったかもしれない。
このあたりは現在進行中で、ほかにも検討しているものがある。
- 認証機能（Cognito）の追加
- 学習履歴の保存
- 収益化の検討
ただし、これらは「やる」と確定したものではなく、運用しながら優先度を見て判断していくつもりだ。
まとめ
AWS 資格を勉強しているなら、問題集をもう 1 周増やすより、小さくても AWS 上で何かを公開した方が、学びは大きいと感じている。私の場合、その公開物が AWS 学習サイトだった。覚えるべきサービスを使ってサイトを作れば、勉強と実装が一本につながり、面接で見せられる成果物も同時に手に入る。
そして、その設計・実装・AWS 構築の相棒として、ChatGPT をシニアエンジニア役にした。コードを書かせるのではなく、設計を一緒に考えてもらう。判断と実装は自分でやる。この役割分担にしたことで、出来上がったサイトだけでなく、自分の中に設計の判断軸が残った。
CLF-C02 の勉強で「覚えたのにすぐ忘れる」に悩んでいる人がいたら、覚えたサービスを 1 つでも実際に動かしてみることを試してほしい。その小さな実装が、次の問題集 1 周より効くかもしれない。
よくある質問（FAQ）
Q. AWS 学習サイトの月額コストはいくらですか？
S3 + CloudFront + Lambda + API Gateway + DynamoDB の構成で、アクセスが少ない段階では月額ほぼ 0 円（無料枠の範囲内）に収まる。AWS Budgets で上限アラートを設定しておくと、予期せぬ課金を早く検知できる。
私の場合、ここ数ヶ月の請求は 月数十円〜100 円程度 に収まっている。アクセス規模が小さいうちは S3 / CloudFront / Lambda / API Gateway / DynamoDB が無料枠内で、固定で発生しているのは独自ドメイン用の Route 53 ホストゾーン代（USD 0.50 / 月 ≒ 75 円前後、為替で変動）がほとんどだ。Budgets でしきい値アラートを設定しておけば、無料枠を超えた瞬間に気付ける運用にできるので、最初に必ず仕込んでおくのをおすすめする。
Q. AWS Cloud Practitioner（CLF）と Solutions Architect Associate（SAA）の違いは、実装面でどう現れますか？
CLF は「AWS の主要サービスを知っている」レベルで、S3・CloudFront・IAM・Budgets などの全体像を押さえる。SAA はより深い設計判断が求められ、Lambda の処理設計・API Gateway の使い方・DynamoDB のテーブル設計などを扱う。私のサイトでは、CLF の知識で全体像を把握し、SAA の知識で詳細設計を詰める、という使い分けになった。
Q. ChatGPT（AI）はどのように使いましたか？
コードの生成ではなく、要件定義・基本設計・API 設計・データ設計・AWS 設計・WBS の作成に使った。AI をテックリードとして機能させ、設計の選択肢と理由を出してもらい、採用判断と実装は自分で行った。
Q. なぜ EC2 を使わなかったのですか？
EC2 は 24 時間稼働で固定費がかかる。個人開発のポートフォリオでは、Lambda などのサーバーレス構成の方が「使った分だけ課金」となりコスト効率が良い。加えて S3・Lambda・API Gateway は CLF / SAA の学習範囲に含まれるため、学習目的とも一致した。