この記事は弁護士ドットコム Advent Calendar 2025 の 11 日目の記事です。
はじめまして。クラウドサイン Product Engineering 部でバックエンドエンジニアをしている牧野（@kumak1）です。 弁護士ドットコムに入社して半年が経ち、有給休暇が付与されました。うれしいです。
はじめに
うれしいといえば、新しい環境でオンボーディングも丁寧にしていただきましたし、20％ルールも導入されていて現状よりもっと良くする行動が多くとれています。 Pull Request のレビューもチームメンバーから非常に丁寧なフィードバックをいただく、といったホスピタリティがあふれる環境で開発できています。
レビューではコードの品質はもちろん、ドメイン知識や設計の歴史的経緯など、コードを読むだけでは分からない文脈を多く学ばせていただいています。 ただ、「あんなに丁寧に教えてもらったのに、また同じような指摘をさせてしまった」ことがあり、申し訳ない気持ちになります。 「Claude Code が過去のレビュー指摘を全部覚えていて、コードを書いてる間も指摘してくれたらいいのに」と責任転嫁したい気持ちがふつふつと湧いてきました。 というわけで、過去の PR レビューを収集・要約し、さらにその知識を使ってレビュアとして振る舞わせるツールを作ってみました。
作ったもの
kcc は、GitHub の PR レビューを収集して資産化、それを活用してレビューする Claude Code プラグイン です。
プラグインとして公開するには JSON を書くだけででき、簡単に公開・導入できて大変便利ですね。
内容としては、以下 3 つのカスタムコマンドで構成されています。
- kcc-save-pr-comments（収集）
- 指定された GitHub PR のレビューコメントやメタ情報を取得する。単なるログの羅列ではノイズが多いため、重要なコンテキストのみを抽出して保存する
- kcc-summarize-pr-knowledge（変換）
- 保存されたレビュー情報を解析し、Claude Code が理解しやすい形のサマリを作成する
- kcc-review-branch（活用）
- 蓄積・要約されたレビュー情報をコンテキストとして読み込み、現在のブランチの変更点に対してレビューする
サマリはただの要約にしない
特に重要なのが、2 つ目の kcc-summarize-pr-knowledge で行っている処理です。 単純にコメントを要約するだけでなく、以下の観点で情報を抽出します。
- 基本品質： アーキテクチャ、パフォーマンス、セキュリティに関する指摘
- 時系列分析：「その指摘は今も有効か（陳腐化していないか）」や技術的な理想の達成度を検証
コードやレビューには、ADR や Design Doc では書ききれなかった、あるいは補足するようなコメントもあります。
- 「今回は工数優先でこう実装するけど、本来は〇〇パターンにしたいよね」
- 「将来的にはこのライブラリを剥がして、自前実装に切り替えたい」
こうした「理想と現実のギャップ」や「チームが目指す方向性」をレビューコメントから拾い上げ「行動の履歴」と「技術的な理想」として Claude Code にインプットします。
意義を再考する
ここまでは「自分が楽をするため」「同じミスをしないため」という動機で作ったツールの話でした。 しかし、これを作っているうちに、もう少し一般化できそうな課題と価値も見えてきました。
レビューコメントは「高品質なドキュメント」だと再認識したい
現代では LLM を使ってコードを書くことが当たり前になっています。 ですが LLM に読み込ませるコンテキストや開発ガイドラインを常に最新に保つのは、多くのチームにとってコストが高い作業です。
他方、私たちは日々の PR レビューという形で、誰かに読ませ・理解させ・行動させるという文書を書いています。 マージとともに過去のログとして流してしまうのは、組織として大きな資産の損失だと考えました。 レビューは一過性のものではなく、礎として蓄積されるものだと捉え直すことで、より良いレビュー文化の醸成にもつながると考えています。
「LGTM」や端的な指摘だけで終わることもあるでしょう。 そこに「ここめっちゃ良いね」「この実装勉強になる」という言葉が添えてあると、チームが大事にしている価値観を伝えたうえに受け手のテンションも上げてくれます。
未来の仲間のために、ドメイン知識が豊富だけど雑に扱えるメンターを置きたい
私自身、入社してからの半年間で多くの知識をレビューから得ました。 では、これから入社してくれるメンバーはどうでしょうか。 プロダクトが長く続けば続くほど、歴史的経緯やドメイン知識は複雑化します。新しく入った人がその「コンテキストの壁」を乗り越えるには時間がかかります。 新入社員だったりすれば、質問することへのハードルが高く感じられることもあるでしょう。
- 「この実装は過去に〇〇という理由で却下されている」
- 「チームの理想としては XX という設計を目指している」
LLM がこのように横でサポートしてくれれば、新しいメンバーは「歴史」や「お作法」のキャッチアップに苦労せず、最初から存分に技術力やクリエイティビティを発揮できるはずです。 また LLM でコードに対する質問することに慣れて要点を押さえてしまえば、人間とも円滑で芯を食ったコミュニケーションが取りやすくなるでしょう。
おわりに
作成したツールは Claude Code のプラグインとして公開していますが、まだまだ実証実験中といった状態です。 将来的には、Renovate が依存関係の更新 PR を作ってくれるように「チームのナレッジ更新」の PR が自動で飛ぶよう GitHub Actions でも動作するようにしたいと考えています。 普段通りの開発プロセスでレビューをするだけで、LLM が勝手に賢くなり、チーム全体の開発体験が向上していく。そんなサイクルを作っていきたいと考えています。
Apache 2.0 ライセンスで公開していますので、好きに改修していただいたり、Devin などの他の AI に応用してもらっても面白そうです。 もし興味があれば触ってみてください。
