30秒サマリー
- AWSが、解決済みITSMチケットを自動でナレッジベース記事に変換するシステムの設計パターンを公式ブログで詳解
- Amazon Bedrock・S3 Vectors・Step Functionsを組み合わせた大規模ドキュメント処理パイプラインの構成が明らかに
- 重複検出・品質スコアリング・コンテンツ改善を自動化しつつ、最終承認は人間のナレッジマネージャーが担う設計
何が起きたか
AWSは公式の機械学習ブログで、社内ITサービス管理（ITSM）の解決済みインシデントチケットをナレッジベース記事へ自動変換するシステム「KnowledgeForge」の実装手法を解説した。
KnowledgeForgeは「生成」と「キュレーション」の2サブシステムで構成される。生成フェーズでは、類似インシデントチケットをクラスタリングし、Anthropic Claude Sonnet 4.5（Amazon Bedrock）を使ってナレッジベース記事と根本原因分析文書の2種類を自動生成する。生成前に既存記事の埋め込みベクトルを参照するRAG（検索拡張生成）を採用し、用語の一貫性確保と手順の創作リスク低減を図る。キュレーションフェーズでは、記事の分類・重複検出・品質スコアリング・低品質コンテンツの改善をAWS Step Functionsで順次かつ並列に処理する。
重複検出にはAmazon S3 Vectorsを活用し、Amazon Titan Text Embeddings V2で生成した1,024次元の埋め込みベクトルを顧客ごとのインデックスに格納。コサイン距離0.05（類似度0.95以上）を初期閾値として意味的な重複を検出し、より新しい記事を残して古い記事を退役させる設計とした。処理オーケストレーションにはAWS Step Functionsの分散マップを2フェーズ構成で使用し、長時間処理に対応するSTANDARDモードを選択している。最終的に生成・改善された記事はServiceNowに送られ、ナレッジマネージャーが承認する人間によるレビューステップを経て公開される。
原典ハイライト
「解決済みチケットが持つ知識はチケット履歴の中に閉じ込められており、同じ問題に直面した次のエンジニアはそれを見つけられない」と原文は課題を提示。KnowledgeForgeは同一のS3 Vectorsインデックスを検索用途と重複検出の両方に流用する設計を採用しており、再実行時は格納済みベクトルを再利用することでBedrockの呼び出しコストを削減できると説明している。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
このブログが示す最大のポイントは、RAGを「検索」だけでなく「重複検出」にも転用するアーキテクチャパターンの汎用性だ。S3 Vectorsを使うことでスタンドアロンのベクトルDBを持たずにセマンティック検索を実現でき、既存のS3環境に追加インフラなしで組み込める。また、生成AIで自動化しつつも最終承認を人間に残す設計は、企業の情報品質ガバナンスとAI活用を両立させるモデルとして参考になる。
日本企業への示唆
社内ヘルプデスクやIT部門を持つ日本企業にとって、蓄積された大量のチケット履歴は「未活用の社内知識」として扱われてきた。本解説で示されたパターン（Bedrock＋S3 Vectors＋Step Functions）はGitHubのサンプルリポジトリ（aws-samples/sample-knowledgeforge）として公開されており、自社環境への応用を検討しやすい。特にServiceNowなど既存のITSMツールを使う企業は、生成フロー部分を自社のチケットシステムに置き換えるだけで同様の知識自動化が視野に入る。閾値チューニング（コサイン距離の調整）は自社データで検証が必要な点、長時間処理設計（ECS Fargate採用の理由）はコスト試算に影響する点を、導入検討段階で確認しておくべきだ。
背景・経緯
原文によれば、KnowledgeForgeはAWSが構築・解説したサンプルソリューションであり、aws-samplesリポジトリとしてコードが公開されている。使用するAmazon S3 Vectorsはオブジェクトストレージと一体化した比較的新しいベクトル検索機能で、原文ではスタンドアロンのベクトルDBを不要にするコスト・運用上のメリットを選定理由として挙げている。サービス自体の提供開始時期については原文に記載がない。
