株式会社インターネットイニシアティブ

生成AI活用でユーザーサポートの効率化を図りたい

──まず、御社の事業内容と品質保証部の役割について教えてください。

杉浦： 当社はISP（インターネットサービスプロバイダー）として創業し、SI（システムインテグレーション）とネットワーク関連サービスという、大きく二つの軸で事業を展開しています。近年は、DX推進に向けた「DXP（DX Platform）」やAI活用にも注力しています。

私たちが所属する品質保証部は、各サービスの開発部門とは独立した立場でシステムテストを行う部署です。社内の全てのサービスをカバーしているわけではありませんが、常時15程度のサービスを対象にテストや評価を実施しています。人員規模は社員が15人程度で、そこにベリサーブさんを中心としたパートナー企業の方々が加わり、合計で約70名が在籍しています。私が着任した3年前と比べると、規模はおよそ倍に拡大しました。

背景としては、それまで開発部門内で完結させていたテストを、より開発業務に集中するために私たちへ依頼したいというケースが増えたこと、各部門で抱えていたテスト部隊を品質保証部へ統合する動きがあったことが挙げられます。新しいサービスが立ち上がるタイミングで、開発の初期段階からテストを依頼される機会も、ここ数年で明らかに増えています。

──今回の評価対象となった「IIJクラウドライセンスポータル」の問い合わせ支援AIと文書整理支援AIは、どのようなものでしょうか。

小野口： 当社は、お客様が専用WebサイトからMicrosoft 365、Amazon Web Services（AWS）、Google Workspaceなど、各種クラウドサービスのライセンスを発注したり、利用料を閲覧したりできる「IIJクラウドライセンスポータル」を提供しています。その中で、今回はMicrosoft 365のユーザーサポートを対象に、AIによる回答機能を組み込みました。

問い合わせ支援AIは、Microsoftが公式に公開している情報へ素早くたどり着けるようユーザーを支援するものです。ドキュメントを検索し、その内容を基にユーザーの質問に対する回答を生成することで、サポートへの問い合わせ件数削減を目的としています。

ただし、それでも問題を解決できず、サポートに問い合わせるケースもあります。その際に、ユーザーの質問内容を整理し、やりとりを円滑にするための機能が、文書整理支援AIです。

一度は見送った生成AI評価

──ベリサーブに協力を仰ぐ以前、生成AIの品質保証や評価はどのように行っていたのでしょうか？

杉浦： 実のところ、これまでは生成AIの出力に対するテストの経験はありませんでした。ただし、生成AIが実用レベルに入って来る中で、社内業務の改善だけでなく、自社サービスに組み込む動きが出てきました。また、「生成AIの出力に対するテストもやりたい」という要望が開発部門から来ていました。そのような中、今回の問い合わせ支援AIと文書整理支援AIの構想自体は2025年秋ごろに持ち上がったわけです。

しかしながら、その時点では生成AIの出力を適切に評価するための方法や体制を整えられていなかったため、生成AI部分の評価は見送ることになりました。結果として、昨年秋の時点では通常のWebアプリケーションとしてのテストのみを実施しました。

──開発部門からの要望に応えられなかったのは、品質保証部のリソースの問題だったのでしょうか、それとも別の理由があったのですか？

杉浦： リソースよりもノウハウ不足の方が大きな原因でした。従来のテストは仕様に基づき、その通りの出力が得られるかどうかと不具合の有無を確認するのが主でしたが、生成AIはその性質上、常に同じ動き方をするとは限りません。今までのやり方が通用しない中で、どうテストすればよいのか、私たちの中に十分な知見がなかったのです。

しかし、翌年には次のサービスリリースがあり、そこでは生成AIの出力もテストしてほしいといった話があったため、準備期間を設けた上で検討を始めることにしたのです。私たちとしても、今後こうした案件は必ず増えていくという問題意識がありました。生成AIに関してキャッチアップしていく必要があるという認識の下、体制などを整備していこうと決めました。

──そうした中で、パートナーとしてベリサーブを選んだ理由は？

杉浦： 2013年からずっと当社のテストや品質保証の業務を担当していて、品質保証部にも常駐いただいていたことが大きいです。そうした信頼関係がすでにあったからこそ、今回も迷うことなくベリサーブさんに相談し、提案を頂きました。

ちょうどベリサーブさんの社内でもAIに関する取り組みが盛り上がっており、「QA4AI（Quality Assurance for AI）」というテーマも議論されていたそうです。また、すでに他案件での実績や事例もあり、それらを基にアイデアを具体的に示していただきました。結果、「これならできそうだ」と判断して、正式に協力をオファーしたという経緯です。

通常のテストとは異なる、生成AIならではのアプローチ

──実際のプロジェクトは、どのようなスケジュールで進んだのでしょうか。

小野口： 支援いただく前段階として、私たちだけで開発側にヒアリングを実施しました。生成AIに対してどういう期待を持っているか、どういった視点で評価してほしいかなどを確認したのが今年3月上旬ごろで、その情報をベリサーブさんに引き継ぐ形で、3月末から具体的な支援に入っていただきました。

そこから本格化したプロジェクトは、最初の2週間ほどで仕様把握と評価対象箇所の特定を行い、続いて評価観点・指標の作成、評価用ツールの選定と実装を進めました。データセットの作成は4月中旬から始まり、実際に評価を始めたのはゴールデンウイーク明けの5月からです。4月末までに幾つかのデータをピックアップして動作確認は済ませていましたが、実際にやってみると想定しきれていなかった部分が次々と見つかり、評価自体は5月末近くまでかかりました。

私たちにとっても開発側にとっても、今回のような体系立ったQA4AIは初めての経験でしたので、最初に計画を擦り合わせ、認識を合わせていく作業がしばらく続きました。3回ほどミーティングを重ね、少しずつ計画を形にしました。

──擦り合わせの段階では、具体的にどのような点に苦労されましたか。

小野口： まず、どのような評価を行い、何がアウトプットとして得られるのかというところから認識を合わせなくてはなりませんでした。その上で、開発側に何を提供してもらう必要があるのか、それを受けて評価側はどのような実装を行い評価していくのか。細かい部分を詰めるために質問を投げ、回答を受けてアップデートするというやりとりを何度も繰り返しました。

具体的には、今回の評価では観点ごとに指標を定め、その指標に沿って質問内容とシステムの応答をスコアリングしていきます。0から1の値でスコアを付け、1が良い評価です。通常のテストであれば1回の結果を基にOKかNGかを判定できますが、そのやり方自体が生成AIの評価では通用しません。生成AIの評価が難しいのは、期待値を定義しづらい点にあるからです。何をもってOKとし、何をもってNGとするか。同じ入力に対しても、生成AIは毎回まったく同じ出力を返すわけではありません。

ただし、当社には「何回評価を実施すべきか」「どのくらいのデータを用意すべきか」といった判断基準そのものに知見がなかったため、そこはベリサーブさんが持つノウハウを基に議論を重ね、二つのアプローチを組み合わせることになりました。

一つは、評価基準や指標を明文化し、それに基づいてスコアを付ける手法です。もう一つは、生成された出力の差異を踏まえ、複数回実行することで平均的な傾向を捉える手法です。

一方で、評価観点の置き方や体系化の考え方については、従来のテストで培われたノウハウが活用できる部分も多くありました。すでに常駐しているベリサーブさんのテストチームのメンバーの協力もあり、比較的スムーズに進められたと感じています。

──実際に評価を進める中では、どのような問題が生じましたか。

小野口： 印象に残っているのは、問い合わせ支援AIにおいてMicrosoftの公式ドキュメントから根拠となる情報を取得する際の処理です。当初は全てのデータを取得する想定でしたが、それだと十数万字を超える膨大な量となり、AIに投げる際のトークンの制約で処理しきれない事象が発生しました。そこで、Microsoftが提供する要約・概要ページから根拠を取得する方式に変更して対応しました。

評価用の環境を用意する上でも工夫が必要でした。当初は社内に閉じたローカルLLM（Large Language Models）を使って評価を行うつもりでしたが、その社内システムと本番環境システムで使用するAIモデルに性能差がありました。また、スコアの信ぴょう性などに懸念が生じる可能性があるとベリサーブさんから指摘を受けました。そこで会社にかけ合って、全社的に実験導入が始まったばかりの生成AIシステムを共同利用させてもらい、より新しいAIモデルで評価を実施できる体制を構築することにしました。私たちだけではなかなか気付けなかった部分でしたが、こうした改善は評価結果の信頼性を担保する上で欠かせないものでした。

3カ月間でプロジェクトを完了できた秘訣

──評価結果を踏まえて、開発側からはどのような反応がありましたか。

小野口： 評価結果を報告した後、開発の担当者とその上長に、初めて経験したQA4AIについての感触や課題を聞きました。総じて前向きな評価を頂いており、次回以降も継続的に取り組み、変更を加えたことで品質が改善されているのか、あるいは悪化していないかを知りたいという意見をもらっています。

特に好評だったのは、「LLM-as-a-Judge」という手法を採用したことで、評価者ごとの属人的なブレが基本的に生じなくなった点です。従来、開発側で実施していたテストは、評価するメンバーがそれぞれの主観で良しあしを付けていたところがあり、そこがLLMによる定量的なスコアリングで解消されたと受け止めてもらいました。加えて、指標ごとの評価や、パターンごとに定量的なスコアを把握できるようになった点も喜んでもらっています。

また、プロジェクトを進める中でもできるだけ毎日コミュニケーションを取り、日々発生している課題を共有し、必要に応じて開発側へすぐプッシュするという体制を敷いていました。実際の作業を担うメンバーとの役割分担を明確にしながら、なるべく停滞しないよう取り組んだことが大きかったと思います。

品質保証部が目指す次のステージとは

──今回のプロジェクトを通じて得られた成果について、どのように捉えていますか。

小野口： 今回構築した仕組みは、「IIJクラウドライセンスポータル」の問い合わせ支援AIと文書整理支援AIに合わせて実装したものですが、共通的に使える考え方や仕組みは、生成AIを組み込んだ他の製品・サービスにも応用できると思います。また、「IIJクラウドライセンスポータル」に関して言えば、現在の製品のスコアリング、いわば「現在地」を把握できたことも大きな成果です。次回以降の改修やAIモデルの変更を行った際に、その影響がどう出ているかを比較しやすくなりました。

──今後、対応を検討しているサービスなどはありますか。

小野口： 今回評価した「IIJクラウドライセンスポータル」のAI機能は、Azureが提供するAIを利用していますが、そのモデルにはリタイア（提供終了）の時期が定められています。そのタイミングに合わせて再評価を行う必要があることは、ほぼ確定しています。今回ご支援いただいた内容を私たちの側でも整備し、社内メンバーでどこまで対応できるかを見極めながら、次回に向けて品質の判断ができる評価体制を整えたいと考えています。

杉浦： この数年でAIの進化は目覚ましく、QAそのものに対するAI活用も、開発に対するAI活用も、社内でどんどん動きが活発になっています。私たちはこれまでシステムテストを主軸とする部門でしたが、AI駆動開発^※1や仕様駆動開発^※2が進む中で、テストの段階で関わるのではもう遅く、開発の上流工程に入っていく必要があると考えています。

※1 ソフトウェア開発の要件定義からユーザーによる運用まで、全ての工程でAIが活用される開発手法。
※2 ソフトウェア開発において要件や設計などの仕様を開発の起点とし、その仕様に基づいてコードの生成や実装、テスト、検証を進める開発手法のこと。

さらに言えば、テストのためのハーネス^※3そのものを構築する役割も担っていくべきでしょう。テストを行う部門ではなく、品質を保証する、真の意味での「品質保証部」としての役割を果たすために何ができるか。これまでとは大きく異なる姿を模索していく段階に来ていると感じています。

※3 テスト目的に応じてテスト活動をAIで自動化するための実行環境や制御の仕組み。

ベリサーブさんとの関係は、これまでQAエンジニアのリソースを提供いただくという側面が大きかったのですが、今回のような新しい価値提供こそ、これから私たちが期待している関わり方です。今後も引き続き、AI活用など従来の支援範囲にとどまらない品質保証の領域でのご支援をお願いしたいと考えています。

──ありがとうございました。