発展:提案書から動くPoCを作る

この章でわかること: 基本のハンズオンより一歩進んだ、実務に近い作り方。 既にある提案スライド(PDF)を起点に、プラグインとプロジェクト方針を仕込み、AIに ブレスト → 設計 → 実装まで走らせて、顧客に触ってもらえる PoC(概念実証) を 0→1で立ち上げます。

非エンジニアのあなたがやるのは、実質3つ

細かい技術用語が並びますが、あなたの作業自体はシンプルです。

1. 提案スライド(PDF)を置く → 2. AIにブレスト・設計・実装を頼む → 3. 動いたら触って直す。 技術スタックの用語(この後 CLAUDE.md に出てきます)はAIへの指示書の中身であって、 あなたが理解・暗記する必要はありません。

所要時間・前提・完成度の目安

• 所要時間: 初回は環境構築込みで半日〜1日、慣れれば数時間。トップページの 「その場で」は基本のハンズオンや小さな修正の話で、この0→1のPoCはもう少し腰を据える前提です。
• 前提スキル: コードは書けなくてOK。環境構築が済んでいること。
• 完成度: ゴールは「顧客に触ってもらえる検証版(PoC)」。本番運用の品質とは別物です。

この章の位置づけ

基本のTODOハンズオンが「作って公開する体験」なら、こちらは**「提案業務でそのまま使える段取り」**です。 プラグイン/スキル・複雑な仕様を図で整理する・ 本番を見据えた技術選定で扱った要素が、ここで1本につながります。

Step 1:プラグインを入れる

まず、開発の各フェーズを助けるプラグインを入れます。入れ方の基本は プラグイン/スキルの通り。ここで使う4つのうち3つは Claude公式マーケットプレイス(claude-plugins-official) にあり、これは 最初から使えるので追加は不要です。そのままインストールできます。

用途	プラグイン	役割
開発	feature-dev(Claude公式)	要件洗い出し→設計→実装→レビューのフェーズに沿って開発を進める
デザイン	frontend-design(Claude公式)	“AIっぽくない”洗練されたデザインにする。スキルなのでAIが自己判断で使う
セキュリティ	security-guidance(Claude公式)	生成コードをリアルタイム検査し、脆弱性をその場で修正
ブレスト	superpowers	TDD・デバッグ等をスキル化。今回はブレインストーミングの枠組みとして使う

インストール例(公式マーケットプレイスは最初から使える)

/plugin install feature-dev@claude-plugins-official
/plugin install frontend-design@claude-plugins-official
/plugin install security-guidance@claude-plugins-official

• feature-dev は /feature-dev コマンドが出れば成功。「/feature-dev キャッシュ機能を追加して」のように使います。
• frontend-design はスキルとして働くので、明示指定しなくてもAIが自己判断で使ってくれます。
• superpowers(ブレスト用) はコミュニティ配布です。導入手順は プラグイン/スキルの「マーケットプレイス追加 → インストール」を参照してください。

技術ごとの Skills は今回は省略

Supabase や Next.js の Agent Skills / Plugin もありますが、わざわざ入れるほどでは ないので今回は省きます。Claude Code 自体が相当優秀なので、これで問題ありません。

Step 2:プロジェクト方針(CLAUDE.md)を置く

プロジェクトのルートに CLAUDE.md を置き、技術選定と品質のルールをAIに常時 読ませます。これはデザインシステムの3層でいう 「AI用ルール(文脈)」の層にあたります。狙いは 特定のクラウドに依存しない、引き継ぎ可能で綺麗なコードベースを保つこと。

この例は「AIに渡す設定」——一語一句の理解は不要

下の CLAUDE.md には専門用語(Server Actions、shadcn/ui など)が並びますが、 これはAIに読ませるための設定サンプルです。意味が分からない語があっても問題ありません。 主要な用語は用語集でも引けます。まずは「こういう方針書をAIに持たせる」 という形だけつかんでください。

CLAUDE.md(プロジェクト方針の例)

# プロジェクト方針
Next.js (App Router), Drizzle ORM, Auth.js を使用した、特定のクラウドベンダーに
依存しない高品質な顧客提案用PoC。将来、本番運用のエンジニアへ引き継ぐ際、
Vercel/Supabase や Cloudflare Workers/D1 等のあらゆる環境へシームレスに移行・
スケールできる綺麗で堅牢なコードベース(保守しにくいコードを避ける)を維持すること。

## 採用スタック(インフラ非依存の一例。唯一の正解ではない)
- フロントエンド・UI: Tailwind CSS + shadcn/ui をベースに、モダンなコンポーネント駆動でデザイン。
- データベース(ローカル): `@electric-sql/pglite` を使用し、Docker不要のローカル完結型 Wasm PostgreSQL。
- ORマッパー: `Drizzle ORM`。スキーマは `src/db/schema.ts` に一元管理し、インフラ変更に耐える抽象度を保つ。
- データ取得・操作: API Routes は原則禁止。取得は Server Components の直接フェッチ、
  更新・処理は `Server Actions` 経由で Drizzle から行う。

## 認証・セキュリティ制約(デモ最適化)
- 認証方式: `Auth.js` (NextAuth v5) と `@auth/drizzle-adapter` で Email/Password (Credentials) 認証。
- セキュリティ: パスワードのプレーンテキスト保存は厳禁。必ず `bcrypt` 等でハッシュ化して保存・比較。
- バリデーション: Server Actions の引数やフォーム受け取りには必ず `Zod` を通し、型安全を徹底。
- デモ用UIの工夫: 手入力の手間がない「ワンタップでテストユーザー(管理者/一般)としてログインできるボタン」を用意。

## 開発プロセス(Claude Code への自律命令)
- 事前設計: 実装前に「既存コンポーネントやデータ構造への影響」を思考し、変更予定ファイル一覧と設計思想を提示して承認を得る。
- 品質管理: 書き換え後は自律的に `npm run lint` と型チェックを実行し、エラーや `any` の混入がないことを確認してから完了する。
- コンポーネント分割: 巨大化・密結合を避け、UI表示とビジネスロジックを分離し、再利用可能な小さな単位に分割する。

前の章とつながっている

このスタック(pglite / Drizzle / Auth.js のインフラ非依存構成)は、 ローカル開発環境の作り方と 認証の実装方法を選ぶで解説した方針そのものです。 方針を CLAUDE.md に落とすと、AIが毎回それに沿って作ってくれます。

Step 3:提案書から0→1する

3-1. 提案書(PDF)を docs/ に置く

提案スライドを PDFに変換して docs/ に置きます(パワポも読めますが、Python を かませる必要があるためPDFが手軽)。あわせて CLAUDE.md も置いておきます。

その提案書、AIに渡してよい情報?

提案スライドが**顧客の機密(NDA対象)**を含む場合、AIに読ませてよいかは事前に確認が必要です。 契約・データの保持や学習利用の扱いは利用プランで異なります。判断の勘所は 個人情報・著作権の注意にまとめました。迷ったら、機密部分を外す・ 匿名化するのが安全です。

3-2. superpowers でブレストし、仕様書を作らせる

スライドを読ませ、MVP(必要最小限)の仕様を抽出・整理させます。

プロンプト例(ブレスト → 仕様書 + 設計図)

/superpowers
docs/サンプル提案資料.pdf の提案スライドを読み込んで、このシステムで実装すべき
必須機能を抽出して。その上で、機能要件・仕様についてブレストしたい。本番稼働ではなく、
デリバリー前の提案フェーズで顧客に試しに使ってもらう「動くプロダクト」を作るのが目標。
ブレストが終わったら、仕様をまとめたマークダウンのほかに、
- 画面一覧
- シーケンス図
- アクティビティ図
- ER 図
- コアロジックの解説書
を、Mermaid で図を入れながらそれぞれ別ファイルで生成して。

ブレスト後は docs/仕様書v1.md として保存させます。提案資料に機能一覧まで 書いてあるならブレストは省いてもかまいませんが、提案書から仕様書に起こす手順は 必ず通します。

3-3. コア機能を実装する

0→1の立ち上げは、superpowers の subagent-driven-development が向いています。 複数の設計書を渡すと、内部で複数の子AI(サブエージェント)を立て、「片方はDBスキーマ、 片方は認証画面」と並列で土台(骨組み)を一気に自律生成します。

一方 feature-dev は、既に動いているアプリに「この画面にこのボタンを足す」と いった1機能を綺麗に差し込む差分開発が得意です。役割が違うので使い分けます。

時間がかかる点に注意

subagent-driven-development は「実装→レビュー→修正」を(例えば14タスク分)律儀に 繰り返す構成のため、普通に1時間ほどかかることもあります。ワークショップ等では 1画面だけに絞る、またはレビュー工程をスキップするなどで時間を調整してください。

3-4. 動くものを見ながら修正する

デバッグ段階では、feature-dev は都度時間がかかるので使わず、直接 Claude Code に 指示して手早く直していきます。「指示する→見る→直す」のリズムは 基本ハンズオンと同じです。

設計を確認したい

途中で全体像を把握したくなったら、設計書を出力させるのが有効です。分けて 出させると読みやすくなります。

プロンプト例(設計書の出力)

分けて確認したいので、以下の設計書を出力してください。
- 画面一覧
- シーケンス図
- アクティビティ図
- ER 図
- コアロジックの解説書(Mermaid で状態遷移やフローをわかりやすく)

Mermaid はこのサイトでも使っています。図での整理の考え方は 複雑な仕様を図で整理するを参照してください。

なぜ大事か

提案業務では、「スライドの構想」と「動くもの」の間の距離が、そのまま商談の スピードを決めます。プラグインで段取りを借り、CLAUDE.md で技術方針を固定し、 AIにブレスト→設計→実装を走らせる——この型を持っておくと、提案資料から 数時間で触れるPoCへ、という筋道が現実になります。仕上げの前に 生成物の見分け方とセキュリティの チェックも忘れずに。

参考リンク(情報ソース)

• Claude Code プラグイン: https://code.claude.com
• superpowers: https://github.com/obra/superpowers-marketplace
• PGlite: https://pglite.dev
• Drizzle ORM: https://orm.drizzle.team
• Auth.js: https://authjs.dev