HQW！主催　QA4AIDDを考える会 第3回　派生開発を見据えたハーネスエンジニアリング 開催リポート

AI駆動開発では、要件整理、設計、実装、テスト、レビューといった開発プロセスのさまざまな場面でAIを活用します。一方で、AIの出力は人間が意図したものと常に一致するとは限らず、仕様の曖昧さや前提条件の不足が、そのまま品質リスクにつながります。

そこで本イベントでは、単にAIに多くの情報を渡すのではなく、「何を」「いつ」「誰に、またはどのエージェントに」渡すのかを設計することに着目しました。さらに、AIが出力した成果物をどのように確認し、次の行動に反映させるのかという評価の仕組みも、ハーネスエンジニアリングの重要な要素として取り上げました。

当日は、前半に二つの講演を行い、後半はフリーディスカッション形式で、参加者同士が自社での取り組みや課題を共有しました。講演では、AI駆動開発の実践事例と、ハーネスを巡る考え方が示され、ディスカッションでは、派生開発における影響分析、回帰テスト、CI/CD、ルール設計など、実務に直結する論点が多く挙がりました。

では、当日の二つの講演内容をご紹介します。

講演① コンテキストエンジニアリングの先へ

一つ目の講演では、AI駆動開発を実際に行った事例を基に、実装前の仕様整理とコンテキスト設計の重要性が共有されました。講演の中心にあったのは、「AI駆動開発で効くのは、実装中の細かな指示よりも、実装前に論点を詰めておくこと」というメッセージです。

AIは、仕様に不足があると、不明点を人間に確認するのではなく、自ら補完して実装を進めてしまう場合があります。その結果、意図しない機能や振る舞いが作られ、後戻りのコストが大きくなる可能性があります。これを避けるためには、実装前に要求や仕様の曖昧さをできるだけ取り除き、AIが判断すべき余地を必要以上に残さないことが重要です。

講演では、AIに仕様のたたき台を作らせた上で、「この仕様を実装するに当たって、決めてほしいところはないか」とレビューさせ、人が判断すべき論点を洗い出すプロセスが紹介されました。AIを実装者としてだけでなく、仕様レビューの相手として使うことで、画面遷移、データ保存、エラー時の振る舞い、外部連携、権限など、実装前に詰めるべき項目を整理しやすくなります。

また、ルールファイルやAGENTS.mdのようなコンテキストは有効である一方、それだけで十分ではないことも示されました。コーディングルール、セキュリティルール、設計ルールは、与える内容だけでなく、与えるタイミングによって効果が変わります。例えば、設計上の制約は、実装時に追加するよりも、仕様や計画を作る段階で反映させた方が、効果的なアーキテクチャにつながりやすいという事例が共有されました。

一方で、セキュリティルールのように、一般的には望ましい制約であっても、対象プロダクトの利用環境や前提と合っていなければ、過剰な実装や不要な機能につながることがあります。コンテキストは多ければよいのではなく、対象や工程に合わせて具体化し、必要な相手に必要なタイミングで渡すことが重要である、という点が強調されました。

講演② ハーネスとは何か

二つ目の講演では、「ハーネスとは何か」をテーマに、AIエージェントを望ましい形で自律実行させるための仕組みへの考察がされました。通常のハーネスが、人や動物の行動範囲を安全に保つための仕組みであるように、AIエージェントに対するハーネスも、AIが危険な方向へ進み過ぎないよう支える外側の仕組みとして捉えられます。

AIエージェントの特徴は、道具を使いながら調べ、直し、確かめ、次の行動を選ぶ自律性にあります。この自律性を実務で生かすには、単にAIに作業を任せるだけでなく、作業環境、利用できるツール、参照すべき情報、人間の承認が必要な場面、そして評価方法を設計しておく必要があります。

講演では、コーディングエージェント自体にも、ベンダーが用意した汎用的なハーネスが組み込まれていると説明されました。そのため、利用者側が追加するハーネスは、ベンダーの仕組みと競合するものではなく、プロダクト固有のルールやテスト、評価、CI/CD、承認フローなど、現場固有の品質保証に関わる部分に重点を置くべきだという考え方が示されました。

特に重要な要素として取り上げられたのが「評価」です。AIが作ったものを人間が一つずつ目視で確認するだけでは、生成される成果物の量と速度に追い付けません。そこで、スモークテスト、回帰テスト、変更箇所に対応するテスト、リンターやカバレッジなどを自動的にチェックする環境を整備し、AIが自ら結果を確認しながら次の行動を選べる状態を整備し運用することが、ハーネスエンジニアリングの中核になっていきます。

派生開発では、既存コードや仕様が巨大であったり、最新化されていなかったりすることがあります。AIが既存コードを探索し、関連箇所を見つける力は高まりつつありますが、その探索結果をそのまま正解とみなすことはできません。既存の振る舞いを壊していないことを確認するためにも、評価のためのハーネス、すなわちテストやレポーティングの仕組みを整えることが重要であると説明されました。

講演後の質疑応答とフリーディスカッションでは、参加者から実務に即した論点が多く挙がりました。

論点①　ハーネスの見直しタイミング
AIエージェントや基盤モデルは日々進化しており、以前は有効だったルールや制約が、後から見ると過剰になる場合があります。そのため、モデルを切り替えるタイミングや、対象プロダクトが変わるタイミングで、ハーネスを見直す必要があるのではないかという議論がありました。

論点②　要求や仕様を誰がどのように詰めるのか
AIに仕様レビューさせることは有効ですが、最終的に顧客や利用部門から何を聞き出し、どの判断を人間が行うのかは、人の役割として残ります。このためAI駆動開発であっても、要求を捉える力や、未決定事項を放置しない姿勢は引き続き重要との意見が出ました。

論点③　ユーザー側が作るハーネスの範囲
参加者からは、AIエージェントの提供元が持つ汎用ハーネスはすでに高度であり、そこに矛盾するルールを重ねると、かえって品質を下げる可能性があるという指摘がありました。これに対して、権限を与え過ぎない、リンターを通さないとマージできない、カバレッジ基準を満たさないと通せないといった、AIの内部挙動に依存しないハーネスが重要ではないかという意見が共有されました。

論点④　派生開発における「正本」をどこに置くか
理想的には仕様書が正本であるべきですが、現場によっては仕様が古い、コードと乖離している、十分に存在しないといったケースもあります。そのような場合、既存の振る舞いを確認する回帰テストやテストスイートが、実質的に品質を支える基盤になる可能性があるという議論が行われました。

論点⑤　変更影響分析
特に組み込みや車載システムなど、変更の影響範囲を慎重に見極める必要がある分野では、AIに明示的に影響範囲分析を行わせること、関連箇所や依存関係を一覧化させること、そしてその結果を人が確認することが重要です。同時に、そもそも影響範囲が広がりにくいアーキテクチャや、小さな変更単位を保つことも、AI駆動開発を安全に進めるための前提になるという意見がありました。

振り返り

今回のディスカッションを通じて、AI駆動開発における品質保証は、最終成果物の確認だけではなく、AIに作業させる前の準備、AIが参照する情報の設計、AIの出力を評価する仕組み、そして人間がどこで判断するかを含むプロセス全体の設計であることが確認されました。

また、ハーネスエンジニアリングは特別な新技術だけを指すものではなく、従来から行ってきた仕様整理、レビュー、テスト、自動チェック、CI/CD、権限管理などを、AI駆動開発の文脈で再設計する活動でもあります。AIを活用するほど、人間の仕事は「コードを書くこと」から「AIが安全に価値を出せる環境を整えること」へと移っていく、という見方が共有されました。

本イベントを通じて、QA4AIDDの重要な観点として、コンテキストを整えること、評価の仕組みを整えること、そしてプロセスとして品質を保証することが浮かび上がりました。AI駆動開発では、AIが「思った通り」に動くことを期待するのではなく、AIが判断しやすいように情報を整理し、判断結果を検証できる仕組みを用意することが欠かせません。

派生開発では、既存のコードや仕様、暗黙知、テスト資産が複雑に絡み合います。だからこそ、AIに渡す情報と、AIの出力を評価する基準を明確にし、必要に応じて人が介入できるプロセスを設計することが、品質保証の中心になっていきます。

参加者からは、AI駆動開発におけるハーネスの考え方を整理できたことや、他社・他現場の課題感を共有できたことが有意義だったという声が聞かれました。本記事が、AI駆動開発の導入や品質保証の在り方を検討する際の一助となれば幸いです。

QA4AIDDを考える会では、今後もAI駆動開発における品質保証をテーマに、実践知の共有と議論を継続していく予定です。

次回は2026/7/27（月）に、「エンジニアのモチベーションはAIでどう変わるのか」をテーマに、ワークショップを実施する予定です。

2026年7月27日（月）に開催予定のワークショップ

・お申し込み

2026年5月15日に開催したワークショップの資料

・コンテキストエンジニアリングの先へ
・ハーネスとは何か

関連サービス

・AI駆動開発プロダクト品質マネジメントサービス（QA4AIDD）