
Claude で自分専用の資格学習サイトを育てた話📖
AWS Certified Generative AI Developer - Professional(AIP-C01) を受けると決めたとき、2026 年 3 月に正式版の受付が始まったばかりの試験で解説つきの日本語教材はまだ少なく、英語の資料を読みながら勉強することになりそうでした。そこで、試験ガイドやドキュメントを Claude に読ませて日本語の解説と図表を書かせ、自分専用の学習サイトをローカルに育てました。Google Cloud Professional Cloud Architect も同じ仕組みに載せています。
答えが会話の中に流れて消えていた
分からない論点は、それまでも AI に画面を貼って質問していました。参考になる技術記事や公式ドキュメントのリンクを教えてもらえるので、その場では解決します。ただし答えは会話の中に流れて消えます。次に同じ論点でつまずくと、また同じことを聞くことになります。
ほしかったのは、Claude に質問しながら自分の理解をまとめて残す場所でした。2 回目に聞かなくていい状態を作りたかった、というのが動機です。もう 1 つ正直な理由もあって、Claude は個人で契約しているので、週の上限まで使い倒してみたいと思っていました。
英語の資料を Claude に読ませて、日本語の解説にする
読ませたのは主に、出題範囲が載っている試験ガイド(AWS は試験ガイド(AIP-C01)、Google Cloud は試験ガイド(Professional Cloud Architect))、各認定ページから案内されている練習問題、そしてサービスの公式ドキュメントです。ドキュメントは英語版を使いました。AWS の日本語ドキュメントに次の注記があるためです。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
出典: Amazon Bedrock とは(AWS ドキュメント日本語版)、2026 年 9 月参照
日本語版で読んで理解し、試験で英語の原文と食い違う、という事故を避けたかったので、原文を Claude に読ませて日本語の解説を書かせる形にしました。手元の教材を追加で取り込む場合は、配布元の利用規約で複製や自動取得が認められているかを先に確認してください。
読み取りから図表までをひと続きにする
ページを読ませる役は Claude in Chrome に任せました。自分の Chrome で開いているページを、そのまま Claude に読んでもらえる仕組みです。試験ガイドやドキュメントを開いておけば、翻訳して、貼って、解説を書いて、という繰り返しが 1 本の流れになります。
Loading diagram...
解説を書かせる前に、自分がどのあたりまで理解できていてどこが弱いかを Claude に読み取らせておきます。そのうえで、長い文章を読むのが好きではないので、可能な限り図にしてほしいと指示しました。この 2 つを先に渡しておくかどうかで、返ってくる解説の当たり外れがかなり変わります。
2 週間でできたもの
AWS の分を一通り育て終えたあと、Google Cloud Professional Cloud Architect も受けるつもりだったので、1 リポジトリで複数の試験に対応する構成に作り替えました。現時点の中身は次のとおりです。
| 項目 | AIP-C01 | Professional Cloud Architect |
|---|---|---|
| 解説の文字数 | 約 68 万字 | 約 36 万字 |
| 図 | 844 枚 | 552 枚 |
| サービス図鑑 | 91 件 | 37 件 |
| 比較表 | 27 本 | 21 本 |
| 構成パターン | 8 本 | 10 本 |
| 用語集 | 73 語 | 50 語 |
練習問題は、認定ページの練習問題と、出題範囲に沿って Claude に作らせた問題です。1 問の画面には、日本語の問題文、6 項目の解説、選択肢の比較表、解き方の分岐図、構成図が並びます。全選択肢に「なぜ違うか」を書かせているので、正解の理由だけを覚えて終わりにならない作りにしました。
サービス図鑑は、Amazon Route 53 のような個々のサービスが何をするものかを図にしたものです。比較表は似た役割のサービスをどちらで使うかの判断表、構成パターンは公式ドキュメントに載っている構成をまとめ直したもの、用語集は自分が分かる言い方に開き直した表になっています。
Google Cloud 側は業務で引ける形にした
Google Cloud は業務で使ったことがなかったため、試験対策よりも、実際に構成を考えるときに引ける形を意識しました。入れたのは 3 つです。
1 つ目は、全 37 サービスに置いた「AWS でいうと」欄です。名前を対応づけるだけでは足りないので、対応させたうえで構造の違いまで書かせました。たとえば Virtual Private Cloud は Amazon VPC と名前が同じでも適用範囲が違います。Google Cloud の VPC はグローバルなリソースで、1 つの VPC が全リージョンのサブネットを束ねます。一方で Amazon VPC は 1 つのリージョンに属します(いずれも 2026 年 9 月時点の公式ドキュメント)。Pub/Sub のように、AWS では複数サービスに分かれている役割を 1 サービスでカバーしているものもあります。Cloud Spanner が外部整合性を保証するような、対応表だけでは伝わらない前提の違いも、この欄に書き足していきました。
2 つ目は、サービス同士のつながりを 37 ノード・44 本の線でまとめた図です。線には「データが流れる」28 本、「権限で守る」11 本、「監視する」2 本、「利用する」3 本の種類を持たせました。単語帳ではなく、構成を考えるときに引ける地図にしたかったためです。たとえば Cloud Run を中心に見ると、Cloud Load Balancing からリクエストが流れ、Cloud SQL に読み書きし、IAM のサービスアカウントで実行され、Cloud Monitoring がメトリクスを集める、という 1 本ごとの理由が線に付いています。
3 つ目は「症状 → 原因 → 対処」の早見表です。AWS の経験があるほど踏みやすい勘違いを、手が止まる場面から引ける形にしました。
| 症状 | 原因 | 対処 |
|---|---|---|
| VPC の設計をリージョンごとに分けようとして詰まる | AWS の VPC はリージョナル、という感覚 | Google Cloud の VPC はグローバル。1 つの VPC で全リージョンのサブネットを束ねる |
| 組織全体で一律に禁止したいのに IAM ロールで頑張ろうとする | AWS では権限(IAM)と組織の制約(Organizations と SCP)が別の概念 | Google Cloud では組織のポリシー(Organization Policy)を使う |
| グローバルな強整合とスケールを同時に求められて詰まる | AWS 単体に相当するサービスがない | Cloud Spanner(グローバル強整合と SQL)を検討する |
品質は「頼む」のではなく「通さない」で保った
人が全部読み直せる量ではないので、品質は人のレビューではなく、書き込む前の機械検査に置きました。
仕組みは 2 段です。まず 1 問の解説の型を固定しました。「そもそも何の話か」から「次に同じ形が来たら」までの 6 セクションと、選択肢の比較表・解き方の分岐図・構成図の 3 点セットが必須です。次に、追記のたびに自作スクリプトがその型を検査します。セクションの欠け、700 字未満の解説、40 字未満の「なぜ違うか」、図の記法の誤り、既存問題との重複、実在しない参照先が対象で、1 件でも NG が出たら 1 バイトも書き込みません。
書き込んだあとは、verify(構文と図の記法)・audit(参照整合性と内部矛盾)・gaps(育て方として足りない箇所)の 3 つの自作スキルで定期点検します。audit は毎週決まった時間に Claude のルーティンで走らせ、公式ドキュメントとの突き合わせも同じ枠でやっています。ルーティンの組み方は Claude Code のルーティンで運用を自己改善する記事が参考になります。現時点では両試験とも ERROR 0 件・WARN 0 件です。
強いモデルにしても、品質は線形には上がらなかった
最初は毎回いちばん強いモデルを指定していました。比較表を 20 本書かせたときに、概念が最も密な 3 本だけを最上位モデルに、残り 17 本を一段下のモデルに割り当てて見比べたところ、品質の差は出ませんでした。
差を作っていたのは、6 セクション必須・700 字以上・図表 3 点セットという機械的な検査のほうでした。モデルを上げる前に、通らないものを書き込ませない仕組みを用意したほうが安く済みます。
指摘 744 件のうち、新しく書いたのは 26 件
audit の指摘は一通り作り終えるまでに累計 744 件になりましたが、約 700 件は既存の記述にリンクを張るだけで済むものだったので、スクリプトで自動処理しました。新しく書く必要があった 26 件だけをサブエージェントに 1 件ずつ渡し、最終的に 0 件になりました。仕分けてから渡しただけで、中身の密度は下げていません。
つまづいたところ
運用面で 2 つつまずきました。1 つ目は、執筆用のサブエージェントを 4 本同時に走らせて週の上限に達し、2 本が途中で失敗したことです。以降は同時 2 本までにしています。2 つ目は「重複の疑い 41 件」の警告がすべて誤検知だったことです。ケーススタディ形式の問題が共有する定型の前置き文に類似度が引きずられていたので、定型文を除いてから測るように計測側を直しました。警告は消す前に中身を見る、が教訓です。
まとめ
2 週間で分かったことを整理すると、次のようになります。
- 英語の資料を読ませて、日本語訳から解説・図表までをひと続きにできたのが起点だった
- 1 問の画面を「問題文・6 項目の解説・図表 3 点」の型に固定すると、Claude の出力が安定し、機械で検査できるようになった
- 品質を決めていたのは、モデルの強さより、書き込む前に落とす検査のほう
- 指摘 744 件のうち手で書いたのは 26 件。仕分けてから機械に渡すと、量に押し切られずに済む
- 検査ツールの警告は、消す前に中身を見る
AI 駆動開発を実際に動くリポジトリで体得する研修として、AIDD キャンプもご用意しています。社内での AI 活用の進め方でお困りごとがあれば、お気軽に KDDIアイレットへご相談ください!
※ 本記事の内容は公開時点の情報です。サービスの名称・内容・料金は予告なく改訂されることがあります。




