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

Jul 23, 2026 @

2026年のソフトウェア開発を考える（2026/07版）
AI DevEx Conference 2026
2026年7月23日（木）
https://dev-productivity-con.findy-code.io/aidevex2026

Transcript

1. 2026年のソフトウェア開発を考える （2026/07版） Jul 23, 2026 @ AI DevEx Conference 2026 rev.31 Takuto WADA fi id:t-wada 📷🙆 🙆 @t̲wada @twada @twada #aidevex̲ ndy
2. 2025年
3. 2025年に起こったこと • Vibe Coding（Andrej Karpathy） • The 70% problem（Addy Osmani） • The End of Programming as We Know It （Tim O'Reilly） • AI Slop: もっともらしい出力による、他者へのレビュー負担押しつけ • FOMO: Fear of Missing Out、乗り遅れる恐怖感にさいなまれる • November 2025 in ection: • コーディングエージェントの能力が11月に大きく向上 • The 80% Problem（Addy Osmani） • コーディングエージェントは使うか使わないかではなく、どう使うかの段階 fl に既に入った
4. Vibe Coding の革命的なところ https://x.com/t̲wada/status/1948590698762305714
5. Vibe Coding から Agentic Coding へ https://arxiv.org/pdf/2505.19443
6. 2025年初夏の整理: AI との協業の2つのモード • AI と伴走 • AI と対話しながら直列開発 • コードを書くスピードは（「AI に委託」に比べて）遅い • コントロールや状況把握の度合いが高い • traditional: "決定論的ではあるものの、人力であるためスケールしない" • AI に委託 • 自走する AI たちに任せて並列開発 • コードが生成されるスピードは圧倒的に速い • コントロールや状況把握の度合いが低く、レビューが課題となる • emerging: "非決定論的で結果が確率的ではあるものの、非常によくスケールする" https://buildersbox.corp-sansan.com/entry/2025/07/03/142500
7. 2025年中盤: 伴走モードの確立 • AI と伴走 • AI と対話しながら直列開発 • コードを書くスピードは（「AI に委託」に比べて）遅い • コントロールや状況把握の度合いが高い • traditional: "決定論的ではあるものの、人力であるためスケールしない" • AI に委託 • 自走する AI たちに任せて並列開発 • コードが生成されるスピードは圧倒的に速い • コントロールや状況把握の度合いが低く、レビューが課題となる • emerging: "非決定論的で結果が確率的ではあるものの、非常によくスケールする"
8. 2025年末から2026年: 委託モードの拡大、移行 • AI と伴走 • AI と対話しながら直列開発 • コードを書くスピードは（「AI に委託」に比べて）遅い • コントロールや状況把握の度合いが高い • traditional: "決定論的ではあるものの、人力であるためスケールしない" • AI に委託 • 自走する AI たちに任せて並列開発 • コードが生成されるスピードは圧倒的に速い • コントロールや状況把握の度合いが低く、レビューが課題となる • emerging: "非決定論的で結果が確率的ではあるものの、非常によくスケールする"
9. レビューが担っていた厳密さ（Rigor）はどこへ移るのか • 前段の仕様レビュー (EARS、Gherkin、デシジョンテーブル、…) • 第一級の成果物としてのテストスイート (TDD) • 型システムや制約によるガードレール • ビジネスの影響度に基づくリスクマッピング • 継続的な理解形成 (ペアプロ、モブプロ) https://martinfowler.com/bliki/FutureOfSoftwareDevelopment.html
10. AI / LLM と ソフトウェア エンジニアリング
11. AI/LLM とソフトウェア開発ライフサイクル • 〜2024年: SDLC（ソフトウェア開発ライフサイクル） の実装工程に AI を活用 • 2025年: 実装の委譲、SDLC 全体への AI の参加 • 2026年: AI 前提の SDLC への組み替え（NEW）
12. AI/LLM と◦◦エンジニアリング • 〜2024年: プロンプトエンジニアリング • 2025年: コンテクストエンジニアリング • 2026年2月: ハーネスエンジニアリング • 2026年6月: ループエンジニアリング（NEW）
13. 2025年7月の予言(?)の背景: 過去から未来を予測する ループエンジニアリング ハーネスエンジニアリング fi https://speakerdeck.com/twada/agentic-software-engineering- ndy-2025-07-edition
14. 技術の螺旋: 『技術選定の審美眼』より https://speakerdeck.com/twada/understanding-the-spiral-of-technologies-2025-edition
15. 今回の螺旋を可能にした技術: LLM • LLM（大規模言語モデル）の登場は、アセンブラから最初の高水準プログラミ ング言語への移行と同じくらい、ソフトウェア開発を大きく変える • 私たちは抽象化のレベルを上げているだけでなく、同時に非決定性という横方向 にも進んでいる • こうした非決定性の進化は、私たちの職業の歴史において前例のないもの https://bliki-ja.github.io/LLMsBringNewNatureOfAbstraction
16. 今回の螺旋の差分 • コードの生産コストがゼロに近づき、ボトルネックは意図と検証へ移動した • 形式知は人間による内面化を経ず、直接 AI によって実行されるようになった • 実行主体たる AI エージェントは自己評価が苦手で非決定論的な動作をする
17. 技術の螺旋は回る: AIと関係なくやるべきことをやると、そこにAIの力が掛け合わされる • プロンプトエンジニアリング • 仕様の言語化・構造化。Spec by Example • LLM への指示・意図の言語化 • コンテクストエンジニアリング • 暗黙知の形式知化。オンボーディングの円滑化。「DX」そのもの • LLM に渡す情報のキュレーションの仕組み作り。「DX」は続く • ハーネスエンジニアリング • 自動化への投資、CI/CD の徹底 • AI エージェントが働く環境の設計。決定性と非決定性の新たな境界線 • ループエンジニアリング • 自動化（Automation）から自働化（Autonomation）へ • 自律的な作業ループと停止条件の設計。評価の重要性
18. 現代のソフトウェアエンジニアリングは過去の積み上げの上にある fi https://speakerdeck.com/takabow/2025-dora-reportkaradu-mijie-ku-aigaying-sichu-su-cheng-guo-wochu-sisok-keruzu-zhi-nogong-tong-dian-number-kai-fa-sheng-chan-xing- ndy
19. DORAレポート2025: AIは増幅器であり、組織の能力を映す鏡 https://dora.dev/research/2025/
20. 新たなる負債
21. 技術的負債（Technical Debt） • 技術的負債（※） • （※ 本来の意味から離れ希薄化が生じている） • 例えば保守性に優れないコード • 2025年初頭の Vibe Coding ではすぐに保守性が崩壊した • 2025年11月からコーディングエージェントの能力がさらに向上した • 保守性に優れないコードは生成されにくくなってきた • 技術的負債（※）に関しては、むしろ改善の傾向が見られる
22. 認知負債（Cognitive Debt / Comprehension Debt） • これまで人間は対象を理解していないとコードは書けなかった • 速度と内容と理解の同期が取れていた • 現在は理解していなくとも（理解より速く）コードが生成されるようになった • 速度と内容と理解がそれぞれ乖離している • 開発の過程で形成されるはずだったメンタルモデルが形成されなくなった • Agentic Coding がより大規模並列化するとこの傾向が強まる • 技術的負債（※）は見えるが、認知負債は見えない • いまのところ理解の乖離を測るメトリクスはない • これまでは出力内容が理解の度合いの代用特性になっていた • 現在は設計を理解していなくとも例えば DORA メトリクスを上げられる • 「生産性」を上げたい組織と個人の共犯関係が成り立ってしまう
23. From Technical Debt to Cognitive and Intent Debt (2026) by Margaret-Anne Storey Cognitive と Intent にさらに分けた https://arxiv.org/pdf/2603.22106
24. Programming as Theory Building (1985) by Peter Naur • プログラミングとは、開発者の頭の中に共有された知的構成物（＝理論）を構築する活動 • コードやドキュメントは、その理論から派生した不完全で二次的な副産物に過ぎない • 理論の3要素 • 現実世界との対応: コードの各部分が現実世界のどの活動を担っているか説明できる • 設計判断の根拠付け: コードがなぜそのように書かれたかを、自身の直感的知識に基づ き説明できる • 建設的な修正能力: 新しい要求に対し、既存の理論を壊さずに適切な変更を加えられる • プログラムの生と死 • 生: 理論を所有するチームがコードの修正と管理を能動的にコントロール している状態 • 死: 理論を持つチームが解散し、コードが動いていても、修正要求に 知的・建設的に答えられなくなれば、そのプログラムは死んでいる ff https://gist.github.com/onlurking/fc5c81d18cfce9 81bc968a7f342fb1
25. Ironies of Automation (1983) by Lisanne Bainbridge • 自動化が進めば進むほど、人間による高度な介入が必要な場面での難易度が上がる • 日常的に使わないスキルは失われる • 微細な感覚は日常的に使わない限りすぐ失われる • 長期記憶から効率的に知識を引き出すには、どうしても使用頻度が不可欠 • 最も重要で危機的な瞬間に最も高度な認知能力を要求する • 脳内のワーキングメモリの立ち上げのための時間が決定的に足りない • 機械に任せきりの領域は「何が起きているか」を把握するための文脈が頭の中にない • 機械が失敗する頻度が減ると、人間が介入経験を積めなくなり、 人間の訓練コストが上がる https://doi.org/10.1016/0005-1098(83)90046-8
26. Debt Metaphor (1992) by Ward Cunningham • Ward の Debt Metaphor (1992) • （※ 意味が希薄化する前の本来の負債のメタファー） • 学びを得るためにそのときの理解でコードを書く • 得られた学びをコードに反映しないでいると、開発と共に得られていく知識 や理解と目の前のシステムとの乖離が生産性低下を引き起こす • 人間達の理解が先行し、コードがついてきていない状態 • 認知負債 (2026) • AI によるコード生成が先行し、人間の理解がついてきていない状態 https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor
27. 理解が鍵となる
28. 理解を漸進的に育てる
29. 理解を関門にする
30. 理解に向いた形式を使う
31. 理解とスピードはトレードオフではない https://arxiv.org/abs/2601.20245
32. 思考は外注できるが、理解は外注できない https://x.com/karpathy/status/2049907410303865030
33. ご清聴 ありがとうございました