GPT-4を使えば自然言語の入力でコードが出来上がるのでは？　LLMを活用した、「KARTE」を拡張する“JavaScriptコード生成機能”

LLMを使ってJavaScriptのコードを生み出せる「Craft Functions Copilot」を開発中

竹村尚彦氏：みなさん、こんばんは。本日は、「KARTE CraftにおけるLLM活用」ということで、「Craft Functions Copilot」という機能のお話をしようと思います。

あらためまして、初めまして、プレイドの竹村と申します。現在私は、パートナー企業との共同事業化とソリューション開発やAPI活用を推進するEcosystem Teamといったところで開発責任者をしているのですが、リーディングしながらけっこうコードも書いているエンジニアでもあります。

私たちは、「KARTE」というSaaSプロダクトを提供しているのですが、本日お話しする、Craft Functions Copilotという機能は、一言で言うと、このKARTEを拡張するJavaScriptのコードをLLMを使って生み出せる機能です。これは、まだ絶賛開発中の機能です。

裏側で「Microsoft Azure」を使っているのですが、本日は、Craft Functions Copilotといったものがどんな設計で作られているのか、どんなサービスを使っているのかという話ができればと思います。

マーケター向けのSaaSプロダクト「KARTE」

KARTEはBtoBtoCのSaaSなので、「そもそも（KARTEって）何だ？」みたいな人たちもいると思います。軽くKARTEや「KARTE Craft」のお話をして、本題に移っていきたいと思います。

KARTEというプロダクトは、現在主にマーケター向けのSaaSとして提供されています。Webサイトやネイティブのアプリケーションを拡張できるSaaSで、JavaScriptのタグをWebサイトに入れたり、ネイティブアップにSDKを入れたりすることで、Webサイトやアプリケーションを利用しているユーザの行動をリアルタイムに解析して、そのリアルタイムに解析したデータをもとに、さまざまなアクションができるプロダクトになっています。

主にマーケターさん向けのプロダクトなので、基本的にノーコードでできるようになっています。

そのKARTEを拡張する機能として、KARTE Craftという機能があって、これは7月にβ版として出したばかりの機能・開発プラットフォームです。

この機能を使うと、KARTEにはない機能、例えばKARTEの特徴であるリアルタイムな解析エンジンなどを使って自由自在に拡張することができます。

これは、ユーザーからの、かゆいところに手が届ききらないことがあるんだよな、というニーズをもとに、外からでも拡張できるように作ったプロダクトになっています。

GPT-4を使えば自然言語の入力でコードが出来上がるんじゃないかと仮説を立てた

これがあるとどんなことができるかというと、一例ですが、天気情報と連携させて、ネイティブアプリケーションと組み合わせると、緯度経度を取って、天気の情報を取って、例えば雨だったらその場所にいる人に、「今雨だから、近くにこんな店がありますよ」と出せたりとか。

あと、クーポンのシステムと連携すると、クーポン在庫の払い出しのポップアップを出したりすることができるようになります。これ以外にもいろいろできることがあります。

いろいろできるのですが、結局これは開発プラットフォームなので、コードを書かないといけないです。冒頭に申し上げたとおり、KARTEは基本的にマーケターさん向けのサービスです。当然、マーケターさんだけではこんなコードを書けることは多くはないですよね。

結局今使ってもらう時は、お客さまの企業側のエンジニアや私たちのカスタマーエンジニアが対応して、コードを書いたり設計したりする感じになっています。

昨今も各企業にはそんなに開発のリソースがあるわけじゃないですよねというところで、この課題をどう解こうかといったところで、GPT-4を使えば自然言語の入力で今のCraft Functionsのコード、JavaScriptのコードが出来上がるんじゃないかと、仮説を立てました。

MVPを作る中で得た学び

最近ですが、それで出来上がったのがCraft Functions Copilotです。

とりあえずは、MVP（Minimum Viable Product）を作ろうといったところで、まず作ってみたんですよね。構成はすごくシンプルで、GPT-4一本勝負みたいな感じになっています。

（スライドを示して）ここにスクリーンショットが入っています。少し小さいですが、そのMVPの画面になっていて、基本的にチャットのインターフェイスで、インプットは自然言語入力を想定して作りました。いろいろ文字を入力していくと、最終的にこの下にあるような精度もそこそこのJavaScriptのコードが出来上がるというところまではできました。

ただ、MVPなので仕方ないところもあると思いますが、想定どおりにはいかなかったです。すごく当たり前の話ですが、KARTEってAPIがいろいろあって、そのKARTEのいろいろなAPI、Craft Functionsを使うためのAPIや、Craft Functionsの機能自体をプロンプトベースで対応させようとすると、けっこうプロンプト量が膨大になっちゃうんですよね。

その結果、コード作成ボタンを押してからのレスポンスがすごく遅くなったり、複数人が使うと、エラーが返ってきたり、あと、コストが意外とかかる。GPT-4を使っているので意外と（コストが）かかるというかたちになってしまいました。

本番提供をまだしていないのですが、本番提供だともっといろいろ使われると思うので、このあたりをやはり考えないといけないよねというところで、レイテンシー、リソース上限、コストの話があるなというのが、このMVPから学んだところです。

本番提供における“制約”を踏まえた設計のポイント

ここで学んだことを踏まえて、再度設計を考え直しました。

今のMVPのバージョン0.0.1って、GPT-4一本勝負みたいなかたちでやっていました。やりたいことはできるんですけども、それを全部力業で解こうとしないようにするというか、たぶんエンジニアの方は無意識にやっていると思うのですが、たぶんプログラムを作るプロセスってステップがあると思うんですよね。

そのステップを適切に分割して、そのステップに沿ったUIやインプット方式で考えていければ、けっこうGPT-4を有効的に使うことができるんじゃないかなと考えました。

（スライドを示して）出来上がった画面がこちらですね。ちょっと全画面になっていないので小さいのですが、上のほうにある部分、「トリガー」「データ取得」「データ出力」「コード生成」というのが、このCraft Functionsのコードを生成するためのステップになっています。

このステップを選択すると、真ん中、私たちはメッセージエリアって呼んでいるのですが、そのメッセージエリアの内容やUIが変わっていく感じですね。

このメッセージエリアを見ていただくと、先ほどはたぶんチャットのインターフェイスで自然言語を入力させるぐらいしかなかったと思いますが、ボタンが付いていたり、「検索」という文字が見えたり、カードが見えたりと、さまざまなインプット方式を用意しました。

このUIの裏側でどんな構成、Microsoft Azureのサービスを組んでいるかというと、（スライドを示して）こんなかたちになっています。

この、1、2、3、4と書かれているのが、先ほどお伝えした上のステップですね。ポイントは、GPT-4って、実は最後のコード生成部分にしか使っていないことです。トリガー、データ取得、データ出力では、GPT-4を使わずにGPT-3.5とかVector Searchを使っていると思います。

基本的に固定値の設定を選ばせたいとかだと、DBの設定をそのまま見せたりしているのですが、ユーザーの中には、設定値をそのまま選べないというか、やりたいことは明確じゃないけどなんか質問を投げたい、検索したい、みたいな方もいるかなと想定しました。

DBに入っているコードのメタデータとかAPIのメタデータみたいなものをベクトル化して、OpenAIの「Embeddings」のAPIを使ってVector Search DBに入れています。その検索は、このVector Search DBを使ったベクトル検索で出して、候補を出してあげるかたちになっています。

そんなかたちで、このステップ1、2、3を順番にやっていくと、そのステップごとの要件が決まるような設計にしているんですよね。その要件が定まった後にステップ4に移り、ステップ4でコード生成ボタンを押すとコード生成がされるかたちになっています。

トークン数、レイテンシー、ユーザー体験において改善が見られた

これが結局、結果的にどうなったのか。次が、最後のスライドですが、GPT-4を有効的に利用したUIに変えて、裏側の構造もそれに伴って変えたことによって、先ほどのバージョン0.0.1の時に比べて、GPT-4に流すトークン数が60パーセントぐらい減りました。

トークン数が減ったからそれは当たり前かもしれませんが、レイテンシーも劇的に改善しました。

入れるトークン数が減ってレイテンシーが改善されたので、生成されるコードの精度は、そんなに上がらないんじゃないか、逆に下がるんじゃないかと思われるかもしれませんが、逆に向上しました。

これはたぶん、GPT-4に渡すプロンプトが逆に絞られたことによって理解しやすくなった、認識しやすくなったということが仮説として考えられるかなと思います。

これは、ちょっと副次的な効果ですが、ステップを切ったり、インタラクティブなUIにしたことによって、これは社内ユーザーの声ですが、結果的にユーザー体験も向上しました。

私たちはこれを絶賛開発中で、外に出していない機能です。マーケターが使うには、直感的じゃない部分などがあるかなと思っています。

先ほどのアーキテクチャのようなかたちで、工夫するだけでこれだけ改善して、LLM周りにはたぶんもっといろいろなプロダクトだったりOSSだったりがあると思うので、それをうまく組み合わせれば、UI/UXをもっと改善できる余地がありそうだと思っています。

今日、MS（Microsoft）さんのイベントなので、今後のMSさんのプロダクトのアップデートをすごく期待していますといったところで、私の発表を締めさせていただきたいと思います。

ご清聴ありがとうございました。