SPECMINE: A Large-Scale Corpus of Spec-Driven Development Artifacts

ソフトウェア制作の世界には、プログラムの「構想」と「プログラムそのもの」との間に、長らく存在する根本的な緊張関係がありました。伝統的に、開発者は頭の中にビジョンを抱いたり、ナプキンにメモを書き留めたりした後、そのビジョンを数ヶ月かけてコードの行へと翻訳してきました。コードこそが主要な成果物であり、書かれ、レビューされ、保守される対象でした。しかし最近、この順序が逆転する新しい手法が登場しました。一行のコードも書かれる前に、開発者は多くの場合、人工知能ツールの助けを借りて、構築すべきものの詳細かつ構造化された記述を作成します。この記述は自然言語で書かれ、設計図として機能します。そしてAIエージェントがこの設計図を読み取り、実際のソフトウェアを生成するのです。この変化は、プロジェクトにおいて最も重要な文書が、もはやコードではなく、仕様書そのものであることを意味しています。これらの仕様書がいかに書かれ、どのように変化し、そして最終的にいかにして動くソフトウェアへと変わっていくのかを理解することは、テクノロジーがいかに作られるかを研究する者にとって、今や極めて重要な問いとなっています。

これまで、この新しい風景を明確に描き出せる地図を持つ者はいませんでした。開発者がこれらの設計図を書くのを助けるツールは数十種類も登場していますが、それらが生成する実際の文書が大規模に研究されたことは一度もありませんでした。カーネギーメロン大学のシャイアム・アガラワル氏とボグダン・ヴァシレスク氏は、SPECMINEを作成することで、その状況を変えました。これは、これらの仕様書とその生成されたコードの膨大なコレクションです。彼らは、2025年から2026年にかけてこの慣習が誕生した瞬間を捉えるべく、GitHub上の公開プロジェクトから、およそ50万件の仕様ファイルを集めました。このコレクションには、仕様書のテキストだけでなく、それらが属するプロジェクトの全履歴、作成者、そして仕様書が更新された際にコードに対して行われた具体的な変更までもが含まれています。これは、AI時代において、書かれた記述がいかにして機能するプログラムへと変貌を遂げるのかを、詳細に観察できる初めての機会となります。

研究者たちは、全体像を確実に捉えるために、主に2つの方法でこのコレクションを構築しました。第一に、多くの新しいツールで標準的な名称として使われている「spec.md」または「specs.md」という名前のファイルを探しました。この検索だけで、73,000以上の異なるリポジトリから470,000件を超えるファイルを回収しました。次に、要件、設計、タスクを別々のファイルで扱うAWS Kiroという特定のツールに対する個別の検索を追加しました。これにより、さらに98,000件のファイルが加わりました。これらの検索を組み合わせることで、現在使用されているツールの大部分をカバーする広範な調査を実現しました。このコレクション内のすべてのファイルには、プロジェクトのスター数、使用されているプログラミング言語、および仕様を生成した特定のツールなど、そのプロジェクトに関する情報が付与されています。

書かれた計画がいかにして実際にコードへとつながるのかを理解するために、研究者たちはさらに一歩踏み込みました。彼らは、人気のあるプロジェクトの中から厳選された小さなグループに焦点を当て、仕様書ファイルが関与するコード変更のリクエストをすべて追跡しました。その結果、開発者またはAIエージェントが設計図とコードを同時に更新した、約6,000件のプルリクエスト（変更要求）を発見しました。これにより、アイデアと実装の間の直接的な繋がりを確認することができました。多くの場合、仕様書とコードは単一の更新の中で同時に変更されており、設計図がリアルタイムで作業を駆動していることが裏付けられました。しかし、研究者たちはこれが唯一の方法ではないことも指摘しています。時には計画が先に書かれ、コードが後から来ることもあれば、コードが先に書かれ、後から計画が追加されることもあります。データによれば、同時変更は一般的ではあるものの、その関係性は複雑であり、プロジェクトごとに異なることが示されています。

単にファイルを数えるだけでなく、チームはこれらの文書の構造を分析し、それらが実際にどのような姿をしているかを確認しました。その結果、仕様書は単なるランダムなメモではなく、人間と機械の両方にとって読みやすいように、明確な見出し、リスト、あるいは構造化された形式を使用するなど、特定のパターンに従っていることが多いことが分かりました。また、研究者たちはこれらの文書内の参照を追跡するシステムを構築しました。もし仕様書が特定のファイルや実行すべきタスクに言及している場合、システムはそのファイルが実際にプロジェクト内に存在するか、あるいはそのタスクが完了されたかどうかをチェックします。これにより、一部のプロジェクトにおける重大なギャップが明らかになりました。仕様書の中で言及されているものの、コードの中に一度も現れなかったファイルやタスクが数千件存在していたのです。これは、仕様書を書くという慣習は拡大しているものの、それらの仕様が完全に実現されていることを保証するという規律は、まだ進化の過程にあることを示唆しています。

このコレクションは、誰が執筆を行っているのかという窓口も提供します。データにはすべての変更履歴が含まれているため、研究者は、仕様書が人間によって書かれたのか、AIによって生成されたのか、あるいはその混合であるのかを見分けることができます。また、これらの文書がどの程度の頻度で更新され、放棄されるまでにどのくらいの期間アクティブであり続けるのかを追跡することも可能です。このレベルの詳細さにより、「優れた仕様書は最終的なコードのエラーを減らすのか」や「特定の種類のプロジェクトの方がこの新しい働き方を採用しやすいのか」といった、以前は不可能であった問いに答えることが可能になります。データは、この慣習が急速に広がっていることを示しており、これらのファイルの大部分がここ2年間で出現していることは、ソフトウェア開発における明確な新しい時代の到来を告げています。

研究者たちは、アイデアとコードの繋がりを誰もが探索できるように整理した上で、このデータセット全体を公開しました。彼らは、貢献者やプロジェクトの身元を隠すことなく、仕様書の生テキスト、プロジェクトの履歴、および両者のリンクを提供しています。これは、すべてが公開ソースから来ているためです。この透明性により、他の科学者たちは、知見を検証し、新たな問いを立て、この慣習が時間の経過とともにどのように変化するかを研究することができます。この研究は、この新しい手法が完璧であるとか、ソフトウェア開発のあらゆる問題を解決したと主張するものではありません。そうではなく、これまで未踏の領域であった広大な地図に対し、最初の確かな証拠となる基盤を提供したものです。それは、仕様書を書くためのツールは存在し、作業量も増大しているものの、人間と機械が協力して言葉をソフトウェアへと変えていく方法は、依然として一つひとつのプロジェクトを通じて模索されている最中であることを示しています。