re:Invent 2024: FINRAにおけるGenerative AI運用化の道のり
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - The journey and challenges of operationalizing generative AI at FINRA (WPS320)
この動画では、米国の投資家保護を担うFINRAにおけるGenerative AIの導入事例が紹介されています。600ペタバイト以上のデータを保有するFINRAが、Amazon BedrockとAmazon Q Developerを活用してAIを導入するまでの道のりと、その成果について詳しく解説されています。特に、Developer Assistantの導入により、コード品質が30%向上し、コード変換作業が40%削減されるなど、具体的な成果が示されています。また、Prompt engineeringの重要性や、セキュリティ、ガバナンス、法的フレームワークの確立など、大規模組織でGenerative AIを運用化する際の実践的な知見が共有されています。段階的な展開アプローチや、トレーニングプログラムの実施など、組織全体への展開に向けた具体的な取り組みも紹介されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
FINRAのGenerative AIジャーニー：背景と目的
はい、皆様ようこそ。音声は聞こえていますでしょうか？まだヘッドフォンを着けていない方は着けていただき、別のチャンネルを聞いている方はオレンジのチャンネルに切り替えてください。準備ができた方は親指を立てて教えてください。素晴らしい。本日は、朝早くからKeynoteに参加していただき、ありがとうございます。心より感謝申し上げます。
私はLeah Crawfordと申します。AWSのPrincipal Customer Solutions Managerを務めています。Customer Solutions Managerの役割をご存じない方のために説明させていただきますと、CSMはクラウドソリューションの提供と実装において、お客様をサポートする役割を担っています。この3年間、私はFINRAのクラウド改革をサポートする機会に恵まれました。本日は、FINRAで最も経験豊富なクラウドエグゼクティブの方々にご登壇いただいています。Kym WeilandさんはFINRAのSenior Vice President of Enterprise Operationsです。FINRAで20年以上の経験を持ち、クラウドジャーニーの最前線で活躍されてきました。クラウドの運用モデルを確立し、クラウドのベストプラクティスを開拓し、さらに重要なことに、成熟したクラウドカスタマーのためにAWSに対して継続的な改善と簡素化を促してこられました。
次に、同じく素晴らしいクラウドパイオニアであるDaniel Kooさんをご紹介します。DanielさんはFINRAのVice President of Enterprise Productivity Engineeringとして、Generative AIを活用した技術組織の改革を推進されています。FINRAのクラウドジャーニーとGenerative AIの取り組みにおいて中心的な役割を果たし、DevOpsプラットフォームを確立し、Generative AIを活用した開発手法の革新を実現されてきました。DanielさんとKymさんに、本日のご登壇に対して盛大な拍手をお願いします。
本日のセッションでは、FINRAのGenerative AIジャーニーについての素晴らしいストーリーをお届けします。どのようなクラウドジャーニーでも、技術的な部分は避けて通れません。しかし、私が最も期待しているのは、技術以外の重要な部分、つまり破壊的技術を成功させるために不可欠な人材、プロセス、組織変革に関するベストプラクティスについてです。 念のため申し上げますと、今週のre:inventには、Generative AIソリューションの開発と設定をハンズオンで学べるセッションが多数用意されています。しかし、それは本日のセッションの焦点ではありません。本日は、米国の投資家を保護するという重要な使命を持つ大規模な規制対象企業において、Generative AIソリューションをどのように運用化したかに焦点を当てます。
それでは、本日のアジェンダに入りましょう。まずKymさんが登壇し、FINRAについての説明と、クラウドジャーニーの背景についてお話しします。その後、Generative AIに対するFINRAのビジョン、成功に向けて設定した原則、そして開始時に直面した課題についてお話しします。さらに、既に本番環境にリリースされた最初のパイロットプロジェクトについても詳しくご紹介します。その後、Danielさんが登壇し、Amazon Qを使用したFINRAのDeveloper Assistantの構築と開発について、すべての経験を共有します。最後に、Kymさんが再び登壇し、FINRAのGenerative AIの今後の展望についてお話しします。
Generative AI導入の課題とFINRAの取り組み
まず始める前に、Generative AIについて皆さんと認識を合わせておきたいと思います。これは300レベルのセッションですので、Generative AIの基礎については触れません。ちょっとお聞きしたいのですが、手を挙げていただけますか？Generative AIの経験レベルが中級だと自己評価される方は何人いらっしゃいますか？何人かいらっしゃいますね。 繰り返しになりますが、これは300レベルのセッションですので基礎的な内容には触れませんが、今日のセッションで取り上げるサービスについては認識を合わせておきたいと思います。
AWSでは、お客様がGenerative AIソリューションを構築・展開できるよう、Generative AIスタックのすべてのレイヤーで革新を続けています。独自のFoundation Modelのカスタマイズ、トレーニング、開発、ホスティングをご希望のお客様向けには、最新のGPUやAmazonが独自に開発したAI専用チップのTrainiumとInferentiaを提供するインフラストラクチャレイヤーのソリューションをご用意しています。 次に、コンピューティングの管理に伴う差別化されていない作業を避けつつ、業界最新のFoundation Modelを活用したいというお客様向けには、Amazon Bedrockをご用意しています。Amazon Bedrockは、業界をリードするFoundation ModelへのAPIアクセスを提供し、Generative AIソリューションを簡単に構築できるネイティブ機能を備えています。最後に、開発者ではなくユーザーとして、Generative AIソリューションを開発するのではなく設定したいというお客様向けには、Amazon Qファミリーのサービスをご用意しています。実際には、ほとんどのお客様は特定のユースケースや要件に応じて、これらのサービスを組み合わせて使用することになります。実際、FINRAもGenerative AIスタックのすべてのレイヤーで実験を行っています。しかし、今日は特にAmazon BedrockとAmazon Q Developerに焦点を当てていきます。Amazon Bedrockは、FINRAがGenerative AIアプリケーションを構築・展開しやすくするネイティブ機能を提供しています。不適切な使用を禁止するGuardrailsや、RAGアーキテクチャーを容易にするデータソースへの安全な接続を提供するKnowledge Baseなどの機能により、迅速な展開が可能になりました。さらに、Amazon Q Developerは開発環境にシームレスに統合され、強化されたセキュリティ機能により、迅速なイノベーションを実現しました。しかし、この取り組みには課題もありました。これらのソリューションを企業全体に展開するには、強い信念と粘り強さ、そして適切な運用アプローチが必要です。
それでは、Kimをステージにお招きして、詳しくお話しいただきましょう。Kimさん、どうぞ。ありがとうございます、おはようございます。まず、FINRAについて少しご説明させていただきます。皆様の中には、FINRAという名前をあまりご存じない方もいらっしゃるかもしれません。 私たちはFinancial Industry Regulatory Authority（金融業界規制機構）です。これは何を意味するのでしょうか？私たちはSECと協力して、投資家保護と市場の健全性を確保し、米国の金融市場が公平で安全であることを保証しています。これを実現するために、データを使用した検知、罰金による規律付け、そして悪質な取引を抑止するためのルール作りを行っています。
データの観点からは、どのように業務を行っているのでしょうか？私たちはビッグデータ組織です。現在、ディスク上に600ペタバイト以上のデータを保有しています。実際、今月までにはエクサバイトを超えているでしょう。そして、このデータを様々な方法で活用しています。私たちは約10年前にクラウドへの移行を開始し、現在はクラウドファーストの組織となっています。つまり、このすべてのデータは現在、モデリング、分析、そしてその他のデータ組織がインサイトを得るために使用されています。しかし、どんな取り組みにも始まりがあります。私たちの場合は、Advanced Analyticsプログラムから始まりました。約3年前にこのプログラムを開始し、モデルガバナンスプログラムを確立し、現在では50以上のモデルが本番環境で稼働し、このデータを活用しています。
しかし、それは単なる道のりに過ぎず、AIによってこれらすべてが変わります。 FINRAのGenerative AIに対するビジョンは、このデータの取り扱い方を変革し、達成可能なことの可能性を広げることです。ここで「変革的」という言葉は非常に重要な意味を持ちます。タイプライターからコンピュータへの移行、VHSやBETA、CDなどの物理メディアから現在のストリーミングサービスへの移行のように、人々の作業方法が全面的に変わります。そして、組織内でその変化に対応するための文化や方法も変わっていきます。
この技術による変革を実現するために、私たちはいくつかの指針を設けています。最初は「変革的であること」です。先ほど申し上げたように、私たちは3年前にSDLCとモデルガバナンスから始めました。AIはモデル、つまりLarge Language Modelですが、これはSDLC 2.0ではありません。ガバナンスやLLM技術、AIへのアプローチは大きく異なります。リスクの軽減も重要です。これは技術的なリスクだけでなく、ビジネスリスク、そしてエンドユーザーが何を質問し、何を探せるのかを理解することに関するリスクです。私たちは倫理的な使用を確保したいと考えています。また、目的を持って構築することも重要です。これはどういう意味でしょうか？誰もがAIで何ができるかというアイデアを持っていますが、ビジネスユースケースに適した目的を持って実施し、本当に必要な成果を得られるようにする必要があります。最後に、複数のステークホルダーを含める必要があります。これは単なる技術的な変更ではなく、データからより良い洞察を得るための変革的な旅なのです。
FINRAのAI導入：パイロットプロジェクトFILLIPの展開
では、始めるにあたっての課題について話しましょう。 まず第一に、大きな関心の高まりがあります。ソーシャルメディアを見ても、スーパーマーケットを歩いても、AIの使用例を目にしない日はありません。すべてのビジネスユーザー、管理者、開発者が、これに触れてみたいと考えています。
しかし、リスクは従来とは異なります。これは単に誤った質問をするリスクだけではありません。ユーザーは、答えが返ってくる際のパラメータを理解していない可能性があります。LLMは数学が得意ではありません。人々は電卓に慣れていますが、これは異なる種類の回答を得ることになります。新しい法的リスクと技術的リスクも存在します。これは、モデルの倫理的使用、補償条項がどのように機能するか、そして従来の契約修正なしに頻繁に変更される方法について、法務チームとの協力が必要な重要な焦点領域となっています。法務組織にとって、これは前例のない新しい技術分野なのです。
私たちの高度な分析活動と同様に、Generative AI連合と呼ばれるものを作りました。ビジネス、法務部門、技術部門、その他の部門のリーダーシップを一堂に集めました。このAI連合を作ったのは、AI技術で達成しようとしていることの適切な優先順位付けを確実にするためです。優先順位付けのフレームワークを作る必要がありました。なぜなら、誰もがそれを使いたがり、素晴らしいアイデアを持っているからです。しかし、皆が快適に感じ、AIの価値と倫理的で安全な使用を実証できる場所から始める必要があります。変化は困難で、恐ろしいものです。明確な計画を持ってそれを乗り切る必要があるのです。
私たちはこの新しいテクノロジーを人々に紹介するためのあらゆる機会を活用しました。FINRAには「Create-a-thon」という素晴らしいイベントがあります。これは社内ハッカソンで、ビジネス部門と技術部門が集まって新しい革新的なテクノロジーを試し、ソリューションを提案することができます。このようなテクノロジー活用のゲーミフィケーションは、組織全体の理解を深めるのに非常に効果的でした。 私たちは自社の法務チームだけでなく、AWSの法務チームや他のサードパーティとも協力して、この領域をシンプルにすることに努めました。法務部門が懸念する主要なリスク領域を特定しました - これはサービスだけでなく、サードパーティ製品や使用するOSパッケージも含みます。誰もがAIを追加したがりますが、それを行う際に通知するかどうかは別として、そこにはリスクが伴います。
私たちはこれらのサービスの上に、いわば蛇口のような運用プロキシを構築し、何が、どのくらいの頻度で、誰によって使用されているかを管理し始めることができました。倫理的で適切な使用を確保するためのガードレールを実装しました。また、観測可能性を高め、組織内で測定したい価値と、その文脈について合意を形成する必要がありました。これは、私たちが必要としているものを確実に得られるようにし、適切なビジネス担当者を関与させ、この取り組みをどのように進めていくかについて適切な焦点を当てる上で重要でした。
トレーニングとスキルアップのプログラムが必要だということをすぐに学びました。技術部門だけでなくビジネス部門でも、最も重要なトレーニング項目はPrompt Engineeringでした。LLMに対するプロンプトの違いは、ユーザーの満足度や精度に影響を与えるだけでなく、コストにも直接影響を及ぼします。プロンプトはすなわちお金です。これはAI実装のROIが有益かどうかを決定づけます。新しいテクノロジーを顧客の前に出して使ってもらい、その後で高額な請求書が届いて「使用するには高すぎる」と言われるのは避けたいものです。Prompt Engineeringは、この journey全体を通じて成功と測定可能性を確保する上で極めて重要な要素となっています。
モデルガバナンスのプロセスとツールを見直す必要がありました。これは単なるSDLC 2.0ではありません - もはやモデル、トレーニング、推論の管理だけではないのです。どのサードパーティのモデルやサービスを使用してもらいたいかなど、ユースケースを管理する必要があります。それらのユースケースで使用してもらいたいベースラインモデルに違いはありますか？目的適合性の分析は異なる必要がありますが、誰もが持ち込む数多くのユースケースに対して、スケーラブルかつ迅速である必要があります。
私たちは出発点として、FILLIP（FINRA's Large Language Interactive Portal）を導入しました。これは Amazon Bedrock をベースにした私たちの最初のパイロットチャットボットです。その上に追加のコントロールとプロキシを実装し、ビジネスユーザーに対してトレーニングと理解すべきリスクの確認とともにロールアウトを開始しました。このテクノロジーがどれほど変革的になり得るかを体験してもらいたかったのです。次に、Amazon Q をベースにした FINRA's Developer Assistant をロールアウトしました。これについての詳細は、Danielをステージにお招きしてお話ししたいと思います。
Amazon Q Developerの導入：戦略と評価プロセス
Kim、FINRAのAIの取り組みについてご説明いただき、また、Leah、素晴らしい紹介をありがとうございます。 本日は、FINRAでのDeveloper Assistantの導入についてお話しできることを大変嬉しく思います。このサービスの導入を検討されている方々にとって、私たちの経験から得られた教訓や導入までの道のりについてお話しすることは、きっと有益な情報になるはずです。
このサービスを導入する際、すべてのエンジニアに対して即座に展開するという方法もありましたが、私たちはそうしませんでした。適切な戦略と計画を立て、段階的なアプローチで展開することを重視したのです。まず最初に、3つの大きな目標を設定しました。1つ目は、プライバシーの懸念、データの問題、セキュリティ要件などのリスクを最小限に抑えながら、Large Language Modelsをソフトウェア開発ライフサイクルにどのように統合できるかを検討することでした。2つ目は、大きな需要に対して限られたキャパシティという私たちの一般的なソフトウェア開発の課題を、このツールで解決できるかどうかを判断することでした。エンジニアの生産性と効率性を向上させることができるのでしょうか？3つ目は、継続的な改善とイノベーションの文化を育むことができるかどうかを確認することでした。エンジニアにとって負担になるのではなく、より生産的になり、学び続けることができるようにしたいと考えました。
これら3つの目標を念頭に置いて、私たちは取り組みを開始しました。 FINRAでは、新しいテクノロジーやコンセプトを評価し、より良い規制システムの構築に役立つかどうかを判断するためのR&Dプログラムを実施しており、その一環として5ヶ月間のResearch and Development活動を行いました。コード支援は、私たちが評価したいと考えていた新興テクノロジーとコンセプトの1つでした。
最初に行ったのは業界調査でした。業界がGenerative AI、LLMs、コード支援機能をどのように活用しているのか、そしてそれがFINRAにとって何を意味するのかを理解したいと考えました。ソフトウェア開発ライフサイクル内の多くの異なるユースケースを検討し、業界調査の中で17の異なるツールを評価しました。包括的な評価フレームワークを確立し、これについては後ほど詳しくご説明します。
FINRAにとって重要な3つのユースケースを定義し、 これらのユースケースに最適なツールを特定するための実験を行いました。これらの実験に基づいて、5つのツールを選定し、 確立した評価フレームワークを使用して本格的なハンズオン評価を実施しました。最終的に、それらのツールのうち3つについて推奨することができ、 Amazon Q Developerが私たちの最優先の選択となりました。
先ほど申し上げたように、私たちはトップクラスのツールやサービスを評価するための評価フレームワークを確立しました。大きく分けて6つのカテゴリーがあります。サービスの機能性については、コード生成とコード説明の観点から検証しました。また、IDEとの互換性やプログラミング言語のサポートなど、サポート技術についても検討しました。3つ目は、セキュリティとコンプライアンスでした。プライバシー、データ、セキュリティ要件を考慮しながら、開発ライフサイクルへの統合が重要だったからです。例えば、このサービスを使用する際にFINRAのデータが共有されないようにする必要がありました。
Enterprise統合も重要な要素でした。というのも、このソリューションは私たちのエコシステム内で機能し、認証、認可、ログモニタリングに必要なすべての統合を備えている必要があったからです。品質は恐らく最も重要な要素でした - ソフトウェア開発中にどのようなパフォーマンスを発揮するかを評価したかったのです。最後に、この機能を維持するための総合的な労力とコストを含むメンテナンスについても考慮しました。
Amazon Qが私たちの最優先の選択となり、その理由を説明したいと思います。ソフトウェア開発ライフサイクルの異なるフェーズを見ると、計画フェーズ、作成フェーズ、テストフェーズ、運用の側面、そしてメンテナンスとモダナイゼーションがあります。このソフトウェア開発ライフサイクルに関わるエンジニア、DevOpsエンジニア、アーキテクトなど、さまざまなペルソナを考慮しました。私たちは作成、テスト、モダナイゼーションという3つの重要な領域に焦点を当てることにしました。これらの側面を評価する際には、FINRAで現在使用しているすべてのプログラミング言語と、評価したいと考えていた一般的な言語を検討しました。
ここで強調しておきたいのは、これらのさまざまなユースケースを見たとき、Amazon Q Developerは生産性向上のためのアシスタントツールだということです。開発者に取って代わるものではありません。すべてが私たちの望む通りに機能しているかを確認するために、人間による確認は依然として必要です。
では、なぜ他のツールと比べてAmazon Qを選んだのでしょうか？機能性、コード品質、セキュリティ、データ要件のすべてを満たし、私たちが持っていたこれらのさまざまな要件全体にわたって非常に良いパフォーマンスを示したからです。機能性の観点から見ると、Amazon Qは複数のモダリティをサポートし、ユーザーがサービスを利用できる複数のインターフェースを持っています。これは私たちのエンジニアにとって非常に有益でした。なぜなら、チャット、インライン、エージェントなど、異なるユースケースに応じてこれらの異なるモダリティを使用していることが分かったからです。
Amazon Q Developerパイロットの実施と成果
次に、Amazon Qは私たちの主要なユースケースの多くをサポートしていました。アプリケーションコードの生成、コードの説明、テストケースの生成、そしてセキュリティスキャンのオンデマンド実行など、いくつかの例を挙げたいと思います。これらの主要なユースケースに対して、非常に優れたパフォーマンスを発揮しました。次の重要なユースケースはコード変換でした。アップグレードの実行が重要でした。なぜなら、Amazon Qがそのサイクルタイムをどれだけ短縮できるか確認したかったからです。そして、JavaバージョンやSpring Bootバージョンのアップグレードを行った際、非常に良い結果を示しました。繰り返しになりますが、セキュリティとコンプライアンスの要件を満たしていました。
Amazon QはFINRAのコードやPIIデータを一切保存せず、FINRAのデータをモデルトレーニングに使用することもありません。これは絶対に重要な要件で、Amazon Qはこれらの要件を満たすことができました。Amazon QはAWSのサービスとインターフェースについてトレーニングされており、FINRAのシステムの大部分がAWS上で稼働しているため、質問やプロンプトを入力する際、多くの質問がAWSサービスに関連していました。そのため、設計やコーディングに関して素晴らしい推奨事項を提供してくれました。
これらの要件を満たしていたとはいえ、すべてのエンジニアに対してこれを有効にできたわけではありません。私たちが決めたのは、パイロットプログラムを実施することでした。日々の業務にどのような影響があるかを確認するため、2ヶ月間のパイロットを実施しました。企業全体から14の異なるチーム、合計60名のエンジニアを選出しました。管理された開発環境内で9週間にわたってこれを実施しました。このパイロットでは、コード変換、テストコード生成、プロジェクトオンボーディング、そしてコードドキュメンテーションという4つのユースケースを選びました。各チームは自分たちに最も関連のあるユースケースを選択し、2ヶ月間パイロットを実施しました。
これはTech Talkですので、アーキテクチャ図は欠かせません。これから説明するアーキテクチャ図をご覧ください。Amazon Qがどのように動作するのか、その仕組みについて少し説明したいと思います。左上から、ユーザー、開発者、アーキテクトなどがいます。彼らはIDEでAmazon Qを使用します。これは非常に重要です。なぜなら、エンジニアが最も時間を費やす場所であるIDEでサービスを利用できるようにしたかったからです。FINRAで主に使用している2つのIDE、IntelliJとVisual Studioを選択しました。右上を見ていただくと、最初に行われるのは認証です。このサービスはすべてのエンジニアに対して有効になっているわけではありません。認証プロセスを経て、承認された場合にのみサービスを利用できます。IDE内のAmazon Qプラグインを使用して、バックグラウンドで様々なモダリティを通じてAmazon Qサービスと直接やり取りします。チャットモダリティやインラインチャットについて言及しましたが、Claudia 3.5モデルを使用して素晴らしいパフォーマンスを発揮しました。ぜひ試してみる価値があります。異なるモダリティがバックグラウンドでAmazon Qサービスとやり取りします。
Amazon QはバックグラウンドでAmazon Bedrockを使用し、そこにある様々なモデルを活用します。右下を見ていただくと、Amazon Qはカスタマイズ機能をサポートしていることがわかります。私たちの環境内にある独自のコードベースを取得するためにRAGを使用し、さらに良い推奨事項を提供します。これは現在パイロット中の機能で、来年初めにリリースする予定です。左下には、統合できた様々なセキュリティコントロールが示されています。認証、ログモニタリング、暗号化、データ共有のオプトアウトなど、これらすべてのセキュリティコントロールをこのプロセスに統合することができました。
パイロットに話を戻しましょう。パイロットの成功をどのように測定したのでしょうか？私たちは、インパクト、利用状況、そして感想という3つの異なるカテゴリーに着目しました。インパクトの観点では、パイロットを開始する際に、各チームに独自の成功指標を定義してもらいました。チームごとに異なる指標が設定され、あるチームはテストコードカバレッジの向上を目標とし、別のチームはデリバリーに関する開発速度の改善を検証しようとしました。利用状況の観点では、センターからサービスのアクティブな利用状況、受け入れ率、承認されたコードブロックの数などの指標を収集しました。パイロットの進行に伴う傾向を、センターで監視していました。そして最後の、非常に重要な要素が、開発者からの感想でした。サービスから良い価値を得られることも大切ですが、開発者が良い体験をし、サービスの使用に満足していること、そして実際に生産性が向上しているかを理解することも重要でした。
どのパイロットでも順調に進むことを期待しますが、いくつかの課題に直面しました。これらが私たちが遭遇した主な課題です。Kimが指摘したように、パイロットユーザーへの展開において、Prompt engineeringが最も顕著な課題でした。一部のユーザーがPrompt engineeringに不慣れで、質問をして回答を得た後、同じ質問をすると異なる回答が返ってくることに戸惑いを感じていることがわかりました。最適なプロンプトの作り方について混乱がありました。そこで、AWSと協力してトレーニングワークショップを企画し、すべてのパイロット参加者に実施しました。また、主要なユースケースに対する参考例を含むプロンプトカタログの構築を開始し、これが参加者の習熟度向上に大きく貢献しました。
同様に、ベストプラクティスの不足も課題でした。これは比較的新しい技術であり、私たちもベストプラクティスを模索している段階でした。提供される様々な機能やモダリティに対して、異なるユースケースにどのようにアプローチするのがベストなのかを見極めたいと考えていました。そこで再びAWSと協力して別のワークショップを開催し、エンジニアのトレーニングのためのベストプラクティスを確立し、参考例を含むユーザーガイドやドキュメントの作成を開始しました。最後の課題はセキュリティ監視に関するものでした。セキュリティ要件は絶対に重要で、進めるために必要だった要素の1つが、プロンプトとガードレールログを監視する能力でした。この点でもAWSと協力し、すべてのログを専用のS3 bucketにエクスポートして継続的に監視できる機能を実現することができました。
パイロットの結果を見ると、あらゆる面で改善が見られました。開発者の生産性と創造性が向上し、それによってチーム全体がより良いソフトウェアを構築し、品質を向上させ、テクニカルデットを削減することができました。チームの改善に伴い、組織全体がよりイノベーティブで俊敏になっていく様子も確認できました。
そして、これらの結果を踏まえて、 本番環境への展開を推奨することができました。 昨日のKeynoteでも言及されましたが、このサービスを通じて大きなインパクトが得られました。コード品質とコードの整合性において30%の向上が見られ、コード変換作業が40%削減され、コードの説明などによってチームの習熟度が向上したことで認知的負荷が20%削減されるなど、素晴らしい数字が得られました。
ユーザーの視点から見ると、業界標準の推奨事項の受け入れ率は30%程度なのですが、私たちはChatモダリティを活用することで、推奨事項全体で70%、インラインコードについては30%近い受け入れ率を達成できることがわかりました。Amazon Qが推奨した4,500以上のコードブロックが受け入れられました。パイロット期間を通じて、継続的にアクティブユーザーがいました。ご覧のように、わずか2ヶ月の間にこれだけ多くのJavaアップグレードを実施することができました。
パイロットに参加したエンジニアを対象に調査を行ったところ、すべてのチームがAmazon Qを推奨していました。80%以上のエンジニアが、作業に集中できフローに入りやすくなったと回答し、タスク完了までの生産性が15%以上向上したと報告しています。さらに興味深い数字として、50%以上のエンジニアが、仕事の進め方が大きく変わった（もちろんポジティブな方向に）と答えています。
本番環境への展開と今後の展望
R&Dとパイロットが成功を収めた後、私たちは本番環境への展開準備が整いましたが、段階的に進めることにしました。FINRAでは反復的なアプローチでこれらの機能を展開していく傾向があることがお分かりいただけると思います。展開を2つのフェーズに分けることにしました。第1フェーズではエンジニアの15%に対して機能を有効化し、第2フェーズは来年初めに組織全体への展開を予定しています。
このような段階的アプローチを取る理由は、成功に向けて多くの基盤作りが必要だからです。本番環境での利用に向けた適切なアーキテクチャの構築、ユーザーアクセス制御、適切なメトリクスの収集とモニタリング、そして先ほど説明したプロンプトとガードレールのロギングなど、企業全体に展開する前にこれらすべてを整備する必要があります。
前提条件として、Gen AIの利用規約を作成し、サービスを有効化する前にすべての開発者にこれを確認してもらいました。フェーズ1に参加するエンジニアは全員、ワークショップとトレーニングを受講する必要があります。パイロットから学んだように、サービスを利用する新しいエンジニアが増え、Promptエンジニアリングも初めての人が多いため、適切なワークショップとトレーニングを実施することが重要だと考えています。
私たちは、エンジニア向けの充実したドキュメントとガイドラインを用意することも確実に行いました。これには、始め方、オンボーディングの方法、さまざまなベストプラクティス、そしてエンジニアが利用できるプロンプトカタログなどが含まれています。また、エンジニア同士が集まってヒントやコツ、成功事例について話し合える実践コミュニティも確立しました。これはサービスの展開において重要な取り組みの一つでした。そして最後に、AWSが新機能をリリースする際には、それをエンジニアが安全に利用できるよう、密接に連携して取り組んでいます。
ここで、Phase 1での進捗についてお話ししたいと思います。先ほど申し上げたように、Phase 1では技術組織の15%をオンボーディングし、右側にあるように4日間のオンボーディングワークショップを開催しました。また、Phase 1を通じて、週次のオフィスアワーと月次のナレッジシェアリングセッションを実施しました。
私たちは、コードの品質と整合性の継続的な向上を実感しています。コード変換における開発チームの認知負荷も軽減されています。ユーザーの観点からは、チャットコードの受け入れ率が50%、インラインコードの受け入れ率が80%という素晴らしい数字を達成し、12,000のコードブロックが承認されました。ソフトウェア開発で使用している10種類の言語全体で、サービスの活発な利用が継続しています。開発者の生産性が向上し、チームのパフォーマンスが改善され、ソフトウェア全体の品質が向上し、組織全体がイノベーションを推進し、アジリティを向上させています。
Phase 2で私たちの開発コミュニティにもたらされる可能性に、大変期待を寄せています。ここで、FINRAの今後についてお話しするため、Kymにバトンタッチしたいと思います。 Danielが言及したように、これらのパイロットと本番展開には多くのメトリクスが組み込まれています。その理由は、展開方法を効率化し、導入のスピードを上げ、これらのテクノロジーの利用をより広範に広げたいからです。次のステップとして、これらの可観測性メトリクスを分析し、そこにもAIを活用する予定です。何が機能し、何が機能していないのかを理解し、その採用において非常にアジャイルである必要があります。
必要なガードレールを検討し、異なるユースケースに応じてガードレールを階層化する方法を見出していきます。企業全体のガードレールと、特定のユースケースに対する個別利用のガードレールが必要になるかもしれません。ガードレールが適切に作動している場合とその理由（教育の問題なのか、誤解があるのか）、また本来作動すべきでない場合に作動している場合（ガードレールの形成が不適切なのか、AIの計装やモデルの使用方法を見直す必要があるのか）を把握し、監視する必要があります。最後に、私たちは今後の発展を期待しています。現在のAIの実用的な活用の多くは、生産性を支援する補助的なものです。私たちは、AIによるエージェント技術を活用し、より良い意思決定を支援するだけでなく、ビジネスレベルでのプロセス完了をより迅速に実現できるレベルまで到達したいと考えています。
それでは、ありがとうございました。このセッションを締めくくるためにLeahにバトンをお返ししたいと思います。素晴らしいセッションでした。私の視点から、いくつかの重要なポイントをまとめさせていただきます。Generative AIの運用化に関しては、迅速な行動を可能にするフレームワークを確立することが重要です。Generative AIの運用、ガバナンス、セキュリティ、法的フレームワークの設定は少し気が重くなるかもしれませんが、安全に実験できる環境を作り、すぐに実践的な経験を積むことが大切です。なぜなら、学習曲線は確実に存在し、成功に必要な人材、プロセス、組織の変更に投資する必要があるからです。
次に、より迅速に進めるためにAmazonのネイティブ機能を活用することです。FINRAがAmazon BedrockやAmazon Qで実践していたように、ネイティブのセキュリティ機能や開発環境との統合により、より迅速な展開が可能になり、セキュリティ運用とガバナンスチームの承認も得やすくなります。
最後に、AWSとパートナーシップを組むことです - 私たちはお客様の成功をサポートさせていただきます。ワークショップやトレーニングを実施することで、ユーザーコミュニティを迅速に巻き込むことができます。以上です。アプリ内のアンケートにぜひご回答ください。大変ありがたく存じます。残り15分ほどありますが、このセッションはサイレントセッションですので、私たちは横に控えさせていただきます。ご質問がございましたら、お気軽に静かに近づいてお声がけください。重ねてお礼申し上げます。素晴らしいre:Inventをお過ごしください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion