コードの検証とは何ですか？

解析プログラムが、意図した方程式を意図した精度で正しく解いているかを確かめる作業です。モデルが現実に合っているか（妥当性確認）や、個々の計算の誤差（解の検証）とは別に、まずプログラムそのものに誤りがないことを示します。厳密解や製造解と比べ、誤差が理論どおりの次数で減るかを確かめるのが中心です。

パッチテストとは何ですか？

有限要素法で、要素が表せるはずの簡単な解（1次要素なら1次式）を、ゆがんだ要素の集まりでも正確に再現できるかを調べる試験です。例では要素をゆがめても1 + 2x + 3y を誤差1.8×10⁻¹⁵（計算機の丸め誤差の大きさ）で再現しました。これに通らない要素は、格子を細かくしても正しい解に近づかないことがあります。

コードの検証でどんな誤りが見つかりますか？

係数の取り違え、一部の要素だけの計算ミス、境界条件の実装の誤りなどです。例では、ある範囲の要素だけ面積を半分に計算する誤りを入れると、パッチテストの誤差が0.23に跳ね上がり、収束次数も2から0に落ちました。見た目の結果だけでは気づきにくい誤りも、数字ではっきり分かります。

コードの検証（Code Verification）

カテゴリ: V&V・ASME規格 | 2026-10-01 改稿

CAE visualization for code verification theory - technical simulation diagram

コード検証（Code Verification）

理論：プログラムの正しさを数字で示す

概要

🙋

社内で開発した解析プログラムの品質を示してほしいと言われました。例題で『それらしい結果が出た』では足りないですか？

🎓

足りないね。小さな誤りは、結果を少しだけずらすので、見た目ではまず気づけない。コードの検証では、答えがわかっている問題で、誤差が計算機の丸め誤差の大きさまで小さくなるか、あるいは格子を細かくしたときに理論どおりの次数で減るかを確かめる。有限要素法なら、要素が表せるはずの解をゆがんだ要素でも正確に再現できるかを見るパッチテストが基本だ。数字で合否がはっきり出るのが大事なところだよ。

試験に使う問題

$$ \nabla^2 u = 0,\qquad u_{patch} = 1 + 2x + 3y,\qquad u_{order} = e^{x}\sin y $$

どちらもラプラス方程式の厳密解。1次式は1次の三角形要素で正確に表せるのでパッチテストに、指数と正弦の積は収束次数の試験に使う。

要素の剛性と誤差の測り方

$$ K^e = \frac{1}{4A^e}\,B^{T}B,\qquad \|e\|_\infty = \max_i |u_i - u(\mathbf x_i)|,\qquad p = \frac{\ln(e_{2h}/e_h)}{\ln 2} $$

$A^e$ は三角形の面積、$B$ は形状関数の勾配の行列。節点の誤差の最大値と、格子幅を半分にしたときの次数 $p$ を見る。

Coffee Break よもやま話

パッチテストの誕生

パッチテストは1960年代半ば、アイアンズらが板曲げの要素を開発する中で考え出した。当時、一部の要素は計算がきちんと動くのに、格子を細かくしても正しい答えに近づかないことがあった。アイアンズは、要素がいくつか集まった小さな『パッチ』に、表せるはずの簡単な状態（一様なひずみなど）を与え、それを正確に再現できるかで要素の正しさを判定する方法を示した。のちにストラングらが数学的な意味を整理し、今でも新しい要素や自作のプログラムを確かめる最初の試験として使われている。

計算例：小さな有限要素法のプログラム

例1：パッチテスト

単位正方形を6×6に分けた1次の三角形要素で、内部の節点を格子幅の最大30%ずらしてゆがめた。境界に 1 + 2x + 3y の値を与えて解くと、節点の最大誤差は1.8×10⁻¹⁵（丸め誤差の大きさ）。正しく実装されている証拠になる。

例2：収束次数の試験と、誤りの検出

指数と正弦の積の解で格子を細かくし、正しい実装と、x > 0.5の範囲の要素だけ面積を半分に計算する誤りを入れた実装を比べた。

分割数	正しい実装の誤差	次数	誤りのある実装の誤差	次数
4	5.8×10⁻⁴	—	8.8×10⁻²	—
8	1.6×10⁻⁴	1.86	1.0×10⁻¹	−0.21
16	4.1×10⁻⁵	1.98	1.0×10⁻¹	0.01
32	1.0×10⁻⁵	2.00	9.9×10⁻²	0.02

🙋

誤りのある実装は、格子を細かくしても誤差がまったく減らないんですね。

🎓

そう。面積を半分にすると、その範囲の要素だけ剛性が2倍になり、格子を細かくしても直らない『方程式そのもののずれ』になる。だから次数が0になる。同じ誤りで、パッチテストの誤差も0.23まで跳ね上がった。逆に言えば、パッチテストと次数の試験を通れば、少なくともこの種の誤りはない、と数字で言えるわけだ。大事なのは、これらの試験を自動化して、プログラムを変更するたびに必ず実行することだよ。一度通っても、後の変更で壊れることはよくあるからね。

コードの検証の進め方

パッチテスト（一様なひずみ・1次の温度分布など）で要素の基本を確かめる。
厳密解のある問題で、格子を細かくして理論どおりの次数が出るかを確かめる。
厳密解のない方程式や項は、製造解の方法で確かめる。
境界条件の種類・要素の種類・非線形の設定ごとに試験を用意する。
試験を自動化し、プログラムの変更のたびに実行して記録する。

Coffee Break よもやま話

「新しい版で結果が0.3%変わった」

社内の構造解析プログラムを改良した新しい版で、以前と同じモデルを計算したら、応力が0.3%だけ違った——という例がある。誤差の範囲だろうと見過ごされかけたが、自動化してあったパッチテストが1件だけ失敗していた。調べると、速くするために書き換えた要素の積分で、ゆがんだ要素のときだけ重みの取り違えがあった。0.3%は小さく見えても、パッチテストに落ちる誤りは格子を細かくしても消えない。数字で合否を判定する試験があったおかげで、出荷前に見つかった。

よくある間違い

間違いと対策

間違い	起きること	対策
それらしい結果で判断	小さな誤りを見落とす	数字で合否を判定
整った格子だけで試験	ゆがんだ要素の誤りが残る	ゆがんだパッチ
1つの格子で比較	次数の低下を見落とす	格子を細かくして次数
境界条件を試さない	境界の実装の誤り	種類ごとに試験
試験を一度きりで終える	後の変更で壊れる	自動化して毎回実行

🙋

関連する内容も知りたいです。

🎓

リチャードソン外挿ツールで次数を試せるよ。関連するページは製造解の方法、解の検証、RoacheのGCI、ASME V&V 10、NAFEMS LE1が参考になる。