嫌いなもの

• 人間

• コーヒー

• 手続き

• 書類

• Kind of Blue

• 人間関係

• 不義理

• Monster Energy

• クラシック音楽

• 社会通念

• 猫被り

• 法律に反すること

• 私有

• 被害者ぶり

• 親

• 仲良しこよし

• 一貫性のない言動

• 暴力

• 綺麗なインターネット

• わかば

• 社交

• 嘘

• 営業

• 要はバランスおじさん

• 酒っぽい酒

• 胸焼けしかねない脂の乗った肉や魚

• ビール

• 明るい人

• クチャラー

• 同じ皿で箸を突くこと (ほぼ無理に近い)

• 飲み回し (ほぼ無理に近い)

• 公衆便所

• 地元

• 規律

• 無難

• 時間的な約束

• 定型作業

• 驚き屋

• 出かけるための準備

• 電話

• なんとなくオシャレな雰囲気

• 今の YOSHIKI

• ジャズが好きというとオシャレと言ってくる人

• 明るいところ

• 集団に参加すること

• ジャズを高貴なものとして捉えている人

• シャバさ

• 不誠実

• 理不尽

• 人が多いところ

• 妥協

• ポリコレ

• リベラル

• 詮索

• 陰口

• カッコつけ

• 権威主義

• Art Blakey

• 手が汚れるザラザラしたグミ

• ルッキズム

• いじめ

• 無自覚

好きなもの

• 鴨

• コンパイラ

• 言語処理系

• コンピュータ

• 筋の良さ

• Led Zeppelin

• 透明水彩

• 香ばしさ

• 猫

• Jazz，特に Contemporary Jazz

• Kurt Rosenwinkel

• 一貫性

• Hip hop

• クラブ

• タバコ，che がベスト

• うに

• インターネット極左

• 最高峰

• ファッション，Mode が好き

• スカートをはくこと

• ワンピースを着ること

• 良い話

• UNITED TOKYO

• Rust

• Piano Trio

• John Coltrane

• 昔の YOSHIKI

• クネクネ

• 筋の良い研究者

• Atonal

• 音楽理論

• 風刺

• 概念

• 批判

• 感覚

• 思考

• Hard Fusion

• Taxonomy

• デザイン

• ピアス

• インテリア

• Nihilism

• インターネット

• Web サイト

• デパス

• レッドブル

• ブロマゼパム

• Brad Mehldau

• パンケーキ

• 油絵

• セブンイレブンのれんこんのり塩チップス

• 生に近い肉

• 麺は硬ければ硬い程よい

• 白米

• チョコレート

• ランダム

• 哲学

• 主張

• 造語

• 覚悟

• 思い切りの良さ

• 実力

• よく作り込まれたもの

• Vue.js

• 殺伐としたインターネット

• ネタツイ

• Art

• Generative art

• 抽象画

• 印象派

• タトゥー

• ギャグ

• 絵を見ること

• アルバムのアートワークを見ること

• クレープ

• 照明が暗いところ

• 複雑なもの

• 写実主義

• 美しいもの

• 景観の良い街

• 景観の良い路地

• 散歩

• 鉛筆デッサン

• 仕組み

注意: この記事は私個人の意見であり，所属企業を代表するものではない． 会社のブログは現在準備中で，現時点では適切な公開場所がなかったこと，また個人的な問題意識に基づく話でもあることから，今回は個人ブログに書いている．また，特定の会社や個人を責めるための文章でもない． ただ，営利企業として OSS を使っているなら，その作者，メンテナ，コアコントリビュータへもう少しお金の流れを作った方がよいのではないか，という話である．

序

OSS の作者，メンテナ，コアコントリビュータに対する報酬が不十分である，という話はたびたび話題になる．あるライブラリのメンテナが疲弊している，重要なパッケージが少人数に支えられている，世界中の企業が依存しているにもかかわらず，その人の生活はまったく安定していない．そういう話が流れてくるたびに，インターネットは少しざわつく．

もちろん，OSS は単純な雇用契約ではない．コードを公開した人が，自動的に利用者全員から対価を受け取る権利を持つ，という単純な話でもないし，利用者が全員，何かに強制的に課金されるべきだと言いたいわけでもない．

ただし，営利企業については少し事情が違う．

私たちは OSS を使ってプロダクトを作り，開発速度を上げ，品質を上げ，運用し，売上を作っている．そしてその売上の一部は，給料や利益として私たちの手元に来ている．

それなら，OSS を利用して収益を上げている企業が，その作者，メンテナ，コアコントリビュータに対して資金を還元することは，自然なことではないか．

Web フロントエンドは特にそうである

私は普段 Web フロントエンドの領域に関わっているので，この話をどうしてもその文脈で見てしまう．

現在の Web フロントエンド開発では，OSS は個別の便利な道具というより，日々の開発と運用の前提になっている． 開発環境を整えるとき，品質を担保するとき，プロダクトを届けるとき，その多くの場面で OSS に触れている．

私たちはそれらを組み合わせ，自社の事情に合わせて運用し，開発基盤として利用している．

もちろん，自社で書いたコードもあるし，設計も運用もプロダクト理解もあるので，そこを軽く見るつもりはない．

しかし，その土台の多くは，自社の外にいる作り手によって支えられている． しかもその多くは，直接の雇用関係も契約関係もない人たちが，どこかの時間を使って作り，直し，リリースしている．

OSS は抽象的な公共財のように見えることがある．しかし実際には，その向こうに作者がいて，メンテナがいて，レビューし，方針を決め，壊れたものを直すコアコントリビュータがいる．支払うべき対象を考えるとき，私はこの人たちの存在をもう少し前に出したい．

この状態で，企業が OSS の作り手にお金を払うことを特別な善行のように扱うのは，少し不自然だと思う．むしろ，通常の費用に近い．サーバー代を払い，SaaS に払い，デザインツールに払い，採用媒体に払い，イベントにスポンサーする．

ならば，依存している OSS の作り手にも支払うべきである．

イベントへの支援に比べて，作り手への支援は少ない

日本の技術コミュニティでは，イベントスポンサーを多く見かけるし，これは重要なことだと思う．会場費や配信費が出て，登壇者や参加者の体験が良くなり，企業とコミュニティの接点も生まれる．イベントスポンサーは文化を大きく支えている．

ただ，イベントにロゴを出す企業の数に比べると，OSS の作者，メンテナ，コアコントリビュータに対するスポンサーはまだ少ないように感じている．

イベントは目に見えやすい．ロゴが出て，会場にブースが出て，採用広報にもつながり，社内説明もしやすい．一方で，OSS の作り手の仕事は見えにくい．issue を読み，再現コードを書き，breaking change を避け，依存関係を更新し，脆弱性を直し，リリースノートを書き，ユーザーからの繊細な不満を受け止める．

これは派手な仕事ではなく，外部からも見えにくい．しかし，この地道な作業が止まると，ある日突然こちらの仕事も止まる．イベントスポンサーが不要だと言いたいのではないし，むしろ続いてほしい．ここで言いたいのは，支援先がイベントに寄りがちであるなら，OSS を作り，維持している人にももう少し支援が向いてよいのではないか，ということである．

メンテナは大企業の中の人だけではない

Meta，Vercel，Cloudflare のような企業には，OSS 活動を仕事として行っている人たちがいる．それは素晴らしいことだし，企業が OSS を戦略の中心に置き，人を雇い，開発を進めることには大きな意味がある．

しかし，OSS はそれだけで成り立っているわけではない．

大きな企業に所属していないメンテナもたくさんいる．個人でやっている人もいれば，小さな会社で働きながら夜や休日にやっている人もいるし，自分のプロダクトではないにもかかわらず，世界中のユーザーのために，結果として大きな責任を引き受けている人もいる．

実際に，私が日常的に利用しているいくつかの OSS も，大きな企業に所属していない開発者によって作成，またはメンテナンスされている．

私たちは，OSS を見るときに，有名な企業の名前を思い浮かべがちである．しかし，実際の依存関係の奥には，名前も顔も知らない個人がいる．その人が大企業に雇われているとは限らないし，会社の業務時間で直しているとも，生活に余裕があるとも限らない．それでも私たちは，その人たちの作ったものを使って売上を作っている．この非対称性を，もう少し直視した方がよい．

個人スポンサーは意味がある，でも足りない

私は GitHub Sponsors で，ありがたいことに 20 前後の個人スポンサーから支援を受けている．

これは大きな支えになっている．活動を見てくれている人がいるという実感があるし，金銭的にも少し余裕ができる．

だから，個人スポンサーに意味がないとはまったく思っていない．むしろ大いに意味があり，個人が個人に対して小さく支援する文化は，もっと広がってよい．

ただ，現実問題として，個人の小口支援だけで生活していくのは難しい．

数百円，数千円の支援が積み重なることは尊い．しかし，生活費，税金，保険，家賃，機材，時間の確保まで考えると，それだけで継続的な OSS メンテナンスやコアな開発参加を成立させるのは簡単ではない．

ここで企業による支援が必要になる．

個人が払えない金額でも，企業にとっては小さな予算であることがある．個人にとって大きな数万円が，企業にとっては一回の会食，一つの SaaS，一つの採用施策に近い扱いになることがある．その差は大きく，そこを活かすべきだと思う．

ただし，大口の継続支援には危うさがある

ここは重要だと思っている．

相当な覚悟がない限り，特定の一社が，一人の作者やメンテナ，コアコントリビュータに対して，継続的に大きな monthly 支援をするべきではない．

一見すると，大きな継続支援は望ましいことに見える．もちろん，安定した資金が入ること自体は良いし，受け取る側にとっても助かる．

しかし，その支援に生活が寄りすぎると，取りやめられたときのダメージが大きい．

会社の方針が変わる，担当者が異動する，景気が悪くなる，予算が切られる，その OSS を使わなくなる．企業側では起こり得る話である．しかし受け取る側にとっては，生活や活動計画が崩れる話になる．

だから，企業による OSS 支援は，集中した太い一本の柱よりも，細い柱がたくさんある状態の方が望ましいと思う．

単発のスポンサーが，たくさんの企業から，分散的に行われる．ある企業が一度支援し，別の企業が次に支援する．年に一度でも，四半期に一度でもよいし，プロジェクトのリリースや，自社で大きく助けられたタイミングでもよい．

一社の美談にせず，一人の作り手を一社に依存させず，企業群全体で，広く薄く，しかし個人スポンサーよりは大きな金額で支える．

この形の方が，OSS の経済としては健全だと思う．

企業は単発で支援すればよい

企業が OSS の作り手にお金を払うというと，すぐに大きな制度や継続契約を想像してしまうかもしれない．

しかし，最初から立派な制度にしなくてもよい．

今月，自社でよく使っているライブラリに払う．大きな移行で助けられたツールに払う．issue 対応が丁寧だったメンテナや，重要な設計判断を支えているコアコントリビュータ，依存関係の奥にいる個人に払う．リリースのたびに少し払う．

そのような単発の支援でよいと思う．

企業としては少額でも，受け取る個人にとっては大きい金額がある．たとえば 5 万円，10 万円，15 万円くらいの支援は，企業の予算としては過大ではないかもしれないが，個人の作者，メンテナ，コアコントリビュータにとっては，大きな意味を持つ金額になる．

そして，それが一社から継続的に来るのではなく，複数の企業から不定期に来るなら，依存の形も少し柔らかくなる．

もちろん，経理処理は煩雑かもしれないし，稟議も必要かもしれない．受け取り口が GitHub Sponsors なのか Open Collective なのか，請求書が必要なのか，社内規程に合うのか，さまざまな論点があると思う．

それでも，取り組んだ方がよい．

手続きの煩雑さを理由に見送るには，私たちは OSS に依存しすぎている．

所属企業で話したこと

ここで少し，自分の所属企業の話をする．

私は普段，株式会社メイツという営利企業でチーフエンジニアを務めている．

当然，仕事では OSS をたくさん利用している．Web フロントエンドでも，バックエンドでも，開発基盤でも，OSS はあらゆる場所にあり，その上でプロダクトが作られ，売上が生まれ，そのうちのいくらかは給料として私に振り込まれる．

この構図を考えると，少なくとも私個人としては，企業として OSS の作り手にお金を払うべきだという気持ちが強い．

ただ，この記事は会社を代表するものではなく，会社の公式見解でもない．ここはきちんと分けておきたい．

そのうえで，私はこの話を社内に持ち出した．まずは提案した本人が動くべきだと思ったからである．

「OSS に支えられているのだから，会社としてもその作者やメンテナ，コアコントリビュータに不定期に単発でスポンサーできないか」

要約すると，こういう相談をした．ありがたいことに，社内のメンバーは賛同してくれた．

これは，過度に美談として書きたいわけではない．会社として巨大な基金を作ったわけでもないし，世界を変える制度が今日から始まるわけでもない．金額も，会社としては少額の範囲になると思う．

ただ，それでも始めることに意味があると思っている．

まず自分のいる場所でやる．そして，できれば他の企業も巻き込む．一社の立派な取り組みにするのではなく，多くの企業が自然に取り組むことにする．

私はそういう方向に進んでほしいと思っている．

これは善行というより，支払いである

OSS 支援は，どうしても「良いことをしている」という印象が出やすく，スポンサーした企業が偉い，支援した人が優しい，という話になりやすい．

もちろん，そういう側面もあるし，支援するのは良いことだ．

しかし，企業に関しては，もう少し冷静に捉えてもよいと思う．

自分たちが使っているものの作り手に払う．自分たちの利益に貢献しているものの維持者に払う．自分たちの開発速度を支えている人に払う．

これは善行というより，通常の支払いである．

むしろ，これまで十分に支払ってこなかった状態の方が不自然だった，くらいに考えてもよいかもしれない．

何かを無料で使えることと，その維持にお金がかかっていないことは違う．ライセンス上は無料で使えることと，経済的にただ乗りし続けてよいことも違う．

OSS は無料で使えることが多い．だからこそ，払える側が自発的に払う必要がある．

特に，OSS を使って収益を上げている企業はそうだ．

結論

営利企業こそ，OSS の作り手に金を払え．

これは，企業を責めたい言葉ではなく，自分たちの仕事の土台を，もう少し正しく見るための言葉である．

私たちは OSS を使い，OSS によって開発速度を得て，品質を得て，売上を作っている．

なら，その一部を OSS の作者，メンテナ，コアコントリビュータに戻した方がよい．

イベントスポンサーも続けばよいし，個人スポンサーも広がればよいし，大企業が OSS 開発者を雇う流れも続けばよい．

そのうえで，もっと多くの営利企業が，依存している OSS の作者，メンテナ，コアコントリビュータに対して，単発で，分散的に，個人スポンサーより少し大きな金額を払うようになってほしい．

一社が過度に前面に出るのではなく，多くの会社が自然に支払う．一人の作り手を一社に寄せるのではなく，たくさんの企業で支える．採用広報の飾りではなく，開発費用の一部として扱う．

私は，この方向に OSS の経済が少しでも進んでほしいと思っているし，私も，自分のいる場所から，できるだけその流れを作っていきたい．

注意: ここでいう「荒らせ」は，誹謗中傷しろ，デマを流せ，人を傷つけろ，という意味ではない．利害関係や政治性や人の生存に関わるものを，軽く扱えという話でもない．むしろ逆で，嘘を言うのは良くないし，間違っていれば謝ればいい．その上で，主張を持て，争え，磨け，という話である．

序

私は2000年生まれのソフトウェアエンジニアだ．インターネットの先輩たちが，ブログで殴り合い，Twitterでプロレスをし，掲示板やコメント欄で長文を書き，勉強会で思想をぶつけ，時にはかなり面倒くさい人間になっていく様子を，横目で見てきた世代でもある．そして俺は，3DSで2ちゃんねるを見て育った．

もちろん，昔のインターネットを無邪気に美化したいわけではない．普通に最悪なものも多かったし，人を傷つける言葉も，雑な決めつけも，笑えない攻撃もあった．あれをそのまま復刻しようと言いたいわけではない．ただ，一つ気がかりなことがある．私の世代のインターネッタラーは，大人しすぎるのではないか．

大人しさは美徳だが，限界でもある

喧嘩は良くない．お互いにリスペクトを持つべきだ．誹謗中傷をしてはならないし，相手の属性や生存に関わることをゲームの駒にしてはいけない．これらは全部正しいし，かなり大事なことだと思っている．

しかし，そこから「だから主張を持つな」にはならない．「だから物議を醸すな」にはならない．「だから何も言わずに，安全な空気の中で，薄い同意だけを交換していろ」にはならない．リスペクトとは衝突を避けることではなく，相手を人間として扱った上で，なお主張をぶつけることだ．

何も言わないことが常に優しさになるわけでもない．主張を避け続ける場では，間違った前提も，弱い設計も，退屈な文化も，そのまま残る．インターネットがずっと無風なら，それは平和なのではなく，単に換気されていないだけかもしれない．

嘘をつくな，でも間違えろ

ここは分けて考えたい．嘘を言うのは良くない．知っていて誤情報を流すこと，確認していないことを断言すること，人を陥れるために事実をねじ曲げることは，ただ悪い．

一方で，間違えることはある．強い主張をすれば間違える可能性は上がるし，新しい概念を出せば粗くなる．誰かに反論すれば読み違えることもあるし，議論の途中で自分の前提が崩れることもある．そのときは謝ればいいし，訂正すればいいし，撤回すればいい．次から少しうまくやればいい．

間違える可能性があるから何も言わない，という態度は一見すると誠実に見えるが，それを突き詰めると何も世界に出せなくなる．嘘をつくな．でも，間違えることまで恐れすぎるな．間違えた主張は，謝罪と訂正によって磨ける．最初から存在しない主張は，何にもならない．

プロレスには技術がいる

私は，もっとプロレスをしてほしいと思っている．ただし，プロレスは殴り合いではない．高度な形式であり，受け身があり，間合いがあり，観客がいて，相手への信頼がある．インターネット上のプロレスも同じで，人格ではなく主張を殴り，相手の強い形を捉えてから反論し，煽るなら逃げ道も残し，比喩で笑わせても事実は雑にしない，という技術がいる．

間違えたら謝ること，相手が本当に傷ついているなら止まることも含めて，それらができないなら，ただの攻撃になる．それはプロレスではなく，素人がリングに刃物を持ち込んでいるだけである．危ないし，ださい．

だからこそ，技術を育てる必要がある．強い言葉を使うなら強い倫理も持て，物議を醸すなら物議の後始末も引き受けろ，人を集める言葉を使うなら人が集まった後の温度管理まで考えろ，という話だ．荒らすとは場を壊すことではない．場に流れを作ることだ．

主張を持て

若い世代は，たぶん失敗のリスクをよく知っている．スクショは残るし，発言は検索されるし，勤務先も見られる．文脈は切り取られ，誰かの怒りは知らないところで増幅される．だから大人しくなるのはわかる．私もわかる．インターネットは，昔よりずっと社会になった．

社会になったインターネットで暴れることは，単にハンドルネームで騒ぐことより重い．それでも，主張は持った方がいい．この技術はこうあるべきだ，この文化はつまらない，この設計は弱い，この流行は変だ，この言葉は便利すぎて危ない，このコミュニティはもっと良くできる．そういう主張を，もっと出した方がいい．

もちろん根拠は要るし，誠実さも要るし，反論を受ける覚悟も要る．でも，主張がなければ議論は始まらない．議論が始まらなければ何も深まらないし，何も深まらなければ世界は変わらない．

争い，磨け

争いは，それ自体が悪なのではない．悪いのは，人を壊す争いであり，属性を殴る争いであり，嘘で相手を潰す争いであり，取り返しのつかないものを軽いノリで燃やす争いである．

そうではなく，主張と主張をぶつける争いがある．概念と概念をぶつける争いがあり，設計思想と設計思想をぶつける争いがある．それは必要だ．衝突しない主張は丸く見えるかもしれないが，丸いだけの石は切れない．どこかで削られ，欠け，研がれないと，道具にはならない．

主張も同じだ．反論されて弱いところが見え，問い返されて前提が見え，笑われて過剰な自意識が落ち，誰かに刺さって初めて自分の言葉の刃の向きがわかる．だから，争え．そして磨け．勝つためだけに争うな．燃やすためだけに荒らすな．自分が正しいと証明するためだけに長文を書くな．世界を少し変えるために争え．自分の主張をより良くするために荒らせ．

結論

若者よ，インターネットを荒らせ．ただし，嘘をつくな．人を壊すな．生存や属性をゲームにするな．間違えたら謝れ．訂正しろ．撤回しろ．それでも主張を持て．

もっと物議を醸していい．もっとプロレスをしていい．もっと議論を深めていい．大人しくしているだけでは，世界はきれいにならない．ただ静かになるだけだ．

静かなインターネットは，一見，成熟して見える．しかし本当に必要なのは，無風の成熟ではなく，よく管理された乱流である．主張を持て．争え．磨け．そして，できれば少しだけ，世界を変えろ．

注意: ここでいう「おじさん」は年齢でも性別でもない． おばさんも若者も含む． なんなら自分の中にもたまにいる． これは属性ではなく，議論中に発生する態度の名前である．

序

私は「要はバランス」という言葉があまり好きではない．

もちろん，バランスそのものが嫌いなわけではない． 品質と速度，自由と規律，安全性と機動力，理想と現実． この手の議論は，だいたい最後にはバランスへ行き着く．

だからこそ，議論の途中で「要はバランス」と言うことは，多くの場合，何も言っていないに等しい．

料理中の人に「要は火加減」と言うようなものだ． 正しい． 正しすぎる． そして，誰の手元も一ミリも助けていない．

強火なのか弱火なのか． 今なのか後なのか． 焦げ目をつけたいのか，中まで火を通したいのか． そこを話している最中に「要は火加減」と言われても，こちらは「はい」としか言えない． そして「はい」と言った瞬間に，議論だけが死ぬ．

主張がないなら，主張がないと言えばいい

主張を持っていないこと自体は悪くない．

情報が足りないなら「情報が足りない」と言えばいい． 判断基準が見えていないなら「判断基準が見えていない」と言えばいい． まだ考えられていないなら「私はまだ主張を持てない」と言えばいい．

それは誠実である．

しかし，主張がないことを「自分は一段上から客観的に見えている」というポーズに変換し始めると，話が変わる．

両サイドを冷笑し， 「まあまあ，みんな熱くならずに」と言い， あたかも自分だけが大人であるかのように振る舞う．

これは中立ではない． かなり濃いめのエゴである．

ポライトな見下しは，見下しである． 砂糖をまぶした毒は，お菓子売り場に置くと余計に危ない．

意見を言えないことと中立は違う

ここは強調しておきたい．

意見を言うことができないこと と，中立的であること は違う．

知識が足りない． 責任を持てない． 場の力学が怖い． まだ言語化できない． そういう理由で，意見を言えない瞬間はある．

それは状態である． 限界である． 人間なので普通にある．

しかし，中立は状態ではなく立場である． 両側の主張を見た上で，いまは判断を保留する． 論点を整理する． 判断に必要な情報を分ける． そういう役割を引き受けることだ．

意見を言えないことを，中立であるかのように扱ってはいけない． それは「まだ立場を置けない」を，「私は両側を超越している」にすり替える行為である．

このすり替えが起きると，無主張がなぜか道徳的優位になる． 議論に参加している人たちが未熟で，自分だけが成熟しているように見える．

それは中立ではない． 参加できていないことのラッピングである．

議論は喧嘩ではない

「要はバランスおじさん」は，しばしば議論を喧嘩として見る．

Aさんが強く言う． Bさんも強く返す． 反例が出る． 前提が掘られる． 論点が増える．

すると，その場を「荒れている」と見て，止めに入る．

もちろん，人格攻撃やハラスメントが起きているなら止めた方がよい． それは議論ではなく，人が壊れる方向へ進んでいるだけだからだ．

しかし，意見がぶつかっていること自体は悪ではない． むしろ，両サイドがきちんと主張を出し合うことで，初めて見える地形がある．

速度を重く見る人がいる． 安全性を重く見る人がいる． 運用コストを言う人がいる． ユーザー影響を言う人がいる．

この状態は，単に「対立している」のではない． 論点の地図が増えている． 価値の軸が見えてきている． 議論が深まるとは，たぶんこういうことだ．

そこで「要はバランス」と言って止めてしまうと，せっかく生えかけた軸が折れる． あとには，何となく大人っぽい空気だけが残る．

その空気は議事録に書けない． 実装にも設計にも意思決定にも使えない． だが本人の自己像だけは少し温まる．

省エネ暖房としては優秀かもしれない． 世界への貢献としてはかなり怪しい．

「両方大事」は入口であって出口ではない

「両方大事」も同じだ．

もちろん両方大事なのだ． 大事だから議論している． 片方がどうでもいいなら，そもそも議論にならない．

重要なのは，そこから先である．

• 今回はどちらを優先するのか

• どの条件なら優先順位が反転するのか

• 誰がそのコストを払うのか

• 失敗したとき，どちらの失敗の方が回復しやすいのか

• 原則の話なのか，今回だけの例外なのか

この粒度まで降りて初めて，「バランス」は作業になる． それ以前の「両方大事」は，ただの入場券である． 入場券を握りしめてステージ中央に立たれても困る． ライブはまだ始まっていない．

何かを選ぶとは，何かを選ばないことでもある． どちらかを重く見るとは，もう片方の不満を引き受けることでもある． バランスを取るとは，その負債の置き場所を決めることでもある．

それを言わない「バランス」は，かなり高級な無責任である．

止めるなら，理由を持て

議論を止めること自体が悪いわけではない．

時間がないこともある． 参加者が疲れていることもある． 前提情報が足りないこともある． 同じ論点を三周していることもある．

ただし，止めるなら理由を持つべきである．

今は判断材料が足りないので，ここで止めたい

論点が三つに分かれたので，いったん分解したい

このままだと人格評価に寄りそうなので，発話の対象を案に戻したい

こういう止め方なら，議論に貢献している． 議論を殺しているのではなく，次に進めるために形を変えている．

一方で，

要はバランスだよね

だけで止めるのは，結論のふりをした停止命令である．

しかも「バランス」は善良そうに見える． だから反論する側が，まるで過激派のように見える．

これはズルい． かなりズルい． そして本人にズルをしている自覚がないことが多い． その無自覚さまで含めて，厄介である．

結論

私が嫌いなのは，バランスではない．

「要はバランス」という言葉が，主張しないための免罪符として使われることが嫌いなのだ．

主張する人は，間違えるリスクを負っている． 反論する人も，嫌われるリスクを負っている． 具体案を出す人は，具体的に批判されるリスクを負っている．

その横から，何も出さずに「要はバランス」とだけ言うのは，手ぶらで鍋パに来て「味って大事だよね」と言うようなものである．

大事だよ． 大事だから今みんなで作っているんだよ． せめてネギを切れ．

主張があるなら主張する． 整理するなら整理する． 止めるなら理由を持って止める． まだ主張がないなら，主張がないと言う．

議論は，冷やせば成熟するわけではない． 熱があるからこそ，出てくる形がある．

火傷しないようにはしたい． でも，火を見た瞬間に消火器を構える人だけで世界を運用すると，たぶん夕飯がずっと生で出てくる．

TypeScriptのネイティブ実装であるtypescript-go，つまりtsgoを眺めていると，かなり自然に発想が変わる瞬間がある．

最初は「tscが速くなる」という話に見える． 実際，TypeScript 6.0のアナウンスでも，TypeScript 6.0は現在のJavaScript実装からTypeScript 7.0以降のGo実装へ移るためのbridge releaseだと説明されているし，Go実装はnative codeとshared-memory multi-threadingを使う新しいcodebaseとして説明されている．

しかしtsgoを外から利用する側のコードを書いていると，関心は少しずつ別の場所へ移る．

僕が欲しいのは，単に一回のtsgo --noEmitを速くすることだけではない． エディタ，リンター，コード生成，リファクタリング，AIエージェント，ビルドサーバーのような複数の利用者が，同じTypeScript program graphとcheckerの周りに集まり，必要な質問だけを繰り返し投げられる形である．

このとき僕には，tsgoがCLIというより，言語処理系サーバー に見えてくる．

そして僕はcorsa-bindで，この見え方を実装へ押し込んでいる． tsgoをforkして中身を書き換えるのではなく，upstreamが用意するstdio API / LSPの境界に乗り，その外側でworker，session，snapshot，transport，cacheを束ねる．

名前についても少し補足しておく． corsaは僕のプロジェクトそのものの名前というより，tsgo側のコードネームに由来する呼び名である． 僕のプロジェクト名はcorsa-bindで，READMEでも，typescript-goをRustやNode.jsから扱うためのbindings / orchestration layersとして説明している． つまりbindは，単にFFIの関数を一本生やすという意味ではなく，tsgoという処理系の外側にRust，Node，native language向けの接続面と運用層を束ねる，という意味合いを持っている．

僕はこの発想を，言語処理系オーケストレーション と呼びたい．

stdio APIは関数呼び出しではない

tsgoのstdio APIを最初に見ると，「標準入力と標準出力でrequest / responseを流すだけ」と思うかもしれない． しかしこの見方だと，かなり大事なものを落とす．

stdioの向こう側には，別プロセスとして起動した言語処理系がいる． こちらはrequestを送る． 向こうはprogramを作り，source fileを読み，型を解き，symbolを持ち，snapshotを管理し，responseを返す．

つまりこれは，

caller process
  -> transport
  -> tsgo worker process
  -> program / checker / snapshot state

という境界である．

ここで重要なのは，tsgo workerが状態を持つことだ． 一回ごとにprocessを起動し，configを読み，projectを開き，型検査して捨てるなら，それはCLIの使い方である． しかしworkerを生かし続け，initializeを一回で済ませ，snapshotを再利用し，同じsessionに対して小さなqueryを投げ続けるなら，それはserverの使い方である．

docs.rsのcorsa_bind_clientは，この層を「typescript-go stdio APIのhigh-level client bindings」として説明している． 具体的には，tsgo worker processをspawnし，一度initializeしたsessionを再利用し，snapshotを作って再利用し，type / symbol / syntaxの質問をtyped helper経由で投げる，という役割を持つ．

この時点で，僕がcorsa-bindでやっていることは単なるbindingではなくなる． FFIで関数を一本生やす，という話ではない． プロセスの寿命，transportの種類，requestの型，snapshot handleの寿命，cleanup，timeout，observabilityをまとめて扱う必要がある．

僕は言語処理系を呼ぶためだけの薄いbindingを作っているのではない． 言語処理系を運用する層を書いている．

コンパイラを速くするのではなく，仕事の形を変える

ここで誤解してはいけないことがある．

僕はcorsa-bindを，tsgoより賢いcompiler engineとして作っているわけではない． 同じprojectを開き，同じ型を解き，同じ診断を出すなら，根本的な仕事はtsgoがやる． wrapperがその中身を魔法のように速くする，という話ではない．

僕がcorsa-bindで狙っているのは，仕事の形を変えることだ．

たとえば，次の二つはかなり違う．

CLI-shaped workflow:
  run tsgo
  load config
  open project
  build program
  answer one big question
  exit

orchestrated workflow:
  spawn worker
  initialize once
  open project once
  create snapshot
  answer many small questions
  reuse worker and snapshot
  close explicitly

前者はbatch処理として自然である． CIで全体を検査するなら，この形は今でもかなり素直だ．

後者はeditorやlint ruleやagentに近い． あるnodeの型を知りたい． 次にsymbolを解決したい． 少しvirtual documentを変えてもう一度知りたい． そのたびにproject全体をCLIとして開き直すのは，分散システムで毎requestごとにdatabase serverを起動するようなものだ．

だから僕がcorsa-bindで採用しているperformance modelは，「同じ仕事をしてtsgoに勝つ」ではなく，「同じengineの状態を再利用し，余計な仕事をしない」に近い． benchmarking guideでも，engine speedとwrapper speedを分け，cold runとwarm runを分け，session reuseやtransportの違いを別々に見る，という考え方を取っている．

良い主張は「corsa-bindはtsgoより速い」ではない． 良い主張は，「warmなeditor workflowでは，毎回tsgo --noEmitを走らせ直すより，live sessionを再利用する方が安くなる」である．

この違いは小さく見えて，かなり大きい． 速いコンパイラを作る話ではなく，コンパイラを含む処理系をどのように配置し，どの状態を再利用し，どのqueryをどのworkerに投げるか，という話になるからだ．

言い換えると，これはcompilerから離れる話ではない． むしろcompilerを一つの実行ファイルや一回きりの関数としてではなく，長生きするserviceとして扱う話である． parser，binder，checker，program graphはcompilerの中核だが，それらをいつ起動し，どこに置き，どのconsumerに共有し，どの単位で問い合わせるかは，compilerの外側にある設計問題になる．

僕がcorsa-bindで触りたいのは，この外側である． compiler engineの意味論はupstreamのtsgoに任せる． そのうえで，compilerを囲むtransportとlifetimeとcacheの層を設計する．

snapshotは値ではなく，遠隔の状態へのhandleである

僕がcorsa-bindで重要視している概念の一つがsnapshotである．

snapshotは，単なるJSONの値ではない． 少なくとも僕がorchestratorを書く視点では，それはworker側にある言語処理系の状態へのhandleである．

かなり雑に書くと，こういう関係になる．

ApiClient
  owns worker process
  owns transport
  initializes tsgo session

ManagedSnapshot
  points to snapshot state inside that session
  can be reused for type / symbol / syntax queries
  releases remote state when dropped or closed

この「handleである」という見方が大事だ．

普通のlibrary callでは，関数に値を渡し，戻り値を受け取る． しかしstdio越しのtsgoでは，重い状態はworker側に残る． callerはそれを識別するhandleを持ち，次のrequestでそのhandleを参照する．

これはdatabase connectionやactor systemにかなり近い． 「このsnapshotに対して，このfileのこの位置のtypeを教えてくれ」と聞く． 「このvirtual documentを反映したsnapshotを作ってくれ」と頼む． 「もう使わないのでreleaseしてくれ」と伝える．

つまり，言語処理系の内部状態を，プロセス境界の外からlifetime管理している． ここを雑にすると，速さ以前に正しさが壊れる． snapshotを解放し忘れればworker側の資源が残るし，process cleanupを軽く見るとzombie processや後続benchmarkの歪みにつながる．

だから僕はcorsa-bindで，typed clientだけでなく，timeout，graceful shutdown，observer event，queue capacityのようなoperationalな要素も同じ設計面に出している． それはbindingというより，少し小さな運用基盤である．

分散サーバーのように考える

この発想をもう一段進めると，僕にはcorsa-bindが分散サーバーに似て見えてくる．

もちろん，単一マシン上でtsgo workerを複数起動しているだけなら，本当にネットワーク越しのdistributed systemではない． しかし設計上の問題はかなり似ている．

• どのworkerにrequestを投げるか

• workerをいつ起動し，いつ止めるか

• coldなworkerとwarmなworkerをどう扱うか

• どのsnapshotを再利用できるか

• workerが落ちたとき，どこまで復旧できるか

• timeoutしたrequestをどう扱うか

• transportをJSON-RPCにするかmsgpackにするか

• 観測可能なeventをどの粒度で出すか

これは「コンパイラAPIを呼ぶ」だけの話ではない． 小さなclusterを扱っているのに近い．

たとえばApiProfileのような概念は，単にspawn configに名前を付けているだけではない． どのtsgo executableを使い，どのcwdで起動し，どのtransportを使い，どのtimeoutとobserverを付けるか，というworkerの性格を安定した名前で扱うためのものだ．

概念的には，こうなる．

profile: "default-msgpack"
  -> worker pool
    -> worker 1
      -> session
      -> snapshots
    -> worker 2
      -> session
      -> snapshots

profile: "lsp-jsonrpc"
  -> worker pool
    -> worker 1
      -> lsp session
      -> virtual documents

workerがdatabase shardのように振る舞う，とまでは言いすぎかもしれない． しかし「状態を持つ遠隔の処理主体を，client側のorchestratorが束ねる」という意味では，同じ設計語彙がかなり使える．

プロセスはnodeである． snapshotはremote stateへのhandleである． requestはmessageである． transportはwire formatである． profileはdeployment unitである． observerはtelemetryである． cleanupはcorrectnessである．

この比喩で見ると，言語処理系のAPI設計は急に面白くなる．

なぜupstreamをforkしないのか

僕はcorsa-bindのREADMEに，かなりはっきりとno forks, no patchesの方針を置いている． ref/typescript-goをexact upstream checkoutとして扱い，upstream-supportedなentry pointに乗り，ローカルpatchを持たない．

これは単なる僕の潔癖ではない． オーケストレーション層を作るなら，土台の意味論を勝手に変えないことが重要になる．

もし僕がtsgo本体にpatchを当てて速くしたなら，その速さはcorsa-bindのorchestrationによるものなのか，compiler engineの改変によるものなのかが曖昧になる． benchmarkも読みにくくなる． upstream追従も難しくなる． 別言語bindingから見た互換性も怪しくなる．

だから僕は，境界を分ける．

tsgoは言語処理系のengineとしてupstreamのまま扱う． corsa-bindではその外側で，transport，typed request / response，session reuse，snapshot lifetime，Node binding，C ABI，その他のlanguage bindingを扱う．

この分離は，かなり健全だと思っている． compilerの中へ入り込んで全てを握るのではなく，compilerを一つの専門serverとして尊重し，その周囲で使い方を設計する．

これはUnix的でもあるし，microservice的でもある． ただし，ここで扱っているserverはHTTP serviceではなく，型検査器である．

Node bindingは作者体験の入口である

僕はcorsa-bindにRust側のclient / orchestratorだけでなく，napi-rsを使ったNode bindingも入れている． これは単にJavaScriptからRustを呼べるようにするためだけのものではない．

TypeScriptの型情報を使う道具の作者は，多くの場合JS / TSの側にいる． lint rule，code mod，editor extension，framework plugin，AI agentのtool adapterなどを書く人は，Rust crateを直接触りたいとは限らない．

一方で，毎回JS側で重いprotocol handlingを書き，process管理を書き，snapshotの寿命を自分で持つのもつらい． だからRust側でhot pathとprocess orchestrationを持ち，Node側には使いやすいsurfaceを出すようにしている．

僕がcorsa-oxlintでやっている方向性は，この考え方にかなり合っている． rule authorはJS / TSでruleを書く． しかし型情報の取得やtsgo workerとの会話は，Rust-backedな層が面倒を見る．

ここでも僕の主語は「binding」だけではない． 主語は，言語処理系を共有資源としてどう配るか である．

一つのcompilerから，複数のconsumerへ

従来のCLIでは，compilerとconsumerの関係は一対一になりやすかった．

tsc command
  -> compiler
  -> diagnostics

しかしeditorやtoolchainの実際の姿は，もっと多対一に近い．

editor hover
editor completion
lint rule
code action
AI agent
test runner
build watcher
  -> shared language-processing state

もちろん全てを本当に一つのprocessに集約すればよい，という話ではない． fault isolationも必要だし，queryの性質によってworkerを分けた方がよい場合もある． read-heavyな型queryと，virtual documentを激しく差し替えるworkflowを同じsessionに押し込むべきかは，慎重に見るべきだ．

だからこそorchestratorが必要になる．

orchestratorは，compilerを隠すためのwrapperではない． compilerを中心に複数のconsumerを配置するためのcontrol planeである．

control planeという言葉を使うと少し大げさだが，やっていることは近い． どのprofileでworkerを作るか． どのworkerがwarmか． どのsnapshotがまだ使えるか． どのrequestが詰まっているか． どのtransportがそのworkflowに向いているか． どの失敗をretryし，どれをcallerに返すか．

こういう判断は，compiler engineそのものとは別の層にある．

言語処理系はこれから常駐する

僕は，今後の言語処理系はますます常駐プロセスとして扱われると思っている．

理由は単純で，開発体験がbatchからconversationへ寄っているからだ．

人間がファイルを保存したら一回検査する，というだけではない． エディタは入力中に候補を出す． リンターはASTと型を見ながらruleを走らせる． AI agentは「このnodeの型は何か」「このsymbolはどこから来たか」「この修正でdiagnosticは消えるか」を細かく聞く． frameworkはvirtual fileを生成し，元ファイルと対応付ける．

こういう世界では，言語処理系は毎回起動するcommandというより，問い合わせを受け続けるserviceになる．

そしてserviceになるなら，そこにはorchestrationが必要になる． worker pool，cache，snapshot，backpressure，timeout，observability，graceful shutdown，version pinning，compatibility policyが必要になる．

僕はcorsa-bindで，tsgoという具体的な対象を通して，この層を作っている．

言語処理系はparserとcheckerだけでは終わらない． それをどう生かし続け，どう共有し，どう壊れたときに畳み，どう別言語の作者体験へ渡すかまで含めて，これからのlanguage toolingになる．

結

tsgoは速いtscである． しかし，それだけでは少しもったいない．

stdio APIを通して見ると，tsgoは状態を持つ言語処理系serverでもある． そして僕がcorsa-bindで作っているのは，そのserverをRustとNodeと複数のnative bindingから扱うためのorchestration layerである．

僕が大事にしているのは，compiler engineそのものを無理に抱え込まないことだ． upstreamのtsgoを尊重し，forkせず，patchせず，その代わり外側でsessionを再利用し，snapshotを管理し，transportを選び，workerを束ねる．

これは，分散サーバーを扱うときの考え方に近い． processがいて，messageが流れ，remote stateへのhandleがあり，lifetimeがあり，失敗があり，観測があり，cleanupがある．

言語処理系をlibraryとして呼ぶだけでなく，serviceとして運用する．

それが，僕がcorsa-bindで作ろうとしている言語処理系オーケストレーションである．

この記事は100% AIによって出力したものであり，使用したモデルはGPT-5.5である．

序

このサイトの背景には，薄い透明水彩のような紙と滲みを置いている． 見た目はただの装飾だが，実装は一枚画像ではない． WebGPUで紙を描き，WebGL2で濡れた顔料を少しだけ動かし，Canvas 2Dのfallbackを持ち，mobileでは静的な背景へ落とす．

最初に大事なのは，これは「Web上で正確な水彩シミュレーションを作る」話ではない． 文章サイトの背景に，正確な流体シミュレーションはいらない． むしろ正確にやろうとした瞬間に，背景が本文より偉くなる．

背景に必要なのは，次のくらいでよい．

• 紙に凹凸と繊維がある

• 顔料が均一な半透明色ではない

• 濡れている間だけ少し動く

• 乾いたら紙に固定される

• 動かせない環境では静かに止まる

• 本文，リンク，スクロールを邪魔しない

実装を読み直すと，水彩らしさはshaderの派手さよりも，この分割で作っていることが分かる． 紙，濡れ，乾き，入力，fallbackを別々にして，それぞれの失敗範囲を小さくする． この設計がほぼすべてである．

背景は強くならない

画面上の層はだいたいこうなっている．

paper fallback span
paper fallback canvas
paper WebGPU canvas
brush canvas
page content
controls

Vue componentのtemplateは，layerを置くだけに近い．

<div class="watercolor-bg-container" aria-hidden="true">
  <span ref="fallbackLayerElement" class="paper-fallback" />
  <canvas ref="fallbackCanvasElement" class="paper-fallback-canvas" aria-hidden="true" />
  <canvas ref="paperCanvasElement" class="paper-canvas" aria-hidden="true" />
  <canvas ref="brushCanvasElement" class="brush-canvas" aria-hidden="true" />
</div>

aria-hidden="true"なのは，これは内容ではなく素材だからだ． screen readerにcanvasの存在を知らせる必要はない．

CSSでも，container自体は巨大なfixed overlayにしない． 固定されるのは個々のcanvasで，containerは本文の上に覆いかぶさらない．

.watercolor-bg-container {
  position: static;
  pointer-events: auto;
  background: transparent;
}

.paper-fallback-canvas,
.paper-canvas,
.brush-canvas {
  position: fixed;
  inset: 0;
  pointer-events: none;
}

pointer-events: noneがかなり重要である． 背景は画面全体にあるが，リンクもスクロールも奪わない． 見た目は広いが，DOM上の権限は弱い． 文章サイトの装飾は，このくらい弱い方がよい．

islandも常に起こさない

この背景はVuerendのislandとして登録している． ただし，すべてのviewportでhydrateするわけではない．

const desktopIslandMedia = "(min-width: 769px)";

export const WatercolorBackgroundIsland = defineIsland("watercolor-background", {
  component: WatercolorBackgroundIslandView,
  load: () => import("./features/ShellWatercolorBackgroundIslandLoader"),
  hydrate: "media",
  media: desktopIslandMedia,
});

desktop幅のときだけclient codeを読む． mobileではCSSでcanvasを隠し，bg-sp.pngを使う．

@media (max-width: 768px) {
  html {
    background: #f1eedf url("/bg-sp.png") center center / cover no-repeat;
  }

  .paper-fallback {
    opacity: 1 !important;
    background: #f1eedf url("/bg-sp.png") center center / cover no-repeat;
  }

  .paper-fallback-canvas,
  .paper-canvas,
  .brush-canvas {
    display: none;
  }
}

これは妥協というより，背景としての仕様だと思う． touch-firstな環境で，水彩brushを有効にしても嬉しさより事故の方が大きい． mobileでは静的な紙を出す． それで十分なところでは，十分なことだけをする．

pointer入力も同じで，fine pointerの環境だけ受ける．

export function canUseFinePointerPaint(): boolean {
  return window.matchMedia("(hover: hover) and (pointer: fine)").matches;
}

背景の実装は，「何をできるか」だけでなく，「どこではやらないか」を先に決めると安定する．

紙は先に出す

WebGPUの紙shaderは非同期で初期化される． だから，その前にCanvas 2Dでfallback紙を描く．

renderPaperFallback(fallbackCanvasElement.value, maxDpr);
brushLayer.resize();
removeViewportListeners = addShellViewportListeners(queueResize);

fallback紙は単色ではない． 薄いradial wash，shadow patch，highlight patch，fiber，grain tileを重ねる．

context.fillStyle = "#f1eedf";
context.fillRect(0, 0, width, height);
drawRadialWash(context, width, height);

context.globalCompositeOperation = "multiply";
drawPaperPatches(context, width, height, random, Math.round(820 * areaScale), "shadow");

context.globalCompositeOperation = "screen";
drawPaperPatches(context, width, height, random, Math.round(520 * areaScale), "highlight");

WebGPUが成功したら，fallbackのopacityを下げる． 完全には消さない．

target.fallbackLayer?.style.setProperty("opacity", "0.1");
target.fallbackCanvas?.style.setProperty("opacity", "0.16");

この順番が大事である． WebGPUが速ければshaderの紙が見える． 遅ければfallback紙が見える． 失敗しても，ただ紙が残る． 背景の失敗としては，それでよい．

紙はWebGPUで一枚だけ焼く

WebGPU側は，ShellSitePaper.wgslをraw importして使っている．

import sitePaperShaderSource from "./ShellSitePaper.wgsl?raw";

export const sitePaperShader = sitePaperShaderSource;

adapterはlow-powerで要求する．

const adapter = await gpu.requestAdapter({ powerPreference: "low-power" });

背景の紙を描くために，高性能GPUを起こす必要はない． 描画もfullscreen triangle一枚で済ませる．

var positions = array<vec2f, 3>(
  vec2f(-1.0, -1.0),
  vec2f(3.0, -1.0),
  vec2f(-1.0, 3.0)
);

DPRは1.25で切っている．

const dpr = Math.min(window.devicePixelRatio || 1, maxDpr);

紙のざらつきは，native DPRまで上げなくても読める． 背景に必要な解像度と，画面の物理解像度は同じではない． ここで欲しいのは精密な紙の顕微鏡画像ではなく，本文の後ろで紙だと分かることだ．

紙は動かさない

紙shaderにはtimeを渡していない． 紙の座標はviewportとseedから決まる．

let aspect = uniforms.resolution.x / max(uniforms.resolution.y, 1.0);
let centered = (input.uv - 0.5) * vec2f(aspect * 1.72, 1.72);
let point =
  rotate(centered * vec2f(1.0, 1.04), -0.06)
  + vec2f(uniforms.seed * 6.4, uniforms.seed * 3.2);

紙が読んでいる最中に動くと，水彩紙ではなく演出になる． 背景に置く紙は，動かない方が強い．

shaderの中では，単なる色noiseではなく，高さ場を作っている． embossField，microGrainField，fiberField，celluloseNetworkField，coldPressToothField，crumpleField，wrinkleLineFieldのような場がある． それらをpaperHeightへ混ぜる．

return macroRelief * 0.34
  + detail.x * 2.16
  + micro * (0.76 + uniforms.fiberDensity * 0.16 + uniforms.grainScale * 0.1)
  + (emboss - 0.18) * (0.18 + uniforms.embossDepth * 0.24)
  + (tooth.y - 0.28) * (0.46 + uniforms.embossDepth * 0.34)
  - (tooth.x - 0.18) * (0.34 + uniforms.shadowStrength * 0.22)
  + (grain - 0.5) * 0.018
  + (pulp - 0.3) * 0.018;

tooth.yは凸部，tooth.xは凹部として効く． この符号の違いが，紙の上に顔料が乗ったときの説得力になる． 紙は白い背景ではなく，顔料が沈む地形である．

紙shaderの処理を手順にすると，こうなる．

1. uvを紙座標へ変換する
2. 低周波のmacro reliefを作る
3. fiber / fibril / cellulose / tooth / pulpの場を別々に作る
4. それらを高さfieldへ合成する
5. 高さfieldを近傍sampleして法線を作る
6. 法線，局所relief，toothからcavity / ridge maskを作る
7. 暖かい白にcavity shadowとridge highlightを混ぜる

法線は解析的に出していない． paperHeightを少しずらしてsampleし，差分から作っている．

fn paperNormal(point: vec2f) -> vec3f {
  let epsilon = 0.00076;
  let center = paperHeight(point);
  let dx = paperHeight(point + vec2f(epsilon, 0.0)) - center;
  let dy = paperHeight(point + vec2f(0.0, epsilon)) - center;
  let strength = 3.1 + uniforms.embossDepth * 2.2 + uniforms.grainScale * 1.1;
  return normalize(vec3f(-dx * strength, -dy * strength, 1.0));
}

その法線と紙目から，凹みと山を別々に見る．

let cavityMask = saturate(
  max(0.0, -localRelief * 1.84)
    + tooth.x * 0.68
    + (1.0 - normal.z) * 0.4
    + max(0.0, -diffuse) * 0.16
    + crumple.x * 0.08
    + wrinkleLines.x * 0.05
);

let ridgeMask = saturate(
  max(0.0, localRelief * 1.42)
    + tooth.y * 0.62
    + detail.y * 0.06
    + max(0.0, diffuse) * 0.18
    + crumple.y * 0.06
    + wrinkleLines.y * 0.04
);

ここでcavityを暗くしすぎないのも大事である． 背景紙なので，凹凸が見えても本文のcontrastを奪ってはいけない． 最後はclamp(tone, vec3f(0.72), vec3f(1.0))で沈みすぎを止める．

ブラシはstampではなく濡れた状態

最初の発想として，Canvas 2Dで有機的な形を重ねれば水彩っぽく見える． 実際，fallback brushはそうしている． ただ，それだけだと「半透明の画像を押している」感じが残る． 水彩らしさには，描いたあとに少しだけ状態が変わる時間がいる．

そこで通常pathではWebGL2の小さなsolverを使う． ただし，これも最初から起動しない．

const fallback = createBrushLayer(options);
let engine: FluidBrushEngine | undefined;
let triedEngine = false;

function ensureEngine(): FluidBrushEngine | undefined {
  if (engine || triedEngine) {
    return engine;
  }

  triedEngine = true;
  engine = FluidBrushEngine.create();
  return engine;
}

WebGL2やfloat framebufferが使えなければ，Canvas 2D brushへ戻る．

if (!gl || !gl.getExtension("EXT_color_buffer_float")) {
  return undefined;
}

solverは画面全体の解像度では動かさない． base sizeは560で，aspectに合わせて小さなtextureを作る．

const simulationBaseSize = 560;

背景の滲みは，細かすぎるsimulationよりも少し鈍い方がよい． 解像度を下げることが，見た目にも性能にも効く．

流体の章は，まずこの1行だけで読める．

筆先が wet を置く -> velocity が wet を少し運ぶ -> pressure が暴れを抑える -> 古い wet が dry になる

目で追う対象は，青いwetのしみだけでよい． 矢印のvelocityはそのしみを動かす力で，赤いpressureは破裂しそうな流れをならすためのブレーキで，橙のdryは紙に固定された跡である． この見方は，three.jsのX投稿を見て，水彩背景の実装を自分のコードに引き寄せて読み直したものである．

brush solverの1 frameは，ざっくり次のpipelineになっている．

curl
vorticity confinement
advect velocity
boundary velocity
advect wet
boundary wet
dry wet into dry
remove dried wet
divergence
pressure solve
subtract pressure gradient
boundary velocity
display

<div> <svg viewBox="0 0 760 360" role="img" aria-labelledby="fluid-frame-title-ja"> <title id="fluid-frame-title-ja">WebGL2 brush solver の1 frame pipeline</title> <defs> <marker id="arrow-fluid-frame-ja" viewBox="0 0 10 10" refX="8.5" refY="5" markerWidth="5" markerHeight="5" orient="auto-start-reverse"> <path d="M 0 0 L 10 5 L 0 10 z" fill="#35495e" /> </marker> <linearGradient id="code-wash-fluid-frame-ja" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" stop-color="#5a8abf" stop-opacity="0.045" /> <stop offset="72%" stop-color="#5a8abf" stop-opacity="0" /> </linearGradient> </defs> <rect x="0" y="0" width="760" height="360" fill="url(#code-wash-fluid-frame-ja)" /> <path d="M 0 0.5 H 760 M 0 359.5 H 760" stroke="#2f3b47" stroke-opacity="0.16" /> <text x="48" y="62" font-size="18" font-weight="700" fill="#35495e">1 frame の見取り図</text> <g font-family="system-ui, sans-serif" font-size="14" text-anchor="middle"> <ellipse cx="112" cy="119" rx="70" ry="32" fill="#64d4a3" opacity="0.16" /> <text x="112" y="115" fill="#35495e">curl</text> <text x="112" y="133" fill="#666">渦度を測る</text> <line x1="184" y1="119" x2="204" y2="119" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-ja)" /> <ellipse cx="281" cy="119" rx="76" ry="32" fill="#64d4a3" opacity="0.16" /> <text x="281" y="115" fill="#35495e">vorticity</text> <text x="281" y="133" fill="#666">渦を少し戻す</text> <line x1="358" y1="119" x2="382" y2="119" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-ja)" /> <ellipse cx="455" cy="119" rx="76" ry="32" fill="#646cff" opacity="0.13" /> <text x="455" y="115" fill="#35495e">advect u</text> <text x="455" y="133" fill="#666">速度を運ぶ</text> <line x1="532" y1="119" x2="556" y2="119" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-ja)" /> <ellipse cx="629" cy="119" rx="76" ry="32" fill="#646cff" opacity="0.13" /> <text x="629" y="115" fill="#35495e">advect wet</text> <text x="629" y="133" fill="#666">顔料を運ぶ</text> <line x1="629" y1="154" x2="629" y2="184" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-ja)" /> <ellipse cx="629" cy="219" rx="76" ry="32" fill="#f59e0b" opacity="0.14" /> <text x="629" y="215" fill="#35495e">dry</text> <text x="629" y="233" fill="#666">wet を dry へ</text> <line x1="552" y1="219" x2="530" y2="219" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-ja)" /> <ellipse cx="455" cy="219" rx="76" ry="32" fill="#ff6b6b" opacity="0.1" /> <text x="455" y="215" fill="#35495e">divergence</text> <text x="455" y="233" fill="#666">膨張を測る</text> <line x1="380" y1="219" x2="358" y2="219" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-ja)" /> <ellipse cx="281" cy="219" rx="76" ry="32" fill="#ff6b6b" opacity="0.1" /> <text x="281" y="215" fill="#35495e">pressure</text> <text x="281" y="233" fill="#666">8回反復</text> <line x1="204" y1="219" x2="184" y2="219" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-ja)" /> <ellipse cx="112" cy="219" rx="70" ry="32" fill="#ff6b6b" opacity="0.1" /> <text x="112" y="215" fill="#35495e">gradient</text> <text x="112" y="233" fill="#666">圧力を引く</text> <line x1="112" y1="252" x2="112" y2="282" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-ja)" /> <path d="M 60 302 C 200 292 388 292 692 302" fill="none" stroke="#fcb32c" stroke-width="28" stroke-linecap="round" opacity="0.14" /> <text x="373" y="307" fill="#35495e">display: wet / dry を透明な brush canvas へ戻す</text> </g> </svg> </div>

完全なNavier-Stokes solverではない． ただ，速度場に渦を少し戻し，semi-Lagrangian advectionで濡れた顔料を運び，pressure projectionで発散を抑える． 背景としては，このくらいのstable fluidsで十分だった．

まず粒子を追っていない

流体と聞くと，水の粒をたくさん置いて，その粒を追いかける絵を想像しやすい． でもこの実装は粒子を追っていない． 画面より小さいtexture gridを用意して，各pixelに「ここでは水がどちらへ流れているか」と「ここにはどれくらい濡れた顔料があるか」を持たせている．

つまり，考える対象は粒ではなく場である．

各pixel:
  velocity = その場所の水の向き
  wet      = その場所の濡れた顔料
  dry      = その場所の乾いた顔料

1つのstrokeは，だいたい次のように変わる．

<div> <svg viewBox="0 0 760 520" role="img" aria-labelledby="toy-fluid-title-ja"> <title id="toy-fluid-title-ja">1つの筆跡が wet / velocity / dry に分かれていく様子</title> <defs> <marker id="arrow-toy-fluid-ja" viewBox="0 0 10 10" refX="8.5" refY="5" markerWidth="5" markerHeight="5" orient="auto-start-reverse"> <path d="M 0 0 L 10 5 L 0 10 z" fill="#35495e" /> </marker> <radialGradient id="wet-blob-ja" cx="50%" cy="50%" r="60%"> <stop offset="0%" stop-color="#646cff" stop-opacity="0.46" /> <stop offset="70%" stop-color="#646cff" stop-opacity="0.18" /> <stop offset="100%" stop-color="#646cff" stop-opacity="0" /> </radialGradient> <radialGradient id="dry-blob-ja" cx="50%" cy="50%" r="60%"> <stop offset="0%" stop-color="#f59e0b" stop-opacity="0.42" /> <stop offset="80%" stop-color="#f59e0b" stop-opacity="0.16" /> <stop offset="100%" stop-color="#f59e0b" stop-opacity="0" /> </radialGradient> <linearGradient id="code-wash-toy-fluid-ja" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" stop-color="#5a8abf" stop-opacity="0.045" /> <stop offset="72%" stop-color="#5a8abf" stop-opacity="0" /> </linearGradient> </defs> <rect x="0" y="0" width="760" height="520" fill="url(#code-wash-toy-fluid-ja)" /> <path d="M 0 0.5 H 760 M 0 519.5 H 760" stroke="#2f3b47" stroke-opacity="0.16" /> <text x="48" y="62" font-size="18" font-weight="700" fill="#35495e">青い wet が動き，橙の dry として残る</text> <g font-family="system-ui, sans-serif" font-size="14"> <path d="M 380 92 L 380 442 M 58 266 L 702 266" stroke="#ddd" stroke-width="1" opacity="0.5" /> <text x="80" y="120" fill="#35495e" font-weight="700">0. splat</text> <text x="80" y="142" fill="#666">pointer位置に wet と velocity を足す</text> <ellipse cx="210" cy="180" rx="46" ry="30" fill="url(#wet-blob-ja)" /> <circle cx="210" cy="180" r="7" fill="#646cff" /> <path d="M 210 180 L 264 160" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-toy-fluid-ja)" /> <path d="M 210 180 L 260 202" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-toy-fluid-ja)" /> <path d="M 210 180 L 174 208" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-toy-fluid-ja)" />

<text x="424" y="120" fill="#35495e" font-weight="700">1. advect</text> <text x="424" y="142" fill="#666">velocity が wet を少し運ぶ</text> <ellipse cx="534" cy="182" rx="58" ry="28" transform="rotate(10 534 182)" fill="url(#wet-blob-ja)" /> <path d="M 478 176 C 520 158 564 164 610 188" fill="none" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-toy-fluid-ja)" /> <path d="M 482 208 C 528 194 574 198 616 220" fill="none" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-toy-fluid-ja)" />

<text x="80" y="314" fill="#35495e" font-weight="700">2. project</text> <text x="80" y="336" fill="#666">膨らみすぎる速度を pressure でならす</text> <circle cx="204" cy="390" r="36" fill="#ff6b6b" opacity="0.12" /> <path d="M 204 390 L 204 354" stroke="#ff6b6b" stroke-width="2" marker-end="url(#arrow-toy-fluid-ja)" /> <path d="M 204 390 L 242 390" stroke="#ff6b6b" stroke-width="2" marker-end="url(#arrow-toy-fluid-ja)" /> <path d="M 204 390 L 204 426" stroke="#ff6b6b" stroke-width="2" marker-end="url(#arrow-toy-fluid-ja)" /> <path d="M 204 390 L 166 390" stroke="#ff6b6b" stroke-width="2" marker-end="url(#arrow-toy-fluid-ja)" /> <path d="M 292 362 C 326 380 326 416 292 438" fill="none" stroke="#42b883" stroke-width="3" marker-end="url(#arrow-toy-fluid-ja)" /> <text x="80" y="450" fill="#666">外向きの破裂を抑える</text>

<text x="424" y="314" fill="#35495e" font-weight="700">3. dry</text> <text x="424" y="336" fill="#666">wet は減り，dry が紙に残る</text> <ellipse cx="540" cy="382" rx="62" ry="30" transform="rotate(8 540 382)" fill="url(#dry-blob-ja)" /> <ellipse cx="566" cy="370" rx="36" ry="18" transform="rotate(8 566 370)" fill="url(#wet-blob-ja)" opacity="0.55" /> <path d="M 494 402 C 528 416 576 412 616 392" fill="none" stroke="#f59e0b" stroke-width="3" opacity="0.7" /> <text x="424" y="430" fill="#666">乾いた部分はもう移流しない</text> </g> <g font-family="system-ui, sans-serif" font-size="13"> <circle cx="78" cy="470" r="7" fill="#646cff" opacity="0.55" /> <text x="94" y="475" fill="#35495e">青 = まだ動く wet</text> <line x1="222" y1="470" x2="260" y2="470" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-toy-fluid-ja)" /> <text x="272" y="475" fill="#35495e">矢印 = velocity</text> <circle cx="406" cy="470" r="7" fill="#f59e0b" opacity="0.6" /> <text x="422" y="475" fill="#35495e">橙 = 紙に固定された dry</text> <circle cx="574" cy="470" r="7" fill="#ff6b6b" opacity="0.45" /> <text x="590" y="475" fill="#35495e">赤 = pressure の補正</text> </g> </svg> </div>

この図で言うと，流体solverが毎frame動かすのは主にvelocityとwetである． dryはそこから外される． だから顔料は，最初だけ水に乗って動き，だんだん紙に固定されていく．

流体の場はtextureとして持つ

solverはCPU上の配列ではなく，WebGL2のRGBA16F textureとして場を持つ． 各passはfullscreen triangleを一枚描き，fragment shaderで次のtextureを書き込む． 読み書きが同じtextureになると壊れるので，velocity，wet，dry，pressureはread/writeを持つping-pong bufferである．

velocity.xy   速度
velocity.zw   未使用 / alphaの余白
wet.rgb       濡れた顔料の吸収量
wet.a         濡れ量
dry.rgb       乾いた顔料の吸収量
dry.a         乾いた量
pressure.x    圧力
divergence.x  速度場の発散
curl.x        2D速度場の渦度

<div> <svg viewBox="0 0 760 340" role="img" aria-labelledby="fluid-textures-title-ja"> <title id="fluid-textures-title-ja">流体solverが持つtexture field</title> <defs> <marker id="arrow-fluid-textures-ja" viewBox="0 0 10 10" refX="8.5" refY="5" markerWidth="5" markerHeight="5" orient="auto-start-reverse"> <path d="M 0 0 L 10 5 L 0 10 z" fill="#35495e" /> </marker> <linearGradient id="code-wash-fluid-textures-ja" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" stop-color="#5a8abf" stop-opacity="0.045" /> <stop offset="72%" stop-color="#5a8abf" stop-opacity="0" /> </linearGradient> </defs> <rect x="0" y="0" width="760" height="340" fill="url(#code-wash-fluid-textures-ja)" /> <path d="M 0 0.5 H 760 M 0 339.5 H 760" stroke="#2f3b47" stroke-opacity="0.16" /> <text x="48" y="62" font-size="18" font-weight="700" fill="#35495e">field は texture として並んでいる</text> <g font-family="system-ui, sans-serif" font-size="14" text-anchor="middle"> <ellipse cx="124" cy="130" rx="78" ry="42" fill="#646cff" opacity="0.1" /> <text x="124" y="121" fill="#35495e" font-weight="700">velocity</text> <text x="124" y="143" fill="#666">xy = 水の流れ</text> <ellipse cx="290" cy="130" rx="78" ry="42" fill="#42b883" opacity="0.12" /> <text x="290" y="121" fill="#35495e" font-weight="700">wet</text> <text x="290" y="143" fill="#666">rgb = 濡れ顔料</text> <ellipse cx="456" cy="130" rx="78" ry="42" fill="#f59e0b" opacity="0.12" /> <text x="456" y="121" fill="#35495e" font-weight="700">dry</text> <text x="456" y="143" fill="#666">rgb = 乾いた顔料</text> <ellipse cx="622" cy="130" rx="78" ry="42" fill="#ff6b6b" opacity="0.1" /> <text x="622" y="121" fill="#35495e" font-weight="700">pressure</text> <text x="622" y="143" fill="#666">x = 圧力</text> <text x="196" y="232" fill="#35495e">read texture</text> <path d="M 128 244 C 162 250 230 250 264 244" fill="none" stroke="#8899aa" stroke-width="2" opacity="0.55" /> <text x="380" y="208" fill="#666" font-size="13">shader pass で write へ描く</text> <line x1="282" y1="224" x2="476" y2="224" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-textures-ja)" /> <text x="564" y="232" fill="#35495e">write texture</text> <path d="M 496 244 C 530 250 598 250 632 244" fill="none" stroke="#8899aa" stroke-width="2" opacity="0.55" /> <path d="M 564 260 C 520 306 240 306 196 260" fill="none" stroke="#f59e0b" stroke-width="2" marker-end="url(#arrow-fluid-textures-ja)" /> <text x="380" y="316" fill="#666">swap: write が次の read になる</text> </g> </svg> </div>

流体として見ると，毎frameでやりたいことはこうである．

u = velocity
w = wet pigment
d = dry pigment

u <- add vorticity(u)
u <- advect(u, u)
w <- advect(w, u)
d, w <- dry(w, d)
u <- project(u)

ここでdryは移流しない． 紙に固定された顔料だからだ． 水彩っぽさは，動く場を増やすことより，動かない場を決めることで出ている．

移流は戻ってsampleする

移流はsemi-Lagrangian advectionである． 現在のpixelに来た量は，ひとつ前の時刻では速度のぶんだけ上流にあった，とみなす． だから現在位置vUvから逆向きに戻ってsampleする．

<div> <svg viewBox="0 0 760 320" role="img" aria-labelledby="advection-title-ja"> <title id="advection-title-ja">semi-Lagrangian advection のbacktrace</title> <defs> <marker id="arrow-advection-ja" viewBox="0 0 10 10" refX="8.5" refY="5" markerWidth="5" markerHeight="5" orient="auto-start-reverse"> <path d="M 0 0 L 10 5 L 0 10 z" fill="#35495e" /> </marker> <linearGradient id="code-wash-advection-ja" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" stop-color="#5a8abf" stop-opacity="0.045" /> <stop offset="72%" stop-color="#5a8abf" stop-opacity="0" /> </linearGradient> </defs> <rect x="0" y="0" width="760" height="320" fill="url(#code-wash-advection-ja)" /> <path d="M 0 0.5 H 760 M 0 319.5 H 760" stroke="#2f3b47" stroke-opacity="0.16" /> <text x="48" y="62" font-size="18" font-weight="700" fill="#35495e">移流は「今の点から上流へ戻って読む」</text> <g stroke="#ddd" stroke-width="1"> <path d="M 84 88 L 84 256 M 144 88 L 144 256 M 204 88 L 204 256 M 264 88 L 264 256 M 324 88 L 324 256 M 384 88 L 384 256 M 444 88 L 444 256 M 504 88 L 504 256 M 564 88 L 564 256 M 624 88 L 624 256" /> <path d="M 64 108 L 660 108 M 64 148 L 660 148 M 64 188 L 660 188 M 64 228 L 660 228" /> </g> <g font-family="system-ui, sans-serif" font-size="14"> <text x="324" y="122" fill="#35495e" text-anchor="middle">前の時刻のsample位置</text> <circle cx="324" cy="150" r="8" fill="#42b883" /> <text x="520" y="122" fill="#35495e" text-anchor="middle">現在のpixel vUv</text> <circle cx="520" cy="166" r="8" fill="#646cff" /> <path d="M 520 166 C 472 132 386 126 324 150" fill="none" stroke="#35495e" stroke-width="3" marker-end="url(#arrow-advection-ja)" /> <text x="420" y="194" fill="#666" text-anchor="middle">速度分だけ逆に戻る</text> <path d="M 242 220 C 330 206 438 210 564 230" fill="none" stroke="#f59e0b" stroke-width="4" opacity="0.7" marker-end="url(#arrow-advection-ja)" /> <text x="380" y="260" fill="#666" text-anchor="middle">速度場 u は顔料を右下へ運ぼうとしている</text> <text x="70" y="294" fill="#35495e">coord = vUv - dt velocity texelSize</text> </g> </svg> </div>

vec2 vel = texture(uVelocity, vUv).xy;
vec2 coord = vUv - dt * vel * uTexelSize;
outColor = dissipation * texture(uSource, coord);

これをvelocity自身にも，wetにも使う．

this.run("advect", this.velocity.write, {
  dissipation: 0.986,
  dt,
  uSource: this.velocity.readTexture,
  uVelocity: this.velocity.readTexture,
});

this.run("advect", this.wet.write, {
  dissipation: 0.998,
  dt,
  uSource: this.wet.readTexture,
  uVelocity: this.velocity.readTexture,
});

velocityのdissipationは0.986で，wetは0.998である． 速度は早めに弱まり，顔料は少し長く残る． semi-Lagrangianは数値的に安定しやすいが，拡散したようにぼやける． このぼやけは，背景の滲みでは欠点になりにくい．

渦度を少し戻す

semi-Lagrangian移流は安定だが，細かい回転を失いやすい． そこで先にcurlを計算し，vorticity confinementで少し渦を戻す．

outColor = vec4(
  0.5 * (right.y - left.y - (top.x - bottom.x)),
  0.0,
  0.0,
  1.0
);

2Dではcurlはscalarとして持てる． 次のpassでは，curlの絶対値の勾配を見て，渦の中心へ押す方向を作る．

vec2 force = 0.5 * vec2(abs(top.x) - abs(bottom.x), abs(right.x) - abs(left.x));
force /= length(force) + 0.0001;
force *= strength * center * vec2(1.0, -1.0);
vec2 vel = texture(uVelocity, vUv).xy;
outColor = vec4(vel + force * dt, 0.0, 1.0);

strengthは18にしている． ここを上げると流れは派手になるが，背景としてはうるさくなる． 水彩の滲みで欲しいのは水面の渦ではなく，顔料が少し不均一に逃げることだ．

境界は場ごとに扱いを変える

各passのあとにboundary passを挟む． edge付近では隣の値を参照し，scaleを掛ける．

if (uv.x < uTexelSize.x) data = scale * texture(uTarget, uv + vec2(uTexelSize.x, 0.0));
if (uv.x > 1.0 - uTexelSize.x) data = scale * texture(uTarget, uv - vec2(uTexelSize.x, 0.0));
if (uv.y < uTexelSize.y) data = scale * texture(uTarget, uv + vec2(0.0, uTexelSize.y));
if (uv.y > 1.0 - uTexelSize.y) data = scale * texture(uTarget, uv - vec2(0.0, uTexelSize.y));

velocityではscale = -1にして壁で反転させる． wetではscale = 0にして外へ流れた濡れを消す． pressureではscale = 1で圧力を続ける． 同じboundary shaderでも，場の意味によって符号が違う．

pressure projectionで発散を抑える

速度場はsplatやvorticityで簡単に膨らむ． そこで発散を計算する．

outColor = vec4(
  0.5 * (right.x - left.x + top.y - bottom.y),
  0.0,
  0.0,
  1.0
);

発散がある場所は，流れが湧いているか吸い込んでいる場所である． これを抑えるために，Jacobi iterationで圧力を解く．

<div> <svg viewBox="0 0 760 320" role="img" aria-labelledby="projection-title-ja"> <title id="projection-title-ja">pressure projection の役割</title> <defs> <marker id="arrow-projection-ja" viewBox="0 0 10 10" refX="8.5" refY="5" markerWidth="5" markerHeight="5" orient="auto-start-reverse"> <path d="M 0 0 L 10 5 L 0 10 z" fill="#35495e" /> </marker> <linearGradient id="code-wash-projection-ja" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" stop-color="#5a8abf" stop-opacity="0.045" /> <stop offset="72%" stop-color="#5a8abf" stop-opacity="0" /> </linearGradient> </defs> <rect x="0" y="0" width="760" height="320" fill="url(#code-wash-projection-ja)" /> <path d="M 0 0.5 H 760 M 0 319.5 H 760" stroke="#2f3b47" stroke-opacity="0.16" /> <text x="48" y="62" font-size="18" font-weight="700" fill="#35495e">pressure projection は「湧き出し」をならす</text> <g font-family="system-ui, sans-serif" font-size="14" text-anchor="middle"> <ellipse cx="174" cy="171" rx="122" ry="84" fill="#ff6b6b" opacity="0.1" /> <text x="174" y="112" fill="#35495e" font-weight="700">projection 前</text> <text x="174" y="136" fill="#9f6464">divergence が大きい</text> <circle cx="174" cy="194" r="16" fill="#ff6b6b" opacity="0.35" /> <path d="M 174 194 L 174 160" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-projection-ja)" /> <path d="M 174 194 L 226 194" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-projection-ja)" /> <path d="M 174 194 L 174 238" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-projection-ja)" /> <path d="M 174 194 L 122 194" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-projection-ja)" /> <line x1="302" y1="171" x2="458" y2="171" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-projection-ja)" /> <text x="380" y="154" fill="#35495e">pressureを解く</text> <text x="380" y="194" fill="#666">∇p を速度から引く</text> <ellipse cx="586" cy="171" rx="122" ry="84" fill="#42b883" opacity="0.1" /> <text x="586" y="112" fill="#35495e" font-weight="700">projection 後</text> <text x="586" y="136" fill="#52745f">divergence を抑える</text> <path d="M 546 164 C 568 146 604 146 626 164" fill="none" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-projection-ja)" /> <path d="M 626 184 C 604 202 568 202 546 184" fill="none" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-projection-ja)" /> <path d="M 546 164 C 532 178 532 190 546 204" fill="none" stroke="#646cff" stroke-width="2" marker-end="url(#arrow-projection-ja)" /> <path d="M 626 184 C 640 170 640 158 626 144" fill="none" stroke="#646cff" stroke-width="2" marker-end="url(#arrow-projection-ja)" /> <text x="586" y="238" fill="#666">膨らみにくい流れになる</text> </g> </svg> </div>

float div = texture(uDivergence, vUv).x;
outColor = vec4(
  (left.x + right.x + bottom.x + top.x - div) * 0.25,
  0.0,
  0.0,
  1.0
);

そのあと，速度から圧力勾配を引く．

vec2 vel = texture(uVelocity, vUv).xy;
outColor = vec4(
  vel - 0.5 * vec2(right.x - left.x, top.x - bottom.x),
  0.0,
  1.0
);

これで完全に非圧縮になるわけではない． iterationは8回だけなので，かなり粗い． ただ，水彩背景では厳密な体積保存より，「strokeの周囲が破裂して見えない」ことの方が大事である．

wetとdryを分ける

WebGL2 solverが持つ中心的な状態は，velocity，wet，dry，pressureである．

velocity  水の流れ
wet       まだ動く顔料
dry       紙に固定された顔料
pressure 速度場を整えるための圧力

pointerから入ってきた色は，いきなりdryへ描かない． まずwetへ入れる． strokeでは，まず前回座標との差分から方向と速度を作る．

const speed = Math.hypot(stroke.deltaX, stroke.deltaY);
const directionX = speed > 0.00001 ? stroke.deltaX / speed : 1;
const directionY = speed > 0.00001 ? stroke.deltaY / speed : 0;
const radius = 0.00018 + stroke.pressure * 0.00034;
const force = Math.min(46, 8 + speed * 2200);
const opacity = Math.min(0.42, 0.18 + stroke.alpha * 3.8 + stroke.pressure * 0.045);

同じstrokeから，速度場と濡れ顔料の二つを更新する． 速度場には動きだけを入れ，濡れ顔料には吸収量を入れる．

this.splatBuffer(
  this.velocity,
  stroke.x,
  stroke.y,
  directionX * force,
  directionY * force,
  0,
  1,
  radius * 1.05,
  0,
  directionX,
  directionY,
);

this.splatBuffer(
  this.wet,
  stroke.x,
  stroke.y,
  (1 - stroke.red) * opacity,
  (1 - stroke.green) * opacity,
  (1 - stroke.blue) * opacity,
  opacity,
  radius,
  speed > 0.0009 ? 1 : 0,
  directionX,
  directionY,
);

RGBをそのまま色として足すのではなく，1 - rgbとして持つ． 顔料を「紙から光を引く量」として扱うためである． さらに中心だけでなく周辺6方向へ小さな速度を入れる． これは物理的に正確な毛細管現象ではないが，筆先の外側へ水が逃げる感じを作る．

for (let index = 0; index < 6; index += 1) {
  const angle = (index / 6) * Math.PI * 2;
  const offset = Math.sqrt(radius) * 0.42;
  const bloomX = clamp01(stroke.x + Math.cos(angle) * offset);
  const bloomY = clamp01(stroke.y + Math.sin(angle) * offset);
  this.splatBuffer(
    this.velocity,
    bloomX,
    bloomY,
    Math.cos(angle) * 28,
    Math.sin(angle) * 28,
    0,
    1,
    radius * 0.62,
    0,
    Math.cos(angle),
    Math.sin(angle),
  );
}

毎frameでは，velocityとwetだけを移流する． dryは動かさない．

vec2 vel = texture(uVelocity, vUv).xy;
vec2 coord = vUv - dt * vel * uTexelSize;
outColor = dissipation * texture(uSource, coord);

この分離がかなり効く． 濡れた顔料は動く． 乾いた顔料は動かない． それだけで，「透明な画像が画面上を広がる」から「紙に染みている」に近づく．

速度場はそのままだと膨らんだり縮んだりしすぎるので，発散を計算し，pressureを反復で解く．

this.run("divergence", this.divergence, {
  uVelocity: this.velocity.readTexture,
});
this.clearTarget(this.pressure.read);

for (let index = 0; index < pressureIterations; index += 1) {
  this.run("pressure", this.pressure.write, {
    uDivergence: this.divergenceTexture,
    uPressure: this.pressure.readTexture,
  });
  this.swap(this.pressure);
  this.applyBoundary(this.pressure, 1);
}

iterationは8回で止めている． 流体としては雑だが，背景のにじみとしては過不足が少ない． むしろ少し緩い方が，紙の不均一さに見える．

乾燥はdryAccumとdryWetの二つのpassで進む．

float density = max(max(w.r, w.g), w.b);
float thicknessFactor = 1.0 / (1.0 + density * thicknessK);
float wet1 = max(wet0 - dryRate * thicknessFactor * dt, 0.0);

濃い顔料ほど乾きにくい． 薄い水は先に消え，溜まった顔料は外縁やムラとして残る． 正確な物理ではないが，知覚としてはここが水彩に近い．

dryAccum側では，乾いた顔料へ単純加算するだけではなく，濃度に応じて置換も混ぜる．

vec3 transfer = w.rgb * frac * 1.015;
float coverage = 1.0 - exp(-density * 1.8);
vec3 headroom = max(vec3(dryCap) - d.rgb, vec3(0.0));
vec3 added = d.rgb + min(transfer, headroom);
vec3 replaced = mix(d.rgb, w.rgb, frac);
outColor = vec4(mix(added, replaced, coverage), min(d.a + dried, 4.0));

全部を加算すると重ね塗りで黒く沈みすぎる． 全部を置換すると透明水彩のglazeが消える． 薄いところは加算寄り，濃いところは置換寄りにすることで，薄い層と厚い溜まりの両方を残す．

表示は透明canvasへ戻す

solver内では，仮の紙色にwet/dryを重ねて色を作る．

vec3 paper = vec3(0.96, 0.945, 0.92);
vec3 afterDry = paper * exp(-dry.rgb * 2.2);
vec3 wetColor = paper * exp(-wet.rgb * 2.2);
vec3 glazed = afterDry * exp(-wet.rgb * 2.2);

でも実際のページには別のWebGPU紙がある． だから最終出力は不透明な絵ではなく，透明度を持ったbrush canvasへ戻す．

float density = max(wetDensity, dryDensity);
float edge = smoothstep(0.002, 0.018, length(vec2(dFdx(density), dFdy(density))));
float alpha = clamp(density * 1.15 + wetAmt * 0.18 + edge * 0.12, 0.0, 0.62);
outColor = vec4(color, alpha);

最後はWebGL canvasから2D canvasへcopyする．

context.clearRect(0, 0, canvas.width, canvas.height);
context.drawImage(this.canvas, 0, 0, canvas.width, canvas.height);

DOM側ではmix-blend-mode: multiplyで紙に沈ませる．

.brush-canvas {
  mix-blend-mode: multiply;
}

WebGPU紙とWebGL2 brushを直接一枚のrendererにまとめないのは，故障範囲を分けたいからだ． 紙だけ生きる，brushだけ消す，2D fallbackにする，mobileでは静止画にする． それぞれを別の層にした方が，背景として扱いやすい．

Canvas 2D fallbackも同じ考え方にする

WebGL2がない環境では，createBrushLayerが使われる． これは流体ではないが，wet/dryの考え方は残している．

dryLayer
wetLayer
wetBlooms
wetDryFrames

strokeはwetLayerへ描かれ，遅れてdryLayerへ移る．

dryContext.globalCompositeOperation = "multiply";
dryContext.globalAlpha = 0.026;
dryContext.drawImage(wetLayer, 0, 0);

wetContext.globalCompositeOperation = "destination-out";
wetContext.fillStyle = "rgba(0, 0, 0, 0.018)";
wetContext.fillRect(0, 0, wetLayer.width, wetLayer.height);

水彩らしさを作っているのは，WebGL2そのものではない． 「濡れている層」と「乾いた層」があり，その間に時間差があることだ． Canvas 2D fallbackでも，この契約だけは残す．

色はすぐ変えない

brush colorは36 drawごとに変える．

const brushColorHoldDraws = 36;

pointermoveごとに色を変えると，水彩ではなく虹色のペンになる． 同じ顔料が水で薄まりながら広がる時間が必要なので，色はしばらく保持する． paletteのalphaも0.04から0.05付近に抑えている．

派手な色替えではなく，薄い顔料が重なって濃くなる方を選ぶ． 透明水彩の背景としては，その方が読みやすい．

Vueにrenderer stateを載せない

Vueが持つstateは少ない．

const fallbackLayerElement = ref<HTMLElement>();
const fallbackCanvasElement = ref<HTMLCanvasElement>();
const paperCanvasElement = ref<HTMLCanvasElement>();
const brushCanvasElement = ref<HTMLCanvasElement>();
const isDrawingEnabled = ref(false);

WebGPU device，WebGL context，texture，framebuffer，wet/dry buffer，last pointer positionはVue reactivityに載せない． これらはUI stateではなくrenderer stateである．

Vueから見ると，brush layerはdraw，resize，clearを持つimperative objectでよい．

const brushLayer = createFluidBrushLayer({
  canvas: () => brushCanvasElement.value,
  isDrawingEnabled: () => isDrawingEnabled.value,
  maxDpr,
});

UI frameworkの中でgraphicsを動かすとき，全部をreactiveにしたくなる． でも，templateを更新しない値をreactiveにしても，追跡コストと混乱が増えるだけである． 描画器の内部状態は，描画器の中に閉じ込める．

後片付けを雑にしない

背景はwindowにlistenerを張る． だから，mountよりunmountを雑にすると後で効いてくる．

onUnmounted(() => {
  if (resizeFrame !== 0) {
    cancelAnimationFrame(resizeFrame);
  }
  removeViewportListeners?.();
  removeBrushListeners?.();
  paperCleanup?.();
});

WebGPU側もunconfigure()まで呼ぶ．

return () => {
  disposed = true;
  if (paperResizeFrame !== 0) {
    cancelAnimationFrame(paperResizeFrame);
  }
  removeViewportListeners();
  gpuContext.unconfigure();
};

背景は地味だが，ページ全体へ触る． だから，止め方も実装の一部である．

テストするのは美しさではない

水彩が「良い感じか」を自動テストするのは難しい． でも，壊したくない性質には分解できる．

このサイトのPlaywrightでは，たとえば次を見る．

• fallback canvasがblankではない

• .watercolor-bg-containerが本文を覆わない

• WebGPUがある環境ではpaper canvasが初期化される

• mobileではbg-sp.pngに落ち，canvasが消える

• tooltipがhover外で残らない

• brushの色が一stroke中に急に変わらない

• 滲みの外縁が遅れて増える，または濃くなる

• pointer eventのburstが一定時間内に終わる

pixel perfectではなく，性質を見る． これは背景表現には向いている． 絵の完全一致を守るより，本文を邪魔しないこと，blankにならないこと，滲みが時間差を持つことの方が大事だからだ．

まとめ

Webで透明水彩をやる技術は，流体をどこまで正確に解くかではなかった． このサイトでは，次の判断が効いている．

• 紙とbrushを別レイヤにする

• WebGPUの前にCanvas 2D fallback紙を出す

• 紙はWebGPUで一度焼き，timeで動かさない

• DPRを制限し，背景に不要なfragmentを払わない

• brushはfine pointerのdesktopだけで有効にする

• WebGL2 solverは遅延初期化し，失敗したらCanvas 2Dへ落ちる

• 顔料をwetとdryに分け，乾いた顔料は動かさない

• 色をすぐ変えず，同じ顔料が薄まる時間を残す

• renderer stateをVue reactivityに載せない

• mobileでは静的背景にする

• テストではpixelではなく壊したくない性質を見る

透明水彩らしさは，水と紙と顔料を全部正しく解くことではない． 読者が見ている時間の中で，紙があり，濡れがあり，乾きがあるように感じられればよい． そして，それができない環境では何もしない． 背景としては，その静かな失敗まで含めて実装である．

みなさんは，あることについて議論をするとき，どのような構造を念頭に置いているだろうか．

おそらく多くの人は，かなり自然に 限られたスコープの木 を前提にしている． いま話している根があり，その下に枝があり，その枝の中で話を進める． 脇道に逸れたら「いったん戻ろう」と言い，別の枝が見えたら「それは別論点」として切り分ける．

この態度は，実務上はかなり好まれやすい． 議論が暴れにくいように見えるし，会議の時間も読みやすくなるように見える． 人に説明するときも，木の形に落とした方が親切だ，と言われることが多い．

しかし私は，この前提が全く好きではない． もっと強く言えば，議論を木として進めることは正しくない と思っている．

情報の本質的な構造はグラフであり，木はその部分構造に過ぎない． 議論を木として進めることは，しばしば本来そこにあった辺を落とし，その欠落を正規の構造として扱うことでもある．

そして落とされた辺は，あとから「考慮不足」という名前で帰ってくる．

木は正しくない

グラフ理論の言葉を借りれば，木はだいたい「閉路のない連結グラフ」として捉えられる． つまり木は，グラフの特殊な形である． グラフの方が先にあり，木はそこに強い制約をかけたものだ．

この関係は，情報にもそのまま当てはまると思っている． 木で表せる情報があるのではなく，木で表せるほど単純な情報だけがたまたま木として扱える． そして議論は，ほとんどの場合，そんなに単純ではない．

ある情報が一つの親だけを持つとは限らない． ある論点が一つの根だけに従属するとも限らない． ある判断材料が一つの枝の中だけで完結するとも限らない．

実際，ファイルシステムを考えるだけでもすぐに無理が見える． 一つのファイルを「仕事」配下に置くのか，「個人研究」配下に置くのか，「2026」配下に置くのか，「あるプロジェクト」配下に置くのかは，その時点の都合でしかない． 親を一つに決めると，別の文脈から見た自然さが失われる． だから私たちは検索を使い，タグを使い，リンクを使い，ショートカットやシンボリックリンクのような逃げ道を使う．

これは単なるUIの好みではない． 木に押し込めること自体が，情報の形に対してかなり強い，そして多くの場合は間違った仮定を置いている．

この問題意識は古くからある． Vannevar Bushは1945年のAs We May Thinkで，記録を機械的に扱う未来を考え，関連する記録をたどるassociative trailsのような発想を示していた． 今の言葉で言えば，これはかなりハイパーテキスト的で，グラフ的な想像力である．

現代のツールでも同じ方向は見える． ObsidianのGraph viewは，ノートをノード，内部リンクをエッジとして可視化する． Scrapboxは2024年にHelpfeel Cosenseへ名称変更されたが，ページ同士をゆるくリンクさせながら知識を育てる思想は，まさに木ではなくグラフに近い．

これらが示しているのは，「情報は親子関係だけでは扱い切れない」という当たり前の事実だ． 私はこの当たり前さを，議論の場でも徹底したい．

なぜ人は木を好むのか

では，なぜ木の形がこんなに好まれるのか．

理由はかなり単純で，人間のワーキングメモリには限界があるからだ．

George A. Millerの有名な論文The Magical Number Seven, Plus or Minus Twoは，人間の情報処理容量の限界をめぐる古典的な参照点になっている． ただし，この「7」という数字を雑に神聖視してはいけない． Nelson CowanはThe magical number 4 in short-term memoryで，短期記憶の容量をより小さく，おおむね3から5チャンクの問題として整理している．

また，Cognitive Load Theoryでも，複雑な課題では，同時に処理すべき情報要素が多すぎると，容量の限られたワーキングメモリが圧迫される，という整理がなされている．

つまり，人が「もっと簡単に話してほしい」「論点を絞ってほしい」「今はこの話だけにしてほしい」と感じるのは自然だ． それ自体は悪ではない． むしろ他者への配慮として重要な場面も多い．

ただし，ここで混同してはいけないことがある．

人間が一度に扱える情報量が小さいこと と，問題そのものが小さい木で表現できること は，全く別である．

前者は受け手の制約であり，後者は対象の構造についての主張である． この二つを混ぜると，とても危ない． 木が好まれるのは，木が正しいからではない． 人間の処理系が狭いから，そう見せると楽に感じるだけである．

楽であることと，正しいことは違う．

間違ったツリーシェイキング

人と働いていると，「頭が良い人」や「話がわかりやすい人」という評価は，多くの場合，その時必要な情報を必要十分に絞って簡略化できる人に向けられる．

この評価自体はわかる． 実際，聞き手に合わせて話す順番を調整できる人は強い．

しかし，話す順番を調整すること と，議論の構造を木に変換すること は違う． 前者はグラフ上のtraversalを選ぶ行為であり，後者はグラフから辺を消す行為である．

しかし，本当の意味でこれができる人はかなり限られている．

なぜなら「何を落としてよいか」を判断するには，すでにグラフ全体の構造が見えていなければならないからだ． ある辺が今の説明に不要なのか，それともあとで意思決定をひっくり返す重要な依存なのかは，木に畳まれた断面だけを見ていても判断できない．

多くの場合，人は必要十分な簡略化をしているのではなく，単に処理しきれない辺を落としている． これはいわば，間違ったツリーシェイキングである．

使われていないコードを落としているつもりで，実は副作用を持つimportを消している． 議論でも同じことが起きる．

• 「それは今の話ではない」として，実は前提条件だった話を落とす

• 「細かい話」として，実は実装可能性を左右する制約を落とす

• 「別チームの話」として，実は責任境界を決める依存を落とす

• 「感情論」として，実は合意形成の失敗を予告している信号を落とす

そしてあとから，なぜかうまくいかない． なぜか認識がずれている． なぜか仕様がひっくり返る．

それは，議論の途中で必要だった辺を落としたからである．

フォーカスもグラフ上の操作である

もちろん，「常に全ての情報を同時に発話しろ」と言いたいわけではない． 人間はそんなに広いワーキングメモリを持っていないし，発話にも文章にも順番がある．

重要なのは，フォーカスを 削除 として扱わないことだ．

フォーカスとは，グラフに対するviewportである． いま中心に置くノードを決め，深さを決め，その範囲を見る． ただし，viewportの外にあるものが存在しないことにはしない． これは木ではない． グラフをグラフのまま見ているが，視野の中心と半径を変えているだけである．

「今はこの話だけ」と言うなら，それは本来，

いまはこのノードを中心にdepth 1で見ている

という意味であるべきだ．

「それは別論点」と言うなら，それは本来，

この論点とは別ノードだが，辺は残す

という意味であるべきだ．

「あとで話す」と言うなら，それは本来，

この辺は閉じていないので，後で戻る

という意味であるべきだ．

ところが実際の議論では，「フォーカス」という言葉がしばしば「存在しないことにする」という意味で使われる． これはよくない．

グラフの一部だけを見ることはある． しかし，見ている対象は最後までグラフである． グラフを木へ変換してはいけない．

議論は依存グラフである

ここで言っているグラフは，何でもかんでも平等に散らばった無方向グラフではない． むしろ議論には，かなり強い方向がある．

• Aを主張するにはBが必要である

• Cが真ならDは弱くなる

• EはFの具体例である

• GはHの用語定義に依存している

• IはJの実装可能性を制約している

• KはLの合意形成を壊しうる

こういう辺がある． つまり議論は，親子関係というより依存グラフである．

この依存グラフを無理に木へ畳むと，「何を親とするか」という不自然な選択を強いられる． しかもその親は，たいてい会議の主催者，ドキュメントの見出し，チケットの粒度，組織図，その時の力学によって決まる．

しかし情報の依存関係は，そんなものに従ってくれない．

だから，グラフに方向がないと言いたいわけではない． 単方向の親子関係として扱うのは正しくない，と言いたいのである． 議論は依存グラフとして進めるべきだ． 「今どの辺をたどっているか」を意識することはあっても，「この枝以外はない」としてはいけない．

外部化せよ

議論をグラフのまま進めるために，人間の脳内だけで頑張る必要はない． むしろ，脳内だけで処理しようとするから木に畳みたくなる．

ボトルネックが人間のワーキングメモリにあるなら，解くべきは「問題を小さく見せること」ではなく，グラフを外部化すること である．

この意味で，議論を地図として扱う試みはかなり重要だと思っている． たとえばDialog Mappingは，会話の中で出てきた質問，アイデア，賛否の議論を共有のネットワーク状の地図として記録する方法として説明されている． その背景にあるIBISも，議論を単なる箇条書きではなく，問い・案・根拠の関係として扱う発想に近い．

もちろん，毎回専用ツールを使う必要はない． 大事なのは，議論中に見えているグラフを，少なくともどこかに残すことである．

たとえば，

• 論点をノードとして名前付けする

• 辺に種類を付ける

• 「あとで戻る」を単なる口約束にせず，未解決の辺として残す

• 「別論点」を削除ではなくリンクとして扱う

• 議論の最後に，落とした辺がないかを見る

この程度でもかなり違う．

議論が複雑になること自体を恐れすぎなくてよい． 複雑なものが複雑に見えているなら，それはむしろ正しい表示かもしれない． 恐れるべきは，複雑なものを単純に見せた結果，重要な依存を消してしまうことだ．

読む順番と構造を混同するな

私は，少なくとも議論の内部表現としては，木を捨てろと言いたい．

文章を書くとき，発表するとき，誰かにオンボーディングするとき，順番は必要になる． 見出しも必要になる． どこから読み始め，次にどこへ進むかを決める必要もある．

しかし，それは木ではない． それはグラフのtraversal orderである．

本当に良い説明者は，背後にあるグラフを見たまま，その時にたどる経路を選んでいる． だから相手が別の質問をしたとき，別の経路へ移れる． 前提が変わったとき，辿り方を変えられる． 一度は視野の外に置いた辺を，必要に応じてすぐ戻せる．

逆に，悪い説明は，経路を構造だと誤認している． 一度たどらなかった辺を落とし，落としたことも忘れ，最後にはその順番が世界そのものだと思い込む．

これは危険だ．

本当に必要なのは，グラフをグラフのまま保持しながら，その上をどう歩くかを選ぶ能力である． そしてその能力が十分でないなら，歩き方を単純化するより先に，グラフそのものを残すべきだ．

結

議論はグラフのまま進めろ．

もちろん，人間のワーキングメモリには限界がある． だからviewportは必要だし，順番も必要だ．

しかし，それらはグラフ上の操作であって，木への変換ではない．

情報の本質的な構造はグラフである． 木はその部分構造に過ぎない． 議論を木に畳むたびに，辺が落ちる． 辺が落ちれば，依存が落ちる． 依存が落ちれば，判断を誤る．

もし議論をグラフのまま扱えないボトルネックが人間の側にあるなら，私は，問題の方を切り刻むより，人間の側を拡張する努力をしたい．

外部化する． リンクする． 未解決の辺を残す． 局所的に見るとしても，グラフであることをやめない．

議論をグラフのまま進めよ． それは「全部を一度に話せ」という意味ではない． いま見えていない辺を，存在しなかったことにするな という意味である．

注意: このポストは半分冗談である． テストの代わりに祈祷しようとか，CIの代わりに踊ろうとか，そういう話ではない． また，特定の宗教や信仰を茶化す意図もない． むしろ，AI時代の不確実性を考えるために，祈りという古い比喩を借りている．

序

ソフトウェアエンジニアは長いこと，再現性 を愛してきた．

• 同じ入力なら同じ出力

• 同じコードなら同じ挙動

• 同じテストなら同じ結果

• 壊れたら再現させ，原因を特定し，修正する

この感覚は，近代科学の作法とかなり親和的だ． 1662年にRoyal Societyが採用した標語，Nullius in verbaは，「誰かの言葉をそのまま信じるな．事実と実験に訴えよ」という態度を表している． 現代的な定義でも，National Academiesは再現性を「同じ入力データ，同じ手法，同じコード，同じ条件のもとで，一貫した結果を得ること」と整理している．

この気風は，かなり深くソフトウェア工学の身体に入っている． 整形，自動テスト，型検査，CI，性能計測，再現可能なビルド． 私たちは長い時間をかけて，コードを祈りから引き剥がし，再現性の側へ寄せてきた．

しかしいま，AIがそこに割り込んできた．

AIは便利だし，速いし，もう無視できない． だが同時に，AIが返す成果物はかなりの部分で 確率的 だ． 少なくとも言語モデルについては，ある文脈の次に続くトークンを条件付き確率分布から順にサンプリングしていく，という説明が素直である．実際，ある研究論文でも，自己回帰型の言語モデルは各トークンを条件付き確率分布から取り出すと記述されているし，OpenAIのヘルプでも，トークンの出やすさを変えるlogit_biasが説明されている．

つまり我々は，決定性を愛する職能でありながら，日々の作業の一部を 確率的な超越者 に委ね始めている．

私は，この瞬間に少しだけ，人類は祈りへ回帰するのではないかと思っている．

人類はずっと，わからないものの前で祈ってきた

もちろん「祈り」と言っても，それは単に神にお願いするというだけではない． もっと広い，理解や制御の及ばないものに対して，人間が姿勢を整えるための行為 として捉えたい．

Britannicaの祈りの項目は，祈りを聖なるものとの交わりとして説明し，しかもそれが「あらゆる時代の宗教に見られる」としている． 同じ項目では，祈りは個人的にも共同体的にも行われ，しばしば犠牲儀礼や文学と結びついてきたと整理されている． 実際，詩篇は祈りの書として読まれてきたし，クルアーンにも祈りの書として捉えられる側面がある，という言及がある．

人類は，ただ黙って手を合わせてきただけではない．

• 祈りのために歌ってきた

• 祈りのために踊ってきた

• 祈りのために建物を作ってきた

• 祈りのために本を書いてきた

• 祈りのために行列と音楽を整えてきた

この「祈りが芸術や建築や共同体の形式を生む」という感覚は，歴史を少し見るだけでもすぐ出てくる． たとえばGöbekli Tepeは，UNESCOの説明でも前土器新石器時代，紀元前9600年から8200年ごろの記念碑的な建築群として整理されており，儀礼や共同の集まりと結びついた場所として説明されている． 人類は，都市や学会や課題管理システムよりずっと前に，まず儀礼のための巨大構造物を作っていたらしい．

もう少し身近な例で言えば，Britannicaの神道の項目でも，神社の儀礼が音楽，舞，行列，奉納の絵などと結びついてきたことが説明されている． 雅楽, 神楽, 獅子舞 のように，音楽や舞が清めや祈りと結びついていることは，日本に生きているとわりと身体感覚としてもわかる．

つまり人類は，理解できないものの前で，言葉だけでなく形式を作ってきた のだ． 祈りには振る舞いがあり，音があり，空間があり，建築があり，書物がある．

科学は，祈りと知をきれいに分けた

近代科学が偉大だったのは，この混ざり合っていたものをかなりきれいに分けたことだと思う．

• 願望と検証を分けた

• 共同体の儀礼と事実の確定を分けた

• 美しい物語と，再現可能な手続きを分けた

もちろん現実の歴史はそんなに単純ではないし，宗教と科学の関係は対立だけでは語れない． しかし少なくとも方法論の水準では，近代以後の知は「それを誰が言ったか」より「それが再現できるか」を重視するようになった．

この流れをソフトウェアはかなり忠実に引き継いでいる． ソフトウェアは，近代科学のかなり優等生な分野だった．

• バグは再現して直す

• テストは何度流しても同じであってほしい

• ビルドは同じ変更履歴なら同じ成果物を返してほしい

• ルールは自然言語ではなく静的解析に落としたい

祈りは個人の心の中に残っていても，少なくとも本番反映の意思決定そのものには入れない，というのが近代的な矜持だった．

でもAIは，決定性の庭に確率を持ち込んだ

ところがAIは，この庭にもう一度ノイズを持ち込んだ．

ここで重要なのは，AIが「嘘つきだ」というような単純な話ではない． もっと構造的な話だ．

言語モデルは，本質的に確率分布を扱っている． ある論文の表現を借りれば，自己回帰型の言語モデルは各トークンを条件付き確率分布からサンプリングする． またOpenAIのヘルプでも，特定トークンの出やすさを変えるlogit_biasが説明されている．

要するに，少なくとも実務者の感覚としては，

• 同じ依頼でも少し違うものが返る

• 指示文の書き方で急に機嫌が変わる

• 文脈の入り方で答えが変わる

• 今日は賢いのに明日は妙に鈍い

という経験が積み上がる．

ここで我々は奇妙な状況に入る．

一方で，AIを使わないわけにはいかない． 速度差がありすぎるからだ．

他方で，AIが返すものは決定的な関数のようには扱えない． もちろん評価器，テスト，静的解析，型システム，レビューで囲い込むことはできる． だが，最初の初稿がどんな顔で出てくるかには，依然として確率の気配が残る．

この瞬間，ソフトウェア開発は少しだけ，「再現性だけでは回らないが，それでも良い結果を期待しなければならない営み」へ足を踏み入れる．

祈りは復活する．ただし，CIを置き換える意味ではない

ここから半分冗談の本題である．

私は，AIとともに働くソフトウェアエンジニアは，少しずつ新しい儀礼を発明すると思っている．

たとえば，

• 新しいリポジトリを切る前に，いつも同じ音楽を流す

• 難しい実装の前に，なぜか同じ指示文の型を唱える

• AGENTS.mdをほとんど経典のように扱う

• 「今日はこのモデルが機嫌がいい」と言い出す

• デプロイ前に意味もなく机を拭く

• 推論コストを供物のように見なし始める

もちろん，これは技術的には無意味なものも多いだろう． しかし完全に無意味とも言い切れない． なぜなら儀礼の役割は，外界を直接変えることだけではなく，不確実性に向かう共同体の姿勢を整えること にもあるからだ．

宗教史の文脈で祈りが個人と共同体の両方の行為だったように，AI時代の儀礼もまた，チームの心拍を揃える機能を持ちうる． 誰も「そのおまじないで指標が改善する」とは本気では言わない． しかし「それをやるとチームが落ち着く」は案外ある．

私はここに，少しだけ祈りの回帰を見る．

近代ソフトウェア工学は，「理解し，分解し，再現し，制御する」ことで強くなった． だがAIはそこに，「十分には理解できないが，うまく付き合わないといけない」という対象を持ち込んだ．

このとき必要なのは，科学を捨てることではない． むしろ逆で，

• 決定的に固定できるところは徹底して固定する

• テストと型検査は絶対に残す

• 評価を厚くする

• 決定的に検証できる境界を広げる

その上でなお残る，確率的な揺らぎに対して，人間の側が少し儀礼的になるのだと思う．

つまり未来のエンジニアは，

1.まずテストを書く2.そのあとシードと温度を調整する3.それでも不安なので静かな音楽を流す4.最後に手を合わせる

という，非常に現代的で，非常に古代的な手順を踏むかもしれない．

最強のプログラマの岩

そして私は，もっとどうでもいい未来も想像している．

新しいプロジェクトを始めるとき，私たちはまず，最強のプログラマが宿っているとされる巨大な岩 を祀る施設を訪れるのだ． そこで靴を脱ぎ，静かにノートPCを開き，祝詞のように指示文を読み上げる．

「構文エラーを遠ざけたまえ」

「謎の1ずれバグを祓いたまえ」

「useEffectの依存配列を正しく導きたまえ」

「このプルリクエストにレビュアの慈悲がありますように」

誰かが小さな鈴を鳴らす． 誰かが薄いシンセの持続音を流す． 誰かがpnpm testを叩く．

そして全員で岩に向かって一礼し，こう唱える．

今日のモデルが，昨日のモデルより少しだけ賢くありますように．

もちろん，岩に本当に最強のプログラマが宿っているかはわからない． だが安心してほしい． それは今のところ，誰もAIの内部で何が起きているかを本当に全部はわかっていないのと，だいたい同じである．

結

人類は，理解できないものに対して，ずっと祈り，歌い，踊り，建て，書いてきた． 科学はその中から，再現可能な部分を取り出し，方法として磨き上げた． ソフトウェア工学は，そのかなり優秀な継承者だった．

しかしAIは，そのソフトウェアの中心に，再び確率を持ち込んだ． だから私は，エンジニアが少しだけ祈りへ回帰する未来を想像している．

それはテストを捨てるという意味ではない． むしろテストを抱きしめたまま，それでもなお残る不確実性の前で，少しだけ姿勢を正すという意味だ．

科学の後に祈りへ戻るのではない． 科学を持ったまま，祈りの身振りを再発見する のだ．

そのときソフトウェア開発は，思ったより古い営みに似てくるのかもしれない． 良い結果を願い，形式を整え，仲間と息を合わせ，それでも最後は少しだけ天を仰ぐ．

少なくとも，AIにコードを書かせている今の我々は，もうその入口に片足を突っ込んでいる．

Coding Agentが実用段階に入ってから，設計の問いは少し変わった． 以前は「このコードをどう書くか」が中心だったが，いまは「このコードのどこまでをAgentに委ねるか」が同じくらい重要になっている．

私はこの「Coding Agentにどれだけ身を任せるか」という度合いを，Agentyと呼ぶことにしたい．

• 0は全くAgentに委ねない状態

• 100は完全にAgentに委ねる状態

これはモデルの性能指標ではない． リポジトリとアーキテクチャの設計指標 である．

重要なのは，Agentyは高ければ高いほど良い値ではない，ということだ． 本当にやりたいのはrepo全体を100にすることではない． どこを0に寄せ，どこに高いAgentyを置くべきかを設計すること である．

この観点で見ると，たとえばfuckin-strict-nuxt-dmmfが示している *.def.ts / *.impl.ts / *.test.tsの分離は，単なるファイル命名規則ではない． あれは「どの層のAgentyを低く保ち，どの層のAgentyを上げてよいか」をrepoに埋め込む試みとして読める．

ただし本質はNuxtでもVueでもない． この考え方は，もっとframework-independentに捉えられる．

Agentyは局所的に設計されるべき

Agentyは，repo全体に一律でかけるノブではない． レイヤごとに異なる値を持つべきだ．

私はだいたい次の3層で考えている．

この数値に厳密な意味はない． 大事なのは，共通言語として「defは下げる」「implは上げてよい」と話せることだ．

Agentyを0に近づけるべき場所

最初に強く言いたいのは，一般的なコーディングルールやプラクティスは，できる限り静的解析で決定的に行われるべき だということだ．

ここは高いAgentyを求める場所ではない． むしろ0に近づけるべき場所である．

たとえば，

• formatterによる整形

• lint ruleによる構文・規約チェック

• 型検査による不整合の検出

• import境界や依存方向の制約

• exhaustiveness checkや到達不能状態の検出

こうしたものは，本来repo自身が 機械的に拒否 できるべきだ．

ここを自然言語の運用に逃がしてはいけない． AGENTS.mdやSkillsに「こういう書き方をしてね」と書くこと自体は補助として有効だが，それをrepoの法にしてはいけない．

なぜなら，自然言語ベースの運用は本質的に非決定的だからだ．

• モデルが変わる

• プロンプトが少し変わる

• 文脈窓の入り方で解釈が変わる

• Skillの適用順や読み取り方で結果が揺れる

つまり，そこにrepoのinvariantを預けると，ルールそのものが確率的になる．

それはAgentyを上げているのではない． 単に，守るべき境界を曖昧にしているだけだ．

私の感覚では，Skillsはrepoの真理を記述する場所ではなく，repoに埋め込まれた真理にAgentを従わせるための補助輪 である． 真理そのものは，なるべく静的な層に落ちていなければならない．

静的解析はドメインモデリングでもある

静的解析というとESLintやformatterの話だけを思い浮かべがちだが，実際にはもっと広い． ドメインモデリングもtype levelに現れる．

つまり，

1.まずstaticなレイヤに定義を書く2.その次に宣言的テストで補足する3.実装は最後に置く

という順番が重要になる．

ここでいう「定義」は，単なる型エイリアスではない．

• 状態空間

• イベント

• 遷移

• 入出力契約

• エラーの表現

• 依存境界

こうしたものを，なるべく実装より手前に書いておく．

私はこの順番をかなり重視している． 先に実装を書き始めると，人間もAgentも，たいてい「いま書きやすいコード」の方向へ流される． しかし先に定義を置いておけば，実装はそのcontractを満たす作業に下がる．

この「実装を最後に追いやる」ことこそが，高いAgentyを安全に使う前提になる．

SDDに似て見えて，少し違う

ここまでの話は，一見するとSDD, つまり仕様駆動開発にかなり近く見えるかもしれない． 実際，「仕様を先に置く」「実装の前に合意を作る」という方向性そのものは近い．

ただ，私はそのまま同一視はしていない． 理由は単純で，運用面で必要な解像度が違う からだ．

現実のrepo運用では，曖昧な自然言語仕様をそのままmasterにするのは無理がある． 人間同士の設計議論やRFCには自然言語が必要だし，それ自体は大切だ． しかし，自然言語はどうしても，

• 解釈の幅が広い

• 境界条件が抜けやすい

• 参照時に読み手の経験へ依存しやすい

• Agentに読ませたときに確率的に揺れやすい

という性質を持つ．

だから私は，「自然言語仕様を起点にする」のではなく，自然言語の議論を，最終的にdefやspecへ落とし切る ことを重視したい． 言い換えると，

• RFCや議論は自然言語でよい

• しかしrepoのmasterは，できる限り形式的であるべき

ということだ．

仕様を自然言語のまま神棚に置くのではなく，型，状態遷移，宣言的テスト，静的制約へ変換する． そこまでやって初めて，Agentと人間の両方が同じcontractを参照できるようになる．

私はここが重要だと思っている． SDDが悪いというより，Coding Agent時代には，自然言語だけをマスターにした仕様駆動では足りない． 確率的で曖昧な自然言語表現をrepoの最終的な真理として運用するのは，現実世界では厳しい． だからこそ，Agentyの議論では「仕様を先に書く」だけでなく，「仕様をどこまで形式に落とすか」まで含めて考える必要がある．

def / spec / implはframeworkに依存しない

fuckin-strict-nuxt-dmmfの面白いところは，*.def.tsと *.impl.tsを分けている点そのものより，分ける基準がframeworkではなく責務になっている 点にある．

重要なのは「Vueだからこう分ける」ではない． むしろ，ReactでもSvelteでもserver-side applicationでも，考え方は同じでよい．

たとえば，抽象化すると次のような分割になる．

feature/
  order.def.ts
  order.spec.ts
  order.impl.ts

あるいは言語に依存しない記法なら，

feature/
  order.def.*
  order.spec.*
  order.impl.*

と考えてもよい．

そしてそれぞれの意味は，おおむね次のようになる．

• def: 低Agenty．変更には設計意図が伴う．Agentにむやみに触らせない

• spec: 低から中Agenty．受け入れ条件や宣言的シナリオを補足する

• impl: 高Agenty．制約の中で最も自由度が高く，Agentの探索空間になる

この分離があると，指示も運用も明確になる．

• 「defは明示的な設計変更があるときだけ触る」

• 「specを満たすようにimplを直す」

• 「レビューではdefのdiffを仕様変更として読む」

• 「implのdiffは仕様充足として読む」

ここで初めて，Agentyがrepoのトポロジに変換される．

Agentyは教育のフレームでもある

ここで強調しておきたいのは，この話は単なるrepo設計やAgent運用の話ではない，ということだ． 人材教育のフレーム としても読める．

正直に言えば，defを必要十分に書き起こすのは難しい． それは簡単な仕事ではない．

• 何が状態なのか

• 何がイベントなのか

• どこまでを同一視し，どこで場合分けするのか

• 何を禁止状態として表現すべきか

• どの境界をstaticに固定すべきか

こうしたことを，実装に逃げずに形式的に書くのは，かなり訓練が要る．

だが，私はそれでよいと思っている． むしろ そうあるべき だと思っている．

なぜなら，実装より先にドメイン仕様を形式的に表現する力こそが，これからの時代により重要になるからだ． Coding Agentが強くなるほど，「速く書く」ことの希少性は下がる． その代わりに，

• 何を定義すべきか

• どこまでを機械に委ねてよいか

• どのcontractなら安全に自動化できるか

• 生成された実装が仕様を満たしているか

を見極める力の価値が上がる．

この意味で，defを書く練習は，単なる前処理ではない． ドメインを形式化する筋力そのものを鍛える．

これは別にまったく新しい話ではない． 「実装をする前にRFCを書きましょう」「実装する前に設計をディスカッションしましょう」という従来の動きにかなり近い． ただ，Coding Agentの登場によって，この順序の意味がさらに強くなっただけだ．

以前は，設計を雑に始めても，最終的には人間が実装の泥臭さの中で辻褄を合わせることが多かった． しかしAgentが大量の実装を高速に吐けるようになると，手前の定義の雑さが後段で増幅される． だからこそ，先にdefを議論し，specを固めることの教育的価値が上がる．

私は，Coding Agentの登場によって「後続人をどう育成するのか」という議論はたちまち話題になっている，少なくともそうなりつつあると思っている． もし実装の大部分をAgentが書くなら，若い開発者は何を学べばよいのか，という問いである．

このフレームは，その解決策の一つになりうる．

• まずdefを書く

• specで受け入れ条件を明確にする

• implはAgentと一緒に作る

• 生成物をcontractとdiffでレビューする

こうすると，育成の焦点は単なるタイピング速度や暗記量ではなく，

• ドメインの切り分け

• 境界の設計

• 状態遷移の記述

• 仕様の言語化

• 生成物の検証

へ移る．

私はこれは健全だと思う． 実装力が不要になるわけではない． むしろ，良いdefやspecを書くには実装感覚も必要だ． ただ，育成の順序が変わる． まず実装から入るのではなく，先に仕様を記述し，その後に実装を読む・直す・評価する 方向へ重心が移る．

そしてこのやり方は，個人の学習だけでなく，組織運用としてもサステナブルだ． 知識が「ベテランの頭の中」や「うまくいったpromptの言い回し」ではなく，defやspecというstaticな資産としてrepoに蓄積されるからだ． これは教育にも，保守にも，引き継ぎにも効く．

高いAgentyを本当に求めるべき場所

では，どこに高いAgentyを置くべきなのか．

私は，複数の実装がありえて，しかも正しさを後段で機械的に検証できる場所 だと思っている．

具体的には，

• mapping

• adapter

• UI wiring

• API clientの組み立て

• viewとstateの接着

• boilerplateが多いdomain implementation

のような場所だ．

これらは「やり方」は複数あるが，「満たすべき条件」は比較的明確に書ける． だから，先にcontractとspecを固定しておけば，実装側のAgentyはかなり高くできる．

逆に，次のような場所で高いAgentyを求めると危ない．

• state machineそのもの

• business ruleの例外条件

• 境界値や禁止状態の定義

• architectural boundary

• repo全体のcoding rule

ここは「あとで直せばよい」では済まない． ここが揺れると，それ以降のすべての自動化が不安定になる．

WebフロントエンドではVMをdefに書き起こす

Webフロントエンドでは，この話は特に重要になる．

私はMVVM的な分離をいま一度強く見直すべきだと思っている． ただし関心があるのは「ViewModelというクラスを作ること」ではない． VMレイヤの状態遷移を，実装の前に定義として書き起こすこと に関心がある．

たとえば，

export type CheckoutState =
  | { kind: "Idle"; cart: Cart }
  | { kind: "Submitting"; cart: Cart }
  | { kind: "Succeeded"; orderId: OrderId }
  | { kind: "Failed"; cart: Cart; reason: CheckoutError };

export type CheckoutEvent =
  | { type: "Submit" }
  | { type: "Resolve"; orderId: OrderId }
  | { type: "Reject"; reason: CheckoutError };

export type Transition = (state: CheckoutState, event: CheckoutEvent) => CheckoutState;

こういうものはcheckout.vm.def.tsのような場所にあるべきだ．

ここで固定したいのはUIの見た目ではない． 画面がどういう状態を持ち，どういうイベントでどこへ遷移するか である．

この層は低Agentyにしておくべきだ． なぜなら，これはそのままプロダクトの振る舞いだからだ．

一方で，

• 状態からpropsへの写像

• componentの分割

• event handlerのwiring

• 副作用の実装

といった部分は，契約が定義されていればより高いAgentyを許容できる．

ただしここで注意したいのは，MVVMのVに相当する部分は，まだAIによる制御がそんなに簡単ではない ということだ． layout, typography, spacing, motion, visual hierarchyのような領域は，単にstate contractがあれば自動で良くなるわけではない． ここはstate machineの正しさとは別種の難しさを持っている．

むしろVは，状態管理の延長として扱うよりも，デザインツールと統合されるべき別のソース・オブ・トゥルース として考えた方がよい． たとえば，

• 画面状態と遷移はVM defに書く

• 受け入れ条件はVM specに書く

• 見た目やレイアウトはdesign tool側で管理する

• 実装コードはその両者を接続する

という分離である．

この意味では，WebフロントエンドのAgentyは単純に一本の軸ではない． 少なくとも，

• VM: 低Agentyな定義と，高Agentyな実装に分離しやすい

• V: まだAI単体では制御しづらく，design system / design toolとの統合が重要

という違いがある．

だから私は，Webフロントエンドでは

• VM defは低Agenty

• VM specは中Agenty

• VM implは高Agenty

• Viewはstate管理とは別軸で，design toolと接続して扱う

と整理するのがよいと思っている．

これをやっておくと，プロダクトの振る舞いはrepo側のVMで握りつつ，Vはより適切なdesign workflowに委ねられる． つまり，画面の意味論と画面の造形を，無理に同じ場所へ押し込めなくてよくなる．

これは運用とレビューのしやすさにも直結する

この設計は，単にAI-friendlyというだけではない． 実際にソースコードを運用するうえで効いてくる．

まず，仕様の分離 が効く． defとspecが手前にあると，「何を変えたかったのか」と「どう実現したか」がdiff上で分離される．

次に，Agentによる改変のしやすさ が上がる． 編集可能領域をimplに寄せられるので，プロンプトは単純になる． 「この契約を守って実装して」と言える．

さらに，コードレビューのしやすさ が上がる． レビューアは全diffを同じ粒度で読まなくてよくなる．

• defが変わっているなら仕様レビュー

• specが変わっているなら期待値レビュー

• implだけなら実装レビュー

というふうに，読むモードを切り替えられる．

高いAgentyを扱う時代ほど，このdiffの意味論が重要になる． なぜなら，Agentは大量のコードを書けるが，人間のレビュー帯域はほとんど増えないからだ．

だからこそ，人間が本当に読むべき差分は，できるだけ静的で，宣言的で，小さく保たれていなければならない． そして，その静的で宣言的な差分こそが，教育可能で，引き継ぎ可能で，組織的にもサステナブルな資産になる．

結

Agentyという言葉で言いたいのは，単に「AIにどこまで任せるか」ではない． どこを確率的にしてよく，どこを決定的に固定すべきか という設計の話である．

一般的なルール，ドメインの境界，状態遷移，契約． これらはなるべくstaticに，type levelに，そして機械的に検査できる形で置くべきだ． その上で，宣言的テストで仕様を補足する． 実装は最後に置く．

高いAgentyを求めるべき場所は，repoの法がすでに定まっていて，その範囲で自由に探索してよい場所だけである．

repo全体をAgentに明け渡すのではない． Agentが暴れてよいsandboxを，architecture側で先に作る．

私はこれが，これからのCoding Agent時代の設計だと思っている．

ここ2, 3年でSignalsという言葉は急激に広がった. しかし，この言葉はしばしば二つの異なるものを同時に指している.

ひとつは，Vueのref()やSolidのcreateSignal()のような，ランタイムで値と依存関係を保持するリアクティブ・プリミティブ という意味でのSignalsだ. もうひとつは，SvelteやSolid，そしてVue Vaporのように，どのDOMがどの依存にぶら下がるかというtrackerまで含めて更新系を語る文脈 でのSignalsである.

私はこの二つを意図的に分けて考えた方がよいと思っている. 前者は「値のリアクティビティ」であり，後者は「レンダラのリアクティビティ」だ.

そしてこの区別を曖昧にすると，Signals = VDOMの終わり のような雑な結論に流れやすい. しかし実際には，TC39 Signals proposal自身がFAQの中で，SignalsはVDOMにも，native DOMにも，両者の組み合わせにも載せられると明言している. つまり，Signalsは 描画方式そのものではない.

この話をするためには少し歴史に戻る必要がある.

Knockout.jsとObservableの時代

Signalsの流行を見るたびに，私はKnockout.jsを思い出す. Knockoutはかなり早い時期からobservableとcomputedを持ち，依存関係を自動追跡していた. しかもKnockoutのドキュメントは，宣言的binding自体がcomputed observablesとして実装されている と説明している.

これは重要だ. 今日我々が「Signals的」と呼んでいるもののかなりの部分は，実はかなり昔からある. 値をobservableに包み，依存を追跡し，変更時にUIの一部を更新するという構図は，新しいアイデアではない.

ただし，その後しばらく標準化の文脈で前に出てきたのはSignalではなくObservableだった. TC39のObservable proposalは，DOM eventやtimerやsocketのようなpush-basedな複数値のstreamを標準化しようとしていた. 現在はWICG Observable proposal側で継続しており，そこでもhistoryとして2015年のTC39提案，2017年のWHATWG DOM issue，2019年の再活性化が整理されている.

ここで一度整理しておきたい.

• Observableが主に扱うのは，時間方向に流れるevent streamだ.

• Signalsが主に扱うのは，「いまの値」とその依存グラフだ.

両者は近いが同じではない. Observableはtemporalであり，Signalはcurrent-value orientedだ. だから，TC39におけるObservableの歴史と，現在のSignals proposalは連続してはいるが，そのまま同一視はできない.

しかもSignals proposalは，framework authorsの協調の上で，developer-facing surface APIよりも，underlying signal graphのcore semanticsを揃える ことに重心を置いている. ここでもう既に，「Signalsとはend-user APIではなく，frameworkの下に潜る基盤である」という意識が見えている.

SignalsとSignals．

ここからが本題だ.

私が言いたいのは，Signalsという語には少なくとも二つのスコープがある，ということだ.

1.ランタイム・プリミティブとしてのSignals

これは最も狭い意味でのSignalsだ.

Vueのreactivity docsは，Vue 3ではreactive() がProxyを使い，ref() がgetter / setterを使ってtrack() / trigger() を実現していると説明している. また同じページでVueは，自身のreactivity systemがprimarily runtime-basedであると明言している.

SolidのcreateSignal()も同様に，getterがreactive context内で依存を追跡し，setterがdependent computationsを通知するprimitiveとして説明されている.

この層でのSignalsは，かなり素朴に次のようなものだ:

signal cell -> track reads -> trigger writes -> rerun effects

ここで主役なのは 値 である. どの値が読まれたか，どのeffectがそれに依存しているか，という依存グラフがランタイムに構築される.

Vueのrefも，SolidのcreateSignalも，この文脈でまず理解できる.

2. DOM trackerまで含めたSignals

しかし，もうひとつ別の文脈がある.

Svelteは，compilerによってbrowserでの仕事を最小化するframeworkであると自身を説明している. TC39 Signals proposalのFAQも，Svelte 5がrunesを内部のsignals libraryにtransformする例として挙げている. SolidのREADMEは，templateをreal DOM nodesにcompileし，whole buttonをrerenderするのではなく，必要な場所だけをupdateするコードを生成することを示している. またSolid Docsのfine-grained reactivityは，Reactがcomponent全体を再実行しがちなのに対して，Solidはtarget attributeを更新すると説明している.

このときSignalsは，もはや単なる値containerではない. どのsignalがどのDOM text node / attribute / bindingを更新するか，というDOM側のtrackerまで含めた更新文脈になる.

signal graph -> compiler-known DOM sinks -> exact DOM mutation

ここではrendererの仕事の一部がdependency graphに吸い込まれている. 再実行の単位はcomponent全体ではなく，もっと細いDOM sinkに近づく.

この意味でのSignalsは，値のprimitiveというより 描画アーキテクチャの名前 である. ここでは同じSignalsという語を重ねている.

Retained UI

ではVDOMやReact Fiberはどこに位置づくのか.

私はこれをRetained UIと呼びたい. つまり，一度desired UIをメモリ内のnode / frame / treeとして持ち，それをもとに更新を管理するランタイムである.

ReactのRender and Commitは，renderでcomponentを呼び，commitでDOMに反映すると説明している. 再renderの際にはchanged propsを計算し，commitではminimal necessary operationsを適用する.

さらにReact Fiber architectureでは，

• render時にappを記述するtreeがmemoryに生成されること

• そのtreeをdiffしてDOM operationsを計算すること

• Fiberはunit of workであり，virtual stack frameのようなものだということ

が説明されている.

これは非常に重要だ. Reactにおいて主役なのは，signal dependency graphではなくin-memory tree / fiber graphの方だ. state updateはそのtreeを再計算するための引き金であり，最終的なDOM updateの主体はreconciler側にある.

つまりReactでは，

state update -> rerun components -> new in-memory tree -> reconcile -> commit DOM

である.

ここでReactivityは存在しないわけではない. しかしそれはVueやSolidのようにfirst-classなdependency graphとして前景化しているわけではない. Reactの場合，reactivityは主に どのcomponent subtreeを再評価するか というinvalidationの問題として現れ，実際の更新はRetained UIが引き受ける.

Vueはその中間にいる

面白いのは，Vueが昔からこの二層を両方持っていることだ.

VueのRendering Mechanismは，

1. templateをrender functionにcompileし

2. mountをreactive effectとして実行し

3. dependency change時にeffectをrerunして新しいVDOM treeを作り

4. patch / reconciliationでDOMを更新する

と説明している.

さらにVueは，同じページでpatch flagsやtree flatteningを用いたcompiler-informed virtual DOMを説明している. つまりVueは昔から，

• 下層にはref / reactive / effectというリアクティビティ

• 上層にはcompiler hints付きVDOM runtime

を重ねていた.

これはReactとSolidの中間というより，SignalsとRetained UIを両方持つ構造 と言った方がよい.

だからVueを見ているとわかる. SignalsはVDOMの否定ではない. SignalsはVDOMの下にも置けるし，上にも別のrendererを置ける. 実際TC39 Signals proposalのFAQも，SignalsはVDOMにもnative DOMにもcombinationにも載ると言っている.

Vue Vaporの未来

この観点からVue Vaporを見ると，話はかなり明確になる.

2025年12月23日のVue 3.6.0-beta.1 release noteは，Vapor Modeを

• Vue SFCのnew compilation mode

• baseline bundle sizeとperformance改善を目指すもの

• 100% opt-in

• feature-completeだがstill unstable

と説明している.

しかも同じrelease noteには，かなり重要なことが書いてある.

1. Vapor-only modeではSuspenseを直接は持たないが，VDOM Suspenseの中でVapor componentをrenderできる

2. createApp側にvaporInteropPluginを入れると，VDOM appの中でVapor componentを使える 3.逆にVapor app側でもinterop pluginを入れればVDOM componentを使える 4.ただしmixed nestingにはrough edgesがあり，distinct regionsを推奨する

これはかなり示唆的だ. 少なくとも近未来のVue Vaporは，「VDOMを完全に捨てて全面移行する新しいVue」ではない. むしろ 高性能subsetとしてのVaporを，既存Vue runtimeとinteropさせながら段階的に広げる構想に見える.

Vapor Roadmapでも，

• SSR / Hydration

• Template Ref Interop

• Suspense support

• Vue Router

• Pinia

• Nuxt.js

• DevTools Integration

• Vue Test Utils

といった項目が並んでいる.

ここから読み取れるのは単純だ. Vaporの本質的な課題は，単に「速いDOM更新ができるか」ではない. Vue ecosystem全体とどう噛み合うか が課題なのだ.

つまりVue Vaporの未来は，私はこう見る.

• VDOMがlegacy residueとして残るのではない

• Vaporがperf-sensitive pathを担う高性能subsetになる

• VDOM runtimeはinterop / ecosystem / library compatibilityの母体として当面は重要なままである

• そして両者の境界が，より明示的に設計されていく

これはむしろVueらしい. Vueは昔からprogressive / incrementally adoptableであることを重視してきた. Vaporが将来成功するとしても，その成功の仕方は「全部置き換える」より，「適切な境界を持って共存する」に近いはずだ.

なぜこれはReactとの比較で重要なのか

ReactではReactivityよりもRetained UIの方がコアであり，Fiberはそのscheduling / reconciliation / prioritizationを担う. 一方でVapor / Svelte / Solid Compilerの方向は，依存追跡とDOM sink trackingを近づけることで，保持されたtreeへの依存を薄くしようとする.

ここで比較すべきなのは「どちらが上か」ではない. 比較すべきなのは，どのレイヤが更新責任を持つか だ.

• React / classic VDOM: in-memory node runtimeが更新責任を持つ

• runtime signals: signal graphがinvalidationを持つが，rendererは別にいる

• compiler + DOM tracker signals: signal graphがrendererの責務の一部まで持ち始める

この三つは別物だ.

そしてVueは今，その全部を一つの体系の中に保持したまま前進しようとしている. refは残り，VDOM modeも残り，その上でVaporが増える. 私はこれをかなり健全だと思っている.

Signalsは魔法の銀の弾丸ではない. またVDOMは単なる過去の遺物でもない. Retained UIは，component composition，dynamic rendering，ecosystem interop，debuggability，toolingとの整合において依然として強い. 一方でcompiler-guidedなSignals.は，hot pathの細粒度更新とbaseline sizeの面で強い.

問題は常に「どちらを捨てるか」ではなく，「どこに境界を引くか」なのだ.

これは私の個人的な考察であり，Vue Team / React Team / TC39の公式見解ではありません.

注意: 私は数学の専門家ではない. この文章は，圏論・Algebraic Effects・Applicativeな構造の語彙を使ってReactを理解するための試論であり，厳密な定理としてではなく，読み方の提案として読んでほしい. 数学的に誤っている点があればぜひ教えてほしい.

序

「UI = f(State)」— Reactに関する言説の中で最も広く流通している等式の一つである. この等式は一見シンプルで，Reactの核心を捉えているように見える. 状態が決まればUIが決まる，と.

しかし，この等式を数学的な言葉で丁寧に読むと，いくつか確認すべき点が出てくる.

• この f は何なのか？ 数学的な意味での「関数」なのか？

• もし関数なら，それはどの圏の射なのか？

• Reactが言う「純粋」「冪等」は，数学におけるそれと同じか？

このエッセイでは，圏論・Algebraic Effects・Applicativeな構造の語彙を用いて，React Componentをより精密に読むことを試みる.

「純粋」の数学的意味

Reactのドキュメントや議論でよく使われる「純粋(pure)」という言葉の数学的意味を明確にしよう.

数学における 純粋関数 (pure function)とは，参照透過性(referential transparency)を持つ写像のことだ. 圏論の言葉で言えば，集合の圏Setにおける射(morphism)に対応する:

$$f: A \to B$$

この射 f は以下を満たす:

• 同じ入力に対して常に同じ出力を返す(deterministic)

• 外部の状態を読み書きしない(no side effects)

• 値の計算以外のことをしない(no observable effects)

ここでReactのFunction Componentを考えてみよう:

function Greeting({ name }) {
  const [count, setCount] = useState(0);
  const theme = useContext(ThemeContext);

  useEffect(() => {
    document.title = `Hello, ${name}`;
  }, [name]);

  return (
    <h1 style={{ color: theme.primary }}>
      Hello, {name} ({count})
    </h1>
  );
}

このComponentは:

• useStateを通じて内部状態を読み，更新手段を受け取っている

• useContextを通じてコンポーネントツリーの外部状態を読んでいる

• useEffectを通じて副作用をスケジュールしている

これはSetの射ではない. 引数(props)以外のものを読んでいるし，純粋な値の計算以外のことをしている.

React Componentは数学的な意味で「純粋関数」ではない.

ではなぜReactはComponentを「純粋」と呼ぶのか？ それはReactが 異なる意味で「純粋」という言葉を使っているからだ. Reactにおける「純粋」とは:

レンダリング中に観測可能な副作用がないこと — より正確には，Reactのエフェクトシステムの中で正しく振る舞うこと

これは数学的純粋性よりもはるかに弱い条件であり，用語の混同は本質的な誤解を招く.

「冪等」の本来の意味

Reactのドキュメントには次のような記述がある（Components and Hooks must be pure）:

"Components must be idempotent – React components are assumed to always return the same output with respect to their inputs – props, state, and context."

ここで使われている「冪等(idempotent)」は，数学的に何を意味するのか.

数学における冪等

代数学における冪等元の定義:

定義 (冪等元). モノイド (M, ·, e) において，元 a ∈ M が冪等 (idempotent)であるとは，a · a = a を満たすことをいう.

これを関数に拡張すると:

定義 (冪等な自己準同型). 圏 𝒞 において，射 e: A → A が冪等であるとは，e ∘ e = e を満たすことをいう.

この2つの定義は，冪等元については Eric W. Weisstein, "Idempotent," MathWorld を，冪等な自己準同型については Emily Riehl, Category Theory in Context, Example 3.2.14 を参照している.

具体例:

• 絶対値関数は冪等: ||x|| = |x|

• 射影行列 P は冪等: P^2 = P

• Math.floorは冪等: Math.floor(Math.floor(x)) === Math.floor(x)

ここで重要なのは，冪等は自己準同型(endomorphism) f: A -> A の性質であるということだ. f の出力にもう一度 f を適用しても結果が変わらない — これが冪等の本来の意味である.

Reactの「冪等」は数学的には冪等ではない

ReactがComponentについて「冪等」と言っているのは，「同じ入力に対して同じ出力を返す」という意味だ. これは数学的には冪等ではなく，決定性(determinism)あるいは 整合性(well-definedness)と呼ぶべきものだ.

なぜなら:

1. Componentの型は Props -> VDOM であり，Props != VDOM. つまりそもそも自己準同型ですらない.

2. f ∘ f = f を検証するためには f の出力を f の入力に渡す必要がある. だがComponentの出力(VDOM)をComponentの入力(Props)に渡すことに意味はない.

3. Reactが言っているのは「f(x) = f(x)（同じ入力なら同じ出力）」であって，「f(f(x)) = f(x)」ではない.

f(x) = f(x) はあらゆる関数が定義上満たすべき性質であり，わざわざ「冪等」と呼ぶようなものではない. 正確に言えば，Reactが意図しているのは「Hookが内部状態を持っていても，同じ(props, state, context)の組に対して同じVDOMを返す」ということだろう. しかしこれは「決定的関数(deterministic function)」であり，「冪等(idempotent)」とは異なる概念だ.

レンダリング操作は冪等として表現できる

ただし，視点を変えるとReactには冪等として表現できる操作がある.

状態 s を固定し，ユーザーのEffectや外部I/Oをいったん捨象して，DOM状態だけを見る. その上でレンダリングとコミットの合成をひとつの操作として考えてみよう:

$$ \begin{array}{c} u_{s}: \mathrm{DOM} \to \mathrm{DOM} \\ u_{s} = \operatorname{commit}(\operatorname{reconcile}(\operatorname{render}(s))) \end{array} $$

このとき:

$$u_{s}(u_{s}(\operatorname{dom})) = u_{s}(\operatorname{dom})$$

同じ状態に対してレンダリング・コミットを2回適用しても，DOM状態だけを見れば1回適用した結果と同じになる. 2回目の適用は差分がなければno-opとして扱える. これはDOM状態変換として見たときの冪等である.

つまり，Reactにおいて冪等として扱うべき対象はComponent関数そのもの ではなく，理想化されたレンダリング・コミット操作 u_s の方だ. この区別は決定的に重要である.

React FiberとAlgebraic Effects

ここで，Reactの内部構造に目を向けよう.

React Fiber — Reactのコアランタイム — には，Algebraic Effectsを思わせる特徴がある. Dan Abramovも，Reactのいくつかの仕組みを考えるための見方としてAlgebraic Effectsを紹介している（Dan Abramov, "Algebraic Effects for the Rest of Us", 2019）. ただし同記事は，Reactとの対応を「stretch」とし，SuspenseはAlgebraic Effectsそのものではなく，JavaScriptでは本当に継続をresumeしているわけではないとも明記している.

Algebraic Effectsとは

Algebraic Effectsは，計算とエフェクト（副作用）を分離するための数学的枠組みだ. この節の一般的な説明は，Plotkin and Power, "Algebraic Operations and Generic Effects" (2003) を参考にしている.

基本構造は3つの要素からなる:

1. エフェクトシグネチャ: 利用可能な操作の集合

2. 計算(computation): エフェクト操作を呼び出しうるプログラム

3. ハンドラ(handler): エフェクト操作に意味を与える解釈器

これはReactの実装そのものではなく，対応関係を説明するための擬似コードだ:

// エフェクトシグネチャ
effect GetState  : Unit → State
effect SetState  : State → Unit
effect ReadProps : Unit → Props
effect ReadContext: Key → Value
effect Suspend   : Promise<A> → A
effect Throw     : Error → ⊥

// ハンドラ（= React Fiber ランタイム）
handler ReactFiber {
  return vdom → vdom
  ReadProps(_, resume)      → resume(currentProps)
  GetState(_, resume)       → resume(currentFiber.memoizedState)
  SetState(newState, resume) → enqueueUpdate(newState); resume(unit)
  Suspend(promise, retryRender) → showFallback(); promise.then(() → retryRender())
  Throw(error, _)           → propagateToErrorBoundary(error)
}

ここで ユーザーが書くReact Function ComponentとReact Fiberランタイム の関係を次のように対応づけられる:

この対応では，ReactのHooksはエフェクト操作として読める:

ここで useProps はReactの実在APIではない. 以降では，通常はComponentの関数引数として受け取るpropsも，ハンドラから現在のpropsを読む概念的なHook操作として一般化して扱う.

ユーザーが書くComponentはエフェクトフルな計算(effectful computation)として，React Fiberはそのハンドラ（解釈器）として見なせる.

ただし，これはReactのすべてをAlgebraic Effectsだけで説明できる，という主張ではない. 特にRules of Hooksが要求する「Hook呼び出し列の静的な形」は，通常のMonadやAlgebraic Effectsの語彙だけでは捉えにくい. ここでは，まずRules of Hooksという規約があり，それがComponent bodyの形に制約をかける. その結果として，Hook呼び出し列をApplicative / Free Applicative的な構造へ比較的忠実に埋め込める，という順序で考える.

Kleisli圏における関数合成

「UI = f(State)」で暗黙に想定されている「関数合成」も，数学的に検証する必要がある.

Kleisli圏

Monad T が与えられた圏 𝒞 に対して，Kleisli圏 𝒞_T を構成できる. ここでのMonadは圏論的Monad，すなわち自己関手 T: 𝒞 → 𝒞 と自然変換 η: Id ⇒ T（unit），μ: T² ⇒ T（multiplication）の三つ組 (T, η, μ) でMonad則を満たすものとしている. MonadとKleisli圏の定義は Emily Riehl, Category Theory in Context, Definition 5.1.1 と Definition 5.2.10 を参照している:

• 対象: 𝒞 と同じ

• 射: A -> B in 𝒞_T は A -> T(B) in 𝒞

• 合成: f: A -> T(B) と g: B -> T(C) のKleisli合成は:

$$g \circ_{T} f = \mu_{C} \circ T(g) \circ f$$

すなわち:

$$ A \xrightarrow{f} T(B) \xrightarrow{T(g)} T(T(C)) \xrightarrow{\mu_{C}} T(C) $$

React ComponentはKleisli射

ここから先は，Reactの公式な形式意味論ではなく，Reactの各種エフェクトをひとつの抽象的なエフェクトMonadとして読むためのスケッチである. ReactのエフェクトMonadを便宜的に R と置く. JSの表面構文に合わせるなら，React Componentの型は次のように読める:

$$\mathrm{Component}: \mathrm{Props} \to R(\mathrm{VDOM})$$

これはKleisli圏 Set_R における射 Props -> VDOM として読むための表現である. ただし，Hook操作のプログラム構造を揃えて扱うなら，propsも外側の引数ではなく，概念的なHook操作として内側に入れられる:

$$\operatorname{useProps}: R(\mathrm{Props})$$

この読み方では，Props -> R(VDOM) は「propsを先に与える」表現であり，useProps を含む R(VDOM) は「propsをReact Fiberが解釈時に供給する」表現である.

Setの射（純粋関数）ではなく，Kleisli射（エフェクトフルな計算）として読む方が，Reactの振る舞いに近い.

コンポーネントの合成

JSXにおけるコンポーネントの合成を考えてみよう:

function Parent({ data }) {
  const processed = use(processData(data));
  return <Child items={processed} />;
}

この依存関係を抽象化すれば，Kleisli合成として次のようにスケッチできる:

$$\mathrm{Parent} = \mathrm{Child} \circ_{R} \mathrm{process}$$

ここで ∘_R はSetの通常の合成 ∘ ではなく，抽象化されたReactエフェクトMonadのKleisli合成 だ. useの呼び出し — つまりSuspendに相当するエフェクト — を経由しているため，純粋な関数合成では表現しにくい.

つまり，Reactにおける「関数合成」は，少なくともHooksやSuspenseまで含めて考えるなら，通常の意味での関数合成だけでは捉えきれない. これも「UI = f(State)」が素朴に正しくない理由のひとつである.

MonadのbindとApplicativeなスケルトン — Component Bodyの正体

Kleisli射の合成を理解したところで，Componentの関数bodyの中で何が起きているか をもう一段掘り下げよう.

Monad T に対して，bind演算（Haskellでは >>= と書かれる）は次の型を持つ:

$$\operatorname{bind}_{T}: T(A) \times (A \to T(B)) \to T(B)$$

これは「エフェクトフルな計算の結果を取り出して，次のエフェクトフルな計算に渡す」操作だ. Haskellのdo記法 はこのbindの連鎖を読みやすく書くための構文糖衣である:

-- do 記法
do
  state <- getState
  ctx   <- readContext themeCtx
  pure (view state ctx)

-- 脱糖後（bind の連鎖）
getState    >>= \state ->
readContext themeCtx >>= \ctx ->
pure (view state ctx)

この見方は，ReactのComponent bodyを「エフェクトを順に呼び出し，その結果を使ってVDOMを返す計算」として読む上では有用だ. useProps まで含めて抽象化すると，たとえば:

function Component() {
  const props = useProps(); // 概念的なHook操作: ReadProps >>= \props ->
  const [state, setState] = useState(init); // ← bind: GetState >>= \state ->
  const ctx = useContext(ThemeCtx); // ← bind: ReadContext >>= \ctx ->
  return <View name={props.name} state={state} ctx={ctx} />; // ← pure: return (View props state ctx)
}

React Componentのbodyは，局所的にはReactエフェクトMonadにおけるdo記法に近いものとして読める.

ただし，ここで注意が必要だ. 通常のMonadはReactが要求する「Hook呼び出し列の静的性」を表すには強すぎる. bindは前段の計算結果に応じて，次に実行するエフェクトの形そのものを変えられるからだ:

do
  x <- action1
  if condition x
    then do { y <- action2; pure (f x y) }  -- action2 がある
    else pure (g x)                          -- action2 がない

これはMonad計算としては自然に書ける. しかしReactのHooksでは，このように値や分岐に応じてHook列の形を変えることが禁止されている.

この「エフェクトの形は先に決まっていて，値だけが後から流れ込む」という性質は，Monadよりも Applicative の方が近い. Applicative F は，おおよそ次の操作を持つ:

$$ \begin{array}{c} \operatorname{pure}_{F}: A \to F(A) \\ \operatorname{ap}_{F}: F(A \to B) \times F(A) \to F(B) \end{array} $$

ここで ap_F は，Haskellでいう <*> に対応する.

Applicativeにはbindのような F(A) -> (A -> F(B)) -> F(B) はない. そのため，前のエフェクトの結果に応じて後続のエフェクト構造を変えることはできない. 代わりに，どのエフェクトをどの順序で使うかというスケルトンが静的に決まり，その結果を純粋な関数へ流し込む 形になる.

Rules of Hooksを満たすComponentに限ってかなり粗くスケッチすれば，Hook呼び出し列は次のようなApplicative的な形として読める:

pure view <*> useProps <*> useState init <*> useContext themeCtx

もちろんこれはReactの実装ではない. しかし，propsも useProps という概念的Hookとして含めると，「入力とHookの列は固定され，そこから得た値でJSXを構成する」という構造を表すには，bindの連鎖よりもApplicativeのスケルトンの方が近い.

Rules of HooksがApplicativeなスケルトンへの埋め込みを可能にする

ここで，ReactのRules of Hooksを見直す:

• Hookをループ，条件分岐，ネストされた関数の中で呼んではならない

• Hookは常にFunction Componentのトップレベルで呼ばなければならない

順序としては，この規約が先にある. つまり「Applicativeな表現がRules of Hooksを説明する」というより，Rules of HooksがComponent bodyの形を制限することで，useProps を含むHook操作からなるApplicativeなスケルトンへ埋め込めるようにしている と考える方が自然だ.

この意味での「忠実な埋め込み」とは，Hook呼び出しの個数と順序を落とさずに，プログラム構造として取り出せるという意味である.

Reactではこれに相当するものが禁止されている:

// NG: 条件分岐の中の Hook
function Component({ condition }) {
  const [x] = useState(0);
  if (condition) {
    const y = useContext(Ctx); // ← Rules of Hooks 違反
    return <A x={x} y={y} />;
  }
  return <B x={x} />;
}

なぜか？ React FiberはHookの呼び出し順序をlinked listとして保持している. レンダリングごとにHook操作の個数や順序が変わると，Fiberは前回のレンダリング結果と今回のHook呼び出しを正しく対応させられない.

一方で，Hook列を先に固定し，その後で値に応じて返すUIを分岐させることはできる:

// OK: Hook列は固定されている
function Component({ condition }) {
  const [x] = useState(0);
  const y = useContext(Ctx);
  return condition ? <A x={x} y={y} /> : <B x={x} />;
}

つまり，Reactが静的に保ちたいのは「値を使ったレンダリング結果」ではなく，Hook操作のプログラム構造 である. Rules of Hooksによってこの形が固定されるからこそ，FreeApplicative HookOp，あるいはコンポーネントツリーの再帰性まで含めるなら Fix (FreeApplicative HookOp) のような構造へ写す余地が生まれる.

この方向の参考実装として，ubugeeei/mreact がある. React HooksをHaskellのindexed Monadとして表現し，Hookの呼び出し順序を型レベルのlistとして表現することで，Rules of Hooksを型検査で扱う実験である. ただし，本稿の整理では，この「型レベルのHook列」はReactに後から貼り付ける表現というより，Rules of Hooksが先に固定しているプログラム形を，Applicative / Free Applicative的な静的スケルトンとして写し取ったものだ，と位置づけ直す.

useとSuspense — Algebraic Effectsを思わせる具象

use HookとSuspenseは，Reactの中でもAlgebraic Effectsを思わせる振る舞いが最も見えやすい部分だ. ただし，これはReactの実装が本物のAlgebraic Effectsを持つという意味ではない.

function UserProfile({ userId }) {
  const user = use(fetchUser(userId));
  return <div>{user.name}</div>;
}

function App() {
  return (
    <Suspense fallback={<Loading />}>
      <UserProfile userId={1} />
    </Suspense>
  );
}

このメカニズムを，Algebraic Effectsの語彙で記述してみる:

1. use(promise)はエフェクト操作の実行(perform)に対応する:

Promiseが未解決なら，Reactの公開APIとしてはそのComponentがsuspendする（useはSuspenseと統合されている）. これはAlgebraic Effectsにおける「操作の呼び出し」を思わせる非局所的制御フロー(non-local control flow)として読める.

2. Suspenseはエフェクトハンドラ(handler)に対応する:

Suspenseはsuspendを受け止め，fallback UIを表示し，Promiseがresolveしたらレンダリングを再試行する.

3.再レンダリング時にuse(promise)は解決済みの値を返す:

これはAlgebraic Effectsにおける「継続に値を渡して再開する」操作に似ている. ただし，ReactはJavaScriptの実行スタックを本当に保存してその地点から再開しているわけではなく，Promiseの解決後にComponent treeを再レンダリングする. この点は React Suspense docs と Dan Abramov, "Algebraic Effects for the Rest of Us" の注意に基づいている.

擬似的なハンドラ記法で表現すると:

handle(UserProfile(userId)) with {
  return vdom → vdom
  Suspend(promise, retryRender) →
    display <Loading />;
    await promise;
    retryRender()  // ← 本物の継続再開ではなく，再レンダリング
}

ここで特に重要なのは，useがComponentのレンダリングを中断し，Reactが後で再レンダリングできる ということだ.

通常のJavaScript関数は，呼び出したら最後まで実行される. async / awaitなら await の地点から継続できるが，React Componentはasync functionとして書かれていない. それでもReactはSuspense boundaryと再レンダリングによって，見かけ上は「そこで待って，値が来たら続きを評価した」ような体験を作る. この点が，Algebraic Effects（あるいは限定継続 / delimited continuation）を思わせる.

Client-Server「同型」の誤り

「同型JavaScript (Isomorphic JavaScript)」あるいは「ユニバーサルJavaScript」という言葉がある. Server Componentsの文脈でもしばしば使われるが，この「同型」は数学的に正しいのか.

圏論における同型

定義 (同型射). 圏 𝒞 において，射 f: A → B が同型射 (isomorphism)であるとは，射 g: B → A が存在して g ∘ f = id_A かつ f ∘ g = id_B を満たすことをいう.

この定義は，Emily Riehl, Category Theory in Context, Definition 1.1.10 における同型射の定義に沿っている.

同型は「構造を保存する可逆な変換」を意味する. A と B が同型ならば，圏論的には区別できない.

ServerレンダリングとClientレンダリングは同型ではない

サーバーとクライアントのレンダリングを関手として考える:

$$ \begin{array}{c} F_{S}: \mathrm{Component} \to \mathrm{HTML} \\ F_{C}: \mathrm{Component} \to \mathrm{DOM} \end{array} $$

そもそも HTML != DOM である. 出力カテゴリが異なるので，F_S と F_C の間に同型を構成する余地はない.

HTML文字列からDOMへの変換（パース）は存在するが，その逆（DOM → HTML）はシリアライズであり，これらの合成が恒等射になるとは限らない（イベントハンドラ，内部状態，クロージャなどは失われる）.

より正確な記述: 異なるエフェクトハンドラ

Algebraic Effectsの枠組みでは，サーバーレンダリングとクライアントレンダリングは同じエフェクトフルな計算に対する異なるハンドラとして理解できる:

$$ \begin{array}{c} \mathrm{Component}: \mathrm{Props} \to \mathrm{Eff}_{\mathrm{React}}(\mathrm{VDOM}) \\ \mathrm{handleServer}: \mathrm{Eff}_{\mathrm{React}}(\mathrm{VDOM}) \to \mathrm{HTMLString} \\ \mathrm{handleClient}: \mathrm{Eff}_{\mathrm{React}}(\mathrm{VDOM}) \to \mathrm{DOMMutations} \end{array} $$

Server ComponentsとClient Componentsの違いは，React公式ドキュメントが説明するように，実行環境と利用可能なAPIの違いとして現れる. この文章の読み方では，それを利用可能なエフェクトシグネチャの違い として捉える:

• Server Component: DBクエリ，ファイルシステムアクセスなどのサーバー側の処理を直接使える. useState, useEffectなど，多くのHooksは使えない.

• Client Component: useState, useEffectなどのクライアント側のAPIを使える. サーバー専用コードをClient module subtreeへ直接持ち込むことはできない.

これは同型ではなく，エフェクトシグネチャ間の包含関係あるいはサブタイピングとして理解すべきものだ.

$$ \begin{array}{c} \mathrm{ServerEffects} \neq \mathrm{ClientEffects} \\ \mathrm{SharedEffects} = \mathrm{ServerEffects} \cap \mathrm{ClientEffects} \end{array} $$

共有される部分は，利用箇所によってServer ComponentにもClient ComponentにもなりうるComponentとして動作する. サーバー専用の操作はServer側でのみ，クライアント専用の操作はClient側でのみ利用できる. これは「同型」ではなく，エフェクトシグネチャの部分的な重なりに基づく互換性(compatibility)として見る方がよい.

結: UI = f(State)を書き直す

ここまでの議論をまとめよう.

素朴な等式の問題

$$\mathrm{UI} = f(\mathrm{State})$$

この等式の問題点:

1. f は純粋関数ではない — Hooksを通じてエフェクトを実行する

2. 「冪等」の誤用 — Component関数は数学的に冪等ではない（冪等として表現できるのはレンダリング操作）

3. 合成が通常の関数合成だけでは捉えきれない — エフェクトの解釈はKleisli合成として表現できるが，Rules of Hooksで固定されたHook列はApplicativeな構造として見る方が自然

4. Client-Serverは同型ではない — 異なるエフェクトハンドラとして表現できる

より正確な記述

React Componentは，この文章の読み方では，JSの表面構文上はエフェクトMonad R のKleisli射として表現できる:

$$\mathrm{Component}: \mathrm{Props} \to R(\mathrm{VDOM})$$

ただし，Hook操作のプログラム構造を揃えて扱うなら，propsも外側の引数としてではなく，概念的なHook操作として内側に入れる:

$$\operatorname{useProps}: R(\mathrm{Props})$$

この場合，この式が捉えるのは「ComponentがReactランタイムに解釈されるエフェクトフルな計算である」という側面であって，Rules of Hooksが要求する静的なHook列そのものではない. Hook操作のプログラム構造については，Rules of Hooksが先に形を固定している. その制約があるから，ReadProps も含めて次のようなApplicative / Free Applicative的なスケルトンへ写せる:

$$\mathrm{HookProgram}\ A \approx \mathrm{FreeApplicative}(\mathrm{HookOp})\ A$$

UIの生成は，エフェクトハンドラ h による解釈として表せる:

$$\mathrm{UI} = h_{\mathrm{props}}(\mathrm{ComponentProgram})$$

ここで:

• ComponentProgram: HookProgram(VDOM) は，useProps, useState, useContext などを含む，ユーザーが書くエフェクトフルな計算の記述

• h_props: HookProgram(VDOM) -> DOM は，現在のpropsを供給しながらReact Fiberランタイムが計算を解釈することの表現

そして，ユーザーのEffectや外部I/Oを捨象したDOM状態変換として見るなら，レンダリング操作 u_s = h(render(s)) はDOM上の冪等な自己準同型として表現できる:

$$u_{s}(u_{s}(\operatorname{dom})) = u_{s}(\operatorname{dom})$$

$$\mathrm{UI} = f(\mathrm{State})$$

は教育的な直感としては有用だが，Reactの振る舞いを数学的に細かく見るには，いくつかの補足が必要になる.

React Componentは数学的な意味での純粋関数そのものではない. React Fiberによる解釈という側面はAlgebraic Effectsシステムにおけるエフェクトフルな計算として表現できる. 一方で，静的なHook列については表現がRules of Hooksを説明するのではなく，Rules of Hooksが先にプログラム形を制約する. その結果として，propsも useProps として含めたApplicative / Free Applicative的な構造へ忠実に写せる，と読む方が自然だ.

$$\mathrm{UI} = \mathrm{ReactHandle}_{\mathrm{props}}(\mathrm{ComponentProgram})$$

この認識によって，Reactの「ルール」やHooksの振る舞い，useとSuspenseの仕組み，Server Componentsの設計原理を，散在する個別知識としてではなく，エフェクトの解釈 と 静的なHookスケルトン という二層に分けて見通しやすくなる.

注意: 筆者はMetaの関係者でもReact Compilerの関係者でもありません．本記事はあくまで外部から観測できる情報に基づいた考察です．

前回の記事では，React Compilerの登場によってReact Componentが「Just JavaScript」ではなくなったのではないか，という議論をした． 今回はその続きとして，Metaのエコシステム全体を俯瞰し，Reactが「言語」として進化していく様子をより深く考察する．

MetaとJavaScriptインフラ

Meta (旧Facebook)はJavaScriptのエコシステムに対して長年にわたり大きな貢献をしてきた．

Babel

Babelは，もともと6to5という名前で始まったJavaScriptのトランスパイラだ． ES6+やJSXなど，ブラウザがネイティブにサポートしていない構文を変換し，後方互換性を保つ役割を担っている．

JSX was created as an extension to ECMAScript with the purpose of designing a more concise and easy-to-understand syntax for building DOM tree structures and attributes. — The Role of Babel in React

Babelは独立したオープンソースプロジェクトだが，Reactのエコシステムにおいて不可欠な存在だ． そして，React CompilerもBabel Pluginとして実装されている．

Flow

FlowはMetaが開発しているJavaScriptの静的型チェッカーだ． FlowもBabel Plugin (@babel/preset-flow)として実装されており，型注釈や独自構文を実行時に削除する役割を担っている．

そして今日の主題の一つとして，Flowは型チェッカーを超えて「言語」としての拡張を行っている．

FlowのComponent SyntaxとHook Syntax

2024年4月，FlowチームはComponent Syntaxを発表した． これはReactのプリミティブであるコンポーネントとフックに対する 一級言語サポート だ．

なぜ追加されたのか

Component Syntax was designed in coordination with the React team, and is already being used across Meta's codebases. — New Flow Language Features for React

These features bring improved ergonomics, expressiveness, and static enforcement for many of the Rules of React. — Flow Blog

つまり，FlowのComponent SyntaxはReactチームと連携して設計 され，Rules of Reactを静的に強制する ことを目的としている．

Component Syntaxの構文

通常の関数コンポーネントではなく，componentキーワードを使って定義する:

// 従来の関数コンポーネント
function Introduction(props: { name: string, age: number }) {
  return (
    <h1>
      My name is {props.name} and I am {props.age} years old
    </h1>
  );
}

// Flow の Component Syntax
component Introduction(name: string, age: number) {
  return (
    <h1>
      My name is {name} and I am {age} years old
    </h1>
  );
}

参考: Component Syntax | Flow

Component Syntaxでは:

• propsが直接パラメータになる: ボイラープレートの削減

• refの自動処理: 内部でReact.forwardRefでラップされる

• 明示的なreturnが必須: すべてのブランチでreturnが必要

• thisの使用禁止: コンポーネント内でthisは使えない

Hook Syntaxの構文

同様に，hookキーワードを使ってフックを定義する:

// 従来のカスタムフック
function useOnlineStatus(initial: boolean): boolean {
  const [isOnline, setIsOnline] = useState(initial);
  // ...
  return isOnline;
}

// Flow の Hook Syntax
hook useOnlineStatus(initial: boolean): boolean {
  const [isOnline, setIsOnline] = useState(initial);
  // ...
  return isOnline;
}

参考: Hook Syntax | Flow

Flowが検出するもの

FlowのComponent/Hook Syntaxは，Rules of Reactに違反するコードを 静的に 検出する:

1. Propsのmutation検出: コンポーネント内でpropsを変更しようとするコード

2. 条件付きフック呼び出しの禁止: if文内でのフック呼び出しをエラーとして報告

3. レンダリング中のrefアクセス検出: レンダリング中にrefを読み書きするコード

4. ネストしたcomponent/hookの検出: componentやhook内で別のcomponent/hookを定義するコード

Flow is able to detect mutations of props in a component or hook. Another pattern enforced in component bodies is that refs are not read or written to during render. — Flow Documentation

これが意味すること

FlowのComponent SyntaxとHook Syntaxは，Reactを「言語」として明示的に定義する試み だ．

従来，Reactコンポーネントは「JavaScriptの関数」として定義されていた． しかし，Flowは新しいキーワード(component, hook)を導入することで，Reactのセマンティクスを言語レベルで表現 している．

これは前回の記事で議論した「ReactはReactだ」という結論を，より明確な形で示している．

React Compiler: 暗黙的なアプローチ

Flowが「明示的」に新しい構文を導入しているのに対し，React Compilerは「暗黙的」なアプローチを取っている．

React Compilerの歴史

React Compilerは約10年 にわたる研究の成果だ:

• 2017年: FacebookがPrepackでコンパイラを初めて探索

• 2021年: Xuan Huangが新しいアプローチの最初のイテレーションをデモ

• 2024年: ベータ版リリース，React Conf 2024で発表

• 2025年10月: React Compiler v1.0安定版リリース

参考: React Compiler v1.0 – React

Hooks: Reactを「言語」として定義した瞬間

ここで一つの重要な視点を提示したい．

Reactを「言語」として定義したのはHooksの登場時点だった．

HooksにはRules of Hooksという，JavaScriptには存在しない制約がある:

• トップレベルでのみ呼び出す (ループ，条件分岐，ネストした関数内では呼ばない)

• React関数からのみ呼び出す (通常のJavaScript関数からは呼ばない)

これらはJavaScriptの関数には存在しないルールだ． Hooksを使う関数は，もはや「JavaScriptの関数」ではなく 「Reactの関数」 になる．

つまり，Hooksの導入こそが，Reactを独自のセマンティクスを持つ「言語」として定義した瞬間だった と言えるかもしれない．

Hooksの設計とコンパイラ

そして，Hooksは最初からコンパイラによる最適化を前提として設計されていた．

React Compiler v1.0のブログには以下の記述がある:

Hooksの設計自体がコンパイラの将来を見据えて設計されました． — React Compiler v1.0

これは後付けの話ではない．2018年に公開されたHooksの公式ドキュメント には，既にこの意図が明記されていた:

As Svelte, Angular, Glimmer, and others show, ahead-of-time compilation of components has a lot of future potential. Especially if it's not limited to templates.

— Introducing Hooks – React (2018)

We wanted to present an API that makes it more likely for code to stay on the optimizable path. To solve these problems, Hooks let you use more of React's features without classes.

— Introducing Hooks – React (2018)

つまり，Hooksは最初からコンパイラによる最適化を前提として設計されていた．

Dan Abramovの発言

当時ReactチームにいたDan Abramovも，コンパイラによる自動メモ化について早い段階から言及していた．

2021年2月に公開された記事"Before You memo()"では，手動でのメモ化の手間について触れた上で，以下のように述べている:

This last step is annoying, especially for components in between, and ideally a compiler would do it for you. In the future, it might.

— Dan Abramov, Before You memo() (2021)

「将来的には，コンパイラがこれを自動で行うかもしれない」——この発言はReact Compilerが一般公開される3年以上前 のものだ．

Reactチームは長年にわたり，コンパイラによる自動最適化 という明確なビジョンを持っていた． これは，Reactが「Just JavaScript」から「独自のセマンティクスを持つ言語」へと進化していく過程が，計画的なものであったことを示している．

React Compilerが行うこと

前回の記事でも触れたが，React Compilerは以下のような最適化を自動で行う:

// 入力
function VideoTag({ heading, videos, filter }) {
  const filteredVideos = [];
  for (const video of videos) {
    if (applyFilter(video, filter)) {
      filteredVideos.push(video);
    }
  }
  // ...
}

// 出力 (コンパイル後)
function VideoTab(t36) {
  const $ = useMemoCache(12);
  const { heading, videos, filter } = t36;
  let filteredVideos;

  if ($[0] !== videos || $[1] !== filter) {
    filteredVideos = [];
    for (const video of videos) {
      if (applyFilter(video, filter)) {
        filteredVideos.push(video);
      }
    }
    $[0] = videos;
    $[1] = filter;
    $[2] = filteredVideos;
  } else {
    filteredVideos = $[2];
  }
  // ...
}

参考: Understanding Idiomatic React – Joe Savona, Mofei Zhang, React Advanced 2023

条件付きメモ化: useMemoでは不可能なこと

React Compiler v1.0のブログでは，手動のuseMemo/useCallbackでは実現できない最適化 の例が示されている:

export default function ThemeProvider(props) {
  if (!props.children) {
    return null;
  }
  // コンパイラは条件付きリターン後のコードもメモ化できる
  // （手動の useMemo/useCallback では不可能）
  const theme = mergeTheme(props.theme, use(ThemeContext));
  return <ThemeContext value={theme}>{props.children}</ThemeContext>;
}

これはuseMemo/useCallbackでは実装できない，コンパイラ固有の能力です． — React Compiler v1.0

Rules of Reactの静的強制

React CompilerにはRules of Reactを検証するパス が含まれており，ESLintプラグインを通じて診断が提供される:

React Compiler's ESLint plugin helps developers proactively identify and correct Rules of React violations. The team strongly recommends everyone use the linter today. — React Compiler Beta Release

Metaでの成果

React Compilerは既にMetaの本番環境で運用されている:

• Instagram: 全ページで平均3%改善

• Quest Store: ロード時間が少なくとも4%改善，一部のインタラクションは2倍以上 高速化，初期ロードは最大12%改善

参考: React Compiler v1.0

React CompilerとFlowの連携

ここで重要なのは，React CompilerはFlowのComponent/Hook Syntaxを明示的にサポートしている ということだ．

compilationModeオプション

React CompilerにはcompilationModeというオプションがあり，どの関数をコンパイル対象とするかを制御できる:

• 'infer' (デフォルト): コンポーネント命名規則(PascalCase)とフック検出(useプレフィックス) を使用

• 'annotation': "use memo"ディレクティブでマークされた関数のみ

• 'syntax': Flowのcomponent/hook構文を使用した関数のみ

• 'all': すべてのトップレベル関数 (非推奨)

'syntax'モード

'syntax'モードを使用すると，Flowの専用構文で定義されたコンポーネントとフックのみがコンパイル対象となる:

// babel.config.js
{
  compilationMode: "syntax";
}

// ✅ コンパイル対象：Flow component 構文
component Button(label: string) {
  return <button>{label}</button>;
}

// ✅ コンパイル対象：Flow hook 構文
hook useCounter(initial: number) {
  const [count, setCount] = useState(initial);
  return [count, setCount];
}

// ❌ コンパイル対象外：通常の関数構文
function helper(data) {
  return process(data);
}

参考: compilationMode – React

これが意味すること

FlowとReact Compilerは 別々のプロジェクトではなく，連携して設計されている．

• FlowのComponent SyntaxはReactチームと連携して設計された

• React CompilerはFlowの構文を明示的にサポートしている

• Metaの内部では，この二つが組み合わせて使用されている

つまり，Metaは「Reactを言語として定義する」という一貫した戦略のもとで，FlowとReact Compilerの両方を開発している．

Reactドキュメントとfunctionキーワード

ここで一つの観察を共有したい．

Reactの公式ドキュメントでは，コンポーネントの定義に 一貫してfunctionキーワード が使われている:

export default function Profile() {
  return <img src="https://i.imgur.com/MK3eW3Am.jpg" alt="Katherine Johnson" />;
}

参考: Your First Component – React

アロー関数(const Profile = () => {}) についての言及は 一切ない．

なぜアロー関数ではないのか

Dan Abramovはoverreacted.ioで以下のように述べている:

it doesn't matter whether I use arrows or function declarations — Dan Abramov

技術的には，アロー関数でも関数宣言でもReactコンポーネントとして問題なく動作する． しかし，Reactドキュメントがfunctionキーワードを使い続けていることには，いくつかの考察ができる．

1. FlowのComponent Syntaxとの親和性

FlowのComponent Syntaxはcomponentキーワードを使う:

component Introduction(name: string, age: number) {
  // ...
}

これはfunctionキーワードを置き換える形で自然に導入できる． もしReactドキュメントがアロー関数を推奨していたら，この移行は不自然になる．

2.構文の一貫性

functionキーワードによる宣言は，将来的に専用構文(FlowのComponent Syntaxのようなもの) へ移行する場合にも自然な形で置き換えられる． アロー関数からの移行よりも，関数宣言からの移行の方が構文的に一貫性がある．

二つのアプローチの対比

FlowとReact Compilerは，同じ問題に対して異なるアプローチを取っている:

Flow:

• 方法: 新しいキーワード(component, hook)

• 明示性: 明示的 (新構文)

• 対象: Metaの内部コードベース

• 目的: Rules of Reactの静的強制

React Compiler:

• 方法: 既存の構文を変換

• 明示性: 暗黙的 (変換)

• 対象: 全Reactユーザー

• 目的: 自動メモ化 + Rules of Reactの検証

しかし，どちらも「Reactは独自のセマンティクスを持つ」という方向性では一致している．

Rules of React

ここで改めてRules of Reactを確認しておこう:

Rulesは，アイディオマティック（慣用的）で高品質なReactコードを書くためのルールです．単なるガイドラインではなく，これに従わないとバグが生じます． — Rules of React – React

主要なルール:

1. ComponentsとHooksはPure（純粋）である必要がある

   • 冪等性: 同じ入力に対して常に同じ出力

   • Side Effectsはレンダリングの外側でのみ実行

   • props, state, Hookの戻り値は不変

2. ReactがComponentsとHooksを呼び出す

   • コンポーネント関数を直接呼ばない

   • Hookを通常の値として渡さない

3. Rules of Hooks

   • トップレベルでのみ呼び出す

   • React関数からのみ呼び出す

これらのルールは「React的意味論」を形成している． そして，FlowのComponent SyntaxもReact Compilerも，これらのルールを 静的に強制する ことを目指している．

結論: Reactは「言語」として進化している

前回の記事で私は以下のように結論した:

Reactは，Reactだ． 構文がJavaScriptと同じで，意味が異なる別の存在だ．

今回の調査で，この結論はさらに強化された:

1. FlowのComponent Syntaxは，Reactのセマンティクスを 明示的に言語として定義 している

2. React Compilerは，Reactのセマンティクスを 暗黙的にJavaScriptに変換 している

3. Hooksは最初からコンパイラを前提として設計されていた

4. Reactドキュメントはfunctionキーワードを一貫して使用 しており，将来の構文拡張に備えている可能性がある

Reactが「Just JavaScript」であった時代は，徐々に終わりを迎えつつある． ReactはReactだ ——この言葉の意味は，今後ますます重要になっていくだろう．

これは私の単なるエッセイであり，React TeamやMetaの公式見解ではありません．

序文

皆さんにとってVue.jsとはどういうものだろうか？

普段Vue.jsを仕事で書いている人，趣味で触れている人，SNSやメディアを通じてその名前だけを知っている人—— 色々な立場の方がいるだろう．

覚えることが多い？
ルールがなくて分かりづらい？
簡単？
マイグレーションが大変？
でもなんか好き？
やっぱり嫌い？

いろんな感情やイメージを持った方がいると思う．

今日は，皆さんが何となく普段肌で感じているVue.jsの特徴やイメージについて改めて考え，体系的にまとめ直してみようと思う．そういう試みだ．

Vue.jsを4つのキャラクター で特徴づけてみる．

<div style="text-align: center; margin: 4rem 0 2rem;"> <svg viewBox="0 0 600 100" style="max-width: 600px; width: 100%;"> <defs> <linearGradient id="titleGrad1" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" style="stop-color:#42b883"/> <stop offset="50%" style="stop-color:#35495e"/> <stop offset="100%" style="stop-color:#42b883"/> <animate attributeName="x1" values="0%;100%;0%" dur="6s" repeatCount="indefinite"/> <animate attributeName="x2" values="100%;200%;100%" dur="6s" repeatCount="indefinite"/> </linearGradient> </defs> <text x="300" y="60" text-anchor="middle" font-size="32" font-weight="bold" fill="url(#titleGrad1)" font-family="system-ui, sans-serif"> 1 / 4 — Approachable </text> <line x1="100" y1="85" x2="500" y2="85" stroke="url(#titleGrad1)" stroke-width="2" stroke-dasharray="5,5"> <animate attributeName="stroke-dashoffset" values="0;-20" dur="1s" repeatCount="indefinite"/> </line> </svg> </div>

Vue.js is Easy?

この言葉を聞いたことがあるだろうか？

「Vue.js is Easy」

巷ではEasy / Simpleという対比もよく目にする．

実は，私自身はこの言葉をあまり好んではいない．
まず前提として，「何を簡単と感じるか」はその人のバックグラウンドに大きく左右されるものであり，かなり主観的だ．
この時点で迂闘に「簡単」という言葉を使うのは避けたいが，加えてこの言葉には2つの誤解 を生む可能性がある．

誤解その1：「Vue.jsは難しくなった」

Vue.jsは2020年にComposition APIとともにversion 3を発表し，大きな変化を得た．
そしてそれから今にあたるまでもたくさんの進化を続けてきた．

そんな中，一定数「Vue.jsは難しくなった」とか，「昔のVue.jsはもっとシンプルでよかった」などといった意見を見ることがある．

確かに，一時期のVue.jsはシンプルで親しみやすく，"簡単" なものを目指していたかもしれない．Vue.jsが今よりも"Easy"だった時代は確かにあるだろう．

しかしここで考えたいのは，「難しくなったのは本当にVue.jsだろうか？」 という話だ．

私はこれは違うと思う．

難しくなったのはWebだ．

フロントエンドが発足し出した2010年代から，徐々にUIの複雑さや，フロントエンドとしてのコードベースの規模，アプリ全体としてのパフォーマンスの課題が大きくなっていき，Webアプリケーション全体が難しくなった．
Vue.jsはそれらのニーズに追従したのだ．

それを裏付けるものとして，「Vue.jsはまだ従来の形式をサポートしている」 というのが挙げられる．
具体的には，TypeScriptを利用しないケースや，CDNからVue.jsを利用するケース．Options API．などなど昔からある形式は今もサポートを続けている．

つまり，「難しくなかった頃のVue」を今も利用することは可能だ．

誤解その2：「Vue.jsにはルールがないからダメだ」

「Vue.jsは簡単だけどルールがない．それはバグを生むし，コードを汚くする」という誤解だ．

プログラムに対して設計や規約を設ける，というのは一般的には良いプラクティスとされている．私もそう思う．
しかしこれらを設ける上で，注意するべきことがいくつかある．

まず1つ目は 「どの課題を解決するためのルールなのか」 ということだ．
ルールには目的が必要だ．そのルールを設けることによってどういった恩恵が受けられるのかということは常に考えられるべきだ．

そして2つ目は，それによって発生するトレードオフの考慮 だ．
規約は0コストではない．その制約が強ければ強いほど，それに準拠することを強く求められ，小回りが効かなくなったり，学習コストが高くなったりする．

じゃあ結局あなたはルールはない方が良いと言っているのですか？と言いたくなるかもしれないがそうではない．
「トレードオフに則ってあなたに合うものを選択しましょう．」 ということだ．

Webアプリケーションというのはあまりに多種多様だ．それを開発しているメンバーや会社の状況なども含め多種多様だ．
そして，それら全てに通じる銀の弾丸は存在しない．

加えて，設計や規約は0/1のものでもない．
私は「ルールは必要ない」と言いたいわけではなく，「ルールは必要だが，色々なものがある．それを選択できる価値は大きい．」 と言いたいわけだ．

そこをフレームワークが責任を負うか，実装者が責任を負うかはトレードオフであり，
実装者が負う場合には多少の責任を請け負う代わりに規約の柔軟さを手に入れることができる．

「Vue.jsは簡単だけどルールがないからダメだ」という反応はこのトレードオフを十分に考慮できていない．

Vue.js is Approachable

<div style="text-align: center; margin: 3rem 0;"> <svg viewBox="0 0 400 120" style="max-width: 400px; width: 100%;"> <defs> <linearGradient id="approachGrad" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" style="stop-color:#42b883"/> <stop offset="100%" style="stop-color:#35495e"/> </linearGradient> </defs> <rect x="20" y="20" width="360" height="80" rx="10" fill="none" stroke="url(#approachGrad)" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,1000;880,0;0,1000" dur="4s" repeatCount="indefinite"/> </rect> <text x="200" y="70" text-anchor="middle" font-size="24" font-weight="bold" fill="url(#approachGrad)" font-family="system-ui, sans-serif"> Approachable <animate attributeName="opacity" values="0;1;1;0" dur="4s" repeatCount="indefinite"/> </text> </svg> </div>

それでは，改めてVue.jsとは何なのだろうか？
私は，Vue.js is Approachableだと思っている．

Approachableという言葉は実は公式ドキュメントのトップにも登場している．

https://vuejs.org/

さまざまなトレードオフがあるが，一貫して 「いろんなユースケースにアプローチしやすい」 というところがかなりポイントだと思っている．

また，Vue.jsは"The Progressive Framework"とも呼ばれている．
これはApproachableと関連する概念で，「あなたのプロジェクトと共に成長し，あなたのニーズに適応できるフレームワーク」ということだ．
ビルドステップなしの静的HTML拡張から始めて，必要に応じてSPAやSSR，SSGへとステップアップしていくこともできるし，最初からフルスタックな構成で始めることもできる．
どんな規模でも，どんな段階からでもアプローチできる——これもまたVue.jsの柔軟さの表れだ．

https://ja.vuejs.org/guide/introduction#the-progressive-framework

Vue.jsはApproachableなUIフレームワークだ．

難しくなったわけでもなく，簡単さと引き換えにメチャクチャになるものでもない．
柔軟に選択できる，ということだ．

Vue.jsは難しくなったWebに追従した．従来の使い方も選択できる．
実装者が規約や設計を柔軟に選択できる．

これが，今日話したいVue.jsのキャラクターの1つ目 だ．

この話題についてさらに深掘りした記事も書いている．興味があればぜひ．

Vue.js is not Easy. It is Approachable.

<div style="text-align: center; margin: 4rem 0 2rem;"> <svg viewBox="0 0 600 100" style="max-width: 600px; width: 100%;"> <defs> <linearGradient id="titleGrad2" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" style="stop-color:#35495e"/> <stop offset="50%" style="stop-color:#42b883"/> <stop offset="100%" style="stop-color:#35495e"/> <animate attributeName="x1" values="0%;100%;0%" dur="6s" repeatCount="indefinite"/> <animate attributeName="x2" values="100%;200%;100%" dur="6s" repeatCount="indefinite"/> </linearGradient> </defs> <text x="300" y="60" text-anchor="middle" font-size="32" font-weight="bold" fill="url(#titleGrad2)" font-family="system-ui, sans-serif"> 2 / 4 — Language </text> <line x1="100" y1="85" x2="500" y2="85" stroke="url(#titleGrad2)" stroke-width="2" stroke-dasharray="5,5"> <animate attributeName="stroke-dashoffset" values="0;-20" dur="1s" repeatCount="indefinite"/> </line> </svg> </div>

Vue.jsは言語だ

Vue.jsが言語であることを説明してみる前に，まずはプログラミング言語のおさらいをしよう．

プログラミング言語とは

プログラミング言語とは何だろうか？
プログラミング言語はプログラムを書くための言語だ．名前の通りだ．

皆さんはこの世界にたくさんのプログラミング言語が存在していることを知っているはずだ．
JavaScriptやTypeScript，Rust，C++，Haskell．
それだけではない．HTMLやCSS，JSONもそのうちの1つだ．

これらは「汎用プログラミング言語」や，「ドメイン固有言語(DSL)」などのように分類される．どちらも言語だ．

どうしてこんなにもたくさんの言語が存在しているのだろうか？

ここで改めて考えて欲しいのだが，プログラムを記述しておくために，コンピューターにとって必要な形式というものはどういうものだろうか？

答えは バイナリ だ．これだけあれば全てのものは記述することができる．
ほとんどの状況で，任意の言語は最終的にはバイナリとなって動作している．

じゃあプログラミング言語というのは誰のためのものなのだろうか？
これは紛れもなく私たち，「人間」 のためのものだ．

<div style="text-align: center; margin: 3rem 0;"> <svg viewBox="0 0 620 300" style="max-width: 620px; width: 100%;"> <defs> <marker id="languageArrow" markerWidth="10" markerHeight="7" refX="9" refY="3.5" orient="auto"> <polygon points="0 0, 10 3.5, 0 7" fill="#35495e"/> </marker> </defs>

<text x="135" y="32" text-anchor="middle" font-size="14" fill="#35495e" font-weight="bold" font-family="system-ui">人間が読める意味へ</text>

<rect x="40" y="214" width="190" height="56" rx="8" fill="#35495e" fill-opacity="0.06" stroke="#35495e" stroke-width="2"/> <text x="135" y="237" text-anchor="middle" font-size="16" fill="#35495e" font-weight="bold" font-family="system-ui">バイナリ</text> <text x="135" y="257" text-anchor="middle" font-size="12" fill="#666" font-family="monospace">01010110...</text>

<rect x="40" y="136" width="190" height="56" rx="8" fill="#35495e" fill-opacity="0.06" stroke="#35495e" stroke-width="2"/> <text x="135" y="159" text-anchor="middle" font-size="16" fill="#35495e" font-weight="bold" font-family="system-ui">アセンブリ</text> <text x="135" y="179" text-anchor="middle" font-size="12" fill="#666" font-family="monospace">mov, jmp...</text>

<path d="M135 210 L135 198 M128 205 L135 198 L142 205" fill="none" stroke="#35495e" stroke-width="2.3" stroke-linecap="round" stroke-linejoin="round"/> <path d="M135 132 L135 120 M128 127 L135 120 L142 127" fill="none" stroke="#35495e" stroke-width="2.3" stroke-linecap="round" stroke-linejoin="round"/>

<rect x="40" y="58" width="190" height="56" rx="8" fill="#42b883" fill-opacity="0.14" stroke="#42b883" stroke-width="2.5"/> <text x="135" y="81" text-anchor="middle" font-size="16" fill="#35495e" font-weight="bold" font-family="system-ui">高水準言語</text> <text x="135" y="101" text-anchor="middle" font-size="12" fill="#35495e" font-family="system-ui">C, JS, Rust...</text>

<line x1="246" y1="86" x2="318" y2="86" stroke="#42b883" stroke-width="3" marker-end="url(#languageArrow)"/>

<text x="450" y="82" text-anchor="middle" font-size="24" fill="#35495e" font-weight="bold" font-family="system-ui">Vue.js — DSL for UI</text> <line x1="320" y1="102" x2="580" y2="102" stroke="#42b883" stroke-width="2"/>

<circle cx="337" cy="138" r="15" fill="#42b883"/> <text x="337" y="143" text-anchor="middle" font-size="13" fill="#fff" font-weight="bold" font-family="system-ui">1</text> <text x="365" y="143" font-size="15" fill="#35495e" font-family="system-ui">HTML + CSS + JS を拡張</text>

<circle cx="337" cy="180" r="15" fill="#42b883"/> <text x="337" y="185" text-anchor="middle" font-size="13" fill="#fff" font-weight="bold" font-family="system-ui">2</text> <text x="365" y="185" font-size="15" fill="#35495e" font-family="system-ui">宣言的 UI を記述</text>

<circle cx="337" cy="222" r="15" fill="#42b883"/> <text x="337" y="227" text-anchor="middle" font-size="13" fill="#fff" font-weight="bold" font-family="system-ui">3</text> <text x="365" y="227" font-size="15" fill="#35495e" font-family="system-ui">コンポーネントで整理</text> </svg> </div>

世の中には多様な記述対象がある．
ハードウェアの制御や，OS，ブラウザ，Webアプリケーション，CLIツールまで．
そしてこれらに必要な知識は異なる．

それぞれの領域で，いろんなコンセプトをもとに人間にとっての "書きやすさ" や "正しさ" を提供するためにたくさんの言語が存在しているわけだ．

非構造的なプログラミングから始まり，制御としての知識をプログラミング言語自体に与えるために構文を用意し，OOPをやる為にOOPの言語を作り，FPをやる為にFPの言語を作り，メモリ管理から解放されるためにまた新しい言語を作り，データを記述するためにデータ記述言語を作る．

Vue.jsはUIを記述するための言語

それでは，Vue.jsはどうだろうか．
Vue.jsはUIを記述するための言語 だと捉えることができる．

すでに，UIを記述するための言語として，HTML, CSS, そしてJavaScriptがある．
Vue.jsはこれらをベースとして，足りない知識を拡張している．

1.宣言的なテンプレート記述

UIのtemplateを宣言的に，かつ動的に記述するということ．
このプラクティスはHTML, CSS, JavaScriptが登場した時期にはあまりないものだった．

Webが発展していくとともに，クライアントで動作するコードの複雑さは大きくなり，さまざまなUIの記述方法が乱立し，安定性や可読性の観点からUIは宣言的に記述できる方が良いということがわかってきた．

Vue.jsはtemplateを記述するための言語をサポートし，この問題を解決した．

2.コンポーネント中心の設計

関連するHTML, CSS, JavaScriptを1つにまとめて記述し，UIに関連する記述の凝集度を高める．
加えて，scoped cssやslotの記述もVue.jsが提供している拡張知識の1つだ．

<script setup lang="ts">
import { ref } from "vue";
const count = ref(0);
function increment() {
  count.value++;
}
</script>

<template>
  <button type="button" @click="increment">count is: {{ count }}</button>
</template>

<style scoped>
button {
  color: #42b883;
}
</style>

ここで注目したいのは，<script> 部分ではJavaScriptのメンタルモデルをほぼそのまま使える ということだ．
ViewとViewModelの境界——つまりReactivityにさえ気をつけていれば，あとは普通のJavaScriptだ．
特別なルールやフレームワーク固有の制約はほとんどない．これもVue.jsのApproachableさの一つだ．

3. Optimizerとしてのコンパイラ

コンパイラによって静的に解析できるパフォーマンスチューニングは人の手で行うべきではない．
こういった最適化はコンパイラに任せて，私たちはUIを記述するために必要な本質的なことに集中しているべきだ．

Vue.jsのコンパイラはさまざまな最適化を行なってくれる．

• Static Hoisting: 静的なノードを巻き上げ，再生成を回避

• Patch Flags: 動的な部分にフラグを付与し，差分検出を高速化

• Tree Flattening: ネストした静的ノードをフラット化

• Vapor Mode: 仮想DOMを介さない，より直接的なレンダリング

言語機能としての構文

皆さんはif文やwhile, for, loopなどを知っているはずだ．
しかし，コンピュータからするとこれらは本質的にはただの "判定してジャンプ" だ．
なぜ "判定してジャンプ" という1つの命令に対して複数の構文があるのだろうか？

それぞれのユースケースで意味付けがされていた方が人間にとって分かりやすいからだ．
単に分岐をしたい時には"if"，特定の条件下にある時まで繰り返したい時には"while"．
コンピューターにとってはただのジャンプでも，人間にとってはこういった意味付がプログラムを書く時の補助になる．

Vue.jsについても同じだ．
プログラム上，コンポーネント間のデータの受け渡しは，その名の通り "受け渡し" でしかない．
しかし，UIを記述する際にはUIの知識を拡張し，意味付を行うことができる．

• コンポーネントにデータをバインドしたい時にはv-bind

• イベントを購読/発行したい時にはv-on, emit

• コンポーネントにテンプレートを差し込みたい時にはslot

そう，Vue.jsはUIを記述する時に発生する知識を言語として整理した のだ．
これはかなりプログラミング言語の価値観そのものだ．

言語ツール

そしてもう1つ，忘れてはいけないことは 「Vue.jsには十分に発達した言語ツールがある」 ということだ．

プログラミング言語を作る際にはさまざまな課題がある．
仕様の決定，コンパイラの実装，そして言語ツールだ．
たくさんの時間と労力がかかる．

確かに，一昔前のVue.jsは他のフレームワークに比べて少し遅れていた．
だが時間は進み，多大な努力とともにかなり改善されている．

ここで改めて，vuejs/language-tools，そしてJohnson Chuさん，コミュニティメンバーの皆さんに感謝したい．

「Vue.jsは言語だ」という話についてさらに深掘りした記事も書いている．

What is Vue.js? It's just a language lol

<div style="text-align: center; margin: 4rem 0 2rem;"> <svg viewBox="0 0 600 100" style="max-width: 600px; width: 100%;"> <defs> <linearGradient id="titleGrad3" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" style="stop-color:#42b883"/> <stop offset="50%" style="stop-color:#35495e"/> <stop offset="100%" style="stop-color:#42b883"/> <animate attributeName="x1" values="0%;100%;0%" dur="6s" repeatCount="indefinite"/> <animate attributeName="x2" values="100%;200%;100%" dur="6s" repeatCount="indefinite"/> </linearGradient> </defs> <text x="300" y="60" text-anchor="middle" font-size="32" font-weight="bold" fill="url(#titleGrad3)" font-family="system-ui, sans-serif"> 3 / 4 — Ecosystem </text> <line x1="100" y1="85" x2="500" y2="85" stroke="url(#titleGrad3)" stroke-width="2" stroke-dasharray="5,5"> <animate attributeName="stroke-dashoffset" values="0;-20" dur="1s" repeatCount="indefinite"/> </line> </svg> </div>

Vue.jsは拡大するエコシステム

Vue.jsのもう一つの大きな特徴は，Vue.jsから始まり，Vue.jsの枠を超えて広がっていくエコシステム だ．

<div style="text-align: center; margin: 3rem 0;"> <svg viewBox="-20 0 740 500" style="max-width: 740px; width: 100%;"> <defs> <linearGradient id="evanGrad" x1="0%" y1="0%" x2="100%" y2="100%"> <stop offset="0%" style="stop-color:#42b883"/> <stop offset="100%" style="stop-color:#646cff"/> </linearGradient> </defs>

<!-- Central Evan You node --> <circle cx="360" cy="70" r="50" fill="url(#evanGrad)"> <animate attributeName="r" values="50;53;50" dur="3s" repeatCount="indefinite"/> <animate attributeName="opacity" values="0.8;1;0.8" dur="4s" repeatCount="indefinite"/> </circle> <text x="360" y="66" text-anchor="middle" font-size="13" fill="#fff" font-weight="bold" font-family="system-ui">Evan You</text> <text x="360" y="80" text-anchor="middle" font-size="9" fill="#ddd" font-family="system-ui">Creator</text>

<!-- Evan You to Vue.js connection --> <line x1="310" y1="70" x2="235" y2="70" stroke="#42b883" stroke-width="3"> <animate attributeName="stroke-dasharray" values="0,100;100,0;0,100" dur="3s" repeatCount="indefinite"/> </line> <circle cx="185" cy="70" r="45" fill="#42b883"> <animate attributeName="r" values="45;48;45" dur="3s" repeatCount="indefinite"/> <animate attributeName="opacity" values="0.8;1;0.8" dur="3s" repeatCount="indefinite"/> </circle> <text x="185" y="75" text-anchor="middle" font-size="15" fill="#fff" font-weight="bold" font-family="system-ui">Vue.js</text>

<!-- Evan to Vite connection (Evan created Vite) --> <line x1="325" y1="110" x2="260" y2="160" stroke="#646cff" stroke-width="2" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,100;100,0;0,100" dur="2.5s" repeatCount="indefinite"/> </line>

<!-- Vue.js to Vite connection (Vue birthed Vite) --> <line x1="210" y1="110" x2="230" y2="155" stroke="#646cff" stroke-width="3"> <animate attributeName="stroke-dasharray" values="0,60;60,0;0,60" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="250" cy="195" r="40" fill="#646cff"> <animate attributeName="r" values="40;43;40" dur="3s" repeatCount="indefinite"/> <animate attributeName="opacity" values="0.8;1;0.8" dur="3s" repeatCount="indefinite"/> </circle> <text x="250" y="200" text-anchor="middle" font-size="13" fill="#fff" font-weight="bold" font-family="system-ui">Vite</text>

<!-- VoidZero --> <line x1="360" y1="120" x2="360" y2="160" stroke="#f59e0b" stroke-width="3"> <animate attributeName="stroke-dasharray" values="0,50;50,0;0,50" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="360" cy="200" r="40" fill="#f59e0b"> <animate attributeName="r" values="40;43;40" dur="4s" repeatCount="indefinite"/> <animate attributeName="opacity" values="0.8;1;0.8" dur="4s" repeatCount="indefinite"/> </circle> <text x="360" y="205" text-anchor="middle" font-size="11" fill="#fff" font-weight="bold" font-family="system-ui">VoidZero</text>

<!-- VoidZero to Vite connection --> <line x1="320" y1="200" x2="290" y2="195" stroke="#f59e0b" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,50;50,0;0,50" dur="2.5s" repeatCount="indefinite"/> </line>

<!-- Volar.js from Vue --> <line x1="140" y1="70" x2="95" y2="70" stroke="#35495e" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,50;50,0;0,50" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="65" cy="70" r="25" fill="#35495e"> <animate attributeName="opacity" values="0.8;1;0.8" dur="3s" repeatCount="indefinite"/> </circle> <text x="65" y="75" text-anchor="middle" font-size="8" fill="#42b883" font-weight="bold" font-family="system-ui">Volar.js</text>

<!-- Volar.js expansions --> <line x1="50" y1="92" x2="35" y2="125" stroke="#35495e" stroke-width="1.5" opacity="0.7"> <animate attributeName="stroke-dasharray" values="0,40;40,0;0,40" dur="2s" repeatCount="indefinite"/> </line> <circle cx="30" cy="145" r="16" fill="#ff5d01" opacity="0.9"> <animate attributeName="opacity" values="0.7;0.9;0.7" dur="2s" repeatCount="indefinite"/> </circle> <text x="30" y="149" text-anchor="middle" font-size="6" fill="#fff" font-weight="bold" font-family="system-ui">Astro</text>

<line x1="80" y1="92" x2="95" y2="125" stroke="#35495e" stroke-width="1.5" opacity="0.7"> <animate attributeName="stroke-dasharray" values="0,40;40,0;0,40" dur="2s" repeatCount="indefinite"/> </line> <circle cx="100" cy="145" r="16" fill="#fcb32c" opacity="0.9"> <animate attributeName="opacity" values="0.7;0.9;0.7" dur="2s" repeatCount="indefinite"/> </circle> <text x="100" y="149" text-anchor="middle" font-size="6" fill="#000" font-weight="bold" font-family="system-ui">MDX</text>

<!-- Nuxt from Vue (curved path to avoid Vite) --> <line x1="150" y1="100" x2="80" y2="270" stroke="#00dc82" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,200;200,0;0,200" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="65" cy="300" r="25" fill="#00dc82"> <animate attributeName="opacity" values="0.8;1;0.8" dur="3s" repeatCount="indefinite"/> </circle> <text x="65" y="305" text-anchor="middle" font-size="9" fill="#fff" font-weight="bold" font-family="system-ui">Nuxt</text>

<!-- UnJS from Nuxt --> <line x1="65" y1="325" x2="65" y2="355" stroke="#00dc82" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,40;40,0;0,40" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="65" cy="380" r="22" fill="#00dc82" opacity="0.9"> <animate attributeName="opacity" values="0.7;0.9;0.7" dur="3s" repeatCount="indefinite"/> </circle> <text x="65" y="380" text-anchor="middle" dominant-baseline="central" font-size="8" fill="#fff" font-weight="bold" font-family="system-ui">UnJS</text>

<!-- Nitro from UnJS --> <line x1="87" y1="375" x2="115" y2="355" stroke="#00dc82" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,40;40,0;0,40" dur="2s" repeatCount="indefinite"/> </line> <circle cx="135" cy="340" r="16" fill="#00dc82" opacity="0.7"> <animate attributeName="opacity" values="0.5;0.7;0.5" dur="2s" repeatCount="indefinite"/> </circle> <text x="135" y="340" text-anchor="middle" dominant-baseline="central" font-size="6" fill="#fff" font-weight="bold" font-family="system-ui">Nitro</text>

<!-- h3 from Nitro --> <line x1="151" y1="340" x2="180" y2="340" stroke="#00dc82" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,30;30,0;0,30" dur="2s" repeatCount="indefinite"/> </line> <circle cx="198" cy="340" r="14" fill="#00dc82" opacity="0.6"> <animate attributeName="opacity" values="0.4;0.6;0.4" dur="2s" repeatCount="indefinite"/> </circle> <text x="198" y="340" text-anchor="middle" dominant-baseline="central" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">h3</text>

<!-- citty from UnJS --> <line x1="87" y1="380" x2="120" y2="380" stroke="#00dc82" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,35;35,0;0,35" dur="2s" repeatCount="indefinite"/> </line> <circle cx="138" cy="380" r="14" fill="#00dc82" opacity="0.6"> <animate attributeName="opacity" values="0.4;0.6;0.4" dur="2s" repeatCount="indefinite"/> </circle> <text x="138" y="380" text-anchor="middle" dominant-baseline="central" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">citty</text>

<!-- ofetch from UnJS --> <line x1="87" y1="388" x2="115" y2="410" stroke="#00dc82" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,35;35,0;0,35" dur="2s" repeatCount="indefinite"/> </line> <circle cx="135" cy="425" r="14" fill="#00dc82" opacity="0.6"> <animate attributeName="opacity" values="0.4;0.6;0.4" dur="2s" repeatCount="indefinite"/> </circle> <text x="135" y="425" text-anchor="middle" dominant-baseline="central" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">ofetch</text>

<!-- unplugin from UnJS --> <line x1="80" y1="400" x2="95" y2="445" stroke="#00dc82" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,50;50,0;0,50" dur="2s" repeatCount="indefinite"/> </line> <circle cx="105" cy="465" r="14" fill="#00dc82" opacity="0.6"> <animate attributeName="opacity" values="0.4;0.6;0.4" dur="2s" repeatCount="indefinite"/> </circle> <text x="105" y="463" text-anchor="middle" dominant-baseline="central" font-size="4" fill="#fff" font-weight="bold" font-family="system-ui">un-</text> <text x="105" y="470" text-anchor="middle" dominant-baseline="central" font-size="4" fill="#fff" font-weight="bold" font-family="system-ui">plugin</text>

<!-- jiti from UnJS --> <line x1="50" y1="400" x2="35" y2="435" stroke="#00dc82" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,40;40,0;0,40" dur="2s" repeatCount="indefinite"/> </line> <circle cx="28" cy="455" r="14" fill="#00dc82" opacity="0.6"> <animate attributeName="opacity" values="0.4;0.6;0.4" dur="2s" repeatCount="indefinite"/> </circle> <text x="28" y="455" text-anchor="middle" dominant-baseline="central" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">jiti</text>

<!-- mlly from UnJS --> <line x1="45" y1="395" x2="20" y2="405" stroke="#00dc82" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,30;30,0;0,30" dur="2s" repeatCount="indefinite"/> </line> <circle cx="8" cy="415" r="14" fill="#00dc82" opacity="0.6"> <animate attributeName="opacity" values="0.4;0.6;0.4" dur="2s" repeatCount="indefinite"/> </circle> <text x="8" y="415" text-anchor="middle" dominant-baseline="central" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">mlly</text>

<!-- Analog, TanStack Start from Nitro --> <line x1="135" y1="356" x2="135" y2="380" stroke="#00dc82" stroke-width="1.5" opacity="0.4"> <animate attributeName="stroke-dasharray" values="0,25;25,0;0,25" dur="2s" repeatCount="indefinite"/> </line> <text x="180" y="370" text-anchor="middle" font-size="5" fill="#8899aa" font-family="system-ui">Analog, TanStack Start...</text>

<!-- Vite expansions (other frameworks) --> <line x1="250" y1="235" x2="250" y2="275" stroke="#646cff" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,45;45,0;0,45" dur="2s" repeatCount="indefinite"/> </line> <text x="250" y="295" text-anchor="middle" font-size="6" fill="#8899aa" font-family="system-ui">React, Svelte,</text> <text x="250" y="308" text-anchor="middle" font-size="6" fill="#8899aa" font-family="system-ui">Solid, Qwik...</text>

<!-- Vite to Nuxt connection --> <line x1="215" y1="215" x2="85" y2="285" stroke="#646cff" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,150;150,0;0,150" dur="2s" repeatCount="indefinite"/> </line>

<!-- Vitest from VoidZero --> <line x1="400" y1="190" x2="465" y2="160" stroke="#42b883" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,80;80,0;0,80" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="490" cy="145" r="28" fill="#42b883"> <animate attributeName="opacity" values="0.8;1;0.8" dur="3s" repeatCount="indefinite"/> </circle> <text x="490" y="150" text-anchor="middle" font-size="10" fill="#fff" font-weight="bold" font-family="system-ui">Vitest</text>

<!-- Rolldown from VoidZero --> <line x1="360" y1="240" x2="360" y2="290" stroke="#ff6b6b" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,55;55,0;0,55" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="360" cy="320" r="28" fill="#ff6b6b"> <animate attributeName="opacity" values="0.8;1;0.8" dur="3s" repeatCount="indefinite"/> </circle> <text x="360" y="325" text-anchor="middle" font-size="9" fill="#fff" font-weight="bold" font-family="system-ui">Rolldown</text>

<!-- Oxc from VoidZero --> <line x1="400" y1="215" x2="470" y2="260" stroke="#f97316" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,90;90,0;0,90" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="500" cy="285" r="28" fill="#f97316"> <animate attributeName="opacity" values="0.8;1;0.8" dur="3s" repeatCount="indefinite"/> </circle> <text x="500" y="290" text-anchor="middle" font-size="10" fill="#fff" font-weight="bold" font-family="system-ui">Oxc</text>

<!-- Oxc to Rolldown connection --> <line x1="475" y1="295" x2="388" y2="320" stroke="#ff6b6b" stroke-width="1.5" stroke-dasharray="4,4" opacity="0.6"> <animate attributeName="opacity" values="0.4;0.7;0.4" dur="2s" repeatCount="indefinite"/> </line> <text x="432" y="300" text-anchor="middle" font-size="5" fill="#8899aa" font-family="system-ui">powers</text>

<!-- Rolldown to Vite connection --> <line x1="332" y1="320" x2="278" y2="220" stroke="#ff6b6b" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,120;120,0;0,120" dur="2.5s" repeatCount="indefinite"/> </line>

<!-- Oxc expansions (6 tools) --> <!-- Parser --> <line x1="528" y1="270" x2="565" y2="210" stroke="#f97316" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,70;70,0;0,70" dur="2s" repeatCount="indefinite"/> </line> <circle cx="580" cy="195" r="14" fill="#f97316" opacity="0.7"> <animate attributeName="opacity" values="0.5;0.7;0.5" dur="2s" repeatCount="indefinite"/> </circle> <text x="580" y="199" text-anchor="middle" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">Parser</text>

<!-- Linter --> <line x1="528" y1="280" x2="575" y2="250" stroke="#f97316" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,55;55,0;0,55" dur="2s" repeatCount="indefinite"/> </line> <circle cx="590" cy="235" r="14" fill="#f97316" opacity="0.7"> <animate attributeName="opacity" values="0.5;0.7;0.5" dur="2s" repeatCount="indefinite"/> </circle> <text x="590" y="239" text-anchor="middle" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">Linter</text>

<!-- Formatter --> <line x1="528" y1="285" x2="575" y2="285" stroke="#f97316" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,50;50,0;0,50" dur="2s" repeatCount="indefinite"/> </line> <circle cx="595" cy="285" r="14" fill="#f97316" opacity="0.7"> <animate attributeName="opacity" values="0.5;0.7;0.5" dur="2s" repeatCount="indefinite"/> </circle> <text x="595" y="283" text-anchor="middle" font-size="4" fill="#fff" font-weight="bold" font-family="system-ui">Forma-</text> <text x="595" y="290" text-anchor="middle" font-size="4" fill="#fff" font-weight="bold" font-family="system-ui">tter</text>

<!-- Transformer --> <line x1="528" y1="295" x2="575" y2="325" stroke="#f97316" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,55;55,0;0,55" dur="2s" repeatCount="indefinite"/> </line> <circle cx="590" cy="340" r="14" fill="#f97316" opacity="0.7"> <animate attributeName="opacity" values="0.5;0.7;0.5" dur="2s" repeatCount="indefinite"/> </circle> <text x="590" y="338" text-anchor="middle" font-size="4" fill="#fff" font-weight="bold" font-family="system-ui">Trans-</text> <text x="590" y="345" text-anchor="middle" font-size="4" fill="#fff" font-weight="bold" font-family="system-ui">former</text>

<!-- Minifier --> <line x1="520" y1="305" x2="560" y2="375" stroke="#f97316" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,80;80,0;0,80" dur="2s" repeatCount="indefinite"/> </line> <circle cx="575" cy="390" r="14" fill="#f97316" opacity="0.7"> <animate attributeName="opacity" values="0.5;0.7;0.5" dur="2s" repeatCount="indefinite"/> </circle> <text x="575" y="394" text-anchor="middle" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">Minifier</text>

<!-- Resolver --> <line x1="515" y1="310" x2="545" y2="420" stroke="#f97316" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,120;120,0;0,120" dur="2s" repeatCount="indefinite"/> </line> <circle cx="555" cy="440" r="14" fill="#f97316" opacity="0.7"> <animate attributeName="opacity" values="0.5;0.7;0.5" dur="2s" repeatCount="indefinite"/> </circle> <text x="555" y="444" text-anchor="middle" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">Resolver</text>

<!-- Web Community label --> <text x="360" y="470" text-anchor="middle" font-size="10" fill="#42b883" font-family="system-ui" opacity="0.8"> → Web Community へ広がる </text>

<!-- Outer ring pulse --> <circle cx="360" cy="260" r="260" fill="none" stroke="#42b883" stroke-width="1" opacity="0.2"> <animate attributeName="r" values="260;265;260;275;260" dur="5s" repeatCount="indefinite"/> <animate attributeName="opacity" values="0.2;0.15;0.2;0.08;0.2" dur="5s" repeatCount="indefinite"/> </circle> </svg> </div>

Vite — Vueから始まった革命

皆さんご存知Viteは昨今のフロントエンドには欠かせない存在だ．

元々Viteはvue-dev-serverという名前で始まった．
これは，Vue.jsの作者であるEvan You氏が，ブラウザのNative ESMを利用し，バンドラを使わない開発セットアップを行うというアイデアから始まったものだった．

それから，No-bundle Dev Server for Vue Single-File ComponentsとしてViteに改名され，v2でcoreがframework agnosticになり，「Next Generation Frontend Tooling」という位置付けになった．

そうだ．ViteはVue.jsから始まり進化を続け，昨今ではVue.jsにとどまらず，フロントエンドのツールとして広がった．

Volar.js — 言語ツールフレームワーク

先ほどもVue.jsのキャラクターの一つとして言語の側面と，優れた言語ツールがあることについて触れた．

Vue.jsの言語ツールは過去にもいくつかの実装があったが，今はvuejs/language-toolsが公式の言語ツールになっている．

元々これはVolarというVue.js用のVSCode extensionとして始まったもので，コミュニティメンバーの個人的なプロジェクトだった．
Volarはv1.0に到達するまでに2年という長い年月と膨大な労力とともに進化し，Vue.js公式の推奨ツールになった．

そこから，Vue.jsに依存しないコアな機能がVolar.jsとして切り離され，Vue.jsの言語ツールはvuejs/language-toolsという名前になった．

そしてこのVolar.jsは現在，AstroやMDX，AngularのメタフレームワークであるAnalogの言語ツールの基盤として広まっている．

UnJS — Nuxtから広がるエコシステム

UnJSはUnified JavaScriptまたはUnleash JavaScriptというJavaScriptのライブラリ群だ．

コンセプトとしては，1つの目的を持った1つのライブラリを高品質に，どんな環境でも動作するように，そしてコラボレーティブにといったことが挙げられる．

このUnJSはNuxt2でリードエンジニアをやっていたPooya Parsa氏がNuxtとは別のエコシステムとして開発を続けていたもので，Nuxt3に向けた開発をしている際に切り出されたサーバーエンジンやPooya氏が作っていたライブラリ群をUnJSというオーガナイゼーションにリブランディングされた．

UnJSとNuxtは綿密にコラボレートし，今ではNuxtの多くの機能がUnJSによって実装されている．
HTTPフレームワークであるh3や，それをベースにしたサーバーエンジンであるNitroなどがその代表だ．
NitroはAnalogなどでも使われている．

ecosystem-ci — テストの仕組みも共有

Vue.jsはたくさんのエコシステムを抱えている．
状態管理のライブラリやUIフレームワーク，ルーター，テスティングライブラリなど本当にたくさんある．

Vue2からVue3へのアップグレードではこれらのエコシステムの追従が大きな課題となった．
そこで，これらのダウンストリームのエコシステムのインテグレーションテストを行う仕組みが導入された．

これは元々ViteのSvelteとのインテグレーションテストで取り組まれていたもので，Vue.jsにもこの仕組みが入った．
そして，これもまた，Vue.js / Viteの垣根を超えて，SvelteやAstro，Oxcなどでも同様の仕組みが導入されている．

<div style="text-align: center; margin: 4rem 0 2rem;"> <svg viewBox="0 0 600 120" style="max-width: 600px; width: 100%;"> <defs> <linearGradient id="voidzeroGrad" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" style="stop-color:#f59e0b"/> <stop offset="50%" style="stop-color:#42b883"/> <stop offset="100%" style="stop-color:#f59e0b"/> <animate attributeName="x1" values="0%;100%;0%" dur="4s" repeatCount="indefinite"/> <animate attributeName="x2" values="100%;200%;100%" dur="4s" repeatCount="indefinite"/> </linearGradient> </defs> <text x="300" y="50" text-anchor="middle" font-size="28" font-weight="bold" fill="url(#voidzeroGrad)" font-family="system-ui, sans-serif"> VoidZero — 次世代への布石 </text> <text x="300" y="90" text-anchor="middle" font-size="14" fill="#8899aa" font-family="system-ui, sans-serif"> Vite, Vitest, Rolldown, Oxc を統合する新たなビジョン </text> </svg> </div>

VoidZeroと統一ツールチェーンへの挑戦

Vue.jsエコシステムの広がりは，さらに大きな挑戦へと繋がっている．

断片化という課題

Evan You氏はViteの開発を通じて，JavaScriptエコシステム全体が抱える課題に直面した．

「あらゆるアプリケーションは無数のサードパーティ依存関係に頼っており，それらがうまく連携するよう設定することは最も困難なタスクの一つだ」

— https://voidzero.dev/posts/announcing-voidzero-inc

Viteは開発体験を大きく改善したが，内部では依然として様々な依存関係があり，異なるツール間での不整合を埋めるための抽象化やワークアラウンドが必要だった．そして，異なるツール間での重複したパースやシリアライゼーションコストがボトルネックになっていた．

VoidZeroの誕生

2024年，Evan You氏はVoidZeroを設立した．
「次世代のJavaScript統一ツールチェーンを構築する」 というビジョンを掲げて．

https://voidzero.dev/posts/announcing-voidzero-inc

VoidZeroのビジョンは4つの特徴を持つ統合開発スタックの構築だ：

<div style="text-align: center; margin: 3rem 0;"> <svg viewBox="0 0 500 300" style="max-width: 500px; width: 100%;"> <defs> <linearGradient id="boxGrad" x1="0%" y1="0%" x2="100%" y2="100%"> <stop offset="0%" style="stop-color:#42b883"/> <stop offset="100%" style="stop-color:#35495e"/> </linearGradient> </defs>

<!-- Unified --> <rect x="20" y="20" width="220" height="60" rx="10" fill="url(#boxGrad)" opacity="0.9"> <animate attributeName="opacity" values="0.9;1;0.9" dur="2s" repeatCount="indefinite"/> </rect> <text x="130" y="45" text-anchor="middle" font-size="14" fill="#fff" font-weight="bold" font-family="system-ui">Unified</text> <text x="130" y="65" text-anchor="middle" font-size="10" fill="#ccc" font-family="system-ui">同じ AST, resolver, module interop</text>

<!-- High Performance --> <rect x="260" y="20" width="220" height="60" rx="10" fill="url(#boxGrad)" opacity="0.9"> <animate attributeName="opacity" values="0.9;1;0.9" dur="2s" begin="0.5s" repeatCount="indefinite"/> </rect> <text x="370" y="45" text-anchor="middle" font-size="14" fill="#fff" font-weight="bold" font-family="system-ui">High Performance</text> <text x="370" y="65" text-anchor="middle" font-size="10" fill="#ccc" font-family="system-ui">Rust による最大並列化</text>

<!-- Composable --> <rect x="20" y="100" width="220" height="60" rx="10" fill="url(#boxGrad)" opacity="0.9"> <animate attributeName="opacity" values="0.9;1;0.9" dur="2s" begin="1s" repeatCount="indefinite"/> </rect> <text x="130" y="125" text-anchor="middle" font-size="14" fill="#fff" font-weight="bold" font-family="system-ui">Composable</text> <text x="130" y="145" text-anchor="middle" font-size="10" fill="#ccc" font-family="system-ui">独立したコンポーネント</text>

<!-- Runtime Agnostic --> <rect x="260" y="100" width="220" height="60" rx="10" fill="url(#boxGrad)" opacity="0.9"> <animate attributeName="opacity" values="0.9;1;0.9" dur="2s" begin="1.5s" repeatCount="indefinite"/> </rect> <text x="370" y="125" text-anchor="middle" font-size="14" fill="#fff" font-weight="bold" font-family="system-ui">Runtime Agnostic</text> <text x="370" y="145" text-anchor="middle" font-size="10" fill="#ccc" font-family="system-ui">あらゆる JS 環境で一貫した体験</text>

<!-- Arrow down to projects --> <line x1="250" y1="170" x2="250" y2="200" stroke="#42b883" stroke-width="2" marker-end="url(#arrowhead)"/>

<!-- Project boxes --> <rect x="40" y="210" width="100" height="40" rx="5" fill="#646cff"/> <text x="90" y="235" text-anchor="middle" font-size="12" fill="#fff" font-weight="bold" font-family="system-ui">Vite</text>

<rect x="160" y="210" width="100" height="40" rx="5" fill="#42b883"/> <text x="210" y="235" text-anchor="middle" font-size="12" fill="#fff" font-weight="bold" font-family="system-ui">Vitest</text>

<rect x="280" y="210" width="100" height="40" rx="5" fill="#ff6b6b"/> <text x="330" y="235" text-anchor="middle" font-size="12" fill="#fff" font-weight="bold" font-family="system-ui">Rolldown</text>

<rect x="400" y="210" width="60" height="40" rx="5" fill="#f97316"/> <text x="430" y="235" text-anchor="middle" font-size="12" fill="#fff" font-weight="bold" font-family="system-ui">Oxc</text>

<!-- Open Source badge -->

<text x="250" y="280" text-anchor="middle" font-size="11" fill="#42b883" font-family="system-ui">Open Source</text> </svg>

</div>

Oxc — Rustで書かれた高速コンパイラ

Oxc (JavaScript Oxidation Compiler)は，Boshen氏が率いるRustで書かれたJavaScript/TypeScriptツールチェーンだ．

パーサー，リンター(Oxlint)，フォーマッター(Oxfmt)，トランスフォーマー，ミニファイアー，リゾルバーを含む包括的なツールセットで，圧倒的なパフォーマンス を実現している：

• Oxlint: ESLintの50-100倍高速

• Oxfmt: Prettierの35倍高速

• oxc-resolver: webpackのenhanced-resolveの30倍高速

• transformer: Babelの40倍高速

https://oxc.rs/

2025年6月にはOxlint 1.0が安定版としてリリースされ，ShopifyやAirbnbなど5,200以上の早期採用者がいる．

Rolldown — Rustベースのバンドラー

RolldownはVoidZeroが開発するRustベースのバンドラーで，Rollup互換のAPIを持ちながら10-30倍高速 なパフォーマンスを実現する．

https://ja.vite.dev/blog/announcing-vite8

2026年3月12日にはVite 8.0が安定版としてリリースされ，Rolldownが単一のRustベースバンドラーとして統合された．
これにより，従来のesbuild + Rollupという二重構成は，Vite 8ではRolldownを中心にした一本化されたアーキテクチャへ移行した．

preview / beta期間の実プロジェクトでは，印象的なパフォーマンス改善が報告されている：

• Linear: 本番ビルド時間46秒 → 6秒

• Ramp: ビルド時間57%削減

• Mercedes-Benz.io: 最大38%削減

• Beehiiv: 64%削減

この取り組みにより，Viteは ビルドツール(Vite)，バンドラー(Rolldown)，コンパイラ(Oxc)という近いチームが連携してメンテナンスするエンドツーエンドのツールチェーンのエントリーポイントになっていく．

Vite+ — 統合されたツールチェイン

さらにVoidZeroは2026年3月13日にVite+ Alphaをリリースした．
Viteのスーパーセットとして，グローバルCLIのvpとプロジェクトローカルのvite-plusパッケージを中心に，開発者に必要なツール群を単一の統合されたツールチェインとして提供する：

• vp create — プロジェクトやモノレポのスキャフォールディング

• vp env — Node.jsランタイムのグローバル / プロジェクト単位の管理

• vp install — 選択したパッケージマネージャー経由の依存インストール

• vp dev — Vite開発サーバー

• vp check — 型チェック，リンティング，フォーマットの一括実行

• vp test — Vitestによるテスト

• vp build — 本番ビルド

• vp run — Vite Taskによるスクリプト / モノレポタスク実行

• vp pack — tsdownによるライブラリ / CLIパッケージング

https://voidzero.dev/posts/announcing-vite-plus-alpha

https://viteplus.dev/

信頼とオープンソースへのコミットメント

ここで重要なのは，VoidZeroの オープンソースへの姿勢 だ．

「コミュニティがViteに置いてくれた信頼」が，この方向性を深く考えるきっかけになった

— https://voidzero.dev/posts/announcing-voidzero-inc

VoidZeroは明確に宣言している：

「オープンソース化したものは全てオープンソースのまま．Vite, Vitest, Rolldown, Oxcはオープンソース．」

— https://voidzero.dev/posts/announcing-voidzero-inc

そのVite+ Alphaでは，Vite+自体もMITライセンスで完全にオープンソース化された．

そして重要なのは，VoidZeroはVue.jsをファーストクラスでサポートする ということだ．Vue.jsから始まったこれらのツールは，Vue.jsエコシステムに対して最高の体験を提供し続ける．

これらのプロジェクトは既にOpenAI，Google，Apple，Microsoft，Shopifyなど主要な組織で採用されている．その信頼性は実証済みだ．

https://github.com/vitejs/companies-using-vite

<div style="text-align: center; margin: 4rem 0 2rem;"> <svg viewBox="0 0 600 100" style="max-width: 600px; width: 100%;"> <defs> <linearGradient id="titleGrad4" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" style="stop-color:#35495e"/> <stop offset="50%" style="stop-color:#42b883"/> <stop offset="100%" style="stop-color:#35495e"/> <animate attributeName="x1" values="0%;100%;0%" dur="6s" repeatCount="indefinite"/> <animate attributeName="x2" values="100%;200%;100%" dur="6s" repeatCount="indefinite"/> </linearGradient> </defs> <text x="300" y="60" text-anchor="middle" font-size="32" font-weight="bold" fill="url(#titleGrad4)" font-family="system-ui, sans-serif"> 4 / 4 — Community </text> <line x1="100" y1="85" x2="500" y2="85" stroke="url(#titleGrad4)" stroke-width="2" stroke-dasharray="5,5"> <animate attributeName="stroke-dashoffset" values="0;-20" dur="1s" repeatCount="indefinite"/> </line> </svg> </div>

Vue.jsはコミュニティ

最後のキャラクター．これはVue.jsとは切っても切れない大事な要素だ．

<div style="text-align: center; margin: 3rem 0;"> <svg viewBox="0 0 500 320" style="max-width: 500px; width: 100%;"> <defs> <radialGradient id="coreGlow" cx="50%" cy="50%" r="50%"> <stop offset="0%" style="stop-color:#42b883;stop-opacity:0.4"/> <stop offset="70%" style="stop-color:#42b883;stop-opacity:0.1"/> <stop offset="100%" style="stop-color:#42b883;stop-opacity:0"/> </radialGradient> <linearGradient id="nodeGrad" x1="0%" y1="0%" x2="100%" y2="100%"> <stop offset="0%" style="stop-color:#64d4a3"/> <stop offset="100%" style="stop-color:#35495e"/> </linearGradient> <filter id="glow"> <feGaussianBlur stdDeviation="2" result="coloredBlur"/> <feMerge> <feMergeNode in="coloredBlur"/> <feMergeNode in="SourceGraphic"/> </feMerge> </filter> </defs>

<!-- Background pulse --> <circle cx="250" cy="160" r="80" fill="url(#coreGlow)"> <animate attributeName="r" values="80;100;80" dur="4s" repeatCount="indefinite"/> </circle>

<!-- Network connections between nodes --> <!-- Inner ring connections --> <line x1="175" y1="90" x2="325" y2="90" stroke="#42b883" stroke-width="1" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="3s" repeatCount="indefinite"/> </line> <line x1="175" y1="90" x2="130" y2="180" stroke="#42b883" stroke-width="1" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="3s" begin="0.5s" repeatCount="indefinite"/> </line> <line x1="325" y1="90" x2="370" y2="180" stroke="#42b883" stroke-width="1" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="3s" begin="1s" repeatCount="indefinite"/> </line> <line x1="130" y1="180" x2="190" y2="260" stroke="#42b883" stroke-width="1" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="3s" begin="1.5s" repeatCount="indefinite"/> </line> <line x1="370" y1="180" x2="310" y2="260" stroke="#42b883" stroke-width="1" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="3s" begin="2s" repeatCount="indefinite"/> </line> <line x1="190" y1="260" x2="310" y2="260" stroke="#42b883" stroke-width="1" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="3s" begin="2.5s" repeatCount="indefinite"/> </line>

<!-- Connections to center --> <line x1="175" y1="90" x2="250" y2="160" stroke="#42b883" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,100;100,0" dur="2s" repeatCount="indefinite"/> </line> <line x1="325" y1="90" x2="250" y2="160" stroke="#42b883" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,100;100,0" dur="2s" begin="0.33s" repeatCount="indefinite"/> </line> <line x1="130" y1="180" x2="250" y2="160" stroke="#42b883" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,100;100,0" dur="2s" begin="0.66s" repeatCount="indefinite"/> </line> <line x1="370" y1="180" x2="250" y2="160" stroke="#42b883" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,100;100,0" dur="2s" begin="1s" repeatCount="indefinite"/> </line> <line x1="190" y1="260" x2="250" y2="160" stroke="#42b883" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,100;100,0" dur="2s" begin="1.33s" repeatCount="indefinite"/> </line> <line x1="310" y1="260" x2="250" y2="160" stroke="#42b883" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,100;100,0" dur="2s" begin="1.66s" repeatCount="indefinite"/> </line>

<!-- Outer nodes for depth --> <circle cx="100" cy="60" r="6" fill="#35495e" opacity="0.4"> <animate attributeName="opacity" values="0.3;0.6;0.3" dur="4s" repeatCount="indefinite"/> </circle> <circle cx="400" cy="60" r="5" fill="#35495e" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="4s" begin="1s" repeatCount="indefinite"/> </circle> <circle cx="60" cy="240" r="7" fill="#35495e" opacity="0.35"> <animate attributeName="opacity" values="0.25;0.55;0.25" dur="4s" begin="2s" repeatCount="indefinite"/> </circle> <circle cx="440" cy="240" r="5" fill="#35495e" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="4s" begin="3s" repeatCount="indefinite"/> </circle> <circle cx="250" cy="30" r="6" fill="#35495e" opacity="0.4"> <animate attributeName="opacity" values="0.3;0.6;0.3" dur="4s" begin="0.5s" repeatCount="indefinite"/> </circle> <circle cx="250" cy="300" r="5" fill="#35495e" opacity="0.35"> <animate attributeName="opacity" values="0.25;0.55;0.25" dur="4s" begin="1.5s" repeatCount="indefinite"/> </circle>

<!-- Faint outer connections --> <line x1="100" y1="60" x2="175" y2="90" stroke="#35495e" stroke-width="0.5" opacity="0.2"/> <line x1="400" y1="60" x2="325" y2="90" stroke="#35495e" stroke-width="0.5" opacity="0.2"/> <line x1="60" y1="240" x2="130" y2="180" stroke="#35495e" stroke-width="0.5" opacity="0.2"/> <line x1="440" y1="240" x2="370" y2="180" stroke="#35495e" stroke-width="0.5" opacity="0.2"/> <line x1="250" y1="30" x2="250" y2="160" stroke="#35495e" stroke-width="0.5" opacity="0.15"/> <line x1="250" y1="300" x2="250" y2="160" stroke="#35495e" stroke-width="0.5" opacity="0.15"/>

<!-- Central Vue logo simplified --> <g filter="url(#glow)"> <polygon points="250,120 270,155 280,140 250,95 220,140 230,155" fill="#42b883" opacity="0.9"> <animate attributeName="opacity" values="0.8;1;0.8" dur="2s" repeatCount="indefinite"/> </polygon> <polygon points="250,120 265,145 250,175 235,145" fill="#35495e" opacity="0.9"> <animate attributeName="opacity" values="0.8;1;0.8" dur="2s" repeatCount="indefinite"/> </polygon> </g>

<!-- Main community nodes --> <g filter="url(#glow)"> <circle cx="175" cy="90" r="14" fill="#42b883" opacity="0.85"> <animate attributeName="r" values="14;16;14" dur="3s" repeatCount="indefinite"/> </circle> <circle cx="325" cy="90" r="14" fill="#42b883" opacity="0.85"> <animate attributeName="r" values="14;16;14" dur="3s" begin="0.5s" repeatCount="indefinite"/> </circle> <circle cx="130" cy="180" r="14" fill="#42b883" opacity="0.85"> <animate attributeName="r" values="14;16;14" dur="3s" begin="1s" repeatCount="indefinite"/> </circle> <circle cx="370" cy="180" r="14" fill="#42b883" opacity="0.85"> <animate attributeName="r" values="14;16;14" dur="3s" begin="1.5s" repeatCount="indefinite"/> </circle> <circle cx="190" cy="260" r="14" fill="#42b883" opacity="0.85"> <animate attributeName="r" values="14;16;14" dur="3s" begin="2s" repeatCount="indefinite"/> </circle> <circle cx="310" cy="260" r="14" fill="#42b883" opacity="0.85"> <animate attributeName="r" values="14;16;14" dur="3s" begin="2.5s" repeatCount="indefinite"/> </circle> </g>

<!-- Node labels -->

<text x="175" y="90" text-anchor="middle" dominant-baseline="central" font-size="8" fill="#fff" font-weight="bold" font-family="system-ui">Dev</text> <text x="325" y="90" text-anchor="middle" dominant-baseline="central" font-size="8" fill="#fff" font-weight="bold" font-family="system-ui">Dev</text> <text x="130" y="180" text-anchor="middle" dominant-baseline="central" font-size="8" fill="#fff" font-weight="bold" font-family="system-ui">Dev</text> <text x="370" y="180" text-anchor="middle" dominant-baseline="central" font-size="8" fill="#fff" font-weight="bold" font-family="system-ui">Dev</text> <text x="190" y="260" text-anchor="middle" dominant-baseline="central" font-size="8" fill="#fff" font-weight="bold" font-family="system-ui">Dev</text> <text x="310" y="260" text-anchor="middle" dominant-baseline="central" font-size="8" fill="#fff" font-weight="bold" font-family="system-ui">Dev</text> </svg>

</div>

コミュニティから生まれるもの

ここまで紹介してきたプロジェクトの多くは，コミュニティメンバーの個人的なプロジェクトとして始まったものだ．

• Volar — Johnson Chu氏の個人プロジェクトからVue.js公式言語ツールへ

• Oxc — Boshen氏が始めたRustパーサーがVoidZeroの中核技術へ

• UnJS — Pooya Parsa氏のNuxt外での取り組みが独立エコシステムへ

これらは偶然ではない．
Vue.jsコミュニティには，個人の情熱がエコシステム全体を動かす力 がある．

信頼の連鎖

Vue.jsのエコシステムが他のフレームワークやツールにも影響を与えている現象は，単なる技術的な優位性だけでは説明できない．

それは 信頼 だ．

Evan You氏がVoidZeroを設立する際に述べたように：

「コミュニティがViteに置いてくれた信頼」

— https://voidzero.dev/posts/announcing-voidzero-inc

この信頼は一朝一夕に築かれたものではない．
10年以上にわたる一貫したオープンソースへのコミットメント，後方互換性への配慮，そしてコミュニティの声に耳を傾ける姿勢．

その結果として，Vue.jsから始まったツールがReactエコシステムでも使われ，Svelteでも使われ，Solidでも使われている．

Webコミュニティへの貢献

これはVue.jsコミュニティだけの話ではない．
Web開発者コミュニティ全体 への貢献だ．

• ViteはVue.js以外のあらゆるフレームワークの開発体験を変えた

• Volar.jsはAstroやMDXの言語サポートを可能にした

• NitroはNuxt以外のメタフレームワークにも採用された

• OxcとRolldownはJavaScriptツールチェーン全体の高速化に貢献している

一つのコミュニティで生まれたイノベーションが，境界を越えてWeb全体に広がっていく．

これこそが，オープンソースの真の力であり，Vue.jsコミュニティが体現している価値だと私は思う．

<div style="text-align: center; margin: 4rem 0 2rem;"> <svg viewBox="0 0 600 150" style="max-width: 600px; width: 100%;"> <defs> <linearGradient id="finGrad" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" style="stop-color:#42b883"/> <stop offset="25%" style="stop-color:#35495e"/> <stop offset="50%" style="stop-color:#646cff"/> <stop offset="75%" style="stop-color:#f59e0b"/> <stop offset="100%" style="stop-color:#42b883"/> <animate attributeName="x1" values="-100%;100%" dur="5s" repeatCount="indefinite"/> <animate attributeName="x2" values="0%;200%" dur="5s" repeatCount="indefinite"/> </linearGradient> </defs> <text x="300" y="60" text-anchor="middle" font-size="36" font-weight="bold" fill="url(#finGrad)" font-family="system-ui, sans-serif"> Characterize Vue.js </text> <text x="300" y="100" text-anchor="middle" font-size="16" fill="#666" font-family="system-ui, sans-serif"> Approachable × Language × Ecosystem × Community </text> <line x1="100" y1="125" x2="500" y2="125" stroke="url(#finGrad)" stroke-width="3"> <animate attributeName="stroke-dasharray" values="0,400;400,0;0,400" dur="4s" repeatCount="indefinite"/> </line> </svg> </div>

結び

Vue.jsを4つのキャラクターで特徴づけてみた．

1. Approachable — 柔軟に選択できる，いろんなユースケースにアプローチしやすい

2. Language — UIを記述するためのドメイン固有言語

3. Ecosystem — Vue.jsから始まり，枠を超えて広がるエコシステム

4. Community — 個人の情熱がエコシステムを動かし，信頼を築く

これらは独立した特徴ではない．
相互に影響し合い，強化し合っている．

Approachableだからこそ多くの人が参入し，コミュニティが育つ．
コミュニティが育つからこそ，言語ツールやエコシステムが発展する．
エコシステムが発展するからこそ，より多くの選択肢が生まれ，Approachableさが増す．

この循環がVue.jsの価値の本質だと私は思う．

Vue.jsはただのUIフレームワークではない．
アプローチしやすく，
人間のために設計された言語であり，
境界を越えて広がるエコシステムであり，
信頼と情熱で繋がるコミュニティだ．

これは私の単なるエッセイであり，Vue.js Teamの公式見解ではありません．

昨今, Simple/Easyというマーケティング用語がよく使われる.
今回は他の具体的な言語やフレームワークについて言及するつもりはない.
あくまでVue.jsとの向き合い方についての物語だ.

「Vue.js is Easy」

このフレーズを聞いたことがあるだろうか？
私は何度も聞いた.
そして, それと同じくらい「Vue.jsにはルールがないからダメだ」という言葉もたくさん聞いてきた.

誤謬

私がVue.js / Webを触り始めたのはおおよそ2020のQ4頃で, それ以前の世界がどうであったかは知らない.
そして, どのタイミングからこのフレーズが流行り始めたのかも知らない.
しかし, 「今」の自分の感覚として, この言葉を使うのが適切なのかどうかについてはいつも疑問を感じている.

「Vue.js is Easy」は私が思うに, 今も限られたコンテキストであれば正しいだろう.
しかしそのコンテキストを理解している人たちはいったいどれくらいいるだろうか.

昨今は「ルールを持つ存在(Webフレームワークに限らず)」の流行もあり, 彼らは彼らで「〇〇 は △△ である(Easyではないけれど)」というマーケティングをよくやる.

そしてそれに飛来して,

「Vue.jsにはルールがないからダメだ」
「目先の簡単さを求めて堅さを捨てている」
「ルールがないことは, コードをメチャクチャにする」

などの言説が生まれる.

抽象的なマーケティングは抽象的なマーケティングで打ちのめされるのだ.

トレードオフ

先ほども言ったように, 確かに「Vue.js is Easy」というのは一部のコンテキストで正しい.
Vue.jsには明確なルールがないので, 何かルールを学んだりしなくても フレームワークの立場としては間違いではない という意味では正しい.

しかし実際にプロダクトを作るには, いろんなことを考える必要がある.
そしてここには トレードオフ がある.

おそらく多くの人たちはこのトレードオフを考えずに, 「ルールはあった方が良い」という意志を先行させ, プログラミングと向き合っている.
もちろん, 「ルールがあった方がいい」ということにすらトレードオフは存在するが, 今日話したいのはここではない.
ある状況下で, 「ルールがあった方が良い」という結論になったことを想像しよう.

ここで考えるべきなのは,

• なんのためのルールなのか (そのルールがあると何が嬉しいのか)

• 今(未来)のチーム(自分)にとって適切なものか (括弧書きにしているのは, コンテキストによって変わるからだ.)

• そのルールがどのようなトレードオフを生むのか

と言ったことだ.

Webアプリケーションはあまりにも多種多様だ.
バックエンドから得たデータにUIを実装し, 単純に表示するだけのものもあれば,
複雑なDOMオペレーションと組み合わせてリッチなUIを提供するものもある.

そしてこれらに必要なルールは全く異なっている.
設計とはかなりアドホックなもので, 銀の弾丸はない のだ.

責任者

ここで重要なのは「誰がそのルールの責任を持つのか」ということだ.
私はWebアプリケーションの場合, 必ずしもフレームワークがルールを持つことが良いとは思わない.
もちろん, 場合によってはフレームワークがルールを持つことが良いユースケースもあるだろう.

しかし「フレームワーク」という我々の基礎となる部分がこの責任を負うというのはやはりトレードオフを含むものだ.
フレームワークがここの責任を持った場合, ほとんどの場合ではそれに準拠することが望まれる.
例えそれが我々のプロダクトにとって重要じゃないことであってもだ.

そして同時に, それによって失われた他のトレードオフについても考えてはおくべきだ (学習コストなど).
加えて「誰がそのルールの責任を持つのか」というのと, 「ルールが必要であるかどうか」というのは全く別の話であることに注意したい.

言葉による抽象化

ここまでの話で私が話したい本質的なことは済んだ.
しかし, どうしても言い切り方の言葉遊びがしたくなるのが私達だ.

「Vue.js is Easy」に対してネガティブな誤謬が含まれやすく, 適切でないならばなんと言えばいいだろうか.
私はVue.jsの公式ドキュメントに登場する「Approachable」という言葉が大好きだ.

https://vuejs.org/

先程も言った通り, 「Vue.js is Easy」は「フレームワークとしての責任」の範囲であれば正しいが,「Webアプリケーションの実装 (・保守運用)」の話に拡大されると間違った判断をする可能性を含んでいる.

何かしらの課題 (需要) があるなら規約や設計を考えるというのは当たり前のことだ.
Easyという言葉は，ここをあたかも考えなくても良いものが作れるものだ，という誤謬を与えかねない.

Vue.jsはApproachableなのだ.
何かを考える時，邪魔にならない.

しかし，それと引き換えに実装者は少しの責任を負う.
これはトレードオフなのだ.

これは私の単なるエッセイであり，Vue.js Teamの公式見解ではありません.

• ここで話すことは公式の見解ではない.

• "言語" についての話をするが，かなり話したいことに寄せている. 現実はそんなに単純ではない.

• あくまで，「こういう見方もできる」という一つの側面を示すものである.

関連: Characterize Vue.jsでは，この言語としての見方を含めて，Vue.jsの性格をもう少し広く整理している．

コンピュータへの命令

Webアプリケーションの実装も，ネイティブアプリケーションの実装も，ブラウザの実装も，全てはコンピュータへの命令である. そして，それらは全てバイナリで表現できる.

しかし，人間がバイナリを直接書くことは現実的ではない. これは，日本語話者に対してモールス信号で会話を強いるようなものである. 意味を伝達する手段としては成立するが，実用的ではない.

プログラミング言語という抽象

プログラミング言語は大きく2つに分類される.

汎用プログラミング言語 (general-purpose programming language)は，特定の領域に限定されない汎用的な計算を記述するための言語である. Rust, TypeScript, JavaScript, Python, C, Haskellなどがこれに該当する.

一方，ドメイン固有言語 (DSL: domain-specific language)は，特定の問題領域に特化した言語である. HTML, CSS, SQL, JSONなどがこれに当たる. そして，Vueもここに位置づけることができる.

抽象の階層

バイナリとISA

ISA (Instruction Set Architecture)はCPUの命令セットを定義するものである. x86, ARM, RISC-Vなどがこれに該当する.

ff 43 00 d1
ff 0f 00 b9
48 05 80 52
...

レジスタへの書き込み，算術演算，条件分岐，ジャンプ. これらの原始的な命令の組み合わせで，あらゆる計算が表現される. if文もwhileループも関数呼び出しも，最終的にはこれらに帰着する.

アセンブリ

バイナリを人間が読める形式に変換したものがアセンブリである.

my_program:
  sub   sp, sp, #16
  str   wzr, [sp, #12]
  mov   w8, #42
  str   w8, [sp, #8]
  ldr   w8, [sp, #8]
  mov   w10, #2
...

subは減算，movは値の転送，jmpはジャンプ. ニーモニックによって，バイナリ列に意味が与えられた.

しかし，これで十分だろうか.

変数に意味のある名前をつけたい. 条件分岐を構造化したい. 繰り返しを簡潔に記述したい. 関数という単位で処理をまとめたい. アセンブリは計算機にとっては十分でも，人間の認知にとっては依然として負荷が高い.

高級言語への進化

int main() {
  int a = 42;
  if (a % 2 == 0) {
    a = 5;
  }
  a = a + 999;
  return a;
}

C言語(Fortran)の登場により，人間の思考に近い形式でプログラムを記述できるようになった. 変数，条件分岐，ループ，関数といった抽象が導入され，開発者の認知負荷は大幅に軽減された.

しかし，これで終わりではなかった.

メモリ管理の自動化，型システムの強化，オブジェクト指向，関数型プログラミング，並行処理の抽象化... 新たな要求が生まれるたびに，新たな言語が生まれてきた.

言語とは，ある種の「翻訳機」である. 人間の意図をコンピュータが理解できる形式に変換する. そして，その翻訳の過程で，何を簡潔に書けるようにし，何を隠蔽するかが，言語の設計思想を決定づける.

言語設計のモチベーション

言語が生まれる背景には，常に開発者体験(DX)の向上がある.

• 構文の意味づけ: if, while, モジュール, 名前空間など，思考の単位に対応する構文を提供する

• 対象領域の意味づけ: OOPならJavaやC++，システムプログラミングならRustやGo，UI記述ならHTML/CSS

• コンパイラによる最適化: 開発者は意図を記述し，最適化はコンパイラに委ねる

言語とは，特定の問題領域において「何を書きやすくするか」という設計判断の集積である.

Vue.jsは言語である

ここで本題に入る.

Vue.jsとは何か. フレームワーク，ライブラリ，様々な呼び方があるが，ここでは一つの見方を提示したい.

Vue.jsは，Web UIを記述するためのドメイン固有言語である.

UIを宣言的に記述するために必要なものを考えてみる.

• Web標準であるHTML, CSS, JavaScriptとの親和性

• データバインディングによる動的なViewの記述

• コンポーネントを単位とした設計

• スコープ付きスタイル

• スロットによるコンテンツの受け渡し

<script setup lang="ts">
import { ref } from "vue";
const count = ref(0);
function increment() {
  count.value++;
}
</script>

<template>
  <button type="button" @click="increment">count is: {{ count }}</button>
</template>

<style scoped>
button {
  color: red;
}
</style>

このSFC (Single File Component)という形式は，HTML/CSS/JavaScriptの構文を借りながら，UI記述に特化した意味論を与えている.

実用性と言語設計

完全に新しい言語を設計することも可能である. しかし，それは現実的だろうか.

新しい言語を作るということは，エコシステムをゼロから構築することを意味する. エディタサポート，型チェッカー，リンター，フォーマッター，ビルドツール... これらを全て新規に開発する必要がある.

Vue.jsはインクリメンタルなアプローチを取った.

既存の資産を活用する. JavaScript/TypeScriptのエコシステム， による恩恵をある程度そのまま享受する.

メンタルモデルを維持する. script部分はJavaScriptのセマンティクスをそのまま使う. HTMLとCSSの書き心地を損なわない.

これは，新しい言語を「方言」として設計するようなものである. 母語の文法を大きく逸脱せず，しかし特定の表現については独自の語彙と構文を導入する.

コンパイラによる最適化

言語がコンパイラを持つことで，最適化の恩恵を受けることができる.

開発者は意図を記述し，コンパイラが効率的なコードを生成する. この分業により，開発者は本質的な問題に集中でき，低レベルの最適化から解放される.

Vue.jsのコンパイラには以下の最適化が実装されている.

• Static Hoisting: 静的なノードをレンダリング関数の外に巻き上げ，再生成を回避する

• Patch Flags: 動的な部分にフラグを付与し，差分検出を高速化する

• Tree Flattening: ネストした静的ノードをフラット化し，走査コストを削減する

• Vapor Mode: 仮想DOMを介さない，より直接的なレンダリングモード

これらの詳細は 公式ドキュメントに記載されている.

SFC Playgroundで出力コードを眺めてみると，コンパイラがどのような変換を行っているかを観察できる.

課題

言語を設計し維持することには，相応のコストが伴う.

• 言語仕様の設計: 一貫性と表現力のバランス

• コンパイラの実装: 正確性と性能の両立

• 周辺ツールの整備: 言語サーバー，他のエコシステムとの統合

Vue.jsはすでに多くの部分が成熟しているが，探せばまだやるべきことは見つかる. 貢献の機会は常に存在する.

結び

バイナリからアセンブリへ，アセンブリから高級言語へ. プログラミングの歴史は，抽象化の積み重ねの歴史である.

Vue.jsもその系譜に位置づけることができる. Web UIという問題領域に対して，HTML/CSS/JavaScriptを基盤としながら，宣言的UI記述のための意味論を与えた言語.

Vue.jsとは何か.

言語である.

稚拙さ

まずはこちらの発言を見てほしい．

https://x.com/ubugeeei/status/1745815915353325898

実際のところ，長い間本当にこのように考えていました．
なぜなら自分に対する寄付をするよりも，コミュニティに対する行動をして欲しかったからです．
そのために行動を起こそうとしていた人を全力でサポートし，提案し，どうにか協力者を増やそうとしていました．

しかしこれにはいくつかの稚拙な深層心理と，コミュニティへの悪影響があることに気づきました．

責任逃れ

お金を受け取ってしまうと「やらなくてはならない」という責任感が多かれ少なかれ生まれます．
私はこれに限らず余計な圧力というのは徹底的に排除したいタイプでしたが，時にはその強制力を原動力に変換する力も身につけるべきです．
責任から逃げることもそうですが，変化に対する挑戦も怠っていました．
これは稚拙な態度だったと反省しています．

安売り

私は私自身に対していつも悲観的です．
これは良い側面もありますが，自分以外への影響を考えると後述の文化への悪影響にもつながることに気付かされました．
「自分なんかが活動に対する対価を受け取るべきではない」「そんなことよりももっと活動しないと」「とにかく，下手 (したて) に，下手に」「傲慢であってはならない」
そんなふうに考えていました．

文化への悪影響

ここからが本題です．
問題が自分自身に対して閉じているならわざわざブログにするほどでもないのですが，この気づきはコミュニティや文化を発展させる上で関係者が全員把握するべき重要なものだと思ったので書きました．
(ぜひ多くの人に届いてほしい)

簡潔に言うと，上記のような態度は文化を停滞させる方向に加担します．
私の理想の世界では，活動をした者は全員それに見合った対価を受け取るべきですし，またそれを原動力に変換して次の活動につなげるべきです．

昨今，OSSやメンテナの努力に対する報酬の希薄さについてしばしば話題にあがります．
OSSコミュニティはもっと経済が循環するべきだと強く思っています．

それなのに，自分が受け取るのをわざわざ断ったり，スポンサーを開けずに受け口を持たないことはこれに矛盾しています．
自分が活動すればするほど，経済循環のハードルを上げてしまい，文化としては良い状態にならないと思いました．

実際のところ，世界で活躍するコントリビューターの方々に比べると自分の活動はまだまだですし，私1人がスポンサーを開けたり開けなったりしてもそれほどの影響力はありませんが，それであってもまだまだなりに少々の対価を受け取ったり，積極的に募ったりして文化貢献をしていくべきだと思いました．
(小さく，自分の周りからでもそういう文化を育てていきたい)

額の大小はあるにしろ，活動に対する対価をみんなで支払っていくという文化はもっと前進するべきです．
受け取りを拒否すればするほど，受け取りや支払いのハードルは上がりますし，文化としても「まぁ，そういうもんか」という認知が広まってしまいますし，何より「オープンソースは無料で使えるものである」というよくある誤解を助長してしまいます．
これはあってはならないことだと思いました．

おまけ話

私がこのことについて考え直すきっかけを与えてくれたのは @ota-meshiさん(Vue.js Core Team Member)でした．
Vue.jsの海外メンバーが日本に来るというのでオフ会をした時にotaさんと同席し，帰りの電車でこの話をしました．
自分の従来の考えを伝えると，「それは間違っているよ」と言われてしまいました．
考え直すと本当にその通りだと思いました．

また，「それはただの責任逃れなんじゃないか？」「あなたは自分を安売りしすぎじゃないか？」と言ってくれたのも別の知人でした．
それもその通りだと思いました．

私は自分1人で考えているとどうしても自分の事ばかり，しかも悲観的になりすぎでしまう癖が強くあるのですが，自分よりも先をいく先輩の話や，客観的に自分を評価をできる人，自分とは違う行動を取っている人と話すことの重要性を再認識しました．

きっかけをくれた全ての方々に感謝します．

GitHubスポンサーの募集を始めました．ぜひご支援よろしくお願いします！

https://github.com/sponsors/ubugeeei

私を含め，人々はしばしば持続的な安定を求める．
仕事で良いパフォーマンスを維持し，個人的な趣味や関心事で一貫した進歩を遂げたいと思う．

しかし，最近，それが本当に目指すべき理想の状態なのかどうか，よく考えている．
不安定さは常に悪いことなのだろうか？

私自身，調子の良し悪しがあり，良い状態でないときはいつもフラストレーションを感じる．
振り返ってみると，「ああ，あの時もっと良い状態だったら，もっとうまくいっていたのに」と思うことがある．

しかし，それは間違いだ．

悪い状態にあることは，原動力になりうる．
常にフラットな状態でいるよりも，高い速度の瞬間がある方が良い．

不安定性と推進力は表裏一体だ．

私はジャズが好きだ．ジャズには，ドミナントやスウィングといった概念がある．
端的に言えば，ドミナントは不安定な音程を作り出し，スウィングは不安定なリズムを作り出す．

この単調でない不安定さが推進力を生み出し，強いグルーヴを作り出す．
そしてそれがジャズの魅力だ．

その魅力を理解し，受け入れよう．

より一般化されたアクセシビリティの形

定義

アクティビストとは？

ここで定義をまとめておこう．
ここでいう「アクティビスト」とは，活動に積極的に関わっているすべての人を指す．（まあ...これでは何も説明していないが...）

会社で働いている人，何かのコミュニティで活動している人，独立したOSS開発者など...
活動の形は様々だが，すべてに共通していることがある．

情報の形態

情報には様々な形態がある．テキストデータ，音声データ，そしてもちろん，あなたが考えていること．
場合によっては，「あなたが考えていないこと」も情報になりうる．

これらには優先度の違いがあり，状況によって扱い方が異なる．

動的情報と静的情報

情報は動的と静的に分類できる．

動的:

• 会話

• 考えていること

• など...

静的:

• テキストデータ

• 音声データ

• など...

この分類方法はかなり主観的だが，大まかに言えば「改ざんへの備え」と「改ざんの追跡可能性」の違いである．

そして私は，アクティビストの役割の一つは「活動に関連する動的情報を静的情報にコンパイルすること」だと強く信じている．
なぜなら，静的情報には多くの価値があるからだ．

静的情報の価値

アクセシビリティ

まず，アクセシビリティについて考えてみよう．
ここでいうアクセシビリティは，ウェブアクセシビリティの文脈とは異なる．
ウェブコンテンツの範囲を超えた，より一般化された概念である．

アクティビストとして，情報へのアクセスにはいくつかの制約がある:

• 時間的制約

• 処理能力の制約

• 記憶の制約

まず，時間について．動的情報は時間を超えて他者と共有することができない．
誰もが同時に存在し，話しているわけではない．
ミクロな文脈では「会議」が良い例だ．もちろん，スケジュールが合わないために参加できない人もいる．
マクロな文脈では，「世代交代（引き継ぎ）」や「新規参加者のキャッチアップ」が良い例だ．過去の出来事や歴史を知るために，その時の考え方や行われたことが静的にまとめられていることは価値がある．

次に処理能力について．人間の処理能力は人それぞれ異なる．
物事を素早く理解する人もいれば，そうでない人もいる．
同じ場所に同時にいて考えを共有していても，その情報を処理する能力は様々だ．
これを補完する静的情報は非常に価値がある．

最後に記憶について．人間の記憶には限界がある．
忘れることは普通のことであり，どこかで情報が変質することも普通のことだ．
さらに，永続的で改ざんに強い静的情報は，記憶の補完として非常に価値がある．

機械可読性

この言葉もウェブコンテンツの文脈で登場するが，この話にも類似点がある．
動的情報は機械が読み取るのが難しい．

一方，静的情報は機械が読み取りやすい．
あえて最近のホットな話題と混ぜるなら，静的情報はLLMに直接入力できる．

課題

静的情報には様々な価値があり，アクティビストにはその価値を生み出す役割があることを理解した．

しかし，問題は「動的情報を静的情報に変換する能力は人それぞれ異なり，向上させるには訓練が必要である」ということだ． この能力は，いわゆる「要約力」や「他者と効果的にコミュニケーションする能力」とは異なる．

「コンパイラ」は入力と出力の間で意味を変えてはならない． つまり，できるだけ情報を失わずに動的情報を静的情報に変換する必要がある．
その時の思考，感情，雰囲気，流れなど．

これらを過不足なく静的情報に変換するのは難しい．
しかし，この能力は私たちアクティビストにとって必要なものだ．訓練しよう．

続き: React is React, just. Part 2では，同じ流れでMeta，Babel，Flow，React Compilerについて考えている．

序・前提

まず前提として，コンパイラを使った最適化を行うという方針については私はとても賛成である. インターフェースを崩さずにDXを改善するにあたってこのアプローチはしばしば有効的であるし，私自身もそれを全面に押し出すフレームワークを使っている. ただし，コンパイラが介入するにあたってのメンタルモデルの変更(または統一 [^1])についていくつかの疑問がある. 私は普段からReactを書いているわけでもなく専門家でもないので，これから話すことはReactに対する意見というより，「Reactを使っている人は，この点どう感じているのだろうか？」という好奇心からくるもので，その是非に対するものではない. 何度も言うが私は 賛成 している.

また，これらはhttps://react.dev/blogでReact Compilerについての話が出た時に感じたことで，これまでReact Compilerについて行われてきた議論などをしっかり調べたりして根拠を作ったものではない. ただのエッセイだ.

私が持っている疑問に対するアンサーは歓迎しているが，このエッセイを根拠にしたReact CompilerやReact自体の是非については歓迎しない. 技術に対する是非はこの一部を切り取って評価できるものではない. (と思っているので，もしこのエッセイにそう捉えられかねない発言があれば，ぜひ指摘してほしい．(是非について何か広めたいわけではない))

私の立場: 感想・疑問をまとめておく 読み手の立場: 感想・疑問について議論・返答する やらないこと: 技術に対する是非

なぜわざわざここまで保険をかけたかというと，自分が叩かれたくなかった，とかそういう意味ではなく， パラダイムに関する是非は視点によって大きく変わるものであり，それについて話すには議論が足りてなさすぎるからだ. 技術の是非に関して，誤謬が広まってしまうことは本当に良くないことだと思っているので，それは避けられたい.

トピック

まずここからすでに主観の話になるが，Reactは「純粋なJavaScript」であるという主張が多かれ少なかれあるはずだ. ここで，「純粋」とは何かについては多義であると感じているので，注意が必要だと思っている．

純粋とは: (ⅰ) React Componentは冪等なJavaScriptである (ⅱ) React ComponentはJust JavaScriptである

今回，特に私が気になっていたのが，「React Compilerの登場で (ⅱ) を満たせなくなってしまったみたいだが，どう感じているのか？」という点だ. 前提として，React Compiler登場以前はどちらも満たせていたという主張のもとである.

(ⅰ) に関しては，React Compilerはむしろ「コンポーネントは冪等であるべき」というルールの元の最適化実装なのでReact Compiler登場後も当然そう言える．この，(ⅰ) で考えている意味論のことを「React的意味論」と呼ぶようにする.

問題は (ⅱ) だ．React CompilerはReact的意味論は変化させないが，「JS的意味論は変化させている」という主張だ. ここについて，Reactを使っているの人たちがどう感じているのかについて興味がある．というのが今回のトピックだ.

「JS的意味論は変化させている」というのがどういう意味なのかについて.

以下のようなコンポーネントを考えてみよう．

これは実際React Advanced 2023のReact Fogetについての登壇で登場したコードだ．(一部省略)

function VideoTag({ heading, video, filter }) {
  const filteredVideos = [];
  for (const video of videos) {
    if (applyFilter(video, filter)) {
      filteredVideos.push(video);
    }
  }

  if (filteredVideos.length === 0) {
    return <NoVideos />;
  }

  return (
    <>
      <Heading
        heading={heading}
        count={filteredVideos.length}
      />
      <VideoList videos={filterdVideos}>
    </>
  )
}

このようなコードを見た時，Reactユーザーならば不要な計算に気づき，最適化を行うことだろう.

function VideoTag({ heading, video, filter }) {
  const filteredVideos = useMemo(() => {
    const filteredVideos = [];
    for (const video of videos) {
      if (applyFilter(video, filter)) {
        filteredVideos.push(video);
      }
    }
    return filteredVideos;
  }, [videos, filters])


  if (filteredVideos.length === 0) {
    return <NoVideos />;
  }

  return ...;
}

参考: Understanding Idiomatic React – Joe Savona, Mofei Zhang, React Advanced 2023 t=196

しかし，React Compilerの登場によってこれが大きく変わりそうだ. React Compilerは，このコード(useMemoを使っていない方)をコンパイラが解析し，メモ化を行うJavaScriptコード に変換する.

function VideoTab(t36) {
  const $ = useMemoCache(12);
  const { heading, videos, filter } = t36;
  let filteredVideos;

  if ($[0] !== videos || $[1] !== filter) {
    filteredVideos = [];

    for (const video of videos) {
      if (applyFilter(video, filter)) {
        filteredVideos.push(video);
      }
    }
    $[0] = videos;
    $[1] = filter;
    $[2] = filteredVideos;

  } else {
    filteredVideos = $[2];
  }

  if (filteredVideos.length === 0) {
    return <NoVideos />;
  }

  return ...;
}

参考: Understanding Idiomatic React – Joe Savona, Mofei Zhang, React Advanced 2023 (t=497)

これはつまり，「React的意味論におけるJavaScriptコード(出力コード)の最適化」であり，「JavaScriptの意味論」自体は変化している．

JavaScriptの関数というものは，

function Func(n) {
  let list = [];
  for (let i = 0; i < n; i++) {
    list.push(i);
  }
  return list;
}

とかくと，その結果に関わらず必ず実行されるものだ.

だが，React Compiler登場後のReact Componentはそうではない. 見かけ上はJS関数だが，Just JS関数ではなくなってしまった と言えそうだ.

function VideoTag({ heading, video, filter }) {
  const filteredVideos = [];
  for (const video of videos) {
    if (applyFilter(video, filter)) {
      filteredVideos.push(video);
    }
  }

 ...
}

と記述したはずなのに，関数の呼び出し回数と実際に記述した処理の回数は一致しない. このような評価規則はJavaScriptにはないもので，React CompilerがReact的意味論を元に最適化した結果だ.

これで，「React Compilerの登場によって，React ComponentがJust JavaScriptではなくなってしまう」というところが伝わっただろうか.

意味論は2つに増えたが，構文論は1つである.

実際に，ReactでComponentを実装する際に「React的意味論」と「JS的意味論」の２つを併用するべきかという議論はさておき，

function VideoTag({ heading, video, filter }) {
  const filteredVideos = [];
  for (const video of videos) {
    if (applyFilter(video, filter)) {
      filteredVideos.push(video);
    }
  }

 ...
}

この関数を見たときに， 2つの意味論が存在してしまうことは事実だ. (React的意味論と，JS的意味論) あるときは，関数はの呼び出し回数とbodyの実行回数は一致するかもしれないし，あるときはしないかもしれない. これが開発者や学習者にとって負担になるかどうかは分からないが，そういった可能性はゼロではないはずだ.

構文論に関する利点について，注意したいこと

今までは主に，

function VideoTag({ heading, video, filter }) {
  const filteredVideos = [];
  for (const video of videos) {
    if (applyFilter(video, filter)) {
      filteredVideos.push(video);
    }
  }

 ...
}

という関数に対する意味論について取り上げてきたが，構文論についてだ. 構文論については，React Compilerの登場以前/後に限らず紛れもなく「Just JavaScript」だ. (JSXはそもそもJSではないだろという話もあるが，今回の話の本筋ではないので割愛する)

ReactがJust JavaScriptであるという利点の一つとして，静的解析の容易さやツールチェーンとのインテグレーションのしやすがしばしば挙げられる. これらに関しては引き続きそう語って概ね良い範囲だと個人的には思われる. (だからと言って，他のものがダメであるかどうかはまた別の議論) 厳密にはJS的意味論が重要なツールなどでは部分的にそうではなくなる可能性もあるが，感覚的にはそこが重要になってしまうようなものはほとんどない気がしている (完全に主観).

しかし，注意したいのはその切り分けである． React Compiler登場以前，「ReactはJust JavaScriptだから ${任意の評価}」は意味論と構文論のどちらにも適用されることがあった．しかしReact Compilerの登場後はそれは構文論の話になったのではないかと思う.

「ReactはJust JavaScriptだから ${任意の評価}」と言われた時，この区別がないと間違った評価をしてしまうことがありそうだ，という考えが私にはある．これがどの程度問題になるかは定かではいが，新たに生まれた問題提起なのではないかな，と思った．

[^1]: もちろん，中にはもともとReact的意味論のみを考えていた方もいると思う．その方にとっては特に変わりがないが，JS的意味論も視野に入れていた人はReact的意味論のみを考えるように統一されていくものなのかな，と思った (実際どうなのかはわからない)

つまりReact Componentは何であると言えそうか

JavaScriptの意味論を変えてしまっては，「Just JavaScript」とは言えなさそうだ． ではなんなのだろうか？ ・ ・ ・ ・ Reactは，Reactだ. 構文 がJavaScriptと同じで，意味が異なる別の存在だ.

と思ったが皆さんはどうだろうか... 🤔

エッセイ: ReactはJavaScript + Ruleなのか，それとも言語なのか

https://x.com/ubugeeei/status/1758298301609492584?s=20

<details> <summary>ref:</summary>

https://x.com/ubugeeei/status/1758296154406821942?s=20

https://x.com/ubugeeei/status/1758308229602529304?s=20

https://x.com/ubugeeei/status/1758309937300808122?s=20

https://x.com/ubugeeei/status/1758458714749911445?s=20

https://x.com/ubugeeei/status/1758467330278035779?s=20

https://x.com/ubugeeei/status/1758508131385266543?s=20

https://x.com/ubugeeei/status/1758521001091191294?s=20

</details>