この度、新作MeisyoNX開発の参考とするため、以下URLでアンケートを行うこととしました。
アンケートページ
期限は11月中となります。
ぜひ、お時間のある時にアンケートにご回答ください。( ^^)/~
【MeisyoNX開発 vol.4】画面イメージを作っては考え直して
MeisyoNX作るよーということで、進めてまいりましょう。
前回 | 次回
コンセプトとキャラクターをある程度作ったので、画面イメージを作っていこうと思います。
中身を作り込む前に、おおよその画面(雰囲気)を作ってみて、企画がイケてるかイケてないか確認します。
何をするの？
画面を作るといっても、何をするんだっけ…という方が多いかと思います。
作業ステップとしては以下の通り。
作る画面を決める
↓
トンマナ(色設定)を作成
↓
モック画面を手で描いてみる
↓
モック画面を作ってみる
↓
作ったモックを元にアイデアを出す
↓
よさそうなアイデアからモックを作り直す
↓
そのモックを元に画面イメージを作る
参考：実践ゲームUIデザイン コンセプト策定から実装のコツまで
ここで重要なことは、コンセプトを守ることと、一番よく使う画面から先に作るということですね。
わかりやすいよう、ここで要素関係図の登場！
これを見ると、このゲームは練習(育成)と試合(実戦)が中心ですね！
コンセプトやテーマで画面に関係がありそうな要素としては、、
・高校野球(青春)
野球で色と言ったらグラウンド（茶）、芝生（緑）、スコアボード（濃い緑）、ユニフォーム（白・黒）が想起される。
現実に存在する「青春」感を出すなら・・・やはり背景は白、文字は黒で彩度低めにして、現実のような雰囲気を出す必要があるでしょう。
・近未来的な世界観・自動的に進む（放置）
近未来で自動化が進んだ世界なので、レトロではなく近未来的なUI・文字フォントを使う。
・おじさんたち(ユーザー)が、監督として指示を出して、細く長く遊ぶことがゲームプレイの前提
練習や試合での指示はシステムっぽい見た目から出す。
試合はYahoo スポーツナビのような雰囲気。
おじさんの目に優しくしないとプレイを続けるのが厳しい・・・億劫になる（実体験）ので、読みやすい白背景・黒文字にする。
要件を整理したので、作業を開始しましょう。
まずは、画面の雰囲気を大きく左右する色の設定、いわゆるトーン＆マナー（トンマナ）を作ります。
彩度は抑えめに、現実感のある色で。目に優しく。眼鏡を外していても問題なく触れるように。
続いて、練習画面を作っていきましょう。
まずは手書きでいくつか案を書いて・書き直してみます。
ここで実際の画面で作ると、ビルド＆スクラップに手間がかかるので手書きにします。
ここでは、他のゲームも参考にしたほうが良いと思います！
参考1：Game UI Database
参考2：ゲームUIブログ
ある程度案が固まってきたら、モック画面を作って・・・
※うーん、このイモっぽさ・・・。前作のMeisyo＋と変わらない。
この画面を元に生成AIでいくつも案を出してもらいましょう。
適当に作ってみて良い案のパターンを盗み、次の案に生かしていきます。
※私はClaude Codeでモック画面とコンセプトを読み込ませて、案出ししてくれと指示しています。
ここで注意したいことは、（自分はプロではないので）一人で考えていても案は限られてくることを念頭に、自分の案を捨てる気を持つということですね。
誰かに案を出してもらうことで、「これはダメ、これは良い」とどんどん自分の考えが明確になっていきます。
それらの画面の要素から、良いと思うものを整理して、本番（バージョン1）の画面イメージを作っていきましょう。
どんなのできた？
色々作ってみたので、ゲームのプレイサイクルと合わせて見ていってみましょう！
練習方針を設定して（基本おすすめ設定でOK）、
放置時間を使って練習して、
試合する！
ホントはこの後に、試合結果詳細(1球速報的なもの)や成績分析(誰に強くて誰に弱いか)を見て、良い選手を見極めていくサイクルになるのですが・・・
とりあえず前の更新から2週間経ちそうなのでここまでで出します！
さいごに
結構時間がかかりましたが、落ち着いた配色かつちょっとスタイリッシュ感があるものにできた…かな？
この手の野球ゲームを良くプレイされている方には、「どんなのできた？」の画面を見たら「どこか見たことあるな・・・」感があるかと思います。
やっぱりいい画面って使い心地良いんですよね。
MVP（最低限のプロダクト）に必要な画面がもう少しあるので、作っていきたいと思います！
MeisyoNX 画面イメージ作成に時間がかかるorz
MeisyoNX作ってます・・・が。
画面を作るのが難しい！
理由：
・ワイ氏デザインセンス皆無
・AIでの自動作成が難しい（思った通りにならない）
・作ってみて壊している
最初にトンマナ（色調）を決めて、練習のイメージを手で書いて…
Webサイトとして作ってみて…
これはひどい。
Meisyo＋と変わらない。
AIで配色パターンを考えてみてもらおう。
これはどうかな？
・・・というのを繰り返し。
20案くらい作っては壊しました。
成果物・・・になりそうなのはこちら。
・練習画面
放置時間を使って、リアルタイムっぽく練習結果が見れます。
画面が結構動くようになっていて、見ていて楽しかったりする。
・試合画面
こちらも放置メインで、大事な所（ピンチ／チャンス）だけ操作できる感じです。
Meisyo＋リアル表示と、監督たちの甲子園の操作画面を組み合わせた感じになりましたね。
;つД｀)うおー難しいぞ…
【MeisyoNX開発 vol.3】キャラクターをゴリゴリ作ろう
MeisyoNX作るよーということで、進めてまいりましょう。
前回 | 次回
コンセプトをある程度作ったので、キャラクター画像を作っていこうと思います。
コンセプトがどの程度楽しくなりそうかは企画の段階でほぼ決まっているので、今回はカードゲームですし、その雰囲気がおおよそ決まるキャラクターが重要なんですよね。
これも自身のモチベを上げていくために重要で、キャラクター的にどういうイメージのゲームになるか見えていたほうが安定感をもって作りやすいという過去の経験からです。
何をするの？
キャラクターを作るには、ストーリーが必要です。
ストーリーはコンセプトからある程度は想像できると思います。
わかりやすいよう、ここで要素関係図の登場！
ざっくりというと、監督が中心のゲームです。
チームとしては現役選手を中心に、コーチ5人とOBがサポートするシステムです。
つまり監督本人か関係者（特にコーチ）がストーリーの中心になるはず。
元々のMeisyoのストーリーは、監督とマネージャー（高藤雪）の関係がほとんどでした。
今回からはコーチ5人が重要になってきそうです。
というわけでコーチ5人の設定を作成してっと・・・
5人のコーチとモブの画像を作りましょう。
必要なのは、(1)カード画像、(2)バストアップ画像、あと(3)ちびキャラ画像。
ここで大事なのは、今後のシステム構築にも対応できるように、複数種類の画像を用意しておくことです。
カード画像は、各選手の詳細画面やガチャの当たり画面に。
バストアップ画像は、選手一覧やオーダー画面、ストーリーに。
ちびキャラ画像は、説明書だったり、ちょっと砕けた場面で使うために。
前作までは1つの画像で全部対応しようとしていたので詰んでました。
コーチの5人のバストアップ画像と、
最後にモブと。
生成AIですべて作っています。
ですが、顔形・印象・髪の長さなどすべて調整するプロンプトを作り、何度も調整し、いいのが出てくるまで出し直し…みたいなことをやっています。
再現性を取れるようになるまで作り込むのが結構大変でしたね。
（絵師の人を見つけたらこの子たちを書き換えてもらいたい…）
再現性をさらに高めるために、(1)カード画像(全身画像)から(2)バストアップ画像と(3)ちびキャラ画像を生成させるようにしています。
プロンプトで顔形をそれぞれの画像で指定するよりも、「添付した画像のキャラクターの顔を切り出して～」などと指示すればうまく出来ます。
注意点は、「○○（マンガ）の××（キャラクター）みたいな女性を～」と指定すると今後著作権的にNGになりそうなのでやめておきましょう。
ワイは固有名詞を出さないようにしていますし、生成に利用したプロンプトを保存しています。
今後を考えると、絶対そういう規制がきちんと整備されると思ってます。
一応、仕事で生成AIを取り扱ってるのでプロであるをいう自覚もありますし、クライアントでの構想や利用方針等を決めるときもありますしね…。
適当に決めると、あと10年変わらない可能性もあって、、リスクがあり、怖いんですよね。
という負の側面もありますので、利用は計画的に。
このカード画像、わりとかっこいいのでは…？姿勢も破綻してないですしね。
ここまでキレイに出すのにめちゃくちゃ苦労しました・・・。
野球は結構画像データがあるみたいで、右投げなら広く応用がききました。。
ただ、小柄＋左投げサイドというかなりニッチなものはなかなかうまくいきませんでした。orz
さいごに
次はMVPの画面のイメージを作っていきたいかなと思います。
どういう体験ができそうな画面なのか、もっと向上させるならどういう画面にするか検討していきたいですね。
これまでの作品のデザインセンスが皆無なこともありつつ、ものぐさなこともあり、とりあえず作る → 更新せずそのままが多すぎるんですよね。;つД｀)
いい感じに作れそうなものができるまで、叩いて叩いて～作っていきたいと思います。
それでは！
【MeisyoNX開発 vol.2】まずはゴールとプロセス設定から
MeisyoNX作るよーということで、進めてまいりましょう。
前回 | 次回
さっそく手を動かしてシステムや画面を作っていく・・・なんてことはしません。
これまでの経験から、高確率で途中で迷子（何をするんだっけ？）になるので。
そうするとモチベが下がってエタる（開発中止）・・・とならないよう、注意していきましょう。
作り切るためには、「限られた能力を頑張って使う」のではなく「仕組みでカバー」が鉄則です！
何をするの？
かんたんに言うと、ゴールと、そこまでのプロセスを先に決めるですね。
そうすると、今自分はどの状態で何をすべきかはっきりしてきます。
個人開発はゴールが自分の頭の中にしかないので、、少しずつ忘れます。これは人間なので仕方ない。
ゲームをはじめ、プロダクトはイメージが少しでズレると思ったものと違うものがでてきます。
そうするとモチベが下がって詰みます。
今回はMVP（Minimum Viable Product;必要最小限の機能を持った製品）を作り、ある程度面白そうであれば進めていきます。
（その時点で面白くならないなら、いくら頑張っても面白くならないんですよね…）
作業ステップとしては以下の通り。
コンセプト作成
↓
要件定義
↓
ゲーム内要素の関係図の作成
↓
MVPターゲット選定
↓
画面リスト作成
参考：
コンセプト「から」ゲームを作るのが苦手な人に捧げる、コンセプト「で」ゲームを作る方法
システム開発のV字モデルとは？流れやW字モデルとの違いを解説
※ゲーム開発（ワイの(まだ)趣味）とシステム開発（ワイの本業）の掛け合わせですね。
注力するポイントは？
一番重要なのはコンセプトです。
コンセプトがダメなら後工程でどう頑張っても仕方ないです。やること決まってるんで。
今のコンセプト(チーム)は「このチームで、一度しかないあの夏へ」ですので、要件が「＝(メンバーが移り変わる)現役チームで強い相手に立ち向かう」ということが確定します。
以前は、「一度しかないあの夏へ」・・・で、これ結構解釈の幅があってコンセプトとして破綻してるんですよね。そうして考えた要件が「現役チームでノーマルモード(対NPC戦)を戦う。それこからプロになった選手たちがOBチームとして対人戦を戦う」・・・すげー複雑。困る。
むしろ、作れるもの（前作も同じ仕様）から逆算してコンセプトを曲解しとる・・・
できるだけシンプルにしたいですね。
プレイの上で、ユーザーに伝わらないと意味がないので…。
例えば、メインコンセプトの「99%の放置と1%の采配が勝負を決める、1日10分の高校野球監督ゲーム」も・・・ピンポイントな采配もできるが基本は放置がメイン。1日10分の縛りあり。という自分の中では単純明快なコンセプトです。
その後の頑張り
そういう検討を繰り返して、、ゲーム内の要素を整理して…
※この時点で破綻してることが結構ある。関係図が書けない＝ゲームとして成り立ちません。。
MVPで最低限必要な要素を出して、画面リストとしてまとめました。
※生成AIをはじめ、いろいろな自動化・思考の外注ツールはかなり使ってます。助かりますね。
さいごに
次からはゲーム開発っぽいことをやっていきます！
MVPで使うキャラクター（メイン5名、モブ1名）イメージの作成をして、練習画面だったり特にゲームの初期のほうに体験するものを作っていきたいですね。
ゲーム自体の雰囲気と、キャライメージを合わせておかないと後で作り直しになるとアレですからね…。
ページのトンマナとかも作らないとかな。
まずはゴールとプロセス設定から！
作成の指針になるものを作っていきましょう。
それではー
名将と呼ばれた者達 Next Generations(Meisyo NX) 開発開始
皆さま、いかがお過ごしでしょうか。れいです。
めーっちゃ暑かった夏も終わりを迎え、勝者(沖縄尚学)が決まり、そろそろ過ごしやすい季節となってまいりました。
そろそろ寒くなるから風邪に注意するんやぞ…ということで(?)、
直近でアンケートさせていただいていましたが、
この度正式に新作ゲームの開発を開始したいと思います。
開発するのはどんなゲーム？
ゲームコンセプトは
「99%の放置と1%の采配が勝負を決める、1日10分の高校野球監督ゲーム」です。
裏コンセプトは
「仕事と家といろいろ頑張るあなたに、ほっと一息。」で、日常の癒しになるような体験を提供できるよう開発を進めていきます。
ジャンル的には放置 × 野球監督 × 戦略ゲーム(RTS)ですね。持ちうるリソースを最適配分し、敵に勝利することが目的のゲームジャンルです。
一言で言うと、「放置ゲーで、先に采配(いろいろな事前設定)をしておき、その成果を少しずつ楽しめるゲーム」ですね。
練習はその通りです。育成方針を決めて、育っていくのを見守って…。
試合も采配 → 放置要素が強く、途中の指揮もできるようになりますが、やはり事前設定をうまく出来るチームが勝つようになりそうです。
放置するにも期待感があって楽しいし、プレイも楽しいようなゲームで、・・・ただ、そんなにゲームに時間を使えない人に向けて送ります。（サブゲーム向けともいう）
そのようなコンセプトをまとめた初版コンセプトはこちら(α1版)。
やっぱりこのマークはいい感じ…
このマークでわかる通り、このゲーム(Meisyo NX)はMeisyo＋の後継・・・もとい魔改造品です。
今も更新していて、「このチームで、一度しかないあの夏へ」という、現役チームを主軸としたわかりやすいストーリー・対人コンテンツを持つゲームとなる予定です。
追加予定の選手の卒業もあるので、その時のチームでその大会に挑めるのはたった一度きりなんですよね。
そうして、チーム力が随時変わっていくので、必然的に、メインの対人コンテンツであるユーザー甲子園(旧：公式戦)も大番狂わせが起こりやすい、毎回ワクワクできるゲーム体験となっていく予定です。
これまではこの人＝強いor弱いがはっきりしてたし、戦う前に「負けそう」と思う→負けるがあたり前でした。
まあシステムがそう（卒業なし＝選手の入れ替えが起こらない）ならそらそう（強い人はずっと強く、勝てない）よ。
今後もいろいろ変えて、最適なコンセプトに調整します。お楽しみに。
（皆さんのご意見待ってます！！）
いろいろ言いたいことはあるけど、「今のオンラインでできるゲームは続けることにめちゃくちゃコストがかかる」んよな…。
毎日の周回を強いられるイベント、イベントが終わらない（イベントの次にすぐイベント）、ついていかないと狩られる…運営側も経験したけども苦い記憶。
ホンマきついで、ワイみたいなおじさんには。;つД｀)
ゲームタイトルでいうと、Meisyo Next Generations…次世代とは…？と思われる方もいらっしゃるかと思います。
これまでのMeisyoになかった選手の卒業・世代の継承やOBによるコーチなど、次の世代・目標とする試合に向けて積み重ねていくことを主眼としています。
Meisyo NXにしたのは、そのまま略するとMeisyo NGは…NGはイヤダナーという個人的な感想です。
ストーリーも次世代に変わる…つもり。ストーリーの登場キャラも作っていってます。
お姉さんｶｯｺｲｲ
ストーリーの枠は決めているけれど、キャラクターはやはりインスピレーションが大事かなと。
なんで次世代(Next Generations)なの？という疑問も、今後出す初期版のストーリーを読んでいただくと分かる…かな！
どこでリリースするの？
Webアプリ…つまりブラウザ(ChromeやEdge)になります。
インストール不要。どこでもIDとパスワードさえあれば遊べます。
監督たちの甲子園はAndroidやiOSでしたが、元に戻します。
そういうこと(?)で名前も戻します。
放置ゲーのコンセプトもMeisyoがベースですしね。
今後はどう開発していくの？
以下のように、継続的にユーザーの皆さまの意見を取り入れて改善しつつ、完成までいければと思います。
1. コンセプト作成
いまやってるよー。
ゲームの大筋を決めていきます！
2. プロトタイプ開発
どういうゲームなのか伝わるよう、プロトタイプを作ります！
次のステップに向けて、自分が納得いくレベル感で出したいですね。
3. プロトタイプ発表・クラウドファンディング
伝えたい物語の示し方（ストーリーデザインやキャラクター設定、世界観・・・とそれを示すUIや画像）・・・いわゆるナラティブに課題感があるので、協力者を募りつつ、知名度を上げていきたいと思います。
今までは本当に最小限のリリースをして積み上げて作っていく形でしたが、プロトタイプ時点である程度魅せられるものにしたい。
4. 本格開発
コーディングAIもあるので、開発の高速化はできそうですが・・・？
5. リリース・継続開発開始
ここからが本番！
開発中止にならないように、ステップをきっちりと踏みながらやりたい…やるんやで;つД｀)
自身の強みと戦略
Meisyoもそうですが、戦略は大事なので書いておきましょう。
もしかしたら、後年誰かが見て参考になるかもしれないし。
自身の強み
楽観的
なんとかなる気が強い。（感想）
ゲームを完成させられる
仕事で業務システムのシステム開発を内（実装側）から、外（構想側）からやってますが、複雑性が明らかに異なるんですよね。
ゲームのほうが圧倒的に難しい。
それを完成させられる時点でなかなか強いかなと。
構想とシステム設計と実装が一気通貫で出来る
仕事でもやってますが、なかなかできる人はいませんね。
構想した通り、思った通りに動かすことができるのは強いと思っている。
なお表現がよくなく、伝わりづらいことは分かってるので改善中…。
AIがチョットワカル
仕事でもやってるのでチョットワカルレベルです。すごい人はすごい（ﾅﾆｿﾚ）
元々品質管理の仕事をやっていたので、ルールベースAIという基礎の基礎から入ってました。
今はLLMやベイズ推定・数理最適化なども理論面からある程度実装・改善ができます。なおレベル感は大学の教科書1冊目のレベルのもよう。
戦略
自分の強いところで戦う。
監督たちの甲子園でフル3Dゲームを作ってみて思ったんですが、総合格闘技過ぎて厳しかった。
複雑なゲームシステム構築やAI実装だけならまだしも、(自身が全くわからない)グラフィック、キャラの動き、感情の動きの表現をはじめとしたすべての軸をある程度高品質に達成しないと厳しいですな。パワプロがやっぱり強い。
Webならそれらの軸を落として、自分の強み（システムで楽しんでもらう）に注力できるかなと考えています。
それでいうと現在のMeisyoにユーザーさんもたくさんいらっしゃいますし。
継続的に発信する。
継続的な（心理的な）つながりって大事ですよね。
開発側で何がどう進んでいるのかわからなかったりして、ユーザーの方の認知が弱くなっていくかなーと思っています。
悩みや弱さも発信する。
発信では、どうしてもきれいなことしか言えなくなりますし、、
試行錯誤だったり、厳しいところ、泣きたくなるところだったりは見えません。
そういったところもユーザーの方へのコミュニケーションとして出していきたいと思います。
（カチッとした会社で作るなら無理でしょうけど、こちらは自分で方針を決められるので。こちらも戦略の1つです。）
そこでいうとコスト削減でいえば、AIで文章は作れますが、AIって良いもの、標準的なものしか見せないんですよね。
瞬間的なつながりというか、興味を持ったその人の共通点を知って少しうれしくなる・・・みたいなところって、強いところではなくて、弱いところ、隠したくなるところにあると考えています。
もちろん、この文章も自作ですし。（頑固）
さいごに
キャラクターをいろいろと作ってみています。いい感じですね。どうキャラ付けしよう。
いろいろ話したいことはありますが、まずはここまでで。
継続的に開発進捗をお伝えしていく予定ですので、これからよろしくお願いします！
つづきはこちら
監督たちの甲子園(v1.3.5) 新規ユーザー分析
私は運営するゲームの分析を日常的に行い、機能の改善を行っています。
元々ゲーム運営のアナリスト(コンサルタント)をしていたので、ゲームの分析はチョットワカルかもしれません。
今回は、ゲームの状況をかんたんに確認するために、新規ユーザーの継続率を分析していきます。
前提
・Unity Analyticsで分析した結果です。
Unity Analytics > SQL データエクスプローラーを利用しています。
SQLの種類はPostgreSQLベースに見えます。
・全ユーザーは含んでいないログです。
(上手く取れないユーザーがかなりいる模様…)
・SQLコードを公開します。
自身のゲームの分析などにご自由にお使いください。
分析したゲームはこちら
新規ユーザーの分析
まず、分析するにあたって対象ユーザーと指標を確認しましょう。
対象ユーザー
新規ユーザーとは、ゲームを開始してすぐのユーザーのことです。
※対して、既存ユーザーはゲームを開始して何日か経過して継続しているユーザーのことを言います。
指標：継続率
継続率は、対象となるユーザーが、対象となる経過日(24時間以内)にログインしている割合を確認します。
継続とは、
DAY1であれば、新規登録後24～48時間にログインしている人をいいます。
DAY3であれば、新規登録24*3～24*(1+3)時間にログインしている人、
DAY7であれば、新規登録24*7～24*(1+7)時間にログインしている人、
DAY14であれば、新規登録24*28～24*(1+14)時間にログインしている人、
DAY28であれば、新規登録24*28～24*(1+28)時間にログインしている人です。
※DAY1, 3, 7, 14, 28の日の区切りはゲームや会社によって変わります。
この指標は「毎日ログインすることが当たり前のゲーム」で採用されやすいです。
毎日プレイすることが必須ではない場合、以下の継続率(Week版)のような指標を入れてみることがあります。
指標：継続率(Week版)
継続率(Wide版)は、継続の判定幅を広くした継続率のことです。
継続(Week版)とは、
DAY1であれば、新規登録後24～24*(1+7)時間にログインしている人をいいます。
つまり、1日後から1週間以内にログインしている人を示します。
この指標は「毎日ログインすることが当たり前ではないゲーム」で採用されます。
「1週間に1回は触ってもらえるよね」ってことです。
これは分析の都合上、「ユーザーがゲームから離脱したかどうか」を厳密に判定できないため、かなり幅を持たせて分析をしています。
分析するサービスによって変わるので、調整して使ってみてください。
分析：バージョン別継続率
それでは、ゲームの分析を行ってみます。
ゲームはバージョンアップにより内容が様変わりするため、「継続率を取るにはバージョン別が良いだろう」ということでバージョン別に分析を行います。
加えて、特定のプラットフォーム(iOS/Android/PCなど)に異常がないことを確認するために、プラットフォーム別にも分析します。「プラットフォームの継続率が大きく違う」ことは、異常があると判断できます。
分析からわかること1
では、継続率を見ていきましょう。
初期バージョン（v1.0、v1.1、v1.2）はそれほど指標が変わりません。
テコ入れしたv1.3_1は指標が大きく改善しています。これは良いアップデートだったと言えるでしょう。
ただ、さらにテコ入れしたv1.3_2は初期バージョンより下がっています。これはよろしくないので、元に戻しましょう。
という、数字からゲーム内に何が起こっているかを想像しながら見ていく必要があります。
分析からわかること2
では、プラットフォーム別に見ていきましょう。
・iOSが良さげかも？
・Androidは要改善
・PCは人がいない
※加えて、完全オフラインではログが取れない仕組みなので実態が不明なユーザーもいます。
こちらの数値と外部データを見比べてみると面白いことがわかります。
・App Store(iOS)とGoogle Play(Android)の登録数から、ログが取れないユーザーがいそう。
・App Storeのアプリ保持数は200超だが、Google Playは100いくかどうか。
Google Playユーザーのほうがアプリを消す傾向にあると言えるでしょう。このゲームは400MB近く容量ありますからね…。
分析からわかること3
1日後継続しない人は、1週間にわたって観察してもほぼ継続しないことが読み取れます。DAY1とDAY1(WEEK版)の数値がほぼ同じですし。
ただ、3日後以降はユーザーは思い思いにログインしているようです。なぜなら、DAY3の1日間だけログイン割合より、DAY3~10の間のログイン割合が大きく伸びているからです。
つまり、平均的なユーザーはこのゲームに対してどのような接し方をしているか推察できます。
このデータから追加で、深掘りとして「毎日ログインしているひと」「たまにログインしているひと」の人数を確認して、それぞれに合わせた施策を打つ等を考えていけますね。
分析コード
当ゲームはバージョンの記載方法にCLIENT_VERSION=「X.X.X」を採用しているため、複数バージョンをVERSION_GROUPにまとめています。
ある程度ユーザー数がいないと分析できないので、複数バージョンをまとめるようにしてください。
-- ユーザーIDごとのゲーム開始時間
WITH user_first_start AS (
SELECT
USER_ID
,time_start
,PLATFORM
-- バージョンごとに切り分け
,CASE
WHEN CLIENT_VERSION LIKE '1.0.%' THEN 'v1.0.X'
WHEN CLIENT_VERSION LIKE '1.1.%' THEN 'v1.1.X'
WHEN CLIENT_VERSION LIKE '1.2.%' THEN 'v1.2.X'
WHEN CLIENT_VERSION LIKE '1.3.%' THEN
CASE
WHEN CLIENT_VERSION <= '1.3.3' THEN 'v1.3_1'
WHEN CLIENT_VERSION <= '1.3.5' THEN 'v1.3_2'
ELSE 'v3_3'
END
ELSE 'others'
END AS VERSION_GROUP
FROM
(
SELECT
USER_ID
,EVENT_TIMESTAMP AS time_start
,PLATFORM
,CLIENT_VERSION
,ROW_NUMBER() OVER (PARTITION BY USER_ID ORDER BY EVENT_TIMESTAMP ASC) AS rn
FROM
EVENTS
) AS t
WHERE
rn = 1
)
-- 継続率
, user_retention AS (
SELECT
fs.USER_ID
,fs.time_start
,fs.PLATFORM
,fs.VERSION_GROUP
-- 通常判定版(1day内)
,MAX(CASE WHEN
e.EVENT_TIMESTAMP > TIMESTAMPADD(HOUR, 24 * 1, fs.time_start)
AND e.EVENT_TIMESTAMP <= TIMESTAMPADD(HOUR, 24 * (1 + 1), fs.time_start)
THEN 1 ELSE 0 END) AS day1
,MAX(CASE WHEN
e.EVENT_TIMESTAMP > TIMESTAMPADD(HOUR, 24 * 3, fs.time_start)
AND e.EVENT_TIMESTAMP <= TIMESTAMPADD(HOUR, 24 * (1 + 3), fs.time_start)
THEN 1 ELSE 0 END) AS day3
,MAX(CASE WHEN
e.EVENT_TIMESTAMP > TIMESTAMPADD(HOUR, 24 * 7, fs.time_start)
AND e.EVENT_TIMESTAMP <= TIMESTAMPADD(HOUR, 24 * (1 + 7), fs.time_start)
THEN 1 ELSE 0 END) AS day7
,MAX(CASE WHEN
e.EVENT_TIMESTAMP > TIMESTAMPADD(HOUR, 24 * 14, fs.time_start)
AND e.EVENT_TIMESTAMP <= TIMESTAMPADD(HOUR, 24 * (1 + 14), fs.time_start)
THEN 1 ELSE 0 END) AS day14
,MAX(CASE WHEN
e.EVENT_TIMESTAMP > TIMESTAMPADD(HOUR, 24 * 28, fs.time_start)
AND e.EVENT_TIMESTAMP <= TIMESTAMPADD(HOUR, 24 * (1 + 28), fs.time_start)
THEN 1 ELSE 0 END) AS day28
-- 判定広め版(1week内)
,MAX(CASE WHEN
e.EVENT_TIMESTAMP > TIMESTAMPADD(HOUR, 24 * 1, fs.time_start)
AND e.EVENT_TIMESTAMP <= TIMESTAMPADD(HOUR, 24 * (7 + 1), fs.time_start)
THEN 1 ELSE 0 END) AS day1_w
,MAX(CASE WHEN
e.EVENT_TIMESTAMP > TIMESTAMPADD(HOUR, 24 * 3, fs.time_start)
AND e.EVENT_TIMESTAMP <= TIMESTAMPADD(HOUR, 24 * (7 + 3), fs.time_start)
THEN 1 ELSE 0 END) AS day3_w
,MAX(CASE WHEN
e.EVENT_TIMESTAMP > TIMESTAMPADD(HOUR, 24 * 7, fs.time_start)
AND e.EVENT_TIMESTAMP <= TIMESTAMPADD(HOUR, 24 * (7 + 7), fs.time_start)
THEN 1 ELSE 0 END) AS day7_w
,MAX(CASE WHEN
e.EVENT_TIMESTAMP > TIMESTAMPADD(HOUR, 24 * 14, fs.time_start)
AND e.EVENT_TIMESTAMP <= TIMESTAMPADD(HOUR, 24 * (7 + 14), fs.time_start)
THEN 1 ELSE 0 END) AS day14_w
,MAX(CASE WHEN
e.EVENT_TIMESTAMP > TIMESTAMPADD(HOUR, 24 * 28, fs.time_start)
AND e.EVENT_TIMESTAMP <= TIMESTAMPADD(HOUR, 24 * (7 + 28), fs.time_start)
THEN 1 ELSE 0 END) AS day28_w
FROM
user_first_start AS fs
INNER JOIN
EVENTS AS e
ON
fs.USER_ID = e.USER_ID
GROUP BY
1, 2, 3, 4
)
-- 日別分析
SELECT
VERSION_GROUP
,PLATFORM
,DATE(MIN(time_start)) AS date_min
,DATE(MAX(time_start)) AS date_max
,COUNT(*) AS count_uu
,SUM(day1) / COUNT(*) AS rate_day1
,SUM(day3) / COUNT(*) AS rate_day3
,SUM(day7) / COUNT(*) AS rate_day7
,SUM(day14) / COUNT(*) AS rate_day14
,SUM(day28) / COUNT(*) AS rate_day28
,SUM(day1_w) / COUNT(*) AS rate_day1_w
,SUM(day3_w) / COUNT(*) AS rate_day3_w
,SUM(day7_w) / COUNT(*) AS rate_day7_w
,SUM(day14_w) / COUNT(*) AS rate_day14_w
,SUM(day28_w) / COUNT(*) AS rate_day28_w
FROM
user_retention
GROUP BY
1, 2
ORDER BY
1, 2;
さいごに
今日はかんたんに、新規ユーザーの継続率からゲームの現状を分析しました。
「もっと知りたい」「○○ってどう分析すればいいの？」というコメントをいただければ、記事を書いていきたいと思います。
ぜひコメントくださいませ。( ^^)/
【生成AIテスト記事】Unity運営に関する各種プラットフォーム(Google, Apple, Unity)の情報公開可否
Deep Researchすげえ、ってことで
”「禁止」とされている所はやらず、「許可」とされているところは自分で調べて実行する”でいいんじゃないかな。
調べる手間の削減っていいよね、という生成AIのテスト記事です。
結論
下記は各プラットフォームごとに「スクリーンショット公開の可否」、「データ公開の可否」、「規約の根拠・該当条項」、「注意点・リスク」を整理した表になります。
| プラットフォーム | スクリーンショット公開の可否 | データ公開の可否 | 規約の根拠・該当条項 | 注意点・リスク |
|---|---|---|---|---|
| Unity Analytics | 原則不可。Unityが提供するUIや画面は機密情報に該当。 | 自社で取得した統計データは公開可能。ただし、個人情報やUIそのものが映らないようにする。 | Unity利用規約（Unity Materialsの取扱いに関する条項） | 機密情報漏洩によりアカウント停止や法的措置のリスク。 |
| Google Play | 基本的に許可。ただし、個人情報や未公開情報が写らないよう注意。 | 自社アプリの統計データ（ダウンロード数、売上など）は公開可能。ただし、特定の機密APIデータは除外。 | Google Play開発者契約、Googleブランド資産ガイドライン | 非公開情報や個人情報の露出、スクリーンショットの改変に注意。 |
| Apple (App Store Connect) | 許可。正式リリース済みの情報は公開可能。ベータ版等プレリリース情報は非公開。 | 売上やダウンロード数などの統計データは公開可能。 | Apple Developer Program License Agreement（プレリリース情報に関する条項） | プレリリース情報の混入や、Appleの商標・ガイドライン遵守の必要性。 |
| Google AdMob | 禁止。管理画面のスクリーンショットはGoogle機密情報とされ、公開は規約違反となる。 | 一部のみ許可。総支払額などは公開可能だが、クリック数、CTR、eCPMなどの詳細指標は非公開。 | Google AdSense/AdMob利用規約（秘密保持条項） | 機密情報漏洩によりアカウント停止や収益没収のリスク。 |
| Google Analytics | 許可。通常の解析画面は公開可能。 | 公開可能。なお、AdSense連携等で機密情報が含まれる場合はその部分を除外する必要がある。 | Google Analytics利用規約（AdSense連携部分はAdSense規約が適用） | AdSense由来の機密情報との混同に注意。スクリーンショット改変や誤解を招く表現に気をつける必要がある。 |
| Firebase Console | 許可。一般公開されている情報については公開可能。ただし、ベータ機能や非公開情報はNG。 | 公開可能。ただし、個人情報やセキュリティに関わる情報（APIキー、プロジェクトIDなど）は伏せる。 | Firebase利用規約、Googleブランドガイドライン | APIキーやプロジェクトIDなど、公開すべきでない情報の露出に注意。ベータ機能や非公開情報の公開は避ける。 |
この表は、各サービスの利用規約やガイドラインに基づく一般的な考察です。具体的な公開内容や方法によっては、各プラットフォームへの事前確認や個別の判断が必要となる可能性がある点にご注意ください。
詳細
Unity Analytics
- スクリーンショット公開の可否: 原則不可です。Unityの利用規約では、Unityが提供するツールや資料（「Unity Materials」）は機密・専有情報と定められており、ユーザーが第三者に配布・開示することを禁止しています
。これにはAnalytics管理画面などUnityの提供するダッシュボードの画面も含まれると解釈されるため、Unityの許可なくスクリーンショットを公開するのは規約違反となる可能性があります。
- データ公開の可否: 自分の取得データは概ね公開可能です。Unity Analyticsで得られる自社ゲームのユーザ数や収益など自分のデータそのものを公開すること自体は、規約で明確に禁止されていません。つまり、数字やグラフの値そのもの（例えば「月間アクティブユーザ◯◯人」など）を文章で共有することは問題ないと考えられます。ただし、それを示す画面そのもの（UnityのUI）は上記の通りUnityの機密情報たり得ます。また公開するデータに個人情報が含まれないよう注意が必要です（ユーザー個人を特定できる情報の公開はプライバシーポリシー違反になります）。
- 規約の該当箇所・根拠: Unity利用規約12.4節で「Unity Materials（Unityが提供するAPIやSDK、ツール類）は機密情報であり、明示的な許可なく第三者へ開示してはならない」と規定されています
。この条項が根拠となり、Analytics管理画面といったUnity提供のサービス画面のスクリーンショット公開は制限されます。一方、開示するデータ自体はユーザーのコンテンツにあたり、この条項の対象外と解釈できます。
- 注意点・リスク: Unityの機密情報を無断で公開した場合、アカウント停止や法的措置などのリスクがあります。実際には個人ブログ等でUnityエディタの画面などを載せている例もありますが、公式には規約違反となり得る点に注意が必要です。また、データ公開に関してはUnity側より禁止されていなくても、自社契約やプライバシー上の配慮（ユーザーのプライバシーや機密情報の取り扱い）を怠らないようにし、問題が起きない範囲で公開しましょう。
Google Play（Play Console）
- スクリーンショット公開の可否: 概ね許可されています。Google Play開発者向け規約には、開発者コンソールの画面を公開してはならないという明示的な禁止条項は見当たりません。実際、多くの開発者が自分のアプリのダウンロード数やランキングをブログ等でスクリーンショット付きで紹介しています。Googleのブランド資産ガイドラインによれば、サービス説明のためにインターフェイスのスクリーンショットを使用すること自体は許容され、許可申請も不要であるとされています
。従って、Play Consoleのスクリーンショットも適切な範囲であれば公開可能です。ただし画面に含まれる他人の個人情報（例: ユーザーレビューの氏名やメールアドレス）が写らないよう注意が必要です。
- データ公開の可否: 自分のアプリの統計データは共有可能です。例えばダウンロード数や売上など、Google Playコンソールで確認できる自社アプリのパフォーマンス指標をブログやレポートで公開することに制限はありません。それらのデータは開発者自身のものであり、Google側の機密情報には該当しません。実際、Google Playではアプリのインストール数レンジがストア上で公開されており、開発者が自ら詳細な数値を明かすことも問題視されていません。但し、Google提供のAPI等から得られる特定のデータは機密指定されている場合があります。例として、購入の払い戻し情報を取得する「Voided Purchases API」で得られるデータはGoogleの機密情報とされ、利用規約上第三者開示が禁止されています
。こうした特定ケースを除けば、一般的な統計データの共有は許容範囲です。
- 規約の該当箇所・根拠: Google Play開発者配布契約（Developer Distribution Agreement）自体にはスクリーンショットやデータ公開を禁ずる条項は見られません。
にあるのは開発者資格情報（ログイン認証情報）の機密保持義務などで、管理画面の内容公開を直接規制するものではありません。また、Googleのブランドガイドラインでは**「サービスや製品の説明を目的としたスクリーンショット使用」は認められる**と明記されています
。一方で前述のように、特定APIの返戻データはGoogleから機密指定される例があります
。従って、一般には許可されているものの、Googleから機密扱いされる情報は公開NGという整理になります。
- 注意点・リスク: 開発者コンソールのスクリーンショットを公開する際は、個人情報や未公開情報の露出に注意してください。たとえば内部テスト中の機能やリリース前情報が写っている場合、それが公開されると問題になる可能性があります。またGoogleのブランドガイドラインに沿い、スクリーンショットの改変をしない（UIを歪めたり変更しない
）、必要に応じて著作権表示を行うなどのルールを守ることが推奨されます。万一Googleが問題視する情報（例: 機密指定されたAPIデータなど）を公開した場合、アカウントへの警告や停止などの措置が取られるリスクもゼロではありません。基本的には常識的な範囲で情報を共有し、懸念がある場合は事前にガイドラインを確認するかGoogleに相談すると安心です。
Apple（App Store Connect 等の管理画面）
- スクリーンショット公開の可否: 許可される場合が多いです。Appleの開発者向けポータル（App Store Connectなど）自体は正式公開されているサービスであり、その画面を共有することを包括的に禁じる条項はありません。重要なのは、Appleが「機密」と指定している情報かどうかです。Apple Developer Program License Agreementでは、プレリリース（ベータ版）のソフトウェアやサービスはAppleの機密情報とされ、それらについてスクリーンショットの投稿やレビュー公開をしてはならないと明確に定められています
。しかし、App Store Connectは開発者向けの本番サービスであり、そこに表示される自分のアプリの販売数・ダウンロード数といった情報はプレリリースの機密には当たりません。そのため、自社アプリの実績を示す目的で管理画面のスクリーンショットを掲載すること自体はApple規約上問題になる可能性は低いです。実際、多くの開発者や企業がプレスリリースやブログで自社アプリの実績データ（Appleから提供される売上レポート等）の画像を公開しています。
- データ公開の可否: 自由に公開可能です。自分のアプリの売上金額、ダウンロード件数、ランキング推移など、App Store Connectで得られる統計データを外部に共有することにAppleの規約上の制限はありません。それらの数値は開発者自身のビジネス成果であり、Appleが秘密にすべきものではないからです。Apple自身も各種ランキングやストア統計情報を公開していますし、開発者が自ら自社アプリの成功事例として具体的な数値を公表することは一般的に行われています。注意点としては、レポートに含まれる購入者の個人情報や、Appleが提供する非公開の指標（もしあれば）を晒さないことです。またAppleの名称やロゴを用いる際のガイドライン（トレードマークの適切な表記など）も守る必要がありますが、単にスクリーンショットを貼るだけであれば大きな問題にはなりにくいでしょう。
- 規約の該当箇所・根拠: Appleの開発者プログラム利用契約 第9条に機密情報の取り扱い規定があります。9.1項では 「全てのプレリリースのAppleソフトウェア、サービス、ハードウェアはAppleの機密情報とみなす」 と定められ、WWDCで開示された技術情報以外のベータ版については 「スクリーンショットを投稿したり公にレビューしてはならない」 と明記されています
。この条項が示すのは、未公開のものに限って秘密保持義務が課されるということです。逆に言えば、正式リリース済みのサービスや既に公知の情報はApple機密には該当しません
。また9.4項では契約内容やAppleとの関係を勝手に公表しないよう求めていますが
、自社アプリのデータ公表は契約そのものの開示には該当しないため問題ありません。以上より、App Store Connectの画面やそのデータはプレリリース情報を含まない限り機密扱いではないと言えます。
- 注意点・リスク: 最大の注意点は、Appleが非公開としている情報をうっかり含めないことです。例えば、新OSリリース前に提供されているベータ版App Store Connectの新機能画面や、Appleからテスト目的で提供された限定レポートなどを公開すると契約違反となり得ます。その場合、Appleは開発者プログラムからの除名（アカウント停止）や法的措置を取る権利があります
。一方、通常の範囲で自社アプリの販売実績を共有する限りはAppleからペナルティを科されるケースはほぼありません。むしろApp Storeの成功事例として表彰されることもあります。ただし第三者へのプレスリリース等でAppleの名前を出す場合には、あたかもAppleが保証したような誤解を与えないようにするといった配慮（Appleの商標ガイドライン遵守など）が必要です。またスクリーンショット中のデータを改竄したり誤解を招く形で公表すると信頼性を損ねるため、その点でも注意しましょう。
Google AdMob
- スクリーンショット公開の可否: 禁止と考えてください。Google AdMob（及びAdSense）の利用規約には機密保持義務が含まれており、管理画面に表示される詳細なパフォーマンス指標は「Google機密情報」として扱われます
。具体的には、クリック率（CTR）や収益に関する各種統計値が機密情報の例として挙げられており、Googleの事前許可なく公開してはならないと明記されています
。従って、AdMobのダッシュボードをそのままスクリーンショットで公開する行為は契約違反になります。実際、GoogleはAdSense/AdMob出版パートナーに対し、管理画面のスクリーンショット共有を禁止しており、SNS等でこれを投稿すると即座にポリシー違反と見なされる可能性が高いです。
- データ公開の可否: 一部のみ許可されています。AdMob（AdSense）規約では、公開が許されるデータと禁止されるデータが明確に区別されています。公開可能なのは総支払額などの大枠の収益額のみです。例えば「先月のAdMob収入は○○円だった」というように、Googleから支払われた総額を正確に開示することは規約上認められています
。一方、クリック数やインプレッション数、CTR、eCPMなど細かな成果指標は全て機密情報に該当し、具体的な数値をブログやSNSで共有することは禁止されています
。「○○万PVで△△円稼いだ」といった概算程度でも、CTR等が類推できる場合は注意が必要です。グラフや表を一部隠して公開する場合でも、非公開とすべき指標が読み取れないよう十分マスキングする必要があります（推奨はされません）。
- 規約の該当箇所・根拠: Google AdMobはGoogle AdSenseのポリシーを踏襲しています。**AdSenseオンライン利用規約 第11条（秘密保持）で「Googleの事前承諾なくGoogle機密情報を開示しない」ことに同意する旨が定められており、「Google機密情報」には「本サービス（AdSense/AdMob）に関連してプロパティのパフォーマンスに関するクリック率その他の統計」**が含まれると明示されています
。この条項が、クリック率や収益レポートの詳細を公開することを禁じる根拠です。また同条項には例外として「Googleから支払われた総支払額について正確に開示すること」は許容されると記載があります
。以上をまとめると、AdMob/AdSense管理画面上の統計データは全面的に非公開が原則であり、公開してよいのは累計や総額程度に限られるということになります。
- 注意点・リスク: AdMobの機密情報を漏洩すると、アカウント停止や収益の没収といった厳しいペナルティが科されるリスクがあります。Googleはポリシー違反に対して非常に厳格で、特に収益やクリック率などの漏洩には即座に対応します。過去にはAdSense利用者が詳細な収益をネット上で公開した結果、アカウントを無効化された例も報告されています。収益公開は読者の関心を引きますが、公開して良い範囲（総額など）に留めることが肝要です。また、仮にスクリーンショットを公開しなくても、言及する内容によっては機密情報の開示と見なされる恐れがあります。例えば「クリック率が◯%」と文章で書くこともNGです。遵守すべき事項を破ると、最悪の場合今後Googleの広告収益を得られなくなる可能性がありますので十分注意してください。
Google アナリティクス（Google Analytics）
- スクリーンショット公開の可否: 基本的に許可されています。Googleアナリティクスの利用規約には、レポート画面の共有を禁止するような項目はありません。収集した解析データはサイト運営者自身のものであり、Googleの機密情報ではないためです。事実、多くのサイト運営者が自社サイトのアクセス解析結果をブログ記事で公開していますし、Googleも公式にそれを制限していません。ただ、一部に「GAのスクショ公開はNGでは？」という噂があったため確認されたことがありますが、Googleの担当者も「AnalyticsおよびAdSenseともに、掲載してはいけないという規約上の部分はない」と回答しています
。このようにGA単体のスクリーンショット公開は禁止されていないと言えます。但し、後述のようにAdSense等他のサービスと絡む場合は注意が必要です。
- データ公開の可否: 自由に公開可能です。Google Analyticsで得られるページビュー数（PV）やユーザー数、セッション時間などの集計データは公開して問題ありません。これらは自社サイトの運営指標であり、サイト運営者が好きに利用・公表できる情報です。実際、Web業界では自サイトのアクセス数やユーザー属性データを公表してマーケティングに活用する事例も多く、GA利用規約でもそれを禁じる記述はありません。また、GAのデータは個人を特定できない統計情報として提供されるものなので、プライバシーの観点からも匿名化された集計値の共有は問題ありません（そもそもGA利用規約で個人情報を収集しないことが義務付けられています）。グラフや数値をブログに載せたり、他の分析資料と組み合わせて公開しても差し支えないでしょう。
- 規約の該当箇所・根拠: Google Analyticsの利用規約には主にプライバシー保護やデータの適切な使用に関する条項がありますが、AdSenseのような機密保持条項は存在しません。例えばAdSense規約ではCTR等を機密情報と定義していました
が、Google Analyticsではそういった定義づけはされていません。実例として、Google担当者への問い合わせでも「載せてはいけないという部分はない」と明言されています
。ただし注意点として、AdSenseとの連携です。GAとAdSenseをリンクさせている場合、GA上にAdSenseのクリック率や収益などが表示されることがあります。このようなAdSense由来の指標は依然としてAdSense規約上機密情報です
。したがって、たとえGAの画面でもAdSenseデータが含まれる部分を公開すると規約違反となります。この点を除けば、GAデータ公開を制限する規約上の根拠は特にありません。
- 注意点・リスク: AdSense等他サービスの機密情報との混同に注意してください。前述の通り、サイトにAdSense広告を設置している場合やAdMob連携アプリの場合、GA画面に広告収益関連の統計が含まれることがあります。それらをうっかり公開するとAdSense/AdMob規約違反となり、広告アカウントに悪影響が及ぶ可能性があります。それ以外でGAデータを公開すること自体に対するGoogleからのペナルティは通常ありません。ただ、Googleのブランド資産利用ガイドラインに従い、スクリーンショットを改変しない・サービスの正式名称を記載するなどの基本ルールは守るべきです
。また、GAの数値を恣意的に加工して誤解を招く形で発信した場合、読者や取引先からの信頼を損ねるリスクがあります。総じて、GAのスクリーンショットやデータ公開は比較的自由ですが、含まれる情報の性質を見極めて慎重に扱うことが重要です。
Firebaseコンソール
- スクリーンショット公開の可否: 概ね許可と考えられます。FirebaseはGoogle提供の開発者向けサービス群であり、そのコンソール（管理画面）は開発者本人しかアクセスできないものの、画面自体を公開してはならないという一般条項はありません。実際、Firebaseコンソールのスクリーンショット（例: プッシュ通知の設定画面など）をブログ記事で紹介している例も数多く見られ、Googleがそれを禁止しているという情報はありません。従って、Firebaseコンソールの画面キャプチャを説明目的で共有すること自体は許容範囲です。もっとも、FirebaseにはBeta版機能や非公開プロジェクトも存在するため、まだ公開されていない新機能画面などは共有しないよう留意してください（それらはGoogleから機密扱いされている可能性があります）。
- データ公開の可否: 自由に公開可能です。Firebaseコンソールで得られる自アプリの各種データ（例: Firestoreの利用量、Crashlyticsのクラッシュ統計、利用者数の推移など）は開発者が活用できるデータであり、必要に応じてブログやレポートで共有して問題ありません。これらの数値は自社サービスの運用情報であってGoogleの営業秘密ではないためです。実際、Firebase公式でも導入事例として特定アプリの指標改善をグラフ付きで紹介するケースがありますし、開発者コミュニティでも自分のFirebaseデータを公開すること自体は容認されています。公開する際は機微情報（例えばユーザーの個人情報やセキュリティ上の秘密データ）は含めず、統計情報や設定例の共有に留めるのが望ましいです。
- 規約の該当箇所・根拠: Firebase自体の利用規約（Google Cloud利用規約の一部として適用）に、管理画面の情報公開を直接禁止する条項はありません。Firebaseの各サービス利用規約やデータ処理規定は主にプライバシー保護やセキュリティに関するもので、スクリーンショット公開に関する制限規定は見当たりません。例えばFirebaseの一サービスであるCrashlyticsの利用規約を見ても、機密情報の扱いは自社アプリのクラッシュデータ分析結果を外部に漏らさないように、といった文脈です。Firebaseコンソール画面そのものはGoogleの商標や著作物でもありますが、Googleはブランドガイドラインで「Googleのサービス画面のスクリーンショット利用は、サービスを説明する目的であれば許可される」旨を示しています
。このガイドラインに従う限り、Firebaseの画面共有も問題ないと解釈できます。
- 注意点・リスク: Firebaseコンソールの共有で気をつけるべきは、セキュリティとプライバシーです。他者に見せることを想定していない管理画面には、APIキーやプロジェクトID、ユーザーのメールアドレスなど公開すべきでない情報が含まれることがあります。スクリーンショットを公開する際は、そうした機微情報をマスキングするか、写らない箇所だけを切り取るようにしてください。また、Firebaseの中には利用者限定プレビュー（Alpha/Beta機能）が提供されることがありますが、それらには個別の利用条件が付随し、外部開示を控えるよう求められるケースもあります。万一Firebase関連で公開NGの情報を漏えいした場合、Googleからプロジェクトの利用停止や契約違反としての措置を取られる可能性があります。しかし通常の範囲でデータや画面を共有する分にはそのようなリスクは低く、むしろ開発事例の共有としてコミュニティで歓迎されるでしょう。結論として、一般公開されていない秘密情報を含まない限り、Firebaseコンソールのスクリーンショットや一部データの公開は問題なく行えます。総じてGoogleの定めるガイドラインを守りつつ、安全に情報発信することを心がけてください。
参考文献: Unity 利用規約
、Google ブランド資産利用ガイドライン
、Google Play Developer API 利用規約
、Apple Developer Program License Agreement
、Google AdSense（AdMob）オンライン利用規約
、有志による規約解説ブログ
など。
ログ
監督たちの甲子園 世紀の逆転劇 戦略指針
知り合いにこのゲームをテストプレイしてもらったときに、
「めっちゃ楽しい。遊び方が分かればやけど。」というコメントをいただきました。
確かに、一見すると複雑怪奇なシステムのため、全体像を把握するのは困難です。
ただ、作者自身は「簡単なシステムを組み合わせているだけ」と考えています。その視点から、監督たちの甲子園を、深く楽しむためにはどんな論点で何を考えるべきかを解説します。
簡単な一言 → 各要素に対していえる一言 → その他と、少しずつ深めて記載していきます。
ゲームはこちら
目次
簡単なまとめ・・・最低限知っておきたい考え方はこちら
育成チェックリスト・・・強くなるために必要なことをできているか確認しよう
各要素に対して言える一言・・・より細かい各要素に対して、何を考えておくべきか書いたものがこちら
簡単なまとめ
・試合は敵より1点でも多くとれば勝ち。一つ一つの指示に得点期待値を考えて動きたい。
・指揮はじゃんけん。自分が得意な作戦か、敵から見ると選んだら嫌な作戦か、メリット・デメリットを考えて動きたい。
・バランス型選手は結局使いづらい。育成には運はあるものの、「どんな特徴を持つ選手を育てたいか」を考えておきたい。
・ユーザー甲子園の強いチームを参考にしよう。真似したら強くなれる。
育成チェックリスト
- 各選手の得意・不得意を踏まえて打順(攻撃)を組めているか
- 各選手の得意・不得意を踏まえて守備を組めているか
- 投手はタイプの違う選手が複数存在するか
- スーパーサブが存在するか
- 練習Gは適切に分け、状況により入れ替えているか(そのままにしていないか)
- 育成方針を決めているか
- 学年ごとの育成状態を加味して練習Gを設定しているか
- スキルを漏れなく設定しているか
- 起用法設定をしているか
打順で前のほうに良い打者を揃えているでしょうか？
同じような弱点を持った打者を並べていないでしょうか？例えば、速球が苦手(反応が低い)選手ばかりではないでしょうか。対人戦では、選手交代で弱みを突いてくるチームが多いです。
守備の要として、センターライン（投手・捕手・二塁手・遊撃手・中堅手）が特に打球が来やすいです。
投手はもちろん、センター(中)・セカンド(二)・ショート(遊)にかなり打球が飛んできます。彼らは守備力の高い選手であり、かつ送球も高い選手でしょうか？
センターに良い選手を置くことで、敵の平均打率を2分(2%)以上落とせることが分かっています。対戦相手全員が打率3割の打者でも、たった一人の活躍で2割8分に落とせるのは大きいでしょう。
捕手は肩を高くしないと、盗塁が自由にできてしまいます。
育成では、エース1人で投げ抜いて勝利することが可能です。
ただ、対人では少しでもHPが減ると厳しいので代役が必要です。
他の観点として、敵の弱点を突きましょう。
速球が苦手なチームには速球投手、変化球が苦手なチームには変化球投手、一発長打が怖いチームには制球投手を繰り出すことで抑えやすくなります。
何かに極端に特化している選手を、ベンチ入り18人のうち2~3人入れておくことで戦術の幅が広がります。
特に、点が欲しい時の代打・代走、1点を守りたいときのセンターラインへの守備固めが大きなキーとなります。
練習では、能力値はSあたりまで上がりやすいです。
ただ、それ以上になると上昇にマイナス補正があるようです。
そのため、入学時点でどの選手をどのような方針で育てるかある程度決めておいたほうが良いです。
例えば、捕手向けなら「強化方針は肩全振りなので、練習は反応と長打を上げよう」みたいな感じです。
反応がSまで上がったら(だいたい2年中盤～後半で切り替え)、長打に切り替えることになると思います。
コーチの指導がうまくいけば、2年前半でもS行けたりするんですが…そこは運ですね。
よく悩むのは、投手は体力を伸ばしてから育成するかどうかですね。
体力を伸ばせば、体力回復の必要回数が少なくなる分効率がいいことはわかっているものの、勝てない投手になる場合が多くて…。orz
練習では、能力値はSあたりまで上がりやすいので、育成方針はそれ以降を伸ばすのにうってつけです。
育成方針で能力が伸びるのは「試合に勝利」が前提となるので、試合前にはきちんと何を育成したいか決めておきたいですね。
例えば、現3年は反応が全員Sに到達しており、反応の練習が必要ないとします。
ただ1・2年生はまだまだ育成の余地があります。
投手・野手で練習Gを1つ使うとして、最大であと1つしか練習Gがないので「何の練習を選択すべきか？」ということですね。
3年野手は長打や走塁になるでしょうが、1・2年野手向けに反応の練習をすべきでしょうか。
それとも、捕手や守備固め育成のために使うべきでしょうか…？
育成では、スキルLvが試合の勝利によって向上していきます。
1年秋からスキルを付与して、2年春・2年夏連覇、3年春連続優勝でスキルLv10になるくらいです。
そのため、1年秋には必ず全員分(ある分の)スキルを付与しておきましょう！！
対人戦では、全OB/OG選手に継承スキルを付与していない方を多く見かけます。
おすすめ設定でもよいので付与しましょう！勝率が変わってきます。
全く設定していないよりもおすすめ設定、おすすめ設定よりも選手に合わせた設定が強いです。
おすすめ設定だと能力に応じて配球・配球コース、打撃方針が決まってしまいます。
特に投手・・・特化型投手は強みにしている球種を多投するように自分で調整したほうが良いかと思います。全然違います。
コントロールが悪い投手はストライク中心がいいと思います。球数が多くなって、HPが削られて、失投で失点が多すぎます…。
各要素に対して言える一言
チーム
1人の選手が強くても勝てない。
強いチームを作るにはそれぞれの弱点を補うべし。
特定のチームに勝ちたいなら、相手の弱点を研究すべし。特にスキルを合わせると勝ちやすい。
（例：対デバフチームには、無畏(投手)、洞察(野手)で固める）
選手
万能型(器用貧乏になりがち)より特化型を育てよう。野手も含め体力が意外と重要。
指揮
速球 vs 反応、変化球 vs 巧打のように、選手の相性を理解しておきたい。
その時の確実性(期待値が高いもの)を取るか、1本に絞って運否天賦するか。
監督
指揮能力(能力UP)は1つに特化してもよくないので、育成パターンに合わせてバランス型にすべし。
コーチ
コーチも万能型より特化型。
5人がすべて同じ能力が高いとその能力を育成できない無駄になる期間があるので、育成パターンに合わせてバランスをとるべし。
学校
施設LvはALLMAX。ただLv3~4でも十分なステータスはある。
持てるリソース(時間・資金)を十分かけて、いかに効率よく能力値を上げる場を提供するか。
育成で考えたいこと
狙ったステータスアップがうまくのった選手をいかに手に入れるか
育成は確率に支配されているので、ベースの能力が高くても伸びない選手が出てきます。
期待値としてはベースの能力が高い選手のほうが高いですが、実際はそうはなりません。
能力のバランスはどうか
総能力値の最大値はどうしても天井があります。(よくある育成ゲームのように)ALLMAXにはなりません。
そのため、どこかを上げればどこかが下がります。どこを上げ、どこを下げるべきでしょうか？
投手は特に、「ステータスが高ければ強い」というわけではありません。
速球と変化球の球速差・変化量で、打ち取りやすい絶妙な値が存在するようです。
初期の投手が打ちにくいのもコレです。
打撃能力のバランスはどうか
野手の打撃能力は特に考える必要があります。
なぜなら、「反応・巧打・長打・走塁のいずれか2つを上げるか」という四者択二(二者択一のようなもの)があります。どれを上げるべきでしょうか。
ただ、アンチパターンがあり、反応＋巧打または長打＋走塁はダメです。
反応＋巧打がダメな理由は、「打てても、飛ばない・走れない」だと単打マン(得点期待値低)になりかねないからです。
長打＋走塁がダメな理由は、「よく飛ばせて走れるけど、当たらない」だと三振王になります。orz
特に、速球が特に強いため、反応と速球に差があるとほとんど当たりません。(ただ、当たったら飛ぶんですよね。)
そのため、反応を上げることが中心になると思いますが、変化球に対応できないと作戦「変化球中心」で打てません…。そのように、どこを取ってどこを下げるかが大事です。
その選手を使うべきタイミングは明確か
ストーリやユーザー甲子園を含め、選手登録数は18人のみです。
どのタイミングで使うべきかはっきりしない、他の選手と特徴が被っている選手は使いづらいです。
特徴が被っている選手が多くいるとなると、すぐに次の良い選手が見つかりやすいですし…。
その選手の弱点は何か、どういうシチュエーションが苦手か
各選手や所有スキルにはメタ(弱点)となるものが必ず存在します。
苦手なシチュエーションを把握していれば、起用法に効いてきます。
NPC状態でもチームが機能するか
ユーザー甲子園を含め、対人戦では敵プレイヤーから挑戦される場合はこちらのチームはNPCとして対戦します。
その際、NPC操作でも勝てるように起用法をしっかり組んであるでしょうか。
弱点を突かれる時間の少ない継投や野手起用など、考えられているでしょうか。
例えば、(1)代打・代走を多くする、(2)体力を高い状態を維持するですね。
「速球だけ」など1種類の能力のみ上げているチームに対し、弱点をさらす時間を減らすために(1)をします。
(2)は、野手も「試合中に体力が減っていくので、能力が落ちていくこと」を防ぎます。
(2)の類型として、投手の交代枠を増やすもあります。投手のHPが落ちない(70%以上)ようにすると、マジで打てません。
ただ…その枚数分選手を育てるのが大変だったりします。
スキルのシナジーを考えよう
スキル同士の組み合わせにより、想定外に強い選手を作ることができます。
例えば、無畏や洞察はデバフ無効です。
捲土重来は1~6回は打撃デバフを味方全体にかけますが、7回以降はバフに変わります。
洞察＋捲土重来と組み合わせると、1~6回のデバフが無効化されます。
例えば、3～4番にチャンス〇＋走者一掃の選手を採用します。
そうすると、走者が2人以上居ると驚異的なバフ量＋自動発動(発動数制限なし)となります。
例えば、代打専門の打者にチャンス〇＋洞察の選手を採用します。
そうすると、どんなタイミングでも、どんなキツいデバフがあっても、かなり良い成績を残せる代打になるでしょう。
上記のように、シナジーを持つスキルの組み合わせがあります。
そのため、そのようなスキルの組み合わせをベースにチームを組んでいくと強いです。
ただし、そのメタ(弱点)として、対策スキルが存在します。
自軍バフ盛りチームに対しては、洞察＋捲土重来の組み合わせではバフ量が負けてしまうため、勝てないかもしれません。
洞察は、敵チームにデバフを与えるささやき戦術には強いですが、自チームや自身を強化するスキルには全く影響力を示せません。洞察自体のバフ量は多くないので、単純に常時弱いバフがかかっている無駄な存在にもなりえます。。
バランスを見ながら、どのスキルが強いか試していきたいですね♪
作者コメント
少しずつ書いていきますね( ^^)/
育成のポイントを追記してみました。(25/04/26)
Unityで”Class” is missing the class attribute ‘ExtensionOfNativeClass’が発生する原因がわからない ⇒ Easy Save3でした
はじめに
通常、”Class” is missing the class attribute ‘ExtensionOfNativeClass’というエラーが出る場合は、【Unity】’【クラス名】’ is missing the class attribute ‘ExtensionOfNativeClass’!が発生するで解決できます。
ただ、Easy Save3が入ったプロジェクトであると原因がわからない。
「関連するスクリプトがアタッチされていないのに、なぜか当該エラーが発生する…」と。
原因
シーンにあるES3 ManagerのReferencesの中に、”Class”に関するデータが残る。
Editorから、当該SceneのES3 ManagerをRefreshしてもOptimizeしても何も変化がありません。これも原因といえばそう。私のイメージするRefreshは削除→再作成しないとできません。
対処方法
当該シーンにあるES3 Managerを削除し、再度作成します。
エラーの起こし方(例)
1. ES3 Managerを導入
2. Log(当該クラス)にScriptableObjectを継承して、test.Scene(当該シーン)のGameObjectにアタッチしたスクリプト(XXX.cs)にアタッチする。
Log.cs
public Log : ScriptableObject {
...
}
XXX.cs
public Log myLog;
3. ES3 ManagerにXXX.csをアタッチしたGameObjectが(勝手に)保存される
4. 設計変更をして、LogからScriptableObjectを外す。当然、XXX.csからもLogの記載を削除する。
Log.cs
public Log {
...
}
test.Scene(当該シーン)で、ES3 Manager内のReferencesにXXX.csのLogクラスの記載が残っているのでエラーが出る
“Log” is missing the class attribute ‘ExtensionOfNativeClass’
感想
Refreshって言ったらRefreshだと思うじゃん！！
意味わからんやろこれ…(´Д⊂ヽ