はじめに - Everything Claude Codeとは

Everything Claude Code (ECC)

Everything Claude Code (ECC) は、Claude Codeの完全な設定コレクションです。その本質は単なる「設定集」ではありません。

ECCが提供するのは、開発の完全なPDCAサイクルを体験できる環境です。

Plan (計画)
├─ リサーチ（問題理解、技術調査）
├─ アーキテクト（システム設計）
└─ プラン（実装計画）
    ↓
Do (実行)
├─ TDD（テスト駆動開発）
└─ 実装（Vibe Coding）
    ↓
Check (検証)
├─ コードレビュー
├─ テスト実行
└─ セキュリティチェック
    ↓
Act (改善)
├─ ドキュメント更新
└─ 次のサイクルへ

このリポジトリの作者、Affaan Mustafa氏は、2025年9月に開催されたAnthropic x Forum Ventures hackathonで、Claude Codeを使ってzenith.chatをわずか8時間で構築し、$15,000相当のAPIクレジットを獲得して優勝しました。

ECC は、agents (15+)、skills (30+)、commands (30+)、rules、hooksで構成されています。重要なのは、これらが開発の一気通貫したフローを実現していることです。

Vibe Coding時代の開発

AI時代以前、コーディング（実装）に時間がかかっていました。しかし、Vibe Coding時代（Claude Code、Cursor等）では、実装は高速化しました。

では、何が重要になったのか？

それは、開発の全体フローです。従来はこのフローを経験できるのは、一部の限られたマネジメント層だけでした。

ECCは、この一気通貫の開発体験を、誰でも、10日間で体験できるようにします。

参考:

私の出発点

私は趣味でPythonを少し書く程度のプログラミング初心者でした：

gitって何？というレベル
本格的なアプリ開発の経験なし
テストも書かない、ドキュメントもない
バージョン管理という概念すら知らない

そんな私が、2026年1月末にポッドキャストでEverything Claude Codeを知り、初めて本格的な開発を始めました。

10日間で体得したこと

Everything Claude Code環境で開発を始めてから10日間で、私が体得したのは個別のスキルではありません。

開発の完全なPDCAサイクルを、何度も何度も回す経験でした：

問題をどう理解するか（リサーチの方法）
システムをどう設計するか（アーキテクトの思考法）
実装をどう計画するか（プランニングの技術）
品質をどう保証するか（TDD、コードレビュー）
知識をどう蓄積するか（ドキュメント駆動）

「比較対象がない」という特異性

多くの開発者は、従来の開発環境からClaude Codeに移行します。そして、「効率化された」「開発が速くなった」と実感するでしょう。

私の場合は違います。ECC環境が私の開発の「普通」です。

従来の開発環境も、手作業でのgit操作も、一切経験していません。開発者として最初の一歩を踏み出したとき、すでにEverything Claude Code環境でした。

比較対象がないため：

「計画は面倒」という抵抗感がない
「テストは後回し」という悪習がない
「ドキュメントは負債」という先入観がない
PDCAサイクルを回すのが当たり前

私にとって、リサーチ→アーキテクト→プラン→実装→レビュー→ドキュメントという一気通貫のフローが、開発の「普通」です。

この環境で私が取った学習アプローチは、しつこく質問しまくることでした。

「ECC効果など感じることはない。なぜならECC以外の枠組みを知らないから」

これが、私が10日経って気づいた逆説的な事実です。そして同時に、良い学習環境で開発を始められたということでもあります。

Spotifyポッドキャストから始まった

きっかけ（2026年1月末）

ある日、Spotifyであるポッドキャストを聴きました。尾原和啓氏といけとも氏の対談でした。

いけとも氏がEverything Claude Code (ECC) について語る内容を、私は集中して聴きました。

「これは使えるかもしれない」

そう判断し、ポッドキャストを聴き終わった後、すぐにECCを導入することにしました。

Youtubeで学習

次に、いけとも氏のYoutube動画を見つけました。

この動画を注意深く視聴しました：

メモを取りながら再生
理解できない部分は何度も巻き戻し
使用法を学習

Youtubeでの学びは単なる概念理解ではなく、具体的な使い方までカバーしていました。これが後の導入をスムーズにしてくれました。

NotebookLMで情報収集

次に、NotebookLMを使ってECCに関する情報を集めました：

いけとも氏のポッドキャストの内容
Youtube動画の内容
ECC開発者のページ
GitHub README・ドキュメント
ECC関連情報

NotebookLMに情報を集約することで、ベストプラクティスを探ることができました。

手動ダウンロードの落とし穴

私はコマンドラインツール（CLI）に慣れていなかったため、GitHubから手動でZIPファイルをダウンロードしました。

しかし、ここで重大なミスを犯しました。

誤配置: ~/MyAI_Lab/.claude/ に全ファイルを配置してしまったのです。

本来は ~/.claude/（ユーザーホーム直下）に配置すべきでした。

間違った配置:
MyAI_Lab/.claude/
├── rules/
├── skills/
├── agents/
├── README.md
├── LICENSE
└── .gitignore

正しい配置:
~/.claude/ (ユーザーレベル) ← rules/skills/agentsはここ
MyAI_Lab/.claude/ (ワークスペース) ← settings.local.jsonのみ
<project>/.claude/ (プロジェクト) ← settings.local.jsonのみ

この誤配置により、全プロジェクトが同じ設定を強制的に共有することになり、プロジェクトごとの柔軟な設定ができない状態でした。

10日間の開発

2026年1月31日〜2月7日の10日間、私はこの誤った配置のまま開発を続けました。

次第に「プロジェクトごとに異なる設定をしたいのにできない」という問題に気づき始めました。

修正フェーズ（2026年2月7日〜8日）

公式ドキュメントとGitHub issuesを読み直し、ECCの階層構造（ユーザー > ワークスペース > プロジェクト）の真の意味を理解しました。

修正作業：

決断: MyAI_Lab/.claudeからの移行を決意
移動: ~/.claude/ にrules/skills/agentsを移動
削除: MyAI_Lab/.claude/からrules/skills/agentsを削除
整理: MyAI_Lab/.claude/には settings.local.json のみ残す
クリーンアップ: 不要なGitHub関連ファイル（README、LICENSE等）を削除

失敗から学ぶ

この10日間の配置ミスは、結果的に学習機会でした：

RTFM (Read The Fing Manual)*: 公式ドキュメントを最初に読むべきだった
階層構造の理解: ユーザー/ワークスペース/プロジェクトの役割分担
実践から学ぶ: 10日間の開発を通じて問題に気づき、修正

比較対象がないため、失敗を恐れずに試行錯誤できました。この経験がなければ、ECCの階層構造を理解することはできなかったでしょう。

ECCの本質 - 開発のPDCAサイクル

従来は限られた層だけが経験できた

開発の全体フローを経験できるのは、従来は一部の限られたマネジメント層だけでした：

新人は「実装」だけを担当
中堅は「設計と実装」を担当
シニアが「計画から検証まで」を担当
マネージャーだけが「全体フロー」を経験

開発者がこの全体フローを経験するには、数年〜10年のキャリアが必要でした。

ECCがもたらす民主化

ECCは、この開発の完全なサイクルを、誰でも、短期間で、何度も回せるようにします。

このPDCAサイクルは、ソフトウェア開発に限りません：

ビジネス: 市場調査→戦略立案→実行→効果測定→改善
研究: 文献調査→仮説構築→実験→検証→論文執筆
デザイン: リサーチ→コンセプト→プロトタイプ→ユーザーテスト→改善

ECCで開発を学ぶことは、仕事の本質を学ぶことに他なりません。

わからないことを全部聞きまくった - 学習の本質

最初は全ての用語がわからなかった

「gitって何ですか？」
「コミットって何ですか？」
「ADRって何ですか？」
「TDDって何ですか？」
「カバレッジって何ですか？」

これが、私のECC導入初日の質問リストです。

聞いたことがない言葉があるたびに、しつこく質問しました。

Claude Codeが何か提案してくる度に、わからない言葉があれば即座に質問。回答を受けて、さらに質問。この繰り返しでした。

納得するまで質問し続けた

Claude Codeの提案を鵜呑みにしたわけではありません。常に以下のような疑問を持ち続けました：

なぜそうするのか？
他の方法はないのか？
この用語の意味は？
この設計の背景は？

こうして、納得するまで質問し続けました。

マルチLLM活用戦略（4段階）

Claude Codeだけでは足りないとき、私は複数のLLMを使い分けました。

1. Claude Codeに質問

まず、開発中に出てきた用語や概念をClaude Codeに質問します。

me: 「gitって何ですか？」
Claude Code: 「gitはバージョン管理システムです...」

しかし、Claude Codeの回答はそっけないときもあります。開発に特化したエージェントなので、教育的な説明が不十分なこともありました。

2. Gemini/通常のClaudeに質問

Claude Codeの回答が不十分だと感じたとき、GeminiやClaude（通常版）に同じ質問をします。

me: 「gitとは何か、初心者にわかりやすく説明してください」
Gemini: 「gitは、ファイルの変更履歴を記録するツールです。例えば...」

より詳しい説明、丁寧な例示、初心者向けの解説が得られます。

3. 「グラップラー刃牙に例えて説明して」

それでもわからないとき、工夫しました。

me: 「TDD（テスト駆動開発）をグラップラー刃牙に例えて説明してください」
Claude: 「TDDは、まず『相手の技を想定』してから『対策を練る』ようなものです。
刃牙が戦う前に...」

漫画やアニメの例えで説明してもらうことで、理解が深まりました。

4. ディープリサーチ

徹底的に調査したいとき、複数のLLMに同じ質問を並行投下します。

Claude Code: 実践的な使い方
Gemini: 概念の詳細説明
ChatGPT: ベストプラクティス
NotebookLM: 関連記事・ドキュメントの統合

この4段階アプローチで、難しい概念も理解できるようになりました。

具体的な学びの瞬間

gitを理解した瞬間

最初は「コミット」の意味すらわかりませんでした。

しかし、Claude Codeと一緒に初めて git commit を実行したとき：

git add src/main.py
git commit -m "feat: Add initial implementation"

「ああ、これが『変更を記録する』ということか」と理解しました。

バージョン管理という概念を初めて体験しました。

ADRの価値に気づいた瞬間

あるプロジェクトで、重要なアルゴリズム選択を行う決断をしました。

Claude Codeが「ADRを書きましょう」と提案してきました。

me: 「ADRって何ですか？」
Claude Code: 「Architecture Decision Recordです。重要な意思決定を記録します」
me: 「なぜ必要なんですか？」
Claude Code: 「将来、なぜその決断をしたのか思い出せなくなるからです」

この説明で、私は「ドキュメント駆動開発」の価値を理解しました。

そして、ADRを書きました：

# ADR-002: アルゴリズム選択

## Status
Accepted

## Context
アルゴリズムAからアルゴリズムBに移行する。
理由: Bはより精度が高く...

このADRは、後続のプロジェクトでも参照され、知識の再利用につながりました。

TDDでテストが通った瞬間

あるプロジェクトで、初めてテストを先に書くことに挑戦しました。

# 最初にテストを書く（RED）
def test_extract_text():
    result = extract_text("sample.txt")
    assert len(result) > 0

# 次に実装を書く（GREEN）
def extract_text(file_path: str) -> str:
    # 実装...

テストを実行して、PASSED が表示されました。

「なるほど、これがTDDか」と納得しました。

リファクタリングしても、テストが通れば安心。この安心感がTDDの価値だと理解しました。

結果: すごい知識がついた

この「しつこく質問する」学習プロセスを10日間繰り返した結果、例えば：

gitワークフロー: コミット、ブランチ、マージ
TDD: テスト駆動開発
ADR: アーキテクチャ決定記録
ライセンス: AGPL-3.0等の違いと選択基準
E2Eテスト: Playwrightでの検証
型チェック: 型安全性

これらは序の口に過ぎません。実際には、ほぼ全ての開発用語を10日前には知りませんでした。

「しつこく質問する」ことで、多くを学びました。

10日間の学び - PDCAサイクルの体得

10日間で複数のプロジェクトに取り組む中で、PDCAサイクルが加速していくのを実感しました。

初めてのフルサイクル体験

最初のプロジェクトで、Plan→Do→Check→Actという一気通貫のフローを初めて体験しました：

Plan: 技術調査、アーキテクチャ設計、実装計画
Do: TDDでテストを先に書き、Vibe Codingで高速実装
Check: コードレビュー、テスト実行、品質チェック
Act: ADRで意思決定を記録、ドキュメント整備

サイクルの高速化

前回の学びを活かし、次のプロジェクトではサイクルが速く回りました：

前回の知見を再利用（アーキテクチャパターン、テスト戦略）
E2Eテストを含む包括的なテスト戦略
セキュリティレビューの習慣化

サイクルの洗練

3つ目のプロジェクトで、より洗練されたサイクルを実現できました：

堅実な計画主義: 実装前に詳細仕様をドキュメント化
不変性の原則: frozen=True で予期しない変更を防ぐ
包括的なドキュメント: ADR、CONTRIBUTING.md、RUNBOOK.md、README完備

共通するパターン

プロジェクトを通じて見えてきた本質：

計画の重要性 - 「いきなりコードを書かない」が当たり前に
TDDの価値 - テストを先に書き、安心してリファクタリング
レビューの徹底 - agentを活用した品質・セキュリティチェック
ドキュメント駆動 - 学びを蓄積し、次のサイクルへ

ECC環境が「当然のこと」として提案してくれ、私はしつこく質問しながら、その価値を理解していきました。

感謝

このSpotifyポッドキャストがなければ、私はECCと出会うことはありませんでした：

いけともさんのYoutube動画で具体的な使い方を学びました：

Before: gitも知らない趣味プログラマー
After: 開発の完全なPDCAサイクルを体得

この10日間の変化は、お二人の情報発信がなければ起こりませんでした。

この記事では、失敗談（配置ミスで10日間）も正直に書きました。次の誰かが同じ失敗をしないために。

おわりに

「比較対象がない」という特異点。

その特異点を活かせたのは、しつこく質問しまくったからです。

わからない言葉があるたびに質問し、納得するまで掘り下げる。この繰り返しが、10日間で多くの学びをもたらしました。

gitも知らなかった初心者が、今ではこうしてZennに技術記事を書いています。

学んだのは「git」という個別スキルではなく、開発の完全なPDCAサイクルでした。

これは奇跡ではありません。Everything Claude Codeという学習環境と、しつこく質問する姿勢があったからです。

次回予告

後編では、この10日間で到達した「エコシステム設計者」への道を明かします。

メタ認知の発動（「開発記録をコンテンツ化できる」という気づき）
マルチLLMディープリサーチの高度な活用
ECC Architectエージェント活用（システム設計からSkill化まで）
エコシステムの全体像（入力→処理→出力→フィードバック）

お楽しみに！

この記事が役に立ったら、「いいね」と「ストック」をお願いします。

#EverythingClaudeCode #ECC #ClaudeCode #BuildInPublic