OpenSpec

料金

Open source

プラットフォーム

Docs, CLI, Git, Agent workflows

公式サイト

https://openspec.dev

私の評価

OpenSpec を Coding Agent Tools に入れる理由は、次のボトルネックが model quality だけではないからです。agent work を durable specs、task plans、reviewable decisions に変換できるかが重要になります。

私の実務評価: OpenSpec は Cursor、Claude Code、Codex、OpenHands、Aider の代替ではありません。それらの tools が improvisation に寄りすぎないための structure です。agents が original goal を忘れる、古い decisions を再度開く、acceptance criteria なしに patches を出すなら、OpenSpec-style SDD が不足しています。

何を解決するか

OpenSpec が強いのは、change の project memory を作ることです。重要な artifacts は proposals、specs、tasks、acceptance criteria、review questions です。AI coding では prompt だけでなく、sessions をまたいで残る source of truth が必要です。

Coding Agent Tools の文脈では、Strategic Advisor original task lists、prototype-to-SDD sequential plans、README/OpenSpec project indexes、AI orchestration safety docs が重要な skills です。これらの artifacts が downstream tools を安定させます。

向いている人

• product intent を spec-driven development に変換したいチーム。
• prototype を maintainable tasks に変えたい人。
• README、decisions、specs、implementation plans を接続したい project。
• 実行前に coding agents へ安定した context を渡したい workflow。
• multi-agent や MCP-heavy workflow の safety boundary を文書化したいチーム。

向いていない人

• 速い inline code edits。
• one-off autocomplete workflows。
• 初回実装後に specs を維持する気がないチーム。

Coding Tools との接続

Claude Code、Codex、Cursor、OpenHands、Gemini CLI、opencode、Aider の前に OpenSpec を使います。OpenSpec で何を変えるか、なぜ変えるか、done の条件、範囲外の files/systems を定義し、その contract に沿って coding agent に実装させます。

Coding Agent Tools の結論

agent confusion のコストが短い spec を書くコストを上回るなら、OpenSpec を入れます。良いシグナルは、proposal、task list、implementation diff、verification output が同じ話をしていることです。