# 企画変更をMCPで開発につなぐ

> 企画が変わっても開発は古い文書を見ている。Specifyの同じ文書に企画を整理し、Claude Code・CodexからMCPで再読します。変更条件を実装計画とテストに合わせます。

会議後に企画が変わっても開発者が古い文書で実装している場合、Specifyの同じ企画文書をMCPで読み、現在の要求を合わせます。

## こんな問題があるとき

企画は会議やメッセージで変わる一方、開発者は以前の複製やエージェントの会話を基準に作業します。キャンセル条件1つでも、画面・API・テストへの反映をチームで確認する必要があります。

## Specifyで解決する

1. 企画担当者がSpecifyエディターで現行条件、変更理由、受け入れ条件を同じ文書に整理します。
2. 開発者がClaude Code・CodexにMCPで原文を読ませ、コードとの差と実装計画を確認します。
3. 企画変更後は同じ本文を再読して影響範囲を合わせ、開発レビュー文書で実装結果と残る質問を共有します。

## 得られる成果

企画と実装の差、変更された受け入れ条件別の作業・テスト、残る質問を共通のチーム文脈で整理します。企画担当者はSpecify、開発者はコードエディターで協業を続けます。

## 企画と開発が同じ文書を見る流れ

予約サービスを開発するチームを例にします。企画担当者は「予約キャンセル」文書に画面フロー、キャンセル条件、例外、受け入れ条件を書きます。開発者はコーディングエージェントに文書を読ませ、現行コードと照合します。企画が変わったら、同じ文書を読み直して実装計画に反映します。

| 役割 | 作業する場所 | 残す成果 |
| --- | --- | --- |
| **企画担当者・PM** | Specifyエディター | 現行の企画、確定事項、未決の質問、受け入れ条件 |
| **開発者** | Claude Code・Codexとコードエディター | 企画とコードの差、実装計画、コードとテスト |
| **チーム** | Specifyの同じ文書と別のレビュー文書 | 変更理由、開発の確認事項、実装結果、残る質問 |

## 始める前に

- 企画担当者と開発者が、同じワークスペースの対象文書にアクセスできる必要があります。
- [エディター・エージェント接続](/ja/mcp/connect)に従い、Specify MCPをClaude CodeまたはCodexに接続します。
- 企画の参照は読み取り権限から始めます。実装結果をSpecifyに残すには[書き込み権限](/ja/mcp/access)も必要です。

## 企画から実装へ

1. **企画担当者が文書を整理します。** 目的、画面フロー、確定条件、例外、受け入れ条件を分け、未決の項目は質問として残します。
2. **開発者がMCPで原文を読みます。** `search`または`browse`で文書を探し、`read_document`で本文を読みます。正確な文書名を伝えると探しやすくなります。
3. **エージェントが企画とコードを照合します。** 実装済み、変更が必要、担当者への質問に分け、実装計画を作ります。
4. **企画担当者が合意した変更を同じ文書に反映します。** 変更条件と理由を書き、現行条件と以前の条件を区別します。
5. **開発者が変更された文書を読み直します。** 以前の内容と比較し、コードとテストへの影響を確認して実装を続けます。
6. **開発の確認事項を文書に戻します。** 書き込み権限があれば、`create_document`で別のレビュー文書を作るか、合意したセクションを`update_document`で更新します。企画担当者が残る決定を整理します。

## 変更された企画を読み直す例

以下は予約サービスの企画例です。

| 項目 | 最初の企画 | 合意後の企画 |
| --- | --- | --- |
| **キャンセル期限** | 予約の24時間前まで | 予約の12時間前まで |
| **キャンセル不可の画面** | ボタンを非表示 | 無効なボタンと理由を表示 |
| **受け入れ条件** | キャンセル可否を検査 | 時間の境界と無効状態の説明も検査 |

変更後は、以前コピーした条件で作業を続けるのではなく、同じ文書を再度読ませます。エージェントはAPI条件だけでなく、画面状態とテストの修正対象も併せて整理できます。

<Note>
  Specifyエディターはリアルタイムの共同編集に対応しています。コーディングエージェントはMCPを呼び出し、サーバーに反映された文書を読みます。企画変更が進行中の会話へ自動で配信される方式ではないため、変更後は同じ文書の本文を再読するよう依頼してください。文書IDが分かれば、検索インデックスの反映を待たずに`read_document`で直接読めます。
</Note>

## コピーして使える依頼

**最初の実装計画を作るとき**

> Specify MCPで「予約キャンセル企画」を探し、本文を読んでください。確定要求と未決の質問を分け、現行コードと照合して実装計画と受け入れ条件別のテストを整理してください。文書にないポリシーは推測せず質問として残してください。

**企画変更後**

> 同じ企画文書をMCPで読み直してください。以前の内容と比較し、変わった条件と実装中のコード・テストへの影響を整理してください。実装済み部分で変更が必要な動作も確認してください。

**開発結果を共有するとき**

> Specifyに別の開発レビュー文書を作成してください。参照した企画、反映した要求、確認したテスト、未決の質問を整理してください。確定企画の本文は変更しないでください。

## 協業で確認すること

- **確定事項と提案を分けます。** 開発者の提案は、企画担当者が決定するまで別に残します。
- **文書名とIDを維持します。** 同じ文書を読み直すことで、複製文書を基準に実装することを減らせます。
- **重要な変更の前に再読します。** 実装開始時、企画変更後、最終レビュー前に現在の本文を確認します。
- **文書と実装を併せてレビューします。** 画面、API、例外、テストが同じ受け入れ条件に従うか確認します。

利用可能なツールと入力は[MCPの提供ツール](/ja/mcp/tools)を参照してください。