・前書き
本記事にはいいねを押さないよう申し上げます
昨日の連続投稿による迷惑行為に対しまして、ここにお詫び申し上げます
運営及び読者、投稿者の皆様に大変なご迷惑、ご負担をおかけし、申し訳ありません
運営の皆様方におかれましては早朝から通報・問い合わせに追われることとなり、日々システム改善やミーティングなど忙しい中、手数を煩わせたこと、お詫び申し上げます
投稿者の皆様方におかれましては、多大なる労力をおかけになった記事を読まれにくい場所に送ってしまい申し訳ございません
読者の皆様方におかれましては、日々楽しみにしていらっしゃるであろう新記事を読みにくい場所に送ってしまったこと陳謝いたします
非常に気分を害するであろうことは予見していましたものの、やはり多大なるご迷惑をかけ、不愉快にさせてしまったことをここに謝罪いたします
今後は、遅筆ながらも、皆様のお役に立てるような記事を作成していきます
以降は本件につきましての、こちら側が提示できるレポートでございます
・概要、要約
5000人のユーザーを募ったALISクローズドβ版であるが50日経過後、そのアクティブユーザー数は1000人を切っており、投稿される記事は300本/日とソーシャルメディアとして非常に内向きであると思えます。またここ最近は非常に内輪ネタ感が強く、仮想通貨関係ないと思える投稿や中身の薄い投稿が多いと思えました。そこでユーザーが多い状態を、連続して投稿を行うことで疑似的に作り出し、自分の記事が常に上位に表示されないようにしました。また、そのような状態を意図して作ることが出来る点について問題提議と実行を早朝より行いました。その結果、通報が相次ぎ、昼前に運営から警告と投稿の下書きへの返送が行われました。
・背景
ALISの新着記事(初期表示)は最新10記事である
ALISには特定の時間で閲覧者が増え、それに合わせて投稿することでPVを増やし評価を得る(数値データなし)という経験則がある
現状、単に記事を投稿するだけでインセンティブがある
ALISの一日に投稿される新記事は300程度で下落傾向なため、1時間当たり12.5記事程度(単純計算)
7日間のアクティブユーザーは700人程度
また一日当たりのユーザーは多くて400人程度
TOP記事の内容や雰囲気としてだらけた、馴れ合いな印象を受ける
・疑問
記事数やアクティブユーザー数が、ソーシャルメディアプラットフォームとして的確にシミュレーションできていない状況では?
今のALISの仕様では10記事連続して投稿することで他人の記事を新着記事TOP10に表示させないようにできるが、それに対して運営と利用者はどう動くのか?
溜め記事や別から引っ越してきた人が、新着全部埋める10記事とはいかなくても、かなりの量の記事を連続で投稿することは今後ありえる
他人を使って新着記事を汚染するなど、この仕様では問題になることについて、ユーザーの良心任せかつ運営任せなところがある
・目的
この10記事を”自分にとって役に立たない”と思われる記事(実際にはちゃんと書いたやつ、検証として必要だったやつ、および内容は仮想通貨とALIS関係に絞ってあります)で埋め、疑似的に自分の記事が他人の記事によって新着記事から弾かれる状況を作ることで界隈の対応をみる
と同時に連続投稿に対する運営とユーザーの対応、どのように規制するか、どの条項を利用するかを計り、前例を作る
フクロウ氏以降、それほど目立って通告がないため、その後どのようになったのか、どう運営は対応するのかが実例としてない
(通告を受けて退場した人は戻ってこないためか、通報によってどのような対応、措置、報告を受けたのか/したのかがわからないのでは)
・条件
投稿内容は全て仮想通貨もしくはALISの投稿や仕様に関係することに絞る
効果的な時間帯に絞って連続投稿を行う
・時間帯とその目的について
1回目(5:30ごろ)...深夜や早朝に投稿し、おはようALISを狙う人の投稿を流す
2回目(7:30ごろ)...通勤前の投稿を流す
3回目(8:05ごろ)...通勤前の投稿を流す
このころからTwitterの通知が稀に来る
そのため、予告した流しとその数分後に予告しない流しを行い、よりアクティブに記事が投稿される状態を作る
4回目(8:30ごろ)...予告した流し、通勤中に読むような新記事、会社について始業前コーヒーブレイクを狙った記事を流す
5回目(8:45ごろ)...予告した流しを確認して投稿するような記事を流す
6回目(9:45ごろ)...RTで新記事情報やこの行為に対する抗議記事が回ってきたので流す
以上、連続して投稿を行った時間とその目的です
・結果
合計6回、60本の記事を投稿した後、10:47にALISサポートセンターよりメールがあり、下書きへのバックと警告
警告がなければどうしたか:12:00前後のお昼ALISと17~20時ごろ退勤ALISと夜ALISにかけて流す予定でした
界隈の反応としては「なぜやったのか」と直接私のアカウントまで問う行動と、通報をする行動、アンバサダーは割と静観していた印象を受けます
・考察
1. 100件の違反報告に対して
これにつきましては、100人がアクティブに通報したと捉えるのは難しく、しかしかといって通報に動いた人数を把握するのも難しいです
当日のGoogle Analysisを見ると直近一週間と比較してユーザー数は特に変化なし
ページビュー数も特に変化なし
他、Google Analysisで示される結果には特別変化がないようにみえます
当時アクティブだったユーザーが適当な記事を通報したと考えるとして、やはり、それでも100件の通報が集まる点にコミュニティの強さと、意外と人がいたのだなという点に驚きました
攻撃時間の選択も効いていると思います
2. 対応・措置について
違反した規約として第6条3項8号を当てるのは適切であると思います
第6条(退会)
3. 当社は、会員が以下のいずれかの事由に該当する場合、またはそのおそれがあると当社が判断した場合、(中略)当社が適切と判断する措置をとることができるものとします。
(8) 他の利用者または会員からの不満・不評・クレームが多く、本サービスにふさわしくないと当社が判断した場合
他の条項ですと証拠や証言の取得が難しい点、今回のケースにのみ適用する点が難しく思えます
例えば第10条(禁止事項)1項12号の
(12) 不正にALISトークンを取得する目的でコンテンツを大量に投稿する行為または無作為にコンテンツに対して「いいね」を行う行為。
はまず『不正にALISトークンを取得する目的』が必要です
目的を明示していないもしくは荒らしであるとした場合、これを当てはめるのは難しいです
また運営の利益にならないという点についても、仮想通貨もしくはALISについての記事数が増えるという点ではALISというメディアにとってはプラスになるともいえます(ただしこれはほぼ詭弁)
3. 措置として下書きに戻すことについて
β版として稼働させている状態であること、警告後の再発性が不明なことから妥当な判断だと思います
再び同じことをやったら一発退場
4. 改善の依頼について
送られてきましたメールの内容を要約しますと
通報があったため下書きに
再投稿される際は内容を精査して投稿せよ
改善が見られない場合は一時的にアカウントを凍結する
ここで「改善が見られない場合」とはどういう場合を指すのか、疑問になり畏れ多くも問い合わせました
これはALIS運営によるチェック(言い方を悪くすれば検閲)が入るのかを確認するためでもあります
その結果、
「改善が見られない場合」とは、投稿された記事に対して、再び「一定数以上の通報が行なわれている」状態となること
通報数と閲覧数に応じて記事が下書きに戻る
と、改善の定義をいただきました
また、前に示したTweetにあります、システムの自動化だけでなく、
という目標を教えていただきました
これはWhitepaperの10の将来検討しているALIS配布パラメータの変更だけではなく、通報などのシステムも運営による中央集権的ではなく、運営から独立したプラットフォームになることを示唆していると思います
5. 目的に対する結果と考察、感想
クオリティの低い記事を連続して投稿してしまったため、客観的に見てもただの荒らしにしかならなかった。そのため訴え、通報という結果になり、反応としてもあまりよいものにはならなかった。
今回は犯人をわかりやすくしていたが、今後匿名や捨てアカウントによる同様の荒らし行為に対してどう対応/予防するか、論点になる。
ALIS運営の規制・対応について順当かつ、このような荒らし行為に対しても誠実かつ迅速に対応していただき、感謝します。
またdiscordでの要望・Twitterでの告知にあったように、通報の件数の公開やメールで警告するなど運営の最新の違反・通報への対応がわかり、透明性が増したと思っています。
今回の手法は最も手軽にできる手法であるため(思い立った1日で100記事、仮想通貨もしくはALISネタで用意はきつかったが)模倣されやすい。ALIS側、ユーザー側が模倣犯(およびそのリスク)に対してどう対応するのかが求められている。UI面での方法として最新記事そのものではなく、最新記事を投稿したユーザーを表示する案がある。しかし、これには弱点があり、複数ユーザーが徒党を組んで(もしくは複数のアカウントを運用して)同一時刻に投稿した場合、最新記事を投稿したユーザーという欄はその組織で埋まってしまう(これは現状でも可能な手法)。そのようなことを故意的に行うユーザー集団に対してどう対応する予定なのか。「いいね」を付けない戦術でユーザー主体で対応していくしかないのか。議論点となる。
また今回、この手法を使うにあたって記事を100本作成しストックさせた。その結果として100本分の記事が場合によっては公開済みにおかれ、現状は下書きに置かれている。この事象には問題点が2つある。1つはこの下書きにある100本分の記事の投稿そのものには何も機械的なストップがかかっていないことだ。投稿ボタンを押すだけで投稿でき、新たに別に作る場合でも開いてコピペできてしまう。2つ目は記事管理の問題である。100記事が分類分けもされずに一か所に入っているため、自分で自分の記事を探すことすら大変である。現状現場で管理を行うならば、投稿者は自分の記事のハブ用のページを作成するという手法になるか。ただしハブ用のページを編集するには自身の記事一覧からそのページを見つけなければならず、自身の記事数が増えるほど見つけにくく効率が悪化していく。また同様に、ストック型の記事の編集、リライトには向いていない仕様である。読者視点での、ALIS内の検索やタグ付けがよく求められているが、投稿者視点で、記事一覧の改善、フォルダ分けやソーティング機能も、個人個人の記事が増えてくるほど必要になってくると思われた。
レポートその2
上記、謝罪と事件に関する考察をほぼ書き終え、ひと段落ついたところ、discordで某葡萄酒さんより「検証結果楽しみにしてます」(意訳:お前が検証って本文につけてやってた内容も晒せよ)と来たので超高速でその検証結果を書き下します
題:ALISにおけるサムネイルと画像と文字のサイズ検証
目的:ALISを見る端末は約55%がスマートフォンであり約45%がパソコンである
それぞれで同様のUXを与えられる画像サイズと文字サイズを検証することは記事の質を上げ、今後ALISの使い方をこってりまとめる際に有用である
前提:コード読めない(改善予定)
自分のパソコンとスマホ以外の観察環境がない(改善予定)
仮説 ・横長だと縮小、縦長だと中央を切り取るサムネイルになる
・その後、最新や最人気、記事一覧での表示ではない場合、加えて、上半分をサムネイルにする処理になる
実験 ・今回、か.1(1000x500)と か.2(500x500)と か.3(250x500)の3種類の画像を用いた
・それぞれ上半分は赤く、下半分は青く塗りつぶしてある
仮説が正しければどれも同じように表示されるはずである
・それぞれをサムネイルに設定し投稿した
結果 まず記事一覧で見た結果
すべて同じように表示された
これらを投稿し、最新ではなくしてみた結果(パソコンで確認)、
か.1(1000x500)では青いラインが見える結果となった
考察 このことから
・最新、最人気、下書き、記事一覧で表示されるときは横長ならば縮小、縦長ならば中心をキャプチャされることがわかった
と思ったが、横長でも中心をキャプチャされたらわからないため、縮小されたかキャプチャされたかを指標するマーカーを用いて再実験が必要
・それ以外のときは横長ならば真ん中よりちょっと下がキャプチャされ、縦長や正方形なら真ん中以上がキャプチャされることがわかった
今後はこの青いラインが消えるところを求めたいけど絶対に一発退場を食らうため、まともな記事のアウトプット速度を高めつつ現場で検証するしかない
・またスマホでのサムネイルの見え方については確認していないため、こちらも今後、同様に検証するしかないであろう
この実験の副産物であるが、どうもアイコンの円が潰れて見える
このことから縦サイズを圧縮しているのではないか、縦サイズの限界の存在が示唆された
・また最適・最大のサイズを検証する際、円も利用するという発見をした
仮説 特になし
実験 本来ならば大中小と3段階に振って最適な範囲を選定し、そこからさらに詰めていく手法が科学的、論理的で最良である
しかし今回、同時に大量投稿によるALISの最新記事表示汚染を行うため、網羅的に解析することで、記事のかさ増しと詳細な検証の両立を狙った
実験に使う画像としてはか.1(1000x500の上下が赤青)に「あ」を白文字で最大限入力したものを使用した(MSゴシック, png)
フォントサイズは8~96まで振った
それぞれの画像をサムネイルにし投稿した
結果 パソコン用で画像として投稿する際の文字サイズとして目安は18~(1000x500)である
2px下げ、16(1000x500)にすると文字が潰れて見える
また、サムネイルに表示させる場合は22~(1000x500)が適当に見える
弊スマホでの記事内の画像のフォントサイズの検証については、弊スマホで本件の記事のスクリーンショットをとっていないためできなかった
サムネイルについてはフォントサイズ16が可読限界であった
ただし、18以上の方がよりはっきりと読めた
考察 ・これらの結果から画像に記載する文字サイズは、画像サイズ1000x500のキャンバスにおいては18以上が適当であることがわかった
・サムネイルであれば22以上であるとよいことがわかった
・これら検証結果を踏まえてより見やすい結果の図を作成できなかったのは遺憾の意
・フォントサイズ20での結果から、縮小されたサムネイルのサイズは190x680(9.5:34)程度であると考えられる
また、このサムネサイズの検証については下で図を用いて議論する
まず、パソコンではフォントサイズを48, 72, 96とすると下のように表示された
(潰れてる......)
またスマホでフォントサイズ48のものを見ると下図のようになった
(引き伸ばされてる......)
これらの結果から、縮小されたサムネイルは下図のようにキャプチャされているのではないかと予想している
また、やはり図がサイズによって縦横に引き伸ばされるため、そういうことの起こらない最適な画像サイズ(縦横比)の検証が必要であることがわかった
某葡萄酒さん、これ以上の検証実験の結果はまとめきれていない&着手していないものもあるのでこの辺で勘弁してくださいお願いします。
このたびは誠に申し訳ございませんでした