はじめに
「この解説、論理が破綻していませんか？」「これ、間違ってますよね？」
AWS 認定試験の対策講座を運営していると、受講生の方からこうしたご質問をいただくことがあります。
もちろん、教材に誤りがあれば修正すべきであり、実際に受講生の方からのご指摘で解説を改善するケースは多々あります。一方、やり取りを進めていくと、教材の誤りではなく「受講生の方の理解にズレがあった」というケースも少なくありません。
本記事は、受講生側のコメントを批判する目的ではなく、初学者が陥りがちな「認知の傾向」について整理し、より効果的な学習の進め方を考えるきっかけになればと思い、執筆しました。
講師（私）は AWS をはじめとしたパブリッククラウドや製造業・SCM に関する教育コンテンツを Udemy で展開しております。以下は講師のリンクです。
1. 実際にいただいた質問と回答のケース
最近いただいたご質問の中から、代表的なケースを3つ紹介します。
ケース①：「論理が破綻しているのでは？」
受講生からの質問： NLB のクロスゾーンロードバランシングをオフにする選択肢が正解になっているが、それでは同じ AZ 内の EC2 の分散もできなくなる。論理破綻ではないか。
講師の回答： クロスゾーンロードバランシングは「AZ をまたいでトラフィックを分散するか」を制御する機能であり、「同一 AZ 内のターゲット間で分散するか」を制御するものではありません。オフにした場合でも、同じ AZ 内に複数のターゲットがあれば NLB は正常にトラフィックを分散します。AWS 公式のベストプラクティスにおいても、AZ 内での分散を前提とした設計が推奨されています。
ケース②：「解説が間違っているのでは？」
受講生からの質問： Lambda の解説に「スケールアウト・スケールイン」とあるが、Lambda は同時実行数の自動調整であり、EC2 Auto Scaling の用語とは違うため解説が間違っているのではないか。
講師の回答： AWS 公式ドキュメントにおいて、Lambda がリクエストに応じて実行環境を自動調整する挙動に対し、明確に「scales out」「scales in」「scales down」という表現が使用されています。EC2 とメカニズムは異なりますが、インフラストラクチャの挙動を示す公式の標準用語です。
ケース③：「解説が紛らわしいのでは？」
受講生からの質問： 問題文に「共通コードを再利用する」とあるなら Lambda レイヤーを使うべきだが、解説に「Lambda レイヤーを管理する必要がなくなる」とあるのは紛らわしい。
講師の回答： 本問の要件は「カスタムランタイム」の使用です。コンテナイメージ方式では Lambda レイヤーは使用できないという AWS のデプロイ仕様が存在します。そのため、共有ライブラリや関数コードをすべて 1 つの Docker イメージにまとめるアプローチが正解となります。
2. ケースに共通する構造と、私自身の経験
これらのケースには、ある共通のパターンが存在します。いずれも「対象機能の仕組みを理解していないこと」に起因していますが、最初の反応は「解説の論理が破綻している」「解説が間違っている」というものです。つまり、まず自身の理解を疑うのではなく、講師の側が誤っていると認知している状態です。
実はこれ、珍しいことではありません。私自身も AWS を学び始めた頃、同じ経験をしました。当時、複数の参考書を読みながら「この解説は分かりにくい」「誤解を招く表現だ」と感じていました。しかし今、当時の本を読み返してみると、間違ったことは書かれていません。大手の IT 企業や著名な講師が執筆し、出版社が校正した書籍ですから、当然といえば当然です。
ではなぜこのような認知の歪みが発生したのか？理由は明確であり、当時の私は、単にその技術の仕組みを正しく理解していなかっただけなのです。 機能の動作原理を正しく理解していない前提で解説を読めば、正確な説明であっても、誤った前提知識に基づいて解釈（ミスリード）してしまいます。そして、自身の解釈と解説の結論が合わないとき、「自分が間違っている」ではなく「解説が間違っている」と認知してしまうのです。
執筆者と学習者の間には情報の非対称性が存在します。執筆者は「既に AWS を長年学習済」であり、学習者は「これから学習する状態」です。執筆者は AWS の専門用語（サービス名や機能）を理解しているためスラスラと文章が読めますが、学習者は専門用語を記号として捉えてしまいます。
3. なぜこのような認知の歪みが起きるのか
こうした現象は、心理学の分野において、学習の初期段階で起きやすい認知の歪みとしていくつかのパターンで説明されています。
-
ダニング・クルーガー効果（Dunning-Kruger Effect）： 特定の分野における能力や知識が低い段階にある人ほど、自身の理解度を過大評価してしまう認知バイアスです。「自分はこの機能を理解している」と思い込んでいるため、解説と自分の理解が食い違った際、「自分が間違っている可能性」に思い至らず、「解説が間違っている」と判断してしまいます。
-
確証バイアス（Confirmation Bias）： 自身の既存の理解や信念を裏付ける情報ばかりを集め、矛盾する情報を無意識に軽視する傾向です。たとえば「Lambda にスケールインという概念は当てはまらない」という先入観があると、AWS 公式ドキュメントにその記述があっても、見落としたり例外だと解釈してしまいます。
-
情報選択の偏り： 初学者の段階では、情報の正確性を判断する「ものさし」が不足しています。そのため、公式ドキュメントを確認せず、個人のブログ記事や、AI に一度質問して得た回答のみを絶対の正解と信じ込み、偏った情報で誤った確信を強めてしまうケースがあります。
これらは人間の認知の自然な傾向です。重要なのは、「自分もこのバイアスに陥っているかもしれない」と自覚できるかどうかにあります。
4. 学習を効果的に進めるための3つの助言
上記を踏まえ、学習の軌道修正を図るための実務的なポイントを3つ紹介します。
① 学習のステップ（階段）を飛ばさない
先ほどの3つのケースはすべて、AWS 認定の SAP（Solutions Architect Professional）試験の対策講座でいただいた質問です。SAP は最難関資格の一つであり、アソシエイトレベルの知識が定着していることが前提となります。
もし解説を読んで「難し過ぎる」「論理がおかしい」と感じた場合は、解説そのものではなく、単に自身の前提知識が不足しているだけかも知れません。現在地を見つめ直し、まずはアソシエイトレベルの知識を固めることを推奨します。SAP 試験は、アソシエイト試験に合格済であり、2年程度の実務経験が推奨されています。技術学習において階段を一つ飛ばしにすると、誤った理解を定着させるリスクを伴います。
② まずは公式ドキュメントで確認する
「解説がおかしいのでは」と思ったら、まずは AWS 公式ドキュメントを確認する習慣をつけてください。AWS のサービス仕様は常に更新されるので、常にドキュメントを見続ける必要があります。一度理解して終わりではなく、常に一次情報であるドキュメントに立ち返る癖をつけることが、AWS エンジニアとしての長期的なスキルの土台になります。
③ AI を活用して自身の理解をクロスチェックする
AWS のドキュメントは膨大であるため、AI を活用して効率的に調べる手段も有効です。ただし、AI も万能ではありません。古い情報や誤った情報を学習している場合があり、特に AWS 関連の知識は AI がハルシネーション（誤回答）を起こしやすいジャンルです。
私自身も、Gemini、Claude、Grok など複数の AI に対して同じ質問を投げかけ、回答を比較（クロスチェック）することで、自身の知識の信憑性を確認しています。ひとつの AI の回答を鵜呑みにしないリテラシーが求められます。
おわりに
「解説が間違っている」と感じたとき、一度立ち止まって考えてみてください。本当に間違っているのは解説なのか、それとも自分自身の前提理解なのか。
繰り返しになりますが、本記事は受講生批判ではなく、初学者が陥りがちな認知バイアスの紹介を目的としています。もし質問があれば遠慮なくどうぞ。
この問いを自分自身に投げかけ、客観視できるかどうかが、初学者とその先を分ける重要な境目になると考えています。本記事が、学習に行き詰まりを感じている方にとっての一助となれば幸いです。
プロフィール：Maruchin Tech
AWS、製造業・SCM DX を専門とする Udemy 講師。新卒で日産自動車に入社。その後アクセンチュア、NTT データを経て独立。大手製造業の基幹システム刷新や DX プロジェクトにおいて、要件定義からアーキテクチャ設計までをリード。現在は「現場で本当に使える技術と視点」をテーマに、エンジニア教育に従事。