品質ゲート（監査ゲート）とは、CI やビルドプロセスにおいて、ドキュメントやコードが規定の品質基準や完全性を満たしているかを機械的に判定・遮断する検収機構です。

独自の監査スクリプトを組み始めたとき、多くの開発者は「違反が 0 件であれば、その成果物は健全であり合格である」という素朴な判定ループを疑いません。私自身も、ドキュメントに含まれる出典 URL の実在性を検証する監査ゲートを社内ナレッジハブに導入した際、確定版（stable）として管理されるドキュメントについて、台帳で検収されていない URL があれば警告してコミットを止める設計です。

しかし導入直後の実測で、AI エージェントが作成した調査ドキュメントのうち、減衰率 30〜70% やインプレッション 1.5〜3 倍といった具体的な数値を多数並べたトピックが、出典 URL を 1 本も持たないまま監査ゲートを素通りし、確定版に留まっていたことが分かりました。

URL を 2 本持っていた別の調査ドキュメントでは、存在しない捏造 URL 1 件が正しく警告・遮断されていました。それにもかかわらず、最も根拠の薄い「出典が一切存在しない記録」は、検査対象の URL が 0 件だったために警告 0 件となり、素通りしてしまいました。

この失敗を通じて痛感したのは、「違反がなければ通す」という除外基準（Exclusion）が抱える構造的な脆さです。以下では、プログラミングや論理学において「0 件が合格してしまう」背後にある「空虚な真（Vacuous Truth）」のメカニズムを解明し、pytest や Jest といった既存テストツール、さらには古典的なセキュリティ原則に学びながら、根拠の等級の側から分母を定義するフェイルセーフな品質ゲートの設計論を考えます。

なぜ「検査対象 0 件」は合格してしまうのか：空虚な真（Vacuous Truth）の罠

なぜ、最も根拠の薄い記録が監査ゲートに合格してしまったのでしょうか。その根本的な原因は、論理学における「空虚な真（Vacuous Truth）」と呼ばれる性質にあります。

論理学において、全称命題 ∀x ∈ S, P(x)（集合 S のすべての要素 x について条件 P(x) が成り立つ）は、条件付き命題 ∀x (x ∈ S → P(x)) と同値です。もし検査対象の集合 S が空集合（∅）であった場合、前提条件（antecedent）である x ∈ S が偽となるため、条件法（含意）の定義により命題全体は無条件に「真」となります 1。

日常会話の例で言えば、「この部屋にあるすべての携帯電話は電源が切れている」という命題は、部屋に携帯電話が 1 台も存在しないとき、論理学上は真となります 1。同時に「この部屋にあるすべての携帯電話は電源が入っている」という命題も真になります。前提となる対象が存在しないとき、その対象に関する任意の全称主張は反証不可能になり、空虚な真として成立してしまうのです。

プログラミング言語における空虚な真の実装

この論理学の挙動は、私たちが日常的に利用しているプログラミング言語の標準仕様にもそのまま反映されています。

JavaScript / ECMAScript の Array.prototype.every() は、配列内のすべての要素が指定されたテスト関数を満たすかを判定します。MDN Web Docs にも明記されている通り、このメソッドに空配列を渡すと無条件に true を返します 2。

[].every(() => false); // true

MDN のドキュメントでは、これを「空集合のすべての要素が任意の条件を満たすことは、空虚な真（vacuously true）である」と説明しています 2。

Python の組み込み関数 all() も同様です。空のイテラブルを渡すと無条件に True を返します 3。Python 公式ドキュメントに記載されている等価な実装コードを見ると、その理由がよく分かります 3。

def all(iterable):
    for element in iterable:
        if not element:
            return False
    return True

走査対象の要素が存在しない場合、ループは一度も回らず、コードは直ちに最後の return True へ到達します。

自作監査スクリプトの素朴な判定ループ

問題は、自作リンターや品質ゲートを書く開発者の多くが、無意識のうちにこの all() と全く同じ構造の判定ループを書いてしまう点にあります。

次のコードは、この判定構造を説明用に簡略化した例です（実際のゲートは台帳で検収済みかどうかを URL ごとに照合していました）。

ファイル: audit_topics_v1.py

import re

URL_RE = re.compile(r"https?://[^\s()]+", re.IGNORECASE)
VERIFIED_URLS = {"https://example.com/verified"}


def check_unverified_urls(markdown_text: str) -> int:
    """ドキュメント内の URL を走査し、未検証の URL 件数を返す"""
    urls = set(URL_RE.findall(markdown_text))
    # 抽出された URL の中に、検証済み台帳にないものがあれば違反とする
    unverified = [u for u in urls if u not in VERIFIED_URLS]
    return len(unverified)


# テスト 1: 未検証 URL を含むドキュメント
doc_with_unverified = "参考: https://example.com/unverified"
assert check_unverified_urls(doc_with_unverified) == 1  # 検出成功

# テスト 2: 出典 URL を 1 本も持たないドキュメント
doc_without_urls = "具体的な数値: 減衰率は 50% です。"
assert check_unverified_urls(doc_without_urls) == 0  # 違反 0 件で「合格」

このコードでは、URL_RE.findall(markdown_text) が空リストを返すと、内包表記のループが 0 回で終了し、未検証リスト unverified も空になります。その結果、戻り値は 0（違反なし）となり、監査ゲートは「健全なドキュメント」として通過させてしまいます。

「怪しい URL が含まれていたら弾く」というチェックは、「URL が 1 本以上含まれている」という前提の上でしか機能しません。前提条件が崩れて検査対象がゼロになった瞬間、除外型の判定ループは静かに口を開け、最も根拠の薄いデータを素通りさせてしまうのです。

既存テストツールはどう防いでいるか：フェイルセーフな分母設計

検査対象が 0 件のときにサイレントパスしてしまう落とし穴は、自作スクリプトに限った話ではありません。成熟した既存のテストフレームワークやセキュリティ設計の歴史を振り返ると、先人たちがこの問題にいかに向き合ってきたかが分かります。

pytest の Exit code 5：No tests collected

Python の代表的なテストフレームワークである pytest は、実行結果に応じて厳密な終了コードを定義しています 4。

終了コード定義（pytest.ExitCode）意味
Exit code 0OKすべてのテストが収集され、正常にパスした
Exit code 1TESTS_FAILEDテストが実行されたが、一部が失敗した
Exit code 5NO_TESTS_COLLECTEDテストが 1 件も収集されなかった

pytest において、終了コード 0 は単に「失敗したテストが 0 件だった」ことを意味しません。「すべてのテストが 収集され（collected）、かつ成功した」ことこそが正常終了の条件です。

もしテストファイルが 1 件も見つからなかったり、絞り込みでテストが 0 件になったりした場合、pytest は「失敗 0 件だから成功」とは見なさず、Exit code 5 という専用の異常終了ステータスを返して CI を停止させます。分母がゼロである状態を明確な異常として扱う設計です。

Jest の --passWithNoTests によるオプトイン

JavaScript / TypeScript エコシステムのテストランナーである Jest も、同様の思想に基づいています 56。

Jest でテストファイルが 1 件も見つからなかった場合、デフォルトではテストスイートは 合格になりません。テストが 0 件の状態でテストスイートを合格させたい場合、開発者は明示的に --passWithNoTests という CLI フラグを指定しなければなりません 5。

Jest のプルリクエスト #5127 は、テストが見つからなかったときに --passWithNoTests の使用を提案するメッセージを加える変更で、議論では「If you consider no tests matching your filters correct behavior, use the ‘—passWithNoTests’ option」という文面が示されています 6。同じ PR は、--findRelatedTests・--lastCommit・--onlyChanged を指定したときに限り、テストが見つからなくてもエラーにしないよう改めました 6。0 件を正しい挙動と見なすかどうかは利用者に明示させ、0 件が正常に起こりうる文脈だけを例外にして、既定は失敗のまま残す設計だと私は読んでいます。

セキュリティ原則：Fail-Safe Defaults（安全側のデフォルト）

この設計思想の根底にあるのが、1975 年に Jerome H. Saltzer と Michael D. Schroeder が提唱したセキュリティ設計の基本原則、Fail-Safe Defaults（安全側のデフォルト） です 7。

Saltzer らは論文の中で次のように述べています 7。

「アクセス決定は、除外（exclusion）ではなく許可（permission）に基づいて行われなければならない。……明示的な許可を与えるメカニズムの設計や実装に誤りがあった場合、アクセスを拒否する方向に失敗する傾向がある。これは即座に検知されるため安全である。一方で、明示的な除外を行うメカニズムに誤りがあった場合、アクセスを許可する方向に失敗する傾向があり、通常の運用では見過ごされてしまう。」

OWASP のセキュアコードレビューや認可（Authorization）チートシートでも、この原則は Deny by Default（デフォルト拒否） として強調されています 89。

監査ゲートの判定ロジックを、この原則に照らして対比してみましょう。

品質ゲートの判定アプローチは、何を合格基準とするかによって空集合に対する耐性が決定的に異なります。

アプローチ判定の基軸0 件時の挙動メリットと課題
除外基準（Exclusion）不正な URL や NG ワードが 0 件ならパスサイレントパスする（空虚な真）実装は容易だが、対象が欠落したときに重大な盲点となる
単純件数アサート（Count）抽出された URL が 1 件以上存在することエラーで遮断できるURL が不要な正当なドキュメントまで一律に拒絶してしまう
許可基準（Permission）確定版なら検証済みの根拠等級を最低 1 つ保持確実に遮断（フェイルセーフ）ドキュメントの品質等級（ライフサイクル）の定義が必要

単に「URL を 1 件以上要求する」という単純な件数アサートを追加するだけでは、URL を必要としない概念説明などの正当なドキュメントまで巻き込んでしまいます。本質的な解決策は、ドキュメントのライフサイクル（確定版か下書きか）に応じた許可基準を設計することにあります。

処方箋：「URL の側」からではなく「等級の側」から分母を定義する

社内ナレッジハブでの失敗を経て私たちが辿り着いた結論は、「URL の実在検査」と「根拠の存在検査」は全く別の穴である という事実でした。

URL の実在検査は、「URL が存在する」という前提の上でしか機能しません。したがって、この検査の分母は「ドキュメント内に含まれる URL の集合」です。一方で、「このドキュメントが確定版として十分な根拠を持っているか」を問う検査の分母は、「確定版（stable）を名乗るドキュメントそのもの」でなければなりません。

根拠の等級から分母を捕捉する修正実装

社内ナレッジハブでは、記録の本文に根拠の等級を書いています。[実測] と [検証済] は確かめた根拠、[未検証] はまだ確かめていない記述を表し、確定版（stable）は確かめた根拠を最低 1 つ持たねばならない、という約束です。

そこで私たちは、監査スクリプトの分母設計を見直しました。URL の実在検査はそのまま残し、それとは独立に、確定版ドキュメントすべてを分母として、本文中に有効な根拠等級が含まれているかを検証する条件を追加したのです。次のコードは、実際の監査スクリプトから判定部分を抜き出して簡略化したものです。

ファイル: audit_topics_v2.py

import sys
from pathlib import Path

# 根拠の等級。確定版（stable）は最低 1 つ「確かめた根拠」を持たねばならない
GRADE_OK = ("[実測]", "[検証済]")


def audit_document(file_path: Path, text: str, status: str) -> bool:
    """確定版ドキュメントの品質基準を検証する"""
    if status != "stable":
        return True  # 下書き（draft）段階は強制しない

    # 【処方箋】URL の有無ではなく、確定版として有効な根拠等級を持つか検査する
    has_valid_evidence = any(grade in text for grade in GRADE_OK)
    if not has_valid_evidence:
        print(
            f"WARN: stable なのに [実測]/[検証済] の根拠が1つも無い: {file_path.name}",
            file=sys.stderr,
        )
        print(
            "      確かめたものを等級付きで書くか、status: draft に落としてください",
            file=sys.stderr,
        )
        return False

    return True

この修正により、「等級の記述が全くないドキュメント」だけでなく、「[未検証] の等級しか持たないドキュメント」も同一の条件で確実に捕捉できるようになりました。

修正時点の確定版ドキュメント 5 件に対して実際の監査スクリプトを実行したところ、誤検出は 0 件でした（5 件という小規模な確認です）。そして、出典を持たない AI 生成トピックを一時的に確定版へ戻して実行すると、狙い通り WARN: stable なのに [実測]/[検証済] の根拠が1つも無い が検出されました。

違反が一度も観測されない状態の罠を防ぐセルフテスト

しかし、ここで話は終わりません。違反が一度も観測されない状態にも、別の罠が潜んでいたからです。

もし現行のリポジトリ内のすべてのファイルが正常（グリーン）だった場合、監査スクリプトの検査ロジック自体が typo や条件分岐のバグで無効化されていても、誰もそれに気づくことができません。全件合格している状態そのものが、テストの空振りを隠蔽してしまうのです。

そこで私たちは、使い捨ての違反トピックを生成して監査ゲートの検査能力をテストするセルフテストを用意しました。次のコードは、上の 2 つの検査関数をそのまま呼び出す形に簡略化した例です。

ファイル: selftest_topics.py（audit_topics_v1.py・audit_topics_v2.py と同じディレクトリに置き、python3 selftest_topics.py で実行）

import contextlib
import io
import tempfile
from pathlib import Path

from audit_topics_v1 import check_unverified_urls
from audit_topics_v2 import audit_document


def run_audit_suite(topics_dir: Path) -> int:
    """トピックごとにゲート本体の2条件（根拠の等級／未検収の出典）を検査し、違反件数を返す"""
    warnings = 0
    for p in sorted(topics_dir.glob("*.md")):
        text = p.read_text(encoding="utf-8")
        status = "stable" if "status: stable" in text else "draft"
        if not audit_document(p, text, status):
            warnings += 1
        elif status == "stable" and check_unverified_urls(text) > 0:
            warnings += 1
    return warnings


def selftest_topics():
    """監査ゲートの検出ロジックが壊れていないかを、使い捨てのデータで検証する"""
    cases = {
        # 1. 等級なし（確定版なのに根拠なし） → 1 件検出されるべき
        "no-grade.md": "---\nstatus: stable\n---\n本文のみ。\n",
        # 2. 未検証の怪しい URL を含む → 1 件検出されるべき
        "unverified-url.md": "---\nstatus: stable\n---\n`[検証済]`\nhttps://example.invalid/bad\n",
        # 3. 下書き段階 → 検出対象外（0 件）
        "draft.md": "---\nstatus: draft\n---\n本文のみ。\n",
    }

    with tempfile.TemporaryDirectory() as tmp_dir:
        tmp_path = Path(tmp_dir)
        for filename, body in cases.items():
            (tmp_path / filename).write_text(body, encoding="utf-8")

        # 標準エラー出力を抑制して検査を実行
        with contextlib.redirect_stderr(io.StringIO()):
            detected_count = run_audit_suite(tmp_path)

        # 使い捨てトピック 3 件中、想定通り違反 2 件が検出されることを assert
        assert detected_count == 2, f"2件検出するはずが {detected_count} 件でした"


if __name__ == "__main__":
    selftest_topics()
    print("セルフテスト成功: 監査ゲートの検出機能は正常です。")

一時ディレクトリの中に、「等級なしの確定版」「未検証 URL を含む確定版」「対象外の下書き」という計 3 件のファイルを動的に作成し、想定通り 2 件の違反が検出されることを assert します。

ゲート自身に違反データを踏ませて「正しくコケること」を毎回確かめることで、用意したケースについては、ゲートが空振りしてサイレントパスを生み出すメタな事故に気づけるようになりました。

メリットの裏にあるトレードオフと適用限界

許可基準に基づく分母設計は強力ですが、運用上のトレードオフや適用限界も存在します。

草案段階（draft）への過剰拘束をどう避けるか

あらゆるドキュメントに対して「検証済みの根拠がなければ保存もコミットも許さない」という厳格なゲートを設けると、開発者や執筆者の自由な思考やアイデアメモの作成が阻害されます。

だからこそ、ドキュメントのライフサイクル設計が不可欠です。私たちは status: draft（下書き）と status: stable（確定版）を明確に区別し、厳しい許可基準は「確定版」に昇格させるタイミングでのみ発動するように設計しました。自由な記述を許す領域と、機械的な品質保証を課す領域の境界を明確にすることが重要です。

形式的タグ付けによるすり抜けのリスク

「[検証済] という文字列が含まれていれば合格」というルールだけを設けると、中身のないダミータグを形式的に貼り付けただけのドキュメントがすり抜ける新たなリスクが生まれます。

したがって、単一のルールに頼るのではなく、多層防御を構築しなければなりません。「確定版としての等級を明示しているか」という許可基準の検査と、「記載された URL が台帳に登録された検証済みソースであるか」という実在性検査を組み合わせることで、形式的なすり抜けと空集合のすり抜けの両方を挟み撃ちにできます。

差分チェックにおける「0 件」の扱い

想定される反論として、「Git の差分コミットに対して走る CI では、変更ファイルが 0 件のケースもあるのではないか。それもエラーにすべきなのか？」というものがあります。

Jest が --passWithNoTests を用意し、PR #5127 で --onlyChanged などの指定時を例外扱いにしたのも、この種の文脈があるからだと考えられます 6。PR でドキュメントやテストコードに変更がないビルドにおいて、テスト対象が 0 件になるのは正常な業務フローです。

重要なのは、「空集合が正当な業務フローである文脈」と、「成果物の完全性を保証しなければならない文脈」を混同しないことです。成果物そのものが満たすべき品質基準を問うゲートにおいては、空集合を無条件に許容してはなりません。

前提が変われば結論はどう変わるか

技術の進化によって、この設計論の前提はどう変わり得るでしょうか。

AI による文章生成の高度化とハルシネーション

LLM の進化に伴い、AI エージェントが生成するテキストはますます自然で説得力のあるものになっています。出典を一切持たない場合でも、もっともらしい業界用語や具体的な数値（「減衰率 30〜70%」など）を滑らかにでっち上げる（ハルシネーション）能力は日々向上しています。

AI が調査やドキュメント作成を自律的に行う時代において、人間が文章を目視しただけで根拠の有無を見抜くことは極めて困難です。だからこそ、文章の「それっぽさ」に惑わされず、背後にある根拠や一次情報の存在を決定論的に検証する機械的な品質ゲートの重要性は、今後ますます高まります。

LLM-as-a-Judge を導入した場合の死角

将来的に、品質ゲートの判定ロジックそのものを LLM に委ねる「LLM-as-a-Judge」のアプローチを採用する場合でも、全く同じ罠が待ち構えています。

LLM に対して「このドキュメントに不適切な記述や誤った情報が含まれていないか評価せよ」とプロンプトで指示すると、LLM もまた除外基準（Exclusion）で推論を行い、根拠のない記述を「特に問題は見当たらない」とスルーしてしまうおそれがあると私は考えています。

LLM に監査を行わせる場合でも、「必須の一次情報リンクや検証済みフラグが本文中に明記されているか」を最初にチェックさせる許可型のプロンプト設計が不可欠です。基盤技術が正規表現からニューラルネットワークに変わろうとも、「分母をどこに置くか」という設計思想の本質は変わりません。

まとめ

自作リンターや品質ゲートを設計するにあたって、持ち帰るべき教訓を 3 つの命題として整理します。

  1. 「違反が 0 件」を「成果物が健全である」と同一視してはならない: 検査対象が空集合のとき、全称命題は無条件に真となります（空虚な真）。除外基準（Exclusion）で作られた判定ループは、最も根拠の薄いデータをサイレントパスさせます。
  2. 分母は「検査対象の側」ではなく「品質を保証したい成果物の側」から定義せよ: URL の実在検査は URL が存在することを前提とします。確定版（stable）を名乗るなら、ドキュメントそのものを分母として、検証済みの根拠が最低 1 つ存在することを要求してください。
  3. 品質ゲート自身に「意図的違反」のセルフテストを組み込め: pytest の Exit code 5 や Jest の --passWithNoTests が示すとおり、成熟したツールは対象 0 件を既定で合格にしません。自作ゲートにも、使い捨ての違反データを踏ませて想定件数の検出を assert するセルフテストを組み込んでください。全件グリーンの状態だけでは、検査ロジックが無効化されていても区別できません。

よくある質問（FAQ）

Q. 自作リンターや CI スクリプトで「検査対象 0 件」を検知すべきなのはなぜですか？

A. 検査対象が 0 件（空集合）のとき、「違反が見つからなければ合格」という素朴な判定ループは無条件に合格を返してしまう（空虚な真）ためです。ファイルパスの指定ミスや正規表現の誤り、あるいは検査対象の属性そのものが欠落している場合、重大な欠陥を抱えたデータがサイレントパスしてしまいます。

Q. pytest がテスト未検出時に Exit code 5 を返す理由は何ですか？

A. テストが 1 件も収集されなかった状態は「テストスイートが正常に合格した」のではなく、設定ミスやテストファイル指定の誤りといった異常状態であると見なすためです。pytest は全テストが正常に収集されてパスした場合（Exit code 0）と、テストが収集されなかった場合（Exit code 5）を厳密に区別しています。

Q. 監査ゲートにおける「除外基準（Exclusion）」と「許可基準（Permission）」の違いは何ですか？

A. 除外基準は「不正なもの（違反 URL など）があれば弾く」という判定であり、対象が 0 件のときに意図せぬ合格を引き起こします。一方、許可基準は「確定版なら検証済みの根拠を最低 1 つ持っていること」という適格条件を要求する判定であり、根拠が欠落している場合に安全側に倒れて確実に遮断（Fail-Safe Defaults）します。

AI エージェントの導入や開発パイプラインの品質保証、自作品質ゲート・CI 自動化プロセスの設計見直しに関するご相談・お問い合わせは コンタクトフォーム までお気軽にお寄せください。

Footnotes

  1. Vacuous truth Wikimedia Foundation, 2026年確認。数学・論理学における空虚な真の定義（前提条件が偽であるため真となる全称命題）、および部屋の携帯電話の例文。 ↩ ↩2

  2. Array.prototype.every() MDN Web Docs (Mozilla), 2026年確認。空配列に対して true を返し、「vacuously true that all elements of the empty set satisfy any given condition」と定義されている仕様。 ↩ ↩2

  3. Built-in Functions - all() Python Software Foundation, 2026年確認。空のイテラブルに対して True を返す仕様、および for element in iterable: if not element: return False; return True という等価コードの実装構造。 ↩ ↩2

  4. Exit codes - pytest documentation pytest-dev team, 2026年確認。pytest.ExitCode 列挙型の定義、および Exit code 0（全テスト収集・合格）と Exit code 5（テスト未収集）の仕様。 ↩

  5. Jest CLI Options (—passWithNoTests) Meta / Jest Open Source, 2026年確認。--passWithNoTests オプション（テストファイル未発見時に合格を許可）の仕様。 ↩ ↩2

  6. Pull Request #5127: Add suggestion of using —passWithNoTests on no tests found Jest GitHub Repository (emilgoldsmith et al.), 2018年1月マージ。テスト未発見時に --passWithNoTests の使用を提案するメッセージの議論（「If you consider no tests matching your filters correct behavior, use the ‘—passWithNoTests’ option」）と、--findRelatedTests・--lastCommit・--onlyChanged 指定時はテスト未発見でもエラーにしない変更。 ↩ ↩2 ↩3 ↩4

  7. The Protection of Information in Computer Systems — I. Basic Principles of Information Protection Jerome H. Saltzer, Michael D. Schroeder (MIT), 1975年 (Proceedings of the IEEE, Vol. 63, No. 9)。Section I.A.3「Design Principles」の b) における安全設計原則「Fail-safe defaults: Base access decisions on permission rather than exclusion」。 ↩ ↩2

  8. Secure Code Review Cheat Sheet OWASP Foundation, 2026年確認。Authorization 観点における安全側のデフォルト原則「Fail-safe defaults: Default deny access policy」。 ↩

  9. Authorization Cheat Sheet OWASP Foundation, 2026年確認。認可アーキテクチャの基本原則「Deny by Default」およびデフォルト拒否思想の推奨。 ↩