【CEDEC2026】コードレビュー支援ツール開発から学ぶ：LLMを用いた業務システムの実践的な運用設計と誤出力対策

Embed

Start on current slide

Slide 1

Slide 1 text

エンジニアリング / プロダクションコードレビュー支援ツール開発から学ぶ LLMを用いた業務システムの実践的な運用設計と誤出力対策株式会社Cygames インフラ / 恩田大輝マネージャー / 佐藤太志サブマネージャー / 山崎公之 1 /82

Slide 2

Slide 2 text

LLM導入の壁 LLMを業務システムに取り入れる際にこのような課題に直面していませんか ◆ 出力の形式が毎回そろわない ◆ 回答の品質にばらつきがある ◆ 誤情報の出力が利用者の混乱を招く 2 /82

Slide 3

Slide 3 text

本セッションで得られること LLMを活用したコードレビューシステムの開発事例を通して、実運用で得られた設計・品質改善のノウハウを紹介 ◆ LLM を組み込んだシステムの設計 ◆ LLM 特有のもっともらしい誤情報との向き合い方 ◆ 継続的な運用と品質の改善 3 /82

Slide 4

Slide 4 text

登壇者紹介インフラ / マネージャーインフラ / サブマネージャーインフラ佐藤太志山崎公之恩田大輝 SIerを経て、2011年に株式会社 Cygamesへ合流 2016年よりマネージャー 2024年よりエンジニア2部副部長兼任複数のゲーム会社で開発およびサーバ /ネットワークインフラ業務を経て、 2012年に株式会社Cygamesへ合流開発支援チームのリーダーとしてインフラ作業の自動化や効率化を推進ゲーム開発会社のバックエンドエンジニアを経て、2021年に株式会社 Cygamesへ合流開発支援チームに所属し、コードレビュー支援ツールの開発・運用に従事 4 /82

Slide 5

Slide 5 text

インフラセクションの紹介最高のコンテンツづくりを支える４つの業務領域ゲームインフラを中心に開発支援やセキュリティなどゲーム開発と運用を多角的に支える組織セキュリティ開発支援ゲームインフラ分析基盤 5 /82

Slide 6

Slide 6 text

コードレビューに着目した背景コードレビューは効果が大きい開発現場の共通課題 AI導入効果の期待開発プロセスの課題想定される効果 ◆ レビュー待ちで開発が止まる ◆ レビュワーに負荷が集中する ◆ レビュー品質のばらつき ◆ レビュー待ち時間の削減 ◆ レビュワーの負荷軽減 ◆ レビュー品質の均一化 6 /82

Slide 7

Slide 7 text

コードレビューに着目した背景実プロダクトへのAI導入には高い壁があったセキュリティガバナンスコードレビュー支援はプロダクトへの組み込みは不要 7 /82

Slide 8

Slide 8 text

LLMを使ったツール開発で直面した課題 2024年4月コードレビュー支援ツールをスタートしたものの課題に直面品質のばらつきツールの普及もっともらしい誤情報継続的な改善 8 /82

Slide 9

Slide 9 text

本セッションのテーマ LLMを活用したシステム設計・運用のノウハウをコードレビュー支援ツール開発の事例から共有出力精度と一貫性の向上継続的なツール改善 9 /82

Slide 10

Slide 10 text

アジェンダ 1. コードレビュー支援ツール「Lyra」とは 2. 品質のバラツキを抑える「構造化出力」 3. 誤出力への対策「マルチエージェント設計」 4. 継続的な改善を支える「運用ダッシュボード」 5. まとめ 10 /82

Slide 11

Slide 11 text

アジェンダ 1. コードレビュー支援ツール「Lyra」とは 2. 品質のバラツキを抑える「構造化出力」 3. 誤出力への対策「マルチエージェント設計」 4. 継続的な改善を支える「運用ダッシュボード」 5. まとめ 11 /82

Slide 12

Slide 12 text

コードレビュー支援ツール「Lyra」とは 12 /82

Slide 13

Slide 13 text

「Lyra」の概要 GitHubのプルリクエストをAIがレビューレビュー結果をコメントでフィードバック 2つの主要機能開発者 ❶プルリクエスト作成 GitHub ❷レビュー ❺レビュー結果をコマンド検知コメント ❸レビュー項目をインプット LLM ❹アウトプットを取得 ◆ コードレビュー ◆ プルリクエストの要約・説明導入の容易さ ◆ GitHubアプリとして提供 ※GitHub Enterprise Server 対応 Lyra 13 /82

Slide 14

Slide 14 text

コードレビュー機能の概要依頼 Pull Requestに /review or /r とコメント解析 Lyraが差分・周辺コード・設定を取得し、レビューを実行投稿良い点・改善点・修正案をレビューコメントとして投稿プルリクエスト上の自然な操作だけで、コードレビュー支援を開発フローに組み込む 14 /82

Slide 15

Slide 15 text

コードレビュー結果の全体像レビュー結果サマリー個別指摘 15 /82

Slide 16

Slide 16 text

プルリクエストの要約・説明機能の概要依頼 Pull Requestに /summarize or /s とコメント解析 Lyraが差分・周辺コード・設定を取得し、PRの要約と説明を自動作成投稿概要・詳細・変更一覧を descriptionとして投稿プルリクエストの概要や変更箇所を自動作成、レビュー前に変更内容をすばやく把握できます 16 /82

Slide 17

Slide 17 text

Lyra の特徴：柔軟なカスタマイズ既存のサービスにはなく、内製ツールの強みは… 利用部署やPJに応じてカスタマイズが可能にプロンプトのカスタマイズカスタムコマンド多様なLLMの選択 /security-review GPT, Claude 17 /82

Slide 18

Slide 18 text

プロンプトのカスタマイズ（ツンデレ風の例）コメントで追加指示を送るだけで、レビューの観点や口調を柔軟に変更できます 18 /82

Slide 19

Slide 19 text

レビュー機能 Version3 の特徴 2026年初頭 Version3 をリリースマルチエージェントインタラクティブフィードバック 19 /82

Slide 20

Slide 20 text

インタラクティブ機能の紹介修正案をその場で確認 ❶ Suggested changeで具体的な変更を提示修正案を提示 PR上で追加確認コメント返信だけで会話を継続 ❷ 開発者が返信対応後の再確認修正内容への補足再レビューを支援 ❸ AIが再確認プルリクエスト上の自然な操作だけで、コードレビュー支援を開発フローに組み込む 20 /82

Slide 21

Slide 21 text

フィードバック機能の紹介指摘単位で評価とても良い/良い/よくない/全くダメを選択除外指定 PRで除外/全体で除外を選択し、ノイズを抑制改善に反映収集したデータをもとに、継続的に品質を改善 PR上のボタン操作だけで、指摘単位の有用性を収集利用者の声をデータとして蓄積し、レビュー品質の継続的な向上につなげる 21 /82

Slide 22

Slide 22 text

まとめ｜コードレビュー支援ツール「Lyra」とは ◆GitHub PR上でAIレビュー・要約が完結、開発フローに自然に組み込める ◆プロンプトやカスタムコマンドを柔軟に設定でき、チームごとのレビュー観点に適応できる ◆レビュー機能 Version3 により、インタラクティブ・フィードバックなどの機能を拡張 22 /82

Slide 23

Slide 23 text

アジェンダ 1. コードレビュー支援ツール「Lyra」とは 2. 品質のバラツキを抑える「構造化出力」 3. 誤出力への対策「マルチエージェント設計」 4. 継続的な改善を支える「運用ダッシュボード」 5. まとめ 23 /82

Slide 24

Slide 24 text

品質のバラツキを抑える「構造化出力」 24 /82

Slide 25

Slide 25 text

初期版：LLM の一回の出力でレビューする構成 LLMに整ったMarkdownを書かせ、そのままGitHubに投稿するシンプルな構成からスタート GitHub PR LLM プロンプト 1回呼び出し動くものはすぐにできた Markdown形式のレビュー文章を生成 GitHubに投稿一方で、業務システムとして使うには課題が見えてきた 25 /82

Slide 26

Slide 26 text

初期版の課題：プロンプトだけでは安定しない ◆表記が揺れる ◼ 見出し・記号・表現粒度が揃わず、分類やパースが不安定 ◆観点・属性が抜ける ◼ 良い点・改善点・重要度など、必要な観点が揃わない ◆データとして扱えない ◼ LLMに出力を委ねると必要な情報を安定して取り出せず、検索・集計・除外・改善に使えない 26 /82

Slide 27

Slide 27 text

表記が揺れる：出力例同じレビューでも、見出し・記号・粒度が揃わない 27 /82

Slide 28

Slide 28 text

表記が揺れる：分類・パース・集計が不安定になる分類できないパースが壊れる集計できない表記が毎回違うと、品質・安全性などの分類が安定しない Markdown頼みだと、必要な項目を取り出せないことがある形式がそろわないと、指摘数や傾向を数えられない例「改善点」/「Issues」/「指摘」例例必須見出しが見つからないレビュー品質の変化を追えない出力を「文章」として期待するのではなく、「データ構造」として固定する必要がある 28 /82

Slide 29

Slide 29 text

観点・属性が抜ける：必須項目の欠落期待される項目が、レビューごとに抜ける期待される項目レビューA レビューB レビューC 状態良い点安定改善点安定重要度 - - 抜けやすいファイル/行 - 抜けやすい推奨事項 - 抜けやすい 29 /82

Slide 30

Slide 30 text

観点・属性が抜ける：レビュー結果を活用しづらい比較できない判断できない改善できないレビューごとの観点が揃わず、品質や傾向を横並びで見られない重要度や対象行が抜けると、必須確認が済んだか判断できない抜けやすい項目を集計できず、プロンプトやスキーマの改善に戻せない必須項目をスキーマで固定し、毎回同じ観点でレビューさせる 30 /82

Slide 31

Slide 31 text

データとして処理できない：自由記述の限界人は内容を理解できるが、検索・集計に必要な情報をシステムが安定して取り出せない自由記述のレビュー「src/service/user.ts で、取得した user をそのまま参照しているように見えます。user が null の場合に後続処理で例外になる可能性があるため…」何が問題か、どこが対象か、重要度が文章中に埋もれるフォーマットされたレビュー問題：null チェックが不足対象：src/service/user.ts:42 重要度：Important 推奨：早期 return を追加必要な情報を項目として取り出せる 31 /82

Slide 32

Slide 32 text

データとして処理できない：管理できない情報レビュー結果から対象箇所・優先度・状態を項目として取得する指摘箇所が特定できない優先度が分からない対応状態を管理できない必要な情報ファイル名・行番号必要な情報必要な情報重要度必要な情報必要な情報指摘ID・状態必要な情報使い道使い道：表示する使い道使い道： Critical / Important / Optional に分類する使い道使い道：除外・再通知・改善分析に使う GitHubの対象行に必要な情報を項目として取り出せる形にし表示・集計・改善につなげる 32 /82

Slide 33

Slide 33 text

初期版のどこが問題だったか初期版は、LLMがMarkdownを完成させてそのまま投稿する構成だったこの構成で困ったこと重要度対象行指摘ID 採用/却下ファイル名・行番号・重要度が項目として残らず、分析・検索・改善サイクルに使いにくい 33 /82

Slide 34

Slide 34 text

レビュー結果を構造化JSONで受け取る LLMの構造化出力（JSON）をテンプレートに適用し、GitHubコメントを生成 LLMの構造化出力（JSON） { “file”:”src/service/handler.go”, “line”: 128, “title”: “ユーザー入力の検証漏れ”, “severity”:”High”, “problem”: “入力値の検証が不足しており、予期しないエラーが発生する可能性がある”, “recommendation”: “入力値の検証を追加し、エラーハンドリングを改善する” } テンプレートに適用 GitHubインラインコメント（テンプレート適用後の表示例） L Lyra Comment on lines 128 to 128 タイトルユーザー入力の検証漏れ重要度 High 問題入力値の検証が不足しており、予期しないエラーが発生する可能性がある推奨対応入力値の検証を追加し、エラーハンドリングを改善する内部表現はJSON、表示はテンプレートで制御する 34 /82

Slide 35

Slide 35 text

LLMとLyra側の処理の役割分担 Lyra側（GitHub App)の処理保存したデータ JSON LLM ❶ AWS JSONを返す S3に保存 Mark down API ❷ ❸ テンプレート適用 GitHubへ投稿 GitHub PRにコメント LLMに任せるのは、JSONを返すところまで GitHubに出す前にLyra側で保存・整形・投稿する 35 /82

Slide 36

Slide 36 text

従来のレビュー例：Markdown 直接出力レビュー例（抜粋）業務システム視点の問題 ◆ どのファイル・どの行か分からない ◆ どれを先に直すべきか判断できない ◆ 検索・集計・分析に活用できない読めるが、扱えない 36 /82

Slide 37

Slide 37 text

構造化後のレビュー例：サマリー表示箇所ファイル名・行番号で特定優先度管理表示重要度で順位判断検索・集計・分析に活用テンプレートで統一 37 /82

Slide 38

Slide 38 text

構造化後のレビュー例：インラインコメント箇所ファイル名・行番号で特定優先度管理表示重要度で順位判断検索・集計・分析に活用テンプレートで統一 38 /82

Slide 39

Slide 39 text

指摘データ蓄積・活用する仕組み表示に使うJSON 裏側で持つフィールド file line title severity problem recommendation AWS S3 短期採用 / 却下 / フィードバックを追跡 Finding_id status feedback posted_at … 指摘データを運用改善に活用する仕組み中期プロジェクト別・時系列で集計・分析長期蓄積データでレビュー内容をチューニング 39 /82

Slide 40

Slide 40 text

まとめ｜品質のバラツキを抑える「構造化出力」 ◆ 構造化出力により、出力の揺れと項目の欠落を抑える ◆ 表示はアプリ側のテンプレートで制御し、データと表示を分離する ◆ 構造化出力で、品質のバラツキを抑え、レビュー結果を運用改善に活用できる 40 /82

Slide 41

Slide 41 text

アジェンダ 1. コードレビュー支援ツール「Lyra」とは 2. 品質のバラツキを抑える「構造化出力」 3. 誤出力への対策「マルチエージェント設計」 4. 継続的な改善を支える「運用ダッシュボード」 5. まとめ 41 /82

Slide 42

Slide 42 text

誤出力への対策「マルチエージェント設計」 42 /82

Slide 43

Slide 43 text

自然に見える誤出力ほど、レビューの手間が増える明らかなエラーではなく、自然なレビュー文として出るため、人が確認してはじめて気づける ◆ 明らかな間違いに見えない ◆ 根拠の確認が必要になる ◆ 確認コストが利用者に移る問題は、誤りそのものではなく、確認コストが利用者に移ること 43 /82

Slide 44

Slide 44 text

例：存在しない関数を前提にした指摘具体的な関数名まで書かれているため、文章だけでは正しそうに見える LLMが出した指摘実際のコード確認メールアドレスをそのまま保存すると、前後の空白や大文字小文字の違いで重複判定が揺れる可能性があります。既存の `normalizeEmail()` を通してから保存してください。このリポジトリに `normalizeEmail()`は存在しない。メール正規化の共通関数も定義されていない。一見もっとらしく見える指摘存在しない関数を前提にしているもっともらしい関数名まで書かれているため、実装と照合しないと気づけない 44 /82

Slide 45

Slide 45 text

なぜ問題か：誤った指摘が利用者のコストになる確認が必要な指摘が増えるほど、レビュー支援の効果が下がる確認コスト増信頼の低下誤った対応のリスク指摘ごとに「本当か？」を毎回確かめる必要が出るレビューシステム自体が信用されなくなる不要な修正や、誤った修正が混入する誤った指摘をそのまま届けると、支援のはずが利用者の負担になる 45 /82

Slide 46

Slide 46 text

設計方針：単一の出力精度を上げる方針には限界があった初期版 LLM レビュー指摘もっともらしい誤りは、一回の出力では減らせない方向転換出力後に検証し、投稿する指摘を絞り込む根拠を確認する根拠のない指摘を除外する投稿可否を判定する「LLM自体の精度を上げる」から「出力された指摘を検証して採用を制御する」へ 46 /82

Slide 47

Slide 47 text

作り変えた方向性根拠を集める投稿前に絞り込む判断の根拠を残す対象コードと周辺情報を調査してから判断根拠の薄い指摘は投稿前に除外何を見て、なぜ除外したかを記録根拠『そのまま投稿』から、検証投稿判定で支える構成へ 47 /82

Slide 48

Slide 48 text

試作アプローチ：段階分割で投稿前に絞り込むいきなり投稿せず、複数の段階を通して投稿対象を判断する。 ❶計画 ❷調査 ❸検証 ❹投稿判定観点・調査個所を決める対象コード・周辺情報から根拠を集める指摘を否定する情報がないか確認する投稿対象の指摘を決める根拠の薄い候補を段階的に除外し、投稿前に採用対象を絞り込む 48 /82

Slide 49

Slide 49 text

試作方式で見えた成果と課題良かった点実運用上の課題 ◆ 誤指摘を減らせた ◆ 根拠の薄い指摘を落とせた ◆ 判断の根拠を残せた ◆ 処理が長くなる ◆ 実装が複雑になる ◆ 新しいモデルを取り込みにくい業務システムとして使うには、精度だけでなく、処理時間・実装の見通し・モデル更新への追従性も必要方向転換へ 49 /82

Slide 50

Slide 50 text

マルチエージェントへの出発点着想日常の開発で「複数AIエージェントに批評させ合う」と誤りが減ることを実感していた ◆相互批評で誤りを潰せる ◆視点の多様性が質を上げる ◆AIエージェントの進化を取り込める「単一の出力を磨く」のではなく、「複数のAIエージェントに批評させ合う」設計へ 50 /82

Slide 51

Slide 51 text

直列の深掘りから、並列エージェントのディベートへ従来：直列の深堀り新方針：並列エージェントのディベート初期版ディベートプロンプト1回出力 Agent A Agent B Agent C Agent D 試作版プラン調査検証投稿判定 ◆ 手順は人が決める ◆ 決まった順番でLLMを呼ぶ ◆ 手順でLLMを縛る使い方処理・実装が重く、差し替えにくい ◆ ４つのAIエージェントが並列に議論 ◆ ディベートで合意した指摘だけを採用エージェント単位で差し替え・性能向上を取り込めるこの設計方針が「マルチエージェント設計」 51 /82

Slide 52

Slide 52 text

最終アーキテクチャ入力並列レビュー + 4つのエージェントでディベート GitHub PR 差分（diff）本文（PR本文）設定（ルール/プロンプト等） Security / Claude Quality / Claude 出力制御採用して公開合意指摘を表示 GitHub /インラインコメント４つのエージェントでディベート相互検証・合意形成不採用も折りたたみで投稿反証・不確実・ノイズ Security / Codex Quality / Codex 折りたたみで投稿必要に応じて展開複数視点の合意で、表示する指摘を制御する 52 /82

Slide 53

Slide 53 text

出力制御前章で紹介したインライン・折りたたみ表示を使って、合意結果に応じて採用・不採用を制御合意結果重要度ラベル表示場所採用（優先度高） Critical/ Important インラインコメント・サマリに件数表示採用（低） Optional サマリー内に折りたたみ不採用の指摘サマリー内に折りたたみ不採用利用者に届ける情報量を制御し、重要な指摘に集中できる状態を作る 53 /82

Slide 54

Slide 54 text

結果 1：サマリーで件数概要、インラインで詳細指摘インラインで表示折りたたみで記載 54 /82

Slide 55

Slide 55 text

結果 2：候補から信頼できる指摘だけを抽出種別件数生成指摘数 8,652件不採用指摘数 5,311件採用指摘数（約61%） 3,341件（約39%）約6割を不採用反証あり/不確実/ノイズ約4割を利用者へ信頼できる指摘だけを届ける「LLMが出したから出す」ではなく、合意できたものだけを届ける 55 /82

Slide 56

Slide 56 text

結果 3：ベンチマークでも有効性を確認 SWE-PRBench eval_100 で、Lyraは論文で報告されている各LLM単体のスコアを上回る平均スコア・検出率と、低い誤指摘率を確認 SWE-PRBench paper v1 Table 8 / arXiv:2603.26130 対象平均スコア（Mean）検出率（DRA）誤指摘率（FPRavg） ※低いほど良い 1 Lyra 0.475 0.560 0.119 2 Claude Haiku 4.5 0.153 0.306 0.346 3 Claude Sonnet 4.6 0.152 0.297 0.227 4 DeepSeek V3 0.150 0.312 0.315 5 GPT-4o 0.113 0.220 0.193 平均スコア検出率誤指摘率（Mean）（DRA）（FPRavg） ※低いほど良い +210% +79% -38% 論文内 top mean との比較で向上論文内最大DRA との比較で向上論文内最良FPRavg との比較で低減比較条件：値は論文内で報告のあった各LLMの数値(Table8)。Lyraはマルチエージェント合意型。モデル世代・呼び出し方式が異なる点に留意。調査・合意・出力制御により、ベンチマーク上でも品質向上を確認 56 /82

Slide 57

Slide 57 text

まとめ｜誤出力への対策「マルチエージェント設計」 ◆ 単一の出力を信じず、複数視点で検証する ◆ 誤りを前提に、根拠が乏しい出力を除外する ◆ 絞り込むだけでなく、見せ方まで設計する 57 /82

Slide 58

Slide 58 text

アジェンダ 1. コードレビュー支援ツール「Lyra」とは 2. 品質のバラツキを抑える「構造化出力」 3. 誤出力への対策「マルチエージェント設計」 4. 継続的な改善を支える「運用ダッシュボード」 5. まとめ 58 /82

Slide 59

Slide 59 text

継続的な改善を支える「運用ダッシュボード」 59 /82

Slide 60

Slide 60 text

見え始めた品質課題利用拡大とともに、AIコードレビュー特有の課題が見え始めた実運用から出てきた声の例 ◆ 巨大リポジトリをレビューしたい ◆ 大規模な差分をレビューしたい ◆ SVGってレビューできるの？全部に個別対応すると、調査・実装・検証・保守のコストが増える 60 /82

Slide 61

Slide 61 text

運用で回避したかったこと ◆使われていない機能の保守を続ける ◼か ◆改善したつもりでも効果が分からない ◆利用実態を見ずに要望ベースで改善判断を行う対応工数を必要なところに集中させたい 61 /82

Slide 62

Slide 62 text

改善判断に用いた３要素 ◆使用頻度 ◼ どのくらい使われているか ◆影響範囲 ◼ どの範囲に影響があるか ◆コスト ◼ 対応後に保守し続ける価値があるかログからこれらの情報を整理できると良い 62 /82

Slide 63

Slide 63 text

方針イベントデータからログに出力し、ダッシュボードで可視化イベントデータログ出力ダッシュボード可視化することで優先度を決定する使用頻度影響範囲コスト 63 /82

Slide 64

Slide 64 text

可視化に向けて ◆ 集計に必要なデータを収集 ◼ イベントデータからログに出力 ◆ トレーサビリティの確保 ◼ ユニークIDをログに紐づける 64 /82

Slide 65

Slide 65 text

集計に必要なデータを収集 GitHub （PRイベント発生） Lyra Webhook (HTTPS) イベントデータから必要なデータを抽出イベントデータログコメント本文 /review PR番号投稿者コメント本文その他メタデータイベントデータ PR番号投稿者イベントをキャッチしてデータを抽出し、ログに出力する 65 /82

Slide 66

Slide 66 text

集計しやすい形式でログに出力抽出したパラメータを集計しやすいJSON形式でログ出力 GitHubからイベントデータを受信 { “message”: “An error has occurred”, “context” : { “deliveryId”: “XXXX”, “organization”: “PJ_NAME”, “repository”: “REPOSITORY_NAME”, ... } 必要な情報を抽出 JSONログとして出力 } JSON形式にすることで、BIツール、監視ツール等で応用しやすい形に 66 /82

Slide 67

Slide 67 text

これだけだと不十分複数のリクエストが同じ時間帯に出力された場合、追跡が困難になる time message 10:00:01 イベント受信リクエストA 10:00:02 イベント受信 10:00:04 処理開始 10:00:06 処理完了リクエストB どのリクエストのログか不明（追跡が困難） 10:00:07 処理開始 10:00:08 処理完了 10:00:09 イベント受信 10:00:11 処理開始リクエストC 10:00:12 処理完了 67 /82

Slide 68

Slide 68 text

追えるIDみたいなものがあれば… トレースIDを付与することでイベント処理をID単位で追跡可能にリクエストA リクエストB リクエストC TraceID time message a1b2c3 10:00:01 イベント受信 b4d5e6 10:00:02 イベント受信 a1b2c3 10:00:04 処理開始 a1b2c3 10:00:06 処理完了 b4d5e6 10:00:07 処理開始 g7h8i9 10:00:08 処理完了 g7h8i9 10:00:09 イベント受信 g7h8i9 10:00:11 処理開始 b4d5e6 10:00:12 処理完了どのリクエストのログかIDで判別可能に（追跡が容易） 68 /82

Slide 69

Slide 69 text

TraceIDにGitHubのDeliveryIDを採用 1. ユニークな ID を選定 ◼ Trace ID として GitHub から届く一意な ID（ Delivery ID ）を利用 2. ユニークな ID をログイベントに紐づける ◼ すべてのログイベントに Delivery ID を残すことで、処理の過程を一連の流れとしてログから追えるようになる GitHub WebhookEvent Lyra Delivery ID: a1b2c3 Delivery ID: a1b2c3 ユニークな ID を決めて、すべてのログイベントに付与する 69 /82

Slide 70

Slide 70 text

トレーサビリティの確保 Lyra内のレビュー処理をDelivery IDでつなげるログ出力 Delivery ID イベント単位でユニークな値受付処理 { delivery_id: a1b2c3, level: info, phase: 受付 } バリデーション処理 { delivery_id: a1b2c3, level: info, phase: バリデーション } レビュー処理 { delivery_id: a1b2c3, level: info, phase: レビュー } 出力処理 { delivery_id: a1b2c3, level: info, phase: 出力 } 同じ ID を持たせることで、一連の処理を 1件のリクエストとして追跡しやすい形に 70 /82

Slide 71

Slide 71 text

ログから集計してダッシュボードを作成 Amazon CloudWatch Log groupに蓄積 Logs Insightsで集計 Custom Dashboards で可視化クエリ作成で柔軟なダッシュボードを作成可能 71 /82

Slide 72

Slide 72 text

Lyraダッシュボード（1/4） Review機能の利用頻度利用頻度をPJ別に確認し、要望に対する対応優先度を決める 72 /82

Slide 73

Slide 73 text

Lyraダッシュボード（2/4） Organization別Review機能の利用頻度利用頻度をPJ別に確認し、要望に対する対応優先度を決める 73 /82

Slide 74

Slide 74 text

Lyraダッシュボード（3/4） LLM種類別の利用数の比較利用されているモデルを確認し、提供し続けるかを決定する 74 /82

Slide 75

Slide 75 text

Lyraダッシュボード（4/4）エラーログの一元管理障害の影響範囲を確認し、改善対応を行う 75 /82

Slide 76

Slide 76 text

可視化結果機能別/PJ別利用数の比較注力すべき機能の特定 LLM種類別利用数の比較障害原因等の特定速度が向上エラーログの一元管理改善効果の振り返り開発コストの低減解決策の検討が加速 76 /82

Slide 77

Slide 77 text

まとめ｜継続的な改善を支える「運用ダッシュボード」 ◆ 改善判断ができるように必要なデータを集計できる形でログに残す ◆ ログから調査・分析をできるようにトレーサビリティを確保する ◆ ダッシュボードで可視化し、改善基盤を構築する 77 /82

Slide 78

Slide 78 text

アジェンダ 1. コードレビュー支援ツール「Lyra」とは 2. 品質のバラツキを抑える「構造化出力」 3. 誤出力への対策「マルチエージェント設計」 4. 継続的な改善を支える「運用ダッシュボード」 5. まとめ 78 /82

Slide 79

Slide 79 text

まとめ 79 /82

Slide 80

Slide 80 text

定着した規模日別レビュー実行数 review_count 1.2K 直近1週間で約4,000回のレビュー 1日平均約800回 1K 800 600 2026年6月現在 43 Organizationで採用 400 200 0 5/25 5/26 5/27 5/28 5/29 5/30 80 /82

Slide 81

Slide 81 text

まとめ ◆ LLMの揺らぎ・誤出力を前提に、構造化出力とマルチエージェント設計で品質を制御する ◆ 利用実態の可視化から継続的な改善につなげる 81 /82

Slide 82

Slide 82 text

82 /82