Titanium の採用技術と、その先に見えたもの

Titanium は、生成AIを活かした文章生産用のエディタとして作った。

前回の記事ではコンセプトや思想的な話を中心に書いたので、今回はもう少し実装寄りの話をご紹介。

バックエンドは Firebase を全面的に採用した

Titanium のバックエンドは、全面的に Firebase を使った。100%Firebaseでバックエンドを作ったのは初めてだった。

Firebase は、いわゆる mBaaS（Mobile Backend as a Service）と呼ばれるサービスのひとつで、

といった機能をまとめて提供してくれる。

今回やってみて良かったのは、生成AIまわりもFirebase の中で完結できたことだ。

Google Cloud には Vertex AI という生成AIプラットフォームがあるが、Firebase にはそれをラップした Firebase AI Logic という仕組みが用意されていた。

これを使うと、Firebaseの中で

といったことが、ほぼノーコンフィグで利用できる。

もうひとつ良かった点が、Firestore がデフォルトでベクトル検索に対応しているところだ。

embeddingに関しては何らか他のデータベースに格納することを覚悟してたので、嬉しい誤算だった。

コアとなる機能は次のようになっている。

Firestoreにはノート本文、ノート全体のembedding、Markdownの見出しごとに分割した「セクション」ごとのembeddingを保存するデータ構造になっている。

Cloud Functionで - ノート保存時の各embedding再計算 - テキストを受け取り、そのテキストの埋め込み表現を計算し似たノートを検索 - 複数のノートを指定し混ぜ合わせたノートをgeminiで生成

ノートに関してはフロントエンド側で、数秒入力がないと自動更新をかけている。更新毎にembedding再計算関数を呼び、カーソルが違うセクションに動けば類似ノート検索をし、Mixボタンが押されたらノート生成という流れ。

とはいえ、すべてが良かったわけではない。

前提として書いておくと、今回 Titanium のコードは、ほぼすべて生成AIに書かせている。
自分は設計や指示、レビューに回っていて、手でコードを書くことはほとんどしていない。

なので「動いてはいるが、自分が完全には理解していないコード」もある。

特に影響が大きかったのが、Firestore のセキュリティルール周りだ。

Firestore のセキュリティルールは独特で、正直かなり分かりにくい。

JavaScript や Python のサブセットだったらもう少し直感的だったかもしれないが、実際には独自DSLになっている。

今回に関しては、この Firestore ルールも生成AIに書かせている。
読む限り大丈夫だとは思うが自分では書けない。

これまでは、理解できていないコードを本番で使うことにはかなり抵抗があった。
しかし生成AI前提の開発では、
こうした割り切りをどこまで許容するのか、という新しい問題が出てきている気がする。

もうひとつ気になったのが、embedding API と Firestore の連携だ。

Firestore のベクトル型は 2048次元が上限になっている。
一方で、

という仕様になっている。

埋め込みを得て、そのまま Firestore に格納するのは、非常によくありそうなユースケースだと思うのだが、ここが噛み合っていない。

結局どうしたかというと、
3072次元の embedding を生成したあと、特定の1024次元を落として 2048次元にする、
というかなり力技な対応を取ることになった。

今回は、生成AIを使って、生成AIを使うサービスを実際に作ってみた。
その過程で、今後のソフトウェア開発について考えることがあった。

ちなみに、これまでも既存プログラムの機能追加やリファクタリングでは、コーディングエージェントを全面的に使ってきたが、ゼロからアプリを作ったのは今回が初めて。