Cursorのコンテキスト制御を極める：.cursorrulesとAST連携による『完全決定論的コード生成』のアーキテクチャ
単なるコード補完エディタの域を超え、開発者の思考速度を超越したコード生成能力を持つ「Cursor」。しかし、企業のエンタープライズコードベースや厳格なアーキテクチャ（Clean Architecture, DDD, Strict TypeScript等）においてデフォルトのままAIを運用すると、「LLMのコンテキストドリフト（文脈の逸脱）」 という深刻な問題に直面します。
AIが一般的なWeb上の学習データに引きずられ、プロジェクト独自の命名規則を無視し、既存の設計パターンを破壊する野良コードを吐き出す――。この「確率論的ランダム性」を極限まで排除し、AIの出力を「完全決定論的（Deterministic）」なレベルまで制御することこそが、DevOpsアーキテクトに課された使命です。
本稿では、Cursorの内部コンテキスト注入メカニズムを解剖し、特定のコーディング規約をAIに絶対遵守させるプロンプトエンジニアリング技術、さらにはCI/CDやAST（抽象構文木）解析ツールと連携させた自動フィードバックループの構築手法まで、低レイヤの視点から徹底的に解説します。
—
1. Cursorコンテキストエンジンの内部アーキテクチャと「ドリフト」の力学
なぜAIは指示を破るのか？ その根底には、LLMのアテンション・メカニズム（Attention Mechanism）とCursorのコンテキストパイプラインの構造的制約が存在します。
[プロジェクトファイル群]
│
▼ (AST & RAG Indexing)
[ベクトルデータベース (Vector DB)]
│
├─► [User Prompt (Cmd+K / Chat / Composer)]
├─► [System Prompt Engine]
│ ├─ Global System Directive
│ └─ .cursorrules / .cursor/rules/.mdc ◄───【本稿の主軸】
│
▼ (Token Budget Packing & Attention Distribution)
[LLM (Claude 3.5 Sonnet / GPT-4o)]
│
▼
[Generated Code Output]
1.1 Context Windowの優先順位と「Lost in the Middle」現象
CursorがLLMにリクエストを送信する際、入力トークンは以下の優先順位でパッキングされます。
1. システムプロンプト（基盤命令）
2. `.cursorrules` (または `.cursor/rules/` 内のルールファイル)
3. 明示的な参照コンテキスト（`@file`, `@folder`, `@symbol`）
4. 直近のチャット履歴 / Composerの編集コンテキスト
5. RAGによって検索された関連コードセグメント
ここで問題となるのが、「Lost in the Middle（中央での埋没）」 と呼ばれるLLM固有の特性です。プロンプトの冒頭と末尾に配置された情報は高いアテンション重みを獲得しますが、中間部に配置された長大な指示や曖昧な文章は無視されやすくなります。
曖昧な自然言語で書かれた`.cursorrules`は、RAGで取得された大量のコード断片に埋もれ、アテンションが拡散します。その結果、LLMは自身の事前学習データ（一般的なWebコード）へと回帰し、プロジェクトの規約を無視するのです。
1.2 構造化データ（XML / Markdown Boundary）による強力な拘束
LLM（特にClaude 3.5 Sonnet）に対して強力な制約を課すためには、自然言語による説明ではなく、XMLタグを用いたセマンティック境界の明確化と否定条件（Anti-Patterns）の明示が不可欠です。
—
2. 決定論的 `.cursorrules` の設計パターンと記法
最新のCursor（v0.40以降）では、従来のプロジェクトルートにある単一の `.cursorrules` に加え、より細かいスコープで制御可能な `.cursor/rules/.mdc` (Markdown Component) 構成がサポートされています。
ここでは、単一 `.cursorrules` およびディレクトリ単位の `.cursor/rules/` の両方で応用可能な、ゼロ・ドリフトを実現するプロンプト構造を提示します。
2.1 実務で即効性を持つ「プロダクショングレード」のルール定義
以下の例は、TypeScript + Clean Architecture構成のプロジェクトにおいて、AIに絶対的な制約を課すためのフルスペック設定です。
あなたは、厳格なClean ArchitectureおよびDDD（ドメイン駆動設計）を適用されたプロジェクトのプリンシパルエンジニアです。
すべてのコード生成、リファクタリング、提案において、以下の【絶対制約】を遵守してください。
{
return await this.profileRepository.findByUserId(this.id);
}
}
]]>
2.2 なぜこの構造が効果的なのか？
1. XMLタグによるパースの強化: `Claude` 等の高度なLLMは、コンテキスト内のXMLタグをコード構文と同等レベルの「メタデータ構造」として厳密に認識します。
2. `bad_example` / `good_example` の対比: LLMの推論（In-Context Learning）は、フューショット（具体例）を与えることで精度が指数関数的に向上します。特にアンチパターン（やってはいけないこと）を示すことで、事前学習の偏りを強制補正できます。
—
3. 次世代ルール制御：`.cursor/rules/.mdc` による動的コンテキスト割り当て
単一の `.cursorrules` ファイルが肥大化すると、コンテキストウィンドウの上限を圧迫し、本来のコード領域が狭まります。Cursorの最新機能である `.cursor/rules/.mdc` を利用すると、ファイルパスやグロブパターンに応じて必要なルールのみを動的にロードすることが可能です。
`.cursor/rules/domain-layer.mdc` の構成例
—
description: Domain層のコード（src/domain//.ts）に対する編集・作成時に適用される厳格ルール
globs: src/domain//.ts
alwaysApply: false
—
Domain Layer Absolute Directives
このディレクトリ配下のファイルは、ビジネスロジックの核となる部分です。以下の制約を厳密に順守してください。
1. 依存性の制限
- 外部パッケージのインポートは禁止（`fp-ts` などの純粋関数型ライブラリを除く）。
- `process.env` への直接アクセス禁止。設定値はValue Objectとしてコンストラクタで受け取ること。
2. 不変性の担保
- すべてのプロパティは `readonly` とすること。
- 状態変更メソッドは、自身のインスタンスを変更せず、常に新しいインスタンスを返却すること（Immutability）。
// ✅ 正しい実装例（Immutable Entity）
export class Money {
constructor(public readonly amount: number, public readonly currency: string) {}
public add(other: Money): Money {
if (this.currency !== other.currency) {
throw new CurrencyMismatchException(this.currency, other.currency);
}
return new Money(this.amount + other.amount, this.currency);
}
}
このようにディレクトリやファイル種別ごとにルールを分散配置することで、Token Budgetを大幅に節約しつつ、精度を極限まで高めることができます。
—
4. CI/CDパイプライン連携：静的解析ツール（AST/Linter）から `.cursorrules` を自動生成する自動化メカニズム
手作業で `.cursorrules` をメンテナンスすると、プロジェクトのESLintやBiome、TypeScriptの設定と乖離（Configuration Drift）が生じます。
真の開発効率化を実現するには、「Linter/Formatterの設定ファイルを正（Single Source of Truth）とし、そこからCursor用のルール記述を動的生成する」 パイプラインを構築します。
4.1 ESLint/Biome設定から `.cursorrules` を動的ビルドするスクリプト
以下は、プロジェクトの `biome.json` や `.eslintrc.js` を解析し、AI用のプロンプト制約ルールにトランスパイルして `.cursorrules` を再構築する Node.js スクリプトです。
// scripts/generate-cursor-rules.ts
import as fs from ‘fs’;
import as path from ‘path’;
// Biome設定ファイルのインターフェース定義
interface BiomeConfig {
linter?: {
rules?: {
recommended?: boolean;
correctness?: Record
style?: Record
};
};
}
const BIOME_PATH = path.join(process.cwd(), ‘biome.json’);
const OUTPUT_RULE_PATH = path.join(process.cwd(), ‘.cursorrules’);
function buildPromptFromConfig(): void {
console.log(‘🔄 Biome設定から .cursorrules を同期中…’);
if (!fs.existsSync(BIOME_PATH)) {
console.error(‘❌ biome.json が見つかりません。’);
process.exit(1);
}
const biomeConfig: BiomeConfig = JSON.parse(fs.readFileSync(BIOME_PATH, ‘utf-8’));
const rules = biomeConfig.linter?.rules || {};
let generatedXml = `\n`;
generatedXml += `
if (rules.style) {
generatedXml += `
for (const [ruleName, status] of Object.entries(rules.style)) {
if (status === ‘error’) {
generatedXml += `
}
}
generatedXml += `
}
generatedXml += `\n`;
// 既存のベースルールと合成
const baseRulesPath = path.join(process.cwd(), ‘.cursorrules.base’);
const baseContent = fs.existsSync(baseRulesPath) ? fs.readFileSync(baseRulesPath, ‘utf-8’) : ”;
const finalContent = `${baseContent}\n\n${generatedXml}`;
fs.writeFileSync(OUTPUT_RULE_PATH, finalContent, ‘utf-8’);
console.log(‘✅ .cursorrules の生成が完了しました。’);
}
buildPromptFromConfig();
4.2 GitHub Actionsによる強制同期パイプライン
開発者がLinterのルールを変更した際、`.cursorrules` の更新漏れを防ぐために、GitHub Actionsでチェックおよび自動コミットを実行します。
.github/workflows/sync-cursor-rules.yml
name: Sync & Validate Cursor Rules
on:
push:
branches: [ main, develop ]
paths:
- ‘biome.json’
- ‘.eslintrc.js’
- ‘.cursorrules.base’
pull_request:
branches: [ main ]
jobs:
sync-rules:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 20
cache: ‘npm’
- name: Install Dependencies
run: npm ci
- name: Regenerate Cursor Rules
run: npx ts-node scripts/generate-cursor-rules.ts
- name: Check for Uncommitted Changes
run: |
if [ -n “$(git status –porcelain .cursorrules)” ]; then
echo “❌ Error: .cursorrules is out of sync with linter config.”
echo “Please run ‘npx ts-node scripts/generate-cursor-rules.ts’ locally and commit the result.”
exit 1
fi
echo “✅ .cursorrules is completely synced.”
—
5. Docker (Dev Containers) 環境での完全標準化
チーム開発において、個々の開発者のCursor設定（拡張機能、ローカル設定、AIモデル指定）がバラバラであると、生成されるコードの品質にムラが生じます。
`.devcontainer` を活用し、チーム全体で完全に同一な「AI統合型開発環境」 をコンテナとして配布・固定化します。
`.devcontainer/devcontainer.json` のプロダクション設定
{
“name”: “Production-Engineered Cursor Container”,
“image”: “mcr.microsoft.com/devcontainers/typescript-node:1-20-bullseye”,
“customizations”: {
“vscode”: {
// チームで統一すべきエディタおよびAI挙動設定
“settings”: {
“editor.formatOnSave”: true,
“editor.defaultFormatter”: “biomejs.biome”,
// Cursor固有の設定：保存時にAIによる自動修正を走らせるかの制御
“cursor.cpp.enablePartialAccept”: true,
“typescript.tsdk”: “node_modules/typescript/lib”,
// Linter/CompilerエラーをAIに自動認識させるための言語設定
“typescript.inlayHints.parameterNames.enabled”: “all”
},
// Cursor環境に必須の拡張機能をコンテナ起動時に強制インポート
“extensions”: [
“biomejs.biome”,
“eamodio.gitlens”,
“dbaeumer.vscode-eslint”
]
}
},
// コンテナ起動直後に .cursorrules の同期スクリプトを自動実行
“postCreateCommand”: “npm install && npx ts-node scripts/generate-cursor-rules.ts”,
“remoteUser”: “node”
}
この構成により、開発者がリポジトリをクローンして「Reopen in Container」を実行するだけで、最適化された `.cursorrules` と必要なLinterエンジンがプリロードされた状態でAIアシスト開発を開始できます。
—
6. AIフィードバックループの自動化：Git Commit以前の自己修復システム
どれほど強固な `.cursorrules` を書いても、確率的モデルであるAIが100%誤りを回避することは不可能です。重要なのは、「誤った生成コードを人間がレビューする前段階（ローカル）で自動検知し、AI自体に自己修復（Self-Correction）させる閉ループ」 を作ることです。
Husky + Lefthook による「AI生成物の自動判定＆修正リトライ」ループ
Gitの `pre-commit` フックに静的解析とAI CLI（あるいは自作フィードバックループスクリプト）を組み込みます。
lefthook.yml
pre-commit:
parallel: true
commands:
biome-check:
glob: “.{js,ts,jsx,tsx}”
run: npx biome check –apply {staged_files}
stage_fixed: true
type-check:
glob: “.{ts,tsx}”
run: npx tsc –noEmit
さらに、Cursorのコマンドライン・インターフェース（またはローカルのLLMフィードバックフック）を活用して、コンパイルエラー発生時に「エラーログ」を即座にAIへ差分還元するコンテキストフィードバック・スクリプトを構築します。
!/usr/bin/env bash
scripts/ai-self-heal.sh
型チェックを実行し、失敗した場合はエラーログを整形してログ出力（これをComposer/Chatに投入させる）
echo “🔍 TypeScriptコンパイルチェックを開始…”
TS_ERROR=$(npx tsc –noEmit 2>&1)
if [ $? -ne 0 ]; then
echo “❌ 型エラーを検知しました。AI修復用コンテキストを生成します…”
# エラー内容をコンテキストファイルに一時保存
cat << EOF > .cursor/last-error.log
【自動修復命令】
以下のTypeScriptコンパイルエラーが発生しました。
.cursorrules の定義に従い、このエラーを解決する修正コードのみを提示してください。
— エラーログ —
$TS_ERROR
EOF
echo “⚠️ .cursor/last-error.log にエラーが記録されました。Cursor Chatで ‘@last-error.log を修正して’ と指示してください。”
exit 1
fi
echo “✅ 型チェック成功。コミットを許可します。”
—
7. 結論：AIアシスト時代におけるDevOpsアーキテクトの真価
AI時代におけるコーディング規約の管理は、従来の「Wikiにドキュメントを書く」「コードレビューで人間が指摘する」というアプローチから、「プロンプトおよびコンテキスト境界としてコードベースに直接埋め込み、機械的に同期・強制する」 アプローチへと完全にシフトしました。
1. セマンティック構造化: `.cursorrules` をXML/Markdownを用いて型安全に設計する。
2. 動的スコープ管理: `.cursor/rules/.mdc` により、トークン消費量を最適化しつつドメインごとの専門ルールを注入する。
3. CI/CD・AST自動連携: 人間がルールを二重管理せず、Biome/ESLint等の設定からルールを動的ビルドする。
4. 自己修復パイプライン: コンパイルエラーやLinter違反をコンテキストとしてフィードバックし、AIに即座に自己修正させる。
これらのアーキテクチャを導入することで、AIは単なる「気まぐれなコード生成器」から、「プロジェクトの設計思想をミリ単位で理解し、24時間不休で正確なコードを書き続ける究極のペアプログラマー」へと昇華します。開発効率を極限まで引き上げるこの「決定論的AI制御」を、ぜひあなたの現場にも実装してください。