AI主導のソフトウェア開発の世界では、データは現代の新たな「金」と言われています。その中でも「ポストモーテムデータ（事後分析データ）」は、組織が持つ最も価値のある知見の一つです。あらゆるインシデント、障害、ヒヤリハットには「何が問題になり得るか」「どう防ぐべきか」という重要な教訓が含まれています。しかし現在でも、その知見の活用は個々のレビュワーの経験や属人的な知識共有に依存しています。長年蓄積してきたインシデントデータがあるにも関わらず、異なるサービス間で同様の問題が再発するのを体系的に防ぐ仕組みは存在しません。

PayPayでは、開発ワークフローを進化させ、最高水準のコード品質を維持するために常に挑戦を続けています。その一環として、私たちはGBB RiskBotを開発しました。これは、過去のインシデントデータを活用し、組織全体のプルリクエストに潜在するリスクを、能動的に事前検出できるコードレビュー支援システムです。

課題：急成長する組織でのコードレビューの拡張性

PayPayは2018年のローンチ以来、わずか7年で急速に成長してきました。その結果、膨大かつ多様なコードベースを抱える中で、コード品質をいかに維持するかという課題に直面しています。エンジニアは数十のリポジトリで開発を行っており、それぞれ異なる特性やリスクパターンが存在します。 

従来のコードレビュー手法は一定の効果を発揮する一方で、次のような制約があります：

• ナレッジの分断：過去のインシデント知識は特定プロジェクト内に留まり、メンバーの異動や離職で重要なコンテキストが失われる。
• 知識共有の属人化：チーム間での知見共有は手作業で行われ、一貫性に欠ける。
• 再発リスク：中央集約されたインシデント把握がないため、異なるサービス間で類似の問題が再び発生する可能性がある。
• 過去インシデントの文脈の多様性：レビュワーごとに経験レベルも異なるため、リスク評価にばらつきが生じやすい。

GBB RiskBot：自動化されたコードレビューアシスタント

GBB RiskBotは、これらの課題に対処するために開発された、自動化されたリスク検知レビュー支援システムです。開発者がプルリクエストを作成すると、ボットはコード変更を過去のインシデントデータベースと照合し、潜在的なリスクを自動で検出します。

動作概要

本システムは大きく2つの仕組みで構成されています。

ナレッジベース取り込み

• データ取得：GitHub Actions上のcronジョブを利用し、複数のソースから新しいインシデントデータを継続的に検出
• データ前処理：ソースから意味のある情報を抽出し、データベース形式に正規化
• べクトルインデックス化：LangChainでラップしたOpenAI Embeddingsを用いて検索可能なベクトルを生成し、VectorDB (ChromaDB)に保存
  • VectorDB には、pgvector、Weaviate、Pinecone、FAISS、Chroma など多くの選択肢があります。私たちは低コストでPoC（概念実証）のセットアップが容易な ChromaDB を採用しました。

コンテキストコード分析

• PR変更をトリガーにナレッジベースに対して類似度検索を実行
• 類似度検索: コンテキスト（PRタイトル、説明、コード変更すべて）をOpenAI Embedding によりベクトル化
  • パフォーマンス・分析品質・コストを考慮し、各アイテムには強制的に1,000文字の制限を設定
  • 生成したベクトルをもとにVectorDBに対してコサイン類似度検索を実行
  • 上位 K 件の類似ドキュメントを取得
•  RAG応答生成：取得した事実とコード変更を組み合わせ、ChatGPT (gpt-4o-mini) にプロンプトを与えて GitHub コメント形式で分析結果を生成

なぜ GPT-4o-mini で十分なのか？

本システムは関連する過去のインシデント情報を取得するためにセマンティック検索を活用しており、LLMの役割は複雑な推論ではなく、既存の事実を整理して提示することです。重い処理（類似コードパターンの特定や過去インシデントとの照合）は、ベクトル類似検索が行います。、モデルに「何が起こり得るか」をゼロから推論させる必要はなく、「実際に過去に起こったこと」の事例が類似検索の時点で得られているため、それを開発者に読みやすい形式でまとめる作業のみで完結することが出来ます。

コスト

GBB RiskBot の運用コストは、主にナレッジベースのインデックス作成における埋め込み生成と、コード分析におけるチャットモデル推論という 2 つの OpenAI API 利用によって構成されます。

OpenAI API 料金

• 埋め込み（text-embedding-ada-002）：$0.10 / 100万トークン
• チャットモデル (gpt-4o-mini)：
  • 入力： $0.15 / 100万トークン 
  • 出力： $0.60 / 100万トークン

コスト要因

ナレッジベース取り込み（初回DB初期化＋増分）：

• 過去インシデントデータの初期処理（埋め込み生成）
• 新規インシデント（あれば）の検知とインデックス更新

PR 単位の分析（継続コスト）：

• PR コンテキストのサイズ：PRの説明が長いほど入力トークンが増加する
• 変更ファイル数 × 変更行数（LOC）：変更が多いほどトークン消費が増加する
• 変更行数（LOC）：大規模変更はさらにトークン消費を増加させる
• 分析時間：各アイテムが VectorDB 全体と照合されるため、スキャン対象が増えると、分析時間がさらに長くなる

サンプルコスト

47 件のインシデントでデータベース初期化：$0.001852
1 ファイル変更のみの PR を分析：$0.000350

先月（7 月）、12 リポジトリで合計約 380 回以上の実行がありましたが、総コストはわずか$0.59 USDでした。OpenAI API の料金水準を踏まえると、本番インシデントの潜在的コストに比べて極めて費用対効果が高いアプローチです。

成果測定（Success Metrics）

AI を活用したコードレビューの有効性を評価するため、システムの健全性を示す先行指標から事業価値を測る遅行指標まで、 3 階層のメトリクスをモニタリングしています。

Tier 1: コア運用指標（先行指標）

これらのリアルタイム指標はシステムパフォーマンスを即座に把握し、問題の早期発見に役立ちます。

• インシデント検出率：過去インシデントに基づく潜在リスクを検出した PR の割合。高すぎる場合は誤検知が多く、開発者がボット疲れを起こし、本当に重要な警告を無視してしまう恐れがあります。逆に値が低すぎる場合は、学習データ不足や見逃し（偽陰性）の可能性を示唆します。

• • ユニークインシデント・カバレッジ：分析で参照された固有の過去インシデント数。特定の事例に偏っていないかを測ることができ、学習データの品質を示します。

• リポジトリカバレッジ

• ナレッジベース拡張速度： インシデントデータの継続的な拡張を追跡し、システムの学習能力が時間とともに向上しているかを確認します。

Tier 2: 開発者フィードバック（直接指標）

GitHub の絵文字リアクションを使って、開発者は分析に対してフィードバックすることができます。自動ワークフローで毎日過去 7 日分のリアクションを収集し、分析データベース保存してトレンドを可視化します。

Tier 3: ビジネスインパクト（遅行指標）

ROI と組織的価値を示す長期的な指標です。

• インシデント発生率の低減：Bot を導入したリポジトリにおいて、時間経過とともにインシデント発生率が減少しているかを追跡します。

今後のロードマップ

学習データを改善するため、現在の埋め込みモデルを「ada」から「text-embedding-3-large」に変更することを検討しています。また、、CAGやmem0など、RAG以外のモデルアプローチも試していきたいと考えています。。

更に、検索精度を高め誤検知を減らすため、コサイン類似度検索の後に 「rerank」 ステップを追加し、入力との関連性をより改善していきたいです。ます。

まとめ

GBB RiskBot は、テクノロジーを駆使して開発者の生産性とコード品質を向上させるという、PayPayのコミットメントを体現している取り組みのひとつです。

過去のインシデントデータと現代の最新AIを融合させることで、潜在的な問題を検出するだけでなく、開発者教育や組織全体での知識共有にも役立っています。

PayPay のエンジニアリング組織が拡大を続ける中で、GBB RiskBot のようなツールは、高いコード品質と優れた運用を維持するうえでますます重要な役割を果たしていくでしょう。