ENECHANGE エクスペリエンス部長の草間です。 今回は、エンジニアの関与無しでCursorで業務アプリのPoC開発を行い、そのまま本格開発につなげた体験談を紹介します。
業務アプリを作らなきゃいけなくなった!
ENECHANGE内では、次々に新規ビジネスが立ち上げられています。 多くは電話やメールでクライアントと調整するミニマムスタートを切るのですが、そのうちの1つを本格運用するにあたり、システムへの移行が必要になりました。そこで、まずGAS(Google Apps Script)とスプレッドシート+Reactで概念実証を行い、その後Dockerコンテナに置き換えていく開発手順を踏むことにしました。
この開発を担当したのは、UI/UXデザインを主務とする私、エクスペリエンス部長の草間でした。これまでWordPressのカスタムテーマ作成程度のプログラミング経験が殆どで、複雑な業務アプリケーションの開発は初めての経験です。
開発環境の現状と制約
はじめに、デザイナー中心のエクスペリエンス部がPoCに使えた開発リソースについて、説明します。
まず、既に整備されていた環境として、ReactアプリケーションのPoCを立ち上げるためのデプロイプロセスと、フロントエンド開発に必要な基本的な環境がありました。
一方で、サーバーサイドプログラムの開発・運用環境、データベースの構築・管理環境、そして本格的なバックエンド開発に必要なインフラは用意されていませんでした。
さらに、人的リソースの制約もありました。他の開発プロジェクトの繁忙期により、エンジニアの確保が困難で、新規業務のPoC開発に従事できるエンジニアリソースが限定的でした。
これらの条件下でも、デザイナーがAI開発ツール「Cursor」を活用することで、エンジニアの直接的なコードライティングやレビューがなくても、PoCとして動作するものが作れるようになりました。これにより、実務担当者のニーズ吸い上げや、機能を通した要件の定義が実現し、従来は電話やメールで行われていた複雑な業務プロセスをWebアプリケーション化するPoC(概念実証)を、わずか1週間で完成させることができました。
本記事では、エンジニアではない視点での開発体験と、AI支援開発の可能性について詳しく紹介します。
業務課題と解決への道のり
手動調整からシステム化への移行
冒頭に触れた通り、新規の事業において、初期段階としては電話やメールで顧客とやりとりするような、ミニマムスタートを採用していました。しかし、業務の成長に伴い、いくつかの課題が顕在化してきました。
電話・メールでの手動調整では、各企業からの注文を個別に受付し、手動で情報を整理する必要がありました。また、取引状況の把握に時間がかかり、機会損失が発生することもありました。複雑な条件での手動計算や調整作業では、エラーが発生しやすく、業務量の増加に伴い、手動調整では対応が困難になってきました。
エクスペリエンス部としての視点
私はエクスペリエンス部の責任者として、この業務に関わるユーザー・担当者の体験改善を検討しました。手動調整による業務フローでは、複雑な手順による操作ミスの発生、時間のかかる手動作業による生産性の低下、人的ミスによるユーザーの不満、そして業務拡大時の対応限界といったUX課題がありました。
技術選択の背景
もちろん、ユーザー体験の改善を最優先に考えながら、技術的な実現可能性も考慮する必要がありました。前述の環境制約を踏まえ、技術選択の背景を整理してみました。
環境制約により、本格的なサーバー環境の構築・運用は知識不足で、複雑なデータベース設計は経験不足で困難でした。また、他の開発の繁忙期でエンジニア確保が困難で、着手までにタイムラグも生じました。一方で、ユーザー体験の検証を迅速に行いたいという要望もありました。
幸いエクスペリエンス部向けには、Reactアプリケーションのデプロイプロセスが既に整備されており、フロントエンド開発環境が利用可能でした。
これらの制約と既存環境を考慮し、PoCについてはエンジニアレス開発のアプローチを採用し、以下の技術スタックを選択しました:
システム構成の比較
PoC段階:GAS + Google Sheets + React構成
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ React App │ │ GAS API │ │ Google Sheets │ │ (Frontend) │◄──►│ (Backend) │◄──►│ (Database) │ │ Static Host │ │ Google Cloud │ │ Google Cloud │ └─────────────────┘ └─────────────────┘ └─────────────────┘
特徴
- フロントエンド:React + TypeScript + Tailwind CSS
- バックエンド:Google Apps Script(JavaScript)
- データベース:Google Sheets
- デプロイ:静的ファイル配信 + GASデプロイ + エンドポイント変更
本格運用段階:Docker + Go + PostgreSQL + React構成
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ React App │ │ Go Backend │ │ PostgreSQL │ │ (Frontend) │◄──►│ (API Server) │◄──►│ (Database) │ │ Docker │ │ Docker │ │ Docker │ └─────────────────┘ └─────────────────┘ └─────────────────┘
特徴
- フロントエンド:React + TypeScript + Tailwind CSS
- バックエンド:Go + Gin Framework
- データベース:PostgreSQL
- インフラ:Docker + Docker Compose
PoC段階の技術スタック選択:GAS + Google Sheets + React
Google Apps Script (GAS) を選んだ理由
1. 学習コストの低さ JavaScriptベースで、既存のWeb開発知識を活用可能で、複雑なサーバー設定やデプロイメントが不要でした。Googleアカウントがあれば即座に開発開始可能という点も魅力的でした。
2. 運用の簡易性 Googleのインフラをそのまま活用でき、メンテナンスフリーの運用環境が提供されていました。
3. コスト効率 初期費用ゼロでの開発開始が可能で、PoC開発では無料枠内で完結し、インフラ構築の依頼も不要でした。
Google Sheets をデータベースとして活用
データの可視性と操作性 データが目で見える形で管理され、処理の結果として何が起きているのか簡単に見て分かる点が魅力的でした。
開発・運用の柔軟性 スキーマ変更が簡単で、データのインポート・エクスポートが直感的、そしてバックアップとバージョン管理が自動で行われる点も評価しました。
エンジニアレス開発による概念実証の実現
既存環境の活用と拡張
フロントエンドのPoCだけを意図して用意されたReact環境に、GAS(Google Apps Script)+スプレッドシートを加えることで、複数人から同時にアクセスされ、取引が進むシステムの本格的な概念実証をエンジニアレスで実現できました。
Cursorによる自然言語での開発
「リアルタイムで取引情報を表示するテーブルコンポーネントを作成して」
このような指示だけで、適切なReactコンポーネントが生成されました。生成されたコードを確認し、また必要に応じて自然言語で調整を加えることで、期待通りの動作を実現できました。
ユーザー要望の議論と要件定義の実現
この設計をもとに、ユーザーの要望やあるべき挙動の議論ができるようになりました。動作するコードがあることで、抽象的な議論ではなく、具体的な機能を通した要件の定義が実現できました。
開発プロセスの変革
従来の開発フロー 1. 仕様書作成 → 2. 設計 → 3. 実装 → 4. テスト → 5. デバッグ
Cursor活用フロー 1. 自然言語での要件定義 → 2. AI生成コードの確認・調整 → 3. 動作確認
この変化により、まったくエンジニアリソースを使わずに、データ処理の概念も含めた実装が実現しました。特に、複雑なロジックの実装において、AI支援により大幅な効率化を実現できました。
1週間でのPoC完成プロセス
初期構築の超迅速性
TailwindベースのUIの初期構築は、なんと会議中の1時間で行われました。Cursorの自然言語での指示により、基本的なUIコンポーネントが迅速に生成され、すぐに動作確認、方向性の意識合わせができる状態になりました。
並行開発の実現
その後、GAS・スプレッドシートデータベース等の実装と、フロントエンド処理を並行的に実施しました。AI支援により、複数の機能を同時に開発することが可能になり、効率的な開発プロセスを実現できました。
学び: エクスペリエンス部の責任者として、ユーザー体験のわかりやすさに焦点を当てた指示を的確に行うことができました。AI支援により、複数回の試行錯誤も苦ではなく、従来の開発手法よりも大幅に短縮された開発期間を実現できました。
エンジニアレス開発環境の難しさ
GAS+スプレッドシート環境での開発には、ちょっとした苦労がありました。
バックエンドエラーの伝達方法
GAS環境では、バックエンドのエラーメッセージがCursorに直接伝わらないため、console.logにエラー情報を吐かせて、そのスクリーンショットを撮ってCursorに伝える必要がありました。まるで「エラーメッセージの翻訳者」のような作業でした。

この方法により、Cursorがエラーの詳細を理解し、適切な修正提案をしてくれるようになりました。一見非効率に見えますが、エンジニアのレビューなしでも問題を解決できるという点で、エンジニアレス開発の可能性を示す興味深い体験でした。
実装した主要機能
1. リアルタイム取引システム
// 自動マッチングエンジンの例 const processMatching = async () => { const orders = await getActiveOrders(); const matches = findMatches(orders); for (const match of matches) { await createReservation(match); await updateOrderStatus(match.buyOrder, 'reserved'); await updateOrderStatus(match.sellOrder, 'reserved'); } };
実装のポイント: 会議の中で吸い上げた情報をもとに指示をすることで、このような複雑なロジックが生成されました。生成されたコードを確認し、必要に応じて調整することで、期待通りの動作を実現できました。
2. 直感的なUI設計
- カラーテーマ: 取引タイプ別の視覚的区別
- リアルタイム更新: WebSocket的な仕組みでの即座反映
- モバイル対応: タブレット・スマートフォンでの操作
実装のポイント: エクスペリエンス部の責任者として、ユーザー体験の改善に焦点を当てた指示を的確に行うことができました。
3. データ整合性の確保
- 重複チェック機能
- トランザクション的な処理
- エラーログの記録
実装のポイント: これらの機能の実装において、AI支援により適切なコードが生成され、期待通りの動作を実現できました。
技術的な成果と学び
実現できたこと
1. 業務効率化の実現
- 手動調整時間を90%削減
- リアルタイムでの状況把握
- 人的ミスの大幅な減少
2. スケーラビリティの確保
- 複数企業の同時取引対応
- 大量データの処理能力
- 24時間365日の自動運用
3. ユーザビリティの向上
- 直感的な操作インターフェース
- モバイル対応による外出先での利用
- 視覚的フィードバックによる操作感向上
技術的な学び
1. エンジニアレス開発の可能性
- 既存環境の活用により、専門知識なしでも実用的なシステム構築が可能
- AI支援により、学習コストを大幅に削減
- 迅速なプロトタイプ作成による早期検証の重要性
- 動作するコードによる具体的な要件定義の実現
2. 段階的開発アプローチの価値
- PoC段階での要件検証の重要性
- ユーザー要望の議論と機能の具体化
- 本格開発へのスムーズな移行
本格運用に向けた課題と解決策
現在認識している課題
1. セキュリティ面での課題
- 認証・認可システムの強化が必要
- データの暗号化・秘匿化
- アクセスログと監査機能
- API レート制限とDoS対策
2. 運用面での課題
- データベースの本格的な設計
- バックアップ・復旧戦略
- 監視・アラート機能
- パフォーマンス最適化
3. スケーラビリティの課題
- 大量データ処理の最適化
- 同時接続数の制限
- データベースの正規化
- キャッシュ戦略の実装
本格開発への移行戦略
動作するコードをもとに、Docker環境でのGo言語+SQLでの開発も開始できました。PoCで検証した機能とユーザー要望を基に、CursorへGo言語でのリビルドを指示することで、エンジニアの介入なく本格的なシステム開発に移行しています。 必要な機能概念の実装をGo環境で確認したあと、最終的にはユーザー管理やセキュリティなどの開発、コードレビューをエンジニアに依頼する予定です。
構成変更のポイント
- データの秘匿性: スプレッドシートの内容をフロントエンド処理で仕分けていた部分を、バックエンド側でユーザーごとに仕分けて送るように変更
- セキュリティ強化: JWT認証、HTTPS通信、入力値検証、SQLインジェクション対策の実装
- 運用性向上: Docker化による環境統一、CI/CDパイプライン、監視・ログ収集システムの整備
1. セキュリティの強化
JWT認証の実装、HTTPS通信の強制、入力値検証の強化、SQLインジェクション対策などがCursorにより行われています。また、スプレッドシートの内容をフロントエンド処理で仕分けていた部分を、バックエンド側でユーザーごとに仕分けて送るようにして、情報の秘匿性に配慮するなど、PoC環境から処理構成を変更している部分もあります。
2. 運用性の向上
Docker化による環境統一、CI/CDパイプラインの構築、監視・ログ収集システム、自動バックアップ機能を整備しています。
エンジニアレス開発の限界と可能性
可能性
1. 迅速なプロトタイプ作成
- アイデアの早期検証
- 要件の明確化
- ステークホルダーとの合意形成
2. コスト効率
- 初期投資の削減
- 開発期間の短縮
- 学習コストの最小化
3. 業務理解の深化
- エンジニアと業務担当者の橋渡し
- 要件定義の精度向上
- ユーザビリティの重視
- エクスペリエンス部としての視点での改善提案
限界
1. セキュリティの専門性
- 本格的なセキュリティ実装には専門知識が必要
- 脆弱性の特定と対策
2. パフォーマンス最適化
- 大規模データ処理の最適化
- メモリ管理とリソース効率
- 並行処理の実装
3. 運用・保守の複雑性
- 本格的な監視システム
- 障害対応と復旧
- 継続的なセキュリティアップデート
今後の展望
段階的な技術移行
Phase 1: PoC検証(完了)
- GAS + Google Sheets での概念実証
- 基本機能の動作確認
- ユーザビリティの検証
Phase 2: 本格運用準備(進行中)
- Go + PostgreSQL への移行
- セキュリティ機能の実装
- 運用監視システムの構築
技術選択の教訓
1. 段階的開発アプローチの重要性
- PoC段階では迅速性を重視
- 本格運用では堅牢性を重視
- 段階的な技術移行の重要性
2. AI支援開発の活用
- 学習コストの削減
- 開発効率の向上
- 既存環境の最大活用
3. エンジニアとの協力の重要性
- 専門知識が必要な領域の認識
- 適切なタイミングでの技術移行
- 継続的な学習と成長
まとめ
今回のプロジェクトを通じて、エンジニアレス開発の可能性と限界を実感しました。Cursorを活用したAI支援開発により、プログラミング知識が少なくても、1週間で実用的なPoCを構築できることを実証できました。
主な成果
- 業務効率化の実現(手動調整の大幅削減見込み)
- 迅速なプロトタイプ開発(1週間での完成)
- ユーザビリティの重視(直感的なUI設計)
- 技術選択の最適化(要件に応じた段階的移行)
今後の課題
- セキュリティ機能の本格実装
- 運用監視システムの構築
- パフォーマンス最適化
- 継続的な技術学習
エンジニアレス開発は、迅速なプロトタイプ作成や概念実証には非常に有効ですが、本格運用に向けては、適切な技術的専門知識と経験を持つエンジニアとの協力が成功の鍵となります。
今回の経験を活かし、今後も業務効率化と技術革新の両立を目指していきたいと思います。
開発期間: 1週間
使用技術: Google Apps Script, Google Sheets, React, TypeScript, Cursor AI
チーム構成: エクスペリエンス部責任者1名
プロジェクト性質: PoC(概念実証)
次期技術スタック: Go, PostgreSQL, Docker, React