ミリシタ7周年で多分いちばんBot作ってた人の話(Botの話だけ)
序論
「Bot作成なら全1です。」
イベントお疲れ様でした！
— きゃな(サベ) (@deco_dreaming) July 12, 2024
2年連続で美也100傑で終わり！(TPMも確定。もう少しだけスコアタするよ)
今年は裏でずーーーーっとコード書いてました。
そのプログラミングの詳細はnote書きますから物好きは読んでください！ pic.twitter.com/QowJZq6kJO
本垢が凍結するトラブルが起きたのですが、まぁそれは別にいいかなって感じ
またアカウント作成して始めて行く予定です。
さて、今年は本当に「Pythonでイベランをサポートする」を軸に周年を頑張りました。
振り返ると5周年から
5周年：自分が頑張って
6周年：サポート頑張った
7周年：サポート頑張った
という感じになりました。
このBotなどを作成する経緯は、6周年終わりから、「もう少し自分が楽できるようなシステム的なものを作っていきたい」と思いつつ、手を出したのがDiscord.pyでした。
要するにDiscordで稼働するBotを動かすためのシステムですよね。
以前、私の知人たちがBotを作成したのですが、今では海に行ってしまった人もいるし、開発停止した人もいるしということで基本ChatGPTに頼って色々作成していました。それは過去のnoteを見ていただければよく分かるかと思います。
最近はこればっかり書いてるので。。。
とりあえず事前の話からしつつ、本編へ。。。
基本的にこのnoteは作成したコマンド（システム）の話が主で私の稼働とかイベランのやり方は1秒も出てこないので悪しからず。
イベランの情報を知りたいなら他の人のnoteを参考にどうぞ。すごい有益情報出てくると思います。
事前準備など
当初は当時くれせんとむ～んで稼働していたBot「藤島慈」に周年の機能を足し込んでいこうかなと思ったのですが、すでに藤島慈には多くの機能が実装されていたので、来年以降の利用とかを考慮して、切り分けることにしました。結果としてこの判断は今振り返ると正しいなと思いました。
作成したBotの名前がこれ
これまでくれせんとむ～んでは声優の名前のBotを入れていたので流れでこのまま入れるか～って思ったので適当に名前考えて入れました。
その場のノリだけなんですよね。真剣にここは考えていません。識別につけているだけで、本当に大したこと考えずに入れています。
もちろん他鯖に転用とか今後考えていますが、そのときは名前変えたりも全然する予定です。
ちなみに、シャニマスの櫻木真乃役などでおなじみの関根瞳さんですが、
先日私の念願でもあったXを開設されていたり、シャニアニを見ていてアツかったので、この名前にしました。
XのIDは@s_hitomi_ です。ぜひフォローお願いします。
さて、周年より前で色々コマンドを作成して、だいたいできた機能が以下の通りです。振り返ると周年期間で作成したコマンドの量が普通に多いです。
周年前の実装コマンド
稼働調査
シアターイベントでは必須級と言っていい30分速度などのポイント変化量から相手がどんな稼働を取っているかを調べるものですよね。
最近はシアター系統が180消化に対して634になったのに対し、周年は537据え置きになったので、分けて作成が必要ですが、通常イベント用のものはあったし、数値を変えるだけだったので簡単でした。
後PU楽曲用の値を入れたら完成です。あんまり場合分けをしていないので、変な稼働は計算はできない感じにはなっています。
てか、この表示、今見るとわかりにくいな、せめて引数くらい表示しろよな。（今更の反省）
→今後改善します。
必要ジュエル計算
これも王道ですね。目標ポイントに対してジュエル数を計算するコマンドです。これも前述の通り、634pt吐きの想定で作成したのですが、これも537ptだったので初日に修正しました。
実際、ブーストとかもあるので、ここで出力される以上に石は使わない気がしますが、参考としてこういうのは作っておきたかったので、作りました。
過去のボーダーとの比較
これも基本は過去に通常イベントの比較で雛形があったので、簡単に作成できました。
要するに現在の形式（リフレ8時間 最終日リフレなし)になった4周年以降の同時刻帯の他の同順位のポイントを抽出して比較するというコマンドです。
後述しますが、今回はボーダー予想作成しましたが、やっぱりこの比較もあると、狙っているボーダーがどこに帰着するのかを想像しやすいですから、こんなんなんぼあってもいいですからね～のミルクボーイの精神で周年のものも作成しました。
ちなみに、普通に把握していなかったのですが、通常100位と通常2500位の方は誤動作するかなと思っていたのですが、普段稼働しているWebhookが普通に周年の比較も出していました。ちょっとびっくり
現在のアイドル別ボーダーを並び替えて一覧表示
シンプルですが、現在の全アイドルのボーダー情報を取得してそれを並び替えるだけです。
ただ、後述しますが、最終日にmatsurihi.meさんがデータを5分おきの取得になってからはこのコマンドが正常に動かなくなってしまいました。
これは、私の作成したコードの構造上の問題で、原因はわかっているんですが、そのログが5分おきの取得になって生じた他のトラブルを先に修正する必要があったりして、ここまで手が回りませんでした。なので、現在進行系で現在も言う事を聞いてくれません。
まぁ、ただアイドル別に並び替えるだけで、特に何に活かせるとかではなくて話のネタ程度で「今年このアイドル高いね～」とかするためのものです。
実はそんなコマンドが結構存在します。やっぱり周年で話のネタはボーダーの話が結構占めるので、そのネタを提供しただけです。
ちなみに引数指定で、10,100位までは比較できます。1000位はボーダーが長いあいだ出ないアイドルがいるので、見送りにしました。まぁスキップとか数行書いたらいいんでしょうけど、面倒だからやめた♡
来年は実装するようにします。
ハイスコア予想
これは普段のイベントでも実装していますから、特段そこから変えず実装しました。
問題点としては周年だとサンプルとできるものが極めて少ないということです。
サンプルを5としているのは、2,3,5,6,Crossingのイベントをサンプルとして採用しているのです。
普段のイベントですと普通に10は超えて、かなり信頼性のあるデータで予想が立てられています。
なぜ4周年を採用していないかと言うと、周年途中でSHSが実装され、スコアタ環境に劇的な変化がイベント中に訪れたからです。これは100,2000位でも看過することはできないと判断し、計算のサンプルから除外しています。
ボーダー予想のシステムとしては、同時刻帯のスコアタと最終ポイントの差分を考慮し、現時点のポイントが最終ボーダーの何％の値なのかを出力し、その％が最も小さい値、最も大きい値、平均、中央値を割り出して、現在のボーダー値に％を割り算して計算している感じです。
なぜこうしているかと言うと、ミリシタのハイスコアは結局カードの性能やスキルなどの変遷により年々上昇しているため、単純にスコアで予測を立てるのが困難になっています。
そこで利用したのが「最終ボーダーの何割か」という情報です。
もちろんアクティブの数の変遷もありますが、この値は年によって比較的大きな変化がない数値です。
さらに通常の100傑ボーダーなどが釣り上がると自然とこの何割かという値も同時刻帯で小さくなります（小さくなるということはそこから急伸して最終ボーダーは高くなる）なので、この値を採用して予想を立てています。通常イベントだとかなり高精度な予想が現状取れています。
さて、これを見てわかるように画像は4日目のデータですが、周年のサンプル数が少なくてもある程度最終ボーダーが見えるようになっています。やっぱり感覚的なものですとボーダーの予想がわからないので、こうやって出してくれると狙いのポイントも定めやすいというものです。
ちなみに画像は別途"種田梨沙"で出していたWebhookの出力結果で、関根瞳からも任意のタイミングで出力することができますが基本はこちらを見てすぐ最新の情報が確認できるようにしておりました。
（システムじゃないけど）ログ取得に関して
ボーダー一覧表示に際してAPIの取得とかを毎回52回やってたら良くない（てかコマンド実行から表示まで1分とかかかるシステム作りたくない）と思ったので、matsurihi.meさんのAPI更新のたびにログを取得できるようにWebhookを回しておりました。
これも名前は別にイイんですけど、常に最新の情報が取得できるようにログ取得をして、ボーダーの一覧表示はそのログを閲覧することでAPIの取得回数を減らし、コマンド実行から出力までを短縮するのが目論見でした。
ただ、結果としてこれで最終日にログの出力期間が短くなったことで、一部コマンドが動作しなくなるトラブルを発生してしまったので、ここは改善です。
詳細は記載しませんが、今振り返るとかなり危険な処理を毎回実施していて、「いや、楽に処理するならそうじゃなくてこうやって処理すべきでしょ」っていう原因がすでに把握しているので忘れないうちに改善して来年の周年はスッとログを回収できるようにしたいですね。少し修正には時間がかかりそうですが、原因は把握できているので、直したいです。
イベント終了後に冷静になってまだまだ高速でログを回収する方法を見つけたので、それを入れていきたいです。通常イベントでは大量のログを回収することはまずないので、実装はする予定ありません。
以上、ここまで実装してイベントが始まりました。
サポートについて
話はそれますが、サポート使用している人にいつも投げている周年サポートで利用している稼働を書いてもらうEXCELファイルも更新しました。
ただ、結局後述する貯め吐きの稼働確認が極めて優秀で、基本的に「この人はこの時間は動けない」という整理でしか今年は使いませんでした。
まぁこういう稼働表は周年稼働においてまず作成するものなので、周年考えている人は作成しましょう。
通常イベントでも高い順位を狙うならあるとポイントが可視化できていいですよ。
理想はマクロとか利用して色々やりたかったのですが、ここに手はまわりませんでした。多分今後も実装予定はありません。
イベント開始
先にちょっと自分のイベント稼働について
基本的に今年はやる気がなかったので、やる気が完全に切れるまでやるって方針でした。MAXが担当100傑でしたが、そこは無事達成できました。
初日は普通に休日なので可能な範囲で貯める。んで、スコアタ頑張るって方針でした。んで、数日でいい感じのスコアが出たので、後はそれに甘えつつポイントを伸ばしたという感じです。
仕事とかも普通に行きました。１日だけ秋葉原に行く予定の有休を取ったのですが、強烈に暑い１日を取ってしまったので、家でトリガー貯めつつコード書いてました。（結局秋葉原は周年終了翌日に行きました）
そんなこんなで自分としてはTPMと美也100傑を継続できたので満足です。
正直後半戦はモチベが全く持っていけなくてしんどかったのが感想です。
以下はイベント開始後に作成したコマンドのほぼ一覧です。（一部都合で書いていません）
ボーダー予想
これは今回の目玉の予定でした。（ただ満足いく結果にはなっていない）
周年イベントは各順位に対して52個の分布があるので、これは比較的大きい分布だなぁと思いつつ、これを利用することでアイドル別ボーダーは予想が効くんじゃないかと思っていました。
んで、色々考えた結果、以下の画像にある手法でボーダー予想にすることとしました。
EXCELで7分で作成した画像なので、汚いのは御愛嬌だが、私が伝えたいことは伝わるはずなので。。。
ざっくり言えばこんな感じ。
・現在時刻の調べたいアイドルの順位のボーダー情報を取得する
・それがすでに分布としてある「同時刻での各周年の同順位のボーダー分布(52個)」ものに今のポイントを入れたら偏差値がどうなるかを割り出す。
・さらに、別の分布として「各周年のそのアイドルの最終ボーダーから現在ポイントを引き算した差分ポイントの分布（52個）」を用意して、その分布において、先程計算した偏差値ならどれくらいの値(取得値)が返ってくるかを見る
・結果、（最初に取得した現在のポイント）＋（取得値) = (ボーダー予想のポイント)として各周年に対して予想として出力する。
各周年として参考としたのは現在の形式となった4,5,6周年のものをベースにしました。少し違いがあるかと思いますが、参考になるかなと思いつつ。
これで、10,100位のボーダー予想を出力しましたが、終了した今あらためて振り返ると、10位は全然正確性に欠けるのは事実です。まぁたった10人の争いで、11人強烈に争っていたら激しいボーダーになるけど、それが1人降りて10人になるとボーダーは強烈に落ち込むので、それはそうという感じです。
100位ボーダーになればそういうことは減るので、比較的それらしい予想ができるようになります。
1000位は予想を出さなかったのですが、別にちょいちょいとコードを書き足せばできます。終盤で一応出せるようにしておきました。
んで、だいたいこんな感じで出力していました。
これはそこまでブレていませんが、周年間で強烈にブレることがあります。
特に10傑で顕著で、もちろん前述の通り、10傑は他の要因でブレることもありますが、最大の原因は「各周年間の貯め吐きのムーブの違い」にあるかと思います。要するに同時刻帯で平均してトリガーをどれくらい持っているかの違いなどで、ポイントが大幅にずれます。
100傑ならまだしも10傑は露骨にそれが出ますから、この予想は良くないじゃないかと思ったりします。
基本10傑は基本的にトリガーが共通で0に落ちる折り返し前しか比較としてそこまで有益ではないと思います。まぁ参考程度にという感じですね。
じゃあどうやればより精度の高い予想ができるかと考えるわけですが、
それは思いつかないわけですよ。
前述の通り、10傑ボーダーは10人だけ突き抜ければボーダーはゆるくなるし、11人いれば激戦になる。しかもそのタイミングは全然わからない。
要するに10傑は流動的で真面目に予想をするのは馬鹿野郎しいので、これで来年も予想を出す予定です。
ただ、100傑ボーダーの見積もりをどうするのかは考えないといけないです。
周年間でブレた予想で「どれを強く参考にするのが正しいのか」と思ったりします。それで考えたのが以下のコマンドです。
過去ボーダーの分布の平均値と標準偏差を出力
上記の最初に作成する各周年の同時刻帯のボーダー分布が現在の同時刻帯の52人のアイドルのボーダー分布を比較するだけのコマンドです。
比較対象は分布の平均値と標準偏差です。
これを利用して、7周年の現在のボーダー分布が他の周年と比較してどうかを割り出すことで、「この周年ボーダー予想を参考にしたらええんや！」みたいなのを考察するだけのコマンドです
これを見て、分布の似てる具合を見る感じです。
例えばこれなら、難しいところですが、5周年の平均値がかなり近いので、5周年のボーダーを現在は参考にするといいかも・・・？とか思ったりするわけです。
ただ、最終盤はログの出力がうまくいかず、なかなか思うように動かなかったコマンドの一つです。まぁログを改善すれば絶対うまくいくコマンドなので、ここはいいかなと。
以上ボーダー予想についてはこんな処理にしていますが、いまいち釈然としないというか、もう少しよい予想方法があるんじゃないかと思ったりしてたま～に頭をぐるぐるしています。
なんか良さそうな方法があったら教えて下さい。
貯め吐きの稼働提案
この機能は間違いなく周年の総合10傑に大きな影響を及ぼしたのは間違いないと思っています。
周年イベントはトリガーを貯める「貯め」とトリガーを吐き出す「吐き」に完全に行動が分かれるのですが、これをどれくらいの時間を稼働したらいいのかって感覚だと正直わからないころがあるので、それを計算してくれるツールです。
貯め吐きを繰り返す行為は悪手なので、それを回避するためのコマンドです。
要するに現在の情報から今後何時間に対しての最適稼働を出力してくれる感じです。
経緯は色々あるのですが、現在の最終形はこんな感じになります。
色々書かないと行けないのですが、
まず、コマンド実行時に以下の引数（入力する値）が必要です。
・残り時間:残り何時間に対しての計算をするか(秒単位で入力OK)
・貯め時速:1時間に貯められる回数(小数も入れられます）
・吐き時速:1時間に吐ける回数(小数も入れられます）
・所持トリガー:現在の所持トリガー数を入れる
・スキップチケット実行枚数：この残り時間のうち、スキップチケットを何枚使うか
・10倍吐き実行回数：この残り時間のうち、10倍吐きを何回実行するか
・スタダ実行回数：この残り時間のうち、スタダを何度実行するか
・ログイン回数：この残り時間のうち、ログインを何回するか
極めて多いですが、イベランをしていたら当たり前の数値ばかりでそこまで難しくありません。ただイベランを実際している人にこれを実行するのは大変なので、基本はサポートして貰う人が実行していました。
まぁ、途中に実装したコマンドなので、これをイベランしている人に説明するのは難しかったのが正直な感想です。以下簡単な処理の流れです
まず入力されたログボとスタダ分のトリガーを足し算して、スタダ分の時間を引き算します。
その後にトリガーが負になってもいいので、先にライブスキップと10倍消化を回数分実行します。もちろん回数分の時間を引き算します。
ちなみにライブスキップの時間はデフォルト値25秒としていますが、その値も変えることができます。
そして残り時間に対して、最適な貯め吐きの回数を出力するようにします。
まぁ要するにトリガー0に近くなるような貯め吐きの値を出すだけですよね。簡単なことです。
そして計算後のトリガーと残り時間を表示して、残り時間に対してどうムーブするのかを継続検討する材料になるかと思います。
例えば出力例だとトリガー1540個で残り時間1分20秒あるなら、もう一回吐けるよねって話です。
なお、スタダに関しては私が勝手に命名したものですが、某イベランサポーターさんから教えてもらった魔法のムーブです。要するに全吐き日でもリフレ時間にライブチケットを900枚持って2回だけ貯めを行うムーブを指しています。流石に思いつきませんでした。すごいなぁ。。。
最終盤の貯め吐きの稼働提案（未完成）
これは未完成に終わりました。
昨年の周年最終盤、とある総合10傑Pをサポートしていて、
トリガーが尽きた時、そこからどういうムーブをすれば一番ポイントを稼げるのかを検討したことがあります。
その時はツテはなくて手計算で最適計算をしたのですが、当然思うことは一つ
Pythonに全投げしたい！ということです。
結論から言うと、使用することはほぼなく（1回だけ参考で使用した）
そもそも完全形にすることができなかったという感じです。
一応出力例を出します。
実は他のPythonコードも2パターンくらい考えたのですが、全然満足する出力をしてくれなくてう～んと思いました。
まずそもそも、この計算ではお仕事10回の時間を引数にして、貯めのとき、10回のお仕事時間を10で割り算して1回の時間を出して、5回分足し算して、貯め時間を足し算して一回の貯め時間として計算しています。
ただ、冷静に考えて今のシステムで5回だけ仕事して貯めしないでしょって思ったりして、「いやこれ正しくないでしょ」とか自問自答してたらこのコマンドに信頼を置くことはできなくなりました。
逆に前述の貯め吐き稼働のコマンドは実際にこれで動いて完璧だった例を見たので、安心していました。
なので、1分1秒を争うときにこれでええんかって思って、あまり参考にしないでね～とか作っておいて言ってました。
結論、総合最上位勢はキレイにトリガーを0近傍にして、貯め吐きをしなかったので、このコマンドは使われることなく周年が終わりました。
でも来年使用の需要があるかもなので、なんとかしたいと思っています。
あまり詳細を記述しませんが、基本この最終盤の稼働に関しては残り時間とトリガーの2つの縛り付けのある多次元ナップサック問題に帰着できると思っていますが、それをPythonでどう実現するかを考えないといけないと思っています。
ナップサック問題に関しては各自調べてください。要するにナップサックに詰め込めるフルーツの最適解を求めるものです。
要するにクソ難しいです。来年までにできたらいいなぁと思っています。
実際使用は13日で最後の1日だけなので、そこまで詰める必要もないのかなと思っています。
逃げ切りラインの出力
これは残り2日でシャワーを浴びていて思いついたやつです。
要するに、現時点から理想ムーブで吐き+持っているスキップチケットや10倍をすべて使われたとして、何ポイントまでボーダーが伸びるかを出すのがこの逃げ切りラインの目的です。
加えて、全アイドルの11位、および101位のボーダーポイントを取得し、それに上記の値を足し算した値も出すようにしています。
11位、101位ってのが大事。当たり前だけど。
時間がなかったので、関根瞳のコマンド実行では実装せず（来年までに実装します）新しくWebhookとして「峯田茉優」を作成して、そこで逐一出力させるようにしました。
ただ、前述のログの回収のところにより、ここも完全に満足のできる動作を取れなかったのは事実で、ここは改善、、、まぁ再三ですが、ログの回収を最適化したら改善できるところです。
一応出力例は以下の通り
まぁ人間は安心したい生き物なので、これを使って理想ムーブされても逃げ切れるぞわっほーい！って思うだけのコマンドです。でも必要だと思う。
激アツな争いの出力
これは、ユーザの求める声に応えただけのコマンドです。
まぁユーザって私なんですけどね。
要するに最終日でボーダー争いが激しそうなアイドルの情報を出すだけのニュース的な役割をするWebhookです。
こちらも峯田茉優さんにお願いしています。関根瞳さんへの実装はしませんでした。多分これに関しては来年もWebhookだけで出力になるかと思います。
出力例は以下の通り。
これを見て「うおおおおおこのアイドルボーダー激アツ！」みたいに盛り上がる
要するに話のネタだけという感じです。
でも正直最終盤すっごい疲れててあんまりこれ見てる元気なかったので、作ったことはいいんだけど活用できたかは謎です。
後、ログの取得がトラブル起きてるせいでこいつもバラバラの更新になったのが良くなかったですね。
来年はちゃんと動かせるようにしたいです。
総合10傑の動向確認
このコマンドは本当に最後の最後に作成して、
多分作ったんはイベント終了2時間くらい前だったと思います。
まぁ要するに総合10傑の動向を探るためだけのコマンドですよね。
なんでこれが必要かといえば、周年は通常の総合ランキングはmatsurihi.meさんが30分おきにログを表示しているのですが、アイドル別になると最終日は5分おきの取得になるので、それを利用すれば本当に最後の最後の1時間とかはそっち見ることでかなりリアルタイム性の高いログ取得ができるというわけです。
なので、最終盤で上位にいる人を調べ、その人がやっているアイドルを確認し、そのアイドルの1位情報を取得して、ただ並び替えただけの簡単コマンドです。
前述の昨年サポートの際に、この取得を手動でやっていて面倒くさかったので、これは最低限Pythonに依頼できるでしょと思い作成しました。
要するにいつトリガーが尽きたかなどを調べるためにこのコマンドを作成した感じです。
出力例は以下の通り
成形とかは全然していなくて、むしろExcelとかに転記しやすいようにコロンで区切っています。
改善としては、2,148ptの倍数じゃない値が差分として出たら文言を出力できたらすごい便利だなと思いました。流石に周年最終盤は他のものもあって全然それができませんでした。（一部使えないコマンドとかが出てきたりログの出力のトラブルとかがあって、ラズパイが爆発しかけたため）
冷静に考えると、これ複数アイドルでやっている人がいたら、全く使い物にならないなと思ったのですが、過去にそんな人はいなかったので、現状は来年も同様の手法で最終日使っていこうかなと思っています。
てか、それをされるともうこのコマンドは言う事聞きません。
（実際複数アイドルやりつつ総合10傑とか取った人っているのかな？)
歌唱アイドル抽選
自分が使いたいだけのものです。周年楽曲でスコアタをするときにイベント楽曲の歌唱アイドルを考えるのが面倒だったので、決めてもらうということで作りました
さすがのChatGPT頼みの俺でもこれは5分でコード書けました。
シンプルだけどこういう機能が僕は好きだったりします。
周年後に作成したコマンドとしては以上です。
いや、本当に多すぎるだろぉ
これを作成しながら普通に宮尾美也100位やってるのキモいなあと思いました。
一時的に作成してすぐさようならしたやつ
Webhook"田所あずさ"を作成しました。
そういえばまだあったわ
勢いでチャンネルごと消し去ってやったので、もうログがないのですが
この周年期間でラウンジのミリオンマスター！さんのファン数が符号付きintの上限値となる2,147,483,647人に到達しそうという話を聞いて急遽監視ができるBotを作成しました。
それが田所あずささんでした。というだけ。
そして無事に到達して、ミリシタ的にも何もなかったので、ファン数はintじゃなかったという事実だけがわかりました（到達おめでとうございます！）
なんか動いていたやつ
関根瞳は基本周年用のコマンドだけ用意しているもので、通常イベントは「藤島慈」というBotに色々をやってもらっています。
その中で、動くと思ってなかったけど動いたコマンドにグラフの出力コマンドがあります。
グラフ出力コマンド
このグラフの出力コマンドは全然周年用に最適化をしていなかったので、どうせ動かんやろとおもっていたのですが、動いて勝手にびっくりしていました。
以下出力例です。
まぁ実際そこまで利用したかと言えば使っていないので、これは通常イベントで暴れるものなので、「まぁ動いたね」程度のものです。
ちなみに現在時刻に寄ったものもちゃんと出ました。
そういえばこのグラフのコマンドもマジで汚い作りで、辞書配列とかを使えばもっとスマートに出力できるものなので、改善したいな～と思いつつ、今動いてるからいいか～とか思いつつ今日がまた終わってゆく。
ラウンジ1位比較コマンド
これも動いていた
特に実行してなんだってわけではありませんが、気になったんで
戦績
メインサポートした方たち
某アイドル 3位
某アイドル 4位 総合TPR
途中からかなりサポートした人
某アイドル 2位 総合TPR
間接的にサポートした人（感謝の意をもらったので勝手にそう解釈している）
某アイドル 1位 総合10傑 2名
（その他にも自分としては何もしていないけど、サポートしていると思う人がいるはず。多分）
衝撃的なのはいつの間にか総合10傑レベルの方を間接的にサポートしていたことです。
詳細に関しては当事者からブログ的なものが出るはずなのでそちらを御覧ください。
2024/7/19更新 出た
私が書かせたみたいです。ご迷惑をおかけしました。
完走した感想
しんどい！
もしかしたら自分がイベランした5周年より大変な周年だったかもしれません
もちろん、普通に当初予定でサポートする人をサポートしていたらここまで大変になることはなかったと思いますが、
「これもやりたい」「あれもやりたい」と増やしていったらとんでもないことになって、勝手に自分で忙しくしたというのが事実です。
ただ、それだけに完璧とは言わずともかなりいい基盤ができたので、それをブラッシュアップして、来年以降にも活かしていきたと思います。
要するに：いい周年でした。自分のスキルアップもできたので。
（普段の業務でPythonを使用することはありません）
今後について
まだ全然何も考えていませんが、Botに関しては今回作成したシステムのうち、通常イベントでも作成できそうなものは流用したいし、加えて現状だとラズパイを負荷で壊しかねない危険なコードがあるので、そこは修正したいと思います。
ただ、通常イベントでの運用では危険なコマンドは基本ないので、周年の構築はのんびりやりたいとか言ってたら「やべもう来週には周年かよ！」みたいになりそうなので、計画的にやりたいと思います。
後は、他にも野望があるので、そこはやっていきたいですね。
次のサポート予定（Botのサポートを含めて）
くれせんとむ～んは参加人数は比較的いるのですが、クローズなサーバなので、ホイホイとサポートだからと人を増やさないようにしています。
んで、今後９月上旬に開催が見込まれているコミック連動イベント「わたしは花、あなたは太陽」にて以下のラウンジでサポートおよびβ版のBotを稼働予定です。裏コマンドも稼働予定。だと思います。
ご興味のある方はラウンジマスター(以下のポスト主)か私にご連絡ください。可能な範囲でサポートいたします。
@no_TL
— のある (@noarup) July 1, 2024
9月上旬の開催が濃厚な「わたしは花、あなたは太陽」に向けて、当方の百合子ラウンジで一緒に走ってくださる方を募集しております。
目標は「色段」、ノルマは「50万」です。※目標が高い方優先
このイベは頑張りたいって方がおりましたら、ぜひよろしくお願いします！
#ミリシタラウンジ募集 pic.twitter.com/KaN33RyDuw
とは書きつつも通常イベントなので、周年で役に立った機能の殆どは使えませんが、シアター形式ではありそうなので、貯め吐き提案とか、逃げ切りラインの情報は出していけるかと思います。
加えて、7周年の今回でBotは全く完成していないので、次の8周年で安定性も高めたより強固なサポートBotとして稼働できるように準備を進める予定です。なので8周年のサポートは決定なので、今回のリベンジや挑戦をしたい方の募集をお待ちしております。
条件はアイドル別10傑を狙う方です。流石にイベント当日からのサポートは無理で基本的に色々事前に作戦を練りたいので、一ヶ月前くらいには連絡ください。
後は普段使いのBot観点だと、監視Bot作りたいな～と思いつつ。要するにDiscordから手元配信してもらって停止していたらサポートの自分や当人にメンションが飛ぶシステムを想定しています。
実は、雛形はできていて、リフリレのときにお試し稼働はしたので、今後限界ランをする！って人がいたら構築考えておこうかな～という感じです。それ以外に現状思いついて作成しようと思っているシステムはありません。
一応言っておく話
アイドルの並び順は結局当初言われていた並びになりましたが、やっぱりとてもきれいな並びとは言えないし、
ミリアニを重視したいのはよくわかりますが、そもそもあのコルクボードってのは左上から左から右に進むことで、スカウトした順番とかの価値が現れるものですから、それを縦でいくってのは正直ミリアニの意図を崩すものなのでいいのかってのは正直ありますね。
また、運営も最低限「初日に楽曲の長さが短い曲を入れたい」という意図は近年とても感じますが、流石に今年の最短曲の二大巨頭とも言える「ゲキテキ！ムテキ！恋したい！」と「銀のテーブル木苺ジャム」を同じ日に実装するのはうーんって感想が正直なところです。
来年からの予想で色々みるのめんどくさ。。。
最後に
これだけPythonで色々できるのはミリシタのデータAPIを提供いただけるmatsurihi.meさんがいるからです。誠にありがとうございます。今後ともよろしくお願いします。
またDiscord上でボーダーBotを提供いただいてるちゃんせーさんにも併せて感謝申し上げます。周年数週間前に突然DMをお送りして周年Botをどうされるかを聞いたところすぐ返信を頂き、本当に嬉しかったです。ありがとうございました。
そしてこのBotを利用していただき、私がサポートしていただいた方は途中でリタイアされることなく皆さん目標の順位、むしろそれ以上の結果を獲得してもらったことはなんか予備校講師の先生みたいに嬉しいです。（予備校講師の先生やったことないけど）
そして、普段からこんな私をサポートいただいているDiscordサーバくれせんとむ～んのみなさまに感謝申し上げます。
謝辞ってのはいいもんですよね。
では、また来年も。
今年はなんかのスポーツの結果書こうかなと思ったのですが、時系列でnoteを書かなかったので、なしです。スポーツは多種多様でずーーーーっと見てました。
この記事が気に入ったらサポートをしてみませんか？