はじめに

こんにちは、DeNAでAIエンジニアをしている鈴木（ @x_ttyszk ）です。2025年10月14日に渋谷オフィスでのオフライン開催とオンラインのハイブリッド形式で開催した「DeNA × AI Talks #3 - 生成AIをコアとするプロダクト開発の舞台裏 -」（ connpass ）の開催レポートをお届けします。 本記事では、当日の発表資料と内容の要約をご紹介します。なお、陶山による発表「生成AI時代に問われるのは“どうつくるか”ではなく“何をつくるか”」については動画のアーカイブ・資料公開は行わず、要約のみ紹介しております。

DeNA × AI Talksについて

「DeNA × AI Talks」は、AI技術の最前線に触れ、実践的な知見を共有することを目的としたDeNA主催のトークイベントです。

DeNAでは今年2月にオンラインで DeNA × AI Day を開催しましたが、より定期的にAIに関する情報を発信し、参加者の皆さんと直接交流できる場を作りたいと考え、8月にこのイベントを立ち上げました。これまでのイベントの様子については 過去のレポート記事 からご覧ください。

第3回目となる今回は、「生成AIをコアとするプロダクト開発の舞台裏」と題し、DeNAでの生成AIをコアとしたプロダクト開発の取り組みが紹介されました。DeNAでは生成AIをコアとした「AIネイティブ」なプロダクトの開発が多数進行中です。そこに携わる事業責任者、AIエンジニア、MLOpsエンジニアの3人から異なる観点での知見を共有しました。前回までと異なり職種横断での登壇であったこともあり、エンジニアだけでなくビジネスサイド、学生などさまざまな立場の方に参加いただき、懇親会も今まで以上に盛り上がりました。

動画

オンライン配信のアーカイブをYouTubeにて公開しています。

セッション

ここからは、当日の各セッションの内容をダイジェストでお届けします。

Introduction

登壇者：鈴木達哉（ @x_ttyszk ）

イベントの冒頭では、前回までのイベントに引き続きDeNAが掲げる「AIオールイン」戦略について紹介しました。

この戦略には3つの柱がありますが、本イベントで紹介したのは３つ目の柱「AI新規事業の創出・グロース」に関連する取り組みです。

前述の通りDeNAでは生成AIをコアとした「AIネイティブ」なプロダクトの開発が多数進行中です。「AIネイティブ」なプロダクトとは、プロダクトの核となるサイクル自体にAIのフィードバックループを組み込み、それによってユーザー体験価値が継続的に高まっていくプロダクトと定義しています。本イベントでは、その開発の中での知見を紹介しました。

その他、AIのコンサルティングやソリューション提供を行う新会社 DeNA AI Link の設立や、国内外スタートアップ連携・戦略投資などの取り組みも行なっています。

生成AI時代に問われるのは“どうつくるか”ではなく“何をつくるか”

登壇者：陶山拓也（ @0xtouyan ）

AI恋活アプリ「fromm」の事業責任者である陶山拓也より、AI技術が急速に進化していく中でどういったプロダクトをつくるべきかについての紹介がありました。なお、本発表は動画のアーカイブ・資料公開は行っておりません。ご了承ください。

生成AI時代に潜む課題とAIネイティブ製品の必要性

AI技術水準は急激に高まり、「Chatbots」から「Reasoners」「Agents」へと進化していますが、この波は影響が全方位におよび、変化のスピードが極めて速いのが特徴です。しかし、現状は多くの企業がAI活用において「何もしないか、すべてをやるか」という二極化に陥っており、実業務への統合が難しいという課題があります。

とくに、LLMの登場による供給の爆発に対し、ユーザーの新しい欲望やモチベーションといった需要が追いついていないという「過剰供給エリア」が存在します。この需給バランスを回復させるためには、既存製品の改善ではなく、AIネイティブなプロダクトを創出することで新しい需要を生み出し、需要曲線をシフトさせることが不可欠です。

AIネイティブなプロダクトの「堀」を形成する1+3の鍵

DeNAでは、AIネイティブなプロダクトを「改善サイクルをAIが駆動し、使えば使うほど自分だけの優れたプロダクトとなる」ものとして定義しています。

その持続的な競争優位性（堀）を形成するための要素としては、以下の1+3の鍵があると考えています。

0. コア要素: Recurring Motivation（半永続的なモチベーション）

AIエージェントは反復的なタスクに強く、使うほど体験価値が大きくなる領域と相性が良いです。

1. Momentum Driven Distribution（勢い主導の流通）

フロントエンド製品は模倣が容易なため、勝負の鍵は「デリバリー速度」にあります。顧客体験、ネットワーク、ブランドこそが「堀」を形成し、ユーザーが行動するほどにデータが貯まる（弾み車の着火剤となる）設計が重要です。

2. Proprietary Data（独自の専有データ）

顕在データだけでなく、潜在的、未解釈、あるいは共時的なデータの価値が高い時代になりました。LLMの登場以前には価値に転じえなかった、非構造化されたデータに着目し、それをプロダクトの燃料にできるかが鍵となります。

3. Self Evolving Loop（自己改善する正のフィードバックループ）

AIネイティブなプロダクトの最重要論点であり、「使えば使うほど良くなるプロダクトを作る」という考え方です。特定の領域に特化したベンチマークや、ユーザー行動・エラーを即時吸い上げるパイプラインを構築することで、プロダクトが自己改善する正のフィードバックループを確立します。

frommでの事例

人間の関係性欲求にAIを活用し、10分通話とAI振り返りログという独自のデータを蓄積。AIが親友として機能し、紹介と自己理解のフィードバックループで関係構築を永続的に支援します。

生成AIをコアとするプロダクト開発で使う技術 - 複数AIと対話できるプロダクトと業務を通して -

登壇者：吉田知貴（ @birdwatcherYT ）

AIエンジニアの吉田知貴より、個人開発のマルチAI・マルチモーダル対話プロダクトの開発経験や業務の中で得られた、実装や評価方法の工夫が紹介されました。

マルチモーダル・マルチAI対話

個人で開発した複数のAIキャラクターとテキスト・音声・画像を介して対話できるプロダクトを題材とした紹介です。実装には LangChain を利用しています。コードは GitHub で公開しており、生成AIサービスの無料枠で動かすことができます。こちらがデモ動画です。

システム構成は以下のようになっています。

このプロダクトは主に以下の3つのLLMで構成されています。

• 話者決定LLM：対話履歴から次に発言するAIを判定します。この際、確実に特定のAIを発言させるために、LangChainの構造化出力（後述）を活用しています。
• 発話生成LLM：決定された話者の発言内容を生成します。ユーザー体験向上のためストリーミング出力に対応させています。
• 状況説明LLM：対話の状況に合わせた画像生成用の説明文を生成します。

発話生成LLMでのマルチAI対話の実装においては、ChatPromptTemplateではAIが連続で発話するとエラーとなる課題があるため、会話履歴を文字列にしてすべてを人間の入力として与えるという工夫をしています。

音声合成の際は応答速度の削減が重要で、chain.invoke() ではなく chain.stream() を使い出力をストリーミングで行います。また、「。、?!」などの区切り文字で分割し、小さい単位で音声合成をバックグラウンドで並列実行することで、トータルの応答時間を短縮しています。

構造化出力の活用

話者決定LLMのように、特定の構造での出力を確実に得たい場合には 構造化出力 を活用します。LangChainではいくつかの方法がありますが、推奨されている方法はwith_structured_outputです。利用するLLMのAPIが構造化出力のためのツールを提供していればそれを使い、そうではない場合はLangChainのPydanticOutputParserが使われるようになります。

構造化出力は失敗する可能性があるため、chain.with_retry() によるリトライ処理や、OutputFixingParser を使用して別のLLMに修正を依頼する仕組みを導入することで、信頼性を向上させるといった工夫も大切です。

生成AI時代における評価とプロンプトエンジニアリングの重要性

「最初は高性能なモデルでやって、後から安価なモデルに変えればいいや」「プロンプトは後で洗練させればいいや」といった考えは危険です。従来の機械学習モデルと異なり、LLMによる自然言語の対話体験は定量評価が難しく、一度ユーザーに受け入れられた体験を後から変えることは極めて難しいためです。リリースしないとわからないオンライン評価だけに頼るわけにはいかないため、モデル変更やプロンプト変更時にデグレを防ぐオフライン評価も必要です。オフライン評価時はLLM as a Judgeやルールベースで各プロダクトに応じた評価項目をチェックするとともに、人間による評価も行います。人間による評価の負担を減らすために、プロンプトは最初から洗練させておくことも大切です。

プロンプトの洗練においては、うまく動かない時に指示を足すのではなく、一度全体を見直すことが大切です。ムダに長いプロンプトはコスト増、応答時間増、内容の把握困難に繋がります。また、プロンプトは先頭が同じならば差分計算で高速化できるコンテキストキャッシュという技術が存在します。prefixを不変にし、可変部分は後方に配置するとキャッシュが効きやすくなります。とくに対話はインクリメンタルな情報増加で、速度も求められるタスクなためこの技術が重要になります。

非同期処理の導入による生成AIプロダクトの処理速度の改善

登壇者：黄英智（ @harris0n3ag1e ）

MLOpsエンジニアの黄英智より、生成AIプロダクト開発における「処理精度と処理速度の両立」という課題に対し、非同期処理と並列化を利用した具体的な改善アプローチ、および信頼性を担保する基盤構築について紹介されました。

生成AIプロダクト開発の難しさ：精度と速度の両立

社内業務効率化やtoBサービスにおいて、LLM処理には高い精度が求められます。しかし、処理精度を高めるアプローチ（リーズニングモデルの採用、データの逐次処理、複雑なAIエージェントの構築など）は、一般に処理時間を増加させます。業務効率化の事例では人手でやった方が早いとならないよう、精度を犠牲にしない前提で、重い処理を効率的に捌く仕組みが求められます。

非同期処理導入における考慮事項

処理の非同期化・並列化を成功させるためには、以下の点に注意が必要です。

• 処理内容：LLM API呼び出しのみか、RAG検索など他の計算が含まれるかによって、最適な手法を選択します。

• 出力結果の順番：要件に応じてデータ出力の順番を保つ仕組みを考慮します。

• Worker数の設定：入れるデータの量やリソース設定に応じて、全体の効率を最大化できるようWorker数を調整し、必要に応じてオートスケーリングを導入します。

• 信頼性：LLM API呼び出しのリトライ処理や、問題発生時に結果を再取得できる仕組みを整える必要があります。

非同期処理による応答速度の改善アプローチ

処理精度を保ったまま処理速度を改善するため、LLM処理の非同期化と並列化が有効な手段です。

1. ThreadPoolExecutor + Background Tasks

比較的簡単なアプローチとして、Python標準の ThreadPoolExecutor によるLLM関連処理の並列化と、FastAPIの BackgroundTasks による重い処理の非同期化が考えられます。

• 処理の流れ：クライアントからリクエストを受け付けたAPI Endpointが、LLM処理を BackgroundTasks として実行します。この処理の中で ThreadPoolExecutor を用いてLLM推論を並列化します。

• 結果の取得：処理結果はFirestoreなどに保存され、クライアントはポーリングによって処理の状態を監視し、完了後に結果を取得します。

• 導入効果：精度要求が高いQA作業の効率化プロダクトに採用したところ、LLM処理時間が60%以上削減され、ユーザー体験が改善されました。

2. Celery + KEDAによる堅固な非同期処理基盤

ThreadPoolExecutor と BackgroundTasks だけでは、タスクが非常に多い場合にCPU負担が増加し、処理が不安定になる可能性があるため、より大規模なアプリケーションにはCeleryとKEDAの導入が考えられます。

• Celery：Pythonの非同期タスクキューライブラリで、メッセージブローカー（RabbitMQやRedis）を介してタスクを非同期実行します。これにより、処理の信頼性を高め、リトライや安定性を担保できます。

• KEDA（Kubernetes Event-driven Autoscaling）：Celery非同期処理の待機数に応じてKubernetes上のWorker数をオートスケーリングします。これにより、トラフィックの変動に合わせたリソースの最適化が可能になります。

さいごに

渋谷オフィスの会場では懇親会も開催され、登壇者と参加者による議論や交流が活発に行われ大盛況のうちに終えることができました。

DeNA AI Talksは今後も1ヶ月に1回程度を目安に開催し続けていく予定ですので、引き続きよろしくお願いします。次回のイベントも近日告知予定です。イベント情報は DeNA × AIのXアカウント @DeNAxAI_NEWS で発信しています。ぜひフォローお願いします。