Cursor使ってみた！〜プログラミング初心者が感じたAIコーディングの衝撃と現実
はじめに
はじめまして！株式会社モアでエンジニアをしています。年齢は46歳でweb系開発を3年目に迎えるまだまだ初心者のエンジニアです。
半年前まではVSCodeとブラウザー版のClaudeで質問しながらコード書いてました。
これでも、調べる速さやとっかかりの速さは、自分でググって探すよりかは断然開発スピードが違ってました。
これで初心者でも難しい問題を乗り越えられる時代がやってきたと感じてました。
そんな中、開発者界隈で「Cursor」というAIコーディングツールが話題になっているのを耳にしました。「VSCodeにAIが統合されたようなもの」「コーディング体験が革命的に変わる」という声を聞いて、これは試してみないといけないと思ったのです。
そこで実際にCursorのProプランを使ってみた感想を、初心者目線でブラウザー版のClaudeと比較しながら正直に書いてみたいと思います。
チャットモードの衝撃
統合度・作業効率の革命
ブラウザー版Claude時代：
コード生成→コピー→VSCodeに貼り付け→動作確認→修正点をまた質問
Cursor導入後：
エディタ内で直接やり取り、コードベース全体を理解した上での提案
これまでのように画面を行き来する必要がなくなり、作業効率が格段に向上しました。
コンテキスト理解の精度向上
ブラウザー版Claude時代：
毎回プロジェクト全体の説明が必要、ファイル構成を把握していない
Cursor導入後：
プロジェクト全体を把握、関連ファイルを自動的に参照
「このプロジェクトでは〜」という説明を毎回する必要がなくなり、より本質的な問題解決に集中できるようになりました。
.cursor rulesファイルによる開発効率化
Cursorの真の力を発揮するために、プロジェクトルートに.cursorフォルダを作成し、その中に複数の設定ファイルを配置することで解決できます。
例えば、これらのファイルには以下のような内容を記載することで「このプロジェクトでは〜」の説明がなくなるので、必ず書くようにしましょう。
プロダクト情報（productContext.mdc）
- サービスの存在理由：起案者と寄付者をつなぐクラウドファンディングプラットフォーム
- 解決すべき問題の明確化
プロジェクト概要（projectBrief.mdc）
- プロダクト詳細：◯◯◯サイトのAPI
- ユーザー種別：一般ユーザー（dominator）とショップオーナー（project owner）
- リポジトリ構成：vision-backendをルートとする構造
技術仕様（techContext.mdc）
- 使用技術：Laravel、PHP 8.2、mysqldef、Firebase認証
- コーディング規約：キャメルケース、PSR-2準拠
- アーキテクチャ：クリーンアーキテクチャ、DDD
システム設計（systemPatterns.mdc）
- ディレクトリ構成：Domain、Usecase、Infraの3層構造
- 設計パターン：CommandQueryパターン、DIの使い方
開発プロセス（taskProgress.mdc）
- 実装手順：OAS確認→テーブル設計→実行計画→テスト実行
- 品質管理：N+1問題の回避、技術的負債の防止
テスト戦略（test.mdc）
- テスト種類：E2Eテスト（tests/Feature）とドメインテスト（tests/Unit/Domain）のみ
- テスト実行方法：個別テスト→全体テスト（make test）の順序
- データ作成：Factoryパターンを使用、foreign key依存関係を考慮
- 認証モック：TestAuthMiddlewareでログインユーザーをシミュレート
つまり、事前にプロジェクト全体のコンテキストを渡しているため、毎回の詳細説明が不要になり、まるで長年このプロジェクトに携わっているエンジニアのような精度で開発が進められるようになったのです。
作業フローの劇的な変化
ブラウザー版Claude時代：
「質問→回答待ち→実装→テスト→また質問」の繰り返し
Cursor導入後：
リアルタイムでの対話、インラインでの修正提案
まるでペアプログラミングをしているような感覚で、開発が進められるようになりました。
エラー対応効率の向上
ブラウザー版Claude時代：
「このエラーが出たんですが...」と毎回エラー文をコピペ
Cursor導入後：
エラー箇所を選択するだけで、自動的にコンテキストを理解して解決策を提案
エラー対応にかかる時間が大幅に短縮され、ストレスが大幅に減りました。
AIエージェント機能の衝撃
自律的な作業進行
「○○機能を実装して」と伝えるだけで、.cursor rulesファイルに沿って
AIエージェントが以下を自動で実行してくれます：
- 複数ファイルを横断した自動作業
- 必要なファイルの自動生成と既存ファイルの適切な修正
- 関連する設定ファイルやテストファイルの自動作成
例えば「◯◯◯のAPIを作成して」と伝える際にきちんと伝えておくことが必要です。
間違ったことを伝えるとAIは何とかそのようなこと実現をしようと考えてしまうからです。
そして全体を把握して以下のように提案してきます。
実際の例がこれになります。
実際の例
ドキュメント作成後のフローも重要です
このドキュメントをもとに実装が進められるため、ご自身のイメージに合った内容になっているかどうかを確認することが重要です。
たとえば、DDD（ドメイン駆動設計）を前提としているため、ドメイン層・ユースケース層・インフラ層・HTTP層が的確に配置されており、適切な名前が付けられているかを確認することで、実装とのズレを未然に防ぐことができます。
また、DBのSQL文が含まれている場合には、その内容が正しいかを確認することで、実装前にバグを防ぐことにもつながります。
そのため、細部まで丁寧に確認していくことで、実装された後の確認の手間が省けたり手戻りのリスクを減らしたりすることができます。
そして「お願いします」と伝えるだけで、本来であれば2時間かかる作業を、わずか10分足らずで自動的に行ってくれます。
まさに“魔法”のような体験ですが、生成されたコードに無駄がないか、また正しく実装されているかどうかは、必ずご自身で確認するようにしてください。
複雑な判断の自動化
AIエージェントは以下のような高度な判断も行ってくれます：
- エラーが発生した際の原因特定と自動修正
- 依存関係の理解と必要なパッケージのインストール提案
- コードの整合性を保った一貫性のある実装
AIコーディングの「現実」も知っておこう
コスト面での課題
実際に業務で使ってみると、PROプランでも意外と上限に達してしまいます。特に複雑な機能を実装している時は、何度もやり取りを重ねるため、気づいたら制限に引っかかっていることも。上限後は性能の低いAIになってしまい、期待した回答が得られず、結局追加課金が必要になりました。
依存リスクという落とし穴
便利すぎるがゆえに、つい頼りきってしまうのも考えものです。ネット障害で使えなくなった時、「あれ、これどうやって書くんだっけ？」と手が止まってしまった経験があります。AIコーディングは強力な道具ですが、基礎的な知識も並行して身につけることが大切だと実感しました。
完璧ではない自動化
便利な反面、以下のような課題も見えてきました：
- 意図しない変更を勝手に加えてしまうことがある
- 複雑な要件では、途中で迷子になって中途半端な実装になることも
- 生成されたコードの品質にばらつきがある
制御の難しさ
AIエージェントを使う上で感じた難しさ：
- 何をどこまで変更したか把握しにくい
- 途中で止めたくても、どこまで戻せばいいかわからない
- 自動化された作業の検証に時間がかかる場合がある
気づいたら重要な設定ファイルが書き換えられていて、デバッグに時間がかかったこともありました。
まとめ
Cursorを使ってみて、AIコーディングの可能性と限界の両方を実感しました。
素晴らしい点：
- 開発効率の劇的な向上
- エラー対応の高速化
- 複雑な実装の自動化
注意すべき点：
- コスト管理の重要性
- AIへの依存リスク
- 生成コードの品質確認の必要性
AIコーディングツールは確実に開発を変革していますが、それは「人間の代替」ではなく「強力なパートナー」として捉えるのが適切だと感じました。基礎知識を身につけながら、AIの力を借りてより高いレベルの開発に挑戦していく、そんな時代が来ているのかもしれません。
皆さんもぜひCursorを試してみて、AIコーディングの衝撃と現実を体験してみてください！
最後に
弊社では一緒に働く仲間を募集しています！AIツールを活用した現代的な開発環境で、新しい技術にチャレンジしたい方、ぜひお気軽にご連絡ください。
詳しくは株式会社モアをご覧ください。
Discussion