AI-Ready Frontend Quality - Web Frontend Night
本イベントでは、これらの取り組みの一環として、AIが爆速でコードを生成する時代において、Webフロントエンド開発の品質保証がこれまで以上に難しくなると感じており、開発フロー・設計・テストがどう進化していくべきかを学びます。 Coding Agentを活用した開発フローの中で品質保証をどう進化させ、価値あるプロダクトを作り上げているのかを探ります。 「AI-Ready Frontend Quality」をテーマに掲げ、LayerXが実際に取り組んできた課題と解決策を具体的に紹介します。
AI時代のフロントエンド開発には、仕様書に載らない情報の言語化が重要ではないだろうか Jun
Structured communication
https://www.youtube.com/watch?v=8rABwKRsec4
課題
仕様書画更新されていなくて、QAにわたり認識のずれ
感想
仕様書って、AIに書かせるなら必要なとき作ればいいんじゃねと思うけどどうなんだろうね。
非決定的だから、レビュー必要というのが現実的だけど。
スクショがないので、画面イメージしづらくQAに渡しづらい
感想 人がいるとそういう考慮必要だよね。
→欲しくなったときに生成したいんだよね。
不安定、お金かかる
仕様書が完璧じゃないので、網羅的に難しい。
感想
仕様書を完璧にして、テスト作成させるなら、開発、仕様書作成する側の負担でかいな〜
QAも巻き込みたいな。
QA AI エンジニアのコミュニケーションとは？
Structured communication
仕様書、テストコードだけじゃない。
デザイン周りや開発過程の言語化されていないものがたくさんある。
How
VRT
Q: DOMの近くに置く？commitしてる？
a11y
開発仮定や気になったことなどレポジトリ内にメモを書く。
z dirは、ignore
ここにつっこんでる
感想: commitしないんだ。
感想
そういえば、commitにプロンプト入れているのか聞きたい。
あなたは高い技術力を持ったテックリードです。AI Agentを使いこなして高速な実装と高い品質を両立させて下さい。 akfm_sato
品質とは誰かにとっての価値である。by ワインバーグ
品質
エンジニアが行うべきことだし、達成はされる。
達成が難しい。投資むずい
検査、予防、サポート
品質保証
検査: 外部品質の検査
予防: 高い内部品質
サポート: 問題発生時のサポート
誰が品質保証するのか？
↑をAIが担える？
AIが担えるものは言語化ｓれたもの
AIが担える
言語化された要求を下にしたテストやテストケースの作成
AIが担えない
要求の言語化
高度なエンジニアリング知識と作業者の時間が必要。
感想: エンジニアじゃないとだめなのか？
リリース可否判断
高い内部品質
設計の壁打ちやルールに基づいたチェック
サポート
AI
原因特定と提案
not ai
問題発見や対処の主体性
問題解決できるという信頼関係
外からの見え方
AIが担う労力>>>指示労力
フロントエンドの品質保証はAIに任せられるか？ teyamagu
品質
水面上と水面下
現時点でのやり方だと悪化する可能性高い
whyは変わらない。
howと人間の役割が変わる。
3つの軸
品質をどう定義するか？
より広い視点から品質を再定義したい。 after ai
品質保証活動をどう設計するか？
感想 活動っていいことば
どのように確認、評価するか？
使う方法は？使う時間は？
AIをどう活用するか？
意思決定の支援パートナーとして使ってるとのこと。
リーダーシップと組織文化
技術に挑戦できる心理的安全性
思考停止しないで、なぜ？と問いつづける
どの様にAIエージェントと 協業すべきだったのか？Takepepe
悪い評判増えてきた？
コーディングに対する謙虚さがなくなった。
わかる
5フェーズ
0→1
AI便利だけど、代替もある。
1→10
そんなに、AIに対する期待は満たされてる
期待しすぎているフェーズ
10→90
課題感じるフェーズ
どかっと指示するより、分けて指示したほうが良かった
ルール守らないとか非決定的なこと増えてくる
90→99
バグや考慮漏れハマるフェーズ
フラストレーションmaxフェーズ
AIにやらせてできないものはできないので、自分でまきとる
99→100
linterとかだと強制できるけど、docsとかは安定しないよね。
感想
ちょうど開発段階分ける事考えていたから、こういう分け方いいかもね。
10→90をもう少しわけて、考えてみると良さそう。
セッション
AIのおし
AIを利用した開発においてとしては、どこまでコンテキストじょうほうレポジトリに入れている？
junさん、vrtの画像を近くに置くみたいなこと言っていた？レポジトリにコミットしてる？
自分が最近気になっているのは、プロンプトもcommitに入れたりしたほうがいいかな〜と思ってきてる。Kiroの開発者がオススメと言ってた
promptは、commitしてない
notionに貼り付けてkる
snapshot commitしてる
context重いので、都度読ませる’
あまりでかくできない。
ubieのkanoさん、devinのナレッジストアを更新かけている
コンテキストをmcp で読ませるのもあり。
50~70まで作ったあとに細かくタスク切って作業させてる。
疑似コード用意してからテスト書かせる。
合意形成に時間かけてる
モブプロしてる。
ありだな〜MTGの設定けっこうしんどいんだよね。
文化や暗黙知を上げる活動してる。
今週取り組んだAIの会がある
別のAIにコンテキスト少ない状態で、別のAIに一般論リサーチ
負債になりそうな予感みたいなコメント書くと意外ときを使ってっくれる。
hr.icon
あとから振り返り
イベント全体の感想と個別のTIPS
気になったTIPSは以下の通りです。
VRT（Visual Regression Testing）: ある発表で、DOMツリーのスナップショットを取得し、コンポーネントの近くに配置（コロケーション）して保存するという話がありました。画像スナップショットほど完璧ではありませんが、DOMツリーを使うという点に一理あると感じました。
思考プロセスのメモ化: 仕様書や実装方針ドキュメントに反映するほどではない、普段の技術的意思決定やデザインに対する考えといった、より粒度の細かいメモを残しておくのも有効だと理解しました。
コードコメントの活用: コードの意図などを、より緩やかに記録するためにコメントをコードの近くに配置（コロケーション）するのも良いと感じました。例えば、「このファイルのこの関数は壊れそうだ」といったメモを残すだけでも、AIによる開発支援の際にAIが注意を払ってくれる可能性があり、有効だと思いました。
品質保証に関する発表からの学び
今回の発表では、AI、フロントエンド、品質保証（QA）を関連付けて整理したものがいくつかありました。特に「品質保証とは何か」「AIを利用した開発はどうあるべきか」といった点を整理してくれる発表が多かった印象です。
この観点を活かし、自分たちのチームやシステム、運用において「どこができていて、どこができていないか」を言語化・整理することが有効だと感じました。品質保証を「検査」「予防」「サポート」の観点で分類し、どの活動にリソースを投入すべきかを整理する機会を設けるのは、非常に有益だと思います。
AIエージェント開発のフェーズ分けに関する考察
AIエージェントを利用した開発を5つのフェーズ（0→1, 1→10, 10→90, 90→99, 99→100）に分けて整理している発表がありました。これは、AI開発で速度が上がる部分と、逆に大変な部分があると感じていた自身の経験と合致しており、非常に参考になりました。
このフレームワークを基に、以下のような進め方を考えました。
1. AIの活用範囲を定義する:
「90→99」や「99→100」のフェーズはAIに頼りにくいため、自分が主導で進める。
「0→1」「1→10」といった初期フェーズは、AIをメインで活用する。
2. 新たな中間フェーズを設ける:
例えば「10→70」のようなラインを設け、そこまでは細かい感性を意識せず「ざっくり作る」フェーズと定義します。
この「ざっくり作った」段階で一度PDF化し、デザイナーなどの関係者に「この粒度で一旦作りました。この時点で確認できるのでお願いします」と共有します。
このアプローチにより、今期のテーマである「早く作る」を実現しつつ、以下のようなメリットが生まれると考えます。
リリース直前・直後の手戻りを減らせる。
開発の主要部分を迅速に完了させ、全体のリリーススケジュールを前倒しできる。
早い段階で多様な観点からの修正を取り入れられる。
結果として、開発における選択肢を増やせるのではないかと考えています。