RevOpsエンジニア（またはGTMエンジニアリングに隣接する担当者）が、売上データに対してSOQL、Apex、HubSpot カスタムコード、n8n フロー、dbtモデルを実装するためにチューニングされた Cursor .cursorrules ファイルです。このアーティファクトは1つのファイル — apps/web/public/artifacts/cursor-rules-revops-engineer/.cursorrules — で構成されており、プロジェクトの .cursor/rules/ ディレクトリに配置するだけで、今四半期中「これはバルク処理すべきか」「このdbtモデルにテストは必要か」といった議論をAIアシスタントと繰り返す必要がなくなります。

RevOpsコードの本質的な特性は、CROが次の決算発表で報告するパイプライン数値に直接触れるという点です。大規模な重複書き込み、デデュープキーの漏れ、ステージ進行のバグは、単にスクリプトを壊すだけでなく、予測を壊します。このバンドルのルールは、バルク処理、冪等性、明示的なリミットチェック、保守的な書き込みを組み込んでおり、CursorのサジェストがRevOpsミスの実際の影響範囲を反映するようになっています。

このルールを使う場面

あなたはRevOpsエンジニア、GTMエンジニア、またはコードを書くRevOpsマネージャーであり、Salesforce またはHubSpotに対してインテグレーションコード（Python、TypeScript、Apex、n8nフロー、dbtモデル）を実装しています。チームは月に数回以上、パイプラインデータに触れる変更をリリースしています。CursorがIDEです。

このルールを使わない場面

RevOpsでエンジニアリングプラクティスを運用していない場合 — 「自動化」がCRM UIの管理者ビルドワークフローであり、リポジトリのコードではない場合。このルールはコードレビュー、バージョン管理、デプロイパイプラインを前提としており、コンフィグのみの組織には役立ちません。
Salesforceソリューションをクライアントに提供する外部SIの場合。このルールは何年もその結果と向き合う社内オペレーターのためにチューニングされており、コンサルタントのエコノミクス（デリバラブルのスコープ、引き渡しドキュメント、契約後サポートモデル）とは異なります。
自社プロダクトにマーケティングアトリビューション機能を実装している場合。このルールはCRMを使用する企業内のオペレーションエンジニアリング向けであり、CRM隣接プロダクトを構築するエンジニアリングチーム向けではありません。

セットアップ

アーティファクトをコピーする。 上記バンドル（またはzipダウンロード）から .cursorrules を取得し、プロジェクトの .cursor/rules/ ディレクトリに配置します。CursorのProject Rulesインジケーターでロードが確認できます。
不要なツールセクションを削除する。 ファイルにはSalesforce（SOQL/Apex）、HubSpotカスタムコード、n8n、dbtのセクションが含まれています。使用しないセクションを削除してください — 無関係なコンテキストに対してモデルが重みを付けるガイダンスを残すとシグナルが薄れます。
シークレットポリシーを設定する。 ルールはハードコードされた認証情報を禁止し、シークレットマネージャーへの誘導を指示します。「Secrets and access」セクションを編集して、モデルが適切な呼び出し先（1Password CLI、Doppler、AWS Secrets Manager、Vault — どれか1つ）を提案するようにします。
監査先を修正する。 いくつかのルールは監査オブジェクト参照（Cleanup_Audit__c がデフォルトのプレースホルダー）を必要とします。チームの実際の監査オブジェクトに編集してください。そうしないと、組織内に存在しない名前がサジェストされます。
代表的なタスクでテストする。 Cursorに「関連するタスクがクローズされるたびにオポチュニティの Last_Activity_Date__c を更新するApexトリガーを書いて」と依頼します。出力はバルク処理され、Limits.getQueries() チェックを含み、テストクラスとともに提供され、匿名Apexを含まないはずです。そうでない場合、ルールがロードされていません — CursorのProject Rulesインジケーターを確認してください。

ルールが実際に行うこと

このバンドルはすべてのCursorプロンプトに適用される5層構造です。

「コードを書く前に確認する」プリアンブル。 生成前にモデルが提示する5つの質問：どのシステムが信頼できる情報源か、データ量はどれくらいか、失敗が売上レポートに何を意味するか、これは一回限りか繰り返しか、誰が監査証跡を読むか。これらの質問は明白に聞こえます。しかし十分に問われていません。
ツール別のガイダンス — SOQL/Apex（ガバナーリミット、バルクパターン、WITH SECURITY_ENFORCED）、HubSpotカスタムコード（v4 SDK、デイリークォータのサーキットブレーカー、20秒タイムアウト）、n8n（executionOrder、タイムゾーン、IF対Codeノード）、dbt（ユニークテスト、ref()、インクリメンタル戦略、ソースの鮮度）、シークレット（名前付き認証情報、Private Appトークン、スコープ付きアクセス）。各サブセクションは実際のリミットと現在のSDKバージョンを引用しています。
強制するデフォルト — バルク処理、冪等性、リミット/サーキットブレーカー、オブザーバビリティ、シークレット全体にわたって適用されます。各デフォルトには具体的な値があります：バルクバッチのデフォルトは25レコード、HubSpotデイリークォータは80%消費時に停止、n8nフローは実行ごとに1000アイテムを上限とします。
拒否すべきアンチパターン。 モデルが拒否する具体的なパターン：本番環境への匿名Apex、サーキットブレーカーのないHubSpotループ、条件が5つ以上のn8n IFノード、ユニークテストのないdbtモデル、ノートブックからの直接本番書き込み。
「ユーザーが間違っている場合」セクション。 締め切りプレッシャーの下でエンジニアが使おうとするショートカットを、実行するのではなく押し返すようモデルに指示します。最もコスト削減効果の高いルール：インポートのためのSalesforceバリデーションルールのバイパスを拒否すること — バイパスすると、ダウンストリームのレポートが集計できないレコードが生成され、CROが説明しなければならない予測差異として表面化します。

コストの実態

トークンコスト：ゼロ。 Cursorルールはプロンプトごとに送信されるローカルコンテキストであり、コンテキストウィンドウ内で占有する約5 KB以外のリクエストごとのAPIチャージはありません。
セットアップ時間：約10分 — ファイルの配置、シークレットマネージャーの設定、監査オブジェクトの実際の名前への変更。
タスクごとのオーバーヘッド： プリアンブルにより生成前に1〜2ターンの対話が追加されます。3行のスクリプトには重すぎます。実際のインテグレーションタスクには、コードレビューやSOXウォークスルーで後から浮上するような意思決定を表面化させます。
メンテナンス：四半期ごとに約30分。 SDKバージョンはドリフトします（HubSpotではv3→v4はすでに発生済み；v4→v5も起こるでしょう）。Salesforceのガバナーリミットはリリース間で安定していますが、メジャーリリースごとにTrailheadで確認する価値があります。

成功の見え方

データ品質バグに起因する予測差異が減少する。 バルクパターンと冪等な書き込みにより、パイプラインをサイレントに膨らませる重複行クラスのバグを防ぎます。
コードレビューがロジックに集中し、「バルク処理したか」に集中しなくなる。 ルールがバルクパターンをインラインで提案するため、レビュアーがその欠如を指摘する必要がなくなります。
SOXウォークスルーでエンジニアの介入なしに監査証跡が表面化する。 すべての書き込みは Cleanup_Audit__c（またはチームの同等物）に (timestamp, user, object, record_id, field, old_value, new_value) とともに行を生成します — 監査人は監査オブジェクトから質問に答えられ、エンジニアとのSlackスレッドは不要です。
「以前は動いていたのに」という廃止SDKのデバッグセッションが発生しない。 バージョンタグ付きルールにより、モデルが現在のエンドポイントを使用することが保証されます；廃止コードはリポジトリに入りません。

代替手段との比較

ルールなし（現状）。 Cursorは200レコードのロードテストで失敗するもっともらしいApexを生成します。バルクスクリプトがサイレントに切り捨てられ、予測が40万ドルずれた時初めて、ルールの不在がボトルネックになります。
Notionのチームコーディング規約ドキュメント。 機能的にはルールなしと同等 — そのドキュメントはAIのコンテキストにロードされません。Cursorルールファイルは、すべてのプロンプトでロードされる規約ドキュメントです。
リンター/静的解析（ApexのPMD、dbtのdbt-checkpoint）。 コードが書かれた後にパターンを検出します。Cursorルールと共存できます；ルールはそもそもコードが書かれないようにし、リンターはすり抜けたケースを検出します。

注意点

ルールのドリフト。 チームはルールを追加するが削除しない。ファイルが「以前はこうやっていた」というガイダンスの博物館になり、モデルが適用しようとし続けます。対策：git blame を使った四半期レビュー — 18ヶ月以上古いものは再正当化するか削除します。
ルールの競合。 Cursorはマッチするすべてのルールを適用します；矛盾する指示は混乱した出力を生成します。ファイルは約300行を上限とします。対策：ルール追加時に同じサーフェスの既存ルールを検索し、追記ではなく統合します。
ツールバージョンのチャーン。 「v4 HubSpot SDKを使用する」はv5がリリースされた時点で間違いになります。対策：SDKバージョンに言及するすべてのルールにバージョンタグを付けます（例：# HubSpot SDK v4 (verified 2026-Q2)）。これにより次のレビュアーがいつ再確認すべきかわかります。
リポジトリごとのオーバーライド。 予測リポジトリで正しいルールがリードルーティングリポジトリでは間違っている場合があります（例：書き込み対読み取りのデフォルト）。Cursorのディレクトリ別ルールサポートを使用し、READMEで差異を文書化します。対策：ファイルをフォークするのではなく、文書化された例外を含む1つの共有ルールファイルを優先します。
ルールは本番データ変更のQAを置き換えない。 ルールはCursorが提案する内容を形成します。CIでは実行されず、スクリプトが触れるデータを検証せず、SOXコントロールにはなりません。対策：dbtテスト、バリデーションルール、コードレビューを別々の実施レイヤーとして維持します。

スタック

Cursor — IDEおよびルールエンジン
.cursor/rules/revops-engineer.md — リポジトリでバージョン管理され、コードレビューされる
選択したシークレットマネージャー — ルールから参照され、インライン化されない
監査オブジェクト — Cleanup_Audit__c または同等のカスタムオブジェクト、サジェストが実際の名前を指すよう明示的に命名される

GitHubでこのページを編集

RevOpsエンジニアリング業務向けCursorルール

Stack