機械に任せるテスト、⼈が⾒るテスト ⽣成AIで引き直した、運⽤保守フェーズの線引き クラスメソッドオペレーションズ株式会社 LINE / アプリ DevOpsチーム 草⽵ ⼤輔 KUSATAKE Daisuke 

リリースのたびに、同じ確認を、⼈が 15 案件 2 端末 iOS LINEミニアプリの運⽤保守 iOS / Android で毎回検証 Android ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ 毎 リリース 同じ項⽬を、⼈が確認 毎回同じ点検表を、上からなぞる 

機能追加が活発な案件では、回帰テストに 2 ⽇ 「壊していないこと」の確認にかかる時間。 新しい価値を⽣む時間ではない。 

重いのは「作る」ではなく「毎回実施する」 実施コストの累積(概念図) R = リリース 作るコストは 1回 実施するコストは リリース回数 × 案件数 運⽤保守は期間が⻑い。 だから積み上がりが効く。 作成 R1 R2 R3 R4 R5 R6 

それでも⾃動化しなかったのは、合理的だったから テストコードのコスト 書く⼯数 保守する⼯数 ⾃動化で浮くコスト ＞ ⼿動の実施⼯数 書ける⼈の確保 怠慢ではなく、判断だった。⾒合わなかったから、⼈が確認してきた。 

AIで前提が変わった。そこへ⼿動100%の案件が来た 前提の変化 きっかけ 決断 ⽣成AIで 「書く」コストが下がった ⾃社製品の保守を新規受注 テストは⼿動100% 受⼊時に テストマイグレーション なぜこの案件から? 「何をテストで担保するか」を、社内だけで調整できたから。 

AIなら、変換は⼀瞬でできる。 ⼿動テスト項⽬を、 そのままコードにすればいい? やってみると、意義が得にくかった。 

⼿動テストは1層、テストコードは多層 ⼿動テスト項⽬ テストコード E2E(large) 振る舞い (ユーザーから⾒た機能) 結合(medium) 単体(small) すべて同じ粒度‧同じ層で書かれている 完成⾞の試乗 全部を「試乗」で確かめると、遅くて⾼い 部品の検査 

確認の⼿順から、保証の設計へ 確認の⼿順 保証の設計 ⼿動テスト項⽬ = ⼈がなぞる⼿順書 何を保証するかの仕様ではない どの層で、何を保証するかを決める = ⼈の仕事 ○ 仕様 → 振る舞い → E2E ⽐較的素直に導ける ! ⼿動項⽬ → 単体テストへの割り当て ⾃動では導けない。実⾏コストと網羅性で判断 ! 粒度の⼩さい単体テスト 仕様から⾃然には出てこない。判断が必要 AIは書いてくれる。どこで何を保証するかは、⼈が決める。 

移し替えではなく、引き直し これまで 線引き後 機能 ⼈が⾒る 機械 E2E(正常系操作)+ 単体テスト(網羅) ⾒た⽬ ⼈が⾒る 機械 VRT(アプリ単位 / コンポーネント単位) 体験 ⼈が⾒る ⼈ 変更に対するユーザー体験 コード化困難 ⼈が⾒る ⼈ LINEアプリ内でのみ動く機能 など テストの妥当性 — ⼈ テストコードそのものの妥当性判断 NEW 

機械に任せたもの E2E VRT ⾒た⽬:間違い探しを、機械が毎回 正常系の操作 ユーザーの操作を通しで確認 − = 単体テスト 網羅的な機能 small / medium 速く、細かく、全パターン 正本 今回 アプリ単位 + コンポーネント単位(Storybook) ※模式図 差分 

⼈が⾒るもの 1 2 3 ユーザー体験 変更を実際に使ってみて、どう感じるか コード化が困難なもの LINEアプリ内でのみ動く部分(リッチメニュー、友だちへのトーク送信 など) テストコードそのものの妥当性 保証すべきことを、正しく保証できているか ⼈の仕事は減ったのではなく、移った。 

設計は⼈、実装はAI。並列で⾛れるように設計する 使ったツール: Claude Code AI 機能A のテスト ⼈ 保証の設計 AI テスト基盤 共通ヘルパー AI 機能B のテスト AI 機能C のテスト AI 機能D のテスト 独⽴した単位で並列に ＋ AIが⾃分で動かして確かめられる環境(Playwright など)を渡すと、⾃律的に直すループが回る ⼈ レビュー 妥当性判断 

2名‧約3週間で、⼿動100% → ⾃動831件 2 設計‧レビュー1 + 実装1 他案件と並⾏ 名 831 件の⾃動テスト VRT 45 3 週間 10 設計1週 + 実装2週 E2E 73 単体 713 分未満 E2E込みの実⾏時間 直近は5分台 small 383 / medium 311 / component 19 

変わったこと 1 ⼿戻りゼロ 2 機能破壊‧⾒た⽬崩れは、実装中(レビュー前) に⾒つかる 3 ⾒た⽬の正本 状態ごとのスクショが常にリポジトリにある。 VRTはおすすめ 潜在バグの発⾒ 網羅的にテストするので、顕在化する前に⾒つ かる 4 仕様の棚卸し 「何を保証すべきか」を問い直す場⾯が必ず来 る。薄かった観点が⾒つかる 

展望: 線引きを案件横断で実施していく いま整理している問い 案件全体を通して、CIでは 何をどこまで保証するべきか? ⼈の判断を、速く正確にする E2Eから先に作る ピラミッドとは逆順。⼈が判断しやすい層から固める Mutation Test わざと実装を壊し、テストが検知できるかを機械的に確かめる = 保証の設計を、案件横断でやる Property Based Testing ⼊⼒パターンを抽象化して網羅する 

まとめ ⽣成AIは、テストを「書く」コストを下げた。 ⼈の仕事は、確認の⼿順から、保証の設計へ。 運⽤そのものから、運⽤設計へ。 開発の⼒で、運⽤のレイヤーを上げる。 LINE / アプリ DevOpsチーム 

ご清聴ありがとうございました