今回はIT戦略部部長の武下より、チームメンバーと進めた「AIを活用したコードレビューの仕組み化」の舞台裏について紹介させていただきます！

はじめに・・・

WellGoのIT戦略部部長の武下です。

今回は、チームメンバーが自発的にdesign docを書いて提案してくれたことをきっかけに、AIを活用したコードレビューの仕組みが生まれた話を紹介します。技術的な内容もありますが、どちらかというと「チームでどうやって課題に向き合い、形にしていったか」というプロセスの話です。

課題・・・レビュー品質のばらつき

私たちのチームでは全員がコードレビューを行っています。ただ、正直なところ課題もありました。
レビューの観点に抜け漏れがあったり、人によって深さが違ったり。特にセキュリティ面（テナント分離や個人情報の扱い）やパフォーマンス面（N+1クエリなど）は経験値に依存しやすく、属人化しがちでした。PR説明が薄くてレビュアーが変更意図を汲み取るのに時間がかかる、というのもよくある風景です。
「なんとかしたいよね」という空気はあったものの、具体的なアクションには至っていませんでした。

メンバーからdesign docが上がってきた

そんな中、あるメンバーがdesign docを書いて提案してくれました。Claude Codeの「スキル」と「フック」という機能を活用して、コードレビューを型化・自動化する仕組みです。指示されて書いたものではなく、本人が課題を感じて自発的にまとめてくれたものでした。
design docには目的・背景・ソリューション詳細がしっかり構造化されていて、「達成すること」「成功の定義」「今回議論しないこと（スコープ外）」まで明確に書かれていました。スコープ外を明示するのは地味に大事で、議論が発散しにくくなります。

「正解」を出すのではなく、ガードレールを敷く

提案の核にあったのは、レビューの正解を決めるのではなく、見落としを防ぐ仕組みをつくるという発想でした。

具体的には、Claude Codeのスキル機能を使って3種類のレビューコマンドを定義しています。
- **`/review`** ── 設計・命名・セキュリティの3観点を並列で分析する包括レビュー
- **`/review-security`** ── セキュリティに特化した深い分析
- **`/review-pr`** ── PR説明の自動生成やテンプレート準拠チェック

レビュー結果は [Conventional Comments](https://conventionalcomments.org/) の標準に準拠したラベルで出力されます。`issue (blocking)` なら要修正、`suggestion` なら改善提案、`praise` なら良い点の指摘。blockingが1件でもあれば「要修正」、non-blockingのみなら「LGTM（軽微な改善推奨）」と判定される。

ここで大事なのは、AIの判定がそのまま最終判断になるわけではないということです。GitHub PRへの自動コメント投稿はスコープ外として明確に除外されており、あくまで人間がAIの分析結果を見て判断する運用です。

AIが出すのは「ここは見たほうがいいですよ」という補助線であって、「これが正解です」ではない。
Rubyファイルを編集すると自動でRuboCopが走るPostToolUseフックも同じ思想です。「保存したら即チェック」は、開発者の判断を縛るものではなく、見落としを防ぐ仕組みとして機能します。

すでにあるものを活かす

もう一つ印象的だったのは、既存の知見やツールを徹底的に活用する姿勢でした。
レビューラベルの体系は一から考えるのではなく、GitLabのコードレビューガイドラインでも採用されているConventional Commentsを土台にしています。Claude Codeのスキルやフックも公式ドキュメントのベストプラクティスに沿って設計されています。

チーム内での議論の中で、「Anthropic公式にスキルを作るスキルがあるらしい」という情報が飛び出したのも象徴的でした。提案者はすぐに「本番マージ前にそれを使って再構築します」と反応。自前で頑張ることが目的ではなく、より良い仕組みをつくることが目的。使えるものがあるなら迷わず使う、というのが自然な判断でした。

サブエージェントの活用も同じ文脈です。`/review`では3つの分析タスクを並列で走らせますが、これはClaude Codeのサブエージェント機能を活かした設計です。親のコンテキストを圧迫しないという実利的なメリットも含めて、ツールの特性を理解した上で活用しています。

出してみて、チームで育てる

design docが共有されてからの流れも紹介します。
ドキュメントが投稿されると、別のメンバーからすぐにフィードバックがつきました。「サブエージェントでコンテキスト汚染を防ぐのはいいね」という技術的な賛同に加えて、「SDDプロセスでアーキテクチャや実装タスクのドキュメントをレビューする専用スキルを運用トライしていて、かなり感触がいい」という自分の実践知の共有も。

さらに話は広がって、「人向けのドキュメントとAI向けのスキルを同時に整備して、更新漏れを防ぐ仕組みにできないか」という議論にも発展しました。いわゆる「Single Source of Truth」をヒトとAIで共有するという考え方です。

提案 → フィードバック → 知見共有 → 改善。完璧なdesign docを出すことがゴールではなく、出してみて、チームの知見をぶつけて、より良いものに育てていく。このサイクルが自然に回るのは、うちのチームの良いところだなと思っています。

AIツールの「運用知」を育てる

今回の取り組みで改めて感じたのは、AIツールの導入は「入れて終わり」ではないということです。
Claude Codeのスキルやフックは強力な機能ですが、自分たちのプロジェクト固有の文脈──コーディング規約、セキュリティ要件、アーキテクチャのパターン──を反映させて初めて実用的なものになります。そしてその文脈の言語化は、結果的に人間同士の認識合わせにもなる。

メンバーの一人が言っていた「人向けのドキュメントも併せて整備されることが理想」という言葉が、まさにそれを表しています。AIのためにドキュメントを書くことが、チームのためのドキュメントにもなる。この好循環をどう維持するかが、これからのチャレンジです。

おわりに

まだ運用が始まったばかりで、使い込む中で調整は必要でしょう。でも、課題を感じたら自分でdesign docを書いて提案する。すでにある知見を活かして仕組みをつくる。まず出してみて、フィードバックで育てる。このやり方で進めていけば、大きく外すことはないと思っています。

WellGoのIT戦略部では、こうした開発文化を一緒につくってくれるエンジニアを募集しています。興味がある方はぜひお気軽にお声がけください。