🎯 背景
本プロジェクトの発端は、あるお客様からの緊急相談でした。
「納期が迫っているが、フロントエンド開発を任せられるパートナーが見つからない」という切実なご相談です。
短期間で高品質な成果を出す必要があり、通常の人力体制では間に合わない状況でした。
そこで弊社では、AIエディタ（AIコードアシスタント）を開発プロセスに導入し、Next.jsをベースに効率的なフロント構築を実現するアプローチを採用しました。
単なる「AIの導入」ではなく、ルール設計・共通化・関数単位の制御を組み合わせることで、開発速度と品質の両立を図りました。
🧭 はじめに
AIがエンジニアリングの世界を急速に変えつつある今、「AIエディタ（AIアシスタント）」の実力を現場で検証する動きが広がっています。
弊社では、2025年6月中旬〜7月末（約1.5か月）にかけて、Next.jsを用いたフロントエンド開発にAIエディタを導入し、その生産性を定量的に分析しました。
結果、従来の人力開発に比べて約12〜15倍の生産性向上という顕著な成果を確認しました。
この効率化は、人間による共通部の事前設計（型・契約・関数責務）と、AIによる関数単位の実装＋UT自動化の分業モデルによって支えられています。
📊 プロジェクト概要
| 項目 | 内容 |
|---|---|
| 期間 | 2025年6月中旬〜7月末（約1.5か月） |
| 開発体制 | 合計19.5人月（6月：2.9人月、7月：16.6人月） |
| 主な技術 | Next.js / TypeScript / scss / AIエディタ支援開発 |
| 評価指標 | ソースコード行数（LoC: Lines of Code）による人月あたりの生産性比較 |
プロジェクト期間全体のうち、約半分以上は設計工程に充てられており、実際の実装期間は1か月未満でした。
つまり、今回の成果（約12〜15倍の生産性）は、実質的に短期間の実装でも達成された点に特徴があります。
この設計フェーズでは、共通部の構造整理・cursor.rulesの定義・プロンプト雛形の整備など、AIが最大限に機能するための文脈設計に注力。
その準備期間があったからこそ、実装開始後のAI生成速度が爆発的に向上しました。
🧱 開発スタイルとAI活用ガイドライン
cursor.rules を中核としたプロジェクト設計
AIエディタをチーム開発に組み込むため、最初にリポジトリ構成と cursor.rulesを整備しました。これにより、AIが「どの階層で」「どの粒度まで」実装すべきかを理解できるようにしました。さらに、他のAIエディタでも再利用しやすいように、ルール定義の統一化・共有化を方針として進めています（ツール差は変換テンプレートで吸収）。
📂 リポジトリのフォルダ構成（例）
src/
├─ components/ … 再利用可能なUIコンポーネント群
├─ features/ … 機能単位モジュール
├─ app/ … App Routerを使用
├─ hooks/ … カスタムフック
├─ utils/ … 汎用ロジック・型ユーティリティ
├─ lib/ … 共通ユーティリティ（計算・日付・検証など）
├─ services/ … APIクライアント／キャッシュ処理
├─ types/ … 共通型・スキーマ定義
├─ errors/ … 例外型とハンドリング規約
├─ tests/ … Jest/Testing Library によるUT
└─ styles/ … scss設定とグローバルCSS
.cursor/rules/ … プロジェクトのCursorルール設定
cursor.rulesには各フォルダの役割・依存関係・責務境界を記述し、AIに対して以下の開発粒度ルールを明示しました。
- コンポーネント単位：Props設計・UI構造・a11yをAI実装
- 機能単位（feature）：状態管理・データ取得ロジックをAI生成
- アプリ単位：人間が設計し、AIが骨格を自動展開
プロンプト雛形と開発ガイドライン
プロジェクト開始時に、Cursorへのプロンプト雛形（Prompt Template）をチーム共通フォーマットとして整備。
AIが理解しやすい「入出力の契約」形式で提示し、生成の再現性と品質を高めました。
【目的】 UI構築またはAPI呼び出し処理の実装（Next.js + TypeScript） 【制約】 - 共通ルール（.cursor/rules/*.mdc）に準拠 - 型安全性（strictモード）を維持 - 生成範囲は指定ファイルパスのみに限定 【出力】 - Next.jsコンポーネントまたは関数ファイル - UT（Testing Library）
共通部の人間設計 × 関数単位のAI実装
UIや機能の実装前に、人間が共通部（Common Layer）を設計・整流化。これにより、AIは関数単位で安全かつ一貫性のあるコード生成に集中できます。
| 領域 | 人間（設計） | AI（実装） |
|---|---|---|
| 型・契約 | ドメイン型／I/Oスキーマの確定 | 型に準拠した関数・フックの生成 |
| 関数設計 | 責務・副作用・エラー規約を定義 | 関数本体の実装とUT生成 |
| 依存関係 | 利用可ライブラリ／禁止事項の明記 | 規約内での呼び出し・ラップ処理 |
🔒 実際のプロンプト雛形（マスク済み公開版）
以下は、実際のプロジェクトでAIエディタ（Cursorなど）に指示したプロンプトの一例です。
顧客固有の機能名やパス、IDなどはマスクし、構成と考え方のみを一般化しています。
【関数名】XXXXCheck
以下の仕様に基づいて、Next.js（TypeScript）で関数を実装してください。
---
■ 機能概要：
特定の条件に基づいて状態を検証するAPIのPOST関数を呼び出す
---
■ 関連情報（※プロジェクト固有情報をマスク）：
- 機能名：XXXX管理
- 機能ID：XXXX00001
- 関数名：XXXXCheck
- HTTPメソッド：POST
---
■ ファイル構成：
- 実装ファイルパス：src/features/XXXX/shared/api/XXXXCheck.ts
- 呼び出しAPI：XXXX/XXXX_check
- API型定義ファイル：src/features/shared/types/XXXXXXXX/XXXX/api.ts
---
■ 実装ルール：
- 共通ルール（`.cursor/rules/*.mdc`）に従って実装すること
- Next.js（App Router）環境を前提とすること
- 指定パス以外のファイルは生成しないこと
- TypeScriptを使用し、any型は使用禁止
- API型定義が存在する場合は必ず利用すること
---
■ 単体テスト（UT）：
- この関数のUTも併せて実装すること
- テスト方針・設計は共通ルール内の「UT実装ガイドライン」に従うこと
🧪 UT（単体テスト）のAI自動実装
テストもAIに自動生成させ、Jest/Testing Libraryを用いてUIごとにUTを同時作成しました。以下の方針を統一しています。
- レンダリング/アクセシビリティ検証（role/name、キーボード操作）
- 主要分岐の網羅（Props/状態/例外）
- スナップショットは最小限、振る舞い中心の検証へ
注記： 本記事の 総コード行数（LoC） には、UT（単体テスト）実装分も含まれています。UIコードのみの指標よりも、実務に近い総合的な生産性指標として解釈できます。
⚙️ 成果データ：AI支援による圧倒的な生産性
| 指標 | 実績値 |
|---|---|
| 総コード行数（実装分） | 453,021行 |
| 実稼働人月 | 19.5人月 |
| 平均LoC / 人月 | 約23,232行／人月 |
一般的な人力開発（1,500〜2,000行／人月）と比較すると、約12〜15倍のスピードで開発が進行しました。
※算出根拠：23,232 ÷ 1,500 = 15.5倍、23,232 ÷ 2,000 = 11.6倍 → 表現は「約12〜15倍」
とりわけ、実装期間が全体の半分以下（1か月未満）であったにも関わらずこの成果に至った点は、AI支援が限られた時間内で高密度なアウトプットを可能にすることを示す実例です。
💡 考察と今後の展望
- 高密度なアウトプット：短期間で膨大なUI・テストコードを実現
- プロセス整備の効果：共通部の人間設計、粒度規約、プロンプト雛形が生成精度を支えた
- 次の焦点：コード品質・保守性・重複検知・リファクタ頻度の定量分析
🏁 まとめ
AIエディタを活用したフロントエンド開発は、従来比約12〜15倍の生産性を記録しました。
成功の鍵は、明確なルール設計・共通化・関数単位のプロンプト制御という人間側の設計力にあります。
今後もMKDTグループは、AIと人間の最適な協働モデルを追求し、クライアントの課題解決に貢献していきます。
✍️ 編集後記
AIは「人間の代替」ではなく「能力拡張」である。
構造を与え、文脈を設計するほど、AIは的確に動く。
本プロジェクトは「AIを正しく使いこなすチーム設計」の重要性を示す実例となりました。
🪄 キーワード
Next.js, TypeScript, フロントエンド開発, cursor, ルール統一, 共通部設計, 関数単位実装, プロンプト設計, 納期対応, AIエディタ, 生産性向上, MKDTグループ
