Claude Codeメタ生態系の爆発 — エージェントの真のmoatはモデルではなく「運用知識の層」だ

「五つのレポジトリが同じ週にGitHub Trendingを占拠した。すべてClaude Codeを「より上手く使う方法」に関するものだった。この現象にはまだ名前がない。」

2026年4月10日の週、GitHub Trendingページに異例の光景が広がった。日次と週次のランキングを合算したとき、上位を占めていた五つのレポジトリが一つの共通点を持っていた。すべてClaude Code — または類似のcoding agent — を「より上手く使うため」のツールだったのである。

obra/superpowersは143,712スターに1日あたり+2,299を記録した。「An agentic skills framework & software development methodology that works」という説明が付いたShellプロジェクトだ。forrestchang/andrej-karpathy-skillsは10,441スター、日次+1,364、週次+2,230。このレポの中核となる成果物はCLAUDE.mdファイル一つである。luongnv89/claude-howtoは24,002スターに週次+7,342。コピー&ペーストできるテンプレートとガイドの集合だ。YishenTu/claudianは6,815スター、日次+200。Obsidian vault内にClaude Codeを埋め込むプラグインだ。そしてYeachan-Heo/oh-my-codexは19,938スターに週次+9,737 — 今週GitHub全体で二番目に速く成長したレポである。これはClaude CodeではなくOpenAIのCodexを対象としたツールだが、パターンは同一だ。

五つのレポの累積スター合計は204,908個。今週だけで追加されたスター数を控えめに合算しても2万を超える。開発者ツールカテゴリーでこの規模の同時トレンドは前例がない。VS Code拡張機能エコシステムの全盛期にも、一週間で「VS Codeをより上手く使うためのツール」が五つ同時にトレンドに上がったことはなかった。プロンプトエンジニアリングのブームが起きた2023~2024年にも、「ChatGPTをより上手く使う方法」のレポが五つずつ同時に上がってきたことはなかった。

何が起きているのか。

本稿は2026年4月10日の週のこの現象を解剖する。各レポを個別に分析し、この現象が開発者ツールの歴史のどこに位置するかを見て、前回の記事で扱った「複製不可能な堀」の議論を一層拡張する。前回の記事の中心的主張は、個人の文脈の蓄積がmoatであるということだった。今回の記事の主張は異なる — 個人の文脈を超え、集団の運用知識(operational knowledge)がモデルの上に新しい層(layer)を形成しつつあり、この層そのものが新しい種類の堀となる。

1. 五つのレポ — 個別の解剖

五つのレポは同じ現象の五つの表現である。だが各々の性格は明確に異なる。一つずつ見ていこう。

obra/superpowers — 方法論のプロダクト化

superpowersは今週の現象のフラッグシップだ。143,712スター。この数字だけで既に大半のプログラミング言語フレームワークを上回る。「An agentic skills framework & software development methodology that works」という説明の中で核心となる単語は二つ。skills frameworkとmethodologyだ。

superpowersがやっていることはClaude Codeに「スキル(skills)」を注入することだ。ブレインストーミング、プラン作成、コードレビュー、デバッグ、Git worktree管理など、ソフトウェア開発の各段階に対応するskillsを定義し、エージェントが状況に応じて適切なskillを呼び出せるように構造化する。これはプロンプトではない。プロンプトは「こうしてくれ」という一回限りの指示だ。skillは「こうした状況では常にこう振る舞え」という構造化された運用指針である。

さらに重要なのはmethodologyという単語だ。superpowersは単なるツールではなく、ソフトウェア開発方法論をプロダクトにしたものだ。「brainstormingの段階を必ず経ること」「planを先に書いてsubagentで実行すること」「完了を主張する前に必ずverificationを回すこと」 — このような規律は人間の開発者が長い経験を通じて体得するものである。superpowersはこの規律をエージェントに植え付ける。シニア開発者の暗黙知がShellスクリプトとMarkdownファイルで結晶化されたのだ。

143,712スターが意味するのは、この方法論への需要が巨大だということだ。Claude Code自体は強力だが、「Claude Codeをどう使うべきか」への答えは公式ドキュメントに十分には盛り込まれていない。superpowersがその空白を埋める。

forrestchang/andrej-karpathy-skills — ファイル一つがプロダクトになる

andrej-karpathy-skillsは今週で最も純粋な形の事例だ。このレポの中核成果物はCLAUDE.mdファイル一つである。Andrej KarpathyがLLMコーディングの落とし穴について観察した内容を整理したものだ。10,441スター、日次+1,364、週次+2,230。

ここで立ち止まってこの数字を噛みしめる必要がある。GitHubで10,000スター以上のレポは全体の上位0.01%に該当する。このレポの中身はMarkdownファイル一つ。コードではない。バイナリではない。インストールするもの、ビルドするもの、実行するものは何もない。テキストファイルをコピーして自分のプロジェクトのルートディレクトリに置けば終わりだ。それでも10,000人以上がスターを付け、1日に1,364人が追加で付けた。

これが意味するところは明確だ。CLAUDE.mdというファイル形式そのものがプロダクトカテゴリーになった。 かつては.vimrcや.emacsの設定ファイルをdotfilesレポで共有する文化があった。だがdotfilesレポが10,000スターを獲得するのはmathiasbynens/dotfiles(30k)のような極少数の伝説的レポに限られ、それですら数年かけて蓄積された数字である。andrej-karpathy-skillsは一週間で2,230スターを追加した。dotfiles文化の速度と比較にならない爆発力だ。

なぜこのファイルがこれほど価値を持つのか。CLAUDE.mdはClaude Codeがプロジェクトに入る際に最初に読むファイルだ。ここに書かれた指針がエージェントの全体行動を規定する。よく書かれたCLAUDE.mdと空のCLAUDE.mdの差は、プロジェクトにシニア開発者が隣に座っているかいないかの差に近い。Karpathyの観察 — LLMがコードを書く際に陥りがちな落とし穴 — をCLAUDE.mdに埋め込めば、エージェントがその落とし穴を予め回避する。一人の経験がファイル一つに結晶化され、そのファイルが数千人のエージェント行動を矯正する。知識のレバレッジが極大化される形である。

luongnv89/claude-howto — テンプレートの産業化

claude-howtoは24,002スターに週次+7,342。「Visual, example-driven guide to Claude Code with copy-paste templates」という説明がこのレポの性格を正確に要約する。これはドキュメンテーション(documentation)であると同時にプロダクトでもある。

伝統的にソフトウェアドキュメンテーションはプロダクトに付随するものだった。プロダクトが先にあり、ドキュメントが後を追う。claude-howtoはこの関係を逆転させる。ここではドキュメント自体がプロダクトだ。Claude Codeという原典プロダクトはAnthropicが作ったが、「Claude Codeを効果的に使用する方法」という知識プロダクトはコミュニティが作っている。24,002スターはこの知識プロダクトに対する市場需要の大きさを示している。

週次+7,342は特に注目に値する。これは今週GitHub全体で上位10位に入る成長速度だ。企業が作ったオープンソースフレームワーク、新しいプログラミング言語、革新的なライブラリ — こうしたものと肩を並べるのが「コピー&ペーストするガイド」であるという事実。これは現在の開発者エコシステムが何に渇望しているかを直截に物語っている。もっと良いモデルではなく、今あるモデルをもっと上手く使う方法だ。

YishenTu/claudian — エージェントの表面拡張

claudianは6,815スター、日次+200。他の四つのレポと性格が異なる。これは知識や方法論ではなく、Claude Codeの物理的表面(surface area)を拡張するツールだ。Obsidian vault内にClaude Codeを挿入するプラグイン。

Obsidianはローカルのマークダウンベースのナレッジ管理ツールである。開発者やリサーチャーの間で厚く使われている。claudianがやっていることは、Obsidianで書いているノートに直接Claude CodeをAIコラボレーターとして付着させることだ。エージェントがコードエディタにだけ住むのではなく、ユーザーの思考空間(thinking space)に入ってくるのである。

これが重要なのはエージェントの「ハビタット(habitat)」拡張だからだ。Claude Codeはターミナルから始まりエディタへ拡張され、いまやナレッジ管理ツールへ進出している。エージェントがコードを書くときだけアクティブになるのではなく、ユーザーが考えを整理する時点から隣にいるようになる。前回の記事で扱った「深い統合が作る堀」の正確な実例がここにある。エージェントがターミナルにだけいるときの交換コストと、エージェントがエディタ+ターミナル+ナレッジ管理ツールを貫通するときの交換コストは、次元が異なる。

Yeachan-Heo/oh-my-codex — パターンの転移

oh-my-codexは今週で最も重要なデータポイントかもしれない。19,938スター、週次+9,737 — GitHub全体で二番目に速い成長。ところがこのレポはClaude Codeのためではない。OpenAIのCodexのためのものだ。「OmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs.」

名前からして示唆的だ。「Oh My」という接頭辞はoh-my-zshから来た。oh-my-zshはZshシェルをより上手く使うためのコミュニティフレームワークで、プラグイン、テーマ、設定を体系化する。180,000+スターのレジェンドプロジェクトだ。oh-my-codexがこの名前を意図的に借りたのは、自身が「Codexの上のユーザー知識層」だというアイデンティティを宣言したことになる。

韓国人開発者Yeachan-Heoがメンテナーであることも記録しておくに値する。hooks、agent teams、HUD(Heads-Up Display) — この三つのキーワードはcoding agentを運用可能なシステムにするためのツールセットだ。hooksはエージェントの行動に事前/事後トリガーを掛けるもの、agent teamsは複数のエージェントを協調させるもの、HUDはエージェントの状態をリアルタイムでモニタリングするインターフェイスである。

oh-my-codexが今週の現象で核心である理由は一つ。同じパターンが別のモデルに転移した。 Claude Codeで観察された「メタツール生態系」現象がClaude Codeに限定されないことを証明する。Codexユーザーも同じ渇望を感じており、同じ構造の解法を生み出している。これは特定プロダクトの現象ではなく、カテゴリーレベルの現象だ。coding agentというツールカテゴリー全体で「運用知識の層」が形成されている証拠である。

2. CLAUDE.mdというファイル形式がプロダクトになった瞬間

五つのレポを貫く最も驚くべき事実は、これらのうち相当数の中核成果物がコードではなくテキストだということである。andrej-karpathy-skillsはMarkdownファイル一つだ。superpowersのskillsも本質的には構造化された指針テキストだ。claude-howtoはコピー&ペーストするテンプレートだ。実行可能なバイナリではなく、読める文書がプロダクトの核心である。

これを理解するにはCLAUDE.mdというファイル形式の本質を押さえる必要がある。

設定ファイルの進化史

ソフトウェアの歴史で「ツールの振る舞いをユーザーが定義するファイル」は常に存在した。Unixの.profile、Emacsの.emacs、Vimの.vimrc、Zshの.zshrc。これらのファイルはいくつかの共通点を持つ。第一に、ツールの基本動作をユーザーの好みに合わせて修正する。第二に、ユーザー間で共有可能だ(dotfiles文化)。第三に、時が経つにつれてますます精緻になる — ユーザーが経験を蓄積しながら設定を磨いていく。

だが.emacsや.vimrcは機械語に近い文法で書かれる。Emacs LispやVimscriptを読むには該当ツールの設定言語を別途学ばなければならない。参入障壁がある。dotfilesレポを共有しても、その内容を理解して自分の環境に合わせて修正するには相当の知識が必要だ。

CLAUDE.mdはこの伝統で決定的に一段階飛躍した形だ。機械語ではなく自然言語で書かれる。「コミットメッセージは英語で書くこと」「テストを先に書いて実装すること」「抽象的な記述を避けて具体的な数字を使うこと」 — これは設定ではなく指針だ。プログラミング言語を知らない人も読めるし、修正できる。参入障壁が事実上消失した。

この参入障壁の消失がandrej-karpathy-skillsの爆発的成長を説明する。.emacsファイルをGitHubにアップして10,000スターを獲得するには、そのファイルが極めて精緻でEmacsユーザー全体に汎用的に有用でなければならない。CLAUDE.mdファイルは違う。誰でも読めて、コピーできて、自分のプロジェクトにすぐ適用できる。消費の摩擦がほぼ0だ。だから同じ時間でずっと多くの人に到達する。

自然言語設定の爆発的レバレッジ

CLAUDE.mdの二つ目の特性は、このファイルが単にツールを設定するのではなく、エージェントの「人格」を形成することだ。.vimrcはキーバインディングを変え、文法ハイライトを設定し、タブの大きさを定義する。機械的振る舞いのパラメータを調整する。CLAUDE.mdは判断の基準を設定する。「コードが長くなるときは関数に分けること」「ユーザーが質問したらすぐに実装せずまず設計を確認すること」 — これはパラメータではなく価値観だ。エージェントの意思決定体系を形成するのである。

前回の記事で扱ったharness概念で解釈すると、CLAUDE.mdはharnessの最も外側の層だ。Raschkaが定義した六つのharness要素 — Live Repo Context、Prompt Shape、Tool Access、Context Bloat最小化、Session Memory、Bounded Subagents — は主にソフトウェア層で動作する。CLAUDE.mdはそのソフトウェア層の上に置かれる人間知識の結晶体だ。harnessがエージェントの「どのように(how)」を構造化するなら、CLAUDE.mdはエージェントの「何を(what)」と「なぜ(why)」を規定する。

andrej-karpathy-skillsが10,000スターを獲得したのは、この「何を」と「なぜ」への回答が極めて不足しているという意味だ。AnthropicはClaude Codeという強力なエンジンとharnessを作ったが、その上で「このエンジンをどう運転するのが最善か」についての運用知識はコミュニティが自ら作っている。モデルを作った会社ではなく、モデルを毎日使うユーザーが知識の供給者になったのだ。

ファイル一つの経済学

もう一つの視点を加えよう。andrej-karpathy-skillsレポの核心はCLAUDE.mdファイル一つだ。このファイルの大きさは数キロバイトに過ぎないだろう。だがこのファイルが生み出す経済的価値を考えてみよう。

このファイルを適用したClaude Codeセッションで、エージェントがありがちなミスを一回少なく犯すと仮定しよう。そのミスをデバッグするのに30分かかっていたはずだ。10,000人の開発者がこのファイルを適用し、それぞれが週に一度その恩恵を受けるなら、週に5,000時間の開発者の時間が節約される。時給50で換算すれば週50で換算すれば週250,000。年換算すれば$13,000,000。Markdownファイル一つで。

この計算は誇張かもしれない。実際の効果はこれより小さいだろう。だが方向性は合っている。運用知識の結晶化と共有が生み出す価値は、コードライブラリの価値と同じ構造を持つ。一人の経験がファイルに収まり、そのファイルがn人に複製されると、価値はn倍になる。伝統的なライブラリが「コードの再利用」を可能にしたのなら、CLAUDE.md生態系は「運用知識の再利用」を可能にする。

3. 歴史的アナロジー:oh-my-zsh、.emacs、.vimrc — ツールの上のユーザー知識層

この現象は前例のないものか。違う。類似の構造は過去にもあった。だが規模と速度が変わった。

oh-my-zsh — 最も正確なアナロジー

oh-my-zshは2009年に始まったプロジェクトだ。Zshシェルにプラグイン、テーマ、設定を体系的に管理するフレームワークをかぶせたものだ。現在180,000+スターで、GitHub全体で最も多くのスターを獲得したプロジェクトの一つだ。

oh-my-zshがZshにやったことが、まさにsuperpowersがClaude Codeにやっていることだ。シェル自体は強力だが、ほとんどのユーザーはその強力さの10%も活用できない。どんなオプションがあるか知らず、どんなプラグインが有用か知らず、どんな設定がワークフローを変えるか知らない。oh-my-zshはコミュニティの集団知識を体系化し、初心者ユーザーも高度な機能を直ちに活用できるようにした。

構造を比較してみよう。

Zsh + oh-my-zshClaude Code + superpowers
基盤ツールZshシェルClaude Code
知識層oh-my-zshプラグイン/テーマ/設定superpowers skills/methodology
設定ファイル.zshrcCLAUDE.md
核心価値シェルをより上手く使う方法の結晶化エージェントをより上手く使う方法の結晶化
共有メカニズムGitHub dotfilesレポGitHub skillsレポ
ユーザーカスタマイズプラグインon/off、テーマ選択skillsの追加/削除、指針修正

アナロジーは構造的にほぼ完璧だ。ただし二つの決定的な違いがある。

第一に、速度。oh-my-zshが180,000スターに到達するのに17年かかった。superpowersは既に143,712スターであり、1日に2,299個ずつ増えている。この速度ならoh-my-zshを数年内に追い越せる。oh-my-zsh時代にはGitHub自体のユーザー数が今より遥かに少なかったという補正ファクターはあるが、それでも速度の差は明白だ。

第二に、レバレッジの大きさ。.zshrc設定が変えるのはシェルの視覚的表現(プロンプトの形)、オートコンプリート動作、履歴管理のようなものだ。有用だが、シェルが処理する作業そのものを根本的には変えない。lsを実行すればlsが実行される。一方CLAUDE.mdが変えるのはエージェントの意思決定体系だ。同じ「このコードをリファクタリングしてくれ」というリクエストも、CLAUDE.mdに何が書かれているかによって完全に異なる結果が出る。設定の影響範囲が次元違いだ。

Emacsの.emacs — Lisp魔法使いの塔

Emacsは「拡張可能なテキストエディタ」という哲学を極限まで推し進めたツールだ。.emacsファイル(またはinit.el)にEmacs Lispでほぼ無限のカスタマイズが可能だ。エディタをメールクライアントに、ウェブブラウザに、ファイル管理ツールに、果ては OS にすらできる。「Emacs is not a text editor, it’s a Lisp interpreter that happens to edit text」という格言があるほどだ。

Emacs生態系で.emacsファイルはユーザーのアイデンティティだった。数年にわたって磨かれた.emacsはそのユーザーの作業方式、思考方式、果ては美的感覚までを盛り込んでいた。「君の.emacsを見せてくれ、君がどんな開発者か教えよう」という半ば冗談が通用するほどだった。

ところが.emacsの問題は参入障壁だった。Emacs Lispを知らないと他人の設定を理解できなかった。設定をコピーして来ても、なぜこの設定がこうなっているのか把握できなければ衝突が起きるか望まぬ動作が発生した。設定の共有が事実上、同じ水準のEmacs Lisp能力を前提していた。

CLAUDE.mdはこの問題を自然言語で解決した。「抽象的な記述を避けて具体的な数字を使うこと」という指針は、プログラミング言語を知らない人も読める。参入障壁が取り払われた.emacsがCLAUDE.mdだ。そして参入障壁が取り払われると共有の速度が爆発する。andrej-karpathy-skillsが一週間で2,230スターを獲得したのは、この爆発の断面である。

Vimの.vimrc — 効率の宗教

Vimユーザーたちは.vimrcを宗教的献身で磨き上げてきた。キーバインディング一つ、マッピング一つが秒単位の効率差を生み、その差が一日に数千回繰り返されれば有意義な生産性の格差になった。「私はhjklではなくjkl;を使う」という宣言が政治的立場のように論争を呼んだ。

.vimrc文化で注目すべきは、最適な設定がユーザーの文脈に深く依存するという点だ。Python開発者の.vimrcとC++開発者の.vimrcは全く異なる。ターミナルで作業する人とGUIを好む人の設定も異なる。汎用的に「最高」の.vimrcは存在しなかった。

CLAUDE.md生態系でも同じ分化が始まっている。andrej-karpathy-skillsは汎用的指針だが、実務ではプロジェクトの性格に応じてCLAUDE.mdが異なるべきだ。フロントエンドプロジェクトとシステムプログラミングプロジェクトの最適指針は異なる。チームの規模、コーディング規約、テスト戦略に応じて指針が分かれる。.vimrcの分化と同じプロセスがCLAUDE.mdで加速している。

三世代の共通構造と決定的な違い

.emacs → .vimrc → .zshrc → CLAUDE.md。この進化ラインで一貫しているのは、ユーザーがツールの振る舞いを定義するファイルが常に存在したという事実だ。ツールが強力なほどこのファイルの重要性は大きくなり、このファイルを共有する文化が形成された。

CLAUDE.md世代が以前の世代と決定的に違う点は三つある。

第一に、自然言語。以前の世代の設定ファイルは専用文法やプログラミング言語を要求した。CLAUDE.mdは日常言語で書かれる。共有の摩擦が消失した。

第二に、影響範囲。以前の世代の設定はツールの外観や機械的動作を変更した。CLAUDE.mdはエージェントの判断体系を変更する。同じリクエストに対して完全に異なる成果物が出る。設定の重要度が次元違いだ。

第三に、経済的価値。.vimrcが間違っていても最悪の場合キーバインディングが絡まるだけだ。CLAUDE.mdが間違っているとエージェントがコードベースに構造的問題を埋め込みうる。逆にCLAUDE.mdが上手く書かれていればエージェントの生産性が体感水準で上がる。このファイルの品質と経済的結果の相関が過去のどんな設定ファイルより強い。

この三つの違いが合わさってCLAUDE.md生態系の爆発的成長を作り出している。誰でも書けて、効果が大きく、共有しやすい。バイラル拡散の三つの条件が同時に満たされたのだ。

4. oh-my-codexの意味 — 同じパターンが別のモデルに転移した

oh-my-codexについてさらに深く掘り下げる必要がある。このレポが今週の現象の鍵だからである。

表面的な事実

oh-my-codexはOpenAIのCodex CLIのためのツールだ。hooks、agent teams、HUDを追加する。19,938スターに週次+9,737。今週GitHubで二番目に速く成長したレポ。メンテナーは韓国人開発者Yeachan-Heo。

このレポがなぜ重要なのか — カテゴリーの証拠

もしsuperpowers、andrej-karpathy-skills、claude-howto、claudianだけがトレンドに上がっていたら、この現象を「Claude Code特殊現象」と解釈できただろう。Anthropicが特別に上手く作ったプロダクトにユーザーが熱狂しているという話。プロダクトレベルの話で終わりえた。

oh-my-codexがこの解釈を不可能にする。同じパターンがOpenAIのCodexでも発生している。CodexとClaude Codeは競合プロダクトだ。作った会社も、基盤モデルも、アーキテクチャも違う。ところがユーザーが同じ構造の解法を作り出している。

これは特定プロダクトの現象ではなくカテゴリー(category)レベルの現象だ。coding agentというツールカテゴリー自体が「運用知識の層」を必要としており、ユーザーコミュニティがその層を独立に形成している。

oh-my-zshアナロジーの精度

oh-my-codexの名前は偶然ではない。oh-my-zshの構造を意図的に借りたものだ。oh-my-zshがZshの上にコミュニティ知識層を載せたように、oh-my-codexはCodexの上にコミュニティ知識層を載せる。

oh-my-zshはなぜ成功したのか。Zsh自体は強力だったが、ほとんどのユーザーはデフォルト設定から抜け出せなかった。数百の有用な機能がドキュメントに埋もれていた。oh-my-zshがやったのはその埋もれた機能を発掘し、体系化し、プラグインとしてパッケージングし、初心者でも一行のインストールコマンドで直ちに活用できるようにすることだった。ツール製作者が作らなかった(あるいは作れなかった)「使い方の体系」をコミュニティが作ったのだ。

coding agent生態系で正確に同じ力学が働いている。Claude Codeも、Codexも、公式ドキュメントには基本的な使い方しか盛り込まれていない。「このツールをどう使えば生産性が極大化されるか」への答えは — どこからも公式に提供されない。superpowersがClaude Codeについて、oh-my-codexがCodexについて、その空白を埋めている。

hooksの意味 — エージェント・ガバナンスの始まり

oh-my-codexの三つの中核機能のうちhooksに注目しよう。hooksはエージェントが特定の行動を実行する前または後にユーザー定義のロジックを実行するメカニズムだ。例えば、エージェントがファイルを削除しようとする際に事前確認を要求したり、コミットを作る前にlintを強制実行したり、特定ディレクトリへの書き込みを遮断したりする。

これは事実上、エージェントに対するガバナンス(governance)だ。エージェントが何をできて何をできないかをユーザーが細かく制御することだ。前回の記事で扱ったcoding agentのharness概念 — Tool AccessとValidation — のユーザー側拡張だ。Anthropicが作ったharnessが基本的なセーフティネットを提供するなら、oh-my-codexのhooksはユーザーが自分の環境に合わせた追加ガバナンスを設置することだ。

このガバナンス層の出現はcoding agentが「ツール」から「システム」に転換しつつあることを示している。ツールはユーザーが直接操作する。システムは自律的に行動するが、ポリシーによって制限される。hooksはそのポリシーをユーザーが定義するメカニズムである。

agent teamsとHUD — 単一エージェントからエージェントシステムへ

oh-my-codexのagent teams機能は、単一エージェントではなく複数エージェントを協調させる構造を作る。一つのエージェントが設計を担当し、別のエージェントが実装を担当し、また別のエージェントがテストを担当するといった具合だ。これは人間の開発チームの構造をエージェントシステムに投影したものだ。

HUD(Heads-Up Display)はこのエージェントシステムの状態をユーザーがリアルタイムで観察できるようにするインターフェイスだ。どのエージェントが何をしているか、どこでボトルネックが発生しているか、どれだけ進行したかを視覚的に見せる。

agent teams + HUDの組合せは、coding agentの使用パラダイムが「私とエージェントの1:1の対話」から「私がエージェントチームを運営する管理者」に進化しつつあることを示唆する。この進化で必要なのはより強力なモデルではない。エージェントチームを効果的に運営するための運用知識である。誰をいつ投入し、どんな順番で進め、どんな基準で結果を検収するか。これはプロジェクトマネジメントの知識だ。

oh-my-codexがやっていることは、この運用知識をツール化することだ。そして19,938スターはこのツール化への需要が巨大だということを物語る。

5. 既存moat議論の限界と拡張 — 個人の文脈から集団の運用知識へ

前回の記事「複製されても生き残るエージェントの条件」で、私は三つの堀を論じた。第一に、文脈の蓄積 — ユーザーとの相互作用を通じて積み上がるパーソナライズされた知識は複製できない。第二に、フィードバック・フライホイール — 出力 → 反応 → 学習 → 改善のループが時間とともに加速する。第三に、深い統合 — エージェントがワークフローの接着剤になれば交換コストが幾何級数的に増加する。

この三つの堀は依然として有効だ。だが2026年4月10日の週の現象は、このフレームワークが見逃している新たな層をあらわにする。

以前の議論の限界 — 個人レベルに閉じ込められた堀

前回の記事の三つの堀はすべて個人またはチームレベルで作動する。私のCLAUDE.mdに溜まった文脈、私のフライホイールの慣性、私のワークフローの統合。これは強力なlock-inを作るが、個別ユーザーの個別経験に縛られている。Aという開発者の文脈はBという開発者に転移しない。各自の堀は各自のものだ。

ところがsuperpowers、andrej-karpathy-skills、claude-howto、oh-my-codexが見せているのは別次元のものだ。個人の運用知識がファイルに結晶化され、GitHubを通じて共有され、数千人のユーザーに直ちに適用される。個人の文脈が集団の知識になる過程である。

これを整理するとこうなる。

層前回の記事のmoat今回の記事の新たなmoat
単位個人/チームコミュニティ/生態系
形態暗黙知(tacit knowledge)形式知(explicit knowledge)
保存媒体ユーザープロファイル、対話履歴CLAUDE.md、skills、templates
転移可能性不可能(堀の核心)可能(知識の結晶化)
蓄積速度個人の使用時間に比例コミュニティの貢献速度に比例

集団運用知識という新たな層

2026年4月現在、GitHubで観察される現象を一つの概念で要約すれば**「集団運用知識の層(collective operational knowledge layer)」**となる。この層はモデルの上に、そして個人の文脈の傍に存在する。

構造を図にするとこうなる。

[個人ユーザーの文脈] ← 前回の記事のmoat
        ↑
[集団運用知識の層: superpowers, karpathy-skills, claude-howto, oh-my-codex] ← 今回の記事の主題
        ↑
[Harness/Agent ソフトウェア: Claude Code, Codex CLI]
        ↑
[Foundation Model: Opus 4.6, GPT-5.x 等]

個人の文脈は蓄積されると移転不可能だ — これが前回の記事のmoatだった。集団運用知識は蓄積されると直ちに共有可能だ — これが今回の記事の新たな発見だ。二つの層は対立するのではなく補完する。集団運用知識が「ベースライン(baseline)」を引き上げ、個人の文脈がそのベースラインの上にパーソナライズを加える。

andrej-karpathy-skillsを適用すれば全ユーザーのClaude Code経験が一段階上がる。これは集団運用知識の役割だ。その上で個人ユーザーが自分だけのCLAUDE.mdを磨けば経験がさらに一段階上がる。これは個人の文脈の役割だ。

含意 — 二種類のmoatが結合するとき

前回の記事で「フィードバックフライホイールと深い統合が結合すれば堀が完成する」と述べた。今回の記事はここに一次元を加える。個人の文脈のmoatと集団運用知識のmoatが結合すれば、生態系レベルの堀が形成される。

具体的に説明しよう。ある開発者がClaude Codeを使い始める。まずsuperpowersをインストールし、andrej-karpathy-skillsのCLAUDE.mdをプロジェクトにコピーする。これで「コミュニティが検証したベストプラクティス」が直ちに適用される。その後数週間使いながら個人の文脈が積み上がる — 「このプロジェクトではこのパターンを使わない」「このチームはレビューコメントを韓国語で書く」のようなものだ。同時にこの開発者が発見した新たなベストプラクティスがあれば、それをGitHubにPRとして上げるか、独自のskillsレポを作って共有する。これが集団運用知識の層に貢献する行為だ。

この循環が回るほど三つが同時に強化される。Claude Codeというプロダクトの価値、個人ユーザーのswitching cost、そしてコミュニティ全体の知識水準。三つの車輪が噛み合って回る複合フライホイールである。

6. 両面解釈:Anthropicのネットワーク効果 vs ベストプラクティスのコモディティ化

ここまで読むと「結局Anthropicが最大の受益者ではないか」という結論に流れうる。Claude Codeをより上手く使う方法がコミュニティによって結晶化され共有されるほど、Claude Codeの価値が上がり、より多くのユーザーが流入し、より多くの運用知識が積み上がる。典型的なネットワーク効果。その通りだ。だが話の半分だけ正しい。

解釈A — Anthropicのネットワーク効果

この解釈は直感的だ。superpowersがClaude Codeをより上手く動かすほど、Claude Codeの実質性能は上がる。andrej-karpathy-skillsがLLMコーディングの落とし穴を矯正してくれるほど、Claude Codeユーザーの満足度は高まる。claude-howtoが参入障壁を下げるほど、新規ユーザー獲得が容易になる。claudianがObsidianで表面を拡張するほど、Claude Codeのハビタットが広がる。

これらはすべてAnthropicが直接作ったものではない。コミュニティが自発的に作ったものがAnthropicのプロダクト価値を高めている。これはAndroid生態系でアプリ開発者がGoogleのプラットフォーム価値を高めたのと同じ構造だ。npmパッケージがNode.jsの価値を高めたのと同じ構造だ。プラットフォームの価値はその上に積み上がる生態系の厚みに比例する。

CLAUDE.mdというファイル形式が事実上の標準(de facto standard)になりつつあることも重要だ。競合 — 例えばOpenAIのCodex — も類似のエージェント指針ファイルをサポートする(AGENTS.md等)が、CLAUDE.mdという名前そのものが生態系を先占している。andrej-karpathy-skillsの中核成果物がCLAUDE.mdという名前を冠しているという事実自体が、Anthropicのブランドがこの生態系のデフォルト(default)になったことを示している。

この観点から見ると、Anthropicの戦略的ポジションは極めて強い。モデル性能でのリード + harnessの品質 + コミュニティが作った運用知識の層 = 複合的堀。競合がモデル性能を追いついても、143,712スターのsuperpowersと10,441スターのandrej-karpathy-skillsがClaude Code生態系に固定されている限り、ユーザーのデフォルトはClaude Codeに留まる。

解釈B — ベストプラクティスのコモディティ化(commoditization of best practices)

ところが反対方向の解釈も成り立つ。この解釈の方がより微妙で、より重要かもしれない。

superpowers、andrej-karpathy-skills、claude-howtoがやっていることは「Claude Codeを上手く使う方法」を誰でもアクセスできるようにすることだ。過去にはこの知識をパワーユーザーだけが持っていた。数百時間の試行錯誤を経てCLAUDE.mdを磨き、skillsを定義し、ワークフローを最適化した人々。彼らは同じモデルを使っても初心者より顕著に良い結果を得た。この格差がパワーユーザーの競争優位だった。

今起きていることはこの競争優位の民主化だ。andrej-karpathy-skillsをコピーして貼り付ければ、昨日Claude Codeを使い始めた人もパワーユーザーの指針を直ちに適用できる。superpowersをインストールすれば、ソフトウェア開発方法論を数年磨いた人の規律がエージェントに自動的に植え付けられる。

これは「ベストプラクティスのコモディティ化」だ。以前は希少だった運用知識がGitHubを通じて無料で配布されながら希少性を失う。パワーユーザーが持っていた情報非対称性が解消される。皆が「上手く使う方法」を知るようになると、「上手く使う方法」はもはや差別化要因ではない。デフォルトになる。

これはAnthropicにとってどんな意味を持つのか。二つの方向の含意がある。

第一に、肯定的方向。デフォルトの水準が上がれば、プロダクト全体の満足度が上がる。不満による離脱が減る。より多くのユーザーがClaude Codeで良い経験をし、サブスクを維持する。

第二に、否定的方向。運用知識がコモディティ化すれば、その知識はプラットフォームに従属しない。oh-my-codexが証明するように、同じパターンはCodexにも適用される。superpowersの方法論 — brainstorming先行、plan先行、verification必須 — はClaude Codeにだけ有効ではない。どんなcoding agentにも適用可能な汎用知識だ。ユーザーがこの汎用知識を体化すれば、Claude CodeからCodexへ、あるいはまだ登場していない新しいエージェントへ移動する摩擦が減る。運用知識がモデルに従属しない以上、その知識の蓄積が特定モデルのlock-inを強化しないかもしれない。

両面が同時に作動する

現実は解釈AとBが同時に作動することだ。ネットワーク効果とコモディティ化は矛盾しない。同じ現象の二つの面である。

短期的には解釈Aが優勢だろう。CLAUDE.mdという名前が生態系に固着し、superpowersのskillsがClaude Codeに最適化されており、claude-howtoのテンプレートがClaude Codeの文法に合わせられている。この生態系から他のエージェントに移るには、これまでに積み上がったskillsとtemplatesを全部新しい環境に合わせて変換しなければならない。これがswitching costだ。

長期的には解釈Bが浮上する可能性がある。運用知識が十分体系化され抽象化されれば、特定ツールに従属しない汎用フレームワークになりうる。oh-my-codexが既にその方向の最初のシグナルだ。「Claude Codeのためのsuperpowers」ではなく「すべてのcoding agentのためのsuperpowers」が登場するのは時間の問題かもしれない。

この解釈が前回の記事のlock-in議論とどう繋がるか

前回の記事「LLM lock-inの亀裂」で、私は「一つのモデルにオールインという前提が揺らいでいる」と書いた。今週の現象はその亀裂の別の面を見せている。運用知識が結晶化し共有されると、モデル間移動の摩擦が減る。一方で生態系のネットワーク効果が大きくなると、特定モデル生態系を離れるコストが上がる。二つの力が反対方向に作用する。どちらが優勢になるかは今は判断できない。3か月後、6か月後のデータが必要だ。

7. 実務者への示唆

この現象が毎日コードを書く開発者、チームリード、エンジニアリングマネージャーにどんな意味を持つのか。抽象的な生態系分析を超え、具体的な行動指針を導いてみよう。

示唆1 — CLAUDE.md(または該当エージェントの指針ファイル)に投資せよ

andrej-karpathy-skillsの10,441スターが物語るのは、このファイル一つがエージェント経験の相当部分を決定するということだ。空のCLAUDE.mdでClaude Codeを使っているなら、性能の相当部分を浪費していることになる。エンジンはV8なのに1速だけで走っているようなものだ。

具体的行動:andrej-karpathy-skillsをフォークしてプロジェクトルートに置くが、そのまま使うのではなく、プロジェクトの文脈に合わせて修正すること。チームのコーディング規約、テスト戦略、コミットメッセージのルール、レビュー基準を追加すること。このファイルを定期的にアップデートすること — エージェントとの相互作用で「これは違った」という瞬間が生じたら、その教訓をCLAUDE.mdに反映すること。

示唆2 — skillsとmethodologyを分けて採用せよ

superpowersはskills(個別機能)とmethodology(作業フロー)の両方を含む。二つを区別して採用することが重要だ。skillsは比較的気軽に追加・削除できる。特定のskillが現在のプロジェクトに合わなければ切ることができる。methodologyは作業方式そのものを変えることなので、チーム全体の合意が必要だ。

具体的行動:superpowersのskillsリストをレビューし、現在のワークフローで反復的に問題となる領域に該当するskillを優先採用すること。例えば、コードレビューが常に不足しているならcode-review skillを、デバッグに時間を多く取られるならsystematic-debugging skillを。methodology採用はチーム議論として別途分けること。

示唆3 — 運用知識のバージョン管理を始めよ

CLAUDE.mdはコードのようにバージョン管理すべきだ。今効果的な指針が3か月後にも効果的だという保証はない。モデルがアップデートされれば最適な指針も変わる。チームの規模が大きくなれば規約も変わる。プロジェクト段階が変わればエージェントの必要な振る舞いも変わる。

具体的行動:CLAUDE.mdをGitにコミットし、変更理由をコミットメッセージに記録すること。「エージェントがテストなしでコードを生成する傾向があるため『テスト先行』指針を追加」のように。この履歴が積み上がると、それ自体がチームのエージェント運用ヒストリーになる。

示唆4 — hooksを設定せよ

oh-my-codexがhooksを中核機能として打ち出したのには理由がある。エージェントが強力になるほど、エージェントの振る舞いを制限するメカニズムも強力でなければならない。これは権限管理の問題であり、リスク管理の問題でもある。

具体的行動:エージェントが絶対に触れてはいけないファイルやディレクトリを定義すること(例:本番環境設定、認証鍵、データベースマイグレーション)。エージェントが外部サービスを呼ぶ前に確認を要求するhookを設定すること。エージェントが一定規模以上の変更を一度に実行しようとする際に中断するhookを設定すること。

示唆5 — 生態系を観察せよ

2026年4月10日の週に五つのメタツールが同時にトレンドしたのは、このカテゴリーが急速に成長しているシグナルだ。明日また別のツールが登場するかもしれない。エージェント運用ツールの環境は急速に変わっている。

具体的行動:GitHub Trendingのdeveloper toolsカテゴリーを定期的にチェックすること。superpowers、oh-my-codexのようなレポのリリースノートを購読すること。この生態系で有用なツールが出たらチーム内に共有するチャネルを作ること。

示唆6 — あなたの運用知識を還元せよ

この生態系はユーザーの貢献で成長する。あなたがプロジェクトで発見した効果的なエージェント運用パターンは、他の誰かにも有用な可能性が高い。それをCLAUDE.mdスニペットとして整理して共有すれば、生態系全体の知識水準が上がる。これは利他的行為であると同時に利己的行為でもある — 生態系の水準が上がれば、その生態系であなたが受け取るツールと知識の品質も上がるからだ。

8. 構造的解釈 — なぜ今、なぜ同時に

五つのレポが同じ週に同時トレンドした理由を構造的に説明できるか。個別のレポの成功には各々の事情があろうが、同時発生は偶然ではない。背景に三つの構造的条件がある。

条件1 — coding agentユーザー人口の臨界点到達

Claude Codeがリリースされて以降、ユーザー数は着実に増加した。だが「メタツール」が必要になるには、基盤ツールのユーザーが十分に多くなければならない。oh-my-zshが登場したのもZshユーザーが一定規模以上になった後だった。npmパッケージ生態系が爆発したのもNode.jsユーザーが臨界点を越えた後だった。

2026年4月時点でcoding agentユーザー数がこの臨界点を越えたと見られる。正確な数値は公表されていないが、間接証拠はある。superpowersの143,712スターは、このツールを一度でも使ったことのある人が最低でも数十万人にはなることを示唆する(スターを付ける人は実際のユーザーの一部に過ぎないので)。

条件2 — 「上手く使う方法」の格差が可視化される

coding agentを初めて使う人と6か月間使ってきた人の生産性格差は体感水準で大きい。前回の記事で扱ったMagantiの事例がこれを示している — 同じ人が、同じモデルで、同じプロジェクトを作ったのに、初回の試み(運用知識なし)はスパゲッティコードで全量廃棄され、二回目の試み(運用知識蓄積後)は成功裏にローンチされた。

この格差が可視化されるほど、「上手く使う方法」への需要が爆発する。andrej-karpathy-skillsの週次+2,230スター、claude-howtoの週次+7,342スターはこの需要の表現だ。ユーザーは試行錯誤を減らしたく、誰かの検証済み運用知識を素早く取り込みたい。

条件3 — 共有インフラの成熟

GitHubは既に20年以上コード共有のインフラとして機能してきたが、CLAUDE.mdというファイル形式の登場は新しい種類の共有を可能にした。コードではなく知識を共有することだ。それも自然言語の知識を。

従来、運用知識を共有するにはブログ記事を書かなければならなかった。長い文を読み、自分の環境に合わせて解釈し、手動で適用しなければならなかった。摩擦が大きかった。CLAUDE.mdはこの摩擦を取り除いた。ファイル一つをコピーすれば直ちに適用される。「読んで理解して適用する」3段階が「コピーして貼り付ける」1段階に短縮された。この摩擦の除去が共有の速度を爆発的に高めたのだ。

三つの条件 — ユーザー人口の臨界点、格差の可視化、共有摩擦の除去 — が同時に満たされたのが2026年4月10日の週だ。だから五つのレポが同じ週に爆発したのである。

9. IDEプラグイン、プロンプトエンジニアリング、そして運用知識 — 三時代の比較

この現象をより広い歴史的文脈に置いてみよう。開発者ツールが「拡張」される方式は三度の質的転換を経た。

時代1: IDEプラグイン (2010年代のVS Code extensions)

VS CodeがExtension APIを公開した後、数万の拡張機能が溢れた。Prettier、ESLint、GitLens、Live Share。これらの拡張機能はエディタに機能を追加した。文法チェック、フォーマッティング、バージョン管理統合、コラボレーション。拡張機能の本質は「ツールに機能を付着させる」ことだ。

この時代の核心仮定は、ツールが中立的(neutral)だということだ。VS Codeはパイソンも、JavaScriptも、Rustも同等に編集できる汎用エディタだ。拡張機能はその汎用性の上に特化された機能を載せる。ツールの「判断」は存在しない。エディタはユーザーのキー入力を忠実に反映するだけだ。

時代2: プロンプトエンジニアリング (2023~2024年)

ChatGPTが登場した後、ユーザーは「どう質問すれば良い答えが出るか」を探求し始めた。プロンプトエンジニアリングという分野が誕生した。Twitterでプロンプトのコツが共有され、GitHub gistに「best prompts for coding」が上がった。

この時代の核心は、知識が使い捨てだったことだ。「chain of thoughtを誘導するには『Let’s think step by step』を付けろ」 — これはコツであり体系ではない。一度適用すれば終わりだ。次の対話でまた覚えて適用しなければならない。プロンプトエンジニアリングの知識はユーザーの頭の中に留まり、ツールに反映されなかった。セッションが終われば蒸発した。

時代3: 運用知識の結晶化 (2026年)

今起きていることは質的に異なる。ユーザーの運用知識がファイルに収まり、そのファイルがエージェントの振る舞いを持続的に規定する。一度CLAUDE.mdに書けば全てのセッションで作動する。一度superpowersのskillとして定義すれば全てのプロジェクトで呼び出せる。知識が蒸発しない。結晶化(crystallize)される。

三時代を比較するとこうなる。

時代1: プラグイン時代2: プロンプト時代3: 運用知識
時期2010s2023~20242026~
対象エディタLLMCoding Agent
拡張の形態コード(拡張プログラム)テキスト(使い捨てプロンプト)テキスト(持続的指針)
ツールの性格中立的(ユーザー入力反映)反応的(質問に回答)自律的(指針に従い判断)
知識の持続性永久(インストールされれば維持)一時的(セッション終了時に消滅)永久(ファイルに結晶化)
共有の単位パッケージ(.vsix)テキストスニペット指針ファイル(CLAUDE.md)
レバレッジ機能追加回答品質の向上エージェント振る舞い体系の変更

時代3の核心的違いは、ツールが自律的だということだ。IDEはユーザーが言われた通りにする。LLMはユーザーが尋ねたことに答える。Coding agentは目標を与えれば自ら判断し行動する。自律的なツールには「機能」ではなく「判断基準」を与えなければならない。だから運用知識の形態がコードプラグインでも使い捨てプロンプトでもなく、持続的な指針ファイルになったのだ。

この観点で2026年4月の五つのレポは時代3の本格的開幕を告げる信号弾だ。開発者ツールの拡張方式が「機能付着」から「運用知識注入」へ転換しつつある。

10. 開かれた問い — この爆発はどこへ向かうのか

2026年4月10日の週の現象を整理すればこうだ。

一つ、coding agentメタツール生態系が爆発的に成長している。五つのレポが同じ週に同時トレンドし、合算スター数は20万を超える。

二つ、この生態系の核心成果物はコードではなく運用知識だ。CLAUDE.mdファイル、skills定義、コピー可能なテンプレート — 自然言語の知識がプロダクトの形を備えた。

三つ、同じパターンがClaude Codeだけでなく Codex でも発生している(oh-my-codex)。これは特定プロダクトではなくカテゴリーレベルの現象だ。

四つ、この現象は新たな種類のmoatを形成している。前回の記事で扱った個人の文脈のmoatの上に、集団運用知識のmoatが追加されている。同時にベストプラクティスのコモディティ化が進行しながら、運用知識が特定プラットフォームに従属しない可能性も開かれている。

この整理の上で、開かれた問いを投げてみる。

問い1 — 運用知識の層はモデルに従属するか、汎用化するか?

現在superpowersはClaude Codeに最適化されている。oh-my-codexはCodexに最適化されている。二つは同じ構造だが互換性がない。この分離は維持されるのか。それとも「全てのcoding agentに適用可能な汎用運用知識フレームワーク」が登場するのか。

もし汎用化されれば、運用知識の層はモデルのlock-inを弱める — どんなエージェントでも同じskillsを適用できるから。もし分離が維持されれば、各モデル生態系のlock-inを強化する — 私のskillsを移すには全部書き直さなければならないから。

問い2 — Anthropicはこの生態系をどう扱うのか?

これまでAnthropicはCLAUDE.mdとskills生態系を奨励する方向に動いた。だがこの生態系が大きくなれば、統制の問題が発生する。コミュニティが作ったskillがモデルの限界を回避したり、安全装置を弱めたりするケースが出うる。Anthropicはこの生態系を公式に統合(curate)するのか、放置するのか、あるいは特定範囲内でのみ許容するのか。

AppleのApp Store戦略(厳格な審査と統制)とGoogleのPlay Store戦略(比較的開放的な許容)の違いを思い起こせる。Anthropicがどちらを取るかによって生態系の性格が変わるだろう。

問い3 — CLAUDE.mdは標準になるのか?

現在Claude CodeはCLAUDE.mdを、CodexはAGENTS.mdを、他のツールは各々の形式を使う。これは統合されるのか。HTMLがウェブの標準マークアップになり、Dockerfileがコンテナの標準形式になったように、エージェント指針ファイルの標準形式が登場するのか。

標準が登場すれば、運用知識のポータビリティ(portability)が高まる。一度書いた指針ファイルを複数のエージェントで使えるようになる。これはユーザーには利益で、特定ベンダーのlock-inには脅威だ。

問い4 — 運用知識の「適用」を超えて「生成」を自動化できるのか?

現在の運用知識は人間が書く。Karpathyが観察し、誰かが整理し、GitHubに上げる。だがエージェント自身が自分の運用を観察し、失敗パターンを検知し、最適な指針を自動で提案することは可能か。

「今回のセッションでエージェントが3回同じミスを繰り返しました。CLAUDE.mdに次の指針を追加しますか:『関数が20行を超えれば必ず分けること』」というフィードバックが自動で生成されたら? これは現在の静的知識を動的学習に転換することだ。superpowersの次世代ツールがこの方向を探索する可能性がある。

問い5 — あなたはこの生態系に参加しているか?

最後の問いは読者に直接向かう。あなたのCLAUDE.mdは空か、それとも数か月磨かれた運用知識が盛られているか。あなたは他人が作ったskillsを消費するだけか、それともあなたの発見を還元しているか。

前回の記事の結論が「あなたのエージェントは使うほど良くなっているか?」だったなら、今回の記事の結論はもう一つ追加される。「あなたの運用知識は結晶化されているか? そしてその結晶体は他の人に届いているか?」

エージェントのmoatはモデルにはない。モデルの上に積み上がる運用知識 — 個人の文脈と集団の知識が結合した層 — にある。2026年4月10日の週、五つのレポが同時にその事実を指し示した。この方向がどこまで行くかはまだ分からない。ただ一つ確かなのは — モデルを上手く作ることとモデルを上手く使う方法を知ることは全く異なる力量であり、後者に対する市場が今爆発しているということだ。

出典: