「AIは作れる。でも、プロダクトのかたちが描けなかった」──株式会社Quixotiks 有吉哲郎 CEOに聞く、Flowzと走り抜けた4ヶ月

熟練者の「暗黙知」をアルゴリズム化し、ユーザーの行動変容を導く対話エンジン「QX Engine」を開発する、株式会社Quixotiks（キゾティクス）。カウンセラー、理学療法士、生活支援員といった専門家の対話術を、認知神経心理学に基づくロジックでAIに実装し、介護・就労支援・メンタルケアといった現場で社会実装を進めている会社です。

その同社が、QX Engineの価値を現場に届けるためのプロダクトとして世に問うたのが、介護特化型音声AI対話アプリである。対話エンジン側には確かな技術を持ちながら、それを「高齢者が日常で触れるかたち」に落とし込むフェーズで、同社はFlowzに相談を持ちかけた。

ユーザーが触れる体験そのもののゼロから設計、Figma上で動くプロトタイプ、オフショアのエンジニアと連携したフロントエンド開発、そして高齢者施設での実証実験。約4ヶ月でPoCのスタートラインに立ち、そこから現場で起きたある変化まで。

Quixotiks代表取締役CEOの有吉哲郎さんに、Flowzの阿部がお話を伺いました。

「AIは作れる。でも、画面の作り方がわからなかった」

Flowz 阿部（以下、阿部）： 最初にFlowzにご相談いただいたとき、有吉さんの中で一番大きかった課題は、どのあたりにあったんでしょうか。

Quixotiks 有吉さん（以下、有吉）： そうですね。我々はもともと、対話エンジンそのものをつくる部分にはきちんとスキルがあったんです。専門家の暗黙知をアルゴリズム化して、ユーザーの行動変容を導く対話ロジックを実装する。技術としてはある程度自信を持って組めるんですが、それを 「どうプロダクトとしてユーザーに届けるか」 が、まったくの手探りでした。

少し簡単な管理画面くらいなら、社内で作ってみたこともあるんです。けれど、いざ触ってみると、画面遷移の設計がしっくりこなかったり、分かりにくいインタフェースになっちゃったりして。AIのモデル側がどれだけよくできていても、ユーザーが触る面がこの状態だと、価値が伝わる前に離脱されてしまう。そういう手応えのなさが、ずっと残っていました。

阿部： AI技術そのものよりも、それを「届ける」部分が見えていなかった、ということですね。

有吉： まさにそうです。「アイデアはある、エンジンもある、けれど画面が描けない」。この感覚は、AI系のスタートアップだと、けっこう多くの方が共感されるんじゃないかと思います。

「アプリ作ったことありますよ」では、足りなかった

阿部： その後、業界イベントを通じてご紹介いただいたのが、最初の接点でした。

有吉： はい。共通の知人がイベントの場で、「うち、こういうことをやっているんですけど、ソフトウェア部分やアプリケーションのところがわからないんです」と相談したところから始まりました。そのとき、Flowzさんともう一社、別の会社さんも紹介していただいて、両社にお話をうかがったんです。

正直に言うと、もう一社さんも技術的に劣るわけではなかった。ただ、お話を聞いていて、決定的な差があったんですね。

阿部： どのあたりに、差を感じられましたか。

有吉： 端的に言うと、「アプリを作ったことがあります」と「高齢者向けのプロダクトを作ってきました」の差 でした。

我々が向き合おうとしているのは、高齢者の方が使うアプリケーションです。一般的なtoCサービスとは、設計の前提がそもそも違う。文字の大きさ、ボタンの数、起動のトリガー、誰がそれを設置するのか──こうした「特殊解」が積み上がってはじめて、現場で使ってもらえるプロダクトになる。

Flowzさんはこれまで、まさにそういう領域でプロダクトを作ってきた実績があった。話していて、こちらの言葉が通じる感触があったんです。「ここはこうしないと高齢者は使えない」と、こちらが言わなくても出てくる。それは、もう一社さんとは決定的に違いました。

我々に不足していたのは、ユーザーがどう触れて、どう体験するかをかたちにする力。インタラクションや画面構成といったUI/UXの全体設計を、しっかり伴走してくださる明確な根拠があった。それで、Flowzさんにお願いすることに決めた、という経緯ですね。

Figmaの上で「動く」プロトタイプが、商談のかたちを変えた

阿部： プロジェクトが動き出してからの話を伺っていきたいのですが、進め方の面で、まず印象に残っていることはありますか。

有吉： たくさんあるんですけど、最初に挙げたいのは、Figma上で実際に動くプロトタイプを最初に作ってもらえた こと。これは、想像していた以上に効きました。

阿部： いわゆるモックアップというよりは、画面遷移まで含めて触れる状態、ということですね。

画面遷移イメージ

有吉： そうなんです。イメージ画像としてのデザイン、いわゆる「絵」じゃなくて、ちゃんと動くものとしてお示しいただいた。もちろん、その背後のAIはまだ別系統で動かしている段階ですが、「ここを押すと会話画面に遷移します」「会話のフローはこういう順番で進みます」というのが、Figmaの中で確認できる。

これは開発の認識合わせとして優れていたのはもちろんなんですが、もうひとつ、想定外に大きかった効用があって。営業の場で、これがそのまま商材になった んです。

開発前のプロトタイプ

阿部： 当時はちょうど、実証実験の協力先を探しているフェーズでしたよね。

有吉： はい。実証実験を引き受けてくださる施設を探さなければいけない段階で、これがあるとないとでは、商談の質がまったく違いました。

紙の資料で「こういうアプリを作る予定なんです」と説明していたら、おそらく半分も伝わらなかったと思うんです。けれど、目の前で動かして、「これを押すと会話が始まります」「会話画面ではこんなふうにキャラクターが応えます」と見せながら話すと、相手のリアクションがまったく変わる。

特に高齢者向けのプロダクトは、本人が使う前に、周りのサポート役や決裁者に「使わせたい」と思ってもらう必要があるんです。施設長や、ご家族や、現場のスタッフさんに、「あ、こういうものを高齢者に使ってもらうんですね」と一目で伝わるかどうか。動くプロトタイプがあったから、その「絵が湧く」状態を商談の最初から作れた。これは、本当にありがたかったポイントでした。

阿部： 実際の商談で、その場でフィードバックを拾えたシーンもあったと伺いました。

有吉： ありましたね。プロトタイプを触ってもらいながら、「もう少し文字を大きくしてほしい」「これは顔（キャラクター）があった方がいいんじゃないか」みたいな声が、その場で出てくる。

通常なら、リリース後にアンケートやインタビューをして初めて気づくような課題が、プロトタイプ段階でどんどん拾えてしまう。デバイスをスマートフォンにするかタブレットにするかも、ある施設の方が「これ、スマホだと高齢者には難しいから、タブレットの方がいい」とおっしゃってくださって、その場でタブレット前提に方針が固まりました。

ログインや認証も、「自分で入力するのは難しいから、こちらで事前にセットアップして渡す形がいい」と。ちょっとした見た目の話に見えて、実はそれがビジネスモデルそのものに直結してくる話なんです。タブレット貸出型にするのか、アプリ単体で売るのか。早い段階でプロダクトが「動くかたち」で世に出ていたからこそ、こうした意思決定の輪郭が、想定よりずっと早く見えてきました。

「どこは自分たちが握るのか」が、最初から明確だった

阿部： プロジェクトマネジメントの面では、いかがでしたか。

有吉： これも本当に助かった部分なんですが、スケジュール管理と、役割分担の明確さ が、際立っていました。

いつもきちんとしたガントチャートがあって、そこに「ここがQuixotiksさんの確認ポイントです」「ここまではFlowz側で進めるので、放っておいてくださって大丈夫です」と、はっきり書かれている。

これ、些細な話に聞こえるかもしれないんですが、けっこう他社さんだと曖昧になりがちなところなんです。「この画面、これから変わるんですか、もう確定なんですか」がわからないと、こちらとしては営業の場で見せていいかどうかすら判断できない。決裁者に説明する資料も作れない。

阿部： 「これはまだ動く、これはもう固まった」の境界が見えないと、こちら側も動けない、と。

有吉： そうそう。Flowzさんの場合、「ここは自分たちが握っている部分」と「ここはFlowzに任せている部分」が、常に明確 だった。だから私は、自分が集中すべきところに集中できた。バックエンド側のAI開発に時間を使ったり、実証実験先の開拓に動いたり。プロジェクトのオーナーシップが、明確に分担されているという感覚です。

正直、最初は「本当にこの期間でできるんですか」と疑っていた部分もあったんです。AI関連の助成金スケジュールが絡んでいて、本来かなりタイトな設定でした。でも結果として、想定どおり──というか、むしろ想定より短い期間 で、11月にスムーズに実証実験をスタート、3月にデータが集まり、4月・5月で次のフェーズに進めた。

「この4ヶ月で本当にできるんだ」というのは、正直、最初から最後まで驚きでした。

想像していた以上に、「提案してくれる」チームだった

阿部： チームの動き方として、印象に残っていることがあれば教えてください。

有吉： 一番びっくりしたのは、「自発的に提案してくれるチーム」だった ということです。

正直に言うと、最初に発注した時点では、「指示したことを忠実に形にしてくれるチーム」をイメージしていたんです。仕様を渡したら、その通りのものが返ってくる。それで十分ありがたい、というくらいの想定でした。

ところが、実際にはまったく違って。「ここはこうした方がいいと思うので、こう変えてもいいですか」「この画面の遷移、ユーザー目線だとこちらの方が自然です」と、こちらが思いつく前に提案が上がってくる。

しかも、レスポンスが超早いんです。テスト中に「これくらい、すぐ直せますか」とお願いすると、もう次にメッセージを返した時には更新されている、みたいな体制で。多分、私の目に入っていないところでも、チーム内で相当緻密にコミュニケーションを取ってくれているんだろうな、というのが、出てくるアウトプットから伝わってきました。

阿部： チームの構成として、ベトナム拠点のエンジニアと、日本側のディレクター・デザイナーが連携するかたちでした。そこのコミュニケーション面で気になられた部分はありましたか。

有吉： 最初は、多少のターン数の増加はありましたよ。間に翻訳的なコミュニケーションが挟まる分、立ち上がりの段階では「あ、こうやってやり取りするんだ」と慣れる時間が必要だった。これは、まあ、しょうがない部分です。

ただ、慣れてからは、まったく問題なかった。むしろ感心したのは、間に入ってくださるFlowzのメンバーが、すべてをビジュアルベースで見える化してくれた こと。エンジニアへの指示もフローも、図と動きで共有される。だから、こちら側からも常に「いまどうなっているのか」が見えていて、不安を感じる瞬間がほとんどなかった。

正直、「これくらい自発的に提案してくる、しかもレスポンスが早いチームが、本当にベトナムの方なんですか？」と疑ったくらいです。後から振り返ると、Flowz側でハブとなる方が、日本とベトナムをまたぐコミュニケーションを丁寧に設計してくださっていたんだろうな、と。そこの設計の上手さが、結果のすべてに効いていた気がします。

UAT（受け入れテスト）のドキュメントが、そのまま「型」として残った

阿部： 開発の終盤、UAT（ユーザー受け入れテスト）のフェーズではいかがでしたか。

有吉： これも感動した部分なんですが、UATの手順書を、信じられないくらい細かくドキュメントにしてくださった んです。

我々が「ここはちゃんと動いているか」「この仕様で意図通り作られているか」を確認するためのものなので、開発側との認識合わせの命綱になる資料なんですね。それが、スライドで「この画面ではここを確認してください」「このボタンを押すと、こういう挙動になります」と1ステップずつ整理されていて、必要なところには動画まで添えられている。

これを順に追っていけば、こちら側で誰が確認担当に立っても、ばらつきなくレビューできる構造になっていた。仕様の通っているか否かを、お互いに同じ目線で見られる状態が、最後まで担保されていた んです。

UAT受け入れテスト時の資料

しかも、これは納品物として優秀だっただけでなく、「型」として弊社の中にも残った という感覚があります。次のプロダクトで開発会社さんと仕事をするときも、このフォーマットを下敷きにすれば、UATの精度をある程度担保できる。「やる」だけじゃなく、「やり方を引き継げる状態」にして渡してくれる。ここは、本当に学びの大きいポイントでした。

実証実験で見えた、ある利用者の変化

阿部： 11月の実証実験スタートから、3月にデータが集まるまでの数ヶ月で、特に印象に残っている事例があれば伺えますか。

有吉： いくつかあるんですが、ひとつ、仮説が現場の行動として現れた、象徴的なケース がありました。少し具体的にお話しさせてください。

ある高齢者施設で、今回のアプリケーションを利用していただいた方の中に、個室で暮らしているおばあさんがいらっしゃったんです。その方は、共同トイレに 一日何十回も 行かれる方で、最初は単純に頻尿なのかな、と思われていました。

ところが、現場のスタッフさんがよく観察すると、どうも違うらしい、と。トイレに行くと、スタッフさんが手伝いに来てくれて、そこで世間話ができる。ご家族も毎日は来てくれない。寂しさを紛らわすために、トイレに行くという行動を繰り返していた ということが、だんだんわかってきたんですね。

阿部： 行動そのものが、コミュニケーションの代替になっていた、と。

有吉： そうなんです。そして、その方の居室に設置させていただいたところ──トイレの回数が、めちゃくちゃ減った んです。

おそらく本人にとって、寂しさが「トイレに行く」という行動を上回るほど、今回開発したアプリケーションとの会話で紛れていたんだと思います。会話相手ができたことで、寂しさを埋めるためにわざわざ移動する必要がなくなった。結果として、本人の生活の質が上がっただけじゃなく、ケアスタッフの方の業務負担も大きく軽減 されました。

これは、我々がもともと描いていた仮説──「孤独の解消」と「ケア提供者の負担軽減」を同時に成立させる──が、現場の行動の数字として、はっきりと現れたケース でした。あとは、こういう方々を見つけて、いかに届けていくかだ、というふうにフェーズが切り替わっていった瞬間でもありました。

阿部： Flowzが設計の段階で重視していた「ボタンをなるべく押させない」「会話のトリガーを自然にする」という考え方が、ここに結びついていたのではないかな、と感じています。

有吉： まさにそう思います。高齢者の方に「アプリを使ってください」「ここを押してください」とお願いするのは、それだけで導入のハードルになる。だから、なるべくボタンを介在させず、自然に会話が始まる設計を選んだ。あれは本当に、設計者として優れていたと思います。

そして、この事例から ビジネスモデル側の発見 にもつながった。施設に届けるよりも、もしかしたら 「在宅にいる高齢者」の方が、今回のようなアプリを必要としている層が大きいのではないか という方向性が見えてきたんです。プロダクトを早く世に出していたからこそ、こういう戦略的な発見にたどり着けた。それは、開発のスピード感そのものが生んだ価値だと思っています。

次に活きる「設計の資産」

阿部： 今後の展開について、教えていただける範囲でうかがえますか。

有吉： 今回のアプリケーションは、我々にとってあくまで第一歩で、QX Engineを軸に、これからいくつかの領域へ展開していこうとしています。対象となるユーザーが変われば、当然、求められるインターフェースのかたちも変わってくる。文字の大きさひとつ、会話のトリガーひとつ、設置のされ方ひとつ、すべて作り直しに近い水準で再設計が必要になる。そこは引き続き、Flowzさんの知見に頼っていきたい領域です。

ただ、今回の取り組みでひとつ確信できたのは、「インタラクションやインターフェースをはじめとしたUI/UXの設計プロセスそのものが、再利用可能な資産になる」 ということなんです。

「どんなユーザーに、何を、どう触れさせるか」を一緒に考え抜き、UATの型まで含めて残してもらった。このプロセス自体が、対象が変わっても活きる骨格になっている。これは、最初にFlowzさんと、ゼロから一緒に作ってきたからこそ得られたものです。「ただプロダクトができた」ではなく、「次のプロダクトの作り方が手に入った」感覚 ですね。

「アイデアはあるけれど、プロダクトのかたちが見えない」フェーズの方へ

阿部： 最後に、有吉さんと同じような立場にいらっしゃる経営者・開発者の方へ、Flowzをおすすめするとしたら、どんなポイントになりますか。

有吉： 「プロダクトのかたちを、ゼロから一緒に考えてくれる」ところ ですね。

「デザインも何もない、アイデアはあるんだけれど、どんなユーザー体験にすればいいか、どんな機能の順に触ってもらえばいいか、どんなセリフが要るのか、ピンと来ていない」──そういう状態の会社って、たぶん想像以上に多いと思うんです。特にAI系のスタートアップは、エンジン側はゴリゴリ書けるけれど、ユーザーの体験を一から組み立てるノウハウがない、というケースが本当に多い。

Flowzさんは、そのフェーズから対等な目線で一緒に考えてくれて、UI/UXとして「触れるかたち」に落としてくれる。そして、見えてきたものをそのまま実装まで運んでくれる。最初の壁打ち段階から信頼関係ができるから、「じゃあ最後までお願いしたい」と自然に思える んですよね。

我々のように、「技術はある、けれどプロダクトのかたちはまだ見えていない」という会社は、世の中にきっとたくさんあるはずです。もし周りにそういう方がいたら、私は必ず紹介したいと思っています。

阿部： 今日は本当にありがとうございました。引き続き、よろしくお願いいたします。

有吉： こちらこそ、ありがとうございました。

プロジェクト概要

• クライアント： 株式会社Quixotiks（キゾティクス）

• 代表取締役CEO： 有吉 哲郎 氏

• プロダクト： 介護特化型音声AI対話アプリ

• 期間： 約4ヶ月（設計〜実証実験スタートまで）

• 体制： Flowz（UI/UXデザイン・フロントエンド開発・PM）／Quixotiks（QX Engine・バックエンドAI）

• 成果： 高齢者施設での実証実験を実施。利用者の行動変化として、孤独感の軽減とケアスタッフの負担軽減を確認。在宅向けへのビジネスモデル拡張の手応えも獲得。

「AIは作れる、でもプロダクトのかたちが描けない」──そんな課題感をお持ちの企業さま。ヘルスケア、介護、医療、メンタルケアなど、ユーザー特性が独特な領域でサービスを立ち上げようとしている方。アイデア段階の壁打ちから、まずはお気軽にFlowzにご相談ください。