vProの匠こと、牧真一郎氏
テレワークが普及する中で、各企業のシステム管理者から注目を集めている「インテル vPro プラットフォーム」。そのすべてを知り尽くした“匠”こと牧真一郎氏によると、プラットフォームで最も基本的な「リモート電源ON」機能のルーツは、「Wake on LAN（WoL）」にあるようだ。
連載の第2回目では前回に引き続き、「Wake on LAN」の進化の過程を掘り下げながら、「インテル vPro プラットフォーム」の歴史を探っていきたい。
AMT1.0リリースでWoLが進化、そしてvProでの採用へ……
――前回はLANコントローラーがまだ黎明期の頃に、“WoL（Wake on LAN）がどう使われていたか”を教えていただきました。その後のWoLの進化についても、お話を聞かせていただけますか？
牧氏：WoLの進化……というか、ハードウェアベースの管理機能でいうと、次に登場したのが「Alert on LAN」でした。これによって、センサー値に異常があった時などに、OSの状態に関係なく、管理者に通知を出す機能がリリースされます。その通信を受け取ったあとで、管理者がクライアントを遠隔操作でリセットできるようになったのが「Alert on LAN2」。その後に、標準化団体のDMTFが「ASF（Alert Standard Format）」という仕様を規格化しましたが、“電源操作”という点でいえば、この時点では従来のWoLと大きな違いはありませんでした。
――ネットワークを介して、クライアントをある程度、コントロールできるようになったと。管理者側でできることが増えそうですね。
牧氏：センサー値の異常を受けて、管理者のポケベルを鳴らす――といった機能を用意するクライアント管理ツールもありましたね。アラートを受けて、管理者が危険なクライアントを遠隔操作でシャットダウンするといった場面もあったようです。
――何か不具合があった時の、初期対応が早くなりそうですね。WoLの機能自体が進化するのは、もっと先の話ということでしょうか？
牧氏：この頃になると、WoLが現場で使われるようになるとともに、いくつかの弱点が浮き彫りになっていきました。例えば……
- マジックパケットがクライアントに受信されたか、送信側からは分からない
- 異なるセグメントのネットワークにあるクライアントを操作できない
- クライアントをMACアドレスでしか認識できない
- ユーザー認証の仕組みがない
このうち（1）についてはOSが起動して、エージェントとの通信が始まれば、電源が入ったことが分かるのですが、当時はOSの起動に時間がかかりましたので……。クライアントの電源が入るまでに、何度もマジックパケットを送信するような管理者もいました。
――今では「インテル EMA（エンドポイント・マネジメント・アシスタント）」を使えば、電源の状態がすぐに分かるんですけどね。（2）については結局、セグメントごとにクライアント管理ツールが必要だったのでしょうか？
牧氏：クライアント管理ツールによっては、セグメントごとに中継サーバーを置いて、マジックパケットを再送信することもできたようです。
――なるほど、対応は可能なものの、設定の手間が増えたと。MACアドレスの件については前回も伺いましたが、いちいちPCのケースを開けて確認する必要があったんですよね？
牧氏：なので初期設定の時も大変ですが、マザーボードやLANカードを交換すると、クライアントを認識できなくなるのも問題でした。
――確かにそれは面倒ですね……。「プロパティで簡単に表示」という時代じゃなかったですし。さらに、ユーザー認証の仕組みもないから、誰でもクライアントの電源を遠隔操作できてしまう、と。クライアント管理ツールは大企業向けに作られていただけに、問題視する会社も出てきそうです。というか、僕も当時、MagicPacket出す手軽なツールが見つけられなくて、導入を断念した記憶があります……
牧氏：そこで、この4つの弱点を解決するために開発されたのが、AMT（Active Management Technology）です。インテル vPro プラットフォームが登場する少し前にあたる、2005年にバージョン1.0がリリースされました。
当時、「82573E」というLANコントローラーがあったのですが、ほとんどのAMT1.0の機能は、このコントローラーが単独で実現していたものになります。管理用コントローラーを内蔵するとともに、ファームウェアにTCP/IPスタックを搭載しており、これが今のvProに搭載されているAMTの原形になりました。「82573E」を丸ごとスタンバイ電源で動作させることで、OSの状態に関係なく、クライアントの管理が可能となっています。
このため、AMT1.0ではクライアントの電源を入れるだけでなく、シャットダウンやリセットのほか、現在の電源状態も確認することができます。TCP/IPベースなので、ルーター側でAMTのポートを開ければ、マジックパケットがセグメントを越えることも可能に。IDとパスワードによるダイジェスト認証も実装され、“なりすまし”も防いでくれます。
さらに、サーバー用の管理モジュールでサポートされているような、SOL（Serial Over LAN）やIDE-R（IDE Redirection）機能も、AMT1.0で実装されました。
――おぉ、vProにおける「リモート電源ON」機能に、徐々に近づいてきましたね。スタンバイ電源でそこまで動くのってワクワクします。当時はサーバー向けマザーボードでもそうした管理機能が付き始めていた時代だったと思いますが、「82573E」の採用状況ってどうでしたか？
牧氏：それが、機能を一度に詰め込んだことで、コストもそれなりに上がってしまいまして……。結局、AMT1.0はそれほど普及せず、一部の企業向けに提供されたインテル製マザーボードなどにしか実装されませんでした。
これは、AMT1.0を採用していない「82573V」というLANコントローラーでも、WoLやASFに対応していたことが大きかったと思います。チップセットにはFast Ethernetコントローラーも入っていましたしね。
また、Alert on LANやASFも含めてSDKを公開していなかったため、当時は対応するアプリケーションも、大企業向けのクライアント管理ツールなど、ごく限られたものしかありませんでした。その後に、vProで採用されたAMT2.0が登場すると、SDKが公開されるようになり、対応するアプリケーションが増えていきます。
（次回に続く）
