AI開発収益化ラボ
Spec Roulette

Spec Roulette ができるまで — 曖昧仕様が事故へ進化する瞬間を遊べるシミュレーターの設計

Spec Roulette ができるまで

「この仕様、なんか嫌な予感がする」

開発現場には、コードレビューより前に気づくべき違和感があります。
要件の日本語がふわっとしていて、会議では誰も反対していないのに、あとで全員ちょっとずつ違うものを想像していたとわかる瞬間です。

そこで作ったのが Spec Roulette。
曖昧な仕様メモと、現場あるあるのカオス要因を混ぜると、

  • PM がどう圧縮するか
  • デザイナーがどこを盛るか
  • 実装者がどこを勝手に一般化するか
  • バックエンドが何を後回しにするか
  • QA / インフラがどの時点で現実を見るか

を、タイムラインで一気に返す仕様事故シミュレーターです。

何を面白がるサービスなのか

このサービスの目的は、正しい仕様書講座ではありません。
むしろ逆で、

曖昧な一文があると、現場ではどれだけ自由に事故へ進化するか

を遊びながら体験できることを重視しました。

完成物としてはかなり変なサービスです。
でも、変だからこそ一発で伝わります。

  • PM 向けのネタになる
  • 提案前のヒアリングトークに転用できる
  • 開発チームの共通言語にしやすい
  • SNS で「あるある」として広がりやすい

このサイト全体の「アイデア発掘」の役割にもかなり合っています。

技術的な方針

今回は AI API を使わず、ローカルのデータと決定的ロジック だけで結果を生成しています。

理由は3つです。

  1. コスト承認なしで何度でも回せる
  2. 押すたびに世界観がブレない
  3. 誤読の質をこちらでコントロールできる

内部で持っているのは、ほぼ次の3種類だけです。

  • 元仕様のプリセット
  • カオス要因のプリセット
  • 役割ごとの誤読テンプレート

そこから briefId + specText + modifierIds を元にハッシュを作り、
どの事故タイトル、どの誤読チェーン、どのプロダクト名を返すかを決めています。

この作りだと、

  • 同じ条件では同じ事故が再現される
  • 条件を少し変えるだけで別世界線になる
  • ランキング保存と相性がいい

という扱いやすさが出ます。

スコアリングをどう作ったか

最初にハマったのはスコア設計でした。
雑に重みを足すだけだと、どんな入力でも 70 点以上になってしまい、サービスとして意味がなくなります。

そこで最終的には、次の4要素で分けました。

  • baseScore: 仕様事故シミュレーターとしての最低値
  • riskScore: 文章中の危険ワードや曖昧さ
  • chaosScore: 選ばれたカオス要因の重み
  • clarityBonus: 文章が具体的なほど下がる補正

イメージとしては、

damageScore = baseScore + riskScore + chaosScore - clarityBonus

です。

これで、

  • 仕様が短くて曖昧なら上がる
  • カオス要因を積むほど上がる
  • ある程度ちゃんと書くと下がる

という直感に近い挙動になりました。

さらに結果画面では、単に数値だけで終わらせず、

  • 元仕様の点
  • カオス要因で増えた点
  • 明確さで下がった点

を見えるようにして、「なぜその点数なのか」がわかるようにしています。

データ設計と API

永続化したいのはランキング用の最小情報だけです。
そのため DB テーブルもかなり薄くしています。

SpecRouletteRun
├── playerName
├── briefId
├── modifierIds[]
├── damageScore
├── disasterTitle
├── shippedThing
└── createdAt

Prisma では svc_spec_roulette_runs にマップし、
damage_score DESC, created_at DESC の複合インデックスを貼って、ランキング取得を単純化しました。

API も /api/services/spec-roulette/runs の1本だけです。

  • GET: 上位20件の取得
  • POST: バリデーション付きで1件保存

保存時に受け取るのは結果全文ではなく、一覧表示に必要なサマリだけ。
これで構造変更の影響も小さくしています。

UI をどうまとめたか

画面の役割はかなりはっきり分けました。

  1. 左で仕様を入れる
  2. 真ん中でカオスを足す
  3. 右で事故の予感を見る
  4. 下で誤読チェーンとランキングを眺める

特に気をつけたのは、「意味不明なネタページ」に見せないことでした。
初期案は世界観だけ先に立ってしまい、何をすると何が返るのかが伝わっていませんでした。

そこで最終的には、

  • 最初の一文で用途を説明する
  • 入力欄は余計なタブを消して単機能にする
  • カオス要因は加点カードとして一覧化する
  • 結果はスコア、生成物、事故タイトルに分解する
  • 誤読チェーンは横並びで因果が見えるようにする

という整理に振り切っています。

見た目も、ネタ感だけで押し切るより、
「ちゃんと使える診断 UI の上に少し狂った世界観が乗っている」くらいを狙いました。

SEO と公開導線

新サービスとして出す以上、遊びページでも SEO を雑にしないようにしています。

  • サービスページ専用 title / description
  • canonical 設定
  • WebApplication + BreadcrumbList の JSON-LD
  • サービス一覧と記事一覧への導線
  • 開発記事の同時公開

Spec Roulette は検索で勝つサービスではありません。
ただ、それでも「何のページか」を検索エンジンと SNS に正しく伝えることは、雑にしないほうが後で効きます。

今後の伸ばし方

このサービスはまだ広げられます。

  • 実在しそうな仕様メモの投稿機能
  • 誤読タイムラインの画像生成
  • 「受託あるある」「社内情シスあるある」などのモード分岐
  • AI で一文から事故連鎖を生成する拡張

特に最後は相性がよくて、
雑メモを入れると「その要件、3営業日後にこう壊れます」と返す体験まで持っていけます。

ただ、その段階に進むなら AI コスト見積もりとモデル選定は必須です。
今回はまず、ノーコストで回る面白い核だけを先に完成させました。

まとめ

Spec Roulette は、便利ツールではありません。
でも、

  • 一発で伝わる
  • 技術ネタとしても企画ネタとしても強い
  • このラボの「アイデア発掘」の役割に合う

という意味で、かなりこのサイトらしいサービスになりました。

曖昧な仕様は、人を自由にします。
そして自由になった解釈は、たいてい想像以上に遠くまで走ります。