AIが1000行を1分で吐く時代に、本当に効くコードはどれか

AIは無限にコードを書ける。残せるかどうかは、別の話だ。

どのリポジトリにも、記録が二つ眠っている。

ひとつはみんなが読む方。コミットログ、PR数、変更行数。要するに活動量、誰がよく動いたか。もうひとつは、ほとんど誰も読まない方。半年後もそのコードが残っているか。git blame が結局誰に当たるか。こちらが構造だ。

マネジメントはたいてい前者を見て、後者に足をすくわれる。「あの人が抜けたら、あのサブシステムは誰も分からない」。その崩壊は、ずっと後者の記録に書いてあった。読んでいなかっただけだ。

なぜ「生き残ったコード」なのか

活動は盛れる。コミットは分割できるし、lockfile で数千行は出る。詰めれば PR 数は増える。忙しさは、いくらでも演出できる。

生き残りはそうはいかない。コードが著者より長く残ったかどうかは、時間が経たないと分からない。一晩では盛れない。タイポ修正もアーキテクチャ変更も「1 PR」だが、半年後に立っているコードは嘘をつけない。

EIS は、その層を読む OSS の CLI だ。git log と git blame だけで7軸と3つのトポロジーを観測し、JSON に吐く。外部APIもAIトークンも要らない。brew install して eis を叩くだけ。式は全部ホワイトペーパーに出してあり、中身は丸見えだ。

AIが、活動量を完全に無意味にした

これが効いてくるのは、ここからだ。

コードを書く速度が、人の手を離れた。AIに頼めば1000行が数分で出てくる。コミット数も変更行数も、もう「その人が動いた量」ではなく「ツールが動いた量」を映している。活動量という指標は前から怪しかった。AIがそれを、完全に無意味にした。

残るのは、生き残ったコードだ。AIが吐いた1000行のうち、来週には書き直される分の survival はゼロ。半年経っても立っているコードだけが、構造として効いている。生成が無限に安くなった世界で、希少なのは出力の量ではなく、残る方だ。

ここに、静かな落とし穴がある。生き残ったコードが実際どれだけあるのかを把握しないまま、構造を気にせず AI に投げっぱなしにしていると、コードベースは「翌週には書き直される層」ばかりで分厚くなっていく。生成は速いのに、機能はいつまでも固まらない。それでいてコミットログは元気に流れているから、同じ場所をぐるぐる回っていることにすら気づかない。生き残りを読めないチームは、その渦の中にいることを、事故になるまで知らずにいる。

しかも生き残りは、AIをもってしても盛れない。時間だけで決まっていないからだ。

あるコードが残るかどうかは、それが置かれた生態系で決まる。次の人が土台にして書き進めるのか、邪魔だと思って書き直すのか。周りの開発者の手が、答えを出す。だから絶対的な物差しではない。現場ごとに変わる。保守的な環境なら、多少いまいちでもバグを産まないコードをそのまま残すかもしれないし、攻めるチームなら同じものを来月には捨てているかもしれない。生き残りは、その現場の中でだけ効く相対的な指標だ。

そして、残るコードは何を解決するために、何を作るか、どういう構造で作るか。これらに熱量を持って向き合った履歴の蓄積として現れる。

ただ、だからこそ盛れない。自己申告でも書いた量でもなく、周りが使い続けたかどうかという、他人の選択の積み重ねだからだ。そして、いくつもの違う現場で残るコードを書ける人は、おそらく本当に設計を考えられる人だ。ひとつの環境の癖にたまたま合っただけ、では説明がつかない。

観測は、生成のちょうど逆でもある。世の中がAI生成であふれるほど、地面に刻まれた事実をそのまま読む道具の価値は上がる。EIS はモデルを使わない。推論しないので、ハルシネーションも起きない。git にもう書いてあることを読むだけ。生成の時代に、観測に徹する。それが立ち位置だ。

ただし、読み方を間違えると壊れる

生き残りシグナルを上から読み、名前の横に数字を置いた瞬間、それは得点表になる。そして得点表は、測ったものを必ず歪める。人は数字を最適化しはじめ、現場の手触りは数字の下に潰れる。エンジニアリング指標が「順位づけと詰め」に化けて死ぬのは、いつもこの瞬間だ。

問いは「git から構造を読めるか」ではない。「読めるとして、評価に堕とさずに読めるか」だ。観測する装置だけでは足りない。どう読むかが、それが助けになるか害になるかを分ける。

これが、EIS と Ace を分けている理由だ。

EIS（望遠鏡）は観測する。 git を読んでシグナルを返すだけ。推薦も予測も評価もしない。事実に徹する。
Ace（天文台）は観測を読む。 ただし順位ではなく、年表に読む。

観測する道具が意味まで決めはじめると、どこからが事実でどこからが意見か分からなくなる。望遠鏡を事実に徹させ、解釈は天文台に引き受けさせる。両方を信じられるのは、そこに境界を引いているからだ。

EIS と Ace の関係 — git history → 望遠鏡 → signals/JSON → 天文台 — 望遠鏡が観測し、天文台が読む。境界は、そこに引いてある。

天文台が読むもの

機能の一覧ではなく、git が隠していた構造の話として読んでほしい。

Structural Summary。数字を、文章に。 「Survival 23」だけでは、設計が弱いのかレガシーを書き換え中なのか分からない。Ace はシグナル全体を読み、いま何が立って何が崩れかけているかを文章で説明する。

Structural Summary — 観測所ダッシュボード（識別子は伏せています） — Structural Summary — 数字を、文章に戻す。

コンウェイの法則チェック。組織図 vs 実態。 人のトポロジーとモジュールのトポロジーを並べ、ズレを見せる。「このサービスはAチーム担当」のはずが、実は書いていない。知識が、組織図の気づかないどこかへ移っていた。

崩壊リスク。事故になる前に。 誰も触らないから残っているだけのモジュール。オーナーが辞めて宙に浮いたモジュール。バスファクター1。リスクは最初から git 履歴の中にあった。Ace は、それが事故になる前に表に出す。

Module Topology — 崩壊リスクとバスファクター（識別子は伏せています） — Conway Check & Collapse Risk — 組織図と実態のずれを並べ、事故になる前に、宙に浮いた知識を見つける。

組織年表（Chronicle）。順位ではなく、時間を。 得点表ではない。エンジニアを順位づけない。代わりに、このコードベースが何をくぐってきたかを記録する。乗り越えたマイグレーション、ある subsystem を作って去ったアーキテクト、オーナーが変わって脆くなったモジュール。

Chronicle — 組織年表（識別子は伏せています） — Chronicle — 順位ではなく、コードベースがくぐってきた時間を読む。

得点表は、人がゲームの仕方を覚える。年表は、チームが愛着を持つ。狙うのは後者だ。シグナルは見ようと思えば見られるが、見出しではなく、近くで確かめるときに手に取るレンズに留めてある。

実例：React に望遠鏡を向ける

抽象論で終わらせたくない。公開 OSS に実際に向けた結果を一つ出す。

ひとつ断っておく。本記事では、観測に現れた個人名を伏せている。名前が出るのは、その人が OrbitLens Ace の公開研究に協力し、自分の名前を claim したときだけ——そういう仕組みにした。既定は匿名、公開は本人が選ぶ。

Star Detail — レーダー + 通期/軌跡（識別子は伏せています） — Star Detail — 通期の重力と、軌跡。切り替えひとつで、同じ人を二つの焦点距離で読む。

React（延べ1,927人が通過）の通期の重力でトップに立つ一人がいる。Indispensability 100、Catalysis 100。構造の形は飽和し、他の全員がその人の上に築いている。

軌跡を開くと、その厚みが見える。彼は 2013 年から繰り返し React の構造的な席に座ってきた。2016 年は Specialist、2022 年は Producer、2023 年には Architect としてその年の一位（gravity 89）、2025 年は Anchor。役を移しながら、十年あいだ構造の中心近くに居続けた人だ。いくつものモジュールのアンカーでもある。彼が敷いた Reconciler は、今も React の土台として息づいている。

それでも現在の Gravity は 9.9 と控えめに出る。Gravity は robust survival——他者が今も現役で圧をかけている生存——で測るからだ。完成して静まった土台に、いま他人が現役で圧をかけてはいない（robust survival ≒0）。だから「今まさに揺れている重力」を測る Gravity では、静かに映る。これは降格ではない。望遠鏡が、出来上がった土台を「現役の重力」と取り違えないだけだ。彼の十年は、軌跡の方にちゃんと残っている。

もう一つの正直な読み方もある。通期を「今まさに揺れている重力」ではなく「生涯に残した構造」として測るなら――生存のゲートを robust survival から素の survival に替えた lifetime gravity――同じその人は通期トップ近く（約74）へ戻る。今まさに圧がかかっているか、と、何が残ったか。別々の問いに別々の答えがあるだけだ。EIS にはこの第二の重力を versioned で加えてある。

重力には、現役の数字だけでは拾いきれない形がある。次の世代が、その上に立って作り直していく土台だ。もう一人の仕事が、まさにそれだ。Hooks、Concurrent Features、Suspense――React の中核を手がけてきた。その多くは後の世代に建て増しされ、EIS は生き残った構造を読むので、上に積み上げられた土台は静かに映る。だが、その静けさこそが意味だ。書き直されることは、失敗ではない。 次の世代がその上に立つ、土台になったということだ。

そして軌跡は、それを忘れない。誰がどの時代にアーキテクトの席を担ったかを、記録し続ける。行は上書きされても、あなたが構造を担ったという記録は上書きされない。すべてのアーキテクトはいつか書き直される。そのとき年表は、あなたが席に座っていたことを覚えている。

そして Ace では、この二つは選ぶものではない。同じ人を、切り替えひとつで両方読める――通期に残したフットプリント（その人が残した構造）と、軌跡（どの時代に担ったか）。そのもう一人なら、上に積み上げられた土台と、アーキテクトの席を担い続けた各シーズンが、同時にそこにある。望遠鏡を引いて全体を、寄って一時代を――同じ宇宙を、二つの焦点距離で読む。

リーダーボードなら、有名で先行した人が永久に一位に居座る。EIS はそうしない。だが軌跡を開けば、誰がどの時代に構造を支えたかは消えずに見える。同じ React で、通期トップ10の顔ぶれは GitHub の maintainer 一覧と6割しか重ならない。残りは、肩書きを持たないまま、システムが今も寄りかかっている人たちだ。

入口は二つ、宇宙はひとつ

望遠鏡（OSS）は、完全に無料で使える。 ローカルで完結する設計で、アカウントもログインも連携もいらない。brew install して、リポに向けるだけ。

brew install machuz/tap/eis
cd your-repo
eis analyze .

天文台（SaaS）は、数クリックで始まる。 ace.orbitlens.io を開き、GitHub でログインし、観たいリポジトリを選ぶ。あとは Ace が観測を回し続け、構造的サマリーもコンウェイ検証も崩壊リスクも年表も、ブラウザの中で読めるように可視化する。CLI を覚える必要はない。

OSS CLI と Ace UI — 二つの入口 — 入口は二つ。同じ宇宙を、コマンドラインからも、ブラウザからも。

自分の組織に、個人のリポジトリに、気になっている OSS に、レンズを当ててみてほしい。公開リポは無制限なので、有名な OSS の重力地図を覗くだけでも、何か見えてくる。

EIS（望遠鏡）はずっと無料の OSS だ。席制限もトライアル期限も、肝心なところだけ有料のオープンコアもない。アイデアに課金したいのではなく、広がってほしい。壁の向こうに置けば、遠くまでは行かない。

値段がつくのは Ace の方だ。観測を回し続けて読み返すのは、れっきとしたインフラだからだ。それでも壁ではなく、手の届く値段にしてある。

Free $0。〜5人、公開リポ無制限、履歴6ヶ月。
Pro $7/月。個人、全期間、フルの Gravity Certificate。
Nova $39/月（8席込）＋ $18/席。組織レベルの読みが要る非公開チーム向け。

この種の分析 SaaS が「開発者ひとり月 $15〜50、しかも contact sales の向こう」が相場なのに対し、Ace は8席までフラットで、その下のエンジンは無料だ。持ち運べる Gravity Certificate は、どのプランでも作成も検証もずっと無料。自分の仕事を証明するのに、金はかからない。

料金プラン — Free / Pro / Starter / Nova — Free から Nova まで。下のエンジンは無料、読み返す天文台だけに値がつく。

最後に、正直なところ

エンジニアリングを上から測った瞬間、現場の肌感覚は平らに潰れがちだ。数字が来ると、その人が実際にやったことの手触りが、その下に隠れてしまう。

その逆を作りたい。だが、できているとは言い切れない。シグナルはシグナルであって、判定ではない。git に映らないものは測らないし、測れないとはっきり言う。メンタリング。コミットにならなかった設計の議論。障害のとき、誰かが保っていた落ち着き。これが望遠鏡の届かない dark matter だ。低いシグナルは「貢献が小さい」のではなく、組織についてのシグナルであることが多い。

人を測るのは、善意でも危うい。現場の感覚を一度も貶さずに測る方法を、まだ見つけられていない。だからこれは、本当の頼みだ。自分のを、チームのを見て、「なんか違う」「平らにされた」「大事だったやつが抜けている」と感じたら、教えてほしい。そのズレている所こそ、次に直す場所だ。

なぜ観測するのか

ここまでを端から読むと、一本の糸が通っている。人は辞める。組織は組み変わる。ツールは1000行の値段を変える。それでも最後まで残らなければならないのは、ここにいた人が分かっていたことだ。そしてその大半は、誰の頭の中にも残らない。コードの中に残る――誰かがまだ、コードの覚えていることを読めるあいだだけ。

観測は、そのためにある。いる人を採点するためではなく、その人が去ったあとも、分かっていたことを読める状態に保つためだ。次の人が、謎ではなく構造を受け継げるように。守るのは人ではない。人は去っていくし、去っていい。守るのは知識だ。順位づける指標は、対象が抜けた瞬間に忘れられる。記録する年表は、次のオーナーが最初に読むものになる。

だからこの製品の魂は、計測ではない。継承のための観測だ。観測の文化とは、継承の文化のことだ。

そしてこの記録は、組織のものだけではない。git に残ったあなたの仕事は、自己申告でも書いた量でもなく、周りがあなたのコードを使い続けたという事実だ。いつか離れた会社が Ace で観測すれば、あなたがそこにいた時期の観測結果が、あなた自身の証明書に積み上がっていく——盛った職務経歴書ではなく、事実からなるキャリア年表として。公開するかどうかは、いつでも本人が決める。

→ ここから先の弧――観測し、理解し、継承し、次の軌道を設計する――は OrbitLens のビジョンに。

GitHub: eis — 望遠鏡。完全にオープンソース。
天文台: ace.orbitlens.io
Library: library.orbitlens.io — EIS の理論と書架（Git考古学・ホワイトペーパー）。