はじめに：OpenCodeでOpenSpecを始める

最近、OpenSpecをOpenCode環境で試してみています。その経験を共有したいと思います。OpenSpecをご存じない方のために簡単に説明すると、仕様駆動開発（SDD）フレームワークであり、AI支援コーディングワークフローに構造をもたらすものです。OpenCodeとの統合もサポートされているので、自分の開発環境にぴったりだと感じました。

この記事では、仕様駆動開発について学んだこと、それがvibe codingとどう組み合わさるか、そしてGitHubのSpec Kitなどの代替案よりもOpenSpecを選んだ理由について説明します。

https://openspec.dev/

仕様駆動開発とは何か？

仕様駆動開発（SDD） は、コードを書く前に明確な仕様を定義するアプローチです。実装に飛び込むのではなく、まず何を作りたいか、なぜ作るのか、どう動作すべきかを明確にします。家を建てる前に詳細な設計図を描くようなものです。

基本的なワークフロー

OpenSpecはシンプルな3段階のプロセスに従います：

1. Propose（提案） — アイデアを説明すると、AIが提案書、仕様書、設計書、タスク分解を生成します
2. Apply（適用） — AIがタスクチェックリストに従って変更を段階的に実装します
3. Archive（アーカイブ） — 完了した変更は、何が行われたかの明確な記録とともにアーカイブに移動されます

主な利点

• 実装前の調整：コードを書く前に、あなたとAIの両方がアプローチについて合意します
• 持続的なコンテキスト：仕様ファイルはコードベース内（openspec/配下）に存在するため、チャットセッション間でコンテキストが消えることはありません
• 追跡可能な進捗：タスクは監視・レビュー可能なチェックリストとして整理されます
• 監査証跡：すべての変更には文書化された履歴があり、過去の判断を理解しやすくなります

Vibe Codingとの組み合わせ

Vibe coding（感覚に基づいて迅速に反復する直感的な開発スタイル）をしている方は、SDDが硬直的すぎるのではと思うかもしれません。私の経験では、実はうまく補完し合っています。Vibe codingは探索や迅速なプロトタイピングに優れており、SDDは複雑な機能の実装や長期的なプロジェクトの維持管理で輝きます。Vibe codingでアイデアを探索し、持続可能なものを作る準備ができたらSDDに切り替えるのが良いでしょう。

oh-my-opencodeでのモデル変更

ちょっと話題を変えますが、以前の投稿をフォローしている方は、oh-my-opencodeのモデル設定の最適化についてご存じでしょう。最近、もう一つ変更を加えました — メインプロンプトモデルをKimi K2.5に切り替えたのです。

興味深いことに、これは業界ニュースとも時を同じくしています：Cursorは最近、新しいComposer 2モデルがKimi K2.5を訓練ベースとして構築されたことを発表しました。Cursorはその上に独自の継続的プレトレーニングと強化学習を追加しましたが、基盤はKimi K2.5です。これは私の決定を裏付けるものです — CursorがコーディングアシスタントにKimiを選ぶなら、自分の環境でも検討する価値があるでしょう。

OpenSpec vs Spec Kit：比較

OpenSpecに決める前に、GitHubのSpec Kitも評価しました。比較は以下の通りです：

主な違い

Spec Kitは、事前計画が報酬となる大規模なグリーンフィールド機能に優れています。包括的なテンプレートと厳格な段階ゲートが徹底性を確保します。しかし、この硬直性は小さなタスクや既存のコードベースでの作業には過剰に感じることがあります。

OpenSpecは一方で、ブラウンフィールドプロジェクトを念頭に設計されています。既存の機能に対する変更を追跡するためにデルタマーカーを使用し、反復的な改善に最適です。ワークフローはより流動的で、硬直的な段階ゲートなしにいつでも任意のアーティファクトを更新できます。

OpenSpecを選んだ理由

両方を試した後、いくつかの理由でOpenSpecに落ち着きました：

1. レガシープロジェクトの維持管理

私の仕事の大部分は、最初から構築するよりも既存のプロジェクトを維持管理することです。OpenSpecのデルタ追跡アプローチ（変更をADDED、MODIFIED、REMOVEDとしてマーク）は、このワークフローにぴったりです。

2. チーム協働の考慮

チーム環境では、全員がOpenSpecを採用するわけではありません。OpenSpecの柔軟性は、チームメンバーがツール自体を使っていなくても、変更を理解してレビューできることを意味します — 仕様はリポジトリ内のただのMarkdownファイルです。

3. シンプルさ

OpenSpecはより軽量で親しみやすく感じられます。Python環境のセットアップや複雑なテンプレートのナビゲーションは必要ありません。シンプルに npm install -g @fission-ai/openspec するだけで準備完了です。

4. 個人の開発ワークフロー

個人のプロジェクトや小さなタスクには、OpenSpecが適切なバランスを提供します。十分な構造を提供しながら、官僚的な感じはしません。

OpenSpecの使い方：ヒントとコツ

はじめに

1
2
3
4
5
6

# OpenSpecをグローバルにインストール
npm install -g @fission-ai/openspec@latest

# プロジェクトで初期化
cd your-project
openspec init

これにより、openspec/ディレクトリが作成されます：

• AGENTS.md — AIエージェントへの指示
• project.md — グローバルプロジェクトコンテキスト
• specs/ — 現在のシステム仕様
• changes/ — アクティブな変更提案

基本的なワークフロー

1. 提案を作成：

   1	/opsx:propose add-user-authentication

   AIが生成するもの：proposal.md、design.md、tasks.md、デルタ仕様

2. レビューと洗練：生成されたファイルを確認し、必要に応じて調整します

3. 変更を適用：

   1	/opsx:apply

   AIがタスクチェックリストに従い、各項目を実装します

4. 完了時にアーカイブ：

   1	/opsx:archive

   完了した変更は openspec/changes/archive/ に移動されます

プロのヒント

• 小さく始める：一度にプロジェクト全体を仕様化しようとしないでください。一つの機能やバグ修正から始めましょう
• 適用前にレビュー：提案段階は、コードが書かれる前に誤解を捉えるチャンスです
• バージョン管理で仕様を保持：openspec/ディレクトリをコミットして、チーム全体が恩恵を受けられるようにしましょう
• 既存プロジェクトでは /opsx:onboard を使用：このコマンドはコードベースをスキャンして初期仕様を生成します

まとめ

OpenCodeでOpenSpecを数週間使用した後、仕様駆動開発が現代のAI支援ワークフローに一席之地を持っていると確信しています。それは創造的で探索的なvibe codingの性質を置き換えるものではありませんが、必要なときに貴重な構造の層を追加します。

OpenSpecの軽量アプローチとOpenCodeのエージェントアーキテクチャの組み合わせは、自然な相性を感じさせます。レガシーコードの維持管理、チームでの協働、または単により意図的な開発プロセスを求めているかどうかに関わらず、試してみることをお勧めします。

すでにoh-my-opencodeを使用している場合、統合はシームレスです — プロジェクトでOpenSpecを初期化して、スラッシュコマンドの使用を開始するだけです。そして、モデル設定の旅に興味がある場合は、oh-my-opencodeモデル選択に関する以前の投稿をチェックしてください。

OpenSpecやSpec Kitで仕様駆動開発を試したことがありますか？コメントであなたの経験を聞かせてください。