【続編】仕様駆動開発_20261114

【続編】最後は人が責任をもつ開発 説明できる・改修できる・テストで確かめる｜仕様駆動開発 × Claude Code うさうさ研修工房｜YouTube／Udemy 兼用・DXエンジニア向け実務講座（続編）

この続編のゴール（6つ） STEP1 講師の整理 1. 人が責任をもつ範囲を、AIに任せる範囲と線引きできる 2. 「説明の5問」に、資料を見ながら答えられる 3. 承認ゲートを、どこに置くか決められる 4. 改修を、変更依頼→影響範囲→仕様を先に直す→試験、の順で進められる 5. 回帰試験で、退行と試験の消失を見つけられる 6. AIの差分を人がレビューし、変更の記録と承認を残せる 前編：DX仕様駆動開発（スライド1〜26）の続き 2

全体の地図：8つのSTEP 講師の整理 難度9 難度6 難度5 難度4 STEP7 AIの差分を人が読 む 難度3 難度3 STEP6 難度2 STEP4 難度1 STEP2 STEP1 人が責任をもつ線 引き STEP3 承認ゲートを置く 改修の入口と影響 範囲 STEP5 改修ハンズオン テスト方法を整え る STEP8 運用へ持ち帰る 説明できる状態と は 難度は講師の設計（山場はSTEP7）。分数は目安 3

AIが書いても、責任は人に残る STEP1 講師の整理 作業は任せられる 判断は任せられない 責任は移らない 下書き、実装、試験の実行 、差分の要約。速く、数も 多くできる。 何を作るか。どこまで許す か。出してよいか。これは 人が決める。 事故が起きたとき、依頼者 や監査に説明するのは人。 AIは説明の相手にならない 。 講師の整理（公式の説明ではありません） 4

人が決めること／AIに任せること STEP1 講師の整理 場面 人 AI・機械 要件の合意 依頼者と合意する 整理の下書き 実装 差分を読んで承認 コードを書く 試験の実行 結果を読む 実行・集計 合否の最終判断 人が判断する 照合表を作る 本番への反映 承認する 手順書の下書き 秘密情報の扱い ルールを決める 仕組みで止める 設計案。実際の線引きは各社の規程・契約に従う 5

説明の5問と、答えの置き場 STEP2 講師の整理 問い 答えの置き場 1. 何を作った（変えた）か 仕様（FR・AC）と変更依頼 2. なぜそう決めたか ADR（代替案と根拠、置き換えの記録） 3. 何を確かめたか 照合表と、変更前後の試験結果 4. 何を確かめていないか OQと、未実施の項目 5. 誰が承認したか 承認記録（名前と日付） 5問は講師の整理。置き場は前編の仕様・ADR・OQ・照合表（書籍 第3・4・7章） 6

説明できない状態の例と原因 STEP2 講師の整理 こう聞かれる 答えられない原因 対処 なぜ上限は30秒なのか ADRがない 決定をADRに残す 試験は通っているのか 結果を人が書いた・古い JSONから機械的に作る 誰が許可したのか 承認記録がない 名前と日付を残す AIが勝手に変えたのでは 差分を読んでいない 差分レビューを工程にする 講師の整理。前編の失敗パターン（特典7）と対応 7

演習1：説明の5問を埋める STEP2 動画を止めて取り組む（目安 10分） 講師の整理 問い 記入例（CR-01） 何を変えた 429が続くときの待ち時間に上限30秒を追加（NFR-01、AC-05・AC-06） なぜ 待ち時間が際限なく伸びると業務が止まる。上限30秒は現場の運用要件（ 数値は例）。ADR-010 何を確かめた 変更前後の照合：AC-01〜04は合格のまま、AC-05・06が新規合格 確かめていない 実APIでの動作、30秒の妥当性の現場確認（OQ-03） 誰が承認 （名前）／（日付）。AIは承認者にならない 右列は変更依頼 CR-01（待ち時間の上限）の記入例。数値は例 8

承認ゲートを置く4か所 STEP3 講師の整理 ゲート 人が見るもの 通過の条件 G1 仕様の合意 要件・AC・OQ 依頼者と合意した記録 G2 実装の前 仕様を先に直したか・ADR spec.md が更新済み G3 取り込みの前 差分・照合表・前後のdiff 退行ゼロ・消失の説明 G4 本番の前 承認記録・少量確認・戻し方 社内承認フローを通過 設計案。ゲートの数・名前は各社の開発プロセスに合わせて調整 9

Claude Codeでの人の関与（公式） STEP3 公式 既定は承認が要る ルールで固定できる 承認の形骸化に注意 ファイルの変更やBashの 実行は、既定では承認が必 要。読み取り専用の一部は 不要（公式） deny→ask→allow の順に 評価。ask に入れた操作は 、毎回確認が入る（公式） 「いつも許可」を重ねると 、確認が形だけになる（講 師の整理）。ゲートは仕組 みで置く 公式：code.claude.com/docs/en/permissions（2026-11-14 確認）。3枚目は講師の整理 10

約束と強制：フックで止める（公式） STEP3 公式 論点 公式の記述（要約） フックとは ライフサイクルの特定の時点で動くシェルコマンド。「LLMの判断に 頼らず、必ず実行される」決まった動きを作れる 止める例 PreToolUse フックで Edit や Write の前にスクリプトを動かし、保護 対象のファイルなら終了コード2で止める。止めた理由は Claude にフ ィードバックされる 設定の監査 ConfigChange イベントで、設定ファイルの変更を記録したり、終了 コード2などで止めたりできる CLAUDE.md との違 い CLAUDE.md は文脈で強制ではない。確実に止めたいことはフック等 を使う 公式：code.claude.com/docs/en/hooks-guide ／ memory（2026-11-14 確認）。表現は要約 11

改修の流れ：9ステップ STEP4 講師の整理 1. 変更依頼（CR）を書く 2. 影響範囲を、番号で逆引きする 3. 仕様を先に直す（ACを追加・更新） 4. 決定を記録する（ADRは消さず「置き換え」） 5. 変更前の試験結果を保存する 6. 実装する（AIでもよい） 7. 試験を実行し、変更前後を比べる 8. 人が差分を読み、承認する 9. 版と変更履歴を更新する 設計案。前編のルール（仕様を先に直す・ADRは置き換え）に沿った流れ 12

影響範囲を番号で逆引きする STEP4 実行確認済み $ python3 impact.py NFR-01 対象ID: AC-05, AC-06, NFR-01 仕様: AC-05 (NFR-01) 待ち時間が試行ごとに増える AC-06 (NFR-01) 待ち時間は上限30秒を超えない コード・試験: app/retry.py:4: BACKOFF_CAP_SEC = 30 # NFR-01 app/retry.py:30: ... 上限は BACKOFF_CAP_SEC。NFR-01 tests/test_contract.py:26: test_AC_05_... tests/test_contract.py:29: test_AC_06_... 読み方 1. 番号を付けてあるから、仕様→コード→試験が たどれる 2. 再実行すべき試験が分かる（影響範囲） 3. 「該当なし」は、番号が付いていない合図 限界（実行で確認した範囲） 1. 文字列の一致で探すだけ 2. 番号を書いていない依存は見つからない 3. 最終的な影響の判断は人が行う sample-kit2 の impact.py を実行した出力（抜粋）。文字列の一致で探す簡易版 13

変更依頼（CR）とADRの置き換え STEP4 受講資料 CR-01 1. 依頼：429が続くとき、待ち時間が 長くなりすぎないようにしたい 2. 影響範囲：NFR-01 / AC-05・AC-06 app/retry.py、tests/test_contract.py 3. 仕様の更新：先に直した 4. 決定：上限30秒 → ADR-010 5. 試験：変更前の結果を before.json に 6. 承認：確認者（人）____ 日付____ ※AIは承認できない ADR-010：待ち時間の上限を30秒にする 状態：採用（ADR-00x を置き換え） 背景：上限がなく、待ち時間が伸び続ける 決定：上限30秒（数値は例） 代替案：A 上限なし B 上限10秒 根拠：現場の運用要件／AC-06の試験結果 影響：30秒を超える待ちは発生しない 関連：NFR-01、AC-05、AC-06、OQ-03 ルール：既存の決定は消さず「置き換え」と書く CRは sample-kit2/docs/change-request.md。ADRの形は特典2。ADR-010の中身は記入例 14

★改修ハンズオン：待ち時間の上限 実行確認済み BACKOFF_CAP_SEC = 30 # CR-01 def backoff_sec(tries): """1,2,4…秒。上限は30秒。 NFR-01""" return min(2 ** (tries - 1), BACKOFF_CAP_SEC) # send_with_retry の中： # sleep(backoff_sec(tries)) STEP5 動画を止めて取り組む（目安 15分） 手順 1. 変更前の結果を保存（before.json） 2. 仕様を先に直す：AC-06 を spec_ac.csv に追加 3. 試験を先に書く：test_AC_06_... → 実装前に不合格になることを確かめる（Red） 4. 実装する 5. python3 run_tests.py → trace.py 6. diff_results.py before.json results.json 制作時の結果：7件合格、AC-05・06が新規合格、 AC-01〜04は変化なし 左：sample-kit2 の app/retry.py（実行確認済み）。右の手順は設計。Redの確認は受講時に実施 15

改修時のテスト：目的で分ける STEP6 受講資料 種類 確かめること 改修での使いどころ 回帰試験 既存の動きが壊れていないか 変更のたびに全件を実行 新規の試験 追加した要件が満たされるか ACを追加したら先に書く 境界値の試験 上限・下限・ちょうどの値 30秒、3回など数字のあるAC 壊しに行く試験 不正な入力でも壊れない 入力や応答の形を変えたとき 性質の試験 どんな入力でも成り立つ性質 計算を変えたとき（乱数で多数） 出典：書籍 第6章（壊しに行く試験・性質の試験）に、回帰試験の整理を加えた講師の整理 16

デモ：変更前後の照合diff STEP6 実行確認済み AC 変更前 変更後 判定 不具合を入れた時 AC-01 〜04 合格 合格 変化なし 変化なし AC-05 未実施 合格 新規合格 新規合格 AC-06 未実施 合格 新規合格 不合格（新規不合格） sample-kit2 の diff_results.py を実行。右列は上限の処理を外す不具合をわざと入れた場合 17

デモ：試験が消えたら気づく STEP6 実行確認済み 見え方 意味 人がすること 合格 → 不合格（退行） 既存の動きを壊した 原因を調べ、直す。承認しない 未実施 → 不合格 新しい要件を満たしていない 実装か試験を直す 合格 → 未実施（消失） 試験が消えた 理由の説明を求める 未実施 → 合格 新しい要件が確かめられた 内容が妥当か読む sample-kit2 の diff_results.py を実行。AC-04の試験を削った場合は終了コード1 18

試験を信じる前に、試験を試す STEP6 講師の整理 確認 やり方 見つかるもの わざと壊して不合格にな るか 実装を1か所壊し、該当ACが不合格に なるか見る 何も確かめていない試験 試験名とACの一致 impact.py で番号を逆引きする 対応のずれ 期待値が緩くないか assert の中身を読む（常に真になって いないか） 緩い判定 削除・skipの有無 diff で合格→未実施を探す 試験の無効化 講師の整理。1は前編で実行確認済み（429を再試行しない不具合でAC-02が不合格） 19

山場：AIの差分を人が読む3点 STEP7 講師の整理 仕様にない変更 試験を弱めていないか 秘密・権限に触れていない 頼んでいないファイルや処 理が混ざっていないか。変 更依頼の影響範囲と、差分 のファイルを突き合わせる 削除、skip、期待値の緩和 、例外の握りつぶし。diff の「消失」と、assertの中 身を見る キー、設定、権限ファイル の変更。denyやフックの設 定が緩められていないか 講師の整理（レビュー観点の設計案） 20

★ハンズオン：説明できる状態を作る STEP7 動画を止めて取り組む（目安 20分） 未確認 ★1 変更前後の照合を取る - before.json を保存してから実装 - run_tests.py → diff_results.py - 退行ゼロ・消失ゼロを確かめる AIへの依頼（設計案） 「この差分を、(1) 仕様にない変更 (2) 試験の削除・ 緩和・skip (3) 秘密や権限の変更、の観点でレビュー して。根拠は行番号で」 ★2 説明の5問を埋める - 何を変えた／なぜ／確かめた - 確かめていない／誰が承認 - 承認欄は人が書く（AIは書かない） 「変更の記録を、ACの番号つきで書いて。確かめて いないことも書いて」 人が確かめること 1. 行番号の根拠を実際に開いて見たか 2. 記録が照合表・diffと一致しているか 3. 承認欄に自分の名前を書けるか プロンプトは設計案。Claude Code上での通し実行は今回未確認（収録前に必ず通し確認）。承認欄は人が書く 21

責任分界を、名前で書く STEP8 講師の整理 役割 名前 見るもの 依頼者（業務側） （名前） 要件・ACが業務の意図と合っているか 開発責任者 （名前） 仕様・ADR・OQ・照合表 レビュー者 （名前） AIを含む差分、試験の削除や緩和 承認者 （名前） 承認記録、本番前の少量確認、戻し方 講師の整理（テンプレート）。役割名は各社に合わせて変更。兼務は理由を書く 22

引継ぎ・証跡・版 STEP8 受講資料 引継ぎ書の5点 証跡を残す 版で管理する 1. 仕様 2. ADR 3. OQ 4. 照 合表 5. 承認記録。説明の5 問と対応させる 変更ごとに、before・after ・diffを日付のフォルダへ 。判定欄と承認欄は人が記 入 版は1か所で管理。Gitは版 ごとにタグ。変更履歴に、 CR番号とADR番号を書く 出典：書籍 第9章（配布と証跡）に、承認記録を加えた講師の整理 23

よくある失敗（続編） STEP8 講師の整理 失敗 起きること 対処 AIの変更をそのまま承認 仕様にない変更が入る 影響範囲と差分を突き合わせる 仕様を直さず実装だけ変更 仕様と実装がずれる 先に仕様を直す 試験を消して緑にした 退行を見逃す diffの「消失」を確認する 承認者が不明 事故のとき説明できない 名前と日付を残す 変更の理由が残らない 同じ議論を繰り返す ADRを置き換えで残す 影響範囲を見ずに改修 別の機能が壊れる 番号で逆引きする 講師の整理。前編の失敗パターン12件の続き 24

修了課題と、修了の基準 STEP8 動画を止めて取り組む（目安 60分） 講師の整理 提出物 必須の中身 変更依頼 CR-02 依頼、影響範囲（impact.py の出力）、承認者の欄（人の名前） 仕様とADR 先に直した仕様（ACの追加）、ADRの置き換え（代替案2つと根拠） 試験と前後のdiff 新規の試験、回帰の結果、退行・消失がゼロであること（または理由） 説明の5問 「確かめていない」を含め、空欄がない レビュー記録 差分レビューの3観点と、根拠の行番号を人が確認した印 課題は講師の設計。配点・合格ラインの数値は設けない（根拠がないため）。必須項目で判定 25

確認したこと／未確認のこと 公式 区分 内容 確認した（公式） 承認の既定と評価順／フックの役割・編集を止める例（終了コード2）／ ConfigChange（2026-11-14） 確認した（実行） sample-kit2：7件合格／不具合投入でAC-06不合格／試験削除でAC-04が 消失（終了コード1） 講師の整理 責任の線引き・説明の5問・4ゲート・レビュー3観点は設計案（公式・規 格ではない） 未確認 Claude Code上のハンズオン／フックの実設定／各社の承認フローとの適 合／実API 出典：code.claude.com/docs/en/permissions・hooks-guide・memory（2026-11-14） 26

この資料の使い方 講師の整理 1. スライド1〜26は講師用と同じ番号です。台本の【スライドN】と対応します 2. の場面（8・15・21・25）は、動画を止めて手を動かしてください 3. 「公式」は公式の事実、「講師の整理」は講師の解釈です。分けて読みましょう 4. 「未確認」の印は、受講前に自分で確かめてください 5. 承認欄には、必ず人の名前を書きます 受講生用のみ。講師用と番号は同じ（27以降が追加） 27

考えてみよう（5問） 講師の整理 1. 説明の5問を言ってください 2. AIが「試験が通りました」と報告したとき、最初に確かめることは？ 3. CLAUDE.md に書いたルールは、必ず守られますか。確実に止めたいときは？ 4. 変更前の結果を、実装の前に保存する理由は？ 5. 承認欄に名前を書けない変更は、どうしますか 答えの目安は次のスライド 28

答えの目安 講師の整理 1. 何を作ったか／なぜ決めたか／何を確かめたか／何を確かめていないか／誰が承認したか 2. 変更前後の照合で、退行と試験の消失がないか。合格の文字だけを信じない 3. 必ずとは言えない（CLAUDE.mdは文脈・公式）。フックや権限等の仕組みで止める 4. 変更前後を比べるには、変更前の結果が要る。後からは作れない 5. 承認しない。足りない記録を揃えるか、確認できる人に回す 目安であり、唯一の正解ではない 29

用語集 講師の整理 用語 意味 CR（変更依頼） 変更の依頼・影響範囲・承認を1枚にしたもの 影響範囲 変更で再確認が要る仕様・コード・試験の集まり 回帰（リグレッション）試 験 既存の動きが壊れていないかを確かめる試験 退行 以前は合格だったものが不合格になること 消失 以前は合格だった試験が、実行されなくなること 承認ゲート 人が確認して通す、工程上の止める場所 講座内での意味 30