AI基盤やHPC（高性能計算基盤）向けにベアメタルサーバー（仮想化層を挟まず物理ハードウェアを直接使うサーバー）を運用しているなら、プロビジョニング（サーバーを使える状態にセットアップする作業）の自動化は避けて通れない検討事項です。
本記事は、物理サーバーの調達・構築・廃棄までを手作業でこなしているインフラ担当者や、Kubernetesのベアメタルクラスタを設計しているエンジニアに向けて書いています。どのレイヤーをどう自動化すべきか、判断材料を整理しました。
仮想マシンならクラウドAPIを叩けば数秒でインスタンスが立ち上がります。しかしベアメタルには仮想化基盤（ハイパーバイザー）が存在しないため、電源投入・BIOS設定・OSインストールまで、すべて物理層のプロトコルで制御する必要があります。この違いを理解せずにcrontabやAnsibleの延長線上で自動化を組もうとすると、電源が入らない・ネットワーク起動が失敗するといった壁にすぐぶつかります。
自動化が必要になる典型的な場面
ベアメタル自動化の検討が始まるのは、たいてい台数が増えたタイミングです。
数台であれば手作業でも回りますが、AIトレーニング用GPUクラスタやエッジ拠点の分散ノードが数十台を超えると、設定ドリフト（本来同じはずの設定が少しずつずれていく現象）や監査ログの欠落が現実の問題になります。
また、ハードウェア障害時の切り離しや、リース満了に伴う一斉入れ替えなど、ライフサイクル全体を管理する場面でも自動化の要否が問われます。単発のOSインストール自動化と、廃棄まで含めた状態管理の自動化は別物だと意識しておくと選定が楽になります。
判断軸1: BMCアクセスプロトコル（IPMI vs Redfish）
OSインストール以前の話として、電源投入やBIOS設定を遠隔操作するにはBMC（Baseboard Management Controller、マザーボード上の管理専用チップ）へのアクセスが必要です。
従来はIPMI（Intelligent Platform Management Interface）という古いプロトコルが標準でしたが、近年はRedfish APIへの移行が進んでいます。RedfishはRESTful（HTTP経由でJSON形式のデータをやり取りする設計様式）なインターフェースで、電源状態・BIOS/UEFI設定・ブート順序・仮想メディアのマウント・ハードウェアテレメトリ（稼働状況の計測データ）取得を、標準化されたJSONペイロードでプログラムから操作できます。
IPMIはバイナリベースで拡張性に乏しく、ベンダーごとの独自拡張に頼らざるを得ない場面が多くありました。Redfishを採用しているサーバーであれば、curlやPythonのrequestsライブラリから直接叩けるため、Ansibleのモジュールを自作する手間も減ります。手元のサーバーがどちらに対応しているかは、BMCのWeb管理画面かベンダーのドキュメントで確認できます。
判断軸2: ネットワークブートの方式（PXE vs iPXE）
電源が入った後、OSをネットワーク経由でインストールする仕組みにもPXE（Preboot Execution Environment）とiPXEの2系統があります。
PXEはTFTP（信頼性より速度を優先した軽量ファイル転送プロトコル）に依存するため、大量ノードへの同時配信で転送が不安定になりがちです。iPXEはHTTP/HTTPS経由でブートローダーやインストールイメージを取得できるため、既存のWebインフラやCDNとも相性が良く、認証やTLSも組み込みやすくなっています。
すでにHTTPベースの社内配信基盤（Nginxなど）があるなら、iPXEへの移行は比較的スムーズです。逆にTFTPベースの既存PXE環境が安定稼働しているなら、無理に切り替える理由は薄いとも言えます。
判断軸3: 無人インストールの設定方式
OSイメージが起動した後、パーティション作成・SSH鍵注入・初期セキュリティ設定を人手を介さず実行する仕組みも選ぶ必要があります。
RHEL系ならKickstart、Debian/Ubuntu系ならPreseed、クラウド寄りの構成ならCloud-Initが使われます。どれも設定ファイル1枚を用意してPXE/iPXEのブートパラメータから読み込ませる方式で、既存のディストリビューションと合わせて選ぶのが基本です。
判断軸4: ライフサイクル管理の粒度
最後に、OSインストール止まりの自動化にするか、廃棄までの状態遷移を管理するかという軸があります。
本格的なベアメタル自動化基盤では、ノードの状態を「Discovered（発見済み）→Commissioned（検証済み）→Provisioned（構築済み）→Active（稼働中）」というステートマシン（状態遷移の管理モデル）で管理します。障害発生時はMaintenanceやQuarantineという状態に切り替え、CMDB（構成管理データベース）を常に実態と一致させます。
この粒度まで求めるかどうかで、必要なツールの規模が大きく変わります。単にOSを入れ替えたいだけなら軽量な構成で十分ですが、監査要件がある環境や台数が多い環境では状態管理そのものを自動化基盤に持たせる価値があります。
選択肢の比較
| 観点 | 軽量構成(iPXE+Cloud-Init手組み) | 統合基盤(MAAS/Tinkerbell等) |
|---|---|---|
| 初期構築コスト | 低い、既存スクリプトの延長で組める | 中〜高、学習コストと導入設計が必要 |
| ライフサイクル管理 | 手薄、状態管理は自前実装が必要 | 状態遷移・CMDB連携が標準機能 |
| 対応台数の目安 | 数台〜数十台規模で運用しやすい | 数十台〜数百台規模でも破綻しにくい |
| BMC操作の抽象化 | Redfish APIを直接叩くスクリプトが必要 | Redfish/IPMIの差異を基盤側が吸収 |
ケース別の推奨
台数が10台前後で、構成がほぼ均一なGPUノード群であれば、iPXE+Cloud-Initの軽量構成で十分まわります。Ansibleと組み合わせてRedfish APIを直接呼び出すスクリプトを書く程度で運用可能です。
台数が数十台を超え、ハードウェア障害の切り離しや監査ログの保存が求められる環境なら、MAASやTinkerbellのような統合基盤を検討する価値があります。状態遷移の管理を自前で書く手間が大きく減ります。
エッジ拠点が地理的に分散していて、遠隔からの再インストールが頻発する構成なら、iPXEのHTTPS対応と仮想メディアマウント機能を重視して選定するのが妥当です。ネットワーク品質に左右されにくい設計を優先すべきです。
あえて見送るべき条件
サーバー台数が数台以下で、構成変更もほとんど発生しないなら、統合基盤の導入は過剰投資になりがちです。BMCのWeb画面から手作業で設定しても運用は破綻しません。
また、既存のIPMIベースの運用が長年安定していて、監査要件も緩いなら、Redfishへの移行を急ぐ必要は薄いと言えます。ハードウェアの世代更新のタイミングに合わせて段階的に移行する方が、リスクが小さくなります。
クラウド上の仮想マシンで代替可能なワークロードであれば、そもそも物理ベアメタルにこだわる理由自体を見直す価値があります。予測可能な性能や専有ハードウェアが必須要件かどうか、まず確認しておきたいところです。
まとめ
ベアメタル自動化の検討は、BMCプロトコル(IPMI/Redfish)、ネットワークブート方式(PXE/iPXE)、無人インストール設定(Kickstart/Preseed/Cloud-Init)、ライフサイクル管理の粒度という4つの軸で整理すると判断しやすくなります。
まず手元のサーバーがRedfishに対応しているか、BMCのWeb画面かベンダードキュメントで確認するのが最初の一歩です。そのうえで、台数と監査要件から軽量構成と統合基盤のどちらが見合うか、上の表を基準に選んでみてください。