[{"data":1,"prerenderedAt":71},["ShallowReactive",2],{"article-qqupfxdxo":3,"prev-article-qqupfxdxo":34,"next-article-qqupfxdxo":59},{"contents":4,"totalCount":32,"offset":33,"limit":32},[5],{"id":6,"createdAt":7,"updatedAt":8,"publishedAt":9,"revisedAt":8,"title":10,"content":11,"tags":12,"is_no_index":31},"qqupfxdxo","2026-01-08T17:11:19.647Z","2026-01-09T05:27:38.651Z","2026-01-08T19:30:52.271Z","「LLMがプログラミングするのなら直接マシン語書けるんじゃね？」←そんなわけがない","\u003Ch1 id=\"h8d027c8ed3\">はじめに\u003C/h1>\u003Cp style=\"text-align: start\">ここ最近、なんちゃって技術界隈で、なんだかすごい言説が流れてくるようになりました。\u003C/p>\u003Cp style=\"text-align: start\">曰く、「現代の高級言語は人間がバイナリを読み書きするための単なる中間言語に過ぎないのだから、LLMが直接実行可能なバイナリを生成すればいいのではないか」とのこと。これを聞いた瞬間、まともな技術者なら、苦笑い、爆笑、冷笑(あるいはその他の否定的な感情)を禁じ得なかったのではないでしょうか。\u003C/p>\u003Cp style=\"text-align: start\">彼らの言う、LLMでプロダクションレベルのコードが書ける時代(笑)では、それが合理的なものに見えているのかもしれません。しかしそれは「明日から全員、口で喋るのをやめて脳波で直接テレパシー通信しようよ！！」と言われるくらい、現実味のない笑い話です。\u003C/p>\u003Cp style=\"text-align: start\">なぜ、現代のLLMによるバイナリコード出力がこれほどまでにナンセンスで、実現不可能なお笑い草なのか。技術的な無理解とその無謀さをあえて基礎的な観点から整理して笑い飛ばしてみましょう。だいたいそういう内容の記事です。\u003C/p>\u003Ch1 id=\"h6bc683b58b\">Excel方眼紙の呪い\u003C/h1>\u003Cp style=\"text-align: start\">人間が直接コードを書かず、何か別の上位概念からシステムを生成しようという発想自体はそう新しいものではありません。LLMが覇権を握る以前から、この国では「Excel方眼紙さえ完璧ならシステムは動く」と信じて疑わない人々が彷徨っていました\u003C/p>\u003Cp style=\"text-align: start\">「設計書さえ完璧に記述すれば、あとは誰がコードを書いても同じ。コードなんてただの実装作業でしかないんだから。」\u003C/p>\u003Cp style=\"text-align: start\">そう謳って構築された、数千億円規模とも言われるの某銀行の巨大システム群が何を生み出したか。それは、誰も全容を把握できず、メンテナンス不能に陥った巨大なブラックボックスでした。\u003C/p>\u003Cp style=\"text-align: start\">ちなみに、某銀行のシステムが、特定のツールで作られたかどうかなど些末な問題です。ここでの本質的な問題は、マルチベンダによる巨大な分業体制の中で、設計と実装を完全に切り離し、言い換えれば、人をコンパイラのように扱ったことにあります。\u003C/p>\u003Cp style=\"text-align: start\">その結果どうなったか。コードを見なくていいはずが、コードと乖離し続ける膨大な設計の整合性を取るために、人間が血眼になってExcelを管理する羽目になりました。\u003C/p>\u003Cp style=\"text-align: start\">厳密な仕様定義と、優秀なエンジニアを大量投入してなお、この苦しみです。確率的にしか動かない現代の残念なLLMにバイナリを生成させればどうなるか、想像に難くありません。\u003C/p>\u003Cp style=\"text-align: start\">実装を軽視し、抽象的な指示だけでシステムが動くという妄想は、過去に我々が大量のお金と時間をドブに捨てて学んできた、SIer仕草の悪しき再生産に他なりません。出来上がるのはシステムではなく、誰も中身を理解できず、修正も検証も不可能な巨大な産業廃棄物です。行く先にはまたしても、何人もの屍が積み上がることでしょう。\u003C/p>\u003Cp style=\"text-align: start\">中には、\u003Ca href=\"https://x.com/takeshy/status/2009130068149408150\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">こんなこと\u003C/a>を本気で言う人もいます。\u003C/p>\u003Cp style=\"text-align: start\">「なんか不具合あったらAIに直してって言えば、バイナリ解析して修正してくれるんでしょ？(意訳)」\u003C/p>\u003Cp style=\"text-align: start\">なるほど。原因の特定も、修正の妥当性も、影響範囲の検証も、すべて省略できる魔法の言葉があるらしい。もしそれが本当なら、我々はとっくにデバッガもテストもCIも捨てているはずです。\u003C/p>\u003Ch1 id=\"h07e54e9c97\">高級言語はセマンティクスを定義する\u003C/h1>\u003Cp style=\"text-align: start\">これら主張の根底には、プログラミング言語は任意バイナリへの変換を楽にするための中間言語であるという誤った認識があります。これは大きな間違いです。\u003C/p>\u003Cp style=\"text-align: start\">現代において、高級言語の本質は、ハードウェアの抽象化だけではなく、システムが何であるかというセマンティクスの定義そのものです。そしてさらに重要なのは、高級言語は表現力を上げると同時に、意図的にできないことを増やしているという点です。\u003C/p>\u003Cp style=\"text-align: start\">RustやGo、TypeScriptなどの現代的な言語を見れば明らかですが、これらは「メモリ領域を勝手に操作できない」「型が合わない計算はできない」といった強力な制約を持っています。なぜそんな制約を入れるのかといえば、自由度と検証可能性がトレードオフの関係にあるからです。\u003C/p>\u003Cp style=\"text-align: start\">制約があるからこそ、コンパイラは「このバイナリは言語仕様上のメモリ安全性が担保されている」「この並行処理は競合しない」といった、ある意味での数学的な正しさを検証できます。LLMに生のバイナリを直接扱わせるということは、安全性を担保するための制約を全てかなぐり捨て、メモリ破壊もセキュリティホールも作り放題の無法地帯に放り込むことを意味します。ガードレールを撤去してゴツいクソデカスポーツカーを自動運転させるようなもので、事故が起きないわけがありません。\u003C/p>\u003Ch1 id=\"h42b14bd67b\">コンテクストウィンドウとトークンコスト\u003C/h1>\u003Cp style=\"text-align: start\">現実的なリソースとお金の話をしましょう。\u003C/p>\u003Cp style=\"text-align: start\">実行バイナリの情報密度は、高級言語で記述されたソースコードに比べて極めて低く冗長です。例えば、Goで\u003Ccode>fmt.Print("Hello world!")\u003C/code>と書けば済む処理も、バイナリになれば、システムコールの番号をレジスタに入れ、メモリアドレスを指定し、割り込みを発生させ、スタックを退避し…といった細かな命令コードの羅列になります。ソースコードなら数行で済むロジックが、バイナリデータとしては数KiB, MiBに膨れ上がります。\u003C/p>\u003Cp style=\"text-align: start\">現在のLLMには、コンテクストウィンドウの限界があります。前述のような、意味の詰まった高級言語でさえ、大規模なシステムを読み込ませればコンクキスト溢れを起こして使い物にならないのが現状です。そこに、冗長極まりないバイナリを流し込めばどうなるか。一瞬で埋まり、LLMがまともに期待する動作をしてくれることはまずないでしょう。\u003C/p>\u003Cp style=\"text-align: start\">最近ではだいぶ安くなったものの、LLMの出力コストは、安いものでも1万トークンあたり数円〜数十円かかります。数MiBにも及ぶバイナリデータを生成させるために、数万、数十万円の金銭を支払うつもりでしょうか？\u003C/p>\u003Cp style=\"text-align: start\">手元のPCにあるコンパイラを使えば、事実上0円かつ数秒で、正確に変換してくれる作業を、わざわざ高コストで不確実性のあるLLMにやらせる合理性は、どこにも存在しません。\u003C/p>\u003Cp style=\"text-align: start\">まともな頭があればこのくらい分かりそうなものですけどね。\u003C/p>\u003Ch1 id=\"h26b276b313\">コンパイラがどうの\u003C/h1>\u003Cp style=\"text-align: start\">｢コンパイラなんてただのバイナリ変換機だろう｣と思っているなら、それも認識を改めるべきです。現代のコンパイラ多くは、過去数十年にわたる人類の英知と膨大な検証の結晶です。\u003C/p>\u003Cp style=\"text-align: start\">コンパイラは単に変換しているだけではありません。ループの展開やデッドコードの削除、パイプラインを停滞させないための命令順序の並べ替え、レジスタ割り当ての最適化など、高度な処理を厳密に行っています。同じソースコードを食わせても、コンパイルオプション一つで生成されるバイナリは大きく変わってしまいます。\u003C/p>\u003Cp style=\"text-align: start\">良くも悪くも、LLMは確率的な出力をするものです。なんとなくそれっぽい文字列を生成することには長けていますが、バイナリを正しく生成するなんてことは当然不可能です。\u003C/p>\u003Cp style=\"text-align: start\">残念なことに、世界には無数の環境があり、命令セットも多岐にわたります。コンパイラは、これらの組み合わせの差異を吸収して、それぞれの環境に最適なバイナリを出し分けてくれています。これをLLMにやらせるということは、OSやプロセッサごとの微妙な仕様の違いやシステムコールの番号を網羅的に充分な量の学習をさせ、環境ごとに毎回何MiBものバイナリを生成し直させるということです。正気の沙汰とは思えません。\u003C/p>\u003Ch1 id=\"h1afe451c43\">さいごに\u003C/h1>\u003Cp style=\"text-align: start\">ひとつ、勘違いしてはいけないことがあります。\u003C/p>\u003Cp style=\"text-align: start\">各社が提供しているエージェントは、決して論理を組み立てているわけではありません。あれは膨大な学習データから次に来そうな文字を確率的に吐き出しているだけであり、そこに意思も、理解も、厳密なロジックも存在しません。\u003C/p>\u003Cp style=\"text-align: start\">だからこそ、私たちは高級言語を使うのです。\u003C/p>\u003Cp style=\"text-align: start\">確率的に嘘をつくことしかできない残念なLLMが吐き出したコードを確認した上で、コンパイラという決定論的な論理エンジンに通すことで、初めて整合性を担保できるからです。\u003C/p>\u003Cp style=\"text-align: start\">LLMが直接バイナリを書けばいいなどという妄言は、これらの前提条件を捨てているといっても過言ではありません。\u003C/p>\u003Cp style=\"text-align: start\">少なくとも技術者を名乗るのであれば、LLMガチャ師仕草をやめて、その残念な自らの頭を活用してみてはいかがでしょうか？\u003C/p>\u003Cp style=\"text-align: start\">驚き屋を追いかけてのお勉強(笑)には熱心なのに、抽象化された高級言語すらまともに読み書きできないのであれば、技術者としてお話になりません。\u003C/p>",[13,19,25],{"id":14,"createdAt":15,"updatedAt":16,"publishedAt":15,"revisedAt":16,"slug":17,"name":18},"wia4slp55q","2025-04-28T07:14:14.541Z","2025-12-03T16:08:13.798Z","thoughts","独り言",{"id":20,"createdAt":21,"updatedAt":22,"publishedAt":21,"revisedAt":22,"slug":23,"name":24},"8q8qyy8sz3","2025-04-29T08:44:23.406Z","2025-12-03T16:07:24.495Z","programming","プログラミング",{"id":26,"createdAt":27,"updatedAt":28,"publishedAt":27,"revisedAt":28,"slug":29,"name":30},"qfey3yw0z1","2025-04-29T08:44:41.687Z","2025-12-03T16:07:14.622Z","technology","テクノロジー",false,1,0,{"contents":35,"totalCount":58,"offset":33,"limit":32},[36],{"id":37,"createdAt":38,"updatedAt":39,"publishedAt":39,"revisedAt":39,"title":40,"content":41,"tags":42,"is_no_index":31,"summary":57},"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>",[43,49,50,51],{"id":44,"createdAt":45,"updatedAt":46,"publishedAt":45,"revisedAt":46,"slug":47,"name":48},"vmhb23sq4","2025-07-29T12:56:07.884Z","2025-12-03T16:06:19.140Z","misskey","Misskey",{"id":26,"createdAt":27,"updatedAt":28,"publishedAt":27,"revisedAt":28,"slug":29,"name":30},{"id":20,"createdAt":21,"updatedAt":22,"publishedAt":21,"revisedAt":22,"slug":23,"name":24},{"id":52,"createdAt":53,"updatedAt":54,"publishedAt":53,"revisedAt":54,"slug":55,"name":56},"fwj_nwhj1-s","2025-04-30T04:55:28.953Z","2025-12-03T16:07:03.591Z","server","サーバー","はじめにMisskeyのサーバー探しで困ったことはありませんか？公式のリストが止まっていたり、実態のわからないサーバーが混ざっていたり。そんな状況に業を煮やし、最新の状況を自動で反映し続けるサーバーリストを作成しました。https://servers.misskey.ink/本当は今年のMisske",46,{"contents":60,"totalCount":70,"offset":33,"limit":32},[61],{"id":62,"createdAt":63,"updatedAt":64,"publishedAt":64,"revisedAt":64,"title":65,"content":66,"tags":67,"is_no_index":31,"summary":69},"q5e6pg8hcoe","2026-01-11T22:23:35.407Z","2026-01-11T22:34:37.088Z","Twitterやめますか？, 人間やめますか？","\u003Cp>Twitterからあの愛らしい青い鳥が姿を消し、得体の知れないアルファベットに成り果ててから、かれこれ3年の月日が経とうとしています。\u003C/p>\u003Cp>イーロン・マスクがTwitterを買収した直後の狂騒は、今となってはある種のエンターテインメントとして消費できていた時期だったのかもしれません。大量のレイオフ、Twitter Blueの強行導入、フリート。破壊の限りを尽くすその姿には、どこか破壊神的なカリスマ性すら感じられました。彼が声高に叫ぶスーパーアプリ構想(笑)とやらが、私たちの生活どう変えてくれるのか、怖いもの見たさがあったのも事実です。結局のところ、彼が作りたかったのは金融機能がついた万能なSNSではなく、単なる自身の承認欲求を満たすための巨大な拡声器だったようですが。\u003C/p>\u003Cp>本題に入る前に、ひとつだけ定義をしておかなければなりません。私は普段、この場所を頑なにTwitterと呼んでいます。\u003C/p>\u003Cp>未練がましいと言われようが、私の青春とインターネットの文脈が詰まったあの場所を、ヘンテコなアルファベットで上書きされたくはありません。私の中でのTwitterは、どうでもいい日常と、顔も知らない友人たちとの緩やかな連帯の象徴でした。その記憶を、現在の惨状と混ぜ合わせたくはありません。\u003C/p>\u003Cp>しかし、本エントリにおいて、あのシステムと運営方針、そしてその背後に透けて見える思想を批判する文脈に限っては、あえてXと呼称します。私が愛したTwitterと、現在進行系でインターネット焼き畑農業をしているこの集金装置は、似て非なる全く別の物だからです。Twitterという名前を汚さないためにも、この悪意の塊にはXとかいうダサい名前がお似合いでしょう。\u003C/p>\u003Cp>さて、そんなXの惨状に嫌気がさし、数年前の私はMisskeyへ安住の地を求めました。ioにアカウントを作り、自前でインスタンスを構築し、燃え尽きて知人のサーバーに居候をしています。APIの制限や厳格なレートリミット、雨後の筍のように湧き出るスパムの氾濫といった表面的な不便さ以上に、プラットフォームの根幹が変質したことに耐えられなかったからです。\u003C/p>\u003Cp>しかし、今に至るまで、私はTwitterをやめられませんでした。\u003C/p>\u003Cp>Misskeyの穏やかなTLを眺めながら、結局は泥沼のようなXへと舞い戻る生活をしています。\u003C/p>\u003Cp>なぜか。それは、Xの資本主義に溺れたカスのレコメンドシステムが、金儲けという一点においてあまりにも優秀で、華々しく成功してしまっているからに他なりません。\u003C/p>\u003Cp style=\"text-align: start\">私たちがXのアルゴリズムは壊れている、Evilだと嘆くとき、それはあくまでユーザー体験の視点に立っています。しかし、株主と経営者の視点、つまるところ、如何にユーザーをサービスに縛り付け、広告を見せ、データを吸い上げるかというKPIの視点に立てば、現在のXはかつてないほどの完成度を誇っています。\u003C/p>\u003Cp style=\"text-align: start\">現に、Xのおすすめフィードを眺めていると、無限に不快なものが流れてきます。論理が破綻した暴論、特定の属性に対する差別的な言説、あまりに無知で傲慢な主張。そして何より、インプレッションを稼ぐためだけに生成されたゾンビアカウント群の文脈を無視した無意味な羅列。\u003C/p>\u003Cp>リプ欄を開けば、元ツイとは何の関係もない謎のマルチバイト文字や、LLMが生成した当たり障りのない同意、あるいは露骨なNFSW画像が溢れかえっています。彼らは会話をするためにそこにいるのではありません。ただ小銭を稼ぐためだけに、ハエのように群がっているのです。\u003C/p>\u003Cp style=\"text-align: start\">残念ながら、これらはバグではありません。すべて想定されたであろう仕様です。\u003C/p>\u003Cp style=\"text-align: start\">我々人間は、穏やかで幸福な情報よりも、怒りや恐怖、軽蔑といった強い情動を伴う刺激に強く反応するように設計されています。こいつは間違っている、許せない、馬鹿な奴だ。そう感じた瞬間、私たちは反射的に指を止め、画面を凝視し、タップしてしまいます。\u003C/p>\u003Cp style=\"text-align: start\">その滞在時間こそが、Xという企業が販売している唯一の商品です。このアルゴリズムは、私の卑しい本性を正確に見透かしています。\u003C/p>\u003Cp style=\"text-align: start\">現に私は、流れてくる不快な投稿を無視できず、縮小鍵垢で引用RTを繰り返しています。こんな馬鹿なことを言っている奴がいると他人をコケにし、安全圏から石を投げ、自分が知的優位に立ったような錯覚に浸る。私は救いようのないカスであることに違いありません。\u003C/p>\u003Cp style=\"text-align: start\">ですが、Xにとって私は最高に優良な養分でもあります。私がストレス抱き、軽蔑し、対立を深めれば深めるほど、プラットフォームの滞在時間は最大化され、広告在庫が消化され、イーロンの財布にはお金が入る。私たちが画面の前でイライラすればするほど、Xは儲かるのです。\u003C/p>\u003Cp style=\"text-align: start\">ここにあるのは、人間の尊厳をハックして換金する錬金術でしかありません。対立を煽れば数字が伸びる。極端なことを言えば金になる。その構造が完成してしまった以上、X上から争いが消えることは永遠にありません。平和な世界は、ビジネスとして儲からないからです。\u003C/p>\u003Cp style=\"text-align: start\">かつてTwitterが持っていた、清濁併せ呑む広場のような機能は失われました。今ここにあるのは、互いの正義を棍棒にして殴り合わせ、その流血を観客に見せて興行収入を得るコロッセオです。もっとも、戦っているのは剣闘士ではなく、承認欲求に飢えた一般人と、小銭稼ぎのbotですが。\u003C/p>\u003Cp style=\"text-align: start\">MisskeyやMastodonといった分散型SNSは、確かに理想郷でした。そこには邪悪な金儲けに最適化されたレコメンドがなく、文脈を共有できる隣人がいました。\u003C/p>\u003Cp style=\"text-align: start\">しかし、Xという劇薬に溺れた私にとって、その平和は時に退屈と同義でした。刺激がない。敵がいない。殴るべき馬鹿がいない。\u003C/p>\u003Cp style=\"text-align: start\">悲しいことに、私の認知機能はすでにTwitterというよりはXの仕様に合わせて最適化されてしまっているのです。ストレスなしには、インターネットの生を実感できなくなっている。これは中毒症状以外の何物でもありません。\u003C/p>\u003Cp style=\"text-align: start\">Twitterでしか繋がれない人脈、Twitterに置き去りにしてきた膨大な思い出。それらを大切に思うからこそ、私は今のXを憎みます。\u003C/p>\u003Cp style=\"text-align: start\">ですが本質的な理由は、私が真人間であることよりも、アルゴリズムに踊らされる反応機械であることの快楽を選んでしまったという点に尽きます。\u003C/p>\u003Cp style=\"text-align: start\">かつて、昭和の街角に貼られたポスターは、白い粉の恐怖と共に｢人間やめますか｣と問いかけました。しかし令和になった今、私たちは手のひらの上で鈍く光る黒いアイコンを見つめながら、その問いに無言で頷こうとしています。\u003C/p>\u003Cp>理性も品性もかなぐり捨てて、汚泥のような情報を浴び続けること。怒りを燃料にして走り続けること。それがこのプラットフォームに最適化された、新しい人類の醜い姿なのかもしれません。\u003C/p>\u003Cp>青い鳥は死にました。多くの人の順当な人間性も、もしかしたらその時に一緒に死んでしまったのでしょう。\u003C/p>\u003Cp>文句を言いながらも指先は正直です。今日も元気に、地獄の窯の蓋を開けに行きましょう！\u003C/p>",[68],{"id":14,"createdAt":15,"updatedAt":16,"publishedAt":15,"revisedAt":16,"slug":17,"name":18},"Twitterからあの愛らしい青い鳥が姿を消し、得体の知れないアルファベットに成り果ててから、かれこれ3年の月日が経とうとしています。イーロン・マスクがTwitterを買収した直後の狂騒は、今となってはある種のエンターテインメントとして消費できていた時期だったのかもしれません。大量のレイオフ、Twi",22,1783975276605]