ハクソク

世界を動かす技術を、日本語で。

バイブコーディングはバスファクターをゼロにする

2025年8月21日原文(mindflash.org)

概要

  • 本記事は筆者個人の意見であり、雇用主の立場を代表しない主張
  • “Bus factor”という知識継承リスクの概念を解説
  • ChatGPT登場後、知識管理がAI依存になった現状を批判
  • LLM生成コードのリスクと“vibe coding”の問題点を指摘
  • 知識の断絶による“Bus factor 0”の危険性を強調

AI時代の“Bus factor”と知識継承リスク

  • 本記事およびウェブサイト上の意見は 筆者個人の見解、 雇用主の意見 ではない
  • 本記事は 2025年8月のHackerNews で議論、 コメント参照推奨
  • “Bus factor”は チームから主要メンバーが失われたとき、 プロジェクト知識が消失するリスク指標
    • 例： データベースバックアップ復元 を知る人が3人なら Bus factorは3
  • 人類は 知識継承のため、 ドキュメント・教育・引き継ぎ など多様な手段を開発
  • しかし 2022年11月30日、 ChatGPT公開 で状況が一変
    • “AI first”時代の到来、 知識管理の人間離れ が進行

“AI first”時代の知識喪失とvibe coding

  • “AI first”は 人間が二番手 になるどころか、 知識管理から人間が消失
  • プログラミング分野では LLMによるコード生成 が常態化
    • コード理解や知識保持 を避ける風潮、 “vibe coding” の流行
  • LLM生成コードの 品質問題 や vibe codingの欠陥 は別議論
  • 重要なのは、 コードの読み解き は どんなに良いコードでも難解
  • LLM以前は メンターやドキュメント など、 最低限の知識継承 が期待可能
  • 現在は LLMが生成した不完全なコード と、 その説明を同じLLMに頼る状況
    • 初期設計や意図を誰も知らないコード の保守・改修・脆弱性対応の困難
  • ユーザー視点でも 誰も構造や理由を知らないソフトウェア への個人情報投入リスク

“Bus factor 0”時代の危険性と結論

  • “Bus factor 0”を生む vibe coding は 本質的に破綻
  • 唯一の例外は 100%正確なAIコード生成 と 100%正確なプロンプト が実現した場合のみ
  • vibe codingに不安 がある場合は、 プログラミング学習アドバイス記事カテゴリ 参照推奨

Hackerたちの意見

記事ではAI生成コードの潜在的な問題がたくさん挙げられてるけど、解決策が今あるのか、これから出てくるのかを考えることは全くないね。- LLMが登場する前は、チームがちゃんと調査してれば、新しいコードベースに取り組むときはいつでも助けが得られたもんだ。著者はレガシーコードに関わったことがないのかな？- （あ、初期の執筆プロセスについてはすっかり忘れちゃってるみたいだけど）。著者はこれが解決できるとは思ってないのかな？- バスファクターがゼロになる状況を生むから、バイブコーディングは根本的に欠陥がある。つまり、AIが100%正確なコードを100%の確率で生成できて、100%正確なプロンプトが与えられるまではね。なんで100%の正確さが常に必要なんだろう？人間は常に100%正確じゃないのに、私たちは彼らにコードを任せてるのに。

└

うん、この記事はちょっと単純化しすぎだと思った。私は共有所有のコードベースで働いてるけど、時には自分のブランチで作業してるときに元の著者に連絡できないこともある。少なくともパートナーがいろんなことを説明してくれるのはすごく助かる。もしかしたらOPは人間がいない世界を想像してるのかもしれないけど、人間がいないっていうのは、私たちのチームが時々直面する現実の問題だよ。

└

なんで100%の正確さが常に必要なんだろう？前にも言ったけど、もう一度言うね：反AI派の人たち、AIユーザーじゃなくて、AIが魔法の万能薬だと思ってる人たちが多い。なんか、論理エラーを捕まえられないから静的型付けに反対する人たちを思い出す。

└

こんにちは、著者です。コメントありがとう。最初のポイントには同意するよ。AIが将来的にそのギャップを埋めるかもしれないけど、その頃にはかなりのダメージがすでに発生してると思う。LLMの推論の記憶についてだけど、将来的に解決できたとしても、元の生成に関連するアーティファクトを失ったコードがすでにあるんだ。全体的に、AIが「常に学習している」とか言われてるけど、新しいモデルがリリースされるまで実際には何も新しいことを学んでないと思う。> なんで100%の正確さが常に必要なんだろう？人間は常に100%正確じゃないのに、私たちは彼らにコードを任せてるよね。確かにそうだけど、人間がコードを書くことはバスファクターが0になるわけじゃないから、問題が何かを理解して対処するのが簡単だよね。もし上記の他のギャップが解決されれば、これも部分的に解消されると思う。

└

過去にレガシーコードベースを掘り下げているときに、AIツールがあればよかったな。「そのperlファイルの著者に聞けばいいじゃん」。確かに、最後に編集されたのは97年で、著者は今や地域マネージャーだし、会議を予約すればいいのかな…？

残念ながら、企業の仕組みはバスファクターが0に収束してきてる。私は今まで、重要なサブシステムの知識を持っているのが自分だけのチームに何度も所属してきたけど、他の人に教えようとすると無駄だった。主に「コスト削減策」で解雇されるから。高プロファイルのオペレーションを扱ってるときに、もうやめたくなるくらいのこともあった。それが続けば、システム全体が長期間動かなくなるところだった。正直、多くのエンジニアと話してると、たくさんの企業がこんな風に運営してるみたいだ。AIが組織の知識の喪失を加速させて、システムの急速な劣化を引き起こすことになると思ってる。

└

私の予想？AI企業は、開発者やそのマネージャーを引きつけるために無料プランと月額20ドルプランを維持すると思う。月額200ドルのプランも用意して、より大きなコンテキストウィンドウで、より大きなコードベースで効果的に作業できるようにするんじゃないかな。でも、大規模なプロジェクトを持つ企業は、いずれもっと大きなコンテキストウィンドウが必要になるから、それが突然年間20万ドル/開発者のサブスクリプションになると思う。「組織的知識」とコンテキストウィンドウの間には、かなりの相関関係があると思う。

この記事はコードだけからどれだけ意図を読み取れるかを過小評価してると思う。コメントがなくてもね。人間（そしてLLMも、人間の生産物の統計的合成だと思うけど）はかなり予測可能だよ。同じ問題に対して同じ解決策を取る傾向があるから、どうやって解決されたかは、なぜ、誰が、いつ解決したかを教えてくれる。確かに、今は多くの知識が隠れてしまってるけど、高い従業員の離職率がある組織でも同じことが言えるよね。

└

この記事はコードだけからどれだけ意図を読み取れるかを過小評価してると思う。それはスケールに関係してるね。私はArduinoのコードを読むのにほとんど困ったことがない。でも、一般的なArduinoの限界は32kBの（コンパイルされた）コードだから、数週間から数ヶ月の努力が必要だったり、場合によっては不可能だったりする。数カ国語で書かれた100以上の相互依存するマイクロサービスがあるプラットフォームを理解するのは、私にはかなり大変だ。もしかしたら、そのすべてに非常に熟練した経験豊富なアーキテクトがいて、包括的なAPIスタイルやドキュメントを要求していたのかもしれない。でも、もしそれが全部バイブコーディングで、私に責任を押し付けられたら？私はやめるよ。

└

記事は、コードだけからどれだけ意図を読み取れるかを過小評価してると思う。コメントがなくてもね。確かに、人間の思考プロセスは、どのように物事を進めるかのいくつかの可能性に埋め込まれるけど、それでもプロセスだし、知識のある人がいるのとは比べ物にならないくらい劣ってる。リバースエンジニアリングは、これまで必要な時にしか行われてこなかった。（まあ、特にレガシーコードベースではみんなやってるけど、生産性には全然良くない。） > 人間（そしてLLMも、統計的に人間の成果を合成してるから、強くそう思う）って結構予測可能だよね。括弧内には同意できないな。それがLLMコードの一番の特徴だと思う：コードには確かに意図が埋め込まれてるけど、それは色んな意図がごちゃ混ぜになってる。小さなスニペットからはあまり推測できないよ。そのスニペットの意図は、全く別の元のコードベースに関連してた可能性が高いから。それがLLMを育てるための堆肥の山になってるんだ。LLMのコードベースを理解するのは実際には難しい。意図が読者を混乱させるから。テキストと同じように、生成されたものが人間が書いたものと同じ意味だと暗黙のうちに思い込んじゃうけど、そうじゃないんだよね。

LLMを使ってレビューされていない大量のコードを生成してるなら、それは間違ってるし、プロジェクトは一度でもアーキテクチャ的に間違った道に進んだら、維持不可能になる運命だよ。LLMが得意なのは、例えばこんな状況：* これを適用したい - バン、半日分の作業が2分で完了。* テストデータとユニットテストの骨組みを設定したい - バン、半日分の作業が2分で完了（注意：LLMをスタート地点として使うのはいいけど、実際のテストケースを生成するのは慎重にレビューしないとダメだよ。すごくバカなAI生成のユニットテストを見たことがあるから）。* SQLite DBに保存して、別のバックエンドAPIを持つビジュアルウェブエディタが欲しい - バン、3日分の作業が2分で完了。* 複雑すぎて賢い正規表現ではできない大規模なコードベースに対して、繰り返しの変更を適用したい - バン、以前は絶対にやらなかった作業が2分で完了。難しい問題を解決する必要はなくて、LLMを使って生産性を大幅に向上させることができる。単にヤクを剃るだけでいいんだ。時間の節約にならなくても、無限の雑務に疲れ果てることなく、興味のある問題に集中できるようになるよ。

└

中間的なアプローチもあって、AIにPRレビューを生成させて、それを手動でレビューするっていう方法もあるよね。だから、君が出した2分のコード（実際にはCCを使うと5〜10分くらいかかるけど）をレビューするのにさらに1時間か3時間かかるし、マージする前に5〜10回のコミットが必要になるかもしれない。私は10,000〜20,000行、約100ファイルのプロジェクトでこれを成功させたことがあるけど、完全にLLM生成で、私のフィードバックもたくさん入れてて、うまくいってるよ。実装する機能の4/5は、私が提供した仕様にかなり近い形で実現できてるし、作業の大部分はリファクタリングだね。でも、うまくいかない時は、一日がかりになることもある。全体的には、たぶん3〜5倍のスピードアップにはなってると思う。ただ、もっと大きなプロジェクトでやるのはちょっと自信がないかな…そうなると、モジュールに分ける方が魅力的に見えてくる。

Hacker Newsで議論の続きを見る