Personal · AI SaaS · 2025–Now

SpecPilot

議事録から、設計書と実装のたたき台へ。

受託開発の上流工程、要件整理〜基本設計を AI で支援する SaaS。打ち合わせの議事録から、仕様の不足や未決事項を整理し、設計書や実装のたたき台までつなげる AI 支援ツールを作っています。

specpilot.flow
議事録input.mdExtractorClaudeQuestionGPT-4oDesignerClaudeVibe Packoutput
● running4 agents · trace_id 9f2…
questions
14
spec coverage
86%
Stack
Next.jsTypeScriptHonotRPCPrismaPostgreSQLMastraClaude APIGPT-4oGeminiStripeDocker
Role / Scope
  • 企画から実装まで一人で担当
  • ターゲット顧客設計
  • GTM 設計
  • 課金モデル設計 / LTV 試算
  • AI Agent パイプライン設計
  • Extractor / Question / Designer / Linter の Agent 構成
  • Claude / GPT-4o / Gemini を用途別に使い分け
  • ドキュメント駆動開発 / 意思決定ログ
Challenge

「打ち合わせした議事録を、そのまま設計と vibe pack に落とせる」体験を一人で作りきりたかった。ただ LLM の出力は揺れるし、ハルシネートもする。そのまま使うと信用できないし、人間が直しすぎると AI を入れた意味がない。このバランスをどう取るかが、結局このプロダクトの肝になった。

Design Decisions
01

Agent を役割で分ける

1 Agent に「議事録読んで設計書出して」と全部任せると、出力が悪かったときに何が悪かったのか分からなくなる。Extractor(抽出)・Question(未決抽出)・Designer(設計化)・Linter(検証)の 4 段に分けて、各段で出力をその場で検証できる構成にした。

02

モデル使い分け

抽出は Claude、探索は GPT-4o、長文整理は Gemini。性能特性とコストが用途で違うので役割ごとに替える。Agent 抽象側でモデルとプロンプトを差し替えられるようにしておくと、新しいモデルが出たときに数行で乗せ替えられる。

03

人間のレビュー導線

AI が直接ファイルを書き換える形は採らず、出力は必ず「決定事項カード」越しに人間が確定 / 仮置きするフローに通す。後戻りを優先する設計。スピードは少し落ちるが、信頼できないものに信頼を貸す導線は引かない。

04

ドキュメント駆動

意思決定ログ(D-XXXX)と ADR を最初から書く。これは人間用というより Agent 用で、過去の判断を踏まえた出力を期待するためのコンテキストとして毎回渡す。書き続けるコストはあるが、Agent の出力品質に直接効く投資。

Deep dive · System Design

会議から、動く初期状態へ。

SpecPilot は単一の LLM 呼び出しではなく、役割で分割した複数の Agent と 人間との収束ループで成り立っています。以下、プロダクトの位置づけ → Agent パイプライン → 出力構造の順で。

§ APositioning

会議 → SpecPilot → vibe pack → 実装。

既存の AI 開発ツールに乗せるのではなく、その前段の『要件を確定させる工程』そのものを担う。

顧客との会議
議事録
SpecPilot
質問 → 収束 → 設計
vibe pack
Core / Archetype / Dynamic
25+ AI dev tools
Claude Code · Cursor · Kiro …
実装
動く初期状態
SpecPilot質問ユーザー回答SpecPilot(収束まで)
01
質問で収束させる
未決・矛盾・不足を会話で解消する
02
vibe pack を生成する
動く初期状態までの距離を最短化する
§ BAgent Pipeline

11 段の Agent + 人間の収束ループ。

抽出 → 質問 → 収束 → 確認 → 設計 → 仕様 → リント。各段は独立した Agent として差し替え可能。Phase 2 で Estimator を追加。

01
議事録 (input)
input.md
02
Extractor Agent
要件候補 · 確定 · 未決を抽出
03
Question Agent
質問生成 + 拡張カタログ判定
04
ユーザー回答
interactive · 収束まで反復
05
収束判定
Blocker / Major = 0 · Archetype 必須 = 100%
06
確認フェーズ
AI 理解のすり合わせ · ユーザー承認
07
Designer Agent
docs/prd · design · decisions
08
Spec Agent
openapi · prisma · sql · rbac
09
Linter Agent
整合チェック · 3レイヤー完全性
10
AGENTS.md 再生成 + tasks.md
vibe pack assembly
11
vibe pack 出力
Claude Code / Cursor / Kiro 等 25+ ツール
Phase 2Estimator Agentestimate.md (工数見積もり) · Linter → AGENTS.md 間に接続
§ COutput · vibe pack

Core / Archetype / Dynamic の 3 層構造。

出力ドキュメントを役割で分割。Core は欠けたら Linter Error、Archetype は Warning、Dynamic は収束過程で動的に積み上がる。

vibe pack
01

Core

欠落 = Linter Error
01AGENTS.md
02tasks.md
03docs/prd/overview.md
04docs/prd/requirements.md
05docs/prd/scope.md
06docs/decisions/log.md
02

Archetype

欠落 = Linter Warning
01docs/prd/non-functional.md
02docs/detail/ui.md
03docs/design/architecture.md
04docs/design/api-design.md
05docs/design/ui-guidelines.md
06docs/design/design-system.md
07docs/diagrams/er.mmd
08docs/diagrams/screen-flow.mmd
09docs/specs/openapi.yaml
10docs/specs/schema.prisma
11docs/specs/schema.sql
12docs/specs/rbac.yaml
13docs/estimate.md(任意 · Phase 2)
03

Dynamic

収束ループ中に動的追加
01docs/diagrams/*.mmd(ステータス遷移 · API フロー等)
02docs/specs/design-tokens.json(Phase 2)
03拡張カタログ発動による追加(対象外は decisions/log.md に根拠記録)