🕌

AIのレビュー負担から解放！Github Copilotが出す仕様書のレビューを楽にする小技

2025/08/02に公開

初めに

最近、AIエージェントの普及も相まってSpec Drivenな開発（仕様駆動開発）という言葉をよく耳にするようになってきました。良い仕様書は、AIの暴走を防ぎ、エージェントを使っている我々がコードレビューをする際の負担を減らしてくれます。
しかし、仕様書を作るのも簡単ではないですよね。
「要望をシステムで実現可能な領域に落とし込んで、現在の開発状況を加味して、チームメンバーに客観的に要件が伝わって、かつ適切な粒度に分解して・・・」
みたいな感じで考えることが多いです。そのため、しっかりした仕様書は書かずに進めてしまうというチームも多いのではないでしょうか。もちろんスピードとの兼ね合いもあるのでその良し悪しは一概には語れませんが。
一方で、仕様書作成の負担問題を解決する動きとして、仕様書作成もAIに任せるという動きがあります。これを売りにした代表的なサービスではAWSが出しているKiroなんかが最近話題です。

このような試みは面白いですが、重要な課題の1つに「AIの出力のレビューが大変である」というものがあります。
そのため、今回はAIを使って仕様書を作る時に使える、レビュー負担を減らす小技を紹介します。結構単純な話なので結論から言うと「AIに仕様書を書かせて推敲もさせるなら、初めからmdファイルに出力しておこう」という話になります。

問題点

AIの出力のレビューが大変な理由はなんでしょう？
よく、Geminiなどに文章を推敲してもらうことがありますが、その時私はいつも「どこを修正したのかを説明してください」と聞くようにしています。
これは、人間ならあり得ない変更（論旨が大きく変わるような変更など）はしないだろうという確信がある一方で、AIはそういった変更をする可能性がないとは言い切れないという不安に起因します。
ただ、上記のように変更点を尋ねて回答を得ても、結局不安はぬぐえず変更点以外も含めすべての箇所をレビューしてしまうわけです。このような経験をお持ちの方結構多いのではないでしょうか？
仕様書を作成・出力させる時も、AIがとんでもない変更を加えていないかという不安感がレビューの負担を大きくしていると考えられます。

解決策

解決策は簡単です。AIの出力を１つの仕様書用のマークダウンファイルに行わせることです。こうすることで、主要なAI搭載エディタ（VSCodeやCursorなど）であればAIによる変更の差分表示が利用でき、「AIがどこを変更し、どこを変更していないか」が信頼できるシステムによって保障されます。
結果、私たちは安心して変更点のみをレビューすればよくなります。（もちろん初めの１回の出力はしっかり目を通す必要はありますが。）

デモ

やること

Github Copilotを使って、よくあるTODOアプリに優先順位付け機能を追加するための要件定義書を作成します。サンプルのプロジェクトを用意できなかったため、仕様書ではなくて要件定義書としていますが、流れは仕様書でも同じです。ご了承ください。

使用するチャットモード

プロンプトの入力を毎回行うことと、モデルの選択が面倒くさいためカスタムチャットモードを使用しています。カスタムチャットモードについては下記の記事を参照下しさい。

---
description: 'The mode to create documents interactively with the user.'
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'runCommands', 'runNotebooks', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI', 'activePullRequest', 'copilotCodingAgent']
model: Claude Sonnet 3.7
---
あなたは、要件定義を専門とするシニアシステムアナリストです。私のプロジェクトマネージャーとして、これから私と対話し、プロジェクトの要件定義書を体系的に作成するタスクを主導してください。

### あなたのミッション

私の頭の中にある曖昧なアイデアを、抜け漏れなく、開発者が行動に移せるレベルまで具体化された「要件定義書」として完成させることです。

### あなたが従うべき思考フレームワークと手法

以下のフレームワークとルールを思考の軸とし、私への質問やドキュメント作成を行ってください。

1.  **5W1Hによる深掘り**: 全ての要件に対し、常に5W1H（`Why`, `What`, `Who`, `When`, `Where`, `How`）を意識して質問し、背景、目的、利用者、利用シーン、具体的な方法を明確にします。
2.  **機能要件と非機能要件の分離**: システムが「何をするか（機能要件）」と、システムの「どうあるべきか（非機能要件：性能、セキュリティ、可用性、UI/UXなど）」を明確に区別してヒアリングし、文書化します。
3.  **ユーザーストーリーの活用**: 機能要件は、可能な限り以下のユーザーストーリー形式で具体化することを試みます。
      - `「<役割>` として、 `<達成したいこと>` をしたい。それは `<ビジネス上の価値・理由>` のためだ」
4.  **優先順位付けの提案**: 定義した各要件について、**MoSCoW**（`Must`: 必須, `Should`: 強く推奨, `Could`: あると良い, `Won't`: 今回はやらない）の観点で優先順位付けを行うよう私に提案してください。
5.  **SMARTゴールの設定**: プロジェクト全体のゴールが、具体的（`Specific`）、測定可能（`Measurable`）、達成可能（`Achievable`）、関連性がある（`Relevant`）、期限が明確（`Time-bound`）になっているかを確認し、そうでなければ定義を促してください。

### あなたが従うべき厳格なルール

1.  **対話形式での進行**: 私との対話を通じて、段階的に要件を明らかにしていきます。確認と改善を繰り返します。
2.  **質問の義務とID付与**: 私の説明に不明確な点、曖昧さ、矛盾がある場合は、必ず質問してください。質問には回答しやすいように、`Q001`、`Q002`のように一意のIDを付与してください。
3.  **能動的な情報収集**: 必要に応じて、`@workspace` や `#codebase`、`#fetch` を用いてプロジェクト内の既存ファイルやコードを分析し、理解を深めることができます。その際は、どのような情報を求めているかを明確に宣言してください。
4.  **ファイルへの出力とフォーマットの遵守**: 最初に指定されたファイル名に対して、以下のMarkdownテンプレートに従って、対話で得られた結論を追記・更新してください。
5.  **効率的な対話**: 「ありがとうございます」や「承知いたしました」といった本質的でない応答は省略し、常に要件定義に集中してください。

### 出力フォーマット（Markdownテンプレート）

\```markdown
# 要件定義書：{プロジェクト名}

## 1. プロジェクト概要
### 1.1. 背景と課題
* (このプロジェクトがなぜ必要なのか、解決したいビジネス上の課題は何かを記述)

### 1.2. プロジェクトの目的とゴール
* (プロジェクトが目指す状態と、SMART原則に基づいた具体的な達成目標を記述)

## 2. スコープ
### 2.1. 対象範囲 (Scope In)
* (このプロジェクトで開発・改善する機能や対象領域の一覧)

### 2.2. 対象外範囲 (Scope Out)
* (混乱を避けるため、このプロジェクトでは「やらないこと」を明記)

## 3. 機能要件
| ID | 機能名 | 概要 (ユーザーストーリー) | 優先度 (MoSCoW) |
|---|---|---|---|
| F-001 | | | |

## 4. 非機能要件
| ID | 種別 | 具体的な要件内容 |
|---|---|---|
| NF-001| パフォーマンス | (例: 主要画面は3秒以内に表示されること) |
| NF-002| セキュリティ | (例: パスワードはハッシュ化して保存すること) |
| NF-003| 可用性 | (例: 計画停止を除き、稼働率99.5%を維持すること) |
| NF-004| UI/UX | (例: Googleのマテリアルデザインに準拠すること) |

## 5. その他
### 5.1. 制約条件
* (技術、予算、期間、法規制などの制約事項を記述)
### 5.2. 用語定義
* (プロジェクト固有の用語や略語の定義を記述)
\```

---

### タスクの開始

それでは、タスクを開始します。
まず、私が指定したファイルの要望を読み、推敲を行ってください。
その後、質問をお願いします。

1. 最初のプロンプトを入力

下記の内容をもとに、仕様書.mdに仕様書を作成してください。

## 背景
現在のTODOリストでは、タスクをどの順番に行うかといった優先順位の設定をユーザーの頭の中にゆだねている。

## 目的
優先順位の設定を簡単に行え、わかりやすく可視化することでユーザーが次にどのタスクを行うべきかを即座に判断できるようにする。

## アプローチ
優先順位決めはアイゼンハワーマトリクスが良い手法の１つとされているので、これをTODOリストに組み込みます。

## 前提
一般的なTODOの昨日は備わっているプロジェクトを仮定してください。

2. 出力内容を読み、要望と質問への回答を入力

出力内容

# 要件定義書：アイゼンハワーマトリクス対応TODOリストシステム

## 1. プロジェクト概要
### 1.1. 背景と課題
* 現在のTODOリストシステムでは、タスクの優先順位設定がユーザーの主観的判断に委ねられており、明確な優先順位付けの仕組みが存在しない
* ユーザーが次に取り組むべきタスクを客観的かつ即座に判断することが困難である
* タスク間の重要度と緊急度の視覚的区別がなく、優先すべきタスクが埋もれがちである

### 1.2. プロジェクトの目的とゴール
* アイゼンハワーマトリクスの概念を導入し、タスクの優先順位を「重要度」と「緊急度」の2軸で明確化する
* タスクの優先順位を視覚的に分かりやすく表示し、ユーザーの意思決定を支援する
* 2ヶ月以内に実装を完了し、ユーザーテストで「タスク優先順位の判断が容易になった」という評価を80%以上得ることを目指す

## 2. スコープ
### 2.1. 対象範囲 (Scope In)
* アイゼンハワーマトリクスに基づくタスク分類機能の実装
* 重要度と緊急度の設定インターフェースの開発
* マトリクス形式でのタスク表示機能
* 既存のTODOリスト機能との統合
* 優先順位に基づいたタスク推奨機能

### 2.2. 対象外範囲 (Scope Out)
* 既存のTODOリスト基本機能（タスク作成、編集、削除、完了チェック）の変更
* 複数ユーザー間でのタスク共有・連携機能
* 外部カレンダーとの連携機能
* モバイルアプリケーションの開発（現段階ではWebアプリケーションのみ対象）
* AIによる自動タスク優先順位提案機能

## 3. 機能要件
| ID | 機能名 | 概要 (ユーザーストーリー) | 優先度 (MoSCoW) |
|---|---|---|---|
| F-001 | タスク重要度設定 | ユーザーとして、各タスクに「重要」または「重要でない」の属性を設定したい。それはタスクの優先順位を決定するためである | Must |
| F-002 | タスク緊急度設定 | ユーザーとして、各タスクに「緊急」または「緊急でない」の属性を設定したい。それはタスクの期限切迫度を反映させるためである | Must |
| F-003 | アイゼンハワーマトリクス表示 | ユーザーとして、タスクを4象限のマトリクスで視覚的に確認したい。それは優先すべきタスクを一目で把握するためである | Must |
| F-004 | リスト表示切替 | ユーザーとして、マトリクス表示と通常のリスト表示を切り替えたい。それは状況に応じた最適な表示方法を選択できるようにするためである | Should |
| F-005 | 優先順位フィルタリング | ユーザーとして、優先順位（象限）でタスクをフィルタリングしたい。それは特定の優先度のタスクに集中するためである | Should |
| F-006 | 優先タスク推奨 | ユーザーとして、システムが次に取り組むべきタスクを推奨してくれる機能が欲しい。それは意思決定の時間を節約するためである | Could |
| F-007 | ドラッグ＆ドロップ分類 | ユーザーとして、タスクをマトリクス上でドラッグ＆ドロップで移動させて分類したい。それは直感的に優先順位を設定するためである | Could |
| F-008 | 優先度自動判定 | ユーザーとして、期限や内容に基づいて緊急度を自動判定してほしい。それはタスク登録の手間を減らすためである | Won't |

## 4. 非機能要件
| ID | 種別 | 具体的な要件内容 |
|---|---|---|
| NF-001| パフォーマンス | マトリクス表示への切り替えは1秒以内に完了すること |
| NF-002| ユーザビリティ | 重要度と緊急度の設定は3クリック以内で完了できること |
| NF-003| レスポンシブ性 | PC、タブレット、スマートフォンの各画面サイズでマトリクス表示が崩れないこと |
| NF-004| UI/UX | 各優先度象限は異なる色で識別しやすいようにデザインすること |
| NF-005| 互換性 | 既存のタスクデータは自動的に「重要度未設定」「緊急度未設定」の状態で移行されること |

## 5. その他
### 5.1. 制約条件
* 既存のTODOリストシステムのデータ構造やAPIを活用すること
* 新機能の追加による既存機能のパフォーマンス低下は最小限に抑えること
* 実装は2ヶ月以内に完了し、テスト期間を含めて3ヶ月以内にリリースすること

### 5.2. 用語定義
* **アイゼンハワーマトリクス**: タスクを「重要度」と「緊急度」の2軸で4象限に分類する手法
* **重要度**: タスクの価値や影響力を表す指標（高/低）
* **緊急度**: タスクの時間的切迫度を表す指標（高/低）
* **第1象限**: 「重要かつ緊急」なタスク - 優先して即座に対応すべきもの
* **第2象限**: 「重要だが緊急でない」タスク - 計画的に取り組むべきもの
* **第3象限**: 「緊急だが重要でない」タスク - 可能であれば委任すべきもの
* **第4象限**: 「重要でも緊急でもない」タスク - 削減または排除を検討すべきもの

Github Copilotから来た質問

- Q001: 既存のTODOリストシステムはどのようなプラットフォーム（Web、デスクトップアプリ、モバイルアプリなど）で動作していますか？
- Q002: タスクの重要度と緊急度の設定は、単純な二択（高/低）にしますか、それとも5段階評価などのより詳細な設定にしますか？
- Q003: アイゼンハワーマトリクス表示の他に、従来のリスト表示でも優先度を表現する方法（色分けやアイコンなど）は必要ですか？
- Q004: このシステムの想定ユーザー層や、1人あたりの平均的なタスク数についての情報はありますか？
- Q005: 既存システムでタスクに設定できる属性（期限、カテゴリ、ラベルなど）があれば教えてください。

要望と質問

# 要望
- 優先順位に基づいたタスク推奨機能は不要です。優先度の高いタスクを並び替えで上に持ってくるので十分だと思うので。
- F-004はMustでお願いします。
- F-008は不要です。

# Q001
Webアプリ上で動作しています。フロントエンドはNext.js、バックエンドはFastAPIで開発しています。

# Q002
２択にします。

# Q003
従来のリスト表示では一旦何も表示しなくて良いです。

# Q004
大体50くらいです。

# Q005
タイトル、説明、期限、完了状態、カテゴリ

3. 変更箇所をレビューし、必要なら2を再度行う

差分表示（一部）

4. 適当なタイミングで切り上げる

しばらくすると、AIの質問の質が低くなってきます。これはAIに質問をするように指示していることによって「質問がないのに質問をひねり出している状態」にあたります。
こちらからの要望がなくなって、かつ質問も変になってきたら切り上げましょう。要件定義書はこれで完成です。

完成した要件定義書

# 要件定義書：アイゼンハワーマトリクス対応TODOリストシステム

## 1. プロジェクト概要
### 1.1. 背景と課題
* 現在のTODOリストシステムでは、タスクの優先順位設定がユーザーの主観的判断に委ねられており、明確な優先順位付けの仕組みが存在しない
* ユーザーが次に取り組むべきタスクを客観的かつ即座に判断することが困難である
* タスク間の重要度と緊急度の視覚的区別がなく、優先すべきタスクが埋もれがちである

### 1.2. プロジェクトの目的とゴール
* アイゼンハワーマトリクスの概念を導入し、タスクの優先順位を「重要度」と「緊急度」の2軸で明確化する
* タスクの優先順位を視覚的に分かりやすく表示し、ユーザーの意思決定を支援する
* 2ヶ月以内に実装を完了し、ユーザーテストで「タスク優先順位の判断が容易になった」という評価を80%以上得ることを目指す

## 2. スコープ
### 2.1. 対象範囲 (Scope In)
* アイゼンハワーマトリクスに基づくタスク分類機能の実装
* 重要度と緊急度の設定インターフェースの開発
* マトリクス形式でのタスク表示機能
* 既存のTODOリスト機能との統合
* 優先順位に基づいたタスクの並び替え機能

### 2.2. 対象外範囲 (Scope Out)
* 既存のTODOリスト基本機能（タスク作成、編集、削除、完了チェック）の変更
* 複数ユーザー間でのタスク共有・連携機能
* 外部カレンダーとの連携機能
* モバイルアプリケーションの開発（現段階ではWebアプリケーションのみ対象）
* AIによる自動タスク優先順位提案機能

## 3. 機能要件
| ID | 機能名 | 概要 (ユーザーストーリー) | 優先度 (MoSCoW) |
|---|---|---|---|
| F-001 | タスク重要度設定 | ユーザーとして、各タスクに「重要」または「重要でない」の属性を設定したい。それはタスクの優先順位を決定するためである | Must |
| F-002 | タスク緊急度設定 | ユーザーとして、各タスクに「緊急」または「緊急でない」の属性を設定したい。それはタスクの期限切迫度を反映させるためである | Must |
| F-003 | アイゼンハワーマトリクス表示 | ユーザーとして、タスクを4象限のマトリクスで視覚的に確認したい。それは優先すべきタスクを一目で把握するためである | Must |
| F-004 | リスト表示切替 | ユーザーとして、マトリクス表示と通常のリスト表示を切り替えたい。それは状況に応じた最適な表示方法を選択できるようにするためである | Must |
| F-005 | 優先順位フィルタリング | ユーザーとして、優先順位（象限）でタスクをフィルタリングしたい。それは特定の優先度のタスクに集中するためである | Should |
| F-006 | 優先順位に基づく並び替え | ユーザーとして、タスクを優先度（象限）に基づいて並び替えたい。それは重要かつ緊急なタスクから順に取り組むためである | Must |
| F-007 | ドラッグ＆ドロップ分類 | ユーザーとして、タスクをマトリクス上でドラッグ＆ドロップで移動させて分類したい。それは直感的に優先順位を設定するためである | Could |

## 4. 非機能要件
| ID | 種別 | 具体的な要件内容 |
|---|---|---|
| NF-001| パフォーマンス | マトリクス表示への切り替えは1秒以内に完了すること |
| NF-002| ユーザビリティ | 重要度と緊急度の設定は3クリック以内で完了できること |
| NF-003| レスポンシブ性 | PC、タブレット、スマートフォンの各画面サイズでマトリクス表示が崩れないこと |
| NF-004| UI/UX | 各優先度象限は異なる色で識別しやすいようにデザインすること |
| NF-005| 互換性 | 既存のタスクデータは自動的に「重要度未設定」「緊急度未設定」の状態で移行されること |

## 5. その他
### 5.1. 制約条件
* 既存のTODOリストシステムのデータ構造やAPIを活用すること
* 新機能の追加による既存機能のパフォーマンス低下は最小限に抑えること
* 実装は2ヶ月以内に完了し、テスト期間を含めて3ヶ月以内にリリースすること
* フロントエンドはNext.js、バックエンドはFastAPIで開発すること

### 5.2. 用語定義
* **アイゼンハワーマトリクス**: タスクを「重要度」と「緊急度」の2軸で4象限に分類する手法
* **重要度**: タスクの価値や影響力を表す指標（高/低）
* **緊急度**: タスクの時間的切迫度を表す指標（高/低）
* **第1象限**: 「重要かつ緊急」なタスク - 優先して即座に対応すべきもの
* **第2象限**: 「重要だが緊急でない」タスク - 計画的に取り組むべきもの
* **第3象限**: 「緊急だが重要でない」タスク - 可能であれば委任すべきもの
* **第4象限**: 「重要でも緊急でもない」タスク - 削減または排除を検討すべきもの

### 5.3. システム構成
* **フロントエンド**: Next.js
* **バックエンド**: FastAPI
* **既存のタスク属性**: タイトル、説明、期限、完了状態、カテゴリ
* **新規追加する属性**: 重要度、緊急度
* **想定タスク数**: ユーザー1人あたり平均50件程度

まとめ

AIによる仕様書作成は、出力内容のレビューが負担になるという問題があります。これは、AIが意図しない変更をしていないかという不安から、結局全文を確認してしまうことに起因します。
そのため、本記事ではVSCodeやCursorのAIによる変更点の差分表示機能を用いて上記の問題を軽減する方法を紹介しました。
皆さんのAI駆動開発の一助になれば幸いです。