まだ、チャット欄からコードをコピー＆ペーストしていますか？
「AIにコードを書いてもらったけれど、結局ファイルをまたいでコピペするのが面倒」
「修正をお願いしたら、別のファイルとの整合性が取れなくなった」
もしそう感じているなら、Cursorの本当の力の半分も使えていないかもしれません。
AIと対話する際、最も重要なのは「文脈（コンテキスト）の共有」です。対話型AIの設計やLLM（大規模言語モデル）を活用したシステム開発の現場においても、文脈が共有されていない状態で指示を出しても、期待通りの成果物は得られません。
多くのエンジニアがCursorのチャット機能（Cmd+L）を使用していますが、それはあくまで「相談相手」としての役割にとどまります。対して、今回紹介するComposer機能（Cmd+I）は、エディタを操作し、複数のファイルを同時に書き換える「腕利きの実装パートナー」として機能します。
本記事では、単にコードを生成させるだけでなく、仕様書レベルの指示から、ディレクトリ構成の決定、複数ファイルの同時生成、そして品質チェックまでを、一貫した対話フローで行うための技術を解説します。
チャット欄とエディタを行き来する手間を省き、AIを「コーダー」から「アーキテクト」へと昇格させることで、新規機能開発のスピードを向上させることが可能です。
この学習パスについて：AIを「コーダー」から「アーキテクト」へ昇格させる
よくある誤解として、「Composerは、チャット機能がフローティングウィンドウになっただけのもの」という認識があります。しかし実際には、AIを単なるコードの記述者から、システム全体を見渡す設計者へと引き上げるための強力な機能です。
なぜChatではなくComposerなのか
従来のチャット機能（Side Chat）は、質問に対して答えを返すことが主目的です。コードブロックが生成されても、それを適用するにはユーザーが「Apply」ボタンを押すか、手動でコピーする必要がありました。これは単一ファイルの修正には便利ですが、新規機能開発のように5つも10個もファイルを作成する場合、作業コストが膨大になります。
一方、Composer（特にAgentモードやFull Projectモード）は、プロジェクトのファイルシステム全体を操作対象とします。ユーザーの許可さえあれば、ファイルの新規作成、既存ファイルの修正、不要なファイルの削除を、システム全体の整合性を保ちながら同時に実行できるのです。
本パスのゴール：仕様書1枚から動くプロトタイプを作成
本記事を通じて、以下のスキルを習得し、実践できるようになります。
- 構造設計: 曖昧な要件から、最適なディレクトリ構成とファイル割り振りをAIに提案させる。
- 一括実装: 依存関係（import/export）を解決した状態で、複数のコンポーネントやロジックを一気に生成する。
- 自律修正: エラーが出た際、AI自身に原因を特定させ、修正コードを適用させる。
所要時間と推奨環境
- 所要時間: 約30分（記事を読みながら実際に手を動かす時間）
- 推奨環境: Cursor（最新版）、Claude（推奨）
- AIモデルは進化が早く、旧モデル（Sonnet 4.5以前など）は順次提供が終了する可能性があります。Cursorの設定画面（Models設定）にて、コーディングや自律的な操作能力が大幅に向上した最新モデル（Claude Sonnet 4.6など）が選択されていることを必ず確認してください。
- 最新のClaudeでは、タスクの複雑さに応じて推論の深さを自動調整する「Adaptive Thinking（適応的思考）」や、長い会話履歴を自動で圧縮する「Compaction機能」が搭載されています。これにより、Composerを用いた複数ファイルにまたがる複雑な実装や、100万トークン規模の膨大なコンテキストを必要とする開発においても、精度の高いコード生成が可能になります。
- 想定技術スタック: 本記事では例として「React + TypeScript + Tailwind CSS」を用いますが、PythonやGoなど他の言語でも応用可能です。
前提知識と準備：AIに「文脈」を正しく渡す技術
プロンプトを入力する前に、最も重要な準備があります。それは「AIにプロジェクトの全体像（コンテキスト）を渡すこと」です。Composerが優秀であっても、プロジェクトの構造が把握できていなければ、不適切な場所にファイルを作成したり、既存のルールを無視したコードを生成したりする可能性があります。
Composerモードの起動と基本操作
まず、Cmd + I（Windowsなら Ctrl + I）を押してComposerを開きます。デフォルトでは小さなバーが表示されますが、複雑な指示を出す場合は Cmd + Shift + I で全画面のエディタモードに切り替えるのがおすすめです。
ここで重要なのが、画面下部にあるモード設定です。「Normal」ではなく「Agent」モード（または機能が統合された最新のComposerモード）になっていることを確認してください。これにより、AIが自律的にターミナルコマンドを実行したり、ファイルを作成したりする権限を持ちます。
コンテキストの重要性：@Codebaseと@Docsの使い分け
「AIが意図しないライブラリを使用した」「既存の共通コンポーネントを利用しなかった」
一般的な傾向として、こうした失敗の多くはコンテキスト不足が原因です。Cursorには強力なコンテキスト参照機能が備わっていますが、適切に指定しなければ効果を発揮しません。
- @Codebase: プロジェクト全体のインデックスを参照します。ただし、大規模なプロジェクトでは情報が埋もれる可能性があります。
- @Files / @Folders: 特定のディレクトリやファイルを明示的に参照させます。新規機能が既存機能に似ている場合、参考にしてほしいファイルをピンポイントで指定するのがコツです。
- @Docs: 公式ドキュメントを参照します。新しいライブラリを使う場合は必須です。
プロジェクト構造の事前整理
AIに作業させる前に、最低限の「足場」を確認しましょう。例えば、src/components や src/features といったディレクトリ構成が決まっているなら、それを守らせる必要があります。
もしプロジェクトに README.md や CONTRIBUTING.md があるなら、それを @README.md としてプロンプトに含めるだけで、AIの理解度は格段に上がります。ドキュメントがない場合は、これから作る機能の仕様をまとめた簡単なMarkdownファイル（例: specs/new-feature.md）を用意し、それを読み込ませるのがベストプラクティスです。
ステップ1：構造化プロンプトの基礎（ディレクトリとファイルの足場作り）
ここから実践的なアプローチに入ります。いきなり「〇〇機能を作成して」と指示するのは推奨されません。建築において設計図なしで柱を立て始めないのと同じように、まずは構造を定義する必要があります。
コードの中身ではなく、「どのようなファイル構造で機能を実装するか」をAIに提案・確定させます。
いきなりコードを書かせない
複雑な機能を一発で生成しようとすると、AIの出力トークン制限に引っかかったり、論理的な矛盾が生じたりします。まずは「構成定義」のフェーズを挟むことで、手戻りを防ぎます。
ファイル構成案を出力させるプロンプト
以下のプロンプトは、新しい機能を実装する際に、まずファイル構成を提案させるためのテンプレートです。
【コピー用プロンプト雛形：構成提案】
# ゴール
現在開発中のプロジェクト（@Codebase 参照）において、新たに「[機能名: 例 ユーザー管理画面]」を実装したいと考えています。
# 技術スタック
- フレームワーク: React + TypeScript
- スタイリング: Tailwind CSS
- 状態管理: [例: React Context / Redux]
- 通信: [例: Axios / React Query]
# 要件
- [要件1: ユーザーの一覧表示]
- [要件2: 新規登録モーダル]
- [要件3: 削除機能]
# 指示
いきなりコードを生成しないでください。
まずは、この機能を実装するために必要な「ディレクトリ構成」と「ファイル一覧」を提案してください。
各ファイルがどのような「責務」を持つかも1行で記述してください。
既存のプロジェクト構造（src/features など）の規則に従ってください。
出力形式:
- ディレクトリツリー（Markdown形式）
- 各ファイルの解説
このプロンプトを実行すると、Composerはコードを書く前に「計画」を提示してくれます。
🤖 AIの応答例
提案する構成は以下の通りです。src/features/users/ ├── api/ │ └── userApi.ts // API通信ロジック ├── components/ │ ├── UserList.tsx // 一覧表示コンポーネント │ └── UserModal.tsx // 新規登録・編集用モーダル ├── types/ │ └── user.ts // 型定義 └── UserPage.tsx // ページ全体の構成
この段階で「型定義は shared/types に配置したい」と判断した場合は、チャットで修正を指示します。この「合意形成」が、後の手戻りを防ぐ重要なプロセスとなります。
ステップ2：詳細実装の一括生成（依存関係の解決）
構成が確定したら、実装フェーズに進みます。ここで重要なのは「依存関係の順序」です。型定義が存在しない状態でコンポーネントを作成しようとすると、AIが不適切な型を使用したり、存在しない型を生成したりするリスクがあります。
型定義を共通言語にする
複数のファイルを生成する場合、「型（Type/Interface）」を最初に定義させることで、それが各ファイル間の共通言語（契約）となり、整合性が保たれます。
一括生成のためのプロンプト
ステップ1で合意した構成に基づき、以下のプロンプトで一気に生成を指示します。
【コピー用プロンプト雛形：一括実装】
# 指示
先ほど合意したファイル構成に基づき、詳細な実装コードを生成してください。
# 生成ステップ（Step-by-Step）
以下の順序で実装を行い、ファイル間の整合性を保ってください。
1. 型定義: `types/user.ts` を実装。全てのデータの基盤とします。
2. APIロジック: `api/userApi.ts` を実装。型定義を使用し、ダミーデータではなく実際のAPIコール（エンドポイントは `/api/v1/users` と仮定）を書いてください。
3. UIコンポーネント: `components/` 以下のファイルを実装。Tailwind CSSでスタイリングし、レスポンシブ対応してください。
4. ページ統合: `UserPage.tsx` で各コンポーネントを組み立ててください。
# 制約事項
- 全てのファイルを作成・保存してください。
- エラーハンドリング（Try-Catch等）を必ず含めてください。
- コード内にはJSDoc形式でコメントを付記してください。
Composerはこの指示を受けると、指定された順序で次々とファイルを作成していきます。画面上で複数のタブが開き、コードが構築されていくプロセスを確認できます。
ポイント: Step-by-Step で順序を指定することが重要です。これにより、AIは「後で使うファイル」ではなく「基礎となるファイル」から順に処理を行うようになり、論理破綻を防げます。
ステップ3：品質向上と自己修正（レビューとテスト）
コードが生成された後、すぐに適用するのは避けるべきです。AIが生成したコードには、セキュリティ上の懸念やパフォーマンスの問題、あるいは単純なバグが含まれている可能性があります。
ここで、AI自身に「レビュアー」としての役割を与えます。
「シニアエンジニアとしてレビューして」の効果
人間がレビューする前に、AIに自己レビューさせることで品質を一段階上げることができます。
【コピー用プロンプト雛形：自己レビュー＆修正】
# レビュー依頼
生成されたコードを、あなたは「シニアテックリード」として厳しくレビューしてください。
# チェック項目
1. 型安全性: `any` 型が使用されていないか。
2. パフォーマンス: 不要な再レンダリングや、重い処理がないか。
3. セキュリティ: XSS対策や入力値バリデーションは適切か。
4. エラー処理: APIエラー時にUIがクラッシュしないか。
# アクション
問題点が見つかった場合は、指摘するだけでなく、該当ファイルを直接修正してください。
問題がなければ「修正なし」と報告してください。
テストコードの同時生成
さらに、動作を保証するためにテストコードも生成させましょう。実装と同時にテストを書かせることで、テスト駆動開発（TDD）に近いサイクルを高速に回せます。
# 追加指示
`src/features/users/__tests__` ディレクトリを作成し、主要なコンポーネントとロジックの単体テスト（Jest/React Testing Library）を作成してください。
正常系だけでなく、エラー系のテストケースも網羅してください。
ここまで進めば、人間が行う作業は「最終確認」と「微調整」に絞られます。
ステップ4：実務応用（独自のプロンプトテンプレート作成）
毎回長いプロンプトを入力するのは非効率です。実務で継続的に活用するためには、これらのプロセスを「型化」し、効率的な対話フローを構築することが重要です。
.cursorrulesファイルの活用
プロジェクトのルートディレクトリに .cursorrules というファイルを作成すると、Cursor全体に対する「システムプロンプト」を設定できます。ここにチームのコーディング規約や、よく使う指示を書いておくと、毎回入力する手間が省けます。
【.cursorrules の設定例】
# プロジェクト全般のルール
- 言語は日本語で応答すること。
- 新規機能作成時は、必ずディレクトリ構成の提案から始めること。
- コンポーネントは関数コンポーネントで記述し、`React.FC` は使用しないこと。
- スタイリングは Tailwind CSS のユーティリティクラスのみを使用すること。
# Composer使用時の挙動
- 複数ファイル生成時は、必ず型定義ファイルから作成すること。
- 生成後は自動的に自己レビューを行うこと。
これを設定しておけば、以降は「ユーザー管理機能を作成して」と入力するだけで、ステップ1〜3のプロセスをある程度自動的に踏襲してくれるようになります。
よく使う機能のテンプレート化
認証機能、決済機能、CRUD画面など、頻出するパターンについては、独自の「プロンプトスニペット」をMarkdownファイルとして保存しておき、Composerに入力する際に @snippets/crud_prompt.md のように読み込ませるのも有効なテクニックです。
よくある失敗とトラブルシューティング
最後に、Composerを活用する上で発生しやすいトラブルとその対処法を解説します。
Q. 「変更が適用されない」問題
A. Composerのチャット画面でコードが生成された後、ファイルに反映されないことがあります。これは「Apply」ボタン（または Save All）の押し忘れか、AIがファイルパスを見失っている場合に起きます。プロンプトで「必ずファイルを作成・保存してください」と明記するか、生成されたコードブロックの右上にある「Apply」を確実にクリックしてください。
Q. コンテキスト溢れ（Token Limit）への対処
A. 関連ファイルを大量に @Files で読み込ませると、AIの記憶容量（コンテキストウィンドウ）が溢れ、古い指示を忘れたり、挙動が不安定になったりします。本当に必要なファイルだけを厳選するか、大きなファイルはインターフェース部分だけを抜粋した要約ファイルを作って読み込ませる工夫が必要です。
Q. 生成が途中で止まる
A. 一度に生成させる量が多すぎることが原因です。「型定義だけ先に作成して」「次にコンポーネントを作成して」と、指示を分割（Chain of Thought）することで安定した出力を得られます。
まとめ：AIは指示待ちの新人から、頼れるパートナーへ
Cursor Composerを使った開発フローは、これまでの「生成されたコードをコピペする」作業とは次元が異なります。
- 構成定義: まず設計図を作る
- 一括実装: 依存関係順に生成する
- 品質保証: 自己レビューさせる
- 型化: ルールとして定着させる
この4ステップを踏むことで、AIは単なる「コード生成ツール」から、システム全体を理解して構築する「アーキテクト」へと進化します。
最初はプロンプトの設計に時間を要するかもしれません。しかし、一度この対話フローを確立すれば、実装スピードは大幅に向上します。ぜひ、今後の新規機能開発において、このアプローチを試してみてください。
コメント