洪民憙雑記

ブログにActivityPub連携を追加した

2026-07-15T16:00:00.000Z

ブログにActivityPub連携を追加した

自作の静的サイトジェネレーターJikjiでこのブログを作ってから、もう五年近く経つ。当時の私はTypeScriptにも最新のウェブ技術にもまだ慣れておらず、 ActivityPubを実装したこともなかった。しかし今ではTypeScriptにも最新のウェブ技術にも比較的慣れ、ActivityPubは私にとって重要な技術になった。しかも曲がりなりにもFedifyのメンテナーでありながら、肝心のブログが連合していないことが、ずっと気になっていた。そこでブログにActivityPub連携を追加することにした。

既存スタック: Jikji + PHP

このブログはもともと、自作のDeno製静的サイトジェネレーターJikjiをベースにしていた。厳密には静的サイトとは言い切れず、昔のMovable Typeがそうだったように、単にHTMLを生成するだけでなく PHPの一部も生成していたからだ。PHPは主にHTTPのコンテンツネゴシエーションに使っていた。ブラウザのAccept-Language ヘッダーを見て、漢字ハングル混じり文の朝鮮語、ハングル専用の韓国語、英語、日本語のうち適切な言語を表示していた。それだけのことではあるが。

すでにPHPを使っているのだから、PHPで薄くActivityPubを実装することも一応検討した。しかしPHPを使っているといっても、自分の手で書いたコードではなくJikjiが生成してくれるものだったから使っていただけで、PHPを手作業で書きたいとは思わなかった。新しい記事が公開されたら自動でCreate(Article) アクティビティをフォロワーに配送しなければならないが、そのためにはどのみちメッセージキューのような仕組みが必要になる。PHPにメッセージキューまで組み合わせるとなると、私見では、PHPに見合う規模と複雑さを超えてしまう気がした。そして何より、Fedifyがあるのに、わざわざゼロからActivityPubを実装したくはなかった。

そこでPHPを丸ごと取り除き、Fedifyを組み込むことに決めた。

新スタック: Astro + Netlify

まず最初の選択として、JikjiとPHPを捨て、静的なコンテンツを中心にしたウェブサイトづくりに特化したJavaScriptフレームワークAstroを採用することにした。すでに@fedify/astroという連携パッケージが存在していたことも、 Astroを選んだ大きな理由だった。

ただし、既存のCSSやHTMLテンプレートはできる限り再利用した。今のウェブデザインに満足していたし、デザインの刷新まで手を出すと範囲が大きくなりすぎる気がした。パーマリンクも完全にそのまま維持した。全体として、訪問者が何が変わったのか気付かないくらい表面を保ちながら、技術スタックだけを移行するのが目標だった。

デプロイ先はCloudflare WorkersとNetlifyの間で迷ったが、Fedifyをまだ Netlifyで動かしたことがなかったので、これを機にFedifyのNetlifyサポートを追加することにした。静的サイトのホスティングでNetlifyは何度も使ってきたが、エッジ関数を併用するのは今回が初めてだった。基本的には静的なアセット群でありながら一部の機能だけが動的に動く、という発想は、九十年代末にウェブサイトを作る際、CGIスクリプトだけを/cgi-bin/ディレクトリに置いていたやり方を思い出させた。

以前はブログ記事をMarkdownファイルとして保存してGitにコミットし、プッシュするとGitHub Actionsが静的サイトをビルドしてからSFTPでデプロイする、という流れだった。今ではGitHub Actionsをビルドパイプラインから外せるようになった。Netlifyが勝手にビルドしてくれるからだ。結果として、より単純になった。

Astroにはおおむね満足しており、移行も比較的スムーズだった。五年前に作ってからほとんど更新していなかったJikjiより優れているのは当然のことだ。 Jikjiはもう保守する理由がなくなったので、リポジトリをアーカイブした。

AstroにFedifyを組み込む

@fedify/astroの最新化

ところがいざAstroにFedifyを組み込もうとすると、@fedify/astroが最新版の Astro 7に対応していなかった。内部で使っているAstroのAPI自体はそれほど変わっていなかったが、パッケージに明記された対応範囲とテストはAstro 5 までしかカバーしていなかった。結局、ブログにFedifyを組み込む前に、まず@fedify/astroを直す必要があった。

単にパッケージのバージョン範囲を広げただけではない。既存のテストは偽の Astroコンテキストを作ってミドルウェアを直接呼び出すものだったので、 ViteのSSR設定やアダプター間の互換性、ビルド後のサーバーにおけるリクエストのルーティングといった問題は検出できなかった。そこでFedifyパッケージを実際にパックして小さなAstroアプリケーションにインストールし、サーバーをビルドして起動したうえでHTTPリクエストまで送る、という互換性テストを新たに作った。

このテストは、Astro 5、6、7それぞれで、HTMLリクエストがAstroのページに渡るか、ActivityPubとWebFingerのリクエストをFedifyが処理するか、それ以外のパスではAstroの404 Not Foundレスポンスが維持されるか、といった点を確認する。Astro 7についてはNode.jsだけでなくDenoとBunでもビルドを試すようにした。

この作業はすでにアップストリームにマージされており、Fedify 2.4.0に含まれる予定だ。

静的ページと動的エンドポイント

Astroプロジェクト全体はサーバー出力としてビルドしつつ、既存のブログページはこれまで通りプリレンダリングするようにした。一方、WebFingerやアクター、インボックス、アウトボックス、フォロワーコレクション、ActivityPubオブジェクトのパスは、リクエストを受けた時点でFedifyが動的に処理する。@fedify/astroが提供するミドルウェアはリクエストのURLとAcceptヘッダーを見て、Fedifyが処理すべきリクエストだけを横取りする。同じURLでも、HTMLをリクエストすれば既存のAstroページが返り、ActivityPub表現をリクエストすればFedifyが作ったオブジェクトが返ることもある。

結果として、訪問者が目にするブログは依然として静的サイトに近い。新しく加わった動的な部分は、ほとんどがフェディバースの他のサーバーだけがアクセスする場所にある。先ほどCGIを思い出したのも、この構成のせいだ。

`Person`と`Article`

ActivityPubを組み込むにあたっては、このブログで何をアクターとし、何をオブジェクトとするかも決めなければならなかった。ブログのアクターには Personタイプを選んだ。実際の公開作業はプログラムが自動でやってくれるが、アクターが表しているのはブログのソフトウェアやサービスではなく、この文章を書いている私自身だからだ。そのためハンドルは @hongminhee@writings.hongminhee.orgで、アクターのウェブURLはこのブログを指している。

各ブログ記事にはArticleタイプを選んだ。タイトルと本文があり、独立したパーマリンクを持つ長文の文書だから、Noteよりも意味的にしっくりくると考えた。幸い、Mastodonをはじめとする主要なActivityPub実装の大半も Articleをサポートしている。人間が読む既存のパーマリンクはそのままにしつつ、 ActivityPubオブジェクトには/ap/articles/{year}/{month}/{slug}という形の別のURIを与えた。Articleのurlは、あらためて既存のパーマリンクを指す。 ActivityPubオブジェクトのURIと、人間が読むウェブページのパーマリンクを、はっきり分けたわけだ。

多言語対応は、もう少し悩んだところだ。言語ごとのページをそれぞれ別の Articleオブジェクトとして表現すると、同じ記事に対する反応やシェアが複数のオブジェクトに分散してしまう。そこで、同じパーマリンクに属する漢字ハングル混じり文の朝鮮語︵ko-Kore︶、ハングル専用の韓国語︵ko-Hang-KR︶、英語︵en︶、日本語︵ja︶の各バージョンを、一つの Articleにまとめることにした。タイトルと概要、本文には、それぞれ言語タグの付いた値をすべて入れてある。JSON-LDでシリアライズすると、それぞれ nameMap、summaryMap、contentMapとして表現される。言語別の値を処理しない実装のために、name、summary、contentにはデフォルト言語の値も併せて入れた。英語版があれば英語を、なければ漢字ハングル混じり文の朝鮮語をデフォルトとした。言語別のHTMLページは、Articleのurlにも hreflang属性の付いたLinkオブジェクトとして加えてある。

こうしておけば、受信側のサーバーが多言語の値を理解できる場合は利用者の言語に合ったタイトルと本文を選べるし、そうでなくてもデフォルト値は表示できる。もっとも、私が知る限りほぼすべてのActivityPub実装は、こうした多言語の自然言語値をまだきちんと表示できていない。 Mastodonのイシュートラッカーにはこのためのイシューが立てられているし、 Hackers' Pubのイシュートラッカーにも似たような提案があるが、実装される見込みはまだ立っていない。おそらくUIデザインの面でも検討が必要になるだろう。

FedifyをNetlifyで動かす

静的ファイルだけをデプロイするのと違い、ActivityPubサーバーにはデプロイが終わった後も残っていなければならない状態がある。まず、アクターの署名鍵はデプロイのたびに変わってはならない。フォロワーの一覧も、次のデプロイで消えてしまっては困る。この二つはNetlify Databaseに保存した。

インボックスで受け取ったアクティビティと、リモートサーバーに送るアクティビティは、Async Workloadsで作ったメッセージキューの中で処理する。アクティビティの配送は相手サーバーの状態次第で遅くなったり失敗したりしうるので、HTTPリクエストを受けた関数の中ですべて終わらせようとしてはいけない。キューに入れておけば、リクエストの受付と配送を切り離せるし、失敗した処理も後で再試行できる。幸いFedifyはこうした処理をあらかじめ抽象化してくれていて、バックエンドのアダプターも拡張できるようになっている。ただ、NetlifyのAsync Workloads向けのアダプターはまだなかったので、FedifyがAsync Workloadsをメッセージキューとして使いながら、 Netlify Databaseに配送順序の状態を保存できるよう、 @fedify/netlifyというパッケージも作った。

新しい記事をフェディバース︵fediverse︶に知らせるのは、また別の問題だった。静的サイトのビルドが終わったからといって、実行中のActivityPub サーバーがどの記事に変化があったのか自動的に分かるわけではない。そこで、本番環境へのデプロイが成功すると、前回のデプロイと今回のデプロイとで記事一覧を比較する。新しく追加された記事にはCreate(Article)、内容や更新日時が変わった記事にはUpdate(Article)、削除された記事には Delete(Article)アクティビティを作ってフォロワーに送る。再試行しても同じ変更には同じアクティビティIDを使い、より古いデプロイが後から同期されて最新の状態を巻き戻してしまわないよう、デプロイの順序も確認する。

Netlifyにはデプロイプレビュー︵deploy preview︶とブランチデプロイ︵branch deploy︶という機能があるが、これらの場合は連合機能を丸ごと無効にした。プレビューのたびに同じブログを名乗るアクターが増えたり、テスト用のデプロイが実際のフォロワーにアクティビティを送ってしまったりすると困るからだ。ローカルではインメモリのストレージとキューで開発でき、本番環境でのみ永続的なデータベースとキューを使う。

ともあれ、そのおかげでFedifyは今やDeno DeployやCloudflare Workersに加えて、Netlify Functionsもサポートするようになった。もちろん、Node.js、 Deno、Bunで動くのは相変わらず基本だ。

おわりに

今回の作業で、ブログにタイムラインや返信作成画面のようなソーシャル機能が付いたわけではない。文章を書いて読むやり方も、既存のパーマリンクやデザインも、ほとんどそのままだ。ただ、このブログと各記事には、フェディバースで通用する名前と住所ができた。読者は@hongminhee@writings.hongminhee.org をフォローして新しい記事を受け取れるし、各記事のActivityPubオブジェクトの URIを検索して元の文章にたどり着くこともできる。

Fedifyを保守しながら、他の開発者にActivityPubを実装する手段を提供してきたし、HolloやHackers' Pubなどを作りながらドッグフーディングもそれなりにやってきたが、すでに運用中のウェブサイト、それも静的なページでできていたブログにFedifyを組み込むのは今回が初めてだった。おかげで Astroインテグレーションの互換性テストとNetlifyサポートを追加することになったし、ドキュメントや単体テストを見ただけでは分からないデプロイや運用上の問題にも直面した。Fedifyがソーシャルネットワークを新しく作るためだけに使われるのではなく、すでに存在するウェブサイトが自分の姿を保ったままフェディバースに参加するためにも使えることを、確認できた。

ハングル専用下の漢字教育について

2026-04-17T09:00:00.000Z

ハングル専用下の漢字教育について

私は韓国語を書くとき、国漢文混用体︵漢字ハングル混じり文︶を好んで使う。ブログの文章も、ソーシャルメディアの投稿も、漢字を混ぜて書くことが多い。漢字に対する個人的な愛着は確かにある。それでも、漢字教育を韓国の公教育で深化すべきだという主張には同意しない。この文章はその理由を説明する試みだ。

教育のデフォルトは「教えない」である

教育にはコストがかかる。教師を養成しなければならず、教材を作らなければならず、何より生徒たちの時間を使わなければならない。生徒の時間は有限であるから、ある科目を教育課程に入れるということは、他の科目に使えたはずの時間を奪うということでもある。だからこそ、どの科目であれ教育課程に含めるなら、その効用が科学的に立証されなければならない。学べば役に立つだろうという漠然とした期待では足りない。役に立たない教育など存在しないからだ。裁縫だって学べば役に立つし、木工だって学べば役に立つ。問題は漢字教育が役に立つかどうかではなく、同じ時間を投入したとき、他の教育より役に立つかどうかだ。

漢字教育が韓国語の読解力向上に役立つという科学的根拠は、現時点では存在しない。漢字を知れば韓国語の語彙力が伸びるという主張はしばしば聞くが、それを裏付ける体系的な研究は見当たらない。教育政策は直感ではなく根拠の上に立つべきだ。効用が立証されない限り、デフォルトは常に「教えない」であり、これは漢字教育にも同様に当てはまる。

国漢文混用体の利点と現実論

率直に言えば、国漢文混用体には語文政策的な利点が多いと思う。漢字文化圏の他の言語との接点が広がるし、テキストの情報密度が高まる。同形異義語の区別も容易になるが、この最後の利点は人間よりも機械にとっての意味が大きい。人間は文脈が十分であれば同形異義語で困ることはめったにないが、検索エンジンや自然言語処理システムはそうではない。国漢文混用体はテキストをより機械親和的︵machine-readable︶にする。

しかし、これらの長所は漢字が日常的に使われる環境を前提としている。韓国でハングル専用が定着してから半世紀近くが経った今、漢字を読める韓国人の割合はすでに大きく低下した。この状況で国漢文混用体の利点を語ることは、英語がいくら現実的に有用だとしても韓国で英語を公用語にはできないのと似た構造だ。理論的な利点があることと、今からそれを実現できることとは別の問題だ。

私の立場を一言でまとめるとこうなる。そもそもハングル専用にしなければ良い点が多かったはずだ。しかし今さら覆すことはできない。ハングル専用を続けなければならないという現実を受け入れるべきだ。

漢字混用なき漢字教育の逆説

韓国の漢字教育の議論でよく見かける立場がある。漢字混用には反対だが漢字教育には賛成だ、というものだ。この立場は一見妥協的に見えるが、実は矛盾に近いと私は思う。学んだことは使わなければ維持できない。漢字を学校で習っても、卒業後の日常で漢字に触れる機会がなければ、その知識は急速に揮発してしまう。使用文脈のない知識の維持コストは過大だ。ハングル専用の韓国社会で漢字教育を施すのは、プールのない環境で水泳を教えるのと変わらない。

自分自身の漢字能力がどう維持されてきたかを振り返ると、この論点はより明確になる。私は国民学校¹時代に漢字教育をある程度受けた。しかしそれだけでは十分ではなかった。武侠小説が好きで漢字に継続的に触れていたし、高校では第二外国語として中国語を学んだし、大人になってからは日本語を学ぶことで漢字を忘れずに済んだ。正規教育が種を蒔いた可能性はあるが、それを維持したのは全面的に個人的な動機と継続的な接触だった。これは二つのことを示唆する。漢字に関心のある人は公教育がなくても自ら学べるということと、関心のない人には公教育があっても知識が残らないということだ。いずれにせよ、公教育における漢字教育を正当化するのは難しい。

趣向と政策の区分

漢字が好きだということと、漢字教育を韓国の公教育で行うべきだと主張することは、まったく別の話だ。私は漢字が好きだ。漢字の構造がもたらす知的な楽しさもよく分かるし、国漢文混用体で文章を書くときの妙味もよく知っている。しかしそれは私の趣向であって、すべての生徒に課す教育の根拠にはならない。教育政策は個人の趣向や郷愁ではなく、科学的根拠と機会費用の比較の上で決定されるべきだ。漢字教育の効用が立証されない限り、そしてハングル専用という現実が変わらない限り、漢字教育を韓国の公教育に含める理由はない。

一九九六年に廃止され、現在の初等学校に相当する教育機関。日本の小学校に相当する。 ↩

コーディングを愛する人たちが、なぜコーディングから追い出されているのか

2026-03-21T09:30:00.000Z

コーディングを愛する人たちが、なぜコーディングから追い出されているのか

Les Orchardが最近の記事で指摘した観察が、頭から離れない。 LLMコーディングアシスタントが登場するまで、ソフトウェアエンジニアたちのあいだの亀裂は見えなかった。

匠人気質の人たちととりあえず動けばいいという人たちが隣り合わせに座り、同じ製品を作りながら、区別がつかなかった。仕事の動機が見えなかったのは、過程が同一だったからだ。

道具が亀裂を作ったのではなかった。すでにあった亀裂を露わにしただけだ。

Orchard自身は最初の陣営だ。七歳でBASICを学んだのはBASICが美しかったからではなく、画面に何かを表示させたかったからだ。彼にとってLLMコーディングアシスタントは、いつも登り続けてきた梯子の次の段にすぎない。パズルが消えたのではなく、より高い抽象水準へと移っただけだ。彼も悲しみはするが、悲しんでいるのは仕事そのものではなく、仕事を取り巻く生態系だ。

Nolan Lawsonの悲しみは違う。二月に上げた彼の文章を見てみよう。

コードを手で掴み、彫刻家のように捏ね上げる感触が恋しくなるだろう。夜中の二時にデバッガーの前で格闘し、ついにバグが降参するあの夜が恋しくなるだろう。私たちが誇りに思ったものを、真摯で正しく良いものを作り上げた感覚が恋しくなるだろう。

彼の文章は挽歌のように読め、その中の悲しみも本物だ。彼が哀悼しているのは行為そのものだ。

二人とも思慮深く率直だが、同じ瞬間を見つめながら異なるものを感じている。この非対称は真摯に受け止める必要がある。「ただ適応すればいい」という論議が繰り返し見逃しているものを指しているからだ。

行為からの疎外

Marxは疎外された労働の次元を四つに分析した。生産物からの分離、労働行為そのものからの分離、他者からの分離、そして自身の人間的能力からの分離。 LLMコーディングアシスタントをめぐる論議において、核心は二番目だと言える。

Marxが言う「労働行為そのものからの分離」とはこういうことだ。人間は他の動物と違い、作りたいものを頭の中でまず構想し、物質世界をそのイメージに合わせて形作ることができる。この意識的で意図的な創造能力こそ、Marxが人間の特性と見たものに最も近い。労働が機械的なもの、強制されたもの、生きることではなく耐え忍ぶものになったとき、その能力は実現されない。活動は依然として起きているが、その人はもうそこに現存していない。

匠人技術を哀悼するソフトウェアエンジニアたちは、この描写に似ている。彼らが大切にしていたのは成果物ではなかった。何かを作る過程、熾烈に集中した時間、システムを十分に理解してそれを再び形作ることができるという感覚。 Lawsonがまさにそう言う。私がこれを作ったと言えるGitHubリポジトリ。何かが作られたではなく、私が作ったということ。

これで、なぜ同じ道具に対する二人の反応があれほど違うのかも見えてくる。 Orchardははじめからコードを書く行為に自分を投資していなかった。結果に投資した。LLMコーディングアシスタントが結果により速く到達させてくれるなら、彼に失うものはない。一方Lawsonには、その行為の中に意味があった。 LLMコーディングアシスタントは成果物を迂回するのではなく、彼が大切にしていた部分を迂回する。 Marxが区分した客観的疎外（感じようと感じまいと存在する条件）と主観的疎外（その喪失を経験すること）が、この分裂にかなりよく重なる。 Orchardははじめから行為そのものに客観的に縛られていなかったから主観的にも疎外を感じないが、 Lawsonは両方だ。

よくある反応は、これが郷愁であるか、あるいは新しい匠人技術が古いものを代替するだろうというものだ。そうかもしれない。しかしその反応は実際の問いを避けていく。コーディングを愛する人たちはなぜコーディングから追い出されているのか。引き寄せられているのではなく、追い出されている。誰も彼らが手でコードを書くことを止めない。市場がそれに不利益を与えているだけだ。

不利益を与えているのは何か

Marxは資本論でイギリスのラッダイト運動をこう評した。

労働者たちが機械そのものと資本による機械の使用とを区別し、したがって物質的生産手段そのものではなく、それの社会的搾取形態を攻撃することを学ぶまでには、時間と経験が必要だった。

機織り機を壊した労働者たちの憤怒は正当だった。方向が間違っていたにすぎない。機織り機が労働時間を延ばしたのではなかった。資本がそうした。機織り機が労働者を機械の付属物にしたのではなかった。資本がそうした。

LLMを使う同僚と生産性を比較され、望まないのに仕事のためにLLMを使うと言うソフトウェアエンジニアたちにとって、疎外の源泉はLLMではない。生計を特定の指標に縛りつけた構造だ。その指標は今や、最も速く最も多くの産出物を出す人に有利に働く。 LLMコーディングアシスタントは梃子であり、市場が機制だ。

ただ、ここは一点だけ分けて考えたい。匠人技術と効率のあいだの緊張は、資本主義を取り除いたからといって消えるものではない。 LLMがより速い産出物を出すという事実そのものは、誰が報酬を受けようと受けまいと有効だ。どんな共同体も、どんな方式で組織されようと、結局その速度の差をどう扱うかという問いを避けることはできない。資本主義はその問いに最も過酷な答えを与える。遅い方が生計を失う。しかし問い自体は資本主義より長く生き残る。

私の状況が示すもの

私は専業でオープンソースプロジェクトのメンテナンスをしている。収入は全面的に公的資金から得ている。 LLMコーディングアシスタントを使わなければ仕事を失うと言う雇用主はいない。私の生産性を同僚と比較する四半期評価もない。

こうした条件のもとで、私とLLMコーディングアシスタントの関係は、 Lawsonが描写するものとはかなり異なる。面白いと思うコードは依然として手で書く。したくない部分、冗長なテストスキャフォールディングや何百回も書いたボイラープレートは、モデルに渡す。この区分は自分で引いた線だ。何かを表現する仕事と、ただ処理しなければならない仕事のあいだの区分線。

Marxが資本主義の外で機械にできることとして想像したものに近い。反復労働から人を解放して、より創造的な活動のための時間を開くこと。技術が違うのではなく、条件が違うのだ。

私の状況を解法として提示したいわけではない。こうした状況は稀であり、依然として資本主義経済の中に存在する。一時的な避難所にすぎず、脱出ではない。ただ、同じ道具が一つの文脈では解放的に、別の文脈では疎外的に感じられるということ、その差異が道具ではなく社会的条件から来るということだけは確かだと思う。

悲しみが向かうべき場所

原因を知ったからといって苦痛が解消されるわけではない。今まさにLLMコーディングアシスタントを使うよう追い立てられているソフトウェアエンジニアたちに、構造分析は今日の午後を助けてくれない。

ただ、問いの立て方は少し変えられる。 Lawsonが描写する悲しみが実在するなら、そしてその悲しみのより深い原因が技術そのものではなくそれを取り巻く関係にあるなら、悲しみが向かうべき場所はLLMではない。望まない道具を望まない条件で使うよう強いているものが何かという問題だ。

Lawson自身も、このあたりまでは来ている。

私は新しい世界を祝福しないが、抵抗もしない。日が昇り日が沈み、私はその周りをどうしようもなく公転し、私の抗議はそれを止めることができない。

率直だが、諦念が私たちに残された唯一の道ではないと信じたい。

合法であれば正当か——AI再実装とコピーレフトの侵食

2026-03-09T15:10:00.000Z

合法であれば正当か——AI再実装とコピーレフトの侵食

先週、Pythonのテキストエンコーディング検出ライブラリchardetのメンテナーであるDan Blanchardが、新しいバージョンをリリースした。 chardet 7.0は従来比48倍の速度を誇り、マルチコアに対応し、設計から作り直されている。 AnthropicのClaudeが貢献者として登録されている。そしてライセンスがLGPLからMITに変更された。

Blanchardの説明によれば、彼は既存のコードを一切参照せず、 APIとテストスイートだけを手がかりにClaudeに一から再実装させた。 JPlagによる検証の結果、新しい実装と旧バージョンのコード類似度は1.3%未満だという。したがってこれは独立した新しい著作物であり、LGPLを継承する義務はない、というのが彼の主張だ。原作者のMark PilgrimはGitHubのイシューを立てて異議を申し立てた。 LGPLは修正版の配布に際して同一ライセンスの維持を要求するが、既存のコードに十分触れた状態での再実装はクリーンルームとは言えない、というのが彼の立場だ。

この一件は、Flaskの作者Armin RonacherとRedisの作者Salvatore Sanfilippo︵以下antirez︶の文章を通じて、より広い論争へと発展した。二人は異なる経路から——Ronacherはライセンス哲学の観点から、 antirezは著作権法の法理から——この再実装は正当だという結論に至る。私は両者の文章を尊重するが、どちらも間違っていると思う。いや、より正確に言えば、どちらも肝心な問いを回避している。

その問いとはこれだ。合法であれば正当か。両者の文章は、この問いに答えないまま、法理的に可能だという事実から社会的に正当だという結論を引き出す。法的な許容と倫理的な正当性は同じではない。法は最低限の基準を定めるだけであり、ある行為がその基準を通過するからといって、その行為が正しいということにはならない。この区別が本稿の出発点だ。

類比の方向が逆だ

antirezの論拠は歴史から始まる。 GNUプロジェクトがUNIXのユーザースペースを再実装したとき、それは合法だった。 Linuxカーネルも同様だ。著作権法は「保護される表現」︵protected expressions︶の複製を禁じるが、アイデアや動作の仕方は保護しない。 AIを使った再実装も同じ法的地形の上に立つ。ゆえに合法だ、というわけだ。

この法理の説明それ自体はおおむね正しい。再実装が合法だという主張を私は否定しない。問題はその次の段階にある。 antirezは合法性を示したところで議論を終える。しかし法理が正しいということと、行為が社会的に正当だということは別の主張だ。この二つを同一視するとき、論証に間隙が生まれる。

その間隙が最も鮮明に現れるのが、antirezが引いてきた歴史的な類比だ。

GNUがUNIXを再実装したとき、そのベクトルは独占から自由へと向かっていた。 StallmanはUNIXという独占ソフトウェアを自由ソフトウェアとして再実装するために、著作権法の限界を巧みに活用した。その再実装の倫理的な正当性は法的合法性から来るのではなく、コモンズを拡張する方向性から来ていた。それがGNUプロジェクトが歓迎された理由だ。

chardetの一件では、再実装のベクトルは反対を向いている。コピーレフト・ライセンスであるLGPLによって保護されていたソフトウェアが、パーミッシブ・ライセンスであるMITで再実装された。これはコモンズを広げる再実装ではなく、コモンズの囲い込みを解除する再実装だ。 chardet 7.0をベースにした派生物は、ソースコードを公開する義務を負わない。月間一億三千万ダウンロードというスケールのライブラリから、その義務が消えた。

antirezはこの方向の違いを論じない。 GNUの歴史を引いてきながら、その歴史が実は自身の結論に対する反証例になっていることを、見えていないのか見ようとしないのか。

GPLは共有に反するのか

一方、Ronacherの論拠は異なる。彼は自分が以前からchardetが非GPLライセンスになることを望んでいたと明かし、「GPLは共有の精神に反する」と書く。自分はできる限りライセンスの強制が少ない形で公開することを支持しており、社会は共有するほど良くなるという信念を持っているからだという。

この主張はGPLに対する根本的な誤解を含んでいる。

GPLが何を禁止するかから見てみよう。 GPLはソースコードを非公開にしておくことを禁じない。 GPLソフトウェアを個人的に改変して使用することに制約は一切ない。 GPLが条件を発動させるのは配布するときだけだ。改変したコードを配布したり、サービスとして提供するなら、そのコードも同じ条件で共有しなければならない。これは共有を制限することではなく、共有を条件として課すことだ。

「これを受け取って使い改善したなら、その改善も共有せよ」という要求は、共有を抑制するメカニズムではなく、共有を連鎖的に強制するメカニズムだ。コモンズの利用者にコモンズへの貢献義務を課すことが共有の文化を損なうという主張は、筋が通らない。

MITライセンスと比較すると差異は明確だ。 MITのもとでは、誰でもコードを持ち出して改善し、独占ソフトウェアとして閉じてしまうことができる。受け取ることは共有だが、貢献は任意だ。 Ronacherがこの構造を「より共有に親和的」と呼ぶなら、彼の言う「共有」は流れる方向が決まった共有だ。より多くの資本と人材を持つ側が持っていく方向に。

この非対称が現実でどう作動するかは歴史が示している。一九九〇年代、多くの企業がGPLコードを吸収して独占ソフトウェアを作った。それが可能だったのは彼らがパーミッシブ・ライセンスを選んだからではなく、当時コピーレフト・ライセンスの執行が緩かったからだ。 GPLの強化によってこの穴は塞がれた。貢献を通じた互恵性に頼るほかない個人開発者や小規模プロジェクトにとって、コピーレフトはかろうじて対等な交換を可能にする装置だった。

Flaskを作った人物がこの区別を知らないはずはない。にもかかわらずこの論拠を展開するなら、それはナイーブなのではなく、便宜的なのだ。

自己論駁する事例

Ronacherの文章で最も興味深い部分は論拠ではなく、ふと触れられる一文だ。 VercelがGNU BashをAIで再実装して公開したところ、 Cloudflareが同じ方法でNext.jsを再実装すると「あからさまに怒った」という話だ。

Ronacherはこれを皮肉として触れ、先へ進む。しかしこの逸話は彼の立場全体を崩す。それも思ったより徹底的に。 Next.jsはMITライセンスだ。 CloudflareのVinextはライセンスに違反したのではなく、 Ronacherが共有文化の前進と呼ぶ行為をそのままNext.jsに適用しただけだ。 Vercelの怒りはライセンス侵害に対するものではなく、純粋に競争的・領土的な反応だった。暗黙の立場はこうだ——GPLソフトウェアをMITに再実装することは共有文化の進展であり、自分たちのMITソフトウェアを同じ方法で再実装されることは許しがたい。これがパーミッシブ・ライセンス陣営のほうがコピーレフト陣営より「共有に親和的」だという主張の実態だ。「共有の精神」とは結局、自分が共有する方向にしか流れない。

Ronacherはこの矛盾を認識しながら立ち止まらない。自分の世界観に合致する事例だからだと書く。自身の立場を否定する証拠を自ら提示しておきながら結論を変えないとき、それは論拠が結論に先行しているのではなく、結論が論拠に先行しているというサインだ。

合法性と社会的正当性は異なる次元にある

冒頭の問いに戻ろう。合法であれば正当か。

antirezは法理を丁寧に説明した後、それで十分とばかりに筆を置く。 Ronacherは法的グレーゾーンを認めながら、道徳的な問題は「自分が関心を持つ部分ではない」と一文で片付ける。両者とも、法的な許容を社会的正当性の代理として扱う。だが法は、ある行為を妨げないと言うだけであり、その行為が正しいと保証しない。節税の限界ぎりぎりまで税を回避することが合法であっても、それが正しいかどうかは別の問いだ。特許を合法的に取得した企業が、数十年にわたって低廉に供給されてきた必須医薬品の価格を数十倍に引き上げることが合法であっても、それが社会的に正当だという意味にはならない。合法性は必要条件たりえても、十分条件ではない。

chardetの一件では、この区別はさらに鮮明だ。

LGPLが保護していたのはBlanchard一人の労働ではない。十二年間このライブラリに貢献してきたすべての人々が同意した社会的契約だ。その契約の内容は、「これを受け取って使うなら、あなたが作るものも同じ条件で共有せよ」というものだった。この契約は法廷が強制する種類の契約でもあるが、それ以前に、オープンソースのコミュニティが数十年かけて築いてきた信頼の基盤だった。再実装が法的に新しい著作物として認められうるということと、その再実装が既存の貢献者たちと結んだ社会的契約を破棄したということは、別々の問題だ。仮に法廷がBlanchardの主張を認めたとしても、それは彼の行為がコミュニティ的に正当であることを意味しない。合法性は社会的正当性を連れてこない。

FSFの代表Zoë Kooymanはこれを簡潔に言い表した。「自分が受け取った権利を他者に与えることを拒むことは、どんな方法によるものであれ反社会的な行為だ。」

誰の視点がデフォルトに設定されているか

この論争を読みながら、ずっと頭から離れない問いがある。二人の著者は、AI再実装のコスト低下をどこから見ているのか。

antirezはRedisを作り、RonacherはFlaskを作った。どちらもオープンソースのエコシステムの中心にいる人物だ。彼らの立場から見て、AI再実装のコスト低下とは、自分が仕掛ける側の話だ。何かをより簡単に再実装できるようになるということ。 RonacherはGNU Readlineをコピーレフトの条項ゆえに再実装しようとしていたと明言している。

一方、何十年もchardetのようなライブラリに貢献してきた人々にとって、同じ技術的変化は自分がされる側の話だ。自分の貢献が込められたコピーレフトの保護が剥がされるということ。二人の著者は前者の位置から後者の位置にいる人々に向けて、「これは常に合法だったし、歴史的先例もある、技術の変化に適応せよ」と言っている。

この非対称を無視して普遍的な論拠であるかのように書くとき、文章は分析ではなく利害関係の合理化になる。両著者がそれぞれ自身の利害関係と正確に一致する結論に達していることを、読者は念頭に置くべきだ。

この争いが指し示すもの

Bruce Perensは『The Register』とのインタビューで「ソフトウェア開発の経済学全体が死んだ」と警告した。 antirezは似た認識のもとで「適応せよ」と言う。 Ronacherはこの方向が気に入っていると言う。

三者の反応のいずれも、核心的な問いに答えていない。コピーレフトの執行が技術的に困難になったとき、それはコピーレフトを不要にするのか、それともより重要にするのか。

私は後者だと思う。 GPLが保護したのはコードの希少性ではなく、ユーザーの自由だった。コードの生産コストが下がったからといって、そのコードを通じて自由を侵食することが許容されるわけではない。むしろ再実装の摩擦が消えるほど、コピーレフト・ライブラリをMITに衣替えするコストも消える。 GPLが依存していた摩擦が減ったのは法的執行の問題であり、その根底にある規範的判断には触れない。

その判断とはこれだ。コモンズから取った者はコモンズに返すべきだということ。その原則は、再実装に五年かかろうと五日でできようと変わらない。法廷がAI再実装をクリーンルームと認めようと派生著作物と見なそうと、その判決がこの原則の社会的重みを軽減することはない。

これが法理とコミュニティの規範が分岐する地点だ。法は事後的に、ゆっくりと、現在の権力関係を反映しながら作られる。オープンソースのコミュニティが何十年もかけて積み上げてきた規範は、法廷の判決を待たなかった。法がそれを保護してくれないときでも人々がGPLを選んだのは、それが自分の属するコミュニティの価値観と一致していたからだ。その価値観は法が変わっても消えない。

以前の文章で私はこの争いの次の段階として訓練コピーレフト︵TGPL︶を提案した。 AI再実装の問題はそこからもう一歩進んで、仕様︵specification︶の層まで保護の範囲を拡張する必要があることを示唆している。ソースコードが仕様から生成できるのであれば、その仕様こそがGPLプロジェクトの本質的な知的財産となる。ソースコードを見ずにテストスイートとAPIだけで再実装したというBlanchardの主張は、逆説的に、そのテストスイートとAPI仕様がコピーレフトで保護されるべきだという論拠になる。

GPLの歴史は、新たな搾取の形式が現れるたびに法的ツールが進化してきた歴史だ。 GPLv2からGPLv3へ、そしてAGPLへ。だがその進化を先導したのは判決ではなく、コミュニティの価値判断だった。法はあとからついてきた。今もそれは変わらない。法廷がAI再実装についてどんな判決を下そうとも、私たちが先に答えるべき問いは法的なものではなく社会的なものだ。コモンズの実りを取った者はコモンズに返す義務があるか。私はそうだと思う。そしてその判断は法廷の判決を待つ必要がない。

antirezとRonacherの文章が興味深いのは、彼らが正しいからではない。彼らが何を見ようとしないかが、鮮明に浮かび上がるからだ。合法性によって社会的な価値判断を代替しようとするとき、本当に重要な問いは、法理の影の中に埋もれていく。

不完全な世界で唯物論的に行動すること——生産手段としてのLLMと社会的関係

2026-02-21T21:40:00.000Z

不完全な世界で唯物論的に行動すること——生産手段としてのLLMと社会的関係

この文章は先月書いたF/OSSの唯物史観——LLMを拒絶するのではなく、取り戻すべきだの続編である。

Cory DoctorowはPluralistic六周年記念の記事で、自身の執筆・公開ワークフローを紹介した。毎日記事を投稿する前に、OllamaというオープンソースのLLMを誤字脱字チェックに使っているという。予想どおりの反発が来た。そして二日後、ドイツの技術批評家tanteが不完全な世界で倫理的に行動すること︵Acting ethically in an imperfect world︶という文章で応じた。

彼のタイトルを借りることが、この文章の出発点として適切だと思った。不完全な世界で倫理的に行動するとはどういうことか——それが彼の問いだ。私は同じ問いに、別の枠組みで答えたい。倫理学ではなく、唯物論で。

以前の文章で私は、ライセンシングを奪還の手段として前面に出しすぎた。ナイーブだという批判を受け、その批判にはある程度首肯する。ただ、私が言いたかったのは奪還という方向であって、奪還の処方箋ではなかった。この文章では、その方向をもう少し正確に整理してみたい。

二つの藁人形

tanteの文章には妥当な指摘がある。Doctorowは、LLM批判者を技術の創始者が悪人だから使うべきではないという純粋主義者として描いた——これは藁人形だ。実際の批判はまったく別のところにある。膨大な電力と水の消費、同意なきデータ収集、グローバル・サウスで行われる搾取的なラベリング労働、オープンソース・エコシステムを含む知識コモンズへの損害……Doctorowはこれらの批判をSam Altmanが気に入らないだけという感情的な反応に還元してしまった。tanteがその還元の誤りを指摘したのは正しい。

Blueskyの指摘も有効だ。Doctorowは中央集権化に対するイデオロギー的な理由からBlueskyへの参加を拒否している。自分の価値観に基づいて技術を拒否することは可能だと信じ、実践している。それなのに、他者がLLMを同じように拒否すると純粋主義と呼ぶ。この二重基準もtanteが正確に突いた。

ところが、tanteも同じ罠にはまっている。

彼は奪還という方向を批判しながら、奪還の手段を事実上一つに限定する。GPTに匹敵するフロンティア・モデルをゼロから作ること。それには数十億ドルが必要で、同じ環境コストが発生するから、奪還は現実的ではない——というわけだ。しかしDoctorowがLLM批判を単純化したように、tanteも奪還の経路を単純化した。ライセンスを通じた法的抵抗がある。規制によって国家に私有モデルの公開を強制させる方向もある。公共基盤モデルを共同で構築する方向もある。どの手段が実際に機能するかは政治的・社会的条件に依存しており、まだ開かれている。以前の文章でライセンシングに言及したのは、そのなかで最初に思いついた一例にすぎなかった。

機械とその資本主義的適用形態

Marxは『資本論』第一巻で、イギリスのラッダイト運動をこう評した。

労働者が機械そのものと機械の資本主義的利用とを区別し、したがって物質的生産手段そのものではなく、その社会的搾取形態を攻撃することを学ぶまでには、時間と経験が必要だった。

機織り機を打ち壊した労働者たちの怒りは正当だった。方向が間違っていただけだ。問題は機械ではなく、機械をめぐる資本主義的社会関係だった——機械が労働時間を短縮するどころか延長し、労働者を解放するどころか機械の付属物にしてしまうのは、機械の本性ではなく、機械を配置する方式の問題だった。Marxは彼らを嘲笑したのではなく、闘争が成熟していく過程を叙述したのだ。

この枠組みは今日のLLM論争でも有効だと思う。tanteのアプローチは本質的に倫理的だ。LLMという技術そのものを道徳的に評価し、その評価に基づいて使用の可否を決める。Doctorowのアプローチもさして違わない。評価の方向が逆なだけで、どちらも技術を道徳の対象として置く。

唯物論的アプローチは別の問いを立てる。この技術はどのような社会的関係のなかに置かれているか。誰が所有し、誰の労働で維持され、その剰余はどこへ流れるか。そしてその関係を変えることができるか。

AI賛否という構図そのものが、この問いを覆い隠す。大手AIベンダーに批判的でありながらLLMという技術の可能性に開かれていることが矛盾して見えるのは、技術とその資本主義的適用形態が同一のものだという前提があるからだ。しかしその前提は誤っている。

図書館と人間

LLMは図書館ではない。図書館が人を原典へとつなぐのに対して、LLMは原典なしに答えを出すという批判は一面では正しい。ただ、LLMは人間に近いと私は思う。

人間も生涯をかけて膨大な量のテキストとコードと画像を吸収する。著作権者にいちいち許諾を求めない。それを自分のものとして消化し、ときには単なる切り貼りにすぎないものを出し、ときには誰も思いつかなかったつながりを生み出す。

AnthropicのNicholas Carliniは最近、Claude Opus 4.6を使ってRustでCコンパイラをゼロから書く実験を行った。インターネット接続なし、クリーンルームで。結果は、Linux 6.9カーネルをx86、ARM、RISC-Vの三つのアーキテクチャでビルドし、PostgreSQL、FFmpeg、SQLite、Redisをコンパイルし、GCCトーチャーテストスイートを99%通過する十万行のコンパイラだった。私の知る限り、Rustで書かれたCコンパイラでそれに匹敵する成果を上げた先例はない。誰かの成果をそのまま再生産したとは言えない。

もちろん、LLMが常に創造的なわけでも、人間が常に創造的なわけでもない。この比喩はLLMを美化するためのものではない。LLMは本質的に再生産しかしないという前提の上に築かれた批判の根拠が揺らいでいる、ということだ。

すべての生成AIが同じではないことも、この枠組みでよりはっきりと見えてくる。LLMと画像生成モデルの違いは、単なる技術の違いではなく、どのような労働をどのような方式で代替するかの違いだ。画像生成モデルが特定の作家のスタイルで画像を生成するとき、それは原作者の市場を直接侵食する。機能の代替ではなく、存在の代替だ。その剰余がどこへ向かうかを見れば、Marxの言う労働の窮乏化︵Verelendung︶が画像生成の領域でより直接的に進行していることがわかる。同じ尺度をLLMにそのまま適用できるかどうかは、はるかに複雑な問いだ。

デフォルトの視点

最後に、個人的な話を一つしたい。

tanteの文章はウェブで公開されているが、主要なLLMベンダーのスクレイピングをブロックするよう設定されているようだ。朝鮮語が母語の私にとって、英語は第二言語だ。tanteの文章のように、論証のニュアンスと暗黙の前提が重要なテキストは、従来の機械翻訳では正確に読めない。論証が生きたまま伝わるには、LLM程度の性能が必要だ。私は結局、文章を手動でコピーしてLLMに渡して読んだ。

tanteは、LLMが著者とのつながりを断つと言った。検索エンジンは人を原典へ案内するが、LLMは原典を抽出して利用者を自分のループの中に閉じ込める、というのだ。まったくの誤りではない。しかし私の経験は、その図式が誰の視点から描かれたものかを示している。英語に堪能な読者にとって、LLMはつながりを断つ技術かもしれない。しかし英語が不得手な読者にとって、LLMはつながりを可能にする技術でもある。tanteがLLMをブロックした行為は、彼自身の論理からすれば一貫しているが、結果として英語に堪能な読者とそうでない読者の間の非対称を強化した。

これが単純なアイロニーではない理由は、この非対称が技術言説の全体にわたって作用しているからだ。誰の視点がデフォルトに設定されているか。どのような社会的関係のなかでそのデフォルトが作られたか。

唯物論的に行動するとは、そのデフォルトを当たり前のものとして受け入れないことから始まる。技術が良いか悪いかを問う前に、この技術が誰のために、誰の労働によって、誰の利益のために動いているかを問うことだ。そしてその問いは、技術を拒否する理由ではなく、取り戻す理由になる——私はいまもそう思っている。

なぜ雪だるまを壊さないのか

2026-01-20T04:15:00.000Z

なぜ雪だるまを壊さないのか

冬になると、Xでこんな話を聞くことがある。道を歩きながらわざわざ雪だるまを壊して回る男たちがいるという。雪だるまを壊したからといって、誰かに実質的な損害を与えるわけではない。だが、そういう行為の中に何かが見える。ある種の倫理的態度の欠如、あるいは形成。

私は同じ理由で、LLMにタメ口を使わないし、命令口調で話さないようにしている。LLMが私の言葉遣いに傷ついたり、気分を害したりしないことは分かっている。しかし重要なのは、LLMの反応ではなく、自分がどんな人間になっていくかということだ。ぬいぐるみを投げたり叩いたりする人を想像してみればいい。ぬいぐるみは痛みを感じないが、そういう行動を繰り返す人は、少しずつそういう人になっていく。

こうした文脈で、AIやLLMについて奴隷制を連想させる表現を使うことにも違和感がある。「LLMを鞭打つ」といった表現が技術コミュニティで冗談のように使われているが、その中には奴隷制という歴史的暴力を軽量化された比喩として消費する態度が潜んでいる。LLMが実際に奴隷ではないのは当然だ。︵いや、当然だろうか？︶奴隷制を軽い比喩として使えると感じた瞬間、私たちはそれが指し示す実際の暴力に対する感覚を失っていく。

私たちが何をし、どう語るかが、結局私たちを作る。誰も見ていないところで、反応しない対象にどう振る舞うかが、むしろその人をより純粋に表すこともある。雪だるまであれ、LLMであれ、私たちが使う言葉であれ、それらすべてが私たち自身を形成する。

だから私は雪だるまを壊さない。LLMに敬語を使う。奴隷制を冗談の素材にしない。こうした小さな選択が私を作ると信じているからだ。

F/OSSの唯物史観——LLMを拒絶するのではなく、取り戻すべきだ

2026-01-16T06:00:00.000Z

F/OSSの唯物史観——LLMを拒絶するのではなく、取り戻すべきだ

数日前、「自由・オープンソースソフトウェアとLLM訓練について」︵On FLOSS and training LLMs︶という記事を読んだ。自由・オープンソースソフトウェアコミュニティの挫折感をよく表現した文章だった。AI企業はF/OSS開発者を全く尊重していない。オープンソースライセンシングの理想主義的原則を悪用している。法律は我々の成果物がプロプライエタリな言語モデルの学習データとして使われることを防いでくれない。記事を読みながら何度も頷いた。

しかし、結論には同意しない。

著者が提案する解決策は拒絶と孤立だ。クローラーを遮断し、GitHubのような中央集権的なforgeから離れ、AIスクレイパーが我々のコードにアクセスできないようにしようというものだ。そして、こうした「非倫理的なツール」を使う人々をコミュニティから排斥しようと言う。断絶と孤立の戦略だ。怒りは理解できる。しかし、このアプローチは重要な機会を見逃しており、F/OSSを作り上げてきた歴史的パターンを誤読している。

我々が同意する点

分岐点を論じる前に、著者が正しい部分から確認しよう。現在の状況は本当に深刻だ。AI企業は訓練データの出所を完全に無視している。「法的に可能だからやる」という言葉が、彼らが個々の開発者とコミュニティに対する態度を正確に示している。攻撃的なクローリングは事実上、分散型サービス妨害︵DDoS︶攻撃に他ならない。コンテンツ制作者の明示的な意思は無視される。まともに機能するオプトアウトメカニズムすら提供しない。

法的闘争も勝ち目が薄いという点で著者の言う通りだ。F/OSSライセンスは本質的に用途を差別しない。オープンソースの定義の第六原則は特定分野に対する制限を明示的に禁じている。GPLのような主要ライセンスは著作者表示を要求し、派生著作物に関する条項を設けているが、著者が指摘する通り、有能な弁護士ならLLM訓練は従来の意味での派生著作物の生成ではないと主張できる。統計的パターン抽出はコード再利用のように著作者表示を要求しないと。

現在の法律は不十分だ。この法律は別の時代のために作られた。その時代に「使用」とはソフトウェアを実行するか、修正するか、再配布することであって、ニューラルネットワークに入れてパターンを抽出することではなかった。法律は権力に奉仕する。この場合、権力は法務チームを動員してこうした曖昧さを探索し悪用できる企業にある。

我々が分岐する点

しかし、ここで道が分かれる。答えは拒絶ではなく再専有だ。

著者は現在の状況を開発者の尊重とAI訓練の許容の間の闘いとしてフレーミングする。しかし、第三の道がある。F/OSSの歴史とより整合的で、我々が実際に望む未来を作る可能性が高い道だ。我々のコードでLLMを訓練させないようにするのではなく、モデル自体を解放するよう要求すべきだ。

私の立場はこうだ。私は自分のコードがLLM訓練に使われることを望んでいる。望んでいないのは、その訓練によってAI企業の私有財産となるプロプライエタリなモデルが作られることだ。問題は技術自体や訓練プロセスではない。コモンズの私有化、集団知識の独占、価値が多数から少数へと一方向に流れることが問題だ。

これは全く新しい問題ではない。F/OSSがずっと闘ってきたその問題だ。服を着替えただけだ。

現実認識について

さらに進む前に、根本的な話をしよう。LLMをめぐる様々な見解は、大抵、現実そのものをどう認識するかで分かれる。

少し前、Redis作者のSalvatore Sanfilippo︵antirez︶がAIコーディングツールの体験談を書いた。彼は我々の多くと同様、手作りのコードとソフトウェアの人間的タッチを深く重視する人物だ。しかし、こう言う。「今起きている現実から目を背けることは不可能だ。コードを書くことはもはや大部分不要だ…プログラミングは永遠に変わった」

彼の結論はこうだ。適応せよ。新しいツールを学べ。「反AI」ハイプに陥るな。彼はLLMを九十年代のオープンソースのような民主化技術と見ている。小さなチームが大企業と競争できるようにするものだと。

私もantirezの現実認識には概ね同意する。LLMはプログラミングを根本的に変えた、そして元には戻せない。一方、〈自由・オープンソースソフトウェアとLLM訓練について〉の著者は現実を異なって認識しているように見える。抵抗が依然として意味があり、撤退が効果的でありうり、LLMの訓練データへのアクセスを有意義に減らせるという認識だ。私は懐疑的だ。OpenAIとAnthropicは既に必要なものを全て収集した。GitHubも全てのコードを持っている。訓練データは既に存在する。

しかし、ここで私はantirezの楽観論と分かれる。彼は中央集権化を懸念しながらも、中国産オープンモデルなどを通じた市場競争が解決してくれると信じているようだ。そして、開発者がどのように適応しこのツールを活用できるかに集中する。重要な話だが、より深い問いを避けている。この変革はどのような条件で起きるのか？

問いはLLMを使うか適応するかではない。その船は既に出た。問いは誰がモデルを所有するかだ。モデルを訓練したコモンズから誰が利益を得るのかだ。数百万のF/OSS開発者が自分のコードを公共に寄与したなら、結果として生まれるモデルがプロプライエタリであるべきなのか？これは単に中央集権化や市場力学の問題ではない。集団労働の果実が集団に残るか、私有財産になるかの問題だ。

唯物論的読解

自由・オープンソースソフトウェアの歴史を唯物論的レンズで見ると、明確なパターンが見える。技術変化が新しい形態の搾取を生み出し、その搾取はコモンズを保護するための新しい形態のライセンシングを要求する。

軌跡を見てみよう。

GPLv2︵一九九一︶はバイナリ配布問題を扱った。企業はGPLコードを取得してコンパイルし、バイナリのみを配布した。自由なコードから事実上プロプライエタリなソフトウェアを作ったのだ。解決策はコピーレフトだった。ソフトウェアを配布するならソースコードも提供しなければならない。

GPLv3︵二〇〇七︶はTivoizationを扱った。TiVoのような企業は技術的にはソースコードを提供したが、ハードウェアロックで修正版の実行を防いだ。解決策はソースコードだけでなくインストール情報まで要求することだった。ユーザーが修正する自由を維持できるように。

AGPL︵二〇〇七︶はSaaSの抜け穴を扱った。企業はソフトウェアを配布する必要がないことに気づいた。サービスとして実行するだけでGPLの配布要件が作動しなかった。解決策はネットワーク相互作用を配布と同等に扱うことだった。

毎回同じパターンが繰り返された。新技術が既存ライセンスの抜け穴を露呈させると、企業がその抜け穴を悪用した。するとコミュニティが抜け穴を埋める進化したライセンシングで対応した。これは理想主義が現実に出会って失敗したのではない。弁証法的発展だ。変化する物質的条件に合わせて我々の道具を精製する持続的過程だ。

今、また新しい間隙が見える。訓練の抜け穴だ。企業はF/OSSコードをプロプライエタリモデルの訓練データとして使える。モデルを公開したり訓練の出所を明らかにする義務もない。典型的な搾取だ。互恵性のない価値抽出だ。

唯物論的対応は新技術を拒絶することではない。ライセンスを進化させて包摂することだ。

訓練コピーレフトがどのような姿になりうるか

私はGPLv4やTGPL︵Training GPL︶のようなものを構想する。次のような条項を含むべきだろう。

訓練は明示的に許可される。コードは機械学習モデルの訓練データとして使用できる。F/OSSの自由の原則と整合的で、分野差別を避ける。

しかし、その結果物であるモデルは解放されなければならない。該当コードで訓練された全てのモデルは互換可能なコピーレフトライセンスで重み︵weights︶を公開しなければならない。GPLv3がバイナリにソースコードを要求するように、訓練コピーレフトは訓練されたシステムにモデル重みを要求する。

訓練データは文書化されなければならない。依存性を文書化することを期待するように、どのようなデータで訓練したかを明確にしなければならない。

ファインチューニングされたモデルも義務を継承する。コピーレフトモデルをファインチューニングすれば派生モデルも公開しなければならない。「少し修正して新しいものだと主張する」回避を防ぐ。

ネットワーク使用も義務を賦課する。AGPLのようにAPIでモデルを提供することも配布と見なして重み公開を要求する。

技術的挑戦と先例

これは技術的に可能なのか？執行できるのか？妥当な問いだが、新しい問いではない。以前の全てのGPL進化で同じように提起された問いだ。

バイナリがあなたのソースコードでコンパイルされたことをどう証明するのか？ハードウェアロックが修正を妨げることをどう証明するのか？サービスがあなたのコードを実行していることをどう証明するのか？毎回、答えは技術的証拠、コミュニティの監視、時には法的措置の組み合わせだった。完璧な執行は不可能だ。しかし、ライセンスが無価値だという意味ではない。GPL違反は起きるが、GPLは機能する。巨大なコモンズを作り保護してきた。

特定のコードが訓練に使われたことの証明は、ソースコードがバイナリに使われたことの証明より確かに難しいだろう。しかし、乗り越えられないものではない。訓練データセットは文書化できる。モデル系譜は追跡できる。統計分析が訓練の出所を特定できるかもしれない。より重要なのは、ライセンスの存在自体が遵守に向けた社会的・法的圧力を生み出すことだ。

混合訓練セットの問題もある。TGPLと非TGPLコードで共に訓練したら？これもGPLと非GPLコードをリンクする問題と類似している。数年間のコミュニティ実践と時折の法廷事例で解決されてきた。詳細は別の問題だが、大きな方向性は正しい。

なぜこれが撤退より重要なのか

著者の撤退戦略には感情的な訴求力がある。アクセスを拒否し、「あなたは我々を尊重しないから我々の成果物を持てない」と言うことには爽快感がある。しかし、いくつかの面でより大きな絵を見逃している。

まず、この戦略は戦場を大きく譲歩する。F/OSS開発者がコードを公開状態から撤退させれば、AI訓練を止めるのではなく、オープンソースAI訓練だけを止める。OpenAIとAnthropicは既に必要なものは全て収集し、巨大なデータセットを持っている。撤退が止めるのはLlamaやMistralのようなプロジェクトとより広いオープンソースLLMエコシステムが良質な訓練データにアクセスすることだ。

より根本的には、問題を誤って捉えている。技術自体ではなく、それを誰がどう使うかが問題なのに。LLMはコンパイラやWebサーバーが本質的に搾取的でないのと同様、本質的に搾取的ではない。単なる道具だ。資本主義下の全ての道具のように、権力を集中させるか分散させるかに使われうる。使用条件ではなく拒絶に集中すれば、病気ではなく症状だけを治療する危険がある。

コミュニティ分裂の危険もある。著者は「非倫理的ツール」の使用者を排斥し、歓迎されないようにし、孤立させようと言う。しかし、どこまでが使用なのか？誰かがF/OSSプロジェクトのパッチを作成するのにGitHub Copilotを使ったら？デバッグにChatGPTを使ったら？正確にどこが線で、それを誰が決めるのか？こうした純粋性テストは歴史的に目標達成より運動分裂により効果的だった。

しかし、最も致命的なのは、実際に機能してきたF/OSSの戦略を放棄することだ。アクセスを止めるのではなく、ライセンスで自由を守る戦略を。GPLの天才性は誰にもコード使用を止めなかったことだ。代わりに、受け取った自由を他者にも与えるよう要求して全員の自由を保障した。撤退は正反対の哲学だ。

我々が作るべき未来

私は強力なAIモデルが存在し、訓練する余力のある民間企業だけでなく全員がそのようなモデルにアクセスできる未来に住みたい。数百万のF/OSSプロジェクトにエンコードされた知識がプロプライエタリモデルに私有化される代わりにコモンズの一部となる世界を望む。私のコードがモデル訓練を助けるなら、そのモデルを私と他の全員が使用し研究し修正し共有できる世界を望む。

この未来は撤退からは来ない。参加から、我々のライセンシングツールの進化から、我々が見たいオープンソースAIエコシステムを構築することから来る。GNU/Linuxを作り、我々が知るWebを作り、我々が毎日使うツールを与えたのと同じ戦略から来る。

著者は尊重は与えられるものではなく得るものであり、我々を無視する者には同様に対処すべきだと書く。私もこの原則には同意するが、異なって適用したい。無礼なのは訓練行為自体ではなく、その結果物を私有化し共同体に返さないことだ。適切な対応は我々も共有を拒絶することではない。それは底辺への競争だ。互恵性を要求し、我々が常に主張してきたまさにその自由を主張することだ。

Linus TorvaldsがLinuxをプロプライエタリとして維持する代わりにGPLで公開したとき、「企業はこれを使えない」とは言わなかった。「誰でも使えるが改善したら共有しなければならない」と言った。その条件、その互恵性の要求が、ボランティア開発者と巨大企業を共に含むエコシステムを作った。スマートフォンからスーパーコンピューターまで全てを動かし、共に作る方式が実際に機能することを証明したエコシステムを。

AI時代にも同じ原則を適用すべきだ。「我々のコードで訓練禁止」ではなく、「我々のコードで訓練するならモデルを解放せよ」と。撤退ではなく、参加条件だ。拒絶ではなく、再専有だ。

歴史的機会

唯物史観は必然性に関するものではないと思う。パターンを認識しそれに従って行動することだ。F/OSSライセンシングの全ての主要な転換は、問題認識、コミュニティ議論、法的革新、漸進的採用のパターンに従った。LLMに関しては現在、そのサイクルの始点にいるようだ。

機会だ。現在、AI訓練とモデル公開を支配する規範についての対話が起きている。コミュニティではこれらの問題についての議論が熱い。オープンソースAIモデルが増えている今、どのライセンスが適用されるかはまだ定まっていない。

F/OSS開発者がこの対話から撤退し、戦場を譲歩し、拒絶だけに集中すれば、五年後には企業と企業寄りの裁判所によって全ての規範が設定されているのを見ることになるだろう。訓練の抜け穴が確固として確立され、オープンソースAIはプロプライエタリモデルと比べて永久に不利になるだろう。

しかし、我々が参加し、訓練コピーレフトを推し進め、モデル解放を要求するライセンスでコードを公開し始めれば、我々がその未来を作れる。簡単ではないだろう。法的作業、コミュニティ組織化、恐らく法廷事例も必要だろう。GPLがテストされ検証されるのに数年かかった。しかし、結局機能した。訓練コピーレフトが機能しない理由はない。

結論

「自由・オープンソースソフトウェアとLLM訓練について」に表現された怒りと挫折を尊重する。現在のAI企業が悪く行動しており、我々の成果物を搾取しており、法律が不十分だという点で、著者は正しい。私の異論は、我々の対応が拒絶ではなく進化であるべきであり、撤退ではなく参加であるべきであり、アクセス禁止ではなくライセンシング革新であるべきだと信じる点だ。

問いはF/OSSコードに対するLLM訓練がある抽象的意味で倫理的かではない。どのような条件で倫理的かだ。答えはF/OSSがこれまで示してきた答えと同じだと信じる。我々が付与する自由が保存され伝達されるとき、改善がコモンズに戻るとき、知識が自由に留まるとき、倫理的なのだ。

クローラーを遮断するのではなく、彼らがクロールする規則を変えるべきだ。GitHubから撤退するのではなく、GitHub訓練がコピーレフトを尊重するよう要求すべきだ。AIツール使用者を排斥するのではなく、我々の自由を尊重するより良いAIツールを作るべきだ。

唯物史観は教える。新しい生産力は新しい生産関係を要求すると。LLMは新しい生産力だ。訓練コピーレフトはLLMをF/OSSの価値と整合させる新しい生産関係となるだろう。

私が書くコードは自由であるために書く。ニューラルネットワークを通過してモデル重みとして現れても、自由に留まることを望む。純真な理想主義ではない。数十年間F/OSSを導いてきたまさにその原則だ。我々は複数の技術転換を経てソフトウェアの自由を保護してきた、今回もできる。

LLMを拒絶するのではなく、取り戻すべきだ。我々のコモンズが彼らの私有地になるのを傍観するのか？私はコードが全員のものであるように、それで訓練したAIモデルも全員のものとなる未来のために闘いたい。

フェディバースと過ごした二〇二五年

2025-12-09T15:00:00.000Z

フェディバースと過ごした二〇二五年¹

昨年も「フェディバースと共に過ごした一年」というタイトルの記事を書いたが、今年も似たようなテーマでまた記事を書くことになった。専業でフェディバース︵fediverse︶²関連のオープンソースソフトウェアを開発するようになったこともあり、この仕事を続ける限り、毎年このような記事を書くことになりそうだという気もする。

『Thinking Penguin Magazine Vol.0』

日本のフェディバース開発者の集まりであるFediLUGが初めて発行した同人誌『Thinking Penguin Magazine Vol.0』に微力ながら寄稿することになった。私が書いた原稿は「国漢文混用体からHolloまで」という記事で、どのようにして Fedify³とHollo⁴を作ることになったのかを扱った。この雑誌は第十一回技術書同人誌博覧会にも出品されたとのことだが、私は余裕がなくて直接観覧はできなかったものの、出品に参加できただけでも貴重な経験となった。

BotKit

今年の初めにはFedifyをベースにしてBotKitというActivityPubボットフレームワークを作った。最初は何かフェディバースのボットアカウントを作りたかったような気がするが、正確に何だったかは今では思い出せない。

とにかく、BotKitはMastodonやMisskeyのようなActivityPubサーバーにアカウントを作って Mastodon APIやMisskey APIを利用してそのアカウントに投稿をする方式の限界を感じて始めたプロジェクトで、 BotKitアプリ自体が一つのActivityPubサーバーとして機能する構造になっている。そのような構造のおかげで、投稿の最大文字数やレートリミット︵rate limit︶などの様々な制約から自由だという利点がある。

作って公開した後、BotKitで作られたいくつかのフェディバースボットが生まれたが、実はまだそれほど多くは使われていない。

Hackers’ Pub

Hackers’ Pubというソフトウェア開発者のためのActivityPubベースの招待制コミュニティを昨年末に作ったが、今年になって多くの方々から関心を頂き、本当に多様なソフトウェア開発者の方々と交流する機会ができた。特に、李在烈（イ・ジェヨル）さんが熱心にHackers’ Pubを宣伝してくださったおかげで、多くの方々がHackers’ Pubに来られるようになった。

夏にはデザイナーの朴恩智（パク・ウンジ）さんにHackers’ Pubのビジュアルアイデンティティを依頼し、とても可愛い猫のロゴが誕生することになった。この猫は幸いにも Hackers’ Pubにいらっしゃる多くの方々に愛され、パブにゃんこという愛称まで得ることになった。パブにゃんこデザインを活用してTシャツやステッカーも制作したが、皆さんの反応がとても良くて嬉しかった。

もしこの記事を読んでHackers’ Pubに興味が湧いた方がいらっしゃれば、招待できますので個人的にご連絡ください。

『Software Sessions』出演

今年の春には良い機会があり、Jeremy Jung氏がホストする『Software Sessions』インターネットラジオに出演し、ActivityPubと Fedifyについて話すことができた——「Hong Minhee on ActivityPub」。ただし英語で進行されたため、かなり緊張してしどろもどろになってしまったことが後悔として残る。英会話をもっと練習しなければという思いもした。︵しかしいつもそうであるように、思うだけで実行には移せなかった…︶

『私たちのコードを探して』出演

生まれて初めてYouTubeにも出演することになった。朴賢宇（パク・ヒョヌ）さんが運営されるハル開発チャンネルの『私たちのコードを探して』︵우리의 코드를 찾아서︶シリーズに「民憙さんとFedify & Holloについて学ぶ」︵民憙 님과 Fedify & Hollo 알아보기︶編で出ることになったのだ。どのようにFedifyと Holloを作ることになったのか、その誕生秘話を気楽な雰囲気で語ることができた。

オープンソースコントリビューションアカデミー︵OSSCA︶

韓国政府機関である情報通信産業振興院︵NIPA︶傘下のオープンソースソフトウェア統合支援センター︵Open UP︶が主催するオープンソースコントリビューションアカデミー︵以下OSSCA︶二〇二五年度参与型プロジェクトとしてFedifyが選定された。これを機に本当に多様な優秀なコントリビューターの方々とご縁ができた。合計90名以上の方々が志願してくださり、その中から20名余りの方々と一緒にFedifyプロジェクトを進めることができた。

実際にFedify 1.8及びFedify 1.9はOSSCAを通じて出会ったコントリビューターの方々がいなければリリースできなかったほど、多くの貢献をしてくださった。

特に、李在烈（イ・ジェヨル）さん、李璨行（イ・チャンヘン）さん、金炫舒（キム・ヒョンソ）さん、権祉源（クォン・ジウォン）さん⁵はOSSCA期間が終わった後も継続的にFedifyに貢献してくださっており、本当に心強い。この縁で十一月には皆で福岡に旅行に行くこともできた。

Fedify投資誘致

昨年の夏にGhostのFedifyへの資金支援を受けてしばらくの間フルタイムでFedifyプロジェクトに専念することができたが、それも今年の第一四半期で終わり、振り出しに戻った。新しい資金源を探すために今年の春にNLnetに申請書を出したが、残念ながら落選し、就職することまで考えていた矢先に、幸いにも申請していたSTFに出した申請書が通過することになった。むしろNLnetから受けられる投資金よりもはるかに余裕のある金額を投資してもらえることになったので、転禍為福となったわけだ。これについては「STFのFedifyへの投資」という記事で詳しく書いた。

とにかく、ありがたいことにこれから一年間フルタイムでFedifyプロジェクトに集中できるようになった。

各種発表

今年は様々な集まりやカンファレンスで発表する機会が多かった。

今年初めてした発表は四月初めに開催された第八回FediLUG勉強会⁶でのもので、先に述べた『Thinking Penguin Magazine Vol.0』に寄稿した記事「国漢文混用体からHolloまで」と同じタイトルで発表した。内容は記事とほぼ同じだ。日本に行く余裕がなかったため、発表自体はオンラインで行った。

その次にした発表も日本でのもので、八月初めにOSC 2025 京都で開催された「フェディバースのつくりかた—開発者・管理者たちの現場から」セミナーで「BotKit by Fedify〜誰でも簡単に作れるActivityPubボット」というテーマで発表した。この時も京都まで行く余裕がなかったのでオンラインで参加した。

秋には今年初開催となる韓国の自由・オープンソースソフトウェアカンファレンス FOSS for All カンファレンス 2025で「ヤクシェービング——新しいオープンソースの原動力」︵야크 셰이빙: 새로운 오픈 소스의 原動力︶というテーマで基調講演をすることになった。この発表は日本でした発表である「国漢文混用体から Holloまで」を基に、私が作ったオープンソースプロジェクトの中でフェディバースと関係ないものまで一緒に扱ったものだ。

冬には韓国の関数型プログラミングカンファレンスであるliftIO 2025で「Optique——TypeScriptの型推論でCLIバリデーションを代替する」︵Optique: TypeScript의 타입 推論으로 CLI 有效性檢查를 代替하기︶という発表をした。今年私がした発表の中では唯一フェディバースと関連のない発表だった。

一年を締めくくりながら

大したことをしていないと思っていたが、いざ整理してみると意外にあれこれしたことが多い一年だった。STFからの投資は来年末まであるので、おそらく来年もFedify プロジェクトを中心にフェディバースと関連した多くの活動を続けることになりそうだ。個人的にはActivityPubとフェディバースの状況が—XがElon Muskの手中に落ちたにもかかわらず—まだ盤石ではないことが心配だが、来年には状況がもう少し良くなることを願う。

Fediverse Advent Calendar 二〇二五の十日目の記事。 ↩
分散型ソーシャルメディアネットワーク。様々なソーシャルメディアソフトウェアやサービスがW3Cの勧告であるActivityPub プロトコルを実装し、相互に通信可能にすることがポイントである。 ↩
TypeScriptで作成されたActivityPubサーバーフレームワーク。 ↩
Fedifyの上で作られた一人ユーザー用ActivityPubサーバー。一人で使うには Mastodonが重すぎて不要な機能が多いため、作ることになった。 ↩
五十音順。 ↩
日本のFediLUGで隔月で開催する勉強会。 ↩

STFのFedifyへの投資

2025-10-03T12:00:00.000Z

STFのFedifyへの投資

昨年、FedifyがGhostから資金支援を受けてから、しばらくの間フルタイムでFedifyプロジェクトに専念することができた。契約期間が終了した後も、GhostはOpen Collectiveを通じて一定のスポンサーシップを続けてくれたが、 Fedifyだけを専業でやれるほどではなかった。GhostのCEOから、もっと安定した資金源を確保してはどうかとアドバイスをもらい、いろいろな財団が運営する投資プログラムに申請書を出すことになった。それが今年の春のことだ。

NLnet

最初に申請したのはNLnetだった。NLnetはフェディバースにも関心が高く、ファンドの規模もかなり大きい。何より、周りのActivityPub関連のオープンソース開発者たちがNLnetを薦めてくれたのが大きかった。

しかし、NLnetに送った申請書は落ちてしまった。後で分かったことだが、 NLnetは資金を受けるプロジェクトのメンテナーの中にヨーロッパ市民が一人くらいはいないと、採択される確率が低いという話を聞いた。もちろん、単純にそういう理由ではなく、私が書いた申請書が水準に達していなかったからかもしれない。

申請書を出したのは一月末で、不採択通知を受けたのは五月中旬だった。その間にGhostとの契約は終わり、無職になっていた。収入が別になかったので、就職するか他のファンドを探すかしなければならなかった。

Sovereign Tech Fund

次に申請したのは、 Sovereign Tech Agencyが運営するオープンソース投資ファンドであるSovereign Tech Fundだった。STFは主に、他のソフトウェアを開発したりデジタルネットワーキングを可能にするのに不可欠なオープンソースプロジェクトに投資しているという。プロジェクト一覧を見ると、Servo、systemd、Babel、FreeBSD、Samba、GNOME、 FFmpegなどのプロジェクトに投資したことが分かる。

すでにNLnetで一度落ちて自信がかなり落ちていた状態だったが、心機一転して申請書を丁寧に作成して提出した。メールを探してみると、 NLnetから不採択通知を受けたその日にSTFに申請したようだ。

今回も返事はかなり遅かった。収入がなくて貯金を使って暮らしていたが、二ヶ月が過ぎても返事が来なくて、心がかなり焦った。ほぼダメだろうと思っていたので就活も一緒に準備したが、去年一年間専業でオープンソース作業だけをした経験があまりにも良かったので、就活が手につかなかった。

ありがたいことに八月初めに返事が来て、驚くことにFedifyプロジェクトがSTFに合格した！その後はメールで書類をやり取りするうちに二ヶ月がさっと過ぎた。そしてついに昨日、FedifyのSTFプログラムに着手することになった。私はこれから、STFに申請する時に自分で決めたマイルストーンを達成するたびに資金を受け取ることになる。総額は€192,000で、すべてのマイルストーンは来年末までに完了しなければならない。

STFのFedifyへの投資についてはSovereign Tech Agencyのウェブサイトに掲載されており、今後遂行すべきマイルストーン一覧はFedifyプロジェクトの告知文に書かれている。

STFの資金源がドイツから来ているからか、欧州連合のウェブサイトにFedifyプロジェクト投資についての事前公告 (ex-ante) が載ったのもなかなか興味深かった。

所懐

今回このようにFedifyプロジェクトの資金源確保のためにいろんなファンドを探し回りながら感じたのは、韓国にもオープンソースプロジェクトに投資する公的ファンドがあれば本当にいいのにという思いだった。特に、NLnetに出した申請書が落ちた時、そんな思いを本当にたくさんした。幸い私は国籍を問わずオープンソースプロジェクトに投資してくれるSTFから資金を受けることができたが、最初から韓国にSTFのような投資プログラムがあったら、ずっと楽だっただろうし、私以外にも韓国にいる多くのオープンソース開発者たちが彼らのプロジェクトに専念できる機会が与えられただろう。

また、まだFedifyには私以外に共同メンテナーが別にいないので今回は一人で資金を受けることになったが、来年末に再びファンドを探すことになる時までは、他の共同メンテナーの方々をお迎えして一緒に専業オープンソースプロジェクトができたらいいなという夢を持つようになった。

オープンソース開発の近況

2025-09-12T11:10:00.000Z

オープンソース開発の近況

気が付けば最近かなり多くのオープンソースプロジェクトを作ることになったので、近況報告を兼ねて、進行中のオープンソースプロジェクトを文章に纏めてみる。各プロジェクトは何らかの形でお互いに関係している。

Hollo

実は最近私が作ることになったオープンソースプロジェクトの出発点となったのが、まさにこのプロジェクトだ。Elon MuskがTwitterを買収してXに名前を変えてから、もともと使っていたMastodonをさらに熱心に使うようになったのだが、漢字ハングル混じり文、所謂「国漢文混用体」で投稿を書いていると他の人が読みづらくないかと気を使うようになった。そこでSeonbiを使って漢字ハングル混じり文をハングル専用文に変換する機能をMastodonに追加することも考えたが…私以外誰も使わなさそうなこの機能をMastodonのアップストリームに入れるのはさすがに無理がある。となるとダウンストリームパッチを維持しながらMastodonサーバーも自分で運営しなければならないということになるが、 Mastodonは重いことで有名なのでそうしたくはなかった。そこで御一人様向けの軽量ActivityPub実装を作ろうと思ったのがHolloだ。一人で使うActivityPubサーバーソフトウェアなので、韓国語で「一人で」という意味の「홀로（ホロ）」と名付けた。

ドッグフーディングに成功し、現在は私のフェディバースアカウントをHolloに移行した。フェディバースのハンドルは@hongminhee@hollo.social。漢字ハングル混じり文で思う存分投稿を書いており、漢字の上にハングルの読み仮名が<ruby>タグで付いている。

実はドッグフーディングを達成してからは、私にとって必要な機能は全て実装されたので、バグ修正などメンテナンス中心の作業となっている。

Fedify

前述のHolloを最初に実装する際は、 ActivityPub実装を一から作ろうと試みた。しかし作っているうちに、ActivityPub実装のコードが思ったより厚く、やることが多いと感じた。そこでHolloの開発を中断してActivityPubサーバーフレームワークを作ることにしたのがFedifyだ。作って半年も経たないうちにGhostから資金支援を受けることになり、その後しばらくフルタイムでFedifyプロジェクトに取り組むことになった。現在は韓国の情報通信産業振興院傘下のオープンソースソフトウェア統合支援センターが主催するオープンソースコントリビューションアカデミーの参与型プロジェクトに選定され、優秀なメンティーの方々と一緒にプロジェクトを進めている。

Fedify以前にもActivityPubサーバーフレームワークがなかったわけではない。しかし、どれも私が必要とする抽象化レベルを提供していなかった。或るものはWebFingerや署名アルゴリズム程度しか提供しない小さなライブラリに近く、また或るものはほぼMastodonと比較できるような、フレームワークというより完成されたソーシャルメディアプラットフォーム実装に近かった。例えるなら、HTTPライブラリやWordPressのようなCMSはあっても、 RailsやDjangoに近いフレームワークがなかったのだ。

Fedifyを作る際に念頭に置いた目標は以下の通り。

できるだけ多くの開発者が使えるようにする。
データベースやストレージに依存しない。アプリケーション開発者が使いたいデータベースを使えるようにする。
ActivityPubプロトコルを活用する方法に制約がないようにする。例えば、マイクロブログのような完成されたアプリケーションの形を前提としない。
ActivityPubを実装するなら備えるべき全てのもの——認証、署名、アウトボックスおよびインボックスキューなど——を一切提供する。
ActivityPubをよく知らない人でも使えるほど豊富なドキュメントを提供する。
型安全でなければならない。

そして、この記事を書いている現在、以上の目標はほぼ達成出来たと思う。結果的にHolloはFedifyベースで作られることになり、その他にも——後述する——Hackers' Pub、Ghostなどが Fedifyを使ってActivityPubを実装することになった。また、まだ完成していないがKosmo、 CosmoslideなどのプロジェクトがFedifyを使ってActivityPubを実装している。

LogTape

Fedifyにログシステムを追加しようとJavaScriptで作られたログライブラリを探してみたが、私が望む条件のライブラリがなかったので新しく作ることになったのがLogTapeだ。

私が望む条件というのも大したものではなかった。ただPython標準ライブラリのloggingモジュールに相当するものを探しただけなのだが、振り返ってみるとloggingモジュールがかなりよく出来たものだったようにも思える。私が望む条件は以下の通りだった。

ライブラリでログを残すが、アプリケーションでライブラリのログ出力を制御できるようにする。アプリケーションで出力設定を別途しない限り、ライブラリのログはどこにも出力されてはならない。
ロガーが階層的に管理されるべき。上位ロガーにインストールされた出力先は下位ロガーにも適用されるべき。
出力先は実装しやすいインターフェースでなければならない。
型安全でなければならない。
Node.js、Deno、Bun、エッジ関数、ウェブブラウザなど様々なJavaScriptランタイムで幅広く動作する。

概してアプリケーションではなくライブラリでログを残すために必要な条件だった。どうせFedifyで使うために作ったので、作った後放置していたが、去年の秋を過ぎてから、なぜか口コミで広まって多くの人が使うようになった。

Hackers' Pub

ソフトウェア開発に関する記事を投稿するブログを作りたくて[velog]¹を少し使うようになったが、 ActivityPubをサポートしていないのが残念で、 velogのイシュートラッカーにイシューを残すことになった。幸いにも前向きに検討するという返答を受けたが、制作陣の方々が忙しくてその後音沙汰がなかった。結局私が自分でActivityPubをサポートするソフトウェア開発者のためのソーシャルメディア兼ブログプラットフォームを作ってみようと思ったのがHackers' Pubだ。

去年の冬に初めてオープンしてからすぐに李在烈（イ・ジェヨル）さんが参加されたが、招待制にも拘わらず、李在烈さんがあちこちでものすごく熱心にHackers' Pubを宣伝してくださったお陰で、かなり多くの方が参加して活動されるようになった。短期的な目標は韓国で広く使われるようになることで、さらに中長期的な目標は東アジア全般と英語圏を網羅することだ。しかし、まだ大部分のコンテンツが韓国語で書かれており、少数の日本人の方が間欠的に日本語コンテンツを投稿してくださる程度だ。

Fedifyを通じてActivityPubを実装したので、当然Hollo、Mastodon、 Misskeyなどと通信が可能で、Xのように投稿——Note——を書くことも出来、長い記事——Article——を書くことも出来る。絵文字リアクションや引用のようなMastodonにはない機能も提供している。

そしてHackers' Pubのもう一つの自慢は、安全で平等なコミュニティを作るための行動規範だ。特に私が最も気に入っている文言は次の通り。

差別的な発言と、差別に対抗する発言を区別します

技術的な側面では、もともとDenoとFreshを使って作っていたが、現在はウェブフロントエンド開発に造詣が深い申義河（シン・ウィハ）さんの協力を得てGraphQLとSolidStartベースに移行している。²

ソースコードはAGPL 3.0でGitHubに公開されている。実際にかなり多くのHackers' Pub会員の方々が不便な点を自ら修正するプルリクエストを送ってくださっている。

ちなみに私のHackers' Pubアカウントは@hongminhee@hackers.pubだ。

Upyo

Hackers' Pubを作りながらメール送信が必要になったが、メールプロバイダーを簡単に切り替えられるメール送信ライブラリを探していて、気に入るものがなかったので作ることになったのがUpyoだ。韓国語で切手を意味する単語「郵票（ウピョ）」から名前を取った。

もともと.NET系のFluentEmailのようなものをJavaScriptエコシステムで探していたが、意外にも適当なものがなくて驚いた。メールプロバイダーを切り替えたり冗長化したりすることは思ったよりあまりないのだろうか？

LLMベースのコーディングエージェント³を本格的に使った最初のプロジェクトでもあった。それでもまだLLMの能力にそれほど期待していなかったため、設計と初期コーディングは自分で行い、後でトランスポートの種類を増やす際にLLMの助けを多く借りた。作るのに2日かかったと思う。コーディングエージェントの驚くべき生産性が印象的だった。

私が作った他のライブラリと同様に、Node.js、Deno、Bun、エッジ関数、ウェブブラウザなど様々なJavaScriptランタイムをサポートしているのも特徴だ。

Optique

Fedifyはフレームワークでもあるが、fedifyコマンドというCLIツールも提供しているが、以前はDeno専用CLIフレームワークのCliffyをそれなりにうまく使っていたが、 Deno以外にNode.js、Bunなどをサポートする必要が出てきて⁴、 Cliffyの代替を探すことになった。しかし今回も同じパターンで…気に入るものが見つからなかった。

実は私の心の中には、既に理想に近いCLIパーサーライブラリが存在していた。ただそれがoptparse-applicativeというHaskellライブラリだったため、 Fedifyでは使えなかっただけだ。このoptparse-applicativeというライブラリのアイデアはシンプルだ。 CLIパーサーもパーサーなのでパーサーコンビネーターで作ろうというものだ。

とにかく、欲しいCLIパーサーライブラリが見つからなかったので自分で作るしかない。それで作ったのがOptiqueだ。

最初はoptparse-applicativeとほぼ同じようにポーティングしようとしたが、やはりHaskellとJavaScriptではDSLを構成する表現力に大きな差があった。そこで悩んだ末に、 TypeScript開発者に既に馴染みのあるZodのようなバリデーションライブラリのAPIを参考にすることにした。

Upyoプロジェクトとは違い、 LLMコーディングエージェントはごく限定的にドキュメント作成やテストコード作成などに使用し、そのせいか作るのに一週間以上かかったと思う。

作ってみると、 JavaScriptエコシステム内ではかなりユニークなCLIパーサーライブラリが出来たと自評出来た。勿論、多くのCLIアプリケーションがそれほど複雑なオプションを受け取るわけではないが、ある程度規模のあるCLIアプリケーションを作るならOptiqueを使っても後悔しないと自負している。

あ、そして前述した他のライブラリと同様に、Node.js、Deno、Bun、さらにはエッジ関数やウェブブラウザでも動作する。そんな必要があるのかと思うが、ただの自己満足というか。ただし、お陰でテストがとても書きやすいライブラリになった。

ヤクシェービング

考えてみると、私のオープンソース開発の原動力はヤクシェービングから来るのではないかと思う。 Anthony Fuの「ヤクシェービングについて」という記事を読んだことがあるが、モチベーションを得る方法が私ととても似ているという印象を受けた。何かが不便でツールを作ろうとすると、それを作る途中でまた不便さを感じてそれを解決するツールを作ることになる。それで元々やろうとしていた最初のことは出来なくなる場合が多いが、だからといって途中で作った副産物がどこかに消えるわけではない。

私も最初に戻って考えてみると、結局やりたかったのは漢字ハングル混じり文でフェディバースに投稿を書きたかったのだが、そのためにHolloも作り、Fedifyも作り、LogTapeも作り、Optiqueまで作ることになった。そうしながらやりたい他のことが新しく生まれ、Hackers' Pubのようなコミュニティを通じて多くの貴重な縁も結ぶことが出来た。あ、それで元々やろうとしていたフェディバースで漢字ハングル混じり文で投稿を書くことは去年末に達成することが出来た！前述した副産物以外にもMastodonやMisskeyなどにパッチを送る必要はあったが。⁵

2年余りの期間に起きたことだが、とても楽しく豊かな旅路だったと思う。これからもしばらくはフルタイムでオープンソース開発をすることになりそうだが、私に与えられた恵みに感謝しながら奮起しなければ。

韓国で広く使われているソフトウェア開発者向けのブログプラットフォーム。日本のQiitaやZennと似た位置づけ。 ↩
いろいろな理由でDenoを使ったことを後悔しているが、仕方なくDenoは移行後も使い続けている。 ↩
Claude Codeを使った。 ↩
Fedifyフレームワーク自体は既にNode.js、Deno、Bun、 Cloudflare Workersなどをサポートしていたが、 CLIツールのfedifyコマンドだけはDeno専用で作られていた。 ↩
投稿を受け取る側でも<ruby>タグをレンダリング出来る必要があったからだ。 ↩

フェディバースと共に過ごした一年

2024-12-23T15:00:00.000Z

フェディバースと共に過ごした一年¹

二〇二四年は、本当にフェディバースに夢中になって過ごした一年だった。フェディバースとActivityPubに関連する大小様々なプロジェクトを進め、その中のいくつかは多くの人々から好評を得る事が出来た。良い思い出として記録に残しておこうと思い、この文章を書く事にした。

フェディバースとは

先ず、フェディバース︵fediverse︶とは何かを簡単に説明すると、異なる種類のソーシャルメディアが相互に通信出来るネットワークの事を指す。詰まり、全く異なるソーシャルメディア上の二つのアカウントが相互にフォローし、コメントを残し、いいねを送り合える事だ。技術的には、異なるソーシャルメディア間の相互運用性︵interoperability︶を実現する為に、 W3Cの技術標準であるActivityPubプロトコルが使用されている。

現在、フェディバースに参加している代表的なソーシャルメディアとしては、 Mastodon、Pixelfed、Akkoma、Misskey、WordPress等があり、その他にも一つ一つ挙げ切れない程多くのプロジェクトが存在する。その大半はオープンソースプロジェクトでも有る。また、オープンソースではないが、 MetaのThreadsも今年の夏からActivityPubを少しずつ実装し、既にある程度フェディバースに参入していると言える。

異なるソーシャルメディアが通信し合う仕組みである為、フェディバース内のアカウントアドレスにはユーザー名だけでなく、サーバー名も含まれる。一般にフェディバースハンドルと呼ばれるこのアドレス形式は、 @username@hostの様に、まるでメールアドレスに似ている。これにより、異なるサーバーやプラットフォームに属するアカウント同士が相互にフォローし、コミュニケーションを取る事が出来る。勿論私自身もフェディバースアカウントを持っており、 @hongminhee@hollo.socialをフォローしてくれれば良い。

Fedify

Fedifyは、今年の私にとって最大の成果と言えるだろう。 FedifyはTypeScriptで書かれたActivityPubサーバーフレームワークで、 ActivityPubサーバーを実装する際に使える適切な抽象化レベルが見つからなかった為、作る事にした。最初は一からActivityPubサーバーアプリを作ろうと何度か試みて、ある程度動作するものも作ってみたが、その結果のコードには満足出来なかった。そこで、きちんと抽象化をしながら作成を進めていく内に、結局フレームワークの様なものを作っている事に気づき、 FedifyといったActivityPubサーバーフレームワークの必要性を痛感する様になった。

Fedifyには計4回の書き直しが有った。最初はTypeScriptで書き、その後Pythonに移行し、更にC#、そして最終的にTypeScriptに戻ってきた。言語選択には複数の考慮事項があった。第一に、 ActivityPubのデータ交換形式であるJSON-LDの実装がある言語である必要があり、またJSON-LDを簡単かつ便利に扱う為にある程度動的である必要があった。第二に、動的言語であっても静的型付け、所謂gradual typingを良くサポートしている必要があった。最後に、ユーザーが多く、エコシステムが豊かである必要があった。これはFedifyが広く使われる事を望んでいた為だ。全てを考慮した結果、TypeScriptを選択する事になった。

全ての書き直しの過程を含めると昨年12月初めから着手し、最後の書き直しに限って言えば2月末から作り始め、 3月初めに最初の0.1.0バージョンをリリースした。リリース前に考えていたコードネームはFedikitだったが、リリースに先立って検索してみると、既に同じ名前のプロジェクトが存在する事が分かり、急いでFedifyに名前を変更する事になった。 Fedikitというコードネームで作業していたPythonバージョンはGitHubにアップロードしてある。

Fedifyは現在、 ActivityPubサーバーを作る際に必要な機能を最も幅広く提供するフレームワークだと自負している。フェディバースはActivityPubを実装するだけでは終わらず、JSON-LD、 Activity Vocabulary、[WebFinger]、NodeInfo、HTTP Signatures、 Linked Data Signatures、Object Integrity Proofs等、多くの仕様を扱う必要がある。Fedifyはそれら全てを網羅している。更には、ActivityPubの主要な実装と言えるMastodonやMisskeyで未実装の機能も、 Fedifyでは実装されているものが多くある。ActivityPubの仕様だけを見て、 ActivityPubサーバーの実装が簡単だと思い込み、 ActivityPubフレームワークなしで着手して、結局その複雑さに戸惑うケースもよく見かける。これからActivityPubサーバーを一つ作ってみようと考えている人々には、是非Fedifyを使う事を勧める。

また、Fedifyを作る上で力を入れたもう一つが文書化だ。リファレンス文書は勿論、 Fedifyの全ての機能を網羅する豊富なマニュアルが存在する必要があると考えた。新機能を追加する際も、マニュアル文書を先に作成してから実装を行う程だった。その御陰で文書の量がかなり多くなり、今では英語以外の言語にどの様に翻訳すべきかが悩みの種となっている。

最後に、私がFedifyを通じて自分なりに満足出来る成果を上げたと感じた最大の出来事は、 GhostによるFedifyの資金支援だ。これにより人生で初めて専業のオープンソース開発者になる事が出来た。² 何より、GhostはFedifyの最大のユーザーでもある。 GhostのActivityPub実装は現在進行中で、プライベートベータ段階にある。恐らく来年には公開される予定だ。

Hollo

Holloはお一人様向けActivityPubサーバーだ。通常はMastodonやMisskeyサーバーの中から気に入った所に登録する形でフェディバースアカウントを作成するが、時々ソフトウェアエンジニアの中には自分のドメイン名で直接運営するサーバーを連携させてフェディバースアカウントを設置する人もいる。しかし、MastodonやMisskeyの様なソフトウェアは基本的に多くの人々がアカウントを作成して共に使用する事を前提に設計されている為、一人で使うには不要な機能も多く、重たい上に設置も面倒だ。そういった人々の為に作ったのがHolloだ。 HolloはPostgreSQLさえ有れば動作する為、設置も比較的簡単で、機能も一人で使う際に必要なものだけを備えている為、シンプルな事が特徴だ。

Holloを作る事になった経緯は少し複雑だ。実はFedifyを作る事になったきっかけがHolloだと言える。 Holloの様な自分専用のActivityPubサーバーを作り始めた事で、 ActivityPubサーバーフレームワークの必要性を実感する事になった為だ。但し、その時最初に作ろうとしたプロジェクトのコードはHolloには再利用されず、当時のプロジェクト名もHolloではなかった為、厳密に言えばHolloがFedifyを作るきっかけになったとは言えない。しかし、 Fedifyを作った後にこれを使って究極的に作りたかったものがHolloの様なものだった事は事実だ。

しかし、実際にFedifyを作ってみると、私が作りたいものはFedify自体となってしまい、元々の動機は多少色あせてしまった。その為、Holloを本格的に作り始める頃には、 Fedifyのデモを作る事がHolloの最大の目的となっていた。実際、 Holloを作りながらFedifyに必要な機能を追加したり、バグを見つけて修正したりもした。但し、あくまでもFedifyプロジェクトの一環だった為、 Hollo自体のコード品質はFedifyと比べるとかなり劣る。この問題はHolloをFedifyプロジェクトの一環として見なくなった時点から改善を始めたが、依然としてコード品質については改善すべき点が多く残っている。

Holloは予想外に日本でユーザー層が生まれ、公式文書を日本語に翻訳したり、日本で開催されたオープンソースカンファレンス二〇二四 Tokyo/Fallというイベントに出展してブースを出したりもした。この時、現地のHolloユーザーであるEsurioさんがブースを一緒に運営してくれて、大変お世話になった。

最近はドッグフーディングの為に、私が持っていたMastodonアカウントを捨ててHolloに移行した。

韓国フェディバース開発者の会

ある日ふと、韓国にはフェディバースソフトウェアを開発する開発者達の交流がない事に気づいた。そこで、Neovim用Mastodonクライアントを作った李在烈（イ・ジェヨル）さんに声をかけ、共に韓国フェディバース開発者の会を発足させた。先ずDiscordサーバーを設置し、かなり多くの開発者が集まった。

そして定期的なスプリント会を企画し、その第一回目の会を八月三一日にリターンゼロのオフィスで開催したところ、予想以上に多くの人々が参加した。この時に出会った人々とは、今でもフェディバース上で交流を続けている。

最近は年末という事もあり、オフライン交流は少し減っているが、来年になればまた活発な活動を再開する予定だ。

初めての同人誌販売

今年の秋から日本語圏のフェディバースで本格的な活動を始め、その過程で日本のHolloユーザー達と交流する様になった。その中でEsurioさんから、日本で開催されるオープンソースカンファレンスにブース出展してみては如何かという提案を頂き、悩んだ末に出展する事にした。日本のイベントへの出展は勿論、ブース出展自体が初めての経験だった為、 Esurioさんには様々な面でお世話になった。この場を借りて感謝の意を表したいと思う。

とにかく、ブースを出展する事になったからには何か展示品が必要だった。その一環として、 Fedifyのチュートリアル自分だけのフェディバースのマイクロブログを作ろう！を紙の本として印刷して販売する事にした。幸い、作って持っていった本は殆ど売れ、帰りは随分と軽く帰る事が出来た。この時に本を買ってくれた方々の中の一人であるモナコ広告さんが、チュートリアルを実践してみた過程をFediLUG 勉強会でFedifyでActivityPubサーバを作ってみたという題目で発表してくれた。

必ずしも本を買ってくれた方々だけでなく、不十分な日本語ながらも手探りで交流が出来て良かった。

専業フェディバース開発

何だかんだあって年初には全く予想していなかった方向へ流れ、一種の専業フェディバース開発者となった状況だが、来年はフェディバース自体の裾野を広げる事に力を注いでみる予定だ。その一環として、ソフトウェアエンジニア達の為のActivityPub基盤のソーシャルプラットフォームを作ってみているが、近々公開出来る様にしたいと思う。

Fediverse Advent Calendar 二〇二四の二四日目の記事。 ↩
厳密には元の職場でもオープンソース製品を専業で作っていましたが、私が始めたプロジェクトではなかった。 ↩

GhostのFedifyへの資金支援

2024-07-03T02:00:00.000Z

GhostのFedifyへの資金支援

悪いニュースばかりだったこのブログにも、遂に朗報が飛び込んできた。今年の春から趣味でやっていたオープンソースプロジェクトであるFedifyが、グローバルブログプラットフォームであるGhostから資金支援を受ける事に成ったのだ。

Fedifyとは？

先ず、Fedifyがどの様なプロジェクトなのか紹介したいと思う。

Fedifyは、ActivityPubプロトコルを実装するサーバーフレームワークだ。オープンソースプロジェクトであるMastodonやMetaのThreadsの様な異なるソーシャルメディアサービスが一堂に会してコミュニケーション出来る技術的背景がActivityPubプロトコルである。この様に集まったソーシャルメディアの連合をフェディバース（fediverse）と呼ぶ。

ActivityPubは一見シンプルなプロトコルの様に見えるが、実際に他のサービスとの相互運用性を正しく実装しようとすると、思ったより難しい点が多い。その為、その様な厄介な部分を処理してくれるフレームワークの存在を望む様に成り、適当な物が無かったので、自分で作る事に成ったのである。

GhostがFedifyを採用

2ヶ月前まで、Fedifyは余暇に作る趣味のプロジェクトで、おもちゃの様な物だった。それでも、小さなユーザーコミュニティが有ったのだが、或る日、その中の誰かがGhostがActivityPubを実装するというニュースを伝え、 GhostもTypeScriptで作られている様なので、 GhostチームにFedifyをセールスしてみる事を勧めた。最初はセールスが出来るかどうか心配で躊躇したが、セールスする事を勧めてくれた方がGhostチームに直接メールまで送ってくれたので、勇気を出して私もGhostチームに連絡する事に成った。

すると、なんと、GhostチームがFedifyを前向きに検討しているのではないか？そして、本当にFedifyを本格的に利用する事を決めたと連絡が届いた。それは驚きであり、私はそれだけでとても嬉しかった！

資金支援

その後、私はGhostチーム、特にGhostにActivityPubを実装しているチームメンバーと緊密に連絡を取り合う事になり、その後すぐにGhostチームからFedifyプロジェクトに資金を提供するので、 GhostチームからFedifyに追加して欲しい機能を実装してくれないかとの提案が来た。ちょうど再就職の為、あちこちの会社に履歴書を出していた私にとっては、かなり悩ましい話だった。

先ずは約半月ほど一緒に働く事にして、少額の資金支援を受けた。そして、就職の準備をしながらFedifyの仕事をする事に成ったが、思った以上に没頭して楽しく働く事ができた。結局、私はもう少し長く資金支援が可能であれば、フルタイムでFedifyの仕事をする意思を表明し、 Ghostチームからも肯定的な回答を得る事が出来た。

その結果、今後かなり長い間、資金支援を受けながらFedifyの仕事をする事に成った。¹ 前職でもフルタイムでオープンソースプロジェクトをした事は有ったが、この様に私が始めたオープンソースプロジェクトに資金支援を受ける形で仕事をするのは初めてなので、これからが楽しみだ。

そして、就職活動をして合格した会社には残念だが（本当に惜しい会社がいくつか有った）、入社オファーを断った。 ↩

洪民憙雑記

ブログにActivityPub連携を追加した

ブログにActivityPub連携を追加した

既存スタック: Jikji + PHP

新スタック: Astro + Netlify

AstroにFedifyを組み込む

@fedify/astroの最新化

静的ページと動的エンドポイント

PersonとArticle

FedifyをNetlifyで動かす

おわりに

ハングル専用下の漢字教育について

ハングル専用下の漢字教育について

教育のデフォルトは「教えない」である

国漢文混用体の利点と現実論

漢字混用なき漢字教育の逆説

趣向と政策の区分

Footnotes

コーディングを愛する人たちが、なぜコーディングから追い出されているのか

コーディングを愛する人たちが、なぜコーディングから追い出されているのか

行為からの疎外

不利益を与えているのは何か

私の状況が示すもの

悲しみが向かうべき場所

合法であれば正当か——AI再実装とコピーレフトの侵食

合法であれば正当か——AI再実装とコピーレフトの侵食

類比の方向が逆だ

GPLは共有に反するのか

自己論駁する事例

合法性と社会的正当性は異なる次元にある

誰の視点がデフォルトに設定されているか

この争いが指し示すもの

不完全な世界で唯物論的に行動すること——生産手段としてのLLMと社会的関係

不完全な世界で唯物論的に行動すること——生産手段としてのLLMと社会的関係

二つの藁人形

機械とその資本主義的適用形態

図書館と人間

デフォルトの視点

なぜ雪だるまを壊さないのか

なぜ雪だるまを壊さないのか

F/OSSの唯物史観——LLMを拒絶するのではなく、取り戻すべきだ

F/OSSの唯物史観——LLMを拒絶するのではなく、取り戻すべきだ

我々が同意する点

我々が分岐する点

現実認識について

唯物論的読解

訓練コピーレフトがどのような姿になりうるか

技術的挑戦と先例

なぜこれが撤退より重要なのか

我々が作るべき未来

歴史的機会

結論

フェディバースと過ごした二〇二五年

フェディバースと過ごした二〇二五年1

『Thinking Penguin Magazine Vol.0』

BotKit

Hackers’ Pub

『Software Sessions』出演

『私たちのコードを探して』出演

オープンソースコントリビューションアカデミー︵OSSCA︶

Fedify投資誘致

各種発表

一年を締めくくりながら

Footnotes

STFのFedifyへの投資

STFのFedifyへの投資

NLnet

Sovereign Tech Fund

所懐

オープンソース開発の近況

オープンソース開発の近況

Hollo

Fedify

LogTape

Hackers' Pub

Upyo

Optique

ヤクシェービング

Footnotes

フェディバースと共に過ごした一年

`Person`と`Article`

フェディバースと過ごした二〇二五年¹

フェディバースと共に過ごした一年¹