はじめに
「このコードどう書けばいいんだろう…」
QAエンジニアとして長年働く中で、私はこの壁に何度も直面してきました。
私は、QAエンジニアのコーディングスキルは「必須」ではなく「あれば業務の助けになる」というNice to haveなスキルとして捉えていました。
しかし、私の経験では、リグレッションテストを自動化するという文脈においてはQAエンジニアやSET（Software Engineer in Test）エンジニアが中心となってE2Eテストのシステム構築、テスト作成、メンテナンスを行う場合が多くありました。
ところが、E2Eテストのシステムを適切に運用し、メンバーに広めていくにはメンテナンス性を意識したコーディングスキルが必要とされ、なかなかハードルが高いものとなっていました。
そんな私の仕事の可能性を広げてくれたのが、AI支援コードエディタ「Cursor」でした。
もし、この記事を読んでくれているあなたがコーディング技術で悩んでいて「どうにかしたい！」と思っているなら「Cursor」といったAIのチカラを借りて次のステップに進む時がきました。
筆者の背景
Ubie（ユビー）株式会社でQAエンジニアとして働いている「やまちゃん」です。QAエンジニアとして足掛け20年くらいキャリアがあり、Ubieでは在籍6年目に突入しています。主にtoBプロダクトの「メディカルナビ」の品質保証業務を担当しています。
得意なことは探索的テストとデータベース/SQLを活用したデータ検証テストです。
コードの読み書きは開発エンジニアの初歩レベルで、既存のE2Eテストへのテスト追加やメンテナンスはある程度できます。しかし、E2Eテストのシステム構築やCI/CDへの組み込みといったSETエンジニアが担当するような専門領域には及びません。
私とCursorとの出会い
Cursorとは
Cursorは、生成AIが組み込まれたコーディング支援機能が豊富なテキストエディタです。コードの生成・編集・理解を効率化して開発者の生産性を向上させてくれます。
Cursor: https://www.cursor.com/ja
また、開発者と書きましたがコンテキストを理解した文章生成もできるので利用者は開発者に限りません。
「ChatGPTなどの他のAIチャットとどう違うの？」と思うかもしれませんが、通常のAIチャットだと入力（プロンプト）に対しての結果だけを返すだけですが、Cursorでは以下のような違いがあります。
- 課題の内容を対話形式で深掘りし、提案を取捨選択しながら解決に導いてくれる
- メンション機能でファイルやフォルダーを指定することで提案の精度を向上させることができる
- ワークスペースに読み込んだフォルダー内（リポジトリ）を横断的に検索し、コンテキスト(※1)を理解する
- MCP Server機能で他のサービスの情報からコンテキストを理解する（MCP Serverについては割愛）
※1：コンテキストとは
どんな指示（プロンプト）であるかも重要なのですが、情報（コンテキスト）が不足していると「思っていたのと違う」「やって欲しいことと違う」といった結果になりがちです。そのため、Cursorには使用者の持つ情報（コンテキスト）を正確かつ適切な量で与えることが重要であり、それが上手くできると精度の高い成果物の生成につながります。
Cursorとの出会い
Ubieでは生成AIを業務に活用して生産性を上げることを必須としています。推奨ではなく必須です。
それを後押しするために社内で勉強会を開いたり、事例やツールの紹介が行われたり、有用なツールのトライアル参加メンバーを募ったりと活発に生成AIに関する活動が行われています。また、生成AIによる急激な技術革新にすぐに対応できる社内の仕組みも同時に進化しています。
Cursorは、私が一言で説明するなら「開発者がAIと対話しながら、提案される内容（コードなど）を取捨選択して目的を達成する」ツールです。
そんな中で私が出会ったのが「Cursor」というツールです。
正直「すごいツールが出てきた」と感じました。
何がすごいかと言うと簡単に表現するなら「開発において自分の持つ知識やスキル以上のことを実現可能にしてくれる」ツールです。
私がCursorを「すごい」と感じて一気にのめり込んで使用したことはCursorを使ってAIとの対話を行うと消費するトークン数が表しています。
当初、私はCursorのBusinessプランのトライアルに参加したものの「時間がない」という言い訳で積極的に使っていませんでした。
【AI活用推進者からの「励まし」】
ところが、一度本気で使い始めるとその可能性に圧倒され、わずか20日後には社内で「ガンガン試すキング」の称号を獲得するほどのヘビーユーザーに変貌していました。
【使用量トップの称号獲得】
何がこの劇的な変化をもたらしたのか？その魅力と可能性についてご紹介します。
私のエンジニアとしての技術面の願望
「もっと開発スキルがあったら」「コードをもっと上手に書けたら」もっといろんなことができたのに...
QAエンジニアを続けていく中で私はこのようなことを何度も考えたことがあります。
具体的には、E2Eテストシステムを自在に構築し、保守性の高いライブラリを作り、CI/CDに組み込んでテストを効率よく実行する...そんなスキルをサクッと身につけたいと思ったことはありませんか？
私はそんな「できるエンジニア」の自分を想像してきました。
それに対して「勉強すればいいのでは？」という意見もあるでしょう。しかし、業務中や可処分時間を使って勉強するのは難しい場合もありますし、闇雲に勉強しても必要な知識が欲しいタイミングまでに身につくとは限りません。
では、デキる自分になるのはいつなのか、3年？5年後？…ちょっと気の遠くなる話ですし、実現する保証もありません。
しかし、前述のCursorを使うと「そんなことを考える前にやってみればいいじゃないか」という選択肢が目の前に現れます。
Cursorに課題を相談し、提案された内容を選択するだけで内容の是非はともかく（※）課題の解決というゴールに着実に近づくことが出来ます。
※ 「内容の是非はともかく」の補足：適切なアーキテクチャーを選び、ベストプラクティスに沿った、品質が高く保守のしやすいものが作れるといったことは指示者の能力や相談内容（プロンプト）が影響することがあるのでそこを磨く必要がある
私がCursorを使ってやってみたこと
ここではCursorを使って作ったものをいくつか紹介します。Cursorの使い方や詳細なコードはここでは示さずに前述した「そんなことを考える前にやってみればいいじゃん」をやってみた結果としてこのようなものがあるということをお伝えできればと思います。
事例1：E2Eテストの実行時間を短くしたい
- 背景
- 待ち時間は可能な限り短い方がいい
- 適切な並列数が分かっていない
- 前提
- Cypressを使ったE2Eテストがある
- シナリオテストは35個
- CIはGitHub ActionsのWorkflowで実行している
- 現在は3並列実行でトータル約11分かかっている
- Cypress Cloud は利用していない
- 期待値
- 適切な並列数で実行してトータル時間の短縮ができていること
シナリオ数から4〜5並列が適切だとCursorから提案されたため、5並列で実装した結果、実行時間が約11分から約7〜8分まで短縮されました。この実装において、私は一行もコードを書いていません。
この経験から得た教訓は、AIに指示する際の適切な範囲設定の重要性です。「テスト実行時間を計測し、動的に最適な並列実行を割り当てる」という高度な要求をしたところ、自分の理解を超える複雑なシステムが生成され、結局は活用できませんでした。
AIの力を借りる際も、自分の理解が及ぶ範囲で進めることが重要だと学びました。
▼テスト並列実行時のフローチャートをMermaid形式で記載（Cursorに書いてもらった）
事例2：E2Eテストの開始をSlackで通知したい
- 背景
- E2Eテストの開始と終了時に実行者にメンションが行われず、いつ実行が終わったのか分からない
- Slack通知が並列実行ごとに行いたいので通知先のチャンネルがすぐに通知で埋まってしまっていた
- 前提
- 既にライブラリを使ったSlack通知が実装されていたがスレッド内投稿やメンション機能がなかった
- CIはGitHub ActionsのWorkflowで実行している
- 期待値
- E2Eテストの開始をSlackで通知し、開始と同一スレッドで終了通知したい
- Workflowの実行者とSlackユーザーを紐づけて通知したい
実行時にSlackの通知先を選べるようになり、意図した通りの通知が行えるようになりました。この実装でも、私は一行もコードを書いていません。
この時の反省点としては、スレッド通知がうまくいかなかった既存のライブラリを諦め、Slack APIを直接呼び出す方針にしたものの、ローカルでのデバッグ環境がなかったため、何度もデプロイしてWorkflowを動かしながら確認する必要があり、デバッグに時間がかかったことです。
経験のある開発者ならもっと手際良くデバッグできたのだと思います。
▼Workflow実行ダイアログ
▼Slackの通知（Yama-chan = 筆者）
事例3：Cypressを採用しているリポジトリにPlaywrightを相乗りさせたい
- 背景
- Ubie社内ではE2Eテストの技術スタックを統一した方がいいのではという声が挙がっていた
- ブラウザーエンジンのWebKitを使ったテストをサポートしたかった（Cypressではサポートされていない）
- できるだけリポジトリを分散させたくなかった
- 前提
- Cypressを使ったE2Eテストがある
- 期待値
- Cypressの環境やテストを壊さずにPlaywrightが導入できること
「どうやってやるんだろう」と深く考える前に、CypressとPlaywrightをあっさりと共存させることができました。
▼これはプルリクエストの要約でCypressに全く干渉せずに追加している様子です
▼ package.jsonのscriptsの設定で、Playwright用の実行コマンドをCypressに干渉しないように追加しているところ
なお、この課題の続きがあり、Cypress用に作ったテストを徐々にPlaywrightへコンバートしていこうと思っています。
このコンバート作業はかなり重い作業になり、工数も多くかかると見積もっていましたが、Cursorのコーディング支援能力を目の当たりにするとスコープを決めてステップを適切に刻めば可能なのではという気になっています。
まとめ
「Cursorをつかってやったこと」の事例は私がCursorを使って実現したことの一部です。
都合上、コードをそのまま掲載できないため、その凄さが十分に伝わったか分かりませんが、長年QAエンジニアとして手動テストの実行を得意としてきた私にとって、AIとの簡単なやり取りで必要なコードが瞬時に生成され、やりたいことが実現できてしまう様子は衝撃的でした。
まだCursorを使いこなしているとは言い難く、雰囲気で使っているレベルであってもその衝撃具合です。
例えばですが、E2Eテストのテストをたくさん作ればメンテナンスは大変で、実行時間は長くなるのが通説です。そのメンテナンスの部分をAIに任せられるようになれば、気軽にテストを追加したり減らしたりといった実行時間の増減を天秤に掛けながら攻めた活動ができるようになるかもしれません。
また、AIを使いこなすことで、自身の知識やスキルを超えた挑戦が可能になり、エンジニアが持つべきHow（手段）＝武器を増やすことができると考えています。
一方で、この急速なAI革命の波に乗り遅れると、AIを巧みに活用する同僚や競合との間に、技術面だけでなく生産性においても大きな差が生まれることは避けられません。今こそAIを味方につける絶好のタイミングです。
Ubie社内で生成AI活用の啓蒙活動や環境整備を行ってくれるメンバーやチームには、とても感謝しています。
生成AIを全社的に活用し、テクノロジーの最前線で活躍するUbie社に興味をお持ちいただけましたか？
あなたも最新AI技術を武器に、QAエンジニアとして新たな可能性に挑戦してみませんか？
カジュアル面談では、Ubieの社会貢献と強い繋がりのある事業内容、先進的なAI活用事例、そしてQAエンジニアの具体的な成長機会についてお話しします。ぜひお気軽にご応募ください。
UbieのQAエンジニア職・活動紹介記事
Ubieの生成AI関連記事
Discussion