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