AIに任せる開発のための Verification 入門

Transcript

1. VERIFICATION 101 AIに任せる開発のための Verification 入門 テストが緑でも、動いているとは限らない test と verification の違いから CI への組み込みまで
2. 今日伝えたいこと 「テストが通った」ではなく 意図どおり動いた証拠を ゴールにする 実物を動かし、その証拠を取る仕組みが verification（検証）です。 AIに任せる開発のための Verification 入門 2
3. 01 / 導入 test と verification は答える問いが違う 観点 test verification 答える問い 書いた期待値どおりに動くか 主張した振る舞いが実際に起きたか 対象 関数・モジュール 起動したアプリ全体 合否の基準 テスト内のアサーション 仕様・再現手順・変更前の振る舞い 性格 回帰を防ぐ資産 変更を受け入れてよいかの確認 出力 pass / fail pass / fail / inconclusive ＋ 証拠 見逃すもの テスト自体の誤り、モックと本物の差 確かめなかった経路 AIに任せる開発のための Verification 入門 3
4. 01 / 導入 確かめたことを test に昇格させる STEP 1 STEP 2 STEP 3 確かめる 昇格させる 守る 変更のたびに、 その主張を実物で確かめる 守り続けたい振る舞いを 自動化して残す 回帰は test が防ぐので、 新しい主張に集中できる verification test 次の変更へ E2E テストは「verification を自動化して残したもの」と考えると整理しやすい。 AIに任せる開発のための Verification 入門 4
5. 02 / なぜ必要か ループを閉じる：AI が確かめ、人間は証拠を見る fail：結果を読んで直す 受け入れ基準 AI が実装する 実物を動かす 合格？ 人間が先に書く コードとテスト verify スクリプト 主張ごとに判定 確かめられなければ止まって報告 pass マージ 人間が証拠を確認 証拠を添えて報告 CI の必須チェック後 コードより先に証拠 コマンド・出力・画像 人間の主な仕事は、最初の基準づくりと最後の証拠の確認になる。 AIに任せる開発のための Verification 入門 5
6. 02 / なぜ必要か test だけでは足りない 3 つの理由 1 2 3 基準そのものが 書き換えられる 同じ誤解を 共有してしまう レビューが 追いつかない テストの書き換え・削除や、 テスト入力だけの特別扱いで 「合格」を取ることがある。 検証スクリプトも守る対象。 仕様の解釈も実装もテストも 同じ AI が書くと、 一つの誤解が 三つすべてに入り込む。 書くコストは下がったが、 確かめるコストは 下がっていない。 証拠なら、経験が浅くても 確かめられる。 AIに任せる開発のための Verification 入門 6
7. 03 / 原則 ツールが変わっても通用する 8 つの原則 01 02 03 04 主張を先に 言葉にする 基準は 実装者の外に置く 失敗しうる チェックにする 外から 観測する 「何が起きたら完了か」を 観察できる振る舞いで書く 正解を決めるのは 仕様・旧版・不変条件・人間 主張が偽なら fail になる ことを先に確かめる 利用者や他のシステムから 見える結果で判定する 05 06 07 08 書く人と 判定する人を分ける 証拠は 再現できる形で残す 深さは リスクに比例させる 確かめたことは 資産にする 実装の文脈から 独立した主体が判定する コマンド、入力、環境、 出力をまとめて残す 影響範囲、戻しやすさ、 利用者への影響で決める 守り続けたい振る舞いは test に昇格させる AIに任せる開発のための Verification 入門 7
8. 原則 03 ― 実務で最も効く原則 緑を見る前に、赤を見る バグ修正：修正前のコードで再現し、fail を確かめてから直す 新機能：入れる前の版や、機能フラグを切った状態で fail を確かめる どちらも難しいとき：わざと壊して fail になることを確かめる AIに任せる開発のための Verification 入門 8
9. 03 / 原則 主張は「前提・操作・観測できる結果」で書く 悪い主張 良い主張 ログインの不具合を直した セッション切れの状態でページを開き、再ログインすると、元のページに戻る CSV 出力を速くした 10 万行の出力にかかる時間が変更前の半分以下になり、 中身は変更前とバイト単位で一致する エラー処理を追加した 決済 API が 500 を返すと、画面に再試行ボタンが出て、注文は二重に作られない 主張が書けないうちは、何を作るかがまだ決まっていない。実装を頼む前に仕様を詰める。 AIに任せる開発のための Verification 入門 9
10. 03 / 原則 深さはリスクに比例させる 深さ 確かめること 対象の目安 L0 型チェック・lint・ビルド 名前の変更、ドキュメント L1 L0 ＋ 関連する test 局所的なロジックの変更 L2 L1 ＋ 変更した経路を実物で通す 通常の機能追加・バグ修正 L3 L2 ＋ 異常系・境界・永続化・周辺 複数の層にまたがる、データを書く L4 L3 ＋ 独立した検証者 ＋ デプロイ後の観測 決済・認証・データ移行など 決め手：影響範囲、戻しやすさ、データを書くか、お金やセキュリティへの影響、自信のなさ。 AIに任せる開発のための Verification 入門 10
11. 04 / 何を確かめるか 何を確かめるかは、4 つの要素で決まる 主張 オラクル 観測点 経路 変更で何が成り立つか 正解はどこから来るか どこを見て判定するか どの道筋を通すか 例：二回目に開いた リセットリンクは無効になる 仕様、再現手順、 変更前の振る舞い、 不変条件、人間の判断 画面、再読み込み後の状態、 DB、送信されたメール、ログ 正常、異常、境界、持続、 重複と並行、周辺、禁止事項 AI は正常系だけを作って、正常系だけを確かめがち。経路は依頼の時点で指定する。 AIに任せる開発のための Verification 入門 11
12. 04 / 何を確かめるか オラクル：正解をどこから得るか オラクル 向いている場面 注意点 仕様・受け入れ基準 新機能 仕様の穴はそのまま検証の穴 再現手順 バグ修正 修正前に再現できることが前提 変更前の振る舞い リファクタ・性能改善・依存更新 旧版のバグも「正解」になる 不変条件 データ処理・移行・並行処理 どの性質を選ぶかに経験が要る 正解ファイル パーサー・変換・帳票 更新は人が承認する 人間の判断 UI の見た目・文言 画像や動画で判断を速くする 実装した AI 自身をオラクルにしない。複数を組み合わせることも多い。 AIに任せる開発のための Verification 入門 12
13. 04 / 何を確かめるか 観測点：利用者に近いほど強い証拠になる 最も強い 利用者に見える結果 画面表示、CLI の出力と終了コード、API レスポンス 強い 永続化された状態 再読み込み後の画面、DB の行、生成されたファイル 強い 外部への副作用 送信メール、外部 API へのリクエスト（開発環境に受け口が必要） 補助 ログ・メトリクス エラーログが出ていない、処理時間 弱い 内部状態 関数の戻り値、変数の値（test の領域） 保存は、書いた経路とは別の経路で読み戻す。同じ経路だとキャッシュを見ているだけかもしれない。 AIに任せる開発のための Verification 入門 13
14. 04 / 何を確かめるか データとセキュリティは「応答」では確かめられない データ セキュリティ 応答ではなく、残った状態を見る 正常系では見えないので、否定形の主張で書く 別の経路で読み戻す 件数・合計・一意性の不変条件 途中で失敗させ、中途半端な書き込みがないか リトライ・二重実行・同時実行で重複しないか 「0 件処理して成功」を疑う AIに任せる開発のための Verification 入門 他人の ID や権限のないロールでは 403 / 404 レスポンスやログに秘密情報が出ない 不正な入力は拒否される 動かすために防御を緩めていない （認可の削除、 CORS の全開放、 TLS 検証の無効化） 14
15. 04 / 何を確かめるか 例：注文 API の 6 つの主張 データ セキュリティ ① 注文を作ると DB に 1 行でき、 金額・税・通貨が入力どおり ⑤ 別ユーザーのトークンで取得すると 404 ⑥ ログにもレスポンスにもカード番号が出ない ② 在庫が 1 減る（注文と同じトランザクション内で） ③ 決済が失敗したら、注文も在庫も変わらない ④ 同じリクエストを二回送っても注文は 1 件 失敗の確認（赤を先に見る） 在庫の処理をトランザクションの外に出すと ③ が fail、 所有者のチェックを外すと ⑤ が fail になることを先に確かめる AIに任せる開発のための Verification 入門 15
16. 04 / どう確かめるか 毎回同じ 8 つの手順で確かめる 1 主張を書く 2 オラクルを選ぶ 3 観測点と経路を決める 4 失敗することを確かめる Given / When / Then で観察できる形に 仕様、再現手順、変更前の振る舞い、不変条件 深さ L0〜L4 に応じて選ぶ 修正前、機能なし、わざと壊した状態で AIに任せる開発のための Verification 入門 5 実物で実行する 6 証拠を残す 7 独立した主体が判定する 8 記録し、昇格させる クリーンな環境から、決まった手順で コマンド、入力、環境、出力、画像を主張ごとに pass / fail / inconclusive 守りたい振る舞いは test に 16
17. 04 / どう確かめるか 良い証拠の 6 つの条件 条件 悪い例 良い例 主張に結びつく 「テストは全部通った」 「基準 3：二回目は無効表示（画像 2）」 再現できる 「手元で確認した」 実行コマンドと入力データ付き 外から観測 「関数が true を返した」 「再読み込み後も設定が残る」 反証できる 「エラーは出なかった」 「201、返った id で再取得し一致」 新しい 途中の版で撮った画像 最終コミットのハッシュ付き 正直 推測で pass と書く 「メール送信は未確認（inconclusive）」 AIに任せる開発のための Verification 入門 17
18. 04 / どう確かめるか AI への依頼文の型 目的：<何を変えるか> 主張（完了条件）： - <観察できる振る舞い 1> - <観察できる振る舞い 2> 基準：<仕様ファイル / 再現手順 / 変更前の出力> 確かめ方：<コマンドまたは手順書>。修正前に失敗することも確かめる 経路：正常系 / <異常系> / <境界> / 再読み込み後 報告：主張ごとに pass / fail / inconclusive と証拠 禁止：基準を変えて通さない。欠陥があれば止まって報告する < > を埋めて使う。最後の一行には、テストを書き換えて通す行動を減らす効果が報告されている。 AIに任せる開発のための Verification 入門 18
19. 05 / 仕組みと CI 仕組みにする：ハーネス・手順書・検証担当    ハーネス 手順書（スキル） 検証担当 1 コマンドで起動〜後片付け 結果は三値で返す 証拠の場所を記録する 失敗を起こす仕掛けを持つ 起動・操作・証拠の手順 禁止事項を明記する 機能ごとの地図を持つ 変更と同じ PR で直す 編集権限を持たない 主張と手順書だけを渡す 「通った」を信じず実行 主張ごとの表で返す 同じミスが繰り返されるなら、設計や lint で起きないようにする方が早い。 AIに任せる開発のための Verification 入門 19
20. 05 / 仕組みと CI CI は AI が書き換えられない判定者になる 速いチェック ビルド 必須：マージを止める 速いチェック（lint・型・単体テスト） 昇格した検証シナリオ inconclusive も失敗として扱う verify シナリオ 必須チェック 証拠を見てマージ 補助：判断材料を出す 基準の変更を検出して警告 AI による検証を PR に報告 失敗したときこそ証拠を保存 CI の後：L4 の変更は、デプロイ後もエラー率や指標を観測し、すぐ戻せるようにしておく。 AIに任せる開発のための Verification 入門 20
21. 05 / 仕組みと CI ツールは「原則の実装」として見る 原則 pstack Claude Code 主張を先に ゴールと確かめ方を渡す 仕様書の最後に検証手順 失敗しうる 先に再現してから直す 再現する失敗テストを先に 外から観測 アプリ専用の検証スキル /verify でアプリを起動 分離 書いた本人とは別の判定者 検証用のサブエージェント 資産にする 検証スキルを毎日保守 起動手順をスキルに記録 機能名は変わりやすい。どの原則をどう実現しているかで理解すると、別のツールにも応用できる。 AIに任せる開発のための Verification 入門 21
22. 06 / まとめ PR ごとのチェックリスト 依頼する前 受け取ったあと マージ前 主張を観察できる形で書いた 主張ごとに判定と証拠がある 必須チェックが通った オラクルを決めた 修正前に fail を確かめた 証拠を一つは開いて見た 深さと経路を決めた 別の経路で読み戻した 守りたいものを test にした 欠陥時は止まるよう伝えた 否定形の主張も確かめた 手順書も同じ PR で更新した inconclusive に理由がある AIに任せる開発のための Verification 入門 22
23. 06 / まとめ 持ち帰ってほしい 3 つのこと 1 主張を先に書き、基準を実装者の外に置く 2 緑を見る前に赤を見る。証拠は外から観測して残す 3 書く人と判定する人を分け、守りたい振る舞いは test に昇格させる 参考 Best practices for Claude Code ／ pstack guide（cursor/plugins） ／ ImpossibleBench（arXiv:2510.20270） ／ OWASP Top 10:2025 23