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

2026/07/24 CEDEC2026

Transcript

1. エンジニアリング / プロダクション コードレビュー支援ツール開発から学ぶ LLMを用いた業務システムの実践的な運用設計と誤出力対策 株式会社Cygames インフラ / 恩田 大輝 マネージャー / 佐藤 太志 サブマネージャー / 山崎 公之 1 /82
2. LLM導入の壁 LLMを業務システムに取り入れる際に このような課題に直面していませんか ◆ 出力の形式が毎回そろわない ◆ 回答の品質にばらつきがある ◆ 誤情報の出力が利用者の混乱を招く 2 /82
3. 本セッションで得られること LLMを活用したコードレビューシステムの 開発事例を通して、実運用で得られた 設計・品質改善のノウハウを紹介 ◆ LLM を組み込んだシステムの設計 ◆ LLM 特有のもっともらしい 誤情報との向き合い方 ◆ 継続的な運用と品質の改善 3 /82
4. 登壇者紹介 インフラ / マネージャー インフラ / サブマネージャー インフラ 佐藤 太志 山崎 公之 恩田 大輝 SIerを経て、2011年に株式会社 Cygamesへ合流 2016年よりマネージャー 2024年よりエンジニア2部副部長兼任 複数のゲーム会社で開発およびサーバ /ネットワークインフラ業務を経て、 2012年に株式会社Cygamesへ合流 開発支援チームのリーダーとしてイン フラ作業の自動化や効率化を推進 ゲーム開発会社のバックエンドエンジ ニアを経て、2021年に株式会社 Cygamesへ合流 開発支援チームに所属し、コードレ ビュー支援ツールの開発・運用に従事 4 /82
5. インフラセクションの紹介 最高のコンテンツづくりを支える４つの業務領域 ゲームインフラを中心に 開発支援 や セキュリティ など ゲーム開発と運用を多角的に支える組織 セキュリティ 開発支援 ゲームインフラ 分析基盤 5 /82
6. コードレビューに着目した背景 コードレビューは効果が大きい 開発現場の共通課題 AI導入効果の期待 開発プロセスの課題 想定される効果 ◆ レビュー待ちで開発が止まる ◆ レビュワーに負荷が集中する ◆ レビュー品質のばらつき ◆ レビュー待ち時間の削減 ◆ レビュワーの負荷軽減 ◆ レビュー品質の均一化 6 /82
7. コードレビューに着目した背景 実プロダクトへのAI導入には高い壁があった セキュリティ ガバナンス コードレビュー支援は プロダクトへの組み込みは不要 7 /82
8. LLMを使ったツール開発で直面した課題 2024年4月 コードレビュー支援ツールを スタートしたものの課題に直面 品質のばらつき ツールの普及 もっともらしい誤情報 継続的な改善 8 /82
9. 本セッションのテーマ LLMを活用したシステム設計・運用の ノウハウをコードレビュー支援 ツール開発の事例から共有 出力精度と一貫性の向上 継続的なツール改善 9 /82
10. アジェンダ 1. コードレビュー支援ツール「Lyra」とは 2. 品質のバラツキを抑える「構造化出力」 3. 誤出力への対策「マルチエージェント設計」 4. 継続的な改善を支える「運用ダッシュボード」 5. まとめ 10 /82
11. アジェンダ 1. コードレビュー支援ツール「Lyra」とは 2. 品質のバラツキを抑える「構造化出力」 3. 誤出力への対策「マルチエージェント設計」 4. 継続的な改善を支える「運用ダッシュボード」 5. まとめ 11 /82
12. コードレビュー支援ツール 「Lyra」とは 12 /82
13. 「Lyra」の概要 GitHubのプルリクエストをAIがレビュー レビュー結果をコメントでフィードバック 2つの主要機能 開発者 ❶プルリクエスト作成 GitHub ❷レビュー ❺レビュー結果を コマンド検知 コメント ❸レビュー項目を インプット LLM ❹アウトプットを取得 ◆ コードレビュー ◆ プルリクエストの要約・説明 導入の容易さ ◆ GitHubアプリとして提供 ※GitHub Enterprise Server 対応 Lyra 13 /82
14. コードレビュー機能の概要 依頼 Pull Requestに /review or /r とコメント 解析 Lyraが差分・周辺コード・設定を 取得し、レビューを実行 投稿 良い点・改善点・修正案を レビューコメントとして投稿 プルリクエスト上の自然な操作だけで、 コードレビュー支援を開発フローに組み込む 14 /82
15. コードレビュー結果の全体像 レビュー結果サマリー 個別指摘 15 /82
16. プルリクエストの要約・説明機能の概要 依頼 Pull Requestに /summarize or /s とコメント 解析 Lyraが差分・周辺コード・設定を 取得し、PRの要約と説明を自動作成 投稿 概要・詳細・変更一覧を descriptionとして投稿 プルリクエストの概要や変更箇所を自動作成、 レビュー前に変更内容をすばやく把握できます 16 /82
17. Lyra の特徴：柔軟なカスタマイズ 既存のサービスにはなく、内製ツールの強みは… 利用部署やPJに応じてカスタマイズが可能に プロンプトの カスタマイズ カスタムコマンド 多様なLLMの選択 /security-review GPT, Claude 17 /82
18. プロンプトのカスタマイズ（ツンデレ風の例） コメントで追加指示を送るだけで、 レビューの観点や口調を柔軟に変更できます 18 /82
19. レビュー機能 Version3 の特徴 2026年初頭 Version3 をリリース マルチエージェント インタラクティブ フィードバック 19 /82
20. インタラクティブ機能の紹介 修正案をその場で確認 ❶ Suggested changeで具体的な変更を提示 修正案を提示 PR上で追加確認 コメント返信だけで会話を継続 ❷ 開発者が返信 対応後の再確認 修正内容への補足 再レビューを支援 ❸ AIが再確認 プルリクエスト上の自然な操作だけで、 コードレビュー支援を開発フローに組み込む 20 /82
21. フィードバック機能の紹介 指摘単位で評価 とても良い/良い/よくない/全くダメを選択 除外指定 PRで除外/全体で除外を選択し、ノイズを抑制 改善に反映 収集したデータをもとに、継続的に品質を改善 PR上のボタン操作だけで、指摘単位の有用性を収集 利用者の声をデータとして蓄積し、レビュー品質の継続的な向上につなげる 21 /82
22. まとめ｜コードレビュー支援ツール「Lyra」とは ◆GitHub PR上でAIレビュー・要約が完結、 開発フローに自然に組み込める ◆プロンプトやカスタムコマンドを柔軟に設定でき、 チームごとのレビュー観点に適応できる ◆レビュー機能 Version3 により、インタラク ティブ・フィードバックなどの機能を拡張 22 /82
23. アジェンダ 1. コードレビュー支援ツール「Lyra」とは 2. 品質のバラツキを抑える「構造化出力」 3. 誤出力への対策「マルチエージェント設計」 4. 継続的な改善を支える「運用ダッシュボード」 5. まとめ 23 /82
24. 品質のバラツキを抑える 「構造化出力」 24 /82
25. 初期版：LLM の一回の出力でレビューする構成 LLMに整ったMarkdownを書かせ、 そのままGitHubに投稿するシンプルな構成からスタート GitHub PR LLM プロンプト 1回呼び出し 動くものはすぐにできた Markdown形式 のレビュー文章を 生成 GitHubに投稿 一方で、業務システムとして使うには 課題が見えてきた 25 /82
26. 初期版の課題：プロンプトだけでは安定しない ◆表記が揺れる ◼ 見出し・記号・表現粒度が揃わず、分類やパースが不安定 ◆観点・属性が抜ける ◼ 良い点・改善点・重要度など、必要な観点が揃わない ◆データとして扱えない ◼ LLMに出力を委ねると必要な情報を安定して取り出せず、 検索・集計・除外・改善に使えない 26 /82
27. 表記が揺れる：出力例 同じレビューでも、見出し・記号・粒度が揃わない 27 /82
28. 表記が揺れる：分類・パース・集計が不安定になる 分類できない パースが壊れる 集計できない 表記が毎回違うと、 品質・安全性などの分類 が安定しない Markdown頼みだと、 必要な項目を取り出せ ないことがある 形式がそろわないと、 指摘数や傾向を数えら れない 例 「改善点」/「Issues」/「指摘」 例 例 必須見出しが見つからない レビュー品質の変化を追えない 出力を「文章」として期待するのではなく、 「データ構造」として固定する必要がある 28 /82
29. 観点・属性が抜ける：必須項目の欠落 期待される項目が、レビューごとに抜ける 期待される項目 レビューA レビューB レビューC 状態 良い点 安定 改善点 安定 重要度 - - 抜けやすい ファイル/行 - 抜けやすい 推奨事項 - 抜けやすい 29 /82
30. 観点・属性が抜ける：レビュー結果を活用しづらい 比較できない 判断できない 改善できない レビューごとの観点が 揃わず、品質や傾向を 横並びで見られない 重要度や対象行が抜け ると、必須確認が済ん だか判断できない 抜けやすい項目を集計 できず、プロンプトや スキーマの改善に戻せ ない 必須項目をスキーマで固定し、 毎回同じ観点でレビューさせる 30 /82
31. データとして処理できない：自由記述の限界 人は内容を理解できるが、検索・集計に必要な 情報をシステムが安定して取り出せない 自由記述のレビュー 「src/service/user.ts で、取得した user をそのまま参照しているように見 えます。user が null の場合に後続処理 で例外になる可能性があるため…」 何が問題か、どこが対象か、 重要度が文章中に埋もれる フォーマットされたレビュー 問題：null チェックが不足 対象：src/service/user.ts:42 重要度：Important 推奨：早期 return を追加 必要な情報を項目として取り出せる 31 /82
32. データとして処理できない：管理できない情報 レビュー結果から対象箇所・優先度・状態を項目として取得する 指摘箇所が 特定できない 優先度が 分からない 対応状態を 管理できない 必要な情報 ファイル名・行番号 必要な情報 必要な情報 重要度 必要な情報 必要な情報 指摘ID・状態 必要な情報 使い道 使い道： 表示する 使い道 使い道： Critical / Important / Optional に 分類する 使い道 使い道： 除外・再通知・改善 分析に使う GitHubの対象行に 必要な情報を項目として取り出せる形にし 表示・集計・改善につなげる 32 /82
33. 初期版のどこが問題だったか 初期版は、LLMがMarkdownを完成させてそのまま投稿する構成だった この構成で困ったこと 重要度 対象行 指摘ID 採用/却下 ファイル名・行番号・重要度が項目として残らず、 分析・検索・改善サイクルに使いにくい 33 /82
34. レビュー結果を構造化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
35. LLMとLyra側の処理の役割分担 Lyra側（GitHub App)の処理 保存した データ JSON LLM ❶ AWS JSONを返す S3に保存 Mark down API ❷ ❸ テンプレート 適用 GitHubへ 投稿 GitHub PRにコメント LLMに任せるのは、JSONを返すところまで GitHubに出す前にLyra側で保存・整形・投稿する 35 /82
36. 従来のレビュー例：Markdown 直接出力 レビュー例（抜粋） 業務システム視点の問題 ◆ どのファイル・どの行か分からない ◆ どれを先に直すべきか判断できない ◆ 検索・集計・分析に活用できない 読めるが、扱えない 36 /82
37. 構造化後のレビュー例：サマリー表示 箇所 ファイル名・ 行番号で特定 優先度 管理 表示 重要度で順位判断 検索・集計・分析 に活用 テンプレートで統一 37 /82
38. 構造化後のレビュー例：インラインコメント 箇所 ファイル名・ 行番号で特定 優先度 管理 表示 重要度で順位判断 検索・集計・分析 に活用 テンプレートで統一 38 /82
39. 指摘データ蓄積・活用する仕組み 表示に使うJSON 裏側で持つフィールド file line title severity problem recommendation AWS S3 短期 採用 / 却下 / フィードバックを追跡 Finding_id status feedback posted_at … 指摘データを運用改善に活用する仕組み 中期 プロジェクト別・ 時系列で集計・分析 長期 蓄積データでレビュー 内容をチューニング 39 /82
40. まとめ｜品質のバラツキを抑える「構造化出力」 ◆ 構造化出力により、 出力の揺れと項目の欠落を抑える ◆ 表示はアプリ側のテンプレートで制御し、 データと表示を分離する ◆ 構造化出力で、品質のバラツキを抑え、 レビュー結果を運用改善に活用できる 40 /82
41. アジェンダ 1. コードレビュー支援ツール「Lyra」とは 2. 品質のバラツキを抑える「構造化出力」 3. 誤出力への対策「マルチエージェント設計」 4. 継続的な改善を支える「運用ダッシュボード」 5. まとめ 41 /82
42. 誤出力への対策 「マルチエージェント設計」 42 /82
43. 自然に見える誤出力ほど、レビューの手間が増える 明らかなエラーではなく、自然なレビュー文として出るため、 人が確認してはじめて気づける ◆ 明らかな間違いに見えない ◆ 根拠の確認が必要になる ◆ 確認コストが利用者に移る 問題は、誤りそのものではなく、 確認コストが利用者に移ること 43 /82
44. 例：存在しない関数を前提にした指摘 具体的な関数名まで書かれているため、文章だけでは正しそうに見える LLMが出した指摘 実際のコード確認 メールアドレスをそのまま保存す ると、前後の空白や大文字小文字 の違いで重複判定が揺れる可能性 があります。 既存の `normalizeEmail()` を通してから保存してください。 このリポジトリに `normalizeEmail()`は存在し ない。メール正規化の共通関数 も定義されていない。 一見もっとらしく見える指摘 存在しない関数を前提にしている もっともらしい関数名まで書かれているため、 実装と照合しないと気づけない 44 /82
45. なぜ問題か：誤った指摘が利用者のコストになる 確認が必要な指摘が増えるほど、レビュー支援の効果が下がる 確認コスト増 信頼の低下 誤った対応のリスク 指摘ごとに「本当か？」を 毎回確かめる必要が出る レビューシステム自体が 信用されなくなる 不要な修正や、 誤った修正が混入する 誤った指摘をそのまま届けると、 支援のはずが利用者の負担になる 45 /82
46. 設計方針：単一の出力精度を上げる方針には限界があった 初期版 LLM レビュー指摘 もっともらしい誤りは、一回の出力では減らせない 方向転換 出力後に検証し、投稿する指摘を絞り込む 根拠を確認する 根拠のない指摘を 除外する 投稿可否を判定する 「LLM自体の精度を上げる」から 「出力された指摘を検証して採用を制御する」へ 46 /82
47. 作り変えた方向性 根拠を集める 投稿前に絞り込む 判断の根拠を残す 対象コードと周辺情報を 調査してから判断 根拠の薄い指摘は 投稿前に除外 何を見て、 なぜ除外したかを記録 根拠 『そのまま投稿』から、 検証 投稿判定 で支える構成へ 47 /82
48. 試作アプローチ：段階分割で投稿前に絞り込む いきなり投稿せず、複数の段階を通して投稿対象を判断する。 ❶計画 ❷調査 ❸検証 ❹投稿判定 観点・調査個所を 決める 対象コード・周辺情 報から根拠を集める 指摘を否定する情報 がないか確認する 投稿対象の指摘を 決める 根拠の薄い候補を段階的に除外し、 投稿前に採用対象を絞り込む 48 /82
49. 試作方式で見えた成果と課題 良かった点 実運用上の課題 ◆ 誤指摘を減らせた ◆ 根拠の薄い指摘を落とせた ◆ 判断の根拠を残せた ◆ 処理が長くなる ◆ 実装が複雑になる ◆ 新しいモデルを取り込みにくい 業務システムとして使うには、精度だけでなく、 処理時間・実装の見通し・モデル更新への追従性も必要 方向転換へ 49 /82
50. マルチエージェントへの出発点 着想 日常の開発で「複数AIエージェントに批評させ合う」と 誤りが減ることを実感していた ◆相互批評で誤りを潰せる ◆視点の多様性が質を上げる ◆AIエージェントの進化を取り込める 「単一の出力を磨く」のではなく、 「複数のAIエージェントに批評させ合う」設計へ 50 /82
51. 直列の深掘りから、並列エージェントのディベートへ 従来：直列の深堀り 新方針：並列エージェントのディベート 初期版 ディベート プロンプト1回 出力 Agent A Agent B Agent C Agent D 試作版 プラン 調査 検証 投稿判定 ◆ 手順は人が決める ◆ 決まった順番でLLMを呼ぶ ◆ 手順でLLMを縛る使い方 処理・実装が重く、差し替えにくい ◆ ４つのAIエージェントが並列に議論 ◆ ディベートで合意した指摘だけを採用 エージェント単位で差し替え・性能 向上を取り込める この設計方針が「マルチエージェント設計」 51 /82
52. 最終アーキテクチャ 入力 並列レビュー + 4つのエージェントでディベート GitHub PR 差分 （diff） 本文 （PR本文） 設定 （ルール/プロ ンプト等） Security / Claude Quality / Claude 出力制御 採用して公開 合意指摘を表示 GitHub /インラインコメント ４つのエージェントでディベート 相互検証・合意形成 不採用も 折りたたみで投稿 反証・不確実・ノイズ Security / Codex Quality / Codex 折りたたみで投稿 必要に応じて展開 複数視点の合意で、表示する指摘を制御する 52 /82
53. 出力制御 前章で紹介したインライン・折りたたみ表示を使って、 合意結果に応じて採用・不採用を制御 合意結果 重要度ラベル 表示場所 採用（優先度高） Critical/ Important インラインコメント・サマリに件数表示 採用（低） Optional サマリー内に折りたたみ 不採用の指摘 サマリー内に折りたたみ 不採用 利用者に届ける情報量を制御し、 重要な指摘に集中できる状態を作る 53 /82
54. 結果 1：サマリーで件数概要、インラインで詳細指摘 インラインで表示 折りたたみで記載 54 /82
55. 結果 2：候補から信頼できる指摘だけを抽出 種別 件数 生成指摘数 8,652件 不採用指摘数 5,311件 採用指摘数 （約61%） 3,341件 （約39%） 約6割を不採用 反証あり/不確実/ノイズ 約4割を利用者へ 信頼できる指摘だけを届ける 「LLMが出したから出す」ではなく、 合意できたものだけを届ける 55 /82
56. 結果 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
57. まとめ｜誤出力への対策「マルチエージェント設計」 ◆ 単一の出力を信じず、複数視点で検証する ◆ 誤りを前提に、根拠が乏しい出力を除外する ◆ 絞り込むだけでなく、見せ方まで設計する 57 /82
58. アジェンダ 1. コードレビュー支援ツール「Lyra」とは 2. 品質のバラツキを抑える「構造化出力」 3. 誤出力への対策「マルチエージェント設計」 4. 継続的な改善を支える「運用ダッシュボード」 5. まとめ 58 /82
59. 継続的な改善を支える 「運用ダッシュボード」 59 /82
60. 見え始めた品質課題 利用拡大とともに、AIコードレビュー特有の課題が見え始めた 実運用から出てきた声の例 ◆ 巨大リポジトリをレビューしたい ◆ 大規模な差分をレビューしたい ◆ SVGってレビューできるの？ 全部に個別対応すると、調査・実装・検証・保守のコストが増える 60 /82
61. 運用で回避したかったこと ◆使われていない機能の保守を続ける ◼か ◆改善したつもりでも効果が分からない ◆利用実態を見ずに要望ベースで改善判断を行う 対応工数を必要なところに集中させたい 61 /82
62. 改善判断に用いた３要素 ◆使用頻度 ◼ どのくらい使われているか ◆影響範囲 ◼ どの範囲に影響があるか ◆コスト ◼ 対応後に保守し続ける価値があるか ログからこれらの情報を整理できると良い 62 /82
63. 方針 イベントデータからログに出力し、ダッシュボードで可視化 イベントデータ ログ出力 ダッシュボード 可視化することで優先度を決定する 使用頻度 影響範囲 コスト 63 /82
64. 可視化に向けて ◆ 集計に必要なデータを収集 ◼ イベントデータからログに出力 ◆ トレーサビリティの確保 ◼ ユニークIDをログに紐づける 64 /82
65. 集計に必要なデータを収集 GitHub （PRイベント発生） Lyra Webhook (HTTPS) イベントデータから 必要なデータを抽出 イベントデータ ログ コメント本文 /review PR番号 投稿者 コメント本文 その他 メタデータ イベント データ PR番号 投稿者 イベントをキャッチしてデータを抽出し、ログに出力する 65 /82
66. 集計しやすい形式でログに出力 抽出したパラメータを集計しやすいJSON形式でログ出力 GitHubから イベントデータを受信 { “message”: “An error has occurred”, “context” : { “deliveryId”: “XXXX”, “organization”: “PJ_NAME”, “repository”: “REPOSITORY_NAME”, ... } 必要な情報を 抽出 JSONログとして出力 } JSON形式にすることで、BIツール、監視ツール等で応用しやすい形に 66 /82
67. これだけだと不十分 複数のリクエストが同じ時間帯に出力された場合、追跡が困難になる 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
68. 追える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
69. 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
70. トレーサビリティの確保 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
71. ログから集計してダッシュボードを作成 Amazon CloudWatch Log groupに蓄積 Logs Insightsで 集計 Custom Dashboards で可視化 クエリ作成で柔軟なダッシュボードを作成可能 71 /82
72. Lyraダッシュボード（1/4） Review機能の利用頻度 利用頻度をPJ別に確認し、要望に対する対応優先度を決める 72 /82
73. Lyraダッシュボード（2/4） Organization別Review機能の利用頻度 利用頻度をPJ別に確認し、要望に対する対応優先度を決める 73 /82
74. Lyraダッシュボード（3/4） LLM種類別の利用数の比較 利用されているモデルを確認し、提供し続けるかを決定する 74 /82
75. Lyraダッシュボード（4/4） エラーログの一元管理 障害の影響範囲を確認し、改善対応を行う 75 /82
76. 可視化結果 機能別/PJ別 利用数の比較 注力すべき機能の特定 LLM種類別 利用数の比較 障害原因等の特定速度が向上 エラーログの一元管理 改善効果の振り返り 開発コストの低減 解決策の検討が加速 76 /82
77. まとめ｜継続的な改善を支える「運用ダッシュボード」 ◆ 改善判断ができるように必要なデータを 集計できる形でログに残す ◆ ログから調査・分析をできるように トレーサビリティを確保する ◆ ダッシュボードで可視化し、 改善基盤を構築する 77 /82
78. アジェンダ 1. コードレビュー支援ツール「Lyra」とは 2. 品質のバラツキを抑える「構造化出力」 3. 誤出力への対策「マルチエージェント設計」 4. 継続的な改善を支える「運用ダッシュボード」 5. まとめ 78 /82
79. まとめ 79 /82
80. 定着した規模 日別レビュー実行数 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
81. まとめ ◆ LLMの揺らぎ・誤出力を前提に、 構造化出力とマルチエージェント設計で 品質を制御する ◆ 利用実態の可視化から継続的な改善に つなげる 81 /82
82. 82 /82