📜

SpecKitの仕様書作成を、NotionAIで代用してみる

に公開

はじめに

GMOメディア株式会社でWebエンジニアしているjunyamaです。

今回の記事では、GitHubが2025年9月2日に公開した「SpecKit」について書いていこうと思います。

書いていく内容ですが、単純にspeckitをインストールした際に追加されたspecコマンドと同じことをNotionAIにやらせて、仕様書をNotion上で作成させてみるだけです。

自分のチームではアジャイル開発を採用しており、チケット管理をNotionで行っています。

ディレクターがタスクやストーリーを作成するので、自動化して仕様書が作成できたら、プランニング中に仕様確認がスムーズになり、仕様書をエンジニア全員で確認できるので、誰がやっても一定の成果物ができあがるのでは?と思ったので試してみます。

SpecKitとは

一応、SpecKitについて軽く説明しておきます。

SpecKitとは、最初に仕様を確定させて、AIにその仕様に沿った形で開発してもらう仕様書駆動開発(SDD)を行うためのツールです。

GitHub CopilotやClaude Codeで、簡単に仕様書駆動開発を行えるようになります。

まだ入れてないよという人は、以下のコマンドで入れてみましょう。

Pythonとuv(Pythonのパッケージマネージャー)が動作すればすぐに導入できます。

uvx --from git+https://github.com/github/spec-kit.git specify init \<PROJECT_NAME\>

SpecKitを導入すると追加されるファイル達

自分はClaude Codeを使っているため以下のような構造になります。

プロンプトが関係あるのはspecifyコマンド(仕様書作成)のみなので、このコマンドをNotionAIで実行できれば、他のコマンドを実行するだけで開発できるはずです。

.claude/
├── commands/                          
│   ├── [speckit.analyze.md](http://speckit.analyze.md)             # 成果物の一貫性・品質分析
│   ├── [speckit.checklist.md](http://speckit.checklist.md)           # カスタムチェックリスト生成
│   ├── [speckit.clarify.md](http://speckit.clarify.md)             # 仕様の不明点を質問で明確化
│   ├── [speckit.constitution.md](http://speckit.constitution.md)        # プロジェクト原則の作成・更新
│   ├── [speckit.implement.md](http://speckit.implement.md)           # [tasks.md](http://tasks.md)に基づく実装実行
│   ├── [speckit.plan.md](http://speckit.plan.md)                # 実装計画ワークフロー実行
│   ├── [speckit.specify.md](http://speckit.specify.md)             # 機能仕様書の作成・更新
│   ├── [speckit.tasks.md](http://speckit.tasks.md)               # タスク分解・[tasks.md](http://tasks.md)生成
│   └── [speckit.taskstoissues.md](http://speckit.taskstoissues.md)       # タスクをGitHub Issueに変換

.specify/
├── memory/                            # プロジェクト記憶・原則
│   └── [constitution.md](http://constitution.md)                # プロジェクト憲法(原則定義)
│
├── scripts/bash/                      # 自動化スクリプト
│   ├── [check-prerequisites.sh](http://check-prerequisites.sh)         # 前提条件チェック
│   ├── [common.sh](http://common.sh)                      # 共通関数
│   ├── [create-new-feature.sh](http://create-new-feature.sh)          # 新機能ブランチ・仕様ファイル作成
│   ├── [setup-plan.sh](http://setup-plan.sh)                  # 計画セットアップ
│   └── [update-agent-context.sh](http://update-agent-context.sh)        # エージェントコンテキスト更新
│
└── templates/                         # テンプレートファイル
    ├── [agent-file-template.md](http://agent-file-template.md)         # エージェントファイルテンプレート
    ├── [checklist-template.md](http://checklist-template.md)          # チェックリストテンプレート
    ├── [plan-template.md](http://plan-template.md)               # 実装計画テンプレート
    ├── [spec-template.md](http://spec-template.md)               # 機能仕様書テンプレート
    └── [tasks-template.md](http://tasks-template.md)              # タスク一覧テンプレート

NotionAIで試すプロンプト

お試しなのでボタンで、AIブロックを生成するようにしました。

NotionAIで試したプロンプトは以下の通りです。

(speckit.specify.mdを参考に、Claudeくんと一緒に作ってみました)

このユーザーストーリーから機能仕様書を作成してください。

## 基本方針

- **WHAT**(何を)と **WHY**(なぜ)に集中する
- **HOW**(どう実装するか)は書かない(技術スタック、API、コード構造は含めない)
- ビジネス担当者が読んでも理解できる内容にする
- 不明点は業界標準や一般的なパターンから推測して埋める
- 確認が必要な項目は本当に重要なもの(スコープ、セキュリティ、UX)に限定(最大3件)

---

## 出力フォーマット

# 機能仕様書: [機能名]

**作成日**: [日付]
**ステータス**: ドラフト

---

## ユーザーシナリオ ※必須

各ユーザーストーリーは優先度順に並べ、それぞれが独立してテスト可能であること。
1つのストーリーだけ実装しても価値を提供できるMVPとして成立すること。

### ユーザーストーリー1 - [タイトル](優先度: P1)

[このユーザージャーニーを平易な言葉で説明]

**この優先度の理由**: [価値と優先度の根拠]

**独立テスト**: [このストーリー単体でどうテストできるか]

**受け入れ条件**:
1. **前提**: [初期状態] → **操作**: [アクション] → **結果**: [期待される結果]
2. **前提**: [初期状態] → **操作**: [アクション] → **結果**: [期待される結果]

---

### ユーザーストーリー2 - [タイトル](優先度: P2)

[説明]

**この優先度の理由**: [根拠]

**独立テスト**: [テスト方法]

**受け入れ条件**:
1. **前提**: → **操作**: → **結果**:

---

### エッジケース

- [境界条件]が発生した場合はどうなるか?
- [エラーシナリオ]をシステムはどう処理するか?

---

## 機能要件 ※必須

- **FR-001**: システムは[具体的な機能]ができなければならない
- **FR-002**: システムは[具体的な機能]ができなければならない
- **FR-003**: ユーザーは[重要な操作]ができなければならない

※不明な要件の例:
- **FR-00X**: システムは[要確認: 認証方式が未指定 - メール/パスワード、SSO、OAuth?]で認証しなければならない

### 主要エンティティ(データを扱う機能の場合)

- **[エンティティ1]**: [何を表すか、主要な属性(実装詳細は含めない)]
- **[エンティティ2]**: [何を表すか、他エンティティとの関係]

---

## 成功基準 ※必須

技術に依存せず、測定可能な基準を定義する。

### 測定可能な成果

- **SC-001**: [測定指標 例: 「ユーザーは2分以内にアカウント作成を完了できる」]
- **SC-002**: [測定指標 例: 「1000人の同時アクセスでも性能劣化なし」]
- **SC-003**: [ユーザー満足度指標 例: 「90%のユーザーが初回で主要タスクを完了」]
- **SC-004**: [ビジネス指標 例: 「関連するサポート問い合わせを50%削減」]

良い例:
- 「ユーザーは3分以内にチェックアウトを完了できる」
- 「検索結果の95%が1秒以内に表示される」

悪い例(技術的すぎる):
- 「APIレスポンスが200ms以内」
- 「DBが1000TPSを処理できる」

---

## 前提条件・未確定事項

### 前提条件
- [推測に基づいて補完した内容をここに記載]

### 未確定事項(最大3件)
- [要確認: 具体的な質問]

実践

出来上がった仕様書を使ってClaude Codeで実行してみます。

出来上がった仕様書をダウンロードして作業プロジェクトに配置しても良いですが、Notionのリンクを教えてあげてplanコマンド実行でも大丈夫でした。

/speckit.plan https://www.notion.so/~~~~~~~~ に仕様書がある

planコマンドですが、Notionから仕様書を読み取ってspec.mdを作成し、本来のplanコマンドで作られるplan.mdやresearch.mdが作成されました。(ついでに本来specifyコマンドで行うブランチ作成と移動も行ってくれました)

今後の展望

NotionAIを使っての仕様書作成はうまくいったので、フローを自動化したいと考えています。

タスクチケットを作成したら自動で仕様書を作成するのはもちろんですが、元々のタスクチケット内容が不明瞭なら良い仕様書ができないので、他のエンジニアが作ってくれたチケット内容をレビューしてくれるAIツールと連携して、チケットと仕様書の質を高めて開発のスピードを上げていければなと思います。

GMOメディアテックブログ

Discussion