AIはQAを代替していない、むしろその可能性を拡張している

生成 AI が登場した際、多くの職種に対して似たような疑問が投げかけられました。「この仕事は AI に代替されるのか？」「反復的な業務は自動化されるのではないか？」「結局、人間の役割は縮小してしまうのではないか？」といった疑問でした。

QA も例外ではありませんでした。AI がテストケースを代わりに作成できるとしたら、QA の役割はどうなるのでしょうか？AI がバグ分析を行い、ユーザーレビューの分析まで自動化された場合、QA には何が求められるのでしょうか？

生成 AI 技術が急速に進化するにつれ、自然とこうした疑問が浮上しました。そして、LINE アルバムの QA でも同様の悩みを抱えていました。AI を導入すれば、QA の役割は縮小してしまうのでしょうか？それとも、まったく異なる形へと変化するのでしょうか？実際の運用経験を通じて私たちが得た結論は、予想とは少し異なるものでした。

AI は QA を代替していません。むしろ、QA の思考範囲と影響力を拡張したのです。

私たちは、AI を単なる生産性向上ツールとして使用するアプローチには限界があると考えました。文書の要約や、テストケースのドラフト生成といったレベルの活用だけでは、QA の業務プロセス自体を変革することは難しいためです。そこで、LINE アルバムの QA では、AI を個別のツールとして使用するのではなく、QA の運用体制そのものを AI を中心に再設計するというアプローチを採用しました。

これには一つの重要な前提があります。それは、QA の生産性が単にテストをどれだけ速く実行できるかによって決まるわけではないということです。実際、QA の業務は、多様な情報の中から文脈を理解し、リスクを判断するプロセスに近いものです。企画文書、開発の変更点、ユーザーからのフィードバック、テスト結果など、さまざまな情報源からの情報を素早く理解し、それらを結びつける能力こそが品質管理の要なのです。

この観点から見ると、QA における課題はテストのスピードではなく、情報の量と複雑さにあります。そしてまさにこの点において、AI は単なる生産性向上ツールではなく、情報を構造化し、思考を拡張する自動化ツールとして機能し始めました。

この記事では、LINE アルバムの QA が AI 導入で経験した変化と、AI を中心に品質管理体制をどのように再設計したか、その事例を紹介します。

QA の役割はそもそも「テスト」ではなかった

前述したように、QA における本質的な課題はテストのスピードではなく、情報の量と複雑さにあります。この点を理解するために、まずは QA の役割を改めて整理してみましょう。

LINE ヤフーにおいて QA エンジニアは、単に機能を検証する役割にとどまりません。プロダクト開発のプロセス全体を通じて、品質の観点から洞察を提供する役割を担っています。企画段階では機能設計において発生しうるリスクを事前に特定し、開発段階ではコードの変更がプロダクト全体にどのような影響を与えるかを分析します。その後、テスト戦略を策定して実際の検証を行い、リリース後は、ユーザーからのフィードバックや運用データを再びプロダクトの改善プロセスに反映させます。

このような観点から見ると、QA の役割は単なるテスト実施者ではなく、プロダクト開発の全プロセスを繋ぐ品質アーキテクト（quality architect）に近いと言えます。QA は、「Plan–Dev–Test–Release」というプロダクトライフサイクル全体を通じて品質の観点を維持し、各段階の情報を結びつける役割を担っています。

下図は、各段階における QA の活動と、それに関連するツールを示したものです。

図 1. プロジェクト管理における各段階の QA 活動とツール

問題は、こうした役割を果たすために処理する情報の量が増え続けているという点でした。実際の QA 業務では、さまざまな情報源から同時に膨大な情報が生まれ、流入してきます。企画文書や技術設計書は継続的に更新され、Slack には機能に関する議論やそれに伴う意思決定が数多くのスレッドとして残ります。Jira には新しい課題やタスクチケットが次々と作成され、サービスリリース後にはさまざまな言語で書かれたユーザーレビューやフィードバックが蓄積され始めます。さらに、自動テストスクリプトや実行ログまで加わることで、QA が扱うべきデータの量は急速に増加します。

要するに、QA の生産性を左右する要素は、「テストをどれだけ迅速に実行できるか」ではなく、「分散した情報をいかに素早く構造化し、文脈を理解してリスクを判断できるか」です。なぜなら、QA はテストを実行する者である以前に、多様な情報の中から品質に関するシグナルを見出す役割を担っているからです。そして、まさにこの点において、AI が重要な役割を果たし始めました。

AI を「対話型ツール」から「品質ワークフロー」へ

AI を初めて導入した当初は、その活用方法が比較的シンプルなものでした。QA エンジニアは生成 AI を活用して、企画文書の要約やテストケースのドラフト生成、複雑なバグレポートの整理、再現手順の文書化といった作業に役立てました。このような活用だけでも、生産性は一定程度向上しました。

しかし、実際の業務に適用していく中で、一つの重要な違いに気づきました。それは、AI を単なる補助ツールとして使用することと運用体制に統合することは、まったく別物だという点です。

当初のアプローチでは、QA エンジニアが必要に応じて AI に質問を投げかけ、その結果を受け取って活用するという仕組みでした。この方法は、個人の生産性を高めるには効果的でしたが、QA 運用全体の効率を改善するには限界がありました。何よりも、QA 業務の大部分は、人間が直接リクエストを行う前に、すでにシステム内でさまざまな形のイベントとして発生していたからです。

例えば、新しい Jira チケットやプルリクエスト（以下 PR）が作成されたり、自動テストが実行されたり、ユーザーレビューが蓄積されたりするたびに、品質に関する重要なシグナルが発生します。しかし、従来のアプローチでは、QA エンジニアがこれらの情報を自ら収集・整理したうえで、AI に提供していました。つまり、AI を活用するために、また別の手作業が発生する仕組みだったのです。

そこで、私たちはアプローチを転換することにしました。「AI を、人間が必要とする時に呼び出すツールとして使用するだけでなく、品質イベントに反応するシステムにできないだろうか？」と考えたのです。その結果、LINE アルバムの QA では自動化ワークフローシステムを構築しました。現在では、30 以上のワークフローが稼働しており、さまざまな品質関連のイベントが発生すると、AI が自動的に分析する仕組みとなっています。

図 2. AI 自動化ワークフローによるプロジェクト管理手法

このシステムにおいて、AI はもはや、人間が入力欄に質問を投げかけたときだけ動作する対話型ツールではありません。Jira チケットの作成、コードの変更、テストの実行、ユーザーからのフィードバック収集といったイベントに反応し、データの分析や結果の構造化を行う品質管理体制の一部として機能しています。

こうした変化は、単に業務のスピードを上げる自動化の枠を超え、QA が品質データを扱うアプローチそのものを変えるきっかけとなりました。

2 つの自動化の仕組み：スケジューリングと Webhook

私たちは AI を中心とした品質管理プロセスを構築するにあたり、すべての自動化を 2 つの方式に分けて設計しました。1 つは決められた時間に実行されるスケジュールベースの分析で、もう 1 つはイベントが発生した瞬間に実行される Webhook ベースの分析です。これら 2 つの仕組みは、それぞれ異なる目的で QA 業務を補完・サポートします。

スケジュールベースの自動実行

スケジュールベースの自動化とは、特定の時間に繰り返し実行される分析フローのことです。定期的に蓄積される品質データを収集・要約し、QA チームが状況を迅速に把握できるようにサポートします。

例えば、毎日 App Store から収集するレビューを自動的に分析して主要な課題を分類したり、API 自動テストの結果を要約して Slack チャンネルに共有したりするワークフローを運用しています。また、UI 自動テストの実行結果をもとに要約レポートを作成するほか、一週間の品質管理活動と主要な課題をまとめた週間 QA レポートも自動的に作成されます。

こうした自動化により、QA エンジニアの役割も自然と変化しました。以前は複数のシステムからデータを自ら収集・整理する必要がありましたが、現在はすでに構造化された結果をもとにリスクを判断し、必要な部分の検証に注力しています。

以下は、業務システムの一つである Jira から QA 関連データを自動的に収集し、Slack に通知するワークフローの例です。

図 3. Jira チケットのうち QA がメンションされているチケットとその内容を Slack に通知するワークフロー

Webhook ベースのイベントトリガー

スケジュールベースの自動化が定期的な分析に焦点を当てているのに対し、Webhook ベースの自動化は、品質関連のイベントが発生した瞬間に即座に動作する仕組みです。

例えば、新しい Jira チケットの PR が作成されマージされると、コードの変更内容をもとに潜在的な影響範囲を要約し、Slack 上で機能について議論していたスレッドが終了すると、主要な意思決定をまとめた議事録を作成します。また、自動テストの結果がアップロードされると、実行統計を分析して可視化するワークフローも連携して動作します。

こうしたイベントベースの自動化により、QA チームは品質に関する重要なシグナルをはるかに迅速に把握できるようになりました。

図 4. PR を分析して変更点とテストの要点を Jira のコメントに追加するワークフロー

現在の QA 業務フロー

これら 2 つの自動化の仕組みを組み合わせることで、QA 業務フローも以前とは異なる形に整理されました。AI は情報を収集・分析・整理する役割を担い、QA エンジニアはその結果をもとにリスクを判断し、最終的な意思決定を行います。これは、単に自動化ツールを追加する程度の変化ではありません。QA が品質データを扱うアプローチや、QA 業務の起点そのものを変える変化でした。

以下は、ワークフローによって自動化された LINE アルバムの QA における、定型的な 1 日の業務フローを示した例です。すべてのイベントは Slack に通知されます。

時間タスク

〜 00:00

UI 自動テスト

MagicPod で実装した Android および iOS の UI 自動テストを実行します。テスト結果は自動的に Jira チケットに反映され、Slack にも共有されます。テストが失敗した場合はテスト失敗の分析を実行し、フレーキーテスト（flaky test）によるものなのか、その原因を分析します。

図 5. LINE アルバム Android の UI 自動テストを実行してその結果を Slack に通知

08:00

API 自動テスト

Pytest で実装された API 自動テストを実行します。前述と同様に、その結果は Jira チケットに反映され、Slack にも共有されます。

図 6. LINE アルバム API テストを実行してその結果を Slack に通知

09:00

デイリースクラムの開始

必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

{"translation": "翻訳全文"}

当日実施する主なテストの状況を事前に共有できるよう、スレッドを作成します。進捗状況を詳細に確認できるよう、スクラムボードのリンクと課題ダッシュボードを共有します。

図 7. デイリースクラムを開始するためのスレッドを自動作成

09:30

未解決課題の確認

関連するスレッドを通じて、現在進行中のテスト版における未解決課題の状況について報告を受けます。また、QA（品質保証）側の確認が必要な課題も自動的に抽出され、Slack に共有されます。

図 8. 未解決の課題と QA（品質保証）側の確認が必要な課題を整理して Slack に通知

09:30

メンションされた課題の確認

Jira チケットでメンションされるとメールで通知が届きますが、それらを分類するのは容易ではなく、当日確認すべきメンションだけを把握するのも簡単ではありません。そのため、スクラム開始時に事前把握できるよう、Slack へ自動でメンションを送信しています。これにより、メールや Jira チケットを開かなくても、自動で整理された内容を事前に確認できます。

図 9. 当日確認が必要なチケットについて担当者をメンションして Slack に通知

09:30

アプリレビューの分析

Android の Google Play ストアと iOS の App Store の情報をもとに、毎日自動的にレビュー内容を分析します。レビュー内容がポジティブかネガティブかを判断し、日本語と韓国語に翻訳して要約します。このように収集された内容は、さらに月単位でまとめて分析し、プロジェクトチームに共有します。

図 10. App Store に登録された日本語レビューを分析して Slack に通知

10:00 ~ 17:00

集中業務時間

必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等)は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

{"translation": "翻訳全文"}

QAエンジニアは、AIを用いて収集した品質情報をもとに品質計画を設計し、実行します。ワークフローの実行結果をモニタリングしながら、ワークフローの改善作業を行います。テストエンジニアは、AIツールを活用して手動テストと自動テストを実施します。このときは、リクエストイベントに応じて主要な会話スレッドをwikiドキュメントに要約する作業や、企画・開発文書またはチケットを分析する作業などが並行して行われます（企画・開発文書を分析してテストケースまで生成するワークフローについては、以下で詳しく説明します）。

図 11. スレッドを要約して Slack に通知

図 12. 開発チケットと Git の変更履歴を分析して自動的に Jira にコメントを追加

17:00

デイリースクラム終了

スクラムを終了するためのスレッドを生成します。当日実施する予定のタスクや課題を共有します。

図 13. デイリースクラム終了のためのスレッドを自動作成

AI はテストパートナー

テストケースの 9 割は今や AI が作成している

AI を中心とした品質管理体制を導入した後、ワークフローにおいて最も大きく変化した領域の一つは、テスト設計（test design）です。

現在、LINE アルバムの QA では、テストケースを作成する際、その初期段階の大部分を AI が担当しています。2026 年時点で、全テストケースの約 9 割のドラフトを AI が生成しています。これは、単なるテスト作成のスピード向上にとどまりません。テスト設計へのアプローチそのものが変わったことを意味しています。

興味深いのは、AI を活用したテストケースの自動作成自体が新しい試みではないという点です。すでに多くの QA 組織が生成 AI を活用してテストケースのドラフトを作成する実験を行っており、LINE アルバムの QA も当初は同様のアプローチをとっていました。要件や機能説明を入力すると、AI が素早く多数のシナリオを生成してくれ、一見するとかなりもっともらしく見えました。

しかし、実際の運用に適用してみると、その限界は明らかでした。AI は一般的な機能フローや典型的な例外ケースを素早く列挙することには長けていましたが、プロダクトの実際の文脈まで反映させるには不十分でした。どの機能がなぜ追加されたのか、過去にどのようなタイプの不具合が繰り返されたのか、今回の変更が既存のユーザーフローにどのような影響を与えるかといった情報が欠けている状態では、いくら多くの結果が生成されても、実際に活用できるテストケースは多くありませんでした。つまり、量は増えたものの、実行可能な品質は十分に向上しなかったのです。

そこで私たちは、単に AI に「テストケースを生成して」と指示するのではなく、QA 管理システムに蓄積されたさまざまな情報を併せて提供する仕組みを構築しました。機能仕様、開発チケット、過去の課題、変更の背景、テスト履歴、繰り返し発生した不具合のパターンなどを入力コンテキストとして結びつけ、AI がこの情報に基づいてテストシナリオを拡張するように設計しました。

この仕組みでは、オーケストレーターエージェントが調整を行い、その配下で 5 つのサブエージェントがそれぞれ異なる役割を担って連携します。以下の表は、各サブエージェントの役割と特徴をまとめたものです。

サブエージェント役割と特徴

Plan-Analyzer:企画文書を分析し、機能の目的、主要なフロー、リスク、テスト範囲を整理する

Dev-Analyzer:開発チケットと実装の文脈を分析し、技術的な変更点、依存関係、潜在的な影響範囲を洗い出す

TestCase-Generator:分析結果に基づいてテストケースを生成し、シナリオを構造化する

必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等)は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

{"translation": "しかし、実際の運用に適用してみると、その限界は明らかでした。AI は一般的な機能フローや典型的な例外ケースを素早く列挙することには長けていましたが、プロダクトの実際の文脈まで反映させるには不十分でした。どの機能がなぜ追加されたのか、過去にどのようなタイプの不具合が繰り返されたのか、今回の変更が既存のユーザーフローにどのような影響を与えるかといった情報が欠けている状態では、いくら多くの結果が生成されても、実際に活用できるテストケースは多くありませんでした。つまり、量は増えたものの、実行可能な品質は十分に向上しなかったのです。

そこで私たちは、単に AI に「テストケースを生成して」と指示するのではなく、QA 管理システム (Quality Assurance Management System) に蓄積されたさまざまな情報を併せて提供する仕組みを構築しました。機能仕様、開発チケット、過去の課題、変更の背景、テスト履歴、繰り返し発生した不具合のパターンなどを入力コンテキストとして結びつけ、AI がこの情報に基づいてテストシナリオを拡張するように設計しました。

この仕組みでは、オーケストレーターエージェント (Orchestrator Agent) が調整を行い、その配下で 5 つのサブエージェントがそれぞれ異なる役割を担って連携します。以下の表は、各サブエージェントの役割と特徴をまとめたものです。

サブエージェント役割と特徴

Plan-Analyzer:企画文書を分析し、機能の目的、主要なフロー、リスク、テスト範囲を整理する

Dev-Analyzer:開発チケットと実装の文脈を分析し、技術的な変更点、依存関係、潜在的な影響範囲を洗い出す

TestCase-Generator:分析結果に基づいてテストケース (Test Case) を生成し、シナリオを構造化する"}

TestCase-Validator：生成されたテストケースのカバレッジ、トレーサビリティ、形式、完成度を評価し、修正すべき点を検出する

Quality-Inspector：ワークフロー全体の成果物をチェックし、フィードバックや改善履歴を次回の実行に反映できるよう管理する

まず、Plan-Analyzer が企画文書や機能説明、画像分析に基づいて基本的な機能フローを整理し、Dev-Analyzer が開発チケットや実装情報の追加分析を行います。その後、TestCase-Generator が、正常フロー、例外フロー、境界値条件、プラットフォームの違い、優先度を反映したテストケースを生成します。このプロセスでは、単なる要件の解釈にとどまらず、過去の Jira 課題や蓄積されたバグパターンを参考にして、類似した不具合が発生する可能性が高い拡張シナリオまで提案します。つまり、「仕様書に書かれていること」だけをテストするのではなく、「過去に実際に問題となったケース」まで含めてテスト設計の範囲を広げるのです。

その後、TestCase-Validator は生成されたテストケースを再検討します。要件のカバレッジ、トレーサビリティ、シナリオの完成度、Given/When/Then 形式の適合性、優先度の分布、プラットフォームのカバレッジなどをチェックし、不備があれば生成段階へフィードバックを送ります。この検証ループを通じて、テストケースは単なるドラフトレベルを超え、実際に実行可能なレベルになります。

必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

{"translation": "その後、TestCase-Validator は生成されたテストケースを再検討します。要件のカバレッジ、トレーサビリティ、シナリオの完成度、Given/When/Then 形式の適合性、優先度の分布、プラットフォームのカバレッジなどをチェックし、不備があれば生成段階へフィードバックを送ります。この検証ループを通じて、テストケースは単なるドラフトレベルを超え、実際に実行可能なレベルになります。"}

次に、Quality-Inspector が最後の役割を果たします。この段階では、単に今回の実行結果を確認するだけでなく、過去のフィードバックや品質評価結果も併せて参照し、次回の実行でより優れたテストケースを生成できるよう、改善点を蓄積していきます。つまり、このワークフローは毎回独立して動作する単なる自動化ではなく、実行を重ねるごとに、より良いテスト設計の方向性を学習していく運用体制に近いものです。

下図は、このテストケース生成ワークフローをステップごとにまとめたものです。

図 14. テストケース生成ワークフローの各ステップの定義

結果的に、AI は企画文書、開発の文脈、過去の課題、検証フィードバックを結びつけ、テスト設計を拡張する中核的な構成要素となりました。これをもとに、QA エンジニアは最終的な判断、文脈の解釈、優先度の調整、および実際の実行可能性の検討を担当します。その結果、現在のテスト設計プロセスは次のような形で運用されています。

• 約 9 割：AI がテストケースのドラフトを生成
• 約 1 割：QA がプロダクトの文脈とリスクの観点から検証・加筆修正

特に、比較的シンプルな機能や要件が明確な機能については、AI が生成したテストケースをほぼそのまま活用する事例もだんだん増えています。

この変化は、QA の役割を縮小させたのではなく、その役割の重点をシフトさせました。QA はもはや、テストケースを一つひとつ作成する作業に時間を費やすことはありません。その代わり、AI が生成したテスト戦略が実際のプロダクトのリスクを十分に反映しているかどうかを判断することに注力しています。

「人間のみ」「AI のみ」「人間と AI の協働」によるテストケース作成のブラインド実験

AI が生成したテストケースのドラフトを実運用に活用し始めた際、ある疑問が生じました。「このアプローチは本当により良い結果を生み出すのか？」ということです。これを確認するため、LINE アルバムの QA では内部で約 1 年間にわたりブラインド実験を実施しました。

実験は以下のように行われました。各バージョンにおいて、テストエンジニアにテストケースを渡し、従来と同様にテストを実施してもらったうえでフィードバックを受けます。ただし、その際に提供するテストケースには、「QA エンジニアが単独で作成したもの」、「AI が単独で生成したもの」、「AI が生成したドラフトを QA がレビューして加筆修正したもの」が混在しています。それぞれのテストケースを同一の基準でレビューし、テストシナリオのカバレッジと文脈の適合性を中心に評価しました。以下の表は、その結果をまとめたものです。予想以上に明確な違いが見られました。

手法特徴

人間のみ安定したシナリオ構成だが、カバレッジの拡大には限界がある

AI のみ多様なシナリオを生成可能だが、プロダクトの文脈を判断する能力に欠ける

AI + 人間カバレッジと文脈の理解がバランスよく調和した、最も高い完成度

人間が作成したテストケースは、プロダクトの文脈を的確に反映しており、品質も安定していましたが、多様な例外状況や拡張シナリオを迅速に探索するには限界がありました。一方、AI は非常に幅広いシナリオを提案したものの、実際のサービスの文脈や優先度を十分に反映できていない場合がありました。

AI モデルの性能が向上するにつれ、テストケース生成用のデータとして企画文書のみを提供した場合でも、生成結果が悪くなかったため、AI が生成したテストケースをテストエンジニアが見て、人間が作成したものだと勘違いするケースが徐々に増えてきました。ただし、そのように生成されたテストケースの水準が平均的に高いとはいえ、機能の規模によっては各テストケース間の品質にばらつきが見られました。

最も良い結果が得られたのは、AI がドラフトを生成し、QA（Quality Assurance：品質保証）がそれを検証して加筆修正するアプローチでした。AI が迅速にさまざまな可能性を模索し、QA がプロダクトの文脈やリスクの特定という観点からそれを精査することで、両方のアプローチのメリットが自然に融合しました。

結論は比較的シンプルでした。最も良い結果を生み出したのは AI 単体ではなく、AI と人間が協働する仕組みでした。つまり、テスト設計においても重要なのは AI の単独活用ではなく、「ヒューマンインザループ（human-in-the-loop）」の仕組みであると確認できたのです。

「ヒューマンインザループ」は選択肢ではなく設計原則

前述のブラインド実験を通じて、ある事実を確認できました。テスト設計において最も良い結果を生み出したのは、AI のみでも人間のみでもなく、AI と人間が協働して機能する仕組みであるということです。

この仕組みを説明する際によく登場する概念が、「ヒューマンインザループ」です。ヒューマンインザループとは、AI システムがすべての意思決定を自動的に行うのではなく、人間が重要な判断プロセスに継続的に関与する仕組みを指します。特に品質のように、プロダクトの安定性やユーザー体験に直接的な影響を与える領域では、この仕組みがさらに重要となります。

AI は特定の領域において非常に強力な能力を発揮します。大量の情報を迅速に要約したり、データの中から繰り返されるパターンを検出したり、さまざまな可能性に基づいてドラフトを生成したりする作業は、AI が特に得意とする領域です。また、多言語で書かれたユーザーレビューやフィードバックを同時に分析する作業においても、AI は高い効率性を発揮します。

しかし、このような能力だけでプロダクトの品質を決定することはできません。実際のプロダクト環境では、単純なデータ分析にとどまらず、文脈や判断を必要とする意思決定が絶えず発生します。機能がプロダクトの哲学に沿って設計されているか、現在の優先度が組織の戦略に合致しているか、ユーザーの感情や体験の面でどのような影響を与えるかといった判断は、依然として人間の役割です。何より、最終的にプロダクトのリスクを承認し、責任を負うプロセスには人間の判断が不可欠です。

AI は多様な可能性を急速に広げることができますが、その方向性を決定するのは人間です。こうした理由から、LINE アルバムの QA ではヒューマンインザループ（human-in-the-loop）を単なる運用方法ではなく、品質システムを設計する基本原則として捉えています。AI が分析と拡張を担当し、QA が文脈とリスクの判断を担当するという役割を明確に分け、両方のメリットを同時に活用することを目標としています。結局、重要なのは、「AI をどれだけ多く使うか」ではなく、「人間と AI がどのような仕組みで協働するように設計したか」でした。

これからのペアテストは人間と AI の協働で

AI の活用は、定型化されたテストケースの生成にとどまりませんでした。最近では、探索的テスト（exploratory testing）の領域でも、人間と AI が協働するアプローチが実際の QA 運用に導入され始めています。

従来の探索的テストは、テスターの経験と直感に大きく依存していました。そのため、熟練した QA エンジニアが実施する場合は非常に強力な反面、個人の経験レベルによってテストの深さや探索範囲が大きく左右されるという限界もありました。どのリスクを先に想定すべきか、どの経路をより深く探索すべきかは、結局のところテスター個人の経験に依存することが多かったのです。

こうしたデメリットを補うため、QA 現場ではペアテストを活用することもあります。これは、2 人のテスターが一緒に機能を探索しながら、互いに異なる観点から交差検証を行う手法です。1 人が見落としたリスクをもう 1 人が発見できるため、探索的テストの品質を高めるうえで効果的な方法です。

しかし、ペアテストにも現実的な制約があります。最大の問題はリソースです。2 人の QA エンジニアが同時に 1 つの機能をテストしなければならないため、常に実施するのは困難です。また、2 人がペアを組んだとしても、経験が浅ければ十分に深く探索できない可能性もあります。

LINE アルバムの QA ではこの問題を解決するため、AI をペアテストのアシスタントとして活用しました。現在の探索的テストのプロセスにおいて、AI は過去の問題、機能変更の文脈、テスト履歴といったデータに基づき、探索的テストチャーター（test charter）を提案し、追加の探索経路を提示します。QA エンジニアはこれをベースにテストを進めながら、必要に応じて AI に対して過去の類似問題の確認や、新たなテストの観点をリクエストできます。

さらに、主要な画面ごとに過去に発生した問題の割合を確認したうえで、優先度の高いテストやリスクベースのテスト（risk-based testing）の実行を提案されることもあります。以下の表は、削除機能に関連する過去の問題をもとに AI から提案された内容です。

図 15. 各主要画面における問題発生頻度の例

このように、AI が過去のデータに基づいて新たな探索の観点を提案し、テストエンジニアはプロダクトの文脈を考慮して実際のリスクを判断しながらテストを行います。現時点では、AI が単独で探索的テストを実行できるわけではなく、まだ改善すべき点も残されていますが、実際の運用ではポジティブな反応を得ています。経験豊富なシニアテストエンジニアのサポートがなくても、探索的テストのプロセスで考慮すべき視点をより迅速に把握して拡張でき、過去の問題をもとに提案されたテストを参考にして、より多様なシナリオを探索できるためです。

AI 導入の効果は時間の削減ではなく思考密度の向上

AI 導入の効果について語る際、最もよく聞かれる質問があります。それは、「その結果、どれくらいの時間が削減できたのか？」というものです。自動化の導入事例の多くが、業務時間をどれだけ節約できたかに焦点を当てているためです。

しかし、LINE アルバムの QA で実感した変化は、少し異なる方向性のものでした。AI を活用した自動化に伴い、反復作業の多くをシステムに移行しました。テスト結果の整理、ユーザーレビューの分析、レポート作成といった作業を自動化ワークフローが処理するようになり、QA エンジニアはこうしたデータを自ら収集・整理することに時間を費やす必要がなくなりました。

その結果、QA の業務は自然と、より高度な判断が求められる領域へとシフトし始めました。機能の変更がプロダクト全体にどのような影響を与えるかを分析し、テスト戦略をリスクベース (risk-based) に再設計し、ユーザーのフィードバックの中から重要な品質のシグナルを見出す活動に、より多くのリソースを割くようになりました。実際、リスクベースのテストの割合も以前より著しく増加しました。

興味深いのは、こうした変化にもかかわらず、QA の総労働時間が劇的に減少したわけではないという点です。その代わり、時間の使い方が変わりました。反復的な整理作業に費やしていた時間は減った一方で、プロダクトの文脈を理解し、品質リスクを判断するという高付加価値な意思決定により多くの時間を割くようになったのです。

この経験を通じて、私たちは一つの明確な確信を得ました。AI 導入の本質的な効果は、単なる時間の削減ではありません。AI は、QA エンジニアがより多くの文脈を同時に考慮し、より深い判断を下せるよう、思考の密度を高めてくれるツールに近い存在です。

QA は今や品質オーケストレーターへ

AI による自動化が QA 業務に深く統合されていくにつれ、QA の役割も自然と変化し始めました。かつてはテストケースの作成や実行、結果の検証といった作業が QA 業務の中心でしたが、現在では AI や自動化システムを活用して品質管理全体を設計・運用する役割がますます重要になっています。

現在の LINE アルバムの QA においても、QA エンジニアの役割は以前よりも明らかに拡大しています。まず、AI が生成する結果の品質を高めるために、どのような文脈情報を入力として提供するかを設計し、結果をどのような形式で構造化するかをコントロールする作業が重要性を増しています。入力の設計によって、AI が生成する結果の品質や活用可能性が大きく左右されるためです。

また、さまざまな品質イベントを自動的に分析できるよう、自動化ワークフローを設計し、継続的に改善する作業も重要な役割となっています。Jira 課題の作成、コードの変更、テスト実行結果といったイベントが発生した際に、どのような分析を行い、どのような形式で共有すべきかを定義するプロセスも、QA 活動の一環となりました。

この過程で生成される多様なデータを理解し、有意義な品質シグナルを見出す品質データ分析の役割もますます重要になっています。そして何より、AI が提示した結果に基づいてプロダクトのリスクを判断し、最終的な決定を下す意思決定の役割が重要視されています。

このような変化は、単に QA が行う業務の内容が変わったというより、QA の視野が広がったことに近いと言えます。QA はもはや、単にテストを実施するだけの役割にはとどまりません。その代わりに、人間、AI、品質データ、自動化ワークフローが効果的に機能するよう、全体の仕組みを設計し、調整する役割を担うようになりました。

こうした意味で、今日の QA は単なるテスターというよりも、人間と AI の協働体制を設計する品質オーケストレーター（quality orchestrator）に近づきつつあります。

QA への AI 導入から得られた教訓

LINE アルバムの QA における AI 中心の品質管理体制からは、いくつかの明確な教訓が得られました。当初は AI の導入そのものが重要な課題のように見えたものの、実際に運用してみて、「AI をどれだけ使用するか」ではなく、「AI をどのようにワークフローに統合するか」が重要であることに気づきました。

AI は、単体のツールとして使用するよりも、運用システム内で自動的に動作させる方が、より大きな効果を発揮しました。単なるツールとして活用するのではなく、イベント駆動型ワークフローと組み合わせることで、初めて QA 業務の流れ全体が変化し始めました。

また、自動化がすべての問題を解決してくれるわけではないという点も明らかになりました。自動化は反復作業を減らし、分析のスピードを上げる点では非常に効果的ですが、どの問題を優先して取り組むべきかを決定するのは、依然として人間の役割でした。

テスト設計においても、同様の教訓が得られました。現在、テストケースの約 9 割は AI がドラフトを生成していますが、実際の品質を保証するためには、依然として人間の検証と判断が不可欠です。完全な自動化よりも、人間の判断を組み合わせた仕組みの方が、より安定した結果を生み出しました。

結局、私たちが導き出した結論は比較的シンプルなものでした。最良の結果は、AI を単独で使用する仕組みからは生まれませんでした。常に、AI と人間が連携して機能する仕組みから生まれたのです。この経験は、AI を導入する組織に対して重要な問いを投げかけます。それは、AI をどれだけ使用するかではなく、AI と人間がどのような仕組みで連携して働くように設計したかが、より重要な問題であるかもしれないということです。

結論：AI は QA を代替するのではなく、その可能性を拡張している

生成 AI が登場した当初、最も多く投げかけられた問いの一つがこれでした。

「QA は AI に代替されるのだろうか？」

実際の運用経験を通じて、私たちが得た答えは明確でした。AI は QA を代替していません。むしろ、QA の役割と可能性を拡張したのです。LINE アルバムの QA では、AI を単なる生産性向上のツールとして使用していません。AI に QA 業務の一部を代行させるのではなく、品質管理体制の中に統合しています。

現在、LINE アルバム QA の品質管理システムは、以下のような体制で運用されています。

• 30 以上の自動化ワークフローを運用
• スケジューリングと webhook 方式を組み合わせた品質イベント分析
• テストケースの約 9 割が AI によるドラフト生成
• ヒューマンインザループに基づく最終的な品質判断

この仕組みにおいて、AI は大量の情報を分析・構造化する役割を担います。そして、QA エンジニアはプロダクトの文脈を理解し、品質リスクを判断して最終的な意思決定を行う役割を担います。このような役割分担は、QA の業務を代替するものではありませんでした。むしろ、QA が扱える情報の範囲と思考の深さを拡張したのです。

QA はもはや、単にテストを実施する役割にとどまりません。AI の力を借りて拡張された情報に基づき、品質戦略を策定し、リスクを判断する役割へとシフトしつつあります。結局のところ、私たちが経験した変化は、自動化によって代替されるものではありませんでした。人間と AI が調和し、品質管理体制が拡張されていく変化だったのです。そこで、この記事を次の言葉で締めくくりたいと思います。

AI は QA を代替していない。むしろ、QA を拡張している。