AI開発を加速するためにテスト戦略を言語化した

Transcript

1. AI開発を加速するために テスト戦略を言語化した Go Connect #13 — 2026/05/20 朱 義宏 / GMOペパボ 1
2. 自己紹介 朱 義宏 GMOペパボ ロリポップ・ムームードメイン事業部 ロリポップ！ 固定IPアクセス 趣味 GWにスリランカに行ってきました ウイスキーが好き X: @yoshihiro_shu AI時代のGoテスト戦略 2
4. 背景: AIエージェントがPRを量産する時代になった AI時代のGoテスト戦略 4
5. 課題: 「正しさ」を証明する基準が言語化されていない PRは量産されるが、ロジックが正しいことをレビューするコストが高い 実装ごとに、正しさを担保するテストにばらつきがある テストはあっても、ロジックの正しさをテスト I/O だけで判断できない → 結局、ロジックが正しいかどうかは 毎回コードを読み解いて判断するしかない 根本原因: 「何を見れば正しいと言えるか」の基準そのものが言語化されていない AI時代のGoテスト戦略 5
6. 2つのプロダクト課題 ① データ遷移の整合性 似たようなユースケースでも、生成されるデータが違う 例: 新規契約 / 二回目以降の新規契約 で発行レコードや適用される時刻が異なる ② 日時依存のビジネスロジック 実行時刻によって結果が変わる 例: 月末に契約すると契約期間が翌月末まで延びる AI時代のGoテスト戦略 6
7. テストがほとんどシナリオテストに集約されていた テストピラミッドの「結合テスト」: Go サーバー + DB を起動し、外部サービスはモック化して 一連のフローをAPI単位でテストを行っている。 担保していたこと: API レスポンス（ステータス・メッセージ内容） DB の状態変化（レコードの生成・論理削除） 日時・金額計算（契約期間・請求金額） 外部システムへの副作用（メール送信・リソースの作成） AI時代のGoテスト戦略 7
8. 解決案: テストによって責務を分ける シナリオテスト 結合テスト層 確認すること 期待通りのレコードが ⽣成・削除されているか ユースケーステスト サービス単位 確認すること 契約期間・価格が 期待通りに算出されるか f(x) 単体テスト 関数単位 確認すること 関数の 振る舞いが変わらないか AI時代のGoテスト戦略 8
9. シナリオテスト → 「データ遷移」だけを見る 保証すること: ユースケースに応じて、期待通りのレコードやリソースが生成・削除されているか 検証しないこと: 日時によって結果が異なるビジネスロジック AI時代のGoテスト戦略 9
10. ユースケーステスト → 「日時・価格計算」を固定日時で検証 する 保証すること: 日時依存ロジック（契約期間・課金額）が期待通りに算出されるか 検証しないこと: DBへのレコード生成・削除 AI時代のGoテスト戦略 10
11. 単体テスト → 「振る舞いの不変性」を守る 保証すること: 関数の入出力が変わらないこと リファクタリングなどで振る舞いが壊れていないことの確認 意図しないロジックの変更の検知 AI時代のGoテスト戦略 11
12. 結果: テストでロジックの正しさが判断できるようになった テストの input / output を見るだけでロジックの正しさを判断できる → コードを読み解く必要がなくなった テストケースの漏れ を防ぎやすくなった → 責務が分かれたことで、各層の網羅性が見えやすい レビューに 別の観点 を考える余裕ができた → 認知負荷が下がり、設計・性能などにも目が向く AI時代のGoテスト戦略 12
13. まとめ 今回考えたのは「大量のPRをマージしてもシステムが壊れない仕組み」だけ レビューには本来、コーディングルール・セキュリティ・パフォーマンスなど多くの観点がある → テストの責務を言語化したのは、その第一歩 → 同じように観点ごとに言語化していきたい AI時代のGoテスト戦略 13