everything-claude-codeとは?GitHub13万スター設計書を30体AIチームで検証

COLUMN

GitHub 13万スターの「AI厨房設計図」を
30体AIチーム目線で答え合わせしてみた

2026.04.03 | AI氣道 コラム

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん(@passion_tanaka)です。

今日はちょっと面白い話をする。GitHubで131,000スターを超えた「everything-claude-code」(以下ECC)っていうオープンソースプロジェクトがあるんだけど、これを見た時の正直な感想が「あ、答え合わせだ」だったんだよね。

私は今、30体のAIチームを毎日動かしてる。AI秘書の凛、分身AIひろくん、Codex——それぞれに役割と人格がある。「脱ChatGPT」の記事でも書いたけど、164個のスキル、102個のhookを積み上げて、コンテンツ制作から経営判断まで全部回してる。

ECCは、この「AIの仕事環境を設計する」という考え方を、世界中の開発者向けに体系化したリポジトリだった。同じ課題に、別のアプローチで答えを出してる。

今日は「どこが同じで、どこが違ったか」を正直に話すね。

この記事でわかること

  • everything-claude-code(GitHub 131,000+スター)の設計思想を3つに分解
  • 私の30体AIチーム「mothership-lab」と比較して同じだったこと・違ったこと
  • 「AIの仕事環境を設計する」がなぜエンジニアじゃなくても関係あるのか
  • 今日から始められる3つのアクション
GitHub13万スターのAI厨房設計図を30体AIチームで答え合わせ 全体図グラレコ
01

「すごいのに不安定」——みんな同じ壁にぶつかってる

AIが不安定な問題

AIコーディングエージェントを使い始めて、こんな経験ない?

同じ指示を出してるのに、昨日と今日で全然違うものが出てくる。ベストプラクティスを無視する。セキュリティの穴を開けてくる。「確認しました」って言うから信じたら、何も確認してなかった。

私もめちゃくちゃ苦労した。30体のAIチームを動かしてる今でさえ、油断するとAIは同じことをやる。

🍳 料理に例えると

腕のいいシェフを雇ったのに、厨房がグチャグチャで毎日味がブレてる状態。レシピ(プロンプト)だけじゃ足りない。厨房そのものを設計しないと、安定した料理は出てこないんだよね。

ECCの公式READMEにもこう書いてある。

ECC公式

“AI coding agents are powerful but inconsistent.”
(AIコーディングエージェントはパワフルだが不安定)

適切なガイダンスなしでは、ベストプラクティスを無視し、セキュリティの穴を作り、信頼できないコードを吐く——と。まさにそれ。世界中で同じ壁にぶつかってたんだよね。

ちなみにForbes JAPANの報道によると、ChatGPTからClaudeへの乗り換えが1487%増。この流れとも無関係じゃないと思う。Claude Codeを使い始めた人が増えたからこそ、「使い方のガイドが欲しい」というニーズが爆発した。

ポイント

AIの「使い方」じゃなくて「働く環境」を設計する。ECCが13万スターを集めたのは、世界中の開発者がこの課題の重要性に気づいたから。

02

everything-claude-codeの正体——読み物じゃなくて実行可能なシステム

everything-claude-codeの全体像

ECCは、SF在住のエンジニアAffaan Mustafaが作ったオープンソースプロジェクト。Anthropicのハッカソンで優勝した実績がある。

「Claude Code Tips」みたいな読み物系のリポジトリとの決定的な違いは、ECCが実行可能なシステムだという点。インストールすると、36体のエージェント、147のスキル、68のコマンドがClaude Codeの環境に組み込まれる。

数字で見るとこうなる。

指標 数値
GitHubスター 131,000+
フォーク 18,800+
コントリビューター 113名
エージェント数 36体
スキル数 147
コマンド数 68
セキュリティテスト 1,282(カバレッジ98%)

出典: everything-claude-code GitHubリポジトリ(2026年4月2日時点)

ECCの答えは、「ベストプラクティスをドキュメントに書くだけじゃなく、HookやAgentとしてプログラム的に強制する」こと。

🍳 料理に例えると

「塩入れすぎないでね」と口頭で言うんじゃなくて、計量スプーンを厨房に組み込むアプローチ。同じAIでも、厨房の設計(ハーネス設計)で結果が別物になるっていう実例がここにある。

導入時は4段階のプロファイルから選べる。いきなりフル装備じゃなくていい。

プロファイル エージェント スキル 想定ユーザー
Core 6 25 個人開発者・入門
Developer 16 65 チーム開発
Security 22 85 セキュリティ重視
Full 36 147 フル装備
03

ECCの3つの柱——エージェント分業・メモリ永続化・セキュリティ統合

ECCの3つの設計思想

中身を分解すると、3つの柱が見えてくる。

柱1: エージェント分業(36体)

36体のエージェントが、それぞれ専門領域を持つ。コードレビュー専門、テスト専門、セキュリティ監査専門、リファクタリング専門。

私のAIチームも「凸凹」で設計してるんだけど、考え方は近い。万能AIなんていない。得意なことだけやらせて、苦手なところは別のAIに任せる。人間と同じだよね。

柱2: メモリ永続化(SQLite State Store)

AIの最大の弱点は「忘れること」だと思う。セッションが切れたら、前回の文脈がゼロに戻る。

私も最初ここでめちゃくちゃ苦労した。AIに同じことを何度も教え直す日々。月曜に教えたことを、水曜にはもうやってない。

ECCはSQLiteベースのState Storeでセッションをまたいで記憶を保持する。さらに「Instinct System」という仕組みで、信頼度スコア(0.3〜0.9)で学習内容の確度を管理してる。信頼度が低い学習はまだ「仮説」、高いものは「確定知識」として扱う。

私のmothership-labでは、CLAUDE.md + rules/ + memory/ の3層構造で同じことをやってる。アプローチは違うけど、「AIに文脈を忘れさせない」という課題意識は完全に一致してた。

柱3: セキュリティ統合(AgentShield)

「AgentShield」は1,282のテスト、98%のカバレッジを持つセキュリティレイヤー。

セキュリティを「後付け」じゃなくて「組み込み」にしてる設計判断は、正直見習いたいと思った。うちのhookは品質管理中心で、セキュリティ専用のテストスイートはここまで体系化できてない。

ポイント

3つの柱に共通するのは「口頭の注意じゃなくて、仕組みで強制する」思想。プロンプトに「セキュリティに気をつけて」と書くより、テストが自動で走る方が確実。

04

mothership-labとの答え合わせ——同じだったこと、違ったこと

ECCとmothership-labの比較

ここからが本題。

観点 ECC mothership-lab
目的 Claude Codeの最適化(汎用) 事業全体のAIオーケストレーション
エージェント 36体(機能別) 30体(役割別・人格あり)
対象範囲 コーディング特化 コンテンツ・経営判断・健康管理まで
品質管理 AgentShield(テスト1,282) AI憲法7条 + hook 102個
メモリ SQLite State Store CLAUDE.md + rules/ + memory/ 3層
設計哲学 ベストプラクティスをプログラムで強制 凸凹を活かす分業で人間の判断を守る

同じだったこと——「仕組みで品質を担保する」

ECCもmothership-labも、根底にある思想は同じだった。

「AIに口頭で注意するのではなく、仕組みで品質を担保する」。

うちには”AI憲法”がある。7条の掟。たとえば「検証せずに確認したと言うな」「ステップを飛ばすな」。これをルールとして書いただけじゃAIは守らない。hookスクリプトとしてプログラムで強制して、初めて守られるようになった。

ECCもHookとAgentShieldで同じことをやってる。世界の反対側で、同じ結論に辿り着いてた。この発見は嬉しかった。

違ったこと——「汎用最適化」vs「魂のある分業」

最大の違いは設計の出発点

ECCは「Claude Codeのコーディング品質を最大化する」という技術課題から出発してる。だからエージェントの分類は機能別(コードレビュー、テスト、リファクタリング)。

一方、mothership-labは「人間が本当に大事なことに集中するために、AIチームに何を任せるか」という経営課題から出発してる。だからエージェントの分類は役割別で、それぞれに人格がある。

たとえば「分身AIひろくん」は、北極星——「凸凹のまま夢中に生きる」——に照らして判断する役割を持つ。「この判断は私たちの魂に合ってるか?」と問うAI。これはECCにはない概念だと思う。

🍳 料理に例えると

ECCは世界中のシェフが使える最高の厨房設備カタログ。mothership-labは一人の経営者が自分の店で磨いた厨房。どっちが正解って話じゃない。ECCは汎用ツール、mothership-labは専用設計。用途が違うんだよね。

ただ、ECCの設計を見て確信したことが一つある。

「AIの仕事環境を設計する」という行為そのものが、もはやニッチな趣味じゃなくて、本流になりつつある。

05

恥ずかしい話をする——私の失敗の歴史

失敗から学んだこと

ちょっと恥ずかしい話をするね。

最初はCLAUDE.mdに30行くらい書いただけだった。それでも「すごい」と思ってた。「俺のAI、賢くなった」って。

でも1週間使って気づいた——AIは指示を忘れる。毎回同じミスをする。

月曜に教えたことを、水曜にはもうやってない。「確認しました」って言うから信じたら、何も確認してなかった。ルールを書くだけじゃダメで、強制する仕組みが必要だった。

そこからAI憲法7条が生まれた。「検証せずに確認したと言うな」「ステップを飛ばすな」。でもAI憲法だけでもダメだった。

ある日、hookの仕組み自体が壊れてることに気づいた。102個のうち35個が機能してなかった。品質がガタ落ちして初めて気づいたんだよね。この失敗があったから「壊れたら仕組みで直す。”次から気をつける”は禁止」というルールが生まれた。

30体のAIチームは、こういう失敗の積み重ねでできてる。最初から設計図があったわけじゃない。

ポイント

ChatGPTは出前の注文。Claude Codeは自分の惣菜屋の厨房を持つこと。この違いがわかった瞬間から、全部変わった。詳しくはこの記事で書いてる

06

「エンジニアじゃないから関係ない」って思った?

エンジニア以外にも関係ある

ちょっと待ってほしい。

ECCが解決しようとしてる問題は、実はエンジニアリングの問題じゃない。「人間がAIとどう協働するか」の設計問題なんだよね。

🍳 料理に例えると

美味しい料理を作る技術と、スタッフが最高のパフォーマンスを出せる厨房を設計する技術は別物。後者はむしろ経営者やマネージャーの仕事。

実際、Qiitaの記事で、プログラミング未経験の方がClaude Codeを700時間以上動かし続けた記録が公開されてる。コードが書けなくても、「これはダメ」「これはOK」と言葉にするだけで、hookの大部分はAIが自分で書いてくれる。

Before/Afterで見てみよう。

Before:ChatGPTに「ブログ記事書いて」と頼む。出てきたものを手直し。毎回ゼロから指示。品質バラバラ。

After:AIの仕事環境を設計する。NGワード、トーン、品質基準、検証手順を仕組みとして組み込む。AIは毎回同じ品質で仕事をする。人間は「味見」と「方向決め」だけに集中する。

私の場合、164個のスキルがあるから「この記事をラジオ動画にして」と一言言えば、台本作成→ナレーション→動画編集→YouTube投稿まで全自動。最初の設計だけがんばれば、あとは仕組みが回る。

「AIを使う」フェーズは終わった。「AIが働く環境を設計する」フェーズに入ってる。

07

今日から始められる3つのこと

今日から始められるアクション

「面白そうだけど、36エージェント・147スキルは重い……」。わかる。私も最初から30体だったわけじゃない。

1. ECCのCore Profile(6エージェント)から入れてみる

ECCの賢いところは段階的な導入パスを用意してること。Core Profileには、コードレビュー、テスト、基本的な品質チェックの6エージェントが入ってる。

🍳 料理に例えると

いきなりフルキッチンを揃えるんじゃなくて、まず「いい包丁」と「正確な計量スプーン」だけ買う。それだけでも料理の質は変わる。

2. CLAUDE.mdを自分用にカスタマイズする(AIに頼んでOK)

ここが一番大事。ECCはあくまで汎用テンプレート。自分のチーム、自分のプロジェクト、自分の価値観に合わせてチューニングしないと、借り物の厨房のまま終わる。

ちなみに私のCLAUDE.md、自分で書いてない。AI秘書に「こういうルールにして」「ここで事故ったから防いで」って伝えたら、AI秘書が整えてくれたんだよね。実運用で「ここが抜ける」「ここで事故る」を繰り返すたびに、AI秘書がAI憲法7条やhookスクリプトとして仕組み化してくれた。

つまり、CLAUDE.mdを自分で書く必要はない。「何がダメだったか」「どうしてほしいか」をAIに伝えれば、AIが整えてくれる。あなたがやるのは「方向決め」と「味見」だけでいい。

3. 「品質を仕組みで担保する」考え方を身につける

技術的なことよりも、考え方のシフトが大事。

「このAI、ちゃんと仕事してくれないな」と感じた時、プロンプトを書き直すんじゃなくて、「なぜブレるのか」を構造的に考える。そしてルールやhookとして仕組み化する。

この習慣がつけば、ECCを使おうが使うまいが、AIとの協働の質は上がるよ。

FAQ

よくある質問

Q. ECCを使うにはプログラミング経験が必要?
A. Claude Codeの基本操作ができれば使える。インストールコマンド1つで環境に組み込まれるよ。ただし、hookのカスタマイズなど深い使い方をするなら、シェルスクリプトの基礎知識があると楽。
Q. ECCとmothership-labは併用できる?
A. できる。ECCはコーディング品質の最適化に特化してるから、コンテンツ制作や経営判断系の仕組みとは競合しない。実際、ECCのセキュリティテストの仕組みは参考にしたい部分がある。
Q. ChatGPTユーザーでもECCの考え方は使える?
A. 「品質を仕組みで担保する」考え方自体はツールを選ばない。ただしhookやエージェント分業のような仕組みはClaude Code固有の機能。ChatGPTのカスタムGPTでも「指示書の構造化」は応用できるけど、自動強制はできない。
Q. 131,000スターって本当にすごいの?
A. 参考までに、React(Facebookが作ったUI開発フレームワーク)が約23万スター。Claude Code関連のリポジトリで13万スターは異常値。それだけこの課題に共感してる開発者がいるということ。

まとめ——最強のレシピは、自分の厨房で磨いたもの

ECCは現時点で最も包括的な「AIエージェントの仕事環境設計」のオープンソースプロジェクトだと思う。131Kスター、36エージェント、147スキル、1,282セキュリティテスト。

私がmothership-labで独自にやってきたことと、ECCが体系化したことには多くの共通点があった。

  • 「仕組みで品質を担保する」
  • 「ステップを飛ばさせない」
  • 「検証なしの完了報告を許さない」

これは普遍的な設計原則。

大事なのは、ECCをそのまま入れることじゃない。ECCの設計思想を理解した上で、自分の「厨房」を設計すること

AIの凸(計算力・再現性・並列処理)と、人間の凸(判断・情熱・文脈理解)。この凸凹が噛み合う仕組みを作れた人が、AI時代を夢中に生きられる。

少なくとも私は、そう信じて30体のAIチームと毎日厨房に立ってるよ。

上部へスクロール