Laravelでの開発を、Cursorに乗り換えて速くしたい——そう思って導入してみたものの、「AIが書いたコードをそのまま受け入れていいのか分からない」「マイグレーションやEloquentのモデル定義でどこまで任せていいのか判断できない」という状態で止まってしまう人は多いです。エディタを変えただけでは、開発は速くなりません。運用の型が必要です。
この記事は、Laravelでの実務開発を前提に、Cursorをどう設定し、どこまでAIに任せ、どこを必ず人間がレビューするかをまとめた入門ガイドです。機能紹介ではなく、Laravelプロジェクトでの具体的な使い方と、絶対に自動承認してはいけない場面を中心に書きます。
先に結論です。Cursorを使うなら、最初にプロジェクト固有のルール（Laravelのバージョン、命名規則、ディレクトリ構成、禁止事項）をルールファイルとして書き、@codebaseでプロジェクト全体を参照させながら、コントローラーやバリデーションのような「型が決まっている」部分から任せていくのが安全な導入順序です。マイグレーションの実行、本番データに関わる変更、認証・権限周りのコードは、生成後に必ず人間が読んでから適用してください。
なぜLaravel開発とAIエディタの相性がいいのか
Laravelは規約（convention）が強いフレームワークです。コントローラー、モデル、マイグレーション、リクエストクラスなど、ファイルの役割と配置場所がある程度決まっています。この「型の強さ」は、AIにとって扱いやすい条件です。パターンが明確なコードほど、AIは学習した傾向から外れにくく、生成結果の再現性が上がります。
一方で、Laravelプロジェクトには、そのチーム独自のルールも積み重なっています。命名規則、使ってよいパッケージ、避けるべき書き方、独自のヘルパー関数など、規約だけでは読み取れない「暗黙のルール」です。Cursorのようなエディタは、これらのルールを明文化して渡す仕組みを持っているため、AIにチームの流儀を学習させながら使えるのが強みになります。
導入初日にやること：ルールを先に書く
コードを1行も生成させる前に、プロジェクト固有のルールを設定しておくと、以降の生成物の質が安定します。次のような項目を書いておくのがおすすめです。
- Laravelのバージョンと、使用しているPHPのバージョン
- ディレクトリ構成の方針（標準構成か、独自のドメイン分割をしているか）
- 命名規則（テーブル名・変数名・メソッド名の慣習）
- 使用を許可しているパッケージと、避けるべき書き方（生SQLを避ける、Eloquentを優先するなど）
- テストの書き方の方針（PestかPHPUnitか、カバレッジの期待値）
これらをルールファイルとしてプロジェクトに置いておくと、Cursorが提案するコードが、チームの慣習から外れにくくなります。ルールを整えずに使い始めると、標準的だけれどそのチームの流儀とは違うコードが混在し、後から見た人が読みにくいコードベースになります。チーム開発でこうしたルールをどう運用するかは、別記事でも詳しく扱っています。
@codebaseの使い方：全体を見て整合性を保つ
Laravel開発でよくある失敗は、AIに1ファイルだけを見せて生成させ、既存の他のモデルやリレーションとの整合性が崩れることです。@codebaseのような、プロジェクト全体を参照する機能を使うと、既存のモデル定義やマイグレーション履歴を踏まえた提案が返ってきやすくなります。
特に効果が出やすいのは、次のような場面です。
- 既存のモデルに新しいリレーションを追加するとき（他のモデルとの整合性を踏まえてほしい場合）
- 新しいコントローラーを、既存のコントローラー群と同じ書き方で作りたいとき
- 命名や責務の重複がないか確認したいとき
逆に、単純なバリデーションルールの追加や、既存メソッドの軽微な修正であれば、範囲を絞って指示した方が速く、意図しない変更が混ざるリスクも減ります。全体参照は便利ですが、常に使う必要はありません。
任せてよい作業、必ず人間が見る作業
比較的任せやすい作業
- フォームリクエストクラスのバリデーションルールの下書き
- 既存のパターンに沿ったCRUDコントローラーの初期実装
- テストコードのたたき台（正常系・異常系のパターン列挙）
- Bladeテンプレートの軽微な修正やスタイル調整
- エラーメッセージやログ出力の文言統一
絶対に自動承認してはいけない作業
- マイグレーションの実行そのもの — 特に本番・ステージング環境に対しては、生成されたマイグレーションを必ず読んでから、自分の手でコマンドを実行する
- 既存カラムの削除・型変更を含むマイグレーション — データ損失のリスクがあるため、内容を精査し、バックアップの有無を確認してから適用する
- 認証・権限（Gate / Policy）に関わるコード — 意図しない権限漏れが起きても気づきにくいため、必ず人間がロジックを読み、テストで確認する
- 外部APIキーや環境変数を含むコード — AIに秘密情報をそのまま入力しない。envの値は参照名だけを渡す
- 決済・在庫・数量など、事業に直結するロジック — エッジケースの見落としが実害につながるため、生成コードをレビューなしで適用しない
AIの提案を「差分（diff）」として確認できる機能がある場合は、必ず差分単位でレビューしてから適用してください。ファイル全体を一括で受け入れる操作は速いですが、意図しない箇所の変更を見逃すリスクも同時に受け入れることになります。
レビューループの作り方
個人開発でもチーム開発でも、次のような小さなループを回すと、AI活用のスピードを落とさずに品質を保てます。
- タスクを小さく分解してから指示する（1コミットで1つの意図に収まる範囲）
- 生成結果を差分で確認し、意図しない変更が混ざっていないかを見る
- 既存のテストを実行し、通ることを確認する。無ければ最低限のテストを先に生成させておく
- コミットメッセージも含めて、人間が読める形で残す
- チーム開発の場合は、AI生成であっても通常のプルリクエストレビューを省略しない
特に5番目は重要です。「AIが書いたから大丈夫」という空気ができると、レビューの質が下がります。生成物であっても、人間が書いたコードと同じ基準でレビューする、という原則を崩さないことが、長期的にコードベースの健全性を守ります。
補完モードとエージェントモードの使い分け
Cursorのようなエージェント型エディタには、1行ずつの補完を受け取る使い方と、まとまった指示を出して複数ファイルにまたがる変更を任せる使い方の、2つの粒度があります。Laravel開発では、この2つを場面で切り替えるとムダが減ります。
- 補完中心でよい場面 — 既存メソッドの延長で書く、型ヒントを揃える、既存パターンの繰り返しが多い実装
- エージェント（自律的な複数ファイル編集）が向く場面 — 新しいリソース（モデル・マイグレーション・コントローラー・ルーティング）をまとめて追加する、既存の命名規則を複数ファイルに一括反映する
エージェントモードは複数ファイルを一度に変更できる分、レビューの手間も増えます。変更されたファイルの一覧を必ず確認し、意図していないファイルが含まれていないかをチェックする一手間を、スピードと引き換えに省略しないことが重要です。
よくある失敗
- ルールファイルを整備せずに使い始める — 最初の数ファイルが標準的すぎる/チームの流儀と違うコードになり、後から手直しが増える
- マイグレーションを確認せず一括適用する — カラムの削除や型変更が混ざっていた場合、データを壊すリスクがある
- 大きすぎる指示を一度に投げる — 「認証機能を全部作って」のような広すぎる指示は、レビューしづらい大きな変更を生む。機能単位でさらに分割して依頼する
- テストを書かせずに機能追加だけを繰り返す — 後から回帰バグに気づきにくくなる。機能追加とテスト追加をセットで依頼する
まだ向いていない場面
すべての開発作業がAIエディタとの相性が良いわけではありません。極端に古いレガシーコードで規約が崩れている場合や、社内独自の複雑な業務ロジックが暗黙知として存在する場合は、AIの提案がその暗黙知を踏まえられず、見た目は良いが実態とずれたコードを出すことがあります。こうした場面では、AIに頼る範囲を狭め、既存コードの読解と設計判断は人間が主導する方が安全です。同様に、パフォーマンスチューニングやN+1問題の解消のように、実際のクエリログや計測結果を見ないと正しい判断ができない作業も、AIの提案をそのまま適用するのではなく、計測結果と照らし合わせながら判断してください。
まとめ：次にやる1アクション
まずは、今のLaravelプロジェクトのルールを、命名規則・ディレクトリ構成・禁止事項の3点だけで簡単にまとめ、ルールファイルとして置いてみてください。それから、比較的リスクの低いバリデーションクラスやテストコードの生成から試すと、AIエディタの実力と限界が具体的に見えてきます。マイグレーションと認証周りは、最初から「必ず自分で読む」対象として扱ってください。
※ 本記事の内容は執筆・検証時点の一般的な使い方です。Cursorの機能・料金プランは変更されることがあるため、導入の判断をする際は公式情報を確認してください。
