AIのUXは『Guidelines for Human-AI-Interaction』に基づいて決めよう——ACES Meetの事例を添えて—— – ACES エンジニアブログ

こんにちは。株式会社ACESのAIエンジニアの阿久澤です。長らく運動とは無縁でしたが、最近は村上春樹さんのエッセイ『職業としての小説家』に啓発されて、一日一回のランニングを日課にしています（彼は毎日1時間程度走るそうです）。HPは消費しますが、最大HPは上がっている気がしますね。

さてこのブログでは、AIとUXの関係性について弊社で特に意識しているポイントと、弊社のSaaS『ACES Meet』の開発における実践内容について紹介していきます。AIとUXの関係性については、日本のAI企業/開発者の中で強く意識されていると認識しています。例えば、LayerX 福島さんのブログの以下の言葉

AIで体験を構築する部分も、AIの精度は100%にならないという前提で、いかにその間違いをUX的に吸収できるかを考える必要があります。

『AI-UXとAX(AI Transformation)というLayerXの挑戦』より引用

は、AIを機能に落とし込んでいく際のポイントを端的に表していると考えます。

さて、実際に機能開発をする上で「AIの間違いをUX的に吸収する」とは、具体的にどういったことでしょうか？このようなAIとUXの関係性について考える時、弊社ではMicrosoft Researchが提唱した『Guidelines for Human-AI-Interaction』（以下、HAIガイドライン）*1を参考にすることが多いです。このガイドラインは人とAIが協働するUX設計のベストプラクティスを体系的に整理したものであり、具体の機能開発において守るべき原則や考えるべき観点を教えてくれます。

HAIガイドラインはChatGPTの登場より前の2019年に発表されたものですが、そのエッセンスはまだ錆びておらず、むしろLLM時代にあってその重要性を増しているものと考えています。弊社のResearch FellowでありCHIの専門家であるriku_arakawaさん（@rikky0611）が社内に普及させ、AIを機能に落とし込む際のUX設計の指針として弊社で重宝されてきました。

Microsoft Research が 2019 年に提唱した『Guidelines for Human-AI-Interaction』は、人とAIが協働する際のユーザー体験設計に関する18の原則（デザインガイドライン）を、4つのフェーズに沿って体系的に整理したものです。このガイドラインに沿った機能を開発する / UXを提供することで、ユーザーがAIを信頼し、安心して機能を利用するようになると期待できます。

それでは、ひとまずガイドラインをざっと眺めてみましょう。

こちらを見て何か染み入るものはありましたでしょうか。「うんうん」となっている方、さすがです。実務でかなりAIを使っておられることでしょう。逆にイメージがつかなかった方、この次の章で弊社事例をケーススタディとしてご紹介するので、ぜひそちらもご覧になってください。

さて、私としては上記のガイドラインの特徴を「人間中心」の視点と考えています。人間中心とはつまり、AIを単なる自動化ツールとしてではなく、人間の意思決定や行動を補助するパートナーとして位置づけています。例えば、

• 「誤りを避ける」よりも「誤りがあったときにどう対処するか」を重視しています。
• ユーザーがAIを「盲目的に信じる」のではなく、「AIがどのように結論に至ったか理解したうえで判断する」できるように、説明性や透明性を重視しています。

なお、AIとUXに関わるガイドラインとしては、本記事でご紹介するマイクロソフト版のHAIガイドライン以外にもいくつか例があります（例えばGoogleのPAIR Guidebookなど）。そうしたガイドラインの中で、マイクロソフト版は特に人間のメンタルモデルに焦点を当てて「人がどう気持ちよくAIを使いこなしていくか」の設計を丁寧に掘り下げている印象です。また抽象と具体のバランスが整っており、原理原則から実務に落とし込むのに役立つと私的には考えています。

💡 ※参考: A Comparative Analysis of Industry Human-AI Interaction Guidelines

逆にGoogleのガイドラインはもう少し包括的で、例えば「どの業務をAIで代替するべきか」という企画や、「モデル訓練方法」といった開発部分まで言及があります

ここからは弊社のプロダクトACES Meetを事例として、実際の機能開発においてHAIガイドラインをどう活用してきたかご紹介します。
なお本記事では弊社の宣伝も含めてACES Meetを事例としますが、HAIガイドラインの論文にも事例は載っている（Table.1）ので、ご興味のある方はそちらもご覧ください。

3.1 問題設定: 話者分割

『ACES Meet』は、会議を効率的に記録・要約するためのAI議事録ツールです。Zoom、Teams、Google Meetといった主要なビデオ会議ツールと連携できるほか、音声ファイルを直接アップロードして文字起こし・要約を生成することも可能です。

このサービスの大きな強みのひとつが「誰がどの発言をしたか」を識別する 話者分割機能です。一見単純な処理ですが、会議データの特性によって思いの外複雑な処理になります。

たとえばZoom経由で取得した音声データでは、参加者ごとに別々のマイク音声が取得できる場合があります。この場合はマイクごとの分割が明確なので、話者の区別は比較的簡単です（これをマイク間の話者分割と呼びます）。ところが、ひとつのマイクを複数人が共有している「会議室録音」の場合、ひとつの音声ファイルの中に複数人の声が混在しています。また、ユーザーが音声ファイルをアップロードするケースも、基本的には「ひとつのファイル内に複数人の話者がいる」という状況を想定しなければならず、マイク内の話者分割を行う必要があります。さらに難しいのは二拠点にそれぞれ2人がいる（≒合計で2×2=4人が参加）ようなハイブリッド会議で、この場合はマイク内・マイク間の話者分割を併用する必要があります。

「マイク間話者分割」は単純で、それぞれ個別の音声ファイルごとに書き起こしを生成すれば、自動的に話者と発言を紐づけることができます。一方「マイク内話者分割」では、ひとつの音声ファイルから複数の話者を自動的に切り分ける機械学習モデルが動作しています。音声の特徴量をもとに「この声とこの声は同じ人物か、それとも別人か」を推定します。これは機械学習モデルの推定に依存しているため、どうしても誤りが生じます。声質が似ている人を同じ人物と判断してしまったり、逆に同じ人の発話を複数人と誤認してしまったりすることがあります。

ユーザーにとっては「議事録上で発言者が誰なのか分かる」ことが非常に重要であるため、話者分割の精度は体験価値に直結します。ただし、マイク内話者分割は機械学習モデルの推定である以上、完全な精度は望めません。また、ユーザーはACES Meetの導入時点では基本的にマイク内・マイク間という概念には馴染みがありません。このような状況下で、ユーザーがAIの挙動を理解し、AIの誤りを受け入れて使いこなすようなUXを作ることがゴールとなります。

[G1. Make clear what the system can do. / G2. Make clear how well the system can do what it can do] マイク間・マイク内の概念を明確に

先に述べた通り、話者分割には「マイク間の話者分割」、「マイク内の話者分割」の2種類が存在します。ここで重要なのは、ユーザーに「どちらの分割なのか」を明示することです。以下に、実際のACES MeetのUIでどう表現されているかを掲載します

上記は、youtubeなどで良くある動画のシークバーを話者ごとに表したものです（色が付いている部分は発言時間帯です）。録画時の状況としてはハイブリッド会議になりまして、ある会議室に3人と、自宅から参加している人物が2人います。赤色で囲われた名前は「発言者の名前」、オレンジ色で囲われた部分は「誰のマイクで収音しているか」を表しています。

この表記が重要なのは「マイク間の話者分割」、「マイク内の話者分割」で精度が異なるためです。マイク間の分割であれば安心して信頼してよいが、マイク内の分割については誤りが含まれている可能性があります。ユーザーが事前に「ここは信頼して良い / ここは誤りが含まれるかもしれない」ことを知ることで、認知負荷が下がり誤りの修正を効率的にできるはずです。これらの違いを理解してもらうことは、Guideline G1, G2が示す、「システムが何を、どの程度うまくできるのかを明示する」という原則の実践です。

次の節では、ユーザーがどのように誤りを修正するか見ていきましょう。

[G9. Support efficient correction] 人間が効率的に修正する工夫

マイク内話者分割（≒AIによる話者分割）は便利ですが、当然ながら誤りが発生します。大切なのは「誤りが起きないようにする」ことに加えて、「誤りが起きても人間が簡単に修正できる」ようにすること —— Guideline G9で提唱されている Support efficient correction の考え方です。

2種類の誤り

話者分割の誤りには大きく分けて2種類あります。

• 過小分割: 本当は複数人が話しているのに、同一人物と判定されてしまうケース。例えば会議室でAさんとBさんが会話していて、両者の声が似ているため、AIが「同じ人」と誤認する場合
• 過剰分割: 本来はひとりの人間が話しているのに、複数の話者として切り分けられてしまうケース。例えばAさんの声を「Aさん」と「Cさん」に分けてしまう、といった誤り

どちらが直しやすいか？

UXの観点からすると、どちらの誤りがユーザーにとって修正しやすいかが重要です。私たちが検討した結果、過剰分割の方が修正コストが低いという結論に至りました。なぜなら「複数に分かれた話者をまとめる（統合する）」操作は、非常に少ないクリック数で実現できるからです。

一方で過小分割をユーザーが人手で修正するのは容易ではありません。例えば「Aさん」に分類された会議中の発言をすべて確認し、Bさんの発言を見つけるたびにに話者ラベルを振り直すといったような、大きな負担を強いてしまいます。

ACES Meetでの実装方針

この知見を踏まえて、ACES Meetではソフトウェア・アルゴリズムの両面から効率的な修正をサポートしています。ソフトウェア面としては、上記のように数クリックで話者を統合するような機能をリリースしました。一方でアルゴリズム面では、あえて「やや過剰分割気味」に機械学習モデルをチューニングしています。つまり、多少多めに話者を切り分けてユーザーに後から統合していただく手間を許容しつつ、過小分割による負を引き起こす確率を最大限に抑えているのです。

💡「やや過剰分割気味」に機械学習モデルをチューニングするとは、recallとprecisionのバランス調整のようなものです。

また基本的に統合対象の話者は同じマイクに所属しています（「マイクAの話者1とマイクBの話者2が実は同一人物でした」というシーンは想像しづらいですよね）。そのために、前節でご紹介したような「マイク間・マイク内の概念をわかりやすく伝える」UIがあることで、「どの話者を統合すれば自然か」が明確になり、ユーザーは迷わず修正作業に取り組むことができます。

HAIガイドラインには全18項目があり、本記事でそのすべてを掘り下げることはしません。その代わりに、前節で紹介したもの、出来なかったものも含めて、弊社の話者分割に関連するHAIの実践内容を一覧化して簡単にご紹介します。

ちなみに、N/Aはnot applicable（話者分割というユースケースと関わりが薄いもの）で、空欄は「本当はxxxの工夫の余地があるけど出来てないなー」と思ったところです。話者分割という機能一つ取っても、アルゴリズム・ソフトウェアの横断で考えるべきポイントがいくつもありそうなことが伝わりますでしょうか。

先にも述べた通り、話者分割機能の開発にあたってはソフトウェア・アルゴリズムの両面からの工夫が盛り込まれています。そのため、ACES Meetでの機能開発にあたってはプロダクトチームとAIチームの間で多くの協働が必要でした。

一つ大きな問いは、こうした開発テーマの立案をPdMとAIエンジニアのどちらが主導するべきかという点でした。プロダクト開発において開発テーマ選定を主導するのは一般的にPdMだと思います。一方AIの挙動についての深い理解がないと、こうした開発テーマの立案は難しそうに思います。例えば「AIの失敗パターンが過剰分割と過小分割の二通りある」という感覚はAIエンジニアにとって容易に理解できますが、プロダクト全方面を見ている多忙なPdMが無意識的にキャッチアップするのは難しそうです。

この溝を埋める上で重要だったのは、第一に、AIエンジニア側の責務を開発に限定せずに「AIがどう使われるか」の機能設計にまで巻き込む（あるいは染み出す）ことだと思います。またそのためには当然連携を増やしていかなければなりませんが、その辺りの話は前回ブログもご参照ください: AIエンジニアのR&Dが事業に届くまで。

もう一つは、『Guidelines for Human-AI-Interaction』のように体系化されたベストプラクティスをもとに議論することだと思います。HAIガイドラインはMicrosoft Researchの研究結果に支えられた説得力を持ち、ともすれば個人の感性の問題に矮小化される危険があるかもしれないUXについての議論と意思決定を、スムーズにしてくれるものだと思います。

HAIガイドラインの実践にはPdM、UXデザイナー、AIエンジニア、その他すべてのメンバーが知見を持ち寄り、リスペクトを持って協働することが大事だと考えています。ACESでは「人とAIが協働するビジネスプロセスの実現」を掲げており、これを共に実現していく仲間を求めています。もしこの挑戦に共感していただける方がいれば、ぜひ私たちと一緒に取り組んでいきましょう！（ここで採用サイトのリンクを貼る）