個として強いマネージャーへ。対話型音声AI を支えるEMのあり方 ── Tech and Me #7
「対話型音声AI は、AIだけでは成立しないんです」
IVRyの対話型音声AI プロダクトが提供するのは、ただ“会話がうまいAI”ではありません。ユーザーとの対話品質を磨き込み、それをブレなく届け続けるシステムをつくり、さらにお客様が迷わず運用できる形に落とし込む──この3つが揃って、はじめて価値になります。
今回お話を伺ったのは、AI対話領域でEngineering Manager（EM）を務める新井 康平さん。AIとソフトウェアの“境界”に立つからこそ見える難しさと面白さ。過去の意思決定から得た学び、そして、AIとソフトウェアの境界に立つマネージャーとしての向き合い方が、どう変わっていったのかを語ってもらいました。
本シリーズ「Tech and Me」では、IVRyのエンジニアが“技術との向き合い方”を通して、自分やチーム、そしてIVRyという組織をどう前進させているのかを語ります。日々の意思決定や価値観、挑戦の裏側を通して、IVRyの技術文化を紐解きます。
新井 康平（@SpicyCoffee66）
クックパッド株式会社にて、バックエンド開発・検索基盤の改善・マネジメントに長年従事。2024年9月にIVRyへ入社。入社当初はプロダクトエンジニアとして開発を牽引し、現在はAI対話システムのソフトウェアエンジニアリング領域を統括するEngineering Managerとして、技術的な意思決定と組織開発の両面を担う。
AIエンジニアリングとソフトウェアエンジニアリングの交差点
── 現在、IVRyでどのような役割を担い、どんな問いに向き合っているのでしょうか。
現在は、アイブリーのコア機能であるAI対話システムの開発チームで、Engineering Manager（EM）を務めています。AIエンジニアリングとソフトウェアエンジニアリングが複雑に絡み合う領域で、中長期的な開発の意思決定とチーム運営の両面を見ています。
── 「AI」と「ソフトウェア」、その境界線はどこにあるのでしょう。
対話型音声AI のアイブリーというプロダクトは、AIの性能だけでは決して成り立ちません。AIエンジニアリングが主に担うのは、たとえば「エンドユーザーの発話に対して、AIがどれだけ正確に、滑らかに応答できるか」といった、対話の品質やタスク完了率を高めることです。
一方で、それをプロダクトとして安定して届け続けるには、ソフトウェアエンジニアリングの力が欠かせません。たとえば外部のLLM（大規模言語モデル）のAPIが落ちたとき、あるいはレスポンスが極端に遅くなったときに、ユーザー体験を損なわずにどうフォールバックさせるか。これはAIの性能以前に、信頼性の高いソフトウェアを設計する必要があります。
また、IVRyは「最高の技術を、すべての人と企業に届ける」というミッションを掲げています。IT技術に詳しくないクライアントでも、直感的にAIの挙動を設定できる画面をどう設計するか。設定した内容が対話にどう反映されるのかをどう確認してもらうか。こうした「コントローラブルなシステム」を構築することも、今僕が向き合っている大きな問いですね。
── 対話型音声AIならではの難しさ、というのはどういった点にあるのでしょうか。
まず、Webアプリケーションとはトラフィックの特性が根本的に違います。ブラウザからのアクセスは、リクエストを投げてレスポンスが返れば基本的にそこで完結します。一方で電話は、通話中ずっとサーバーとエンドユーザーの電話機とのコネクションを握り続けなければなりません。
また、AIを活用することの難しさとして、システムの中に非決定的な振る舞いが入り込んでくることがあげられます。LLMは同様の入力に対して違ったレスポンスを返してくる。
これらの特性が、システムの振る舞いや信頼性の担保に独自の難しさを生みます。これまでのWeb開発の経験だけでは通用しない、新しい引き出しが必要になる領域なんです。
対話をつくるプロダクトエンジニアリング
── まさに対話という体験をエンジニアリングで支えているのですね。
そうなんです。対話の開発って泥臭いし難しい。でも、そのぶん面白い。
僕たちが扱っているのはクライアントさんの業務を支える対話システムなので、会話だけではなくて、業務フローや現場で使われる外部システムの挙動まで考えてプロダクトに落とし込まないといけない。いわゆるプロダクトエンジニアリングが重要になってきます。
── 具体例について教えてください。
たとえばレストランボードやTableCheckなどの飲食店の予約管理システムとの連携です。IVRyが持たないデータを持つサービスとの連携が実現したことにより、接客で忙しい店員さんを介さずに、AIだけで予約を完結できる体験を提供できるようになってきています。
逆にいうと、人間がフォローアップせずとも違和感なく予約が完結し、クライアントの業務も電話をかけてきたユーザーの体験も破綻しないシステムを提供しないといけない。そのためには、飲食店での予約がどのように行われているのかというドメインに対する理解を深める必要があります。どんな項目をどの順番で聞いていて、もし埋まっていた場合はどうしているのかなど、実際の現場で何が行われているのかを詳細に知らないといけない。開発の際には PdM を中心に、実際に電話をかけてみるようなこともしていました（笑）。
── それは確かに泥臭いですね。
他にも、API のレスポンスが遅れた際、その待ち時間が無言だとユーザーの離脱につながるので、システムから「少々お待ちください」のような発話を入れるようにしています。
こういう実装は地味ですが、対話プロダクトの品質を決める重要な要素です。技術だけで解こうとせず、現場の実態を掴んだ上でプロダクトに落とし込む。「すべての人と企業に」使ってもらうプロダクトを目指しているので、この辺りは丁寧にやっていきたいなと思っています。
予約連携の事例を紹介
価値から考えるプロダクトの意思決定
── 新井さんは前職のクックパッド時代から、高度な技術的意思決定をされてきたと思います。これまでで最も「難しかった」と感じる決定は何ですか。
振り返ってみると「純粋な技術選定」自体に、それほど難しさを感じたことはない気がします。技術の前にある「仕様」や「やりたいこと」を定義するプロセスに時間を使ったり頭を悩ませたりすることが多かったように思います。“問いの設定”の部分ですね。
前職で、レシピ投稿の「検索結果への反映時間」を短縮するプロジェクトを手がけたときの話が分かりやすいかもしれません。当時は、投稿してから検索に反映されるまで最長で24時間かかっていました。これを改善しようとなったとき、最初に出てきた方針は「投稿をリアルタイム反映にしたい！」でした。
── 投稿して即座に反映される。エンジニアなら挑戦したくなる目標ですね。
ええ。でも、技術的に「完全なリアルタイム」を、あの膨大なトラフィックの中で実現しようとすると、アーキテクチャは極めて複雑になります。開発・運用コストも跳ね上がるし、プロジェクトの成功確率も下がってしまう。
そこで僕は問い直したんです。「本当に即座に反映されないと、ユーザーは幸せになれないんだっけ？」と。
── 本質的なニーズを掘り下げたわけですね。
レシピ投稿者の体験を考えると、レシピを投稿したその日に誰かから感想が届けば十分うれしいですよね。それなら、必ずしもリアルタイムである必要はない。
そこで、ユーザー体験と運用負荷のバランスを見直して、「投稿が数分以内に反映されれば目指す体験は十分に成立する」という仮説を立てました。結果として、「リアルタイム」という言葉に引っ張られるのをやめ、目標を5分更新に再定義したんです。
── その結果、何が変わったのでしょうか。
アーキテクチャが劇的にシンプルになりました。エンジニアはどうしても「高い技術的ハードル」を越えることに目がいきがちですが、事業やユーザーにとっての最適解は、必ずしも技術的な最高到達点ではありません。
「何のためにそれを作るのか」を考え抜き、顧客に届ける価値を最大化する。この“チューニング”こそが、事業開発を推進するエンジニアに求められる最も重要な意思決定だと思っています。
独断ではなく助言から導く
── 意思決定をする際、個人的に大切にしているプロセスについて教えてください。
とにかく「いろんな人の話を聞く」こと。これに尽きます。僕は自分のことを、特定の技術領域におけるスペシャリストだとは思っていません。特定言語の内部処理に誰よりも詳しいわけでも、AI対話のアルゴリズムをゼロから発明したわけでもない。
だからこそ、詳しい人に聞く。これは徹底しています。ただし、ゼロベースで「どうすればいいですか？」と丸投げするのではなく、自分なりに「こういう理由でこうしたい」という叩き台を用意して、筋を通したうえで相談しに行きます。
── ティール組織の「助言プロセス」のような考え方を取り入れているとお聞きしました。
そうですね。ティール組織の考え方を全部支持しているわけではないんですが、「意思決定の精度を上げるために、関係者や専門家から助言を集める」というプロセスには強く共感しています。
最終的な意思決定の責任は、リーダーである自分が持つ。けれど、そのための材料は、開かれた場で衆知を集めて精査する。この手順を踏むと、自分の言葉に自信が持てるようになりますし、結果として組織全体の納得感も高まるんです。
僕にとって、いろんな人の話を聞いて、複雑な事象を咀嚼して、一つの意思決定として言語化することは、そこまで苦じゃない。でも、それが周りから「助かります」と言ってもらえる。だったら、それが僕の得意であり役割なんだろうな、と。そう思えるようになってからは、迷わずこのスタイルを貫けるようになりました。
プレイヤーからEMへ。責任の重さを受け入れる覚悟
── 入社当初から役割も変わってきたかと思います。その変遷についても伺えますか。
入社して最初の半年程度は、自分もガリガリとコードを書いていました。その後、半年ほどDev POという役割を担いました。技術に軸足を置きつつ、Project Onwer と二人三脚でプロジェクトを牽引する役割です。各種状況を鑑みて施策の優先順位を議論したり、開発メンバーと協力して案件の見通しを立てたり、エンジニアのリソース配分を調整していくような仕事をしていました。
そして今は、正式にEngineering Manager（EM）というタイトルになりました。実務としてはDev POの頃からマネジメントに近いことをやっていたんですが、EMになって明確に変わったのは、評価と採用が責任範囲に入ったことです。
── 評価を担うことで、心境の変化はありましたか。
ありましたね。Dev POは、基本的にはプロジェクトと成果に集中していればよかった。でもEMは、メンバーの人生やキャリアに踏み込むことになります。
たとえば「この人のグレードを上げるために、どんなチャレンジが必要か」を考える必要がありますよね。これは、プロジェクトを前に進めるのとは別の観点になります。判断がそのまま本人のキャリアにも影響するので、軽く扱っていいような話でもありません。それと同時にチームが役割を果たすにはどういうケイパビリティが必要なんだっけ？という点も考えないといけない。メンバーの will とチームの must を擦り合わせる意識は、以前よりもかなり強くなりました。
採用についても同じで、単に「採用に貢献するぞ！」ではなく、「今のIVRyに足りないピースは何か」という、より経営に近い視点でチームのケーパビリティを考えことが必要になる。自分ひとりで解決するフェーズから、組織全体の力を底上げするフェーズへ。役割が変わったことで、僕自身の視座も強制的に引き上げられました。
「マネージャーは裏方」という意識からのアップデート
── IVRyでのマネジメントを通じて、新井さん自身がアップデートされたと感じる部分はどこでしょうか。
実は今、大きな内省の真っ最中なんです。これまでの僕は、どちらかというとマネージャーは裏方であるという意識を持っていました。メンバーが歩く道にある障害物を取り除いて、最高のパフォーマンスを出せるように支える。マネージャーの役割は、黒子としてそれを徹底することだと思っていたんです。
── それは一般的に、良い上司の条件として語られることも多いですよね。
そうなんです。でも最近、それがどこかで「自分はプレイヤーとして第一線を降りた」という感覚を言い換えたものになっていなかったか、と考えるようになりました。
自分の中には、ものづくりの世界って難しい課題をスマートに解くスタープレイヤーが一番かっこいい、という価値観がある。そこで勝ち続ける自信が持てなくなったから、「支える側に回ればいい」と自分に言い聞かせていたんじゃないか。そんな後ろめたさや、一種の諦めが混じっていた気がするんです。
でも、IVRyがこれからさらに成長して、社会に大きな価値を届けにいくなら、その一員であるマネージャーがその価値観を持っていたらダメだなと思った。
── サポートの先にある、新しいマネージャー像ですね。
スタープレイヤーが集まるチームを率いるなら、マネージャー自身も「強い存在」である必要がある。メンバーの成果を最大化するのは前提として、そのうえで「組織としてどこに向かうのか」を自分の言葉で示して、チームを牽引しないといけない。
「自分は裏方だから」という耳ざわりのいい言葉で逃げるのをやめて、僕自身がこの組織の主人公の一人として振る舞う。自分がマネージャーとして強い個であることが、結果として最高の組織をつくることにつながると信じています。
信頼の積み上げがキャリアを作る
── キャリアや技術に向き合う上で、一貫して大切にしている価値観はありますか。
これも逆説的かもしれませんが、「キャリアをゴールに置かない」ことですね。実は僕、これまであまり「何年後にこうなりたい」みたいなキャリア戦略を立てたことがないんですよ。
── 目標がない中で、どうやって歩む道を決めてきたのでしょう。
僕にとって、仕事のサイクルはすごくシンプルです。
目の前の課題にちゃんと向き合う
その積み重ねで信頼が貯まる
信頼を前提に、より大きな課題を任される
これを淡々と回す。それがキャリアの本質だと思っています。
誰かの役に立つことをやって、その結果として「あの人に任せれば大丈夫だ」という信頼が積み上がる。そうなれば、肩書きは後から勝手についてくるものだと思っています。
── 前職での部長経験や、IVRyでのEMという立場も、その積み上げの結果だと。
そうですね。「マネージャーになりたい」と思ったことは一度もありません。でも周りから「今の組織にはこの役割が必要だから、やってみてほしい」と言われて、自分でもそれが妥当だと判断したから引き受けてきた。
結局、信頼の積み上げこそが、エンジニアとしての、そして人間としての唯一の生存戦略なんだと思っています。目の前の仕事に真摯に向き合うこと。結局はそれが一番の近道なんじゃないでしょうか。
技術で社会を本気で変えたい人へ
── 最後に、IVRyでこれから挑戦したいと考えている方々へメッセージをお願いします。
IVRyの面白さは、技術を後付けで使っていないところにあります。多くの企業が、既存の事業を伸ばすための手段としてAIを使おうとしますが、IVRyは創業時から「AIというテクノロジーで、社会をどうリデザインするか」という思想から始まっています。
技術で変化を起こしたい、という純粋な衝動を持っている人にとって、ここはかなり居心地がいいと思います。
── ビジネスの成長スピードも、技術的な刺激になっているのでしょうか。
もちろんです。ありがたいことに導入していただいているクライアントが増え、扱うデータの量も質も変わっていく中で、昨日までの正解が今日には通用しなくなる。そんな課題がどんどん降ってきます。
ただ、常に意識していることは、技術はあくまで価値を生むための武器だということです。自分の書いたコードが、誰のどんな課題を解決し、どう価値を提供しているのか。そこまで想像して、責任を持ちたい。そんな人と、ぜひ一緒に働きたいですね。
キャリア登録 / カジュアル面談
IVRyでは「イベントや最新ニュース、新着ポジションの情報を受け取りたい」「会社について詳しく話を聞いてみたい」といった方に向けて、キャリア登録やカジュアル面談の機会をご用意しています。ご興味をお持ちいただけた方は、ぜひ以下のページよりご登録・お申し込みください。
