⟐ Claude Code/2026-04-19上級

Claude Code × Cursor × Devin Desktop（旧 Windsurf）— 3ツールを使い分けるハイブリッド開発環境の実践設計

Claude Code・Cursor・Devin Desktop（旧 Windsurf）をタスク別に使い分ける設計手順。ディレクトリルールへ同期するスクリプトを、5回連続実行の実測つきで解説します。

Claude Code²⁶⁵ Cursor⁴Devin DesktopWindsurfAI開発ハイブリッドワークフロー開発環境⁷ 2026¹⁵

✦ プレミアム記事

朝いちばんに Cursor を開いたら、補完が Pages Router の書き方を提案してきました。そのプロジェクトは半年前に App Router へ移し終えています。設定ファイルは同期スクリプトで揃えているはずでした。

原因にたどり着いたのは、午前をまるごと使ってからです。ツール側が設定の置き場所を増やしていて、私のスクリプトは古い方だけを書き換え続けていました。同期は成功していました。ただ、誰も読まないファイルに向かって成功していたのです。

Claude Code・Cursor・Devin Desktop（旧 Windsurf）— この3つは設計思想が異なり、得意なタスクもはっきり違います。どれが優れているかを比べるより、どの場面でどれを使うかを決めておく方が、開発速度には素直に効きます。ただしその使い分けが成立するのは、3つが同じ前提を読んでいる間だけです。前提がずれた瞬間、使い分けは速度ではなく事故を生みます。

複数のモバイルアプリとコンテンツサイトを個人で運営しながら、この組み合わせを試してきました。最初は1つに統一すべきだと思っていましたが、今は逆の考えです。用途ごとに切り替える設計と、その前提を機械的に揃える仕組み。この2つを対にして初めて、ハイブリッド環境は使いものになります。

1. 3ツールの設計思想を正確に把握する

ハイブリッドワークフローを設計する前に、まず各ツールの「本質的な強み」を理解することが必要です。比較記事では速度や価格が前面に出がちですが、設計思想の違いを理解すると、使い分けの判断が格段に楽になります。

Claude Code — エージェント型・ターミナルネイティブ

Claude Code は IDE への依存を意図的に排除した、ターミナルから直接動作するエージェントです。最大の特徴は、CLAUDE.md を通じてプロジェクト全体の文脈をセッション間で維持できること、そしてサブエージェントを並列で起動できる真のマルチエージェント実行環境を持っていることです。

# Claude Code の起動（プロジェクトルートで）
claude
 
# 並列サブエージェントを使った大規模タスク
claude "src/ 配下の全コンポーネントを確認し、型エラーを修正して。
フロントエンドとバックエンドを並列で作業してよい"

Claude Code が本領を発揮するのは以下の場面です。

アーキテクチャの設計と判断（「このリファクタリングは正しいか？」）
大規模な横断的変更（複数ファイルにまたがる修正）
CI/CD・デプロイの自動化（GitHub Actions・Cloudflare Workers への連携）
コードレビューとドキュメント生成（PR レビュー・CLAUDE.md の更新）

Cursor — インライン補完・IDE 統合

Cursor は VSCode をベースに構築された IDE で、既存の開発環境に最も自然に溶け込みます。インライン補完（Tab）とチャット（Cmd+L / Cmd+K）の組み合わせで、コードを書きながらリアルタイムに AI のサポートを受けられます。

Cursor が本領を発揮するのは以下の場面です。

既存コードのインライン修正・リファクタリング（選択してCmdK）
単一ファイルまたは少数ファイルの実装
補完ベースの高速な定型コード生成
デバッグ中の素早い修正（エラーメッセージをそのままチャットに貼る）

// ❌ 修正前: エラーハンドリングなし
async function fetchUser(id: string) {
  const res = await fetch(`/api/users/${id}`)
  return res.json()
}
 
// ✅ Cursor で "Cmd+K → エラーハンドリング付きで書き直して" した後
async function fetchUser(id: string): Promise<User | null> {
  try {
    const res = await fetch(`/api/users/${id}`)
    if (!res.ok) {
      console.error(`ユーザー取得失敗 ${id}: ${res.status}`)
      return null
    }
    return res.json() as Promise<User>
  } catch (error) {
    console.error(`ユーザー取得エラー ${id}:`, error)
    return null
  }
}

エラーが出たら Cursor のチャットにそのままペーストして「これを直して」と言うだけで済む — この手軽さが Cursor の最大の強みです。デバッグ中のコンテキストスイッチが最小で済みます。

Devin Desktop（旧 Windsurf）— エージェント管理型 IDE

この3ツールのうち、名前が最も動いたのがこれです。経緯を押さえておくと混乱せずに済みます。Codeium が 2025 年 4 月に Windsurf へ改名し、同年 7 月に Cognition が買収。そして 2026 年 6 月 2 日に Devin Desktop へ再改名されました。OTA アップデートで配信され、プラン・価格・拡張機能・キーバインドはそのまま引き継がれています。既存ユーザーが何かを移行する必要はありませんでした。

実務に効くのは名前より中身です。長尺タスクを担っていた Cascade は、Devin Local という後継に置き換わりました。公式の告知によれば、Rust で一から書き直され、トークン効率は最大 30% 改善し、サブエージェントに対応しています。移行用に残されていた旧 Cascade は 7 月で提供終了しました。手元で「Cascade が見当たらない」と探している場合は、まず更新が止まっていないかを疑ってください。

もう一つ、ハイブリッド運用に直接効く変更があります。Devin Desktop は Agent Client Protocol（ACP）に対応し、Codex・Claude Agent・OpenCode といった他社エージェントを同じ画面の中で動かせるようになりました。「ツールを行き来する」という前提そのものが、少しずつ「1つの画面に複数のエージェントを並べる」方向へ動いています。この記事の使い分けの考え方は、その並べ方を決める判断としてそのまま使えます。

Devin Desktop が本領を発揮するのは以下の場面です。

複数ファイルにまたがる新機能の実装（エージェントがステップを追跡）
既存コードの理解と説明（コードベース全体の把握）
設計書・仕様書から実装への変換（長いドキュメントを起点にした実装）
テストコードの一括生成（複数コンポーネントのテストをまとめて作成）

3ツールは、力を発揮する領域そのものが違います。1つの道具で全てを叩こうとするのではなく、場面に応じて持ち替えます。この発想の転換が、ハイブリッドワークフローの出発点です。

2. タスク別ツール使い分けフレームワーク

3ツールの特性を理解した上で、実際の開発フローでどのように使い分けるかを整理します。以下の判断フレームワークを私は日常的に使っています。

判断フレームワーク

タスクの性質 → 推奨ツール

① プロジェクト全体の構造を変える
  └→ Claude Code（CLAUDE.md の知識を活かして横断的に対応）

② 特定のファイルを素早く修正・リファクタ
  └→ Cursor（インライン編集が最も高速）

③ 新機能を0から複数ファイルにまたがって実装
  └→ Devin Desktop（エージェントがプロセスを追跡）

④ CI/CD・デプロイ・インフラの自動化
  └→ Claude Code（ターミナルでの実行権限が最も広い）

⑤ コードレビュー・ドキュメント生成
  └→ Claude Code（プロジェクト文脈の理解が深い）

⑥ デバッグ中のエラー修正（エラー → 修正のサイクル）
  └→ Cursor（エラーコンテキストをチャットに即貼れる）

実際の開発セッションの流れ

Next.js アプリで「認証機能をゼロから追加する」タスクを想定した場合、私はこう動かします。

Step 1: Claude Code で設計を固める

claude "src/app に NextAuth.js v5 を使った認証機能を追加したい。
現在のプロジェクト構造（CLAUDE.md を参照）を踏まえて、
どのファイルを作成・修正すれば良いか設計案を出して。
実装はまだしなくてよい"

Claude Code は CLAUDE.md を参照しながら、既存の設計に沿った具体的なファイル構成・データフロー・注意点を出力します。

Step 2: Devin Desktop でスキャフォールディング

Claude Code の設計案をそのまま貼り付けて実装を依頼します。複数ファイルを順番に生成しながら、進捗が Kanban ビューで追えます。

Step 3: Cursor で細部を調整

生成されたコードの型エラーや、プロジェクト固有の命名規則に合わない部分を、インライン編集で素早く修正します。

Step 4: Claude Code で最終確認とテスト生成

claude "実装した認証機能のユニットテストを生成して、
セキュリティ上の問題がないか確認して"

このサイクルを回すと、1つのツールだけを使うよりも作業が明らかに速くなります。特に「設計 → 実装 → 修正 → 確認」の各フェーズで最適なツールを使えるため、それぞれのフェーズでのやり直しが大幅に減ります。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦「ツールを1つに絞れない」という悩みを解消し、Claude Code・Cursor・Windsurf を目的別に使い分けるシステムを今日から導入できる

✦3ツールそれぞれが本領を発揮するタスクの見極め方と、設定ファイルを同期して切り替えコストをゼロに近づけるワークフロー設計を習得できる

✦設定同期スクリプトが2回目以降に静かに壊れる原因と、マーカー方式で冪等にする書き直し方を、実行前後の行数とともに確認できる

✦`.cursorrules` と `.windsurfrules` が旧形式になった現在の優先順位を把握し、ディレクトリルールへ同期を移す実装と5回連続実行の実測を持ち帰れる

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

3. ハイブリッド環境のセットアップ：設定ファイルの同期

3ツールを使い分ける際の最大の課題は、「各ツールがプロジェクトの文脈を別々に持ってしまう」という問題です。Claude Code には CLAUDE.md、Cursor と Devin Desktop にはそれぞれのルールファイル — これらを同期するための設計が必要です。

先に結論を書いておきます。この章で扱う同期スクリプトは、2 回書き直しています。1 度目は 2 回目以降の実行で壊れたため、2 度目はツール側が設定の置き場所を変えたためです。順を追って両方お見せします。同じ落とし方を再現できるようにしておきたいからです。

設定ファイルのヒエラルキー設計

私が採用しているのは、CLAUDE.md を single source of truth にして、他ツールの設定ファイルにはそのエッセンスを展開するという方法です。

プロジェクトルート/
├── CLAUDE.md              ← 主設定（詳細・包括的）
├── .cursorrules           ← Cursor 用（※ 現在は旧形式。後述）
├── .windsurfrules         ← Devin Desktop 用（※ 同上）
└── .ai-rules/
    └── shared-context.md  ← 3ツール共通のルール（共有元）

この構成は今も動きますが、2026 年時点では両ツールとも「単一ファイル」が旧形式の扱いになっています。まず素朴なスクリプトが壊れる話を片付けてから、現行の形式へ移ります。

.cursorrules の例（CLAUDE.md から抽出した要点）：

# Project Rules for Cursor
 
## Tech Stack
- Next.js 16 (App Router) + TypeScript strict mode
- Tailwind CSS + shadcn/ui
- Cloudflare Workers (edge runtime) — Node.js APIs は使用不可
- next-intl v4 for i18n (ja/en)
 
## Critical Rules
- サーバーコンポーネントでは 'use client' を付けない
- API routes は /app/api/ 以下に置く
- 環境変数は process.env. で参照
 
## Naming Conventions
- コンポーネント: PascalCase (ArticleCard.tsx)
- ユーティリティ: camelCase (formatDate.ts)
 
## Code Style
- エラーハンドリング必須（try-catch または Result 型）
- 非同期処理は async/await のみ（Promise.then は使わない）
- コメントは日本語で記載

CLAUDE.md は詳細な設計思想・歴史的経緯・複雑なルールを含む包括的なドキュメントですが、Cursor の .cursorrules は補完時に都度読み込まれるため、短くして本当に重要なルールだけを書くのがポイントです。

設定の自動同期スクリプト：素朴に書くと壊れます

3ツールの設定を手動で同期するのは手間なので、スクリプト化して Git フックから呼びたくなります。ただ、ここには落とし穴があります。私が最初に書いたのは、こういう素朴なものでした。

#!/bin/bash
# scripts/sync-ai-rules.sh（※ このバージョンには不具合があります）
set -e
 
PROJECT_ROOT="$(git rev-parse --show-toplevel)"
SHARED="${PROJECT_ROOT}/.ai-rules/shared-context.md"
CURSOR_RULES="${PROJECT_ROOT}/.cursorrules"
 
if [ ! -f "$SHARED" ]; then
  echo "⚠ .ai-rules/shared-context.md が見つかりません"
  exit 0
fi
 
if [ -f "$CURSOR_RULES" ]; then
  tmp=$(mktemp)
  echo "# === 共通ルール (shared-context.md より自動生成) ===" > "$tmp"
  cat "$SHARED" >> "$tmp"
  echo "" >> "$tmp"
  echo "# === Cursor 固有のルール ===" >> "$tmp"
  # 既存の .cursorrules から「共通ルール」セクションを除いた部分を追記
  grep -v "=== 共通ルール" "$CURSOR_RULES" >> "$tmp" || true
  mv "$tmp" "$CURSOR_RULES"
fi
 
echo "✅ .cursorrules を更新しました"
echo "✅ .windsurfrules を更新しました"

一見きちんと動きそうに見えます。実際、1回走らせただけでは何も問題は起きません。

問題は 2 回目以降でした。切り出し用の空ディレクトリで、shared-context.md を 7 行・.cursorrules を 2 行にして、このスクリプトを 5 回連続で実行してみます。

実行回数	.cursorrules の行数	共通ルール本文の重複数
実行前	2	0
1 回目	12	1
2 回目	21	2
3 回目	30	3
4 回目	39	4
5 回目	48	5

コミットのたびに 9 行ずつ増え続けます。原因は grep -v "=== 共通ルール" にあります。これが消しているのは見出しの 1 行だけで、その下にぶら下がる共通ルールの本文はそのまま残ります。残った本文の上に、新しい共通ルールがもう一度積まれます。その繰り返しでした。

しかも .windsurfrules については、成功メッセージだけが出ていて、ファイルには一度も触れていません。実際に diff を取ると、実行前と完全に同一でした。「✅ 更新しました」という表示を信じていた期間、Windsurf だけが古い文脈を読み続けていたことになります。

厄介なのは、このバグが後述する落とし穴④（設定ファイルの肥大化）を自分で作り出す点です。肥大化を防ぐために作った仕組みが、肥大化の原因になっていました。気づいたのは、Cursor の補完が妙に古いルールを引きずるようになってからです。

冪等に書き直す

直し方はシンプルで、「自動生成領域」をマーカーで囲み、毎回そのブロックごと差し替えるという形にします。行単位の grep ではなく、開始マーカーから終了マーカーまでを範囲として捨てるのがポイントです。

#!/bin/bash
# scripts/sync-ai-rules.sh
# .ai-rules/shared-context.md を .cursorrules / .windsurfrules に展開する
set -euo pipefail
 
BEGIN="<!-- AI-RULES:BEGIN -->"
END="<!-- AI-RULES:END -->"
 
PROJECT_ROOT="$(git rev-parse --show-toplevel)"
SHARED="${PROJECT_ROOT}/.ai-rules/shared-context.md"
 
if [ ! -f "$SHARED" ]; then
  echo "⚠ .ai-rules/shared-context.md が見つかりません" >&2
  exit 1
fi
 
sync_one() {
  target="$1"
  [ -f "$target" ] || : > "$target"
  tmp="$(mktemp)"
  {
    echo "$BEGIN"
    echo "# このブロックは shared-context.md から自動生成されます。直接編集しないでください。"
    cat "$SHARED"
    echo "$END"
    # 既存ファイルから自動生成ブロックだけを範囲で除去し、固有ルールは残す
    awk -v b="$BEGIN" -v e="$END" '
      index($0, b) { skip = 1; next }
      index($0, e) { skip = 0; next }
      !skip { print }
    ' "$target"
  } > "$tmp"
 
  if cmp -s "$tmp" "$target"; then
    rm -f "$tmp"
    echo "= $(basename "$target") は変更なし"
  else
    mv "$tmp" "$target"
    echo "✅ $(basename "$target") を更新しました"
  fi
}
 
sync_one "${PROJECT_ROOT}/.cursorrules"
sync_one "${PROJECT_ROOT}/.windsurfrules"

同じ条件で 5 回連続実行した結果です。

実行回数	.cursorrules	.windsurfrules	共通ルール本文の重複数	出力
1 回目	12 行	12 行	1	✅ 更新しました
2〜5 回目	12 行	12 行	1	= 変更なし

行数が動かなくなりました。.cursorrules 側の「補完は日本語コメントで」も、.windsurfrules 側の「エージェントは型定義から進める」も、マーカー外にあるため保持されています。shared-context.md に 1 行足して再実行すると 13 行になり、差分もきちんと伝わります。

意図的に入れた要素が 3 つあります。

set -euo pipefail — 未定義変数と、パイプ途中の失敗も検出します。元の set -e だけでは grep の失敗が || true で握り潰されていました
exit 1（元は exit 0）— 共有ファイルが無いのは設定ミスです。Git フックから呼ぶスクリプトが黙って成功を返すと、事故に気づく機会そのものが失われます
cmp -s による差分判定 — 「変更なし」と「更新しました」を区別します。ログが正直になると、同期が効いているかを目で確認できます

そして .git/hooks/post-commit に登録します。フック側の設計を詰めたい場合は、Claude Code Hooks の設定と運用に踏み込んだ内容をまとめています。

#!/bin/bash
if git diff HEAD~1 --name-only | grep -q "CLAUDE.md\|shared-context.md"; then
  echo "📝 AI 設定ファイルを同期中..."
  bash scripts/sync-ai-rules.sh
fi

自動化スクリプトは、書いた直後ではなく 2 回目以降の挙動で評価します。3ツールを跨ぐ仕組みを作るときに、私が一番高い授業料を払って覚えたことです。

単一ファイル形式は、両ツールとも旧形式になりました

冒頭に書いた「補完が Pages Router を提案してきた朝」の原因が、ここです。上の冪等版スクリプトは正しく動いていました。ただ、書き込む先が現行の読み取り先ではなくなっていました。

2026 年時点の状況を整理します。Cursor は 2024 年末に .cursorrules を旧形式とし、.cursor/rules/ 配下の .mdc ファイルへ移行しました。Devin Desktop 側も同様で、公式 FAQ には .devin/rules/ が推奨の置き場所でありそちらが優先されると明記されています。.windsurfrules と .windsurf/rules/ は後方互換として読まれ続けますが、あくまでフォールバックです。なお .devinrules という単一ファイル形式は存在しません。

ツール	旧形式（読まれるが後方互換）	現行形式（優先）
Cursor	`.cursorrules`	`.cursor/rules/*.mdc`
Devin Desktop	`.windsurfrules` / `.windsurf/rules/`	`.devin/rules/`

「後方互換なら困らないのでは」と思うかもしれません。困るのは、両方が存在するときです。切り出した空ディレクトリで再現してみます。共通ルールに Next.js 16 と書いて同期スクリプトを走らせ、その状態で古い内容の .devin/rules/stack.md を置きます。

# 同期スクリプトは成功している
$ grep -o 'Next.js [0-9]*' .windsurfrules
Next.js 16
 
# しかし優先されるのはこちら
$ grep -ho 'Next.js [0-9]*' .devin/rules/*.md
Next.js 14

スクリプトは .windsurfrules を正しく更新し、正しく成功を報告します。読まれているのは .devin/rules/ の方です。差分もエラーも出ないまま、エージェントだけが古い前提で動き続けます。落とし穴①（コンテキストの矛盾）を、同期の仕組み自身が作り出している状態でした。

ディレクトリルールへ同期を移す

書き直したのが以下です。出力先をディレクトリにし、自動生成ファイルを固定名の 1 本に限定します。手書きのルールは別ファイルとして残るため、マーカーで囲む必要すらなくなりました。

#!/bin/bash
# scripts/sync-ai-rules.sh
# .ai-rules/shared-context.md を各ツールのディレクトリルールへ展開する
set -euo pipefail
 
ROOT="$(git rev-parse --show-toplevel)"
SHARED="${ROOT}/.ai-rules/shared-context.md"
GEN_NAME="00-shared-context"   # 自動生成ファイルは必ずこの名前
 
if [ ! -f "$SHARED" ]; then
  echo "⚠ .ai-rules/shared-context.md が見つかりません" >&2
  exit 1
fi
 
# $1=出力先ディレクトリ  $2=拡張子  $3=フロントマター
write_rule() {
  dir="$1"; ext="$2"; front="$3"
  mkdir -p "$dir"
  target="${dir}/${GEN_NAME}.${ext}"
  tmp="$(mktemp)"
  { printf '%s\n' "$front"; cat "$SHARED"; } > "$tmp"
  if [ -f "$target" ] && cmp -s "$tmp" "$target"; then
    rm -f "$tmp"; echo "= ${target#$ROOT/} 変更なし"
  else
    mv "$tmp" "$target"; echo "✅ ${target#$ROOT/} を更新"
  fi
}
 
write_rule "${ROOT}/.cursor/rules" "mdc" \
'---
description: Project-wide shared context
alwaysApply: true
---'
 
write_rule "${ROOT}/.devin/rules" "md" \
'---
trigger: always_on
---'
 
# 単一ファイル形式が残っていると優先順位で事故るので明示的に知らせる
for legacy in "${ROOT}/.cursorrules" "${ROOT}/.windsurfrules"; do
  [ -f "$legacy" ] && echo "⚠ レガシー形式が残っています: ${legacy#$ROOT/}（ディレクトリルールが優先されます）" >&2
done
exit 0

同じ空ディレクトリで、手書きルール（90-local.mdc / 90-local.md）を置いた状態から 5 回連続で実行した結果です。

実行回数	.cursor/rules/00-shared-context.mdc	.devin/rules/00-shared-context.md	ルールファイル総数	出力
1 回目	10 行	9 行	4	✅ 更新
2〜5 回目	10 行	9 行	4	= 変更なし

行数もファイル数も動きません。手書きの 90-local は 2 本とも中身を保ったままでした。共通ルールに 1 行足して再実行すると 11 行・10 行になり、差分はきちんと伝わります。行数が 2 種類あるのは、Cursor の .mdc が 4 行のフロントマターを、Devin 側が 3 行を持つためです。

そして最後のループが効きます。旧形式が残っている限り、実行のたびに警告が出ます。

⚠ レガシー形式が残っています: .cursorrules（ディレクトリルールが優先されます）
⚠ レガシー形式が残っています: .windsurfrules（ディレクトリルールが優先されます）

私はこれを消すまでに数日かかりました。消す作業そのものは 1 分です。かかったのは、旧ファイルに書いてあった内容のうち、どれがまだ有効なのかを確かめる時間でした。移行は形式の変換ではなく、棚卸しです。

同期先が読まれているかを、カナリアで確かめる

置き場所には追随できました。それでも私は、同じ朝をもう一度迎えたくありませんでした。同期が成功したことと、その結果がエージェントに届いていることは、別の事実だからです。

そこで、生成する各ルールファイルの先頭に合言葉を 1 行だけ埋めることにしました。CANARY: <同期した日付> と書いておき、作業を始める前にエージェントへ「CANARY の値をそのまま返してください」と尋ねます。返ってきた値が古ければ、読まれているのは別のファイルです。

合言葉を尋ねる前に、どのファイルが優先されるのかを機械的に並べる短いスクリプトを置いておきます。

#!/bin/bash
# scripts/check-rules.sh — 実際に読まれる側を優先順つきで一覧にする
set -uo pipefail
ROOT="${1:-$PWD}"
 
report() { # $1=ツール名  $2.. = 優先順の候補（先頭が最優先）
  local tool="$1"; shift
  local winner=""
  for cand in "$@"; do
    local found
    found=$(find "$ROOT/$cand" -maxdepth 1 -type f 2>/dev/null | head -1)
    [ -z "$found" ] && [ -f "$ROOT/$cand" ] && found="$ROOT/$cand"
    if [ -n "$found" ]; then
      if [ -z "$winner" ]; then winner="$found"; echo "  [有効] $cand"
      else echo "  [無視] $cand  ← 上に負けています"; fi
    fi
  done
  [ -z "$winner" ] && { echo "  [なし] ルールファイルが見つかりません"; return; }
  echo "  canary: $(grep -h -m1 'CANARY:' "$winner" 2>/dev/null || echo '(なし)')"
}
 
echo "Cursor";        report Cursor ".cursor/rules" ".cursorrules"
echo "Devin Desktop"; report Devin  ".devin/rules" ".windsurf/rules" ".windsurfrules"

冒頭の朝と同じ状態を、切り出した作業ディレクトリで作って走らせた結果が以下です。同期スクリプトは旧形式に Next.js 16 を書き込み、現行形式には古い前提が残っています。

$ ./check-rules.sh .
Cursor
  [有効] .cursor/rules
  [無視] .cursorrules  ← 上に負けています
  canary: CANARY: STALE-0401
Devin Desktop
  [有効] .devin/rules
  [無視] .windsurf/rules  ← 上に負けています
  [無視] .windsurfrules  ← 上に負けています
  canary: CANARY: STALE-0401

$ grep -o 'Next.js [0-9]*' .windsurfrules
Next.js 16

同期は Next.js 16 を書き込んで成功しています。それでも、読まれる側の合言葉は STALE-0401 のままです。成功の報告は、届いたことの証拠になりません。 私が午前をまるごと使ったのは、この 2 つを同じものだと思っていたからでした。

置き場所への追随は、一度やれば終わります。読まれている側を確かめる手順は、置き場所が動くたびに効きます。

ディレクトリ形式にした本当の見返り

置き場所を追随しただけなら、ただの追従作業です。実際に得たものは別のところにありました。ディレクトリ形式のルールはフロントマターで発火条件を持てます。常時適用・モデルが関連を判断したとき・glob に一致するファイルのとき・手動で呼んだときの 4 通りです。

---
description: Cloudflare Workers 固有の制約
globs: ["src/lib/**/*.ts", "src/app/api/**/*.ts"]
---
Node.js API（fs / path / crypto）は使用不可。
ASSETS バインディングは getCloudflareContext() から env を取得して使う。

単一ファイル形式は、内容に関係なく毎リクエスト読み込まれます。CSS を直しているときにも Workers の制約が同送されます。これが後述する落とし穴④（設定ファイルの肥大化）の正体でした。glob で絞れるようになった時点で、肥大化は「定期的に削る」問題から「そもそも該当時しか載せない」問題に変わります。

もう一点、実務上ありがたい変更があります。Devin Desktop は AGENTS.md も読み、.cursor/rules の .mdc を .devin/rules/ へ取り込めます。ツール間で設定を手で書き写す時代は、静かに終わりつつあります。

4. 実践：Cloudflare Workers プロジェクトでの3ツール連携例

具体的なシナリオで3ツールの連携を見ます。「既存の Next.js + Cloudflare Workers アプリに記事管理機能を追加する」タスクを例にします。Cloudflare Workers 環境特有の制約（Node.js API 不可・バンドルサイズ制限・ASSETS バインディング）を扱うため、ツールの正確なプロジェクト理解が重要になります。

Phase 1: Claude Code で設計

claude "このプロジェクトに MDX ベースの記事管理機能を追加したい。
Cloudflare Workers の 62 MiB バンドル制限と ASSETS バインディングの
制約を踏まえた設計を出して。CLAUDE.md の Content Split Architecture
を参考にして"

Claude Code が CLAUDE.md の「Content Split Architecture」セクションを参照し、既存設計に沿った提案を出力します。ここが Claude Code の強みです — プロジェクト固有の制約を文脈として保持したまま設計提案できる点で、汎用チャット AI や他ツールとは質が異なります。

Phase 2: Devin Desktop で実装

Claude Code の設計案をそのまま渡して実装します：

【設計書要約】
- content/articles/{ja,en}/{category}/{slug}.mdx
- src/generated/articles.json (メタデータのみ)
- public/content/articles/{locale}/{category}/{slug}.html (HTML本文)
- src/lib/content.ts に getArticleContent() を追加

【依頼】
この設計に従って、型定義 → generateContent スクリプト →
content.ts の関数 → ページコンポーネントの順で実装して。
各ステップで動作確認コマンドも一緒に示して

エージェントがステップを追いながら実装します。各ステップで「次は何をするか」を明示するため、長い実装中でもどこにいるかを見失いにくいです。

Phase 3: Cursor で細部を調整

生成された getArticleContent() を確認すると、Cloudflare Workers 環境に合っていない部分があります。

// ❌ 生成されたコード（Workers 環境では動作しない）
import fs from 'fs'  // Node.js API — Workers では使用不可
 
export async function getArticleContent(slug: string): Promise<string> {
  const filePath = `./public/content/articles/${slug}.html`
  return fs.readFileSync(filePath, 'utf-8')  // Node.js API
}

この部分を Cursor で選択して Cmd+K：

"Cloudflare Workers 環境では fs モジュールが使えない。
ASSETS バインディングを使って fetch する方法に書き直して。
getCloudflareContext() から env を取得して使う"

// ✅ Cursor が修正したコード（Workers 対応）
import { getCloudflareContext } from '@opennextjs/cloudflare'
 
export async function getArticleContent(
  locale: string,
  category: string,
  slug: string
): Promise<string | null> {
  try {
    const { env } = await getCloudflareContext()
    const path = `/content/articles/${locale}/${category}/${slug}.html`
    
    // ASSETS バインディング経由でHTMLを取得
    const res = await env.ASSETS.fetch(
      new URL(path, 'https://placeholder.example.com')
    )
    
    if (!res.ok) {
      console.error(`記事コンテンツ取得失敗: ${path} (${res.status})`)
      return null
    }
    
    return res.text()
  } catch (error) {
    console.error(`記事コンテンツ取得エラー:`, error)
    return null
  }
}

Cursor の「インラインで即修正」が光る場面です。Claude Code に依頼するより速く、コンテキストスイッチも最小で済みます。

Phase 4: Claude Code で最終確認

claude "実装した記事管理機能を確認して：
1. TypeScript のコンパイルエラーがないか tsc --noEmit で確認
2. CLAUDE.md の禁止事項（workers での self-fetch 等）に違反がないか
3. 本番想定の負荷でボトルネックになる箇所はないか
問題があれば修正して"

Claude Code はプロジェクト全体の設計を知っているため、「これは CLAUDE.md の #74 の制約に引っかかる」という指摘を適切に行えます。ここが他のツールでは代替できない Claude Code の真価です。

5. コスト最適化戦略

3ツールを使い分けると、コストの管理が複雑になります。私が実践しているコスト最適化のアプローチを共有します。

コストの考え方

個人開発者・月40〜60時間の開発量で、私は Claude Code の上位プランを軸に、Cursor と Devin Desktop をそれぞれの下位プランで併用しています。金額は各社とも改定が入るため、契約前に公式の料金ページで確認してください。Devin Desktop への改名時はプラン・価格とも据え置きで、既存の Windsurf 契約がそのまま引き継がれています。

三重課金に見えますが、実際のトークン消費は分散します。Claude Code は重いアーキテクチャ判断にだけ使い、Cursor の補完は軽量に保ちます。この配分にしてから、Claude Code 側の上限に触れることがほぼなくなりました。合計額よりも、一番高いプランを一番安い用途に使っていないかを点検する方が効きます。

Claude Code のコスト節約のための使い方

# ❌ 非効率（コンテキストを無駄に使う — 一度に詰め込みすぎ）
claude "src/components/ の全コンポーネントを確認して、
全ての useState を useReducer に書き換えて、
その後テストも書いて、最後にドキュメントも更新して"
 
# ✅ 効率的（タスクを分割してセッションを分ける）
claude "src/components/UserCard.tsx の useState を useReducer に書き換えて"
# 完了したら別のセッションで次のコンポーネント

また、Cursor での補完を積極的に使うことで Claude Code の使用量を抑えられます。「Cursor で書けるものは Cursor で書く、Claude Code はどうしても必要なときだけ」という意識を持つだけで、Claude Code 側の消費は目に見えて軽くなりました。削減率は扱うリポジトリの規模で変わるため数字は挙げませんが、上限に触れる頻度が下がったことは請求の履歴ではっきり分かりました。

Devin Desktop でのコスト管理

長いエージェントセッションはクレジット消費が大きいため、大きな機能実装を1回のセッションで完結させるよう意識します。途中で止めて再開を繰り返すよりも、1回で最後まで動かす方が効率的です。Devin Local はトークン効率が最大 30% 改善しているため、旧 Cascade 時代の感覚より1セッションで踏み込める範囲は広がっています。

# エージェントへの指示の良い例
【タスク】認証機能の実装（6ファイル）
【完了条件】全ファイルが作成され、TypeScript のコンパイルエラーがゼロになること
【制約】Cloudflare Workers 環境なので Node.js API は使用しない
【進め方】型定義 → ユーティリティ → ページコンポーネント → API ルート の順で進めて。
        各ステップ完了後に「次は〇〇に進みます」と報告して

完了条件を明示することで、エージェントが途中で迷走するのを防げます。

6. よくある間違いと落とし穴

3ツールを使い始めてぶつかりやすい問題を具体的にまとめます。

落とし穴① コンテキストの矛盾

同じプロジェクトを3ツールで扱うと、それぞれのコンテキストが矛盾することがあります。Devin Desktop で実装したコードを Claude Code が「CLAUDE.md の設計と違う」と判断するケースがその典型です。前章で見たとおり、同期スクリプトが古い置き場所を更新し続けているだけ、という場合もあります。矛盾を見つけたら、人間の運用を疑う前に読み取り先を確認してください。

解決策: 実装方針を変更したら、必ず CLAUDE.md を更新します。

# 実装後に CLAUDE.md を更新する習慣をつける
claude "今日の実装で判明したことを CLAUDE.md に追記して：
- UserCard コンポーネントは useReducer で状態管理することに決めた
- ASSETS バインディングでは new URL() でパスを構築すること"

CLAUDE.md が常に「現在の正しい状態」を反映していれば、3ツール間の矛盾は大幅に減ります。

落とし穴② 生成コードの理解不足

「エージェントが全部やってくれた」という達成感の後、実はそのコードをほとんど理解していないという状況に陥ることがあります。コードの品質が下がり、後からバグが出たときに修正できなくなります。

解決策: 生成されたコードは必ず Claude Code にレビューさせ、自分でも重要部分を読む習慣をつけます。「AIが書いたから」ではなく「私が理解して採用した」というスタンスを保つことが、長期的な品質維持に直結します。

# エージェント実装後の必須レビューコマンド
claude "生成された認証機能を確認して。
理解しておくべき重要なロジックを3点、
想定されるバグのリスクを2点、挙げて"

落とし穴③ ツール切り替えの迷い

3ツールを使い分けると、「どのツールを使うか」判断するオーバーヘッドが発生します。特に慣れないうちは、判断に時間がかかって逆に非効率になることがあります。

解決策: 最初の1ヶ月は「迷ったら Cursor」というルールを設けてください。Cursor は最も汎用的で、何でもある程度こなせます。Claude Code と Devin Desktop に手を伸ばすのは、Cursor では明らかに不足だと感じたときに限定します。慣れてきたら徐々に使い分けを細かくしていきます。

落とし穴④ 設定ファイルの肥大化

設定ファイルが膨らむと、指示の密度が下がります。私自身、運用ドキュメントが伸び続けた結果、履歴部分を別ファイルへ退避して現行ルールだけを残す再構成をしたことがあります。読ませたい規則が、読ませなくてよい経緯に埋もれていたためです。

解決策は 2 段構えです。 まず、常時読ませるルールは「禁止事項」と「決定済み設計」に絞ります。経緯や検討過程は別ファイルへ逃がします。そのうえで、前章の発火条件を使います。特定のディレクトリでしか効かない制約は glob で縛れば、無関係な作業中には載りません。定期的に削る運用と、そもそも該当時しか載せない構造。後者の方が長持ちします。

# CLAUDE.md の月次メンテナンス
claude "CLAUDE.md を確認して、
現在のプロジェクト状態と合っていないルールや、
重複しているルールを整理して。削除前に理由を説明して"

落とし穴⑤ セキュリティ設定の見落とし

3ツールを使い分けていると、セキュリティ設定が抜け落ちることがあります。特に Claude Code のパーミッション設定と、Cursor・Devin Desktop でのコードベース除外設定が不一致だと、意図しないファイルが参照されるリスクがあります。

解決策: .gitignore に加えて、各ツールの「除外ファイル設定」を揃えます。

# .cursorignore（.gitignore と揃える）
.env
.env.local
.env.production
**/secrets/**
**/credentials/**
node_modules/

Claude Code では CLAUDE.md に「APIキーや認証情報をコードに直接書かない」というルールを明記し、MCP サーバーの接続情報なども除外します。

7. チーム開発での運用設計

個人開発では比較的自由に試せますが、チームでは「AI ツールの使い方を統一する」ことが重要になります。

チーム共通の設定管理

.ai-rules/                ← 共有元（人間が編集するのはここだけ）
└── shared-context.md

.cursor/rules/            ← 生成物 + 手書きの Cursor 固有ルール
├── 00-shared-context.mdc （自動生成・直接編集しない）
└── 90-*.mdc

.devin/rules/             ← 生成物 + 手書きの Devin 固有ルール
├── 00-shared-context.md  （自動生成・直接編集しない）
└── 90-*.md

scripts/
└── sync-ai-rules.sh

数字の接頭辞は、自動生成分と手書き分を目で見て区別するためのものです。00- は触らない、90- は自由に書く。チームに入ったばかりの人が最初に迷うのはここなので、命名で答えを出しておきます。

新しいメンバーが参加した際は、sync-ai-rules.sh を実行するだけで全ツールの設定が揃います。生成物もリポジトリにコミットしておくと、スクリプトを走らせ忘れた人の環境だけがずれる事故を防げます。

チーム向けツール使用ポリシーのサンプル

チームに導入する際は、簡単なポリシードキュメントを作ると混乱が減ります。

Claude Code: アーキテクチャ判断・CI/CD・コードレビューに使用。セッション終了時に CLAUDE.md を更新
Cursor: 日常のコーディング・デバッグ・小規模修正に使用
Devin Desktop: 新機能の実装（5ファイル以上にまたがる場合）に使用
共通ルールの編集: .ai-rules/shared-context.md のみ。生成物への直接編集は禁止
AI 生成コードのレビュー: 人間の確認を経てから PR を作成
秘密情報: API キー・パスワードの受け渡しは禁止

PR レビューワークフローの統一

チーム全員が異なるツールを使っていても、PR レビューは Claude Code に統一することを推奨します。CLAUDE.md の設計方針に沿ったレビューができるため、「ツールを使って書いたコードだからレビュー基準が違う」という問題が起きません。

# PR レビュー用エイリアス（.bashrc / .zshrc に追加）
alias ai-review='claude "このブランチの変更点をレビューして。
セキュリティ・パフォーマンス・型安全性・
CLAUDE.md のルール準拠の4点で評価して"'

8. まとめ

今日ひとつだけ手を動かすとすれば、リポジトリのルートで置き場所の棚卸しをすることをおすすめします。

# どの形式が残っているかを確認する
ls -d .cursorrules .cursor/rules .windsurfrules .windsurf/rules .devin/rules AGENTS.md 2>/dev/null

旧形式と現行形式が両方出てきたら、優先されるのは現行形式の方です。中身が食い違っていないかをまず見てください。私が半日を溶かしたのは、ここを見ていなかったからでした。

片方しか無ければ、CLAUDE.md を整えるところから始めます。共通ルールの原本が 1 箇所に定まると、各ツールへの展開は本文のスクリプトに任せられます。

3ツールを使い分ける設計そのものより、その 3 つが同じものを読んでいると確認できる仕組みの方が、結果的に時間を返してくれました。ツールの名前も置き場所もこれからも動きます。動いたときに気づける形にしておく — 実際に半年運用してみて、それが一番効いた工夫でした。

3ツールを跨ぐ設定同期の考え方は、Claude Code 公式ドキュメントの CLAUDE.md の解説を土台にすると理解が早まります。ルールをどの粒度で切り出すかで迷ったら、Claude Code Skills の選定軸で使っている判断基準がそのまま応用できます。

この記事に載せたスクリプトは、いずれも隔離した作業ディレクトリで 5 回連続実行し、行数と差分を確認したうえで掲載しています。手元のプロジェクトに入れる前に、まずは空のディレクトリで 2 回走らせてみてください。ツール側の改名や形式変更は今後も起きます。そのたびに慌てずに済む形にしておければ、と思っています。

お読みいただきありがとうございました。

お読みいただきありがとうございます

Claude Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

✦コピー&ペーストで使える実装コード付き
✦毎日新しい上級ガイドを追加
✦¥580/月または ¥1,480 の永久アクセス

メンバーシップを見る →