
Next.js のアプリに AI でコードをかかせる小さなコツ
Claude 3.5 あたりから AI を利用したコーディングの波が大きくなり、エディター統合を本格的に検討しました。
私の主な担当領域はフロントエンドなので、そこで使えるかどうかというのが重要な要素です。その面での検証はあまり社内で話題に上がっていなかったので試してみました。Figma MCP がないタイミングだったのでデザインの仔細を伝えるのは難しく、自由に実装させるとユーザーインタラクションがあらぬところに現れたりして難儀でした。
また、shadcn のコンポーネントを利用するように頼んでも自前で実装したり上書きしたりと暴走が激しく断念しました。
ただ時が経つにつれてモデルの性能自体が大きく改善されて、gpt-5-codex high や Sonnet 4.5 という十分な性能を発揮できるものが登場しました。その上で、Chrome DevTools やPlaywright、Storybook、Figma の MCP が登場して AI に対しての入力も、実装後のフィードバックもかなりしやすくなりました。
まだまだ制約はありますが、開発に取り入れられる水準に達したと思います。なのでどのようにすれば素早くうまいものが作れるかを個人的に考えてまとめてみました。
前提条件
新規で作成する小〜中規模なアプリケーションを想定しています。
UI ライブラリをつかう
AI に対する指示は UI コンポーネントの組み合わせになります。つまり、フォームを実装するとしたら input や label、button などに対してスタイリングを施したコンポーネントを事前に用意しておく必要があります。今後の拡張性や既存のデザインが使いやすいことから shadcn を推奨します。理由は、TypeScript との親和性が高く、カスタマイズが容易で、コミュニティサポートも充実しているためです。既存開発でコンポーネントがあったり開発工数が膨らむことを許容できるのであれば自前で実装することも可能です。
つまり画面設計を UI コンポーネントの配置でできるようにすることが肝心です。Figma MCP でコードを起こすこともできるようにはなっています。
CSS の精度だったり、汎用性に欠けるコンポーネントの実装などをするため、まだコード品質は十分ではないと私は考えています。なのでやはりライブラリの導入がおすすめです。
コンポーネントを AI に自由に配置させるとなるとデザイン業務が不要に感じるかもしれません。ですが、必要な情報をどのページで出すかの設計やフォームを複数ステップに分けて認知負荷を下げる工夫など言語化できて重要な箇所はあります。しっかりとユーザー体験を設計してそこで必要となる内容をまとめることでページ全体の品質が保たれます。
Zod でスキーマを作る
フロントエンドアプリケーション実装の基本はデータの受け渡しです。API から受け取ったデータをコンポーネントが使えるような形に変換するのと、フォームで受け取った値を API に送れる形に変換するのが基本です。
不確実なデータに型をつけたり、フォームの値に間違いがあったら API リクエスト前にエラーを返せるようにするために zod は必須です。
ここまでの前提は AI とあまり関係ないですが、例えば API からのリクエストをもとにテーブルを表示したいとなったら型情報が必要です。interface でも賄えますが、Zod ならより細かい情報、例えば正の整数など、を伝えることができます。その上、メタデータも扱えるので「テーブルのヘッダー名はメタデータを参照して」のような使い方もできます。
Zod の導入自体はそこまで大変ではないので、interface を定義する代わりにスキーマを始めるのがよいと思います。また下記のようにコンパニオンオブジェクトパターンが好きです。スキーマも型も同名で扱えてスッキリします。
export const LoginFormData = z.object({
username: z.string(),
password: z.string(),
})
export type LoginFormData = z.infer<typeof LoginFormData>
MCP を設定する
フロントエンド開発では Chrome DevTools を追加しましょう。ユーザーインタラクションによってのみエラーが起きる場合に今までは伝えるのが面倒だったり難しかったのですが、ブラウザを操作してくれて DevTools をみられるのでかなり精度高く修正をしてくれます。ネットワークなども見る事ができるのでパフォーマンス改善にも活用ができます。
claude mcp add \
chrome-devtools npx chrome-devtools-mcp@latest \
-s user
ヘッドレスモードも快適です。ですが、認証が必須のページではアクセスができないので普段はヘッドレスモードを利用して、ユーザー操作が必要な場合にはブラウザを立ち上げるようにしましょう。
フロントエンドは関係ないですが、GitHub MCP もいれて PR のコメントを自動生成することで業務負担を減らせます。ただ、たまに膨大なコメントを書いてしまうので、内容を確認して不要な箇所は削り、不足部分は補足してからレビューを依頼しましょう。
claude mcp add \
--transport http \
github https://api.githubcopilot.com/mcp \
-H "Authorization: Bearer TOKEN" \
-s user
また、MCP を公開していない場合でもドキュメントを Markdown で公開している場合もあります。Next.js や shadcn などは Markdown の URL があったり Claude で開くみたいなオプションがあったりもします。活用しましょう。
AI にコーディングさせるコツ
さて実際に AI にコーディングをさせる際、どのようにして扱うか触れていきます。
Page Components は自分でつくる
いきなり AI に書かせない状態になって申し訳ないのですが、Page Components の大枠は自分で作りましょう。AI にコードを書かせるとすぐに Client Components にしたがります。極力 Server Components を利用したいのに、Page Components で "use client"
を使うのは、クライアントサイドでのバンドルサイズ増加につながるので避けたいです。
なのでページのルーティングを定義する感覚で作成します。
ここまで実装すると、AI はページの外に Client Components を作成します。その対処は後述します。
import type { Metadata } from "next";
import type { Group } from "@/features/auth/models";
import { authorization } from "@/features/auth/utils/server";
const allowedGroups: Group[] = ["admin"];
export const metadata: Metadata = {
title: "greeting",
};
export default async function Page() {
await authorization(allowedGroups);
return <div className="container px-6"></div>;
}
上記の Page Component では JWT にあるユーザーグループを利用してロールベースでのアクセス制限をかけています。そもそもログインしていなかったら、ログインページにリダイレクトし、権限がない場合は403エラーを表示します。
また div 要素に container px-6
というクラスを付与しています。container
はTailwind のクラスで、ブラウザ幅に応じて最大幅を自動調整します。 px-6
はブレイクポイントに近づいた時に画面が窮屈にならないように付与しています。ブレイクポイントや最大幅を決定していないのであればデフォルトのスタイルとして設定することをお勧めします。
Components のインタフェースを用意する
Props で何を受け取るかをまずは決めます。そして空のコンポーネントでデータを受け取れるようにします。最後に AI に中身を実装させます。
interface Props {
name: string
}
export const Greeting = ({ name }: Props) => {
return <div />
}
通常のコンポーネントを設計する場合に、UI としては 1つにカウントされるけど、状態管理をわかりやすくするためにコンポーネントを分離したいことがあります。またコンポーネント側で Server Functions でデータをフェッチしてそれを Client Components に流したいなどの要件もあります。
AI に任せると1つのファットなコンポーネントで状態を管理したり、データフェッチをそもそもクライアントサイドでやろうとしたりするので綺麗な設計からずれてしまいます。1個の UI を依頼しているので適切ではありますができれば、可読性が高く、末端でのみ状態を扱えるようにしましょう。
Temporal のあつかいを決める
日付に関する処理がある特定のライブラリで行われるのであれば、そのことを AI に伝えましょう。データフォーマットの統一を検討しているのであれば、libs
などにまとめてその関数を利用するように伝えましょう。
そうしないと Intl を使ったり、toLocaleString を使ったりすることがあるので今後のリファクタリングが大変になります。それ以外にもロガーだったり、共通化できる部分は初めに共通化してそれを伝えるのが吉です。
付録. AI にチャートを作らせてみた
それでは実際に AI にチャートを作らせてみます。既存コンポーネントと今のモデルでどこまでできるかの指標になるかと思います。
テーブルの実装とチャートの実装はコンポーネント作成で煩雑です。HTMLがそもそも、table
、thead
、tr
、td
のように、多くてしかもそれらが非常に入り組んだ構造なので頭を抱えます。
テーブルは仕事で取り組んだ際に、サンプルデータと型を用意したら意図したコンポーネントができました。なので次はチャートを作ってみます。
私が今までに書いた記事の情報を集めました。下記のようなスキーマです。これを可視化しましょう。
{
url: "https://dev.classmethod.jp/articles/amazon-cognito-with-next-sample-02/",
title: "Amplify Adapter Next.js と Cognito でログインをしてみた",
tags: ["Amazon Cognito", "Next.js", "フロントエンド"],
createdAt: "2025-09-28T15:38:34.885Z",
estimatedReadMinutes: 20,
},
それを元に、3回だけ下記のプロンプトを実行しました。
少し any アサーションや型エラーが出ているところはありますがかなり優れたものができています。
これが、shadcn と gpt-5-codex high のパワーです。
- shadcn の https://ui.shadcn.com/docs/components/chart.md を参考に data を表示する最も最適なチャートを作り表示して
- 今のチャートの下にカードでタグに関するチャートを書いてください
- この執筆者のモチベーションにつながるようなチャートをちゃーんと作って
さいごに
まだまだ制約はありますが、フロントエンドでも AI を利用した開発というのが徐々に可能になってきました。バックエンドとは異なり、明確な仕様書というのを言葉から作るというのは難しいです。なんとなく欲しい情報があって、一定の操作をしたら何かが起こるみたいなフワッとした形でしか定義できないので仕様書駆動という考え方が取り入れ難いのが現状です。
なので、コンポーネントライブラリを利用して、インタフェースの設計を手動で行い、データの型を props として渡すことで AI にかなり強い制約を課した上で活用するのが今の現実的なラインだと思います。
複雑な UI を実現することは難しいかもしれませんが、業務システム、管理画面、PoC などデザインがある程度似通っても問題ないアプリケーションであれば十分に力を発揮できると感じています。
実際に、小規模なアプリで認証機能の追加、ページ設計からコンポーネントの導入、モックでの動作を全体に渡って作成しました。4日くらいで目処がつくと思っていましたが、2日で完了したのには AI のパワーを感じました。これからも使える範囲で使っていきたいです。