基本情報の仮想化を理解するハイパーバイザとコンテナの違い

基本情報の仮想化で大切なのは、方式名よりも「どの層を分け、どの層を共有するか」です。ハイパーバイザ型とホスト型は仮想化ソフトの置き場所、仮想マシンとコンテナはゲストOSとカーネルの扱いを見ると区別できます。

「ホストOSの上で動く」という説明だけでは、ホスト型の仮想マシンなのかコンテナなのか決まりません。この記事では、構造、CPU・メモリの配分、科目Aで読む記述の条件をつなげて整理します。後半の例題は、本記事で作成した理解確認用の問題です。

基本情報の仮想化を構造から見分ける

仮想化と仮想マシンの役割

仮想化とは、物理的な機器と利用者から見える資源の関係を切り離し、論理的な実行環境を作る技術です。サーバの仮想化では、1台の物理マシンに複数の仮想マシンを作り、それぞれを別のコンピュータのように利用します。物理サーバが増えたわけではなく、実行環境の数を物理機器の数と分けて考えられる点が特徴です。

例えば、社内用のWebサーバと試験用のWebサーバを別々の仮想マシンへ配置すれば、各環境にOSや設定を持たせられます。試験用のアプリを更新する際にも、社内用のOSへ同じ変更を加える必要はありません。ただしCPU、メモリ、記憶装置などは、下にある物理マシンの資源を利用しています。

VMはVirtual Machineの略で、ここではOS全体を動かす仮想マシンを指します。VMから見えるCPU、メモリ、ディスク、ネットワークインタフェースは仮想的に提供されます。ゲストOSはその仮想ハードウェアを使い、アプリケーションはゲストOSが提供する機能で動きます。

ハイパーバイザは、VMを作成・実行し、物理資源へのアクセスを管理するソフトウェアです。VMMという呼び方もあります。VMが実行環境そのもの、ハイパーバイザがそれを動かす管理の仕組み、と役割を分けると、同じ用語として扱わずに済みます。

IPAの基本情報技術者試験シラバスVer.9.2には、システム構成の用語例として仮想化とVMが挙がっています。ここでは、単に「1台を複数台に見せる」で終わらず、複数のOSを何が支え、資源をどこから得るかまで理解しましょう。

ハイパーバイザ型とホスト型

ハイパーバイザ型は、物理ハードウェア上で直接ハイパーバイザを動かし、その上のVMへゲストOSを置く方式です。Type1、ベアメタル型とも呼ばれます。基本的な構造を下から読むと「ハードウェア→ハイパーバイザ→各ゲストOS→各アプリケーション」です。サーバ全体を仮想化基盤として使う場面と結び付けると理解しやすくなります。

ホスト型は、物理マシンに通常のOSを動かし、そのホストOS上で仮想化ソフトウェアを動かす方式です。Type2とも呼ばれます。構造は「ハードウェア→ホストOS→仮想化ソフトウェア→各ゲストOS→各アプリケーション」です。普段使っているPCのOSを残しながら、別のOSの検証環境を用意する場面が代表的です。

比較点	ハイパーバイザ型（Type1）	ホスト型（Type2）
管理ソフトの位置	物理ハードウェア上で直接稼働	通常のホストOS上で稼働
ゲストOS	各VMに持つ	各VMに持つ
基本構造のホストOS	通常のホストOSを間に置かない	仮想化ソフトの下に置く
代表的な用途	サーバの仮想化基盤	普段のPC上での別OSの検証
判定する語	直接・ベアメタル	ホストOS上・既存OS上

ホストOSは、仮想化ソフトウェアを支える側のOSです。ゲストOSは、VMの中で動く側のOSです。ホスト型では両方が登場しますが、同じOSの役割ではありません。ホストOSがWindows、ゲストOSがLinuxという構成も考えられます。具体的に実行できる組合せは、製品が対応するCPUやOSなどの条件に依存します。

「ハイパーバイザ型はOSが不要」という表現には注意が必要です。通常のホストOSを間に置かないことと、VMにゲストOSがないことは別です。また、ハイパーバイザ自体にもメモリ管理や入出力などの機能が必要です。「OSに相当する機能が一切存在しない」と読むと誤りになります。

広い意味では、Type1もType2もハイパーバイザの種類です。一方、日本語の教材では「ハイパーバイザ型」をType1の意味で使い、「ホスト型」と対比する場合があります。問題の分類を読み、名称だけでなく、通常のホストOSを介しているかを確認してください。

Red Hatのハイパーバイザー解説も、Type1をハードウェア上で直接動く方式、Type2を通常のOS上で動く方式として説明しています。製品名を丸暗記するより、問題文に書かれた配置をこの二つの構造へ戻すほうが判断の根拠を示せます。

仮想マシンとコンテナの境界

仮想マシンとコンテナを分ける中心は、独立したゲストOSのカーネルを持つかどうかです。カーネルはOSの中核で、プロセス、メモリ、入出力などを管理します。通常のVMは、それぞれにゲストOSとそのカーネルを持ちます。コンテナは、アプリケーションの実行環境を分離しながら、その実行を支えるOSカーネルを共有します。

例えば、同じLinuxカーネルの上で、Webアプリ用とデータ処理用のコンテナを動かす構成を考えます。二つのコンテナには、それぞれ必要なプログラムやライブラリを持たせます。しかし、各コンテナのためにLinuxカーネルを一つずつ起動するわけではありません。共有する中核と、分けるアプリの実行環境が同時にあります。

比較点	仮想マシン（VM）	通常のコンテナ
分離の中心	仮想ハードウェアとゲストOS	アプリとその実行環境
OSカーネル	各ゲストOSに独立して持つ	実行基盤のカーネルを共有
含めるもの	ゲストOSとアプリ等	アプリ、ライブラリ、設定等
資源の制御	仮想CPUやメモリ等を割り当てる	CPU時間やメモリ等を制限できる
考慮する条件	ゲストOSの対応と資源容量	共有カーネルとの互換性と権限

コンテナについて「OSを含まない」とだけ覚えると、Linuxのディストリビューション名が付いたイメージを見たときに混乱します。コンテナイメージにOS由来のライブラリやコマンドなどが入ることはあります。それでも、VMのように独立したゲストカーネルを起動しているわけではありません。試験の記述では、OSという語がカーネルまで含めた意味なのかを丁寧に読みます。

Dockerのコンテナと仮想マシンの比較は、コンテナがOSカーネルを共有し、VMが各OSを持つ違いを示しています。「コンテナはアプリケーションごとにOSカーネルを起動する」という選択肢なら、この境界と逆なので誤りと判断できます。

コンテナが軽量とされるのは、各環境でゲストOS全体を動かす負担を減らせるためです。ただし、アプリ自体が大量のメモリを使えばコンテナも重くなります。起動時間もイメージの取得、初期化、処理内容などで変わります。「必ず一瞬で起動する」「どんなアプリもVMより速い」という条件のない断定にはできません。

なお、VMの中にコンテナを置く構成も可能です。その場合、コンテナが共有するのは、その実行基盤となるVM内のOSカーネルです。物理マシンの一番外側のOSをいつも直接共有すると決め付けず、コンテナのすぐ下にある実行基盤を見てください。

CPUとメモリはどう分ける

VMでは、ゲストOSに仮想CPUや仮想メモリを見せます。仮想CPUは物理CPUそのものを増やす装置ではなく、ゲスト側が使う処理の単位です。実際の命令を処理するのは物理CPUで、ハイパーバイザがVMの処理を物理資源へ対応させます。仮想CPUを合計で多く設定しても、物理マシンの処理能力がその分だけ増えるわけではありません。

理解用の例として、4コアの物理CPUがあるマシンに、仮想CPUを2個ずつ持つVMを3台設定するとします。ゲストから見える仮想CPUの合計は6個ですが、物理コアが6個になったわけではありません。三つが同時にCPUを使いたがれば競合する可能性があり、各VMへ常に専用の2コア相当の性能が保証されるとは限りません。

メモリも同様に、割当てと実際の余裕を分けて考えます。物理メモリ16GB、仮想化基盤などに必要な領域2GB、各VMへの割当て4GBという簡略化した条件で、重複割当てをせずに計算するなら、VM用に使えるのは14GBです。14÷4の整数部分から3台を置け、2GBが残ります。これは設問用の仮定であり、実際の必要容量を示す推奨値ではありません。

4台なら割当て合計が16GBとなり、管理側の2GBを含めた必要量は18GBです。物理メモリ16GBでは、この条件のままでは不足します。問題に管理用領域があるのに、16÷4で4台とするのは見落としです。一方、メモリの共有や動的な割当てなどの条件が明記される問題では、その条件を優先します。

コンテナでも資源の制御はできます。Linuxではcgroupsなどの機能を使って、CPU時間やメモリ使用量の制限を設定できます。「カーネルを共有するので、コンテナごとの資源制限はできない」という説明は誤りです。ただし、制限が最初から設定されているかどうかは別に確認する必要があります。

Dockerの資源制限の公式資料は、既定では資源制限がなく、設定によりCPUやメモリを制御できると説明しています。上限、優先度、最低限の保証は同じ意味ではありません。上限を設けるのは使い過ぎを抑えること、優先度を付けるのは競合時の配分を調整することです。本文にない保証を補って判断しないようにしましょう。

イメージと実行環境の違い

コンテナイメージは、アプリケーションのコード、実行に必要なライブラリ、設定などをまとめた実行用の材料です。コンテナは、そのイメージをもとに実行した環境です。イメージが置いてあるだけではアプリが動いているとは限らず、同じイメージから複数のコンテナを起動することもあります。設計図とそれを使って動かす実体の関係として分けてください。

例えば、同じWebアプリのイメージからコンテナを二つ起動した場合、材料は共通でも、動いているプロセスは別です。片方のアプリが終了したからといって、もう片方のプロセスまで同じ終了命令を受けるわけではありません。ただし同じカーネルや記憶装置などを使うので、共有部分の問題まで分離できるわけではありません。

アプリと依存関係を一緒にする利点は、環境の差による動作の違いを減らしやすいことです。ただし、外部データベース、接続設定、CPUアーキテクチャ、対応するカーネルなどの条件は残ります。「イメージさえあれば、どのOSでも条件なしでそのまま動く」とは考えません。持ち運びやすさは互換条件がなくなることではないのです。

VMにも仮想ディスクなどのファイルやテンプレートがありますが、コンテナイメージと同じ対象を包むとは限りません。VMはゲストOSを含む実行環境、コンテナはアプリと依存関係を中心にまとめる実行環境、と対象の違いを押さえます。特定製品のファイル形式まで暗記しなくても、この違いで記述の方向を確かめられます。

OSがプロセスを実行する仕組みが曖昧なら、基本情報のOSとスケジューリングでプロセスと資源管理を確認すると、共有カーネル上で複数のコンテナが動く意味をつなげやすくなります。

基本情報の仮想化問題を条件で解く

方式を見分ける判断手順

構造を問う記述は、文に出てくる名詞を順に確認すると整理できます。最初にゲストOSの有無、次にホストOSと仮想化ソフトの位置、最後に共有するカーネルを見ます。「高速」「柔軟」といったメリットの言葉を先に見て方式を決めると、複数の方式に当てはまって迷いやすくなります。

例えば「既存のOS上で仮想化ソフトを実行し、そのソフト上の複数のゲストOSでアプリを動かす」という文なら、独立したゲストOSがあるのでVMの構成です。さらに既存のOSが仮想化ソフトの下にあるので、ホスト型に対応します。「既存のOS上」という最初の部分だけを見てコンテナと答えないようにします。

反対に「同じOSカーネルを利用しながらアプリと必要なライブラリを分離して動かす」という文なら、通常のコンテナの特徴です。ライブラリが各環境に存在しても、それがゲストカーネルを独立して持つ根拠にはなりません。問題がどの部分を共有し、どの部分を分けると言っているかを読めば判断できます。

「仮想サーバ」「仮想環境」といった広い語だけでは方式は断定できません。問題文に層の図があるなら、箱の名前だけでなく、OSの箱が何個あるか、何を共通の土台にしているかを照合します。図と本文の両方に情報がある場合は、一方を省略せず、対応しているかを確認します。

要件から方式を選ぶ

方式の選択を問われたら、必要なOSと分離の単位から考えます。異なるOSをそれぞれ動かす必要があるなら、各ゲストOSを持てるVMが候補です。アプリごとに依存するライブラリを分けたいが、共通のカーネルを使えるなら、コンテナが候補になります。先に性能の優劣を決めるより、実行要件を満たすかを確認する順番が確実です。

例えば、Linuxを前提としたアプリとWindowsを前提としたアプリを、別々のOS環境で動かしたいケースです。各VMに対応するゲストOSを置く構成なら、この要件に合わせて検討できます。一つのLinuxカーネルを共有する通常のコンテナ構成だけで、Windowsのカーネルが必要なアプリまで動かせると判断するのは適切ではありません。

一方、同じLinuxカーネルで実行できる三つのアプリを、それぞれ異なるライブラリ構成で運用したいケースでは、コンテナが選択肢になります。各アプリの必要物を別々にまとめ、ゲストOS全体を三組起動する負担を減らせます。ただし、共有カーネルを使ってよいという前提があることが、この選択を支えています。

個人のPCで通常のOSを使い続けながら別のOSを検証したいなら、ホスト型が分かりやすい選択肢です。サーバを専用の仮想化基盤として運用する前提なら、ハイパーバイザ型が候補になります。実務では性能、対応ハードウェア、運用方法なども確認しますが、試験では問題文が指定した制約を優先して読みます。

PCでLinuxコンテナを使えるからといって、そのPCのOSカーネルがLinuxと共通になったとは限りません。Docker Desktopの仮想マシン管理の説明には、Linuxコンテナを支えるVMの仕組みが示されています。外側のOSとコンテナの間にVMがある場合は、コンテナがそのVM内のLinuxカーネルを共有すると読めます。

VMとコンテナは併用もできるため、「どちらか一方しか採用できない」という二択は必須ではありません。VMでOS環境を分け、そのVM内でコンテナを使ってアプリを分ければ、二種類の分離を重ねられます。ただし、層が増えることによる管理や資源の負担もあります。必要な要件を満たす構造を選ぶのであり、方式名の新しさで選ぶのではありません。

例題で記述の正誤を確かめる

次の問題は理解確認用の独自例題で、IPAの過去問の転載ではありません。説明を隠して自分で答えた後、「どの語が判断の根拠になったか」を確かめてみてください。正解記号だけ覚えるより、別の言い回しにも対応しやすくなります。

例題A：物理マシンで通常のOSを動かし、そのOS上の仮想化ソフトウェアが二つのゲストOSを実行している。この方式として適切なのは、ア：ハイパーバイザ型（Type1）、イ：ホスト型（Type2）、ウ：コンテナ型、エ：仮想記憶のページング方式、のどれでしょうか。

答えはイです。「通常のOS→仮想化ソフトウェア→ゲストOS」という順序が決め手です。ゲストOSがあるのでウではなく、通常のホストOSを間に置くのでアでもありません。エはメモリの管理方法に関する用語で、複数のゲストOSを実行するこの構成の分類ではありません。

例題B：同一のLinuxカーネルを共有し、各アプリケーションと必要なライブラリを分離して実行する構成について適切な説明を選びます。ア：各環境に独立したゲストカーネルが必要、イ：コンテナごとのメモリ使用量は制限できない、ウ：ゲストOS全体の起動を各環境に求めず実行できる、エ：カーネル障害の影響は必ず一つの環境だけに限定される。

答えはウです。共有するカーネルの上に実行環境を分けるので、各環境でゲストOS全体を起動する構成ではありません。アはVMの特徴との取り違えです。イは資源制限の機能を否定しているので誤り、エは共有部分の障害まで完全に分離できると断定しているので誤りです。

例題C：物理メモリ24GBのうち、基盤用に4GBを確保します。各VMへ5GBを割り当て、メモリの重複割当てはしないものとします。この条件での最大VM数は何台でしょうか。

答えは4台です。先に24−4＝20GBを計算し、20÷5＝4台とします。基盤用領域を忘れて24÷5の整数部分を求めても、この例では偶然4台になるため、答えだけでは計算手順の誤りが分かりません。数値を変えても使える根拠として、VM用領域を先に求める手順を確認してください。

例題D：4個の物理コアがあるマシンへ、仮想CPUを2個ずつ持つVMを3台設定しました。これだけを根拠に「6個の物理コアを専有でき、各VMの性能は互いに影響を受けない」と説明してよいでしょうか。

答えはいいえです。仮想CPUの数と物理コアの数は同じではなく、処理を行う物理資源は共有しています。専有や最低性能の保証があるかは、別の割当て条件を確認する必要があります。問題に書かれていない保証を、仮想CPUの個数から追加してはいけません。

この四問を通すと、方式を判定する問題、共有の特徴を選ぶ問題、容量を計算する問題、性能保証の断定を見抜く問題で、注目する情報が違うと分かります。すべてを「仮想化は効率的」という一文で解こうとせず、設問が構造・資源・保証のどれを聞いているかを先に分類しましょう。

混同しやすい記述を整理する

「一つのVMでアプリが停止しても、他のVMは必ず正常に動き続ける」という記述は、分離の意味を強く言い過ぎています。アプリやゲストOS単位の問題を分けやすいことと、あらゆる障害の影響を分けられることは別です。物理マシンの電源、共有ストレージ、仮想化基盤などが停止すれば、複数のVMへ影響が及ぶ場合があります。

したがって「VMに分けるだけで、物理サーバの冗長化も完了する」という説明も適切ではありません。VMを三つ作っても、同じ物理マシンに三つ置いているなら、その物理マシンは共通の停止要因です。論理的な分離と物理的な冗長化を区別し、設問に複数の物理機器があるかを確認する必要があります。

コンテナの分離も、カーネルや資源が一切共有されない意味ではありません。Linuxの名前空間などは、プロセスから見える環境を分けるために使われます。cgroupsなどの資源制御とは役割が異なります。「見える環境を分ける」と「使える量を制御する」を分けると、単に箱へ入れれば両方が自動的に保証される、という誤読を避けられます。

記述	判定の根拠
ホスト型はゲストOSを使わない	ホスト型VMにもゲストOSがある
コンテナごとにカーネルを起動する	通常のコンテナはカーネルを共有する
仮想CPUを増やせば物理性能も増える	処理する物理CPUの能力は別にある
資源上限があれば最低性能も保証される	上限と保証は異なる条件
同じ物理機にVMを分ければ冗長化が完了する	物理機の停止は共通の影響要因

「仮想記憶」と「仮想マシン」も違う用語です。仮想記憶は、プログラムに見せるアドレス空間と物理メモリとの関係を管理する仕組みです。仮想マシンは、OSを動かすための仮想的なコンピュータです。両方に仮想という語が入りますが、問題が聞いている対象がメモリ管理か実行基盤かで切り分けます。

仮想化とクラウドも同じ意味ではありません。仮想化は実行環境や資源を作る技術で、手元のPCや社内のサーバでも利用できます。サービスとして何を利用し、どこまで管理するかが問われる場合は、別の論点です。その判定は基本情報のクラウドサービスと管理範囲で確認できます。

安全性についても「VMなら絶対安全」「コンテナは必ず危険」と順位を固定しません。分離の単位に加え、権限設定、基盤の更新、共有する資源などが関係します。科目Aの記述を読むときは、問題が指定した一般的な構造を基準にし、構成に依存する結論を条件なしの絶対表現へ置き換えないことが大切です。

基本情報の仮想化を解く要点

基本情報の仮想化は、構造を下からたどると整理できます。通常のホストOSを介さずハイパーバイザがハードウェア上で動くならType1、ホストOS上の仮想化ソフトでゲストOSを動かすならType2です。ゲストカーネルを環境ごとに持つVMと、共通のカーネル上でアプリを分けるコンテナは、分離する層が違います。

記述を判定するときは、まずゲストOS、次に管理ソフトの位置、最後に共有カーネルと資源の条件を確認してください。資源の割当てを、物理資源の増加や専有性能の保証と取り違えないこともポイントです。上限があるか、基盤用領域を除くか、共通の障害点があるかまで読むと、正誤の理由を説明できます。

次は、本文を見ずに「ハードウェア→管理層→OS→アプリ」の順番を書き、VMとコンテナでOSカーネルの置き方がどう変わるかを確かめてみましょう。構造を説明できたら、基本情報の過去問アプリで、科目Aの記述を読み分ける練習へ進めます。