re:Invent 2024: bpx energyのAWSへの完全移行とGen AI活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - All-in on AWS: Transforming production operations with AWS (ENU307)
この動画では、bpx energyのAzureからAWSへの完全移行プロジェクトと、Gen AIの活用について解説しています。bpx energyのChief ArchitectのMike Broganが、18ヶ月に及ぶOneCloud移行プロジェクトの詳細を説明し、SAPやArcGISなど91のアプリケーションの移行、280テラバイトのファイル共有データの移行、約1,000のServerlessコンポーネントの移行について具体的に解説しています。また、AWS for Energy and Utilities Business GroupのMu Liが、Gen AIの活用について、年間2.6兆から4.4兆ドルの経済価値創出の可能性や、Amazon Bedrock、Amazon OpenSearch Service、Amazon Textractなどを活用したソリューションアーキテクチャを詳しく説明しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
セッション概要と参加者の背景
みなさん、こんにちは。本日のセッションへようこそ。みなさんとお会いできて大変嬉しく思います。始める前に、簡単に挙手をお願いしたいと思います。エネルギー業界で働いている方は何人いらっしゃいますか？はい、こちらのグループですね。マイグレーションを実施している方は？はい、こちらですね。そして今最も注目を集めているGen AIについて、Gen AIを試験的に使用したり、導入したりしている方は何人いらっしゃいますか？はい、素晴らしいですね。本日はこれらすべてについてお話しする予定ですので、まさに適切なセッションに来ていただいたと思います。
私はAWS for Energy and Utilities Business Groupに所属するSolutions ArchitectのSenior ManagerのMu Liと申します。本日は、bpx energyのChief ArchitectであるMichael Broganとご一緒させていただき、bpx energyがAWSへの完全移行を決断し、マルチクラウド環境をシンプル化し、SAPやArcGISのマイグレーションを含む取り組みについてお話しできることを大変嬉しく思います。 本日は充実したアジェンダをご用意しています。まず、マイグレーションとGen AIにおける機会と課題についてお話しし、その後Michaelが、実際のお客様事例として、AzureからAWSへのマイグレーションの道のりについてご説明します。その後、私からGen AIのビジョンとデータ戦略について説明し、Gen AIのソリューションアーキテクチャについて詳しく掘り下げていきます。このセッションは、ビジネス部門の方々も技術部門の方々も対象とした300レベルのセッションで、複数の実例とソリューションアーキテクチャをご紹介します。
クラウドマイグレーションの機会と課題
それでは、クラウドマイグレーションとモダナイゼーションにおけるビジネスチャンスと推進要因についてお話ししていきましょう。お客様がAWSへマイグレーションする理由は様々です。左下から時計回りに見ていきますと：データセンターの撤退と統合、グローバル展開、エネルギー業界では特に一般的なM&A（合併・買収）などがあります。お客様は俊敏性とスタッフの生産性を向上させ、顧客についての洞察をより迅速に得られるデータ駆動型組織への転換を目指しています。コスト削減に関しては、お客様はAWSでオンプレミスと比べて25～50%のコスト削減を実現しています。しかし、お客様はコスト削減以上のものを期待しています。セキュリティと運用の強靭性の向上、デジタルトランスフォーメーションと企業のモダナイゼーションの実現、そしてサステナビリティにおける責任ある企業市民としての役割を果たすことを望んでいます。最近の傾向として、お客様がこれらのコスト削減分をGen AIに再投資している例が見られます。
AWSは数千のお客様のマイグレーションをサポートしてきましたが、共通の課題がいくつか見られます。第一に、クラウドの運用とセキュリティです。クラウドの運用モデルを定義し、セキュアに実施する必要があります。第二に、プログラム管理と計画です。マイグレーションのために1年間ビジネスを停止するわけにはいきませんので、ビジネス目標を達成しながら依存関係を管理する必要があります。第三に、リソースの確保です。現在の技術状況とクラウドの両方を理解している人材が必要ですが、これは人材だけでなく、資金や時間のリソースも含みます。また、様々な技術的な障壁も存在します。私の好きな例えとして「問題は常にネットワークにある」というものがありますが、ネットワークチームの方々に公平を期すために言えば、バージョンの非互換性やシステム統合の問題、また市販のパッケージソフトウェアを使用している場合は、AWSへの移行やAmazon RDSをデータベースとして使用する際に、ベンダーにアプリケーションレベルのサポートを依頼する必要があるかもしれません。
マイグレーションとモダナイゼーションは一つの旅路であることを認識しましょう。私たちは数千のお客様がこの体系的なアプローチを取られるのを見てきました。 まず、評価（Assess）です。チーム、ステークホルダー、ビジネスの準備状況を評価し、変革のケースを作成します。 次に、始動（Mobilize）です。これは経験を通じて推進していく段階です。初期の成功事例を作り、勢いを生み出し、興奮を生み出し、さらに速く進められるように反復していきます。
このフェーズで行うことの1つに、Cloud Center of Excellenceの設立など、クラウドにおける運用モデルの構築があります。第3に、Landing Zoneの準備が整ったら、本格的な移行を加速させていきます。私たちが見てきた限り、ほとんどのお客様が、少なくとも何らかの形でモダナイゼーションを行う機会を活用しています。セキュリティの脆弱性やEnd-of-Service-Lifeの問題に悩まされたくない方はいませんよね。この段階では、皆さんもご存知のAWS Well-Architected Frameworkの全ての柱に関わる、パフォーマンス、コスト、運用の優位性について継続的な最適化を行っています。
私たちが協業している全てのお客様で、このような体系的なアプローチが見られます。ここで手を挙げていただきたいのですが、皆さんの過去の経験の中で、少なくとも大まかなレベルで、同様の機会や課題、あるいは似たようなアプローチを経験された方はいらっしゃいますか？ありがとうございます。本日は、bpx energyの実例という興味深いストーリーをご紹介させていただきます。bpxのチームが成し遂げてきたことを見守ってきた素晴らしい旅でした。そして、より詳しくお話しいただくために、bpxのMike Broganさんをご紹介させていただきます。
bpx energyのOneCloud移行プロジェクト：背景と実施内容
ありがとう、Lee。皆さん、こんにちは。Leeの紹介にもありましたように、私はbpx energyのChief ArchitectのMike Broganです。bpxには6年以上在籍しています。私たちのクラウドジャーニーは私が入社する前から始まっていましたが、私は面白い部分に関わることができました。本日お話しするのは、私たちのOneCloud移行プロジェクトについてです。なぜ実施したのか、どのように進めたのか、そこから得られた利点、そしてその過程で学んだことについてお話しします。皆さんにとって何か参考になることがあれば幸いです。また、プロジェクトチームのメンバーも会場にいますので、後ほど詳細な質問がありましたら、直接お話しいただくこともできます。
まず、bpx energyについて少しご紹介させていただきます。私たちはBPの米国陸上Oil & Gas部門です。2018年にBHPから資産を取得したことで、現在のポートフォリオは主にPermian、Eagle Ford、HaynesvilleのBasinに集中しています。この数年間で、それ以前に保有していた資産のほとんどを売却し、この資産群から最大の価値を引き出すことに注力してきました。なお、フォーカスというのは、このプレゼンテーションの共通テーマとなります。本社はDenverにありますが、資産のほとんどはTexasにあります。
私たちの旅は2017年に始まりました。多くの企業と同様に、SaaSベースのサービスやストレージ、VMなど、クラウドへの試験的な取り組みから始めました。また、その時期にAWSでIoTの実験も始めました。しかし、2019年に私たちのクラウドへの取り組みは本格化しました。先ほど申し上げたように、2018年にBHPから資産を取得し、2019年にその運用を開始しました。2019年春には、上流のSCADAシステムをAWSに移行し、2019年秋には、SAPインスタンスを別のクラウドに移行しました。これが私たちのデュアルクラウド戦略の始まりとなりました。
私たちがそうしたのは、主に厳格なセキュリティ分離と呼べるものを実現するためでした。制御系、つまりOT（運用技術）環境をAWSに、企業系、つまりIT（情報技術）環境を別のクラウドに配置しました。これは、パブリッククラウド上のSCADAを初めて目にするセキュリティ担当者たちの同意を得るために必要な措置でした。 その後2年間で、私たちは資産のクラウド移行を継続し、データの統合を進め、クラウド上の単一のData Lakeを目指して取り組みました。また、分析とMachine Learningにも深く取り組み始め、様々なソリューションを検討した結果、Amazon SageMakerを採用しました。これは実は、その後の展開に大きな影響を与えることになりました。なぜなら、これが私たちのAWSクラウドに配置した最初の企業系（IT）資産だったからです。2年前に当社のCTOであるJordy Harrellが私たちのクラウドジャーニーについて講演した際（先ほど触れるのを忘れていましたが）、企業環境で稼働していたのはSageMakerだけでした。そこで私たちは考えました。なぜ2つのクラウドを使う必要があるのだろうか？適切なセキュリティを確保できれば、単一のクラウド内でも分離は可能なはずだと。
また、2つのクラウドを運用することで余分な作業が多く発生することも分かっていました。そこで2023年、私たちは単一クラウドへの移行を決定し、OneCloudイニシアチブを開始しました。 これは18ヶ月に及ぶ取り組みでした。多くのプロジェクトがそうであるように、現在99%まで完了していることを嬉しく思います。最後の1マイルが常に最も長く感じられますね。まだ数個の移行が残っていますが、私たちは今や単一クラウドのメリットを実感できる段階に来ており、 AIや生成AIソリューションを活用する次のステップに進もうとしています。
では次は何か？誰もがAIの活用と言うでしょうが、私たちは2030年を見据えています。 これは企業目標として、そのメリットが本当に実感できる時期だと考えています。2030年までに生産量を2倍にする一方で、キャッシュコストと人員を増やさないことを目標としています。これはテクノロジーを活用しなければ達成できません。そして、それをクラウドで実現しているのです。
OneCloudに対する私たちのビジョン、つまり何を得ることを期待しているのか。誰もがここでコストを期待するでしょう。しかし、それは私たちの主目的ではありませんでした。 時間とともにコスト効率は向上すると予想していますが、私たちの分析では、それは間接的な削減効果になると示されています。実際、数字があまりにも良すぎて信じがたく、一時はプロジェクトを断念しかけたほどでした。しかし、私たちの本当の焦点はテクノロジーの観点からの簡素化です。これは、より大きな簡素化の取り組みの一部です。先ほど述べたように、私たちは単一のアップストリームSCADA、単一のTime Series Database、単一のData Lake、単一のSAPインスタンスを持っています。さらにサービスパートナーも合理化しました。
簡素化は私たちの活動の大きな部分を占めています。この簡素化により、2つの異なるやり方を維持する必要がなくなり、すべてに対して2つのスキルセットを持つ必要もなくなることで、効率化が図れると経営陣を説得できました。業務に集中できるよう、リソースを分散させすぎないようにすること。この簡素化と効率化により、ビジネスのためのイノベーションと価値提供のペースを加速できます。結局のところ、テクノロジー部門として、私たちはビジネスに価値を提供するために存在しているのです。
このようなプレゼンテーションでエグゼクティブサマリーのスライドを再利用しようとするとこうなってしまいます。まずはタイムラインの部分から始めましょう。 18ヶ月のプロジェクトだったと申し上げましたが、12ヶ月で完了できれば理想的でしたが、それは現実的ではないと分かっていました。少し遅れることを見込んで、当初は15ヶ月の計画を立てましたが、途中でいくつかの障害に遭遇し、結果的に18ヶ月かかりました。最初にSAPの移行から始めました。最も大規模で複雑なアプリケーションの一つであるSAPを最初に移行するなんて、少し無謀に聞こえるかもしれませんが、実際にそうしたのです。
SAPの移行と並行して、移行が必要な他のアプリケーション、サービス、データベースのアーキテクチャと設計に取り組みました。その後、それらのアプリケーションを複数のウェーブに分け、バッチで移行を進めていきました。どのようなアプリケーションを移行したのかというと、最終的に数えたところ少なくとも91のアプリケーションがありました。これらの数字は数え方によって毎回変わってしまうので、完全に信用できるわけではありませんが。91というと多くの方にとっては少ない数かもしれませんが、私たちにとってはこれは全体の3分の1に相当します。私たちは約300のアプリケーションを保有していますが、これは多くのアプリケーションがすでにSaaSとして運用されていて、移行の必要がなかったことを示しています。
280テラバイトのファイル共有データについて話すと、私が今年DenverからHoustonに引っ越した経験を思い出します。私にはストレージユニットがあり、中身は大体把握していましたが、引っ越しを早く済ませたかったので、今回の移行プロジェクトと同じように、すべての物を整理する時間を取らずにそのまま移動させました。結局、ストレージユニットの移動は外部業者に依頼することになりました。同様に、このプロジェクトでも、すべてのデータとアプリケーションを期限内に移行するために、サードパーティのソリューションを導入する必要がありました。
そして、このプロジェクトを本当に複雑にしたのは、他のクラウドに存在していた約1,000のServerlessコンポーネントをAWSに移行する必要があったことです。アーキテクチャ図を描いたり技術的な概念を考えたりする際に、あるクラウドのサービスは他のクラウドのサービスと同等だと考えがちですが、実際にはそうとは限りません。移行の過程で、かなりの現代化も行いました。その一部は単に最新の技術を使用することでしたが、
Infrastructure as Code、デプロイメントパイプライン、VMの代わりにコンテナを使用するなど、21世紀の技術水準に追いつくことも含まれていました。また、Non-prod、Pre-prod、Productionという3つの独立した環境を確保し、高可用性と災害復旧の構成を強化することで、デプロイメントの信頼性も向上させました。結果として、単なるアプリケーションではなく、より堅牢なプラットフォームを構築することができました。このプロジェクトが完了する頃には、2019年のBHP買収の際に学んだ教訓も活かし、各アプリケーションをアーキテクチャレビュー、クラウド変更管理委員会、セキュリティリスク評価のプロセスを通じて評価するという同じアプローチを踏襲しました。
OneCloud移行の具体的な取り組みと学んだ教訓
主要な移行アプリケーションの中で、まず最初に挙げられるのがSAPです。これを5ヶ月で完了しました。これは婉曲表現なのですが、「モメンタムを作るため」と言っています。「Burn the ships（船を焼く）」という言葉をご存知の方はいますか？実際に「Burn the Ships」という曲もあるんです。この考え方は、どこかに到達して船を焼いてしまえば、もう後戻りはできないというものです。私たちは、一度始めたら誰も引き返そうなどと考えないようにしたかったのです。そのため、最初にSAPを選びました。私たちにとってSAPは、基本的にはリフト＆シフトでした。
次にArcGISという、これも主要なアプリケーションです。これは以前のプラットフォームではパフォーマンスが出ず、スケーラビリティにも問題があり、頻繁に停止していました。そのため、このアプリケーションではインフラの大幅な再設計を行いました。そして、もう一つの主要なアプリケーションが、Well Connected Portalと呼ばれる、複数のアプリケーションを含む大規模なカスタム開発プラットフォームです。できれば移行ではなく廃止したかったのですが、廃止計画が間に合わなかったため、移行せざるを得ませんでした。幸運だったのは、これらのアプリケーションの大部分を開発した人物が、私たちの移行チームのクラウドアーキテクトの一人として参加していたことです。その方は今、この部屋の隅に座っています。
SAPに関して、これは恐らく皆さんが見た中で最もシンプルなSAPの図解でしょう。この図から多くの情報が得られるとは約束できません。これは非常に高レベルのネットワーク図に過ぎず、私たちのSAPプラットフォームが持つ100以上のインターフェースや統合については示していません。この図が強調しているのは、私たちが予想していなかった部分です。つまり、この取り組みを通じて、親会社であるBPとの統合方法を再設計し、基本的に同じ会社の一部というよりも外部パートナーとして扱うことにしたということです。
SAPの要請で、自社クラウドでの運用を続けるのではなく、SAPインスタンスをSaaSに移行することについても少し検討しました。現時点ではメリットが十分ではないと判断しましたが、数年後には彼らの提供するサービスが改善されているかもしれません。先ほど統合について触れましたが、社内外のシステムやBPとのファイル転送、APIなど、何百もの統合があります。SAPをご存知の方なら、私が何を言っているかお分かりでしょう。SAPを移行する際の複雑さは、まさにそこにありました。私たちが発見したのは、このような大規模なモノリシックアプリケーションの移行は、実は小規模なアプリケーションの移行よりもシンプルだったということです。
もう一つのリスク領域は、生産会計に関するものでした。私たちのSAPシステムにはCrawfordプラスパックなどのカスタマイズが施されていたため、これらがAWSに正常に移行され、継続して機能することを確認するために特別な注意を払う必要がありました。移行が非常にスムーズだったため、ビジネス部門からは「何も起こらなかった」と言われましたが、移行週末に待機していた100人のスタッフにとっては決して「何も起こらなかった」わけではありません。彼らの懸命な努力のおかげで、この移行の過程で1回のアップグレードも実施し、SAPの近代化も行うことができました。以前のクラウドで使用していたGlusterファイルシステムとVM基盤のNFSファイル共有から、Amazon EFSに移行しました。この移行の過程でAmazonやAWSに対して、EFSについて様々な意見を述べてきましたが、その中には必ずしも好意的でないものもありました。
その成果は結果が証明しています。昨年8月にこの移行を実施して以来、それまで四半期に1回ほど発生していたクラスター障害が1度も起きていません。次にArcGISについてお話しします。私たちはこれをOneMapと呼んでいます。 この実装は私たちにとってユニークなものです。図の左上には、パブリックIPアドレスを持つインターネット向けインターフェースが示されています。実は私たちの環境の大部分はパブリックIPを持っていないため、この部分には特に注意を払う必要がありました。Amazon Route 53、仮想Palo Altoファイアウォール、そしてAWS Web Application Firewallを導入してこれを実現しています。アーキテクチャの残りの部分は、皆さんにとってはそれほど目新しいものではないでしょう。
これは皆さんのArcGIS実装と比べると小規模かもしれませんが、先ほど申し上げたように、以前別のクラウドにArcGISをリフト＆シフトした際にはうまくいきませんでした。そこで今回は、正しく再設計を行いました。素晴らしいチームを結成しました。また、プラットフォームのオーナーが出産を控えていたため、彼女がプラットフォームのことを気にせずに出産に臨めるよう、タイトな期限内に完了させる必要がありました。そして私たちはそれを実現しました。ここでの近代化には、Azureファイル共有からAmazon FSXへの移行が含まれています。さらに重要なのは、データベースをInfrastructure as a ServiceからPlatform as a Serviceに移行し、専用のSQLサーバーからAmazon RDSに移行したことです。AWSとの主要な議論の1つは、より多くのISVがRDSで製品認証を取得するよう依頼することです。そうすれば、クラウドにSQLサーバーインスタンスを置く必要がなくなります。
このプラットフォームのメリットは大きく、確かにこのチャートにはたくさんのアイコンが表示されています - 最初のバージョンではこの2倍ほどのアイコンがありました。しかし、冒頭で申し上げたように、シンプル化が当初の技術的目標でした。これにより、セキュリティの向上、可用性の向上、監視の効率化、スケーラビリティの改善がすべて、単一のプラットフォームに焦点を当てることで達成しやすくなります。2番目は、リーダーシップへの説得方法です：単一のプラットフォームと目標に向けたスキルの集中的な活用です。しかし最も重要なのは、これによって得られる（または得られつつある）デリバリースピードの向上です。イノベーションへの集中、自動化とプラットフォームの回復力への集中、コスト最適化への集中、そして最も重要なのは、2030年の目標達成に向けたビジネスのためのイノベーション提供の加速です。
途中で学んだことがいくつかあります。この機会を活用して近代化を進めることができました。 数スライド前で説明したように、プラットフォームをより安定的で、回復力があり、パフォーマンスの高いものにするために様々なレベルで近代化を行いました。一方で、あまりにも多くの変更を加えようとして移行のタイムラインを脅かすこともありました。そのため、どれだけ早く実施したいかと、どの程度の近代化を行いたいかのバランスを取る必要があります。Well Connected Portalのように、End-of-Service-Lifeのコンポーネントを多く抱えるプラットフォームもありましたが、実質的にアプリケーションの書き直しが必要となるため、アップグレードの時間を取ることができませんでした。
近代化にはニーズに応じた適切なバランスを見つけることが必要です。早期かつ頻繁なコミュニケーションと調整が重要です - いくら頻繁に連絡を取っても足りないということはありません。また、複数のチャネルを使用する必要があります。 メールの一斉送信、ミーティングやアナウンス、社内のソーシャルメディア的なプラットフォームの活用、そして時には昔ながらの対面での打ち合わせも必要です。驚いたことに、経営陣レベルや中間管理職レベルでの数々のミーティングを経て、この取り組みについて説明したにもかかわらず、「このOneCloudって何？なぜ私のこのプロジェクトやあのプロジェクトの妨げになっているの？」と、あるリーダーから呼び出されることが何度もありました。これは誰もが常に注目している話題ではないので、定期的に意識を喚起する必要があるのです。
ドキュメントは素晴らしいものです。このプロジェクトを始めた時にドキュメントがあれば、もっとスムーズに進められたはずですし、実装パートナーからの不満も少なかったでしょう。今はドキュメントがありますので、これを最新の状態に保っていければと思います。ビジネス部門が独自に行っている特別な作業には要注意です。私たちが直面した最大のリスクの一つ、そして一部のロールアウトや変更が大幅に遅れた主な理由は、コミュニケーションの問題を解決しようとしたことでした。
テクノロジー部門が把握していない、誰かが独自に構築したツールやインテグレーションの存在を特定するのに苦労しました。すべてのものをCMDBに登録できれば理想的ですが、それは現実的に可能でしょうか？おそらく無理でしょう。ですから、皆さんの知らないところで何が動いていて、それが何に依存しているのか、何と連携しているのかには注意が必要です。実際、あるシステムを廃止した際、すべてのプロセスを踏み、必要だと思われる関係者全員に通知し、システムを停止したのですが、数日後に誰かが大騒ぎをするという事態が起きました。
もう一つの重要な教訓は、このような大規模な移行の最中にサービスパートナーを変更するのは得策ではないということです。このプロジェクトの途中で、サポートチームと開発チームの約75%を入れ替えました。移行対象のアプリケーションについて説明してくれるチーム、そして移行後にそれらのアプリケーションの引き継ぎを受けるチーム - これが最も大きなスケジュールへの影響を与え、15ヶ月の予定が18ヶ月に延びる結果となりましたが、なんとか乗り越えることができました。
では次は何でしょうか？re:Inventに注目していない方のために、画面に表示されているAI生成画像がヒントになります。残念ながら、単一のプラットフォームに集中できるようになった今、私たちが取り組んでいるGenerative AIの具体的な内容についてはここでお話しできませんが、Leeが戻ってきて、その取り組みのプロセスについてお話しします。
Generative AIのビジョンとデータ戦略
ありがとう、Mike。素晴らしい発表でした。では、Generative AIについて話しましょう。イノベーションは産業を変革することができます。今日は生産運用の変革について話していますが、中心となるGenerative AIが変革の触媒になり得ると考えています。McKinseyの調査によると、Generative AIは年間2.6兆から4.4兆ドルの価値を世界経済にもたらすとされています。考えてみてください - 比較のために言うと、調査時点でのイギリスの経済規模は約3.1兆ドルでした。このような規模の変化は、グローバルな規模で変革的な影響をもたらすことでしょう。
しかし、お客様が Generative AI の構築を始めるにあたって、いくつかの疑問をお持ちです。 おそらく皆様も同じような疑問をお持ちかもしれません。まず、「どうすれば自社のデータを安全かつプライベートに保てるのか」という点です。ご存知の通り、セキュリティは AWS における最優先事項であり、お客様にとっても最も重要な関心事です。次に、「特に大規模な展開において、どうすれば迅速に進められるのか」「どうやって始めればいいのか」という点です。素早くイノベーションを起こしたいものの、始め方にはどのような選択肢があるのかと考えています。そして3つ目は、モデルの選択についてです。数多くのモデルがある中で、自社のユースケースや要件に最適なものは何でしょうか。
本日はこれらについて話し合いますが、まずは大きな視点から、Generative AI のビジョンとロードマップについて見ていきましょう。ビジョンは単純に、右上のビジネス価値に到達することです。 McKinsey の調査を思い出してください。Generative AI は世界経済に数兆ドルの価値をもたらすと言われています。問題は、そこにどうやって到達するかです。ロードマップはあるのでしょうか？上部のビジネス価値に到達したいのであれば、左下から逆算して取り組む必要があります。重要なビジネス目標と価値を特定することから始めます。今日は生産操業の変革について話していますが、これは生産安全性の向上、非生産的な時間の削減、コスト削減、そして企業のリスク管理を意味します。もちろん、成長や収益性、新製品・サービスの開発など、異なる目標もあり得ます。
そして、このロードマップ上で自分の位置を見出すことになります。現在の技術とデータプラットフォームを評価し、Mike が言及したように、複雑さが見られる部分を簡素化し、ギャップがある部分で能力を構築していきます。その後、AI とデータの戦略を策定し、従業員のトレーニングとスキルアップを行います。移行の際に話題に上ったスキルギャップを覚えていますか？それは Generative AI においても同様に、あるいはこの分野が急速に進化し変化しているため、さらに重要になっています。次に、ガバナンス、セキュリティ、リスク管理のフレームワークを確立します。最終的にそこに到達できる理由は、傍観者として留まることができないからです。
世界が前進を続ける中で、組織が何もしないでいることはできないため、AI ソリューションは避けられません。AI を受け入れれば、あとはソリューションのパイロット実施とテスト、本番環境へのデプロイとモニタリング、そして継続的な改善と評価を通じてスケールアップし、ビジネス価値を実現することになります。では、データ、お客様の迅速な開始方法、そしてモデル選択に関する3つの具体的な質問に答えていきましょう。
まず、データについて話しましょう。誰もがモデルとアプリケーションについて話していますが、それらは非常にエキサイティングで急速に進化しているものの、氷山の一角に過ぎません。表面下には、さらに多くの複雑さが潜んでいます。構造化・非構造化データの保存は依然として必要です。現在のアプリケーションやカスタマーエクスペリエンスをサポートしているため、様々なタイプの運用データベースも全て必要です。Data Lake とアナリティクスは、企業や事業に特有のデータを蓄積する場所として重要です。データ統合には、データパイプラインの設定と、AI および Generative AI ソリューションで使用できるようにデータを変換することが含まれます。最後になりましたが、データガバナンスによって、データ品質、プライバシーとコンプライアンス、セキュリティ、そしてアクセスコントロールが確保されます。
データは差別化要因です。左側から見ていきましょう。スケーラブルなData Lakeと目的に特化したデータサービスを備えたモダンなデータ戦略から始まり、それによって上部にある、より優れたGenerative AIモデル、つまり御社のビジネスにより適したコンテキストを持つモデルの構築が可能になります。より優れたGenerative AIモデルとエクスペリエンスは、より良い製品やサービスにつながり、それによってより多くのユーザーを惹きつけ、ユーザーの採用率とエンゲージメントを高めることができます。そして、それがより多くのデータを生み出し、そのデータがスケーラブルなData Lakeに還元されていくのです。
データについて説明したところで、業界内の企業やパートナー、競合他社がこぞってGenerative AIのトレンドを取り入れている中、お客様からは「どうすれば素早く始められるか」という質問をよくいただきます。パートナー企業と協力する方法を選ぶ企業もあれば、社内でDIYに挑戦する企業もあります。ここでAWSと直接イノベーションを進める例をご紹介します。左端では、AWSのSolutions Architect（SAと呼んでいます）と協力して大きな構想を描きイノベーションを起こすことができます。興味深いのは、GartnerのMagic Quadrantで、AWSが14年連続でStrategic Cloud Platform Servicesのリーダーに選ばれていることです。今年、GartnerはAWSのソリューションサポートを重要な差別化要因として特に評価しています。業界別、特定のテクノロジースタック、エンタープライズワークロードを専門とするAWS SAと協力することで、お客様の具体的なユースケースや要件に合わせたソリューションの設計と提供を行うことができます。
中央にあるのがGenerative AI Innovation Centerです。ここではAWSのチームがお客様と協力して、MVPのスコーピングを加速し、迅速なPoCプロトタイピングを行い、本番環境への移行パスを設計します。また、私たちの取り組みではAWS Professional Servicesとも連携してデリバリーを行っています。最後に、右端にはAmazonのイノベーション手法があります。私たちはAmazonのWorking Backwards手法を活用するデジタルイノベーションチームと協力し、PR/FAQを作成し、製品のユーストーリーやビジュアルを開発しました。
こちらが私たちのGenerative AIソリューションの概要です。左側のユーザーから始まり、これはオフィスの従業員やフィールドオペレーションチームで、データとの会話型エクスペリエンスを持つことができます。アプリケーションとのやり取りは質問から始まります。最初のソリューションコンポーネントは質問書き換え（Question Rewrite）と呼ばれ、 ユーザーのリクエストや質問を会話のコンテキストや追加情報とともに受け取ります。
書き換えられた質問は、2番目のソリューションコンポーネントであるRouterに送られます。 Routerは、それがPythonのユースケースなのか、SQLジェネレーションのユースケースなのかを判断します。Pythonジェネレーションのユースケースの場合は、右上のPython Generator に送られ、Pythonコードを実行してグラフを生成します。SQLジェネレーションのユースケースの場合は、4番目のソリューションコンポーネントであるSQL Generatorに送られ、SQLクエリを生成して実行し、表形式のデータを返します。 最後に、取得されたデータと自然言語のコンテキストは、中央下のソリューションコンポーネント であるData2Textによって統合され、表形式のデータと自然言語クエリを組み合わせてテキスト応答を生成し、左端のユーザーに返されます。
Generative AIソリューションのアーキテクチャとモデル選択
アプリケーションアーキテクチャについて、一緒に詳しく見ていきましょう。これは300レベルのセッションですので、段階的に説明していきます。まずアーキテクチャ図の右上から始めます。右端にあるAmazon S3にドキュメントを保存します。これらは私たちの業界でよく見られるPDFドキュメント、製造オペレーションマニュアル、手順書などです。Amazon Textractを使用して、ドキュメント、フォーム、表、画像から情報を抽出します。そしてドキュメントをベクトルに変換し、Amazon OpenSearch Serviceに保存します。この変換にはAmazon Bedrockとそのエンベディングモデルを使用します。アプリケーションのこの部分から始めるのは、お客様のデータでアプリケーションを準備するためです。先ほどお話ししたように、データこそが差別化要因となるのです。
残りのアプリケーションは、サーバーレスアプリケーションアーキテクチャの設計に従っています。左端に戻って、エンドユーザーがフロントエンドアプリケーションと対話する部分から見ていきましょう。アプリケーションはAmazon API Gatewayにリクエストを送信し、それはAWS Lambdaによってバックエンドで処理されます。アプリケーションと対話する同時接続ユーザーを処理するために、左下にあるAmazon Simple Queue Service（Amazon SQS）とAmazon DynamoDBを使用して、複数のユーザーリクエストをキューイングして保存します。SQLの生成ユースケースでは、Lambda関数がAmazon Bedrockを呼び出してSQLクエリを生成し、それをAWS上のデータベースに対して実行します。これにはリレーショナルデータベースのRDSだけでなく、AWS上で動作するあらゆる種類の運用データベースが含まれます。
元のデータが取得され、RAGパターン（検索-拡張-生成パターン）の場合、Lambda関数がデータを取得して返します。その後、Lambda関数は再びAmazon Bedrockを呼び出して、表形式のデータと自然言語のコンテキストをテキストレスポンスとしてフロントエンドのユーザーに返します。さて、これまでデータについて、そしてAWSとお客様が一緒にどのように始めるかについて説明してきました。3番目の質問は、お客様がどのようにモデルを選択できるかということです。多くのモデルが利用可能ですが、どれが最適なのでしょうか？私たちが見ているのは、モデル選択は精度、レイテンシー、コストのバランスであるということです。2024年を通じて、Foundation ModelやLarge Language Modelにおいて非常に速いペースでイノベーションが続いています。すべてを支配する1つのモデルは存在せず、お客様はモデルの選択肢から利点を得ることができます。
最後に、これは私たちのエンゲージメントにおけるモデル選択のまとめです。先ほど見た複数のGenerative AIソリューションコンポーネントをモデルを使用して構築しました。パフォーマンスを向上させるために、異なるプロンプトエンジニアリング技術と異なるモデルの組み合わせを試しました。
精度、レイテンシー、コストのバランスを選択基準として使用しました。ソリューションコンポーネント、プロンプトエンジニアリング技術、モデルは下の表にまとめられています。本日は、移行とモダナイゼーションを旅として捉え、Mikeがbpx energyのOneCloudの例を通じて、クラウドインフラストラクチャとポスチャーをどのように簡素化したかを説明しました。データが差別化要因となるGen AIビジョンとデータ戦略について話し、AWSでイノベーションを起こす方法と例を紹介しました。そして最後に、モデル選択はバランスが重要だということを説明しました。
本日のプレゼンテーションの詳細とコンテキストについてさらに学びたい方のために、こちらにQRコードをご用意しました。1つ目は、私たちのユースケースと実装の詳細についてAWSとbpx energyが共同で執筆したブログです。真ん中のものは、bpx energyのData ScienceとAIの責任者であるMatt McElheneyによるCERAWeekでのプレゼンテーションです。Mattには素晴らしいプレゼンテーションをしていただき、大変感謝しています。右端のものは、先ほどMikeが言及したもので、bpx energyのCTOであるJordy Harrellが2年前に当時の取り組みについて行ったプレゼンテーションです。
本日この場にいらっしゃるbpx energyのチームの皆様に感謝申し上げます。私たちの journey とストーリーに耳を傾けていただき、ありがとうございます。他のセッションと同様に、アンケートへのご協力をお願いできればと思います - 5つ星の評価をいただけると大変嬉しく思います。ご質問がございましたら、こちらの横でお受けいたします。ご来場ありがとうございました。イベントの残りもお楽しみください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion