先日、本番稼働中の仮想化基盤に新しいサーバーノードを増設しました。この作業を、AIエージェント（Claude）との分担で進めたので、その記録を残します。

結論から言うと、役割分担はかなり綺麗にハマりました。ただし「AIに任せたら全部うまくいった」という話ではありません。むしろ逆で、重要な事故を防いだ判断は、いずれも人間側から出ています。 そこも含めて書きます。

分担の実際 #

物理は人、論理はAI。乱暴に言うとこれだけです。ただし後述するとおり、「何が危ないか」を知っているのは人間側でした。

AIが効いた場面：手数・反復・突き合わせ #

AIが明確に強かったのは、退屈で、量が多く、間違えると痛い作業でした。

1. バージョンの完全一致 #

既存クラスタは全ノードのバージョンを厳密に揃える運用をしています。新規ノードはOSインストール直後で、パッケージが数世代古い状態でした。

単純に「最新へ更新」すると既存クラスタより新しくなってしまい、運用方針から外れます。かといって特定バージョンを指定すると、依存関係が解決できずインストールが失敗する。

AIは、エラーメッセージから原因を切り分け（関連パッケージを一括で指定しないと旧版が残って衝突する／本来この段階で入れるべきでないサーバー側コンポーネントを引き込んで詰まっていた）、既存ノードと寸分違わぬバージョン構成に着地させました。この手の試行錯誤は、人間がやると集中力が持ちません。

2. 全ノード横断の差分検証 #

増設後、全ノードで共有ストレージの見え方が一致しているかを1台ずつ確認しました。台数が増えるほど、人力では「たぶん大丈夫」で済ませたくなる工程です。

AIは全台に対して同じコマンドを流し、表にして差分を出すという作業を淡々とやります。結果、新ノードが既存ノードと完全に同じ状態になっていることを、憶測でなく実測で確認できました。

3. 「両端」での証跡照合 #

リンク集約（LACP）の確認では、サーバー側だけでなくスイッチ側の状態も突き合わせました。とくに、サーバー側に見えている対向装置の識別子が、意図したスイッチのものと一致するかまで確認しています。「リンクが上がった」ではなく「意図した相手と、意図した設定で繋がっている」ことの証明です。

AIが見つけた、地味だが危ないもの #

作業中、AIがいくつか「言われていないが見つけた」問題があります。

ブート順序に前OSの残骸 #

あるノードのUEFIブート順序の先頭に、以前インストールされていた別OSのエントリが残っていました。実体はディスク上に存在しないため起動はできず、さらに後続はネットワークブートのエントリが並び、正しいエントリは7番目。

このまま再起動すれば、存在しないOSを探し、ネットワークブートのタイムアウトを延々と待ち、運が悪ければ意図しないものが起動する状態でした。再起動する前に見つけられたのは大きかったです。

時刻の連鎖故障（これが一番面白い） #

別のノードで、パッケージ更新が全て失敗しました。エラーは「リポジトリの情報がまだ有効期間前（あと901日）」。

辿ると、こういう連鎖でした。

1. ハードウェアクロック（RTC）が1998年を指していた（電池切れが疑われる）
2. OSは異常と判断し、OSビルド時期まで時刻を繰り上げた（＝約2.5年前）
3. 時刻同期はインターネット上のNTPサーバーを参照する設定だったが、DNS設定が壊れていたため参照先を解決できず、同期ソースがゼロ件
4. → 時刻が2.5年前のまま → パッケージ管理システムがリポジトリを「未来の署名」とみなして全拒否

「パッケージが入らない」の真因が「DNSが壊れている」という、4段跳びの連鎖です。DNSを直して時刻同期を再起動したら一瞬で解決しました。

しかもこれは、放置していればクラスタ参加後に効いてきます。 分散システムはノード間の時刻ずれに敏感で、2.5年ずれたノードを本番クラスタに入れるのは論外です。

設定が「無言で失敗」していた #

ネットワークの性能チューニングを行う仕組みが、起動時にはまだ対象が存在しなかったため、何もせず正常終了していました。エラーは出ません。ログ上は成功です。

AIは作業順序からこれを予測して確認し、実際に未適用であることを見つけて再実行しました。「成功と表示されるが実は何もしていない」は、人力の目視確認では最も見落としやすい類です。

人間が効いた場面：これが本質 #

ここからが本題です。今回、致命的な事故を防いだ判断は、2つとも人間側から出ました。

1. 「連携用のファイル配置が漏れている」 #

AIは作業項目を整理していましたが、外部システムとの連携に必要なファイル配置を「最後にやる工程」に分類していました。実際には、その工程のうちそのファイル配置だけは先にやっても問題なく、むしろ先にやるべきものでした。

人間側から「漏れている」と指摘され、AIは初めて自分の分類ミスに気づいています。指摘がなければ、後工程でつまずいていました。

2. 「ストレージ側の登録が先だ。ちぐはぐな見え方になる」 #

これが一番大きい。

AIは参加前チェックとして、バージョン・ネットワーク・時刻などを並べて「準備完了」と判断していました。しかしそこに、ストレージ装置側のアクセス許可登録が入っていませんでした。

人間側から「登録前に参加させると、共有ストレージの見え方がノード間でちぐはぐになり、深刻な不整合を起こしかねない」と指摘が入ります。

AIが調べたところ、過去に全く同じ事象が起きた記録が社内に残っていました。1台だけがストレージを認識し他が認識しない状態になり、別ノードを再起動したら無関係なノードまで巻き込んで再起動するという事象です。

指摘がなければ、AIは綺麗に整った検証結果を並べたうえで、そのまま事故に突っ込んでいました。

結果として、事前にアクセス許可を登録し、参加前に「新ノードから見えるストレージ一覧が既存ノードと完全一致するか」を非破壊で実測してから参加させ、事故はゼロで完了しています。

この2つに共通するのは、「経験から来る危機感」です。AIは目の前の情報から整合的な結論を出しますが、「その項目がそもそもリストに無い」ことには気づけません。 何がリストに載るべきかを知っているのは、痛い目を見たことがある人間の側でした。

AIが間違えたこと（隠さずに書きます） #

公平のため、AIの失敗も並べます。これを書かない事例紹介は信用しない方がいいです。

• 手順書に誤った順序を書き、そのまま実機に持ち込んだ。 設定の投入順序を逆に記載しており、実機でエラーになって初めて発覚。幸い通信影響のない工程だったため実害はなし
• 検証したつもりで検証していなかった。 設定の事前チェックがエラーを返していたのに、スクリプトの書き方が悪く「OK」と表示していた。後から自己申告して修正
• 問題でないものを問題だと騒いだ。 1台とだけ比較して「設定が食い違っている」と報告。全台を調べたら、むしろ新ノードの方が正しかった
• 明らかに様子がおかしくなり、人間に止められた。 作業中、AIが文脈と無関係な話題に反応して脱線する事象が発生。人間側が異常を察知して作業を全面停止させ、状態を確認してから再開している

最後の1点は特に重要です。AIは自分の異常を自分では検知できません。 「何かおかしい」と思ったら止められる人間が、本番作業には必ず要ります。

学び：分業をどう設計するか #

今回うまくいった理由を整理すると、こうなります。

AIに任せて良かったもの #

• 反復・突き合わせ・全数確認（人間が「たぶん大丈夫」で飛ばしたくなる工程）
• 試行錯誤が要る依存関係の解決
• 証跡を残しながらの検証
• 作業内容の手順書への反映（やった直後に書けるので陳腐化しない）

人間が握るべきもの #

• 何をリストに載せるか（AIは載っていない項目には気づけない）
• 過去の事故の記憶に基づくリスク指摘
• 止める判断
• 物理作業（当然ながら）

そして両者に共通して効いたのが「小さく実行して、都度実測する」という進め方でした。1台ずつ、1工程ずつ、変更のたびに実測で確認する。この型があったから、AIの誤りも、人間の見落としも、傷が浅いうちに見つかりました。

おわりに #

「AIがインフラを構築した」と言うと、人間が指示を出して座っているだけの絵を想像されるかもしれませんが、実際は違いました。

AIは、人間が集中力を失う領域で圧倒的に強い。人間は、AIが構造的に気づけない領域で決定的に強い。 その2つが噛み合ったとき、片方だけでは到達できない品質になります。

そして、AIを本番環境に入れるなら、止められる人間が要ります。 今回、それが機能したことが、この事例で一番共有したい点です。