2022年3月31日木曜日

「春の湊に」を配信しました(東方VGS)

東方VGSで「東方星蓮船 ~ Undefined Fantastic Object.」の1面のテーマ「春の湊に」を配信しました。(Pull Request

辞書を調べてみた所「春の湊」とは「春の行きつくところ。春の果て。はるのとまり。」という意味らしいですが、同梱のストーリーに土はぬかるみ、氷で覆われた大地から有象無象が目覚めるとあるので、ストーリー上の季節感としてはガッツリ春先ですね。

ニコニコ大百科によると「春の湊とは春の終わりのこと。春を船に喩えた表現。星蓮船本編の季節はまだ残雪が残る春先なので湊を港とかけている?」とのこと。ちなみ、「港」と「湊」の違いは、「港」は船が通る水路、「湊」は船が停泊する場所とのことです。英語で言えば「港」は Port、「湊」は Harbor ですね。

星蓮船のストーリーからシンプルに「春先に謎の船(UFO)のハーバーを探しに行くよ!」という感じではないでしょうかw

第16回東方Project人気投票の結果によると、544曲中41位ということで、かなり人気が高い曲のようです。

原作者様コメント(東方星蓮船 Music Roomより)

1面のテーマです。

軽快で気持ちの良い曲で始めたかったのでこんな感じに。

やっぱさ、シューティングって明るい方がよくない?

と、その時の気分で趣味嗜好が変わる人間が言ってもねぇ。

曲は爽やかです。窓から飛び出したくなるくらい。

なるほど。

原作者様コメントは発売当時に読んだものの、もう13年前の事なので内容をほぼ忘れてました。ただ、何故か「窓から飛び出したくなる」という件だけは覚えてました。デフェネストレーション?最近はもう聞かない(幻想入りした?)ネットスラングですね。

だいたい全ての作業が終わってから、曲に関するコンテキスト情報を調べて、「この曲はそういう曲なのか〜」と勝手に愉しむのが最近のマイブームです。

以下、曲自体の簡単な解析内容を記します。

【構成 & テンポ】

  • 5パート構成: 第1提示→第2提示→第1展開→第2展開→コーダ
  • テンポ: 155
  • 主調: 嬰ヘ短調

【第1パート】(第1提示)& 【第5パート】(コーダ)

これは、イ長調...ではなく嬰ヘ短調ですね。

ピアノがメインのパートですが、第5パート(コーダ)では第4パートのメロディ(リード)のカデンツァ(下図)と一緒に演奏されます。

【第2パート】(第2提示)

変ホ短調へ3半音下転調(短3度下転調)をして、ピアノで第2モチーフを提示してリードで繰り返します。

【第3パート】(第1展開)

ピアノで第1モチーフを展開したと思しきモチーフ(下図)を展開しながら4回演奏します。

第3展開でセオリー通り3半音上(嬰ヘ短調)の主調へ戻り、第4展開でリードに切り替えて第4パートのメロディーへ繋ぐ形になります。

【第4パート】(第2展開・再現)

主調(嬰ヘ短調)で第2モチーフを展開したと思しきモチーフ(下図)を2回繰り返します。

【考察】

ソナタ形式は概ね、

  1. 主調で第1主題を提示
  2. 転調して第2主題を提示
  3. 主題を展開(展開部)
  4. 主調に戻って第1主題と第2主題(※第2主題に限り同主調も可)を再現(再現部)
  5. 主調または同主調でコーダ
という構成になっています。

「春の湊に」の構成はソナタ形式を意識したであろう形になっていることが分かります。

つまり、この曲は「ピアノソナタの二次創作」という結論に至りました。

...というのが私のアナリーゼ結果ですが、合っているかは分かりません ^^;

2022年3月28日月曜日

Cubaseをなるべく安く買いたい

耳コピ作業に主にLogic Proを使ってます。

一番気に入っているのは...値段です。

AppStore(Mac)で約2万円で買える買い切りソフトですが、DAWとしては破格で、しかもアップグレードも無料です。(他のソフトだとバージョンアップの都度ライセンスを書い直す必要があります)

Logic Pro の VariSpeed という機能を使えばピッチ(音程)を変えずに -50% ~ 100% の範囲でテンポを変えることができるので、高速なアルペジオのコピーなどが割と簡単にできるようになります。あと、メロディーラインをコピーする時はリアルタイムに演奏して採譜するのですが、アップテンポな曲だと技術不足でモタついてしまうので、テンポを落として弾きます。

VariSpeed は標準だと表示されてませんが、ディスプレイ(テンポなどが表示されている部分)のプルダウンをクリックして「コントロールバーとディスプレイをカスタマイズ...」で「VariSpeed」をチェックすることで使えるようになります。(下図の「速度のみ」という部分)

同じような機能が Cubase にもあるらしく、以前から気になっていたのですが、Cubaseはちょっと高いです... 調べてみたところ、ダウンロード版は6万円以上して、しかもメジャーバージョンアップ時のアップグレードも有料です。

ついでに、以前のバージョンだと専用のUSB(ドングル)を挿し込まないと起動できないという不便な仕様だったようです。(流石に最新バージョンだとそれは廃止されたようですが)

サウンドハウスだともっと安く(5万円台で)買えますが、物理パッケージです...

廉価版(Artist)ならダウンロードでも3万円台で手頃感があり、一応Artist以上なら目的の機能はあるらしいので、買うならArtistかな...と思っていたのですが、Proのダウンロード販売には「競合製品からの乗り換えキャンペーン」なるものがあるらしく、それなら4万円台で買えるようです。

お値段まとめ(2022.03.28時点)

  • Cubase 12 Pro パッケージ販売: ¥57,800 (サウンドハウス)
  • Cubase 12 Pro ダウンロード販売(通常)¥62,700
  • Cubase 12 Pro ダウンロード販売(乗換)¥41,800
  • Cubase 12 Artist ダウンロード販売: ¥35,200
  • Cubase 12 Artist パッケージ販売: ¥30,222

買ってから「Proの機能が必要だった」というようなケースが発生すると困るので、その時の保険として +¥6,600 なら支払っても良いかもしれません。

ちなみに、乗り換え対象のDAWはだいたい有名所は入っているようで、もちろんLogicも入ってました。


...ただ、やっぱり高いので暫くはLogic Proで我慢しておきます。

アプリの年間利益が20万円を超えたら経費で買おう。

2022年3月24日木曜日

広告削除機能の検討(東方VGS)

東方VGSのレビューで「アプリ内課金で広告削除できるようにしてほしい」というご要望を頂いてます。

実はリリース当初からどうしようか悩んでました。

まず、東方VGSには3種類の広告があります。

  1. 楽曲アンロック(リワード広告)
  2. 画面上部(バナー広告)
  3. シャッフル再生(インタースティシャル広告 ※動画広告は排除)

現時点(約3ヶ月の運用)で収益性が一番良いのは 1 です。

収益の比率としては 1:2:3 = 10:3:3 ぐらいです。

例えば、1の売上が1万円なら 2 と 3 はそれぞれ 3千円(計6千円)です。

そして、長期的な運用で考えると重要なのは 2 と 3 だと想定してます。

収益性が低くても 2 と 3 が重要な理由は、赤字運営を回避するためです。

仮に新曲の追加をしない状態が続くと徐々に1の収益性は低下して、2と3は残存ユーザーが居る限り一定の収益が得られ、それにより赤字を回避できるという想定ですが、全ての広告を削除してしまうと(一時的な売上は高くなりますが)将来的に単年赤字になるリスクが高くなってしまいます。

悩んだ末、「1 と 2&3 を別々の課金で削除できるようにして、多くのユーザーさんが望んでいる 1 はリーズナブル価格($2.99)、2・3 は少し割高($9.99)で提供してみてはどうか?」という奇策を思いついたので、現在実装中です。

開発中の図

全部の広告を削除する課金だと、試算してみたところ1,000円以上の価格設定にしなければならないので、大半のユーザーさんが欲する機能を可能な限り割安で提供することが出来るこの形がベストかもと思っているところです。

とりあえず、iOSは実装できたので審査提出してみました。

Androidの課金周りの実装は結構面倒なので苦戦中。(実装自体はできているのですが、購入フローが何故か動かない...)

ただし、Androidで有料販売する場合、GooglePlay上で住所を晒さないといけないルールなので、もしかするとこの機能はiOSのみになってしまうかもしれません。(まだ、どうすべきか悩み中)

2022年3月9日水曜日

Apple Music連携(東方VGS)

先日の東方VGSのアプデで、Apple Music の原曲とリンクする対応をしました。

Settingsで「Apple Music で原曲をチェック」をタップすると、ミュージックアプリが起動して上海アリス幻樂団様のアーティストページが起動する形になります。

 

この意図はシンプルに「東方Project(原曲)の布教」です。

なので、今後は Apple Music を積極的にプッシュしていきます。

現時点ではSettingsからのリンクだけですが、今後のアップデートで曲単位で原曲(Apple Music)とリンクできるようにしようと検討中です。

なお、東方Projectの原曲はApple Musicだけでなく他のサブスクリプションサービスでも配信されていますが、東方VGSでは Apple Music だけを推していく方針です。

その理由は2つあります。

第1の理由はプロモーションのチャンスがある(かも)と思っているためです。

東方VGS で Apple Music をプッシュしておけば、あわよくば Apple の方からフューチャーしてくれるかも?という淡い期待を抱いています。

期待値としてはそんなに高くはないですが、東方VGSは個人運営のアプリなので、大手企業のようにお金を積んで大々的に広告を打ち出す体力はありません。なので、プロモーションは死活問題だから、確度が低くてもお金を掛けずにできる事なら何でもやります。(ん?)

第2の理由は上海アリス幻樂団様の実入りが他サービスをプッシュするよりも良くなる可能性が高いと考えられる為です。

Apple Music や Spotify などのサブスクリプション型の音楽配信サービスは、売上の一部を権利者(コンテンツホルダー)に実績値で按分して分配する仕組みになっています。

Apple Music の場合、サブスクリプション収益の52%を再生回数で按分して権利者に分配しています。Apple Music の現在の会員数は不明ですが、2019年時点の報告では約6,000万人なので、月間の売上はおよそ600億円、その52%(およそ312億円)を約6000万曲(※2019年時点の配信楽曲数)へ分配するので、1曲あたりの分配額は平均520円/月ぐらいだと考えられます。そして「1再生平均1円ぐらい」とも言われているので、1曲あたり平均520回/月ぐらい再生されているものと思われます。(参考

なので、1アルバム平均16曲で28本のアルバム(全448曲)をリリースしているアーティスト(東方Projectがだいたいそれぐらいの規模感)の場合、平均23万2,960円/月ぐらいの収益を得られる計算になります。(もちろん、人気などによって大きく上下する筈です)

ただし、Apple Music以外はアーティストへの分配金額が低いという情報があります。

ソース: https://rockinon.com/blog/nakamura/201465

また各ストリーミングが曲を1回ストリームしてアーティストに支払う金額と、$1000払われるまでのストリーム回数(全て推定)
Tidal 0.12ドル、8,333回
Apple Music 0.01ドル、100,000回
Amazon Music 0.004ドル、250,000回
Spotify 0.0033ドル、303,030回
YouTube Music 0.002ドル、500,000回

Apple Music よりも Spotify の方が有料会員数が多いにも関わらず、アーティストへの還元率が低いらしいことが分かります。

これは別に Spotify がアーティストから搾取している訳ではなく、仕組み上やむを得ずそうなっているものと考えられます。

Spotfiyの場合、売上の15%〜30%(平均22.5%ぐらい?)がApple税/Google税で持っていかれるので、Apple Musicと同程度の収益配分(52%)にしようとすると、ネット売上(Apple税/Google税を差し引いた金額)の約67.1%をアーティス還元に回すことになり、売上に対する粗利益率は25.5%(対するAppleはiOSでは48%)で、そこからランニングコスト等を差し引くとかなりカツカツの経営になる筈です。

Android版の Apple Music でも Spotify と同じようなことが言えますが、課金ユーザーは圧倒的に iOS の方が多く、加えて経営体力もある Apple なら、それで経営がカツカツになることはまず無いと思われます。

Spotify にはアプリ内課金ではなく独自決済もあるので、ユーザーが積極的に独自決済を利用すれば、Spotifyとアーティストの実入りが多少良くなると考えられますが、独自決済であっても手数料は当然タダではありません。決済システムやクレジットカード手数料は規模がデカイほど有利で、世界最大級のAppStoreの決済システムをタダ同然で使えるApple Musicが有利であることは変わらないと思います。(何より独自決済よりもアプリ内決済の方が利用者にとって圧倒的に便利なので、値段が同じなら普通にアプリ内決済を選択する人が大半だと思われます)

要するに、構造上「Apple Musicの分配金が高くなって当然」ということです。

プラットフォーマーと同じ土俵で商売するのは分が悪すぎる...

「Spotifyを応援したい人」はSpotifyを使うのがオススメですが、「アーティストを応援したい人」はApple Musicを使うのがオススメということになるので、東方VGSは必然的に後者ということになります。

2022年1月18日火曜日

iOS版 東方BGM on VGSも配信再開しました

先日配信再開したAndroid版に続き、iOS版の東方BGM on VGSもAppStoreで配信再開しました。

https://apps.apple.com/jp/app/id680248037

実は数日前から既に旧バージョンをそのまま復活させていたのですが、本日からAndroid版と同等のアップデートがされました。

久々のApple審査対応は中々楽しかったです。(Appleによるバイナリリジェクトが1回、メタデータリジェクトが1回、審査待ちの間の自己審査によるセルフリジェクトが7回ぐらい)

機能的には、Android版とほぼ同じですが、モダンUIの見た目が少し異なります。

Android版のモダンUIはマテリアルデザイン(にしたつもり)で作りましたが、iOS版の方は私の個人的な趣向でフラットデザイン & ダークモード固定にしてみました。

デザイン方面はサッパリなので、マテリアル or フラットのどっちが良いのか実のところよく分からないです。(フラットが好きなのは作りやすいため)

しばらくの間(1ヶ月ぐらい?)、色々と手が回らないと思いますが、落ち着いたら月1回程度でも曲追加できたら良いなと思っています。

半分わざと、私自身のお尻に火をつけるため「曲追加をしないと収益が上げにくいマネタリング構造」にしてみたので、今度こそは続けられる...筈。

なお、旧東方VGSの頃はApple審査に結構時間が掛かった関係で、Androidは即アップデート、iOSはある程度まとまってから月1ペースぐらいでアップデートという(管理が面倒な)リリーススケジュールで運営してましたが、最近は審査期間がAndroidもiOSもあまり変わらないので、今後アップデートはAndroid/iOSほぼほぼ同時になる予定です。

基本、審査が通ったら即リリースするので、若干のラグはあるかもしれませんが。


以下、技術寄りのネタです。


Androidでリリース後、(嬉しいことに)旧UIを懐かしむ声が多かったので、旧UIを再現したRETRO UIというものを(かなり難産しながら)作ってみました。もちろん、iOS版でも RETRO UI は実装済みです。

VGSは元から「半エミュレーション」みたいな技術で作っていたので、単一のFragmentViewで簡単に組み込むことが出来ます。

iOS版もAndroid版と同様、GPLv3ライセンスのOSSとしてソースコードを公開しているので、気になる方は覗いてみてください。

https://github.com/suzukiplan/tohovgs4-ios

なお、Android版の開発言語はKotlinですが、iOS版はSwiftではなくObjective-cです。

新規にスマホアプリを開発するならDart(Flutter)、ゲーム系ならC#(というかUnity)というのが今後のトレンドだと思われるので、Swiftを習得する機会を逸してしまった感があります。(Flutterについてはまだメインストリームというよりは比較的攻めているデベロッパしか使ってないかもしれませんが)

それなら東方VGSも今回はDartで作れば良かった訳ですが、Android版を復活させた時点ではiOS版の復活は未定で、最低限 iOS Developer Program の年会費を支払える程度の収益が得られそうなら復活させようと考えていたので、Dart より手早く作れる Kotlin で開発した経緯があります。

GitHubの方を見て頂けると東方BGM on VGSの言語構成比率を見ることができますが、実装の約9割が C/C++ で、OSネイティブ実装(Kotlin, Objective-c)のコード量は大したことがないから、それなら色々と面倒なP/F共通化をするよりも小回りが効くネイティブ言語(Kotlin, Swift)の方がメンテし易いかも...という見立てもあります。(Flutterではないですが実際こういう話しもあるらしいですし)

安定運用フェーズになれば基本的にネイティブコードは殆ど触らず、songlist.jsonの更新とMMLファイルの追加だけになるように設計しているので、ネイティブコードを触る必要があるのはOSのアップデートや依存ライブラリのアップデートなどへの追従ぐらいになる筈で、それならOSネイティブ言語で開発しておいた方がメンテナンスが楽になるのではないかという見立てもあります。

また、現状曲の追加にはアプリのアップデートが必要な形になってますが、曲データの配信をサーバで行い、アプリのアップデート頻度を下げる方策についても並行して検討中です。


以下、現在検討中のサーバサイド(動的な曲配信)についての技術ネタです。


アプリのアプデ作業も中々手間が掛かるので、サーバで曲データを配信するのが良いのは当然です。

そこで、私が tohovgs-cli (GitHub) で曲データ追加の Pull Request をマージすれば、アプリに追加した曲が配信されるような形のコンテンツ配信システムを現在検討中です。

AWSとかを使えばサーバ系が専門外の私でも、そういったサーバの構築自体は簡単にできます。

ただし、下手に構築してしまうとサーバコストが発生してしまい、それで赤字になるとまた続けられなくなってしまいます。変動費が増える分には売上でペイできるので問題無いかもしれませんが、固定費は極限まで0円に漸近させなければなりません。

今のアプリの構造上、tohovgs-cli の GitHub Pages で songlist.json と MML ファイルだけ配信できれば(つまり、静的ホスティングだけできれば)動的な曲配信に対応出来るので、小規模な内は GitHub Pages でサーバ配信がノーコスト対応可能かも...と思ったのですが、どうやらそういった使い方はNGらしいです。

https://docs.github.com/ja/pages/getting-started-with-github-pages/about-github-pages#prohibited-uses

Prohibited uses

GitHub Pages is not intended for or allowed to be used as a free web hosting service to run your online business, e-commerce site, or any other website that is primarily directed at either facilitating commercial transactions or providing commercial software as a service (SaaS). 

GitHub Pagesは、オンラインビジネス、eコマースサイト、その他商取引の促進や商用ソフトウェア(SaaS)の提供を主目的とするウェブサイトを運営するための無料ウェブホスティングサービスとして使用することは意図されていませんし、許可もされていません。 

なので、動的な曲配信という用途で GitHub Pages を使うことはできません。

その他の方法としてはFirebase Hosting を使う方法もありますが、Sparkプラン(無料)だと 10GB/月 が上限(GitHub Pages の 1/10)で、Blazeプラン(有料)だと10GB/月を超えると 1GB あたり $0.15 らしいです。

AWS S3 なら50TBまでは1GBあたり$0.023なので、一見するとAWSの方がお得に見えますが、CDN(CloudFront)を使う場合、クライアントの地域によって値段が変わり、日本なら 1GB あたり$0.114掛かるので合計すると $0.137。最初の10GBまで無料という点を勘案すると、Firebase Hosting の方がお得かもしれません。

GCPもStorage+CDNならAWSよりちょっと安いぐらい。

東方VGSはそもそもデータサイズが小さいから、恐らく無料枠(10GB)だけで余裕で捌けそうなので、Firebase Hostingが一番コスパが良いだろうと思っているところです。

また、Firebase HostingならダイレクトにGitHub actionsと統合できる点が強いので、私のユースケース的にもやはりFirebase Hostingが有力かなと。

2022年1月5日水曜日

東方BGM on VGSを再公開しました(とりあえずAndroidのみ)

暫くアップデートを怠っており、最新のプログラムポリシーに追従できていなかったためGooglePlayから削除されてしまったAndroid版東方BGM on VGS(東方VGS)を色々とアップデートというか、年末休暇でプログラム部分を全部作り直して配信再開しました。

https://play.google.com/store/apps/details?id=com.suzukiplan.TOHOVGS

また、今回のバージョンからAndroid版もOSS化しました。

https://suzukiplan.github.io/tohovgs4-android/

OSSライセンスはGPLv3です(※ライセンスについては後で MIT に変更するかもしれません)。

assets に MML ファイルをぶち込み、songlist.json を書くだけで、驚くほど簡単に同じようなアプリを作ることができます。

VGS音源を使って同じような音楽配信アプリを作りたい会社などありましたら、ライセンスの範囲内でご自由にどうぞ。

最後に東方VGSのアップデートをしたのが2016年2月なので、もう6年もアップデートしていなかったんですね...その間に色々と足回りの準備をしていたこともあり、色々と遅くてスミマセン。

iOSのDeveloper Accountの維持費を支払うことをやめてiOS版が削除され、その後(2018年頃)アップデートをサボり続けていた結果Android版も削除されて現在(2022年1月)に至るので、Android版は恐らく4年ぶりぐらいの復活ではないかと推測しています。

2023年(10周年)より前に復活できて良かったです。

できれば10周年前にiOS版も復活させたいところ...

今回のアップデートでは、UIをマテリアルデザインっぽい凡庸で使いやすいものに変更しつつ、広告を追加してマネタイズするようにしています。

また、Android 8.0以降でバックグラウンド再生を長時間しているとOSから止められる問題についても対策しました。

新曲の追加はまだありませんが、追々追加していくつもりです。

最低限iOSのDeveloper Account維持費(年間1万2,000円ほど)が支払える程度のプロフィットを得ることができそうであれば、iOS版についても同じような形で再開しようと思っています(多分、遅くともGWぐらいまでには判断できる筈)。

それでは、よろしくお願いします。

(以下、駄文です)

折角久しぶりに東方VGSのネタを書くことができたので、軽くこれまでの経緯を振り返ってみます。

東方VGSを最初にリリースした2013年当時、精神的にヤバイ状態になって休職したりといったイベントがあり、その間(ゴールデンウィーク頃)に作ったものです。

元ネタは昔マイコンBASICマガジン(ベーマガ)という雑誌のMMLで書かれた楽曲投稿のコーナーで、それをVGSの波形メモリ音源のMMLでやってみた感じのものです(最初は東方ではなくヨハン・セバスティアン・バッハの曲でやっていたのですが、残念ながらそっちの方はまだ復活できていません)

ゲーム音楽というのは一般的に権利関係がかなり複雑であることに加え、そもそもマネタイズを一切していなかったので企業やJASRACに相手にされないだろうということで、東方Projectなら二次創作ガイドラインの範囲内でセーフだから東方Projectでやってみた...という経緯があります。

当然ですが、東方Projectが好きだという大前提もあります。

ただし、私は音楽に関しては雑食で、クラシックや映画音楽も東方と同じぐらい好きだし、ラブライブとかもμ’sやAquosに関係なく好きです(静岡出身だから若干Aquosを贔屓している程度)。

ラブライブ(スクフェス)は東方VGSとほぼ同じ時期にリリースされたこともあり、その頃から知っているのですが、ラブライブVGSは(やりたいけど)多分やれません。

そんな東方VGSですが、リリース後からジワジワとですが想定以上に好感触で、Android版は最終的にレビュー数6775で平均評価 4.8 / 5.0 という、かなり凄い評価をいただきました。

iOSでは「神々が恋した幻想郷」と「芥川龍之介の河童」を追加した時のアップデートが一番好評で、100件以上のレビューがついて平均 5.0(パーフェクト)だった時はビックリしました。

もちろん、サクラ無しです。

100件以上のレビューがついて平均 5.0 なんて普通はサクラを使わない限りあり得ない評価ですが、サクラを雇おうにも当時マネタイズを一切していなかったので原資が無いですし、そもそも、サクラを使ってレビューを引き上げるメリットも分かりません。

東方VGSでこれだけ多くの人に評価を頂きながら一切マネタイズをしなかった(後述しますがそもそも「できない」と思っていた)のは、当初は精神安定剤のような効果があったので、それで十分かなと思っていたためです。

しかし、その後精神も安定して当時勤めていた会社を辞め、ドワンゴに転職したりして忙しくなり、そうなると今度はマネタイズしていないことが致命傷になって、結果的に続きませんでした。

精神が安定している状態では、精神安定剤は毒にしかなりません。

私はあまりお金を使わない方なのでガッツリ稼ぐ必要もないのですが、最低限iOS Developer Accountの維持費(年間1万2,000円)程度の収益をあげていなかったことが敗因です。

という訳で、今度はちゃんとマネタイズします。

ただし、二次創作ガイドラインの規定で有料アプリはNGなので、マネタイズといっても広告だけです。

参考: https://touhou-project.news/guideline/

ブラウザ上で動くゲームアプリ、スマートフォンでのゲームアプリは無料のもののみとします。アプリ内への広告の導入、広告機能の解除のための課金機能はOKです。

以前、ZUNさんがWeb媒体か何かのインタビュー記事で、「無料はOK、有料はNG」ということを仰られていたので、少なくとも「有料はNG」という点は分かっていたものの、果たして広告を載せて良いのか、私には判断できませんでした。

つまり、正確に言えばマネタイズを「しなかった」のではなく「出来なかった」訳ですが、今はちゃんとガイドラインとして「広告はOK」と明文化されている点が大きいです。

そこで、大きく分類すると次の3種類の広告を導入しました。

  1. リワード広告(楽曲のアンロック時にタイトル単位で)
  2. バナー広告(アプリ上部に常時表示)
  3. インタースティシャル広告(シャッフル再生リスト作成時)

ハイパーカジュアルのようなLTV(Life Time Value≒アンインストされるまでの期間)が短いアプリの場合、広告解除の課金も重要ですが、東方VGSは他のアプリよりもLTVが長いので、広告解除の課金とはあまり相性が良くありません。

LTVが長い場合、単発の広告解除ではなくサブスクリプションとかにせざるを得ないのですが、サブスクリプションだと「有料販売」に該当するのでガイドライン的にNGになると私は解釈しています。

以前一度、バナー広告を実装したバージョンをAndroidで(本家アプリとは別アプリとして)試験的にリリースしたことがあるのですが、100万DLされているような大御所アプリと違ってニッチ狙いのアプリ(本家でもAndroid+iOS合計して30万DLぐらい)だから、バナーだけだと収益性の面で全然足りなかったので、今回は広告のバリエーションを少し工夫してみました。

一番の要はリワード広告だと思っています。

収益性の状況次第では緩和すること(例えばリワード広告のみに絞るなど)もあり得るかもしれません。

追加楽曲はデフォルトでロックされた状態になっていて、これにより、曲を追加したら追加に掛かった労力に対する十分な(路上ライブの投げ銭程度の)対価が得られるんじゃないか...と淡い期待を抱いていて、それなら続けられるのではないかというのが現在の私の見立てです。

当然ですが、うっかり想定以上に儲かってしまった場合、東方Projectの事務局の方に「これ大丈夫ですか」と確認してみて按分等が必要なら対応するつもりですが、それもシッカリやろうとすると中々面倒なので「ほどほど」が良いです。

どれぐらいが「ほどほど」なのかは人それぞれですが、私の感覚ではギリギリ雑所得以内(年間20万円以内)ぐらいが一番「ほどほど」に同人活動として続けられると思っていて、それを超えたら「同人」ではなく「商人」だと思っています。

仮に、広告のeCPM(1,000回広告を出した当たりの収益)を¥1,000、DAU(1日あたりのアクティブユーザ)1人あたりの平均インプレッションを1と仮定すると、アクティブユーザ1人あたり1円の収益になるので、想定月収は次のようになります。

※Googleとの契約で細かいeCPMとかを公表することはできないので、eCPM ¥1,000というのは計算しやすくするための仮の値です

  • DAU 平均100人 = 月収3,000円
  • DAU 平均500人 = 月収1万5,000円
  • DAU 平均2,500人 = 月収7万5,000円
  • DAU 平均30,000人 = 月収90万円

悲観的な予測として、DAU 100 以下のレンジになるんじゃないかと推定していますが、それでも年間換算するとiOS Developer Programの維持費は賄えるのでセーフです。

しかし、YAU 12,000 ≒ DAU 約33 以下だと、続けることが厳しくなります。

そして、DAU 500 が同人としてほどほどに良い感じのレンジ(目標レンジ)です。

参考値で出した 2,500 という数字は、現在のAndroid版東方VGSのインストール端末数ですが、もう長いことアップデートしていないのにまだこんなにインストールしてくれている端末が残っているということは、もしかするとそれぐらいのDAUになるのかもという楽観的な期待数値です。

そして、30,000 という数字はピーク時の推定DAUで、この辺は完全にお花畑な期待値です。

※当時はFirebaseすら入れてなかったので推定値でしか分かりません...

毎日 30,000 ではなく、曲を追加(アップデート)したタイミングだけが特別多くて、平常時は 3,000 〜 5,000 前後だったのではないかと予測していて、仮に当時広告でマネタイズしてたら、月収換算すると22万円ぐらいは安定して稼いでいたんじゃないかと思われます。

ただ、流石にそれぐらいの水準で稼いでしまったら同人と呼ぶには無理があるので、事務局の方に相談して場合によっては何かしらの対応が必要になり、仮に按分が 7:3 なら月収15万4000円ぐらいという想定です。

その場合、年収換算で184万8000円ですが、そこから国民保険で月約2万(年間約24万)と所得税18万4800円(※専業の場合)が引かれるので、仮に当時専業にしていた場合の手取り年収は142万円ぐらいということになります。

アプリを作り始めた当時は、もっと人生が狂うレベルのお金が稼げるお花畑みたいな予測をしていた時期もありましたが、流石に今となってはそれは無いです。

ゴールドラッシュはもうとっくに終わっているので、見立ては悲観値あたりが現実的な着地点だろうと予測しています。

人が狂うレベルで儲かった時、お金に縁がないけど困ったこともない程度の凡庸な私が果たして狂わずに正気を保てるのかという点に興味はありますが、一度狂ったことがある経験上、狂わずに健康でいることが一番です。

2021年9月29日水曜日

User-AgentでiPadとMacの区別は不可能

例えば、あるURLにアクセスした時に、

  • iOS → AppStoreのアプリページ
  • Android → GooglePlayのアプリページ
  • PC → ランディングページ

という形で機種に応じて異なるURLにリダイレクトする場合、PHPであれば、

<?php

// 言語判定

$isJa = false;

$accept_language = explode(',', $_SERVER['HTTP_ACCEPT_LANGUAGE']);

foreach ($accept_language as $language) {

    if (preg_match('/^ja/i', $language)) {

        $isJa = true;

        break;

    }

}

// 端末判定

$ua = $_SERVER['HTTP_USER_AGENT'];

if ((strpos($ua, 'iPhone') !== false) || (strpos($ua, 'iPad') !== false)) {

    if ($isJa) {

        print '<meta http-equiv="refresh" content="0;URL=https://apps.apple.com/jp/app/アプリID">';

    } else {

        print '<meta http-equiv="refresh" content="0;URL=https://apps.apple.com/app/アプリID">';

    }

} elseif ((strpos($ua, 'Android') !== false)) {

    print '<meta http-equiv="refresh" content="0;URL=https://play.google.com/store/apps/details?id=パッケージID">';

} else {

    print '<meta http-equiv="refresh" content="0;URL=ランディングページURL">';

}

?>

という感じで、User-Agent毎に出力する meta タグを変えればOK...というミスは、誰しもが踏むトラップかと思います。

iPhone or iPad だと、ブラウザにPCモードとモバイルモードみたいなものがあり、モバイルモードであれば、iPhoneなら「iPhone」、iPadなら「iPad」がUser-Agentに含まれていますが、PCモードだとMacと同じ(Macintosh; xxxx Mac OS xxxxみたいな形)になります。

また、iPadはあるバージョンからデフォルトがPCモードになっています。

つまり、上記コードだと、iPadからアクセスするとAppStoreではなくランディングページに飛ぶことになります。

Macでアクセスした時、ランディングページではなくAppStoreに飛ばしてしまっても問題無ければ、iPhone or iPad の判定式を次のように変更してあげれば良いかと思います。

if ((strpos($ua, 'iPhone') !== false) || (strpos($ua, 'iPad') !== false) || (strpos($ua, 'Mac') !== false)) {

User-AgentでiPadとMacの区別は不可能です。(そもそも、ブラウザやOSバージョンによってコロコロ変わるので確実性は保証できません)

参考までに、手元にあるMacとiPadのUser-Agentは以下のように(Mac OS Xのバージョン部分以外は完全に一致する形に)なっていました。

MacBook Air 2020 (Intel) + macOS Big Sir 11.6 + Safari の User-Agent

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.0 Safari/605.1.15

iPad Pro 3rd + iPadOS 15.0 + Safari (default = Desktop) の User-Agent

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.0 Safari/605.1.15


合理的ではないものを作りたい

ここ最近、実機版の東方VGSの開発が忙しくて、東方VGSの曲追加が滞っています。 東方VGS(実機版)のデザインを作りながら検討中。基本レトロUIベースですがシークバーはモダンに倣おうかな…とか pic.twitter.com/YOYprlDsYD — SUZUKI PLAN (...