BunのZig→Rust全面書き換え論争とは？Anthropicが53万行を11日でAI移植・Zig創設者の批判・unsafe 13,365個問題を徹底解説

Anthropic傘下のJavaScriptランタイム「Bun」が、53万5,496行のZigコードベース全体を、Claudeを主体とした最大64並列のAIエージェントで11日間かけてRustへ全面書き換えしました。2026年7月8日の公式ブログ公開後、Zig創設者のAndrew Kelleyが翌9日に痛烈な批判記事を公開し、AI生成コードの品質・技術的負債・レビュー不能問題をめぐる大論争に発展しています。

Bunの移植が成立したのは「150万超のアサーションを持つ適合性テストスイートが既にあった」という極めて特殊な前提条件があったからであり、同じことを大半の組織が真似すべきではありません。 また、この論争の本質は「ZigとRustのどちらが優れた言語か」ではなく、Kelley本人が結論づけているとおりエンジニアリング文化と価値観の乖離にあります。

日本語メディアでは「6日」「96万行」「13,044個」といった数字が混同されたまま流通しています。ここでは公式値との突き合わせ、Bun自身が公開した「unsafe監査ページ」の中身（13,365個のunsafeブロック、うち5関数が実バグ（unsound）と公式が自認）、そして「自社でAIによる大規模移植をやってよいか」の判断基準までを、一次情報ベースで整理します。AIによる大規模コード移植を検討している技術責任者・CTO、AI生成コードの技術的負債を経営層に説明する必要がある人に向けた内容です。

論争の構図：Bun・Kelley・未決着の争点

そして最も見落とされている事実がひとつあります。2026年7月14日時点で、Rust版のBunはまだ安定版として出荷されていません。 Bun公式のunsafe監査ページには「今日あなたがインストールするBunは、いまだにオリジナルのZig実装で動いている（the Bun you install today still runs the original Zig implementation）」と明記されています。v1.4.0はcanary（bun upgrade --canary）で試用できる段階です。「もうAIが書いたRust版が本番で動いている」という理解は、現時点では誤りです。

何が起きたのか：時系列で整理する

出典: Bun 公式ブログ

Bunは、JavaScript/TypeScriptのランタイム兼ツールキット（パッケージマネージャ・バンドラ・テストランナー・トランスパイラを内蔵）です。JavaScriptエンジンにJavaScriptCore（WebKit）を採用し、Node.js / Denoの競合として知られています。開発元のOvenは2025年12月にAnthropicが買収し、創業者のJarred Sumnerを含むBunチームは現在Anthropic所属です。

錯綜している数字を公式値で突き合わせる

このテーマの記事を読むときに最も注意すべきなのは、メディアごとに数字が食い違っている点です。 「6日」「11日」、「53万行」「96万行」「100万行」、「13,044個」「13,365個」、「99.8%合格」「100%グリーン」が混在しています。

これは誤報というより「何を数えたか」が違うことに起因しますが、多くの日本語記事が整理せずに転載しています。Bun公式ブログ（bun.com/blog/bun-in-rust）と公式unsafe監査ページ（bun.com/bun-unsafe-audit）の一次情報が正です。

Sumner氏は人力換算について「フルコンテキストを持つエンジニアチームで約1年かかる作業を、エンジニア1名 + Claude で11日で終えた」と述べています。この「1年 → 11日」というインパクトの強い数字が独り歩きしていますが、Bun側に揃っていた前提条件（巨大な適合性テストスイート、機械的翻訳に限定したタスク設計、移植後の監査予算）を無視したまま自社に当てはめるのは危険です。

なお、今回使われたClaude Fable 5は、Anthropicの現行世代モデルのプレリリース版です。モデル自体の性格や設計思想についてはClaude Fable 5とは何かで整理しています。

なぜZigからRustへ移行したのか

Bun公式が挙げる理由は、性能でも流行でもなく「メモリ安全性」が中心です。

Bun公式の説明（一次情報）

1. GCと手動メモリ管理の混在が構造的なバグ源だった：JavaScriptCore（GCが管理する）のJS値と、Zigの手動メモリ管理を混ぜた結果、use-after-free / double-free / エラー境界でのメモリリークが繰り返し発生していた。
2. 「スタイルガイド＋コードレビュー」では防ぎきれなかった：人間の規律に依存する方式に限界を感じ、Rustのborrow checkerによるコンパイラ強制の所有権保証へ移行したかった。
3. 移行後の安全網を用意した：borrow checker、Miri（未定義動作検出器。CIで対象を拡大中）、LeakSanitizer、パーサーに対する24時間365日のカバレッジガイド付きファジングを導入。

実際、メモリの改善効果は明確に報告されています。一例として、Bun.build()を2,000回反復した際のメモリ使用量が6,745MBまで増加していたものが、609MBで頭打ちになるよう改善されました。v1.3.14比で128件のバグ修正も行われています。

コミュニティが指摘する「もう一つの動機」（※Bun公式は明言していない）

以下は第三者メディアやコミュニティ側の解釈であり、Bun公式ブログはZigのAIポリシーにもフォークにも一切言及していません。留保付きで受け止めるべき情報です。

• BunはClaude Codeの実行基盤でもあり、Claude Code側で14〜23GBのメモリリークが報告されていた。つまりメモリ問題の解決はAnthropicにとってビジネス上の切実な課題だった、という見方
• Rustのエコシステムとコントリビュータ人口がZigより桁違いに大きい
• ZigのAI寄稿禁止ポリシーにより、Anthropic傘下でAIファースト開発を続ける限りZigとは共存できなかった、という見方

とくに「ZigのAI禁止ポリシーがRust移行を強制した」と断定する記事が散見されますが、これはBunの公式表明ではありません。

どうやって11日で100万行を移植したのか

出典: Bun 公式リポジトリ（GitHub）

Bunの手法で最も参考になるのは、モデルの性能ではなく「バグを手で直すのではなく、バグを生むプロセスの側を直す」という設計思想です。

公式ブログが説明する主なワークフローは次のとおりです。

• ポーティングガイドを先に作成。Zigのパターン → Rustのパターンの対応表を定義し、全エージェントに共有する
• 別ワークフローで、元コードのライフタイム（生存期間）を追跡・注釈してから移植させる
• 1つの実装エージェントに対し、最低2つの「敵対的レビューエージェント」を別コンテキストで走らせる
• レビュー指摘を、さらに別のエージェントが修正として適用する
• 最大64 Claude（4 worktree × 16 Claude）を24時間稼働させ、ピークで毎分約1,300行を生成

重要なのは、公式が「初期の一括生成直後は、まったく何も動かなかった（Absolutely none of it worked yet）」と正直に書いている点です。11日間の大半は、生成ではなく「テストを通すためのループ」に費やされています。

この「実装役とレビュー役を別コンテキストで分離し、多数のエージェントを並列に回す」やり方は、規模こそ違え個人でも再現可能な設計です。並列エージェント運用の実務についてはClaude Codeのサブエージェント活用ガイドやClaude Code Agent Teamsの使い方で解説しています。エージェント同士に役割を分担させる考え方の基礎はAIエージェントとは何かを参照してください。

Simon Willison氏はこの手法を「dynamic workflows、trial runs、adversarial reviewを備えた、洗練されたエージェンティック・エンジニアリング」と評価し、Joel Spolskyの名エッセイ「絶対に書き直すな」（2000年）への挑戦として位置づけました。「プログラミング言語の選択はこれまで“片道切符”だったが、AIエージェントがそれを覆した」という指摘です。

品質はどう担保されたのか：150万アサーションという「てこ」

Bunの移植を成立させた最大の要因は、モデルの賢さではなく、既存の巨大なテストスイートです。

• テストのスキップ・削除はゼロ
• 1プラットフォームあたり約57,000〜60,000テスト
• 100万〜138万回のexpect()アサーション
• 対応6プラットフォーム（Linux x64/arm64、macOS x64/arm64、Windows x64/arm64）すべてで最終的にグリーン
• 移植中に19件のリグレッションを自ら発生させ、修正した

Willison氏はこれを「適合性テストスイートがてこ（leverage）になった」と表現しています。人間が読めない量のコードをLLMに書かせても、正しさを機械的に検証し続ける安全網があったからこそ、レビューを自動化できた、という構図です。

逆に言えば、この安全網がない組織が同じことをやると、検証不能な100万行だけが残ります。 ここが自社適用を考えるうえでの分岐点になります。

unsafe 13,365個問題：Bun自身が「5件の実バグ」を認めた

出典: Bun 公式 unsafe監査ページ

ここが今回の論争の技術的な本丸です。

外部からの批判

コミュニティの集計で、生成されたRustコードに13,365個のunsafeブロックが含まれることが判明し、炎上しました。Rustのunsafeは、コンパイラの安全性チェックを明示的に外すための構文です。ここが多いほど、Rustを使う最大の利点である「コンパイラによる強制」が効かなくなります。

• Hacker Newsでは「codebase fails basic miri checks, allows for UB in safe rust（Miriの基本チェックすら通らず、safe Rustから未定義動作に到達できる）」と指摘された。MiriはRustの未定義動作を検出するインタプリタで、LLM生成のunsafeコードでは実行が標準的作法とされますが、Bunはマージ前にMiriを通していませんでした。具体例として、PathStringがポインタのアドレスと長さを1つのポインタに詰め込む（Zig由来のテクニック）ため、Rustの厳格なメモリモデルではライフタイム問題を起こすと指摘された
• Charlie Marsh氏（Astral / uv 作者）の指摘：「200個の既知の問題を、13,000個のunsafeブロックに潜む未知の数のバグと交換したのではないか」
• 「AIによる翻訳コードは元言語の構造を保持し、移行先言語のイディオムを採用しない。結果として人間が読めず、リファクタも拡張もできないコードになる」という構造的批判
• 「Bunチームの誰一人としてこの新しいコードベースを完全には理解していない」という運用面の懸念

なお「同規模の人手書きRustではunsafeは73個程度」という比較が広く拡散しましたが、比較対象の定義や出典が曖昧です。数字として鵜呑みにすべきではありません。

Bun公式の自己監査：13,365個の内訳と5件の実バグ

批判を受けて、Bunは公式にunsafe監査ページ（bun.com/bun-unsafe-audit）を公開しました。擁護でも言い訳でもなく、自ら問題を数え上げている点で一次情報として重い内容です。

つまり、批判側の「13,000個やばい」も擁護側の「想定内の中間状態」も、どちらもBun自身が公開した数字の一部しか見ていないということです。事実は「Bunは問題を認識し、定量化し、実バグ5件を公表し、是正計画を出したうえで、Rust版をまだ安定版として出荷していない」です。

擁護側と批判側の再反論

• 擁護側：これは大規模移植における想定内の中間状態。翻訳は「即座の安全性」より「元Zigの挙動への忠実さ」を優先した。mainにマージしたのは広くコミュニティのレビューを受けるため。既存テストが改善のバックプレッシャーとして機能する
• 批判側：unsoundなコードをmainにマージするのは標準的な実務に反する。そもそも決定論的な変換ツールを使うべきで、確率的なAI生成に頼るべきではなかった

AI生成コードが持ち込むセキュリティ上の穴と、その検査の考え方についてはAIコーディングのセキュリティリスクで体系的に整理しています。

Andrew Kelleyの批判：「これは言語の問題ではない」

出典: Zig 公式リポジトリ（GitHub）

Zig創設者Andrew Kelleyの批判の核心は、「Zig vs Rust」ではありません。「持続的なエンジニアリング努力の欠如」です。

① 技術的な批判

• 「Zigのスタイルガイド」vs「Rustのコンパイラ強制所有権」という二者択一の立て方自体が誤りである。足りなかったのは、コードをレビューし、バグを直し、技術的負債を返済し、危険な箇所をファジングし、安定に必要な時間をかけるという地道な作業だった
• Bunのメモリ問題はZig言語のせいではなく、Bun固有の杜撰なエンジニアリング慣行の結果だ
• 性能向上とバイナリサイズ削減は言語変更と無関係であり、Zigのままでも達成できた。LTO（リンク時最適化）はZigに以前から存在したのに、Bunは活用していなかったし、comptimeの濫用については何年も前からZig側が警告しており、Zig Software Foundation（ZSF）は使用状況を監査するツールまで用意していた

② 最も鋭い一撃

Kelleyの批判で、最も反論が難しいのがこの一点です。

Bunのテストスイートが Zig版の安定性問題を捕捉できなかったのなら、なぜ同じテストスイートが、人間が一行もレビューしていない約100万行のRustコードの十分な品質保証になると言えるのか？

Bunのブログは「テストスイートがすべてのバグを捕捉した」と主張する一方で、「Zigコードベースはバグだらけだった」とも述べています。この2つは論理的に両立しない、というのがKelleyの指摘です。実際、公式監査ページが5件のunsoundな関数を後から発見していることは、この指摘を部分的に裏づけています。

③ 組織・人間関係の話

Kelleyの記事の後半は、技術論を超えた内容になります。

• Sumner氏は約5年前（2021年頃）にZigコミュニティに参加し、当初はZigを性能面で称賛し、Zig Software Foundationに年6万ドルを寄付していた
• VC調達後、優先順位が「持続可能な開発」から「短期的な生産性指標・イグジット」へシフトした
• Sumner氏の「初心者エネルギー（試行錯誤で高速に学ぶ姿勢）」は個人としては強みだが、他人をマネジメントする立場に立った途端に破壊的になった
• 引用された労務観（「ワークライフバランスが『働かない時間が多い』という意味なら、たぶんフィットしない」）が評判被害となり、優秀なZig開発者がOven/Bunへ参加するのを躊躇させた

④ 皮肉な結論と、本人による自己反省

Kelleyは最終的に「Rust移行を歓迎する」と述べています。理由は、Anthropic → Bun → Zig という連想によって、ZigにAI生成の低品質な寄稿が流入し、「真面目な言語開発」ではなく「AIハイプ」と結び付けられるリスクがあったからです。Rust移行によってその連想が断ち切られたので安堵している、という皮肉な締め方です。

そして記事の最後で、Kelleyは自己反省もしています。「ビジネス批判のつもりで書いたが、実際には未処理の恨みを抱えていたことが読者には明白だった」と認め、Sumner氏に悪意はなく、彼が彼の基準で成功したことは認めると述べています。今後は非難ではなくコミュニティの成果に注力する、とも宣言しました。

Kelleyの批判を「Zigの負け惜しみ」と矮小化するのは、本人の結論を読んでいないことになります。 本人が言うとおり、争点は言語能力の差ではなく価値観の乖離と関係の崩壊です。

事実 / Bunの主張 / Kelleyの主張 / 未決着の争点

この論争を正しく理解するには、「確定した事実」と「一方の主張」を分けて読む必要があります。

こうした「AI成果物を、十分な品質保証プロセスなしに世に出してしまう」構図は、Bunに固有のものではありません。KPMGがAIハルシネーションを含む報告書を撤回した事例や、Claude Code自身の品質劣化に関する公式ポストモーテムも、同じ問題系列にあります。

前史：ZigのAI寄稿禁止ポリシーとは何か

この論争の背景には、ZigがLLMによる寄稿を全面禁止しているという事実があります。

Zig公式のCode of Conduct（ziglang.org/code-of-conduct/）には、次のように明記されています。

• 「No LLMs for issues.」「No LLMs for pull requests.」「No LLMs for comments on the bug tracker」
• 対象はコードだけでなく散文も。言い換え・編集・翻訳・ブレインストーミング・バグ探しにLLMを使うことも禁止

Kelley氏の言い分は明快です。AI寄稿は「invariably garbage（例外なくゴミ）」であり、「価値がゼロどころかマイナスだ。チームのレビュー時間を奪うから」。Zigは常時約200のオープンPRを抱え、コアチームは少人数だという背景があります。

さらにZig Software FoundationのVP of Community、Loris Cro氏は「contributor poker（カードではなく人に賭ける）」という哲学を掲げています。レビューの目的はコードをマージすることではなく、信頼できるコントリビュータを育てることだ、という立場です。この論理に立つと、どれだけ完璧なAI製PRであっても、育成価値がゼロなので受け入れる意味がないということになります。

2026年5月には、BunがAI支援でbun-compileを約4倍高速化する改善を実装したものの、ZigのAIポリシーによりupstreamできずZigを独自フォークしたと報じられました（※Bun公式の言及はなく二次情報）。「AIファースト開発を掲げるAnthropic傘下の企業」と「AI寄稿を全面禁止する言語コミュニティ」は、構造的に共存が難しかった、というのがコミュニティ側の見立てです。

これは特殊事例か？業界データで一般化する

Bunの13,365個のunsafeは異常値ではなく、業界全体で進行している「保守性ギャップ」の、極端に可視化された事例です。

GitClearの「The Maintainability Gap: 2026 AI Code Quality Research」（2026年1月公開）は、2023〜2026年の6億2,300万件のコード変更を分析しています。

GitClearの解釈は端的です。AIは「欠陥としてラベル付けされないコード」を書くことを強く好む。 テストが通ること、エラーが出ないことを最優先に最適化するため、重複を厭わず、例外を握り潰し、リファクタを避ける傾向が出ます。

Bunのケースはまさにこの縮図です。Zigのパターンを機械的にRustへ写した結果、Rustのイディオムを採用せず、unsafeで安全性チェックを黙らせながらテストだけを通した——構造として、GitClearが指摘するエラーマスキングの大規模版と言えます。Bun公式自身が「生成物はZigの忠実な移植（faithful port）であって、イディオマティックなRustではない」と認めています。

関連する調査では、73%がAI生成コードの保守を懸念し、82%が自社コードベースに新たな技術的負債が生じるリスクを指摘、GitLabの調査では92%がAIコーディングツールのガバナンス課題を抱えていると回答しています（いずれも二次情報）。

「人間が読まないコードを大量に生成する」という開発スタイルの功罪についてはバイブコーディングとは何かでも扱っています。

自社でAI一括移植をやってよいか：判断チェックリスト

Bunの事例から学ぶべきは「AIならできる」ではなく「Bunが成立した前提条件」です。 その前提を分解すると、実務的な判断基準になります。

確認すべきは次の6項目です。1つでも欠けるなら、大規模なAI一括移植は見送るべきです。

さらに、コスト面の現実も見ておく必要があります。BunのAPIコストは約165,000ドル（約2,500万円規模）でしたが、Willison氏が指摘したとおりAnthropic社員はトークンが実質無料です。同じ規模を外部企業が実行すれば、この金額はそのまま請求されます。「エンジニア1年分より安い」と単純比較する前に、移植後の監査工数（Bunの場合、9,300箇所のsafe化）を加えた総額で見積もるべきです。

導入前にどのAIコーディングツールを選ぶかで検証体制も変わります。ツールごとの特性はAIコーディングツールのおすすめ比較で整理しています。

こんな人におすすめ / おすすめしない人

この論争を追う価値がある人

• AIによる大規模移植・リプレースを検討している技術責任者・CTO：Bunの前提条件チェックリストがそのまま判断材料になります
• AI生成コードの技術的負債を経営層に説明する必要がある人：「13,365個のunsafe」「5件のunsound」「9,300箇所の是正計画」は、抽象論ではない具体的な説明材料です
• Bun / Node.js / Denoのランタイム選定をしている人：Rust版はまだ安定版として出荷されていないという事実は、選定判断に直結します。現行の安定版はZig実装のままです
• AIエージェントの並列運用・敵対的レビュー設計に関心があるエンジニア：Bunのワークフロー設計自体は、規模を落としても再現価値があります

おすすめしない人（この記事の主題ではない人）

• 「ZigとRustのどちらが優れた言語か」の勝敗を知りたいだけの人：本件は言語能力の争いではありません。Kelley本人が「価値観の乖離」と結論づけています
• 「AIが人間のエンジニアを置き換えた証拠」を探している人：Bunの成功は既存の巨大テストスイート・人間が設計したポーティングガイド・段階的な出荷判断に支えられています。人間の関与が減ったのではなく、関与のレイヤーが移動しただけです
• すぐに自社でも同じことをやりたい人：チェックリストの1（適合性テストスイート）を満たしていない組織が大多数です。まず安全網を作るところから始めるべきです

この件から実務者が持ち帰るべき3つの示唆

1. AI大規模移植の律速はモデルではなく「検証手段」：Bunが11日で終えられたのは、Claudeが賢かったからではなく、正しさを機械的に判定する仕組みが既にあったからです。テストのない領域では、AIは速度を出せません（出したように見えるだけです）。
2. 「テストが通る」は「正しい」ではない：Bunは全6プラットフォームでグリーンにしたうえで、後からsafe Rustから到達可能な未定義動作を5件発見しています。テストは「既知の期待」しか検証できません。Miri等の性質検査・ファジング・型による強制を組み合わせない限り、AI生成コードの品質は保証できません。
3. 技術的負債は消えていない。先送りされている：Bunは9,300箇所のunsafe除去という宿題を自ら公表しました。これは誠実な態度ですが、裏を返せば11日で作った成果物に、数ヶ月〜数年分の返済計画が付随しているということです。「1年分の作業を11日で」という見出しは、この返済コストを含んでいません。

よくある質問（FAQ）

Q. 今インストールできるBunは、AIが書いたRust版ですか？
いいえ。2026年7月14日時点で、Bun公式のunsafe監査ページは「今日インストールできるBunは、いまだにオリジナルのZig実装で動いている」と明記しています。Rust版のv1.4.0はbun upgrade --canaryで試せるcanary提供の段階です。

Q. 「6日で書き換えた」という記事を見ましたが、どちらが正しいですか？
公式は11日間（2026年5月3日〜14日）です。「6日」は主要な実装フェーズのみを指した数字と考えられます。同様に「96万行」「100万行」は元コードの量ではなく、PR差分の追加行数（+1,009,272行）を指しています。元のZigコードは535,496行です。

Q. unsafeが13,365個もあるのは危険ではないですか？
Bun公式は「約9,300個はsafeに書き換え可能」「約4,000個はFFI境界などで残さざるを得ない」と説明し、5つの関数がunsound（safe Rustから未定義動作に到達できる実バグ）であると自認しています。8ステップの是正計画も公開済みです。危険性を認識したうえで、安定版として出荷していない状態です。

Q. Zigの方が優れている／Rustの方が優れている、という話ですか？
違います。Kelley氏自身が「争点は言語能力の差ではなく価値観の乖離だった」と結論づけています。彼の批判の中心は「Zigのままでも、LTOの活用やcomptimeの適正化、地道なバグ修正とファジングで同じ改善はできた」というエンジニアリング姿勢への指摘です。

Q. ZigのAI禁止ポリシーがRust移行の原因ですか？
そう指摘するメディアは多いですが、Bun公式ブログはZigのAIポリシーにもフォークにも一切言及していません。公式が挙げる理由はメモリ安全性です。「ZigのAIポリシーとの非互換が実質的な引き金になった」というのはコミュニティ側の解釈であり、確定した事実ではありません。

Q. うちの会社でも同じことができますか？
数十万〜百万規模のアサーションを持つテストスイートが既にあり、タスクが設計変更を伴わない機械的翻訳で、移植後に数ヶ月〜数年の監査予算を確保でき、Miri相当の検証をCIに組み込め、失敗時にロールバックできるなら、検討の余地があります。1つでも欠けるなら見送るべきです。

Q. 使われたモデルは何ですか？
Claude Fable 5のプレリリース版（Mythosクラス）です。APIコスト換算で約165,000ドル分のトークンが消費されました。

まとめ

BunのZig→Rust全面書き換えは、AIエージェントによる大規模移植が技術的に成立しうることを実証した一方で、その成立条件がいかに特殊であるかを同時に示した事例です。

確定している事実は、53万5,496行のZigコードが11日間・最大64並列のClaudeで移植され、全6プラットフォームのテストがグリーンになり、性能が2〜5%、バイナリサイズが約20%改善し、そして13,365個のunsafeブロックと5件の実バグ（unsound）が残り、Rust版はまだ安定版として出荷されていない、ということです。

Andrew Kelleyの批判は感情的な側面を含みますが、その核心である「Zig版のバグを捕捉できなかったテストスイートが、なぜ未レビューの100万行を保証できるのか」という問いは、Bun公式が後から5件のunsoundを発見したことで、部分的に正しさが裏づけられました。

この事例の教訓は「AIは人間のエンジニアを置き換えた」ではありません。「AIの生成速度が上がるほど、検証と監査のコストがボトルネックになる」です。 自社への適用を考えるなら、まずモデル選定ではなく、安全網（テストスイート・UB検証・ロールバック手段）の整備から始めるべきでしょう。

AI生成コードのリスク管理全般はAIコーディングのセキュリティリスク、AIエージェントの基本概念はAIエージェントとは、生成AIの全体像は生成AIとはで解説しています。

出典・参考

• Bun公式ブログ「Rewriting Bun in Rust」: https://bun.com/blog/bun-in-rust
• Bun公式 unsafe監査ページ: https://bun.com/bun-unsafe-audit
• Andrew Kelley「My Thoughts on the Bun Rust Rewrite」: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html
• Zig Code of Conduct: https://ziglang.org/code-of-conduct/
• Simon Willison「Rewriting Bun in Rust」: https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
• GitClear「The Maintainability Gap: 2026 AI Code Quality Research」: https://www.gitclear.com/the_ai_code_quality_maintainability_gap
• Ray Myers（批判的論評）: https://raymyers.org/post/zig-creator-calls-spade-a-spade/
• GIGAZINE（日本語報道）: https://gigazine.net/news/20260712-bun-zig-rust/