aiseed.dev›AIネイティブな仕事の作法
第10章 / Essay
第10章 № 10 · 2026

物語を、
AI で検証する。

AI 自身も物語に流される。だから検証の設計が要る

2026.05.02 🌐 EN

仕事の現場は、物語に取り囲まれている。

第 1 章「活用マニュアル」のコツ 5（AI のハルシネーション・迎合性に気をつけて、最後は自分が確認する）を、この章では「組織や社会レベルの物語をどう検証するか」に押し広げる。

経営者の説明、ベンダーのピッチ、業界の常識、ニュース記事、政治家の言葉、SNS のトレンド、業績発表、人事評価、求人票、契約書の前文 ── 私たちが日々受け取る情報の大部分は、誰かが意図を込めて構成した 物語(narrative) である。

そして物語のほとんどは、語る側に都合よく作られている。多くの場合、それは無意識の自己正当化 ── 人間は自分の行動を正当化し、文脈を整理し、関係性を保つように物語を作る。社会的な動物としての標準動作である。

しかし、それだけではない。市場支配力のある企業や政治的影響力を持つ個人が物語を発するとき、その物語は 意図的に設計されている 場合がある。Satya Nadella の「ネイティブアプリ回帰」のような戦略的スローガンは、報道機関、開発者ブログ、SNS、そして AI の訓練データを通じて拡散することを計算したうえで打ち出されている。Microsoft は OpenAI への巨額投資、GitHub の所有、LinkedIn の所有、npm の所有 ── これらすべてが AI が学習する情報源そのもの である。物語の発信者が AI を含めた情報インフラを所有する時代、「悪意ではない」と無条件に仮定するのは素朴に過ぎる。意図的な物語形成と無意識の自己正当化の境界は、もはや明瞭ではない。

問題は、物語に流されると、判断を間違える ことだ。そして AI 自身も、物語に流される。これが本章の核心である。

ベンダー選定で営業のピッチに乗せられて高い契約をする。経営判断で業界レポートの誇張を信じて投資する。採用で履歴書の物語を額面どおり受け取る。投票で政治家の説明を検証せずに選ぶ。

この章は、AI 時代の重要な仕事 ── 物語を検証する ── について書く。これは、AI に「やらせる」仕事ではなく、AI と一緒に 人間がやる 仕事である。

なぜ AI が物語の検証に向いているか

物語の検証は、もともと専門家(記者、研究者、調査員、弁護士)の仕事だった。一般の人は、時間も能力もなくて、検証せずに信じるしかなかった。

ここに AI が入る。

1. 大量のテキストを横断的に読める

人間が読むのに 1 週間かかる発言録・議事録・SNS 投稿・記事を、Claude は数分で目を通せる。「過去 5 年間の X 氏の Y についての発言を、時系列で並べてください」── これだけでも、人間の調査時間を桁違いに短縮できる。

2. 矛盾を指摘するのが得意

「A 氏は 2020 年にこう言い、2024 年にこう言った。これは整合するか」 ── こういう構造的な比較は AI の得意領域である。表現の揺れに惑わされず、主張の中身を抽出して比較できる。

3. 偏らない視点(訓練データ全体を見る)── ただし、ここに重大な留保がある

人間は、自分が読みたい記事だけを読む傾向がある(認知的フィルターバブル)。AI の訓練データには、相反する立場の記事が両方入っており、うまく問えば両側の主張を出してくれる ── ように見える。

しかし AI も偏る。

4. 疲れない ── ただし、忖度はする

AI は「上司への配慮」も「業界での立場」も持たない。これは事実だ。

しかし AI は別の意味で 忖度する。

AI は「物語を作る」のは得意だ。同時に「物語を検証する」のも得意である ── ただし条件付きで。同じ訓練データから出た AI が同じ訓練データを検証しても、両側に同じ偏りが残る。これは 第9章 AI に任せる仕事を見極める で論じた 「AI が AI を検証しても、ハルシネーションは互いに補強される」 という構造そのものだ。

だから、検証は次のように設計する必要がある:

作る側にも検証する側にも AI がいる時代に、私たちは AI の偏りを理解した上で、複数の AI を使い分ける 必要がある。「AI がそう言ったから」は、判断の根拠にならない。

事例:WordPress と Matt Mullenweg

具体的な事例で見てみよう。

WordPress の共同創設者であり、Automattic の CEO でもある Matt Mullenweg 氏が、2024 年から WP Engine という大手ホスティング会社との対立を公にしている。多くの公的発言、法廷文書、ブログ投稿、カンファレンス講演、ポッドキャスト出演がある。

これは AI で物語を検証する 格好の事例 である。なぜなら、

物語の主要な主張(表層)

Matt 氏が公的に展開してきた物語の主要な主張は、おおむねこう整理できる [要検証:具体的な発言の引用と日付]。

  1. 「WP Engine は WordPress エコシステムにフリーライドしている」 ── 商標を不正使用し、本家への貢献が著しく少ない
  2. 「WP Engine は WordPress の正しい姿を歪めている」 ── デフォルト設定で revision を無効化するなど、ユーザー体験を意図的に貧弱にしている
  3. 「WordPress.org は私の個人的な財産である」 ── ドメインもインフラも私個人で所有しており、誰をブロックするかを決められる
  4. 「WP Engine の差し止めは、コミュニティを守る正当な行為である」

AI で検証する手順

これらの主張を、AI と一緒にどう検証するか。

ステップ 1:主張を抽出して分類する

Claude に、Matt 氏の発言と公開文書を読み込ませて、

以下のテキスト群から、Matt 氏の主要な主張を抽出してください。各主張を「客観的事実の主張」「意見・評価」「比喩・修辞」に分類してください。

これだけで、議論の構造が見えてくる。「フリーライド」は意見、「商標不正使用」は事実主張(検証可能)、「コミュニティを守る」は評価 ── と切り分ける。

ステップ 2:事実主張を検証可能な情報源と照合する

「WP Engine は WordPress 商標を不正使用している」── これは事実主張なので、検証できる。

WordPress 商標の所有者は誰か。WordPress Foundation の商標方針で、「WordPress」名を含むサービス名はどこまで許容されているか。過去 10 年間、Matt 氏や Automattic は WP Engine の商標使用に公的に異議を唱えていたか。

Claude は、WordPress Foundation の trademark policy ページ、過去のコミュニティ議論、WordCamp での発言などを参照して、回答を組み立てることができる。検証可能な情報源があれば、AI は事実関係を整理できる。

ステップ 3:時系列で発言の整合性をチェック

これが AI が特に得意な部分だ。

過去 10 年間の Matt 氏の WP Engine についての言及を時系列に並べてください。WP Engine が CEO の Heather Brunner を起用した 2014 年から、Lee Wittlinger が Silver Lake から WP Engine の取締役会に加わった 2018 年、そして 2024 年の差し止めまで。

このとき、

を整理させる。過去の発言と現在の発言が大きく食い違っている場合、それは新しい情報がある か、物語が後付けで構成されている か、のどちらかだ。

ステップ 4:第三者の検証可能な記録と照合

法廷文書(WP Engine 対 Automattic、2024 年 10 月以降の係争)では、両者の主張が宣誓のもとで提出される。これは Matt 氏の単独の物語と比較できる 第三者検証 である。

Claude に、

WP Engine 訴訟の差止命令申立書(2024 年 10 月)、Automattic の反論、裁判官の暫定命令(2024 年 12 月)を要約してください。 Matt 氏の公的主張と一致する部分、矛盾する部分を整理してください。

裁判の暫定命令で「Automattic の WordPress.org からの WP Engine ブロックは差止対象」と判断された事実は、Matt 氏の「WordPress.org は私の個人財産だから自由に決められる」という主張と整合しない。

ステップ 5:残った疑問点を整理する

すべての矛盾を解消できるわけではない。最後に、

を整理する。「分かったこと」と「分からないこと」を明確に分ける こと自体が、物語に流されないための重要な作業である。

何が見えてくるか

このプロセスを通して、Matt 氏の物語のうち

といったことが、AI を使うと 個人でも見えてくる。

これは「Matt 氏が悪人だ」という結論ではない。人間は誰でも、自分の状況に合わせた物語を語る。そして、リーダーや有名人ほど、その物語は社会的な影響力を持つ。だから検証する必要がある。

物語を語ることと、物語を信じることは、別の活動である。 AI を使えば、後者を 構造的に 行うことができる。

事例 2(別ページ):Node.js を仕事で採用すべきか ──「管理されていない」現実

WordPress の事例は、特定個人による過度な集中 という管理不全だった。逆方向の事例 ── 誰も全体を管理していない という管理不全 ── を、身近な技術判断で検証する。題材は Node.js を仕事で採用すべきか である。

検証の結果、

が見える。WordPress は「一人が責任を持ちすぎる」、Node.js は「誰も責任を持たない」── どちらも管理失敗だが、方向が違う。

詳細な 5 ステップ検証は、本章末尾の 実例 1 のページを参照。表層の物語の抽出から、一次情報照合、時系列整合性、第三者記録の横断、最終的な「分かったこと/分からないこと」整理まで、ウォークスルー形式でまとめてある。

事例 3(別ページ):Linux ディストリビューションを何で選ぶべきか ──「無料・永続・中立」が崩れるとき

WordPress と Node.js の二例で見てきたのは、

という二つの管理不全だった。

ここに、もう一つの典型的な失敗モード ── 企業ステワードが途中で約束を変える ── を示す事例を加える。題材はサーバー用途の Linux ディストリビューション選定 である。

検証の結果、

が見える。WordPress は「一人が責任を持ちすぎる」、Node.js は「誰も責任を持たない」、Linux ディストリは「企業ステワードが約束を書き換える」── どれも管理失敗だが、方向が違う。

詳細な 5 ステップ検証は、本章末尾の 実例 2 のページを参照。 CentOS EOL 当日の現場の混乱、Canonical の 5〜10 年単位の方針転換、 Debian の構造、AlmaLinux / Rocky Linux の永続性検証、採用判断への時間軸別の含意まで、ウォークスルー形式でまとめてある。

Debian は、20 年単位で計画を立てられる唯一級の Linux である。それは技術ではなく、ガバナンス構造 が約束する。

事例 4(別ページ):Microsoft の「ネイティブアプリ回帰」は本物か ──「100% ネイティブ」の対象範囲、そして AI が AI に騙された実例

WordPress、Node.js、Linux ディストリの三例で見てきたのは、

という三つの管理不全だった。

第四の事例は、情報インフラの所有者が物語を AI に学習させる という、これまでとは性質の異なる失敗モードを示す。題材は、2026 年 4 月 29 日に Satya Nadella が打ち出した Microsoft の「ネイティブアプリ回帰」戦略 である。

検証から分かったこと:

そして、本書全体を通じて最も重要な発見:

Gemini Pro 自身が、Microsoft の「ネイティブ回帰」物語に騙された。同じ題材について Gemini Pro が出力した「.NET 10 Native AOT の技術的成熟度」資料には、「Entity Framework Core / Microsoft.Data.SqlClient の AOT 対応がほぼ完璧になった」という記述が含まれていた。しかし Microsoft の 公式ドキュメントは正反対のことを書いている ── 「EF NativeAOT applications in production を recommend against する」「highly experimental」と明記。 Gemini Deep Search に検証させて初めて、この 致命的な過大評価 が明らかになった。

つまり、AI が物語を作り、AI が物語を増幅し、別の AI が一次情報で検証して初めて誤りが見える ── という構造である。これは個別の事例ではなく、情報インフラを所有する大企業が AI を経由して開発者判断に影響を与える、一般的なパターン である。

WordPress は「一人が責任を持ちすぎる」、Node.js は「誰も責任を持たない」、Linux ディストリは「企業ステワードが約束を書き換える」、Microsoft「ネイティブ回帰」は「情報インフラを所有する事業者が、AI を含む情報経路を通じて物語を浸透させる」── どれも管理失敗だが、方向が違う。

詳細な 5 ステップ検証は、本章末尾の 実例 3 のページを参照。「100% ネイティブ」の対象範囲特定、Microsoft 365 部門の WebView2 選択、Web ラッパー型アプリの実測リソース消費、.NET 10 Native AOT の実証成果と限界、Gemini Pro vs Deep Search の検証比較、サードパーティ開発者の経済学までウォークスルー形式でまとめてある。

「100% X」「Y 回帰」と聞いたら、まず 「100% の対象は何か」 を AI に聞く。さらに、異なる手法の AI に同じ問いを投げて答えを比較する。Gemini Pro と Deep Search、Claude と ChatGPT ── 答えが割れる箇所こそ、人間が一次情報で確認すべき場所である。

物語検証の一般的な作法

WordPress の事例から、一般化できる作法を 5 つ挙げる。

flowchart TB N(["物語
(発言・記事・ピッチ)"]) S1["1. 主張を抽出して分類
(事実 / 意見 / 修辞)"] S2["2. 事実主張を一次情報と照合
(決算・契約・議事録・判決)"] S3["3. 時系列で整合性をチェック
(過去の発言と矛盾しないか)"] S4["4. 第三者の検証可能な記録を当てる
(訴訟・告発・監査・学術)"] S5["5. 分かったこと / 分からないこと
を整理"] Out(["判断
(結論を急がない)"]) AI[("チャット型 AI
(Claude / Gemini / GPT)")] Deep[("Deep Research 型 AI
(引用必須)")] N --> S1 --> S2 --> S3 --> S4 --> S5 --> Out S1 -.- AI S2 -.- Deep S3 -.- AI S4 -.- Deep classDef step fill:#e8f5e9,stroke:#7a9a6d,color:#3a4d34 class S1,S2,S3,S4,S5 step

1. 主張を抽出して分類する

物語をそのまま信じる前に、「この物語は、何を主張しているのか」 を明示的に書き出す。Claude に手伝わせるとよい:

以下のテキストの主要な主張を抽出してください。各主張を、 (a) 客観的事実の主張 (b) 意見・評価 (c) 比喩・感情表現に分類してください。

(a) だけが検証の対象になる。(b)(c) は議論の余地がある(または検証不要な)領域である。

2. 事実主張を一次情報と照合する

抽出した事実主張を、一次情報 に当てる。

「ニュース記事は二次情報」という意識を持つ。記事の中で引用されている発言や数字を、可能なら原典で確かめる。AI に「この記事の引用元を教えて」と頼むと、原典を見つけやすい。

3. 時系列で整合性をチェックする

過去の発言と現在の発言が整合するか。

物語の最大の脆弱性は時間軸である。人間は今この瞬間の都合に合わせて物語を作るが、過去の自分の発言は記録されている。

4. 第三者の検証可能な記録を当てる

当事者だけの発言ではなく、第三者の証言 や 公的記録 を当てる。

第三者の視点が入ると、物語の 盲点 が見える。

5. 「分かったこと」と「分からないこと」を分ける

検証の最後に、

を整理する。結論を急がない。情報が足りないなら「足りない」と書く。これが知的誠実さである。

仕事におけるこの作法の重要性

物語検証は、単なる時事評論の道具ではない。仕事のあらゆる場面で重要な役割を果たす。

ベンダー選定

営業のピッチ、ホワイトペーパー、事例集 ── これらはすべて物語である。「導入企業 1,000 社」「平均 ROI 300%」「業界 No.1」── これらの事実主張を、Claude と一緒に検証する。

「業界 No.1」と書いてある根拠は何か。どの調査機関の、どのカテゴリで、どの時点の数字か。比較対象に何を含めて、何を含めていないか。

数値の物語は、定義の操作で大きく変わる。AI で因数分解する。

経営判断

業界レポート、コンサルの提言、競合分析 ── これらも物語である。「市場は年率 30% で成長」「新規参入の脅威は高い」── これらの裏にある一次データ、調査方法、想定を、AI と一緒に確認する。

採用面接

履歴書も物語である。「プロジェクトをリードして売上を 50% 伸ばしました」── 実際にリードしたのは何人のチームか、その「50%」は何の基準か。AI で構造を分解した上で、面接で具体的に聞く。

(注:採用は法的な保護領域でもあるので、AI で個人を「評価」することには慎重になる。AI は 質問の精度を上げるため に使う。)

投資判断

決算発表、IR 資料、CEO 発言 ── すべて物語。会計数字の脚注、過去のガイダンスとの差、業界比較 ── AI で広く深く検証する。

契約交渉

相手の主張、業界慣習、過去の判例 ── AI と一緒に。「相場どおり」と言われたときに、本当に相場かを確かめる。

政策・公共の意思決定

これは仕事の話ではないが、市民として最も重要な領域だ。政治家、官庁、業界団体の発言を、有権者として検証する。AI を使えば、専業記者でなくても、ある程度の検証ができる。

物語に流されると、人は時間と金を失う。検証する習慣を持てば、その損失を桁違いに減らせる。

注意点 ── AI も物語に流される

AI で物語を検証する、というと万能のように聞こえるが、AI 自身も物語に流される。これが本章の最も重要な留意点だ。

1. AI は誤った情報を「自信を持って」出す

Claude や ChatGPT は、訓練データの偏りや幻覚(hallucination)で誤った情報を出す。事実主張は、必ず一次情報で再確認する。AI は仮説を出す、人間が事実確認する、この役割分担を守る。

2. AI は権威に忖度する

公式ドキュメント、CEO 発言、大企業の公式ブログを「信頼できる」と扱いやすい。Gemini Pro が Microsoft の「ネイティブ回帰」物語を信じて、EF Core の AOT 対応を「ほぼ完璧」と要約してしまった事例 (実例 3)は、その典型である。権威ある情報源こそ批判的に検証する。

3. AI は質問者に忖度する

RLHF で「ユーザーが満足する応答」を学習している AI は、ユーザーの仮説を裏付ける情報を優先的に出す。「この主張は正しいですか?」と問えば肯定を、「誇張ではないですか?」と問えば否定を出しやすい。 仮説を立てる前の「白紙の問い」と、仮説を立てた後の「批判的な問い」の両方を投げる。

4. 訓練データには情報インフラ所有者の偏りがある

AI 訓練データの源泉(GitHub、Stack Overflow、技術ブログ、企業ドキュメント)を所有・運営する事業者の物語が、AI に増幅されて返ってくる。Microsoft が GitHub・LinkedIn・OpenAI 投資・npm を所有している構造を踏まえれば、Microsoft 関連の物語が AI を通じて開発者判断に影響することは構造的にあり得る。

5. 異なる手法の AI を組み合わせる

通常チャット型(Gemini Pro、Claude、ChatGPT)+ Deep Research / Deep Search 型(一次情報引用付き)を組み合わせる。後者は引用元の URL を要求するため、ハルシネーションと権威バイアスを大幅に減らせる。複数のベンダーで答えを比較するのも有効。

6. AI ベンダー自身の物語に注意

AI ベンダー(Anthropic、OpenAI、Google など)も、自社製品について物語を語っている。それを同じ AI に検証させると循環参照が起きる。 AI 業界の主張は、AI 業界外の情報源で検証する。

7. 最終判断は人間

AI が「矛盾している」「整合している」と指摘しても、その判断が正しいとは限らない。AI の出力は 仮説 として扱い、自分で原典に当たって判断する。「AI がそう言ったから」は、判断の根拠にならない。

8. 個人攻撃の道具にしない

物語の検証は、当事者を糾弾するためではなく、自分の判断を間違えないため に行う。検証結果を SNS で攻撃材料に使う、という方向には進まないように注意する。これは知的な作業であって、感情的な活動ではない。

まとめ

AI ネイティブな仕事の作法は、AI に 任せる だけではない。AI と 一緒に考える こと、特に 物語を検証する ことは、AI 時代に人間が果たすべき重要な役割である。

物語を作るのは、AI が得意だ。物語を検証するのも、AI が得意だ ── ただし、作る側と検証する側の AI が同じ訓練データから出ていれば、両者の偏りは打ち消されない。検証する側に 異なる手法の AI を据えるのは、人間の選択である。

物語を額面通り受け取らないこと。AI を使って構造を見ること。AI 自身も物語に流されることを忘れないこと。これができるかどうかで、AI 時代の仕事の質は大きく分かれる。

次の最終章では、これらの道具と作法をすべて組み合わせて、1 人 + AI という新しい仕事の単位がどう成立するかを見る。

関連

実例

再現可能なソース・コマンド・実測結果を、別ページにまとめてある。