私たちはもうテストを書きません — AIくん、あとは全て任せましたよ

私たちはもうテストを書きません AIくん、あとは全て任せましたよ FlutterKaigi 2026 / 株式会社デジタルバリュー 小野紀輝 Digital Value

ある日、チームリーダー権限を使って宣言しました 「私たちは、テストコードは書きません」 Digital Value

テストは人が書かない代わりに、全部AIが書いています E2Eテスト (Maestro) 39画面分 ※Maestro→Integration Testにリ プレイス中 Unit / Widgetテスト 285ファイル 約3,050ケース、CIで3.4分 対象 one parettoアプリ one paretto E2Eの深掘りは2週間後のTokyo Test Festで話します! 今日は両方に共通する「作り方」 テスト総量は簡単に確保できるようになった →量が品質を意味しないと気づくまでの話をします Digital Value

Before: 人間レビューを捨てきれなかった AIがテストを生成 → 人間がテストコードをレビュー → マージ 当時リポジトリのユニットテストは62件 (レビューを通せる分しか増えなかった) それでもレビューを手放せなかったのは、 品質も 網羅性も 効くかも「人間が見るべき」と思い込んでいたから 実態は「人間が見るべき」ではなく 「AIに任せるための土台を作っていなかった」だけ Digital Value

After: 暗黙知をSkillにして渡す 人間が「なんとなく」見ていたもの スコープ: 何をテストしないか 境界値: どの値で何が起きるべきか 疑い方: 本当に壊れたら落ちるのか → Skillを用いて標準化 E2E: 独立したSkill 6本+指揮台1本 Unit: 手順書1本+品質規約11本+除外リスト 手放したもの: AIが書いたテストコードを読んで良し 悪しを判定すること 残したもの: テストが失敗したときの「実装のバグ か、テストの不備か」の切り分け Digital Value

AIに任せる土台を6段階に分解 E2Eは6本のSkill、Unitは1本のSkillの6ステップ。形は同じ。⑤⑥には「通すために曲げない」がつく ポイント1 書く前 ①何をやらないか ②期待値の根拠 ③到達設計 ④書く ポイント2 ⑤実行 ポイント3 ⑥疑う・報告 E2E Skill 6本 何をやらな いか宣言 期待値は実 コードと Figma から E2E専用。 今日は割愛 落とし穴カ タログ付き 1回実行し て報告。直 さない 別セッショ ンのAIが 疑う Unit Skill 1本 6ステップ 除外リスト に照らす 実装を全行 読んでから 書く 該当なし 品質規約11 本を併読 testを1 回。落ちて も直さない 1か所壊し て落ちるか 確認 Digital Value

ポイント1 書く前 ①やらない ②期待値 ③到達 ④書く ポイント2 ⑤実行 ポイント3 ⑥疑う 最初に「やらない」を決める E2E: scope-layering 書く前に、検証する層と「やらない」理由を1行で宣言(L1入 力/L2送信/L3DBはやらない) 限度額変更: L1+L2 / 送信は「正しく呼ばれたか」まで 会員解約: スコープ外(送信でログアウトする) Unit: 除外リスト(乗っていなければ全部対象) 約1,000 → 約280 lib/のファイル数 「テストしないファイル」だけを書く。除外できるのは6種 だけ 自動生成物 abstractだけ 分岐の無いデータ 計算のない定数 UI副作用ラッパー 画面まるごと→E2E E2EとUnitに共通すること 「やらない」を先に、理由つきで書き出す 書かずに渡すと、AIは範囲を都合よく解釈する。決めた範囲は逃がさない Digital Value

ポイント1 書く前 ①やらない ②期待値 ③到達 ④書く ポイント2 ⑤実行 ポイント3 ⑥疑う AIは「たぶんこう動く」で書いたので先に読ませる E2E: boundary-data-design 期待値の出どころは validator・repository・Figma の3つだけ。境界は「ちょうど通る/ちょう ど落ちる」のペアで Unit: 品質規約R7、原文(抜粋) #### R7. 実装の挙動を観察してから期待値を書く // NG: 「マイナスは弾かれるはず」と予想で書く → 実際は通る // OK: int.tryParse('-100') が -100 を返すのを観察してから書く E2EとUnitに共通すること 期待値は予想で書かせない。根拠を先に読ませる 予想で書くと、テストは「実装の検証」ではなく「自分の予想の検証」になる 限界: 実装が間違っていれば、テストは間違いごとと固定する。 Digital Value

ポイント1 書く前 ①やらない ②期待値 ③到達 ④書く ポイント2 ⑤実行 ポイント3 ⑥疑う 品質規約11本: 全部、レビューで言っていたこと R1 mocktailを使う。mockitoは廃止 R2 registerFallbackValueを忘れない R3 テスト名は日本語、Given-When-Thenで構造化 R4 any()の多用は禁止。固定値でverifyする R5 観点の数は「分岐の数」に比例させる R7 実装の挙動を観察してから期待値を書く R8 1分岐1テスト。同じパスを2度テストしない R9 代入行とexpectを1対1で突き合わせる R10 publicメンバーの対応表を作ってから書く R11 テストはファイル内でも順序独立にする R6 実装を1か所わざと壊して、落ちることを確認する → ポイント3へ どれも特別なことは書いていない。レビューで毎回指摘していたことを、先に渡しただけ Digital Value

ポイント1 書く前 ①やらない ②期待値 ③到達 ④書く ポイント2 ⑤実行 ポイント3 ⑥疑う 「直すな」: 落ちたテストを、通るように曲げない 落ちた原因が実装のバグかテストの不備かは、書いた本人には区別させない。 AIに直させると「通るように」どちらかを曲げる E2E: run-and-report: 1回実行して、報告して、止まる ## The Iron Law 落ちたテストを直さない。もう一度走らせて緑を狙わない Red Flags (出たらSTOP) の頭をよぎる言い訳まで原文に書いてある 「flakyだからもう一回」 → 再実行の緑は本物のデグレを隠す 「assertを直せば通る」 → その差分がデグレかもしれない 「直してPASSが親切」 → 検知の破壊。報告までが責務 Unit: 書き手はlib/を書き換えない 読むのはOK。禁じるのは「通すために」直 すこと。導入時もlib/を1行も変えずに書い た。疑問はTODOにピン留めして人へ hookで機械的に止める仕組みは導入中。今は手順 書と設定での禁止で、まだ半分は「お願い」 Digital Value

ポイント1 書く前 ①やらない ②期待値 ③到達 ④書く ポイント2 ⑤実行 ポイント3 ⑥疑う PASSを信用しない: 壊したら落ちるか 「対象機能をわざと壊したら、このテストは赤くなるか?」 赤くならないテストは無価値 E2E: adversarial-review: 壊したつもりで読む 実機で壊すのは高い。文脈を共有しない別セッションのAI に「壊したら落ちるか」を問わせる。同じセッションだと自 分の出力を追認する False-pass: 通っているのに何も守っていない。常 に表示される文字列だけ見ていないか、送信せずに 通っていないか レビュー役のAIは直さない。返すのは重大度つきの指摘と 「こう壊れても落ちない」具体例だけ Unit: R6 破壊検証: 実際に壊す 実装を1か所反転してflutter test。その箇所を守る はずのテストが落ちなければ書き直す // 破壊検証ログ: // `token.isEmpty` の分岐を `success` に反転 // → 3 件 FAIL → ロールバック Digital Value

ポイント1 書く前 ①やらない ②期待値 ③到達 ④書く ポイント2 ⑤実行 ポイント3 ⑥疑う 答え合わせ 疑ったら実際に⾒つかったもの 4枚目で言った「量」の答え合わせ。全部PASSしていたテストを、敵対的レビューと全数監査に疑わせたら E2E 17 / 39 画面 画面に届かない・確認が丸ごとスキップされるなど 画面が切り替わらなくてもPASS: 確認した文字列 が、元のメニュー画面にもあった 確認が1つも動かずPASS: 「表示されたら確認」 をスクロール前に判定し、全部スキップ Unit 約70 / 約3,050件 全数監査で削除+書き直し・追加 16テストあって1フィールドを誰も見ていない: 実装が定数に化けても通る 同じ分岐に5個並ぶテスト: 境界を含まないなら 1つで守れる 通ってはいる。でも壊れても落ちない。量は、品質を意味しなかった Passの数ではなく「壊したら落ちるか」で測る Digital Value

| 落とし穴 Skillの一文が、AIの癖になる 「最低3観点」と書いたら 分岐が無いメソッドにも3観点 を発明した。さっきの「同じ分 岐に5個」の根本原因 →「観点は分岐の数に比例」に 書き換えた 「既存を踏襲」と書いたら 直書き値まで踏襲して探索をや めた。実機では何も変わらない 修正が出た →何を踏襲し、何を踏襲しない かまで書く 規約同士が矛盾したら 新ルールと除外リストの古い記 述が衝突。AIは古い側を選び、 矛盾を報告してきた →矛盾はAIが見つけてくれる。 拾って直す 規律は「精神」ではなく「やり方」のレベルまで書く。 書いた一文の副作用は、実際に走らせて確かめる Digital Value

| 検証 効いたのか E2E: Skillの有無で同じ課題を解く 37 / 37 vs 19 / 37 Skillあり Skillなし 手順と構造の評価項目37項目に対する遵守 数。3課題×2Skill=6試行。なしだと Maestroで動かない正規表現や、要検証マー カーの欠落が出た Unit: 同じチケットを土台の前後で再実装(同じモデル) 土台なし: NG 既定の判定に戻す1行修正 で、先頭からの更新まで死ん だ。analyzeもlintも通り、 テストは「費用対効果」で見 送った → 土台あり: OK 同じ案を実測で却下し、正し い修正+Widgetテスト2 本。効いたのは「振る舞い変 更はテストで実証。書かない なら理由を書け」の一文 分かったこと: lintやanalyzeは「もっともらしい誤り」を止められない。止めたのは、テストを書 けという一文と手順 Digital Value

人の仕事は「書くこと」から「教えること」へ ポイント1 書く前: ①②④ 書く前に決めさせる 「やらない」の決め方、期待値 の根拠を6段階と規約に ポイント2 書いた後: ⑤ 通るように曲げない 実行担当は報告して止まる。書 き手は実装を書き換えない ポイント3 書いた後: ⑥ PASSを疑う Unitは実際に壊す。E2Eは別セ ッションのAIに「壊れたら落ち るか」を問わせる 「ここは人間が見るべき」と感じたら、それは 「まだ言語化していない」のサイン 書き出せば、AIにもチームにも渡せる Digital Value

ありがとうございました 小野紀輝 おの としき 株式会社デジタルバリュー / シニアデベロッパー 北国銀行が提供する決済アプリをFlutterで開発 赤い猫のアイコンが目印です これからアプリを育てていきたい方 Joinお待ちしています 私たちはもうテストを書きません。でも「テストの作り方」は、私たちが書いています。 E2Eの続きは2週間後のTokyo Test Fest 2026で Digital Value