エンジニアの相棒Cursorで爆速開発！

こんにちは！労務プロダクト開発本部/労務コア開発1部に所属する、16bit_idolと申します。最近は、お問い合わせ対応負荷軽減の取り組みに全力を出している者です。お問い合わせ対応の事を、社内ではDesk（デスク）と呼んでいます。

昨年のWomen Developers Summit 2024のライトニングトークでお問い合わせ対応負荷軽減の取り組みをお話ししました。

Deskってなに？

Deskとは、簡単に言うと、お客様からいただくテクニカルなお問い合わせに対して、私たちプロダクトエンジニアが調査・対応する業務のことです！ SmartHRには、労務全般を扱う基本機能の他にも、文書配布、人事評価といったオプション機能があり、その機能ごとにDesk対応をしています。特に大変なのが、基本機能のDesk業務です。現在は、基本機能のDesk担当はローテーション制を採用しており1週間毎に担当者が変わります。基本機能は複数の機能がまとまっているため、とても大きく隅々まで把握するのが難しくなってきています。どのくらい大きいかは、以下の記事を参考にして頂けると雰囲気は伝わるかなと思います。 logmi.jp

そのため、各機能に対してオーナーがおり、オーナーはチーム単位で割り振られています。お問い合わせがくると、機能オーナーへタライが回ります。タライが回ってきたチームは対応に当たります。いつどのタイミングでDesk対応が必要になるかわかりませんし、お問い合わせの件数によってはFeature開発を一旦止めて対応に当たる場合もあります。また、お問い合わせ数も年々増加しています。チャットサポート件数に対するDeskお問い合わせ比率は2〜3%を維持しているものの、導入企業増加に伴いその数は増え続けています。このままでは、耐えられなくなる時期はいずれ来てしまいます！

日々増えるお問い合わせ対応に追われるDesk業務。私たちは、この課題をAIの力を借りて解決することにしました。

Desk AIアプリケーションとは？

Desk AIアプリケーションとは、SmartHRの社内問い合わせをAIの力でよりスマートに・効率的にするサービスです。まだ開発半ばではありますが、以下のような機能を持つサービスにしていく予定です。

賢い回答提案
- 過去の問い合わせデータをベクトル検索で分析
- AIが最適な回答を提案
- お問い合わせ者、対応者の時間を節約
- 回答リードタイムの短縮
効率的な業務フロー
- 自動応答機能で即時対応
- JIRAとの連携で課題管理もスムーズ
- 過去の問い合わせデータを活用した学習機能

技術面では、Ruby on Railsをベースに、Azure OpenAI ServiceやGoogle Cloud Platformの最新技術を活用。セキュアでスケーラブルな設計になっています。お問い合わせをする人、受ける人それぞれの業務効率を向上させることを目指しています。

Desk AIアプリケーションの開発は、インフラからアプリケーションまでを私を含めた2名で担当しています。このアプリケーションの開発はサブプロジェクトになるため、私はフルコミットできるのですがもう1名は自身のメインタスクの合間を縫って開発作業にあたっています。そのため、どうしても開発速度が出せずにいました。 GitHub CopilotやChatGPT、Clineなどを利用して開発をしていましたが、もっともっと開発速度を上げれたら……と日々悩んでいました。

そんなある日、社内でのCursor利用が解禁されたのです。開発速度を上げることができるならば！と藁にもすがる気持ちで使ってみることにしました。するとどうでしょう、ちょっとびっくりするような開発体験が待っていたのでした。

どうしてCursorにしたの？

先にも書いた通り、GitHub CopilotやChatGPT、Clineなどを利用して開発をしていましたが、それぞれに一長一短がありました。

GitHub Copilot
- リアルタイムでコード補完をしてくれる
- でも、既存コードベースの文脈理解が限定的である
- 複雑な機能追加は対話形式で相談できない
ChatGPT
- 対話形式で相談できる
- でも、コードベースを理解させるのが大変
- エディターと行き来する必要がある
Cline
- エディター上で手軽に使える
- でも、開発の文脈を維持するのが難しい場合もある

Cursorは、OpenAIのGPT-4を搭載した次世代のAIコーディングエディターです。Visual Studio Code（以下、VS Code）をベースに開発されており、従来のコーディングエディターの機能に加えて、強力なAI機能を統合しています。

主な特徴は以下の通りです。

コードの自動生成
- 日本語で「こんなの作って！」って言うだけでコードを作ってくれる
コードの解説・ドキュメント化
- 既存コードの説明や改善提案をしてくれる
バグの検出と修正
- エラーの原因特定と修正案の提示をしてくれる
リアルタイムペアプログラミング
- AIとの対話形式でのコーディングできる

今回の開発でCursorを選んだ理由は、AI開発に特化した機能が充実していたからです。特に以下の点が決め手となりました。

AIとの自然な対話
- プロンプトを書くだけで、AIが文脈を理解して適切なコードを生成してくれる
高速な開発サイクル
- コードの生成から修正まで、すべてエディター内で完結できる
VS Code互換
- 普段使い慣れたVS Codeの操作感とプラグインが使える
充実したAIサポート
- コードレビュー、バグ修正、リファクタリングなど、開発全般をサポートしてくれる

実際どんな感じでコードを書いているの？

Desk AIアプリケーションは、Ruby on Railsで作っています。作成当初は、人間の手でコードを書いていましたが、Cursorを使うようになってからは以下のような変化が生まれました。

開発当初、ドキュメント類は人間向けのガイドラインみたいな内容だったのですが、少しずつCursorが一人で理解・作業できそうな内容に変更したり削っていったりしました。それから、人間がおこなうとめんどくさい作業も追加しました。機能追加や修正のたびに作業ログを残させて、次回からそのログが参照できるようにしました。改善のサイクルを勝手に回させる試みを追加しています。作業ログは、下記のようにファイルに書き出されます。

# ログインテスト修正作業ログ

## 日付
2025年3月14日

## 担当者
Cursor AI

## 作業内容
ログイン機能のシステムテスト（`spec/system/login_spec.rb`）が失敗する問題を修正しました。

### 問題の詳細
テストケース「GitHubログインボタンをクリックするとGitHub認証にリダイレクトされること」において、
ログイン後に「こんにちは、Test Userさん！」というテキストが表示されることを期待していましたが、
実際のアプリケーションでは単に「Test User」と表示されているため、テストが失敗していました。

### 修正内容
テストの期待値を実際のアプリケーションの動作に合わせて修正しました。

/```diff
expect(page).to have_current_path(root_path)
expect(page).to have_content("ログインしました")
- expect(page).to have_content("こんにちは、Test Userさん！")
+ expect(page).to have_content("Test User")
/```
・
・
・

Cursorのルールは、以下のように設定しています。いくつかあるルールファイルのうちの1つ（.cursor/rules/FEATURE_DEVELOPMENT_GUIDELINES.mdc）をご紹介します。

# 機能開発ガイドライン（Cursor Agent向け）

以下は、CursorがAgentモードで自律的に機能開発を行う際に確認すべきルールです。

## 1. 設計ドキュメントの確認と更新
- 開発前に必ず `docs` フォルダの既存の設計書やADRを参照する。
- 新規機能の場合は、実装前に設計書を作成し、`docs` に追加する。
- 既存機能に変更を加える際は、設計書やADRを必ず更新する。

## 2. コミットメッセージ
- コミットメッセージはリポジトリ内の `.commit_template` を参照し、その形式に従う。

## 3. 複数行コミットメッセージのルール
- 1行目は `.commit_template` のEmojiリストから適切な絵文字を選び、簡潔なサマリーを記載する。
- 2行目は空白行を挿入し、以降の内容と明確に区切る。
- 3行目以降のボディには、変更の詳細を箇条書きや簡潔な文章で記載する。
- ボディでは変更理由・影響範囲・検討した代替案などを適切に説明する。

## 4. テストの実施
- すべての新機能には自動テストを作成する。
- テスト実装においてはモックを最低限にとどめ、既存のモデルやFactoryBotを使用し、実際のデータやアプリケーションの挙動に近いテストを行う。
- 外部APIへの依存がある機能のテストでは、依存性の注入パターンを使用し、Fakeサービスクラスで置き換えることで外部APIの呼び出しを防ぐ。
- モックやスタブを使用する場合は、その理由を設計書に明記する。
- テストが難しい場合は理由を設計書に明記する。

## 5. マイグレーションとデータベース変更
- DBスキーマの変更時はマイグレーションを作成し、動作確認を行う。
- DB変更手順を設計書または運用ドキュメントに記載する。

## 6. エラーハンドリングとログ
- エラーケースや重要処理には明示的なログを残す。
- 障害対応やモニタリングのため、ログメッセージは具体的に記述する。

## 7. 依存関係・影響範囲
- 機能の実装や変更時は、必ず他機能やシステムへの影響範囲を確認し、設計書に記録する。

## 8. 振り返りとフィードバック
- 開発完了後、実装結果についてのフィードバックを収集し、設計書に追記する。
- 次回の改善のため振り返り結果を記録する。

## 9. 作業ログの記録場所
- 作業ログや振り返り・フィードバックなどの記録は、`work_logs` フォルダに保存する。
- ファイル名は `[日付]_[機能名]_log.md` の形式で統一する（例: `20250314_user-login_log.md`）。

## 10. 作業ログの活用
- 新しい機能開発や改善を開始する前に、関連する過去の作業ログを必ず確認する。
- 過去に発生した問題や改善策を設計時点で反映し、同じ課題が繰り返されないようにする。
- 作業ログ内の有効な知見や学びは設計書やADRに取り込み、ノウハウとして体系化する。

## 11. ファイルサイズと構造のルール
- 1つのファイルやクラスのサイズはコンパクトに維持し、責務が複数ある場合は分割を検討する。
- 原則として、1ファイルは200行以内を目安とし、超える場合は設計書で分割案を記載する。
- 複雑な処理や複数の責務がある場合は、明確に分離し別ファイルに抽出することでAIが適切に文脈を理解できるようにする。

この他にも、Railsアプリケーション開発ガイド（Cursor用）を作っていたりします。では、実際にどのようなプロンプトでコード生成をお願いしているのでしょうか？現在、私含め2名で開発をしているのですが、プロンプトはそれぞれで書いています。

私はかなり雑にお願いをするタイプです。 FAQデータをGoogle Driveにアップロードする機能を追加する際に実際に使用したプロンプトです。

FAQ生成API（POST /faqs_generate/execute）で生成したデータを、Google Drive一括アップロードできるようにしたいです。
Google Drive一括アップロード画面（/google_drive_upload）と機能・デザインを揃えたいです。

ただし、下記を考慮してください。
1. アップロード先はFAQ専用フォルダにする
2. 選択されたFAQを１ファイルにしてアップロードする

いやもっと細かく仕様を伝えてやれよ……と書いてる自分でも思いますが、そこはCursor。こちらのやりたいことを汲み取り、いい感じに作ってくれます。

私がCursorに雑なプロンプトで作業依頼をしているチャットウィンドウ — Cursorとのチャット画像

もちろん対話形式なので、相棒と一緒に作業をしている気持ちになってきます。

もう一人は、以下のようにプロンプトを書いていました。

課題の要約ドキュメントをGoogle Driveにアップロードする機能なのですが、未アップロードの要約ドキュメントを一括で非同期ジョブでアップロードする機能を実装したいです。

どの画面にどのように実装するのが良いでしょうか？
画面ごとにアクセス権限もあるので考慮してください。

既存の画面でも良いですし、新たに適切な画面が必要になりそうであれば提案してください。

このプロンプトに対してCursorは以下のように一次回答してくれました。

## Google Drive一括アップロード機能の実装提案

### 現状分析
現在のシステムでは:
- チケット詳細画面(TICKET_002)に個別のGoogle Driveアップロード機能がある
- 管理者ユーザーは特別な権限を持っている(JQLインポート画面、Slackインポート画面)
- 一般ユーザーはチケット閲覧権限を持っている

### 実装提案
新規画面: Google Drive一括アップロード画面

このように、誰が指示を出してもCursorは回答・提案をしてくれます。

AI開発におけるCursor活用のメリット・気づき

Cursorを使い始めてから、開発のスピードが上がったのは言うまでもありません！

驚きの開発効率

最も印象的だったのは、プロンプトの柔軟性です。例えば、Google Driveへのアップロード機能を実装する際、私は上で書いたように簡潔なプロンプトを投げかけました。

このような「雑な」プロンプトでも、Cursorは既存のコードベースを理解し、必要な実装を提案してくれました。人間同士のペアプログラミングでは、これほど少ない情報での意思疎通は難しかったでしょう。もし、自分がペアプロした際に相棒にコレを言われて、即座に理解できる自信はありません。

開発者体験の革新

従来のコーディングでは、以下のような作業に多くの時間を費やしていました。

テストコードの作成
エラーハンドリングの実装
ドキュメントの更新
コードの最適化

Cursorは、これらの作業を自動的に提案し、実装してくれます。例えば、新機能の実装後に「テストを追加しましょうか？」と提案してくれたり、エラーハンドリングの実装漏れを指摘してくれたりします。

一貫性のある品質担保

私たちのプロジェクトでは、開発ガイドラインやルールを設定していますが、Cursorはこれらを完璧に遵守します。例えば……

200行を超えるファイルは自動的に分割を提案
コミットメッセージの形式を統一
作業ログの自動記録
テストカバレッジの維持

人間では見落としがちな細かいルールも、AIは確実に守ってくれます。

思考の質的転換

価値があると感じているのは、コードを書く時間が圧倒的に短くなり本質的な課題に集中できるようになったことです。例えば、FAQ生成機能の実装では、コードの記述ではなく、生成されたFAQの品質向上やユーザーインターフェースの改善により時間を割くことができます。また、AI駆動な思考になり「AI向けのガイドラインを整備しよう」となってきます。

今後の展望・まとめ

現在、Desk AIアプリケーションは「賢い回答提案」に向けて絶賛実装中です。過去のお問い合わせとその回答から、FAQを生成しNotebookLMにインプットさせ活用できるところまできています。 Desk AIアプリケーションに取り組みはじめた頃はNotebookLMはまだなかったため、インターフェイスをどうするかで考える事が多かったのですがNotebookLMが使用できるようになることで、より柔軟にAI活用をしていけるようになりました。将来的には、過去の問い合わせデータをベクトル検索で分析をし、AIが最適な回答を提案してくれる事を目指しています。

最初は、2人で作っているとはいえ1名はフルコミットではなかったり、私も別件対応などで開発が思うように進みませんでした。しかし、Cursorという最高の相棒も加わることで、開発速度は爆上がりです。