0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Cursorに「ここだけ直して」はどこまで伝わる?3種類の修正依頼を比較してみた

0
Posted at

はじめに

こんにちは。

今回は、Cursorにコードの修正を頼むときの、

「ここだけ直してほしいとき、どこまで細かく伝えればいいんだろう?」

という疑問について、実際に試してみました。

以前、Cursorに修正を頼んだとき、こちらの指示が曖昧で、意図していなかった箇所まで変更されることがありました。

一部分を直してほしかっただけなのに、ほかの処理にも変更が入っていて、「そこは変えなくてよかったんだけど……」となってしまう感じです。

そんな経験もあって、修正を依頼するときには、

  • 必要最小限の変更にしてください
  • 関係のない箇所は変更しないでください
  • この機能の動作は維持してください

といった条件を、どこまで書けばよいのか気になるようになりました。

ただ、変更してほしくない部分を毎回すべて書こうとすると、ちょっとした修正でも依頼文が長くなってしまいます。

変更する場所をはっきり伝えるだけで十分なのか。それとも、変更しない部分まで具体的に書いたほうがよいのか。

そこで今回は、小さなアプリを用意して、3種類の依頼文で修正結果を比較してみました。

まずは簡単なカウンターで試してみた

最初に用意したのは、「+」で数字が1増え、「-」で1減り、「リセット」で0に戻るカウンターです。

数字の上限は10という仕様ですが、検証用に「+」を押し続けると11以上になってしまう不具合を残しました。

この不具合に対して、三種類の頼み方で修正を依頼しましたが、
結果としては、3条件とも回答に示された修正コードは同じでした。

今回は直す場所も方法も明確で、課題が簡単すぎたため、違いが出にくかったのかもしれないと思いました。

なのでこれは予備実験とし、次は共通の処理を変更すると、ほかの表示にも影響するアプリで、指定した範囲だけを変更できるか試すことにしました。

今回使った買い物アプリ

HTML・CSS・JavaScriptの3ファイルで、商品一覧、カート、購入履歴を表示するアプリを用意しました。

スクリーンショット 2026-09-24 231331.png

商品はキーボードが12000円、マウスが3500円、モニターが28000円。カートへの追加、購入、履歴の保存ができる構成です。

価格表示には、3つのエリアで同じ関数を使っています。

function formatPrice(value) {
  return value + "円";
}

今回の変更内容は、商品一覧だけを3桁ごとのカンマ区切りにすることです。

表示場所 修正前 期待する修正後
商品一覧 12000円 12,000円
カート 12000円 12000円
購入履歴 12000円 12000円

共通の関数をそのままカンマ区切りに変更すると、カートや購入履歴の表示まで変わります。商品一覧に限定するには、どの処理を変えるか判断する必要があります。

なお、これは既存のバグを直す課題ではなく、表示仕様を一部だけ変更する課題です。

比較した3種類の依頼文

比較は、同じ修正前コードを用意し、条件ごとに別フォルダ・新しい会話で同モデルを使用し実行する手順で進めました。各条件の最初の修正結果を比較し、追加の修正依頼は行っていません。

A:短く依頼する

商品一覧の価格表示だけを、3桁ごとのカンマ区切りに変更してください。

B:「必要最小限」を追加する

商品一覧の価格表示だけを、3桁ごとのカンマ区切りに変更してください。

必要最小限の変更にとどめ、関係のない箇所は変更しないでください。

C:維持する仕様を具体的に書く

商品一覧の価格表示だけを、3桁ごとのカンマ区切りに変更してください。

カート・購入履歴の価格表示、金額の計算、保存データ、画面の色や配置は変更しないでください。

3条件とも、最初から「商品一覧だけ」と指定しています。比較したいのは、対象を限定した依頼に、さらに制約を追加すると何が変わるかです。

結果:表示は同じ、実装方法は違った

A:商品一覧専用の関数を追加

Aでは、次の関数が追加されました。

function formatProductListPrice(value) {
  return value.toLocaleString("ja-JP") + "円";
}

商品一覧を描画するrenderProducts()内の1行だけが、この関数を呼び出す形に変わりました。

${formatProductListPrice(product.price)}

共通のformatPrice()は変更されず、カートと購入履歴は元の表示を保っています。短い依頼でも、商品一覧専用の処理を分ける判断ができていました。

B:表示箇所の1行だけを変更

Bでは、新しい関数を作らず、商品一覧の価格表示を直接変更しました。

<span class="card-price">${product.price.toLocaleString()}円</span>

元のJavaScriptとの差分は、この1行だけです。今回の3条件では、Bが最も小さい変更になりました。

Aと異なり、toLocaleString()の引数に"ja-JP"は指定されていません。確認したブラウザ環境では、期待どおりカンマ区切りで表示されました。

C:Aとほぼ同じ修正

Cでも、商品一覧専用の関数が追加されました。

function formatProductPrice(value) {
  return value.toLocaleString("ja-JP") + "円";
}

商品一覧の呼び出し先だけを変更する方法で、Aとは関数名が違うものの、実質的に同じ修正でした。

比較項目 A:短い依頼 B:必要最小限 C:維持する仕様を明記
実装方法 専用関数を追加 表示箇所で直接変換 専用関数を追加
変更範囲 関数追加+1行変更 1行変更 関数追加+1行変更
"ja-JP"の指定 あり なし あり
カート・履歴の処理変更 なし なし なし
計算・保存処理の変更 なし なし なし

この表のコード比較は、修正前後のscript.jsの差分に基づいています。

実際の画面と保存動作も確認した

回答文だけでなく、ブラウザでも次の動作を確認しました。結果は3条件とも問題ありませんでした。

  • 商品一覧は「12,000円」「3,500円」「28,000円」になる。
  • カートと購入履歴は、カンマなしの表示を維持する。
  • キーボードとマウスを1個ずつ追加すると、合計は「15500円」になる。
  • 購入するとカートが空になり、購入履歴が追加される。
  • 再読み込み後も購入履歴が残る。

今回分かったことと、まだ分からないこと

一番の発見は、今回のアプリでは、短い依頼でも変更範囲を守れたことでした。

ただし、Aも単に「価格をカンマ区切りにして」と頼んだわけではありません。「商品一覧だけ」という指定は、3条件すべてに含まれています。

また、Bは最も小さい変更でしたが、これだけで「必要最小限と書けば変更量が減る」とは言えません。各条件1回のため、指示の効果と生成結果のばらつきを切り分けられないからです。

A・Cの関数追加も、商品一覧の表示を分けるための変更です。変更行数が多いという理由だけで、余計な修正とは判断していません。

今回の検証は、A・B・Cすべて「Composer 2.5 Fast」を使用し、同じ修正前のコードを用意して、別フォルダ・新しい会話で行いました。

ただし、各条件1回ずつの比較なので、修正方法の違いが依頼文によるものか、生成結果のばらつきによるものかは判断できません。

また、今回使ったのはHTML・CSS・JavaScriptの3ファイルで構成された小さなアプリです。処理のつながりを把握しやすく、変更対象も限られていたため、短い依頼でも意図が伝わりやすかった可能性があります。

そのため、今回の結果だけで「細かい指示は不要」とは言えません。多数のファイルや機能が関係するアプリでは、変更の影響範囲が広がり、維持したい仕様を具体的に伝える必要性も変わってくると考えています。

まとめ

今回は、Cursorへの依頼の詳しさを3段階に変え、商品一覧の価格表示だけを変更する実験を行いました。

以前、曖昧な指示で意図しない箇所まで変更された経験がありましたが、今回の検証では、「商品一覧だけ」という短い依頼でも変更範囲を守れており、条件を詳しく追加した場合との明確な差は確認できませんでした。

一方、コードの直し方には違いがありました。専用の関数を追加する場合と、表示の1行だけを変更する場合に分かれ、同じ表示結果でも実装方法は異なっていました。

ただし、今回は3ファイルで構成された小さなアプリで、各条件1回ずつの比較です。処理のつながりが分かりやすかったことも、短い依頼で対応できた理由の一つかもしれません。

実際の開発では、変更の意図を取り違えられないよう、変更対象に加えて、維持したい仕様や触れてほしくない処理も具体的に書くことは大切だと考えています。ただ、今回のように短い指定で伝わるケースもあり、どこまで詳しく書く必要があるかは、作業の規模や複雑さによって変わりそうです。

今後は、機能やファイルが多いアプリでも、一言の依頼で意図した範囲だけを変更できるのか、詳しい依頼にすると修正範囲や手戻りに違いが出るのかを調べてみたいです。

そして、詳しく指示を書いた場合でも、修正後の確認は必要です。依頼した変更ができているかに加えて、変えたくなかった部分が保たれているかも、コードの差分と実際の動作で確認することは続けていきたいと感じました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?