Executive Function シリーズでは、AI による変革を推進するリーダーの視点を紹介しています。
JioStar は、5 億人以上が利用するエンターテインメントとスポーツのライブ配信プラットフォームを運営し、スポーツのライブ配信では最大 7,250 万人の同時視聴に対応してきました。この規模では、AI に速さと信頼性、そして本番運用に耐える品質が求められます。
JioStar は OpenAI API を使い、動画やクリケットの統計を会話で探せるアシスタントを JioHotstar に組み込みました。視聴者は自然に話しかけるだけで、映画や番組、過去のハイライト、ライブ中の試合のシーン、クリケットの統計を探せます。結果は、ビジュアルと会話を組み合わせた体験を通じて表示されます。
シンガポールで開催された OpenAI の Executive Summit で、ASEAN の GTM 戦略責任者を務める OpenAI の Sidharth Sharma が、JioStar のチーフアーキテクト、Vijay Seshadri 氏と対談しました。テーマは、15 を超える言語に対応したこの体験を約 8 週間で構築した経緯と、AI をデモから本番運用へ移行するリーダーへの教訓です。
コンテンツの探し方は、過去 25 年間、ほとんど進化していません。最後の大きな変化は、レコメンデーションの登場でした。それ以降の多くは、同じ発想に改良を重ねたものです。
しかし、何を見るかという選択は、とても個人的なものです。たとえば、こう言う人がいるかもしれません。「落ち込んでいます。元気が出るものを見せてください」。こんな簡単なリクエストにも、多くのニュアンスが含まれています。どんなふうに落ち込んでいるのでしょうか？その人は普段、何を見ると元気になるのでしょうか？コメディを求めているのか、心が安らぐ作品なのか、それとも何もかも忘れられるような作品なのでしょうか？
従来のレコメンデーションシステムでは、そのときの気持ちを理解するのは難しいかもしれません。会話なら、視聴者はその気持ちを説明できます。私たちはこれを、音声とビジュアルを組み合わせたインターフェースと呼んでいます。
2 月にクリケットの主要大会を控え、10 月から 11 月にかけて構想の具体化に着手しました。使える時間は約 2 か月で、対象はエンターテインメントの視聴者とクリケットファンという、まったく異なる 2 つの層でした。
エンターテインメントの視聴者なら、「金曜の夜なので、意外な作品をおすすめしてください」と言ったり、タイトルがわからない映画の内容を説明したりするかもしれません。スポーツの視聴者は、ウィケットが落ちた場面やシックスの連発、ある選手が特定の得点を挙げた試合など、より具体的な情報を求めることがあります。クリケットに詳しい人なら、すべての投球の統計を求めるかもしれません。
これらは、コンテンツ探しの課題としては大きく異なります。エンターテインメント、スポーツの名場面、クリケットの詳細な統計を、多言語に対応した 1 つの体験にまとめることに、非常に短い期間で取り組みました。
ごく初期の段階で、精度、レイテンシ、コストという 3 つの要素のトレードオフとして課題を捉えました。技術面でのあらゆる判断で、この 3 つを同時にバランスさせる必要がありました。
音声を使うことで、その重要性が特に高まりました。ユーザーの 60% 以上がテキストではなく音声を使っています。見たいものは、話して伝えたいのです。それでも、応答には的確さと速さが必要ですし、大規模に提供しても採算が取れなければなりません。
私は、評価フレームワークと検証レイヤーの 2 つに分けて考えています。本番導入前は、評価フレームワークによって必要な改善を促すべきです。本番運用では、顧客の行動や失敗事例を新たな評価ケースに変えるフィードバックループが必要です。
この好循環は回るほどに勢いを増しますが、うまく機能させるのは非常に困難です。
分野の専門家が欠かせません。スポーツ統計の評価では、熱心なファンがどんな質問をするかを理解している、スポーツ雑誌の編集者などに協力してもらいました。プロンプトだけで始めることはできません。人間が持つ深い専門知識を、最初からシステムに取り入れる必要があります。
うまくいったことの 1 つは、チームづくりです。課題を明確に定義し、データサイエンティストとエンジニアからなる少人数のチームで始めました。OpenAI の顧客現場で支援するエンジニアも私たちと協働し、絶対に外せない少数の要点をさらに絞り込みました。
最初は対応範囲です。音声やテキストのインターフェースでは、ユーザーはほぼ何でも質問できるので、まずシステムが答えるべきでない内容を決めました。ガードレールが最優先でした。
評価では、元となるデータセットから始め、モデルを使ってバリエーションを増やして拡張しました。今でいう、作成役と確認役を分けるメイカー・チェッカー方式を構築しました。一方のモデルが質問への回答方法を考えるのを助け、もう一方は対抗する目的を持つ検証役、つまり審査役の LLM として機能しました。
そこから、審査役は誰がテストするのか、という新たな問いが生まれました。検証役の設計そのものが、評価の課題だったのです。Codex は、評価ケースの生成やシステムの更新といったチームの作業を加速させました。しかし、開発が速くなっても、判断や検証が不要になるわけではありませんでした。
本番環境でモデルの有効性を監視する仕組みに、もっと早く投資します。
P99 レイテンシなど、従来のインフラ指標は今も重要ですが、それだけでは不十分です。本番環境でのモデルの有効性も監視する必要があります。
まず、技術的に可能なことと企業内の現実には、大きな隔たりがあります。フロンティアモデルが発表されるたびに対応できていなくても、それは御社だけではありません。
次に、活動量ではなく成果に目を向け続けることです。目に見える動きを、意味のある進歩と取り違えるのは簡単です。特に、企業が投入量の指標を重視している場合はそうです。たとえば、生成したコードの行数だけでは、意味のある価値を生み出したかどうかはわかりません。
最後に、ほとんどの企業は、必要とされる人間のスキルと主体性を過小評価しています。一般的なスキル研修だけで済む話ではありません。リーダーに必要なのは、的確に判断しながらこれらのツールを活用できる人材です。優れたエンジニアに Codex のようなツールを渡せば、成果は何倍にもなり得ます。しかし、本番システムを検証する判断力がなければ、リスクも何倍にもなります。
手にしているのは、いわばロケットです。特に本番システムでは、検証とガードレールが必要です。そして、操縦を任せる相手を正しく選ぶ必要があります。
