Cursor Meetup Tokyoも開催され、日本のITエンジニア界隈にもいよいよCursorが本格的に浸透してきたか・・・と思い、まだ使っていなかったのでCursorを導入することにしました。
目次
インストール・会員登録とプランの契約
特に詳しく説明しない(公式のページを参照ください)ですが、インストール時にVSCodeを使っている場合は基本的な設定などはインポートでき、またWeb上で会員登録などを行うのと、CursorアプリからWebブラウザへリンクを飛ばしてその中でログイン認証→Cursorへ戻るという流れで、契約しているプランも無事使えるようになりました。
初回セットアップは想像していたよりもスムーズで、VSCodeからの移行についても拡張機能やキーバインド設定が引き継がれるため、ほぼ違和感なく使い始めることができました。
導入自体は思っていたほどのエモーショナルな出来事にはならなかった
Proプランに入っているものの、Max modeはコスト面を考慮して、通常のモードで使っていることもあるのか、そこまで革新的なものはなく、普通にコーディングをチャット画面から依頼して、実行してもらう単調なものでした。
後述のように、どこかおかしいところはないかなどプロジェクト内を網羅的にみて修正や調整といったことをしてくれるといったところで、価格以上の仕事はしてくれるのですが、体感的に、ファイルベースではClaude 4に直接添付してやったほうが、2025年6月現在は確実により高度で精度が高いコーディングが行えます。
この点について深く考えると、CursorとClaude 4それぞれには得意分野があり、使い分けることで開発効率を最大化できるのではないかという気づきが得られました。
ルールの作成、.mdcファイルは作らせてしまおう
感動的なコーディング、プログラミングはないのですが、確実に仕事をこなしてくれる分野はあり、指示プロンプトとなるルールを.mdcにfront matterなYAML形式で書き出せば利用できるので、もし既存のプロジェクトを読み込んで利用する場合は、その資材をCursorに分析させつつ、どのような視点に重きを置いてルールを最適化するかを伝えることでルールをCursorに作成させることができます。
最初にやってみた中では、ルールの.mdcファイルは3〜4kbぐらいに納め、複数ある場合はYAML内に参照するファイルを記述、またその優先順位などでも、処理の作りとしてはエージェントの種類などの影響で多少プログラミングやコーディングに変化がでてきそうでした。
興味深いのは、8kbで多層的なコーディングルールを指定した場合は入力時にフリーズしてしまうこともあったので、コンテクスト豊かなルールが可能になるのはまだ少し先のようでした。この制限を理解して、段階的にルールを構築していく必要があります。
実際のルール設定例
参考までに、実際にCursorで作成し、cdbk.tokyoのNuxt3環境で使用している.mdcファイルを一つ紹介します。
前提として、一度自分で構築・Claude ProでリファクタリングしたものをプロジェクトとしてCursorにワークスペースとして取り込んで使用しています。
# コーディングプロファイル ## 基本設定 ### 開発環境 - Node.js: v18.x以上 - パッケージマネージャー: pnpm - エディタ: VSCode - ブラウザ: Chrome最新版 ### 必須ツール - Git - ESLint - Prettier - TypeScript - Vue DevTools ## コーディング思想 ### 設計原則 1. コンポーネント設計 - 単一責任の原則 - 再利用可能な設計 - 適切な粒度の分割 2. 状態管理 - ローカル状態はコンポーネント内で管理 - グローバル状態はPiniaで管理 - 状態の不変性を維持 3. エラーハンドリング - 型安全性の確保 - 適切なエラーバウンダリ - ユーザーフレンドリーなエラーメッセージ ## フロントエンド実装 ### コンポーネント設計 ```vue <script setup lang="ts"> // 型定義 interface Props { // プロパティ定義 } // プロパティ定義 const props = defineProps<Props>() // イベント定義 const emit = defineEmits<{ (e: 'update', value: string): void }>() // 状態管理 const state = ref<State>() // ライフサイクル onMounted(() => { // 初期化処理 }) </script> ``` ### スタイリング - SCSSモジュールの使用 - BEM命名規則 - 変数とミックスインの活用 - レスポンシブデザインの基本単位 #### カラー定義 - RGB形式: `rgb(r, g, b)` - RGBA形式: `rgba(r, g, b, a)` - 透明度: `opacity`プロパティで制御 #### フォント指定 - 本文テキスト: `a-otf-ud-reimin-pr6n`（UD黎ミン） - コンセプト/キャッチ: `din-2014`（DIN 2014） - フォールバック: `source-han-sans-japanese`（Source Han Sans） - システムフォント: `-apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif` #### アニメーション - キーフレームアニメーションの使用 - トランジション効果の定義 - パフォーマンスを考慮した実装 #### ミックスイン - `blockMargin`: ブロック要素のマージン設定 - `blur`: ぼかし効果の設定（saturate, blurパラメータ） #### SCSSファイル構成 - 変数定義: `_variables.scss` - ミックスイン: `_mixin.scss` - ベーススタイル: `_body.scss` - レイアウト: `_header.scss`, `_footer.scss`, `_nav.scss`, `_main.scss` - コンポーネント: `_button.scss`, `_icon.scss`, `_modal.scss`など - ページ固有: `_page.scss`, `_pageBackground.scss`など - インポート順序: 変数・ミックスイン → ベース → レイアウト → コンポーネント → ページ固有 ### アニメーション - CSSトランジションを優先 - パフォーマンスを考慮した実装 - ユーザー体験を重視 ## AIとの協業 ### プロンプト設計 - 具体的な要件の提示 - コンテキストの提供 - 期待する出力形式の指定 ### コードレビュー - 生成コードの検証 - セキュリティチェック - パフォーマンス確認 ## 実装プロセス ### 開発フロー 1. 要件の理解と分析 2. コンポーネント設計 3. 実装 4. テスト 5. レビュー 6. デプロイ ### 品質管理 - 型チェック - リンター - フォーマッター - ユニットテスト ## 技術選定 ### フレームワーク - Nuxt 3 - Vue 3 - TypeScript ### ライブラリ - Pinia（状態管理） - Vue Router（ルーティング） - SCSS（スタイリング） ## コミュニケーション ### コードレビュー - プルリクエストの活用 - レビューガイドラインの遵守 - フィードバックの共有 ### ドキュメント - コードコメント - コンポーネントドキュメント - 変更履歴の管理 ## 参照ガイドライン - SEO設定: `seo-guidelines.md` - ブランドトーン: `brand-guidelines.md` - 技術実装: `technical-guidelines.md` ## 更新履歴管理 ### 更新履歴の記録ルール 1. 各ルール設定の変更時は必ず更新履歴に追記 2. 日付は YYYY-MM-DD 形式で記録（JST） 3. 変更内容は簡潔かつ具体的に記述 4. 複数の変更は個別の行に記録 5. 最新の変更を最上部に記録 6. 日付は日本標準時（JST）を基準とする ## 更新履歴 - 2025-06-07: SCSSの@importを@useに移行し、モジュール化 - 2025-06-07: フォント指定のルールを追加し、変数定義を更新 - 2025-06-07: 更新履歴の日付をJST基準に指定 - 2025-06-07: SCSSファイル構成の整理とルール追加 - 2025-06-07: スタイリングセクションに詳細なルールを追加（カラー定義、アニメーション、ミックスイン） - 2025-06-07: 初版作成 - 2025-06-07: AI協業セクション追加 - 2025-06-07: コード例の更新...
このような形で、主要なファイル構成なども織り込んで、対応しやすい状態を整え始めました。
別の視点から見ると、ルール設定の段階でプロジェクトの方向性や品質基準を明確化できるという副次的な効果も得られており、これは単なるAIツールの設定を超えた価値があると感じています。まだまだCursorでどこまで分析・判断・処理できるのか未知数なところもあるので、しばらく使いながら調整していきます。
複雑な処理を行う場合はまだClaude 4が優勢
たとえば、Nuxt3の汎用的な対応から外れた依頼をプロンプトでした場合、例外的な特殊な処理を追加していた場合などは、うまくいかないことが多く感じました。
具体的には、cdbk.tokyoではFlickr APIを利用して写真のアルバムを取得し、それをphotographyやkeyboardで写真の一覧と全画面モーダルでの表示といったことを行っているのですが、これを実装しようとすると、Cursorではなく、Claude 4にやりたいこと、画面構成、使うフレームワークや既存の画面などをプロンプトとファイルで添付しつつ作らせるのが、今のところは最も効率的な方法のようでした。
Claude 4との使い分けのコツ
コツとしては、事前にファイルを分けたい場合はそのディレクトリ構造やファイルリストをプロンプトで伝えること、そして、エラーが出る、レイアウトがうまくいかないときに、修正させるのではなく、依頼時のプロンプトの内容を改変して1から作らせる方が早くうまくいくことが多いので、その点に留意が必要です。
また、トークンを結構使うのでPro契約の場合はそれを1つやり終える、もしくは終わらないうちに制限がくることがあるので、段階的に作業を依頼することが重要です。修正させる場合は修正して欲しい関数のみを出力させて自分で差し替えたり、差分だけを出力させることでトークン消費を減らすことができます。
そしてある程度できてしまえば、Cursor上からの操作で対応できるので、共通化させたい処理の重い機能をClaude 4で下地を作り、それをCursorで展開するといったやり方が今のところは現実的な路線かなと考えています。
それぞれのツールの適材適所を見極める
これまでの経験から言えることは、Cursorは既存プロジェクトの保守・改善や定型的なコーディング作業において真価を発揮し、Claude 4は複雑な設計や新規機能の実装において優れているということです。両方の側面を考慮すると、開発フェーズや作業内容に応じて使い分けることで、開発効率を大幅に向上させることができそうです。
Cursorをしばらく使ってみる
これから、Cursorが日本でも本格的に使われ始め、Zennなどでもっと知見が広まっていくと思うので、その辺りをキャッチアップしつつ、Claude 4でコード作成などに最適化したプロンプトなどで使えるところは、どんどんCursorで使える形にして導入していきたいです。
プロセスを振り返ってみると、AIツール同士の連携や使い分けという新しい開発パターンが生まれつつあることを実感しています。しばらくCursor中心に開発を進め、AIエージェントを使った開発をもっと身近にできるよう進めていきます。
より高次の視点から見れば、これは単なるツールの導入ではなく、開発プロセス自体の変革につながる可能性があります。今後の展開が楽しみです。