OpenSpec

用語集 ​

OpenSpec の用語をすべて一箇所に集め、平易な言葉で定義しています。一度目を通せば、残りのドキュメントがより素早く読めるようになります。

用語はトピックごとにグループ化され、各グループ内でアルファベット順に並べられています。

中核となる名詞 ​

Spec. システムの一部の動作を記述するドキュメントです。Spec は openspec/specs/ に格納され、ドメインごとに組織化され、要件とシナリオから構成されます。Spec は「このソフトウェアは何をするのか？」に対する合意された答えです。Concepts を参照してください。

Source of truth. openspec/specs/ ディレクトリ全体を指します。システムの現在の合意された動作を保持しています。変更はこれに対する編集を提案し、アーカイブによって適用されます。

Change. 作業の単位を 1 つとし、openspec/changes/<name>/ 配下のフォルダとしてパッケージ化します。Change はその作業に関するすべてを保持します：提案、設計、タスク、そして導入する Spec の編集内容です。1 つの Change は 1 つの機能または修正に対応します。

Artifact. Change 内のドキュメントです。標準的な Artifact は、提案、Delta Spec、設計、タスクです。依存関係の順序で作成され、互いに連携します。

Delta spec. Change 内で、変更される部分のみを記述する Spec です。ADDED、MODIFIED、REMOVED セクションを使用し、Spec 全体を再記述しません。これにより、OpenSpec は既存のシステムをクリーンに編集できます。Concepts を参照してください。

Domain. Spec の論理的なグループ化です。例：auth/、payments/、ui/ など。システムの考え方に合わせてドメインを選択します。

Spec の内部 ​

Requirement. システムが備えるべき単一の動作です。通常は RFC 2119 キーワードを使用して記述します。「The system SHALL expire sessions after 30 minutes.」のように。Requirement は what（何を）を記述し、how（どのように）を記述しません。

Scenario. Requirement が実際に機能している具体的なテスト可能な例です。通常は Given/When/Then の形式で記述されます。シナリオは Requirement を検証可能にします：1 つのシナリオから自動テストを書くことができます。

RFC 2119 keywords. MUST、SHALL、SHOULD、MAY という言葉で、要件の厳格さについて標準化された意味を持ちます。MUST と SHALL は絶対的です。SHOULD は例外を許容する推奨事項です。MAY は任意です。名称はこれらを定義したインターネット標準ドキュメントに由来します。

Artifacts ​

Proposal (proposal.md). Change の why（なぜ）と what（何を）です：意図、スコープ、高レベルなアプローチ。最初に作成する Artifact です。

Design (design.md). how（どのように）です：技術的なアプローチ、アーキテクチャの決定事項、変更する予定のファイル。シンプルな Change では省略可能です。

Tasks (tasks.md). チェックボックス付きの実装チェックリストです。AI は /opsx:apply 実行中にこれを進め、進捗に応じて項目にチェックを入れます。

ライフサイクル ​

Archive. Change を完了させる操作です。Delta Spec がメインの Spec にマージされ、Change フォルダは openspec/changes/archive/YYYY-MM-DD-<name>/ に移動します。アーカイブ後、Spec は新しい現実を記述するようになります。Concepts を参照してください。

Sync. Change をアーカイブせずに、Delta Spec をメインの Spec にマージする操作です。通常は自動的に行われます（アーカイブ時に提案されます）が、長期にわたる Change に対しては /opsx:sync として単独でも利用できます。Commands を参照してください。

ワークフローとコマンド ​

OPSX. 現在の標準 OpenSpec ワークフローです。硬直的なフェーズではなく、流動的なアクションを中心に構築されています。スラッシュコマンドはすべて /opsx: で始まります。OPSX Workflow を参照してください。

Slash command. AI アシスタントのチャットに入力するコマンドです。例：/opsx:propose。スラッシュコマンドはワークフローを駆動します。ターミナルコマンドではありません。How Commands Work を参照してください。

Explore (/opsx:explore). 思考パートナーのコマンドです。コードベースを読み取り、選択肢を比較し、漠然としたアイデアを具体的な計画に明確化します。Artifact は作成せず、コードも書きません。問題はあるが計画がまだない場合の推奨される出発点です。Explore First を参照してください。

CLI. ターミナルで実行する openspec プログラムです。プロジェクトのセットアップ、Change の一覧表示と検証、ダッシュボードの起動、アーカイブを行います。OpenSpec のターミナル側です。CLI を参照してください。

Skill. AI アシスタントが自動検出・追従する指示のフォルダ（.../skills/openspec-*/SKILL.md）です。Skill は、OpenSpec ワークフローをアシスタントに届けるための新興のクロスツール標準です。

Command file. ツールごとのスラッシュコマンドファイル（.../commands/opsx-*）です。旧来の配信メカニズムで、Skill と並行して引き続きサポートされています。直接触れることはほとんどありません。

Profile. プロジェクトにインストールされたスラッシュコマンドのセットです。Core（デフォルト）は propose、explore、apply、update、sync、archive です。expanded セットには new、continue、ff、verify、bulk-archive、onboard が追加されます。openspec config profile で変更します。

Delivery. OpenSpec がツールに対して Skill、コマンドファイル、またはその両方をインストールするかどうかです。グローバルに設定され、openspec update で適用されます。

カスタマイズ ​

Schema. ワークフローが持つ Artifact とその依存関係の定義です。組み込みのデフォルトは spec-driven（proposal → specs → design → tasks）です。フォークしたり、自作したりできます。Customization を参照してください。

Template. Schema 内の Markdown ファイルで、AI が特定の Artifact に対して生成する内容を形作ります。テンプレートの編集は再ビルドなしで即座に AI の出力に影響します。

Project config (openspec/config.yaml). プロジェクトごとの設定です：デフォルトの Schema、すべての計画リクエストに注入される context:、Artifact ごとの rules: です。OpenSpec にスタックや規約を教える最も簡単な方法です。Customization を参照してください。

Context injection. プロジェクトの背景情報を config.yaml の context: フィールドに記述し、AI が生成するすべての Artifact に自動的に追加する仕組みです。AI が別のファイルを読むことを期待するよりも確実です。

Dependency graph. Artifact の requires: 関係によって形成される有向グラフです。DAG（有向非循環グラフ：矢印は前方のみを指し、ループにはなりません）であり、OpenSpec はこれを使用して次に作成できるものを判断します。

Enablers, not gates. Artifact の依存関係は次に何が 可能 になるかを示し、次に何が 必須 であるかを示すものではないという原則です。いつでも任意の Artifact を再訪問・編集できます。Core Concepts at a Glance を参照してください。

リポジトリ間の調整（ベータ） ​

これらの用語は、計画が複数のリポジトリにまたがる場合のみ適用されます。ベータ版です。ほとんどのユーザーは無視して問題ありません。Stores User Guide を参照してください。

Store. 計画を唯一の目的とするスタンドアロンのリポジトリです。既知の openspec/ の構造（specs と changes）に加えて、小さな ID ファイルを持ちます。マシン上で一度名前を登録すると、OpenSpec コマンドはどこからでも Store で動作します。

Reference. コードリポジトリの openspec/config.yaml 内で、そのリポジトリが参照する Store を宣言するものです。Reference は読み取り専用です：リポジトリは自前のルートを持ち、openspec instructions は参照 Store の Spec のインデックスを獲得し、それぞれに取得する正確なコマンドが付きます。

Working context. openspec context が現在のリポジトリに対して組み立てるものです：OpenSpec ルートと、参照するすべての Store（それぞれ取得方法付き）。「何と作業しているのか？」への答えです。

Workset. 一緒に開くフォルダの個人用・マシンローカルのセットです（作業するコードリポジトリと Store が並ぶ）。openspec workset create で明示的に作成します。これらのローカルパスに関する情報は共有計画リポジトリにコミットされません。

関連項目 ​