週20時間の作業を自動化！コミュニティ運営パイプラインの作り方
私は、技術系非営利団体でコミュニティリーダーとしてボランティアをしています。無料のトレーニングプログラムとメンターシップを通じて、人々がテクノロジーの世界に足を踏み入れる手助けをするのが使命です。役割は二つに分かれています。Slackでメンバーの質問に答えることと、非営利団体のソーシャルチャンネルを運営し、より広いコミュニティに役立つコンテンツを発信することです。
Slackには多くのチャンネルがあり、常に目を配るのは難しいですが、そのうち4つのチャンネルがトラフィックの大半を占めています。それらを合わせると、週に約80件の質問が寄せられます。以前は、コンテンツ制作のたびに、手作業でスレッドをすべてスクロールし、パターンを見つけ、よく出てくるトピックを中心にカレンダーを作成していました。うまくいった週でも、投稿は2～3件。1件あたりのリサーチ、執筆、スケジュール設定、コメント返信に3～5時間かかり、合計で週15～20時間を本業に加えて費やすことになり、燃え尽きてしまいました。
もっと効率的な方法が必要だと感じ、私はパイプラインを構築しました。コミュニティのワークスペース内の会話を監視し、見逃されがちな質問を表面化させ、共通の悩みをより多くの人にとって役立つコンテンツに変える仕組みです。このパイプラインは、4つのチャンネルをスキャンし、実際の質問には私が承認・送信できる下書きを返信し、公開に値する質問を私の文体で記事にまとめ、Bufferに送ってスケジュール設定できるようにします。
投稿を公開する理由は、Slack内のメンバーだけがコミュニティのすべてではないからです。多くのメンバーは毎日ソーシャルメディアをチェックしますが、ワークスペースを開くのは週に1度。そして、私たちが支援したいと思っているまだ見つかっていない人々は、検索エンジンが届かないログインの向こう側にある答えを探しています。質問はもちろん最初にチャンネル内で回答されます。しかし、同じ回答を人々がすでにスクロールしている場所に公開すれば、スレッドが静かになった後もずっと役立ち続けます。
ここでは、どのように構築したか、そしてそれが私の仕事量とコミュニティの体験をどのように変えたかを説明します。
手動での対応が限界に達した理由
量そのものは管理可能でした。問題は、最もキャッチすべき質問が最も見逃されやすいことでした。いくつかの要因が重なっていました。
- 質問が埋もれる：4つのチャンネルでは、チャットやブレインストーミング、考え事を声に出す会話も行われ、重要な質問は速い流れに沈んでしまいました。
- タイムゾーンの壁：私はナイジェリアにいますが、メンバーはヨーロッパ、アメリカ、そしてその間の複数のタイムゾーンに広がっています。夜にラップトップを閉じると、朝には寝ている間に積み重なった会話の連なりがあり、質問がずっと未回答のままになっていました。
- 締切日に殺到：私たちは応募締切が厳格な無料トレーニングプログラムを運営しており、人々は最終日に応募しがちです。ブロッカーにぶつかると、一気に何百ものメッセージが届きます。もし1つの返信を逃すと、その人が返事を聞く前に登録が締め切られてしまいました。
- 最も助けが必要な人は決して質問しない：新しくて恥ずかしいから、あるいは一度質問して埋もれて諦めたからです。そのため、一人か数人が質問をあげたとき、その質問はたいてい、声をあげなかった大勢の代弁者でした。それらの質問こそ、公開で回答する価値があるのです。
これらの背後には、タイムリーに助けを得られなかった誰かがいます。それが、次の誰かが質問する前に、答えがすでに公開されている場所にあるようにする仕組みを作ろうと思った原動力です。
今では、毎日、コミュニティが尋ねたことを読み、どの質問が公開回答に値するか判断し、投稿の下書きを準備してすぐに出せる状態にしています。私だけができる役割、つまり公開する内容のレビューと承認だけを残しています。
パイプラインの5ステップ
パイプラインは5つのステップで構成されます。Read（読み取り）、Filter（フィルタ）、Archive（アーカイブ）、Cluster（クラスタリング）、Publish（公開）（Buffer経由）です。ワークフローはGumloopというローコードキャンバスで構築しており、AIステップ、API呼び出し、カスタムノードを一つに連鎖させています。
最初の3ステップで、生のSlackトラフィックをクリーンでタグ付け可能なアーカイブに変換します。最後の2ステップで、公開回答に値するものを判断し、Bufferに送ります。
Read（読み取り）：4つのチャンネル内のすべてのメッセージは、GumloopのAI Extract Dataノードを通過します。一回の処理で、メッセージが質問かどうか判断し、回答の下書きを作成し、その下書きへの自信度を「High」または「Needs Verification」でスコアリングし、テーマ（オンボーディング、請求、技術、機能リクエストなど）をタグ付けします。このステップではGPT-5.4 Miniを使用しており、複数フィールドの抽出をクレジットを消費せずに処理します。自信度スコアは便利で、私の判断が本当に価値を発揮する部分に注意を集中させ、すべての行を同じようにレビューする必要がなくなります。
Filter（フィルタ）：別のカスタムノードが、質問と判定された行だけを残し、それ以外を削除します。フィルタリングを独立したステップにしたのは、AIに1パスで1つの判断をさせ、その判断をデータに可視化したままにするためです。もし誤分類が始まったら、アーカイブを見ればわかりますし、その呼び出しは監査可能な形で記録に残ります。
Archive（アーカイブ）：フィルタを通過したすべてのデータは、Notionデータベース「Community Ops Log」に書き込まれます。10のフィールド（質問者、チャンネル、テーマ、下書き回答、元メッセージへのリンク、ステータスなど）を持ちます。2つのビューがあります。すべてのデータのテーブルビューと、ステータス（要レビュー、確認済み、返信済み、却下）でグループ化されたカンバンレビューボードです。このステータスフィールドによって、アーカイブは受動的なログから、実際にトリアージできるものに変わります。一目で、どれだけの下書きが待っているか、どれだけ処理済みか、どれだけ保留にしたかがわかります。
Cluster（クラスタリング）：私の好みのAIモデルであるClaude Opusが、質問を根本的な問題でグループ化し、どの質問が公開回答に値するかを判断します。パイプラインの判断の中核なので、後ほど詳しく説明します。
Publish（公開）：選ばれた質問はコンテンツアイデアと投稿下書きになり、Bufferに直接プッシュされます。
スクリーンショットに関する注意：以下のスクリーンショットに表示されるSlackワークスペース、チャンネル、メンバーデータは、実際のコミュニティのスレッドを非公開にするためにこの記事用に作成したシミュレーションです。パイプラインは実際に稼働しているものと同じです。
[Gumloopでの完全なワークフロー。左から右へ：AI Extract Dataノードの設定、フィルタステップ（質問のみ保持）、Community Ops Logのテーブルビュー、ステータス別カンバンレビューボード]
パイプラインがソーシャルチャンネルで回答すべき質問を判断する方法
このステップはおそらく最も難しく、最も重要です。これがないと、すべての質問が投稿になり、キューがノイズで埋まってしまいます。そのため、パイプラインはデフォルトで投稿しません。
NotionリーダーがCommunity Ops Logからすべてのデータを取得し、GumloopのAsk AIノード（Claude Opus実行）に渡します。一回のパスで、プロンプトが質問をクラスタリングし、表現が異なっても同じことについて尋ねているものをグループ化します。次に、各クラスタに公開投稿に値するかスコアを付け、重複を削除し、選ばれたテーマに対してコンテンツアイデアと投稿下書きを作成します。
[テーマ分析ジェネレーター（Ask AIノード）の設定]
2番目のカスタムノードが、その出力をプレーンなルール（AIなし）で解析し、同じクラスタから常に同じ構造化された行を生成します。
[サンプルクラスタ出力とラベル付きフィールド]
目標は、公開回答に値する質問を表面化することです。特に、少数の人（あるいはたった一人）しか思いつかなかった貴重な質問を含みます。これらは最も見逃されやすく、しばしば沈黙の大多数が答えを必要としているものです。
そのために、各テーマは3つの基準に対して簡単なチェックを受け、少なくとも2つをクリアすれば昇格します。
- メンバーは既に自分で解決できるか？ もし既存のドキュメントで約15分以内に解決できるなら、投稿には値しません。
- コミュニティのかなりの割合に影響するか？ およそアクティブメンバーの10～20％が目安です。ただし、ルールは2/3なので、まれな質問でも他の基準をクリアすれば通過できます。これは、1～2人しか尋ねなかった高価値の質問のための安全弁です。
- 本当のギャップか、単なるドキュメント修正か？ 答えが不足機能や混乱を招くパターンなど構造的なことを指すならカウントします。「ドキュメントを更新すべき」というだけなら、公開投稿ではなくドキュメントに属します。
[3つの昇格基準]
また、昇格キャップもあります。モデルが1回の実行でクラスタの70％以上を昇格させた場合、停止し、最も弱いものから最も強いものへ再ランク付けし、明らかに昇格に値するものだけを残します。これは、LLMがすべてを昇格させたがる傾向があり、選択的であることが目的だからです。
私が意図的に除外したのは頻度です。ほとんどのコミュニティツールは頻度順にソートします。これはトリアージには理にかなっています（よくある質問から答える）。しかし、コンテンツにとっては、同じソートが私が最も見つけたい質問を埋もれさせます。したがって、単一の質問でも実際のギャップを明らかにすれば投稿に値しますが、「どこから始めればいい？」という8つのバリエーションはそうではないかもしれません（特に私の答えはたいてい「ドキュメントを読んで」だからです）。
パイプラインは、スコアリング、下書き作成、プッシュをすべて自動で行います。私のレビューは最終段階でBuffer内で行われます。アイデアはCreateスペースに届き、投稿は公開前に最終チェックのためにキューで待機します。
Bufferがシステムにどのように適合するか
3つのカスタムノードが引き継ぎを処理し、それぞれが単一のBuffer API呼び出しを担当します。最初のノードは、昇格した各テーマに対してBufferのCreateスペースにアイデアを作成します。他の2つは投稿をキューに入れます（X用とThreads用）。Bufferが自動的に日付を分散させるので、手動で時間を設定する必要はありません。
BufferのAPIをローコードツールやスクリプトから呼び出す際の実用的な注意点：リクエストはブラウザから来ているように見える必要があります。BufferのAPIはCloudflareの背後にあり、自動化トラフィックをフィルタリングします。そのため、生のスクリプトはまさに捕捉対象です。解決策はヘッダーにあります。リクエストに添付される小さなラベルで、受信サーバーに誰が何を求めているかを伝えます。標準の2つ（コンテンツタイプとアクセストークン）に加えて、実際のブラウザが通常送信する4つを追加しました。
- どのブラウザか
- どの形式を期待するか
- リクエストがどのサイトから来ているか
これらを設定すれば、すべての呼び出しが問題なく通過します。以下のスクリーンショットに6つのヘッダーが表示されています。
[Bufferプッシュノード、Cloudflareを通過させる6つのヘッダー]
プッシュ完了後、結果は2番目のNotionデータベース「Content Pipeline Log」に送信されます。各テーマには「アイデア作成済み、Xキュー済み、Threadsキュー済み」などのステータスが、実行日と元の質問へのリンクとともに保存されます。そのため、すべての投稿はそれを生んだ質問に遡れます。投稿が異常に良いパフォーマンスを示した場合、その背後にある質問を見つけ、周辺のフォローアップに値する質問を探すことができます。また、非営利団体の役員から公開コンテンツの選択基準を問われた場合も、正確な質問、チャンネル、日付を示せます。
[NotionのContent Pipeline Log、各テーマのプッシュステータス]
Bufferは私のレビューの場でもあります。アイデアはCreateスペースに届き、投稿は公開前に最終チェックのためキューで待機します。こちらのスクリーンショットは最初の完全実行時のもので、4つのチャンネルから18の質問を取得し、5つのコンテンツアイデアと10のスケジュール投稿（Xに5、Threadsに5）に変換しました。
[BufferのCreateスペース（5つのアイデア）と公開キュー（スケジュール投稿）]
投稿を自分らしく聞こえるようにする方法
これは私が最も心配していた部分です。汎用的なAIがコミュニティコンテンツをどう変えるか見てきたので、公開するものがコンテンツボットのように読めるのは避けたかったのです。そこで、モデルに何かを生成させる前に、実際の自分の書き方のサンプルを見せて、パターンを抽出させ、可能な限り一致させました。4つのサンプルを使いました。2つはSlack内でのピア返信、1つは別の場所での長文投稿、1つはDM（最も自然な文体）です。
サンプルに加えて、プロンプトにいくつかの厳格なルールを与えました。
- タイトルは短く具体的に、リスト構成は避ける
- 投稿はフックではなく状況説明で始める
- 口調は会話調で対等に
- エムダッシュとAIの冗長表現は禁止
最後のルールは、最初の実行と最終実行の間に行った主要な調整です。初期出力はすでに私らしく聞こえましたが、エムダッシュにやや過剰に依存していることに気づきました。エムダッシュは長年作家が使ってきた完全に正当な句読点ですが、実際にはAIが普及させるまで私はそれを使っていませんでした（そのキーがキーボードのどこにあるのか正直わかりません）。
最後の要素は自己チェックです。プロンプトが内容を確定する前に、自身の出力を禁止パターンについてスキャンし、すり抜けたものを書き直します。このステップが、サンプルマッチングだけでは見逃される小さなAIらしさを捉えます。文体が本当に合うまでには数回のテストが必要でした。しかし、一度合うと、投稿は私が自分で書いたかのようなものになり始めました。
[ビフォーアフター：汎用的なAI生成投稿と、声のサンプル追加後の同じ投稿の比較]
これまでの変化
パイプラインは最近できたばかりで、まだ確固たるエンゲージメント数値を示すには至っていません。数回の実行が数週間続いている程度で、違いは感じられますが、チャートで証明できるほどではありません。しかし、いくつかの変化、特に私の働き方に気づいています。
まず、以前コミュニティ運営に費やしていた週15～20時間が、ごく一部にまで削減されました。トリアージ、下書き作成、手動コンテンツカレンダーはすべてパイプライン内で行われ、私に残されたのはレビューと承認だけです。これこそ私が最も必要としていた変化でした。
締切のストレスも大幅に減りました。過去のトレーニングラウンドで最も多かったブロッカーは、次の応募日の殺到が来る前にすでに公開回答されています。そのため、同じ質問が積み重なることが少なくなりました。洪水が来ても、答えはすでにそこにあることが多いのです。
気づくのに最も時間がかかった変化は、実は私が最も気にかけているものです。寄せられる質問が変わってきました。元の問題を再質問するのではなく、人々は公開投稿を参照し、その上に次の質問を重ねるようになりました。これは、コンテンツが私の主目標である、最初は声を上げなかったメンバーに届いているという強いシグナルです。
なぜこれを構築したのか
ボランティアの役割は小さなコミットメントではありません。成長するコミュニティを率いることは、本業の上にある本当の仕事であり、私が真剣に自動化を検討し始めた頃には、それが有給の仕事に食い込み始めていました。何かをしなければならないとわかっていました。
実用的な理由は、ほとんどの人が共感できるものです。私のコミュニティチームの他のメンバーはエンジニアではないため、私なしでも使い続けられるものが必要でした。それが、私の特定のスタックが適切だった理由です。チームの誰でもGumloopでプロンプトを調整したりステップを変更したりでき、Bufferは出力を実際のコンテンツカレンダーに変え、見ることができ、スケジュール設定でき、信頼できます。今や仕事は誰か一人が起きていることに依存しません。私が机にいようと、別の大陸で眠っていようと、誰かが物事を進められます。
また、ボランティアには私を引き寄せる何かがあります。時々、神は私たちに期待せずに与え、自分では決して収穫しないかもしれない種を蒔くように導くのだと思います。これを構築することは、その小さな方法の一つでした。あのチャンネルの中のすべての質問は、学び、構築し、前進しようとしている実際の人間に属しています。助けられた人が多ければ多いほど、その努力はやりがいのあるものに感じられました。
構築の準備はできましたか？
BufferのAPIを試すなら、始めるためのリソースがあります。開発者向けドキュメントでは、GraphQLスキーマ、認証フロー、クイックスタート例をカバーしています。Buffer MCPサーバーのドキュメントでは、ClaudeやMCP対応AIエージェントへのプラグイン方法を説明しています。
手動でのサポートが必要な場合は、サポートチームが対応します。また、Discordサーバーに参加して、APIを使って構築している他のユーザーとチャットすることもできます。
あなたが作るものをぜひ聞かせてください。Discord、または主要なソーシャルチャンネルで@bufferまで。