データセンターの推奨には撤回ルールが必要である

データセンターの設定には、相反する方向に作用し得る2つの役割があります。短い電圧擾乱の間も施設の送電網接続を維持することと、故障が対応を必要とするときに予備電源へ切り替えることです。最初の課題を解決する推奨であっても、2つ目の課題への正当性を得たことにはなりません。私の設計基準は、一見成功したように見える回答を取り消し得る根拠を含め、両方の条件を明示することです。

当社のVeriprajnaシミュレーションは、合成施設においてその基準を実践しています。その機器リスト、電圧事象、結果はテストフィクスチャであり、顧客の導入事例や実測インシデントではありません。モデル支援実行では、新規の推論ではなく、ローカルブリッジ経由のキャッシュ済み応答を使用しています。その限定された例において、新たに追加提案された故障により、最終的な回答は暫定合格の設定から推奨なしへと変化します。

この反転は極めて重要です。なぜなら、たとえすでに妥当な設定と流暢な解説が存在していても、ワークフローは不合格となった受入テストを保持しなければならないからです。

切り替えを行う2つの理由

このシミュレーションは、UPS（無停電電源装置）の群をモデル化しています。一方の切り替え経路は、移動時間窓内で対象となる電圧擾乱をカウントします。一定回数の事象が蓄積されると、ユニットは予備電源へ切り替わります。もう一方の経路は、十分に深く持続的な電圧低下に対して独立して反応します。カウント設定を変更しても、この2つ目の経路はそのまま残ります。

この工学的なトレードオフは、機器構成図がなくても理解できます。敏感なカウンターは、施設が乗り切るべき一連の擾乱の間に切り替えを行ってしまう可能性があります。より許容度の高いカウンターは、モデル化された負荷の接続を維持できますが、保護機能のテストに使用される故障事例には依然として対応する必要があります。このデモでは、有限な事象ライブラリ全体にわたって両方の動作を満たすことが受入条件となります。

これらの結果も慎重に命名する必要があります。データセンターを予備電源に切り替えると商用電源グリッドから負荷が切り離されますが、それ自体はサーバーの電源が喪失したことを証明するものではありません。逆に、モデル化されたグリッド負荷を維持していることは、実際のバッテリーに十分なエネルギーがあるかどうかについて何も示していません。設定の推奨は、一方の指標から他方の結論を借用することはできません。

初期探索では、累積カウントを用いて90秒の窓内で5回の事象を許容する候補が見つかります。これはベースライブラリに合格します。これによりワークフローには候補のテストを継続する理由が生まれますが、疑うことをやめる理由にはなりません。

提案された故障が経路の間から漏れる

キャッシュされたモデルチャレンジャーは、進行性の変圧器巻線絶縁故障とラベル付けされた合成事象を追加します。有用な根拠はシミュレータ内での挙動であり、その名称が示唆する権威ではありません。

これには、90秒以上離れた4回のカウント対象電圧低下が含まれています。暫定的な5回カウントの候補では、十分な回数が蓄積される前に初期の低下が時間窓から外れてしまいます。また、各低下はモデル化された0.60 per-unitの深刻な低下しきい値（per unitは定格電圧に対する比率を意味します）を上回ったままです。どちらの切り替え経路も、その候補に対して提案された事象を捕捉できません。

その後、ワークフローは、4つのベース故障に提案された事象を加えたものを使用し、事象しきい値、時間窓、カウントモードの全32通りの組み合わせにわたって探索を繰り返します。軽微な事象と故障事象の両方の条件を満たす候補は存在しません。最終結果は選定構成なしの棄権となります。これは暫定推奨の撤回であり、すべての候補があらゆる個別テストに失敗したという測定結果ではありません。

ここで重要な設計上の選択が見て取れます。モデルは新しい事例を提示できますが、候補が受入可能であり続けるかどうかは決定論的チェックが判断します。それらのチェックが失敗した後に、提案設定の説得力のある説明によって推奨を復活させることはできません。デモ解説では、この例の動画と詳細なコンテキストを提供しています。

合格するまで調整を続けない理由とは？

カウント窓を広げることは、間隔の広い擾乱に対する自然な対応のように思えます。しきい値を下げることも同様です。どちらも切り替えを引き起こす事象を変更するため、軽微な擾乱を乗り切るという目標を損なう可能性があります。修正策は、新しく追加された事象を捕捉できるかだけで判断するのではなく、両方の目的に対して評価される必要があります。

実演された探索はすでに有限のメニューを確認し、回答なしを返しています。そのメニューを拡大することは新たな実験となります。別の候補を特定できるかもしれませんが、成功は依然として同じ受入条件とモデルが表現するものに依存します。メニューを使い果たしたことは、探索された選択肢に関する根拠であり、考えられるあらゆる機器設定が不適切であることの証明ではありません。

私は、最も失望の少ない失敗を選んで構成として提示するよりも、未解決の結果を目に見える形で残すことを好みます。その選択にはコストが伴います。チームはこの実行から新しい設定を受け取りません。どのような根拠やモデル変更が次の探索を正当化するかを判断する必要があります。その拒絶は、不足している作業を明示することによって正当性を獲得します。

実際のエンジニアリングプロセスにおいて、提案された変更を保留することは、既存の機器を運用することとも区別される必要があります。このシミュレーションは機器へのコマンドを発行しません。その棄権は、施設を切り離すべきであること、現在の設定が安全であること、あるいはハードウェアを交換する必要があることを立証するものではありません。

反例にも同様に精査が必要

困難なテストは、物理的な機器の不十分な記述でありながらも受入手順の盲点を浮き彫りにすることがあります。「巻線絶縁故障」という名称は、変圧器の診断を確定するものではありません。この例は、シミュレートされた事象がモデル化された2つの切り替え経路をすり抜けることを示していますが、その事象を実際の電気的故障として検証するものではありません。

これにより、2つの独立した判断が残されます。現在のテスト前提の下では、ワークフローには受入可能な推奨がありません。実際の施設では、エンジニアはそれらの前提が重要な機器や擾乱を表しているかどうかも評価する必要があります。回答を妨げるからという理由でテスト課題を削除することは、第1の判断を覆い隠すことになります。課題を物理的な証明として扱うことは、第2の判断を省略することになります。

したがって、有益な次のステップは、何が不確実性を解決するかを明記することです。提案された事象が物理的に妥当である場合、推奨を進める前にモデルや利用可能な設定の改訂が必要になる可能性があります。妥当でない場合、それを除外するにはモデル化された範囲に結びついたエンジニアリング上の理由が必要です。いずれのルートであっても、失敗したテストとその判断結果を保存し、後で合格した結果を理解できるようにする必要があります。

測定された機器の挙動、バッテリーエネルギー、切り替えタイミングは、この実演の範囲外にとどまります。実際の設定変更には、検証済みの機器設定、測定された擾乱データ、適切に検証された電気モデル、および独立したエンジニアリングレビューが必要となります。より流暢なモデル出力であっても、これらの不足している入力を補うことはできません。

裏付けとなるテストが失敗したときに、私が推奨の撤回を求める理由についての短い説明は以下の通りです。

AI支援エンジニアリングワークフローにおいて、私は受入記録が現在の候補、それが満たすテスト、それを排除し得るテスト、および撤回後に残る不確実性を明記することを求めます。合格した回答は、その表明された理由が有効であり続ける間のみ有用です。それらが成り立たなくなったとき、ワークフローは異議を保存し、誰かがそれを機器変更の許可として扱う前に推奨を撤回すべきです。