ハーネスエンジニアリングのプラクティス P6. 多層検証ピラミッド（ループ位置に検証頻度を合わせる） 🎯 ポイント 全ステップで10分のE2Eテストを回したら、エージェントの思考は10分ごとに止まります。検証にも「軽重」の設計が必要です。 📝 概要 速く安い検証（型チェック・lint）は毎ステップ、中程度の検証（単体テスト）はマイルストーンごと、遅く高い検証（結合・E2Eテスト）は完了ゲートで実行します。検証のケイデンスをループ位置に合わせることで、レイテンシ税を最小化します。 🔍 解説 すべての検証を毎ステップで実行するのは非効率であり、逆にすべてを完了時にまとめて実行するのはリスクが高すぎます。テストピラミッドの考え方を検証タイミングにも適用するのがこのプラクティスです。型チェックやlintは数秒で終わるため毎ステップで実行してもレイテンシへの影響は軽微です。一方、E2Eテストは数分かかるため、頻繁に実行するとエージェントの作業効率を大きく損ないます。ループの内側に速い検証を、ループの外側に遅い検証を配置することで、フィードバックの速度と網羅性を両立させます。 🛠 実践方法 ・検証を3層に分類します：毎ステップ（型チェック・lint、数秒）、マイルストーン（単体テスト、数十秒）、完了ゲート（結合・E2E、数分） ・ハーネスのループ構造に検証タイミングを組み込み、各層が自動的に適切なタイミングで実行されるようにします ・各層のレイテンシを計測し、ループ内検証が遅すぎる場合はテストの範囲を絞るか並列化で対応します ・層の間に検証の死角がないか定期的に確認し、カバレッジのギャップを埋めます 💼 ユースケース ・ペアプログラミングで、編集のたびに型チェックだけ即座に実行し、影響範囲のテストだけを走らせる場面 ・issue-to-PRエージェントで、実装中は単体テストで検証し、完了宣言前にCI全体を実行する場面 ・CI自動メンテナンスで、トリアージは安いチェックで行い、修正の検証だけフルテストを回す場面 ⚠ 落とし穴 ピラミッドの層を間違えると、速度と品質の両方を失います。重い検証を頻繁に回せばレイテンシで死に、軽い検証しか回さなければリグレッションが流出します。また、「型チェックが通ったから大丈夫」という過信も危険です。各層の検証がカバーする範囲を正確に理解し、層の間に死角がないか確認することが重要です。 #HarnessEngineering# #TestingStrategy#