re:Invent 2024: AWSとCBAが示すAIと人間の協調による知識管理革新
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Leveraging human-AI collaboration to reinvent knowledge management (ARC205)
この動画では、AWSのTechnical Field Communities(TFCs)とCommonwealth Bank of Australia(CBA)の事例を通じて、組織における効果的な知識共有の方法が紹介されています。AWS re:Post PrivateとAmazon Bedrockを組み合わせたGenerative AIの活用により、CBAは技術的な問い合わせの30%削減を目指しています。また、Technical Field Communitiesの構築方法や、200-400レベルの知識体系の整理方法、コミュニティメンバーの巻き込み方についても具体的に解説されています。特に、人間とAIの協調によるCollaborative Intelligenceの実践例として、CBAにおけるインターネットエグレス設定の問い合わせフローの改善事例は、知識共有の効率化における具体的な成果を示しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSのSpecialist Communitiesとre:Inventの紹介
おはようございます。re:Inventへようこそ。皆さんの組織のスキルを向上させたいとお考えですか？イノベーションの急速な進展に伴い、それが難しいと感じていませんか？また、Generative AIのような技術について、従業員の生産性を向上させるためにどのような機会を提供できるでしょうか？
私はAWS Specialist Communitiesチームのリーダーを務めるJohn Bellです。本日は、Collaborative IntelligenceチームのリーダーであるSesi Somarouthu、 オーストラリアとニュージーランドのEnterprise Support LeaderであるRovan Omar、そしてCommonwealth Bank of AustraliaのHead of CloudであるJason Sanderyをお迎えしています。私たちは、AWSとCBAがどのように専門家コミュニティを構築してきたか、そしてAWS re:PostやGenerative AIのようなテクノロジーを活用して知識共有を強化する方法について、ベストプラクティスをご紹介します。
AWSのTechnical Field Communities（TFCs）の構築と運用
まず、私たちが観察してきた一般的な課題についてお話しします。世界中の情報技術において、イノベーションの速度が急速に加速しているのを目の当たりにしています。8年前、私たちが独自の専門家コミュニティの仕組みを構築し始めた時も、そのイノベーションの速度は速いと感じていました。これから8年後を想像してみてください。私たちが提供するサービスや機能、そしてパートナー、お客様、皆様が構築されているものすべてを考えると。さらに、異なる地域、場所、言語で働く人々を含むグローバルな規模での従業員の増加に伴い、生み出され共有される知識の量は増加します。専門家が誰で、どのようにお客様を支援し、知識をキュレーションして世界中で共有するのか、そして製品をどのように改善するのかといったことが、時間とともにますます課題となってきています。
AWSではこれに対応するため、Technical Field Communities（TFCs）と呼ばれる仕組みを構築しました。これは、世界中のプロフェッショナルが技術やビジネスユースケースなどの共通の関心事について協力し合い、専門家が誰で、どのようにお客様と関わっているかを効果的に把握できるよう、意図的に構築された成功のためのコミュニティです。
皆さんが独自のコミュニティや専門家コミュニティを構築する際には、まずスコープについて考える必要があります。専門家に何を知ってもらいたいのか、お客様は何を求めているのか。これに基づいて、どの分野の知識を育てたいのかを決めるモデルを作成します。私は主に2つの軸で考えています。1つは、Generative AI、Compute、Storage、Containerなどの技術です。これらを取り巻くさまざまな技術、つまりサービスやパートナー製品など、さらに多くのものが含まれます。もう1つは、ビジネスの知識、業界の垂直分野、自社に関連する特定のセグメントについて考え、それらがレジリエンスなどにどのように適用されるか、つまり独自のソリューションを構築する際のレジリエントなアーキテクチャの確保などを考えることです。
AWSで構築したコミュニティの一つをご紹介し、それがどのように分解されているかをお見せしましょう。AWSの各コミュニティはグローバルで、組織横断的で、より高度なドメインレベルの知識に焦点を当てています。例えば、データベースの場合、SQL、NoSQL、Timestreamデータベースなどの異なるエンジンに技術を分類し、より深い専門知識を育成するためのサブコミュニティを作成しました。また、Solution Architect、Technical Account Manager、Professional Services、さらにはAsia Pacific、Public Sector、Global Servicesなどの各地域や組織からのメンバーが、それぞれのコミュニティ内にローカルチャプターを持ち、独自の声を発信できるようにしています。これには、これらの組織のリーダーだけでなく、スタッフの思想的リーダーやグローバルレベルでコミュニティを運営するProgram Managerも含まれています。
皆さんが独自の知識コミュニティを構築する際の参考として、あるコミュニティについて詳しくご説明しましょう。画面には Analytics コミュニティを表示しています。ご覧の通り、これには200から400レベルの知識が含まれており、皆さんからの質問を基に、エキスパートに何を知ってほしいかを決定しています。これらは技術的なコミュニティなので、意図的に100レベルは除外しました。100レベルでは、人々が自分で知識を見つけられることを期待しています。AWS re:Postなどの様々なナレッジベースを活用して、情報を見つけ、利用可能なトレーニングを受講し、特定のトピックについてさらに学びたい場合に活用できるようにしています。AWSでは、200レベルではサービス、ソリューション、Analyticsの分野における全体的な製品とそれらの相互作用について考えるような、より高度なレベルを維持することをお勧めしています。これは自己ペースで進められる方式です。
そして、300レベルでは、メンタリング、より深い関与、シャドーイングを行い、知識を構築・維持するためにより多くの時間が必要なエキスパートを育成します。より深いレベルに進むにつれて、Analyticsのようなドメインをビッグデータ、データ処理、補助的なデータサービス、データガバナンスなどのユースケースに分解し、サブドメインの知識を得て、さらにグローバルエキスパートとしてより深い知識を得ることができます。これらのコミュニティは、世界中のパートナー製品に対応するAWSサービスと、ビッグデータやデータ処理の分野で顧客がそれらをどのように使用しているかに基づいて構築されています。
re:Post PrivateとGenerative AIによる知識共有の革新
さて、皆さんが独自のコミュニティを構築する際の例として、ヘルスケア企業の場合を考えてみましょう。ヘルスケア企業では、200レベルから始めて、構築したいコミュニティの範囲に応じて、企業レベルまたは特定のコミュニティレベルで基本的な知識を開発できます。それを定義した後、ヘルスケアにおけるGenerative AIなど、関連する可能性のある技術やユースケースについて検討できます。Generative AI技術と、医療画像や医療機器などの特定のユースケースに対する自社の製品やソリューションをどのように活用するか、デバイスがテクノロジースタック全体でどのように相互作用するか、そしてソリューションを構築するさまざまな方法を考えることができます。その能力が向上するにつれて、Amazon HealthLakeをAnalyticsの上に構築する場合や、自社の特定の製品や技術とそれらが基盤技術とどのように相互作用するかなど、より深いレベルの専門知識を必要とする複雑な質問が出てくるかもしれません。
コミュニティの構築方法と、知識をどのように考え、範囲を分解するかを定義しましたが、次の質問は「どのように参加者を巻き込むか」です。この図はAWSのエンゲージメントフローを示しています。皆さんの会社でも、Solution Architect、Account Managerなどのアカウントチームが顧客と協力して始めるような、同様のエンゲージメントがあると思います。彼らがユースケースに対するソリューションを構築しようとして行き詰まった場合、AWS re:Postやインターネットなどの利用可能なナレッジベースを使用して知識を強化し、問題解決を図ります。リソースを使い果たした場合、エキスパートが必要になるかもしれません。AWSではSpecRegというシステムを構築しました - 皆さんは独自のチケットシステムを持っているか、より独自のものを構築中かもしれません。これにより、ローカルエキスパートが互いに助け合い、workforce全体の知識を向上させながら、一貫したエキスパートエンゲージメントの仕組みを作ることができます。また、ナレッジベースを活用して複雑さの低いリクエストを時間とともに自動化し、エキスパートが最も深く関連性の高いエンゲージメントに集中できるようにします。
次にご紹介したいのは、コミュニティがどのように協力し合えるかという例です。これは Intelligent Document Processing ソリューションの例で、Solutions LibraryやIDPで見つけることができます。このアーキテクチャはコンソールで確認できます。私たちはプロトタイピングチームや法律関連企業と協力して、このような文書の処理時間を短縮する方法を見出しました。この取り組みが企業で成功を収めたとき、他のお客様にとっても有用かもしれないと考えました。そこでMachine Learning技術分野のコミュニティがこのソリューションを採用し、複数のSTEと協力してプロダクション化を進め、アーキテクチャ図やサンプルコードなど、皆様が利用できる多くのリソースを構築しました。これは、Machine Learningコミュニティが、Serverless、データベース、ストレージなどの技術と連携した好例です。
この総合的なソリューションに向けた協力関係により、分野を超えた連携が促進されました。実際のお客様のニーズに基づいて優先順位付けされ、お客様に最適なソリューションを構築し、既存のシステムと共に時間をかけて改良していくことが可能になりました。ここで、このようなコミュニティから得られるデータの成果についてお話ししたいと思います。
エキスパートの関与や知識構築活動を通じて、大量のデータが生成されます。私たちはそのデータを収集し、Amazon Redshiftのようなデータウェアハウスに保存し、その後Amazon QuickSightやAmazon Qなどのテクノロジーを活用してインサイトを導き出します。私たちはこれをコミュニティで実践しており、収集した全ての知識や情報をAmazon Qに入力することで、様々な場所で異なるテクノロジーに焦点を当てているフィールドスタッフが、自分のビジネスに関連する質問をして、カスタマイズされた回答を得ることができます。このアプローチにより、AWSが持つ幅広いコミュニティ全体にわたるアドホックな質問に対応することができます。
このシステムは、メンバーの活動成果やコンテンツ・アセットのインパクトを示すことで、メンバーの貢献を認識することができます。また、フィールドからの繰り返される質問を分析することで、製品やサービスの改善点を特定し、頻繁な問い合わせの原因となる根本的な問題に対処することも可能です。AWS Control Tower、AWS IoT Greengrass、その他のサービスでも、この例が複数見られます。
知識の話から始めましたので、最後も知識についてお話ししたいと思います。人々が専門知識を維持するためには、それに関わり、活用する時間が必要です。コミュニティへの参加が追加の負担ではなく、業務目標と整合性を持つようにすることが重要です。re:Inventに参加されている皆様のように、知識を深める方法を考えてみてください。AWS Certified Solutions Architectのエキスパートブース、ピアトーク、その他のセッションに行かれると、スピーカーやレビュアーの約80%がAWSテクニカルフィールドコミュニティのメンバーであることがわかります。
また、メンバー同士のネットワーキングの機会も重視しています。Technical Field Communityのサミットウィークを主催し、世界中のローカルチャプターを通じてネットワーキングイベントを開催しています。人々が出会い、お互いを知り、時間をかけて持続的な関係を築くことが重要です。AWSコミュニティの活用方法や、私たちがどのようにコミュニティを構築しているか、そしてあなたがどのようにコミュニティを構築できるかについてのベストプラクティスをお話ししました。ここで、re:PostやGenerative AIなどのAWSテクノロジーを活用して、人間とAIのコラボレーションを通じて知識をスケールさせる方法について、Sesiからお話しいただきます。
Collaborative Intelligenceの概念と実践
ありがとうございます、John。皆さん、おはようございます。本日はお招きいただき、ありがとうございます。私はAmazon Web ServicesのコラボレーティブインテリジェンステクノロジーリーダーのSesi Somarouthuです。Johnから、組織全体で再利用可能な知識を構築するためにコミュニティを結集することについてお話がありました。皆さんは既に、日々の業務においてGenerative AIの革新的な可能性を経験されているかもしれません。本日は、これら2つの強力な力を組み合わせて、Collaborative Intelligenceを推進し、知識をスケールさせる方法についてお話しさせていただきます。
Collaborative Intelligenceとは、人間とAIが協力して問題を解決するアプローチです。Generative AIは革新的で、大量のデータやコンテンツを処理し、誰もが利用できるインサイトやコンテンツを生成することができます。人間は、知識を価値あるものにするために不可欠な、ニュアンスのある文脈と判断を提供します。これら2つの強力な力を組み合わせることで、集合知を構築し、知識管理における生産性を継続的に向上させることができます。競争優位性を維持し、継続的な改善とイノベーションを推進することが、あらゆる組織にとって重要であり、Collaborative Intelligenceはその過程で重要な役割を果たします。
Collaborative Intelligenceの概念は全く新しいものではありません - 人間の翻訳者と機械翻訳は、20年以上にわたって協力し、技術コンテンツの翻訳の改善に取り組んできました。このフライホイールで示されている翻訳の過程は、技術コンテンツ領域における翻訳ベンダーによって作成された膨大な翻訳メモリから始まります。この翻訳メモリには、様々な言語のテキスト文字列が含まれており、機械翻訳エンジンが翻訳入力を受け取ると、翻訳メモリを使用して出力を生成します。この出力は必ずしも100%正確ではないかもしれません。そこで人間の専門家が人手による後編集を通じて介入し、翻訳コンテンツが言語の専門家によって継続的に改善され、品質が維持されることを確保します。
これらの言語の専門家は、各言語における文脈とニュアンスが保持されることを確認します。人間の専門家によって生成されたすべてのフィードバックは翻訳メモリに戻され、翻訳の継続的な改善を推進します。これにより、過去20年間にわたって翻訳品質の継続的な向上が実現されてきました。このコンテキストにおいて、Collaborative Intelligenceは、人間が品質を確保しながら、迅速なコンテンツ処理と翻訳を可能にし、協調的なインテリジェンスを推進してきました。
このコンセプト自体は全く新しいものではありませんが、ナレッジマネジメントにおける具体的な応用についてお話ししたいと思います。Johnが言及したように、Technical Field Communitiesは組織全体で再利用可能な膨大なデータとナレッジを生み出してきました。このナレッジは多くの従業員にとって価値があり、同様に皆様の組織でも、従業員が活用できる豊富なナレッジが存在しているかもしれません。Generative AIの進化により、私たちは大規模な言語モデルをAWSのナレッジコーパスで学習させました。モデルを学習させることで、一般的な問題に対する回答やソリューションを生成できるようになりました。
しかし、技術革新が絶え間なく続き、テクノロジーが急速に進化する中で、これらのソリューションや回答が常に正確とは限りません。昨日生成されたナレッジが、今日では正確でなくなったり、関連性を失ったりする可能性があります。ここで人間の専門家が重要な役割を果たします。人間の専門家は、大規模言語モデルが生成した出力や回答が、今日のコンテキストや現状においても妥当であることを検証します。そのフィードバックに基づいて情報が確認され、キュレーションされたナレッジベースに再度取り込まれ、ナレッジフライホイールが形成されます。このナレッジフライホイールは、ナレッジの継続的な品質を確保し、組織全体でスケーラブルなナレッジマネジメントを実現するために不可欠です。
では、組織内でこれらのナレッジのベストプラクティスを取り入れ、このナレッジフライホイールを構築する方法について説明しましょう。ナレッジネットワークを構築するには4つの重要な要素があります。1つ目は Subject Matter Expert です。Johnが言及したように、専門家を招いてコミュニティを作ることができます。これらの専門家は、豊富な実践的知識を持っており、組織のナレッジベースという形でナレッジを外部化することで大きな価値を提供します。皆様の組織では、すでに社内の質問に答えるために使用される膨大なナレッジベースやドキュメントが存在するかもしれません。
3つ目の要素は、組織に専門家がいるのと同様に、AWSにはデータベース、Analytics、Generative AI、さまざまな技術や業界領域のエキスパートであるTechnical Field Communitiesがいます。これらの専門家は、お客様と協力して問題を解決し、一般的なソリューションを提供してきました。また、AWSのイノベーションのスピードに伴い、長年にわたって蓄積された膨大なAWSのナレッジも持っています。これら4つの機能をGenerative AIと統合することで、組織全体で動的に相互接続され、継続的に進化するナレッジネットワークを構築できます。この協調的なアプローチにより、
組織はナレッジマネジメントの実践をスケールさせ、開発者の生産性向上を支援することができます。ここで、AWS re:Post Privateをご紹介したいと思います。これは独自のクラウドプラクティスコミュニティを構築するために特別に設計されたサービスです。独自のプライベートナレッジベースを構築し、組織内のパブリックおよびプライベートなナレッジを統合して、開発者の生産性を継続的に向上させ、イノベーションを推進することができます。
re:Post Privateの主要な機能についてご説明させていただきます。組織内には、新しく参加する多くの開発者がいて、テクノロジーの進化に伴って継続的にスキルを変革していく必要があります。これらの開発者のために、特定のトピック、科目領域、ドメイン、スキル、あるいはペルソナに関する体系的な学習パスを作成することが非常に重要です。例えば、DevOpsエンジニア向けのGenerative AIの学習パスを作成したい場合、re:Post Privateを活用できます。これらの学習パスには、組織内のコンテンツ、LMS内のコンテンツ、またはAWSのパブリックナレッジからのコンテンツを含めることができます。
re:Post Privateを使用して、クラウドのCommunity of Practiceを構築することもできます。 組織にとって、ベストプラクティスの作成と普及を支援するクラウドのCommunity of Practiceを持つことは不可欠です。スケールに対応するための設計方法、レジリエンスのための設計方法、クラウド実装の一環として運用の優秀性とコスト最適化を確保する方法など。多くのクラウドセントラルチームがこれらのベストプラクティスを作成し、組織全体に展開しています。
Johnが言及したように、様々なコミュニティを通じて蓄積できる知識が多くあるかもしれません。組織内で検索可能で、再現可能で、スケーラブルで、セキュアなナレッジベースを構築し、開発者が協調的な環境で質問し回答することを支援することで、重複した質問を排除できます。プライベートな討論フォーラムを作成でき、 スキルや役割が変化しても組織全体で再利用できます。このプライベート討論フォーラムは永続的で、知識へのアクセスに役立ちます。
コミュニティメンバーがこれらのプライベート討論フォーラムに参加し、 関与するために、re:Post Privateはポイントベースの報酬システムを備えた組み込みのゲーミフィケーション機構を提供し、リーダーボードを通じて上位貢献者を認識します。AWS re:Post PrivateがAmazon Bedrockと統合されていることをお知らせできることを嬉しく思います。 これはGenerative AIフレームワークで、プライベートな知識とAWSのパブリックナレッジを一つの場所に集め、質問に対して文脈に応じた回答を提供します。
re:Post PrivateはAWSのマネージドサービスで、数十から数千の開発者までスケールできます。私たちAWSはこのテクノロジーを6年以上使用してきました。そして、Commonwealth Bank of AustraliaがAWS re:Post Privateを使用して開発者の生産性を向上させ、継続的なイノベーションを推進している実際のユースケースについて、RovanとJasonにご説明いただくことを楽しみにしています。
Commonwealth Bank of AustraliaのCloud Foundationsと課題
私はAWSのPrincipal TechnologistのRovanです。Technical Field Community（TFC）に7年以上所属しており、APAのResiliency TFCの共同リーダーを務めています。Commonwealth Bank of Australiaのエンタープライズサポートチームのリーダーとして5年以上携わってきました。この長年の関係により、銀行の業務方法、プロセスの確立方法、直面している課題について理解を深め、それに応じたソリューションを提供し、サービスを彼らのニーズに合わせて形作ることができています。それでは、Commonwealthから参加しているJasonをご紹介します。
ありがとう、Roy。私はJason Sanderyで、Commonwealth Bank of AustraliaのCloud Foundationsクルーのクルーリーダーを務めています。シドニー、メルボルン、ブリスベン、そしてインドに分散する12のスクワッドで構成される約120名のエンジニアを率いています。私たちのクルーは、AWSネイティブとグループ間のインターフェースの構築を担当しており、多くの自動化された制御、予防的制御、検知制御、そしてEgress/Ingress、Private Link、その他の重要なサービスなどの中央サービスの構築を担当しています。
Commonwealth Bank、オーストラリアでの呼び名ではCBA（私たちは何でも短縮するのが好きなので）についてご紹介させていただきます。CBAはオーストラリアを代表する金融機関で、リテール、商業、法人など、あらゆる形態の銀行業務を手がけており、総顧客数は約1,700万人に上ります。CBAグループには、西海岸で大きな存在感を持つ主にデジタルバンキングを展開するBank Westや、ニュージーランドのASB（Auckland Savings Bank）も含まれています。オーストラリアにおいてこれだけ多くの顧客を抱えているため、私たちはオーストラリア経済にとって非常に重要な存在です。実際、オーストラリアの取引の50%以上が毎日私たちのシステムを通じて処理されているため、レジリエンシーとセキュリティを維持しながら、グループとしての開発速度も保つことが非常に重要です。
CBAは顧客重視を徹底しており、私もそれを非常に大切にしています。私たちは社内のエンジニアに提供するソリューションにも同じ理念を組み込もうとしています。CBAは真に顧客中心の銀行であり、顧客が必要とする時にいつでも対応できるよう努めています。私たちにとって、それは可能な限り早く質の高い製品を市場に提供できることも意味します。CBAはクラウドを長年活用してきましたが、その歴史の詳細は割愛させていただきます。この10年ほど、私たちは制御要素の強化とセキュリティインシデントの防止に重点を置きながら、DevSecOpsと開発速度にも大きく注力してきました。これを実現するために、自動化された手順を構築し、シフトレフトの考え方を積極的に推進しています。
リフト＆シフトから始めたのは良かったのですが、モダナイゼーションにも大きく力を入れてきました。現在、数千のアプリケーションをクラウドに移行する際の重点は、FinOpsなどの最適化に移行しつつあります。毎日数千人のエンジニアが私たちのプラットフォームで作業している中で、デリバリーの最適化は非常に重要です。Commonwealth Bankを含む中大規模企業での観察によると、組織が成長し、異なるチームに分かれ、アプリケーションを構築し、AWSのフットプリントを変更して成長していく中で、サイロ化が自然に進むという共通のパターンが見られます。これには特定の問題が伴い、チーム間の可視性の欠如、コミュニケーションの分断、そして多くの企業で一般的な問題である属人的な知識の蓄積などが見られます。
これらの問題が発生すると、チームにどのような影響があるのでしょうか？コミュニケーションが円滑に流れないため、結果が遅れ、ボトルネックが発生します。また、エンジニアや開発者が適切な情報や質問への正確な回答を探そうとしたり、時には他の場所で既に行われた作業を重複して行ったりするため、生産性が低下します。このような課題が、re:Post Privateの開発につながったと言えるでしょう。先ほど触れたように、非常に価値のある暗黙知が往々にしてサイロ化されています。また、私たちが全てのエンジニアに共有できなかった貴重な情報として、サポートチケットがあります。私の社内のクラウドチームだけでも、CBA内部で約900件のサポートチケットを処理しており、さらにAWSに直接登録される何百件ものサポートチケットがあります。このデータセットには、エンジニアにとって価値のある情報が豊富にありますが、利用可能な形で提供されていませんでした。また、大規模な組織で多くのエンジニアがいるため、Teamsチャット、Jira、サポート情報など、様々な形で支援情報が分散してしまいました。これらが検索可能な形になっていなかったため、問題に対する迅速で簡単な回答を得ることができませんでした。
知識共有の効率化に関して、サポート情報以外にも、エンジニアがホワイトペーパーを一元的な場所で公開することが困難でした。CBAには私が非常に価値を置く巨大な技術コミュニティがあり、彼らのアイデアや知識を共有する場を提供しつつ、その情報が効果的にインデックス化され活用されることを確保したいと考えています。
最も困難な課題の1つは、質問が繰り返されるという問題です。エンジニアは一人一人異なりますが、彼らが抱える問題の多くは似通っており、様々なチャネルで同じような質問が繰り返し行われていることがわかりました。質問の表現は少しずつ異なりますが、多くの場合、求める結果は同じです。これは、顧客にとっても、これらのリクエストに対応する技術コミュニティにとっても、フラストレーションの原因となっています。また、これほど多様なヘルプ、サポート、コミュニティ貢献のチャネルがあると、これらの人々を適切に評価することが難しくなります。私の技術コミュニティに貢献している多くの人々は私のチームのメンバーではありませんが、報酬のあるコミュニティを構築するためには、kudosや内部的なポイント制度を通じて、彼らに認識を与える必要があります。
私たちが観察してきたことは、組織全体に共通する課題です。これは、Jasonが説明した技術フィールドコミュニティと、re:PostおよびそのGenerative AI機能が、サイロを解消し、チーム間のコミュニケーションと可視性を効率化することで解決できる部分です。どの組織でもそうですが、CBAもデータ、コンテキスト、プロセスを異なるリポジトリに保存しており、おそらく3つのバケットやSharePoint、ウェブサイト、GitHubなどに分散しています。Amazon Bedrockを活用したエージェントを備えたre:Postは、これらのリポジトリに接続し、このコンテキストと情報にアクセスすることができます。
Commonwealth Bankのエンジニアがre:Postに質問を投稿すると、Generative AI搭載のエージェントが回答を提供します。ただし、AWSのホワイトペーパーやCommonwealth Bankのリポジトリに情報がない新しい質問や問題の場合もあります。そのような場合、その質問をAWSサポートにエスケーレーションして介入し、回答を提供してもらうことができます。Enterpriseサポートにアクセスできる場合は、アカウントに割り当てられたチームがガイダンスを提供できます。そこから、銀行内の技術コミュニティがこの新しい知識を取り入れ、リポジトリに新しいコンテキストとして追加することができます。これにより、Amazon Bedrockがアクセスできるリポジトリにフィードバックされ、知識管理のフライホイールが生まれます。
re:Post Privateの導入とCBAでの活用
私たちが最初に行ったこと、そして皆さんにもお勧めしたいことは、達成すべき目標をNorth Starとして設定することです。最初の目標の1つは、AWSの豊富な情報とグローバルサポートコミュニティを活用しながら、CBAのコンテキストを追加することでした。シンプルに聞こえるかもしれませんが、実際にはバックエンドで大きな作業が必要です。また、私たちは独自のDevSecOpsに関するドキュメントと手順を追加してさらにコンテキスト化を行いました。これは、エンジニアリングとDevSecOpsに関して私たちが明確な見解を持っているため、非常に重要だったのです。もう1つの重要な目標は、これらの多様なチャネルを1つの場所、シングルペインオブグラスに集約することでした。Robinが言及したように、re:PostはAmazon Bedrock経由で質問に回答し、必要に応じてサポートへのエスカレーションも処理できます。このアプローチは、私たちのChatbotを他と一線を画すものにしています。
皆さんの銀行やグループでも様々なChatbotにアクセスできると思いますが、これは一般的な情報ではなく、AWS Cloudに特化したものです。エージェントとのやり取りは一般的なChatbotとは意図的に異なっており、これは設計上の意図であり、私たちが目指すところでもあります。
最後に、そして重要なことですが、私たちは多様なコミュニティメンバーを集め、彼らにホームを提供し、コミュニティに貢献し続けながら、プラットフォームも提供したいと考えていました。私の世界や私たちのグループには、素晴らしいアイデアを持つ優秀なエンジニアが大勢います。しかし、ConfluenceやSharePoint、その他のプラットフォームにおいて、その情報を保存して簡単に再利用できる中心的な場所がありませんでした。
私たちのアプリケーションの目標は非常に重要です。なぜなら、測定可能な成果を求めているからです。測定できる1つの指標は、数多く存在する社内サポートチケットです。AWSとCBAのナレッジベースを統合し、過去のサポート問題を参照・再現できるようにすることで、私のチームへのサポートチケットを約30%削減することを目指しています。測定は難しいものの、同様に重要なのは、AWSや私のチームへの各サポートチケットが摩擦ポイントを表しているということです。つまり、開発者が必要な情報にアクセスできない期間があるということです。毎日数千人の開発者が私たちのプラットフォームで重要な作業を行っている中で、これらの時間のブロックは無駄を表しており、それこそが私たちが本当に解決しようとしている問題なのです。
以前のジャーニーの1つを見てみましょう。 クラウド経験を持つ数千人のエンジニアがいて、彼らは以前の組織で「はい、4時間でアカウントを取得できました - 完璧なSLAですが、インターネットエグレスが必要です」と考えていたかもしれません。以前の職場では、単にInternet Gateway（IGW）を実装すればよかったことを覚えています。そこで、インターネットエグレスを検索します。 別の検索エンジンを試し、AWSのホワイトペーパーを読んで、実装方法が分かったと考えます。 しかし当然、管理体制が整った金融機関では、エグレスを自由に許可するルールやサービスを単純に追加することはできないため、失敗してしまいます。
その後、お客様はAWSのサポートラインに電話をかけます。重要度の低いサポートチケットなので、当然ながら待機時間が発生します。そしてAWSのサポートエンジニアから、AWSには問題がなく、Service Control Policy（SCP）のブロックか何か別の要因で問題が起きているため、社内のクラウドチームに相談するように告げられます。 そこで社内のサポートチケットを起票することになります。 サービスレベル目標に従って、私のチームの誰かがレビューして回答するまでには通常待ち時間があります。回答の内容は「もちろんインターネットエグレスを簡単に取得することはできません。適切なセットアップのためのPull Requestを提出する方法はこのドキュメントリンクを参照してください」というものです。 これらの時間を全て合計すると、かなりの時間になることがあります。週末を挟むと、数日以上かかる可能性もあります。
最初の段階で適切なコンテキストに基づく回答が得られないことが、この状況を引き起こしています。 AWSのドキュメントや公開されているre:Postでインターネットエグレスを検索すると、有効な回答は得られますが、Control Planeの設定がある組織（おそらく皆様の組織の多くも該当すると思います）では、必ずしも有効な回答とは限りません。では、私たちが考える理想的な流れについて説明しましょう。
同じエンジニアが、別の世界ではインターネットエグレスを必要としています。re:Post、シングルペインオブグラス。 AWS re:Post PrivateはAmazon Bedrockエンジンを使用するCBAのエンジニアであることを理解し、AWSから提供されているスキーマを使って情報を取得し、ターゲットを絞り、コンテキスト化してre:Postに送ります。CBA re:Post Privateは、最初からCBAのコンテキストに沿った回答を提供し、成功を収めています。このようにコンテキストに基づいた情報があることで、数日の労力だけでなく、フラストレーションのポイントも削減できます。エンジニアにとって、何かができるとわかっているのに障害があるという状況ほど嫌なものはありません。そのため、異なるアプローチが必要になります。それを妨げているのは、適切なコンテキストがないことだけなのです。
例を挙げましょう。私たちのre:Post Privateでのインターネットエグレスは、自動化されたアプローチと、最初から必要な設定を提供します。re:Post PrivateとCBAの世界について、もう一つ強調したい点はコミュニティの重要性です。私は技術コミュニティが大好きです。彼らは同じナードで、テクノロジーに情熱を持ち、お客様に対して情熱的で、適切な情報を適切なタイミングで得ることの重要性を理解しています。re:Postで私たちが目指していることの一つは、ポイントや認知度だけでなく、様々なチャネルを削減し、彼ら自身のプラットフォームを提供することで、彼らに報いることです。
これにより、彼らとは異なる方法で、より生産的な方法でエンゲージメントを図り、彼ら自身がより多くのコンテンツを発信することを期待しています。また、re:Post Privateでは、先ほどの発表でご覧いただいたように、institutional、banking、equities、retailなどの社内グループやコミュニティを作ることができます。これがTribal Knowledgeと結びつく点は、私たちはまだTribeの概念を維持できるということです。なぜなら、結局のところ人々はTribeという概念を好むからです。ただし、そのTribe内に蓄積される情報は、CBAとTribe両方にとってコンテキスト的であっても、実際には他の全ての人々によって活用されます。これが、ここでのコラボレーションの基本だと考えています。
re:Post Privateの実装と成果
もう1つの側面として、CBAコミュニティから枝分かれして、RomanがAWSコミュニティに直接アクセスできると話していたように、re:Post Privateで非常に複雑な質問をして答えが見つからない場合、そのシングルペインのインターフェースを通じてAWSコミュニティを活用できます。これは私たちにとって非常に強力で素晴らしい機能です。なぜなら、サポートチケットを登録するために別のUIに移動する必要がなくなるからです。 エンタープライズでre:Post Privateについて検討する際、AWSチームと協力することには大きな価値があると考えています。サポートチームはこの導入の計画を支援し、お客様独自のカスタマージャーニーの検討をサポートしてくれます。これは非常に重要なポイントです。なぜなら、どのようなカスタマージャーニーに対応できるか、そしてそれらをどのように変革したいかを理解することで、re:Post Privateの見方が形作られるからです。
カスタマーコミュニティをどのように計画するかという点も重要です。また、デザイン要素についてAWSチームと協力することも非常に重要になります。さらに、どの情報を取り込むかを設計する必要があります。個人的な経験から、re:Post Privateにどの情報を入れるべきか判断するのは難しかったと感じています。私たちの目標は、ほとんどのケースで真に文脈に即した正確な情報を持つことでしたが、他の多くの組織と同様に、古いデータが至る所に散在していました。そのため、私たちのデザインアプローチは慎重に選別され、実際には「少なければ少ないほど良い」という方針を取りました。そして実装アプローチに関しては、AWS Technical Account Managerチームやプロダクトチームからの支援は素晴らしいものでした。皆さんも同様のサポートを受けられると思います。
彼らの実装支援により、バックエンドのエンジンのチューニング、スキーマのチューニング、情報を転送するためのバケットのセットアップなども非常にスムーズに行えました。最後に最適化についてですが、これは決して設定して忘れるようなプロダクトではありません。しかし、他のAIモデルと比べて、エンジンの継続的な最適化を容易にする優れた機能がいくつかあります。主に、re:Post Privateのインターフェースにある投票の上下ボタンは、正しい回答に対してエンジンをチューニングする非常に巧妙な方法です。
エンゲージしたコミュニティがそれらの回答と相互作用を持ち、製品を継続的にチューニングする必要がありますが、同時に新しいデータを取り込み続けることも重要です。これは非常に重要な部分であり、プロダクトチームやサポートチームと協力することが成功の鍵となります。では、成果と私たちが実現したことについて話しましょう。私たちにとって、re:Post Privateはすぐに使える状態で提供されます。 エンジニアは全員、AWSアカウントを取得するか、AWSアカウントへのアクセス権を得た時点で、自動的にre:Post Privateにオンボーディングされます。これは私のチームだけでなく、CBAでパブリッククラウドを利用・接触する全てのエンジニアに当てはまります。
さらに、現時点ではアクセス権を持っていないものの、今後必要となる多くのエンジニアもいます。また、もはや実務から離れているエンジニアリングリーダーたちも、この情報へのアクセスを必要としています。そのため、アカウントアクセスが付与された際の自動オンボーディングプロセスに加えて、非ユーザー向けの二次的な自動オンボーディングプロセスも用意しています。また、スキーマのエクスポート、スキーマのダウンロード、その他の情報のエクスポート、エンジンのチューニングを組み合わせることで、CBAデータとAWSデータの統合も実現しました。
現在、このシステムは順調に稼働しており、AIと技術コミュニティの連携も実現できています。これは単なるAIによる応答ではなく、知性とスマートさの融合だと私は考えています。また、複数の横断的なコミュニティを設立し、多くのメンバーが貢献してくれています。同じ質問への重複した回答を減らすという生産性の向上も実現できました。そして、ここに来る直前にSydneyでローンチパーティーを開催し、MelbourneとIndiaからも参加して、re:Postをコミュニティに向けて正式にローンチしました。今後数ヶ月で、確実に30%のチケット削減を達成できると期待しています。
これを参考に、皆さんも独自の技術コミュニティを構築し、AIの機能を活用して、質問への対応や情報へのアクセス、適切なタイミングでの正確な回答を効率化し、エンジニアや開発者のフラストレーションを軽減し、チームの開発速度を向上させていただければと思います。ここでアクションアイテムをご紹介します。まず、re:Post Privateの利用をご希望の方は、こちらのバーコードをご利用ください。これでウェブサイトにアクセスできます。無料プランでは、無制限のユーザーに対して無制限のアクセスを提供しています。独自の技術コミュニティを立ち上げたい方は、セッション後に私たちに質問するか、Expoブースで専門家に相談してください。このセッションが皆様にとって有意義なものとなり、独自のコミュニティ構築と開発速度の向上にインスピレーションを与えられたことを願っています。セッションの評価をアンケートでお願いいたします。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion