Showroomの複数アカウント（複アカ、複垢）について考えてみた(1)

ちょっと古いものですが次のような記事がありました。

　　　　「SHOWROOM配信応援ブログ - 複数アカウントによる不正ポイント減算システム導入後の推移について」

以前読んだときは気づかなかったのですが、最近あらためて読んでみると記事の中にある

　　「既にこの不正ポイント減算システムについて考察していたブログ記事を先日見付けました」

というのは私のこの記事のことのようです。

　　「1/20～1/29におけます某イベントにおける参加配信者３名分の獲得支援ポイントの推移をグラフ化したものを掲載し、...」

とあるからです。せっかくだからリンクを貼ってくれればいいのにと思うのですが....

　　「本記事で紹介させて頂こうと考えておりましたが、自動星集めについての考察記事も該当ブログには御座いましたので、割愛させて頂く事にしました。」

要するに記事はよく書けているがブログのスタンスがけしからんということのようです。私も記事を書いていてちょっとはうしろめたい気持ちはあるわけですし、SHOWROOMのオーガナイザーさんのブログとしてはとうぜんの反応だと思います。

記事を読まれている方がいらっしゃることはわかったので、せっかくだからその後複数アカウントについて調べてわかったことを追記しておきます（赤い字で書いてある部分が追記した部分です）

詳細は記事の最後にあるリンク先にあります。

蛇足ですが...
SHOWROOMの配信でときどき"複垢問題"が話題になってなっていますが、けっこう思い込みで（あるいは単なるうわさばなしをもとに）で話したり、コメントされている方が多いようです。以前はその場に居合わせたら、講釈をたれていたのですが、最近はやめました。

1. 複垢問題は単なる話題であって、具体的に何が真実か知りたい方がそう多いとも思えない。何が真実かわからないから、話題としておもしろいわけで、仕組みが明白になるともう話題として使えないわけですし...

2. SHOWROOMのシステムは（部外者から見ると）まあまあ円滑に稼働しており、私がどうこう言う問題でもなさそうだし、私がどうこう言ってどうにかなるというものでもなさそう。もっと言うとみんな誤解してる方が楽しめる。

（2019.03.27)
--------


Showroomが複数アカウント（以下“複アカ”と略します）のチェックをはじめました。

複アカとはどういう意味か、なぜ複アカは許されないのか、というようなことを最初に書きたいのですが、面倒くさいので今回は省略します。

ただひとつだけ書いておきます。スマホとPCの両方を使ってShowroomを利用すると複アカとして扱われるのではないかと不安に感じている方がいらっしゃいますがその心配はないです。このことは「Showroom - よくある質問」に次のように明記してあるからです。

　　同じひとつのアカウントであれば、複数の端末から同じアカウントデータでご利用することが可能です。

--------------------------------

複アカはもともと許されていないし、実際イベントで複アカを理由に獲得ポイントが減算されたという事例もありましたが、今回は組織的に取り締まるようです。詳細は「イベントにおけるポイント不正の対応に関する重要なお知らせ」という通知に書いてありましたが対策内容は次の二点です。

・イベント期間中、重複アカウントを用いた不正な応援行為がされていないか定期的にチェックする仕組みを導入

・不正なギフティングが確認された場合はその分のポイントを減算し、正確なポイントをもってランキング結果を発表する

これは22日の通知です。肝心の「何をもって複アカと判断するか」が明記されていません。それを書くと回避策を考える人がいるから、というのが常識的な推測ですが、じっさいはルールを公表できないもっと切実な(?)理由があるような気がしないでもないです。

上のルールは当日から実施されました。つまり22日の正午に減算操作が行われました。このときDDの私は某イベントに出ている三人の配信者さんを応援していたのでイベント参加者の獲得ポイントの変化を記録していました。下記のグラフはイベント参加者から三人分を抜き出したものです。仮に緑さん、青さん、赤さんという名前とします（私が応援していたのがこの御三方というわけではないです）

確かに22日から獲得ポイントの減算が始まっています。このグラフをよく見るといろいろと興味深いことがあります。

まず毎日（A1～A7の矢印で示したところで）ポイント減算の事象が見られます。特に緑さんは毎日減算されています。つまり

　　1. 複アカのチェックとそれを理由にした減算は毎日行われている。

ことがわかります。何日に一回とかサンプル的に抽出ではなく毎日全員に対してチェックが行われているようです。
（少なくともすべての配信者さんに対し毎日チェックが行われていることを否定する事象はありませんでした）

次に赤さんのグラフを見るとA1のところで大きな減算がありA2のところで軽く減算、A3のところでまた大きく減算されています。特にB（＝A3）のところは前日の獲得ポイント以上のポイントが減算されています。これは青さんのC点ではさらに顕著で一回で３，４日分の獲得ポイントが減算されています。

Showroomの通知を素直に読むと毎日前日分のチェックを行い複アカがあったらその分を減算するように思えますが実際にはそうではないようです。次のような可能性が考えられます。

　　2-1. チェックは前日分だけではなく毎日イベント開始時に遡って行っている。

あるいは

　　2-1. 前日分のチェックで複アカが見つかった場合はイベント開始時に遡って再度チェックを行う。

のいずれかが行われており、そしていずれの場合も言えることは

　　3.a 複アカを検出する方法（アルゴリズム）は毎日同じではない。

ということです。

（この部分は考え過ぎのようで、単に ある日複垢によるポイントの獲得が確認された場合は該当するアカウントの（うち一方のアカウントの）貢献ポイントをイベント開始時にさかのぼって減算するということのようです）


3.についてはまた二つの可能性が考えられます。

　　3a-1. 複数の方法を日替わりで使っている

あるいは

　　3a-2. 複アカ検出の方法を常に更新している

です。これはいずれかわかりません。負荷軽減の目的で3a-1.も考えられないことはないですがこういうことをすると配信者、リスナーが混乱するので、おそらく3a-2の方だと思います。複アカの正確な検出は難しい（というより不可能？）と思われるので検出方法を常に改良しようとしていると思うからです。

（これはなんとも言えませんが、複垢検出は意外なほど単純な方法を使っているようで、別につねに検出方法を改良するというようなものではないように思えます）

もし3a-2が正しければ、常に検出に改良が必要（もし正確に検出できていれば改良の必要がないはず）ということ、すなわち

　　4a. 現在の複アカチェックは正確に行われていない （3a.2 が正しい場合）

ことを意味します。要するに、複アカじゃないのに複アカの嫌疑をかけられて泣いているリスナーさんがいれば、複アカがバレずほくそ笑んでいるリスナーさんがいるのが現状だと思います。

（ここがいちばん問題なところで、現実にはSHOWROOMの規約にある重複アカウントの定義と、実際の運用で検出する重複アカウントの定義は異なっているようです。だから規約を読んでどういうことが禁止されるかをいくら考えてもあんまり意味がないです。そもそもSHOWROOMの規約にある重複アカウントの定義どおりだと（個人認証を行っていない現在のSHOWROOMの仕組みの中では）重複アカウントを正しく検出することは不可能としか思えません）

そんなことはないとは思うのですが、可能性としては次のようなのも考えられないわけではないです。

　　3b リスナーが複アカに相当する行為を行ったことが検出された場合そのアカウントでのポイントを過去に遡って減算する。

仮に3b.が正しいとすれば次のような状況が排除できなくなると考えられます。

　　4b.-1 複アカでも減算が行われないケースがある（3b.が正しい場合、可能性として）
　　4b.-2 複アカではなかったのに減算されるケースがある（3b.が正しい場合、可能性として）

今日泥棒した人だから昨日も泥棒したんだろう、と考える人も多いでしょうが、感性としてはともかく論理としては間違っています。

（3b、4b.-1、4b.-2のいずれも正しいです。つまりイベント中途で複垢と認定されると少なくとも1つのアカウントの貢献ポイントはイベント開始時にさかのぼって減算されます。またSHOWROOMの規約の定義では複垢と言えないケースで減算されることもあれば、あきらかに複垢であっても減算されないことがあります）

それから減算されたときどのリスナーさんが対象となったのか気になりイベント貢献ランキングをチェックサれる方がいらっしゃると思いますが（少なくとも現時点では）無意味です。

　　5. ポイント減算はイベント貢献ランキングには反映しない。

からです。

（減算されたポイントと貢献ポイントからどのアカウントが複垢減算の対象となったか調べることができます。ただし確実に特定するためにはいくつか条件があります）

----------------

私はそもそも複数アカウントのチェックができるものか疑問に思っています。Showroomは「疑わしきは罰する」方向でチェックを行っているのではないかと危惧しています。

Showroomで行われている複数アカウントのチェックの手法を推理し、その推理が正しいか否か検証するにはどうしたらいいか、ということを今いろいろ考えていますので、そのうち記事にしたいと思います。できれば実際に実験して検証したいのですが、それはいろいろと問題があるのでどうしようか悩んでいます。

----------

2018.09.22 追記

協力していただける配信者さんが現れたので実験を始めることにしました。

　　「Showroom - 複数アカウント(複垢)問題の真実 - 実験計画」  （複垢減算のQ&A）
　　「Showroomの重複アカウント（複垢）減算はこうして起きる」　　（実験結果）

-------------------------

参考

　　「Showroom - 自動星集め・星投げ・カウントツール）」 （使用法とソースつき）
　　「Showroom - 自動三周ツール（もう一つの自動星集め・星投げ・カウントツール）」　
　　「Showroom - イベントの獲得ポイント数を取得して記録するツール」
　　「Showroom - 福引するプログラムとその結果 (1)」

　　「Showroomの複数アカウント（複アカ、複垢）について考えてみた(1)」
　　「Showroom - 複数アカウント(複垢)問題の真実 - 実験計画」
　　「Showroomの重複アカウント（複垢）減算はこうして起きる」

　　「Showroomでの自動星集めの試み (3) ガチイベ、最後の5分間
　　「Showroom ラスカルイベの最後の5分間」

　　「Showroomでの自動星集めの試み (1)」
　　「Showroomでの自動星集めの試み (2) 配信ルームの一覧を作る」
　　「Showroomでの自動星集めの試み (4) 星集めツール」
　　「Showroomでひたすらリスナーレベルを上げるための星集めツール（Go/Agouti）」

　　「超初心者のGo言語/agouti - ブラウザ操作の基本の基本」
　　「超初心者のGo言語 - 複数の戻り値をもつ関数」
　　「超初心者のGo言語 - もっとも簡単なGoroutine（並列処理）」

　　---------------------

　　「GoDoc - package agouti」

　　「Qiita @0829 - Goではじめてみたブラウザの自動操作」

　　「Qiita @tenten0213 - agoutiというWebDriverクライアントを使って面倒な作業を自動化する」
　　「Qiita @masaru_b_cl - Windows上でGo言語初心者向け学習環境を作る」

　　「はじめてのGo言語」
　　「天才まくまくノート - まくまく Hugo/Go ノート - 関数を定義する (func)」

　　「Qiita @TakaakiFuruse - Golang Goの並列処理を学ぶ(goroutine, channel)」
　　「Qiita @To_BB - Rubyエンジニアがゴルーチン(Go言語)を学んでみた【初心者向け】」
　　「Qiita @fukumone - goroutine 使い方まとめ」