Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — 問いを立て直す
メカニズム — ボトルネックは消えずに移動する
減価するスキル — もともと価値ではなく代理指標だったもの
増価するスキル (1) — 検証:差分を眺める目ではなく、正解を供給する力
増価するスキル (2) — 本番のデバッグ:文脈が暗黙であるとき
増価するスキル (3) — システム設計とトレードオフの趣味
増価するスキル (4) — 要件考古学:何を作るかを知る仕事
増価するスキル (5) — オーナーシップ:ポケベルを持てる存在であること
反論 — 「検証も結局AIがやるのでは」
おわりに
参考資料

はじめに — 問いを立て直す

「AIは開発者を置き換えるのか」は、立て方を誤った問いです。この問いは開発者を一つのスキルとして扱っています。実際の開発者は十数個のスキルの束であり、その束の項目は今 それぞれ異なる速度で再価格づけされている最中 です。ゼロに収束する項目もあれば、上がる項目もあります。

だから本来の問いはこうです — 束の中で安くなるのはどれで、その価値はどこへ行くのか。これは趣味の問題ではなく、かなり退屈な経済学の問題であり、答えの骨格はすでに出ています。

メカニズム — ボトルネックは消えずに移動する

ある工程が安く豊富になっても、ボトルネックは消滅しません。次の工程へ移動します。そして価値はボトルネックのある場所に貼りつきます。生成が安くなれば、価値は生成の次の段階へ行きます — それが正しいかを確かめる仕事、何を作るかを決める仕事、他人のシステムに組み込む仕事へ。

この直観をAI側で最も鋭く研いだのが Jason Wei です。彼の言う 検証の非対称性(asymmetry of verification) は単純です — ある種の課題は、解くより確かめるほうがはるかに簡単だということ。数独を解くのには時間がかかりますが、埋まった盤面が正しいかは即座にわかります。ここから彼は 検証者の法則(verifier's law) を導きます — 「AIにある課題を解かせる訓練の容易さは、その課題の検証可能性に比例する」。もっと切れ味よく言えば、解くことが可能で、かつ検証が容易な課題は、いずれすべてAIが解く ということです。

多くの人はこの法則を「AIが得意になる仕事のリスト」として読みます。しかし逆から読むほうがはるかに重要です。検証が容易な仕事が自動化されるなら、人間に残るのは、まさに検証が高価か、遅いか、主観的か、そもそも正解表が存在しない仕事 です。これは慰めではなく予測です。

そしてボトルネックは、実際にもう動いています。

DORA 2025 は技術職の約90%がAIを使っていると報告します。ただし結論が奇妙です — AI導入はスループットとの関係が正に転じた一方で、デプロイの不安定性は上がり続けています。 DORA自身の要約は、AIは組織の既存の強みと弱みをともに増幅する アンプ だというものです。速度だけ上げて品質統制を上げなければ、ボトルネックは単に下流へ押し出されます。
LinearB の2026年ベンチマーク は、その下流がどこなのかを数字で示します。4,800を超える組織の810万件のPRを分析したところ、AIが生成したPRはレビューを4.6倍長く待ちます。 エージェントが開いたPRのピックアップ時間は5.3倍です。マージ率は 32.7%対84.4% と、人間が書いたコードに遠く及びません。生成が爆発した場所で、レビューの前に行列ができた のです。
その行列がなぜ捌けないのかは Stack Overflow 2025 が説明します。開発者の84%がAIツールを使うか使う予定で、半数以上が毎日使っています。それでいて不満の第1位が 「ほぼ正しいが、完全には正しくないAIの解」(66%) 、第2位が 「AIが生成したコードのデバッグに時間がかかる」(45.2%) です。出力の正確性を高く信頼していると答えたのはわずか3.1%でした。

この最後の項目が、この記事全体の蝶番です。ほぼ正しいコードは、間違ったコードより高くつきます。 間違ったコードは即座に弾かれます。ほぼ正しいコードは一瞥を通過し、レビューを通過し、ステージングを通過して、本番で爆発します。生成が安くなるほど、これがより多く、より速く流れ込みます。検証コストは生成量に比例して増えますが、検証能力はそうではありません。

減価するスキル — もともと価値ではなく代理指標だったもの

正直に名前をつけます。

暗記したフレームワークAPI。 モデルはあなたより正確に、そして全部ドキュメントを読んでいます。シグネチャを覚えていることに付いていたプレミアムは消えました。
ボイラープレートのスループット。 CRUDの雛形、DTO変換、設定ファイル、テストフィクスチャ — 分あたり生産量で競っていた領域です。
「自分は速く打てる」型の生産性。 タイピング速度が本当にボトルネックだったことは一度もありませんが、それでも値がついた時代はありました。

肝心なのはここです — これらのスキルは もともと価値そのものではなく、価値の代理指標(proxy) でした。生成がボトルネックだった時代に希少だったから値がついただけです。希少性が消えれば値も消えます。

ただし減価と無用は違います。読めないコードはレビューできません。 言語も知らずフレームワークも知らなければ、以下で述べる増価スキルは一つも始まりません。土台は依然として必要です。ただ土台はもはや 入場料であって、優位性ではありません。

増価するスキル (1) — 検証:差分を眺める目ではなく、正解を供給する力

まず誤解を取り除きましょう。増価する検証能力とは「差分を丁寧に読む勤勉さ」ではありません。それは機械がすでにかなりの部分やっています。リンター、型チェッカー、静的解析、AIレビューボット — nullチェック漏れや明白な競合状態は検証が容易な側に属し、検証者の法則に従って その側は自動化され続けます。

値が上がるのは、機械が供給できない側です — 正解表(ground truth)そのもの。 このシステムで、この事業で、この規模で「正しい」が何を意味するのかを 決める仕事 です。モデルはテストを通すことはできますが、どのテストが存在すべきかは決められません。それはコードの事実ではなく、事業の事実だからです。

意図的に鍛える方法:

モデルがコードを書く前に、合格条件を先に書く。 合格条件を文にできないなら、それは要件ではなく願望です。
仮説を持ってレビューする。 差分を開く前に「この変更が本番を壊しうる経路を三つ」書き出し、それを狩りに行く。仮説なきレビューは誤字チェックです。
バグ台帳をつける。 本番バグごとに「どんな検証があればこれを捕まえられたか」を一行で書く。その一覧が、あなたに欠けているテストです。
「テストが通る」と「正しい」を区別する訓練をする。 評価の設計はそれ自体が一つのスキルであり、AIコーディングモデルの評価で信号とノイズを見分けるで扱った問題とまったく同じ問題です — ノイズより大きい差だけが信号です。

増価するスキル (2) — 本番のデバッグ:文脈が暗黙であるとき

ここでは METR のランダム化比較試験が最も役に立ちます。熟練のオープンソース開発者16名が、自分のリポジトリ(平均スター2万以上、100万行超)で実際のイシュー246件を処理しました。開始前、彼らは24%速くなると予想しました。終了後、20%速くなったと 感じました。 実際には 19%遅くなっていました。

理由が決定的です。長年触ってきた成熟したリポジトリは、AIにとって最悪に近い条件です — 要件がリポジトリの外にある文脈と絡み合っており、人間の側には どこにも書かれていない膨大なローカル知識 が蓄積しているからです。モデルにはそれがありません。

これが堀の形です。AIは、文脈が暗黙で、失敗が創発的な場所で最も弱い。 本番はまさにそういう場所です。バグは差分の中にはありません。差分と、誰も書き残さなかった6年分の決定との相互作用の中にあります。

自分の経験から言えば — KubeVirt GPUパススルーVMが112日間スケジュールされなかった剖検で、原因はリポジトリの中にありませんでした。リポジトリだけを読む何ものも、それを見つけられなかったはずです。CloudNativePGでPostgresを立ち上げて殺してみた記録も同じです — フェイルオーバーが実際に何をするのかは、読んで知るのではなく、プライマリを殺して23秒を測って知るのです。

意図的に鍛える方法:

障害を最後まで所有し、ポストモーテムを自分で書く。 学びは消火活動ではなく、書くことのほうに宿ります。
安全な場所で、わざと壊す。 プライマリを殺す。ディスクを埋める。ネットワークを切る。先に結果を予測してから、測る。 予測と測定の差こそが、あなたの持つシステム模型の誤差であり、会社が金を払っている対象はその模型です。
コードではなくシステムを読む訓練。 メトリクス、トレース、カーネルログ、イベント。観察 → 仮説 → 実験のループを体に入れる。
自分が書いていないコードをデバッグする。 これがこれからの既定値です。コードはモデルが書き、責任はあなたにあります。

増価するスキル (3) — システム設計とトレードオフの趣味

モデルはどんな設計上の問いにも、もっともらしい答えを出します。できないのは、あなたの組織が今後5年間耐えられるトレードオフはどちらかを選ぶこと です。その判断はリポジトリにない事実に依存しているからです — チーム規模、オンコールの成熟度、払えない移行コスト、期限切れが近いベンダー契約、半年後に辞める人。

趣味(taste)は神秘的なものではありません。前回何が爆発したかについての、圧縮された記憶 です。自分が引き受けた結果から作られた事前確率にすぎません。

意図的に鍛える方法: 他人のポストモーテムを読む(公開されたものが山ほどあります)。設計文書ごとに 何を諦めるのか を明示的に書く。却下した代替案を最低二つ、却下した理由とともに書く。そして12か月後に自分の決定を開き直して採点する — このフィードバックがなければ、育つのは趣味ではなく頑固さだけです。

ルールを一つ — 却下された代替案のない設計文書は、設計ではなく好みです。

増価するスキル (4) — 要件考古学:何を作るかを知る仕事

最も高価なバグは 完璧に実装された、見当違いのもの です。AIは作るコストを下げます。それは同時に、見当違いのものを、はるかに速く、はるかに大量に作れるようになった ということでもあります。だから何を作るかを知る能力は、作るコストが安くなる分だけ正確に比例して増価します。

要件考古学とは、人々が口にしたことの中から、実際に必要なものを発掘する作業です。本物の要件のほとんどはどこにも書かれていません。誰も消せない2019年のif文の中に、奇妙な例外処理の中に、置き換えようとしている旧システムの既定値の中に、化石のように埋まっています。

この曖昧さを扱うこと自体が職務である役割もあります — Forward Deployed Engineer を目指す記事で整理したとおり、そこでは曖昧さは副作用ではなく業務そのものです。

意図的に鍛える方法: ユーザーの隣に座り、実際にやっていることを見る(言うこととは違います)。「これが失敗したら、次に何をしますか」と訊く — 本当の要件はたいていその答えの中にあります。コードベースで最も醜い分岐を選び、なぜ存在するのかを最後まで掘る(たいてい間違いではなく要件です)。設計文書の前に 1ページの問題定義 を書く。そして間違えるなら、早く、安く、声に出して間違える。

増価するスキル (5) — オーナーシップ:ポケベルを持てる存在であること

モデルにポケベルを持たせることはできません。賢さが足りないからではなく、責任は結果を引き受ける主体を要求するから です。組織は決定に名前が付くことを望みます。午前3時に起きて「これは自分がロールバックする」と言う人間が要ります。

ここは正直であるべきです。これは 能力の事実というより、社会的・法的な事実 です。制度はいずれ変わるかもしれません。ただ社会的事実は粘り強く、実際に労働に値段をつけます。

コミュニケーションもここに属します。コードを読めない相手にトレードオフを説明できなければ、決定を通すことはできません。生成が安くなるほど希少になる行為は 決めること であり、決めることは本質的に社会的な行為です。

意図的に鍛える方法: ポケベルを受け取る。誰もやりたがらない移行に手を挙げる。何かを出荷し、1年間それに張り付く。 結果が自分にまで届くフィードバックループ — 判断力が育つ場所はそこだけです。

反論 — 「検証も結局AIがやるのでは」

この反論は真剣に扱う価値があります。弱い形に仕立てて勝つのは自己欺瞞です。

最も強い形はこうです。検証者の法則は 検証が容易なものはすべてAIが取る と言っており、レビューのかなりの部分は検証が容易です。型エラー、null参照、明白な競合状態、スタイル — AIレビューツールはすでにこれを上手にこなします。テスト生成、ファジング、実際にコードを走らせて観測するエージェントまで加われば、検証の相当部分は自動化されます。さらに、上で引いた METR の結果でさえ METR自身が但し書きを付けました — 2026年2月の更新で彼らは実験設計を変更すると表明し、2026年初頭の時点では開発者は初期推定より さらに速くなっている可能性が高い と述べています(ただしその大きさについての証拠は弱いと認めています)。だから「19%遅くなる」を永久法則のように持ち歩いてはいけません。あれは一時点の測定です。

ここまでは認めます。機械的な検証は自動化されるでしょうし、おおむね自動化されたほうがよい。 あなたの「検証能力」がnullチェック漏れを見つけることなら、それも一緒に減価します。

それでも残る境界があります。正しさの検証には 照合すべき正解表 が要ります。その正解表はどこから来るのか。数学やアルゴリズム問題には解答があります。あなたの会社の精算システムにはありません。誰かが「正しい」とは何かを決めなければならない。

この境界が実在することの最もきれいな証拠が DeepMind の結果です — 外部フィードバックなしにモデルが自分の答えを直す 内在的自己修正 は、精度を上げませんでしたし、むしろ下げることさえありました。改善が現れたのは、正解ラベル(オラクル)を渡したときだけでした。これは2023年当時のモデルによる結果で、その後モデルは大きく良くなりました — 具体的な数値を今日にそのまま当てはめてはいけません。しかし 構造的な論点はモデル性能の関数ではありません。 自分の信念を自分の信念で検査するシステムは、持っていない正解表を作り出すことはできないのです。

ここで不確実性を正直に印します。私は この境界がどこまで押し戻されるか知りません。 もしモデルが、あなたの事業において「正しい」が何かを、あなたより上手に決められるようになれば、この記事の助言は失効します。私はそれが近いとは思いません — 制約は知能ではなく 結果へのアクセス だと考えるからです。しかし「そう思わない」は証拠ではなく信念です。緩く握ってください。

賭けるなら、こちらに賭けます — AIが大半を検証する世界でも、その判定に責任を負う誰かは依然として必要であり、責任こそが職業の定義です。

おわりに

両極を拒否しましょう。

「開発者は終わった」は誤りです。束の全体がゼロに再価格づけされたと仮定していますが、実際には 不均等に 再価格づけされただけです。「何も変わっていない」も誤りです。多くの人がキャリアを築いた項目こそ、まさに安くなった項目だからです。

居心地の悪い部分も残しておきます。この再価格づけはジュニアに特に厳しい。減価するスキルは、これまで 梯子の下の段 だったからです — ボイラープレートを打ちながらコードベースを覚えるという道が塞がりつつあります。私はここに綺麗な答えを持っていません。せいぜい言えるのは 結果により速く近づくこと です。小さくてもいいから本番で何かを所有し、それが壊れたときに呼び出される場所に、居心地が悪いくらい早く立つこと。

増価するスキルは、一つの性質を共有しています。すべてが 結果との接触 を要求します。検証は何が爆発するのかを知っていなければならず、デバッグは呼び出された経験を要し、趣味は間違えた経験からしか生まれません。だからこれらはダウンロードできません。そして同じ理由で、一度も呼び出されたことのないモデルに学習させるのは、まだ難しいのです。

一行にまとめるなら — コードを書く値段は下がり、コードが正しいかを知る値段は上がりました。