はじめに
今回は、APEXlangで作ったアプリから、今話題の Jev を呼べるか試したくて、
既存の2048ゲームをCodexに頼んでAPEX版にしてみました。
できあがったのはこちら
Jevが2048を自動でプレイするアプリです。
Jevは、文章を生成する代わりに、選択肢からの判断と確率を返すTypeSafe AIのモデルです。
2048は、同じ数字のタイルを合体させて大きな数字を作っていくパズルゲームで、Jevには毎回「上下左右のどちらに動かすか」を判断してもらいます。
実際に動いている様子はこちらです。
左側にゲームの盤面、右側にレイテンシやコストなどの情報を並べています。
盤面の下には、選んだ方向と、方向ごとの判断確率も表示しています。
ゲーム終了時の1回の実行結果です。389手進み、最大タイルは512、スコアは5,604でした。
元にした以下のアプリではJevとLLMを並走させていましたが、今回はJev側だけをAPEX版にしています。
APEXlangと今回の環境
APEXlangの説明や開発環境は、前回の記事を参照してください。
今回もローカルのCodexから、既存のAutonomous AI Database（以下、ADB）上にアプリを作っています。
アプリ定義はAPEXlangで管理し、Codexに実装を指示して、SQLclで検証後にADB上のAPEXへimportしました。
ADBからJevを呼ぶ方法は、asahideさんのこちらの記事をおおいに参考にさせていただきました（感謝）
Codexに相談したこと
今回は、作成済みのゲームのソースコードを渡し、APEXでどこまでできるか相談するところから始めました。
やり取りから抜き出すと、こんな感じです。
「このアプリ、私が作ったんだけど、APEXlangでも実装できる？」
「APEXからJev呼び起こせる？ asahideさんの記事を参考に確認して」
「左右の独立ループは不要でOK。Jevだけ動かせたらOKとして、リアルタイムで、レイテンシとコストを見えるような仕様には出来る？」
アプリの構成と保存の流れ
全体の構成はこちらです。OCI側のコンポーネントはADBだけで完結してます。
ブラウザとの通信をORDSが仲介し、ADB内のAPEXが画面とログインを受け持ちます。
ゲームの処理とJevの呼出しは、PL/SQLが担当します。
保存先のテーブルももちろんADB内です。
ゲームの状態、各手の履歴、モデルや単価の設定などを保存しています。
ADBからJevを呼ぶ
ADBのPL/SQLから、DBMS_CLOUD.SEND_REQUEST でJevのAPIを呼び出しています。
APIキーはDBの資格証明に保存し、呼出し先を bearer://api.typesafe.ai/v1/systemone と指定します。
この形式では、資格証明に保存したキーがBearerトークンとして送られます。
認証方式をURIで指定する仕組みは、Oracleのドキュメントにも記載されています。
Jevの判断でゲームを進める
1手ごとのデータの流れは、次のようになります。
- ADB側のコードが盤面やスコア、動かせる方向を整理してJevへ送る
- Jevが返した方向ごとの確率をもとに、有効な方向を選び、タイルの移動や合体、スコア計算を行って保存する
ゲームのルールと計算はADB側、次の一手の評価はJev、という分担です。
自動プレイはADB内のバックグラウンド処理で進み、ブラウザは最新の状態を定期的に取得します。
画面には盤面だけでなく、各手のAPI呼出し時間やトークン数、概算コストも反映されます。
さいごに
ADBとJev繋げられたので、今後いろんなユースケースが考えられそうでワクワクします！