目次
はじめに:AIとの共創を「阿吽の呼吸」にするために
AIコーディングツール(Cursor, Gemini, Claude Code, GitHub Copilot)の進化により、私たちは驚くべきスピードでソフトウェアを作れるようになりました。しかし、開発が進むにつれて「AIに意図を伝える難しさ」を感じる瞬間はないでしょうか?
もっとAIとスムーズに連携したい。 自分の頭の中にある設計図を、100%の純度でAIに理解させたい。 チーム開発のように、文脈を共有しながら開発を進めたい。
その願いを叶える鍵が「OpenSpec」であり、それが提唱する「Spec Coding(仕様駆動コーディング)」という新しい開発スタイルです。
本記事では、AI開発を「指示」から「協調」へと進化させるOpenSpecの導入から実践までを、ポジティブかつ体系的に解説します。これを読めば、あなたはAIという最強のパートナーと、真の意味で「ペアプログラミング」ができるようになるでしょう。
Spec Codingとは何か?意図を形にする技術

定義:コードの前に「正解」を定義する
Spec Coding(仕様駆動コーディング)とは、AIにいきなりコードを書かせるのではなく、「まず人間とAIで仕様(Spec)を合意し、それを羅針盤として実装する」というアプローチです。
これは面倒な手続きではありません。むしろ、AIの「論理的思考能力」を最大限に引き出すためのブースト行為です。
- 従来のスタイル: 曖昧なアイデアを投げかけ、AIが出したコードを見て修正を繰り返す。
- Spec Coding: 自然言語で「やりたいこと」を構造化し、AIに文脈(Context)を深く理解させてから、最高精度のコードを一発で出力させる。
Spec Codingがもたらす3つの進化
- 高解像度な実装: AIは仕様書という「正解」を参照しながら書くため、変数の命名からアーキテクチャまで、あなたの意図にピタリと合ったコードを生み出します。
- サステナブルな開発: 「なぜそのコードになったのか」という経緯が仕様書として残るため、将来の拡張やメンテナンスが劇的に楽になります。
- コンテキストの永続化: チャットのログが流れても、Specファイルがある限り、AIはプロジェクトの全容を忘れません。
概念図:Spec Codingによる価値創造のフロー
graph TD
User(("ユーザー(開発者)")) -->|「理想の機能イメージ」| Spec_Phase
subgraph "Spec Coding Workflow"
Spec_Phase["OpenSpec(仕様策定)"]
AI_Context["AIによる文脈理解"]
High_Quality_Code["高品質なコード生成"]
end
Spec_Phase -->|構造化されたMarkdown| AI_Context
AI_Context -->|深い理解と推論| High_Quality_Code
High_Quality_Code -->|実装完了| App[("堅牢なアプリケーション")]
style Spec_Phase fill:#ccffcc,stroke:#333,stroke-width:2px
style AI_Context fill:#e1f5fe,stroke:#333,stroke-width:2px
style High_Quality_Code fill:#fff9c4,stroke:#333,stroke-width:2px
OpenSpecの役割と導入
OpenSpecは、このSpec Codingを誰でも簡単に実践できるように設計された、オープンソースの標準フレームワークです。
OpenSpec = AIとの共通言語
OpenSpecは単なるメモツールではありません。人間とGemini 3、そしてCopilotが最も効率よく意思疎通するための「プロトコル(規約)」です。
- Markdownファースト: 人間にも読みやすく、全てのLLMが最も理解しやすいMarkdown形式を採用しています。
- 変更管理システム: Gitのように、仕様の「提案(Proposal)」「確定(Active)」「アーカイブ(Archive)」といったライフサイクルを管理し、開発の混乱を防ぎます。
- ブラウンフィールド対応: 既存の巨大なコードベースへの機能追加に特化しており、AIに文脈を理解させるための仕組みが整っています。
インストールとセットアップ
最高の開発体験を始める準備は簡単です。
ステップ1:インストール Node.js環境があれば、以下のコマンドでグローバルにインストールします。
npm install -g @fission-ai/openspec
ステップ2:プロジェクトの初期化 開発中のプロジェクトルートで実行します。
openspec init
これだけで、あなたのプロジェクトに「AIとの対話用スペース(.openspec)」が作成されます。
【推奨】Geminiエディタとの統合設定(究極の効率化)
ワークフローを始める前に、開発体験を劇的に向上させる設定を行いましょう。いちいちターミナルでコマンドを打つのは面倒です。
Geminiを搭載した最新のエディタ(例: CursorのGeminiモードや、GoogleのProject IDXなど)では、プロジェクト内に特定の定義ファイルを置くことで、OpenSpecの操作をエディタのコマンドパレットやスラッシュコマンドから直接呼び出せるようになります。
プロジェクトルートに .gemini/command/openspec/ ディレクトリを作成し、以下の3つのTOMLファイルを用意します。これが、エディタとOpenSpecをつなぐ「神経」となります。
.gemini/command/openspec/proposal.toml (新規提案コマンド)
エディタからワンアクションで新しい仕様ドラフトを作成するための定義です。
# エディタのコマンドパレットに表示される名前
name = "OpenSpec: New Proposal"
description = "新しい機能の仕様ドラフトを作成します"
# 実行時にユーザーに入力を求めるプロンプト
[input]
type = "text"
label = "機能のタイトルを入力してください (例: Add AI Recommendation)"
variable = "title"
# 実行される裏側の処理 (OpenSpec CLIを呼び出す)
[action]
type = "execute_command"
command = "openspec new \"${title}\""
# 実行後、生成されたファイルをエディタで開く
open_file = true
これを用意すれば、エディタ上で「New Proposal」を選びタイトルを入れるだけで、ドラフトが生成されて自動で開きます。
.gemini/command/openspec/apply.toml (実装適用コマンド)
これが最も重要です。完成した仕様書(Markdown)をGeminiに読み込ませ、実際のコードへの実装を指示するための定義です。「アーキテクト(仕様書)」から「ビルダー(AI)」への橋渡し役です。
name = "OpenSpec: Apply Spec to Code" description = "現在開いている仕様書に基づいて、Geminiに実装を指示します" [context] # 現在アクティブなファイル(仕様書)をコンテキストとして使用 include_active_file = true # プロジェクトの全ファイル構造も参照させる(Gemini 3なら可能) include_project_tree = true [ai_prompt] # Geminiへのシステム指示 system = """ あなたは熟練した実装エンジニアです。 提供されたOpenSpec仕様書(Markdown)の「Technical Implementation Notes」セクションを注意深く読み、 その内容に忠実に、プロジェクトのコードベースに対して変更を適用してください。 既存のコードスタイルや設計思想を尊重し、デグレを起こさないように注意してください。 """ # ユーザーの追加指示(任意) user_input_label = "追加の指示があれば入力してください (Enterで実行)"
仕様書を開いた状態でこのコマンドを実行すれば、Geminiが仕様書を隅々まで理解し、コードの修正を開始します。
.gemini/command/openspec/archive.toml (アーカイブコマンド)
実装が完了した仕様書を、アーカイブフォルダへ移動させるための定義です。
name = "OpenSpec: Archive Spec"
description = "現在の仕様書を完了とし、アーカイブへ移動します"
[context]
include_active_file_path = true
[action]
type = "execute_command"
# 現在開いているファイルのパスを引数にopenspec archiveを実行
command = "openspec archive \"${active_file_path}\""
これらの設定により、ターミナルを一切触らず、全てエディタの中で完結するフローが実現します。では、実際にやってみましょう。
【実践】OpenSpecワークフローで開発体験を変える
実際に「ブログ機能に『いいね』ボタンを追加する」というシナリオで、そのスムーズな体験を見てみましょう。
Step 1: 仕様のドラフト作成(Proposal)
思いついたら、エディタのコマンドパレットから 以下の(AIプロンプト) を実行し、タイトルに「Add AI Recommendation」と入力します。
OpenSpec: New Proposal
すると、OpenSpecは単なるファイル1つではなく、変更を管理するための専用ディレクトリと複数のファイル群を生成します。これが、AIが「設計」を行うための作業場となります。
📂 生成されるディレクトリ構造とファイルの解説
コマンド実行後、openspec/changes/ 配下に、ユニークなID(動詞から始まる分かりやすい名前)が付いたディレクトリが作成されます。
例: openspec/changes/add-ai-recommendation/
この中には、以下の3つの重要なファイルが含まれています。
openspec/
└── changes/
└── add-ai-recommendation/ <-- 今回の変更専用の作業フォルダ
├── proposal.md # ① 提案の概要(Why & What)
├── design.md # ② アーキテクチャ設計(How)
└── tasks.md # ③ 実装タスクリスト(Action Plan)
それぞれのファイルの中身と、その重要な役割を見ていきましょう。
proposal.md:なぜ作るのか?(Why & What)
これは、変更の「目的」と「範囲」を定義する最上位のドキュメントです。AI(アーキテクト)と人間(プロダクトオーナー)が、ビジネス的な価値について合意するための場所です。
📄 サンプル (proposal.md)
# Proposal: Add AI Recommendation Feature ## Summary (ここに概要を記述) ## Motivation (Why) (ここに背景を記述) ## Goals & Non-Goals (What) ### Goals * [ ] OpenAI APIを用いて商品データのベクトル化を行う。 * [ ] PostgreSQL (pgvector) にベクトルデータを保存する。 * [ ] 商品詳細ページに「関連商品」コンポーネントを表示する。 ### Non-Goals * [ ] ユーザーの閲覧履歴に基づくパーソナライズ(今回は商品間の類似度のみ)。 * [ ] リアルタイム学習機能。
design.md:どう作るのか?(How & Architecture)
これは、技術的な「設計図」です。複数のシステムにまたがる変更や、新しいパターンを導入する場合に、その構造や決定理由を記述します。AIがコードを書くための最も重要な指針となります。
📄 サンプル (design.md)
# Design: AI Recommendation Architecture ## System Context (ここにシステム構成を記述) ## Key Decisions & Trade-offs (ここに設計判断を記述) ## Data Model Changes * `Product` テーブルに `descriptionEmbedding` カラム (vector型) を追加。 ## API Interface * `GET /api/products/[id]/recommendations`: 指定した商品IDに類似する商品リストを返す。
tasks.md:何をするのか?(Action Plan)
これは、設計を具体的な「実装タスク」に分解したリストです。AI(ビルダー)は、このリストを上から順に消化していくことで、迷うことなく実装を進めることができます。
📄 サンプル (tasks.md)
# Tasks: Implementation Plan ## Phase 1: Database & Backend Setup 1. [ ] **DB Migration:** PostgreSQLで `pgvector` 拡張を有効化するマイグレーションを作成・適用する。 2. [ ] **Schema Update:** `schema.prisma` の `Product` モデルにベクトルカラム定義を追加する。 3. [ ] **Embedding Utility:** OpenAI APIを呼び出してテキストをベクトル化する共通関数 (`lib/embedding.ts`) を実装する。 ## Phase 2: API & Frontend 4. [ ] **API Route:** 類似商品検索を行うAPIエンドポイント (`app/api/recommend/route.ts`) をPrismaの生クエリを用いて実装する。 5. [ ] **UI Component:** フロントエンドの `RelatedProducts.tsx` コンポーネントを作成し、SWRでAPIからデータを取得して表示する。 ## Validation * [ ] 商品詳細ページを開き、関連商品が3つ以上表示されること。 * [ ] 表示速度が500ms以内であること。
この3ファイル構成が最強である理由
以前の「1ファイルに全部書く」スタイルから、この「3ファイル構成」に進化したことで、Spec Codingはさらに強力になりました。
- 思考の分離: 「ビジネス目的(Proposal)」「技術設計(Design)」「作業手順(Tasks)」を分けることで、人間もAIも、それぞれのフェーズで考えるべきことに集中できます。
- AIへの明確な指示: Gemini 3のような高度なAIに対し、「まずは
design.mdでアーキテクチャを議論しよう。それが固まったらtasks.mdを作ってくれ」といった、段階的で的確な指示が可能になります。 - 大規模対応: 複雑な機能追加であっても、ファイルが分割されているため見通しが良く、管理が容易になります。
Step 2では、Gemini 3の力を借りて、これらの空欄だらけのファイルを、完璧な仕様書へと練り上げていきます。
Step 2: Gemini 3 と共に仕様を練り上げる(Refine)
ここが最もエキサイティングな時間です。あなたは一人で空欄を埋める必要はありません。Gemini 3の圧倒的なパワーを頼りましょう。
エディタのGeminiチャットを開き、こう話しかけます(ファイルは開いているのでコンテキストに含まれます)。
Gemini 3は、数千ファイルを瞬時に読み込み、コードを書く前にまず「設計」を行います。数秒後、Markdownファイルは、Prismaの具体的な型定義やAPIの仕様まで網羅された、驚くほど詳細な仕様書へと書き換わります。
あなたはそれをレビューし、対話しながら仕様書を完成させます。これが「設計」のプロセスです。
Step 3: 確定した仕様からコードを生成(Implementation)
仕様が固まったら、現場監督(ビルダー)の出番です。ここで、先ほど設定した秘密兵器 .gemini/command/openspec/apply.toml が火を吹きます。
仕様書ファイルを開いた状態で、エディタのコマンド 以下の(AIプロンプト) を実行します。
OpenSpec: Apply Spec to Code
すると、Geminiは確定した仕様書(特に Technical Implementation Notes)を「完璧な指示書」として読み込み、設定されたシステムプロンプトに従って、忠実に実装を開始します。
schema.prisma の変更、マイグレーションファイルの作成、APIルートの実装、フロントエンドコンポーネントの作成…。Gemini 3が描いた完璧な設計図を元にしているため、AIは迷うことなく、驚くべき精度で各パーツを実装していきます。
Step 4: 成功の記録を資産化する(Archive)
機能が無事に実装されテストも通ったら、最後にコマンド以下の(AIプロンプト) を実行します。
OpenSpec: Archive Spec
仕様書は specs/archive/ ディレクトリに移動し、「成功の歴史」として保存されます。これが積み重なると、Gemini 3は次回以降、このアーカイブを参照して「あなたのプロジェクトの流儀」を深く理解するようになり、あなた専属のベテラン開発者へと成長していくのです。
図解でわかるプロジェクト構造の進化
OpenSpecを導入すると、プロジェクトはどのように整理されるのでしょうか。Mermaid図で可視化します。
graph TD
Project_Root["Project Root"]
subgraph "Core Application"
Src_Code["src/ (ソースコード)"]
end
subgraph "OpenSpec Knowledge Base"
Active_Specs["specs/active/ (進行中のタスク)"]
Archive_Specs["specs/archive/ (完了した仕様=資産)"]
Draft_Specs["specs/proposals/ (アイデア段階)"]
end
Project_Root --> Src_Code
Project_Root --> OpenSpec_Knowledge_Base
Draft_Specs -->|AIと共にブラッシュアップ| Active_Specs
Active_Specs -->|実装&テスト成功| Archive_Specs
Archive_Specs -.->|「以前の実装方法」を参照| AI_Agent(("AI Agent"))
AI_Agent -->|高品質な実装| Src_Code
style OpenSpec_Knowledge_Base fill:#e0f7fa,stroke:#006064,stroke-width:2px
style AI_Agent fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2pxプロフェッショナルが教える運用のコツ

私の開発経験に基づき、OpenSpecの効果をさらに高めるポイントを紹介します。
「Why」を語ることでAIは賢くなる
OpenSpecのMarkdownには、技術的なことだけでなく「なぜこの機能を作るのか(ビジネス的な価値やユーザー体験)」を記述してください。 最近のAIは文脈理解力が高いため、目的を理解させることで、単に動くコード以上の、「ユーザーにとって使いやすいコード」を提案してくれるようになります。
小さく始めて、大きく育てる
最初から巨大な仕様書を書く必要はありません。OpenSpecは「アジャイル」なツールです。 「ボタンの色を変える」といった小さな変更から openspec new を使い始めてみてください。小さな成功体験(Small Win)の積み重ねが、信頼性の高いシステムを作り上げます。
未来展望:Spec Codingがスタンダードになる日
OpenSpecのような「仕様駆動」のアプローチは、今後AI開発のスタンダードになっていくでしょう。
なぜなら、これはAIを縛るものではなく、AIに「創造性」を発揮させるための土台だからです。しっかりとした土台(仕様)があるからこそ、AIは安心して高度なリファクタリングや機能提案を行えます。
「コードを書く」という作業はAIに任せ、人間は「どんな未来を作るか(Spec)」を考えることに集中する。OpenSpecは、そんなクリエイティブでワクワクする開発スタイルを実現してくれます。
まとめ
OpenSpecを導入することで得られるポジティブな変化
- 確実性: AIの出力が安定し、手戻りのないスムーズな開発ができる。
- 資産化: 開発プロセスそのものがドキュメントとして残り、チームの財産になる。
- 成長: AIがプロジェクトの文脈を学習し、頼れるパートナーへと進化する。
さあ、あなたも今日からOpenSpecをインストールして、AIとの新しい開発体験「Spec Coding」を始めてみませんか? それはきっと、あなたのエンジニアリングライフをより豊かで、楽しいものにしてくれるはずです。
次のアクション
この記事に共感していただけたら、ぜひご自身の個人プロジェクトで openspec init を実行してみてください。 そして、AIに対して「コードを書いて」と言う前に、「仕様を一緒に考えよう」と話しかけてみてください。その一言が、魔法のような開発体験への入り口です。

