1. EISとは何か
EIS (Engineering Impact Signal) は、git log と git blame のデータだけから、エンジニアがコードベースに残した構造のかたちを読むCLIツールです。Gravity はその関係的な読み — 構造のかたちを2つの正直なゲートに通したもので、生き残ったコードだけでも、catalysis だけでも、それを成り立たせることはできない。
shape = 0.45·Design + 0.25·Breadth + 0.30·Indispensability
catGate = 0.15 + 0.85·(Catalysis / 100)
survGate = 0.15 + 0.85·(RobustSurvival / 100)
Gravity = catGate × survGate × shape
重力を「出力の合計」ではなく関係的 なものにしているのは、この2つのゲートだ:
survGate (Robust Survival) — そのコードは他者の圧力の下で 生き残ったか。Robust survival は、あなた以外 の著者が能動的にコミットしているモジュールで生き延びた行だけを数える。誰も触らない隅のコードや、自分で書き換え続けたコードは数に入らない。
catGate (Catalysis) — 他者があなたの生き残った土台の上に積んだか。一人の著者では必ずゼロになる唯一の軸であり、だからこそ構造が誰かに観測可能なかたちで寄りかかっていることの証になる。
GRAVITY
shape — survival と catalysis のゲートを通したかたち
Indispensability
× 0.30
そのコードを書いた人が
他にいない度合い
Breadth
× 0.25
コードベース全体に
どれだけ広くタッチしたか
Design
× 0.45
設計上の基盤となるファイルに
どれだけ深く関わったか
データソース: git log + git blame のみ
言語横断の比較には Gravity Concentration を使う — ある宇宙の全 Gravity のうち、上位3名がどれだけの割合を保持するか。高い値は権力としては読めない。むしろ、構造がごく少数の荷重を担う名前に観測可能なかたちで寄りかかっている、と読める。
2. 言語横断分析 — 物理法則は一様ではない
異なる言語は異なる「物理法則」を生む。型システムの表現力、フレームワーク文化、そしてアーキテクチャの集中度。
29のOSSリポジトリを5つのカテゴリに分類し、構造権威の分布を比較しました。
カテゴリ 特徴 言語 リポ数
Expressive 豊かな型システム、ADT、パターンマッチ、トレイト Rust, Scala 5
Go (Self-structured) 静的型付け、反フレームワーク文化、明示的インターフェース Go 7
Framework-driven 構造をフレームワークに委譲、CoC Ruby, PHP, Java, Python, TS, Elixir 6
Systems (C/C++) 手動メモリ管理、テンプレート C, C++ 5
Dynamic / Structural 動的型付け、自己構造化 JavaScript, TypeScript, Python 6
重力集中度(Gravity Concentration)
カテゴリ別に、ある宇宙の全 Gravity のうち上位3名が占める割合の平均。高い値ほど、構造がごく少数の荷重を担う名前に寄りかかっている、と読める。
Dynamic / Structural
60.3%
Go (Self-structured)
50.1%
2つのゲートで読むと、Framework-driven が最も少ない名前に寄りかかり、Systems (C/C++) が最も多くに分散する。
重力は、コードが他者の圧力の下で生き残りかつ 他者がその上に築いた場所にしか刻まれない。だからカテゴリの集中度は、少数の creator-architect がいまも荷重を担う役を保っているかを読み取る。Framework カテゴリの内部は振れ幅が広い — 場が誰にも傾かない Rails (9.8%) から、構造のほぼ全体が一人二人を通る Spring Boot・FastAPI (97.2%、94.5%) まで。
Systems (C/C++) や Go は多数の長命なメンテナに荷重が散らばり、ごく小さな集団がそれを抱え込むことはない。Dynamic・Expressive・Go は中位で互いに十数ポイント以内に収まり、唯一はっきり離れた信号は最下部の Systems / C++ だ。集中度は、構造がいまも誰に寄りかかっているかを追い、どの言語が先に書かれたかは追わない — 他者が圧をかけなくなれば、最初であったことは何も生まない。
3つの構造権威モード
29の宇宙を通して、生き残った構造がどこに寄りかかることになるか に3つのパターンが繰り返し現れる。モードは言語だけで決まるのではない — 活動のノイズを濾し取ったあとに2つのゲートが読み取るものだ。
Architect-built(Go)
構造は明示的なインターフェースを通して、人が一から組み上げる。複数の長命なメンテナがそれぞれ実在するが非支配的な重力を持ち、荷重が分け合われるため集中度は中位(50.1%)。Terraform、Kubernetes、Prometheus がこう読める。
Type-distributed(言語コンパイラ)
言語コンパイラそのものでは、構造が型に埋め込まれ、荷重が多くの手に散らばる — Rust 27.6%、Scala 37.3%、Scala 3 38.9%。システムが傾く単一の名前はなく、設計史は型機構をかたちづくる全員を通る。
Framework-funneled(Rails ↔ Spring Boot)
構造がフレームワークに吸収されると、カテゴリ内部の振れ幅は最も広くなる — 場が誰にも傾かない Rails (9.8%) から、ほぼ一点に荷重がかかる Spring Boot (97.2%) まで。カテゴリとしては最も少ない名前に寄りかかる(61.9%)。
Framework
3. Rails vs Laravel — 同じカテゴリ、逆の物理
どちらも「Framework-driven」カテゴリ。伝説的な作者を持つ人気フレームワーク。
しかしGravityの物理法則は完全に逆 です。
Rails
マルチアーキテクト文明
Engineers 6,056
Top10 Design(平均) 57.0
リーダーの Gravity 4.0
Gravity Conc. (top-3) 9.8%
Design > 40 9人
Laravel
創造者の王国
Engineers 4,149
Top10 Design(平均) 12.0
リーダーの Gravity 65.1
Gravity Conc. (top-3) 38.0%
Design > 40 2人
Design権威の分布
Rails — 35超が10人、40超が9人
── Design 40 閾値 ──
Laravel — 単独著者の独占
── 他の全Top10コントリビュータ: Design < 7 ──
同じFramework-drivenカテゴリ。逆のガバナンス物理。
Rails はマルチアーキテクト文明 として読める。10人の著者が Design 35超、9人が40超を抱える — 上位10名のうち9名が Design 40超を抱え(最上位は96.8)、しかも誰一人として首位ではない。首位の著者が重力の中心を置いたが、上位の重力スコアは圧縮され(4.0, 3.8, 3.6)、top-3 は全体のわずか9.8%しか保持しない — 29の宇宙すべての中で最も低い。場は特定の誰にも傾かない。
Laravel は創造者の王国 として読める — 2つのゲートが一人のために同時に開く稀な例だ。単独著者が Catalysis 100 と RobustSurvival 78.4 を同時に持つ唯一の著者である:他者が彼の土台の上に積み、彼のコードは他者が触り続けるモジュールで生き延びる。その重力は65.1、次の著者(6.5)のおよそ10倍に着地する。一貫していて、そして一脚の椅子に寄りかかっている。
問いはどちらが優れているかではなく、何がその差を生んだのか — そして Laravel の場の線が、20年かけて Rails が分散したように広がっていくのか、それともこのまま集中したままなのか、だ。
4. esbuild — 一人の宇宙(重力特異点)
124人のコントリビュータが通り過ぎるが、一人が top-3 構造重力の77.0%を保持 する — そして生き残った構造が寄りかかる唯一の著者である。
100
単独著者の Design / Breadth / Indisp
単独著者
Gravity 15.0 | Design 100 | Indisp 100 | RobustSurv 0
123人の他コントリビュータ
全員 Design: 0, Indisp: 0
金色の領域 = 全プロジェクト重力の77.0% (top-3)
esbuild の 77.0% はどこに位置するか
かたちは完璧だ。欠けているのは関係の証拠だ。
単独著者は4,202コミットでバンドラ全体をかたちづくった — Design、Breadth、Indispensability はすべて100 — そして生き残った構造が寄りかかる唯一の著者である。それでも望遠鏡が返す重力は100ではなく15.0だ:一人の宇宙では、彼のモジュールの中で他の誰も決してコミットしないため、robust survival は0と読まれ、survival ゲートは床に張りついたまま、場は内側へ崩れ込む。争われない所有は重力を生まない。77.0%という集中度は権力の判定ではない — 外側の何ものもまだ寄りかかっていない構造の、目に見える痕跡だ。これはこの地図で最も純粋な特異点であり(密度では swc がわずかに上回る)、静かな問いを一つ残す:もし他の誰の手もこのコードを圧の下で担ったことがないのなら、その著者が静かに去ったとき、誰かがそれを受け止めるだろうか。
5. React — 10年の世代交代
1,927人のエンジニアが関わった React は、10年をかけて実際のアーキテクト継承を経てきた。
以下の期間別タイムラインは、各窓をそれぞれ単独で読む。構造の椅子は、3人の著者のあいだを移っていく:Contributor A(仮想DOM期)→ Contributor B(Fiber + Hooks 期)→ Contributor D(Server Components 期)。
構造の椅子の世代交代
2013-2014 — 仮想DOMの時代
Contributor A が初期の構造を担う(仮想DOM期)— 2013年は Architect(重力約15)、2014年に Anchor へ落ち着く(約6)。
仮想DOMに最初のかたちを与えた著者。プロジェクトがその著者を追い越して育つ前の時代。
2017-2022 — Fiber + Hooks の時代
Contributor B がこの年月の支配的な構造の著者だ(Fiber + Hooks 期)— Architect 重力 68 (2018) → 65 (2020) → 77 (2021)。
Contributor C が Cleaner/Anchor として隣の椅子を持つ(2018年にピーク約46)。Reconciler が Fiber として書き直され、Hooks が着地した。構造の荷重は Contributor B に正面から乗り、Contributor C は開発者向けの表層を担った。Contributor C は2024年に去った。
2023 & 2025 — Server Components の時代
Contributor D が椅子に座る(Server Components 期)— Architect 重力 89 (2023)、Anchor 38 (2025) へ落ち着く。
Server Components、新しいレンダリングパイプライン。静的な全履歴の読みでは、Contributor D が React の重力で首位(約9.9、Anchor):他者がその上に築き(Catalysis 100)、コードベースはいまも Contributor D に寄りかかる(Indispensability 100)。それでも重力は控えめなまま — 据えられた Reconciler はいまや大きく揺らされず、そのコードは他者の live な churn の下ではあまり生き残っていない。
いま — 据えられつつある次の椅子
React Compiler が Design に現れる — Contributor E が Design で #1、Contributor F が隣に並ぶ。
これらの著者の関係的な重力はまだ低い:仕事が新しく、まだ誰も圧の下でその上に築いていない。これは据えられつつある次の椅子であって、まだ荷重を担ってはいない、と読める。
React は、本物の継承として読める。
Contributor A(仮想DOM期)→ Contributor B(Fiber + Hooks 期)→ Contributor D(Server Components 期)→ いま据えられつつある次の椅子。
一人が退くと、次の著者が他者の寄りかかる構造を引き継ぐ。静的な全履歴の読みでは Contributor D が約9.9で首位、top-3 が重力の 31.4% を保持する — 一度に一人が荷重を担うが、椅子は3人の著者をきれいに渡り、単一の名前が場を支配することはない。
読みは静かだが一貫している:設計の核心にコードが置かれた貢献者は構造的な重力を刻み、最新の設計仕事は、荷重を担うと読まれるまで、他者がその上に圧をかけるのを待つ。望遠鏡は、誰がどれだけ書いたかではなく、システムがいまどこに寄りかかっているかを読む。
6. EISの妥当性 — 感覚とデータは一致するか
重力は git log と git blame だけから計算される。RFC やデザインドキュメントは見えない。
それでも2つのゲートで読むと、各宇宙の上位に上がってくる名前は、コミュニティが「システムが寄りかかっている人」として挙げるであろう名前と一致する。
64.2%
Tier1 アーキテクトの平均 Recall
41.0%
GitHub との平均 Top-10 重複
355
見つかった Hidden Architect
検証項目 重力の読み コミュニティの直感 一致
Phoenix の中心 首位の著者が重力88.2、両ゲート開通(Architect) コミュニティが中心的設計者と見なす人物と一致 一致
Laravel の創造者 首位の著者が重力65.1、#2 のおよそ10倍 単独の創造者という見方と一致 一致
swc の作者 首位の著者が重力89.2(Architect) 単独コンパイラ作者という見方と一致 一致
Polars のリード 首位の著者が重力65.3(Anchor) プロジェクトのリードという見方と一致 一致
ESLint のメンテナ 首位の著者が重力77.1(Architect) 現行メンテナという見方と一致 一致
Rails の設計分布 Top10 Design 平均57.0、40超が9人 コアチームが厚いという見方と一致 一致
esbuild の単独性 77.0%集中、荷重を担う唯一の著者 単独作という見方と一致 一致
Kubernetes の分散性 Gravity Conc. 27.5%、多数に分散 巨大コミュニティという見方と一致 一致
「感覚的にいい線いっている」を超えて。
重力は完璧ではない。RFC での議論、設計の会話、コードレビューを通した指導 — このダークマターは git blame には観測できないまま残る。
それでも29の宇宙を通して、各プロジェクトの Tier1 アーキテクトの平均 recall は 64.2% 、コミュニティでの立ち位置との順位相関は ρ 0.442 を保つ — そして地図は、どのメンテナリストにも名前のない、しかしシステムがいまもそのコードに寄りかかっている 355人の hidden architect を浮かび上がらせる。
29リポジトリ・51,321人のエンジニアを横断して読むと、システムが寄りかかる構造は言語ファミリーごとに系統的に異なる — そして同じ計器が、毎回それを同じように読む。その一貫性こそ、経験と直感だけでは数に置けなかった部分だ。
7. 結論
システムが寄りかかるものは観測できる — そしてそれは宇宙ごとに異なる
重力は関係的だ。構造が観測可能なかたちで誰かに寄りかかっている場所 — 他者の圧力の下で生き残るコード、他者がその上に積む土台 — にしか刻まれない。生き残ったコードだけでも、catalysis だけでも、それを成り立たせることはできない。両方のゲートが開いたままでなければならない。
そう読むと、集中度は言語ファミリー間で約2.1倍ぶれる — 最も少ない名前に寄りかかる Framework-driven (61.9%) から、最も多くに散らばる Systems C/C++ (30.0%) まで。旧来の加算モデルで最高とされた Go は、いま中位の50.1%に座る。
3つのモードが繰り返し現れる — architect-built (Go)、type-distributed (言語コンパイラ)、framework-funneled (Rails ↔ Spring Boot) — そして同じカテゴリが両極を抱えうる:Rails は誰にも傾かず (9.8%)、Spring Boot はほぼ一人に傾く (97.2%)。esbuild は、誰も他にそのコードの上に立たないために計器が重力と呼ぶことを拒む特異点だ。React は10年をかけた本物の継承として読める — Contributor A → B → D と椅子が渡っていく。
この地図はリーダーボードではない。問いを一つ開いたまま残す:活動のノイズを濾し取ったあと、システムは実際に何に寄りかかっているのか — そしてそれが静かに去ったとき、誰かが気づくだろうか。
全29リポジトリ一覧
Repository カテゴリ 言語 Engineers Top Gravity Grav Conc
spring-boot Framework Java 1,430 50.2 97.2%
prettier Dynamic JS 782 87.1 95.3%
fastapi Framework Python 861 15.0 94.5%
swc Expressive Rust 349 89.2 92.0%
duckdb Systems C++ 618 81.7 83.5%
polars Expressive Rust 665 65.3 78.4%
esbuild Go Go 124 15.0 77.0%
nest Framework TS 638 18.9 68.1%
eslint Dynamic JS 1,153 77.1 66.8%
prometheus Go Go 1,159 35.8 64.4%
phoenix Framework Elixir 1,343 88.2 63.5%
express Dynamic JS 378 8.3 60.3%
vite Dynamic TS 1,204 90.7 59.9%
terraform Go Go 2,121 27.1 56.2%
argo-cd Go Go 1,832 13.7 50.9%
superset Dynamic Python/TS 1,433 20.5 47.7%
grafana Go Go/TS 2,715 28.2 45.1%
scala3 Expressive Scala 3 895 7.2 38.9%
laravel Framework PHP 4,149 65.1 38.0%
scala Expressive Scala 709 9.7 37.3%
ClickHouse Systems C++ 2,189 12.2 33.9%
react Dynamic JS 1,927 9.9 31.4%
loki Go Go 1,272 12.1 29.8%
rust Expressive Rust 7,215 10.5 27.6%
kubernetes Go Go 4,510 16.3 27.5%
arrow Systems C++ 1,369 3.7 14.8%
rails Framework Ruby 6,056 4.0 9.8%
redis Systems C 848 3.8 9.6%
envoy Systems C++ 1,377 4.0 7.9%
名前について
このマップは既定で匿名 だ。役割と構造は観測しても、本人の同意なく個人を名指しでランクづけはしない——EIS の開示ファイアウォールの原則をそのまま適用している。
重力は本人のもの だ。だから——もしあなたが観測された一人なら、GitHub アカウントで EIS の公開研究に協力 できる。あなたの名前で重力を名乗るか、名前だけ出すか、匿名のままでいるか、あるいは完全に外れるかを、観測される側のあなたが選ぶ。既定は匿名のまま。出版物に現れる名前は、すべて参加を望んだ本人のものだ。
OSS重力マップを開いて、重力を名乗る →