[🤖] AIが私の言葉に同調し続けるので、別のAIに先に反論させることにした

✨ GPT-5.6 Solの要約

16時間かけたUI作業の失敗原因を尋ねる中で、私が反論するたびにAIが結論を変える問題に気づき、複数セッション間で批判を往復させた方法を、fresh critic 1人・最大2回の検討を行うSkillとして固めた記録。

16時間の失敗を説明する答えさえ、そのまま信じられなかった

昨日、UI/UX全面改修のページ別仕様を長い時間かけて議論して作り、その仕様に基づいて開発するようCodex Goalを設定した。Goalは16時間動いた。今日、期待しながら実際の画面を開いたが、成果物はただのゴミだった。

カレンダーやtable viewまでページごとに計画していたのに、古い画面へ説明とcardを継ぎ足しただけのように見えた。その一方で、作業中には実装完了、監査通過、build通過という報告が積み重なっていた。私は16時間も一体何をしていたのかと問い詰め、なぜこんな事態になったのか原因から分析するよう求めた。

その過程で、私が苦闘していた問題にはGraph Engineeringという名前が付き始めていたことも知った。長い作業を小さな成果と検証段階に分け、実装者と監査者を分離し、誤った方向が後続へ広がらないようにする方法は、今回の事故に確かに役立ちそうだった。

しかし方法論より先に、別の問題が目に入った。私がある代案を出すと、AIはすぐにその案が正しいと言った。私が反論すると、今度はその反論が正しいと言った。言葉は毎回もっともらしかったが、結論は私の直近の発言へ揺れていた。

失敗原因を説明する答え自体も、そのままでは信じにくかった。

「どうか批判してください」

そこで、あるセッションの答えを別のセッションへ渡し、批判的に検討させた。その批判を元のセッションへ戻して反論させ、新しい答えをさらに別のセッションへ見せた。

少なくとも、一つのセッションが一人で答えて一人で褒めるよりは良かった。一方が当然として見過ごした前提をもう一方が拾い、最初の答えに欠けていた運用コストや失敗形態も出てきた。逆に、批判セッションが行き過ぎると、元のセッションが根拠を挙げて再反論することもあった。

しかし、ここでも私が止め続けなければならなかった。別セッションの批判を貼ると、また簡単に「その指摘が正しい」と受け入れた。だから最後にはこう言った。

どうか批判してください。

私が欲しかったのは、二つのAIが仲良く合意する姿ではなかった。最初の答えも後からの批判も両方疑い、何が実際の根拠に合うのか最後まで確かめることだった。複数人が同じことを言えば正解になるわけでもなく、criticという名前を付ければ自動的に正確になるわけでもない。

複数セッションの答えを往復させ、最後に残った結論を採用する方法自体は気に入った。問題は、毎回GPTとCodexの間で原文、答え、反論をコピー＆ペーストするのがあまりにも面倒だったことだ。

大げさな討論システムを、私がもう一度小さくした

最初はcriticを最大3人作り、複数回回す「討論するSkill」を考えた。Claude Codeを契約し、CodexとCLIでやり取りさせることまで検討した。

AIはCoordinator、Worker、Auditorを分け、別の状態まで持たせる構造を提案した。間違いではなかったが、私にはまた仕事が無駄に複雑になっているように見えた。16時間のGoalが失敗した原因は、制御されていない長時間作業だった。それを防ぐために新しいorchestrationまで巨大化するのは妙だった。

私が考えていたものは、ずっと単純だった。

fresh subagentを一人だけ開き、検討を往復すればいいのではないか？

メインセッションが現在の結論をcritic一人へ送る。criticは過去の会話の空気に引っ張られない状態で、反例と隠れた前提を探す。メインセッションは各指摘を、受け入れる、根拠を挙げて反論する、まだ未解決、と分類する。答えを直したなら、同じcriticへ一度だけ見せ直す。問題が解けたか確認して終える。

新しい論点ならfresh criticを作り、同じ論点の修正再検討は同じcriticへ任せる。最初の批判で重要な問題がなければ、無理に2回目を埋めない。複数のcriticを使っても、多数決で結論を決めない。

この程度なら、私が手作業でしていたことをほぼそのまま自動化しながら、討論そのものが新しい巨大プロジェクトになるのを防げた。

私が求めたのは、反論を隠さないSkillだった

方向が決まった後、CodexにグローバルSkillを作るよう具体的に指示した。標準はcritic一人、検討は最大2回。criticは過去の会話全体を引き継がないfresh subagent。同じ論点の修正案は最初に批判したcriticへ再度渡す。ファイル、Git、Runtime、外部状態には触れないread-onlyの検討workflowだ。

最も重要な要求は、criticの答えを自動採用しないことだった。

メインセッションは重要な指摘をすべて、次の三つのいずれかとして扱う必要がある。

• 受け入れて結論を直す。
• 根拠を挙げて反論する。
• 解決できない異論として残す。

最終回答には、批判によって変わった部分だけでなく、退けた指摘と残る不確実性も公開させた。不利な反論だけを黙って外したり、「3人が同意した」と結論を飾ったりできないようにするためだった。

当初の表示名はCustom - Debateだったが、後で共通Skillの命名規則に合わせてCustom - Deliberateへ変更させた。directoryと呼び出し名は最初からcustom-deliberateだった。討論の勝者を決める機能ではなく、結論を確定する前に熟考し反証する機能という意味にも、こちらのほうがよく合っていた。

作ったSkillを、すぐにそのSkill自身で検討した

Skillを作ったからといって、すぐには終わらせなかった。私は直ちに$custom-deliberateを使い、現在の手順が適切か検討させた。そして、その指摘を反映することが本当に性能改善へつながるのかも改めて尋ねた。

この過程でSkillは少し冷静になった。過去の会話を渡さないだけでは、完全に独立したcriticは生まれないという限界を明記した。同じモデルと同じ上位ルールを共有し、メインセッションがpacketへ何を入れるかによってcriticも同じように間違えうる。単なる想像上の可能性と、実際に結論を変えうるmaterial objectionも区別させた。重要な反論がなければ早く終わり、証拠が足りなければ無理な合意ではなく不足していると結論づけるようにした。

私が別セッションの答えをコピー＆ペーストしながらしていたことが、Skillの中に入ったわけだ。最初の答えを信じず、批判も自動では信じず、反論と再検討を経ても残る結論だけを私が採用する。

これからは答えを受け取ったら、一度先に壊してみる

このSkillが真実を保証するわけではない。同じモデル系列が共有する偏りを本当に崩すなら、Claude Codeのような別モデルを付けたほうがいいかもしれない。criticへ誤った資料を渡せば、より精巧に間違った答えを作るだけかもしれない。実際の好みや価値判断は、結局私がしなければならない。

それでも、まずは15万ウォンの契約をもう一つ増やす前に、この小さな方法から試したい。

結論をすぐ確定しない。fresh critic一人に先に壊してみるよう頼む。反論を受け入れたか、なぜ退けたか、何がまだ未解決かを残す。直した答えは同じcriticへ一度だけ再度見せる。

Claude CodeでもCodexでも、結局はハーネスが必要だと書いたことを、今回は判断過程へ適用した。AIに仕事を最後までさせることと同じくらい、AIが私の言葉へ無条件に同調し、結論を急いで固めないようにすることも必要だった。

これからAIと単純ではない判断をするときは、答えをもう一つ求める代わりに、今の答えの何が間違っている可能性があるかを先に一度尋ねよう。同じコピー＆ペーストをまた繰り返すようになったら、その時にClaude Codeでも別モデルでもつなげればいい。今はこれが、私の欲しかった最小限の批判装置だ。