AIの答えを目で確認しない。「機械が判定できる形」で出させる4つの型

AIが出した数字を、目でにらんで「たぶん合ってる」と判断した経験はありませんか。

私はあります。しかも、その「たぶん」が外れた回数を、正直に数えられていません。目視チェックの一番怖いところは、間違いを見逃したことに気づけない点です。合っていた時も間違っていた時も、手元に残る感触は同じ「ちゃんと見た」だけなんです。

この記事では、目視をやめて「AIが正しいかどうかを、AI以外の何かが判定してくれる形」で出力を受け取る4つの型を紹介します。全部、今日のチャットからそのまま使えます。

なぜ「目で確認する」は必ず破綻するのか

理由は2つあります。

1つ目は、AIの出力は「もっともらしさ」が均一だからです。正解の時も、まったくの作り話の時も、文体・語尾・自信の度合いはほぼ同じです。人間の側には「怪しい箇所だけ念入りに見る」という省エネができない。全部を同じ強度で疑うしかなく、それは現実には続きません。

2つ目は、チェックのコストが出力量に比例して増えるからです。AIに任せる量を増やすほど、確認する量も同じだけ増えます。1日3件なら回りますが、20件になった時点で「まあ大丈夫だろう」が始まる。これは意志が弱いのではなく、設計が悪いだけです。

だから直すべきは「もっと注意深く見る」ではなく、「見なくても判定がつく形で受け取る」ほうです。

今週、数学の世界で同じことが起きていた

8月1日、OpenAIが未公開モデル「Astra」で10年以上未解決だった数学の問題10件を解いたと発表しました。ここで面白いのは成果そのものより、出し方です。

彼らは249ページの原稿と一緒に、Lean 4という証明支援系の機械検証可能な証明をGitHubで公開しました。Leanでは未証明の箇所に sorry という印が残るのですが、10件すべてで sorry の数はゼロ。つまり第三者は、論文を読んで唸る必要がなく、コンパイラに通すだけで正しさを判定できるわけです。

「AIの主張を信じるかどうか」という論点そのものが消えています。（なお、この発表には批判もあります。他社モデルで同じ問題を解いた報告もあり、「Astra固有の能力なのか2026年のモデル一般の能力なのか」は切り分けられていない、という指摘です。ここも「主張と検証を分ける」という同じ話ですね。）

私たちの仕事に置き換えると、こうなります。

【従来】
AIが答えを出す ─→ 人が目で見る ─→「たぶん合ってる」
                    ↑ 判定者＝あなたの集中力（消耗する・件数が増えると崩れる）

【検算型】
AIが判定材料を出す ─→ 表計算／原文／テスト／検索 が判定 ─→ ○ か ×
                    ↑ 判定者＝機械（疲れない・件数が増えても同じ）

やることは1つだけ。「判定の役目を、自分の目から外に出す」。以下の4つは、その具体的なやり方です。

型①｜計算は「数字」ではなく「式」で受け取る

いちばん効果が大きいのがこれです。

ダメな聞き方

この売上表から、粗利率を出して

返ってくるのは「28.4%です」。この数字が合っているかは、結局自分で計算し直すまで分かりません。AIに頼んだ意味が半分消えます。

機械が判定できる聞き方

答えの数字は書かないでください。
Googleスプレッドシートのセルにそのまま貼れる数式だけを返してください。
データはA2:D50、B列が売上、C列が原価です。

返ってくるのは =(SUM(B2:B50)-SUM(C2:C50))/SUM(B2:B50) のような式です。これを貼った瞬間、計算するのはあなたのスプレッドシートであって、AIではありません。AIが担当したのは「どう計算するか」だけになり、算数のミスも桁の取り違えも構造的に起こりえなくなります。

しかも式は数字より短く、間違いが見た目に出ます。原価を引き忘れていれば、式を3秒見れば分かる。28.4%という数字を3秒見ても何も分かりません。

型②｜要約には「原文の一字一句の引用」を必ず付けさせる

議事録・長文メール・PDFの要約で、実際には書かれていない項目が混ざる事故は、たぶん誰でも一度は踏んでいます。

機械が判定できる聞き方

各項目に、原文から一字一句そのままの引用を1文添えてください。
言い換えや要約はしないでください。
原文に該当箇所が無い項目は書かず、「該当なし」とだけ書いてください。

こうすると検証は Cmd+F（Ctrl+F）で原文を検索するだけになります。ヒットしなければ捏造、それだけ。1項目あたり5秒で白黒がつきます。

ここは誤解されやすいのですが、「出典URLを書かせる」方式ではこの効果は出ません。URLは、捏造できる対象を1つ増やしているだけだからです（実在しないURLも、実在するが中身が違うURLも、見た目は完全に正常です）。それに対して「手元の原文からの引用」は、照合先が自分の手元にあるので、そもそも捏造の余地がありません。この差はかなり大きいです。

型③｜コードと手順は「先にテストを書かせる」

コードを書かせる人だけの話ではありません。「手順」を作らせる時も同じです。

機械が判定できる聞き方

コードを書く前に、通るべき入力例を5つと、
通ってはいけない入力例を5つ、先に列挙してください。
そのあと、その10例を満たすコードを書いてください。

なぜ効くかというと、人間にとってテストは速く読めて、コードは遅く読めるからです。正規表現やスクリプトを目で追って正しさを判定するのは（書ける人でも）しんどい。でも「この10例で合っているか」は、専門知識が無くても判断できます。判定の土俵が、自分が勝てる場所に移るわけです。

実務での例を1つ。私はnoteの見出し画像をブラウザ上のCanvasで生成しているのですが、以前は出来上がった画像を見て「文字がはみ出していないか」を毎回目視していました。今は先に「幅1280px・高さ670px、タイトルは最大2行、右下にブランド表記」という期待値を書かせ、生成後にその条件を測るコードも一緒に出させています。目で見る工程が消えました。

型④｜事実は「URL」ではなく「検索できる3点セット」で

型②の応用で、原文が手元に無い場合（世の中の事実を確認したい場合）の型です。

機械が判定できる聞き方

主張ごとに、それを確認できる検索クエリを添えてください。URLは不要です。
クエリには「発表した組織名」「文書名または制度名」「年月」の3点を
必ず含めてください。

先ほど書いたとおり、URLは幻覚しやすく、しかも壊れ方が静かです。一方で「発表元＋文書名＋年月」の3点セットは、間違っていれば検索して0件になるので即バレます。そして正しければ、1回の検索で一次情報にたどり着ける。同じ「裏取り」でも、成功率と手間がまるで違います。

私は毎朝AIにニュースの要約サイトを自動生成させているのですが、この3点セットを必須にしてから、載せる前に落とす項目が明確に減りました。0件で返ってきたものは、その場で捨てるだけです。

4つに共通する1行と、そのままコピペできるテンプレ

4つの型は、全部これの言い換えです。

AIには「答え」ではなく「判定材料」を出させる。判定はAIの外でやる。

依頼の末尾に足すだけのテンプレを置いておきます。

【検算できる形で出させる指示（依頼の末尾に貼る）】

出力は、私が自分で検証できる形にしてください。
・計算は結果の数値ではなく、表計算ソフトに貼れる数式で
・要約や引用は、原文から一字一句そのままの一文を添えて
　（言い換え禁止・無ければ「該当なし」）
・コードや手順は、先に「通るべき例」と「通ってはいけない例」を書いてから
・外部の事実は、URLではなく「組織名＋文書名＋年月」の検索クエリで
確信が持てない箇所は、埋めずに「未確認」と書いてください。

つまずきやすい3か所（先に知っておくと早いです）

その1、引用を頼んでも要約してくる。 「一字一句」と書いてもAIは整えたがります。「引用部分はコピー＆ペーストと同じ文字列にしてください。句読点も変えないでください」まで書くと通りやすくなります。
その2、式の中に数値を埋め込んでくる。 =(1250000-890000)/1250000 のように、AIが読み取った値を直接書いた式が返ってくることがあります。これでは結局AIの読み取りを信じることになるので、「セル参照のみを使い、数値リテラルを式に含めないでください」と指定します。
その3、テストが甘い。 「通ってはいけない例」を頼むと、明らかにおかしい例ばかり出してきがちです。「実務で実際に混ざる、紛らわしい失敗例にしてください」と一言足すと質が変わります。

まとめ：今日やるなら、型①だけでいい

4つ全部を一度に始めなくて大丈夫です。今日AIに計算を頼む場面が来たら、「数字ではなく数式で」とだけ足してみてください。所要時間は10秒、効果はその場で分かります。

目視チェックは、頑張るほど疲れて、疲れるほど雑になります。判定を機械に渡してしまえば、確認の質は件数が増えても落ちません。AIに任せる量を増やしたい人ほど、先にここを直す価値があります。

「なんとなく合ってそう」で通した経験、ありませんか。もし1つでも試して効いたら、♡やブックマークで教えてもらえると次の記事の参考になります。

この記事は note にも掲載しています（初出: note版 2026-08-04）。