ClaudeCode ~AIのコードレビューが『教科書的』なのは、あなたのチームを知らないから~
優秀なエンジニアが1人いても、その人の判断軸がチームに広がらなければ、プロダクトは属人化したままです。かといって「レビューで止める」だけでは、手戻りコストが積み上がっていく——この課題感は、私たちが中小企業のDX支援をしてきた現場でも、自社開発でも繰り返し感じてきたものでした。
Claude Code 用のプラグイン
そこで作ったのが、Claude Code 用のプラグイン claude-engineer です。チームメンバーの「考え方の癖」を分身としてAIに持たせ、設計・実装・レビューに参加させる——この仕組みで何が変わるのか、以下に書いていきます。
https://github.com/etsurouwatanabe-tech/claude-engineer
「分身」という発想
claude-engineer では、プロジェクトの `.engineer/team/` にチームメンバーを Markdown で定義します。
まず自分の分身を作ります。過去にやったPRレビューのコメントや、Slack での技術議論を Claude に読ませて、こう頼むだけです。
自分のPRレビューコメントとSlackの技術議論を分析して、
team/sato.md にメンバー定義を作って。
レビューの癖、よく出る指摘、設計の好み、判断基準をまとめて。出てくるのは、こういうファイルです。
# 佐藤（リードエンジニア）
## レビューの特徴
- 共通リポジトリへの影響を最初に確認する
- Service への切り出しを好む。Action が太ると必ず指摘する
- データ移行とコード変更は絶対に別 PR にさせる
## よく出る指摘
- 「この処理、共通側に置いた方がよくない？」
- 「トランザクション張らなくて大丈夫？」
- 「テストの前提条件が暗黙的。Factory で明示して」
## 過去に踏んだ地雷
- Enum を個別リポに書いて、共通化するとき全リポ修正が発生した
- null 許容カラムを追加して、既存データの null が予期しない挙動を起こした
- Job の失敗時にリトライが効かない設計にして、深夜に手動リカバリした自分のレビューの癖が、言語化されます。 これがまず面白い。普段無意識にやっていることが明文化されて、「あ、自分こういう観点で見てたんだ」と気づく瞬間があります。
分身の「材料」は3つ
私は直近1年分のデータを食わせました。データソースは3つあります。
1. Slack の技術議論
一番リッチなデータソースです。設計相談、障害対応、レビューの背景——「考え方の癖」が一番出るのがここです。Slack MCP を入れていれば、こう頼むだけでいい。
自分の直近1年の #dev チャンネルでの発言を検索して、
技術議論・設計判断のメッセージを分析して team/自分.md を作ってSlack MCP がなくても、重要スレッドをコピペで渡せば同じことはできます。
2. GitHub の PR コメント
レビューの癖が一番直接的に出る部分です。何を指摘するか、どこを見ているか。gh CLI で自分のレビューコメントを抜き出して、Claude に渡して分析させます。具体的なコマンドは GitHub の README に載せています。
3. 実装コード
設計思想・命名規則・抽象化の粒度はコードに出ます。同じく gh CLI で自分のコミットを取得して分析させます。
この3つを合わせると、かなり精度の高い分身ができます。ポイントは、**プラグインがこれらのツールを同梱しないこと**です。Slack MCP や Gmail MCP は汎用ツールなので、既に入れている人はそのまま使えばいい。入れていない人も gh CLI + コピペで十分作れます。
同僚の分身も同じ要領で作れる
チームに1人、レビューが鋭い人がいます。その人が全部の PR を見るのは現実的に無理ですが、その人の観点を分身として再現すれば、全 PR に目が行き届くようになります。
作り方は同じです。同僚のPRコメント・Slack発言・コードを Claude に分析させて `team/yamada.md` に落とすだけ。
チーム全員分を作れば、Claude Code 上にチーム全体が再現されます。
分身は「レビュー」だけじゃない。設計・実装も揃う
ここまで「レビュー」の話をしてきましたが、分身の本領はもう少し広いところにあります。
普段の Claude Code の使い方のなかで、`team/` に分身を置いておくだけで、**設計や実装を依頼した時点からチームの癖が反映されます**。
- 設計を依頼したとき: 「佐藤さんならここは Service に切り出す設計にするはず」が最初から反映される
- 実装を依頼したとき: チームのコーディング癖・命名規則・抽象化の粒度が揃う
- レビューを依頼したとき: 別人格の分身が「佐藤さんだったらここ突っ込むだろうな」「前に down() 書き忘れてロールバックできなかった件と同じ」と指摘する
セルフレビューのバイアスを避けるため、レビュアーは別人格にしています（自分で書いたコードを自分でレビューしても甘くなるので）。ただ、本当に効くのは、設計・実装の時点で分身の判断軸が入っていることです。
「止める」より「そもそも起こさない」方が速い
分身がいない普通の開発だと、こうなります。
設計 → レビューで「うちのやり方と違う」と差し戻し
実装 → レビューで「Action 太りすぎ」と差し戻し
テスト → レビューで「この失敗パスのテストない」と差し戻し分身が参加すると、こうなります。
（チームの癖を踏まえて）設計 → レビューは細かいチューニングのみ
（チームの命名で）実装 → レビューで挙がる論点が減る
（過去事例を踏まえて）テスト → 差し戻しが激減レビューで止めるより、そもそも手戻りを起こさない方が速い。
チーム開発で地味に効いてくるのは、実はここです。分身は「レビューの質を上げる」だけじゃなく、成果物を最初からチームのやり方に寄せる役割を持っています。
おまけ：一括で回したいときの `/engineer:autodev`
設計 → 実装 → テストを Issue 単位でまとめて自動で回したいときは `/engineer:autodev` というコマンドも用意しています。
# Issue #1 に対して autodev を実行
/engineer:autodev #1
各フェーズで分身がレビューに入るので、差し戻しを待たずに指摘が反映されていきます。
ただし、これは中〜大規模タスクを一括で実装したい場面向けのコマンドです。単一リポジトリの小さな修正や日常のタスクには正直オーバースペックで、普段使いなら Claude Code に直接依頼して分身が参加する形の方が速いです（autodev 自体も今後リファクタ予定）。分身の真価はあくまで「設計・実装・レビューに参加すること」自体にあって、autodev はその応用形という位置付けです。
他のレビュー手段と、何が違うのか
ここまで読んで、「コード規約を読ませればいい」「DBA やセキュリティの汎用レビュアーで十分」と思った方がいるかもしれません。
結論から言うと、分身はそれらと別のレイヤーにあります。
コード規約との違い：暗黙知 vs 明文化
コード規約（`CLAUDE.md`、lint ルール、スタイルガイド）が扱えるのは、すでに明文化された判断です。
- 「Service層に切り出す」
- 「N+1を避ける」
- 「マイグレーションは up/down 両方書く」
これは、チームで合意済みのルール。守ることは大事ですが、問題は規約に書かれていない判断の方です。
- 「この処理、今回は共通化すべき？それとも後回し？」
- 「PR サイズがちょっと大きいけど、分けるほどでもない？」
- 「このテストケース、書くべき？スコープ外？」
こうしたグレーゾーンの判断は、規約には書けません。書けない理由は、状況次第で答えが変わるからです。その人の経験と勘で判断している。分身が再現するのは、ここです。
汎用 AI 専門家との違い：チーム文脈の有無
プリセットとして DBA・セキュリティ・パフォーマンスの汎用専門家も用意しています。ただ、**本当に効くのは同僚の分身の方**です。
汎用 DBA は「マイグレーションに down() を書いてください」と言う。
同僚の分身は「前に down() 書き忘れて本番ロールバックできなくなった件あったよね。ここは特に気をつけて」と言う。
文脈がある指摘は刺さります。「なぜそれが重要か」が実体験に紐づいているから、実装者が納得できるわけです。
レビューがチームの資産になる
ここが一番伝えたいところです。
分身を作ってレビューさせる。それだけでも便利ですが、もう一歩踏み込んでいます。
レビュー結果が蓄積されて、チームの共有知になる。
autodev を回すとレビュー結果がファイルに溜まります。`/engineer:review-retrospective` を実行すると、過去のレビュー結果を分析してくれます。
- 同じ指摘が繰り返されている → `principles.md` に昇格を提案
- 新しい失敗パターンが見つかった → `anti-patterns.md` に追加を提案
承認したものだけ反映されます。次回の autodev では全メンバーがこれを参照する状態になります。
流れはこうです。
- 1回目：佐藤の分身が「ここ N+1」と指摘
- 2回目：佐藤の分身がまた「N+1」と指摘
- → retrospective で「N+1 チェック」が principles.md に昇格
- 3回目：designer が設計段階で eager loading を計画に含める。指摘自体が出なくなる
個人の暗黙知が、チームの明文化された知見に変わります。
分身が指摘する → 繰り返される → ルールに昇格 → 全メンバーが参照。
人が辞めても、知見は残ります。新メンバーが入っても、チームの過去の失敗から自動的に学べる環境になります。
どの言語・FWでも動く
プラグイン本体は言語・フレームワークに依存しません。PHP でも TypeScript でも Python でも同じように動きます。**変わるのは team/ の中身だけ**です。
Docker や CI のようなプロジェクト固有の処理は、`config.yml` で hook スクリプトを指定して委譲する形にしています。hook がなければスキップされるだけです。
インストールと最初の一歩
# マーケットプレイスに追加
claude plugin marketplace add etsurouwatanabe-tech/claude-engineer
# プラグインをインストール
claude plugin install engineer@claude-engineerプロジェクトのルートで `/engineer` を実行するとセットアップが始まります。
/engineer対話形式で初期チーム（リードエンジニア＋ガーディアンの2名）がセットされ、`.engineer/` ディレクトリが作られます。
ここに分身を追加していきます。Claude にこう頼むだけで、自分の分身ファイルが生成されます。
自分の直近のPRレビューコメント20件を分析して、
team/自分の名前.md にメンバー定義を作ってこれで、次回の autodev から自分の視点でもレビューが入るようになります。
同僚にも「このプラグイン入れて、お互いの分身作ろう」と言えば、チーム全員の視点が AI 上に再現されます。
まとめ
AIのレビューが刺さらないのは、AIの性能の問題ではありません。あなたのチームを知らないからです。
claude-engineer でやっていることはシンプルです。
- 自分と同僚の分身を作る — Slack・PR コメント・コードから、メンバーの「考え方の癖」を Markdown で定義する。教科書的な AI レビューが、チームの文脈を持ったレビューに変わる
2. 分身が設計・実装・レビューに参加する — 成果物が最初からチームのやり方に寄るので、レビューでの手戻りが減る。別人格のレビュアーがセルフレビューのバイアスを排除する
3. レビューがチームの共有知になる— 繰り返される指摘はルールに昇格する。個人の暗黙知がチームの資産に変わり、人が入れ替わっても知見が残り続ける
中小企業の業務自動化・AI導入支援を本業としています。「個人の経験をチームの資産に変える」という考え方に共感していただける方、
特にAI/業務自動化の実装に踏み込みたい開発者・PdM・コンサルタントの方がいれば、ぜひお話しましょう。
リポジトリは公開しています。フィードバック歓迎です。
