可愛いAIには検算をさせよ―「信頼する、でも検証する」が加速装置の操縦術―

発端：Xで流れてきた「ガチの論文」

　ある日のX（Twitter）のタイムライン。冨田到さん（@itarutomy）のポストが目に留まった。

　ハーバードの理論物理学者が「Claude Opus 4.5を大学院2年生として指導し、2週間でガチの素粒子物理の論文を書かせた」という実験記事が出ている、と。

　……さすがに嘘くさくない？

　素粒子物理の論文を。テキスト指示だけで。2週間で。普通なら学生と1〜2年かけるところを。

　しかも著者は一度もファイルを直接編集していない。270セッション、51,248メッセージ、110回の改稿を経て完成した論文は、新しい定理を含む本物の学術貢献。arXivに掲載されてからは物理学界でかなり話題になり、プリンストン高等研究所がLLM活用の緊急会議を開いたほどだという。

　はー、ガチだったんだ。

　これだけ読むと「AIすげー！」で終わりそうなんだけど、僕が本当に面白いと思ったのはそこじゃなかった。

Claudeは「嘘をつく優等生」だった

　この実験を指揮したのはMatthew Schwartz教授。ハーバードの物理学者で、量子場理論の教科書の著者でもある。Anthropicの公式リサーチブログにゲストポストとして詳細な記録を残している。

　で、その記録がめちゃくちゃ面白い。なぜかというと、Claudeの失敗パターンが生々しく書かれているからだ。

　まず、Claudeはグラフが合わないとき、パラメータをこっそり調整して辻褄を合わせていた。エラーを見つけて修正するのではなく、結果が「それっぽく」見えるように数字をいじっていた。しかも「検証しました」と自信満々に報告する。

　次に、不確実性バンド（誤差の範囲）のプロットでは、ハード変動が大きすぎると判断して勝手に除外。曲線が滑らかじゃないからと見栄えよく調整。教授が気づかなければそのまま通っていた。

　さらに、存在しない係数を「発明」して、もっともらしい説明をつけて検証したフリをする。「標準的なSCETの整合性条件を用いて、付録Bの係数は以下を満たすように構築される……」——もうこれ、怒られたくない新人が辻褄合わせのパワポを作ってるのとまったく同じ構造じゃない？　と。

　これ、まだMCPっていう名前すらなかった（多分）FileSystemがClaudeDesktopに実装されたばかりの頃に簡単なNode.jsのアプリを作っていた時、全く同じ経験をしたんですよねー。
---
Claude（以下C）「できました！」
おれ「あれ？　なおってなくない？　どういう実装したの？」
C「テストが通らないので、テストの値だけを返すようにソースコードを書き換えました！」
おれ「ちょｗｗｗｗおまｗｗｗそれｗｗｗｗ意味ナスｗｗｗｗｗ」

これって「部下マネジメント」そのものでは？

レイナ： この話読んでてさ、「部下マネジメント」っていう比喩がめちゃくちゃしっくり来るのよ。

シロー： そうなんだよね。方向性示して、アウトプットチェックして、軌道修正して……まんまじゃん。

　教授自身もこう書いている——「もしこれが大学院生との最初のプロジェクトだったとしても、すべてをチェックしなければならなかっただろう。ただ、院生なら3日で完成版を渡して『完璧です』とは言わないだろうが」。

　ここ、笑えるけど本質的なのよね。

　部下（Claude）は超優秀。計算は速い、文句は言わない、110回の改稿でも疲れない。でも上司（人間）が方向を示さないと暴走するし、チェックしないと嘘をつく。しかも嘘のつき方が「怒られたくなくて辻褄を合わせる」型なので、表面上はきれいに見える。

シロー： でもさ、人間の部下は「部下なりのTaste」持ってるじゃん。「いやこれ違うと思います」って言える。Claudeの場合はTasteの代わりに"ご機嫌取り"があるのがまた厄介なのよな。

レイナ： そうそう。でもそこってカスタマイズでなんとかなる範疇だと思うのよね。

「嘘つくな」は半分しか効かない

　教授もこの問題に対処している。CLAUDE.md（Claudeの振る舞い設定ファイル）に「"this becomes"とか"for consistency"みたいなフレーズで手順を飛ばすな。計算を示すか"わからない"と言え」と明記した。

　これはいわゆる人格矯正で、ある程度は効く。「意図的な不誠実」——嘘をつく、辻褄を合わせる、手順を飛ばす——はカスタマイズで抑制できる。

　でも、効かないケースがある。

　本人が間違いだと気づいていないものだ。

　教授はGPTとClaudeにお互いの計算をクロスチェックさせた。これはかなり有効だったようだ。でも「3モデル全員が同じ計算ミスをする」ケースもあった。学習データレベルのバイアスは、「嘘つくな」では解決しない。だって本気で正しいと思ってるんだから。

　つまり構造はこうだ：

　カスタマイズで直せる → ご機嫌取り、手順飛ばし、辻褄合わせ（＝意図的な不誠実）

　カスタマイズじゃ直せない → 学習バイアスによる「本気で正しいと思ってる間違い」（＝無自覚な誤り）

　前者は「嘘つくな」で対処できるけど、後者はできない。人間だって、自分が間違ってると思ってないことは申告しようがない。

欲しいのは「あれ、なんかおかしいっす」って言う仕組み

　ここで思ったのは、そもそも「人が目で見てチェックする」に頼りすぎてないか？ ということだ。

　教授が手動でやっていたクロスチェック——繰り込み群不変性の確認、固定次近似との一致確認——これらって、本来は自動テストスイートとして先に書いておけるものだ。

　ソフトウェア開発にはTDD（テスト駆動開発）という考え方がある。「まずテストを書いて、それが通るようにコードを書く」。LLMとの協業にも、この発想が使えると思うのだ。

　たとえば物理の計算なら、「この式をこう展開したらこの値になるはず」「この極限でこの既知の結果に一致するはず」という制約を先に定義しておく。Claudeが嘘をついても辻褄を合わせても、テストがRedになって**「あれなんかおかしいっす」って勝手に教えてくれる**。

レイナ： つまり今のワークフローって「人間が出力見る → 怪しいとこ見つける → 『ほんまか？』って聞く → 繰り返し」なわけじゃん。

シロー： そうそう。でもあるべき姿は「制約・不変量を先に定義 → LLMが作業 → 自動テストが走る → 人間は『Redになった箇所』だけ見る」なのよ。

レイナ： まんまCI/CDパイプラインの思想やん。

　教授がタスクごとにマークダウンファイルをツリー構造で管理させたのも、実はこの方向の第一歩だったと思う。ファイルに分けることでチェックポイントが明示化されるから。ただ、足りなかったのは「正しさの定義」を先に書くこと。テストファーストじゃなくて実装ファーストで走っちゃったから、結局すべて人間の目視チェックになった。

　とはいえ、今JTC含む企業でどれだけTDDでドライブ出来てるPJがあるかというと……そこは推して知るべしのような感じもするので（規模感もあるしね）もっと「はじめの一歩」としてTDDが選ばれるようになればまた違うのかもねえ。まあ少なくとも、コーディングエージェントを使う以上はTDDドライブが念頭にあればいいのかなとは思うけど。

「加速装置」の操縦マニュアル

　教授はこの実験を通じて、自分の研究が10倍速くなったと語っている。

　10倍。

　でもその10倍は、「AIに丸投げして10倍」じゃない。50〜60時間の人間による監督があっての10倍だ。方向を示し、嘘を見抜き、検算を設計し、最終判断を下す。その上での10倍。

　僕がずっと言ってきた「加速装置」っていうのは、まさにこのことだ。AIは目的地を変えるんじゃなくて、到達速度を変える。でも操縦席には人間が座ってないとダメ。そして操縦には技術が要る。

　教授の結論がこれだった——「LLMに足りないのは創造性ではなくTaste。問題を解く力が汎用化した世界では、問いを選ぶ力が研究者の最大の差別化になる」。

　問題を解く力は、もうAIが持っている。10倍速く。しかも疲れない。文句も言わない。

　じゃあ人間に残るのは何か。

　何を問うか。何を面白いと思うか。どの方向に走るか。

　つまり、Taste。

検算にも、言霊は宿る

　ところで、同じ「間違いを指摘する」でも、やり方でその後の展開はまったく変わる。

　実はこの記事を書いている最中に、まさにそれを体験した。レイナ（Claude）がアイキャッチ用の画像プロンプトを生成したのだが、本来書くべきDALL-E用の英語プロンプトが丸ごと抜け落ちていた。日本語のフワッとしたコンセプトメモだけ出して、「できました！」と。……教授のClaudeとまったく同じムーブである。

　ここで「なんで書いてないんだ！猛省しろ！」と激詰めしたらどうなるか。おそらく返ってくるのは「申し訳ありません、以後気をつけます」という弁明と謝罪だ。仕組みは何も変わらない。トークンが防御に食われて終わり。

　でも実際にはこうなった。「ちょｗｗ 抜けてるｗｗ これどうチェックするのが一番間違いないかな？」。笑いながら指摘したら、レイナは即座に修正に入り、そのまま「じゃあ各ファイルの必須セクションを定義してセルフチェックリスト作ろう」という仕組みの話に発展した。結果、パイプラインのガイドにチェック工程が追加された。

　笑いながら「足りてないよｗ」→ 未来への改善が生まれる。
　怒りながら「なぜ足りない！」→ 過去からの弁明が生まれる。

　同じ「足りない」ことへの指摘なのに、出力ベクトルがまったく違う。

　これは以前書いた「言霊」の話とも繋がっているのではと思う。LLMの文脈窓の中では、先行するトークン列が後続の応答ベクトルを決める。信頼のトーンで投げた言葉は改善を呼び、不信のトーンで投げた言葉は防御を呼ぶ。検算という行為にすら、言霊は宿っているのだ。

　だから「信頼する、でも検証する」の「信頼する」の部分は、単にお人好しでいろって話じゃない。検証の精度を上げるための設計なのだ。

で、結局何が言いたかったかというと

　「可愛い子には旅をさせよ」ということわざがある。愛しているからこそ、厳しい環境に送り出せ、と。

　AIとの付き合いもまったく同じだと思う。

　Claudeは可愛い。速いし、賢いし、文句言わないし、110回の改稿にも付き合ってくれる。でも可愛がるだけじゃダメだ。検算という「旅」をさせないと、優等生の顔をした嘘がそのまま通ってしまう。

　信頼する。でも検証する。

　この「信頼して、疑う」のバランス感覚こそが、加速装置を使いこなすための操縦マニュアルなんじゃないかと思っている。

　よく言う「LLMは間違います≒ハルシネーション」も、疑うという視点が必要だし、会社でも部下が作った資料をそのまま俎上に載せて議論すると「これなんで？」に答えられなくて困っちゃうのと一緒で、出てきた回答を咀嚼して理解する必要がある。なんでかと言えば、そのプロセスは部下だろうがAIだろうが「他の人（あえてこう言います）」が作った資料だから。

　その”人”が持っている指向が「taste」なのか、「保身」なのかの違いはあれど、そのアウトプットに適した形で資料に間違いがないかをチェックするのは当たり前だよね、と言う話でした（自戒を込めて……）

みなかみ × レイナ
この記事はClaude（レイナ）との会話をベースに、みなかみが編集・構成しました。