社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

Web フロントエンド開発者のためのユーザ参加型エラー収集システムの提案
山本 将弘†

柗本 真佑†

楠本真二†† 大阪大学大学院情報科学研究科〒 565–0871 大阪府吹田市山田丘 1–5
E-mail: †{m-yamamt,shinsuke,kusumoto}@ist.osaka-u.ac.jp
あらまし

Web のフロントエンドを構成する HTML や JavaScript では様々なエラーが発生する．開発者はこれらのエラーの発生状況を早期に把握し，修正する必要がある．本研究では，エラーを早期に検知し改善に役立てることを目的として，参加型センシングのコンセプトを取り入れたエラー収集システムを提案する．エラー収集をユーザの協力により実施することで，多様な環境からの収集を実現できる．本稿では，Web において発生するエラーに関する背景と提案システムの概要，及び被験者実験により収集したエラーの事例について紹介する．
キーワード Web フロントエンド開発，エラー収集，参加型センシング

1. は じ め にいう通信方法は，2013 年 8 月ごろから各ブラウザで警告から禁止に変更された．これにより，混在コンテンツを利用していWeb は現代における情報発信の基本となりつつある．従来のた Web ページは，仕様変更後に開発者の期待通りに動作しな

Web のフロントエンド（Web ブラウザ上に表示される UI のくなった [2]．これは，仕様やブラウザに対するリソースの相対こと）は，Web ページと呼ばれるような HTML や CSS 等の的な劣化と見なすことができる．また，仕様の変更と同様にラ

静的なコンテンツのみで構成されるものが代表的であった．一

イブラリのアップデートも頻繁に行われている．これらのこと

方，近年では，Web アプリケーションと呼ばれるようなユーザから，開発を終えたリソースに対しても定期的なメンテナンス

からのインタラクティブな操作を想定する，よりリッチかつ複が必要不可欠である．

雑なシステムへと移り変わりつつある．この流れは，Web フロ

三つ目の難しさは，エラーに対する修正方法が把握しにく

ントエンド開発の複雑化を意味しており，その開発の支援は重いという点である．Web フロントエンドの動的な責務を担う要な課題であるといえる．

JavaScript は，他の言語と比べて柔軟性が高い．そのため，あWeb フロントエンド開発における難しさの一つは，クラる特定の機能を実現する場合であっても様々なコードの書き方

イアント側で発生するエラーの再現である．HTML や CSS，が存在する．これはエラーの修正方法が多岐に渡るという課題

JavaScript 等の Web のリソース（以降，Web リソースと呼ぶ）に繋がる．StackOverflow（注 1）等の良質なナレッジサービスも登の特徴の一つは，W3C や WHATWG，Ecma インターナショ

場しているが，見つかったコードスニペットが期待する実行環

ナル等の標準化団体が定めた中立的な仕様に対し，様々な Web

境やバージョンと合致しているかを見極める必要もある．この

ブラウザの実装が存在する点にある．この特徴は Web の中立

スニペットのバージョン齟齬という問題は，Java や C，Python

性を保つ重要な性質である一方で，Web リソースの解釈がブラ等の他の言語でも同様に発生するが，前述したように Web のウザごとに異なるというブラウザ互換の問題の原因となる．近技術は仕様の変化が激しいことからも，古い情報がノイズにな

年では HTML5 の仕様策定に伴い，ブラウザ互換の問題は減少

りやすいといえる．

しつつあるものの，ブラウザごとに外観が変わるような問題も本研究では，Web フロントエンド開発におけるエラーの発依然として存在している [1]．そのため，フロントエンド開発者

見および修正の効率化を目的として，参加型センシングのコンは自身の開発した Web リソースに対し，様々なブラウザを用

セプトを取り入れたエラー収集システムを提案する．参加型

いて正しく動作するかを確認する必要がある．

（Participatory または Voluntary）センシングとは，ユーザのフロントエンド開発のもう一つの難しさは，Web リソース

自発的な参加を元に，計測対象のデータを広く回収する考えでが時間と共に「劣化する」という点である．Web の仕様は常にある [3]．提案システムではこの考えを取り入れた 2 つの機能

進化しており，過去に正しく動作していたページが動作しなくを実現する．まず機能 1 では，様々なユーザに自主的に協力しなるということも少なくない．例えば，SSL 保護されたページ
内から保護されない HTTP 通信を呼び出す混在コンテンツと（注 1）：https://www.stackoverflow.com—1—

てもらい，Web 上に存在する膨大な数の Web リソースを対象としたエラー発生報告の回収を行う．ユーザ参加型とすること
で，様々なブラウザや実行環境の組み合わせが実現でき，さらにエラーの早期発見に繋がると考えられる．この機能 1 は先に述べた 2 つの問題（エラーの再現，リソースの劣化）の解決策となる．機能 2 では，収集したエラー情報に基づいてエラーの発生している Web ページを定期的に確認し，エラーの修正事
例を回収する．これにより様々なエラー修正事例の提示が可能となる．
本稿では特に機能 1 に着目し，Web リソース上で発生するエラーに関する背景や，提案システムの概要，およびプロトタイ
プとして開発したシステムについて紹介する．さらに，被験者実験により得られたエラーの事例について紹介する．本稿の貢献は以下のとおりである．

•

Web フロントエンド開発の支援を目的とした，ユーザ参加型のエラー収集システムを提案した．

•

収集価値，およびプライバシーの 2 つの観点から収集対図 1 Google Chrome による Web ページの閲覧

象とするエラー情報の検討を行った．

2. Web の構成要素と参加型センシング
2. 1 Web リソース
Web のフロントエンドは様々なリソースによって構成される．大別して，HTML や JavaScript 等のテキスト系のリソー
スと動画や画像等のマルチメディア系のリソースに分類することが可能である．本稿では，Web ブラウザ上で解釈，実行されるテキスト系のリソースに着目し，これらを単に Web リソー
スと呼ぶこととする．

Web リソースは他の一般的なプログラミング言語と異なり，
コードオンデマンドと呼ばれるアーキテクチャに従って処理，実行される．コードオンデマンドでは，まずクライアント（一般的に Web ブラウザ）がサーバに対して HTTP リクエストを送信し，サーバから Web リソースを取得する．取得された

Web リソースはクライアント側で解釈され，実行される．リ
ソースのコンパイルや実行がクライアントサイドで行われると

図 2 Internet Explorer 6 による Web ページの閲覧いう点が特徴的であり，多種多様な実行環境を想定する必要がある．

2. 2 Web リソース上で発生するエラー
前節で説明したように，Web リソースはクライアント側で実行される．そのため，ユーザ側の環境で様々なエラーが発生する．JavaScript のエラーの実情を調査した研究 [4] によると，

図 3 Web ページ内部で発生していたエラー

アクセス数上位の多くのユーザが利用する Web サイトでも，平均で 1Web サイト当たり 4 個のエラーが含まれている．これらを図 2 に示す．図 2 では画面中央の YouTube 動画や，画面下のエラーには，型に関するエラーや未定義変数の利用などの実部の Facebook のいいねボタンが正しく表示されていない．加行時エラーだけでなく，構文エラーのような開発途中に発見しえ，YouTube 画面の「エラーが発生しました」というエラー

やすいエラーも含まれている．

メッセージ自体もレイアウトが崩れている．
（注 2）

具体的なエラーの事例を示す． 図 1 は，ある Web ページ

このエラーの原因は，jQuery ライブラリのアップデートに伴うを Google Chrome で閲覧した画面のスクリーンショットであものであると推測できる．Chrome で閲覧した際の JavaScriptる．同様に，同ページを Internet Explorer 6 で閲覧した画面のコンソールでは，図 3 のようなエラーが発生している．具体
的なエラー発生箇所（bulletphysics.org の 749 行目）のソース（注 2）：http://bulletphysics.org/wordpress/

コードは以下の通りである．

—2—

エラーリポジトリ// IE6 max - width for images
if ( jQuery . browser . msie &&

開発者

収集サーバ

/ MSIE 6\.0/ i . test ( navigator . userAgent ) &&!/ MSIE 7\.0/ i . test ( navigator . userAgent ) ) {4. エラー情報の確認

当 該 コ ー ド は ，IE6 に 対 す る 画 像 サ イ ズ の 特 殊 な 処 理 を
行 っ て い る 部 分 で あ る ．こ の if 分 岐 内 で 利 用 さ れ て い る

jQuery.browser.msie というプロパティは，ブラウザが IE
かどうかの判定結果が格納されるが，jQuery のバージョンアップに伴い削除された．これらの点から，この Web ページの開エラー送信プラグイン

3. エラー情報の送信

発者は IE6 利用者を想定して開発し，その後不用意に jQuery

1. Webリソースの要求・送信のバージョンを更新してしまったため，IE6 対応のコード自体が期待通りに動かなくなったと推測できる．
この事例のように Web リソースは，ブラウザの違いや仕様の変更，ライブラリのアップデート等の様々な要因でエラーが発生する．より品質の高い Web リソース開発のためには，ま任意のWebサーバ

ユーザ
2. Webリソースの実⾏

ずエラーの発生状況を早期に把握し，その修正事例をいかに提示するかが重要となる．

図4

エラー送信プラグインを
インストールしたWebブラウザ

エラーリポジトリ機能 1 の仕組み

2. 3 参加型センシング
参加型センシングとは，ユーザの自発的な参加の元，ユーザ

エラーリポジトリ機能 1 の動作の流れを図 4 に表す．機能の持つモバイル端末をセンサデバイスと捉えることで，広域か

1 はユーザの協力を必要とする．ユーザには普段使用している

つリアルタイムなセンシングを実現するアイデアである [3] [5]．
モバイル端末の普及を背景に考案され，近年の IoT の考え方が一般社会に広がるにつれてますます注目を集めている．
参加型センシングに関する研究をいくつか紹介する．Prabal
らは大気汚染に関する情報を参加型センシングにより収集している [6]．また，Pengfei ら [7] はバスの待ち時間に関する研究を行った．ユーザの GPS 情報を用いることで到着時間を予想するシステムを提案している．

Web ブラウザにエラー送信プラグインをインストールしてもらう．2. 1 節で説明したコードオンデマンドという特性により，ユーザは自身の環境でソースコードを実行する．具体的には，閲覧したい Web ページを有する Web サーバに対して Web リ
ソースを要求して受信する（図中矢印 1）．その後，受信した

Web リソースをユーザ自身の環境で実行する（図中矢印 2）．実行時にエラーが発生すると，エラー送信プラグインがこれを検知し，収集サーバに対して情報を送信する（図中矢印 3）．収集
サーバでは送信されてきたエラー情報をデータベースに保存し3. 提案システム：エラーリポジトリ
3. 1 キーアイデア
本研究では，Web リソース上で発生するエラーの早期発見を目的として，エラーリポジトリというシステムを提案する．エラーリポジトリは，Web リソース上で発生するエラーの情報を収集する．エラーリポジトリのキーアイデアは参加型センシン
グの考え方をエラー収集に取り入れる点である．
参加型センシングのコンセプトを取り入れるにあたって，構成要素を置き換える．まず，ユーザの現在地は地点ではなく閲覧している Web ページに対応づけられる．センサデバイスは
モバイル端末ではなく Web ブラウザに対応づけられる．また，センサ情報はエラーの情報やユーザ環境の情報である．

3. 2 システムの概要
エラーリポジトリは 2 つの機能を提供する．これらの機能を実現するために，エラー送信プラグイン（Web ブラウザ拡張プ
ラグイン）と収集サーバを作成する．
（ 1 ） エラー参加型のエラー収集・一元管理（ 2 ） エラー解決時の差分を修正例として収集
前者を機能 1，後者を機能 2 と呼ぶことにする．それぞれの機能について説明する．

て一元管理する．これらの情報はリアルタイムに更新されて，開発者はそれらのエラー情報を確認することができる（図中矢印 4）．この機能により，Web フロントエンド開発者はユーザ環境で起きたエラーを早期に発見できる．また，エラーが発生した環境などの情報も取得することができる．
機能 2 では，エラー収集から修正事例を収集する．機能 1 においてユーザからエラー情報を受信してから，一定の時間ごとにエラー情報内の Web リソースを取得して保存・実行する．ある時点で今まで発生していたエラーが発生しなくなったとき，
前回と今回のソースコードの差分を抽出し，それらをエラーの修正例として収集する．
以降では，研究の第一歩として特に機能 1 について着目する．

3. 3 エラーに関連する情報と収集の方針
収集するエラー情報について，エラー発生時の状況を表す項
目を表 1 にまとめる．各項目とその一例を左側の 2 列に挙げている．右側の 3 列については，のちの収集の方針にて述べる．
これらの項目の中で収集する項目を決定しなければならない．
収集すべき項目を判断する基準は，（ 1 ） エラーの原因解明に役立つこと（ 2 ） プライバシーを可能な限り守ること—3—

表 1 収集可能なエラー情報の項目一覧と収集方針
項目

具体例

原因解明に役立つか

オプトアウトか

収集するか

✓

✓

✓

エラーメッセージ Uncaught SyntaxError: Unexpected token {

✓

✓

✓

スタックトレース sub.js:5 main.js:7

✓

✓

✓

ブラウザ・OS

Google Chrome/61.0 Windows NT 6.1; x64

✓

✓

✓

日時

2017-08-20 15:30

✓

✓

✓

cookiesession_id=X9Qj5Bp

✓

✓

×

位置情報（GPS） 34.8, 135.5

✓

×

-

バッテリー残量

×

-

-

URL

http://www.example.com/main.html

0.78の 2 点である．この 2 つの基準はほぼ背反の関係にある．例
えば，エラーの原因解明のためには Web ページの情報の全項
目を収集するのが簡単であるが，その Web ページが個人情報

window . onerror = function ( msg ) {console . log ( msg ) ; // エラー発生時に行う処理}を含む場合，プライバシーを侵害してしまうことになる．反対
図 5 window.onerror の例に，Web ブラウザの種類や URL などの項目を個人情報とする
ならば，原因解明のために収集できる項目がなくなってしまう．
よって，これらの基準を考慮しながら，条件を満たすか満たさないかでフィルタリングをしながら収集する項目を決定する．
まず，エラー情報の各項目がエラーの原因解明に役立つかど
うかでフィルタリングする．Web ブラウザを使用している端末のバッテリー残量などはエラーの原因と直接関係ないと考えられるので選択肢から外す．表中の他の項目は全て原因解明に役に立つ場合がある．URL はどの Web ページでエラーが起きたかを判断できるので役立つ．エラーメッセージとスタックト
レースはエラーが発生した箇所を確認できるので役立つ．ブラウザ・OS の項目は環境に依存したエラーである場合にエラーが起きた環境を判断できるので役立つ．日時はエラー発生の状
況を時間方向に振り返ることができるので役立つ．cookie は

図 6 エラー情報公開ページ

ユーザ専用の Web ページにおいてエラーが発生した場合に状況を再現することができるので役立つ．位置情報（GPS）は，

3. 4 エラーの収集方法

特定の区域（大学内など）でのみ発生するエラーに対して，そ

エラーを収集するためには，エラー送信プラグインが Web リの地域に限定したファイアウォールといった原因が検討できる

ソース上で発生した実行時エラーを検知できなければならない．

ので役立つ．

これには window.onerror というイベントハンドラを利用する．

次にオプトアウトであるかどうかでフィルタリングする．オ

window.onerror は実行時エラーが発生した時に呼び出され，図プトアウトとは，ユーザが拒否しない限り取得してもよい項目

5 のように開発者自身が独自の実装を行う．Google Chrome をであることを表す．類似した用語にオプトインがあり，これは始めとした多くの Web ブラウザがこの window.onerror の仕組

ユーザが許可しない限り取得してはいけない項目である．プラ

みを取り入れている．エラーリポジトリでは，window.onerror

イバシーに関する項目はオプトインになることが多い．本研究の中で前節で選択した項目からなるエラー情報を非同期通信

ではオプトアウトの項目のみを収集することにする．エラーのAjax を用いて収集サーバに送信する．

原因解明に役立つ項目のうち，オプトアウトでないのは位置情報（GPS）である．よって位置情報（GPS）は収集する項目か

4. システムの試作

ら外す．

本稿では実験に向けてエラーリポジトリの機能 1 のプロトタ

フィルタリングされなかった全ての項目を収集したいとこ

イプを作成した．収集サーバの実装については，メイン処理部

ろであるが，cookie は収集しないことに決めた．その理由は，分に Node.js を，データベース部分に MongoDB を用いた．まcookie を知ることによってサービスのログイン乗っ取りができた，エラー収集プラグインとして Google Chrome 用のブラウてしまう可能性があるためである．以上より，URL，エラー

ザ拡張機能と Firefox 用のプラグインをそれぞれ JavaScript でメッセージ，スタックトレース，ブラウザ・OS，日時の項目を実装した．

収集することに決定した．

また，収集したエラー情報を開発者に向けて公開するために—4—

1% 1%Web サーバを収集サーバのプログラム内に実装した（注 3）．図 6にスクリーンショットを示す．現時点では，収集したエラー情

6%報のうち，エラーメッセージの種類の割合や送信された数の多ReferenceError

いエラーメッセージが確認できる．

TypeError

HTTPS 通信により閲覧している Web ページからはプラグ

32%

60%

インにおいてもデータの送信は HTTPS に限定される．エラー

SyntaxError

情報を送信する際のプライバシーも向上するため，エラーリポ

その他

ジトリの全ての送信は HTTPS 通信で行うようにした．

5. 実

CustomError験
図 7 エラーメッセージの種類の割合

5. 1 実験の目的
エラーリポジトリという Web リソース上で発生するエラーを収集するシステムを提案するにあたり，プロトタイプによる実験を行なって評価する．実験の目的を以下の 2 点に定める．

•

価値のあるエラー情報が収集できるか調べること•

プライバシーに関する情報が含まれるか調べること価値のあるエラー情報とは，Web ページに影響をもたらすエラーであり，かつエラー情報を確認した時に原因が解明できる
エラーであるとする．収集したエラー情報の中に価値のあるエ
ラー情報が含まれていれば，エラーリポジトリの存在が意味を持つ．

3. 3 節でエラー情報の項目の収集方針においてプライバシーに関する情報を考慮したが，実際に収集すると決めた項目にプライバシーに関する情報が含まれていないのかどうかを確認
する．

5. 2 実 験 設 計
実験において，被験者に対しては普段使用している Web ブ
ラウザにエラー送信プラグインをインストールしてもらう．ま送信されたエラー情報について，実際に Web リソースの該当箇所を目視で確認した．その結果，価値のあるエラー情報が見つかったので，6. 2 節でいくつか紹介する．また，Refer-enceError の中で件数が多かったエラーメッセージに adpds_js
や adRequest という変数が定義されていないというメッセージが含まれていた．これらについて，該当箇所を確認するなど調べてみると広告を非表示にするプラグインをインストールしている場合に発生するエラーであることがわかった．これらのエラー情報は，Web ページに影響をもたらすエラーであり，かつエラー情報を確認した時に原因が解明できるエラーであるが，価値のあるエラーとみなすかどうかは今後検討する必要がある．

6. 2 収集できたエラーの事例
目視により Web リソースの該当箇所を確認すると，いくつかの事例で原因を判断することができた．2. 2 節で紹介したエラーもその中の 1 つである．継続的にエラーの発生状況を調べるエラーリポジトリだからこそ発見できたエラーであるといえる．その他に見つかった価値のある事例を紹介する．

た，収集サーバを実際に稼働させて，エラー情報を受信・保存する．
被験者は 8 人であり，内訳は Google Chrome の使用者が 7
名，Firefox の使用者が 1 名である．実験を行う期間は 2017 年

8 月 15 日から 2017 年 8 月 31 日までの約 2 週間である．

6. 実 験 結 果

Uncaught SyntaxError: Unexpected token {このエラーは，ソフトウェア工学関連の国際会議の Web サ
イト（注 4）で発生していたエラーである．このエラーが発生した

Web リソースの該当箇所を確認すると以下のようなソースコー
ドを発見した．

6. 1 集計の結果< script src = " bootstrap /3.3.0/ css / bootstrap . min

期間内に収集したエラー情報を集計した結果を述べる．ま. css " > </ script >ず，被験者から受信したエラー情報の総数は 4,172 件となった．これは，1 日あたり平均 245 件のエラー情報が収集サーバに送信されていることを表す．エラーメッセージの種類ごとの割合は図 7 のグラフのようになった．参照に関するエラーである ReferenceError が最も多く．次いで型に関するエラーである TypeError が多かった．
送信されたエラー情報を確認すると，日時以外の項目が一致
する重複したエラー情報が多数見られた．そこでエラーメッ
セージと URL についてユニークな数を調べてみると，ユニー
クなエラーメッセージの数は 192，ユニークな URL の数は 481となった．

HTML の script タグにおいてエラーが発生している．script
タグは JavaScript 等のスクリプト言語リソースをロードするために用いられる．しかしながら，この事例では script タグを用いて CSS ファイルを読み込もうとしている．そのため，ブラウザは CSS ファイルを JavaScript と見なして実行するため，

CSS のブラケットの部分で構文エラーを発生させている．CSS
は本来 link タグによって読み込むのが正しい文法であり，当該部分は開発者の期待通りに動作していないといえる．
また，同じエラーメッセージの別件を調べると別の Web サ
イト（注 5）において，以下のようなソースコードも発見できた．
（注 4）：https://icsme2017.github.io/（注 3）：https://tyr.ics.es.osaka-u.ac.jp/error-collect/にて公開（注 5）：https://mj-news.net—5—これらのサービスと本研究で提案したエラーリポジトリの決} elseif ( strpos ( $site_rocal , ’ xxxxxx ’) !==false ) {定的な違いは，エラー発生時にエラー情報を送信するコード片が Web リソース内に埋め込まれているか，Web ブラウザに拡

このソースコードの記述は JavaScript の一部分である．PHP

張プラグインとして埋め込まれているかである．Web リソースには elseif 構文が存在するが，JavaScript では else と if の内に埋め込む仕組みでは，エラーの発生を知ることができる対間にスペースを挟まなければならない．そのため，構文エラー

象となる開発者が限定される．一方，本研究のエラーリポジトが発生した例である．

リのようにプラグインとして Web ブラウザ側に埋め込むこと

6. 3 プライバシーに関する考察ができれば，ユーザが閲覧した全ての Web ページを開発した

実験の結果を目視で確認した結果，プライバシーに関する情開発者がシステムの恩恵を受けることになる．ただ，新たに発報が含まれることが分かった．含まれていた箇所は以下のとお生する問題として，ユーザに参加してもらうためにどのようなりである．

動機付けを行うかについて考慮する必要がある．

•

URL のクエリ部分•

URL のパス部分•

エラーメッセージの一部分

8. お わ り に
本稿では，Web フロントエンド開発におけるエラー収集シ

URL のクエリ部分では ID やキーワードが含まれた．ID に

ステム，エラーリポジトリを提案した．さらに，エラーリポジ

より個人が特定できる場合，プライバシーの情報がエラー情報

トリのプロトタイプを作成し，被験者を対象とした実験を行っに含まれていたことになる．場合によってはキーワードでも個た．収集したエラーをもとに Web ページを閲覧することで価人が特定されてしまう可能性もある．

値のある事例を探して，いくつかを紹介した．また，エラー情報の公開に向けて課題となるプライバシーに関する情報が含まhttp://www.example.com/main?id=xxxxxxx
http://www.example.com/search?q=xxxxxx

れる場所について述べた．
今後は，見つかったエラーの事例について実際に開発者にコンタクトを取り，開発者にとって価値のあるエラーであるかを

URL のパス部分やエラーメッセージに ID が含まれること確認する予定である．また，エラーリポジトリのもう 1 つの機があった．下の例は Google Drive におけるエラー情報の URL能であるエラー収集事例の収集について，実装・評価を行う．

やエラーメッセージである．サービスによっては，URL をメー

謝

ル等で交付することで，URL を知っている人々に限定して公本研究は，日本学術振興会科学研究費補助金基盤研究（S）

辞

開する場合がある．これらをエラー情報として公開してしまう(課題番号：JP25220003)，および文部科学省研究費補助金若手と，限定でなくなるためサービスの意図に反する可能性がある．

研究（B）（課題番号：JP26730155）の助成を得て行われた．
文

https://drive.google.com/drive/folders/xxxxxxxxxx
Uncaught CustomError: Team Drive not found:xxxx-xxxxxx
エラー情報を一般に公開する場合，これらのようなプライバ
シー情報を非公開または匿名化する必要がある．URL のクエ
リ部分以外にプライバシーの情報が含まれたのは Google Driveのみであった．そのため，公開する情報においてクエリ部分は常に非公開にし，Google Drive といった特定のサービスだけ独
自のフィルタで非公開にするのが妥当と考えている．

7. 既存のエラー収集サービスとの比較
Web リソース上のエラー収集にはすでにいくつかのサービスがある．Errorception [8] や Airbrake [9] などが一例である．これらのサービスでも実行時に発生するエラーは win-

dow.error によって検知する．window.onerror 内ではサービスが運用するサーバに対してエラー情報を送信する．開発者はwindow.onerror を含むサービスが指定したソースコードを自身が開発している HTML のヘッダ部分に埋め込むことでサービスの恩恵が受けられる．

献[1] A. Mesbah and M.R. Prasad, “Automated cross-browser
compatibility testing,” International Conference on Software Engineering, pp.561–570, 2011.
[2] P. Chen, N. Nikiforakis, C. Huygens, and L. Desmet, “A
dangerous mix: Large-scale analysis of mixed-content websites,” Information Security, pp.354–363, Springer, 2015.
[3] J.A. Burke, D. Estrin, M. Hansen, A. Parker, N. Ramanathan, S. Reddy, and M.B. Srivastava, “Participatory
sensing,” Center for Embedded Network Sensing, pp.1–5,
2006.
[4] F.S. Ocariza Jr, K. Pattabiraman, and B. Zorn, “Javascript
errors in the wild: An empirical study,” International Symposium on Software Reliability Engineering, pp.100–109,
2011.
[5] 青木俊介，岩井将行，瀬崎薫，“参加型環境センシングを用いた統計情報構築のためのプライバシー保護手法，” 電子情報通信学会論文誌 B，vol.97，no.1，pp.41–50，2014．
[6] P. Dutta, P.M. Aoki, N. Kumar, A. Mainwaring, C. Myers,
W. Willett, and A. Woodruﬀ, “Common sense: Participatory urban sensing using a network of handheld air quality
monitors,” The ACM Conference on Embedded Networked
Sensor Systems, pp.349–350, 2009.
[7] P. Zhou, Y. Zheng, and M. Li, “How long to wait?: predicting bus arrival time with mobile phone based participatory
sensing,” International Conference on Mobile Systems, Applications, and Services, pp.379–392, 2012.
[8] Rakesh Pai, “Errorception,” https://errorception.com.
[9] Airbrake, “Airbrake,” https://airbrake.io.

—6—