AIに設計を書かせるだけで「理解負債」と「実装漏れ」が激減した話【フロントエンド編】

Transcript

1. AIに設計を書かせるだけで、理解 負債と実装漏れが激減した話 【フロントエンド編】 PeopleX / 芹澤和也
2. ⾃⼰紹介 株式会社 PeopleX PeopleX AI⾯接 エンジニア Goodpatchをはじめ複数のスタートアップ企業でモバイルアプリや SaaSプロダクトの開発に従事。 2024年よりPeopleXでAIプロダク トのフロントエンド。 © PeopleX Inc. 芹澤 和也 KAZUYA SERIZAWA ❤ ランチ、ボードゲーム、お喋り @seriseri_55 2
3. PeopleX AI⾯接 24時間365⽇対応の労働⼒ 柔軟な対話AIが⼈に代わり業務 個社に合わせた業務設定 ・24時間365日対応可能な労働力 ・夜間、土日での対応可能 ・マネジメント不要 ・全て録画と文字起こしで事後確認可 ・営業、接客など顧客接点の職種も可 ・24時間365日で顧客対応でリード、商談対応 ・グローバル対応可能（多言語対応） ・受付、接客など会社の顔として振る舞い ・個社の需要に沿った質問カスタマイズ ・複数のAIワーカーを簡単に作成可 3
4. © PeopleX Inc. 4 先⽇zennでこんな記事を書きました...
5. © PeopleX Inc. 5
6. © PeopleX Inc. 6 ⼀時はてブのテクノロジーのトップエントリーに
7. © PeopleX Inc. 7 AIに設計を書かせるだけで、理解負債と実装漏れが激減した話 [要約] • AIにデザインドキュメント（設計書）を⽣成させる • ⽣成させたデザインドキュメントをチームでレビュー • レビューしたデザインドキュメントを元にAIに実装させる 上記のフローで進めた結果... Before • 既存の設計・⽅針を無視したアウトプット • レビューコストが⾼い • 実装漏れがQAで発覚する After • 実装前に仕様や⽅針の曖昧さを潰せる • AIのアウトプットが、実装者の意図とズレ にくくなる • 設計を前提にレビューできるため、コード レビューが圧倒的に楽になる © PeopleX Inc. 7
8. © PeopleX Inc. 8 AIに設計を書かせるだけで、理解負債と実装漏れが激減した話 [要約] デザインドキュメント（設計書）に含めている内容 • ⼤まかな概要 ◦ 類似する設計パターンの列挙（あれば） ◦ UI/UX視点での体験概要 • 実装概要 ◦ フロントエンドの hooks / interface ◦ バックエンドのレイヤー分離（Controller / Service / Repository） ◦ データ構造・テーブル周りの変更 • テスト戦略 ◦ 単体 / E2E どこで何を担保するか • 意思決定が必要項⽬の精査 ◦ 機能フラグの有無 ◦ 権限設計 ◦ ⼤量実⾏時の処理⽅針（例：何件以上でジョブ化するか） © PeopleX Inc. 8
9. © PeopleX Inc. 9 AIに設計を書かせるだけで、理解負債と実装漏れが激減した話 [要約] デザインドキュメント（設計書）に含めている内容 • ⼤まかな概要 ◦ 類似する設計パターンの列挙（あれば） ◦ UI/UX視点での体験概要 • 実装概要 ◦ フロントエンドの hooks / interface ◦ バックエンドのレイヤー分離（Controller / Service / Repository） ◦ データ構造・テーブル周りの変更 • テスト戦略 ◦ 単体 / E2E どこで何を担保するか • 意思決定が必要項⽬の精査 ◦ 機能フラグの有無 ◦ 権限設計 ◦ ⼤量実⾏時の処理⽅針（例：何件以上でジョブ化するか） © PeopleX Inc. 9 フロントエンドの内容も入ってるが、もうちょい改善 できた...
10. © PeopleX Inc. 10 本⽇はこのフロントエンド特化verについてお話しします。
11. © PeopleX Inc. 11 AI時代のフロントエンドで起きがちなことと対策 起きがちなこと • コードは出るが設計がバラバラでレビュー コストが⾼い • 検証が⼿作業・属⼈化 ◦ バックエンドと⽐べてテストが難し い＋時間がかかる • 知⾒が残らない → 同じ調査・同じ失敗の 繰り返し ◦ ブラウザ検証はコンテクスト依存が 強い（ログイン情報、URL等） 対策 • デザインドキュメントと実装プランを先に ⽤意させる ◦ 参考にできる実装パターンがある場 合、ファイルパス、⾏番号、構造を 記録する • Playwright などのブラウザ検証ツールを 使⽤ • Agentが参照できるようなチートシート、 RAGを⽤意する
12. © PeopleX Inc. 12 フロントエンドで⼀気通貫のSkillを作成：Phaseの全体像 1. 要件ヒアリングと既存コード調査から、デザインドキュメントを作成し、ユーザーレビューで承認 を得る。 2. 実装ステップ（参考にすべき既存実装）と検証⽅法（開発サーバーでの確認＋Playwright MCP の ⼿順）をドキュメントに追記し、再度レビュー・承認。 3. 実装。各ステップ後に typecheck を回し、最後に typecheck と lint を並列実⾏。 4. Task subagent にコードレビューを委任。must-fix が 0 になるまで修正・再レビュー。 5. Playwright MCP(CLI) を Task subagent に任せてブラウザ検証。失敗したら3に戻る。 6. デザインドキュメントのチェックリスト（動作確認項⽬）と照合し、すべて満たしたら DONE。並 ⾏してナレッジベースを更新。 「設計→実装→検証」が必ず⼀巡するようにして、設計なし実装・検証なし完了を防いでいます。
13. © PeopleX Inc. 13 1. デザインドキュメント（設計書）を作成 • Claude Codeを使⽤しています • スキルを起動 • 機能要件が書いてあるチケットのURL、及 びUI情報を持っているFigmaのURLを貼り 付け ◦ MCP経由でClaude Codeが上記の機 能要件を取得 • 類似実装パターンの調査（subagent) • 受け⼊れ条件となるチェックリストの⽣成 • Claudeがデザインドキュメントを⽣成 • ユーザーが⽣成されたデザインドキュメン トをレビュー及び更新
14. © PeopleX Inc. 14 2. 実装プラン及び検証⽅法を作成 • 実装順序 • 各ロジックの詳細な実装⽅法 • 参照すべき実装の明記 ◦ ruleで指定するよりも確実 • Playwright を使った具体的な検証コード ◦ 全ては検証しない ◦ デザインドキュメントで指定されたチェッ クリストのもののみ
15. © PeopleX Inc. 15 3,4. 実装及びレビューのループ • ステップ１、２で⽣成したドキュメントを参照しながらの実装 • subagentでコードレビュー ◦ must-fix: 修正必須（バグ、セキュリティ、規約違反） ◦ should-fix: 修正推奨（パフォーマンス、可読性の大きな問題） ◦ nit: 軽微（スタイル、命名の改善提案） • must-fixが直るまでフィードバックループ subagentとは？ • 定義: より⼤きなAIエージェント（Skill）から特定のタスクを委任され、実⾏す る専⾨的なAIコンポーネントです。 • 役割: 今回のフローでは、特にコードレビューやブラウザ検証（Playwright）な どのタスクを担当します。
16. © PeopleX Inc. 16 5. subagent を使ってブラウザ検証。失敗したら3に戻る。 • 実装プランで指定されたテストのブラウザ検証 • テストが全て通るまで「実装」→ 「コードレビュー」→ 「ブラウザ検証」のループを回す
17. © PeopleX Inc. 17 6. 最終確認及びナレッジベース（RAG）の更新 • デザインドキュメントで指定され たチェックリストの要件が全て満 たせているか確認 • Agent⽤のチートシート（RAG） の更新 ◦ その情報があるとPlaywright が効率的に動ける　など
18. Summary まとめ © PeopleX Inc. 18
19. © PeopleX Inc. 19 まとめ • 設計をAIに書かせるフローを導⼊：「設計→実装→検証」のループを徹底し、設計なし実装や検証 なし完了を防いだ。 ◦ デザインドキュメントの生成 → チームレビュー → 実装プラン・検証方法の作成 → subagentによる 実装・レビュー・ブラウザ検証 の一気通貫したサイクル。 • 「理解負債」と「実装漏れ」が激減 • 品質と安全性の向上を⾃動化 ◦ subagentがコードレビュー（must-fix）やブラウザ検証（Playwright）を担い、人に依存しない高品質 な実装を担保。 • 知識の蓄積を促進 ◦ 実装プランで参照すべき既存コードや、 Agentが参照できるチートシート（ RAG）を更新することで、 知見が残り、調査の繰り返しを防ぐ。