From Spec to Simulation: An AI Agent Builds a Data Center Cooling Model

ベンダー提供のPDFから始め、たった1回の作業セッションで、検証済みかつシミュレーション可能なModelicaモデルを完成させます。どの段階でも手動でのコーディングは一切不要です。これが、本記事で紹介したい機能であり、これは将来の実装予定ではなく、すでに実現されている機能です。

図1:Modelon Impactでエージェントによって生成された7.4 MWのデュアルループ型データセンター冷却モデル。ベンダー提供のPDFを基に、1回の作業セッションで完成させた成果物である。

データセンターのインフラは急速に変化しています。AIコンピューティングの普及により、施設は高密度で液体冷却を採用したアーキテクチャへと移行しつつあり、ダイレクト・トゥ・チップ冷却も研究段階から実用化へと進んでいます。設計者は、より厳しい時間的制約の下でより多くのアーキテクチャを評価しなければならず、ベンダーのリファレンスデザインから実際にシミュレーション可能なモデルへと至る道のりは長いものです。その作業の多くは、仕様書の確認、流量の算出、コンポーネントの選定、配線といった体系的なものです。これこそが、エージェントが担うことのできる作業そのものです。

課題:7.4 MWのデュアルループ型データセンター冷却システムの構築

対象となるのは、シュナイダーエレクトリックのリファレンスデザイン108(RD108)です。これは、NVIDIA GB200 AIラック向けのTier III、7.4 MWの冷却設計です。これは、すでにモデルが存在する小規模なプラントをスケールアップしたものではありません。真に異なるトポロジーを採用しています。すなわち、AIラック冷却分配ユニットに給水する37 °Cの高温ループと、ネットワークラック用の23 °Cの低温ループが別々に存在します。これらは2つの独立した回路であり、それぞれに独自のチラー、流量、バルブサイズが設定されています。

トポロジの変更は、容量の増加よりも困難です。エージェントは、既存のモデルを単純にスケールアップすることはできません。新しいループ境界を構築し、2つの独立した回路用に個別のチラーレコードを選択し、それぞれについて流量とバルブサイズを導出する必要があります。そして、唯一の入力はRD108 PDFのみです。そこにはシミュレーションに利用できるデータは含まれていません。すべての工学的値は、仕様書と、Modelonのライブラリにすでに存在する検証済みの参照モデルから導出する必要があります。

図2:左:1 MWのRD48リファレンスデザイン — IT負荷に対応する22 °Cの冷水ループが1つ。右:7.4 MWのRD108データホール — 132 kWのAIラックと22 kWのネットワークラックが、別々の冷却ゾーンに配置されている。これはスケーリングの問題ではなく、アーキテクチャが異なるのである。

AIエージェントによるデータセンター冷却モデルの自動作成方法

このエージェントは、Model Context Protocol(MCP)サーバーを介してModelon Impact上で動作します。MCPは、AIエージェントを外部ツールに接続するためのオープンスタンダードであり、ここではプラットフォームを、クエリライブラリ、Modelicaソースの読み書き、モデルのコンパイル、動的シミュレーションの実行、結果の抽出といった、型付きツール群として公開しています。すべての呼び出しは構造化されたデータを返し、セッション全体がログに記録され、監査可能です。

一連の処理は単純明快です。エージェントはPDFを読み込み、27個のエンジニアリングパラメータを抽出してタグ付けし、Data Center Libraryにクエリを発行して一致するコンポーネントを検索します。コードを記述する前に、抽出された値、計算された値、および仮定された値のすべてについて構造化された要約を表示するため、エンジニアはシミュレーションの失敗につながる前に、誤った仮定に気づくことができます。その後、デュアルループトポロジーを構成する405行のModelicaコードを生成し、プラットフォーム上でコンパイルを行い、24時間の動的シミュレーションを開始します。

図3:モデル構築中のエージェントコンソール。「compile_model」は成功を返し、CDUレコードのクエリ、モデルの書き込み、コンパイル、シミュレーションの起動という一連の処理が、手動による介入なしに実行される。すべてのアクションはログに記録され、追跡可能である。

AI生成シミュレーションモデルにおいて、検証済みのModelicaライブラリが重要な理由

ここが、単なるデモではなく実用的なものにするポイントです。エージェントは、熱交換器の方程式を記述したり、チラーの効率曲線を導出したりすることは一切ありませんでした。その必要がなかったからです。「データセンター・ライブラリ」には、Modelon社の「液体冷却」、「蒸気サイクル」、「キャリブレーション」ライブラリを基盤として、メーカーのデータシートから直接パラメータ化された冷却分配ユニットなど、ベンダーによって検証済みのコンポーネントレコードが含まれています。各コンポーネントには、メーカーのデータやキャリブレーション測定値にアクセスできる分野の専門家によって一度確立された、検証済みの物理モデルが組み込まれています。この種のレコードはコミュニティライブラリには存在しないため、オープンライブラリのみを使用したツールチェーンでは、このケーススタディを再現できない理由の一つとなっています。

同様に重要なのは、エージェントがどのような状態から開始するかという点です。私たちは、エージェントを空白のワークスペースに向けるのではなく、「Data Center 1MW」という、シュナイダーエレクトリックのRD48に対してすでに検証済みの1メガワットのリファレンスモデルに向けました。

図4:Modelon Impactで検証済みの1 MW基準モデル。これは、エージェントが7.4 MWシステムを構築する前に参照する、信頼性が確認済みの出発点である。コンポーネントの表記規則、図面のレイアウト、ポートの配線はすべてここから引き継がれる

そのモデルには、エージェントが頼りにできる規約――コンポーネントのパターン、図のレイアウト、命名規則、ポートの配線――が組み込まれています。エージェントは、第一原理からシステムを生成するのではなく、ライブラリにすでに存在する検証済みのリファレンスアーキテクチャを拡張し、再構成します。

これが中核となる考え方です。ライブラリが物理法則を保証し、エージェントが選択と構成を行います。物理法則をゼロから生成すると、その不確実性を限定しにくく、監査も困難になります。一方、検証済みのコンポーネントから選択する場合は、そのような問題が生じません。

興味深い点:エージェントが冷却モデルの問題を特定し、修正した方法

最初のシミュレーションで、この手法の有効性が明らかになった。6つのKPIのうち5つは基準を満たすか、それに近い値を示した。しかし、1つは基準を満たさなかった。低温ループの供給温度が、目標値の23 °Cに対して42.2 °Cと測定され、19 °Cの誤差が生じていた。

この結果をツールを通じて再検証したエージェントは、ループの熱バランスを追跡し、ネットワーク負荷と排熱を合わせると約1.88 MWのチラー容量が必要であることを算出しました。そして、インスタンス化されていたチラーのレコードの定格がわずか1.125 MWであり、必要容量に対して約1.7倍不足していることを突き止めました。これは物理的な誤りではありませんでした。方程式自体は正しかったのです。構築前のクエリで正しい1,881 kWのレコードがすでに特定されていたにもかかわらず、誤ったレコードが選択されていたのである。

そこで、担当者はライブラリに再度クエリを実行し、正しいレコードを確認して差し替え、不要になったコンポーネントを削除した上で、シミュレーションを再実行しました。修正後の実行結果では、目標値と完全に一致する23.0 °Cが得られました。この過程でモデルも簡潔になり、行数は405行から366行に削減されました。

図5:7.4 MWモデルにおける初回実行時のKPI結果。IT負荷は基準を正確に満たしている。冷却能力のギャップは逸脱を示しており、エージェントはこれを低温ループにおけるチラーの容量不足に起因するものだと特定した。
図6:エージェントによる冷却能力のギャップ分析。LTチラーの問題(定格出力1.125 MWに対し、必要出力は1.88 MW)が特定され、検証済みのライブラリから1件のレコードを置き換えるだけで解決された。

このエピソードは、検証済みライブラリが単にモデルを構築するだけでなく、モデルを修正する上でも重要である理由を示しています。エージェントは、信頼できる「真実の源」に再クエリを送信することで、選択ミスを修正しました。そのライブラリがなければ、再クエリを送信する対象が存在せず、検証されていない物理モデルと、その背後にあるキャリブレーション履歴が失われてしまうことになります。資産のライフサイクルが数十年単位で測定されるインフラストラクチャにとって、それは決して取るべきリスクではありません。

結果:ベンダー仕様から検証済みシミュレーションモデルまで、わずか数時間で実現

1回のセッションで仕様から検証済みモデルまで完成。比較として、経験豊富なエンジニアが同じRD108モデルを手作業で構築する場合、3~4営業日かかると推定されます。エージェントは、診断と修正を含む全プロセスを約4時間で完了しました。これは6~8倍の速度であり、すべてのアクションがログに記録され、追跡可能です。

このモデルは、単なるスケッチや生成された文書ではありません。プラットフォーム上でコンパイルされ、24時間の動的シミュレーションを実行し、公開されているリファレンスデザインに対してエンジニアリングKPIを満たしています。

図7:Modelon Impactで完成したData Center7MWのモデル。青色の領域は48台のネットワークラックに冷水を供給する低温ループ、赤色の領域は48台のAIラック用CDUポッドに冷水を供給する高温ループである。修正前後でトポロジーは同一であった。

AI主導のモデリングにおいて、依然として人間のエンジニアリング的判断が重要となる場面

エージェントは検証済みの草案を作成した。しかし、それはエンジニアリング的判断に取って代わるものではなかった。デュアルループトポロジーが顧客にとって適切かどうかを判断し、シミュレーションで使用されたベルリンの気候条件とパリでキャリブレーションされたRD108リファレンスとの間のPUEの差を解釈し、サイト固有の知識を必要とするTier IIIのステージング決定に最終承認を与えるのは、依然として人間である。適切な役割分担とは、反復的な導出や組み立て作業を自動化し、エージェントが持たない文脈を必要とする決定については人間の判断を残すことである。

このAIシミュレーションワークフローがエンジニアリング分野全体でどのように拡張するか

このアプローチが機能するのは、4つの条件が揃っているためです。まず、対象分野に対して検証済みのライブラリが存在すること。次に、参照設計から必要なパラメータを抽出できる程度に仕様が明確であること。そして、評価指標(KPI)が定量的で機械的に検証可能であること。さらに、その物理現象がModelicaによる方程式ベースのモデリングに適していることです。

これらは特殊なケースに限られた条件ではなく、多くの実際のエンジニアリングプロジェクトで満たされる前提条件です。そして、その条件が揃うのであれば、同じツールチェーンを適用できます。

この仕組みは、Modelica、FMI、Python、MCPといったオープンスタンダードを基盤として構築されているため、すでにModelon Impact上では、データセンター冷却だけでなく、熱マネジメント、パワートレイン、HVAC、車両ダイナミクスなど、さまざまな分野のライブラリに対して同じワークフローを適用できます。分野ごとに変わるのはライブラリの内容であり、フレームワークそのものは変わりません。

もしAIエージェントがベンダーのPDF仕様書から、検証済みの7.4MW冷却システムモデルを半日で構築できるとしたら、次に考えるべき問いはこうです。

「あなたの組織にある参照設計の中で、同じアプローチによって自動化・効率化できるものは何でしょうか?」

References

Schneider Electric. Reference Design 108: 7.4 MW Tier III AI Reference Design (NVIDIA GB200). 2024. https://download.schneider-electric.com/files?p_enDocType=Other+technical+guide&p_File_Name=RD108DSR7-GB200.pdf&p_Doc_Ref=RD108DSR0

Schneider Electric. Modular Data Center AI Reference Design EU — Reference Design 48. 2023. https://download.schneider-electric.com/files?p_enDocType=Other+technical+guide&p_File_Name=Modular+Data+Center+AI+Reference+Design+EU+FINAL.pdf&p_Doc_Ref=RD48DSR0_EN

Anthropic. Model Context Protocol Specification. 2024. https://modelcontextprotocol.io/

Modelon AB. Modelon Impact: cloud-based system simulation platform. https://modelon.com/modelon-impact/