以下の文章は、コリイ・ドクトロウの「Code is a liability (not an asset)」という記事を翻訳したものである。
Pluralistic
コードは資産ではなく負債だ。テック業界の経営者たちはそれを理解していない。AIはプログラマーの1万倍のコードを生成できるからすばらしいと彼らは言うが、それはすなわち1万倍の負債を生み出しているということにほかならない。AIは我々の高度技術社会の壁に吹き付けられたアスベストだ。
https://pluralistic.net/2025/09/27/econopocalypse/#subprime-intelligence（邦訳）
コードは負債である。コードが持つ機能こそが資産だ。テック企業の目標は、コードの機能が生み出す収益が、そのコードを維持するコストを上回ることにある。長年にわたって、企業は「コードの運用コストは時間とともに下がる」という誤った信念を抱き続けてきた。最初の調整期間――バグを発見して修正する期間――が終われば、コードはもはや大きなメンテナンスを必要としなくなる、と。なにしろコードとは可動部のない機械であり、磨耗しない。そもそも劣化すらしない、という理屈である。
これはポール・メイソンが2015年に著した『ポストキャピタリズム』の論旨でもある――もっとも、この本は（メイソン自身の政治的信頼性ほどではないにしても）驚くほど時代遅れになってしまったが。コードは、労働力を必要としない無限に複製可能な機械などではない。むしろ、正常に動き続けるためにますます大がかりな措置を必要とする脆い機械であり、最終的には「摩耗する」（つまり、全面的なリファクタリングを必要とするようになる）。
なぜコードが負債なのかを理解するには、「コードを書くこと」と「ソフトウェアエンジニアリング」の違いを把握しなくてはならない。
「コードを書くこと」は、非常に有益で楽しく、夢中になれる営みだ。複雑なタスクを細かなステップに分解し、コンピュータが確実に実行できるほど精緻に記述し、RAMやプロセッササイクルといったコンピュータのリソースへの負荷を最小化する巧妙な方法を見つけることでパフォーマンスを最適化する作業である。
一方、「ソフトウェアエンジニアリング」は「コードを書くこと」を包含しつつも、そのコードが属するシステムの長期的な運用に焦点を当てた専門分野だ。ソフトウェアエンジニアリングが関心を持つのは、システムが受け取るデータを生成する上流のプロセス、システムが処理済み情報を送り出す下流のプロセス、そして上流プロセスからデータを受け取るか、あるいは下流プロセスにデータを送り出す隣接システムである。
「コードを書くこと」は、うまく動くコードを作ることだ。「ソフトウェアエンジニアリング」は、うまく失敗するコードを作ることだ。つまり、読み解けるコードを作ること――第三者がその機能を理解できること、メンテナンスを依頼されたり、システムが壊れないように上流・下流・隣接プロセスを調整するよう依頼されたりする人物が、その機能を把握できること――を意味する。あるいは、動作基盤のコンピュータアーキテクチャが廃止されて新しい種類のコンピュータや旧コンピュータのエミュレーションに置き換えなければならなくなった際にも、適応できるコードを作ることでもある。
https://www.theregister.com/2026/01/05/hpux_end_of_life
なぜなら、それが現実だからだ。どれほど大層なコードであれ外の世界とやり取りしなければならない。だが外の世界は静的ではなく、動的だ。外の世界はソフトウェア制作者が立てた前提を常に打ち砕き、そのたびにソフトウェアは修正を迫られる。Y2K問題を覚えているだろうか？ 完全に正常なコードが、完全に正常なハードウェア上で動作しているにもかかわらず、機能しなくなるという事態だった。コードが変わったわけでも、ハードウェアが変わったわけでもなく、単に時間が流れただけだ。
今から12年後には「Y2038問題」が訪れる。32ビット版のUnixがすべて、計算可能な秒数を使い果たし動作を停止する。これらのコンピュータ自体は変わっていないし、そのソフトウェアも変わっていない。しかし世界が――68年間、1秒ずつ時を刻み続けることで――その縫い目を擦り切り、ついには破裂させてしまう。
https://www.theregister.com/2025/08/23/the_unix_epochalypse_might_be
「世界」の存在は、ソフトウェアを摩耗させ、しばしば莫大なコストをかけて再構築することを強いる、避けがたい要因だ。コードが稼働している期間が長くなるほど、「世界」と遭遇する可能性も高まる。デバイスが物理的な位置情報を報告するために使うコードを考えてみよう。もともとこのコードは、どのキャリア／プロバイダのネットワークを使用しているか、ローミング中かどうかを判断するための課金用途に使われていた。やがてモバイル端末がナビアプリでの経路案内のために位置情報を利用するようになり、さらに紛失したデバイスを探すためにも流用されるようになった。これがさらに盗まれたデバイスの位置を特定する用途へと転用されたが、この用途は紛失デバイスの発見とは重要な点で大きく異なる――たとえば盗難デバイスを探す場合、悪意ある第三者が「紛失デバイスを探す」機能を無効化している可能性に対処しなければならない。
こうした新たな用途――上流・下流・隣接のいずれにおいても――は、以前の用途では表面化しなかった元のコードのバグを露わにした。たとえば、位置情報が正確に把握できない（これは非常によくあることだ）場合に備えて、すべての位置情報サービスは何らかのデフォルト動作を持たなければならない。接続している携帯電話基地局の位置は分かっているとか、最後に正確な位置情報を取得した場所は分かっているといった概算の情報がある場合もあれば、まったく見当もつかない場合もある。
実際のところ、多くのケースで位置情報アプリは「自分がいる可能性のある場所」を囲む円を描き、その円の中心を自分の位置として設定していたことがわかっている。円の直径が数フィートであれば問題ないし、アプリがより正確な位置情報でこの概算を更新できれば問題ない。だが、その位置情報が何マイルもの広さに及び、しかも位置情報が一向に改善されないとしたら？ 定義された位置情報を持たないIPアドレスの位置がアメリカ大陸の中心として設定され、自分の位置を把握できないアプリがカンザス州のある家を位置として報告するとしたら？ そして怒り狂った見知らぬ（時には武装した）人々が何十人もその家を訪れ、「お前は盗まれたスマホやタブレットを持っているはずだ」と迫るとしたら？
https://theweek.com/articles/624040/how-internet-mapping-glitch-turned-kansas-farm-into-digital-hell
このバグは1度修正すれば終わりではなく、何度も何度も修正しなければならない。
ジョージア州でも。
https://www.jezebel.com/why-lost-phones-keep-pointing-at-this-atlanta-couples-h-1793854491
テキサス州でも。
そして私が住むバーバンクでも同じことが起きた。Googleの位置情報共有サービスはかつて、当時11歳だった娘（電話に出ない状態だった）が12マイル先のLAカウンティの非法人地域1訳注：市町村に相当する最小区分の基礎自治体が設立されていない地域。米国では主に群が管轄する。本稿では、「ロサンゼルスの都市圏の中にあるのに、特定の市には属していない空白地帯」というニュアンスを帯びている。のフリーウェイのランプにいると告げた（実際には近くの公園にいたが、圏外だったため、アプリは最後に位置を確認した地域の中心と推定してしまった）（その2時間は本当に生きた心地がしなかった）。
根底にあるコード――無害なはずのデフォルト設定で不明な位置情報をごまかしているコード――は、絶えず更新し続けなければならない。上流・下流・隣接のプロセスが絶えず変化し続けているからだ。そのコードが放置される時間が長くなるほど、元の動作はますます時代遅れになり、上に重ね塗りされるパッチは複雑怪奇で難解なものになっていく。
コードは資産ではなく負債だ。コンピュータシステムが稼働し続けた年数が長いほど、そこに積み上がる技術的負債も大きくなる。システムの重要性が高いほど、一度停止して完全に作り直すことが難しくなる。代わりに新しいコードの層が次々と塗り重ねられ、その層が接触する箇所ごとに、システムの動作が完全には噛み合わない亀裂が生まれる。さらに厄介なのが、2つの企業が合併するとき、その縫い目だらけ・亀裂だらけのITシステムが一つに叩き合わされ、今度は隣接する技術的負債の源、そして上流・下流の亀裂まで生まれてしまうことだ。
https://pluralistic.net/2024/06/28/dealer-management-software/#antonin-scalia-stole-your-car
大企業がランサムウェア攻撃に対してこれほど脆弱なのもそのためだ。さまざまなデジタル版の接着剤やひも、針金で互換性の「ふり」をさせられた、互換性のないシステムがぎっしり詰まっているからだ。そのシステムは水密ではなく、水密にすることもできない。ハッカーに倒されなくても、時としてシステムは自然に倒れ、二度と立ち上がれなくなる。2022年のクリスマスウィークに サウスウェスト航空 のコンピュータがクラッシュし、何百万もの旅行者が立ち往生したのがまさにそれだ。
https://pluralistic.net/2023/01/16/for-petes-sake/#unfair-and-deceptive
航空業界は特に深刻だ。コンピュータ化が早かったこともあり、旧システムを停止して新しいシステムに置き換えることが永遠にできない。アプリがあれほどポンコツなのも、カスタマーサービス担当者を解雇して乗客にあらゆることをアプリで済ませるよう強いておきながら、そのアプリがまともに機能しないという最悪の状況を生んでいるのも、そのためである。これらのアプリは、決して正常に動作するようにはならない。
ブリティッシュ・エアウェイズ（BA）のアプリが40〜80%の確率で「不明なエラーが発生しました」と表示する理由は、ITスタッフを全員解雇して海外の最安値業者に外注したから（だけ）ではない。確かにそれもあるが、BAの最初のコンピュータは電気機械式の真空管で動作しており、以来すべてのシステムがアラン・チューリングの弟子の1人が自らの前歯で丸太を削り出したとも言えるようなシステムとの後方互換性を維持しなければならないという事情もある。コードは資産ではなく負債だ（BAの新アプリは何年も遅延している）。
コードは負債だ。マイケル・ブルームバーグを億万長者にした Bloomberg端末のサーバーはRISCチップで動作しており、同社は縮小し続ける専門ハードウェアおよびデータセンターベンダーへの依存、専門プログラマーへの報酬、そしてこれらのRISCシステムをより一般的なシステムと接続するための脆い連鎖を構築し続けることを余儀なくされている。コードは資産などではない。
AIはコードを書けるが、ソフトウェアエンジニアリングはできない。ソフトウェアエンジニアリングとは文脈を考え抜くことだ――このシステムの前には何が来るのか？ 後には何が続くのか？ 隣には何が並ぶのか？ 世界はどう変化するのか？ ソフトウェアエンジニアリングには非常に広い「コンテキストウィンドウ」が必要だが、それはAIが持っていない、そして持てないものだ。AIのコンテキストウィンドウは非常に狭く浅く、AIのコンテキストウィンドウを線形に拡張するには、AIが消費する計算資源を指数関数的に増やさなければならない。
https://pluralistic.net/2025/10/29/worker-frightening-machines/#robots-stole-your-jerb-kinda
失敗の可能性を考慮せず、ただ動けばいいコードを書くことは、惨事への道だ。技術的負債を量産する手法であり、我々の技術社会の壁にアスベストを吹き付ける行為にほかならない。
経営者たちはコードが資産ではなく負債であることをまったく理解していない。だからこそ彼らはチャットボットがどんな人間プログラマーよりも1万倍のコードを生み出すことを絶賛し続けるのだ。彼らは人間プログラマーの1万倍の速度で資産を生み出す機械を手に入れたと思っている。だが実際は違う。人間プログラマーの1万倍の速度で負債を生み出す機械を手に入れたのだ。
保守性はただ苦労して経験から落とし穴を学べばいいという話ではない。「フィンガースピッツェンゲフュール［Fingerspitzengefüh］）」――まだ見ぬ落とし穴がどこに潜んでいるかを合理的に推測できる「指先の感覚」――を磨くことも必要だ。これはプロセスの知識の一形態であり、避けがたいものだ。学習データとして用いうる最大規模のコードコーパスの中にも、それは潜在していない。
https://pluralistic.net/2025/09/08/process-knowledge/#dance-monkey-dance
Microsoftを見れば、テック業界の経営者たちがいかにこれを理解していないかがよく分かる。彼らが今賭けているのは「エージェントAI」だ。ユーザのコンピュータにすべてのキーストローク・あらゆる通信・すべての画面をキャプチャしてMicrosoftのクラウドに送信するスパイウェアをインストールし、そのデータに多数のチャットボットがアクセスできるようにすれば、「カーディフ行きの電車を予約して、コリーが去年言っていたホテルを見つけて部屋を予約して」とコンピュータに話しかけるだけで実行してくれる、という構想だ。
これはまったく現実的ではない。そのすべてをこなせるチャットボットなど今のところ存在しないことは、Microsoft自身も認めている。1つのチャットボットで処理するのではなく、Microsoftは何十ものチャットボットに分散させ、それぞれを95%の信頼性に引き上げることを目指しているという。
それ自体、チャットボットの水準としてまったく非現実的な数字だが、さらにこう考えてほしい。確率は乗算される。95%の信頼性で動作するプロセスを2つ含むシステムの実際の信頼性は90.25%（0.95×0.95）だ。数十の95%精度ボットにタスクを分割すれば、そのタスクが正確に完遂される確率はゼロに近い。
さらに悪いことに、Microsoftはトランプ政権にクラウド上のすべてのデータへの秘密アクセスを許可することを公言している。
つまり――Signalのメレディス・ウィテイカーとウドバブ・ティワリが先週ハンブルクで行われた素晴らしい39C3トークで述べていたように――Microsoftは個人・企業のコンピュータ上のあらゆるデータにおいてプライバシーという概念そのものを事実上廃止しようとしており、それもまともに動作しえないAIエージェントを出荷するためにそうしようというわけだ。
https://www.youtube.com/watch?v=0ANECpNdt-4
一方、昨年12月にはあるMicrosoftの幹部がLinkedInに、AIでMicrosoftのコードすべてを書き直すという意図を投稿して問題になった。Microsoftのコードベースのリファクタリング自体は理にかなっている。Microsoftもブリティッシュ・エアウェイズなどのレガシー企業と同様、持続不可能な技術的負債を抱えた非常に古いコードを大量に持っている。ただし、AIを使ってそのコードを書き直せば、時間とともに膨らみ続ける技術的負債を最初から抱えた状態でスタートすることになる。
さて、この記事を読んでいる中には、チャットボットを使ってコードを書くことの驚くべき価値を称賛するソフトウェアエンジニアの声を聞いたことがある人もいるだろう。あるいは、チャットボットがコードを書くのに非常に役立つと感じているソフトウェアエンジニア本人かもしれない。これはAIにまつわるよくあるパラドックスだ。なぜAIを使う人の中に本当に助かると思う人がいる一方で、嫌悪する人もいるのか？ AIを好まない人は「AIの使い方が下手」なのか？ AIを好む人たちは怠惰で仕事の質を気にしていないのか？
確かにどちらも多少はあるだろう。しかし、全員をAIの達人に育て上げ、仕事に誇りを持たない人間をすべてサンプルから取り除いても、このパラドックスは依然として残り続ける。AIパラドックスの真の答えは自動化理論、そして「ケンタウロス」と「逆ケンタウロス」の概念にある。
https://pluralistic.net/2025/09/11/vulgar-thatcherism/#there-is-an-alternative
自動化理論において「ケンタウロス」とは、機械によって補助される人間のことである。そして「逆ケンタウロス」とは、機械を補助するよう徴用された人間のことだ。検証の時間も経験も存分に持ち合わせているソフトウェアエンジニアがルーティンコードをAIに書かせる――フィンガースピッツェンゲフュールとプロセスの知識を発揮して、それが目的に適っているかを確認しながら、いつ・どのように・どのペースでAIを活用するかを自ら選択できる――なら、AIが役立つと感じるのは容易に理解できる。
しかし、以前の10倍、100倍、1万倍の速度でコードを生産するよう命じられ、その手段としてAIしかなく、そのコードを確認して「世界と初めて接触した瞬間に壊れない」ことを人間として確認する方法がまったくないとすれば、そのエンジニアはそれを憎む（AIのミスに対して個人的に責任を負わされるAIのアカウンタビリティ・シンク［責任の受け皿］にされている場合、さらに憎しみは強くなろう）。
https://pluralistic.net/2025/05/27/rancid-vibe-coding/#class-war
AI生成のコードが非常に役立つと感じるもう1つの状況がある。そのコードが孤立している場合だ。ある形式のファイルを別の形式に1回だけ変換するというような単発プロジェクトであれば、下流・上流・隣接のプロセスを気にする必要がない。そもそも存在しないのだから。他のシステムと一切やり取りすることなく、1回きりの処理をするコードを書いているだけだ。コーディングの中には、こうしたユーティリティ的なプロジェクトが非常に多い。退屈で地味な仕事なので、自動化にうってつけだ。個人プロジェクトの多くがこのカテゴリに当てはまるし、定義上、個人プロジェクトはケンタウロス的なプロジェクトだ。個人プロジェクトではAIの使用を強制されることはなく、いつ・どのように個人としてツールを活用するかは常に自分で決められる。
しかし、ソフトウェアエンジニアがAIで一部の仕事を効率化できる場合があるからといって、コードが資産ではなく負債であること、そしてAIのコードが大規模な負債生産を意味するという事実を否定するものではない。
技術的失業論では、新技術が古い仕事を時代遅れにしながら新しい仕事を生み出すという考え方がある。自動車によって仕事を失った鍛冶屋1人につき、自動車整備士という仕事が待っているというわけだ。AIバブルが膨らみ始めてからの数年間、このバリエーションを何度も耳にしてきた。AIは「プロンプトエンジニア」の仕事を生み出す、あるいはAIが世界を一変させるまでは想像もできないような仕事を生み出す、と。
AIによって意識が変容し、新しい仕事の形を概念化できるようになるまでは文字通り想像もできないような、夢想的な職種に就けると期待するのは無謀というものだ。
だがもしAIが確実に大量に生み出す仕事を探しているなら、1つ提案がある。デジタルアスベストの除去業だ。
AIのコード――人間のどんなプログラマーよりも1万倍の速度で書かれ、うまく動くように設計されているが、優雅に失敗するようには設計されていない――が我々が壁に吹き付けているデジタルアスベストだとすれば、我々の子孫は何世代にもわたってそのアスベストの処理に難儀することになる。「コードを書くこと」と「ソフトウェアエンジニアリング」が同じものだという幻覚的な信念、これがAIにまつわる最も危険な狂気だが、それによって我々が壊したものを修復する仕事は山ほどある。このペースが続けば、何世代にもわたるアスベスト除去作業員たちが完全雇用される未来が待っている。
(Image: Cryteria, CC BY 3.0, modified)
Pluralistic: Code is a liability (not an asset) (06 Jan 2026) – Pluralistic: Daily links from Cory Doctorow
Author: Cory Doctorow / Pluralistic (CC BY 4.0)
Publication Date: January 6, 2026
Translation: heatwave_p2p
- 1訳注：市町村に相当する最小区分の基礎自治体が設立されていない地域。米国では主に群が管轄する。本稿では、「ロサンゼルスの都市圏の中にあるのに、特定の市には属していない空白地帯」というニュアンスを帯びている。
