⌛️Webアプリ開発もAI駆動開発で楽ができる！...と思っていたが
現在は、以下の技術スタックでゼロから業務管理系のWebアプリ開発をしています。
採用技術スタック
- 開発環境：DevContainer
- フロント、APIのフレームワーク：Next.js
- フロント言語：TypeScript
- フロントランタイム（パッケージ管理、テストフレームワーク）：bun
- UIライブラリ：React-Admin
- バック（帳票作成）:Python、openpyxl、SQLModel
- エディタ：Cursor
- モデル：Claude3.7、GPT-4o-mini
- 調査や設計考案：ChatGPT、Perplexity
AIとのやり取りを減らすために、できるだけドキュメントが整備され、ネット上の情報が多い技術スタックを選びました。そのおかげか、開発環境構築からWebAPI、テストコード作成までは結構早く進みました。自分が知らない部分もあったので学習した部分（AI周りの整備）もありますがそれでも3日程度でAPIが動くところまではほぼノーコーディングで行けました。
開発において私がしている作業は以下です。
AI駆動開発における作業
- ChatGPTやPerplexityを使った調査、設計の試案づくり
- Cursorで仕様書と指示書を作成
- UserRulesやCursorRulesの修正
- AIエージェントが出してくる指示をみたりコードのレビュー、承認作業
- AIエージェントが解決できない部分の補佐（コマンド実行、コードや設定修正）
チャットで指示するまえにある程度は情報をファイルに仕様書や指示書としてMarkdownで記載してからAIエージェントにタスクを依頼するようにしています。
Cursorは指示書ファイルの場所をチャットへ渡すのがすごく楽です。ファイルを開いてそのままチャットの+ボタンおせば開いているものがチャットで参照されます。
チャットベースよりはファイルベースで指示をなげるようにしています。それは以下の記事を参考にしました。
個人的には一回の指示で精度を上げるためには、ファイルに情報を整理し、それを渡したほうがよいと感じます。
Cursor（+モデル）では、仕様書や指示書に概要レベルを書いただけでも、短時間でコードを作成してくれます。DevContainerやAPIのように仕様が比較的シンプルで、設定ファイルに近い感じだと修正はかなり少なかったです。
ちなみに、AIが作成したコードは一回で動くことは稀です。なのでユニットテストコードも生成して、動作確認をする必要があります。仕様書にはテスト仕様も併せて書くようにしています。
WebAPIを作るところまでは比較的、ストレスもなくかなりサクサク進みました。
が、フロントに来たところからちょっとめんどくさく、時間が掛かるようになってきました。もっともAIがというより、本来的にWebのフロントは開発や実装技術が複雑というか不確定要素が多すぎることにめんどくささが起因すると思います。
そのフロントのめんどくさく、時間がかかる点を整理しています。
😖Webフロントのめんどくささ、時間がかかるポイント
a. 視覚的なデザイン
見た目のデザインは、非デザイナーであるプログラマーにはなかなか難しいです。プログラムはゴールがありますが、デザインはゴールがあってないような感じです。
もっとも、業務アプリについてはダッシュボード系のライブラリをつかえば、このあたりは解決します。今回、私は、React-Adminをつかってそこは解決しました。
AIツールとしては、v0を使うのが一般的かなと思います。
Claude3.7だけでもよいデザインができるという話はよく聞きます。
なのでここはAIを使えばかなり問題は解決できると思います。
b. ビルドの時間、複雑性
ビルドは本当に面倒が多いです。Webフロントのストレスの少なくない部分がビルドではないかと思います。
ビルドの弊害はいろいろあると思いますが、バックエンド、バッチ処理との比較を念頭に、思いつくところを書きます。
フロントのビルドの弊害
- 時間がかかる（Viteやbunなどをつかってもそこそこかかる）
- ビルド対象は多く、設定が複雑になる（AIで設定ファイル各にしてもそもそも仕様が複雑）
- ホットリロードで更新できたり、できなかったりする場合がある（修正できてるのかわからないときがある）
- ビルド前提なのでコードを修正してすぐに動きを見たりできない
挙げてみるとそんなに項目数はないのですが、それぞれの項目が何度となく開発工程で発生します。特に開発工程の前半ではよく起こります。シンプルにライブラリが与えたように使っていれば問題も少ないのですが、少しカスタマイズすると必ずと言ってよいほど起こります。
修正したけど更新が反映されてないという問題が一番厄介だと思っています。ビルド時間は、以前に比べればbunを使うと、少し待てばいいやぐらいな感じです。
プロジェクトの後半には課題もなくなり安定してくるのですが、前半は結構ストレスがあります。AIで開発スタイルも変わったので、できればビルドレスでWebフロントの開発ができたらと思ったりします。
それができる技術はすでにあるのですが、なかなか広まっていないように思います。それは人間がコーディングするのを前提にしたフレームワークが幅を効かせているからなのかなと思ったりもします。
とはいえ、当面は、AIデコーディングするにしても一般的なやり方を踏襲するのがよいので、ビルドという処理は不可避だと思います。徐々に、AI駆動開発によって便利なライブラリや技術がでるのを待ちたいと思います。
c. エラーメッセージもない見た目の不具合はAIに伝えにくい
バックエンドの処理やビルドエラーは、エラーメッセージがでるので、AIに修正点を伝えやすいし、問題解決も明確です。
一方、見た目上、動作上の不具合はエラーメッセージもでず、人間が目で見たりさわって、「おかしい」と感じます。それを言語化して、修正方法を伝えるのは結構たいへんです。
単純なことですら、結構、コンポーネントの階層やスタイルのあてかたによっては直らなかったりします。先程の、ビルドにまつわる弊害がぶつかるともう、AIではどうにもならないこともあります。AIも修正がループに入ったりします。
画面キャプチャをしてマルチモーダルなAIに対応をもとめてもいいのかもしれませんが、すごいコストがかかりそうな気もします。こうなったら、人間の対応の方が早いとときもあります。実際、私はコードとドキュメントを改めて確認して自分で直しました。その方が早かったです。
それにしても、フロントエンドのエラーメッセージのない不具合はたちが悪いです。ものすごく時間がかかります。
d. CSS設定の複雑さ
見た目や動きをコードで定義するCSSは、かなり論理的に部品や動きを考える必要があり、すごく時間がかかります。もちろん、CSSフレームワークやコンポーネントライブラリを使えばある程度、工数削減できます。
それでも、画面要素が増えてくると影響関係が多くなり、設定が複雑になります。囲碁をしてる如く、あっちこっち考える必要があります。
特にカスタマイズをしていくと、ちょっとしたところで不具合を起こして、どれを調整すればよいのか簡単にわからないときがあります。
こうした複雑さは、画面独特な問題だと思います。AIでもかなり試行錯誤しながらでないと答えがでないなと感じます。
e. 画面の要件は異なる要素が多い
API開発については、DBのCRUD処理が大半で要件もとてもシンプルです。設計書や指示書もシンプルに作れるので、AIに依頼するのも楽ですし、生成物の精度も比較的高いです。
一方、フロントエンドはどうでしょうか？
そもそもなのですが、要件が多すぎます。どんな言語、ビルドツール、ライブラリをするか以前に、外部設計（ユーザーレベル）の要件が多すぎます。
たとえば、以下のような感じです。
フロントエンド特有の外部設計レベルの要件
- どんな部品を使うのか？（扱うデータが多ければかなり部品が多くなります）
- 部品の色、形状、配置（余白含む）
- レスポンシブの歳のレイアウトや要素の表示（スマホだとOSや端末ごとに要件を決める）
- 部品の挙動（動き、アニメーション）
- 状態管理（どのデータいじったら、どこが変わるか。セッションの保持も含む）
- 画面遷移（ダイアログの表示なども含む）
他にもバリデーションなどもありますが、バリデーションはバックエンドでも実装しますので、特有の要件には含めていません。
業務管理アプリも単純なものであれば、ダッシュボードライブラリを使えば、要件を満たす実装は簡単にできます。ただ、項目数が多かったり、DBテーブル間の結合がふえてくると厄介さが増してきます。
一方、公開型の画面であれば、デザイン、UI/UXもオリジナリティを求められたり、独自で実装することも増えます。3rdPartyライブラリの利用もせいぜい、Tailwindやコンポーネントライブラリという小さい部品レベルのものを使うぐらいです。ゲームとかになったらもう大変過ぎます。
WebAPIはデータの編集が大変だとしても、結構、やることは見えているし、淡々とこなしていけます。まして、AIのちからをかりれば本当に工数削減効果絶大です。
というようにフロントエンドはビルド云々以前に、外部設計レベルの要件が多く、複雑です。しかも、AIにつたえるにも、ある程度高性能なモデルの利用が求められます。
このあたりのフロントエンドの大変さはたくさん記事があります。
以上が、私が思いつくWebフロントの開発上の弊害です。
📜最後に（AI駆動開発でWebアプリを開発することについての所感）
AI駆動開発はWebアプリ開発の工数をかなり削減してくれます。インフラ、開発環境構築、DBマイグレーション、バックエンド系の処理などはかなり工数が減ります。ストレスもかなり少なくなります。
一方で、フロントについても、デザインやコンポーネントのコーディングしなくてよくなったので、開発工数は下がりました。とはいえ、AIをつかってすらなかなか解決しにくい課題を抱えていると思います。
フロントの課題については、できるだけUIやダッシュボードライブラリをつかうことや、初回はAIと人間がタッグを組んで今までどおり問題解決していくしかないのかなと思いました。
とはいえ、フロントエンドもAI駆動開発でかなり楽になったのは確かです。ただ、相変わらずフロントエンド開発はイラ！とすること多いなと感じます。そのうち、もっとフロントエンドが得意なAIモデルやツール、ライブラリがでるのを期待しています。
おまけ：AIシステム開発や企業のAI活用に関する意見交換会
5/17（土）に東京の永田町でタイトルのイベントがあります。オフラインだけでなく、YouTube配信もあります。
以下のようなAIシステムやシステムへのAI利用などの話を経営者の方にしていただきながら、みんなでいろいろな意見を交換するイベントです。興味のある方がいれば参加してみてください。
トークテーマ
- 「AIシステム企業」ってどんな仕事になるのか、少し解像度を上げて考えてみる
- IT企業のAI活用状況（既存プロジェクトへのAI駆動開発の導入など）