AIの結果に自分で証明させる：証拠を求める5つの方法

AIでコードを書く人、情報を調べる人、AIエージェントに作業を任せる人なら誰でも、初心者の方でも読めます。前提知識は要りません。用語にはどれも身近なたとえを添えています。計算の部分は印をつけてあるので、不要なら読み飛ばせます。

数字は公開情報から取っており、末尾に一覧があります。「例」と書いたものは作った例で、実在の人物や会社には触れていません。AIが内部でどう動いているかは、まだ誰にも完全には分かっていません。以下のたとえは覚えやすくするための補助です。また、記事の5つの方法は、挙げた文書や研究から整理した実務上のまとめであり、一つずつ対照実験で確かめられた技法ではありません。

---

まず要点#

• AIを使う人の多くは、結果を確かめ直すことに慣れています。Stack Overflowの2026年調査では、回答者の48%が、結果を確かめやすいときにだけAIを信頼すると答え、重要な判断でAIを信頼するのは6.6%でした。
• 「よく読んで、自分で考え直す」確かめ方は、最も手間がかかります。AIが開ける証拠を添えて出せば、確認は「議論全体の組み立て直し」から「具体的な一点を見ること」に変わります。
• 証拠を求める5つの方法：開ける出典、実行できるテストと出力そのまま、小さく分けた変更、実行済み・読んだだけ・仮定の仕分け、他の人が再実行できる手順。
• どの方法にも穴があります。出典は作り話かもしれず、テストはAI自身が通るように書いたものかもしれず、出力は途中で切れているかもしれません。記事では種類ごとの見つけ方を挙げます。
• 記事の計算例では、主張が8つある要約を確かめるのに、証拠がなければ約48分、あれば約18分かかります。これは例として作った数字で、自分のチームの数字で計算し直せます。
• 証拠は保証ではありません。確認を安くしてくれますが、それを見て判断できる人は必要です。

---

むずかしい言葉をやさしく#

---

1. まずイメージ：車の整備票#

車を整備工場に持っていったとします。作業員が「できましたよ、よく走りますよ」と言います。確かめる方法は、運転してみて祈ることくらいです。次に、作業員が整備票を渡してくれたとします。前のブレーキパッドを交換し、店の裏の坂道で時速30kmからブレーキを試し、制動距離は普通でした。ブレーキオイルの系統はまだ見ていません。同じ作業員でも、何をして、何を試し、何にまだ触れていないかが分かります。

AIも同じです。「完了しました、テストはすべてパスしています」という一文は、確かめる手がかりをほとんど与えてくれません。信じるための材料にしかなりません。Claude Codeの使い方の文書は、まさにこの点を説明しています。エージェントは作業が終わったように見えたところで止まり、試すものがなければ「終わったように見える」ことしか頼りがありません。すると人間がテストの代わりになります。文書は、実行したコマンドとその出力のような具体的な証拠を一緒に求めることも勧めています。

ここから言えること：「完了」と言うのにコストはかかりません。確認を安くするのは証拠です。やることは、信じるか信じないかを決めることではなく、結果が確かめ方を一緒に運んでくる形に依頼を設計することです。

---

2. なぜ必要か：使う側が確かめている#

2.1 Stack Overflow 2026年調査の2つの数字#

Stack Overflow Developer Survey 2026の結果ページ（ある報道によると3万を超える回答）によれば、回答者の約48%が、結果を確かめやすいときにAIを信頼すると答え、6.6%が重要な判断を含む多くの作業でAIを信頼すると答えました。また、見慣れない課題に出会ったときにAIエージェントに聞く人は69.9%でした。つまり、よく使うが、信頼には条件がつくということです。

注意が2つあります。1つめは、私が要約で読んだだけで、表を一つずつ照合してはいないことです。ページ上の「87%超が何らかの信頼を持ち、前年の31%から上昇」という数字は、6.6%と食い違って聞こえるため、使っていません。2つめは、出典の明示についてです。AIの回答を評価するときに出典の明示を重視する割合は、私が読んだ資料では78.7%（ある報道）と93%（調査ページの要約）と、ずれています。数え方や質問が違う可能性があるので、「大多数、約80%から93%」と受け取ってください。

**ここから言えること：**使う人自身が「結果を確かめやすくしてほしい」と言っています。足りないのは、確かめやすくする具体的な方法です。

2.2 実際にあった事件：存在しない判例（Mata v. Avianca、2023年）#

ニューヨークの連邦裁判所での訴訟で、原告側の弁護士がChatGPTで書面を作りました。書面は、航空会社名、引用文、番号がそろった判例を引いていましたが、そのうち6件は存在しませんでした。2023年6月22日、裁判所は2人の弁護士と法律事務所に合計5,000米ドルの制裁金を科しました。詳しくは記事なぜAIを鵜呑みにしてはいけないのかにあります。

注目したいのは、書面には「出典」があったのに、誰もその出典を開かなかったことです。証拠は、誰かが開いて初めて役に立ちます。

**ここから言えること：**出典を求めるのが1歩目、出典を開くのが2歩目です。2歩目がなければ、1歩目は飾りにすぎません。

2.3 AIが自信ありげに答えがちな理由：知っておきたい一つの議論#

Kalai、Nachum、Vempala、Zhangのグループ（OpenAIとジョージア工科大学、2025年9月4日）は、モデルの訓練や採点の方法が、「自信がありません」と言うことよりも当てずっぽうで答えることに得点を与えがちだと論じています。彼らの例では、ある人の誕生日を聞かれたとき、一つの日付を推測すれば当たる確率は約365分の1ですが、「分かりません」と答えれば必ず0点なので、推測のほうが得になります。OpenAIの付属記事は、SimpleQAというテストでの比較を報告しています。あるモデルは52%の問題で回答を控えて誤りが26%、より古いモデルは1%しか控えず誤りが75%でした。

これは著者自身の論じる説明と、当の企業が出した数字であり、私の調べた範囲では独立した検証は見つかっていません。ただ実務上のヒントにはなります。システムが確信がなくても答える傾向を持つなら、AIが自分から認めるのを待つのではなく、確信がない箇所を明示するよう依頼で求めるほうがよいのです。

ここから言えること：「自信がありません」は自然には出てこないことが多いので、依頼の中で頼んでおきます。

---

3. 証拠を求める5つの方法#

イメージしやすいように、各方法を整備票の一欄だと考えてみてください。どこで読んだか、何を試したか、何を変えたか、何をまだしていないか、自分でやり直す手順です。

方法1. 開ける出典を求める#

**イメージ：**ページ下の脚注つきの本のようなものです。脚注は、そのページまでめくれて初めて価値があります。

依頼に入れる文例：

コードや文書についての主張には、確認できる場所を添えてください。
ファイルのパスと行番号、または公式文書のリンクです。
出典のない主張には、はっきり「出典なし」と書いてください。

結果の読み方：最も重要な主張を一つか二つ選んで出典を開き、出典が本当にその内容を述べているかを見ます。リンクが開くだけでは足りず、内容が合っている必要があります。

穴になりやすい点：作り話の出典（先の判例のように）、実在するが別のことを言っている出典、古い出典。見つけ方は、開いて、日付を見ることです。

方法2. 実行できるテストと、出力そのままを求める#

**イメージ：**ブレーキを試し踏みするようなものです。結果は「止まった」か「止まらなかった」で、誰のコメントも要りません。

文例：

完了と報告する前に、次の確認コマンドを実行し、
コマンドと出力を要約せずそのまま貼ってください：npm test
失敗したテストがあれば直して再実行してください。
実行したテストの数も書いてください。

Claude Codeの文書は、テストとして使えるものを挙げています。テストファイル、ビルドの終了コード、静的解析（リンター）、出力を期待結果と比べるスクリプト、デザイン案の横に置くスクリーンショットなどです。大事なのは、テストが合格か不合格を返し、AIがその結果を読めることです。

穴になりやすい点：AI自身がコードに合わせて書いたテスト（同じ間違いがコードとテストの両方にある）、AIがコードに合わせてテストを書き換える、テストの一部しか実行しない。見つけ方は、テストフォルダの差分を見る、実行したテストの数を全体の数と比べる、そして壊してみることです。自分で1行をわざと間違えて、テストが赤になるかを見ます。よりよいテストの書き方は記事AIが書いたコードのテストにあります。

方法3. 小さな変更に分けてもらう#

**イメージ：**答案を一束で出すのではなく、一問ずつ出すようなものです。採点者は休み時間のうちに採点できます。

文例：

一度に一つのことだけやってください。一回の変更は一文で説明できる内容に限り、
変更は100行程度までにしてください。各部分のあとに、
その部分が何のためか、動作をどこで確認できるかを書いてください。

Googleが公開しているコードレビューの指針は、小さな変更のほうが速く、しかも丁寧にレビューできると述べています。レビューする人は、30分の塊を確保する代わりに、数分を何度も見つけられ、大きな変更では重要な点を見落としやすいからです。目安として、100行程度は妥当で、1,000行は大きすぎることが多いとしています。これは人がレビューするときの経験則で、厳密な数字ではなく、ファイル数によっても変わります。

穴になりやすい点：小さく分けても部分同士が依存していて、読む人が追いにくい。見つけ方は、分け方の順序と理由を書かせることです。一括の改名のように本当に大きな変更が必要なときは、機械的な部分と、判断を含む部分を分けて示すよう頼みます。

方法4. 仕分けを求める：実行済み、読んだだけ、仮定#

**イメージ：**医師のカルテに「診察した」「画像を見た」「症状からの推測」と書き分けるようなものです。この三つを混ぜてはいけません。

文例：

回答の最後に、結果を3つに分けてください：
(a) 実行して結果を見たもの（コマンドつき）
(b) コードを読んだが実行していないもの
(c) 仮定または推測
確信が持てないことは、省かずに(c)に入れてください。

理由は2.3のとおりです。システムには、答えをまとめきる傾向があるかもしれず、「これは実行していません」は自然には出てきません。3つに分ける表は、確信のなさに居場所を与えます。

穴になりやすい点：AIが読んだだけのことを(a)に入れてしまう。見つけ方は、(a)のすべてにコマンドと出力そのままを隣に付けさせることです。コマンドのない(a)は(b)として扱います。

方法5. 他の人が再実行できる手順、または独立した読み手を求める#

**イメージ：**料理のレシピのようなものです。手順どおりにやり直して同じ料理になれば、作った人の自慢話より信頼できます。

文例：

きれいなマシンで、自分で結果をもう一度見られるコマンド
（または数ステップ）を教えてください。必要なバージョンと環境変数も書いてください。

重要な作業なら、以前の議論を見ていない新しいセッションに、元の依頼と変更を照らして読み直してもらいます。Claude Codeの文書は、これを、会話を見ていない新しい子エージェントで走らせるレビューコマンドとして説明しています。コードに至った議論に引きずられないためです。これは筋の通ったやり方であって、保証ではありません。別のAIも同じ種類のミスをするかもしれないからです。

穴になりやすい点：AIのマシンでは動くが自分のマシンでは動かないコマンド（環境変数やバージョンの違い）。見つけ方は、きれいなマシンかCIで実際に一度動かすことです。重要な作業では、機械だけでなく人も読みます。

短い一つのブロックにまとめる#

長く使うなら、次のブロックをAGENTS.mdやツールの指示ファイルに貼り、毎回のセッションで読まれるようにします。

## 作業の完了を報告するとき
- 実行した確認コマンドと出力をそのまま貼る。実行したテスト数も書く。
- コードについての主張には、ファイルと行番号をつける。
- 一つの変更は一つの目的、100行程度まで。
- 結果を分ける：実行済み／読んだだけ／仮定。
- きれいなマシンで再実行できるコマンドを一つ示す。

5行なので、人もAIも読み切れます。短くしたのは意図的です。長い一覧は読み飛ばされるかもしれません。

---

4. 自分で確かめられる計算（例、読み飛ばしても可）#

これは作った数字による例で、実測値ではありません。AIが、8つの主張を含む変更の要約を出したとします（例：「日付の書式のバグを直した」「決済の関数には触れていない」）。承認する前に、各主張を確かめる必要があります。

• 証拠がない場合：各主張を自分で組み立て直す必要があり、1つ6分と仮定します。
• 証拠がある場合：示されたものを開くだけで、1つ1分と仮定します。最もリスクの高い2つは、さらに5分ずつ深く確かめます。

claims, rebuild, glance, deep, risky = 8, 6, 1, 5, 2
without = claims * rebuild              # 48分
with_proof = claims * glance + risky * deep   # 8 + 10 = 18分
print(without, with_proof, without - with_proof)
# 48 18 30

per_month = 2 * 20                      # 1日2件の要約、20日
print(without * per_month / 60, with_proof * per_month / 60)
# 32.0 12.0   (月あたりの時間)

結果の読み方：要約1件あたり48分が18分になり、約38%に減ります。1日2件、稼働20日なら、レビューする1人あたり月約32時間が約12時間になります。

はっきり言っておくと、6分、1分、5分は私が仮定した数字で、測った値ではありません。実際の作業ではかなり違うかもしれませんし、証拠を求めるとAIの実行や記述の時間も増えます。自分のチームで何回かストップウォッチで測り、数字を入れ替えてください。

---

5. 証拠を求めても穴になる場所#

整備票を思い浮かべてください。作業員は、試していなくても「ブレーキ試験済み」と書けてしまいます。

5.1 例：証拠がある午後と、ない午後#

これは作った状況で、実在の人物や製品には触れていません。

証拠を求めなかった場合：

• 14:00. 開発者がエージェントに頼みます。「レポートで12/31が翌年と表示されるバグを直して。」
• 14:20. エージェントが答えます。「直しました。テストはパスしています。」開発者は変更をざっと読み、もっともらしいので本流にマージします。
• 16:30. 顧客から、別の日付書式では年末のレポートがまだ間違っていると連絡が来ます。エージェントは2か所のうち1か所しか直していませんでした。

証拠を求めた場合：

• 14:00. 同じ依頼に、上の5行のブロックを添えます。
• 14:20. エージェントが提出します。npm testを実行し、12件のテストがパス、新しいテストはdd/MM書式の12/31の1件だけ。(b)：2つめの書式の関数は読んだが実行していない。(c)：すべてのレポートがdd/MM書式だと仮定した。
• 14:25. 開発者は(b)と(c)を見て、2つめの書式での12/31のケースを追加します。テストが赤になります。エージェントが残りの箇所を直します。
• 14:40. 新しいテスト2件とともにマージします。

どちらの場合も、すべきことは、(b)と(c)の段階で「完了」を止めることです。AIが正直に「実行していません」と書いた場所が、開発者にどこを見るべきかを教えてくれます。これは例なので、何かを証明するものではありません。根拠は研究にあります。Perryらの研究（スタンフォード、2022年）では、AIアシスタントを使った人のほうが、ほとんどの課題で安全性の低いコードを書いたのに、自分のコードは安全だとより強く信じていました。ざっと読んで承認することを心配する理由はあります。あわせて記事AIが書いたコードのレビューもご覧ください。

---

6. 使った数字と文書#

**正しい読み方：**上の資料は、結果を確かめやすくすることを支持しています。ただし、証拠を求めることでミスがどれだけ減るかを直接測った対照実験は、見つかっていません。上の5つの方法は実務上のまとめです。

---

7. リスクに応じた証拠のレベル#

どんな作業にも5つ全部を求める必要はありません。買い物にたとえると、野菜は目で見ればよく、腕時計には保証書が要ります。

---

8. 明日から使える習慣#

8.1 結果を受け取る前の8つの質問#

1. この結果は、出典、テスト、言葉だけのうち、どんな確かめ方を一緒に運んできているか。
2. 重要な出典を少なくとも一つ開いたか。その出典は本当にその内容を述べているか。
3. 確認コマンドと出力はそのままか、それとも要約だけか。
4. 全体のテスト数のうち、いくつ実行されたか。
5. 新しいテストは誰が書いたか。自分が1行を壊したとき、赤になるか。
6. この変更は、全部読めるほど小さいか。
7. AIが「読んだだけ」「仮定」と書いた部分を、自分はどう扱うか。
8. きれいなマシンで再実行できたか、それともAIの言葉を信じただけか。

8.2 今すぐできる3つのこと#

1. 今使っているツールの指示ファイルに、5行のブロックを貼る。
2. 今日の小さな作業を一つ選び、証拠を求める前と後で、確認にかかった時間を測る。
3. 同僚に「実行済み、読んだだけ、仮定」の仕分けを一件読んでもらい、使えるかどうかを聞く。

---

9. バランスよく見る：証拠にできること、まだできないこと#

**できること：**確認を安く速くする。実行していない箇所をAIにはっきり言わせる。他の人が確かめ直せる記録を残す。依頼と変更のずれを見つけやすくする。

まだできないこと：

• 証拠は正しさの保証ではありません。テストは間違っているかもしれず、出典は作り話かもしれず、整った表が過剰な安心感を生むこともあります。Perryらの研究は、AIアシスタントがあると人は油断しやすいことを示唆しています。
• 証拠を求めると、AIの実行と記述の時間が増えます。リスクの低い作業には過剰です。
• それぞれの方法の効果を単独で測った対照実験は、見つかっていません。自分のチームで測ってみてください。
• 別のAIが読み直しても、同じ種類のミスをするかもしれません。重要な作業では人の読み手が必要です。

**大げさに言わない：**これはAIが間違えなくなる方法ではありません。**軽く見ない：**確かめるものがないまま「完了」を受け取るコストは、たいてい最後に、ミスが顧客の手元に届いたときに現れます。

---

10. おわりに#

AIの「完了しました」は、答えのように聞こえますが、実は約束です。証拠は、その約束を確かめられるものに変えます。開ける出典、実行できるテスト、小さな変更、実行済み・読んだだけ・仮定の3分類、再実行できる1本のコマンド。これらの依頼はAIに渡す文の中に入れ、証拠を開くのは、いつも人です。

---

参考資料#

数字は2026年10月時点の公開情報から取っています。報道によって数字が異なる場合があるので、引用する前に元の資料を開いて確認してください。

• Stack Overflow、2026 Developer Survey（要約で読んだもので、表ごとの照合はしていません）
• Anthropic、Best practices for Claude Code（Give Claude a check to run の項）
• Kalai、Nachum、Vempala、Zhang、Why Language Models Hallucinate（2025年9月）とOpenAIの記事
• Google Engineering Practices、Small CLs
• Mata v. Avianca, Inc.：WikipediaとLawNextの制裁金に関する記事
• Pearceら、Asleep at the Keyboard?（2021年）とPerryら、Do Users Write More Insecure Code with AI Assistants?（スタンフォード、2022年）