Self-Made Keyboards in Japan こと自作キーボード Discord サーバーでアクセスコントロールとその bot による自動化を導入した話
TL;DR
リモートワーク / WFH や STAY HOME 等でネットワークを介したコミュニケーション手段が非常に求められている中、Discord サーバー運用のノウハウとして カテゴリやチャネルのアクセスコントロールの仕方と bot による自動化 についてまとめます。
Self-Made Keyboards in Japan Discord サーバー
2 年半ほど前から Self-Made Keyboards in Japan という自作キーボードコミュニティのサーバーを Discord で運用しています。
大変ありがたいことに非常に多くの方に利用していただいており、メンバーはそろそろ 3000 人になろうかというところです。感謝🙏
今春、サーバーメンバーが多くなってきたこともあり、より一層コミュニティとしての機能を拡充したいという思いから、キーボードに直接は関係ないチャネル群とそれをまとめるカテゴリを導入しました。一方で「キーボードサーバー」としての混乱をきたさないことも期待されており、今回カテゴリ単位での可視性・アクセスコントロールを導入しました。
その手順と自動化手法、オマケとして導入経緯や判断について簡単に紹介します。
チャネル・カテゴリ単位でのアクセスコントロール
Discord のチャネルやカテゴリに対するアクセスコントロールの設定法は既存のチャットアプリなどと比べるとやや特殊に見えるかもしれません。
Slack ではプライベートチャネルは「プライベートチャネルを作って」「そこに招待された人だけが見える」という比較的オールドスクールな手法によっています。対して Discord ではこのようなアクセスコントロールをするために role という概念を用います。一見複雑ですが、きめ細やかな権限管理が柔軟にしやすく非常に便利です。
role
Dircord における role というのは、簡単に言うとユーザーにつくラベルです。そしてチャネルやカテゴリに対して、その role というラベルごとに 読み書き等の権限を管理することができます。個人ではなく role に対して権限管理を行うため
- 個人単位での権限管理が不要で
- 権限設定の複雑化・意図しない権限付与バグを防ぎやすく
- 権限のオンオフを role というテンプレート付与剥奪で冪等にできる (←自動化しやすい)
というメリットがあります。
Biacco42 というアカウントには managers Nitro Booster enable-other-category という role が付与されていることが確認できます。
チャネル / カテゴリを不可視にする
Discord の role による権限管理は非常に柔軟で様々なことができるのですが、基本的に必要なのは 読み書き権限のコントロール かと思います。
Discord では
サーバー全体での role による権限管理 → カテゴリの権限管理 → チャネルの権限管理
のように階層化された権限管理モデルが採用されています。より狭い範囲での権限設定が優先され、変更しないものに関しては上位の権限設定が継承されます。
これを利用して「カテゴリ A の中では role α だけが書き込むことができる」「チャネル B は role β しか見れないし書き込めないプライベートチャネル」というような管理が可能になります。
例えば上記画像は、管理者アカウントによる bot の動作テスト用のチャネルの権限設定の一部で、 everyone role の Read Message 権限が剥奪され、 managers role が付与されている人たちのみこのチャネルを見ることができるようになっています。真ん中のグレーの斜め線は上位からの権限の引き継ぎを表しています。
まとめると、カテゴリやチャネルに
everyoneなど全員が該当する role で読み書き権限を制約- 許可したい role ごとに読み書き権限を設定
でプライベートチャネルをつくることができます。
role 付与の自動化
会議体のようなある程度固定した組織運用をする場合は上記のカテゴリ / チャネルの権限設定をして管理者権限でユーザーごとに role を付与すればよいのですが、Self-Made Keyboards in Japan のような多人数のオープンコミュニティではそれを人力で管理するのはだいぶ無理があります。また、厳密なアクセスコントロールが必要なわけではなく、「単純に興味がなくて表示を減らしたい」「一部チャネルについては別途規約に同意してほしい」などといった場合には、ユーザーが制限された範囲内で自由に role を付け外しできる方が好ましいです。
ここからは、そういった role 付与の自動化について説明します。
role 付与を管理する bot を導入する
こういったチャットサービスの自動化といえば bot の導入が手軽です。ですが bot を別途サーバーなどでホストするのはインフラ的にも運用的にもコストが重いです。今回のような role 付与をするぐらいであれば bot のホスティングを含んだサービスを利用することで導入・運用コストを大幅に引き下げることができます。
今回は Dyno というサービスを利用する方法を紹介します。今やろうとしている role の付与程度なら無料プランで利用できる大変太っ腹なサービスです。
Dyno のサイトにアクセスして右上の Add To Server を押して、自身の Discord アカウントに紐付いた サーバー管理権限のある サーバーに bot を追加します。その際 bot に付与する権限を確認されます。
Administrator や Manage Server 等の強い権限はその権限を必要とする機能を利用しなのであれば外しておいたほうが安全です。今回は role の付与とテキストコマンドの削除等だけできればいいのでかなりの権限を制約しておきました。接続が完了すると Discord サーバーの方に bot が参加して、Dyno のページに自動的に遷移します。
Dyno には非常にたくさんの機能があるのですが、不用意に発動されると困るため今回利用する Custom Command 以外は Module / Command ですべて無効にしておきました。利用したい場合は適宜有効化してください。
めちゃくちゃたくさんの機能があります。
role を付与する Custom Command を設定する
Dyno には標準で role {user} {role} というコマンドがあるのですが、これを誰でも使えるようにしてしまうと好き勝手に role が振れるようになってしまい大変危険です。そのため Custom Command という機能を利用してこの role コマンドを安全にラップします。
Custom Command は bot が読み取ることができるチャネルで {prefix 文字列}{Command 文字列} と入力すると Response が実行されるものです。prefix 文字列はデフォルトで ? ですが変更することが可能です。
Dyno の管理画面の Custom Command のページを開き Add Command でコマンド追加画面を開きます。
Command 欄には受け付けるコマンドの文字列を、Response には実行する機能やテキストチャネルに書き込む文字列を記述します。今回の設定では、 #enable-other-category チャネルでのみ ?i-agree-to-the-terms-of-use を入力すると enable-other-category role がオン・オフできるようになっています。
上記画像では
- Command を
i-agree-to-the-terms-of-useに - Response を
{require:#enable-other-category}と{!role {user} enable-other-category}に
設定しました。前述の通り、なにも制限しなければ bot が読み取り可能なすべてのチャネルでこのコマンドが発行されてしまうため、require によってこのコマンドが利用可能なチャネルを #enable-other-category のみに制約しています。 {!{既存コマンド}} で既存のコマンドを呼び出すことができ、{user} などの事前適宜 Variable によって値を埋めることができるので、 role コマンドをこの Custom Command を発行したユーザー {user} と enable-other-category を引数として呼び出しすとことで role の付与のオン・オフを制御します。
このように Custom Command で既存コマンドをラップすることで、動作を制限して安全に任意のユーザーに利用してもらうことが可能になります。
利用できるコマンドはこれ以外にもたくさんあります。詳細については Dyno のドキュメントを確認してみてください。
このようにして、Dyno を利用することで bot サーバーをホスティングすることなく Discord の role 付与を安全に行うことができます。
以上で role 付与、カテゴリ / チャネルのアクセスコントロールの自動化は完了です。お疲れさまでした。
余談
今回、Self-Made Keyboards in Japan Discord サーバーでは、自作キーボードサーバーというトピックサーバーならではの問題として、オフトピックな話題を「コミュニティ」としてどう扱うかという観点で、OTHER カテゴリというカテゴリを導入し、上記の可視性のコントロールを設定しました。
人間、多様な側面を持っているものですから、キーボードのことで意気投合した人々と、キーボードを離れて単に雑談をしたり他の趣味を共有したりといったコミュニケーションを取りたい、人間関係を構築したい、というのは自然な欲求かと思っています。また、そういった刺激が新たな創発の原動力になりうるとも思っています。一方で、Self-Made Keyboards in Japan はキーボードをメイントピックとしたサーバーなので、そういったチャットはノイズという捉え方も可能です。
それらどちらか一方を取るのではなく、個人の自由と裁量に任せてサーバーが運用できたらという思いで今回のような施策を実施しました。他のサーバーでも似たような問題に悩んでいる管理者の方がいるのではないかと思い、今回この記事を書きました。そのような悩めるサーバー管理者の一助になれば幸いです。
おしまい。
