はじめに
近年では、AIコーディングアシスタントを活用してアプリケーションを開発することは珍しくなくなりました。
IBMには Bob というAIコーディングアシスタントがあり、自然言語で要件を伝えるだけで、コード生成や実装支援を行ってくれます。
あるとき私は、新しいWebアプリケーションを開発している際に、次のようなことを考えました。
「AIコーディングアシスタントがここまで進化したのであれば、バックエンドとAPIさえ提供すれば、フロントエンドは利用者自身が生成できるのではないか？」
もし実現できれば、開発者はバックエンドとAPIの提供に注力し、利用者は自分の用途に合わせてUIを生成・カスタマイズできます。
今回はこの仮説を検証するために、シンプルなToDoアプリのフロントエンドをAIコーディングアシスタントでどこまでカスタマイズできるのか実験しました。
本記事では、この実験内容を紹介するとともに「フロントエンドは開発者が作るもの」という前提が今後どのように変わる可能性があるのかを考察します。
実験
実験の前提
今回の実験用にごくシンプルなToDoアプリを用意しました。
機能は最低限です。
- タスク追加
- タスク完了
- タスク削除
- タスク一覧表示
技術構成
今回の検証では、以下の構成でToDoアプリを用意しました。
- Frontend: React
- Backend: Python
- Database: PostgreSQL
バックエンドはコンテナ化してIBM Cloud Code Engineにデプロイし、OpenAPI仕様（Swagger UI）のみを公開しました。バックエンドのソースコードは公開していません。
フロントエンドはGitHubでソースコードを公開し、IBM Cloud Code Engineにもデプロイしています。利用者はリポジトリをクローンすることで、ローカル環境でアプリを動かしたり、自分の用途に合わせてUIを変更できます。
この構成では、利用者が取得できるのは フロントエンドのソースコード と APIドキュメント のみです。
実験方法
参加者にはこう伝えます。
「このToDoアプリを好きに改造してください。
ただし条件があります。バックエンドの変更は禁止で、変更できるのはフロントエンドだけです。」
以下の２つの実験を行いました。
どちらの実験もローカルで行っており、フロントエンドとバックエンドはそれぞれ別のターミナルで起動しています。（Bobのエディタ上でフロントエンドのコードを開いています。）
UIの改造
「すべて」ボタンと「未完了」ボタンの配置を逆にするようにBobにプロンプトを入力。
「すべて・未完了のボタンの配置を逆にしてください」
ボタンの配置が逆になりました！
機能の動作も問題ありません。
データの自動登録
Todoリストの自動登録をするようBobにプロンプトを入力
「今このプロジェクトを立ち上げていて、Todoアプリを動かせる状態になっている。
バックエンドがlocalhost:8000で動いているから、localhost:8000/docsを見に行って以下の内容を基にTodoの自動追加をしてほしい！
【内容】
引越し準備チェックリストについて作成したい。これを5件ほどで適切に細分化したTodoリストを作成して、localhost:8000/docsを参考にTodoリストの自動登録を行って！自動登録の際は極力curlを使うようにして。」
playwrightというMCPサーバーを使ってAPIドキュメントを参照。
追加するTodoリストの確認。
Todoリストが追加されました！
実験結果・考察
２つのデモ動画のようにIBM Bob、フロントエンドのソースコード、APIドキュメントがあれば短時間でフロントエンドを自分用にカスタマイズできることがお分かりになると思います。
ここで重要になるのがフロントエンドとバックエンドの違いです。
フロントエンドでも、計算、データ加工、AIを利用した処理などは実行できます。
バックエンドに処理を配置する理由は、単に「バックエンドの方が高性能だから」ではありません。
本質的な違いは、フロントエンドで動くコードは利用者が自由に閲覧・変更できるため、その結果をシステムとして信頼できない点にあります。
そのため、認証・認可、権限チェック、入力値の検証、データの整合性を保証する処理など、改ざんされては困る処理はバックエンド側で担保する必要があります。
今回の実験で変更しているのは、利用者自身がローカル環境で動かすフロントエンドです。
そのため、利用者が画面や機能を自由に追加・変更しても、その影響は基本的に自分の環境に限定されます。
一方で、バックエンド側では認証や権限チェック、データ検証などの重要な処理を引き続き実施しています。
つまり、この実験のポイントは、安全性を担保すべき処理はバックエンドに残したまま、フロントエンドだけを利用者が自由に生成・カスタマイズできるか を検証することにあります。
このToDoアプリの横展開
今回扱ったのはシンプルなToDoアプリですが、同じ考え方はより複雑なシステムにも応用できる可能性があります。
開発者はREST APIやOpenAPI仕様、認証方式を提供し、利用者はAIに対して「このAPIを使って学習管理アプリを作って」「このAPIを使ってカンバン型のタスク管理アプリを作って」と依頼する。
その結果、同じバックエンドを利用しながら、用途に応じて異なるUIを持つアプリケーションを生成できるようになるかもしれません。
このような開発スタイルが実現すれば、開発者はバックエンドやAPIの保守に集中でき、利用者ごとのUI改修や画面バリエーションのメンテナンスコストを削減できる可能性があります。
また、利用者自身が後から必要な機能やUIを作れる点も大きなメリットです。
一方で、API仕様やソースコードを渡すだけでは不十分な場合もあります。
アプリケーションには単なる実装以上に「設計思想」があります。
どのような利用シーンを想定し、何を重視して設計したのかという考え方は、ソースコードだけでは伝わりにくい場合があります。
同じToDoアプリでも、シンプルさを重視するのか、情報量を重視するのか、モバイル利用を前提とするのかによって、理想的なUIは変わります。
そのため、将来的にAIによるフロントエンド生成が一般化したとしても、設計思想を伝えるためのリファレンス実装やサンプルUIは、引き続き重要な役割を持つのではないかと感じています。
まとめ
今回は、バックエンドとAPIを固定したまま、AIを活用してフロントエンドをどこまでカスタマイズできるのかを検証しました。
結果として、フロントエンドのソースコードとAPIドキュメントがあれば、AIコーディングアシスタントを使って短時間でUIや機能を変更できることが分かりました。
もちろん、アプリケーションにはコードだけでは伝わりにくい設計思想があります。そのため、今後AIによるフロントエンド生成が一般化しても、リファレンス実装やサンプルUIは重要な役割を持ち続けると考えています。
一方で、開発者がバックエンドとAPIに集中し、利用者が自分に合ったUIをAIとともに作るという開発スタイルには、大きな可能性を感じました。
開発者が「正解のUI」を作る時代から、利用者が「自分にとって最適なUI」を作る時代へ。
そんな変化が、少しずつ現実になっていくのかもしれません。