AIニュースの転載や要約を一次情報までたどる:長文解説の裏取り17件、数字の出どころ、GGUF版Spaceの中身

開発mdx-playground

AIニュースの転載や要約を一次情報までたどる

9月23日の早朝から9時台にかけて、3つのセッションで同じ種類の作業をした。 誰かがまとめたものを入口にして、その元をたどる作業である。

5時台に扱ったのは、ある長文の解説記事の要約だった。 6時台は画像生成モデルの配布ページ、9時台は SNS で流れてきた数字入りのニュースである。 題材はばらばらでも、3件とも入口の情報をそのまま受け取らず、奥にある資料まで開いた。

05:51 長文の解説記事を要約し、裏取りにかける

最初の題材は、AI インフラの重心が強化学習寄りに移っていくと論じる、ある長文の解説記事だった。 筆者はこれを要約して、非公開の記事として保存するよう Claude Code に頼んだ。

Chrome DevTools MCP で記事を開かせると、本文は326ブロック、画像は77枚あった。 そのうち25枚をダウンロードさせ、すべてが PNG として正しく読めることを検証させた。 要約の本文に入る前に、数値が載っている図を先に確認させた。

表示確認の途中で、最後の1枚(図25)だけが読み込み待ちのように見えた。 再確認させてから、要約の保存を終えた。

要約をそのまま信じないための2本立て

要約ができた時点で、筆者は Codex のレビューとファクトチェックの両方を頼んだ。 Claude Code に、Codex のレビュー(gpt-6-astra、high)と、Web 検索で裏取りするサブエージェントを並行で走らせた。

先に戻ってきたのは Web の裏取りだった。 17件の主張を Web 上の一次資料と照らした結果は、16件が「正しい」、1件が「ほぼ正しい」で、誤りは0件だった。

少し遅れて Codex のレビューも終わった。 その指摘を受けて、要約の本文を7か所直させた。 裏取りの結果は「ファクトチェック」の章として、要約の末尾に足させた。

裏取りで誤りが出なかったことと、要約に直す箇所が残っていたことは、別々の話である。 裏取りだけで済ませていたら、この7か所はそのまま残っていたことになる。

「原文の主張」と「そこから導いた仮説」を分ける

次に筆者が手を入れたのは、冒頭の「結論」だった。 原文が言っていることと、それを読んで立てた仮説が、ひとつの「結論」にまとまっていた。

これを「原文の主張」と「そこから導いた仮説」の2段に組み直させた。 2段に分けておけば、あとで読み返したときに、どこまでが原文で、どこからがこちらの読みなのかを見分けられる。

「8層化は供給不足からの妥協では」

最後に、筆者は記事の論理そのものに疑問を投げた。 原文にある「8層化」は、構造的な方向を示すものではなく、供給不足からの妥協ではないか、という指摘である。

Claude Code の返答は、この指摘を認めるものだった。 原文は「8層化」を構造的な方向として扱っており、Claude Code が立てた仮説にも同じ読み替えがあった。 供給不足からの妥協という見方は、原文の論理からも仮説からも漏れていたという。

そこで、関係する経営者の発言と製品ロードマップを公開情報で裏取りさせてから、仮説を書き直させた。 リントと表示確認まで済ませて、このセッションを閉じた。

振り返ると、裏取りの17件は、どれも事実の正誤を問うものだった。 「8層化」を何の表れと読むかは、正誤ではなく解釈の問題である。 この読み替えは、筆者の指摘で初めて書き直しの対象になった。

06:10 GGUF 版を試せる Space は、本当にその GGUF を読んでいるか

2つ目は、eurekapu-nuxt4 のリポジトリで開いたセッションだった。 ある画像生成モデルの GGUF 版を、手元にダウンロードせずにブラウザで試せないかを Claude Code に調べさせた。

まず Hugging Face のモデルページを見させた。 ページ自体には、試用のウィジェットが無かった。 代わりに「Spaces using this model」の欄に、4件の Space が並んでいた。

4件のうち3件は、同じ名前の複製に見えた。 そこで全部は開かず、1件に絞って確かめさせた。 Space の名前は「Qwen Image 2.1 GGUF Studio」で、Zero GPU で動いていた。

名前に GGUF と入っていても、中で読み込んでいるのがこのモデルだとは限らない。 Claude Code に app.py と README を読ませて、この GGUF を読み込んでいることを確かめた。

結論は、モデルページからは試せないものの、このモデルを読み込んだ Space が公開されていて、ブラウザだけで試せる、というものだった。 Space の名前ではなく、app.py の中身で判断したことになる。

09:24 数字入りのニュースを、社内プレゼン資料までさかのぼる

3つ目は、SNS で流れてきた数字入りのニュースだった。 話題の数字のひとつは、Grok Bot の「40万ユーザー」である。 筆者はこの出どころを Claude Code にたどらせた。

流れてきた投稿は、ニュースを転載するアカウントが見出しをそのまま載せたものだった。 元の報道は、Bloomberg が2026-09-22に出した記事である。 数字そのものは、SpaceXAI がロンドンのイベントで見せた社内プレゼン資料から来ていた。

転載、報道、社内資料と3段さかのぼって、たどり着いたのは会社が自分で出した数字だった。 外部の監査や独立した計測を経た数字ではない、というのが調べた結果である。

報道に載ったことと、数字が検証されたことは、同じではない。 見出しだけを見ていたら、この区別はつかなかった。

たどった先にあったもの

3件を並べると、入口と行き着いた先は次のようになる。

時刻入口行き着いた先
05:51長文の解説記事の要約Web 上の一次資料17件、Codex レビュー、筆者の「8層化」への疑問
06:10モデルページの「Spaces using this model」Space の app.py と README
09:24転載アカウントの見出しBloomberg の記事、SpaceXAI の社内プレゼン資料

最初の件だけは、行き先に筆者自身の疑問が入っている。 事実の照合は、サブエージェントと Codex に任せることができた。 一方で、裏取りを通った記事の中にある解釈のずれは、読んだ筆者が引っかかるまで表に出なかった。

前日にも、自分のうろ覚えを一次資料で確かめる作業をしていた(うろ覚えを一次資料で裏取りして公開記事にした2本)。 前日に確かめたのは自分の記憶で、この日に確かめたのは他人がまとめたものだった。

学び

  • 事実の正誤を照合する裏取りと、原文の解釈を問う読みは別の作業だった。17件の裏取りで誤りが0件でも、「8層化」の読み替えは筆者の指摘まで残っていた
  • 転載の見出しや Space の名前は入口にすぎない。確かめる先は、社内プレゼン資料や app.py のような元の資料だった
#ファクトチェック#一次情報#Claude Code#Codex#Hugging Face#GGUF