開発をしていると「あのプロジェクトで実装したコードを、別のプロジェクトでも実装しないといけなくなった」という場面に遭遇することがあります。しかもベースとなるフレームワークが異なる場合も多く、DIや環境変数・外部サービスとの連携方法などが違うため、単純なコピペではうまくいきません。
今回は、Cursorの機能を活用して複数プロジェクトを同時に開き、AIに既存コードを参考にしながら新しい実装を作らせる方法をご紹介します。
複数プロジェクトの同時起動
Cursorでは、コマンドラインから複数のプロジェクトを同時に開くことができます。
cursor ./project-api ./project-web
このようにCursorコマンドを実行することで、複数のプロジェクトをまとめて開くことができます。親ディレクトリで開くことでも理論上可能ですが、その場合無関係なプロジェクトまで開いてしまうことや、プロジェクトディレクトリを移動させる必要があるなどの手間があります。
AIエージェントによる横断的なファイル参照
1つのCursor IDEウィンドウでまとめて開くことにより、CursorのAIエージェントがプロジェクトを横断したファイル参照をできるようになります。これにより、以下のような指示が可能になります。
Project-Aのsrc/lib/external-api.client.tsを参考に、Project-BのNestJSにmoduleを作成して
実装前の調査と計画立案が重要
ただし、いきなり実装を依頼するのではなく、まず調査と計画を立てさせることが重要です。今回試した例では、以下のような指示を出しました。
project-aのこの処理で取得した生成テキストを、外部APIのチャットにコメントで投稿したい。
このLambdaはSQSからトリガーされて実行する。呼び出し元は@webhook-handler.ts からチェックできます。
また、外部APIの周りについては、project-bの@api-handler.ts を中心に実装されたコードを調査することで理解することができるでしょう。まずは実装を詳細に調査して、実装計画を立ててください。
この指示により、AIは以下のような流れで作業を進めました。
会話テキスト投稿の実装場所と既存の外部API送信ロジックを把握するため、関連ファイルとシンボル（APIクライアントクラス、sendMessage）を一括で確認します。続けてSQSプロセッサの全体も読み込みます。
[3 tools called]
今から関連実装を詳しく把握するために、`project-b` の `api-client.ts` を開いて送信処理の詳細（エンドポイント、認証方法、ペイロード形式）を確認し、同時に SQS ペイロードに含まれるフィールドも確認します。
[1 tool called]
今取り掛かること: 外部APIトークン取得ユーティリティと関連インターフェースを読み、キュー処理で必要な情報（APIキー/シークレット、型）を把握します。
[3 tools called]
やったこと: 関連ファイルを読み込み、既存の外部API投稿処理の仕様とSQSフローを把握しました。これを踏まえて、SQSトリガーLambdaで生成テキストを外部APIへコメント投稿する実装計画をまとめます。
### 把握した現状
- `webhook-handler.ts`
- 署名検証→対象イベントだけ抽出（特定のメッセージタイプ）→外部APIから該当スレッドのメッセージ取得→対象チャネルのみ処理→SQSへ投入。
- SQSメッセージには `conversationId`（= threadId）, `prompt`, `messageId`, `timestamp` が含まれる。
- `queue-processor.ts`
- SQSメッセージを受け取り、`prompt` を使って AI エージェントを呼び出し、レスポンス文字列をログ出力して終了（投稿処理は未実装）。
- `project-b/src/functions/api/client.ts`
- 外部API投稿実装の既存例があり、`/conversations/v3/conversations/threads/{threadId}/messages` に `type: 'COMMENT'`, `text`, `richText` をPOST（`Authorization: Bearer <token>`）。
- トークンは `process.env.API_TOKEN` を使う設計。
- `project-a/lambda/libs/api/token-util.ts`
- SSMから外部APIトークンを取得する `getApiKey()` があり、Webhookでも `Authorization: Bearer ${apiKey}` で利用中。
### 実装計画
- 目的: SQSトリガーの `queue-processor.ts` でAI生成テキストを、外部APIスレッドへ「コメント（COMMENT）」として投稿する。
- 仕様/入出力
- 入力: SQSレコード `record.body` に以下が含まれる想定
- `conversationId`（必須）: 外部API threadId
- `prompt`（任意/既存）: AI入力
- `messageId`（任意/メタ）
- 出力: 外部API Conversations API へのPOST（COMMENT作成）。成功/失敗をCloudWatchログに出力。
- 変更点（実装箇所）
- `lambda/queue-processor.ts`
- `getApiKey` をインポート。
- ユーティリティ関数 `postComment(conversationId: string, text: string): Promise<void>` を実装。
- 外部API Private App Token を `getApiKey()` で取得。
- POST先: `https://api.example.com/conversations/v3/conversations/threads/${conversationId}/messages`
- ペイロード:
- `type: 'COMMENT'`
- `text: <AI出力を整形した本文（先頭にBot識別子などヘッダを付与可）>`
- `richText: <必要に応じてtext→簡易HTML化（改行→<br>程度）>`
- ヘッダ: `Content-Type: application/json`, `Authorization: Bearer <token>`
- 失敗時はレスポンス本文をログ化して継続（リトライはSQSの再実行/DLQ任せ）。
- メイン処理フロー:
1) `record.body` をJSONパースし `conversationId`, `prompt` を取り出す（無い場合はスキップ/警告）。
2) AI エージェントへ `prompt` を送信し、レスポンス文字列を取得。
3) 取得した文字列を上記 `postComment` に渡してコメント投稿。
4) ログに結果を出力。
- 簡易テスト方針
- SQSへ手動で `{ "conversationId": "...", "prompt": "..." }` を投入してE2E確認。
- 外部APIスレッドに `type: COMMENT` が追加されることを目視確認。
この方針で実装に進めます。実装に取り掛かってよければ続けて編集を行います。
このように、AIは段階的に調査を進め、現状把握から詳細な実装計画まで含む包括的な報告書を作成してくれました。個別にプロジェクトごとに調査指示を出すことでも、似たような計画を作ることは可能だと思います。ただ、ワークスペース機能を利用することで、「あっちでやったのをこっちでもやりたい」という意図や目的まで伝えて作業させることができますし、複数ファイルに散らばっている場合の探索なども簡単になります。
実装作業だけなら Auto でも良さそう
これは統計データがあるわけではないのですが、調査フェーズについてはGPT-5 や Sonnet-4 などのモデルを個別に指定するようにしています。これらは Cursor の利用量を Auto よりも早く消費します。が、やり直しや手戻りリスクを考えると、調査と計画はしっかりさせた方が安全かなと感じています。
実際今回試したケースでも、 GPT-5 に調査をさせた後は Auto モードで作業をさせていました。HubSpotの、それもSDKが対応していない Preview 状態の API を利用する要件でしたが、それでも違和感のないコードが生成されていました。
この辺りのモデル使い分けによってCursorの利用コストと開発時の迷走リスクの削減を実現できるのではないかと考えています。
まとめ
複数プロジェクトを同時に開くことで、CursorのAIエージェントは既存コードを参考にしながら新しい実装を行えるようになります。特に重要なのは、実装前に必ず調査と計画立案をさせること。これにより、的確で効率的な実装を実現できるでしょう。
また、調査フェーズとの実装フェーズでモデルを使い分けることで、コストと品質のバランスを取ることも可能です。ぜひ試してみてください。
Discussion