自社サイトの改良を、外部の AI レビュー（同じレビュアー）に 1 日で 7 回かけました。採用した指摘は多い（1 回目だけで採用 22・修正採用 12）。ただ、「Hero の H1 が DOM で最後にある」という誤った指摘が 4 回続きました。本番の HTML を 3 通りで測って否定し、6 回目からは作業をやめました。

分かったのは 2 つです。同じレビュアーが H1 の位置という同じ観測対象について繰り返した 4 回の指摘は、独立した 4 件の証拠として合算できない（回答の数は証拠の量にならない）。7 回は対象の文書が回ごとに違うので、7 回答をまとめて「同じ状態を見せた」とは言いません。判断は「回数」ではなく「新しい証拠が増えたか」で行う。そして、前回と逆のことを言われたときは、レビュアー同士を戦わせず既決の文書の前提が壊れたかで裁く。

この記事の位置づけ（2026-09-26 追記）

この記事で新しく示すこと: 同じレビュアーへの 7 回の依頼のうち、H1 の位置という同じ観測対象について同じ誤りが 4 回続いたこと＝回答の数は証拠の量にならない。
当てはまる範囲: 同じ外部の AI レビュー・1 日・当方のサイトです。

数字の元データと再現の手順は、検証の記録（Lab）にまとめています。

7 回の一覧

対象は Astro の静的サイト 1 つ。当方が指摘を本番の HTML で測り、採否を決めて commit した。

回	対象	扱い	commit
1	サイト改良提案 49 節	採用 22・修正採用 12・棄却 6・本人裁定 6	改良書 V2
2	改良書 V2 の精査	線を 3 種に命名・価格を 1 か所に・Case の型など反映（件数は記録なし）	v2b
3	トップ評 P1 1〜8＋Hero 評 1〜9	否定 1（DOM 順）・既に済み 3〜4（記録の切り方で変わる）・採用 8／真 4・半分誤り 1・棄却に同意 2	`580bf03` `7ea860b`
4	公開版の見直し	否定 2（DOM 順 S×3・入口が見出しより前）・採用 5・据え置き 3	`d82ffa2`
5	同上	否定 1（DOM 順）・採用 4・既に済み 5・据え置き 2。⚠ 4 回目と逆向きの推奨 1 組	`bd0ba4d`
6	同上	否定 1（DOM 順・3 通りで計測）・残り 9 項目は反映済み	なし
7	統合版	今すぐ 5・Lab 側 5・据え置き 3（同意）	`da3168e`

⚠ 数え方: 「サイト（またはトップ）全体への評」を 1 回と数えた。同じ日に「動きの体系」だけを主題にした評が別に 1 回あり（採用 8・棄却に同意 4・未採用 3。DOM 順の指摘なし）、それを含めれば 8 回。

「DOM 順」の誤りは 3・4・5・6 回目の 4 回。4 回とも本文は少しずつ違うが、主張は同じ（Hero の見出しが文書の末尾にある／入口の一覧が見出しより前にある）。

3 通りで否定した

レビュアーが言う「H1 が DOM で最後」を、本番の HTML で測った。

① 生 HTML の文字位置（curl で取った本文の indexOf）: 4 頁とも header < h1 < 最初の h2（トップは 56 ＜ 1,449 ＜ 2,435・4 回目時点。4 頁ぶんの数字は Lab 版に）。「入口の一覧が見出しより前」も、入口の h2 は ul より前だった。⚠ 途中でサイトを直しているので、回ごとに位置の数字は少し違う（5・6 回目時点は h1 1,449 ＜ h2 2,428）。結論は変わらない。

② innerText で得られるテキスト順: 小口 → h1 → 本文 → CTA → 証拠 → 「何をするところか」……の順。H1 は 2 番目。（innerText は描画順のテキストであって、スクリーンリーダーの読み上げ順そのものではない。ここでは「見えている順」の確認として使った）

③ compareDocumentPosition: h1 が最初の h2 より前。main は display: block、order を持つ要素は 0（CSS で順番を入れ替えている要素も無い）。

const h1 = document.querySelector('h1'), h2 = document.querySelector('main h2');
(h1.compareDocumentPosition(h2) & Node.DOCUMENT_POSITION_FOLLOWING) !== 0;  // true = h2 は h1 の後
[...document.querySelectorAll('*')].filter(e => getComputedStyle(e).order !== '0').length  // 0

3 通りとも同じ結論。レビュアーが何を見て「最後」と言ったかは分からない（推測しない）。言えるのは「実 DOM ではない」まで。

逆向きの推奨をどう裁いたか

4 回目は「トップの『確かめた結果』と Lab の 2 本を 1 節に統合」を推奨し、5 回目は「成功 1＋棄却 1 に絞って Lab は別節」を推奨した。逆向き。

当時は、社内の改良書に書いてある順（確かめた結果 → Lab）に一致する方（分離）を採った。動いたが、これは「一致した方を採る」で、確認バイアスに見える。

今なら、こう書く。既決の文書の目的・制約・受入条件に照らし、新しい証拠が既決の前提を壊していない限り既決を維持する。 5 回目の推奨は新しい証拠を持っていなかった（同じ状態への再解釈）ので、既決を維持＝分離。結果は同じだが、理由が「一致」から「前提が壊れていない」に変わる。

回答の数は証拠の量ではない

DOM 順の指摘が回を重ねて戻ってきたのは、同じ読み取りを違う言葉で書き直しているように見えます（レビュアーの内部で何が起きたかは確認していません）。回ごとに対象の文書は違い、途中でサイトも直しているので、7 回答を「同じ状態への回答」とは言えません。言えるのは、H1 の位置という同じ観測対象について、途中でサイトを直しても本番の HTML の測定結果（h1 が先）が変わらなかったなら、指摘が 4 回出ても証拠は増えていないことです。多数決に見えても、同じ観測を 4 回数えているだけで、4 件の証拠として合算できません（統計的な独立性を実験で示したわけではありません。ここで言えるのは「新しい根拠の付かない同じ観測対象への指摘は、同じ観測の言い直しとして扱った」まで）。

判断の軸を「何回言われたか」から「新しい証拠が増えたか」に変えると、6 回目で作業を止めたことの説明がつく。DOM 順の指摘は 4 回目以降、新しい証拠を 1 つも持って来なかった。

停止則（改良版）

6 回目に当方が置いた規則は「DOM 順の指摘は測った値を添えて否定するだけ・作業しない」。これは強すぎる。コードが変わった、測り方が間違っていた、新しい根拠が出た、なら再検討すべきだから。

対象の状態・根拠・測定条件が変わっていない同一指摘は再作業しない。新しい証拠か状態の変更があったときだけ再開する。

再開する条件は 3 つだけ: ①対象の状態が変わった（コードや文面を直した）②新しい証拠が出た（測定値・一次資料）③測定条件が変わった（測り方・環境）。どれも無ければ閉じる。

これは「AI を無視する規則」ではなく、再監査の限界効用を管理する規則。実装は記録表 1 枚で足りる。

回	指摘	現物で測った値	採否と理由
3	H1 が DOM で最後	h1 777 ＜体制 2227（V2-1 本番）	否定・測定値を添えた
4	同上（S×3）	4 頁とも header ＜ h1 ＜ h2（4 回目時点）	否定・同上
5	同上	h1 1,449 ＜ h2 2,428（5 回目時点）	否定・同上
6	同上	3 通り（生 HTML・innerText・compareDocumentPosition）	否定・状態も根拠も変わっていない→以後は再作業しない

言わないこと

「AI レビューは信用できない」とは言わない。7 回で採用した指摘は本物で、サイトはそれで良くなった。
「n 回で止めろ」とも言わない。止める条件は回数でなく「新しい証拠が無い」。
レビュアーが内部で何を見たかは分からない。実 DOM でないことだけが測れた。
同じレビュアー・同日・1 サイトの 1 系列（n=7）。別のレビュアーや別日で同じかは測っていない。

4 頁ぶんの位置の数字・全採否の履歴・検証の記録（型）は本家 Sumitsuke Lab → 同じ AI レビューを 1 日に 7 回かけたら、同じ誤りが 4 回続いた——回答の数は証拠の量ではない。判断は「新しい証拠」で。

AI の利用について

サイトの改良案は外部の AI レビューが出し、本番 HTML の計測・採否・commit は人と Claude Code が行いました。レビュアーの製品名は書いていません。対象は自社サイトで、顧客案件は含みません。

関連

外部 AI レビューを現物に当てて照合する運用の話は AI レビューを現物で照合する運用——3 回・17 件が全部正しくても、指摘されなかった穴が 2 件あった。本記事はその「反復」版。

次に読む: LLM に「もう一度見直して」は効くのか。正解つき 160 件で測ったら、初回が 159/160 で天井だった

この記事は Zenn にも同じ内容を掲載しています。