ITSMチケットの知見からKB記事を生成し品質を保つKnowledgeForgeの仕組み

KnowledgeForgeとは

AWSは2026年8月19日付のブログで、ITサービス管理(ITSM)の解決済みチケットからナレッジベース(KB)記事を自動生成するソリューション「KnowledgeForge」を紹介した。企業のサポートチームは毎月数千件のチケットを解決しているが、そこに含まれる症状・根本原因・対処手順の知見は、チケット履歴に埋もれたままだ。次のエンジニアが同じ問題に直面しても、その解決情報を見つけられないという課題に着目する。

ナレッジベース側にも問題がある。重複記事の蓄積、内容の陳腐化、執筆者や時期による品質のばらつきが発生し、検索しても似た記事が並ぶだけで正確な回答にたどり着きにくい。KnowledgeForgeはチケットからの新規記事生成と、既存KBの分類・重複排除・品質スコアリング・低品質記事の書き直しを同時に実行する。最終的な公開にはナレッジマネージャーのレビューと承認が必要で、人の判断が介在する点も特徴だ。

生成とキュレーションの連携

KnowledgeForgeは互いに連携する2つのサブシステムで構成される。生成側は、同じ問題を表すチケットのクラスタを入力として、KB記事と根本原因分析(RCA)文書の2種類を自動生成する。キュレーション側は、新規生成された記事と既存記事の両方を対象に、タイプ分類、重複チェック、品質スコアリング、改善の4段階を実行する。処理後の記事はServiceNowに送られ、ナレッジマネージャーの承認を受ける。承認結果はAmazon DynamoDBに書き戻される。

2つのサブシステムが閉ループを形成している点が新しい。キュレーション側はすべての記事をベクトル化して保存し、生成側は新しい記事を書く前にそのベクトルを参照する。これにより、過去の記事と用語や手順の一貫性を保ち、実在しない手順を生成するリスクを減らす。記事は取り込み、生成、キュレーション、人によるレビュー、閉ループという5段階を経て管理される。

生成処理の実装

生成処理はAmazon ECSとAWS Fargate上のコンテナで実行する。1テーマあたり2文書の生成に数分かかり、処理は静かな時間と大きなバッチが交互に来るバースト型であるため、キュー長に応じてタスク数を増減できる常駐コンテナの方がAWS Lambdaより適しているとAWSは説明する。モデルにはAmazon Bedrock上のAnthropic Claude Sonnet 4.5を使用し、レスポンスストリーミングでトークンの到着に合わせて文書を組み立てる。

1つのチケットクラスタには、キーワード、記事のスコープ、チケットの説明や作業履歴のサンプルが含まれる。新しいファイルがS3バケットに置かれるとAmazon SQSキューにイベントが送られ、コンテナが最大5テーマを同時に処理する。生成前には、その顧客の既存記事から類似する上位5件をベクトルインデックスから取得し、参照情報としてモデルに渡す。参照記事が存在しない場合はチケットデータだけで生成し、手順部分をレビュー対象としてフラグする。

重複検出とオーケストレーション

重複検出にはAmazon S3 Vectorsを採用した。埋め込みベクトルをAmazon S3に直接保存するため、スタンドアロンのベクトルデータベースが不要になる。各記事はAmazon Titan Text Embeddings V2で1,024次元のベクトルに変換され、顧客ごとのインデックスに保存される。課金はクエリとGB単位で、実行ノード単位ではないため、全記事のベクトルを保持してもコストを抑えやすいという判断だ。

重複判定は、コサイン距離0.05(類似度0.95以上)を初期閾値とし、上位5件の既存ベクトルと照合する。AWSはフラグされたペアをサンプリングして閾値を調整しており、緩すぎると誤検出、厳しすぎると言い換え記事の見逃しが発生する。重複が見つかった場合は、新しい記事を残して古い記事を引退させる。キュレーション全体はAWS Step Functionsの分散マップで制御し、分類と埋め込みの第1フェーズと、重複検出・スコアリング・改善の第2フェーズに分ける。第2フェーズは最大40バッチを並列処理するが、重複検出だけはバッチ内で逐次実行し、バッチ間の順序はAmazon SQS FIFOキューで顧客単位に保証する。

制約と導入の前提

Step Functionsの実行状態は256KBに制限されるため、KnowledgeForgeは記事本文をインラインで渡さず、Amazon S3上のポインタを参照する。また、各記事が実行するAmazon Bedrockの呼び出しは5分を超えることがあるため、分散マップのアイテムプロセッサにはEXPRESSではなくSTANDARDを選び、実行履歴をデバッグに残す設計にしている。これらの工夫は、大規模な文書処理パイプラインを構築する際に再利用できるパターンとして公開されている。

導入には、Amazon BedrockでAnthropic Claude Sonnet 4.5とAmazon Titan Text Embeddings V2のアクセス有効化、AWS CDKの知識、そしてS3やS3 Vectors、Step Functions、Lambda、ECS/Fargate、DynamoDB、SQSなどのリソース作成権限が必要だ。コードはaws-samples/sample-knowledgeforgeリポジトリから取得できる。なお、記事中の重複判定閾値はAWS側のデータで調整された値のため、利用するデータに応じて再調整が必要になる可能性がある。