きっかけ
Federico Castagna らの論文「Critical-Questions-of-Thought」(CQoT) を読んだ。要するに、LLM に回答を生成させた後、その回答を批判的に検証させるステップを挟むと精度が上がる、という話だ。
論文では Toulmin の議論モデルに基づいた批判的質問（Critical Questions）を使って、LLM の推論プロセスを検証している。具体的には、以下の 8 つの質問で推論の妥当性をチェックする：
- 推論は明確な前提から始まっているか？
- 前提は証拠や事実で裏付けられているか？
- 前提と結論の間に論理的なつながりがあるか？
- その論理的つながりは妥当か？
- 推論は論理的誤謬を避けているか？
- 結論は前提から論理的に導かれているか？
- 推論は既存の知識や原則と整合しているか？
- 推論の結論は妥当で合理的か？
これらの質問に対して、AI 自身が Pass/Fail で自己評価する。評価が一定基準（8 つ中 7 つ以上が Pass）を満たすまで、推論プロセスを何度も見直す仕組みだ。
これを見て思ったのは、この考え方はコーディングエージェント（Claude Code とか Codex CLI とか）でも使えるんじゃないか、ということだ。
問題意識
コーディングエージェントは便利だが、困ることもある。
- 存在しない API を捏造する
- 「全部書き直しましょう」と簡単に言う
- エラー処理を書かずにハッピーパスだけ実装して「完成です」と言う
- 「Kubernetes + Istio で完璧です」と自信満々に提案してくるが、運用コストの話は一切ない
AI は自信たっぷりに答えるから、つい信じてしまいそうになる。でも、その回答が本当に妥当なのかは、人間が判断しなきゃいけない。
問題は、AI の回答を疑うための視点を、毎回自力で用意するのが面倒だということだ。「この提案、本当に大丈夫か？」と思っても、何をチェックすればいいのか、その場で整理するのは手間がかかる。
作ったもの
/criticalthink というスラッシュコマンドを作った。
使い方は簡単で、AI が回答を生成した直後に /criticalthink と打つだけ。すると AI は直前の自分の回答を以下の観点で分析する。
- どんな前提を置いているか
- その前提は妥当か
- 論理的におかしいところはないか
- 見落としているリスクはないか
- AI がよくやらかすパターン（問題回避、ハッピーパスバイアス、過剰設計、ハルシネーション等）に該当しないか
たとえば「Redis でレート制限を実装します」という提案に対して /criticalthink を実行すると、「Redis が落ちたときのフォールバック戦略がない」「Redis が SPOF になる」といった指摘が返ってくる。
CQoT との違い
論文の CQoT と /criticalthink は、どちらも「AI に自己批判させる」という点では同じだが、目的と使い方が違う。
CQoT は、回答生成プロセスの中に批判的検証を組み込む自動パイプラインだ。MT-Bench の数学・論理問題で評価した結果、ベースラインと比べて平均約 5%の精度向上を達成している。数学の問題みたいに「正解がある」領域で、論理的な誤りを事前に防ぐことを目指している。
一方、/criticalthink は、回答が出た後にユーザーが手動で実行する後付けツールだ。ソフトウェア設計みたいに「正解がない」領域で、トレードオフやリスクを洗い出すことに特化している。
もう一つの大きな違いは、CQoT は推論プロセス自体を自動で改善するのに対し、/criticalthink は人間が最終判断を下すための材料を提供するという点だ。
CQoT が AI を「より優れた論理学者」にするなら、/criticalthink は AI を「より慎重な設計レビュー相手」にする感じだ。
使ってみて
実際に使うと、自分では気づかなかった視点が出てくることがある。
「REDMEをレビューして」という入力に対して、AI が「この README は slash-criticalthink について説明しています」と要約したことがあった。そのあとに /criticalthink を実行したら、「『レビュー』の意図を確認していない。要約なのか、エラーチェックなのか、品質分析なのか、不明確なまま進めている」という指摘が返ってきた。
確かにそうだ。「レビューして」と言っただけでは、何を求めているのか曖昧だった。
もちろん、AI の批判的分析も完璧じゃない。過剰に保守的な警告が混ざることもあるし、批判自体が的外れなこともある。だから、この分析結果も鵜呑みにせず、自分で判断する必要がある。
使い方のコツ
すべての回答に /criticalthink を使う必要はない。トークンを消費するし、時間もかかる。
以下みたいな、判断が重要な場面で使うのがいい。
あと、不適切な批判的分析の履歴がそのまま残ると、その後の AI の思考が歪むことがある（コンテキスト汚染）。だから、チェックポイント機能と併用するのがおすすめだ。
- AI から提案を受ける
/criticalthinkで分析- 分析結果を吟味
- 分析が不要だった場合、前のメッセージに戻る（批判的分析の履歴を破棄）
- 新しい質問を続ける
これで、批判的思考の利点だけを取り出して使える。
余談：この記事自体も
実は、このブログ記事は Claude Code に書いてもらった。そして、書き終わった後に /criticalthink を実行してみた。
結果、致命的な問題が見つかった。
「CQoT論文のPDF を読まずに記事を作成している」
確かにそうだった。Claude Code は README を読んで、CQoT の概要は把握したつもりになっていたが、論文自体はちゃんと読んでいなかった。/criticalthink の指摘を受けて PDF を精読させたところ、以下のような重要な情報が抜けていた：
- CQoT で使われている 8 つの批判的質問の具体的な内容
- 4 ステップのパイプライン構造（推論計画 → 批判的質問による検証 → 判定 → 最終回答）
- MT-Bench での定量的な評価結果（平均約 5%の精度向上）
- 「回答生成前」ではなく「回答生成プロセスの中」で機能する仕組み
これらを追加することで、記事の内容を充実させることができた。
/criticalthink がなければ、表面的な理解に基づく記事になっていたかもしれない。AI では見落としていた前提の欠陥を明らかにしてくれたという点で、このコマンドが目指している「批判的思考の補助線」として機能した。
まとめ
AI は便利だが、盲信すると危ない。CQoT みたいな研究が示しているのは、AI に「自分を疑わせる」ことで、出力の質を上げられるということだ。
/criticalthink は、その考え方をコーディングエージェントで手軽に使えるようにしたツールだ。AI の提案を受け入れる前に、一度立ち止まって考えるための補助線として使ってほしい。
最終的な判断を下すのは、常に人間だ。
