検証で組んだ仕組みをそのまま本番環境へ移せることを、基盤選定の判断軸に据えた点が大きかったと考えられます。他のプロジェクトですでに使われていたVertex AIを選び、PoCで求める性能が得られることを確かめたうえで実装に進む流れをとったため、「試すための実装」と「売るための実装」を二度書く工程が生まれません。開発の速さは作業量を削って稼いだのではなく、作り直しの工程そのものを設計段階で消した結果と見るのが妥当でしょう。
モデルを選ぶ基準を、日本語の性能と後から調整できることの二点に置いた判断も効いています。ファインチューニング(特定の業務向けにAIを再学習させる手法)の機能が備わっていたことで、クライアントごとに異なる個別課題へ、モデルを作り直さずに寄せていく余地が残りました。リリース当時に入力できるトークン数の上限が少なかったという制約も、基盤側の継続的な機能改善によって解消しており、外部の進化を自社サービスの伸びしろとして取り込める構図になっています。
サービスを4つのソリューションに分け、それらをつなぐ役割を∞AI Marketing Hubという別の層に持たせた構成も見逃せません。∞AI Adsはシステム全体をGoogle Cloud上に置く一方、∞AI Chatは社内のセキュリティポリシーとの兼ね合いから他社のクラウドサービス上に構築し、生成AIの部分だけをGoogle Cloud側の機能に連携させています。要件の異なるサービスを一つの基盤に無理やり揃えず、生成AIの機能だけを切り出して接続する形にしたことが、制約を抱えたまま前に進む余地を生んだと言えます。