はじめに
ユアスタンドでハードウェア・ファームウェア開発担当をしている吉田です。
今回は私の担当している組込み開発領域において、Cursorを利用し始めて1ヶ月程度使ってみたので感想をまとめてみます。
なぜ導入したか
もともとはClineを活用していた
この記事の通り、私は元々VScode+Copliot+Clineを使っていました。
その中で我慢していた部分がいくつかありました。
- 生成スピードが少し遅い。
- 複数モデルが使えるのはメリットに感じていたが試すのが徐々に億劫になった。
- モデルごとに料金が異なり、その都度アカウント作成・支払い設定するのが面倒だった。
- (OpenRouterとか使えばいいのだろう、、、)
Cursorの良かった点✅
Cursorの基本的なメリットはもちろんですが、組込み開発ならではの良かったことを紹介します。
-
プロジェクト全体を横断的に参照してくれるため、プロンプト工数が少なくて済む！
- 参照すべきファイルやモジュール、ドキュメントを自動で探索してくれる。
- 以前(GPT)だと、モジュール間の依存関係までしっかり書く必要があったが省略できるようになった。
- 既存コードを参照して命名規則やクラス分割の規則性などを分析して、それに沿ったコードを生成してくれる。
-
Linuxのディレクトリ構造を理解した上で作業してくれる！
- systemdサービスなどの定義ファイルを適切なディレクトリに自動生成してくれる。
- 適切なファイル権限を考えてくれる。
- 断片的な権限設定ではなく、他のファイルも参照したうえで相談、コマンド実行できる。
-
仕様ドキュメントを入れておけば実装を補助してくれる！
- 各機器の通信仕様書(Modbusとか)を
docs/配下にいれておけば、それを参照してデモコードの実装や、アドレスマップの確認、実装時にサジェスチョンしてくれて便利。 - これで何十ページもある仕様書を眺めることも少なくなるかも・・・
- 各機器の通信仕様書(Modbusとか)を
Cursorのイマイチだった点⚠️
-
組込み環境特有の制約を考慮してくれない
- 例えば標準ライブラリしか使えない環境だとしても、生成時はモダンでイケイケなライブラリを当たり前のようにサジェスチョンしてくる。
- ルールで制限しないといけない。
-
リソース制限に対する配慮が弱い
- メモリ/CPU使用量を抑えた設計（多重ループや頻繁なポーリングを避ける等）を意識しないため、こちらも明示的な指示が必須。
- 生成されたコードに対して軽量化の検討を毎回行う必要がある。
-
実機デバックの限界
- 組込み開発では最終的に実機でのデバックが必要になるはず、そうなると必ずしもローカル環境とは異なるため、ハードウェア依存問題には無力に近い。
- ハードウェアレベルのトラブルシューティングは結局自分でどうにかしないといけない。
-
その他Cursorあるある
- 意図しないファイル編集がされてしまう。
- あれ、いつの間にか関係ないファイルが変更されている～
- エラーでハマると抜け出せないときがある。
- 自分でログを追った方が早いときがある。
- 結局切り出してGPTに聞くことも度々、、、
- メソッド名・変数名が理解できない。
- 見慣れない単語をあまり使わないで～
- 意図しないファイル編集がされてしまう。
Tips
私がよく使うcursorのtipsネタ。
参照ファイル指定
こんな感じで@hogehogeとすることで、参照してほしいファイルを確実に選択できます。
Project Rules/.cursorrules
日々変更して熟成を重ねています。以下抜粋です。
かなり抜粋しています。
## 基本ルール
* ファイルの修正は承認なしでは行ってはいけません。設計案を考えて
* コードの修正を行う前に、必ず変更内容を説明し、承認を得てください
* 変更が必要な場合は、まず変更内容を提案し、確認後に実施してください
~~略~~
## 技術背景と制約
### 技術情報
~~略~~
### コードの設計方針
* シンプルで理解しやすいロジックを優先
* メモリ使用量を最小限に抑える
* 以下のような処理は避ける
* 多重ループの使用
* 毎秒の判定など頻繁なポーリング
* リソースを大量に消費する処理
まとめ
最初は何となくの導入してみましたが、今のところ満足して使えています。
とはいえ、数ヶ月後にはClineに戻っていたり、別なツールを使っているかもしれませんね。
また進捗があれば報告します！！
ユアスタンド株式会社の情報はこちら！
会社概要と採用情報についてはwantedlyをご覧ください！
Discussion