AIの編集を、変更に関係するテストへつなぐ

まず手元で試す

1. 1. 既存のテストを一度確認する

   普段のテストコマンドが動くことと、変更するソースがテストからimportされていることを確認します。以下の例は、Vitestが導入済みのリポジトリ向けです。

2. 2. 変更ソースを指定して一回だけ実行する

   例のsrc/cart.tsとsrc/price.tsを、実際の変更ファイルに置き換えます。--runを付けて監視モードを避け、コマンドが終了する形にします。

3. 3. 必要な失敗を拾えるかを見る

   既知の失敗を含む変更で試し、選ばれたテスト名と失敗理由を確認します。対象が0件だった場合は、成功と決めずにパス・import関係・設定を点検します。

./node_modules/.bin/vitest related --run src/cart.ts src/price.ts

パスは説明用の例です。未導入のリポジトリにそのまま実行するコマンドではありません。この例の導入フックや性能は実測していません。

自動化へつなぐときの流れ

1. 1. 変更の集合を記録する

   PostToolUseのEdit/Writeを使う案では、編集されたパスを収集します。Bash・コード生成・外部プロセスによる変更はこの経路を通らないため、取得方法を別に用意します。

2. 2. 実行する時点を決める

   Stopを使えば、Claudeが応答を終える時点にまとめて実行できます。長いターン内で複数回編集しても、その都度の終了検知にはなりません。即時のフィードバックが必要かで判断します。

3. 3. 一回の実行へ安全に引き渡す

   同じパスをまとめ、ファイル名を文字列連結せず引数の配列でランナーへ渡す設計にします。別セッションや同時の編集を混ぜず、実行中に増えた変更は次の集合に残します。これは導入前に決める設計事項です。

4. 4. 結果を返し、次の動作を分ける

   失敗時はテスト名と失敗理由をClaudeへ返し、修正後に再確認します。合格した集合だけを完了扱いにし、ランナー欠落やタイムアウトをテスト失敗から分けます。同じ失敗で無限に続かないよう上限を設けます。

結果をどう読むか

合格

選ばれたテストの範囲で合格しています。
対象の選択漏れと、別途必要な全体CIを確認します。

失敗

変更に関係するテストが失敗しています。
失敗理由を返し、修正後に同じ対象を再確認します。

対象0件

対象が存在しない場合と、選択が漏れた場合を区別できません。
ソースのパス・import関係・ランナー設定を確認します。

実行できない

コマンド欠落・環境不備・タイムアウトなどの可能性があります。
環境の問題として扱い、同じ実行の無限再試行を避けます。

採用前に点検すること

• Bashや生成処理の変更も必要なら、現在の公式資料にあるFileChangedや変更前後の差分による把握を検討し、利用する版での対応を確認します。
• 既にあった人の未コミット変更と、今回のAIによる変更を区別します。
• 動的import、設定ファイル、外部データや連携に依存するテストは、関連選択だけで十分かを確認します。
• 実行時間の上限、同じ失敗の再試行上限、実行中に増えた変更の扱いを決めます。
• 既存の必須テスト・CI・レビューを、この回避策で省略しません。

2026年11月1日に、元の要望・返信とAnthropic/Vitestの公式仕様を照合して編集しました。フックを実環境へ導入した結果や、テスト時間の短縮を検証した記事ではありません。