前回の山下さんからバトンを受け取りました、伊藤由貴です。 「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 .

はじめに さくらのナレッジ編集部の法林です。 ある日、さくナレ編集部に読者からのお便りが届きました。そこには、「高齢者の家族が子どもや孫たちとビデオで会話する仕組みを、さくらインターネットのサーバを使って作りました。せっ […]

はじめまして、こんにちは。tofu屋にジョブチェンジした、いなみです。 今回はtofuのことを書いてみようと思います。皆さんtofuお好きですよね? OpenTofu とは? 移行ガイド 前提条件 今回やること 各バージョン 検証 事前作業として、バックアップ取得 OpenTofu インストール Atlantis Server の設定変更 テスト 変更点 感想 OpenTofu とは? OpenTofuはTerraformのオープンソースフォークです。 2023年8月にHashiCorpがTerraformのライセンスをオープンソース（MPL 2.0）から商用ライセンス（BSL 1.1）に変更…