はじめに
2026年4月、GitHub Trending を眺めると明確なパターンが浮かび上がる。上位に目立つのは LLM そのものよりも、AIエージェントを「どう運用するか」を扱うリポジトリだ。ただし Trending はあくまで短期的な注目度の指標であり、ここで取り上げるリポジトリの評価は「いま勢いがある」という観測に基づくものである点に留意してほしい。
しかも、この傾向は特定のツールに閉じていない。Claude Code と Codex CLI という2つの主要なコーディングエージェントの周辺で、驚くほど似たカテゴリのエコシステムが並行して発展している。拡張レイヤー、CI統合、サブエージェント、ベストプラクティス——解決しようとしている課題が同じだから、生まれるツールも似てくる。
本記事では、2026年4月の GitHub Trending で注目を集めたリポジトリ群を エコシステム横断で俯瞰 し、AIエージェント開発の現在地を整理する。
注記: 本記事の情報は2026年4月時点のものであり、各リポジトリの機能・数値は変動する可能性がある。Stars 数は2026年4月11日時点の各リポジトリページに基づく。最新の情報は各リポジトリの README を参照してほしい。
トレンドの全体像: モデル性能から運用設計へ
少なくとも GitHub Trending で見る限り、関心の中心は「AIにコードを書かせる」こと自体から、どう分業し、どうレビューし、どうコンテキストを節約し、どう CI に接続するか——つまり「エージェントハーネス」の設計へと移りつつある。
この傾向は Claude Code 系・Codex CLI 系の両方で共通している。モデルの出力品質が一定水準に達した今、差がつきやすいのは「どう使わせるか」の設計部分だと考えられる。
2つのエコシステム: 共通する6つのカテゴリ
Claude Code と Codex CLI のエコシステムを並べると、6つの共通カテゴリが浮かび上がる。
| カテゴリ | 何を解決するか | Claude Code 系 | Codex CLI 系 |
|---|---|---|---|
| 拡張レイヤー | CLI にワークフロー層を追加 | oh-my-claudecode (~27.5k) | oh-my-codex (~20.8k) |
| CI統合 | GitHub Actions へのエージェント統合 | claude-code-action (~7k) | codex-action (~920) |
| サブエージェント | タスク特化エージェントの管理 | Claude サブエージェント機構（.claude/agents/ にファイル定義） |
awesome-codex-subagents (~3.8k) + codex-specialized-subagents |
| 実践知識 | テンプレート・運用ルールの即戦力化 | claude-code-best-practice (~36.3k) | codex-cli-best-practice |
| フレームワーク / 最適化 | プロセスの規律化・ハーネス最適化 | superpowers (~146k) / everything-claude-code (~150k) | (Claude 起点だが両者とも Codex 等にも対応) |
| 並列実行 | 複数エージェントの協調オーケストレーション | claude_code_agent_farm (~780) | — |
注目すべきは、拡張レイヤー（oh-my-claudecode / oh-my-codex）と実践知識（claude-code-best-practice / codex-cli-best-practice）がそれぞれ同一の作者によって開発されている点だ。両エコシステムの課題が共通していることを示唆している。
カテゴリ別: 共通と差異
拡張レイヤー: 同じ問いに異なる回答
oh-my-claudecode と oh-my-codex は同じ作者（Yeachan-Heo）による姉妹プロジェクトだ。どちらも「CLI 本体を置き換えず、上にワークフロー層を被せる」という設計思想を共有する。
しかし対象 CLI の違いから、実装は大きく分岐している。
| 観点 | oh-my-claudecode | oh-my-codex |
|---|---|---|
| 基盤技術 | Claude Agent SDK に深く統合 | 本番依存3パッケージ + Rust クレートで軽量独立 |
| エージェント設計 | 静的レジストリ（専門特化型を事前定義、モデル選択まで制御） | 動的カタログ（多数のロールプロンプトをタスク時に選択、モデル選択はCLI委任） |
| モデルルーティング | Haiku → Opus 自動選択（OMC 固有） | なし（Codex CLI 依存） |
| 拡張性 | 内蔵フック群を設定で調整するスタイル | HookPluginSdk によるプラグイン拡張スタイル |
差異の本質は3点だ。SDK 統合の深さ（Claude Agent SDK に深く乗るか、最小依存で独立するか）、エージェント管理の方式（静的定義のレジストリか、タスク時に動的選択するカタログか）、拡張の方向性（内蔵フック群の設定調整か、プラグイン SDK による自由拡張か）。5段階 Team パイプライン・tmux・HUD・autopilot は両ツール共通であり、「どちらを選んでも核心的な機能は得られる」という前提の上で、この3軸が選択を分ける。
各プロジェクトの詳細は oh-my-claudecode入門編 および oh-my-codex入門編、設計判断の比較は 比較記事 を参照
CI統合: セキュリティ設計の違い
claude-code-action（Anthropic 公式）と codex-action（OpenAI 公式）は、どちらも公式の GitHub Action として CI パイプラインへのエージェント統合を提供する。
claude-code-action は MCP サーバーによるカスタムツール拡張と複数の認証プロバイダー（Anthropic API、AWS Bedrock、Google Vertex AI）を売りにしている（リポジトリ参照）。codex-action はワークスペース権限を制御する sandbox とプロセス権限を制御する safety-strategy の2軸によるきめ細かなセキュリティ管理が特徴だ（公式ドキュメント参照）。
Stars 数では claude-code-action が上回っているが、codex-action はリリースからの期間が短い点を考慮する必要がある。
サブエージェント: 設計パラダイムの違い
Claude Code はサブエージェントを .claude/agents/ にファイルとして定義するビルトインの仕組みを持つ。一方、Codex CLI 側では awesome-codex-subagents（TOML 定義のエージェントカタログ。詳細はCodex CLI エコシステム編参照）と codex-specialized-subagents（MCP サーバーによる委任基盤。前身の codex-subagents-mcp からの全面書き直し）が「何を委任するか」と「どう委任するか」を分離して提供している。
Claude Code 側がプラットフォーム内蔵のサブエージェント機構を持つのに対し、Codex CLI 側はコミュニティ主導でエコシステムとして構築している。ただし Codex 側にも公式の CI 統合（codex-action）があり、「公式 vs コミュニティ」という対比は領域によって異なる点に注意が必要だ。
実践知識: 同一作者が見た共通解
claude-code-best-practice と codex-cli-best-practice は同じ作者（shanraisshan）の手による。いずれもカテゴリ分類された多数の Tips を収録している（Tips 数はバージョンにより変動する。詳細は各エコシステム編を参照）。
興味深いのは、両者が「Research → Plan → Execute → Review → Ship」という同じワークフローに収束している点だ。CLIが違ってもベストプラクティスが似るのは、運用課題の本質が CLI の選択ではなくエージェントの制御にあることを示唆している。
フレームワーク / 最適化: Trending 上では Claude Code 側のレイヤーが広い
superpowers と everything-claude-code は、いずれも十万超の Stars を集め、プロセスの規律化とハーネスの最適化という上位レイヤーをカバーする大規模プロジェクトだ。どちらも Claude Code を起点としつつ、Cursor、Codex、OpenCode など複数のツールにも対応しており、実質的にはツール横断のフレームワークとして機能している。
Codex CLI 側は公式 CI（codex-action）とコミュニティ主導の委任基盤が先に整備される一方、専用のフレームワーク層はこれからの領域だ。ただし superpowers や everything-claude-code が Codex にも対応しているため、Codex ユーザーもこれらを活用できる状況にある。
エコシステムの比較（2026年4月 Trending 観測時点）
| 観点 | Claude Code エコシステム | Codex CLI エコシステム |
|---|---|---|
| Stars 規模感 | 大規模（数万〜十数万） | 小〜中規模（数百〜約2万） |
| リポジトリ数 | 7以上 | 5以上 |
| カテゴリのカバー範囲 | 6カテゴリ（フレームワーク・並列実行含む） | 4カテゴリ（公式 CI と委任基盤が先行整備、専用フレームワーク層はこれから） |
| ツール横断性 | superpowers / ECC が Codex にも対応 | codex-specialized-subagents が Claude パターンを移植 |
| CI統合の公式度 | Anthropic 公式 | OpenAI 公式 |
Trending の Stars 規模でみると Claude Code エコシステムのレイヤーが広く見えるが、Codex CLI 側も主要カテゴリでは同等の課題を解決するツールが揃いつつあり、公式 CI 統合やコミュニティ主導の委任基盤など独自の強みも持つ。
どこから始めるか
Claude Code ユーザー
- claude-code-best-practice で運用ルールを整える
- oh-my-claudecode でマルチエージェント構成を導入
- superpowers でプロセスの規律を追加（Codex 等にも対応）
- claude-code-action で CI に接続
Codex CLI ユーザー
- codex-cli-best-practice で運用ルールを整える
- awesome-codex-subagents で特化エージェントを導入
- oh-my-codex でチームワークフローを構築
- codex-action で CI に接続
詳細は本シリーズの Codex CLI エコシステム編を参照
どちらの CLI を使うか迷っている場合
両エコシステムの拡張レイヤー比較（oh-my-claudecode vs oh-my-codex）が判断材料になる。SDK エコシステムへの深い統合と内蔵フック群の充実を重視するなら OMC（Claude Code 側）、外部依存を最小化しプラグイン拡張で積み上げるスタイルを好むなら OMX（Codex CLI 側）が設計思想に合う。モデルルーティングの自動化（Haiku → Opus の自動選択）が必要な場合は OMC 固有の機能だ。
参考リンク
- oh-my-claudecode — Claude Code 向けマルチエージェント拡張
- oh-my-codex — Codex CLI 向けワークフロー拡張
- oh-my-claudecode vs oh-my-codex（Qiita） — 同一作者が異なる設計判断をした理由の分析
- claude-code-action — Anthropic 公式 GitHub Action
- codex-action — OpenAI 公式 GitHub Action（開発者ドキュメント）
- awesome-codex-subagents — Codex CLI サブエージェントカタログ
- codex-specialized-subagents — MCP サーバーによるサブエージェント委任基盤（前身: codex-subagents-mcp、アーカイブ済み）
- claude-code-best-practice — Claude Code 運用ベストプラクティス集
- codex-cli-best-practice — Codex CLI 運用ベストプラクティス集
- superpowers — エージェントスキルフレームワーク（ツール横断対応）
- everything-claude-code — エージェントハーネス最適化（ツール横断対応）
- claude_code_agent_farm — Claude Code 並列エージェント実行
まとめ
2026年4月の GitHub Trending で上位に相次いでランクインした「エージェントハーネス」系リポジトリは、CLI の選択を超えた共通トレンドを示している。Claude Code と Codex CLI という異なるプラットフォームの周辺で、拡張レイヤー、CI統合、サブエージェント、実践知識という同じカテゴリのツールが並行して生まれていることは、運用設計が新たな競争軸として浮上しつつあることを示唆していると読める。
本シリーズでは、各エコシステムの詳細を個別記事で深掘りしている。自分のチームが使う CLI とワークフローに合ったものから試してみてほしい。