Measuring What a Specification Determines: A Formal Semantic-Block Model and an Execution-Judged Benchmark

現代のソフトウェアの世界では、人工知能を用いてコンピュータプログラムの作成を自動化しようとする企業が増えています。エンジニアのチームを雇ってすべてのコードを一から書き直させる代わりに、ソフトウェアが何をすべきかを詳細に記述した「仕様書」と呼ばれる文書を提供し、AIにそれを構築させます。この「仕様駆動開発」と呼ばれるアプローチは、書かれた計画を機械への主要な指示書として扱うものです。もし計画が十分に明確であれば、AIは毎回完璧なソフトウェアを生み出すことができるはずだという期待があります。しかし、決定的な疑問が残っています。優れた計画は実際にAIを賢くするのか、それともAIシステムはすでにトレーニングに基づいて答えを知っているのか、という点です。もしAIが、過去に似たような計画を見たことがあるという理由だけでその計画に同意しているのだとしたら、その計画自体は実質的な役割を果たしていないことになります。この不確実性は、ある仕様書が真に高品質なものなのか、それとも単に機械がもともと行おうとしていたことに合致しているだけの文書なのかを判断することを困難にしています。

研究者の一団は、特定の複雑なタスクをテストすることで、この測定問題を解決しようと試みました。それは、大規模なデータベースをあるシステムから別のシステムへと移行するという作業です。彼らは、データの保存や処理に関する数千のルールを翻訳する必要がある、OracleデータベースからPostgreSQLデータベースへのデータ移行のための、形式的で構造化された仕様書を作成しました。この仕様書が実際に役立つかどうかをテストするために、彼らは単にAIにコードを書かせ、それが正しく見えるかを確認しただけではありません。代わりに、彼らは厳格な実験を構築しました。そこでは、同じグループのAIシステムが、詳細な仕様書がある場合とない場合の計2回、移行作業を行うことになりました。研究者たちは、ライブのOracleデータベースと新しいPostgreSQLシステムを厳格な判定役として使用しました。彼らは、生成されたコードを元のデータに対して実行し、結果が同一であるかどうかを確認することで、ソフトウェアの実際の挙動を唯一の真の成功指標として扱いました。

この研究には、同じ75個の特定の移行タスクに取り組む、独立した実装者として機能する3つの異なるAIシステムが関わっていました。研究者が結果を比較したところ、ソフトウェアができることと、AIシステム同士がどの程度一致するかとの間に、明確な乖離があることが分かりました。仕様書は、ソフトウェアがクラッシュせずに実行できる能力を劇的に向上させました。仕様書がない場合、生成されたコードが新しいデータベースに正常にロードできた割合は72パーセントでした。完全な仕様書を用いた場合、その数値は97.3パーセントへと跳ね上がりました。計画は、AIが致命的なエラーを回避し、実際に動作するコードを生成するためのガイドとして機能したのです。

しかし、研究者が「仕様書によってAIシステム間の合意が形成されるかどうか」に目を向けたとき、物語は異なる展開を見せました。完璧な計画があれば、すべてのAIシステムが全く同じ決定を下すよう強制され、統一されたソースが生まれるという期待がありました。しかし、データはそうではないことを示しました。仕様書がなくても、AIシステムはすでに83パーセントの確率で互いに一致しており、これはおそらく、トレーニング中に標準的な業界慣行を学習していたためと考えられます。仕様書を追加しても、この一致率はほとんど動かず、わずか83.8パーセントへの上昇にとどまりました。計画は、AIが既に行っていた決定を変えることはありませんでした。それは単に、AIがそれらの決定を壊れることなく実行するのを助けただけだったのです。

また、研究者たちは、情報の「量」よりも「提示方法」が重要であることを発見しました。ある実験において、彼らは単一のルールを取り上げ、ドキュメント内の異なる場所に配置しました。そのルールがセクション末尾の段落の中に埋もれていた場合、AIがそれに従う割合はわずか23パーセントでした。同じルールをセクション上部の構造化された表に配置すると、遵守率は42パーセントに上昇しました。驚くべきことに、ルールを両方の場所に重複して記載すると、遵守率は34パーセントに低下しました。これは、冗長性が指示を強化するのではなく、システムを混乱させる可能性があることを示唆しています。この発見は、ドキュメントの構造がテキストの量よりも影響力を持つことを示しています。

おそらく最も重要な発見は、仕様書が時には状況を悪化させることもあるという点です。ある特定のケースでは、仕様書のルールがAIに対して特定のデータコンテナを使用するように指示していました。AIはこのルールを完璧に遵守しましたが、その結果、無効で動作しないコードが生成されました。仕様書がなければ、AIはその特定の指示を無視して、独自の動作する手法を使用していたはずでした。これは、ルールに従うことが正しい結果を保証するわけではなく、仕様書が古いエラーを修正する一方で、新たなエラーを導入することもあるという事実を証明しました。また、研究ではAIシステムの整合性には自然な限界があることも判明しました。研究者が同じテストを複数回実行したところ、AIがテキストを生成する際のランダムな性質により、結果には約14パーセントポイントの変動が見られました。この変動性は、小さな改善が真の進歩であると信頼することを困難にしました。

最終的に、本研究は、仕様書はソフトウェアを実行可能にし、人間がどこに指示が欠落しているかを見つけるための強力なツールではあるものの、異なるAIシステムに同じように考えさせる魔法の杖ではない、と結論付けています。仕様書は、壊れたプログラムの数をほぼ4分の1減少させることに成功し、コードを実行可能にするという価値を証明しました。しかし、異なるAIシステム間の合意を高めたり、データ自体の正確性を向上させたりすることには失敗しました。データの正確性は、制御群と非制御群の両方において、42回のテストのうち正しい結果は19件のままでした。この研究は、現世代のAIにとって、仕様書は「AIがすでに知っていること以上の質へと引き上げるガイド」というよりも、「破滅的な失敗を防ぐためのセーフティネット」として機能することを示唆しています。仕様書の真の力は、AIを一致させることにあるのではなく、ソフトウェア構築のプロセスを、チェックと検証が可能なほど信頼できるものにすることにあるのです。