「AIにレビューさせています」という言葉を、最近よく聞くようになりました。ドラフトを渡して、事実誤認や誇張がないか、論理が破綻していないかをチェックさせる。便利ですし、実際に役立ちます。

ただ、これは LLM の使い方として 半分 しか合っていません。

LLM に文章を読ませて意見を求める操作と、文章の根拠になったデータや引用元に 実際に立ち返って確認する 操作は、似ているようでまったく別のものです。そして後者でなければ絶対に捕まえられない誤りが、実際に存在します。この記事では、直近で公開した性能検証記事の制作過程で実際に起きたことをもとに、その違いを具体的に見ていきます。

「レビューさせる」と「検算させる」は別の操作

まず言葉を整理しておきます。LLM の検証能力に関する2026年の論文が、評価者としての役割を Judge（判者） と Verifier（検証者） という2つの言葉で明確に区別しています。

By definition, a judge is one who forms an overall opinion and assigns a decision, whereas a verifier is one who confirms the truth or correctness of something and requires more detailed evaluations.1

日本語にすると、Judge は「全体を見て意見をまとめ、判定を下す者」、Verifier は「物事の真偽・正確性を確認する者であり、より詳細な検証を必要とする」となります。この語彙の区別自体、2026年に入ってから明確化されたばかりで、日本語ではまだ定着していません。

「AIにレビューさせる」という運用の大半は、この Judge の使い方です。ドラフト全体を読ませて、「ここの論理がおかしい」「ここは誇張だ」と意見を言わせる。これはこれで有用ですが、文章の中で完結する操作です。

一方の Verifier は、文章の外に出て、その文章の根拠になった 一次のソース に戻って確認する操作です。生ログを再集計する、引用元の原文と本文の数値を突き合わせる。文章だけを読んでいては絶対にできない作業です。

本記事ではこれを 検算 と呼びます。

きっかけ:前回の記事で、自分の分析に複数の訂正が入った

直近で公開した ローカル LLM の性能ブレを追いかけた記事 では、公開前のレビュー工程で複数の自己訂正が発生しました。GPU のクロックに関する読み違いや、律速要因についての言い過ぎなど、記事本文にもそのまま「ここは私が最初に読み違えたところで」と書いた箇所があります。

訂正の中身そのものは前回の記事で明かしているので、ここでは繰り返しません。この記事で扱いたいのは一段引いた問いです。その訂正は、そもそもどうやって見つかったのか。

答えを先に言うと、見つかり方は一様ではありませんでした。ある誤りは文章を読むだけで決着し、ある誤りは生ログを検算してようやく確定し、そしてある誤りは、そもそも文章を読むだけでは疑う余地すら生まれませんでした。この違いこそが、「レビューさせる」と「検算させる」を使い分けるべき理由です。

「検算」の中身:一次ソースに戻って確認するという操作

検算と一口に言っても、実際にやった操作は2種類ありました。

1つ目は、生データの再計算です。 文章の根拠になった生ログをそのまま LLM に渡し、そこから集計を最初からやり直させる。今回の場合は、powermetrics の8分間・74サンプル分の生ログをまるごと渡し、GPU の P-state 別の滞在時間を再集計させました。

これはコスト・スケーラビリティの観点からも支持できるやり方です。LLM に集計値を直接答えさせるのではなく、集計処理そのものをコードとして生成・実行させ、結果だけを受け取るという設計は、データ分析の実務記事でも紹介されています。

One way around this is to instead perform the analysis by having the LLM generate the code for the task. For example, if the user asks for a count of records in a dataset, have the LLM generate a snippet of Python to count records in the raw data, execute it, and pass that information back to the user. This requires far fewer tokens compared to passing in the raw data to the LLM.2

念のため補足すると、この記事の論拠は「LLM は算術が苦手だから精度が出ない」という正確性の話ではなく、「生データをそのまま渡すとトークンを大量に消費するので、集計はコード実行に任せたほうが安い」というコスト・スケールの話です。ただ、目的は違っても「集計値を LLM の暗算に任せず、生データに対して計算をやり直させる」という設計そのものは共通しています。

2つ目は、引用・出典の実在確認です。 文章中に「〜という数値がある」と書いてあるとき、その数値が実際に引用元の原文に存在するかどうかを、原文に戻って突き合わせる操作です。こちらは集計をやり直すわけではありませんが、「文章の記述だけで判断せず、一次のソースに戻って確認する」という点では同じ検算の一種です。

この2種類目の検算が、次に説明する誤りの発見につながりました。

実際に見つかった3つの誤り

前回の記事の制作過程では、性質の異なる3つの誤りが見つかりました。並べてみると、「文章のレビューだけで済んだもの」から「検算でなければ絶対に見つからなかったもの」まで、はっきりとしたグラデーションになっています。

文章の論理チェックだけで完全に決着した誤り

最初の誤りは、生ログを開く必要すらありませんでした。

草稿には「SSD の読み出しが律速要因であることの直接的な実測証拠」という記述がありました。しかし、実際に計測していたのは CPU 電力・GPU 電力・熱の3項目だけで、ディスク I/O(読み出しレイテンシ・IOPS・帯域)はそもそも一切計測していませんでした。

「何を計測したか」という前提と、文章の主張を突き合わせるだけで矛盾が確定します。生データを1行も見なくても、文章とその前提を照らし合わせるだけで完結する、純粋な論理チェックです。最終的な記述は「作者の説明と整合する観測(ただし I/O 側は未計測)」に格下げされました。

文章では違和感止まりで、確定には検算が必要だった誤り

2つ目の誤りは、もう少し込み入っています。

草稿には「クロックは約600MHzまでしか上がらない」という記述がありました。レビュー段階でまず指摘されたのは、「階梯の最上段ラベルが1296MHzなのか、実際に1296MHzに到達したという意味なのか、この書き方では読み手が判別できない」という 文章表現上の違和感 でした。

ただ、この時点ではどちらの読みが正しいかは決着しません。実際に powermetrics の生ログを P-state 別に再集計してはじめて、正しい実態が確定しました。

負荷区間69サンプルのうち、1296MHz への滞在は全サンプルで発生していました。 ただし平均滞在率はわずか2.17%です。GPU HW active frequency として報告される値(この区間の中央値で614.0MHz)は、6段に分かれた P-state への滞在時間で加重した平均であって、上限ではありません。前半・後半で比較すると631.7MHzから605.9MHzへと約4.1%低下してもいますが、これも「上がらない」のではなく「一瞬だけ全開になってすぐ落ちる」という動き方の反映でした。

つまりこの誤りは、文章を読むだけで「何かがおかしい」という端緒こそ得られたものの、どちらが正しいかを確定させたのは生ログへの検算でした。 1つ目の誤りとの違いはここです。文章の中だけでは決着しない。

検算でなければ、そもそも疑う余地すら生まれなかった誤り

3つ目が、本記事で最も伝えたい誤りです。

企画の初期段階でまとめたメモには、次のような記述がありました。

read レイテンシは、M2 で 83ms/token に対し M5 Pro では 12ms。合計は 163ms/tok vs 30ms/tok

この記述には、どのコメントから拾った数値なのかという出典の紐付けがありませんでした。そして詳細調査の段階で実際に確認できたのは、まったく別の Hacker News のコメントの、次の一文だけでした。

The full route changes almost every token. The cache works through partial reuse, about 40% of experts repeat on the next token and 57% within two tokens, cutting I/O from 166 to 88 ms/token on M2 Mac.3

ここにあるのは「166ms/token から88ms/token に下がる」という一点のみです。163 も 30 も、この原文には一切登場しません。

にもかかわらず、設計段階の文章には次の一文が生成されていました。

M2 では合計163ms/tokenのうち88msがI/O(約54%)。M5 Proでは合計30ms/token

これは何が起きたかというと、検証済みの数値である「88」を、出典不明の未検証の数値「163」の内訳として勝手に接続し、そこから「約54%」という比率を 自分で算出していた のです。単なる書き写しミスではなく、別々の場所にある数値を組み合わせて、もっともらしい新しい主張を作り出してしまっていました。

そして、この文章はとても自然に読めます。「合計のうちI/Oが占める割合」という体裁で、数字の整合性にも違和感がありません。文章の論理だけを追っている限り、疑う理由がどこにもないのです。実際、この記述は何度かのレビューを通過していました。発覚したのは、脚注に掲げた元コメントの原文に実際に戻り、本文の数値と1つずつ突き合わせるという検算の段階でした。

この種の誤りには、学術的にも近い呼び名があります。LLM が生成する引用の正確性を検証した論文は、ハルシネーションを2種類に分類しています。

Intrinsic hallucinations are those that are inconsistent with the information provided in the input prompt or context.4

論文が挙げている例は、「参加者は150人」としか与えられていないのに、そこから「男性120人・女性80人」という男女内訳を勝手に捏造してしまうケースです。今回の「88という検証済みの数値から、163という内訳を捏造した」操作と、構造的にまったく同じです（総称は “total fabrication” ではなく、この論文が定義する intrinsic hallucination です)。

なぜこの誤りだけ、レビューでは見つからないのか

3つの誤りを並べて見えてくるのは、検算がどれだけ深く関与したかという段階の違いです。1つ目は文章の論理チェックだけで決着し、2つ目は文章が違和感の端緒を与えつつも確定には生ログの検算が必要で、3つ目に至っては文章に違和感の端緒すら生まれませんでした。

理由は Judge と Verifier の視点の違いに戻ります。Judge が見ているのは「文章として筋が通っているか」というもっともらしさです。3つ目の誤りの文章は、まさにもっともらしく整った文章として書かれていたため、文章レビューはこれを自然な記述として通してしまいます。

先ほどの分類の論文は、もう1つの型(存在しない URL や人物名のような、完全な作り話にあたる extrinsic hallucination)については “clearly non-authentic strings”、つまり明らかにそれとわかる不自然な文字列として現れやすく、検出しやすいと述べています。一方で intrinsic hallucination は “plausible-sounding but incorrect”、もっともらしく聞こえるが実際には誤っている、と表現されており、人手による検証が必要だとしています4。3つ目の誤りはまさにこの型で、文章の読み直しだけでは気づきにくく、原典と照合する検算が有効な手立てになります。

ここで一般化の範囲には注意が必要です。今回確認できたのは1つの記事・1件の実例にすぎません。「検算でなければ絶対に見つからない」と断定するつもりはなく、これはあくまで筆者の見立てです。ただ、レビューを何周重ねても見つからなかった型の誤りが、原典への検算で見つかったという事実と、intrinsic hallucination の検出困難性という研究上の指摘は、方向としては重なっています。

この考え方は、実はすでにある規範の延長

検算という発想自体は、まったく新しいものではありません。障害対応のポストモーテムを書く実務では、以前からこう言われています。

Every statement in the root cause section should be traceable to a specific log line, metric, or timestamp. If it’s not, it’s inference.5

根本原因に関する主張は、すべて具体的なログ行・メトリクス・タイムスタンプに遡れるべきで、そうでなければそれは推論に過ぎない、という指摘です。この規範自体は、ポストモーテムを書くエンジニアの間ではそれほど目新しいものではないはずです。

問題は、それを実行する具体的な手順を持っている人がまだ少ないことです。「主張は一次情報に遡れるべき」だと知っていても、実際に手元の文章の主張ひとつひとつを生ログや引用元に戻って確認する作業は、手間がかかるので後回しにされがちです。LLM に生データを渡して再集計させるという操作は、この「知っているけれどやっていない」規範を、実行可能な手順に変える1つのやり方だと言えます。

今日から試せること

読んでいただいた分析資料やポストモーテム、比較レポートが手元にあれば、試せることは単純です。

その中から、「全体を通じて」「最大で」「〜回とも」「約〜%」のような、数値を伴う断定的な一文を1つ選んでください。その一文の根拠になったはずの生ログや生データファイルを特定し、LLM に文章と生データの両方を渡して、「この一文の数値は、このデータから実際に導出できるか。生データに戻って計算し直してほしい」と指示してみてください。

もう1つ、脚注や参考文献として数値を引用している箇所があれば、その元コメントや元資料の原文に実際に戻って、本文の数値と一致するかを確認してみてください。今回の3つ目の誤りのように、検証済みの数値と未検証の数値が接続されて、もっともらしい新しい数字が生まれていないとも限りません。

おわりに

「AIにレビューさせています」という運用は、LLM を Judge として使っているに過ぎません。それ自体は否定しませんが、文章の根拠になった一次のソースに戻って確認する Verifier としての使い方は、まだ別の話です。そして後者でなければ捕まえられない誤りが、実際に存在します。

検算という運用を組織のレビュー・執筆プロセスに組み込むご相談があれば、コンタクトフォーム からお気軽にお問い合わせください。

Footnotes

  1. LLM-as-a-Verifier: A General-Purpose Verification Framework (arXiv:2607.05391) ↩

  2. Reframing LLM ‘Chat with Data’: Introducing LLM-Assisted Data Recipes (Towards Data Science) ↩

  3. Show HN スレッドの投稿(expert の再利用率) ↩

  4. Picazo-Sanchez, P., Ortiz-Martin, L. “Evaluating the Integrity of LLM-Generated Citations.” Data 11(5), Article 122 (2026)。MDPI 掲載の学術論文（自動アクセス制限のためリンクは省略）。 ↩ ↩2

  5. Your Postmortem Root Cause Is Probably Wrong, Here’s How to Know (Medium) ↩