【第4回】AIに「書かれていないこと」までテストさせる——QEハーネスという仕組み

本連載では、品質を3つの軸で捉えます——
①設計書適合（仕様どおりか）
②暗黙要件（仕様に書かれない当たり前）
③本質要件（本当に達成したい目的）

②は「ベテランの頭の中」にある

第2回で見たとおり、②（境界値、null、エラーハンドリング、性能、セキュリティ、設計書間の矛盾……）は、経験者なら「当たり前に確認すること」だ。問題は、その当たり前が仕様書には書かれず、ベテランの頭の中や業界の常識として存在することだった。

AIは書かれたものからしか期待値を作れない。だとすれば打ち手は明快だ。その"頭の中の当たり前"を、AIが読める形に書き出して、AIに渡してしまえばいい。これを行う仕組みが、ハーネスである。

ハーネスとは何か

2026年、AIコーディングエージェントの実用化とともに、ハーネスエンジニアリングという規律が登場した。AIエージェントの周囲に制約・フィードバック・検証の仕組みを設計し、エージェントを実務で信頼できる状態にする営みだ。

ハーネスは大きく2種類の部品でできている。ガイド（先回りして与える制約。フィードフォワード制御＝「こう動け」）と、センサー（後から検知する仕組み。フィードバック制御＝「ちゃんとできたか」）だ。象徴的なのは、エージェントがうまく動かないとき、直すのはコードではなくハーネスのほうだという点である。制約やドキュメントやツールを改善すると、以後の生成全体が底上げされる。

QEハーネス：②の経験知をテストエージェントに埋め込む

このハーネスを「テストを作るAI」に向けたものが、QEハーネスだ。①向けの「開発ハーネス」がコーディングエージェントを律するのに対し、QEハーネスはテスト設計・実行・判定のエージェントを律し、②を主戦場とする。

中身はこうなる。

• ガイド：テスト技術のチェックリスト（境界値・null・負数・エラーパスの網羅）、非機能テストの基準、設計書を横断して矛盾を探すルール、OWASP等の業界標準——これらをマシンリーダブルな制約として、テストエージェントに与える

• センサー：そのテストが本当に効いているかを検証する。ミューテーション検証（実装にわざとバグを仕込み、テストがそれに気づくか確かめる手法）、カバレッジ分析、Reference Oracleとの比較

つまりQEハーネスは、②のテスト技術知識を形式知として体系化し、AIのガイドに埋め込むことで、AIに「仕様に書かれていないこと」もテストさせる仕組みだ。第2回で「書ける②は①に引き上げられる」と述べたが、その"引き上げ"をAIエージェントに対して継続的に効かせる装置が、QEハーネスにあたる。

それでも、判断は人間に残る

ここで誤解してはいけない。ハーネスが担うのは、生成（テストの自動生成）・検出（整合性チェックやカバレッジ）・継続検証（CIで回し続けること）であって、判断ではない。

• 生成された案のうち、何を採用するか

• 何が暗黙のまま残っているか

• これで十分か

• 検出された問題のうち、何を許容するか

——これらは人間の中核責務として残る。ハーネスがどれだけ高度化しても、この線は動かない。むしろハーネスが生成・検出を引き受けるからこそ、人間は判断に集中できる。

まとめ

QEハーネスは、②というベテランの経験知をAIに届けるための媒体だ。チェックリストや基準として書き出し、テストエージェントのガイドに組み込み、センサーで効果を測り続ける。そうして「書かれていないこと」までAIにテストさせつつ、最終的な判断は人間が握る。AIの速度を損なわずに②を作り込む——その実装が、QEハーネスである。

▼連載の全体像と各回へのリンク（連載インデックス）

本稿および本編は個人の見解であり、所属する組織を代表するものではありません。
問い合わせ先：terumitsu.takahashi.qe [at] gmail.com