フリーランスでコーディングも自分でやる場合、エディタ選びは生産性に直結します。CursorはVS Code系の操作感に、AI補完が載ったエディタとして、制作現場でも名前が出るようになってきました。私もWordPress周りや静的コーディングで使っています。
ただし、初期設定をそのままにすると、AIの提案がプロジェクトの規約とズレたり、意図しないファイルまで触られたりすることがあります。この記事では、制作現場でCursorを「毎日使える道具」にするための初期設定と運用ルールに絞って書きます。
先に結論
- 向いている人: コーディングを自分で行うWebディレクター・デザイナー、小〜中規模の案件を一人で回す人、VS Code経験者
- 向いていない人: チームで厳密なIDE統一が必須でルール策定が追いついていない現場、AI補完を一切使わない方針のクライアント案件（要確認）
- 私のおすすめ:
.cursor/rulesでプロジェクトごとのルールを先に書く。AIは補助、最終判断は人間。クライアント案件は秘密情報を渡さない前提で設定する
この記事には、Google AdSense による広告およびアフィリエイトリンクが含まれる場合があります。紹介経由で購入や申し込みがあると、私に紹介料が入ることがあります。
私は実装直前の手戻りを減らすために、Cursorの手順を短く固定しています。
CursorとVS Codeの関係
CursorはVS Codeをベースにしています。拡張機能の多くはそのまま使え、キーバインドも移行しやすい。VS Codeから乗り換える場合、設定のインポート機能を使うとショックは小さいです。
違いは、AIチャット・エージェント・インライン補完が標準で深く統合されている点。単なる「補完が強いエディタ」ではなく、リポジトリ全体を文脈にした提案ができるのが特徴です。その分、何をAIに見せるかの設計が重要になります。
初回インストール後の設定チェックリスト
| 項目 | 推奨 | 理由 |
|---|---|---|
| アカウント | 個人用と仕事用を分けるか検討 | 利用規約・データの扱いを把握 |
| テーマ・フォント | VS Codeから移行 | 操作感の連続性 |
.gitignore |
秘密情報・.env を除外 |
AIや共有に漏らさない |
.cursor/rules |
案件ごとに作成 | コーディング規約を固定 |
| 拡張機能 | Prettier、ESLint、言語別 | 保存時フォーマットを統一 |
| ターミナル | プロジェクトのNode/Python版 | ビルドエラーを減らす |
プロジェクトルール（.cursor/rules）の書き方
制作現場で一番効くのは、プロジェクトルートのルールファイルです。例えば次のような内容をMarkdownで書きます。
- 使用しているフレームワーク（WordPressテーマ、Laravel、静的HTMLなど）
- 命名規則（BEM、FLOCSSのプレフィックスなど）
- 触ってはいけないディレクトリ（
vendor/、本番設定など） - コメント・コミットメッセージの言語（日本語など）
- テストの有無と実行コマンド
ルールは長すぎるとAIが拾いきれないので、その案件で外しやすい点だけに絞るのがコツです。私は「最小限の修正」「既存の命名に合わせる」「.envは読まない」を毎回入れています。
AI補完の運用ルール
AIは速いですが、無条件に信頼すると事故ります。私が現場で守っているルールです。
ルール1: 提案は必ず diff を読んでから適用
一括適用は便利ですが、関係ないファイルまで変わることがあります。
ルール2: 秘密情報をチャットに貼らない
APIキー、クライアントの本番URL、未公開の個人情報は禁止。.env はgitignoreとルールの両方でブロック。
ルール3: クライアント案件のコードを学習に使うかは契約と規約で確認
Cursorのデータポリシーは公式を確認。不安な案件はオフライン相当の使い方や、AI機能を限定する選択もあります。
ルール4: 生成コードはリントと動作確認を通す
動く見えても、セキュリティやアクセシビリティは別問題。保存時フォーマットと手動テストをセットに。
ルール5: 複雑な設計は先に人間が方針を書く
いきなり「全部作って」より、ファイル一覧や関数の責務を短く指示した方が、手戻りが減ります。
フリーランス案件でのフォルダ構成
案件ごとにワークスペースを分けます。複数クライアントを1ウィンドウで開くと、文脈が混ざるリスクがあります。
~/work/
client-a-wp-theme/ ← Cursorで開く単位
client-b-lp/
personal-blog/
各フォルダに .cursor/rules を置き、クライアント名や触る範囲を明記。未公開案件のスクショや実データCSVはリポジトリに入れない、は鉄則です。
拡張機能のおすすめ構成（制作向け）
案件によりますが、よく使う組み合わせです。
- Prettier: 保存時フォーマット
- ESLint: JavaScript/TypeScriptの静的解析
- PHP Intelephense: WordPressテーマ作業時
- Tailwind CSS IntelliSense: Tailwind案件
- GitLens: 変更履歴の確認
- Live Server または Browser Sync: 静的HTMLのプレビュー
AIに任せる部分と、人間がルールで縛る部分の境界を、拡張機能で固めるイメージです。
ターミナルとビルドの統一
Cursor内ターミナルで npm run dev や composer install を回す日が多いです。プロジェクトごとに .nvmrc や engines を書いておくと、AIもバージョンを誤りにくくなります。
Docker案件なら、Makefile の make up など既存のコマンドをルールに書いておく。「勝手に新しいビルドを追加しない」も入れておくと、余計な package.json 改変を防げます。
失敗しやすいパターン
ルールなしで大規模リファクタを依頼
差分が巨大になり、レビュー不能。小さな単位で依頼。
.env をコミットしたままAIに読ませる
git履歴に残る。即ローテーションとignore。
クライアントの本番DBダンプをワークスペースに置く
個人情報違反のリスク。架空データのみ。
VS CodeとCursorで設定が二重管理
メインをCursorに決めたら、設定の正本を一つに。
AIのコードをそのままクライアント納品
著作権・ライセンス・品質の責任は自分側。必ず確認。
チーム・クライアントとのすり合わせ
一人制作なら自分でルールを決められます。チームやクライアントのリポジトリを触る場合は、次を確認してください。
- リポジトリにAI利用の方針があるか
- 秘密情報の取り扱い
- コミットの署名者・メッセージ規約
- ブランチ戦略（main直接禁止など）
方針がなければ、自分の作業範囲だけでもルールファイルをPRで提案する、という動きもできます。
コストの目安
Cursorは無料枠と有料プランがあります。執筆時点（2026年5月・日本時間）の料金は公式サイトで確認してください。フリーランスで毎日使うなら、有料プランを事業経費として計上できるかは、会計ソフトの「通信費」「消耗品費」「支払手数料」など、自分の区分けルールに従います。
時給換算で、1日30分のコーディング時間が削れるなら、月額料金は回収しやすい部類です。逆に、AIに頼りすぎてレビュー時間が増えるなら、使い方の見直しサインです。
ショートカットと生産性の基本設定
VS Code系なので、ショートカットは慣れたものをそのまま使えます。私がよく使うのは、コマンドパレット（Cmd+Shift+P）、ファイル検索（Cmd+P）、シンボル検索（Cmd+Shift+O）、ターミナル表示（Ctrl+`）です。AI機能のショートカットは公式ドキュメントで確認し、既存の習慣と衝突しないように割り当てます。
マルチカーソル、行移動、リネーム（F2）は、AIに任せる前に人間の手でやった方が速いことも多いです。AIは「まとまったブロックの生成」向き、細かい編集は従来のエディタ操作が強い、という役割分担が現場では回りやすいです。
WordPressテーマ案件での具体例
テーマの functions.php を分割読み込みしている案件では、ルールに「新規関数は functions/ 配下の適切なファイルに追加」「functions.php 本体は require のみ」と書きます。テンプレートは page/ や partial/ の既存構造に合わせる。ACFを使っているなら、フィールド名の命名規則も1行でよいので明記。
AIに「新しいカスタム投稿を追加して」と頼む前に、既存の add_customposts.php の書き方をルールに貼ると、提案の形が揃います。これはCursorに限らず、どのAIエディタでも効くテクニックです。
Laravel・静的HTML案件での違い
Laravel案件では、app/Http や resources/views 以外を触らない、マイグレーションは勝手に作らない、という線引きが重要です。静的HTML案件では、FLOCSSのプレフィックスや、画像パスの慣習をルールに書きます。
同じ人が複数スタックを触ると、AIも混乱しやすい。ワークスペースを開き直す＝ルールが切り替わる、と意識するとミスが減ります。
バックアップとGitの習慣
AIがファイルを変更したあとは、こまめにコミットします。メッセージは日本語で「なぜ」を短く。大きなAI生成の塊を1コミットにまとめると、戻しにくいので、機能単位で分けます。
リモートにpushしていない変更は、マシン故障で消えます。クライアント案件は特に、作業終了時にpushするルールを自分に課すと安心です。
セキュリティチェックリスト（制作向け）
.envはgitignoreとCursorルールの両方- 本番のDBダンプ・実CSVはワークスペース外
- APIキーをチャットに貼らない
- クライアントの未公開URLは匿名化して説明
- 依存パッケージの追加は理由を残す
フリーランスは一人で権限が広い分、自分で線を引く必要があります。
モデルとプランの選び方（一般論）
CursorのAI機能はプランと利用量によって変わります。執筆時点の料金体系は公式を確認してください。毎日フルでエージェントを回すなら有料、週に数回の補完なら無料枠で試す、という切り分けが現実的です。
モデルを選べる場合、複雑なリファクタは高性能、単純な補完は軽量、と使い分けるとコストと速度のバランスが取れます。案件の機密レベルが高いほど、クラウド送信に慎重になる、という判断もあります。
チームにCursorを導入するときの話題
複数人で同じリポジトリを触る場合、.cursor/rules をリポジトリにコミットして共有するのが自然です。AI利用の可否、生成コードのレビュー義務、秘密情報の定義を、READMEかCONTRIBUTINGに書く。フリーランスがクライアントのGitに入る場合も、同様の確認をします。
トラブル時の切り分け
提案がおかしい → ルールを足す、コンテキストを減らす、依頼を小さくする。
拡張機能が効かない → VS Code互換の拡張が有効か、ワークスペース設定を確認。
遅い → 開いているフォルダが巨大（node_modules等）なら、検索除外を設定。
切り分け表を自分用に1枚作っておくと、イライラが減ります。
日次・週次の運用ルーティン
朝: ワークスペースを1案件だけ開く。余計なフォルダを閉じる。
作業中: AI依頼はチケット1件ずつ。diff確認してから保存。
終了時: commit & push。未保存のAI提案は破棄かコミットを決める。
週1: 拡張機能の更新、Cursor本体の更新、ルールファイルの見直し。
ルーティンが固定されると、AIの有無に関わらず制作速度が安定します。
クライアント別ワークスペースの例
クライアントごとにフォルダを分け、それぞれに .cursor/rules を置きます。WordPress案件ならテーマ規約、静的HTMLならFLOCSS、Laravelなら触る範囲の制限。フォルダ名に実名を使うか匿名IDにするかは、バックアップとチャットの習慣次第です。
学習リソースの扱い
公式ドキュメントを正とし、ブログ記事のプロンプト例は参考程度。案件のルールは、自分のリポジトリに書いたものが最優先。他人のルールをコピペする場合も、スタックが違えば削る勇気を。
プロンプトの書き方（制作向けの型）
AIに依頼するときは、次の4行テンプレが使いやすいです。
- 何をしたいか（1文）
- 触っていいファイル・触るなファイル
- 既存の命名・スタイルの参照先
- 完了条件（テストコマンド、表示確認など）
長文の願望リストより、短い制約付きの方が、提案のブレが減ります。
エージェント機能を使うときの線引き
エージェントに複数ファイルを自動編集させる機能は強力です。クライアント案件では、ブランチを切り、変更範囲を限定し、終わったら必ずdiff全体を読む。個人の実験リポジトリで慣れてから本番に持ち込む順番が安全です。
更新と互換性
Cursorは更新頻度が高いです。案件直前にメジャーアップデートするより、余裕のある日に更新し、拡張機能の互換を確認。更新でAI挙動が変わることもあるので、ルールファイルの文言を少し足す対応が続きます。
他エディタとの併用
一部の作業だけIntelliJやPhpStorm、Xcodeなど別IDEを使う人もいます。その場合も、正本のGitは一つ。Cursorで編集したあと別IDEで開くと、フォーマット差分が出るので、PrettierやEditorConfigをリポジトリに入れて揃えます。
よくある質問
Q. VS Codeから完全に乗り換えるべきですか？
A. 必須ではありません。CursorはVS Codeの延長として使えます。AI補完を試したい案件だけCursor、という併用も現実的です。設定同期の手間を減らすなら、メインを一方に決める方が楽です。
Q. WordPressテーマ制作向けの設定はありますか？
A. PHP Intelephense、WordPress用スニペット、Prettier（可能な範囲）、.cursor/rules に「コアを触らない」「テーマディレクトリのみ」と書く、が基本です。ACFや独自関数のプレフィックスもルールに入れると、AIの提案が既存コードに寄りやすくなります。
Q. オフラインでは使えますか？
A. AI機能はネットワークが必要です。オフラインではVS Code相当の編集機能に近い動きになります。機内や回線不安定な環境では、AI依存度を下げておくか、ローカルで完結する作業に切り替える想定が必要です。
Q. 生成コードのライセンスはどうなりますか？
A. 利用規約と法務は公式ドキュメントを参照してください。クライアント納品物として問題ないかは、契約と社内方針次第。不安な場合はAI生成部分を明示し、人間がレビュー・修正したうえで納品する運用が無難です。
オフライン・低回線環境での代替
回線が不安定な日は、AI機能を使わず従来のコーディングに切り替え。事前にドキュメントをローカルに保存し、オフラインでも参照できるようにする。Cursorに限らず、クラウド依存のツールはバックアッププランを持つと、締切前の焦りが減ります。
記事・ブログ執筆でのCursor利用
Markdown執筆でも、ルールで語り口や禁止事項を書けます。ただし、事実関係は自分で確認し、体験と推測を分けて書く。アフィリエイト記事では、プレースホルダリンクを壊さないよう、AIに一括置換させない方が安全です。
補足
Cursorは日々進化するツールです。ルールファイルとGitの習慣があれば、エディタが変わっても制作の芯は残ります。AIは下書きと修正案の供給源と割り切り、公開前の品質と秘密情報の管理は人間が担う。この線引きができれば、フリーランスの現場でも無理なく使い続けられます。
Cursorは日々進化するツールです。ルールファイルとGitの習慣があれば、エディタが変わっても制作の芯は残ります。AIは下書きと修正案の供給源と割り切り、公開前の品質と秘密情報の管理は人間が担う。この線引きができれば、フリーランスの現場でも無理なく使い続けられます。
Cursorは日々進化するツールです。ルールファイルとGitの習慣があれば、エディタが変わっても制作の芯は残ります。AIは下書きと修正案の供給源と割り切り、公開前の品質と秘密情報の管理は人間が担う。この線引きができれば、フリーランスの現場でも無理なく使い続けられます。
Cursorは日々進化するツールです。ルールファイルとGitの習慣があれば、エディタが変わっても制作の芯は残ります。AIは下書きと修正案の供給源と割り切り、公開前の品質と秘密情報の管理は人間が担う。この線引きができれば、フリーランスの現場でも無理なく使い続けられます。
Cursorは日々進化するツールです。ルールファイルとGitの習慣があれば、エディタが変わっても制作の芯は残ります。AIは下書きと修正案の供給源と割り切り、公開前の品質と秘密情報の管理は人間が担う。この線引きができれば、フリーランスの現場でも無理なく使い続けられます。
Cursorは日々進化するツールです。ルールファイルとGitの習慣があれば、エディタが変わっても制作の芯は残ります。AIは下書きと修正案の供給源と割り切り、公開前の品質と秘密情報の管理は人間が担う。この線引きができれば、フリーランスの現場でも無理なく使い続けられます。
綺麗さより再現性——Cursorではそこを優先しています。
まとめ
Cursorを制作現場で使うなら、エディタの設定より先に「プロジェクトルール」と「AIの使い方の線引き」を決める。秘密情報を守り、diffを読み、小さく依頼する。VS Codeからの移行は容易なので、試すコストは低いです。
次にやることは、今動いている案件のルートに .cursor/rules を1ファイル作り、触る範囲と命名規則を10行で書くこと。それだけで、翌日からのAI提案の精度が変わります。
