Claude起点の仕様駆動開発

DevelopersIO 2026 Osaka（2026.09.29）Session-A203 の登壇資料です。

Claude Desktop を起点に Google Stitch・Pencil.dev・Claude Code を MCP で繋いで、
「デザインを仕様書として扱う」プロダクト開発に挑戦した記録。
うまくいったところより、躓いたところを多めに話しています。

Transcript

1. OSAKA Aトラック Session-A203 Claude起点の仕様駆動開発 産業⽀援グループ製造ビジネステクノロジー部 ⽥中 聖也
2. ⾃⼰紹介 • 2017.04~2021.07 • • 部署 ◦ • 名前 ◦ • ⽥中聖也 好きな⾔葉 ◦ • 製造ビジネステクノロジー部 現場‧現物‧現実 職種 製造業の⽣産技術部 ◦ 設備の保全全般(事後,予防,予知) ◦ IATF16949取得に向けた取り組み 2021.08~2025.01 SES ◦ AI, OCRを活⽤した製造業向けの業務アプリ ◦ AWSを活⽤したWebシステム • 2025.02~ クラスメソッド⼊社 ◦ メーカー様 担当 ▪ 製品の需要予測PoC ▪ 原材料管理 業務改善 ▪ ⽣成AIを活⽤した⽣産設備の予知保全 ◦ ソフトウェアエンジニア 2
3. ⽬次 • 背景&注意点 • 去年、良かったこと / しんどかったこと • 今年の挑戦内容 • 躓いたところ • 今後の展望 3
4. 背景&注意点
5. 背景&注意点 DevelopersIO 2025 Osaka で「⽣成AIを上流⼯程で使い倒す」で登壇 • 結論：「AIが読み取れる情報を、AIが理解しやすい形でたくさん残しておこう」 • Vercel v0とグループウェア(Google Workspace)フル活⽤で上流⼯程を短縮 • Cursorで⾼速開発 今年は、その発展形 • ⼈間がドキュメントもコードも⼀切書かずに、プロダクト開発ができないか？ • 上流の成果物と、実際に動くコードを、最初から地続きにできないか？ 今年の挑戦も道半ばで具体的な成果は出ていません。 あくまで「こんなことできるんだ」ぐらいの気持ちで聞いてください 5
6. 去年、良かったこと / しんどかったこと
7. 去年、良かったこと / しんどかったこと Cursor GitHub 開発 issue管理 Vercel v0 Google Workspace デモアプリ 7 上流⼯程 Vercel v0でアプリの画⾯構成 をエンドユーザーと⼀緒に開 発。 グループウェアをフル活⽤し て仕様、設計⼯程を短縮。 ドキュメント管理 開発⼯程 Gemini Notebook 旧:NotebookLM エンドユーザー 開発者 Gemini Gem 機能要件、⾮機能要件整理 優秀なチームメンバーに開発 の基礎部分を作ってもらって Cursorで⾼速開発。
8. 去年、良かったこと / しんどかったこと 良かったこと • • • 8 しんどかったこと 上流⼯程の時間は、本当に圧縮できた。 エンドユーザーと⼀緒に画⾯を作る体験が、とにかく 良かった。 ◦ 「この⼈がどういう業務でアプリを使いたいか」 が、そのまま画⾯に出てくる 開発⼯程でもAIエディタを使って⾼速に開発できた。 • • • デザイン(Vercel v0)と開発しているソースコードが⼀致 しない。 ◦ ⼩さい修正にデザインが追いつかない ◦ 特にデザイン側の更新が追いつかない 仕様書はさらに追いつかない 結局、どれが最新の仕様なのか分からなくなる ドキュメント‧デザイン‧ソースコードが⼀致しない ⾃分でもどれが正しいのか分からなくなる • 3つの成果物を⼈⼒で同期させるコストがAI駆動開発で浮いた時間を完璧に⾷いつ ぶしてしまう。
9. 今年の挑戦内容
10. 今年の挑戦内容 10 • デザインが仕様書として機能を果たし⾼速にプロダクト開発を⾏う • ⼈がドキュメントやソースコードを書かない ①AIが活躍できる場が整った • 去年までは情報を⼈が繋いでいた ◦ AIで⾼速に成果物ができても、AI↔ツール、 ツール↔ツールの情報の受け渡しを⼈間が やっていてボトルネックであった。 • エージェント、MCP、Skillがでてきた ◦ AIが⾃律的に必要な⼿順やツールを操作でき る技術がそろった。 • Claude Enterpriseが導⼊された ◦ ◦ プロジェクト機能により、仕様‧意思決定な どがチーム全員で参照できる。 MCP, Skillをプロジェクト内で共有できる。 ②ドメインスペシャリスト(調達)の⼊社 • ⻑年、製造業で働いてきた⾮エンジニアが ⼊社 ◦ ◦ その⼈が「こういうものがあった⽅がいい」 と⾔うアプリには、明確なニーズがあった。 ドメイン知識の解像度が、私とは⽐べものに ならない • 去年の⽅法では⾼速なプロダクト開発は難 しい ◦ ◦ 聞き出して → 私が仕様書に落として → 実装 する、では絶対に追いつかない。 仕様書を起点にすると、「⼀致しない3つ」 となり去年と同じ失敗をする
11. 全体構成 Google Stitch 11 Google Workspace Pencil.dev MCP GitHub Claude Code Claude Desktop プロダクトオーナー 開発者
12. 今年の挑戦内容 12 ツール ⽬的 触る⼈ Claude Desktop 職種を問わずMCPの起点 Skillをプロジェクトで配る 全員 Google Workspace 打合せメモや意思決定の証跡 全員 Google Stitch プロダクトの画⾯構成を決める(仕様) プロダクトオーナー Pencil.dev 画⾯構成から詳細デザインを決める デザイナー Claude Code MCPを束ねて実際に実装する エンジニア GitHub Issue管理とCI/CDの起点 エンジニア ツール間の情報の受け渡しはClaude DesktopからMCP連携で実施 微修正は実際に⼈間がツールを操作する。
13. Claude Desktop • • • • 全員が触る 職種を問わず、ここがMCPの⼊⼝。 ◦ プロダクトオーナーもエンジニアも、まずClaudeに話しかける Claude Project が、チームの記憶になる ◦ 仕様の議論‧意思決定‧フィードバックを全部ここに残す プロジェクト内で決まった画⾯以外の仕様(⾮機能要件)とかはGoogle DocumentにMCP経由でまとめる Skillをプロジェクト単位で配る 13
14. Google Stitch プロダクトオーナーが触る 14 • Google Stitch とは？ ◦ テキストの指⽰（プロンプト）や参考画像をもとに、WebやモバイルアプリのUIデ ザインとフロントエンドコードを数分で⾃動⽣成するGoogleの実験的なAIツール ⽐較項⽬ Google Stitch Vercel v0 主な役割 UIデザイン‧モックアップ作成 フルスタックWebアプリ開発 得意なユーザー層 ⾮エンジニア、プランナー、デザイナー エンジニア、Web開発者 デザインの柔軟性 ⾮常に⾼い（⾃由なレイアウト、Figma 連携） ⾼い（実⽤的なコンポーネント中⼼） バックエンド連携 なし（Google AI Studio等との⼿動連携が あり（SupabaseやAWS等との統合が可能） 必要） 料⾦プラン 基本無料 無料枠あり / 有料プラン⽉額$20〜
15. Google Stitch プロダクトオーナーが触る 15
16. Pencil.dev デザイナーが触る 16 • Pnecil.devとは？ ◦ VS CodeやCursorなどのIDE（統合開発環境）やローカル環境に統合して動作する、 AIファーストの次世代ベクターデザイン‧Generative UIプラットフォーム ◦ Figmaみたいなもの ◦ ⾃律型AIエージェントと深く統合されており、キャンバス上でプロンプト（Cmd+K など）を使ってUIを⽣成‧修正可能 ◦ Pnecil.dev⾃体は無料で使⽤可能。すでに使⽤しているClaude Code、ChatGPT、 Geminiなどの⽣成AIツールと連携できる。
17. Pencil.dev デザイナーが触る 17
18. 全体構成 Google Stitch 18 Google Workspace Pencil.dev MCP GitHub Claude Code Claude Desktop プロダクトオーナー エンジニア
19. Stitchから直接Claude Codeを連携させていない理由 Google Stitch Pencil.dev 19 Claude Code • デザイナーが操作するツール ◦ プロジェクトが育ったときに、デザイナーが⼊る余地を残しておきたい ◦ Claude Code が読める形のデザインデータにしておきたい • Stitch は「画⾯構成 ＝ 仕様」を決める場所 ◦ ⾒た⽬を詰める場所ではない、と役割をはっきり分けた ◦ プロダクトオーナーが細かな⾒た⽬で悩み始めるポイントをなくすため
20. 躓いたところ
21. 躓いたところ 1. Windows特有の問題で環境構築に時間がかかった 2. ツールの変化が早すぎる 3. ツール間連携にトークンを過剰に消費する 4. ドメイン知識の差を埋めるのに時間がかかる 21
22. Windows特有の問題で環境構築に時間がかかった • 公式のStitch MCPがWindowsで動作しない • ⾊々と調査するとstitch-mcp の stdio 実装バグっぽいこ とが分かった 22 Google Stitch Stitch MCP いったん、⾃作プロキシで動くようにした。 Claude Desktop Windows版
23. ツールの変化が早すぎる • Google Stitch の UI と操作⽅法が、わりと頻繁に変化する。 ◦ 使い⽅が慣れ始めたぐらいで変化 • Google Stuich、Pencil.devの開発が想像以上にスピーディだった ◦ ベータ版は無料である⼀⽅、UIの使い勝⼿が変化することを前提として織り込む べきだった 23
24. ツール間連携にトークンを過剰に消費する 24 • Google Stitch → Pencil.dev へ MCP での連携 ◦ ⼀番最初に落とし込む情報量が、そもそも多すぎる ◦ 膨⼤なトークンを使ってしまう ◦ 処理も⻑いし、反映されるまでも⻑い • 「全部まとめて持っていく」が重い Google Stitch Pencil.dev 画⾯⼀覧取得 画⾯作成 MCP Claude Desktop Windows版
25. ドメイン知識の差を埋めるのに時間がかかる 25 • ⼈間同⼠のやり取りが⼀番ボトルネック ◦ プロダクトオーナーは経験からユーザー視点でプロダクトを作る ◦ エンジニアは技術視点でプロダクトを作る ◦ 仕様はすぐに出てくるのに、その画⾯が必要な理由の合意に時間がかかる この機能は必要です。 なぜなら実業務では‧‧‧ プロダクトオーナー この機能って必要なんですか？ 技術的に‧‧‧ エンジニア
26. 成果として使えそうな経験
27. 成果として使えそうな経験 • プロダクトオーナーが、⾃分で画⾯を作ること ◦ デモアプリでも何でも、動くものがあった⽅が議論が活発になり、何を作りたい かのが具体的分かる ◦ 仕様を聞き出して→エンジニアが作るというやり⽅より遥かに早い ◦ 対顧客のプロダクト開発でも利⽤できそう • 役割ごとに触るツールを分けること ◦ ◦ ◦ ◦ プロダクトオーナー → Google Stitch デザイナー → Pencil.dev エンジニア → Claude Code ツールが変わってもプロダクト開発はできる • MCP連携はすんごい ◦ ツール通しの情報のやり取りが⾮常に簡単になった 27
28. まとめ
29. まとめ • • • • 29 仕様書を書くのをやめて、デモアプリを仕様とした Claude Desktopを中⼼にMCP連携でツール同⼠の情報のやり取りを実施 AIは「何を作るか」を速くする。「なぜ作るか」は速くしない 対顧客のプロダクト開発でも利⽤できそう Google Stitch Google Workspace Pencil.dev MCP GitHub Claude Code Claude Desktop プロダクトオーナー エンジニア