深夜テンションで一気に書き上げたので誤字があるかも…見つけたら都度修正します。
最近仕事でも個人でもvibe codingで終わっているコードを良く目にするのでその気持ちとかを書いていきます。 なおこの記事では個人的な感想が主軸で具体的な解決方について書かないのであしからず。もしなんとかできたらその時はまた記事を書きます。
vibe codingで書かれたコードは速く死ぬ
ソフトウェア工学の観点から「死んだソフロウェア」とは「プログラムが問題を解決しようと書かれた際に構築された理論が失われること」と指し、僕は以下のツイートにてその概念を知りました。
Peter Naur が言うところの「死んだ」ソフトウェアが出来上がってしまった https://t.co/YSkcY5Qwww
— Takuto Wada (@t_wada) May 9, 2026
このツイートにてPeter Naurが指摘している内容は論文「Programming as Theory Building」に書かれていて、Naurは論文のなかでプログラミングと問題解決の関係性について、プログラミングの本質はコードではなく問題に対してどのような理由でどの手段を用いて問題を解決したのかが重要であると主張しています。
最近ADRなどが注目されているのもこのwhyに該当する箇所をコードとは別の仕組みで残そうとする動きのひとつだったりしますね。
さて、この論文のなかで象徴的な一文として以下があります。
A dead program may continue to be used for execution in a computer and to produce useful results. The actual state of death becomes visible when demands for modifications of the program cannot be intelligently answered. Revival of a program is the rebuilding of its theory by a new programmer team.
Nani翻訳で翻訳したものも合わせて掲載します。
「死んだ」プログラムであっても、コンピュータ上で実行され続け、役に立つ結果を生み出すことはあります。そのプログラムが実際に死んでいると判明するのは、プログラムの修正要求に対して適切な対応ができなくなったときです。プログラムを「復活させる」とは、新たなプログラマーチームがその理論をゼロから構築し直すことを意味します。
このソフロウェアの生死を左右するのはコードが持っている問題解決に対するコンテキストが残っているか、という所に存在しています。 つまり、vibe codingで書かれたコードは従来なら書き手が持っているであろう問題解決に対するコンテキストが欠落しているため、入来より速くコードが死を迎えてしまうという訳です。
事例
事例があった方が良いかなと思って仕事での(言えそうな範囲でボカした)内容と、趣味での事例を書いてみた。 仕事の方が普通に辛いという現実が目に見えてマズいですね…
仕事での事例
最近仕事ではリプレース案件をやっていて、そこそこドメインが複雑で年季の入ったソフトウェアをClaude Codeで別の言語へリプレースするというものをやっている。 まあ当然移行前システムを開発した企業とは直接連絡は取れないし、仕様書なんて存在せず、ドメイン固有の謎の用語と仕様がてんこ盛りで、ドキュメントがExcelで書かれてたりしている。
こうなると当然元のソフトウェアのコンテキストを100%受け取ることなんでできっこないし、なんなら客先も完全に把握している訳ではないため、結構瀕死、なんならICU直行コースみたいな状態な訳です。
こういうソフトウェアのリプレースを行う前には、まぁとりあえずスモークテストを通すなりして正常系の仕様を把握したのち、内部のソースコードを調査してデータ構造なりを抽出、それを客先から聞き出した実際の使用例を突き合わせてコンテキストを把握したりするのが定石だと思うのですが、まぁそんなことはなく…
参画した数日後にClaude Codeが書き散らした大量のMarkdownを押し付けられ、重要なコンテキストはドキュメント化されていないため口頭で聞き出し、コンテキストは共有されず、都度Claude Codeにコードを調べさせかすかな痕跡をかき集めてコンテキストを推測するしかないのが現状。
こうなるともうほぼコンテキストは旧システムのコンテキストは残っておらず、言わばテセウスの船みたいな状態となっている訳です。 なんならこれ絶対リリース後に不具合連発するよなと思いつつ、ペーペーにはもうどうすることも出来ない状態まで来ているため、氷山に激突する寸前の船に乗っているみたいな気分で日々を過ごしています。
書いてて不安になってきた… これ本当に大丈夫なんすかね…？
あ、コード品質に関しては当然壊滅的で、レビュー時に変更箇所以外のコードは読まないのと、lintを通さない運用(lintのインストールに申請通さなきゃなので…)をしているので全然PEP8に違反しているし、多分他のPEPにも違反している漢気のあるコードベースとなっている。すごいですね。
趣味での事例
個人での事例はまだ希望があって、なんと、自身がドメインエキスパートになれる領域の問題となっている。
状況としてはドキュメントが存在はしているものの、Claude Codeによって生成されたものが大半という状況になっていて、ドメイン自体はどこまで複雑でもないかなという印象。
自身がドメインエキスパートになれる状況なので、実装にあたってのコンテキストが欠けていてもある程度実装された内容に対して理由を推測できるし、かなり有利な状況ではある。
ただ、コードの変更がかなり激しく、数ヶ月でアーキテクチャがごっそり入れ変わっていたりするので、そのあたりの追従に関してはそれなりにコストがかかるという状況。 とはいえLLMがある今リーディングの負担は大きく減ってはいるし全然ペイできるかな〜という温度感。
じゃあどうすれば良いのか
完全な対処方法は分からん…が、ある程度は対処方法があると思っていて、うち一つがテストを書くだったり(テストがないコードはレガシーコードだ！)先述したADRを残すことだったりすると思っている。
従来のソフトウェア開発においてはドキュメントをいかに残すかが重要とされていたし、実際それが重要だったけれど今となってはLLMがコードを生成するスピードに太刀打ちできないので問題を解決できないと思う。
実際仕事ではドキュメントが腐敗するスピードがあまりに速く、逆にLLMが誤った判断をする要因となったりして逆に有害となっているので、従来のドキュメントに相当する内容はドキュメンテーションコメントに記載して、本当に重要な内容はREADMEに記載するなど形態を大きく変える必要があると思う。
あとドキュメントの腐敗に対してもテストは有効な対策になると思っていて、テスト自体が実行できる仕様書ともとれるため、実際にコードを確認しなくともテストケースのみでコードの挙動を推測できる。 実際ドキュメントがないCommon LispのコードとかをroveのテストコードとREPL結果を頼りに推測してたので、コードリーディングの観点からも結構使えるなという印象を持っている。
対処方について、仕事の方は社内でコード品質に関する問題提起が一切されず(マジかよ)どうしようもないな〜って感じで、LLMが生成しコードの改善に関してはそもそもコード品質に関して組織内で問題意識を共有するする必要があるという大前提の重要性を思い知らされたりしている。なのでなんかもうどうしようもないな、という感じでこれ以上は特に言うことはないです。
一方趣味の方はコード品質に対して問題提起は(俺がやると啖呵切ったため)出来ていて、実際に動けているので改善に対して希望があるという感じ。
ドキュメントの鮮度維持に関してはなんらかの方法(それこそskillを仕込むなど)で意思決定をするたびに、リポジトリ内でADRを貯めていくようにしたりすれば解決できそうではあるなと。 実際にADRを使ったことがまだないので、実際どの程度効果があるのかも検証したいところ。
現在はテストを突っ込む作業とかをしていて、その関連でカバレッジを計測したりしてテストのカバー範囲に穴がないかだとか、そもそもテストケースが有効か確認したりだとかしている。 vibe codingで書かれたコードに対してはPBTも有用だと思うので、そのあたりも検証がてらぶっこみぶっこみしていきたい。
実際vibe codingでのテストの重要性については結構取り上げられていると思うのだけど、ユニットテストの範疇を出たものを見ない(VRTとかはあったかも？)気がしていて、そのあたりの実践的な内容についても知りたいかもしれない…まぁ来月それについて話す予定なので記事が出てきたら逆に困ってしまうかもしれないですが…
という訳でつらつらと書いてきましたが、、LLMがコードを書くようになっても現状コードの品質を保ち、コードを死なせないようにする方法とかを書いてきた。 とは言え結論としては、従来からやってきているようなテストを書くことの重要性の再確認、強いていうならADRの重要性について確認できたことが新規性のある話かもしれない。ADR自体は数十年前から存在しているものではあるので、それ自体の新規性はないけども。
冒頭にも書いたように進捗が出たら今度は「なんとかした」という内容で解決編の記事をまた書きます。
参考文献と謝辞
Programming as Theory Building
論文の本体が1985年と古く、原本がスキャンしたものしかないため、有志がOCRでスキャンしたものもあわせて添付しておきます。 この論文に辿り着けたのはt-wadaさんの該当のツイートがきっかけなので、あわせて感謝を述べさせていただきます。
Gist(Markdown)版: https://gist.github.com/masci/5ee3be331b05c9014cc5dea87f9c026b?utm_source=chatgpt.com