DX検定の 「クラウドとIT開発/運用分野（K）」 は、クラウドの基本概念から、IT開発/運用の考え方までを体系立てて理解することが求められる領域です。しかし、クラウドは定義やモデルが複数あり、開発/運用も用語が多いため、丸暗記だと混乱しやすいのが実情です。
本記事は、K1（クラウド・コンピューティング）とK2（IT開発/運用）で、実際の試験の問題文や選択肢での頻出キーワードを出題頻度（★〜★★★）つきで整理した「合格用まとめ」です。
クラウド/開発運用を「基礎→応用→構築（開発）」の観点で段階的に整理でき、最後に「混同しやすいキーワードまとめ」で取り違えやすい概念を総復習できるので、理解の順序を崩さずに学習を進めたい方におすすめです。
出題範囲の全体像はこちらのページをご覧ください。
K1_クラウド・コンピューティング
クラウドの基礎知識
クラウドコンピューティング（★★★）
定義：ネットワーク越しに、計算資源（サーバー/ストレージ等）やサービスを必要に応じて利用する形態。
ポイント：
・「自前で買う」のではなく「必要な分だけ使う」に設計思想がある
・スケール（増減）を速くできる前提で、サービス設計や運用が変わる
間違えやすいポイント：クラウド＝“サーバーがどこかにある”という場所の話だけではなく、利用モデル（オンデマンド/計測/共有）の話。
NISTのクラウド定義（SP 800-145）（★）
定義：クラウドの本質を「5つの必須特性」「3つのサービスモデル」「4つのデプロイモデル」で整理した代表的定義。
ポイント：試験では「5つの特徴（必須特性）」が選択肢トラップになりやすい
間違えやすいポイント：問題文で「2009年に発表」と書かれていても、広く参照される最終版は2011年公表として紹介されることがある（用語セットを覚えるのが主目的）。
クラウドに欠かせない5つの特徴（必須特性）（★）
定義：NISTが示す「クラウドであるための要件（5点セット）」。
ポイント（5点セット）：
- オンデマンドセルフサービス（★）
- 幅広いネットワークアクセス（★）
- リソースの共有（★）
- 迅速な拡張性（★）
- 計測可能なサービス（従量課金）（★）
間違えやすいポイント：ハイブリッドクラウド/マルチクラウド/ベアメタルは「5つの特徴」そのものではない（別概念として混ぜられがち）。
IaaS（★）
定義：サーバー・ネットワーク・ストレージなど“インフラ”をサービスとして提供する形。
ポイント：OSやミドルウェアは利用者側で責任を持つ側に寄る（責任分界の理解が鍵）
間違えやすいポイント：IaaS＝物理サーバーそのもの（ベアメタル）ではない。
PaaS（★）
定義：アプリ実行基盤（ランタイム/ミドルウェア等）をサービスとして提供する形。
ポイント：開発者は“アプリの開発とデプロイ”に集中しやすい
間違えやすいポイント：PaaS＝SaaS（完成品アプリ）ではない。
SaaS
定義：完成したアプリケーションをサービスとして利用する形。
ポイント：ユーザーは“使う”に寄り、運用は提供側に寄る。
間違えやすいポイント：SaaS＝クラウドそのもの、ではない（クラウド上で提供される“サービス形態”の一つ）。
ベアメタル（★）
定義：仮想化を介さず、物理サーバーに近い形で計算資源を提供する形態（またはサービス）。
ポイント：高性能/専有性/特殊要件で比較対象に出やすい
間違えやすいポイント：ベアメタル＝クラウドではない、ではない（クラウド提供形態の一つとして出る）。
ハイブリッドクラウド（★）
定義：オンプレミス（自社環境）とクラウドを組み合わせて運用する形。
ポイント：データやレガシー資産の都合で「全部クラウド」が難しい時の現実解になりやすい
間違えやすいポイント：ハイブリッド＝複数クラウド、ではない（オンプレ×クラウドが軸）。
マルチクラウド（★）
定義：複数のクラウド事業者（例：A社/B社）を併用する形。
ポイント：特定ベンダーロックイン回避、用途ごとの使い分けで語られやすい
間違えやすいポイント：マルチクラウド＝オンプレ併用、ではない（それはハイブリッド）。
クラウドの応用知識
クラウドネイティブ（★★）
定義：クラウド環境に最適化した設計・開発・運用の考え方（小さく分けて独立運用しやすくする等）。
ポイント：試験では「マイクロサービス」と「コンテナ」がセットで問われやすい（クラウドネイティブの代表要素）
間違えやすいポイント：「クラウド上で動けばクラウドネイティブ」ではない（設計思想が主）。
サーバーレス・アーキテクチュア
定義：サーバー管理を意識せず、イベント等に応じて実行環境が動く設計（運用負担を寄せる）。
ポイント：スケールと運用の“自動化寄り”の文脈で押さえる。
間違えやすいポイント：サーバーが無い、ではない（管理を意識しないだけ）。
分散型クラウド
定義：クラウドの機能や運用を、複数拠点へ分散させる考え方（中央集約だけでない）。
ポイント：エッジや拠点要件（遅延/規制/拠点運用）と結び付けて覚える。
間違えやすいポイント：分散＝マルチクラウド、ではない（分散の軸が違う）。
量子クラウド
定義：量子計算資源（量子デバイス等）をクラウド経由で利用する提供形態。
ポイント：「量子×クラウド」の言い回しとして暗記。
間違えやすいポイント：量子クラウド＝量子暗号、ではない（計算資源の提供の話）。
オンプレクラウド
定義：オンプレミス側に“クラウド的運用（自動化/セルフサービス等）”を持ち込む考え方。
ポイント：ハイブリッドの文脈で一緒に出やすい。
間違えやすいポイント：オンプレ＝クラウドではない、と即断しない（運用モデルとしての“クラウド化”が論点）。
NIST 5特性（★）を満たす設計
定義：オンデマンド・計測可能・迅速拡張などを、運用やシステム要件として落とす考え方。
ポイント：クラウドを“定義”で問われる時は、5特性のどれかが穴埋めになりやすい。
クラウドの開発知識
コンテナ（★★）
定義：ホストOS上で、アプリを分離して動かすための軽量な実行単位。
ポイント：「ホストOS（カーネル共有）」がキーワードになりやすい。仮想マシンより軽量、という説明で出やすい
間違えやすいポイント：コンテナ＝複数OSを同時に動かす仕組み、と混同しない（OSカーネル共有の発想）。
コンテナエンジン（★）
定義：コンテナを作成・実行・管理する仕組み（概念としての用語）。
ポイント：試験では「コンテナ＝ホストOS上」「隔離＝コンテナエンジン等を介して」という説明で出やすい。
間違えやすいポイント：エンジン＝オーケストレーター（Kubernetes等）と混同しない。
Kubernetes（★）
定義：コンテナを大規模に運用するためのオーケストレーション基盤（OSS）。
ポイント：“コンテナ管理基盤の代表名”として暗記。Cloud Native Computing Foundation（CNCF）文脈と一緒に出やすい
間違えやすいポイント：Kubernetes＝Dockerの別名、ではない（役割が違う）。
Docker（★）
定義：コンテナの作成・配布・実行を支える代表的技術/製品名として出やすい語。
ポイント：Kubernetesと並べて「作る/動かす」寄りの文脈で覚える。
間違えやすいポイント：Docker＝コンテナオーケストレーション、と混同しない。
Cloud Native Computing Foundation（CNCF）（★）
定義：クラウドネイティブ技術を支えるOSS群のコミュニティ/財団（Kubernetesの文脈で頻出）。
ポイント：KubernetesがCNCF関連として説明される問題で名前が出やすい。
間違えやすいポイント：CNCF＝クラウド事業者、ではない（コミュニティ/財団側）。
KubernetesベースのPaaS/IaaS（★）
定義：クラウド各社がKubernetesを基盤にしたサービス（PaaS/IaaS）を提供する、という文脈。
ポイント：問題では「KubernetesベースのPaaS/IaaS」という言い回しがそのままヒントになりやすい。
K2_IT開発/運用
IT開発/運用の基礎知識
マイクロサービス（★）
定義：機能を小さなサービスに分割し、独立して開発・デプロイ可能にする設計思想。
ポイント：クラウドネイティブの説明文で登場しやすい（“独立したサービス群”の言い回し）
間違えやすいポイント：マイクロサービス＝分散型、とは限らない（分割の目的と運用が要点）。
DevOps（★）
定義：開発（Dev）と運用（Ops）が協調し、リリースと改善を高速に回す考え方。
ポイント：
・CI/CDなど“継続的に届ける”運用とセットで語られやすい
・ブランチ戦略（Flow系）と並んで出やすい
間違えやすいポイント：DevOps＝特定ツール名、ではない（文化・プロセスも含む）。
アジャイル開発（★）
定義：短いサイクルで作って改善する開発アプローチ。
ポイント：小規模チーム/変化が多い領域の文脈で出やすい。
間違えやすいポイント：アジャイル＝計画しない、ではない（“計画の粒度と見直し頻度”が違う）。
OSS（★）
定義：ソースコードが公開され、ライセンスの範囲で利用・改変・再配布できるソフトウェア。
ポイント：Kubernetesの説明で“OSS”がそのまま出やすい
間違えやすいポイント：OSS＝無料、ではない（ライセンスと運用が論点）。
プラットフォームエンジニアリング（★）
定義：開発者が速く安全に開発できるよう、共通基盤（内部プラットフォーム）を設計・提供する取り組み。
ポイント：
・DevOpsやコンテナ/クラウドと密接、という説明で出やすい
・“開発者体験（DX: Developer Experience）を整える”文脈で覚える
間違えやすいポイント：データエンジニアリング（データ基盤寄り）と混同しない。
Git（★★）
定義：分散型バージョン管理システム。
ポイント：ブランチ運用（Flow系）とセットで出やすい
間違えやすいポイント：Git＝GitHub（サービス）ではない。
GitHub Flow（★）
定義：シンプルで迅速な運用に寄せたブランチ運用の考え方。
ポイント：小規模チーム/高速リリースの文脈で比較対象になりやすい。
間違えやすいポイント：Flow＝どれも同じ、と混同しない（チーム規模や運用要件で使い分ける）。
GitLab Flow（★）
定義：環境ごとのブランチ管理や課題管理と結び付け、DevOps運用に寄せたブランチ運用の考え方。
ポイント：中〜大規模/統合的運用（課題管理・環境ブランチ等）という文脈で出やすい。
間違えやすいポイント：GitHub Flowと“シンプルさ/統合運用”の軸を取り違えない。
SVN（Subversion）（★）
定義：集中型のバージョン管理システム。
ポイント：Gitとの比較選択肢として登場しやすい。
間違えやすいポイント：SVNの特性（集中型）をGit（分散型）と混同しない。
IT開発/運用の応用知識
ノーコード開発（★）
定義：基本的にコードを書かず、UI操作や設定でアプリを構築する開発手法。
ポイント：非開発者でも扱える、という文脈で出やすい
間違えやすいポイント：ノーコード＝自由度が高い、とは限らない（枠内で速い）。
ローコード開発（★）
定義：GUIや設定を中心にしつつ、必要に応じて少量のコードも併用できる開発手法。
ポイント：「ドラッグ＆ドロップ（★）」がキーワードとして結び付きやすい
間違えやすいポイント：ローコード＝ノーコード、と混同しない（コード併用の余地が違う）。
Kintone（★）
定義：テンプレートアプリをカスタマイズして業務アプリを作れる、ローコード開発ツール例として出やすい名称。
ポイント：試験では「ローコードの具体例」として覚えるのが効率的。
Google AppSheet（★）
定義：業務アプリを比較的簡単に作れる“ノーコード/ローコード枠”として選択肢に出やすい名称。
ポイント：同じ“簡単にアプリ開発”枠のツール名と混同しない。
間違えやすいポイント：AppSheetを「コンテナ/オーケストレーション」系と混ぜない（領域が違う）。
Microsoft Designer（★）
定義：資料/デザイン作成系のサービス名として選択肢に出やすい名称。
ポイント：アプリ開発（ノーコード/ローコード）と“領域が違う”という見分けが重要。
間違えやすいポイント：Designerを「開発基盤」扱いしない。
IT開発/運用の構築知識
GitHub Copilot（★）
定義：コード補完や提案など、開発を支援するAIペアプログラマ系ツール。
ポイント：「AIがコードを書く」のではなく「開発者の作業を支援する」位置づけで覚える
間違えやすいポイント：Copilot＝完全自動で開発が終わる、ではない。
GitHub Copilot X（★）
定義：Copilotをチャット等の体験に拡張し、開発プロセス全体で支援を強めた取り組み（発表名）。
ポイント：チャット/質問応答、プルリク支援など“体験拡張”として覚える
間違えやすいポイント：Copilot X＝「アイデアだけで自動的に全部のコードを書く」と断定しない（支援範囲の説明が重要）。
バイブコーディング（★）
定義：自然言語で意図を伝え、AIと対話しながら実装を進める“新しいコーディングの進め方”として出やすい言い回し。
ポイント：AI時代の開発スタイル名として暗記（用語問題になりやすい）。
間違えやすいポイント：プロンプトエンジニアリング（★）と混同しない（後者は“指示文設計”の技術寄り）。
プロンプトエンジニアリング（★）
定義：AIに望む出力を得るために、指示（プロンプト）を設計・改善する技術。
ポイント：コーディング支援でも、要件整理や制約指定として重要。
間違えやすいポイント：プロンプトエンジニアリング＝ツール名、ではない。
Cursor / カーソル（★）
定義：AI支援を前提にした開発ツール名として選択肢に出やすい名称。
ポイント：「AIによるプログラミング支援ツール」の具体例枠として暗記。
間違えやすいポイント：一般名詞の“カーソル”と取り違えない（文脈で判断）。
GitHub Spark（★）
定義：自然言語でやりたいことを説明すると、AIがアプリを生成し、プレビューしながら進められる開発体験（サービス名）。
ポイント：
・「自然言語→動くアプリ」系の固有名詞として押さえる
間違えやすいポイント：Copilot（既存コード支援）とSpark（アプリ生成体験）を同列にしない。
Replit（★）
定義：開発環境/実行環境として選択肢に出やすいサービス名。
ポイント：「AI開発支援」や「ブラウザで開発」などの文脈で混ざりやすいので名前を押さえる。
間違えやすいポイント：Replitをノーコード/ローコードの代表例として断定しない（選択肢の混同枠になりやすい）。
コードインジェクション（★）
定義：文脈により、コードを不正に注入する攻撃や脆弱性の話になり得る用語。
ポイント：AI開発支援の話題に紛れ込む“それっぽい別領域ワード”として注意。
間違えやすいポイント：AIコーディング手法（バイブコーディング等）と同カテゴリ扱いしない。
代表サービス/事例
Copilot Xの「開発支援」機能（★）
定義：チャット等の体験で開発者を支援する、という方向性の代表例。
ポイント：試験では「開発プロセス全体の支援」「修正提案・テスト生成」などが選択肢になりやすい。
混同しやすいキーワードまとめ
ハイブリッドクラウド（★） vs マルチクラウド（★）
ポイント：
・ハイブリッド：オンプレ×クラウドの組み合わせ
・マルチ：複数クラウド事業者の併用
間違えやすいポイント：「複数＝マルチ」と短絡して、オンプレ併用（ハイブリッド）を落とす。
オンデマンドセルフサービス（★） vs ハイブリッド/マルチ（★）
ポイント：
・オンデマンドセルフサービス：NIST 5特性（クラウドの定義要素）
・ハイブリッド/マルチ：クラウドの“使い方・構成”の分類
間違えやすいポイント：NISTの「5つの特徴」を問う問題に、ハイブリッド/マルチ/ベアメタルを混ぜてしまう。
IaaS（★） vs PaaS（★） vs SaaS
ポイント：
・IaaS：インフラ提供
・PaaS：実行基盤提供
・SaaS：アプリ提供
間違えやすいポイント：「どこまで提供側が面倒を見るか（責任分界）」で見分ける。
ベアメタル（★） vs IaaS（★）
ポイント：
・ベアメタル：物理に近い専有/高性能寄り
・IaaS：仮想化前提の計算資源提供が典型
間違えやすいポイント：どちらも“インフラ提供”に見えるが、仮想化の前提や専有性が違う。
Docker（★） vs Kubernetes（★）
ポイント：
・Docker：コンテナを作る/動かす寄りの代表語
・Kubernetes：コンテナを“まとめて運用する”管理基盤（オーケストレーション）
間違えやすいポイント：Kubernetes＝Dockerの上位版、のように雑に一体化しない（役割で分ける）。
コンテナ（★★） vs 仮想マシン（VM）
ポイント：
・コンテナ：ホストOSのカーネル共有で軽量
・VM：OSごと分離（重いが分離が強い）
間違えやすいポイント：コンテナを「複数OSを動かす」と誤認する。
DevOps（★） vs プラットフォームエンジニアリング（★）
ポイント：
・DevOps：開発と運用が協調して高速に回す文化/プロセス
・プラットフォームエンジニアリング：開発者が速く安全に開発できる“内部基盤”を整備
間違えやすいポイント：どちらも運用改善に見えるが、プラットフォームは“共通基盤提供”に軸がある。
GitHub Flow（★） vs GitLab Flow（★） vs SVN（★）
ポイント：
・GitHub Flow：シンプル運用・迅速リリース寄り
・GitLab Flow：課題管理や環境ブランチなど統合運用寄り
・SVN：集中型VCS（Git系と性質が違う）
間違えやすいポイント：Flow同士の“運用の軸”を落として、ただの用語暗記で取り違える。
ノーコード（★） vs ローコード（★）
ポイント：
・ノーコード：基本コードを書かない
・ローコード：少量のコード併用があり得る（ドラッグ＆ドロップ等）
間違えやすいポイント：どちらも“簡単開発”だが、自由度とガバナンスの設計が変わる。
GitHub Copilot（★） vs Copilot X（★） vs GitHub Spark（★）
ポイント：
・Copilot：コーディング支援（補完・提案）
・Copilot X：チャット等で体験拡張し、支援範囲を広げる
・Spark：自然言語から“動くアプリ”を生成しプレビューする体験
間違えやすいポイント：「AIがすべて自動で開発」系の雑な理解で、役割の違いを落とす。
