[{"data":1,"prerenderedAt":70},["ShallowReactive",2],{"article-ps7odth1qy":3,"prev-article-ps7odth1qy":21,"next-article-ps7odth1qy":45},{"contents":4,"totalCount":19,"offset":20,"limit":19},[5],{"id":6,"createdAt":7,"updatedAt":8,"publishedAt":8,"revisedAt":8,"title":9,"content":10,"tags":11,"is_no_index":18},"ps7odth1qy","2025-12-26T19:49:40.314Z","2025-12-26T19:55:11.972Z","傲慢なありのまま","\u003Cp>もう、うんざりです。普段は「バカな発言だな〜」と思ってもスルーしていますが、最近あまりにも目に余るのでお気持ちが溢れています。\u003C/p>\u003Cp>SNSを開けば「男女の友情はありなし？」みたいな低レベルな議論。あるいは「私、女の子大好きなんで！」みたいな、聞いてもいない性的アピール。\u003C/p>\u003Cp>こういう人、皆さんの周りにもいませんでしたか？いますよね。少なくとも私の周りには結構いました。\u003C/p>\u003Cp>よく言えば恋愛体質な子が友達に多かったので、こういう性愛中心の話題を聞かされることは多々ありました。\u003Cbr>正直、こういう話題自体が大嫌いなのですが、友達である以上、適当に相槌を打ってスルーしていました。でも最近、ネット上でもこの手の言説があまりにも目につきすぎて、さすがに許容範囲を超えました。てかシンプルに、非常に、気持ち悪いです。いい歳をして、恥ずかしくないんでしょうか。\u003C/p>\u003Cp>これは考察でもなんでもありません。私の視界に入ってくる社会性のない振る舞いに対する、ただの不満であり、ただのお気持ち表明です。\u003C/p>\u003Ch1 id=\"h9bab4633d8\">理性を否定する議論の無意味さ\u003C/h1>\u003Cp>まず、定期的に繰り返される「男女の友情は成立するか」という問いについて。いい歳をした大人たちがこの議論に熱を上げているのを見ると、人間の精神的成熟とは一体何なのかと疑いたくなります。\u003C/p>\u003Cp>この議論の前提には、男女が接触すれば、必ず(特に男性側が)性的な感情を持つはずだという、極めて動物的な決定論があります。しかし、もしそれが真理だとしたら、私たちの社会活動はすべて破綻します。\u003C/p>\u003Cp>職場であれ学校であれ、まともな理性・感性を持ち合わせた人間であれば、相手を無条件に性的なオブジェクトとして消費したりしません。相手を一人の人間として認識するよりも先に、オスとメスという生物学的な区分でしか関係性を定義できない。それは、自らの理性の欠如を告白しているに等しい行為です。\u003C/p>\u003Cp>そのような未熟な前提を大人の恋愛論のように語ることは、人間の知性に対する冒涜ではないでしょうか。\u003C/p>\u003Ch1 id=\"h526521e741\">無害な性と有害な性のダブスタ\u003C/h1>\u003Cp>次に、昨今の多様性の文脈でよく目にする、「私、女の子大好きなんです♡」といった、公共の場での性的指向の開示について。ここで私が違和感を覚えるのは、発言の内容そのものではなく、それを許容する社会の判定基準の曖昧さと残酷さです。\u003C/p>\u003Cp>想像してみてください。生え際が寂しく後退し、肌はクレーターのように荒れ、脂性肌でテカテカと光っている。近づけばツンとしたアンモニア臭が漂うのに、本人はその悪臭を微塵も自覚せず、自分のことをごく普通のフツメンだと信じて疑わない中年男性。\u003C/p>\u003Cp>もし彼が、公の場で「俺は若い女の子が大好きだ！」と大声で宣言したらどうなるでしょうか。即座に悲鳴と共に拒絶され、「セクハラだ」「通報しろ」と社会的に抹殺されるはずです。それは聞きたくもない他者の生々しい性欲に対する、至極真っ当な防衛反応です。\u003C/p>\u003Cp>しかし、なぜか女性やマイノリティが同じ質量の性的欲求を口にしても、個性や自己表現として受容されてしまう。ここには、社会全体が内面化しているうっすらとした男性嫌悪、所謂ミサンドリーのようなバイアスが存在しているように思えてなりません。\u003C/p>\u003Ch1 id=\"h3dc52a32a0\">優劣と差別\u003C/h1>\u003Cp>私たちは無意識のうちに、性欲に審美的な優劣をつけている。だから、清潔感のある女性が性的な話をしてもどうせ実害はないと高を括り、逆に小汚いおじさんが口を開けば実害があると判定して過剰に警戒する。\u003C/p>\u003Cp>つまり、社会は無意識に男性の性欲＝制御不能な猛獣、女性の性欲＝去勢された愛玩動物という格付けを行っているのです。一見、女性の発言が許容され優遇されているように見えますが、これは裏を返せば女性には他者を脅かすほどの主体性も、性的なエネルギーもないと高を括られているに過ぎません。女性の性欲は綺麗で尊い(だから公言してもいい)という幻想は、女性を人間として対等に見ていないからこそ成立する、非常にグロテスクな保護と言って差し支えないでしょう。\u003C/p>\u003Cp>この構造は、男性をその容姿や属性で不当に貶めていると同時に、女性を加害性含む性的な主体性を持たない、無力で愛玩的な存在とみなす、逆説的な差別でもあります。この歪さに無自覚なまま、多様性という言葉でコーティングされた性的発言が飛び交う現状は、健全な状態とは言えないはずです。\u003C/p>\u003Ch1 id=\"h66131ec73a\">ありのままの傲慢\u003C/h1>\u003Cp>誤解を恐れずに言えば、私はその人の性的指向や性自認といったパラメータが何であれ、最低限のTPOすらも守れない知性の足りない人間に強い拒否感を覚えます。\u003C/p>\u003Cp>ありのままの自分を肯定することは、他者の領域に土足で踏み込んでいい理由にはなりません。なぜ彼ら彼女らの振る舞いがこれほど不快なのか。それは、社会生活を営む上で支払うべき配慮というコストを周囲に押し付けているからです。\u003C/p>\u003Cp>私たちは皆、本能や自我を理性でフィルタリングし、摩擦が起きないよう調整して生きています。その労力を放棄し、生の欲望を垂れ流しておきながら、「それを受け入れない社会が悪い」と被害者ぶって居直る。それは自由への渇望などではなく、単なる甘えと怠慢に過ぎません。多様性という言葉を免罪符にして、理性を放棄した人間を私は評価しません。\u003C/p>\u003Ch1 id=\"h692d7b7c17\">個としての作法\u003C/h1>\u003Cp>結局のところ、私たちが目指すべき多様性のある社会とは、互いの属性を大声で発表し合い、褒め称え合う社会などではありません。むしろ逆です。隣に誰がいようと、何が好きだろうと、互いに干渉せず、気にも留めない冷ややかな無関心が徹底された社会こそが、最も生きやすい場所なのではないでしょうか。\u003C/p>\u003Cp>そうでなければ、多様性なんてモノはとっくに破綻しています。\u003C/p>\u003Cp>考えてもみてください。あのおじさんの性欲は気持ち悪いから排除するけれど、私のそれは尊い個性だから受け入れろなんて理屈が通るわけないんですよ。当人を当人として消化できない時点で破綻しているのに、その致命的な欠陥を見て見ぬふりして、ありのままだの理解だの、耳触りのいい綺麗事ばかりを並べ表面だけを繕うのはやめてくれませんか。\u003C/p>\u003Cp>文明とは、ある意味で人間が自らの性欲や排泄欲、暴力性といった獣性を、うまいこと隠すことによって成立させたシステムです。それを解放することが多様性だと本気で思っているなら、どうぞそのアンモニア臭のするおじさんの性欲も、同じ笑顔で抱きしめてあげてください。\u003C/p>\u003Cp>それができないなら、自分の性欲だけを多様性の箱に入れてラッピングして差し出してくるのは、随分と都合のいい傲慢な仕様だと思いますよ。\u003C/p>\u003Cp>\u003C/p>",[12],{"id":13,"createdAt":14,"updatedAt":15,"publishedAt":14,"revisedAt":15,"slug":16,"name":17},"wia4slp55q","2025-04-28T07:14:14.541Z","2025-12-03T16:08:13.798Z","thoughts","独り言",false,1,0,{"contents":22,"totalCount":44,"offset":20,"limit":19},[23],{"id":24,"createdAt":25,"updatedAt":26,"publishedAt":26,"revisedAt":26,"title":27,"content":28,"tags":29,"is_no_index":18,"summary":43},"hqg_zi74u","2025-12-19T14:04:54.748Z","2025-12-24T10:28:24.896Z","Misskeyインスタンスの持続可能性","\u003Ch1 id=\"h8d027c8ed3\">はじめに\u003C/h1>\u003Cp>この記事は\u003Ca href=\"https://adventar.org/calendars/11291\" target=\"_blank\" rel=\"noopener noreferrer\">Misskey Advent Calendar 2025\u003C/a>、24日目の記事です。\u003C/p>\u003Cp>\u003Ca href=\"https://adventar.org/calendars/11291\" target=\"_blank\" rel=\"noopener noreferrer\">https://adventar.org/calendars/11291\u003C/a>\u003C/p>\u003Cp>私のテーマはMisskeyインスタンスの持続可能性。\u003C/p>\u003Cp>このテーマを選んだきっかけは、先日流れてきたある中規模Misskeyインスタンスの閉鎖告知でした。サーバー運営の話になると、決まってサーバー代という金銭的コストが注目されます。もちろん学生の身には痛い出費ですし、それが理由で閉じるケースも往々にしてあるでしょう。\u003C/p>\u003Cp>ただ、ある程度の収入がある人であれば、月数万円程度の維持費は趣味として許容できるように思えます。それなのに、なぜ多くのサーバーが終わりを選ぶのか。\u003C/p>\u003Cp>根本的な原因は、金銭ではなく、コミュニティを維持運営することそれそのものにあるのではないかと、個人的には感じています。\u003C/p>\u003Ch1 id=\"h921254d548\">歴史は繰り返す\u003C/h1>\u003Cp>少し昔話をしましょう。\u003C/p>\u003Cp>2016年頃に、Mastodonという黒船が到来しました。\u003Cbr>ビッグテックに依存しない、セルフホスト可能なSNSという触れ込みに、当時は色めき立ったのを覚えています。誰でもインスタンスを建てられ、それらが緩やかに繋がるFediverseの世界。そこには確かに、自由なユートピアの幻影が見えていました。\u003C/p>\u003Cp>実はわたしもその熱狂に当てられた一人でした。当時、Twitterで見かけた\u003Ca href=\"https://knowledge.sakura.ad.jp/8752/\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">さくらのナレッジの記事\u003C/a>に感化され、ターミナルと格闘しながらサーバーを建てた記憶があります。\u003C/p>\u003Cp>とはいえ、その熱狂が永遠に続いたかというと、そういうわけでもありませんでした。自由にサーバーを建てられるといっても、多くのユーザーは結局人が多く、安定している場所を選びました。jpやPawooといった巨大サーバーに数十万人が雪崩れ込む一方で、個人が意気揚々と建てた小規模サーバーは、過疎とインフラ維持の現実に晒されました。\u003Cbr>結局、維持費や管理の手間に見合わなくなった小規模サーバーは次々と閉鎖し、行き場を失ったユーザーは巨大サーバーへ流れるか、あるいは「やっぱTwitterでいいや」と古巣へ帰ってしまいました。運営元の譲渡やサービス終了のニュースが流れるたび、分散型の夢は少しずつ色あせていきました。残念。\u003C/p>\u003Cp>そして現在、Misskeyでも全く同じ歴史が繰り返されています。\u003Cbr>Twitterで話題になるMisskeyは、実態としてMisskey.ioと同義として語られることがほとんどです。独自の絵文字やリアクション機能を楽しむための場所として機能しており、分散型ネットワークというよりは、特定サーバーへの一極集中に近い状態となっています。ActivityPubに対応しようと、UIがリッチになろうと、人間の群れたがる性質が変わらない限り、歴史は何度でも繰り返すようです。\u003C/p>\u003Ch1 id=\"hf24e19d6ed\">ユーザーは理念を気にしない\u003C/h1>\u003Cp>界隈ではよく、「邪悪な巨大資本 vs 民主的な分散型SNS」といった構図が語られますが、実際のところはどうでしょうか。\u003C/p>\u003Cp>Twitterが得体の知れないアルファベットになり果てても、閑古鳥が鳴く事はなく、なんだかんだ言いつつも結局はみんなそこに居座っています。Misskeyに来た人たち限定しても、その大半はMisskey.ioという巨大な中央集権サーバーに群がっているのが現実です。\u003C/p>\u003Cp>界隈では「チャンネル機能が閉鎖的だ」とか、開発者本人の「分散化はおまけ」発言に複雑な思いを抱いたとか、io一強状態に対する議論は尽きません。しかし、これをユーザーの怠慢だとか、特定の運営の責任にするのは建設的ではありません。そもそも、ユーザーにとって重要なのは分散型であることよりも、そこで何を体験できるか であるからです。\u003C/p>\u003Cp>Misskeyは良くも悪くもインスタンスによって使用できる絵文字や機能が異なります。つまり、インスタンスごとにユーザーが体験できるものが均質ではありません。話題のリアクションを使いたければ、それがあるインスタンスに行く必要があります。人が多く、反応が早くて、話題の絵文字がある場所に集まる。それは怠惰ではなく、極めて合理的な選択と言えるでしょう。\u003C/p>\u003Cp>そして、このユーザーは理念だけでは動かないという現実を象徴するニュースが、つい先日ありました。Meta社のThreadsが、AP対応をメンテナンスモードに移行させたという話です。事実上の開発縮小、あるいは一旦距離を置くと言って差し支えないでしょう。\u003C/p>\u003Cp>あれだけ「分散型を信じている」などとザッカーバーグが豪語し、界隈の人たちも盛り上がっていたようですが、蓋を開けてみれば、連合機能を積極的に使っていたユーザーはごく一部に限られていた、と言われています。多くの人にとっては、分散していること自体よりも、使い勝手や周囲の友人がいるかどうかといった要素の方が、はるかに優先度が高かった、ということなのだと思います。所謂UGCの宿命ってやつですね。\u003C/p>\u003Cp>「Fediverseは圧倒的に利用者が少ない」と外から指摘されたとき、今のわたしなら「まあ、そらそうだよね」と答えると思います。\u003Cbr>かつては私自身も、Fediverseが中央集権的な従来のSNSを淘汰するような未来を妄想していた時期がありましたし、ここがもっと多くの人で賑わう未来を信じていました。今では、少なくとも、当面は爆発的に増えることはなさそうだと、少し現実寄りの見方をするようになりました。\u003C/p>\u003Cp>ただ、それが必ずしも悪いことだとは思いません。\u003Cbr>というのも、今ここに居る住民たちも、どこかで適度な規模感を好んでいるように見えるからです。新規ユーザーが増えれば嬉しい一方で、内輪ノリや独特の空気感も保ちたい。結果として、ある種の村社会的な雰囲気が生まれやすいのは、人の集まりとして自然な姿でもあります。\u003C/p>\u003Ch1 id=\"hd37c53201a\">コミュニティ運営の負荷\u003C/h1>\u003Cp>一極集中の是非はさておき、じゃあ小規模サーバーなら安定して運営できるかというと、それも一筋縄ではいきません。\u003C/p>\u003Cp>似たような経験が多くの人にあるのではないしょうか。意気揚々とDiscordサーバーを建てて、最初は身内だけで盛り上がるものの、人が増えるにつれて古参と新参の対立が起き、内輪ノリが疎まれ、空気が淀んでいくあの感じ。\u003C/p>\u003Cp>これは、中小規模のインスタンスでもほとんど同じことが起こり得ます。最初は新しい村を作る高揚感で回るのですが、時間が経つにつれ、方針のすり合わせやユーザー間のトラブル対応など、運営として向き合うべき課題がじわじわ増えてきます。\u003C/p>\u003Cp>重要なのは、これらが運営者の手腕の良し悪しだけで決まるわけではない、という点です。人が集まれば、そこには自然と摩擦が生まれます。ある程度以上の規模になったコミュニティがちょっと疲れる場所になりやすいのは、ある意味で避けがたい側面でもあります。\u003C/p>\u003Cp>そして厄介なことに、管理コストはユーザー数に対して非線形に増加する傾向があります。\u003Cbr>ある日突然ユーザーが急増すれば、通報対応やモデレーション業務で膨大な時間を割くことになります。法務部門もカスタマーサポートも持たない個人が、仕事や学業の片手間で不特定多数のユーザーを管理し続けるのは、リソース的に破綻しやすいことは自明でしょう。\u003C/p>\u003Cp>私自身、中規模といって差し支えない規模のインスタンスを運営していますが、熱意だけで永遠に走り続けるのは現実的には難しいだろうなという感覚を日々覚えています。ユーザーは必ずしも理想通りには動きませんし、運営側もずっと同じテンションでいられるわけではありません。私がそうであるように、そもそも人々は思ったより理知的な振る舞いをしませんし、他人を慮る余裕もありません。\u003C/p>\u003Ch1 id=\"ha84ed78290\">永遠を求めない\u003C/h1>\u003Cp>ここから導き出せる教訓は、個人がコミュニティを維持するのは構造的に困難であるということ、個人運営のサーバーに企業のインフラと同じ永続性を求めるのは間違いであるということです。\u003C/p>\u003Cp>私たちはつい、慣れ親しんだ居場所が永遠に続くことを願ってしまいます。少なくとも私はそうです。\u003C/p>\u003Cp>そこそこの規模になったサーバーを抱えていると、ユーザーがいる手前「閉じてはいけない」「明日も動かし続けなければならない」という奇妙な責任感に縛られていきます。最初は純粋な遊び場として、自分の楽しみのために始めたはずでした。それなのに、いつの間にかインフラとしての信頼性を勝手に背負い込み、楽しさよりも義務感でサーバーを維持してしまう。これは、私の偽らざる本音であり自戒でもあります。\u003C/p>\u003Cp>その結果が、燃え尽きによる突発的な閉鎖や、悲痛な終了告知につながるのだとしたら、あまりに皮肉な話です。\u003C/p>\u003Cp>そもそも、個人がポケットマネーと余暇で維持している場所に、恒久的なインフラとしての役割を期待するのが土台無理な話なのです。管理者が飽きたり疲れたりすれば、その場所は終わります。\u003C/p>\u003Cp>Misskeyインスタンスの持続可能性というテーマに対する私の答えは、サーバーを死なせないことではなく、サーバーはいつか死ぬものであると許容することです。場所がなくなれば、また別の場所へ移ればいい。あるいは新しく焚き火を起こしてもいい。一つの場所にしがみつくのではなく、次へと渡り歩いていける流動性こそが、Fediverseというシステムの本来の強みであり、持続可能性の正体ではないでしょうか。\u003C/p>\u003Ch1 id=\"h9be0c3393d\">おわりに\u003C/h1>\u003Cp>とはいえ、全員が遊牧民になってしまえば、そもそも移動先がなくなってしまいます。Fediverseが成立するためには、誰かがどこかしらでサーバーを維持し続けなければなりません。\u003C/p>\u003Cp>私自身、文句を言いながらもサーバーを畳まずにいるのは、別に崇高な使命感があるわけではなく、単純に技術的な興味や、自分の場を持つ面白さがまだ勝っているからです。要するに、ただの趣味です。\u003C/p>\u003Cp>だからこそ、運営者もユーザーも、「これは公共インフラではなく、個人の趣味の延長線上にあるものだ」という前提にもっと自覚的であるべきでしょう。運営者は義務ではなく趣味の範囲でサーバーを動かせばいいし、ユーザーも場所借りくらいの感覚でいればいい。\u003C/p>\u003Cp>もちろん、これは無責任でいいだとか技術力がなくてもいいという意味ではありません。\u003Ca href=\"https://mq1.dev/entry/krpvl5itbr9h\">かつての記事\u003C/a>でも書きましたが、碌に意味も理解せずコピペで建て、トラブルが起きたら放り出すような運用は、趣味以前の傲慢です。まともに運用できない人間が安易に手を出すべきではない、という前提は今でも変わりません。\u003C/p>\u003Cp>そうではなく、技術的な裏付けを持ち、自分で責任を負える人間が、過度な義務感に縛られずにもっと気楽にやるべきだ、という話です。運営者は公共インフラの維持という義務ではなく、あくまで趣味の範囲でサーバーを動かせばいいし、ユーザーも場所借りくらいの感覚でいればいい。\u003C/p>\u003Cp>明日なくなるかもしれないし、10年続くかもしれない。そのくらいの適当な距離感で付き合っていくのが、精神衛生上もっとも持続可能なあり方なのだと思います。\u003C/p>\u003Cp>まぁ、もしここが焼け野原になったとしても、また別のどこかでお会いしましょう。 Fediverseは無駄に広いですから、避難先には困らないはずです。それでは。\u003C/p>",[30,36,42],{"id":31,"createdAt":32,"updatedAt":33,"publishedAt":32,"revisedAt":33,"slug":34,"name":35},"vmhb23sq4","2025-07-29T12:56:07.884Z","2025-12-03T16:06:19.140Z","misskey","Misskey",{"id":37,"createdAt":38,"updatedAt":39,"publishedAt":38,"revisedAt":39,"slug":40,"name":41},"qfey3yw0z1","2025-04-29T08:44:41.687Z","2025-12-03T16:07:14.622Z","technology","テクノロジー",{"id":13,"createdAt":14,"updatedAt":15,"publishedAt":14,"revisedAt":15,"slug":16,"name":17},"はじめにこの記事はMisskey Advent Calendar 2025、24日目の記事です。https://adventar.org/calendars/11291私のテーマはMisskeyインスタンスの持続可能性。このテーマを選んだきっかけは、先日流れてきたある中規模Misskeyインスタンス",44,{"contents":46,"totalCount":69,"offset":20,"limit":19},[47],{"id":48,"createdAt":49,"updatedAt":50,"publishedAt":50,"revisedAt":50,"title":51,"content":52,"tags":53,"is_no_index":18,"summary":68},"e-3nu72af97k","2025-12-29T18:01:40.332Z","2025-12-30T10:20:45.448Z","非公式Misskeyサーバーリストをつくった","\u003Ch1 id=\"h8d027c8ed3\">はじめに\u003C/h1>\u003Cp>Misskeyのサーバー探しで困ったことはありませんか？公式のリストが止まっていたり、実態のわからないサーバーが混ざっていたり。そんな状況に業を煮やし、最新の状況を自動で反映し続けるサーバーリストを作成しました。\u003C/p>\u003Cp>\u003Ca href=\"https://servers.misskey.ink/\" target=\"_blank\" rel=\"noopener noreferrer\">https://servers.misskey.ink/\u003C/a>\u003C/p>\u003Cp>本当は今年のMisskey Advent Calendarのネタにしようかとも思っていたのですが、どうせ技術的な記事は他の方々がたくさん書かれているだろうし、何より当時のUIはちょっと見せびらかすには残念な出来だったので見送っていました。 そんなわけで、諸々がいい感じに仕上がってきたので、少し遅れての登場です。\u003C/p>\u003Cp>私が (Unofficial) Misskey Server List を作成しようと思い立った直接のきっかけは、Misskey公式のMisskeyHubに掲載されていたインスタンス一覧が、長期メンテナンスに入ったまま復旧しなくなってしまったことでした。 開発者からは「ユーザーの混乱を避けるため」といった趣旨の説明がなされていましたが、その裏にある実情は十中八九、Misskeyの派生プロジェクトであるCherryPickによる実装変更が引き金でしょう。\u003C/p>\u003Cp>現行のCherryPickは、\u003Ca href=\"https://github.com/yunfie-twitter/cherrypick/commit/98ae8b5d869bac470aad2b8f025318f2c222e432#diff-c99e10daaf6c2db57012b73a31a76d7e3bbbf9e2599ed226e2f1651cdff40c20\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">User-AgentにJoinMisskeyの文字列を含むリクエストに対してのみ、メタデータ上で自身をMisskeyであると偽装して返すという、極めて行儀の悪い実装\u003C/a>を行っています。JoinMisskeyとは、aqz氏が個人でメンテナンスを行っているインスタンス一覧のデータソースであり、MisskeyHubも内部的にこれを利用していました。その結果、本来掲載されるべきではないCherryPickのインスタンスが、Misskeyの顔をして公式リストに混入してしまう事態が発生していました。\u003C/p>\u003Cp>私自身、新しいインスタンスが生えていないか定期的に見に行っていたため、この信頼できない状況には困っていました。 「ならば、自分で納得できるクリーンなリストを作ろう」というのが、開発の出発点です。\u003C/p>\u003Ch1 id=\"h89265527fa\">本物を識別する\u003C/h1>\u003Cp>「Misskeyのインスタンスだけを集めたい。」言葉にするのは簡単ですが、いざ実装しようとすると、すぐに多様性とスプーフィングの壁にぶち当たります。ActivityPubのおかげで、MastodonもFirefishも、そして悪意ある偽装サーバーも、外向きには同じような顔をして通信してくるからです。加えて、フォーク文化が盛んであり、独自機能を追加した派生版も無数に存在します。そんな混沌としたFediverseの中から、どうやって本物と偽物を分別しているのかと言えば、幸いなことにCherryPickはJoinMisskeyに対してのみMisskeyを名乗るような仕草をしていたので、これを逆手に取りました。\u003C/p>\u003Cp>私が実装した検出機構では、単にリクエストを投げるだけでなく、意図的に異なるUAでリクエストを投げています。まず通常のブラウザなどを模したUAと、JoinMisskeyを模したUAの二種類を用意し、その双方から対象サーバーの\u003Ccode>/api/meta\u003C/code>および\u003Ccode>/nodeinfo/[2.0|2.1]\u003C/code>にリクエストを投げます。もし、ここで返ってきたJSONレスポンスの内容、特に\u003Ccode>softwareName\u003C/code>やバージョン情報に矛盾がある場合、あるいは相手によって応答を変えるような挙動が見られた場合は、その時点で信頼できないノードとして即座に弾く仕組みにしました。\u003C/p>\u003Cp>また、なるべく全ての工程を自動化したかったので、Misskey以外のソフトウェアを機械的に判定し、排除する機構が必要でした。対象のホストがMisskeyを名乗っており、JoinMisskeyが公開している\u003Ccode>ignorehosts.yml\u003C/code>に含まれていないことは最低条件ですが、それだけでは足りません。正常なレスポンスを返すかどうかの監視に加え、レポジトリ情報の検証も徹底しています。具体的には、APIで返却されるレポジトリURLが公式のものなのか、あるいは信頼できないフォークを含まないかを厳密にチェックします。\u003C/p>\u003Cp>中にはType-4nyのように過度な独自修正が加えられて独自のブランディングを行っていてもなお、nodeinfo上ではMisskeyを自称するようなフォークも存在します。そういったものを判定するため、データベース上に保持した除外リストや、既知のレポジトリパターン判定ロジックを用いて検知を行っています。このフィルタリングロジックは適宜更新し、常に概ね純粋なMisskeyを提供しているサーバーのみを抽出できるよう調整をしています。\u003C/p>\u003Cp>中規模以上のサーバーだいたい何かしらのカスタマイズを施したMisskeyを利用しているのもあって、結局のところ「どの程度までをMisskeyと見なすか」は難しいラインではあります。しかし、そこに明瞭な指標もないので、取り敢えずは私の主観とコード上のロジックで決定しています。「これこそが公平な判定だ！」といういい感じのアイデアがある方がいれば、GitHubにPRを投げてくれれば採用するかもしれません。\u003C/p>\u003Ch1 id=\"hde3dc27fcf\">連合探索\u003C/h1>\u003Cp>静的なリストではなく、各インスタンスの現状をリアルタイムに反映するため、いくつかの定期タスクを実装しています。\u003C/p>\u003Cp>まず\u003Ccode>update\u003C/code>タスクが6時間おきに実行され、登録済みのインスタンスを検証します。ユーザー数やノート数、登録開放状況といったメタデータを最新の状態に更新し、応答がないサーバーや410を返すサーバーはリストから除外します。\u003C/p>\u003Cp>そして、新規開拓を行うのが\u003Ccode>discovery\u003C/code>タスクです。既存のリストの中で\u003Ccode>is_alive=true\u003C/code>状態のMisskeyインスタンスをランダムに抽出し、そのサーバーが持つ連合先インスタンス一覧を取得します。そこに含まれるFQDNが未登録であれば、検証プロセスへ回します。\u003C/p>\u003Cp>ActivityPubの特性上、稼働しているサーバーは高い確率で他のサーバーと連合しています。\u003Cbr>つまり、既知のサーバーを起点にネットワークを辿ることで、主要なリレーやリストに登録されていない小規模な個人サーバーであっても自動的に検出が可能になります。これにより、手動登録に頼らずともある程度網羅的なリストを作成できるエコシステムを構築しました。\u003C/p>\u003Ch1 id=\"hd04cfc55ee\">アーキテクチャ\u003C/h1>\u003Cp>システムの構成についてですが、当初はCloudflare Workers / D1 / Queuesを中心に、APIだけを提供するつもりで開発を進めていました。しかしながら、数千件に及ぶ大量の連合情報を数時間に1度収集・解析する都合上、WorkersのCPU Time Limitに引っかかり、当然耐えられませんでした。特にJSONのパースやバリデーションといったCPUインテンシブな処理が重なり、タイムアウトが頻発しました。その致命的な問題に気付いたのは、コードを書き始め、実装の半分以上が完成してからでした。\u003C/p>\u003Cp>どうせ構成を見直すなら、ついでにフロントも付けて目に見える形で多くの人に使って貰えたらなと思い立ったのもこのタイミングです。ここで技術選定を根本からやり直し、フレームワークにはNuxt4を採用、データベースにはCockroachDBを使用してアプリケーションを再構築しました。インフラ基盤はGoogle Cloud Platformで統一し、Cloud Run / Cloud Build / Cloud Scheduler / Cloud Tasks / Secrets Managerで構成しています。\u003C/p>\u003Cp>この構想から設計、実装、そしてデプロイに至るまでの全ての工程は、丸2日程度で行いました。\u003C/p>\u003Cp>全体的なアーキテクチャのイメージとしては、Cloud Schedulerが定期的にトリガーを引き、Cloud Tasksがジョブを管理し、Cloud Run上のアプリケーションがCockroachDBと連携しながら外部のMisskeyインスタンス群やGitHub APIを巡回する形になります。\u003C/p>\u003Cfigure>\u003Cimg src=\"https://images.microcms-assets.io/assets/3aba23b5bd6f4b79800a0305d0e4f8aa/4248fb5b4e75471ab42e22d4d653b993/mi-server-list.png\" alt=\"\" width=\"1324\" height=\"878\">\u003C/figure>\u003Cp>また、Cloud Runをasia-northeast1を含む特定のリージョンで利用している際、Custom Domain Mappings を利用するとレイテンシが顕著に上昇する既知の問題がありました。これに対し Cloud Load Balancingを利用したルーティングと比較検証を行いましたが、結果として40ms 程度の違いしか見られなかったため、LB の維持コストとの兼ね合いでそのままマッピングを行っています。検索クエリを叩かなければレスポンスはキャッシュされる前提で実装をしているおかげか、ユーザー体験に顕著な差は現れませんでした。\u003C/p>\u003Cp>これらの基盤は全て Terraform でコード化して管理しています。\u003Cbr>会社でも普段はAWS基盤ばかり利用していますが、GCPの開発体験はAWSのそれと比べてだいぶ分かりやすく、直感的であるという印象を覚えます。無料枠も太っ腹なので嫌いじゃないです。\u003C/p>\u003Cp>\u003C/p>\u003Ch1 id=\"h38757ef838\">非同期分散処理\u003C/h1>\u003Cp>タスク実行基盤として、当初はCloud SchedulerからCloud Runのエンドポイントを直接呼び出していましたが、処理量の増加に伴いタイムアウトで処理が中断されるリスクが顕在化し、Cloud Tasksを導入しました\u003C/p>\u003Cp>現在のアーキテクチャでは、Cloud Schedulerはタスクの実行をエンキューする軽量な処理のみを行います。具体的には、Cloud Schedulerが\u003Ccode>/api/tasks/:name\u003C/code>を叩くと、アプリケーションは処理を直接実行せず、Google Cloud Tasksのキューにタスクを積みます。\u003C/p>\u003Cp>ここの重要な点として、キューの\u003Ccode>max_concurrent_dispatches\u003C/code>(最大同時実行数)を1に制限しています。これは、外部インスタンスへの過度なリクエストを防ぐ行儀の良さの担保と、自身のデータベース接続数の枯渇を防ぐためです。タスク名にタイムスタンプを含めて重複実行を排除し、失敗時にはCloud Tasksのリトライポリシーによって自動的に再試行される堅牢な設計としています。\u003C/p>\u003Cp>また、Cloud TasksからCloud RunへのリクエストにはOIDCトークンが付与されており、Cloud Run側でリクエストが正当な権限を持ったサービスアカウントからのものであるかを厳格に検証しています。つまり、\u003Ccode>/tasks/workers/[:name]\u003C/code>エンドポイントはインターネットに公開されていますが、実質的には内部からしか叩けない設計となっています。人間が手動でキックするためのエンドポイントには独自のBearerトークン制限をかけ、システムからの自動実行にはIAM認証を用いるいい感じのセキュリティを実現しました。\u003C/p>\u003Ch1 id=\"h08ac57933c\">言語の判定\u003C/h1>\u003Cp>実装において最もかつ苦労したのはインスタンスの主要言語判定です。ユーザーが新しいサーバーを探す際、「そこで何語が話されているか」はサーバーのテーマと同じくらい重めな条件になります。しかし、Misskeyの仕様上、言語設定は必須ではなく、説明文も英語と日本語が混在している文章や極端に短い文章で構成されているといったケースが多々あります。APIから得られる情報だけでは、そのサーバーが実際にどの言語圏のコミュニティなのかを正確に断定することが困難でした。\u003C/p>\u003Cp>既存の言語判定ライブラリもいくつか試しましたが、短文やノイズの多いテキストに対してはどれも単体では実用に耐えうる精度が出ませんでした。そこで、複数のロジックを組み合わせた合議制アルゴリズムを実装して解決することにしました。\u003C/p>\u003Cp>判定プロセスは三段階に分かれており、第一段階として、テキスト内の文字コードの範囲を走査するヒューリスティック判定を行います。日本語や中国語、韓国語のように特徴的な文字種が含まれていれば、重い処理を回すまでもなく高速に言語を確定できます。ここで判別がつかない場合は第二段階として、特性の異なる3つの言語判定ライブラリに判定を委ね、多数決投票を行います。アルゴリズムの異なるライブラリに投票をさせることで、個々の誤判定を相互に補完させる狙いです。\u003Cbr>さらに、それでも結果が割れて怪しい場合は、実際にそのサーバーのLTLから直近の投稿20件を取得し、実データのサンプリングに基づいて解析を行っています。\u003C/p>\u003Cp>最近だとLLMのAPIもだいぶ安くて、Geminiあたりを使ってもよかったのですが、自動で収集と判定を延々と繰り返している、かつMisskeyを利用する全てのインスタンス数が把握できない以上、ランニングコストの試算ができなかったため無謀すぎてやめました。もし対象が小規模かつ試算ができる状態であれば、実装コスト諸々との天秤にかけて利用していたと思います。\u003C/p>\u003Cp>また、どれだけ収集能力が高くても、ノイズだらけでは意味がありません。そのため、除外リストの運用には細心の注意を払っています。ベースとなるのはJoinMisskeyが公開している\u003Ccode>ignorehosts.yml\u003C/code>ですが、これはあくまで最低ラインです。当リストでは、これに加えて独自の検疫プロセスを導入しています。例えば、一度は正常にMisskeyと判定されたサーバーであっても、その後の定期観測でソフトウェア名の偽装や、Misskey以外の実装への変更などといった不審な変更が見られた場合、自動的にシステム側の除外テーブルに追加され、リストから排除されます。また、Misskey以外のAP実装が誤って検出された場合も、同様にフィルタリングされます。このプロセスは完全に自動化されており、私の主観が入り込む余地を排除しています。\u003C/p>\u003Ch1 id=\"hfa9126a93a\">透明性がどうのこうの\u003C/h1>\u003Cp>幸か不幸か、インターネット人間として長年活動している中で、私を嫌う方々に粘着されてしまっていて、こういうものを作ると必ずいちゃもんを付けられることが懸念されました。具体的には、「私の気に食わないサーバーを意図的に排除している」だとか、「公平性に欠く基準で恣意的にレコメンドしている」なんかがそうですね。\u003C/p>\u003Cp>まぁ、個人運営のリストに対する主張としては妥当だと思うのですが、これに関して言えば私に限らず公式だろうと似たり寄ったりだろうと思うわけです。それにしても、こういうことをイチイチ言われるのも気分がいいものではありません。\u003C/p>\u003Cp>こうした懸念を払拭するため、私は全ての情報を公開する方針をとりました。ソースコードはGitHub上にAGPL-3.0ライセンスのもと公開しており、収集した統計データ、除外リスト、そしてその除外理由に至るまで、全てAPIで取得可能です。\u003C/p>\u003Cp>特にRecommendedスコアの算出ロジックについても、コード内の\u003Ccode>calculateRecommendationScore\u003C/code>関数を見ていただければ分かる通り、完全に数式です。ユーザー数や投稿数といった規模感に加え、GitHub Releasesから取得した最新バージョンに対する追随度や、活動率を係数として掛け合わせ、機械的にスコアを弾き出しています。たとえば、バージョンが古いサーバーはセキュリティリスクと見なし、指数関数的にスコアを減衰させる処理を入れています。そこに私の主観やお気持ちが入る余地は当然1ミリもありません。\u003C/p>\u003Cp>実際、この懸念は杞憂ではなくて、公開直後にある方から直々に文句を言われてしまいました。こういうの言ってくる人って、自身の主張に妥当性があるかどうかすら考えないんですかね。コードも公開データも見ずに、イメージだけでいちゃもんをつけて来るのはかなり無理があります。文句があるならGitHubでIssueでも建ててもらえば、こちらとしても対等な議論として対応できるので幾分建設的だとは思うのですが、残念ながら彼女にその考えはなかったようです。\u003C/p>\u003Ch1 id=\"h1afe451c43\">さいごに\u003C/h1>\u003Cp>そんなわけで、年の瀬ギリギリの滑り込み記事でした。\u003C/p>\u003Cp>元々は自分が不便だからという理由だけで作ったツールですが、公開してみると予想以上の反響があり、私としてはうれしい限りです。非中央集権の海は広大で、自由で、そして少しだけ不親切です。そんな中で、結果として誰かの役に立てたのなら、それはとても嬉しいことだと思います。\u003C/p>\u003Cp>収集したデータはWebで見れるだけじゃなく、登録不要のAPIとして全開放しています。Botを作るもよし、統計を取ってニヤニヤするもよし。私のお財布が吹き飛ばない程度に、自由に叩き倒してください。ドキュメントも一応用意してあるので、バグや要望があればGitHubまで。PRはいつでも歓迎します。\u003C/p>\u003Cp>それでは、よいお年を。\u003C/p>",[54,55,56,62],{"id":31,"createdAt":32,"updatedAt":33,"publishedAt":32,"revisedAt":33,"slug":34,"name":35},{"id":37,"createdAt":38,"updatedAt":39,"publishedAt":38,"revisedAt":39,"slug":40,"name":41},{"id":57,"createdAt":58,"updatedAt":59,"publishedAt":58,"revisedAt":59,"slug":60,"name":61},"8q8qyy8sz3","2025-04-29T08:44:23.406Z","2025-12-03T16:07:24.495Z","programming","プログラミング",{"id":63,"createdAt":64,"updatedAt":65,"publishedAt":64,"revisedAt":65,"slug":66,"name":67},"fwj_nwhj1-s","2025-04-30T04:55:28.953Z","2025-12-03T16:07:03.591Z","server","サーバー","はじめにMisskeyのサーバー探しで困ったことはありませんか？公式のリストが止まっていたり、実態のわからないサーバーが混ざっていたり。そんな状況に業を煮やし、最新の状況を自動で反映し続けるサーバーリストを作成しました。https://servers.misskey.ink/本当は今年のMisske",24,1783975276724]