7年前にソニックガーデンが入って、Ruby on RailsとAWSでリプレイスをはじめた時点ですでにアクセスが多かったですし、そこからさらに増えると予想していました。なので、最初の段階から「アクセスがめちゃくちゃ来るぞ」という前提でコードを書いてきました。

といっても、特別なことをしているわけではなく、パフォーマンスの問題が起きないように、基本を押さえたコードを書いています。一覧系の画面では、表示のたびに集計するのではなく、あらかじめキャッシュする処理を仕込んでいます。当たり前のことではあるのですが、ここで油断すると一発でサーバーが落ちるんですよね。なので、基本通り丁寧に作っています。

この「基本通り」が、すごく高い水準にあるんです。私が自分では速度を考慮したつもりのコードを書いても、コードレビューで坂川に「このSQLはこうすればもっと速くなる！」と指摘されて驚くことがあります。この妥協のないチューニングを、私が参加する前から長年積み重ねたことで、現在のパフォーマンスが実現していると感じます。

当時から20万人以上のユーザーがいましたし、既に学習記録関連の高負荷な機能の原型はあったんです。なので、もはや多少の工夫では負荷がさばききれず、中川さんは「学習の記録データを3か月ごとに削除する」という手段を取るところまで追い詰められていました。

我々が入った最初の頃、リプレイスの相談をする中で中川さんから「やっぱりデータは3か月ごとに消さないと動きませんよね？」と聞かれたのを覚えています。中川さんもエンジニア経験があるので「この規模でこのパフォーマンスを実現しようと思ったら、データを消すしかない」という諦めの感覚をもっていらっしゃったんだと思います。

でも、私は「いやいや、ユーザーからしたら、せっかく問題を解いた記録が消えるの、嫌じゃないですか」と言いました。そこから、要件や予算の制約の中で、データを全部残しても動く設計とコードを考えて、リプレイスを進めました。

その甲斐あって、現在では全データを残したまま、当時の倍以上の50万ユーザーに快適に使っていただいています。

技術面で工夫を凝らしたのは、問題文をAIでレビューする機能です。出題する問題に矛盾がないか、専門用語にちゃんと説明がついているか、解説の分かりやすさはどうか。複数の評価項目ごとに配点が付いて、すべての基準をクリアしないと問題を公開できない、という仕組みです。

そうなんです。「Ping-t」には大量の問題がありますし、「評価基準を変えたから1000問まとめて再レビューしたい」みたいなことも起こります。なので、単に1問ずつ手でAIに投げて終わり、では成り立たない。APIで一斉にAIに指示を送る機能を作るのはもちろん、改善の仕組み全体を考えて「AIの回答精度をどうやって上げ続けるか」という課題に取り組みました。

AIの回答って、最初から完璧にはならないんですよね。「ここの評価が甘い」「この観点も入れたい」と、お客さまが使うたびにプロンプトを調整していくのが望ましい。また、AI自体も進化していっているので、常にその時点で良いアウトプットが出せるように改善していく必要があります。なので、もしプロンプトをシステム内に埋め込んでいたら、調整するごとにシステムを改修することになり、とても実務が回りません。

そこで、お客さまがプロンプトを直接編集できる管理画面を作りました。これは「プロンプトのGit管理」みたいなもので、いつ、どんな理由でプロンプトを調整したかの変更履歴が全部残ります。さらに、実際にレビューした際にAIに送ったプロンプトと、処理したモデル、返ってきた応答、トークンの消費量まで全件保存しています。

はい。採点結果を人の目で見て「この問題の採点がおかしい」と感じた時に、当時のプロンプトのバージョンとAIの応答を遡って確認できるようにしたんです。

要は、「AIに投げて終わり」ではなく、お客さまが自分でAIの使い方を改善し続けられるシステムを作ったということですね。他にも細かい工夫として、AIとスムーズにやり取りするために、回答の型指定とか、画像にプロンプト内で独自IDを振るとか、話は尽きないのですが、一番大事だったのは「改善し続ける仕組み」全体の設計です。ここまでやって、Ping-tの中で生成AIを本当に「実用化」することができました。

コスト面の考慮も、実用上欠かせませんでした。大量の問題を評価するとトークン量が膨大になりますが、この機能の性質上、採点基準などを記述したプロンプトの前半は全ての問題で共通になります。ですので、この共通部分をAI側でキャッシュすることでトークン消費を抑えています。

決済にはStripeを使っているんですが、Stripeの「銀行振込」機能が追加されるタイミングで、すぐに採用して組み込んだんです。まだ事例がほとんどない中、開発環境で何度も振込を試しながら手探りで実装しました。銀行振込には「金額がズレていたら管理者に通知する」といったお客さまの業務フローが絡む特殊な考慮があり苦労しましたが、結果的に先行事例として注目され、Stripeのユーザーグループで発表することになりました。