AWS、生成 AI を活用したサポート業務の近代化とスケーリングを解説

サポート業務の拡張には、チケット数の増加への対応、厳格なサービスレベル合意書（SLA）の遵守、変化するコンプライアンス要件への適応、そして迅速に陳腐化してしまうドキュメントの維持管理が求められます。これらすべてを、人員増に比例しない範囲で実現する必要があります。多くのチームでは、チケット解決に必要な知識が標準作業手順書（SOP）、録画資料、属人的なノウハウといった場所に断片的に散在しており、アナリストは問題解決よりも情報検索に多くの時間を割かざるを得ない状況にあります。

これらの課題に対処するため、AWS 上の生成 AI を活用すれば、運用ワークフローからナレッジを収集し、チケット解決時にそれを活用するとともに、SLA（サービスレベルアグリーメント）に悪影響を与える前にリスクを可視化することが可能です。個々のチケットやドキュメントを孤立して最適化するのではなく、このアプローチはチーム間での作業の流れを決定する基盤プロセスの改善に焦点を当てています。

本記事では、トレーニング動画から標準手順書（SOP）を作成し、検索拡張生成（RAG）を活用してチケット解決を支援し、機械学習（ML）で負荷配分を最適化・SLA リスクを予測する、AWS 上の生成 AI ベースのサポート運用ソリューションの設計と実装方法について解説します。また、エージェント型ワークフローを通じてチケットのタグ付け、コメント追加、ステータス更新といった運用タスクを自動化しつつ、制御性と精度を保つために人間が関与する仕組み（human in the loop）も維持しています。

本記事では実際の運用ユースケースを通じてアーキテクチャを紹介し、このソリューションが金融サービス、ヘルスケア、物流、製造業、エネルギー分野など他の業界でもどのように応用可能かを示します。

運用上の課題

エンタープライズレベルのサポート運用は、プロセスに関する知識に依存しています。しかし組織が大きくなるにつれて、その知識はドキュメント、人材、ツール間に断片化されてしまいます。その結果、単一の障害点が生じるのではなく、小さな非効率性が連鎖して、解決までの遅延、品質のばらつき、反応的な意思決定といった問題が蓄積していきます。

文書は存在しても、知識は定着しない

サポートチームは、リクエストの処理や承認、システム変更の方法を説明する数百から数千もの標準作業手順書（SOP）を維持しています。しかし、これらは通常、特定の機能のために必要に応じて作成されるものであり、システム全体としての視点から設計されたものではありません。各チームが自らのプロセスの一部だけを文書化しており、その業務が上流の入力や下流の手渡し、あるいは他部門との依存関係とどうつながっているかを把握できていないケースがほとんどです。

その結果、個々のタスクをカバーする文書は存在しても、実際の作業がどのようにエンドツーエンドで流れているかを示すものはめったにありません。プロセスに変更が生じると、更新も局所的に行われる（あるいは全く行われない）ため、文書化された内容と現実の乖離はさらに広がります。

同時に、多くの運用知識は研修会議やウォークスルー、トラブルシューティングセッションを通じて共有されていますが、会議が終わればその知識は長い録画ファイルの中に閉じ込められたままです。数ヶ月後には、チームが再度過去のセッションを視聴して「どのようにタスクが行われたか」を再構築しようとするのです。

組織は知識を蓄積するのではなく、同じことを何度も再発見している状態です。文書が正確性を保つためには、運用活動から直接知識を捉え、構造化され検索可能な形式で保存する必要があります。

すべてのインバウンドチケットは、作業を開始する前に解釈され、適切な手順とマッチングされる必要があります。しかし、チケットの到着速度がアナリストの処理能力を上回ると（リーンシックスシグマのタクトタイム原則に違反した状態）、システムにはバックログが蓄積し、遅延が連鎖します。

アナリストは、正しい手順を特定するために、ウィキや共有ドライブ、チャットのスレッド、録画資料など across 広範囲を検索する膨大な時間を費やしています。たとえ適切な標準作業手順書（SOP）が見つかったとしても、それは通常、単一の機能部門の視点しか反映していません。アナリストは、複数の文書を頭の中でつなぎ合わせ、組織内の暗黙知や過去の経験を加味して、完全な解決策を再構築しなければなりません。この作業は組織的な設計に依存するものではなく、個人の専門性に大きく左右されます。

多くの場合、チケットは誤った事象への対応や、解決者が全体像を把握できていないために振り戻されることがあります。実際には、手順のすべてが文書化されているわけではなく、残りは少数の有能なアナリストが持つ暗黙知として存在しています。若手スタッフはエスカレーションに頼らざるを得ず、ベテランスタッフは一般的な質問に対してボトルネックとなっています。

人手で指示を探すことを強いるのではなく、システムはリクエストの内容から自動的にガイダンスを特定すべきです。

作業は実行されるが、プロセスは見えない

チケットが適切に処理されたとしても、チームは業務が実際にはどのよう役割やシステム間を流れているかを把握できていないケースがほとんどです。一部の依頼には複数の承認プロセスや他部門との調整が必要ですが、他のものは数分で解決されます。外部からはどちらも単なるチケットに見えますが、引き継ぎや依存関係の可視化がなければ、管理者は「業務量の多さ」と「複雑度の高さ」を区別できません。その結果、業務配分が偏り、アナリストに過剰な負担がかかり、標準化よりもメンタリングが優先されるようになります。

一貫性を高めるには、単なるチケット数の把握ではなく、組織内での業務の動き方を可視化する必要があります。この「見えない状態」は、SOP（標準作業手順書）が機能ごとに個別に作成され、エンドツーエンドのプロセスがマッピングされていないことに起因しています。ドキュメントが全体のワークフローを反映していなければ、運用視点も当然ながら不十分なものになります。

優先順位は往々にして遅れて特定される

サービス目標の達成には、期限を超過する前にどのチケットがリスクを抱えているかを認識することが不可欠です。しかし、顧客関係管理（CRM）システムでは優先度がインパクトと緊急性に基づいて自動的に割り当てられることが一般的ですが、その判断は通常、アナリストがチケットの詳細を手動で評価することによって行われ、測定可能な指標から導き出されるわけではありません。この課題は、受付段階でのデータ品質の問題によってさらに複雑化します。多くのチケットが不正確または不完全な情報とともにシステムに流入する場合、経験豊富なアナリストであっても真の緊急性を適切に評価することが困難になります。その結果、インパクトの大きい（あるいは可視性の高い）リクエストと通常の業務リクエストが混在し、遅延が目に見えるようになるまで優先順位付けが後回しにされてしまいます。多くのチームは、パフォーマンス指標が悪化してから初めて問題に気づきます。エスカレーションが行われる頃には、すでに期限超過という事態が発生してしまっています。プロアクティブな運用を実現するためには、どのリクエストが目標達成を逃す可能性が高いかを示す早期のシグナルが必要です。

リーダーはオペレーションではなくレポートを見る

長期的に、断片化した知識、偏った業務負荷、受動的な優先順位付けが互いに悪循環を生み出しています。専門性が一部の担当者に集中し、オンボーディングが遅延。スケーリングにはプロセス効率の改善ではなく、人員増発が必要になります。

リーダーは通常、事後報告に基づいてパフォーマンスを把握しますが、報告書は「何が起きたか」は説明できても、「これから何が起こるか」までは示せません。継続的な運用可視性がなければ、ボトルネックは発見が遅れ、キャパシティ判断も後手に回ります。

したがって、サポート業務のスケーリングには、プロセス設計の意思決定（標準作業手順書の構造、承認パス、引き継ぎポイント）が、解決時間や SLA リスク、手戻り率といった運用成果にどう影響するかを可視化する必要があります。つまり、単なる過去指標ではなく、リアルタイムな運用インサイトとガイダンスが不可欠です。

ソリューション概要

マニュアルドキュメントの限界、断片的なチケット処理、受動的な業務管理という課題に対処するため、本ソリューションは AWS 上で実行機能と分析機能を統合した単一の運用システムを実現します。

本ソリューションは、2 つの密接に連携するレイヤーで構成されています。1 つ目は分析担当者が日常業務で使用する「運用インテリジェンス・ワークスペース」であり、2 つ目は分析担当者および経営層がリアルタイムでの洞察と最適化のために利用する「分析・意思決定インテリジェンス・レイヤー」です。

後者のレイヤーでは、アクション可能なインテリジェンスをワークフロー内に直接表示します。これにより、最前線の分析担当者は接続されたデータストリームに基づき、各チケットの真の影響と緊急性を理解できるようになります。同時に、経営層にはパフォーマンス監視や意思決定のガイダンスに役立つ集約ビューを提供します。

図 1: AWS 上のサポート運用ソリューションのエンドツーエンド・アーキテクチャ

1. 運用インテリジェンス・ワークスペース（Amazon Bedrock および AWS Strands Agents SDK） – このレイヤーは、分析担当者やオペレーターが業務を実行する主要な環境です。ドキュメント、チケット分析、バリュー・ストリーム・インテリジェンスを統合したインターフェースで提供します。3 つの中核機能から構成されています。

• 1.1 動画から標準作業手順書（SOP）へ – このツールは、Amazon Bedrock 上でモデル呼び出しを多段階で行うパイプラインを通じて、トレーニング記録やシステムウォークスルーを自動的に構造化された SOP に変換します。その後、視覚的文脈、発話された指示、およびインターフェースの操作を、埋め込まれたスクリーンショットと検証ガイダンス付きの手順書へと変換します。

1.2 チケット解析器

このコンポーネントは、自然言語処理、セマンティック検索、RAG（Retrieval-Augmented Generation）を活用して着信チケットを分析し、関連する手順を特定して文脈に即した解決策のガイダンスを生成します。システムは Amazon Bedrock 上のファウンデーションモデルと照会された標準業務手順書（SOP）やポリシー文書を組み合わせ、組織基準に沿った正確な推奨事項を導き出します。さらに、AWS Strands Agents SDK で構築したエージェントワークフローを活用し、複数の自律型エージェントが連携してチケットのタグ付け、コメント追加、ステータス更新といった運用タスクを遂行します。これらのアクションは、精度・制御・コンプライアンスを確保するため、人間の監視下（human-in-the-loop）で実行されます。

1.3 バリューストリームインテリジェンス

解決ワークフローは、チームやシステム間での作業の流れを示すインタラクティブなスイムレーンマップとして可視化され、ボトルネックを明確に示して継続的な改善を促します。この仕組みにより、上流・下流のプロセスにまたがるデータセットが連携し、関係者は遅延、承認の摩擦、調整の隙間などを即座に把握できます。

2. アナリティクスおよび意思決定インテリジェンス層（Amazon Quick） – アナリティクス層は、Amazon Quick を基盤としたダッシュボードを通じて、リーダーにワークロードの配分、チケット数、SLA リスクに関する中央集権的な可視性を提供します。これによりチームは運用状況を監視し、新たなリスクを特定して、先回りして作業の優先順位をつけることが可能になります。この層には、以下の 3 つの中核機能が含まれています。

• 2.1 ワークロード管理とキャパシティの可視化 – ダッシュボードでは、利用状況インジケーターやトレンドビューを活用し、ボリュームと複雑さの観点からアナリストごとにチケットがどのように配分されているかを表示します。これにより、過負荷状態や未活用領域を明確に浮き彫りにします。

• 2.2 ML によるチケット分類および SLA リスク予測 – ML モデルはチケットを機能的なカテゴリにグループ化し、SLA リスクスコアを付与します。これにより高リスクのケースが表面化し、チームは予測される影響に基づいて優先順位を設定できます。

• 2.3 埋め込ま型エージェント体験 – インテリジェントな Amazon Quick エージェントが、ワークロードの再バランスや優先順位付けのための実行可能な推奨事項を提示します。これらの推奨は監査証跡を完全に保持した監督付きワークフローを通じてレビューおよび実行されます。

これらのレイヤーは独立しているわけではなく、相互に作用し合う循環構造を形成しています。Video-to-SOP は、これまで録画データや属人的なノウハウとして閉じ込められていたプロセス知識を構造化して取り込みます。Ticket Analyzer は、この構造化された知識を活用してリアルタイムの事案解決を導きます。Value Stream Intelligence は、機能ごとに作成されていた従来の SOP からは見えなかったエンドツーエンドのワークフローパターンを可視化します。

各事案が解決されるたびに、また新しい SOP が追加されるたびに、ナレッジベースは強化され、次の解決プロセスはより迅速かつ正確になります。時間の経過とともに、このシステムは「何が起きたか」を記録するものから、「次に何が起こるべきか」を予測するものへと進化していきます。

以下のセクションでは、各コンポーネントの技術設計と、それらが AWS 上でどのように統合されて本番環境で運用可能なアーキテクチャを構築しているかを解説します。

1. オペレーションインテリジェンス・ワークスペース（Amazon Bedrock および AWS Strands Agents SDK）

オペレーションインテリジェンス・ワークスペースは、Video-to-SOP、Ticket Analyzer、Value Stream Intelligence の 3 つの中核機能で構成されています。

1.1 Video-to-SOP

サポートおよび運用チームは、知識の伝達に画面録画や研修セッション、ライブデモを頻繁に活用しています。これらは貴重な組織の専門性を記録した資産ですが、従来は手動でレビューされ、文書化された手順書へと変換する必要がありました。このプロセスは時間がかかり、一貫性に欠け、特定の分野の専門家への依存度が高いため、結果として古びた不十分なドキュメントが作成されるケースが多々ありました。

動画から標準作業手順書（SOP）を生成するツールは、このような手動ワークフローに代わり、Amazon Bedrock と高度な動画理解モデルを基盤とした完全自動化されたマルチモーダルドキュメンテーションシステムを実現します。大規模な動画埋め込み、意味的な検索、生成モデルを組み合わせることで、非構造化された録画データを数分で本番環境対応の SOP へと変換します。以下の図は、録画データのアップロードから SOP の生成までを一貫して行う「SOP Generator」のユーザーインターフェースを示しています。

Figure 2: The SOP Generator interface for uploading recordings

マルチモーダル動画理解

動画が取り込まれると、まず Amazon Bedrock を通じて Marengo Embed 2.7 モデルで処理されます。このモデルは動画を小さく設定可能なセグメントに分割し、非同期で処理を行うため、長時間の動画にも対応可能です。生成されるのは、視覚コンテンツ、発話言語、インターフェースの文脈を統合的に表す高密度なマルチモーダルベクトル埋め込みです。テキストだけの埋め込みに加え、画面内のアクションやユーザーの意図、システムレスポンスが運用ワークフローとどう関連しているかも捉えます。

生成された埋め込みは Amazon OpenSearch Serverless にインデックスされ、これがシステムの拡張可能なベクトルストアとして機能します。これにより、大規模な動画ライブラリや過去の録画データ間での低遅延の類似検索が可能になります。その結果、チームはドキュメント更新に必要な関連するワークフローセグメントを即座に取得でき、手順上の隙間を発見したり、既存のナレッジ資産を再利用したりできます。時間が経つにつれて、この検索層が孤立していたトレーニング動画を、永続的で検索可能なナレッジベースへと変えていきます。

一方、同じ動画コンテンツは Pegasus 1.2 モデル を用いて分析され、生成 AI による動画理解が行われます。この 2 つのモデルはそれぞれ異なる役割を担っています。

Marengo は検索を担当し、動画を検索可能なベクトルに変換することで、拡大するライブラリ内から関連コンテンツを見つけやすくします。一方、Pegasus は理解を担当し、動画を読み込んで SOP（標準作業手順書）生成を駆動するための構造化テキストを生成します。

Pegasus は、細粒度の動画からテキストへの変換を実行し、ステップごとの要約、章ごとの分割、およびアクションや UI 状態に関する構造化された記述を出力します。また、必要な入力、システムからの出力、条件分岐ロジック、承認チェックポイントといった運用メタデータも抽出し、各プロセスの機械可読な表現を作成します。

構造化 SOP の生成

これらの出力は統合され、時間的な動画セグメントと抽出されたアクションや意思決定ポイントを整合させる統一された意味モデルへと組み込まれます。フレームサンプリングや視覚的フィルタリングの手法を適用し、設定変更、フォーム送信、システム確認など、意味のあるワークフローの遷移に対応する代表的なスクリーンショットを選択します。これらの画像は自動的に、関連する手順ステップにリンクされます。

次に、構造化された動画理解データを Amazon Bedrock 上で利用可能な Claude Sonnet 4.6 モデル に渡します。このモデルが正式なドキュメントを生成する仕組みです。

この生成レイヤーは、中間表現を完全な標準作業手順書（SOP）へと変換します。構造化されたステップシーケンス、埋め込まれたスクリーンショット、検証チェック項目、そして期待される結果が含まれています。

タイムスタンプ連動型再生によるインタラクティブな検証

本システムの重要な差別化要因は、インタラクティブな SOP プレビューエディタです。生成された SOP の各手順には、ソース動画内で該当するアクションが発生した正確な瞬間に対応するインタラクティブなタイムスタンプが付与されています。

レビュー担当者が特定のタイムスタンプを選択すると、元の動画がその正確なポイントから再生されます。これにより、ドキュメント化された手順をソース資料と照合してリアルタイムで検証することが可能になります。この仕組みは、書かれた手順とその動画証拠の間に直接的なトレーサビリティリンクを確立し、これが真実の根拠（ソース・オブ・トゥルース）として機能します。

レビュー担当者は、録画全体を手動でスクラブして確認する必要なく、人間が関与するプロセスを通じて各手順を検証できます。