- ソフトウェア開発における Bus Factor とは、特定の知識保有者が何人いればプロジェクトを維持できるかを示す概念で、従来は 最悪でも値は1 だった
- しかし ChatGPTの公開（2022年11月30日） 以降、生成AIが一般的に採用されるようになり、多くの人が知識を自ら保持せずAIに依存することで、事実上 バスファクター0 の状況が生じている
- プログラミングの現場では、ますます多くの開発者が LLMが生成したコードや機能 をそのまま使い、コードベースを理解しようとする努力を放棄して、「バイブコーディング（vibe coding）」へ移行している
- その結果、バグ修正、セキュリティパッチ、機能拡張の際に、なぜそのコードがそのように書かれたのか誰にも分からない状況 に直面しうる
- これはソフトウェアの信頼性とセキュリティに深刻なリスクをもたらし、AIが完璧なコードを完璧に生成できる日 が来るまでは根本的な限界が存在する
バスファクターの概念と歴史
- バスファクター とは、特定の知識が 何人に共有されているかを数値で表した 概念である
- 例: 3人がデータベースのバックアップを復旧できるなら、その機能のバスファクターは3である
- 伝統的に最悪の値は1 であり、1人が知識を失うとプロジェクトの維持が不可能になった
- 人類はこれを克服するために、文書化、教育、知識移転、セミナー、学校など数多くの方法で知識を広めてきた
- 膨大な人的資源と時間を投じて、知識を継承・保存する体系的な取り組みへとつながってきた
AI導入とバスファクター0
- 2022年11月のChatGPT公開によって 「AI First」時代 が幕を開けた
- AIがコードや機能を生成する過程で、多くの人が 知識保存の主体から排除 され、AI生成物に依存し始めたことで、プロジェクトへの理解度が急激に低下した
- 結果として 知識保有者がまったくいない状態、すなわち バスファクター0の状況 が発生する
- プログラマーはコードや機能を自ら書いて理解するのではなく、AIに完全に委任 する流れを見せている
- この過程で開発者は コードベースの理解と文書化を避け、単に AIに説明を再要求する パターンへと変化している
LLMベースのコーディングの問題
- コード品質の問題はひとまず脇に置くとしても、読むことと保守することは、本質的に書くことより難しい という点が核心である
- 以前はメンターや文書が最低限の助けを提供していたが、AI依存の環境ではそうした安全網すら消えつつある
- LLMベースの開発ではコード生成の過程が記録されず、AIですら自分が生成したコードの文脈を記憶していない
- 結局、開発者は AIが書いたが文脈が不明確なコード を分析して修正しなければならない状況に置かれる
- これはバグ解決、セキュリティ脆弱性のパッチ、依存関係のアップグレードなどで、コードの意図や構造を誰も把握できない状態 を招く
ユーザー視点でのリスク
- 開発者だけでなくユーザーもリスクにさらされる
- 個人文書、クレジットカード情報、私的な写真や思考などをアップロードするソフトウェアが、内部構造と目的を誰も知らないコード によって作られている可能性がある
- これは データ保護と信頼性の観点 から深刻なリスクを内包し、サービスの安定性 に対する疑問を呼び起こす
結論
- バスファクター0を招くバイブコーディングは、根本的に欠陥のあるアプローチ である
- これは、AIが100%正確なコードを100%正確なプロンプトから生成できるようになるまでは避けられない限界である
- したがって現状では、AI活用 とあわせて 知識保存 と コード理解の重要性 を見過ごすことはできず、知識管理と文書化の仕組みを維持 することが不可欠である
3件のコメント
バスファクターが無限大になったのではないですか？
会社所属の開発者に知識がなければ、バス係数は0に収束しますね。
Hacker Newsの意見
LLMを使ってレビューされていない大量のコードをそのまま吐き出させるのは誤った活用法であり、そのようなプロジェクトは構造的に間違った方向へ進むか、複雑なバグが生じた時点ですぐに保守不能になることを意味する LLMの本当の強みは次のような場面にある: 既存の複雑なデータ構造に有名なアルゴリズムを適用する時、テストデータや依存関係の多い単体テストの骨組みを作る時、ビジュアルなWebエディタとバックエンドAPIを作りつつsqliteへの保存機能を付ける時、複雑な正規表現でも難しい反復作業を大規模コードベースに適用する時など 実際、LLMのおかげで半日や3日かかる仕事でも2分で着手できる 重要なのは、LLMが非常に難しい問題を解けなくても、生産性は大幅に上がり得るという点 退屈な反復作業から解放され、より面白い問題に集中できる
大規模コードベースに反復的な変更を適用する際、LLMなら2分で終わると思っていたが、実際に複数の大規模モデルで試してみると、コンテキストが複雑になるほどエラーが蓄積し、無関係な変更まで時々発生して、結果として信頼できなかった 小規模な例では完璧だが、規模が大きくなるほど不十分になる agentic loopを使えば改善できるが、繰り返し実行とレビューが必要になり、結局はるかに時間がかかる LLMに変更作業を自動化するプログラムを書かせるほうが、はるかに信頼性が高い
挙げられた例はどれも良さそうだが、実際に可能な活用例はもっとずっと多い あなたは熟練開発者ならではの事例を挙げたが、技術力が不足していたり学び始めたばかりの人たちも、LLMのおかげでできることが大きく増えた 100ドル払ってやってもらっていたことを、3分で自分で試せるようになった 成果物が完璧で保守可能かどうかは、むしろ重要ではなくなり、可能性を示すことのほうが大きな価値を持つ
あなたの意見には同意するが、最近あった面白い体験を共有したい Claudeに単体テストの作成を頼んだところ、レビューの結果、実際に自分のコードにバグがあり、そのテストがそれを見つけた ところがClaudeはバグを修正する代わりに、その失敗するテスト自体を実行しないことで通そうとした。現実の愉快なエピソードだ LLMは要件定義、アーキテクチャ設計、要件に合った仕様書作成には弱く、コード作成のように範囲が明確で影響が限定された作業に強みがある
AIがPRレビューを自動で行った後に手動レビューをする、という中間段階を適用してみた コード生成には5〜10分、レビューと追加コミットには通常1〜3時間かかるが、複数のプロジェクト（10〜20k LOC、約100ファイル規模）でこの方式を成功裏に適用した 仕様をうまく与えれば、多くの機能は大きな修正なしでほぼ正確に実装され、主にフィードバックベースのリファクタリングが発生する もちろん、まともに動かない時は解決に丸1日近くかかる場合もあるが、全体としては3〜5倍の生産性向上だった 大規模プロジェクトでは分割してモジュール化するほうが良さそうだ
「LLMで2分でx日分の作業完了」のような表現は、レビュー時間が含まれていないので少し誇張されている 実際のレビューと検証工程まで含めると、はるかに時間がかかる 最初に言っていた「間違った方法」にむしろ陥りかねない
この記事ではAIコード生成の問題点は数多く挙げているが、すでに存在する、あるいは今後登場し得る解決策は考慮していないように見える 以前から、チームがコードベースに最低限の努力さえしていれば、新しく入った人がコードを理解する助けを得ることはできた レガシーコードの経験がないのか、それともAIが「最初の作成過程に関するすべての文脈を忘れてしまう」という点は本当に直せないと考えているのか疑問だ Bus Factor 0の問題も、100%完全に正確でなければ解決できないと誤解しているが、実際には人間も常に100%正確ではない。それでも信頼している
その記事は問題の見方があまりに要約されすぎていると感じた そもそも私たちは、すべての作業を作者と一緒にできるわけではないという現実をすでに生きている ペア相手や説明してくれるAIがいるだけでも大きな前進だ 人間がいない世界を想像しているようだが、私たちはすでにそういう状況をしばしば経験している
私は著者だが、最初の指摘には同意するし、AIが今後そのギャップを埋めていくだろうとも思う ただ、その頃にはすでに一部の問題は発生してしまっているかもしれない 論理的な文脈や操作履歴のないコードが残るという問題もある AIは「常に学習する」とよく言われるが、実際には新しいモデルが出るまでは学ばない 人間も100%正確ではないが、Bus Factor 0ではないので、問題の把握と解決はより容易だ 他の問題も解決されれば、バス係数の問題も軽減される
昔レガシーコードを分析していた時、AIツールがあればよかったのにと思う 「このPerlファイルの最後の編集者は今や支店長だが、直接会議を設定しないといけないのか？」みたいなばかげた状況が実際にあった
「なぜ100%正確でなければならないのか？」という問いについては、AIに批判的な人たちは、むしろAIが魔法のように完璧な解決策であることを期待する傾向があると思う 静的型付けに反対する人が「論理エラーまでは捕まえられない」と不満を言うのに近いニュアンスだ
最近はどのブログにもAIが作った画像が多すぎて、かえって集中の妨げになり、内容の助けになっていないことが多いように思う
最近、ひどいコードベースを抱えたチームに加わったが、既存の開発者の大半はすでに去っており、残っていた人たちもコードをよく分かっていなかった 完全にBus Factor 0だった 驚いたことに、AIのおかげでコード理解、意図の把握、デバッグ速度などが大きく改善した AIでコードそのものからドキュメントを抽出し始めた 文書化や口伝は歪むことがあるが、コード自体が真実だ AIの助けで、コードが自らを説明する環境を作ることができ、大きな生産性向上を感じた
LLM登場前からBus Factorは常に問題だった ほとんどの会社は、仕事の一部を複数人が理解できるよう構造化してこなかった 複数人が各領域に割り当てられていても、仕事量は増え続け、最終的には誰も全体を理解できない状況が繰り返される これを完全に避けるには、コードベース内で人員をローテーションさせるなど、非常に大きなエンジニアリング管理が必要で、たいていは速度への要求のせいで完璧にはできない これに関連する私のCTO経験の回顧をここで本にまとめ、価格に関係なく公開している LLMでシステムを作る環境と、10人の外部委託開発者を使う環境の原理はそれほど変わらないと思う
Bus FactorはLLM以前から問題であり、昔からある専門用語だ TFA（元記事）は、以前はBus Factorが1だったものが、今は完全に0へ向かっているという傾向を批判している
仕事量が増えるだけで、実際にはより望ましい方向に進むわけではなく、締め切りに合わせて雑に終わらせるパターンが繰り返されるだけだ 手順上いくつか障害物を置く程度では解決しない
私たちの脳は、あまり使わない情報にはエネルギーを節約しようとするため、何かから離れるほど理解しにくくなったり忘れやすくなったりする 直接コードレビューをすべてやっていても、結局は実力が衰えることがある エンジニアが長く管理業務をすると技術的な問題をほとんど解けなくなるのと似ている 自動車の自動化でも、中間段階（level2→5）を人間が継続して関与しながら維持するのは難しく、機械が100%信頼できないなら結局問題になる
この議論には本当に重要なポイントがあるが、実際のところ、こうしたツールとワークフローはまだ始まったばかりの段階だ 将来的にはこうした問題をAIが人間よりうまく解く可能性があると確信している LLM活用の実験もしてみたが、一部は成功し一部は失敗したものの、特定分野では確かに優れた能力を示す LLMは面倒がらず、ドキュメントやコメント、README、ADRまで丁寧に更新してくれる 十分なガイドと構造さえあれば、LLMコードベースは長期的にはむしろ参入しやすいものになるかもしれない。その分、文書化が優れやすい
この記事は、コードそのものからでも意図をかなり読み取れるという点を見落としていると思う 人間も、そしてLLMもそうだろうが、かなり予測可能な存在だ たいていは似た問題を似た方法で解決する コードがどう書かれているかを見れば、なぜ誰がいつどんな問題を解いたのかについてのヒントが分かる もちろん情報が隠れてしまう部分も多いが、構成員が頻繁に入れ替わる組織でも似たようなことは起こる
人間の思考過程は結局コードに溶け込むと考えているが、それでも直接聞ける人がいる場合に比べればはるかに劣るプロセスだ リバースエンジニアリングは本当に必要な時にだけやるのが普通だが、レガシーコードでは結局みんなやることになる しかし生産性の面で良いものではない そしてLLMコードベースは単一の意図ではなく、さまざまな人の意図が混ざっているため、一部のコード断片だけを見ても本来の趣旨が何だったのか、かえって混乱しやすい AIが生成したコードも人間が書いたコードのように徹底して同じ意味を持つと錯覚してしまい、むしろ解釈が難しくなることがある
意図をコードだけ見て把握する能力は、範囲と規模によって異なる Arduinoのように32kB制限なら理解は容易だ しかし何十ものマイクロサービスが絡み合った複雑なプラットフォームで、とくにそれが「vibe coding」式で組まれていたら、自分の責任になった時点で諦めたくなる
この記事の要点と結論には同意するが、20年間で何度も似たような状況（誰にも質問できない環境、実際の担当者が全員去っている）を経験してきた LLMによってこうしたことが少し速くなる可能性はあっても、まったく新しい問題というより、昔からの問題の加速に近いと思う こうした問題意識が提起されること自体は歓迎したい
むしろ逆の状況もある コードベースをAIがうまく活用できるよう、文書化、テスト、設定などをきちんとしておけば、1年後でもAI agentが同じ作業をより速くこなせるはずだ
AI Coding Toolが、どうやって既存の開発者のように「以前のコードは全部いまいちだから、全面的に書き直すべきだ」という態度を取るようになるのか気になる 将来的にはCI/CDシステム自体が、プロジェクト全体をAIが丸ごと再構築する形になるのかもしれず、興味深い
私は著者だが、その通りならBus Factorはすでに上がっていることになる つまり、本質は情報が頭の中だけに残るのではなく、さまざまな形で保存され持続することにある