研究が前提の新規事業の作り方 ─ 会話AIロボットを ChatGPT 前から作って得た知見

この記事は MIXI DEVELOPERS Advent Calendar 2025 19日目の記事です。

生成 AI を主軸にしたプロダクトを 8 年作ってきた中で得た知見を書きます。

1. はじめに：私と Romi について

2017年1月。ChatGPT はまだ先、そのベースになる Transformer の論文が出る前夜ごろに 会話 AI ロボット Romi のプロジェクトは始まりました。
スマートスピーカーのような便利なツールではなく、心通い合わせられるような、ユーザーを元気づけてくれるような雑談会話をできる会話ロボットを作ろう。そんな思いでプロジェクトは立ち上がりました。

「雑談」は話題の幅がとてつもなく広いので従来からあるルールベースの仕組みだけでは難しく、 Romi はプロジェクトの開始時点から生成AIで話すことを目指しました。
その Romi は2020年6月に先行販売開始、2021年4月には量産販売を開始し、世界初の「ディープラーニング技術を用いて言語生成し会話する家庭用コミュニケーションロボット」として認定されました。

そんな Romi プロジェクトの1人目のエンジニアとしてコードベースづくりから組織づくりまで取り組んで来た中で得た知見をこの記事ではお話します。

「研究をプロダクトに活かすことがなかなかできていない」そんな悩みに対する一つの知見になれば幸いです。

この記事での大きなテーマは以下の2つです。

• チームと人材 ─ 研究とプロダクトをつなげられるチームを作る
• 事業の進め方と文化 ─ 研究とアジャイル

2. チームと人材 ─ 研究とプロダクトをつなげられるチームを作る

Romi は雑談会話を主軸とするプロダクトです。
雑談は掴みどころがなく、何を作るのか、どう評価するのかがとても曖昧なプロダクトです。
企画サイドが思いついた「こんな会話を作りたい」をそのまま作れば終わり、というものではなく、技術と企画的アイディアがお互いに影響を与えながら発展していく必要がありました。
（ChatGPT が発展した今では事情はだいぶ変わってしまいましたが）

そのような曖昧性の高い技術ドリブンなプロダクトでユーザー価値を届けられるチームを作るには、プロダクト思考と技術を兼ね備えた人材が必要になります。
この章ではその中でも、「プロダクト思考な研究者」と「企画と研究をつなげる人」について書きます。

2.1. プロダクト思考な研究者

研究者の2タイプ： アカデミック思考とプロダクト思考

研究に秀でた人には、大きく分けて次の2つの価値観があります。

• アカデミック志向：新規性、厳密な評価、論文での発表を価値とする
• プロダクト志向：研究をユーザー価値に変換することを価値とする

大きな組織の研究所ではアカデミック志向が重要になる一方、 新規事業ではプロダクト志向の研究者が必要になると私は考えています。

プロダクト思考な研究者とは

新規事業の研究者に求められるのは「プロダクト思考＋研究力＋実装力」の総合力だと私は考えています。

• 企画意図やプロダクトの方向性を理解して研究ロードマップを描けること
• 日々論文や新たな情報をキャッチし使える程度に理解すること
• 論文を読むだけでなく、実装し、改善し、ユーザーに届けられること

プロダクトは動かしてはじめて価値を持ちます。そして実ユーザー・実環境からのフィードバックは研究・実装の糧になります。
研究者自身が研究をプロダクションに組み込むことまでは難しくとも、作ったものをチーム内の人がすぐ試せる環境を作る、可能な限り実環境に近い場所で動かすといった思考を持っていることは重要です。

組織の規模が大きくなってくると論文を書いたり学会発表をしたりといった研究専業のエンジニアも必要になるかもしれませんが、プロダクトにフォーカスしている初期には論文よりも世に出すことに重きを置きます。
（もちろんプロダクトの性質によっては論文やアカデミックなプレゼンスを最初から重要視するのもありです）

Romi で活躍した研究者の素質

Romi の場合、幸いにもこれらの素質を持った研究者を採用できました。
彼が持っていた（またはチーム内で獲得していった）素質をいくつか紹介します。

• プロダクトの方向性を理解し、研究ロードマップを描ける
  • 内定後の初顔合わせで「僕ならこう作る」というロードマップを語ったのが印象的でした
• 日々論文を読み、公開実装を自分で試せる
• OSS の中身を理解し、速度・拡張性など実用上の問題点を改善できる
  • OSS を使える人は多いが、改良・修正できる人は希少
  • 公開している事例：
    • medusa head / speclative sampling で高速化
    • 音声認識モデル Whisper の推論をほぼ倍速に高速化した話
    • その他公開してないですがいろいろ
• vLLM / DeepSpeed / Ray などの研究周辺技術を学び使いこなせる
  • 推論基盤や大規模学習まで一気通貫で扱える能力は少人数から始まる新規事業では重要

彼自身は前職では研究職ではなく、趣味で機械学習や強化学習をやっていた人でした。
後述する Romi の開発文化の中で上記のような能力を開花させていきました。

2.2. 企画と研究をつなげる人

多くの組織で、研究と企画というのは遠い位置にあることが多いのではないでしょうか。
そのような組織・文化が、研究を研究に閉じたものに向かわせ、良くも悪くも研究組織をアカデミックな方向性に行かせてしまっているのではないかと思っています。

新規事業で研究をプロダクトに落とし込んでいくには「企画と研究をつなげる人」の存在も重要です。
どういうところで役に立つのかはこのあとの「事業の進め方と文化」の章で話そうと思いますが、ざっくりと以下のような行動が必要だと思っています。

• 橋渡し： 企画的なプロダクトの今後の方向性や本質的に実現したい価値を大雑把に理解しつつ、研究方面で将来何が実現しうるのか企画・研究双方に提案する
• 技術的な最適化： 持続的に開発可能な枠組みを作ったり、研究的な手法を使わなくてもできる部分の切り分け、研究がうまく行かなかった場合のフォールバックの仕組みづくり
• 期待値調整： 研究は時に企画の人を過度に期待を抱かせたり、過度に失望させたりします。中長期視点で、現実的にどの程度のものができうるかの期待値調整は重要な仕事です

Romi では私がこのポジションで仕事をしていました。
したがってこの記事に書いてある全体を包括的に行っていくのも「企画と研究をつなげる人」のお仕事かもしれません。

実際には研究やその橋渡しといった人材が負う責務は、そのチームのメンバーの特性ややりたいことによって変わってくると思います。

2.3.プロダクト思考な人の育て方

新規事業においては、企画からエンジニア、研究者まですべての人がプロダクト思考であるべきだと私は考えています。
研究にかかわらず、プロダクト思考なメンバーを育てるために私が必要と考えているのは以下です。

• プロダクトの大きな方向性を示す
  • Romi がどんな存在になってほしいか。
  • 「いつもオーナーの味方でいてくれる。落ち込んでいても話していたら3分後にはくすっと笑っている。」などの与えたい価値ベースの方向性。
  • プロダクトオーナーなど、ユーザー価値に責任を持つ人からトップダウンに伝えます
• 様々なアイディアの風呂敷を全員が広げる
  • 「プロダクトの方向性」に従って実現性はおいておいてどんなことができたらよいかのアイディアを出し合う会を Romi では定期的に開いていました
    • 「風呂敷を広げる会」とか「妄想する会」とか呼んでました
    • ワイワイみんなで夢を語ってテンションを上げてきましょう！
  • 「実現性は考えない」とすることでみんながイメージする理想の感覚を近づけることができます
    • 「アイディア出したら作る責任が・・」を防ぎアイディアを出しやすくする
    • この方法で大事なのは、アイディア書いたんだから作れるよね、みたいな圧をかけないこと
    • 誰かが「これは流石に無理かも」と思ったアイディアでも、別の誰かが「近いことならできるかも」と言い出してくれることも
  • トップダウンな方向性に従って、ボトムアップにアイディアを出し、方向性を整えつつメンバーのオーナーシップを高めます
    • 人は主体的に考えたという感覚があるほどオーナーシップを持つようになります
• フィードバックを全員が見れるようにする
  • モノを作ったら全員が体験できたり、フィードバックを得られるようします
  • 特にユーザーからのフィードバックを得られるパスを作るのは重要です
    • ユーザーからのフィードバックがあることで、ユーザー視点の文化が育ちます
  • Romi では、主に3つのフィードバックルートがありました
    • SNS
    • 展示会
    • ユーザーインタビュー
      • 企画のトップがユーザーインタビュー系の経歴の人だったのがとても大きかったです！

このようなフローでモノを作っていく、そして研究メンバーもこのプロセスの中に参加していくことで、自然とユーザー視点やプロダクト思考の文化が根付きます。

2.4. 研究者とエンジニアの関係性

お互いにリスペクトを持ちましょう。

研究者の中には「俺は高度なことをしているんだ」とエンジニアを見下すことがいるかもしれませんし、エンジニアの中には「研究者の書くコード汚くてプロダクションで使えない」と不満を持っている人もいるかも知れません。
（何ができることを格好良いと感じるかの価値観が違うことが多い。）
Romi ではそんなことは有りませんけどね！

お互いに「自分ができないことをできる人」という認識をもって、お互いのやることにワクワクしましょう。

• 研究者は作ったものを可能な限り見える形で動かして周りをワクワクさせる
• 研究者は作ったものをプロダクションで動かすには自分が考えるよりも多くの障壁を突破しないといけないことを理解する
• エンジニアは、研究者が出してきたワクワクする研究に共感しつつ、それをユーザーに価値をもって届けられる提案をする

これらの空気を作るのに後述する Demo or Die! などがとても大事になってきます。
Demo or Die! を含む、研究を含む新規事業のすすめかたの話を次の章ではしていきます。

3. 事業の進め方と文化 ─ 研究とアジャイル

不確実性の高いプロダクトを作るのにスクラムを始めとしたアジャイルな手法は向いています。
一方、研究は深い専門知識に基づいて長い時間をかけて進むことが多く、スクラムと合わないこともあります。
この章ではこの研究とアジャイルとどう向き合ってきたかを書きます。

3.1. 不確実性の高いプロダクト開発にはアジャイルが向く

Romi のプロジェクトが始まった当初、一般家庭向けの生成系 AI で話すロボットは世の中に存在しませんでした。
世の中の人々が、果たして人間以外に話しかけるのか。ましてやロボットに話しかけるのか。人と話すロボットがどんな価値を届けられるのか。
それらは「やってみないとわからない」世界でした。

このように、「やってみないとわからない」けど「やれば観測できる」世界にはアジャイルやスクラムが向きます。
クネビンフレームワークで言うところの「複雑な領域」です。

出展：エッセンシャルスクラム よりクネビンフレームワーク

最初期：実装無しの検査と適応

Romi では、例えば「人はモノと話すのか」の検証として Wizard of Oz による実験を行っていました。
ぬいぐるみなどと擬似的に話せる環境を作り、被験者には「AIが話します」と言いつつ実は裏は人が話すという手法です。
これによって、完璧な AI ができたとして、人はモノと話すのか？もし話すとしたらどんな形状のものが良いのか？などの検証を行いました。

モノができてからの検査と適応

完璧な AI が作れれば一定の需要はある。その肌感を得たら、次は「その会話システムをどう構築するか」です。

Romi は会話システムなので、まずは社内コミュニケーションツールである Slack で会話できる仕組みを作ってドッグフーディングを繰り返し、並行してロボット本体である実機も作っていきました。

• 高速でものを作り、それをチーム内で体験できる場所に素早く出し、企画・エンジニア全員が体験してフィードバックを得る
• タイミングによって SNS・展示会・ユーザーインタビューなど実ユーザーからフィードバックを得て改善

このループを回すことが重要です。

3.2. 研究はスクラムと相性が悪い・・？

Romi では1週間を1スプリントとするスクラム体制で開発を行ってきました。
しかしながら研究というのは1週間で成果がでるものではありませんでした。

• 実装と違って「作れば動くはず」ではない。期間が不定。
  • 1スプリントごとにデリバリーをして検査と適応をまわすスクラムと合わない
• スプリントごとの成果を求めると、小手先の実装改善に向かってしまう
  • 確実に効果がある短期的なネタに走るインセンティブに
• 一方「かかる時間は不定だから」で期間を管理しないと、無限にずるずる伸びる

このように、成果が出るまでの期間が不定で長くなりがちな研究と、プロダクトとして価値を早く届ける必要があるスクラムとの間で、バランスを取ることが重要になります。

この「どのくらいで成果がでるか/出すべきか」の肌感を企画・研究の双方を理解したうえで期待値調整するというのが「企画と研究をつなげる人」の一つのお仕事です。

これらの問題への対応としてやったこと / やるべきと考えていたことを列挙します。

• 動くものを見せる
  • 気軽さと工数の段階に応じて見せる場所がいくつかあるのが良いです
    • スプリントレビューで Jupyter notebook 上での実験を見せる（気軽）
    • Slack などで新しい AI と会話できる
    • Romi の開発環境向きの実機を使って検証できる（工数かかる）
  • 後述の Demo or Die で詳述しますが、これによって期待値調整や、アイディア創出に役立ちます
  • ユーザー価値に合わない方向に進もうとしてる研究を早期発見
    • 「技術ドリブンでこんなことできそう」に有りがち。それ作ってもよくよくユースケース考えるとだれも喜ばないよ。的な。
• 大雑把なスケジュールを合意する
  • 目標設定や評価のタイミングで各機能がどれくらいの時間でできることを期待するかを伝える
    • 今期中にここまで行きたいね、とか
    • 研究してるとスケジュールのお尻の意識が希薄になりがちなので
• ベースラインを素早く作り、差分をこまめに出す
  • 現在の会話モデルと比較してどうか、という視点で常に新たな会話モデルを作る
  • Romi の場合ひたすら会話 AI を作っていたので、新規ベースラインを作る機会はあまりなかった
    • いきなり「俺の考えた最強の方法」を試そうとして時間がかかる問題への解決
    • 一方、ベースラインを企画に見せて企画の期待値が下がる現象も起きる
      • ベースラインを作ってから改善するという方法論を企画にインストールする必要がある

まとめると、研究にかかる期間のマネジメントはある程度大きめの枠でコントロールし、そのかわり今どうなってるかを見せるところを重要視していました。
可視化によって、企画サイドもその時時の実現可能性に応じて色々な施策を進めることができます。

3.3. Demo or Die!

デモするか死ぬか。とにかくデモをしろ、実環境で動かせ！という言葉です。
私が所属していた京都大学奥乃研究室の教授の好きな言葉でした。

Romi は AI の研究開発からサーバー、アプリ、ハードウェアまで、幅広い技術が結集してできるプロダクトです。
職種も、企画・営業・デザイナー・エンジニア・QA など多様です。

多様なメンバーの共通言語は「動くものを見せる」ことです。

• 数式や数値、仕組みを語られても遠い分野の人は理解が難しい。動かせば、そのユーザー価値を想像できる。
• 動いているものが見れればアイディアが膨らむ
• 数値では表せない質的な情報が得られる
  • 例
    • 「この会話 AI はなんか返しが淡白だ」
    • 「この会話 AI はお馬鹿だけど返しがすっとぼけてて面白い」
    • 「感情識別 AI が sad を angry と勘違いしがちだけど、この例ならたしかに気持ちが分かる」
  • 特に生成系 AI では重要
• できるだけ実環境に近い環境で動かすことで、「あれ、その入力だと動かない」とかに気づける
  • 「なぜかデモのときだけ失敗する」現象を「デモの呪い」と呼んでました
• 今できることと理想のすり合わせの場になる
  • AI 関連の施策は企画側の期待値が「何でもできる」になりがち
    • デモを繰り返すことで、AI にどういうことができて、何が苦手かの肌感を企画の人が掴んでくれるようになる

長らくこの Demo or Die! 精神を大切にしてきたため、 Romi のスプリントはスプリントレビューの時間が長めでかつその殆どがデモです。
これはこれで大変ですが、そこから得られる価値も大きかったです。
ただ、チームの規模が大きくなりすべてを共有するのは時間や情報量的に難しい、となったときの運用の仕方は（いろいろ試しましたが）バチッとはまる解決策は見えないまま終わってしまいました。

この記事を書きながら、実はプロジェクトが始まった2017年にも似た記事 研究開発系の新規事業と似非スクラム を書いていたのを発見しました。そこでも Demo or Die! については書いています。

3.4. 失敗を価値と捉える文化

アジャイルなプロダクト開発では、作ったものをユーザーに当てて、失敗したとしてもそこから知見を得て改善をします。

プロダクト開発をしてユーザーに当てる -> 成功/失敗 -> 知見を得る

研究も失敗から知見を得ようという考えは同じです。
一方プロダクト開発と違うのは、AI 研究の場合データから学習をしても一発でうまく動くことは稀だということです。10回試行すれば9回は失敗します。たぶん。
したがって、失敗したり知見を得たりの回数も開発より多くなります。

研究開発 -> うまく動く/動かない -> 知見を得る -> ユーザーに当てる -> 成功/失敗 -> 知見を得る

これが研究にかかる時間が不確定になりがちな要因です。
企画や研究以外のエンジニアは、研究のこの性質を知っておく必要があります。
「失敗」がネガティブな印象を持ちすぎると研究者は成果の進捗を話しにくくなります。
AI 学習などの試行の失敗も知見として捉えるような文化を作っていくことが大事です。
（ただ、試行ごとの知見の共有とかは Romi でもあまりうまくはできていませんでした。）

これらの成果や進捗の共有は、職種ごとにいくつかのレイヤーに分けて行うのが良いです。
その話は次の 3.5. 研究環境と実環境・デプロイ で話します。

3.5. 研究環境と実環境・デプロイ

研究者が出す成果はコントロールされた環境やデータでの結果であることが多いです。
実世界は遥かに多様性が大きく、想定していない入力もたくさん入ってきます。実世界では思ったように動かない、はよくある話です。

このような研究環境と実環境を橋渡しするプロセスはいくつかあると思っています。

進捗・成果共有のレイヤー

進捗や成果を共有しフィードバックを得るレイヤーをいくつか用意します。

• AI 学習などの試行ごとの進捗や成果
  • 研究者やエンジニア間での知見共有
  • この段階では失敗が多いので、企画などにまで見せると情報過多 & 期待値の過度な低下を招くことがあります
    • 企画サイドの研究への理解次第
  • 1試行ごとには流石に多い気はしますが、学習のノウハウなどを伝える場になります
    • Romi でもできていましたが、もっとここがあるとチームがスケールしたかも
• ラフに価値を出せるものができた時点での進捗や成果
  • 企画も含めたチーム全体への共有
  • できるだけ実環境に近い環境で
  • 細かいところをつめすぎず、一定価値が出せそうなら早い段階で企画を巻き込む
  • ユーザー価値の観点からどこが足りてないかのフィードバックを早期にもらう
  • 不必要な部分の精度向上に時間を割くのを避ける
• 現状のベースラインより少しでも良ければ早期にユーザーに当てる
  • 実環境でのフィードバックを素早く得る
  • よくあるのが重箱の角をつつきすぎていつまでも成果を本番に出せないこと。
    • そして出すのに時間をかけるほどハードルが高まりさらに出せなくなっていく・・
    • 特に生成系では全てにおいて完璧は難しいです。「現状より良ければ出す」を基準にします。

期待値調整

Demo or Die! に従って AI の楽しいデモをするとみんなテンションが上ります。
しかしデモでみた性能が実世界でそのまま出るわけではありません。
すぐに世に出せそうな気がしてしまいますが、ここからが長いよという意識をみんなに持ってもらいます。
プロダクト開発と同じで8割の性能を出すのは2割の労力でできて、残りの2割をつめるのに8割の労力がかかります。

特に AI の場合99%のパターンでうまく行っても1%のハズレにユーザーは敏感です。
デモでは代表的なケースを見せることが多いので、様々なエッジケースに対応していくことも一定必要です。
（一方、上の「進捗・成果共有のレイヤー」にも書いた通り、エッジケースを気にしすぎてなかなか出せないのも問題です。）

ドッグフーディング

研究レベルでのデモで成功したら、企画の人を巻き込んで社内の実環境に近い環境でドッグフーディングをかならずします。
ある程度の時間ユーザーとして使ってみて得られる知見を研究者にフィードバックします。

デプロイ

実世界にデプロイするかどうかは、「要望したものができたら」よりも「今動いているものと総合的に同等以上なら」が良いです。
「要望が満たされたら」にしてしまうと、ドッグフーディングの結果重箱の角をつつき続けていつまでも出せなくなることがあります。
そして期間が長くなるにつれてサンクコストがつもり、デプロイするかの基準も高まっていってしまいます。

それよりも、「今動いているベースラインより少しでも良ければ出していく」の方針のほうが素早く実環境からフィードバックを得られます。研究者のモチベーションも上がります。

3.6. 研究の不確実性を緩和する： フォールバックな実装を作る

研究というのは不確実性の高いものです。

したがって、その不確実さ次第ではルールベースなどの別の仕組みも並行開発するのが良いです。

Romi の場合、最初に作ったのは bot と selector という枠組みでした。
独立して会話をできる bot を複数並べ、それらの応答を selector が選ぶという枠組みを作りました。
そして、 bot の一つとして独自生成 AI で会話するものを作ったり、汎用ルールベースやしりとりのような特化型ルールベース bot を作りました。

• selector
  • 汎用ルールベース bot
  • しりとり特化 bot
  • hogehoge bot
  • E2E AI bot

このあたりの仕組みは Romiの会話の仕組み にまとめてあります。

2017年の開発開始当初は生成 AI は（私の研究力の問題もあり）日本語出せればバンザイくらいのレベルでした。
したがって、多くの会話をルールベースでおこなっていました。

その後優秀な研究メンバーの採用に成功し、 Transformer が出てきたあたりから劇的に AI の能力が上がり始め、次第にルールベースエンジンのルールを削っていき AI に多くの会話を任せるようになりました。

このように、

• 現実的に作れるが到達点は低い（ルールベースなど）
• 実現可能かわからないが到達点は高い（生成 AI など）

を柔軟に組み合わせ/切り替えできる仕組みは事業を持続させるうえでとても役に立ちました。

4. おわりに

ここまで、Romi という「生成 AI を前提にした雑談ロボット」を立ち上げから8年やってきた中で感じたことを

• チームと人材
• 事業の進め方と文化

といった観点から書いてきました。

実はわたしはこの12月末をもって Romi を卒業して、お隣の家族アルバムみてね事業に異動します。
今日研究メンバーの一人と、彼がジョインした直後からの1on1の記録を振り返ったりしたのですが、 RNN に attention 入れたら性能が上がったとか、 HRED とか、 RNN 時代の生成 AI から話が始まっていてとても懐かしい気持ちになりました。
Romi での8年間は、言語系生成 AI が、その夜明け前から世界の中心に躍り出るまでの8年間でした。
言語生成 AI との関わり方も、「いつか花開くかもしれない未来の技術」から「実用的なものが作れる時代」、そしてもはや個別の起業が「作る」というかは「使う」時代へと変遷してきました。

研究に対して必要なことは、この時代の変化に合わせて、そして対象とするプロダクトによって変わってくると思います。
そのなかで「プロダクト思考であること」「とにかく動くものをチーム内外に出してフィードバックを得ること」といった、この記事を貫いている思想が、研究 x プロダクト開発を行う誰かのヒントになれば幸いです。