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つのアクション
「すごいのに不安定」——みんな同じ壁にぶつかってる
AIコーディングエージェントを使い始めて、こんな経験ない?
同じ指示を出してるのに、昨日と今日で全然違うものが出てくる。ベストプラクティスを無視する。セキュリティの穴を開けてくる。「確認しました」って言うから信じたら、何も確認してなかった。
私もめちゃくちゃ苦労した。30体のAIチームを動かしてる今でさえ、油断するとAIは同じことをやる。
腕のいいシェフを雇ったのに、厨房がグチャグチャで毎日味がブレてる状態。レシピ(プロンプト)だけじゃ足りない。厨房そのものを設計しないと、安定した料理は出てこないんだよね。
ECCの公式READMEにもこう書いてある。
“AI coding agents are powerful but inconsistent.”
(AIコーディングエージェントはパワフルだが不安定)
適切なガイダンスなしでは、ベストプラクティスを無視し、セキュリティの穴を作り、信頼できないコードを吐く——と。まさにそれ。世界中で同じ壁にぶつかってたんだよね。
ちなみにForbes JAPANの報道によると、ChatGPTからClaudeへの乗り換えが1487%増。この流れとも無関係じゃないと思う。Claude Codeを使い始めた人が増えたからこそ、「使い方のガイドが欲しい」というニーズが爆発した。
AIの「使い方」じゃなくて「働く環境」を設計する。ECCが13万スターを集めたのは、世界中の開発者がこの課題の重要性に気づいたから。
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 | フル装備 |
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つの柱に共通するのは「口頭の注意じゃなくて、仕組みで強制する」思想。プロンプトに「セキュリティに気をつけて」と書くより、テストが自動で走る方が確実。
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の仕事環境を設計する」という行為そのものが、もはやニッチな趣味じゃなくて、本流になりつつある。
恥ずかしい話をする——私の失敗の歴史
ちょっと恥ずかしい話をするね。
最初はCLAUDE.mdに30行くらい書いただけだった。それでも「すごい」と思ってた。「俺のAI、賢くなった」って。
でも1週間使って気づいた——AIは指示を忘れる。毎回同じミスをする。
月曜に教えたことを、水曜にはもうやってない。「確認しました」って言うから信じたら、何も確認してなかった。ルールを書くだけじゃダメで、強制する仕組みが必要だった。
そこからAI憲法7条が生まれた。「検証せずに確認したと言うな」「ステップを飛ばすな」。でもAI憲法だけでもダメだった。
ある日、hookの仕組み自体が壊れてることに気づいた。102個のうち35個が機能してなかった。品質がガタ落ちして初めて気づいたんだよね。この失敗があったから「壊れたら仕組みで直す。”次から気をつける”は禁止」というルールが生まれた。
30体のAIチームは、こういう失敗の積み重ねでできてる。最初から設計図があったわけじゃない。
ChatGPTは出前の注文。Claude Codeは自分の惣菜屋の厨房を持つこと。この違いがわかった瞬間から、全部変わった。詳しくはこの記事で書いてる。
「エンジニアじゃないから関係ない」って思った?
ちょっと待ってほしい。
ECCが解決しようとしてる問題は、実はエンジニアリングの問題じゃない。「人間がAIとどう協働するか」の設計問題なんだよね。
美味しい料理を作る技術と、スタッフが最高のパフォーマンスを出せる厨房を設計する技術は別物。後者はむしろ経営者やマネージャーの仕事。
実際、Qiitaの記事で、プログラミング未経験の方がClaude Codeを700時間以上動かし続けた記録が公開されてる。コードが書けなくても、「これはダメ」「これはOK」と言葉にするだけで、hookの大部分はAIが自分で書いてくれる。
Before/Afterで見てみよう。
Before:ChatGPTに「ブログ記事書いて」と頼む。出てきたものを手直し。毎回ゼロから指示。品質バラバラ。
After:AIの仕事環境を設計する。NGワード、トーン、品質基準、検証手順を仕組みとして組み込む。AIは毎回同じ品質で仕事をする。人間は「味見」と「方向決め」だけに集中する。
私の場合、164個のスキルがあるから「この記事をラジオ動画にして」と一言言えば、台本作成→ナレーション→動画編集→YouTube投稿まで全自動。最初の設計だけがんばれば、あとは仕組みが回る。
「AIを使う」フェーズは終わった。「AIが働く環境を設計する」フェーズに入ってる。
今日から始められる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との協働の質は上がるよ。
よくある質問
- 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チームと毎日厨房に立ってるよ。





