このスクラップの要約：
1. 要件定義からリリースまでのプロセスをAIで高速化したい。
2. 仕様書作成フェーズでAIを活用すれば、開発・動作チェック役に立つと考える。
3. FigmaやChatGPT、Claude CodeなどのAIツールを課金して、上記の試行錯誤を行う。

スクラップなので、一旦思考を垂れ流しにする。
内容まとまったうえで記事にできそうな場合は記事にする。

目的：
仕様書作成からプロダクトのリリースまでのサイクルを爆速にしたい
自分がコーディングする必要はないが、肌感を掴んで起きたい。（やっぱり自分が作りたい気持ちも正直ある）

早速タイトルから離れそうな話ではあるけれどやりたいことを具体化しよう。

仕様書作成からプロダクトのリリースまでのサイクルを爆速にしたい

下記の一連の流れを爆速にしたい

1. MTG等で出た話をもとに要件を定義する（要件定義書）
2. 要件定義をもとに主要なユースケースを洗い出す。ここまでは基本的にサクッと終わるはず。
3. 主要なユースケース以外も含めて、すべてのユースケースに付いて仕様の詳細を洗い出し仕様書にまとめる。データの整合性やエッジケースの考慮、どのページでどんな変更を加えるかなどを考える。ここがコーディング以外だと一番時間がかかる＆大変。一番手戻りが起こりやすい。仕様書（要求仕様書、機能仕様書、詳細仕様書）を作る。ふと思ったけどここまで全部PdM（PM）ひとりがやるのか...。そりゃボトルネックになりえるわけだ。もっというと、この段階でデザインも入ってくる。デザインを自分で作るか、デザイナーさんにおまかせするかはその時々。自分で作ると考慮漏れが出やすくなる。
4. 開発（設計含む）
5. 動作確認
6. リリース
7. 効果（アウトカム）計測

熱がこもってしまったが3の仕様書に落とし込むことがとてつもなく重い。3をミスったら以降の全てがちゃぶ台返しされる可能性がある。そう考えると3を爆速にするのが、リリースフローにおける一番の重みなのかもしれない。
というか３を爆速かつAIに任せられる形・レベルでアウトプットできるなら、4の開発も必然的に高速になりそう（AIで）。そうすると、5の動作確認でも3の仕様書をもとに自動テストできるようになりそう。

雑にChatGPTに要件定義書のテンプレを作ってもらって、加筆修正した。
MTGの内容（を仮定したもの）をAIに投げて、このテンプレに沿って整理してもらってみよう。

title: 要件定義書
author: # 自動挿入可
date: {@date} # VS Code拡張で自動埋め

📄 プロジェクト要件定義書

1. プロジェクト概要

1.1 背景・目的

• 背景：
• 課題：
• ゴール：

1.2　期待するアウトカム

• 先行評価：
• 遅行評価：

1.3 ステークホルダー

• 関係者：
• 主導者：
• 体制：

1.4 前提・制約

• リソース：
  • 人：
  • 予算：
  • スケジュール：
• 技術制約：
• 法・規制：

2. 機能要件

優先度の分類

MoSCoWの優先度分類を使用します

• Must：必須
• Should：可能な限り実装
• Could：実装できれば良い
• Won't：実装しない

2.1 ユーザー登録（F001）

• 入力項目／出力項目：
• バリデーション：
• 例外処理：
• UI要件（※Mermaid可）：
• 特筆事項：

改訂履歴

基本的にMTGの議事録や、頭の中になんとなくあるイメージからあまり手間をかけずに要件定義書にまとめたい。（脳内メモリが8bitとかなので、吐き出してまとめて1bitのチャンクにしたい）
それ用のプロンプトを作成した。

以下のMTGメモをもとに、下記の要件定義テンプレートに従ってマークダウン形式で記述してください。

出力条件：

• テンプレートの見出し・構成に完全準拠してください
• 表やコードブロック、Mermaid記法を含めてください
• 不明な項目は「未定」や「TBD」と記載してください

プロジェクト要件定義書

title: 要件定義書
author: # 自動挿入可
date: {@date} # VS Code拡張で自動埋め

1. プロジェクト概要

1.1 背景・目的

• 背景：
• 課題：
• ゴール・完了条件：

1.2 期待するアウトカム

• 先行評価：
• 遅行評価：

1.3 ステークホルダー

• 関係者：
• 主導者：
• 体制：

1.4 前提・制約

• リソース：
  • 人：
  • 予算：
  • スケジュール：
• 技術制約：
• 法・規制：

2. 機能要件

優先度の分類

MoSCoWの優先度分類を使用します

• Must：必須
• Should：可能な限り実装
• Could：実装できれば良い
• Won't：実装しない

2.1 ○○機能（任意の1つを詳細化）

• 入力項目／出力項目：
• バリデーション：
• 例外処理：
• UI要件（※Mermaid可）：
• 特筆事項：

改訂履歴

以下がMTGメモです：

（ここにMTGメモを貼ってください）

ひとまず自分の資産を作るためにブログがほしいなぁ。ついでに自由にAIについての試行錯誤をアウトプットできるものがほしいなと思ったので、AIと議論（レスバ）して議事録形式でアウトプット。

📝 要件定義素材：PdM・エンジニア向け個人ブログ設計（UX5段階モデル準拠）

✅ 概要

• AI時代におけるPdMおよびエンジニアとしての知見・実践を発信・蓄積するための個人ブログを設計。
• UXの5段階モデルに基づき、情報構造・体験・発信戦略を整理。
• Zennと自作ブログの併用によって、「拡散と資産化」を両立。

🎯 ブログの目的（戦略段階）

• 実践知の構造化・資産化（テンプレート、設計判断、プロンプトなど）
• PdM視点の「定義力」、エンジニア視点の「技術的背景」を言語化
• 信頼・影響力・思考スタンスの可視化
• 読者が横断的に学べる“知の体系”を提供する

👤 想定読者（ペルソナ）

• PdMを目指す or 若手PdM
• 実務的な設計判断や要件定義に悩むエンジニア
• AIツールや再現可能なワークフローに関心の高い層
• 自分でも手を動かしながら学びたいタイプ

🧱 UX5段階モデルに基づく要件整理

1. 戦略（Strategy）

• 目的：思考と言語化力の資産化と共有
• 差別化：構造・背景・再現性を一貫して記事に含める
• 役割分担：Zenn（拡散）／自作ブログ（体系化）

2. 要件（Scope）

📚 コンテンツ分類

AIに作らせたものをそのまま出力しているので、このまま採用することはない。
ただ、概ね良いと思うので、一旦これで作ってみる。

• product-design/：要件定義・定義力・思考整理
• architecture/：構成設計・選定理由・技術判断
• ai-practice/：ChatGPT, Copilot, Claudeなどの活用記録
• frontend-dev/：Next.js, テスト, UI実装のTips
• templates/：仕様書テンプレ・プロンプト・再利用可能資源
• reflection/：ふりかえり・読書メモ・月次まとめ

⚙️ 機能要件

• カテゴリ＋タグ整理
• タグ/タイトル検索
• コード・図解・テンプレ挿入
• Mermaid.js対応
• RSS・SNS・Zenn連携
• 関連記事推薦
• モバイル・ダークモード対応

3. 構造（Structure）

/
├── home/
├── about/
├── categories/
│ ├── product-design/
│ ├── ai-practice/
│ ├── architecture/
│ └── …
├── tags/
├── articles/
├── templates/
├── blog/zenn-links/
└── contact/

4. 骨格（Skeleton）

トップページ構成

• ヘッダー（ロゴ・カテゴリ・検索）
• ファーストビュー：目的 or 自己紹介
• 新着記事（時系列）
• 注目カテゴリ別記事
• フッター：SNS・GitHub・購読導線

記事ページ構成

• タイトル、投稿日、カテゴリ、タグ
• 本文（コード・図・強調ブロック）
• 関連記事
• Zenn共有・購読ボタン

5. 表層（Surface）

🔗 Zenn連携方針

運用フロー

1. Zennに簡潔に発信（入り口）
2. ブログに構造化記事・テンプレを掲載
3. 相互リンク（Zenn末尾 → ブログ詳細記事）

⸻

🛠 技術スタック候補

AIに作らせたものをそのまま出力しているので、このまま採用することはない。

要素 技術
静的生成 Next.js + MDX / Astro
デプロイ Vercel / Netlify
CMS なし（GitHub管理 or Notion連携）
スタイリング Tailwind CSS
図解 Mermaid.js / Excalidraw
検索 Pagefind / Algolia（任意）

⸻

📝 今後のタスク候補
• 実際のディレクトリ構成と初期ファイル設計
• Next.js / Astro 初期構築セットの作成
• 記事テンプレのZenn／ブログ版両対応化
• 更新の自動化（GitHub Actions or CLI）

⸻

MTG memo:
https://chatgpt.com/share/687ca3c5-f3a8-8012-b1a6-7961a86ba867

プロンプトを使ってMTGの議事録から要件定義書にしたものが以下

プロジェクト要件定義書

title: 要件定義書
author: TBD
date: {@date}

1. プロジェクト概要

1.1 背景・目的

• 背景：AI時代において、PdMおよびエンジニアが持つ実践知を体系的に発信し、知識を資産化する個人ブログが必要とされている。
• 課題：実践的な知見や判断のプロセスが構造的に整理されておらず、散逸・再利用が困難。
• ゴール・完了条件：個人ブログを構築し、Zennとの連携による「拡散と資産化」を両立した状態。

1.2 期待するアウトカム

• 先行評価：記事へのアクセス数、Zennからの流入数、SNSでの共有数
• 遅行評価：ブログ訪問者数の増加、読者の定着率、発信内容の参照・引用率

1.3 ステークホルダー

• 関係者：本人、ブログ読者（若手PdM、エンジニア）
• 主導者：本人
• 体制：個人運営

1.4 前提・制約

• リソース：

  • 人：本人のみ
  • 予算：TBD
  • スケジュール：TBD

• 技術制約：現段階ではなし（Next.js, Mermaid.js）

• 法・規制：著作権、個人情報保護法

1.5 補足情報

• ブログの目的：

  • 実践知の構造化・資産化（テンプレート、設計判断、プロンプト等）
  • PdM視点の「定義力」、エンジニア視点の「技術的背景」を言語化
  • 信頼・影響力・思考スタンスの可視化
  • 読者が横断的に学べる“知の体系”を提供する

• 想定読者（ペルソナ）：

  • PdMを目指す or 若手PdM
  • 実務的な設計判断や要件定義に悩むエンジニア
  • AIツールや再現可能なワークフローに関心の高い層
  • 自分でも手を動かしながら学びたいタイプ

• コンテンツ分類：

  • product-design/：要件定義・定義力・思考整理
  • architecture/：構成設計・選定理由・技術判断
  • ai-practice/：ChatGPT, Copilot, Claudeなどの活用記録
  • frontend-dev/：Next.js, テスト, UI実装のTips
  • templates/：仕様書テンプレ・プロンプト・再利用可能資源
  • reflection/：ふりかえり・読書メモ・月次まとめ

• 構造（Structure）：

/
├── home/
├── about/
├── categories/
│   ├── product-design/
│   ├── ai-practice/
│   ├── architecture/
│   └── …
├── tags/
├── articles/
├── templates/
├── blog/zenn-links/
└── contact/

2. 機能要件

改訂履歴

memo: chatgpt
https://chatgpt.com/share/687ca9a7-a2e8-8012-99fc-e6aced9fd2d2

ここまでが前から整理したいと思ってたことで、ここからが試行錯誤したい部分。
ユースケースの洗い出しと、仕様書への落とし込みをどうAIで爆速にできるか...

と、その前に、ここまでの内容の先行事例とかを調べてみる
自分の場合、一旦手を動かしてみないとヌケモレが出やすいので、未知のものに挑むときはまず考える・てを動かすようにしています。

https://qiita.com/Umeco_co/items/8a434b0e72202d4532ca
今回の話で触れていない、課題の整理の話に付いて触れていた。
完全新規出ない限り、事業においては企業のMVV、経営戦略、事業戦略、プロダクト戦略と前提の話があるので、本当は課題の整理についても考えたほうが良い（が、今回は試したいことの本題ではないので省略）

あとプロダクトの概要とか、前提となるコンテキストの注入は必要。
可能ならプロダクトの全体像を用意して（claude.mdみたいなルール・コンテキストファイルが多分良さそう）、情報を渡せるようにしておくと、仕様書の作成やテスト項目作成の精度が上がりそう。
レビューフローとかにも組み込みやすいし。

冷静になって考えると、要件定義書・仕様書・チェックリストのレビューをAIにやらせるの絶対に用意しなきゃ。AIの得意分野だし。

3〜４（仕様書作成・詳細設計・コーディング・テスト）までの部分Kiroが流行ってそう

• https://zenn.dev/gotalab/articles/3db0621ce3d6d2
• https://zenn.dev/sesere/articles/31d4b460c949e5
• https://zenn.dev/gotalab/articles/3db0621ce3d6d2

あとあれだ、データからの課題分析もAIにやらせたい。
そのためにはどこにどんなデータがあるか、どの数値をどう解釈するかみたいなドキュメントまとめないとだ。

デザインを1から作るのが大変だったので、AIにやらせて見ることにした。

最初Figma Makeで作って見ようと思ったのだけど、まだbeta版だからか（2025/07/21現在）figmaファイルに落とし込んだりできず、使い回しが悪かった。

Figma designのAIでどうにかならないかと思ったけど、画像やテキストの作成・変更ならともかく、デザインを0からは厳しそう。（全然そんなことなかった。後ろのスクラップでfigmaバージョンの記載します。）

ネットサーフィンをした結果Googleが出しているStitchを使ってみた。Stitchは作成したデザインをFigmaへエクスポートすることができる（ファイルとかではなくコピペでFigmaのデザインファイルに移す形）。
複数画面のデザインを一度に作成できることがとても素晴らしい。一つずつ編集もできる。

デザインの作成指示は、作成した要件定義書をそのまま投げただけ。
記事の詳細ページだけ内容が薄すぎたので、「具体例を記載して」と指示を出した。

出来上がったデザインの全体像が以下。細かいところは気になるが、そこら辺は後で手直ししようと思う。
完成度としては60%くらい。

Figmaの階層構造は下記の画像のような感じ。命名は「Depth〜」とUIの意味や粒度は解釈していなさそう。ただ、絶対位置で設定はされておらず、Auto Layoutで配置されているのでコードへの変換とかはできそう。
Figmaやコード的なコンポーネントはどう解釈させようか...。そもそもAIが管理するようになると、コンポーネントの管理とかも不要になったりするのかな。

1画面ずつだが、Figma design内でもFigma AIを使ってデザインを0から作成することができた。

1分くらいでデザインを作ってくれる（gifは4倍速かつ、1フレームに変換したもの）。
何回か作成してみたがデザインの系統が似ていたので、学習データに偏りがあるのだと思う。（なんか海外ECサイトのLPみたいだな、という感じ。）

Figma Design上でStichからインポートしたデザインのフレームの名前の書き換えをFigmaAIでよしなに書き換えることができた（便利）。

一発ではうまくリネームできない場合があるので、2回目で強制的に全ての要素に対してリネームする。

結論として現次点では、Figma上でデザインの作成までAIで行うのは難しい。(2025/07/27現在)

Figma MCPではfigmaのデータを取得できるものの、figmaのデータを編集することはできない。
Figma MakeはUIの生成をFigma designのデータをAIで生成→コードに変換ではなく、最初からコードでUIを自動生成しているようで、Figmaデザインのデータとして保存することができない。
将来的にデザインデータを介さずにUIを編集する可能性はあると思うが、今年中にそんな未来が訪れるとは思わないので結構辛い。
Figma Design上のAIも学習データに偏りがあるのか、生成されるデザインが海外の製品サイトのLPみたいなデザインが生成されてしまい、正直使い勝手が悪かった。すでに作成済みのFigmaのセクションデータや作成済みのサイトのURLを渡しても、同様の状態となった。（読み取っているのかも不明）

そんなこんなで、現時点で自分が最適解だと思うのは次のどちらか。

• StichでUIデザインを作成→Figma デザインに落とし込む。
• Figma Makeでデザインを作成→手元に動くコードとしてデータを落としてhtml.to.designプラグインでfigmaデータに変換→Figma Desingにインポート。

ただ、既存のプロダクトだとトンマナやサイト構造を維持する必要があり、上記方法では0ベースからデザインを作成してしまうので使い物にならない。年内中にFigma AIが内部データをいい感じに参照・編集できるようになることを期待するばかりである...

話の流れが断絶してしまうが、Claude CodeのSub agentsが要件定義書、仕様書、テスト仕様書・シナリオの作成に良さそうなのでメモしておく。（もちろん職場でClaude Codeを使えることが前提になるが）。

何が嬉しいかといえば、MCPみたいに、専用の処理を定義しそれを一種のサンドボックス環境で実行・呼び出しできること。コンテキスト制限、巨大なプロンプトになることによる意図しない挙動を防げるのがでかい。あと並列で動くっぽい。

• Sub agentsを使えば各ドキュメントを作成するときのテンプレやコンテキストを分離できる。
• グローバルと各レポジトリで優先度を変えながら複数のSub agentsを使い分けられる。
• sub agentsを並列で動かせる

https://docs.anthropic.com/en/docs/claude-code/sub-agents

https://zenn.dev/tacoms/articles/552140c84aaefa