昨今のAI技術の進化は目覚ましく、Web制作の現場においても「AIにコードの書き方を質問する」だけの時代は終わりを告げようとしています。いま私たちが直面しているのは、AIが自律的にツールを操作し、タスクを完遂する「AIエージェント」の時代です。
本コラムでは、当社が自社サイトの改修プロジェクトにおいて実施した、最新のAIエージェント技術
(Figma MCP, microCMS MCP, Cursor)を用いた3つの実践的検証の結果を公開します。
システム連携やコンテンツの大量生産において、AIエージェントは果たしてどこまで工数を削減できるのか。
そのリアルな実証データとノウハウをお届けしますので、ぜひ参考にご覧ください!
目次
実践1:デザインからコードへ直結 (Figma MCP)
実践1では、Figma MCPとAIエージェントを活用し、Figma上のデザインデータをもとにUIパーツを作成することで、従来の手動コーディングと比較した際の作業時間削減効果を検証します。
🔄検証の流れ

上記デザインをもとに、コンポーネント単位でUIパーツを作成し、以下の2パターンの手順でコーディングを行いました。それぞれに要した作業時間を比較します。
① 手動でコンポーネントを作成
② Figma MCPを利用してコンポーネントを作成
Webサイト制作においては、デザインデータをHTML/CSSで再現する工程が、最も工数がかかりやすい作業のひとつです。
特に、以下のような作業には多くの時間を要します。
- デザインのレイヤー構造の確認
- フォント・カラー・余白などスタイル情報の確認
- コンポーネント単位でのHTML設計
- デザインとの差分確認・調整
ここからは、Figma MCPの設定方法や手順を交えながら、Figma MCP × AIエージェントを活用した際の作業工数の削減効果と、実運用を通して得られた所感を紹介します。

Figma MCPの設定(事前準備)
Figma MCPは、AIエージェントと接続することで、コーディング時に利用することが可能です。
AIエージェントをFigma MCPに接続する手順は以下になります。
1.FigmaをDev Modeに切り替える
Figmaアプリで対象デザインを開き、「Dev Mode」に切り替えます。
2.Figma MCPを有効化
右側パネルの「MCPサーバーを有効にする」を選択します。有効化すると、アクセス用のエンドポイントが発行されます。
3.AIエージェント(Cursor)と接続
手順2で起動したMCPサーバーのエンドポイントを、をmcp.json(cursorの場合) に記述すれば、接続完了です。
{
"mcpServers": {
"Figma": {
"url": "<http://127.0.0.1:3845/mcp>"
}
}
}
4.AIエージェント(Cursor)のルール設定
Figma MCPの利用自体はルールの設定は不要です。
ただし生成される HTML/CSS の品質を安定させるためには、ルール設定は必須と考えて良いです。
---
description: "FigmaからMCPコンポーネント生成ルール"
globs: ["src/components/mcp/**/*.{tsx,ts,scss}"]
alwaysApply: true
---
# Figma MCP コード生成ルール
FigmaデザインデータからMCP(Module Component Piece)コンポーネントを生成する場合は、以下のルールに従うこと。
## 1. モジュール配置・命名
- 生成したMCPコンポーネントは必ず `src/components/mcp/` ディレクトリ以下に配置すること
- MCPコンポーネントのディレクトリ名・ファイル名は **ケバブケース(kebab-case)** を使用する
- 例: `mcp-header`, `mcp-footer`, `mcp-hero-section`
- コンポーネント名は `Mcp` プレフィックスを付けた **camelCase** とする
- 例: `McpHeader`, `McpFooter`, `McpHeroSection`
## 2. コードスタイル
- MCPコンポーネントは **TypeScript** で実装し、関数コンポーネント(camelCase)とする
- 必ずProps型を定義し、型安全性を保つこと
- Props型は `Props` とする(例: `McpHeaderProps`)
- スタイルは同階層に `styles.module.scss` としてSCSS Modulesで分離する
- コンポーネント内のクラス名も必ずキャメルケースを使用する
## 3. デザイン仕様コメント
- 各MCPコンポーネントの先頭には必ずFigmaデザインファイルのURLと名称をコメントとして記載すること
```ts
// Figma: https://www.figma.com/file/xxxxxxxx 「Header」コンポーネント
export const McpHeader = () => { ... }
```
## 4. サイズ単位の変換
- Figmaから取得したpx値は、**remに変換して**SCSSに記述する
- 変換計算: `px値 ÷ 10 = rem値`(10px = 1rem)
- 変換したrem値には、元のpx値をコメントで記載する
- 詳細は `styling-units.mdc` を参照
## 5. 画像・アセット取扱
- 画像は `src/assets/` 以下に配置し、WebP形式への変換を優先する
- 画像利用時は `` タグと `type="image/webp"` 属性を使用し、`
` タグの単独使用は避ける
## 5-1. SVGアイコンのサイズ指定
- SVGアイコンのサイズは、**Figmaから取得したサイズを正確にremに変換して適用すること**
- Figmaのデザインから取得したアイコンのサイズ情報(width、height)を必ず確認し、その値をremに変換して指定する
- `mask-image`を使用する場合、親要素のサイズをFigmaから取得したサイズに正確に設定すること
- アイコンのサイズは親要素の`100%`ではなく、Figmaから取得した実際のサイズ(px値をremに変換)を指定すること
- Figmaのデザインから取得したアイコンのサイズ情報をコメントで明記すること
- 例:
```scss
.icon {
width: 1.7rem; /* 17px / 10 - Figmaから取得したサイズ */
height: 1.7rem; /* 17px / 10 - Figmaから取得したサイズ */
-webkit-mask-image: url('/assets/img/icon/icon_outlink.svg');
mask-image: url('/assets/img/icon/icon_outlink.svg');
}
```
## 6. その他
- figma上でvariant名に `hover`、`mouseover`、`focus`、`focus-visible` を含むものはコンポーネントのvariantとして追加しない
- これらのvariantは、CSSの`:hover`、`:focus`、`:focus-visible`などの疑似クラスとして実装すること
- 例: Figma上に`hover`というvariantがある場合、TypeScriptのPropsには追加せず、SCSSで`.component:hover`としてスタイルを定義する
- figma上のコンポーネントでvariantがdefaultに設定されてるインタラクションを他のvariantにも付与する。
- 共通UI部品化できる場合は `src/components/` 配下で通常の再利用コンポーネントとして切り出して利用すること
- コード生成時はこのルールを厳密に順守し、命名揺れや記法不統一を防ぐこと
Figma MCPを利用する手順
Figma MCPを利用した実際のコーディングフローは、以下の通りです。
- 作成したいコンポーネントを選択しリンクをコピー
- AIエージェントに 対象コンポーネントのFigmaリンクを含むプロンプトを送信
- AIエージェントがデザインコンテキストを取得(get_design_context)
- フォント・カラー・余白・レイアウト情報を抽出(get_screenshot)
- AIエージェントがHTML/CSS を自動生成
- デザインとの差分を微調整
従来の手動コーディングと比較すると、Figma MCPの導入によって、作業者がデザインを確認・読み取る工程が大きく削減されていることが分かります。
コンポーネント別 工数削減結果
実際に自社サイトのUIコンポーネント(モジュール)を作成する工数を、Figma MCP導入前後で比較してみました。
| コンポーネント | 手動 | MCP利用後 | 削減時間 |
|---|---|---|---|
| ヘッダー(見た目のみ) | 約90分 | 約60分 | 30分 |
| タイトル | 約20分 | 約5分 | 15分 |
| ボタン | 約30分 | 約15分 | 15分 |
| テキスト | 約10分 | 約5分 | 5分 |
| リスト | 約60分 | 約20分 | 40分 |
| 合計 | 約205分 | 約115分 | 90分(約44%削減) |
上記から分かるように、シンプルなコンポーネントほど削減時間が大きい傾向が見られました。
Webサイト制作において、コンポーネントの多くはシンプルな要素で構成されています。
そのため、ボタンやタイトルといった一見単純な要素であっても、積み重なることで意外と多くの作業時間を要します。今回の検証では、こうしたシンプルなコンポーネントの工数を大きく削減できた点は、非常にポジティブな結果だと言えます。
また、ヘッダーのように構造がやや複雑なコンポーネントについても、一定の工数削減が確認できました。
Figma MCP × AIエージェントによって生成されるHTML/CSSは実用的なクオリティを備えており、微調整にかかる時間も想定より少なく済んだ印象です。
Figma MCPを活用してみて分かったデザイン連携のポイント
今回の検証を通して、デザインと実装をつなぐ連携プロセスの効率化において非常に有効であることが確認できました。
特に、Figma上のデザインデータをコンテキストとして直接活用できる点は、実装時の判断や確認作業を大きく減らす要因となっています。
また、デザインルールをFigma上で明確に定義し、データ構造を整理しておくことで、
デザイン連携の精度が高まり、結果として工数削減効果がさらに期待できることも分かりました。
改善点・より効果を高めるためのポイント
Figma MCPを活用したコーディング効率をさらに高めるには、生成されるコンポーネントの品質を向上させることが重要です。
コンポーネントの品質が高まることで、最終的な微調整にかかる時間を大きく削減できます。
そのための具体的なポイントは、以下の通りです。
実践2:システム連携の自動化 (microCMS MCP)
実践2では、システム連携の自動化をテーマに、microCMS MCPを用いた検証を行います。
microCMS MCPは、ヘッドレスCMSであるmicroCMSと開発環境(Cursor)を直接接続し、microCMSの構造理解や管理画面上の操作を、AIが行えるようにする仕組みです。
従来の開発では、エンジニアが管理画面とエディタを行き来しながら手動で型定義を行い、APIドキュメントを参照しつつデータ取得処理を実装するのが一般的でした。
しかし、MCPを導入することで、AIがmicroCMSのスキーマ(設計情報)を直接解析できるようになります。
これにより、「API仕様の確認」「TypeScriptの型定義」「データ取得ロジックの実装」といった一連の繋ぎ込み作業からテストまでを、AIとの対話だけで完結させることが可能になります。
今回は、実案件を想定し、microCMS MCPのセットアップからテストまでの一連の流れを紹介します。
🔄検証の流れ
- microCMS MCPのセットアップ
- MCPを活用したmicroCMS APIの繋ぎ込み
- MCPを活用したmicroCMSへのテストデータ入稿

1. microCMS MCPのセットアップ
CursorがmicroCMS MCPを使用できるよう、事前にセットアップを行います。
MCPサーバーの導入(ダウンロード)
公式のリリースページから microcms-mcp-server をダウンロードする、もしくは npx @microcms/mcp-server コマンドを使用して、CursorとmicroCMSを仲介するサーバープログラムをシステム内に用意します。
Cursorへの登録と認証
①Cursorの設定(Features > MCP)に、導入したサーバーを追加します。
②その際、microCMSから発行した「サービスドメイン」と「APIキー(書き込み権限のあるマネジメントAPIキーを推奨)」を環境変数として設定し、CursorにCMSの操作権限を付与します。
microCMS MCPの詳細なセットアップ方法については、公式ページをご参照ください。
[MicroCMS公式ページ] :セットアップ手順について
2. APIの繋ぎ込み
人手による定義作業を排除し、AIがmicroCMSのスキーマを直接解析・実装する工程です。
スキーマの自動解析と型定義
①各エンドポイントの定義情報を取得します。
②Cursorがその場で、最新のスキーマに完全に準拠した TypeScriptの interface(型定義) を出力し、.ts ファイルとして保存します。
microCMSから利用可能なすべてのAPI構造をスキャンしてください。
その情報を元に、現在のプロジェクトの types/microcms.ts(※保存先は任意)に、すべてのエンドポイントに対応するTypeScriptの型定義ファイルを生成してください。
特に「繰り返しフィールド」や「カスタムオブジェクト」が含まれる場合は、それらもネストされた型として正確に定義してください。
③ページコンポーネントへの統合します。
取得したデータを表示するための JSX/TSX 構造を、スキーマのフィールド名と一致させて自動的に組み込みます。
microCMS MCPを使って news エンドポイントのスキーマを確認してください。
その内容を元に、Next.js(またはNuxt)のニュース詳細ページ pages/news/[id].tsx を作成してください。
3. テスト
テスト工程では、「データ駆動」のテストをAIで完結させます。
テストデータの自動入稿
①定義されたフィールドの型(リッチエディタ、繰り返しフィールド等)に合わせた適切なテストデータを microCMS へ直接流し込みます。
②「空文字」「長文」「画像なし」などのパターンをAIに網羅させます。
microCMS MCPを使用して、[ここにエンドポイント名を記入] のスキーマを解析し、以下の5つの検証パターンを網羅する合計12件のテストデータを一括で入稿してください。
入稿すべき5つの検証パターン:
【極端な長文(表示崩れ確認用)】×2件
タイトル:100文字以上の超長文。
本文:数千文字のリッチエディタ。
目的:三点リーダー処理やレイアウトの突き抜けが発生しないか確認。
【最小構成(未入力・画像なし確認用)】×2件
必須項目のみ入力し、任意項目(画像、サブタイトル、タグ等)はすべて空にする。
目的:null や undefined によるフロントエンドのエラー(Cannot read property...)を防ぐ。
【特殊文字・HTML(セキュリティ確認用)】×2件
項目内に <b>太字</b> や <script> などのタグ、および & < > " ' などの特殊文字を含める。
目的:エスケープ処理が正しく行われ、意図しないタグが実行されないか確認。
【画像バリエーション(メディア確認用)】×2件
縦に非常に長い画像、横に非常に長い画像、透過PNGなど異なるアスペクト比を設定。
目的:object-fit やアスペクト比の固定が正しく機能しているか確認。
【ページネーション検証(バルク投入)】×4件
通常のデータを日付を1日ずつずらして作成。
目的:合計12件にすることで、10件/1ページなどのページネーション表示が正しく動くか確認。
実行ルール:
・@types/microcms.ts(型定義ファイル)がある場合は、その型に完全に準拠させてください。
・MCPの create_content をループ、またはバッチ処理で実行してください。
・すべての入稿が完了したら、入稿した記事のタイトル一覧を表示してください。
4. プレビューと修正の自動ループ
①入稿したデータを元に画面をレンダリングし、不備があれば Cursor の Composer モードでコードを即時修正します。
②必要に応じて、CMS側のスキーマ設定の変更提案までをAIが行います。
先ほど入稿したテストデータを表示したところ、以下の不備が見つかりました。修正してください。
[不備を記載]
運用フェーズにおける応用例
運用フェーズにおいては、これまでに紹介した内容以外にも、MCP経由で実行できる高度な活用案があります。
活用項目 | 内容 |
|---|---|
コンテンツ一括操作 | 条件に合致する既存記事(例:特定のカテゴリ)のデータを一括で置換・更新する。 |
スキーマのマイグレーション | 新機能追加に伴うフィールドの追加や、古いフィールドから新しいフィールドへのデータ移行スクリプトを実行。 |
多言語翻訳の自動化 | 日本語フィールドの内容を翻訳し、対応する英語用フィールドへ自動的に入稿する。 |
コンテンツの定期メンテナンス | 過去1年間更新されていない製品ページ一覧を取得する。 |
工数比較(API 1本あたりの目安)
API(管理区分)1つあたりにおいて従来の手法とMCPを活用した場合の工数を比較しました。
| 工程 | 従来の手法(手動) | MCP活用(AI自動化) | 削減率 |
|---|---|---|---|
| スキーマ確認 | 管理画面とドキュメントを往復 (15分) | 不要(AIが直接取得) | 100% |
| 型定義の作成 | TypeScriptのinterfaceを手書き (20分) | AIが瞬時に生成 (1分) | 95% |
| 繋ぎ込み実装 | Fetch関数の記述・データ加工 (30分) | 既存コードに合わせ自動生成 (5分) | 83% |
| テストデータ準備 | 手動で管理画面から入稿 (15分) | AIが適切な値を自動入稿 (3分) | 87% |
| 合計 | 約80分 | 約8分 | 約90% |
microCMS MCPを活用してみて分かったシステム連携のポイント
microCMS MCPの導入によって、開発のあり方そのものを「ドキュメントを読み、手動でコードを書く作業」から「AIと対話しながら仕様を反映させるプロセス」へと進化していくことを実感しました。
以下では、実際に活用してみて分かったポイントを整理します。
🚀開発スピードの向上
これまでエンジニアが手作業で行っていた
スキーマの確認、TypeScriptの型定義、データ取得ロジックの実装といった工程の多くを
AIが代行することで、API1本あたりの作業時間を大幅に短縮できます。
✅「手作業」ゆえのミスを軽減
AIが直接CMSの設計図(スキーマ)を読み取ってコードを生成するため、フィールド名のタイポや型定義の不整合といった、人間が介在することで発生していたイージーミスを構造的に排除できます。
📋テストの質と網羅性の担保
「長文での表示崩れ」や「画像がない場合の挙動」など、後回しにされがちなケースについても、AIへの指示一つでテストデータを一括入稿できるため、テストの網羅性を自然に高められる点も大きなメリットです。
改善点・注意点
CMSをAIによって操作することができる非常に便利なmicroCMS MCPですが、いくつか注意点や課題があるので注意して使っていくことを推奨します。
実践3:コンテンツの大量生産・投入(Cursor)
実践3では、AIを活用したコンテンツの大量生産・投入方法をご紹介します。
手動のコピー&ペースト作業を排除し、AIが「クローラー」と「コーダー」の二役を担う、新しいデータ投入のアプローチです。
より実務に活用できるよう、実際のサイトリニューアル案件を想定し、現行サイトから新サイトへのデータ移行を題材に、旧サイトのデータ取得から、新サイトのデザイン・構造に沿ったマークアップまでを一連の流れとして解説します。
💡AIを活用したコンテンツ投入のポイント
エージェントモードの活用
CursorのComposer(Agentモード)は、指定したURLに直接アクセスし、その中身を読み取ることができるため、ブラウザとエディタを行き来する必要がなくなり、作業の手間を大幅に削減できます。
コードベースへの即時適合
単にテキストを抽出するだけでなく、現在開発中のプロジェクトで使用しているCSS設計(Tailwind CSSのクラスなど)やコンポーネント設計をAIが自動で考慮し、違和感のないコードとして出力します。
サイトリニューアルに適した設計
旧コーポレートサイトから新サイトへのデータ移行では、新旧サイトでデザインシステムが異なるケースが多く発生します。
この手法では、その差分をAIが“翻訳”する役割を担うことで、移行時の調整工数を大幅に削減できます。
コンテンツ投入フロー
1.コンテンツ複製
「URLリスト」を渡すだけで、自動でページが量産されるパイプラインを構築します。
- インプット(URLリストの提供): 移行対象となる旧サイトのURL一覧をCursorに渡し、「これらのページを一つずつ読み取って、現在のサイト構成で再現して」と指示します。
- 解析と整形: Cursorが各URLから「タイトル」「本文」「画像」「メタデータ」を抽出。それを新しいReact/VueコンポーネントのPropsやHTML構造に合致するよう整形します。
- ファイルの一括生成: 整形されたデータを元に、.tsx や .vue ファイルをプロジェクトの適切なディレクトリに直接書き出します。
💡 さらに精度を高めるための Tips: Project Rules の活用
Cursorの Project Rulesに以下を定義しておくと、量産の精度が向上します。
- 命名規則の定義:「新しいページファイルは kebab-case で命名し、特定ディレクトリ配下に配置すること」といったルールを徹底させます。
- 使用禁止タグの指定:「既存の <table> は使わず、自作の DataGrid コンポーネントに変換すること」などの具体的な制約を与えることで、修正の手間を最小限にします。
- SEOルールの固定:全ての新規ページに共通のメタタグ構造や、Alt属性の必須化をルール化できます。
---
description: サイトリニューアルおよびコンテンツ大量生産(データ移行・新規作成)に関する総合ルール
globs: **/*
---
# コンテンツ大量生産・移行ガイドライン
## 1. エージェントの動作フロー(Agent Mode Only)
URLリストや旧サイトの情報を元にコンテンツを生成する際、Agentは以下のステップを順守すること。
1. **情報の取得**: 指定されたURL(またはファイル)から、タイトル、本文、メタデータ、画像を抽出する。
2. **構造解析**: 現在のプロジェクトのコンポーネント設計(React/Vue)やスキーマ(Nuxt Content等)を読み取る。
3. **データ整形**: 抽出した情報を、現在のプロジェクトの規約に適合するように変換する。
4. **ファイル生成**: 正しい命名規則とディレクトリ構造でファイルを新規作成する。
## 2. ディレクトリ構造と命名規則
- **ページファイル**:
- すべてのサービス関連ページは `src/pages/services/` 以下に配置すること。
- ファイル名は必ず **kebab-case** とすること(例: `cloud-migration-service.tsx`)。
- **Nuxt Content活用時**:
- 効率的な運用のためにMarkdownで投入する場合は `content/services/` ディレクトリに `.md` 形式で保存すること。
- フロントマター(YAMLヘッダー)には、`title`, `description`, `date`, `category` を必ず含めること。
## 3. コンポーネント変換・技術制約
旧サイトの古いHTMLをそのまま持ち込まず、以下のモダンコンポーネントに必ず変換すること。
- **テーブル要素の禁止**:
- `table`, `tr`, `td` タグは使用禁止。
- 代わりに自作コンポーネント `@/components/ui/DataGrid` を使用し、データをPropsとして渡すこと。
- **画像要素の最適化**:
- `
` タグは使用せず、`@/components/ui/AppImage` または Next.js/Nuxt の最適化画像コンポーネントを使用すること。
- すべての画像には、文脈に応じた適切な **Alt属性** を必ず付与すること。
## 4. SEO・品質管理ルール
- **メタタグの自動生成**:
- `title`: 旧サイトのタイトルを尊重しつつ、プロジェクトの接尾辞(例: | 株式会社〇〇)を付与。
- `description`: 記事冒頭から120文字程度を抽出し、SEOに最適な要約を作成してメタタグに挿入。
- **リンクの整合性**:
- 内部リンクが旧サイトのドメインを含んでいる場合は、新サイトの相対パス(例: `/services/abc`)に自動置換すること。
## 5. テスト・バリデーション
一括投入後は、以下の「表示確認用ケース」を考慮したデータが1件以上含まれているか自律的にチェックすること。
- タイトルが極端に長い(100文字以上)場合のレイアウト崩れがないか。
- 画像がない場合でもデザインが崩れず、プレースホルダーが表示されるか。
2.Nuxt Content を使用しさらに効率的な投入
ページの量産を「コード(.vueファイル)」ではなく「データ(.mdファイル)」で行うことで、保守性と柔軟性を両立させます。
- データの軽量化と高速投入:
- ページごとに複雑なコンポーネントファイルを生成するのではなく、本文データをMarkdown(.md)として書き出します。
- CursorにとってMarkdownは構造がシンプルで扱いやすいため、生成速度が向上し、ミスも少なくなります。
- 「運用」を見据えた設計:
- Nuxt Content(またはAstro Content等)を採用することで、移行後のちょっとした文言修正は、エンジニア以外でもMarkdownを触るだけで完結できるようになります。
- フロントエンドとの分離:
- デザイン(Vueコンポーネント)と中身(Markdown)が分かれているため、将来的にデザインを再度刷新する場合も、今回Cursorで生成したコンテンツ資産(Markdown群)をそのまま再利用できるという大きなメリットがあります。
サイト規模や複雑性にもよりますが、結論から述べると、API連携フェーズで約80%、コンテンツ移行フェーズで約90%以上の工数削減が期待できます。
工数比較(100ページの移行を想定)
| 項目 | 従来の手法(コピー&ペースト) | Cursor Agent(自動量産) | 削減効果 |
|---|---|---|---|
| 作業内容 | URLを開く → コピー → 新サイト用に整形 → 保存 | URLリストを渡し、AIが全自動で巡回・ファイル作成 | - |
| 1ページ辺り | 15〜20分 | 約1〜2分(AIの処理時間) | - |
| 総工数 | 約25〜33時間(約4日) | 約2〜3時間(半日以下) | 90% |
| 人的ミス | リンク切れや貼り付けミスが発生しやすい | プロジェクトルールに基づき一貫性を保持 | ミスを大幅に低減 |
Cursorを利用してみて
今回の手法を導入することで、これまで数週間かかっていた大規模なサイト移行やコンテンツ投入を、わずか数日に短縮することが可能になります。
- Cursor Composer(Agentモード) を使って、ブラウザとエディタの壁を取り払う。
- Project Rules を定義して、プロジェクト独自の「型」にAIを適応させる。
- Nuxt Content など仕組みを使い、運用の柔軟性を確保する。
これからの開発者は、一字一句コードを書く「作業者」から、
AIに指示を与え、その品質を保証する役割へと変わっていくと考えています。
この変化を味方につけ、より価値の高い開発に注力していきたいと考えます。
改善点・注意点
AIエージェントによるデータ移行・コンテンツ量産は非常に強力ですが、以下のポイントを理解し、適切に管理する必要があります。
総合成果:AIエージェント活用の実力値
今回の3つの実証実験を通じて得られた成果を総括します。
1. 圧倒的な工数削減(定量評価)
- UIコーディング: 平均して約40〜50%の工数削減。特に単純コンポーネントの量産において効果大。
- システム連携: API連携や型定義において約90%の工数削減。
- データ移行: 旧サイトからの移行作業において約90%の工数削減。
2. 品質の安定化と役割の変化(定性評価)
- 人的ミスの排除: スペルミス、型定義の不一致、コピペミスといったケアレスミスがほぼゼロになりました。
- スタイルの統一: Project Rulesを徹底することで、複数人で作業してもコードの書き方やクラスの命名規則が統一されます。
- エンジニアのリソースシフト: 単純な記述作業から解放され、より本質的な「設計」「UX改善」「複雑なロジックの実装」に時間を使えるようになりました。
考察・まとめ:Web制作は「書く」から「指揮する」へ
今回の検証から明確になったのは、Web制作におけるエンジニアの役割が
「コードを書く作業者」から「AIを指揮し、品質を保証する監督者」へと変化しているという事実です。
AIエージェントは、私たちが与えたコンテキスト(設計図やルール)が正確であればあるほど、驚異的なパフォーマンスを発揮します。逆に言えば、人間側にはこれまで以上に
「明確な設計能力」や「言語化能力」が求められるようになると言えます。
当社では今後も研究を重ねながら、AIエージェント技術を自社サイトだけでなく、クライアントワークにも積極的に取り入れていきます。
AIの「圧倒的なスピード」と、専門家による「確かな品質管理」を掛け合わせることで、多様なプロジェクトにおいて、高品質かつ短納期を両立した次世代のWeb制作が実現できると確信しているからです。
最新技術を活用したWeb制作のご相談はぜひ当社へ
企業のWeb担当者様・新規事業ご担当者様へ
最新のAI技術を取り入れ、
スピードと品質の両立を重視したWebサイト構築・リニューアルのご要望も増えています。
「短納期・コストを抑えた高品質なサイトを立ち上げたい」
「AIを活用して効率的にサイトを運用したい」
「大量のコンテンツ移行を、できるだけ効率よく進めたい」
このような課題をお持ちのご担当者様は、ぜひ一度マイクロウェーブクリエイティブまでご相談ください!
AIを活用したプロトタイプ制作(MVP開発)のご相談も承っております。
エンジニアの方へ
マイクロウェーブクリエイティブのエンジニアチームは、AIエージェントやMCPといった最新技術を、実験的にではなく「実戦」で使いこなすチームです。
AIと共に進化する開発に挑戦したい、開発のあり方そのものをアップデートしたいというエンジニアの方は、ぜひ、採用のご応募をお待ちしております!
この記事の著者

マイクロウェーブクリエイティブ バックエンドグループ
CMS、Webアプリケーション、開発・プログラミングに関する情報などエンジニア目線で深く切り込んだ情報を発信します。




