Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AI時代のフロントエンド開発には、仕様書に載らない情報の言語化が重要ではないだろうか
Search
Jun
September 24, 2025
5
700
AI時代のフロントエンド開発には、仕様書に載らない情報の言語化が重要ではないだろうか
LayerX Web Frontend Night資料
Jun
September 24, 2025
Tweet
Share
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
303
21k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
53k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
9
570
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Rails Girls Zürich Keynote
gr2m
95
14k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Agile that works and the tools we love
rasmusluckow
331
21k
Writing Fast Ruby
sferik
629
62k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
45
2.5k
How to train your dragon (web standard)
notwaldorf
96
6.3k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
114
20k
Transcript
© LayerX Inc. AI時代のフロントエンド開発には、仕様書に載 らない情報の⾔語化が重要ではないだろうか Jun @jude638 2025/09/24 LayerX Web
Frontend Night
© LayerX Inc. 2 Jun @jude638 株式会社LayerX バクラク債権管理チーム所属 これまではフロントエンドエンジニアとしてスタートアップ数社を経験 ⾃⼰紹介
© LayerX Inc. 3 ‧今回の内容は、試⾏錯誤の過程を話すものです ‧私はClaude Codeを主に使っているので、その前提で話します ‧まだ個⼈レベルの取り組みです 🙇 前置き
Structured communication is the bottleneck (AIが発達するに従って)構造化された コミュニケーションがボトルネックとなる
© LayerX Inc. 5 Structured communication is the bottleneck ‧The
New CodeというプレゼンでOpenAIのSean Grove⽒が述べた⾔葉 ‧今後、AIがコード⽣成を担うようになるにつれて、ボトルネックとなるのは、 コードを書くことではなく、開発プロセス全体を整理‧構造化すること ‧なぜそれを作るのか? ‧どのように仕様を決めたのか?(チームでの議論) ‧できたものが意図した通りに動いているか? 👉こうした「⼈間のコミュニケーションを整理して記録する」がAIとの開発では⼤事
「⼈間のコミュニケーションを整理して記録」 つまり...それは仕様書?🤔
© LayerX Inc. 7 仕様書を作成するツールは増加中 これらのツールは「⼈間のコミュニケーション」を「仕様書」という形に整理して 記録する。 ‧Kiro ‧Spec Kit
‧cc-sdd ‧spec-workflow-mcp
© LayerX Inc. 8 私のチームは、仕様書‧テストが不⾜しがち ‧バクラク債権管理は2025年春にリリースされた新しいプロダクト ‧エンジニアが開発しながら仕様を決めていくので、最初の仕様書はざっくりとしか書かれ ていない ‧仕様書が更新されないままQAに渡ってしまい、エンジニア‧QA間で認識のズレが⽣まれ たりする。機能リリース後は更新されない
‧テストはフロントエンドはあまり書けていない 👉つまりエンジニア‧QA‧AI間での認識のズレが起こりがち
© LayerX Inc. 9 仕様書‧テストがちゃんとメンテナンスされれば3者間の「整理されたコミュニケー ション(Structured Communiation)」がうまくいくのでは?
それなら仕様書とテストを ⾃動で作れたらいいのでは? そうすればメンテナンスもしやすい💡
© LayerX Inc. 11 mastraで仕様書⾃動⽣成をやってみた mastraでAIワークフローを作って、仕様書の草案とプルリクエストを元に⾃動⽣成させてみ た
© LayerX Inc. 12 実際のチャット画⾯
© LayerX Inc. 13 簡単にはいかなかった ‧仕様はそれっぽいが、網羅性もなく微妙なものが出来上がった ‧よく分からないAIっぽい⾔葉選びや表現 ‧スクショがないので画⾯のイメージがしづらい → このままだとQAに渡せない
‧GitHubのプルリクは、開発初期のPRが⼊ってむしろノイズになってしまった ※プロンプト修正、cc-sddなどをもっと活⽤して改善できそうなことは多い
© LayerX Inc. 14 テストの⾃動⽣成もやってみた Shortestという⾃然⾔語からテストを⽣成できるツールを使ってみた // 請求書一覧の最初の請求書をクリックする shortest("/invoices ページで、一覧の一番上の請求書をクリックする
"); // 「請求メモ」に入力する shortest("「請求メモ」と書かれた入力欄をクリックする "); shortest("「これは請求メモです」と入力する "); // 「下書き保存」ボタンをクリックする shortest("「下書き保存」ボタンをクリックする ");
© LayerX Inc. 15 簡単にはいかなかった ‧テスト結果が毎回変わって不安定(1回の実⾏に30円くらいかかる) ‧アクセシビリティが間違っているところで⽌まってしまう(Locatorで取得できない) ‧結局、毎回の結果を安定させるにはPlaywrightのようなコード化が必要
© LayerX Inc. 16 Playwrightも書かせてみた ‧正常系の⾃動⽣成は意外とできた ‧仕様書が完璧でないので、網羅的なテストケースを作成するのが難しい ‧他の機能との複合したテストケースを考慮してくれない ‧Playwright MCPはrefの採番をしているので要素が取得できるが、普通のPlaywrightだと
それができないのでa11y対応が重要
⾃動⽣成はもっと試⾏錯誤が必要そう...。 そもそも仕様書とテストが⾃動⽣成 できたらそれでOK?🤔
© LayerX Inc. 18 この3者間のコミュニケーションは「仕様書+テストコード」だけ?
© LayerX Inc. 19 「Structured communication === 仕様書+テストコード」ではない 仕様書とテストだけではカバーできない、開発における⼈間のコミュニケーションはたくさ ん存在する
© LayerX Inc. 20 仕様書でカバーできないものとは ‧仕様書でカバーできないものはフロントエンドに多い ‧marginやpadding (例:なぜここは1remではなく2remのmargin-top?) ‧アクセシビリティ ‧開発過程の議論
‧なぜここのボタンは右寄せにしたのか ‧なぜこのテーブル「メモ‧ラベル」カラムは2つに分けずに1カラムなのか ‧当初のデザインからなぜ変更されたのか 👉 こうした仕様書やコードベースに載りにくい、でもフロントエンドエンジニアが知って いる背景がたくさんある
© LayerX Inc. 21 開発過程での同僚への質問や相談も仕様書に載りにくい 「このモーダルは他のモーダルと違って、なぜ下に閉じるボタンがあるんですか?」 「この機能は別のバクラクのプロダクトと連携するから、ここだけ違うデザインにわざとし ています」
こうした「仕様書に載らない情報の⾔語化」 がフロントエンドでは特に重要
© LayerX Inc. 23 具体的にどう⾔語化するか 1. margin、paddingなどのUI ‧DOM構造なのでJestのスナップショットでAIが読める形にできる ‧詳細な単体テストを書く時間はなくても、スナップショットテストならすぐ書ける ‧実際のコードベースだと条件分岐も⼊ってくるので、できればスナップショットのような
レンダリング結果がいい
© LayerX Inc. 24 具体的にどう⾔語化するか 2. アクセシビリティ ‧PlaywrightでアクセシビリティツリーのJSONを出⼒させる ‧できればDOMのスナップショットと近い場所に置く
const a11ySnapshot = await page.accessibility.snapshot(); { "role": "WebArea", "name": "ログイン", "children": [{ "role": "text", "name": "メールアドレス/ログインID" }, … ] }
© LayerX Inc. 25 具体的にどう⾔語化するか 3. 開発過程‧気になったことを、リポジトリ内にメモを作ってどんどん書く ‧仕様書やコード上のコメントに書くほどではないものを書く (⾃分⽤メモに近い) ‧主に書くのはその機能に関する試⾏錯誤の過程
‧コーディングルールはrulesなどに載せているので書く必要はない ‧メモのような、煩雑なドキュメントでOK
© LayerX Inc. 26 例 /z/settings/representativeSettingsPage.md これは「代表入金先設定機能」のメモである。似ているページは「◯◯設定」と「◯◯設定」ページ。 開発過程での議論: - 新規作成ボタンは他の設定ページと違って左に寄せている。その理由は◯◯
- 他の設定ページを作る場合は、このページのボタンの UIに沿わない方が良さそう メモ: - そういえばdivタグでとりあえず実装してしまったけど、 sectionタグ使うべきだった - そのうちモーダルは共通化した方がいいかも - このモーダルのFormの項目増えたら負債になりそう
© LayerX Inc. 27 今後はこうしたい ‧MCP化して、⾃動でClaude Codeと対話させるようにしたい ‧理想はどんな細かいメモや議論も、本来の仕様書に含めるようにしたい ‧「⾃分⽤メモ」が存在するということは、つまり仕様書に全てを書けていない ‧古い機能の挙動やUIに関する議論は、古いNotionの仕様書ではなく、コードの近くに
配置する ‧greptileなどのレビューツールで、他のページのスナップショットとa11yツリーを⾒た上 で⽐べてもらいたい
© LayerX Inc. 28 最後に ‧「うちではこうやっているよ」、「こんなやり⽅はどうか?」という⽅がいればぜひご意 ⾒ください! ‧絶賛採⽤中なので、よかったら以下のカジュアル⾯談のリンクより話しましょう!
ご清聴ありがとうございました