第11章「AIで物語を検証する」の作法を、Node.js 採用判断 という 身近な実務シナリオに適用したウォークスルー。
このページで実演すること
「Node.js を社内で採用しよう」という提案を受けたときに、AI と 一緒に物語を 5 ステップで検証する具体的な手順を示す。
WordPress / Mullenweg 事例(本章の事例)が 過度な個人集中 という 管理不全を示したのに対し、Node.js は 誰も全体を管理していない ── 正反対の管理不全パターンを示す。
どちらも「管理されていない」という共通項を持つ。 AI を使えば、どちらの失敗モードに直面するかを採用前に見抜ける。
表層の物語(採用提案者がよく語ること)
Node.js を社内で推す提案を受けた、と仮定する。提案者の話、ベンダー 資料、技術ブログ、Stack Overflow の調査、Hacker News のコメントから、 おおよそこういう物語が組み立てられる。
- 「Node.js は現代 Web 開発の標準である」 ── ほぼすべての モダンスタックで使われている
- 「主要企業が支援している」 ── Microsoft、IBM、Red Hat、Google など。OpenJS Foundation の傘下
- 「成熟したエコシステム」 ── npm に 数百万のパッケージ、 何でも揃う
- 「Netflix、Uber、LinkedIn など世界規模で実績」 ── 大企業が 採用する以上、安全
- 「オープンソース、ベンダー中立」 ── 特定企業に縛られない
- 「優れたパフォーマンスとスケーラビリティ」 ── 高負荷でも動く
聞こえはとてもいい。「これだけの実績があるなら採用しない理由がない」 と感じる。ここで AI を使って検証する。
ステップ 1:主張の抽出と分類
Claude に、まず主張の地形を整理してもらう。
上記の Node.js 採用提案から、主張を抽出して、(a)客観的事実、 (b)意見・評価、(c)比喩・修辞 に分類してください。
Claude の応答(要約):
| 主張 | 分類 | 検証可能性 |
|---|---|---|
| 「現代 Web 開発の標準」 | 評価(普及度の事実+価値判断) | 部分的に検証可 |
| 「主要企業が支援」 | 事実主張 | 検証可 |
| 「成熟したエコシステム」 | 評価 | 「成熟」の定義次第 |
| 「Netflix らが採用」 | 事実主張 | 検証可 |
| 「ベンダー中立」 | 事実主張 | 検証可 |
| 「優れたパフォーマンス」 | 評価 | 比較対象次第 |
(a) と (c) を分けるだけで、議論の地形が見えてくる。「標準」「成熟」 「優れた」 ── これらは評価語であって、事実ではない。
ステップ 2:事実主張を一次情報と照合する
「主要企業が支援」を一次情報で検証する。
Node.js Foundation / OpenJS Foundation の理事会・スポンサーの 推移を 2009 年から現在まで時系列で整理してください。スポンサー 額、影響力の所在、ガバナンス構造の変遷を含めて。
Claude が整理する内容(要点):
- 2009 年:Ryan Dahl 個人が Node.js を作る。Joyent が雇用・ サポート
- 2014 年:Joyent と一部のコア開発者が衝突 → io.js フォーク
- 2015 年:io.js が Node.js Foundation(Linux Foundation 傘下) として再統合
- 2019 年:JS Foundation と合併し OpenJS Foundation に
- 2020 年:npm Inc. が GitHub(Microsoft)に買収 ── npm レジストリは事実上 Microsoft の所有物に
- 現在:Node.js ランタイムは OpenJS Foundation、npm レジストリは Microsoft、両者の ガバナンスが分離 している
ここで重要な発見が出る。
「Node.js」は一枚岩ではない。ランタイムと、その配布インフラ (npm)は別組織が運営している。
「主要企業が支援」は事実だが、支援の対象が分裂している。Node.js 本体は財団傘下でも、開発者が日々触れる npm レジストリは一企業 (Microsoft)に握られている。これは「ベンダー中立」という主張と 正面衝突する。
ステップ 3:時系列で整合性をチェック
これが Node.js の物語で最も劇的な部分だ。
Node.js の作者 Ryan Dahl の発言を、2009 年から現在まで時系列で 整理してください。Node.js への評価がどう変化したかを示してください。
Claude が整理する(要点):
- 2009〜2012 年:Node.js を熱心に推進。「サーバーサイド JavaScript の革命」と語る
- 2018 年(JSConf EU):「Node.js について後悔している 10 のこと」
と題する講演で、自分が作った設計の根本的な誤りを公に列挙
[要検証]- npm の設計、ビルドシステム、モジュール解決、セキュリティモデル、 package.json の肥大化など
- 2018 年:Ryan Dahl が Deno を発表 ── Node.js の設計上の 問題を解消する目的で、ゼロから作り直した代替ランタイム
- 2021 年:Deno Land 社を設立、Node.js とは異なる方向で開発 継続中
- 並行して:Jarred Sumner が Bun を 2022 年に発表 ── パフォー マンスと開発体験の問題を解消する別の代替ランタイム
Node.js の創始者が、自分が作ったものの設計を公に否定し、ゼロから 作り直す代替を作っている ── この事実は、「成熟した、信頼できる 標準」という物語と正面から衝突する。
なぜなら、本当に「成熟した標準」なら、創始者は改良で対応するはず だ。フォークやリプレイスメントが現れるのは、根本設計の問題が 直せない という判断があるからだ。
ステップ 4:第三者の検証可能な記録と照合
Node.js 採用の現実的な含意を、第三者の記録で検証する。
過去 10 年の Node.js / npm の主要なサプライチェーン事件を、被害 規模・原因・対応とともに整理してください。
Claude の整理(主要なものだけ):
- 2018 年:event-stream 事件 ── 暗号通貨ウォレットを狙った
悪意あるコードが、メンテナー交代を経て公式パッケージに混入。
数百万ダウンロード
[要検証] - 2021 年:ua-parser-js 事件 ── 6 億ダウンロード超えの人気
パッケージのアカウント乗っ取り。マイナーや RAT が混入
[要検証] - 2022 年:colors / faker 事件 ── 著名メンテナー本人による 意図的な機能破壊。数百万のプロジェクトが影響
- 2024 年:xz-utils バックドア ── npm ではないが、長期計画的 な内部侵入として教訓
- 2026 年:SAP npm パッケージ汚染事件 ── 1,100 超のリポジトリが
流出
[要検証](第7章で詳述)
加えて、メンテナー側からの証言 も記録に残っている。
- 2024 年:lodash や moment.js などの主要パッケージのメンテナーが 「燃え尽き」を公に語る
- 「ビリオン規模のビジネスが、無償ボランティア 1〜2 人に依存して いる」という構造が、何度も指摘される
「主要企業が支援」「成熟したエコシステム」という物語の裏側で、 数百万社のビジネスを支えるコードが、無償ボランティアの善意に 寄りかかっている。これは支援ではなく、寄生に近い。
ステップ 5:分かったこと/分からないことの整理
ここまでの検証で、事実関係としてはっきりしたこと を整理する。
| 項目 | 結論 |
|---|---|
| 普及度 | 確かに広く使われている(事実) |
| ベンダー中立 | 不正確。npm レジストリは Microsoft 所有 |
| 主要企業支援 | 事実だが、構造の脆弱性を覆い隠している |
| 創始者の評価 | 負の評価。Ryan Dahl は Deno を作って離脱 |
| 設計の成熟 | 疑問。創始者本人が根本問題を列挙、代替が複数登場 |
| 実績企業の採用 | 事実。ただし大企業ほど 専属チームでメンテナンスしている |
| サプライチェーン安全性 | 構造的に脆弱。ほぼ毎年大規模事件 |
| メンテナー基盤 | 脆弱。無償ボランティア依存 |
そして、まだ検証できていないこと:
- Deno や Bun が代替として完全に成熟したか(まだ移行期)
- npm の代替レジストリ(JSR、jsdelivr など)がどこまで普及したか
- 大企業が Node.js から移行している実態の数字
浮かび上がる「管理されていない」構造
WordPress の事例(本章本文)で見えたのは、Matt Mullenweg 氏と いう個人による過度な集中 だった。WordPress.org、財団、Automattic の境界が個人の都合で揺れる構造的な脆さ。
Node.js の事例で見えるのは、正反対の問題 ── 誰も全体を管理 していない という脆さである。
- ランタイムは財団、レジストリは一企業、品質は個別メンテナーの善意
- 創始者は離脱して代替を作っている
- メンテナーは燃え尽きと乗っ取りに晒されている
- セキュリティ事件は構造的に再発する
- 「主要企業が支援」と言われるが、何かあったときの責任を取る人が どこにもいない
WordPress は「一人が責任を持ちすぎる」、Node.js は「誰も責任を 持たない」── どちらも管理失敗だが、方向が違う。
オープンソースの物語は、しばしば「コミュニティ全体が支えて いる」と語る。AI で検証すると、その「コミュニティ」の実体は、 無責任の分散 であることが多い。
採用判断への含意
検証の結果、Node.js 採用判断について、こういう問いが出てくる。
- 誰が責任を取るのか? ── レジストリは Microsoft、ランタイムは 財団、個別パッケージはボランティア。事故があったとき、組織として 追える相手がいない
- 代替パスはあるか? ── 移行コストの見積もりに「Deno や Bun に 乗り換える可能性」を織り込むべきか
- 依存ツリーを見られるか? ── 採用するなら、依存パッケージ全体を 自分たちで監査する覚悟があるか
- 長期保守の体制は? ── 既存大企業のように専属チームを置く余裕が あるか、ないなら別の選択肢を考えるべきか
これらは「Node.js を採用するな」と結論する話ではない。採用するなら、 何に、どこまで備えるべきか が、物語ではなく構造で見える、という ことだ。
物語検証の力
この事例で示したかったのは、物語が真っ二つに割れる という体験 である。
採用提案者の物語は嘘ではない。Node.js は確かに普及しており、確かに 大企業が使っている。しかし、物語が省略していた構造的な脆さが、 AI の検証で浮かび上がる。
「広く使われている」と「安全に長く使える」は別の話だ。 「主要企業が支援」と「事故時に誰かが責任を取る」も別の話だ。 これらが混同されたまま採用判断をすると、後で「こんなはずではなかった」 となる。
1 個人による過度な集中(WordPress / Mullenweg)も、 全体不在の分散(Node.js)も、 どちらも 管理されていない 状態である。 採用判断のときに、どちらの問題に直面するかを知っておくと、 後の対応が桁違いに楽になる。
これが、AI で物語を検証することの実務的な価値である。採用前に 構造が見える ことで、採用後の仕事の質が変わる。
関連
- 第11章本文: AIで物語を検証する
- 第7章: Web を作る ── React を捨て Markdown と HTML/CSS で書く (npm の構造的な脆弱性についての具体的な対策)
- 構造分析シリーズ: Mythos 時代のセキュリティ設計