AIのファクトチェックはどこまで信用できるか──AIが入れた赤入れを、一次情報で9項目検証

AIに原稿を書かせ、そのファクトチェックもAIにやらせる。速さを考えれば自然な流れですが、「直された内容そのものが正しいのか」という不安が残ります。

人間によるレビューを挟まず、AI同士でチェックを完結させる体制ほど、この不安は大きくなります。

編集部が実際の案件の成果物を検証したところ、公式発表と突き合わせた9項目は、すべてが一致していました。抜き出した範囲に、事実の誤りは1件もありません。

にもかかわらず、編集部がこの構成案をそのまま通していれば、読者に古い情報を届けるところでした。問題は、書かれている内容ではなく、書かれていない範囲にありました。

何を、どう調べたか──AIの赤入れ9項目を公式発表と突き合わせた

調べ方は以下のとおりです。

使ったAIと実行環境は次のとおりです。構成案・赤入れとも Claude Opus 4.8 で、Claude Code（CLI）から動かしています。情報の取得は、実際のブラウザ（agent-browser）で開いて確認する設定のつもりでしたが、実際に動いていたのは内容を要約して返す取得ツール（Claude Code の WebFetch）でした。赤入れの実行は当時1回だけです。1回では、たまたまその日だけ抜けたのかもしれません。そこで2026年9月2日に、同じ構成案・同等の指示で10回やり直しました。結果は後述します。

赤入れとは、原稿に直接書き込む修正指示のことです。今回の構成案には「この記述は事実と違うので、こう直してください」という指摘が、根拠とともに本文へ埋め込まれていました。

構成案自体もAIが書いたものである以上、古い情報が紛れ込んでいる可能性は最初からありました。赤入れの役目は、まさにそこを見つけて更新することです。

題材になったLINEミニアプリは、LINEの中で動くウェブアプリケーションです。予約やクーポンの受け取りを、LINEの画面から離れずに使えます。ここから、赤入れが実際に何を直したのかを見ていきます。

赤入れの中身は正確だった──9項目すべてが一次情報と一致

例えば、LINEミニアプリを外部のウェブブラウザでも使えるようにする仕様変更について、赤入れは開始日を「2025年10月1日」と書いていました。

この日付は、簡単には出てきません。最初の告知は2025年4月2日のもので、タイトルにも本文にも「2025年10月より」としか書かれていません。日付の欄には「仕様変更日は決まり次第、改めてお知らせします。」とあります。

「1日」が出てくるのは、2025年9月26日に出た続報のほうです。ここで初めて「仕様変更予定日 2025年10月1日」と明記されました。赤入れは、およそ半年あとの続報まで辿っていました。

利用者数の記述も正確でした。LINEヤフーが2026年1月29日に出したプレスリリースは「国内月間利用者数※1が1億ユーザー※2を突破」と書いています。

赤入れは、数値だけでなく、それが「2025年12月末時点」であること、発表日、そして注釈の定義まで写していました。定義とは「1か月の間に一度でも「LINE」を起動したユーザーアカウントの数」という文言です。出典として示されていたURLも実在し、内容も合っていました。

技術的な制約の記述に至っては、外部ブラウザで使えない機能が5つ挙げられ、その5つとも公式ドキュメントと一致していました。メッセージの送信、別ウィンドウを開く操作、ウィンドウを閉じる操作、QRコードの読み取り、そしてアプリ内課金です。

元の構成案が「推測」「確認が必要」と留保していた箇所を、赤入れが確定した事実に書き換えていく。作業として見れば、これは正しい方向の仕事です。

実物はこうなっていました。赤い字が赤入れ、あいだの黒い段落が元の構成案です。構成案の利用者数は「9,400万人（2022年12月末時点）」のままで、赤入れがそれを最新の数値に更新しています。

検索ツールの要約は、原文の項目を落とす

外部ブラウザで使えない5つの機能については、編集部の側にも記録しておきたいことがあります。

編集部が裏を取るとき、最初は検索ツールの要約で確認しようとしました。返ってきたのは4項目です。アプリ内課金の1件が落ちていました。

編集部が公式ドキュメントを実際に開くと、「外部ブラウザで利用できない機能、および動作が保証されていない機能は以下のとおりです。」という一文のあとに、確かに5項目が並んでいます。要約は、原文にある項目を1つ落としたまま、それらしい体裁で返してきました。

赤入れのほうが正しく、検索ツールの要約のほうが間違っていた。この記事で扱っているのと同じ種類の抜けが、検証する側でも起きていたわけです。

問題は正確さではなく、赤入れが見た範囲の狭さだった

赤入れが確認した範囲は2025年12月で止まっていました。2026年に入ってからの変更3件が、丸ごと抜けています。

赤入れには「確認済みアップデート一覧」という項目がありました。日付とともに、近年の変更が並んでいます。この一覧が、2025年12月で終わっていました。

記事のタイトルには「2026年版」と入っています。それでいて、2026年に入ってからの変更が3件、丸ごと抜けていました。

一つめは、入り口となる画面そのものの作り替えです。LINEヤフーは2025年11月17日に「LINE、「ウォレットタブ」を「ミニアプリタブ」へ刷新」と発表し、「2026年2月より順次提供予定」としていました。ミニアプリを紹介する記事にとっては、読者がミニアプリにたどり着く入り口そのものが変わる、という変更にあたります。

二つめは、2026年5月19日に告知された画面仕様の変更です。LINEアプリのバージョン26.7.0から、ミニアプリを表示する画面の上部の作りが変わりました。赤入れが「最新」として書いた2025年12月の仕様は、すでに上書きされています。古い情報を最新として書かせることになります。

三つめは、アプリ内課金の手数料です。2026年7月1日の告知に「2026年7月度ご利用分から、所定の手数料を適用します」とあります。赤入れは費用の記述について「根拠となる一次情報が確認できない」と正しく指摘していました。それでいて、費用の前提そのものが変わった事実には触れていません。

この3件は、探しにくい場所にあったわけではありません。二つめと三つめは、提供元の開発者向けニュースを日付順に見れば、2ページ以内で見つかります。

ただし、置かれている場所は同じではありません。一つめは開発者向けではなく、企業のプレスリリースとして出ています。開発者向けの一覧をどれだけさかのぼっても出てきません。確認する側が探す場所を1か所に決めていると、これだけが漏れます。

正確な指摘と、確認していない空白が、同じ書式で並んでいた

赤入れの文面には「確認済み」「一次情報で確認しました」という表現が繰り返し使われていました。そして、その表現は確認した箇所については本当のことでした。

問題は、確認していない領域にも同じ書式が並んでいることです。9項目の正確な指摘と、2026年分の空白は、文体の上では区別がつきません。

自信のなさが文面ににじむこともなければ、「ここまでしか見ていません」という断り書きが入ることもない。読み手の側から見ると、全体が等しく検証済みに見えます。

編集部も、同じ WebFetch で同じ見落としをしかけた

空を返した取得ツールが、失敗したことを知らせてくれませんでした。

編集部も、検証の最中に同じ失敗をしかけています。

公式の告知ページを、ページの中身を自動で読み込むツール（Claude Code の WebFetch）にかけたところ、返ってきたのはタイトルだけで、本文が空でした。エラーは出ません。取得は成功したという扱いで処理は進みます。

別の形式のURLを試すと、今度は403という応答が返りました。403は、アクセスそのものを拒まれたことを示すエラーコードです。人が画面を見れば「弾かれた」とすぐ分かります。それでも、取得結果が一覧としてまとめられた時点で、成功と失敗の区別は消えます。

最終的に、編集部が実際のブラウザでページを開いて、はじめて本文が読めました。

そして、検証の核心となる2点は、その本文の中にしかありませんでした。変更前の仕様が具体的にどうだったのか。そして、旧機能が同じ日に提供終了になること。自動で読み込むツールだけで裏を取っていれば、編集部も赤入れと同じ結論を書いていたはずです。

ここで、赤入れの側の条件も書いておきます。今回の赤入れも、同じ WebFetch で情報を取得していました。

作業した側は、実際のブラウザでページを開く設定で動かしているつもりでした。実際に動いていたのは、内容を要約して返す WebFetch のほうです。編集部が踏んだのと同じ WebFetch が、赤入れの側でも動いていたことになります。

ただし、それが原因だと決めつけることはできません。

2026年9月2日、同じ構成案に同等の指示で、赤入れを10回やり直しました。2026年の3件のうち拾われたのは、10回のうち1回、1件だけです。残る9回は3件とも出てきませんでした。

しかも10回のうち7回は、3件が載っているニュース一覧のページを実際に開いています。開いたうえで、拾っていません。

取得ツールを入れ替えて比べることも試みましたが、条件を分けられませんでした。WebFetch だけを使わせるつもりで指定した5回でも、実際のブラウザ（agent-browser）のほうが選ばれています。10回とも、WebFetch は一度も動いていません。

理由ははっきりしています。編集部は2026年8月1日に「公式ドキュメントの中身は実際のブラウザで開く。WebFetch は使わない」という決まりを作り、AIへの指示文に書き込んでいました。7月の赤入れで痛い目に遭ったからです。使ってよいツールとして WebFetch を指定しても、指示文に書いてあるほうが優先して使われました。

同じ食い違いが、向きを変えて二度起きたことになります。7月は実際のブラウザで開くつもりが WebFetch が動き、9月はWebFetch を動かすつもりが実際のブラウザが選ばれた。どちらも、こちらが指定したつもりの条件と、実際に動いたものが違っていました。

そのため「取得ツールを替えれば拾えるのか」には、この記事では答えを出せていません。

これは WebFetch の性能の話ではありません。人がやってもAIがやっても、同じように起こります。

外に情報を取りに行かせると、取れなかった部分が埋められる

渡した文書を読む作業は正確でした。間違いが出たのは、文書の外へ情報を取りに行かせたときだけです。

編集部は同じ時期に、別の測定も行っています。

3,891字の社内規程を模した文書をAIに読ませ、表から15行分の数値を書き出させたところ、5回とも15行すべてを正確に転記しました。規程の内容を例外まで含めて要約させても、5回とも漏れがありません。読解の精度は落ちていません。

間違いが出るのは、情報が文書の外にあるときです。渡された文書の中に答えがある作業では、AIは強いです。

ところが、AIに外部の情報を取りに行かせた瞬間に、取れなかった部分が空白のまま、それらしい文章で埋まります。そして、埋めたことが本人にも読み手にも分かりません。

今回の赤入れも、まさに文書の中と外という境界をまたいでいました。渡された構成案の中身を読む作業は正確にこなし、そこにない2026年の更新を取りに行く段で、確認できていない範囲を確認済みと同じ書式で埋めています。

現場で「AIが間違える」と言われる場面の多くは、読み間違いではなく、調べた範囲の外側を埋めた形をしています。事実そのものは合っているのに、いつ時点までの事実なのかが揃っていないのです。

確かめ方は3つ──範囲を書かせる・一覧を開かせる・URLを開く

編集部が実務で採っている確認の仕方を3つお伝えします。どれも大掛かりな仕組みは要りません。2つはAIへの指示文に一行加えるだけ、1つは人がURLを1回開くだけです。

ただし、やらなければ、赤入れの精度がどれだけ高くても効果はありません。

一つめは、日付ではなく範囲を書かせるという違いです。確認した日を書かせても、どこまで見たのかは分かりません。範囲の終端を書かせれば、空白がその場で見えます。

二つめは、当初この記事に「AIに一覧を開かせればよい」と書いていました。測り直したところ、そうはなりませんでした。

先の10回の測定では、7回がニュース一覧を実際に開いていて、それでも拾えたのは1回だけでした。 一覧を開くことと、一覧から自分の知らない項目に気づくことは、別の作業だったということです。

個別の事実を1件ずつ問い合わせる形では、存在を知らない更新は永遠に出てきません。そこは変わりません。ただし、その一覧を見て「2026年のぶんが無い」と気づく作業は、いまのところ人の側に残ります。

三つめについては、今回、出典として示されたURLは実在し、内容も正しいものでした。それでも開く価値はあります。

開けないURL、中身の違うURLが混じっていた場合、それは一件の誤りではありません。確認の工程そのものが行われていなかったという合図です。

AIによるファクトチェックは、使えないものではありません。今回検証した赤入れは、9項目すべてが一次情報と一致する水準でした。ただし、それは「調べた範囲では」という条件つきの正確さです。範囲の外側は、確認済みの記述と見分けのつかない形で出力に混ざります。

だからこそ、チェックは一度で完結させないという前提が要ります。今回の抜けも、赤入れを読んだだけでは分かりませんでした。編集部が提供元のニュース一覧を日付の並んだ状態で開くという、別の探し方を重ねて初めて見えています。

同じAIに、同じ聞き方で、もう一度確認させても、同じ空白がもう一度できるだけです。重ねる意味があるのは、探し方を変えたときだけでしょう。

そして、今回それを変えたのは人でした。ニュース一覧を開くという判断も、日付の並んだ画面を見て「2026年の更新がある」と気づいたのも、AIではありません。AIに何回確認させても、範囲の外側は視野に入りません。一覧を開いて「2026年のぶんが無い」と気づくところに、人の目が要ります。

編集や校閲をする側が確かめるべきは、書かれている内容が正しいかどうかだけではありません。どこまでを見て、どこから先を見ていないのか。

とりわけ「その記述が無い」「出典が無い」という指摘は、探した範囲が足りなかっただけでも、同じ形で成立します。指摘する側にも、範囲を言わせる必要があります。

編集部のように毎回全件を突き合わせる体制を組めない現場でも、この一言を求める習慣だけは、今日から始められます。