QAがCursorの力を借りてソースコードを読んでみた

この記事は、CYBOZU SUMMER BLOG FES '25 の記事です。

こんにちは。この記事では巷で噂のCursorについて、QAエンジニアの視点からつらつら語ってみようと思います。

「Cursorに興味はあるが、最初の一歩を踏み出せていない」というQAエンジニアの皆さんにお読みいただけると嬉しいです。

はじめに

あらためまして、QAエンジニアのKanaです。昨年9月にサイボウズにJoinし、現在はサイボウズOfficeという製品のモバイルアプリ版を開発するチームでQAエンジニアとして活動しています。

長いこと「構想からカットオーバーまで足掛け6年!」といった規模の巨大プロジェクトでウォーターフォール開発ばかりやってきたところから、いきなり1スプリント1週間のアジャイルの現場に踊り込み、右往左往しつつも、日々楽しくQAライフを満喫しています。

Cursorとは

早速ですが、CursorはいわゆるAIコードエディタの一種です。

パッと見は「右側にAIチャットボットがくっついたIDE」といったおもむきで、見た目のとおりAIにあれこれ相談しながら開発作業を進めていけるようになっています。

聞くところによるとCursorのベースはVisual Studio Code(VS Code)だそうですが、なにしろPG現役時代最後に触ったIDEがEclipse 4系あたりなので、「VS Codeベース」といわれても一向にピンときません。「Xcodeがベースです」と言われても「へぇ、そうなんだぁ」と納得してしまうかもしれません。

Cursorを使ってみようと思ったきっかけ

私がはじめてCursorに触れたのは、去る8月14日。お盆休み期間で少し時間に余裕が生じ、手持ちの改善タスクなどもある程度目処がついたので、しばらく見て見ぬフリをしていたAI4QA領域の探索にちょっと手を伸ばしてみようかと思い立ちました。

実を言うとCursorに関しては、少し前から噂を耳にしていました。しかし、社内でエンジニアのみなさんが「Cursorすげぇ」「めっちゃ便利」…とザワザワしているのを、

「私、コードを書くわけじゃないし…」

と半ばヒトゴトのスタンスでちら見を決め込んでいたのです。

そんな私が重い腰を挙げるきっかけとなったのは、お盆前に帰省してきていた息子の一言でした。

息子もIT業界で働いているのですが、ちょっと前まで「ワイヤーフレームってなんのこと?」というレベルだった彼が、聞くと最近はChatGPTとCursorを駆使してAWSのアーキテクチャ図やER図、なんならモックまで自作しているというではありませんか。

「便利だから、絶対使った方がいいって!」

という彼の一言に背中を押される形で、Cursorのアカウントを作ってみたというわけです。

Cursorはじめの一歩

さて、これがCursorの入門記事なら、ここでダウンロードからインストールまでの手順などの説明が入るところですが、あいにくこの記事は五十路QAの他愛のないつぶやきです。そのあたりは大胆に割愛させていただいて、Cursorを使える環境が整ったところまで時計の針を進めましょう。

Cursorを入手した私が最初に試みたのは、自分が担当している製品のソースコードを読み解く作業でした。

一般にQAが自らプログラムコードを書くシーンはそれほど多くありませんが、ソースコードが読めると便利な場面は多々あります。不具合の再現確認の際にプログラム構造からあたりをつけることができますし、試験設計時にグレーボックス的アプローチでテストケースを間引くのにも役立ちそうな気がします。

Cursorは、起動時にUI上で「既存のプロジェクトを開く」「リポジトリをcloneする」「SSHで接続する」の三つのモードから好きなものを選択できるようになっているのですが、今回はGithub上にあるソースコードをローカルにダウンロード(clone)してきました。認証まわりの設定ができていさえすれば、画面上にリポジトリのURLを入れてEnterを押すだけです。

cloneが終わるとエディタ画面が開き、右側にAIとチャットする画面が表示されるので、ここに聞きたいことを打ち込みます。

ちなみに記念すべき最初の質問は「一番はじめに呼び出されるファイルはどれ?」

…残念ながら会話の様子をお見せすることはできませんが、Cursorは質問に応じてリポジトリ内のソースコードを調査してサクッと答えを出してくれました。

その後、回答で指示されたファイルを一つひとつ開きながら、「このコードはどういう意味なの?」「このファイルに書かれた処理が終わると、アプリケーションはどんな状態になるの?」「このフォルダの中にはどんな種類のファイルが入っているの?」「⚪︎⚪︎と××でファイルが分かれているのはなぜ?」…などなど頭に浮かんだ質問を繰り返し、起動から初期画面表示までの流れを追ってみました(アプリケーションの処理の流れを追ってみるのは、プログラムの構造理解にとても役立ちます)。

それにしても、こちらが投げかけるどんなささいな疑問に対しても、面倒臭がらずに丁寧に回答してくれるのはありがたいですね。相手の手間暇を気にかけることなく都度質問を投げられるのは、小さいようでいてとても大きなAIの美点だと思います。

目指せCursor使い!今後の野望

というわけで、ファーストセッションである程度感触が掴めたのに気をよくして、その後も日々のQA業務の中でも色々とCursor先生のお世話になっています。先日はPGメンバー不在時に報告された現象について、それが不具合なのか仕様制限なのかを切り分けるために、Cursorにソースコードの調査をお願いしてみたりもしました。

まだ使い始めたばかりで手探りしているところではありますが、今後うまく使いこなせるようになれば、次のようなシーンで役立ってくれるのではないかと期待しています。

  • グレーボックス的アプローチによるテストの効率化
  • 不具合調査時の情報収集・整理
  • 探索的テストのアシスト役として
  • テスト不十分な領域の割り出し
  • 自動テストの安定性改善   …などなど

なお、言わずもがな、ではありますが、注意したいのは「AIは完璧ではない」という点です。コーディング領域ではかなり精度が上がってきているとはいうものの、AIが不正確な答えを出してくる恐れはまだまだあるでしょう。

Cursorから得た情報はあくまでも一次情報として扱い、重要な意思決定前には必ず有識者の助言を仰ぐというスタンスをしばらくは貫きたいと思っています。

おわりに

この記事では、QAエンジニアが一念発起してCursorを使い始めた経緯と、今後のささやかな野望などを語ってみました。

長い文章を書くのは割と久しぶりで、我ながらぐだぐだになってしまいましたが、Cursorに関心を持つQAの皆さんに、この記事がすこしでも参考になれば幸いです。