用語集

OpenSpec の用語を平易な言葉でまとめて定義します。一度目を通しておけば、他のドキュメントを読みやすくなります。

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

基本用語

Spec（仕様）。 システムの一部がどのように動作するかを記述するドキュメントです。仕様は openspec/specs/ に置かれ、ドメインごとに整理され、要件とシナリオで構成されます。「このソフトウェアは何をするのか」について合意した答えです。概念を参照してください。

Source of truth（真実の情報源）。 openspec/specs/ ディレクトリ全体を指します。システムの現在の合意済みの動作が保存されています。change ではここへの変更を提案し、アーカイブ時に反映します。

Change（変更）。 openspec/changes/<name>/ 以下のフォルダーにまとめた、ひとまとまりの作業です。提案、設計、タスク、導入する仕様の変更など、その作業に関するすべてを含みます。1つの change は1つの機能または修正に対応します。

Artifact（成果物）。 change 内のドキュメントです。標準の成果物は、提案、差分仕様、設計、タスクです。依存関係に沿って作成され、互いに情報を引き継ぎます。

Delta spec（差分仕様）。 仕様全体を書き直すのではなく、ADDED、MODIFIED、REMOVED の節を使って変更点だけを記述する、change 内の仕様です。これによって OpenSpec で既存システムを整然と変更できます。概念を参照してください。

Domain（ドメイン）。 auth/、payments/、ui/ など、仕様を論理的にまとめる単位です。システムをどのように捉えるかに合わせて選びます。

仕様の構成要素

Requirement（要件）。 システムが備えるべき1つの動作です。通常、RFC 2119 のキーワードを使って記述します（例:「システムは30分後にセッションを期限切れにしなければならない」）。要件は 何をするか を示し、どのように実現するか は示しません。

Scenario（シナリオ）。 要件が適用される具体的でテスト可能な例で、一般に Given/When/Then 形式で記述されます。シナリオによって要件を検証可能になり、自動テストを書く際にも利用できます。

RFC 2119 キーワード。 要件の厳密さについて標準化された意味を持つ MUST、SHALL、SHOULD、MAY の語です。MUST と SHALL は絶対的な要件です。SHOULD は例外を認める強い推奨です。MAY は任意です。これらを定義したインターネット標準文書に由来します。

成果物

Proposal（提案、proposal.md）。 change の 理由 と 内容、つまり目的、範囲、概要を記述します。最初に作成する成果物です。

Design（設計、design.md）。 技術的な方法、アーキテクチャ上の判断、変更する予定のファイルなど、実現方法 を記述します。単純な change では省略できます。

Tasks（タスク、tasks.md）。 チェックボックス付きの実装チェックリストです。AI は /opsx:apply 中に作業しながら、完了した項目にチェックを付けます。

ライフサイクル

Archive（アーカイブ）。 change を完了する操作です。差分仕様がメインの仕様にマージされ、change フォルダーは openspec/changes/archive/YYYY-MM-DD-<name>/ に移動します。アーカイブ後、仕様が新しい状態を表します。概念を参照してください。

Sync（同期）。 change をアーカイブせずに、差分仕様をメインの仕様にマージする操作です。通常はアーカイブ時に自動で行われます（アーカイブが実行を提示します）が、長期にわたる change のため /opsx:sync コマンドだけで実行することもできます。コマンドを参照してください。

ワークフローとコマンド

OPSX。 固定的なフェーズではなく柔軟な操作を中心にした、現在の OpenSpec 標準ワークフローです。スラッシュコマンドはすべて /opsx: で始まります。OPSX ワークフローを参照してください。

Slash command（スラッシュコマンド）。 /opsx:propose のように AI アシスタントのチャットに入力するコマンドです。ワークフローを進めるためのものであり、ターミナルコマンドではありません。コマンドの実行方法を参照してください。

Explore（/opsx:explore）。 考えを整理するパートナーとなるコマンドです。コードベースを読み、選択肢を比較し、曖昧なアイデアを具体的な計画にします。コードを書くことはなく、調査内容を change として記録するよう依頼するか、提示に同意しない限り、他の内容も書き込みません。問題はあるが計画がまだないときに、最初に使うことを推奨します。まず Exploreを参照してください。

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

Skill（スキル）。 AI アシスタントが自動検出して従う手順をまとめたフォルダー（.../skills/openspec-*/SKILL.md）です。複数のツールに OpenSpec ワークフローを提供する標準として広まりつつあります。

Command file（コマンドファイル）。 ツールごとのスラッシュコマンドファイル（.../commands/opsx-*）です。スキルとともに引き続きサポートされている、従来の配布方法です。通常、直接編集する必要はありません。

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

Delivery（配布形式）。 OpenSpec がツールにスキル、コマンドファイル、または両方をインストールするかを示します。グローバルに設定し、openspec update で適用します。

カスタマイズ

Schema（スキーマ）。 ワークフローが持つ成果物と、それらの依存関係を定義します。組み込みの既定値は spec-driven（proposal → specs → design → tasks）です。フォークしたり、独自のスキーマを作成したりできます。カスタマイズを参照してください。

Template（テンプレート）。 スキーマ内の Markdown ファイルで、特定の成果物について AI が生成する内容を形作ります。テンプレートを編集すると、再ビルドなしで AI の出力がすぐに変わります。

Project config（プロジェクト設定、openspec/config.yaml）。 プロジェクトごとの設定です。既定のスキーマ、すべての計画依頼に注入する context:、成果物ごとの rules: を指定します。技術スタックや規約を OpenSpec に伝える最も簡単な方法です。カスタマイズを参照してください。

Context injection（コンテキスト注入）。 config.yaml の context: フィールドにプロジェクトの背景情報を記述し、AI が生成するすべての成果物に自動で追加します。AI が別ファイルを読むことに期待するより確実です。

Dependency graph（依存関係グラフ）。 成果物間の requires: 関係で形成される有向グラフです。DAG（有向非巡回グラフ。矢印が前方にのみ進み、循環しないグラフ）であり、次に作成できる成果物を判断するために OpenSpec が利用します。

Enablers, not gates（助けであり、関門ではない）。 成果物の依存関係は、次に 可能になること を示すものであり、次に 必須となること を示すものではないという原則です。どの成果物もいつでも見直して編集できます。コア概念の概要を参照してください。

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

これらの用語は計画が複数のリポジトリにまたがる場合にのみ使用します。ベータ版の機能であり、ほとんどの利用者は読み飛ばしてかまいません。Stores ユーザーガイドを参照してください。

Store。 計画管理だけを目的とする独立したリポジトリです。既知の openspec/ 構成（仕様と change）に、小さな識別ファイルが加わります。マシン上で名前を付けて一度登録すれば、どこからでも任意の OpenSpec コマンドで利用できます。

Reference（参照）。 コードリポジトリの openspec/config.yaml で、利用する store を宣言するものです。参照は読み取り専用です。リポジトリは独自のルートを維持し、openspec instructions には参照先の仕様の索引が追加され、それぞれに取得用の正確なコマンドが表示されます。

Working context（作業コンテキスト）。 現在のリポジトリについて openspec context がまとめる情報です。OpenSpec のルートと、参照するすべての store、およびそれぞれの取得方法が含まれます。「何を使って作業しているか」への答えです。

Workset（ワークセット）。 同時に開く、個人用かつマシン上に限定されたフォルダーのセットです（作業中のコードリポジトリと並べた store など）。openspec workset create で明示的に作成します。ローカルパスに関する情報が共有の計画リポジトリにコミットされることはありません。

関連項目

• コア概念の概要: 5つの考え方を1ページで紹介
• 概念: 詳細な説明
• コマンドの実行方法: スラッシュコマンドと CLI の違い