多言語コミュニティの運営方法（2026年版）

5つの言語の話者が集まったコミュニティは、1つのコミュニティではありません。言語を1つ決めた1つのコミュニティか、ログインだけを共有する複数のコミュニティか、そのどちらかです。そのどちらでもないふりをすることが失敗の始まりで、しかもそれは静かに進みます。何かが壊れるわけではなく、ただ人が読まなくなるだけです。

ほとんどの運営者は、計画してではなく成り行きでこの状況にたどり着きます。コミュニティが成長し、創設時の言語を話さないメンバーが加わり、気づけばフィードの半分が、大半の人が読み飛ばす言語で埋まっています。

言語が混ざったフィードが失敗のかたち

すべての言語を1つの流れに入れることは、包摂的な対応ではありません。それは全メンバーのフィードを、大半がノイズという状態にしてしまいます。

5つの言語のうち1つを読むメンバーは、5件の投稿のうち4件をスクロールで飛ばすことになります。これは好みの問題ではなく算数の問題であり、訪問の頻度を落とすのが合理的な反応です。その結果、コミュニティは全員にとって同時に閑散として見えます。最も多くを占める言語の話者にとっても、それは同じです。

影響は苦情ではなく、沈黙というかたちで現れます。フィードが読めなくなったと、わざわざ書いてくる人はいません。毎日だった訪問が週1回になり、やがて月1回になり、数字の上では、下したことのない構造上の判断の結果ではなく、ごく普通の離脱に見えます。

構造の選択肢は3つ

ここで現実的に取りうる構造は3つだけで、それぞれに代償があります。正しく選ぶことよりも、意図して選ぶことのほうがはるかに重要です。一般的な考え方はコミュニティの構造の作り方にまとめています。

1つ目の選択肢に運営者は罪悪感を抱きがちですが、その必要はありません。英語で運営していると明言するコミュニティのほうが、4つの言語を競わせて声の大きい言語をひそかに優遇するコミュニティよりも、参加者に対して誠実です。明示しておけば、無視されたと感じた後ではなく、参加する前に判断してもらえます。

言語を切り出すタイミング

判断の基準は、メンバー全体に占める割合ではありません。運営者がその場にいなくても、そのグループだけで会話が続くかどうかです。

実務的なテストはこうです。そのスペースを週に1度のぞくメンバーは、毎回なにか新しいものを見つけられるでしょうか。見つけられないなら、切り出したことでそのメンバーは、半分しか分からないが賑わっている場所から、完全に理解できるが誰もいない場所へ移されたことになります。そして後者のほうが悪い状態です。

実際のところ、言語グループには、促されなくても投稿する常連が数人必要だということです。人数ではなく、脈があるかどうかを見ます。書く人が10人いれば、それは場になります。読むだけの人が60人いても、場にはなりません。

より多いのは、分けるのが早すぎるという失敗です。しかも取り消すのが難しいのはこちらです。いったんスペースを作って空のまま放置されると、それは「自分のような人はここにいない」という証拠として読まれます。元に戻すのは失敗を公に認めることになるため、たいていの運営者は、空の部屋をそのまま残してしまいます。

インターフェースの言語とコンテンツの言語は別物

この2つは絶えず混同されますが、まったく別の問題です。

インターフェースの言語とは、ボタン、メニュー、設定、通知メールのことです。コンテンツの言語とは、メンバーが実際に書く言葉のことです。ソフトウェアは前者を完全に解決できますが、後者はまったく解決できません。

Mateflow では、インターフェースが8言語（英語、スペイン語、フランス語、ドイツ語、ポルトガル語、日本語、韓国語、中国語）に対応しており、各メンバーが自分の設定で使う言語を選びます。そのため、2人が同じディスカッションを、それぞれ別の言語のナビゲーションで読むこともできます。また管理者は、コミュニティ全体のデフォルト言語を1つ設定することもできます。これは、コミュニティを単一の言語で運営すると決めたときに使う設定です。

ただし、これはメンバーが書いた内容を翻訳してくれるものではありません。投稿は、書かれた言語のまま残ります。だからこそ、前述の構造上の判断こそが重要になるのです。誰にも読めないフィードから救ってくれるインターフェース設定は、存在しません。

読めない言語はモデレートできません

これこそが、いくつの言語を支えられるかを実際に決めている制約であり、たいていは気づくのが遅れます。

機械翻訳は、その投稿がおそらく問題ないと判断するには十分です。しかし、その投稿が問題だと判断するには不十分です。皮肉、内輪の侮辱、率直と残酷の境目、そして誰かが困っていることを示す独特の言い回しは、どれも翻訳をうまく生き延びません。運営者が読んでいるのは、メンバーが読んでいるものとは別のバージョンです。

ですからルールは単純です。モデレートできない言語を開いてはいけません。最初のトラブルが起きた後ではなく、スペースを作る前に、その言語をネイティブに読める人を確保してください。その方法はボランティアモデレーターの集め方で解説しています。

その人たちに独自の基準を作らせるのではなく、同じ基準を渡してください。ルールは1セットだけ用意し、それを異なる言語で読む人たちが適用します。安全や法律に関わることについては、運営者に戻す共通のエスカレーション経路を用意します。そうしなければ、2つの文化を持つ2つのコミュニティへと少しずつ分かれていきます。それこそ、避けようとしていた結末です。土台となる実務についてはオンラインコミュニティのモデレーションで詳しく扱っています。

翻訳すべきもの、手をつけないもの

すべてを翻訳するのはコストが高く、その大半は無駄になります。価値があるのは3つで、それ以外にはありません。

ルール。行動規範と、誰かが退会処分になりうる事柄のすべてです。メンバーが読めなかったルールを執行するのは、執行ではなく罠であり、もめ事になれば真っ先に突き返されます。

オンボーディング。歓迎のことば、案内、どこに何を書けばよいのかの説明です。ここは、メンバーがこの場所は自分に向いているかを判断する瞬間であり、同時に、推測の手がかりが最も少ない瞬間でもあります。

約束の内容が変わること。料金の変更、移転、終了、方針の転換です。メンバーが受け取るものに影響するなら、対応すると掲げているすべての言語で告知します。

それ以外、つまり日々の会話、返信、ごく普通の投稿の流れには、手をつけないでください。進行中のディスカッションを翻訳するのは、持ち時間をすべて使い切ったうえで、誰も完全には信用しないものを生み出す最短の道です。メンバーは一般に、自分で頼んで表示させた機械翻訳を読むことには抵抗がありません。一方、運営側が本人の名前で公開した翻訳を読むことには、はるかに抵抗を感じます。

隠れたコストは語数ではなく時間

運営者は翻訳の予算は見込んでおきながら、日程の調整で不意を突かれます。

言語グループはタイムゾーンごとに固まる傾向があるため、2つ目の言語は通常、全員が参加する1つのイベントではなく、2つ目のライブ開催枠を意味します。つまり、同じイベントを2回企画し、2回開催し、2回フォローアップすることになります。詳しくはコミュニティイベントの開き方をご覧ください。

この負担は、コミュニティ運営のうち規模が変わっても一定な仕事ではなく、規模とともに増えていく仕事のほうに、正面からのしかかります。そして運営者を消耗させるのは、その増えていく側です。まだ正直に見積もっていないなら、言語を増やした後ではなく前に見積もってください。コミュニティ運営にかかる時間が参考になります。

結論

言語の問題は意図して決め、その決定を書き出し、参加する前に見える場所へ掲げてください。

新しい言語を開くのは、その言語で話す人たちの集まりが実際にすでにあるとき、その言語を読める人がモデレートできるとき、そして2つ目の恒例企画を回すだけの時間があるときに限ってください。1つの言語をきちんと支えるほうが、3つの言語を薄く支えるよりも優れています。そして、正直に断ったメンバーのほうが、誰も返事をしない場所に迎え入れたメンバーよりも、あなたを良く評価してくれます。