Zedで作る仕様駆動AI開発環境：spec-workflow-mcp × Codex × OpenCode の役割分担

#AI

投稿日: 2026.05.28

本記事について

本記事は、Zedをメインエディタとして使いながら、spec-workflow-mcp による仕様駆動開発を行うための環境構築メモです。
実際に設定でつまずいた点、Zed Agent / Codex / OpenCode の役割分担、Superpowers導入を見送った判断理由まで含めて整理します。

AIコーディング環境は、ここ数か月で一気に複雑になりました。
エディタ内蔵のAgent、ターミナル型Agent、MCPサーバー、OpenRouterのようなモデルルーター、そして仕様駆動開発のためのワークフロー管理ツールが次々に登場しています。

一方で、実際に使おうとすると次のような問題にぶつかります。

AIにいきなり実装させると、仕様にない機能まで作ってしまう
モデルを増やしすぎると、どの工程で何を使うべきか分からなくなる
CodexやOpenCodeなど複数のAgentを使うと、文脈が分散しやすい
Superpowersのようなスキル管理を入れようとしても、ZedのAgent Panel上では使えない機能がある
従量課金モデルを使う場合、コスト上限を意識した設計が必要になる

そこで今回は、いったん欲張らずに、Zedを中心にした仕様駆動開発環境を構築します。

最終的な構成は以下です。

Zed
├─ Zed Agent
│  └─ 仕様作成・設計・タスク分解・実装計画
│
├─ Codex
│  └─ 承認済みタスクの連続実装
│
├─ OpenCode
│  └─ 実装後レビュー
│
├─ spec-workflow-mcp
│  └─ requirements / design / tasks の正本管理
│
└─ AGENTS.md
   └─ 全Agent共通の作業ルール

今回は、Zed Agent / Codex / OpenCode をそれぞれ別の役割に分け、spec-workflow-mcp を仕様の正本として使います。

1. なぜZed中心の環境にするのか

AIコーディング環境は、ターミナル中心にも、エディタ中心にも構築できます。
今回Zedを中心にした理由は、仕様、実装、レビューを同じプロジェクト画面の中で扱いやすいからです。

Zedは、Agent PanelからZed標準Agentだけでなく、Codexなどの外部Agentも起動できます。さらに、MCPサーバーを context_servers として登録することで、Agentから外部ツールを呼び出せます。

この「エディタ内でAgentを切り替えられる」点が、仕様駆動開発と相性が良いです。

1.1. Zed Agentだけで完結させない理由

当初は、Zed Agentだけでモデルを切り替えながら、仕様作成・実装・レビューをすべて行う構成も検討しました。

Zed Agent
├─ 仕様作成：高品質モデル
├─ 実装：Coder系モデル
└─ レビュー：別モデル

この構成はシンプルです。
ただし、同じAgentが「仕様を書く」「実装する」「レビューする」ことになるため、レビューの独立性が弱くなります。

そこで、最終的には次のように分担しました。

Zed Agent = 仕様・計画
Codex     = 実装
OpenCode  = レビュー

実装したAgentとは別のAgentにレビューさせることで、仕様逸脱や過剰実装、テスト不足に気づきやすくなります。

2. spec-workflow-mcp の役割

今回の中核は spec-workflow-mcp です。

spec-workflow-mcp は、AI支援開発向けに、仕様駆動開発の流れを構造化してくれるMCPサーバーです。
主に以下の流れを管理します。

Steering
  ├─ product.md
  ├─ tech.md
  └─ structure.md

Spec
  ├─ requirements.md
  ├─ design.md
  └─ tasks.md

Implementation
  └─ tasks に基づく実装

特に重要なのは、requirements、design、tasks をAIとの会話だけに閉じ込めず、Markdownファイルとしてプロジェクト内に残せることです。

これにより、Zed Agent、Codex、OpenCodeがそれぞれ別のスレッドで動いても、同じ仕様ファイルを参照できます。

.spec-workflow/
├─ steering/
│  ├─ product.md
│  ├─ tech.md
│  └─ structure.md
└─ specs/
   └─ 任意の機能/
      ├─ requirements.md
      ├─ design.md
      └─ tasks.md

AI Agentを複数使う場合、会話履歴ではなく、ファイル化された仕様を共通の文脈にすることが重要です。

3. 最終的な役割分担

今回の運用では、工程ごとに担当Agentを分けます。

工程	担当	目的
1. steering作成	Zed Agent	プロダクト・技術・構造の前提を決める
2. requirements / design / tasks作成	Zed Agent	仕様、設計、実装タスクを作る
3. 実装計画	Zed Agent	実装範囲と方針を決める
4. 実装	Codex	承認済みタスクを連続実装する
5. レビュー	OpenCode	仕様照合・過剰実装・テスト不足を確認する

3.1. Zed Agent：仕様と計画の担当

Zed Agentには、上流工程を担当させます。

steering作成
requirements作成
design作成
tasks作成
実装計画作成
実装前レビュー

Zed Agentには、原則として大きなコード変更をさせません。
仕様を固めることに集中させます。

3.2. Codex：実装担当

Codexには、承認済みの tasks.md に沿って実装させます。

当初は「1タスクずつ実装」も検討しましたが、実務上は毎回止まるとテンポが悪くなります。
そこで、今回は 関連タスクを最大3〜5個まで連続実装してよい というルールにしました。

ただし、無制限に進めるのではなく、以下の条件で停止させます。

requirements と design に矛盾がある
tasks の完了条件が不明確
既存コードと設計方針が大きく食い違う
テストが連続して失敗し、原因が特定できない
認証、権限、課金、外部APIなど重要な設計判断が必要になる

3.3. OpenCode：レビュー担当

OpenCodeは、実装後のレビュー専任にします。

requirements に合っているか
design から逸脱していないか
tasks の完了条件を満たしているか
仕様にない機能が追加されていないか
過剰実装がないか
テスト不足がないか
セキュリティや保守性の懸念がないか

レビュー担当に置くことで、OpenCodeが実装環境として多少不安定でも、大きなリスクになりにくい構成になります。

4. Superpowers導入を見送った理由

当初は、obra/superpowers を導入し、CodexにTDDや実装計画、完了前検証などのスキルを使わせる構成を考えていました。

しかし、Zed Agent Panel上のCodexは、通常のターミナル版Codex CLIではなく、codex-acp 経由で動作しています。
そのため、通常のCodex CLIで使える /plugins が使えませんでした。

実際にZed内Codexで /plugins を実行すると、次のように表示されます。

/plugins is not a recognized command in codex-acp.
Available commands for codex-acp:
/review
/review-branch
/review-commit
/init
/compact
/logout

つまり、Zed Agent Panel内のCodexには、通常の方法でSuperpowersを導入できません。

ここで無理にターミナル版Codex CLIを別途導入して運用を分けると、環境が複雑になります。
今回の目的は「Zed中心の仕様駆動開発を実証すること」なので、Superpowersは見送り、代わりに AGENTS.md に作業規律を書くことにしました。

Superpowers plugin
  → 今回は見送り

AGENTS.md
  → Superpowers的な作業規律を文章で定義

この割り切りにより、構成がかなりシンプルになります。

5. 構築する環境

今回の環境は以下です。

項目	内容
エディタ	Zed
仕様管理	spec-workflow-mcp
仕様・計画担当	Zed Agent
実装担当	Codex
レビュー担当	OpenCode
モデル供給	OpenRouterなど
共通ルール	AGENTS.md
対象プロジェクト	`/Users/testuser/project/sample`

6. Step 1: Node.js / npx の確認

spec-workflow-mcp は npx で起動します。
まず、Node.js、npm、npx が使えるか確認します。

node -v
npm -v
npx -v

未導入の場合は、HomebrewでNode.jsを入れます。

brew install node

7. Step 2: プロジェクトを作成

今回は以下のプロジェクトを例にします。

mkdir -p /Users/testuser/project/sample
cd /Users/testuser/project/sample

Zedで開きます。

zed /Users/testuser/project/sample

8. Step 3: プロジェクトごとの `.zed/settings.json` を作成

spec-workflow-mcp は、対象プロジェクトのパスを引数として渡します。
そのため、Zedのグローバル設定ではなく、プロジェクトごとの .zed/settings.json に設定する方が安全です。

cd /Users/testuser/project/sample
mkdir -p .zed
touch .zed/settings.json

.zed/settings.json に以下を書きます。

{
  "context_servers": {
    "spec-workflow": {
      "command": "npx",
      "args": [
        "-y",
        "@pimzino/spec-workflow-mcp@latest",
        "/Users/testuser/project/sample"
      ],
      "env": {}
    }
  }
}

JSONの末尾カンマに注意

Zedの settings.json はJSONとして解釈されます。
以下のような末尾カンマがあるとMCPが有効になりません。

"/Users/testuser/project/sample",
"env": {},

最後の要素の後ろにはカンマを付けないようにします。

9. Step 4: `--` は付けない

npx 経由でコマンドを起動する際、一般的には -- を使うケースがあります。
しかし今回、@pimzino/spec-workflow-mcp では -- を付けると次のエラーになりました。

npx -y @pimzino/spec-workflow-mcp@latest -- /Users/testuser/project/sample --dashboard

エラー:

Error: Unknown option: --
Use --help to see available options.

そのため、以下のように -- なしで実行します。

npx -y @pimzino/spec-workflow-mcp@latest /Users/testuser/project/sample --dashboard

Zed側の設定でも、-- は不要です。

10. Step 5: ダッシュボードを起動

spec-workflow-mcp にはダッシュボードがあります。
承認や進捗確認に便利なので、別ターミナルで起動します。

npx -y @pimzino/spec-workflow-mcp@latest /Users/testuser/project/sample --dashboard

標準ではポート5000を使います。
ただし、環境によっては5000番ポートが使用中の場合があります。

その場合は、ポートを指定します。

npx -y @pimzino/spec-workflow-mcp@latest /Users/testuser/project/sample --dashboard --port 5050

ブラウザで開きます。

http://localhost:5050

MCPサーバーとダッシュボードは別に考える

Zed Agentから使うMCPサーバーは、Zedが context_servers 経由で起動します。
一方、ダッシュボードは手動で起動するWeb UIです。
そのため、Zed側のMCP設定に --dashboard や --port を入れる必要はありません。

11. Step 6: Zed側でMCPの有効化を確認

Zedを再起動し、対象プロジェクトを開き直します。

その後、Agent Panelで確認します。

Agent Panel
→ Settings
→ MCP / Context Servers
→ spec-workflow

spec-workflow が有効になっていれば成功です。

もし有効にならない場合は、npx のパスを確認します。

which npx

Apple Silicon Macでは、多くの場合以下です。

/opt/homebrew/bin/npx

その場合、.zed/settings.json の command を絶対パスにします。

{
  "context_servers": {
    "spec-workflow": {
      "command": "/opt/homebrew/bin/npx",
      "args": [
        "-y",
        "@pimzino/spec-workflow-mcp@latest",
        "/Users/testuser/project/sample"
      ],
      "env": {}
    }
  }
}

12. Step 7: AGENTS.md を作成

次に、全Agent共通のルールとして AGENTS.md を作成します。

cd /Users/testuser/project/sample
touch AGENTS.md

内容は以下です。

# AGENTS.md

このプロジェクトでは、Zed Agent Panel、Codex、OpenCode、spec-workflow-mcp を使って仕様駆動開発を行う。

## 基本方針

- 実装前に必ず spec-workflow の requirements / design / tasks を確認する
- requirements → design → tasks → implementation → review の順で進める
- 未承認の requirements / design / tasks がある場合は実装しない
- 仕様にない機能を勝手に追加しない
- 関係ないリファクタリングを混ぜない
- 変更後はテスト、差分、残課題を報告する
- 仕様が曖昧な場合は、推測で進めず requirements または design に戻る

## 役割分担

### Zed Agent

Zed Agent は、仕様駆動開発の上流工程を担当する。

担当範囲:

- steering の作成
- product.md の作成
- tech.md の作成
- structure.md の作成
- requirements の作成
- design の作成
- tasks の作成
- 実装計画の作成
- 実装前レビュー

Zed Agent は、原則として大きなコード変更を行わない。  
実装は Codex に渡し、レビューは OpenCode に渡す。

### Codex

Codex は、実装担当とする。

担当範囲:

- 承認済み tasks に沿った実装
- 必要なテストの追加
- テスト実行
- 実装結果の報告
- 軽微なバグ修正

Codex は、requirements / design / tasks を確認してから実装する。  
仕様にない機能は追加しない。

### OpenCode

OpenCode は、レビュー担当とする。

担当範囲:

- 実装後レビュー
- requirements / design / tasks との照合
- 過剰実装の確認
- テスト不足の確認
- セキュリティ・保守性の懸念確認
- 残課題の整理

OpenCode は、原則としてレビュー専任とし、明示されない限りファイルを変更しない。

## 実装単位

原則として、spec-workflow の tasks に従って実装する。

小規模または相互依存するタスクは、複数まとめて連続実装してよい。  
ただし、以下の条件を守ること。

- 実装前に、今回実装するタスク範囲を明示する
- requirements / design / tasks に含まれない機能は追加しない
- 各タスク完了ごとに、内部的に差分と動作を確認する
- テスト可能な単位ごとにテストを実行する
- 大きな設計変更が必要になった場合は実装を止め、design に戻る
- 仕様が曖昧な場合は推測で進めず、確認事項として報告する
- 最後に、実装したタスク、変更ファイル、テスト結果、残課題をまとめて報告する

## Codex の連続実装ルール

Codex は実装担当として、承認済みの tasks を上から順に連続実装してよい。

ただし、以下の場合は停止する。

- requirements と design に矛盾がある
- tasks の完了条件が不明確
- 既存コードと設計方針が大きく食い違う
- テストが連続して失敗し、原因が特定できない
- 実装範囲が当初計画より大きく広がる
- 認証、権限、課金、外部APIなど重要な設計判断が必要になる
- セキュリティ上の判断が必要になる
- データ削除、データ移行、本番環境への影響がある変更が必要になる

停止した場合は、勝手に判断せず、問題点と選択肢を報告する。

## 実装後の報告

実装後は、以下を必ず報告する。

1. 実装内容
2. 実装した tasks
3. 変更ファイル
4. 実行したテスト
5. テスト結果
6. requirements / design / tasks との整合性
7. 仕様との差分
8. 残課題
9. 次に行うべき作業

## レビュールール

OpenCode はレビュー時に、以下を確認する。

- requirements に合っているか
- design から逸脱していないか
- tasks の完了条件を満たしているか
- 仕様にない機能が追加されていないか
- 過剰実装がないか
- テスト不足がないか
- エラーハンドリングが不足していないか
- セキュリティ上の懸念がないか
- 保守性を下げる実装になっていないか
- 不要な依存関係が追加されていないか

レビュー結果は、最後に以下のいずれかで示す。

- 承認
- 要修正
- 仕様確認が必要

13. Step 8: steering を作成する

空の新規プロジェクトでも、steeringは作成した方が良いです。

既存コードがない場合、AIが勝手に構成を決めやすいため、最初にプロダクト・技術・構造の前提を固定します。

Zed Agentに以下を依頼します。

AGENTS.md に従ってください。
このプロジェクトは新規作成の空プロジェクトです。

spec-workflow を使って、このプロジェクトの steering を作成してください。
product.md、tech.md、structure.md を順に作成してください。

既存コードはまだないため、以下の前提をもとにしてください。
- 作成するアプリ：
- 主な利用者：
- 主な機能：
- 使用したい技術：
- 避けたい技術：
- デプロイ先：
- その他の制約：

各ファイルは承認待ちにしてください。
まだ実装はしないでください。

ポイントは、空プロジェクトであることを明示することです。
既存コードがないのに「既存構成を確認して」と指示すると、Agentが不要な推測をしやすくなります。

14. Step 9: requirements / design / tasks を作る

steeringができたら、新機能のspecを作ります。

AGENTS.md に従ってください。
spec-workflow を使って、「日報入力フォーム」機能の requirements / design / tasks を作成してください。

各工程で承認待ちにしてください。
まだ実装はしないでください。

仕様駆動開発では、ここでいきなり実装に入らないことが重要です。
requirementsで「何を満たすべきか」を決め、designで「どう作るか」を決め、tasksで「どの順番で作るか」を決めます。

15. Step 10: 実装計画を作る

実装前に、Zed Agentに計画を作らせます。

AGENTS.md に従ってください。
spec-workflow の tasks から未完了タスクを確認し、実装計画を作成してください。

今回実装するタスク範囲、変更予定ファイル、実装方針、テスト方針を示してください。
まだファイルは変更しないでください。

ここで重要なのは、まだファイルを変更しないことです。
計画と実装を分けることで、AIが勝手に作り始めることを防ぎます。

16. Step 11: Codexで連続実装する

実装はCodexに渡します。

Zed Agent Panelから New Codex Thread を開き、以下を入力します。

AGENTS.md に従ってください。
spec-workflow の requirements / design / tasks を確認してください。

承認済みの tasks のうち、未完了タスクを上から順に連続実装してください。
今回は、関連するタスクを最大3つまでまとめて実装して構いません。

ただし、以下を守ってください。

- 実装前に、今回実装するタスク範囲を明示する
- requirements / design にない機能は追加しない
- 各タスク完了ごとに内部確認を行う
- テスト可能な単位でテストを実行する
- 途中で仕様不明点や設計変更が必要になった場合は停止する
- 最後に、実装タスク、変更ファイル、テスト結果、残課題をまとめて報告する

16.1. 連続実装の考え方

「1タスクずつ」だと安全ですが、実務ではテンポが悪くなります。
一方で「全部実装して」と依頼すると、仕様逸脱のリスクが上がります。

そこで、中間案として、以下のどちらかで区切るのがおすすめです。

最大3〜5タスクまで

または、

機能まとまり単位

たとえば、日報アプリなら次のように分けます。

まとまり	例
初期セットアップ	プロジェクト作成、Lint、型設定
データ層	DBスキーマ、バリデーション
API層	CRUD API、エラーハンドリング
UI層	入力フォーム、一覧画面
テスト層	ユニットテスト、E2Eテスト
仕上げ	README、軽微なUI調整

17. Step 12: OpenCodeでレビューする

実装後はOpenCodeにレビューさせます。

Zed Agent PanelでOpenCodeスレッドを開き、以下を入力します。

AGENTS.md に従ってください。
あなたはレビュー専任です。ファイルは変更しないでください。

Codex が実装した今回の差分を、spec-workflow の requirements / design / tasks と照合してレビューしてください。

確認項目:
1. 実装済みタスクはどれか
2. 各タスクの完了条件を満たしているか
3. requirements / design から逸脱していないか
4. 仕様にない機能が追加されていないか
5. タスク間の整合性に問題がないか
6. テスト不足がないか
7. セキュリティ・保守性の懸念がないか

最後に、承認可否を「承認 / 要修正 / 仕様確認が必要」で示してください。

レビュー専任にしているため、OpenCodeには原則としてファイルを変更させません。
これにより、実装担当とレビュー担当を明確に分けられます。

18. モデル選択の考え方

今回の構成では、工程ごとにモデルを分けることもできます。

工程	モデル方針
steering / requirements	高品質モデル
design	高品質または中品質モデル
tasks	中品質モデル
実装	Coder系モデル
テスト	Coder系の安価モデル
ドキュメント	日本語説明に強い軽量モデル
レビュー	実装と別系統のモデル

18.1. テスト・ドキュメント用モデル

テストやドキュメントには、必ずしも最上位モデルは不要です。

実装・テストには、Coder系モデルが向いています。
READMEや日本語の利用手順には、文章生成が自然な軽量モデルが向いています。

実装・テスト:
  Qwen Coder系
  DeepSeek Coder系

ドキュメント:
  Gemini Flash Lite系
  Qwen Plus系

OpenRouterを使う場合は、APIキーごとに上限を設定しておくと安心です。

zed-agent-key      : 仕様・計画用
codex-impl-key     : 実装用
opencode-review-key: レビュー用
experiment-key     : 実験用

従量課金の暴走を防ぐ

Agentは、計画・実装・検証を何度も繰り返すため、通常のチャットよりAPI利用量が増えやすいです。
OpenRouterなどを使う場合は、APIキー単位で上限を設定してから使うことをおすすめします。

19. トラブルシューティング

19.1. MCPが有効にならない

まず .zed/settings.json のJSON構文を確認します。

NG例:

{
  "context_servers": {
    "spec-workflow": {
      "command": "npx",
      "args": [
        "-y",
        "@pimzino/spec-workflow-mcp@latest",
        "/Users/testuser/project/sample",
      ],
      "env": {},
    },
  },
}

OK例:

{
  "context_servers": {
    "spec-workflow": {
      "command": "npx",
      "args": [
        "-y",
        "@pimzino/spec-workflow-mcp@latest",
        "/Users/testuser/project/sample"
      ],
      "env": {}
    }
  }
}

19.2. 5000番ポートが使用中

--port を指定します。

npx -y @pimzino/spec-workflow-mcp@latest /Users/testuser/project/sample --dashboard --port 5050

19.3. Zedから `npx` が見えない

which npx で絶対パスを確認します。

which npx

例:

/opt/homebrew/bin/npx

.zed/settings.json を修正します。

{
  "context_servers": {
    "spec-workflow": {
      "command": "/opt/homebrew/bin/npx",
      "args": [
        "-y",
        "@pimzino/spec-workflow-mcp@latest",
        "/Users/testuser/project/sample"
      ],
      "env": {}
    }
  }
}

19.4. Zed内Codexで `/plugins` が使えない

Zed内Codexは codex-acp 経由で動作しているため、通常のCodex CLIの /plugins は使えません。

Available commands for codex-acp:
/review
/review-branch
/review-commit
/init
/compact
/logout

この場合は、Superpowers導入を見送り、AGENTS.md に作業規律を書く運用にします。

20. 実証シナリオ

最初に試す機能としては、シンプルなCRUDが向いています。

例として、製造業向けの日報入力アプリを考えます。

項目	内容
作成するアプリ	製造業向け日報入力Webアプリ
主な利用者	現場作業者、事務担当者、管理者
主な機能	日報入力、良品数・不良数記録、不良率計算、日別一覧
使用技術	Next.js、TypeScript、SQLiteまたはSupabase
制約	スマホ・タブレットで入力しやすいUI

この程度の規模なら、steering → requirements → design → tasks → implementation → review の流れを確認しやすいです。

21. セキュリティ・運用上の注意

AI Agentにコードを書かせる場合、最低限次のルールは必要です。

対策	内容
仕様の正本を持つ	`.spec-workflow/` を共通文脈にする
変更範囲を限定する	実装前にタスク範囲を明示する
破壊的変更を止める	データ削除・移行・本番影響は確認必須
秘密情報を保存しない	APIキーやトークンをコードに含めない
レビューを分ける	実装AgentとレビューAgentを分ける
コスト上限を設ける	OpenRouter等でAPIキー別に上限を設定する

AIに「全部やって」と頼むほど、思わぬ変更が増えます。
仕様駆動開発の価値は、AIの能力を制限することではなく、AIの作業範囲を明確にすることにあります。

22. 今後の課題：工程ごとのモデル自動選択

現時点では、工程ごとにモデルを完全自動で切り替えるより、担当Agentを分ける方が現実的です。

Zed Agent = 仕様・計画
Codex     = 実装
OpenCode  = レビュー

OpenRouterのAuto Routerのような仕組みを使えば、ある程度の自動選択は可能です。
ただし、仕様駆動開発では「この工程では必ずこの品質のモデルを使う」という制御も重要になります。

そのため、まずは手動またはAgent単位でモデルを固定し、実証後に自動ルーティングを検討する方が安全です。

23. おわりに

この記事では、Zedを中心に、spec-workflow-mcp、Codex、OpenCodeを組み合わせた仕様駆動AI開発環境を構築しました。

今回のポイントは、ツールを増やしすぎないことです。

採用:
  Zed Agent
  Codex
  OpenCode
  spec-workflow-mcp
  AGENTS.md

見送り:
  Superpowers plugin
  ターミナル版Codex CLI前提の複雑な構成

Superpowersを導入できれば理想的ではありますが、Zed Agent Panel内のCodexでは /plugins が使えないため、今回は AGENTS.md で作業規律を定義する方針にしました。

結果として、かなりシンプルな構成になりました。

Zed Agentで仕様を作る
Codexで実装する
OpenCodeでレビューする
spec-workflow-mcpで仕様を残す
AGENTS.mdで作業ルールを固定する

AIコーディングでは、優秀なモデルを選ぶことも重要ですが、それ以上に重要なのは、AIが何を基準に判断するかです。

仕様をMarkdownとして残し、Agentごとに役割を分け、実装とレビューを分離する。
この構成は、今後のAI活用型開発において、かなり実用的な土台になると感じています。

24. FAQ

空の新規プロジェクトでも steering は必要ですか？: はい、必要です。空プロジェクトでは既存コードや構成がないため、AIが勝手に技術選定やディレクトリ構成を決めやすくなります。最初に product.md、tech.md、structure.md を作って前提を固定する方が安全です。
spec-workflow-mcp はグローバルに導入できますか？: パッケージ自体は npx やグローバルインストールで共通利用できます。ただし、対象プロジェクトのパスを指定する必要があるため、Zedの設定はプロジェクトごとの .zed/settings.json に書くのがおすすめです。
ダッシュボードのポート5000が使えない場合はどうすればよいですか？: --port 5050 のようにポートを指定して起動します。例: npx -y @pimzino/spec-workflow-mcp@latest /Users/testuser/project/sample --dashboard --port 5050
Zed内Codexに Superpowers を導入できますか？: 通常の方法では難しいです。Zed内Codexは codex-acp 経由で動作しており、通常のCodex CLIで使える /plugins が利用できません。今回はSuperpowersを見送り、AGENTS.md に作業規律を書く方法を採用しました。
タスクは1つずつ実装した方が安全ですか？: 最も安全なのは1タスクずつですが、実務ではテンポが悪くなります。今回は、関連タスクを最大3〜5個まで連続実装してよいが、仕様不明点や設計変更が必要になったら停止する、という運用にしました。
レビューはZed Agentで行ってもよいですか？: 可能です。ただし、実装したAgentとは別のAgentにレビューさせた方が、見落としを減らしやすいです。今回はCodexが実装し、OpenCodeがレビューする構成にしています。
OpenRouterは必須ですか？: 必須ではありません。ただし、複数モデルを使い分けたい場合や、APIキーごとに利用上限を設定したい場合には便利です。従量課金の暴走を防ぐため、上限設定は必ず行うことをおすすめします。
最初に試す機能は何がよいですか？: 入力フォーム、一覧表示、簡単なCRUDなど、仕様・設計・実装・レビューの流れを一通り試せる小さな機能が向いています。製造業向けの日報入力アプリは実証例として扱いやすいです。