「プロジェクトをまたいでも品質基準を一定に保ちたい」——そんな課題を感じたことはないでしょうか。

私たちは最近、Webアプリの新規開発プロジェクトにおいて、Claude Code に everything-claude-code を組み合わせることで、Rulesを活用したチーム全体のアウトプット品質の統一を進め、あわせて設計判断を含む工程の自律化にも段階的に取り組んでいます。

本記事では、その導入構成・設計思想・実際の開発フローを紹介します。

対象読者: Claude Codeをチーム開発に活用しており、品質の統一や設計判断の自律化に課題を感じているエンジニア

私がこの導入を主導した背景には、チームの多様性をいかしながら、クライアントへの一貫した品質を担保したいという課題意識があります。

私たちのチームは、異なる強みを持つメンバーで構成されています。高い品質基準を組織として再現性高く提供するためには、担当者に依存しない仕組みが必要です。また、プロジェクトの規模や局面によって体制が変わる場面でも、設計判断の質を落とさずに自律的に動ける開発チームを目指しています。

everything-claude-codeの導入はこの課題に対する技術的なアプローチです。Rulesによりコーディング規約・レビュー基準・コミットフォーマットをチーム全体で統一することで、誰が実装しても同じ品質基準のアウトプットを実現します。また、設計判断を @architect エージェントに委ねることで、自律的に上流工程を進められるように段階的に取り組んでいます。

everything-claude-code（2026年5月時点で186,000スター獲得）は、Claude Codeをさらに強化するための非公式設定集です。Anthropicが提供するClaude Code本体とは別に、コミュニティが開発・公開しているサードパーティ製ツールです。

主な構成要素は以下のとおりです：

公式が推奨するプラグインインストールを使う場合は、以下のコマンド一発で導入できます。

# マーケットプレイスを追加
/plugin marketplace add https://github.com/affaan-m/everything-claude-code
# プラグインをインストール
/plugin install everything-claude-code@everything-claude-code

手動でインストールする場合は、リポジトリをクローンして依存パッケージをインストールした後、必要なファイルをディレクトリ単位でコピーします。ファイル名の衝突を防ぐため、* で展開せずディレクトリごとコピーするのが公式推奨です。

git clone https://github.com/affaan-m/everything-claude-code ~/ecc
cd ~/ecc
npm install
mkdir -p ~/.claude/rules ~/.claude/skills
cp -r ~/ecc/rules/common ~/.claude/rules/
cp -r ~/ecc/rules/php ~/.claude/rules/
cp -r ~/ecc/skills/laravel-patterns ~/.claude/skills/
cp -r ~/ecc/skills/laravel-tdd ~/.claude/skills/

これらを ~/.claude/ 配下の適切なディレクトリに配置することで有効になります。なお、プラグイン方式と手動方式で手順が異なるため、導入前に公式READMEを必ず確認してください。

everything-claude-codeは全機能を一括導入するのではなく、プロジェクトの実情に合わせて必要なものを選んで使っています。現在の導入構成は以下のとおりです。

Rules（10種） — Claude Codeの挙動を常時制御するルールセット

Skills（2種） — スラッシュコマンドとして呼び出せる Laravel 特化スキル

Agents（1種・個人導入） — @エージェント名 で呼び出す専門エージェント

Memory（プロジェクト固有） — ~/.claude/projects/*/memory/ に蓄積される会話横断の記憶

プロジェクト概要・PR作成ルール・先方への報告スタイルなどをメモリファイルとして保存しています。新しいセッションを開始しても、Claude Codeがこれらを参照することで文脈の再説明が不要になります。

everything-claude-code の構成要素は、単なる機能の違いだけでなく、チームの統制と個人の自由度をどう分けるかという設計思想に直結しています。

Rulesは全会話に自動で適用されるため、チームの合意事項を強制する仕組みとして機能します。コミットメッセージのフォーマット・テストカバレッジの基準・コードレビューのチェックリストなど、「全員が守るべきこと」をRulesに集約することで、Claude Codeの挙動がメンバー間でブレなくなります。

laravel-patterns や laravel-tdd などのSkillsは、Laravelの設計パターンやTDD手順をコマンド一発で呼び出せる形にまとめたものです。Rulesのように強制はされませんが、いつでも /laravel-tdd と打てば手順が展開されます。フレームワーク固有の知識をSkillsとして持っておくことで、実装の迷いをその場で解消できます。

Agentsは独立したコンテキストを持ち、コードベースを自律的に調査した上で専門的な回答を返します。ただし、すべてのメンバーが同じAgentsを必要とするわけではありません。本プロジェクトでは @architect を個人の判断で導入していますが、チームへの強制はしていません。「アーキテクチャの相談をしたい人が使う」という選択肢として置いておくことで、チームの統制（Rules）と個人の自由（Agents）を両立させています。

@tdd-guide のような専門エージェントは、毎回同じ手順を繰り返す場合のみ .md ファイルとして作成する価値があります。「この機能だけテストファーストで進めたい」という一時的な用途なら、会話内で直接指示するだけで十分です。エージェントファイルは「繰り返す手順を自動化するもの」と捉えると、作成すべきかどうかの判断がしやすくなります。

今回のプロジェクトはLaravel + Blade（Tailwind CSS）のスタックで構成されています。以下に、実際の開発でClaude Codeをどう使ったかを紹介します。

今回は実装の順序を入れ替えたい事情があったため、「何から着手すべきか」をClaude Codeに確認しています。

「先にCSV取り込み機能を実装することって可能ですか？」と質問すると、

Claude Codeは実装計画書・モデル定義・サービス層を参照した上で依存関係を整理して回答します

## B3-5 の依存関係

| 必要なもの               | 状態             |
|------------------------|-----------------|
| d_applications テーブル  | 完了             |
| d_application_answers   | 完了             |
| Application モデル       | 完了             |
| ReviewService（点数計算）| B3-2 未実装      |

B3-5 の仕様に「点数自動計算」が含まれているため、
B3-2（ReviewService）も一緒に実装する必要があります。

推奨順序: B3-2（計算ロジック）→ B3-5（CSV取込）→ B3-3/B3-4（UI）

「先にやりたい」という要望に対して、単に「できます/できません」で返すのではなく、依存関係を整理した上で現実的な実装順序を提示してくれる点が実用的です。

コーディングは development-workflow.md に記述したフローに従い、Claude Codeが自動的に以下の手順で進めます

1. テストファイルをまず作成（RED）
2. サービス・コントローラ・フォームリクエスト・Bladeを順番に実装（GREEN）
3. code-review.md のルールに基づいてコードレビューを実施
4. 指摘事項を修正してコミット

今回のCSV取込実装では、以下のファイルがこの順序で作成されました

### RED（テスト先行）
tests/Unit/Services/ApplicationImportServiceTest.php  ← 10テストを先に作成

### GREEN（実装）
database/migrations/..._add_application_field_to_m_questions_table.php
app/Services/ApplicationImportService.php
app/Http/Controllers/Admin/ApplicationImportController.php
app/Http/Requests/ImportApplicationRequest.php
resources/views/admin/applications/import.blade.php

コードレビューでは code-review.md の基準に従い、以下の指摘が自動検出されました

[HIGH] DB::transaction() なし
  → 複数テーブル（sectionScores・Review）への書き込みが原子的でない
  → DB::transaction() で全操作を囲むよう修正

[HIGH] ループ内 updateOrCreate() による N+1 クエリ
  → CSV一括取込時にセクション数 × SELECT+INSERT/UPDATE が発生
  → upsert() に変更して一括処理に修正

これらはマージ前に修正完了しています。ルールファイルに基準を書いておくだけで、毎回同じ観点でのレビューが走ります。

新機能の設計判断が必要な場合は @architect に委ねます。

今回は Google Form の CSV を質問マスタ（m_questions）へマッピングする方式の選定で活用しました

「@architect Google Form CSVの列を質問マスタにマッピングする方式として
A案（ヘッダーテキスト照合）とB案（sort_order順）を検討しています。
技術的なリスクと推奨案を教えてください。」と質問すると、

エージェントはコードベースの m_questionsスキーマ・実際のCSVデータ・既存の実装を自律的に調査した上で判断を返しました

## 推奨：B案（sort_order順マッピング）

A案（ヘッダーテキスト照合）のリスク:
- 「その他」が複数列に存在するため、
  ヘッダーテキストによる一意特定が不可能
- Googleフォームの設問文変更で即座にマッピング破綻が起きる

B案（sort_order順）の利点:
- チェックボックス回答がカンマ区切りで1セルに収まるため列ずれが発生しない
- 管理者が sort_order を意識して質問を登録する運用で完結する

設計の一次判断をエージェントに任せることで、検討スピードが上がりました。

git-workflow.md のルールにより、コミットメッセージのフォーマット（feat:, fix: など）が自動的に統一されます。PRの作成も自然言語で依頼するだけで、差分をもとにタイトルと説明を生成してくれます。

メモリファイル（~/.claude/projects/*/memory/）にプロジェクト固有の背景・決定事項を蓄積しておくことで、「なぜこの設計にしたか」をClaude Codeが把握した上で実装を進めてくれます。本プロジェクトでは累計26PRの開発を進めていますが、1PRあたり3分かかっていたセッション開始時の文脈共有がほぼ不要になりました。担当者の感覚ベースではありますが、累計で数時間単位の工数削減につながっています。

マイグレーションファイル・ファクトリ・ユニットテストの骨格など、パターンが決まっている作業はほぼClaude Codeに任せられます。こちらも感覚ベースとなりますが、従来1PRあたり約2時間かかっていたこれらの作業が数分程度まで短縮でき、累計26PRで換算すると累計で数十時間規模の工数削減につながっています

コードレビュールールをファイルとして持つことで、「大きすぎる関数（50行超）」「ネストが深すぎる条件分岐」などを毎回レビュー指摘として受け取れます。レビュアーによる指摘ムラが削減されました。

everything-claude-codeはMITライセンスで公開されているサードパーティ製ツールです。AgentsやSkillsはコード操作やコマンド実行を自律的に行うため、~/.claude/ に配置する前に、導入対象のRules・Skills・Agentsの .md ファイルの内容を読み、意図しない挙動が含まれていないかを確認した上で使用することを推奨します。全機能を一括導入するのではなく、本プロジェクトのようにプロジェクトの実情に合わせて必要なものを選んで導入するアプローチが現実的です。

Claude Codeのコンテキストウィンドウは有限です。長時間のセッションでは圧縮が走り、過去の判断が参照できなくなることがあります。重要な決定事項はメモリファイルやコミットメッセージに残しておく運用が不可欠です。

Claude Codeは非常に高精度ですが、業務ドメインの暗黙知（「この項目はnullにできない」など）は事前にインプットしなければ考慮されません。生成コードをそのまま使うのではなく、必ずエンジニアが確認する前提で運用することを推奨します。

デフォルトのルールはあくまで汎用的な設定です。プロジェクト固有の規約（命名規則・テスト方針・コミットメッセージフォーマット）は必要に応じてカスタマイズする必要があります。

Claude Code + everything-claude-code の組み合わせは、「AIがコードを補完するツール」から「AIがワークフロー全体に参加するチームメンバー」へという使い方を実現します。現時点では、Rulesによるコーディング規約・レビュー基準の統一が主軸であり、@architectによる設計判断の自律化はその補完として段階的に取り組んでいます。

導入コストは設定ファイルの配置のみで、すぐに効果を体感できます。Rulesを置くだけでClaude Codeの挙動が統一され、Memoryを育てていくことで会話を跨いだ文脈の維持も可能になります。

まずはRulesだけ導入してみることをおすすめします。最初の「これは便利だ」という体験が、チーム全体への展開を後押しする一番の近道です。