生成系AI×AWSサービスの最前線!AWSソリューションアーキテクトが実践するスキル習得とは──AWS Tech talk Night#6
アーカイブ動画
生成系AIはいまやさまざまなシーンで活用されている
最初に登壇した石橋香代子氏は、「生成系AIアプリケーションへの挑戦を全方位で支援するAmazon Web Services」というテーマでセッションを行った。
アマゾンウェブサービスジャパン合同会社
技術統括本部 消費財リテールソリューション部 部長
シニアソリューションアーキテクト 石橋 香代子氏
石橋氏は外資SIerでITエンジニアやプロジェクトマネージャを経験した後、2018年7月にAWSにジョイン。AWSにはTFC(Technical Field Community) の技術や業界に特化したコミュニティがあり、石橋氏はCloud OperationsというTFCに所属している。2023年のAWS Summitでは、システム運用をテーマにしたセッションに登壇した。
本セッションのテーマ、生成系AIとは何か。「いろいろ定義はあるが」と前置きした上で石橋氏は、「会話、ストーリー、画像、動画、音楽などの新しいコンテンツやアイデアを生み出すことができるAI」と説明する。
技術的には基盤モデルと呼ばれる膨大なデータに基づいて、事前にトレーニングされた大規模モデルを利用する。今生成系AIと共に注目を集めているLLM(大規模言語モデル)はこの基盤モデルの一種である。
生成系AIの利用は、顧客体験や社員の生産性の向上、事業運営改善、創造性など、様々なシーンで利用されている。
これらの中でも石橋氏たちがよく相談されるユースケースが紹介された。それが「社内のマニュアルやルールを簡単に探して要約したい」というもの。そこで石橋氏たちが提案したのが、社内の情報収集を生成系AIで効率化するという方法である。
あらかじめ関心事を登録して、従業員が関心事に関する情報の要約の生成を生成系AIアプリにリクエストする。すると、アプリが社内の文書を検索して、そのアウトプットをLLMで要約した結果を出力するという仕組みである。
直接生成系AIに聞けばいいのではと思う人もいるかもしれないが、生成系AIアプリで、まず関心事について検索させるのには理由があると、石橋氏は言う。それがRAG(検索拡張生成)というアプローチである。生成系AIは膨大なデータに基づいて事前にトレーニングされているとはいえ、欠点がある。
「それがハルシネーションです。ハルシネーションとは事実ではない回答を出力すること。生成系AIだけでは、このハルシネーションを制御することは困難です。そこで利用するのがRAGです。RAGでは、検索結果に基づく回答を生成させることで、ハルシネーションを抑えることができます」(石橋氏)
このようなエンタープライズサーチを作るのは難しいと、思う人もいるだろう。それを容易にするのが「Amazon Kendra」だ。機械学習を利用した高精度な文書検索のためのサービスである。
Amazon Kendraはコネクタを利用することで、Amazon S3やAmazon RDSはもちろん、SharePointやBoxなどさまざまなデータソースに接続可能。しかも学習なしで各業務の文書に対応できる。
つまり、Amazon KendraとLLMの機能を組み合わせて、RAGワークフローを容易に実装できる。組織内のコンテンツに基づく会話型のユーザ体験を提供する最先端の生成系AIアプリケーションが作成できるのだ。
「エンタープライズサーチに困っている方はチャレンジしていただきたいです」(石橋氏)
続いて石橋氏は、生成系AIを支える基盤モデルについても紹介。基盤モデルは、膨大な量の事前学習をしていること、多数のパラメータを有していること、そしてデフォルトで幅広い状況への適用が可能になっていることという特徴を持つ。
だが、業務適用するには、独自のデータを使用してカスタマイズするファインチューニングが重要になる。ファインチューニングすることで、さらに価値を上げることができるのだ。
基盤モデルと一口に言っても、様々なものが存在する。最も生成系AIで使われているのが、簡単な自然言語プロンプトからサマリを生成するなど、アプリケーションのためにテキストを生成する「Text-to-text」というモデル。また「Text-to-embeddings」は、検索や文書間の類似点検索の用途向けに、テキストの数値表現を生成するというモデルもある。
「例えばコーヒーというインプットがあったらそれを数値表現にし、コーヒーフィルターやコーヒー豆など似通った文章を見つけたり、どの程度似通っているかを定量的に計算するときに使います」(石橋氏)
もう一つは「Multimodal」という複合的な情報を扱うモデル。自然言語プロンプトから画像生成・編集を行う。「こういう絵を描きなさい」と入力すると、それに沿った絵が出されるというものである。
「今はText-to-textに注目が集まっていますが、基盤モデルがあるので、適材適所に使っていくことが大事になると思います」(石橋氏)
生成系AIアプリケーション開発のチャレンジをサポートするAWS
生成系AIアプリケーション開発には、次のようなチャレンジが必要となる。第一に複数の基盤モデルや新しいバージョンへのアクセス、第二に基盤モデルのカスタマイズは複雑なことである。
第三にデータのプライバシーとセキュリティの維持、第四が基盤モデルにタスクを実行させること、第五にデータソースへの接続、第六がインスフラストラクチャーの管理は困難な場合があることだ。
これらのチャレンジを支援するAWSのソリューションとして、まず、石橋氏が紹介したのが、Amazon Bedrockである。これは最も簡単に生成系AIアプリケーションを構築、拡張できるソリューション。
「9月末に一般提供を開始し、10月初頭から東京リージョンでも使えるようになりました」(石橋氏)
Bedrockの最大の特徴は、単一のAPIで様々な主要な基盤モデルにアクセスできることである。
そのほかにもファインチューニングが可能であり、データセキュリティとコンプライアンスを実現している。ここで石橋氏は、開発した靴を販売することを例に、説明を行った。販売するためにはまず、必要になるのが商品説明だ。
それを実現するために、「Anthropic Claude」に「次の素材を使用して東京を歩き回るのに適した靴の商品説明を書いてください」とお願いをすると商品説明を作ってもらえる。
次に魅力的な写真が必要になる。スタジオで撮影した靴の写真に、スタイリッシュな背景をつける場合には、「Stability AI Stable Diffusion」が活用できる。商品の告知ツイートを作成するときには、「AI21 Labs Jurassic-2」を使う。
最後に必要になるのが検索に引っかかるようにすること。検索用語のリストを作り見つけやすくするには、「Amazon Titan Text」を使う。
「このような形で、一つのユースケースでもそれぞれ得意とする生成系AIを使っていくことをお勧めします」(石橋氏)
さらに「Agents for Amazon Bedrock」は、顧客のデータと基盤モデルを連携させ、タスクを複数のステップに分解して、アクションを実行する。
このソリューションを活用する例として、例えば、「青いジャケットありますか」と顧客からの問い合わせに回答するだけではなく、裏で注文の更新や交換の管理などのタスクにも活用できるという。
「実際にビジネスアプリケーションに組み込む場合には、このようなソリューションを活用することが開発の加速につながります。現在はプレビューの提供ですが、一般提供開始になるのを楽しみにしていてください」(石橋氏)
基盤モデルのファインチューニングには、顧客独自のデータが欠かせない。だが不安になるのが、セキュリティの問題である。
「Amazon Bedrockなら顧客データは暗号化され、転送、保存され、仮想プライベートクラウドを離れることはありません。プライベートかつセキュアをお約束します」(石橋氏)
GDPR(EU一般データ保護規則)やHIPAA(医療保険の相互運用性と説明責任に関する法律)にも準拠しているため、安心安全に使えるサービスとなっている。
生成系AIにAWSで取り組むメリットは柔軟性、ファインチューニングが可能なこと、基盤モデルによる生成系AI開発の容易性、生成系AIがビルトインされたソリューションなどあるが、忘れてはいけないのがコスト効率の高さである。
一般的に大規模モデルであればあるほど、コストは高くなっていく傾向があるが、一般的に大規模モデルであればあるほど、コストは高くなっていく傾向があるので、ビジネス上必要なレベルのモデルを正しく選ぶことも重要だ。AWSは複数のモデルを用意しており、ユーザーは複数の選択肢から選択できる。「ぜひ、AWSを活用して生成系AIのチャレンジを始めてほしい」こう語り、石橋氏はセッションを締めた。
AWSのSolutions Architectのリアルがわかるパネルディスカッション
続いて、「AWSのSolutions Architect(ソリューションアーキテクト:SA)のリアル」をテーマでパネルディスカッションが行われた。石橋氏がファシリテーターを務め、技術統括本部の塚本真理氏、北川友稀氏、宮崎友貴氏の3名がパネラーとして登壇した。
アマゾンウェブサービスジャパン合同会社
技術統括本部 ソリューションアーキテクト 塚本 真理氏
アマゾンウェブサービスジャパン合同会社
技術統括本部 ソリューションアーキテクト 北川 友稀氏
アマゾンウェブサービスジャパン合同会社
技術統括本部 ソリューションアーキテクト 宮崎 友貴氏
SAはAWSのロールの1つで、ミッションは大きく3つある。
- Trusted Partner:顧客やパートナー、社内で関わるメンバーなどから技術面で信頼される存在であること
- Technical Thought Leadership:社内外に先進的なテクノロジのメッセージを発信する
- Platform Improvement:AWSサービスの進化・新たな活用方法の開拓に貢献する
SAは200以上あるAWSの技術の代表として、顧客のビジネス変革やIT変革をリードする存在である。SAには複数のポジションがあるが、今回のパネルディスカッションに登壇した3人のSAは案件対応のアカウントSA、つまりカスタマーと直接相対するSAだ。
──まずは、自己紹介からお願いします。
塚本:ERPやグループウェア製品の開発会社で経験を積んだ後、2022年9月にAWSに入社。入社時はAWSスキルの基礎的な知識はありました。現在はSAとして、自社開発を行っているISVやSaaSを担当しています。
宮崎:通信事業会社で技術営業、法人営業、クラウドの保守運用、故障対応業務を自動化するシステム開発兼PMを経験してきました。2022年8月、AWSに入社。入社時はAWSという名前を知っているくらいでした。現在は、通信業界の企業支援を担当しています。
北川:金融系SIerでアプリケーションエンジニアを経験した後、HRTech会社に転職。2022年9月、AWSに入社しました。入社時のAWSスキルはサーバーレス、セキュリティ、ガバナンスなど。23年3月末から6月末まで育休を取得していました。
──AWSに入社した理由は何ですか?
宮崎:大きく2つあります。一つはSAという仕事をやりたかったこと。クラウド最前線のAWSに興味を持っており、お客様に提案する仕事がしたいと思いました。もう一つはAWSなら自分が提案するときに自信を持って提案できるサービスなので、やりたい提案ができるのではと思ったことです。
前職は8年ぐらい経験したので、キャリアを手放す不安もありましたが、やりたいことをやろうと思って転職を決めました。お客様の課題解決ができており、お客様のビジネスに貢献できていると感じる瞬間がやりがいです。
塚本:前職では自社開発でAWSを使っていましたが、使い方が決まっていました。使いこなすにはどうすればいいのかを考えるようになり、さらにはAWSの提供側に立って、悩んでいるお客様を支援したいと思い、転職を決めました。
北川:転職を決めた理由は、自分を成長させられる、チャレンジングな仕事だと思ったからです。SAの仕事はお客様と接するので、コミュニケーションスキルが求められます。
営業組織に属するロールなので、売上やお客様のビジネス成長を常に意識することが必要です。経験が浅くても、一人のAWSの人として相対することが求められます。それに応えられることは難しいのですが、やりがいは大きいですね。
──前職での経験はAWSで役に立っていますか?
宮崎:役立っている面もあります。自社で持っていたクラウドサービスのインフラを保守運用していた経験があるので、ハードウェア運用の大変さもわかりますし、ソフトウェアの開発もやっていたので、開発者の視点もわかります。
また外部向けの登壇イベントによく出ていたことも、SAとして登壇する際に役立っています。ただ、レイヤーが高いところの知識が少ないので、もっと勉強しておけばよかったと思うこともあります。
塚本:ISV系の企業にいたので、運用や設計面でのお客様の悩みが理解できることが、役立っていると感じています。
また前職では、Web3層構造の技術スタックとしてJavaやOracleなどを使っていました。そうした技術スタックも役立っています。ただ、IoT系はなかなか関わりがなかったので、勉強しながら支援する難しさを感じています。
北川:非常に役に立っていると思っています。元々SIerでアプリケーション開発をしていた経験から、お客様の課題をより深く理解し、寄り添うことができます。またHR Techで働いている時に取り組んでいたマルチアカウント管理の課題は、多くのお客様が抱いているのと同じような課題でした。このような実際に開発・運用していた人の観点を持っているのは、大事だと思っています。
──SA業務での苦労・大変なことはありますか?
宮崎:お客様対応の経験がないまま、AWSのサービス知識を身につけるのは大変でした。ただ、研修期間中にロールプレイを通じて、スキルを身につけることができます。そのときに先輩SAから学んだマインドは活きていると思います。
よく言われたのは、「なぜを繰り返す」こと。何を懸念しているのか、どういったことをやりたいのか、もっと自分自身で考えなさいと言われました。お客様がこれをやりたいと言っても、よく話を聞くことで、深くお客様を理解することができるからです。
北川:私も同じことを言われました。そこがSAの大変なところですね。
──ワークライフバランスは実現できていますか?
北川:ワークライフバランスは取れています。育休は入社して半年後に3カ月取得しました。SAは一人で複数のお客様を担当します。引き継ぎするSAには出産予定日よりも1週間早く出産になりましたが、快く引き継いでもらいました。
また育休から復帰後も、娘はまだ3カ月で朝6~7時に起きてくるので、9時~10時に自宅で業務開始しています。育児で中抜けするときは、娘が寝た後などに仕事をしています。
出社するときも早めに帰宅しています。フレックスやハイブリッド型勤務ならではの働き方なので、入社して良かったと思っています。もちろん、妻やチームメンバーの協力がある前提なので、大変感謝しています。
塚本:保育園の登園時間に間に合うかを心配していました。実際にはテレワークがベースなのでその心配は杞憂でした。予定の調整についても周りのサポートもあります。第2子を考えると不安がありましたが、いろんなサポート体制が整っているので安心しています。
石橋:二人の子どもがいますが、イベントごとなどがあるときもちゃんと考慮してくれます。お互いに理解しながら仕事ができる文化があることが、AWSの良いところだと思います。
──新しい技術をどのようにキャッチアップしていますか?
宮崎:研修期間中に、社内外向けの学習教材がたくさんあることを知りました。研修でAWSの知識がゼロでもキャッチアップできますし、資格を取ることができました。SA同士で情報をシェアする文化もありますし、社内にある様々な学習教材を使ってキャッチアップをしています。
北川:AWSのサービスは、アップデートが日々行われているので、キャッチアップが難しいところもあります。ですが、SAが発行している週刊AWSやクラスメソッド社のDevelopersIOを見て、実際に触ったりしながらキャッチアップしています。
その際に実際の運用時にどう対処すればよいのか疑問に思った点をメモして、公式ドキュメントを参照して疑問を解消します。社内のスペシャリストが頻繁に勉強会を開催しているので、お客様と一緒に参加して勉強しています。
北川:AWSのHands-on for Beginnersもいいですね。公式ドキュメントにもチュートリアルが載っているので、興味があるサービスを触ってみることをお勧めします。
石橋:動画になっていてわかりやすいので、私もお勧めです。課金が気になるという方もいらっしゃると思いますが、無料利用枠もあるので、ぜひ触ってみてください。
Q&A(イベント中に寄せられた質問への回答)
Q.Bedrockで、自分でチューニングしたモデルを展開することはできますか?それとも、チューニング前のモデルのみを利用する方式でしょうか?
Bedrockには、ファインチューニングの機能がございます(11/16時点では東京リージョンは未対応です)。ラベル付きの独自のトレーニングデータセットを提供して Bedrock モデルを微調整することが可能です。
詳細は、以下の開発者ドキュメントをご参照ください。
Amazon Bedrock ユーザーガイド
Q.SageMaker と BedRock の使い分けを知りたいです。
Amazon SageMaker は独自のモデルをホストすることができるので、お客様にて学習済みのモデルをご利用になりたい場合に使っていただくことができます。他にも、Amazon SageMaker のほうが利用可能な基盤モデルの選択肢が300種類以上とAmazon Bedrockに比べて多いことと、基盤モデルを動かすインスタンスを柔軟に選んでいただけることが特徴です。
一方で、Amazon Bedrockは、利用可能な基盤モデルの種類が少ないですが、Amazon Bedrock APIで簡単に呼び出して使うことができます。また、フルマネージドなサービスのためインフラの管理が不要なのが特徴です。
また、料金体系も異なり、Amazon SageMaker は、インスタンスの稼働時間による課金に対してAmazon Bedrockは モデルに入力されるトークンの長さによって課金されます。そのため、大きなトークンの入出力を頻繁に行うようなユースケースではAmazon SageMaker を使っていただくほうがコスト面で良い場合もございます。
Q.個人開発など、個人レベルでAmazon Bedrockを試して活用できるでしょうか?
はい、可能です。AWSアカウント作成いただく必要がございますが、個人のお客様でもAWSコンソール画面上およびAPIでの呼び出しによってご利用可能です。
Q.Claude, Command, Jurassic, Titan等のモデルの使い分けについて知りたいです。
それぞれのモデルプロバイダーとモデルの特徴は、以下のようになります。
* Anthropic:Amazon が多額の投資をしており、安全かつ制御可能なAIの開発を目指す
* Claude v2 :誠実で責任感のあるAIシステムのトレーニングに関する研究に基づく、会話、質問応答、ワークフロー自動化のためのLLM。日本語対応。
* Cohere:“The enterprise LLM” を掲げ、顧客自身のネットワーク/環境へのデプロイ、 そこでのカスタマイズ、さらにサポートを提供する
* Command:ビジネスアプリケーション用のテキスト生成モデルと、検索、クラスタリング、 分類用の埋め込みモデル
* AI21 Labs: 文書の校正を支援する Wordtune などを開発する企業。 AI に より人が読み書きする方法の変革を目指す
* Jurassic-2 Ultra:スペイン語、フランス語、ドイツ語、ポルトガル語、イタリア語、オランダ語でのテキスト生成用の多言語LLM
* Amazon: オンラインで求めるあらゆるものをいつでも検索・発見できるこ と、地球上で最もお客様を大切にする企業になることを目指す
* Amazon Titan: テキストの要約、生成、分類、自由形式の Q&A、情報抽出、埋め込み、検索などさまざまなユースケースをサポートするように構築された汎用LLM
上記はAmazon Bedrock で提供しているモデルの一部です。
詳細は、以下の「Amazon Bedrockのはじめ方」やAmazon Bedrock 公式ページにございますのでそちらをご参照ください。
Amazon Bedrockのはじめ方
Amazon Bedrock 公式ページ
Q.データレイク、ETL(ELT)、DWH、データマート、BIとAWSソリューションの位置づけを改めて確認したいです。 また、データ周りのソリューションと生成AIソリューションの位置づけも教えてください。
AWSサービスは、製品カテゴリで大別されております。今回ご紹介しました生成系AIソリューションは「機械学習」カテゴリに含まれます。
また、データレイク、ETL、DWH、データマート、BI などのAWSサービスは、ほとんどが「分析」に分類されます。他には、DWHサービスであるAmazon Redshift は「データベース」にも分類され、データレイクとして使用されることもあるAmazon S3は「ストレージ」に分類されています。
詳しくは、以下のページで製品カテゴリ別の製品一覧をご確認いただくことが可能ですので、そちらをご参照ください。
AWS クラウド製品
Q.AWSでは 業務外での OSS への貢献、競技プログラミングへの参加、個人サービス/アプリの開発運用は許されているのでしょうか。また、可能な場合は、どのくらいの割合の人が実際に活動されているのでしょうか?加えて、個人での(業務内容が含まれない内容での)論文執筆・学会発表は許可されていますか?
AWS のお客様はいわゆる企業やパートナー様、公共機関などにとどまりません。様々なコミュニティや個人のお客様など、クラウドコンピューティングの恩恵を幅広くお届けしたいと考えていますので、 社内申請を行い、社内ポリシー に準拠していれば可能となっており、OSS 活動やコミュニティでの活動は SA の **OSS 活動やコミュニティでの活動は ソリューションアーキテクトの活動の中で推奨されています。**
Q.日頃の開発業務で困った際、支援いただく方法はありますでしょうか。
AWSサポートをご利用いただくことで技術サポートを受けることができます。AWSサポートのビジネスレベル、エンタープライズ On-Ramp レベル、およびエンタープライズレベルのお客様は、チャットや電話を使ってリアルタイムのサポートを受けることができ、デベロッパーレベルのお客様はメールでのやりとりによるサポートを受けることができます。 詳細は、以下のAWSサポートページをご確認ください。
https://aws.amazon.com/jp/premiumsupport/?nc=sn&loc=0
【参考】AWSの知識習得に役立つサイト
● AWSサービス別資料
● 週刊AWS
● クラスメソッド DevelopersIO
● AWS ハンズオン資料