新しいサービスやアプリのアイデアをどう調理するか
はじめに
最近、自分の中で明らかに変化が起きています。
バイブコーディングを続けているうちに、少しずつ技術的な理解が深まってきました。
1行1行のコードは読めませんが、何が起こっているかはメタ的に認知できるようになりました。
わからないことがあったら逐一Claude Codeに説明させていますし、調べずに使うのは性に合いません。
以前は「アイデアが浮かんだら、どんな価値を提供できるか」を考えるだけでした。
それが今は、バックエンドはどう構成するか、フロントエンドはどのフレームワークで作るか、技術的に実現可能かどうかまで自分で考えるようになっています。
想像している機能が本当に作れるのかを検証し、AIと壁打ちして詰めていく。
そのサイクルが回るようになりました。
そんな中、新しいサービスのアイデアが降ってきました。
今回はそのアイデアからどうやってサービスの骨格を組み立てたのか、試行錯誤の過程をそのまま書いてみます。
きっかけは「他人に自分の性格診断をやってもらったらおもしろい」
「自分になりきってMBTI診断をやってもらうと、自己認知と他者認知のズレがわかる」
──そんなアイデアが出発点でした。
上司や部下からの認知と自分の認知のギャップを自覚するのに使えそうだな、と。
これが16gap.me──性格タイプの「ギャップ」を可視化する診断サービス──の原型になります。
3つのAIとの壁打ちで思考を練る
アイデアが浮かんだら、まずManus.aiで調査します。
同じ質問をGensparkとClaudeにも投げます。
やり方はこうです。
3者の調査結果や意見を読んだうえで自分の考えをまとめ、それをまた3者に同時に投げます。
AIからの回答で思考を拡散させつつ、自分が導いた答えを投げ返して収斂させる。
そしてまた同じ質問を投げて、新しい気づきを得る。
このラリーの繰り返しで、アイデアの解像度がどんどん上がっていきます。
サービス設計の思考フロー──詰まっては聞いての繰り返し
壁打ちの中で考えたことを、詰まったところも含めて振り返ります。
まず「このサービスでどんな価値を提供できるか」「先行事例はあるか」を調べました。
他者認知と人間関係の関係性については先行研究も多いですし、性格診断サービス自体は無数にあります。
ただ、MBTIで「他者から見た自分のタイプ」を主軸に扱うサービスは、国内にはほとんど見当たりませんでした。
自己診断ツールはたくさんあっても、「他者認知とのギャップ」にフォーカスしたものは空白地帯。
ここに入り込む余地があると判断しました。
次にサービスの価値の本質を定義しました。
「本人のタイプ」と「回答者が思うタイプ」を入力し、「その差からわかること」を出力する。
シンプルですが、これが核になります。
ここで「レポートの主体は誰か」という問いにぶつかりました。
本人に対するレポートなのか、それとも入力者（回答者）に対するレポートなのか。
回答者に寄せると「あなたはこの人をこう見ていますよ」という内容になりますが、それだと回答者側のメリットが薄い。
一方、本人に寄せれば「周囲からこう見られていますよ」という気づきの提供になり、サービスを使う動機が明確になります。
主体は本人にあるべきだろうという結論に至りました。
収益化の方向性も考えました。
まずシンプルに個人向けにバズらせてサービス展開する線はあります。
ただ、正直そこからの収益化の出口が見えません。広告を貼る程度しか思いつかない。
一方で、企業の人事・研修にリーチできる可能性もあります。
ストレングスファインダーのような路線です。
チームビルディングや1on1の材料として「お互いの認知ギャップ」を可視化するパッケージにできれば強い。
個人向けでバイラルを起こしつつ、企業向けパッケージ化を出口として見据える。
スケールすれば収益化できそうだとわかった時点で、着手を決めました。
技術面の判断──わからないことはAIに聞けばいい
価値が定まったら、技術スタックを考えます。
この時点で自分の中では、SupabaseとNext.jsで作って、Stripe投げ銭を実装すればよさそうだなと思っていました。
AI APIも今回は不要なので、コストはSupabaseだけ気にしておけばよくて、月にせいぜい$10。
バズってもAPI破産は起こりません。リスクほぼゼロ、リターンは夢があります。
ここからが試行錯誤でした。
まず、ロールが2種類（本人と回答者）います。
全部一人で入力させるか、別々に入力してもらうか。
回答者が複数人いるパターンを考えると、別々に入力してもらうほうがいい。
そして別々にすれば匿名化もできます。
性格診断のギャップを正直に答えてもらうには、「誰が何と回答したか」が本人にバレない仕組みが必要です。
ここまでは自分で判断できました。
次に詰まったのが、ダッシュボードと回答の紐づけです。
会員登録させるのはユーザーにとって面倒ですし、かといって同じURLだと匿名性を担保できません。
自分の中では「会員登録させるか」「共有URLにするか」の二択でしか考えられず、どちらもデメリットが大きい。
どうしよう──と思ってAIに投げたら、3者とも「URLにユニークなトークンを埋め込めば、会員登録なしで紐づけできる」と返してきました。
なるほど、その手があったか。
二択だと思い込んでいたところに第三の選択肢を出してくる。
これがAI壁打ちの強さだと思います。
通知の仕組みも悩みました。
PWAやLINE通知など技術的にはいろいろできるらしいのですが、AIに聞いたら「MVPとしては普通にアクセスしてもらうのがいいと思うよ」と諭されました。
確かに、現段階ではそれで十分です。
そして回答用URLの設計を考えているうちに、もう一つの可能性が見えてきました。
回答者がURLを開いてギャップ診断に答える。
その回答完了画面で「あなたも自分のギャップを調べてみませんか？」と導線を置けば、回答者がそのまま次の利用者になれます。
利用者がSNSで回答を募り、回答者が新しい利用者になり、さらにその人がSNSで募る
──バイラルの流れが設計上作れることに気づきました。
それならバイラルを前提とした設計にしよう、と方針を切り替えました。
骨格が決まったら実装へ
大体こんな流れで、壁打ちしながらサービスの骨格を定めました。
3つのAIにサマリをまとめてもらい、mdファイルとして同じディレクトリに配置します。
Claude Codeに改めて読ませてプロジェクトディレクトリを開始し、概要を理解させたらCLAUDE.mdを作成させて詳細設計に入ります。
あとは普通に実装していくだけです。
振り返り──アイデアを調理するフロー
以前に比べて、フローが明らかに本格化してきました。
マーケティングやセールスの基礎知識がベースにあって、そこに技術の理解が追いついてきた。
完璧じゃなくてもAIに助けてもらえます。
わからなければ聞けばいい。詰まったら投げればいい。
今回のプロセスを整理すると、以下のようになります。
- アイデアの種を拾う──日常の体験や気づきから「これサービスにならないか？」を拾い上げる
- AI 3者に同時に壁打ち──Manus・Genspark・Claudeに同じ問いを投げ、拡散と収斂を繰り返す
- 価値の本質を定義する──「何を入力して、何を出力するサービスか」をシンプルに言語化する
- 収益化の出口を確認する──スケールしたときに回収できる構造があるか。なければ撤退判断もここで
- 技術で詰まったらAIに聞く──自分で判断できるところは判断し、詰まったら即座に投げる
- 骨格をドキュメント化して実装へ──AIにサマリを書かせ、CLAUDE.mdを起点に開発を始める
今後も一人の独立した個人開発者として、この路線を続けていきます。