# 実例 1 — Node.js を仕事で採用すべきか:AIで物語を検証する

第11章「AIで物語を検証する」の作法を、**Node.js 採用判断** という
身近な実務シナリオに適用したウォークスルー。

## このページで実演すること

「Node.js を社内で採用しよう」という提案を受けたときに、AI と
一緒に物語を 5 ステップで検証する具体的な手順を示す。

WordPress / Mullenweg 事例(本章の事例)が **過度な個人集中** という
管理不全を示したのに対し、Node.js は **誰も全体を管理していない**
── 正反対の管理不全パターンを示す。

> どちらも「管理されていない」という共通項を持つ。
> AI を使えば、どちらの失敗モードに直面するかを採用前に見抜ける。

---

## 表層の物語(採用提案者がよく語ること)

Node.js を社内で推す提案を受けた、と仮定する。提案者の話、ベンダー
資料、技術ブログ、Stack Overflow の調査、Hacker News のコメントから、
おおよそこういう物語が組み立てられる。

1. **「Node.js は現代 Web 開発の標準である」** ── ほぼすべての
   モダンスタックで使われている
2. **「主要企業が支援している」** ── Microsoft、IBM、Red Hat、Google
   など。OpenJS Foundation の傘下
3. **「成熟したエコシステム」** ── npm に **数百万のパッケージ**、
   何でも揃う
4. **「Netflix、Uber、LinkedIn など世界規模で実績」** ── 大企業が
   採用する以上、安全
5. **「オープンソース、ベンダー中立」** ── 特定企業に縛られない
6. **「優れたパフォーマンスとスケーラビリティ」** ── 高負荷でも動く

聞こえはとてもいい。「これだけの実績があるなら採用しない理由がない」
と感じる。ここで 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で物語を検証する](/ai-native-ways/verify-narratives/)
- 第7章: [Web を作る ── React を捨て Markdown と HTML/CSS で書く](/ai-native-ways/web/)
  (npm の構造的な脆弱性についての具体的な対策)
- 構造分析シリーズ: [Mythos 時代のセキュリティ設計](/insights/security-design/)