AI エージェントに記事執筆や技術ドキュメントの作成を任せ、その品質を担保するために自動検証や設計レビューの品質ゲートを組み込む運用が増えています。しかし、ゲートからの指摘を受けて修正を重ねるたびに新たな不整合が発生し、差し戻しループが何周も続いて一向に成果物が公開されない「レビューループの迷走」に直面したことはないでしょうか。

当リポジトリの執筆パイプライン運用において、まさにこの迷走が発生しました。同一の社内調査資料から起こした 2 つの企画が、詳細設計と検証レビューを合計 5 周回し、13 ファイル・1,427 行の仕様成果物を生成しながら、公開用の初稿本文は 1 文字も書かれないまま不採用・破棄となったのです。

企画段階での論証可能性判定とは、AI エージェントに設計・執筆ループを回させる前に、看板主張（記事の中心命題）が反例 1 つで崩れないか、崩れないように留保を重ねると同語反復（自明な命題）に縮まないかを企画の最上流で事前検証し、破綻する企画を早期に遮断（Fail Fast）するゲート設計です。

品質ゲートで不採用になること自体は失敗ではありません。真の損失は、下流で修正を繰り返しても救いにくい欠陥を抱えた企画に対し、長時間のレビュー周回とコンテキストを浪費してしまうことです。本記事では、この 2 企画・通算 5 周・本文 0 文字の破棄ログを一次データとして開示し、なぜ「不可能性や限界」を看板に据えた企画は収束しないのか、そして下流の対症療法に委ねず企画段階で論証可能性を判定して早期に止める（Fail Fast）ための判断基準を解説します。

成果物1,427行・本文0文字で消滅した2つの企画

当リポジトリの執筆パイプラインでは、同一の調査資料を素材として 2 回の企画立案と設計レビューを試行しました。題材は、AI エージェントの記憶設計で、記憶の優先度を 1 本の忘却曲線（減衰曲線）で表す設計の是非です。しかし、いずれの企画も執筆工程に到達することなく、設計検証の段階で打ち切られ、不採用（ボツ）となりました。

その全容を客観的に示すのが、当リポジトリに残された一次計測ログの実測データです。

指標先行企画（試行 1）再企画（試行 2）通算合計
Issue 作成日時 (UTC)2026-08-05 02:15:26Z2026-08-05 16:07:19Z-
クローズ日時 (UTC)2026-08-05 09:44:05Z2026-08-05 23:29:53Z-
経過時間7 時間 28 分 39 秒7 時間 22 分 34 秒21 時間 14 分 27 秒（先行企画の起票から再企画のクローズまで。同一日内）
レビュー周回数2 周3 周5 周
打ち切りの契機中断条件4（再発）該当Hard Stop 到達＋中断条件4 同時該当-
ユーザー選択不採用（ボツ）1 回目: 縮小して続行 / 2 回目: 不採用-
生成された成果物行数509 行918 行1,427 行（13ファイル）
公開用初稿の文字数0 文字0 文字0 文字
重要度「高」の指摘件数3 件（1周目: 2件, 2周目: 1件）7 件（1周目: 3件, 2周目: 1件, 3周目: 3件）10 件

※経過時間は Issue の起票からクローズまでのタイムスタンプ差であり、実作業時間ではありません。

特筆すべきは、2 企画合計で 1,427 行（企画書、調査書、設計書、検証レポートなど計 13 ファイル）もの仕様成果物を生成したにもかかわらず、公開用の初稿本文は 1 文字も書かれなかったという点です。

検証レポートは、「周回数」と「同じ欠陥クラスの再発か」の 2 軸で判定を記録します。周回数が上限の 3 周目に達すると Hard Stop、前の周と同じ欠陥クラスの指摘が再発すると中断条件4 に該当し、続行・縮小・不採用のどれを選ぶかは人間（オーナー）が決めます。5 本の検証レポートには、次のような判定行が記録されていました（抜粋）。

  • 先行企画 2 周目: 中断条件4（再発）: 該当（「独立に到達した」という看板主張のヘッジ不足が再発。…同一欠陥の別箇所への移動）
  • 再企画 2 周目: 中断条件4（再発）: 該当（…『主張が自分の提示する論証より強い』というヘッジ不足が、…本文から看板主張・見出しへ移動しただけで解消していない。…）
  • 再企画 3 周目: Hard Stop: 到達（3 周目） / 中断条件4（再発）: 該当（…看板主張から…中核論証へ再び移動しただけで解消していない。同じ欠陥が…先行企画 #64 を含めると通算5周連続で発生している）

検証ゲートは合計 10 件の重要度「高」指摘を検出し、同一欠陥の再発と上限周回数への到達を判定行に記録しました。それを受けてオーナーが不採用を選び、執筆には進みませんでした。

直すたびに移動する欠陥──なぜ1周ごとの独立採点では止まらないのか

なぜ、レビューと修正を重ねても議論が収束しなかったのでしょうか。その原因は、指摘に対応するたびに欠陥が形を変えて別の場所へと移動していたことにあります。

5 周にわたる重要度「高」指摘の移動経路を辿ると、修正のたびに欠陥の所在が目まぐるしく変化していることが分かります。

  1. 先行企画 1 周目（本文・導入）: 先行企画のタイトルは「AIエージェントの記憶設計に『1本の忘却曲線』では足りない──howm(2002)とautograph(2026)が独立に到達した結論」でした。このうち「2 つの先行事例が互いを知らずに独立して同じ結論に到達した」という看板主張に対し、無裏付け・反証不可能であると指摘。
  2. 先行企画 2 周目（見出し）: 本文には留保（ヘッジ）を追記したものの、記事タイトルと見出しが無留保の断定表現のまま残存し、見出しへ欠陥が移動。
  3. 再企画 1 周目（中核論証）: 企画を再構成したものの、「特定ツールの挙動は関数の符号反転では表現できない」という論証自体が自己矛盾していると指摘。
  4. 再企画 2 周目（看板主張）: 論証の矛盾を解消すべく「関数としては容易に反転を作れる」と自ら認めた結果、大元の看板主張である「1つの関数では1方向しか表現できない」という前提が本文によって論破される事態が発生。
  5. 再企画 3 周目（中核論証）: 看板を維持しようとした結果、本文の別の節に「どう変形しても作れない」という無条件の不可能主張が再出現。

「本文 → 見出し → 中核論証 → 看板 → 再び中核論証」という 5 周の軌跡が示すとおり、指摘の所在は毎回変わり、種類は同じでした。少なくとも再企画 2 周目では、指摘箇所の修正（関数としては反転を作れると認めたこと）が大元の看板主張と矛盾し、別の箇所の破綻として現れたことを検証レポート自身が記録しています。

ここに、AI レビューループの重大な罠があります。

もしレビューループに周回をまたいだ再発検知がなく、各周回を「独立したテスト」として採点していると、1 周目は「本文の裏付け不足」、2 周目は「見出しの表現不一致」、3 周目は「関数の定義矛盾」というように、毎回異なる指摘が出ているように見えます。その結果、「修正は着実に進んでいる」と錯覚し、無限に修正指示を出し続けてしまうのです。

しかし、構造的な視点で見れば、これらはすべて「本文の提示する論証よりも看板主張が強すぎる」という 単一の欠陥クラス が場所を変えて生き残っていたに過ぎません。

外部オラクル（ユニットテストやコンパイラのような客観的判定器）を持たない自然言語の推論タスクにおいて、モデル自身の自己対話だけで論理の破綻を修正することは難しいと考えられます。Huang et al. (2024) は、外部フィードバックのない内在的自己修正（intrinsic self-correction）では推論性能が向上せず、自己修正の後にかえって性能が劣化する場合もあることを示しています1。

また、Anthropic のエージェント評価ガイドでも、客観的な評価機構を持たないチームは「1 つの失敗の修正が別の失敗を生む」リアクティブループ（reactive loops）に陥ると警告されています2。Evaluator-Optimizer パターンが特に有効とされるのも、評価基準が明確で、反復改善が測定可能な価値をもたらす場合です3。

強く書けば反証され、正確に書けば自明になる──不可能性看板のジレンマ

再企画のクローズコメントは、この 5 周の迷走の原因を、エージェントの文章力や修正プロンプトの不備ではなく、企画の看板主張そのものにあると見立てています。

2 つの企画が一貫して看板に据えていたのは、「1 本の忘却曲線では足りない」という、単一のモデルでは記憶の優先度を表現しきれないとする 不可能性や限界の主張 でした。

不可能性や限界を看板に据えた企画には、宿命的なジレンマが存在します。

  • 強く書けば反証される: 「〜は不可能である」「〜では作れない」という強い否定命題は、反例（代替関数や変形モデル）が 1 つでも示されれば即座に論破されます。
  • 正確に書けば自明になる: 反論を避けるために正確な条件や前提を付け足して留保（ヘッジ）を重ねると、最終的には「全レコードに同じ関数を一律適用すれば、レコードごとの個別制御はできない」という、定義上当たり前の同語反復（トートロジー）に縮んでしまいます。

このジレンマは、再企画の 2 周目においてユーザーが「企画を縮小して続行」を選択した際の実測ログに鮮明に記録されています。

2 周目の指摘を受け、企画書では看板主張を次のように縮退させました。

1 本の減衰曲線を全レコードに一律適用する設計では、優先度を動かしたい方向を全部は表現できない。

しかし、この縮小に対して 3 周目の検証レポートが下した指摘は、極めて痛烈なものでした。

「全レコードに一律に同じ振る舞いを当てると、レコードごとに違う振る舞いは出せない」という、定義上ほぼ自明な命題 に縮んでいる。

このときのクローズコメントには、構造的な原因の見立てが次のように総括されています。

強く言えば 1 - f(t) の存在で反証され、正確にヘッジすると「一律に同じ振る舞いを当てれば一律にしかならない」という自明な命題に縮む。この往復から抜ける道が、企画の枠内には無かった。

ここでの f(t) は時間とともに優先度を下げる減衰曲線で、1 - f(t) はそれを反転して時間とともに上がる曲線です。

Madaan et al. (2023) の Self-Refine は、文体変換やコード最適化などのタスクで、自己フィードバックによる反復改善を報告しています4。しかし、論証可能性と主張強度のトレードオフという企画レベルの構造的矛盾は、今回の 5 周では本文や設計書の反復修正で解消しませんでした。

看板主張は、本文の論証が正直に支えられる強さに縮める必要があります。支えきれない看板を掲げたまま下流へ進めば、反証と同語反復の間を往復するだけの不毛な周回を重ねることになります。不可能性の代わりに看板へ据えやすいのは、「こう作った」「こう壊れた」という、手元の実測ログで確かめられる記述です。

教訓と処方箋: 企画段階での論証可能性判定（Fail Fast）

この失敗から得られた最大の教訓は、「修正の層」を見極め、企画層の欠陥は企画の最上流で遮断する（Fail Fast） という原則です。

欠陥には明確な階層が存在します。

  1. 文言層: 誤字脱字、表現の揺れ、フォーマット違反など（下流の文章修正で容易に解消可能）。
  2. 構成層: 章立ての順序、具体例の不足、説明の飛躍など（設計書の章立て変更で解消可能）。
  3. 企画層: 看板主張の論証可能性、前提の反証容易性、客観的オラクルの不在など（本文や設計書の修正では解消しにくい）。

下流の執筆工程で企画層の欠陥に対処しようとすると、レビューの指摘を満たすために「〜と断定しないこと」「〜の例外を併記すること」といったネガティブな制約ルールが雪だるま式に積み上がっていきます。これは 制約の積み増しによる文章の死滅（Constraint Tax）を検証した過去記事 でも詳述した現象です。制約の網を厳しくすればするほど、エージェントの生成する文章は過剰に抑制され、主張のない無難で退屈な文章へと死滅していきます。

ソフトウェア工学の古典である Jim Shore (2004) の「Fail Fast」原則は、問題を自動的に迂回して動き続ける（遅延失敗: failing slowly）のではなく、問題が起きたその場で即座に、目に見える形で失敗させることの重要性を説いています5。

AI パイプラインにもまったく同じ原則が当てはまると考えます。設計検証や執筆工程という下流で何周も修正を回して遅延失敗させるのではなく、企画段階で看板主張のアサーション（事前検証）を行い、論証不能な企画を即座に破棄すべきです。また Andrew Ng (2024) は、自己反省にとどまらず、ユニットテストの実行や Web 検索といったツールで出力を評価させる方法を挙げています6。

企画ゲートで点検すべき「論証可能性の3つの問い」

企画段階で看板主張を検査するために、以下の 3 つの問いをアサーションとして組み込みます。

  1. 反証容易性: 看板主張に「1 つでも反例があれば崩れる無条件の不可能命題（〜は不可能、〜では足りない）」が含まれていないか？
  2. 同語反復への退行リスク: 反証を避けるために正確な留保（ヘッジ）をつけたとき、「定義上当たり前の自明な命題」に縮んでしまわないか？
  3. 一次情報の存在: その主張を支える客観的オラクル（自社の実測ログ、検証コード、公開メトリクス）が手元にあるか？

今回の 2 企画に当てはめると、問い 1 は企画の時点で引っかかります。先行企画のタイトル「1本の忘却曲線では足りない」は、それ自体が無条件の不可能命題だからです。一方、問い 2 は記録上、再企画 2 周目で縮小した看板が 3 周目に「定義上ほぼ自明」と指摘されるまで表に出ませんでした。企画段階で問い 2 を当てるには、看板を一度留保付きの形に書き下ろし、その文が自明かどうかを人間か別の LLM に判定させる 1 手が要ります。設計書と検証レポートを何周も回すより、この 1 手のほうが安く済むと考えます。

企画アサーションの疑似ロジック

以下は、3 つの問いを判定項目として構造化し、該当する企画をその場で止める流れを示した概念モデルです。各フィールドの真偽値はコードが判定するのではなく、企画段階で人間か LLM が埋めます（例: 看板の文面に「〜では足りない」のような無条件の否定が含まれていれば has_universal_negation を真にする）。実行例の has_primary_evidence=False は、再企画のクローズコメントが、この運用ログこそ記事に最後まで欠けていた一次情報だったと記録していることに対応します。

from dataclasses import dataclass


@dataclass
class ProposalClaim:
    claim_text: str
    has_universal_negation: bool    # 「〜は不可能」「〜では足りない」等の無条件否定
    hedged_text: str                # 反論を避けるための留保付き表現
    is_tautology_when_hedged: bool  # 留保をつけると自明な命題に縮むか
    has_primary_evidence: bool      # 手元に客観的な実測データやコード差分があるか


class PlanningGateError(Exception):
    """企画段階で論証不能と判定された場合のエラー"""
    pass


def assert_provable_claim(proposal: ProposalClaim) -> None:
    """企画看板の論証可能性を事前判定し、早期破棄（Fail Fast）するアサーション"""

    # 検査 1: 反証容易性のチェック
    if proposal.has_universal_negation:
        raise PlanningGateError(
            f"Fail Fast: 看板主張 '{proposal.claim_text}' は無条件の限界・不可能を主張しており、"
            "反例（代替関数等）が 1 つ示されれば崩れます。"
        )

    # 検査 2: 同語反復（トートロジー）への退行リスクのチェック
    if proposal.is_tautology_when_hedged:
        raise PlanningGateError(
            f"Fail Fast: 看板主張を正確に留保した表現 '{proposal.hedged_text}' は、"
            "定義上自明な同語反復に縮んでおり、読者に提供する独自の価値がありません。"
        )

    # 検査 3: 一次情報オラクルの存在チェック
    if not proposal.has_primary_evidence:
        raise PlanningGateError(
            f"Fail Fast: 主張 '{proposal.claim_text}' を支える客観的な一次ログ（実測・コード差分）が不在です。"
        )


# 企画判定の実行例（概念モデル）
if __name__ == "__main__":
    flawed_proposal = ProposalClaim(
        claim_text="AIエージェントの記憶設計に1本の忘却曲線では足りない",
        has_universal_negation=True,
        hedged_text="全レコードに一律適用するとレコードごとの差は出せない",
        is_tautology_when_hedged=True,
        has_primary_evidence=False,
    )

    try:
        assert_provable_claim(flawed_proposal)
    except PlanningGateError as e:
        # 下流（詳細設計や執筆）へ進めず、最上流の企画段階で即座に破棄（Fail Fast）する
        print(f"[REJECTED AT PLANNING] {e}")

この疑似コードは、設計意図を読者に明示するための概念モデルです。重要なのは、エージェントが詳細設計書や本文を書き始める前に、看板主張が「強い反証リスク」と「自明な同語反復」の狭間に陥っていないかを判定し、該当する場合は迷わずその場で企画を遮断することです。

ゲート設計の比較とトレードオフ

エージェントの暴走や迷走を防ぐアプローチは複数存在しますが、介入するフェーズによって発生するコストと成果物の質は劇的に異なります。

ゲート方式介入フェーズ主な停止契機トレードオフ・限界
企画段階の論証可能性ゲート (Fail Fast)企画（最上流）不可能性看板・自明な命題・客観的オラクル不在企画の通過率は下がるが、手戻りコストとコンテキスト浪費を大きく減らせる
設計検証の停止装置 (Hard Stop / 再発検知)設計・検証（中流）周回数上限（3 周）または同一欠陥クラスの再発下流での執筆浪費は防げるが、設計書作成と数周のレビューコストは消費する
下流での制約積み増し (対症療法)執筆・校閲（下流）禁止ルールやチェック項目の追加修正を強行できるが、主張が平坦化し無難で退屈な文章に死滅する（Constraint Tax）

下流での対症療法に頼るほど、修正コストは増大し成果物は痩せ細ります。周回数ではなく欠陥クラスの再発で判定する設計を論じた過去記事 でも触れたとおり、設計検証での停止装置（Hard Stop や再発検知）を安全弁として維持することは不可欠です。しかし、真に防ぐべき論理破綻は、そもそも設計書を書かせる前──企画段階のゲートで落とすのが最も経済的です。

よくある質問（FAQ）

Q1: なぜレビュー周回数の上限（Hard Stop）だけでは不十分で、企画段階のゲートが必要なのですか？

周回数上限（3 周など）は優れた安全弁ですが、上限に達するまでに設計書の生成、検証レポートの作成、コンテキストの再読み込みによる時間とトークンが確実に消費されます。今回の実測でも、打ち切りまでに 1,427 行の仕様成果物が生成されました。また、下流で部分修正を重ねても欠陥が別の場所へ移動するだけで本質的な論理破綻は解消されないため、上流で企画そのものの成立可否を判定して手戻りを未然に防ぐ必要があります。

Q2: 不可能性や限界を看板に据えた記事は、なぜ自己修正ループで収束しないのですか？

「〜は不可能である」という主張は、1 つでも例外や代替解法が存在すれば論破されるため、強く書くと反証されます。一方で、反論を避けるために条件をつけて正確に留保すると、「特定の前提下ではその振る舞いしか出ない」という定義上自明な同語反復に縮んでしまいます。主張の強度と論証の成立が両立しない構造的ジレンマに陥るため、プロンプトの修正をいくら繰り返しても収束しません。

まとめ──失敗の運用ログそのものを一次資産にする

AI エージェントを活用したコンテンツ制作やドキュメント開発において、レビューループの迷走を防ぐための原則は以下の 4 点に集約されます。

  • 看板の命題化: 「こうでなければならない」という不可能性や限界の規範を看板にせず、「こう作った」「こう壊れた」という検証可能な実測ログを看板に据えること。
  • 同一欠陥の再発検知: レビューループを 1 周ごとに独立採点せず、周回をまたいで同一の欠陥クラスが場所を変えて移動していないかを監視すること。
  • 最上流での Fail Fast: 修正の層が「企画」にある欠陥は下流の文章修正では閉じにくいため、企画段階で論証可能性を判定して早期に破棄すること。
  • 失敗ログの一次資産化: 破棄された企画の成果物や検証記録を捨てずに保持することで、次の設計や別記事の貴重な一次情報へ転化できること。

今回の 2 つの企画は、本文が 1 文字も世に出ないまま破棄されました。しかし、5 本の検証レポートに記録された判定行、欠陥の移動経路、そして「強く言えば反証され、正確に言えば自明になる」というクローズコメントの見立てそのものが、本記事を支えるかけがえのない一次データとなりました。

AI エージェントを活用した開発プロセスの標準化、品質ゲートや停止装置のアーキテクチャ設計、あるいは自律パイプラインの運用見直しについて、ぜひ コンタクトフォーム よりお気軽にご相談ください。

Footnotes

  1. Large Language Models Cannot Self-Correct Reasoning Yet Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song, Denny Zhou。2023年10月3日（arXiv:2310.01798）、ICLR 2024採択。外部フィードバックのない内在的自己修正（intrinsic self-correction）の困難さと、自己修正後に性能が劣化する場合があることは Abstract。 ↩

  2. Demystifying evals for AI agents Anthropic Engineering。2026年1月9日。評価機構がない場合に「1つの失敗の修正が別の失敗を生む」リアクティブループ（reactive loops）に陥る警告は “Introduction” 節。エージェント評価の構成要素（Task, Trial, Transcript, Outcome）は “The structure of an evaluation” 節。 ↩

  3. Building Effective AI Agents Erik Schluntz, Barry Zhang（Anthropic）。2024年12月19日。Evaluator-Optimizer ワークフローの定義と有効な条件（明確な評価基準・反復改善価値）は “Workflow: Evaluator-optimizer” 節。 ↩

  4. Self-Refine: Iterative Refinement with Self-Feedback Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, Shashank Gupta, Bodhisattwa Prasad Majumder, Katherine Hermann, Sean Welleck, Amir Yazdanbakhsh, Peter Clark。2023年3月30日（arXiv:2303.17651）、NeurIPS 2023採択。単一の LLM を生成者・フィードバック提供者・修正者として使う反復改善の仕組みは Abstract。 ↩

  5. Fail Fast Jim Shore（Martin Fowler’s Design column）。IEEE Software, Vol. 21, Issue 5, pp. 21–25, 2004年9/10月号。DOI: 10.1109/MS.2004.1331296。問題を自動的に迂回して動き続ける遅延失敗（failing slowly）と、その場で目に見える形で失敗させる fail fast の対比は p. 21。アサーションの活用は pp. 22–24。 ↩

  6. Agentic Design Patterns Part 2: Reflection Andrew Ng（DeepLearning.AI / The Batch）。2024年3月27日。Reflection パターンの基本構造と、自己反省に加えてユニットテストや Web 検索などのツールで出力を評価させる方法の紹介。 ↩