生成AIのファクトチェック方法AIの結果をそのまま使わない5つの基準

AIに、あまり慣れていない仕事を頼んだことはありますか？

報告書を頼めば、報告書が出てきます。企画書を頼めば、タイトルも目次も表もそろった資料が出てきます。最初に見たときは、きっと驚かれると思います。想像以上に、それらしく仕上がっているからです。

ところが、いざその資料をお客様に送ろうとしたり、実際の業務で使おうとしたりすると、手が少し止まります。

「これで、もう大丈夫なのかな？」

文章は自然で、形も整っています。でも、大事なことが抜けていないかが分かりません。数字は合っているのか。根拠は本当にあるのか。その分野に詳しい人が見たら、すぐに気づくようなミスはないか。気になり始めます。

AIの仕事が悪かったのでしょうか。そうではありません。むしろ、うまく作りすぎたくらいです。本当に難しいのは別のところにあります。自分がその仕事をよく知らないので、どこまで来たら「完成」なのかを判断しにくいということです。

ですから、先に答えをお伝えします。

AIが結果を作ったのに、なぜ不安になるのでしょうか？

いつもやっている仕事なら、AIのミスにはすぐ気づけます。

毎日作っている見積書を思い浮かべてみてください。抜けている項目、おかしな計算、お客様に使ってはいけない言い回し。こうしたことは、見ればすぐに分かりますよね。頭の中に「ちゃんとした見積書」の形がすでにあるからです。AIが作ったものを、その経験と比べればよいのです。

初めての仕事は違います。見た目は分かっても、中の空白が見えません。

• 何が必ず入っていなければならないのか？
• どの順番で進めるべきなのか？
• どの数字や書類を、原本で確かめるべきなのか？
• どんな例外がよく起きるのか？
• 最終的な責任は誰が持つのか？

これらに答えにくいなら、資料がきれいに仕上がっているというだけでは、完成とは言いにくいのです。自信をもって書かれた文章と、確認された文章は、同じではありませんから。

よく言われる「AIのハルシネーション（もっともらしい誤り）」も、ここで問題になります。生成AIは、存在しない資料や間違った内容を、事実のように示すことがあります。ですから、重要な主張や数字は、原文で確かめ直す必要があります。

でも、誤りを見つけさえすれば、仕事は終わるのでしょうか。そうではありません。事実がすべて正しくても、お客様が求めている内容が抜けていたり、現場で使えなかったりすれば、良い結果とは言えません。

なぜコーディングでは、AIと一緒に直し続けられるのでしょうか？

このことを理解するのに、分かりやすい例がプログラミング（コーディング）です。

大事なのは、「デバッガー」というツールがあることではありません。コーディングという仕事には、作ったものを確かめて、問題があればまた直す流れが、最初から組み込まれています。

多くの開発環境では、実行時のエラー、ログ、テストの結果、デバッグツールなど、コードの状態を知らせてくれる技術的なサインが表示されます。ただし、すべてのツールにデバッガーがあるわけではなく、仕事や環境によって使える確認手段は変わります。

技術的なサインだけではありません。画面がきちんと表示されるか、ボタンを押したら約束どおりに動くか、値を入れたら期待した結果が出るか。こうした目で見て分かる結果や動きもあります。

そのため、コーディングの結果は、おおむね二つの道で確認できます。

1. 技術的な確認サイン — 実行エラー、ログ、テスト、デバッグツールで問題を見つけます。
2. 目に見える結果と動き — 画面、ボタンの動作、入力と出力が期待どおりかを見ます。

専門家は、さらにコードの構造や設計、読みやすさ、あとから直しやすいかまで判断できます。専門家でなくても、コード全体を理解しないまま、この二つの道で一部の失敗は見つけられます。

1. AIがコードを作ります。
2. 技術的なサインと、実際の動きを確認します。
3. 期待した結果と実際の結果を比べます。
4. うまくいかない部分を探します。
5. 直して、もう一度動かします。

このように「確かめて、直す」流れが比較的はっきりしているため、コーディングは、慣れていない方でもAIとやり取りしながら進めやすい仕事だと言えます。

AnthropicがAIエージェントの評価について書いた記事でも、同じような話があります。コーディングの課題は、やるべきことを比較的はっきり決めやすく、テスト環境も作りやすいそうです。そして、AIが何かを「した」ことと、その結果が「正しい」ことは、分けて見るべきだと説明しています。

だからといって、「コーディングはAIだけに任せても完全に安全だ」という意味ではありません。
私の現場での経験では、結果をもう一度確かめる方法があれば、人とAIがやり取りしながら結果を磨きやすくなる、ということです。

これは、コーディング分野でAIの活用が増えた理由を証明したものでも、コーディングがAI活用の一番多い分野だという意味でもありません。

また、テストに通ったり、画面がきちんと動いたりしたからといって、結果が完全になるわけではありません。セキュリティ、あとから直しやすいか、抜けている要件、使う方の体験、事業としての価値までは、自動的には保証されません。

テストに通れば、本当に良い結果なのでしょうか？

ここで、ひとつだけ押さえておきたいことがあります。

テストは、私たちが確認すると決めた条件だけを確認します。テストに入れていないお客様の要望、想定していなかった例外、セキュリティの問題、あとから直しにくい作り、実際に使う方の不便までは、見つけてくれません。

プログラムが動くことと、良いサービスであることは違います。数字の出典が正しいことと、良い報告書であることも違います。

そこで、AIが作った結果を見るときは、質問を二つに分けてみるとよいと思います。

1. 間違いはないか？ — 事実、数字、引用、計算、出典を確認します。
2. 必要な結果になっているか？ — 目的、要件、抜けている内容、実際に使えるか、責任の範囲を確認します。

生成AIのファクトチェックは、一つ目の質問に近いものです。仕事が本当に終わったかを知るには、二つ目の質問まで確認する必要があります。

報告書や企画書にも「確認の仕組み」は作れますか？

はい、作れます。コードのような実行ボタンがない仕事でも、確認の流れはつくれます。大がかりな仕組みは要りません。次の5つを先に書き出すところから始めれば大丈夫です。

1. 「終わった状態」を先に書いておく

AIに任せる前に、「何ができたら終わりなのか」を一文で書いてみてください。

「市場調査レポートの作成」ではなく、次のように具体的に書くのがおすすめです。

新規事業に参入するかどうかを判断できるように、市場規模の原典、主な競合、確認すべき規制、まだ確認できていない項目を分けたレポートを作る。

こう決めておけば、資料が長いから、表がきれいだからという理由で「終わった」と思い込まずに済みます。判断に必要な材料がそろっているかに目が向きます。

2. 事実と判断を分ける

日付、数値、法令、会社名のように確かめられる事実と、見通しやおすすめのような判断を分けてみてください。

事実には出典が必要です。おすすめには、どんな前提でそう判断したのかが必要です。個人の経験や意見を研究結果のように書かないこと、調査資料の主張を会社の決定事項のように書き換えないことも大切です。

3. 出典と数字は、別のルートで確かめる

AIが示したリンクをそのまま信じず、原文を実際に開いてみてください。その資料が本当にあるか、その文が本当に書かれているか、調査の時期と対象がいまの仕事に合っているかを確かめます。

同じAIに「もう一度確認して」と聞くのも、役には立ちます。ただ、それは独立した確認ではありません。重要な情報は、公式の文書や原資料、自分でやってみた計算など、別のルートで確かめるのが安心です。

4. 抜けている要件と例外を確かめる

正しい文だけを集めても、良い結果になるとは限りません。

最初に頼んだ内容がすべて入っているか、お客様が実際に使える形になっているか、反対の事例や当てはまらない条件が抜けていないかを確認してみてください。できれば、以前うまくできた成果物やチェックリストを横に置いて、見比べてみるとよいでしょう。

5. 判断できない部分は、印をつけておく

分からない部分を、無理に通さなくても大丈夫です。

確認済み、条件付きで使用、未確認、専門家の確認が必要 のように状態を分けておくと、どこまで使ってよいかが見えてきます。判断できなかった部分を隠さずに書いておくことも、成果物の一部です。

どこまで自分で確認し、いつ専門家に聞くべきでしょうか？

すべての仕事を、同じ深さで確認する必要はありません。

アイデアを広げるための下書きなら、軽く目を通すくらいで十分なこともあります。でも、法律、税務、医療、契約、安全、大きな金額が関わる判断のように、間違えたときの影響が大きい仕事は、その分野の専門家に確認してもらうのがおすすめです。

このときの基準は、「AIがどれだけ自信をもって答えたか」ではありません。次の質問を確かめてみてください。

• 間違えたときの損失は大きいか？
• 外部に提出したり、実際の行動に使ったりするか？
• 自分で間違いや抜けを見つけられるか？
• 別に確かめられる原文、計算、テストがあるか？
• 最終的な責任を持つ人が確認したか？

答えにくい質問があれば、範囲を小さくしてみてください。仕事全体を一度に任せるのではなく、確かめられる小さな単位で、まず試してみるのです。

参考になる研究があります。AnthropicがClaude Codeの利用記録を分析したところ、人が主に担っていたのは、何をするか、どの方法を取るか、何をもって完了とするか、といった「計画段階の判断」でした。これとは別に、その仕事をよく知っているユーザーほど、テストに通るなど確かめられる成功のサインが多く見られました。この結果は、AIに仕事を任せる前に、完了条件と確認方法を決めておく必要性を考えるための参考事例と見ることができます。

体感と、実際に測った結果が違うことがある、という研究もあります。METRの2025年の研究では、経験豊富なオープンソース開発者16人が246の課題に取り組んだところ、AIを使ったときのほうが完了までの時間が19%長くなりました。もちろん、特定の参加者と課題に限った結果なので、すべての開発者や仕事にそのまま当てはめることはできません。2026年の追跡研究では、新しいツールで速くなる可能性も見られましたが、AIなしで働くことを避けたい参加者や課題が抜ける「選択の偏り」や募集の問題があり、効果の大きさは信頼しにくいとしています。

ですから、この事例からお伝えしたいのは、人が一人でやるときとAIと一緒にやるときを、同じ完了基準、同じ品質、同じ期間で比べてみる必要がある、ということです。

今日、何から始めればいいでしょうか？

AIに任せたい仕事を一つ選んで、二つの文を書いてみてください。

そして、もう一文だけ書き足してみてください。

AIをうまく使うとは、プロンプトを長く書くことだけではありません。AIが作った結果をどこまで信じ、何を確かめ直し、いつ人に渡すのかを決めることです。

それらしく見える結果と、本当に使える結果のあいだには、「確かめる」という一歩があります。その一歩を仕事の中に組み込んでおけば、AIは資料を代わりに作ってくれる道具から、一緒に仕事を終わらせる道具へと、少し近づいていきます。