---
title: AI境界値分析で 回帰テスト作成を自動化してみる
tags: 
author: [ktnyt](https://image.docswell.com/user/nanogram)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/YE62834QJV.jpg?width=480
description: 久々のやってみた系発表でした
published: July 23, 25
canonical: https://image.docswell.com/s/nanogram/Z6J1P9-ai-regression-testing
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/YE62834QJV.jpg)

AI境界値分析で
回帰テスト作成を自動化してみる
AI生成コードのレビューがつらい…“品質”をどう守る？現場の知見共有会
Mirei Itaya (Kotone) - 2025/07/23


# Page. 2

![Page Image](https://bcdn.docswell.com/page/GE529LQ2E4.jpg)

自己紹介
ことね（板谷美玲）
• LAPRAS株式会社
• ソフトウェア開発者です
• アジャイル開発が好きです
• 人を生き生きとさせるのが好きです
• FF14にハマってます
• 鳥と暮らしてます


# Page. 3

![Page Image](https://bcdn.docswell.com/page/97242LP1ER.jpg)

なぜ「回帰テスト」なのか


# Page. 4

![Page Image](https://bcdn.docswell.com/page/DJYMYQ54JM.jpg)

「品質が高い」とは？
ソフトウェアにおける品質の高低をどう判断するのか
結論：ユーザー体験 (UX) の高さ
コードの「きれいさ」は開発者体験に影響する
開発者体験は開発生産性に影響する
開発生産性はエンドユーザーにとってはどうでもいい
ただし開発生産性が結果的に上がることはある


# Page. 5

![Page Image](https://bcdn.docswell.com/page/V7NWPKN678.jpg)

「ユーザー体験」とは？
エンドユーザーは何を以てして「良い体験」をするのか
テクノロジーを意識することなく目的を達成できること
初代MacのGUI→WYSIWYG
iPhoneのタッチパネル→直感的操作
LLMエージェント→自然言語インタラクション


# Page. 6

![Page Image](https://bcdn.docswell.com/page/YJ9X3VRRE3.jpg)

ユーザー体験を高めるには？
テクノロジーとの摩擦を減らす方法
人間の特性を活かした実装が重要
動作を減らす→同じことを少ない操作で実現する
コンテキスト削減→大きな描画を減らす
フィードバック→何が起きているかを明確にする
習慣を活用する→奇を衒わない、破壊的変更をしない


# Page. 7

![Page Image](https://bcdn.docswell.com/page/GJ82MPWGJD.jpg)

デグレ（回帰）をテストで防ぐ
回帰の有無を確認するから「回帰テスト」
前提として意図的な破壊的変更は避けるべき
例：ボタンの配置を変える→操作方法を再学習しなければならない
例：設定ファイルの参照先を変更する→突然環境が壊れる
意図しない破壊的変更はもっと避けるべき（起こしてはならない）
インシデントはだいたい意図しない破壊的変更に起因する


# Page. 8

![Page Image](https://bcdn.docswell.com/page/LJL231NXER.jpg)

AIは平気で既存動作を壊す
小規模ペーパークリップ問題
良くも悪くもLLMは指示されたこと「だけ」を達成しようとする
1. 指示が間違っている→人間の問題
2. 指示の意図を誤解する→コンテキストが不足している
3. 楽をしようとする→「テストが失敗しているのでテストを消そう！」


# Page. 9

![Page Image](https://bcdn.docswell.com/page/47M8DWX37W.jpg)

AIは余事象の機能的推論が苦手
AIが生成したコードをレビューすることがなぜつらいのか？
「数字が偶数であることを判定する関数を実装して」
Web系の言語の多くは動的型付け (Python/Ruby/JavaScript…)
浮動小数が渡されたら？文字列が渡されたら？
テスト駆動開発をすれば動作を保証できる
型を使うと特定の事前条件を棄却できる


# Page. 10

![Page Image](https://bcdn.docswell.com/page/P7R54YNRJ9.jpg)

AIの破壊衝動と付き合っていくには？
人間を介さずにいかにAIの行動を制限できるか
Claude Codeは複数の方法が実装されている
Tools→外部リソースからのコンテキスト注入を自動化
Commands→定型文の入力を自動化
Hooks→フォーマッタ、リンタ、テストの実行を自動化
機械的に制約できることを増やすと人間の介入が減る


# Page. 11

![Page Image](https://bcdn.docswell.com/page/PJXK2GNY7X.jpg)

機械的制約がAIの真価を引き出す


# Page. 12

![Page Image](https://bcdn.docswell.com/page/3JK5M4N47D.jpg)

AI自身に制約を作らせられる？
回帰テストの実装をどこまで自動化できるのか
1. プログラムのロジックを読解させる
2. ロジックの境界値分析を実施させる
3. テストすべき境界値をチェックリスト形式で保存する
4. チェックリストに対してテストを実装させる
5. 境界値の網羅率を機械的にチェックする←これは自動化できそう


# Page. 13

![Page Image](https://bcdn.docswell.com/page/LE3KYLVDE5.jpg)

Coverage Checker
Pythonの境界値網羅率チェックツール
1. 関数のdocstringを確認する
2. チェックリストがない場合は「未カバー」としてマーク
3. 境界値に対応するテストが存在するか確認
4. 存在するか否かに応じて自動的にチェックをつけ外しする
5. 結果を報告する


# Page. 14

![Page Image](https://bcdn.docswell.com/page/8ED35N827G.jpg)

デモタイム


# Page. 15

![Page Image](https://bcdn.docswell.com/page/V7P4G58LE8.jpg)

しばらく運用してみた所感
良かったこととか悪かったこととか
✅ 境界値の条件とテストの実装を読めば中身をある程度信用できる
✅ 全自動でテストを書いてくれるので人間の工数はゼロで楽
❌ それなりに時間がかかる
❌ 無視してよい事前条件もテストしてしまう
境界値は人間が設定したほうがいいのかもしれない


# Page. 16

![Page Image](https://bcdn.docswell.com/page/2JVX6PN67Q.jpg)

Tips &amp; Tricks
良いコード・テストを出力させる工夫
イント
振る舞いの局所性 (Locality of Behavior) を上げる
コードの検索性 (Code Discoverability) を上げる
ドキュメントをちゃんと書く（書かせる）
E2E/Pinningテストだけを残して定期的に全部捨てる
ポ
結局AIに作らせる最大のメリットは気軽に消せること


# Page. 17

![Page Image](https://bcdn.docswell.com/page/5EGVNPK2EL.jpg)

cclsp:
LLM用LSP MCP
npx cclsp@latest setup
参照先の発見
定義元の発見
一括リネーム
Diagnostics取得


# Page. 18

![Page Image](https://bcdn.docswell.com/page/4JQ6Q2N9JP.jpg)

結局まだ仕組みが足りない
Claude Codeがんばって
LSP機能はIDE頼りじゃなくて組み込むべき
IDEが繋がっていてもFind/Grepを多用するのはなんとかしてほしい
Todoリストと併用できるチェックリストを運用したい
チューリング完全なHooksの仕組みがあったほうがいい
逆に言えばコーディングエージェントは伸びしろがありそう


# Page. 19

![Page Image](https://bcdn.docswell.com/page/K744NL3R71.jpg)



