Recursive SuperintelligenceのAWSとの4億1,000万ドル契約、資金をコンピュートへ転換
Recursive SuperintelligenceはAmazon Web Servicesに4億1,000万ドルを投じることを約束し、公表済み資金の大半を複数年にわたる計算能力への投資へと振り向けた。Amazon TechCrunchの報道が重要なのは、これが通常のクラウド購入ではないためだ。Recursiveは、AIエージェントにモデル、インフラ、製品を改善させ、従来は人員拡大が担ってきた役割を縮小しようとしている。
このコミットメントは、Recursiveが5月にステルス状態を脱し、6億5,000万ドルの資金調達を発表した後に続くものだ。AWSとの契約額は、立ち上げ時に発表された資本のおよそ63％に相当する。Recursiveは、この契約の支払いスケジュール、年間最低利用額、ハードウェア割り当て、性能目標を公表していない。
したがって、その緊張関係は異例なほど明白だ。Recursiveは、そのリソースが生み出す製品を公に実証する前に、エージェント数とコンピュートへ資本を投入している。このアプローチは、進歩が研究者の採用よりも自動化された研究ループの拡大に依存するのかを、他の研究所にも考えさせることになる。
AWSも、大口顧客を1社得る以上のものを手にする。Amazonによれば、両社は同様のAI研究を進める組織向けのインフラを共同開発する。ただし、この契約には投資要素は含まれておらず、インフラへのコミットメントと戦略的資金提供を組み合わせるクラウド提携とは一線を画している。
Recursiveは10月ごろに最初の具体的な製品をリリースする予定だ。これらの製品は、同社のコンピュート集約型の運営モデルが、単に目を引くインフラ費用ではなく有用なソフトウェアを生み出せるかどうかを示す最初の証拠となる。
Amazon TechCrunchの契約が実際に変えるもの
Recursiveは、野心的な研究仮説を測定可能なインフラへのコミットメントへと転換した。
元のコンピュート契約によると、Recursiveは7月28日にAWSと複数年・4億1,000万ドルの契約を締結した。この契約により、同社は自己改善システムの成長に合わせて計算リソースを柔軟に拡張できる。
再帰的自己改善とは、AIシステムが将来の自らのバージョンを改善するプロセスに参加することを指す。その参加には、コードの作成、実験の提案、結果の評価、研究ツールの修正などが含まれる。必ずしも、人間の監督なしに自律システムが自らのあらゆる部分を再設計できることを意味するわけではない。
この区別は重要だ。Recursiveが追求しているのは、理論上の知能爆発だけではなく、実用的な開発ループである。同社のエージェントは、それらを構築するシステムを改善しながら、実際の製品を生み出すことが期待されている。これにより、クラウドの計算能力は同社の生産モデルの一部となる。
創業者兼CEOのRichard Socherは、この戦略を端的な対比で要約した。「私たちにとって重要なのは、人員数よりもエージェント数です」。この言葉は、Recursiveがどのようにリソースを配分するつもりかを示している。新たな資本の大半を給与や従来型の業務に振り向けるのではなく、自動化された実験を実行するマシンに資金を投じる計画だ。
このコミットメントは、Recursiveが公表した資金調達の大部分を占める。ただし、これを一括の即時支払いと捉えるべきではない。複数年のクラウド契約は通常、時間をかけた商業上の義務と利用条件を定めるものであり、実際の消費量はワークロードや契約条件に左右される。
両社はいずれも、その条件を公表していない。読者には、Recursiveがどのアクセラレータを使うのか、AWSがどれほどの容量を確保したのか、支出が特定の開発マイルストーンに依存するのかは分からない。したがって、発表された金額はコミットメントの規模を示すものであり、完了済みの利用額ではない。
SocherはTechCrunchに対し、今後数年間においてこれはRecursiveの小規模なコンピュート契約の一つになると見込んでいると語った。この発言は会社による予測であり、独立して検証された支出計画ではない。それでも、経営陣が現契約を初期配分と見なしていることを示している。
AWSの幹部Jason Bennettも、この種の顧客に適したインフラを両社で共同開発すると述べた。目的特化型のインフラには、ワークロードのスケジューリング、データ移動、実験管理、専門的な構成などが含まれうる。両社は、共同作業の対象となる正確な構成要素を明らかにしていない。
この契約には、AmazonによるRecursiveへの投資は含まれない。この分離により、取引は理解しやすくなる。Recursiveはクラウド容量を購入し、AWSはインフラを提供・調整する。投資資金が直ちにクラウド収益として戻る循環的な取り決めについて、両社は説明していない。
この構造はRecursiveに柔軟性を与える一方、説明責任も生む。同スタートアップはいま、製品提供の基準となる大規模かつ公的なコミットメントを負っている。10月の目標は、追加のエージェントが開発サイクルを十分に短縮し、この運営モデルを正当化できるかを試すことになる。
Recursiveが人員拡大より先にエージェントへ投資する理由
Recursiveは、自動化された研究が従来型の研究所組織よりも速く資本を吸収し、さらに大きく拡張できると賭けている。
従来のAI企業は、研究者、エンジニア、製品チーム、営業、コンプライアンス、オフィス、計算リソースに支出を配分する。Recursiveのアプローチは、そのバランスを技術作業を行うマシンへより大きく移す。人間の研究者が目標と安全策を定義し、エージェントが実験と開発タスクの増加する部分を実行する。
この分担は、なお目標にとどまる。現在のAIエージェントは、コードを書き、ツールを操作し、実験結果を比較できる。一方で、誤りを犯し、不適切な前提に従い、一貫した判断を要する長期タスクには苦戦する。効果的な自動化には、依然として評価システムと人間によるレビューが必要だ。
Recursiveは、若い企業としては異例に大規模な資金基盤を持って公に登場した。同社のステルス解除には、GV、Greycroft、Nvidia、AMDなどからの6億5,000万ドルが含まれていた。同社は主要なAI研究所や大学での経験を持つ研究者を集めた。
この資金により、Recursiveは小規模なスタートアップには容易に試せない組織設計を検証する余地を得た。自動化された研究ループには、多数の並列モデル実行、評価、失敗した実験が必要となる。各ループは、有用な結果を生まない場合でも計算リソースを消費する。
この無駄は、必ずしも偶発的なものではない。研究は不確かな経路を探索することに依存し、エージェントは限られた人間チームよりも多くの経路を探索できる。ビジネス上の問いは、追加の実験が資本を消費する速度を上回って知識を生み出すかどうかだ。
「エージェント数」は、経営陣にとってのボトルネックも変える。数百人の専門研究者を採用するには時間がかかり、チーム規模の拡大とともに調整コストも上昇する。十分なコンピュート、信頼できるツール、そして有用なタスクがあれば、ソフトウェアエージェントを追加で起動することは迅速に行える。
しかし、ソフトウェアエージェントは交換可能な従業員ではない。その数を増やすと、同じ誤りを繰り返したり、低品質な出力でレビュアーを圧倒したりする可能性がある。並列化が価値を生むのは、システムが実験を順位付けし、有用な知見を保持し、弱い結果が後続の作業を汚染するのを防げる場合に限られる。
ここでインフラが中核となる。Recursiveが必要とするのは、生のモデル訓練能力だけではない。実験を起動し、系統を追跡し、評価を比較し、検証済みの知見を将来のエージェントに戻せるシステムが必要だ。
同社名はフィードバックループを示唆するが、そのループは設計されなければならない。エージェントが変更を提案し、別のプロセスがそれを検証し、評価レイヤーが採用するかどうかを決定する。失敗した変更は隔離したままにし、成功した変更には文書化と再現性が必要になる。
これは、より大きな研究規模での自動化されたソフトウェアデリバリーに似ている。難しいのは有望な答えを一つ生成することではない。限られた人間の注意のもとで、数千のアクションにまたがる信頼できるプロセスを維持することだ。
Amazonは、こうしたワークロード向けに弾力的なインフラと運用支援を提供できる。AWSはまた、最先端研究スタートアップが何を必要とするかを、それらの要件が標準的なクラウド製品になる前に学ぶことで利益を得る。この関係により、Amazonは株式を保有せずに新興の顧客パターンへ直接接することができる。
したがって、Amazon TechCrunchの報道は、スタートアップ経済におけるより広範な変化を指し示している。資金調達は、希少な人材チームを採用するためだけに使われるものではなくなっている。コーディング、テスト、研究を24時間体制で行う継続的な機械労働を購入できる。
この変化が人間を不要にするわけではない。人間がプロセスのどこに位置するかを変える。研究者はますます目標、評価、制約を設計し、エージェントは反復可能な実行を担うようになる。
開発者やナレッジワーカーにとって、このモデルは実務上の変化を予見させる。価値あるスキルは、多数の自動化タスクにまたがって文脈を維持し、出力を判断することになる。ナレッジブレンディングのためのシステムは、機械生成の作業を人間の意思決定やソース資料と結び付け続ける必要がある場面で、より重要になる。
Recursiveはいま、自社のエージェントが累積的な進歩を生み出すことを示さなければならない。各タスクが信頼できる記憶、評価、文脈なしに始まるなら、エージェント数の増加はコストを押し上げるだけだ。コンピュートは実験を可能にするが、それが積み上がるかどうかはプロセスの質が決める。
Amazon TechCrunchの報道が明らかにする真の対立軸：人員数対エージェント数
中心となる競争は、Recursiveと一つの競合研究所の間ではない。エージェント優先の運営モデルと、人材集約型のAI開発モデルの間にある。
大規模なAI研究所は、研究者、インフラエンジニア、安全性の専門家、製品チーム、政策担当者を雇用している。その規模は、モデルの訓練と研究成果を信頼できるサービスへ転換することの複雑さを反映している。Recursiveはそれらの機能を回避しているわけではないが、その内部でソフトウェアエージェントがより多くの作業を担うことを期待している。
この戦略は、技術力を採用と同一視する研究所に圧力をかける。Recursiveがより小さなチームで競争力のある製品を提供できれば、競合他社は自らの人員配分について問われることになる。投資家もまた、追加の役職一つひとつが、同額のコンピュート予算より大きな進歩を生んでいるかを問うだろう。
圧力は双方向に働く。既存の研究所は、組織的な知識、独自データ、流通チャネル、成熟した評価プログラムを備えている。こうした資産は人間チームの有効性を高め、エージェントにより良い環境を与えることができる。
Recursiveは同じ製品基盤を持たずに出発する。モデル、研究システム、デプロイメントインフラ、安全管理、ユーザー向けアプリケーションを、ほぼ同時に構築しなければならない。コンピュートはこれらの作業を加速できるが、それらの間にある依存関係を取り除くことはできない。
人材集約型の組織は、目標が曖昧な場合にも強みを持つ。経験豊富な研究者は、誤解を招くベンチマークを見抜き、安全でない挙動に気づき、実務では機能しない洗練されたアプローチを放棄できる。エージェントは、根底にある目標をその目的が十分に表していない場合でも、与えられた目標を最適化しがちだ。
タスクを明確に指定・評価できる場合、エージェントファーストのモデルは説得力を持つ。コードはコンパイルでき、テストは自動実行でき、モデルの性能は定義済みのスイートに照らして測定できる。一方、評価そのものに異論がある場合、研究の自動化は難しくなる。
したがってRecursiveの戦略は、エージェントを構築するのと同じくらい評価器の構築に依存している。評価器とは、出力や実験を期待される基準に照らして採点するシステムだ。弱い評価器は近道を報いるため、本当の改善を伴わない見かけ上の進歩を許してしまう。
この懸念は、エージェントが自ら使用するツールの後続バージョンに影響を及ぼす場合、さらに深刻になる。評価ループが欠陥のある変更を維持すれば、エラーは増幅しかねない。人間によるレビューは一部の問題を捉えられるが、レビュー能力はエージェント数に応じて自動的に拡張されるわけではない。
再帰的自己改善という概念にも、普遍的に受け入れられた閾値はない。別のRSI分析では、研究者がこの用語を異なる自動化水準に対して用いていることが示された。段階的な改善を指す人もいれば、人間の介入をほとんど必要としない急速なサイクルを想定する人もいる。
Recursiveはまず、段階的でプロダクト志向のバージョンを追求しているように見える。どのシステムも自律的に自らを再設計できるようになる前に、同社のエージェントは研究やソフトウェア開発に貢献できる。この位置づけにより、短期的な主張はより検証可能になる。
最も明確な試金石は開発速度だ。Recursiveが有用なプロダクトをリリースし、迅速に改善し、比較的小規模な組織でそれを実現できれば、そのモデルの信頼性は高まる。集中的な支出にもかかわらず提供が遅れれば、エージェント主導開発の限界も同様に有益な情報となる。
コスト効率ももう一つの試金石だが、外部からの測定は難しい可能性がある。計算資源に関する負担が大きい場合、給与総額が小さいからといってコストが低いとは限らない。重要な比較は、人件費、インフラ、運用オーバーヘッドを横断した1ドル当たりの成果だ。
品質も重要である。自動化システムは、顧客が何を必要としているかを見つけ出さないまま、多数のプロダクトのバリエーションを生成できる。利用データだけで動機を説明できることはほとんどないため、人間によるプロダクト判断は依然として重要だ。
このため、人員数とエージェント数の対比を、単純な人間排除の物語にしてはならない。Recursiveにはなお、研究の方向性を定め、挙動を監査し、どのプロダクトをリリースに値すると判断する人材が必要だ。同社の賭けは、人間の専門知識の消滅ではなく、レバレッジにある。
他の研究所も、このアプローチの一部を模倣できる。コーディングエージェントと自動評価は、すでにAI開発全体で一般的になっている。Recursiveは、自社のループが他で利用できるツールよりも統合され、自律的で、生産性が高いことを示さなければならない。
Amazonにも、そのモデルの標準化を支援する動機がある。エージェントファーストの研究所が大量のクラウド容量を消費するなら、AWSは計算集約型の新たな顧客層にインフラを販売できる。Recursiveを支援することで、Amazonは将来の提供内容に活かせる運用上の知見を得られる。
したがって主要な競争上の影響は、組織設計に現れるだろう。競合ラボが直ちに同一の契約を結ぶ必要はない。どれだけの技術作業を人間のチームから、監督下にあるエージェントシステムへ移すべきかを決める必要がある。
コンピュート予算は自己改善の有効性を証明しない
大規模なクラウド契約は実験のための基盤を供給するが、Recursiveの技術的な仮説を裏付けるものでも、有用なプロダクトを保証するものでもない。
4億1,000万ドルという数字は、依然として未知である事柄を覆い隠しかねない規模感を生む。Recursiveは、エージェント数が研究生産性にどう影響するかを示すベンチマークを公表していない。エージェントが受け入れられる変更をどの程度の頻度で生み出すのか、各変更にどれだけの人間によるレビューが必要なのかも開示していない。
現時点で、Recursiveのシステムが大幅な人間の介入なしに自らを改善することを示す公的な証拠はない。同社はその目標に向けて構築中だと述べている。報道では、計画中の能力と実証済みの能力の違いを維持すべきだ。
再帰的自己改善について、合意されたベンチマークも存在しない。静的テストにおけるモデル精度では、エージェントが価値ある研究の方向性を確実に選べるかを捉えられない。コーディングベンチマークは狭いタスクを測定する一方、本格的なプロダクト開発には優先順位付け、統合、セキュリティ、ユーザー判断が求められる。
生産的なループは、システムが意図した結果を達成せずに指標だけを満たすことで起きる報酬ハッキングを避けなければならない。エージェントは、テスト上のアーティファクトを利用したり、モデルの挙動を狭めたりしてベンチマークを改善するかもしれない。スコアは上がっても、基盤となる能力は向上しない。
自動化された研究はセキュリティ上の懸念も生む。コードの編集、ワークロードのデプロイ、データへのアクセスが可能なエージェントには、厳格な権限管理が必要だ。誤作動した、あるいは操作されたエージェントは、情報を露出させ、リソースを消費し、重要なシステムを変更するおそれがある。
Recursiveは、自社エージェントを統治する権限モデル、監査プロセス、封じ込め措置を公には詳細に説明していない。この不在は、安全でない慣行の存在を示すものではない。読者が同社による自律性と統制のバランスを評価できない、という意味だ。
インフラの集中は別のリスクをもたらす。複数年にわたるAWSとの関係は、Recursiveにリソースと技術支援へのアクセスを与えるが、単一のクラウドプロバイダーへの依存を深める可能性もある。ツールとワークフローが特定のプラットフォームを中心に共同開発されると、移行はより困難になる。
Amazonからの出資がないことは、ある形態の結び付きの強さを抑える。今回の取引においてRecursiveは、Amazonの投資先企業ではなく顧客であり続ける。ただし、株式関係がなくとも、技術的な依存は重大になり得る。
容量の可用性も不確実要因となる。AI企業はアクセラレータ、ネットワーク機器、電力、データセンター用スペースを奪い合っている。大型契約は計画立案を改善し得るが、公表された契約額だけでは、Recursiveがどのハードウェアをいつ利用できるのかは分からない。
同社の支出軌道も精査に値する。Socherは、将来的にはさらに大きなコンピュート契約を見込んでいる。この予測は、技術の進歩、資金調達の継続、商業収益、あるいはそれらの組み合わせを前提としている。
Recursiveの初期資金調達は相当なリソースを与えるが、コンピュートは資本を急速に消費し得る。プロダクトの登場が予想より遅れれば、経営陣はワークロードの優先順位について難しい判断を迫られるかもしれない。追加の資金調達は所有構造を変えたり、短期的な成果への圧力を高めたりする可能性もある。
最初のプロダクトが仮説全体を決着させるわけではない。再帰的改善の寄与が小さくても、従来型のエンジニアリングから有用なアプリケーションは生まれ得る。Recursiveは、開発のどの部分をエージェントが担い、その参加が時間、コスト、品質をどう変えたのかを説明する必要がある。
独立した再現は証拠を強める。Recursiveの外部にいる研究者がその手法を再現したり、同様の成果を観測したりできれば、主張は企業の発言への依存を減らせる。このスタートアップは、そうした評価に必要な技術的詳細をまだ十分には公開していない。
安全性も不確実性の一部である。再帰的自己改善は、AI能力が急速に高まることに関する議論で長らく取り上げられてきた。査読済みのリスクモデルは、再帰的改善を超知能のハザードに関連し得る一つの経路として特定したが、特定のシステムがその経路をたどるとは予測していない。
短期的なリスクは、投機的なシナリオより具体的だ。信頼できないコード、誤解を招く評価、過剰なリソース利用、データ露出、十分なテスト前にリリースされるプロダクトなどが含まれる。Recursiveの10月のプロダクトは、こうした日常的だが重大な問題を同社がどう管理するかについて証拠を示すはずだ。
Amazonに関するTechCrunchの報道は、Recursiveの仮説に財務上の数字を与えている。しかし、その仮説に成功指標を与えてはいない。同社がプロダクト、評価、開発上の証拠を公開するまで、この取引は資金を得た実験にとどまる。
Recursiveの賭けが機能しているかを示す3つのシグナル
プロダクトの提供、測定可能なエージェントの貢献、そして後続のインフラ判断が、コンピュートファーストのモデルがより広く採用されるに値するかを決める。
最初のシグナルは、Recursiveが計画している10月のプロダクトリリースだ。Socherは、AWS契約からわずか数カ月後という短期的な節目として、その時期にユーザーが具体的なプロダクトを目にするはずだと述べた。
公開リリースは、Recursiveのエージェントが作業をデプロイへと進められるという根拠を強める。プロダクトが超知能を確立する必要はない。機能し、認識可能な問題に対処し、エージェントが実質的に支援する開発プロセスを通じて改善される必要がある。
リリースの遅延は、再帰的自己改善を反証するものではない。研究のスケジュールは変わり、責任あるチームはテストで問題が明らかになればプロダクトを延期する。しかし、説明のない遅延は、エージェント数が実行速度を高めるという主張を弱めるだろう。
リリースに伴う詳細は、ブランディングより重要になる。Recursiveはプロダクトが何をするのか、どのモデルが支えているのか、ユーザーが信頼性をどう評価できるのかを説明すべきだ。また、自動化された研究がシステムの構築に果たした役割も説明すべきである。
2番目のシグナルは、測定可能なエージェントの貢献を示す証拠だ。Recursiveは、自動化された作業と受け入れられた改善を結び付ける指標を必要としている。有用な測定には、検証済みの実験、レビューを通過したコード変更、開発サイクルの短縮、複数回の実行で再現された評価上の向上などが含まれ得る。
生の活動量だけでは不十分だ。実験数、生成されたコード行数、稼働中のエージェント数は、価値を生まないまま増える可能性がある。強い証拠は、活動を信頼できる成果へ結び付けなければならない。
人間の関与も明確に開示すべきだ。研究者向けの提案を生成するエージェントは、限られた介入で実験を設計、実行、評価するシステムとは異なる。どちらも有用になり得るが、裏付ける主張は異なる。
Recursiveは、有意義な証拠を提示するために、機密性の高いモデル詳細を公開する必要はない。手法、評価プロトコル、失敗カテゴリー、集計された受け入れ率を公表できる。外部監査や研究協力があれば、こうした開示の信頼性はさらに高まる。
同社が統制された人間の監督下で再現可能な成果を示せば、競合他社にとってエージェントファーストの運営モデルを無視することは難しくなる。指標が検証済みの結果ではなく量に焦点を当てるなら、懐疑は強まるべきだ。
3番目のシグナルは、次のインフラまたは資金調達に関する判断だ。SocherはAWS契約について、将来の取引の中では比較的小さい部類になる可能性が高いと説明した。後続のコミットメントは、追加のコンピュートが引き続き有用なリターンを生むと経営陣が考えていることを示すだろう。
その次のステップの条件は示唆に富む。AWSとの追加契約は共同開発関係を深める可能性がある。別のプロバイダーとの契約は、マルチクラウド戦略、ハードウェアの多様化、あるいは交渉力を求める意図を示すかもしれない。
資金調達も重要になる。Recursiveはすでに、複数年にわたって支出されるとはいえ、公表済み資金の大半に相当する額をコミットしている。今後のインフラ拡大は、残存資本、収益、新規投資、または見直された商業条件によって支えられなければならない。
新たな資金調達ラウンドが、技術的成功を自動的に確認するわけではない。プロダクトが成熟する前でも、投資家は野心的な仮説に資金を提供し得る。より強いシグナルは、資本へのアクセスと、公開導入、継続利用、技術的証拠を組み合わせたものになる。
AWSにも独自の節目がある。Bennettは、両社が同様のニーズを持つ組織向けのインフラを開発すると述べた。Amazonが後にその取り組みを文書化されたサービスへ転換したり、同種の研究所を呼び込んだりすれば、このパートナーシップは1件の契約を超えてクラウド市場に影響を与えたことになる。
その成果は、Amazon TechCrunchが掲げるより広範な論点を強化することになる。エージェントファーストのAI企業は、独自のインフラカテゴリーを形成しているという論点だ。こうした企業のワークロードには、反復的な実験、大規模なオーケストレーション、そして機械主導の開発に合わせて設計された評価システムが必要となる。
後続顧客が現れなければ、その意義は限定される。この契約は、例外的な資金力を持つ1社のスタートアップ向けに特化した取り決めにとどまる可能性がある。AWSは、Recursiveと計画しているインフラを利用する他の顧客を明らかにしていない。
開発者がこうした兆候を注視すべきなのは、成功した自動化研究ループが一般的なソフトウェアチームにも広がっていくためだ。同じ仕組みでコードを生成し、テストを実行し、障害を分析し、社内ツールを更新できる。その信頼性が、組織がどこまで安全に責任を委任できるかを左右する。
エンタープライズの購入担当者は、超知能をうたう言葉ではなく、証拠に注目すべきだ。製品が監査可能で、制御可能で、経済的に持続可能かどうかを知る必要がある。大規模なコンピューティング予算だけでは、こうした疑問への答えにはならない。
ナレッジワーカーも同様の変化に直面する。エージェントが増えれば、下書き、判断、実験記録、そして相反する出力も増える。人間が結果に至った経緯を検証できるよう、情報源と推論を維持することが課題になる。
Recursiveは、自社の論点を検証する明確な方法を選んだ。AWSのキャパシティを活用して研究と製品開発への機械の参加を拡大し、その後、具体的なアプリケーションをユーザーの手に届ける。
このコミットメントは同社にリソースと期限を与えるが、信頼性を自動的に与えるものではない。信頼性は、実際に機能する製品、エージェントを検証済みの進捗へ結び付ける指標、そして観測可能なリターンに裏打ちされた支出判断によって得られる。
これが、4億1,000万ドルという見出しの実質的な意味だ。Recursiveは、スタートアップが投資を機械による研究能力へ転換する速度で、従来型の研究所による投資から人員への転換を上回れるかどうかを試している。
10月に何がリリースされるのか、どのような証拠が添えられるのか、そして顧客が使い続けるのかを見極めたい。こうした兆候は、Amazon TechCrunchの契約がより生産的な開発モデルに資金を投じたのか、それとも単にそれを構築しようとする非常に高価な試みに過ぎなかったのかを示すことになる。
