AI駆動開発における設計思想 認知負荷を下げるフロントエンドアーキテクチャ/ 20251211 Teppei Hanai

2025/12/11 AI 駆動開発勉強会 フロントエンド支部 #1
https://aid.connpass.com/event/374658/

株式会社SHIFT
DAAE統括部 DAAE部 DAAEグループ
花井 徹平

Transcript

1. AI 駆動開発勉強会 フロントエンド支部 #1 AI駆動開発における設計思想 - 認知負荷を下げるフロントエンドアーキテクチャ - 株式会社SHIFT DAAE統括部 花井徹平
2. いかにAIの認知負荷を下げる設計を行えるか 本日のテーマ 2
3. 3 OUR PRODUCT プロダクトの紹介 【プロダクト】 総務向けの資産の一元管理ツール「ナクサナイ」 【ローンチ】 2025/9 【エンジニア構成】 FEリード＋BEリード＋業務委託（部分アサイン） （ほぼ）毎週リリース！ FEの月平均PR消化数70件！
4. IMPACT AIの活用状況 60% エージェント型AIツール （Devin）によるPR作成率 ※ PRを Open したのが AI か人間かで判定しているため、 AIコードエディタで実装した場合も Humanに含まれています。 65 44 2025年11月のPR作成数 AI Human 4 AIを活用し少人数であっても安定したリリースを実現しています。
5. CONCEPT 認知負荷を下げる AIが効率的にコードを理解・生成するために最も重要なのは「認知負荷」を下げることです。 ※認知負荷 = コードを理解するために必要な労力 5 認知負荷が低い ≒ AIフレンドリー
6. AIフレンドリーな設計原則
7. PRINCIPLES AIフレンドリーな設計原則 1. 宣言的設計 HOW（命令形）ではなく WHAT（宣言形）を記述。 「因果関係」が明確になり、状 態追跡が容易に。 2. 関数型パラダイム 純粋関数を重視し副作用を分離。 各関数が独立することで、AIの理 解コストが下がる。 3. イミュータブル 変数が不変であることで、「ど こで値が変わったか」を追う認 知負荷を減らす。 4. 型システム 型は「意図」のドキュメント。 Discriminated Union等で不可 能な状態を物理的に排除する。 5. セオリー準拠 フレームワーク推奨パターンを 守る。 独自ルールを減らし、AIの学習 知識を最大限活かす。 6. 意図の明確化 単一責任、明示的な入出力。 「このコードは何をしているか ？」が自明な状態を保つ。 7
8. PRINCIPLES AIフレンドリーな設計原則 1. 宣言的設計 HOW（命令形）ではなく WHAT（宣言形）を記述。 「因果関係」が明確になり、状 態追跡が容易に。 2. 関数型パラダイム 純粋関数を重視し副作用を分離。 各関数が独立することで、AIの理 解コストが下がる。 3. イミュータブル 変数が不変であることで、「ど こで値が変わったか」を追う認 知負荷を減らす。 4. 型システム 型は「意図」のドキュメント。 Discriminated Union等で不可 能な状態を物理的に排除する。 5. セオリー準拠 フレームワーク推奨パターンを 守る。 独自ルールを減らし、AIの学習 知識を最大限活かす。 6. 意図の明確化 単一責任、明示的な入出力。 「このコードは何をしているか ？」が自明な状態を保つ。 8
9. EXAMPLE 設計原則３ -イミュータブル- 変数がミュータブルだと「どこで何が変わったか」を追跡する必要があります。 イミュータブルな設計のほうが認知不可が下がります。 // 同じ参照をミューテート → 再レンダ/メモ化が壊れる const handleAdd = (item: Item) => { itemsRef.current.push(item) // mutate setItems(itemsRef.current) // 参照変わらず } 9 // 子で常に新しい配列 const handleAdd = (item: Item) => { setItems(prev => [...prev, item]) } Good NG
10. EXAMPLE 設計原則４ -型システム- 判別可能なユニオン型で不可能な状態を排除し、Valibot/Zodでランタイム検証を行うことで、 データの形状が常に保証されます。 // 何でも通す → 想定外の値が混入 type Consumable = { status: string }; function useConsumable(raw: any): Consumable { return { status: raw.status }; } 10 // 受け取る前にバリデーションし、型を確定 const ConsumableSchema = v.object({ status: v.picklist(['active', 'inactive']), name: v.string() }); type Consumable = v.InferOutput<typeof ConsumableSchema>; function useConsumable(raw: unknown): Consumable { return v.parse(ConsumableSchema, raw); } Good NG
11. EXAMPLE 設計原則５ -セオリー準拠- フレームワークの推奨パターンに準拠することで、コードの一貫性が保たれます。 // クラスでfetchを直書き＆DOM操作 class UserCard extends React.Component { state = { user: null } componentDidMount() { fetch('/api/user').then(r => r.json()).then(u => { this.setState({ user: u }) document.title = u.name }) } render() { return <div>{this.state.user?.name}</div> } } 11 const useUser = (id: string) => { const [user, setUser] = useState<User | null>(null) useEffect(() => { let cancel = false fetch(`/api/user/${id}`).then(r => r.json()).then(u => { if (!cancel) setUser(u) }) return () => { cancel = true } }, [id]) return user } const UserCard = ({ userId }: { userId: string }) => { const user = useUser(userId) useEffect(() => { if (user) document.title = user.name }, [user]) return user ? <div>{user.name}</div> : null } Good NG
12. AIフレンドリーなライブラリ選定
13. TECH STACK AIフレンドリーなライブラリ選定 採用ライブラリ 検討ライブラリ 選定理由 Validation Valibot Zod APIが小さく宣言的で、AI/人間とも「スキーマ→型」が単純に読め る。 Data Fetch SWR / Fetch TanStack Query 薄いAPIで書き方が揃いやすく、AI補完が安定。キャッシュ/再試行 は十分カバー。 Test Vitest / MSW Jest / nock VitestはVite互換で起動が速い。MSWはHTTPレイヤを宣言的に記 述でき、AIが意図を読み取りやすい。 Router Wouter React Router APIが少ないためコードパターンを固定化しやすく、認知負荷を抑 えられる。 13 AIの学習データに含まれ、かつシンプルで置き換え可能なものを選定しています。
14. AIのための自動テスト
15. BENEFIT 01 CIの高速化とAIとのサイクル AI駆動開発では「AI生成 → CI検証 → 失敗 → AI修正」のサイクルが遅いと開発全体のボト ルネックになります。 そのため以下を意識して、AIが自身の生成したコードを検証しやすい状態を作っています。 Integration Testの高速化 テストしやすい設計により、 Integration Test自体のチュー ニングが容易に。 フィードバックの速度 失敗時のフィードバックが速い ほど、AIは即座に学習し、修正 を行う。 AIの実装ミスを即座に検出 単体テストとCIの連携により、 AIが誤ったパターンを学習する ことを防ぐ。 15
16. BENEFIT 02 テストしやすい設計 認知負荷の低い設計は、そのままテストしやすい設計につながり品質と速度の両方を支えます。 例えば、ロジックとUIを分離することで以下のように責務を明確に分離できます。 結果: 単体で切り出して検証しやすく、AIの実装ミスも即座に検出可能。 Containerのテスト • 検証項目：「この条件のときにこういうデ ータを渡すか？」 • 手法： MSWなどでAPIをモックし、ビジネ スロジックだけ検証 Presenter (UI) のテスト • 検証項目： 「特定のPropsを渡したときに こう描画されるか？」 • 手法： Storybookやスナップショットテス トで機械的に確認 16
17. 今後について
18. CONTINUOUS EVOLUTION 継続的なコードベースの改善 現在のコードベースも完成形ではないので日々改善を行ないながら、AIを活用できる範囲をさら に広げていきます。 AI委譲の推進 現在人間が行っている軽微な修 正も自律型AIエンジニアに任せ られるようにコードベースを整 理し、効率よく任せられる構造 を追求する。 設計原則の徹底 紹介した責務分離、一貫性、薄 い依存関係などのAIフレンドリー な設計原則を守り、維持される ようにする。 普遍的な価値 AIフレンドリーな設計は、人間に とっても品質の高い設計。 どのようにしたら、人間が秩序 を守りやすいのかを考えて取り 入れていく。 18
19. FUTURE エンジニアの役割の変化 AIが解釈しやすい道を 舗装する 今後も、AIが迷わず走れるようなアーキテクチ ャとドキュメントを整備することを意識して、 開発を進めていきます。 19
20. まとめ