GitHub15万スターの「AI開発自動化リポジトリ」を、自社のAI開発ルールと比較検証してみた
340件の修正履歴が教えてくれた「本当に効くルール」の作り方
— 340件の修正履歴が教えてくれた「本当に効くルール」の作り方 —
はじめに
先日、X（旧Twitter）で大きな話題になっteiru投稿があります。
「Google歴11年のエンジニアがClaude Codeで業務の80%を自動化。1日2〜3時間の勤務で月$28,000の収入」
この投稿で紹介されていたのが、GitHubで15万スター以上を獲得しているリポジトリ「Everything Claude Code（以下ECC）」です。
47の専門AIエージェント、181のスキル、79のコマンド——これだけ聞くと「導入すれば全部解決するのでは？」と思いますよね。
私も最初はそう思いました。
しかし、実際にClaude Codeを使ってこのリポジトリを徹底分析したところ、意外な結果が出ました。
株式会社IIWAYO.TECHの代表として「BANSOU CTO™」（伴走型フラクショナルCTOサービス）を運営し、独自のAI開発手法「Flow Coding」を構築してきた立場から、率直に比較レポートをお伝えします。
まず、記事の主張を検証してみた
話題の投稿には、いくつかのインパクトのある数値が並んでいました。一つずつ検証します。
「153K+スター」 → 事実。実際にはさらに多い157K+。ここは正確です。
「30+エージェント / 180+スキル」 → むしろ控えめ。実際は47エージェント・181スキルとさらに充実。
ここまでは記事の信憑性を裏付ける結果。しかし、問題はここからでした。
「コンベンション違反率40%→3%」 → 定量的な根拠がありません。どのプロジェクトで、どういう基準で、どう測定したのか一切不明。
「AgentShield 1,282テスト」 → リポジトリ内にAgentShieldのディレクトリが見当たりません。別リポジトリとして存在はしますが、「内蔵」という記事の表現は正確ではありません。
「v2.1.100のトークン水増し問題」 → Claude Codeは「根拠なしの陰謀論」と判定。サーバー側の処理変更をトークン窃盗と結びつける論理に裏付けがありません。
「Karpathyとの関連」 → Karpathy氏本人が作ったものではなく、同氏の発言を元に第三者が作成したルールファイル。権威の借用です。
結論として、リポジトリ自体は高品質。でも、記事のマーケティングが相当に誇大だったということです。
ECCの中身は実際どうなのか
誤解しないでいただきたいのですが、ECCリポジトリそのものは非常によくできています。
1,318コミット、170人以上のコントリビューター、Anthropicハッカソン受賞という実績。Claude Code、Cursor、Codex、OpenCodeなど主要AIツール全てに対応するクロスプラットフォーム設計。MITライセンスでオープンソース。
特に優れていると感じた点は2つあります。
1つ目はHooks（実行タイミングの自動化）。コードを編集した後に自動でチェックが走る、git push前にビルド確認が入る、といった仕組みです。ルールを「書いておく」だけでなく「自動で発動させる」という考え方は、人間の注意力に依存しない品質管理を実現します。
2つ目は自律実行の安全制御。AIが暴走しないためのループ安全ゲート（同一エラー3回で停止、1ラウンド20ファイル上限など）は、実運用では極めて重要です。
では、なぜ「自社ルールの方が上」と言えるのか
ここからが本題です。
私のFlow Codingでは、claude.aiで設計→Lovableで実装→Claude Codeで検証、という3段階パイプラインの中で、340件以上の修正履歴から帰納的にルールを構築してきました。
Claude Codeにこの2つのシステムを比較分析させた結果、明確な差が出ました。
自社の方が優れていた点
チェックコマンド体系の精度。
私のシステムでは、A〜Iのパターン分類による19種のチェックコマンドを持っています。「過去にこう壊れたから、こう防ぐ」という実証データに基づくルールです。
ECCのルールは「こうすべき」という演繹的な理想論。私のルールは「こう壊れた」という帰納的な事実。この差は、実際にプロジェクトを動かしたときに如実に現れます。
Supabase/RLS特化ルール。
ECCにはPostgreSQLの汎用パターンはあります。しかし、Lovable + Supabase構成で実際に発生するRLSの落とし穴——たとえば匿名ユーザーのアクセス制御やEdge FunctionでのSERVICE_ROLE_KEY使用時の注意点——に特化したルールはありません。
私のルールは、実際にRLSの設定ミスでヒヤリとした経験から作られています。
340件の修正履歴に基づく実証。
ECCの181スキルは「理論から導いた正解」。私の19チェックコマンドは「340回の失敗から蒸留した正解」。どちらが現場で効くかは、システム開発の経験者なら直感的にわかるはずです。
ECCの方が優れていた点
先述の通り、Hooks（自動実行の仕組み）と安全制御（ループ防止）。
これは「ルールの質」の問題ではなく「ルールをいつ・どう発動させるか」の仕組みの話です。ここはECCに学ぶべき点があると素直に認め、自社のシステムにも取り入れました。
具体的には、Edit/Write後の300行超過自動検出、確信度閾値（CRITICAL 90%/HIGH 80%/MEDIUM 70%）の導入、同一エラー3回で停止するループ安全ゲート。これらをECCの思想を参考に、自社のルール体系に統合しています。
「有名なツールを入れれば解決」という幻想
この比較を通じて改めて確信したことがあります。
AIツールの世界では、「15万スターのリポジトリを入れれば開発が自動化される」「このプロンプト集を使えば品質が上がる」といった話が溢れています。しかし、現実はそう単純ではありません。
ECCのREADME自体が警告していますが、全コンポーネントを入れるとClaude Codeの200Kコンテキストウィンドウが70Kまで縮小します。つまり、「全部入り」にした瞬間、AIの理解力が65%低下するのです。
本当に効くのは、自社の開発現場で実際に起きた問題から作られた、必要最小限の、的確なルールです。
「AIセミナーの先」にあるもの
今、多くの企業がAIセミナーに参加し、最新ツールの情報を集めています。それ自体は素晴らしいことです。
しかし、入口で止まっている企業が多すぎるのが現実です。
「すごいツールがある」と知ること。「自社の現場でどう使うか」を設計すること。この2つの間には、想像以上に大きな溝があります。
15万スターのリポジトリも、340件の修正履歴から生まれたルールも、どちらも「道具」にすぎません。大事なのは、自社の業務にどう落とし込むか——その翻訳者がいるかどうかです。
BANSOU CTO™は、まさにその「翻訳」を行うサービスです。技術の最前線を理解した上で、御社の現場に合った形に変換する。15万スターの汎用ツールではなく、御社だけの「340件」を一緒に積み上げていく。
それが、AIを本当に経営に活かすということだと考えています。
株式会社IIWAYO.TECH 代表取締役 伊藤翔太 BANSOU CTO™ — AIを「入口」で終わらせない、伴走型フラクショナルCTOサービス
次に読むおすすめ
- 「「システム会社に頼むのは、もうやめたほうがいい」——中小企業のシステム内製化が、いま現実解になった理由」
- 「AIで700万行のコードを生成した「バイブコーディング」とは何か。従来の26年分の工数を4ヶ月で実現した開発手法の全貌」
- 「AI開発ツールで電子契約システムを作って壁にぶつかった話 〜Claude Opusと一緒に解決した全記録〜」