FSDはAI Codingの品質と開発コストを改善し得るか / 20260828-ai-coding-with-fsd

Transcript

1. FSDはAI Codingの 品質と開発コストを改善し得るか 戦略開発本部 AIチャット開発部 佐⽵友真
2. ⾃⼰紹介 佐⽵友真 • AIチャット開発部 Webアプリの0→1 • 男の⼦の好きな趣味は⼤体好き • 最近バイク始めました • フロントエンドカンファレンス名古屋 実⾏委員⻑ • X：@yuma_satake22
3. FSDとは FSDはAI Codingの 品質と開発コストを改善し得るか
4. FSDとは Feature-Sliced Designとは？
5. FSDとは FSDとは • FE開発における設計⼿法 • 思想とツールチェーンを提供 • コードベースを分割して管理 → Layers（依存整理） → Slices（ドメイン単位） → Segments（技術単位） Source: https://github.com/feature-sliced/documentation| MIT License
6. FSDとは FSDとは • FE開発における設計⼿法 • 思想とツールチェーンを提供 • コードベースを分割して管理 → Layers（依存整理） → Slices（ドメイン単位） → Segments（技術単位） Source: https://github.com/feature-sliced/documentation| MIT License
7. FSDとは 提供されているFSDツールチェーン • ESLint Plugin • steiger（CLIツール） ➡ 主にFSDの中⼼的な概念である依存関係の制約についてのLinter
8. FSDとは 提供されているFSDツールチェーン • ESLint Plugin • steiger（CLIツール） • Skills • llms.txt ➡ FSDの設計を適切に使⽤するための概念‧ユースケースの提供
9. Source: https://github.com/feature-sliced/documentation| MIT License
10. Source: https://github.com/feature-sliced/documentation| MIT License
11. お話の主成分 FSDはAI Codingの 品質と開発コストを改善し得るか
12. お話の主成分 男の⼦の好きなものといえば？
13. お話の主成分 カメラ
14. お話の主成分 カメラ オーディオ
15. お話の主成分 カメラ オーディオ ⾞‧バイク
16. お話の主成分 カメラ オーディオ ⾞‧バイク ITガジェット
17. お話の主成分 カメラ オーディオ ⾞‧バイク ITガジェット クソデカ重厚アーキテクチャ
18. お話の主成分 なぜ世界は分厚いアーキテクチャを 受け⼊れてくれないのか
19. お話の主成分 なぜ分厚いアーキテクチャは受け⼊れられないか 「メリット」 「デメリット」 • 変更容易性の向上 • ボイラープレートの増⼤ • テスト容易性の向上 • 学習/認知コストの⾼さ • 型安全性の向上 • 開発速度の低下
20. お話の主成分 なぜ分厚いアーキテクチャは受け⼊れられないか 「メリット」 「デメリット」 • 変更容易性の向上 • ボイラープレートの増⼤ • テスト容易性の向上 • 学習/認知コストの⾼さ • 型安全性の向上 • 開発速度の低下 ➡ 開発コストの増⼤に⾒合った品質向上が得られない
21. お話の主成分 なぜ分厚いアーキテクチャは受け⼊れられないか 「メリット」 XXXってやつ too muchですよね」 「デメリット」 ？？？「その • 変更容易性の向上 • ボイラープレートの増⼤ • テスト容易性の向上 • 学習/認知コストの⾼さ • 型安全性の向上 • 開発速度の低下 ➡ 開発コストの増⼤に⾒合った品質向上が得られない
22. お話の主成分 なぜ分厚いアーキテクチャは受け⼊れられないか 「メリット」 Effect TSって〜 「デメリット」 • 変更容易性の向上 • ボイラープレートの増⼤ • テスト容易性の向上 • 学習/認知コストの⾼さ • 型安全性の向上 • 開発速度の低下 ➡ 開発コストの増⼤に⾒合った品質向上が得られない
23. お話の主成分 なぜ分厚いアーキテクチャは受け⼊れられないか 「メリット」 「デメリット」 フロントエンドでやる Clean Architectureって〜 • 変更容易性の向上 • ボイラープレートの増⼤ • テスト容易性の向上 • 学習/認知コストの⾼さ • 型安全性の向上 • 開発速度の低下 ➡ 開発コストの増⼤に⾒合った品質向上が得られない
24. お話の主成分 なぜ分厚いアーキテクチャは受け⼊れられないか 「メリット」 「デメリット」 Redux + Redux-Sagaって〜 • 変更容易性の向上 • ボイラープレートの増⼤ • テスト容易性の向上 • 学習/認知コストの⾼さ • 型安全性の向上 • 開発速度の低下 ➡ 開発コストの増⼤に⾒合った品質向上が得られない
25. お話の主成分 なぜ分厚いアーキテクチャは受け⼊れられないか 「メリット」 「デメリット」 マイクロフロントエンドって〜 • 変更容易性の向上 • ボイラープレートの増⼤ • テスト容易性の向上 • 学習/認知コストの⾼さ • 型安全性の向上 • 開発速度の低下 ➡ 開発コストの増⼤に⾒合った品質向上が得られない
26. お話の主成分 なぜ分厚いアーキテクチャは受け⼊れられないか 「メリット」 Branded Typeって〜「デメリット」 • 変更容易性の向上 • ボイラープレートの増⼤ • テスト容易性の向上 • 学習/認知コストの⾼さ • 型安全性の向上 • 開発速度の低下 ➡ 開発コストの増⼤に⾒合った品質向上が得られない
27. お話の主成分 男の⼦なので重厚なアーキテクチャが好き！！！
28. お話の主成分 男の⼦なので重厚なアーキテクチャが好き！！！
29. お話の主成分 ソフトウェアエンジニアは アーキテクチャによる品質向上の夢を⾒ない
30. お話の主成分 時代はAI Coding！
31. お話の主成分 アーキテクチャによる 品質⾯の強み ✖ Skills等による AIの認知コストの低減
32. お話の主成分 アーキテクチャによる 品質⾯の強み ✖ Skills等による AIの認知コストの低減 ⬇ AIネイティブな分厚いアーキテクチャ+AI Codingは 低い開発コストと⾼品質を提供してくれるのでは？
33. 検証内容 FSDはこれを満たしていそう！ ちゃんとコスト測って検証しよう！！
34. 検証内容 検証した内容
35. 検証内容 前提
36. 検証内容 品質って？開発コストって？
37. 検証内容 前提① - 品質 品質の定義 • 変更容易性：変更が低コストかつ、狭い影響範囲で⾏えるか • 要件網羅率：要件を満たした実装が正しく⾏えているか ➡ 要件を満たし、かつ要件変更に対して 低コストかつ破壊無く対応できる状態 “品質が⾼い” とする
38. 検証内容 前提① - 品質 計測⽅法 • 変更容易性 ➡ 要件の変更対応後のトークンコスト‧検証⽤E2Eの通過率 • 要件網羅率 ➡ 初回の実装が仕様を元にしたE2Eを何%通過するか
39. 検証内容 前提② - 開発コスト 開発コストの定義 • トークン課⾦額 FSD側で⼤量のドキュメントを読み込むため、単にトークン量で測ると不利 ➡ ドキュメントの読み込みなどが影響を受けるプロンプトキャッシュ などを考慮し、実際の開発に近い“開発コスト”を計上するため
40. 検証内容 検証した仮説
41. 検証内容 検証した仮説 FSDの採⽤によって • 品質 ：変更容易性がFSDの⽅が⾼くなるはず • 開発コスト：開発初期は⾼く、変更をしていくと低下するはず • モデル差 ：低性能なモデルほどFSDの効果が⼤きく出るはず
42. 検証内容 仮説① - 品質 • 要件網羅率は変わらないはず 要件を正しく実装できるかは、要件に対するモデルの読解⼒に依存するため アーキテクチャの影響を受けにくいはず • 変更容易性はFSDが有利になるはず ドメインの集約と依存の整理により、既存実装の破壊を抑えつつ 要件の変更に対応できるはず
43. 検証内容 仮説① - 品質 • 要件網羅率は変わらないはず 要件を正しく実装できるかは、要件に対するモデルの読解⼒に依存するため アーキテクチャの影響を受けにくいはず • 変更容易性はFSDが有利になるはず ドメインの集約と依存の整理により、既存実装の破壊を抑えつつ 要件の変更に対応できるはず ➡ FSDの採⽤は、変更容易性を改善するはず
44. 検証内容 仮説② - 開発コスト
45. 検証内容 仮説② - 開発コスト 「開発初期」 FSDの方がSkills等の非コード トークンが多いため 高コスト
46. 検証内容 仮説② - 開発コスト 「開発中期」 生成が必要なものが多いため ・探索費： FSDの方が低い ・生成費： FSDの方が高い
47. 検証内容 仮説② - 開発コスト 「追加開発」 要件の変更・追加においては 探索・生成においても FSDの方が優位
48. 検証内容 仮説② - 開発コスト • １セッション内では複雑ならFSDの⽅が低コスト セッションが⻑くなるほどSkills等の読み込みコストより アーキテクチャによる探索コストの低下が効くはず • 開発全体ではコードベースが⼤きくなればFSDの⽅が低コスト 初期はコードベース⾃体が軽量なため、FSDの⽅が⾼コスト 開発が進めば、アーキテクチャによるコスト低減が出てくるはず
49. 検証内容 仮説② - 開発コスト • １セッション内では複雑ならFSDの⽅が低コスト セッションが⻑くなるほどSkills等の読み込みコストより アーキテクチャによる探索コストの低下が効くはず • 開発全体ではコードベースが⼤きくなればFSDの⽅が低コスト 初期はコードベース⾃体が軽量なため、FSDの⽅が⾼コスト 開発が進めば、アーキテクチャによるコスト低減が出てくるはず ➡ 初期は⾼コストだが、どこかで損益分岐点がくるはず
50. 検証内容 仮説③ - モデル性能による作⽤の違い • ⾼性能モデル（Opus）ではFSDの効果は⼩さいはず 元々設計⼒が⾼く、FSD無しでも堅牢に実装ができてしまうはず • 低性能モデル（Haiku）ではFSDの効果は⼤きいはず 設計⼒の低いモデルでも、FSDのツールチェーン+AI向け要素によって 適切な実装が⾏えるはず
51. 検証内容 仮説③ - モデル性能による作⽤の違い • ⾼性能モデル（Opus）ではFSDの効果は⼩さいはず 元々設計⼒が⾼く、FSD無しでも堅牢に実装ができてしまうはず • 低性能モデル（Haiku）ではFSDの効果は⼤きいはず 設計⼒の低いモデルでも、FSDのツールチェーン+AI向け要素によって 適切な実装が⾏えるはず ➡ FSDにより安価なモデルでも⾼品質なコードを書けるかもしれない（？）
52. 検証内容 仮説の検証⽅法 テーマ：ECサイト 3つのストーリーをOpus 4.7とHaiku 4.5に取り組ませて検証をする • • • S1：要件に基づいて基本的なECサイトをNext.js + TSで実装（基礎実装） S2：カート機能/注⽂履歴機能の追加（要件追加） S3：商品に⾊やサイズなどのバリエーションを持たせる変更（要件変更） FSDの対抗として⼀般なFeature-Based（以後FB）で検証を⾏う
53. 検証内容 検証結果
54. 検証内容 検証結果 有効な検証Run数 モデル アーキテクチャ S1 S2 S3 Opus 4.7 FSD 2 2 2 Opus 4.7 Feature-Based 2 2 2 Haiku 4.5 FSD 2 3 2 Haiku 4.5 Feature-Based 4 3 2
55. 検証内容 品質仮説① - 要件網羅率はFSD/FBで変わらないはず
56. 検証内容 品質仮説①：要件網羅率はFSD/FBで変わらないはず S1（基礎実装）/ S2（要件追加）：仮説通り差は⽣まれなかった 各シナリオ初回E2E通過率 モデル シナリオ Opus 4.7 S1（初期実装） 1.00 1.00 Opus 4.7 S2（要件追加） 0.96 0.94 Haiku 4.5 S1（初期実装） 0.00 0.00 Haiku 4.5 S2（要件追加） 0.89 0.89 FSD FB
57. 検証内容 品質仮説①：要件網羅率はFSD/FBで変わらないはず S3（要件変更）Opus/Haiku共にFSDの要件網羅率が低下した ➡ 原因：FSDのPublic APIパターン vs Next.jsのRSC境界問題 S3初回E2E通過率 モデル シナリオ Opus 4.7 S3（要件変更） 0.00 1.00 Haiku 4.5 S3（要件変更） 0.71 1.00 FSD FB
58. 検証内容 品質仮説①：要件網羅率はFSD/FBで変わらないはず FSDのPublic APIパターン vs Next.jsのRSC境界 • Public API：他ドメインで関数を使う場合にはindex.tsでre-export • 実装でserver onlyな関数をre-export経由でclient内で使う実装が多発 • 検証都合でbuild check無し
59. 検証内容 品質仮説①：要件網羅率はFSD/FBで変わらないはず FSDのPublic APIパターン vs Next.jsのRSC境界 • Public API：他ドメインで関数を使う場合にはindex.tsでre-export • 実装でserver onlyな関数をre-export経由でclient内で使う実装が多発 • 検証都合でbuild check無し ➡ AI向けドキュメントがあっても、FSD+Next.jsの認知負荷の⾼さが⽬⽴った
60. 検証内容 品質仮説② - 変更容易性はFSDの⽅が⾼くなる
61. 検証内容 品質仮説② - 変更容易性はFSDの⽅が⾼くなる 結論 S3（要件変更）を通してFBの⽅が⾼い通過率を達成した S3初回E2E通過率 FSD FB Opus 4.7 0.00 1.00 Haiku 4.5 0.71 1.00
62. 検証内容 品質仮説② - 変更容易性はFSDの⽅が⾼くなる 結論 S3（要件変更）を通してFBの⽅が⾼い通過率を達成した S3初回E2E通過率 FSD Opus 4.7 0.00 Haiku 4.5 0.71 FB �� 1.00 1.00
63. 検証内容 品質仮説② - 変更容易性はFSDの⽅が⾼くなる S3初回E2E通過率 Opus 4.7 0.00 品質仮説①と同じ FSDのPublic APIパターン vs Next.jsのRSC境界 問題が発⽣ 1.00 Haiku 4.5 0.71 1.00 FSD FB
64. 検証内容 品質仮説② - 変更容易性はFSDの⽅が⾼くなる S3初回E2E通過率 FSD FB Opus 4.7 0.00 1.00 Haiku 4.5 0.71 1.00 Opusの方がS1（基礎実装）で正しく FSD実装 ➡ Public APIの適⽤箇所が多くなり抜け漏れ
65. 検証内容 品質仮説② - 変更容易性はFSDの⽅が⾼くなる S3初回E2E通過率 FSD FB Opus 4.7 0.00 1.00 Haiku 4.5 0.71 1.00 ➡ 検証⽅法に問題はありつつも、E2Eの通過率では品質仮説①と同様に FSD+Next.jsの認知負荷の⾼さが⽬⽴った
66. 検証内容 品質仮説② - 変更容易性はFSDの⽅が⾼くなる E2E以外の検証では、正しくFSD実装しているOpusではFSDの⽅が優位 観点 内容 Haiku/FSD E2E通過率 初回E2Eの通過率 0.71 1.00 0.00 1.00 変更ファイル率 ファイルの変更率 0.21 0.20 0.16 0.24 レビュー指摘密度 レビュアー AIによる指摘量 0.012 0.007 0.008 0.017 avg import モジュール結合度 2.04 2.15 1.9 2.3 Haiku/FB Opus/FSD Opus/FB
67. 検証内容 品質仮説② - 変更容易性はFSDの⽅が⾼くなる E2E以外の検証では、正しくFSD実装しているOpusではFSDの⽅が優位 観点 内容 Haiku/FSD 初回E2Eの通過率 0.71 1.00 0.00 1.00 変更ファイル率 ファイルの変更率 0.21 0.20 0.16 0.24 レビュー指摘密度 レビュアー AIによる指摘量 0.012 0.007 0.008 0.017 avg import モジュール結合度 2.04 2.15 1.9 2.3 E2E通過率 Haiku/FB OpusではFSDの方がレビュー指摘が 50%少ない Opus/FSD Opus/FB
68. 検証内容 品質仮説② - 変更容易性はFSDの⽅が⾼くなる E2E以外の検証では、正しくFSD実装しているOpusではFSDの⽅が優位 観点 内容 Haiku/FSD 初回E2Eの通過率 0.71 1.00 0.00 1.00 変更ファイル率 ファイルの変更率 0.21 0.20 0.16 0.24 レビュー指摘密度 レビュアー AIによる指摘量 0.012 0.007 0.008 0.017 avg import モジュール結合度 2.04 2.15 1.9 2.3 E2E通過率 Haiku/FB モジュール結合度は 両モデルで FSD優位 Opus/FSD Opus/FB
69. 検証内容 開発コスト① - FSDの⽅がトークンの固定費は⾼い
70. 検証内容 開発コスト① - FSDの⽅がトークンの固定費は⾼い 結論 Opusでは仮説通り固定費が増⼤した 初回のEditまでのトークン読み込み量（FSD/FB⽐） S1（基礎実装） S2（要件追加） S3（要件変更） Opus 4.7 1.31x 1.52x 1.27x Haiku 4.5 1.05x 1.04x 0.96x
71. 検証内容 開発コスト① - FSDの⽅がトークンの固定費は⾼い 初回のEditまでのトークン読み込み量（FSD/FB⽐） S1（基礎実装） S2（要件追加） S3（要件変更） Opus 4.7 1.31x 1.52x 1.27x Haiku 4.5 1.05x 1.04x 0.96x Haikuでは適切にSkillsの読み込みが行われなかった ため 差が出なかった
72. 検証内容 開発コスト② - FSDの⽅がトークンの変動費は低い
73. 検証内容 開発コスト② - FSDの⽅がトークンの変動費は低い 結論 Opusではファイルの探索費‧⽣成費双⽅が増⼤ トークン消費量（FSD/FB⽐） 探索費 生成費 Opus 4.7 1.06x 1.18x Haiku 4.5 0.95x 0.85x
74. 検証内容 開発コスト② - FSDの⽅がトークンの変動費は低い FSDに忠実なOpusでは明確にFSDが⾼い シナリオ モデル 探索 - FSD/FB比率 生成 - FSD/FB比率 S1（基礎実装） Opus 4.7 1.13x 1.27x S2（要件追加） Opus 4.7 1.30x 1.29x S3（要件変更） Opus 4.7 0.71x 0.93x
75. 検証内容 開発コスト② - FSDの⽅がトークンの変動費は低い FSDに忠実なOpusでは明確にFSDが⾼い 調査した結果、 FSDのPublic vs Next.jsのRSC境界問題で シナリオ モデル APIパターン 探索 - FSD/FB比率 生成 - FSD/FB比率 FSDの適⽤が完全ではなかったため、外れ値になっている S1（基礎実装） Opus 4.7 1.13x 1.27x S2（要件追加） Opus 4.7 1.30x 1.29x S3（要件変更） Opus 4.7 0.71x 0.93x
76. 検証内容 開発コスト② - FSDの⽅がトークンの変動費は低い 探索コスト増 • FSD規約の読み込みコスト • Public API（index.ts）経由での⼆段階読み込み • 設計判断のための他entityの読み込み ⽣成コスト増 • モジュール分割（1.13倍〜1.49倍） • 依存削除のための重複記述
77. 検証内容 開発コスト② - FSDの⽅がトークンの変動費は低い Haiku...?知らない⼦ですね （例によって不完全なFSD実装のため、結果がFBの値に寄ってしまっている）
78. 検証内容 開発コスト③ - 実装フェーズによって損益分岐点が来る
79. 検証内容 開発コスト③ - 実装フェーズによって損益分岐点が来る 結論 固定費‧変動費ともにFSDの⽅が⾼く、損益分岐点はこない🥲
80. 検証内容 ラスト！安価なモデルでもFSDなら⾼品質！
81. 検証内容 どうみても実現していない 仮説 FSDにより安価なモデルでも⾼品質なコードを書けるかもしれない（？） 結論 • 安価なモデルではアーキテクチャの規約を守りきれず、品質は向上しない • ⾼価なモデルでは恩恵を受けられるが、規約によるコスト増をもろに受ける • Haikuでコーディングしてはいけない
82. まとめ まとめ
83. まとめ FSDは低コスト‧⾼品質を提供してくれるのか？
84. まとめ FSDは低コスト‧⾼品質を提供してくれるのでは？ ⬇ 品質は向上するがAIにとっての認知コストは下がり切らない コストは相対的に増加する
85. 最後に 最後に
86. 最後に 最後に • 検証設計難しい（AIのサンドボックス周りも⼤変だった） • 検証に従量課⾦換算1,616💲掛かりました😇 • 気が向いたら記事にします（喋りきれてないので、懇親会で聞いて下さい） • 検証データはここにあります https://github.com/Yuma-Satake/FSD-with-AI-verification
87. FSDはAI Codingの 品質と開発コストを改善し得るか 戦略開発本部 AIチャット開発部 佐⽵友真