AIエージェント向けのプロンプトやコマンド集を、社内で複数人に配布している基盤チームに向けた話です。Cursor（AIコーディング支援エディタ）のスラッシュコマンド（/から始まる定型指示）を運用資産として管理する方法を整理します。
多くのCursorコマンド集は、単なるMarkdown（軽量マークアップ言語）の断片です。プロンプトを貼り付けて、エージェントがうまく振る舞うことを期待し、期待通りに動かなくなったら文章を書き直す。個人のメモならそれで十分ですが、他人が使う運用資産としては心もとない仕組みです。これはインフラのコード管理と同じ課題で、SRE（サイト信頼性エンジニアリング）が長年向き合ってきた「暗黙知の属人化」とほぼ同じ構造をしています。
何が問題で、なぜ見ておくべきか
Terraform（インフラをコードで定義管理するツール）を使わずに手動でサーバー設定を変更し続けると、いつの間にか本番環境の状態が誰にも把握できなくなります。プロンプト運用にも同じ現象が起きます。
「セーフガードとなる一文」がある日誰かの編集で消えていても、レビューで気づかれなければ、そのままリリースされてしまいます。たとえば「ビルダー自身に自分の成果物を評価させない」というガード文が、コマンドファイルの改稿中にうっかり削除されるケースです。人間のレビューだけに頼ると、こうした欠落はコードのnullチェック漏れと同じくらい静かに紛れ込みます。
Cursorのスラッシュコマンドをプロダクト水準で配布する仕組みとして、コマンドとスキル（振る舞いの契約書）を分離し、評価（eval）とCI（継続的インテグレーション）でのゲート判定を組み合わせる設計が公開されています。GitHub上のcursor-commandsリポジトリがその実例です。SREの視点で見ると、これは「インフラのドリフト検知」をプロンプト運用に輸入した話として読めます。
仕組みを段階的に見る
まず全体構造は3層に分かれます。スラッシュコマンドは薄い入口、実際の振る舞いの契約は対になる「スキル」ファイルに書き、その契約が守られているかを評価とCIで検証します。
1. コマンドとスキルの分離
/gauntlet-loopというコマンドを例にすると、コマンドファイル自体はYAMLフロントマター（設定用のメタデータ）とOverview・Defaults・Steps・Anti-patternsという定型セクションだけの薄いファイルです。実際の判断ロジックは、対になるSKILL.mdという別ファイルに置かれます。
このコマンドの最初のステップは、必ずスキル契約を解決する処理から始まります。ワークスペース内のパスを優先し、なければユーザーのインストール先にフォールバックする、という探索順序です。インフラのコードでいえば、環境変数を「ローカル設定 → デフォルト設定」の順で解決するのと同じ発想です。
Anti-patterns(アンチパターン)セクションは、Trigger（何が起きたか）・Wrong（誤った対応）・Correct(正しい対応)・Reason（理由）という固定フォーマットで書かれます。ここで重要なのは、Correctとして書かれた振る舞いが、スキル側にも「positive guard(肯定的な保護条項)」として実在していなければならない、というルールです。ドキュメントに書いてあるだけでは足りず、実装側にも同じ制約が存在することを求める設計です。
2. スキル契約の中身
スキル側では、着手前に必ずGOAL（目的）とREAL-WORLD EQUIVALENT(現実世界での比較対象)、さらに検査可能な参照パック(ファイル・スクリーンショット・クリップ・ビルド・リポジトリパスなど)を要求します。「有名な名前」を挙げるだけでは参照パックとして認められません。
その上でタスクを独立した部分に分解し、各部分ごとにbuild(構築) → critique(批評) → pass/iterate/terminal(合格・再試行・打ち切り)という状態遷移を回します。批評担当は毎回フレッシュなコンテキスト(前の作業記憶を持たない状態)で評価し、構築した本人が自分の成果を評価することは許されません。参照より優れていなければ不合格、同点も不合格という厳しめの基準です。
3. 評価とCIによるゲート
評価のルーブリック(採点基準)には、参照が欠けているケース、参照パックが欠けているケース、同点を合格にしてしまうケース、批評ステップを飛ばすケースなど、具体的な失敗パターンが列挙されています。判定はPASS・PARTIAL・FAILの3段階で、PARTIALはship-gate(出荷判定)の文脈ではFAIL扱いになります。
そしてCIにおけるship-gateの実体は、eval/fixtures.yamlというフィクスチャ(固定の検証データ)ファイルです。ここにはSKILL.md内に一言一句そのまま存在しなければならないフレーズ(skill_required)が列挙されています。たとえば「ビルダーに自分の作業を評価させてはいけない」という一文を削除すると、run-eval-fixtures.py --strictの実行結果が失敗(red)に変わります。
既存のインフラ・SRE慣行との比較
この設計は目新しい発想というより、インフラ運用で確立された手法をプロンプトに転用したものと捉えると理解しやすくなります。
- ドリフト検知との類似: Terraformの
terraform planが「宣言された状態」と「実際の状態」の差分を検出するように、fixtures.yamlは「あるべきガード文」と「実際のSKILL.md」の差分を検出します - LLM審査を使わない判断: 毎回LLM(大規模言語モデル)に「このプロンプトは安全か」と判定させるのではなく、文字列の存在チェックという構造的な仕組みだけで判定します。これはSLO(サービスレベル目標)監視で複雑な異常検知モデルより先にシンプルな閾値監視を置く発想と近いものです
- フェイルセーフの設計思想: ガード文が消えたら即座にCIを赤くする、という設計は、本番障害の検知をアラート疲れさせない工夫と同じ方向を向いています。判定条件を複雑にしすぎると誤検知にもすり抜けにも弱くなります
| 観点 | 従来のプロンプト管理 | skill+eval+ship-gate方式 |
|---|---|---|
| 変更検知 | 目視レビュー頼み | fixtures.yamlによる文字列一致チェック |
| 評価コスト | 都度LLMに判断させる | 構造的アンカーのみ・LLM審査なし |
| 失敗の扱い | 気づいたら直す | PARTIALもFAIL扱いでビルド停止 |
| 権威の根拠 | 属人的な暗黙知 | コード化されたネガティブナレッジ |
この表でいう「ネガティブナレッジ」とは、「過去にこの失敗が起きたので、二度と起こさないためのルール」を指します。インシデントのポストモーテム(事後分析)で得られた教訓を再発防止策としてコード化する、SREの標準的なプラクティスとほぼ同じ構造です。
今日、自分の環境で確認できること
社内でCursorのスラッシュコマンドやAIエージェント向けプロンプトを配布している場合、次の点を確認する価値があります。
- コマンドとロジックが分離されているか: 1つのMarkdownファイルに指示と判断基準が全部詰まっていないか確認します。分離されていなければ、まず薄いコマンド定義と契約書(スキル相当のファイル)に分ける余地があります
- 削除されたら困る一文を洗い出せているか: 過去にインシデントや誤動作の原因になった「守るべき制約」を、明文化されたリストとして持っているか確認します。持っていなければ、まずポストモーテムやレビュー記録から拾い集める作業から始められます
- CIで文字列一致のチェックが回っているか:
grepや簡単なPythonスクリプトでも構いません。重要な一文が変更後も残っているかを、プルリクエストのCIで機械的に確認する仕組みがあるかを見ます - 同点・曖昧判定をどちらに倒しているか: 評価が「合格か不合格か迷うケース」で、デフォルトを安全側(不合格)に倒す設計になっているか確認します
Cursor自体の利用形態としては、GitHub上のリポジトリをユーザープラグインとして追加する形での配布が紹介されています。Customize画面のPluginsセクションから追加でき、デスクトップ・Web・CLI・モバイルの間でアカウント経由で同期される仕組みです。ただしこれはCursor公式のプロダクトではなく、MITライセンス(改変・再配布が自由なライセンス)で公開された個人プロジェクトである点は踏まえておく必要があります。
まとめ
プロンプトやAIエージェント向けコマンドを複数人で使う運用資産にするなら、インフラコードと同じ発想で守りを固める余地があります。
- コマンド(入口)とスキル(契約)を分離し、判断ロジックを1か所に集約する
- 過去の失敗から得た「守るべき一文」をリスト化し、フィクスチャとしてCIに組み込む
- LLMによる都度の審査ではなく、文字列一致のような安価で機械的な検証を優先する
- 判定が曖昧なケースはデフォルトで不合格側に倒す設計にする
まずは社内で配布しているコマンド集の中から、過去にトラブルの原因になった注意書きを1つ選び、それが今も本文中に残っているかを確認するチェックスクリプトを書くところから始められます。