CursorでWordPressテーマを編集する方法｜本番前に確認すること

この業務で解決したいこと

Cursorを使う目的は、AIにコードを大量に書かせることではありません。既存のファイルを理解し、変更案を小さく作り、表示やテストで確かめ、差分をレビューするまでの時間を整えることです。自然言語で依頼できても、要件、権限、公開判断、顧客への影響をAIへ丸投げすることはできません。

この記事では、非エンジニアがCursorを使い始めるときに、何を任せ、何を人が確認するかを整理します。最初から新しいサービスを作るのではなく、戻し方が分かる小さな変更から試すと、AIの提案を安全に評価できます。

Cursorを使う前に決める4つのこと

観点	決める内容	例
目的	何を改善したいか	記事ページの読みやすさを直す
対象	変更してよいファイル	特定のCSSとテンプレートだけ
確認	何で正しさを確かめるか	ブラウザ表示、テスト、差分
戻し方	問題があればどう戻すか	Git、バックアップ、以前のZIP

依頼が「いい感じに直して」だけでは、Cursorも人も結果を判断できません。対象ファイル、変えてよい範囲、完成条件、触れてはいけない情報を短く書きます。まず計画を出させ、実装前に対象が正しいかを確認するだけでも、意図しない変更を減らせます。

活用例

記事カードの余白だけを修正し、テーマZIPを検証環境へ入れて確認する。

この例では、Cursorへいきなり本番反映を依頼しません。最初に「対象ファイルと変更案を示す」「目的以外は変更しない」「確認手順を最後に出す」と依頼します。次に、人が差分を読み、ローカルまたは検証環境で確認します。期待と違うときは、変更を追加する前に戻し、依頼文か要件を修正します。

PLAN → BUILD → TEST → REVIEW の進め方

PLAN：現状、変更する場所、完了条件、触れてはいけない範囲を文章にします。Agentを使う場合も、最初は調査と計画だけを依頼します。
BUILD：変更は一つの目的に絞ります。複数の機能、ファイル、依存関係を一度に変えず、差分を読み切れる大きさに分けます。
TEST：画面、入力、エラー時の動き、既存のテストを確認します。Cursorがテスト結果を示しても、何を確認したかを人が理解します。
REVIEW：変更差分、実行したコマンド、追加された依存関係、秘密情報の混入を確認します。公開・マージ・本番操作は責任者が行います。

CursorのAgentは、検索、編集、ターミナル操作を組み合わせて作業できます。便利な反面、対象外のファイルやコマンドまで進む可能性があります。最初は承認を求める設定を保ち、計画と差分を確認する習慣を作ります。Background Agentや外部サービス連携は、権限とデータの扱いを組織で決めてから検討します。

AIへ渡す指示の型

次の5項目を揃えると、依頼の曖昧さを減らせます。

項目	書く内容	例
目的	何を良くするか	申込み導線を読みやすくする
対象	読んでよい範囲	`assets/css/article.css`のみ
制約	してはいけないこと	HTML構造と公開設定は変えない
確認	完了の条件	PC・スマホで崩れないこと
出力	最後に報告すること	変更ファイルと確認手順

たとえば「対象のCSSだけを確認し、変更案と影響範囲を先に説明してください。実装はまだしないでください」と依頼すれば、計画段階で止まれます。実装を許可するときも「変更後に差分と確認方法を示してください」と続けます。AIの回答が速いほど、依頼とレビューの型を固定する価値があります。

使う前に確認すること

リポジトリ、フォルダ、ファイルのうち、今回見せてよい範囲
APIキー、パスワード、個人情報、顧客情報を含むファイルの扱い
Agentが実行しようとするコマンドと、追加・削除・更新されるもの
画面確認、テスト、レビュー、公開を担当する人
変更を戻す手順と、想定外の動きが出たときに止める基準

Cursorのプライバシー設定、データの扱い、チーム管理、料金は変わり得ます。導入前と設定変更時には、必ず公式ドキュメントと自社の情報管理ルールを確認します。個人の試用と、チームのリポジトリやGitHub権限を扱う利用は、同じ判断ではありません。

よくある誤りと直し方

最も多い誤りは、変更の目的を決めずに大きな依頼を出すことです。「このサイトを改善して」と依頼すると、文章、CSS、テンプレート、依存関係まで広く変更される可能性があります。最初は「この見出しを二行以内にする」「このボタンの余白を確認する」のように、一つの画面・一つの目的へ絞ります。変更が正しいかを確認できたら、次の小さな変更へ進みます。

次に多いのは、AIが作ったコードを読まずに採用することです。表示が一度うまく見えても、別の画面幅、既存機能、エラー時の動き、セキュリティまで正しいとは限りません。差分で何が変わったかを確認し、テストやブラウザ確認を行います。読めない差分は受け入れず、説明を求めるか、変更単位を小さくします。

また、秘密情報を含むフォルダをそのまま開くことも避けます。設定ファイル、顧客データ、鍵、トークンは、必要最小限の範囲に分けます。チームでは、誰が閲覧でき、誰が編集や公開を承認できるかを決めます。AIの利用量ではなく、意図しない変更を止められたか、確認にどれだけ時間がかかったかを振り返ると、導入範囲を適切に広げられます。

Cursorを使わない・止める判断

Cursorは、要件が決まっていて、変更の結果を確認でき、問題があれば戻せる作業で力を発揮します。反対に、目的が決まっていない新規事業の判断、法務・会計・人事の最終判断、顧客へ影響する本番操作、障害中の緊急変更を、説明なしで任せる用途には向きません。急いでいるときほど、AIの提案を検証する時間が省かれやすいためです。

止めるべき兆候も決めておきます。対象外のファイルを触ろうとする、意味を説明できないコマンドを実行しようとする、想定外の依存関係を追加する、秘密情報や外部サービスへの送信が見える、テストが失敗する、といった場合は実装を続けません。作業を中断し、最初の計画、対象範囲、権限、バックアップへ戻ります。

「AIを使わない」という判断は、導入の失敗ではありません。人が決めるべきことと、AIが下書きにできることを分けられた状態です。まず人が十分に理解できる小さな変更で成果を確認し、その後にルール、テスト、自動化の順で広げます。Cursorを速さのためだけに使うのではなく、変更の理由と確認の記録を残すために使うと、チームでも続けやすくなります。

参考情報

CursorでWordPressテーマを編集する方法で確認したい判断基準

このテーマで大切なのは、作業量を増やすことではなく、変更の理由と確認結果を残すことです。最初の数回は、Cursorが提案した内容をそのまま採用せず、人が修正した箇所を記録します。修正が集中する部分は、要件が足りない、既存コードの前提を読めていない、または人の判断が必要な工程です。原因ごとに、依頼文、プロジェクトルール、テスト、レビューのどれを改善すべきかを分けます。

Cursor RulesやAGENTS.mdを使う場合も、長い社内規程を丸ごと入れるより、今回のプロジェクトで守る行動へ分けたほうが機能します。たとえば「変更前に対象ファイルを列挙する」「削除の前に理由を書く」「本番設定を変えない」「テストを実行できないときは理由を報告する」といった短い規則です。規則はコードと同じように見直し、守れなかった理由を次の更新へ反映します。

小さく始めるためのチェック

確認項目	最初の基準	見直すタイミング
対象範囲	一つの画面または一つの機能	差分を読み切れないとき
実行環境	ローカルまたは検証環境	本番に近い条件が必要なとき
品質	表示・テスト・差分を確認する	修正や差し戻しが続くとき
権限	必要な人だけに限定する	担当者や連携先が変わるとき

このチェックを通過した作業だけを、次の範囲へ広げます。AIの提案を断ることや、途中で作業を止めることも、失敗ではありません。確認できない変更を本番へ入れないことが、長期的にはもっとも速い改善につながります。