2026年のソフトウェア開発を考える（2026/07版）
Agentic Software Engineering 2026-07 Findy Edition

📖 概要

本資料は、和田卓人氏（t-wada）が AI DevEx Conference 2026（2026年7月23日）で登壇した発表資料（rev.32）です。 2025年から2026年にかけて起きたソフトウェア開発の大きな変化を振り返り、 「Vibe Coding → Agentic Coding」 への進化、AI前提の開発ライフサイクル、 そして新たに生まれた 「認知負債」 という概念について深く考察しています。

特に 「思考は外注できるが、理解は外注できない」 という核心的なメッセージを軸に、 AI時代のソフトウェアエンジニアリングが直面する本質的な課題と、それに対する実践的な解決策を提示しています。

🔄 2025年に起こったこと：AI開発の激動期

2025年はソフトウェア開発にとって歴史的な転換点となりました。主な出来事：

• Vibe Coding（Andrej Karpathy 提唱）— 感覚でコードを書く新しいスタイル
• The 70% Problem（Addy Osmani）— AIが生成するコードの70%問題
• The End of Programming as We Know It（Tim O'Reilly）
• AI Slop — もっともらしい出力による、他者へのレビュー負担押しつけ問題
• FOMO（Fear of Missing Out）— 乗り遅れる恐怖感
• 2025年11月の感染（infection） — コーディングエージェントの能力がこの月に大幅向上
• The 80% Problem（Addy Osmani）— 問題が70%から80%に拡大

🤝 AIとの協業の2つのモード

t-wada氏は、AIとの協業を次の2つのモードに整理しています。

項目	AI と伴走（直列開発）	AI に委託（並列開発）
方式	AIと対話しながら直列で開発	自走するAIたちに任せて並列開発
速度	「委託」に比べて遅い	圧倒的に速い
コントロール	高い	低い（レビューが課題）
性質	traditional: 決定論的だが、人力でスケールしない	emerging: 非決定論的・確率的だが、非常によくスケールする

2025年中盤には伴走モードが確立され、2025年末から2026年にかけて委託モードへの移行・拡大が進んでいます。

🛡️ レビューの厳密さ（Rigor）はどこへ移るのか

委託モードの拡大により、レビューが担っていた厳密さは、より前段の工程へと移動します：

• 前段の仕様レビュー（EARS、Gherkin、デシジョンテーブル等）
• 第一級の成果物としてのテストスイート（TDD）
• 型システムや制約によるガードレール
• ビジネスの影響度に基づくリスクマッピング
• 継続的な理解形成（ペアプロ、モブプロ）

⚙️ エンジニアリングの進化：4つの段階

時期	エンジニアリングの名称	本質
〜2024年	プロンプトエンジニアリング	仕様の言語化・構造化（Spec by Example）。LLMへの指示・意図の言語化
2025年	コンテクストエンジニアリング	暗黙知の形式知化、オンボーディングの円滑化。「DX」そのもの。LLMに渡す情報のキュレーション
2026年2月	ハーネスエンジニアリング	自動化への投資、CI/CDの徹底。AIエージェントが働く環境の設計。決定性と非決定性の新たな境界線
2026年6月 NEW	ループエンジニアリング	自動化（Automation）から自働化（Autonomation）へ。自律的な作業ループと停止条件の設計。評価の重要性

🌀 技術の螺旋とLLMの革命性

LLM（大規模言語モデル）の登場は、アセンブラから最初の高水準プログラミング言語への移行と同じくらい、ソフトウェア開発を大きく変えるものです。

また、t-wada氏は「AIと関係なくやるべきことをやると、そこにAIの力が掛け合わされる」と指摘。 各エンジニアリング（プロンプト・コンテクスト・ハーネス・ループ）は、もともと重要だった実践がAI時代によってさらに重要性を増した形と言えます。

💸 新たなる負債：技術的負債から認知負債へ

① 技術的負債（Technical Debt）は改善傾向

技術的負債（本来の意味：Ward Cunninghamのメタファー）に関しては、2025年初頭のVibe Codingではすぐに保守性が崩壊しましたが、 2025年11月以降コーディングエージェントの能力が向上し、保守性に優れないコードは生成されにくくなってきたため、むしろ改善傾向が見られています。

② 認知負債（Cognitive Debt）— 新たな見えない危機

本発表の核心的な概念が「認知負債」です。

• これまで人間は対象を理解していないとコードは書けなかった（速度・内容・理解が同期）
• 現在は理解していなくとも（理解より速く）コードが生成されるようになった
• 速度と内容と理解がそれぞれ乖離している
• 開発過程で形成されるはずだったメンタルモデルが形成されなくなった
• Agentic Codingが大規模並列化するとこの傾向が強まる
• 技術的負債は見えるが、認知負債は見えない
• 現在は設計を理解していなくともDORAメトリクスを上げられる

③ 負債の対比：Ward Cunningham（1992）vs 認知負債（2026）

📚 古典的知見からの警告

t-wada氏は、過去の古典から2つの重要な知見を引用しています。

Programming as Theory Building（1985）— Peter Naur

プログラミングとは、開発者の頭の中に共有された知的構成物（＝理論）を構築する活動。コードは二次的な副産物に過ぎません。理論には3つの要素があります：

1. 現実世界との対応：コードの各部分が現実世界のどの活動を担っているか説明できる
2. 設計判断の根拠付け：コードがなぜそのように書かれたか説明できる
3. 建設的な修正能力：既存の理論を壊さずに適切な変更を加えられる

Ironies of Automation（1983）— Lisanne Bainbridge

自動化の皮肉（パラドックス）：

• 自動化が進むほど、人間による高度な介入が必要な場面での難易度が上がる
• 日常的に使わないスキルはすぐ失われる
• 最も重要で危機的な瞬間に最も高度な認知能力を要求される
• 機械に任せきりの領域は「何が起きているか」を把握する文脈が頭の中にない
• 機械が失敗する頻度が減ると、人間が介入経験を積めなくなり訓練コストが上がる

🔑 解決策：理解が鍵となる

t-wada氏は、認知負債に対する解決策として「理解」を中心に据えた実践を提案しています：

✨ コアメッセージ

AIに「コードを書くこと」や「思考作業」は外注できても、 そのシステムを理解し、理論を構築し、建設的に修正できる能力は人間にしか獲得できません。 これが、AI時代のソフトウェアエンジニアにとって最も重要な武器となります。

📝 所感・まとめ

本発表は、AIによる開発効率化の表面的な楽観論にとどまらず、 「認知負債」という見えないリスクに鋭く切り込んだ画期的な内容です。 技術的負債という概念が生まれて30年以上、Ward Cunninghamの本来のメタファーを振り返りつつ、 AI時代における「逆方向の負債」を定義した点が非常に洞察に富んでいます。

特に 「Programming as Theory Building」（Naur, 1985）と 「Ironies of Automation」（Bainbridge, 1983）という 古典的知見を引用し、現代のAI開発課題を照らし出す手法は、t-wada氏らしい深い歴史的視点を感じさせます。 開発者・マネージャー双方が「理解を外注しない」という原則を胸に、AIと協業すべき時代の指針と言える資料です。