AI が効率化できる作業と、QA の判断が必要な場面
AI ツールは、テストの提案、データの準備、画面のスクロール、結果の要約を行うことができます。チームは、どのリスクが重要なのか、機能が正常であることをどのような結果が証明するのか、混乱を招くテストをいつ調査するか中止するかを決定し続けています。すべてのクリックを確認する必要はありません。支払い、権限、個人情報、サービスへのアクセスに影響を与える可能性のある決定を確認する必要があります。
講演やテスト イベントでは、これらのタスクを人々とツール間で分散する方法について議論します。これは働き方についての話であり、単一の定義を持つ新しいポジションについての話ではありません。また、すべての企業が同じ割合で転職を行っているというわけでもありません。具体的には、AI が各チームにどのような支援を提供し、その結果に対して誰が責任を負うのかを評価することです。
要件とリスクを明確な基準に変換して、結果が正しいかどうかを判断する方法を学びます。ルールを作らないように、ツールに必要な情報を提供します。提案が関連性があるか、再現可能であるか、どのアラートが実際のエラーであるかをチェックします。何が起こったかを再現できるように、手順と結果を記録してください。製品によっては、API、データ、クラッシュ ログ、セキュリティ、アクセシビリティに関する知識が追加されます。
また、生成されたコードとテストをレビューする練習も行います。弱いアサーション、脆弱なデータ、隠れた依存関係、ケース数が増加するだけのカバレッジをチェックします。生成システムでは、入力と出力、堅牢性、プライバシー、および不利な命令に直面したときの動作の評価が追加されます。ツールはすぐに変わります。品質基準と専門分野の知識は長く続きます。
現在から 2027 年までに何が変わる可能性があるか
2026 年 11 月までに入手可能な証拠は、チームが一部のタスクを変更していることを示していますが、AI が QA で働く人々に取って代わるとは言えません。 World Quality Report によると、調査対象の組織の 89% がソフトウェア品質において生成 AI をテストまたは使用していました。それを全社に拡大したのはわずか 15% でした。ツールをテストしても、そのツールが監視なしで動作できることや、すでに結果が向上していることを意味するものではありません。
準備として、どのタスクが自動化されているか、誰が変更と結果をレビューするか、まだ調査が必要なバグは何か、チームに不足している知識は何かを書き留めます。面接では、どのようなリスクを検出したか、何をテストするかをどのように決定したか、どのような証拠を確認したか、何が改善されたかなど、具体的なケースについて話してください。ツールやプロンプトを列挙するよりも、その方がエクスペリエンスを説明できます。
サブスクリプション更新の変更を想像してみてください。ツールは、アクティブなアカウント、期限を過ぎたアカウント、および支払いが拒否された別のアカウントのテストを提案できます。ダミーデータを用意してフローをループさせることもできます。 QA 担当者は、重要なケースが抜けていないかどうかを確認し、請求書とアクセスで何が起こるかを確認し、実際のアカウントが使用されていないことを確認し、エラーがあれば確認します。修正後、影響を受けたテストを繰り返すことができます。
この配布は、分離されたテスト環境、ダミー アカウント、許可されるアクション、最大試行回数、テストを停止するルールなど、明確な制限がある場合にのみ機能します。これらの制限がないと、ツールがデータを変更したり、料金を作成したり、正常な結果にエラーとしてフラグを立てたりする可能性があります。 QA の仕事は、何をテストする必要があるかを説明し、それらの制限を設定し、その結果が本当にその機能に問題がないことを示しているかどうかを判断することです。
委任するタスクを選択する方法
タスクを委任する前に、「答えをどのように確認するか?」と考えてください。エラーを元に戻すことはできますか?機密データはありますか?ツールには必要な情報が含まれていますか?誰かが時間内に結果をレビューできますか?個人データを使用せずに草案を作成したり、記録を要約したりすることは、通常、リスクが低いです。権限、支払い、個人情報、またはセキュリティに影響を与える変更には、より多くの制御と人間の承認が必要です。重要な決定においては、データ収集を自動化し、最終的な決定をチームに任せることができます。
World Quality Report 2025–26 によると、企業は生成的な AI 知識 (63%) に加え、品質の基礎 (60%)、口頭および書面によるコミュニケーション (51%) を重視していることが示されています。実践的な読書は、「プロンプトを学習すればそれで終わり」ではありません。技術的な知識、テストの経験、リスクを説明する能力を組み合わせる必要があります。 AI は分析に役立ちます。チームは、結果を信頼する理由、または信頼しない理由を説明できなければなりません。
最初の 1 か月間は、既知のプロセスを選択し、リスク、データ、およびどのような結果が正しいと考えられるかを書き留めます。 2 つ目では、特定のタスク (要件に基づいてテストを提案するなど) を試し、その提案が役立つかどうか、ケースを繰り返すか、重要な状況を省略するか、レビューに時間がかかりすぎるかどうかを確認します。 3つ目では、成功したものだけを組み込んで、それをどのように止め、誰が合格し、失敗したテストをどのように繰り返すかを文書に残します。目標は、どこにでも AI を使用することではなく、AI が実際に役立つ場所を知ることです。
面接の際は、最初のリスク、適用範囲の決定、見つかった証拠、除外された誤検知、確認された欠陥、変更の結果など、完全な履歴を持参してください。どの部分を委任したか、何を確認したか、エージェントに何を許可しなかったかを説明してください。その物語は、技術的な判断、コミュニケーション、責任を示しています。プロバイダーやプロンプトをリストするだけではそれを証明できません。
仕事の進め方は変わる。役職名を変えるだけでは説明できない
人と AI ツールとのコラボレーションは、標準化された専門分野や、すべての QA がエージェントを管理するという予測ではなく、仕事のやり方を説明するものです。チームでは、1 人が AI を使用してドラフトケースを作成できます。別のケースでは、生成されたコードのレビュー、会話型サービスのオラクルの定義、または分析の繰り返し部分の自動化が優先されます。この立場は、製品、規制、設備、およびエラーのコストによって異なります。導入調査では大規模な実験が行われていることが示されていますが、規模に達している組織の割合は非常に小さいです。ツールを導入することは、仕事の構造全体を変えることと同じではありません。
正確に話すためには、仕事と責任を分けてください。組み合わせの検索、初期データの準備、またはログの要約を支援できます。 「正しい」とは何かを定義し、ビジネス リスクに優先順位を付け、例外を承認し、リリースを公開するかどうかを決定するには、依然として明確な判断と責任が必要です。一部のタスクは開発、製品、またはプラットフォームに移行します。他のものは評価と制御に関連して表示されます。この配分がすべての企業で均等であると断言する証拠や、ポジションの数が特定の割合で増減することを約束する証拠はありません。
これは、間違いによる影響、結果の検証の容易さ、可逆性、データ漏えいの 4 つの要素によってタスクを分類します。一般的な要件に対するケースのアイデアを生成し、レビューすることは、通常、許可を変更したり支払いを実行したりするよりもリスクが低くなります。エージェントは架空の環境で画面を閲覧できますが、実際のアカウントが表示されない場合は、そのアカウントにアクセスすべきではありません。結果が独立したアサーションで検証され、元に戻すことができる場合、自動化できる範囲が広がります。それが曖昧な解釈に依存している場合、または人々に影響を与える場合、制御が強化され、人間の承認が維持されます。
委任は、アプリケーションのバージョン、プロンプトまたは指示、利用可能なツール、アクションの制限、使用されたデータ、返された証拠などの痕跡を残さなければなりません。これにより、2 つの実行で異なる応答が得られた理由を調査できます。また、代理人の失敗を本人のせいにしたり、概要をあたかも元の証拠であるかのように受け入れたりすることも避けてください。適切に動作すると、システムは「情報が足りません」と通知し、製品の欠陥にならずに技術的な障害を発生させ、範囲外のアクションを停止することができます。
今後 3 か月で身につけたいこと
最初の 1 か月間で、既知のフローを選択し、各ケースがどのような要件をカバーしているか、どのようなデータが使用されているか、および結果を示す証拠は何かを書き留めます。 2 つ目では、ダミー データと小さなサンプルを使用して AI タスクをテストします: ケースの生成、差分のレビュー、またはバグの分類。ヒットだけでなく、拒否された結果と修正時間を節約します。 3 つ目では、現在の方法と比較して、それを維持するか、調整するか、破棄するかを決定します。この計画は、流行の予測に頼ることなく、チームに具体的なストーリーを提供し、面接での防御的なエクスペリエンスを生み出します。
プロファイルを開発するには、テストの基礎と製品に必要な専門性 (API とコントラクト、自動化、データ、パフォーマンス、アクセシビリティ、セキュリティ、または生成システムの評価) を組み合わせます。製品と開発を理解する言語でトレースを読み取り、権限を確認し、リスクを説明する方法を学びます。スキルは、きれいなプロンプトを書くことではありません。反復可能なチェックを設計し、モデルがいつルールを作成したかを検出し、決定が信頼できる理由を証拠とともに示すことです。各コンピテンシーに対する実際の需要は、講演や世界的なレポートから推測するのではなく、市場での役割や会話によって確認する必要があります。
ツールがケースを生成したりウォークスルーを実行したりするときに、チームが作成されたスクリプトや実行されたテストのみをカウントする場合、QA の価値が見えにくくなる可能性があります。観察可能な結果で説明することをお勧めします。リリース前にどのようなリスクが発見されたか、どのような曖昧な仮定が明確になったか、どのような証拠によって誤検知を除外できたか、そのレビューのおかげでどのような決定が変更されたかなどです。これは、結果全体を QA のせいにするという意味ではありません。これは、分析と製品またはエンジニアリング上の決定との関係を示すことを意味します。具体的な事例は、開発部門やリーダーがなぜ専門家によるレビューが依然としてフローの中に存在するのかを理解するのに役立ちます。
学習方法も変わります。登場する新しいプロバイダーをすべてマスターする必要はありません。出力をチェックし、分類エラーを測定し、ログを読み取り、テストがカバーしていると主張する要件をカバーしていないことを認識する方法を学ぶ方がより有益です。 QA を始めた人にとって、テスト技術、SQL、HTTP、バージョン管理、およびエラーの読み取りの基礎は、特定のインターフェイスを覚えるよりも多くのオプションを提供します。経験のある人の場合、次のステップは、エージェントが権限、データ、証拠とどのように統合されているかを確認することかもしれません。どちらの場合も、流行のタイトルではなく、再現可能な作業と説明された決定によって基準が実証されています。