この記事の面白いところは、筆者が Bunを褒めているのに、最後にはかなり警戒していることです。
普通、こういう話は「機能が微妙だからやめる」になりがちですが、今回は違います。問題はBunの技術力ではなく、Bunを取り巻く組織やプロダクト運営の空気にある、という話なんですね。
Bunは、ざっくり言うと JavaScript や TypeScript を動かすための高速な実行環境です。
Node.js の代わりになることを目指していて、実際かなり速い。さらに、パッケージ管理、bundling、testing までまとめて面倒を見てくれるので、ツールがバラバラになりがちな開発現場ではとても魅力的です。
筆者が「Bunはgreat software」と言っているのは、決してお世辞ではありません。
それでも心配なのは、2025年12月に Anthropic が Bun を買収したことです。
買収の発表では、Bun はオープンソースのままで MIT license も維持され、チームもそのまま、ロードマップも高速なJavaScript tooling と Node.js compatibility を重視すると説明されました。ここまではかなり安心材料です。
さらに Anthropic は、Claude Code が Bun executable として大量のユーザーに配布されているので、Bun が壊れたら Claude Code も壊れる、としていました。
つまり「Anthropic には Bun を大事にする直接の動機がある」という理屈です。
この理屈自体は、かなり筋が通っています。私も当時なら「たしかに、それなら悪くない話だな」と思ったはずです。
でも、問題はその後に起きました。
元記事は、Anthropic のモデル自体――たとえば Claude Opus など――は依然として高く評価しています。
ここでいう「モデル」は、AI の頭脳そのもののことです。文章を書いたり、コードを書いたり、推論したりする中核部分ですね。
筆者が不満を持っているのは、AIモデルの性能ではなく、その上に乗る製品体験です。
つまり、見た目や機能、課金、制限、サポート、運用ルールといった“使い心地の部分”です。
これ、かなり重要です。
なぜなら、実際にユーザーが毎日触るのはモデルの中身ではなく、プロダクトとしてのClaude Codeだからです。
どんなに賢いAIでも、使いづらかったら意味がない。これは本当にその通りだと思います。
筆者によると、1年前の Claude Code はかなり衝撃的だったそうです。
プロジェクトを読んで、必要な箇所だけ編集して、コマンドを実行して、失敗したら修正して、また進む。
これができると、単なるautocomplete（入力補助）ではなく、agent（自律的に動くAI）としての未来を感じられた、と。
この感覚はわかります。
開発者って、ただコードを打ちたいわけじゃなくて、面倒な作業を減らしたいんですよね。
その意味で Claude Code は「未来っぽさ」が強かった。筆者が高く評価していたのも納得です。
しかも当時は Anthropic のモデルも強く、Claude Code はかなり無敵感があった、と述べています。
この時点では、Bun が Anthropic の傘下に入るのも自然に見えたわけです。
「未来の開発ツールを作る会社が、土台になる runtime も抱える」――たしかに悪くない絵です。
ところが、2026年に入ると状況が変わります。
筆者は、Claude Code に久々に戻ってきて、あまりの劣化ぶりに驚いたと書いています。
この記事で挙げられている不満は、ざっくり言うとこんな感じです。
ここでいう harness は、ざっくり言えば **AIを実行するための“外側の仕組み”**です。
CLI ツールやラッパーのようなもの、と考えるとわかりやすいでしょう。
Anthropic はこの件について engineering postmortem（障害や失敗の振り返りレポート）を出し、
など、製品レイヤーの問題を認めたそうです。
これは誠実ではあります。少なくとも「何も起きていないふり」をするよりはずっといい。
ただ、筆者が言うように、Anthropic が自分たちの責任を認めたのは、これがほぼ初めてだったのではという空気感もあったようです。
このへん、かなり嫌なリアルさがあります。
ソフトウェアって、技術だけでなく「運用の丁寧さ」で評価が決まるんですよね。
そこが崩れると、ユーザーは一気に不信感を持つ。私もこれはかなり同意です。
筆者が特に問題視しているのが、いわゆる OpenClaw の件です。
報道によると Anthropic は Claude Code のサブスク利用者に対し、OpenClaw や他の third-party harness を使うなら追加料金が必要だと伝えたそうです。
それだけでも「えっ」となるのですが、さらに奇妙なのが、
git history に OpenClaw の名前があるだけで、Claude Code がリクエストを拒否したり、追加課金のような挙動を見せたりしたという報告です。
git history というのは、過去にどんな変更が入ったかの履歴です。
つまり、今そのコードを使っていなくても、昔ちょっと名前が残っていたせいで挙動が変わる可能性がある、という話です。
もし本当なら、かなり気持ち悪い。いや、かなりどころではないですね。かなり不自然です。
筆者はこれを、開発者自身が実際のコードレベルの体験をちゃんと dogfood（自社製品を自分たちで使って確かめること）していない兆候ではないかと見ています。
これは推測ですが、外から見る限りそう見えてしまうのも無理はないと思います。
ここがこの記事の核心です。
筆者は「Anthropic が嫌い」と言っているわけではない。
でも、Claude Code の動きが“だんだん使いにくくなる方向”に進んでいることが、Bun にも波及するんじゃないかと不安になっているんです。
この不安、かなり理解できます。
ある製品群で「制限を増やす」「説明が雑」「思わぬ条件で挙動が変わる」といったことが起きると、同じ会社の別製品にも疑いの目が向きます。
人間ってそういうものです。私もたぶん同じことを考えると思います。
筆者は明確に言っています。
Bunは悪くない。Bun は excellent だ。
問題は Bun の技術ではなく、Anthropic に深く統合されることで、そのポリシーや運営思想まで一緒に取り込まれてしまうかもしれないことだ、と。
これ、すごく本質的です。
ソフトウェアはコードだけでできているわけではなく、それをどう売るか、どう制限するか、どう改善するかという会社の姿勢に左右されます。
つまり筆者が怖がっているのは、
「Bun の性能が落ちること」ではなく、
“Claude Code で見えてきた嫌な変化”が Bun にも起きることなんですね。
たとえば、
こういうのは、開発者にとって本当にストレスです。
性能が速いだけでは足りない。信頼できることが大事なんです。
元記事の筆者は、しばらく pnpm を使うと述べています。
pnpm は、Node.js / JavaScript の package manager です。
package manager というのは、外部ライブラリを入れたり更新したりするための道具ですね。
「この依存関係をどう管理するか」を担当する、開発の地味だけど重要な存在です。
Bun は package manager 以外にも、
など、かなり多機能です。
一方で pnpm はそこまで全部入りではなく、あくまで package manager に専念しています。
筆者は、日常的に一番よく使うのは Bun の中でも package management の部分だと言っています。
そしてその用途なら、速度が速く、monorepo に強く、ディスク使用量も抑えやすい pnpm でも十分だ、と。
ここは現実的です。
「全部入りツールは魅力的だけど、今の不安を考えると、まずは安定している道具に寄せたい」という判断ですね。
私はこの慎重さ、かなり好きです。派手さはないけど、現場では強い判断だと思います。
重要なのは、筆者がBunの全面否定をしていないことです。
むしろ逆で、かなり明確に「自分はただのネット上の一人の意見にすぎない」と断っています。
という、かなりバランスの取れた姿勢です。
こういう言い方は好感が持てます。極端な煽りではなく、実際の運用コストをちゃんと考えているからです。
この記事は、単なる「Bun の性能レビュー」ではありません。
本質は、すばらしい技術でも、それを運営する会社のふるまい次第で安心して使えなくなるという話です。
筆者は Bun に失望したわけではない。
ただ、Anthropic と Claude Code を見ていると、
「この会社はプロダクトを長期的に丁寧に育てるのだろうか？」
という疑問が出てきてしまう。
その疑問が、Bun にまで影を落としている――そういう構図です。
個人的には、これはかなり刺さる話でした。
ソフトウェア開発では、性能が速いこと以上に、**“この道具を来年も安心して使えるか”**が重要だからです。
Bun 自体は魅力的です。でも、信頼は一度揺らぐと、性能だけでは取り戻しにくい。
そこが今回の記事のいちばん重いポイントだと思います。
