Miro が Amazon Bedrock を活用し、ソフトウェアバグの経路特定精度を向上させ解決時間を数日から数時間に短縮

本記事は、Miro の Philipp Pavlov、Dmytro Romantsov、Evgeny Mironenko、Gowri Suryanarayana と共著です。 [Miro](https://miro.com/de/index/) は、世界で 9,500 万人以上のユーザーにサービスを提供する AI 搭載のイノベーションワークスペースであり、チームが非構造化されたアイデアを整理されたワークフローへと変換するのを支援しています。この規模に対応し、システムをさらに強化するために、Miro の開発者体験チームは、現代技術を活用して開発者の生産性を向上させるため、Miro 自身のためのイノベーションワークスペースの構築を決断しました。チームが直面する主要な課題の一つは、ソフトウェアの不具合（バグ）を責任あるチームへ効率的にルーティングすることです。迅速かつ正確なバグのルーティングは、不要なコンテキストスイッチングを取り除き、開発者のフラストレーションを軽減し、解決までの時間を短縮し、最終的にはより良い製品と満足度の高い顧客につながります。Miro では、不具合の多くが内部の SLA（サービスレベルアジメント）を満たせず、主に誤ったルーティングやチーム間での繰り返し再割り当てが原因となっています。この問題により、遅延と重複する調査活動によって、年間推定で 42 年分の累積した生産性が失われています。この課題に対処するため、Miro は AWS のプロトタイピングおよびクラウドエンジニアリング（PACE）チームと連携し、AI を活用した自動バグトライアージのためのソリューション「BugManager」を開発しました。 本稿では、Miro のバグルーティングを改善するために採用したアーキテクチャと技術について詳しく解説します。これにより、チームの再割り当てが 6 分の 1 に減少し、[Amazon Bedrock](https://aws.amazon.com/bedrock/) を活用することで、解決までの所要時間が数日から数時間に短縮されました。 ## チャレンジ：約100のソフトウェアチームへのバグ報告の正確なルーティング 現代のソフトウェア環境におけるバグのトリアージ（選別）を自動化することは複雑です。バグ報告はしばしば不整然としており、文脈が欠落しており、テキスト、スタックトレース、スクリーンショット、さらには動画など多様なデータを含んでいます。多くのチームを抱えるソフトウェア特化型企業ではこの複雑性が倍増し、多数の可能なラベルを持つマルチクラス分類問題となります。Miro のエンジニア組織は約100のチームで構成されており、それぞれが特定の製品側面を担当しています。高精度なバグ分類には、GitHub のプルリクエスト、Confluence ドキュメント、README ファイル、および以前解決されたチケットなど、さまざまなソースから関連する製品情報を報告に付加する必要があります。さらに、組織構造は動的であり、チームの統合や新設、製品の進化によりチームの責任範囲が絶えず変化します。ソフトウェア機能についても同様で、追加、更新、または非推奨となることで常に変化しています。 従来の自然言語処理（NLP）に基づくテキスト分類器、例えばファインチューニングされた BERT モデルやファインチューニングされた大規模言語モデル（LLM）分類器は、こうした動的環境において深刻な制限に直面します。組織変更が発生した際に再学習が必要であり、新しい構造にはラベル付きデータが存在しない可能性もあります。Miro は、ファインチューニングされた GPT モデルに基づく既存のソリューションでパフォーマンスが急速に低下する経験をしました。 これらの課題を認識し、Miro はチーム分類のための最適化されたプロンプトと、文脈取得のための検索拡張生成（RAG）を組み合わせた LLM 駆動のアプローチを採用しました。これにより、より適応性が高く、ゼロトレーニングで済み、精度の高いバグトリアージソリューション「BugManager」が実現されました。 ## BugManager: Amazon Bedrock を活用した RAG ベースのバグトリアージ BugManager は、LLM（大規模言語モデル）を活用したアプローチを採用してバグ分類を行います。新しいバグレポートが受信されると、BugManager の分類システムが即座に動作を開始します。まず、BugManager は [Amazon Nova Pro](https://aws.amazon.com/nova/) の[マルチモーダル画像およびビデオ理解機能](https://docs.aws.amazon.com/nova/latest/userguide/modalities.html) を用いて、スクリーンショットや画面録画などの非テキストデータを解析します。その後、システムは RAG（Retrieval-Augmented Generation：検索拡張生成）技術を活用し、複数のナレッジベースから重要な文脈情報を付加してレポートを強化します。これらのナレッジベースには、過去に解決済みの Jira イシュー、GitHub のプルリクエスト、Confluence のドキュメント、および GitHub の README ファイルなどが含まれています。Amazon Bedrock 上で [Anthropic の Claude Sonnet 4](https://aws.amazon.com/bedrock/anthropic/) を使用することで、システムは強化されたバグ記述と、各チームおよびその責任範囲に関する詳細なテキスト情報を統合し、正しいチームへのルーティングを実行する最適化された分類プロンプトを生成します。オプション機能として、収集した情報に関連するソースコードリポジトリの検索結果を組み合わせて、詳細な根本原因分析も生成可能です。これにより、問題に対するより深い洞察を提供し、解決策に関する仮説を提示することができます。 摩擦のない導入と利用を可能にするために、BugManager はシンプルな Slack ベースのワークフローを通じて Miro エンジニアリングコミュニティに公開されています。以下のスクリーンショットは、ユーザーが BugManager と対話する例を示しています。バグの初期説明に基づき、BugManager は優先順位の高い順に最大 5 つの適切なチームを提案し、その根拠も示します。デフォルトではバグは最も可能性の高いチームへルーティングされますが、ユーザーはこの選択を手動で上書きすることもできます。オプションとして、BugManager は Miro のフルコードベースから取得した情報を元に、報告されたバグの原因分析をエンジニアに提供することもあります。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/03/11/Picture-1-542x1024.png) 次のセクションでは、BugManager のアーキテクチャについて詳しく掘り下げていきます。 ## アーキテクチャの深掘り BugManager は主に Amazon Bedrock を使用します。これは、単一の API を通じて主要な AI 企業から高パフォーマンスなファウンデーションモデル（FMs）を選択できるフルマネージドサービスです。Amazon Bedrock Knowledge Bases、Anthropic の Claude Sonnet 4、および Amazon Nova Pro を Amazon Bedrock で活用することで、Slack に投稿されたバグの説明を Jira に作成されたイシューに変換し、解決のためにチームに割り当てるエンドツーエンドのワークフローを開発しました。 BugManager は [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/)（Amazon EKS）クラスター内で Python マイクロサービスとして実行されます。アーキテクチャとアプリケーションの流れは、以下の図で示されています。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/03/11/Picture-2-1024x579.png) BugManager ワークフローは、以下のステップで構成されています： - ユーザーからのフィードバックレポートを提出する。 - メディア添付ファイルを解析する。 - コンテキスト情報を付与してユーザーのフィードバックを強化する。 - ユーザーのフィードバックを適切なチームへルーティングする。 - 根本原因分析（Root Cause Analysis）を生成する。 - 結果をユーザーに返却してレビューしてもらう。 以下のセクションでは、これらのステップについてより詳細に探求します。 ## ステップ 1: ユーザーからのフィードバックレポートの提出 ユーザーは、専用の Slack チャンネルにフィードバックレポート（例えばバグに関するもの）を投稿します。このレポートにはテキストとメディア添付ファイルが含まれる可能性があります。メディア添付ファイルには、バグを再現する手順を説明した動画（通常は画面録画）、バグの様子を示すスクリーンショット、または機能強化のための製品ページのスクリーンショットなどが含まれます。バグレポートは JSON オブジェクトとして配信され、そこにはコンテンツ（テキスト）と、[Amazon Simple Storage Service](http://aws.amazon.com/s3) (Amazon S3) に保存された添付ファイルへのリンクが含まれています。 ## ステップ 2：メディア添付ファイルの解析 メッセージにメディア添付ファイルが含まれている場合、後続のステップでバグ分析と分類を単一モダリティ（テキスト）で行えるようにするために、これらをテキストに変換する必要があります。ここでは、Amazon Nova Pro の画像理解機能を用いて、メディア添付ファイルの説明をテキストとして解析します。このアプローチにおける一つの課題は、LLM がデフォルトでは文脈を意識していない点です。つまり、画像の種類（通常は Miro 製品のスクリーンショット）に関する情報が欠落しているため、それを特定の有用な方法で解釈することができません。したがって、必要な文脈を提供するために、まずバグテキストに基づいて RAG（検索拡張生成）を実行し、メディア資産に描かれている可能性が高い機能に関する情報をプロンプトに追加します。当社の RAG アプローチでは、Amazon Bedrock Knowledge Bases を使用して、Miro の社内製品ドキュメントから自動的にデータを取得します。これにより、添付ファイルから抽出される情報の特定性が大幅に向上します。解析が完了すると、メディア添付ファイルのテキスト説明が元のバグテキストに追加され、アプリケーションワークフローの次のステップへ引き渡されます。 ## ステップ3：文脈を付与してユーザーフィードバックを強化する 私たちは、Amazon Bedrock Knowledge Bases を使用して、さまざまなソースから自動的にデータを取得し、FM（ファウンデーションモデル）に対して、Miro の内部および外部の多様なデータソースからの文脈情報を提供しました。Amazon Bedrock Knowledge Bases は、セッションコンテキスト管理とソース帰属機能を備えた完全マネージド型機能であり、データソースへのカスタム統合構築やデータフロー管理を行うことなく、インgestion から検索、プロンプト拡張に至るまでの RAG ワークフロー全体を実装できます。具体的には、Amazon S3 と Confluence のコネクタをデータソースとして使用しました。[Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) のオンデマンドサーバーレスオプションである [Amazon OpenSearch Serverless](https://aws.amazon.com/opensearch-service/features/serverless/) をベクトルストアとして構成しました。知識ベースには、以下のデータソースをインデックス化しました：Confluence ドキュメント、Miro ヘルプセンター記事、解決済みの Jira チケット、GitHub README、および Backstage ドキュメント（技術ドキュメントとソフトウェアカタログ）。Amazon Bedrock Knowledge Bases は増分再同期をサポートしており、コスト効果の高い方法で、文書の変更に合わせて知識ベースを最新状態に保つことが容易になります（変更されたドキュメントのみが再埋め込みされ、再インデックスされます）。 ## ステップ4：ユーザーフィードバックを適切なチームへルーティング Amazon Bedrock と Anthropic の Claude Sonnet 4 の支援により、バグを担当チームへルーティングしました。LLM に正確な分類を行わせるために提供されたコンテキストには、拡張されたバグの説明、拡張された添付ファイルの説明（添付ファイルが存在する場合）、および Backstage で中央集権的にキュレーションされバージョン管理されている（GitHub をバックエンドとして利用）チーム説明が含まれます。チーム説明は、必要に応じて随時更新可能な生きたドキュメントです。Miro のプロダクトおよびエンジニアリング組織は動的な構造であり、プロダクト機能の追加や廃止、チームの責任範囲の変更が行われます。BugManager がプロンプトベースのアプローチを採用しているため、これらの変更は、対応するチーム説明（英語で記述された Markdown ファイル）を更新するだけで比較的容易に反映できます。変更は即座に伝播します。以下は、バグからチームへの分類に使用したプロンプスの簡略化版です。出力における タグの使用にご注意ください。これにより、出力の堅牢な解析が可能になります。 翻訳全文 Miro チームの記述 思考を段階的に実行してください！ """.strip() BugManager は、バグからチームへのルーティングにおけるトップ 1 の精度が 75% を超えることを達成しました（これは、微調整された NLP モデルに基づく既存の社内ソリューションと比較して 70% の向上です）。平均分類レイテンシは 53 秒であり、本番環境での展開において実用的であることが証明されました。BugManager は、信頼度順にランク付けされた最大 5 つの有望なチームオプションを返します（正確な数は設定可能です）。トップ 3 の精度は 95% に達しており、これは人間が関与するアプローチと組み合わせることで、さらにトリアージ精度を向上させることが実証されています。これらの結果は、[Anthropic の Claude の拡張思考](https://www.anthropic.com/news/visible-extended-thinking) を通じて可能となりました。これにより、追加で 7〜9% の精度向上が実現しました。 各分類において、このソリューションは特定のルーティング決定が行われた理由についての包括的な根拠も提供します。これは、単一のチームのみを説明なしに返す微調整された NLP ソリューションと比較して、ユーザーの受容性と信頼性を大幅に向上させました。 ## ステップ 5：根本原因分析の生成 BugManager はオプションとして、バグの根本原因分析を生成することができます。再び、Amazon Bedrock Knowledge Bases を使用して必要なコンテキストを提供し、今回は Miro の GitHub コードベース全体を参照元として活用します。根本原因分析の実行中、LLM（Anthropic の Claude Sonnet 4、拡張思考機能を有効化）には、バグの説明、以前に取得されたコンテキスト、およびバグを解決する担当ソフトウェアチームが提供されます。その後、LLM は Amazon Bedrock Knowledge Bases を用いて該当するコードセクションを取得し、観測されたバグの根本原因に関する一連の仮説を生成します。これにより、ソフトウェアエンジニアはアクションの方向性を特定するために必要な調査作業から解放されます。 ## ステップ 6：結果をユーザーに返してレビューしてもらう 分類および根本原因分析（オプション）の結果は、最初に投稿されたメッセージへのレスポンスとして Slack に送信されます。ユーザーはルーティング結果を確認し、必要に応じてデフォルトの選択を変更できます。その後、元のバグ説明と、知識ベースから取得した関連ドキュメント、ならびに根本原因分析の結果を記載した Jira チケットが作成され、選定されたチームに割り当てられます。 ## 結論 BugManager は、Amazon Bedrock を活用した非常に優れたバグトリアージソリューションであり、Miro のエンジニアリング組織全体で大きな成功を収めています。その主な機能は以下の通りです。 - 高精度な初回トライでのバグから担当チームへのルーティング - マルチクラス予測による人間が関与する意思決定のサポートを通じたさらなるパフォーマンス向上 - ユーザー受容性を高める透明性の高いルーティング判断 - 解決を加速させるバグ根本原因分析 - 継続的に更新される組織ナレッジとの連携強化 - チーム責任範囲の変化に対する堅牢性と柔軟性 BugManager は本番環境で数千件のバグとサポートリクエストを正常にルーティングし、Miro の開発ワークフローにおいて卓越した成果を上げています。このシステムにより、顧客サポートリクエストのチーム再割り当てが 6 分の 1 に減少し、解決までの中央値時間が 5 倍改善されました。かつては数日かかっていたプロセスが、今では数時間で完了するようになっています。BugManager は年間を通じて累積した待機時間と調査時間を数年分節約できると予測されており、最終的には Miro の製品体験を大幅に向上させることになります。 独自のフィードバックルーティングシステムを構築し始めるには、AWS の生成 AI リソースとサンプルアーキテクチャ [Generative AI on AWS](http://aws.amazon.com/generative-ai) を探索してください。ここでは、AI 駆動の運用効率化への道筋を加速させるためのステップバイステップガイド、リファレンス実装、ベストプラクティスを見つけることができます。 ## 著者について ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/03/10/Philipp-Pavlov-Profile-Photo-Squared.jpg) ## Philipp Pavlov Philipp は Miro の技術および製品リーダーであり、AI ファーストのデベロッパー支援と大規模な運用効果向上イニシアチブを推進しています。彼は Miro Digital Twin（社内のすべてのシステムにわたるコンテキストを集約し、文脈認識型 AI ワークフローや文脈駆動型の意思決定を可能にする接続されたセマンティック知識レイヤー）に関する作業を主導しています。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/03/11/DSC09649-small.jpg) ## Dmytro Romantsov Dmytro は、クラウドインフラストラクチャ、JVM エコシステム、応用 AI にわたる 12 年以上の経験を持つシニア SRE（Site Reliability Engineer）および Developer Experience エンジニアです。エンジニアリングチームがより迅速に動き、より信頼性高く運用できるよう支援する内部プラットフォームと自動化を構築しています。彼の専門分野には、開発者向けツール、AI の活用促進、ソフトウェアの所有権とガバナンス、コストと運用効率、そしてプロダクションエクセレンス（生産性の卓越）が含まれ、断片化されたシステムを拡張可能な基盤へと変革し、速度、信頼性、ビジネス成果を向上させています。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/03/11/T028Q5EBK-U02HL64KS1M-aab811032c9a-512.png) ## Evgeny Mironenko Evgeny は、フロントエンド、バックエンド、AI 技術を横断して活動するソフトウェアエンジニアであり、スケーラブルな内部プラットフォームの構築を専門としています。彼の焦点は、システムの統合、開発者体験の向上、そして自動化と堅固なエンジニアリング基盤を通じてチームがより迅速に動けるようにすることです。

Miro が Amazon Bedrock を活用し、ソフトウェアバグの経路特定精度を向上させ解決時間を数日から数時間に短縮

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト