人間はどの意思決定を手放せるのか

技術的負債に向き合うConference 2026 の発表資料です。

ぜひ最後までお読みください。

Transcript

1. 人間はどの意思決定を 手放せるのか kawasima
3. https://agilejourney.uzabase.com/entry/2025/12/11/103000
6. AI以前からあった 「成果物の内部まで理解しているわけではない」問題 が、なぜ今クローズアップされるのか？
7. 時間をかければ計測できていたものが 少なくとも計測できている体のもの AIの出力スピード/量についていけず 計測できなくなっている
8. compile ✓ tests ✓ lint ✓ CI ✓ architecture ✓ maintainability ✓ domain semantics ✓ future evolvability ✓ 計測可能性の谷
9. 大きな粒度の仕事をAIに任せても そこで行われている 様々な意思決定 その効果・影響を 計測できない
10. 例題 既存のECシステムに、 「ユーザが注文をキャンセルできるようにしたい」 という要望が上がった。 コーディングエージェントに、 「 注文キャンセルを実装して。決済済みの場合は返金して、在庫も戻して。 」 と依頼するとどういうことが起こるのか？
11. 「注文キャンセルを実装して。決済済みの 場合は返金して、在庫も戻して。」 を受けて、実装するコーディングエージェ ントには多くの 性質の異なる意思決定 が含 まれている。
12. 次のようなコードを出力してくるかもしれない
13. 暗黙的に次のような意思決定がされている • 返金 → 在庫戻しの順序にする • payment.refund() はDB transactionと同じ意味で扱っている • 出荷済み注文もキャンセル可能である • refund成功後のDB rollbackは許容できる • 在庫戻しは必ず一度だけ起きる
14. 意思決定構造はDAG 多くの決定が依存しているものほど、重 要な意思決定になる。 だが、この構造は見えにくい。
15. 現状よく見られる人間/AIの責務分離ライン DAGをLeafから辿り、その決定を 委譲したら品質特性が評価できな くなるラインが、その人・組織が AIに任せられる領域
16. 委譲できる = 理解しなくても正しいと判定できる 委譲できる2つの条件 • Evaluability 成果物の内部を理解しなくても外部基準によって正しい と判定できるか • Controllability 間違っていたときに、その被害を制御できるか
17. Evaluabilityが高くてもControllabilityが低いと委譲しにくい 例えば: 本番環境のデータマイグレーションのSQLを作って実行してもらう。 Evaluability Controllability 実行結果が正しいかは確認用 のSQLを実行すれば簡単に確 かめられる 間違ったDDLやデータ書き換 えが発生した時点で即、大問 題である
18. Controllabilityをあげる仕組み • Feature toggle や Expand and Contract など、デプロイとリリース を分離する • Progressive Exposure: カナリアリリースやBlue / Green • 間違いを局所に閉じ込める: BulkheadやCircuit Braker • 実行済みでも戻せる: Recovery, Compensation
19. Evaluabilityのために多大な工数をかけては経済合理性がない Resilienceな方向が当面の主流になりそう… • • 間違いは基本的に受容して失敗に気づいたら修正したらいい (OpenAI; かなり意訳) E2Eの重い評価を毎回回すのは解析・運用コストが高すぎる。中間ステップ を検証する軽量な行動評価に分割してローカルで高速（数秒）に回す。 (Google)
20. まとめ • 人間が手放せる意思決定領域は、EvaluabilityとControllabilityが高いもの • Evaluabilityが高く保たれていれば、AIが作る成果物の内容を人間が理解し なくても良い (ハーネスエンジニアリングの基礎概念) • Controllabilityを高める仕組みは、これまでのソフトウェアエンジニアリン グの蓄積が使える • とはいえEvaluabilityを高めるのにコストがかかり過ぎたり、何回も開発ルー プ回さなきゃいけないとしたら経済合理性が無くなってしまう
21. …と似たような話は 今日も世界中のどこかで誰かがしていることだろう
22. Evaluability 成果物の内部を理解しなくても外部 基準によって正しいと判定できる それが難しいんだよー💢
23. Evaluabilityについての過信 • AIが間違いを起こさないような仕様を書く 最初からそれが書ければ苦労しない • ドメインエキスパートと連携しながら正しい仕様を書く そんな人がいるなら連れてきてほしい • 開発ループを回し間違いを修正していけば、正しい結果に近づく 何の基準もない中で、何回この開発ループを回せば成功いいのでしょうか…
24. そもそも上位の意思決定項目は 何を持って正しいとするか を決めることが成果物であり、委譲ができない！
25. 頭打ちなのか…
27. 限界突破のために共有メンタルモデル 上位の意思決定をモデルとして書き表す このモデルをAIと協働で速く作る 下位の意思決定のEvaluatorとして使う そんなことが…
28. できる
29. Souther 正しい(と言える)仕様を最初から書くことは誰に もできないので、モデルとexampleを繰り返しな がら作っていく モデル 業務で扱うデータと振る舞い example 実際に振る舞いを実行した時 に期待する具体的な入出力 exampleはモデルと同時に書き、検証される https://souther-lang.org
30. Southerでまず雑にモデルを書く (data/behaviorをザッと書き出す)
31. exampleの素を生成 → 期待する結果を人間が埋める モデルの表現力に対して足りていないexampleを Southerが解析する
32. 仕様の解像度があがり、モデルを修正したくなる
33. モデルを修正するとコンパイルが通らなくなる…のでexampleを加筆修正
34. Souther以後の世界ではテストを先に書くか/後に書くか という概念はなくなる モデル 業務で扱うデータと振る舞い example 実際に振る舞いを実行した時 に期待する具体的な入出力 十分なモデルとexampleを書き終わった瞬間 本当の意味での仕様を満たした動くドメインモデルが出来上がっている
35. 残った外側 (ControllerだったりDBアクセスだったり) は それこそコーディングエージェントの得意分野なので 「Southerモデル満たすように作って」と 委譲してあげれば良い。