こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2026年 4 月号 はお読みいただけましたでしょうか。今月は、6月25日と26日に AWS Summit Japan 2026 が開催予定となっており、AWS Village では Amazon Connect Customer に関する出展を行います。皆様とお会いできることを楽しみにしています。 今月はアップデート 情報に加え、AWS Summit の Amazon Connect Customer 関連セッションに関する情報をお届けします。皆様のお役に立つ内容があれば幸いです！今月は 以下の内容でアップデート情報をお届けします。 AWS Summit Japan 2026 Amazon Connect Customer 関連セッション 2026 年 5 月のアップデート一覧 AWS Contact Center Blog のご紹介 今月のアップデートに関するよくある質問 1. AWS Summit Japan 2026 Amazon Connect Customer 関連セッション AWS Summit Japan 2026 では、今年も Amazon Connect Customer のお客様導入事例や、ユースケースを元にした最新機能のご紹介についてのセッションを行います。皆様のコンタクトセンター改革のヒントとなる情報をご提供いたしますので、是非ご参加ください。最新のセッション情報、およびご登録については AWS Summit Japan ページをご覧下さい。 日付 時刻 タイトル 6/25(木) 11:30～12:10 AI ネイティブで実現する、妥協なき顧客体験 — Amazon Connect Customer － 6/25(木) 12:20～12:50 JRE GO — 予約体験の再設計と内製開発 6/25(木) 12:30～13:10 Amazon Connect Customer で実現する進化したコンタクトセンター — Agentic AI が変える顧客体験 — 6/25(木) 16:30～17:10 パーソナライズでビジネス成長を実現するコンタクトセンターへ ― AI エージェントが顧客を知り、先回りする― 6/26(金) 13:40～14:10 東京電力におけるコンタクトセンター変革 － CX 向上に向けた AI 活用の取り組み－ 2. 2026 年 5 月のアップデート一覧 Amazon Connect Customer のタスクは何日先までスケジュールできますか？最長90日先までの登録に対応しました – 2026/05/29 Amazon Connect Customer で、最長90日先までのタスクをスケジュール登録できるようになりました。組織が長期にわたるフォローアップ作業の計画、ルーティング、および追跡を行えるようになります。例えば、自動車修理の請求を管理する保険チームでは、査定員の訪問、部品の在庫確認、修理完了後のフォローアップのために将来のタスクをスケジュールでき、それぞれのタスクは関連する請求のコンテキストを保持したまま、適切なタイミングで適切なチームにルーティングされます。タスクのスケジュール登録は、StartTaskContact API、フロー、またはエージェントワークスペースから行えます。この機能は、Amazon Connect Customer が提供されているすべての商用リージョンおよび AWS GovCloud（米国）リージョンで利用可能です。 管理者ガイド Amazon Connect Customer のタスク Amazon Connect Customer のコンタクト後の要約は日本語に対応していますか？日本語を含む8言語ファミリーが新たに追加されました – 2026/05/28 Amazon Connect Customer の生成 AI を活用したコンタクト後の要約が、日本語を含む8つの言語ファミリー（ポルトガル語、フランス語、イタリア語、ドイツ語、スペイン語、中国語、日本語、韓国語）に対応しました。コンタクト後の要約は、音声・チャット・メールチャネルにわたる顧客との会話の簡潔で構造化された概要をエージェントやマネージャーに提供し、トランスクリプト全体を読む必要をなくします。この拡張により、会話で使用された言語で要約が自動的に生成されるため、エージェントはコンタクト後の作業をより迅速に完了でき、マネージャーは複数の言語でコンタクトを確認できるようになります。例えば、グローバルなサポート組織では、フランス語、ドイツ語、日本語で対応した通話の要約を自動生成し、スーパーバイザーがすべての地域のサービス品質を把握できます。この機能は、Amazon Connect Customer のコンタクト後の要約が提供されているすべての AWS リージョンで利用可能です。 管理者ガイド 生成 AI を活用したコンタクト後の要約の表示 Amazon Connect Customer のステップバイステップガイドを自然言語で作成できますか？ノーコード UI ビルダーに AI アシスタントが搭載されました  – 2026/05/28 Amazon Connect Customer アシスタントが UI ビルダーに統合され、コンタクトセンターのマネージャーが自然言語を使用してビューを作成・変更できるようになりました。例えば、「評価フィールドとコメントフィールドを含んだフィードバックフォームを作成」と説明するだけで、対応する UI コンポーネントが自動生成されます。生成されたものはレビューしてから公開でき、ステップバイステップガイドやワークスペースページのビュー作成に必要な時間と専門知識を最大70%削減できます。マネージャーは会話形式のプロンプトを使用して、ビューの作成、条件付き UI によるレイアウトの設定、コンポーネントプロパティの設定、スタイルの適用を、手作業に頼らずに行えます。アシスタントはコンポーネントの推奨、オプションの説明、問題のトラブルシューティングも行い、構築作業を迅速化します。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、アフリカ（ケープタウン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、欧州（フランクフルト）、欧州（ロンドン）、AWS GovCloud（米国西部）の各 AWS リージョンで利用可能です。 管理者ガイド Connect assistant in the UI builder Amazon Connect Customer で AI エージェントによるセルフサービス対話の品質を自動評価できますか？生成 AI を使用した自動評価が可能になりました – 2026/05/27 Amazon Connect Customer で、マネージャーが生成 AI を使用してセルフサービスの対話を自動的に評価し、カスタマーエクスペリエンスを向上させるための集約されたインサイトを取得できるようになりました。マネージャーは評価フォーム内で「お客様の問題はすべて AI エージェントによって解決されたか?」など、自然言語でカスタム評価基準を定義できます。生成 AI はこの基準を使用してセルフサービス対話の質を評価し、会話の文字起こしからの関連する参照ポイントとともに、評価の詳細な推論を提供します。管理者は、これらのインサイトのまとめや個々の問い合わせについて、セルフサービス対話の記録や文字起こしと合わせて確認し、AI エージェントのパフォーマンスを向上させる機会を特定できます。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、欧州（フランクフルト）の AWS リージョンで利用可能です。 管理者ガイド セルフサービス対話のパフォーマンス評価 Amazon Connect Customer のエージェントログイン/ログアウトレポートにきめ細かなアクセス制御は適用できますか？タグベースアクセスコントロールに対応しました – 2026/05/26 Amazon Connect Customer のエージェントログイン/ログアウトレポートで、タグベースのアクセスコントロールがサポートされるようになりました。データアクセスに関するコンプライアンスおよび規制要件を満たすために、きめ細かなアクセス制御を適用できます。コンタクトセンター管理者は、リソースタグを使用して、特定のエージェントのログインおよびログアウト情報を閲覧できるユーザーを制御できます。例えば、エージェントに「Department: Customer Service」というタグを付けると、カスタマーサービスのチームマネージャーのみがこれらのエージェントのログイン/ログアウト情報を確認できるようになります。この機能は、Amazon Connect Customer が提供されているすべての AWS 商用リージョンおよび AWS GovCloud（米国西部）リージョンで利用可能です。 管理者ガイド タグベースのアクセス制御 Amazon Connect Cases でエージェントがケースの関連項目を編集・削除できますか？エージェントワークスペースからの直接操作に対応しました – 2026/05/15 Amazon Connect Customer Cases で、関連項目の編集と削除、およびエージェントワークスペースからのケースの直接削除が管理者の介入なしで行えるようになりました。エージェントは、コメントを更新したり、間違ったケースに関連付けられている連絡先のリンクを解除したり、誤って開かれたケースを削除したりできます。また、注文、返品、請求書などのカスタム関連項目を作成・編集・削除して、追加のケースコンテキストを把握することも可能です。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、欧州（フランクフルト）、欧州（ロンドン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、アフリカ（ケープタウン）の各 AWS リージョンで利用可能です。 Amazon Connect Customer でエージェントが自分のパフォーマンス評価だけを確認できますか？自己評価の表示専用権限が追加されました – 2026/05/14 Amazon Connect Customer で、他のエージェントの評価を公開せずに、エージェントが自分のパフォーマンス評価のみにアクセスできる権限がサポートされるようになりました。エージェントはフィードバックを確認してパフォーマンスを向上させることができます。この権限により、エージェントは自分が評価を受けたコンタクトを検索し、通話録音やトランスクリプトと並べて評価を確認したり、確認後に承認を送信したりできます。例えば、複数のコンタクトにまたがる顧客の問題を調査するために部署全体の連絡先を閲覧する権限をエージェントに付与しつつ、評価については自分のものだけを確認できるように設定できます。同僚の機密性の高いパフォーマンスデータをエージェントが閲覧できない状態を確保しながら、運用上の柔軟性を提供します。この機能は、Amazon Connect Customer が提供されているすべての AWS リージョンで利用可能です。 管理者ガイド 評価とコーチングの権限 Amazon Connect Customer の Cases と Customer Profiles をカスタムエージェントアプリケーションに埋め込めますか？SDK による統合が可能になりました – 2026/05/12 Amazon Connect Customer で、カスタムエージェントアプリケーションに Cases と Customer Profiles を埋め込めるようになりました。エージェントは問題解決のために既に使用しているツールに加えて、ケースの詳細や顧客のコンテキストにアクセスできるようになります。デベロッパーは Amazon Connect SDK を使用してネイティブの Connect 環境をカスタムアプリケーションに取り込むことができるため、これらの機能をゼロから構築して保守する必要がなくなります。この機能は、Amazon Connect Customer が提供されているすべての AWS リージョンで利用可能です。 管理者ガイド / デベロッパーガイド カスタムアプリケーションへの統合 Amazon Connect SDK（GitHub） Amazon Connect Customer のアフターコンタクトワーク時にステップバイステップガイドを自動起動できますか？ACW 用デフォルトガイドが追加されました – 2026/05/08 Amazon Connect Customer で、アフターコンタクトワーク（ACW）のデフォルトガイドがサポートされるようになりました。コンタクトセンターの管理者は、エージェントが ACW 状態になったときに手動操作なしでステップバイステップガイドを自動的に起動できます。処理コードの記録、ケースの更新、フォローアップアクションの完了など、必要なラップアップタスクをエージェントが自動的に実行できるようにすることで、コンタクト後のワークフローを標準化し、対応時間を短縮できます。ACW 中にエージェントが手動で正しいアプリケーションに移動する必要がなくなるため、コンタクトセンター業務全体において一貫性の向上、エラーの削減、エージェントの生産性向上が期待できます。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、アフリカ（ケープタウン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、欧州（フランクフルト）、欧州（ロンドン）、AWS GovCloud（米国西部）の各 AWS リージョンで利用可能です。 管理者ガイド Amazon Connect のフローブロック: ビューを表示 Amazon Connect Customer のアウトバウンドキャンペーンは複数タイムゾーンの顧客に適切な時間帯で配信できますか？複数の連絡先情報からのタイムゾーン検出に対応しました – 2026/05/07 Amazon Connect Customer のアウトバウンドキャンペーンで、主要な連絡先フィールドだけでなく、顧客プロファイルのすべての電話番号と住所を使用して顧客のタイムゾーンが検出されるようになりました。これまでは主要な電話番号のみが使用されていたため、複数のタイムゾーンにまたがる顧客を見落とす場合がありました。プロファイルの連絡先情報が複数のタイムゾーンにまたがっている場合は、検出されたすべてのタイムゾーンにおいて設定済みの時間帯に含まれる場合にのみ配信し、重複がない場合はプロファイルをスキップします。例えば、顧客に東部標準時の市外局番の携帯電話番号と太平洋標準時の市外局番の事業用電話番号があり、キャンペーンが午前9時から午後5時まで配信されるように設定されている場合、メッセージは両方のタイムゾーンが許可された時間帯に含まれる東部標準時午後12時から午後5時（太平洋標準時午前9時から午後2時）にのみ配信されます。この機能は、Amazon Connect アウトバウンドキャンペーンが提供されているすべての AWS リージョンで追加費用なしで利用可能です。 管理者ガイド アウトバウンドキャンペーンの配信時間設定 Amazon Connect Customer Cases で重複する顧客プロファイルが統合されたときケースも自動的にまとまりますか？アイデンティティ解決との連携に対応しました – 2026/05/05 Amazon Connect Customer Cases で、重複する顧客プロファイルが統合される際にケースが自動的に再度関連付けられるようになりました。これにより、エージェントは常にそれぞれの顧客の完全なケース履歴を確認できます。同じ顧客が異なるチャネルを通じて連絡したり、異なる連絡先情報を提供したりすることで複数のプロファイルが作成される場合があります。Amazon Connect Customer Profiles のアイデンティティ解決がそれらの重複を検出して統合すると、関連付けられたすべてのケースが Cases によって統合プロファイルに自動的にまとめられます。エージェントは複数のプロファイルを検索したり、顧客の履歴を手動でまとめたりする必要がなくなりました。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、欧州（フランクフルト）、欧州（ロンドン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、アフリカ（ケープタウン）の各 AWS リージョンで利用可能です。 管理者ガイド Amazon Connect Cases 3. AWS Contact Center Blog のご紹介 Amazon Connect Customer: 中国への発信におけるコンプライアンスのベストプラクティス (日本語翻訳) グローバルにビジネスを展開する企業にとって、中国（国番号 +86）への発信における通信規制への準拠は避けて通れない課題です。規制に適合しない設定のままアウトバウンド発信を行うと、通話切断やサービス停止、さらには中国への発信機能そのものの利用制限といった深刻な影響を受ける可能性があります。本記事では、Amazon Connect Customer を使用して中国へコンプライアンスに準拠した発信を行うための 5 つのベストプラクティス（承認済み DID 番号の設定、禁止番号タイプの排除、レート制限の実装、発信者 ID の設定、番号検証の実装）を紹介します。 4. 今月のアップデートに関するよくある質問 Q. Amazon Connect Customer とは何ですか？ Amazon Connect は、Amazon の運用実績に基づいて構築されたエージェンティック AI ソリューションのファミリーになりました。2026年4月に、Amazon Connect Customer（カスタマーエクスペリエンス）、Amazon Connect Decisions（サプライチェーン）、Amazon Connect Talent（採用）、Amazon Connect Health（ヘルスケア）の4つのソリューションに拡張されました。( Amazon Connect について ) コンタクトセンター領域を担う Amazon Connect Customer は、音声・チャット・メール・タスクなど複数のチャネルを一つのプラットフォームに統合し、AI を中核に据えたクラウドコンタクトセンターソリューションです。料金プランは、すべての AI 最適化機能がチャネル料金に含まれる「Amazon Connect Customer」（旧 Unlimited AI）がデフォルトです。従来のアラカルト型プランは「Amazon Connect Customer Basic」として既存顧客向けに提供されていますが、今後の新しい AI 機能は Connect Customer で提供されるため、Customer Basic からの移行が推奨されます。( Amazon Connect Customer について / Amazon Connect Customer の料金 ) Q. Amazon Connect Customer Tasks とは何ですか? Amazon Connect Customer Tasks は、音声・チャット・メールと同じように優先順位付け、割り当て、追跡、自動化ができる作業項目です。エージェントはエージェントワークスペース上でタスクを受け取り、フォローアップの電話、保険請求の処理、ケースの更新など、コンタクト対応以外の業務を管理できます。タスクは手動で作成するほか、コンタクトフロー内のアクション、ルール、StartTaskContact API から自動生成することも可能です。ルーティングプロファイルによりキューへの振り分けや優先度の設定ができ、今月のアップデートでは最長90日先までのスケジュール登録にも対応しました。（ Amazon Connect Customer Tasks ） Q. Amazon Connect Customer のステップバイステップガイドとは何ですか？ ステップバイステップガイドは、エージェントワークスペース上でエージェントに対して業務手順を段階的に案内する UI コンポーネントです。管理者はノーコードの UI ビルダーでフォーム、ボタン、テキストなどのコンポーネントを組み合わせてガイドを作成し、コンタクトフローでトリガー条件を設定できます。エージェントが通話を受けた際やアフターコンタクトワーク（ACW）に入った際に自動的に表示され、処理コードの入力、ケース作成、顧客情報の確認などを標準化された手順で実行できます。今月のアップデートでは、ACW 状態でデフォルトガイドを自動起動する機能と、AI アシスタントによる自然言語でのガイド作成（作成時間を最大70%削減）が追加されました。（ ステップバイステップガイド ） Q. Amazon Connect Customer にはどのようなレポートがありますか？ Amazon Connect Customer は以下のレポート・分析機能を提供しています。 リアルタイムメトリクス : キューやエージェントの現在の状態（待ち呼数、対応可能エージェント数、サービスレベルなど）をリアルタイムに表示します。 履歴メトリクス : 指定した期間のコンタクト数、平均処理時間、放棄率などを集計し、トレンド分析に活用できます。 ダッシュボード : キューとエージェントのパフォーマンスを視覚的に一覧でき、カスタムウィジェットやカスタムメトリクスの作成も可能です。 ログイン/ログアウトレポート : エージェントの勤務時間を追跡し、タグベースのアクセスコントロールによりチームマネージャーごとに閲覧範囲を制限できます。 会話分析（Conversational Analytics） : 音声・チャット・メールのコンタクトに対してリアルタイムおよびコンタクト後の分析を提供します。自動文字起こし、感情分析、コンタクトの自動分類、PII（個人識別情報）の墨消し、生成 AI によるコンタクト後の要約生成、テーマ検出などの機能を備えています。 分析データレイク : コンタクトデータを Amazon Athena や Amazon Quick で直接クエリ・分析でき、複雑なデータパイプラインを構築することなくカスタムレポートを作成できます。今月のアップデートでは、ログイン/ログアウトレポートへのタグベースアクセスコントロールが追加されました。 Q. Amazon Connect Customer の Identity Resolution(アイデンティティ解決)とは何ですか？ アイデンティティ解決は、Amazon Connect Customer Profiles の機能で、同じ顧客が異なるチャネルや連絡先情報で作成した複数のプロファイルを自動的に検出・統合する仕組みです。今月のアップデートにより、プロファイルが統合される際に Amazon Connect Cases のケースも自動的に統合プロファイルに再関連付けされるようになりました。エージェントは複数のプロファイルを検索する必要なく、常に顧客の完全なケース履歴を確認できます。( Amazon Connect Customer Profiles , Identity Resolution ) Q. Amazon Connect Customer Cases とは何ですか？ Amazon Connect Customer Cases は、顧客との応対履歴をケースとして作成・追跡・管理する機能です。エージェントはエージェントワークスペース内でケースの作成、ステータスの更新、関連するコンタクトやタスクの紐づけを一画面で行えます。ケースにはカスタムフィールドを定義でき、テンプレートを使って業種や業務に応じた構造化が可能です。コンタクトフローからケースを自動作成するルールも設定できます。今月のアップデートでは、エージェントがワークスペースから関連項目の編集・削除やケースの直接削除が可能になったほか、Amazon Connect Customer Profiles のアイデンティティ解決によりプロファイル統合時にケースが自動的に再関連付けされるようになりました。（ Amazon Connect Customer Cases ） Q. Amazon Connect Customer のアウトバウンドキャンペーンとは何ですか？ アウトバウンドキャンペーンは、Amazon Connect Customer Profiles のセグメントに基づいて、音声・SMS・メールなど複数チャネルで顧客にプロアクティブにアプローチする機能です。そして、ジャーニー（複数ステップのワークフロー）を設計し、顧客の行動や属性に応じたパーソナライズされたアウトリーチを実行できます。セグメントビルダーで対象顧客を定義し、ビジュアルフローデザイナーでマルチチャネルジャーニーを構築します。配信ガードレールやエンゲージメント設定により、適切な時間帯・頻度でのコミュニケーション管理も可能です。今月のアップデートでは、顧客プロファイルのすべての電話番号と住所からタイムゾーンを検出し、複数タイムゾーンにまたがる顧客にも適切な時間帯で配信できるようになりました。（ アウトバウンドキャンペーン ） 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせいただけますと幸いです。 AWS Summit Japan 2026 にもぜひご登録の上、ご来場ください。会場でお待ちしています！Amazon Connect Customer の最新情報は毎月このブログでお届けしていますので、来月号もお楽しみに。 著者プロフィール   梅田　裕義（Hiroyoshi Umeda） アマゾンウェブサービスジャパン合同会社 シニア Amazon Connect ソリューションアーキテクト 2020年12月入社。コンタクトセンター領域を専門に、Amazon Connect Customer を活用した顧客体験の向上や業務効率化の技術支援を行っています。AI によるセルフサービスの導入、オムニチャネル対応、分析基盤の構築などコンタクトセンターが抱える課題解決に幅広く取り組んでいます。

前回の山下さんからバトンを受け取りました、伊藤由貴です。 「E2Eテスト自動化」という話題は私としてもある程度関わってきたジャンルなので、なにか思考のタネをご提供できればと思います。 今回は山下さんから2つのポイントをいただいているので、それに対して私なりの意見をお伝えしつつ、私から山下さんや読者の皆さまに問いを立てていきます。 テスト自動化の移り変わりや流行りについて テスト自動化と一口に言っても、そのツールや対象などはだんだんと変化してきました。これはテスト自動化単独というよりは、例えばデスクトップからWeb・モバイルへと、一般的なアプリケーションの動作環境が変わってきたことなど、さまざまな環境要因によるものです。 いろいろと思い出話をしてしまうと長くなるので割愛しますが、ここ10年ほどはWebアプリケーションの自動化がかなり盛り上がった期間だったように思います。SeleniumやPlaywrightなどオープンソースのライブラリが登場したことで、それまでの高価・高機能な有償ツールを用いた自動化から、誰でも手元で学習・トライアルできる自動化へと移り変わってきました。 そして現在は、生成AIによるコード生成など、また新たな変化の波が来ています。このあたりは山下さんの記事中でも言及されていましたね。 問い：生成AIの登場でノーコードのテスト自動化ツールがどのような影響を受けるのか 山下さんからいただいたポイントのひとつがこちらです。 まず、この問いの背景情報として、私は現在「ノーコードのテスト自動化ツール」を提供する会社に所属しています。そのため（可能な限りフラットに発言しようと思いますが）バイアスが含まれていたり、ポジショントークのように見えたりする可能性があります。読者の皆さまに対してフェアでいるためにも先にお伝えしておきます。 そのうえで、実はこうした「ノーコードテスト自動化ツールは生成AIにどのような影響を受けるか」に類する質問は最近よくいただきます。山下さんがそのような意図かどうかは別として、多くは「（ビジネス的に）大丈夫なの？」という言外のニュアンスを含んでいるようです。SaaS is DEADなどと言われることもあるように、生成AIが既存のツールやビジネスを破壊する、駆逐するといった印象をもたれることは、一般論として増えていそうです。 このような側面は、確かにあると思います。ノーコードテスト自動化ツールは、コードを読み書き出来なくてもテスト自動化ができる、という点が一つのメリットです。ところが生成AIを使うことでも、コードを書かずに（正確にはAIがコードを書いてくれることによって）テストを自動化できるようになりました。最近は全社員が生成AIを使えるという会社も増えていて、テスト自動化に限らずさまざまなツールの契約を見直し、生成AIでできることはそれでまかなってしまおう、という動きも多くあるようです。ただ、個人的には生成AIでノーコードツールが完全に代替できるかというと、そうではないと考えています。生成AIのサポートで自動化ができる人・チームもあれば、やっぱりノーコードツールが必要だよねという人・チームもあるだろう、という予想です。 生成AIで自動テストコードが生成できるのは確かに便利ですが、私が JaSST’26 Tokyoのセッション でも繰り返し述べたように、テスト自動化は運用が大事です。 個人の、あるは短期的な視点で「自動化をする」「自動テストを生成する」ことはできても、組織で、長期的な視点で「自動テストを継続的に運用する」ためには、生成AIだけでほんとうに十分なんだろうか？そこにノーコードツールの強みがあるのではないか？と思っています。 生成AIはものすごいスピードで進化しているので、運用まで含めてAIにおまかせできる時代が来る可能性は十分にあります。しかし、そういう時代が来ることと、運用のことを考慮せずに「生成AIがあればオッケー」と安易に考えるのとでは別の話です。自動テストを自分たちが運用しつづける際のプロセスや担当など、組織としての取り組み方や仕組みを十分検討したうえで、それらが生成AIによって実現可能である、と判断できたのであればノーコードツールを使わずに生成AIでいこうとするのは納得できます。自動テストの作成だけを考えて判断するのは危険である、という点はぜひ気にしていただきたいポイントです。 また違った視点として、生成AIはテスト自動化をしたい方だけが使える道具ではありません。テスト自動化ツールを提供する側もまた、生成AIを自社のツールに取り込み、これまで以上にユーザーのためになる機能や新ツールの開発を続けています。テスト自動化ツールが生成AIを活用することで、たとえばノーコードかコードベースかといった軸とは全く違うパラダイムでの自動テストを行うツールに進化をするかもしれません。 このように、大きな変化をもたらすきっかけや手段として、生成AIがノーコードテスト自動化ツールに影響するのではないかと思います。 問い：自動テストについて慎重に考えること 山下さん記事の内容を引用します。 私はテスト自動化が「当たり前の技術」となり、だからこそ慎重に「自動テスト」について考えるような、手動テストの設計時と同様に、冷静な視点が必要だと感じています。この点について、ぜひ見解をお聞きしたいです。 まず、前提となっている テスト自動化が「当たり前の技術」となり の部分について。 この点は、実感としては合っているように思います。各社の求人を見ていても、「QA・テストエンジニア」と「テスト自動化エンジニア・SET」を明確に分けている求人が減ってきており、QA・テストエンジニアの必須もしくは歓迎スキルとしてテスト自動化が扱われることが多くなっているように感じます。（データがないので、体感です。） 一方で「本当にそうだろうか、当たり前になっているんだろうか」と思うこともあります。 そのひとつには、これまた生成AIの普及がある、とみています。 数年前はある種「テスト自動化ブーム」のような時期もあり、日本で一番大きいソフトウェアテスト関連のカンファレンス、JaSST Tokyoのセッションで自動化の話題がいくつも出てきていました。 それが、2026年現在は「生成AIを用いた～」が（大げさに言えば）ほぼすべてのセッションに含まれているくらい、生成AI活用が流行っています。 テスト自動化は、ある意味この生成AIという「次のブーム」に押し出される形で「一昔前の流行り」になっていて、それを「当たり前の技術」になったと捉えている部分があるのではないでしょうか。 たしかに、自動化の技術や考え方は以前と比べると当たり前に近づいています。しかし、当たり前になることと、流行りが落ち着いたこととを一緒にしてはいけません。 ということで、もとの山下さんからのコメントに戻ると、 冷静な視点が必要だと感じています に賛成です。 山下さんの意図した冷静な視点、に沿う回答かどうかはわかりませんが、仮にズレていたとしてもそれもまたこの往復書簡スタイルの面白さ、ということにしましょう。（ちなみに、裏に台本などはなく、事務的なやりとりを除けば本当にこの記事だけでやりとりをしています。） もうひとつ、普段私が考えていることでかつ冷静な視点に当てはまりそうなこととして、テスト自動化のこれまでの常識を改めて考え直す必要がある、という点です。 テスト自動化に関するベストプラクティスやアンチパターンは、書籍や事例発表など先駆者たちの活動で広く皆が知るところになりました。これも当たり前の一部ですね。 しかし、ベストプラクティスやアンチパターンと言われるものには、当然ながら前提があります。 たとえばテストピラミッド。おおざっぱに言えば、単体テストを充実させ、E2Eテストは必要最小限にするのが良い、という考え方です。 この考え方には、単体テストのほうがE2Eテストに比べて実行時間が短く、実行コストが低いという前提があります。ではもし、E2Eテストが単体テストと同じくらい高速・低コストで実行できるなら・・・？ これはあくまでも一例ですし、改めて前提を疑った結果、それでもやはりベストプラクティスだ、という結論になることもあるでしょう。 しかし、テスト自動化が当たり前になったことに加えて生成AIの登場によりさまざまな前提が覆る可能性のある今、テスト自動化を知ったつもりになって当たり前をなぞるのではなくて、きちんと理解したうえで一度問い直す、といった姿勢が求められているのではないでしょうか。 山下さんへのバトン テスト自動化が当たり前の技術になったのかどうか、という点について、山下さんから見た印象もお伺いしてみたいです。ソフトウェアテスト・QA界隈だけでなくプログラミング言語やアジャイル、そして海外も含めた幅広いコミュニティに参加している山下さんの視点での感覚も知りたいです。 また、自動テストについて冷静な視点が必要ではないかという意見は、裏を返すと「冷静でない」、たとえば過剰な期待や、それとは反対に価値を低く見られているなどの状況を目にしたことがあるのかな？と想像しました。 このあたり、具体的に「こんなのを見た・聞いた」があれば（話せる範囲で）聞いてみたいです。 The post 【第2回】E2Eテスト自動化でつなぐ②〜生成AIがテスト自動化に及ぼす影響をどう捉えるか〜 first appeared on Sqripts .

「QAエンジニア」と一口で言っても、その背景や専門性は多岐にわたります。 前回の連載では、自身の経験がブリコラージュのように結びつき、現在の土台となっていることについてお話ししました。 本連載は新たに、「 Connecting the dots 」というテーマを扱います。 本連載では、今まで現場やコミュニティの中で出会ってきた専門家の皆様と、往復書簡のような形で意見を交換していきます。 ひとりひとり独立した専門家という「点」を、技術や関心ごとといった共通点で繋ぎ、連載を形作ります。 本シリーズ最初の話題は「E2Eテスト自動化」を取り扱いたいと思います。 お相手は同じくSqripterの伊藤由貴さんで、2回程度の往復（全5回）を予定しています。 本記事では、私の視点から「E2Eテスト自動化のいまむかし」について振り返りつつ、伊藤さんへバトンを渡したいと思います。 ※これ以降、単に「テスト自動化」と表現するものは「E2Eテスト自動化」を指します。 テスト自動化との出会い 私が「テスト自動化」というものに本格的に触れる機会があったのは2021年ごろです。 第三者検証会社での「テスト自動化トレーニング」という1ヶ月ほどのフルタイムの研修に通った時期でした。 当時の私はターミナルがインターフェースとなる製品にしか携わったことがありませんでした。 テスト自動化の技術が公に議論されているWebの分野については全くの未経験であり、どこか蚊帳の外にいるような感覚がありました。 Seleniumを主として、複数のツールを使ってE2Eテスト実装の体験をしました。 2020年にもJSTQBのワーキンググループからテスト自動化エンジニアのシラバスが翻訳されたこともあり、「テスト自動化」という技術が「特別な経験者が持つスキル」から「勉強すればアクセスできるスキル」という位置付けに変わってきたタイミングだったなと今では思います。 現在隆盛を誇っているPlaywrightを触り始めたのもこのタイミングであり、当時は後発のツールであるPlaywrightがどんな思想で、どんな優位性を持っているかという、初期段階の構想を調べたことがあります。 この体験がきっかけとなって、テスト自動化カンファレンスで発表するアイデアが生まれたことなど、今振り返ると、感慨深いものがあります。 余談：伊藤さんとの不思議なご縁 この連載を始めるときに全く意識していなかったのですが、この研修コースを企画・運営している課の課長が伊藤さんでした。 また、現在私は主に”QAエンジニア”と呼ばれるロール、あるいはテストや品質保証に関する明確な専門家がいない現場を支援することがあります。いわゆる「一人目QA」のような立場で支援を行っています。 当時は（今もですが）雲の上のような存在でしたが、今でもこうして伊藤さんから多くを学びつつ、親しく交流させていただいていることに、不思議なご縁を感じています。 テスト自動化の現在 2026年現在、私がテスト自動化を学んでから5年程度が経ちましたが、特にWeb分野のテストエンジニアのスキルセットとして、その位置づけが大きく変化してきたように感じます。 5年前は「テスト自動化ができる環境をセットアップしてコードが書ける」というだけでも重宝されていた記憶があります。 一方、今ではテスト自動化という分野は採用において前提条件となっていたり、当たり前の技術になっていると強く感じます。 特にPlaywrightについてはプロダクトコードを書くエンジニア、いわゆる”開発者”が詳しく知っているような現場に何度か出会いました。 生成AIによるコード生成 こういったテスト自動化のやりやすさは生成AIの登場により、ますます顕著になったと考えます。 （個人的にはあまり推奨したくない表現ですが）いわゆる「エンジニア経験のないQA」であっても、自然な日本語を使ってテスト自動化フレームワークが動作する環境を作り、開発環境をセットアップし、テストコードを書くことができるようになったためです。 テスト自動化をどう考えるか テスト自動化の成果物、つまりテストコードが簡単に書けるようになって、「何を自動テストにするか」というテスト計画・設計・分析といった知見の必要性が強くなってきたことも感じます。 一見これは生成AIによるプロダクトコードと同様の論点に聞こえます。 しかしながら、テストはプロダクトコードと違い、ユーザーの使われ方や売り上げといった、効果測定や仮説検証がしづらい課題があると考えています。 こうしたテストコード特有の落とし穴は想像以上に根深く、AIを活用してテストコードを生成する際に、その課題の大きさを痛感させられます。 テスト自動化ではなく自動テスト ここで一言言及しておきたい考えがあります。 「テスト自動化ではなく自動テスト」という考え方です。 「テストを自動化する」ではなく「自動化に適したテストを自動テストとして捉え直す」という提言はSqripterでもある末村さんが2020年にすでに言及されています。 私も、本記事では「テスト自動化」という言葉を使っていますが、普段は文脈により「テスト自動化」と「自動テスト」は使い分けるようにしています。 そして、可能な限り後者の表現が適した活動になるよう日々心がけています。 参考： テストを自動化するのをやめ、自動テストを作ろう​​ （Speaker Deck）／Takuya Suemura AIテストツールの現在は？ 生成AIが爆発的に流行する以前にあった、いわゆる「ノーコードテスト自動化ツール」はどうでしょうか。 実のところ、私は過去にノーコードテスト自動化ツールに対して苦手意識を持っていました。 2021年にMagicPodをはじめとしたテスト自動化ツールを触りましたが、率直な感想として「ノーコードよりもコードを書いた方が実装者としていい体験ができる」という感覚を持った覚えがあります。 そうした背景から、ノーコードテスト自動化ツールに関しては自発的に学習する意欲を保つのが難しい時期がありました。 そのため、テスト自動化ツールの知識はテスト自動化実装担当者として手を動かさなくなってから、アップデートされていないのが実情です。 私がツール選定に関わる立場になっても、これらのツールを積極的に採用する機会に恵まれませんでした。 一方で現在では、PlaywrightのCodeGenのように、コードベースのツールでもノーコードツールと同等の機能が簡単に実現できるようになっています。 また、PlaywrightCLIなど、生成AIを効果的に使いながらさまざまな運用が可能になっていますね。 なにより、テストコードの自動修正など、機能レベル（あるいはカタログスペックとして）で同等のことが簡単にできるようになったとも考えます。 伊藤さんへのバトン ぜひ伊藤さんに聞いてみたいことがあります。 私はテスト自動化が「当たり前の技術」となり、だからこそ慎重に「自動テスト」について考えるような、手動テストの設計時と同様に、冷静な視点が必要だと感じています。この点について、ぜひ見解をお聞きしたいです。 そして、生成AIの登場でノーコードのテスト自動化ツールがどのような影響を受けるのか。 現在MagicPodのエヴァンジェリストをされている伊藤さんがこの状況をどう捉えておられるか、ぜひ見解をお聞かせいただきたいです。 The post 【第1回】E2Eテスト自動化でつなぐ①〜E2Eテスト自動化のいまむかし〜 first appeared on Sqripts .