AIエージェント活用事例
Views —

AIエージェント活用事例

今日の新着

2すべて 191件

全191件中 1〜20件

開発・コーディング

AIがコードレビューを担当し、人は高リスクな変更のみ確認するチーム運営

著者によると、Anthropic Claude CodeチームではコードレビューをAIに任せ、人は高リスクな変更のみ直接確認する運用を行っているそうです。

Claude Code

使い方

  1. コードを作成した後、実行可能なテストやビルド、デザイン比較用のスクリーンショットなどで変更内容を検証します。
  2. Claudeにコード変更の成果物を提示し、内部のサブエージェントが新しいコンテキストでdiffを確認します。
  3. CLAUDE.mdやREVIEW.mdなどでプロジェクトやレビュー基準を明確に文書化し、AIレビューアがそれを参照できるようにします。
  4. すべてのプルリクエスト（PR）に対してClaudeが自動でコードレビューを行います。変更の目的や全体のコードベースを参照し問題点を探し、複数のエージェントがバグの有無を投票で検証します。
  5. セキュリティレビューも自動化し、バグやセキュリティ問題が残っていればマージをブロックします。オープンソースのGitHub Actionや /security-review コマンドも活用できます。
  6. 自動化されたリント、型チェック、テスト、ビルドなど様々な検証を通過する必要があります。PRテンプレートにはテスト方法やロールバック方法を明記します。
  7. 変更のリスク度合いに応じて人による承認ステップを変えます。リスクが低い変更は自動化のみでマージし、中リスク以上は1人または2人の承認を得ます。信頼された作成者のみ自動化ルートを利用できます。
  8. マージキューで全てのチェックを再実行し、マージ後に問題がないようにします。新機能はフラグで社内スタッフに先行配布し、段階的に公開します。
  9. 問題が発生した場合、迅速に検知しロールバックできるようにフラグやダッシュボード、オンコール体制を運用します。
  10. レビュー工程やAIレビューアは実際のインシデント事例を毎日評価し、繰り返し発生する問題はルールやドキュメント、スキルで改善します。

結果

著者は、コード変更の大部分をAIが自動でレビューし、高リスクな変更のみ人が直接承認する体制を運用していると紹介しています。自動化されたレビューやセキュリティチェック、リント、テスト、ビルドなど複数の検証段階を経て、リスク度合いに応じて人の承認ステップを調整しています。実際にマージされたPR数は2倍になったものの、ロールバック率は40％以上減少したと述べています。繰り返されるレビュー指摘はドキュメントやルールで改善し、インシデント事例を毎日の評価に反映してAIレビューアの品質向上に努めているそうです。

補足

著者はClaude Codeチームの実際の運用経験をもとに、自動化コードレビューと人の役割分担の方法を説明しています。具体的な設定値や外部公開されたコード、プロンプト例は含まれていません。チーム内部の信頼基準、リスク分類、承認ポリシーなどは各組織の状況に合わせて調整が必要です。

出典

Anthropic Claude.dev 블로그 原文 ↗

プロンプト例 · Claude Code

目標：コード変更の大部分をAIが自動でレビューし、高リスクな変更のみ人が直接承認するチーム運営方式を実現したい。

必要な入力および環境：
- GitHubリポジトリとプルリクエスト（PR）を基盤とした開発環境
- Claude Code（または類似のAIコードレビューツール）の利用権限
- プロジェクトごとのCLAUDE.md（プロジェクト説明、スタック、ルール等）とREVIEW.md（レビュー基準、失敗例、スキップ経路等）の作成
- リント、型チェック、自動テスト、ビルドなど自動化されたCIパイプライン
- セキュリティレビュー用のGitHub Actionまたは /security-review コマンド
- リスク分類基準（例：低リスク：ドキュメント/内部機能、中リスク：主要機能、高リスク：決済/ビルド/CI等）
- 信頼された作成者リストと承認ポリシー

実装および設定手順：
1. CLAUDE.mdとREVIEW.mdを各リポジトリに作成し、AIレビューアが参照できるようにします。
2. PR作成時に自動で /code-review および /security-review を実行するワークフローを設定します。
3. リント、型チェック、テスト、ビルドなど自動化された検証をPRに統合します。
4. PRテンプレートにテスト方法、リスク度、ロールバック方法を明記する項目を追加します。
5. リスク分類ロジック（例：パス、変更内容、作成者の信頼度に基づく）を実装し、低リスクPRは自動化のみで、中リスク以上は1人または2人の承認を要求します。
6. 信頼された作成者のみ自動化ルートを利用できるようにし、それ以外は常に人の承認を要求します。
7. マージキューで全てのチェックを再実行し、マージ後に問題がないようにします。
8. 新機能はフラグで社内スタッフに先行配布し、段階的に公開します。
9. インシデントやロールバック事例をAIレビューアの評価セットとして活用し、繰り返される指摘はルールやドキュメントで改善します。

成果物：
- ほとんどのPRがAIレビューと自動化検証のみでマージされ、高リスクな変更のみ人が直接承認するワークフロー
- インシデント発生時の迅速なロールバックと原因分析、レビュー工程の改善体制

検証条件：
- PRごとに自動化レビュー、セキュリティチェック、リント/テスト/ビルドが正常に動作するか確認します。
- リスク分類と承認ポリシーが実際に適用されるかサンプルPRでテストします。
- インシデント発生時にロールバックおよび評価体制が機能するか点検します。