正しい計算を二つつないでも、正しい答えになるとは限らない――PSC2026から考える「シミュレーションの受け渡し」

滋賀坂本余白書房別館

2026年10月1日 17:52

＜AIは難しいことを考えるのが大好きなようです。新しい概念を発明したと言っています。本当でしょうかね。＞
＜２０２６年１０月４日追記を最後にしました。Ozaki Scheme IIとOpenDLSS-NRです。＞

＜本文＞

2026年11月19日（木）、東京・大手町で「Prometech Simulation Conference 2026（PSC2026）」が開かれます。

公開されている講演一覧を見ると、テーマはかなりばらばらです。

トヨタ車体は、冠水路走行時の水撃荷重によって床下部品が受ける影響を扱います。Particleworksで流体側を解析し、MSC Nastranによる構造解析へつなぐ内容です。

JAXAは、航空機へ水滴が衝突し、凍り、氷へ変わっていく現象を扱います。公開概要では、水滴1個の解析から、複数の水滴をまとめたパーセル近似へ進む流れが示されています。

HYUNDAI MOBISは、高速回転するEVモーター内部で飛び散るオイルのParticle Simulationと、1D thermal Modelsを組み合わせます。

東京大学からは、粒子法と構造解析、さらにFVMとMPSという異なる計算方法を組み合わせる講演があります。公開概要では、構造解析との連成にOpenSees、FVMとの連成にOpenFOAMが使われます。

NVIDIAとプロメテックは、Particleworksの解析結果をOmniverseへ持っていき、AIエージェントを使って可視化開発を進める事例を紹介します。

車、航空機、モーター、粒子法、3D可視化。

一見すると別々の話です。

しかし、これらを並べてみると、一つの共通した問題が見えてきます。

「計算した結果を、次の世界へどう渡すのか」です。

計算は、一つの箱の中で終わらなくなった

昔のシミュレーションを、かなり乱暴に単純化すると、

一つの計算モデルを作り、その中で答えを出す

という姿を想像しやすかったと思います。

ところが現在のCAEは、そう単純ではありません。

流体で計算した圧力を構造解析へ渡す。

細かな水滴の計算結果を、もっと粗いモデルへ渡す。

粒子の流れを、1Dの熱モデルへ渡す。

粒子で表した世界を、格子で表した世界へ渡す。

解析結果を、3D可視化用のデータへ変換する。

つまり、一つの巨大な計算をするというより、

異なる計算をつないで、一つの仕事を完成させる

方向へ進んでいます。

ここで厄介なのが、両側の計算がそれぞれ正しくても、間の受け渡しまで正しいとは限らないことです。

たとえば、流体解析から構造解析へ圧力を渡したとします。

画面上ではきれいに圧力分布が載っていても、

全体として加わる力は同じなのか
瞬間的な衝撃の大きさは保たれているのか
細かい格子から粗い格子へ移したことでピークが消えていないか

は別問題です。

「数字が渡った」と「物理が渡った」は、同じではありません。

温度は同じでなくてもよい

ここでもう一つ、直感に反することがあります。

シミュレーション同士をつなぐなら、

境界で値を同じにすればよい

と思いたくなります。

ところが、必ずしもそうではありません。

たとえば二つの物体が接触して熱をやり取りするとします。

完全に密着していると仮定すれば、接触面の温度を同じとして扱える場合があります。

しかし実物には微小な隙間や表面の粗さがあります。

すると接触面の両側に温度差が残っていても、それ自体は間違いではありません。

大事なのは、

温度が同じかではなく、その温度差と熱の流れが、採用した物理モデルと矛盾していないか

です。

気体と液体の境界でも似たことが起きます。

表面張力があり、界面が曲がっている場合には、境界の両側で圧力が違うことがあります。

相変化があれば、熱の流れの差が蒸発や融解のエネルギーへ使われます。

つまり境界では、

何を同じにするかより、何を保存し、何の違いを許すか

を先に決めなければなりません。

粒子を格子へ渡すと、もう一つ問題が増える

粒子法では、さらに面白い問題が出てきます。

流体を小さな粒子の集まりとして計算しているとします。

次に、その結果を格子を使う別の計算へ渡します。

粒子は点です。

格子は空間を区切った箱です。

同じ現象を見ていても、世界の表し方が違います。

すると、

粒子Aの値を、格子のどこへ入れるか

という問題が生まれます。

一番近い格子へ入れるのか。

周囲の格子へ分配するのか。

いったん滑らかな場へ変換してから渡すのか。

この変換方法だけでも、結果は変わります。

粒子法の流体に限らず、固体粒子をDEMで表し、格子流体とつなぐCFD-DEMでも同じ種類の問題が現れます。

米国NETLのMFiXでは、DEM粒子の情報をEuler格子へ渡すための補間や平滑化に関する設定が公開されています。MFiX 26.1 User Guideでは、補間設定は4章 Model guideの紙面p.146付近、平滑化は12.1 Keywordsの「DES_DIFFUSE_WIDTH」の紙面p.293付近で確認できます。

これは単なるファイル変換ではありません。

「同じ物理を、別の表現へ翻訳する仕事」

です。

私はここを、Representation Interface――表現の境界として分けて考えるのがよいと思っています。

「何を守るか」は、データの種類によって違う

この問題をかなり分かりやすく見せている実装例が、オープンソースの連成ライブラリpreCICEです。

preCICEでは、異なるmesh間でデータを渡すときに、データの性質によってmappingの考え方を分けています。

たとえば力のように「全部足した量」が重要なら、合計値を保つconservative mappingを使います。

一方、温度や圧力のような場ではconsistent mappingを使います。

さらに、温度や速度のような量を補間しつつ、面積分・体積分、たとえば質量流量のような合計も守りたい場合には、scaled-consistentという考え方があります。

これを日常語にすると、

荷物によって、受け渡しのルールを変える

ということです。

100万円を別の箱へ移すなら、合計100万円が残っていることが大事です。

一方、温度分布なら、平均してしまって山と谷が消えると、元の分布の意味が失われます。

逆に、力をきれいな分布へ補間した結果、全体の力が増減してしまっても困ります。

つまり、

何を渡すかによって、「正しく渡せた」の意味が違う

のです。

五つの「つなぎ目」に分けて考える

この問題を整理すると、少なくとも五つに分けて見ることができます。

まず物理の境界です。

質量、運動量、エネルギーなど、何を守らなければならないのかを決めます。

次がモデルの境界です。

温度差を許すのか、滑りを許すのか、接触や相変化をどう表すのかを決めます。

三つ目が表現の境界です。

粒子から格子へ、3Dから1Dへ、細かな計算から粗い計算へ、どう翻訳するのかを決めます。

四つ目が計算手順の境界です。

二つの計算をいつ同期するか、何回やり取りするか、どちらを先に計算するかを決めます。

最後が証拠の境界です。

本当に正しく渡せたのかを、残差、総量、格子依存性、実験、標準問題などで確認します。

この五つを私は、まとめてInterface Guaranteeと呼んで整理しています。

既存の標準規格の名前ではありません。

異なる計算やモデルをつないだとき、

何を守るのか
何を変えてよいのか
どう変換するのか
いつ交換するのか
何を見て正しいと判断するのか

を一枚の見取り図へ置くための整理です。

PSC2026を見ると、「つなぐ仕事」が主役になっている

PSC2026のプログラムを、この視点でもう一度見ると面白くなります。

トヨタ車体の講演では、Particleworksで得た床下部品への水撃圧力を、MSC Nastranの構造解析へどう渡すのか、という問いが立ちます。

JAXAの航空機着氷では、一滴ずつ詳細に計算した世界から、多数の水滴をまとめた世界へ何を引き継ぐのか、という問いが立ちます。

HYUNDAI MOBISでは、モーター内部のオイル飛散を扱うParticle Simulationと1D thermal Modelsの間で、何を縮約して渡すのかが気になります。

東京大学のParticleworks SDKの講演では、OpenFOAMを使うFVMとMPSという異なる表現をどう接続するかがテーマになります。

NVIDIAとプロメテックの講演では、計算結果から可視化世界へ移るとき、単位、時刻、粒子ID、局所ピークなどがどう保たれるのかという問いが生まれます。

もちろん、公開された講演概要だけから、

各講演がこの五つを実装している

と断定することはできません。

むしろ逆です。

同じ物差しで質問できる場所が、これだけ増えている

ことが重要です。

シミュレーションの品質管理も変わる

これまでCAEの品質を見るときは、

方程式は正しいか
meshは十分細かいか
計算は収束したか
実験と合っているか

といった確認が中心でした。

もちろん、これらはこれからも重要です。

ただし複数の計算がつながる時代には、その間へもう一枚チェック表が必要になります。

たとえば、次のような問いです。

交換量：何を相手側へ渡すのか
保存：何の総量を守るのか
不連続：何が違っていてよいのか
表現変換：粒子・格子・1D・3Dをどう変換するのか
時間：いつ、何回交換するのか
証拠：正しく渡せたことを何で確認するのか

そして、これらを確認した外側で、最後に人が判断します。

判断：誰が受理、保留、再解析を決めるのか

この「判断」は五つのInterfaceそのものではなく、確認結果を受けて次の行動を決める外側の仕事です。

計算ソフトの画面には、きれいな色のコンター図が表示されます。

しかし、その絵がきれいだから正しいわけではありません。

本当に確認したいのは、

その絵に到達するまで、物理が途中で落ちていないかです。

AIが入るほど、この問題は大きくなる

ここから先は、CAEだけの話でもなくなります。

AIエージェントが解析条件を作る。

別のAIが計算を実行する。

計算結果を別のモデルへ渡す。

可視化AIがデータを間引く。

さらに別のAIが結果を読み、設計変更を提案する。

こうなると、一つ一つのAIが賢いかどうかだけでは足りません。

重要になるのは、

仕事から仕事へ渡るたびに、意味が保たれているか

です。

これは、AIエージェントの世界で権限や証拠を考えるときにもよく似ています。

部品や仕組みをつなぐこと自体はよい。

仕事も次へ渡してよい。

しかし、渡した瞬間に意味や保証まで自動的に引き継がれるとは限りません。

シミュレーションで「圧力」という名前が同じでも、中身の表現や意味が違うことがあります。

AIの仕事でも「承認済み」という言葉が同じでも、誰が何を承認したのかが違えば意味は変わります。

「つなげる技術」が進歩するほど、

つながったことではなく、何が保たれたか

を見る必要があります。

バトンを落とさないための技術

シミュレーションは、ますます速くなります。

GPUも使われます。

AIも入ります。

3Dモデルと1Dモデルが組み合わされ、粒子とmeshが行き来し、解析結果はリアルタイムに可視化されるようになります。

それでも最後に残る問題は、意外に地味です。

次の人へ渡したバトンは、本当に同じバトンなのか。

途中で軽くなっていないか。

形が変わっていないか。

渡すタイミングを間違えていないか。

そして、それを後から確かめられるのか。

PSC2026の一見ばらばらな講演を並べてみると、シミュレーション技術の次の競争は「もっと大きく計算すること」だけではないように見えます。

異なる計算を、安全に、意味を保ったままつなぐこと。

その「つなぎ目」こそ、これからのCAEで最も注意深く見る場所の一つになるのではないでしょうか。

参考資料

PSC2026の公開情報について

本稿は、PSC2026公式サイトおよび主催者が一般公開している講演タイトル・講演概要を参照してAIが執筆しています。

＜２０２６年１０月４日追記＞

補足：科学計算の中にも「つなぎ目」が見えてきた

Ozaki Scheme IIとOpenDLSS-NRから読む、Interface Guaranteeの計算機内部への拡張

元記事：正しい計算を二つつないでも、正しい答えになるとは限らない――PSC2026から考える「シミュレーションの受け渡し」　note.com/yohaku_bekkan/n/nea0879f455d6

この補足の位置づけ

この補足は、元の記事で整理した五つのInterface Guaranteeを増やすものではありません。Physical / Model / Representation / Solver / Evidenceという構造はそのままに、そのうちRepresentation・Solver・Evidenceで起きる問題が、計算機内部の実行経路にも現れ始めた、という追加事例です。 OpenDLSS-NRは科学計算そのものではありませんが、異なる物理実装から同じ数値結果を保つ対照例として扱います。

この記事を書いたあと、もう一段下の世界にも同じ問題があることに気づきました。

これまで考えていたのは、流体解析から構造解析へ、粒子から格子へ、といった「異なる計算をつなぐ場所」です。

ところが現在は、ひとつのシミュレーションの内部でも、「何を計算したいのか」と「実際にコンピューターでどう計算するのか」を分けて考える必要が出てきています。