ContractS開発者ブログ

契約マネジメントシステム「ContractS CLM」の開発者ブログです。株式会社HolmesはContractS株式会社に社名変更しました。

Kiro CLIを開発に導入して、AIコードレビューを役割別に並行実行した

はじめに

最近、開発業務にAIアシスタント「Kiro CLI」を導入した。Kiroはターミナル上で動くAI開発支援ツールで、コードの解析やレビューなど幅広いタスクに対応できる。

今回は、Kiroを使ってコードレビューを複数の専門的な観点から並行実行する仕組みを作った話を書く。

課題感

導入前、以下のような課題を感じていた。

  • レビュアーの知識や経験によって指摘内容に偏りがある
  • 脆弱性対応(ライブラリやフレームワークのバージョンアップ)で、対応に必要な知識が不足しており、結果として不具合が多発していた

やったこと

Kiroに対して4つの役割を与え、それぞれの専門的な観点からコードレビューを並行で実行させた。

設定した役割(実際のプロンプトの一部):

### バックエンドエンジニア
**責任範囲**: サーバーサイドロジック、データベース、API実装
**レビュー観点**:
- ビジネスロジックの正確性
- データモデルの整合性
- トランザクション処理の妥当性
- パフォーマンス(N+1、クエリ効率)
- エラーハンドリング
- コーディング規約の遵守

### フロントエンドエンジニア
**責任範囲**: UI/UX、クライアントサイド、API連携
**レビュー観点**:
**バックエンド変更時**:
- APIレスポンス構造の変更影響
- 後方互換性(既存フロントエンドが壊れないか)
- エラーレスポンスの適切性
- JSONシリアライゼーションの問題(循環参照、null値)
**フロントエンド変更時**:
- コンポーネント設計の妥当性
- 状態管理の適切性
- API呼び出しのエラーハンドリング
- ユーザビリティ(ローディング、エラー表示)
- アクセシビリティ
- パフォーマンス(再レンダリング、バンドルサイズ)

### QAエンジニア
**責任範囲**: 品質保証、テスト戦略
**レビュー観点**:
- リグレッションリスクの特定
- テストすべきシナリオ(正常系、異常系、境界値)
- テストカバレッジの充足性
- 既存テストの更新必要性
- エッジケースの洗い出し
- データ整合性の検証ポイント
- 手動テストが必要な箇所

### インフラエンジニア
**責任範囲**: デプロイ、運用、監視、インフラ
**レビュー観点**:
- デプロイ戦略(ダウンタイム、ロールバック)
- データマイグレーションの必要性と手順
- 環境変数・設定の変更
- ログ出力の適切性
- 監視・アラートの追加/変更
- パフォーマンスメトリクスへの影響
- スケーラビリティへの影響
- 依存関係の変更(ライブラリ、バージョン)

効果

人間のレビューだけでは見落としていたであろう指摘が実際に出てきた。

  • BFF(Backend For Frontend)の変更に伴うUI側の修正漏れの指摘(レスポンスボディの構造変更による影響など)
  • 公式ドキュメントに記載されている修正方法と実装が異なる箇所の指摘

また、4つの観点が毎回必ず走るので、レビュアーのコンディションや得意領域に依存しなくなった点も良い。

工夫したこと・ハマりどころ

  • プロンプトで使用するツールを明示的に指定しないと、必ずしも並行実行してくれるわけではない
  • 指摘の出力が長文になりがちで、重要度の判断に慣れが必要(要改善点)
  • 並列実行時、ツール使用の許可を都度求められるため、自動許可の設定をしておかないと4倍の確認が発生するので注意

まとめ

Kiro CLIを使って役割別の並行コードレビューを導入したことで、レビューの質と網羅性が上がった。AIレビューは人間のレビューを置き換えるものではないが、見落としを減らす補助として十分に機能している。

今後はプロンプトの精度をさらに改善しつつ、他の開発フローへの活用も模索していきたい。