数字の勝ち負けを争っていた場所に、第三の測り方が持ち込まれた
先日、少し変わったレポートが公開されました。量子コンピュータを使った化学計算の代表的な成果について、その計算結果が「そもそも狙った状態を計算できていたのか」を検証したものです。
背景を短く説明します。IBMが2025年に発表した鉄硫黄クラスタ（生体内の酵素などに含まれる金属化合物）の計算は、量子コンピュータが化学の実務で役に立つことを示す旗艦的な成果とされてきました。これに対して「量子コンピュータで出したサンプルは、同じコストをかけた従来型コンピュータの手法に勝っていない」という批判論文が出て、双方の議論が続いていました。
ここまでの論争は、ずっとエネルギーの数値の大小をめぐるものでした。どちらが低いエネルギーを出したか、同じ条件で比べたらどうか。ところが今回のレポートの著者は、まったく別のことをしました。エネルギーではなく、その計算がどの電子状態に収束しているのかを測ったのです。スピン（電子の自転のような性質で、化学的な振る舞いを左右する）を表すS²という指標を計算すると、論文が狙っていると宣言している状態なら0になるはずでした。実際に出てきた値は4.7から7.0でした。
両者が数字の大小を争っている横で、誰も「その数字が何の数字か」を測っていなかった。 この構図は、量子化学とは何の関係もない場所で毎日起きていることでもあります。営業会議で先月比の増減を議論しているとき、その数字が実は解約分を含んでいなかった、というような話と構造は同じです。
監査の中身を、専門知識なしで読める形にする
レポートの具体的な指摘は、いくつかの層に分かれています。
ひとつ目は、対策機能が実質的に効いていないという指摘です。IBMのツールにはこのスピンの問題に対する緩和機能が用意されていて、それを説明書どおりに使うと、計算対象の空間は48,600個から194,481個へと4.00倍に広がります。ところが肝心のエネルギーはナノハートリー未満（実質的にゼロと言っていい幅）しか動きませんでした。狙った状態を表現できる余地は作るけれど、実際にその状態を出してはこない。しかも、そのソルバーには狙う状態を直接指定できる引数が用意されているのに、標準の処理経路ではそれが設定されないままだった、という話です。
ふたつ目は、自作の再実装ではなく本家のデータで検証した部分です。IBMは論文のデータ公開アーカイブに、実機の測定記録をそのまま置いていました。2023年12月の[2Fe-2S]で2,457,600回の測定、2024年4月の[4Fe-4S]で3,163,742件の結果です。この本家データを本家のパイプラインに流したところ、片方は自分たちの参照値から248ミリハートリー（エネルギーの単位。化学の精度議論では1〜2ミリハートリーが目安）ずれ、もう片方は非常にきれいな三重項状態に収束しました。きれいではあるけれど、狙っていた状態ではない。参照値との差は1,438ミリハートリーでした。
みっつ目は、著者の分析すら不要な部分です。公開アーカイブの中で、比較用に置かれていた「完全にランダムなサンプル」が、公表されている比較のすべてで実機のサンプルと同等かそれ以上の成績を出していました。加えて、最大規模の実行結果は、同じアーカイブに入っている従来型手法の結果に149ミリハートリー負けていました。
外部の批判者が新しい実験をしたのではなく、公開されていた本家の材料を本家の手順で動かし直しただけで、これだけの論点が出てきた。 ここが、この件を「難しい物理の話」として片づけずに読む価値のあるところです。
AIがやったのは、速さではなく自分の誤りの検出だった
著者はこの監査について、Claudeが監督のもとで最初の一巡を約72時間で終えた、と書いています。その後、敵対的なレビューを何度も重ねています。
私が本当に注目したのはそこではありません。著者自身も「速さは面白い部分ではない」と明記しています。面白いのは次の点です。Claudeは、あらかじめ登録しておいた検証ゲートを通すことで、自分の作業の中から5件の欠陥を検出しました。そのうちの1件は、IBMが論文に載せているエネルギー表と突き合わせることで発見されています。そして最後には、自分が出した中でもっとも量子コンピュータ側に有利だった結論を、新しい測り方の結果を受けて自ら撤回しました。
AIに調査や分析をさせたときの一番の失敗は、間違った答えが出ることではありません。もっともらしい答えが、検証されないまま資料に載ってしまうことです。今回の事例が示しているのは、その失敗を防ぐのは「賢いモデルを使うこと」ではなく「作業を始める前に、何が正しさの判定基準かを書いておくこと」だという点です。
レポートには、AUDIT_TRAIL.md（作業の時系列記録）とREPRO_MAP.md（主張ごとに、それを再現するファイルとコマンドを対応づけた地図）という2つのファイルが添えられています。どの結論も、誰かが同じコマンドを打てば再現できる形になっている。主張と、その主張を作り直せる手順が1対1で結びついている状態こそが、AIの出力を業務で使える最低条件です。
非エンジニアにとっての意味は、答えを買うのをやめること
ここからが本題です。中小企業の経営者や個人事業主、バックオフィス担当の方にとって、この事例はどう効くのか。
多くの人はAIを「答えを出してくれるもの」として使っています。資料を作らせる、要約させる、メールの文面を書かせる。これは間違いではありませんが、その使い方だと品質の上限がAIの一発目の出来で決まってしまいます。しかも、出てきたものが正しいかどうかを判断できるのは、その分野に詳しい人だけです。詳しくないから頼んでいるのに、詳しくないと検品できない、という逆説があります。
今回の事例が示した抜け道は、詳しくなくても検品できる形を先に作ることです。エネルギーの正しさを判断するには専門知識が要りますが、「この計算はS²が0になるはずだ、なっていなければ失格」という条件は、条件さえ決めてしまえば機械的に判定できます。
これは仕事でもまったく同じです。請求書のチェックが正しいかどうかを判断するのは大変ですが、「合計が総勘定元帳と1円でも違ったら失格」なら誰でも判定できます。広告レポートの分析が妥当かどうかは判断が難しいですが、「各媒体の消化金額の合計が請求額と一致しなければ失格」なら一致するかしないかしかありません。
AIに頼むべきは答えそのものではなく、答えと、その答えが失格になる条件を同時に出させることです。 条件を先に決めておくと、AIは自分の出力をその条件で落とすようになります。今回の監査で5件の欠陥が見つかったのは、まさにこの仕組みが働いたからです。
業種別に見た、明日から効く使い方
40人規模の食品メーカーの経理担当の場合
月次の原価計算で、原材料の仕入データと生産実績、在庫数量を突き合わせる作業があるとします。従来はAIに「このデータから原価を計算して」と頼み、出てきた表を目視で確認していました。これを変えます。依頼の冒頭に判定条件を書きます。期首在庫と仕入から期末在庫を引いた消費量が、生産実績から逆算した必要量と5%以上ずれたら失格。品目別の単価が前月比で30%以上動いたら該当行を必ず列挙すること。合計が試算表の製造原価と一致しなければ、原因の候補を挙げるまで計算結果を出さないこと。この3行を先に書いておくだけで、AIは計算結果と一緒に「この品目がずれています」という報告を返すようになります。目視で全行を追う作業が、指摘された数行を追う作業に変わります。
10人規模の広告運用会社のレポート担当の場合
クライアントごとに5媒体分のレポートを毎月作っている状況を想像してください。数字を貼り付けて所感を書く、という作業をAIに任せると、それらしい所感は出てきますが、貼り付け元の数字が古いままでも文章は成立してしまいます。ここで効くのが再現手順の要求です。所感の各文について、根拠になった数値とその出典セルを一覧で出させます。「CPAが改善しました」という一文に対して、どのシートのどの範囲を見たのかが並ぶ形にする。すると、参照先が先月のシートのままだった、といった事故が提出前に見つかります。クライアントに出す前の10分の確認が、レポート全体の信頼度を決めます。
社労士事務所や税理士事務所の担当者の場合
法改正が絡む業務では、AIの回答が古い制度に基づいていないかが常に不安です。ここでは反証条件を先に置く方法が効きます。回答を求めるときに、「根拠となる条文または通達の番号と、その施行日を必ず併記すること。施行日が本日より後、または3年以上前の改正に触れていない場合は、回答せずに確認が必要と返すこと」と条件を書きます。答えを信じるかどうかの判断を、条文番号と日付が揃っているかどうかという機械的な判定に置き換えるわけです。顧問先に案内する文面を作る前段として、この一手間が事故を防ぎます。
建材商社の営業事務の場合
見積書の作成では、単価表の版が古い、値引き率が承認範囲を超えている、納期が仕入先のリードタイムと矛盾している、といったミスが起きます。AIに見積の下書きを作らせるとき、「単価表のファイル名と更新日を出力の先頭に書くこと」「値引き率が15%を超える行には理由の記載を必須にすること」「納期が発注日から10営業日未満の行は警告を出すこと」を条件として渡します。営業担当が確認するのは、警告が出た行だけになります。
実践手順は5ステップに収まる
順番に説明します。
ステップ1は、作業を頼む前に合格条件と失格条件を書くことです。ここで重要なのは、失格条件のほうを具体的に書くことです。「正確に」ではなく「合計が試算表と1円でも違ったら失格」と書きます。
ステップ2は、答えと同時に根拠の出所を出させることです。どのファイルのどの箇所を見てその結論に至ったかを一覧にさせます。これがあると、間違いが起きた場所を後から特定できます。
ステップ3は、別の方法で検算させることです。同じ計算を同じ手順でもう一度させても意味がありません。合計から逆算する、件数で割って平均を出す、前月比で異常値を探す、といった別ルートの確認を要求します。今回の監査で決定的だったのも、エネルギーではなくスピンという別の指標で測ったことでした。
ステップ4は、自分の結論を壊しにいかせることです。「この結論が間違っているとしたら、どんなデータが出てくるはずか。それを実際に確認して報告して」と頼みます。今回の著者が「これを潰したいなら、こうやれ」と反証の方法を3つ具体的に示したのと同じ発想です。
ステップ5は、判定の記録を残すことです。何を条件にして、どこで落ちて、どう直したかを1ファイルに残します。これは監査対応のためではなく、来月の自分のためです。
そのまま使える形にすると、こうなります。
（コピーして使えるプロンプト:） 以下の作業をお願いします。ただし、作業を始める前に次の3つを守ってください。
- 失格条件: [ここに具体的な数値条件を3つ書く]。1つでも該当したら、結果を出す前に該当箇所を報告する。
- 出力には、結論・根拠の出所（ファイル名と該当箇所）・失格条件の判定結果を必ず含める。
- 結論を出したあと、その結論が間違っているとしたらどんな矛盾が出るかを自分で検証し、見つかった問題を正直に報告する。 作業内容: [ここに依頼を書く]
注意点と、よくある誤解
まず誤解されやすい点を整理します。この事例は「量子コンピュータは使えない」という話ではありませんし、「IBMが不正をした」という話でもありません。著者自身が、自分の指摘が間違っていた場合の反証方法を3つ提示し、結果がどうであれ公開すると宣言しています。レポートの限界も明記されています。比較の条件が固定されている、片方の参照値は近似である、公開データの一部は重複除去されていて元の分布を検証できない、といった具合です。
同じ姿勢が、AIの使い方にもそのまま当てはまります。よくある誤解を3つ挙げます。
ひとつ目は、賢いモデルを使えば検証は不要になるという誤解です。今回の事例で欠陥が見つかったのは、モデルが賢かったからではなく、検証ゲートが先に設置されていたからです。基準がなければ、賢いモデルはより説得力のある間違いを出すだけです。
ふたつ目は、AIに「間違っていないか確認して」と聞けば確認になるという誤解です。これはほとんど機能しません。判定基準がないので、AIは自分の出力を肯定する材料を探しにいきます。確認させるなら、何が起きたら失格なのかを数値で渡す必要があります。
みっつ目は、この方法が手間を増やすという誤解です。増えるのは最初の10分だけです。条件を書いたテキストは、次の月にもそのまま使えます。むしろ、目視で全行を確認する時間と、提出後に間違いが発覚したときの対応時間が減ります。
もうひとつ、実務上の注意も書いておきます。AIに検証させても、最終的な責任は人が持ちます。特に、金額の確定、外部への送信、契約に関わる判断は、AIの合格判定をそのまま通さず、人が承認する形を必ず残してください。AIに任せるのは検品の実行であって、合格の決定ではありません。
まとめ
量子化学の論争という、多くの人にとって縁のない話題から、仕事に直結する教訓が3つ取り出せます。
1つ目。議論が数字の大小に集中しているとき、その数字が何を測っているかを誰も確認していないことがあります。社内の数字でも同じことが起きます。
2つ目。AIを業務に使うときの品質は、モデルの性能ではなく、検証条件を作業前に決めたかどうかで決まります。詳しくない分野でも、失格条件さえ決めれば検品できます。
3つ目。良いAIの使い方の証拠は、都合のいい結論が出ることではなく、自分の結論を撤回できることです。今回の事例でClaudeが5件の欠陥を自ら見つけ、最も有利だった結論を取り下げたのは、そういう仕組みが先に置かれていたからでした。
明日からできることは1つです。次にAIに何かを頼むとき、依頼文の前に3行だけ、失格条件を書き足してみてください。それだけで、出てくるものの質が変わります。
自社の業務でどこに失格条件を置けばいいのか、どの作業からAIに検品させるべきか。実際の帳票や業務フローを見ながら整理したい方は、Claude Worksの無料30分相談をご利用ください。業種と作業内容をうかがったうえで、その場で使えるプロンプトの形まで一緒に作ります。
