OpenSpec対Spec Kit：AIエージェント開発向けスペック駆動フレームワークの選択

AIコーディングエージェントは人間よりも速くコードを書きます。ボトルネックはシフトしました。スペックが今やプロダクトです。 エージェントが作業するための明確で構造化された仕様を持たない場合、アーキテクチャを幻覚し、要件を発明し、誰も頼んでいないテストに合格するコードを生成します。

この問題を解決する2つのフレームワークが現れました。OpenSpec（GitHub stars約28k）とGitHubのSpec Kit（約75k stars）です。両方ともMITライセンスです。両方ともAIエージェントが直接消費するスラッシュコマンドを生成します。しかし速度とガバナンスの間に根本的に異なるトレードオフがあり、間違った方を選ぶとチームに数週間のやり直しを強います。

選び方を説明します。

コアの分割：流動的な反復対構造化ガバナンス

OpenSpecはNode.js CLI（@fission-ai/openspec）で、スペックを軽量でリポジトリネイティブなアーティファクトとして扱います。作業を提案、仕様、設計、タスクファイルを含む変更フォルダに編成します。哲学は最小限の儀式です。素早くエージェントにスペックを提示し、反復し、完了時にアーカイブ。

Spec Kit（GitHubのフレームワーク、specify CLIと/speckit.*コマンドを中心）は、すべてを憲法、つまり制約、コーディング標準、TDD要件、コンプライアンスルールをエンコードするプロジェクトレベルのドキュメントに固定します。すべての機能は各ゲートにテンプレートとチェックリストを備える構造化フェーズパイプラインを通じて流れます。

違いは表面的ではありません。チームが機能ごとに吸収するオーバーヘッドの量、エージェントがプロンプトごとに消費するコンテキストの量、そして監査証跡がコンプライアンスレビュー担当者を満足させるかどうかを決定します。

ワークフロー比較

OpenSpec：4コマンド、最小摩擦

OpenSpecのワークフローは意図的に短いです。

graph LR
    A["/opsx:propose"] --> B["/opsx:explore"]
    B --> C["/opsx:apply"]
    C --> D["/opsx:archive"]

1. /opsx:propose — 提案ドキュメントを含む変更フォルダを作成
2. /opsx:explore — そのフォルダ内でスペックと設計を反復
3. /opsx:apply — 確定したスペックに基づき実装を実行
4. /opsx:archive — 完了した作業をアーカイブに移動

これだけです。憲法なし。必須の明確化フェーズなし。タスク分解ゲートなし。提案、探索、適用、アーカイブします。適用から探索へ戻る必要がある場合、ただ行うだけで、それを止めるフェーズゲート強制はありません。

OpenSpecはプロンプト膨張を防ぐため50KBコンテキスト制限を強制します。これは意図的な設計選択です。OpenSpecスペックで作業するエージェントは巨大なコンテキストウィンドウで詰まりません。これはモノレポ全体で複数のエージェントを実行する場合に重要です。

Spec Kit：6フェーズ、憲法固定

Spec Kitのパイプラインはより広範です。

graph LR
    A["/speckit.constitution"] --> B["/speckit.specify"]
    B --> C["/speckit.clarify"]
    C --> D["/speckit.plan"]
    D --> E["/speckit.tasks"]
    E --> F["/speckit.implement"]
    G["/speckit.analyze"] -.-> B

1. /speckit.constitution — プロジェクト全体のルール、制約、標準を定義
2. /speckit.specify — 詳細な機能仕様を作成
3. /speckit.clarify — 曖昧さと未解決の質問を解決
4. /speckit.plan — 実装計画を生成
5. /speckit.tasks — 計画を個別の割り当て可能なタスクに分解
6. /speckit.implement — TDDゲートとチェックリスト検証を備えてタスクを実行
7. /speckit.analyze（オプション） — 変更を指定する前に既存のコードを分析

憲法が主要な差別化要因です。これは後続のすべてのコマンドが尊重する生きたドキュメントです。憲法が「すべてのデータベース変更は移行スクリプトを必要とする」または「再試行ロジックなしの直接APIコールは不可」と言う場合、エージェントはすべてのフェーズでそれらのルールを強制します。規制産業、医療、金融、政府向けには、これがまさにコンプライアンス要件を開発ワークフロー自体にエンコードするために必要なメカニズムです。

直接比較

コンテキスト税問題

Spec Kitの力にはコストが伴います。インストールされたすべてのスラッシュコマンド、すべてのテンプレート、すべての憲法ルールがエージェントのコンテキストウィンドウにトークンを追加します。複数の拡張を備えてSpec Kitを実行するチームは重大なコンテキスト税を報告します。エージェントがあなたのコードについて推論する代わりにフレームワーク指示を解析してトークンを消費します。

これはスケールで重要です。Spec Kitの完全なコマンドセットをロードしてClaude CodeやCodexを大規模コードベースに対して実行している場合、フレームワークオーバーヘッドでコンテキストを消費しています。一部のチームは実用的なトークン予算内に収めるため拡張を剪定するか憲法を分割する必要があると報告しています。

OpenSpecは50KBコンテキスト制限でこれを回避します。これは鈍い道具です。同じ深さのガバナンスをエンコードできませんが、フレームワークメタデータではなく実際の仕様にエージェントを集中させ続けます。

エンタープライズのポイント：エージェントが既にコンテキスト制約されている（大規模コードベース、複雑なシステムプロンプト、マルチファイル変更）場合、コミット前にSpec Kitのコマンドセットのトークンコストを測定してください。OpenSpecの上限は低いが予測可能です。

OpenSpecを使う場合

次の場合にOpenSpecを選ぶ：

• 速度がプロセスより重要なラピッドプロトタイピングや概念実証作業をしている
• チームが複数のAIエージェントツールを使用し、すべてで機能する単一の軽量スペックレイヤーを望む
• 実装開始後にスペックを変更するなど、フライト中に反復する必要がある、フェーズゲートと戦わずに
• コードベースが大きくコンテキスト予算が現実の制約
• 完全なガバナンスフレームワークを採用せずにスペック駆動開発を望む

OpenSpecの「コア」プロファイルはスペック駆動AI開発への最低摩擦のエントリポイントです。CLIをインストールし、変更フォルダを作成するだけで、エージェントは作業する構造化されたスペックを持ちます。書く憲法も、キュレートする拡張カタログもありません。

Spec Kitを使う場合

次の場合にSpec Kitを選ぶ：

• ガバナンスと反復性がオーバーヘッドを正当化する本番システムを構築している
• 組織が規制ドメイン（医療、金融、政府）で運用し、コンプライアンスルールを開発ワークフローにエンコードする必要がある
• 後からボルトオンではなくフレームワークに焼き込まれたTDD強制を望む
• チームが構造化フェーズゲート、計画前の明確化、実装前の計画から恩恵を受ける
• 組織固有のワークフロー向けにフックとキュレートされた拡張カタログ経由の拡張性が必要

Spec Kitの憲法モデルはエンタープライズコンテキスト向けに真に強力です。「すべてのAPIエンドポイントはOpenAPIドキュメントを必要とする」または「すべての状態変更はイベントソーシングを必要とする」を憲法ルールとしてエンコードすることは、エージェントがそれらを毎回自動的に強制することを意味します。それはガバナンスの芝居ではなく、実際に実行するガバナンスです。

ハイブリッドアプローチ：軽く始め、構造を追加

これらのフレームワークは哲学的に相互排他ではありません。多くのエンタープライズチーム向けの実践的な道：

1. OpenSpecで始める。初期探索とプロトタイピング用。オーバーヘッドなしにスペックの習慣を確立。
2. Spec Kitに移行。プロジェクトが本番に昇格し、ガバナンス、コンプライアンスエンコーディング、反復可能なフェーズワークフローが必要な時に。
3. OpenSpecをサイドプロジェクト、社内ツール、Spec Kitの儀式が速度を落とすラピッド実験向けに保持。

最悪の結果はスペックフレームワークが全くないことです。曖昧なプロンプトから作業するエージェントが、誰も書かなかった要件に対して誰もレビューしなかったコードを生成することです。

実践的なポイント

1. スペック駆動開発はもはやオプションではありません。 AIエージェントが構造化されたスペックを持たない場合、幻覚した要件をデバッグしています。フレームワークを選んでください。

2. コンテキスト予算を最初に測定。 Spec Kitの完全なコマンドセットをロードしてエージェントを実行し、フレームワークオーバーヘッドにいくつのトークンが向かうか確認してください。コンテキストウィンドウの15〜20%を超える場合、OpenSpecまたはトリムしたSpec Kit設定を検討してください。

3. 規制産業向け、Spec Kitの憲法は元を取る。 エージェントが自動的に強制するコンプライアンスルールのエンコーディングは、追加のアーティファクトオーバーヘッドに価値します。代替はエージェント生成のすべての変更の規制コンプライアンスに向けた手動レビューです。

4. ラピッドプロトタイピング向け、OpenSpecは速度で勝つ。 4コマンド、50KBコンテキスト制限、保守する憲法なし。素早くスペックをエージェントに提示。

5. アーカイブ/クリーンアップステップをスキップしない。 両フレームワークが完了した作業のアーカイブをサポート。リポジトリ内の古いスペックは将来の実行でエージェントを混乱させます。積極的にアーカイブ。

6. 実際のスタックに対して両方を評価。 各フレームワークの例リポジトリをクローンし、好みのAIエージェントでコードベースに対して実行し、出力品質とトークンコストを比較。正しい選択はGitHub star数ではなくチームのガバナンスニーズに依存します。