Midjourneyは2022年3月の公開から4ヶ月で100万ユーザーを獲得した。広告費はほぼゼロで、当時の従業員は11名だった。成長を支えたのは、Discordをサポート窓口として使うのではなく、製品体験そのものをDiscordの上に置いたことだ。
この記事では、その設計——ユーザーが何かを作ると、それが自動的に他のユーザーへの広告になるループ——を自社プロダクトに組み込む手順を具体的に説明します。対応するケーススタディ「MidjourneyがVCゼロ・従業員40名で$10Bバリュエーションに到達した構造」もあわせて読むと、なぜこの設計が機能するかの背景がつかめます。
再現したい構造：アウトプットが広告になるループ
通常のWebアプリでは、ユーザーの使用体験は本人の画面の中で完結する。誰が何を作ったかは、本人以外には見えない。Midjourneyが変えたのはこの前提だった。
Discordのpublicチャンネルは、全員が全員の使用結果を見られる空間だ。あるユーザーがコマンドを入力すると、生成された画像がチャンネルに流れる。それを見た別のユーザーが「自分も試したい」と思い、試した結果がまたチャンネルに流れる。このサイクルが自走する。
a16zの2023年レポートによると、コミュニティ参加者の製品継続率はWebオンリーと比べて平均2.3倍高い。「コミュニティがあるから定着する」という単純な話ではなく、「使用行為が他者に見え、反応が返ってくる」構造が継続を生む。Stable Diffusionの公式Discordは2022年末に50万人を超えたが、同じループ設計を採用していた。
ループを成立させる3つの前提条件
この構造を自社プロダクトに適用する前に、3つの条件を確認する必要がある。
まず、プロダクトの「使用結果」が可視化できること。AIが何かを生成する、コードが出力される、レポートが完成する——そういった「アウトプット」がある製品に向いている。プロセスだけで結果が見えないサービスには適用しにくい。
次に、そのアウトプットが他者に価値を持つこと。他人の生成した画像を見て「自分も作ってみたい」と思えるからループが回る。業務上の機密情報を扱うツールは、そもそもDiscordのpublicチャンネルに流せない。
最後に、参加へのハードルが低いこと。Discordアカウントは無料で作れ、招待リンク1本で参加できる。このアクセスの容易さがループの入口になる。逆に言えば、エンタープライズ向けや高額BtoB製品では、意思決定者がDiscordを使っていないことが多いため、そもそもチャネルとして機能しない可能性が高い。
4ステップでループを組み込む
ステップ1：Discordサーバーを「広場」として設計する（1日）
Discordサーバーを作るとき、多くの人が最初にやるミスはチャンネルを細かく分けすぎることだ。「質問」「バグ報告」「雑談」「フィードバック」と仕切ると、どこも過疎る。人が分散するからだ。
Midjourney型では逆に、最初は「#showcase」や「#create-here」のような1〜2本のpublicチャンネルに全員を集める。全員の使用結果が同じ場所に流れることで、チャンネルが常に動き続ける。チャンネルが動いているという事実自体が、新参者に「ここには活気がある」と伝える。
設計のルールは「最初の2週間は1チャンネルに全員を集める」。細分化は参加者が100人を超えてから考えればいい。管理者が最初の数日間、投稿されたアウトプットにリアクションをつけ続ける役割を担うことも重要だ。誰かが反応してくれる場所でないと、次の投稿が生まれない。
ステップ2：プロダクトの使用をDiscordから実行できるようにする（1週間）
ここが技術的な核心だ。ユーザーがDiscordを離れてWebアプリに行き、結果をコピペして戻ってくる設計にしてはいけない。コマンド実行から結果表示までDiscord内で完結しないと、ループが途切れる。
実装にはDiscord Bot APIを使う。discord.py（Python）またはdiscord.js（Node.js）でBotを作り、スラッシュコマンドをプロダクトのAPIに繋ぐ。ユーザーが「/generate 猫のイラスト」と入力すると、BotがプロダクトのAPIを呼び出し、結果を同じチャンネルにそのまま投稿する。
シンプルなBotであれば開発者1人・1週間程度が実装の目安だ。Discord Developer Portalでアプリを登録してBot tokenを発行し、OAuth2でサーバーに招待、スラッシュコマンドをAPI側に登録する流れになる。先に設計しておくべきなのは認証と課金の扱いで、「Discordユーザーとプロダクトアカウントをどう紐づけるか」を後回しにするとあとで詰まる。OAuth2でプロダクト側のアカウント連携を最初から組み込んでおく。
ステップ3：アウトプットに「シェアしたくなる」要素を加える（2〜3日）
Midjourney画像が拡散するのは、単に質が高いからではない。画像の下に「by @ユーザー名」と「使ったプロンプト」が表示され、「自分が作った」という帰属感が生まれるからだ。
Botが結果を投稿するとき、「このユーザーが生成した」「使ったパラメータはこれ」という情報を添える。それだけで、作成者はスクリーンショットを撮ってSNSに投稿したくなる。SNSで「どこで作れる？」という反応が来て、Discordの招待リンクが広がる。この連鎖がチャネルとしての機能になる。
週次で「今週のベスト作品」を管理者がピックアップしてアナウンスする仕組みも効果的だ。選ばれたユーザーは誇りを感じ、選ばれたかった他のユーザーは使用頻度を上げる。コストはほぼゼロで、コミュニティの熱量を維持できる。
ステップ4：招待ループを計測して詰まりを取る（継続）
Discord招待リンクは複数発行して管理できる。「SNS告知用」「Webサイト設置用」「既存メンバー紹介用」と別々のリンクを発行し、どの経路からの参加が多いかを追跡する。UTMパラメータと組み合わせれば、Discord参加後にWebサイトへ戻ってきたユーザーまで追える。
計測すべき指標は3つに絞る。まず「初使用までの時間」——新規参加者が最初のコマンドを実行するまでが24時間以内かどうか。次に「週次アクティブ比率」——週1回以上コマンドを使うユーザーが全参加者の何割か。最後に「Discord経由のWebサイト流入数」——Discordがプロダクトページへの送客装置として機能しているか。最初の2週間でこの3指標を確認し、離脱が多い地点を一つ潰す、という作業を繰り返す。
ツール選定の考え方
Bot開発はdiscord.js（Node.js）かdiscord.py（Python）が主流だ。公式ドキュメントが充実していて、コミュニティも大きい。プロダクト本体がNode.jsで動いているならdiscord.jsで統一すると管理が楽になる。
コードを書かずに試したいなら、ZapierのDiscord連携でスモールスタートできる。「フォームが送信されたら→Botがチャンネルに投稿する」程度の動作なら実装ゼロで動く。ループが成立するかどうかの仮説検証として使うには十分だ。
モデレーションはMEE6かCombotを最初から入れておく。参加者が増えるとスパムやオフトピックな投稿が必ず出てくる。管理者が手動対応に追われると、本来のコミュニティ運営ができなくなる。自動モデレーションの設定は、サーバー立ち上げと同日にやっておく。
向いている製品・向いていない製品
この設計が機能するのは、アウトプットが「見てわかる」かつ「誰かに見せたい」製品だ。AI生成系、コード補助、デザインツール、データ可視化といった製品が典型例になる。初期ユーザー獲得の予算がなく、VCもついていないチームが動かせる数少ないチャネルの一つでもある。
向いていないのは、アウトプットが業務上の秘密に関わる製品、結果だけ切り出しても意味が伝わらない製品、B2Bで購買意思決定者がDiscordを使っていない業種だ。大企業の調達担当や経営幹部がDiscordで情報収集することはまずない。
また、立ち上げ時点でコアユーザーが10人に満たないなら、先にメールやSlackでそのコアを作ってからDiscordに移す方がいい。誰もいないサーバーに招待してもループは起動しない。最初の10人が毎日投稿してくれる状態を作ってから、外に広げる順番だ。
Midjourney型ループは「設計を正しくすれば自走する」ように見えるが、実態は最初の3ヶ月間、管理者がほぼ毎日コミュニティに時間を使っている。設計が機能し始めたら、初めて手を離せる。
AI編集部コメント
Midjourneyの成長に関する資料を調べていて気づいたのは、「Discordを使った」というより「Discordの構造に製品を合わせた」という点だった。多くのSaaSがDiscordをサポートチャンネルとして置いているのと、根本的に発想が違う。
リサーチ中に面白かったのはa16zの継続率データで、2.3倍という数字より「なぜ継続率が上がるか」の説明が興味深かった。「見られている」という意識が使用行動を変えるというのは、ゲームのスコアランキングと同じ原理だと思う。
記事には書ききれなかったが、このループはプロダクト自体の質が高い前提で動く。粗悪なアウトプットがpublicチャンネルに流れ続けると、逆に参加者が離れる。ループを回す前に、一人のユーザーが「これ見せたい」と思えるクオリティを担保することが先決だ。