Claude Code で画面の仕様書を作ろう Copyright © ZOZO, Inc. 1 株式会社ZOZO
 ZOZOTOWN開発本部 ZOZOTOWN開発1部 iOSブロック
 
 だーはま / 濵田 悠樹 Copyright © ZOZO, Inc. 

© ZOZO, Inc. 株式会社ZOZO ZOZOTOWN開発本部 ZOZOTOWN開発1部 iOSブロック 濵田 悠樹 @ios_hamada 2 ● 25年新卒でZOZOに入社 ● 大学, 大学院で AIの研究 ● 服でユーザーの人生を変えるためZOZOへ入社 ● 新卒4人で IRODORI を開発中（業務外） 

© ZOZO, Inc. 3 Claude Code で画面の仕様書を作ろう ○ 4つの Subagents を使い 、コードから画面の仕様書を作りました 依存関係 UIコンポーネント 実装コード ※ 対象は ZOZOTOWN ではなく、個人開発しているIRODORI 

© ZOZO, Inc. 4 なぜAIにコードから仕様書を作らせるのか？ （1/2） A君、HogeView について知ってる？ いやー、知らないですね 何年も前に作られた画面で、担当者も仕様書もないです まじかー、FatVC になっててコードが1,000行超えてるんだよね しかも、依存関係もかなり複雑で、、、 

© ZOZO, Inc. 5 なぜAIにコードから仕様書を作らせるのか？ （2/2） けど 今日の案件ミーティングに向けて調査したいんだよなあ... A君、画面の構成から関連するファイル全部調べてくれない？1時間で 、、、はい？（人間にはできないでしょう） 

© ZOZO, Inc. 6 なぜAIにコードから仕様書を作らせるのか？ （2/2） 、、、はい？（人間にはできないでしょう） 

© ZOZO, Inc. 7 なぜAIにコードから仕様書を作らせるのか？ （2/2） 、、、はい？（人間にはできないでしょう） AIの強み : 分析と解釈 （not 創造） 高速に大量のコードを読んで、ドキュメント生成までやってくれる 

© ZOZO, Inc. 8 なぜ画面の仕様書を作ったのか？ 背景と課題 ■ 仕様書が存在しない画面は 実装者 or コード から仕様をまとめる ■ 大規模なプロジェクトのコードリーディングに時間がかかる 提案 ■ Claude Code を使い高速に仕様まとめる 

© ZOZO, Inc. 9 Claude Code で画面の仕様書を作ろう ○ 4つの Subagents + 1つの Custom Command . ├── agents │ ├── spec-reseacher.md │ ├── ios-architecture-enngineer.md │ ├── modern-swift-reviewer.md │ └── refactor-planner.md ├── commands │ └── screen-spec-survey.md └── settings.local.json 画面仕様（画面構成, データフロー など） を調査 アーキテクチャ導入に向けた依存関係の整理 および 導入に向けた技術的調査 UIやライブラリ選定など技術的課題を調査 リファクタリングに向けたプランニング 

© ZOZO, Inc. 10 Claude Code で画面の仕様書を作ろう ○ 4つの Subagents + 1つの Custom Command . ├── agents │ ├── spec-reseacher.md │ ├── ios-architecture-enngineer.md │ ├── modern-swift-reviewer.md │ └── refactor-planner.md ├── commands │ └── screen-spec-survey.md └── settings.local.json $ claude /screen-spec-survey HogeView 

© ZOZO, Inc. 11 spec-reseacher のプロンプト ## 目的 * 画面を開いてからの **データフロー**（依存解決→API→変換→State 更新→描画）と、ユーザー操作（例: **Aというコンポーネントをタップ**）時の **処 理・I/O・状態/遷移** を一目で把握できるようにする。 ## 出力フォーマット 1. TL;DR（初回ロードと主要アクションのI/Oを箇条書き） 2. 画面の構成（UI/State/Lifecycleの表） 3. データフロー（画面表示→初回ロードのシーケンス図） 4. UIコンポーネント×アクション×副作用の対応表 5. 主アクション毎のシーケンス図（最低A=主ボタン, Refresh, セル選択） 6. ネットワークI/O一覧（Method/Path/Auth/キャッシュ/失敗時/呼出根拠） 7. 状態管理（公開State, アクション, 非同期/キャンセル） 8. DI（依存解決の流れ）／ナビゲーション 9. エラー/ローディング/空状態 10. イベントログ送信箇所（ない場合は無しと記載） 11. 分析イベント/フラグ 12. リスク・改善 13. Reference ## 探索範囲 * **関連するファイルは可能な限り探索・調査** する （ViewModel/Reducer/Repository/API/Router/DI/テスト/ 拡張/ユーティリティを横断参照）。 ## 対象のアクション（該当するもののみ） * 画面表示（初回ロード） * 主要ボタン（例: AddToCart/Favorite/Buy）タップ * セル選択（詳細遷移） * Pull-to-Refresh / ページネーション * 失敗時のエラーハンドリング ## 出力スタイル * 判断根拠となるコードは丁寧に過不足なく提示 。 * 技術構成を図に描く場合は、左側にUI層で右に行くほ どDomain,Data層になるようにしてください。 * 出力は日本語でお願いします。 

© ZOZO, Inc. 12 キーポイント（1/2） ○ はじめに 出力フォーマット を確定する ■ AI の手綱を握るために最も重要なこと。プロンプトから書かない。 出力マークダウンの構成 ## 出力フォーマット 1. TL;DR（初回ロードと主要アクションのI/Oを箇条書き） 2. 画面の構成（UI/State/Lifecycleの表） 3. データフロー（画面表示→初回ロードのシーケンス図） 4. UIコンポーネント×アクション×副作用の対応表 5. 主アクション毎のシーケンス図（最低A=主ボタン, Refresh, セル選択） 6. ネットワークI/O一覧（Method/Path/Auth/キャッシュ/失敗時/呼出根拠） 7. 状態管理（公開State, アクション, 非同期/キャンセル） 8. DI（依存解決の流れ）／ナビゲーション 9. エラー/ローディング/空状態 10. イベントログ送信箇所（ない場合は無しと記載） 11. 分析イベント/フラグ 12. リスク・改善 13. Reference 

© ZOZO, Inc. 13 ○ 既存実装から仕様をドキュメント化 ■ ZOZOTOWN iOS では MVVM+UseCase アーキテクチャのガイドラインあり キーポイント（2/2） AI は基本的に学習させたデータのみをもとに回答 している しかし、多くの企業は AI が事前学習不可能なデータを扱っている ことが多い 企業やチーム独自にAI をチューニングしたいならデータを与えるのが有効 個人的な見解 ※ 社外秘情報を使う場合は、必ずオプトアウトの設定にする 

No content