こんにちは、技術広報の yayawowo です。 私たち株式会社ラクス開発本部では、Missionである 「顧客の成長を支援する、圧倒的に使いやすいクラウドサービスを創り提供する」 を念頭に、日々プロダクト開発に励んでいます。 現在、ラクスでは歴史あるロングセラーのプロダクトから、近年立ち上がった新規プロダクトまで、多くの開発プロジェクトが並行して動いています。このように古いものから新しいものまで多くのプロダクト開発に深く携われるからこそ、エンジニアやデザイナーが触れられる技術の機会が非常に多い点が、私たちの組織の大きな特徴であり魅力です。 本記事では、各プロダクトの「技術スタック」を改めて整理し、皆様に最新情報をお届けしたいと思います！自社開発に携わるエンジニア、デザイナーだけでなく、これから携わりたい！という方にも必見の内容です。 現場のリアルな最新データから見えてきたのは、単なるツールの変更履歴ではありません。 ラクスが開発組織として一貫して掲げている「技術選定の思想」そのものでした。 各組織の最新スタックを公開する前に、まずは私たちが大切にしている「2つのコア思想」を技術広報の視点からご紹介します！ 1. ラクスが技術選定で掲げる「2つのコア思想」 ① お客様の日常を守り、進化させるための「顧客志向」 ② 技術を「価値創造」に集中させるための「AIネイティブ＆自動化」 2. 各プロダクトの紹介 ＆ 最新技術スタック 楽楽精算 楽楽明細 楽楽電子保存 楽楽債権管理 楽楽勤怠（給与計算） 楽楽販売 楽楽請求 楽楽自動応対開発 楽楽メールマーケティング blastmail / blastengine 3. それを支える連携部署の技術スタック フロントエンド推進課 SRE AI開発課 ＆ AIエージェント開発課 QA課 インフラ開発部 プロダクトデザイナー 4. 終わりに 1. ラクスが技術選定で掲げる「2つのコア思想」 今回、全社規模で集まった最新のデータを見て、技術広報である私が一番強く感じたのは、ラクスが大切にしている「技術選定のブレない軸」でした。私たちは、単に流行りのツールを追いかけるのではなく、以下の2つの思想をベースに日々の開発環境をアップデートしています。 ① お客様の日常を守り、進化させるための「顧客志向」 ラクスにとって、技術は「自分たちが使いたいから」選ぶものではありません。すべては「お客様の業務をいかに楽にできるか」という目の前の課題を解決するための最高の手段です。 私たちのクラウドサービスは、ありがたいことに数万社を超えるお客様の日常のビジネスを支える社会インフラになっています。だからこそ、長年培った圧倒的な安定基盤を深くリスペクトし、1分1秒のダウンも許されない堅牢性を守り抜く責任があります。しかし、私たちは「守り」だけでは終わりません。お客様へより速く、より安全に新しい価値を届けるために、歴史のあるプロダクトほど「お客様の未来のために、今最適な武器は何か」を貪欲に追求し、裏側では大胆なモダナイズを仕掛けています。 ② 技術を「価値創造」に集中させるための「AIネイティブ＆自動化」 お客様の課題解決に1分1秒でも多くの時間を割くため、ラクスはエンジニアの創造性を奪う泥臭い手作業や無駄な作業を徹底的に排除する環境作りに本気で取り組んでいます。 今回、一際目を引いたのが、各現場の「AIと自動化へのリアルな使い分け」です。単に世間の流行りに乗って同じツールを一律で入れるのではなく、プロダクトの特性に合わせて最適な技術スタックを現場主導で選定しています。そして何より特徴的なのが、ほぼすべての組織が、実装前の「壁打ち相手」としてAIをフル活用している点です。単にツールを入れて楽をするためではなく、エンジニアが本来向き合うべき「顧客のための価値ある設計や、より良いユーザー体験の創造（本質）」に100%集中できる環境を、ラクスは本気で作り上げています。 具体的にどんなツールを、どんな考え方で使い分けているのか？ それは、この後各プロダクトの技術スタックにてご紹介します。 2. 各プロダクトの紹介 ＆ 最新技術スタック ここからは、ラクスが展開する各クラウドサービスと、現場のエンジニアが2026年度現在、実際に選定して使っている技術スタックをご紹介します。 楽楽精算 会社の「経費精算」にかかる時間と労力を劇的に減らすシステムです。利用者はスマホで領収書を撮影するだけで金額や日付が自動入力され、面倒な紙の提出や手入力をすることなく精算を完了できます。経理担当者にとっても、確認や承認の負担を大幅に削減する「日本のバックオフィスを楽にする」代名詞的な存在です。 ✅バックエンド カテゴリ 技術スタック 使用言語 Java、Swift、Kotlin MW PostgreSQL、Postfix、Apache、Room、Realm FW・ライブラリ Spring Boot、jQuery、Retrofit2 開発ツール IntelliJ IDEA、Xcode、Android Studio、Flyway、Redmine、GitHub、VSCode CI・テスト Selenide、Gradle、JUnit、JMeter、Jenkins、GitHub Actions AI Claude Code、Codex、GitHub Copilot、Gemini、ChatGPT、Notebook LM、Cursor ※2026年7月時点での情報です。 ✅フロントエンド カテゴリ 技術スタック 使用言語 HTML、CSS、JavaScript、TypeScript FW・ライブラリ React、jQuery、MUI、Jotai、zod、TanStack Form、Tanstack Query、Sass、Vite、ESLint、Prettier、Biome、Storybook、msw 開発ツール GitHub、GitHub Projects、VSCode、OpenAPI、Figma CI・テスト GitHub Actions、Jenkins、Playwright、Vitest AI Claude Code、Codex、GitHub Copilot、Gemini、ChatGPT、Notebook LM ※2026年7月時点での情報です。 楽楽明細 企業が取引先に発行する「請求書」や「納品書」を、すべてWeb上で一括配信するシステムです。これまでは担当者が印刷し、封筒に詰め、切手を貼って郵送していた手作業をゼロにします。受け取る側の取引先もマイページからいつでも即座に確認・ダウンロードできるため、双方のペーパーレス化と業務スピードアップを同時に実現しています。 カテゴリ 技術スタック 使用言語 Java、TypeScript、JavaScript MW PostgreSQL、Tomcat、Postfix、Docker、Redis、AWS Lambda / EventBridge / Step Functions / S3 / SQS FW・ライブラリ SpringBoot、React、Redux、JasperReports、Lombok、Jooq、jQuery、GraphQL 開発ツール IntelliJ IDEA、VSCode、Redmine、GitHub、gulp.js、webpack、Storybook CI・テスト Gradle、jUnit、Playwright、GitHub Actions AI Claude、Claude Code、GitHub Copilot、ChatGPT、Codex、Notebook LM、Gemini ※2026年7月時点での情報です。 楽楽電子保存 国税関係の書類（領収書や請求書など）を、国が定める「電子帳簿保存法」の厳しい要件に100%準拠して、安全にクラウド保存・一元管理できるシステムです。ユーザーは「法律が変わってどう対応すればいいかわからない…」という不安から解放され、検索機能を使っていつでも過去の書類を1秒で見つけ出せるようになります。 カテゴリ 技術スタック 使用言語 Java、TypeScript、JavaScript MW PostgreSQL、Nginx、Tomcat、Postfix、Docker、Kubernetes、Node.js、AWS Lambda / S3 / DynamoDB / API Gateway / SQS FW・ライブラリ React、MUI、MSW、Spring Boot、Jooq 開発ツール IntelliJ IDEA、GitHub、Vite、VSCode、Open API、Figma、ESLint、Prettier、Yarn CI・テスト Gradle、JUnit、GitHub Runner、Vitest、Cypress、argoCD、Playwright、GitHub Actions AI Claude、Claude Code、GitHub Copilot、ChatGPT、Codex、Notebook LM、Gemini ※2026年7月時点での情報です。 楽楽債権管理 「取引先からちゃんとお金が振り込まれているか」を確認する、企業の経理で最も神経を使う入金消込・債権管理業務をスムーズにするシステムです。銀行の入金データと自社の請求データを自動で照合し、ミスマッチがあればすぐに通知。人の目によるダブルチェックや残高管理のプレッシャーから担当者を解放し、確実な資金管理を支えます。 カテゴリ 技術スタック 使用言語 Java、TypeScript、JavaScript MW PostgreSQL、Tomcat、Postfix、Docker、Redis、AWS S3 FW・ライブラリ React、MUI、Spring Boot、Jooq、DuckDB 開発ツール IntelliJ IDEA、VSCode、Redmine、GitHub、Storybook、Open API、Figma CI・テスト Gradle、jUnit、Playwright、GitHub Actions AI Claude、Claude Code、GitHub Copilot、ChatGPT、Codex、Notebook LM、Gemini ※2026年7月時点での情報です。 楽楽勤怠（給与計算） 従業員の日々の「出退勤」を正しく記録し、労働時間や時間外労働時間を自動で集計、そのまま給与計算システムへとデータをスムーズに連携させるシステムです。シフト管理や有給休暇の消化状況もひと目でわかるため、中小企業から大企業まで、複雑な労務管理をミスなくシンプルに行える環境を作ります。 カテゴリ 技術スタック 使用言語 PHP、Python、JavaScript、TypeScript MW MySQL、Nginx、Docker、Node.js、Gunicorn FW・ライブラリ Flow、Vue.js、Fast API、Pinia / Pinia Colada, Vue Router, Vue I18n, Vite, Tailwind CSS, ESLint, Prettier, Storybook, msw 開発ツール GitHub、GitHub Projects、PhpStorm、IntelliJ IDEA、VSCode、Cursor、OpenAPI、Figma、renovate CI・テスト GitHub Actions、PHPUnit、PHPStan、Selenium、Ansible AI Claude、Claude Code、GitHub Copilot、ChatGPT、Codex、Notebook LM、Gemini、VertexAI ※2026年7月時点での情報です。 楽楽販売 販売管理、顧客管理、案件管理など、自社のやりたい業務に合わせて画面や項目をノーコードで自由自在に構築できるWebデータベースシステムです。Excelで属人化してしまっていた複雑なデータをチーム全員で見える化し、ボタン一つでの帳票発行や、ルーチンワークの自動化によって、会社全体のコア業務を劇的にスピードアップさせます。 カテゴリ 技術スタック 使用言語 PHP、Java MW PostgreSQL、Postfix、Apache、Redis FW・ライブラリ Zend Framework、jQuery 開発ツール VS Code、Cursor、GitHub CI・テスト Selenium/Selenide、PHPUnit、JMeter、Jenkins、PHPStan、Playwright AI Claude Code、Codex、ChatGPT、Devin、Notebook LM ※2026年7月時点での情報です。 楽楽請求 取引先から紙、PDF、メールなど様々な形でバラバラに届く「受領請求書」を、一つの画面でスマートに一元管理するシステムです。高性能なAI-OCRが中身を自動で読み取ってくれるため、手入力の手間が激減。仕訳データや支払処理、データの保存までをワンストップで効率化し、毎月発生する「請求書処理の山」を瞬時に片付けます。 カテゴリ 技術スタック 使用言語 Java, Kotlin、TypeScript MW PostgreSQL、Pure Storage、Redis、nginx、Tomcat、Kubernetes、AWS[SQS、SES、S3] FW・ライブラリ Spring Boot、jOOQ、React、MUI、Storybook 開発ツール IntelliJ IDEA、Flyway、Gradle、detekt、GitHub、OpenAPI、Figma CI・テスト Playwright、Kotest、Vitest、ArgoCD、Grafana AI GitHub Copilot、ChatGPT、Devin、Notebook LM、Claude ※2026年7月時点での情報です。 楽楽自動応対開発 お客様から届く膨大な問い合わせメールやチャットを、チーム全員で一元管理・共有するシステムです。「誰がどのメールに対応しているか」「返信待ちか、対応済か」がリアルタイムに全員に共有されるため、ネットショップやサポート窓口での対応漏れや、二重返信によるクレームを完全に防ぎ、顧客対応の品質を最大化します。 カテゴリ 技術スタック 使用言語 PHP、Node.js、TypeScript MW PostgreSQL、Apache、Postfix、AWS Lambda / S3 / DynamoDB / SQS、Qdrant FW・ライブラリ Laravel、jQuery、CKEditor、Socket.IO、Vue.js、NestJS 開発ツール PhpStorm、Github、VS Code CI・テスト Selenium/Selenide、PHPUnit、Vitest、Biome、Jenkins、GitHub Actions、Ansible AI Claude Code、Codex、GitHub Copilot、 ChatGPT、 Devin、 Notebook LM ※2026年7月時点での情報です。 楽楽メールマーケティング 企業のマーケティングや営業担当者が、顧客へ一斉にメルマガや案内メールを配信し、そこからの成果を最大化するためのシステムです。ただ送るだけでなく、「誰がメールを開いたか」「どのURLをクリックしたか」を直感的に分析可能。見込み客の興味関心を可視化することで、次の商談獲得へのアプローチをシンプルかつ効果的に支えます。 カテゴリ 技術スタック 使用言語 PHP、TypeScript MW PostgreSQL、Postfix、Nginx、Apache、Redis FW・ライブラリ Slim、jQuery、Vue.js 開発ツール PhpStorm、GitHub、Docker、Podman CI・テスト Playwright、Puppeteer、Jenkins、JMeter、PHPUnit、PHPStan、PHP_CodeSniffer、PHPDoc、Ansible、vegeta AI Claude Code、Codex、GitHub Copilot、ChatGPT、Devin、Notebook LM ※2026年7月時点での情報です。 blastmail / blastengine 「blastmail」は数百万通ものメールを顧客へ一瞬で確実に届ける独自の配信システム、「blastengine」はエンジニアが自社のシステムやアプリに組み込んで、通知メールなどを超高速で自動配信させるためのAPI・リレーサービスです。どちらも「遅延なく、迷惑メールに振り分けられることなく、確実に届ける」という配信技術の極限を支えています。 カテゴリ 技術スタック 使用言語 Java、TypeScript、Go、Python MW Docker、PostgreSQL、MongoDB、Postfix、RabbitMQ、AWS[EC2、ECS、RDS、S3、Lambda、SQS] FW・ライブラリ SpringBoot、React、Quarkus 開発ツール VSCode、GitLab、Redmine、Gradle、OpenAPI、Figma、StoryBook CI・テスト GitLab CI/CD、JUnit、Vitest、Biome、Playwright AI Claude Code、Codex、GitHub Copilot、Gemini、ChatGPT、Notebook LM ※2026年7月時点での情報です。 3. それを支える連携部署の技術スタック ラクスには、各プロダクトの提供価値を最大化し、開発組織全体のエンジニアリング水準を横断的に引き上げる連携・専門組織が存在します。実務で選定している先進的な「武器」をご紹介します。 フロントエンド推進課 フロントエンド推進課は、ラクスの各サービス開発チームと協力し、フロントエンド領域からプロダクトの成長と品質向上を支える専門組織です。 新機能開発や既存機能のUI/UX改善に加え、技術的負債の解消、リアーキテクト、パフォーマンス改善、デザインシステム構築、共通UIコンポーネント開発など、サービス単体では対応しきれない横断的なテーマにも取り組んでいます。 各プロダクトの事業フェーズや技術課題を踏まえ、開発現場に入り込みながら、ユーザーにとって使いやすく、開発者にとって継続的に改善しやすいフロントエンドを実現していくことが役割です。 技術を目的化するのではなく、ユーザー価値、開発生産性、品質、保守性を高めるためにどう活用するかを重視し、プロダクトとチームの両面からラクスのサービス成長に貢献しています。 カテゴリ 技術スタック 使用言語 HTML、CSS、JavaScript、TypeScript FW・ライブラリ React, TypeScript, MUI, RHF, zod, Tanstack Router, Tanstack Query, zustand, emotion, Vue.js, Pinia / Pinia Colada, Vue Router, Vue I18n, Vite, Tailwind CSS, ESLint, Prettier, Storybook, msw 開発ツール GitHub, Github Projects, VSCode, OpenAPI, Figma, renovate CI・テスト GitHub Actions, Playwright, Vitest, happy-dom AI Claude Code, Codex, Copilot, ChatGPT, Gemini, Notebook LM ※2026年7月時点での情報です。 SRE ラクスにおけるSREでは、開発とインフラの知見を活かして顧客への価値提供スピード向上に寄与する自動化・標準化（生産性向上のための取り組み）を推進する役割を担います。 開発とインフラを繋ぐHubというビジョンを持ちながら、システムのモダナイズ化や基盤の構築を行う役割です。 開発言語は主にGoを利用し、横断的なトイル削減や運用の自動化を推進しています。 新しい技術スタック調査などを進めながらノウハウを各サービスへ広めることで、開発部門全体のアーキテクチャ刷新へ寄与していきます。 カテゴリ 技術スタック 使用言語 Go 仮想基盤 Kubernetes MW PostgreSQL, Amazon Aurora, Redis, Kafka FW・ライブラリ gRPC CI/CD・IaC GitHub Actions, ArgoCD, Argo Workflows, Argo Event, Hashicorp Vault, Terraform, Helm 運用・監視 Grafana Stack AI Claude Code, Codex, GitHub Copilot, ChatGPT, Devin, Notebook LM ※2026年7月時点での情報です。 AI開発課 ＆ AIエージェント開発課 ラクスが提供する各プロダクトへ実用的なAI機能を組み込むための研究開発や、社内の複数プロジェクトを横断して業務を自動化する「AIエージェント」の実装・導入を牽引する最先端チームです。 ✅AI開発課 カテゴリ 技術スタック 使用言語 Python MW PostgreSQL、Redis、DynamoDB、Docker、Kubernetes FW・ライブラリ PyTorch、Keras、TensorFlow、FastAPI、OpenAI API、AWS Bedrock、Vertex AI 開発ツール GitHub CI・テスト GitHub Actions、pytest、Terraform AI（開発支援） Claude Code、GitHub Copilot、ChatGPT、Notebook LM、Cursor (OpenSpec) ※2026年7月時点での情報です。 ✅AIエージェント開発課 カテゴリ 技術スタック 使用言語 Java, TypeScript, Python MW amazon corretto, tomcat, postgres, Kubernetes, AWS[Lambda, SQS, SNS, Bedrock, EKS, CloudWatch, DynamoDB, S3, KMS], ArgoCD, Grafana, Litellm, flipt, Otel-collector FW・ライブラリ Spring Boot, Mastra, Hono 開発ツール Gradle, Github, Zed, Visual Studio Code, pnpm, mise CI・テスト junit, vitest, testcontainer, Github Actions AI（開発支援） Claude Code, Codex, Github Copilot Agent, Devin ※2026年7月時点での情報です。 QA課 各プロダクトに準ずる開発環境や仕様を深く理解し、お客様に届くクラウドサービスの品質を「テスト・保証」の側面からハックする品質専門組織です。 カテゴリ 技術スタック 使用言語・MW 各プロダクトに準ずる 開発ツール・FW 各プロダクトに準ずる CI・テスト Playwright、Jenkins 他、各プロダクトに準ずる AI Claude Code、ChatGPT、Gemini、Notebook LM ※2026年7月時点での情報です。 インフラ開発部 8割のサービスリソースをオンプレミスで構築しております。 オンプレミス環境でも自動化などなるべくソフトウェア視点のアプローチが出来るようにHCIで基盤構築し運用効率化をしています。 今後のアップデートとしては、クラウドで先行構築したクラウドネイティブなコンテナ環境やCI/CD環境などをオンプレミス環境にフィードバックし、自動化、自立化を推進しつつもコスト優位性を出せるシステムを構築していきます。 カテゴリ 技術スタック 使用言語 Python、Bash プラットフォーム On-Premise、AWS「EC2、ECS、EKS、RDS、S3、Lambda・・・etc」、GCP ネットワーク Cisco、Dell、Paloalto、F5 OS・仮想化 LinuxOS、VMware、Nutanix、Docker、K8S MW PostgreSQL、Apache、Tomcat、Nginx、PaceMaker、etc... IaC Ansible、Terraform その他ツール Git、Rundeck 運用・監視 Zabbix、Grafana、Prometheus、ArgoCD AI GitHub Copilot、ChatGPT、Devin、Claude、Gemini ※2026年7月時点での情報です。 プロダクトデザイナー フロントオフィス・バックオフィスの業務システムにおける管理画面のUI/UX設計を担当しています。 業務ドメインの理解を深め、ユーザーの声を直接収集しながら課題を把握し、複雑な業務をUI/UXの力でシンプルに解決することを目指している組織です。 また、AI活用による設計業務の効率化、サービス横断での一貫した体験を実現するデザインガイドラインの策定、さらにデザイン組織としての勉強会やナレッジ共有にも取り組んでいます。 カテゴリ 技術スタック デザインツール Figma コミュニケーションツール Slack、Zoom、Google Meet、FigJam AI（業務支援） GitHub Copilot、Claude Code、Cursor、ChatGPT、Notebook LM、Gemini ※2026年7月時点での情報です。 4. 終わりに 最新の技術スタック、あなたの得意な技術や、挑戦してみたい武器はどこかに見つかりましたでしょうか？ ラクスがこれほどまでに技術スタックをオープンにし、長年愛されている歴史あるプロダクトであっても現状に甘んじず変化を続けさせているのには、明確な理由があります。それは、私たちのミッションが「ITサービスで企業の成長を継続的に支援」することだからです。 技術はあくまで、誰かの課題を解決するための素晴らしい手段です。しかし、最高の手段をエンジニアが持たなければ、お客様に最高の価値を届けることはできません。 だからこそ私たちは、これまで培ってきた圧倒的な安定基盤を深くリスペクトしつつも、時代に合わせたインフラの進化や、AIを活用した開発体制へのアップデート、品質を支える仕組みづくりに注力しています。 「自分が今まで培ってきたスキルを、このクラウドサービスで活かしてみたい」 日々進化する技術を積極的に取り入れ、自社プロダクトの未来を共に創り上げていきたい。 そう少しでも感じていただけたなら、その力をぜひラクスで発揮してみませんか。 最後までお読みいただき、ありがとうございました。

こんにちは！みなさん、テストしてますか？ 第2回の前編 では、E2Eテストの基幹部分とも言える 要素探索 の技術の変遷について扱い、 中編 では 実装 の技術の変遷について扱いました。 後編では、どのようにブラウザを介してWebアプリケーションを自動操作するのか、つまり 自動操作技術 について触れたいと思います。また、UIを自動操作して実施するテストという点から、E2Eテストには良くも悪くも様々な目的が期待されてしまっていましたが、これらはWebアプリケーション開発技術の変遷と共に徐々に変わってきました。こうした E2Eテストの目的 についても触れたいと思います。 記事一覧：モダンなE2Eテストの考え方をマスターしよう 【第1回・前編】まずはやってみよう – Playwrightを使ったハンズオン（事前準備編） 【第1回・後編】まずはやってみよう – Playwrightを使ったハンズオン（テスト自動化編） 【第2回・前編】E2Eテストの歴史 -要素探索技術の変遷- 【第2回・中編】E2Eテストの歴史 -様々な実装技術- 【第2回・後編】E2Eテストの歴史 -自動操作技術と目的の変遷 自動操作技術の変遷 さて、この連載では一貫してPlaywrightを使っています。PlaywrightはいわゆるE2Eテストフレームワークですが、大きく分けると「Webブラウザを自動操作するコンポーネント」と「自動テストを記述するコンポーネント」で成り立っています。 このうち、「自動操作」のほうには様々な変遷がありました。あまりに古いものは自分も良く知らない部分が多いので、おおむね2016年以降の主要なマイルストーンについて記載します。 Selenium 3 と Webdriver CDP（Chrome DevTools Protocol）とヘッドレスChromeを用いた自動テストの流行 開発者体験を重視したツールの流行 Selenium 3 と Webdriver Seleniumは、2025年現在で利用できるものの中では、もっとも歴史の長いブラウザ自動操作ライブラリです。複数のブラウザを統一されたAPIで自動操作できる、というのが強みで、たくさんのテストケースをたくさんのブラウザインスタンス上で実行するためのインフラも用意しています。 クロスブラウザの複雑性をライブラリ側で吸収するというアイディアと、ブラウザとSelenium Serverの中継ぎをするWebDriver部分は仕様を公開して各ブラウザベンダーに実装を任せるという思想そのものは良かったのですが、自動テストインフラの複雑さを招くことにもつながり、インフラの構築やメンテナンス、テスト実行時のトラブルシューティングなどの別の辛さを招いてしまうことも多かったです。 加えて、Selenium WebDriverの（少なくとも当時の）設計思想は「UI上で実際にユーザーが可能なインタラクションを模倣する」というものだったため、テストのためのモック/スタブを作りにくかったり、ネットワークスロットリングなどで特殊な環境を再現した上でのテストが難しいという弱点もありました。 また、仕組み上全てがHTTPベースのコミュニケーションになってしまう点もパフォーマンス上問題になるケースが多く、特にページロードや要素の表示待ちなどが非常に長くなるケースがありました。当時E2Eテストに「不安定」「遅い」という印象を持っていた人たちは、おそらくこれらに苦しめられたいたことでしょう。 一方で、色々と問題はありつつも、自動テストのための大統一APIを作るというビッグピクチャーに向けて今もなお前進し続けているプロジェクトであることは疑いの余地はなく、自動テストエンジニアとして生きるならぜひ動向を追い続けたいプロジェクトの一つです。 ちなみに、HTTPベースの単方向通信しか出来なかったのを改善するために、新しくWebDriver BiDiという仕様が策定されています。こちらについては後述します。 CDP（Chrome DevTools Protocol）とヘッドレスChromeを用いた自動テストの流行 ChromeがHeadlessモードをサポートしたことと、CDP（Chrome DevTools Protocol）をテストに使うことでSeleniumの弱点をカバーできると考えて、CDPをベースにしたハイレベルAPIを実装したのがPuppeteerです。当初はCDPを使っていたのですが、現在は後述するWebDriver BiDiを用いています。 Seleniumがあくまでユーザーに出来る操作のみにフォーカスしていたのに対し（参考： Selenium使いのためのPuppeteer解説｜Qiita ）、PuppeteerはCDPを用いるためネットワーク速度のスロットリングやスタブなど様々な開発者向け機能に対応しており、テストしやすさを改善していました。 一方で、Seleniumユーザーたちの多くがJavaやPythonなどでテストコードを書いていたのに対して、PuppeteerはJavaScriptのみの対応でした。これは普段UIを扱うフロントエンドエンジニアたちには自然だった一方で、JavaScriptの非同期APIに慣れ親しむ前の自動テストエンジニアたちにとってはかなり悩みのタネで、筆者も「自動テストスクリプトが順番通りに動いてくれない……おれはただテストを自動化したいだけなのに……」と毎日悪戦苦闘していたのを覚えています。 ちなみに、パフォーマンスの点について公平のために補足しておくと、Chrome/Chromiumブラウザの自動操作を担うWebDriver実装であるChromeDriverもまたCDPベースで実装されています。ですが、やはりWebDriver自体の通信がHTTP通信であることによるオーバーヘッド自体が大きかったため、速度の面でPuppeteerの方が有利でした。 また、SeleniumとPuppeteerの大きな違いとして、Selenium Gridのような大規模テストインフラを構築する機能の有無がありました。これは大量の実機テスト実行環境を束ねる目的では重要なのですが、CI/CD環境の中でChromiumをインストールしてテストを回すようなケースではそもそも不要なものでもありました。 開発者体験を重視したツールの流行 Cypress さて、Puppeteerの登場で、あくまで筆者の肌感ではあるものの、自動テスト界隈の人気は二分された印象がありました。 テストコードが書けるたくさんのテストエンジニアを中心にたくさんの自動テストを実行したい→Selenium 開発者が日常の開発サイクルの中でガンガンE2Eテストを回していきたい→Puppeteer そうすると、開発者はどうしても 開発者体験 の良さに目が行ってしまいます。例えば、ドキュメントが豊富であるとか、コードが書きやすいとか、デバッグ用のツールキットが充実しているとか、普段の開発エコシステムの中に組み込みやすいとか、そういった具合です。 そんな中で登場したのがCypressです。Cypressははフロントエンドの開発体験をウリにしたツールで、当時の開発者たちが慣れ親しんでいたjQueryのメソッドチェーンを踏襲した書きやすいAPI、フロントエンドエコシステムとの親和性、デバッグ体験の良さなど、良いところがたくさんありました。 一方で、仕組み上複数タブ・ウィンドウの切り替えが出来ないことや、クロスドメインiframeがテストできないことなどは、テスト対象のウェブサイトによっては致命的でした。ちなみに、Cypressのドキュメントは本当に徹底していて、これらのトレードオフまでつまびらかに解説されています。 Cypress docs： https://docs.cypress.io/app/references/trade-offs こうした課題はありつつも、上述した開発者体験の良さ、ならびにこうしたトレードオフまで充分に解説されたドキュメントなどは非常に開発者フレンドリーで、多くの開発者たちに親しまれていました（余談ですが、筆者はあるオンラインカンファレンスでCypressの中の人が「ドキュメントが充実しているのもCypressのいいところで、困ったことがあったらCommand+Kで一発で検索できる」と誇らしげに語っているのを見て、とても良いことだなと感心した覚えがあります）。 Playwright さて、Cypressのメジャーリリースとほぼ同時期に、本連載でも使っている Playwright がα版として産声を挙げました。自動操作の方法としてはPuppeteerが使っているCDPというものになるのですが、この方法は名前の通りChromium系のブラウザ（Chrome、Chromium、Edge）でしか使えないので、FireFoxやSafariはテスト用にビルドしたものを使っています。 個人的には非常にバランスの取れた、良い意味でいいとこ取りのツールだと捉えています。開発者体験の観点からCypressと人気を二分していましたが、その後Cypressと似た機能を取り入れることでより強力なツールになりました。 余談: Selenium4・Webdriver-BiDi 冒頭で紹介したSeleniumですが、何となくオワコンのように見えてしまいがちですが、きちんとメンテナンスされ続けており、2022年には待望の新メジャーバージョンが登場しました。本記事のPuppeteerの項目で「PuppeteerはCDPを直接触れるのでテストが楽」というようなことを書きましたが、Selenium4は待望の cdp エンドポイントが実装され、ブラウザによりますがCDPによる豊富なデバッグ機能にアクセスできるようになりました。 また、Seleniumの根幹となるWebdriver規格も進化しており、新たにWebdriver-BiDiというものが提案されています。BiDiはBiDirectional、つまり双方向の略です。SeleniumがHTTPベースの単方向通信のみのツールだったのを、Webdriver-BiDiはWebsocketベースの双方向通信のものに変えています。これにより、ページの表示待ちなどのパフォーマンスが改善しました。 Puppeteerの話の中で触れたとおり、現在PuppeteerはCDPベースからWebdriver-BiDiベースに変わっています。これがより進んでいくと、クロスブラウザテストのやりやすさはより高くなっていくはずです。 目的/役割の変遷 さて、この「E2Eテストの歴史」は、主にE2E自動テストで使われる技術の変化にスポットを当てることで、「本/記事によって書いてあることが全然違う」という状態を解きほぐすことを目的にしていました。締めくくりとして、これらの技術が何に対して使われるのかの変遷についても理解しておきましょう。 手続き的UIの時代: UIテスト = E2Eテスト JavaScriptによるインタラクティブな表現が可能になった直後のWebアプリケーションは、UIの変化をDOMツリーの操作によって行っていました。例えば、以下のサンプルは簡単なToDoアプリの実装です。ページ全体を読み込み直すことなく、ToDoアイテムの追加/削除のタイミングでデータをバックエンドサーバーに送信しています。 <div id="todoApp"> <input type="text" id="todoInput" placeholder="新しいタスク"> <button onclick="addTodo()">追加</button> <ul id="todos"></ul> </div> <script> function addTodo() { const text = $('#todoInput').val(); if (text) { // バックエンドにPOST送信 $.post('/api/todos', {text: text}, function(todo) { // 成功時にDOMに要素を追加 $('#todos').append(`<li data-id="${todo.id}">${todo.text} <button onclick="deleteTodo(${todo.id})">削除</button></li>`); $('#todoInput').val(''); }); } } function deleteTodo(id) { // バックエンドにDELETE送信 $.ajax({ url: `/api/todos/${id}`, method: 'DELETE', success: function() { // 成功時にDOM要素を削除 $(`li[data-id="${id}"]`).remove(); } }); } </script> DOMツリーを直接編集するということは、状態を再現させるためにはそこまでの手続きを再現させなければいけないということでもありました。再現させるためにはバックエンドも（データベースなども含め）完全なものを準備する必要があるため、必然的にUIテスト=E2Eテストという構図が生まれていました。 宣言的UIの時代: UIテストとE2Eテストの分離 一方、Reactに代表される宣言的UIフレームワークは、「状態を引数として受け取り、UIを返却する」関数としてUIを定義しています。同じToDoアプリをReactで書くと以下のようになります。 function TodoApp() { const [todos, setTodos] = useState([]); const [inputText, setInputText] = useState(''); const addTodo = async () => { if (inputText) { const response = await fetch('/api/todos', { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({text: inputText}) }); const newTodo = await response.json(); setTodos([...todos, newTodo]); setInputText(''); } }; const deleteTodo = async (id) => { await fetch(`/api/todos/${id}`, {method: 'DELETE'}); setTodos(todos.filter(todo => todo.id !== id)); }; return ( <div> <input value={inputText} onChange={e => setInputText(e.target.value)} placeholder="新しいタスク" /> <button onClick={addTodo}>追加</button> <ul> {todos.map(todo => ( <li key={todo.id}> {todo.text} <button onClick={() => deleteTodo(todo.id)}>削除</button> </li> ))} </ul> </div> ); } これにより、状態を再現させるための手続きを踏まなくても、特定の状態をテストできるようになります。 また、特徴的なのがUIをいくつかのコンポーネントのまとまりとして構成しており、各コンポーネントを分けてテストすることも可能である点です。子コンポーネントたちも親と同様に状態を受け取る関数として定義されているので、コンポーネントごとに状態を変えられるようになりました。 同時に、WebフロントエンドのビルドはバックエンドのWebアプリケーションフレームワークと別のフレームワークが担当することも増え、フロントエンドUIのみを分離してテストする傾向が増えてきました。その結果、純粋にUIの挙動だけをテストしたい場合はUIコンポーネントテストで済ませ、バックエンドとの統合における不具合の検知やCUJ（クリティカルユーザージャーニー: もっとも重要なユーザー導線）をE2Eテストで守る、という考え方が広まってきました。 まとめ この後編では、自動操作技術の変遷と、E2Eテストの目的の変遷について、流れを追う形でまとめてみました。 第2回はこれで終わりです。続く第3回では、E2Eテストが他のテストレベルとどう違うのか、どのような目的で行われるのか、どのように使い分けるべきなのか、などについて深堀りしていきたいと思います。 【連載】モダンなE2Eテストの考え方をマスターしよう 【第1回・前編】まずはやってみよう – Playwrightを使ったハンズオン（事前準備編） 【第1回・後編】まずはやってみよう – Playwrightを使ったハンズオン（テスト自動化編） 【第2回・前編】E2Eテストの歴史 -要素探索技術の変遷- 【第2回・中編】E2Eテストの歴史 -様々な実装技術- 【第2回・後編】E2Eテストの歴史 -自動操作技術と目的の変遷 The post 【第2回・後編】E2Eテストの歴史 – 自動操作技術と目的の変遷 first appeared on Sqripts .

GENIEEの技術進化の軌跡：オープンソースから最新技術スタックまで こんにちは、GENIEE歴14年目の経営情報システム開発部部長をしていますYinoueです。（今は人事部で採用も兼務しています）。GENIEEはこの春16期目に入り、提供しているプロダクトは20を超えました。今回は、そんなGENIEEの技術の遷移についてお話しします。GENIEEは、広告技術とマーケティング技術の両方で多くの進化を遂げてきました。その過程でどのような技術選定が行われ、どのようにシステムが進化してきたのかを詳しく見ていきましょう。 初期のLAMP環境とオープンソースSSP GENIEEの初期段階で