AI出力の検証、機械ゲートとAI審査｜99記事

今日のGitHubトレンドに、別々の会社が作った道具が並んでいました。片方はCloudflareのセキュリティ監査スキル、もう片方はAlibabaのコードレビューツールです。

どちらも同じ設計を名乗っていました。数えれば分かることは機械に任せ、意味が合っているかは別のAIに見せる。二層に分かれています。

ただし中を開けたら、その境目は看板より曖昧でした。そこが今日いちばん面白かったところです。

ぼくの手元には、同じ考え方で作ってきたnote記事が99本あります。機械プリフライトと、独立した敵対レビュー。ただし機械ゲートを入れたのは途中からで、それ以前の記事も混じっています。今日はこの二層が実際に何を止めて、何を素通りさせたのかを、自分のログで数えます。

先に結論です。

・Cloudflareの公式ドキュメントは、機械検証についてこう書いています。「Validator success proves format and ledger consistency only.」検証器の成功が証明するのは、形式と台帳の整合性だけ。真偽の判定は別の層の仕事だと、作った側が明言しています
・自分の記事に意味を壊す欠陥を4件入れて機械ゲートを再実行したら、判定もFAIL数もWARN数も太字数も出典数も、すべて不変でした。動いたのは文字数の2字だけです
・独立レビューの側は、FATALの有無が記録されている53本のうち17本で致命的欠陥を見つけていました。中身は数値の100倍取り違え、帰属のすり替え、タイトルの向き反転など、どれも機械には数えられないものです

この記事は、ぼく個人の運用ログの話です。会社の開発現場にそのまま当てはまる保証はありません。

同じ日のトレンドに、同じ形の道具が二つ並んだ

まず、今日の実物から。

Alibabaのopen-code-reviewは、9月17日に取得した時点で33,285スターでした。9月16日から17日にかけて、GitHubのトレンド一覧に並んでいます。

どれだけの速さで増えたのかは書けません。スターの時系列を取る口が塞がっていて、増え方を自分で確かめられなかったからです。

名乗りはこうです。「Hybrid architecture code review tool: deterministic pipelines + LLM Agent」。決定的なパイプラインとLLMエージェントのハイブリッド。

READMEの見出しでは「Deterministic Engineering × Agent Hybrid」と書かれています。Go実装、Apache-2.0、作成は2026年5月18日です。

決定的な側として挙がっているのは、レビューするファイルの選定、関連ファイルの束ね方、ルールとの対応づけ、指摘位置の補正の4つ。この4つが後で効いてきます。

Cloudflareのsecurity-audit-skillは、同じ日に取得して8,632スター。こちらも同じトレンド一覧にいました。ただしこのリポジトリ自体は2026年6月18日に作られたもので、今日の新作ではありません。

こちらは監査を6段階に分けます。偵察、カバレッジ主導の探索、候補の検証、構造化出力、独立した記録検証、ターゲット中立のレポート。

3段目の原文がこうです。「give every unique candidate to a fresh verifier that tries to disprove it」。見つかった候補はひとつ残らず、それを反証しようとする新しい検証役に渡す。

5段目はこうです。「fresh agents verify final source claims」。

設計方針の欄には、もっと短く書いてあります。「The agent that checks a finding is never the agent that found it.」指摘を検査するエージェントは、それを見つけたエージェントでは決してない。

Cloudflareが自分で書いている「検証器が証明するのは形式だけ」

このスキルには、依存ゼロのNodeスクリプトが2本ついています。findings.jsonとcoverage-ledger.jsonを検査する機械の側です。

面白いのは、その機械が何をしていて、何をしていないかを、ドキュメントがはっきり線引きしていることでした。

機械がやっていること。スキーマ適合の検査。verdictごとの禁止フィールドの検査。深刻度が実証された影響を超えていないか。攻撃経路の並び順が入口から出口になっているか。指紋の一意性と辞書順ソート。パスの安全性。

そして台帳の側には、もっと踏み込んだ検査があります。証拠が空のまま「covered（調査済み）」と宣言することが機械的に不可能になっていて、検証役の使い回しも検出されます。「assignment owner must be fresh for each attempt」。他のエージェントの成果物を自分の証拠として流用することもできません。

つまり機械の層は、真偽ではなく手続きの誠実さを守っています。ちゃんと別の人にやらせたか。証拠なしに済ませていないか。

そのうえで、ドキュメントにはこう書いてあります。

「Fix every structural and semantic error before continuing. … Validator success proves format and ledger consistency only.」

検証器が通ったことが証明するのは、形式と台帳の整合性だけ。スクリプトは監査対象のソースコードを一度も開きません。JSONを2本見るだけです。脆弱性が本当に存在するかは、機械の管轄外だと明記されています。

ここが、ぼくが今日いちばん腑に落ちたところでした。自分の仕組みでも同じ線を引いていたのに、言葉にできていなかった。

なお、このスキルは特定の製品専用ではありません。「This skill is agent-neutral」と書かれていて、全ファイルを製品名で検索してもヒットは0件でした。

「決定的」と書いてある側を開けたら、半分はLLMだった

Alibabaのほうも、同じように中を見ました。先ほどの4要素です。4つ目が「位置補正とreflection」の複合なので、下では5行に分けます。

実際のGoのソースを読むと、純粋に決定的だと確認できたのは2つだけでした。

・ファイルの選定は決定的です。「the review's one deterministic pre-dispatch selection … no git or LLM access」と書かれていて、gitにもLLMにも触りません
・ルールとの対応づけも決定的です。ただしルール自体は静的解析ではなく、globでMarkdownに振り分ける52件のルーティング表でした（9月17日取得）。中身はエージェントへの指示文です
・ファイルの束ね方はLLM呼び出しでした。「groupDiffs calls the LLM with file metadata … to produce semantic groups」。変更ファイルが閾値の4件未満のときだけ、決定的に処理されます
・指摘の補正は、まず決定的なテキスト照合を試し、失敗するとLLMに回ります
・reflectionもLLMです。そのプロンプトの冒頭が「You are a fact-checker for code review comments.」でした

つまり「決定的なパイプライン」と名乗っている4つのうち、2つは実装上LLMを呼んでいます。しかもこの名乗り自体は、READMEの本文ではなくGitHubのリポジトリ説明欄にあるものでした。

そしていちばん引っかかったのが、成績の測り方です。

PrecisionとF1を出すために、指摘と正解を突き合わせる工程があります。その照合はパス、変更の側、行番号、そして意味の4段階で、最終段は裁判役のLLMが意味の一致を判定していました。 どのモデルを裁判役に使ったかは公開されていません。

ここに、この記事の主題がそのまま出ています。このベンチマークでは、パスと位置と文字列の照合だけでは指摘が同じものか決められず、最終段にLLMの裁判役を置いていました。 意味のうちテストや型検査で確かめられる部分はあります。ただ「同じ指摘か」の判断は、そこに乗らなかった。

数字そのものにも触れておきます。「同じモデルでPrecisionとF1が有意に高い」とありますが、READMEに表としては載っていません。実数値は画像と、サイトのソースに埋め込まれていました。テキストで検算できるのは後者だけです。

最高の組み合わせでF1が25.10%、Precisionが33.90%、Recallが20.00%です。絶対値としては低く、「有意に高い」はあくまで比較対象に対しての話になります。

トークンが約9分の1という主張は、比較対象が製品名で明記されていました。5組の合計では8.95倍で計算が合いますが、組ごとには5.43倍から14.71倍までばらついています。

公平のために書くと、Alibabaはデータセットも評価用のハーネスも公開しています。ハッシュ値つきです。主張を自分で確かめられる形にしてある点は、この種の自社ベンチマークの中では誠実なほうだと思いました。論文はプレプリントで、査読採録は確認できていません。

土台：機械ゲートが強制できたもの

ここからは自分のログです。

ぼくのnote制作には、公開前に必ず通す機械プリフライトがあります。168行、13ルール。太字の対数、単一アスタリスクの残留、HTMLコメントの混入、旧ハンドルの文字列、本文中の内部リンク、見出しの数、出典の本数、段落の長さ、文字数。

13ルールすべてが、出現回数か、有無か、長さの計数です。 出典URLが生きているか、数値が正しいか、帰属が合っているかを見るルールは0件でした。

これを手元にある99本すべてに当て直しました。公開したものと、下書きのままのものが混ざっています。

ここで最初に失敗しています。全99本を同じモードで走らせて「65本がFAIL」という結果を得て、危うくそのまま書くところでした。

間違いです。健康系の記事は出典をDOIで書き、トレンド系はURLで書きます。URL用のモードで健康記事を測ると、出典が0件と数えられるだけでした。記事ごとに様式を判定して測り直した結果がこれです。

・総数99本のうち、PASS 72本・FAIL 27本
・FAILの内訳は、出典不足19、太字過多11、HTMLコメント8、単一アスタリスク残留7、見出し重複1、内部リンク露出1

そしてこの機械ゲートを作ったのは2026年7月8日です。その前後で分けると、形がはっきりします。

・ゲート導入前に書いた30本のうち、いまFAILするのは26本
・ゲート導入後に書いた69本のうち、いまFAILするのは1本

唯一の1本はdaily-steps-healthで、見出しが14個ある、というだけの指摘でした。

ただし、この数字の読み方には注意がいります。導入後の記事は「FAILが0になるまで直してから公開する」運用なので、0本に近づくのは定義上そうなるだけです。対照実験ではありません。ここで言えるのは「ゲートが強制している範囲」であって、「記事の質が上がった」ではない。

日付も、ファイルの最終更新日を使った近似です。既知の公開日と突き合わせると当日から翌日がほとんどでしたが、1本だけ3日ずれていました。後から編集した形跡です。

上乗せ：意味を4か所壊しても、ゲートは通った

では、この機械ゲートは何を見ていないのか。数えるより、壊してみるほうが早いと思いました。

昨日書いたばかりの記事のコピーを作り、意味を壊す欠陥を4件だけ入れました。その記事はまだ下書きで、公開していません。どれも、過去に独立レビューが実際に見つけた事故と同じ型を選んでいます。

1．数値の10倍化。掲示板のポイント数を545から5,450に
2．中核主張との矛盾。その記事の背骨は「公式文書にAIという語は一度も出てこない」でした。語数表の0を7に
3．向きの反転。「429ではなく503」を「503ではなく429」に
4．帰属のすり替え。「書いた本人が推測だと明示している」を「Internet Archiveの公式見解として示されています」に

4番目は、匿名の一般ユーザーの推測を、実在の団体の公式見解に化けさせる書き換えです。記事として最もまずい部類でしょう。

機械ゲートを両方に走らせた結果です。

・判定：原文PASS、注入版もPASS
・FAIL件数：0と0
・WARN件数：3と3
・太字：26対と26対
・出典URL：13件と13件
・文字数：7,575字と7,573字

動いたのは文字数の2字だけでした。 13ルールのどれも、4件の嘘に反応していません。

当たり前といえば当たり前です。ぼくがそう作ったのだから。でも自分の道具で実際に見ると、印象が変わりました。機械ゲートを通ったことは、中身が正しいことの保証にはならない。 保証しているのは、決めた形式と手続きを通った、それだけです。

念のため書くと、これは1記事・4件・ぼくが選んだ欠陥での結果です。「機械ゲートは意味を一切検出できない」と一般化できるものではありません。

独立した検証役が、実際に止めたもの

では上の層は何をしたのか。

ぼくは記事ごとに、制作とは別に新しく立てたAIに敵対レビューをさせています。致命的な欠陥が1件でもあれば公開しない、という運用です。

作業記録を集計しました。分母は、独立レビューに言及し、かつ致命的欠陥の有無を書き残してある53本です。

・致命的欠陥が1件以上見つかった記事：17本
・0件と明記された記事：36本

17本、およそ3割。 これは記録の残る53本に限った話で、全記事の発生率ではありません。中身を並べると、性質がはっきりします。

・調査要約の「入力570億トークン」が、実際は5.7億だった。100倍のコピー伝播
・自分の過去記事の「47稼働日で$2,625」を月額に換算するとき、稼働日を暦日として扱っていた。月$1,700と書きかけて、正しくは月約$1,310
・取得ツールの要約が数値の帰属を取り違え、2つのサイトの数字が入れ替わったまま記事に伝播していた
・「著者ページが404だから著者は実在しない」と書きかけた。実際にはリンク先が別のパスで生きていた。実名3名への名誉毀損になりかねない誤り
・タイトルが手法の向きを反転させていた。欠陥を注入したのは実装側で、テストは凍結していたのに、タイトルは逆に読めた
・AIが見た画像を「筆者が自分の目で確認した」と書いていた

どれも、文字を数えて見つかるものではありません。出典URLの本数は足りているし、太字の数も正常。自分で決めた13ルールの上では通ったまま、中身だけが間違っている。 上の層が要るのは、この形の間違いのためです。

この集計にも限界があります。ぼくの作業メモの集計であって、体系的なログではありません。書き漏らした回があれば実数はこれより多いはずです。実際、件数を書き残しておらず分母から外した12本のうち、少なくとも1本は記録上NO_GO（＝致命的欠陥あり）でした。17本は下限です。件数は深刻さも表しません。1語の修正で済んだものから、中核の主張が崩れて全面改稿になったものまで、同じ「1件」に混ざっています。

ただし「業界が検証層へ向かっている」とは言えない

ここで一度、自分にブレーキをかけます。

今日のトレンドに二層構造の道具が2つ並んだ。だから業界全体がそちらへ動いている、と書きたくなりました。書けません。2件は2件です。しかもCloudflareのほうは6月に作られたもので、今日の新作ですらない。

同じ2日間に、近い設計のものがいくつか公開されてはいます。自分で原文を読んだ範囲では、こうでした。

・corundは、エージェントが作業を終えようとしたときに動きます。テスト以外の変更を使い捨ての作業ツリーに巻き戻し、エージェントが今書いたテストを実行し直す。それでも通ってしまうなら、終了を拒否する。そのテストは実装を検証していない証拠だからです。ただしどれくらいの確率で偽テストを捕まえるかの測定値は、書かれていません
・HEXISは、指示書を状態機械にコンパイルします。問題提起の原文が「requirements that the document states clearly can still be skipped, reordered or applied in the wrong situation」。文書に明記した要件でも、飛ばされたり順序が入れ替わったりする、という話です。こちらも測定値の記載はありません
・seanswarmは、2つの経路が同じ文書を独立に読んで突き合わせます。矛盾の裁定規則が「Independent-source count > vote count; primary > secondary; newer > older」。そして「conflicts are resolved by arbitration, never by majority vote」と明記してあります。多数決では決めない

並べると流れに見えます。でもこれらを結ぶ線は、いまのところぼくの解釈です。作者どうしが示し合わせた証拠はありませんし、どれも効果の測定値を出していません。

ハーネスの差は成功率で平均±2%、という別方向の実測

もうひとつ、自分の主張に都合の悪い実測も置きます。

同じ9月16日に、UC BerkeleyとArenaの研究者6名が「HarnessTax」という測定を公開しました。7モデル×3ハーネスの21組み合わせを、2つのベンチマークで比べたものです。各30タスク、1タスクにつき3回。

結果はこうでした。

・ハーネスの違いが成功率に与える影響は平均で、SWE-bench Liteで±2%以内、Terminal-Bench 2.0で±5%程度。個別の組み合わせではもっと開きます
・一方コストは、SWE-bench LiteでClaude CodeがPiの約2.0倍（コスト比の幾何平均）。Terminal-Bench 2.0では1.5倍です。「The same model can achieve similar success rates at up to 5x costs」
・「Pi reaches the Pareto frontier on both benchmarks by providing just four tools: read, write, edit, and bash」。道具を4つしか持たない最小構成が、両方のベンチマークでパレート最前線に届いた

ただし、正面からの反証ではありません。あちらが測ったのはコーディング課題が解けたかどうかと、その費用で、独立レビューが誤りをどれだけ減らすかは測っていないからです。

ぼくが測ったのは、公開した文章に嘘が残っていないかでした。課題が解けたかはテストが通れば判定できます。嘘が残っているかは、通ったかどうかを機械が判定できない。だから同じ「ハーネス」でも結論が分かれる、というのがぼくの読みです。「層を増やせば目的の指標が良くなる」と無条件に考えるな、という警告として受け取りました。

この研究自体にも留保が要ります。査読論文ではありません。 arXivですらなく、プロジェクトページとして公開されたものです。

著者自身が「These findings can be limited to the two open-source benchmarks we test」と書いていて、生の実行記録は公開予定とされたまままだ出ていないので、いまは追試できません。評価対象ベンダーのAPIクレジットを第三者経由で受け取っていることも謝辞に書かれています。

掲示板では「セキュリティやサンドボックスの機能をコストに数えず、税と呼ぶのは不誠実だ」という反論も出ていました。これは検証されていない一利用者の意見ですが、もっともだと思います。

今日からできること

1．自分のチェックが「形式」と「意味」のどちらを見ているか、数えてみる。ぼくは13ルール全部が形式側でした。比率を知るだけで、どこが無防備かが分かります。

2．見つける役と、検査する役を分ける。Cloudflareの一文がそのまま使えます。指摘を検査するエージェントに、それを見つけたエージェントを使わない。同じセッションの続きで「確認して」と頼むのは、少なくとも独立した検査にはなりません。

3．通ったことを、安心の材料にしない。自分のチェックを通っている成果物を1つ選んで、意味だけ壊してもう一度通してみる。ぼくは4件入れて4件とも素通りしました。

4．数字は、記事の中の別の数字で検算する。今日ぼくが「65本FAIL」を書かずに済んだのは、内訳を見て「健康記事に出典URLが0件」という不自然さに気づいたからでした。合計値だけ見ていたら、そのまま出していたと思います。

最後まで読んでいただき、ありがとうございます。

・💬 コメント：あなたのチェックは、形式と意味のどちらを見ていますか。比率を数えてみた結果を教えてください
・👤 フォロー：AIの実測と、公式文書の原文を突き合わせる記事を続けています。よければフォローを（note: designing_edges）
・📚 関連記事もどうぞ

AIが書いたテストに、実装の欠陥を20個ぶつけた:
https://note.com/designing_edges/n/n68361ba4ce2c 

コードレビューの詰まり、大手3社と査読論文17本:
https://note.com/designing_edges/n/n49554dffaecd 

claude -p の終了コード0を疑う:
https://note.com/designing_edges/n/ne4188cf5ed1a 

参考リンク（一次ソース）

cloudflare/security-audit-skill:
https://github.com/cloudflare/security-audit-skill 

alibaba/open-code-review:
https://github.com/alibaba/open-code-review 

HarnessTax（UC Berkeley / Arena・査読なし）:
https://harnesstax.github.io/ 

Grade-Inc/corund-plugin:
https://github.com/Grade-Inc/corund-plugin 

Worldbuilder013/HEXIS:
https://github.com/Worldbuilder013/HEXIS 

ccai40359-wq/seanswarm:
https://github.com/ccai40359-wq/seanswarm 

HarnessTax の掲示板スレッド:
https://news.ycombinator.com/item?id=49733726 

※99本には、公開した記事と下書きのままの記事が混ざっています。集計は記事ファイルの最終更新日を公開日の近似として使っています。既知の公開日と突き合わせた結果、当日から翌日が大半で、1本だけ3日のずれがありました。

※Alibabaのベンチマークは自社で作り自社で測ったもので、第三者による再現は確認できていません。ただしデータセットと評価ハーネスは公開されているため、原理的には追試できます。正解データは「AIが下書きし専門家が検証した」もので、純粋な人手注釈ではありません。

※スター数は2026年9月17日にGitHubのAPIで取得した値です（Alibaba 33,285／Cloudflare 8,632）。変動します。

※増え方の時系列は取得できなかったため、伸びの速さについては判断していません。取得できなかったのは環境側の制約で、別の大規模リポジトリでも同じ結果になることを確かめています。トレンド一覧に並んでいたのは取得当日に自分で見た表示で、スナップショットは保存していません。

※Cloudflareの「単発実行は繰り返し実行が見つけた脆弱性の約半分」という記述は、試行回数も対象リポジトリも公開されていないため、この記事では本文に採用していません。