仕様駆動開発の、その先へ。決める力と確かめる仕組み

Transcript

1. 仕様駆動開発の、その先へ 決める⼒と確かめる仕組み 稲⽥ ⼤陸 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト © 2026, Amazon Web © 2026, Services, Amazon Inc. or Web its Services, affiliates.Inc. All or rights its affiliates. reserved.All rights reserved. 1
2. 稲⽥ ⼤陸 / いなだ りく • 経歴 • 製造業のお客様を中⼼に⽀援する ソリューションアーキテクト • 最近の取り組み • AI 駆動開発ライフサイクルの推進 • Kiro, AWS Amplify の情報発信 @inada_riku © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2
3. コーディングエージェントを、 仕事で週に 1 回以上使っている⽅ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 3
4. そのうち、 AI が書いたコードをどう確かめるか、 チームで決めている⽅ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 4
5. 道具は、ほぼ⾏き渡った 90% 68% 週に 1 回以上、職場で コーディングエージェントを使う 毎⽇使う 出典 : JetBrains Developer Ecosystem Survey 2026（2026 年 5〜7 ⽉、プロの開発者 1.5 万⼈） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 5
6. 同じ道具でも、結果は組織によって違う AI の導⼊度が⾼いほど AI は増幅器 強い組織はより強く、 デリバリーの速さ 不安定さ 弱い組織は負債をより速く積む 出典 : DORA「Balancing AI tensions」（2026-03） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 6
7. 同じ道具を使うなら、 差はどこで出るのか © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 7
8. 今⽇の流れ 1 詰まる場所が両端に移った 2 何を作るかを決める 3 確かめる仕組みを作る 4 ゲートを設計する 5 ⼿元に何が残るか 6 明⽇から始めること この 2 年で、何が変わったか 仕様に何を書くか 性質のテストと、期待値の置き場所 層、承認、往復の上限 検収と、次の案件 置き場所と、最初の⼀歩 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 8
9. 詰まる場所が両端に移った この 2 年で、⼈が確かめる単位は どう変わったか © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 9
10. 詰まる場所が両端に移った ⼈が確かめる単位は、2 年で⼤きくなり続けた 確かめる単位 ループと パイプライン とゲート 1⾏ 差分 仕様 2024 年 2025 年前半 2025 年後半 2026 年前半 2026 年後半 詰まる場所 詰まる場所 詰まる場所 詰まる場所 詰まる場所 モデルの能⼒ ⽂脈の渡し⽅ 意図の伝え⽅ 確かめる仕組み ⼈の注意と 開発基盤 完了条件 仕様駆動開発: 先に要件、設計、タスクを書き、それに沿って作る（2025 年後半〜） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 10
11. 詰まる場所が両端に移った 速くなったのは真ん中で、詰まっているのは両端 決める 書く 確かめる 何を作るか 速くなった 正しくできたか 詰まっている 詰まっている Anthropic の 1 ⽇のマージ 決めること 動く前に⽅向づける。 仕様、業務ルール、規約 約 2,500 件 → 3 万件超 （2026 年 5 ⽉ → 9 ⽉） 詰まったのは、 ソース管理、CI、レビュー 確かめる仕組み テスト、解析、レビューの検査と、 その結果で⽌めるゲート ⼈の役割: 同じ問題が繰り返し起きたら、決めることと確かめる仕組みを直す 出典 : Anthropic「Redesigning source control at Anthropic」（2026-10-13） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 11
12. 詰まる場所が両端に移った ⽇本の現場では、もともと要件が⼀番の壁だった 開発⽣産性を阻む要因（上位 3 つ） 53.5% 要件定義の不明確さ 会議の過剰な頻度 コミュニケーションの⾮効率 38.7% 33.6% 出典 : ファインディ株式会社調べ「開発⽣産性」に関する実態調査（2025 年、798 名） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 12
13. 何を作るかを決める エージェントが動く前に、 何を決めておくか © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 13
14. 何を作るかを決める 設計書は、納品した⽇から古くなる Excel の設計書 リポジトリの仕様 置き場所 ファイルサーバー コードと同じリポジトリ 読む⼈ ⼈だけ ⼈とエージェント コードとのずれ ⼈が⽬で追う テストで確かめ直す 案件のあと 古いまま残る 次の変更に使う ⽬指すのは、実装のあとも残して次の変更に使い続ける仕様（spec-anchored） 元になる仕様はリポジトリに置き、顧客にはこれまでの形式で書き出して納める © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 14
15. 何を作るかを決める 仕様には、タスクより判断と完了条件を書く 判断と、選ばなかった案 作らないこと、してはいけないこと なぜこの案にしたか 範囲の外と、禁⽌の条件 完了の条件 間違えたときの重さ 何をもって終わりとするか どちらに倒すか 何が欲しいかを⼈が最初に明確に書いていなければ、正しさはどの検査でも確かめられない © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 15
16. 何を作るかを決める 例: 送料無料の判定を、クーポンを使ったあとの⾦額にする ネット通販の改修（説明⽤の架空の案件）。いまは商品の合計が 5,000 円以上なら送料無料 商品の合計 5,200 円 クーポン −500 円 ⽀払う⾦額 4,700 円 いま: 割引前の⾦額で判定 変更後: 割引後の⾦額で判定 5,200 円 ≥ 5,000 円 なので送料無料 4,700 円 < 5,000 円 なので送料がかかる © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 16
17. 何を作るかを決める 判断と、選ばなかった案を書く 案 中⾝ 判断 A 割引前の⾦額で判定（いま） 変える B クーポンを使ったあとの⾦額で判定 採⽤ C 会員ランクごとに基準の⾦額を変える 今回は選ばない。 値付けの判断が要り、顧客が決める C を選ばなかった理由は、次の案件でよく聞かれる © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 17
18. 何を作るかを決める 作らないこと、してはいけないこと、間違えたときの重さを書く 作らないこと ポイント払いは、今回の判定に含めない 重い 送料を取りすぎると、クレームと返⾦になる してはいけないこと（テストにする） 相対的に軽い NG-1 確定した注⽂の送料を変えない NG-2 クーポンのコードを、ログに出さない 取り損ねても、1 件あたり数百円の損 だから要件で決めきれない条件（端数など）は、買う⼈に有利な側にすると顧客と決めておく。 切り替える前に、過去の注⽂で、いまと新しい判定を並べて流す © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 18
19. 何を作るかを決める 完了の条件は、要件のファイルに EARS と例で書く AC-1 注⽂を確定するとき、割引後の⾦額が 5,000 円以上なら、システムは送料を無料にする AC-2 割引後の⾦額が 5,000 円未満のとき、 システムは送料を加える EARS の形で書き、条件の ID をテストと PR まで引き継ぐ 境界の例（顧客と合意） 4,700 円 ← 送料がかかる © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 5,200 円 − 500 円 5,500 円 − 500 円 4,999 円 5,000 円 5,200 円 5,500 円 送料無料 → 19
20. 何を作るかを決める 判断は設計のファイルに、業務の決まりは毎回読むファイルに design.md Steering/ ツールでは: Kiro は design.md と steering、Spec Kit は plan.md と constitution © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 20
21. 確かめる仕組みを作る できたものを、 何で確かめるか © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 21
22. 確かめる仕組みを作る 費⽤を抑えたモデルでは、書いてある要件も抜け落ちる 費⽤を抑えたモデルで、10 回作らせた 3/10 落ちたのは、端の部分 • 時間切れのときの応答 仕組みなし • 送信メッセージの契約の細部 10/10 • エラー応答の種類 • 環境変数の名前 仕組みあり • 合格 ◦ 不合格（10 回作らせた結果） 要件は詳しく書いてあった。落ちたアプリも、 178 件の検査のうち 144 件以上には通っていた 検査が⾚になるたびに、抜け落ちた要件にエージェントの注意が戻る 上位モデルは検査なしでも 10 回とも通った。そう⾔えたのは、独⽴した 178 件の検査があったから 出典: martinfowler.com「Are Harnesses Worth the Cost?」（2026-10）。新規サービス 1 つで各 10 回。著者は検査に使ったツールの作り⼿ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 22
23. 確かめる仕組みを作る 完了の条件から、確かめる性質を取り出す 完了の条件（EARS） 性質（プロパティベーステストにする） AC-2 割引後の⾦額が 5,000 円未満の とき、システムは送料を加える 1 割引後 5,000 円未満なら、必ず送料がかかる AC-1 注⽂を確定するとき、割引後の ⾦額が 5,000 円以上なら、システム は送料を無料にする 2 割引後 5,000 円以上なら、送料は 0 円 3 クーポンなしなら、いまと結果が同じ 変えてはいけないこと いまの動きと、計算の前提 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 4 商品の並び順を変えても、結果は同じ 23
24. 確かめる仕組みを作る いまと変更後の違いを、⾒分けられる性質を選ぶ 商品 5,200 円 クーポン −500 円 ⽀払い 4,700 円 いま（A 案） 送料無料 性質 1 に反する 割引後は 5,000 円未満なのに、 送料がかかっていない 性質 1 性質 4 A 案では崩れ、B 案では成り⽴つ。 変更を⾒分けられる A 案でも B 案でも成り⽴つ。 これだけでは変更を確かめられない テストが通ることより、何を⾒分けられるテストかが⼤事 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 24
25. 確かめる仕組みを作る テストの数とカバレッジだけでは、品質を説明しきれない これまで AI が書くと 検収で加えて⽰す • テスト密度（1,000 ⾏あたりの • ⾏数は機能の量と⽐例しない • 完了の条件ごとにテストがあるか テスト項⽬数）、バグ密度、 • テストはいくらでも増やせる • 誤りを⼊れるとテストが落ちるか • 同じエージェントが書いた （ミューテーションテスト。 カバレッジで品質を説明してきた • コードもテストも⼈が書き、 量が⼿間に⽐例する前提 テストは、同じ思い込みで通る • 性質 1 つで何百通りを試す Stryker、PIT など） • 過去の注⽂で結果が変わらないか テストは、項⽬数では 少なく⾒える 実例: カバレッジ 100% のファイルに、単体テストが 1 本もなかった わざと⼊れた誤り 13 個がテストをすり抜けた。⼤きな受け⼊れテストが通過していただけで、結果は確かめていなかった 出典: martinfowler.com「Maintainability sensors for coding agents」（2026-05） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 25
26. 確かめる仕組みを作る エージェントを増やす前に、Git と CI Git と CI（テストが毎回回る） 増やしても⼟台が⽀える 増やすほど不安定さが増える 回答者の 15.8% が VSS、13.7% が Subversion。CI/CD に満⾜しているのは 14.2% 型のある⾔語、はっきりしたモジュール境界、CI があるコードほど、確かめる仕組みを置きやすい 出典: ファインディ株式会社調べ「開発⽣産性」に関する実態調査（2025 年、798 名） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 26
27. 確かめる仕組みを作る 要件の ID を持つテストを、変更のたびに⾃動で回す テストの名前に、要件の ID を⼊れる 毎回、⾃動で 性質 1〜4 を、ランダムな⾦額と クーポンで 100 通りずつ試す 反例は最⼩の⼊⼒にして⽰す ID の数で⽌める ID にテストがあるかを数え、⽋ けたら⽌める。中⾝が⾜りるかは 別に⾒る ツールでは: Kiro は要件からテストを作り hooks で回す。AI-DLC v2 は、作る役とは別の確かめ役と承認ゲート © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 27
28. 確かめる仕組みを作る 期待値は合意した仕様と例で作り、エージェントに弱めさせない 顧客と合意した 機械で照合 仕様と境界の例 期待値 テスト 例が仕様に合っているか 鍵をかける 判定する 同じエージェントが、実装とテストの両⽅を要件 から作ると 同じ読み違いが、両⽅に⼊る × 期待値は弱めさせない 落ちたら 実装を直す の実装 例では: 境界の例の表と、過去の注⽂で並べた結果を、エージェントが書き換えられない判定に使う © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 28
29. 確かめる仕組みを作る 3 つのループで回す 承認 実⾏ 判断と完了条件 仕様に書く ⼈ 受け⼊れ 仕組みを 直すループ 直すループ 計画 検査が⾚なら直す エージェントが回す 検査 ⼈が回す 例: 5,000 円で⾚なら判定を直す 直す 学ぶ 検査とゲートを直す 例: テストのない ID が続いたら ID を数えるゲートを⾜す 学ぶループ 落ちた理由を書き⾜す エージェントが書き、⼈が確かめる 例: 5,000 円ちょうどを表に 1 ⾏⾜す ⼟台: 決めることと、確かめる仕組み © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 29
30. ゲートを設計する 確かめる仕組みを、 どこに、どう置くか © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 30
31. ゲートを設計する 1 つのゲートではなく、層で受け⽌める 書いている間 機械 性質のテストを回す LLM 別のエージェントが 読む PR ごと マージ前 LLM ⼈ 確かめた指摘だけ 出す AI レビュー ⼈の承認 （送料の計算も） 出荷時 出荷後 機械 機械 段階的に切り替える 指標を⾒て戻す 機械 ⽌める検査（型、 Lint、性質、AI に ⾒せないシナリオ） LLM 定期的に: AI によるモジュール性とセキュリティのレビュー、依存関係の鮮度 Claude Code のリポジトリ（6 ⽉→9 ⽉）: PR 2 倍超、リバート 4 割超減 出典: Anthropic「How the Claude Code team does code review」（2026-10） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 31
32. ゲートを設計する いつもの品質ゲートに、⾜すもの 判断、完了条件、境界の 例を合意 顧客と開発チーム 設計レビュー 本番移⾏ 受⼊テスト 結合テスト 単体テスト 書いたのとは別の AI のレビュー AI と開発チーム 段階的な切り替えと戻し⽅ 顧客と開発チーム 現⾏との⽐較、ID の対応表 顧客 契約と例の検査、AI に⾒せないシナリオ 機械 性質のテスト、誤りで落ちるか 機械 コードレビュー ⼯程は変えず、各⼯程に⾜す（オレンジの⽂字）。いまの記録と成績書は、これまでどおり出す © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 32
33. ゲートを設計する 判定は外で⾏い、指⽰ではなく仕組みで強制する 読めない・書けない・黙って変えられない エージェントの作業場所 ⾃⼰申告で終えない 「できました」ではなく、実⾏した出⼒を⾒せる。 完了の判定は別の役がする 判定のデータ × シナリオは⾒せず、 境界の例は書かせない × CI の設定と、検査を弱める変更 × テストの削除や期待値の緩和は、 ⼈が理由を確かめるまで⽌める 資格情報 サンドボックスの外に置く 指⽰のファイル（AGENTS.md）に書くだけでは守られない。hooks と CI が作業場所の外から強制する © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 33
34. ゲートを設計する ゲートの出⼒は、エージェントが直せる形で返す ⼈向けの出⼒（ESLint の標準の出⼒） エージェント向けの出⼒（直し⽅を書き⾜す） 出⼒は数⾏に 例外がレビューの⼊⼝ 詳細はログへ。時間のかかるテストは⼀部だけ流す AI が抑制した警告や上げた上限から、⼈が読み始める 直し⽅を書かなかった規則だけ、AI が上限を上げがちだった 出典: martinfowler.com「Maintainability sensors for coding agents」（2026-05） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 34
35. ゲートを設計する ⼈の承認は変更の中⾝で段階を決め、コミットに結び付ける 変更 ⾃動で段階を決める 変わったファイルと 変更の種類で 低 承認なし • 承認はコミットに結ぶ 案内⽂の修正 • エージェントの承認は、 ⼈の代わりにならない 中 1⼈ 商品⼀覧の表⽰ • 重要な指摘は、 答えるまでマージ不可 ⾼ 2⼈ 送料と課⾦の計算、CI 受託なら、⾼は社内 2 ⼈。顧客の承認が要る変更（課⾦など）は、いつもの変更管理に乗せる © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 35
36. ゲートを設計する ゲートの往復には、上限を付ける 修正 作る ほかに決めたこと レビューする • 同じ種類はまとめて指摘 指摘 3 回まで ⼀晩で 50 回以上 • 2 回⽬以降は差分だけ⾒る • 同じ指摘を繰り返さない 超えたら⼈へ ⼈ エージェント同⼠で往復した PR • ⾃動の修正は回数に上限 約 59% 繰り返された指摘の約 6 割は、 1 回⽬のレビューからあったコード だから 2 回⽬以降は差分だけ⾒る 出典: Anthropic「How the Claude Code team does code review」（2026-10） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 36
37. ゲートを設計する いつ、何回⾛らせるかは、モデルと変更の重さで決める 前の実験の続き 開発中の検査なし 開発中の検査あり 上位モデル 10/10 10/10 約 0.41 ドル 約 2.68 ドル（約 7 倍） 費⽤を抑えた 3/10 10/10 約 0.09 ドル 約 0.27 ドル モデル 変わるのは、いつ⾛らせるか。受け⼊れ前の独⽴した検査は、どのモデルにも残す 損失の⼤きい変更（送料の計算）には深い検査を、⽂⾔の修正には軽い検査を 出典: martinfowler.com「Are Harnesses Worth the Cost?」（2026-10）。費⽤はトークンからの推定で、⼈の⼿間は含まない © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 37
38. ⼿元に何が残るか 案件が終わったあと、 何が⼿元に残るか © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 39
39. ⼿元に何が残るか 案件が終わったとき、リポジトリにはこれが残る 決めたこと • 要件と境界の例（AC と NG の ID） • 判断と選ばなかった案 • 送料と割引の業務ルール 確かめる仕組み • 性質 1〜4 のテスト • いまとの⽐較の結果 • 直し⽅を書いた Lint の規則 • hooks と CI、ID の対応表 どれもコードと同じリポジトリに置き、コードと⼀緒に変える。どのファイルに置くかは最後に © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 40
40. ⼿元に何が残るか 仕様とソースを 1 対 1 にしなくても、つながりは⽰せる 要件の ID テスト（名前に ID を持つ） AC-1 性質 2、境界の例 5,000 円以上なら送料無料 AC-2 5,000 円未満なら送料を加える NG-1 確定した注⽂の送料を変えない NG-2 クーポンをログに出さない AC-3 あとから⾜した要件 性質 1、境界の例 確定後の再計算のテスト PR PR AC-1〜NG-2 の ID 使った AI のモデルと版 対応表は CI が毎回作る ログの検査 テストがない → CI が⽌める テストのない ID が 1 つでもあれば⽌める。規格や顧客が求める⽂書は、この表から書き出す © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 41
41. ⼿元に何が残るか 検収で⽰せることと、次に持ち越せること 検収で 次の変更で 次の案件で ID の対応表で、 何をどう確かめたかを ⽰せる C 案に進むとき、 選ばなかった理由が 残っている 決めたことと 確かめる仕組みを テンプレートにして 持ち越す © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 42
42. 明⽇から始めること 明⽇、何から始めるか © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 43
43. 明⽇から始めること 書いて読ませるものと、仕組みで強制するもの 書いて読ませる（エージェントは⽂脈として読む。守られるとは限らない） 今⽇の話 Kiro Claude Code 毎回守らせる決まり、規約 .kiro/steering/ CLAUDE.md 1 つの変更の仕様 .kiro/specs/<機能>/ 決めた場所を CLAUDE.md で指す 繰り返す⼿順 .kiro/skills/ .claude/skills/ 仕組みで強制する（エージェントの判断に関係なく効く） 毎回の検査 .kiro/hooks/ settings.json の hooks 判定のデータを書かせない .kiro/agents/ の permissions settings.json の permissions 別のエージェントのレビュー .kiro/agents/ .claude/agents/ 最後のゲート（ID の数、検査を弱める変更の検出）は CI に置く。どのツールでも同じ。 GitHub Copilot なら、指⽰は .github/copilot-instructions.md に書き、強制は CI に寄せる © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 44
44. 明⽇から始めること 送料の例のリポジトリを、2 つのツールで置くと Kiro © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Claude Code 45
45. 明⽇から始めること いまいる段階から、次の⼀歩 毎⽇の雑務を 1 つ 次の案件で 1 機能だけ、境界の例と 性質のテストを 1 つ作る Git に移し、 CI を回す 2 1 並⾏して使う 0 1 つの会話 複数を同時に Git と CI ⼈と 1 対 1 で進める ⾛らせる © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 定期実⾏に任せる 5 4 エージェントが 3 キューでつなぐ 割り振る 記憶と定期実⾏ 作業を順番待ちに 取りまとめ役が 前の作業を覚え、 ⼊れて次へ流す 作業を分けて渡す 決まった時刻に動く 46
46. 明⽇から始めること ⼈に残る判断 作るべきか ⾼リスクの箇所 真似される設計 証拠を読む 結果への責任 ⽅向と範囲 課⾦、⾃動更新、 CI 他の⼈が従う型 何を確かめ、 何を⾒逃すか 誰が書いたかに 関係なく 良いハーネスは、⼈の⼊⼒をなくすことではなく、 ⼈の⼊⼒が⼀番効く場所に向けることを⽬指す 出典: Birgitta Böckeler（martinfowler.com、2026-04） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 47
47. 明⽇から始めること 持ち帰ってほしい 3 つ 1 2 3 仕様には、タスクより判断と完了条件を書く。 書いていない正しさは確かめられない 確かめる仕組みは、変更を⾒分けられるテストで作り、 作る側から切り離して層で受け⽌める。 期待値はエージェントに弱めさせない 仕様と確かめる仕組みをリポジトリに残し、検収と次の案件に使う © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 48