オンラインホワイトボードのMiroは、社内のソフトウェアバグ振り分けを自動化する『BugManager』をAmazon Bedrock上で構築し、AWS Machine Learning Blogでアーキテクチャと成果を公開した。導入前は誤ルーティングによる累計生産性損失が年間42年分に達していたが、本番稼働後はチーム再アサイン回数が6分の1、解決時間が数日から数時間(約5分の1)に短縮された。
中核は2つの基盤モデルの分業である。Amazon Nova Proがバグ報告に添付されたスクリーンショットや画面録画をテキスト化し、Anthropic Claude Sonnet 4が約100チームの責任範囲に分類する。判断材料となる『どのチームが何を所管しているか』はJira・GitHub・Confluence・READMEをAmazon Bedrock Knowledge Basesに取り込み、RAGで参照する。利用者はSlackワークフローから呼び出し、最大5候補チームと根本原因分析を受け取る。
この設計の要点は、組織変更に対して再学習が不要な点にある。チーム再編が起きても、ドキュメントを更新すれば分類根拠が即時に切り替わる。従来の教師あり分類器であれば再ラベリングと再学習が必要だった工程が、Knowledge Basesの再インデックスだけで済む。
日本の開発組織への含意も明確である。Jira/GitHub/Confluenceという構成は多くのエンタープライズで一致しており、Slackをハブとした起票フローも近い。読者がまず行うべきは、自社の誤アサイン率と再アサイン回数を数値で記録し、Bedrock経由の推論コストとの損益分岐を測ることだ。本家ブログには記載のない落とし穴として、Knowledge Bases側のドキュメント鮮度とアクセス権の不整合がそのまま誤分類に直結する点には注意がいる。