Cursor Composer 実務実践編
本記事では、AIコードエディターこと「Cursor」のとりわけ Composer を用いた 実務 での活用法について、お伝えしていきます。
私自身、日々のコーディングに関する業務は Cursor を利用し、とりわけ Composer によるコード生成を日常的に活用しています。コーディングをするとき、6〜7割程度は Composer に委ね、残りの部分で生成されたコードをレビューしたり、手作業でコーディングするようなスタイルになってきています。
Cursor がアップデートするたびに、私の仕事のスタイルが変わっていくほど、生成AIによるコーディング支援は強力で、目を見張るものがあります。一方で、同じように Cursor を使って開発をしている人の中では、一部の機能(Cursor Tabや⌘+K)のみを活用している方もいらっしゃるようです。
そんな方が、Composer の使い方を理解し、小さい個人プロダクトではなく、ある程度のチームで構成される中規模〜のプロダクト開発で、活用できることを本記事では目指していきたいと思います。
はじめに
Composer とは
Composer は Cursor に搭載されているAIコード生成機能です。⌘+I(Windows では Ctrl+I)で起動でき、自然言語で実装したい内容を伝えると、コードを生成してくれます。
Composer の特徴:
- プロジェクトのコンテキストを理解し、既存のコードベースに沿った実装を提案
- コードの生成だけでなく、テストの作成やリファクタリングにも対応
- エージェントモードでは、コマンドの実行やエラーの自動修正なども可能
- Claude 3.5 Sonnet などの高性能な言語モデルを活用
通常のAIアシスタントとの大きな違いは、プロジェクト全体を理解した上でコードを生成できる点です。ファイル間の依存関係やプロジェクトの規約に従った実装を提案してくれるため、より実用的なコード生成が可能です。
こんな方に本記事をおすすめ
- Cursor の有料ライセンスを持っているけど、活用しきれていないと感じる方
- 一度 Composer を使ってみたけど、やめてしまった方
- 小規模PJや新規PJなら有用だけど、規模が大きくなると使えないのでは?と感じている方
生成AIを用いた実務上でのComposerの期待値
「Cursor アシストが強い」「6〜7割程度は生成AIがコードを書いている」といった前振りをしましたが、一度みなさんと期待値を揃えて置かなければなりません。
Composer は使い方によっては、精度高くコードを生成することができますが、反対に期待した結果を得られないことも多々あります。また、(自分が思い描いた通りの)完璧なコードを 一つのプロンプトで生み出すことはそうそうありません。
必要十分なコンテキストを与え、何度かプロンプトでやり取りをして、ようやく実現したかったことに対して、6~7割程度実現できた。というくらいの期待値の設定がよいかと思います。
もちろん、9割程度満足のいく結果を得られることもありますが、過度な期待は避けたほうが導入としては入りやすいことをお伝えしておきます。
Composer を活用する効果
期待値のところで完璧ではないことを述べた分、プログラミングが得意な方は「自分で書いたほうが速い!」となったかと思います。
私も一時は Composer で指示を出し、好みの成果物が出来上がらずに、自分で一から仕上げる。というのをやってきました 😂
うまくいくときもあれば、うまくいかないときもあるのですが、Composer を使ってある程度確度の高いコードを生成できると、脳内負荷も下がり、作業後の疲労感が全然違います。
例えばですが、1日に1本 PullRequest 送るのがやっとだったのが、2,3本 PullRequest を送ってもそこまで疲れない。そんな感覚を得られると思います。
コード生成部分の大部分を Cursor に委ねられると、コーディングに限った生産性は上がりますし、その負荷を Cursor に預けられるのがメリットです。
Composer を効果的に使うための初期設定
前置きが長くなりました。ここからが Composer の活用の仕方になります。
まずは、初期設定からです。
以下の二点は、プロンプトを送るたびに付与されるコンテキストとなります。生成されるコードの品質を決める大部分になりますので、設定してみてください。
Rules for AI
Cursor でプロンプトを送る際に付与するグローバルなコンテキストの設定です。
「Cursor Settings」-> 「General」に設定できる箇所があります。
どんなプロジェクトやリポジトリを開いていても、Rules for AI に書かれている内容はコンテキストとして加味されます。
Rules for AIで書くとよい内容は
- プロンプト全体でやってほしいこと
- ex. 日本語で返事をしてほしい
- プロンプトを受け取ったときのタスクの分解の仕方
- やってほしくないこと・禁止事項
- 個別でやってほしいこと
といった内容になります。
プロンプトを受け取ったときのタスクの分解の仕方 については、きのぴーさんのこのポストがとても参考になります。
これを踏まえて、私の場合はこのような Rules for AI を設定しています。(長いので gist のリンクを置いておきます)
.cursorrules
Cursor でプロンプトを送る際に付与するプロジェクト固有のコンテキストの設定です。
リポジトリの直下に .cursorrules
というファイルを置き、そこにコンテキストを書いていきます。
.cursorrules で書くとよい内容は
- プロジェクトの構成
- 使用している技術
- コーディングスタイル
- フォルダ構成
といった内容になります。こういったもの以外にも、ライブラリを追加する条件など、プロジェクト特有のルールがあれば、ここに書くと良いでしょう。
また、Rules for AI と .cursorrules がそれぞれ矛盾しないように記述されていることも重要です。
Composer を使うときのコツ
初期設定を終えたら、Composer を効果的に使えるようになっていると思います。
Composer は ⌘+I で起動できます。
モデルは今のところ「Claude3.5 sonnet」が安定してよい成果を出しているように感じます。
「normal/agent」となっているところで、エージェントモードに切り替えることが可能です。
agent モードで Composer を使うことで、プロンプトで与えたタスクを分析・解釈して、適切にツールを使い分けながら、タスクを完了へと運んでくれます。ターミナルでのコマンド操作やエラーを検知して、自動修正なども走り、自走してくれます。(normal モードを使うシーンは正直思い浮かばないです...)
適切なコンテキストを渡す
実装したい内容を実際に行う上でのコンテキストを渡していきます。
ファイルのコンテキスト
テキストフィールド上部にある 「Add Context」や、テキストフィールド内で @File
と打って、Composer に前提情報や修正してほしいファイルの情報を送ることができます。
中規模〜大規模のプロジェクトほど、ファイルによるコンテキストの付与は効果が高いように思います。
この規模のプロジェクトはファイルもフォルダも数が多くなるため、抽象的なプロンプト(ex. XXX 画面を作りたい)を送ってもうまくいかないことが多いです印象です。
- このファイルにこういう実装をしてほしい
- このファイルを参考にして、実装をしてほしい
など、使い方は様々です。
公式ドキュメントのコンテキスト
テキストフィールド内で @Docs
と打つと、Cursor がプリセットで持っている公式ドキュメントや、自身が取り込んだドキュメントをコンテキストとして渡すことができます。
ライブラリを用いて、実装してほしい。不具合を修正してほしい。というケースで役立ちます。
その他にも様々なコンテキストが渡せます。 Composer のテキストフィールドに @
と打ってみて、いろいろと試してみてください。
スクリーンショットを添付する
とりわけ画面に関する動きを実装してもらうときには、スクリーンショットを添付することで説明を省いたり、正確に物事を伝えることができます。
「このようなデザインにしてほしい」「こんなエラーや不具合が出ている」というケースなどに使えます。
タスクは検査可能な完了条件を書く
プロンプトを入力し、エンターキーを押せば、agent が走り始めます。
1つのタスクのみをプロンプトとして送ることもできますが、開発の一連の流れをプロンプトとして送ることで、agent がより自走しやすくなります。
🤷♀️
path/to/file に XXX という実装をしてください
🙆
path/to/file に XXX という実装をしてください。その後、対応するテストを書いてください。
また、テストを実行し、テストが成功することを確認してください。
前者では、実装のみでタスクが完了しますが、普段の開発ではテストを書くプロジェクトも多いと思います。
後者のように、実装とテストをセットにしてプロンプトを送ることにより、テストの実装とそれが通ることまで一気に実現してくれます。(もちろん、そのあと、生成されたコードやテストが正しいかを自身がレビューする必要はあります。
また、この検査可能な完了条件はリファクタリング時にも有効です。
すでにテストがあるという前提で実装をよりシャープにし、テストが通ることを保証させれば、より安全にリファクタリングを行うことができます。
具体と抽象を調整する
プロンプトを送り、期待する結果が得られないとき、その指示が「具体的すぎて効果的な修正をできていない」ケースと「抽象的すぎて狙った修正ができていない」ケースに直面することがあります。
さじ加減が非常に難しいところですが、期待する結果が得られないときは、プロンプトとして送っている内容の具体と抽象を加減して再度プロンプトを送るとうまくいくことがあります。
具体的なプロンプト
Aというファイルに、XXXのときにYYYするボタンを追加して。
そのボタンを押したときに、モーダルを開き、データを作成できるようにして。
抽象的なプロンプト
ユーザーがZZZの操作をできるようにして。
1タスク-1Composer
一つの Composer で何度もやり取りをしていると、コンテキストも膨らみ、期待する結果を得られないことがあります。
1つのタスクを完了し、また別のタスクに移る場合には、Composer を新規作成するとコンテキストもリセットされるため、不要なコンテキストを渡さずに済みます。
Composer 起動時に狙ったタスクが完了できたのなら、次に任せるタスクはComposer を新規作成してから始めましょう。
Composer でできること/できないことを把握する
上記のようなことを留意して Composer にタスクを任せようとしてもできないこともあります。
しかし、任せるタスクができるのか、できないのか、その匙加減を知るのは大変むずかしいかと思います。(小さなプロジェクトではできるのに、大きなプロジェクトではできないというのもありますし)
まずは自分自身が手動で完遂できるコーディング作業をあえて、Composer にやらせてみる。というのをおすすめします。プロンプトの内容にもよりますが、こういう指示の出し方ならいける。どんなに指示出ししてもできない。という境目がわかりやすくなります。
この境界が分かるようになると、ここは Composer でやろう。ここは手動でやろう。というのをスッと判断できるようになり、コーディング作業の効率化に繋がります。
最初は時間がかかりますが、後々レバレッジの効く作業だと思いますので、ぜひ検討してみてください。
Rules for AI / .cursorrules をメンテナンスする
Composer とやり取りをするうちに、不足していそうなコンテキストや、やってほしくない振る舞い、やってほしい振る舞いを見つけたら、都度ルールとして更新していきましょう。
これも地味に時間が掛かる作業ですが、同じくレバレッジの効く作業です。
おまけ
私が Composer 実践していることをこれまで書かせていただきました。
YOLO モード
agent モードで Composer を実行すると、コマンドを実行する際には、都度ユーザーに確認が入ります。通常だとそこで人間が介在し、エンターキーを押す必要がありますが、YOLOモードでは、agent が直接コマンドを実行します。
「Cursor Setting」-> 「Features」-> 「Enable yolo mode」 から設定できます。
もちろん、使ってほしくないコマンドはあらかじめ拒否リストに入れておくことで勝手な実行を防ぐことができます。とはいえ、YOLOモードではタスク完遂に向けてどんどん作業が進んでいきます。
git コミットや、PullRequest の作成まで一息でやってしまうことがあります。
嬉しいこともある一方でシステムに影響のあるコマンドを実行してしまう等のリスクも伴いますので、用法用量を守って利用を検討してみてください。
最後に
生成AIの活用方法や、Cursor の活用方法を、まとめて無料で見られる場所が少ない印象があり、普段私が実行している内容を記事として書かせていただきました。
この記事を読んでくださるみなさまにとって、一つでも持ち帰れる発見があると大変うれしいです 🙏
Discussion