【登壇資料】「Claude起点の仕様駆動開発」というタイトルでDevelopersIO 2026 Osakaに登壇しました #devio2026
概要
こんにちは、クラスメソッド製造ビジネステクノロジー部の田中聖也です。
2026年9月29日(火)にクラスメソッド大阪オフィスで開催されたDevelopersIO 2026 Osaka Day2にて、Session-A203「Claude起点の仕様駆動開発」というタイトルで登壇してきました！
去年の登壇の発展形として、人間がドキュメントもソースコードも一切書かずにプロダクト開発ができないか、上流の成果物と実際に動くコードを最初から地続きにできないか、という挑戦の途中経過をお話ししました。
先にお伝えしておくと、今年の挑戦も道半ばで、具体的な成果はまだ出ていません。正直なところ「こんなことができるんだ」「ここで転ぶんだ」くらいの温度感で読んでいただけると嬉しいです。
登壇資料
去年、良かったこと / しんどかったこと
去年のDevelopersIO 2025 Osakaでは「生成AIを上流工程で使い倒す」というタイトルで登壇しました。結論は「AIが読み取れる情報を、AIが理解しやすい形でたくさん残しておこう」です。
具体的には、Vercel v0とGoogle Workspaceをフル活用して上流工程を短縮し、Cursorで高速に開発するという進め方をしていました。
去年の記事はこちら
去年の挑戦でよかったこと
- 上流工程の時間は、本当に圧縮できた
- エンドユーザーと一緒に画面を作る体験が、とにかく良かった
- 「この人がどういう業務でアプリを使いたいか」が、そのまま画面に出てくる
- 開発工程でもAIエディタを使って高速に開発できた
特に2つ目が大きかったですね。画面を一緒に触りながら話すと、業務の実態がそのまま仕様として立ち上がってきます。
一方で、しんどかったこと
- デザイン(Vercel v0)と、開発しているソースコードが一致しない
- 小さい修正にデザインの更新が追いつかない
- 仕様書はさらに追いつかない
- 結局、どれが最新の仕様なのか自分でも分からなくなる
ドキュメント・デザイン・ソースコードという3つの成果物を人力で同期させるコストが、AI駆動開発で浮いた時間を完璧に食いつぶしてしまいました。
今年の挑戦：デザインに仕様書の役割を持たせる
そこで今年は、デザインが仕様書としての機能を果たす形にして、人がドキュメントやソースコードを書かないプロダクト開発ができないかを試してみました。
挑戦しようと思えた理由は2つあります。
1: AIが活躍できる場が整ったこと
去年までは、AIで高速に成果物ができても、AIとツールの間、ツールとツールの間の情報の受け渡しを人間がやっていて、そこがボトルネックでした。エージェント、MCP(Model Context Protocol、AIと外部ツールを共通の作法で繋ぐための規格)、Skill(Claudeに手順書を持たせる仕組み)が揃ったことで、AIが自律的に必要な手順やツールを操作できるようになりました。
加えてClaude Enterpriseが社内に導入され、プロジェクト機能で仕様・意思決定をチーム全員が参照できるようになったのも大きいですね。MCPやSkillをプロジェクト内で共有できます。
2: ドメインスペシャリストの入社
今年の2月に、長年製造業で働いてきた非エンジニアのメンバーが入社しました。調達領域のドメイン知識の解像度が私とは比べものにならず、その人が「こういうものがあった方がいい」と言うアプリには明確なニーズがありました。
ただ、聞き出して → 私が仕様書に落として → 実装する、という去年のやり方では絶対に追いつきません。かといって仕様書を起点にすると、また「一致しない3つ」が生まれて去年と同じ失敗をします。
全体構成とツールの役割分担
今年組んだ構成はこちらです↓
| ツール | 目的 | 触る人 |
|---|---|---|
| Claude Desktop | 職種を問わずMCPの起点。Skillをプロジェクトで配る | 全員 |
| Google Workspace | 打合せメモや意思決定の証跡 | 全員 |
| Google Stitch | プロダクトの画面構成を決める(仕様) | プロダクトオーナー |
| Pencil.dev | 画面構成から詳細デザインを決める | デザイナー |
| Claude Code | MCPを束ねて実際に実装する | エンジニア |
| GitHub | Issue管理とCI/CD(検証とデプロイの自動化)の起点 | エンジニア |
ツール間の情報の受け渡しは、すべてClaude DesktopからのMCP連携で実施します。微修正は人間が直接ツールを操作する、という切り分けにしました。
Claude Desktop：全員が触る
職種を問わず、ここがMCPの入口です。プロダクトオーナー(作りたいものの中身に責任を持つ人)もエンジニアも、まずClaudeに話しかけます。
そしてClaude Projectがチームの記憶になります。仕様の議論・意思決定・フィードバックを全部ここに残し、画面以外の仕様(非機能要件)はMCP経由でGoogle Documentにまとめる形にしました。Skillもプロジェクト単位で配れるので、全員が同じ手順を踏めるのが良いですね。
Google Stitch：プロダクトオーナーが触る
Google Stitchは、テキストの指示(プロンプト)や参考画像をもとに、WebやモバイルアプリのUIデザインとフロントエンドコードを数分で自動生成するGoogleの実験的なAIツールです。
去年使っていたVercel v0との違いはこんな感じ↓
| 比較項目 | Google Stitch | Vercel v0 |
|---|---|---|
| 主な役割 | UIデザイン・モックアップ作成 | フルスタックWebアプリ開発 |
| 得意なユーザー層 | 非エンジニア、プランナー、デザイナー | エンジニア、Web開発者 |
| デザインの柔軟性 | 非常に高い(自由なレイアウト、Figma連携) | 高い(実用的なコンポーネント中心) |
| バックエンド連携 | なし(Google AI Studio等との手動連携が必要) | あり(SupabaseやAWS等との統合が可能) |
| 料金プラン | 基本無料 | 無料枠あり / 有料プラン月額$20〜 |
※2026年9月時点の情報です。
Pencil.dev：デザイナーが触る
Pencil.devは、VS CodeやCursorなどのIDE(統合開発環境)やローカル環境に統合して動作する、AIファーストのベクターデザイン・Generative UIプラットフォームです。ざっくり言うとFigmaみたいなものですね。
自律型AIエージェントと深く統合されていて、キャンバス上でプロンプト(Cmd+Kなど)を使ってUIを生成・修正できます。Pencil.dev自体は無料で使用でき、すでに使っているClaude CodeやChatGPT、Geminiなどと連携できます。
Stitchから直接Claude Codeを繋がなかった理由
StitchからそのままClaude Codeに繋げば工程は1つ減ります。それでも間にPencil.devを挟んだ理由は3つあります。
- プロジェクトが育ったときに、デザイナーが入る余地を残しておきたかった
- Claude Codeが読める形のデザインデータにしておきたかった
- Stitchは「画面構成 ＝ 仕様」を決める場所で、見た目を詰める場所ではない、と役割をはっきり分けたかった
補足説明：躓いたところ
登壇では、うまくいかなかったところを中心にお話ししました。大きく4つです。
1: Windows特有の問題で環境構築に時間がかかった
公式のStitch MCPがWindowsで動作しませんでした。色々と調査すると、stitch-mcpのstdio(標準入出力を使ったプロセス間のやり取り)実装のバグっぽいことが分かり、いったん自作プロキシを挟んで動くようにしています。
本題に入る前のここで結構な時間を持っていかれました。
2: ツールの変化が早すぎる
Google StitchのUIと操作方法が、わりと頻繁に変化します。使い方に慣れ始めたくらいでまた変わる、という感じでした。
Google StitchもPencil.devも開発スピードが想像以上に速いです。ベータ版は無料である一方で、UIの使い勝手が変わることを前提として織り込んでおくべきでしたね。
3: ツール間連携にトークンを過剰に消費する
Google Stitch → Pencil.dev へのMCP連携で、一番最初に落とし込む情報量がそもそも多すぎました。画面一覧を取得して画面を作成する、という最初の一歩で膨大なトークンを使ってしまい、処理も長いし反映されるまでも長い。
「全部まとめて持っていく」が重い、というのが率直な感想です。ここは分割して渡す設計にすべきでした。
4: ドメイン知識の差を埋めるのに時間がかかる
結局、人間同士のやり取りが一番のボトルネックでした。
プロダクトオーナーは経験からユーザー視点でプロダクトを作り、エンジニアは技術視点でプロダクトを作ります。仕様自体はすぐ出てくるのに、その画面がなぜ必要なのかの合意に時間がかかる。「この機能って必要なんですか？」「実業務ではこうだから必要です」のやり取りが、最初の一歩を一番重くしていました。
成果として使えそうな経験
うまくいかなかった一方で、持って帰れたものもあります。
- プロダクトオーナーが自分で画面を作ること。デモアプリでも何でも、動くものがあった方が議論が活発になり、何を作りたいのかが具体的に分かります。仕様を聞き出してエンジニアが作るより遥かに速いですね
- 役割ごとに触るツールを分けること。プロダクトオーナーはGoogle Stitch、デザイナーはPencil.dev、エンジニアはClaude Code。この切り分けができていれば、ツールが変わってもプロダクト開発は回せます
- MCP連携はすんごいです。ツール同士の情報のやり取りが圧倒的に簡単になりました
まとめ
仕様書を書くのをやめてデモアプリを仕様とし、Claude Desktopを起点にMCPでツールを繋ぐ構成を試してみました。
道半ばではありますが、役割ごとにツールを分ける設計と、人間同士の合意形成が残り続けるという学びは、対顧客のプロダクト開発でもそのまま使えそうだと感じています!!
