  |
はてなキーワード: ネイティブアプリとは
あれを一番簡単に実現するのはソース送信だけどそれは無しとして他の方法を模索してみる。ちなみに解は出てない。
※想定問答 Q「サーバサイドでやれ」 A「石油王連れてきて」
レコメンド対象にしたいキーワード辞書をアプリに同梱してマッチした単語だけ送る。
本文丸ごとでは無いんで多少は忌避感下がるけど、いつ・誰が・どのURLでそのキーワードをブラウザで見たかは伝わっちゃう。
パーソナライズ不要なら「誰が」も落とせるけどそれだと精度出なかったからあの仕組みにしたんだろうしねぇ…
あと本当に本文だけ使ったレコメンド目的ならURLも不要だけどwww.muji.com→オサレみたいな特徴を加えたかったのかな。
--
最近はiOS(CoreML)にもAndroid(NNAPI)にも機械学習機能あるようで、
ネイティブアプリなんだからその辺触れるんだしクライアント側で完結しちゃえば?という発想。
レコメンド先のコンテンツ丸ごとスマホに持つわけにはいかんから、
コンテンツID?カテゴリ?的なものを出すとこまでやって中身はサーバに取りに行くんで本当にクライアントだけで閉じるわけじゃ無い。
パーソナライズ観点で一人一人特注のモデル作って配るとかはしんどそうだけど、
ある程度セグメント切った層ごとに事前にモデル作るぐらいなら何とかなるんでは。
ああでもレコメンド対象が日々増えるWeb記事だとモデル頻繁に更新するからデプロイが辛いか。
スペックもりもりのサーバでやる推薦が現代のスマホでそもそも代替出来るのかはわからん。
エッジAIなる名目で各社頑張ってて目的の一つはセキュリティだから、今は無理でも将来に期待?
--
分類にしろ推薦にしろ元データそのものをダイレクトに結果に変換するんじゃ無くて一度単なる数値の配列（特徴ベクトル）に変換して、
そのあとモデルに突っ込んだら中でこねこねヘイお待ち!と出てくるんだよね?
その特徴ベクトルに変換のとこだけクライアントでやってそれ送れば?という発想。
スペック問題はあるけどレコメンド全部やるよりはマシだよねと淡い期待を抱いている。
特徴ベクトルから元のデータに戻せるとアウトだけど可能なのかね。
文字列を数値にしててかつ情報量が落ちて結果が1対1にならないから、完全な復元は無理だと思うけどどうだろう。
ありとあらゆるキーワードを事前に変換しといて結果から逆引きすれば変換元候補を出すくらいはできるんかな。
--
いろいろ考えたけどソースそのものじゃ無くてもそれに近い情報はどうやっても送るんだから、
コールセンターに電話すると自動音声で「サービス品質向上のために通話を録音します」的なアナウンス流れたりするのと同じで、
おすすめ機能ってこういう情報送ります的な説明をアプリ内ですべきでそれ無しにやっちゃダメだったんでしょう。
アプリの実物触る前に終わったので実際には説明してたんならごめんなさい。
--
https://toolbar.rakuten.co.jp/mobile/rule.html
利用者が本アプリを利用した場合、利用者は、第6項の定めに従い、これを停止しない限り、本アプリがデバイスにインストールされているブラウザの全てのウェブ閲覧履歴（http（https含む。以下本条において同じ。）で始まる閲覧ページURL、アクセス日時（分秒）、表示されたウェブページのHTMLソース、クッキー情報（Cookie）, ウェブサイトの閲覧履歴、リファラ, ユーザーが使用しているOSやアプリのバージョン、位置情報をいい、以下「ウェブ閲覧履歴取得情報取得情報」といいます。）が当社によって取得されることに同意するものとします。
当社が取得するウェブ閲覧履歴取得情報には、ウェブページのURLを含み、当該ウェブページのセキュリティ環境によってはURLにIDやパスワード等の非公開、又は機密性の高い情報が含まれることがあります。よって、機密性が高い情報、または機密性が高い可能性のある情報を閲覧する環境において本アプリを利用される場合には十分にご留意ください。
ソースどころか脆弱性無い限り聖域のクッキーまで取る豪快さを見習おう。
--
ちなみにフェアじゃないので一応書いておくと「楽天ウェブ検索 規約」でググると出てくるこっちのブラウザ拡張機能版は微妙に内容が違ってクッキーは入ってない。
上のアプリ版はアプリストアの説明にURLが書いてある。なんでアプリとブラウザ拡張機能で2種類あるのかは分からん。
拡張機能じゃ取れないから? でもサイトごとのクッキー編集する拡張とかあったような・・・
https://toolbar.rakuten.co.jp/intro/rule/
２． 利用者が本機能を利用した場合、利用者は、第6項の定めに従い、これを停止しない限り、本機能がインストールされたブラウザの全てのウェブ閲覧履歴（http（https含む。以下本条において同じ。）で始まる閲覧ページURL、アクセス日時（分秒）、表示されたウェブページのHTMLソースをいい、以下「ウェブ閲覧履歴」といいます。）が当社によって取得されることに同意するものとします。
３． 当社が取得するウェブ閲覧履歴には、ウェブページのURLを含み、当該ウェブページのセキュリティ環境によってはURLにIDやパスワード等の非公開、又は機密性の高い情報が含まれることがあります。よって、機密性が高い情報、または機密性が高い可能性のある情報を閲覧する環境において本機能を利用される場合には十分にご留意ください。
あとこの規約についても先日malaさんが突っ込んでいるので第一発見者ではないです。
https://twitter.com/bulkneets/status/1339435587015639041
--
ソースどころかクッキーまで取ってますと堂々と書いてるほうが燃えずに、
はっきりとは書かずに取ってたほうが燃えてるの、
やらないと思ってたやつがやる・やると思ってたやつがやる、どっちもやってるけど燃えるの大抵前の方なの、
中国語の勉強を始めるにあたって自分用に単語帳アプリを作ってたら思ったより
大掛かりになってしまったのでせっかくなのでドメイン取得して公開してみたよ
当初は１週間くらいで完成させる予定だったけど2ヶ月くらいかかってしまった……
イメージとしては↓な感じ
https://i.imgur.com/VE4mA72.mp4
既存のスマホアプリは多くがデバイス間のデータの共有(特にPCとの)がやたら面倒だったり
編集画面がスマホでしか提供してなかったり微妙に不便なものが多かったので
今回はWebサービス(+PWA)として自分好みなUIで開発してみたよ、粗い部分もあるけどとりあえず公開だけ。
途中経過の保存とかは無理だけど一応未ログインでも使えるのと、
会員登録さえすれば覚えた単語、覚えてない単語、シャッフル機能で並び替えたカードの順番とかが更新した瞬間にDBと同期されるので
朝に自宅のPCで半分くらい暗記して残りは職場の昼休みにスマホからワンタップでそのまま続きを実行する、とかができる。
目玉機能としては音声認識で発音確認ができること(win&androidのchrome限定だけど)
日本人には『right』『light』とか『year』『ear』の発音が難しいとはよく言われてるけど、その辺りの発音の感覚を音声認識のできる範囲で掴むことができるよ
あとは、中国語(簡体字限定)ではピンインを自動で表示してくれたりする
今回開発してて一番失敗だったと思ったのは、公開前提じゃなかったのでマネタイズとかについての展開を開発中あんまり考えてなかったこと。
今回PWAとしてスマホアプリと近いものをWebで実装する感じを意識したけど、このやり方だと広告サービスの審査にはまあ大体は落ちる。
Ankiltは単語帳一覧があって、その下に詳細ページ的な位置づけとして単語帳の実行画面があるページ設計になっている。
実行画面のファーストビューでは大体『apple』とかの1ワードが表示されてるだけなので、AdSenseを始めとしたASPからすると『文字が少ない＝価値がないコンテンツ』と見なされてしまうみたいだった。
多くのASPやSSPのWeb用広告はあくまでWebメディアやブログ用のサービスであって、
いかがでしたブログでも適当に作った5chコピペブログでもいいから一定の文字数で埋まったページではないと価値があるとは認めてくれないようで、
文字が少ないこの手のアプリやブラウザゲームをPWAとして実装した場合、仮にどんなに高機能で品質の高いものを開発したとしても上記理由で
基本的には単価が低いかアダルト寄りなもの以外つけにくく、サブスクモデルならともかくとして既存の人気ASPに依存した広告収入モデルとはかなり相性悪そうだと思った。
マネタイズを狙うならもっとちゃんとWebライクなインターフェースにして文字をなんとか埋めたりしてASPに忖度するか、
またはガワネイティブででも同じ仕様のネイティブアプリを作ってアプリ用広告(これはWeb用広告と審査基準がまた異なる)を載せた上でPlay Storeとかで配信する、
みたいなところに結局行き着いちゃう気がする(そこまでやるならPWAをやる意味は…)
要するにWeb用の広告からは「こんなのWebメディアじゃないから広告載せさせない」って言われてて、アプリ用の広告からは「こんなのアプリじゃないから広告載せさせない」って言われているような状態。
ちなみにガワネイティブ案の場合は広告審査とは別にGoogleやAppleのアプリ審査を通過するためにまた知恵を絞らなければならない。
調べてみるとPWA開発で同じような問題に直面してる人はまあまあいそうだった。
PWAってこの辺の事情があるから魅力的な技術の割に未だに流行んないのかなぁって気がした。
既存のWebサービスを補助としてPWA対応するとかならまだしもガチガチのアプリやゲームを最初からPWAで作るなら心捨てていかがでしたブログでも作った方が金目当てだったらどう考えても楽だし得。
まあ今回は公開しても利用者自分だけとかになる可能性もあるので次回の教訓としてとりあえずは考えないことに。
今は最低限だけ実装してる感じだけどモチベの問題もあるのでもし需要があれば拡張していく予定。
まあよかったら見てみてね。
とりあえずスマホ対応が結構でかいかな。10年前にスマホあったけど、普及はこの10年。PCだけ考えていればOKだったのが、スマホも考えるとなると結構キツイところ。（PC横長、スマホ縦長だし）
あとはWebアプリ作る感じだとパフォーマンスの制約(ここにもスマホは絡む)と実現したいことのギャップもキツイ。普通に常時通信とか当たり前だし、Flash死んだし。
結構普通にネイティブアプリでやってたことがWebでできないとおかしい的な感じもでかいかな。ゲーム界隈とかほんとすごいと思うよ。使ってると気づかないんだけど、気づかせないのがすごい。10年前ならネイティブアプリとWebで機能全然違うとか普通だったしね。。。今同じな方が普通だしね。。。そうなると開発規模が増えてFWとかモジュール管理が欲しくなってきて、ただそこも独自ルールを覚える必要もあるし更なる問題も出てくるからそこにも対応せんといかんしね。。。同じように実現できてても「まだNode.jsで消耗してるの？」とかクソヤローもたまに出てきて確かに便利だけど面倒なんじゃ！ってなるし。←ここは主の主張とマッチしてござるなｗｗｗんんｗｗｗ
いろんなライブラリたちがバージョンアップして、適材適所でやってたつもりが一本化できるんじゃね？できないの？検証しなきゃ・・・とかやらんとならんってのもあるなぁ。
まあなんだ、この10年でWebも変わってはいるんスよ。ただ同時にWeb"系"が隆盛して、マウンティーになっているのも事実かもなーなんて思う。俺なんてjQueryおじさんにもWeb系イケメンにもバーニーおじさんにもなれないような人間のたわごとですけどね・・トホホ
ワイ「おっ、ええやんけ。さっそくインストールしてみっか」
dotnetコマンド「Running 'dotnet restore' on winformtest/winformtest.csproj...
/usr/share/dotnet/sdk/3.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(59,5): error NETSDK1100: Windows デスクトップ アプリケーションを構築するには Windows が必要です。」
ワイ「そういうとこだぞ！」
業界に入る前にインターンとかでこの辺を知ると、その後のキャリア選択に有用です。
プロジェクト全体を回す人として、スクラムマスターとか、プロジェクトマネージャー、が設置されているケースもあります。
関わる担当者も、会社によって、置かれていない職種もあります（役割を兼務など）。
http://b.hatena.ne.jp/entry/s/co3k.org/blog/why-do-you-use-jwt-for-session
と厳しい叱責を受けたため、無能の見識を書いてみた。
「聞くは一時の恥、聞かぬは一生の恥」のとおり、
せっかくの機会のため、びしばしセキュリティに関する認識の甘さを指摘してほしい所存
作ったシステムではexpは約1時間でやってしまいました(機密保持契約違反を恐れ多少ぼかしております)
確認している間に1時間はかかるからいいやと思ってしまっていた
師はきっとJWT生成直後3秒でユーザーが
と気づいて通報
そして師が2秒で
「これは、セッションハイジャックだ！」
と検知してセッション遮断、秒速で一億円の被害が出るところを阻止する前提なのではないかと推測している
これは確かにJWTだと厳しそうだ
セッションを任意に切れることに意味はないのでは、と思えてきたが、浅はかだろうか
(師はログインを即座に検知してセッションを切れるから問題ないのか)
とにかくアカウントロック機能を作れば上記の懸念全てにきれいに対応できそうに見えている
この理屈だと例えば.envに書くような他のkeyも定期的な交換が必要に見える
これはまずい、自分の今までの見識の甘さを思い知らされた
keyは初回に設定したのみで、定期的な交換を勧める文が見つからない
私の検索力不足なのかと思ったが、もしかして彼らもこの危険性に気付いていないのではないか
JWTはhash化してつないでいる前提で
解読時間は下記を参考に、計算はwindows10の電卓アプリを用いて手動で行った
https://ja.wikipedia.org/wiki/%E7%B7%8F%E5%BD%93%E3%81%9F%E3%82%8A%E6%94%BB%E6%92%83
英数字大文字小文字で約60の時は10桁で20万年と書いているが
現代の解析技術は20万倍は速度が出ると仮定して1年として計算する
日本語に直すと60京4661兆7600億年かかる計算となった
実際にはこれが6.0466176e+17倍されさらに3600倍されつまりどういうことだ
そもそも師は何年で交換したら安全と書いていないが、何年なら安全という意見だったのだろうか
私の理解ではとかくuser_idのみ必要なら意味がないと思っていたため落ち込んでいる
まず、IDとpassを内蔵するネイティブアプリに対するapiサーバでの実装経験しかないこと
JWTが切れたら都度IDとpassを投げる方向でリフレッシュトークンは実装しなかったことを告白しておく
そのためapiサーバで上記前提で用いた場合に考えたことを書く
webアプリのJWT実装経験はないので、そちらの論は差し控えさせていただく
では危険で
JWT送信→セッション(cookie形式?)送信切り替え→セッションからuser_id取得
とりあえず思いついたのは下記だった
tokenはheaderにbearerで付けユーザーID(あるいはそれに代わる特定可能な識別子)が含まれる
httpsで通信するのでパケットキャプチャによる傍受は不可能と思っていた
(httpで通信するのはJWTとかcookieとか関係なく傍受できるため考慮しない)
0に何をかけても0なので、何回送っても解読されないならJWTを何回送っても問題ない
というかJWTが抜けるなら同様にheaderに付けるcookieでも抜けると思うので
JWTだからといって危険性に差はない、という論拠により安全性は変わらないという個人的結論になった
※余談だが、たまに送る回数が少ない方が安全という
攻撃者がアプリに保存されたJWTが取得できるならIDもpassも同じ方法で抜けそうに見えた
(厳密には保存場所が違ったかもしれんが実装依存なので同一とする)
その前提のため、わざわざ
JWT送信→セッション(cookie形式?)送信→セッションからuser_id取得
で接続しても、おそらくcookie形式で送れる何かもJWTらと同じ方法で抜かれると思われる
つまりcookieだろうがJWTだろうがアプリから直接情報が抜かれる危険性には変わりがないという結論になった
つまりcookieだろうがjwtだろうがidとpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら
JWT→user_id
でいいじゃん、わざわざcookieと同様の形式を間に挟むの無駄じゃん、となりコメントの発言に至った
ここまで書いて、常にJWTにsession_idを含めておいて送ることを意図されていた可能性にも気づいたが
セッションにするメリットとして唯一思いついているのは任意にサーバ側でセッションを切れることだが
それを指していたのであろうか
余談だが、ブコメの雰囲気に日和って「ユーザーIDのみ入れ」(そもそもJWTを自然に作れば入るのだが)
というセッションストア的にJWTに他の情報を入れると入れない時に比べて危険性があがることに同意したような記載をしてしまったが
結局JWTが奪えたら中身に関係なくbearerとしてセットして接続するだけなので
正直JWTを使った時点でついでにセッションストアのように使おうが使わまいがセキュリティ的にそこまで変わらないのでは、と思っている
強いて上げるならセッションに保存している内容が分かる可能性があり、サーバー内部の実装が推測できる危険があるくらいだろうか
でも暗号化したらよいのでは、と思った
expを適切に設定しつつ、必要ならアカウントロック機能を入れる
(アカウントロック機能はJWTに関係なく被害の増加を抑えられる可能性がある)
少なくともapiサーバ→ネイティブアプリに関して、セッションIDを含めても危険性は変わらない
正直webアプリでも大して変わらんのでは、と思っているのは内緒である
HTML5 が宣伝されて、世間がクラウドだのと言い始めたが、
iPhone や Android のネイティブアプリが普及して、Chrome bookが廃れたのを見て、ざまあみろと思った。
社内のアプリケーションが InternetExplorer専用のクソ使いにくいWebアプリになったりして印象が悪かった。
開発元企業が、あたかも先進的なテクノロジーのように宣伝しているのを見て死ねと思った。
ところが2018年現在、未だかつてないほど、Webアプリを使う人生を送るようになっている。
やはり Microsoft Office が Webアプリ化した影響は大きかった。
俺の中で Webアプリもなかなかやる、という認識に変わった。
ストレージに Google Drive を使用するとして、Googleドライブから接続できる範囲のWebアプリしか見えてこない。
iPhone や Android、MacやWindowsといった胴元のいるプラットフォームなら、アプリストアが整備されるので、
必要なサービスが探しやすいが、Webアプリはとにかく検索性が悪いと思う。
検索性が悪いため、ユーザーが集まらず、サービスが簡単に終了したりする。
なんだかんだでネイティブアプリが好きだが、Webアプリも使っていきたい。
この問題が解消されることを願っている。
そう思うだろ？
そこら辺の問題はネイティブアプリで「広告がない代わりに値段がついているアプリ」と、「広告がある代わりに無料であるアプリ」を比較した際に
圧倒的に後者の方が収益性もDL数も高かったことから、やっぱりガラケーおじさん並みの「珍種」でしかないことが市場によって証明されている。
とはいえ一定数広告を嫌う人間はいるので、その人間をも食い物にするために「広告オフにするオプション」を有料で提供したりもしている。
つまりは、オフにできない広告がある現状がまだ不自由なだけで、アドオン広告を消すための有料オプションが基本的に広告を出力する全てのプラットフォームで採用されれば解決する問題とも言えるわけだ。
増田だって電車降りて駅から出た途端に無数の広告に囲まれてるやんか。
そこで蕁麻疹起こすんか？ 起こさんだろ。そういうこっちゃ。
さてさて、いきなりタイトルがこれですが、何で書こうかと思えば2月14日に配信したミリオンのニコ生がミリシタのことは触れてもコンテンツとしてのミリオン5周年に全然触れてないので、5周年前日というこの日にこちらが勝手に振り返ってみましょうかと。本当は副題に「-ミリオンライブ 5周年に寄せて-」と入れるつもりでしたが、入らなかったのでここに記載w
なお、筆者はどちらかといえばデレマス寄りの人間ですので、それを承知の上でお読みください。
元よりこの作品、あらゆる意味で「大人の事情」が複雑に絡み合った作品でした。遡ること2011年11月に先んじて「シンデレラガールズ」(モバマス)がリリースされたわけですが、想定の10倍の売上を記録したもんだからバンナムにとってもソーシャルゲームは稼げると確信付けたに違いありません。しかしモバマスはCygamesに外注したが故に当然レベニューシェアが何割か取られることになります。そこで本家の開発陣で作った純正のアイマスソシャゲを作ることで自社の収益を最大化したいのは言うまでもありません。
一方でモバマスの人気に指を咥えていた会社もいました。モバゲー(DeNA)のライバルであるGREEです。元々他でヒットしたソーシャルゲームを模倣して売上を伸ばしていた同社からすれば、アイマスは喉から手が出る程欲しい作品です。こうした利害の一致からバンナムとGREEは戦略的業務提携し、GREE版アイマスの開発がスタートしました。
ところでこのGREE版アイマスは当初男性アイドル物になるはずでしたが、坂上総合プロデューサーによって時期尚早と待ったがかけられ「765プロの新人」という設定に変わりました。また、上層部からはモバマスのように100人のアイドルを出せとの指示もあったようですが、結局は50人(765AS13人+新規37人)に落ち着きました。グリマスがいわゆるSideMのようなものとして生まれてたらどんな未来だったか想像つきませんよね。
さらにバンナムはもう一つの課題を抱えていました。IP(知的財産)を軸としたグループ企業間の連携です。今までアイマスの音楽CDは日本コロムビアが販売してますが、これを自社グループ傘下のランティスからも発売すれば当然グループ連結の売上にも寄与します。そんな形でGREE版アイマス、即ちミリオンライブ！(以下グリマス)は誕生します。
ここで寝耳に水だったのはモバマスの開発元であるCygamesやモバマスの出演声優陣です。木村取締役(当時)の「サイゲームスとモバマスユーザーはズッ友だよ」発言や、一部出演声優からの発言からも察するに、グリマスが出れば自分たちはお役御免になってしまうのではないか、そういう危機感があったのです。
奇しくもモバマスのテーマ曲「お願い！シンデレラ」(4月10日)とグリマスのテーマ曲「Thank you!」(4月24日)はほぼ同時期に発売、しかも「Thank you!」は8thライブの先行抽選販売まで付いていました。極め付けは2014年公開の「THE IDOLM@STER MOVIE 輝きの向こう側へ！」でミリオンのアイドル7人が出演すると聴いてアニメ出演まで出し抜かれてしまいます。なお2013年当時のモバマスはオンラインゲームとしては「艦これ」、二次元アイドル物としては「ラブライブ！」という強力なライバルの奇襲に囲まれてました。つまり前門の艦これラブライブ、後門のミリオンライブ！という状況だったのです。
もっともこれがモバマスが奮起する原動力にもなりました。CINDERELLA MASTERシリーズや年1回の総選挙でボイス付きのアイドルを増やし、新規イベントを次々と増やすことでユーザーの繋ぎ止めを図ったのです。単独ライブもアニメ化も、いわば自分達で掴んだようなものです。
さらにCygamesが水面下で開発していた新作RPG「グランブルーファンタジー」も助け舟になりました。2014年秋に開催されたコラボイベントはモバマスを梃子にグラブルのユーザー数や売上を拡大した契機になり、またアニメ化前にPの熱気を暖めることにも成功しています。つまりこの逆境が無ければ今のシンデレラガールズもCygamesもなかったことでしょう。
2015年から始まったアニメが軌道に乗ったシンデレラガールズに対して、ミリオンライブ！は苦境を迎えることになります。初年度から2年目こそ毎月のようにCDがリリースされる程勢いは良かったのですが、コアであるゲームのアクティブユーザーや売上が漸減していってたのです。それもそのはず、グリマスがリリースされた2013年は前年に「iPhone5」が発売し、「パズル＆ドラゴンズ」(パスドラ)等のヒットでブラウザソーシャルゲームからネイティブアプリにトレンドが移行していました。アイドル物でも「ラブライブ！スクールアイドルフェスティバル」(スクフェス)などアプリを主戦場とするタイトルが中心となり、前時代的なブラウザソーシャルゲームでは太刀打ちできる状況ではなかったのです。でも楽曲のストックは沢山あるのだからリズムゲームを中心にしたアプリに移行すればいいと皆考えるでしょう。
ところがここで思わぬ伏兵が出てきます。そう、シンデレラガールズのリズムゲーム「スターライトステージ」(以下デレステ)です。完成度の高い3Dモデルによるリッチな演出、アニメまでの楽曲の少なさを逆手に取ったイベント新曲の導入、まるで玩具箱の人形が飛び出してきたかのようなルーム機能…元よりのシンデレラガールズ達の知名度の高さも手伝って、デレステは瞬く間にスマホ向けリズムゲームのトップシェアに上り詰め、今や国産ゲームアプリでも年間10位以内の売上を誇ります。想定以上の大型タイトルが出現したため、当初2Dで開発していたというミリオンライブのアプリ化計画は振り出しに戻されます。
そして2017年にようやくリズムゲーム「シアターデイズ」(ミリシタ)をリリースすることになります。デレステを越えるアプリにすべくパートによる歌い分けやフルポリゴンによるコミュニケーションパートなど意欲的な技術が導入されるのでした。サービス開始当初は配信楽曲の少なさやイベントスケジュールの遅さなどが響きつまづきましたが、最近になりようやく毎週のセールスランキングで上位に食い込むようになりました。さすがにデレステ程でなくてもリスクヘッジのようにデレステが売上の谷間を作りやすい月の半ばから下旬を補完するくらいにはなったのです。P視点ではグリマスサービス終了の影響か「俺たちがミリオンを支えなくてどうするんだ」と奮起するようになったのではないかとも考えられます。
てな訳で皮肉なことに同じアイマス一家の姉シンデレラと妹ミリオンがライバルとして、互いを高め合うべく切磋琢磨しているのです。しかしシンデレラもミリオンもまだ安穏としていられません。スマホ向けアイドルリズムゲームの元祖スクフェスが3DCGを身につけた新アプリとなって逆襲の機会を伺ってますし、今春グリマスのサービス終了と引き換えに、完全新作「アイドルマスター シャイニーカラーズ」(シャニマス)が控えています。同じアイマス一家にも新入りの後輩というライバルが生まれるのです。
思えばアイマスの歴史は逆境を乗り越える歴史でした。大体最初のアニメ化はサンライズ側の都合で設定や声優まで替えられてしまうような作品でした((ゼノグラシア自体はスパロボX-Ω参戦など、むしろ公式も積極的に弄ってくれてるのでもう誰も気にしてませんがね))。それでも9.18という混乱を乗り越えてアニメで栄華を極めた765プロ、所詮傍流という立場から奮起し、今やアイマスは元より二次元アイドル物有数の稼ぎ頭に進化したシンデレラガールズ、先の9.18で生まれたが故に「忌み子」扱いされたJupiterが新たな事務所、新たな仲間と共に真の栄光を掴んだSideM…みんな苦難を乗り越えて今の栄華があるのです。
ならばミリオンライブ！の逆境はまさしく今ではないでしょうか。原典の終了、アニメ化の目処も立たず、シャニマスという後輩が生まれる今だからこそです。ミリシタを拠点に再起を図り、逆境を乗り越えた先にこそミリオンライブ！の真の未来が見えるはずです。だって、「765プロの未来はここにある」んですから。
最近、サービス終了したソシャゲと、そのユーザーの反応を見ていて思う所があったので書いてみる。
一言で言うと「会社として続けていくことが難しくなったから」ということになる。
で、9割方はお金の問題になる。売上がでなければ当然サービスを維持できないので終了する。
開発チームの人員が確保出来なくなったとか細かい事情は色々考えられるけど、結局どれも根本はお金の問題だったりする。（お金があれば人は離れないし、確保もできる）
逆に言えば、例えばApp Storeのセールスランキングトップ10に居るようなアプリはハッキリ言って突然サービス終了するなんてことはあり得ない。
ソシャゲの売上はざっくり言うとDAU（アクティブユーザー数） × ARPU（ユーザー一人あたりの平均課金額）で求められるので、どちらかを上げれば売上も上がると言える。
DAUを増やして売上を上げようという算段のモデル。要は薄利多売。
有名所で言えばモンスト、FGOなどが挙げられる（FGOは一人あたりの課金額もすごそうだけど…）
ARPUを増やして売上を上げようという算段のモデル。言い方は悪いけど、一部の廃課金者にごっそり貢がせようという形。
有名（と言えるのかよくわからないけど売り上げランキング上位の）例としては戦国炎舞 -KIZNA-など。
ここ数年はアプリの数も増えてソシャゲ市場は完全にレッドオーシャンの状態なので、特にユーザー数の獲得が難しいオリジナルの新規タイトルはこのモデルに寄りがち。
売れなかったアプリはこのどちらのモデルにも寄せられなかったということになる。
高DAUモデルの場合はちゃんと万人受けするものを作れていなかったとか、広告宣伝が足りてなかったとか、そもそもターゲティングを読み間違えていたか。
高ARPUモデルの場合は、しっかりとコアユーザーに課金をさせるためのゲームデザインができていなかったということになる。
Twitterなんて近しい人間をフォローするのでその中で盛り上がっているように見えるのは当たり前。
とりあえず試しに人気アプリ（FGOとか）と自分のやってるアプリでTwitter検索して、ツイートの流速とか比較してみるといいと思う。
極めつけに言うと、ソシャゲの売上はストアランキング見れば大体分かってしまうので、ランキング推移を人気アプリと比較してみるといい。（「アプリ ストアランキング」とかで検索すると推移を見れるサイトが出る）
会社の規模とかにもよると思うけど、ざっくりとした感覚で言うと、ストアランキングの「"総合"セールスランキング」で、月に一回（ガチャ更新の日など）くらい「100位以内」（ゆとりを持って見ても200位以内）に上がらないアプリは結構厳しい。
圏外の場合はハッキリ言って論外なので、いつ終了してもおかしくない。
色んな推論が飛び交ったりするけど、ランキングさえ見れば9割方は判断が付くので、変な憶測を飛ばしたりする前に、まずはランキングを見て欲しい。
これは結構見るけど、売れないから打ち切るのは至極当然の判断。
結局金かよ！とか冷たい判断、とか思うのかもしれないけど、そんな感情論ではなく世の中はお金で動いている。
当然アプリを開発するのにもお金がかかっている訳で、開発チームの人件費だったり、サーバー等の運用費だったり、広告費だったりと、恐らく皆が思っている以上のお金がかかっている。（特にネイティブアプリに移行してからは開発費用も期間も大幅に増えている）
そのお金を賄うのは会社（経営陣）な訳で、その回収が見込めなければ終了せざるを得ないのは当然。
「開発チームはまだまだ続けたかったはずだ！」なんてのも見るけど、その開発チームの給料を払うのも会社な訳で、極論を言えば売上が出なければ開発チームの人間に給料を払うこともできなくなる。
結局売上が無ければ開発チームも満足に開発できる環境は得られないし、最終的には誰も幸せにならない未来しか残らない。
あと、これは個人的な意見だけど、ゲームが好きとは言え、売上の上がらないゲームの開発をし続けるのは正直モチベーション的にも厳しい所があるし、
それを何も知らない外部から勝手な憶測で「まだやりたかったはずだ」とか言われたり、誰かを悪者にされたりしてもあまり気持ちの良いものではない。
サービス終了を悲しむのはいいけど、変な妄想で周りを攻撃したり、自分の勝手なエゴを押し付けるのは辞めておいたほうが良い。
そんな事をしてもサービスは復活しないし、作り手も嬉しくはない。
サービス終了の判断まで行くという事は既に結構厳しい状況という事なので、現実的には難しい。
例えば仮に有志100人が集まって毎月皆でン十万円課金してくれるとかなら続けられるかもしれないけど、そんな事をしても運営もユーザーも疲弊していくだけ。
現状で売上が上がっていないということは、無理をして解決しようとしたって絶対に破綻する。
売上を上げられなかった開発チーム（具体的に言えばターゲティングとそれに合わせた課金モデルをうまく作れなかったプロデューサー、ディレクター、プランナーなどの責任が重い）と、
適切な判断ができずにGOサインを出してしまった経営陣が悪い。
身も蓋もないことを言ってしまえば、サービス終了しそうなゲームをプレイしないこと。（ランキング圏外のゲームをプレイしないこと）
とは言え、そうやってニッチなゲームに誰も課金しなくなって、人気ゲームだけに一極集中してしまうのは少し寂しいものがある。
大人な心をもって、無理のない課金でゲームを楽しんでくれれば作り手としては嬉しい。
ソシャゲ業界に居た人間。いくつかのソシャゲのサービス終了を看取ってきた。
ソシャゲに関わるのに疲れて、今はWeb系の会社でまったり仕事している。
なんか結構反響があったので、改めてこの記事で言いたかったことの整理と、いくつか多く見られたコメントへの返信も書いておく。
特に言いたかったのは3つ目で、別にソシャゲの話でなくてもこういう事は多いけど、ちょっとむしゃくしゃしたので書いた。
当たり前の話じゃん
全くもって本当にその通り。こんなことをわざわざ書いた理由としては前述の通りで、まあ単に個人的なストレス発散が目的。
増田なんか読んでるような人間は当たり前に思うかもしれないけど、実際当たり前な事を理解してない人間は多い。
そのパターンは自分も直面したことは無いので知らない。自分もソシャゲ業界全てを知ってる訳じゃないので免責も込めて9割と言ったけど、まあ99%くらいはお金の問題に帰結すると思う。
拡散性ミリオンアーサーも乖離性に移行する以前の問題として「運営の体力が厳しかったから」って事らしいし。
https://app.famitsu.com/20141226_479007/
FGOは割と特殊な例なので今回の例としては相応しくなかったなと思うけど、DAUが多いのは確か。（と言ってもモンストとかツムツムレベルでは無いが）
実態としてはDAUが結構多くてARPUも高めって感じだと思うので線引が微妙な所。
個人的にもFateは一部の古参ファンが金をめちゃくちゃ注ぎ込むコンテンツという認識だったので、ここまでユーザーが増えたのには驚いてる。
ちなみに今回はシンプルで分かりやすいようにDAUとARPUを挙げたが、売上の指標としては他にPUR（課金ユーザー割合）、ARPPU（課金ユーザー一人辺りの平均課金額）とかもある。
この辺の話は割とよく出てくるので、興味があったら調べてみると良い。
終了後にコンテンツを残してほしい
この声も結構多くて、実際最近では終了後にも楽しめるようにコンテンツを残してくれるソシャゲも増えてきている。（ポプストとかあんガルとか）
その取り組み自体は素晴らしい事だと思うけど、実際これをやろうと思うと思った以上に手間が掛かる。それはつまりお金（人件費）が掛かる。
結構皆簡単にやって欲しいとか言うけど、アプリを簡単にオフライン化できることなんてまず無くて、結構根本から作り直さないと難しかったりする。
それにオフライン化してリリースしたからと言ってそれで終わりにもできなくて、リリースする以上ある程度はサポートやバグ修正などもしなければいけないので、それに対応する運用体制が必要になってくる。
設定資料集みたいな物を作るとしてもデータをまとめたり編集作業したりでそれなりに工数が掛かるし、印刷費なども掛かる。
データのアーカイブの公開も、主に外注の権利関係の問題などがあったりして、簡単にすぐ出せるようなものでもない。
だから、あまり期待を膨らませられても困るし、サービス終了を検討するような状況の所に身銭を切らせてやらせるのは酷だという事は理解して欲しい。
これも数年前から言われ続けてるけど、自分は潰れること無く続いていくんじゃないかなと思ってる。
最近は任天堂まで参入してきたし、去年はアズールレーンみたいなオリジナルでのメガヒットタイトルが久々に出てきた。
あと、Appleがガチャ確率表記を義務付けた話も、裏を返せばAppleはガチャモデルを容認したとも取れる。
今更大規模な法規制が起きる事も考えにくい（誰も得しない）し、仮にソシャゲを規制してもコンシューマに金が流れるとは思わない。
ただ、「日本の」ソシャゲ業界は厳しい状況になってきてるだろうなと思う。
アズールレーンの台頭から既に騒がれつつはあるけど、中国の持つ資金力に加えて、日本でも売れるコンテンツ力が付くと、正直勝ち目は無いんじゃないだろうか。
もうソシャゲ業界でも「金がなくてもワンチャン成り上がれる」みたいな夢のある話は無くなってて、体力（資金力、開発力）のある企業がしっかり丁寧に作らないと勝負にならない。
それができる企業というのはもう本当に少ない。悔しいけど、多分Cygamesくらいしかないかも。
正確に言うなら、ソシャゲビジネス自体は無くなることは無いけど、日本のソシャゲ業界は衰退していくのかもしれない。（あるいは既に衰退し始めている）
Y!知恵袋が少し前まで、スマホ版ではWebではBAしか見せず、それ以外の回答はアプリで見ろとアプリをゴリ押ししてたのは記憶に新しいだろう。幸いにも今はWebで全部見れるようになった
なぜスマホサイトはアプリをゴリ押ししたがるのだろうか。Webで完結するサイトをわざわざネイティブアプリを介して見させる意味がわからない。(*よく利用する*人なら通知がくる、手軽に投稿できるなどネイティブアプリのメリットはあるが)
もしPCで知恵袋を見ててChiebukuroViewer.exeをインストールして続きを見るとか言われたら(ﾟДﾟ)ﾊｧ?となるだろう。
増田のようなスタンスを否定する謂れは一切無いし、むしろそういうライトなファンを如何に獲得するかがコンテンツの発展につながることは承知の上で、ではなんでゲームもふれて欲しいという熱心なファンが多いのかというと、やっぱり情報量が段違いなんですね
で、このアイドルゲームのスタンスとしては、アイドルはアイドルであるまえに人間だと
それを表すための膨大で多角的なテキストがゲームには詰まってるのです
しかも最近はソシャゲベースで展開していますから、時間軸という概念を獲得しまして、もはや容易には伝えきれない量になっていて、もう自分でやって自分で発掘してもらうしか無いのです
正直申し訳ない気はしないでもないです
ただ、メディアミックス展開や二次創作だけでなく、大本のゲームを、更に言うなら最新のネイティブアプリだけでなくブラウザゲームのほうも触れて欲しいというのはそういう事情があるのです
http://anond.hatelabo.jp/20160522003506
ども。
この辺りの一連の発言（特に後二者）を見るに、多分React以前の前提がいろいろ違っています。単にJSやNodeやNPMやSPAやWeb APIといったフロントエンドの世界観に対して、興味がないどころか漠然とした不信があり、サーバ側でヘビーにHTMLを作って吐くスタイルを守り続けたい人なのだ、という印象を受けます。
ユーザの各操作毎にサーバ側で外見のHTMLを組み立て直して配信するという旧来のWebの方が特殊な世界です。それこそAndroid/iOS開発やデスクトップアプリで、そんなやり方はしません。UI関連のことはクライアントで完結し、メニュー遷移程度で通信したりしない。サーバは静的データの配信とDB操作に専念する。SPAとは、やっとブラウザがそういうネイティブアプリのレベルに追いつき、同じやり方ができるようになった、というだけの話です。
とりあえずReactは、まずその前提を受け入れてから使うものです。その前提なしに使えないこともないですが、メリットは活きないでしょう。その時点で既に「よくわかんないんですけどSQLiが…」と漠然とした不安を表出されるようだと、道のりが遠いな…と。もちろん「私の周囲にそういう案件はない」ということなら、それで構いません。
具体例を出せとのことだったので。私の場合は変幻する数百のテキストフィールドとリアルタイム集計が登場する勤務予定表的なものを、1人でjQueryのSPAで作った際、数百行のHTMLと数千行のJSがスパゲティ化し「こりゃいかん、メンテ不能になりそう」と思ったのが、具体的にReactを覚えるきっかけでした。実際非常にうまく行き、10年後の誰かにも「この時代のベスト」として自信を持って残せます。JSXの局所的な見た目の問題など、アプリ全体の構造の見通しやすさと比べたら些細な話です。Angularなら出来たかもしれませんが、サーバ側処理とページ遷移を多用して書くことに関しては検討すらしていません（私の知っているどんなフレームワークを使ってもユーザビリティと、見通しの良いコードを保つことは無理だったと思います）。ビデオ再生や大きな画像処理を伴うアプリでもReactを使っており、そちらではページ遷移などもってのほかです。
「変な独自拡張を入れてまでJSを使い続ける理由がわからん」についても、まるでJSが生来の嫌われ者で、クライアント側でもPythonやRubyを使いたい人が多くいるかのような書き方のように思えるのですが。実際そんなことはないですよね？ たぶんES6は人々から積極的に愛されています。現状、クライアント側にPythonが進出するのではなく、逆にデスクトップやモバイルやサーバ側にどんどんJavaScriptが進出する流れが起きています。
速度に関しては、Reactはやってる内容の割に十分速くて実用的だよね（mustache使うよりは速いよね）ということであり、賢い人が手間暇かけて最適化した生DOM操作より遅いのは言うまでもありません。また、JSXはシンタックスハイライトが出来ないとかも、そうとう昔の話です。今は普通のJS技術者が普通に触れる程度の成熟はしています（枯れたとまでは言いませんが）。
