ベンダーの語りは、そのままでは判断の材料にならない。一次情報で検算してから使う。3-01: 企業は自分でコードを書かないは、事務と基幹が並立し、税が二重にかかっていたことを見た。その税を払い続けるか、離れるかを決めるのは、ベンダーが語る物語ではなく、一次情報である。この章は、その検算の手順を置く。続く 3-03 と 3-04 の結論は、すべてこの手順で得たものだ。
AI 自身も、語りに引かれる
語りを確かめる仕事は、長らく記者・研究者・弁護士のものだった。時間と手間が要るからだ。AI はその手間を大きく下げる。5 年分の発言を時系列に並べる、 2020 年の主張と 2024 年の主張が整合するかを見る ── こうした横断はたしかに速い。
ただし、AI 自身も語りに引かれる。ここが出発点だ。
- 訓練データの厚みが偏る ── 英語が中心、西側の情報源が中心、ネット上の議論が中心である。Microsoft Learn、GitHub の README、大企業のブログは大量に入る。批判的なフォーラム投稿、地方紙、紙媒体、非英語の議論は薄い
- 権威に重みが寄る ── 公式ドキュメント、CEO の発言、大企業の公式ブログを信頼できる情報源として先に置きやすい。GitHub Issue や Reddit の投稿は軽く扱われる
- 多数派に重みが寄る ── 多くの記事が同じ主張をしていれば、AI はそれを事実として扱う。話題の量が、確かさの代わりに使われる
- 情報インフラを所有する側の語りが増幅される ── AI が学ぶ源泉は GitHub、 Stack Overflow、技術ブログ、企業ドキュメントである。Microsoft は GitHub を所有し、LinkedIn を所有し、npm を所有し、OpenAI に投資している。語り手が情報経路を所有していれば、その語りは AI を経由して戻ってくる
もう一つある。AI は質問者にも合わせる。人間のフィードバックで学習したモデルは、利用者が満足する答えを返す方向に寄る。「この主張は正しいか」と聞けば肯定が返り、「誇張ではないか」と聞けば否定が返りやすい。問いの形が、答えの向きを決めてしまう。
だから、確かめ方のほうを設計する
同じ訓練データから出た AI が、同じ訓練データを確かめても、両側に同じ偏りが残る。AI が AI を確かめるだけでは、思い込みは互いに補強される(2-17)。だから、確かめ方を先に設計する。
- 手法の違う AI を組み合わせる ── 通常のチャット型(Gemini Pro、Claude、 ChatGPT)に、一次情報の引用を必須とする Deep Research / Deep Search 型を足す。後者は引用元の URL を出すので、権威への寄りが減る
- 複数のベンダーに当たる ── Anthropic、Google、OpenAI に同じ問いを投げ、答えを並べる。一致する部分は確からしさが上がり、割れる部分は人が見る場所になる
- 批判的な仮説を立てる ── 「この主張は誇張ではないか」「反対の証拠はあるか」と明示して聞く。肯定を期待する問いは、肯定を引き出す
- 一次情報に当たる ── AI の出力は仮説である。公式のリリースノート、 GitHub Issue、法廷文書、憲章や規約 ── 最後は人が原典を見る
以下の四つの事例は、この手順で確かめたものだ。四つとも、語りの形は違う。
事例:WordPress ── 一人に権限が集まるとき
WordPress の共同創設者であり Automattic の CEO でもある Matt Mullenweg 氏は、 2024 年から大手ホスティング会社 WP Engine との対立を公にしている。公的発言、法廷文書、ブログ投稿、カンファレンス講演が大量に残っており、確かめる材料がそろっている。
氏の語りの主な主張は、おおむね四つに整理できる。WP Engine は WordPress のエコシステムにただ乗りしている。WP Engine は WordPress の姿を歪めている。 WordPress.org は自分の個人的な財産である。WP Engine の遮断はコミュニティを守る正当な行為である。
手順どおりに確かめると、こうなる。まず主張を「事実の主張」「意見・評価」「比喩」に分ける。「ただ乗り」は評価、「商標の不正使用」は事実の主張、「コミュニティを守る」は評価である。検算できるのは事実の主張だけだ。
次に一次情報に当てる。WordPress Foundation の商標方針、過去 10 年のコミュニティ議論、WordCamp での発言。時系列も並べる ── WP Engine が Heather Brunner 氏を CEO に迎えた 2014 年、Silver Lake の Lee Wittlinger 氏が WP Engine の取締役会に入った 2018 年、そして 2024 年の遮断まで。過去には WP Engine を WordCamp のスポンサーとして迎えていた時期があり、 WordPress.org の推奨ホスティング一覧に載っていた時期もある。
最後に第三者の記録を当てる。WP Engine 対 Automattic の訴訟(2024 年 10 月以降)では、双方の主張が宣誓のもとで提出される。2024 年 12 月の暫定命令は、 Automattic による WordPress.org からの WP Engine 遮断を差止の対象とした。これは「WordPress.org は個人財産だから自由に決められる」という主張とは別の線を引いている。
見えてくるのは、個人と財団の境界 ── WordPress.org、Automattic、WordPress Foundation の関係 ── が、語りのたびに置き直されていることだ。これは誰かを悪者にする結論ではない。人は誰でも、自分の状況に合った物語を語る。影響力の大きい人ほど、その物語は広く効く。だから確かめる。
事例:Node.js ── 全体を見る役が置かれていないとき
WordPress は、一人に権限が集まりすぎた形だった。逆向きの形もある。全体を見る役が置かれていない、という形だ。仕事で Node.js を採用すべきかを題材にすると、それが見える。
確かめると、こうなる。
- Node.js ランタイムは OpenJS Foundation、npm レジストリは Microsoft の所有である。「ベンダー中立」という語りは、後半に当てはまらない
- 創始者の Ryan Dahl 氏は 2018 年に「Node.js について後悔している 10 のこと」を講演し、Deno を作る方へ移った
- event-stream、ua-parser-js、colors、SAP ── 供給網の事件が、ほぼ毎年起きている
- 「主要企業が支援」という語りの内側で、10 億ドル規模の事業が、無償のボランティア 1〜2 人に支えられている区画がある
WordPress は一人が持ちすぎる形、Node.js は全体を引き受ける役が置かれていない形である。どちらも管理の形の問題だが、向きが逆だ。
事例:Linux ディストリビューション ── 約束が途中で変わるとき
三つ目の形は、企業のステワードが約束を途中で変える、というものだ。サーバー用の Linux ディストリビューションを選ぶときに、そのまま効いてくる。
- CentOS 8 ── 2020 年 12 月 8 日、2029 年までとされていたサポート期間が、 2021 年末までに変更された。8 年の前倒しである
- Red Hat の発言 ── 2014 年「CentOS の独立性を守る」、2019 年「IBM に買収された後も独立性は守られる」、2020 年「CentOS 8 を終了する」。三つを時系列に並べると、同じ線の上には乗らない
- Ubuntu / Canonical ── Snap の既定化(2020 年〜)、Ubuntu Pro の登録要件 (2022 年〜)、Mir と Unity の独自路線とその取り下げ。私企業の経営判断で、 5〜10 年ごとに方針が変わってきた
WordPress は一人が持ちすぎる形、Node.js は全体を引き受ける役が置かれていない形、Linux ディストリビューションは約束が途中で変わる形である。
事例:Microsoft の「ネイティブアプリ回帰」── スローガンの及ぶ範囲を測る
四つ目は、情報インフラを所有する側が語りを出す形だ。題材は、2026 年 4 月 29 日に Satya Nadella 氏が打ち出した「ネイティブアプリ回帰」である。
確かめると、範囲が見えてくる。
- OS のシェル層(スタートメニュー、タスクバー、ファイルエクスプローラー) では、WinUI 3 と .NET 10 Native AOT による「100% ネイティブ」化が進んでいる。2026 年 5 月の Windows 11 更新 KB5083631 が、その成果である
- 同じ Microsoft の中で、Microsoft 365 部門は別の道を選んでいる。新しい Outlook も Teams も WebView2 のラッパーである。クラシック Outlook からの移行は 1 年延期され(2026 年 4 月 → 2027 年 3 月)、サポートは 2029 年まで続く
- サードパーティ層では、Microsoft 自身が React Native for Windows を進めている(2026 年の 0.81 / 0.82)。開発者側の経済が変わらないかぎり、 Electron と React Native は続く
つまり「ネイティブ回帰」は、OS のシェル層という限られた範囲で本当に起きている。スローガンの及ぶ範囲と、実装の及ぶ範囲は、同じ大きさではない。「100% X」「Y 回帰」と聞いたら、まず「100% の対象は何か」を聞く。
Gemini Pro が、Microsoft の語りに引かれた
この事例には、AI の偏りがそのまま現れた場面がある。
Gemini Pro に「.NET 10 Native AOT の技術的成熟度」をまとめさせた資料には、 *Entity Framework Core と Microsoft.Data.SqlClient の AOT 対応がほぼ完璧になった* という記述が入っていた。同じ論点について、Microsoft 自身の公式ドキュメントは別のことを書いている ── EF Core の NativeAOT を本番で使うことは "recommend against" とされ、状態は "highly experimental" と明記されている。同じ問いを Gemini Deep Search に投げ、一次情報の引用付きで確かめて、初めてこの差が見えた。
出どころは、Gemini Pro が生成した同題材の資料と、Microsoft の公式ドキュメントである。前者は 2026 年の「ネイティブ回帰」を追った調査の一部で、後者は EF Core のドキュメントに現在も書かれている記述だ。
ここで起きたことは、章の最初に挙げた偏りの組み合わせである。権威ある情報源に重みが寄り、業界で繰り返されている「Native AOT は成熟した」という語りがそのまま通り、情報インフラを所有する側の物語が AI を経由して戻ってきた。そして、手法の違う AI(引用を必須とする Deep Search)を当てて初めて差が出た。検証の設計が効くのは、こういう場面だ。
Debian を確かめる ── 2-02 が土台に据える根拠
Linux ディストリビューションの事例には、同じ手順で確かめた別の結果がある。 Debian である。
- 1997 年の社会契約 ── ディストリビューションが利用者と自由ソフトウェアに対して何を約束するかを、文書として公開している
- 1998 年の憲法 ── 誰がどの決定権を持つか、プロジェクトリーダーをどう選ぶか、決定をどう覆せるかが、文書で定まっている
- 所有する企業が無い ── 買収の対象になる法人が、そもそも存在しない
- 資産は SPI(Software in the Public Interest)が保有する ── 商標も資金も非営利法人の側にあり、経営判断で方針が変わる経路が置かれていない
CentOS で起きたのは、企業のステワードが約束の期間を変えられた、ということだった。Ubuntu で繰り返されたのは、私企業の経営判断で方針が変わる、ということだった。Debian には、その経路がない。約束しているのは技術ではなく、 ガバナンスの構造 である。
Debian は、20 年単位で計画を立てられる側の Linux である。それを約束しているのは技術ではなく、1997 年の社会契約と 1998 年の憲法、そして所有する企業が無いという構造だ。
2-02: AI に PC を一台渡すが、会社の PC を Debian にして AI に渡す、と決めているのは、この検証の結果である。土台は長く同じ形で残るほうがよい。だから、長く同じ形で残る構造を持つものを選ぶ。「使いやすい」という理由ではなく、確かめた結果としてそこに置いてある。
一般化した五つの作法
四つの事例に共通する手順を、五つに整理する。
(発言・記事・ピッチ)"]) S1["1. 主張を抽出して分ける
(事実 / 意見 / 比喩)"] S2["2. 事実の主張を一次情報に当てる
(決算・契約・議事録・判決)"] S3["3. 時系列に並べて整合を見る
(過去の発言と同じ線に乗るか)"] S4["4. 第三者の記録を当てる
(訴訟・監査・証言・学術)"] S5["5. 分かったことと
分からないことを分ける"] Out(["判断
(結論を急がない)"]) AI[("チャット型 AI
(別の会社の物を複数)")] Deep[("Deep Research 型 AI
(引用が必須)")] N --> S1 --> S2 --> S3 --> S4 --> S5 --> Out S1 -.- AI S2 -.- Deep S3 -.- AI S4 -.- Deep classDef good fill:#e8f5e9,stroke:#7a9a6d,color:#3a4d34 class S1,S2,S3,S4,S5 good
1. 主張を抽出して分ける
語りを受け取る前に、「この語りは何を主張しているのか」を書き出す。AI にやらせるとよい。各主張を (a) 客観的事実の主張、(b) 意見・評価、(c) 比喩や感情の表現、に分ける。検算できるのは (a) だけである。
2. 事実の主張を一次情報に当てる
抽出した事実の主張を、原典に当てる。
| 語りの種類 | 当てる一次情報 |
|---|---|
| 経営者の発言 | 決算報告書、開示資料、SEC ファイリング |
| ベンダーのピッチ | 契約書の原文、SLA、過去の導入事例 |
| 技術の成熟度 | 公式ドキュメント、リリースノート、GitHub Issue |
| 法的な紛争 | 法廷文書、判決文 |
| 業界レポート | 一次データ、調査方法、標本の大きさ |
ニュース記事は二次情報である。記事の中の発言や数字は、可能なら原典で見る。 AI に「この記事の引用元はどこか」と頼めば、原典に早く着く。
3. 時系列に並べて整合を見る
過去の発言と今の発言が、同じ線に乗るか。乗らないなら、乗らない理由が説明されているか。Red Hat の 2014 年・2019 年・2020 年の発言を並べたのが、この作法である。語りのいちばん確かめやすい面は時間軸だ。人は今の都合に合わせて語るが、過去の発言は記録に残っている。
4. 第三者の記録を当てる
当事者の発言だけでなく、第三者の記録を当てる。訴訟の法廷文書、監査報告、議会や委員会の証言、退職者のインタビュー、学術論文での引用。WordPress の事例で暫定命令を当てたのが、これにあたる。第三者の記録は、当事者の語りが触れていない面を出す。
5. 分かったことと、分からないことを分ける
最後に、確認できた事実、確認できなかった事実、反対の主張がある論点、情報が足りない論点を分けて書く。情報が足りないなら、足りないと書く。結論を急がないことが、ここでの作法である。
この五つは、相手を糾弾するための道具ではない。*自分の判断を間違えないために使う*。書くのは「公式文書にはこう書いてある」という対比であって、それ以上でも以下でもない。
この作法で得た結論が、続く二章になる
転換編がベンダーの語りに対して取る立場は、この章の上に立っている。
続く 3-03: デジタル主権 ── Microsoft 問題と Trump 問題は、Microsoft 365 が経済でも安全でも既定値だった、という語りを検算した結果である。人数課金の推移、CLOUD Act の条文、テレメトリの公開情報、Copilot が内容をどこへ送るかの公式記述 ── 一次情報に当てたうえで、前提が反転したと言っている。
その次の 3-04: SIer委託モデルの構造的不経済も同じだ。「委託したほうが安い」という語りを、上流の判断がどこに残るか、一周に何が要るか、という確かめられる形に開いている。
どちらも、ベンダーの語りをそのまま受け取った結論ではない。この章の五つの作法を通した結論である。だから、読む側も同じ手順で検算できる。
まとめ
この章は、語りを一次情報で検算する手順を置いた。
- AI 自身も語りに引かれる ── 訓練データの厚み、権威、多数派、そして情報インフラを所有する側の語りが増幅される構造
- だから確かめ方を設計する ── 手法の違う AI を組み合わせ、複数のベンダーに当たり、批判的な仮説を立て、最後は一次情報に当たる
- 四つの事例 ── WordPress(一人に権限が集まる)、Node.js(全体を見る役が置かれていない)、Linux ディストリビューション(約束が途中で変わる)、 Microsoft の「ネイティブ回帰」(スローガンと実装の範囲が同じ大きさでない)
- Gemini Pro は EF Core の AOT 対応を「ほぼ完璧」とまとめ、Microsoft 公式ドキュメントは "recommend against" / "highly experimental" と書いている
- Debian の 1997 年の社会契約、1998 年の憲法、所有企業が無いこと、SPI が資産を持つこと ── 2-02 が Debian を土台に据える根拠はここにある
- 五つの作法 ── 主張の抽出 → 一次情報 → 時系列 → 第三者の記録 → 分かったことと分からないことの切り分け
語りを作るのは、AI が得意だ。語りを確かめるのも、AI が得意だ。ただし、作る側と確かめる側の AI が同じ訓練データから出ていれば、偏りは残ったままになる。確かめる側に手法の違う AI を据えるのは、人の選択である。
次の章は、この作法を Microsoft に当てる。人数課金、CLOUD Act、テレメトリ、そして米国政府への依存 ── 事務側の前提が、どこで反転したのかを見ていく。