見出し画像

生成 AI を活用した UI の自動生成 ~ アーキテクチャ編 ~


はじめに

こんにちは。株式会社ラキールで DX 基盤開発を行う LaKeel DX Engine Group に所属する田村です。
現在、フロントエンド開発に高度なプログラミング知識を必要としない、ローコードビジュアル開発環境「Component Studio」の開発を行っています。

このたび、「Component Studio」では、生成 AI を利用した画面の自動生成機能「AI Navigator」をリリースしました。本リリースに関するプレスリリースはこちらをご覧ください。
本記事では、生成 AI による画面の自動生成方法やそのアーキテクチャについて解説します。

Component Studio について

Component Studio(以降、C/S) は、我々がスマートウィジェットと呼称している、画面部品を作成するための開発基盤です。
スマートウィジェットは、ボタンやテキストエリアなどの、画面を構成する小さな部品(UI コンポーネント)を組み合わせた画面要素です。UI コンポーネントはドラッグ&ドロップで配置できるため、高度なプログラミング知識がないユーザでも画面開発を行えます。
配置された UI コンポーネントはそれぞれ独自の設定項目を持っており、C/S 内でこれらの設定項目を変更することで、見た目や振る舞いを変更することができます。
C/S で作成されたスマートウィジェットは、JSON 形式のデータで表現され、ビルドやデプロイの過程を経ることなく画面に描画することが可能です。

背景

C/S は先述した通り、高度なプログラミング知識がないユーザでも画面開発を行えるようなローコード開発基盤です。
しかし、従来の C/S を利用した開発では、C/S 特有の設定などについて理解する必要があり、特に初めて利用するユーザ等にとって難しい部分もありました。
そこで、今回生成 AI を利用した、ユーザの指示文に基づき、チャットベースで画面を自動生成する機能 AI Navigator をリリースしました。これにより、C/S に精通していないユーザでも迅速に開発ができるようになります。

アーキテクチャ概要

本記事では、以下の点について具体的にご紹介します。

  1. 利用した生成 AI モデルとプロンプト

  2. 利用する UI コンポーネントの選定方法

  3. トークン数・生成時間の削減手法

  4. UX を改善するための HTTP 通信方式

利用した生成 AI モデルとプロンプト

AI Navigator では、OpenAI の GPT-4o を利用しています。GPT-4o は 2024年5月にリリースされた比較的新しいモデルで、それまでのモデルと比べて性能が非常に高く、価格も比較的廉価であるという特徴があります。

C/S で作成された画面部品(スマートウィジェット)は、JSON で表現されるデータです。以下に、C/S 上でボタンを配置するための JSON の一部を示します。この JSONには、ボタンの配置座標や設定値が含まれます。

[
  {
    "x": 1,
    "y": 1,
    "w": 4,
    "h": 2,
    "name": "CsBaseButton",
    "componentName": "RegisterButton",
    "version": "1.0.0",
    "props": [
      {
        "key": "size",
        "value": "small"
      },
      {
        "key": "text",
        "value": "Register"
      }
    ]
  }
]

AI Navigator では、生成 AI に「ユーザの指示に従ったスマートウィジェットのデータを出力する」というタスクを依頼しています。
生成 AI への依頼は、「プロンプト」と呼ばれる指示を介して行います。今回の場合、プロンプトとは生成 AI への依頼内容を示した文章になります。
GPT-4o に送信するプロンプトには、C/S の仕様情報を含めています。以下にプロンプトの一部を示します。

要求文にしたがって SmartWidget を作成し, 回答様式に従って返答をしてください. 
回答様式に反する回答は禁止します.

# SmartWidget の作成方法
SmartWidget は, 2次元座標上にコンポーネントと呼ばれる「役割を持った領域」を配置することで作成することができます.  
横軸, 縦軸ともに単位はピクセルとなります. 
このピクセル平面では左上を原点とします. 
縦軸の最大値は無限であり, 横軸の最大値は画面幅となります. 
コンポーネントの役割は様々で,  ui-specification.txt内に各コンポーネントの仕様が記述されています.
下記に示す規約と制約を遵守してください.

作成手順
1. 画面をセルに分割する.
2. 配置可能なコンポーネントリストを作成する.
3. コンポーネントを配置する

このように、C/S の仕様・制約・回答様式をプロンプトに含めることで、意図通りの出力が得られるようにしています。

利用する UI コンポーネントの選定方法

上記のプロンプトで C/S のデータ様式に沿った出力が可能になりました。次に、ユーザの指示文に沿った UI コンポーネントを利用したデータを出力するようにします。

GPT-4o のモデルは C/S 特有の「利用できる UI コンポーネント」と「UI コンポーネントの設定項目」を学習していないため、そのままでは出力できません。
例えば、C/S で標準的に提供している UI コンポーネントとして、「ボタン」の UI コンポーネントがあります。この UI コンポーネントは、「色」「ラベル」「アイコン」といった設定項目を持ちます。
これらの設定項目が、C/S で利用できるコンポーネントの数だけ存在します。これらは C/S の内部情報であるため、GPT-4o は学習しておらず、明示的にプロンプトに含める必要があります。 

しかし、これらの情報を全てプロンプトに含めると、不要な UI コンポーネントの情報も含まれてしまうため、非効率です。
そこで、今回は 利用できるコンポーネントとその設定項目を一つのテキストデータに纏め、RAG(Retrieval-Augmented Generation) を用いてプロンプトに追記する アプローチを採用しました。
RAG とは、生成 AI に渡すプロンプトを、外部情報の検索結果を追記して補強することで、回答精度を向上する技術です。今回は、外部情報として UI コンポーネントの仕様情報を利用することで、AI の出力に必要な UI コンポーネントの情報をプロンプトに追記しています。
これによって、ユーザの指示文に関連するコンポーネントが RAG によってプロンプトに追記され、適切な UI コンポーネントと適切な設定項目を含んだ回答が得られます。

具体的には、以下のような構成になります。

RAG の構成図


今回は RAG 部分を OpenAI が持つ Assistants APIFile Search を利用しました。作成したテキストデータをベクトルデータベースに変換して紐づけることで、OpenAI の RAG の仕組みによってプロンプトが補強されます。
このプロセスにより、最終的なプロンプトには「利用する UIコンポーネント」と「その UIコンポーネントの設定項目」が適切に含まれるようになり、正確なスマートウィジェットのデータが生成されます。

トークン数・生成時間の削減手法

ここまでのアーキテクチャによって、ユーザの指示文に沿ったスマートウィジェットのデータを出力することができるようになりました。
しかし、スマートウィジェットの JSON データをそのまま出力させると、出力トークン数が多くなり、それに比例して出力時間も長くなるという問題がありました。

そこで、AI Navigator では 生成 AI に JSON を出力させるのではなく、スマートウィジェットを表現する独自のデータ形式を中間データとして定義し、その定義に沿ってデータを出力させるアプローチを採用しました。
これにより、トークン数の削減と生成時間の短縮を実現しています。
出力された中間データを C/S で扱うために再度 JSON に戻す処理が必要ですが、この処理にはほとんど時間がかからないため、全体の処理時間の短縮を実現できています。

JSON と中間データのトークン数比較

UX を改善するための HTTP 通信方式

生成時間を短縮し、処理全体の時間を短縮できましたが、それでも生成 AI の出力内容によっては十数秒、データの大きさによってはさらに時間がかかることがあります。
通常の HTTP 通信の仕組みだと、生成 AI の出力が完了し、スマートウィジェットのデータに変換するまで画面にレスポンスを返すことができません。そのため、ユーザーは十数秒間待たされることになります。
そこで、AI Navigator では OpenAI API と AI Navigator API 間、および AI Navigator API と画面間の通信に SSE (Server-Sent Events) の仕組みを利用しています。
SSE とは、サーバがクライアントに対してリアルタイムにデータを送信するための仕組みです。SSE を利用することで、HTTP 通信を利用して生成途中のレスポンスを都度クライアントに渡すことが可能となり、OpenAI もこの方式に対応した API を提供しています。
AI Navigator ではこの API を利用し、OpenAI API から渡されたレスポンスを都度スマートウィジェットのデータに変換し、都度画面に渡すことで、画面側では段階的なスマートウィジェットの描画を可能にしています。

SSE の流れ

例えば、AI Navigator に「日報アプリを作成して」と依頼すると、以下のような動作になります。

SSE を利用した AI Navigator の画面

全体のフロー図

上記のアーキテクチャを踏まえた、全体のフロー図は以下のようになります。

フロー図

おわりに

今回は、ローコードツール C/S 上で生成 AI をどのように活用したのか、という点について紹介しました。

昨今の AI、特に生成 AI の発展は目覚ましく、日々言語モデルの性能が進化していく反面、それを活用する開発者の力量が試されているように感じています。
AI に関する機能は C/S に限らず、LaKeel 社員一丸となってアイデアを出し、これからも様々な機能をリリースしていこうと思っております。今後もどうぞご期待頂けると幸いです。

そして、今回この記事は全体的なアーキテクチャに絞って説明させて頂きましたが、 AI Navigator の開発で得た知見を基に、プロンプトに関する記事を近日中に公開する予定です。
こちらの記事もぜひお読みいただければと思います。

そして、今回ご紹介した内容が少しでも皆様のお役に立てればと思います。最後まで読んで下さり、ありがとうございました。