診断サービスの拡張は、結果数を増やす作業ではなく、変更単位を小さくする作業です。 16タイプを64パターンに広げると、結果文だけでなく、URL、OGP画像、シェア文言、一覧の管理単位も増えます。
ここでは Love Character 64 を例に、ラブタイプ診断64 の結果を「64件のフラットな配列」ではなく「16 × 4 の合成モデル」として扱う設計を整理します。
なぜ64件のフラット管理がつらいのか
| 対象 | フラット管理で起きること | 後で困ること |
|---|---|---|
| 結果文 | 64件ごとに全文を持つ | 表現修正が全体に散る |
| 画像/シェア文 | 各結果で個別に設定する | 微修正のたびに漏れが出る |
| URL | 完了画面の状態に寄せる | 再訪や共有で復元しづらい |
| 一覧 | 結果配列を並べるだけにする | 分類や絞り込みが後付けになる |
結果をBaseTypeとSubTypeに分ける
まず、16個の基本タイプと4つの差分を別の設定として持ちます。
const baseTypes = {
LCRO: {
coreTraits: ["情熱的", "主導的"],
},
// ...
} as const;
const subTypes = {
VD: {
behaviorStyle: "気持ちを素直に表現しやすい",
},
// ...
} as const;
type BaseType = keyof typeof baseTypes;
type SubType = keyof typeof subTypes;
type ResultCode = `${BaseType}-${SubType}`;
ResultCode は、表示だけでなくURL、OGP画像、シェア文言を結ぶ共通キーにします。
const baseTypeKeys = Object.keys(baseTypes) as BaseType[];
const subTypeKeys = Object.keys(subTypes) as SubType[];
const resultCodes = baseTypeKeys.flatMap((base) =>
subTypeKeys.map((sub) => `${base}-${sub}` as ResultCode),
);
何を16単位、4単位、64単位で持つか
全部を合成に寄せると、結果が機械的になります。逆に全部を64件で持つと、修正が重くなります。
| 管理対象 | 推奨単位 |
|---|---|
| 基本性格・反応 | 16 BaseType
|
| 恋愛中の見え方 | 4 SubType
|
| URL slug | 64 ResultCode
|
| OGP画像キー | 64、または BaseType + SubType
|
| meta title | 64 |
| 注意書き・安全な距離感 | 全体共通、または4 SubType
|
つまり、合成は「文を機械的につなぐ」ことではなく、編集単位を分けることです。最終表示文は64通りでも、内部では BaseType.coreTraits + SubType.behaviorStyle + safetyNote のように参照元を分けておくと修正範囲を狭められます。
ResultCodeをURLから逆算できるようにする
診断結果を完了画面だけに置くと、共有先で「どの結果か」「再診断はどこか」が曖昧になります。Next.js の静的ルートなら、ResultCode からパスを作っておくと扱いやすいです。
function getResultPath(code: ResultCode) {
return `/lovecharacter64/${code.toLowerCase()}`;
}
export function generateStaticParams() {
return resultCodes.map((code) => ({
type: code.toLowerCase(),
}));
}
| パス | 役割 | 設計上の意味 |
|---|---|---|
/lovecharacter64 |
診断入口 | 初回利用と再診断の入口 |
/lovecharacter64/quiz |
回答画面 | 質問状態を閉じ込める |
/lovecharacter64/results |
結果一覧 | 64タイプ全体を探索できる |
/lovecharacter64/{resultCode} |
個別結果 | 例: /lovecharacter64/lcro-vd
|
実装例として、自作のラブタイプ診断64 では入口、一覧、個別結果を分けています。個別結果URLがあると、結果ページ -> SNS共有 -> 新規訪問 -> 一覧/再診断 の流れを作りやすくなります。
文言は生成ではなく管理単位を分ける
ラブタイプ診断64 を、恋愛タイプ診断 や 64タイプ恋愛診断 として読む人もいます。さらに「恋愛MBTI診断」「LoveType16診断」の近くで理解されることもあるので、公式診断や科学的判定に見せない線引きは必要です。
- 「必ず当たる」と読める表現にしない
- 相性や恋愛傾向を最終判定のように書かない
- 結果名だけでなく、距離感・甘え方・自由さなどの読み物にする
- OGP文、本文、注意書きのトーンを共通ルールでそろえる
実装前チェックリスト
- 64結果を1枚の巨大な配列としてだけ扱っていないか
-
BaseTypeとSubTypeの役割が説明できるか -
ResultCodeがURL、画像、シェア文言の共通キーになっているか - 公開URLの大文字/小文字ルールが決まっているか
- 一覧ページと個別結果ページの役割が分かれているか
- 診断文案が公式・科学的・断定的に見えすぎないか
型、URL、文言、導線を分けると、細かい体験を運用しやすくなります。