Where Did the Variability Go? From Vibe Coding to Product Lines by Regeneration
本論文は、LLMが派生エンジンとして機能することで、宣言的な仕様に基づき生成時に目的特化型かつデッドコードのないバイナリを生成する、新たなソフトウェアプロダクトラインのアプローチである「再生による可変性（Variability by Regeneration: VbR）」を提案しており、これはAI駆動型の「バイブ・コーディング」の時代において、可変性の管理をコードそのものから仕様へと効果的に移行させるものである。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
論文「Where Did the Variability Go?（変異性はどこへ消えたのか？）」の解説を、平易な言葉と日常的な比喩を用いて説明します。
大きな問題：変更できない「魔法の」コード
想像してみてください。あなたは超一流のシェフ（AI）を雇い、料理を作ってもらうことにしました。あなたは「スパイシーなパスタが食べたい」と伝えます。すると、シェフは即座に、完璧で湯気の立つスパイシーなパスタを作り上げます。
ここで、あなたが「やっぱり、辛さを控えめにして」と心変わりしたとしましょう。従来の料理であれば、シェフにスパイスの量を調整してもらうだけで済みます。しかし、この新しいスタイル（**「バイブ・コーディング（Vibe Coding）」**と呼ばれます）では、シェフは単にスパイスを調整するのではなく、あなたの新しいリクエストに基づいて、最初から全く「新しい」一皿を作り直します。
問題は、最初に作ったスパイシーなパスタが、あなたにとって使い物にならなくなることです。それは「単一目的」の成果物なのです。もし異なるバージョンのソフトウェアが欲しくなったら、その都度、AIに全く新しいファイルを生成させなければなりません。
発見： 「選択肢」はどこへ行ったのか？
研究者たちは、この手法で作られた10種類のソフトウェア・プロジェクトを調査しました。そこで驚くべき発見がありました。「選択肢」が消えていたのです。
昔ながらのソフトウェアは、スイスアーミーナイフのようなものです。刃、ドライバー、コルク抜きがすべて組み込まれており、必要なツールを使うためにスイッチ（設定）を切り替えるだけです。コードには、今使っていないツールも含めて、あらゆる道具が含まれています。
しかし、「バイブ・コーディング」において、AIはスイスアーミーナイフを作ることはしません。AIが作るenのは**「単一目的の道具」**です。
- もし「ナイフ」を求めたら、AIはナイフを作ります。
- もし「ドライバー」を求めたら、AIはドライバーを作ります。
- 「ナイフ」バージョンのコードの中には、ドライバーのパーツは入っていませんし、「ドライバー」バージョンのコードの中にナイフのパーツも入っていません。
研究者たちはこれを**「ニア・ゼロ・バリアビリティ（極めて低い可変性）」**と呼んでいます。ソフトウェアが「何であるか」というすべての決定は、AIがコードを書くその瞬間に下されます。一度コードが書かれると、それは固定されます。もはや切り替えるためのスイッチは残されていないのです。
解決策：「再生による可変性（Variability by Regeneration: VbR）」
AIに巨大で複雑なスイスアーミーナイフを作らせようとする（それはコードを乱雑で理解しにくくさせます）のではなく、著者らは**「再生による可変性（VbR）」**という新しい手法を提案しています。
これは、**「オーダーメイドのスーツ店」と「デパート」**の違いに例えられます。
- 従来の方法（デパート）： 後で「設定」できるように、不要な布地やボタン、使わないこともないポケットをあらかじめ縫い付けたスーツを購入します。これは重くて無駄が多いものです。
- VbRの方法（オーダーメイドのスーツ店）： あなたには**「マスター・ブループリント（設計図／仕様書）」**があります。
- あなたは店に「結婚式用のスーツが必要だ」と伝えます。
- AI（仕立て屋）はその設計図を参照し、その結婚式のためだけに完璧で軽量なスーツを即座に縫い上げます。余分な布地はありません。
- 後であなたは、「ビーチパーティー用のスーツが必要だ」と言います。
- AIは結婚式のスーツを切り刻もうとはしません。再び設計図を確認し、全く新しい、完璧なビーチ用のスーツを縫い上げるのです。
このシステムでは、「可変性（異なるスーツを持つ能力）」は服そのものの中に存在するのではなく、**「ブループリント（設計図）」**の中に存在しています。
実践的な仕組み
論文では、これをwc（ファイル内の単語数をカウントする古典的なコンピュータ・ツール）を用いて実証しています。
- ブループリプト（設計図）： 開発者は、考えられるすべての機能（「行数を数える」「単語数を数える」「文字数を数える」など）をリストアップしたシンプルなファイル（YAMLファイル）を作成します。
- 生成（Generation）： ユーザーが特定のバージョン（例：「行数だけを数えたい」）を求めたとき、AIは設計図を読み取り、そのリクエストを確認して、その目的のためだけに特化した、非常に小さく高速なプログラムを生成します。
- ディスパッチャー（ウェイター）： AIが複数の異なるプログラム（行数用、単語用、すべて用など）を作成した場合、コンピュータはどのプログラムを実行すべきかをどうやって判断するのでしょうか？
- 研究者たちは「ウェイター（ディスパッチャー）」を構築しました。
- あなたがコマンドを入力すると、ウェイターがあなたのコマンドを確認し、メニュー（マニフェスト）をチェックして、リクエストに一致する特定のプログラムを即座に実行します。
- ユーザーであるあなたは、背後にある異なるプログラムを見ることはありません。ただ、挙動が魔法のように変わる一つのツールとして目にすることになります。
なぜこれが重要なのか
著者らは、「バイブ・コーディング」を修正するために、AIにコードの中に「スイッチ」を戻させようとするべきではないと主張しています。それはこの新しいテクノロジーの目的を損なってしまうからです。
代わりに、私たちは**「コードは使い捨てであり、特定の目的のためのものである」**という事実を受け入れるべきです。
- 従来の方法： すべてのオプションを中に隠し持った、一つの大きくて乱雑なコードファイルを保持する。
- 新しい方法（VbR）： 一つのクリーンな**「仕様書（ルール）」**を保持し、ルールが変わるたびに、AIに新鮮で完璧な、「デッドコード（不要なコード）のない」プログラムを生成させる。
まとめ
この論文は、AIコーディングの時代において、一つのプログラムを「微調整」する能力が失われたと主張しています。代わりに、AIはニーズに合わせて新しいプログラムを作成します。著者らは、**「ルール（仕様）」を永続的なマスターとし、「コード」**をルールが変わるたびに再生される、一時的で完璧な製品として扱うことで、この状況を受け入れるべきだと提案しています。これはコードを「修理」する話ではなく、適切な仕事に対して、適切なコードを「再生」する話なのです。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。