論文フォーラムを教師データとしたアプリレビュー分類モデル
市川 直人† a)

本真佑† b)

楠本 真二† c)Classification Model for Application Review Training with Forums
Naoto ICHIKAWA† a) , Shinsuke MATSUMOTO† b) , and Shinji KUSUMOTO† c)

あらまし ソフトウェア開発において，アプリケーションレビューは開発者にとって豊富な情報源である．しかし，レビューは膨大な数が投稿されており，無意味なレビューも多い．これらの情報を開発者が効率良く取得するために，自然言語処理と機械学習を用いてレビューを自動分類する手法が数多く報告されている．これらの手法では主に教師あり学習を用いるため，大量のレビューを目視で確認し，バグ報告や機能要求といったラベルを付与することで教師データを生成する必要がある．またレビューとは別に，エンドユーザが情報を共有する場としてフォーラムがある．特にゲームの分野で盛んな文化で，フォーラムに投稿される各トピックはバグ報告や機能要求などのカテゴリーに分類されている．本研究では，既にカテゴライズされたフォーラムのトピックを教師データとして用いることで，教師データを用意するコストを削減したレビューの分類手法を提案する．実験では，デジタルゲーム配信プラットフォームである Steam 上のレビューを対象に，レビューをバグ報告，機能要求，
その他の 3 種類に分類した．既存手法では教師データの用意に 50 時間以上費やしたが，提案手法では 2 時間程
度で多くの教師データを収集でき，教師データを用意するコストが大幅に削減できた．また，分類精度は既存手法には劣るものの，提案手法は AUC 0.8 以上の精度でレビューを分類できることを示した．
キーワード フォーラム，アプリケーションレビュー，機械学習，教師あり学習，自然言語処理，BERT

発の改善にはつながらない．人気のアプリに対しては

1. ま え が き

1 日に数百件のレビューが投稿されているため，開発

ソフトウェア開発において，アプリケーションレ

者による手作業での確認には限界がある．

ビューは開発者にとって豊富な情報源である [1], [2]．

そこで，膨大な数のレビューから開発者が有用な情

有益な情報の例としては，バグの報告や新機能の提案，報を効率良く取得することを目的とした研究が多く行機能強化の要望，特定の機能に対するユーザのフィー

われている [3]〜[19]．これらの研究では自然言語処理

ドバッグなどが挙げられる．

と機械学習，主に教師あり学習を用いて，レビューをこれらのレビューは，アプリの開発やメンテナンス

その内容ごとに自動で分類する．既存研究では主に，に活用できる．しかし，レビューの中には開発者ではApple App Store や Google Play のようなモバイルアプ

なくユーザを対象とした内容も数多く存在しており，

リ配信プラットフォームに投稿されたレビューを，バ

これらはソフトウェアの改善という目的にはあまり役

グ報告や機能要求といったカテゴリーに分類している．

に立たない．例えば，good や bad などの数単語のみで既存研究の課題として，教師データを用意するコス構成される内容や，インストールできないなど説明のトの高さが挙げられる．機械学習において教師データ不足した問題の報告，顔文字のみの内容などが存在すの数と質は精度に大きく寄与するため，既存手法ではる．これらは対象アプリの印象を共有する，というレ

大量のレビューを目視で精読し，バグ報告や機能要求

ビューそのものがもつ目的に従う内容ではあるが，開といったラベルを付ける必要がある．実際に，Maalej† 大阪大学，吹田市

Osaka University, Suita-shi, 565–0871 Japanら [6] は 4,400 件，Zhang ら [8] は 3,092 件のレビュー
を目視で確認しており，大きな労力を費やしている．

a) E-mail: n-itikaw@ist.osaka-u.ac.jp

そこで本研究では，アプリレビュー分類における教b) E-mail: shinsuke@ist.osaka-u.ac.jp

師データ作成の労力削減を目的として，レビューを目c) E-mail: kusumoto@ist.osaka-u.ac.jp
DOI:10.14923/transinfj.2022JDP7014

電子情報通信学会論文誌 D Vol. J105–D

視でラベル付けする代わりに，既にカテゴライズされNo. 11 pp. 669–678 © 一般社団法人電子情報通信学会 2022

669

電子情報通信学会論文誌 2022/11 Vol. J105–D No. 11

図 1 既存手法の流れたフォラーム上のトピックを教師データとして用いる

教師データを作成するため，アプリストアから幾つか手法を提案する．フォーラムとは，ユーザと開発者がのレビューを抽出し，目視によって個々のレビューが自由に議論できるインターネットコミュニティの一

どの種類に属するかをラベル付けする．既存研究では形態であり，個々のソフトウェアに対して設置される

主に，Apple App Store や Google Play のようなモバイことが多い．例えば Web 会議サービスである Zoom

ルアプリ配信プラットフォームに投稿されたレビューには，Zoom Developer Forum（注 1）が設けられている．

を対象に実験を行っている．分類の区分は研究によっフォーラムはレビューとは異なり，バグ報告や機能要て様々である．Chen ら [4] は，レビューを開発者に

求，一般議論などのカテゴリーがフォーラム管理者にとって有益かどうかで 2 種類に分類し，Maalej ら [6]よって事前に設けられている．よってフォーラムへのは，バグ報告，機能要求，ユーザ体験，評価の 4 種類

投稿（トピック）は，既にカテゴリーごとに分類されに分類している．更に Zhang ら [8] は，バグ報告や機た自然言語のデータであるとみなすことができる．こ

能要求を含む計 17 種類のカテゴリーに分類している．

のトピック群をレビュー分類の教師データとすること

次に自然言語処理を行う．自然言語処理とは，曖昧で，目視によるラベリングコストの大幅な削減が可能な性質をもつ自然言語をコンピュータが扱えるようにとなる．

加工する処理である．具体的には，小文字への統一化

具体的な手法としては，アプリレビューをバグ報告，や単語単位への分割などの前処理や，文章をその特徴

機能要求，その他の 3 種類に分類するために，フォーを表す分散表現（ベクトル）に変換する処理を行う．

ラムのバグ報告，機能要求，一般議論のカテゴリーに続いて分類モデルの構築を行う．分類モデルに対し属するトピックをそれぞれに対応する教師データとして自然言語処理を施した教師データを与えることで，て利用する．フォーラムが設けられているアプリはあ

正しく文章を分類できるように学習を行う．分類モデ

まり多くないが，ゲームの分野ではフォーラムが設け

ルには，ナイーブベイズやロジスティック回帰のようられることが多い．そこで実験では，デジタルゲーム

な古典的な機械学習手法 [4]〜[6] や，深層学習を利用

配信プラットフォームである Steam 上のフォーラムをした手法 [15] など様々な手法が報告されている．

もつゲームへのレビューを対象として，提案手法と既最後にレビューの分類を行う．学習済みモデルに自存手法の分類精度を比較した．その結果，提案手法は

然言語処理を施した未分類状態のレビューを入力する

既存手法に比べて分類精度は低下するが，AUC 0.8 以

ことで，各レビューがどの種類に属するかを判定する．

上の精度でレビューを分類可能だと示した．

2. 準

備

2. 2 課題

既存研究の課題として，データの用意にかかるコストの高さが挙げられる．既存研究はそれぞれ，自然言

2. 1 既存手法の流れ

語処理や分類モデルに独自のアプローチを施すこと

近年，膨大な量のアプリレビューの中から開発者にで分類精度の向上を目指している．一方で，データのとって有益な情報を効率的に取得するために，機械学用意については共通して，数千件のレビューを目視で習を用いてアプリレビューを自動分類する研究が多く

ラベル付けすることで教師データを生成している．機

行われている [3]〜[19]．これらの研究は，図 1 に示し

械学習には多くの教師データが必要であり，目視で教たフローに従ってレビューの分類を行う．

師データを作成する労力は非常に大きい．特にバグ報

まずはデータの用意を行う．教師あり学習に用いる（注 1）：https://devforum.zoom.us

670

告や機能要求に該当するレビューは，レビュー全体に占める割合が少なく，十分な数を確保するためには大論文／フォーラムを教師データとしたアプリレビュー分類モデル

量のレビューを目視する必要がある．実際に Maalej

500 件以上のレビューが投稿され，開発者がその全て

ら [6] は，ラベリングを行うための GUI ツールを作成に目を通すことは困難である [20]．これらのレビューすることで，Apple App Store と Google Play から取得には Apple App Store や Google Play に代表される一した計 4,400 件のレビューを目視でラベル付けしてい般的なモバイルアプリ配信プラットフォームに投稿さる．このような目視で教師データを作成する労力は，れるレビューと同様に，雑多な感想やアスキーアート

アプリの開発者が，自身が開発したアプリに対するレのような開発者にとってあまり役に立たないレビュー

ビューを分類しようとした際に大きな障壁になると考と，バグ報告や機能要求のような開発者にとって有益えられる．

なレビューが混在している．

2. 3 フォーラム
フォーラムとは，レビューと同様にエンドユーザが

3. 提 案 手 法

感想や質問を投稿し，開発者やユーザ同士で自由に議

本研究の目的は，アプリレビュー分類における教師論や情報共有ができるインターネットコミュニティのデータ作成の労力削減にある．そこで本研究では，目一形態である．Arudino Forum（注 2）や Zoom Developer

視でのラベル付けによって教師データを用意する代わ

Forum のように，一般にフォーラムは一つのアプリ

りに，既にカテゴライズされたフォーラムのトピック

ケーションやプロジェクト単位で設けられる．様々なを教師データとする．これにより，目視でのラベル付

内容の投稿が混在しているレビューとは異なり，フォー

けによる教師データ作成のコストを大幅に削減したレ

ラムにはバグ報告，機能要求，一般議論のようなカテビュー分類手法を提案する．具体的には，レビューをゴリーがフォーラムをの管理者によって事前に設けら

バグ報告，機能要求，その他の 3 種類に分類するためれており，フォーラムへの投稿（トピック）はその内に，フォーラムのバグ報告，機能要求，一般議論のカ

容ごとに分類されている．これによって，開発者が開テゴリーに属するトピックをそれぞれに対応する教師発に有益なトピックを確認しやすい仕組みが完成してデータとして利用する．

いる．フォーラムはアプリの開発元が公式に運営して図 2 に提案手法の流れを示す．既存手法との大きないることもあれば，有志のエンドユーザが非公式に運違いは，データの用意のステップである．既存手法で営しているものもある．また，一つのアプリに複数のはレビューを幾つか無作為に抽出して目視でラベル付

フォーラムが存在することもあり，その規模や設けらけを行っているのに対して，提案手法では既にカテゴれているカテゴリーは様々である．ただし，バグ報告

ライズされたフォーラムのトピックを用いるため，目や機能要求，一般議論に該当するカテゴリーは多くの視によってラベル付けを行う必要がない．自然言語処場合で共通して設けられている．フォーラムは全ての理や分類モデルの構築，実際にレビューを分類するス

アプリに設置されているわけではなく，フォーラムを

テップは既存手法と同様に行い，自然言語処理の技術もつアプリはあまり多くない．しかし，アプリの中でや分類モデルは既存研究で用いられている技術の中でもゲームの分野ではフォーラムをもつアプリが比較的も特に分類精度の高かった技術を用いる．詳細は 5. 3，

多い傾向にある．

5. 4 にて述べる．

2. 4 Steam（注 3）

提案手法の最大の目的は，教師データを用意する労は，Valve Corporation が開発したデジタル力の削減であり，分類精度の向上ではない．レビュー

ゲーム配信プラットフォームである．30,000 以上のとフォーラムはどちらもエンドユーザが自身の意見

ゲームが配信され，1 億 2,000 万人以上のアクティブを投稿することのできる場であるが，一般にレビュー

ユーザーがいるなど，PC ゲームのデジタル配信プラッはライトユーザからの投稿が多く，フォーラムはヘトフォームとしては最大級の規模を誇る．

ビーユーザからの投稿が多い傾向にある．そのため，

Steam

Steam では，ユーザはプレイしたゲームのレビュー

レビューとフォーラムに投稿される文章には少なからを投稿することができ，1,000 万件以上のレビューがず性質の違いが生じる．これにより，提案手法の分類

投稿されている．特に人気の高いゲームには 1 日に精度は既存手法よりも低下することが予想される．一方で，提案手法では大量の教師データを用意すること（注 2）：https://forum.arduino.cc（注 3）：https://store.steampowered.com/

ができるため，機械学習において有利に働く可能性もある．
671

電子情報通信学会論文誌 2022/11 Vol. J105–D No. 11

図 2 提案手法の流れ

4. Research Question
本研究では，提案手法の有効性を確認するために，
以下の二つの Research Question（RQ）を設ける．

RQ1: 提案手法の分類精度は既存手法と比較してどの程度か？

RQ1 では，フォーラムのトピックが，レビューを

分類精度を比較する． Fapp B ⇒Rapp A でも一定の精度が確認できれば，フォーラムをもたないアプリへのレ
ビューを分類する場合でも提案手法が適用できることが確認できる．

5. 実 験 手 順
5. 1 概要分類する際の教師データとして機能するかどうかを

本節では RQ を確かめるための実験手順，すなわち確認する．ここで，あるアプリ app のフォーラムか

既存手法と提案手法による分類タスクの実現方法につら得られたトピック群を Fapp ，アプリストアから得いて説明する．図 1 と図 2 に示したとおり，既存手られたレビュー群を Rapp と定義する．更に， Fapp

法と提案手法の本質的な違いは教師データの違いにあを教師データ， Rapp をテストデータとする提案手法

る．よって，これら二つの手法は自然言語処理，分類を，Fapp ⇒Rapp と表記する．既存手法は，教師デー

モデルの構築，分類の 3 手順は共通となる．以降では

タとテストデータの両方にレビューを用いるため，

図 1 と図 2 の流れに従い，データの用意（5. 2），自然Rapp ⇒Rapp と表現できる．本 RQ では，これら二つ

言語処理（5. 3），分類モデル構築（5. 4），評価（5. 5）の手法の分類精度を比較する．3. で述べたように，レの順で説明する．

ビューとフォーラムの性質の違いによって提案手法の5. 2 データの用意

分類精度は既存手法に比べて低下することが予想され実験を行うにあたって，分類対象になるレビューとる．しかし，提案手法でも一定の精度が確認できれば，教師データになるフォーラムのトピックを収集する．

フォーラムのトピックが教師データとして機能するこ

2. 3 で述べたように，ゲームにはフォーラムを設けらとが確認できる．

れることが多い．そこで本実験では，ゲームに対するRQ2: フォーラムをもたないアプリへのレビューを

レビューを対象とし，Steam 上からレビューを収集す

分類する際にも提案手法を適用可能か？

る．これは 2. 4 のとおり，Steam はゲーム配信プラッ2. 3 で述べたように，フォーラムをもつアプリは多トフォームとして最大級の規模を誇り，ゲームに対す

くはない．フォーラムをもたないアプリへのレビュー

る多くのレビューが存在するためである．また，Steamを分類する際に提案手法を適用する場合，別アプリの上の全てのゲームがフォーラムをもっているわけでは

フォーラムを教師データとして利用することが考えらないため，本研究で用いるデータセットとして，Steam

れる．異なるアプリのフォーラムを教師データとしての売り上げ上位のゲームタイトルからフォーラムを用いる場合，そのアプリ固有の表現や文化が影響する

もつタイトルを選定する．売り上げ上位のタイトルをことで分類精度が低下する可能性がある．そこで，異対象とするのは，より多くのレビューを収集するためなるアプリのフォーラムでも教師データとして機能すである．なお，本実験では開発元が公式に運営しているかを調査するために，あるアプリ app A のフォーラ

るフォーラムをもつタイトルのみ対象とした．これら

ムのトピックを教師データとして同じアプリへのレの条件を満たすタイトルとして，Cities: Skylines（注 4）

ビューを分類する場合 Fapp A ⇒Rapp A と，別のアプ（Cities）と Euro Truck Simulator 2（注 5）（Euro）を本実験

リ app B のフォーラムを教師データとしてあるアプリ

app A へのレビューを分類する場合 Fapp B ⇒Rapp A の
672

（注 4）
：https://store.steampowered.com/app/255710/Cities_Skylines/（注 5）：https://store.steampowered.com/app/227300/Euro_Truck_Simulator_2/

論文／フォーラムを教師データとしたアプリレビュー分類モデルの対象として選定した．これらのタイトルのレビュー

表 1 実験データのうち英語で書かれたものと，これらのタイトルのフォーラム（注 6）（注 7） からバグ報告，機能要求，一般議論に該当するカテゴリーに分類されたトピックをスク

CitiesEuro

CitiesEuro

フォーラムのトピック数#バグ報告 #機能要求 #その他 合計
7,007
2,813
5,650 15,470
13,1134,800
4,184 22,097

レイピングによって収集した．
提案手法は，教師データを作成するために目視によるラベル付けを行わずにすむことがメリットであるが，本実験では，レビューを目視でラベル付けする作業を行う．これは，提案手法の分類精度の比較対象として

レビュー数#機能要求 #その他
69 (15)1,000
87 (6)
959#バグ報告
106 (17)63 (5)

合計
1,175
1,104

※括弧内の数値は，レビュー全体から無作為に抽出した約 1000 件に含まれるバグ報告，機能要求のラベルが付与されたレビューの数である．

既存手法を実施する必要があり，その既存手法の適用においてはレビューのラベル付けが必須であることが理と同様の前処理として，出現する全ての文字の小文字

由の一つである．更に，提案手法と既存手法のいずれ

化処理のみを適用した．一般的な自然言語処理としてにおいても，その分類精度を確認するためには分類の正は，ストップワード除去や Lemmatization などが広く

解集合を知る必要があることも理由として挙げられる．

知られているが，BERT ではトークナイズ処理におい収集したレビューからタイトルごとに約 1,000 件をて Byte Pair Encoding が採用されており，それらの前無作為抽出し，目視によりバグ報告，機能要求，その他のラベルを付与した．しかし，バグ報告，機能要求に該当処理は不要であると指摘されている [21]．

5. 4 分類モデル構築するレビューはそれぞれ 20 件以下であり，実験に十分

本実験で用いる分類器は BERT（Bidirectional En-

な数が取得できなかった．そこでバグ報告によくみらcoder Representations from Transformers）[22] を用いてれる単語として"bug"，"fix"，"crash" [6] を含んだ構築する．BERT は 2018 年に Google から発表されレビューの中から 800 件を無作為抽出し，目視によってた自然言語処理を行うための深層学習モデルであり，ラベル付けを行った．その中からバグ報告，機能要求の転移学習によりさまざまなタスクに対応でき，少ない

ラベルが付与されたレビューを実験データに追加した．

データを追加で学習することによってモデルの構築を

機能要求についても同様に，機能要求によくみられる行うことができるという特徴がある．アプリレビュー

単語として"please"，"hope"，"improve"，"need"，の分類においても，ナイーブベイズやロジスティック"prefer"，"request"，"suggest"，"wish" [6] を含回帰による分類モデルに比べて BERT による分類モデ

んだレビューの中から 800 件を無作為抽出し，目視にルが高い精度を示したことが報告されている [23]．

よってラベル付けを行った．その中からバグ報告，機

提案手法はテストデータとは別種のデータソース

能要求のラベルが付与されたレビューを実験データにを教師データとして用いる性質上，学習データの語追加した．

彙に存在しない未知語の存在が精度低下の要因にな

表 1 に収集したレビュー数とフォーラムのトピック

ると考えられる．しかし，BERT におけるトークン数を示す．本研究ではレビューのラベル付け作業に 50

化処理では WordPiece アルゴリズムが採用されてお時間以上費やしたが，フォーラム上のトピックを収集

り，未知語は既知の複数のサブワードに分解される．

するために費やした時間は 2 時間程度である．得られ

例えば"playing"という語が未知語であった場合，既

たレビュー数に対してフォーラムのトピック数は 10

知の"play"と"##ing"の二つの語に分解される．よっ倍以上であり，提案手法では少ないコストで教師デーて，BERT は提案手法と親和性の高いモデルであるとタが大量に用意できることが分かる．

考えられる．

5. 3 自然言語処理
自然言語処理技術を用いてテキストに前処理を施す

本実験では，ラベル付けを行った Cities と Euro のレビューをそれぞれ 7:3 の比率で教師データとテストことによって，自然言語のもつ曖昧さを削減できる場

データに分割し，Rcities ，Reuro ，Fcities ，Feuro の 4 種類

合がある [6]．ここでは利用した BERT-Base-uncasedの教師データでそれぞれ学習した 4 種類の分類器を生成した．なお，本実験では BooksCorpus と Wikipedia（注 6）：https://forum.paradoxplaza.com/forum/forums/cities-skylines.859/（注 7）：https://forum.scssoft.com/viewforum.php?f=3

によって事前学習された BERT-Base-uncased モデルを
ファインチューニングして使用した．今回の実験で設
673

電子情報通信学会論文誌 2022/11 Vol. J105–D No. 11
表 2 ハイパーパラメタ
入力最大系列長
バッチサイズ
最大エポック数
損失関数
最適化手法
学習率

128
32
10
交差エントロピー
Adam [24]3e-5

る．まず，図 3(a) の Rcities に対して既存手法を適用した場合と，図 3(b) の提案手法を適用した場合の比較を行う．AUC に注目すると，既存手法は全てのカテゴ
リーで 0.9 を超えており，高い精度で分類できている．
対して提案手法では，既存手法には劣るものの全てのカテゴリーで AUC は 0.8 以上であった．それぞれの混同行列に注目すると，提案手法では既存手法に比べ定したハイパーパラメタを表 2 に示す．分類モデルとて F 値は一貫して低下する結果となった．特に Cities

しては，ファインチューニング後の最終層の CLS ベクの機能要求では，既存手法でも F 値が低かったが提案

トル（pooler レイヤ）から全結合層に直結する構造を構手法では適合率，再現率共に低下している．逆に Euro

築した．最適化手法には Adam [24] を，損失関数にはではバグ報告の適合率と再現率が低下していた．提案

交叉エントロピーを用いた．過学習回避のために Early

手法はバグ報告，機能要求共にどちらのアプリに対し

Stopping を有効としたが，それ以外の過学習回避の手ても AUC 0.8 以上の精度で分類できる一方で，F 値は段である Dropout 層は設置していない．実験の目的は低い結果となった．このことから，実際の利用シーン

学習データの違いによる効果の確認であり，ハイパー

においては分類のしきい値設定に課題が残ると考えら

パラメタの調整やモデル構造の改善等は最小限とした．

れる．

5. 5 評価

生成した分類器を用いて， Rcities と Reuro を分類

RQ1 の結論：提案手法は既存手法には劣るもの

し ，そ の 精 度 を 調 査 す る ．ま ず ，既 存 手 法 に 倣 いの AUC 0.8 以上の精度で分類が可能である．バグ

Rcities ⇒Rcities ， Reuro ⇒Reuro を実施する．次に，RQ1

報告と機能要求の F 値は低いため分類のしきい値を 調 査 す る た め に 提 案 手 法 と し て Fcities ⇒Rcities ，設定は改善が必要である．

Feuro ⇒Reuro を実施する．最後に，RQ2 を調査するために，提案手法を交差的に適用した Feuro ⇒Rcities ，Fcities ⇒Reuro を実施する．
分類精度は，Precision（精度），Recall（再現率），F1-

6. 2 RQ2: フォーラムをもたないアプリへのレ
ビューを分類する際にも提案手法を適用可
能か？

score，ROC 曲線の AUC（Area under the curve）の四つ

RQ2 では，フォーラムをもたないアプリのレビューの評価指標を用いて評価する．ROC 曲線は，縦軸を真を分類するシナリオを想定して，別アプリのフォーの陽性率，横軸を偽陽性率として，様々なしきい値にラムを教師データとして提案手法を適用した場合の対応する点をプロットした曲線で，AUC は ROC 曲線

分類精度を確認する．まず，図 3(b) の Fcities ⇒Rcitiesの下の面積で定義される．AUC は分類器の性能を特定と図 3(c) の Feuro ⇒Rcities を比較する．AUC に注目すのしきい値に拠らず評価する指標であり，0 から 1 の値

ると，別アプリのフォーラムを用いることで分類精を取る．AUC は分類器の性能が高いほど 1 に近づき，度は低下しているものの，AUC は全てのカテゴリー

ランダムに分類を行う分類器に対しては 0.5 となる．

6. 実 験 結 果

で 0.7 以上であった．次に，図 3(e)Feuro ⇒Reuro と図3(f)Fcities ⇒Reuro を比較する．AUC を確認すると別ア
プリのフォーラムを用いた場合であっても，大きな精図 3 に，本実験で実施した各手法の結果をそれぞれ

度の低下は見られなかった．AUC は全てのカテゴリー示す．図には混同行列と Precision，Recall，F1-score，

で 0.7 以上であった．これらの結果から，アプリ固有

AUC が示されており，黄色でハイライトされた箇所はの表現や文化は分類精度にあまり影響を与えないこと

正しく分類できているレビューの数を表している．まが分かる．

た，図 4 に AUC を算出するための ROC 曲線を示す．
この曲線で区切られた面積で AUC は定義される．

6. 1 RQ1: 提案手法の分類精度は既存手法と比較してどの程度か？

RQ1 では，既存手法と提案手法の分類精度を比較す
674

RQ2 の結論：別アプリのフォーラムを教師データとして提案手法を適用した場合でも AUC 0.7 以上の精度で分類が可能である．

論文／フォーラムを教師データとしたアプリレビュー分類モデル

図 3 実験結果：混同行列

図 4 実験結果：ROC 曲線

7. 考

察

いう単語が除去されるため，空の文章として分類器に入力される． Feuro を教師データとした場合，このよ

本節では，実験結果の考察を行う．本実験の分類対

うに空の文章や 1 単語のみのレビューをバグ報告とし象となったレビューの中から，正しく分類できなかって分類するケースが数件確認できた．また， Fcities をたレビューを定性的に調査することで，その特徴を

教師データとした場合は，空の文章や 1 単語のみのレ

明らかにした．以下に，正しく分類できなかったレ

ビューを機能要求に分類するケースが数件確認できた．

ビューに見られた特徴を示し，その理由を考察する．

このような誤分類の原因として，フォーラムとレ

7. 1 1 単語以下の情報量の少ないレビュー

ビューの性質の違いが考えられる．3. で述べたとお提案手法では，1 単語以下の情報量の少ないレビューり，レビューはライトユーザが気軽に投稿する傾向にをバグ報告や機能要求に誤って分類してしまうケースある一方，フォーラムはへービーユーザが投稿する傾が数件確認できた．例えば Feuro ⇒Reuro では，"a"と向にある．そのため，フォーラムにおける一般議論のいう 1 文字だけのレビューをバグ報告に分類している．

カテゴリーには，1 単語のみのような情報量の少ない

このレビューは，ストップワード除去によって"a"とトピックがほとんど存在しないことが予想される．
675

電子情報通信学会論文誌 2022/11 Vol. J105–D No. 11

このような誤分類を防ぐための改善案として，レビューを分類する前に 1 単語以下のレビューを除外する手法が考えられる．今回の実験結果から 1 単語以
下のレビューを除外したところ，図 3(b)Fcities ⇒Rcities
において，実際にはその他であるが，機能要求と予測してしまった 8 件のうち 3 件が除外された．また，図3(e)Feuro ⇒Reuro において，実際にはその他であるが，バグ報告と予測してしまった 27 件のうち 10 件が除外された．

7. 2 文章量の多いレビュー
既存手法と提案手法のどちらにおいても，一定以上

図 5 誤分類された文章量の多いレビューの例の文章量をもつレビューが正しく分類されていないケースが数件確認できた．これは，BERT における入が大きくなるため，本研究の実験環境では 128 が入力

力長の制限が原因であると考えられる．BERT は，文最大系列長の限界であった．しかし，実験環境によっ

章を形態素単位に分割したリストを入力とするが，入ては入力最大系列長をより大きくすることで，文章量

力は固定長でなければならない．そこで，入力最大系の多いレビューに対応することができる．また，入力列長に満たない文章は空いた部分を無意味なデータで最大系列長を超えた文章をトリミングするのではなく，パディングし，逆に入力最大系列長を超える文章は，分割する手法も考えられる．一つの長いレビューを分

入力最大系列長に合うようにトリミングされる．本実

割して二つ以上のレビューとみなして分類を行い，分験では，文章の先頭から順に入力として扱い，入力最割した各レビューのうち一つでもバグ報告や機能要求

大系列長を超えた段階で残りの部分を無視する手法をに分類されれば，分割元のレビューをバグ報告や機能とっている．表 2 のとおり，本実験では入力最大系列

要求とみなすことで，情報を損なわずに文章量の多い長を 128 としているため，これを超えるレビューにレビューを分類できる可能性がある．

ついては，レビューの一部分が考慮されずに分類が行われる．そのため，文章量が多く文章の後半にバグ報

8. 制

約

告や機能要求に当たる記述があるレビューは，その部

8. 1 フォーラム構造への強依存分が無視されてしまい，正しく分類ができなかったと提案手法が抱える一つの強い制約として，学習デー

考えられる．実際に文章量の多いレビューでは，初めタとなるフォーラム構造への強依存が挙げられる．提に好意的な内容のレビューを行い，その後にバグ報告

案手法はフォーラムの構造を学習データのラベルとしや改善点，不満点を述べる構成のレビューが多く見らて直接利用するため，フォーラム上に設置されていな

れた．

いトピックの文章を分類することはできない．

図 5 に，実際にはバグ報告であるが，誤ってその他と予測された文章量の多いレビューの例を示す．黄色でハイライトされた部分は入力として反映される箇所

Pagano と Maalej らの調査 [25] によると，アプリへのフィードバックは以下 4 種類に大別できる．

• コミュニティ内での情報の共有．他アプリの推薦で，それ以降は入力最大系列長を超えて無視される文やアプリ自体の使い方の共有など．

章である．また，赤でハイライトされた部分はバグを• アプリ自体の改善につながる情報．機能要求やバ報告している箇所である．このレビューは，アプリのグ報告など．

長所を述べたのちに短所を述べる構造だが，入力長の• アプリの評定．称賛や非難など．

制限により短所を述べている途中で文章が打ち切られ• アプリ使用の体験．機能や UI の説明など．

ている．そのため，レビューの後半に書かれたバグを本論文では上記 4 種類のうち，アプリ自体の改善につ報告している箇所が無視されている．

ながる情報に着目し，バグ報告と機能要求の自動分類

このような誤分類を防ぐための改善案として，入力を試みた．バグ報告と機能要求は多くのフォーラムで最大系列長をより大きく設定することが考えられる．

独立したトピックとして設置されることが多く，提案

入力最大系列長に比例して学習時に必要なメモリ容量手法による分類が適するユースケースであるといえる．

676

論文／フォーラムを教師データとしたアプリレビュー分類モデル

他方，それ以外の 3 種類を自動分類するようなユース

別のアプリのフォーラムを教師データとすることで提ケースに適用できるかはフォーラムに強く依存する．

案手法が適用できることを示した．

また機能要求をより詳細なサブカテゴリ，例えば機能今後の課題としては，対象とするゲームタイトルをと非機能へ分類するようなケース [26], [27] への適用

増やし，一般化可能性を向上させる点が挙げられる．

も困難である．このようなユースケースの場合，提案

また今回はゲームドメインを対象に実験を行ったが，手法を用いて自動分類を試みた後に人手によるラベリ

既存研究で主に対象とされているモバイルアプリでのングと併用することで，低コストかつ詳細な分類がで実験も重要な課題である．

きると考えられる．

8. 2 妥当性の脅威

謝辞 本研究の一部は，JSPS 科研費（JP20H04166，

JP21H04877）による助成を受けた．

データセットのラベル付けが分類器の性能に影響している可能性がある．本実験ではまず初めに，著者ら文[1]veloper’s perspective,” Telematics and Informatics, vol.28, no.1,

2 名で数十件のレビューを確認し，バグ報告，機能要求の基準を定めたのちに，著者が 1 人でラベル付けを

pp.22–31, 2011.
[2]

行った．そのため主観の影響が完全には排除できていEmpir. Softw. Eng., vol.27, no.2, p.63, 2022.
[3]

on Mining Software Repositories, pp.41–44, 2013.
[4]

テゴリーの区分は様々である．本実験で対象としたフォーラムとは別のフォーラムを教師データとした場
合に，本実験と同程度の分類精度を達成できるかどう

ketplace,” Proc. Int. Conf. Softw. Eng., pp.767–778, 2014.
[5]

E. Guzman, M. El-Haliby, and B. Bruegge, “Ensemble methods
for app review classification: An approach for software evolution,”
Proc. Int. Conf. Automated Softw. Eng., pp.771–776, 2015.

[6]

W. Maalej, Z. Kurtanović, H. Nabil, and C. Stanik, “On the automatic classification of app reviews,” Requirements Engineering,

ものの F 値は低い傾向にあった．実際の利用シーンにおいては分類結果そのものが重要となるため，分類時

N. Chen, J. Lin, S.C.H. Hoi, X. Xiao, and B. Zhang, “AR-Miner:
Mining informative reviews for developers from mobile app mar-かは明らかでない．

6. 1 で述べたとおり，提案手法は AUC 自体は高い

C. Iacob and R. Harrison, “Retrieving and analyzing mobile appsfeature requests from online reviews,” Proc. Working Conference

2 の二つのゲームのフォーラムを対象として実験を行った．しかし，フォーラムによってその規模やカJ. Dabrowski,
˛
E. Letier, A. Perini, and A. Susi, “Analysing app
reviews for software engineering: A systematic literature review,”

ない．
本研究では，Cities: Skylines と Euro Truck Simulator

献

A. Holzer and J. Ondrus, “Mobile application market: A de-vol.21, no.3, pp.311–331, 2016.
[7]

S. Panichella, A. Di Sorbo, E. Guzman, C.A. Visaggio, G. Canfora,のしきい値設定には課題が残るといえる．この F 値のand H.C. Gall, “ARdoc: App reviews development oriented classi-

低さの理由の一つは，実験に用いたデータの不均衡に

fier,” Proc. Int. Symp. Foundations of Softw. Eng., pp.1023–1027,あると考えられる．その他にカテゴライズされる文章

2016.
[8]

は，バグ報告や機能要求と比べて 10 倍以上の数があり

proach for labelling mobile app reviews,” J. Comput. Sci. Technol.,

典型的な不均衡データである．本論文では損失関数として BERT と同じ交叉エントロピーを用いたが，不均

vol.32, pp.1076–1089, 2017.
[9]

P. Zhenlian, J. Wang, K. He, and M. Tang, “An approach of extracting feature requests from app reviews,” Proc. Collaborate Com-

衡データを考慮した Focal Loss [28] や Dice Loss [29]puting: Networking, Applications and Worksharing, pp.312–323,

等の指標が提案されており，これらを利用することで結果が変化する可能性がある．

L. Zhang, X.-Y. Huang, J. Jiang, and Y.-K. Hu, “CSLabel: An ap-

2017.
[10]

N. Jha and A. Mahmoud, “Using frame semantics for classifying
and summarizing application store reviews,” Empir. Softw. Eng.,

9. む す びvol.23, pp.3734–3767, 2018.
[11]

M. Tavakoli, L. Zhao, A. Heydari, and G. Nenadić, “Extracting

本研究では，フォーラムを用いることで，教師デー

useful software development information from mobile application

タを用意するコストを削減したアプリレビュー分類手

reviews: A survey of intelligent mining techniques and tools,”法を提案した．実験では，デジタルゲーム配信プラットフォームである Steam 上のレビューを対象に，レExpert Systems with Applications, vol.113, pp.186–199, 2018.
[12]

user feedback using traditional machine learning and deep learn-

ビューをバグ報告，機能要求，その他の 3 種類に分類

ing,” Proc. International Requirements Engineering Conference
Workshops, pp.220–226, 2019.

した．その結果，提案手法は既存手法と比べて精度は下がるものの，AUC 0.8 以上の精度で分類ができるこ

C. Stanik, M. Häring, and W. Maalej, “Classifying multilingual[13]

C. Wang, P. Liang, M. Daneva, and M. vanSinderen, “Augmenting
app reviews with app changelogs: An approach for app reviewsとを示した．またフォーラムがないアプリについても，
677電子情報通信学会論文誌 2022/11 Vol. J105–D No. 11
classification,” Proc. Int. Conf. Softw. Eng. Knowl. Eng., pp.398–
403, 2019.
[14]

M.B. Messaoud, I. Jenhani, N.B. Jemaa, and M.W. Mkaouer, “A

ciation for Computational Linguistics, pp.465–476, 2020.

（2022 年 3 月 14 日受付，6 月 20 日再受付，
7 月 27 日早期公開）

multi-label active learning approach for mobile app user review
classification,” Proc. Knowledge Science, Engineering and Management, pp.805–816, 2019.
[15]

N. Aslam, W.Y. Ramay, K. Xia, and N. Sarwar, “Convolutional
neural network-based classification of app reviews,” IEEE Access,市川 直人

vol.8, pp.185619–185628, 2020.
[16]

[17]

F. Rustam, A. Mehmood, M. Ahmad, S. Ullah, D.M. Khan, and2020 大阪大学基礎工学部情報科学科卒．

G.S. Choi, “Classification of shopify app user reviews using novel

同年より同大学大学院情報科学研究科コン

multi text features,” IEEE Access, vol.8, pp.30234–30244, 2020.

ピュータサイエンス専攻博士前期課程在学

M. Häring, C. Stanik, and W. Maalej, “Automatically matching

中．自然言語処理に関する研究に従事．

bug reports with related app reviews,” Proc. Int. Conf. Softw.
Eng., pp.970–981, 2021.
[18]

S. Panichella, A. Di Sorbo, E. Guzman, C.A. Visaggio, G. Canfora,
and H.C. Gall, “How can i improve my app? classifying user re-

本

真佑

（正員）

views for software maintenance and evolution,” Proc. Int. Conf.
Software Maintenance and Evolution, pp.281–290, 2015.
[19]

[20]

2010 奈良先端科学技術大学院大学博士後

K. Srisopha, C. Phonsom, M. Li, D. Link, and B. Boehm, “On期課程了．同年神戸大学大学院システム情building an automatic identification of country-specific feature re-

報学研究科特命助教．2016 大阪大学大学院

quests in mobile app reviews: Possibilities and challenges,” Proc.

情報科学研究科助教．博士（工学）．エン

Int. Conf. Softw. Eng. Workshops, pp.494–498, 2020.

ピリカルソフトウェア工学の研究に従事．

D. Lin, C.-P. Bezemer, Y. Zou, and A.E. Hassan, “An empirical
study of game reviews on the steam platform,” Empir. Softw. Eng.,
vol.24, no.1, pp.170–207, 2019.

[21]

[22]

1988 大阪大学基礎工卒．1991 同大学大intent recognition using a frequency cut-oﬀ strategy for domain-

学院博士課程中退．同年同大学基礎工学部

specific vocabulary extension,” Applied Sciences, vol.12, no.3,

助手．1996 同講師．1999 同助教授．2002

p.1610, 2022.

同大学大学院情報科学研究科助教授．2005

J. Devlin, M.-W. Chang, K. Lee, and K. Toutanova, “BERT: Pre-同教授．博士（工学）．ソフトウェアの生

standing,” Proc. Conf. North American Chapter of the Association
for Computational Linguistics: Human Language Technologies,
pp.4171–4186, 2019.

山田侑樹，櫨山淳雄，“BERT によるアプリケーションレ
ビュー分類モデルの構築と評価，” 信学技報，KBSE2020-38,
2021.

[24]

D. Kingma and J. Ba, “Adam: A method for stochastic optimization,” Int. Conf. Learning Representations, pp.1–15, 2014.

[25]

D. Pagano and W. Maalej, “User feedback in the appstore: An
empirical study,” Proc. International Requirements Engineering
Conference, pp.125–134, 2013.

[26]

T. Hey, J. Keim, A. Koziolek, and W.F. Tichy, “Norbert: Transfer learning for requirements classification,” Proc. International
Requirements Engineering Conference, pp.169–179, 2020.

[27]

M. Lu and P. Liang, “Automatic classification of non-functional
requirements from augmented app user reviews,” Proc. Int. Conf.
Evaluation and Assessment in Softw. Eng., pp.344–353, 2017.

[28]

T. Lin, Goyal P., Girshick R., He K., and P. Dollar, “Focal loss for
dense object detection,” IEEE Trans. Pattern Anal. Mach. Intell.,vol.42, no.2, pp.318–327, 2020.

[29]

X. Li, X. Sun, Y. Meng, J. Liang, F. Wu, and J. Li, “Dice loss fordata-imbalanced NLP tasks,” Proc. Annual Meeting of the Asso-

678

（正員）

Z. Callejas, and J.M. Montero, “Fine-tuning BERT models fortraining of deep bidirectional transformers for language under-

[23]

楠本 真二

F. Fernández-Martínez, C. Luna-Jiménez, R. Kleinlein, D. Griol,

産性や品質の定量的評価に関する研究に従事．IEEE，IFPUG 各会員．