re:Invent 2024: AWSが発表したApp Studioでアプリ開発を革新
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - AWS App Studio: The fastest and easiest way to build applications (AIM218)
この動画では、AWSが新たにリリースしたAWS App Studioについて、プロダクトチームリーダーのJohn BrockとFrancoisが詳しく解説しています。AWS App Studioは、Generative AIを活用してアプリケーション開発を根本から変革するツールで、60秒以内でアイデアからアプリケーションを作成できます。NFLの事例では、選手のヘッドショット処理ワークフローを自動化し、Adobe FireflyのAPIを活用して画像処理の完成度を98%まで高めています。デモでは、ITヘルプデスクアプリケーションをリアルタイムで作成し、Amazon Bedrockを活用した修理メモの要約機能を追加する様子を紹介。AWSの消費ベースの価格設定を採用し、ユーザーの使用時間に応じた課金（月1時間で25セント）という特徴的な料金体系も明らかにしています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS App Studioセッションの開始：概要と期待
おはようございます。皆様、音声は聞こえていますでしょうか。ヘッドフォンがオレンジ色になっていない場合は、おそらく別のセッションを聞いていることになります。もし聞こえない方がいらっしゃいましたら、手を挙げていただけますでしょうか。聞こえている方は親指を立てていただけますと幸いです。今回は少し異なるセッションとなります。もし聞こえない場合は何らかのジェスチャーをしていただけますと助かります。プレゼンテーションの半分まで進んでから気づくということは避けたいと思います。
このセッションはインタラクティブにしたいと思います。私たちの説明で良いと感じたことや、プロダクトについて興奮を感じた場合は、2本指を立てていただけますと幸いです。ペースが遅すぎると感じた場合は「スピードアップ」のジェスチャーを、速すぎる場合は「スローダウン」のサインを送ってください。皆様にこのセッションを最大限活用していただきたいと考えています。私はAWS App Studioのプロダクトチームを率いるJohn Brockです。本日は、このプロダクトについてお話しできることを大変嬉しく思います。7月にプレビューを発表し、11月中旬の2週間前にGAに到達したばかりで、新機能についてもお話しできることを楽しみにしています。
本日はプロダクトチームのFrancois Gastも同席しており、NFLの素晴らしい顧客事例についてお話しできることを大変嬉しく思います。本日はShawn Badenにもご参加いただいています。彼からは、なぜNFLがAWS App Studioを選択したのか、そしてApp Studioを使用してNFLのどのようなユースケースを改善しているのかについてお話しいただく予定です。
それでは、本日のアジェンダについてご説明させていただきます。内容の濃い予定を組んでいます。まず、AWS App Studioについて、そしてここまでの経緯、お客様から寄せられた摩擦点や課題、そしてなぜAWSがApp Studioの開発を決めたのかについてお話しします。新機能についても触れますが、プロダクトの概要は簡潔に済ませ、NFLのユースケースにより多くの時間を割きたいと考えています。実際のアプリケーションのスクリーンショットをご覧いただき、NFLが現在どのようにApp Studioを実践的に活用しているかをご紹介します。
アジェンダスライドには記載されていませんが、本日はデモにも多くの時間を割く予定です。リアルタイムでアプリケーションを生成する様子をお見せします - 完全なライブデモで、事前録画は一切ありません。プロダクトの体験を一緒に見ていきましょう。最後にロードマップの概要をご紹介し、今後リリース予定の機能や最近リリースした機能についてお話しします。これは皆様からより多くのフィードバックをいただき、次に開発する機能に影響を与えていただく機会にもなります。
最後に、次のステップについてお話しします。セッションの途中で興味を持たれた方は、re:Inventの他のセッションもカタログでブックマークしていただけます。今日の午後にはディープダイブセッションもあります。また、最後にQRコードで読み取れる入門チュートリアルや次のステップガイドへのリンクもご用意しています。ご来場ありがとうございました。では、Francoisに引き継ぎたいと思います。
企業が直面するアプリケーション開発の課題
ありがとう、John。皆様、本日はお越しいただき、ありがとうございます。 なぜAWS App Studioを構築したのか、お話しさせていただきます。私たちは多くのお客様とお話をする中で、今日皆様にもきっと共感していただけるであろう課題に気づきました。Line of Businessから要求されたアプリケーションのバックログを完全に解消できている方はいらっしゃいますか？おそらく誰もいないでしょう。これが現在の主な課題ですが、これは私たちが置かれている世界の性質でもあります。常に進化し、より良いものを目指し、時には新しい課題に取り組もうとしています。そのためには常に新しいツールが必要になります。
当然、組織のIT部門がその要求を受け、アプリケーション開発のボトルネックとなってしまうことが多いでしょう。私たちが多く耳にした2つ目の課題は、開発者不足です。開発者は非常に貴重なリソースで、簡単には見つからず、多くの場合、組織内で最も価値の高いプロジェクトに配置されています。ほとんどの場合、顧客向けのコンテンツやソリューションの開発に従事することになります。これは当然のことです。そのため、社内利用のアプリケーションを開発しようとすると、そのリソースの獲得に苦労することになります。これは私たちがよく耳にする課題の一つです。また、お客様からはレガシーアプリケーションに縛られているという声も聞きます。
これらのアプリケーションはリファクタリングが難しく、規模も大きいことが多いのです。場合によっては長年使用されており、一から作り直すとなるとリファクタリングは簡単な作業ではないと感じています。アプリケーション構築の総所有コストは、開発作業だけではありません - それは恐らくコストの半分程度です。セキュリティパッチやコードライブラリの更新など、アプリケーションの保守にも多大なコストがかかります。
部門全体で5,000から20,000のアプリケーションを抱える企業組織にとって、これらの課題は時間とともに大きな問題となっています。また、多くのリーダーが、より迅速な結果とより早い価値の実現を求めているということも耳にしています。イノベーションはもはや6ヶ月もかけて実現するものではありません。人々は6週間から3ヶ月の期間で、Proof of Conceptを構築し、イノベーションを示し、明日の可能性を提示できる必要があります。従来のコードよりもはるかに早く価値を提供できるツールを、チームに提供したいと考えています。
チームが解決策を探る際、まず最初に Low-code ツールに目を向けるのは当然のことです。開発作業のスピードアップを目指すなら、Low-code が提供する抽象化によって、チームのアウトプットを大幅に加速することができます。しかし、お客様からは、これらのツールを導入しても、学習曲線が非常に急で、導入の度合いもツールによってまちまちだという声を聞きます。対象とするユーザー層が異なり、独自の言語を習得する必要があったり、社内に専門知識を持つ人材がいない既存の言語を使用したりする必要があるケースもあります。
もう1つの懸念は、アプリケーションのスケーラビリティとパフォーマンスです。多くのアプリケーションは、最終的な規模で始まるわけではありません。よくあるのは、小規模なチームが構築したアプリケーションが成功を収め、6ヶ月後には150人もの複数チームが使用するようになるというケースです。そして、そのアプリがスプレッドシートをバックエンドに持ち、データモデルが完全に制御不能になっており、予定外の大規模なリファクタリングが必要になるということがわかるのです。そのため、大規模な組織からは、最初から適切にアプリを構築することの重要性についてよく耳にします。
ガバナンスについても広く意見を聞いています。組織に Low-code ツールを導入することで、それ自体がシャドーITになってしまうことがあります。これは特に、テクノロジー業界やエネルギー部門など、博士号を持つ従業員が在籍し、自らアプリを構築できる技術力を持つ組織で顕著です。データはどこに保存されているのか？アプリへのアクセス方法は？組織内のすべてのアプリケーションに対する可視性はどの程度か？これらの課題は、大規模な組織が本当に苦心している問題です。
最後に、お客様から伺った点として、何千人ものユーザーに対応するためのプラットフォームのスケーリングコストが、時間とともに法外なものになってしまうという課題があります。エンドユーザーを異なる料金プランに登録させる必要があるサブスクリプションモデルは、大規模な展開では現実的ではありません。そこで John、このプロジェクトを始めた時のビジョンについて教えていただけますか？AWS App Studio を始めた本当のビジョンは、既存のソリューションに対するお客様のこれらの課題や摩擦を解決することでした。
AWS App Studioの革新的アプローチ：Generative AIの活用
私たちは単なる新しい Low-code ツールを作るのではなく、Generative AI を活用してアプリケーション開発の方法を根本から変革したいと考えました。そこで私たちは、Generative AI を中核に据えて AWS App Studio を一から構築しました。これこそが、プロフェッショナルな開発の専門知識がなくても、エンタープライズグレードのアプリケーションを構築できる最速の方法を実現できた理由だと考えています。もちろん、プロフェッショナルな開発者であれば素晴らしいのですが、本番環境へのアクセスを制御する管理ツールやパネルを維持するために、コードベースの完全な制御やCI/CDパイプラインの設定、複数のデプロイメントターゲットの設定が必要ないアプリケーションも数多くあるはずです。
クライアントや消費者が使用・操作するアプリケーションや、App Storeにリリースするアプリケーションについては、完全なコントロールを維持したいものです。しかし、社内のビジネスプロセス用アプリケーションについては、運用の負担を軽減してイノベーションを加速させたい、そしてそれらのアプリケーションの提供を優先したいと考えるはずです。
そこで私たちは、Generative AIアシスタントを中心とした AWS App Studioを構築しました。このツールを使えば、60秒以内でアイデアからアプリケーションを作成できるだけでなく、今回のGA版リリースでは、アシスタントとチャットしながら既存のアプリケーションを修正することも可能です。直感的なドラッグ＆ドロップツールを使用するか、アシスタントにアプリケーションの修正を依頼することで、クリックや操作を自分で行う必要がなくなります。
AWSが提供するApp Studioで構築されたすべてのアプリケーションは、バックグラウンドで完全にコード生成されています。CloudFront、Lambda、S3、DynamoDBなど、標準的なAWSのテクノロジーとサービスにデプロイされる最新のフルスタックWebアプリケーションです。すべてのアプリケーションはサーバーレスですが、独立したアプリケーションとしてデプロイされます。マルチテナントランタイムでの実行や解釈実行ではなく、プロの開発者が書くのと同じようなアプリケーションですが、従来のアプリケーションに伴う運用のオーバーヘッドなしで、デプロイ、スケール、保守、運用を行います。
これらのアプリケーションは、企業が保有する既存のビジネスデータ、最も重要なデータに接続するため、セキュリティとガバナンスは譲れない要素です。App Studioインスタンスの管理者は、AWSのデータソースや他のシステムに接続する際の詳細なアクセス制御ポリシーを正確に定義できます。さらに、サードパーティシステムに接続する場合、エンドユーザーは自身としてOAuth認証を使用します。つまり、アプリケーションからSalesforceやHubspot、Twilioにリクエストを行う場合、特権ユーザーや統合ユーザーとしてではなく、エンドユーザーとして行います。そのため、App Studioアプリでは、そのサードパーティアプリケーションに直接ログインした場合と同じデータしか見ることができません。
さらに、組織内で構築されたすべてのアプリケーションを管理者が確認できること、それらのアプリケーションを監視できること、アプリケーションのビルダーがアプリケーションレベルの役割を定義できることなど、エンタープライズアプリケーションに求められるセキュリティとガバナンスのニーズや要件を満たすための幅広い制御が可能です。そして、Francoisが言及していたこれらのソリューションのコストについてですが、私たちは従来のAWSの消費ベースの価格設定と課金モデルを採用していることを嬉しく思います。つまり、構築は完全に無料です。ビルド環境にログインし、App Studioを有効にしてログインすれば、アプリケーションの構築、Generative AIを使用したアプリケーションの生成や修正が完全に無料で行えます。
公開したアプリケーションのエンドユーザーの使用時間に対してのみ課金されます。ユーザーが月に1時間アプリを使用した場合、25セントの支払いで済みます。月額10ドルのユーザーライセンス料を支払う必要はありません。もしそのユーザーがログインしない場合、つまり1か月間誰もアプリにログインしなければ、一切料金は発生しません。これらのアプリはServerlessで、使用した分だけ支払えばよいのです。高額な長期月額契約やユーザーライセンスを維持する必要はありません。
AWS App Studioの実用例：Amazonでの活用事例
先ほど申し上げたように、11月中旬の2週間前にGeneral Availabilityを発表しました。それ以前のプレビュー期間中に、お客様は素晴らしいアプリケーションを構築されました。 ユースケースの範囲は非常に広範です。Amazonの社内でも、すでに約25のチームがAWS App Studioで構築したミッションクリティカルなビジネスアプリケーションを本番環境にデプロイしており、さらに数十から数百のアプリが現在開発中です。その一例が、Amazon Transportation Services（ミドルマイルキャリア）です。高速道路で見かける18輪トラック、あの大きなPrimeトレーラー、青い大型トラックは、フルフィルメントセンターからソートセンターへ荷物を運んでいます。フルフィルメントセンターは、コンテナが到着し、荷物が降ろされる巨大な倉庫で、そこからソートセンターに配送され、最終的に小規模な配送拠点に配送されて、24時間配送や2時間配送が実現されるのです。これらのトラックは、フルフィルメントセンターからソートセンターへと荷物を運び、在庫を再配分しているのです。
以前は、これらのトラックの積み込みや管理を行う従業員は、荷物が急増したり、トラックが来なかったり、Black FridayやCyber Mondayで2台目のトラックが必要になったりした場合、手作業で例外処理を行っていました。輸送能力の割り当て変更のプロセスは完全に手作業でした。彼らはAWS App Studioを使って数週間でアプリを構築し、デプロイして規模を拡大しました。現在では、Amazonのフルフィルメントセンターで約39,000人の従業員がこのアプリを使用して、新しいトラックのリクエスト、荷物の再配分を行い、拠点間の荷物の移動をより効率的に行うことで、お客様へのAmazonの配送をさらに迅速化しています。Amazonにとって、荷物をより効果的に移動できるようになったことで、最適化とコスト削減の効果は非常に高くなっています。
社内の他のチームも、コンプライアンスや証明書のローテーション管理、メディアアセットや画像の承認プロセスなど、さまざまなユースケースで活用しています。 このプラットフォームは、幅広いユースケースをサポートできるように設計されており、これからソリューションをご紹介する際にそれがよくわかっていただけると思います。社内のニーズに最適な従来型のソリューション、つまりフォームを作成してデータを収集し、自動化でそれらを処理し、ドキュメントを適切なデータストアやリポジトリに安全に保存する必要があるようなユースケースは、AWS App Studioの得意分野です。在庫や機器の管理もその一例です。
COSCO SHIPPING Logisticsのように、アセット管理のためのソリューションを素早く構築したお客様も複数いらっしゃいます。必要に応じてロジックをカスタマイズし、コア機能のコードを簡単に拡張できるため、さまざまな種類のソリューションが実現されています。より複雑な承認プロセスにも対応できるので、組織内で必要な承認プロセスがあれば、それに適したソリューションとなります。現在、バーレーン、シンガポール、南アフリカでAWS App Studioを使用して検査を行っている企業もあります。データセンターで検査を実行し、そのデータはすべてAmazon Redshiftに集約され、QuickSightでリアルタイムにレポートされています。データが数日かけて中央リポジトリに少しずつ蓄積されていく従来のシステムから、検査コンプライアンスの現状をリアルタイムで報告できるシステムへと移行することができました。
このチームはベンダー管理システムも構築しました。このように、私たちが構築できるアプリケーションには大きな多様性があることがわかります。個人的に私が気に入っているのは、集中型のケース情報とCase Managementというコンセプトです。これは本質的に、異なるデータソースからのデータを1つのインターフェースに集約し、ビジネスプロセスに関する意思決定に必要なすべての情報を簡単に閲覧できるようにするというものです。これらのユースケースについて、私たちはさらなるインパクトを与え、ソリューションの構築をより一層シンプルにしていくことが期待できます。 Shawnさん、AWS App Studioで初めてのソリューションを構築されましたが、少しご自身について教えていただけますか？NFLでどのようなお仕事をされているのか、そしてこれまでの経歴について教えてください。
NFLにおけるAWS App Studioの導入：ヘッドショット処理の効率化
私は2003年にネットワークが立ち上がった時にNFLに入社しました。つまり今では約21年になりますね。NFLにはアーティスト、ブロードキャストデザイナー、アニメーターとして入社しました。皆さんの言葉で言えば、PhDキャンプというよりもクラフティキャンプに属する方だと思います。ただ、コードに興味を持つようになり、すぐにコードを少し書くことで自分のデザインをインタラクティブにできることを発見しました。そしてその後、自動化の力に気づきました。それから何年も経った今、NFLの様々なグループや部門向けに自動化システムを構築しています。
どの部門と協力しているか、そしてソリューションがどこで最も役立っているかについて聞かれると、私たちは少なくとも3〜4つの異なるグループが密接に関わるヘッドショット処理の新しいワークフローを作成しました。
従来、NFLはアメリカ全土の32チームに写真家を派遣し、2〜3日の間に最大3,200枚のプレイヤーの写真を撮影します。これらの写真が準備できると、私たちが使用しているクラウドリポジトリにアップロードされます。その後、写真部門がABC、NBC、CBSなどのすべてのパートナーにアクセス権を付与します。また、社内向けにもアクセス権を付与します。その時点で、NFL内の異なるグループがそれらの画像にアクセスし、ダウンロードして、様々なベンダーに送って処理してもらいます。処理というのは、頭部を切り抜き、背景を削除し、各グループの仕様に基づいてヘッドショットのサイズ調整やトリミングを行うことです。
この正確なメディアプロセスにおける自動化の機会について聞かれた時、私は多くの重複があることにすぐに気づきました。処理における重複が至る所にありました。複数のグループが同じヘッドショットを異なるベンダーでダウンロードして処理していましたが、それらは全く同じヘッドショットだったのです。また、ローカルストレージの重複もあり、非常に面倒で時間のかかるプロセスでした。多くの大企業と同様に、NFLも非常にサイロ化されていたため、この問題を解決するのは困難でした。異なる部門の人々が協力して、より集中的なプロセスを作り出すのは簡単ではありませんでした。
この問題を解決するための最初のステップとして、カスタムコードによるReactウェブアプリを作成しました。これにより、基本的にアーティストであるユーザーが、クラウドリポジトリや私たちのローカルサーバーなど、どのリポジトリからでも画像を取得し、それらの画像をAWSのAmazon S3バケットのようなバックエンドに転送できるようになりました。Adobe Photoshop APIを使用したヘッドショットの切り抜きなど、多くの処理がそこで行われ、画像認識を使用してプレイヤーのヘッドショットのサイズ調整やトリミングを行います。アーティストはそのウェブアプリを使用して画像にアクセスしダウンロードでき、必要な人に配布できるようになりました。
AWS App Studioの導入プロセスと技術的詳細
タイムラインについて聞かれた際、本番環境への移行に約6ヶ月ほどかかりました。9月に会議を行い、AWS App Studioを紹介された時に最も興味を引かれたのは、ほとんどコードを書かずに素早くアプリケーションを立ち上げ、バックエンドサービスとの連携を少ない労力で実現できる点でした。セキュリティチームはAWS App Studioの使用について何か懸念を示しましたか？特定の要件について心配されましたか？
AWS App Studioの素晴らしい点は、最初に作成したアプリと比べて、セキュリティ部門が対応しなければならない多くのセキュリティやコンプライアンス要件を処理してくれることです。例えば、Secrets Managerによる認証情報の管理は特に有益でした。
これが実際のアプリケーションです。ここで何が行われているのかご説明しましょう。取り込みのセクションが2つあります。1つはPhotoShelterで、ここに表示されているのは写真リポジトリ内のすべてのコレクションです。コレクションを選択したら、次にチームを選択します。 この時点で、そのチームの全選手を確認できます。1回限りの処理であれば1人の選手を選択できますが、プレシーズン開始前などは、チーム全体を選択することができます。文字通り100人の選手を選択して、Amazon S3バケットにプッシュすると、自動的に処理が開始されます。
このセクションはローカルでの取り込み用です。アクションショットやトリミングが必要な画像がある場合は、このインターフェースを使用します。サーバーやデスクトップ、ダウンロードしたコンテンツなど、あらゆる場所からS3にプッシュできます。これは主にシーズン中の番組制作のサポートで使用されます。 こちらは後処理のセクションです。バックエンドでの処理が完了すると表示されます。現在は1つのジョブに1人の選手しかいませんが、プレシーズン中であれば、理論的には32の異なるジョブがあり、それぞれに100人の選手がいることになります。
アプリケーションのアーキテクチャについてお話ししましょう。Oktaとの統合は、このアプリケーションへの認証が必要というセキュリティ部門の要件に合致しています。App Studioの素晴らしい点は、これらすべてを処理してくれることです。OktaでAWSにログインする企業として、構築したアプリケーションへの接続が自動的に得られます。バックエンドサービスに関しては、Amazon S3バケットとAmazon DynamoDBが迅速にセットアップされ、S3は処理中のすべての画像を保存します。
App Studioをデプロイする際、Identity Centerと一緒にデプロイします。すでにIdentity Centerをお使いの場合は、そのインスタンスに接続するだけで、お客様が使用中のシステムと統合することができます。また、データを保存できるインスタンスもデプロイし、すべてのデータがお客様のアカウントに流れ込むようになっています。重要なポイントは、すべてのデータ、ドキュメント、画像がアカウントに流れ込むようにすることでした。サービスはマネージド型で、インフラストラクチャは当社が管理しますが、サービスへのアクセスとデータフローは、それらのアカウント内に存在する必要があります。AdobeとPhotoShelterへは安全にアクセスし、認証情報はSecrets Managerに保存されます。リソースへのアクセスはロールとポリシーを通じて行われ、お客様のニーズに合わせて正確にスコープを設定でき、公開する内容を完全にコントロールすることができます。
Seanが説明した内容をまとめてみましょう。自身のアカウントのAmazon S3などのサービスへのアクセスから、AdobeとPhotoShelter間のオーケストレーションまで。これらすべてを、単一のビルダーインターフェースで実現しました。このインターフェースを通じて、それらのサービスへのセキュリティ接続を確立し、テスト環境で変更をテストし、開発環境で変更を実行し、そしてテストにプッシュすることができました。
テスト後、Seanは本番環境にプロモートすることができました。これらはすべてすぐに使える状態で提供され、オープンな仕様から取得できたものにアクセスする以外に設定は必要ありませんでした。プロバイダーとの統合は、セキュリティチームからの要件の1つでした。今日では、Seanが構築するすべてのアプリケーションが、このセットアップとネイティブに統合されることになります。
私たちは「将来の計画はありますか？これが最初のアプリケーションですが、他に何か構築を検討していますか？」と尋ねました。彼は次のように答えました。「これは本当に可能性を広げてくれます。次に取り組もうと考えているのは、ジャージーの交換に関する継続的な本番環境の問題です。シーズン中に選手がトレードされる際、例えばCowboysのジャージーで撮影された写真の選手がSeahawksにトレードされるようなケースです。現在はPhotoshopで手作業で行っていますが、Adobe Firefly APIを使用して体の部分やジャージーを識別し、生成的にジャージーを置き換えることができないか検討しています。」
Adobeは最近、Fireflyという新しいAPIをリリースしました。これはこのソリューションの中核となるものです。なぜなら、選手の切り抜きや背景の削除はすべて、彼らが最近リリースしたこのAPIで実行されているからです。SeanはこれらのAPIを使用した進捗について次のように説明しました。「以前とは雲泥の差です。最初のソリューションで使用していたAPIも画像の切り抜きは上手くできましたが、その後、エッジの修正などの手作業が多く必要でした。それが70%程度の完成度だったとすれば、新しいAPIは選手の切り抜きのエッジの余分なピクセルを本当にきれいに除去してくれて、おそらく98%程度まで完成度が上がっています。」
AWS App Studioのデモンストレーション：ITヘルプデスクアプリの作成
Sean、詳細な説明をありがとうございます。これは、実際のソフトウェアを使用したデモをお約束した一例です。John、ここからバトンを受け取っていただけますか。インターネットの調子が悪くなりませんように。Sean、ありがとうございます。皆さまの邪魔にならないよう、静かな拍手で進めましょう。これは本当にすごいことで、選手が日曜の午後に別のチームにトレードされた場合でも、月曜のナイトフットボールまでに、テレビも、ウェブサイトも、すべてが新しいユニフォームの画像で更新されるアプリができるんです。しかも、写真家に撮影を依頼する必要すらありません。
ログインして、セッションがタイムアウトしていないことを確認している間に、皆さまにお聞きしたいのですが、AWS App Studioを有効にして試してみた方はいらっしゃいますか？誰もいませんか？素晴らしいですね。今日は製品をご覧いただき、実際に触れていただけます。実際のコードをお見せしますが、もしかしたらコードすら必要ない、ドラッグ＆ドロップの環境かもしれません。少し前かがみになって失礼します。それでは始めましょう。プレゼンテーションを切り替えて、AWS App Studioで作成していきます。
こちらがAWS App Studioにログインした状態です。これは私たちのオフコンソール体験です。より多くの人々にアプリケーション構築を可能にするという私たちのミッションに忠実に、これはAWSコンソールからAWSアカウントで有効化されますが、一度有効化すると、Identity CenterやIdentity Providerと統合されます。App Studioで公開されたアプリの管理、構築、アクセスには、企業の認証情報を使用し、これは完全なオフコンソール体験となります。AWSコンソールへのアクセス権がない人でも、管理者になったり、ビルダーになったり、公開されたアプリにアクセスしたりできます。私はログインしてBuilder Hubに到着しました。ここでは、自分が構築したアプリや、共有されているアプリをすべて確認できます。また、新しいアプリの作成や、製品について学んだり、チュートリアルを見つけたり、始めるための情報を得ることもできます。
少し寄り道をして、上部を見てみましょう。Admin Hubがあります。もしあなたがAWS App Studioのインスタンスをセットアップする管理者であれば、オフィスや自宅に戻ってから、このビューが見えるはずです。これは、AWS App Studioが提供するセキュリティとガバナンスコントロールについて説明しています。組織内のビルダーが製品内で定義されたアクセス権と機能を持てるように、ロールとコネクタをセットアップすることができます。
ロールについては、App Users、Admins、Buildersがあることがわかります。Identity Providerと統合されているため、既存のLDAPやADグループをすべて使用しています。AWS App Studioチームを管理者として、AWS App Studioエンジニアをビルダーとして、あるいはAWS App Studio XYZをアプリユーザーとして設定できるため、管理の観点から、誰が何をできるのかを本当にコントロールすることができます。
2つ目のポイントは、コネクターをセットアップできることです。 これは基本的に、既存のビジネスデータへのコネクターを事前承認してセットアップするプロセスです。Shawnの話にあったように、彼らはすでにAmazon S3を使用しており、ジョブを追跡するためにDynamoDBを新しく導入しました。そこで、S3の既存データへの接続や、既存リソースへの接続、新しいデータの保存が可能であることをお見せします。私たちは、最も一般的なAWSサービス向けの組み込みコネクターを提供しています。一般的なAWSコネクターを使用すると、Bedrock、Lambda、Textract、Recognitionを含む200以上のAWSサービス、そして本日発表されるすべてのサービスに接続できます。
Bedrock Agentsもここで利用可能になり、AWS App Studioアプリケーションに統合できます。また、先ほど説明したAdobe APIやPhotoShelter APIへの接続と同様に、REST APIコネクターを使用してOpenAPI仕様をアップロードできます。さらに、Salesforce用の組み込みコネクターも用意されており、近々より多くのサードパーティアプリケーション向けのネイティブコネクター体験が追加される予定です。これらは、ユーザーごとの認証を含む様々な認証メカニズムをサポートしているため、ユーザーは自身の認証情報でそれらのサードパーティアプリケーションやデータにアクセスできます。
では、Builder Hubに戻って開発を始めましょう。Create Appをクリックすると、 私たちが「Getting Started Flow」または「Cold Start Experience」と呼んでいる画面に移動します。これは、製品内でGenerative AIと初めて対話する場面です。ビルダーとして、これが最初のステップとなります。右側には、お客様から寄せられた最も一般的なユースケースを基に作成された50～75個のサンプルプロンプトのカタログがあります。これらを数行の文章に凝縮して、プロンプトの例として開始時のガイドとしています。Customizeをクリックしてプロンプトを入力するか、そのままGoをクリックすることもできます。また、左下で作成したいアプリについて入力することもできます。
通常であれば、マイクがあれば参加者からの入力を求めるところですが、今回はFrancoisに代わりを務めてもらいます。完全にライブであることをお見せするために、Francoisにどんなアプリを作りたいか聞いてみましょう。ライブでアプリを作成し、どのようなものができるか見ていきます。そして、アイデアからAWS App Studioで機能するアプリを作成し、プレビューして、テストを開始し、改良を重ねていく、このアイデアから実際のアプリまでの時間を大幅に短縮できることをご覧いただけます。
AIアシスタントによるアプリケーション要件の生成と改良
前回のプレゼンテーションではHR採用ワークフローソリューションを作成しましたので、今回は別のものを作ってみましょう。ITチケットシステム、つまりヘルプデスクのようなアプリを作って、製品で問題が発生したときにユーザーが助けを求められるようにしましょう。私はITヘルプデスクを管理しており、ユーザーが修理依頼を提出し、それらの依頼を確認して承認または却下できるダッシュボードを備えたアプリが必要です。ここで一旦止めて、 Builder Assistantが何を提案してくるか見てみましょう。そして、その結果に基づいて必要な変更を加えることもできます。
私が今Francoisの発言を説明したところです。これから、AIエージェントがそのプロンプトを分析し、AWS App Studioに関する知識を活用します。 また、他のアプリケーションの構築事例に関する知識も活用して、ユースケース、要件、データモデルに落とし込み、お客様が求めているアプリケーションをより正確に表現できるようにします。これは本質的に、新しいプロジェクトを始める際に作成するPRD（Product Requirements Document）やプロジェクトプランにあたるものです。
ヘルプデスクユーザーのユースケースから始めると、 修理依頼を簡単に提出し、承認または却下された際に通知を受け取りたいというものです。ヘルプデスク管理者については、 保留中の修理依頼をすべて表示し、確認、承認、そしてオプションで通知を送信したいというものです。これには修理依頼の提出に関するユーザーフロー、依頼の確認に関するユーザーフロー、 そしてデータソースが含まれます。
興味深いのは、既存のデータに接続していないにもかかわらず、この修理依頼のデータモデルが、修理依頼を保存するための新しいデータベーステーブルを提案してくれており、フィールドとそのタイプまで含まれているということです。また、修理依頼のステータスを表すenumを持つステータスカラムが必要だと指摘している点も面白いですね。比較的シンプルな一文のプロンプトから、これほど詳細な内容が生成されるのは素晴らしい出発点だと思います。
では Francois、気に入らない点や追加したい点はありますか？というのも、左下で変更点を説明すれば、このアウトラインを改良して、実際に望むものにより近づけることができるからです。データモデルを見ていて思ったのですが、依頼を担当する人を追跡するためのデータポイントを1つ追加できますか？RepairRequestに、依頼のオーナーを追跡するための追加フィールドを加えたいと思います。
これを送信すると、このエージェント群が生成された要件を見直し、 その改良プロンプトを組み合わせて修正を試みます。データソースを見ると、ownerフィールドが追加されているのが分かります。これは非常にシンプルな例です。時間があれば、ステータスや承認オブジェクトを修理依頼から分離するように依頼することもできます。なぜなら、2段階の承認プロセスが必要かもしれないからです。修理そのものに関連する承認依頼を表す、まったく新しいデータベーステーブルや新しいデータベースモデルを作成するように依頼することもできます。
Francoisさん、これでよろしければ、アプリの概要を確認することもできます。これはアプリのREADMEのようなものだと考えてください。これにより、ドキュメント作成の手間が大幅に削減されます。これをコピーしてREADMEファイルに貼り付け、チームと共有することができます。このアプリに含まれる主要な機能と使用方法が表示されます。
さて、ここからが本当にすごいところです。「Generate App」をクリックしてみましょう。何が起こるのか、まず説明させていただきます。というのも、とても速いので。私たちのAIアシスタントは、これらの要件をサポートする「メタモデル」と呼ばれるものを作成します。メタモデルは、完全なアプリケーションのためのCDK定義のようなものだと考えてください。このメタモデルは、人間であるあなたが確認できるように自然言語で表現されます。そして、このメタモデルは私たちのVisual Builderに変換され、実際のアプリとして表現されます。Builderに取り込まれると、実際に実行可能なアプリとしてコード生成されます。
では、生成ボタンを押してみましょう。数秒で、これらの要件がVisual Builder内のアプリに変換されるのが分かります。すぐにアプリをプレビューしたり、編集したりすることができます。これはリアルタイムです - デモの速度を上げているわけではありません。もしFrancoisさんと話さなくても、彼が何を望んでいるかが分かっていれば、もっと早くできたはずです。製品内で提供できる機能は、本当に素晴らしいものです。
プレビューボタンを押しました。プレビューでは、そのメタモデルを取り、基本的にアプリをコンパイルし、公開されたかのようにブラウザタブで表示します。ただし、注意点として、完璧というわけではありません。ピクセルパーフェクトで完成され、変更が不要なアプリを生成することが目的ではありません。ニーズに合わせてカスタマイズする必要があることを想定しています。
例えば、ホームページは修理リクエストの送信ページですが、ダッシュボードをホームページにしたい場合もあるでしょう。そのため、細かな調整が必要かもしれません。AIはまだ心を読むことはできませんので、自分で操作や更新を行う必要があります。60秒以内に、送信フォームを備えた完全なクレジットアプリを作成できたのは素晴らしいことです。多くの重要な詳細を取得し、すでにバックエンドのDynamoDBテーブルに接続されており、アプリを公開すると、そのテーブルがあなたのアカウントにプッシュされます。
これらの修理依頼をすべて表示するダッシュボードがあります。このアプリケーションを生成する際、サンプルデータを生成する別のAgentも用意されており、実際のデータを反映したアプリのテストが可能になっています。テストは非常に面倒な作業になりがちで、特にサンプルデータの生成は大変です。DynamoDBにインポートして本番環境にデプロイしてテストを行い、その後データを削除する必要があるため、特に課題が多いのです。このサンプルデータAgentを使用することで、そのプロセスがはるかに簡単になります。これは私たちが最初にリリースしたAgentの1つであり、最も役立つものの1つでもあります。
AWS App StudioのビジュアルビルダーとGenerative AI機能の詳細
ここにリクエストのリストが表示されているのがわかります。 既に処理・承認されているものもあれば、却下されているものもあります。詳細を確認する機能があり、完全な詳細ビューのテーブルが表示されます。ここに戻ってスクロールすると、編集機能もあります。 例えば、これを「承認済み」に変更して、処理時間を今日の11時に設定したいとします。これを送信すると、完全なインタラクティブ性が確認できます。 トップの行が承認済みになり、処理時間が設定され、ブラウザ上で即座にアプリを完全にテストできているのがわかります。まさにWYSIWYGの体験です。
アプリに戻ると、メトリクスカードが正しいデータを表示していないことに気づきました。AIがアプリを正しく接続し忘れた可能性があるので、不一致がないかチェックしてみましょう。ビジュアルビルダーでの変更が、もう一方のタブにリアルタイムで反映されているのがわかります。開発時は通常、 大きな画面に2つのウィンドウを表示しています。一方がビルダー画面で、もう一方が実際のアプリで、行き来しながら作業できます。昔のDreamweaverを使用するような感覚ですが、静的なWebサイトだけでなく、完全なアプリケーションを構築できます。これは、先ほど説明したメタモデルからコード生成された、TypeScriptとSGSを使用したフルスタックアプリケーションです。
ビルダー内には3つの主要なモードがあります。上部を見ると、Pages、Automations、Dataがあります。PagesはすべてのUIページで、アプリケーションのビジュアルな体験を表現します。中央のAutomationsタブは、アプリケーションのビジネスロジックやAPIを表します。ここでデータベースの更新やレコードの作成、メールの送信、API呼び出し、PhotoShelter APIを呼び出してアプリ内に画像を表示するといった処理を行います。Dataタブはデータモデルを表し、すべてのフィールド、データタイプ、データ間の関連性を示し、データクエリを定義できます。
これら3つの異なるモードから、左側にアプリ内のすべてのページを確認できます。例えば、修理依頼の詳細表示はナビゲーションメニューにありません。詳細ページをナビゲーションから直接表示する必要はないため、AIが自動的にナビゲーションバーから除外したのです。このダッシュボードで、メトリクスカードをチェックしようとしていました。 これによりメトリクスカードが追加され、右側には各コンポーネントの設定が表示されています。これは保留中のリクエストを示しており、エンティティ（データベーステーブル）に接続されてクエリが作成されていますが、ステータスが期待通りにマッピングされていないようです。このデータクエリには入力パラメータがあるので、保留中のリクエストについて、AIを少し手助けして保留中、承認済み、却下のステータスを追加しましょう。これも同様に追加されていることを確認します。
そうすると、自動的に再コンパイルされて更新されたバージョンが表示されます。このDashboardを開くと、正しいアイテム数が表示されます。ちょっと皮肉なことに、Statusパラメータの設定を忘れていましたね。このData Queryを開いてみると、これらはすべてAI Assistantによって生成されたものです。AI Assistantは、このMetrics Cardに対して、特定のカード内のステータス数を表示するために、Statusに基づいてフィルタリングされたクエリを生成する必要があることを理解していました。データベーステーブルに対してこのData Queryを作成し、Where句を設定し、Approved、Rejected、Pendingを渡すことで、ここにマッピングされ、Metrics Cardに適切な数が返されるようになりました。
これは本当にAIの素晴らしい機能であり、Visual Builder内でも非常に直感的な体験ができます。これが私たちのアプリで、右側では他のComponentをアプリに追加することができます。データ関連のComponent、Generative AI Component、日付Component、ボタン、テキストなど、アプリに追加したいものは何でも、右側のComponent paletteからドラッグしてアプリに追加できます。例えば、Rowを追加したい場合は、ドラッグ＆ドロップでRowが追加されます。この中に新しいComponentを追加し、レイアウトをデザインし、テーマも設定できます。
HeaderとNavigation Barについて、Dashboardをホームページにしたい場合は、設定をクリックしてホームページに設定するだけです。アプリが再読み込みされ、Dashboardが新しいホームページになり、Metrics Cardも見栄えが良くなり、Componentを追加できるRowができました。次にやりたいことは、このアプリの見た目を自分のカラーパレットに合わせてカスタマイズすることかもしれません。少しエッジの効いた感じにしたければDark Modeを選んでもいいですし、単にヘッダーの色を選ぶこともできます。Amazonのオレンジ色を覚えているなら、ヘッダーの色をそれに設定すると、アプリ内でテーマとスタイリングがすぐに反映されます。Secondary colorを選択すると、NavigationやButtonの色が変更されます。ロゴやバナーを追加することで、自社で作ったアプリのように見せることが本当に簡単にできます。
次に紹介したい、私たちが本当にワクワクしている機能は、Generative AIを使用してアプリを追加・修正できることです。今、View Repair Requestページにいますが、これは特定のリクエストの詳細を確認できる詳細ビューです。サービス技術者として、この特定のリクエストに関連する修理メモをアップロードする機能を追加したいかもしれません。それらの修理メモの要約を生成して、より素早くサマリーレポートを取得し、ステータスを更新し、これらの報告された問題をどのように修正しているかを追跡できるようにしたいと考えるかもしれません。
左下に「Build with AI」があります - これが私たちのAI Assistantです。いくつかの追加プロンプトがあり、それをクリックして実行するか、自分で記述することができます。ボタンの追加、ボタン名の変更、Componentへのアイコン追加といった簡単なことから、この完全な機能の追加のような複雑なことまでできます。そこで、「修理メモのアップローダーを追加してそれらを要約する」と入力してみましょう。S3に保存する修理メモのアップローダーを追加し、それらを要約して主要な問題と結果を簡潔に説明するアウトプットを生成するように指定します。これを送信すると、Getting Startedの体験やCold Startの体験と同様に、プロンプトを分析し、ページを分析し、アプリを分析して、私が説明した変更をアプリにどのように組み込むかを理解し、他の修正や追加作業をせずに機能するようにします。AI Agentがそれをどのように機能させるかを理解し、処理しています - インターネットが少し遅いので、この処理を待ちますが、結果が返ってくるのが分かります。
プランができました。 アプリをすぐに変更するのではなく、確認を取ってから進めます。修理メモのアップロードと要約のための新しいセクションを追加するか、ファイルアップロードコンポーネントを追加するか、要約をトリガーするボタンを追加するか、そして修理メモの要約を表示するためのMarkdownを含めるかを確認します。とても良さそうですね。
確認ボタンを押してみましょう。 行が追加され、ファイルアップローダーと要約ボタンが追加されました。さらに詳しく見てみると、 このボタンがこのAutomationに接続されており、このAutomationにS3ファイルの詳細情報が渡されているのが分かります。 アップロードされたS3ファイル、ファイル名、バケットが渡され、Automation自体には、先ほど説明したビジネスロジックやAPIが含まれています。 生成されたフローでは、S3オブジェクトを取得し、このInvoke LLMステップを通じてAmazon Bedrockを呼び出し、アップロードされたファイルを要約します。
ここで入力項目を確認できます。また、シンプルなユーザープロンプトもあります。 AIがこのユーザープロンプトを生成してくれました。これはとても役立ちましたね。「修理メモを分析する専門家として、簡潔な要約を提供してください」というものです。とても良さそうです。Invoke LLMでは、リクエストに使用できる様々なモデルがあります。Temperature、Max P、モック出力の設定が可能で、ClaudeモデルかTitanモデルかも選択できます。Novaモデルもまもなく利用可能になります。
公開されたアプリでどのように見えるか確認してみましょう。これは昨夜作成したサイドアプリで、エンドツーエンドで実際に要約を実行できるものを用意しました。これは完全にデプロイされています。リクエストと保留中のリクエストが表示されています。これはFrancoisのアプリとは少し異なりますが、似ています。ファイルを選択して修理メモを選び、これをS3にアップロードします。AIアシスタントが追加したのと同じコンポーネントを使って、これを要約してみましょう。
ここに簡潔な要約が表示されています。この要約をコピー＆ペーストできます。これは修理メモの文書全体を分析したものです。 この要約を記録に保存したり、別のシステムを更新したり、あるいはワンクリックで自動的に行を更新したりすることができます。他のコンソールに行ったり、自分でプロンプトを書いたり、配線作業をしたりする必要はありませんでした。素晴らしいですね。
AWS App Studioの今後の展開とセッションのまとめ
PowerPointに戻って、手短にまとめたいと思います。 残り2分ほどですので、このロードマップを駆け足で見ていきましょう。 これまでに触れた主なポイントをご紹介します。公開済みアプリでのGenerative AIをお見せしました。これが先ほどのデモでした。また、アプリの修正のためのスタイリングとGenerative AIもデモンストレーションしました。エンタープライズ向けのリレーショナルデータモデリングが間もなく登場します。さらに、デプロイ時間の短縮、コネクタの設定、共有コントロール、組織全体のエラーモニタリングも提供予定です。より多くのネイティブな統合SaaSおよびサードパーティのアクションコネクタもローンチする予定です。現在はSalesforceとAPIがありますが、さらに多くのネイティブコネクタを導入して、これらのエンドポイントへの接続をより簡単にしていきます。
本日はご参加いただき、ありがとうございました。また、お客様にも大変感謝しています。これらのお客様は、プライベートベータからプレビュー、そしてGAまで私たちと共に歩んできました。製品の形成に大きく貢献していただきました。素晴らしい旅でした。NFL、Deloitte、Adobeは素晴らしいパートナーとして、他の何百もの企業とともに、私たちをここまで導いてくれました。
こちらにいくつかQRコードを表示しています。画面に表示したままにしておきます。1つは入門チュートリアル用で、もう1つはステップバイステップのアプリ構築ガイド用です。本日午後にはディープダイブセッションを予定しています。これはチョークトークで、より詳しいJavaScript拡張ポイントとAWS App Studio内のLambda統合について深く掘り下げます。これにより、既存のプロ開発者が作成したLambdaに接続したり、組織内の開発者に依頼して、標準機能として提供していない機能をカスタマイズしたりすることができます。
セッションは2時30分からです。ここでは質疑応答はできませんが、Francois、私、そしてShawnが会場後方にいます。ご質問がある方は、会場を出てヘッドフォンを置いていただき、スタジアム後方で質問にお答えいたします。ご参加いただき、ありがとうございました。素晴らしいre:Inventをお過ごしください。本日はお越しいただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion