AIエージェントを「部下」として御する：Cursor Composerにおける自律境界線の設計思想
多くのエンジニアがCursorの`Composer (Cmd+I)`にコードを丸投げし、結果として生成されたスパゲッティコードのデバッグに追われる。「AIの自律度」を制御できないことは、CI/CDパイプラインにおいて「テスト未実施のコードを本番環境へデプロイする」のと同じリスクだ。
本稿では、Cursorを単なるエディタではなく、「人間による承認を前提とした自律型開発エージェント」へと昇華させるためのアーキテクチャ設計を解説する。
—
1. AI自律性の「ヒエラルキー」を定義する
AIの自律度を制御するとは、AIに「何を考えさせ、どこで止まらせるか」を設計することだ。私は以下の3段階の境界線を推奨する。
- Level 1: 局所的提案（Inline Chat）
- 関数単位の修正。コンテキストは直近のファイルのみ。即時適用を許容。
- Level 2: 協調型実装（Composer – Review Required）
- 複数ファイルに跨るリファクタリング。`Diff View`で全差分を人間が目視確認するまで`Apply`を禁止する運用。
- Level 3: 自律型CI/CD統合（Custom CLI Integration）
- AIが作成したコードをCLI経由でテストスイートに投げ、Passしたものだけをステージングへ送る運用。
設定の勘所：`.cursorrules`によるガードレールの設置
`.cursorrules`は単なる指示書ではない。AIの「思考のフレームワーク」を強制するシステムプロンプトだ。
.cursorrules: AIエージェントへの行動制約
- 複数ファイルへの変更を行う際は、必ず「変更計画」を冒頭に出力せよ。
- 破壊的変更（APIシグネチャの変更等）を行う前に、影響範囲を特定しユーザーに問い直せ。
- 「Apply All」を前提とせず、人間が確認可能なチャンクサイズ（最大200行）で差分を提示せよ。
- テストコードが存在しない機能追加は禁ずる。必ずテストとセットで実装すること。
—
2. Dockerコンテナ環境でのCursor最適化ハック
Cursorの強みはVS Codeベースである点だが、巨大なモノレポを扱うとメモリ消費が劇的に増大する。Dockerコンテナ内の環境をCursorで操作する場合、「Remote – Containers」の最適化が不可欠だ。
`.devcontainer/devcontainer.json` の高度設定
Cursorが解析する不要なパスを除外することで、AIのコンテキスト汚染を防ぎ、インデックス生成時間を短縮する。
{
“name”: “Production-Ready-Env”,
“customizations”: {
“vscode”: {
“settings”: {
// AI解析対象外とするディレクトリ。ログやビルドキャッシュは除外
“files.watcherExclude”: {
“/target/“: true,
“/dist/“: true,
“/node_modules/“: true
},
// AIの提案速度を上げるため、インデックスの優先順位を制御
“cursor.indexing.exclude”: [“/.min.js”, “/assets/”]
}
}
}
}
—
3. 「人間中心」の承認フロー：ComposerとCI/CDの架け橋
AIの生成物をそのままメインブランチにマージしてはならない。私はCursorのComposer出力をGitの「Worktree」へ流し込み、CLI経由で自動テストを通すワークフローを構築している。
自動検証スクリプト：`validate_ai_changes.sh`
Composerで生成されたコードが「壊れていないか」を担保する、アーキテクト専用の確認スクリプトだ。
!/bin/bash
1. AIが変更したファイルを検知
CHANGED_FILES=$(git diff –name-only)
2. 変更されたファイルに関連するテストのみを抽出して実行
for file in $CHANGED_FILES; do
if [[ “$file” == “src/” ]]; then
test_file=”${file/src/tests}”
echo “Validating: $test_file”
# ユニットテスト実行。ここで落ちればAIの負け
npm test “$test_file” || exit 1
fi
done
3. リントチェックを通す
eslint $CHANGED_FILES –fix
このスクリプトをCursorのターミナルに常駐させ、AIのApply直後に実行する習慣をつける。これが「AIと人間が対等に戦うための作法」だ。
—
4. アーキテクトの視点：なぜ「自律度」を制限するのか
AIエージェントの出力は「確率論的な推論」であり、「論理的な絶対値」ではない。多くのエンジニアが躓くのは、AIを「完璧なプログラマ」として扱っている点だ。
- メモリ消費の真相: Composerはコンテキストウィンドウ（LLMの入力長）を大量に消費する。不要なファイルをAIに読み込ませることは、精度を下げるだけでなく、トークンコストを無駄に浪費する。
- 人間中心の意義: あなたの役割はコードを書くことではなく、「AIが書いたコードの論理的整合性を検証する」ことだ。Composerの差分確認画面（Diff View）は、あなたの脳内のレビュープロセスを外部化した「拡張現実」である。
結びに：Cursorを「使いこなす」のではなく「組み込む」
Cursorはエディタではない。あなたの開発パイプラインにおける強力な「計算リソース」だ。
1. AIの自律度を絞る: `.cursorrules`で制限をかける。
2. 検証を自動化する: CI/CDとローカルCLIの整合性を取る。
3. 人間は「意思決定」に集中する: 実装の退屈な部分はすべてAIに投げる。
もしあなたが、AIにすべてを委ねることに不安を感じているのなら、その直感は正しい。その不安こそが、シニアエンジニアとしてあなたが持つべき最後の砦である。その砦を守りつつ、Cursorという最強の武器を使いこなせ。
我々の仕事は、ツールに支配されることではなく、ツールを意のままに操り、プロダクトの価値を最大化することなのだから。