「コーディングは解決済み」という文の主語は誰か
「コーディングは解決済み」という文の主語は誰か
コーディングが解決したかどうかは、モデルの性質なのか。それとも、そのコードに責任を負う人間と、その人間が引き受けられるリスクの性質なのか?
導入
2026年9月28日、Hacker Newsのトップページに「Coding is not solved」という記事が上がり、585ポイントを集めた。筆者は信頼性エンジニアリングとAIシステムについて書いてきたAlex Ewerlöfで、Substackのメタデータ上の公開日は9月26日である。HNのスレッドには筆者本人がhanifbbzというアカウントで現れ、この記事は反AI宣言ではなく、「価格はそのままなのにサービスが劣化していくこと」への疲れの表明だと説明した（直接の引用ではなく、コメントの要旨の要約）。
タイトルだけ見れば見慣れた論争である。このブログでも9月11日にはコーディングモデルのベンチマーク競争を、8月26日にはコードレビューのバグ検出率を扱った。しかしEwerlöfの記事を最後まで読むと、ベンチマークもレビュー精度も中心的な論点ではない。彼が実際に立てる軸は二つだ。一つはリスク許容度（risk tolerance）、もう一つは**説明責任（accountability）**である。彼は、コードを読んで整えるのに費やす時間はリスク許容度の関数であり、リスク許容度は業種だけでなく、規模・結合度・隔離・オブザーバビリティの関数だと書く。
この枠組みを受け入れると、「コーディングは解決したか」という問いはモデルに向かわない。そのコードが壊れたとき誰が呼び出されるのか、その人は何を理解していなければならないのか、という方向に向かう。本稿では、この転換がどこまで有効か、そしてHNの読者がどこで反論したかを見ていく。
「解決した」の定義が分かれる地点
Ewerlöfはまず、コードを読まなくてもよい製品の類型を四つ挙げる。個人用ソフトウェア（かゆいところに手を届かせる自動化やDIYパッチ）、POC（技術的な実現可能性とプロダクトとしての成立可能性の実証）、結果だけを検証する予算しかない使い捨ての自動化、そしてリスクを意図的に標的へ向ける「兵器化されたAI」である。前の三つはリスク許容度が高く、最後のものはリスクそのものを武器にする、というのが彼の整理だ。
反対側には、エンジニアを雇って給料を払うソフトウェアがある。彼は医療、金融、自動車、防衛、発電所、航空、製造を並べ、ミスが金銭や人命や法的帰結につながる場所では責任の所在が必要だと書く。ただし、これは二分法ではないとも付け加える。同じ業種の中でも、利用者が多ければ小さな欠陥が大きな被害になり、密結合は連鎖障害へと広がり、サンドボックスやバルクヘッドのような隔離は被害を閉じ込め、オブザーバビリティが高ければエラーのコストは下がる。
この分類が興味深いのは、「コーディングは解決した」と言う人と「解決していない」と言う人が、別々のマスに立っている可能性を浮かび上がらせるからだ。HNでもすぐに定義論争が始まった。最も短い反応は「コーディングは解決した、ソフトウェアエンジニアリングは違う」というものだった（@federicobrancas、直接の引用ではなく、コメントの要旨の要約）。@lordnachoはより細かく分けた。現在の状態と望む変更が既に分かっている「小さなコーディング」、たとえばブロッキングなTCPハンドラを非同期に書き換えるような作業は解決済みだが、何を誰のために作るかを判断しなければならない「大きな意味でのコーディング」は決して解決しない。LLMはデフォルトの決定を代わりに下してくれるが、そのデフォルトが何だったのかさえ気づかないことがある、と彼はリスクを指摘した（直接の引用ではなく、コメントの要旨の要約）。
Ewerlöf自身もこの区別を予期していた。彼は「コーディングは解決したがエンジニアリングは違う」という主張を「半分タオルを投げたもの」と呼び、良い知らせと悪い知らせを同時に伝える。良い知らせは、フィードバックループのおかげで単純作業のかなりの部分が既に解決したことだ。悪い知らせは、コードが依然として信頼できる唯一の情報源（source of truth）だという点である。コードは何が起きているか、どう動くかを語り、我々が責任を負う対象はまさにそれだ。LLMの説明よりもコードを読む方がはるかにコントロールが効く、というのが彼の結論である。
ここで両陣営の違いがはっきりする。「小さなコーディングは解決した」という側は、コードを生産物として見ている。Ewerlöfはコードを証拠として見ている。生産物であれば、それらしく動けば十分だ。しかし証拠であれば、誰かがそれを読み、法廷であれ障害のポストモーテムであれ、どこかで説明できなければならない。
説明責任は理解を要求するのか — 反論が最も鋭かった場所
記事の中核命題は「理解していないものに責任を負うことはできない」である。EwerlöfはAIは罰を受けられないため説明責任（accountability）を負えず、道具としての役割上の担当（responsibility）しか持てないと区別する。彼はオーナーシップを三本の柱で説明する。何をなぜ解いているかを知る知識、許可を求めずに決定できる権限、そして事が起きたときに呼び出される説明責任だ。三つのうち一つでも欠ければ「壊れたオーナーシップ」になる。だからAIはコードを説明してはくれても、代わりに理解してはくれない、と彼は書く。
HNで最も説得力のあった反論は、まさにこの命題を狙ったものだった。@hibikirは、法体系のあちこちに自分がコントロールできないものについて責任を負う事例があると指摘した。犬を放していて子どもが怪我をすれば、犬の行動を完全には制御できなかったことは免責の理由にならない。したがって、制御しにくいAIが書いたコードについても人間は当然責任を負いうるし、危険なおもちゃを売った者と同じように扱われるだろう、という主張である（直接の引用ではなく、コメントの要旨の要約）。
この反論はEwerlöfの結論を覆すというより、むしろ重くする。理解がなくても責任が成立するなら、人間は理解していないコードについても責任を負うことになる。それは「AIを使っても構わない」という許可ではなく、「AIが作ったものを出荷した瞬間、リスクはあなたに移転する」という警告だ。犬の飼い主の比喩が成り立つのは、飼い主が犬をつないでおく義務を負うからである。ソフトウェアでその綱に当たるのが、テスト、隔離、オブザーバビリティ、そしてレビューだ。
二つ目の軸の反論は、「読むこと」自体を問題にした。最も多くの返信を集めた@efficaxのコメントは、コードを読むことは理解することではなく、長い経験がくれた教訓は自分が一度もコードを理解したことがないということだった、と述べる。その代わりにLLMに、このソフトウェアが動くあらゆる方法を洗い出させ、ファザーとプロパティベーステストを作らせ、フルトレースを記録してシナリオごとにバグを分析させることができる、と主張する。彼は米国のデビットカード取引を処理していたソフトウェアを書いた経験を根拠に挙げ、そうすればコードを一行も読まずに高リスク業種のソフトウェアをより信頼できるものにできると見た（直接の引用ではなく、コメントの要旨の要約）。
返信は割れた。ある利用者は、LLMが問題を解決したと自信満々に宣言したり、機能を誤って説明したりすることがよくあり、人間との違いはその根拠のない確信だと警戒した（@grumple、直接の引用ではなく、コメントの要旨の要約）。別の利用者は、高リスク業種はもともと広範なテストに依存してきたのであり、人間のレビューはその上に載った一つの層にすぎず、最も重要な層ではなかったとして@efficax側に立った（@pu_pe、直接の引用ではなく、コメントの要旨の要約）。
このやり取りが示すのは、「コードを読むべきか」という問いが、実は「理解を何で代替できるのか」という問いだということだ。Ewerlöfはコードを読むことを、@efficaxは体系的な検証を、理解の代替物として提示する。二人とも理解を放棄しようとは言っていない。違うのは理解の証拠をどこに置くかである。そしてここで、Ewerlöfが別の箇所で挙げた指摘が再び意味を持つ。彼は、レビュー不能なほど巨大なPRが「信頼」でマージされる古い手口を皮肉った。検証をLLMに任せる道も、その検証結果を人間が読める大きさに保つときにだけ、理解の代替物になる。
リスク許容度、SLA、そしてデータなき論争
この記事で最も注目されなかったが、実務的に最も役に立つのは経済を扱った節だ。Ewerlöfは一つの仮定を置く。AIが書いたコードが品質面で二倍悪くても、人間より1000倍速く100倍安いなら、多くのタスクでは遅くて高い人間を投入する経済的な根拠がない。「遅いことは速いこと」という原則は、リスク許容度の低いクリティカルなソフトウェアでしか正当化されない、というのだ。これらの数字は測定値ではなく思考実験の仮定である点は明確にしておく。
ここで彼は、SaaS企業がますます「SLAを売るビジネス」になりつつあると診断する。今やAIにSaaS製品を複製させることはできる。しかしその複製品が壊れたとき、多くの企業は自前で原因を探すことにリソースを割くより、ベンダーに電話することを望む。そしてAIが引き起こした障害は、別のモデルを使ってもAIには直しにくいことが多い。規模の経済のおかげで、SaaS企業は高い品質と保証のコストを多くの顧客に分散できる。彼の処方は単純だ。欲しいものがあまりに独特で、妥当な価格で提供するところがないならプロンプトで作ればよい。ただしTCO（総所有コスト）と保証の不在を承知の上で。それが本業でないならSLAを買え。
この論理は冒頭のリスク許容度の枠組みと正確に噛み合う。「コーディングは解決した」と感じる体験の多くは、リスク許容度の高いマス、つまり個人ツールやPOCから生まれる。そのマスでは生成コストの低下がそのまま価値になる。一方、リスク許容度の低いマスでは価値は生成ではなく保証にあり、保証は誰かが障害時に呼び出されうるときにだけ成立する。同じモデル、同じ出力であっても、どのマスに置かれるかで「解決した」の真理値が変わる。
HNでは、このマス分け自体への反論もあった。@Seviiは、エンジニアを雇うソフトウェアの大半はリスク許容度が低いという前提は誤りで、ほとんどのエンジニアはリスク許容度の低いコードを扱っていないと反論した。@giovannibonettiはヘルステックで働いた経験から、医療分野は遅くてバグだらけのUIで利用者が毎月何時間も無駄にしても許容されるほど、技術品質に寛容だったと書いた。@thesumofallは、エンタープライズソフトウェアの9割は退屈で単純であり、一夜漬けの作業と管理の行き届かない下請けと質の低い要件から生まれたにもかかわらず、大半は24時間問題なく動いていると指摘した（三つのコメントとも直接の引用ではなく、コメントの要旨の要約）。
これらの反論はEwerlöfの枠組みを崩さない。むしろ、その枠組みがちょうどどこで争われているのかを示している。業界の大多数がリスク許容度の高いマスにいるなら、「コーディングは解決した」という言葉はその大多数にとって事実に近い。ならば論争は「解決したか」ではなく、「あなたのソフトウェアはどのマスにいるのか」へ移るべきだ。そしてその問いへの答えは、しばしば正直ではない。ヘルステックの例のように、組織が実際に許容しているリスクと名目上のリスク水準が食い違うことがあるからだ。
公平を期せば、この記事の弱点も明らかである。@Marha01は、これほど確信に満ちた主張をするなら、人間が書いたコードとAIが書いたコードのバグ密度を比較し、その推移を示すような硬いデータが必要なのに、この記事は雰囲気だけだと批判した。「コーディングとソフトウェアエンジニアリングを混同するな」という指摘は妥当だが、残りは愚痴に近い、という評である（直接の引用ではなく、コメントの要旨の要約）。@armchairhackerは結論には同意しつつも、LLMが確率的であることは愚かであることを意味しないし、記事が挙げた特異な失敗例の一部は既に数か月前に直っていると指摘した（直接の引用ではなく、コメントの要旨の要約）。
記事の中で数字による証拠は少ない。比較的具体的なのは筆者自身の実験だ。彼はエージェントにパッチリリースだけのnpm依存5件を更新させたところ12分と72ステップかかり、自分なら1分以内でできたと書く。一つの逸話にすぎないが、方向には意味がある。作業のリスクが低く範囲が明確な場合でさえ、エージェントの「過程のコスト」が人間より大きくなりうるということだ。ただし、これを一般化するにははるかに多くの測定が必要である。
時間軸からの反論もあった。@temp00345は、この記事が1年前なら100パーセント、9か月前なら75パーセント、3か月前なら50パーセント正しかっただろうが、今は25パーセント以下だと評価した。30年以上のプログラミング経験が急速に陳腐化していく事実を受け入れられず眠れないと打ち明けながら、最新モデルに大きなタスクを任せ、出てきたコードを自分で読んでみるよう勧めた（直接の引用ではなく、コメントの要旨の要約）。EwerlöfはS字カーブを持ち出してこうした外挿を戒める。能力は上がるが収穫逓減があり、より高価なモデルが価格の上昇ほど生産的ではない地点が来る、というのだ。どちらが正しいかは、現時点でこのブログが判定できる問題ではない。
それでも、リスク許容度と説明責任という枠組みはモデル性能の推移とは無関係に維持されるという点が重要だ。モデルが1年後に二倍良くなっても、障害時に呼び出される人がそのシステムを説明できなければならないという要求は残る。@vmg12の指摘がこの点を補強する。AIはCRUDエンドポイントやデータ構造の実装はほぼ完璧にこなすが、システムがどう進化するかを見通した型やAPIの設計には弱い。その能力を育てる強化学習環境を作るには、まず大規模なソフトウェアを作り、それを進化可能な形に分解しなければならないため、時間がかかるだろうという観測である（直接の引用ではなく、コメントの要旨の要約）。言い換えれば、現在のモデルが得意な領域は正解を機械的に確認しやすい領域であり、そうでない領域ほど人間の理解が証拠として求められる。
結論
「コーディングは解決した」という文には、省略された主語がある。誰にとって、どのリスク水準で、障害時に誰が呼び出されるという条件のもとで解決したのか。Ewerlöfの記事がこれまでの数多くの「AIはまだまだ」系の記事と違うのは、この省略された主語を、リスク許容度と説明責任という二つの変数で復元しようとした点にある。個人ツールやPOCのマスでは既に解決しているかもしれない。医療や航空のマスでは、解決という言葉自体が「誰が責任を負うのか」と切り離せない。
HNの優れた反論の数々は、この枠組みを壊さず、より精密にした。説明責任は理解がなくても成立するので、リスクはむしろ人間により重く移転する。理解はコードを読むことだけでなく体系的な検証でも代替できるが、それはその検証結果が人間の読める大きさであるときに限られる。そして業界の大多数は、思っているよりリスク許容度の高いマスにいる。
あなたのチームのソフトウェアはどのマスにいるだろうか。名目上のマスではなく、前回の障害で実際に許容された被害の大きさが語るマスのことだ。そしてそのマスでAIが書いたコードが壊れたとき、呼び出される人は今、そのコードを何によって理解しているのだろうか。
出典: