Windowsが起動しなくてもPCを遠隔操作できる？――AMD AIM-TとIntel AMTの仕組みを解説
新人PCエンジニアのためのPCプラットフォーム技術入門
はじめに――Windowsが壊れたPCをどうやって修理するのか？
ある日、会社の情報システム部門に連絡がありました。
「PCの電源は入るのですが、Windowsが起動しません」
そのPCは、遠く離れた営業所にあります。
通常のリモートデスクトップでは、Windowsが正常に起動していなければ操作できません。
では、現地まで出張して修理するしかないのでしょうか。
実は、そうとは限りません。
IntelやAMDの企業向けPCには、Windowsが正常に動作していなくても遠隔から管理できる技術があります。
Intelの「AMT（Active Management Technology）」と、AMDの「AIM-T（AMD Integrated Management Technology）」です。
これらの技術を使うと、対応するPCでは、BIOS画面を遠隔表示したり、電源を制御したり、起動トラブルを調査したりできます。
今回は、これらの技術を新人PCエンジニア向けに解説します。
さらに、PCメーカーがIntelとAMDの両方を採用する場合、評価業務をどこまで共通化できるのかについても考えてみます。
1. リモートKVMとは何か？
最初に覚えてほしい用語がKVMです。
KVMとは、次の3つの単語の頭文字です。
K：Keyboard（キーボード）
V：Video（画面）
M：Mouse（マウス）
つまり、離れた場所にあるPCの画面を見ながら、キーボードやマウスで操作できる仕組みです。
例えば、東京の管理者が大阪のPCを操作する場合を考えてみましょう。
東京の管理者PCで大阪のPCの画面を表示し、キーボードを操作します。
その操作情報はネットワークを経由して大阪のPCに届きます。
そして、大阪のPCの画面情報が東京へ送られてきます。
これがリモートKVMの基本です。
しかし、普通のリモートデスクトップと何が違うのでしょうか。
最大の違いは、対応するリモートKVMでは、Windowsが起動する前の画面も扱えることです。
このようにOSから独立した管理経路を使うことを、アウトオブバンド管理（Out-of-Band Management：OOB）と呼びます。
ただし、OSが起動しなくても必ず操作できるという意味ではありません。管理用ファームウェア、ネットワーク、電源などが動作している必要があります。
2. Windowsが起動していないのに、なぜBIOS画面を表示できるのか？
ここは新人PCエンジニアに理解してほしい重要な部分です。
PCの電源を入れると、Windowsのロゴが表示される前に、メーカーのロゴが表示されます。
また、特定のキーを押せばBIOSセットアップ画面を開くことができます。
では、Windowsがまだ起動していないのに、誰が画面を表示しているのでしょうか。
答えはUEFI/BIOSです。
UEFIには、画面出力のためのGOP（Graphics Output Protocol）という仕組みがあります。
UEFIはGPUを初期化し、GOPなどを利用して画面を描画できます。
したがって、Windowsのグラフィックスドライバーが起動していなくても、BIOS画面を表示できるのです。
ただし、GOPだけではリモートKVMは実現できません。
BIOS画面を描画することと、その画面をネットワークへ転送することは別の機能だからです。
AMD AIM-TやIntel AMTでは、対応するハードウェアと管理用ファームウェアが連携して、起動前の画面を遠隔管理者へ転送します。
ここで注意したいのは、実際にどの回路から画面データを取得しているかという内部実装です。
AMDの公開ユーザーガイドではBIOS KVMの操作方法は説明されていますが、映像取得に使われる内部の回路やメモリアクセス経路まで完全に公開されているわけではありません。
そのため、管理プロセッサがGPUのフレームバッファーを直接読み取っていると断定することは避けるべきです。
技術者は、公開仕様で確認できることと、実装を推測している部分を区別する必要があります。
3. AMD AIM-Tの仕組みを理解しよう
AMD AIM-Tは、AMD Ryzen PROプラットフォーム向けの遠隔管理技術です。
対応するSoCには管理用の処理機構があり、専用ファームウェアなどと組み合わせてリモート管理を実現します。
管理に関係する主な構成要素を整理します。
AIM-Tは、DMTFが策定するDASH（Desktop and Mobile Architecture for System Hardware）という管理規格を利用しています。
DASHは、PCの電源状態やシステム情報の取得など、企業向けPCの管理機能を標準化するための仕組みです。
そのため、AMD独自の仕組みだけに頼らず、標準化された管理インターフェースを利用できます。
ただし、KVMなど一部の高度な機能にはAMD固有の実装も関係します。
OS KVMとBIOS KVM
AMD AIM-Tには、OS KVMとBIOS KVMがあります。
OS KVMはWindowsの動作中に利用するKVMです。
一方、BIOS KVMはWindows起動前のUEFI/BIOS画面を遠隔操作する機能です。
AMDの2026年9月版AIM-T 6.0ユーザーガイドによると、対応するOS KVMでは最大4K（3840×2160）まで対応しています。
BIOS KVMの解像度は1024×768です。
また、同ガイドでは、モニターが接続されていないPCではKVMがサポートされないことも説明されています。
したがって、PCメーカーは単にKVM対応と表示するだけでは不十分です。
どの画面構成、GPU、ファームウェア、電源状態で動作するのかを評価しなければなりません。
4. Intel AMTとの違いは何か？
Intelにも、企業向けリモート管理技術としてAMTがあります。
Intel AMTはIntel vPro対応プラットフォームで使用される技術で、Intel CSME（Converged Security and Management Engine）を中心に実現されています。
AMD AIM-Tと比較してみましょう。
どちらも企業PCを遠隔から管理するという目的は共通しています。
しかし、内部の管理基盤や初期設定方法、管理ソフトウェアは異なります。
また、KVMが利用できるGPU構成や電源状態にも違いがあります。
Intel AMTはIntelのグラフィックス構成との関係が重要です。
一方、AMD AIM-Tでは、対応する外付けGPUとの組み合わせもサポートされています。
ただし、AMDでもすべてのGPUやディスプレイ構成が利用できるわけではありません。
ここで重要なのは、単純にAMDとIntelのどちらが優れているかを判断することではありません。
PC OEMは、それぞれのプラットフォームの違いを理解し、製品仕様に合わせて評価する必要があるのです。
5. Provisioningとは何か？
AMD AIM-TとIntel AMTを利用するには、Provisioning（プロビジョニング）が必要です。
Provisioningとは、PCの遠隔管理機能に管理者の認証情報や権限などを登録する初期設定です。
例えば、新しく建設した会社のビルを想像してください。
建物が完成しただけでは、誰が入室してよいのか分かりません。
社員証を発行し、入室権限を登録する必要があります。
Provisioningも同じです。
BIOSで管理機能を有効にするだけでは、誰が管理してよいのか決まりません。
管理者情報を登録し、認証の仕組みを用意して、初めて安全な遠隔管理が可能になります。
AMD AIM-Tの場合
AMDでは、AMD Provisioning Console（APC）を利用できます。
代表的な手順では、APCを使って管理者情報、証明書、ネットワーク設定などを登録したProvisioning Packageを生成します。
そして、そのパッケージを管理対象PCへ配布し、適用します。
設定後はDASH CLIなどからPCを管理できます。
また、AMDには次の操作があります。
Provisioningは初回設定、Re-Provisioningは設定変更、Un-Provisioningは設定情報の消去です。
特に重要なのが、APCのCrypto Keyの管理です。
AMDは、Re-Provisioningに必要な元のCrypto Keyを安全にバックアップするよう求めています。
Intel AMTの場合
Intel AMTには、Client Control Mode（CCM）とAdmin Control Mode（ACM）という管理モードがあります。
CCMでは、KVMなどの遠隔操作時にユーザー同意が必要です。
ACMでは、適切なProvisioningを行ったうえで、管理ポリシーに応じてユーザー同意を不要にできます。
例えば、無人のPCを遠隔管理する場合、ACMが重要になることがあります。
ACMへの設定にはPKI（公開鍵基盤）などを使用する方式があります。
ただし、Intel AMTは世代によってProvisioning方式が異なります。
Intel CSME 19.0以降では、従来の一部の設定方式が廃止され、Secure Host-Based（Local-PKI）方式が推奨されています。
したがって、最新のPCで古いProvisioning手順をそのまま利用できるとは限りません。
6. リモートKVMにはセキュリティ上の危険もある
ここで忘れてはいけないことがあります。
リモートKVMは便利な技術ですが、第三者に悪用されると非常に危険です。
なぜなら、PCの画面を見たり、キーボードやマウスを操作したりできるからです。
そのため、管理者の認証と権限管理が重要になります。
AMD AIM-Tにはユーザー同意の機能があります。
ただし、AMDの公式ガイドによると、Provisioning時に同意機能を有効にしなければ、同意済みとして扱われます。
また、Windowsのロック画面では同意確認が適用されない仕様になっています。
Intel AMTの場合、CCMではKVMなどの利用者同意が必須です。
一方、ACMでは、管理ポリシーに応じて同意を不要にできます。
このように、両社のセキュリティモデルには違いがあります。
PC OEMは、KVMが正常に動作することだけでなく、認証されていない管理者が接続できないことも評価する必要があります。
さらに管理用のネットワークを一般のネットワークから分離したり、TLSや証明書認証を利用したりすることも重要です。
7. PC OEMはどのような評価をするべきか？
ここからはPCメーカーの開発現場を考えてみましょう。
リモート管理機能は、CPUや管理用ファームウェアだけでは成立しません。
BIOS、GPU、ネットワーク、電源制御、OS、セキュリティなどの機能が連携する必要があります。
そのため、PC OEMには幅広い評価が求められます。
例えば、BIOS KVMが正常に表示されても、それだけでは十分ではありません。
BIOS設定画面をキーボードで操作できるか。
設定を保存して再起動できるか。
再起動後にも接続できるか。
Windowsが正常に起動しない場合にも利用できるか。
有線LANと無線LANで動作が異ならないか。
スリープやシャットダウン状態から管理できるか。
さらに、不正な管理者からの接続を拒否できるか。
こうした試験が必要になります。
重要なのは、正常系だけでなく異常系も確認することです。
特にリモート管理機能は、PCに障害が発生したときに利用する技術です。
PCが正常なときだけ使えるリモート管理機能では、障害復旧という本来の価値が十分に発揮できません。
8. IntelとAMDの評価は共通化できないのか？
ここからは、私の考察です。
PCメーカーがIntelとAMDの両方を採用する場合、それぞれのプラットフォームに対して評価が必要になります。
しかし、評価内容を見てみると、共通する項目が多く存在します。
例えば、Provisioningの成功確認、認証失敗時の動作、電源状態の取得、BIOS KVM、ユーザー同意などです。
実装方式は異なっていても、評価の目的は共通しています。
そこで私は、Intel AMTとAMD AIM-Tの評価要求を共通化し、実際のコマンド処理だけを個別に実装する方式が有効だと考えます。
例えば、共通の評価システムから「電源状態を取得する」という指示を出します。
IntelのPCならIntel AMT Adapterが処理します。
AMDのPCならAMD AIM-T Adapterが処理します。
評価システムは、どちらからも共通の形式で結果を受け取ります。
この仕組みをソフトウェア設計ではAdapterパターンと呼びます。
Pythonで共通評価システムを構築する
実装例としては、Pythonとpytestなどを利用できます。
共通の試験プログラムには、次のようなインターフェースを用意します。
is_provisioned()：初期設定が完了しているか確認する。
get_power_state()：電源状態を取得する。
is_authentication_rejected()：不正な認証が拒否されるか確認する。
start_bios_kvm()：BIOS KVMの開始を要求する。
ただし、コマンドの成功だけで実際のKVM画面が正しく表示されたと判定してはいけません。
画面表示やキー操作の成否は、別の観測手段を組み合わせて検証する必要があります。
また、AMDのAPCによるパッケージ生成やIntelのPKI Provisioningなど、プラットフォーム固有の設定処理はAdapter側に残します。
共通化とは、違う技術を無理に同じものにすることではありません。共通する要求と製品固有の実装を分離することです。
9. 評価自動化をどのように進めるべきか？
私なら、自動化を段階的に進めます。
最初はProvisioningを手動で実施し、その結果を自動的に確認するところから始めます。
次に、設定パッケージの適用や管理プロファイルの配布を自動化します。
そして、BIOSや管理用ファームウェアが更新されるたびに、関連する評価を自動的に実施する仕組みへ発展させます。
例えば、BIOS開発チームが新しいBIOSを登録したら、専用の評価用PCに適用し、KVMや管理機能の試験を開始するという方法です。
これにより、過去のBIOSでは正常だった機能が、新しいBIOSで動かなくなるような不具合を早期に発見できる可能性があります。
もちろん、ファームウェアの更新や管理情報の消去を伴う試験には注意が必要です。
本番PCではなく専用の評価機材を使い、更新失敗時の復旧手段も確保する必要があります。
また、自動化に使用する管理者パスワードや秘密鍵をソースコードやログに残さないように設計しなければなりません。
自動化のためにセキュリティを弱めてしまっては、本末転倒だからです。
10. PC OEMは何を競争力にするべきなのか？
最後に、少しPC業界全体の話をしたいと思います。
PC OEMは、IntelやAMDが提供するプラットフォームを組み合わせて製品を開発しています。
そのため、各社が同じような技術の組み込みや評価を繰り返す構造があります。
もちろん、製品固有のハードウェアやBIOS、電源制御などについては、PCメーカーが責任を持って評価する必要があります。
しかし、管理コマンドの基本動作や認証試験、標準仕様への適合性などは、共通化できる部分があるはずです。
私は、PC OEMが共通の評価基盤を構築することには、大きな意味があると考えます。
その効果は、単純な評価工数の削減だけではありません。
共通の試験結果が蓄積されれば、IntelとAMDの品質を同じ観点で比較しやすくなります。
さらに、管理機能の不具合を早期に発見し、サプライヤーへ具体的な改善を要求しやすくなるでしょう。
将来的には、PC OEM間で標準仕様に関する評価方法を共有することも考えられます。
そうなれば、各メーカーは共通技術の重複作業を減らし、製品固有の使いやすさや安全性などに開発リソースを集中できます。
これは、PC OEMがSoCベンダーに依存するだけでなく、自らプラットフォーム品質を主導するための一つの方法だと考えます。
ただし、異なるPC OEM間での共通化には、知的財産、セキュリティ情報、製品固有の技術情報をどう扱うかという課題もあります。
実現するには、標準化する部分と競争領域を明確にする必要があります。
まとめ――リモートKVMはPCプラットフォーム技術の集合体である
今回は、AMD AIM-TとIntel AMTの仕組みを解説しました。
新人PCエンジニアに理解してほしいのは、リモートKVMが単なる画面転送ソフトウェアではないということです。
CPU、GPU、BIOS、管理用ファームウェア、ネットワーク、電源制御が連携して初めて成立する技術です。
そしてProvisioningは、管理者の認証と権限を決める重要なセキュリティ工程です。
IntelとAMDでは実装方法が異なりますが、PC OEMが求める品質には多くの共通点があります。
そのため、評価要求を共通化し、プラットフォーム固有の処理を分離するアーキテクチャには価値があると考えます。
今後、AI PCなどによってPCのプラットフォームがさらに多様化すると、PC OEMの開発や評価はますます複雑になるでしょう。
そのとき、すべての作業をプラットフォームごとに繰り返すのか。
それとも、共通化できる技術を整理し、製品固有の価値に開発リソースを集中するのか。
この違いは、将来のPCメーカーの競争力にも影響するのではないでしょうか。
PC OEMが目指すべきなのは、IntelやAMDの技術を単に製品へ組み込むことではなく、異なるプラットフォームでも安全で管理しやすいPCを提供できる開発基盤を持つことだと思います。
そして、その基盤を作ることもPCエンジニアの重要な仕事なのです。
参考資料
※本記事は2026年10月16日時点の公開技術資料に基づいています。各機能の利用条件は、PCの機種、ファームウェア、管理ソフトウェアのバージョンによって異なります。
#AMD #Intel #vPro #AMT #AIMT #リモートKVM #BIOS #UEFI #PCエンジニア #ファームウェア #セキュリティ #Provisioning #品質保証 #PC開発
