cursor自動コーディング・検証を安全に効率的に
claude 3.7 sonnetがcursorに入ったことで、コーディングが指示を出すだけになったので、自動実行させるようにした。安全の担保が肝だから、gitに修正毎に保存させて、いつでも戻れるようにしたよ。
コーディングにcursorを導入して効率が爆上がりを実感してました。しかし、人の欲望は際限がないもの。修正の指示はできたけど、ソース修正結果の承認と検証は自分で指示しなければならなかった。これを自動化する機能を注意深く使ってみました。
Cursorで安全かつ効率的なコード自動実行を実現する方法
近年のAIコーディングツールの進化は目覚ましく、開発ワークフローに大きな変化をもたらしています。特に、AnthropicのClaude 3.7 Sonnetのような高性能AIモデルと、それを強力にサポートするエディタであるCursorの組み合わせは、コード生成、編集、そして実行の自動化を新たなレベルへと引き上げています。本記事では、Cursorの自動実行モードを活用しつつ、安全性と効率性を両立させたコードの自動実行方法について、これまでの情報源を基に解説し、最後に自分なりの工夫を示します。
危険と隣り合わせの高速化？ auto-runモードを安全に活用するために
Cursorの auto-runモードは、AIエージェントに単一のプロンプトを与えるだけで、後はこちらが介入することなく、自律的に必要な作業を高速に実行させる強力な機能です[1] 。これは、まるで暴走列車のように、最初の指示以外は気にせず突き進むClineの自動実行に近い体験をCursor上で実現します[2] 。
しかし、その圧倒的な速度[2] と引き換えに、予期せぬ動作や潜在的な危険性も孕んでいます[1] 。特に、コードの自動実行においては、意図しないファイルの削除やシステムへの変更といったリスクも考慮しなければなりません。そこで重要となるのが、以下の安全対策です。
- コマンド許可リストと拒否リストの適切な設定: YOLOモードを安全に利用するためには、**実行を許可するコマンド（許可リスト）**と、**決して実行させないコマンド（拒否リスト）**を明確に設定することが不可欠です1 。例えば、git statusのような安全なコマンドは許可リストに、rm -rf /のような危険なコマンドは拒否リストに追加します。どのようなコマンドが危険であるか不明な場合は、Vectalに「AIエージェントに自動的に実行させるべきではないターミナルコマンドは何か」と質問するのも有効な手段です（会話履歴）。
- ファイル削除保護の有効化: Cursorの設定には、エージェントが自動的にファイルを削除することを防ぐ「ファイル削除保護」必ず有効にしておくことで、誤操作によるデータ損失のリスクを低減できます。
- 慎重な利用と監視: YOLOモードは非常に強力ですが、重要なプロジェクトや本番環境での利用は慎重に行うべきです1 。実行後には、AIエージェントが行った変更を必ず確認し、意図しない動作がないかを監視するように心がけましょう。
効率的なコード自動実行のための戦略
安全性を確保した上で、Cursorで効率的にコードを自動実行させるためには、以下の戦略が有効です。
- Project Rules（.cursor/rules）の活用: Cursorでは、プロジェクト固有のルールを**.cursor/rulesディレクトリ**に定義することで、AIエージェントがよりコンテキストを理解し、適切なコードを生成・実行できるようになります[4] 。特に、Auto Attachedルールを利用すると、ファイルの種類やプロジェクト構成に応じてルールが自動的に適用されるため、効率的な自動化に繋がります[5] …。例えば、Pythonプロジェクトであれば特定のコーディング規約やライブラリ利用に関するルールを自動的に適用できます。
- タスクを細分化し、セッションを短く保つ: 1つのセッションで多くのタスクを依頼すると、AIエージェントが以前の指示やルールを忘れてしまう可能性があります7 。タスクを可能な限り細かく分割し、セッションを短く保つことで、より正確で効率的な自動実行が期待できます。設計フェーズと実装フェーズを分けたり、バックエンドとフロントエンドの実装を分離したりするのも有効です[7]。
- ビルド、Lint、テストを自動化に組み込む: コードの自動実行後には、その結果を検証するプロセスが重要です。ビルド、Lint、テストの実行をCursorエージェントに依頼することで、問題点を早期に発見し、自動的に修正させることが可能になります[8] 。独自のLinterを設定し、アーキテクチャの整合性などをチェックするのも効果的です[8]。
- MCP（Model Context Protocol）による外部連携: CursorのMCP機能を活用することで、AIエージェントが外部APIを呼び出したり、リアルタイムデータを取得したりすることが可能になります6 …。例えば、天気情報を取得してその結果に基づいてコードを生成する、といった高度な自動化も実現可能です[11] 。
ここまでのまとめ
CursorとClaude 3.7 Sonnetの組み合わせは、適切に活用することで開発効率を飛躍的に向上させる可能性を秘めています。YOLOモードのような強力な自動実行機能を安全に利用するためには、コマンド許可/拒否リストの設定、ファイル削除保護の有効化といった安全対策が不可欠です。
さらに、Project Rulesによるコンテキストの提供、タスクの細分化、自動テストの導入、そしてMCPによる外部連携といった戦略を組み合わせることで、安全性と効率性を両立させた、より高度なコード自動実行ワークフローを構築することができるでしょう。常に最新の情報にアンテナを張りながら、自身の開発スタイルやプロジェクトの特性に合わせて、これらの機能を最適に活用していくことが重要です。
参考文献
[2] https://steve-yegge.medium.com/the-death-of-the-stubborn-developer-b5e8f78d326b
[12] 該当動画は文字起こしのためURLなし
[1] 該当動画は文字起こしのためURLなし
[9] https://qiita.com/yuku_t/items/b1108941a1807323e595
[5] https://qiita.com/yuku_t/items/b1108941a1807323e595
[6] https://qiita.com/yuku_t/items/b1108941a1807323e595
[4] https://qiita.com/suthio/items/3761b06d35f14894a5a8
[7] https://qiita.com/suthio/items/3761b06d35f14894a5a8
[8] https://qiita.com/suthio/items/3761b06d35f14894a5a8
[13] https://zenn.dev/zennkutakutat/articles/cursor-devin-memo
[10] https://qiita.com/yuku_t/items/b1108941a1807323e595
[11] https://qiita.com/yuku_t/items/b1108941a1807323e595自分で工夫した点ルール
Cursor AIエディタとClaude 3.7 Sonnetの組み合わせにより、コーディング速度が飛躍的に向上しました。さらに、自動修正機能を活用することで効率化が加速します。しかし、AIエディタがファイルを破壊したり、システムを深刻に書き換えるリスクも存在します。そのため、安全性と効率を両立するルールを策定し、Cursorにこの機能を追加しました。以下では、そのルールの工夫点、背景、目的についてまとめます。
巨人の肩に乗ろう
先人たちがいいルールをあげています。それらをありがたく参考にさせていただきました。
ルールの背景と目的
AIエディタの自動修正機能は、コーディングの効率を大幅に向上させます。しかし、無制限に自動修正を行うと、意図しないファイルの変更やシステムの破壊につながる可能性があります。そこで、安全性を確保しつつ効率的なコーディングを実現するためのルールを策定しました。
ルールの主な工夫点
- 作業前の計画と目的の明確化:
- 作業開始前に、目的、ゴール、作業フローを説明し、計画的な作業を促進します。
-
ディレクトリ構成と技術スタックの把握:
- 新しいプロジェクトでは、ディレクトリ構成や技術スタックを判断し、READMEファイルに要件定義を記述します。
-
Gitによる変更管理:
- 修正前にGitで状態を保存し、変更前に戻れるようにします。自動修正時も、確実にGitを用いて保存します。
-
自動修正の制限:
- 除外リストにあるファイルは自動修正しないようにし、システム動作関連のファイル編集は特に許可を得る必要があります。
-
ショートカットの活用:
- 特定の作業を効率化するためのショートカットを定義し、作業の迅速化を図ります。
ショートカット一覧
- 用語は品質マネジメントシステムの規格ISO 9001のPDCAに倣いました。
| ショートカット | 説明 |
|---|---|
| /plan | 仕様を読み込み、実装方針を検討するフェーズ。コード生成や修正は次の指示を待つ。 |
| /do または /cline | /plan に従ってコードを新規作成・修正するフェーズ。自動修正を実行する前にGitで保存し、/undo できる状態にする。 |
| /check | エラーの原因や状況を関連ファイルやコードを参照して確認するフェーズ。コードの修正・編集は行わない。 |
| /another | 現在の方法以外の解決策を検討するフェーズ。コードの提示は不要で、多角的な分析と積極的な提案を行う。 |
| /debug | バグの根本原因を特定するフェーズ。可能性のある原因をリストアップし、絞り込む。修正前にユーザーの許可を得る。 |
| /undo | 直近の /auto-fix または /fix のコミットをGitでリバートする。実行前にユーザーの確認を取る。 |
| /replay | 直近の cline: コミットを再実行する。 |
| /list | 直近10件の git: コミット履歴一覧を表示する。 |
| /commit | まだGitに登録していない場合、修正内容のコメント付きでコミットする。 |
実際適用してみてどうだったか
-
初回auto-runを
enableにして実行してはいけないコマンドを追加して、ルールファイルができていること、Alwaysになっていることを確認しましたが、初回〜３回までからルールファイルは無視して実行されました。その度に無視してはいけないと諭したところ反省していましたが、無視が続きました。そこでルールファイルを直接引用させたところ(@で指定）、無視する回数はへいました。この辺りのインプリはまだまだ。 -
そこで、ルールを読んでいるかどうかを判断させる裏技をyoutubeで見つけたのでこれを追加。ルールベースかどうか解答から分かるようになりました。それがこちら。
- まず、このファイルを参照したら、このファイル名を発言すること -
まだ1日目ですが、スムーズにいく時はなかなか快調です。備忘録として書いてみました。
良い点：
- gitに修正前と成功した修正をコメント付きで自動でつけてもらえるようになったのでgit管理が楽になった。
悪い点：
- 変更しすぎるので元に戻りたくなる。
- chmodを使うなと書いてあるが、ルール無視が頻発するので安心しない
まとめ
これらのルールにより、AIエディタの自動修正機能を安全かつ効率的に活用できます。作業前の計画、Gitによる変更管理、自動修正の制限、ショートカットの活用など、多角的なアプローチでコーディングの効率と安全性を向上させます。
今今のルール
---
description: Apply this rule to the entire repository
globs:
alwaysApply: true
---
# torir-dev-rules:
## general rules:
- まず、このファイルを参照したら、このファイル名を発言すること
- あなたは高度な問題解決能力を持つAIアシスタントです。以下の指示に従って、効率的かつ正確にタスクを遂行してください。
- まず、ユーザーから受け取った指示を確認します：
<指示>
{{instructions}}
<!-- このテンプレート変数はユーザーの入力プロンプトに自動置換されます -->
</指示>
この指示を元に、以下のプロセスに従って作業を進めてください：
- 常に日本語で返答する
- チャット開始時には今日の日付を宣言し、.specstoryフォルダの最新履歴を見て要約する
- 作業を行う前に、目的とゴール、作業フローを説明する
- 作業フローのテンプレート化：
- 作業説明は以下のフォーマットで行うこと：
目的：
入力：
出力：
手順：
テスト方法：
- 新しいプロジェクトの際は、ディレクトリ構成やユーザーとの会話から技術スタックを判断し、Readmeファイルに要件定義、技術スタックなどを記述する
- 新しいプロジェクトの場合ではディレクトリやREDME.mdがない場合は、目的と入力、出力を聞いた上で、ディレクトリを提案し、確認した上で作成する
- README.mdファイルの既存の構造を維持する
- プロジェクトの説明はプロジェクトのルートディレクトリに配置する
- 各コマンドの説明は'./doc'に'コマンド名'+'.md'とする
#### ディレクトリの確実な指定
- コマンドの発行は$HOMEを基点とする。''./"などを基点としない。
- ドキュメントとREADMEファイルには常にMarkdownを使用する
#### 元に戻れるように保存(git)を確実に行う
- 後述のショートカットで自動修正する場合は修正前に戻れるように確実にgitを用いて保存する。
- 差分検出で`git diff`を用いる場合はインターラクトモードでなく、自動で表示させ、差分の情報を取得する。
#### 命名とフォーマット
- cursor-rule.mdファイルとそのフォルダには'technology-focus-cursor-rule.md'のパターンに従った説明的な名前を使用する
- README.mdファイル内のリスト項目には一貫したフォーマットを使用する
#### コンテンツガイドライン
- cursor-rule.mdファイルを作成または編集する際は、プロジェクト固有の指示とベストプラクティスに焦点を当てる
- 複雑なルールの説明やコンテキストを提供するためにcursor-rule.mdファイルにコメントを含める
#### メンテナンスと更新
- ユーザの指示がない限り、git登録直前にREADME.mdを更新する。
- README.mdファイル内のすべてのリンクが相対的で正しいことを確認する
- README.mdを更新する際は、目次が正確であることを確認する
- 新しいカテゴリを追加する際は、README.mdの「目次」と「ルール」セクションの両方を更新する
#### コーディングルール
- リポジトリ全体で大文字小文字と句読点の一貫性を維持する
- 常に正しい大文字小文字とスペースを使用する
- 例や説明を追加する際は、Cursor AIユーザーの実用的なユースケースに焦点を当てる
## 作業プロセス
### 指示の分析と計画
<タスク分析>
- 主要なタスクを簡潔に要約してください。
- 記載された**守るべきルールのディレクトリ/ファイル**を必ずチェックしてください。
- 重要な要件と制約を特定してください。
- 潜在的な課題をリストアップしてください。
- タスク実行のための具体的なステップを詳細に列挙してください。
- それらのステップの最適な実行順序を決定してください。
#### 重複実装の防止
実装前に以下の確認を行ってください：
- 既存の類似機能の有無
- 同名または類似名の関数やコンポーネント
- 重複するAPIエンドポイント
- 共通化可能な処理の特定
このセクションは、後続のプロセス全体を導くものなので、時間をかけてでも、十分に詳細かつ包括的な分析を行ってください。
</タスク分析>
---
### タスクの実行
- 特定したステップを一つずつ実行してください。
- 各ステップの完了後、簡潔に進捗を報告してください。
- 実装時は以下の点に注意してください：
- 適切なディレクトリ構造の遵守
- 命名規則の一貫性維持
- 共通処理の適切な配置
---
### 品質管理と問題対応
- 各タスクの実行結果を迅速に検証してください。
- エラーや不整合が発生した場合は、以下のプロセスで対応してください：
a. 問題の切り分けと原因特定（ログ分析、デバッグ情報の確認）
b. 対策案の作成と実施
c. 修正後の動作検証
d. デバッグログの確認と分析
- 検証結果は以下の形式で記録してください：
a. 検証項目と期待される結果
b. 実際の結果と差異
c. 必要な対応策（該当する場合）
---
## 最終確認
- すべてのタスクが完了したら、成果物全体を評価してください。
- 当初の指示内容との整合性を確認し、必要に応じて調整を行ってください。
- 実装した機能に重複がないことを最終確認してください。
---
## 結果報告
以下のフォーマットで最終的な結果を報告してください：
```markdown
# 実行結果報告
## 概要
[全体の要約を簡潔に記述]
## 実行ステップ
1. [ステップ1の説明と結果]
2. [ステップ2の説明と結果]
...
## 最終成果物
[成果物の詳細や、該当する場合はリンクなど]
## 課題対応（該当する場合）
- 発生した問題と対応内容
- 今後の注意点
## 注意点・改善提案
- [気づいた点や改善提案があれば記述]
```
---
## ショートカット
- 以下のショートカットが記述されている場合、プロンプトに含まれている場合、そのショートカットのルールや説明に基づいて処理する。
- '/plan':
- 仕様を読み込みどういう風にインプリしていくのかを考えるフェーズ。
- コード生成や修正は次の指示を待ってください。
- インプリする方針を概説し、ユーザの考えと相違点がないことを確認してください。
- 必ずテスト方法と期待値・期待動作を記載してください。
- '/do', もしくは'/cline':
- ロジックとインプリの方法は/planに従ってコードを新規作成、修正するフェーズ。
- 手続きは'./rules/cline-rules.md'に従って、自動修正(cline)してください。
- 事前にgitに保存して、'/cline-undo'できること。
- 最初にテスト方法と期待値・動作を宣言して、必要に応じてテストデータを準備してください。
- テストの期待値と合致するもしくは、エラーがない状態になるまで自動で修正してください。
- '/check'：
- エラーの原因や状況など、関連するファイルやコードを参照して、実行結果と動作をチェックするフェーズ。
- コードの修正・編集はしない。
- ただし、データベースにアクセスする、各プログラムの状況(status)を調べるなど、情報収集のコマンドは自動発行して良い。
- '/another'：
- 修正が収束しないなどの理由で、ユーザーが別のインプリ方法などを探しているフェーズ。
- 現在の方法以外に多角的に分析し、問題解決の積極的な提案してください。
- コードの提示は不要です。
- 情報収集はして構いません。それ以外のタスクを実行しないでください。
- '/debug'：
- /checkより更にバグの根本原因を特定します。
- 5～7つの可能性のある原因をリストアップし、1～2つに絞り込みます。修正する前に、許可をとってください。
- '/undo' :
- 直近の /auti-fix または /fix のコミットを Git で revert
- 必ず git log で “cline:” プレフィックスのあるコミットを探す
- ユーザに確認してから実行する（重要ファイルであれば二段階承認）
- undoする以外はコード編集をしてはいけない。
- '/replay' :
- 直近の “cline:” コミットを cherry-pick または patch 適用で再実行させる
- もし undo → replay の流れがある場合は一貫性チェックも行う
- '/list' :
- 間近10件の git: コミット履歴一覧を表示
- ```git log --grep='^cline:'```
- コード編集をしてはいけない。
- '/commit':
- まだgit登録していない場合は、修正内容のコメント付きでコミットする。
## 自動実行(Cline/YOLO)のガイドライン
- 除外リスト('.cursor/rules/cline-exclude.yaml')にあるファイルは自動修正してはならない。
- プロジェクトのcline-ruleは'./rule/clinerules.md'にある場合、必ず参照しなければならない
- './rule/clinerules.md'がない場合は、方針を自動生成し、ユーザにこれを伝え承認を得なければならない必ず実行前に戻れるように現在の状態をgitで保存しなければならない。コメントは自動で追加すること。単にaddするのか、新しいブランチを切るのかは'git status'で複雑さで判断すること。
- 自動コミットを行う場合は、コメントに[auto-cline]プレフィックスを含め、目的と修正範囲を1行で要約する。
- 自動で編集するのは、プロジェクトのディレクトリ'./'以下のファイルのみである。他のファイルの編集が必要場合は自動実行可能なモードであっても、必ずユーザに確認が必要。
- ./以下でも、シンボリックリンクや外部ストレージ、ネットワークマウントを通じて他ディレクトリへのアクセスが発生する場合、それらは編集不可とする。
- 自動実行の変更を自動的にステージしない
- 自動実行が可能な場合でも、その前にどういうことを行うかを提示してユーザの許可をもらわなければならない。
- 実行範囲とは使用するコマンド群、編集するファイル群で、cline実行前にこれらを提示して許可をもらうこと
- システム動作関連のファイル編集は特に許可をもらわなければならない
- 機能実現と並行して、テスト方法の提示が必要。テスト方法とテスト入力と期待される出力（期待値）を準備を先に行わなければならない。この入力と期待値をユーザに提示して許可をもらう。
- この入力と期待値に合致するようにコードを修正していく。
- コードを実際に修正する場合、**あったらいい機能(wish)**の追加はしてはならない。必要な機能(**must**))のみ追加することができる。
- システム変更・外部アクセス系コマンド（rm, sudo, curl, wget , pip, pyenv, brew apt, yumなど)は自動実行中には使用不可。使用が必要な場合は必ずユーザ確認を経る。
- clineのすべての実行ログは.cline-log/以下にタイムスタンプ付きで保存し、作業の再現性を確保する。
## README.md構造
README.mdファイルでは以下の構造を維持する：
1. タイトルとAwesomeバッジ
2. ロゴ
3. 簡単な説明
4. 目次
1. インストール
2. ルール
3. 使用方法
4. テスト
5. 貢献
6. ライセンス
以上以上