続・ソフトウェアアーキテクトのための意思決定術: Decision Readiness, Revisited — When AI Changes the Economics of Software Architecture

「『ソフトウェアアーキテクトのための意思決定術』のその先 ――AIで置き換わる仕事と残る意思決定」の発表資料です #意思決定術_findy

https://findy.connpass.com/event/409797/

アーカイブ動画: https://findy-code.io/events/FnA4map8nAkHn?fr=event_archive_20261105

Transcript

1. 続・ソフトウェアアーキテクトのための意思決定術 Decision Readiness, Revisited ̶ When AI Changes the Economics of Software Architecture ENISHI TECH INC. 島田浩二(@snoozer05) 2026.11.05 - 『ソフトウェアアーキテクトのための意思決定術』のその先
2. 島田浩二 @snoozer05
3. ENISHI TECH INC. Vision Organization Management Business Process IT Systems Execution Management Talent Development Teams
5. 続・ソフトウェアアーキテクトのための意思決定術 Decision Readiness, Revisited ̶ When AI Changes the Economics of Software Architecture ENISHI TECH INC. 島田浩二(@snoozer05) 2026.11.05 - 『ソフトウェアアーキテクトのための意思決定術』のその先
6. 2026年のソフトウェア開発の状況 AIが本格的にソフトウェア開発に参加し始めた • Vibe Coding から Agentic Coding へ • AIによる生成を前提とした開発の仕方、仕組み、考え方が活発に議論されている • Harness Engineering、Context Engineering、Software Factory … 人が多くの時間を費やしてきた活動が変わってきている中で アーキテクトの仕事、とりわけ意思決定はどう変わるだろうか？
8. https://speakerdeck.com/snoozer05/create-decision-readiness-the-real-skill-behind-architectural-decision
9. https://speakerdeck.com/snoozer05/create-decision-readiness-the-real-skill-behind-architectural-decision?slide=56
10. https://speakerdeck.com/snoozer05/create-decision-readiness-the-real-skill-behind-architectural-decision?slide=58
11. 今日までの変化を踏まえると、話はどう変わるか？
12. ソフトウェアアーキテクチャとは システムに求められる重要な品質を、さまざまな制約のもとで、 経済的に合理的な手段で実現・維持していく方法 その合理性を支える条件を AIが変えるとしたら…… これまでは合理的だったアーキテクチャ上の選択が、 今後もそうとは限らない
13. 今日のお話 •AIは何を変えていっているか • ソフトウェアアーキテクチャに関わる影響 •どうしていけばいいか、何に備える必要があるか • 現時点で島田の思考や実践の断片として
14. 1 AIが変えているもの
15. AIが変えているのは ソフトウェアアーキテクチャの前提
16. AIが変えているソフトウェアアーキテクチャの前提 外部環境の変化① 攻撃者の経済性 AIで攻撃の探索や実行のコストが下がり、攻撃者は、より多くの対象をより短時間に 調べられるようになってきている → これまで攻撃コストに見合わなかった標的も、対象になり得る → 守る側もリスク評価を見直す必要がある 外部の脅威が変われば、必要なセキュリティ水準は変わり得る
17. AIが変えているソフトウェアアーキテクチャの前提 外部環境の変化② 利用者の主体 人の代理としてAIがシステムにアクセスし、操作する場面が増えてきている → 人間とは異なる速度や頻度でアクセスし、処理を並列し、リトライや自動実行を 行うクライアントを想定する必要が出てくる → 性能、信頼性、セキュリティ、相互運用性などのソフトウェア品質に影響がある 利用の仕方が変われば、品質特性の重要度や水準を決めていた前提も変わり得る
18. AIが変えているソフトウェアアーキテクチャの前提 内部環境の変化① 開発の経済性 AIによって、調査、設計案の検討、プロトタイピング、コード生成、変更などの作業 コストが変わってきている → 時間や予算などの制約で見送ってきた試作や比較検討ができるようになる 実装や変更が容易になることで、これまで取り得なかったアプローチが可能になる
19. AIが変えているソフトウェアアーキテクチャの前提 内部環境の変化② 運用の経済性 AIは、テストや分析、観測、障害調査、文書化といった作業も行える → 従来は価値を認めながらもコストなどの都合から実施が現実的でなかった範囲 まで運用の活動を広げられるようになる これまで経済的に成立しなかった品質管理活動が、新たな選択肢になり得る
20. 「どの品質をどの程度重視するか」と「それをどう守るのが合理的か」 が同時に変わっていっている 外部環境の変化 重要な品質特性と、その優先順位・要求水準を変える 内部環境の変化 品質特性を実現・維持する手段とコストが変わる では、これまでのアーキテクチャ上の選択を、どう見直すか
21. 2 アーキテクチャ上の選択の経済性を見直す
22. 経済的に合理的な手段を選ぶ = 価値とコストを天秤にかける 例）モジュール分割 価値 コスト 変更の影響範囲を限定し 設計・実装・維持 将来の変更時リスクを減らす ⚖ モジュール分割すべきか この天秤で価値がコストを上回ると期待するので 分割を選択する
23. 経済的に合理的な手段を選ぶ = 価値とコストを天秤にかける 例）モジュール分割 価値 コスト 変更の影響範囲を限定し 設計・実装・維持 将来の変更時リスクを減らす ⚖ モジュール分割すべきか AIで変わる AIで変わる この選択を支えていた価値とコストを、改めて量り直す
24. 前提の変化は価値とコストを同時に動かす 例）セキュリティ投資 例）性能・容量の持ち方 価値：攻撃者の経済性が変わり、守ることの重みが増す 価値：アクセス頻度・並列性・利用パターンなどが変わ り、求められる品質の水準が変わる コスト：AIによって監視や調査が実施しやすくなる コスト：AIによって観測・分析・改善を継続的にしやす くなる → 予防・検知・封じ込め・復旧をどう組み合わせる のが合理的か？ → 事前に用意する容量・構造と運用での調整をどう 組み合わせるのが合理的か？
25. ただし、すべての前提が変わったわけではない • コードは素早く直したり戻したりできても、起きた影響すべては取り消せない • 失われたデータ • 情報漏えいや障害によって失われた信頼や事業機会 •… • 作業は高速に行えても、物理的・社会的・組織的な制約がなくなるわけではない • 理解や検証、運用、組織的な調整にかかるコストは残る AIで安くなった部分と、依然として高くつく部分を、注意深く見分けて扱う必要がある
26. 変化から前提を捉え直し、価値とコストの両方を量り直す 価値 ⚖ アーキテクチャ上の選択 コスト 前提の変化は 前提の変化は どう価値を変えるか どうコストを変えるか
27. 変化から前提を捉え直し、価値とコストの両方を量り直す ⚖ アーキテクチャ上の選択 価値 コスト 前提の変化は 前提の変化は どう価値を変えるか どうコストを変えるか ただ、変化は続くので、一度量り直せば済むわけではない では、私たちはどう意思決定をしていけばいいか
28. 3 アーキテクトの意思決定はどう変わるのか
29. https://speakerdeck.com/snoozer05/create-decision-readiness-the-real-skill-behind-architectural-decision?slide=29 → この戦略自体は、AIによって古びたわけではない → けれど、変化を受けて、適用の仕方を考え直す必要がある
30. タイミング：決定を先送りすることの価値とリスクが変わる • AIによって探索や試作が容易になるなら、決定を先送りすることで、実験からより 多くを学べるかもしれない • 例）拡張ポイントや抽象化は、必要になったときに用意する方が経済的かもしれない • 外部環境の変化によっては、より早く十全な対応をしないと、リスクを取れなくなる かもしれない • 例）攻撃が速くなれば、セキュリティの決定は先送りしにくくなる → 決定を先送りして試せる余地が広がっても、待つ間に生じるリスクの見極めを疎かにしない
31. 可逆性：「戻せること」と「取り消せないこと」の差が広がる • コードの変更が容易になれば、試してから戻す選択を取りやすくなる • 変更を戻せることと、変更が及ぼす影響を取り消せることは違う • 例）公開したインターフェイスやコントラクトは、それに合わせて変更する外部の利用 クライアントが増えるほど、自分たちのタイミングだけで変更を戻せなくなる → 変更を戻せるかだけでなく、その影響を取り消せるかを見極めて、リスクを取る
32. 判断材料：集めるコストが下がり、意図して集める重要性が増す • AIによって試作・計測・比較が容易になれば、これまではコスト上の制約で得られ なかった量・範囲の材料を使えるようになる • 材料を得られることと、その材料が判断に効くことは違う • 例）AIに技術選定の比較表を作らせると、数分で選べる状態になったように見えるが、組織 の体制や既存システムの負債、事業の時間的制約が考慮されているとは限らない → 前提を踏まえ意図を持って集められた材料でなければ、量があっても判断には効かない
33. 判断における作業コストの重みが減ったAI時代こそ リスクの見極めがより重要になる ① タイミングが来るまで決定を先送りする → 決定を先送りして試せる余地が広がっても、待つ間に生じるリスクの見極めを疎かにしない ② 決定を可逆的にする → 変更を戻せるかだけでなく、その影響を取り消せるかを見極めて、リスクを取る ③ 決定の材料を増やす → 前提を踏まえ意図を持って集められた材料でなければ、量があっても判断には効かない
34. 探索―検知―対応アプローチ https://speakerdeck.com/snoozer05/create-decision-readiness-the-real-skill-behind-architectural-decision?slide=41
35. AI時代の変化を受けて、探索―検知―対応アプローチを改めて捉え直す 必要性の変化：より重要に 実現可能性の変化：よりやりやすく 外部環境の急速な変化によって、判断を支えていた 前提が変わりやすくなっている 内部環境で、探索・観測・分析・検証・変更にかかる コストが下がる → 過去にした決定がいつまでも妥当とは限らない → これまでは難しかった継続的な学習と適応を実践 しやすくなる AI時代には、アーキテクチャ上の判断の妥当性を継続的に確かめ、 必要に応じて見直すことが、より重要に、より実践しやすくなる 変化を捉える 判断する 確かめる 見直す 次の判断へ
36. 変化し続ける状況では 探索―検知―対応による継続的な学習と適応が意思決定を支える 必要性の変化：より重要に 実現可能性の変化：よりやりやすく 外部環境の急速な変化によって、判断を支えていた 前提が変わりやすくなっている 内部環境で、探索・観測・分析・検証・変更にかかる コストが下がる → 過去にした決定がいつまでも妥当とは限らない → これまでは難しかった継続的な学習と適応を実践 しやすくなる AI時代には、アーキテクチャ上の判断の妥当性を継続的に確かめ、 必要に応じて見直すことが、より重要に、より実践しやすくなる 変化を捉える 判断する 確かめる 見直す 次の判断へ
37. ADRに「学習」の経過を残す価値もより高まる https://speakerdeck.com/snoozer05/create-decision-readiness-the-real-skill-behind-architectural-decision?slide=43 判断の経過の記録が、過去の決定を将来問い直す材料になる
38. 4 これからの意思決定に向けて、どう備えるか
39. これからの意思決定に向けて、どう備えるか ① 前提を点検するタイミングを設計する • 定期的な点検と、変化をきっかけにした点検を組み合わせる • 品質特性の優先順位や要求水準に変化あるいは変化の兆しはないか • 外部環境と内部環境、両方の変化に気を配る • 前提がわかっていないなら、まずそれを明らかにするところから 起きている変化が自分たちのソフトウェアにとって何を意味するかを捉える
40. これからの意思決定に向けて、どう備えるか ② ADRに見直しトリガーを残す • 決定の理由を残すだけでなく、その決定が妥当であり続ける条件を残す • 「この決定はどういう条件が変わったら見直すか」を明らかにしておくことで、 「今の状況は見直しトリガーに該当しているか」と問える状態にする 例） 品質：p95応答時間がSLOで定めた上限を継続的に超えたとき 利用状況：エージェント経由のアクセスが想定のn倍を超えたとき 技術・コスト：利用中のサービスの料金や機能が大きく変化したとき リスク：新たな攻撃手法により、従来の防御策の前提が崩れたとき
41. これからの意思決定に向けて、どう備えるか ② ADRに見直しトリガーを残す • 決定の理由を残すだけでなく、その決定が妥当であり続ける条件を残す • 「この決定はどういう条件が変わったら見直すか」を明らかにしておくことで、 「今の状況は見直しトリガーに該当しているか」と問える状態にする • ADRを記録していなければ、まず記録するところから • AIを活用すれば、今ならやりやすい • ただし、AIが推測した判断理由を、当時の実際の判断と混同しないこと 決めた理由に加えて、問い直す条件を残す
42. これからの意思決定に向けて、どう備えるか ③ システム品質を観測・検証・評価できる状態を作る • 適応度関数、テスト、SLI/SLO、運用監視、CI/CD… • これまで費用対効果の判断から実施できなかった活動を改めて検討する • “AIを利用することで、従来よりも実施しやすくなっていないか” • 例）ログやパフォーマンスをAIに継続的に確認させて、問題の兆候を早期に捉える • ただし、AIが自動的に評価したというだけで品質が保証されるわけではない点に注意する 見直しのきっかけに気づけるのは、観測できているものだけ
43. これからの意思決定に向けて、どう備えるか ④ AIが作業する前提で、アーキテクチャの統制を設計する 開発運用の中で、アーキテクチャが適切に実現され、それが守られるようにするのもアーキテクトの仕事 AIが作業するのなら… 何の作業をどこまで任せ、どう統制すればAIがそれをうまくできるのかも考える必要がある 何をどこまで任せるか アーキテクチャが実現され、守られているか 任せられるかと、任せるべきかは異なる AIによる暗黙のアーキテクチャ判断にも目を向ける → リスクを取れるか、検証できるか → 暗黙の選択が重要な品質を損なっていないか AIに何を任せ、どう統制するかも、アーキテクチャ上の意思決定
44. これからの意思決定に向けての備え ① 前提を点検するタイミングを設計する ② ADRに見直しトリガーを残す ③ システム品質を観測・検証・評価できる状態を作る ④ AIが作業する前提で、アーキテクチャの統制を設計する
45. まとめ
46. AIによって意思決定の前提が変わっている 外部環境の変化 重要な品質特性と、その優先順位・要求水準を変える 内部環境の変化 品質特性を実現・維持する手段とコストが変わる これまでは合理的だった選択が、これからも合理的であるとは限らない
47. 変化から前提を捉え直し、価値とコストの両方を量り直す ⚖ アーキテクチャ上の選択 価値 コスト 前提の変化は 前提の変化は どう価値を変えるか どうコストを変えるか ただ、変化は続くので、一度量り直せば済むわけではない
48. 判断における作業コストの重みが減ったAI時代こそ リスクの見極めがより重要になる ① タイミングが来るまで決定を先送りする → 決定を先送りして試せる余地が広がっても、待つ間に生じるリスクの見極めを疎かにしない ② 決定を可逆的にする → 変更を戻せるかだけでなく、その影響を取り消せるかを見極めて、リスクを取る ③ 決定の材料を増やす → 前提を踏まえ意図を持って集められた材料でなければ、量があっても判断には効かない
49. 変化し続ける状況では 探索―検知―対応による継続的な学習と適応が意思決定を支える 必要性の変化：より重要に 実現可能性の変化：よりやりやすく 外部環境の急速な変化によって、判断を支えていた 前提が変わりやすくなっている 内部環境で、探索・観測・分析・検証・変更にかかる コストが下がる → 過去にした決定がいつまでも妥当とは限らない → これまでは難しかった継続的な学習と適応を実践 しやすくなる AI時代には、アーキテクチャ上の判断の妥当性を継続的に確かめ、 必要に応じて見直すことが、より重要に、より実践しやすくなる 変化を捉える 判断する 確かめる 見直す 次の判断へ
50. これからの意思決定に向けての備え ① 前提を点検するタイミングを設計する ② ADRに見直しトリガーを残す ③ システム品質を観測・検証・評価できる状態を作る ④ AIが作業する前提で、アーキテクチャの統制を設計する
51. これからの意思決定に向けての備え ① 前提を点検するタイミングを設計する いつ問い直すか ② ADRに見直しトリガーを残す 何が変わったら問い直すか ③ システム品質を観測・検証・評価できる状態を作る どうやって気づくか ④ AIが作業する前提で、アーキテクチャの統制を設計する • 何をどこまで任せるか • アーキテクチャが実現され、守られているか リスクを取れる状態をどう作るか AIによる判断を問い直せる状態をどう作るか
52. AI時代のソフトウェアアーキテクトのための意思決定術の本質 「これなら、ここでならリスクを取れる」と決められる状態を作っていく だけでなく 必要なときに決めたことを問い直せる状態も作っていく
53. 続・ソフトウェアアーキテクトのための意思決定術 Decision Readiness, Revisited ̶ When AI Changes the Economics of Software Architecture ENISHI TECH INC. 島田浩二(@snoozer05) 2026.11.05 - 『ソフトウェアアーキテクトのための意思決定術』のその先