Next.js と Coding Agent で開発しやすい設計を目指した実践と振り返り

Next.js と Coding Agent で開発しや すい設計を目指した実践と振り返り Yuba Hiroto (@yuba_4)

自己紹介 ● ● ● ● Yuba Hiroto ソフトウェアエンジニア at 千株式会社 フロントエンドを中心にアプリケーション開発をしています 趣味 ○ 車 ○ 読書 SEN CORPORATION

話すこと ● ● ● Coding Agent に Next.js の実装を任せていく中で試した実装とかの振り 返りです MCP とかツール周りの話はしません このスライドは k1LoW/deck で作りました！ ○ markdown で Google スライドが生成されて便利 ○ k1LoW/deck の紹介とチュートリアル SEN CORPORATION

• https://github.com/k1LoW/deck
• https://www.docswell.com/s/Songmu/K137GV-about-deck#p1

経緯 ● 新規事業のプロジェクトの開発に入っていくことに ○ CTO (バックエンド Go) 僕 (フロントエンド) 業務委託 (ネイティブアプ リ) ○ CTO が Claude Code Codex を使って爆速で Go のバックエンドを 実装! ○ フロントエンド側も Coding Agent (Claude Code) を使っていくこ とに SEN CORPORATION

Coding Agent を使って速度出して開発していくぞ！ ● ● ● とはいえ速度重視でコードの品質が悪いのは 🙅 ただフロントエンドはバックエンドと比べるとコレというアプリケーション設計 もない 🤔 色々と模索していくことに SEN CORPORATION

LLM にとって扱いやすいアプリケーション構造を考える 大規模言語モデル (LLM) は、非常に大規模なデータセットを使用してコンテンツ を認識、要約、翻訳、予測、生成することができるディープラーニング アルゴリズム です。 大規模言語モデルとは? 大規模言語モデルは主に、Transformer ネットワークと 呼ばれるディープラーニング アーキテクチャのクラスを表します。Transformer モデルは、この文の単語のように、連続したデータ内の関係を追跡することで文脈 と意味を学習するニューラル ネットワークです。 NVIDIA 大規模言語モデルから引用 SEN CORPORATION

• https://www.nvidia.com/ja-jp/glossary/large-language-models/

LLM にとって扱いやすいアプリケーション構造を考える ● 自分は Coding Agent との向き合い方をこう考えました ○ データセットに多い技術スタックを扱う ○ 連続性があるファイル構造を作る ○ アプリケーションで扱う特有のコンテキストはちゃんと用意する SEN CORPORATION

技術選定は素朴に ● Next.js (App Router) ○ 2023 年リリースでナレッジやデータセットも溜まっているので採用 ● コンポーネントライブラリ shadcn/ui ● Tailwind CSS ○ ● インラインで CSS が記述されるので LLM も相性がいい React Hook Form ○ Form ライブラリとしては定番 ● 状態管理 useState useContext ● Orval ○ クライアント API の自動生成 SEN CORPORATION

データセットが少なそうな新機能はなるべく使わない ● 開発の初期段階では Server Actions や useActionState などの新機能 を試すも useFormState や既存の情報に引っ張られたり... ● ここは Deep Wiki MCP Context7 などで保管することで改善するかもし れません SEN CORPORATION

クライアント API の自動生成で API のコンテキストを渡す ● ● ● go-swagger でバックエンド側で生成した swagger.json からOrvalでク ライアントのコードを自動生成 今回は Next.js の fetch を使うので、fetch での生成を選択 tags-spilitのオプションを用いることでコードが分類されて出力されます ○ users.ts ■ getUserData()のような関数 ○ cart.ts ○ api.schemas.ts (API の型の一覧) SEN CORPORATION

• https://orval.dev/
• https://orval.dev/guides/fetch

コンポーネント構造の模索 ● 初期の開発では page.tsx その他の Component の用な形のコンポーネン ト設計をしていました ○ 方針がないと LLM が出してくる適当な実装に引っ張られるのでいい実 装パターンはないかと考えていました ○ akfm_sato さんのNext.js の考え方の Container/Presentational パターンの章を読んで、これを採用 SEN CORPORATION

• https://zenn.dev/akfm/books/nextjs-basic-principle/viewer/part_2_container_presentational_pattern

Container / Presentation パターンの実装 ● ● 以下の様な構造、ファイル名をベースに実装を進めました page.tsx (ルーティング data fetch 層) ↓ ● 〇〇 Container.tsx(ロジック層) ↓ ● 〇〇 Presentation.tsx (プレゼンテーション層) ここから Component を切り分けても OK ○ ファイル名に寄って Coding Agent がレイヤー層を認識してくれるので 実装ミスなどが起きづらい SEN CORPORATION

Container / Presentation パターンのメリット ● フロントエンドの機能ごとの責務を上から下にドリルダウンにしていくことを AGENTS.md などに明記していく ● Presentation のような層でのデータ fetch や状態の定義などの Coding Agent のミスを抑えて一定の流れの実装は任せることができるよ うになりました SEN CORPORATION

実装のプロンプト例 ● user.ts にある getUserData 関数を使って、ユーザーデータの表示を実装 してください ● page.tsx でデータフェッチを行う ● Container / Presentation パターンにしたがって AGENTS.md を確認 して実装を行うこと SEN CORPORATION

ガードレールなどの整備 ● 最低限の CI/CD の整備 ○ ESLint で console や any などのチェック ○ next build ● Gemini Claude Action でレビューを行ってもらう ● セルフレビュー SEN CORPORATION

うまくいかなかったこと ● ● テスト ○ Presentation 層のテストは制度はいいが、Container 層のロジック でうまく書けないことが多くてテストのカバレッジが落ち気味に... ○ 良い方法があれば教えて下さい バックエンドに比べて精度が急に落ちる時があるような... 🤔 ○ 存在しないライブラリを作り出したり、import ○ 急に useEffect で fetch ○ as の型キャスト ○ console.error を急に使いだす SEN CORPORATION

おわりに Coding Agent と人間の思考 ● 最近開発チームにヘルプでメンバーが入ってきました ○ 僕「実装してみてどうですか？読みにくいところとかないですか？」 ○ メンバー 「どこで何書くかわかりやすいんで、迷うとか特にないですよ！」 ○ Coding Agent にわかりやすくと考えていたけど、人間にも通ずるので は？ 🤔 ○ think tool などは人間の思考を模倣している SEN CORPORATION

AI にとってではなく人にもわか りやすい実装を考えていく 👍 SEN CORPORATION

We are Hiring! https://sencorp.co.jp/recruit-career/

• https://sencorp.co.jp/recruit-career/