科学・技術

デコヒーレンストラップ

156 pointsby cassianoleal2026年10月19日67 コメント

要約

この記事は「デコヒーレンス」という概念を導入しています。これは、システム内に局所的には有効だが相互に互換性がなかったり冗長だったりするモデルが蓄積し、モデル間の変換や意図しない副作用の防止にコストがかかるようになる現象です。AIの普及により、このデコヒーレンスが持続不可能な速度で増大しており、AIの自己改善能力の暴走を防ぐ一方で、「デコヒーレンス崩壊」という新たな危機に向かっていると論じています。

全文翻訳

The Decoherence Trap

TL;DR

この記事では、デコヒーレンスという概念を紹介します。これは、システム内に局所的には有効だが、互いに互換性がなかったり冗長だったりするモデルが蓄積し、それらのモデル間の変換や意図しない副作用の防止にコストが支配されるようになる現象です。

言い換えれば、それはノイズの果てしない海の中で、ノイズがシグナルを溺れさせることです。

デコヒーレンスはシステムの変更率に対して成長し、システムがデコヒーレントであればあるほど速く増加するため、制御不能な指数関数的成長につながります。これは新しい現象ではなく、人間は常に、より少ないリソースでより多くのことを行う方法を慎重に見つけ、ばらばらのパターンやモデルを包括的な全体に統合することによって、これに対抗してきました。しかし、AIの広範な使用は現在、持続不可能な速度でこれを生み出しています。

良いニュースは、これにより、誰も反応する前に放物線状に急上昇する知能爆発、つまり再帰的な自己改善の亡霊が排除されることです。デコヒーレンスは、AIが孤立して改善するのを防ぎ、また、外部で改善する速度を制限するからです。悪いニュースは、私たちは別の種類の災害に向かっているということです：デコヒーレンス崩壊です。

建物を想像してみてください。小さなオフィスビルだとしましょう。この建物が建てられたとき、時間の経過とともに劣化し、最終的に交換が必要になるタイプの配管が使用されました。これは標準的なインフラストラクチャの負債です。基本的な摩耗と損傷、ということわざの通りです。

次に、配管を交換する時期が来たら、新しい規格に変更する必要があるとしましょう。これは、新しい建築基準法の要件のため、古い配管が製造されなくなったため、または新しい配管がはるかに優れていてメンテナンスが容易になったためかもしれません。これは標準的な技術的進歩の負債であり、時間の経過とともに技術が進歩するにつれてアップグレードおよび移行する必要があるものです。

古い配管から新しい配管への移行をどのように行うかに基づいて発生する、3番目の形態の負債があります。次のオプションを検討してください：

建物を閉鎖し、すべての配管を一度に交換する。これは非常に破壊的で高価な方法です。作業中は建物を使用できず、事前に交換費用を支払う必要があります。しかし、プロセスは終了時に完了します。
各フロアを一度に1つずつ閉鎖し、そのフロアの配管を交換する。これは全体としては破壊的ではありませんが、事前に支払う必要があり、作業中に物事を円滑に進めるための追加労働にプレミアムを支払う必要があるため、いくらか高価になります。
配管が故障し始めたときに、必要に応じて交換する。これは最も破壊的でない戦略であり、一度に1つの小さな修理で、交換費用の償却を時間とともに行うことができます。

ほとんどの人にとって、オプション3は非常に魅力的です。物事を円滑に進め、メンテナンス費用を分散させることができます。そして、もし私たちがテセウスの船のようにして、配管を一つずつ交換できるなら、なぜそうしないのでしょうか？

さて、その理由の1つは、それがデコヒーレンスを生み出すことです。

そしてデコヒーレンスは、これまでで最悪の技術的負債の形態です。

Evolution

テセウスの船は、デコヒーレンスの真の範囲を理解するための良いレンズを提供してくれます。木製の船の作り方、鋼鉄製の船の作り方はわかっています。元の思考実験のように、1つずつ同じ素材で船を修理できれば、船は機能し続け、組み込まれたすべての元の設計と構造はそのまま維持されます。

しかし、木材と鋼鉄の間のすべてのイテレーションの船を構築する方法を知っているでしょうか？たとえば、戦艦のすべての部品をゆっくりと交換して、徐々に現代の駆逐艦に変えることができるでしょうか？そして、プロセスの各段階で、機能的（機能の何らかの定義において）であるようにできるでしょうか？

［画像: Ship of Theseus, stage 1 of 4］［画像: Ship of Theseus, stage 1 of 4］

［画像: Ship of Theseus, stage 2 of 4］［画像: Ship of Theseus, stage 2 of 4］

［画像: Ship of Theseus, stage 3 of 4］［画像: Ship of Theseus, stage 3 of 4］

［画像: Ship of Theseus, stage 4 of 4］［画像: Ship of Theseus, stage 4 of 4］

答えが絶対的な「いいえ」ということではありません。私たちが十分に創造的であれば、最高の頭脳がそれに取り組んでいれば、確かに何らかの道はあるでしょう。しかし、それは創意工夫とスキルと職人技を必要とするでしょう。それは細部への注意を必要とするでしょう。そして、決定的に、プロセスを完了したいと思うでしょう。なぜなら、半戦艦、半駆逐艦の船は、現代の戦闘ではおそらくあまり役に立たないからです。

配管の例に戻ると、同じ戦略が建設の世界でどのように定期的に展開されているかを見ることができます。配管が壊れるたびに、配管工が呼ばれ、壁が開かれ、その特定の領域のために修理が手作業で作られ、その後すべてが閉じられます。運が良ければ、配管工は詳細なメモを残すでしょう。運が悪ければ、何年も後に誰かがその壁を再び開けて、「一体これは何だ？」と言うでしょう。

私たちの建物の配管をゆっくりと交換していく過程で、そのプロセスを倍増させると、結果として、古い配管と新しい配管のパッチワークになり、どちらのシステムよりもはるかに複雑になります。すべての接合部、すべての手作業で作られたパッチは、それ自体が独自の力と特性の小さな束であり、十分に研究されていないため、完全に理解して作業するには両方のシステムの専門家が必要になります。

表面的には、これは問題ありません。配管は機能しています。どのように機能するかはなぜ重要なのでしょうか？良いパッチである限り、誰が気にしますか？

さて、たとえば、別館を建てたい場合はどうなるでしょうか？

この思考実験の目的のために、別館の水は既存の建物の一部を通過し、既存の配管を使用する必要があるとしましょう。そして、決定的に、システム内の全体的な水圧を上げる必要があります。

さて、質問は次のとおりです：圧力の上昇は安全ですか？

もし私たちがすべてタイプAまたはすべてタイプBの配管を持っていたとしても、時間とともにパッチが当てられ修理されたものであっても、これは簡単な質問だったでしょう。両方のシステムはよく理解されており、どちらも容量を計算するためのツールとプロセスを持っており、人々は常にこれらの計算を実行しています。

しかし、それらのシステムの未知の混合物がある場合、突然、その質問に答えるためにより多くの分析を行う必要があります。すべてのパッチは、たとえシステムの反対側にあっても、答えを変える可能性があります。なぜなら、それらはすべてつながっているからです。

［画像: A small office building drawn faintly, with its plumbing inside: a main from the street feeds a network of pipes that widens floor by floor, and new runs reach out toward an annex next door. Dots mark the patched joints. Most hold; two, on different floors, fail.］［画像: A small office building drawn faintly, with its plumbing inside: a main from the street feeds a network of pipes that widens floor by floor, and new runs reach out toward an annex next door. Dots mark the patched joints. Most hold; two, on different floors, fail.］

そして、ここでデコヒーレンスの真の複雑さが明らかになります。デコヒーレントなシステムに変更を加えようとすると、単一のシステムを扱うよりもはるかに多くの専門知識とスキルが必要になります。システムに取り組むエンジニアは、変更が意図しない結果をもたらす可能性があるため、システムをより徹底的かつ注意深くトレースして理解する必要があります。そしてはい、私は配管工をエンジニアと見なします、少なくともソフトウェア開発者と同じくらい。排水管の圧力の力をリアルタイムで考えているのを見たことがありますか？それは驚くべきことです。

それは簡単な作業ではなく、急いで行うべきではありません。しかし、外部の観察者にとっては、問題の深さを理解せずに、これはイライラさせられる可能性があります。通常、この部分は簡単です。なぜ今回はこんなに時間がかかっているのですか？

この状況では、経営陣はしばしば物事をより速く終わらせるために圧力をかけます。圧力がかかると、専門家は分析を速く完了するのではなく、分析を早く切り上げて、ほぼ確実に機能すると思われることを行います。不格好な接合部、珍しい部品、念のため追加の安全対策など。

しかし、タスクを徹底的に完了しないことは、連鎖効果を生み出します。この特定の変更は品質が低下し、システムをより脆弱で複雑にします。これは、次の変更がさらに多くの思考と注意を必要とし、エンジニアへの圧力が同じであれば、さらに悪い仕事をするだろうという意味です。

それはすでにかなり厄介な状況であり、ここで一種の複雑さの指数関数的な成長が起こっているのがすでにわかります。しかし、まだあります！デコヒーレンスの次のレベルを考えてみましょう：最初の移行を完了する前に2番目の移行を開始することです。

The Maze

物理的な建物や他の種類の現実世界のシステムと比較して、ソフトウェアの難しい点は、すべてが一種の不可視であるということです。

コーダーは毎日コードベースの廊下を歩き回っています。私たちはコードベースの迷路を非常に頻繁に通り抜けるため、隅々まで精通しており、歩行が長くなり、より多くの廊下、行き止まり、落とし戸が現れると、それをはるかに即座に直感的に感じます。

［画像: A maze extending past every edge, with a dot stepping through it］［画像: A maze extending past every edge, with a dot stepping through it］

しかし、これは迷路が見えない人、毎日あなたと一緒に歩かない人には伝えにくいことです。そして、借金を片付けたり、迷路を短く曲がりくねらないようにしたりする時期が来ると、たとえ昔は迷路を歩いていた人たちでさえ、提案を上に売り込むのは難しいです。結局、誰もあなたの迷路を知りません。彼らは、あなたがそこに入るたびに直面する試練を知りません。

それに比べて、現実世界の配管工は、建物の所有者に配管の不条理さを直接示すことができます。

［画像: A tangled patchwork of plumbing pipes］

r/plumbing提供 r/plumbing[^2^]

2つ以上のシステムを、時間とともに無計画に多くのパッチを当てて混合し始めると、迷路の複雑さは爆発します。それは組み合わせ的になります。A → B、A → C、B → C、A → B → C、C → B → Aなどを考える必要があります。

もちろん、ある程度エンジニアをこれらから隔離することはできます。ベストプラクティスを考案したり、ツールやフレームワークを使用してシステムの一部を別の部分から分離したりできます（たとえば、配管に圧力制限バルブを使用するなど）。しかし、最終的には、最高のエンジニア、最も賢い人々でさえ、迷路を安全にナビゲートできなくなる時点に達します。

彼らは80％または90％の時間それを実行できるかもしれませんが、最終的には間違った道を選び、

糸の跡を残すのを忘れて、立ち往生してしまう

終わりのない成長の広大さの中に

彼らのすべての歩みを超えて進む

永遠に。

［画像: A lone figure with a lantern at the entrance of a vast maze］［画像: A lone figure with a lantern at the entrance of a vast maze］

これがデコヒーレンストラップです。迷路は、あなたを丸ごと飲み込み、暗闇で迷子にするまで、進み続けます。それがあまりにも巨大になり、一生かかるようになるまで。

まあ、人間の一生ならね。しかし、AIはどうでしょうか？

Simulation

人間は疲れ、身体的な限界に達しますが、自律エージェントのスワームは、ロボットのように、迷路を熱心にマッピングしながら、一日中稼働し続けることができます。問題が規模であるなら、より多くのコンピューティングリソースを投入して、それで終わりにするだけでよいのではないでしょうか？

さて、それは私たちが直面している複雑さの性質によります。それは：

コードベース全体のサイズに線形に成長する、または
指数関数的に成長し、各変更が次の変更がさらに多くの複雑さを追加する可能性を高める。

前者であれば、問題のサイズが大きくなるにつれて、より多くのエージェントとデータセンターを追加し、ほぼ同じペースで問題に取り組むことができます。しかし、後者の場合、容量を増やすことは、地球上の（そして宇宙の、もしSpaceXの計画[^3^]がうまくいけば）すべてのコンピューティングを食い尽くそうとする迷路のサイズになるまで、少しだけ先に進む能力しか得られません。

私の経験では、後者です。配管工が壁を開けて混乱を見たとき、何が起こっているのかは明らかではありません。パイプAを使用するかもしれないし、パイプBを使用するかもしれないし、混乱の中でまったく新しいタイプのパイプを追加するかもしれません。コードではさらにそうです。

これは、以下の簡単なシミュレーションで展開されるのを見ることができます。ここでは、コードベース（または他の複雑なシステム）を表すグラフがあります。ここで：

ノード

システム内のさまざまなコンポーネントを表します。

ノードサイズ

コンポーネントのサイズを表します。

ノードカラー

コンポーネントが属する主要なパラダイムを表します。これはコンポーネントの「種類」と考えることができます。さまざまな素材の配管、コード内のさまざまな構造、さまざまな種類のシステムなどです。

エッジ

それらのコンポーネント間の接続を表します。

プリコンパイルされたタイムラインを読み込んでいます…

これはいくつかの実行の記録です。自分で完全なシミュレーションを試して、設定を変更して何が起こるかを見たい場合は、こちらで見つけることができます。

開発者を表すアクターは、グラフのランダムなサブセクションを歩き、それを変更することによって「機能」を実装します。アクターの基本的な動作は、そのコヒーレンスファクターによって形成されます：

低いコヒーレンスは、アクターが問題に対してより迅速に駆け抜け、コンテキストを考慮せずに単純な解決策を好み、全体としてグラフに複雑さを追加することを意味します。
高いコヒーレンスは、アクターがより長く時間をかけ、より多くの思考をもって各問題に取り組み、したがって、より少ない複雑な変更を行うか、または複雑さを削除する可能性が高くなることを意味します。

当初、低コヒーレンスのアクターは、高コヒーレンスのアクターと比較して非常に速く移動します。しかし、グラフが変化するにつれて、それはアクターの歩行にも影響します。次の各項目がアクターの進行を遅くします：

高い接続度（エッジの数）。これは、現在のノードへの影響を理解するために、少なくとも部分的に、各隣接ノードのコンテキストを引き出す必要があるという負担の増加を表します。
色の間の遷移。パラダイムを切り替える際にはオーバーヘッドがあり、アクターは各パラダイムのコンテキストと理解、およびそれらがどのように接続されているかを再び得る必要があります。
パス長。遷移が必要な接続が増えるにつれて、歩行自体がさらに長くなる可能性があります。これは、アクターが機能を実装するために必要なコンテキストをすべて取得するために、より多くの読み取りと再訪問が必要になることを表し、システム全体のサイズに達するまで無期限に増加する可能性があります（つまり、どこでも変更を加えるには、すべてを理解する必要があることを意味します）。

時間とコヒーレンスにわたって構築された機能の分布を取ると、結果をプロットして、エンジニアなら誰でも見慣れているはずの形状を見ることができます：スイートスポット。

スイートスポットでは、システムは比較的コヒーレントであり、それを維持するために積極的に投資します。いくつかの主要なパラダイムがありますが、物事が変化し適応できる十分なジッターがあり、すべてに対して過度に完璧主義ではありません。

スイートスポットの上では、新しいノードが既存のパラダイムに適合するように、そしてあらゆる機会に複雑さを排除するように、私たちは非常に懸命に努力します。これにはさらに時間がかかり、機能作業が遅くなりますが、最悪の場合でも、比較的迅速にイテレーションできる非常にコヒーレントなシステムが生成されます。

スイートスポットの下では、コードベースが指数関数的に複雑になるにつれて、ドロップオフは急激です。機能を出荷するのにかかる時間は際限なく増加するため、コヒーレンスファクターが負であり、コヒーレンスの維持に注意が払われない場合、速度は非常に急速に失われます。

また、さまざまな開始点からさまざまな戦略が時間とともにシステムにどのように影響するかを確認できます。非常にコヒーレントなシステムから始め、ほとんどデコヒーレントな戦略（いくらかのコヒーレンスが維持されるがショートカットが取られるコヒーレンスファクター+0.2）を使用すると、グラフは最初にゆっくりと崩壊し、いくつかの変曲点を経てトラップに入ります。

対照的に、デコヒーレントなシステムから始め、時間とともに再コヒーレンスさせる努力をすると、コヒーレンスに向かって針を動かし、加速することができます。

さて、批評家は、このシミュレーションには任意の値があり、複雑なシステムがどのように進化するかを決定的に証明するものではないと指摘するかもしれません。これは私の主張ではありません。

シミュレーションが示すのは、この曲線が単純なルールとローカルな決定の創発的な振る舞いとして存在できるということです。今日のシステムを変更するアクターは、将来のアクターがシステムを変更する能力を改善または低下させることができます。これは明らかな真実ですが、現実世界のように配管やワイヤー、物理ハードウェアで複雑さを見ることができない場合、その意味合いは非常に簡単に失われる可能性があると思います。

したがって、エージェントに関する質問に戻ります。エージェントはこれらのシステムで作業し、コヒーレンスを維持できるでしょうか？それとも、時間とともに、たとえわずかであってもデコヒーレンスを導入するのでしょうか？なぜなら、考慮すべきもう1つの重要なリスクがあるからです。デコヒーレンスは時間とともに成長するのではなく、変更とともに成長するということです。

デコヒーレントなシステムを今日構築し、それを10年間変更せずに放置し、戻ってきた場合、それはあなたがそれを残したままのデコヒーレンス度になります。他の形態の技術的負債があるかもしれませんが、それらはデコヒーレンスとは関係ありません。デコヒーレンスは、システムに変更が加えられたときにのみ成長または縮小します。

そして、非常に速く変更を加えている場合、知らず知らずのうちにデコヒーレントになる可能性もあります。たとえ非常にわずかなデコヒーレンス増加率であっても、制御不能に陥る可能性があります。

事実はこうです。私たちは、エージェント開発が登場するずっと前から、この現象に対処してきました。私が働いたすべての会社には、大量のデコヒーレンスがありました。経験の浅いエンジニアやプレッシャーの下にあるエンジニアも、時間の経過とともにデコヒーレンスを増やす傾向があるため、人間が完璧であるわけではありません。

実際、ほとんどの会社はスイートスポットをはるかに下回っており、実際には次のような連続サイクルで運営されていると断言できます：

デコヒーレンスが、合理的な時間内に機能を完了できなくなるまで成長します。
デコヒーレンスを削減するために大規模な努力が行われます。
その努力は成果を生み、機能は遅いが許容できるペースで出荷され始めます。
その努力は完了しないか、完了してもスイートスポットまで到達しません。リソースと焦点がシフトされ、システムは再びデコヒーレンスし始めます。

洗って、すすいで、繰り返します。一部の会社は、他の会社よりも速く、長く再コヒーレンスするかもしれませんが、ごく一部は時間とともにスイートスポットにとどまることができますが、それには献身的なエンジニアリング文化の卓越性が必要です（Appleが思い浮かびます。macOSの状態については何を言っても構いませんが、Windowsよりはいつでも受け入れます）。

問題は、エージェントがこの時点で平均的なエンジニアリング文化よりも実際に優れているかどうかです。しかも大幅に優れているのか？

これまでのところ、その証拠はありません。むしろ、初期の研究は逆を示唆しています。

ハーバード大学の研究[^4^]は、718社を対象に、コーディングエージェントの導入がコードの量を30％増加させたが、完成した作業の測定可能な増加はもたらさなかったと結論付けています。追加のコードはレビューで積み上がり、プルリクエストのレビューに49％長くかかり、変更のために戻されるものがほぼ2倍になりました。カーネギーメロン大学の研究[^5^]は、オープンソースプロジェクトでCursorを採用した結果、速度の大きなジャンプが見られたが持続せず、コードの複雑さの増加は持続し、その追加された複雑さが後の減速の主な原因であったことを示しています。また、6,000以上のリポジトリにわたる300,000以上のAI作成コミットの分析[^6^]では、11件に1件程度（アシスタントによっては最大7件に1件）が少なくとも1つの品質問題を導入し、その問題のほぼ4分の1が今日までコードに残っていることがわかりました。

より多くのコード、同じ量の完成した作業、そして変更ごとに残されるより多くの複雑さ。

Progression

さて、主な反論である技術的進歩の議論に対処しましょう。それは次のようなものです：

エージェントの最初の世代は劣悪なコードを生成するでしょうが、「十分によい」限り、それらはほとんどのコーディングタスクで人間を置き換えることができ、将来より有能なエージェントを期待してプロセスを構築できます。

これは、産業革命中の自動化の物語に効果的に似ています。最初の世代の繊維機械は確かに人間よりも劣っていましたが、最終的には追いつきました。Cory Doctorowが指摘したように、産業家たちは自動化を採用するために競い合いました。なぜなら、それは労働者を訓練し、労働者と一般の人々を犠牲にして権力を集中させることを可能にしたからです。彼らは何世代にもわたって、はるかに悪い労働条件と劣悪な品質の商品に耐えなければなりませんでした。[[^7^]][[^8^]][[^9^]]

［画像: Output per worker and real wages in Britain from 1780 to 1900, indexed to 1800. From 1800 to 1830, output per worker grows 0.63% a year while real wages grow 0.00% a year. From 1830 to 1860 output grows 1.12% a year and wages 0.86%, and from 1860 to 1900 output grows 1.03% a year and wages 1.61%. Over the same stretch, the share of income going to profits doubles from about 20% to over 40%.］［画像: Output per worker and real wages in Britain from 1780 to 1900, indexed to 1800. From 1800 to 1830, output per worker grows 0.63% a year while real wages grow 0.00% a year. From 1830 to 1860 output grows 1.12% a year and wages 0.86%, and from 1860 to 1900 output grows 1.03% a year and wages 1.61%. Over the same stretch, the share of income going to profits doubles from about 20% to over 40%.］

しかし、私はこれをさらに発展させたいと思います。なぜなら、それが繊維に効果があった根本的な理由があったからです。機械は劣悪な製品を生産しましたが、最低限の基準を満たしていました。

機械自体も、それが何であるかについては非常によく設計されていました。最近、機械技師と話しましたが、その世代の機械の品質、それらがどれほどうまく動作したか、どれだけ長く持ったかについて絶賛していました。はい、低品質のゴミを生産したかもしれませんが、それらを迅速かつ疲れを知らずに、そして何年も生産し続けました。次の世代が現れて、漸進的な改善でそれらを置き換えるまで。そして決定的に、機械が動作している間、デコヒーレンスの増加はありませんでした。摩耗と損傷はありました。世代間の進歩もありました。しかし、デコヒーレンスはありませんでした。

さて、問題はこうです。この議論の論理は、コードが繊維のアナロジーであると仮定しています。つまり、コードはユーザーが支払う最終製品です。しかし、誰もコードを買いたくありません。彼らはアプリケーションを買いたいのです。

言い換えれば、コードは繊維ではなく、繊維機械です。画面がレンダリングされるたびに、フォームが送信されるたびに、レコードが更新されるたびに、それがコードが生成する「製品」です。だからこそ、コードは非常に収益性が高かったのです。なぜなら、追加の顧客ごとに追加のオーバーヘッドは必要ないからです。原材料はチップ上の電気のビットとバイトであり、製品はそれらのビットにエンコードされた情報とプロセスです。

より正確なアナロジーは、私たちがタイムマシンで過去に戻って、繊維機械だけでなく、繊維機械を設計する機械を作ったとしたらどうなるかということです。それは、半自律的またはおそらく完全に自律的に、次の世代の繊維製造をイテレーションします。これはこれまで存在しなかったものであり、自動化の歴史において前例のないものです。

これは再帰的自己改善の夢です。知能爆発、技術的特異点[^10^]の夢です。これは、そもそもAIの夢です。

では、それはどうなっていますか？

Singularity

さて、ゴールポストは微妙にシフトしています。今年の5月、知能爆発理論の懐疑論者であるTom Reedは、AIが新しい世界についてのデータなしに孤立してイテレーションすることの限界を説明するために、「Goodhart Singularity」という用語を造りました。これはGoodhartの法則[^12^]に基づいています：

測定値がターゲットになると、それは良い測定値ではなくなる。

Charles Goodhartを言い換えたMarilyn Strathern

先月の投稿で、Forethought[^13^]の上級研究員であるTom Davidsonは、AIが「人間品質の天井」に達すると、データボトルネックが進歩を遅らせることを認めました。これは、学ぶべきこれ以上の人間のデモンストレーションがなくなり、AIが既存のすべてよりも高品質のデータを製造しなければならない時点です。Davidsonは、AIのテイクオフ速度のモデルについて広く書いており、彼の作品に基づいた後の予測、特にAI 2027シナリオ[^15^]があります。

したがって、Davidsonがわずかでも揺らいだことは注目に値します。しかし、彼はそれが一度限りの減速であり、壁ではないと主張しており、一般的に、速いテイクオフを期待している人々は、それが比較的少ないデータで独自に再帰的に自己改善できると考えており、このプロセスがデータセンターで孤立して制御不能になり、超知能の誕生につながる可能性があると考えています。

彼らがそれを可能にすると期待している方法は、彼らがソフトウェア知能爆発[^16^]（SIE）と呼ぶものです。具体的には、データボトルネックに関するDavidsonの投稿には、議論の微妙だが負荷の高い瞬間があります：

現実世界のソフトウェア成果物の構築を教えるRL環境を構築するのではなく、AIは人間が作成したものよりも優れたソフトウェアを作成することを教えるRL環境を構築する必要があります。

明確にしておきますが、これは可能だと思います！難しい課題を構築し、その答えを検証することは、それらを解決することよりも簡単です。今日でも、人間の専門家は、人間品質の天井を超えるデータを生成するRL環境を構築しています。データ品質は人間の天井で壁にぶつかることはありません。

これを分解しましょう。

Davidsonがここで言っているのは、AIは、主に孤立した状態で、現実世界のあらゆるものよりも優れたソフトウェアを作成できる必要があるということです。これを行うには、そのソフトウェアを生成できる強化学習環境[^17^]を作成できる必要があります。これが機能する仕組みは基本的に次のとおりです：

目標を定義する
実行できることのセットを定義する
アルゴリズムを使用して、目標を達成するためのさまざまな方法を試す
目標達成にどれだけ近づいたか、そして方法がどれだけ優れているかを測定する
最良の方法を見つける

SIEが発生するためには、AIは学習のためのより良いアルゴリズムを発見するために、このすべてを独自に行う必要があります。それが重要な部分です。それは単に優れたソフトウェアを生成することではなく、学習と改善のためのより優れたアルゴリズムを生成することです。

Goodhart Singularityは効果的に、データセンターで孤立したAIは、結果の測定ステップのために、多くの重要な現実世界のタスクに対してこれを行うことができないと主張しました。より良い車、ロケット、またはコンピューターチップの構築方法を理解したい場合、シミュレーションを構築して試すことはできますが、それでも調査結果を検証するために現実世界でテストする必要があります。さもなければ、設計をより極端な場所に進めるにつれて、最終的には現実からますます離れていくでしょう。これは、速度制限を導入し、物事を大幅に遅くします。

［画像: Three paths from one starting point. Reality wanders. A path checked against it drifts a little and snaps back at every check. A path that is never checked curves steadily away.］［画像: Three paths from one starting point. Reality wanders. A path checked against it drifts a little and snaps back at every check. A path that is never checked curves steadily away.］

しかし、これは一部のドメインでは真実ではありません。Davidsonが後半で言っているのはこれです。囲碁やチェスのようなゲームの場合、ゲームのルールが世界のすべてであり、明確な勝利条件があるため、孤立して実行し、より良い戦略を見つけることができます。また、より良い戦略を見つけるためのより良いアルゴリズムを見つけることもできます。これは、スタークラフト[^19^]やDota[^20^]のようなより複雑なゲームでも同様です。

しかし、これらはゲームであり、勝利条件が明確で単純であり、ルールまたは環境が非常に限定されているため、これを行うことができます。爆発を得るためには、これらの方法を重要なものに適用し、現実世界でテストすることなく、データセンターのバブル内でそれを検証できる必要があります。

［画像: Two five-step learning loops. In a game the loop closes on itself. For anything that matters, step four, measuring, has to leave the room and wait on the real world.］［画像: Two five-step learning loops. In a game the loop closes on itself. For anything that matters, step four, measuring, has to leave the room and wait on the real world.］

これにより、ソフトウェアに適用できることがわかります。SIE推進者は、ソフトウェアをギャップを埋める方法として捉え、それに固執していると思います。ソフトウェアは孤立して実行でき、非常に簡単かつ迅速に孤立してテストできます。これはRL環境を作成するのに最適であり、最終的には現実世界との同期を必要としないものを作成できると考えています。

結局のところ、それはソフトウェアだからです。それはほとんど何でもできますよね？

これは、シリコンバレーの多くの人々にとって、どのように自然に感じられるかがわかります。私たちは非常に知的であり、大きな問題を解決できることを誇りに思っています。コンピュータサイエンス教育の大部分は、ソフトウェアやアルゴリズムのプロパティを論理的に証明することなどです。このプログラムは完了しますか？このソートアルゴリズムは速いですか？どれくらい速いですか？このシステムは安全で、考えられるすべてのケースでクラッシュしないでしょうか？

私たちは問題をこのように考えることに慣れており、ソフトウェアには限界がないという考えに慣れています。テクノロジーは世界を支配したので、機械にコードを書くことを教えることができれば、最終的にはコードを書くのが得意になるという考えの自然な延長です。

そして、最終的には、機械も世界を支配することになります。

Better Software

この見方の問題は、ソフトウェアを良くしているもの、つまりコヒーレンスを完全に無視していることです。

詳しく説明しましょう。ソフトウェアは、現実世界で目標を達成するためのツールです。その目標は、多くの抽象化を経て、多くのステップ離れているかもしれませんが、それが成功するかどうかは、最終的にはその目標をどれだけうまく解決したかによって決まります。

なるほど、しかしソフトウェアを作成し、それが目標を解決したら、それをターゲットの出力として使用できるのではないでしょうか？そして、AIはそれらの目標を達成するためのより良い方法をイテレーションできるのではないでしょうか？

「より良い」を、行数、速度、メモリ、または効率のような単純で測定しやすいものとして定義した場合、はい。これらはすべて重要ですが、それらをターゲットとして扱うと、小さく、速く、そして完全にデコヒーレントなソフトウェアになります。

コードは作業をスキップすることで速くなり、作業をスキップできるのは、システムの他の部分に関する仮定を立てることによってのみです。このリストはすでにソートされている、その値はゼロにならない、など。それらの仮定のそれぞれは、誰も書き留めなかった隠された接続です。最適化されたネイティブコードが抽象化の下にあるのには理由があります。パフォーマンスのためにそれが必要であり、その仮定が漏れないように箱に封印します。もし私たちがすべてのコードをそのように書いたなら、それは絡み合った混乱になるでしょう。JavaScriptでの実践的な例は、ホットパスをモノモルフィック[^21^]に保つために、複数の論理クラスを単一のクラスに結合することです。それは常に大きな苦痛ですが、それをいじる必要がない限り、それに見合う価値があります。

ソフトウェアを一度だけ書いて、二度と触らないのであれば、それは問題ないでしょう。しかし、実際にはそれは決して真実ではありません。なぜなら、ソフトウェアは終わりのないテセウスの船だからです。アプリケーション、ライブラリ、フレームワークは、変化する状況に対応するために進化しなければなりません。社会の働き方を変え、自然界についてより多くを発見し、達成できることの限界を押し広げるにつれて、変化する現実世界の制約です。

したがって、優れたソフトウェアは時間とともに適応可能です。既存の技術資本（これまでに書いたすべてのソフトウェア）を取り込み、新しい問題に迅速に再結合して、その場で解決できます。

そして、それを適応可能にするのはコヒーレンスです。コンピュータープログラミングとソフトウェア品質におけるほとんどの大きな進歩は、ソフトウェアをよりコヒーレントにすることに関するものであり、それがよりコヒーレントであるかどうかをテストする唯一の方法は、現実世界からのフィードバックです。

具体的な例で分解しましょう：futures[^22^]。

Futuresは、非同期プログラミングをいくつかの根本的な方法で容易にします。Futuresが登場する前は、非同期を処理する方法はたくさんありましたが、それは予測可能な混沌とした混乱でした。具体的には、デコヒーレントなものでした。同じことを行うための多くの局所的に合理的な方法がありましたが、それらは互いに適合しませんでした。

開発者はその混乱の中で生きなければならず、1つのアプリが持つ可能性のあるさまざまな種類の非同期の間を慎重かつ注意深くナビゲートする必要がありました。ステップを逃したり、何かを忘れたりすると、追跡が困難なバグや問題が発生しました。また、コールバックが増え、アプリが複雑になり、処理すべき非同期が増えるにつれて、コード自体はホラーショーのように読めました。

Futuresは1970年代に概念として導入され、将来の値のプレースホルダーであるという中心的な考えがありました。最初の具体的な実装は1985年のMultiLispでした。しかし、Javaが2004年にそれらを導入し、チェーン可能なPromiseがJavaScriptに初めて導入され、C#がTaskをリリースした2010年代まで、それらは主流になりませんでした。アイデアから主流まで約35年かかりました。[[^22^]]

［画像: Timeline of futures: the idea in the 1970s, MultiLisp in 1985, Java in 2004, and JavaScript promises and C# Task in the 2010s, about 35 years from idea to mainstream.］［画像: Timeline of futures: the idea in the 1970s, MultiLisp in 1985, Java in 2004, and JavaScript promises and C# Task in the 2010s, about 35 years from idea to mainstream.］

これには主に2つの理由がありました：

最初のFutures APIは機能しましたが、ぎこちないものでした。Futureを渡すことはできましたが、値を読み取ろうとするとブロックされたため、いつ行うかに注意する必要がありました。また、独立してチェーンできなかったため、Futureを簡単にフォークすることはできませんでした。
Futuresはかなりのオーバーヘッドを導入します。たとえば、関数ポインタを格納する代わりに、状態を追跡するためのラッパーオブジェクトを作成する必要があります。

しかし、時間の経過とともに、うまく機能するAPIを見つけ、問題を解決し、オーバーヘッドは、より大きなシステム（コンピューティングとメモリが安くなることも役立ちました）を推論し、組み合わせるのが容易になるため、それだけの価値があることに気づきました。

これをAIに戻しましょう。

より良いAIソフトウェアを構築するには、それが実際に改善されたかどうかをテストできる必要があります。そして重要なことに、前述したように、バブル内で測定できる必要があります。バブルの外で測定することはできません。なぜなら、それは私たちが世界によって速度制限されることになるからです。

では、バブル内で何を測定できるでしょうか？

さて、私たちはそれを次のものに絞り込みました：

ゲーム
ソフトウェア
数学

ゲームは、私たちが気にかけている現実世界のタスクに根ざしていないため、あまり進歩しません。したがって、ソフトウェアに進みましょう。

確立したように、優れたソフトウェアはコヒーレントです。では、コヒーレンスをどのように測定するのでしょうか？

さて、抽象化を取り、さまざまなコンテキストでそれがどれほどうまく機能するか、そしてコードがそれぞれに適合するためにどれだけ曲がる必要があるかを確認します。データセンターを離れることは許可されていないため、これを行う方法は2つしかありません：

既存のすべてのソフトウェアに適用する。これは、たとえそれらがすべてでうまく機能したとしても、将来のすべてのソフトウェアでうまく機能するかどうかを知る方法がないため、ある程度しか役に立ちません。コールバックとイベントループは、GUIが標準になるまで一般的ではありませんでした。初期のWebサーバーはまだスレッドと従来の並列処理を使用していました。そのため、Webを構成するプログラムのセット全体が発見され、探索されるまで、Futuresがどれほど価値があるかは明らかではありませんでした。私たちはすでに知っているプログラムに過剰適合することになります。結果は今日完璧にコヒーレントに見えるかもしれませんが、適合しない最初の新しい問題はパッチを当てる必要があります。
新しいソフトウェアを作成する。これは理論上試みることができることですが、実際には、トレーニングセットを拡張するために、もっともらしい有用なプログラムを生成することはできません。繰り返しになりますが、ソフトウェアは現実世界で目標を達成するためのツールであり、その有用性を時々検証しないと、現実から大きく乖離する可能性があります。

この中核的な問題を超えて、コヒーレンスのもう1つの重要なテストは、抽象化または概念が、さまざまなコンテキストと進化する要件全体で、時間とともにどれほどうまく変換されるかです。標準は紙の上では良く見え、デスクトップコンピューターのような1つの環境ではうまく機能するかもしれませんが、モバイルデバイスや大規模なクラウドベースシステムには完全に不十分になる可能性があります。

もっともらしい有用なソフトウェアを生成するだけでなく、それがどのように適応するか、全員がアップグレードしない場合に何が起こるか、人々（またはエージェント）が遅れるか、別の方向に進むことを決定した場合、システムのエコシステムが常に移動するターゲットである場合にどうなるかを見るために、もっともらしい進化シナリオを生成する必要もあります。

既存のソフトウェアをよりコヒーレントにするためには、いくらでも良くなることができます。まだ持っていないソフトウェアを改善するには、(a)現実世界が新しいソフトウェアを生成するのを待つか、(b)新しいソフトウェアを作成し、現実世界でテストし、それが時間とともに進化するのを待つ必要があります。これらのオプションの両方には、バブルの外への往復が必要です。

すべてをまとめましょう：

バブル内に留まりながら、人間の能力を超える、より高速で、より小さく、より効率的なソフトウェアを生成するAIを作成できます。
前述のように、バブルを出ることなく、人間の能力を超えるソフトウェアのコヒーレンスを改善するAIを作成することはできません。
AIはバブルを出ることなくソフトウェアが普遍的に優れているかどうかを確認できないため、AIは学習アルゴリズムを実際に改善しているのか、それともドリフトしているのかを判断できません。
私たちはGoodhart Singularityにすぐに戻ります。

これは、高速で孤立したSIEの可能性に最初から釘を刺します。しかし、別の角度からアプローチすることもできます。このアプローチは、他の形態の知能爆発にも適用されます。

あらゆる形態の知能爆発は、AIが独自のソフトウェアまたはハードウェアを研究および改善することに依存しており、各世代は前の世代の改善の上に構築されます。
AIが現在の理解のフロンティアを超えてシステムを構築または拡張するため、各世代はシステムにデコヒーレンスを導入する可能性のある一定の割合を持ちます。
AIが速すぎると、修正できるよりも速くデコヒーレンスを蓄積し、全体的な能力の停滞または後退につながります。
AIがすべての調査結果を検証および確認する場合、世界からデータを収集する能力によって速度が制限されます。
これは、AIが測定するものがないため、純粋な孤立状態で開発されたより良い学習アルゴリズムでは対処できません（最初の証明を参照）。

ポイント3の失敗モードは、以下のグラフで確認できます。これは、EthとDavidsonのSIE論文[^16^]のモデルから適応されたものです。彼らの予測では、成長曲線は5か月前に放物線状になります。以下のグラフは、彼らのモデルを維持し、1つの仮定を追加しています。つまり、累積作業が増加するにつれて各変更のコストが倍増するという仮定です。これは、人間のコードベースにおけるデコヒーレンスのように見えます。

［画像: Growth of AI software over the first year after AI research is automated, on a log scale. Eth and Davidson's model with returns of 1.5 accelerates without limit and passes one hundred million times before month five. The same model with a cost of change that doubles as work accumulates follows it at first, then flattens: at about 460,000 times after a year when the cost doubles every 1,000 units of work, about 10,000 times when it doubles every 100, and about 200 times when it doubles every 10.］［画像: Growth of AI software over the first year after AI research is automated, on a log scale. Eth and Davidson's model with returns of 1.5 accelerates without limit and passes one hundred million times before month five. The same model with a cost of change that doubles as work accumulates follows it at first, then flattens: at about 460,000 times after a year when the cost doubles every 1,000 units of work, about 10,000 times when it doubles every 100, and about 200 times when it doubles every 10.］

これが真実であり、AIがデコヒーレンスを回避できない場合、最終的にAIは現実によって速度制限されます。それは決して私たちを追い越せないということではなく、意味のある意味でそうなるまでにはまだ長い道のりがあるということです。そして、たとえそうなるとしても、現実が要求するすべての作業を行う必要があり、私たちを支配するのと同じ物理的および情報的限界によって制約されることになります。

Davidsonは、現実世界のタスクを記録するだけで十分なデータを簡単に収集できると主張しています：

もし世界全体が協力してこれを迅速に進めるなら、それほど時間はかからないでしょう。各仕事について、1000人が画面を録画し、頭にビデオカメラを装着すれば、4か月以内にAIは300年分の経験を得るでしょう。

これは根本的に、世界の複雑さを過小評価しています。機械が継続的に自己改善できると期待する場合、カーソルを画面上で動かすことや、ビデオ内のオブジェクトを識別することに長けているだけでは不十分です。それは、世界自体を理解することについての深い洞察を開発する必要があります。人間のようにそれを経験する必要はありませんが、画面録画やビデオフィードだけでは捉えられない、目に見えないものや微妙なものを測定するために、同じ種類の情報を、同じ視点を捉えることができる必要があります。

それは、最初はまったく関係がないように見えるもの同士のつながりを作る必要があります。これは私たちの最後のトピックにつながります。

Mathematics

数学は、理論的には、検証済みの証明を使用してバブル内でチェックできるもう1つのドメインです。AIがバブル内で数学をより良くできるようになれば、全体としてより良い学習アルゴリズムを開発でき、そうすればSIEの議論は依然として成り立つかもしれません。

問題は、数学は一種の恣意的であるということです。私たちは、それがどのように機能するか、そして何が有用かについて多くの決定を下します。たとえば、数字のゼロは常に有効な数として受け入れられていたわけではありません。虚数は受け入れられるまでに数世紀かかり、その4次元のいとこである四元数は、Lewis Carrollにとってそれほど不条理に思えたため、Mad Hatter's tea partyで風刺した[^23^]と考えられています。

これらは、私たちが当然のことと考えている例ですが、実際にはそれほど明白でも自然でもありません。それらは、実生活の実践で使用され、出力が現実と意味のある方法で一致した場合にのみ、広く受け入れられるようになりました。

同様に、コンピューティングの基礎となる数学であるブール代数も、ほぼ1世紀にわたって難解な数学分野と見なされていました。それは1847年にGeorge Booleによって初めて発表されました[^24^]が、実用的な応用はなく、真剣な工学ツールとしてではなく、形式論理の奇妙なものとして研究されていました。

この数学の重要性は、1930年代にClaude ShannonがMITでVannevar Bushの微分解析機の継電器制御に取り組んでいたときに発見されました。彼は以前、学部時代の哲学の授業でブール代数に出会い、[[^25^]]回路に取り組んでいるときに、それらが完全に一致することに気づきました。彼の修士論文「A Symbolic Analysis of Relay and Switching Circuits」は、1937年にその関連性を示し、あとは歴史です。

［画像: Timeline from Boole's algebra in 1847 to Shannon's thesis in 1937. AND lines up with two relay contacts in series, OR with two in parallel, across ninety years in which the algebra had no use.］［画像: Timeline from Boole's algebra in 1847 to Shannon's thesis in 1937. AND lines up with two relay contacts in series, OR with two in parallel, across ninety years in which the algebra had no use.］

Booleは単に数学を無意味に発明していたわけではありません。彼は、彼が発見した特性、彼が作ったシステムがいつか重要になるという直感を持っていました。彼は人間の思考の法則を発見したと思っていましたが、それはある程度誤解されていたかもしれませんが、論理学者や哲学者がそれを研究し、Shannonが見つけてそれを構築するまでそれを引き継いだほど興味深いものでした。

もしShannonが、現実の問題に直面して、どこを見るべきかを教えてくれるリレーでいっぱいの部屋にいなかったら、代わりに、すべてが局所的に有効で全体的に無意味な証明の無限の山をソートしていたとしたら、AI時代にその関連性を見つけることができたでしょうか？

［画像: Two fields of identical tick marks, each a valid proof. In 1937 there are two dozen and the one that matters is easy to see. Now, with AI, there are hundreds and the same tick is nearly lost.］［画像: Two fields of identical tick marks, each a valid proof. In 1937 there are two dozen and the one that matters is easy to see. Now, with AI, there are hundreds and the same tick is nearly lost.］

真空中で定義できる論理的および数学的システムは無限にあり、これらの仮説を構築し探求することに非常に長けることができます。それらが重要かどうかを判断することは別のスキルであり、それはバブルで改善できないスキルです。

数学者はすでにこの二分法を心配しています。9月には、Terence Taoを含む25人のフィールズ賞受賞者が、問題の解決は数学の真の目標である理解の単なる代用品であり、真の命題の大量生産は新しいアイデアが育つ土壌を侵食する可能性があると主張する宣言に署名しました[[^27^]]。

その土壌がすべてすり減ったとき、何が起こるのでしょうか？

Collapse

コヒーレンスを構築する作業は、長く容赦のないプロセスです。それは、すべての隙間を探索し、すべての岩の下を調べる作業です。現実の泥に身を沈め、ブーツに染み込ませながら、盲目的に手探りで、世界があなたを中心にどのように構成され、再構成されるか、無限に、それがあなたを飲み込むことを許さずに、すべての方法を見つけ出すことです。

それは単に問題を解決することではありません。それは、そもそも私たちが解決しようとしている問題が何であるかを理解することです。

私たちが解決しようとしているすべての問題を見つけ出し、迷路のように爆発することなく、それぞれを解決する単一の解決策を見つけることです。

そこで、私の最後のポイントに移ります。

［画像: Pixel-art Omarchy wordmark with the tagline: Beautiful, fun and agentic Linux by DHH. The malleable OS for the age of agents. Vibe your way through every alteration, tweak, or trouble.］［画像: Pixel-art Omarchy wordmark with the tagline: Beautiful, fun and agentic Linux by DHH. The malleable OS for the age of agents. Vibe your way through every alteration, tweak, or trouble.］

最近、Omarchy[^28^]について多くのことが言われています。それを愛する人もいれば、言ってみれば、エージェント中心のLinuxディストリビューションに懐疑的な人もいます。彼らはエコシステムの端にかなり速く進み、元のクリーンなデフォルトセットであるという目標から、カスタムカーネルを備えた完全なディストリビューション[^29^]へと変貌を遂げているようです。

ここで明確にしておきたいのは、エコシステムの端での実験は重要だということです。フォークすること、アイデアを探求すること、制約なしで何が機能するかを見つけること、そしてその発見をコミュニティに持ち帰ることは、オープンソースソフトウェアがこれほどうまく機能する理由の大きな部分です。

しかし、私はここで心配しています。

私たちは皆一緒に山を登っていることを、どこかで忘れてしまったのではないかと心配しています。私たちがコミュニティとしてこれほど成功し、回復力があった理由、過去数世紀にわたってコンピューティングをこれほど速く進歩させたものは、コヒーレンスを構築するプロセスです。

80年代、90年代、そして00年代を通して、すべての企業が独自のスタックを管理していました。各サーバーは、依存関係、スクリプト、OSバージョンなどの独自の小さなバンドルでした。平均的な企業で物事を円滑に進めるためだけにチームが必要でした。

OS戦争[^30^]の間、その断片化はさらに悪化しました。Unixには明確な後継者がなく、Windowsはまったく異なるパラダイムで勢力を伸ばしていました。もしLinuxがその時期に構築されていなかったら、そして古い*nixエコシステムを捉えていなかったら、私たちは今日どこにいたでしょうか？はい、FreeBSDが存在し、その代わりになった可能性があることは知っています。私が本当に意味するのは、もしフリーソフトウェア運動がまったくなかったらどうなっていたかということです。

クラウドでコンテナを起動するたびにライセンス料を支払うことになるのでしょうか？

スタックを実行するためのコストのために、どれだけのスタートアップが開始できなかったでしょうか？

その断片化は、すべてのシステムが時間とともに古く、ぎこちなく感じられるようになった理由でもありました。エコシステム全体がデコヒーレントであり、過去20年間の作業の多くはコヒーレンスを追加すること（そしてSaaS製品でその価値の一部を捉えること、しかしそれは先走っています）でした。

私たちはここで一種の焼畑農業を実践しているのではないかと恐れています。私たちが築き上げたコヒーレンスを、すべての依存関係を再構築し、すべてのソフトウェアをカスタマイズし、短期的な問題を解決するためにあらゆる方向に拡張することのために捨てているのです。

そして、そのすべてが、私たちが罠に深く入り込んでいることに気づいていないのです。

［画像: A much larger maze with three regions. A small bright central region is the amount of the maze that humans can work within. A larger purple region around it is the amount that agents can work within. Beyond that, the walls scatter out of alignment, and this is where it all falls apart.］［画像: A much larger maze with three regions. A small bright central region is the amount of the maze that humans can work within. A larger purple region around it is the amount that agents can work within. Beyond that, the walls scatter out of alignment, and this is where it all falls apart.］

人間が処理できること（そして時間とともに修正できること）

エージェントが処理できること（しかし後戻りできない）

地球上のすべてのコンピューティングで到達不可能な場所

もし私たちがコヒーレンスを維持または再構築することなく長すぎたり遠すぎたりすると、現在の傾向では、システムを維持するためにエージェントを使用しなければならない場所に行き着くでしょう。なぜなら、システムは非常に大きく、圧倒的すぎて、私たち自身では維持できないからです。しかし、もし私たちがそこに捕らえられ、エージェントが修理作業を行うことによって私たちを後戻りさせることができないと判明した場合、私たちは非常に不快な状況に陥るかもしれません：

たとえ修正にどれだけ努力しても、システムがゆっくりと劣化する開発モデルに閉じ込められる。

それは最終的にシステムを修正できなくなるということではありません。しかし、それには数年または数十年かかる可能性があり、その間、機能を出荷したり、社会における他の多くの差し迫った問題に取り組んだりすることはできません。

これが私がデコヒーレンス崩壊と呼ぶものです。そして、それは実際に今、私たちの目の前で起こっているため、暴走する超知能よりもはるかに恐れています。

AIにはある程度の有用性があることは明確にしたいのですが、それはコアワークフローを置き換えたり、完全に自律的に実行したりするよりも、むしろ周辺にあると考えています。私はCory Doctorowのリバースケンタウロス分析[^31^]を強く支持しています。機械に私たちを運転させたくありません。私たちが機械を運転したいのです。その点について、私の個人的な仕事や生活でどのようにアプローチしているかについての詳細な議論は、私のAI使用ポリシーとガイドをお読みください。

そして、この作品で繰り返し述べてきたように、デコヒーレンスは新しい問題ではありません。むしろ、それは人類文明の始まり以来、あるいはそれ以前から存在していました。それは、私たちが常に扱ってきた、そして常に扱わなければならない、自然な種類の減衰または劣化、エントロピーの一種です。それを念頭に置いて、2つの最後の考えを残したいと思います。

デコヒーレンスは、システム自体が変更されたときにのみ変化します。これは、どれほど悪化しても、常に前進を止め、後戻りを開始できることを意味します。AIが私たちを罠の奥深くに押し込んだ場合、完全に回復するには数年または数十年かかるかもしれませんが、最も難しい部分は最初です。それ以降のすべての部分は雪だるま式に大きくなるでしょう、ただし、コヒーレンスの改善に焦点を当て続け、仕事を完了する場合。もし私たちが古いパターンに戻るのに十分なだけ改善した場合、サイクルを再開するだけです。
私たちはすでに、時間とともにコヒーレンスを改善することが知られているプロセスを持っています。人間はよりコヒーレントなシステムを作成する方法を見つけており、それらのシステムは、過去数世紀にわたる技術進歩の範囲と規模を可能にしたものの大部分を占めています。

特に、ソフトウェア開発のコヒーレンスの大部分を支えるオープンソースソフトウェアプロセスは、企業ソフトウェア開発をいくつかの驚くべき方法で打ち負かすほど、コヒーレンスを生み出すことに非常に成功しています。しかし、それについては次のエッセイでさらに議論します：Open Capital。