OpenSpecは、AIコーディング作業をMarkdown仕様で追跡可能にする

軽量な仕様レイヤー

OpenSpecは、AIコーディングアシスタントに仕様駆動開発のレイヤーを追加するTypeScriptプロジェクトです。READMEは、要件がチャット履歴にしかない場合、AIアシスタントは強力だが予測不能だと問題を位置づけ、その答えとして、コードを書く前に人間とAIが何を作るか合意できるよう軽量な仕様レイヤーを追加すると述べています。表明された哲学は、固定的ではなく流動的、ウォーターフォールではなく反復的、複雑ではなく簡単、グリーンフィールドだけでなくブラウンフィールド向け、個人プロジェクトからエンタープライズまでスケール可能、というものです。リポジトリはアーカイブされておらず、本稿執筆時点のメタデータでは63,848スターと4,407フォークを示しています。プロジェクトのホームページはopenspec.devです。

アーティファクト駆動のワークフロー

READMEはまず、コーディングアシスタントに入力するスラッシュコマンドを中心とした、アーティファクト駆動と呼ぶワークフローを紹介します。正規のコマンドは/opsx:proposeで、openspec/changes/の下にproposal.md、specs/ディレクトリ、design.md、tasks.mdを含むフォルダを作成します。併用する/opsx:exploreは、コードを読み、選択肢を検討し、何かを書く前に計画を形にする、リスクのない思考パートナーと説明されています。計画ができたら/opsx:applyがタスクを実装し、/opsx:archiveが変更を日付入りのフォルダ名でopenspec/changes/archive/に移動します。READMEはこの流れを会話の書き起こしで示していますが、どのツールがどのコマンドをサポートするかは明記しておらず、正規名がツールごとに異なる表記になる可能性があるとだけ述べています。

仕様はプレーンなMarkdown

仕様はプレーンなMarkdownで書かれ、学ぶべき特別な構文はありません。READMEの例には、'ADDED Requirements'セクション、アプリがSHALLユーザーにライトテーマとダークテーマの切り替えを許可し、システム設定をデフォルトにするという要件、そしてトグル操作をWHENとTHENのステップで書いたシナリオが含まれています。READMEは、これらのアーティファクトをAIが書き、人間がコードを書く前に計画をレビューすると述べています。また、OpenSpecはOpenSpec自身で作られており、リポジトリ自身のopenspec/specsとopenspec/changesディレクトリを大規模な実例として挙げています。

チーム計画のためのStores

チーム利用向けに、READMEは現在ベータ版のStoresを紹介しています。Storeは独立したリポジトリで、同じopenspec/形式の仕様と変更を持ち、他のリポジトリと同様にgit pushで共有されます。想定される用途は、複数のリポジトリにコードが入る変更を1つの計画で扱うクロスリポジトリ機能、プラットフォームチームが仕様を所有し製品チームが読み取り専用で参照する共有要件、そしてコードリポジトリが追いつく前に計画をストアに記録するコード前計画です。READMEはセットアップ用のStoresユーザーガイドにリンクしていますが、ストアの作成や同期の仕組みについてはメインのREADMEでは説明していません。

インストールとコマンド名

インストールにはNode.js 20.19.0以上が必要です。ドキュメントに記載された手順は、npm install -g @fission-ai/openspec@latestを実行し、プロジェクトディレクトリ内でopenspec initを実行するものです。READMEによれば、openspec initはユーザーが選んだツールに応じた正しいコマンド形式を出力します。正規の/opsx:proposeは、CursorとGitHub Copilotでは/opsx-propose、Amazon Qでは@opsx-propose、Codexでは$openspec-proposeと表記される可能性があるためです。READMEは30以上のツールをサポートし、CLIはpnpm、yarn、bun、nixでも動作すると主張しており、インストールオプションはドキュメントにあります。デフォルトプロファイルには/opsx:exploreと/opsx:proposeが含まれ、拡張プロファイルには/opsx:new、/opsx:continue、/opsx:ff、/opsx:verify、/opsx:bulk-archive、/opsx:onboardが追加され、openspec config profileで選択しopenspec updateで適用します。

READMEが示す比較

READMEはOpenSpecを、名前付きの2つの代替製品と、仕様レイヤーをまったく使わない場合と比較しています。github/spec-kitに対しては、徹底しているが重厚で、厳格なフェーズゲート、大量のMarkdown、Pythonセットアップがあり、OpenSpecはより軽量で自由に反復できると主張しています。Kiro（AWS）に対しては、強力だが特定のIDEに縛られClaudeモデルに限定される一方、OpenSpecはユーザーがすでに使っているツールで動作すると主張しています。何も使わない場合に対しては、仕様なしのAIコーディングは曖昧なプロンプトと予測不能な結果を招くとしています。これらはREADMEの主張であり、独立したベンチマークではありません。READMEには性能データや第三者評価は一切ありません。また、高推論能力モデルを推奨し、計画と実装にCodex 5.5とOpus 4.7を挙げ、実装を始める前にコンテキストウィンドウをクリアするよう助言しています。

メンテナンス、テレメトリー、ライセンス

更新は同じnpm installコマンドで行い、各プロジェクト内でopenspec updateを実行してAIガイダンスを再生成し、最新のスラッシュコマンドを有効にします。テレメトリーはデフォルトで有効で、コマンド名とバージョンのみを収集し、引数、パス、コンテンツ、個人情報は収集せず、CIでは自動的に無効になります。オプトアウトはexport OPENSPEC_TELEMETRY=0またはexport DO_NOT_TRACK=1です。貢献ガイドラインは、小さな修正はプルリクエストとして直接送り、大きな変更はまずOpenSpecの変更提案から始めるべきとし、AI生成コードはテスト・検証済みであれば歓迎され、PRにコーディングエージェントとモデルを記載すべきとしています。リポジトリはMITライセンスで、ライセンス条文は使用、複製、変更、統合、公開、配布、サブライセンス、販売の権利を認め、ソフトウェアは現状有姿で提供され保証がないと定めています。条文はセキュリティ体制、サポート、本番稼働への適合性については何も述べていません。

編集部の結論

OpenSpecは、AIコーディングアシスタントに実装前の要件と実装後の確認点を残したいチームに向きます。複雑な計画管理や独自の保存基盤をすぐ必要とする場合、READMEの軽量なモデルだけでは不足する可能性があります。まず `openspec/specs` と `openspec/changes` の構成を自分のリポジトリで作り、提案からアーカイブまでのCLI操作と生成Markdownをレビューできるか確認してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes