【ITニュース解説】Your verification tool reports what it saw, never where it didn't look

システムエンジニアとして働く上で、私たちが開発したシステムが正しく動いているかを確認する「検証」という作業は非常に重要だ。しかし、この検証作業は思った以上に難しく、一見完璧に見える検証をしても、重大な欠陥を見過ごしてしまうことがある。あるITニュース記事では、まさにその落とし穴について、動画制作パイプラインでの実体験を通して深く掘り下げている。

記事の筆者は、短いスクリプトから地図アニメーション動画を生成し公開するシステムを運用していた。動画が完成すると、自動チェック5項目と手動チェック7項目を含む計12項目の検証プロセスを経て公開される。初期の5つの動画では、この12項目全てが問題なくパスし、公開された。しかし、後にこれらの動画を改めて監査したところ、驚くべきことに4つもの欠陥が発見されたのだ。その中には、動画の主要な主張を台無しにするような重大な欠陥や、根拠のない数値が表示されているという問題も含まれていた。

検証チェックは「嘘をついていなかった」と筆者は言う。それぞれのチェックは、自身が「見た」範囲については正確に報告していた。問題は、チェックがパスしたという報告が、そのチェックの「視野外」にある全てのことについて沈黙している点だ。そして、この「沈黙」が、全てが問題ないという誤った解釈を生んでしまう。

この経験から、検証における欠陥の見落としには、主に三つの異なる種類があることが明らかになった。

一つ目の問題は「そもそも見ていなかった場所」で欠陥が発生していたというケースだ。筆者の動画検証では、動画から一定間隔でフレームを抽出し、それらを並べて目視確認していた。しかし、この固定間隔のサンプリングは、たまたま特定の重要なアニメーション効果が発生する瞬間を常に避けてしまい、その結果、肝心な部分が検証の対象から外れていた。この問題に対し、アニメーションのイベント発生時に合わせてフレームを抽出する「イベント駆動型サンプリング」という、より正確な方法が提案された。しかし、詳細に調べてみると、多くの種類のエフェクトがイベントを発しないことが判明し、もしこの新しい方法だけを採用していれば、実際に見つかった欠陥の多くは検出できなかったどころか、以前よりも多くの欠陥を見落としていた可能性があった。

ここから得られる教訓は、検証ツールや方法が「何を見ているか」だけでなく、「何を見ていないか」を明確に把握することの重要性だ。検証がカバーしている範囲と、そうでない範囲を明確に示す情報、いわゆる「カバレッジ情報」を常に意識し、必要であればその情報を検証結果と合わせて出力するように設計する必要がある。

二つ目の問題は「見たけれども、その情報源では正しい答えが得られなかった場所」で欠陥が発生していたというケースだ。例えば、動画に表示された数値ラベルを見て、筆者はそれが静的な説明文だと誤解したが、実際はカメラのズームに合わせて動的に変化する「カウントアップ」の数値だった。この数値は「海岸線パラドックス」というテーマを表現するための意図的なもので、仕様書を最後まで読んでいれば誤解はなかった。また、あるイベント名からそのイベントの動作を推測したが、実際のコードの定義は全く異なる意味を持っていたという事例もある。

このタイプの問題は、画面に表示されている情報（フレーム）、コードに書かれた仕様（スキーマ）、元データ（ソースデータ）というように、異なる媒体で表現されている情報を混同することで発生する。ある媒体から得られた情報で、別の媒体にまつわる疑問の答えを導こうとすると、誤った結論に至りやすい。この場合の解決策は、より多くの情報をスキャンすることではなく、「答えがどこにあるべきか」を理解し、適切な情報源（コード、仕様書、データ変換の仕組みなど）を参照することだ。

三つ目の問題は「見ることができたはずなのに、構造的に見ないように誘導されていた場所」で欠陥が発生していたというケースだ。筆者の動画では、マーカーのテキストがアニメーションの特定のタイミングで画面の端にクリップしてしまう欠陥があった。この欠陥は、ほぼ毎秒のように発生していたにもかかわらず、固定間隔のフレーム抽出方法が、欠陥が可視化される瞬間を常に避け続けていたため、何週間も発見されなかった。これは、動画で車の車輪が逆回転して見える現象と同じ「エイリアシング」という問題だ。

この問題の解決策は、検証の対象範囲を広げたり、情報源を変えたりすることではない。動画のように周期的な動きをする要素に対しては、単に固定間隔でサンプリングするのではなく、欠陥が発生しやすい「特定のフェーズ（例: アニメーションのピーク時、開始直後）」を意図的に狙ってサンプリングするような設計に改善する必要がある。

これらの三種類の欠陥は、検証レポート上では全て「パス」という同じ緑色のチェックマークとして表示されるため、問題の種類を誤って認識し、的外れな修正提案をしてしまう危険性がある。

さらに記事では、複数の開発者による「相互チェック」が、かえって問題を増幅させる可能性も指摘している。筆者がルーラーの誤診を同僚に伝えた際、同僚はその誤った前提を疑うことなく受け入れ、その前提に基づいて新たな検証設計を始めてしまったのだ。このように、前提を共有した上でのチェックは、独立した検証ではなく、単なる「間違いのコピー」になりかねない。この教訓として、議論の根幹となる情報については、要約ではなく「原文や定義そのもの」を共有することが重要だと述べている。この問題は、AIによる情報要約ツールなど、人間以外の「要約者」が介在する場合にも起こりうる。要約は、複数の真実の断片を組み合わせて一つの誤った前提を作り出すことがあるため、常にその情報が信頼できる「証拠」に基づいているかを確認する必要がある。

そして、最も重要な教訓の一つは「システムがチェックをパスすること」と「その情報が追跡可能であること」は全く異なる事象だということだ。動画中に表示された根拠不明な数値の例では、最終的にそのうち2つは正しいと判明したが、一つは追跡不能だった。しかも、正しいと判断された数値も、実は測定方法によって値が変わる可能性があるという、動画のテーマと深く関わる曖昧さを含んでいたのだ。チェックをパスしたからといって、それが無害だと判断するのは早計であり、その情報の出所や根拠をきちんと追跡・確認する姿勢が不可欠だ。

これらの問題は、動画制作の現場だけでなく、IT開発のあらゆる場面で共通して見られる現象だ。例えば、テストカバレッジが92%だと報告されても、残りの8%だけでなく、テストが全く書かれていない機能についてはその数字に含まれない。監視ダッシュボードが全て緑色でも、監視対象外の部分で障害が起きている可能性もある。型チェッカーがエラーなしと報告しても、データ入出力部分の型定義の漏れによって誤ったデータが流れる可能性もある。

したがって、システムエンジニアとして、どんなに優れた検証ツールやプロセスを使っていたとしても、「全てパスした」という結果を見たときに、常に次の三つの問いを自問自答する習慣が重要だ。

一つ目は、このチェックの「分母」、つまり検証の対象となった全ての候補セットは何だったのか？　何が検証されなかったのか？を明確にすること。

二つ目は、私が今観察している情報源（画面、ログ、要約など）は、私の疑問に対する「真の答え」を含んでいる情報源なのか？　その情報源が正しいかどうかを判断するためには、コードや仕様書といった別の情報源を参照すべきではないか？と考えること。

三つ目は、私が作成したり、他者から受け取ったりした要約や前提が、そのまま他者や自分自身の誤った判断の基盤になっていないか？　重要な情報については、要約ではなく、一次情報や定義そのものを確認し、共有すること。

これらの問いを常に意識し、一つ一つの検証結果を深く掘り下げることで、私たちはより堅牢で信頼性の高いシステムを開発できるようになるだろう。