AI生成コードレビューのトレーニング：開発者にモデルが書いたコードを監査する方法を教える

開発者がアシスタントに、ユーザーがレポートをダウンロードできるかどうかを確認する関数を作成するよう依頼した。コードはコンパイルされ、正常系テストもパスした。プルリクエストも整然としているように見えた。ところが2週間後、同僚が、その関数はユーザーがログインしているかどうかはチェックしているものの、レポートがユーザーのものであるかどうかはチェックしていないことに気づいた。

これはあくまで例示であり、実際に発生した事例ではありません。AI生成コードレビューのトレーニングにおいて、AIが解決すべき課題を明確に示しています。基本的なチェックを通過した生成コードであっても、認証や同時実行性に関する欠陥が含まれている可能性があり、レビュー担当者はそれを見つけ出し、なぜそれが重要なのかを説明する必要があるのです。

このガイドは、エンジニアリングイネーブルメントリーダーおよびエンジニアリングマネージャー向けです。パフォーマンスの問題の記述方法、ギャップの診断方法、設計準備と実践方法、ケーススタディの進め方、そして習得したスキルが実際のレビューに適用できるかどうかの評価方法について解説します。トレーニング設計に関する内容です。プログラム内のすべての欠陥、テスト、レビュールールは、上級エンジニアとセキュリティチームによって検証される必要があります。

AIによるコードレビュー研修とは何ですか？

AIによるコードレビューのトレーニングでは、開発者はアシスタントに明確な指示を与え、返ってきたコードを評価・監査する方法を学びます。つまり、コードは正しいか、安全か、同時負荷下で正しく動作するか、十分な効率性があるか、といった点を検証します。これは特定のツールに関するコースではなく、ツールが変わっても変わらないレビュー習慣を身につけるためのものです。

クイック事実

1. パフォーマンス上の問題点を説明する

まずはタスクから始めましょう。生成されたコードを監査し、テストによってリスクを立証します。監査とは、疑いの目でコードを読むことです。立証とは、その疑いを証拠、通常は失敗するテストや欠陥を示す再現手順に変えることです。

この研究は、なぜ意図的な練習が必要なのかを示唆している。GitHub Copilot の研究において、Pearce 氏らは既知の脆弱性タイプに基づいて選択された 89 のシナリオにわたって 1,689 のプログラムを生成し、そのうち約 40 パーセントが脆弱であることを発見した (ピアースら、2021年これは初期のツールであり、特定のシナリオに基づいていたため、この数値を今日のAIアシスタントの割合として扱わないでください。別のユーザー調査では、参加者にAIアシスタントを使用した場合と使用しない場合でコードを書いてもらいました。アシスタントを使用した参加者は、セキュリティの低いコードを書いたことが多く、自分のコードが安全だと信じる傾向が高かった（ペリーら、2023年同じ研究では、アシスタントへの信頼度が低く、アシスタントの指示により積極的に関わった参加者は、脆弱性が少なかったことがわかった。

トレーニング設計に関して、以下の2つの教訓が得られる。まず、説得力のある成果物には、積極的なレビュー担当者が必要である。そして、自信は証拠ではないため、演習では意見ではなく、テストを求めるべきである。

パフォーマンスに関する記述を1文で書き、エンジニアリングマネージャーに確認してもらいましょう。「生成された変更に対して、開発者はセキュリティ、並行処理、効率性に関するリスクを列挙し、それぞれについて、そのリスクを示すテストを記述または作成する。」

2. 学習と状況のギャップを診断する

何かを構築する前に、そのタスクを現在のプログラムで実践・評価されている内容と比較してください。トレーニングのギャップとそれ以外の問題を区別する上で、通常、次の3つの質問が役立ちます。

1. 現在の実践は、実際の課題に基づいているか？ 研修でプロンプト作成を指導するだけで、開発者に成果物のレビューを一切求めなければ、誰も監査の実践をしていないことになる。評価がセキュアコーディング規則に関する多肢選択式テストであれば、それは記憶力しか測っていないことになる。
2. 認知的な要求とは何ですか？ ブルームの改訂版分類法では、コードが安全かどうかを判断し、それを証明するテストを選択することは分析と評価のレベルに該当し、より良いプロンプトや修正を設計することは創造のレベルに該当します。アクティビティをこれらのレベルに合わせる方法については、ガイドで説明しています。 学習活動をブルームの分類法に合わせる.
3. スキル以外の何かが妨げになっているのでしょうか？ レビューに要する時間、ツール、担当者を確認してください。レビュー担当者がプルリクエスト1件につき5分しか時間をかけられない場合、どんなトレーニングをしても監査は実施されません。パイプラインに静的解析やテストハーネスがない場合、開発者はリスクを発見しても、それを立証することはできません。トレーニング以外の原因については、それを解決できる担当者に報告してください。

3. 設計準備と実践

トレーニングによって埋められるギャップが分かったら、各段階に明確な役割を与えましょう。

準備。 簡単な診断で前提条件を確認しましょう。対象となるのは、システムスタックが抱える一般的な弱点、テストの構造、チームが使用するレビューチェックリストなどです。この段階では、自分のペースで学習を進めるのが適しています。復習チェックでは、前提条件の確認のみを行います。

練習。 現実的な生成コードから作成した監査演習を使用してください。それぞれの演習には、所有権チェックの欠落、2つのリクエスト間の競合、非効率なループなど、さまざまな種類の欠陥を少数ずつ含め、さらに問題のないコードもいくつか含めます。開発者はレビューを行い、各リスクに名前を付け、その深刻度を説明し、それを実証するテストを提案します。行番号のリストではなく、その理由を尋ねてください。

フィードバック 合計スコアではなく、決定事項に関連付けてください。「共有カウンターでループは検出しましたが、競合は検出できませんでした。テストではリクエストを1つずつ実行するため、検出できなかったでしょう」という説明の方が、「3件中2件検出」という説明よりも役立ちます。

リアルタイム入力か、非同期レビューか？ リスクが曖昧な場合、ライブでの意見交換は最も効果を発揮します。開発者は、上級エンジニアがマージをブロックする理由を説明するのを聞くことで学ぶことができます。開発者の発見事項と注釈付きの専門家レビューを比較するには、非同期レビューで十分です。多くのチームは両方を活用しています。まず各自のペースで準備を行い、その後、難しいケースについてファシリテーター付きのセッションを実施します。

4. 現実的な例題に取り組む

例示です。エンジニアリングマネージャーは、使用前に事例と回答基準を検証する必要があります。

ケース。 生成されたエンドポイントは、請求書IDに基づいて顧客の請求書を返します。呼び出し元が有効なセッションを持っていることを確認し、パラメータ化されたクエリを使用し、基本テストに合格します。同じ関数は、ロックなしで共有ダウンロードカウンターをインクリメントします。

その任務。 開発者は、想定されるリスクをそれぞれ挙げ、それらをランク付けし、それぞれのリスクを裏付けるためのテストについて説明する。

最初の試み。 「問題なさそうだ。クエリはパラメータ化されていて、テストもパスしている。」開発者はテストのパスを証明とみなし、テストでカバーされていない点について質問していない。

フィードバックと再試行。 レビュー担当者は、セッションチェックによって何が証明され、何が証明されないのかを開発者に説明するよう求めます。再試行では、2人の異なる顧客と2つの同時リクエストについて検討するよう求められます。

より強力な試み。 「セッションチェックは、誰が呼び出しを行っているかを証明するものであり、請求書がその人のものであることを証明するものではありません。顧客Aが顧客Bの請求書IDを要求し、拒否されることを想定するテストを作成します。カウンターは同期なしでインクリメントされるため、2つのリクエストが同時に発生すると更新が失われる可能性があります。同時実行テストを実行してカウントを比較します。クエリ自体はパラメータ化されているため、そこに時間を費やす必要はありません。」この回答では、リスクをランク付けし、それぞれをテストに関連付けていることに注目してください。

それぞれの回答が妥当である理由、あるいは不完全である理由。 審査員の好みではなく、承認された基準に基づいてそれぞれを評価する。最初の試みは習慣に従っているが、証拠が欠落している。より優れた試みは、具体的で、優先順位が付けられ、検証可能である。

5．能力を評価し、移転計画を策定する

能力の証拠は、学習者が見たことのない新しい課題におけるパフォーマンスです。スコアの検証品質と関連する欠陥の特定。シンプルなルーブリックでは、基準ごとに0から2の尺度を使用します。

アンカー: 0 は存在しないかサポートされていない、1 は関連する省略がある部分的、2 は合意された基準に対して完全かつ正当化されている。保護されていないアクセス パスを持つコードの承認など、重大なエラーを個別に定義し、全体的なスコアで隠蔽できないようにします。この評価基準は提案であり、検証済みの準備標準ではありません。エンジニアリング マネージャーと調整し、パイロット運用してください。 有益なフィードバックを伴うインタラクティブな実践を設計する 意思決定につながるフィードバックの書き方を示します。

計画的な移行を実施しましょう。演習後、各開発者に生成されたコードを含む実際のプルリクエストを割り当て、一緒に発見事項をレビューするか、あるいは最近行ったレビューで見落としがあった点について簡単な振り返りを実施してください。

インタラクティブな配信が役立つ場面

インタラクティブな形式は、グループを見る前に全員がコミットする必要がある場合に役立ちます。ライブセッションでは、ファシリテーターが生成されたスニペットを表示し、各開発者にリスクと作成するテストを入力するように求め、議論の前にスプレッドを公開できます。同じ演習を準備のために自己ペースで実行することもできます。AhaSlidesはインタラクティブな学習と、ライブ配信と自己ペース配信の切り替えをサポートしています。これはプレゼンテーションおよび学習ツールであり、コードを実行する場所ではないため、コード演習は独自の環境で実行してください。使用する予定の特定のオーサリング、フィードバック、またはレポート機能を、独自のワークフローと照らし合わせて確認してください。形式の選択に関するガイダンスについては、次の記事を参照してください。 適応型学習、インタラクティブ学習、ライブ学習をいつ活用するか.

何が変わったかを測定する

開発者がタスクを実行できることを示す基準を事前に決定してください。未知の演習における検証品質と欠陥検出結果を基準値と比較します。対象者、分母、および期間を明確に定義してください。結果が改善された場合は、トレーニングの効果を評価する前に、同じ期間に他に何が変更されたか（新しい静的解析ルール、改訂されたレビューチェックリスト、アシスタントの変更など）を確認してください。

残る可能性のある制約

• レビューの時間です。 監査はざっと目を通すよりも時間がかかり、締め切りはざっと目を通す方に有利に働く。
• ツーリング。 パイプラインにテストハーネスやスキャンが組み込まれていない場合、リスクを立証することは困難です。
• ツールを変更する。 アシスタントはすぐに変わるので、レビューの習慣を身につけるための練習は、特定の製品に限定せず、継続的に行うようにしましょう。
• 事件報道。 ある演習では、いくつかの種類の欠陥が示されています。スコアは、開発者の判断力を総合的に表すものではありません。
• 転送。 ワークショップでのパフォーマンスは、多忙なレビュー待ち行列でのパフォーマンスとは異なります。

これらの問題点を早めにスポンサーに伝え、個別の修正計画を立てましょう。トレーニングは開発者が発見し証明できる能力を向上させますが、時間やツールを生み出すものではありません。

よくある質問

AIによるコードレビュー研修とは何ですか？

このプログラムは、開発者がAIアシスタントによって生成されたコードを促し、評価し、監査する方法を教え、セキュリティ、並行処理、効率性の問題を見つけ出し、それぞれをテストで裏付ける方法を学ぶものです。

生成されたコードは、人間が書いたコードよりも安全性が低いのでしょうか？

研究結果はリスクを指摘しているものの、結果はツール、タスク、研究デザインによって異なる。あるユーザー調査では、アシスタントがいる参加者はセキュリティレベルの低いコードを書く傾向があり、そのコードに対する自信も高まったことが明らかになった。これは、コードレビューの習慣を身につける必要性を示す一例である。

開発者が生成されたコードを監査できるかどうかをどのように評価しますか？

新しいコード演習を実施し、合意された基準に基づいて検証品質と欠陥特定を評価します。セキュアコーディング規則に関するクイズは、前提条件の確認のみを目的としています。

トレーニングのためにコードサンドボックスは必要ですか？

演習を実行する場所が必要ですが、通常は自分の環境がそれに該当します。使用するツールが自分のニーズを満たしているかどうかを、使用する前に必ず確認してください。

どこから始めれば

コードベース内で繰り返し発生する変更の種類を1つ選びます。パフォーマンスに関する記述を作成し、エンジニアリングマネージャーに導入した欠陥と、それらを明らかにするテストを検証してもらい、0～2のスケールと重大なエラーのリストを含む3つの評価基準からなるルーブリックを作成します。展開する前に、少人数のグループでパイロットテストを実施してください。

監査演習を自社チームで実際に実行し、その後は各自のペースで再利用する方法を確認するには、AhaSlides をご覧ください。