コミュニティ運用をコードで表現する — Slack を題材にしたポリシー・モデレーション・招待フローの実装

なぜ「コードで表現する」のか — 属人運用の限界

Slack 上のコミュニティが100人を超えたあたりから、運営者は次のような状況に直面します。

• 招待のたびに「この人を入れていいか」を運営チャットで個別に判断している
• ウェルカムメッセージを誰が・いつ送ったか分からない
• チャンネルが増えすぎて、何のためのチャンネルかを誰も把握していない
• ルール違反の対応が、その時の運営担当者の気分で揺れる
• 運営メンバーが交代するたびに、引き継ぎ資料が増えていく

これらはすべて 運用が運営者の頭の中にしかない ことから生まれる症状です。属人運営の限界と、その背景にある考え方は コミュニティ開発という考え方 — プログラマブルなコミュニティ設計論 で扱いました。本記事はその実装編として、Slack を題材に どうコードで表現するか を具体的に示します。

「コードで表現する」とは、Web インフラで広まった Infrastructure as Code (IaC) の発想をコミュニティ運用に持ち込むことです。チャンネル構成・利用規約・モデレーションルール・招待フローを、画面上の操作ではなく テキストファイル として管理し、Git で履歴を残し、Pull Request でレビューしながら変更する。これが Community-as-Code の核心です。

---

Community-as-Code の3つの構成要素

Slack 上の運用をコード化する対象は、大きく次の3つに整理できます。

構成要素	何をコード化するか	主に使うツール
運用ポリシー (Policy as Code)	利用規約・チャンネル構成・ロール・行動規範	Markdown / YAML + Git
モデレーション (Moderation as Code)	介入トリガー・自動レスポンス・エスカレーション経路	YAML + Bot / Workflow Builder
招待フロー (Invite Flow as Code)	招待 → 審査 → オンボーディング → ロール付与	フォーム + Webhook + Slack API

これら3つを、リポジトリの中で1つのコミュニティ運用基盤として束ねてコードベースにするのが Community-as-Code です。以下、それぞれを順に見ていきます。

---

運用ポリシー (Policy as Code)

チャンネル構成を YAML で宣言する

Slack のチャンネルは管理画面から作成・削除できますが、これを画面操作で運用すると次の問題が起きます。

• 何のために作ったチャンネルか、半年後に誰も思い出せない
• 似たようなチャンネルが乱立する (#dev と #development と #engineering)
• アーカイブ判断が属人的になる

これを防ぐために、チャンネル構成をリポジトリで宣言的に管理します。

config/channels.yaml

channels:
  - name: announcements
    purpose: 運営からの公式お知らせ。投稿は運営のみ
    topic: 重要なお知らせはここから
    visibility: public
    post_permission: admins_only
    archive_policy: never

  - name: introduction
    purpose: 自己紹介。新規参加者は最初にここに投稿する
    visibility: public
    post_permission: members
    archive_policy: never

  - name: random
    purpose: 雑談。仕事と関係ない話題はここに集約する
    visibility: public
    post_permission: members
    archive_policy: low_activity_90d

  - name: events-2026q2
    purpose: 2026年Q2のイベント運営
    visibility: public
    post_permission: members
    archive_policy: end_of_quarter

このファイルを Git で管理し、変更は Pull Request 経由で行います。purpose フィールドにチャンネルの存在理由を必ず書く規約を設けるだけで、半年後の整理が劇的に楽になります。

このファイルから Slack API を叩いてチャンネルを同期するスクリプトは、最初は小さな実行スクリプトで十分です。手で同期するだけでも、「リポジトリが正、Slack が従」という関係を運営チームで共有できれば、属人化はかなり防げます。

利用規約と行動規範を Markdown で管理する

利用規約 (Code of Conduct) は、Slack の #welcome や #rules チャンネルにピン留めされたメッセージとして運用されがちですが、これは履歴が追えず、変更時のレビューもできません。

docs/
  ├── code-of-conduct.md       # 行動規範 (変更は PR + 運営合意)
  ├── terms-of-use.md          # 利用規約 (変更は PR + 運営合意)
  ├── moderation-policy.md     # モデレーション方針
  └── escalation-flow.md       # トラブル時のエスカレーション経路

リポジトリの docs/ 配下に Markdown で置き、変更は必ず Pull Request を経由するルールにします。Slack のピン留めメッセージは、このリポジトリ上の URL を指すリンクだけにしておきます。これで「いつ、誰が、なぜ規約を変えたか」がすべて Git の履歴として残ります。

ロールを設定ファイルで宣言する

Slack の User Group (有料プラン) は、@moderators のような形でメンション可能なロールを作る機能です。これも運用上の意味を持つ単位なので、コードで管理します。

config/roles.yaml

roles:
  - handle: moderators
    purpose: 一次モデレーション・新規参加者対応の責任を持つ
    members:
      - alice
      - bob
    promotion_rule: 運営合意 + 3ヶ月以上の継続参加

  - handle: speakers
    purpose: 月次LTイベントで登壇予定のメンバー
    members:
      - charlie
      - dave
    promotion_rule: 自薦 + 運営承認
    archive_policy: 登壇後30日で自動的に外す

ロールの付与・剥奪は手作業でも構いませんが、誰がそのロールを持つかをファイルで宣言する こと自体に意味があります。「あれ、この人なんで @moderators に入ってるんだっけ？」がなくなります。

---

モデレーション (Moderation as Code)

介入トリガーをルールとして外出しする

モデレーション Bot を作るとき、最初の判断は 「ルール (何を検知するか) を、実行コード (どう動くか) と一緒に書くか、分けて書くか」 です。一見すると同じファイルに書いた方がシンプルに見えますが、運用に乗せると必ず破綻します。ルールは設定ファイル、実行はコード に分けるべき理由は次の4つです。

1. 変更頻度が桁違いに違う。Bot の実行ロジックは数ヶ月に一度しか触りませんが、ルールは「先週このスパム文面が流行った」「新規メンバーの初日だけは少し緩めたい」といった現実の事象に応じて毎週のように追加・調整されます。頻繁に変わるものと滅多に変えないものを同じファイルに置くと、頻繁な変更がコードの稀少な変更を巻き込み、レビューも事故も増えます。
2. 編集できる人を分けたい。ルールはモデレーターや運営 (非エンジニアを含む) が直接編集できる必要があります。コードに埋め込むと、ルール一行追加するだけでエンジニアの作業待ちが発生し、結局「Slack 管理画面で手動対応」に戻ってしまいます。設定ファイルなら YAML の書き方さえ共有すれば運営が自走できます。
3. 「なぜそのルールがあるか」を残す。description フィールドや PR の議論として、ルールを追加・削除した理由を Git の履歴に刻めます。半年後「このキーワードを禁止してるのなぜ？」となったときに、当時の文脈を復元できます。逆に言うと、コードに埋め込まれた if ... contains("FREE BTC") には文脈が残りません。
4. 可逆性が高くテストしやすい。ルールは宣言データなので、効かなければ消すだけで戻せます。実行コードに埋まっていると、削除のたびにロジックを読み直して影響範囲を確認する必要があります。さらに「このメッセージはルール X にマッチするか」を、ルール集合 + 実行ロジックのユニットテストとして書けます。

この4つはどれも、Web サービスでルールエンジン (LaunchDarkly のフィーチャーフラグや、Open Policy Agent の Rego など) が普及しているのと同じ理由です。変更頻度・編集権限・監査性・可逆性が異なる関心ごとを、ファイルとして物理的に分離する という発想を、コミュニティ運用にも持ち込みます。

具体的には次のような形になります。

config/moderation-rules.yaml

rules:
  - id: link-in-first-post
    description: 参加初日のメンバーが外部リンクを貼った場合の検知
    condition:
      member_age_days: { lte: 1 }
      contains: ["http://", "https://"]
    action:
      type: notify_moderators
      channel: "#mod-alerts"
      template: "新規メンバー {{user}} が初日にリンクを投稿しました: {{message_url}}"
    severity: low

  - id: spam-keywords
    description: 既知のスパムキーワード検知
    condition:
      contains_any: ["FREE BTC", "click here to win"]
    action:
      type: auto_remove
      notify_moderators: true
    severity: high

  - id: high-frequency-post
    description: 短時間の連投検知
    condition:
      messages_in_window: { count: 10, window_minutes: 5 }
    action:
      type: rate_limit
      duration_minutes: 30
    severity: medium

このルールファイルを Bot が読み込み、定義に従って動作する設計にします。ルール変更は Pull Request で行い、運営チームのレビューを経てマージされます。誰がいつどんなルールを追加・変更したかが Git で追跡できる状態が、ガバナンスの根幹です。

介入タイミングは「自動 + 人間」のハイブリッドで

すべてを自動化するのではなく、自動検知 → 人間判断 の二段階で設計するのが現実的です。

重大度	自動アクション	人間の関与
低 (low)	モデレーターに通知のみ	24時間以内に1人が確認
中 (medium)	一時的な制限 + 通知	当日中に運営合意で対応決定
高 (high)	即時削除 + 通知	即時に責任者が事後確認・本人連絡

「自動で消す」ことを最小限に抑え、「自動で気づく」ことを最大化する設計が、誤検知による信頼の毀損を防ぎます。介入タイミングについては、別記事「モデレーターはいつ口を出すべきか — 介入の最適タイミング」を執筆予定ですが、要点としては「流量が認知限界に達している」かつ「自律的にスレッドが立っていない」状態が介入の最適点になります。

---

招待フロー (Invite Flow as Code)

招待フローは Community-as-Code で最も成果が見えやすい領域です。属人運営では次のような状態になりがちです。

• 招待を頼まれた運営者が、その場で Slack の招待リンクを送る
• 申請者の情報を運営チームで共有する仕組みがなく、誰が招待したか不明
• 入った直後にどう動けばいいか分からず、沈黙の参加者が増える

これを次のような 状態遷移 として設計します。

[申請] → [審査] → [承認] → [招待] → [参加] → [オンボーディング] → [本登録]
            ↓                                     ↓
         [却下]                                [離脱]

各状態の遷移条件と自動化を、コードで表現します。

招待フォーム + Webhook の最小構成

最小構成では Slack 招待を直接送らず、フォーム経由で申請を受けてから運営承認後に招待リンクを発行します。Astro / Cloudflare Workers / Slack API を組み合わせた例:

// functions/invite-request.ts
export async function onRequestPost({ request, env }) {
  const { email, name, motivation, referrer } = await request.json();

  // 1. 申請を D1 に記録 (状態 = pending)
  await env.DB.prepare(`
    INSERT INTO invitations (email, name, motivation, referrer, status, created_at)
    VALUES (?, ?, ?, ?, 'pending', ?)
  `).bind(email, name, motivation, referrer, Date.now()).run();

  // 2. 運営の #invite-review チャンネルに通知
  await fetch("https://slack.com/api/chat.postMessage", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${env.SLACK_BOT_TOKEN}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      channel: env.INVITE_REVIEW_CHANNEL,
      blocks: buildInviteReviewBlocks({ email, name, motivation, referrer }),
    }),
  });

  return new Response(JSON.stringify({ ok: true }));
}

審査は Slack 上の Approve / Reject ボタンで行い、Approve されたら別の Worker が招待メールを送信します。招待がいつ・誰の判断で・なぜ通ったかが、すべて DB と Slack の履歴に残る状態になります。

オンボーディング自動化

招待を受けて参加した直後の体験は、定着率に直結します。Slack の team_join イベントを Webhook で受け取り、自動でオンボーディング Bot がメッセージを送る設計が一般的です。

config/onboarding.yaml

onboarding:
  - step: 1
    timing: on_join
    action: send_dm
    message_template: docs/onboarding/welcome.md
    next_action_required: true

  - step: 2
    timing: on_join + 1h
    condition: { has_posted_in: introduction }
    action: invite_to_channels
    channels: [random, weekly-checkin]

  - step: 3
    timing: on_join + 24h
    condition: { has_not_posted_in: introduction }
    action: send_dm
    message_template: docs/onboarding/nudge-introduction.md

  - step: 4
    timing: on_join + 7d
    action: send_survey
    survey_id: first-week-feedback

ステップごとの条件分岐をコードに埋め込まず、設定ファイルで宣言することで、運営チームの非エンジニアメンバーでも改善提案ができるようになります。

---

運用基盤 — Bot とドキュメントサイトを長く動かすための原則

ここまでの YAML や TypeScript は、それ単体では動きません。Bot を実行する場所、設定を反映するパイプライン、メンバーが読むドキュメントの配信先、そしてそれらへのアクセス制御が必要です。Slack 上の運用 (前半) と並行して、これらの 運用基盤 をどう組むかが、Community-as-Code を継続できるかを分けます。

具体的なツール選定 (Cloudflare Workers / Vercel / GitHub Actions / VitePress / Hugo / etc.) は環境次第で変わって構いません。むしろ重要なのは、どんな技術選定をしても外せない5つの設計原則 です。

原則	何を実現するか
1. モノレポで全要素を一つに束ねる	規約・Bot・ドキュメントの整合性を保つ
2. Bot の実行場所は3階層で考える	過剰な実装と運用負荷を避ける
3. 公開ドキュメントは静的サイトとして配信する	メンバーが読み返せる場所を作る
4. 認証はアプリに書かず、インフラ層に逃す	コミュニティに閉じない汎用設計を保つ
5. デプロイは PR トリガーで自動化する	「手作業の本番反映」を構造的に排除する

以下、それぞれの原則を順に見ていきます。

原則1: モノレポで全要素を一つに束ねる

招待フォーム・モデレーション Bot・ドキュメントサイト・共有設定をそれぞれ別リポジトリで管理すると、変更が複数リポジトリに跨る瞬間に運用が崩れます。利用規約を更新したらドキュメントサイトと Bot のメッセージテンプレートも揃えて変えたい、というのは日常的に起きるからです。

これを避けるために、コミュニティ運用に関わる全要素を一つのリポジトリで管理する ことを推奨します。物理的に同じリポジトリにあれば、規約の変更とそれを参照する Bot 側の挙動変更を、一つの PR でまとめてレビューできます。

リポジトリの中身を概念的に分けると、次の4つです。

• 公開ドキュメント (メンバーが読むハンドブック・規約・ガイド)
• アプリケーション (Slack Bot ・ 招待フォームの Webhook ・ 計測ジョブ)
• 共有設定 (チャンネル・ロール・モデレーションルール・オンボーディングの YAML)
• 共有ライブラリ (設定読み込み・Slack API クライアントなど、複数アプリで再利用するロジック)

ツールとしてはモノレポを扱える任意の仕組みで構いません (Bun workspaces / pnpm workspaces / Turborepo / Nx など)。重要なのは「Bot の変更とドキュメントの変更が、同じ PR で説明できる状態」を維持することです。

原則2: Bot の実行場所は3階層で考える

Slack Bot を作るとき、最初から自前のサーバーを立てる必要はありません。実行場所の選択肢は大きく3階層あり、下から順に試して、必要になったときだけ上に上がる のが運用負荷を抑える鉄則です。

階層	向いているケース	コスト感
L1. プラットフォーム標準機能 (Workflow Builder など)	定型応答・固定的な招待フロー	ゼロ円。停止リスクなし
L2. サーバーレス関数 (任意の FaaS)	Webhook 駆動のイベント処理・短時間ジョブ	従量課金。スケール自動
L3. 常駐サーバー (任意の VM / コンテナ)	長時間処理・WebSocket 維持・大量バッチ	24h 稼働費 + 障害対応の運用責任

「とりあえず VPS を借りて Bot を動かす」を最初にやると、運用負荷とコストが先に発生し、コミュニティが小さい間に疲弊します。動くものを最小コストで先に出し、必要が見えてから格上げする という順序を守ります。

L2 のサーバーレス関数を選ぶとき、汎用的な型として覚えておきたいのは次の2つのハンドラだけです。

• Webhook ハンドラ — Slack からのイベント (メッセージ投稿・参加・リアクション) を受け取り、設定ファイルに照らして応答する
• スケジュールハンドラ — 1日1回・週次など、時間トリガーで定例の集計や通知を流す

この2種類で、モデレーション・オンボーディング・健全性レポートまでカバーできます。具体実装はランタイム (Workers / Lambda / Cloud Functions / etc.) によって書き方が違うだけで、構造は共通です。

原則3: 公開ドキュメントは静的サイトとして配信する

利用規約や行動規範を Git 管理することと、それをメンバーが読める形で 配信 することは別の問題です。Slack のピン留めメッセージだけに頼ると、検索性が低く、半年経つと誰も読みません。

コミュニティ向けに 独立した公開ドキュメントサイト を持つことで、次の状態が成立します。

• メンバーが「あのルール、どこに書いてあったっけ」を検索で解決できる
• 規約変更が PR レビューを経て、自動デプロイで本番反映される
• 新規参加者のオンボーディング動線として、Slack から外部 URL を1本指すだけで足りる

Markdown を入力にできる任意の静的サイトジェネレーター (VitePress / Astro / Hugo / Docusaurus / MkDocs など) で実現できます。重要なのは 「規約の原本は Git 内の Markdown、配信は静的サイトジェネレーター、ホスティングは静的サイト配信サービス」という分離 であって、特定の組み合わせではありません。

ドキュメントサイトの URL を Slack のチャンネルトピックや /help ワークフローから固定リンクとして指しておくと、規約の変更がメンバー側の体験に自動で反映されます。

原則4: 認証はアプリに書かず、インフラ層に逃す

ドキュメントサイトをメンバー限定で公開したい、招待フォームを既存メンバーだけに見せたい、といった要件は必ず出てきます。このとき アプリケーションコードに認証を書かない ことが、Community-as-Code で最も価値ある設計判断の一つです。

「認証は書かない」とは、ログイン UI・セッション管理・パスワードリセット・MFA を アプリの前段 (リバースプロキシ / Identity-Aware Proxy / SSO ゲートウェイ) で完結させ、アプリは「認証済みのリクエストだけが届く前提」で書く、という構造です。

この設計が効く理由は3つあります。

1. 認証はバグとセキュリティ事故の温床。自前実装は監査・運用負荷が大きく、専門サービスに任せた方が圧倒的に安全です。
2. 権限変更が設定で完結する。退会者の権限剥奪・新規モデレーターの権限付与を、アプリのコードを触らずに許可リストの更新だけで実行できます。
3. テンプレートとしての複製コストが下がる。アプリに認証ロジックがなければ、別コミュニティへリポジトリを複製したとき、テナント固有の認証実装を考えずに済みます。

ツール選定としては、IdP (Google / GitHub / Microsoft などの SSO) と、その認証結果をアプリ前段で検証してくれるゲートウェイ製品 (Cloudflare Access / Google IAP / AWS Cognito + ALB / Auth0 + リバースプロキシ など) を組み合わせます。どれを選んでも、アプリ側のコードが「認証済みヘッダーを信頼する」という1行に近づくのが正しいゴールです。

逆に言うと、「ログイン画面を作りたい」という発想が出てきたら設計を疑う くらいでちょうどいいです。

原則5: デプロイは PR トリガーで自動化する

設定変更が反映されるタイミングが「運営者が手でデプロイコマンドを叩いたとき」だと、せっかくコード化しても属人化が再発します。「main ブランチが本番である」「PR マージで自動デプロイされる」 という GitOps の発想を、コミュニティ運用にも持ち込みます。

最低限自動化すべきフローは次の3つです。

• 規約・ドキュメントの変更 → ドキュメントサイトの再ビルド・再配信
• 設定ファイル (YAML) の変更 → Bot が次回起動時に新しい設定を読み込む (もしくは Webhook で hot reload)
• アプリコードの変更 → Bot 実行環境への自動デプロイ

CI 設定では paths フィルタを使って「ドキュメントだけ変えたときに Bot まで再デプロイしない」ような最適化を入れます。同時に、API トークンや認証情報は リポジトリに書かず CI のシークレット管理に置く のが大原則です。これを徹底できると、リポジトリそのものを別コミュニティに複製しても秘匿情報が漏れません。

PR レビューを通った変更だけが本番に届く状態を作ること自体が、運営チームのガバナンス手段になります。「いつ・誰が・なぜそのルールを変えたか」が PR の議論として永続的に残るのは、口頭合意では絶対に得られない価値です。

---

プログラマブル化の落とし穴

実装に踏み込むほど、避けたい落とし穴も明確になります。

1. 機械化しすぎて情緒的価値を壊す

ウェルカムメッセージを Bot に任せたきり、運営者から個別の声かけが消えると、新規参加者は「歓迎されている感」を失います。自動化は声かけを減らすためではなく、声かけに使う時間を増やすため にあります。

2. ルールをコードにすると変更コストが上がる

Pull Request 経由でしか変更できない規約は、緊急時に変えづらくなります。これを避けるため 「変えにくい層 (規約・ロール) 」と「変えやすい層 (告知文・イベント企画) 」の分離 を徹底します。すべてをコード化するのではなく、変更頻度に応じて格納先を変えます。

3. ツール依存が新たな属人化を生む

カスタム bot を作りすぎると、その bot を作った人がいなくなった瞬間に運用が止まります。標準機能 (Workflow Builder ・ Slack API) で実現できることは、まず標準機能で実装する ことを原則にし、カスタム実装は本当に必要な領域に絞ります。

4. 「人間の判断」を消してはいけない領域

招待の最終判断・違反の重大度判定・卒業の声かけといった、信頼や共感が必要な領域は 意図的にコード化しない ことが正解です。コード化しないという判断もまた、コミュニティ開発における設計判断の一つです。

---

段階的に導入する道筋

すべてを一度に整える必要はありません。次の順序で段階的に進めるのが現実的です。

フェーズ	やること	期間の目安
0. 文書化	利用規約・チャンネル構成・運営ロールを Markdown で書き出す	2週間
1. ポリシー as Code	上記をリポジトリに移し、変更を PR 経由にする	1ヶ月
2. 運用基盤の足場づくり	モノレポ + ドキュメントサイト + 自動デプロイ + 認証 (アプリの外側) を整える	1〜2ヶ月
3. 招待フロー	申請フォーム + 運営承認 + 招待自動送信を実装	1〜2ヶ月
4. オンボーディング自動化	参加後の Bot メッセージ・チャンネル招待を自動化	1ヶ月
5. モデレーション as Code	検知ルールを設定ファイル化し、Bot を導入	2〜3ヶ月
6. 計測ダッシュボード	健全性指標を自動計算し、運営定例で参照する	1〜2ヶ月

フェーズ0と1だけでも、属人運営からの脱却としては大きな前進です。最初から bot を書こうとせず、まずは文書化と Git 管理から始める のが堅実なルートです。フェーズ2の運用基盤は、Bot やフォームを作る前の土台として済ませておくと、以降のフェーズで「動かすこと自体」に時間を取られません。

---

まとめ — コードで表現できる部分を増やすことが、コミュニティを長く続ける条件になる

Community-as-Code の目的は、コミュニティを機械化することではありません。運営者が信頼関係の構築に時間を使えるようにするために、判断不要な手続きをコードに任せる ことです。

属人運営の温かみと、コードによる再現性は、対立しません。むしろコードで表現できる部分を増やすことで、運営者は「この人は何を悩んでいるか」「この場の温度はどうか」といった、コードでは表現できない領域に時間を使えるようになります。

最初の一歩として、次の問いを運営チームで話してみてください。

• 運営者が毎週・毎月、同じ判断を繰り返している作業は何か？
• 半年前に決めたルールが、なぜそうなったか説明できるか？
• 運営者が交代したら、何ヶ月で同じ品質に戻せるか？

これらに即答できない項目があれば、そこが Community-as-Code の最初の対象になります。

コミュニティ運用の仕組み化や、Slack 上の運用基盤の設計を伴走する支援が必要な場合は、六瀬のコミュニティサポートサービスをご検討ください。

関連記事

• コミュニティ開発という考え方 — プログラマブルなコミュニティ設計論
• 企業コミュニティを始める前に決めるべき3つのこと
• コミュニティKPIの選び方と運用のコツ
• コミュニティ運営で「文脈設計」が先に必要な理由