■ 1. 問題の所在
- AI以前からある問題:
- 成果物の内部まで理解しているわけではないという問題はAI以前から存在した
- その問題がなぜ今クローズアップされるのかが出発点
- 技術的負債:
- 現在の理解でまず実装し製品として世に出すことは、借金をすることに似ている (Ward Cunningham)
- 開発は前に進められるが、後に得た理解を反映してコードを書き直し、速やかに負債を返済することが条件
- 認知負債:
- ソフトウェアシステムが変化する速度に、チームの共有理解の更新が追いつかない状態 (Margaret-Anne Storey)
- 安全かつ確信を持ってシステムを変更するために必要な共有メンタルモデルが徐々に侵食されていく
- 計測の破綻:
- 時間をかければ計測できていた、少なくとも計測できている体のものがかつては存在した
- AIの出力スピードと量についていけず、計測できなくなっている
■ 2. 計測可能性の谷
- 機械的に確認できる側:
- compile、tests、lint、CIは確認できる
- 確認が難しい側:
- architecture、maintainability、domain semantics、future evolvabilityは確認が難しい
- 両者の間には計測可能性の谷がある
- 大きな粒度の委譲:
- 大きな粒度の仕事をAIに任せても、そこで行われている様々な意思決定の効果と影響を計測できない
■ 3. 例題: 注文キャンセル
- 例題の設定:
- 既存のECシステムに、ユーザが注文をキャンセルできるようにしたいという要望が上がった
- コーディングエージェントに、注文キャンセルを実装し、決済済みの場合は返金して在庫も戻すよう依頼する
- 依頼に潜む決定の量:
- この依頼を受けて実装するコーディングエージェントには、多くの性質の異なる意思決定が含まれている
- 出力されうるコード:
- @Transactionalを付けたcancelメソッドで、注文取得、payment.refund()、inventory.restore()、order.cancel()、repository.save()を順に呼ぶ実装
- 暗黙に行われた意思決定:
- 返金から在庫戻しの順序にする
- payment.refund()をDB transactionと同じ意味で扱っている
- 出荷済み注文もキャンセル可能である
- refund成功後のDB rollbackは許容できる
- 在庫戻しは必ず一度だけ起きる
■ 4. 意思決定構造のDAG
- 意思決定構造はDAG:
- キャンセルの意味、キャンセル可能条件、業務不変条件、障害時の意味、Tx方式、冪等性方式、実装構造、具体コードが依存関係で連なる
- 多くの決定が依存しているものほど、重要な意思決定になる
- だが、この構造は見えにくい
- 人間とAIの責務分離ライン:
- DAGをLeafから辿り、その決定を委譲したら品質特性が評価できなくなるラインが、その人や組織がAIに任せられる領域
■ 5. 委譲の2条件
- 委譲できるとは:
- 理解しなくても正しいと判定できること
- Evaluability:
- 成果物の内部を理解しなくても、外部基準によって正しいと判定できるか
- Controllability:
- 間違っていたときに、その被害を制御できるか
- 両条件の非対称:
- Evaluabilityが高くてもControllabilityが低いと委譲しにくい
- 本番環境のデータマイグレーションのSQLを作って実行してもらう例が該当する
- 実行結果が正しいかは確認用のSQLを実行すれば簡単に確かめられる
- 間違ったDDLやデータ書き換えが発生した時点で即、大問題である
■ 6. Controllabilityをあげる仕組み
- デプロイとリリースの分離: Feature toggleやExpand and Contract
- Progressive Exposure: カナリアリリースやBlue / Green
- 間違いの局所化: BulkheadやCircuit Braker
- 実行済みでも戻せる仕組み: RecoveryやCompensation
■ 7. 経済合理性とResilience
- 過剰投資の否定:
- Evaluabilityのために多大な工数をかけては経済合理性がない
- Resilienceな方向が当面の主流:
- 間違いは基本的に受容し、失敗に気づいたら修正すればよい (OpenAI、かなり意訳)
- E2Eの重い評価を毎回回すのは解析・運用コストが高すぎる (Google)
- 中間ステップを検証する軽量な行動評価に分割し、ローカルで数秒の高速実行に変える
■ 8. 前半のまとめ
- 手放せる領域:
- 人間が手放せる意思決定領域は、EvaluabilityとControllabilityが高いもの
- 理解不要の条件:
- Evaluabilityが高く保たれていれば、AIが作る成果物の内容を人間が理解しなくてもよい
- これがハーネスエンジニアリングの基礎概念
- 既存資産の活用:
- Controllabilityを高める仕組みは、これまでのソフトウェアエンジニアリングの蓄積が使える
- 経済合理性の限界:
- Evaluabilityを高めるコストが過大だったり、開発ループを何回も回す必要があれば経済合理性が無くなる
- ありふれた議論:
- ここまでと似たような話は、今日も世界中のどこかで誰かがしている
■ 9. Evaluabilityへの過信
- 難しさの本体:
- 成果物の内部を理解せずに外部基準で正しいと判定すること自体が難しい
- 仕様で防ぐという過信:
- AIが間違いを起こさないような仕様を書くという主張に対し、最初からそれが書ければ苦労しない
- ドメインエキスパート頼みへの過信:
- ドメインエキスパートと連携して正しい仕様を書くという主張に対し、そんな人がいるなら連れてきてほしい
- 開発ループへの過信:
- 開発ループを回して間違いを修正すれば正しい結果に近づくという主張に対し、何の基準もない中で何回回せば成功なのか不明
- 委譲できない領域:
- 上位の意思決定項目は、何を持って正しいとするかを決めること自体が成果物であり、委譲ができない
■ 10. 共有メンタルモデル
- 限界突破の手段:
- 上位の意思決定をモデルとして書き表す
- このモデルをAIと協働で速く作る
- 下位の意思決定のEvaluatorとして使う
- 実現可能性:
- それができる
■ 11. Souther
- 前提:
- 正しいと言える仕様を最初から書くことは誰にもできない
- モデルとexampleを繰り返しながら作っていく
- モデル:
- 業務で扱うデータと振る舞い
- example:
- 実際に振る舞いを実行した時に期待する具体的な入出力
- exampleはモデルと同時に書き、検証される
- 手順1:
- Southerでまず雑にモデルを書き、dataとbehaviorをザッと書き出す
- 手順2:
- exampleの素を生成し、期待する結果を人間が埋める
- モデルの表現力に対して足りていないexampleをSoutherが解析する
- 手順3:
- 仕様の解像度があがり、モデルを修正したくなる
- 手順4:
- モデルを修正するとコンパイルが通らなくなるため、exampleを加筆修正する
- テスト順序概念の消滅:
- Souther以後の世界では、テストを先に書くか後に書くかという概念はなくなる
- 完成の瞬間:
- 十分なモデルとexampleを書き終わった瞬間、本当の意味での仕様を満たした動くドメインモデルが出来上がっている
■ 12. 外側の委譲と結論
- 外側の担当:
- 残った外側のControllerやDBアクセスは、コーディングエージェントの得意分野
- Southerモデルを満たすように作ってと委譲してあげればよい
- 結論:
- 今までと同じプロセスや設計手法では、期待するほど品質と生産性をあげることはできない
- 人間とAIが真に協働するためには専用の言語が必要であり、それがSouther