PL-HR7's Wiki

TDiceBot 開発の経緯

2024年11月にDiscordで利用できるダイスボットTDiceBotを公開した。

きっかけ

数年前に身内からDiscord用のダイスボットを作って欲しいと言われ、ボットを作ってみた。このボットはただひとつのスラッシュコマンドである /dice を持ち、計算式を入力するとロール結果を計算して表示してくれるものだった。

ボットの名称は当時話題になっていた「タコピーの原罪」からタコボットと命名され、人知れずどこかで密かに稼働していた(表記上は這い寄るDiceBotだが)。

なんと関数も使えるのだ。

高機能だからいいというわけではない

ただ、このボットには欠点があった。それはどんなコマンドが使えるのかを把握しないといけないということで、help コマンドでどんな機能があるか確認できるようになってはいたが、実際これを見せられたところでなにができるのか分からないということが問題だった。

高機能っぽく見えるけど関数ってナニ？

タコボットの敗因

help の内容を見てピンとくるのはプログラマか数学者かあるいはExcelの操作に長けた会社員だけではないだろうか？

そもそもダイスロールをしたいユーザーは簡単にダイスロールをしたいのであって、こういう式や関数を組み合わせて自分の目的となる処理をしたいわけではないし、MAX(2d6 + 1, 5) というダイスロールを見せられたとして、まわりの人間がそれが意味するところを正しい理解できないといけない。ユーザーが欲しがっているのは高機能な関数電卓ではなく、ダイスローラーであることを失念していたのである。

新しいボットを作りたい

正直タコボットは失敗だった。端的に言えば不必要な高機能が備わっていたのである。業務ならまだしも、娯楽で関数式を組み立てるほどのことはしたくないのである。いくら柔軟で数式が書けてもこれでは利用者が使いたいと思わない。

タコボットを作ってからちょうど1年ほど経ち、ある程度時間的余裕も生まれたのでこれを機にボットを再設計することにした。とはいえ、単純に作り直すだけでは前回となんら変わらないので、身内だけでなく不特定多数に対しても展開できるようなサービスを狙ってみた。

不特定多数に対してサービスを提供することは簡単ではあるものの、そもそも使われなければボットを作り直すだけの価値がないので、次の三点を再確認することにした。

競合の調査

失敗作といえど、タコボットの開発経験は無駄ではなかったはずである。敗因を分析してそれが解消できた結果、新しいボットがいいサービスとなりうるならば、身内だけに留まらず不特定多数に提供できないかと考え、まずは競合となりうるサービスを調査することにした。

結果としてTRPG用のダイスローラーは基本的にセッション用ツールと統合されていることが多く、Discord向けのものは国内でも数えるほどしかないことが確認できた。これであれば参入できる余地はあるはずだ。

既存サービスに対する優位性

私のサービスは後発なので、既存のサービスよりも優位性がなければ採用されない。ただ、既存サービスのすべての機能を上回る必要もないと考えている。これはコピー商品を作ってしまう(作られてしまう)と行き着く先は価格面での戦いになってしまうからだ。

サービス同士が価格で戦い始めるとユーザー視点では安く使えて嬉しいが、提供価格が安くなることによりサービスが維持できなくなると、やがてサービス自体が消滅してしまう。これはサービスの提供者と利用者でお互いに不利益な状況になるので、こういったことは避けるべきである。

そのために既存サービスにない優位性を提供することで価値を示すことが必要と感じている。TDiceBotにおいては後述の哲学の項で細かく説明するが、やることとやらないことをあらかじめ決めて、ユーザーにとって期待されたとおりの洗練されたサービスを提供することを第一の目標にしている。

小さく素早く始める

インターネット文化が成熟してSNSが浸透した現代では情報が氾濫し、ユーザーがとれる選択肢は多岐に渡る。一般論として使われないものを時間をかけて作っても意味がない(私のこれは趣味なので問題ないが)。そのため、最低限必要とされる機能を決めてサービスを構築することに注力した。

その結果、タコボットは当初見込んでいた1週間程度でTDiceBotに転生を果たし、サービスを開始した。今はまだ利用者が少ないものの、徐々に認知が広まり導入数が増えていくはずだ。

既存の仕組みを使わない

Discordでボットを作成する際に discord.js や discrod.py といったライブラリを選択することは開発スピードの面では有利だ。特にDiscordのAPIを隠蔽してコードファーストで手軽に機能を実装できることは魅力的と言える。しかし、こういったライブラリを使うことは、ボットの主機能がライブラリに強く依存することになる。

私の経験する限り、現代の一般的なアプリケーションはある程度の規模になると、まったくライブラリに依存しないことはまずあり得ないが、特定のアーキテクチャ層として分離できる範疇に納まらないと、ライブラリの破壊的変更に巻き込まれやすくなる。うまくライブラリとアプリケーションが噛み合わなくなると対処に苦慮するか、解決に時間がかかることになりかねない。

開発は大変になるものの、のちのメンテナンスまで見据えるとアプリケーションの設計で重要な部分は自身で構築したほうが取り回しがよく、不確定要素に振り回される心配もない。これはDiscordライブラリだけでなく、ダイスロールの部分も同様で、既存のソフトウェアに大きく依存しない作りになっている。

TDiceBotの哲学

TDiceBotには哲学を設定することにした。それぞれについて賛否両論はあるが、これらの方針を明確にすることで、あらかじめ開発者(私)とユーザーの認識をすり合わせて、双方にとって好ましい関係が構築できることを期待している。

スラッシュコマンド

TDiceBotが提供するのはいくつかのスラッシュコマンドに限られる。これはDiscordに推奨された方法であるだけでなく、以下のいくつかの理由に基づくものである：

  1. ユーザーの発言に対して反応するボットを作成することもできるが、昨今データプライバシーが叫ばれる中で、すべての発言を確認する仕組みにすることは導入する側にとって抵抗感があると判断した。また、サーバー管理者がボットを導入するだけで、参加者全員にもその影響が及ぶ点も留意しなければならない。
  2. すべての投稿に対して特定の文字列(コマンド)が含まれているか走査することは、ボットの通信量が増え、負荷が大きくなる。ダイスロールのリクエスト頻度が通常会話を超えることはないと推測できることから、ほとんどの時間は本質的でない処理を行なっており、維持費の単純な増加に繋がる。
  3. ユーザーの発言に反応するという仕様は、ユーザーの発言が自由形式がゆえに前述のタコボットの「どういった構文が使えるかわからない」という問題を解決できていない。その点スラッシュコマンドではコマンドの説明を確認できるため、不慣れでも扱いやすいと言える。
  4. いっぽうで、特にスマートフォン環境においてはスラッシュコマンドを入力することは手間であることは否定できない。これについてはよく使うダイスロールに関してはショートカットとなるコマンドを用意してなるべく負担に感じないようにしている (例: /expr に対する /d100 コマンド)。

最小限の洗練された機能

サービスは使われていくうちに機能が増えていくことが多いと考えられる。しかし、欲しいと言われたもの闇雲に追加していくことが常にいいとは限らない。わずかな機能をうまくやってくれることを期待していたはずが、時を経て紆余曲折あり、いつのまにか使うことのない機能にあふれたシステムができあがっているということは避けたいと考えている。

  1. TDiceBotは本質的な機能のみの提供にとどまる。ここでいう本質的というのは、ダイスロールや数値計算のことを指しており、それ以外のものは提供する予定がない。
  2. もしダイスロールの域を超える機能が欲しいということであれば、それを行なってくれる仕組みを別途導入するべきである。そうすれば、ユーザーごとに必要な機能を取捨選択できるようになり、把握もしやすくなる。
  3. ジョークコマンドの類は提供せず、ジョークを伴う応答もしない。ジョークというものはしばしば時事ネタやインターネットミーム、オタク(ギーク)知識等の影響を受け、人によっては不快さや苛立ちを感じるためである。前項と同じようにジョークが必要であればそのための仕組みを別途導入するべきである。

高速で安定した動作

ユーザーに使われるものは得てして信頼性が求められている。いつでも期待する動作が期待した通りに動くことが当たり前でなければならない。

  1. 応答速度がなるべく速くなるように設計されている。タコボットは起動速度と実行速度に難があり、コールドスタートの際にしばしばDiscordの3秒レスポンスルールに引っかかっていた。これはいうまでもなくユーザー体験を損なう要素であり、TDiceBotではアーキテクチャを変更してこの問題を解消している。
  2. クラウドコンピューティングサービスを利用して、稼働率100%に近い設計になっている。アップデート時のダウンタイムもなく、いつでも利用できるようになっている。もちろんサービス側が障害を起こした場合までは担保できない。

見て楽しい出力

ほとんどの状況で重要視されるのは過程ではなく結果である。しかし、同じ結果になったとしても過程が重要とされる場合もある。TRPGをプレイしているという文脈では 2d6+1 が振られて 7 が得られたしても、その内訳がないとなんとなく心情的に納得できず無機質なものとなる。ここでふたつの例を出してみる：

  • 2d6+1 → 7
  • 2d6+1 → 🎲2 + 🎲4 + 1 = 7

ふたつの表記のうち、より納得できて見やすいのは後者のはずだ。また、重要な部分を強調することで、見て楽しい表示にもなる。TDiceBotではこの「楽しませる表示」を強く意識している。

ダイス目なのか技能値なのかわかりやすい

有料プランへの誘導や広告の表示をしない

最近のインターネットは悲しいかな、おそろしいほどに広告にあふれるようになってしまった。あらゆるものが収益に結び付けられてビジネス至上主義の時代がやってきた。そしてユーザーはサービスを利用するために、見たくもない広告を見ることを強要されている。

TDiceBotはその機能において有料プランへの誘導や広告の表示をしないことにしている。広告ほど興醒めするものはない上に、サービスの本質的な部分でもないからだ。

その代わりに無料プランでのサービスの利用に上限を設けている。これはパトロンサービスの支援プランに加入することで、利用制限を緩和や撤廃することできるようになっている。

このドネーションウェア的な収益モデルはWikipediaやThunderbirdでも失敗を見ているが、実際どのくらいのユーザーがこのサービスに価値を感じて支援をしていただけるかの実験も兼ねている。