[{"data":1,"prerenderedAt":79},["ShallowReactive",2],{"article-e-3nu72af97k":3,"prev-article-e-3nu72af97k":39,"next-article-e-3nu72af97k":56,"$f2Gb2Jg4_xihX6pmQwfo8i1JAqPs_cJ-so8wnEUddZzs":71},{"contents":4,"totalCount":37,"offset":38,"limit":37},[5],{"id":6,"createdAt":7,"updatedAt":8,"publishedAt":8,"revisedAt":8,"title":9,"content":10,"tags":11,"is_no_index":36},"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>",[12,18,24,30],{"id":13,"createdAt":14,"updatedAt":15,"publishedAt":14,"revisedAt":15,"slug":16,"name":17},"vmhb23sq4","2025-07-29T12:56:07.884Z","2025-12-03T16:06:19.140Z","misskey","Misskey",{"id":19,"createdAt":20,"updatedAt":21,"publishedAt":20,"revisedAt":21,"slug":22,"name":23},"qfey3yw0z1","2025-04-29T08:44:41.687Z","2025-12-03T16:07:14.622Z","technology","テクノロジー",{"id":25,"createdAt":26,"updatedAt":27,"publishedAt":26,"revisedAt":27,"slug":28,"name":29},"8q8qyy8sz3","2025-04-29T08:44:23.406Z","2025-12-03T16:07:24.495Z","programming","プログラミング",{"id":31,"createdAt":32,"updatedAt":33,"publishedAt":32,"revisedAt":33,"slug":34,"name":35},"fwj_nwhj1-s","2025-04-30T04:55:28.953Z","2025-12-03T16:07:03.591Z","server","サーバー",false,1,0,{"contents":40,"totalCount":55,"offset":38,"limit":37},[41],{"id":42,"createdAt":43,"updatedAt":44,"publishedAt":44,"revisedAt":44,"title":45,"content":46,"tags":47,"is_no_index":36,"summary":54},"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>",[48],{"id":49,"createdAt":50,"updatedAt":51,"publishedAt":50,"revisedAt":51,"slug":52,"name":53},"wia4slp55q","2025-04-28T07:14:14.541Z","2025-12-03T16:08:13.798Z","thoughts","独り言","もう、うんざりです。普段は「バカな発言だな〜」と思ってもスルーしていますが、最近あまりにも目に余るのでお気持ちが溢れています。SNSを開けば「男女の友情はありなし？」みたいな低レベルな議論。あるいは「私、女の子大好きなんで！」みたいな、聞いてもいない性的アピール。こういう人、皆さんの周りにもいません",45,{"contents":57,"totalCount":70,"offset":38,"limit":37},[58],{"id":59,"createdAt":60,"updatedAt":61,"publishedAt":62,"revisedAt":61,"title":63,"content":64,"tags":65,"is_no_index":36,"summary":69},"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>",[66,67,68],{"id":49,"createdAt":50,"updatedAt":51,"publishedAt":50,"revisedAt":51,"slug":52,"name":53},{"id":25,"createdAt":26,"updatedAt":27,"publishedAt":26,"revisedAt":27,"slug":28,"name":29},{"id":19,"createdAt":20,"updatedAt":21,"publishedAt":20,"revisedAt":21,"slug":22,"name":23},"はじめにここ最近、なんちゃって技術界隈で、なんだかすごい言説が流れてくるようになりました。曰く、「現代の高級言語は人間がバイナリを読み書きするための単なる中間言語に過ぎないのだから、LLMが直接実行可能なバイナリを生成すればいいのではないか」とのこと。これを聞いた瞬間、まともな技術者なら、苦笑い、爆",23,{"url":72,"domain":73,"title":74,"description":75,"image":76,"favicon":77,"type":78},"https://servers.misskey.ink/","servers.misskey.ink","(Unofficial) Misskey Server List | Misskeyサーバー・インスタンスリスト","あなたにぴったりのMisskeyサーバーを見つけよう。登録数、ノート数、活動率などで検索できる非公式のMisskeyサーバーリスト(インスタンスリスト)です。","https://servers.misskey.ink/ogp.png","https://servers.misskey.ink/favicon.ico","GENERAL",1783975276706]