[脆弱性の検討] 招待機能のストレステスト@Palmu

ホーム » 思想哲学 » [脆弱性の検討] 招待機能のストレステスト@Palmu

皆さん、こんにちは。
Matephysiです。

いかがお過ごしでしょうか。

今日は、僕が利用している配信アプリPalmu(パルム)を取り上げ
ちょっとした思考実験をしてみたいと思います。

それは、
アプリのシステムの脆弱性を悪用した配信活動維持が可能であるのか
という思考実験です。

というのも、最近僕はXにて、
視聴者からのギフトが重要な配信アプリにおいて不正ギフティングの疑いがあるユーザーがいる
と指摘するポストを見かけました。

僕はアプリ管理者でも陪審員でもなく、件の疑惑の当事者でもないので生じた出来事自体を裁く権利はありません。
そのため、誰か特定の人を批判する目的は一切ありません。

ただし、もし仮にシステムに穴がある場合は、その脆弱性を分析し見直しを促すことが配信アプリ全体の改善につながると信じています。
アプリの改善と適切な利用の推進はユーザーの満足度にもつながり、ひいてはユーザーの一人である僕自身が心地よく活動できることにもつながると期待しています。

したがって今回は、思考実験として様々な仮説を置いたうえで、アプリの仕様を利用した配信活動について思いを巡らせてみたいと思います。

繰り返しになりますが、この記事は特定の個人を批判し否定する意図はありません。
また、アプリの不正利用を促すものでもありません。
現状認識とそれに基づく改善、および建設的な議論が活性化することを期待して執筆しました。

Palmuの友達招待キャンペーン

僕がほぼ毎日使用しているPalmu(パルム)という配信アプリでは、新規ユーザー登録を推進し定着させることを目的として
「友達招待キャンペーン」を実施しています。

キャンペーンの詳細は以下の通りであり、登録して24時間以内のユーザーが招待コードを入力し累計5分間視聴すると、招待した/されたユーザーが互いに無料でコインがもらえるというものです。

「人が集まり、定着する土台作り」として始まった友達招待キャンペーンの詳細

僕がアプリを使用開始した去年の時点では招待キャンペーンの存在を知らなかったので利用できませんでしたが、
自分自身が招待する側として、配信に遊びに来てくれた初見さんに招待コードを教えた経験はあります。

条件を満たせば無料コインが確実にもらえ、そのコインを使用して配信アプリの楽しみ方を知ることができるので、とても良い制度だと感じています。

余談ですが、初見さんに招待コードの存在を知らせるのはとても難しいです。
「条件を満たせば無料でコインがもらえるよ」と初めての配信で言われれば怪しむのも仕方がありません。
僕は最近は招待コードの存在を伝えるのを半ば諦めています。

詐欺でもなんでもない善意に満ちた温かな制度なので、Palmu(パルム)の利用を検討している方はぜひ覚えておいてほしいと思います。

善意に潜む脆弱性

今回取り上げる友達招待キャンペーンは、新規ユーザーの流入と定着を促進するために実施されている善意の企画です。
「友達」と書いてあるように、新規登録ユーザーは既存のユーザーとは独立した個別の個人として認識されています。

しかしながら、このキャンペーンでは、一人のユーザーは電話番号登録(SMS認証)の結果として識別されているようです。

もちろん、アプリ運営が公開していない指標でユーザーの個別性を評価して不正を監視している可能性はあります。
しかしながら不正検出システムについては公開されていないため、今回は電話番号登録(SMS認証)のみによってユーザーを識別していると簡略化して考えます。

では、もし仮に無限に電話番号を発行できるリソースがあると想定したら、どうなるでしょうか。

電話番号を際限なく生成可能な個人が招待コードを利用すると、新規ユーザーの流入がないにも関わらず無料コインのみが1ユーザーの手元へ流出することになります。
新規ユーザーの流入と定着の促進という本来の目的は果たせないまま、損失だけが拡大していくことになるのです。

なお、Palmu(パルム)では、このキャンペーンにおける注意事項として以下の3点を挙げています。

自分で発行した招待コードを、自身の別アカウントに入力する行為は、キャンペーンの趣旨に反する違反行為です。

同様に、特典のコインを目的とした複数アカウントの作成も、違反行為として対応いたします。

上記のような不正が確認された場合は、過去の利用状況や実績に関わらず、予告なくアカウント停止となる場合がございます。

注意事項

また、全体の規約として、同一ユーザーの複数アカウントによるギフティングや自分自身へのギフティングは禁止されています。

問題は、電話番号によるSMS認証のみを根拠に同一ユーザーであることを証明することができない点です。
「家族や親せき、知人の携帯である」「端末を手元に置いているだけで、所有者は自分自身ではない」
と言われてしまうと、不正利用の疑いを完全に暴くことはできないのです。
また、罰則もアカウント停止であり、アカウントを利用する個人そのものを罰する効力はないようです。

制度設計上、同一人物による再登録等を十分に防げない場合には、アカウント停止後も同様の行為が繰り返される余地があります。

これまで、先に引用したページにある初心者用のチュートリアルミッションでもらえる数十コインを不正にギフティングしている疑いが指摘されていました。
今回はさらに程度が進み、友達招待キャンペーンでもらえる数千コインを不正にギフティングしている疑いが指摘されています。
以前と比較して規模が大きいだけに、新規ユーザー流入の機会損失と疑惑のあるユーザーの放置および不当に維持された配信ランクに対する報酬という損失を鑑みて運営が正式に不正認定すれば、このキャンペーンがなくなってしまうことすらあり得ます。

本記事で焦点を当てたいのが、友達招待キャンペーンにおける上記の脆弱性です。

思考実験の前提条件

不正利用を認識してキャンペーンを取りやめるのが一番手っ取り早い方法です。
しかしながら、本来の目的である新規ユーザーの流入と定着の促進を考えるならば、簡単に切り捨てることも難しいように感じます。

どのように対処するかは運営側の知恵の見せどころであり、既存ユーザーの信頼獲得につながるチャンスでもあります。

そこで、適切な対処法―例えば新たな条件追加―を検討するために、友達招待キャンペーンを実践的に不正利用することを考えてみたいと思います。

ここでは、非現実的かもしれませんが、
・新規ユーザーの従順性
・無限の電話番号リソース
・電話番号の紐づいたアカウントの退会手続き後、1か月で再利用可能
・電話番号を再利用した新アカウントでは招待コード使用回数もリセット

を思考実験の前提条件として検討します。

また、配信でのランクアップ/キープに必要なコイン数は、8月14日に更新されたメーター値を基準に算出された値を用いることにします。

新規ユーザーの従順性

本来配信におけるギフティングは、視聴者が主体的に決定するものです。
招待コードの受け取りとその後のギフティングは、必ずしも一致しません。
今回行われているキャンペーンも、招待する/されることによる先行優位性を固定化することは意図していないはずです。

ただし、ここでは新規ユーザーの主体性をはく奪し、今回着目する仮想の配信者のためにすべてを費やす従順なユーザーであることを想定します。

つまり、大前提として、どれほど現実的に面倒で物議をかもす恐れのある行為であっても、新規登録ユーザーは24時間以内に所定の条件を漏れなく達成し、特定の配信者のためにギフティングを行うものとします。

無限の電話番号リソース

まず、友達招待キャンペーンに参加するためには、電話番号を用いてSMS認証を完了したアカウントでなければなりません。
そのため、今回想定する仮想ユーザーは新規登録が可能な固有の電話番号を有しているものとします。
そして、友達招待キャンペーンをたった一人の個人が最大限利用するために、その個人は電話番号を無限に利用可能な状態であると想定します。

退会後の再利用可能性

Palmu(パルム)の利用規約には、使用している電話番号について次のような記述があります。

他のアカウントで登録済みの電話番号は、別のアカウントでご利用いただくことができません。

ただし、該当のアカウントが退会済みの場合には、一定期間経過後に同じ電話番号を再び登録できるようになります。

退会後、電話番号が再度使用可能になる具体的な時期はご案内できかねます。

他アカウントで使用されていて電話番号が使えない場合

Palmu(パルム)では、電話番号でSMS認証を済ませたアカウントの退会手続き後、一定期間後に再度利用可能になるようです。
再利用可能になる期間は公開されていませんが、ここではその期間を4週間として扱います。

招待コード使用回数について

友達招待キャンペーンにおける招待コードの発行上限は、10回です。
10回分の招待コードを使用した時点で、招待コードは生成されなくなります。
さらに、アプリ全体の招待上限人数に達した場合、既存ユーザーが10回分使用していなくてもキャンペーンが終了する場合があることが公表されています。

そのため、今回想定するユーザーは10回分の招待コードを生成する能力を持ち、アプリ利用期間中にキャンペーンが終了することはないと仮定します。

また、上述の退会手続き後に招待コード発行上限はリセットされ、再び10回分の招待コード生成権を有するものとします。

必要なコイン数とスコアへの反映

配信でのランクアップ/キープに必要なコイン数として、@Penchan_palmu さんがぱ(る)むの計算機を基に計算しまとめてくださったポストの値を参照します。
詳細は以下のポストをご覧ください。

また、現在Palmu(パルム)では、明らかにされていないアルゴリズムによってギフトがライブスコアに変換され、変換されたライブスコアの累積によってランクが決定する仕組みを運用しています。
上記のぱ(る)むの計算機はこれまでのギフト数とライブスコアの関係から、未知のアルゴリズムの推定を目指したものです。

どれほど卓越した推定であっても、統計データと個別の事例に差が生じる事態は避けられません。
実際に配信をしていると、ギフトから想定されるライブスコアに到達しなかった場合や、本来想定される以上の反映のされ方をする場面も多く目にします。

今回は、ライブスコアへの反映のされ方は考慮しないものとします。
上記ポストの通り計算されたコイン数を獲得すれば、ランクアップ/キープに必要なライブスコアを自動的に達成できるものとして考えます。

想定されている正当な招待

1人を招待して得られるコイン数

まずは当たり前の場合から考えてみましょう。

配信者をSS、電話番号認証を済ませたユーザーをU(i)U(i)とします。
ii は1から10までの自然数で、配信者Sの招待コードの発行回数に相当します。

SU(i)(1i10)S → U(i) (1\le i \le10)

配信者SSが招待コードをユーザーU(1)U(1)に伝え5分視聴の条件満たした場合、
配信者SSおよびユーザーU(1)U(1)はそれぞれ1000コインを受け取ることができます。
さらに、ユーザーU(1)U(1)がバッジを獲得した場合、ユーザーU(1)U(1)は追加で1000コインを受け取ることが可能です。
こうして、ユーザーU(1)U(1)は累計2000コインを無料で獲得することができます。

SU(1):2000coinS → U(1):2000\,coin

Palmu(パルム)では、任意の配信者の枠で1000コインを使用すればバッジを獲得することができるため、
ユーザーU(1)U(1)が配信者SSの枠でバッジ取得まで果たした場合、累計2000コインを受け取ることになり、
2000コインを配信者SSの枠で使用することになります。

したがって、配信者SSはユーザーを一人招待することで、自分自身の枠に2000コイン分のギフトを取り込むことができるのです。

なお、このとき、招待した配信者SSは1000コインを受け取りますが、自分自身にギフティングすることはできないので、自分自身の配信を考える上では考慮しなくて良いです。

10人を招待して得られるコイン数

では、配信者SSが招待コード発行上限の10人を招待した場合はどうなるでしょうか。

これは、上記の自然数ii を1から10まで変化させて考えれば分かります。

SU(1):2000coinSU(10):2000coin\begin{aligned} S → U(1)&:2000\,coin\\ &\vdots \\ S → U(10)&:2000\,coin \end{aligned}

2000コイン分のギフトが獲得できる組み合わせが10パターンあるので、合計で20000コイン分のギフトを取り込むことができるのです。

なお、このとき、招待した配信者SSは合計で10000コインを受け取りますが、自分自身にギフティングすることはできないので、自分自身の配信を考える上では考慮しなくて良いです。

招待権の伝搬

ユーザーU(1)U(1)による招待

本来想定されている正当な招待コードの使用法を考えると、配信者が視聴者を招待することになります。
配信者が利用可能な招待コードは10回分なので、その上限にも限界があります。

しかしながら、配信者に招待された新規ユーザーも10回分の招待権を持ちます。
招待された新規ユーザーが既存ユーザーとして、新たな新規ユーザーを招待することも可能なのです。

ユーザーU(i)U(i)が新たに招待したユーザーをu(i,j)u(i, j)とすると、招待の関係は次のように書けます。
ここで、jjは1から10までの自然数で、ユーザーU(i)U(i)の招待コードの発行回数に相当します。

SU(i)u(i,j)(1i,j10)S → U(i) → u(i,j) (1\le i,j \le10)

先ほど同様に、i=1, j=1i =1, \ j=1の場合を考えます。

SU(1)u(1,1)S → U(1) → u(1,1)

ユーザーU(1)U(1)が招待コードをユーザーu(1,1)u(1,1)に伝え5分視聴の条件満たした場合、
ユーザーU(1)U(1)およびユーザーu(1,1)u(1,1)はそれぞれ1000コインを受け取ることができます。
さらに、ユーザーu(1,1)u(1,1)がバッジを獲得した場合、ユーザーu(1,1)u(1,1)は追加で1000コインを受け取ることが可能です。

したがって、ユーザーu(1,1)u(1,1)は累計で2000コインを受け取ることになります。

ユーザーU(1)U(1)が招待コード発行上限の10人を招待した場合、招待したユーザーU(1)U(1)は合計10000コイン分を、新規ユーザーは合計20000コイン分を取得することが可能です。

ここで、ユーザーU(1)U(1)は配信者SSに招待されたことで、2000コインを受け取っていることを思い出しましょう。
ユーザーU(1)U(1)もユーザーu(1,j)(1j10)u(1,j)(1\le j \le10)も配信者SSにギフティングすると仮定すると、配信者SSは合計で32000コイン分を取り込むことができます。

SU(1)u(1,j):32000coin(1j10)S → U(1) → u(1,j):32000\,coin\,(1\le j \le10)

招待による多分岐ツリー構造

同様に考えると、配信者SSに招待されたユーザーU(1)U(1)に招待されたユーザーu(1,1)u(1,1)もまた、10回分の招待権を行使して新規ユーザーを招待することができます。
u(1,1)u(1,1)に招待されたu(1,1,1)u(1,1,1)も、そのユーザーに招待されたu(1,1,1,1)u(1,1,1,1)も、、、とつながりは事実上無限に増殖していきます。

招待する/されるの関係性が伝搬していくことによって、配信者SSを起点につながるユーザーネットワークはねずみ算式に増加していくのです。

SU(1)u(1,1)u(1,1,1)u(1,1,2)u(1,1,10)u(1,2)u(1,2,1)u(1,2,2)u(1,2,10)u(1,10)u(1,10,1)\begin{aligned} S → U(1)&→ u(1,1)&→ u(1,1,1)\\ &&→ u(1,1,2)\\ &\vdots \\ &&→ u(1,1,10)\\ &→ u(1,2)&→ u(1,2,1)\\ &&→ u(1,2,2)\\ &&\vdots \\ &&→ u(1,2,10)\\ &\vdots \\ &→ u(1,10)&→ u(1,10,1)\\ &&\vdots \\ \end{aligned}

したがって、友達招待キャンペーンにて設けられている招待コード発行上限10回というのは、関係性の限界ではなく、関係性の分岐数のことです。
すなわち、この上限は招待可能性を限定するための制約条件ではなく、ネットワークの拡散速度を規定するパラメータでしかないのです。

ユーザーによる不正利用を限定するような規約上の壁としては機能していないと言えます。

一分岐あたりの増加量

これまでの検討から、招待する/されるという関係性のネットワークは、招待コードを通じて10本の分岐を持ちながら拡大していく多分岐構造を有することが分かりました。

では、一分岐ごとに配信者へ取り込まれるコイン数はどの程度なのでしょうか。
これまでの検討を参考にして、さらに一段階関係性を深めたユーザーのつながりについて考えます。

SU(1)u(1,1)u(1,1,k)(1k10)S → U(1) → u(1,1) → u(1,1,k)\,(1\le k \le10)

招待されたユーザーu(1,1,k)u(1,1,k)は合計で20000コインを獲得し、10人分招待することでユーザーu(1,1)u(1,1)は合計10000コインを獲得します。
また、ユーザーU(1)U(1)がユーザーu(1,1)u(1,1)を招待したことによって、それぞれ1000コインと2000コインを獲得します。
さらに、配信者SSがユーザーU(1)U(1)を招待したことによって、それぞれ1000コインと2000コインを獲得します。

以上のことから、すべてのユーザーが配信者SSにギフティングすると仮定すると、配信者SSは合計で35000コイン分を取り込むことができます。

この関係性は、既存のユーザーu(i,j)u(i, j)が新規ユーザーu(i,j,k)u(i, j, k)を10人招待した場合を用いて一般化することができます。
ここで、i, j, ki,\ j,\ kは1から10までの自然数です。

u(i,j)u(i,j,k)(1i, j, k10)u(i,j) → u(i,j,k)\,(1\le i,\ j,\ k \le10)

新規ユーザー10名は合計で20000コインを獲得し、10人分招待することで既存ユーザーu(i,j)u(i,j)は合計10000コインを獲得します。
さらに、既存ユーザーu(i,j)u(i,j)は招待されたユーザーとして2000コインを受け取り、招待したユーザーに1000コインを取得させます。

したがって、既存ユーザーが分岐点として新たなユーザー10人をつないだ場合、ブリッジとなる自分自身を含めたユーザー11名から配信者SSへ流入するコインの増加分は合計で33000コインとなります。

招待による増加分算出の一般式

最後に、招待によって配信者SSへ流入するコイン数を定式化してみましょう。

既存のユーザーが分岐点として新たなユーザーを10人つないだ場合、配信者SSへ流入するコインの増加分は合計で33000コインであることが分かりました。
既存ユーザーu(i,j)u(i,j)と新規ユーザーu(i,j,k)u(i, j, k)10人の合計11名分の関係で合計33000コインが配信者SSへ流入することから、招待されたユーザーが一人増加するごとに3000コイン分だけ配信者SSへ流入するコイン数は増えることが分かります。

ここで、配信者SSと直接つながったユーザーU(i)U(i)において配信者SSが獲得する1000コイン分は利用できないことから、配信者SSとユーザーU(i)U(i)の招待関係から配信者SSへと流入するコイン数は2000コインであることに注意が必要である。

以上を考慮すると、配信者SSが直接招待したユーザー数をdd、配信者Sにつながる新規ユーザーの総数をNNとすると、招待によって増加するコイン数C(N,d)C(N,d)

C(N,d)=3000N1000dC(N, d)=3000N-1000d

と書けます。

B1ランク到達に必要な招待数

友達招待キャンペーンを利用した招待のネットワークにより、配信者SSに流入するコイン数C(N,d)C(N,d)は、直接招待したユーザー数をdd、配信者Sにつながる新規ユーザーの総数をNNとして

C(N,d)=3000N1000dC(N, d)=3000N-1000d

と書けることが分かりました。

次に、実際に配信におけるランクに目を向けてみます。
ここでは、各事務所が配信初心者応援キャンペーンの条件の一つとしているB1ランクへの到達を検討してみます。

2026年8月14日現在、DランクからB1ランクへ到達するために必要なコイン数は37400コインとされています。

配信者SSの元へ37400コイン相当が流入するための条件は、

C(N,d)37400C(N, d)\geq37400

と書くことができます。
配信者SSがコインを獲得することはランクアップにつながらないため、ここでは直接招待したユーザー数を1人(d=1)(d=1)として考えます。

したがって、

3000N100037400N12.8\begin{aligned} 3000N-1000&\geq37400\\ N&\geq12.8 \end{aligned}

と計算され、B1ランクに到達するために必要な新規ユーザー数の下限は13名であることが求まります。

興味深いことに、冒頭で考えた配信者SSが招待コード発行上限の10人を招待する場合より、配信者SSに招待されたユーザーU(1)U(1)が既存ユーザーとして新規ユーザーを招待する場合の方が、ランクに対して強力な効果を有することが分かります。

友達一人を起点として残り12名を招待し、配信へギフティングしてもらうことは、それほど非現実的ではないように感じます。
友達招待キャンペーンの制度設計上の脆弱性とともに、各事務所が実施するB1タッチイベントの在り方も見直した方が良いのかもしれません。

再登録による循環可能性の検討

新規ユーザーの獲得と定着を目指した友達招待キャンペーンという、アプリ活性化のための善意の制度に見出される脆弱性について検討してきました。
結果として、配信者へ流入するコイン数を定式化することに成功し、新規ユーザーを13名(うち一人は配信者が直接招待)招待することでB1ランクへ到達することができることが明らかになりました。

事務所に所属している配信者は特に、デビュー1か月でB1ランク到達を目指して日々頑張っています。
どれだけ頑張っても、なかなかうまくいかないものです。
僕自身も苦戦し、消耗した記憶があります。

残酷な現実があるにも関わらず、実は公式の制度を利用することでいとも簡単にB1ランクへ到達することができることが分かりました。

これは、明らかな制度上の欠陥であり、公正な配信活動を阻害する要素となりかねません。

しかしながら、制度の脆弱性を利用した不正な配信活動による影響は、これだけに収まりません。
ここからは最悪の事態を想定し、分析と考察を深めていきます。

最悪の事態とは、
「アカウントの登録と退会、そして再登録を繰り返すことで、招待コード生成上限をリセットし、
限定的な電話番号のリソースを用いてランクを維持すること」

です。

B1ランク維持に必要な追加招待数

DランクからB1ランクに到達するために必要なコイン数から、B1ランク到達に必要な招待数を算出しました。
では、到達したB1ランクを維持するためには、追加でどれほどのユーザーを招待する必要があるのでしょうか。

2026年8月14日現在、B1ランクを維持するためのコイン数は、一週間当たり24430コインとされています。

既存ユーザーが新たなユーザーを招待することで、3000コイン分だけ配信者SSへ流入するコイン数が増えることは既に述べた通りです。

このとき、配信者SSの元へ24430コイン相当が流入するための条件は、新たに追加するユーザー数をnan_aとすると

3000na=24430na=8.143…\begin{aligned} 3000n_a&=24430\\ n_a&=8.143… \end{aligned}

と計算され、一週間B1ランクを維持するために必要な追加ユーザー数の下限は9名であることが求まります。

毎週新たに9名ずつ新規ユーザーを招待関係のネットワークに取り込むことによって、理論上永久にB1ランクを維持することが可能です。

循環を前提としたリソース数

ここで、事態は最悪の局面を迎えます。

すなわち
「一度使用した電話番号を再登録することによって、招待コード生成上限をリセットする」
ことでランク維持を可能にする循環モデルの適用です。

招待コードを利用し配信者へのギフティングを行い、役目を終えたら退会させ、資格が復元されるまで待機させておくという、
役割ごとに共存させておけるだけの電話番号のリソースを確保しておけば、ランク維持を効率良く行うことが可能になります。

今回、退会後に同一電話番号が利用可能になるまでの日数を4週間と前提しています。

DランクからB1ランクに到達するのに必要な招待数13名と組み合わせると、Dランクから配信をはじめ電話番号が再利用になるまでの期間B1ランクを維持するためのリソース数の下限は、

13+9+9+9=4013+9+9+9=40

と計算できます。

ランク維持に必要なリソース数算出の一般式

あるランクにおいて、Dランクからそのランクに到達するために必要なコイン数をRR、一週間そのランクを維持するために必要なコイン数をTTとすると、ランク到達に必要な招待数NaN_aとランク維持に必要な追加招待数nan_a

Na=R+10003000N_a=\biggl\lceil\dfrac{R+1000}{3000}\biggr\rceil
na=T3000n_a=\biggl\lceil\dfrac{T}{3000}\biggr\rceil

と計算できます。
よって、再登録が可能になるまでの期間に必要となる新規ユーザーのリソース数KK

K=Na+3naK=N_a+3n_a

と書くことができます。

各ランクにおけるリソース数

2026年8月14日時点で各ランクの到達・維持に必要とされるコイン数を基準に、上記の一般式から必要なリソース数を算出すると、次のようになります。

DC1C2C3B1B2B3A1A2A3A4A5SSS
NaN_a012613315490145216310428583812
nan_a1124912182736455872152336
KK44818406710817125335148464410391820
(NaN_a:ランク到達に必要な招待数, nan_a:ランク維持に必要な追加招待数, KK:再登録が可能になるまでの期間に必要となる新規ユーザーのリソース数)

友達招待キャンペーンにおける脆弱性

友達招待キャンペーンを利用してランクをアップ/キープさせる方法について検討してきました。

最初に述べた通り、本記事は善意に基づき実施されているキャンペーンの悪用を促進するものではなく、
脆弱性を指摘することで検証すべき事柄を見定め、改善を促すためのものです。

いくつかの前提の下で行った今回の検討の結果、規則では補いきれない本質的な課題が存在することが示唆されました。

すなわち、

・新規ユーザーの認証コストが低い
・招待権が再帰的に伝搬する
・招待資格の復元可能性がある
・配信のランク評価へ継続的な強い影響がある

ことが示唆され、これら要素が複合的に絡み合うことによって公正な配信アプリ運営を阻害する可能性が想定されました。

僕自身はアプリのシステム全体を知っているわけではありません。
むしろ単なるユーザーであり、何も知らないと言っても過言ではありません。

そうであるにも関わらず、制度を最大限悪用することで構造的な問題が潜在していることを垣間見ることができました。

アプリ運営側は今後、悪用への対策として、
例えば招待コードを入力すればライブスコアに関係する招待限定アイテムがもらえるように変更するなど、
キャンペーン内容の変更が必要かもしれません。

同様に、配信事務所が実施しているBランク到達ボーナスも見直す必要があるかもしれません。

もちろん、現状のまま悪用する人がいない状態が続けばそれに越したことはありませんし、
本来の目的である新規ユーザーの獲得と定着がアプリ全体としての課題であることに変わりはありません。

本記事で検討した内容が、アプリ活性化のためのインセンティブ機構が思わぬ形で悪影響を及ぼさないような制度設計を再考するきっかけとなれば幸いです。

ご覧いただきありがとうございました!
是非、次回の投稿もお楽しみに!

コメントする

CAPTCHA