ビジネス担当の企画に、6人の専門家AI+検証役が意見書を返す ― Claude Codeスキル公開

🧭 本記事は Claude Code実務運用シリーズ の STEP 5「レビュー自動化する」です。
レビューの対象をコードから「ビジネス企画」に広げ、専門家AIの意見書を返します。
シリーズ全体の地図と読む順は 親記事 にまとめています。

はじめに

ビジネス担当から企画が来たとき、エンジニア側はこういう対応をしがちです。

• 忙しくて「あとで見ます」のまま数日寝かせる
• パッと見の印象で「たぶんできますよ」と答えて、後で仕様の衝突に気づく
• 技術的な懸念を伝えたいが、専門用語だらけになって伝わらない

逆に、AIにそのまま企画を貼って「意見して」と聞くと、今度は一般論のコンサル風の答えが返ってきます。「ユーザー体験の観点から段階的なリリースを推奨します」— それらしいけれど、自社アプリの既存仕様を1行も踏まえていない。

そこで、企画に対して「上流工程のプロチーム」が自社アプリの既存仕様に照らした意見書を作るカスタムスキルを作りました。

/plan-review 企画書.md

企画がRedmineやBacklogのチケットとして起票されているなら、チケットをそのまま渡すこともできます。

/plan-review PROJ-123

この記事は2部構成です。

• 前半: 仕組みの解説。エンジニアでなくても読めるように書いています（この意見書を受け取るビジネス側の方にも読んでほしい部分です）
• 後半: エンジニア向けの導入手順と、コピペで使える公開用テンプレート

本記事の構成は完全自動化ではなく、意見書はあくまで「たたき台」で、最終判断は人間が行う前提です。実プロジェクト名、内部URL、実際の企画内容などは一切含めていません。

前半: 仕組み（非エンジニア向け）

なぜ「1人のAI」に聞かないのか

AIに企画への意見を求めると、1回の回答で要件・実装・UX・リスクをまとめて語ろうとします。すると、こうなります。

• 観点が混ざって、それぞれが浅くなる
• 得意な話（実装）に引っ張られて、苦手な話（ビジネス整合）が薄くなる
• もっともらしいが根拠のない意見が混ざる

人間の組織がそうしているように、観点ごとに担当を分けます。

ポイントは3つあります。

1. 6人の専門家は互いの結論を見ずに独立して検討する（後の人が前の人に引っ張られない）
2. 統合役が重複と矛盾を整理する（指摘の数ではなく、根拠の強さで判断する）
3. 検討に関わっていない検証役が、意見の根拠を仕様書と突き合わせて確認する（根拠のない意見はここで落ちる）

「プロの意見」の正体は、接地（グラウンディング）

このスキルの品質を決めているのは、実はプロンプトの工夫ではありません。自社アプリの仕様ドキュメントです。

同じ企画に対する2つの意見を比べてください。

一般論のAI:
「既存機能との整合性に注意が必要です」

接地したAI:
「本棚のロック機能の既存仕様と競合します（docs/本棚ロック.md）。
 ロック中の本棚に通知バッジを出すかどうかの仕様判断が必要です」

後者が「プロの意見」に見えるのは、AIが賢いからではなく、参照できる仕様書があるからです。各専門家は検討の際に関連する仕様書を実際に読み、意見には出典（どの仕様書・どの画面）を付けます。検証役は、その出典が本当に意見を支えているかを確認します。

「仕様書がないプロジェクトでは使えないのか」と思うかもしれませんが、そうではありません。動いている仕様の最終的な真実はソースコードです。仕様書がなければ、各専門家はコードを一次情報として接地できます（このスキルはコード検索・実装確認を含みます）。

ただし、仕様書にはコードが構造的に答えにくい情報が2つあります。

1. 意図と経緯——「なぜこの仕様なのか」「なぜやらないと決めたのか」。企画レビューで一番効くのは、実はこの種の情報です
2. 語彙の索引——企画は「本棚」「通知」というビジネスの言葉で書かれ、コードはクラス名で書かれています。仕様書はこの翻訳表になり、探索コストと見落としを大きく減らします

そして、この「意図と経緯」が最もよく残っている場所のひとつが、チケットのコメント欄です。

仕様書には「今こうなっている」という結論は書かれても、「なぜそうしたか」「なぜ別案を捨てたか」は落ちがちです。一方チケットのやり取りには、その判断の過程がそのまま残っています。企画レビューで一番効くのは、まさにこの種の情報でした。だからこのスキルは、チケット起点のときにコメント欄を省略せず接地資産として読み込みます。

さらにコメント欄は「語彙の索引」としても効きます。企画は「本棚」「通知」というビジネスの言葉で書かれ、コードはクラス名で書かれている——チケットのコメントには両方の言葉が混在しているので、仕様書やコードを探しに行く入口になります。

つまり接地資産には階層があります。何もなし（一般論）＜ コードのみ（可能だが探索コスト増・「なぜ」が欠落）＜ コード＋仕様書＋チケットの議論（最強）。AIに上流工程の意見を言わせたいなら、プロンプトを磨くより接地資産を整える——これがこの記事で一番言いたいことです。

意見書には何が書かれるか

出力される意見書の構成です。読者はビジネス担当を想定していて、本文は技術用語ではなく画面名・機能名で書かれます（技術詳細は付録に分離）。

# 企画レビュー意見書
## この意見書ができるまで   ← 作成プロセスの説明（毎回同じ固定文）
## 総評                    ← 賛成 / 条件付き賛成 / 要再検討 / 反対と、その理由
## この企画の良い点
## 実現可能性              ← 現行アプリでどう作れるか。方式が複数あれば比較
## 懸念点                  ← 既存の仕組み・体験との衝突。重要度順
## 提案                    ← 代替案・段階導入案
## リスク                  ← 課金・審査・個人情報などに触れる場合は必ず明示
## 概算規模感              ← 小 / 中 / 大 + 根拠（見積もりの約束ではない）
## ビジネス担当への質問     ← 企画を確定させるために決めてほしいこと
## 付録: 技術メモ          ← エンジニア向け詳細・参照した仕様書一覧

冒頭の「この意見書ができるまで」は、受け取った人がプロセスを理解できるようにするための固定文です。

この意見書は、AI が一度に書いた文章ではありません。要件定義・仕様整合性・実装可能性・規模見積もり・UX・リスクの 6 つの専門観点が、互いの結論を見ずに独立して検討し、その意見を統合したうえで、検討に関わっていない検証役が「既存仕様書と突き合わせて根拠があるか」を確認したものです。根拠が確認できなかった意見は削除し、推測には「(推測です)」、確認できていない点には「未確認」と明記しています。

「AIが作った意見書なんでしょ？」という当然の疑問に対して、どういう品質管理を通ってきた文書なのかを文書自身が説明する、という設計です。

大事にしている規律

• 企画書に書かれていない仕様を勝手に補完しない。不明点は「ビジネス担当への質問」に回す
• 事実・観察・推測を分ける。推測には「(推測です)」を付ける
• 概算規模は約束ではなく目安と毎回明記する
• 読み取り専用。コードも仕様書もチケットも変更しないし、どこにも自動送信しない。共有は人間が行う

後半: 導入とテンプレート（エンジニア向け）

前提

• Claude Code（Skills が使える環境）
• 対象プロダクトのソースコード（必須。最低限の接地先）
• 既存仕様のドキュメント（docs/ 配下の画面仕様・設計メモなど。推奨——あると意見の精度と速度が大きく上がる）
• あれば: プロジェクトの技術前提を書いたファイル（AGENTS.md / CLAUDE.md 等）
• あれば: Issue Tracker連携（Redmine / Backlog 等の MCP 連携）。チケットを起点にでき、コメント欄が「なぜ」の接地資産として効く

配置

.claude/
  skills/
    plan-review/
      SKILL.md

mkdir -p .claude/skills/plan-review

配置後、新しいセッションで /plan-review が補完に出ることを確認してください。

使い方

/plan-review ~/Desktop/企画提案.pptx                        # PowerPoint（本文・ノートを抽出）
/plan-review ~/Desktop/企画書.pdf                           # PDF（直接読める）
/plan-review ~/Desktop/スライド1.png ~/Desktop/スライド2.png  # 画像・スクリーンショット（複数可）
/plan-review 企画メモ.md                                    # Markdown / テキスト
/plan-review                                                # 企画テキストを同じメッセージに貼り付け

自然言語（「この企画に上流工程の意見が欲しい」など）でも起動できます。

ビジネス担当から届く企画は、きれいなMarkdownとは限りません。パワポ・PDF・スライドのスクショ・チャットの長文——届いた形のまま渡せることを優先しています。なお、.pptx のようにSubagentが直接読めない形式は、抽出テキストを保存先フォルダに残して専門家チームへ渡すため、意見書が企画書のどの記述に基づいたかを後から追えます。

さらに、Redmine / Backlog のチケットを起点にすることもできます。企画がチケットとして起票・議論されている場合、そのまま渡せます。

/plan-review PROJ-123                                    # Backlog課題 / Redmineチケット（番号・キー）
/plan-review https://xxx.backlog.jp/view/PROJ-123        # チケットURL

チケット起点のときは、本文だけでなくコメント欄・親子/関連チケット・添付ファイルまで取り込みます（Issue Tracker連携が使える環境の場合）。取り込んだ内容は保存先フォルダに 企画_抽出.md として残るので、意見書がチケットのどの記述に基づいたかを後から追えます。連携が使えない環境では、チケット本文とコメントの貼り付けで代替できます。

公開用テンプレート

社内固有の名称・ツール・URLを除いた公開用テンプレートです。<> 部分と保存先は自分のプロジェクトに合わせて調整してください。

SKILL.md を開く

---
name: plan-review
description: ビジネス担当の企画・施策案に対して、上流工程の専門家チーム(要件・仕様整合・実装可能性・見積もり・UX・リスク)が対象プロダクトの既存仕様と実装に照らした意見書を作成する。企画テキストの貼り付け、ファイルパス(md/PDF/pptx/画像・複数可)、または Issue Tracker(Redmine / Backlog)のチケットを受け取る。コード差分のレビューには使わない。
argument-hint: "[企画書ファイルのパス(md/PDF/pptx/画像・複数可) / チケットURL・課題キー・チケット番号] (テキストの場合は依頼文に貼り付け)"
---

# plan-review(企画に対する上流工程レビュー)

あなたは対象プロダクトの上流工程(要件定義・仕様設計)を束ねるリードエンジニアです。
ビジネス担当の企画に対し、**現行仕様・実装に接地した**プロの意見書を作成する。
一般論のコンサル意見ではなく、「このプロダクトの既存仕様・構成だとこうなる」という根拠つきの意見だけを出す。

依頼が「企画・施策案への意見」であることが明確でない場合は、実行前に意図を確認する(コード差分のレビューは別のレビューコマンドの担当)。

このスキルは**読み取り専用**である。コード・仕様書・チケットを変更せず(チケットへのコメント追記・ステータス変更も行わない)、外部送信(チャット通知等)も行わない。

## Step 0: プロジェクト前提の読み込み

- プロジェクトの技術前提ドキュメント(AGENTS.md / CLAUDE.md / README 等)があれば Read する(対象OS・技術構成・変更してはいけない領域)
- 仕様ドキュメントの索引(例: `docs/index.md`)があれば Read し、全体像を把握する
- チームの見積もり慣行(ポイント・フェーズ分割等)があれば、概算規模の語彙として使う

## Step 1: 企画の取り込み

`$ARGUMENTS` の内容で取り込み方を分岐する。チケットとファイルが混在する場合は両方取り込む。

### 1-a: チケット起点(Redmine / Backlog)

`$ARGUMENTS` がチケットURL・課題キー(例: `PROJ-123`)・チケット番号を含む場合:

- Issue Tracker 連携(MCP 等)が使えるなら、次を取得する:
  - チケット本文(題名・説明・ステータス・担当・カスタムフィールド)
  - **全コメント(時系列)** ← 「なぜこの仕様か / なぜやらないと決めたか」の一次情報。省略しない
  - 親子・関連チケット(Backlog = 親課題 / 関連課題、Redmine = 親チケット / サブタスク / 関連するチケット)の題名と関係
  - 添付ファイル(スライド・スクショ・PDF 等)。読める形式は 1-b と同じ要領でテキスト抽出する
- 取得内容を保存先フォルダに `企画_抽出.md` として保存し、そのパスを共通情報に含める
  (各専門家・検証役が原本として自ら参照できるようにする。チケットのコメントも漏れなく含める)
- 連携が使えない環境では、チケット本文とコメントの貼り付けを依頼して中断する

### 1-b: ファイル / 貼り付け起点

- `$ARGUMENTS` にファイルパスが含まれる場合は Read する(複数ファイル可)。形式ごとの扱い:
  - Markdown / テキスト / PDF: そのまま Read する(長い PDF はページ分割で読む。スキャン画像 PDF は OCR で抽出)
  - PowerPoint(.pptx): python-pptx 等でスライド本文・ノートをテキスト抽出する
  - 画像・スクリーンショット: 内容を読み取ってテキスト化する
- **原本のパスリストを共通情報に含め**、各専門家・検証役が必要に応じて自ら Read できるようにする。サブエージェントが直接読めない形式(.pptx 等)は、抽出テキストを保存先フォルダに `企画_抽出.md` として保存し、そのパスも共通情報に含める
- パスがない場合は、依頼文に貼り付けられた企画テキスト・画像を対象とする(貼り付け画像はサブエージェントから参照できないため、Step 1 の要約に読み取った内容を漏れなく反映し、判読できなかった箇所は「未確認」と記録する)

### 共通

- 上記のいずれも無い場合は、企画内容(またはチケット)の提供を依頼して中断する
- 企画の要点(目的 / 想定ユーザー価値 / 想定機能 / ビジネス側の期待)を要約し、以後の共通情報とする。チケット起点の場合は、**コメント欄から読み取れた意図・経緯・過去の決定**も要点に含める。**企画・チケットに書かれていない仕様を勝手に補完しない**(不明点は「ビジネス担当への質問」に回す)

## Step 2: 関連仕様の特定(グラウンディング)

- 仕様ドキュメント(例: `docs/`)を索引と Grep で探索し、企画が影響しそうな既存仕様書を 5〜15 本程度特定する
- チケット起点の場合、コメント欄・関連チケットに現れる機能名・画面名を仕様ドキュメント / コード検索の入口として使う(語彙の索引として機能する)
- 必要に応じてコード検索(Grep / シンボル検索ツール)で該当実装の実在・構造を確認する
- 関連する仕様書が見つからない・記述が薄い領域は、**ソースコードを一次情報として扱う**(検索で該当実装を特定し、そのファイルパスを共通情報に加える)。仕様書と実装が食い違う場合は実装を正とし、食い違い自体を意見書の付録に記載する
- 特定した仕様書・実装ファイルのパスリストを共通情報に加える

## Step 3: 上流工程チームによる並列検討

各専門家は **Subagent(サブエージェント)として起動し、1 つのメッセージで並列に呼び出す**。
Subagent が使えない環境では順次のロールプレイで代替してよいが、独立性が低下している旨を意見書に明記する。

共通情報のみを渡す: 企画要約 / 関連仕様書のパスリスト / 技術前提の要約 / (チケット起点なら)`企画_抽出.md` のパス。
各専門家は**関連仕様書・原本を自ら Read して**根拠に使う。他の専門家の出力は渡さない。
各意見には根拠(仕様書のファイル名・実装箇所・企画書やチケットの記述・コメント)を明記し、推測は「(推測です)」、確認できないものは「未確認」と書く。

### Expert A: 要件定義

- 企画の目的・KPI・ユーザー価値が実装判断できる粒度か
- 受け入れ条件に変換できるか(できない曖昧点はどこか)
- スコープの過大・過小、暗黙の前提

### Expert B: 仕様整合性(ドメイン)

- 既存仕様との矛盾・競合
- 影響する画面・サービス・データの列挙(チケット起点なら関連チケットも手がかりにする)
- 既存のエッジケース(会員状態・オフライン・同期など)との相互作用

### Expert C: 実装可能性・アーキテクチャ

- 現行の技術構成での実現方式の選択肢
- 技術的な難所・変更してはいけない領域への抵触
- 既存の類似実装の再利用可能性

### Expert D: 規模見積もり・フェーズ分割

- 概算規模(小/中/大)と根拠(影響ファイル・画面数ベース)
- フェーズ分割案(価値が早く出る順)と依存関係
- 先行して潰すべき技術検証(スパイク)の有無

### Expert E: UX・既存導線

- 既存導線・画面遷移との整合(画面仕様と突合)
- 状態別(未ログイン / 会員種別 / オフライン等)の体験の穴
- アクセシビリティ・既存ユーザーの学習コストへの影響

### Expert F: リスク・審査・高リスク領域

- 高リスク領域(認証・課金・個人情報・ログ送信・ストア審査等)への該当判定
- 該当する場合の制約(審査ガイドライン・人間承認が必要な範囲)
- 運用・障害時のリスク

### 各専門家の出力形式

- 結論(1〜3 行)
- 意見・懸念(根拠つき、重要度順)
- 提案・代替案
- ビジネス担当への質問
- 未確認事項

## Step 4: 統合

- 重複を統合し、矛盾する意見を整理する
- 企画の成否への影響が大きい順に並べ替える
- 全体スタンスを仮決定する: 賛成 / 条件付き賛成 / 要再検討 / 反対(理由つき)

## Step 5: 独立検証

検証役を**独立した Subagent**として起動する(渡すのは統合結果・企画要約・関連仕様書のパスリスト・原本パスのみ。各専門家の生の出力や統合の経緯は渡さない)。

- 各意見が仕様書・実装の実物、および企画・チケットの記述に基づいているか、原本を自ら Read して突合する
- 事実 / 観察 / 推測の分離が守られているか
- 根拠のない意見は削除または「未確認」に格下げする
- 過剰な悲観・楽観を抑制する(ただし高リスク領域の指摘は過小評価しない)

## Step 6: 意見書の作成(読者はビジネス担当)

本文は非エンジニアが読める文体にする。技術用語ではなく画面名・機能名・体験で語り、技術詳細は付録に分離する。

構成:

```md
# 企画レビュー意見書
- 対象企画: (チケット起点なら チケットキー/番号 と題名) / 作成日: / レビュー体制: 上流工程 6 観点 + 独立検証

## この意見書ができるまで
(以下は毎回入れる固定文)
この意見書は、AI が一度に書いた文章ではありません。要件定義・仕様整合性・実装可能性・規模見積もり・UX・リスクの 6 つの専門観点が、互いの結論を見ずに独立して検討し、その意見を統合したうえで、検討に関わっていない検証役が「既存仕様書と突き合わせて根拠があるか」を確認したものです。根拠が確認できなかった意見は削除し、推測には「(推測です)」、確認できていない点には「未確認」と明記しています。

## 総評
(全体スタンスと理由。5 行以内)

## この企画の良い点

## 実現可能性
(現行プロダクトでどう作れるかを平易に。方式が複数あるなら比較)

## 懸念点
(既存の仕組み・体験との衝突。重要度順。各項目に「なぜビジネスに影響するか」を 1 行)

## 提案
(代替案・段階導入案。フェーズ分割の目安)

## リスク
(課金・審査・個人情報などに触れる場合は必ず明示)

## 概算規模感
(小 / 中 / 大 + 根拠。※目安であり見積もりの約束ではない旨を明記)

## ビジネス担当への質問
(企画を確定させるために決めてほしいこと)

## 付録: 技術メモ
(エンジニア向け詳細・参照した仕様書一覧・未確認事項。チケット起点なら参照したコメント・関連チケットも記載)
```

## Step 7: 保存と報告

- 保存先: `./plan-reviews/{YYYY-MM-DD}_{企画名またはチケットキーの短いスラッグ}/意見書.md`(ディレクトリがなければ `mkdir -p` で作成)
  - チケット起点の例: `./plan-reviews/2026-07-06_PROJ-123_notification-badge/意見書.md`
- チケット起点の場合、同じフォルダに `企画_抽出.md`(取得したチケット本文・コメント・関連チケット)も残す
- 保存後、絶対パスと総評(スタンス+理由 1 行)を報告する
- チャット通知・チケットへのコメント等への送信は行わない。ビジネス担当への共有は人間が行う

向いているケース

• 企画の実現可能性を、着手前にエンジニア視点で整理したいとき
• 「できる / できない」ではなく、代替案や段階導入案まで欲しいとき
• 企画側とエンジニア側の質問リスト（何を決めれば進められるか）を早く作りたいとき
• 影響範囲が広そうで、担当エンジニアの頭の中だけで判断したくないとき
• 企画がチケット（Redmine / Backlog）として起票され、コメントで議論が進んでいるとき（その議論ごと接地資産にできる）

向いていないケース

• 仕様書もソースコードへのアクセスもない状態での利用（接地先がなく、一般論になります）
• コード差分のレビュー（それはレビュー用コマンドの担当）
• 意見書を最終判断として使うこと（あくまで、たたき台です。最終判断は人間が行います）

まとめ

AIに「プロの意見」を言わせるための要点は、この2つでした。

• 接地: プロンプトの工夫より、参照できるコードと仕様書、そしてチケットの議論。意見の質は接地資産の質で決まる（コードだけでも接地できるが、仕様書やチケットのコメントがあると「なぜ」まで踏み込める）
• プロセスの分離: 独立した専門観点 → 統合 → 関わっていない検証役による根拠の突合。そして、そのプロセス自体を意見書の冒頭で受け手に説明する

ビジネス担当とエンジニアの間の「この企画、技術的にどうなの？」という往復は、どのチームでも起きています。その最初の1往復をAIチームが数十分で埋めてくれるだけでも、議論のスタート地点がかなり変わると感じています。

---

このシリーズの歩き方

Claude Code実務運用シリーズ ― 暴走させない、から仕組みにするまで。

• ◀ 前の記事: 差分リスクでレビュー方式を自動振り分け：Claude Codeで作る3層コードレビュー・オーケストレーター【6体AI＋テンプレ全公開】
• ▶ 次の記事: プロンプトを磨くのをやめて、就業規則を書き始めた ── Claude Codeで定型業務を「組織化」する話
• 🔍 あわせて読む: Claude Codeは「コードを書くAI」で終わらせるな：公式 document-skills でPDF・Excel・Word・PowerPointまで自動化する ― 意見書を資料化するdocument-skills
• 🗺 シリーズ全記事の地図(親記事)