『学園アイドルマスター』（学マス）の非公式攻略サイト、Hintlogを運営しています。
ゲームの攻略情報を扱うサイトでは、記事を増やすだけでなく、「どこから探すか」「その情報はいつ確認されたか」「自分の条件に当てはまるか」を伝える必要があります。これはゲームに限らず、製品比較やイベント案内など、更新が続くWebサイトにも共通する課題だと思います。
今回はHintlogの公開ページを例に、情報への入口、確認状況の表示、計算ツールの前提条件という3つの観点を整理します。学マスを知らない方にも伝わるよう、ゲーム固有の用語は補足します。
カテゴリー名と利用者の疑問を結び付ける
Hintlogのホームには、ガチャ予定、最強サポカ、レジェンドカード、リセマラ、キャラ一覧という入口があります。「サポカ」は育成を支援するサポートカード、「リセマラ」はゲーム開始時に目当ての結果が出るまでやり直すことを指します。
カテゴリーを考えるときは、それぞれがどの疑問に応えるかを言葉にすると、ページの役割を整理しやすくなります。
| 入口 | 対応させる疑問の例 |
|---|---|
| ガチャ予定 | 次のガシャはいつ開催されるか |
| 最強サポカ | どのサポートカードを優先するか |
| レジェンドカード | カードの条件や使い方を知りたい |
| リセマラ | ゲーム開始時に何を狙うか |
| キャラ一覧 | 特定のキャラクターの情報を探したい |
実際のホームでも「次のガシャはいつ？」のような問いを入口に添え、最新更新やクイックナビを配置しています。
ここで役割が異なるのが、更新順の一覧と目的別のナビゲーションです。前者は最近の変化を追う人、後者は知りたいことが決まっている人を助けます。両方を用意すれば、初めて訪れた人も再訪した人も、自分に合う入口を選べます。
日付だけでなく情報の確認状況も見せる
予定を扱うページでは、日付が新しいことと、内容が確定していることを分けて考える必要があります。
Hintlogのガチャ情報には、「公式確認」「開催日程の参考情報」「公式発表済み」「詳細は未確認」といった表示があります。発表の存在は確認できても、詳細がすべてそろっているとは限りません。その違いが見えれば、読者は情報の確かな範囲を判断できます。
情報確認日とJSTの表記も、予定を読む際の前提になります。海外から閲覧する人や、日付の境目で確認する人にとって、時刻の基準も判断材料になります。
同様のページを設計するなら、少なくとも次の項目を別々に扱うと整理しやすくなります。
- 開催期間：そのイベントがいつ始まり、いつ終わるか
- 情報確認日：掲載内容をいつ確認したか
- 確認状況：確定している範囲と、未確認の範囲
- 参照先：どの公式情報や資料を根拠にしたか
表示上も、日付と確認状況を近くに置くと、読者は両方を合わせて判断できます。更新日の文字列を表示するだけでは伝えきれない部分です。
計算ツールは入力項目の意味まで設計する
ガチャ予定ページには、「開催中」「次回予定」「引くか待つか」「ジュエル計算」という区分があります。
ジュエルはガシャに使うゲーム内の資源です。この計算ツールでは、目標回数に到達するまでに追加で必要なジュエルを求めます。入力するのは、所持ジュエル、使えるチケットの回数、獲得済み交換Pt、目標回数、1回に必要なジュエルです。
交換Ptは、この計算では1回につき1Ptとして扱います。また、チケットは枚数そのものではなく、利用できるガシャの回数として入力します。目標回数や必要ジュエルは、対象ガシャの条件に合わせて変更します。
計算の中心は次の式です。
追加必要ジュエル =
max(0, (目標回数 - 獲得済み交換Pt - チケット回数)
× 1回必要ジュエル - 所持ジュエル)
以下は仕組みを示す説明用のJavaScriptです。回数・Pt・所持数は非負整数、1回の必要数は正の整数として、入力を事前に検証する前提です。
function requiredJewels({
target,
currentPoints,
tickets,
jewels,
costPerPull,
}) {
const remainingPulls = Math.max(
0,
target - currentPoints - tickets
);
return Math.max(
0,
remainingPulls * costPerPull - jewels
);
}
例えば、目標200回、交換Ptが0、チケットが10回分、所持ジュエルが15,000、1回250ジュエルという条件なら、追加で必要なのは32,500ジュエルです。
ただし、この数字が意味を持つのは入力条件がそろっている場合です。チケットは同じ交換Ptの対象である必要があります。割引、無料分、有償限定などの条件をツールが自動判定するわけではなく、希望するカードを入手できる確率を示すものでもありません。
小さな計算ツールでも、式と同じくらい、入力ラベル、単位、適用条件の説明が重要になります。
計算結果の読み方と境界条件をそろえる
数値を返す機能では、「何を計算した結果なのか」が出力の近くで分かることが大切です。この例なら、答えは目標に届くための追加必要ジュエルです。
同様のツールを実装する際には、通常の入力に加えて、次の条件を確認すると意図を整理できます。
- 交換Ptだけで目標に達しているときは、追加必要数が0になるか
- 手持ちのジュエルで足りるときに、負の値を表示しないか
- 空欄や負数を、意図しない有効値として扱っていないか
- チケットの「枚数」と「回数」を取り違えない説明になっているか
入力の検証と結果の表示を一緒に確認することで、計算の前提と画面上の説明をそろえやすくなります。利用者が数値を入れられることに加え、その結果を正しく解釈できる状態まで考える必要があります。
事実と評価を分けて更新できる形にする
攻略情報には、公式に確認できる日程や条件と、運営者による評価・提案が混在します。
Hintlogの編集方針でも、公式情報に基づく事実と、編集側の評価・提案を分けて扱っています。確認していない内容まで新しく見せるように、日付だけを自動で当日に変更しない方針も示しています。
情報を更新するときは、「予定が変わったのか」「参照先が追加されたのか」「評価の前提が変わったのか」を分けて考えると、修正すべき箇所を判断しやすくなります。
Hintlogを通して考えたいのは、記事への到達から情報の確認、計算結果の理解までをつなぐ設計です。コンテンツの分類や確認状況の見せ方について、似た課題を扱っている方の工夫もぜひ教えてください。