0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

チームのレビュー知識をAI化する──Codex×GitHub MCPでPR前チェックを自動化した話

Posted at

背景:レビューは減らない、むしろ増えている

AIによってコード生成速度は劇的に上がりました。
しかし、その一方でレビュー時間は短縮されていません。むしろ次のような状況が起こります。

  • PRの数が増える
  • 差分量が増える
  • 「AIが書いたコードだからこそ慎重に見なければ」と感じる

つまり、AI導入によって書く時間より読む時間が増えたのです。

この構造的課題を緩和するために、「AI自身にレビュー前チェックをさせる」アプローチを試しています。

実施した取り組み

1. GitHub MCPサーバでレビューコメントを収集・学習

まず、WindsurfからGitHub MCPサーバを利用して、直近のPRに付けられたレビューコメントを収集。
レビュワーが実際に指摘した内容を解析し、「今後気をつけるべきポイント」としてまとめました。

この時点で出力されるのは、いわば「チームのレビュー文化をAIが学習した成果」です。

実際に使用したプロンプトは次のとおりです:

現在のブランチで出しているPRにつけられたコメントから、今後気をつけないといけないポイントをチェックリストの形で抽出してください。
抽出した内容をAIにレビューをさせる前提で、内容をマークダウンファイルに出力してください。

2. Codexにチェックリストを読ませてセルフレビュー

生成されたチェックリストをCodexに読み込ませ、
新しいPRを出す前に「このコードは過去の指摘傾向と照らして問題がないか?」を自己チェックさせます。

以下は実際に生成されたチェックリストの一部です👇

🔒 セキュリティ関連

  • XSS対策

    • ユーザー入力やDBの値をHTMLに埋め込むときは必ず htmlspecialchars() でエスケープ

      htmlspecialchars((string)$v, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
      
    • プレースホルダー置換({{key}}形式)も常にサニタイズ

    • テンプレートエンジン(Blade/Twig等)の利用を推奨

⚙️ Laravel / PHP設計指針

  • 依存性注入(DI)

    • コントローラーは具体クラスではなく、インターフェースへ依存する

      // ❌ 悪例
      public function __construct(DashboardNotificationService $service)
      
      // ✅ 良例
      public function __construct(NotificationServiceInterface $service)
      
    • クラスの責務を明確化し、専用/汎用コントローラを明示的に命名する

💡 可読性・命名規約

  • メソッド名から「何を」「なぜ」やっているかが分かるようにする

    // ❌ 曖昧
    public function list()
    
    // ✅ 明確
    public function listDashboardNotifications()
    
  • 1文字変数(n, x, tなど)は避け、文脈に即した命名を

    // ✅ 推奨
    const notificationData = notification.getDetail(id);
    

🧩 Vue / Nuxt のリアクティビティ

  • watchdeepimmediate オプションは慎重に使う
  • DOM更新後の処理には await nextTick() を活用
  • 不要な emit 定義や Teleport の競合に注意

⚠️ エラーハンドリング

  • try-catchでの握りつぶしは厳禁。適切なログや通知を必ず行う

    try {
        await someOperation();
    } catch (e) {
        console.error('Operation failed:', e);
    }
    

⚡ パフォーマンス最適化

  • 大量データ処理でスプレッド構文(...)を多用しない

    // ✅ 推奨
    items.value.forEach((n) => {
        if (processed.has(n.id)) {
            n.read = true;
        }
    });
    

💬 Codexによるチェック結果の一例

Codexには次のようなプロンプトを送っています:

チェックリストの項目ごとに「合格」「不合格」を出してくれる?
不合格であれば理由と修正提案もしてほしいです

実際の出力結果は以下のようになります👇

Finished working

セキュリティ
────────────────────────────
✅ 合格: テンプレート処理時のエスケープ — 文字列埋め込みは DashboardDeliveryHandler 経由で
   テキスト用途に限定され、Vue 側もマスク処理されているため安全です。
✅ 合格: HTMLインジェクション対策 — PlaceholderRenderer の結果はそのまま DOM に差し込まれず、
   フロントで構造化データとして扱われています。

Laravel / PHP ベストプラクティス
────────────────────────────
❌ 不合格: 依存性注入(インターフェース依存)
   DashboardNotificationController が具体クラス DashboardNotificationService に依存しています。
   → NotificationServiceInterface を定義し、DI経由で注入してください。

✅ 合格: コントローラー責務の明確化 — Dashboard専用で命名が明示されています。
✅ 合格: Laravel標準機能の活用 — 一覧取得は cursorPaginate() を使用。
❌ 不合格: メソッド名の明確化 — count() は何を数えるか曖昧です。
   → countDashboardNotifications() などに変更を検討してください。

このように、Codexがチェックリストを基にPRを自動採点し、
「どの項目が不合格で、どう直すべきか」まで提示してくれます。

チェックリストの継続学習と自動更新

レビューが繰り返されるたびにGitHub MCP経由でコメントを再収集し、
チームの傾向を学習し続けます。
たとえば、新しいレビュワーが加わった場合でも、その指摘傾向が自動的にリストへ反映されます。

つまり、レビュー文化そのものをAIに継承させる仕組みです。

今後の展望:AIと人間のすみわけ

最終的には以下のような分業を目指しています。

役割 チェック内容
AI(Codex) 命名、エラー処理、構文・ベストプラクティス
人間(レビュワー) 意図、設計判断、ビジネス文脈

レビューを「減らす」ではなく、「分ける」。
この設計思想が、AI時代の開発フローにおける本質的な効率化だと感じています。

まとめ

AI導入後のレビュー負荷は、コード量の増加ではなく信頼の非対称性から生じています。
そのギャップを埋めるために、

  1. GitHub MCPでレビュー履歴を学習
  2. Codexによるセルフチェックを自動実行
  3. 継続的にチームのレビュー知識を更新

という仕組みを構築しました。

これにより、レビュー効率が向上し、チームの“暗黙知”をAIが学ぶという状態に一歩近づきました。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?