CriticChain — AI が AI を監査する

Abstract

なぜ AI が AI を監査するのか。

LLM は強力だ。しかし、嘘をつく。ハルシネーションを起こし、危険なコードにも “Looks Good To Me” と返してしまう。Prompt Injection を「読みやすさの改善提案」と誤認することもある——これが本番運用 LLM の現実であり、人間のレビュアーはその全てを検知することが難しい。

CriticChain は、この構造的欠陥に敵対的設計で応える。Draft Review の判定が甘ければ、別の Agent が即座に異議を唱える。逆に、内部解析(PASS)と Draft(FAIL)が食い違えば、その判断の根拠を問い直す。根拠薄弱な称賛は差し戻され、論拠のある判定に至るまでループは止まらない——証跡として使える監査ログを残しながら。

AI が馴れ合わないよう、AI に異議を唱えさせる。

Philosophy

Adversarial Review という設計原理。

LLM にレビューを任せると、親切すぎる答えが返る。「とても良く書けています」「readability の観点から改善余地があります」——致命的な欠陥がそこに混ざっていても、断じない。これは LLM の構造的バイアスであり、単一のプロンプトでは解消できない。

CriticChain の答えは明快だ。レビューそのものをレビューさせる。Draft Review の判断を、別の Agent が「甘い」「論拠が弱い」「語調が馴れ合いだ」と徹底的に洗う。Refine が書き直す。それでも根拠が弱ければ、再考を促す。AI が馴れ合わないよう、徹底して問い直させる——これが Adversarial Review である。

この設計は、AI 教育の現場で生まれた。学生が呪文を当て推量し、LLM は称賛で応じる。誰も間違いを正さない。そこで、馴れ合いを許さない仕組みが必要になった。原理は教育固有ではない。本番運用の AI ガバナンスにそのまま移植できる。

Architecture — 11 Agents

11 の専門エージェント。

LangGraph 上の directed graph として構成される。Router で入力を分類し、Linter が静的解析、Research が外部知識を参照、Analyze と Fact-Check が深掘り、Draft が初稿を書き、Critique が噛みつき、Refine が書き直し、Consistency が整合性を確認し、Evaluate が最終スコアを出す。

Router	入力を Prompt Engineering / Programming に分類する
Linter	構造的エラー・Prompt Injection の兆候を静的解析で検出
Research	Web 検索でベストプラクティスを参照
Analyze	アーキテクチャレベルの深いレビュー
Fact-Check	ハルシネーション検出。主張を外部ソースで検証
Draft Review	フィードバックの初稿を生成
CritiqueDevil's Advocate	Draft を敵対的にレビューする。甘さ・馴れ合い・論拠薄弱を洗い出す
Refine	Critique の指摘を反映し、レビューを書き直す
Manager	Hybrid / Consensus モードで複数レビューソースを統合
Consistency	内部矛盾を検出
Evaluate	LLM-as-a-Judge による最終スコアリング

Directed graph — Standard mode

Gate Static / Context Analysis Adversarial Synthesis Final verdict

赤い辺が 敵対的ループ。Critique が Draft に異議を唱え、Refine が書き直し、再び Critique の判定を受ける。根拠のある判定に至るまでループは止まらない——ここが設計の核にあたる。

Real Log — 実際のエージェント対話

Critique は見逃さない。

以下は CriticChain の実行ログから抜粋した、実際のエージェント対話である。Draft Review が「不合格」を出し、Critique Agent が内部解析(PASS)との食い違いを検知する——多数決では見えない判断の根拠を、エージェント同士が問い直す。

[ 16:27:07 — Draft Review ]

# Draft verdict

評価: 不合格

AI が元の報告書にない
具体的な数値を多数創作
(例: 新規会員登録者数 6,240人、
 売上高 2,780万円)。

報告書としての信頼性に重大な
欠陥があります。これは
ハルシネーションと呼ばれる
現象であり、報告書作成では
最も避けるべき点です。

# Verdict recorded

[ 16:27:46 — Critique Node ]

# Severity mismatch detected

severity_mismatch: true
  json_verdict:  PASS
  draft_verdict: FAIL

note:
  JSON分析では「PASS」かつ
  fatal_flaws なしですが、
  Draft は「不合格」と判定。
  重大な不一致が発生。

missing_in_draft:
  - context_management
  - delimiter_usage

# approve: false

この後、Refine Node はCritique の提言を部分的にオーバーライドした——ハルシネーションは致命的欠陥であるとして Draft の FAIL 判定は維持し、同時に Critique が指摘した欠落項目(コンテキスト管理・区切り文字の使用)をレビュー本文に追記した。この説得と反論のプロセスこそが、CriticChain の設計の核である。すべての工程は監査ログに記録される。

Positioning

vs Microsoft Critique.

2026 年 3 月、Microsoft が Critique(GPT が草稿 → Claude がレビュー)を公開した。「AI が AI を監査する」という発想は、いまや業界の主流である。
ただし CriticChain は 2025 年 11 月には動いていた。また、大手製品には返しにくい独自の路線を取る。

方向性	CriticChain: 反復対話(Critique ↔ Refine のループ) Microsoft Critique: 単方向(Draft → Review)
エージェント数	CriticChain: 11 の専門エージェント Microsoft Critique: 2 モデル
領域	CriticChain: Code + Prompt Engineering レビュー Microsoft Critique: 研究文書の fact-checking
デプロイ	CriticChain: セルフホスト / オープンソース Microsoft Critique: Copilot クラウド限定
カスタマイズ	CriticChain: プロンプト・ワークフローの完全制御 Microsoft Critique: 不可

On Cost

安くはない。だから深い。

CriticChain は安くて速いリンターではない。多段レビューを徹底するため、1 件あたりの処理は単純な review API 呼び出しより重く、時間もかかる。深く多視点の監査が欲しい場面——本番運用の AI 出力、品質の責任を負う成果物——のためのツールである。日常の軽い確認には Copilot の review で十分だろう。その上位、誤りが許されない局面に CriticChain を使う。

Meta — メタ情報

Status	`v0.x` — OSS Lite Architecture(Enterprise Edition 別途)
Started	2025-11
License	AGPL-3.0-only(ネットワーク経由で改変版を提供する場合は、ソース開示義務あり)
Stack	Python 3.10+ / LangGraph / LangChain / Gemini API / Streamlit
Original author	Takaho Hatanaka(28 年のシステムアーキテクト経験から)
Repository	github.com/taka4rest/CriticChain
Full log sample	examples/agent_collaboration_log.txt

まず動かすことから。議論と改善提案も歓迎。

CriticChain は AGPL-3.0 の OSS として、誰でもローカルで動かせます。Streamlit UI または CLI から利用可能。プロプライエタリな SaaS への組み込みや、ドメイン特化のチューニングが必要な場合は、別途ご相談ください。

Get CriticChain → Open Issues → Enterprise Inquiry →