「タイムアウト0件、合格」という結果が出た。だが、その数値は本当に測りたいものを測っていたか。
実機検証でもっとも見落とされがちなのは、対象システムの不具合ではなく計器（測定の前提）の誤りだ。
きれいな結果ほど疑われず、そのまま結論に変わりやすい。

「計器を疑う」という視点

パイロットが視界ゼロの気象条件で飛行するとき、コックピットの計器だけを根拠に操縦する。FAA（米連邦航空局）はこの飛行方式をIFR（Instrument Flight Rules）と定義している（FAA Pilot/Controller Glossary 2024年）。計器が正しいことを前提とした運用だ。

この話を逆にすると、ソフトウェア検証への応用になる。「計器が正しい」という前提を意識せずに検証結果を読むと、計器が狂っていても気づかない。「計器を先に疑う」というのは著者が航空のアナロジーを逆転させた言い方で、正式な学術用語ではない。ただ、実機検証の現場で繰り返しぶつかった構造を説明するのに、航空のアナロジーを逆転させた視点が有効だった。

SREやDevOpsのオブザーバビリティ文脈では、instrumentation（計器化）は「センサー・ゲージ・アラームの集合体でシステム状態を観測可能にする行為」を指す（SRE School 2026年）。その計器自体が誤った値を出していたら、オブザーバビリティは機能しない。

以下で、実機検証で実際に踏んだ4種類の計器の嘘と、それぞれへの対処を整理する。

計器の嘘1: 環境の汚染

前回の検証データが環境に残留していて、新しい測定が汚染される。典型的なのは「解決済み件数が投入件数を上回る」という数値が出るケースだ。物理的にあり得ない値なので、見た瞬間に気づけば問題ない。だが、きれいな数値の場合はそのまま通過してしまう。

対処：サニティチェックを先に走らせる。

サニティチェックとは、「主張や計算結果が正しい可能性があるかを素早く評価する基本テスト」（Wikipedia – Sanity check 2024年）だ。明らかに誤った結果クラスを除外するための確認で、IEEEやSEIの正式標準用語ではなく業界慣用語にとどまるが（Software Testing Help 2024年）、実務では有効なファーストステップになる。

チェック観点確かめること
あり得ない値件数の逆転、マイナス値、100%超え
前回データの残存ジョブテーブルに旧データが混在していないか
環境の初期化本当にクリーンな状態から始めているか

測定を始める前に、「この環境は本当に前回と切れているか」を確かめる。これが最初の手続きだ。

計器の嘘2: 指標の取り違え

「処理時間を測った」という記録が、実際には「キュー待ち時間＋実行時間」の合計だったというケースがある。見たかったのは実行時間だけなのに、待機時間が混入していると、数値の意味が変わる。

たとえばキューが詰まっている状況では総経過時間が長くなるが、実行自体は速い場合がある。反対に、キューが空いていれば見かけ上速く見えるが実行処理が重いこともある。指標の定義を事前に明示せずに測ると、「速い/遅い」の結論が的外れになる。

対処：測定対象の定義を測定開始前に書き留める。

「どこからどこまでを時間とするか」「何個のジョブを対象とするか」「並列度はいくつか」——これらを検証レポートの冒頭に書いておく。指標の定義は後付けにしない。

なお、このパターンの技術的な詳細（Dataverse非同期ジョブのキュー構造とタイムアウトの関係）は関連記事「async-timeout-diagnosis」を参照。

計器の嘘3: データ消失（成功ジョブの自動削除）

Power Platform（Dataverse）の非同期ジョブ処理で遭遇する、見落としやすい仕様がある。

Microsoft Learnの公式ドキュメントによれば、Dataverse AsyncOperationテーブルの成功済みシステムジョブは、デフォルトで30日後に自動削除される（Microsoft Learn 2025年）。失敗・キャンセルの場合は60日間保持されるが、成功ジョブの保持期間はそれより短い。

“All environments are configured with out-of-box bulk delete jobs to delete successfully completed workflow system jobs that are older than 30 days.”
— Microsoft Learn, Delete completed system jobs and process log

ジョブ状態デフォルト保持期間
成功（Succeeded）30日
失敗（Failed）60日
キャンセル（Cancelled）60日

この非対称性が問題を起こす。検証から時間が経った後にジョブテーブルを見ると、失敗ジョブは残っているが成功ジョブは消えている。「失敗だけが見えている」状態で分析すると、「成功した処理は速く、失敗した処理は遅い」という結論が出やすくなる。だが、成功ジョブが存在しないのではなく、消えているだけだ。

クラウドフローの実行履歴（FlowRunエンティティ）も同様にデフォルト28日保持（Microsoft Learn 2025年）。検証後の振り返りで「成功データがない」という状況が起きた場合、最初に疑うべきは自動削除の仕様だ。

対処：検証中にデータをエクスポートしておく。

  • 検証終了時点でジョブテーブルをCSV等にエクスポートする
  • または保持期間の設定を延長してから検証を始める
  • 後から「成功ジョブが見つからない」という状況を構造的に防ぐ

計器の嘘4: n=1の測定

1回だけ測定して境界値を決めようとすると、実際にはばらつきがある場所を点として固定してしまう。「このスレッド数で性能が変わった」という観察が1点だけの場合、それが境界なのか、たまたまそのときの周辺負荷のせいなのかが判別できない。

統計的に見ると、n=1では標本分散の計算式の分母（n-1）がゼロになり、信頼区間の計算が成立しない（Pearson Statistics Study Guide 2024年）。

学術文献でも同様の指摘がある。

“Current evaluation practices that rely on single generations (N=1) effectively treat outputs as deterministic point estimates… this approach is statistically unreliable.”
— arxiv, A Tale of Two Variances（2025年）

“When the local variance of metrics is large at a given condition, a single-seed endpoint report can be a poor estimate of the repeated-run mean.”
— arxiv, Within-Model vs Between-Prompt Variability in Large Language Models（2025年）

いずれもLLMベンチマークの文脈から出た知見だが、「1点の測定値で平均を推定することの限界」という構造は、クラウドシステムの負荷試験・PoC検証にも同様に当てはまる。

実務では、1点ではなく「ゾーン」として認識するアプローチが有効だ。たとえば「スレッド数50〜70の範囲で性能が変化する傾向がある」という認識に留め、特定の閾値に固定しない。統計的目安として、約30回の反復測定で平均と分散が安定してくることが知られている。Power Platform固有の推奨サンプルサイズの公的ガイドラインは現時点で存在しないため、これはあくまで一般的な統計的目安として参考にする。

対処：点ではなくゾーンで記録する。

  • 同条件で複数回測定して分布を確認する
  • 結果は「N点の平均 ± 標準偏差」または「観測範囲」で記録する
  • 境界として報告するなら「この条件での繰り返し測定で、おおよそX〜Yの範囲に収まった」という形式にする

測定を確かめる手順（結論を出す前のチェックリスト）

4種の計器の嘘をまとめると、以下の順序で確かめる手続きになる。

1. 環境の初期化を確認する（前回データが混入していないか）
2. 指標の定義を書き留める（どこからどこまでを何と呼ぶか）
3. サニティチェックを走らせる（あり得ない値が出ていないか）
4. データが存在するか確認する（自動削除で消えていないか）
5. 反復測定して分布を把握する（1点で境界を決めない）
6. 射程つきで結論する（この条件・この環境での観察である旨を明記）

この6ステップを検証レポートのテンプレートにしておくと、「測定は通ったのに本番で再現しない」という事後検討の起点として使える。

まとめ

検証の結論を左右するのは、対象システムの挙動より先に、測定の設計が正しいかどうかだ。きれいな数値が出たとき、その数値が「測りたかったものを測っている」かを先に確かめる——それが測定の前提を先に確かめる手続きの意味になる。

次の一歩：次回の検証・PoC・負荷試験の前に、上記6ステップを検証レポートの冒頭に貼り付けて使う。Dataverse環境を使う場合は、ジョブテーブルのエクスポートタイミングを検証計画に含めておく。

関連記事

  • [async-timeout-diagnosis]（リンク予定）——嘘2（指標取り違え）・嘘3（成功ジョブ消失）の個別技術例
  • [parallel-wont-beat-serial-bottleneck]（リンク予定）——嘘4（n=1がゾーンになる背景：負荷依存の非線形挙動）
  • [prod-safety-outside-in]（リンク予定）——「壊して確かめる設計」と「測定を先に確かめる」の補完関係

Power Platform全体の設計判断を体系的に整理したい場合は「Microsoft Power Platform 設計判断の全体像」（リンク予定）を参照。