シミュレーションモデルの検証と妥当性確認

# シミュレーションモデルの検証と妥当性確認 ## 定義シミュレーションモデルの良さは、実システムの出力にどれだけ近い結果を出すかで測られる。モデルの開発では現実に関する多くの前提(assumptions)を置くため、良さの評価は2つの独立した問いに分解される。1つは「その前提は合理的か」を問う**妥当性確認(validation)**で、前提の現実代表性(representativeness)に関わる。もう1つは「モデルはその前提どおり正しく実装されているか」を問う**検証(verification)**で、実装の正しさに関わり、デバッグと同義とも言える。この2軸は独立であるため、モデルは「無効かつ未検証」「無効かつ検証済み」「有効かつ未検証」「有効かつ検証済み」の4象限のいずれかに位置しうる。前提が現実からかけ離れていても実装だけは前提どおり正しく動く「無効かつ検証済み」モデルが典型例として示される。モデリングとプログラミングを別の人(またはチーム)が担当する場合、モデリング担当が妥当性確認、プログラミング担当が検証の責務を負う(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 25 Analysis of Simulation Results]] §25.1)。検証技法は計算機プログラム一般のデバッグ技法の延長にあり、モデルの内容によらず一般に適用できる。トップダウン・モジュラー設計、アンチバグ(境界チェックやエンティティ計上の自動検査)、構造化ウォークスルー、決定的モデルでの検算、簡略ケースの実行、トレース、オンライングラフィック表示、連続性・退化・一貫性テスト、シードの独立性確認という技法群がある。一方、妥当性確認技法は前提・システムの内容に依存するため、あるシミュレーションで使った手法が別のシミュレーションにそのまま転用できるとは限らない。妥当性確認は前提・入力パラメータの値と分布・出力値と結論という3つの対象を、専門家の直感・実システムの測定・理論的結果という3つの拠り所と比較する作業として整理され、「完全に妥当性確認されたモデル」は神話であり、限られたシナリオでモデルが無効でないことを示すにとどまるとされる(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 25 Analysis of Simulation Results]] §25.1, §25.2)。 ## 横断的知見 - 本 concept は現時点で単一ソース([[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 25 Analysis of Simulation Results]])のみに基づいて作成された。[[研究方法論における妥当性概念]]が扱うアルゴリズムエンジニアリングの9種の妥当性概念(生態学的・設計・実装・外的・正当化・論理的・内的・構成概念・結論妥当性)とは、いずれも「意図した性質を実際に備えているか」という広い問題意識を共有するが、対応関係は単純ではない。本ページの verification(実装が前提どおり動くか)は[[研究方法論における妥当性概念]]の実装妥当性(implementation validity、実装が意図した設計を忠実に具体化しているか)に近く、本ページの validation(前提が現実を代表しているか)は同ページの生態学的妥当性(ecological validity、タスク・設定が現実世界を反映しているか)に近い対応が見て取れるが、この対応づけはどちらのソースにも明示されておらず、本項執筆時点での本ページ側からの推測にとどまる。両ソースを正式に突き合わせるには、[[研究方法論における妥当性概念]]の9分類が経験的シミュレーション研究にどう射影されるかの検討が要る。 - [[モデルの確実性検証]]が扱う機械学習モデルの確実性チェック(運用投入前にシステムを壊さないかを確認する一連のゲート)は、名称こそ近いが本ページの検証(verification、実装が意図どおりに動くという「正しさ」の確認)とは異なる。確実性検証は「モデルが安全に動くか」というシステム運用上の性質を問うのに対し、本ページの検証は「実装が前提を忠実に反映しているか」という正しさそのものを問う。両者は「モデル」という語を共有するが、前者は運用アーキテクチャの信頼性工学、後者はシミュレーションという計算方法論に属する別の問題であり、意図的に別ページとして立てた(1991年のシミュレーション文脈と2024年のMLOps文脈という時代・分野の隔たりも大きい)。 - **検証技法の1つ「シードの独立性」は、第26章のマルチストリーム設計指針があって初めて実行可能になる**: 本ページの検証技法(§25.1.11)は「乱数生成に使うシードの値は最終的な結論に影響してはならず、異なるシード値で似た結果が得られることを確認する必要がある」と述べるが、それを満たすシードをどう選ぶかの具体策には立ち入らない。[[乱数生成器]](第26章§26.7)はマルチストリームシミュレーションのシード選択指針(ゼロを避ける、単一ストリームを分割しない、重複しないストリームを使う等)を与えており、この指針に従って設計されたシミュレーションでなければ、そもそも「異なるシード値で似た結果が得られる」というシードの独立性テスト自体が意味を持たない。第25章が示す検証は結果として確認すべき性質(何を確かめるか)、第26章が示す指針は設計として満たすべき前提条件(どう作れば確かめられる状態になるか)であり、両者は検証対象と検証可能性の前提という対になる関係にある(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 25 Analysis of Simulation Results]] §25.1.11, [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 26 Random-Number Generation]] §26.7)。 ## 未解決の問い - 検証と妥当性確認の4象限モデル(無効×未検証・無効×検証済み・有効×未検証・有効×検証済み)は、モデリング担当とプログラミング担当が分業している場合の責務分担として示されるが、両者を1人のアナリストが兼務する典型的な状況で、この2軸をどう運用上分離して確認手順に落とし込むべきかは本章では扱われない。 - 妥当性確認の3つの拠り所(専門家の直感・実システムの測定・理論的結果)のうち、実システムの測定が「最も信頼でき望ましい」とされる一方で「実務上しばしば不可能」ともされる。実システムの測定が不可能な場合に専門家の直感と理論的結果をどう重み付けて組み合わせるべきかの指針は示されていない。 - 本ページが扱う「良さ(goodness)」の定義(モデル出力と実システム出力の近さ)は定性的な記述にとどまり、[[信頼区間]]が扱うような定量的な近さの基準(信頼区間による有意差判定など)と明示的には接続されていない。§25.2.2は第13章の統計手法を実システムとの比較に使えると述べるが、具体的にどの検定をどう適用するかまでは踏み込んでいない。 ## 関連 - source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 25 Analysis of Simulation Results]] / [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 26 Random-Number Generation]] - 概念: [[離散事象シミュレーション]](検証・妥当性確認の対象となるモデルの類型) / [[信頼区間]](妥当性確認で実測データと比較する際の統計的道具) / [[モデルの確実性検証]](名称が近いが異なる問題を扱うMLOps文脈の隣接概念) / [[研究方法論における妥当性概念]](妥当性概念のより広い体系。対応づけは未確定) / [[乱数生成器]](シードの独立性テストが前提とするマルチストリーム設計指針) - 実体: [[Raj Jain]] / [[The Art of Computer Systems Performance Analysis]] ## 出典 - Raj Jain, *The Art of Computer Systems Performance Analysis*, John Wiley & Sons, 1991, Chapter 25, §25.1-§25.2. - Raj Jain, *The Art of Computer Systems Performance Analysis*, John Wiley & Sons, 1991, Chapter 26, §26.7.