なぜ11行のコードが世界のビルドを一斉に壊せたのか

結論：壊れたのは「行数」ではなく「依存の連鎖」

横にスクロール

left-pad事件が教えるのは、「11行しかない小さな関数が世界を壊した」という数字の意外性そのものではありません。本当の原因は、無数のプロジェクトが自分では意識すらしていない末端の1パッケージを、何層もの推移的依存を通じて共有していたという構造にあります。中心にあったコードの小ささは、この構造的な脆弱性を誰の目にも分かる形で可視化しただけの、いわば症状の表面にすぎませんでした。

当時の状況と競合：パッケージ名を巡る対立と、抗議としての一括削除

2016年当時のnpmは、パッケージ名を早い者勝ちで登録できる一方、名前の所有権を巡るトラブルへの調停ルールが今ほど整っていませんでした。開発者Azer Koçuluは複数の小さなユーティリティパッケージをnpmに公開していましたが、そのうちの一つが、メッセージングアプリを提供する企業Kikのプロダクト名と衝突。Kik側からの申し立てを受けたnpm運営がKoçuluのパッケージ名を移管する判断を下したことで、両者の対立が表面化しました。

この対応に納得できなかったKoçuluは、抗議の意思表示として自分がnpmに公開していた全パッケージを一括で削除（unpublish）するという行動に出ます。当時のnpmは、公開者が自分のパッケージをいつでも自由に削除できる設計になっていました。個人の作品を個人の判断で取り下げること自体は筋が通っています。問題は、削除されたパッケージ群の中に、文字列の先頭を指定の文字で埋めて長さを揃えるだけの、わずか十数行の関数left-padが含まれていたことでした。

決定打・経緯：削除から数時間で世界中のビルドが壊れ、npmが緊急復元

left-padがレジストリから消えた瞬間、これに依存する無数のパッケージのnpm installが「パッケージが見つからない」エラーで失敗し始めました。left-pad自身を直接使っていたプロジェクトはごく一部でも、Babelのように多層の依存ツリーの奥深くでこれを取り込んでいたツールが軒並み巻き込まれたため、影響範囲はJavaScriptエコシステムの広い範囲に一気に波及しました。CI(継続的インテグレーション)のビルドが世界中で赤くなり、SNS上では「11行のコードがインターネットを壊した」という文脈で瞬く間に話題になりました。

事態を受けてnpm運営は、通常なら行わない例外的な判断として、Koçuluの意思とは別にleft-padパッケージ自体をレジストリ上で復元する措置を取りました。これによりビルド不能は数時間規模で収束しましたが、「公開者の意思に反してnpmがパッケージを復元した」という対応自体も、オープンソースの所有権とレジストリ運営者の権限を巡る新たな議論を呼びました。

この一件を受けて、npmは公開から一定時間が経過し、かつ他の公開パッケージから依存されているパッケージについては、作者であっても単純なunpublish操作を制限するようポリシーを改めました。個人の自由な削除権と、エコシステム全体の安定性のどちらを優先するかという線引きが、実際の障害を経てようやく明文化された形です。

今への影響と教訓：「バス係数」問題は今も終わっていない

left-pad事件が突きつけたのは、現代のソフトウェア開発が、ごく少数の—多くは無償の—個人が保守する基盤部品の上に、想像以上に大規模に積み上がっているという現実でした。あるプロジェクトの持続性が「特定の一人が興味を失ったら、あるいは燃え尽きたらどうなるか」という問い、いわゆるバス係数（bus factor）の低さに左右される構造は、この事件だけの特殊事情ではありません。

依存グラフの奥に潜むリスクを可視化する仕組みや、パッケージのロックファイル・レジストリの仕組みそのものについてはプログラミング、少人数運営のOSSが結果的に攻撃対象になった経緯は脆弱性シリーズ、CI/CDパイプラインの設計や依存関係の固定・監査の実務はDevOpsの各トピックを参照してください。

一段で言うと

left-pad事件は、パッケージ名を巡る対立への抗議として作者が自分の全作品を削除したところ、その中の十数行の小さな関数が実は無数のプロジェクトの依存の奥深くで使われており、世界中のビルドが数時間規模で連鎖的に壊れたという出来事でした。壊れた理由はコードの短さではなく依存グラフ上の位置であり、少数の個人が支える基盤に大規模なエコシステムが乗っかっているという構造は、形を変えながら今も繰り返されています。