「メンバーにもっと価値を届けたい」

そう思って、特典を増やす。
勉強会を増やす。
動画や資料を追加する。

コミュニティ運営をしていると、つい「何をもっと渡せるだろう」と考えます。

もちろん、コンテンツが充実していること自体は、とてもありがたいことです。

学ぶものがたくさんある。
新しい知識が手に入る。
参加するモチベーションにもなる。

ただ、ひとつ難しいことがあります。

コンテンツをたくさん渡したからといって、その人がコミュニティに愛着を持つとは限らない。

むしろ、受け取るものが増えすぎると、

「まだ見られていない動画がある」
「参加できていない勉強会がある」
「全然活用できていない」

と感じてしまうことさえあります。

そして、ある程度学び終わったところで、

「そろそろ卒業かな」

となる。

では、長く関わってくれる人は何が違うのでしょうか。

僕がコミュニティを運営してきて感じるのは、

「ここは運営者のコミュニティ」ではなく、「これは自分たちのコミュニティだ」と感じているかどうか

が、とても大きいということです。

人は「参加している場所」より「自分が関わっている場所」に愛着を持つ

コミュニティに参加したばかりの頃は、多くの人が受け手です。

イベントに参加する。
コンテンツを見る。
誰かの投稿を読む。

それでいいと思います。

ただ、ずっと「お客様」のままだと、コミュニティとの関係はなかなか深まりません。

一方で、長くいるメンバーを見ていると、少しずつ変化していきます。

新しい人に声をかけるようになる。
自分の経験を話してくれる。
イベントを手伝ってくれる。
企画を持ち込んでくれる。

その頃には、

「コミュニティに参加している」

というより、

「自分もこのコミュニティをつくっている」

という感覚が生まれています。

これは「心理的所有感」という考え方にも近いものです。

法律上、自分のものではない。

でも、

「これは自分の場所だ」
「自分もここに関わっている」
「なくなったら寂しい」

と思える。

この感覚が生まれると、コミュニティは単なる「サービス」ではなくなります。

「渡す」のではなく、「預ける」

ここで大事なのが、

運営者が全部やるのをやめること

です。

といっても、いきなり運営を丸投げする必要はありません。

僕が大切だと思っているのは、

コミュニティの一部を、メンバーに預けること。

全部ではなくていい。

ほんの一部分でいいんです。

たとえば、イベントの一部を担当してもらう。

5分だけ自分の経験を話してもらう。

新しく入った人への案内をお願いする。

自分の商品やサービスについて紹介できる時間をつくる。

こうした小さな「余地」があるだけで、立場が変わります。

「提供される側」から、

「一緒につくる側」へ。

原則1　役割を預ける

一番わかりやすいのは、小さな役割を持ってもらうことです。

イベントで司会をお願いする。

参加者への声かけをお願いする。

テーマについて5分話してもらう。

勉強会の一部分だけ担当してもらう。

ポイントは、

最初から大きな責任を渡さないこと。

コミュニティ運営を丸ごと任せる必要はありません。

むしろ、

「ここだけお願いします」

くらいの小ささから始める方が参加しやすい。

小さな役割でも、

「自分がいたから、この場が少し成立した」

という経験になります。

この経験が、自分ごとの入口になります。

原則2　経験を預ける

コミュニティで主体性を発揮する方法というと、

「たくさん発言する」
「リーダーになる」
「プレゼンに手を挙げる」

といった形を想像しがちです。

でも、それだけではありません。

普段あまり発言しない人でも、

自分の経験なら話せることがあります。

たとえば、

「この半年でやってみたこと」
「失敗したこと」
「仕事で工夫していること」
「最近乗り越えた壁」

などです。

人は、自分の経験が誰かの役に立ったときに、

「自分もこの場に価値を出せるんだ」

と感じます。

知識を与えるだけではなく、

その人が持っているものを、コミュニティに置ける場所をつくる。

これも「預ける」設計のひとつです。

原則3　挑戦できる場所を預ける

以前運営していたコミュニティでは、コミュニティ内でクラウドファンディングのような企画を行っていました。

メンバー自身が企画を立てる。

そして、その企画を見た別のメンバーが、

「応援します」

と手を挙げる。

自分の商品やサービスを、実際に誰かが支援してくれる。

この体験は、とても大きかったです。

なぜなら、

「このコミュニティの中に、自分のお客様が本当にいる」

と実感できるからです。

それまで、

「運営者のコミュニティに参加している」

と思っていた人が、

「ここは、自分の活動も育てられる場所なんだ」

と思い始める。

これは、心理的所有感を育てる大きな一歩でした。

「主体的な人だけが活躍できる場」にしない

ここで、ひとつ注意したいことがあります。

主体性というと、

声の大きな人や、前に出るのが得意な人ばかりが目立つ設計になりがちです。

でも、本当はもっといろいろな参加の仕方があっていい。

話すのが得意な人もいる。

文章を書くのが得意な人もいる。

誰かを支えるのが得意な人もいる。

商品をつくるのが得意な人もいる。

静かに参加しているけれど、あるテーマについては深い経験を持っている人もいます。

だから、

「リーダーになること」だけを主体性のゴールにしない。

これが大事です。

その人なりの関わり方を持てる余地があるか。

そこを設計する必要があります。

コミュニティ運営者は「与える人」から「余地をつくる人」へ

良い運営者ほど、

「もっと与えなければ」

と思います。

もっとコンテンツを。

もっとイベントを。

もっとサポートを。

でも、コミュニティが育ってくると、運営者の役割も少し変わります。

全部を提供する人ではなく、メンバーが関われる余地をつくる人になる。

もちろん、最終的にすべてをメンバーへ委ねる必要はありません。

コミュニティの性質によっては、運営者が強くリードした方がいい場合もあります。

完全な自治型コミュニティを目指すことが正解とも限りません。

でも、

一部を担当してもらう。

一部で主体性を発揮してもらう。

自分の商品や経験を伝えられる時間をつくる。

そうした小さな設計は、どんなコミュニティでも考えられるはずです。

渡すほど、愛着は生まれない

コンテンツを渡すことはできます。

知識を渡すこともできます。

特典も、イベントも、情報も渡せます。

でも、

愛着そのものを渡すことはできません。

愛着は、

自分が関わった。

自分が役に立った。

自分の挑戦を応援してもらった。

自分がこの場所の一部になった。

そんな経験の積み重ねから生まれます。

だから、コミュニティ運営で考えたい問いは、

「次に何を渡そうか」

だけではありません。

「次に、何を預けられるだろうか」

という問いです。

あなたのコミュニティには、

メンバーが「自分もここをつくっている」と思える余地がありますか。

コンテンツを渡すだけになっていないでしょうか。

小さくて構いません。

次のイベントの5分でもいい。

ひとつの役割でもいい。

誰かの経験を話してもらうだけでもいい。

運営の一部を、メンバーに預けてみる。

そこから、

「参加しているコミュニティ」が、

「自分のコミュニティ」へ変わっていくのだと思います。

事例付きさかい美佐のnote
https://note.com/msakai2025/n/n0ca6e69ab0f7
さかい美佐の5分でわかる音声要約
https://stand.fm/episodes/6a8a0d01e378f29a5f54bd28
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

過去の勉強会。
限定ライブ。
メンバー向け動画。
アーカイブ。

運営者からすると、

「せっかく作ったから、あとでぜひ見てほしい」

と思います。

でも、ここでひとつ考えたいことがあります。

あなた自身は、「あとで見よう」と保存した動画を、どれくらい実際に見ていますか？

おそらく、多くの人が経験しているはずです。

「あとで見る」は、悪い意思ではありません。

むしろ、その瞬間は本当に見るつもりです。

ただ、人間は「いつでも見られるもの」を後回しにしやすい。

だから問題は、メンバーの意欲ではありません。

「あとで見られる状態」にしてしまう設計そのものです。

コミュニティ運営で大切なのは、コンテンツを増やすことだけではありません。

どうすれば、メンバーが価値を受け取れる状態を作れるか。

今回は、継続視聴を生むための3つの設計ポイントを整理します。

見出し構成案

1. 「あとで見る」に期待しすぎない

アーカイブは便利です。

しかし便利だからこそ、優先順位が下がります。

人は、

「今見なければ損するもの」

よりも、

「いつでも見られるもの」

を後回しにします。

だから「見てください」とお願いするだけでは、継続視聴は生まれません。

2. 視聴期限は「運営都合」ではなく「見る理由」とセットにする

期限設定は有効です。

ただし、

「○月○日までに見てください」

だけでは、運営側の都合に見えてしまいます。

大切なのは、

「なぜ、そのタイミングで見る価値があるのか」

を伝えること。

例えば、

• 年始の目標設計 → 1月に見るから意味がある

• 新年度の準備 → 始まる前に見る価値がある

期限ではなく、タイミングの理由を作る。

これが継続視聴につながります。

3. 1時間の動画を見る前提を捨てる

忙しい人にとって、1時間の動画を見ることは大きな投資です。

だからこそ、

• 3分で読める要約

• ポイントだけまとめた図解

• AIで整理したマインドマップ

• 箇条書きまとめ

を用意する。

重要なのは、

「全部見てもらうこと」

ではありません。

「価値を受け取ってもらうこと」

です。

動画を最後まで見てもらえなくても、要点が届けば関係は深まります。

4. AI時代のコミュニティ運営は「要約」が武器になる

現在はAIを使えば、

• 動画の文字起こし

• 要約

• 図解化

• チェックリスト化

が短時間でできます。

運営者がすべて手作業で整理する必要はありません。

メンバーの時間を奪わない設計こそ、これからのコミュニティには必要です。

まとめ

コミュニティの価値は、コンテンツ量だけでは決まりません。

どれだけ素晴らしい動画があっても、

「あとで見る」

のまま眠ってしまえば、価値は届きません。

大切なのは、

• 今見る理由を作る

• 見る負担を減らす

• 要点だけでも価値を届ける

こと。

あなたのコミュニティは、

「いつか見る場所」

になっていますか？

それとも、

「今、価値を受け取れる場所」

になっていますか？

事例付きさかい美佐のnote
https://note.com/msakai2025/n/n6571d7a124fc
さかい美佐の5分でわかる音声要約
https://stand.fm/episodes/6a88bcbef0338f5133a61ecb
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

「もう少し料金を下げたら、継続してくれる人が増えるのではないか」

「もっとコンテンツを増やせば、満足度が上がるのではないか」

「毎日投稿したほうが、価値を感じてもらえるのではないか」

もちろん、価格やコンテンツ量は大切です。

しかし、実際のコミュニティ運営では、不思議なことが起こります。

同じ月額料金でも、

「少し高いけれど、ここは続けたい」

と思う人がいる一方で、

「この金額なら今月は削ろう」

と判断する人もいます。

なぜでしょうか。

違いを生むのは、金額そのものではありません。

そのお金を、本人がどの「財布」に入れているかです。

人は金額ではなく「意味」でお金を判断している

心理学や行動経済学には、**メンタルアカウンティング（心の会計）**という考え方があります。

簡単に言えば、人はお金を完全にひとつの数字として管理しているわけではなく、頭の中で用途ごとに分類して考えている、というものです。

例えば同じ5,000円でも、

「生活費」

として見る場合と、

「学習費」

として見る場合では、心理的な負担が変わります。

また、

「娯楽費」

として考える場合と、

「未来への投資」

として考える場合でも、そのお金への向き合い方は変わります。

コミュニティの月額費用も同じです。

メンバーが、

「毎月払うサービス料金」

として見ているのか、

「自分を成長させるための投資」

として見ているのか。

ここで継続への判断が変わります。

つまり、コミュニティ運営で考えるべきなのは、

「どうやって安くするか」

だけではありません。

むしろ重要なのは、

「この場所を、メンバーの中でどの財布に入れてもらうか」

なのです。

コミュニティが「消費」になる瞬間

では、コミュニティが消費として扱われるのは、どんな時でしょうか。

例えば、

• なんとなく参加している

• 投稿を見るだけになっている

• 楽しいけれど、自分の変化につながっていない

• 入っている理由を説明できない

こうなると、月額料金は「なくても困らないもの」になりやすくなります。

人は、削減対象を探すとき、

「なくても生活できるもの」

から見直します。

その時、コミュニティが単なる娯楽として分類されていると、最初に候補になってしまう可能性があります。

しかし、ここで誤解してはいけません。

「楽しいことには価値がない」

という話ではありません。

むしろ、楽しいという感覚はコミュニティにとって非常に重要です。

人とのつながり。

安心して話せる場所。

挑戦を続けるためのエネルギー。

孤独にならない環境。

これらは、人生や仕事を前に進めるための大切な価値です。

問題は、

その楽しさが、どんな価値につながっているのかが伝わっているか

です。

「楽しい」から「意味がある」へ

例えば、あるコミュニティがあります。

毎月オンライン交流会を開催していて、参加者同士の会話が盛り上がっています。

ただ、運営者が、

「毎月楽しい交流会をしています」

だけを伝えている場合。

メンバーによっては、

「楽しいけど、忙しくなったら優先順位は下がるかな」

となるかもしれません。

一方で、

「この交流会は、同じ挑戦をしている仲間と出会い、継続するための環境です」

と伝えていたらどうでしょうか。

同じ活動でも、意味づけが変わります。

楽しい時間が、

「娯楽」

ではなく、

「継続するための環境投資」

になる可能性があります。

コミュニティ運営者の役割は、価値を作ることだけではありません。

すでに存在している価値を、メンバーが理解できる形に翻訳すること

も重要なのです。

継続されるコミュニティを作る3つの設計原則

では、メンバーがその場を「自己投資」と感じるためには、何が必要なのでしょうか。

ここでは3つのポイントに整理します。

原則1：未来の変化を見せる

多くのコミュニティは、提供している内容を説明します。

「毎週勉強会があります」

「教材があります」

「交流会があります」

もちろん大切です。

しかし、メンバーが本当に知りたいのは、

「それによって、自分はどう変わるのか」

です。

例えば、

「AIについて学べます」

よりも、

「AIを使って、毎週3時間の作業時間を減らせるようになる」

のほうが未来が想像できます。

コンテンツではなく、変化を伝える。

これが自己投資として認識される第一歩です。

原則2：活用される仕組みを作る

どれだけ良いコンテンツがあっても、使われなければ価値として感じられません。

運営者側は、

「良いものを提供した」

と思っていても、

メンバー側は、

「結局、何をすればいいかわからなかった」

となることがあります。

だからこそ、

• 最初に何をするのか

• どんな順番で参加するのか

• どんな小さな成果を得られるのか

を設計することが重要です。

価値は、存在するだけでは伝わりません。

体験されて初めて価値になります。

原則3：楽しさの価値を言語化する

コミュニティには、学習や成果だけでは説明できない価値があります。

例えば、

• 同じ価値観の人と出会える

• 一人では続かないことを続けられる

• 前向きな刺激を受けられる

• 安心して挑戦できる

こうしたものです。

しかし、運営者がこれを「ただの交流」と考えてしまうと、価値として伝わりません。

楽しさは、おまけではありません。

人が継続するための重要な要素です。

だからこそ、

「楽しい場所です」

ではなく、

「なぜ、その楽しさがメンバーの人生や活動に役立つのか」

まで伝えることが大切です。

全員に残ってもらう必要はない

ここまで継続率について書いてきましたが、最後に大切なことがあります。

それは、

すべての人に残ってもらう必要はない

ということです。

人には、それぞれタイミングがあります。

仕事が忙しくなる。

環境が変わる。

別のことに集中する。

その結果、コミュニティを離れる人がいるのは自然なことです。

大切なのは、退会をゼロにすることではありません。

必要な人にとって、

「ここに参加してよかった」

と思える場所を作ることです。

在籍した期間が、

「楽しかった」

だけで終わるのか。

それとも、

「自分の成長や挑戦につながった」

になるのか。

その違いを作るのが、運営者の役割なのだと思います。

あなたのコミュニティは、メンバーの中でどの財布に入っていますか？

月額料金を下げる。

コンテンツを増やす。

投稿頻度を上げる。

これらも大切な改善です。

でも、その前に考えたい問いがあります。

このコミュニティは、メンバーにとって何なのか。

消費なのか。

自己投資なのか。

そして、

その価値はちゃんと言葉になっているのか。

人は金額だけで継続を決めません。

その場所が、自分の人生にどんな意味を持つのか。

そこが見えた時、月額費用は単なる支出ではなくなります。

あなたのコミュニティは、メンバーの「心の財布」の中で、どこに分類されていますか？

事例付きさかい美佐のnote
https://note.com/msakai2025/n/n734223b44a91
さかい美佐の５分要約音声
https://stand.fm/episodes/6a876b5d8bc29be7f1cbdfcb
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

「あ、これはみんなに送っている文章だな」

メッセージを読んだ瞬間、そんなふうに感じることはありませんか。

名前はちゃんと自分のものになっている。

冒頭には、

「○○さんへ」

と書いてある。

文章も丁寧です。

でも、なぜか「自分に向けて書かれた」という感じがしない。

私は、こういう状態をよく「透けて見える」と表現しています。

テンプレートなのか。

AIで生成された文章なのか。

一斉送信の文面に、名前だけ差し込んだのか。

もちろん、本当のところは受け取った側には分かりません。

それでも、

「これは私だけに向けて書かれたものではないな」

ということは、意外と伝わるものです。

AIを使うこと自体が問題なのではない

最初にお伝えしておくと、私はAIに文章を書かせること自体を悪いとは思っていません。

むしろ今は、さまざまな文章の裏側にAIが関わっているのが自然な時代になってきました。

私自身も、発信をつくるときにAIを使います。

テーマ案を出してもらう。

文章の細かい表現を整えてもらう。

構成を整理してもらう。

そういうことは日常的にやっています。

ただし、私の中ではひとつ大事にしていることがあります。

その文章の「元」が、どこから来ているか。

ここです。

たとえば、AIにテーマを3つ提案してもらったとしても、どれを選ぶかは私が決めます。

そして、そのAIに読み込ませているのも、私自身が書いてきたKindle書籍や講座、過去の文章です。

出てきた内容が、

「なんだか私の考えとは違うな」

と思えば、そこからAIとやり取りして修正します。

つまり、細かい文章を書くのはAIでも、

何を伝えたいのか。
何を大切にしているのか。
どこに違和感を持つのか。

その出発点までは、AIに丸投げしていません。

「AIっぽさ」の正体は、文章の上手さではない

AIが書いた文章というと、

「きれいすぎる文章」

「妙に整った文章」

を想像する人もいるかもしれません。

もちろん、それもひとつあります。

でも私は、もう少し本質的な違和感があると思っています。

それは、

「この人が、私を見て書いた感じがしない」

ということです。

言っていることは正しい。

文章も自然。

励ましてくれている。

でも、

「これは誰にでも当てはまるよね」

と思えてしまう。

心理学では、誰にでも当てはまりそうな曖昧な表現を「自分のことだ」と感じる現象を、バーナム効果と呼びます。

AIは、こうした「多くの人にそれらしく当てはまる文章」を作るのがとても得意です。

だからこそ、文章としては成立していても、

一対一のコミュニケーションとして読むと、どこか薄く感じることがあります。

では、全部個別に書けばいいのか

ここで反対側に振り切って、

「じゃあ、全部のメッセージを一人ひとり個別に書きましょう」

となると、それも現実的ではありません。

私はコミュニティの運営側でもあるので、この大変さはよく分かります。

100人、500人、1000人に対して、

すべて違う文章を書く。

これは無理です。

そして実は、受け取る側にとっても、すべての連絡が毎回パーソナルである必要はないと思っています。

イベントのお知らせ。

全員に共有したい変更事項。

今週の予定。

こうしたものまで毎回、

「○○さんは先日こうおっしゃっていたので……」

と個別化されていたら、少しお腹いっぱいになります。

だから私は、

全体に送る言葉と、その人に届ける言葉を分ける。

これが大切だと思っています。

私が考える、AIと人の役割分担3原則

では、どこをAIに任せ、どこを人に残すのか。

私は、次の3つで考えています。

1. 全員に伝える情報は、AIを使って効率化していい

日時、場所、ルール、案内、要点整理。

こうした情報は、相手によって内容を変える必要がありません。

むしろAIを使って、

分かりやすくする。

抜け漏れを減らす。

読みやすく整える。

そのほうが、受け取る側にも親切です。

「AIを使わないこと」を目的にする必要はありません。

2. 「あなたに伝えたい理由」は、人が決める

個別メッセージで重要なのは、

文章全部を手書きすることではありません。

たった一行でもいいんです。

たとえば、

「先日の○○のお話を聞いて、この件はぜひお伝えしたいと思いました」

「以前、○○で悩んでいると話されていたので、もしかすると役立つかもしれません」

「今日のお話のときの表情が少し気になっていました」

こうした一行があるだけで、メッセージの意味は大きく変わります。

これは「名前を知っている」だけでは書けません。

なぜ、その人に今この言葉を届けるのか。

ここは、人が持っておきたい部分です。

3. テキストになっていない情報は、人が拾う

生成AIが扱える材料の中心は、基本的にはデータになっている情報です。

特に文章生成では、テキストとして与えられたものが大きな材料になります。

でも、人と実際に話していると、それ以外の情報がたくさんあります。

声のトーン。

表情。

間。

いつもより少し元気がなかったこと。

話題を変えた瞬間。

逆に、ある話をしたときだけ急に表情が明るくなったこと。

コミュニティでは、こうしたものも「その人を知る」ということの一部です。

現時点では、こうした文脈を日常の関係性の中から拾って、

「この人には、今この言葉を伝えよう」

と判断する役割は、人に残しておく価値があると思っています。

大事なのは「全部AI」か「全部人間」かではない

AIについて話すと、

「AIを使うべきか、使わないべきか」

という二択になりがちです。

でも、私はそうではないと思っています。

自動送信するものがある。

全員に同じ内容を送るものがある。

一部だけ個別にするものがある。

完全に一対一で書くものもある。

この切り替えがあるから、コミュニケーションに緩急が生まれます。

すべてを手書きする必要はない。

すべてをAIにする必要もない。

どこを共通化して、どこから個別にするのか。

その境界線を、人が設計する。

これからは、その力のほうが大切になっていくのかもしれません。

「あなただけ」は、宛名ではなく文脈に宿る

名前を差し込めば、個別メッセージの形にはなります。

でも、

「あなただけに書きました」

という感覚は、名前から生まれるわけではありません。

その人と交わした会話。

その人が話していた悩み。

そのときの表情。

一緒に過ごした時間。

そういう文脈が、一行に入ったときに初めて、

「これは私に向けた言葉だ」

と感じてもらえるのだと思います。

だから、AI時代のパーソナライズで大事なのは、

文章をどこまで自動生成できるかではなく、

人にしか持てない文脈を、どこに残すか。

なのかもしれません。

あなたが最近送ったメッセージを、ひとつ思い出してみてください。

そこにあるのは、

「宛名が変わっただけ」の一文でしょうか。

それとも、

**「その人にしか書けない一行」**があるでしょうか。

事例付きさかい美佐のnote
https://note.com/msakai2025/n/n0d4d95e3c5e2
さかい美佐の５分要約音声
https://stand.fm/episodes/6a861a20261f2173b5d9a27c
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

コメントをしてくれる人。

質問をしてくれる人。

イベントに参加してくれる人。

リアクションを返してくれる人。

こうしたメンバーは、もちろんコミュニティにとって大切な存在です。

場を盛り上げてくれる。
他の人の参加を促してくれる。
文化づくりにも大きく貢献してくれる。

運営者にとって、とてもありがたい存在です。

一方で、もうひとつ大切な存在があります。

それが、

読んでいるけれど、まだ発言していない人

です。

「発言しない = 関心がない」ではない

運営者側から見ると、反応がない人は見えません。

投稿してもコメントがない。

案内を出しても返信がない。

イベントを開催しても参加者が増えない。

そんな状態が続くと、

「ちゃんと届いているのかな？」

「誰も興味を持ってくれていないのでは？」

と不安になることがあります。

でも、ここで一度立ち止まって考えてみる必要があります。

人との関係は、必ずしも発言から始まるわけではありません。

まず読む。

内容を理解する。

何度も目にする。

少しずつ信頼が積み重なる。

その先で、初めて言葉になる人もいます。

静かな読者にも、すでに関係性は生まれている

コミュニティや発信では、つい「目に見える行動」を重視しがちです。

コメント数。

いいね数。

投稿への返信。

もちろん、これらは重要な指標です。

しかし、それだけを見ると見落としてしまうものがあります。

それは、

一方向の認知（アンビエント・アウェアネス）

です。

まだ会話はしていない。

まだ名前も覚えていないかもしれない。

でも、

「この人の発信はいつも見ている」

「このテーマなら、この人の話を聞きたい」

という状態は、すでに関係性の入り口にあります。

街でよく見るお店が、いつの間にか気になる存在になるように。

何度も触れることで、人への理解や親近感は少しずつ育っていきます。

サイレントメンバー活性化の3原則

では、読んでくれているけれど発言していない人と、どう関係を育てればいいのでしょうか。

ポイントは、

無理に発言させないこと

です。

「いつも読んでくださっていますよね。ぜひ意見をください！」

と突然前に出してしまうと、かえって心理的なハードルを上げてしまうことがあります。

大切なのは、その人が自然に参加できる余白を残すことです。

原則1：存在を「反応」ではなく「行動」で見る

まず必要なのは、印象で判断しないことです。

「コメントがないから関心がない」

ではなく、

「実際にはどう関わっているのか」

を見る。

記事の閲覧。

メールの開封。

動画の視聴。

継続的なアクセス。

こうした行動を見ることで、

「この人は何もしていない」

ではなく、

「静かに参加してくれている」

という見方ができます。

運営者自身の心理的安心感にもつながります。

原則2：いきなり発言者にしようとしない

サイレントメンバーに対して、最初から大きな参加を求める必要はありません。

発言。

投稿。

イベント登壇。

いきなりそこを目指すと、参加のハードルが高くなります。

まずは、

• 読む

• 小さなリアクションをする

• 個別に感想を送る

• 小さな質問をする

そんな小さな接点から始まります。

コミュニティへの参加には段階があります。

静かに見ている期間も、その人にとって必要な準備期間なのです。

原則3：1対1の接点を大切にする

意外と多いのが、

「みんなの前では発言しないけれど、個別では話してくれる人」

です。

大人数の場では発言しづらい。

でも、運営者との1対1なら意見を伝えられる。

こういう方は少なくありません。

その時に届いた言葉は、コミュニティ改善の大きなヒントになります。

また、その人にとっても、

「自分のことを見てくれている」

という感覚につながります。

コミュニティの文化は、目立つ人だけで作られるものではありません。

静かな参加者との関係も含めて、少しずつ育っていきます。

まとめ：静かな人は、まだ関係がない人ではない

コミュニティ運営で大切なのは、

「どうやって発言者を増やすか」

だけではありません。

その前に、

「すでに関わってくれている人を、どう理解するか」

があります。

コメントしてくれる人も大切。

でも、読むだけで支えてくれている人も大切です。

見えている反応だけで、人との距離を判断しない。

数字と行動を見る。

そして、その人のペースを尊重する。

読まれているだけで、関係はもう始まっています。

あなたのコミュニティにも、まだ声には出していないけれど、しっかり見守ってくれている人がいるかもしれません。

一度、静かなメンバーにも目を向けてみてください。

そこから、新しい関係が始まるかもしれません。

事例付きさかい美佐のnote
https://note.com/msakai2025/n/n484448d91e7f
さかい美佐の５分要約音声
https://stand.fm/episodes/6a84d650885c6ced774662db
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

「じゃあ、今日もいつものやつで」

「例の件、お願いします」

「前回と同じ感じでいきましょう」

長く続いているコミュニティほど、こういう言葉が増えていきます。

そして、私はこれ自体が悪いことだとは思っていません。

「いつものやつ」で通じるのは、それだけ一緒に過ごしてきた時間があるということです。

「あれね」で笑える。

説明しなくても伝わる。

それは、既存メンバーにとっては一種の絆です。

でも、同じ言葉が、新しく入った人にとっては壁になることがあります。

「わからない人」は、わからないと言ってくれない

コミュニティを運営していると、ときどきこんな場面があります。

最初はZoomで顔を出して参加していた人が、途中からカメラをオフにする。

しばらくすると、発言もなくなる。

そして、そのまま退出してしまう。

理由を直接聞けることは、ほとんどありません。

けれど、その人の中では、

「みんなが何を話しているのかわからない」

「自分だけ話についていけていない」

「ここは自分のいる場所じゃないのかも」

ということが起きているかもしれません。

運営者にとって、これはとても悲しいことです。

特に気になるのが、

「私、新しいので、よくわかっていません」

という言葉です。

何がわからないのかではなく、

「全体的によくわからない」。

こうなってしまうと、本人も質問のしようがありません。

実は、新しい人がつまずくのは、難しい専門用語だけではないんです。

むしろ、

「いつもの」
「例の」
「前回の」
「あれ」
「定番の」

といった、既存メンバーには説明不要の言葉のほうが厄介なことがあります。

これは「知識の呪縛」で起きる

自分が知っていることを、「知らない状態」で考えるのは意外と難しいものです。

運営を長く続けている人ほど、

「これはみんな知っているだろう」

「前に説明したから大丈夫」

「いつもやっていることだから伝わる」

と思いやすくなります。

でも、新しく入った人には、その「前」がありません。

運営者には100回目でも、その人にとっては1回目です。

ここに、知識を持っている側と持っていない側のズレが生まれます。

だから私は、コミュニティのオンボーディングでは、

内輪の言葉を禁止するのではなく、“翻訳する”ことが大切

だと考えています。

そのための原則を3つに整理します。

原則1　内輪の言葉を、なくそうとしない

まず大切なのは、

「内輪の言葉＝悪」と考えないこと。

「いつものやつ」が通じる関係性は、そのコミュニティが積み上げてきた文化でもあります。

全部を初心者向けの説明に置き換えてしまうと、今度は既存メンバーにとって居心地の悪い場所になってしまうかもしれません。

大事なのは、内輪感を消すことではありません。

新しい人にも入口を用意することです。

たとえば、

「いつもの自己紹介をやります」

ではなく、

「いつもの自己紹介をやります。初めての方へ説明すると、名前・住んでいる場所・最近ハマっていることを一人30秒くらいで話すものです」

と、一言足す。

これだけで、新しい人は参加できます。

既存メンバー同士のテンポも、ほとんど壊れません。

つまり、

既存メンバー向けの言葉＋新しい人向けの翻訳

という二層構造にするわけです。

原則2　「用語集を読んでおいて」で終わらせない

では、コミュニティ内の言葉を全部まとめた「用語集」を作ればいいのでしょうか。

もちろん、用語集そのものが悪いわけではありません。

スタッフ間で知識を共有するときには、とても便利です。

コミュニティでも、「こんな言葉がありますよ」というネタ的な用語集を置いておくのはいいと思います。

ただ、新しく参加した人に、

「わからない言葉は用語集を見てください」

と任せてしまうのは、少し違います。

なぜなら、新しく入った人にとって用語集は、

「これを覚えないと参加できない単語帳」

のように見えることがあるからです。

学生時代のテスト前みたいですよね。

コミュニティに入りたいだけなのに、最初に専門用語を勉強しなければいけない。

それでは参加のハードルが上がります。

だから、用語集があるとしても、基本はその場で翻訳する。

文章なら、

「○○（このコミュニティで毎週行っている振り返り会のこと）」

と括弧書きする。

会話なら、

「例の企画……あ、新しく入った方には初めてですね。先月からやっている○○企画のことです」

と一言添える。

これだけでいいんです。

覚える責任を、新しい人だけに背負わせない。

これはオンボーディングではかなり重要だと思っています。

原則3　「質問してください」ではなく、運営側から先に翻訳する

運営側はつい、

「わからないことがあったら、何でも聞いてくださいね」

と言います。

私も言います。

もちろん、それ自体は大切です。

でも、ここには一つ問題があります。

新しい人ほど、質問しづらい。

すでに盛り上がっている会話を止めて、

「すみません、それって何ですか？」

と聞くのは、かなり勇気がいります。

しかも本人は、何がわかっていないのかすら整理できていないかもしれません。

だから、

「質問されたら説明する」

だけでは足りません。

運営者の側から、

「これは新しい人にはわからないかもしれない」

と気づいて、先回りして翻訳する必要があります。

たとえばオンラインイベントなら、録画や文字起こしをAIで確認してみるのも一つの方法です。

• 内輪だけで使っている略称

• 「いつもの」「例の」など、前提知識が必要な表現

• 初参加者には意味のわかりにくい固有名詞

• 説明なしに使っている専門用語

こうした言葉を拾い、

次回から説明を足す。

あるいは、アーカイブに簡単な補足を入れる。

運営を続けている本人には見えなくなった「わかりにくさ」を、あとから発見することができます。

AIは、こういう使い方にも向いています。

大事なのは「初心者扱い」することではない

ここで一つ注意したいことがあります。

新しい人に説明することと、その人を「何も知らない初心者」として扱うことは違います。

何でもかんでも、

「これはですね……」

と長々説明すると、かえってうっとうしくなります。

必要なのは講義ではありません。

その会話に入るための、ほんの一言の橋渡しです。

「いつものやつです」

だけなら壁になる。

でも、

「いつものやつです。初参加の方向けに説明すると、○○のことです」

なら、扉になる。

たった一言です。

でも、その一言があるかどうかで、

「自分はここにいていい」

と思える人がいるのではないでしょうか。

コミュニティが長く続くほど、「翻訳」が必要になる

コミュニティが育つと、文化ができます。

共通言語ができます。

思い出が増えます。

「あれ」で通じるようになります。

それは、コミュニティが成熟してきた証拠でもあります。

だから、なくす必要はありません。

ただし、コミュニティが成熟すればするほど、運営者にはもう一つの役割が増えます。

古くからいる人と、新しく入った人の間を翻訳すること。

私は、これもオンボーディングの一部だと思っています。

新しい人が入るたびに、コミュニティの言葉を全部覚えてもらうのではなく、

その人が自然に会話へ参加できるよう、こちらから橋をかけていく。

その小さな積み重ねが、

「新しく入っても居場所があるコミュニティ」

を作っていくのだと思います。

最後に、あなたのコミュニティを少しだけ思い返してみてください。

最近、

「いつもの」
「例の」
「前回の」
「定番の」

という言葉を使った場面はありませんでしたか？

その場に初めて来た人がいたとしたら、

その人にも意味が伝わる話し方になっていたでしょうか。

内輪の言葉は、絆にもなる。

でも、翻訳されなければ壁にもなる。

コミュニティを長く続けるほど、ときどき「初めて来た人の耳」で、自分たちの会話を聞き直してみたいですね。

事例付きさかい美佐のnote
https://note.com/msakai2025/n/n83fd53b5484d
さかい美佐の５分要約音声
https://stand.fm/episodes/6a8377dbc1de3c345d64adfb
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

「コミュニティをもっと活性化したい」

そう思うと、つい考えるのは、

• 新しいイベントをやる

• 投稿企画を増やす

• 新しいチャンネルを作る

• メンバーへの声かけを増やす

みたいな、「何かを足すこと」だったりします。

でも最近、むしろ逆なんじゃないかと思っています。

場を動かしたいなら、先に“終わったもの”を手入れする。

これ、地味なんですが、かなり大事です。

終わった告知は、運営者の中でしか終わっていない

イベント募集が終わった。

運営者の頭の中では、その瞬間に「終了」のスタンプが押されます。

だから、もう終わったものとして認識しています。

でも、ページは残っています。

申し込みボタンも残っている。

過去のお知らせもそのまま。

古いスレッドも残っている。

そして読者やメンバーは、こちらが思っている以上に、そういう古いページを見ています。

実際、終わったLPをあとから見てみると、意外にアクセスが残っていることがあります。

しかも、

「申し込もう」と思ってボタンを押す
↓
募集は終わっている
↓
その先で止まる

ということもあります。

運営側からすると「もう終わったページ」。

でも訪問者からすると、いま初めて出会ったページなんですよね。

ここに大きなズレがあります。

問題は「古いこと」ではなく、「いま何が生きているのか分からないこと」

古い情報が残っていること自体が、すべて悪いわけではありません。

過去イベントの記録を見たい人もいます。

あとから内容を振り返りたい人もいる。

だから、

古いもの＝全部削除

ではないと思っています。

大事なのは、

「いま申し込めるのか」
「もう終わっているのか」
「次にどこへ行けばいいのか」

が分かることです。

たとえば、募集が終わったLPなら、

• 申し込みボタンを消す

• 「募集は終了しました」と書く

• 次回案内のページへつなぐ

• 終了ページへリダイレクトする

これだけでも、かなり違います。

できれば、終了したものをまとめて受け止めるページを1枚作って、そこへ飛ばしてしまうのがきれいです。

404になって終わるより、

「この募集は終了しました。現在はこちらをご案内しています」

と書いてあるほうが、ずっと親切です。

消す・残す・上に重ねる

最近、古い情報の扱いは、この3つに分けると整理しやすいなと思っています。

1. 消す

明らかに役割を終えたもの。

たとえば、

「あと3名です」

「○月○日締切」

「お申し込みはこちら」

といった、期限が切れた誘導文です。

ページ自体に記録としての価値があっても、募集文面まで残す必要はありません。

2. 残す

過去のイベントページや、あとから読んでも意味がある記録。

これは無理に消さなくていい。

ただし、

「これは過去の情報です」

と分かる状態にはしておきたいです。

3. 上に重ねる

これが意外と便利です。

古い告知を消すか迷うなら、

新しい「終了しました」のお知らせを、その上に置く。

サイトのお知らせ欄なら、

「○○イベントは終了しました」

と新しく1本出す。

あるいは、過去のお知らせタイトルに「終了」と付ける。

それだけで、「放置されている感じ」がかなり減ります。

消すか残すかの二択ではなく、

“いまの状態を伝える情報を上に重ねる”

という方法もあるんですよね。

フィード型とストック型では、優先順位が違う

全部を同じ熱量で片づける必要もありません。

たとえばSNSのフィードは、古い投稿ほど下へ流れていきます。

そういう場所なら、過去の告知が多少残っていても、影響は比較的小さい。

一方で、

• LP

• 会員サイトのトップ

• 固定ページ

• 使われていないスレッド

• メニューからいつでも行けるページ

みたいな「居座る情報」は、優先して手入れしたほうがいい。

つまり、

流れていく情報より、残り続ける情報から直す。

この順番です。

私はAIに「終わったもの」を探してもらっています

とはいえ、こういう古いリンクや告知を、自分ですべて把握するのは結構大変です。

私はこれがかなり苦手です。

なので最近はAIに、

「この中から、もう終了していて、削除または修正したほうがいいものをピックアップしてください」

とお願いしています。

これだけでも、かなり楽になります。

運営者は、毎日の仕事の中で新しいものを作ることには意識が向きます。

でも、

「半年前に出した告知がどうなっているか」

までは、なかなか頭に残っていません。

こういう人間には把握しきれない棚卸しは、AIと相性がいい仕事だと思っています。

「投稿が少ない」の前に、「投稿したくなる場か」を見る

コミュニティで投稿が少ないと、

「もっと投稿してください」

と言いたくなります。

でも、その前に一度見てみたい。

トップページに去年の告知が残っていないか。

押せない申し込みボタンがないか。

誰も使っていないスレッドが並んでいないか。

古い質問が放置されていないか。

そういうものが積み重なると、それだけで

「ここ、いま動いているのかな？」

という印象になります。

場は、説明文だけで「活発です」と言っても活発には見えません。

いま動いているものが、ちゃんといちばん目に入る。

それが大事なんだと思います。

だから、投稿を増やしたいときほど、

「何を足そう？」

ではなく、

「いま、何を終わらせたほうがいい？」

と考えてみる。

コミュニティの手入れは、新しい企画を足すことだけではありません。

終わったものを消す。

残すものには、終わったことを伝える。

そして、いま生きているものを前に出す。

この「引き算」ができるだけで、場の見え方はかなり変わります。

あなたのコミュニティには、

もう終わっているのに、まだ“現役の顔”をして残っているものはありませんか？

事例付きさかい美佐のnote
https://note.com/msakai2025/n/n38a235b90d03
さかい美佐の５分要約音声
https://stand.fm/episodes/6a82248e5e9572e804f8bdc2
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

普通に考えれば、そうなりそうです。

でも実際には、逆のことが起こります。

人数が増えるほど、

「いつも同じ人と話している」

「新しい人に声をかけづらい」

「知っている人のいる場所にしか行かない」

という状態になっていきます。

不思議ですよね。

100人も300人もいるのに、自分が話しているのはいつもの3人。

世界は広がったはずなのに、体感としては狭くなっている。

今日は、そんなコミュニティの中にある“穴”に、どう橋を架けるかという話です。

人のネットワークは、蜂の巣のようには広がらない

人のつながりは、全員が均等につながった蜂の巣のようには広がっていきません。

実際には、

小さな塊ができる。

その横に、また別の小さな塊ができる。

そして、その塊同士を一本の線でつなぐ人が現れる。

そんな形で広がっていきます。

コミュニティ運営をしていると、この動きはとてもよく見えます。

たとえば、

「朝活によく参加する人たち」

「ある分科会に集まる人たち」

「地域支部で仲良くなった人たち」

「同じテーマに興味がある人たち」

という小さな集団が、自然に生まれます。

これは悪いことではありません。

むしろ、居場所ができた証拠です。

ただし、ここでひとつ問題が起きます。

その小さな塊の中だけで、関係が完結してしまうことです。

1対3なら話せる。でも1対300では話せない

コミュニティに入ったばかりの人の気持ちを想像してみてください。

自分以外に3人しかいなければ、

「こんにちは」

と3人に話しかければいい。

ところが300人いたら、どうでしょう。

知らない人が299人いる。

誰に話しかければいいかわからない。

何を話せばいいかわからない。

すでに仲良さそうな人たちの輪には入りづらい。

そうなると、一番わかりやすい相手に話しかけます。

運営者です。

コミュニティが大きくなるほど、運営者に会話が集中しやすくなる理由のひとつは、ここにあります。

「人見知りだから」

「積極性がないから」

だけではありません。

構造上、そうなりやすいのです。

だから運営者は、

「もっとみんな自由に交流してください」

と言うだけではなく、

人と人がつながりやすい構造を作る必要があります。

まずは、小さな居場所を作る

最初の一歩として、とても機能するのが少人数の場です。

分科会。

部活。

オンライン交流会。

地域支部。

2人、3人、5人程度で話せる小さな場。

いきなり300人の中から友達を作るのは難しくても、5人なら話せます。

そこで一人知り合いができる。

次にその人が、別の誰かを紹介してくれる。

この連鎖が始まると、コミュニティの中に自分の居場所ができます。

入会後のオンボーディングでも、最初のゴールはここです。

いきなり深い交流を求めなくていい。

まず、

運営者以外の人をひとり知っている状態を作る。

これだけでも大きく変わります。

たとえば、会員サイトのスレッドをひとつ読んでもらうだけでもいい。

相手はこちらを知らなくても、自分はその人の投稿を読んだことがある。

それだけで、次に会ったとき

「あ、この人知ってる」

になります。

私はこれを、勝手に「勝手な知り合い」と考えています。

プロフィールを書いてもらうのも同じです。

プロフィールを読んだ誰かの中に、その人の存在が残ります。

発言するのが苦手なら、オンラインイベントで名前を呼ぶだけでもいい。

覚えやすい肩書きを添えて紹介するだけでもいい。

一方向の認知でも、人間関係のゼロ地点からは一歩進みます。

ただし、小さな居場所だけでは足りない

分科会や部活がうまくいくと、次の問題が起きます。

その場所にしか参加しなくなる。

これはコミュニティ運営では、かなりよくあります。

本人からすれば当然です。

気の合う人がいる。

話しやすい。

安心できる。

わざわざ知らない人のいる場所に出ていく理由がありません。

ここで大切なのが、

小さな塊と小さな塊のあいだに橋を架けることです。

原則1　分科会を「孤島」にしない

分科会が増えてきたら、運営側から全体との接点を作ります。

たとえば、

• 分科会リーダーを集めた報告会を開く

• 全体会の中に分科会紹介の時間を作る

• 最近どんな活動をしたか定期的に共有する

私自身、支部運営をしていたときには、毎月の支部Meetingや、毎週の朝活の中で「今週の支部報告」をしていました。

すると、

「そんな活動やっていたんですね」

「今度参加してみたいです」

という人が出てきます。

面白かったのは、本部のイベントにはあまり来ないけれど、支部イベントには熱心に参加する人もいたことです。

つまり分科会は、「本体より小さい場所」ではありません。

その人にとっては、コミュニティへの別の入口になり得ます。

だからこそ、入口同士をつないでおく必要があります。

原則2　人気者だけを橋渡し役にしない

橋を架けようとすると、つい頼りたくなる人がいます。

顔が広い人。

よく発言する人。

いつもイベントに参加している人。

もちろん、その人たちは大切です。

でも、橋渡しをいつも同じ人気者に任せると、ネットワークは意外と広がりません。

私が面白いと思うのは、

みんながよく知っている人と、普段あまり表に出ない人を組み合わせることです。

すると、今まで知られていなかった人の良さが、初めて表に出ます。

「こんなことを考えていたんだ」

「こんな経験を持っていたんだ」

と、新しい発見が起こる。

そこから別の人が興味を持ち、また新しい線が伸びていきます。

意外性が、次の意外性を生みます。

原則3　「誰と誰をつなぐか」より、「2人が生まれる場」を作る

運営者が毎回、

「AさんとBさんは相性がよさそう」

とマッチングする方法もあります。

でも、人数が増えるほど、それだけでは回らなくなります。

だから考えたいのは、

誰を紹介するかではなく、人と人が自然につながる場をどう作るか。

最小のチームは、2人から生まれます。

交流会で隣になった2人。

同じテーマについて話した2人。

共同で小さな企画を始めた2人。

そこから、新しい塊が始まります。

実際、運営をしていると、ときどき

「一緒にプロジェクトを始めることにしました」

という報告をもらいます。

これは本当に嬉しい。

しかも私の感覚では、

もともと仲がよさそうな人同士よりも、

「この2人が？」

という組み合わせのほうが、大きく発展することがあります。

人は、意外なところで共通点を見つけます。

仕事は違っても、原体験が同じだった。

住んでいる場所は違っても、目指しているものが同じだった。

表面的な属性だけでは見えなかった共感が生まれます。

だから運営者の役割は、全部の答えを持つことではありません。

意外な2人が生まれるきっかけを増やすこと。

それも、大切な仕事のひとつです。

橋を渡ると、メンバー自身の世界も広がる

ここまで運営者視点で書いてきましたが、橋を渡るメリットは、もちろんメンバー側にもあります。

小さなグループと別のグループを行き来する人は、両方の話がわかるようになります。

すると、

「あの人と話したら面白そう」

「あっちのグループにも同じ課題を持っている人がいますよ」

という橋渡しが自然にできるようになります。

そういう人の周りには、さらに新しい人が集まってきます。

結果として、その人自身がハブになっていきます。

ハブになるというのは、

単に「顔が広い人になる」という話ではありません。

コミュニティの中に存在する複数の世界を、一度に体験できる立ち位置になるということです。

これは、コミュニティの良さをかなり速いスピードで受け取れる状態だと思います。

コミュニティの価値は「人の多さ」ではなく「人の幅」にある

コミュニティには、いろんな人がいます。

ただ、これは渋谷の交差点に人がたくさんいるのとは違います。

同じ理念や方向性に、ある程度共感した人たちが集まっています。

完全な他人ではない。

でも、同じ人でもない。

この「共通項があるけれど違う」という距離感があるからこそ、面白い相乗効果が起きます。

そして、コミュニティで

「支払ったお金以上のものを受け取った」

と感じる瞬間は、コンテンツの本数が増えたときだけではありません。

思いがけない人に出会った。

知らなかった考え方に触れた。

一緒に何かを始める仲間ができた。

そんな瞬間にも生まれます。

だからもし、

100人、300人とメンバーがいるのに、

みんなが「いつもの3人」としか話していないなら。

そのコミュニティが持っている価値は、まだ十分に使われていないのかもしれません。

人数を増やすことより、

塊と塊のあいだに橋を増やすこと。

そのほうが、コミュニティ全体の世界を広げることがあります。

あなたのコミュニティは今、

「同じ顔ぶれ」で回っているでしょうか。

それとも、

「意外な二人」が生まれているでしょうか。

事例付きさかい美佐のnote
https://note.com/msakai2025/n/n2abfc5b3852e
さかい美佐の５分要約音声
https://stand.fm/episodes/6a7f86293389f4b44f0f1dbe
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

コミュニティを運営していると、

「こんなにいろいろやっているのに、伝わっていない気がする」

と思うことがあります。

イベントを企画した。
会員サイトを改善した。
新しい仕組みを入れた。
スケジュールを整理した。

でも、反応がない。

そんなとき、運営者側ではつい、

「これだけやっているのに……」

と思ってしまいます。

ただ、最近あらためて感じたことがあります。

やっていないのではなく、見えていない。

もっと言えば、

こちらは「伝えた」と思っていても、相手には判断材料が渡っていない

ことが、とても多いんです。

象徴的なのが、

「更新しました」

という一言です。

「更新しました」は、相手に考えさせている

公式サイトや会員サイトで、よくあります。

8/14　更新しました
→リンク

運営側からすると、ちゃんとお知らせしています。

でも受け取る側になると、

「何を更新したんだろう？」

と思いませんか？

私は思います。

つまり「更新しました」という言葉だけでは、

その先を読むかどうかの判断を、全部相手に委ねている

んですよね。

忙しい人ほど、そこで止まります。

わざわざクリックして、

「自分に関係あるかな？」

と確認してくれるとは限りません。

だから、ほんの一言だけ足します。

たとえば、

8/14：9〜12月のイベントスケジュールを更新しました！

あるいは、

8/29：夏合宿に1名の空きが出ました！

これだけで、

「自分に関係がありそう」

「これは見ておこう」

と判断できます。

コミュニティ運営の可視化で大事なのは、

情報量を増やすことではありません。

相手が考えなくても意味がわかる状態にすること。

これが1つ目の原則です。

原則1：「更新しました」に、もう一言を足す

お知らせを書くときに、

「何をしたか」

だけで終わらせない。

その変更によって、

メンバーに何が起きるのか

まで書く。

これを意識するだけでも、伝わり方はかなり変わります。

たとえば、

「イベントページを更新しました」

より、

「秋のイベント日程を公開しました。予定を先に押さえられます」

のほうがわかりやすい。

「資料を追加しました」

より、

「初参加の方向けに、当日の流れがわかる資料を追加しました」

のほうが親切です。

ポイントは、

運営側が何をしたかではなく、メンバー側で何が良くなったかを書くこと。

これはコミュニティだけではなく、サービス運営全般に共通すると思います。

原則2：かかった時間と苦労は、「後日談」にする

ここは、運営者ほどやってしまいがちなところです。

ものすごく時間をかけて作った企画。

何度も打ち合わせをして、調整して、やっと公開できた新しい仕組み。

当然、

「これ、ものすごく大変だったんです！」

と言いたくなります。

でも、公開した瞬間にそれを全部伝えてしまうと、

受け手にとっては「運営者の苦労話」になってしまうことがあります。

大変だったことを隠す必要はありません。

ただ、

出すタイミングを変える。

まずは、

「何ができたのか」

「メンバーにとって何が良くなるのか」

を伝える。

そして、苦労や試行錯誤は、あとからストーリーとして伝える。

私はこれがいいと思っています。

メイキング映像が感動する理由

YouTubeなどで、映画や舞台のメイキング映像を見ることがあります。

あれって、けっこう感動しませんか？

本編を見たあとで、

「実はここまでに、こんな試行錯誤があった」

と知る。

すると、本編の見え方まで変わります。

そして大事なのは、

メイキング映像は、完成してから突然生まれるわけではない

ということです。

撮影中から写真や映像を残している。

途中の失敗も記録している。

だから、あとでストーリーになる。

コミュニティ運営も同じです。

今が大変なときほど、

• メモ

• 写真

• スクリーンショット

• 変更前と変更後

• そのとき考えていたこと

を残しておく。

その瞬間にはただの記録でも、

あとから見ると、

コミュニティがどう育ってきたかを伝える資産

になります。

苦労は、公開時に全部説明しなくていい。

記録して、あとで意味のある物語にする。

これが2つ目の原則です。

原則3：1か月、3か月単位で「変化」をまとめる

もうひとつ、運営者とメンバーのあいだには大きな違いがあります。

運営者は、毎日コミュニティを見ています。

でもメンバーは、そうではありません。

毎回のお知らせを全部読んでいる人ばかりではないし、

「先月何が変わったか」

なんて、ほとんど覚えていません。

これは当たり前です。

だから、

1か月や3か月という単位で、変化をまとめる。

たとえば、

今月のコミュニティアップデート

• 秋のイベント日程を公開しました

• 初参加者向けページを作りました

• 夏合宿の追加枠が出ました

• ○○企画がスタートしました

こんな形です。

一つひとつは小さな変更でも、

まとまると、

「このコミュニティ、ちゃんと動いているな」

と感じられます。

さらに、

「なぜこの変更をしたのか」

まで短く添えると、

このコミュニティがどこへ向かっているのか

まで伝わります。

この棚卸しこそ、AIに任せる

とはいえ、

「毎月まとめましょう」

と言われても、運営者は忙しいです。

そして1か月前のことって、意外と忘れます。

そこで、今はAIがかなり使えます。

1か月分のお知らせやメモをまとめて渡して、

「今月、メンバーにとってどんな変化があったか、ニュース形式で整理して」

と頼む。

それだけでも、かなり棚卸しできます。

私は、漫画やインフォグラフィクスも好きなので、

文章だけではなく、

時系列を図にする

のもいいと思っています。

このnote記事で使っているインフォグラフィクスも、毎朝、記事を読んでもらって作っています。

正直、

「記事全部を読むより、図のほうが一瞬でわかる」

こともあります。

だから可視化は、

文章を書くことだけではありません。

相手が短い時間で理解できる形に変換すること。

そこまで含めて可視化です。

新しい企画ほど、「伝わっているはず」と思わない

私はこれまで、

一生懸命企画したイベントなのに、申し込みが少ない。

という経験を何度もしてきました。

逆に、最初から申し込みが入りやすいのは、

過去にも開催したことがある企画

だったりします。

合宿もそうです。

以前の写真がある。

参加者の様子がわかる。

どんな時間になるのか想像できる。

だから、申し込みやすい。

一方で、新しい企画は違います。

私は内容をずっと考えているので、

「新企画！○○○」

と出せば、みんな意味を理解してくれるような気になります。

でも実際には、

運営者の頭の中にある情報量と、メンバーの頭の中にある情報量がまったく違う。

だから、新企画ほど、

最初から一度で伝わることを期待しない。

徐々に説明する。

公開前に何人かのメンバーへ、

「これを見て、どういう企画だと思う？」

と聞いてみる。

そうすると、

こちらが当たり前だと思っていたことが、まったく伝わっていなかったりします。

これは失敗ではなく、

公開前に見つけられた“伝わらなさ”

です。

「これだけやったのに」を、運営の燃料にしない

最後に、これは可視化以前の話です。

コミュニティを運営していると、

「これだけやったのに、わかってもらえない」

と思う瞬間があります。

でも、この気持ちをずっと抱えながら運営すると、苦しくなります。

考えてみれば、どんな人間関係でも、

自分がやったことを相手が100％理解してくれているわけではありません。

だから、

「全部見てもらいたい」

「頑張りをわかってもらいたい」

「称賛してもらいたい」

を運営の中心にしないことも大切です。

可視化する目的は、

運営者が褒めてもらうためではありません。

メンバーが、

「何が変わったのか」

「自分に何が関係するのか」

「このコミュニティはどこに向かっているのか」

を理解できるようにするためです。

伝わるコミュニティ運営・可視化の3原則

今回の話をまとめます。

1．「更新しました」に、もう一言を足す
何をしたかではなく、「メンバーに何が良くなったか」まで書く。

2．苦労は、後日談にする
今の苦労を全部説明するのではなく、記録して、あとからストーリーとして届ける。

3．1か月・3か月単位で変化をまとめる
逐一のお知らせだけではなく、コミュニティがどう変わってきたのかを定期的に可視化する。

そのための記録整理やニュース化には、AIもかなり使えます。

運営者には、毎日見えている。

でもメンバーには、断片しか見えていない。

この差を埋めるのが、

可視化の設計

なんだと思います。

あなたのコミュニティのお知らせは、

「更新しました」で終わっていませんか？

それとも、

「メンバーにとって何が良くなったか」まで伝わっていますか？

事例付き本日のnote記事
https://note.com/msakai2025/n/ncd2db0776f9f
さかい美佐の５分要約音声
https://stand.fm/episodes/6a7e357c836d14834bf06d2d
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

コミュニティ運営をしていると、

「お盆だから、今週はお休みにしよう」
「祝日だから、定例イベントはなしにしよう」
「年末年始くらいは、一度止めよう」

そんな判断をすることがあります。

もちろん、運営する側にも休みは必要です。

だから私は、「休んではいけない」と言いたいわけではありません。

ただ、長くコミュニティを運営してきて、ひとつ強く感じていることがあります。

コミュニティは、一度完全に止めてしまうと、再開するほうが大変です。

むしろ私は、

「休むほうが、手間が増える」

と感じています。

祝日を休みにしたら、問い合わせが増えた

以前、毎週開催していたオンラインイベントを、祝日はお休みにしていた時期がありました。

すると、何が起きたか。

「今日はないのでしょうか？」

という問い合わせが増えました。

なかには、いつも通りZoomにアクセスしてから、開催がないことに気づく方もいました。

運営としては、

「1回休めば、そのぶん楽になる」

と思いますよね。

でも実際には、

「今日はあるのか、ないのか」

という確認が必要になります。

参加する側だけではありません。

運営する側も、

「今日は祝日だっけ？」
「今週は開催するんだっけ？」

と判断しなければいけなくなります。

これが意外と、小さくないコストです。

しかも月曜日は祝日が多いので、毎週月曜開催のイベントなら、年間の開催回数そのものも減っていきます。

そこで、ある時期から私は、祝日でも、お盆でも、年末年始でも、基本的には開催するようになりました。

祝日だからこそ、来られる人がいる

続ける理由は、習慣を切らしたくないからだけではありません。

祝日だからこそ参加できる人がいるからです。

普段の月曜日は仕事があって参加できない。

でも祝日なら参加できる。

そんな方が、実際にいます。

「カレンダーを見て、この日は参加できると思ったので」

そう言って参加してもらえたこともありました。

いつも同じメンバーが集まる場に、普段は来られない人が加わる。

すると、場の空気も少し変わります。

話題も、雰囲気も、いつもとは違うものになります。

祝日開催は、単に「休まないため」ではなく、

普段とは違う人が入れる入口

にもなるんです。

コミュニティは、習慣で成り立っている

ずっと参加していた人でも、一度来なくなると、その次も来なくなる。

これは本当によくあります。

1回休む。

次の回もなんとなく行かない。

気づけば、そのまま足が遠のいている。

コミュニティに限らず、習慣にはそういうところがあります。

私自身もそうです。

一度止めると、再開するときに少しエネルギーが必要になる。

だから私は、コミュニティ運営では、

「盛り上げること」より先に、「習慣にすること」

を大切にしています。

イベントの日になったら、いつもの場所が開いている。

カレンダーを確認しなくてもいい。

祝日かどうかを考えなくてもいい。

そこに行けば、いつも何かがある。

この状態は、思っている以上に大切です。

10を続けられないなら、1でいい

とはいえ、

「じゃあ、運営者は365日休めないの？」

という話ではありません。

私は、全部を通常運行する必要はないと思っています。

大切なのは、

ゼロにしないこと。

普段10やっているなら、1でも2でもいい。

1時間のイベントを30分にしてもいい。

スタッフ全員が参加しなくてもいい。

実際、私だけが運営として参加していたこともあります。

短い動画を流す形にしたこともあります。

過去のコンテンツを、

「今日はこれを振り返ってみてください」

と案内するだけでもいい。

内容を間引いても、

「今日もここは動いている」

という状態は残せます。

私は、

ゼロと1は、まったく違う

と思っています。

「開催不明」をつくらない

コミュニティ運営で意外と大切なのは、

豪華な企画を用意することでも、

毎回新しいイベントを考えることでもなく、

参加する人に余計な判断をさせないこと

なのかもしれません。

今日は開催するのか。

祝日はどうなのか。

お盆は休みなのか。

年末はいつまでなのか。

毎回考えなければならない場より、

「この曜日、この時間に行けば開いている」

とわかる場のほうが戻りやすい。

そしてこれは、参加者だけのためでもありません。

運営者自身にも効きます。

私自身、習慣を続けるのが特別得意なタイプではありません。

だからこそ、例外を作らず淡々と開催することが、自分の習慣を守ることにもつながっていました。

このnoteも、もし週1投稿だったら、私はここまで続かなかったと思います。

私の場合は、毎日だから続く。

人によって合う頻度は違います。

でも、自分たちのコミュニティにとって、

「考えなくても続くリズムは何か」

は、一度決めておく価値があります。

休む設計より、続けられる設計

もちろん、スタッフの稼働や会社のルールによって、祝日や年末年始に開催できないコミュニティもあります。

すべてのコミュニティが年中無休にすべき、という話ではありません。

ただ、

「休みだから全部ゼロにする」

以外にも選択肢はあります。

短くする。

人数を減らす。

動画にする。

過去コンテンツを案内する。

投稿だけは続ける。

そうやって、

完全停止ではなく、細くつないでおく。

そのほうが、参加する人にとっても、運営する人にとっても、次の一歩が軽くなります。

コミュニティは、イベントの数だけでできているわけではありません。

人が、

「ここに来るのがいつものこと」

と思える積み重ねでできています。

だから最後に、これだけ。

コミュニティは、習慣です。

あなたのコミュニティでは、祝日や長期休暇のとき、完全にお休みにしていますか？

それとも、少し間引きながらでも動かしていますか？

よかったら、あなたの運営方法も教えてください。

事例付き本日のnote記事
https://note.com/msakai2025/n/nc33c025b8f20
さかい美佐の５分要約音声
https://stand.fm/episodes/6a7ce1537dc998b8ff699a03
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

コミュニティ運営をしていると、避けて通れないものがあります。

それが「課金」です。

いくらにするのか。

月額にするのか。

都度課金にするのか。

年額にするのか。

多くの運営者は、まず金額や料金プランから考えます。

もちろん、それも大切です。

でも、実際に運営してみると、それ以上に大事なことがあります。

それは、

メンバーが、その支払いをどう感じているか。

ということです。

同じ月額5,000円でも、

「この場所に参加できている」

と感じる人もいれば、

「毎月5,000円払っている」

と感じる人もいます。

この差が、継続率に大きく影響します。

課金は、運営者がお金を「回収」するためだけの仕組みではありません。

この場所にこれからも参加する。

この価値を受け取り続けたい。

その意思表示として、メンバーと運営者がお互いに同意する瞬間です。

だからこそ、課金設計では金額だけを見るのではなく、

どんな体験として支払いを迎えてもらうか

まで考える必要があります。

原則1：参加しない方が安くなる設計を作らない

以前、コミュニティで都度課金に切り替えた経験があります。

一見すると、メンバーに優しい仕組みに見えました。

参加した分だけ払う。

使った分だけ払う。

無駄がない。

でも、実際に運営してみると違う問題が起きました。

それは、

参加しない方が金額的には安くなる

ということです。

忙しい月。

予定が合わない月。

少しモチベーションが落ちた月。

そんな時に、

「今月は参加していないから払わなくていい」

という判断ができます。

これは利用者側から見ると合理的です。

でも、コミュニティ側から見ると、接点が減るきっかけになります。

実際、過去に運営していたダイビングショップでも、都度課金に変更したことがあります。

すると、夏の3ヶ月だけ参加するメンバーが増えました。

本当に楽しんでほしい時期は秋だったのですが、

「今年は夏だけでいいかな」

という選択が増えてしまったんです。

さらに、忙しい時期に参加が集中するという運営上の問題も起きました。

料金体系は、単なる支払い方法ではありません。

メンバーの行動パターンまで変えてしまいます。

原則2：課金回数を増やしすぎない

次に大切なのは、

支払いの回数を設計すること

です。

コミュニティでは、

• 都度課金

• 月額課金

• 年額課金

など、さまざまな方法があります。

私はこれまで、すべて経験してきました。

その中で、継続率という観点では、年額は強いと感じています。

理由はシンプルです。

辞めるタイミングそのものが少なくなるからです。

月額の場合、毎月、

「今月も続けるか」

という判断が発生します。

もちろん、その判断自体が悪いわけではありません。

ただ、忙しい時期や気持ちが落ちている時には、その小さな判断が離脱につながることがあります。

一方、年額の場合は、1年間という期間でコミュニティとの関係を考えることになります。

ただし、最初から年額をおすすめするわけではありません。

立ち上げ期のコミュニティは、まだ参加者の反応を見ながら改善していく時期です。

その段階では、

• 月額

• 都度課金

から始める方が、試行錯誤しやすいです。

年額は、ある程度ファンが育ち、

「この場所を応援したい」

と思ってくれる人が増えてからでも遅くありません。

原則3：自動送信ではなく、関係性を届ける

課金周りでもうひとつ重要なのが、支払い前後のコミュニケーションです。

例えば、決済が未完了になった場合。

多くのサービスでは、自動送信メールを送ります。

もちろん、自動化は便利です。

でも、課金に関する連絡は少し特殊です。

なぜなら、

自動送信は、届いていないことがあるからです。

迷惑フォルダに入る。

見落とされる。

後回しにされる。

そして、多くの場合、未払いの人は悪意があるわけではありません。

単純に気づいていないだけです。

だからこそ、重要な場面では、

「回収する」

という視点ではなく、

「関係性を維持する」

という視点で連絡することが大切です。

実際に、電話やDMなど、自分自身から直接連絡すると対応率が大きく変わりました。

そして、それは単なる督促ではありません。

「最近どうですか？」

「入会した時に話していた目標、その後どうなっていますか？」

そんなコミュニケーションのきっかけになります。

課金のタイミングは、関係が薄れる瞬間ではなく、

むしろ関係を深めるタイミングにもできます。

引き落とし日は「退会判断の日」ではなく「振り返りの日」にする

自動更新のコミュニティでは、引き落とし日の設計も重要です。

規約上、自動更新になっている場合でも、

「勝手に更新される」

という印象を持たれると、支払いの痛みになります。

だから私は、引き落とし前に必ず連絡をするようにしていました。

ただの、

「○月○日に更新されます」

という通知ではありません。

その1年間を振り返る機会にします。

例えば、

• 入会した時の目的

• この1年間でできたこと

• コミュニティで印象に残った出来事

• 次の1年で得られる価値

を伝える。

すると、支払いは単なる決済ではなく、

「またこの場所で活動していこう」

という再確認の時間になります。

まとめ：継続率を上げるのは、価格ではなく体験設計

コミュニティの課金設計で大切なのは、

「いくら取れるか」

ではありません。

大切なのは、

「メンバーがどんな気持ちで支払うか」

です。

今回の3原則をまとめると、

1. 参加しない方が安くなる設計を避ける

コミュニティとの接点が減る構造を作らない。

2. 課金回数を増やしすぎない

支払い判断の回数を減らし、継続しやすい環境を作る。

3. 自動送信ではなく、関係性を届ける

課金連絡を「回収」ではなく「コミュニケーション」に変える。

課金は、コミュニティ運営の中でも特にセンシティブな場所です。

だからこそ、仕組みだけではなく、

「この場所に参加していてよかった」

と思ってもらえる体験まで設計する必要があります。

料金プランを考える時は、ぜひ金額だけではなく、

その支払いの瞬間に、メンバーはどんな気持ちになるのか？

という視点で考えてみてください。

事例付き本日のnote記事
https://note.com/msakai2025/n/n5a1b32baea58
さかい美佐の５分要約音声
https://stand.fm/episodes/6a7bab0b4c01738d164cc9e6
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

最初は、みんなちょっと面白がって使ってくれるんです。

「これ聞いてみよう」
「こんなことも答えられるかな」

ところが、しばらくすると利用が減っていく。

気がつけば、使っているのは私がテストするときくらい……。

以前、実際にそんなことがありました。

設置する前は、

「これで質問対応が少し楽になるかも」

なんて期待していたんですが、置いただけでそう簡単にうまくいくわけではありませんでした。

AIの失敗だけ、なぜか覚えている

これ、ちょっと不思議なんですよね。

人が何か間違えたときは、

「まあ、そういうこともあるよね」

で流れることがあります。

でもAIが一度変な答えをすると、

「あれも間違ってた」
「この前も答えられなかった」
「やっぱり使えないよね」

と、なぜか失敗リストが作られていく。

私自身も、ついやってしまいます。

たぶんそこには、

「AIなら、もう少しちゃんとできるはず」

という期待があるんだと思います。

なんとなく、何でも答えてくれる魔法のランプのように見えてしまう。

だから期待した答えが返ってこないと、

「もっと完璧なはずなのに、どうして？」

となる。

そして、その一回が

「もう使わなくていいか」

につながってしまいます。

でも、入っていない情報には答えられない

当たり前の話ではあるのですが、

AIは、運営側が渡した情報をもとに答えます。

たとえば、

「今日のZoomのURLは？」

と聞かれても、その日のURLをこちらが入れていなければ答えられません。

新しいルールを決めたのに、情報を更新していなければ、古いルールを答えることもあります。

そう考えると、

「AIが使えない」

というより、

「まだ、使える状態まで育てられていなかった」

というケースもかなりあるのではないでしょうか。

AIは作ったようにしか動きません。

ここは、運営する側も忘れないほうがよさそうです。

「何でも聞いてください」は、意外と難しい

もうひとつ感じているのが、

チャットボットを置いて、

「何でも質問してください！」

だけでは、意外とうまく使ってもらえないことです。

慣れている人なら自由に質問できます。

でも、慣れていない人は、

「何を入れればいいんだろう」

で止まります。

そこで、最近はもっと入り口を狭くしたほうがいいと思っています。

たとえば、

・よくある質問を3つくらい並べる
・「入会」「イベント」「Zoom」などキーワード例を見せる
・カテゴリーを選んでから質問してもらう

これだけでも、かなり聞きやすくなります。

逆に、一生懸命説明しようとして長い文章を入れると、かえって欲しい答えが出てこないこともあります。

なので、

「こう聞くとうまくいきます」

までセットで見せる。

ここが大事なんですよね。

テキストで説明するより、見せたほうが早い

そして、使い方を伝えるなら、文章だけよりも実際の画面を見せるほうが早いです。

私は、

「このボタンを押して」
「ここに、このキーワードを入れて」
「すると、こう答えが返ってきます」

という流れを、短い動画やスクショで見せるのがいいと思っています。

特に、こういうツールに慣れていない人には効果的です。

質問のしかただけではなく、

どこから起動するのか

も忘れずに。

運営側は毎日見ている画面でも、メンバーにとっては「どこにあったっけ？」から始まります。

答えられないとき、人につながれるようにする

もうひとつ、コミュニティで使うなら大事だと思うことがあります。

AIで解決できない場合に、

「コミュニティマネージャーに聞く」
「担当者から連絡してもらう」

というルートを残しておくことです。

大規模なコミュニティなら別ですが、ある程度人の顔が見える場所なら、全部をAIで完結させなくてもいいと思っています。

いちばん怖いのは、

AIが答えられなかったことではありません。

答えが得られなかった人が、質問すること自体を諦めてしまうこと。

「あ、わからないままでいいや」

となって、そのまま離れてしまう。

それなら、

「ここで解決しなければ人に聞けますよ」

とわかるほうが安心です。

AIか人か、ではなくて、

AIから人へちゃんとつながる。

そのくらいの設計が、コミュニティではちょうどいいのかもしれません。

置いて終わりではなく、一緒に育てる

チャットボットは、設置した瞬間に完成するものではありません。

運営者自身が質問してみて、

「この答えで大丈夫かな」

と確認する。

答えられなかった質問があれば、情報を追加する。

新しいルールやイベント情報が出たら、早めに更新する。

そしてメンバーにも、

「まずここに聞いてみてください」

と使ってもらう。

その繰り返しで、少しずつ使える場所になっていくんだと思います。

私が以前置いたチャットボットも、最初はよく使われました。

でも、だんだん利用が減って、気がつけば私のテスト使用がほとんどになっていました。

設置すれば、自動的に質問が減る。

そんなに簡単ではなかったです。

だから今なら、

「高性能なものを置く」

より先に、

「どこで使うものなのかを決める」
「使い方を見せる」
「情報を更新する」

この3つを考えます。

万能じゃなくていいんです。

むしろ、

「これは、この質問をするときに使ってください」

くらいのほうが、長く使ってもらえる気がします。

AIを一回で見限らないこと。

そして同じくらい、

運営側も、一回うまくいかなかったからといってアップデートを諦めないこと。

コミュニティに置くAIは、完成品というより、

みんなで少しずつ使いやすくしていく道具

くらいに考えておくのが、ちょうどいいのかもしれません。

あなたのコミュニティにあるチャットボットは、

一回で見限られていますか？

それとも、今も少しずつ育っていますか？

事例付き本日のnote記事
https://note.com/msakai2025/n/n90aec5bbe5a9
さかい美佐の５分要約音声
https://stand.fm/episodes/6a7a4e600bc1c6da7fa995ca
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

これは運営をするうえで、かなり大事なことです。

でも、ひとつ覚えておきたいことがあります。

早く告知したからといって、参加人数が一気に増えるわけではありません。

むしろ早く出せば、その分、

「ごめんなさい、その日は行けません」
「予定が合わなくて参加できません」

と断られる回数も増えます。

運営をしていると、これが地味にこたえることがあります。

でも私は、

断られた回数は、ちゃんと告知できたという証拠

くらいに考えていいと思っています。

知らせなければ、断られることすらありません。

まず運営者自身が、ひとつひとつの不参加に傷つきすぎないこと。

そのうえで考えたいのが、

「予定を早く出したのに、なぜ来てもらえないのか？」

という問題です。

答えは、日程だけではありません。

空いていても、参加しないことはある

これは私自身もそうです。

予定が空いていても、

「参加する意味はあるかな」
「時間の浪費にならないかな」
「カメラONなのかな」
「コメントしないとダメかな」
「何か準備が必要なのかな」

と思うイベントには、参加しないことがあります。

つまり、

「予定が空いている」＝「参加できる」

ではないんですよね。

参加するためには、時間以外にも小さなハードルがあります。

だから日程だけを何度も告知しても、参加人数が伸びないことがあります。

そこで私は、コミュニティの参加設計では、次の3つを意識するといいと思っています。

1．「見るだけ」「聞くだけ」を正式な参加にする

コミュニティイベントというと、

・カメラON
・積極的に発言
・コメントする
・ワークに参加する

といったものを求めたくなります。

もちろん、そういう回があってもいいと思います。

でも、毎回すべてを求める必要はありません。

私は読書会をしていたとき、

カメラONで参加する人とは別に、カメラOFFで聞くだけの人を

「オーディエンス」

と呼んでいました。

名前をつけて正式な参加形態にしてしまうんです。

「仕方なくカメラOFF」ではなく、

「今日はオーディエンスとして参加する」

という選択肢になります。

これだけでも、かなり参加しやすくなります。

2．「遅刻・早退の謝罪」まで不要にする

オンラインイベントで途中から入ってきた人が、

「遅れてすみません」

途中で抜ける人が、

「早く抜けてしまってすみません」

とコメントしてくれることがあります。

でも私は、

そのコメントも別にしなくて大丈夫ですよ

と伝えることがあります。

遅刻した。
早退した。
ブレイクアウトルームには参加できない。

それだけで毎回「申し訳ない」と思わせてしまうと、参加そのものが面倒になります。

ブレイクアウトに参加できないなら、名前にマークをつけてもらう。

見るだけならカメラOFFでいい。

途中入退室もOK。

仕組みで処理できることは、仕組みで処理する。

参加者に、いちいち言い訳をさせない。

これは小さなことですが、継続するコミュニティではかなり大切です。

3．毎回同じ「参加強度」にしない

今回、私がいちばん大事だと思っているのがここです。

「参加のハードルを下げる」と言うと、

全部ゆるくしましょう

という話に聞こえるかもしれません。

でも、そうではありません。

たとえば講座なら、

「最初から参加してください」
「途中参加だと内容がわかりにくくなります」
「今日はカメラONでワークをします」

という回があっていい。

知識を教える講座なら、事前準備が必要なこともあります。

大事なのは、

強度の高い回と、ふらっと参加できる回を分けること。

今日はしっかり参加する回。

今日は聞くだけでもいい回。

今日は準備ゼロで来ていい回。

その区別があるだけで、メンバーはかなり気が楽になります。

逆に、

毎回カメラON。
毎回発言。
毎回事前準備。
毎回ワーク。

となると、

「今日はちゃんと参加できないから、やめておこう」

という判断が増えます。

それが何度も続くと、

参加しない癖

がついてしまいます。

コミュニティは、一度きりの講座とは違います。

何か月、何年と続いていく場所です。

だから、毎回100点の参加を求めるより、

30点でも50点でも、関わり続けられる設計

のほうが大事なことがあります。

告知も「日程」だけを繰り返さない

日程を早く出すことは最低限必要です。

でも、

「○月○日に開催します！」

という告知だけを何度繰り返しても、人数が増えないことがあります。

そんなときは、告知する切り口を変えてみます。

たとえば、

日程を伝える告知

「○月○日に開催します」

手間の少なさを伝える告知

「準備不要です」
「見るだけでもOKです」
「カメラOFFでも大丈夫です」
「途中入退室OKです」

参加するメリットを伝える告知

「参加すると○○が整理できます」
「こんなことを持ち帰れます」

という具合です。

日程、手間、得られるもの。

切り口をローテーションして伝えてみる。

「行ける日だから参加する人」だけではなく、

「これなら気楽に参加できそう」と思った人

も動きやすくなります。

聞きにくいことは、先に答えておく

参加者が意外と困るのが、

「こんなこと、運営者に聞いていいのかな」

という小さな疑問です。

「カメラはOFFでも大丈夫ですか？」
「途中から入っていいですか？」
「見るだけでもいいですか？」

運営者本人には、少し聞きづらい。

だからFAQに書いてもいいですし、案内文に入れてもいい。

AIチャットボットを置いているなら、そこで聞けるようにしておく方法もあります。

大事なのは、

参加する前に生まれる小さな不安を、できるだけ本人に抱えさせないこと。

参加するかどうかを決める前の段階で、

「面倒そう」

と思われない設計にしておきます。

そして、「参加しない自由」もある

コミュニティの日程を知らせると、

「参加できなくてすみません」

と返事をいただくことがあります。

でも本来、

コミュニティへの参加は自由です。

参加するかどうかを決めるのは本人です。

運営者が、

「こんなに早く予定を出したのに」
「どうして参加しないんだろう」

と考えすぎても仕方ありません。

まして、

「忙しいんですか？」

と詰め寄ってしまったら逆効果です。

コミュニティは、生活の中にあるサードプレイスです。

仕事や家庭、その日の体調、気分。

いろいろなものがあったうえで来てくれています。

だから私は、

来てくれた人には、

来てくれてありがとう。

アーカイブを見てくれた人には、

見てくれてありがとう。

そう思うくらいがちょうどいいと思っています。

「言い訳を要らなくする」参加設計3原則

最後にまとめます。

コミュニティへの参加ハードルを下げたいなら、

1．見るだけ・聞くだけも、正式な参加形態にする

2．遅刻・早退・カメラOFFなどで、言い訳や謝罪をさせない

3．毎回すべてを求めず、回ごとに参加強度を分ける

この3つを意識してみてください。

そして土台に置いておきたいのが、

「参加しない自由もある」

という考え方です。

参加率を上げることだけを考えると、ついルールや声かけを増やしたくなります。

でも、本当に必要なのは逆かもしれません。

参加するための言い訳を増やすのではなく、

参加しないための言い訳すら必要ない場所にする。

そうすると、

「今日は聞くだけで行こうかな」

と戻ってこられる人が増えます。

あなたのコミュニティは、

「ちゃんと参加できるときだけ来る場所」になっていますか？

それとも、

「今日は30％でも参加できる場所」

になっているでしょうか。

これからも、コミュニティを無理なく長く続けるための設計や、実際の運営で気づいたことを書いていきます。

よければ無料購読して、次の記事もメールで受け取ってください。

今すぐ登録する

事例付き本日のnote記事
https://note.com/msakai2025/n/nd24d0626a6cd
さかい美佐の５分要約音声
https://stand.fm/episodes/6a799799bd80498a8158695a
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

コミュニティを運営していると、

「次の日程、決まっていますか？」

「いつ頃わかりますか？」

と聞かれることがあります。

もちろん、ただ予定を知りたいだけの場合もあります。

でも最近、私はこの質問が何度も来るなら、少し運営側の告知を見直したほうがいいのかもしれない、と思うようになりました。

告知のスケジュールが、こちら都合になっている可能性があるからです。

私たち運営側は、つい、

「内容が決まってから告知しよう」

「登壇者が確定してから」

「申込ページができてから」

と思います。

でも参加する側が、最初に知りたいのはそこじゃないことも多い。

まず、

いつなのか。

なんですよね。

「第一金曜です」では、まだ足りなかった

今運営しているコミュニティでは、毎月MeetUpというオンライン交流会を開いています。

かなりゆるい交流会です。

録画を残して後から見るような会でもありません。

そして開催日は、ほぼ「第一金曜の夜」と決まっています。

なので私は、正直なところ、

「第一金曜と決まっているんだから、だいたい分かるよね」

と思っていた部分がありました。

でも、それでも、

「次はいつですか？」

「早めに教えてください」

と言われるんです。

そこで気づきました。

「第一金曜」と「◯月◯日」は、運営側から見るとほぼ同じでも、参加者からすると全然違う。

第一金曜と言われたら、一度カレンダーを開いて、

「今月の第一金曜って何日だっけ？」

と考えないといけない。

小さなことなんですけど、相手の脳を使わせています。

◯月◯日なら、そのまま自分の予定と比べられます。

だから今は、

規則で伝えるより、日付で伝える。

これ、地味ですがかなり大事だと思っています。

メンバーは、自分で「行く・行かない」を決めたい

考えてみれば当たり前なんですよね。

コミュニティのメンバーにも、仕事があります。

家族の予定もあります。

友人との約束もあるし、別のコミュニティやイベントに参加している人もいます。

その中で、

「これは行こう」

「今回はやめておこう」

と、自分で決めたい。

運営者としては、参加してほしい。

でも、その前にまず選択肢としてテーブルに乗せてもらわないといけません。

あとから別の予定に負けることはあります。

それは仕方ない。

でも、少なくとも先に日程が分かっていれば、

「あ、この日はコミュニティのMeetUpがある」

と一度は予定の候補に入れてもらえます。

私はこれだけでも、かなり違うと思っています。

一番最初に分かった予定、というだけでアドバンテージがある。

詳細が決まっていなくても、日付は出せる

告知が遅くなる理由のひとつに、

「まだ中身が決まっていない」

があります。

これもよく分かります。

テーマが決まっていない。

登壇者が決まっていない。

会場が決まっていない。

だから告知できない。

でも、全部を一緒に決めなくてもいいんですよね。

たとえば、

4月18日（土）リアルイベント予定
詳細は後日

これでも、予定を空けるかどうかは考えられます。

オンラインなのか、リアルなのか。

交流会なのか、勉強会なのか。

それくらいのカテゴリーまで分かれば、さらに判断しやすい。

特にリアルイベントは、早めに出したほうがいいです。

オンラインなら「その時間だけ空けておこう」で済むこともありますが、リアルだと移動があります。

宿泊を伴う合宿なら、さらに調整が必要です。

私は、

オンライン
↓
リアルの日帰り
↓
合宿・宿泊

の順番で、告知を前倒しする必要があると思っています。

カレンダーにしたら、質問が減ったことがある

以前、中小企業の経営者や幹部の方が参加するコミュニティを担当していたことがあります。

そこは、とにかくイベントが多いコミュニティでした。

しかも、そのコミュニティのイベントだけではなく、系列のほかのコミュニティのイベントにも参加できる。

すると当然、

「次は何がありますか？」

「このイベントはいつですか？」

という問い合わせも増えます。

そこで、会員サイトのヘッダー画像そのものを、直近3か月のイベントカレンダーにしました。

イベントの種類によって色分けもしました。

さらに、最新イベント一覧をダウンロードできるボタンも設置しました。

そうしたら、問い合わせが減りました。

一方で、会員サイトへのアクセスは増えました。

これはかなり分かりやすい変化でした。

考えてみれば、日程を文章でずらっと並べるより、

自分が普段使っているカレンダーと同じ形で見えたほうが、生活に当てはめやすい。

「この週は忙しいな」

「ここなら行けそう」

が、一瞬で分かります。

ただし、何でもカレンダーにすればいいわけではない

ここは少し悩むところです。

イベントがものすごく少ない場合、半年分のカレンダーを出したことで、

「こんなに何もないんだ」

と見えてしまうこともあります。

その場合は、無理にカレンダーにせず、イベントの日程を列挙するだけでもいいと思います。

……と書きながら、月1回くらいあるなら、やっぱり私はカレンダーにするかもしれません。

このあたりはイベント数とのバランスですね。

大事なのはカレンダーを作ること自体ではなく、

参加者が自分の生活と並べて予定を考えられる形にすること。

だと思います。

年間予定は、全部確定していなくてもいい

ダイビングショップに関わっていた頃、年間スケジュールはかなり重要でした。

何月にはこのイベント。

この季節にはこの企画。

というものを早めに出していました。

年間で並べてみると、季節感も出ます。

コミュニティでも同じで、

「春にはこれ」

「夏にはこれ」

「年末にはこれ」

と、大きな予定だけでも先に出しておくといいと思います。

全部確定していなくても、

「予定」

「仮」

と書けばいい。

むしろ何も見えないより、

この先もこんなことをやる予定なんだ

と分かったほうが、コミュニティの動きも伝わります。

忘年会や新年会なんて、特にそうです。

あの時期は予定のライバルが多い。

11月後半になってから、

「12月に忘年会します！」

と言っても、もう埋まっている人がたくさんいます。

恒例行事ほど、

「今年もあるだろう」

ではなく、

「今年は12月◯日です」

まで早めに出しておきたいところです。

AIに決めてもらうなら「日付」より「中身」

年間予定を作ろうとすると、

「そんな先の企画まで決められない」

となります。

ここはAIを使ってもいいと思います。

ただ、私ならAIに日付を決めてもらうというより、

「このコミュニティなら1年間でどんなイベント構成がよさそう？」

「春・夏・秋・冬で、どんな企画が考えられる？」

「オンラインとリアルをどう組み合わせる？」

という中身のほうを一緒に考えてもらいます。

告知が遅れる理由は、案外日付ではなく、

「その日に何をやるか決まっていない」

ことだったりします。

そこをAIに手伝ってもらう。

日付は、自分たちの事情やメンバーの動きを見ながら人が決める。

この役割分担のほうが使いやすいと思っています。

「日程決まってますか？」は、小さな運営診断かもしれない

もちろん、すべての予定を半年前から決める必要はありません。

急にやるイベントがあってもいい。

思いつきのオンライン会も楽しいです。

でも、

「日程決まっていますか？」

「いつ頃分かりますか？」

という質問が何度も来ているなら。

それは、

参加者が知りたいタイミングより、運営者が出したいタイミングを優先している

サインかもしれません。

詳細より先に、まず日付。

できれば、リアルなのかオンラインなのかも。

そして変更はなるべく少なくする。

参加する人は、その予定を自分の生活の中に入れてくれています。

だから、参加者にとって予定が立てやすいことも、コミュニティ運営のひとつなんだと思います。

あなたのコミュニティは、

「直前告知」が多いでしょうか。

それとも、

先の予定まで、ある程度見えるようになっているでしょうか。

事例付き本日のnote記事
https://note.com/msakai2025/n/nb1dc6848c5fa
さかい美佐の５分要約音声
https://stand.fm/episodes/6a78e99460a6a62b3bd80677
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

「満足しています」が多い。
大きなクレームもない。
DMにも、とくに困りごとは届いていない。

「ああ、順調なんだな」と思う。

でも、長くコミュニティを運営していると、ときどき後から知らされます。

「実は、ずっと動画が見られなくて……」

「年会員に変えたかったんですけど、方法が分からなくて……」

「ログインできなくて、コメントできないままでした」

運営側からすると、

早く言ってくれれば、すぐ直せたのに。

と思います。

でも、たぶん問題はそこなんです。

困っていた人は、言わなかったのではなく、
言いにくかった。

そして、その「言いにくさ」には、少なくとも2種類あります。

「言うと悪役になる」と「自分が悪いことになる」

ひとつは、

「こんなことを言ったら、面倒な人だと思われるかもしれない」

という怖さです。

「この会員サイト、使いにくいです」

「イベント代、少し高いと思います」

「もっと早く予定を教えてほしいです」

どれも運営改善にはありがたい情報です。

でも言う側からすると、場の雰囲気を悪くする人になりかねない。

特に、運営者や他のメンバーとの関係が良ければ良いほど、

「わざわざ水を差さなくてもいいか」

となることがあります。

もうひとつは、

「言ったら、自分が悪いことになる」

という怖さです。

ログインできない。

でも、

「説明をちゃんと読んでいない自分が悪いのかもしれない」

と思う。

動画が見つからない。

でも、

「みんなは普通に見ているみたいだから、分からない私がおかしいのかな」

と思う。

すると、質問そのものが消えます。

運営者には何も届きません。

そして数週間、数か月経ってから、

「あれもできなかった、これもできなかった。ついていけそうにないので退会します」

になる。

運営者が初めて問題を知るのが、退会のとき。

これは、かなりもったいないことです。

高評価の裏で起きる「誰か言ってよ」

悪い知らせほど伝わりにくくなる現象に、MUM効果と呼ばれるものがあります。

コミュニティでも、よく似たことが起きます。

「私はちょっと困っている。でも、私だけかもしれない」

「誰かが言ってくれたら、私も『私もです』と言えるんだけど」

そんな状態です。

私はこれを、

「誰か言ってよ」状態

だと思っています。

全員が少しずつ困っている。

でも、最初の一人になりたくない。

その結果、運営者には何も届かない。

だから、

意見が来ない＝問題がない

ではありません。

むしろ運営側が見るべきなのは、

「言いにくいことが、どうすれば上がってくるか」

です。

私は、ここに3つの設計が必要だと思っています。

原則1　「あなたのせいではない」を先に出す

「分からなかったら聞いてくださいね」

だけでは、聞けない人がいます。

なぜなら、

「分からないのは、自分がちゃんと読んでいないから」

と思っているからです。

だから運営側から、先に自責を外します。

たとえば新しい会員サイトを入れたあとなら、

「今回ちょっと分かりにくいですよね。私の説明も足りていないと思うので、迷ったところがあったら教えてください」

と伝える。

すると、

「私だけが分かっていないわけじゃないんだ」

と思いやすくなります。

これは、意見をもらった“後”に感謝する話とは少し違います。

そのさらに前。

報告する前の心理的なハードルを下げる。

運営者自身が先に、

「分かりにくい可能性がある」

「改善の余地がある」

と認めておくことです。

原則2　雑談の中の「小さな違和感」を記録する

改善点は、いつも要望フォームの形で届くとは限りません。

むしろ、本音は雑談の端に出ます。

「まだ会員サイト入れてないんですけどね」

「イベント、もう少し早く知りたかったなあ」

「今回は予定が合う人向けですよね」

本人は苦情のつもりではありません。

だから、こちらも聞き流しやすい。

でも、こういう一言にはかなり情報があります。

たとえばイベント告知。

運営側は何度も、

「もう少し早く予定を教えてほしい」

と言われているうちに、慣れてしまうことがあります。

でも参加者側からすれば、仕事も家庭も予定があります。

「タイミングが合う方だけどうぞ」

では、本当は行きたかった人を取りこぼしてしまいます。

詳細まで決められなくても、

「○月○日ごろに、このイベントを予定しています」

だけ先に出せる。

イベントカレンダーを置く。

これだけでも変わります。

大事なのは、

明確なクレームだけを改善要望だと思わないこと。

雑談の中の、

「ちょっと困った」

「本当はこうだったらいいのに」

を拾って、記録しておく。

私は、ここにAIを使うのもかなり相性がいいと思っています。

ログイン率、滞在時間、視聴状況などの数字を見せて、

「どこに離脱やつまずきがありそうか」

を出してもらう。

人は遠慮しますが、数字は遠慮しません。

「誰からも苦情が来ていない」

と

「誰も困っていない」

の間には、かなり距離があります。

原則3　意見を言う人を「細かい人」にしない

ここが、運営者にとって一番大事かもしれません。

何度も意見をくれるメンバーがいると、

「またAさんか」

と思う瞬間があります。

実際、細かな意見かもしれません。

でもそこで運営者が困った顔をすると、その空気は周囲に伝わります。

コミュニティは関係性ができてくるほど、メンバーが運営者の味方をしてくれるようになります。

すると、

「Aさん、ちょっと細かいですよね」

という言葉が出る。

別の人も、

「確かに、いつも細かいですよね」

と言う。

やがて、

Aさん＝細かい人

という場の認識ができてしまいます。

するとAさん本人の居場所が削られるだけではありません。

それを見ていた他のメンバーも、

「意見を言うと、ああなるんだ」

と学びます。

こうして、さらに何も上がってこなくなる。

だから必要なのは、

意見を言われて困らない、運営者の立ち居振る舞い

です。

すぐに正しい・間違っているを判定しなくてもいい。

「そう感じたんですね」

「言ってくれてありがとうございます。ちょっと他の方にも聞いてみます」

くらいでいいと思います。

そして、本当にその人だけの感覚なのか分からなければ、他のメンバーにもそっと聞く。

たとえば、

「ちょっと正直に聞きたいんですが、先日のイベント代金、高かったと思いますか？」

と聞いてみる。

すると、

「私はちょうどいいと思いました」

という人もいれば、

「実は私もちょっと高いと思ってました」

という人もいます。

一人の意見を、そのまま全体の意見だと思わない。

でも、一人の意見だからといって、切り捨てもしない。

一つの断片を、検証の入口にする。

この姿勢が大事だと思っています。

頭の中に「エアAさん」を置く

意見をくれた人を、改善のパートナーとして頭の中に残しておくのもおすすめです。

私はこれを、

「エアAさん」

と考えています。

新しいシステムを導入するとき、

「これ、Aさんだったら迷わないかな」

と考える。

新しいイベントを告知するとき、

「Aさんだったら、このタイミングで予定を空けられるかな」

と考える。

新しい説明ページを作ったとき、

「Aさんなら、どこを読めばいいか分かるかな」

と考える。

一度出てきた意見を、その場で対応して終わらせない。

次の設計に使うんです。

そうすると、「細かい人」だったはずの人が、

コミュニティのUXを改善してくれる人

に変わります。

本当に怖いのは、苦情が来ることではない

コミュニティ運営をしていると、ネガティブな意見は少し怖いです。

できれば、

「楽しいです」

「入ってよかったです」

「いつもありがとうございます」

という言葉を聞いていたい。

もちろん、それも本音です。

でも本当に怖いのは、悪い意見が来ることではありません。

困っているのに、何も言わずに離れていくこと。

そして、その途中で何度も、

「誰か言ってよ」

と思っていたかもしれないことです。

だから運営者がつくるべきなのは、

「何でも言ってくださいね」

という一文だけではない。

言った人が悪役にならない。

分からない人が「自分が悪い」と思わない。

言ってくれた人に「細かい人」というラベルが貼られない。

そんな経路と空気なんだと思います。

アンケートが高評価だったときこそ、一度だけ考えてみてください。

「ここに書かれなかったことは、何だろう？」

そして、あなたのコミュニティで意見をくれる人を思い浮かべてみてください。

その人は、本当に「細かい人」でしょうか。

それとも、

みんなが言えないことを、代表して言ってくれている人でしょうか。

事例付き本日のnote記事
https://note.com/msakai2025/n/na4cb5f9ad3df
さかい美佐の５分要約音声
https://stand.fm/episodes/6a779bc1ea1b5b5c8d126dd8
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

コミュニティで人と人との距離が急に縮まる瞬間があります。

それが、

「え、実は私もです」

というひと言が出たとき。

同じ仕事をしている。
同じ業界にいる。

もちろん、それも共通点です。

でも私がコミュニティを運営していて感じるのは、むしろ表向きのプロフィールからは見えない、ちょっと意外な共通点が見つかったときのほうが、関係が一気にフラットになることがある、ということです。

たとえば、昔やっていたスポーツ。
出身地。
最近ハマっているもの。
以前住んでいた場所。
過去にしていた仕事。

肩書きとは関係のないところで、

「それ、私もです」が見つかる。

そこから、急に会話が始まることがあります。

このPublicationでは、こうした「人がつながる場」を、感覚だけでなく実際の運営に落とし込める形で考えていきます。

今すぐ登録する

共通点があるだけでは、関係は始まらない

ここで一つ、コミュニティ設計で大切だと思っていることがあります。

それは、

共通点は「ある」ことと「見つかる」ことが別

だということです。

たとえばプロフィールに、

「静岡県出身」
「旅行が好き」
「以前は営業職」

と書いてあったとします。

どこかのメンバーと共通しているかもしれません。

でも、そもそもプロフィールを細かく読んでもらえなければ、その共通点は存在しないのと同じです。

情報を置いておくだけでは、人と人は重なりません。

だからコミュニティ側が考えるべきなのは、

「何を書いてもらうか」だけではなく、「どうやって見つかるようにするか」

なのだと思います。

【画像：共通点は「ある」ことと「見つかる」ことが別】

私が理想だと思うのは、

意外なときに、意外な形で、お互いが気づくこと。

プロフィールは「置き場所」。

交流会や会話は「見つかる場面」。

この両方が必要です。

ダイビングの話だけで、その人を覚えた

私自身にも、そんな経験があります。

私は以前、よくダイビングをしていました。

だから、誰かからダイビングの話が出ると、それだけですぐにその人のことを覚えます。

実際、コミュニティメンバーの中に、

時代は違うけれど、お互い西伊豆によく通っていた

という方がいました。

仕事が同じだったわけではありません。

でも、

「西伊豆、よく行ってました」

という一つの共通点が見つかったことで話題が生まれ、その後よく話すようになりました。

たった一つの重なりです。

でも、その重なりが、次の会話の入口になった。

これが、心理学でいう「類似性‐魅力効果」をコミュニティで考えるときのおもしろいところだと思います。

人は、自分との共通点が見つかると、相手を少し身近に感じやすくなる。

だから重要なのは、共通点の数を増やすこと以上に、

すでに存在している共通点を、見つけられるようにすること

なのかもしれません。

原則1　「仕事以外」が見つかる入口をつくる

【画像：共通点を“見つかる場所”に置く設計3原則】

一つ目は、

仕事以外の情報が自然に出てくる場をつくること。

プロフィールに趣味欄を追加するのも一つの方法です。

ただ、先ほど書いたように、

「〇〇県出身」

とプロフィールに書いておくだけでは、見つからない可能性があります。

そこで私は、オンライン交流会などでよく、

「最近ハマっているもの」

を話してもらいます。

これ、結構楽しいんです。

最近見ているドラマでもいい。
買ってよかったものでもいい。
食べ物でも、趣味でも、旅行でもいい。

仕事の自己紹介とは違って、その人の「人となり」が出ます。

すると、

「私もそれ好きです」

「それ、どこでやってるんですか？」

という会話が自然に生まれます。

そして、それがメンバー同士で話し始めるきっかけになります。

表向きの肩書きだけを交換する交流会よりも、

その人の意外な一面が一つ見える交流会

のほうが、その後の関係につながりやすいと感じています。

同業という共通点も、もちろん強い

もちろん、仕事の共通点が悪いわけではありません。

同業だったり、以前やっていた仕事と相手の現在の仕事が同じだったりすれば、

「その苦労、わかります」

と話が早くなることがあります。

ただしビジネスの場では、現在の直接的なライバルではないことも大切でしょう。

そして、同業という「表向きの顔」の共通点とは別に、意外な共通点には一つ大きな特徴があります。

上下が生まれにくいことです。

肩書きや実績が重なると、

「どちらが経験豊富か」
「どちらが売れているか」

という比較の視線が入りやすい。

でも、

「保護猫を飼っています」
「西伊豆でダイビングしていました」

には、あまり上下がありません。

だから、フラットな関係をつくる入口として機能するのだと思います。

原則2　「全員の情報」が場に出るようにする

二つ目は、

全員に話す時間を配ること。

私はコミュニティの交流会なら、あまり大人数ではない少人数の会が好きです。

理由は単純で、一人ひとりが話せるからです。

人数が増えれば、Zoomのブレイクアウトルームを使う方法もあります。

ただ、大人数になるほど、

「よく話す人」
「ずっと聞いている人」

に分かれやすくなります。

飲み会でもありますよね。

この状態には、コミュニティ設計上の問題があります。

公平か不公平か、というだけではありません。

聞き役の人が持っている共通点が、いつまでたっても場に出てこない。

ということです。

話していないのだから、ほかの人が見つけようがありません。

【画像：コミュニティ運営の類似性‐魅力効果】

だから私は、

「全員が均等に話せること」も、共通点を発見するための設計

だと考えています。

私がやっている「1分〜90秒＋バトン」

具体的には、私はタイマーを使います。

一人あたり、

1分〜90秒くらい。

「よく知らない人の話を3分聞く」のは、正直なところ、結構長いと思っています。

でも1分なら聞ける。

全員に順番が回ってくることもわかります。

Zoomのタイマーアプリを全員に見えるように表示して、時間が来たら音楽が流れるようにします。

そして話し終わった人には、

次に話す人を決めてもらいます。

「では次、〇〇さんお願いします」

とバトンを渡してもらう。

司会者だけが次々指名するより、少しだけメンバー同士の関係が生まれます。

小さな工夫ですが、

• 全員が話す

• 時間を独占する人が出ない

• まだ知られていない情報が場に出る

• そこから共通点が見つかる

という流れをつくれます。

ファシリテーションというと「会をスムーズに進める技術」と思われがちですが、

私はむしろ、

まだ場に出ていない人の情報を、場に出す技術

でもあると思っています。

原則3　AIに「仕事以外の重なり」も見つけてもらう

三つ目は、これからますます使えると思っている方法です。

AIによるメンバー同士のマッチング。

たとえばコミュニティのメンバー情報をもとに、

「この2人は話が合いそう」

という組み合わせをAIに見つけてもらう。

ビジネスマッチングでは、すでに考えやすい使い方です。

ただし、ここで重要なのは、

AIは、渡された情報の中からしか共通点を見つけられない

ということです。

仕事、業種、会社、役職。

それしかデータがなければ、AIが見つけるのも仕事上の重なりだけです。

逆に、

• 趣味

• 過去にやっていたこと

• 最近興味があること

• 好きな場所

• 学びたいこと

• 今ちょっと困っていること

などが入っていれば、まったく違うマッチングができます。

つまり、

仕事の情報しか持っていないAIは、仕事の重なりしか見つけられない。

AIマッチングを考える前に、

「そもそも何の情報を持っておくか」

を設計しないといけません。

プロフィール設計とAIマッチングは、実は同じ問題なのだと思います。

【画像：共通点を見つかる場所に置く設計3原則】

共通点を増やしすぎなくてもいい

ここまで「共通点」の話をしてきましたが、一つ線を引いておきたいと思います。

コミュニティ全員が似ている必要はありません。

むしろ、全員が同じだったら、おもしろくない。

共通点は、

仲良くなるための条件ではなく、会話を始める入口

です。

一つ重なるものがある。

そこで近づく。

近づいたあとに、

「そこは全然違うんですね」

が見えてくる。

その違いが、今度は相手への興味になる。

だから私は、

「重なりで近くなり、違いで深める」

くらいがちょうどいいと思っています。

【画像：重なりで近くなり、違いで深める】

「プロフィールを充実させる」だけでは足りない

今回あらためて感じたのは、

コミュニティ設計で考えるべきなのは、

「どんな人がいるか」だけではなく、「その人の何が見つかるか」

だということです。

プロフィールに情報を置く。

交流会で意外な一面が出る問いを投げる。

全員に話す時間をつくる。

そして将来的には、AIにもその重なりを見つけてもらう。

この一連の設計があって初めて、

そこにすでにあった共通点が、

人と人をつなぐ共通点

になります。

前回 #378 では、一人の人間の中にある「多面性」について考えました。

今回は、その増やした側面が、

二人の間で重なる瞬間

の話です。

一人の中に見える面が増えるほど、
誰かとの入口も増えていく。

だから、コミュニティで大切なのは「すごい人を集めること」だけではない。

お互いの意外な一面が、自然に見つかる場所をつくること。

あなたのコミュニティは、

「いつものプロフィール」だけでしょうか。

それとも、

「実は私も」が見つかる場所

になっているでしょうか。

重なりで近くなり、
違いで深める。

そんな関係が少しずつ増えていくコミュニティを、私はつくっていきたいと思っています。

今すぐ登録する

このPublicationでは、コミュニティ運営の現場で試したことや、人と人との関係が自然に生まれる「場の設計」を、実体験とともに掘り下げていきます。

次の記事も読みたい方は、無料で購読しておいていただけるとうれしいです。

事例付き本日のnote記事
https://note.com/msakai2025/n/n890a18294f15
さかい美佐の５分要約音声
https://stand.fm/episodes/6a764524f6328055429b1f00
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

コミュニティを運営していると、こんな言い方をすることがあります。

体のことならAさん。
場を盛り上げるならBさん。
説明会で話してもらうならCさん。

まだメンバー同士がお互いをよく知らない段階では、こうした言葉は役に立ちます。

「あの人は、そういうことが得意なんだ」

と周囲に知ってもらえるからです。

本人にとっても、自分の存在や得意なことを認めてもらえた感覚があります。

だから、「〇〇といえばAさん」というラベル自体が悪いわけではありません。

問題は、そのラベルが一つだけになり、長く固定されてしまうことです。

固定されたラベルは、本人の動きを狭くします。

そして同時に、ほかのメンバーが活躍する余地まで狭くしてしまいます。

今回は、ラベリング理論を手がかりに、コミュニティの役回りを固定させないための3つの原則を考えます。

ラベルは、最初は承認として機能する

コミュニティに参加したばかりの人は、自分がどんな形で関われるのか分かりません。

そんなとき、

「いつも積極的に参加してくれますよね」

「体の動かし方に詳しいですよね」

「場を明るくしてくれますよね」

と言ってもらえると、自分の居場所が見つかったように感じます。

運営者がメンバーの特徴を言葉にすることは、その人の存在をほかのメンバーに紹介することでもあります。

とくに立ち上げ直後のコミュニティでは、こうしたラベルがメンバー同士をつなぐきっかけになります。

「あのことなら、Aさんに聞いてみよう」

という接点が生まれるからです。

ただし、ラベルにはもう一つの働きがあります。

同じ言葉で何度も呼ばれるうちに、本人も周囲も、

「この人は、この役割の人」

と考えるようになります。

承認だった言葉が、いつの間にか役割の固定に変わっていくのです。

一つのラベルが、二つの窮屈さを生む

役割が固定されると、まず本人が動きにくくなります。

いつも話す人は、話さなければいけない。
いつもまとめる人は、まとめなければいけない。
いつも場を明るくする人は、明るく振る舞わなければいけない。

本人が今日は静かに参加したいと思っても、周囲から期待されている役割を降りにくくなります。

そして、もう一つの問題があります。

そのラベルが、ほかのメンバーの席を奪うことです。

「体のことならAさん」

と言われ続けると、同じ分野の知識を持つ別の人は、前に出にくくなります。

「説明会で話すならCさん」

と決まっていると、それ以外の人の事例や視点が表に出にくくなります。

運営者としては信頼できる人に頼んでいるだけでも、周囲には、

「その役割は、もう埋まっている」

ように見えます。

コミュニティの人数が増えるほど、一つのラベルを一人に結びつけ続けることの影響は大きくなります。

では、どうすれば役回りを固定させずに、それぞれの良さを活かせるのでしょうか。

原則1：ラベルを細かくする

一つ目は、ラベルを大きなまま使わず、具体的にすることです。

たとえば、

「整体といえばAさん」

では、範囲が広すぎます。

別の整体師や、体に関わる仕事をしている人が入ってきたとき、参加する余地がなくなってしまいます。

そこで、もう少し細かくします。

「女性の更年期を中心に、大阪で女性専門の整体院を運営しているAさん」

ここまで具体的になると、その人の専門性は伝わりながらも、別の人の席を残せます。

スポーツの体づくりに詳しい人。
高齢者の歩行を支援している人。
産後の体のケアに詳しい人。

同じ「体」の分野でも、それぞれ違うラベルを持つことができます。

これは、役割でも同じです。

「Bさんはリーダーです」

と決めてしまうと、ほかの人はリーダー役を遠慮してしまいます。

でも、

「Bさんは飲み会リーダーです」

なら、席は一つではありません。

勉強会リーダー。
合宿リーダー。
初参加者を迎えるリーダー。
写真を撮るリーダー。

役割を細かくすると、リーダーという席そのものが増えていきます。

役割を奪い合うのではなく、新しい役割をつくれるようになるのです。

原則2：いつもの人以外を探す

二つ目は、登壇や紹介を「いつもの人」だけに偏らせないことです。

コミュニティの説明会やイベントでは、つい話し慣れている人にお願いしたくなります。

コミュニティの活用方法を明確に話せる。
実績が分かりやすい。
人前で話すことにも慣れている。

運営者として頼みやすいのは当然です。

しかし、その人たちだけにお願いし続けると、コミュニティの中で見える成功例や参加の仕方が限られてしまいます。

実際には、意外な人が意外な形でコミュニティを活用していることがあります。

まだ大きな成果にはなっていなくても、面白い使い方をしている人。
独自の視点で参加している人。
本人も気づかない形で、周囲に良い影響を与えている人。

こうした人は、大勢が参加する場だけを見ていても、なかなか見つかりません。

だから運営者には、日頃からメンバーと話すことが求められます。

イベントの感想を聞く。
最近取り組んでいることを聞く。
どんな使い方をしているのか尋ねる。

目立つ人の中から選ぶのではなく、まだ見えていない人を発掘する。

その姿勢が、役回りの固定化を防ぎます。

原則3：意外な一面が出る場をつくる

三つ目は、普段の肩書きや役割以外を話せる場をつくることです。

大勢が参加するオンラインイベントでは、どうしても話題が仕事や活動内容に寄りやすくなります。

限られた時間の中で自己紹介をすると、

「何の仕事をしているか」

「何が得意か」

が中心になります。

そのため、肩書き以外の個性は見えにくくなります。

私は、意外な一面は雑談の中に宿ると思っています。

少人数のオンライン交流会。
ランチ会。
合宿。
移動中の会話。
食事をしながらの雑談。

こうした場では、仕事とは直接関係のない話が出てきます。

合宿で話してみたら、中国武道を続けていることが分かった。
実は水彩画を描いている。
保護猫たちと暮らしている。
同じ地域の出身だった。
同じ高校の先輩と後輩だった。

肩書きだけでは見えなかった接点が見つかります。

すると、その人は、

「〇〇の仕事をしている人」

だけではなくなります。

武道をしている人。
絵を描く人。
猫が好きな人。
同郷の人。
同じ学校に縁がある人。

ラベルが増えるほど、ほかのメンバーとの接点も増えていきます。

仕事の肩書きだけでつながる場とは違う、コミュニティならではの関係が生まれます。

ラベルは、剥がすのではなく増やす

ラベリングという言葉を聞くと、

「人にラベルを貼るのはよくない」

と考えたくなるかもしれません。

でも、ラベルがすべて悪いわけではありません。

人が誰かを理解するとき、何らかの言葉は必要です。

「この人はこういう人」

という入口があるから、関心を持ち、話しかけることができます。

大切なのは、一つのラベルだけでその人を決めないことです。

今の仕事。
過去の経験。
得意なこと。
苦手なこと。
趣味。
出身地。
家族との暮らし。
最近興味を持っていること。
これから挑戦したいこと。

人には、いくつもの側面があります。

人生経験が長くなるほど、ラベルは減るのではなく、増えていきます。

そしてラベルが増えるほど、人とのつながり方も、活躍できる機会も増えます。

コミュニティ運営者の役割は、

「この人は〇〇の人です」

と一つに決めることではありません。

「この人には、こんな一面もある」

と、新しいラベルを見つけ続けることなのだと思います。

役割を増やせるコミュニティへ

「〇〇といえばAさん」

その言葉は、最初は承認になります。

ただし、それを一つの役割として固定してしまうと、本人も、ほかのメンバーも動きにくくなります。

役回りを固定させないためには、次の3つが大切です。

1. 大きなラベルを細かくする

2. いつもの人以外を探す

3. 意外な一面が出る場をつくる

ラベルをなくす必要はありません。

一人に一つしかなかったラベルを、二つ、三つと増やしていけばいいのです。

「リーダー」は一人かもしれません。

でも、

「飲み会リーダー」
「勉強会リーダー」
「初参加者を迎えるリーダー」

なら、席は増やせます。

人の役割も、コミュニティの席も、最初から決まっているものではありません。

運営の仕方によって、いくらでも増やしていけます。

あなたのコミュニティでは、メンバーの役割は固定されているでしょうか。

それとも、新しいラベルと新しい席が、少しずつ増えているでしょうか。

事例付き本日のnote記事
https://note.com/msakai2025/n/n489d9dcf66bf
さかい美佐の５分要約音声
https://stand.fm/episodes/6a74f5b36b5ca1bec7b377ad
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

コミュニティを長く運営していると、やっぱり何かは起きます。

何もトラブルが起きない、ということは基本的にありません。

人と人が集まって、継続的に時間や場所を共にするわけですから、本当に何もないほうが不自然なくらいです。

ドラマも映画も、何かがあるから面白いですよね。

とはいえ、当の本人たちは、そんなふうには思えません。

何か起きるたびに一喜一憂するし、

「どうしてこんなことになったんだろう」

「信頼を失ってしまったかもしれない」

と、運営者ほど落ち込んでしまいます。

私も、何度もありました。

でも、長くコミュニティを続けてきて思うのは、何かが起きた時ほど、運営者の姿勢が伝わるということです。

普段は明るくて、おちゃらけている人が、トラブルの時にはピシッと対応してくれた。

反対に、この人なら安心だと思っていた担当者が、いざという時には逃げ腰になり、言い訳ばかりしていた。

そんな場面を見たことがある人もいるのではないでしょうか。

トラブルは、いいようにも悪いようにも転びます。

その人が何を大切にしているのかが、いちばん見えやすい時間でもあります。

トラブルの後に、前より信頼されることがある

サービスの世界には、「サービスリカバリーパラドックス」という考え方があります。

問題が起きたあと、適切に対応することで、何も問題が起きなかった時よりも信頼が高まることがある、というものです。

もちろん、ミスをすればいいという話ではありません。

起こさないほうがいいミスは、起こさないほうがいい。

でも、どれだけ気をつけていても、人が運営する以上、すべてをゼロにはできません。

だから大切なのは、「転ばないこと」だけではなく、「転んだ後をどう設計しておくか」だと思っています。

![[サービスリカバリーの3原則.png]]

私が大事だと思っているのは、次の3つです。

1．謝罪より先に、まず見通しを伝える

何か起きた時、もちろん謝ることは大事です。

ただ、相手が知りたいのは、「申し訳ありません」という言葉だけではありません。

いつまでに確認するのか。

今、何が分かっているのか。

次にいつ連絡が来るのか。

つまり、見通しです。

「現在確認しています。今日の17時までに一度ご連絡します」

これだけでも、待つ側の不安はかなり変わります。

すぐに解決できない時でも、状況を説明することはできます。

何も分からないまま待たされる時間が、一番不安なんですよね。

![[画像プレースホルダー：謝罪より先に見通しを.png]]

2．気づいた人が、すぐに教えられる関係を作る

私は、何か不備を教えてくださった方に、よくこんなふうに伝えます。

「うっかりさんなので、これからも気がついたらご一報ください」

ちょっと頼りない言い方に見えるかもしれません。

でも、このひと言を伝えておくと、次に何かあった時にも、教えてもらいやすくなります。

たとえば、

「朝の動画が見られません」

とDMをくれる方は、朝に強くて、普段から朝の動画を見てくださっている方です。

行動を見ると、その人の得意なことや、気づきやすい場所が分かります。

オンラインイベントでも、

「何時でも、どんな時でも、不備に気づいたら、その場でメッセージをください」

と伝えるようにしています。

運営者だけで、すべての異変に気づくことはできません。

早く教えてもらえる関係そのものが、トラブルを大きくしない仕組みになります。

3．起きたことを記録して、次の仕組みに変える

トラブルが収まると、ほっとして終わりにしたくなります。

でも、そこで一度だけ、記録を残します。

なぜ起きたのか。

どこで気づけたのか。

次から何を変えるのか。

本当に単純なミスでも、記録しておくと、自分がどこで間違えやすいのかが見えてきます。

たとえば、リンクの間違いが多いなら、送信前にリンクをチェックする工程を作る。

メールのセグメント分けや配信時間で迷いやすいなら、チェック項目を残しておく。

今なら、AIに確認してもらうこともできます。

私は今、本当に毎日AIを使っています。

メールを出す前に、

「この内容で伝わるか」

「リンクに不備がないか」

「対象者と配信内容が合っているか」

と確認してもらいます。

AIは、転んだ後の原因分析だけではなく、転ぶ回数そのものを減らすためにも使えます。

![[転んだ後を設計する3原則.png]]

お金に関わるミスでも、関係が終わるとは限らない

以前、年会員の自動更新について、あるメンバーからご意見をいただいたことがあります。

「勝手に引き落としされていた」

という、よくあるご意見でした。

規約には自動更新について書いてありました。

ただ、その当時は、

「○月○日に自動更新になります」

という事前のご案内をしていなかったんですね。

お金に関わることですから、本来は失敗してはいけないところです。

以前の私なら、

「ここで失敗したら、もう信頼は戻らない」

と思っていたかもしれません。

でも、その方とは、その後のやり取りをきっかけに、以前よりも距離が近くなりました。

最後まで年会員でいてくださり、コミュニティの最後には温かいメッセージもいただきました。

今でも、また会いたいと思う方です。

そして、この出来事をきっかけに、年会員の更新前には、事前案内と私からのご挨拶文をメールでお送りするようになりました。

ミスがあったから良かった、とは思いません。

でも、その方が伝えてくださったから、仕組みを改善できた。

ありがたかったなと思っています。

「お金に関わる失敗は即アウト」なのではなく、お金に関わる大切なところだからこそ、回復の設計が必要なのだと思います。

一番大事なのは、すぐに動ける余力

ここまで、見通し、関係づくり、記録について書いてきました。

でも最近は、もうひとつ、すごく大事なことがあると思っています。

それが、余力です。

どれだけ正しい対応方法を知っていても、日々の仕事でいっぱいいっぱいだったら、すぐには動けません。

連絡を返すことも、

状況を確認することも、

必要な人に相談することも、

余裕がなければ遅れていきます。

ミスの対応が遅れると、トラブルに発展し、その分だけ影響が大きくなります。

だから運営では、頑張り切ることだけが正解ではありません。

何かあった時に、すぐ動ける余白を残しておく。

予定を詰め込みすぎない。

自分しか分からない仕事を増やしすぎない。

チェックをお願いできる人を見つけておく。

AIに任せられる確認は任せておく。

こういう地味な準備が、実は大きなサービスリカバリーにつながります。

![[いつでも動ける余力を作っておく.png]]

何も起きないコミュニティはありません。

そして、何かが起きた時、運営者も完璧である必要はありません。

ただ、逃げないこと。

見通しを伝えること。

教えてもらえる関係を作っておくこと。

そして、次の仕組みに変えること。

ミスそのものよりも、その後の時間に、運営者の姿勢は表れます。

あなたは今、いっぱいいっぱいでしょうか。

それとも、何かあった時に動ける状態でしょうか。

頑張りすぎている時ほど、一度立ち止まって、余力を確認してみてもいいのかもしれません。

事例付き本日のnote記事
https://note.com/msakai2025/n/n489d9dcf66bf
さかい美佐の５分要約音声
https://stand.fm/episodes/6a73a1912136e84def6aa781
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

経営者の方から、こんな質問をいただくことがあります。

「どんな人が、コミュニティマネージャーに向いていますか？」

パッパとタスクを進められる、抜けのない人。

それとも、たまにミスはするけれど、なぜか周囲から許される愛されキャラ。

どちらが向いているのでしょうか。

私の答えは、どちらの一面も持っている人です。

コミュニティ運営では、正確さが欠かせません。

一方で、完璧すぎて隙がなく、メンバーが声をかけにくい運営者よりも、ときどき人間らしさが見える運営者のほうが、親しみを持たれることもあります。

心理学には、能力の高い人が小さな失敗をしたとき、かえって好感度が上がることがあるという「プラットフォール効果」があります。

ただし、ここには重要な条件があります。

失敗すれば、誰でも好かれるわけではありません。

むしろ、失敗の見せ方を間違えると、信頼を失います。

今回は、コミュニティ運営者の失敗が好感に変わる条件を、3つの原則に整理します。

原則1　先に信頼を積み上げる

![失敗を信頼に変える設計3原則]

プラットフォール効果が働くのは、すでに「この人はしっかりしている」という評価がある場合です。

初手から失敗すると、好感には変わりません。

まだ信頼ポイントがゼロの状態でミスをすれば、単純にマイナスから始まります。そして、そのマイナスを取り戻せないことも少なくありません。

大切なのは、失敗そのものではなく、失敗の前にどれだけ信頼が積み上がっているかです。

たとえば、

• 約束した日時を守る

• 質問にきちんと返答する

• 必要な情報を事前に案内する

• 言ったことを忘れない

• トラブルが起きたときに放置しない

こうした日々の積み重ねがあるからこそ、たまに起きた軽微なミスが「人間らしさ」として受け取られます。

「うまくいっている×3、たまに失敗」ならいい

![「うまくいってる×3、たまに失敗」ならいい。逆はだめ]

私が重要だと思うのは、成功と失敗の比率です。

「うまくやっている、うまくやっている、うまくやっている。たまに間違える」

この状態なら、多少のミスがあっても、これまでの信頼が支えてくれます。

「ああ、そんなこともあるよね」と受け止めてもらえる可能性があります。

しかし、

「間違っている、間違っている、間違っている。たまにうまくいく」

この状態では、信頼は積み上がりません。

メンバーの中には、ずっと「この人に任せて大丈夫かな」という不安が残ります。

失敗が好感に変わるかどうかは、失敗の内容だけではなく、その前後に何が並んでいるかで決まります。

抜けていても許されるのは、基本的には抜けない人です。

原則2　失敗してよい領域を間違えない

![失敗が好感に変わる条件の設計3原則]

コミュニティ運営では、すべての失敗を同じように扱ってはいけません。

笑って許される失敗と、信頼を大きく損なう失敗があります。

特に失敗してはいけないのは、メンバーのお金や権利、時間に関わる中核部分です。

たとえば、

• 入会や退会の手続き

• 会費や決済

• 返金

• 個人情報

• イベントの開催日時

• 申込方法

• 参加資格

• 優先申込の条件

こうした領域でのミスは、単なる「おっちょこちょい」では済みません。

メンバーの予定やお金に、直接影響するからです。

一方で、比較的リカバリーしやすい周辺部分もあります。

たとえば、投稿内のリンクが間違っていた、画面共有を忘れて話し始めた、マイクがミュートになっていた、といった失敗です。

もちろん、周辺部分ならミスしてよい、という意味ではありません。

ミスを防ぐ努力をしていても、うっかり起きてしまうことはあります。そのとき、早く気づき、誠実に修正できれば、致命的な信頼低下にはつながりにくいということです。

周辺なら甘えていい、ではない

オンラインイベントで、画面共有をしているつもりのまま話してしまう。

マイクをミュートにしたまま話し続けてしまう。

こうしたことは、多くの人に経験があると思います。私にもあります。

ただし、「こういうキャラだから許してください」と甘えているわけではありません。

本人なりにミスを防ごうとしていても、結果として起きてしまった状態と、最初から確認する気がない状態は、まったく違います。

メンバーは、その違いをよく見ています。

原則3　失敗ではなく、事後の姿勢を見られている

![転ばないようにより、転んだ後にどうするか]

私自身、毎朝7時の投稿にYouTubeのリンクを入れていたとき、リンク先が再生できないことがありました。

毎日リンクを入れ替える運用だったため、その作業の中でミスが発生していました。

そんなとき、メンバーはすぐに連絡をくれました。

私は、よく連絡をくださるメンバーに、あらかじめこうお願いしていました。

「何時でも、どんなときでも、不備に気づいたら、その場でメッセージをください」

ミスが起きた後は、対応までの時間が勝負です。

そして、メンバーが見ているのは、間違いの有無だけではありません。

• 指摘を受け止めるか

• 言い訳をするか

• すぐに確認するか

• 修正後に報告するか

• 同じことを減らす工夫をするか

こうした向き合い方を見ています。

問題が起きたとき、黙って直して終わるのではなく、

「リンクが誤っていました。教えていただきありがとうございます。修正しました」

と伝える。

この一言があるだけでも、受け取られ方は変わります。

完璧であることよりも、不備が起きたときに、逃げずに向き合うことが信頼につながります。

「オペレーションの美しさ」がコミュニティを支える

![コミュニティ運営のプラットフォール効果]

私は、コミュニティ運営では「オペレーションの美しさ」がとても重要だと考えています。

少しドン臭いキャラクターや、親しみやすい運営者が悪いわけではありません。

しかし、コミュニティには複数の人が集まります。

Aさんにとっては笑って許せることでも、Bさんにとっては信頼を失う出来事になることがあります。

運営者とメンバーが一対一であれば、「この人らしいね」で済むかもしれません。

しかし、人数が増えるほど、感じ方や許容範囲も広がります。

だからこそ、基本の運営はきっちり行う必要があります。

そのうえで、ときどき軽微な失敗が見える。

この順番が大切です。

「完璧ではないほうが好かれる」という話を、「きっちり運営しなくてもよい」と読み替えてはいけません。

人間らしさは、雑な運営の言い訳にはなりません。

自分が言ったことを、忘れた状態にしない

私がオペレーションで特に気をつけているのは、自分が言ったことを忘れた状態にしないことです。

たとえば、

「イベントの申込は、○月○日頃に開始する予定です」

と案内したとします。

予定どおりに開始できないのであれば、

「以前は○日に開始するとお伝えしましたが、準備が整っていないため、○日頃に変更します」

と伝えます。

変更すること自体よりも、前に伝えたことをなかったことにしてしまうほうが問題です。

聞くたびに説明が変わる。

以前の案内との違いについて何も触れない。

こうした状態が続けば、メンバーは「何を信じればいいのだろう」と感じます。

相手のお金、時間、注意を多く占有するものほど、運営者は神経を使う必要があります。

「ITが苦手です」で止まってはいけない

コミュニティ運営では、ITやAIのリテラシーも重要です。

もちろん、最初からすべてのツールを使いこなす必要はありません。

しかし、「私は苦手なので」と言ったまま、学ぶことをやめてしまうのは危険です。

現在のコミュニティ運営は、オンラインやデジタルと切り離しにくくなっています。

仮に、活動の中心がリアルな集まりだったとしても、

• 会員情報の管理

• 申込受付

• 決済

• 日程調整

• メール配信

• 問い合わせ対応

• イベント案内

などでは、何らかのシステムやツールを使うことになります。

AIやシステムは、苦手の言い訳に使うものではありません。

運営者の作業を減らし、メンバーと向き合う時間を増やすために使うものです。

ツールを活用して定型作業を減らせば、その分、質問に答えたり、声をかけたり、場の変化に気づいたりする時間を増やせます。

コミュニティ運営者にとって重要なのは、ツールに詳しいことそのものではありません。

より大切な仕事に時間を使うために、学び続ける姿勢を持つことです。

失敗が信頼に変わる3つの条件

ここまでの話を整理します。

運営者の失敗が好感や信頼につながるためには、次の3つが必要です。

1．失敗する前に、信頼が積み上がっている

日頃の約束、対応、案内、進行がきちんとしていること。

「うまくいっている」が十分に並んでいるから、たまの失敗が人間らしさとして受け取られます。

2．中核部分の失敗ではない

お金、入退会、個人情報、権利、重要な日程などは、ミスを防ぐ仕組みが必要です。

笑って許してもらうことを前提にしてはいけません。

3．発覚後、すぐに誠実な対応をする

指摘を歓迎し、早く確認し、修正し、報告する。

必要であれば再発防止まで行う。

信頼を決めるのは、転んだことだけではなく、転んだ後の行動です。

完璧を目指すより、中核の穴を防ぐ

コミュニティ運営者は、ミスをしないように努力する必要があります。

これは大前提です。

しかし、人が運営する以上、すべてのミスをゼロにすることは難しいでしょう。

だからこそ重要なのは、すべてを完璧にしようとすることではありません。

中核の穴は、仕組みで防ぐ。
周辺の欠けは、速やかにリカバリーする。

お金や権利に関わる部分は、チェックリストやダブルチェック、システムを使って守る。

軽微な不備が起きたときは、すぐに認めて修正する。

そして、同じことを少しずつ減らしていく。

完璧ではない人が信頼されるのは、失敗するからではありません。

失敗した後も、誠実に運営を続けるからです。

転ばないようにする努力は必要です。

そのうえで問われるのは、

転んだ後に、どうするか。

あなたのコミュニティ運営は、完璧を目指していますか。

それとも、守るべき中核を守りながら、ミスをリカバリーして成長していますか。

事例付き本日のnote記事
https://note.com/msakai2025/n/na79d1df3dc94
さかい美佐の５分要約音声
https://stand.fm/episodes/6a72595855c133dd99c01b42
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4

「何か質問はありますか？」

そう投げかけても、誰も手を挙げない。

オンライン会議でも、コミュニティのチャットでも、説明会でもよくある光景です。

このとき、運営側はつい安心します。

「きちんと伝わったようだ」
「特に困っている人はいないのだろう」
「順調に進んでいる」

けれど、質問が出ないことと、疑問がないことは同じではありません。

むしろ、全員が似たところで困っているのに、全員が黙っている可能性があります。

その沈黙の背景にあるのが、多元的無知です。

「分かっていないのは、自分だけかもしれない」

多元的無知とは、多くの人が同じ疑問や不安を抱えているにもかかわらず、ほかの人は理解しているように見えるため、自分だけが分かっていないと思い込んでしまう状態です。

コミュニティでは、この状態がとても起こりやすいと感じます。

すでに会話が進んでいる。
参加者同士の関係もできている。
聞き慣れない言葉が当たり前のように飛び交っている。

新しく入った人から見ると、コミュニティは、すでに回っている大縄跳びのようなものです。

縄の中にパッと入れる人もいます。

でも、多くの人はタイミングをうかがいます。

「今さら、こんなことを聞いていいのかな」
「前に説明されていたのを、自分が見落としただけでは」
「ほかの人は分かっていそうだ」
「流れを止めたら申し訳ない」

そう考えているうちに、質問する機会を失ってしまいます。

そして、運営側からは「質問がないように見える」のです。

「私が分かっていないだけだと思うんですが」

質問が出たとき、その最初の一文に注目してみてください。

「私が分かっていないだけだと思うんですが……」
「初歩的な質問ですみません」
「すでに説明されていたら申し訳ないのですが」

こうした前置きは、単なる謙遜ではありません。

質問者が、

「ほかの人は分かっている」
「分かっていない自分のほうに問題がある」

と感じているサインでもあります。

つまり、多元的無知が実際の言葉になって表れているのです。

運営者が見るべきなのは、質問の内容だけではありません。

質問するまでに、その人がどれほど心理的な負担を引き受けたのか。

そこまで含めて受け止める必要があります。

一人が質問すると、「実は私も」が続く

誰かが勇気を出して質問したあとに、こんな反応が続くことがあります。

「私も知りたかったです」
「同じところで止まっていました」
「聞いてくれて助かりました」

運営側としては、「それなら最初から聞いてくれればいいのに」と思うかもしれません。

けれど、質問することと、同意を示すことでは、必要な勇気が違います。

自分から疑問を言葉にして、場の流れを止め、最初の一人になるのは難しい。

一方で、誰かが出した質問に対して「私もです」と手を挙げることは、比較的簡単です。

だから、最初の質問が出たときには、回答して終わりにしないことが大切です。

たとえば、こう続けます。

同じところが分からなかった方は、リアクションで教えてください。

オンライン会議なら、挙手機能やリアクションボタンで十分です。

コメントを書いてもらう必要もありません。

この一言だけで、質問者の個人的な疑問が、場全体に関係するテーマへと変わります。

そして質問者も、

「自分だけが分かっていなかったわけではない」
「自分が聞いたことで、ほかの人も助かった」

と感じられます。

質問者を、場の流れを止めた人ではなく、みんなの理解を前に進めた人に変えられるのです。

沈黙を読み違えない場づくりの3原則

では、質問しやすい場をつくるために、運営側は何ができるのでしょうか。

私が重要だと考えているのは、次の3つです。

1．運営側から「よく聞かれる質問」を先に出す

質問が出るのを待つだけでは、最初の一人に大きな負担がかかります。

そこで、運営側から先に問いを出します。

よく聞かれるのですが、ここは少し分かりにくいポイントです。

初めての方は、この手順で迷うことが多いです。

ここで誤解されやすいのは、〇〇と△△の違いです。

実際に何度も聞かれた質問でなくても構いません。

運営者だからこそ、「ここは分かりにくいだろう」「この表現は誤解されそうだ」と気づいている場所があるはずです。

LPやサービスページにある「よくある質問」も、すべてが実際の質問から生まれたとは限りません。

多くは、利用者が迷いそうな場所を運営側が想像し、先回りして用意したものです。

コミュニティでも同じです。

「よく聞かれるのですが」という言葉には、質問の責任を個人から外す力があります。

誰か一人に名乗り出てもらわなくても、運営側から分かりにくさを認められるからです。

2．表では言いにくい人のために、別の入口を用意する

すべての質問を、全員の前で聞けるとは限りません。

内容によっては、

「こんなことを聞いたら評価が下がるのでは」
「人間関係に影響しそう」
「少し個人的な事情がある」

と感じることもあります。

そのため、公開のチャットだけでなく、別の入口も用意しておくと安心です。

たとえば、

• 運営者へのDM

• 個別相談の時間

• 質問フォーム

• 匿名でも送れる意見フォーム

などです。

すべてを匿名にする必要はありません。

匿名にすると、追加で詳しく聞きたいときに連絡できないという問題もあります。

それでも、「匿名でも送れます」という選択肢が見えているだけで、心理的な安全性は変わります。

コミュニティの性質に合わせて、複数の質問経路を用意しておくことが重要です。

3．言葉だけでなく、行動から「詰まり」を拾う

質問として表に出てこない困りごとは、行動に表れることがあります。

たとえば、

• ログインを始めたのに完了していない

• 会員ページに入って、すぐ離脱している

• 同じ案内リンクが何度もクリックされている

• 特定の手順まで進んだ人が、その先に進んでいない

• 同じ操作に関する問い合わせが繰り返されている

こうしたデータがあれば、どこで詰まっているかを推測できます。

大切なのは、数字を見るだけで終わらないことです。

「ログイン完了率が低い」という数字を見て、

「パスワード設定が分かりにくいのでは」
「ログイン後の画面が想像と違うのでは」
「案内メールが届いていないのでは」

と、人が利用者の状況に翻訳します。

分析ツールやAIを使う場合も、役割は同じです。

異常や傾向を見つけるところまでは仕組みに任せられます。

しかし、その行動の背景にどんな戸惑いがあるのかを考え、場に合う言葉で説明するのは運営者の仕事です。

見つけた詰まりに対して、

よく聞かれるのですが、ログイン後はこの画面が表示されれば完了です。

と先回りして案内する。

この組み合わせは、質問を待つよりも高い確率で、困っている人に届きます。

FAQを増やすと、質問が減ってしまうのか

運営を続けていると、よくある質問は増えていきます。

同じことを何度も説明するのが負担になり、FAQや解説動画を作ることもあるでしょう。

すると、こんな不安が出てくるかもしれません。

「先回りして全部説明したら、コミュニケーションが減るのではないか」

実際には、逆になることがあります。

基本的な疑問が解消されると、その先の質問が出てくるからです。

ログイン方法が分からない人は、ログイン後の使い方を質問できません。

用語の意味が分からない人は、応用について相談できません。

最初の詰まりを取り除くことで、読者やメンバーは次の段階へ進めます。

すると、

「自分の場合は、どちらを選べばいいですか」
「この方法を別の場面でも使えますか」
「ここまでできましたが、次はどうすればいいですか」

という、より具体的な質問が生まれます。

FAQは会話を減らすためのものではありません。

会話を、ひとつ先の段階へ進めるための土台です。

質問者の名前を出すか、出さないか

質問を場全体に共有するとき、質問者の名前を出すべきか迷うことがあります。

ここには一律の正解はありません。

判断基準は、その人が「晒された」と感じるか、「役に立てた」と感じるかです。

たとえば、質問した本人が前向きで、ほかの人からも多くの共感が集まりそうなら、

〇〇さんが聞いてくださったので、解説を作りました。

と伝えることで、その人をヒーローにできます。

一方で、質問者が恥ずかしさを感じそうな内容や、共感者が少なそうな内容であれば、

よく聞かれる質問なので、解説します。

と、個人を出さずに扱ったほうがよいでしょう。

大切なのは、運営者が成果を示すために名前を使うのではなく、質問者本人がどう受け取るかを考えることです。

質問した人が、「聞かなければよかった」と思う場にはしない。

「聞いたことで、誰かの役に立てた」と思える場にする。

この違いは、次の質問が生まれるかどうかを大きく左右します。

いつも同じ人だけが質問していないか

もうひとつ、注意したいことがあります。

質問が出ているからといって、必ずしも質問しやすい場とは限りません。

いつも同じ人だけが質問している場合、その人に「質問する人」という役割が固定されている可能性があります。

ほかの人は、

「あの人が聞いてくれるから、自分は黙っていよう」
「あの人は積極的だけれど、自分はそこまでではない」
「また質問していると思われたくない」

と感じているかもしれません。

質問者が、みんなのヒーローではなく、「いつも質問する少し変わった人」として見られていないか。

運営者は、質問の数だけでなく、誰が質問しているかにも目を向ける必要があります。

質問した人を称えることと同時に、

• リアクションだけで参加できるようにする

• 事前に質問を集める

• 少人数で話す時間をつくる

• 運営側から問いを代弁する

といった方法で、最初の一人の負担を分散させることが大切です。

沈黙は、理解ではなく遠慮かもしれない

質問がないとき、運営側が確認すべきなのは、

「説明したかどうか」ではなく、
「質問できる状態をつくったかどうか」です。

沈黙を、そのまま理解や満足のサインとして受け取らない。

運営側から分かりにくさを認める。
表で言いにくい人の入口を用意する。
行動から詰まりを見つける。
質問者を、場を止めた人ではなく、理解を前に進めた人として扱う。

コミュニティは、最初から輪の中にいた人だけでつくるものではありません。

回っている大縄跳びの外で、入るタイミングを探している人も含めて、場の一員です。

その人が入りやすいように縄を少し緩める。

「ここで入って大丈夫ですよ」と声をかける。

それが、運営者にできる場づくりなのだと思います。

最後に、あなたのコミュニティについて考えてみてください。

質問する人は、いつも同じ人になっていないでしょうか。

その人は「また質問している人」として見られているでしょうか。

それとも、みんなが聞けなかったことを代わりに聞いてくれた、ヒーローになっているでしょうか。

事例付き本日のnote記事
https://note.com/msakai2025/n/nc043b36e7020
さかい美佐の５分要約音声
https://stand.fm/episodes/6a71029718e1d0bb27a82b85
AI時代のコミュニティ運営 —— 感情は人間の仕事、データはAIの仕事
https://note.com/msakai2025/n/n054b6b5245f4