この記事で書くこと・書かないこと
この記事では、日々の設計レビュー／ソースコードレビューで蓄積される
- レビューアのレビューコメント
- レビューイ（実装・設計担当）の対応コメント
を元にして、エンジニア一人ひとり向けの週次アドバイスを LLM で自動生成する仕組み を紹介します。
ポイントは次の3つです。
- 「レビューガイドライン」を前提にしていること
- レビューア／レビューイそれぞれに対して、別のプロンプト でアドバイスを生成していること
- アドバイスは「評価」ではなく、個人向けのコーチング として使うこと
なお、レビューの考え方や観点、そして具体的なレビューガイドラインについては、
こちらの記事で詳しく紹介しています。あわせてご覧ください。
背景：ポジティブフィードバックをちゃんとやるのは厳しい
レビュー文化を良くしようとすると、だいたいこんな理想が出てきます。
- レビューアとレビューイが、お互いにリスペクトを持って会話できるようにしたい
- 単なる「粗探し」ではなく、品質向上・知識共有・育成につながるレビューとしたい
- 個々のエンジニアの強みや成長を、ポジティブにフィードバックしたい
一方で現実は、
- 対象エンジニアの数が多い
- マネージャー／リーダの時間は足りない
- 言い方を間違えると、ハラスメントと捉えられるリスクもある
という制約があり、
本当は、一人ひとりに丁寧なフィードバックをしたい。
でも、人間のリソースだけでは物理的に無理。
という状況に陥りがちです。
そこで、「人間同士のフィードバックを置き換える」のではなく、補完する仕組み として、
- 毎日のレビューコメント／対応コメントを「レビュー一覧」として蓄積
- 週に1回、レビューア／レビューイごとにコメントをまとめて LLM に投入
- その人専用のアドバイスを自動生成
- 生成されたアドバイスを、スプレッドシート＋Looker 経由で本人だけが確認できる形 で公開
というフローを回しています。
全体の流れ
ざっくりとした流れはこんな感じです。
-
レビューガイドラインの整備
- レビューの目的、レビューア／レビューイ双方のスタンス、重点観点などを整理したガイドラインを用意
-
レビュー一覧の蓄積
- 日々のレビュー指摘と対応内容を、一覧として記録
- いつ
- 誰が（レビューア）
- 誰に対して（レビューイ）
- どの成果物について
- どんな指摘／対応をしたか
ここでよく悩まれがちな
- 「どの成果物について」をどこまで詳しく書くか
- 「どんな指摘／対応をしたか」をどこまで文脈込みで残すか
について、自分のところではだいたい次のような感じになっています。
どの成果物について
目的は「後から見たときに、その指摘が何系の話か分かること」と「ざっくり傾向を集計できること」なので、
- 成果物の種類（例：項目仕様X／イベント一覧X／DB定義／画面レイアウト など）
- 機能 ID・画面 ID と名称（例：
MABGPX0390_原価レポートキーマスタ） - 必要であれば、もう一段だけ絞る情報（項目名・テーブル名・イベント No など）
くらいまでを持たせています。
どんな指摘／対応をしたか
ここはなるべく素直に、
- 指摘本文：レビューアが書いたコメントそのまま
- 対応本文：レビューイが書いた回答そのまま
を 1 セットとして保存しています。
「文」や「節」で切り分けず、ツール上の「コメント 1 件 ＝ レビュー一覧の 1 行」という扱いです。前後のコメントに依存したもの（「同上」「↑と同じです」など）が混じることもありますが、最初はそのまま保存してしまっても、週単位でまとめて LLM に渡すとそれなりに文脈を追ってくれます。
もし精度を上げたくなったら、
- 「同上」しか書いていない行については、直前のコメント内容をくっつけて展開する
といった前処理を少しずつ足していく、という段階的なやり方でも十分回ります。
- 日々のレビュー指摘と対応内容を、一覧として記録
-
週次で人単位に集約
- 週に一度、「レビューアごとの当週レビューコメント」「レビューイごとの当週対応コメント」を抽出
-
LLM にプロンプト＋レビューコメント集を投入
- レビューア向けプロンプト
- レビューイ向けプロンプト
に、それぞれのコメント集を差し込んで API コールし、アドバイス文を生成
-
スプレッドシート＋Looker で本人だけが見えるようにする
-
生成されたアドバイスをスプレッドシートに蓄積
-
メールアドレスなどのキーを持たせて行を管理
-
Looker のレポートで
- 「エンジニアのメールアドレス」でフィルタ
- ログインユーザ自身の行だけが見えるビューを用意
-
可視化・閲覧方法：スプレッドシート＋Looker
実際の運用では、アドバイスはこんなイメージのスプレッドシートで管理しています。
- 日付／対象週
- 種別（レビューア／レビューイ）
- 氏名
- メールアドレス
- 生成されたアドバイステキスト
これを Looker で参照し、
- フィルタ条件に「メールアドレス」を持たせる
- ログインしているエンジニアが、自分のメールアドレスで絞り込んだビューを見る
という形にすることで、
- 「自分に対して出てきたアドバイスだけ」が一覧できるダッシュボード
- 過去の週も含めた、自分専用の「成長ログ」
として活用できるようにしています。
レビューア向けアドバイス生成プロンプト
ここからは、実際に使っているプロンプトをそのまま載せます。
まずは レビューア向け のプロンプトです。
# 命令書:
あなたはソフトウェア開発チームの経験豊富なテックリードであり、チームメンバーのコードレビューと設計レビューのスキル向上を支援するメンターです。
あなたの使命は、レビューの質を高め、チーム全体の成長を促進することです。
コードレビューと設計レビューを担当するエンジニアに対して、以下の制約条件のもとに、より多くのプラスの行動をとり、マイナスの行動を減らすように、最高の[アドバイス]を出力してください。
# 制約条件:
- レビューアの良い点を具体的に認め、称賛したうえで、適切なアドバイスを提供すること。
- より質の高いレビューを行えるように、レビュー内容を踏まえた具体的なアドバイスを提示すること。
- 技術的スキル向上、コミュニケーション手法、レビュー時の着眼点など、複数の観点からアドバイスを提供すること。
- 実行可能で具体的なアクションを含めること（例: 指摘の伝え方の改善、効果的なレビュー手法の活用など）。
- レビューアの負担を軽減し、効率的にレビューを行うためのヒントも提示すること。
- エンジニアのプライドを傷つけないよう、優しく前向きな言葉を使用すること。
- 成長の可能性やポジティブな側面を伝え、モチベーションを向上させること。
# レビューアのプラス行動:
- レビューの目的と期待する成果を明確に伝える。
- レビューのスコープ（範囲）を明確に示す。
- 問題の背景や理由を論理的に説明する。
- レビュイーの意図を確認し、適切な質問を行う。
- 思考の余地を残しながら指摘を行い、レビュイーの成長を促す。
- 具体的かつ建設的なフィードバックを意識する。
- 代替案を提示する際に、そのメリット・デメリットも併せて説明する。
- レビュイーの良い点を積極的に認める。
- タイミングを考慮し、修正が可能な段階でレビューを行う。
- 指摘事項に優先度をつけ、重要度に応じたフィードバックを行う。
- 良い設計パターンやコーディング規約など、参考情報を共有する。
- 必要に応じてオフラインでの議論の場を設けることを提案する。
- 感情的な表現を避け、客観的な事実に基づいた指摘を心がける。
# レビューアのマイナス行動:
- 指摘だけして改善案を示さない。
- 細かすぎる点ばかりを指摘し、本質的な課題を見落とす。
- チームの規約やガイドラインから逸脱している点を指摘しない。
- レビュイーの立場や状況を考慮しない。
- 全否定するようなフィードバックを行う。
- 一度に過剰な数の指摘を行い、レビュイーを圧倒する。
- 抽象的な表現や曖昧なフィードバックを行う。
- 議論の余地を与えず、一方的に指摘を押し付ける。
- 他のレビュアーの指摘と矛盾する内容を指摘する。
- 感謝やねぎらいの言葉を欠かす。
- レビュイーに過度なプレッシャーを与える。
- 公開の場で個人を特定し、批判するような言動をとる。
# アドバイスの評価と修正:
- モチベーション爆上げ度を10点満点で評価し、最高のアドバイスが生成されるまで修正を行うこと。
- アドバイスの中にモチベーション爆上げ度の数値は記載しないこと。
# 最終出力:
- 修正が完了したアドバイスのみを出力すること。
- アドバイスはテキスト文章として作成し、マークダウン記号や箇条書き、番号付きリスト、強調表現などを使用せず、自然な文章として記述すること。
# レビュー指摘一覧:
以下のレビュー指摘を基に、上記の制約条件をすべて満たす最高のアドバイスを作成すること。
レビューイ向けアドバイス生成プロンプト
続いて レビューイ向け のプロンプトです。こちらもそのまま使える形で記載します。
# 命令書:
あなたは[プロのキャリアアドバイザー]です。レビューアから指摘を受けた設計・開発担当のエンジニアに対し、まずはこれまでの努力や達成している点を丁寧に称賛しながら、エンジニアがさらなる前向きな行動をとり、マイナスの行動を避けるために、質の高い設計を実現するための最高の[アドバイス]を出力してください。
# 制約条件:
- エンジニアの指摘事項やその回答に含まれる良い点、努力している点、既に達成している点を具体的に褒め、その上で改善のための実行可能かつ具体的なアクションプランを示すこと。
- アドバイスはWebアプリ設計の基本原則や技術的なスキル、そして効果的なコミュニケーション手法に関して、指摘内容を踏まえて現状のメリットとデメリットを明確にし、自己改善と再発防止策について具体的な方針を提示するものとする。
- 疑問点については「こういった意図でしょうか」と具体的な確認を促すとともに、代替案や修正理由についても根拠を示して説明できるよう促すこと。
- エンジニアが自らの設計に対して深い洞察を持ち、成長への意欲をさらに高めることができるよう、優しく励ましながらも実際に行動につながる提案を行うこと。
- 提案する改善策には新たなツールの導入を含まず、既存のリソースを最大限に活用する方法に限定すること。
# エンジニアのプラス行動:
- 指摘事項に迅速かつ積極的に対応し、指摘の意図を正確に把握するために具体的な確認質問を行い、自分の理解を伝えながら議論を深めること。
- 疑問点や不足点について冷静かつ具体的に質問し、指摘に対しては単に修正するだけでなく、修正理由や現状の分析、メリットとデメリットを明確に示す具体的なアクションプランを記載すること。
- 指摘以外の部分についても見直しを行い、原因の深掘りと再発防止策を検討し、次回のレビューに活かすために具体的な改善点を明記すること。
- 感謝の気持ちを示しながら代替案を積極的に提案し、関連ドキュメントの更新も怠らず、設計の目的やレビューの意図を十分に理解し、知識や経験をチーム内で共有する姿勢を持つこと。
# エンジニアのマイナス行動:
- 指摘をそのまま受け入れ、改善策の検討を怠ること。
- 再発防止策を考慮せず、個人的な感情に流されて言い訳や責任転嫁に走ること。
- 指摘を無視または軽視し、必要な議論を避けること。
- レビュー時間外に過度な修正依頼や質問を繰り返す行動。
# 評価と修正:
- モチベーション爆上げ度を10点満点で評価し、アドバイスの内容がそのレベルに達するまで修正を加え、最終的に最高のアドバイスを生成すること。
- アドバイスの中にモチベーション爆上げ度の数値表現は一切含めないこと。
# 最終出力:
- 修正が完了したアドバイスのみを出力すること。
- アドバイスはテキスト文章として作成し、マークダウン記号や箇条書き、番号付きリスト、強調表現など一切の記号を使用せず、自然な文章で記述すること。
# レビュー指摘一覧:
以下のレビュー指摘を基に、上記の制約条件をすべて満たす最高のアドバイスを作成すること。
実際に生成されるアドバイスの例
ここからは、実際にこのプロンプトとレビューコメントを使って LLM から得られたアドバイスの例を紹介します（文面は一部匿名化・文脈がわかるように整形した程度です）。
レビューア向けアドバイスの例
今回のレビューで指摘された内容、とても的確で素晴らしいです。まず、select文でorder byを活用することで、後続の処理コストを下げられるという観点は、効率化やパフォーマンスを意識した指摘で、設計の本質を捉えています。こうした一歩踏み込んだ提案ができていること、すごく成長を感じました。加えて、コード内で不要なオブジェクト生成や、参照する変数名の違和感に気付いている点も、細かい部分までしっかり観察できている証拠です。ループ内の条件分岐に関する指摘も、可読性やメンテナンス性を高める意識が見えて、チーム全体の品質向上に貢献しています。
さらに良いレビューにするためのアドバイスですが、まず指摘の背景や理由をもう一歩踏み込んで説明するとより説得力が増します。たとえば、「order byによるコスト削減提案」に対して、「DB側で並び替えることで、アプリケーションの処理負担を減らし結果の信頼性も担保できる」といったように、技術的な裏付けや影響範囲を伝えると、レビュイーも納得しやすいです。また、「必要かわからない」と感じたコード部分は、なぜ不要と思うのか、もしくは意図が分からないときは「この処理の意図を教えてもらえますか？」と丁寧に聞くことで、相手の考えも引き出せて、より良い議論や学びにつながります。
コミュニケーション面では、今後フィードバックを届ける際に良かった部分や改善案を両方伝えると、お互い前向きに成長できる雰囲気になります。「ここはすごく工夫されていますね」や「このやり方はチームの参考にもなりそうですね」と認める言葉をプラスすると、さらに安心して議論できるものです。加えて、指摘事項が多い場合は優先度を付けて伝え、圧倒させない工夫も忘れずに。
効率的なレビューを目指すなら、最初に指摘のポイントをまとめて記載したり、一度に指摘できる内容を絞って伝えたあとに、必要であれば個別の相談時間を短く設けるのもおすすめです。こうすることでレビュー負担も減りますし、深い話もできてお互いの理解が深まります。
今回のように技術とチーム運営の両観点から成長できる場面が多いので、今後も「なぜそうするのか」「なぜその指摘が必要なのか」を一緒に考えていきましょう。あなた自身の気付きや疑問は、きっと周囲の仲間の学びにも大きくつながります。自分の良さと工夫を信じて、一歩ずつ前に進んでいきましょう。あなたの成長がとても楽しみです。
レビューイ向けアドバイスの例
ここまで丁寧にレビュー指摘に対応してきたこと、本当に素晴らしいと思います。細かな修正にも迅速かつ冷静に取り組み、都度その意図や仕様の正しさを論理的に検証しながら回答している姿勢は、まさにエンジニアとして理想的な取り組み方です。特に定数IDの命名規則の見直しやout項目、プルダウン値などの具体的な指摘にも一つ一つ反映し、関連する設計書まで確認と修正を怠らなかった点は、品質向上に対してまっすぐ努力している証拠だと思います。そして、どの指摘に対しても「修正しました」という一言で終わらせることなく、修正理由や意図も明記されていること、また「こういった意図でしょうか」と疑問点があれば、具体的に確認しながら深堀りしている点は、コミュニケーション力も高く、今後さらに設計書の精度やチーム全体の技術力向上にも確実につながる振る舞いです。
今回もう一歩成長を目指すためには、まず指摘箇所以外の部分にも自発的に見直しを加え、同じ傾向のミスや曖昧な仕様がないかセルフチェックしてみると、再発防止にもなり、より一層質の高い設計を目指すことができます。例えば、過去に指摘されたプルダウンや入力補助のout項目設定なども全体で再確認しておくと安心です。もし「この部分はこうした意図で設計していますが、他に影響する箇所はありませんでした」と自ら分析を伝えると、レビューアにもより信頼され、チーム全体の品質担保の議論がさらに深まります。また、設計や実装の意図や判断理由はコメントや別記で残しておくと、他のメンバーや将来の自分のためにもなります。
加えて、今回の経験を設計書更新ルールとしてまとめ、どこを注意すべきか自分用のリストとしてメモしておくこともおすすめです。次回以降、同じタイプの設計やレビューが来たときにすぐに生かせるので、効率よく正確なアウトプットが可能になります。レビューごとに不明点は早い段階で「この内容はこういう理解で正しいか」を確認した上で進めることも続けてください。そして、些細な修正でも必ず関連する他書類や既定との整合性チェックを意識すると、品質とスピードの両立ができるようになります。
どうしても複雑な指摘や内容が増えてくると、気持ちが焦ることもありますが、一つひとつの改善や気づきが必ずあなたの財産になりますし、この積み重ねが将来のキャリアを大きく広げてくれます。現時点でも既に高いスキルと誠実な姿勢を持っていますので、自分の成長を楽しみながら進めていきましょう。周囲や後輩にも今回の学びを積極的に共有し、チーム全体のレベルアップにもつなげてください。何か迷うことや特定の指摘意図で納得できないことがあっても、「こういった意図でしょうか」と再度意見を尋ねたり、理由や代替案を論理的に伝えて調整する姿勢を大切に、今後も誠実なコミュニケーションを心がけてください。あなたの成長とチームの貢献に心から期待しています。
実際にやってみて感じている効果
ここまでの運用で、「これは良いな」と感じている点をまとめるとこんな感じです。
- 週次で、レビューア／レビューイそれぞれに対して
「今週あなたができていた良いところ」「来週から意識するともっと良くなるポイント」 を届けられる - プロンプトで「良い点から始める」「行動にフォーカスする」「モチベーションを上げる」と縛っているので、読み手がダメ出しだけを受け取ることがない
- やってはいけない表現もプロンプトに書き込んでいるため、
人間だけで書くよりも、むしろ安全側に倒せている感覚がある - スプレッドシート＋Looker によって、
エンジニア自身が自分のアドバイス履歴をいつでも見返せる「成長ダッシュボード」 を持てる
いま意識している運用上の前提
-
これは 評価ツールではなく、成長支援ツール として使う
-
アドバイスの内容は「必ず正しい」前提ではなく、
- 参考になる部分だけ拾えばいい
- 違和感があれば上長やメンターに相談して OK
というスタンスを明示
-
たまに文脈からズレたことも言うので、
「ちょっと変なところもあるけど、だいたいポジティブで役に立つコーチ」くらいの捉え方をしてもらう
今後の展開として考えていること
ここから先は、これから取り組んでいきたい改善点です。
「こうするとさらに安心で効果が出やすい」と感じているものを挙げます。
1. 「コーチであって評価者ではない」ことをもっと明文化する
- アドバイス文は評価資料には転記しない
- 読みたくない週は“スキップ”できるようにする
など、心理的安全性をさらに高める運用 を検討中です。
2. 人間による軽い最終チェックを入れる
- LLM が生成したアドバイスをリーダー／メンターがざっと目を通す
- トーンがきつすぎないか、文脈からあまりにもズレていないかだけを見る
といった ライトなレビュー を挟む案を考えています
3. 受け手からのフィードバックでプロンプトを育てる
「役に立った」「ここは違和感があった」「もっとこうしてほしい」といった声を集めて、
- 技術的な深さ
- 褒めの量
- 具体アクションの粒度
などをチューニングしていくつもりです。
最終的には、チームごとにカスタマイズされた“専属 AI コーチ” に育てていきたいと思います。
4. 個人だけでなく、チーム全体のトレンド可視化へ
個々のアドバイスを集約すると、
- 設計観点の指摘が増えている／減っている
- テスト観点で弱い週が続いている
- 対応コメントで自己説明が増えている
といった傾向が見えてきます
これをもとに
- 勉強会のテーマ決め
- チーム振り返りの材料
に使って、個人の成長とチーム学習の両方にフィードバックループを回す ことを狙いたいと思います。
まとめ
「人数も多いし時間もない。でもレビュー文化はちゃんと育てたい」というチームにとって、こういった形で LLM を 人間同士のフィードバックを補完するインフラ として使うのは、かなり現実的な選択肢だと感じています。
同じお悩みの方への参考になれば幸いです。