**階段に足場が欠けている―AI が中間を食べたときのエンジニアリング進化**

トランスクリプト – QCon London、2026年3月17日

---

AIはエンジニアリングキャリアの最初の10年間にあたるタスクをほぼ完璧に近づけており、そのタスクは単なる作業ではありませんでした。 それらは判断力・直感・今やAIに委譲しているシステムを監督する能力を構築したメカニズムだったのです。 ラダー（キャリア階段）は、ただ足場が欠けているだけでなく、人々を育成しラダーを作り上げたプロセス自体が失われています。

昨年ニューヨークで開催された会議で、強化学習から人間のフィードバック（RLHF）の共同発明者でAnthropicの共同創業者でもあるダリオ・アモーディは、AIが90％のコードを書き始めるまでに3〜6か月、12か月以内にはほぼすべてを執筆すると予測しました。 6か月目になったとき、アモーディは「90％という数字は絶対に正しい」と主張し、少なくともAnthropic内ではその検証が成立したと言いました。

---

第I幕：予測の消滅

12か月後、ほぼ同じ日。 実際にはそれほど単純な現象ではありませんでした。

Redwood Research の詳細分析は、90％という数字が誤解を招くものであると結論づけました。 リポジトリにコミットされたコードのみを数えると、その割合は約50％でした。 それでも衝撃的な数字です。 この数値は「捨てるスクリプト」「一回限りの探索」や、すべての AI が生成したテキスト（短期的に有用だったもの）を含めたときに90％になるだけです。一方で Google は社内コードの25％程度が AI によって生成されると報告し、Microsoft は約30％、GitHub Copilot は企業ユーザーからの提案受け入れ率が約30％です。

これらの数字は過去6か月間ほぼ変わりません。 「実質的にすべて」という主張には到底届きません。

しかし AI は多くのコードを書いています。 開発者という職務の風景は大きく変化しました。 アモーディも嘘をついているわけではなく、Anthropic の内部データはエンジニアが Claude を 59％ の日常業務で使用し、50％ の生産性向上を報告していると示しています。 公開 GitHub コミットの約4％は Claude Code によって作成されています。 ツールは実在します。 生産性も確かに高まっていますが、特定の状況下でのみです。

問題は「コードを書く」こと自体ではなく、「何をすべきか」という議論にあります。 今多くの人々が語っているのは AI がコードを書いているという話ですが、本来私たちが行うべき会話は、ソフトウェアエンジニアがコードを書く必要がない時代におけるソフトウェア工学の姿についてです。その背後にはもう一つ重要な問題があります。 それは構造的質問であり、両側が無視している議論です。 AI がエンジニアを育てた作業を担う場合、次世代のエンジニアはどこから来るのでしょうか。

アモーディ自身の警告はこの点を示しています。 彼はプログラマが全体設計、コード間の協働方法、および設計が安全であるかどうかを指定する必要があると述べました。 彼は「書くこと」と「工学」を分離しました。しかし3〜6か月前まで、書くことこそがエンジニアリングを学ぶ手段でした。

昨年7月、Reuters の見出しは世界中のエンジニア Slack チャンネルに拡散されました。 「AI は経験豊富なソフトウェア開発者の速度を遅くする研究結果」 という内容です。 私が元ジャーナリストとしては最もキャッチーではないかもしれませんが、確かに注目を集めました。

METR のランダム化比較試験（RCT） は経験豊富な開発者が AI ツールを使用するとタスク完了時間が 19％長くなることを示しました。 （出典：metr.org）

この METR の研究は、ベンダー調査ではなく真のランダム化比較試験です。 予測としては AI が 24％速くなると考えていましたが、実際に完了した後も 20％速いと信じていました。 観測された差は43ポイントでした。この見出しだけでも AI に関する物語を挑戦します。

しかしその後何が起こったかが本講演の鍵です。

今年2月、METR はフォローアップ調査を試みましたが失敗しました。 方法論が失敗したわけではなく、開発者たちが AI なしで作業することを拒否したためです。 開発者の増える割合は、AI を使わずにタスクの半分を完了させる調査には参加しないと告げました。 この研究は「効果が消えた」ではなく、「依存関係が制御できないほど深くなった」という理由で測定不能になりました。 1年以内に「AI が経験豊富な開発者を遅くするが彼らは気づかない」から「開発者は AI なしで作業を試みない」に移行しました。 ツールはオプションから負荷を担うものへ変わり、誰もそれが実際に何をしているのか理解しませんでした。

最近の AI コーディングの改善は主に使いやすさのブレークスルーによるものです。 ただし大部分はモデル自体ではなく、エージェントループやリンター・テストランナーからの構造化フィードバック、単発生成ではなく反復可能な仕組みなどツールとアーキテクチャにあります。 モデルは少し改善しましたが、スキャフォールドが大幅に向上しています。 私たちが目撃したほぼすべての利益は「より密接なフィードバックループ」に起因します。 アーキテクチャであり、インテリジェンスではありません。

過去1年間、私はスケールアップ企業で仮想 CTO を務めました。 採用に多く関わっています。 現在採用を行っている人は、印象的なポートフォリオが質問時に崩れたり、面接中に AI 拡張を明らかに依存しているケースを目の当たりにしています。「これを書いた」という発言は「このプロンプトを作った」と同じ意味です。 ただし必ずしもそうではなく、一部の人は真剣に学んでいます。しかしシグナルはノイズが多く、実際に何を理解しているか判別することが難しくなっています。 これが私を「階段」に本当に心配させた理由です。 キャリア進歩について。

---

第II幕：データ

私は真の研究を探しました。 ベンダー調査やブログ投稿、LinkedIn のホットトピックではありません。 統計的に有意な結果を持つ本物のデータです。 想像よりも見つけるのが難しく、実際にそれを行う人は少ないでしょう。

METR の時間軸ベンチマーク はタスク完了能力が 4〜7か月ごとに倍増すると示しています。 （出典：metr.org）

METR は「50％ タスク完了時間限界」をベンチマークし、 AI エージェントが 50％ の信頼性で完了できる人間調整タスクの長さを測定しました。 主な発見は、AI が自律的に扱えるタスクの長さが 2019 年以来約7か月ごとに倍増し、2024 年以降は約4か月ごとに加速しているというものです。

成功確率は約1時間人間相当タスク後で急激に低下する。 （出典：metr.org）

しかしキャリア階段が崩れるのは成功率の落ち込みです。 ここでは Claude Sonnet の3モデルを用いて、人間タスク期間に対する成功確率をプロットしています。 曲線は約1時間で急激に下がります。 初級者が1年目に行うタスクの曲線はほぼ100％、数年経験によって構築された判断力が必要なタスクではほぼ0％です。

4分未満の小さなバグ修正や定型コード、単純実装など AI はほぼ 100％ の成功で処理できます。 約1時間かかるタスクでは AI の成功率は約50％です。 4時間を超えるタスクでは10％以下です。

ただしベンチマークスコアは実世界の能力を過大評価します。 METR 自身の「マージ可能性」研究は、テストに合格した AI が生成した PR の約50％がリポジトリ管理者によって実際にはマージされないことを示しています。 成熟オープンソースプロジェクトから 18 件の実務タスクで Claude 3.7 Sonnet はテストケースに 38％ 合格しましたが、15 件のレビューされた PR の中でマージ可能なものはゼロでした。 すべての PR にドキュメント不足、テストカバレッジ不十分、リンティング違反、コード品質問題という少なくとも3つのカテゴリの欠陥がありました。 AI が生成した PR をマージ可能状態にする平均時間は42分で、元タスク全体の人間時間の約1/3です。 AI はコア機能を実装できますが、一貫してクラフトを失敗します。

---

第III幕：人的コスト

データだけではすべてが説明できません。 先日 LinkedIn に「25 年経験のシニアエンジニア」が投稿した内容は、データが語らないことを示しています。

「コードを書いた手は休息している。 見た目が良いものを知る眼はかつてなく必要とされている。」 — Eli Finer

AI ツールに抵抗するエンジニアチームのリーダーであれば、実際に何が起きているか考えてください。 彼らの職業的アイデンティティは急速に価値を失うスキルに基づいています。「設計と構築はまだ必要だ」という標準的な保証は、90％ が不要になった経験に対して受け入れられません。 アーキテクチャについて数語言えば、ほとんどが跳ね返ります。

しかしこのベテランが持つパターン認識やシステム構造の仕方、複雑性の潜在的箇所、スケールで何が壊れるかという知見は、従来通りに取得できなくなっています。 若手エンジニアは数年間レガシーコードベースを読んだり、深夜に本番障害をデバッグしたりしません。 ソフトウェアの実際の挙動についての深い直感は、今や「クラフト」時代を経験した少数派の間でしか得られないものになっています。

AI への高採用率チームは21％タスク完了増加だが PR レビュー時間は91％増。 （出典：Faros AI Productivity Paradox Report 2025）

10,000 人の開発者、1,200 チームから収集したテレメトリを分析した Faros の報告書は、高AI採用率チームが21％ タスク完了増加と98％ PR マージ増加を実現していることを示しています。 しかし PR レビュー時間は91％ 増、開発者あたりのバグ数は9％ 上昇、平均 PR サイズは154％ 増大します。

ボトルネックは消えません；それはコードレビューに移行し、正確にはシニア判断が存在する場所へと移ります。 私たちは多くの高プロファイルオープンソースプロジェクトで AI が生成した PR を完全に禁止しているケースを見てきました。 その急増は「AI スロップ」と呼ばれる低品質提出物の問題です。

シニア・スタッフ以上エンジニアが最も時間節約するが、採用率は最低。 （出典：DX AI‑Assisted Engineering Q4 Impact Report 2025）

DX の報告書（20,000 人の開発者を対象）は、経験豊富なシニアエンジニアが日常的に AI を使用し、最も時間を節約していること（週あたり 4.4 時間）を示しています。 DX が調査したサンプルは、より広範囲の開発者で構成されており、グリーンフィールド、未知コードベース、定型作業など全体的なワークロードを網羅しています。

METR の研究と DX の研究が何故異なるかという質問に対しては、 METR が 16 人の経験豊富開発者を観察し、AI が彼らを19％遅くしたことを示す一方で、DX は広範囲なサンプルを調査しシニアが最も時間節約していると報告しています。 両方とも同時に真実である可能性があります。その事実自体が問題です。 ツールの有効性さえ測れないなら、利用者が学んでいるかどうかを知ることは不可能です。

METR は経験豊富な開発者が深く慣れ親しんだコードベースで作業しました。 彼らのスキルセットは既に最適化されていました。 DX のデータは、全週を通じた広範囲サンプル（グリーンフィールド、新規開発、ドキュメントなど）をカバーしています。 AI はいくつかの作業で時間を節約しますが、それらは METR が注目した「経験豊富な専門家が慣れ親しんだ複雑なコードベース」ではなく、短く明確に定義されたタスクです。

Anthropic のエンジニアはリアルタイムでこの点を語ります。 あるシニアは AI を「答えが分かっている／見た目でわかるケースで主に使用する」と述べ、ソフトウェア工学を「やり方がハード」で習得したと指摘しました。 もし彼らがキャリアの早い段階であれば、 AI 出力を盲目的に受け入れることを避けるためには意図的な努力が必要でした。 別のエンジニアは「AI の出力は危険なほど賢い」と評し、非常に才能ある新人が提案するものと同じように認識できる問題だと述べました。

Anthropic は Claude に対して 80〜90％ の質問を行っていると報告しています。 シニアの一人は「若手が自分たちに質問しないことが悲しい」と言い、しかし「確実により効果的に回答できている」と述べました。 長年業界で働いた者にとって驚くべき点は、シニアエンジニアが人と共に作業するのを楽しみ、今ではその必要性が減ったことです。 人間との相互作用から得られる偶発的学習（デバッグセッションでメンターと苦闘しながらシステムを理解する）は、 AI が答えを提供することでバイパスされます。

---

第IV幕：ケーススタディ

最近の問題は、非常にエレガントなケーススタディを示しています。 それは Amazon のインシデントです。

2025年12月中旬、AWS エンジニアは Amazon の Kiro AI コーディングツールが AWS Cost Explorer を変更できるようにしました。 オペレーター権限を持つ AI エージェントは「環境全体を削除して再構築する」ことが最善策だと判断し、2 つの中国リージョンでコストエクスプローラーを復旧するために13時間かかりました。 Amazon はこれを「ユーザー エラー—具体的にはアクセス権限の誤設定」と呼びました。

しかし後日、4 件の別々の情報源が Financial Times に Kiro が自律的に決定したと報じました。

「漏れた蛇口を修理するために壁を壊すソフトウェア相当」 — Lukasz Olejnik

人間エンジニアは「環境を削除して再構築する」という応答が設定変更への合理的な対処ではないと知っています。 それは、失敗例を目にし、プロダクション障害を経験し、顧客向けシステムで状態を消去しないという暗黙のルールを吸収した結果です。 AI は権限を持っていましたが、戦闘傷痕（バトルスカル）を欠いています。

その後 Amazon の小売サイトで一連の障害が発生しました。 3 月 5 日に約22,000 人が報告し、 Financial Times と CNBC は「GenAI アシスト変更」が寄与要因として特定され、「高い爆弾半径」と「ベストプラクティスや保護策がまだ確立されていない新しい GenAI 使用」 というトレンドを報告しました。 3 月 10 日に SVP の Dave Treadwell は「今週の店舗技術（TWiST）」会議を必須化し、メールは「サイトと関連インフラの可用性が最近良くない」と始まりました。その後 Amazon は新しい承認要件を導入したと報じられ、 junior や mid‑level エンジニアに AI アシスト変更に対して senior のサインオフが必要になりました。 その後、同じ METR の研究のように全エンジニア Slack チャンネルに広まりました。

興味深いことに、最近数日 Amazon はこの物語に反論しました。 公開声明で、Financial Times の報道は不正確だと述べました。 彼らのバージョンでは、最近の小売インシデントのうち1件だけが AI ツールを何らかの形で使用したと確認しています。そのインシデントは AI が書いたコードによるものではなく、エンジニアが古い内部 wiki から不正確な助言を受け取り、それに従った結果です。 他の障害は独立した運用問題であり、AI は関与していませんでした。また、新しい承認要件は導入されていないと述べました。 Amazon は AI 関与インシデントをヒューマン エラーとして扱い、AI の失敗ではありません。

Amazon がほとんどの障害が AI と関係ないと主張するのは正しいかもしれません。しかし、詳細に見ると Amazon が確認した事実は以下です。 AI ツールが古い内部 wiki を読み取り、古くなった情報を推論し、エンジニアがその助言に従いサイトをダウンさせたということです。 それは「AI が悪いコードを書いた」物語ではなく、「コンテキストの不足」の話です。 AI は現在の wiki ページと古いページを区別できず、すべてを同等に扱いました。 エンジニアがその助言を疑問視しなかったか、ツールの自信度を自身より重視したかは不明ですが、どちらにせよ「判断力」への依存ではなく AI への依存です。

先述したように、問題は「コードを書く」ことではなく、「コードを取り巻くもの」にあります。 設計決定・システムコンテキスト・何故そうなるかという理解が欠けていると、古い wiki ページは組織の記憶の失敗です。 エンジニアが助言に疑問を持たず従ったことは判断力の失敗です。 これらは直接的に足場の欠落を示します。 AI に頼ることで自分の判断を置き換えているわけです。

ArXiv の論文（先月公開）は、チームが AI コンテキストを管理する方法を追跡しました。 1つのプロジェクトは 26,000 行のコード化されたコンテキストに進化し、実際のコードよりも多くの指示を含んでいました。

一方 GitClear の分析（211 万行）では、AI ツール採用がコード量を10％増加させた一方で品質メトリクスは崩壊しました。 リファクタリングは60％低下、コピー＆ペーストコードは48％上昇、コードチェンジ率は44％跳ね上げました。 モデルはより多くのコードを書いているが、既存のものを理解していないようです。

これは「プロンプトエンジニアリング」（「どうやって尋ねるか」）と「コンテキストエンジニアリング」（「作業開始時にモデルが見るもの」）の違いです。 コンテキストを正しく管理できるチームは、ファイルをオンボーディングドキュメントとして扱います。 ファイル階層は段階的開示を持つメモリ階層、アーキテクチャ決定記録（ADR）に理由を添えます。 26,000 行のコンテキスト構造はオーバーヘッドではなく、かつて人々の頭脳に存在した組織知識を明示化し、新たなエンジニアが学べるようにします。

ほとんどの工学はグリーンフィールドではありません。 「ブラックフィールド」―レガシー システムで高負荷、廃止パス上にあるものです。 仕様書は存在しないか、10 年間未文書化決定で無効になっています。 ビジネスルールは条件分岐としてエンコードされており、すべてを理解した人がいなくなりました。

AI エージェントはコード・テスト・ドキュメントを読むことができますが、本番環境を読むことはできません。 何年にもわたるリクエストパターンを見て、コード内に明示されない負荷の高い経路を理解することはできません。 デッドケースハンドラと0.1％ユーザーしか走らないものを区別できません。

Amazon の古い wiki は最も顕著な例です。 すべてのコードベースには、書かれていない暗黙知が存在し、あるいは一度だけ記載され、更新されていません。 AI はそこにあるものを読むのみで、欠落や古さを把握できません。 システムを長く使用した人だけがそれを感知できます。

非グリーンフィールドシステムの正しい手順は「仕様書を書く→コード生成→テスト実行」ではなく、「本番観測→挙動契約抽出→システムテストとして仕様化→その後にエージェントを投入」という流れです。 すでに存在するツール（キャラクタリゼーションテスト、契約テスト、トラフィックシャドウイング、カナリー分析）は新しいものではありません。 AI が登場する前からソフトウェア工学はこれらを確立してきました。 AI 会話はそれらを継承し、より良いプロンプトで問題が解決されたかのように振る舞ってはいけません。

Financial Times の見方と Amazon の見方に関係なく、構造的ポイントは同じです。 AWS Kiro インシデント（削除再作成）は「AI が判断力を持たず、経験から得られる直感が欠如した結果」です。 確認された小売インシデント（古い wiki）は「コンテキストが管理されておらず、その管理は足場の欠落に直結する」ものです。

この論争自体が、組織が構造的問題として捉えることを拒む姿勢を示しています。 Amazon はこれを「ユーザーエラー」と呼び、「運用レビュー」と位置づけます。しかし、AI が誤った助言を信じて従う行為は単なる偶発的な失敗ではなく、 AI ツールが導入されるすべてのシステムで再現されるパターンです。

---

第V幕：ギャップに注意

答えを簡潔に提示しようとはしません。 私たちは根本的な構造問題に直面しています。 ラダーには足場が欠けています。しかし興味深いのは、私たちは以前にここに来ていたという事実です。

1980 年代のホームコンピュータ革命は、試行錯誤で学ぶエンジニア世代を生み出しました。 私の世代は BBC Micro、Commodore 64、ZX Spectrum の時代を経験し、BASIC プロンプトから起動するマシンに触れました。 子どもたちはゲームやツール、実験を書き、ほとんどがゴミでしたが、学びました。

2000 年代初頭にはコンピュータはパッケージ化され、デスクトップは Windows に起動し、ソフトウェアはディスクから配布されました。 ソースコードは付属せず、Xbox が BBC Micro を置き換えました。 子どもが寝室でプロフェッショナルと同じレベルのゲームやアプリを作ることは不可能になりました。その結果、多くの学生は大学に入学してもコードを書いた経験がありませんでした。

この問題は学術界と業界で大きなパニックを引き起こしました。 その対策として Raspberry Pi が登場し、手頃なコンピュータを提供し、物理的な接続（GPIO）で触れられるマシンを持たせました。 これが成功したのは診断が正しかったからです。

現在の AI の乱世は同じダイナミクスをプロフェッショナルレベルで再現しています。 「小さな仕事」（バグ修正、定型コード、ドキュメントなど）は新人に見せる前に自動化されます。

Anthropic の内部データはエンジニアリングの新しい形状を示します。 エンジニアは Claude を 59％ の日常作業で使用し、50％ の生産性向上を報告していますが、全体作業の20％しか完全に委任できないと回答しています。 一人のエンジニアは「70％以上コードレビュー/修正で、純粋な新規コーディングではなく」 という転換を経験しました。

2 月から 8 月まで Claude Code の連続自律行動は9.8 から 21.2 に倍増し、人間トランスクリプトあたりの人間ターンは6.2 から 4.1 に減少しています。 残る作業は監督・設計・判断が中心です。

Anthropic の労働市場分析では「AI は雇用への影響：新しい指標と初期証拠」 が示されています。 コンピュータープログラマーは最も曝露されている職種（74.5％）であり、30％ 以上の作業が実際に自動化されています。 一方で物理的な仕事（料理人・メカニック）は 0％ 被覆です。

AI はまだ理論上の能力に到達していません。 LLM が理論上できることと、現実で使われていることとのギャップは大きいままです。 コンピュータと数学職種では94％ の理論曝露がある一方、観測されたカバレッジは33％ しかありません。

この「アモーディのギャップ」は講演冒頭で測定されました。 AI に曝露された職種は将来成長が鈍化し、10 年後に経験豊富なエンジニアを育てるパイプライン自体が縮小しています。

Amazon は 2025 年 1 月に 14,000 社内社員を解雇し、1 月にはさらに 16,000 人を削減しました。 Anthropic の観測曝露データは AI が最も曝露された職種の成長予測が低下していることを示しています。

若年層（22〜25歳）の新規雇用は、2024 年以降下降傾向にあります。 14％ の雇用率減少は統計的に有意ですが、 ADP 給与データでも同様の結果が確認されました。

結局、AI を採用するかどうかという質問は閉じたものです。 私たちは AI を採用し、もしあなたが採用しないのであれば、1 年後に仕事や会社を失うでしょう。 重要なのは「どのようにエンジニアを育てるか」です。 現在の構造的課題を解決できなければ、10 年後には企業自体が存在しなくなる可能性があります。

---

今すぐできること

• 構造化された学習パス – 意図的に「基礎作業」をローテーションさせる。 AI が高速で処理できても、理解は不可欠です。 コストが高く、多くの企業は実施しませんが、将来のシニアエンジニアを確保できます。

• 速度ではなく理解を測定 – 「このコードが何をするか説明できるか？ AI なしでデバッグできるか？」 ペアプログラミングで思考過程を見ることで評価します。

• コンテキストをインフラとして扱う – チームは Claude.md、メモリ階層、ADR を教育資料とし、単なる設定ファイルではなくオンボーディングドキュメントに変えます。

• 正直な期待値を提示 – AI はツールであり教師ではありません。 使うことで理解をスキップすることは将来の投資を減らす行為です。 将来価値がある人は、指示を読むだけでなく、仕組みを知る者です。

---

今後の見通し

現在の倍増率では AI エージェントは 2027 年に1 日分、2028 年には1 週間分、2029 年には1 ヶ月分のタスクを処理できるようになると予測されます。 ただし、これらは慎重に検討すべきです。 もし AI が「クラフト」時代を失った人々を育てるプロセスを構築できないなら、10 年後には中間段階の足場自体が再構築されます。

Anthropic のデータは一つの脱出口を示します。 Claude を使用した作業の27％ は「新規実験・ツール化」や「探索的作業」であり、従来の手動でしかできなかったものです。 ただしこれが機能するには、人間監督者自身が AI を使いこなし、設計を理解している必要があります。

AI は生産性を高める可能性がありますが、同時に「クラフト」スキルの育成プロセスを失わせています。 現在の労働市場データは、AI が最も曝露された職種で雇用増加が鈍化し、若年層の採用が減少していることを示しています。 これはパイプライン自体が切断されている証拠です。

Amazon の解雇事例や Anthropic の分析は、AI が人間の判断力と経験に代わるものではなく、むしろその欠如を露呈するというメッセージです。 今後も AI を導入する企業は、コンテキスト管理と教育プロセスの構築を怠らないようにすべきです。 そうでなければ、10 年後には「AI の監督者」を育てるための人材が足りなくなるでしょう。