2026 年：AI と大規模技術的負債によるエンジニアリングの崩壊

過去の教訓：2020 年の失敗

2020 年、あなたはチームで最も経験豊富なメンバーとして、以下の責任を果たしていました。

• コード品質とアーキテクチャ の責任者
• 健全なコードベースの維持
• 優れたエンジニアリングプラクティスの導入
• 新規メンバーからの PR を丹念にレビュー

しかし、休暇中にチームは以下のように崩壊しました。

• PR が他者のものとして合併され、確認が甘くなる
• 「デノーマライゼーション」の名目で不必要なテーブルが増加する
• 必要性の裏付けがないまま、サーバーレス技術や Kafka を追加する
• コードベースが散乱し、理解不能な状態になる

あなたはこの状況を修正する力を持っていました。

現在：2026 年の悲観的な現実

数年後の 2026 年。ただの火曜日の朝、あなたは以下の状況に直面します。

• 7 つの PR をレビューする必要に迫られる
• 最初の PR は +24,506 ラインもの変更内容
• AI が生成した説明付きだが、実際の実装意図は不明瞭
• 休暇中とは対照的に、短期間に膨大な変更が行われている

現在のエンジニアリングカルチャーの問題点

• AI は速度制限を削除し、過剰な生産性を促進している。
• 弱いエンジニアリングカルチャーを持つプロジェクトは、AI の介入によってより早く破綻する。
• 「どうすればよいか」を検討する時代ではなく、「エージェントに数時間プロンプトを与えて PR を提出する」のが標準になっている。

システムの崩壊プロセス

1. ブランチをプルしてテストすると、ある程度機能するように見える。
2. 実際には理解されていないまま、修正が繰り返される（「また同じこと」）。
3. プロジェクトは誰も任何东西の動作原理を理解できない状態に達する。

クレジットカードで高級車を買うようなものです。
負債には見えませんが、中身は空洞な外見だけの車です。

やがてユーザーから奇妙なバグの報告が続くようになります。

• チームはこのバグを4 回目に修正しようとしている。
• その内容は「AI に修正を依頼する」ことのみ。
• Fable（高度な AI ツール）ですら解決できない。

対話：理解不能なアーキテクチャの行方

機能実装者の回答は以下のようでした。

質問者	回答者
「データはどのようにして来ているのですか？」	「うーん…実は知りません。Claude に聞いてみましょう。」
（画面に無限の壁面テキストが表示される）	（二人とも情報の真偽に確信はないが、Claude は自信満々）
「意味があるように感じますか？」	「自信はありません」
「あれほど複雑に……先週には構築したのですよ」	沈黙

システムの現状

このプロジェクトは以下のような状態にあります。

• あまりにも複雑で、層やサービスが多すぎる。
• チーム全員が状況を理解し始めていません。
• 修正には膨大な労力が要するため、管理職への正当化が不可能。
• 数ヶ月もすれば、また同じ状態に戻る。

結果として以下の会話が繰り返されます。

1. 「Claude に修正を依頼しましょう」
2. 「了解です。完走チェックが終わるまでループとゴールを設定します。」
3. 「良さそうですね」
4. 「実は今日 Fable の使用枠を使い切ってしまったので、明日実行しますね」

究極の問いかけ：誰が設計を決めているのか

残りの PR（13 件）を処理する中で、あなたは以下のメッセージを送ります。

「なぜここで行っているのですか？」

相手は Claude の会話履歴をリンクで送ってきます。 その履歴には以下が含まれていました。

• Claude が自信を持って一つのアーキテクチャを推奨
• 謝罪と考えの変化の繰り返し
• 15 ラウンドにわたる変更の記録
• 最終的な設計決定が埋もれている

質問：「どの部分を読むべきでしょうか？」 回答：「おそらく全部でしょう」

これは懐かしい響きではありませんか？
「誰も大規模システムを完全に理解したことはなかった」と言われることがあります。確かにそうです。

しかし、かつては誰かが理解していてあなたに説明してくれる人がいました。 今では、自分たちですら知らないため LLM に尋ねるしかありません。

---

いまや不良なエンジニアを雇用する余裕はありません

人材市場の劇的な変化

どのチームにも以下のような人物が存在します。

• 有能な人：プロジェクトを実現する
• 困難を招く人：他の全員にとってマイナスの影響を与える

過去と比べて、以下の点が大きく変わりました。

• 速度の違い：かつては何年もかかっていたコード作成が、1 日で完了可能に
• コスト構造の変化

過去の失敗要因の再考

上記の話で誰もが犯したミスを以下のように整理できます。

• +25,000 ラインの PR を提出したエンジニア

  • エージェントの動作を止めるべきだった
  • 何をしているのか理解し、作業を小さく分割すべきだった
  • 導入された全ての新しい抽象概念を疑う必要があった

• レビューを行った人物

  • その規模に屈服する代わりに、これをレビューすることを拒否すべきだった

• Kafka を追加した人物

  • 必要性を明確に説明できなければならない

• 機能を構築した人物

  • Claude の会話履歴へのリンクを送ることなく、データがどこから来るかを説明できなければならない

問題の核心：撤回は極めて困難

「ただ AI に修正を依頼すればよい」という解決策は存在しません。理由は以下の通りです。

• 大規模技術的負債の撤去には時間がかかる
• しかし、負債があるからといってそれが常に悪いわけではない（重要なのは近道に気づくこと）
• ただし、悪い意思決定を撤回するのは非常に困難

具体例：データベース移行の難しさ

LLM がテーブルや列を追加するのに 10 分かかったとしても、その後の影響は計り知れません。

• データ保存が始まると簡単には削除できない
• 移行計画を立てる必要がある
• 毎日利用しているためシステムへの影響を避けることが必須
• 移行失敗時の対応策の準備
• 孤立した外部キーを残さないよう注意
• 修正するほど難易度が上昇し、最良のモデルでも限界に

さらに、以下のサイクルに陥ります。

1. 一つの不良な意思決定を解きほぐすのに時間がかかる
2. その間、もう 5 つの悪い意思決定が合併される
3. 新しい PR が次々と入ってくる
4. より多くのコード、抽象化、意思決定が蓄積する

1 人の人が 1 日の午後で 20,000 ラインのコードを生成できる時代です。
それでもあなたは座って、それらの行が実際に何を行うかを理解する必要があります。

---

新しい AI エコノミー

技術的負債の歴史と違い

不良なエンジニアは常にリスクでした。しかし今回は質的不同があります。

• 過去（OpenAI や Anthropic が存在する前）
  • 悪い意思決定が積み重なり、複雑性が蓄積されたチームが終了したが、やることに速度制限があった。
• 現在（AI エポック）
  • 実装は安価になり、良い意思決定を行いながらスケールできるソフトウェアを構築するために支払われています。

なぜ高給なのか？

会社がロンドンやサンフランシスコのエンジニアに対し六位数字の給与を支払う理由は以下の通りです。

• もし唯一必要な仕事が「仕様を実行可能なコードに変換する」だけなら、他処で安くできていた。
• ソフトウェアが「解決済み」と主張する企業が、最も優秀な人材を獲得し続けるのはなぜか？
  • AI は大幅にスピードアップできるため、良いエンジニアはより価値がある。
  • 実装作業に必要な人員を減らせる。

雇用市場への影響予測

AI は給与格差をさらに拡大させます。

• 雇用可能であるためには：現在の最良のモデルができることをクリアする基準線が必要。
• 不良なエンジニアを雇うコストは大幅に高騰。
• 「Vibe コーディング」のキャリアパスは破滅。
  • プロンプトを与えてエージェントに依存するだけでは、すでに得られているものを超えた貢献が必要。

結論：判断力を持つ人材へのシフト

LLM の推奨事項を評価するために必要な判断力がなければ、問題解決には至りません。

ある時点で、何が行われているのかを知る人がいなければならない。
そしてそれがチーム内で最も価値のある人物です。

労働市場の分断

• 理解できない人々
  • 雇うコストが大幅に下がるか、完全に置換されるでしょう。
• 資金の集約
  • 資金は実際に信頼できる少数の人々へと集約されていきます。

これはソフトウェアエンジニアリングに限定されず、ほとんどの知識労働において同様の現象が発生すると確信しています。

AI の本質的な影響

1. 優れた人々はさらに生産的になる
2. 不良な人々はほぼ雇用不能になる
3. 以前は悪い意思決定が過度に進む前に誰かが発見できた可能性があったが、今では周囲の誰も現実的にレビューしたり理解したりできない速度で変更を加えることができる。