プロダクト思考とソリューション設計
本章のガイド
学習内容
全体的に、アプリを作るための基本知識を学びます：アイデアの出所 → アイデアをアプリにする方法 → 使えるアプリから使いやすいアプリへ → AIの活用 → ユーザーの獲得。
- アプリを作るにあたって、どこから来たアイデアが信頼できるか？
- アイデアがあれば、どうやって実現可能なアプリに分解するか？
- 作った後、どうやって「良いアプリ」に判断し磨き上げるか？
- どの段階で、どのように合理的にAIを活用して価値を拡大するか？
- アプリがあれば、0から最初のリアルユーザーをどう見つけるか？
1. アプリを作るにあたって、どこから来たアイデアが信頼できるか
多くの人がアプリを作るといえば、まず十分に印象的なクリエイティブなアイデアを思いつくことだと反応します。だから毎日ランキングをチェックし、レポートを読み、様々な人気プロダクトを研究し、他人の成功ストーリーに注目して、いつか自分も特別に違うアイデアに出会えることを願っています。
しかし実際のところ、多くの人は本当のアイデアを持っておらず、単にアイデアがないことに焦っているだけです。また、最初から高いハードルを設定する人もいます：面白くなければ始めない、普通は失敗と同義だと思う。でも実際に少し進んでみると、長く安定して続くアプリの多くは、深夜に思いついたものではなく、具体的な生活シーンの中で、リアルな問題の周りに少しずつ育ったものだということに気づくでしょう。
だから、この章が解決したいのはスタート地点の問題です：どうすればアイデアを持てるのか？そのアイデアは本当に信頼できるのか？あなたが時間とエネルギーを投じて、それをリアルなアプリにする価値があるのか？
1.1 アイデアとは何か
まず、最も基本的でありながらもよく見過ごされる問題から始めましょう：アイデアとは一体何か。
日常会話で人々がよく言うアイデアは、多くの場合、非常に主観的な興奮です。道を歩いていて動画を見かけ、瞬間的にこの方向がすごくクールだと思い、「私も似たようなものを作れる」と心の中で思うかもしれません。あるいはパーティーで誰かが製品の使い勝手の悪さに文句を言い、あなたが「こういうのが自動的に全部やってくれるものがあればいいのに」と口を挟むかもしれません。この時、確かに曖昧な考えはありますが、実際に作れるものとはまだほど遠いです。
ここでは、少し厳密な基準を設けましょう。あるアイデアが以下の条件の少なくともいくつかを満たす場合にのみ、それを「アイデア」と呼びます：
第一に、明確なユーザー層に向けている必要があります。漠然と「全員」と言うのではなく、主に誰に使われるのかを明確に説明できる必要があります。大学生、新入社員、子育て中の親、それとも独立開発者、EC事業者、小規模企業のオーナー。異なる人は同じことに対して全く異なる関心を持っており、ターゲット層さえ決まっていなければ、その後のすべての判断が宙に浮いてしまいます。
第二に、具体的なシーンに根ざしている必要があります。このアプリはユーザーがいつ使うのか、朝の通勤電車の中、仕事の合間、寝る前、週末の資料整理の時。ノートやタスク管理のような一見抽象的なツールであっても、よく観察すれば、高頻度で使われる部分は必ず特定のシーンと密接に結びついています。
第三に、ユーザーが明確なタスクを完了するのを助ける必要があります。タスクは大きくなくても構いませんが、説明できる必要があります。一日のToDoリストを整理する、長い記事をいくつかの要点にまとめる、会議のための構造の明確な議事録を生成する、あるいは週末の都市散策のための実行可能なルートを生成するなど。タスクを具体的に説明できれば、後の機能設計と価値評価が容易になります。
第四に、現状よりも良い方法やツールを提供する必要があります。ユーザーが元々どのようにこのことを完了していたのか、頭で覚える、紙に書く、Excel、スクリーンショットで保存、それとも異なるアプリ間を行き来するのか。あなたが提供できるのが、明らかに手間が省けて、安定して、快適な方法であれば、そのアイデアは真に価値を持ち始めます。
上記の思考について、うまく整理できなくても大丈夫です。今はAIの時代です。上記の内容を完全なプロンプトに整理し、あなたのアイデア、ターゲットユーザー、使用シーンをまとめて書き込み、LLMに補完と洗練を任せることができます。モデルを常にオンラインのプロダクトパートナーとして扱い、繰り返し対話、質問、修正することで、曖昧な概念を具体的にすることができます。
1.2 アイデアとユーザーニーズ：自己満足を避ける第一の防衛線
多くの人が初めてアプリを作る時に最も陥りやすい罠は、自己満足です。自己満足とは、自分のアイデアに夢中になり、世界を変革する方向だと感じているのに、一般ユーザーに話すと反応が冷静で、礼儀正しく頷きながらも「いいですね」としか言わず、製品がリリースされてもダウンロードも長期利用もされないことです。
この状況を避けるには、アイデアとユーザーニーズを分けて考える必要があります。
まずユーザーニーズとは何かを話しましょう。比較的簡単な言葉で要約できます：具体的なシーンにおいて、ユーザーが目標を達成するために、下げたい様々なコスト、または増やしたい様々な価値。 ここでのコストは、お金だけでなく、時間、労力、精神的負担、ミスのリスク、さらには社交的なプレッシャーも含まれます。
このことを理解すると、単なるかっこよさだけではニーズを構成できないことがわかります。多くのアイデアは確かに十分に斬新ですが、ユーザーが特定の目標においてより省力的に、より安心して、より自信を持てるようにしない限り、真に持続可能なアプリを支えることは困難です。
アイデアとニーズの間には、よく見過ごされる溝があります。アイデアはあなたの主観的判断を表し、データによる裏付けではありません。 ニーズは、ユーザーが実際に何を経験し、何に悩んでいるかを表します。
アイデアを判断する際、簡単な区別方法があります。真のニーズか偽のニーズかを見ることです。真のニーズの明確な特徴は、あなたのアプリがなくても、ユーザーが積極的にこの問題を解決しようとしていることです。
偽のニーズの典型的な状況はまさに逆です。あなたが積極的に提起しなければ、大多数の人はそれが問題であることに気づきません。
だから、自己満足を避ける第一の防衛線はユーザーニーズを理解することです。 最初に、「自分以外に、このことで真剣に悩んでいる人は誰か」という一見簡単だが非常に重要な質問に答える必要があります。
1.3 良いアイデアが良い理由
すべてのアイデアが同じ運命を辿るわけではありません。良いアイデアは、数日で粗いがプロセスが通るバージョンを作っても、自然に少数のリアルユーザーを引き付けます。悪いアイデアは、機能を詰め込み、広告にお金をかけ、様々なプラットフォームで宣伝しても、最終的に外力で一時的にデータを積み上げるだけで、すぐに静寂に帰します。
この背後にある最も本質的な違いは、アイデア自体が重要な問題点に触れているかどうかです。
良いアイデアは、自然に成長を迎えます：非常に質素な形態で登場しても、ユーザーの手元の具体的な小さな問題を解決できれば、ある程度の自然な成長を得ることができます。例えば、音声を素早くテキストに変換する小ツールは、最初はウェブページに数個のシンプルなボタンがあるだけかもしれませんが、認識品質が良ければ、多くの人がリンクを友人に転送するでしょう。
悪いアイデアは、最初から外力駆動に依存することになります。外見が良くても、継続的にプッシュしなければならず、ユーザー獲得の努力を緩めると、使用データは急降下します。
もちろん、上記の状況は絶対ではありません。例えば初期市場ではユーザーが価値に気づくまで一定の遅延がある場合や、競合がある場合は外観、操作の難易度、ブランド特性などを考慮する必要がありますが、これらはより深い内容であり、当面は考慮しません。
選択は努力より重要です。
1.4 良いアイデアの出所：4つの主要な出所と具体的な例
多く人がアイデアを思いつくとき、机の前に座って天井を見つめ、いつかインスピレーションが突然降ってくるのを待つ姿を想像します。しかし現実の良いアイデアは、生活の中の小さな観察、コミュニティでの繰り返しの質問、インターネット上の山のような不満、そして既存のプロダクトから少しずつ選別されるものです。
以下の4つの出所から、真剣に取り組めば、スタートできる方向を容易に見つけることができます。
自分の生活を愛する
非常に素朴ですが効果的な原則があります：生活に参加すればするほど、問題を発見しやすくなり、何が解決する価値があるかを判断する能力も高まります。 参加感とは、画面越しに他人の生活を見るのではなく、自分で体験し、試し、失敗することです。
例えば、猫を飼うのが好きなら、猫と一緒に過ごす一日は、100件の「猫の飼い方のコツ」を見るよりも情報量が多いです。毎回の少し不快な体験は、潜在的なプロダクトの手がかりです。
猫を写真に撮ることについて考えてみましょう。多くの人が経験したことがあるでしょう：スマホをかざしても猫は絶対にカメラを見てくれない。下を向いて爪を舐めるか、別の隅を見つめている。だったら、スマホやタブレットの画面に自動で動く赤い点、羽、小さな虫のアニメーションを表示して、猫の視線を引きつける小ツールがあってもいいのでは。シャッターボタンを押すと、フロントカメラの近くで自動的に一周動いて、猫の視線をカメラの方向に「騙し」、ついでに連写して、その中からはっきりして見栄えの良いものを選ぶ。さらに一歩進めば、このアプリは各猫がどの色、どの移動軌跡に最も興味を持つかを記録し、次回は自動的にその猫の「専用」遊びモードを使って成功率を高めることができる。
メイクやスキンケアを楽しむなら、家のキャビネットに並ぶ製品一つひとつの背後には、大量の試行錯誤と意思決定があります。スマートフォンのアルバムで毎回のメイクの写真を撮る習慣があるかもしれませんが、振り返る時に、その日どの口紅、どのアイシャドウを使ったかを少しずつ思い出す必要があります。これらの情報を体系的に記録して、自分だけのメイク図鑑にできるかどうか。さらにアプリに統計を取らせて、特定のメイクがどんな場面で最も使われているか、どの組み合わせが写真で最も良い表現になるかを把握できれば、次にメイクを選ぶ時にゼロから考える必要がなくなります。
もう少し具体的に、多くの人が経験するシーンを考えてみましょう。朝の時間がとても急で、アルバムを開いて「前回の成功した通勤メイク」を探そうとしても、長い時間探した末にその時どの製品を使ったか思い出せない。だったら、メイクの写真を撮った後、スマートフォンに向かって「今日は面接メイク、01番のオレンジブラウンアイシャドウとローズベージュのリップを使った」とだけ言えば、アプリが自動的に認識して「メイクレシピ」を生成し、写真と結びつける機能があってもいい。次回は「面接」「オレンジブラウンアイシャドウ」「ローズベージュ」で検索するだけで、関連するすべてのメイクがワンタップで表示され、「今日は通勤に適した、5分で完成するメイクだけ見る」というレコメンドリストも自動生成される。毎朝節約できる数分は、非常に具体的な「解決された問題」です。
City walkや各種のスロートラベルが好きなら、すでに様々なツールを使って体験を組み立てているかもしれません：地図アプリでルートを記録し、メモ帳に行きたいカフェをリストアップし、アルバムに沿道の写真と感想が散在している。では、ルート、チェックインスポット、写真、テキストを一つにして、タイムラインとストーリー性のあるウォーキングログにできるアプリは作れないか。さらに、そのルートをワンタップで友人にシェアし、同じ都市で違うバージョンを歩けるようにする。
さらに日常的な小さなディテールを掘り下げてみましょう。多くの人がcity walkの時に、「その角がとても美しいと思ったのに、家に帰って地図で全く見つけられない」という挫折感を経験しています。超軽量な機能を作れないか。歩いていて感覚のある角に来たら、イヤホンのボタンを長押しして、「ここにマーク、デート散歩に適した道」と言えば、アプリが瞬時に現在地に音声付きのマークポイントを落とし、時間、天気、騒音レベルを自動記録する。後で自分や友人がこの都市の地図を開くと、「通行者実測の雰囲気スポット」が見える。一人でぼーっとするのに適した場所、夜景を見るのに適した場所、友達と歩きながら話すのに適した場所。本来「歩き過ぎて忘れる」小さな角が、このように徐々に質感のある都市体験データベースに育っていく。
これらの例が説明したいのは一つのことだけです：自分の生活を愛する必要がある。生活が最高のアイデア出所です。 毎日遭遇する困惑、その場で思いついた応急処置、少し面倒だけど我慢してきた場所。これらに少し多く目を向け、小さなツールで改善できるかどうかを考えてみれば、すべて未来のプロダクトの原型になり得ます。
自分が持つユーザー資産から発掘する
ユーザー資産とは、簡単に言えば、あなたがすでにリーチできる人々のことです。読者、運営するコミュニティ、会社の同僚グループ、長期参加している趣味コミュニティなどです。一部の人々が日常何を話し、何に悩み、何を期待しているかを安定して聞けるチャネルがあれば、ゼロから始める人よりも大きなアドバンテージがあります。
よくある例を挙げます。あなたがデザイナーコミュニティの主催者であれば、毎日グループで見えるコンテンツは、実は非常に貴重なニーズプールです。誰かがクライアントが常に修正を繰り返すと文句を言い、誰かが特定の素材サイトの課金方式に不満を持ち、誰かが異なるサイズ間の調整が時間の無駄だと感じている。各不満の背後には、潜在的なプロダクトの手がかりが隠されています。
あなたが試験対策コミュニティにいる場合、グループには長期的に似たような話題が溢れているかもしれません。今日の調子が悪い、計画がまた延期された、どの資料を見るのがより効率的か、どうすれば継続的にチェックインできるか。想像で考える必要はなく、しばらく観察して、皆が繰り返し言及する共通の難題を整理すれば、学習系アプリの初期機能の方向性を大まかに描くことができます。
公開の場からニーズを発掘する
自分のコミュニティや読者層がなくても心配する必要はありません。インターネット上では毎日、無数の人が様々なプラットフォームで自分の困難と不満を語っています。公開の場でのこれらの声は、それ自体が巨大な宝庫です。
あなたの興味のある業界に関連するいくつかのプラットフォームを選び、定期的に感情の色のある重要ワードを検索できます。例えば、「面倒」「おすすめある？」「どう解決する」「本当に不便」「もっといい方法ない？」 など。そして忍耐強く投稿とコメントを見て、二種類の情報に注目してください。
一つ目は、ある問題が長期的に、繰り返し言及されていること。就職関連のセクションでは、定期的に履歴書の書き方、自己紹介の準備、面接結果のフォローアップについて質問がある。育児グループでは、離乳食の組み合わせ、生活リズムの調整、親子コミュニケーションの困惑が繰り返し現れる。小規模EC事業者のコミュニティでは、在庫管理、キャッシュフロー、スタッフのシフトが常に心配されている。これらの長期に存在する繰り返しの問題は、業界が繰り返し露呈しているシステム的なペインポイントです。
もう一つは、特定のシーンでユーザーが非常に不器用な方法で無理やりやっていること。例えば、すべてのToDoを紙に書いてから写真を撮ってクラウドにアップロードする人。異なるアプリ間でコピーペーストを繰り返して、あるフォーマットから別のフォーマットに変換する人。異なるチャネルのデータを手動で一つの表にまとめる人。これらの場所は、少し注意深く観察すれば、プロセス化・ツール化できる多くの小さな切り口が見つかります。
巨人の肩の上に立つ
よく見過ごされるもう一つのアイデアの出所は、既存のプロダクトとプロジェクトです。世界にはすでに多くの素晴らしい人々が、私たちのために多くの探索の道を歩んでくれました。あなたは毎回白紙から始める必要はなく、他人が半分まで進めたところに立って、もう一歩進むことができます。
ハッカソン、プロダクトイノベーションコンテスト、スタートアップ Demo Dayのような場では、多くの面白い小さな作品が現れます。それらの多くは二つの特徴を持っています：時間が厳しく、リソースが限られている。これはあなたが今作ろうとしている小アプリと非常によく似ています。だから、これらの受賞作品を見るとき、二つの問いを多くしてみると良いでしょう。もしこのものがより狭いセグメントだけにサービスしたら、もっと実現しやすくなるか。機能を半分、さらには三分の二削って、最もコアな部分だけ残したら、むしろもっと明確になるか。
同様に、プロダクトランキング、オープンソースプロジェクト、ツールコレクションサイトにリストされているツールも、思考の出発点になります。興味のあるものをいくつか選び、一つ一つ分解してみてください。それは誰のどんな問題を解決しているのか、現在の形態にはどのような明らかな不足があるのか、別のシーンや別の国に移行したらどう変わるか。コピーするのではなく、この分解練習を通じて、問題とソリューションの間の関係への理解を訓練するのです。
長期間これらの4つの道から素材を掘り起こし続けると、アイデアは突然頭の中に現れる奇跡ではなく、生活、他人、情報世界との長期的な相互作用から自然に育つ副産物であることがわかります。
1.5 良いアイデアを一言で要約する方法：少ないほど多いという芸術
アイデアがどこから来るかを大まかに知った後、次の重要な練習は、一言で明確に説明することです。この練習は簡単そうに聞こえますが、実際にはかなり残酷です。なぜなら、あなたのアイデアが本当に明確なコアをつかんでいるかという事実に直面することになるからです。
人を記憶に留められるのは、相手が全面的に完璧だからということは少なく、多くの場合、ある明確な特徴があるからです。プロダクトも同じです。十数個の機能を無理に覚えさせるより、素朴だが明確な印象を与える方が良いです。
一言を書く際のよくある間違いは、過度に広範囲であることです。例えば：「ユーザーの英語力を向上させるアプリ」。一見間違っていませんが、深く掘り下げると、この文はほとんど何も言っていないことがわかります。
相対的に良い表現はもっと具体的です。例えば：「毎日10分の通勤時間を利用して、1ヶ月で100のコア単語を覚える暗記アプリ」。ここでは少なくとも3つのことが説明されています：使用コストは管理可能で、毎日10分だけ；予想結果は可視的で、1ヶ月で100の新単語；シーンは明確で、主に通勤中。
この練習は、誰を助けるのか、どのようなシーンであなたを思い出してほしいのか、どの程度の期間でどのような結果を達成したいのかという3つの質問に繰り返し答えることです。
1.6 AIを使って思考を発散させ、差別化を見つける
過去にアイデアを思いつくのは、ほとんど自分でゆっくり考えるしかありませんでした。今はAIがあり、いつでも召喚できるブレーンストーミングパートナーが増えました。
ある方向に行き詰まったとき、現在のアイデアをできるだけ明確にAIに説明し、いくつかのことをお願いしてみましょう。例えば、同じコアタスクに基づいて、20種類の異なるユーザーグループをリストアップしたり、学生、フリーランサー、子育て中の親、小規模事業者などの異なる角度から、このアイデアの可能な使用方法を再記述したりします。
一般的なアイデアは必ずしも無効なアイデアではありません。 単語暗記、ToDoリスト、家計簿、習慣トラッキングのような一見一般的な方向は、背後にある問題が実際に普遍的に存在するからこそ、継続的に作られます。この場合、誰が特定の小グループをよりよく理解し、細部でより彼らの生活に寄り添えるかが競争になります。
AIの価値は、あなたに代わって決定を下すことではなく、本来非常に狭い道を、より完全な地図に変えることにあります。
まとめ
いくつかの簡単な次元を使って、アイデアがすでに十分明確かどうかを検査する方法を学びました。自分がかっこいいと思うことと、ユーザーが本当に必要としていることの違いを区別する必要があります。良いアイデアが良い理由は、最初からあるペインポイントに立っているからです。自分の生活、ユーザー資産、公開情報、既存プロダクトから継続的に手がかりを掘り起こすことを学びました。一言でアイデアを説明する練習も必要です。AIを思考を拡張するパートナーとして使い、判断を代替するツールとして使わないことも学びました。
手元に1〜3個のそのようなアイデアがあり、一言で説明できる（誰に使われるのか、どのシーンで、おおよそどんな結果をもたらすのか）時、新アイデアを考え続ける衝動を止めて、次のステップに注意を向けることができます：その中の一つを、実際に作れて、実際のユーザーに使えるアプリに分解する方法。
アイデアが少し微妙でも大丈夫。最初は微妙なのが正解です。完成は常に完璧より重要です。 始めなければ終わりはありません。
📚 課題
上記の内容に基づいて、以下の課題を完了してください：
- 自分の興味に合わせて、AIを使っていくつかのアプリの「アイデア」を生成する
- AIに自分のアイデアに基づいて、それが真のニーズか偽のニーズかを評価させ、ユーザーニーズインサイトと提案を得る
- 4つの主要な出所から1〜2つの出所を選んで「アイデア」を得るか、AIにいくつかのアプリの「アイデア」を生成させる
- 上記のすべての Idea から、最も好きな3つのアイデアを選び、情報量の豊富な一言でそのアイデアを要約してみる
2. アイデアがあれば、どうやって実現可能なアプリに分解するか
前の章で解決したのはスタート地点の問題でした：一体どのようなアイデアが真剣に扱う価値があるのか。
本当の挑戦はここから始まります。多くの人がこのステップでつまずきます：頭の中には一見完全な青写真があるのに、いざ手を動かすと複雑すぎて手がつけられません。
考えないで！今がその時です！この章では、アイデアから実現可能なバージョンへの分解方法を学びます。ゼロからあるものを作るのは天才に依存するのではなく、発散、収束、分解、詳細化、参考、質問という一連の反復練習可能な具体的なアクションに依存します。
2.1 アイデアからソリューションへ：ダブルダイヤモンドモデルの発散と収束
ページを描いてアイデアを出すことを学んだ後、すぐにもう一つの一般的な問題に直面するでしょう：アイデアがどんどん増えてくること。ホワイトボードに様々なシーンと機能を書き連ね、紙には異なるページバージョンが描かれ、一見達成感がありますが、実際にやろうとすると逆に手がつけられなくなる。なぜなら、すべてが重要に見え、どれも試す価値があるように思えるから。
この時、非常に古典的で分かりやすい思考フレームワークを使う必要があります：ダブルダイヤモンドモデル。このモデルの意味は実はとても素朴で、人生の多くの段階で、最初に発散してから収束する必要があり、最初からすべてを一度にやり切ろうとしてはいけないということです。
ダブルダイヤモンドモデルとは
ダブルダイヤモンドモデルは、英国デザイン評議会が提案したイノベーションとデザインプロセスフレームワークです。プロセス全体を連続する二つの菱形（「ダブルダイヤ」）に例えます。最初のダイヤは「問題の発見」から「明確な問題の定義」へ、まず広く発散し、十分に調査・理解してから、真に解決すべきコア問題を収束・整理することを強調します。2番目のダイヤは「解決策の発展」から「最終的なソリューションの納品」へ、可能な解決アプローチを大胆に発散・探索・反復し、その後収束・選別・磨き上げて最適で実行可能な案を出すことを強調します。ダブルダイヤモンドモデルは、問題とソリューションの両方の段階で「発散—収束」のプロセスを経ることを強調し、最初から解決策に飛びつくことを避け、イノベーションの品質と成功率を向上させます。
第一ダイヤ：問題を理解し、単点から全体像への発散と収束
ダブルダイヤモンドモデルでは、第一ダイヤは問題そのものに関するものです。 まず曖昧な認識から始め、徐々により多くの関連状況と可能性を発散させ、その後一度収束して、真に解決する価値のある問題点を見つけます。
アプリに対応させると、次のようなことがあります。
発散段階では、ユーザーが直面する可能性のある使用シーン、遭遇する可能性のある障害、期待する結果をできるだけ多く列挙します。 急いで判断せず、頭の中の関連するものをすべてまず並べます。
収束段階では、最も一般的で最も痛い1〜2つの状況だけを選ぶよう自分に強います。 例えば、多数のシーンから、最も多く言及されたのは、非常に長い作業ドキュメントを受け取った時に、このドキュメントが何を言いたいのか、主な結論は何かをまず把握したいということだと発見したとします。それなら、第一版のアプリの目標をこう定めることができます：ユーザーが5分以内に長文のコア意味を理解できるようにする。
第一ダイヤの終了時には、開始時よりも明確になっているべきです：あなたが真に解決する必要のある問題は何か、他の周辺問題と比べて、なぜ優先度が高いのか。
第二ダイヤ：ソリューションを設計する、粗いアイデアから実行可能な案へ
ダブルダイヤモンドの第二部分は、ソリューションの誕生に関するものです。 どの問題を解決するかを大体把握した後、次にするのは、その問題に対してできるだけ多くの解決方法を考え、その中から第一版に最も適したものを選び出すことです。
発散段階では、絶えずアイデアを追加し続けることを意味します。様々な機能、より細かいシーン、様々な可能なプレイ方法をブレインストーミングできます。
収束段階では、シンプルだが非常に実用的な評価ツールを取り出します：ユーザー価値 × 実現可能性 × 時間コスト。各アイデアにこの3つの次元で大まかなスコアをつけ、例えば1〜5点とし、総合スコアが高く、時間コストが管理可能なアイデアをMVP、つまり最小実行可能バージョンの構成要素として優先的に選びます。
このプロセスで絶えず自分に思い出させるべきことが一つあります：第一版の目標は完璧なアプリを作ることではなく、実際に存在し、誰かが本当に使えるバージョンを作ることです。 すべてを網羅する必要はなく、一つの具体的なタスクで十分にまともに機能すればいいのです。
ダブルダイヤモンドモデルを使って思考を整理することに慣れると、多くの元々絡み合っていた状況がずっとスッキリします。どの段階で可能な限り多く考え、どの段階で断固として一部の可能性を削るべきかが分かります。
2.2 実行可能なステップを得る：抽象から具体へ
発散した後、アイデアを得ることは簡単ですが、実行可能なステップを得ることは非常に困難です。「効率を向上させるツールを作りたい」と言っても、抽象的すぎて手がつけられません。ここに必要な能力は分解と詳細化です。大きな抽象的な目標を、すぐに手を動かせる最小の実行可能項目に分解して詳細化することです。
生活の例から始める：「ハンバーガーが食べたい」とは一体何か
「ハンバーガーが食べたい」という文は一見複雑ではありませんが、真剣に分解すると、多くの具体的な分岐が隠されています。
まずは動機と内面のコアニーズ。本当にハンバーガーが食べたいのか、味が恋しいのか、素早く食事を済ませたいのか、友達と集まりたいのか、それともいい写真を見て食いつきたのか。一見無関係に見えますが、後の選択に直接影響します。
次に行動の範囲。どんなハンバーガーを食べたいか、何時に食べたいか、ハンバーガーだけか、セット全体が欲しいか。
さらにどうやって実現するか。店に行くのか、デリバリーか、自分で作るか。それぞれの選択に対応する行動ルートは全く異なります。
分解をすべて明確にした後、曖昧な「ハンバーガーが食べたい」という言葉は、具体的なアクションステップの列になります。
分解と詳細化の意義はここにあります：聞こえは大きくて抽象的な願いを、具体的に実行可能なリストへと導くことです。
アプリの例：ドキュメント処理効率の向上をどこから始めるか
もう少し複雑で段階的な例を見てみましょう。ある正当な願いがあると仮定します：「ドキュメント処理効率を向上させるアプリを作りたい」。この方向は正しいですが、この半分の文で止まってしまうと、どこから手をつけていいかわかりません。
ここでは分解と詳細化の方法を使って、一歩ずつ具体的にしていきます。時間の都合上、ここでは2層の分解方法のみを示します。
第一層の分解と詳細化
まず、「ドキュメント」とは何かを定義する必要があります。 ドキュメント自体は非常に広い概念で、表、Wordレポート、PDFファイル、Markdownテキスト、TXTメモ、スキャンされた画像ドキュメント、数式を埋め込んだ学術論文などが含まれます。
次に、「処理」とは何かを定義する必要があります。 50ページのレポートを5ページの読みやすい要約にするのか、様々な形式のWord、PDF、Markdownを統一テンプレートにするのか、翻訳、書き換え、推敲なのか。
「アプリ」についても定義する必要があります。 自分専用の小ツールなのか、将来ユーザーがいるものなのか、Webアプリなのか、モバイルアプリなのか、既存システムに埋め込まれる小機能なのか。
「効率」も具体的に分解する必要があります。 速度だけか、速度と品質とエラー率と理解の難易度を含むのか。
第二層の分解と詳細化
第一層の分解結果が「AIを使ってPDFドキュメントをテキストに変換する速度と品質を向上させるWebアプリを作りたい」という文になったとします。
しかし、この記述でも多くの重要な情報がまだ曖昧です。「どのAIを使うか」「どの程度まで向上させるか」「どの使用シーンに対応するか」「どのようなユーザーを対象とするか」などです。
さらに分解を続け、この文をより細かい粒度の設計決定と技術案に変える必要があります。
最終的に、以下のような明確な記述になります：
ユーザーにブラウザベースの小ツールを提供し、構造が比較的明確でテキスト主体のPDFレポートを優先サポートし、適応した解析プロセスと軽量AIクレンジングを通じて、約10秒以内に段落構造が明確でタイトル階層が基本的に保持される編集可能なテキストを出力し、ログインなしで使用可能にする。
抽象から具体への移行は、「ドキュメント処理効率を向上させるアプリを作りたい」という大きな願望を、誰でも（あるいはAIでも）すぐに理解して実行を開始できるタスクリストに分解することです。
2.3 ホワイトボードでアプリを構想する：最初のアプリを描く
多くの人がアプリを作り始めるとき、最初に思い浮かぶのはコード、バックエンド、データベース、API、フレームワークです。しかし、最初にすべての注意を技術に向けると、最も重要なものを見落とす危険があります：ユーザーがここで一体何をするのか。
最も簡単でよく見過ごされる方法は、まず描くことです。ホワイトボード、白紙、メモ帳で構いません。ユーザーが入ってから出るまでの全経路を、数枚の簡単なページスケッチで描き出し、エディタを開いてコードを書くのではなく先に構想します。
アプリ全体をまず3種類のページに分けることができます：入口ページ、操作ページ、結果ページ。
入口ページ：ユーザーがどこから入り、最初に何を見るか
入口ページは、ユーザーとアプリが初めて出会う場所です。多くの人が入口を設計する時、まず汎用的なトップページを思い浮かべ、機能ボタン、モジュール入口、広告枠を詰め込み、これで十分な量と素晴らしさがあるように見えます。しかし、このページを紙に描いて壁に貼り、初めて来た人のふりをすると、突然非常に現実的な問題に気づくでしょう：「結局どこを押せばいいんだ？」
入口ページを描く時、まず自分をガイドとして見なすことができます。いくつかの非常に具体的な質問をします：ユーザーはどのような方法で入ってくるのか、シェアリンクのクリックか、アプリストアでの検索か、ウェブページでのQRコードスキャンか。異なるソースはユーザーの予想を全く異なるものにします。
操作ページ：ユーザーが何を入力、クリック、選択するか
ユーザーが前に進むことを決めた後、次は操作ページに落ちます。つまりアプリの作業領域です。ここがユーザーと本当にインタラクションする場所であり、最も過剰に複雑に設計されやすい場所でもあります。
操作ページを描く時、ユーザーに一つのことだけさせるという非常に効果的な練習があります。
紙の上で操作ページを構想する利点は、非常に低コストで異なるバージョンを試せることです。
結果ページ：ユーザーが何を得て、どう表示するか
結果ページでは、ユーザーが最も関心するコア情報を最も目立つ位置に配置する必要があります。
入口ページ、操作ページ、結果ページをすべて描いた後、矢印で繋ぎ、ユーザーが初めて入ってから終了までの一歩一歩を描きます。
この章のコアは一言です：まずユーザーの操作プロセスを描き、その後技術実装を考える。コードが書けなくても、数枚の簡単なスケッチでアイデアを目に見えるアプリの原型に変えることができます。
2.4 他人のアプリを参考にする：賢く「宿題を写す」
多くの人が最初のアプリを作る時、一種の心理的負担があります：ゼロから始めなければならず、ページ構造、インタラクション方法、ビジュアルレイアウトはすべて完全にオリジナルでなければならず、そうして初めてプロダクトを作っていると言えると。現実は、この原則を守ると、無関係な場所で大量のエネルギーを無駄にすることになります。
アプリデザインにおいて、より効率的で成熟した態度があります：賢く宿題を写すです。単なる模倣ではなく、他人がすでに検証した良い解決策を選択的に借用し、あなたのユニークな価値にエネルギーを残すことです。
インターネット上にはアプリのインターフェースのスクリーンショットを収集するウェブサイトがたくさんあり、アプリストアの詳細ページも大量にあります。これらは巨大な参考図鑑です。自分の方向に近いアプリをいくつか選び、サンプルのように一ページ一ページ見てください。
重点的に観察するのは配色の美しさではなく、いくつかの重要なエリアでどのように処理しているかです：
- ナビゲーションバーの設計、下部か上部か、固定のコア入口か一つのメインボタンだけか
- フォームの構成、一度に同じページで全て入力するか、複数の小ステップに分けるか
- 結果表示時に、最も重要な情報が最も目立つ位置に置かれているか、次要情報はどのように整理されているか
- 新ユーザーが初めて来た時、使用方法を説明する短いガイドフローがあるか
具体的には以下のウェブサイトを参考にできます：
- https://www.uisources.com/
- https://screenlane.com/
- https://pagecollective.com/
- https://patttterns.net/
- https://mobbin.com/
- https://refero.design/
- https://scrnshts.club/
- https://godly.website
2.5 すべてが準備できてからユーザーニーズを調査するのを待たない
多くの人がユーザー主導のプロダクトを作ると言いながら、実際には最初に自分の心の中の完全なバージョンを作ってから他人に見せる習慣があります。これは一見体面が良いですが、プロダクトの観点からは非常に危険な習慣です。
解決策：描きながら聞く、作りながら聞く、作ってから聞くのではない。
描きながら聞く：紙の段階からフィードバックを収集する
ホワイトボードや紙に入口ページ、操作ページ、結果ページを描いた時点で、すでにユーザーと対話する基盤があります。
作りながら聞く：半完成品の段階で人を招いて試用する
基本プロセスが通る半完成品バージョンがあれば、一人で黙って使う理由はありません。定義した最小タスクを完了できれば、すでにリアルユーザーの試用を招待する条件を備えています。
このプロセスであなたがすべきは弁解ではなく、観察です。
粗雑さを恐れない
早い段階で問題を露呈させることは、コストが最も低いです。
📚 課題
上記の内容に基づいて、以下の課題を完了してください：
- 任意のLLMを使用して、前のアイデアについてAIにダブルダイヤモンドモデルを参考に発散結果を出させ、あなたがその発散結果から実行可能なソリューションセットを選ぶ必要があります。
- 以前に思いついたアイデアについて、分解と詳細化の方法を使用して、より具体的な実行可能な内容を得てください。例：「ユーザーにウェブツールを提供し、20ページ以下のテキスト主体PDFをアップロードすると、10秒以内に段落構造が明確でタイトル階層が保持された編集可能テキストを得られ、ワンタップコピーと.txtダウンロードをサポートする。」
- 詳細化したアイデアに基づいて、ホワイトボードでアプリを描いてみてください。アプリは2つの部分に注目する必要があります：UIはどのように設計すべきか、どのような機能があるべきか、各機能はどこにあるか。
3. 作った後、どうやって「良いアプリ」に判断し磨き上げるか
アプリが作られて実際の世界で人に使われるようになると、全く別の段階に入ります。これまでの議論はすべてアイデアとデザインの段階に留まっていましたが、今、プロダクトは初めて実際の使用シーンで検証されます。ユーザーが間違えた場所、躊躇した場所、立ち止まった場所が見えると同時に、どのステップが驚くほどスムーズか、あるいはあるコーナーで予想外に長く留まったかも見えるでしょう。これらのディテールは、頭の中のプロダクトへの様々な想像よりもはるかに正直です。
この章で解決するコア問題は：アプリがすでに作られ、初期ユーザーが使用している時、良いアプリからどれくらい離れているか、そしてどのように実際の使用情報を利用して少しずつ磨き上げるか。
3.1 良いアプリとは：4つのコア特徴
アプリが良いかどうかを判断するには、自分がどれだけ好きか、ダウンロード数や一両日の使用回数だけを見るのではなく、より基礎的で安定した特徴があるかどうかを見る必要があります。簡単に言えば、以下の特徴を参考にできます：
良いアプリは具体的な価値をもたらす
良いアプリの最も直接的な特徴は、あるシーンでユーザーに実用的なメリットをもたらすことです。このメリットは大きくなくても、高度な言葉でパッケージングする必要もありませんが、具体的に説明できる必要があります：ユーザーに何を少なくさせたか、どれだけの時間を節約したか、あるいは何をミスしにくくしたか。
例えば、簡単な会議議事録ツールが、録音をアップロードするか会議中に直接録音するだけで、終了後に自動的に構造化された会議議事録を生成し、ToDo、責任者、締め切りをリストで明確にするなら、それはタイピングの時間だけでなく、記録、整理、選別、フォーマット出力の全プロセスの精神的労力を節約します。
ユーザーが直感的に使える、マニュアルなしでわかる
もう一つの過小評価されがちですが極めて重要な特徴は、良いアプリは通常あまり説明を必要としないことです。ユーザーが初めて開いた時、直感で大体どこから始めればいいか分かり、何をクリックすると何が起きるかが分かります。
良い使い勝手は、本質的にユーザーコストに対するプロダクトの尊重です。 あなたは一つのことを認めているのです：誰にもあなたのアプリを研究する義務はない。
高頻度または重要なシーンで自然にあなたを思い出す
良いアプリはしばしば安定した使用リズムを持っています。高頻度であるか、重要であるか。高頻度とはユーザーの日常に溶け込んでいること。重要とは毎日使わなくても、特定のシーンに遭遇するとユーザーが真っ先にあなたを思い出すこと。
本当に警戒すべきは、ユーザーが高頻度にも使わず、重要シーンでも積極的に思い出さないことです。
利他心
本当に良いアプリは、比較的素朴な利他心を持っています。確かにどう生き残るかを考え、合理的な課金方法も設定しますが、デザインのパスと体験において、優先順位は常に：ユーザーがこのことをよりスムーズに完了できるようにするか、追加の障害を作るために余計なステップを加えるか。
もう一つ重要なことがあります：良いアプリは必ずしも大きなアプリである必要はありません。 小さくても、ある人々、あるシーン、あるタスクに特化していれば、その小さな部分で十分に優れています。
3.2 ニーズインサイト：マズローの欲求階層理論
アプリを作る前に、多くの人は機能レベルの思考に直接飛びつきます。しかし、アプリが生き残れるかどうかを決定するのは、あなたが人間のどのレベルの欲求に触れているか、そしてどれくらい正確に触れているかです。
マズローの欲求階層理論は、5つの層に分けられます：生理的欲求、安全の欲求、所属と愛の欲求、尊重の欲求、自己実現の欲求。
生理的・生存に関連するニーズ
この層は最も基礎的で、食べる、寝る、生存状態そのものに直接関係します。フードデリバリー、食材購入、ランナーサービス、予約、配車などの典型的な配送・移動サービスは、本質的にユーザーがより低い時間コストで最も基本的な問題を解決するのを助けています。
あなたのアプリがこの層で頑張る場合、一つの特徴があります：ユーザーは安定、信頼性、予測可能性に特に敏感です。
安全感と確実性のニーズ
安全のニーズには、物理的な安全だけでなく、経済的、情報的、心理的な安全感も含まれます。
多くのツール型アプリは、実際には主にこの安全の層で機能しています。家計簿、資産管理、保険アシスタント、契約テンプレートツール、パスワードマネージャー、バックアップツール、プライバシー保護ツールなど。
この種のプロダクトをデザインする時、もう一つ聞いてみてください：あなたは一体ユーザーのどの種類のリスクを下げているのか、お金の、時間の、関係の、それともコンプライアンスと法務の。
帰属感、つながり、認められること
さらに上の層は、所属と愛のニーズです。簡単に言えば、一人になりたくない、ある人たちとつながりたいということです。この層は、ソーシャル、コミュニティ、趣味グループアプリの本拠地です。
もしあなたのアプリがこの層に立とうとするなら、コンテンツだけでは不十分です。考えるべきは：ユーザーはなぜここを「仲間がいる場所」だと思うのか、ここに痕跡を残し、他人と軽くてもリアルなインタラクションを起こしたいと思うか。 そうでなければ、あなたが作っているのは単方向の放送ツールです。
尊重、自己価値、達成感
さらに上の層は、尊重と自尊のニーズです。人は受け入れられるだけでなく、ある段階で意識し始めます：私はここでまともな人間なのか、見られ、認められているのか、やったことが誰かに知られているのか。
大量のチェックイン、バッジ、ランキング、称号、達成システムが、実はこの層で機能しています。
この層では、重要はインセンティブシステムを作ったかどうかではなく：あなたのアプリがユーザーに蓄積できるステージを提供しているか、初心者から熟練者への変化を明確に見えるようにしているかです。
自己実現と自己超越
ピラミッドの最上層は、どのような人間になりたいか、そして自分の一部を貢献したいかを指します。これは非常に抽象的に聞こえますが、具体的なシーンに落とすと、非常に実践的な表現があります。
例えばクリエイティブツール：執筆、絵画、音楽制作、ビデオ編集、プログラミングプロジェクト管理。表面上は技術的能力を提供していますが、背後にあるのはユーザーの何か自分のものを創造したいという渇望です。
アプリが真にこの層に触れた時、非常に強い粘性を持つことが多いです：インターフェースが最も美しくなくても、機能が最も完全でなくても、ユーザーはここに留まります。なぜならそれは、私はどんな人間か、どんなことをしているかというより深いつながりを確立しているからです。
実際のデザインでは、このように自己チェックできます：
- まず自分に聞く：私のアプリが最も主要に、最もコアで満たしているのはどの層のニーズか、一つだけ選ぶ
- 次に聞く：このコア層の上で、自然に一つ上の層に拡張する機会があるか、無理に概念を貼り付けるのではないか
- 最後に、自分のターゲット層より下の層で、明らかな欠点がないか、ユーザーの足を引っ張っていないか
3.3 ユーザータイプ別：CエンドアプリとBエンドアプリの違い
アプリを作った後、もう一つ重要なことに気づくでしょう：一般個人ユーザーと企業・機関ユーザーに向き合うのは、全く異なるゲームルールです。どちらもユーザーと呼ばれますが、関心事は全く異なります。
- Cエンド（Consumer End）：消費者側。一般個人ユーザーが対象。WeChat、Douyin、Meituan など。
- Bエンド（Business End）：企業側。企業、機関、組織ユーザーが対象。DingTalk、財務ソフトウェア、POSシステムなど。
Cエンドアプリ：一般個人の生活、感情、習慣に向け
Cエンドアプリは個人ユーザーに向けており、各人の日常生活に組み込まれています。
これらのアプリは種類が異なりますが、いくつかの共通の関心事があります。
第一に、ユーザー成長。 つまり、より多くの人に初めてアプリを試させる方法。
第二に、リテンションと再訪。 人が来ただけではなく、留まりたいか、戻りたいか。
第三に、コンバージョンと課金。 ユーザーが課金する理由は、無料版をひどくしたからではなく、あなたから一部の価値を得た後、有料機能がより高いレベルの利便性をもたらすと見たから。
第四に、シェアと伝播性。 多くのCエンドプロダクトが急速に広がるのは、使用プロセスに自然なシェア性があるからです。
Bエンドアプリ：組織の効率、コスト、リスク管理に向け
Bエンドアプリは企業、チーム、機関、または特定の部門に向けています。
これらのアプリとCエンドの最大の違いは、複数のロールのニーズを同時に満たす必要があることです。
Bエンドアプリにはいくつか特にコアな関心事があります。
第一に、効率の向上。 ある一人の時間が短縮されただけでなく、プロセス全体の時間が減少し、コラボレーションコストが下がり、コミュニケーションリンクが減る。
第二に、コスト削減。 人件費、研修費、システム保守費など。
第三に、リスクコントロールとコンプライアンス保証。 多くのBエンドシーンでは、コンプライアンスとトレーサビリティに高い要求があります。
第四に、権限管理と責任の境界。 誰が何を見れるか、誰が何を変更できるか、誰がどの結果に責任を持つか。
業界からアプリへの思考方法：あなたがある程度理解している業界を選び、その業界の日常的な運営の中で、どのプロセスが人工に大きく依存しているか、どの情報が複数のシステムやプライベートチャットに散在しているか、どのプロセスのエラー率が特に高いがすぐには発見されにくいかを分析します。これらの場所の周りに、非常にフォーカスされた小ツールを設計できます。
3.4 ユーザーデータに基づく磨き上げ：自分が良いと思うものからユーザーが良いと思うものへ
アプリを作った後に最も起こりやすい錯覚は、自分では使えば使うほどスムーズに感じ、どこもかなり合理的だと思い込んで、そのままユーザーも同じように感じるはずだと考えてしまうことです。実際には、自分で作ったプロダクトほど、他人がつまずいている点に気づきにくくなります。アプリを「自分ではよくできていると思う作品」から、本当に良いアプリへ育てていくには、実際のユーザーフィードバックを設計の中に取り込む必要があります。
ユーザーが話せる出口として、シンプルなフィードバックの仕組みを設計する
最初から複雑なカスタマーサポートシステムやデータ分析基盤を作る必要はありません。ごくシンプルな方法から始められます。
グループチャットは最も直接的な方法です。 すでに小さなユーザーグループを持っているなら、普段の利用中に出てきた問題やアイデアを、そのグループに投稿してもらうよう促せます。あなたがやるべきことは、丁寧に返信し、記録し、定期的に整理することです。グループ内で言い訳したり、防御的に反論したりすることではありません。この小さな集団の中で、率直に話せる雰囲気を作れるほど、後から集まるフィードバックの価値は高くなります。
アンケートは、一度に比較的多くの構造化された情報を集めたいときに向いています。たとえば、あるバージョンをリリースした後、いくつかの具体的な機能についてユーザーがどう感じたかを知りたい場合です。回答率を高めたいなら、アンケートは長くしすぎず、質問もできるだけ具体的にします。たとえば「この期間で最もよく使った機能はどれですか」「どのステップで一番詰まりましたか」と聞く方が、「このアプリ全体をどう感じますか」と漠然と聞くより有効です。
使用後のポップアップもよく使われる方法です。たとえば、ユーザーが一つのタスクを完了した後に、非常に短い評価と自由記入欄を出し、「今回の体験はスムーズでしたか」と尋ねます。場合によっては、単純な数値評価だけでも、あるフローに明らかな問題があるかどうかを判断する助けになります。
1対1のインタビューはコストが高めですが、得られるリターンも大きいことがよくあります。異なるタイプのユーザーを数人選び、20分から40分ほど時間を取ってもらい、普段の使い方を詳しく聞いてみましょう。実際に操作してもらいながら、何を見ているのか、何を感じているのかを話してもらうと、画面を眺めているだけでは見えない問題が出てきます。以前、ある創業者がユーザーから提案をもらうために、毎日十数件のミーティングを組んで対話していた例を見たことがあります。ユーザーニーズを理解するために時間を使うことは、決して悪いことではありません。
雑然としたフィードバックから3種類の情報を抽出する
ユーザーフィードバックはたいてい混ざり合っていて、一目で整理するのは難しいものです。そこで、まずはそれらを bug、体験上の問題、新しいニーズ の3種類に分けてみましょう。
bug とは、本来起きるはずだと言っていた動作が、ある状況ではまったく起きなかったり、間違った動作になったりすることです。 たとえば、アップロードに失敗する、クラッシュする、ボタンが反応しない、結果が明らかにおかしい、といった問題です。この種の問題に対しては、できるだけ早く再現し、修正し、修正後には影響を受けたユーザーへ自分から知らせるべきです。そうすることで、あなたがこれらの問題を本気で扱っていることが伝わります。
体験上の問題とは、フローの長さ、操作位置、文言の表現などで、最もスムーズな経路を選べていないことです。 たとえば、ユーザーがあるボタンの前でいつも迷い、クリックすると取り返しのつかない結果になるのではないかと不安になる。重要な機能なのに目立たない隅に置かれている。デフォルト設定が多くの人の習慣と逆で、毎回余計な調整が必要になる。この種のフィードバックは、データと観察を組み合わせて判断し、変えるべきか、どの程度変えるべきかを決める必要があります。
新しいニーズとは、ユーザーがあなたの想定していなかった機能や利用シーンを提案し始めることです。 複数のエクスポート形式、チーム共同作業、ほかのよく使うツールとの連携など、本当に検討する価値があるものもあります。ただし、ユーザーが言ったことをすべてそのまま作る必要はありません。本当に見るべきなのは、その新しいニーズの背後に共通した問題があるか、それがもともとサービスしたかった人たちや中核タスクと一致しているかです。そうでなければ、分散したニーズにあちこち引っ張られ、最後には何でもやりたいが、どれも深く作れないプロダクトになってしまいます。
一つの習慣として、すべてのフィードバックにラベルを付けるとよいでしょう。それが bug なのか、体験上の問題なのか、新しいニーズなのかを記録します。定期的にこれらのラベルを集計し、どの種類の問題がどの機能やフローに集中しているかを見ます。そうすれば、ただ受け身で修正するだけでなく、高頻度の問題を意識的に中心へ置いて改善を進められます。
3つのシンプルな指標で継続投資すべきか判断する
リソースが限られている中、このアプリが継続的な長期投資に値するかを判断するためのシンプルで効果的な指標が必要です。
一つ目はリテンションです。 リテンションは、ある1日に何人がアプリを開いたかを見るものではありません。一定期間の中で、どれだけのユーザーが継続して使っているかを見るものです。かなり粗く数えても構いません。たとえば、ダウンロード後1週間以内に少なくとも1回使った人が何人いるか、1か月以内に戻ってきた人が何人いるかを見ます。大多数のユーザーが1、2回使っただけで戻ってこないなら、初期段階で十分な価値を感じてもらえていないか、利用のハードルが高すぎる可能性があります。
二つ目は再訪頻度です。 アプリをアンインストールしなかった人たちが、どのくらいの頻度で戻ってくるのかを見ます。毎日使えるツールと、四半期に一度だけ思い出されるアプリでは、プロダクトの位置づけが違います。だから同じ物差しでは測れません。それでも、あなたは合理的な利用リズムの想定を持ち、実際のデータと照らし合わせて、大きなズレがないかを見るべきです。頻度が期待より高いなら、価値が想定以上かもしれません。頻度が期待よりはるかに低いなら、シーンの捉え方がずれているのか、どこかの体験がユーザーを疲れさせているのかを考え直す必要があります。
三つ目は推薦意欲です。 あなたのアプリを誰かが自分から他人に勧めたいと思うかどうかです。これはいくつかの方法で観察できます。たとえば、ユーザーが特にスムーズにタスクを完了した後に自然な共有入口を用意し、実際に何人が使うかを見る。グループ内で誰かが自発的にあなたのプロダクトを薦めているかを見る。小規模なユーザーインタビューで、「身近な人が似た問題に遭遇したら、このツールを勧めますか」と聞いてみる。推薦意欲は、単純な満足度スコアよりも問題をよく表すことが多いです。なぜなら、推薦は個人の信用を伴う行為であり、ユーザーは本当に大きく助けられたと感じたときにだけ、友人へ紹介しようとするからです。
この三つの指標を、前に述べたユーザーフィードバックと組み合わせて見ると、アプリが今どの状態にあるのかがだいたい判断できます。機能はまだ不完全でも、すでに一部の人が残り、特定のシーンで繰り返し使っているなら、そのアプリは投資と磨き込みを続ける価値があります。逆に、たくさんの bug を直し、新機能も積み上げたのに、リテンションと再訪がずっと上がらず、ほとんど誰も自発的に薦めないなら、一度冷静に考えるべきです。範囲を縮め、最初の中核シーンへ戻るべきなのか、場合によっては別の方向を検討すべきなのかを見直すタイミングです。
4. どの段階で、どのように合理的にAIを活用して価値を拡大するか
ひとたび本気でアプリを作り始めると、すぐに非常によくある誘惑に出会います。「ここにもう少し AI を入れられないだろうか」という誘惑です。この誘惑が強いのは、毎日のように「AI が某業界をエンパワーする」「AI が某プロセスを根本的に作り直す」「AI がすべてをワンクリックで片づける」といった宣伝を目にするからです。時間がたつにつれ、本来は素朴だった問題を、いかにも派手なスローガンに変えてしまい、技術スタックの中にいくつものモデル呼び出しを積み上げ、気づけばアカウント残高だけが減っていく、ということが起こりやすくなります。
このチュートリアルは AI ネイティブアプリの開発を扱っているので、この話題を語るのは少し自分の商売道具に水を差すようにも見えます。しかし、小さなアプリや立ち上げたばかりのプロダクトにとって、最も危険なのは AI を使わないことではなく、AI のために AI を使うことです。本当は、まずシンプルで信頼できるツールを作ればよいのに、新しい能力に惹かれて、賢そうに見える機能を次々に足してしまう。その結果、もともと着地できたはずの方向が、高く、複雑で、しかも価値の伸びがはっきりしないものになります。この章で解決したい核心は、どの段階で、どの部分に、どのような形で AI を使えば、本当にアプリの価値を大きくできるのかを明確にすることです。
4.1 AIのためにAIをしない
自分が気づかないうちにAIのためにAIをしていないかを判断するための非常に実用的な方法は、AI機能を追加する前に、まず真剣に2つの質問に答えることを強制することです。
第一に：AIなしでも、このアプリは成立するか。 つまり、すべてのAI能力を一時的に取り除いても、あなたがやっていることはそれ自体価値のあることであり、ユーザーに現実のニーズがあり、毎日、毎週、毎月このことに真の時間を投じる意欲があるかどうか。
この言い方は少し時代に逆行しているように聞こえるかもしれません。今ではほとんどのプロダクト紹介で AI が非常に目立つ位置に置かれ、AI がなければ現代的なツールではないかのように見えるからです。しかし、もしあなたのアプリが AI を外した途端に完全に成り立たなくなるなら、多くの場合、それは技術が十分に先進的ではないという問題ではありません。もっと深い問題として、あなたが捉えているニーズ自体が痛くもかゆくもない、あるいは実際には存在していない可能性があります。
たとえば、ToDo を整理するツールを作るとします。主な差別化が、ToDo リストにモデルが生成したヒントを足すこと、たとえば自動タイトル付け、自動分類、自動説明補完だったとします。しかしユーザーはそもそも ToDo を書くときに、タイトルを付けることを苦痛だとは感じておらず、ただ早く用件を書き留めたいだけかもしれません。そうであれば、どれだけ賢そうな機能を足しても、継続的な価値にはなりにくいでしょう。逆に、一歩引いて、AI を使わないときにこのアプリの最も素朴な価値は何かを問い直すと、もっと堅実な方向が見えてくるかもしれません。たとえば、複数のチャネルに散らばったタスクを一か所に集めること、1日に実際に終えられる量を見える化すること、予定が破綻する前にリスクを示して、削るべきことと選ぶべきことを判断しやすくすることです。こうした基礎能力を堅く作る方が、最初から ToDo にさまざまなスマートタグを付けるより重要なことが多いのです。
第二に：AIを使った後、具体的に何が向上したか。 ここでは「効率向上」「体験再構築」「スマートアップグレード」のような非常に一般的な要約は受け付けません。ユーザー自身が明確に感知できる1〜2つの次元に落とす必要があります。
自分に次のように問いかけてみてください。
- タスク完了の速度が明らかに上がったか。たとえば、もともとゼロから1ページのコピーを書く必要があったものが、5分の確認と修正で済むようになったか。
- 結果の品質が明らかに上がったか。たとえば、同じ時間で、より整理され、より専門的で、対象読者に合った内容を出せるようになったか。
- 利用プロセスがよりスムーズ、あるいはより楽になったか。たとえば、退屈なフォーム入力を、会話に近い質疑応答に変えられたか。
- 実際のコストが下がったか。たとえば、外注回数、人工サポート時間、研修期間、意思決定時間を減らせたか。
頭の中の答えがまだ、なんとなく便利になりそう、少し格好よく見えそう、という程度にとどまっているなら、その AI 機能はまだ最も重要な力点を見つけられていない可能性が高いです。
この二つの問いには、はっきりした順序があります。まず AI がなくてもアプリとして筋が通ることを確認し、その上で、AI を加えると具体的にどこが良くなるのかを問うのです。
4.2 AIがどのような役割を果たすかを考える
このアプリがAIを使わなくても成立し、明確な改善点を見つけた後、次に考える必要があるのは：あなたのアプリで、AIは一体何をしているのか。 多くのプロダクトがここで間違えるのは、AIを非常に抽象的なエネルギーとして扱い、具体的な役割を持ったパーツとして扱わないからです。
より明確なアプローチは、AIをいくつかの異なるコンポーネントとして考えることです：それは脳であり、目であり、手です。 プロダクトの目標に基づいて、どの部分を担当させるかを決める必要があります。可能であれば、最初は一つか二つの役割だけを選んでしっかりやり、全部詰め込むべきではありません。
脳として機能する時、AI は主にテキスト内容を理解して生成したり、複雑な情報の間で推論したりします。たとえば、会議議事録アシスタントを作るなら、長い録音から本当に重要な論点を取り出せる必要があり、単に時系列で並べるだけでは足りません。学習アプリを作るなら、ユーザーの回答を見て、概念を理解していないのか、それとも単に手順を書き間違えただけなのかを判断し、それぞれ違うフィードバックを返す必要があります。この種のシーンでの AI の価値は、ユーザーの言葉を読み取り、与えられた材料を理解し、構造と論理を持つ出力を生成できることにあります。あなたがやるべきことは、ユーザーが問題を明確に出せるようにし、十分に正確なコンテキストを渡し、この「脳」が判断するための情報をそろえることです。
目として機能する時、重点は画像や動画など、テキストではない内容を処理することにあります。これらを機械が理解できる記述へ変換し、その記述をもとにさらに行動します。たとえば、紙の書類を整理するツールなら、写真を撮って、請求書、契約書、包装説明書などを検索可能な文字に変えられます。絵の練習アプリなら、ユーザーが描いたラフを見て、構図や線の問題を指摘できます。部屋の整理提案ツールなら、ユーザーがアップロードした写真から部屋のレイアウトや物の分布を認識し、簡単に実行できる改善案を出せます。ここでの AI の要点は、分析できる目のように働き、アプリがキーボード入力の文字だけでなく、ユーザーの生活にある実物世界へ触れ始められることです。
手として機能する時、AI は単に提案やテキスト結果を返すだけでなく、一連の具体的な動作を実行し始めます。たとえば一部の自動化プラットフォームでは、複数のステップを一つのワークフローとしてつなげられます。メールから添付ファイルを読み取り、内容を要点にまとめ、グループへ送信し、原文をクラウドドライブに保存し、最後にタスク管理ツールへフォローアップ項目を自動作成する、といった流れです。ここでの AI の役割は、複雑なプロセスの中で、文脈に応じて次に何をすべきかを動的に判断することです。たとえば、あるメールがクレームかどうかを見分ける、フォームがきちんと埋まっているかを判断する、そしてそれに応じて異なる後続処理を起動する、といったことです。
これらに加えて、実際のアプリケーションでは、AIの役割はさらに具体的で多様になります：
テキスト処理では、翻訳、要約、Q&A、続きを書くこと、感情分析などを担うことがあります。たとえば、カスタマーサポートシステムで問い合わせを自動分類する、法律文書アシスタントで契約条項を抽出する、教育アプリで作文を添削する、といった使い方です。
- 技術的な基盤は主に深層学習における 大規模言語モデル（ LLM ） です。大量のテキストから言語規則と世界知識を学び、長文や多ターン対話の文脈を「読める」だけでなく、一貫した文体で自然な内容を「書ける」ようになります。
- 「理解」の側では、LLM はユーザー意図の識別、重要情報の抽出、感情傾向の判断に使えます。「生成」の側では、要約の自動作成、質問への回答、続きを書くこと、書き換え、多言語翻訳などに使われ、人が読む、整理する、書く必要のある大量の作業を自動化または半自動化できます。
- オンラインカスタマーサポートボットの例では、システムがまずユーザーの一言から、問い合わせ、クレーム、アフターサポートのどれに近いかを大まかに判断し、発話の中から注文番号、時間、商品名などの重要情報を抽出します。その後、LLM が文脈と企業ナレッジベースを組み合わせて、自然で完全な回答を生成します。これにより、人手の負荷を減らし、ピーク時にも安定したサービス品質を保てます。
画像処理では、認識、分類、生成、修復、強化を担うことがあります。たとえば、医療画像で病変位置を標注する、EC プラットフォームで商品を自動切り抜きして背景を差し替える、デザインツールでテキスト記述から挿絵を生成する、といった使い方です。
- 画像理解は通常、畳み込みニューラルネットワーク （ CNN ） などの視覚深層モデルに依拠します。大量の画像からエッジ、テクスチャ、構造などの特徴を学び、物体検出、画像分割、細粒度分類、たとえば異なる病変や商品カテゴリの区別に使われます。
- 画像生成と修復は、拡散モデル、 GAN ** などの生成モデル**に依拠します。テキスト記述や参考画像から新しい画像を生成したり、ぼやけた画像、欠けた画像、低解像度画像を修復・超解像したりできます。
- 多くのシステムでは LLM も組み合わせます。まず自然言語でユーザーの説明を理解し、その後、視覚モデルに適した「プロンプト」、スタイルタグ、構図制約を自動生成し、「何が欲しいかを聞き取る」ことから「欲しいものを描く」ことまでつなげます。
- EC プラットフォームの「スマート主画像生成」を例にすると、システムはまず検出・分割モデルで商品を元画像から精密に切り抜きます。次に LLM が事業者の入力した文言、たとえば「シンプルな北欧風リビング、柔らかい自然光」を解析し、具体的なシーン、色調、スタイルパラメータへ変換します。最後に拡散モデルがそれに合う背景と光と影を生成し、構図が悪いものやスタイルが合わないものを自動で除外し、そのまま出品に使える商品主画像を出力します。
音声・動画処理では、音声や動画の生成、文字起こし、ノイズ除去、編集、字幕作成を担うことがあります。たとえば、ポッドキャストツールで冒頭と締めのナレーションを自動生成する、動画プラットフォームで台本から解説動画を自動合成する、会議ソフトで会話をリアルタイム文字起こし・翻訳し、多言語字幕と録画再生を生成する、といった使い方です。
- 「理解」の側では、システムは音声認識モデルで音声を文字へ変換し、同時に話者、言語、話速、おおよその感情を分析します。また、視覚モデルで動画画面内のシーン、人物、重要な物体を理解します。
- 「生成」の側では、LLM を中核として、台本、会議内容、ユーザー指示を理解・分解・書き換えます。その後、音声合成 （ TTS ）で自然な音声解説を生成し、動画生成・編集モデルによって画面を自動合成または編集し、背景を差し替え、ショットや字幕を挿入します。音声側の生成モデルは背景音楽や環境音も自動生成でき、深度ノイズ除去や音質強化と組み合わせて全体の聞き心地を高めます。
- 「テキストから短動画を生成する」タイプのプロダクトでは、ユーザーは文章を入力するだけで済みます。システムはまず LLM で文章をいくつかの自然な段落と画面に分け、ナレーションに適した原稿と簡単な絵コンテ記述を生成します。次に TTS モデルが音声を合成し、動画テンプレートや生成モデルが絵コンテに基づいて画面を選ぶ、または生成します。タイムライン上で字幕と音声を自動同期し、最後にそのまま公開できる短動画として書き出します。
音声インタラクションでは、認識、合成、感情検出、対話管理を担うことがあります。たとえば、スマートスピーカーでユーザー指示を理解する、音声ナビでルートを読み上げる、語学学習アプリで発音を修正する、といった使い方です。
- フロント側では、深層学習の音声認識モデルがユーザー音声をテキストに変換し、さらにイントネーション、音量、話速などの特徴を抽出して、感情や状態を判断する手がかりにします。
- バックエンド側では、音声合成（TTS）が文字の返答を自然で流暢な音声出力に変えます。感情認識モデルはユーザーの現在の話し方に応じて返答の口調や速度を調整し、やり取りをより本物の会話に近づけます。
- スマートスピーカーを例にすると、ユーザーが「今日は少し疲れたから、リラックスできる音楽をかけて」と言った場合、システムはまず音声認識で文字に変換します。次に LLM が過去の再生履歴を組み合わせて、ユーザーにとっての「リラックス」の好みを理解し、より穏やかなプレイリストを自動選択します。感情認識がユーザーの疲労状態を判断した後、TTS は返答を合成するときに話速を落とし、声の調子を柔らかくして、全体の交流を「聞き取れる」だけでなく「聞いて心地よい」ものにします。
上の内容は、AI のいくつかの主要方向における応用と技術を簡単に紹介したものにすぎません。実際のビジネスシーンでは、多くの場合、複数の最新 AI API を導入し、異なるタスクでより全面的にテストする必要があります。現在の AI の能力がどこまで強いのか、どんな問題を解けるのか、どのような状況で間違えやすいのか、その境界がどこにあるのかを、少しずつ把握していかなければなりません。これを理解して初めて、能力を誤って見積もることでリスクを埋め込むことなく、機能とフローを合理的に設計できます。
次に、この点をめぐって、AI の能力と境界をどう理解するか、実際にプロダクトを作るときに何を考えるべきかを、もう少し体系的に見ていきます。
4.3 AIの能力と限界に習熟する
実際に AI をアプリへ組み込み始めると、すぐに一つの現実に気づきます。宣伝で語られる万能感と、具体的な一機能に落としたときの制約には、かなり大きな差があることがあります。過度に約束して結果が外れるのを避けるには、現在の AI 能力の主な方向について基本的な認識を持ち、それぞれの境界がどこにあるのかを明確にする必要があります。大量のテストを通じて Bad Case を集めて振り返り、利用時には AI が高い確率で間違える状況を避けるか、少なくともエラーに対する警告を加える必要があります。
現在のモデルは多くのシーンで、依然としてもっともらしい作り話をする問題を抱えています。特に、自由に発揮させたり、十分に信頼できる参考資料を与えなかったりすると、見た目には自信に満ちているが完全に間違った答えを出すことがあります。存在しないファイル、データ、経験を作り出すことさえあります。したがって、結果が重大な影響につながるシーン、たとえば財務報告書、法律文書、医療アドバイスなどでは、設計上、必ず人間による校正や多重チェックの層を明確に加え、モデル出力をそのまま自動実行できる指示として扱ってはいけません。
同時に、プライバシーとデータセキュリティも正面から向き合う必要がある問題です。どのデータならそのままモデルに送れるのか、どのデータは匿名化処理が必要なのか、どのデータはそもそも第三者システムに出してはいけないのかを、非常にはっきり理解しておく必要があります。ユーザーがアップロードする契約書、病歴、個人識別情報などの敏感な内容については、画面と規約の中で処理方法を明確に説明し、可能であれば、こうしたシーンにはより安全で制御しやすいモデルデプロイ方式を個別に選ぶべきです。
もう少し具体的に、ここではエージェント Agent に関係する例を借りて、AI 能力の境界を本当に理解するとはどういうことかを説明します。注意してほしいのは、ここで Agent をゼロから実装する方法を教えるわけでも、今すぐ特定のアーキテクチャを追うべきだと言っているわけでもないことです。この例を通じて見てほしいのは、一つの考え方です。同じ Agent という話題でも、ある人は単なる新しい用語として扱うだけですが、別の人はこの話題を使って、タスクを明確に分解し、境界をはっきり描くことができます。
AI アプリの現場に長くいる著者 Barret 李靖氏が、Agent をどう作るべきか、AI を使うべきかを説明するために、私が非常に納得している整理を示していました。それは成熟した理解の仕方をよく表しています。まず問題を分解し、それから AI の使いどころを語る、という方法です。
Agent には二つの変数があります。一つはタスクの進み方を制御する workflow、もう一つは内容生成を制御する context です。
1）workflow と context の確定性がどちらも高い場合、この種のタスクは自動化しやすく、従来の RPA に近いものになります。たとえば請求書処理やフォーム入力タスクでは、AI は主に接着剤のような役割で、発揮できる余地は比較的限られます。
2）workflow は確定しているが context が不確定な場合、つまりプロセスは固定されているが入力が多様な場合、Agent は意味理解の面で補完する必要があります。たとえばカスタマーサポート Q&A や契約解析では、外部検索、知識グラフなどのツールで情報の不足を補い、推論結果を期待に近づける必要があります。
3）workflow は不確定だが context が確定している場合、つまり入力は明確だが進み方が多様な場合、Agent は自律的に経路を計画する必要があります。市場分析レポート生成、パーソナライズ推薦などがこれに当たります。多くの End-to-End RL Agent はこの種のタスクを得意とします。訓練段階で大量の経路計画や問題解決の考え方を学習しているからです。
4）workflow と context がどちらも不確定な場合は、最も複雑なシーンです。推論も探索も必要になります。革新的なソリューション設計、部門横断の情報収集などは、より汎用型 Agent に近いものです。その実行効果は、与えられたツールの豊富さに左右され、特にプログラミング能力を最大限開放することが重要です。たとえば Github でリポジトリを探して clone し、コードを修正して問題を解決することを学ばせ、人間のように働かせることです。
したがって、Agent をうまく作るには、まずシーンを明確にする必要があります。本質的に、自動化が解くのは「確定性」の問題であり、知能化が解くのは「不確定性」の問題です。
この分解方法の価値は、「Agent を作る」という曖昧な概念を、具体的に判断できる問いへ変えることにあります。あなたが向き合うタスクでは、どこが確定していて、どこが不確定なのか。プロセスも情報も確定しているなら、従来のプログラムで十分です。不確定性が現れたときに初めて、AI の意味理解、パターン認識、推論計画の能力が活きます。ただし同時に、不確定性が高いほど、AI が持ち込む新しいリスクも大きくなります。両方が不確定なシーンでは、AI の一歩一歩がずれる可能性があり、どの選択をするかを事前に知るのは難しくなります。多くのチームが第二象限、つまり workflow は確定しているが context が不確定なシーンから始めるのはこのためです。AI の理解能力を活かしながら、固定されたフローでリスクを制御範囲に閉じ込められるからです。
この小節の最初の問いに戻りましょう。本当に AI の能力境界を理解するとは、どういうことでしょうか。
まず、シーンごとに AI への要求が違うことを理解することです。前の workflow と context の例が示しているように、プロセスも情報も確定しているとき、AI に活躍の余地はあまりなく、従来の自動化で十分です。プロセスは確定しているが情報が不確定なとき、AI の価値は理解と補完にあります。プロセスが不確定なとき、AI には計画と探索が必要になります。この分解方法の本質は、不確定性の出どころと程度を識別することです。AI の中核能力は、不確定性の中でパターンと関連を見つけることです。この考え方は Agent だけでなく、画像認識、コンテンツ生成、推薦システムなど、あらゆる領域に同じように重要です。たとえば AI 切り抜きツールを作る場合、入力は確定しています。一枚の画像です。しかし、エッジ認識の正確さや複雑背景の処理能力こそが、不確定性のある部分です。
しかし、AIは不確実性を解決すると同時に、新しい不確実性も導入します。その出力は確率的であり、誤解、誤推論、ハルシネーションを起こす可能性があります。異なるシーンと異なるユーザーは、この不確実性に対する許容度が全く異なります。だからさらに聞く必要があります：
AI が導入する新しい不確定性を、ユーザーとシステムは受け止められるか？ たとえばカスタマーサポートのシーンでは、AI がユーザー意図を誤解しても、ユーザーはすぐに訂正できます。この不確定性は制御可能です。しかし、財務承認を自動実行する場合、AI の一度の誤判断が深刻な結果をもたらす可能性があり、この不確定性は受け入れられません。画像生成でも同じです。ユーザーのアバターを美化するだけなら、結果が気に入らなければ再生成すればよく、試行錯誤のコストは低いです。しかし、建築設計者に施工図を生成する場合、たった一つの細部の誤りでも工事事故につながる可能性があります。
AI の正確率は、このシーンの合格ラインに達しているか？ そしてその合格ラインは、ユーザーがそれを何に使うかで決まります。 同じ画像認識でも、ユーザーのアルバム整理や顔写真分類を助けるだけなら、識別精度が80%でも受け入れられるかもしれません。せいぜい数枚を手動で調整すればよいからです。しかし、セキュリティ監視に使う場合、20%の不審者を見逃すことは深刻な安全リスクになります。同じテキスト生成でも、ソーシャルメディア投稿を書くなら60点のアイデアで十分かもしれません。ユーザーが自分で整えられるからです。しかし、法律契約条項を生成するなら95点でも足りません。たった一つの言葉の不適切さが法的紛争を引き起こす可能性があるからです。ユーザーや用途によって、エラー率への感度は完全に違います。自分がサービスするシーンの許容範囲がどこまであるのかを、はっきり理解しておく必要があります。
AI が間違えたとき、補正する方法はあるか？ workflow が確定しているシーンでは、重要な節点に人間のレビューを置き、AI の不確定性を局所的に制御できます。しかし workflow も不確定なシーンでは、AI の一歩一歩がずれる可能性があり、いつ介入すべきかを判断するのが難しくなります。このとき、コストとリスクは急速に上がります。たとえば画像修復シーンで、AI が古い写真を十分にリアルに修復できなかったとしても、ユーザーは一目で気づき、採用しないことを選べます。しかし医学画像の補助診断シーンで、AI が異常位置を間違ってマークした場合、医師が気づきにくい可能性があり、結果ははるかに深刻です。
AI のパフォーマンスを測定し、最適化する方法はあるか？ そのタスク自体に明確な正誤基準がない場合、AI がうまくできているかどうかをどう判断するのでしょうか。ユーザーのフィードバックが遅れて返ってくる場合、どう素早く反復するのでしょうか。測定すらできないとき、AI の不確定性はブラックボックスになります。たとえば推薦システムなら、クリック率や滞在時間などの指標で効果を素早く評価できます。しかし、クリエイティブな広告コピーを生成する場合、「良い」とは何か自体が主観的で、配信後のコンバージョン率を待たなければ分からないことがあり、反復周期は長くなります。
本当に成熟した判断は、「ここに不確定性があるから AI を使える」ではありません。「ここでの不確定性は AI が処理でき、AI がもたらす新しい不確定性も自分たちで管理できる」という判断です。「この機能点で、AI はどの程度助けになるのか、投資する価値があるのか、どのように投資すれば最も費用対効果が高いのか」。こうした判断力を形成できれば、今後機能を設計し、案を評価するたびに、多くの遠回りを避けられます。
5. アプリがあれば、0から最初のリアルユーザーをどう見つけるか
苦労してアプリを作った後、次の難題は、最初のリアルユーザーをどう見つけるかです。
多くのチームはこの段階で、ものができたのだから、あとは広めればよい、と考えがちです。宣伝する、広告を買う、露出を増やす。より多くの人に見てもらえば自然に回り始めるように見えます。しかし最初から大規模露出を追うと、典型的な罠にはまりやすくなります。貴重な時間と予算を使い、データ上は人が来たように見えても、そのアプリを本当に継続利用したい人がいるのかは検証できないままです。
この段階で最も重要なのは一つだけです。できるだけ小さなコストで、本当に人がこのアプリを使いたいと思い、使い終わったあとも戻ってきたいと思っていることを証明することです。 成長とプロダクトの文脈では、このステップは通常「コールドスタート」と呼ばれます。
コールドスタートとは、ほとんどすべてがゼロの状態から、新しいプロダクトを本当に動き始めるところまで持っていくことです。このときは、ユーザー基盤も、口コミも、検索流入も、ブランド認知もありません。各種指標はほぼ 0 にとどまっています。そんな冷え切った環境の中で、最初に本当に使ってくれる人たちを見つけ、その人たちを中心に最初の利用ループを組み立てる必要があります。
これは、その後の既にユーザーやデータのあるプロダクトを最適化する仕事とはまったく別の種類です。ざっくり言えば、次の4つのステップで進められます。
- まず、成長は 0–1 と 1–N に分けられると理解し、今の自分が何を把握すべきかを知る
- 本当に探すべき相手が誰なのかを明確にし、終端ユーザーだけを見ない
- 対象をはっきりさせたうえで、自分に合った 1〜2 本のコールドスタート経路を選ぶ
- リソースが限られる現実の中で、取捨選択を学び、力を最も重要な小さな部分に絞る
5.1 まず2つの段階を区別する：0–1と1–N
正式にユーザーを探し始める前に、まず一つ明確にしておく必要があります。それは、成長には段階がある ということです。成長に関する仕事を全部まとめて考えると、今どこに力を入れるべきか分からなくなります。最も単純で実用的な分け方は、成長を 0–1 と 1–N に分けることです。
0–1：誰も使っていない状態で、どうコールドスタートするか
0–1 とは、完全にユーザーがいない状態から、本当に使いたいと思う少数のユーザーが現れるまでのプロセスです。冷スタートの「冷」は、最初の時点でほぼすべての指標がゼロであることにあります。ダウンロードも、検索量も、口コミもありません。あなたのアプリは、この世界にまだ存在していないのと同じです。
この段階でやるべきことは、自然流入や運を当てにすることではありません。自分から動いて、最初の土台を作ることです。具体的には、次のことが必要です。
本当に使ってくれる少数のシードユーザーを見つけること。 ただ知り合いから数を集めるのではなく、あなたが解きたい問題に本当のニーズを持っている人を探します。人情や好奇心で一度だけ開いて去る人ではなく、その問題に現実に困っている人です。
最初の利用体験と供給を用意すること。 ユーザーが来たとき、真っ白な画面しか見えないのではだめです。機能がまだ不完全でも、少なくとも一度はコア操作を完了でき、価値を感じられるようにします。
このプロダクトが何をするのか、何を解決するのかを簡単な言葉で説明できるようにすること。 ブランドの後ろ盾がない初期段階では、ユーザーがあなたに与える注意は数秒しかありません。「これは自分に何の役に立つのか」を最短で伝える必要があります。
最初の接触経路を確保すること。 小さなコミュニティでも、フォーラムでも、友人関係でも構いません。大事なのは規模ではなく、本当に必要としている人へ正確に届くかどうかです。
0–1 段階で本当にやるべきことは、最初のリアルニーズを持つ人を引き込み、流入から利用、そしてフィードバックまでの完全なループを回すことです。そのループが回れば、このアプリが空中楼閣ではなく、本当に必要とされ、使われるものだと証明できます。
1–N：すでに使いたい人がいる基盤で、どうスケールするか
繰り返し使いたいユーザーが少しずつ増えてきたら、ようやく問題は、数十人、数百人から、数千人、数万人、さらにその先へどう拡大するかに移ります。これが、一般に言う成長、拡張、スケールの段階です。
1–N の段階では、メカニズム、組織、収益化、ブランド、チームといった、より複雑な論点を考え始めます。たとえば:
比較的安定した獲得チャネルを見つけているか。 どれだけの予算や時間を入れれば、どのくらい新規ユーザーが増えるのか。ここでは運ではなく、再現可能で予測可能な成長経路が必要です。
サービスの仕組みを整え始めているか。 たとえばサポート、運営施策、ユーザー教育です。ユーザーが増えると、初期のように一人ひとりへ手取り足取り教えることはできません。標準化されたサービス体制が必要になります。
このプロダクトでどうやって収益を得るか。 サブスク、単発課金、追加価値サービス、その他の方法か。ビジネスモデルは最初から完全に固める必要はありませんが、1–N に入ったら持続可能な形を真剣に考えるべきです。
ユーザーにどんなブランド印象を残したいか。 早期は小さな輪の中で広がるだけでも、規模が大きくなると「覚えてもらうこと」「信頼してもらうこと」「自発的に薦めてもらうこと」を考えなければなりません。
チームにどんな能力がまだ足りないか。どの工程は長期的に見張る必要があるか。 0–1 は一人や小さなチームでも支えられますが、1–N には複数の役割が必要になりがちです。
これらはどれも重要です。しかし 0–1 の段階でそれらを先に考え始めると、空転するだけになりやすいです。まだ本当に使われるのか、残ってくれるのかが分かっていない段階で、収益モデルやブランド戦略を語っても、肝心なところから目を逸らしてしまうだけです。
なぜまず0–1に集中すべきか
個人開発者や小チームにとって、1–N よりも本当に最も重視すべきなのは 0–1です。理由は単純です。最初のリアルユーザーすら見つけられないなら、その後のスケール、商業化、ブランド構築について語るのはすべて机上の空論だからです。
0–1 段階は、プロダクトのライフサイクルの中で最も脆く、同時に最も重要な瞬間です。この段階は、そのプロダクトの価値を証明できるか、最初の信頼を作れるか、そして次の成長の土台を築けるかを決めます。0–1 を本当に回せて初めて、1–N の議論に進む資格ができます。
次に、0–1 段階にさらに焦点を絞り、「いったい誰を探すべきか」という問いを明確にしてから、具体的なコールドスタートの経路を話します。
5.2 コールドスタートの対象：シードユーザー、供給側、トラフィック側、チャネル側
さまざまな種類のアプリは、たいてい次の四つの対象を避けて通れません。シードユーザー、供給側、トラフィック側、チャネル側です。
第一類：シードユーザー
シードユーザーは、あなたが最初に接触するユーザーです。 彼らの典型的な特徴は人数が少ないことですが、ターゲットのペルソナと非常に高く一致していることです。彼らから得たいのは、登録数や利用データだけではありません。方向性そのものと体験のフィードバックです。
たとえば、個人向けツールなら、シードユーザーは、ある問題で長く困ってきた人たちかもしれません。長文を書くことが多いコンテンツクリエイター、報告資料を頻繁に作る職場の人、毎日大量の資料と向き合う学生などです。教育系アプリなら、同じ試験を準備している少人数の受験者や、特定学年の保護者がシードユーザーになりえます。
コールドスタート時には、まず 20〜50 人ほどの協力してくれるユーザーを見つけ、1〜2 週間かけて使いながら対話する、といった明確な目標を立てられます。重要なのは人数ではなく、高密度なやり取りを通してプロダクトのロジックを磨き込むことです。
第二類：供給側
一部の二面市場や多面市場のプラットフォーム型プロダクトでは、ユーザー側だけでは不十分です。 十分な供給側がなければ、ユーザーを連れてきても、使えるものがなくてすぐに離れてしまいます。
供給側は、コンテンツクリエイター、講師、サービス提供者、店舗、ドライバー、大家などであることがあります。彼らが、プラットフォームの豊かさと魅力を決めます。
たとえば、デザイナー向けの素材プラットフォームを作るなら、まず一部のデザイナーに作品をアップロードしてもらう必要があります。たとえ小規模でも、無料素材の一部を開放してもらえないと、ユーザーが来てもサンプル画像しか見えず、定着しにくいでしょう。オンライン予約ツールなら、あらかじめ使ってくれそうな店舗や機関と連携していないと、普通のユーザーが来ても実際に予約できる相手がいません。
冷スタートのときは、まずユーザー側を先に解くのか、供給側を先に解くのか、あるいは両方を同時に進めるのかを、はっきり理解しておく必要があります。多くのプラットフォームは、初期にこの取捨選択を経験しています。これを構造的な問題として正面から認識しているだけでも、終端ユーザーばかり集めようとする人たちより一歩先に進んでいます。
第三類：トラフィック側
トラフィック側とは、短時間である程度のユーザーの注意をあなたへ向けられる人や組織です。インフルエンサー、縦型メディア、コミュニティ運営者、あるいは多くのユーザーを持つツールプラットフォームがこれに当たります。
たとえば、職場向けツールなら、何人かのキャリア系ブロガーに自然な形でアプリを紹介してもらえれば、仕事効率ツールに敏感な人たちを短期間で集められる可能性があります。小紅書のクリエイター向け選題アシスタントなら、数人の中堅ブロガーと協力して、実際のケースで使い方を見せてもらうと、そのクリエイターたち自体が潜在的なシードユーザーになります。
冷スタートの段階で、いきなり最大級のトラフィック側を探す必要はありません。むしろ、規模は中程度でもターゲット層と強く重なる小さなトラフィック側のほうが、カスタマイズされた試みに一緒に取り組みやすいことが多いです。大事なのは、そのような人や組織を見つけ、あなたが何をするのか、相手にどんな利点があるのかを分かりやすく伝える提案を持ち込むことです。
第四類：チャネル側
チャネル側とは、特定のシーンでターゲットユーザーに安定して届く組織や入口を指します。トラフィック側との違いは、トラフィック側が一時的な注意の導入に寄りがちなのに対し、チャネル側はより長期的で構造化された接続方法であることです。
学校、研修機関、企業、業界団体、ソフトウェアサービス事業者は、典型的なチャネル側です。あなたのアプリが、ある種の機関の効率向上、コスト削減、サービス品質向上に本当に役立つなら、相手にはそのアプリを自分たちの体制内の多くのユーザーに紹介する動機があります。
冷スタート時に、大きなチャネルを一気に取りにいくのは現実的ではありません。まずは小さな範囲の試験導入から始めることができます。たとえば、1〜2 クラス、小さな会社、地域コミュニティと協力し、しばらく内部で使ってもらい、そのフィードバックを見てから規模を広げるかどうか決める、という進め方です。
このように対象を分けて考える利点は、すべての力を終端ユーザーの新規獲得だけに投入し、プロダクト構造のほかの重要な部分を見落とすのを防げることです。自分のプロダクト形態に応じて、簡単な役割図を描き、それぞれの対象が誰なのか、今どれだけいるのか、短期の目標が何なのかを書き出してください。この対象図が整理できたら、具体的なコールドスタート経路を話し始められます。
5.3 コールドスタート方法：異なる対象に対する3つの主要ルート
ルート1：シードユーザーで突破口を開く、私域を優先活用
このルートは、主にシードユーザーと一部の供給側に向けたものです。
多くの個人開発者、小さなチーム、さらにはスタートアップにとって、最も現実的で、コストが低く、しかもリズムをつかみやすい方法は、通常、自分がすでに持っている私域から始めることです。
このルートでは、おおよそ三つの重要な行動があります。
- 少数の的確なユーザーを積極的に体験へ招くこと - 重要なのは数ではなく、ターゲットペルソナとの一致度です。
- 意識的にフィードバックを集め、すばやく改善すること
- シードユーザーに最初のコンテンツや事例を生み出してもらうこと
ルート2：コンテンツまたは特典で駆動する、明確な第一の理由を提示
このルートは、主にシードユーザーとトラフィック側に向けたもので、競争の激しい領域では特に一般的です。
ユーザーに多くの代替選択肢があるとき、「新しく出たから試してみて」という一言だけでは動いてもらえません。もっと明確で、もっと魅力的な理由を用意する必要があります。
よくあるアプローチは二つあります。
- 実利のある特典で引き込むこと - たとえば新しいコースプラットフォームなら、初期に高品質な無料コースをいくつか公開したり、期間限定の割引枠を出したりします。
- 縦深のあるコンテンツで継続的に惹きつけること - TikTok、小紅書、公式アカウント、ポッドキャストなどで、ターゲットユーザーが関心を持つ垂直テーマを継続的に扱い、価値ある内容を出し続けます。
ルート3：ビッグプラットフォームを活用し、既存のエコシステムで突破口を見つける
このルートは、主に供給側、トラフィック側、チャネル側に向けたものです。
多くの分野で、新しいアプリがゼロから独自のエコシステムを作るのは、非常にコストが高いです。しかし、自分を大きなプラットフォーム上の新しい店舗、新しいアカウント、新しいプラグインとして捉えれば、コールドスタートの難易度は大きく下がります。
5.4 リソースが限られた時の取捨選択：0–1段階で最も重要な小部分だけをする
0–1 段階にいることを確認し、サービス対象を明確にし、コールドスタート経路も大まかに選んだのに、リソースがまったく足りないことに気づく。
この段階では、意識的に縮小する必要があります。目標は「たくさんやること」ではなく、「最も重要な小さな部分をしっかりやること」です。ここでは、三つの角度から自分の行動の組み立て直しができます。
目標から具体的なタスクへ
コールドスタートのとき、多くの人が設定しがちな目標は、「市場の反応を見てみる」「まずユーザーを増やす」「まず試用してもらう」といった曖昧なものです。こうした表現は広すぎて、毎日やっていることが本当に目標に近づいているのか判断しづらいです。
より実務的な方法は、目標を一つの具体的な小さなことへ絞ることです。たとえば、今後 4 週間で、ターゲットペルソナに合う 20 人のリアルユーザーに、彼ら自身のリアルな場面で、何度も完全にアプリを使ってもらい、そこから具体的なフィードバックを十分に集める、といった形です。
「細分化された人々」とは、単に「この種のツールを使いそうな人」ではなく、具体的なラベルを指さして説明できる一群のことです。 たとえば、レポート生成ツールなら、ターゲットは漠然とした「職場の人」ではなく、「インターネット業界の運営職で 1〜3 年目の人」に絞るべきです。この層には共通点があります。毎月本当にレポートを書く必要があり、時間が限られていて、それでも内容をある程度専門的に見せたいのです。問題は具体的で、しかも継続的です。
「完全な使用タスク」も曖昧にしてはいけません。 このレポートツールを例にすると、一回の完全なタスクは、ユーザーが最近一週間の運営データと素材を整理してツールに取り込み、初稿を生成し、その後おすすめの構成と要点に従って 2〜3 回修正し、最後に PPT または文書として出力し、実際に部門会議で使うところまで含みます。ユーザーが少し触って終わりで、なんとなく眺めただけなら、それは完全な使用とは言えません。
フィードバックは、十分に細かく聞く必要があります。たとえば:
- データを取り込むとき、どこか分かりにくい、入口が見つからない、あるいは毎回違う場所を押してしまうところはあるか
- 生成された構成は、その会社のレポートの習慣に合っているか。たとえば「背景–目標–プロセス–結果」の形になっているか
- 本当に使う画面はどれで、毎回削除される画面はどれか
- 使ったあと、レポート準備時間が 3 時間から 1 時間に縮まったと明確に感じるか、それとも「少し便利になった気はするが、はっきりは言えない」程度なのか
何でも試そうとしない
小目標を決めたら、次の問題は、その 20 人のユーザーをどう見つけ、どうやって実際のシーンを一緒に回すかです。
冷スタートの方法はたくさんあります。コンテンツを書く、コミュニティを作る、広告を打つ、インフルエンサーに頼む、機関と組む、プラットフォームに載せる。ですが、リソースが限られているなら必要なのは、方法の数ではなく、今の自分にとって最も自然で、続けやすいものはどれかです。
もし普段から長文を書くのが得意で、最後まで読んでくれる人たちがいるなら、まずはコンテンツから始めるのがよいでしょう。たとえば、このツールを使って実際の月次レポートを準備する過程を、非常に具体的な実践記録として書きます。元データの受け取りから、構成の検討、初稿の生成、細部の修正、実際の会議室での使用までを順に示します。途中で比較スクリーンショットを挟み、使う前と後で時間、見た目、構成がどう変わったかを見せます。最後は、冷たいダウンロードリンクだけを置くのではなく、「運営レポートを作る人なら、私と一緒にこのツールを磨きたいなら連絡してください。20 人を選んで一対一でフォローします」と明確に書きます。
もし、安定したコミュニティをいくつか持っているなら、たとえば運営者のグループや同窓会の仕事グループがあるなら、私域から始める方が向いています。そこで、率直にこう話せます。「レポート生成ツールを作っています。まだ使える段階ですが、かなり粗いです。本当にレポートが必要な人を集めて、一緒に使い方を磨きたいです」。自分から手を挙げてくれた人の中から、職種や仕事内容を見て最も合う人を選び、小さなグループを作って試用してもらい、スクリーンショットや不満、改善案を送ってもらい、自分は毎日そのフォローをします。
もし、特定の業界で人脈があるなら、たとえば研修機関の講師を何人か知っている、あるいは中小企業の事業責任者を知っているなら、試験導入を 1 つのクラスや小さなチームに落とし込めます。具体的には、明確な試用プランを提案します。たとえば、次の 1 か月はそのチームの週報をすべてあなたのツールで作成してもらい、あなたはリアルタイムでサポートと調整を行う。その代わり、相手には毎週 10 分だけ小さな会議に付き合ってもらい、どこが一番使いやすいか、どこが一番しんどいかを教えてもらいます。
最も重要な部分だけを磨く
小目標を持ち、主経路も決めたら、次にやるべきことは、自分に「この小さな部分だけをやる」という制限をかけることです。
冷スタート段階のチームに共通する特徴は、不安です。不安になると、すぐ外に新しい動きを探したくなります。短動画アカウントを作るべきか、使い方動画をいくつか撮るべきか、少し予算を入れて広告を試すべきか、何人かのメディアに連絡して記事を書いてもらうべきか。どれも単体では悪くありませんが、合わさると、毎日あちこち向かっていて、どの経路も深くならないという結果になります。
たとえば、今後 4 週間は二つのことだけに集中すると自分に決めます。 一つは、20 人のユーザーを対象に、彼らの実際の場面での体験を何度も改善し、「なんとか使える」から「かなり自然に使える」状態へ持っていくこと。もう一つは、選んだ主経路に沿って少数の新規ユーザーを継続的に見つけ、その行動とフィードバックを記録し、前のグループとの共通点と違いを見ることです。
この 4 週間のあいだに、新しいアイデアや新しい機会が出てきても、まず自分にこう問い直します。「それは、この期間内に 20 人のユーザーの体験を明らかに良くするか、あるいは次の似たユーザーを見つけるのに本当に役立つか。」
このやり方の背景には、コールドスタートの本質を認める姿勢があります。手元にある情報は非常に限られており、同時に多くの方向で良い判断は下せません。10 か所で少しずつやるよりも、一つの具体的なシーン、一つの具体的なグループで、繰り返し検証できる改善をした方がよいのです。たとえば、ある運営新人の集団に対して、このツールがレポート準備時間を本当に短縮し、本当に重点を伝えやすくしていると、明確に見えることがあります。
あなたが通るべきなのは、ユーザーを見つける → 使ってもらうよう導く → フィードバックを集める → 体験を改善する → 継続利用してもらう という閉ループです。このループが滑らかに回るようになって初めて、次に別のチャネルを増やしたり、新しい連携を試したりする意味が出てきます。
まとめ
最初の問題に戻ります：アプリを作ること、一体どこから始めるのが信頼できるスタートか。
この記事の全内容は、実は一つのメインラインを中心に展開しています：まずアイデアが何かを明確にし、それとユーザーニーズの関係を見て、それを一歩一歩作れて、使えて、磨き上げられて、AIで拡大でき、ユーザーを見つけられる完全な使用パスに分解すること。
まず第一章では、アイデアそのものから出発しました。アイデアはもう頭の中の「なんかかっこいい」ではなく、明確なユーザー層に向け、具体的なシーンに根ざし、具体的なタスクを完了させ、現状より良い方法を提供する必要があります。
次に第二章では、行動を開始することを学びました。発散と収束の間を行き来し、ダブルダイヤモンド方式でまずアイデアを広げ、その後ユーザー価値、実現可能性、時間コストに基づいて真に実行可能なルートに収束させること。抽象から具体への練習、ホワイトボードや紙で先に描いてから作ること、他人のナビゲーション、フォーム、結果表示、ガイドフローを分析し、既存の経験を借りること。そして、プロダクトが完全に完成してからユーザーに聞くのではなく、プロトタイプや半完成品の段階から、描きながら聞き、作りながら聞き、リアルユーザーに可能な限り早くデザインに関与させること。
第三章では、何が「使える」で、何が「使いやすい」かを区別する自分なりの判断基準を徐々に構築しました。
第四章では、視点を純粋なプロダクトからAI能力へと拡張しました。AIのためにAIをする衝動を抑え、真剣に2つのことを問う：AIなしでもこのアプリは成立するか、AIを使った後具体的に何が向上したか。
最後の第五章では、これらすべてを一つの現実的な問題に引き戻しました：たとえすでに悪くなく、AIも使えるアプリがあっても、ユーザーがいなければ価値はゼロです。
これらの内容を合わせると、一連の方法は神秘的なものではありません：信頼できるアイデアから出発し、それがリアルなニーズに根ざしていることを確認する。描く、書く、分解する方法で、最小実行可能アプリに収束する。リアルユーザーと明確な指標を使って、少しずつ良いアプリに磨き上げる。重要ポイントで合理的にAIを導入して価値を拡大する。最後に、限られたリソースの下で、適切なコールドスタート方法で最初の対価を支払う意思のある人を見つける。
次のステップは、過度な幻想を捨て、その中から一つを選んで作り出し、推し出し、実際の世界で検証を受けることだけです。アイデア、方法論、AI、成長に関するすべての議論は、最終的に具体的な一人の人、一つの具体的なシーン、一つの具体的なタスクに落ちなければなりません。
だから、最初は粗くても問題ありません。機能が欠けていても、プロセスが硬くても、インターフェースが簡素でも構いません。公開しても誰も反応してくれなくても、登録や課金する人がいなくても、それでも問題ありません。これらはすべてプロセスの状態であり、最終的な結論ではありません。次にどう修正すればいいかを教えてくれているだけで、真に重要なのは進歩することです。
この段階で、筆者はプロセスを楽しむだけでいいと思っています。有名なインタラクティブストーリーゲーム『To the Moon』が言ったように：
"The ending isn't any more important than any of the moments leading to it."
結末は、そこに至るまでのどの瞬間よりも重要ではない。
