SKYPCEの新機能「名刺音声検索」の検証において、生成AI特有の「読み捨て」現象に対処した品質評価プロセスを紹介します。自動検証ツールによる定量分析とプロンプトのセクション分割改善により、解析精度が約10%向上しました。
1. はじめに
SKYPCEでは、スマートフォン of 利便性を向上させる新機能「名刺音声検索機能」が搭載されました。 この機能は、従来のキーボード手入力を不要にし、マイクに向かって話しかけるだけで瞬時に目的の名刺を見つけ出せるようにする、生成AIを活用した取り組みです。
従来のプログラムであれば、「1つの入力に対して、必ず定義された1つの出力（正解）が返る」という決定論的なテストが可能です。 しかし、生成AI（LLM：大規模言語モデル）を組み込んだ機能では、ユーザーの発話に含まれる細かな言い回しやニュアンスによって、AIの解釈に「ゆらぎ（非決定的な挙動）」が生じてしまいます。
検索機能であるため、ユーザーが「鈴木さんの名刺」と言えば、検索項目の氏名欄に「鈴木」がセットされるという一定の「期待値（正解）」が存在します。 このゆらぎを相手にしながら、いかにしてブレずに期待値通りの正解を高精度で導き出し、お客様に安心してご利用いただける品質に仕上げるか。
今回は、検証チームが開発チームと二人三脚で挑んだ、生成AI品質評価の裏側と、泥臭くもシステマチックな不具合解析のプロセスをご紹介します。
2. 機能紹介：話しかけるだけで複数条件を自動セットする「名刺音声検索」
まずは、今回検証した「名刺音声検索」がどのような機能なのか、具体例を交えてご紹介します。
スマートフォンでの名刺検索画面でマイクボタンをタップし、以下のように話しかけます。
発話例： 「先週会ったABC社の鈴木さんの名刺を検索して」
すると、生成AI（LLM）がこの自然言語を解析・パースし、以下のように各検索項目へ自動的に切り分けてマッピングします。
- 会社名：
ABC社 - 名前：
鈴木 - 名刺交換日：
先週（対応する日付範囲へ自動変換）
さらに、日本語特有の 「様」「さん」といった敬称や、「株式会社」「有限会社」といった法人格を自動的に除外するインテリジェントな処理も行われます。 検索条件が各項目へ自動セットされた後は、ユーザーが画面をタップすることなく自動的に検索が実行され、該当する名刺が画面に表示されます。
外出先や歩行中など、スマートフォンの小さな画面で複数の条件を手入力するのが困難なシチュエーションでも、話しかけるだけでスマートに名刺情報を呼び出すことができる、極めて直感的なユーザー体験（UX）を実現しています。
3. 機能搭載の背景：スマートフォンの機動性を最大限に引き出す
なぜ、この音声検索機能の開発が必要だったのでしょうか。 その背景には、システムをご利用いただいている「現場のリアルな声」がありました。
ビジネスパーソンがスマートフォンで名刺検索を行うタイミングは、「取引先を訪問する直前」や「移動中の隙間時間」など、機動性が求められるシーンがほとんどです。 しかし、片手に荷物を持った状態や、急いで移動している最中に、スマートフォンの画面を何度もタップして会社名や部署名、氏名をキーボードで打ち込む作業は想像以上に煩雑であり、誤操作や誤入力を招く大きなストレスとなっていました。
「もっと直感的に、話しかけるだけで目的の名刺をパッと探せるインターフェースが欲しい」
こうした現場の切実な課題を解決し、ビジネスパーソンの一分一秒を無駄にしない操作性を提供するため、最先端の生成AIを活用した音声検索機能の開発プロジェクトがスタートしました。
4. 【検証チームの挑戦①】「ゆらぎ」を持つAIから、期待値通りの「正解」を確実に引き出すテスト設計
ここからが、検証チームの本当の戦いです。
前述の通り、AIは同じ発話内容であっても、実行タイミングや細かな表現（「～の名刺を検索」「～を呼び出して」など）によって解釈の仕方がぶれてしまう「ゆらぎ」を持ちます。
検証チームのミッションは、 「さまざまな言い回しをされても、高精度で期待値通りの検索パラメータをセットできること」 を証明し、品質を保証することでした。
これを検証するため、私たちは実利用を想定した 「多数のテストバリエーション」 を細かく定義し、網羅的なテスト設計を行いました。
検証パターン例
| 検証パターン概要（検証するアプローチ） | 主な発話の構成イメージ |
|---|---|
| 1. 所有者情報あり（連絡先除く） 所有者情報（誰が持っているか）を軸に、名前、会社、名刺交換日などの主要情報をランダムに組み合わせた基本検索パターン。 |
「[所有者名]が持っている、[会社名]の[人名]の名刺」など |
| 2. 所有者情報あり（連絡先含む） 所有者・主要情報に加え、AIの認識難易度が比較的高い「電話番号」や「メールアドレス」を必ず含めた複合検索パターン。 |
「[所有者名]が持つ[会社名]の[人名]で、電話番号が[番号]の名刺」など |
| 3. 所有者情報なし 所有者を特定せず、会社名や人名、交換日といった項目のみを組み合わせて、幅広く目的の名刺を探し出すパターン。 |
「[会社名]の[人名]で、先月交換した名刺」など |
| 4. 検索外情報（ノイズ）を含む場合 「性別」「年齢」「趣味」など、名刺検索には関係のない言葉が含まれていても、AIが混乱せずに必要な検索項目のみを正確に抽出できるかを検証するパターン。 |
「先週会った、趣味がゴルフの[会社名]の[人名]さんの名刺」など |
これらのテスト設計に基づき、多様なバリエーションの試験データを網羅。 どのような言い回しがなされても、AIが正しく目的の検索窓へと情報を仕分けられるように品質を徹底して精査しました。
5. 【開発秘話・開発経緯】テストツールによる検証と、AI特有の「読み捨て」現象との戦い
実際の検証プロセスを進める中で、私たちは生成AI（LLM）特有の特異な不具合事象に遭遇しました。 それが、名前の 「読み捨て」現象 です。
遭遇したパラドックス（逆転現象）
テスト中、以下のような短い発話を行った際に不具合が検出されました。
- 短い入力の不具合：
ユーザーが「鈴木部長の名刺」と話しかけた際、AIは役職である「部長」は認識してセットしたものの、肝心な名前である「鈴木」を検索条件から読み捨て、欠落させてしまいました。
しかし非常に不思議なことに、情報量が多く複雑な入力を行うと、挙動が変化したのです。
- 長い入力：
「経理部が先月15日に会ったABC社の鈴木部長の名刺を検索して」という、極めて多くの条件が含まれる発話では、会社名も日付も、もちろん名前（鈴木）も役職（部長）も、すべて完璧に抽出されて期待値通りの動作をしました。
短い入力で失敗し、長い複雑な入力で完璧に成功するという、従来のプログラムでは考えられない「パラドックス（逆転現象）」が発生したのです。
開発と検証の協調によるアプローチ
最先端の生成AIを実際のプロダクトとして高い品質で安定稼働させるためには、AIモデル特有の振る舞いを理解し、正確に制御する必要があります。 開発チームと検証チームはＡｌｌ Ｓｋｙの協力体制を活かし、連携しながら技術的なアプローチを推進しました。
「どの発話パターンにおいて、どの程度の確率で読み捨てが発生するのか」を正確に把握するため、自動化ツールを活用し実施しました。 大量の検証用データを自動検証ツール経由で流し込み、AIの応答傾向を多角的に分析・可視化しました。
開発チームはこの検証データをデバッグへとフィードバックし、AIモデルが持つ解釈の仕組みや条件の優先傾向を共同で分析。 検証チームによるデータ収集と、開発チームによるプログラミングロジックが融合することで、原因の特定と対策へスピーディーに進むことができました。
プロンプトエンジニアリングによる解決
この定量的なデータ分析の結果、LLMの特性である 「Lost in the Middle（指示の中だるみ）」 という現象が関係していることが分かりました。
AIへの指示文（プロンプト）が長文で記述されていた際、そのプロンプトの「中部（真ん中）」に書かれたルールや制約事項は、AIにとって効力が弱まりやすく、無視されがちになるという性質です。 これまでの仕様では、特に優先順位を意識せずにプロンプトが一括で書かったため、短い入力時の処理ルールが中だるみ部分に埋もれてしまい、読み捨てが発生していました。
この課題を克服するため、開発チームはプロンプトの記述方法を根本から見直しました。
指示の特性ごとにプロンプトを明確な「セクションで区切る」対策を導入したのです。
[所有者情報の読み捨て防止セクション][敬称・法人格の除外セクション][不適切な入力への対応セクション]
指示をセクション化してAIに明確な構造として認識させることで、短い入力であっても指示の効力が薄れることなく、期待値通りに人名を正しく抽出することに成功しました。 検証チームによる自動検証ツールを用いたテストと、開発チームによるプロンプトエンジニアリングの融合が、この問題を解決した瞬間でした。
6. 検証結果：テストの反復による精度の向上と手応え
プロンプトのセクション分割改善を反映した後、検証チームは再度、網羅的な反復テストを実施しました。
テストと修正を繰り返した結果、課題となっていたテストにおいて、当初の解析精度から約10%の精度向上を記録しました。
7. まとめ：AI時代の品質検証を終えて
生成AIを活用した新機能の検証は、これまでの決定論的なソフトウェアテストとは異なり、品質保証の今までの常識にとらわれない挑戦でした。
「1つの入力に対して、100%同じ文字列が返ってこない環境で、いかに品質を一定以上に保つか」
この「ゆらぎの制御」は、検証チームにとっても大きなパラダイムシフトであり、テスト技術の幅を広げる非常に有益なノウハウの蓄積となりました。 自動検証ツールを用いた定量的なゆらぎ発生率の可視化や、開発チームと密に連携したプロンプトの構造改善といったプロセスは、今後のAI機能検証における「確固たる品質評価プロセス」の基礎となるでしょう。
私たちはこれからも、新しい技術に積極的に挑戦し、お客様が「本当に心地よく、安全に使える高品質なソフトウェア」を提供し続けられるよう、検証技術を磨き続けてまいります。
