AI経済においてソフトウェア要件が容易になる理由

AI経済において、ソフトウェア要件の収集は大幅に容易になると考えられます。その理由は、要件の出所が人間から他のプログラムへとシフトするからです。従来のソフトウェア工学では、要件定義が最も時間のかかる作業であり、ユーザーの真のニーズを理解するために何度も対話を重ねる必要がありました。しかし、AIエージェントが主体となる経済では、多くのプログラムが他のプログラムと直接やり取りします。プログラムは人間のように曖昧ではなく、明確な意味論と仕様を持っているため、要件を正確に把握することが可能です。

まず、形式検証の概念が紹介されています。形式検証とは、システムが数学的に正しいことを証明する手法であり、AIシステムが再帰的自己改善中に暴走するのを防ぐための最善の保護策の一つとされています。しかし、自然な障害は、施行したいルールを十分に詳細に書き出すことであり、そのような記述は仕様と呼ばれます。経済におけるAIの役割が増大するにつれて、一方ではルールの慎重な施行が重要なコンピュータシステムの数が増えますが、他方では正しいルールを書き出す作業が容易になるという逆説的な感覚があります。筆者は以前、AIが普及するにつれて、AI同士のみが相互作用する「バブル」を経済に含めるように設計することが理にかなっており、ユーザーインターフェースの仕様策定が容易になると論じました。今回、筆者はシステム要件のより広範な課題も根本的に容易になるという主張を展開します。基本的な利点は、要件において誰の意図を形式化する必要があるかから来ます。頼りない人間から要件を得るのは任意に困難ですが、新しい要件のソースが主にすでに稼働している他のプログラムである場合はどうなるでしょうか。

筆者はソフトウェア工学の難しさを振り返ります。AIコーディングアシスタントがソフトウェアエンジニアの時間配分を変える前から、この分野ではユーザーが本当に望むものを理解する、つまり要件収集が圧倒的に時間のかかる活動であるというのが自明の理でした。最近のルーチンコーディングの自動化により、要件収集の中心性はますます高まると予想されるかもしれません。しかし筆者は、自動化の可能性にさらに依存することで、皮肉にも従来の要件収集の重要性が低下するだろうと示唆します。1960年代にはアナリストとプログラマーが分離し、前者が要件を理解してフローチャートなどの比較的曖昧さの少ない表記法に変換し、後者がコードに変換しました。筆者の正式なプログラミング教育では、フローチャートにほんの少し触れただけでしたが、夏季インターンシップで大企業の長年在籍する技術者から「プログラマーはキャリアパスとして貧弱な選択であり、アナリストの指示を受ける認知的下層階級である」と助言されたことを覚えています。（AIコーディング支援の進展により、その助言は当時考えていたよりも先見の明があったのかもしれません！）ソフトウェア工学の分野では、ウォーターフォールモデルなどの正統派が発展し、チームは高価なプログラミングプロセスを開始する前に、書かれた要件を何度も繰り返し検討しました。要件の作成はソフトウェア専門家チーム内部のプロセスだけではなく、プログラムの意図されたユーザーとインターフェースして、どの機能が彼らを満足させるかを完全に理解することがおそらく最も重要です。1回の会話では不十分で、ユーザーに要件文書の改訂版を繰り返し示し、関連するすべてのシナリオについてより抽象的に考えるよう促す必要があります。

結局、ウォーターフォールは時代遅れとなり、より迅速に動作するプログラムを開発してユーザーがより情報に基づいたフィードバックを与えられるようにするアジャイル手法が主流になりました。問題は、ソフトウェアの専門家でさえ複雑なプログラムのすべての関連シナリオを列挙するのが難しいことです。多くのシナリオは、ユーザーの専門知識に依存して初めて重要であることが明らかになりますが、そのユーザーはすべての関連する使用フローをその手順と微妙な点までマッピングするために必要な抽象的かつ体系的な思考の訓練を受けていません。製品ロードマップを導くためにそのような情報を引き出すことは、今日でも非常に困難であり、プロダクトマネジメントという専門分野を動機付けています。ユーザーにとって本当に最適なソリューションを学ぶことの課題は、ヘンリー・フォード（おそらく伝説的）に帰せられる引用でしばしば説明されます。もし顧客に交通手段で何を望むか尋ねていたら、彼らはより速い馬を求めただろうが、彼が最終的に与えたのは自動車だった、というものです。少なくとも2つの別々の問題があります。第一に、ソフトウェアの基本的な目的について漠然とした考えを持つユーザーは、その目的を十分に詳細に説明するのに苦労するかもしれません。第二に、ソフトウェア開発の実用性を理解していないユーザーは、何をどのコストで構築することが実現可能かを理解できないかもしれません。

良い知らせは、機能を要求するユーザーが人間ではないことが多い場合、これらの課題は劇的に減少するはずです。より正確には、エージェントエコシステムの一部の部分では従来の要件収集の課題が残り、おそらくより困難な形で存在しますが、残りの部分ではこの活動を大幅に回避できます。

ソフトウェアはより知識のあるユーザーである プログラムの「欲求」を人間の欲求よりも知ることが容易である理由には根本的な理由があります。私たちの進化の過程では、人間の心を他者がモデル化しやすいようにする選択圧はあまりかかっていません。実際、シグナリングなどの側面は、私たちの思考プロセスの不透明さを促進してきました。例えば、他者が私たちを感動させる方法を推測するのを難しくし、私たちを感動させることに成功した人が異常に有能で、交流する価値があると信じられるようにするためです。対照的に、プログラムは少なくとも1つの聴衆、すなわちそれを実行するコンピュータに対して説明可能である必要があります。つまり、コンピュータはプログラムの意味を十分に明確に理解してプログラムを実行できる必要があり、これはより技術的に言えば、プログラムに曖昧さのない意味論が必要であるということです。さらに、人間がプログラムを作成し保守する際にプログラムを理解する必要性（少なくとも最近までは）が加わります。プログラムが理解可能であることには多くの選択圧がかかっており、それが今、プログラムが自分の仕事をより良く行うために新しいコードの作成を要求する能力に活かされています。

この利点が最大限に発揮される究極の設定は、経済のかなりの部分が人間ではなくAI同士の相互作用のみで構成される場合です。そのような設定は、自動推論に対する可読性のために設計された環境の恩恵を最大化できます。自動化された作業のエコシステムは、事前に設定された仕様に向かって再帰的に自己改善することも、競合し協力するエージェントのセットが独自の仕様に向かって共に進化することもできます。どちらの方法でも、基本的な目標の機械可読な特性評価が容易に得られ、それを定期的に新しいプログラムの要件に投影できます。

筆者は図を用いて原理を視覚的に説明しています。左側のパネルは現在の世界を示し、多くのAIエージェントが存在し、そのほとんどすべてが人間と直接調整する必要があり、自分が何を望んでいるのかをうまく説明できないステークホルダーから要件を収集せざるを得ません。右側のパネルは私たちが向かっているかもしれない世界を示し、経済の大部分はAIエージェントによって処理され、それらは自然にクラスターを形成し、人間とインターフェースする必要があるまれなゲートキーパーだけが存在します。クラスターの内部は秩序と明確な要件の場です。この世界では、プログラムの大部分は内部にあり、明確な要件源の恩恵を受けます。

重要なのは、私たちが後からエージェントエコシステムの行動や欲求を特徴づけようとするのではなく、今、形式仕様と検証を初期の段階からそれらの設計に織り込む可能性があるということです。私たちの課題は、AIエコシステム全体をカバーする仕様を書き、その住人が私たちの目標や価値観と互換性のある方法で進化するように強制することです。この要件収集の課題は少なくとも従来と同様に困難です！筆者の主張は、そのようなAIバブル内の他の多くのエンジニアリングプロジェクトは枠組みを構築するのが容易になり、それらは進行中のソフトウェア工学の努力（および関連コスト）の大部分を占めるべきであるということです。

この現象のより控えめなバージョンは今日すでに一般的です。新しいWebブラウザを実装するソフトウェア工学チームの例を考えてみましょう。既存の技術標準は新しい設計を大幅に制約します。インターネット標準には、Webページのコードがユーザーに表示されるべきものとどのように対応するかを説明する膨大な要件がすでに書き下されています。経済のより多くの部分がAIエージェントによって処理されるにつれて、それらのコンテキストのより多くが同様に標準化されるか、少なくとも分析可能な既存のコードに具体化されるでしょう。

ここで注目すべきは、今日最も人気のある種類のAIソフトウェアである深層学習には、個々のプログラム（学習された要素としてのモデル重みを含むと解釈される）にほとんど見かけ上の構造がなく、したがって理解が難しいという明確な欠点があることです。筆者は、この特性が、理解可能性と数学的議論でその動作を正確に境界づける能力のために設計された他の方法の使用を促進するべきだと主張しますが、より広範な議論はそれ以外でも関連性を保ちます。言い換えれば、解読不可能な学習システムの世界に住むか、それとも明示的な要件を満たすことが証明されたシステムを推進するかを決定するための短いウィンドウがあるかもしれません。悪意のあるAIに対する安全性だけでなく、それが可能にするAI自己改善の効率性にとっても、第二の道が重要である可能性があります。

仕様とコードの一部をコピーすることは比較的容易 では、プログラムが新しいプログラムの作成を要求するようになるにつれて、ソフトウェア工学の初期段階がどのように安価になるのか、もう少し具体的に見ていきましょう。

まず、ユーザープログラムが良いプラクティスに従って書かれており、独自の洗練された要件文書を持っていると仮定します。最も一般的な議論を見ると、新しいプログラムを要求するプログラムは、新しいプログラムに望まれる品質基準で要件が書き出されていると仮定できます。この利点の単純な説明は、要求元プログラムの要件から関連する要件内容の一部を単にコピーできるということです。人間のユーザーではそのような選択肢は簡単ではありません。人間は自分の人生の目標を機械可読な形で包括的に公開する傾向がないからです。

より広く、プログラムが新しいプログラムの作成を望むことがどのように起こるべきかを考えてみましょう。筆者は、技術革新に従事する経済を、コンピュータサイエンスの意味での分散システムと見なし、異なるエージェントが一連の重複する最適化問題の中で協力し競争することを提案しています。異なる参加者は、自分が達成しようとしていることを異なる詳細レベルで知っています。ソフトウェアである参加者は、特に厳密な形式仕様と関連付けられる可能性が高いはずです（少なくとも、人間にはその名誉はほとんどないでしょう！）。あるレベルでは、そのような経済システムは、繰り返し自己最適化に従事するプログラムです。

自己改善プログラムが自然に自身のコードの一部を改善された変種に持続させる例をもう少し具体的に見てみましょう。比較的単純なケースは、特定の数学関数を計算し、その関数をより効率的に計算するために自身の構造を改善する方法に気づくプログラムです。筆者は、将来立ち上がるソフトウェア工学プロジェクトは、私たちが慣れ親しんでいるものよりも、この種の自己最適化に似ているだろうと主張しています。目標を持っているが、それを達成する方法について比較的曖昧な考えしか持っていないプログラムは、新しいコードの作成を要求します。

[AIコスト制御のため省略]