エ、AI駆動開発ッ？
本記事で使用している「AI駆動開発」という用語について最初に注釈しておきます。
開発手法としてよく知られているSDD、TDD、BDDなどは、「何を起点として開発を進めるか」を示す概念という認識です。一方、「AI駆動開発」は決して「AIを起点に開発を進めている」わけではなく、少なくとも上記の概念に肩を並べるべきではないでしょう。この点について、私もこちらの記事で指摘されている違和感を抱いています。
本記事では、適切な用語が見つからないため、「プロンプト、コンテキスト、ハーネスを適切に制御したAIエージェント」を活用した開発手法という意味で「AI駆動開発」という言葉を使用しています。より適切な用語をご存知でしたらぜひコメントで教えていただければと思います。
はじめに
こんにちは、menu事業部エンジニアの中坪です。
ここ数年のLLMと生成AIツールの進化に伴い、エンジニアにコードをタイプさせるコストは相対的に高くなっています。最近のエンジニアの主な役割は、コードを書くことの代わりに、要件定義や調査・設計、コードレビューやQA検証、AIエージェントやインフラストラクチャの管理などにシフトしているのではないでしょうか。参考数値ではありますが、先月の私のコミットに対するCursorの生成率は83.2%を占めており、今はドキュメントもコードもAIが全て「指示通り」書いてくれる時代です。
しかし、AIは良くも悪くも「指示通り」に書いてしまいます。何を作るのかの認識において、ユビキタス言語レベルで相違があると正確な出力は期待できません。複雑なプロダクト開発においては、ビジネスロジックやドメイン知識が属人化していることも多く、そもそも正確な指示を出せる人は限られているかもしれません。また、AIへの「指示」を、単なるプロンプトという意味だけではなく、AIに渡すツールやデータを含む組織特有のコンテキストや、ガードレールやワークフローといったハーネス的な概念など、「AIの制御に関する全ての情報」に広げて考えてみると、その「指示」を正確に行うハードルはとても高いことに気づきます。
nwiizoさんも2025年、AI時代の要件定義について考えるで「AIが10倍の速度でコードを生成する時代には、要件が間違っていれば間違ったコードも10倍の速度で、10倍の量、生成されてしまいます。」と述べています。つまり、「指示」の品質を高める、特に仕様書や要件定義という上流工程での正確性こそが、AI時代のエンジニアリングにおける最大のボトルネックのひとつになりつつあります。
現在、menuでは社内で横断的にAX（Agentic Transformation）を推進する組織が立ち上がっており、その取り組みの一つとして、開発フロー（要望→要件定義→デザイン→実装→QA）をAIエージェントで一貫して行うプロセスの構築に力を入れています。本記事では、この取り組みの起点となるPMエージェントの開発と、そこから派生する要件定義から実装・QA・デザインまでの一貫したAI活用アプローチについて、SDD×AI駆動開発の観点から紹介します。
SDDとは何か
SDD（Spec-Driven Development）とは、仕様書（Spec）を起点として開発を進める手法です。実装やテストに先立って仕様を定義・合意し、それを単一の正しい情報源として各工程が参照することで、認識のズレを防ぎます。cc-sddなどのツールを使用した開発に限らず、CursorなどのPlanモードを使用した実装開発も、広義的にはSDDであると個人的には考えています。
※cc-sddの詳しい理解についてはこちらの記事を参考にしてください。
cc-sddの課題から見えたPMエージェント開発の必要性
しかし、実際にcc-sddを活用した開発を進める中で、以下のような課題が明確になりました：
1. コーディングエージェントに複数リポジトリを参照させる非効率性
フロントエンド・バックエンド・インフラなど複数のリポジトリにまたがる開発において、コーディングエージェントにそれらを並列参照させることはコンテキストウィンドウの制限やパフォーマンス面において最適解ではないように思えました。
2. spec-initからspec-requirementsまでの過程に再現性がない
cc-sddの/spec-initから/spec-requirementsまでの仕様策定プロセスが属人的で、同じ要望に対して異なる人が作業すると全く異なる仕様になってしまう問題がありました。
3. 組織特有のナレッジを盛り込むことができない
汎用的なコーディングエージェントでは、menu特有のビジネスロジックや過去の設計判断、運用ノウハウなど、ソースコード以外の組織ナレッジを要件定義プロセスに活用することが困難でした。
これらの課題を解決するために、PMエージェントの開発に着手しました。PMエージェントにrequirements.mdを生成させ、デザイン・実装・QAの各工程はすべてこのファイルを起点として動き出す構造にすれば、SDDとAI駆動開発の考え方をそのまま適用できます。マルチリポジトリ横断検索、再現性のある要件定義プロセス、組織ナレッジの活用を実現することで、cc-sddをより実用的で組織適応性の高いものに発展させることを目指しています。
PMエージェントの設計思想
nwiizoさんが指摘する通り、AIが「作る」を高速化すればするほど、最初の「選ぶ」の重みは増します。この意味を抽象的に捉えるならば「コードを書く」ことは「作る」にあたり、「要件定義」は「選ぶ」に相当するでしょう。しかし、「要件定義」のプロセスを具体化すると、それらはさらに細かな「作る」と「選ぶ」の連続であることがわかります。したがって、HITLの思想に基づいて適切なフェーズで人間の承認を挟めば、要件定義においても十分にAIを活用できるはずです。
PMエージェントに期待することは、——曖昧な要望に対するヒアリングと明確化、要件の作成や提案、トレードオフの可視化、既存システムへの影響調査、工数感の見積もり——これらの材料を効率的に揃えて、人間が決断できる状態に変換することです。このアプローチにより、上流工程においてより効果的な意思決定が可能になることと、工数的なボトルネックの解消による開発生産性の向上を期待しています。
また、開発の下流工程で必要となるコンテキストをあらかじめ集約しておくこともPMエージェントに期待する大きな役割です。これまでの開発プロセスにおいては、同じ要件定義で走り出したにもかかわらず、デザイナー、エンジニア、QAが同じコンテキストを共有できていない課題がありました。PMエージェントが起点となり、後戻りしないためにも集約された情報を各工程に提供できるようにする工夫が必要です。
PMエージェントの実装詳細
PMエージェントとは、要望精査や要件定義という組織固有の意思決定の瞬間に介在し、既存のコンテキストから新規の価値を提案できるAIエージェントです。以下の図のように、ma_chanで開発された技術リソースを体系的に統合することで、PMエージェントの開発効率を最大化しています。
マ、ma_chanッ?
このPMエージェント開発は、前回私が記事で紹介したma_chanというマルチエージェントシステムの発展形として進めている文脈があり、今回の記事はその前提知識に部分的に依存しています。前提の全体像や設計の詳細については、ぜひ前回記事**「menuのADK業務活用事例から学ぶ、マルチエージェントシステムの設計と実装」**を一度ご覧いただけると幸いです。
時間がない方へ
ma_chanとは、menuのプロダクト関連の問い合わせ対応を自動化するオーケストレーターです。
- 自律的な調査：Slackメンションをトリガーに、ソースコード解析・ドキュメント検索を実行
- ナレッジ蓄積：調査過程で発見した仕様知識をデータベースに保存
- 再利用可能設計：モジュール化されたエージェントとツール体系
PMエージェント開発では、ma_chanで確立したこれらのモジュール化設計とツール体系を再利用しています。特に以下の技術リソースを活用しています：
- file_search_mcp：MCPを利用した内製のファイル検索システム。マルチリポジトリ環境での効率的な仕様調査に活用
- code_analyzer：コード解析エージェント。既存実装の影響範囲分析に再利用
- knowledge_agent：ma_chanで蓄積した仕様知識を構造化・活用し、PMエージェントの要件定義精度を向上させる基盤
対話ラリーによるヒアリング
PMエージェントは、Claude Codeとの継続的な対話ラリーを通じて要件定義を行います。ユーザーの初期要望を受け取った後、必要な情報が揃うまで段階的にヒアリングを重ね、技術調査をバックグラウンドで並行実行することで、精度の高い要件定義を実現します。Claude Codeを採用した理由は大きく3つあります。
1. Claude Codeそのものがすでに優秀
将来的にはPMエージェントもma_chanのようなオーケストレーターとしてリモートに立ち上げて、エージェント機能の民主化を図ることも検討できますが、プロトタイプでオーケストレーターの開発に工数をかけるよりClaude Codeの自律性や高機能なパッケージを利用するほうが初期フェーズとしては効率的です。
2. 個人に眠る暗黙知の言語化、そして組織知へと移行する第一歩
要件定義に必要なスキルやナレッジの多くが暗黙知として属人化している現状を考慮すると、まずそれらを言語化してもらうことが重要な第一歩と考えました。Claude Codeのローカル実行環境を活用することで、個々の専門家が持つ知見を.claudeに段階的に蓄積し、それを組織全体の共有資産として集約したいという意図があります。
3. 高度な対話能力の活用
Claude Codeの優れた対話能力とスキルやカスタムコマンドを活用して、効率的なヒアリングプロセスを実現しています。特に、選択肢の動的生成機能により、ユーザーが回答しやすい形式で質問を提示したり、文脈に応じて適切な深掘り質問を行うことができます。また、曖昧な回答に対しては具体的な観点を提示して明確化を促すなど、人間の思考プロセスに寄り添った対話設計が可能になります。
マルチリポジトリ横断検索
Claude Codeと既存エージェントシステムの連携により、組織全体のリソースを効率的に活用できる環境を構築しています。file_search_mcpによるマルチリポジトリ横断検索では、フロントエンド・バックエンド・APIドキュメントなど、複数のリポジトリにまたがる仕様やマイクロサービス化された実装を統合的に調査できます。また、MCPツールの使用方法と効果的な検索クエリ生成メソッドをすでに理解しているcode_analyzerを通して分析を行うことで、Claude Codeが事業特有のドメインを理解しやすくなっています。これは、Claude CodeやCodexなどのコーディングエージェントに直接grepなどで大規模ソースコードを検索させる際に生じる、コンテキストウィンドウを逼迫する問題を解決しています。
ナレッジ再利用
knowledge_agentを活用することで、ma_chanが問い合わせ対応で蓄積した「コード由来の仕様知識」を、PMエージェントの要件定義プロセスにフィードバックする仕組みの構築を目指しています。これにより、同じ課題の再発防止や運用実績に基づいた意思決定、社内ナレッジの集約が可能になります。
4つの観点による段階的ヒアリング
PMエージェントは、下流工程での円滑な作業実行を目指し、各専門観点から体系的にヒアリングを実施します。この4つの観点は、menuの開発フローにおいてrequirements.mdを受け取る下流の職種（PdM・デザイナー・エンジニア・QA）に対応しており、各職種が作業を開始するために必要な情報を漏れなく収集することを意図しています。ヒアリングはビジネス観点から順に行い、上流の決定が下流の観点に影響を与える依存関係を考慮した順序設計になっています。
- ビジネス観点：事業背景・機能の目的・課題・成功指標・想定ユーザー・トレードオフの明確化
- デザイン観点：UI/UX要件・既存デザインシステムやブランドガイドラインとの適合性確認
- エンジニア観点：開発要件・既存への影響・変更箇所の洗い出し・運用コストの整理
- QA観点：テストケース作成やリリース判定基準に必要な情報の定義
下流工程への橋渡し
これらの情報を事前に構造化することで、生成されるrequirements.mdが各職種の作業起点として機能します。以下は、PMエージェントが最終的に出力するrequirements.mdテンプレートのサンプルです。
requirements.md テンプレート（クリックで展開）
# Requirements Document
## メタ情報
| 項目 | 内容 |
|------|------|
| 作成日 | {YYYY-MM-DD} |
| 要望概要 | {1行で要望を要約} |
| ステータス | Draft |
---
## 1. ビジネス観点
### 背景・課題
{誰が・何が・どのタイミングで困っているかを事実ベースで記載}
### 目的・ゴール
{この要望が解決されると何が変わるか}
### ステークホルダー
| ロール | 関与 |
|--------|------|
| {役割} | {影響内容} |
### 成功指標（KPI）
- {測定可能な指標}
---
## 2. デザイン観点
### 対象画面・コンポーネント
| 画面名 | 変更内容 |
|--------|----------|
| {画面名} | {変更概要} |
### ユーザーフロー（Before / After）
**Before:**
{現状のフローを箇条書き}
**After:**
{変更後のフローを箇条書き}
### UI 変更点サマリー
{追加・変更・削除される UI 要素を列挙}
### Figma 実装に必要な情報
{Figma でデザインを始めるために必要な情報をまとめる}
※ デザインの詳細は別途 Figma MCP セッションで詰める
---
## 3. エンジニア観点
### 3.1 サーバー
> **要件サマリー:** {サーバー側の変更要件を一言で}
#### 現状のコード分析
{関連する実装の概要。参照ファイルはパス付きで記載}
**参照ファイル:**
- `{ファイルパス}` — {役割}
#### 実装方針（提案）
{採用した実装方針を記載。複数案があった場合は選択理由も添える}
#### 変更箇所
| 対象 | 変更内容 |
|------|----------|
| `{ファイル/API/機能}` | {変更内容} |
### 3.2 フロント
> **要件サマリー:** {フロント側の変更要件を一言で}
#### 現状のコード分析
{関連する実装の概要。参照ファイルはパス付きで記載}
**参照ファイル:**
- `{ファイルパス}` — {役割}
#### 実装方針（提案）
{採用した実装方針を記載。複数案があった場合は選択理由も添える}
#### 変更箇所
| 対象 | 変更内容 |
|------|----------|
| `{ファイル/コンポーネント/画面}` | {変更内容} |
### 3.3 APIドキュメント
> **要件サマリー:** {API仕様の変更要件を一言で}
#### 変更箇所
| 対象 | 変更内容 |
|------|----------|
| `{APIエンドポイント/スキーマ}` | {変更内容} |
### 実装工数
| タスク | SP |
|--------|----|
| {タスク名} | {N} |
| **合計** | **{N} sp** |
---
## 4. QA 観点
### 機能実装の背景サマリー
{QAチームがテストの意図を理解できるよう、ビジネス観点を1〜3文で要約}
### 影響画面一覧
| 画面名 | 変更有無 | 確認優先度 |
|--------|----------|-----------|
| {画面名} | あり / なし | 高 / 中 / 低 |
### テスト観点
- {正常系・異常系・境界値などの主要な観点を箇条書き}
### 受け入れ条件（EARS 形式）
1. WHEN {イベント} THEN {主体} SHALL {応答}
2. IF {前提条件} THEN {主体} SHALL {応答}
🎨 デザイン領域でのAI活用
- Figma MCPによるデザイン生成自動化
- requirements.mdの仕様からUI/UXデザインのプロトタイプを自動生成
🧪 QA領域でのAI活用
- Magic Podを活用したテスト設計とテストの自動化
- requirements.mdのテスト項目からテストケースの自動生成
- UI仕様に基づく自動テストシナリオの作成
⚙️ 開発領域でのAI活用
- SDDとTDDによる実装の効率化
- requirements.mdに基づいて実装とテストを別セッションで行う
このように、requirements.mdを中心としたマルチ方面でのAI活用の起点として機能させることで、開発プロジェクト全体の効率化を目指しています。
プロトタイプ段階での所感
PMエージェントはまだプロトタイプの段階ですが、徐々に以下のような手応えを感じています。
良さそうな点
- エンジニアの工数を使わずに技術的な調査が可能で、影響や工数を考慮した仕様を出力できる。
- 調査した内容をもとにスキルで提案や仮説立てを行うので、抽象度の高い要望を具体化する認知負荷が軽減される。
- 既存のcc-sddコマンドで生成するrequirements.mdより密度の高い情報を出力できている。
- ログを残すことで要件定義の過程をスナップショットとして保存でき、要件定義の仕方や出力そのものを客観的に評価できる。
懸念
- 情報の過不足を判断することが難しく、各方面におけるAI活用で逆にノイズになる可能性がある。
- どれくらいの規模・ストーリーポイントの要望までを仕様に落とし込めるかは未検証。
今後の展望
組織知の集約とエージェント機能の民主化
現在、PMエージェントはClaude Code（ローカル環境）に依存していますが、今後は各個人のローカル環境で蓄積されたスキルやナレッジを組織知として集約し、他業務でエージェント活用を行う際の暗黙知抽出モデルに応用していく予定です。必要に応じてオーケストレーターとしてのPMエージェントをクラウドにデプロイし、ma_chanのようなエージェント機能の民主化を実現していきます。
エージェントのエージェントによるエージェントのためのSSoT
マルチエージェントシステム同士が連携する際の情報源として機能する、マルチエージェントシステムのためのSSoT（Single Source of Truth）を整備していきます。具体的には、knowledge_agentが蓄積するナレッジDBとPMエージェントが生成するrequirements.mdを同一のSSoTに集約し、ma_chanやデータ分析エージェントなど複数のエージェントが共通の情報源を参照できる仕組みを構築します。これにより、エージェント間の情報連携の精度向上と、組織全体での一貫性のある意思決定を支援します。
データ分析エージェントとの連携強化
ビジネス側で実装を進めているデータ分析エージェントの結果をPMエージェントが参照できる仕組みを構築し、「なんとなく必要そうな機能」ではなく「データに裏付けられた必要な機能」の要望精査や要件定義に活用できる体制を目指します。
下流工程での自社製SDDツール開発
下流工程におけるカスタムSDDコマンドや実装スキルを確立し、いわば自社製cc-sddの作成を進めます。PMエージェントは、cc-sddでいうところの/spec-init、/spec-requirementsに相当する機能として、要件定義から実装までのシームレスで一貫性のある連携を目指します。
ナレッジエージェントのデータベース革新
現在のCloud SQLから、Spanner GraphやTemporal Knowledge Graphなど、AIエージェントとより親和性の高いデータ構造を持つシステムへの移行を検討し、ナレッジの管理・検索・活用の精度向上を図ります。
QA自動化との統合
QA側で進めているテスト自動化との連携を深化させ、要件定義からテスト実行まで一貫したAI支援の開発フローを確立します。
おわりに
PMエージェント含め、本記事ではやりたいことや構想を語る部分が多く、技術ブログとしては不確定要素が多くなってしまいましたが、これからAI時代の開発プロセス変革に本気で取り組んでいく決意表明として受け取っていただければ幸いです。
menuでは、AI駆動開発によって「作る」だけでなく「選ぶ」プロセスの質と効率を向上させ、開発サイクルの生産性向上を目指しています。今後もこれらの取り組みを通じて得られた知見を定期的に共有していきたいと思います。最後までお読みいただき、ありがとうございました。
▼新卒エンジニア研修のご紹介
レアゾン・ホールディングスでは、2025年新卒エンジニア研修にて「個のスキル」と「チーム開発力」の両立を重視した育成に取り組みました。 実際の研修の様子や、若手エンジニアの成長ストーリーは以下の記事で詳しくご紹介していますので、ぜひご覧ください！
▼採用情報
レアゾン・ホールディングスは、「世界一の企業へ」というビジョンを掲げ、「新しい"当たり前"を作り続ける」というミッションを推進しています。 現在、エンジニア採用を積極的に行っておりますので、ご興味をお持ちいただけましたら、ぜひ下記リンクからご応募ください。