LLM（大規模言語モデル）やAIエージェントを活用した開発・自動化パイプラインの導入が進む中で、多くのチームが「コードレビューの自動化」や「文章品質ゲート」の導入に取り組んでいます。

しかし、厳格な品質レビュー工程を設けて通過させたはずの技術レポートや開発ドキュメントにおいて、「根拠となっている一次計測ログ（生ログ）を誰も検証していなかった」 という構造的な穴が存在することに気づいているでしょうか。

本サイトの連載では、これまで AIパイプライン振り返り や 敵対的検証ゲート、自動化パイプライン構築 を通して、「自動化ゲートがどのような不備や誤りを検出してきたか」の実例を報告してきました。また 文章をレビューさせるな、ログを再集計させろ では、同じ powermetrics-8min.log の再集計事例をもとに、発見された個々の誤りが「文章レビューだけで決着したか」「検算まで必要だったか」という誤りの性質の違い を扱いました。

本記事が扱うのは、それらとは別の問いです。個々の誤りの性質ではなく、「そもそも、その生ログを検証する工程は、パイプラインのどこにも所有されていなかった」 という、検査対象の設計そのものに空いていた構造的な穴を主題とします。まとめ文章の論理整合性をいくら高めても、集計元の生ログの解釈が誤っていれば真逆の主張がまかり通ってしまうという、品質保証のブラインドスポット（盲点）について解説します。

1. 実例: 276KBの生ログを再集計して見えた「真逆の結論」

まず、実際に私たちの開発・執筆パイプラインの中で発覚したリアルな実例を紹介します。

過去に実施した「ローカルLLM推論検証」のレポート設計段階において、執筆担当エージェントは計測ログをもとに以下のような要約主張を作成し、レビューに提出していました。

「74サンプルの計測を通じて、最上位P-state（動作周波数階梯）は 1296 MHz に留まっている。クロックが最上位の半分程度までしか上がらないため、推論速度のボトルネックはGPUプロセッサ上限の低さにある」

このまとめ文章は、文脈としても論理展開としてもきわめてスムーズであり、レビュアー（人間およびAI審判）の一次チェックを不自然さなく通過しかけていました。

しかし、検証フェーズにおいて根拠となった 276KB の生ログファイル（powermetrics-8min.log）を直接プログラマティックに再集計・検算したところ、驚くべき事実が判明しました。

生ログの再集計数値とギャップ

  • 計測環境: MacBookPro18,3 (M1 Pro / 14コアGPU / 16GB RAM)
  • ログ仕様: powermetrics-8min.log (ファイルサイズ: 276KB / サンプル数: 74 / サンプリング間隔: 5,000ms / 観測時間: 6分06秒)
  • 実際の再集計数値（計測全時間に対する内訳）:
    • 74サンプル中 69サンプル（約93.2%） で 1296 MHz の active residency > 0%（常時到達）
    • GPU P-state 階梯別平均滞在率: 389 MHz (25.45%), 486 MHz (13.13%), 648 MHz (18.75%), 778 MHz (17.50%), 972 MHz (6.58%), 1296 MHz (2.03%)
    • GPU Idle（非稼働率）: 16.56%（上記全稼働階梯の合計 83.44% に対する残存割合）
    • Active Frequency（時間加重平均クロック）: 約 609 MHz

主張の反転と真の原因

生ログの数値を正確に集計すると、「74サンプル中69サンプルで最上位 1296 MHz に到達している」ことがわかります。

つまり、「上限クロックが低く抑えられていて到達しない」のではなく、「最上位 1296 MHz には問題なく到達しているが、I/O待ちによる Idle (16.56%) や低周波数階梯と交互に稼働するため滞在時間が短く（2.03%）、加重平均クロックが約609MHzに低下していた」 のが真実でした。

文字通りの事実（「1296 MHz という数値が出現している」）から「1296 MHz に制限されている」という正反対の推論が導かれ、それが要約テキストとして整形されていたのです。

2. 構造的盲点: レビューが見ているのは「文章」であって「生ログ」ではない

なぜ、複数層の品質レビューや自動検証ゲートを設けていたのにもかかわらず、このような「主張の真逆化」が見過ごされそうになったのでしょうか。

そこには、既存のコードレビューやAIレビューツールが持つ構造的な盲点が存在します。

レビューツールの限界

  1. 検査対象が「テキスト表現」に偏っている: コードレビュアーやAI（LLM）審判が評価するのは、提出されたテキストの「文法」「論理の一貫性」「フォーマット」「事前プロンプトへの追従性」です。まとめ文章の内部で閉じた論理矛盾がない限り、文章レビューは合格判定を出してしまいます。
  2. 生データとまとめ文章の間の乖離を検出できない: 集計ロジックの誤り、集計範囲（全サンプルなのか平均値なのか）の誤解、全称記号（「すべてのサンプルで」）の誤用は、生データとまとめ文章の双方を直接突き合わせて再計算しない限り、テキストだけから検出することは原理的に不可能です。
  3. 一次データの所有権・検証責務の欠如: 当時の私たちのリポジトリにおいて、エージェントの指示書やCI/CDパイプラインのスキル定義を検索したところ、計測ログ（一次データ）自体の正確性をチェックする命令は ヒットゼロ でした。生ログは「どこにも所有者が存在しない成果物」として放置されていたのです。

3. 一次データを品質ゲートの検査対象に組み込むアプローチ

この盲点を克服し、根拠データの信頼性を担保するためには、「文章の推敲」とは別に 「一次データの自動検算・追試プロセス」 を開発パイプラインに組み込む必要があります。

1. 一次検証ログと生データの保持（追試性の設計）

実機検証やパフォーマンス計測を伴う開発レポート・技術記事では、検証環境や集計結果を記録した一次検証ノート（hands-on-log.md 等）と、元となる生ログ（powermetrics の出力等）1 を同一リポジトリ・同一ディレクトリ内に保存することをルール化します。

第三者や自動化スクリプトがいつでも生ログから数値を再現（追試）できる状態を作ることが第一歩です。

2. LLM as Verifier（文章の審判ではなく「検算機」としての活用）

LLMを品質ゲートに組み込む際、単に文章を読ませて「この表現でよいか」を判定させる（LLM as Judge）だけでは不十分です。

一次生ログのテキストやCSVデータをPythonスクリプトやLLMコード実行機能に直接投入し、「本文中に記載された数値（平均値、最大値、パーセンテージ）が生ログから正しく計算されているか」を自動再計算・照合させる「検算機 (Verifier)」 として位置づけます。

# 一次生ログの検算スクリプト例（概念コード）
def verify_log_metrics(log_filepath, reported_avg_freq, reported_max_pstate):
    samples = parse_powermetrics_log(log_filepath)
    actual_max = max(s.gpu_pstate for s in samples)
    actual_avg = calculate_weighted_active_freq(samples)
    
    assert reported_max_pstate == actual_max, f"最上位クロックの不一致: {reported_max_pstate} vs {actual_max}"
    assert abs(reported_avg_freq - actual_avg) < 5.0, f"平均クロックの乖離: {reported_avg_freq} vs {actual_avg}"

人間の直感やAIのテキスト解釈を盲信せず、コードや数値データで裏を取るプロセスを品質ゲートの最前線に置くことで、データの読み違いによる事故を未然に防ぐことが可能になります。

4. まとめと今後の展望

「CI/CDやAIレビューの品質ゲートを整備したから安心だ」という考え方は、時に大きな盲点となります。どれだけ堅牢なゲートを構築しても、そのゲートが 「文章やコードの表面的な形式」 しか検査していなければ、根拠となる一次データの解釈誤りやすり替わりを防ぐことはできません。

  1. 検査対象の範囲を再点検する: 自分のチームのレビュー工程が「まとめ文章」だけを見ていないか点検する。
  2. 一次データと生ログの所有権を明確にする: 追試可能な形で生データを保存し、パイプラインの所有成果物として定義する。
  3. 自動検算（Verifier）を導入する: テキストの整合性確認とは別に、生ログからの数値再集計ステップを設ける。

「ゲートが何を検出したか」だけでなく「ゲートの検査対象に入っていないデータは何か」を意識することが、真に信頼できる技術情報・システム開発を実現する鍵となります。

AI開発パイプラインの品質保証や自動化プロセスの設計に関するご相談・お問い合わせは コンタクトフォーム まで。

Footnotes

  1. PowerMetrics Command: Gather and display CPU and power usage stats in macOS - ss64.com ↩