組織活用に最適！Notion×AI要件定義レビューの仕組みを大公開
著者: すぅ AI駆動PM 媒体: note 公開日: 2025-11-08
概要
「営業から来る要望メモの粒度がバラバラ」「テンプレートを配っても項目が埋まらない」「会議のたびに非機能要件が抜けて見積もりがブレる」という要件定義の典型課題に対し、Notionのボタン一発でAIレビューを回し、テンプレートに自動整形したうえで不足点を赤ペン指摘まで返す仕組みを実装する方法を解説した記事。
技術スタックは Notion × Make × GitHub Actions × OpenAI API。非エンジニアでも実務導入できるよう9ステップで分解されている。
解決する課題
- 要件入力の粒度バラつき（書き手の経験差）
- テンプレートを配布しても揃わない
- レビュー担当者の稼働逼迫・遅延蓄積
- レビュー基準の人による分散
仕組みの全体フロー
[担当者が Notion ページに要件を自由記述]
↓
[「要件定義レビュー」ボタンを押す]
↓
[Make の Webhook が起動]
↓
[Make → GitHub Actions の workflow_dispatch を呼び出し]
↓
[GitHub Actions が以下を実行]
1. Notion API で対象ページ内容を取得
2. テンプレート定義ページを参照し不足フィールドを補完・整形
3. レビュー観点ページを適用し不足・曖昧さを赤ペン指摘として生成
4. Notion API でページ本文・コメントを更新
5. ステータスを「レビュー中」→「完了」または「差し戻し」へ遷移
テンプレート定義ページの章立て（Step 3）
- 概要（何を実現するか）
- 背景・目的（なぜ必要か）
- 対象ユーザー／ステークホルダー
- スコープ（含む／含まない）
- ユーザーストーリー
- 受け入れ条件（テスト観点）
- 非機能要件（性能／セキュリティ／運用）
- 依存関係／前提／制約
- リスクと対応方針
- スケジュール案／優先度
レビュー観点の例（Step 3）
- 目的の明確さ
- スコープの境界
- 受け入れ条件の検証可能性
- 非機能要件の具体性（数値目標の有無）
- 依存とリスクの記載有無
- 曖昧語の排除
赤ペン指摘サンプル:
- 受け入れ条件に「ユーザーが確認できる事実」が書かれていません
- 非機能要件に数値目標（P95応答時間・可用性・RTO/RPO）がありません
- スコープの「含まない」が空欄です
- リスクに「発生確率と影響度」の記載がありません
GitHub Actions のシークレット構成（Step 5）
| シークレット名 | 内容 |
|---|---|
| NOTION_TOKEN | Notion統合で発行したトークン |
| TEMPLATE_PAGE_ID | テンプレート定義ページのID |
| REVIEW_CRITERIA_PAGE_ID | レビュー観点ページのID |
| OPENAI_API_KEY | OpenAI APIキー |
設計上の重要な考え方
- Makeには詳細ロジックを持たせない: 中継と権限分離に徹し、整形・レビュー生成はActions側に集約
- 冪等性の担保: 同じページIDへの複数回実行でも破壊的にならない設計（整形済みセクションのみ差し替え・赤ペンはタイムスタンプ付き追記）
- テンプレート変更はNotionページだけで完結: Actionsのコードを頻繁にいじらない運用設計
期待できる効果
- 粒度の均一化（フォーマット統一による読み手の理解負荷低減）
- 往復回数の削減（最初の提出で必要項目が揃いやすくなる）
- レビュー時間の短縮（赤ペン指摘に沿った補完でレビューアー判断が早まる）
- 属人性の低減（観点ページをチーム資産として更新し暗黙知を明示知化）
- 処理時間目安: ボタン押下後2〜3分（AIモデルによる）
応用ケース
- 企画書・提案書のレビュー
- マニュアル・手順書の品質チェック
- レポート・報告書の標準化
- 教育資料・研修資料の完成度チェック
- 契約書・規約のレビューポイントチェック
チーム導入の進め方
- 1チーム／1案件でパイロット運用を開始（小さく始める）
- 週次で差し戻し理由を観点ページに反映
- DBの説明ページに運用ルールとSLAを明記
- 利用者には「書いて押す」の二点のみ伝える（教育は最小限）