20260528_FE_Yatai.pdf

Transcript

1. AI を活用して、 本当に効率化されていますか？ tom-chiba / Gaji-Labo Inc.
2. tom-chiba フロントエンドエンジニア X @tom_chiba_1 最近 テニスにハマっています 好きなゲーム ドラゴンクエスト 所属 フロントエンド開発と UI デザインで、 スタートアップのプロダクト開発に伴走する会社です。 www.gaji.jp 01 / 08
3. 02 / 08
4. こう思うことありませんか？ AI と何往復もして、 自分で書いた方が早いのでは？ 書く量は減ったはずなのに、 「直して」 「違うそうじゃない」が続いて、 思ったほど速くなっていない。 03 / 08
5. なぜ、こんなに往復することになるのか？ 設計レイヤーを自分が握れていないまま、 AI に丸投げしていたから。 今日の主役は、この握るべき「設計レイヤー」の話です。 04 / 08
6. 機能をひとつ実装するときの、開発フローを思い浮かべる。 AI で、もう一段レイヤーが増えた。 それを持つのは、人間。 01 調査 AI 任せる 既存パターン・前例・API の調 査は、AI がかなりの精度でこ なせる。 02 設計 人間 握る プロジェクト固有の思想が乗 る。AI 任せにすると、怪しい ケースが多い。 03 実装 AI 任せる 設計が固まっていれば、コー ド化は AI の得意領域。 04 検証 人間 握る 最終的に責任を取れるのは人 間だけ。AI に任せきりにはで きない。 設計 → 実装　／　人間 → AI AI が読み取りやすい形に整える 抽象化レイヤー 実装 → 検証　／　AI → 人間 人間がレビューしやすい形にま とめる抽象化レイヤー AI で増えた「新しい一段」は、工程の境界に現れる。 人間が握るべき設計と検証の前後で、AI との受け渡し用のレイヤーをどう設計するかが、これからの仕事になる。 05 / 08
7. あの『境界のレイヤー』 、どう作るか？ 長い日本語より、 AI が熟知している言葉でやり取りする。 人間 → AI、AI → 人間。境界のレイヤーを双方向で交わすプロトコル。 ここで効くのが、AI が熟知している技術用語と原則・パターン。 単一責任の原則 関心の分離 コロケーション 純粋関数 SSOT Adapter パターン Container / Presentational Composition over Inheritance Compound Components Render props カスタムフック DI Server Component 境界 Suspense boundary Error Boundary BFF 06 / 08
8. 同じ AI でも、 渡す言葉で品質はかなり変わる。 日本語の仕様で渡す Before 「ユーザー一覧画面を作って。 - データを取得して表で表示 - ローディングとエラー状態を出して - 検索もできるように - スタイルも整えて」 200 行の useEffect + useState fetch も view も同居 レビューで全部読む羽目に 設計原則で渡す After 「ユーザー一覧画面を作って。 - データ取得は Server Component で - 一覧と検索は別コンポーネント（SRP） - 状態は URL searchParams に集約（SSOT） - 取得層は Adapter 経由で差し替え可能に」 責務が分離されたコードが返ってくる テスタブル、レビューも一瞬 変えたのは抽象度だけ。設計の言葉で渡せれば、レビュー コストもトークン消費も往復回数も、まとめて下がる。 07 / 08
9. まとめ 抽象化レイヤーを意識する。 設計の語彙を磨く。 AI で速くなる理由を、自分の言葉で説明できるか。 AI が書いたコードを読むかどうかは、いろんな意見がある。けれど、自分の中で理解し、納 得し、説明できる状態でいることは欠かせない。 それを支えるのが、AI が熟知している設計・原則・語彙の勉強。 08 / 08
10. Appendix
11. そんなに AI に任せて、本当に大丈夫？ AI は確率的。 でも、人間も。 AI 同じプロンプトでも、結果がブレる。 人間 同じ仕様でも、書くたびにブレる。 調査や実装は、現状 AI のほうが人間より精度が高いことも多い。だから、堂々と任せたほうがいい。 ただし、AI に限らず、どんな技術も最終的な責任は「使う側」にある。 責任が取れる範囲で、AI に任せる。 Appendix
12. Gaji-Labo www.gaji.jp tom-chiba on X x.com/tom_chiba_1 Appendix