CursorチームがBugbotルールを使用してコードレビューを自動化する方法 特にリスクの高いデータベース移行シナリオにおいて、Bugbotが手動レビュー前に危険な操作の大部分を阻止できる「鉄壁のルール」を開発しました。鍵となるのは、「標準化」「自動化」「左シフト」というキーワードを掲げた「Bugbotルール」です。 🤖 Bugbot ルールとは何ですか? Bugbotは、24時間365日稼働のオンライン「コードインスペクター」と考えることができます。動作メカニズムはシンプルです。コードベースにルールファイル（通常は.cursor/BUGBOT.md）を保存し、レビュー基準を自然言語で記述します。新しいコードがコミットされると、Bugbotはこの「検査マニュアル」と照らし合わせてコードを自動的にスキャンします。違反が見つかった場合は、直ちに該当のコード行にコメントを追加するか、警告を発します。 🛡️ コア実践アプリケーション: データベース移行のための「防災ガイド」 Cursorチームは、データベースインシデントを防止するための具体的な社内ルールを公開しました。Bugbotには以下の基準を厳守することが求められています。 1. 許可される業務（条件付き） 新しいテーブルまたは列の追加：これは許可されています。ただし、古いコードがデータを書き込む際にエラーが発生しないように、新しく追加する列は「nullable」に設定するか、「デフォルト値」を持つ必要があります。 2. インデックス作成には細心の注意が必要です。これは高リスクな操作です。ルールでは、インデックス作成中にテーブル全体がロックされ、業務に支障をきたす可能性があるため、`CONCURRENTLY` キーワードの使用が必須となっています。また、インデックス作成は別の移行ファイルで実行する必要があります。 3. 厳格に禁止されている操作：列の削除、テーブルの削除、列名の変更、列のデータ型の変更は厳重に禁止されています。これらの操作を行うと、古いバージョンのコードが即座にクラッシュします。 外部キー制約：新しいテーブルでは外部キーは禁止されています。カーソルチームは、潜在的なパフォーマンスのボトルネックを回避するため、データベースの外部キー制約に依存せず、アプリケーションコードレベルでデータ関係を処理することを推奨しています。 • 複雑なクエリ：メインデータベースでは、テーブル全体のスキャン、JOIN、GROUP BY操作は禁止されています。これらの操作はデータベースリソースを容易に消費するため、アプリケーション層でデータアセンブリを実行することをお勧めします。 4. フィールド タイプの選択に関する推奨されるベスト プラクティス: INTEGER の代わりに BIGINT を使用し、VARCHAR の代わりに TEXT を使用することをお勧めします。 🚀 拡張アプリケーション: データベースを超えて データベース セキュリティ以外にも、Bugbot のルールは他の多くの日常的な開発シナリオに適用でき、チームがクリーンで標準化されたコードを維持するのに役立ちます。 • コードのクリーン度管理: Bugbot に「TODO または FIXME コメントが表示された場合は、特定の問題番号に関連付けられているかどうかを確認する必要があります」と指示できます。関連付けられていない場合、Bugbot は自動的に開発者に追跡番号を追加するかコメントを削除するように促すメッセージを残します。これにより、コードベースに大量の「ゾンビタスク」が蓄積されるのを防ぎます。 • セキュリティと命名規則: 漏洩の可能性があるキーをブロックするルールを設定したり、特定の関数とイベント追跡がチームの命名規則に準拠するように強制したりできます。 原文を読む
