Spec Kit と OpenSpec の比較:自分の AI コーディングワークフローに合うのはどちらか

Spec Kit と OpenSpec はどちらも MIT ライセンスのオープンソースツールで、同じ問題に取り組んでいます。要件がチャット履歴にしか存在しないと AI コーディングアシスタントの出力は予測しにくくなるため、先にスペックを書き残し、コードを書く前に人と AI が合意しておく、という考え方です。両者の違いは、プロセスの重さ、スペックの整理の仕方、ツールチェーンにあります。

最初に私たちの立場を

HagiCode 自身のワークフローは OpenSpec をベースにしているため、私たちには偏りがあります。以下の事実は両プロジェクトの公式ドキュメントに基づいており、2026-10-26 に確認しました。私たちの意見にあたる部分は、そのように明記しています。どちらのプロジェクトも更新が速いので、選ぶ前にそれぞれの最新ドキュメントをもう一度確認してください。

何を比較するのか

Spec Kit:GitHub 製です。コマンドラインは specify(Python パッケージ specify-cli)で、インストールと使い方は Spec Kit のインストールにあります。
OpenSpec:Fission AI 製です。コマンドラインは openspec(npm パッケージ @fission-ai/openspec)で、紹介は OpenSpec の紹介にあります。

主な違い

観点	Spec Kit	OpenSpec
実行環境	Python 3.11+、uv または pipx でインストール	Node.js 20.19.0+、npm または Homebrew でインストール
インストールコマンド	`uv tool install specify-cli`	`npm install -g @fission-ai/openspec@latest`
初期化	`specify init my-project --integration claude`	プロジェクト内で `openspec init`
コマンドの接頭辞	`/speckit-*`	`/opsx:`(一部のアシスタントでは `/opsx-`、Codex では `$openspec-*`)
主なフロー	constitution → specify → clarify → plan → checklist → tasks → analyze → implement → converge。最短ルートは specify → plan → tasks → implement → converge	既定のプロファイルは propose、explore、apply、update、sync、archive。拡張プロファイルでは new、continue、ff、verify などが加わる
機能ごとの成果物	`spec.md`、`plan.md`、`tasks.md`、およびチェックリストと分析結果	`proposal.md`、`specs/`、`design.md`、`tasks.md` を含む変更フォルダ 1 つ
スペックの整理の仕方	1 つの機能を中心に完全なスペックを書く	デルタスペックが中心。`ADDED` と `MODIFIED` で変更を記述し、アーカイブ時に長期のスペックへマージする
拡張性	拡張(extension)とプリセット(preset)。公式には bug、assess などがある	カスタムスキーマとコミュニティスキーマ
複数リポジトリ	公式ドキュメントの中核フローには、複数リポジトリ専用のサポートは見当たらなかった	Stores(ベータ)が計画を専用リポジトリに置き、複数のコードリポジトリで共有する
対応アシスタント	公式ドキュメントに数十の統合が載っている	公式ドキュメントでは 30 以上のツールに対応とある
ライセンス	MIT	MIT

プロセスの重さ:最もよく言われる違い

OpenSpec の README は、Spec Kit を「徹底しているが重い。厳格なフェーズゲート、大量の Markdown、Python 環境が必要」とまとめ、自分たちはより軽く、どの成果物もいつでも直せるものだと位置づけています。これは OpenSpec 側の説明です。

公平に見ると、Spec Kit のクイックスタート自体が 5 ステップの最短ルートを示しており、constitution、clarify、checklist、analyze はいずれも任意です。一方、OpenSpec も拡張プロファイルではコマンドがかなり増えます。本当の違いはコマンドの数ではなく、既定のスタンスにあります。Spec Kit は、スペックから実装まで進んで最後に収束させるパイプラインに近く、OpenSpec は、各変更がいつでも修正できる独立したフォルダであることを重視しています。

場面で選ぶ

以下の助言は私たちの判断であり、どちらのプロジェクトの公式な結論でもありません。

あなたの状況	より合う選択	理由
新規プロジェクトで、スペックから実装までの完結したフローがほしい	Spec Kit	フローが完全で、constitution がプロジェクト全体を縛り、`converge` がスペックとの照合で締めくくる
既存コードが多く、毎回小さな部分だけを変える	OpenSpec	デルタスペックは変更点だけを記述するので、既存機能の完全なスペックを書き直す必要がない
チームが主に Python で、uv に慣れている	Spec Kit	インストール方法が技術スタックと一致する
チームが主に Node.js を使っている	OpenSpec	npm のコマンド 1 つでインストールできる
1 つの機能が複数のリポジトリにまたがる	OpenSpec	Stores なら計画を共有リポジトリに置ける。ただしまだベータ
既成の拡張が多くほしい(バグ修正、アイデア評価)	Spec Kit	公式サイトに載っている拡張とプリセットが多い
要件がよく変わり、スペックや計画をいつでも直したい	OpenSpec	成果物に厳格なフェーズがなく、戻って修正できる

判断のポイント

機能より先に、技術スタックと習慣を見る。 両者は機能がかなり重なっているので、環境が合わないことによる摩擦のほうが大きいことが多いです。
同じ小さな機能でそれぞれ一度ずつ試す。 半日で終わる要件を選び、それぞれで全体のフローを通してみるほうが、比較記事を 10 本読むより確かです。
同じプロジェクトに両方を入れない。 どちらのツールもプロジェクトにコマンドとディレクトリを生成するため、混ぜるとアシスタントのコマンド一覧が散らかります。
評価では 3 点を見る。 スペックを書いたことで手戻りが本当に減ったか、使っている AI アシスタントが公式にサポートされているか、チームがこれらの Markdown を喜んで維持できるかです。

HagiCode のやり方

私たちは長く OpenSpec を使っており、それをもとに複数リポジトリのスペック管理と、段階ごとに異なる Agent を使う運用を作ってきました。次の 2 つの記事にまとめています。異なる Agent で OpenSpec の各段階のパフォーマンスを最適化:HagiCode 実践まとめ、MonoSpecs とは何か:なぜそれは OpenSpec のさらなるアップグレードと拡張であると言えるのか。これは私たちの選択であり、すべてのチームにとってより良いという意味ではありません。チームに Spec Kit のほうが合うなら、HagiCode が対応している Claude Code や Codex などの Agent CLI と同じように使えます。準備については AI Agent CLI のインストールを参照してください。