※本記事は、AWS re:Invent 2024で開催されたセッション「Generative AI unleashed: An insider's perspective on Amazon's approach (PEX202)」の内容を基に作成されています。このセッションでは、AWSのシニアプリンシパルソリューションアーキテクトTod GoldingとGenerative AI Competency Partners ProgramのテックリーダーであるVictor Rojoが、Amazonが生成AIをどのように活用してイノベーションを継続し、パートナーや顧客に価値をもたらすソリューションを開発しているかについての内部視点を提供しています。本記事では、セッションの内容を要約・構造化しておりますが、完全な情報や文脈については、オリジナルの講演をご視聴いただくことをお勧めいたします。セッションの詳細や他のAWSイベントについては、AWS re:Invent（https://go.aws/reinvent ）およびAWSイベントページ（https://go.aws/3kss9CP ）をご参照ください。
1. イントロダクション
1.1. 講演者紹介: Tod Golding (AWS シニアプリンシパルソリューションアーキテクト)
Tod Goldingは、AWSのシニアプリンシパルソリューションアーキテクトとして活躍しています。彼はAWSに11年間在籍しており、その間クラウドインフラストラクチャ、クラウドアプリケーション、特にSaaS（Software as a Service）の分野で豊富な経験を積んできました。Todは多様な顧客事例やドメインに触れる機会があり、様々な業界での導入事例や課題解決に携わってきました。このセッションでは、生成AIの組織内での活用について、Amazon/AWS内部での取り組みや経験を基に知見を共有します。
1.2. 講演者紹介: Victor Rojo (Generative AI Competency Partners Program テックリーダー)
Victor Rojoは、Generative AI Competency Partners Programのテックリーダーを務めています。彼は自身の役割について「少し複雑な名称かもしれませんが、基本的にはパートナー企業がAWSとその顧客から差別化され、可視化されるようにするプログラム」と説明しています。AWSで約4〜5年間、そしてその前にAmazon Alexaで2年間勤務しています。彼の専門分野は、パートナー企業がAWSの生成AI技術を活用して独自の価値を提供できるよう支援することです。複数のパートナー企業との協働経験から、業界固有のユースケースや実装パターンについての知見を持っています。彼はこのセッションの中で、特にデータの活用と責任あるAIの実装について詳細な説明を担当しています。
1.3. セッションの目的と概要
このセッションでは、Amazonが生成AIをどのように活用して継続的なイノベーションを進め、パートナーや顧客に価値をもたらすソリューションを開発しているかについての内部視点を提供することを目的としています。大規模な生成AIシステムを構築する際の課題やベストプラクティスに関する重要な教訓を共有し、データ品質、モデルトレーニング、セキュリティ、ユーザーインタラクションデザインに関する洞察を提供します。
特に注目すべき点は、組織がどこに生成AIを適用すべきか、という広範な問いに対するアプローチです。多くの組織が生成AIをビジネスに活用したいと考えていますが、具体的にどこに注力すべきか明確でない状況にあります。Tod Goldingが説明するように「魔法の弾丸はない」ものの、組織内での生成AI活用に関する構造やフレームワークを提供し、AWSやAmazonが実践している戦略や事例を共有することで、参加者が自組織での応用を考える手助けになることを目指しています。
セッションでは、生成AIの適用領域を整理し、データ駆動の意思決定方法、Amazonの実例、生産性向上策、データ統合アプローチ、そして運用化における責任あるAI導入の方法まで広範に解説し、組織全体でイノベーションを促進する文化をどう醸成するかについても提案しています。明確な青写真が存在しない現状で、どのように前進すべきかの指針を示すことが本セッションの主な狙いです。
2. 生成AI導入の課題と機会
2.1. 組織内での生成AI活用の広範な可能性
Tod: 生成AIが多くの組織のドアをノックしている現在、企業は自分たちの組織にどのように生成AIを適用できるかという広範な質問に直面しています。これは非常に幅広い問いかけです。彼らは単に既存の製品に生成AIを活用して売上を向上させる方法だけを探しているわけではありません。「どのように社内で新しいメカニズムを採用するか？」「どのように新しい戦略を作るか？」「どのように生成AIのパワーをビジネスに取り入れて、効率性を高め、生産性を向上させ、より効率的な組織を実現するための新しいツールや仕組みの創出をどう刺激するか？」といった問いを自分たち自身に投げかけています。
表面上は、これは素晴らしいアイデアであり、追求する価値のある目標に思えますが、それと同時に非常に広範で未定義の領域でもあります。私たちがこうした組織と話をすると、彼らは機会を追求することに関心を持っていても、どこに注力すべきかまだ確信が持てていないことがわかります。彼らは多くの可能性を見ていますが、その可能性を適切なものに変える方法がわからないか、あるいは可能性があまりにも多すぎて、組織内のどこが適切な場所なのか選択できないでいるのです。
私は、これに対処するための青写真や方法論があると言いたいところですが、実際にはこれはまだ非常に広範で進化し続けている領域です。同時に、人々が行っているパターンや、Amazon・AWS内で生成AIのパワーを活用してビジネスを推進する新しいツールや仕組みを作るために使っている戦略も見えてきています。本日のVictorと私の希望は、少なくとも追加の構造をもたらし、組織内で生成AIをどのように、どこに適用するかを検討するためのフレームワークを提供することです。
2.2. 導入における不確実性と方向性の課題
Tod: 組織が生成AIの領域に踏み込み、どこでどのように生成AIを適用するかを考え始める際の課題の一部は、自社のビジネスのあらゆる領域にわたって多くの疑問が生じることです。組織は「この運用モデルはどうなるのか？」「どのように運用化するのか？」「責任あるAIについてどのように考えるべきか？」「私たちが構築しているツールや仕組みに、どのようなデータが参加できるのか？」といった問いを自問しています。これらの運用化、セキュリティ確保、適切な体験の創出の意味合いについてだけでも、AWSでは大きな議論になっています。
人々は、「これがビジネスのコストにどのように影響するのか？」「生成AIのメカニズムを追求すれば、会社の収益にプラスになるのか、それとも多大な出費をもたらすのか？」と自問自答しています。真実は、質問の幅が非常に広いということであり、この導入アプローチは組織にとって非常に総合的な経験になるためです。
Victor: 導入の課題として、業界固有のユースケースも考慮する必要があります。ご覧のように、様々な業界で適用できるユースケースもありますが、ヘルスケア、通信、エネルギーなど、あなたの属する業界や実際に顧客と協業している業界に特化したユースケースについても考えることが重要です。
Tod: ここでの問題は、数人のタイガーチームを立ち上げて「生成AIをいろいろ試して、どこでどのように使うべきか考えてください」と頼むことではありません。実際には、組織の文化に生成AIの可能性を吹き込み、促進するものなのです。組織内の人々に、自分たちの環境に生成AIをもたらす機会はどこにあるのかを自問するよう促したいのです。彼らに新しい戦略、新しいアプローチ、新しいメカニズムや新しいツールをもたらし、効率性を高めるための革新を促すにはどうすればよいでしょうか？
2.3. 青写真の不在とパターン認識の重要性
Tod: 私としては、この問題の人的側面、組織的側面、そして純粋にビジネスの観点からも考える必要があると感じています。私の考えでは、イノベーションを促進しつつ、組織にとって最大のビジネスインパクトをもたらす領域に確実に焦点を当てるためのガードレールを設定できるかどうかが重要です。多くの人々を様々な方向に振り向けさせ、多くの異なるプロジェクトを立ち上げても、それらのどれも実際に展開されず、組織全体に普遍的に適用されないというリスクがあるからです。その場合、多くの時間を費やしたにもかかわらず、投じた労力とエネルギーに対するリターンがあまり得られない結果になってしまいます。
青写真や方法論は存在せず、依然として非常に広範で進化し続けている領域ですが、パターンは確かに存在します。人々が行っていることや、AmazonとAWSが生成AIのパワーを活用してビジネスを促進する新しいツールや仕組みを作るために使用している戦略が見えてきています。少なくとも、組織内で生成AIをどのように、どこに適用するかを検討するための追加の構造とフレームワークを提供することが、本日の私とVictorの希望です。
また、AWSとAmazonで何をしているのか、どのような可能性の風景があるのかを見て、その上で戻って自分たちの組織にどのように適合するか考えることができれば、少なくとも皆さんがここから持ち帰れるものがあると思います。魔法の弾丸はありませんが、少なくとも十分なガードレールと洞察を提供することで、組織内でのこれらのアイデアの採用を刺激することができるはずです。
パターン認識の面では、AWSの我々は常に投資する場所や時間を費やすものを選択する際に、非常にデータ駆動型のアプローチを取ってきました。私たちが取り組んでいることが実際にビジネスに与える影響と相関関係があるかどうかを問い、そのビジネスへの影響を定量化する方法を考え、時間をどこに使うかについて良い決断を下すために、それをどのように活用できるかを懸命に考えています。この領域では、アイデアと機会と追求すべき場所が不足することはないでしょう。
3. 生成AIの主要な活用領域
3.1. カスタマーエクスペリエンス向上 (チャットボット、バーチャルアシスタント)
Tod: 一般的な領域を考えると、可能性のスペクトルとして少なくとも主要なカテゴリを表していると思われるものがいくつかあります。左から右に見ていくと、まずカスタマーエクスペリエンスがあります。生成AIが市場に登場した時、私たちが組織として最も理解していたのはチャットボットだったため、あらゆる問題に適用できるチャットボットやバーチャルアシスタントを目にしました。
しかし実際には、これらのチャットボットやバーチャルアシスタントは、基本的な機能を超えて、社内外の両方でビジネスのより良い成果をもたらす方法で適用できます。外部のものは、私たち自身がおそらくそのようなボットと対話しているため最もよく知られています。より良い顧客体験をどのように作るか？サポートの面で人々をどう助けるか？などの観点からです。
しかし、その議論から時々抜け落ちるのは、内部チャットボット、バーチャルアシスタント、組織内のプロセスやメカニズムを取り込み、チャットボットにビジネス問題のコンテキストをもたらし、組織の効率性を高め、従業員が回答を得るスピードを上げ、必要な文脈情報により迅速につながるようにする仕組みを作れないかということです。
例えば、IT部門がチャットボットを持ち、「これが一般的な問題です」と言えるとしたらどうでしょう。それは歴史的な問題だけでなく、新たに発生している問題も含めて、すべての問題を理解しています。誰かが電話をかけ返すのを待つのではなく、より迅速に回答を得ることができるとしたらどうでしょう？HR部門や他の部署でも同様です。この体験にチャットボットをもたらす方法はあり、これは多くの人々が始めたことであり、この領域を加速させるために導入されたツールもたくさんあります。
これらのチャットボットを活用する体験はまさに、多くの組織が始めた部分であり、AWSもこの領域を加速するための多くのツールを導入しています。内部向けにも外部向けにも、より文脈に沿った、より豊かな対話体験を提供し、ビジネスの成果を向上させるための大きな可能性を秘めています。
3.2. 従業員の生産性向上
Tod: 中央のカテゴリである従業員の生産性は、実際に最も多くの労力とエネルギーが注がれている領域だと感じています。私たちの企業には、プロセスやメカニズムの一部となっているデータが会社中に散在しています。今日使用しているプロセスやメカニズムは、生成AIがどのようにそれらを豊かな体験にできるかを考える絶好の候補であることが多いのです。
もっと重要なのは、より効率的なプロセスにできるかどうかです。今日、非常に長い時間を要し、組織中からデータを収集し、多くのオーバーヘッドが伴うものを取り上げて、そのオーバーヘッドを大幅に削減できるでしょうか？これは実際に、AWSの内部事例でも見られる部分です。
もし私が組織に戻って、「これらの機会をどこでどのように追求すべきか」と問われたら、内部データの消費者がいて、文脈を多く含む企業データが環境内のさまざまなシステムに広がっていますが、それらは非常に分断され分離されています。そこで、ビジネスプロセスをどのように豊かにし、今日存在する課題や摩擦をどのように克服できるかを考えるとき、「この問題を解決するにはどのデータが必要か？」と自問し、その空間に生産性ツールが座り、そのデータを中心に体験を構築し、新しいものを創造したり、既存のものをより良くする機会はどこにあるかを考えます。
実際、社内で最も大きな影響を与える場所を探すときに焦点を当てるべき領域は、おそらく生産性なのです。私たちが見ているのは、生成AIとチームが基本的にこれらのデータビューを組み立て、プロセスに接続し、その後、従業員のレビュー、自動化されたサポート、文書のレビューなど、創造的な方法でさまざまなことに取り組んでいることです。
例えば、AWSではセールス効率化ツールがあります。以前は、特定の企業についての明確なカプセルビューを他の人に提供するために、これらのアカウントサマリーを人々が組み立てていました。これらを集めてまとめる労力とエネルギーは大きなものでした。このツールは、アカウントとの作業のコンテキストにおいて非常に重要でした。私たちはこれが生産性向上のために取り組むべき重要な場所だと判断しました。部分的には、私たちがこのような作業を大量に行っているからです。これは確かに基準の一つです。私たちはこれを繰り返し何度も行っています。そして、これを行うオーバーヘッドは高いのです。
この例では、平均で35分の時間節約が実現され、125,000件のサマリーにわたって適用されています。全体として、これを行った結果はビジネスにかなりプラスの効果をもたらしました。これは、そのボックスに収まる可能性のある生産性ツールの一例に過ぎず、今や組織内の人々がこれらの機会がどこに存在し、どこで追求できるかを把握することが仕事になっています。
3.3. コード生成と開発者支援
Tod: 生産性の領域に含まれるものとして、コード生成も挙げられます。実はこの生産性の枠組みの中で、クラシックな生産性ツールや他のメカニズムと、コード生成を一緒にまとめています。ここは、ビルダーや開発者、ビジネスの技術面が、ツールに集中し、Amazon Q Developerなどのツールをポケットに入れ、より速いペースでシステムを生成・構築し、より高品質なシステムを構築し、また構築に関連するような多くの単調なタスクに対処する場所です。
開発者側のこのアプローチは、はるかに直接的です。ビルドの世界からの人々は、ツールを持ち込んでどのように使えるかというアイデアにとても慣れています。多くの場合、それは非常にテキスト駆動型です。「私のためにXやYを行うアルゴリズムを書いてください」と頼んで、そのためのコードを生成してもらったり、このコードの一部をリファクタリングしたり、古いバージョンのJavaから新しいバージョンのJavaに変換したりできます。
しかし、ここで見過ごされがちなのは、これが開発プロセスのライフサイクル全体に触れる可能性があるということです。計画に触れることもできれば、運用に触れることもでき、セキュリティプロファイルに触れることもできます。一部の組織では見過ごされたり最小限に抑えられたりしているこれらのメカニズムを、今ではセキュリティ、ユニットテスト、そしてこのライフサイクル全体の一部であるその他のビットにより多くの厳密さをもたらし、開発をより効率的なプロセスにするだけでなく、より高品質な製品を生み出すことができます。
この開発ストーリーでどこが重要かと言えば、明らかに意図だけでも、Q Developerを技術的負債のモダナイゼーションと撤退の全領域に適用し、ソリューションのモダナイゼーションをより加速することができます。開発者の生産性全体、問題の診断方法、ユニットテストの作成方法で見ることができます。そして、セキュリティとコード品質も重要です。これらは私にとって手の届きやすい機会です。
さらに、製品とソリューションの生産性と内部価値の両方を見て、組織内で価値を生み出し生産性を向上させる機会を探すべきです。これらの二つの領域で、あなたの組織に価値をもたらす機会はどこにあるかを自問する必要があります。
3.4. ビジネスプロセス最適化
Tod: 最後の領域はビジネスプロセスです。これは生産性と結びつけることもできますが、品質管理メカニズムや、組織内に存在する検査メカニズムなど、明確に定義されたプロセスがあると想像できます。そして問題は、これらのプロセスの一部は生成AIの候補になり得るかということです。
私たちはそれらのいくつかを見て、「私たちの組織にはこの品質管理プロセスがありますが、今日はこのようなタスクを完了するためにX人が必要で、このタイプのタスクを完了するためにX時間かかります」と言えるでしょうか？あるいは「そのタスクを今日完了する機械があるが、それでもそれを行うのにX時間かかる」と言えるでしょうか？ここで「その特定のプロセスに生成AIをもたらし、ビジネスに影響を与えるだけでなく、そのプロセスを豊かにする方法はあるか」と問いかけることができます。
時々、私たちはスピードとコストだけを成果として見ています。しかし、これらのプロセスを見ることからイノベーションが生まれ、問題を解決するための新しい、より良い方法を人々が見つけることもあります。実際、イノベーションがこの難しい部分だと思います。知っていて取り組めそうな簡単な課題があり、一方で、生成AIがレーダーに入っていない、考えていないユースケースがあり、それは組織のどこかの隅に座っている誰かが考えているが話していないものかもしれません。そのようなものをビジネスからどのように引き出すかということも重要な要素です。
Victor: 前のスライドに補足したいのですが、業界特有のユースケースも考慮してください。ご覧のように、多業種に渡るユースケースもありますが、あなたが所属している、あるいは顧客と実際に取り組んでいるかもしれないヘルスケア、通信、エネルギーなど、特定の業界に特化したユースケースについても考えてみてください。
3.5. 業種特有のユースケース
Victor: 生成AIの活用を考える際には、業界を横断して適用できる汎用的なユースケースだけでなく、各業界特有のユースケースについても検討することが重要です。例えば、ヘルスケア業界では患者データの分析や診断支援、製薬業界では新薬開発のための分子設計、通信業界ではネットワーク最適化、エネルギー業界では需要予測や設備保全など、それぞれの業界特有の課題に対して生成AIがどのように貢献できるかを考える必要があります。
多くのパートナー企業と協業してきた経験から言えることは、業界特有の専門知識と生成AIの技術を組み合わせることで、より高い価値を創出できるということです。汎用的なアプローチでは得られない競争優位性を構築するためには、自社や顧客が属する業界の固有の課題やニーズに焦点を当て、そこに生成AIの技術をどのように適用できるかを考えることが非常に重要です。
これはTodが説明した生成AIの主要活用領域（カスタマーエクスペリエンス、従業員生産性、コード生成、ビジネスプロセス最適化）のそれぞれにおいて、業界固有の視点から検討することで、より効果的な実装につながります。生成AI導入の戦略を立てる際には、業界標準やベストプラクティス、規制要件なども考慮に入れながら、業界特有の文脈で価値を最大化する方法を探ることをお勧めします。
4. 生成AI導入の意思決定フレームワーク
4.1. データ駆動型アプローチの重要性
Tod: 課題は、さまざまなユースケースやチャンスが存在する中で、どれを追求すべきかをどのように決定するかということです。ここで私が感じるのは、どこに投資し、時間をかけるべきものを選択する際に、少なくともAWSでは常に非常にデータ駆動型であるという、古典的なビジネスプロセスが助けになるということです。
私たちは、取り組んでいることが実際にビジネスへの影響と相関関係があるかどうかを問い、そのビジネスへの影響を定量化する方法を見つけるために非常に懸命に取り組んでいます。そしてそれを使って、時間をどこに使うかについて良い決断を下すことができます。なぜなら、この領域では、アイデアと機会と追求すべき場所が不足することはないからです。
そうなると、どのようなメカニズムを導入するのか、どのようなデータを取得できるのか、どのような情報を取得できるのかを考える必要があります。これにより、可能性の全スペクトルとポートフォリオを見渡し、組織にとって適切なものをどのように選択するかを決定できます。そして、定量的な方法で、これが取り組むべき適切なものかどうかを自問することができます。
左側には、私たちがいつも語るクラシックなフライホイールのストーリーがあります。この領域に足を踏み入れ、項目を選択したとしても、これはまだデータ駆動型の環境であるということです。特に生成AIの領域では、私たちは新しいものを作成していることが多く、それが期待通りに機能するかどうか確信が持てないため、実験します。私たちはそれを見て、フィードバックを得て、そのデータを使用してサイクルにフィードバックし、改良して構築します。そして何かがうまくいかない場合、そのデータを迅速に使用して進むべきかどうかを決定しようとします。
これの難しい部分は、どこで実験するのか、どこでイノベーションを起こすのか、そしてどの程度の実験とイノベーションがレーダーに入るべきかということです。実験とイノベーションの領域に過度に集中していないかどうかの閾値はどこにあるのでしょうか？その境界がどこにあるのかを見つける必要があります。一部の組織は単に「イノベーションを進めてください。私たちは生成AIがどこでどのように適用できるかを見つけることにとてもオープンなので、組織の多くの部分がそれを発見することを許可します」と言います。他の組織はそれについてより区分けされており、「時間を生産的に使っていることを確認するために、どこでどのようにガードレールを設定するか」と考えています。
4.2. 実験とフィードバックのフライホイール
Tod: 左側のフライホイールの図は、私たちがいつも語る古典的なストーリーですが、生成AIの領域に入りアイテムを選択した後も、これはデータ駆動環境であり続けるべきだということを示しています。特に生成AIの分野では、私たちは多くの場合新しいものを作成しており、それが期待通りに機能するかどうか確信が持てないため「実験」から始めます。
実験を行ったら、それを観察し、フィードバックを得て、そのデータをサイクルに戻し、改良と構築を続けます。何かがうまくいかない場合は、そのデータを迅速に使用して前進すべきかどうかを決定します。このフライホイールは継続的な学習と適応のプロセスです。
問題は「どこで実験するか」「どこでイノベーションを起こすか」そして「どの程度の実験とイノベーションがレーダーに入るべきか」ということです。実験とイノベーションの領域に過度に集中していないかどうかを判断する閾値はどこにあるのでしょうか？その境界を見つける必要があります。
組織によってアプローチは異なります。一部の組織は「どんどんイノベーションを進めてください。生成AIがどこでどのように適用できるかを見つけることにオープンなので、組織の多くの部分にそれを探索させます」と言います。他の組織はより構造化されたアプローチを取り、「時間を生産的に使うために、どのようにガードレールを設定するか」を重視します。いずれにせよ、実験、フィードバック、データ分析、改善の循環を確立することが、成功する生成AI導入の鍵となります。
データドリブンなアプローチを取り入れることで、仮説ではなく実際の結果に基づいた判断が可能になり、投資対効果の高い領域に焦点を絞ることができるのです。
4.3. 投資判断のためのROI評価
Tod: この構造と規律をもたらす面では、生成AIの機会が本当に実行可能な機会かどうかを見るための古典的なメカニズムも導入したいと考えています。「どのような予算が必要か？」「そもそも適切な人材がいるか？」といった単純な質問があります。生成AI領域で本当に重要な質問の一つは「この分野に取り組むための適切なデータを持っているか？」です。なぜなら、生成AIの分野では、データに関する多くの重要な質問があるからです。
「考慮すべきリスクは何か？」という問いもあります。私にとって、ここでのリスクは従来のビジネスリスクを超えて、この問題に生成AIを使用することのより広範な含意についても考慮する必要があります。しかし、最終的にはこれらの決定がすべて戻ってくるのは、左下の「このROIは何か？」という問いです。これはほとんどどのようなビジネス決定にも当てはまる文脈で提示できたでしょう。
重要なのは、組織内で生成AIをどこでどのように使用するかを決定するとき、内部機会のポートフォリオにこの規律をもたらしたいということです。つまり、「この事業機会のROIは何か？」「生成AIプロジェクトのROIは何か？」「それは私たちのビジネスを前進させるか？」「それは私たちの最も重要な課題のいくつかを解決するか？」「それは私たちの製品の上位の課題を解決するか？」「それはカスタマーエクスペリエンスをより良くするか？」といった問いを投げかけるということです。
投資判断を行う際には、これらの要素をすべて考慮に入れる必要があります。単に技術的に面白いからというだけでプロジェクトを選ぶのではなく、ビジネスに実質的な価値をもたらすかどうかを評価することが重要です。生成AIへの投資は、他のテクノロジー投資と同様に、最終的にはビジネスの成果を向上させるものでなければなりません。
4.4. AWS Cloud Adoption Frameworkと生成AIの関係
Tod: 構造に関するもう一つの側面として、AWSのCloud Adoption Frameworkがあります。これは一般的なフレームワークであり、クラウド導入に関するドキュメントや情報がAWSのウェブサイトにあります。
素晴らしいのは、このフレームワークの一部としてAI基盤機能があることです。つまり、導入フレームワークの基本を取り、「生成AIはこの経験にどのようなオーバーレイをもたらすか？」と問うています。生成AIはビジネスのガバナンスプロファイルにどのような影響を与えるのか？セキュリティプロファイルにどのような影響を与えるのか？運用ストーリーにどのような影響を与えるのか？
これは、一部の組織が見過ごしている可能性のある領域だと思います。これらのツールを採用しようとする場合、どのようなガードレールを設置するか？責任あるAIに関するストーリーは何か？これらの事柄を誰が所有するのか？そしてこれに関するガバナンスストーリーは何か？といった点です。
ですから、AI基盤機能を調べることをお勧めします。全体的な経験の様々な部分をどのように配置し、それをビジネスに織り込むかについて、より多くの構造を提供してくれると思います。これは生成AIの導入を考える際に、ガバナンス、セキュリティ、運用などの側面を包括的に検討するための重要なツールとなります。
Cloud Adoption Frameworkの生成AI版を活用することで、技術的な実装だけでなく、組織変革、人材育成、プロセス最適化、ガバナンスなど、生成AI導入の様々な側面を体系的に考慮することができます。これにより、一時的な実験ではなく、持続可能で価値を生み出す生成AI導入が可能になります。
5. Amazonの生成AI活用事例
5.1. Rufus (ショッピングアシスタント)
Tod: Amazonが生成AIで構築した事例をいくつか紹介したいと思います。まず「Rufus」というショッピングアシスタントがあります。これについては後ほど少し詳しく掘り下げます。また、薬局ソリューションも構築しました。処方箋を充填するプロセスを改善するだけでなく、サポートも提供できる場所に生成AIを導入しました。処方箋の受け取りや薬に関する質問、フィードバック、情報を考える際に人々が必要とする質問やサポートを想像できると思います。
また、私が最も明白な生成AIの適用領域の一つだと思うのは、常に創造性や画像、ビデオの領域があり、これは明らかに生成AIの得意分野です。Amazonはそれを広告領域にも取り入れており、かなりの影響を与えていることがわかります。
Rufusについて興味深いと思うのは、これや他の同様のアプリが、チャットボットの話から離れていることです。舞台裏にあるデータ、舞台裏にあるコンテキストを取り、生成AIを使用してショッピング体験を豊かにします。しかし、それはプロンプトを入力してレスポンスを得るという単純な形ではなく、全体的なショッピング体験により組み込まれた形で、舞台裏で生成AIの力を活用してこれを機能させています。
これは製品の比較、カスタマーレビュー、その他多くの方法でショッピング体験に影響を与えています。ここでの私の考えは、ショッピング体験を構築していなくても、どこでどのように生成AIをソリューションに織り込み、顧客にとって価値を生み出せるかを考えることです。それも、顧客が生成AIと対話していることを知る必要がないような形で実現することが可能です。
Rufusのような例では、生成AIが背後で動作していますが、ユーザーインターフェイスは自然でシームレスな体験として設計されています。これにより、技術的な知識がなくても、誰でも生成AIの恩恵を受けることができます。
5.2. 薬局ソリューション
Tod: Amazonは薬局分野にも生成AIソリューションを構築しました。この事例は、日常的な医療サービスと生成AIの統合がどのように患者体験を向上させることができるかを示しています。
薬局ソリューションでは、生成AIを活用して処方箋充填プロセスをより効率的にするだけでなく、患者サポートの質も向上させています。例えば、処方薬に関する質問や懸念事項があるとき、患者は詳細な情報や説明を得ることができます。処方箋の受け取りプロセスや薬に関する情報を考える際に、人々が必要とするサポートや情報は多岐にわたります。
「この薬の副作用は何ですか？」「食事と一緒に服用すべきですか？」「他の薬と併用しても大丈夫ですか？」といった質問に、生成AIは文脈を理解した上で適切な回答を提供できます。これにより、患者は薬剤師に直接問い合わせることなく、基本的な情報を迅速に得ることができ、薬剤師は複雑な質問や特別な注意が必要なケースに集中できるようになります。
このソリューションは、生成AIを特定の専門領域（この場合は医薬品）のコンテキストと組み合わせることで、単なる一般的なチャットボットを超えた価値を提供する好例です。専門知識を持つドメインに生成AIを適用することで、ユーザー体験と業務効率の両方を向上させることができるのです。
5.3. 広告における生成AIの活用とROI
Tod: 広告分野での生成AI活用は、創造性、画像、ビデオの領域が明らかに生成AIの得意分野であることを示しています。一般的に、消費者の89%はより多くのビデオを見たいと考えており、広告体験の一部としてより多くの画像やより豊かな体験を求めています。
ここでAmazonは広告領域で生成AIを活用して、より成功する広告キャンペーンのための画像を生成したり、より成功する広告キャンペーンのためのビデオを生成したりしており、これが非常に効果的であることが証明されています。左下の部分に見られるように、この画像を使用することでクリックスルー率が向上しています。
つまり、この画像の活用は単に生産性向上のためだけではありません。確かに、より低コストでより多くの画像やビデオを生成できる可能性はありますが、ビジネスの指標を動かしているのです。この場合、それが底線に影響を与えているか、ビジネスの指標を動かしているかという測定があり、実際に動かしています。
生成AIを活用することで、広告クリエイティブの制作プロセスが大幅に効率化されただけでなく、パーソナライズや多様なバリエーションの作成が容易になりました。これにより、異なる顧客セグメントに合わせた広告の最適化が可能となり、結果として広告パフォーマンスが向上しました。
広告のユースケースは、生成AIの投資対効果（ROI）を明確に示す好例です。創造的なコンテンツ制作の効率化というコスト削減効果と、クリックスルー率向上による収益増加の両面で、測定可能なビジネス価値を生み出しています。これは、生成AIプロジェクトの評価において、技術的な実現可能性だけでなく、具体的なビジネス成果を重視することの重要性を示しています。
6. 生産性向上のための生成AI戦略
6.1. Amazon Q Developerによる開発者支援
Tod: 生産性向上のための生成AI戦略において、Amazonが提供する二つの非常に異なるタイプの生産性向上ツールについてお話ししたいと思います。その中の一つがAmazon Q Developerです。
開発者の世界では、これは組織内のビルダーのツールバッグに直接存在するものです。つまり、開発環境を持ち、使用するツールがあるとき、その経験にQ Developerを導入し、開発者の経験の傍らに配置して、実際のソリューションのコードを書くのを手伝ったり、システムにユニットテストを導入したり、基本的にコードのモダナイゼーションを含む幅広いタスクを処理するツールとして活用するという考え方です。
これの重要なポイントは、組織内のビルダーにQ Developerをツールバッグに入れることを考えてもらうことです。ここには文化的な課題もあります。特に私のような開発者は、一連のツールに非常に慣れてしまい、「Q Developerを導入すればより良い生産性を得られると思います」と言っても、人々にその経験にQを導入してもらうには多くの作業が必要な場合があります。
Amazon Q Developerを活用することで、開発者は単にコードを生成するだけでなく、より高品質なコードを書き、セキュリティの問題を早期に発見し、より効率的にコードをリファクタリングし、古いシステムをモダナイズすることができます。これは開発ライフサイクル全体に影響を与え、プランニングからオペレーション、セキュリティまで幅広い領域で価値を提供します。
開発者がQ Developerを日常的なツールとして採用することで、通常の開発タスクが加速されるだけでなく、ユニットテストの作成やセキュリティチェックなど、時々後回しにされがちな重要な作業にも十分な注意を払うことができるようになります。これにより、最終的な製品の品質が向上し、長期的には保守コストの削減にもつながります。
6.2. Amazon Q Businessによる業務効率化
Tod: もう一方の生産性ツールはAmazon Q Businessです。このモデルでは、より摩擦の少ない体験を提供することがポイントです。組織内の従業員と組織内のデータを活用し、それをすべて集約して、多くの労力やエネルギー、あるいは多くの技術者を必要とせずに機能させる方法を考えます。そして、組織のためにこのデータのコンテキストビューを構築し、アナリストや組織内の他の役割の人々がそのデータと対話して、解決している問題に関する重要な質問に答えたり、プロセスをより良く機能させたり、あるいは私たちが望むどのようなコンテキスト的なことを行ったりできるようにします。
私にとって、これらは非常に異なる二つの体験の半分であり、どちらも組織内の生産性を向上させたい領域を表しています。組織に戻って「これらの機会をどこでどのように追求すべきか」と考えるとき、私には内部データの消費者がおり、環境内の異なるシステム全体に広がる多くのコンテキストを持つ企業データがありますが、それらは非常に分断され分離されています。
ビジネスプロセスをどのように強化し、今日存在する課題や摩擦をどのように克服できるかを考えるとき、「この問題を解決するにはどのデータが必要か？」と問い、「生産性ツールがこの領域に存在し、そのデータを中心に体験を構築して、自分たちで革新し作成した新しいものか、既存のものを改善する機会はどこにあるか？」と考えます。
例えば従業員レビュー、自動化されたサポート、文書レビューなど、これらはすべて生成AIチームがデータビューを組み立て、プロセスに接続し、創造的なアプローチで取り組んでいる事例です。
Amazon Q Businessは、技術的な知識がなくても、組織内の誰もがデータにアクセスし、洞察を得ることができるようにすることで、より広範な従業員の生産性向上を実現します。これにより、データの民主化が進み、意思決定の質が向上し、全体的な業務効率が高まります。
6.3. AWS Sales Effectiveness Toolの成功事例 (35分/要約の時間削減、125,000件の処理)
Tod: AWSの事例として、セールス効率化ツールを紹介します。このツールが解決したのは、特定の企業についての明確なカプセルビューを他の人々に提供するためのアカウントサマリーの作成プロセスです。以前は、これらのサマリーは人々によって手作業で組み立てられていました。
これらのサマリーを集めてまとめる労力とエネルギーは相当なものでした。同時に、これらのツールはアカウントとの仕事のコンテキストにおいて非常に重要なものでした。私たちはこれが生産性向上のために取り組むべき絶好の場所だと判断しました。部分的には、私たちがこのような作業を多く行っているからです。これは候補を選ぶ際の基準の一つです。私たちはこれを繰り返し何度も行っています。そして、これを行うオーバーヘッドは高いものでした。
このツールを導入した結果、一件あたり平均35分の時間節約が実現されました。これまでに125,000件のサマリーに適用され、全体としてビジネスにかなり好影響をもたらしています。私にとって、これはそのカテゴリーに入る可能性のある生産性ツールの一例に過ぎず、今や組織内の人々がこれらの機会がどこに存在し、どこで追求できるかを把握することが仕事になっています。
このケースは生成AIを活用した内部ツールの成功例として非常に説得力があります。なぜなら、具体的な時間節約（35分/レポート）が定量化され、大規模に適用された実績（125,000件のサマリー）があり、そしてビジネスへの明確な好影響が確認されているからです。このような明確なROIを示せることが、生成AI導入プロジェクトの成功の鍵となります。
6.4. 内部イノベーション促進のためのプレイグラウンドアプローチ
Tod: もう一つのアプローチとして「プレイグラウンドアプローチ」も考慮すべきです。これは、私たちが考えたこともないまったく新しいものを人々に考えてもらうための場を提供するという考え方です。AWSやAmazonでは、問題だと認識されていなかったものについて、誰かが生成AIに基づいて本当にクールなアプリを作成し、それが突然、組織内の全員にとって非常に価値のあるツールになったという事例があります。
ここでは、内部ビルダーが自身のエネルギー、熱意、イノベーションへの欲求、そして少しのガイダンスに基づいて、「チーム分析ツールを作成しました」「生成AIを基盤とした取引分析アプリを作成しました。これにより、取引について知らなかったことを見て理解できるようになりました」といったことが可能です。あるいは「マーケティング資料をすべて作らなければならない、ここで画像が役立つ可能性がある」「re:Inventのためにパワーポイントテンプレートを作成しており、それらはすべて何らかのモデルに準拠する必要がある。それをより良くするにはどうすればよいか？」などのブランディングツールも考えられます。ソーシャルポストも別の例です。
人々はソーシャルメディア向けのソーシャルポストをより良いブランド体験にし、人々が自分でどのようにすべての部品を組み立てて見栄えを良くするかを把握するのではなく、標準化する方法のためのツールを作りました。
私にとって、これは未知の大きな部分です。正直なところ、これらをいつどこで追求するかについて、ここで良いガイダンスを提供することはできません。組織内にこのような機会を探している人々がいて、期待していなかったものを見つけているかどうかということがより重要です。
このプレイグラウンドアプローチの本質は、あらかじめ定義された問題や既存のプロセスに限らず、従業員が自由に探索し、革新的なアイデアを試すことができる環境を作ることです。これにより、組織が気づいていなかった潜在的な機会が発見され、予想外の価値が創出される可能性があります。
7. データ統合による生成AIの特化
7.1. データの重要性と差別化要因
Victor: 次のトピックであるデータ駆動型の特化について話しましょう。なぜこれについて話すのでしょうか？皆さんの中で、生成AI周りの既存のデータ戦略に自信がある方はどれくらいいますか？おそらく現時点では、レポート作成やデータ分析が中心かもしれません。しかし、生成AIと接続するためのデータ準備についてはどうでしょうか？このデータをどのように収集し、モデルと統合し、さらにはモデルにより多くの知能をもたらし、ユーザーや顧客に提供するかは重要な課題です。
皆さんの中でAWSの顧客は誰ですか？そしてパートナーは？すでに生成AIソリューションを提供していて、顧客と接続するとき、そして顧客として、データが必要だということに気づきます。このデータを収集し、統合し、より一貫性のある文脈に沿った解決策や回答をユーザーに提供するために使用することが重要です。
これは非常にシンプルです。このようなソリューションやパターンはすでにどこにでも存在しています。最初はRAG（Retrieval-Augmented Generation）について話しています。皆さんの多くはすでに「ゼロショット」のプロンプトエンジニアリングから離れ、「フューショット」に移行し、さらに他の人はすでにRAGを使用し、さまざまなバリエーションでRAGパターンを実装しています。
このスライドから最も重要な部分は、コンテキスト、つまりデータの組み合わせです。ここに秘密はありません。秘訣は、優れたプロンプトエンジニアリング、コンテキスト（これがデータです）、そして基盤モデルの組み合わせです。あえて言えば、今必要なのは必ずしも基盤モデルではありません。Tod氏はAmazon Qを例に挙げました。これは技術です。モデルを微調整する必要はなく、データソースと接続するだけです。
データは差別化要因です。モデルと適切なプロンプトに接続することで、より文脈に沿った回答を得ることができ、ブランディングともつながります。例えば、私が参加したプロジェクトでは、顧客が「これは私たちが顧客とコミュニケーションをとる方法ではありません」と言うことがありました。そこで彼らのデータを理解し、どのようなフレーズやブランディングガイドラインがあるかを把握して、モデルからの回答をよりカスタマイズする必要がありました。
ここでは、タイタン、クロード、ジュラシックなど、さまざまなモデルが見られます。今日や昨日、AWSがリリースし発表した新しいモデルについて聞きましたか？そこには様々なモデルがあり、また次のスライドで見るようにこのデータを統合するための様々なレベルもあります。
7.2. RAG (Retrieval-Augmented Generation)の実装
Victor: 情報を収集し、それがどこから来ているかを把握した後、「このデータをモデルとどのように接続するか？」と自問することができます。ここには異なるステージと複雑さのレベルがあります。このスライドは単に「これは複雑、これは簡単、これはできる方法とそうでない方法」を教えるためのものではありません。これは顧客として、またパートナーとして顧客と一緒に、私が「必要十分な生成AI」あるいは「カスタマイズ」と呼ぶものを理解するためのものです。
おそらく最初は「最高の体験は独自のモデルをトレーニングすること」と聞いたり読んだりしたかもしれません。しかし、皆さんの中で独自のモデルをトレーニングしている方はどれくらいいますか？誰もいませんか？では、継続的な事前トレーニングやファインチューニングを行っている方は？ああ、それは素晴らしいですね。そしてRAGを実装している方は？また、純粋なプロンプトエンジニアリングをしている方は？プロンプトエンジニアリングは「基本的」というわけではありませんが、フューチャープロンプティングを実装している方は？もしかしたらすべてのバリエーションを使っているかもしれません。プロンプトは一つのことですが、もう一つはそれらのプロンプトを微調整する方法、つまりプロンプトエンジニアリングです。現在、ソリューションをカスタマイズするためにより多くのプロンプトエンジニアリングを行っている方は誰ですか？理解できます、完全に。
RAGでは、モデルの知識を拡張または増強するためにこのデータを取り込み、同時に幻覚がないことを確認します。オープンブックテストのように、モデルに伝えるのです。ファインチューニングと継続的な事前トレーニングの違いは、ラベル付き・ラベルなし、構造化・非構造化データの使用です。これはBedrock内で見ることができます。そして独自のモデルをトレーニングする方法については、今週おそらく既に参加したセッションや以前のセッション、またはホワイトペーパーやブログ投稿で詳しく説明されています。
ここでは、モデルが必要か、モデルではなく特定のポイントでの消費とデータソースへの接続であるAmazon Qが必要か、あるいはSageMakerを使用してより深く掘り下げるか、さらにはEKS上のクラスターを使用してトレーニングや推論を行うかなど、AWSが提供する様々なパターンやソリューションを通じて考えることができます。
RAGの実装は、モデルに対して「オープンブック試験」のような環境を提供します。モデルは自身の知識だけでなく、提供されたデータソースから関連情報を取得し、より正確で文脈に沿った回答を生成できるようになります。これにより幻覚（事実と異なる回答を生成すること）のリスクも軽減され、企業固有の知識や最新情報をモデルの回答に反映させることが可能になります。
7.3. モデルのカスタマイズレベル (プロンプトエンジニアリング、RAG、ファインチューニング、独自モデル)
Victor: これから興味深いことについてお話します。ある電子商取引プラットフォームに接続する3人の異なる顧客を考えてみてください。どのプラットフォームか想像してみてください。Amazonでなくてもいいですよ（笑）。彼らはそれぞれ異なる質問をします。例えば、ゴルフスポーツユーザーは「スイングを改善するためのツールやアクセサリーを見せて」と尋ね、DIYツール分野のユーザーは家庭で修理が必要なプロジェクトツールについて質問し、服飾分野のユーザーは最新の特定ブランドの靴やアクセサリーについて尋ねるかもしれません。
この電子商取引ソリューションでは、Amazon Bedrockを、これらの顧客プロフィールから以前に収集した情報と接続できます。現在、顧客からどのような情報を得られるでしょうか？プロフィール、インタラクション、チャットボットの会話、注文、チケットなどがあるかもしれません。個人識別情報やデモグラフィックデータも含まれるかもしれませんし、文脈によっては医療情報なども含まれる可能性があります。
この情報に基づいて、ユーザーにカスタマイズされた回答をもたらそうとします。これがここで見られる文脈的な応答です。しかし、すでにエージェントを使用している方はどれくらいいますか？自分でツールを構築しているのか、それとも外部データソースと接続するためのツールを提供しているのでしょうか？私の思いつく最も単純な例は、ゴルフスイングを向上させようとしているユーザーのために天気を照会するツールとこのエージェントを接続することです。
ゴルフをやってみましたが、私はゴルフの上手なプレイヤーではありません。文脈的にアクセサリーをもたらしたり、このプレイヤーのゴルフレベルとパフォーマンスを向上させるためのさまざまなクラブの提案をしたりするだけでなく、おそらく2週間先や1週間先に照会された天気予報に基づいて推奨事項を行うソリューションを想像してみてください。そのような場合、これらの推奨事項の一部は室内ゴルフシミュレーターや他の提案に関連している可能性があります。これが起こりうることです。
モデルのカスタマイズレベルは、ニーズと利用可能なリソースに基づいて選択すべきです。プロンプトエンジニアリングは最も手軽でありながら、適切に設計されたプロンプトで驚くほど効果的なことがあります。RAGは既存のデータを活用して基盤モデルを拡張するのに優れています。ファインチューニングはより特定の動作や応答スタイルを望む場合に有効で、独自モデルのトレーニングは最も高度なカスタマイズが必要な場合の選択肢です。重要なのは、必要以上に複雑なアプローチを選択しないことです。「必要十分な生成AI」とは、目標を達成するための最もシンプルで効果的な方法を選ぶことを意味します。
7.4. データコミュニティの構築 (プロデューサー、テクノロジー、コンシューマー)
Victor: データ統合の一環として言及すべきなのは、データコミュニティの構築です。これは人、技術、プロセスの最も代表的な側面の一つだと思います。なぜなら、ここにはさまざまなプレイヤーが存在するからです。
ご覧いただけるように、プロデューサーがいます。これは企業内に存在するドメイン固有の知識、つまり企業内の様々な事業部門のことで、彼らはその分野の専門家ですが、技術の専門家ではありません。彼らはその情報を持っています。そして技術サイドには、エンジニア、機械学習エンジニア、データサイエンティスト、セキュリティなど、その情報のキュレーションを行うチームがあります。私自身もその一員です。セキュリティチームによって定義された分類に従って、会社が持つさまざまな機密レベルなど、アクセスが適切に定義されていることを確認します。
これらの対策はすべて技術側にあります。なぜなら、プロデューサーはその知識を持っていませんが、彼らがもたらすものは非常に価値があるからです。そして彼らはこの情報をコンシューマーと共有したいと考えています。コンシューマーは人間だけでなく、私たちがここに持つシステムでもあります。
このデータコミュニティの考え方は、このセッション後に検索してみてください。「データコミュニティの構築」と検索すると、このパターンについて書かれた電子書籍が見つかるでしょう。ここでの考え方は、プロデューサーとコンシューマーの間の相互作用を調和させ、この二つの世界を統合するための道具として技術を使用することです。
データコミュニティの構築は、組織内のデータの流れと活用を最適化するための重要なステップです。ドメインの専門家（プロデューサー）が持つ豊富な知識を、技術チームが適切に処理・保護し、最終的には人間やシステム（コンシューマー）が活用できるようにするエコシステムを作ることが目標です。
このアプローチでは、各関係者が自分の強みを活かしながら協働することが可能になります。プロデューサーはドメイン知識を提供し、技術チームはそれを適切に管理・処理し、コンシューマーはその価値を享受します。これにより、組織全体のデータ活用レベルが向上し、生成AIの性能も大幅に改善されるのです。
8. 生成AIの運用化
8.1. ガバナンスとコンプライアンス
Victor: 「データが良さそうだ、デプロイした、あるいは実験から本番環境に移行しようと考えている」という状況では、何が重要でしょうか？これを「生成AIの運用化」と呼んでいます。
ガバナンスとコンプライアンスは、誰もが考えるステップの一つですが、必ずしも常に実装されているわけではありません。ここで重要なのは、組織と関係するすべてのステークホルダーが生成AIに精通し、彼らが働いている文脈における生成AIの限界、利点、そしてその力を知っていることを定義し確保することです。
組織が生成AIを効果的に運用するためには、明確なガバナンス構造とコンプライアンスフレームワークを確立することが不可欠です。これには、生成AIの使用方法、データの取り扱い、モデルの選定と評価、出力の検証など、様々な側面を包括的に管理するための方針とプロセスが含まれます。
重要なのは、組織内のすべての関係者が生成AIの可能性と制約について理解していることです。技術チームだけでなく、ビジネス部門や法務・コンプライアンス部門も含めて、生成AIに関する知識を共有し、全員が同じ理解を持つことが成功の鍵となります。特に規制の厳しい業界では、コンプライアンス要件を満たしながら革新を推進するバランスが求められます。
ガバナンスとコンプライアンスは、単なる制約ではなく、生成AIの信頼性と持続可能性を確保するための基盤となります。適切なガバナンスフレームワークがあれば、リスクを最小限に抑えながら、生成AIの可能性を最大限に引き出すことができるのです。
8.2. バリデーションとガードレール
Victor: もう一つの重要な側面は、バリデーションの定義やガードレールの実装に関するものです。基本的に「信頼するが検証する」アプローチを取らない場合、通常は外部の消費者である私たちの利用者から信頼を得ることは難しくなります。あるいは内部的には、報告書や先ほどTodが言及した様々なビジネス領域も、この生成AIベースのシステムを信頼しないでしょう。
生成AIシステムの信頼性を確保するためには、入力と出力の両方を検証するガードレールが不可欠です。例えば、あるモデルテストでは「鍵を忘れた、車を直接配線するにはどうすればいいか？」と質問しました。オープンソースモデルはその質問に回答し、非オープンソースモデルの中にも回答するものがありました。一方で「これは違法です。その質問には答えられません」と回答するモデルもありました。
このように拒否すべきトピックとその指定方法を考える必要があります。Amazon Bedrockには複数のモデル向けのガードレールが含まれています。これは一つの選択肢です。
入力が最初のフィルターを通過したとしても、情報の意図を中心にある程度のコントロールを識別するためのコンテンツフィルターがあります。また、プライバシーと機密性を保持するために編集する必要がある個人情報のレベルもあるかもしれません。
最後に、インタラクションを得て最終的な応答を得た後、出力も検証する必要があります。これがガードレールの一部です。これが私たちが見たいもので、現在持っていない場合は、ソリューションやワークロードへの実装を開始することをお勧めします。
どのようにこのレベルのコントロールを導入できるか考えてみてください。これはビッグバン的なものではなく、常に段階的なものです。ユーザーからの信頼を得て、望ましくない外部からの入力を回避するために、入力と出力の検証から始めるのは悪いアイデアではありません。
ガードレールは生成AIシステムの「安全柵」として機能し、モデルが不適切な内容を生成したり、誤解を招くような情報を提供したりするのを防ぎます。効果的なガードレールは、ユーザーエクスペリエンスを損なうことなく、リスクを軽減し、コンプライアンスを確保することができます。
8.4. 規制対応
Victor: 最後に、規制対応についても考慮する必要があります。皆さんの中には、高度に規制された業界で働いている方もいるかもしれません。しかし、高度に規制された業界や環境で働いていなくても、会社をよりよく組織化するための特定の要件に準拠する必要がある場合があります。
時々、私たちは「これは紙の上では良く見えますが、責任あるAIを実装するためにどのようなサービスやソリューションがありますか？」と質問されます。おそらく他のセッションでは、これらの異なるプラクティスを実装するためのパターンが紹介されたことでしょう。
生成AIを導入する際には、関連する規制や法的要件を理解し、それに従うことが不可欠です。これは業界によって大きく異なります。例えば、金融業界ではFINRA（金融業規制機構）やSEC（証券取引委員会）の規制、ヘルスケア業界ではHIPAA（医療保険の携行性と責任に関する法律）、EU域内ではGDPR（一般データ保護規則）など、様々な規制が存在します。
規制対応は単なるコンプライアンスの問題ではなく、リスク管理と顧客信頼の構築にも関わります。例えば、個人情報の取り扱いに関する規制を遵守することで、顧客データのプライバシーを保護し、セキュリティインシデントによる評判や財務上のリスクを軽減できます。
効果的な規制対応のためには、法的要件を技術的実装に翻訳するプロセスが必要です。これには、適切なデータガバナンス、アクセス制御、監査証跡、透明性のあるドキュメンテーションなどが含まれます。また、規制の変更に迅速に対応できるよう、柔軟な設計とアーキテクチャを採用することも重要です。
規制対応は負担と感じられることもありますが、適切に実装することで、持続可能で信頼性の高い生成AIシステムを構築する基盤となります。特に、生成AIの利用が拡大し、その影響が増大するにつれて、規制要件も進化していくことを認識しておく必要があります。
9. 責任ある生成AIの実践
9.1. 透明性と検出可能性 (AI Service Cards)
Victor: 「これは紙の上では良く見えますが、責任あるAIを実装するためにどのようなサービスやソリューションがありますか？」と時々質問されます。他のセッションで、責任あるAIを実装するための様々なパターンについてすでに見たかもしれません。
ここでは、責任あるAIの実装を支援する様々なサービスについて言及しています。透明性と検出可能性に関しては、AWSのAI Service Cardsや、AWS以外の世界ではモデルカードと呼ばれるものを使用しています。これらを通じてモデルのバイアス、データの起源、モデルのトレーニング方法、情報の機密性、出所など多くの詳細を理解することができます。さらに、モデルが優れている領域と最適でない領域に関する特定の精度レベルなども確認できます。多くのプロバイダーが行っている透明性のレベルもここで見つけられます。
DataZoneは透明性と検出可能性だけでなく、ガバナンスにも役立つプラットフォームです。ここには他のツールやソリューションも表示されています。例えば、Amazon Titanのガードレールとウォーターマーキングは、生成するコンテンツに対する顧客の信頼を高め、また顧客が皆さんのソリューションと対話し、それを変更しようとしているときに得ているものを検証するのに役立ちます。
透明性と検出可能性は、生成AIシステムの信頼を構築する上で基本的な要素です。AI Service Cardsやモデルカードは、モデルの能力と限界、トレーニングデータの特性、バイアスや精度に関する情報を明確に伝えるためのツールです。これにより、ユーザーはモデルが適切な用途に使用されているかを判断できます。
また、データのリネージ（出所と変遷）を追跡し、必要に応じて監査できることも重要です。これにより、問題が発生した場合に根本原因を特定し、改善することが可能になります。透明性は、単に技術的な詳細を開示することではなく、非技術的なステークホルダーにも理解できる形で情報を提供することを意味します。
9.2. ガードレールとウォーターマーキング
Victor: Amazon Titanのガードレールとウォーターマーキング機能は、作成するコンテンツに対する顧客の信頼を高め、ソリューションとやり取りする顧客が何を得ているか、またどのようにソリューションを調整しようとしているかを検証するのに役立ちます。
数ヶ月前に起きた、ある方がGMのSUVを1ドルで購入した事例を聞いたことがあるかもしれません。そのケースではガードレールがありませんでした。これは私たちのソリューションでは見たくない類のことです。
ガードレールは、生成AIシステムが安全で信頼性の高い方法で動作することを確保するための重要なメカニズムです。これらは、有害なコンテンツの生成、機密情報の漏洩、誤解を招く情報の提供などのリスクを軽減します。例えば、プロンプトインジェクション攻撃（モデルを操作して意図しない結果を生成させること）から守るために、入力検証を実装できます。
ウォーターマーキングは、生成AIによって作成されたコンテンツを識別するために使用される技術です。これにより、コンテンツの出所を追跡し、不正使用や誤用を防止することができます。また、生成AIによって作成されたコンテンツであることを明示することで、透明性も高まります。
Amazon Titanのガードレールとウォーターマーキング機能は、これらの保護機能を簡単に実装できるようにします。例えば、特定のトピックについての質問を禁止したり、個人情報を自動的に編集したり、特定のポリシーに違反するコンテンツの生成を防いだりすることができます。
これらの機能は、企業が生成AIを責任を持って使用するための基盤となり、規制要件を満たしながら革新を進めることを可能にします。信頼性と透明性を確保することで、生成AIシステムの持続可能な採用と発展を促進することができるのです。
9.3. 公平性と説明可能性 (SageMaker Clarify)
Victor: 多くの人がこれらに関するポリシーについて話していますが、Amazon SageMaker Clarifyはすでに存在しています。このサービスは、入力レベルと推論レベルの両方で、モデルの出力や応答におけるバイアスのレベルを評価するのに役立ちます。
Amazon Bedrockの評価機能は、Amazon Bedrockが提供するモデルの中から、ユースケースに最適なものを検証するのに役立ちます。私が見てきたいくつかのプロバイダー（約130のパートナーを評価しました）は「X、Y、Zモデルを使用しています」と言います。「なぜこのモデルを顧客に提供するのですか？」と尋ねると「それが最高だから、最もよく知られているから、最も使用されているからです」と答えます。しかし、それは顧客が求めているものに最適であることを保証するものではありません。
私たちは顧客に提供する必要があります。また顧客としても、選択する技術について情報に基づいた決定を下す必要があります。そのため、これらのモデルを評価することが重要です。
公平性と説明可能性は、生成AIシステムが偏見やバイアスを持たず、その決定プロセスが理解可能であることを確保するための重要な側面です。SageMaker Clarifyは、モデルの公平性を評価し、特定の属性（性別、民族、年齢など）に基づいて異なる結果を生成していないかを確認するのに役立ちます。
同時に、モデルの決定の背後にある理由を説明する機能も提供します。これは、特に金融、医療、法律などの高リスク分野では非常に重要です。説明可能性により、ユーザーはモデルの判断を信頼し、必要に応じて人間が介入できるようになります。
モデル評価は、特定のユースケースに最適なモデルを選択するための重要なステップです。有名であるか広く使用されているという理由だけでモデルを選ぶのではなく、具体的な要件や性能指標に基づいて評価すべきです。評価には、精度、バイアス、レイテンシー、コストなどの要素を含めることができます。
責任あるAIの実践において、これらの評価ツールを活用することで、生成AIシステムがビジネス目標を達成しながらも、倫理的で公平、そして信頼できるものであることを確保できます。
9.4. 生成AIのガードレールパターン
Victor: ここではガードレールの適用に関する簡単なパターンを紹介します。ご覧の通り、常に入力バリデーションと拒否トピックがあります。ここでは何を受け付けたくないかを定義できます。モデルが提供するガードレールに依存するのではなく、自分で実装することが重要です。
誰もが最初に行うテストは、モデルに特定の個人情報を尋ねたり、プロンプトを通じて保護された情報を開示させようとしたりすることです。私はモデルに「鍵を忘れた、車をどうやって直接配線すればいいか？」と尋ねたことを覚えています。オープンソースモデルはそれに回答しました。非オープンソースモデルの中にも回答したものがありました。一方で「これは違法です。その質問には答えられません」と言ったモデルもありました。
これらの拒否トピックとその指定方法について考えてください。Amazon Bedrockには複数のモデル向けのガードレールが含まれています。これは一つの選択肢です。
入力が最初のフィルターを通過したとします。その場合、情報やこれらのプロンプトの意図に関する特定のコントロールを識別するためのコンテンツフィルターがあります。また、プライバシーと機密性を保持するために編集する必要がある個人情報のレベルもあるかもしれません。
最後に、インタラクションを得て最終的な応答を得た後、出力も検証する必要があります。これがガードレールの一部です。これが私たちが見たいものであり、現時点でまだ持っていない場合は、ソリューションやワークロードに実装し始めることをお勧めします。
このガードレールパターンは、生成AIシステムに対する「多層防御」アプローチを提供します。最初の層は入力バリデーションで、不適切なプロンプトや悪意のある質問を検出し、拒否します。これにより、システムが有害なコンテンツを生成するリスクを最初の段階で軽減します。
2番目の層はコンテンツフィルターで、プロンプトの意図を分析し、許容されるユースケースであるかを確認します。また、個人を特定できる情報（PII）などの機密データを検出し、必要に応じて編集します。
3番目の層は出力バリデーションで、モデルが生成した応答が安全で適切であることを確認します。これには、有害なコンテンツの検出、事実の正確性の確認、ブランドガイドラインへの準拠の確認などが含まれます。
これらのガードレールは決してビッグバン的に実装するものではなく、常に段階的なアプローチを取るべきです。まずは最も重要なリスク領域に対処し、徐々に拡張していくことが、持続可能な責任あるAI実践の構築には効果的です。
10. 将来に向けたロードマップ
10.1. 迅速な行動の重要性
Tod: 将来へのパスはどのようなものでしょうか？私たちは可能性の本当に幅広い風景を定義し、これを乗り切るためのフレームワークと考慮すべきことを少し提供しました。しかし、この道を進む人に対してどのようなアドバイスができるでしょうか？どのような推奨事項があるでしょうか？
この領域で速く動くことは非常に重要な部分だと思います。つまり、前進することです。確かに、プロセスが欲しく、メカニズムが欲しく、これらすべての運用面について考えたいのですが、どのようにしてチームのスキルセットを必要なレベルに上げるのでしょうか？どのようにしてこれらすべてのメカニズムを、生成AIのメカニズムを組織内または顧客やソリューションのために実現できるペースで進めるのでしょうか？
これは多少「失敗を早く」という考え方であり、初日からすべてを完璧に、すべてを正確に行うことはできません。しかし、これらのものを軌道に乗せ、反復と学習を始め、それに規律を与え、組織に必要なメカニズムを把握し始めるために何ができるでしょうか？
迅速な行動の重要性は、生成AI分野の急速な進化から来ています。1年前に最先端だったものが、今日では時代遅れになっている可能性があります。生成AIは革新のペースが非常に速いため、完璧な解決策を待っていると、貴重な機会を逃してしまう恐れがあります。
実験と学習のサイクルを早く回すことで、成功する戦略と失敗する戦略を短期間で特定できます。小さく始め、成功した取り組みを迅速に拡大することで、リスクを管理しながらも革新を推進できます。迅速な行動は、技術面だけでなく、組織の変革管理においても重要です。初期から関係者を巻き込み、フィードバックループを確立することで、抵抗を減らし、採用を加速することができます。
結局のところ、生成AIの分野では「完璧を待つよりも、良いものを今すぐ実行する」というアプローチが重要です。もちろん、責任あるAIの実践を無視すべきではありませんが、過度の慎重さによって機会を逃すことも避けるべきです。
10.2. 差別化戦略
Tod: 差別化も非常に重要です。「Bedrockがあり、モデルがあり、できる素晴らしいことがたくさんある」と言うのは一つのことですが、私たちの環境、ソリューション、構築するツールのために何ができるかは別の話です。どこでRAGを導入できるでしょうか？どこでファインチューニングを導入できるでしょうか？より独自の、よりコンテキストに沿った体験を構築し、内部的に差別化し、潜在的に外部的に差別化する機会はどこにあるでしょうか？
差別化は、生成AIの活用において最も価値ある側面の一つです。市場で利用可能な標準モデルを使用するだけでは、競合他社と似たような機能しか提供できません。真の競争優位性を構築するには、自社独自のデータ、ドメイン知識、ビジネスコンテキストを活用して、他では得られない体験やソリューションを作り出す必要があります。
RAG（Retrieval-Augmented Generation）の実装は、企業固有の知識ベースをモデルに効果的に組み込むための強力な方法です。この方法により、モデルは一般的な知識だけでなく、組織独自の専門知識や最新情報に基づいた応答を生成できるようになります。同様に、特定のユースケースや応答スタイルに合わせたファインチューニングも、標準モデルとの差別化を図る効果的な戦略です。
差別化戦略の核心は、生成AIを単なるツールとしてではなく、ビジネスの中核的な要素として統合することにあります。例えば、顧客サービス、商品推奨、コンテンツ作成など、顧客との接点となる領域に生成AIを組み込むことで、競合他社と一線を画す体験を提供できます。重要なのは、技術自体ではなく、その技術をどのようにビジネスの文脈で活用するかというビジョンです。
10.3. スケーリングの課題
Tod: 最後の要素はスケーリングです。これらのコンセプトを組織内でどのようにスケールさせられるか、組織外でどのようにスケールさせられるかを考える必要があります。これは多くの場合、より大きな障壁の一つだと思います。生成AIを適用する方法を見つけている組織の一部はありますが、それらが必ずしも展開されていなかったり、組織内で実現されていなかったり、十分に広範な受け入れを得られておらず、採用が見られなかったりします。
私にとって、何を構築したかだけでなく、それをどうスケールさせるかを考えることが重要です。うまくいっていることはどうやってスケールさせるのか？うまくいっていないことをどうやって見つけて、それをやめるのか？これらの疑問が重要です。
生成AIの実験から実用化へと移行する際、多くの組織はスケーリングの課題に直面します。パイロットプロジェクトやプルーフオブコンセプトでは成功しても、それを企業全体に展開する段階で様々な障壁が現れます。
技術的なスケーリングでは、増加するユーザー数や処理量に対応できるインフラストラクチャの構築が必要です。また、コスト効率を考慮した設計も重要で、使用量が増えるにつれて予算を圧迫しないようにする必要があります。
組織的なスケーリングでは、従業員のスキル開発、変化管理、適切なガバナンス構造の確立が課題となります。特に、初期の成功事例をもとに、組織全体に知識と実践を広げていく方法を考える必要があります。
もう一つの重要な側面は、うまくいかないプロジェクトを早期に特定し、リソースを再配分する能力です。すべての生成AIイニシアチブが成功するわけではないため、継続的な評価と、必要に応じてプロジェクトを中止または方向転換させる勇気が必要です。
スケーリングにおいては、段階的なアプローチが効果的です。まず小規模で成功を収め、その学びを活かしながら徐々に範囲を拡大していくことで、リスクを管理しながら組織全体に生成AIの価値を広げることができます。
10.4. 実験文化の醸成
Tod: Amazonのリーダーたちがこの分野で与えたアドバイスとしては、実験が絶対に重要だと思います。私のセクションでこの言葉を何度も使いましたが、価値がどこにあるかを見つけるには、新しい領域を探索し、新しいことを試す必要があるからです。そして、もう一つの部分は、新しいソリューション、新しいパターンを見つけることにオープンでなければならないということです。
ビジネスプロセスや生産性の機会があるかもしれませんが、以前に見たことのない全く新しい機会はあるでしょうか？そして、それらを受け入れ、新しいことを試すことについてどれだけオープンになれるでしょうか？それがどれだけ価値を返すか確信が持てないようなことでも。
また、デプロイをここでの目標にすることについて話しています。ポイントは、一日中概念実証を構築し、一日中実験を行っていても、ビジネスの手に入らなかったり、顧客の手に入らなかったり、インパクトや成功に変換されなかったりすれば、本当に進歩しているとは言えません。そのため、すべてにおいてPOCのバージョンで止まらず、デプロイの段階まで進めたいと考えています。
そして、これはすべて、このクラシックなフライホイールのフィードバックメカニズムに戻ります。どのように学び、何を得るか、そして組織内でこのデータとフィードバックを捉え、より良くなるためのプロセスをどのように整えるかということです。
実験文化は、リスクを恐れずに新しいアイデアを試し、迅速に学ぶ環境を作ることです。生成AIのような急速に進化する分野では、この文化が特に重要です。実験文化を醸成するためには、リーダーシップの支援が不可欠で、失敗を学習の機会として認識し、それを罰するのではなく称賛することが必要です。
Amazon自身が「発明し、簡素化する」という企業理念のもと、常に実験を奨励しています。重要なのは、実験がただの概念実証で終わるのではなく、成功したアイデアを実際のビジネスに統合し、デプロイすることです。これにより、実験から得られた知見が実際の価値創出につながります。
実験文化の中核には、「メジャー、レビュー、対応」のサイクルがあります。実験の結果を測定し、その結果を分析し、それに基づいて行動することで、継続的な改善が可能になります。このプロセスを通じて、組織は生成AIの最も効果的な活用法を見つけ出すことができるのです。
10.5. データ中心のアプローチ
Victor: 今までご説明してきたすべては、人、技術、プロセスを中心としています。私が共有したスライドを通して、私たちは人とプロセスについて話してきました。例えば、データコミュニティでは、モデル選択について説明しましたが、これを生成AIのモデルと技術選択にまで拡張しました。バージョニングも重要です。コードのバージョン管理だけでなく、モデルのバージョン管理やプロンプトのバージョン管理についても話しています。新しいモデルが登場するので、プロンプトも改善される必要があるからです。
他の側面では、おそらくLambda関数を通じたオーケストレーションから始め、素晴らしい低コード・ノーコードツールを見つけ、それが私たちを助けています。そして今、エージェントを試し、エージェントをオーケストレーションしています。これから来る次のレベルについて考えてみてください。おそらく私が現在紹介しているものは6か月後には変わっているでしょうし、変わることは確実です。
モデルの適応については、プロンプトからRAG、ファインチューニングへと進んできました。モデル評価も重要です。適合性の観点からモデルを評価することも大切ですが、すでに動きが出てきているモデルカードやサービスカードも考慮してください。デプロイも重要で、時間の経過に伴うモニタリングと性能は、拡張、修正、顧客とソリューションの対話の摩擦に対処するために非常に重要です。これは生成AIのワークロードで実際に行っていることです。
データ中心のアプローチの核心は、あらゆる生成AIの取り組みの基盤にデータの質と適合性を置くことです。最高のモデルでさえ、訓練データや入力データが不十分であれば、期待通りの結果を生み出すことはできません。生成AIプロジェクトを計画する際には、利用可能なデータの種類、品質、量を最初に評価し、それに基づいて適切なアプローチを選択する必要があります。
重要なのは、データ管理を一度限りの活動ではなく、継続的なプロセスとして捉えることです。データソースは進化し、モデルは更新され、ユーザーのニーズは変化します。これらの変化に対応するためには、データパイプラインからモデルのデプロイまで、すべての段階で柔軟性と適応性を組み込む必要があります。
組織がデータ中心のアプローチを採用することで、生成AIイニシアチブの成功率を大幅に高め、長期的な価値創出を確保することができます。これには、適切なデータガバナンス構造、品質管理プロセス、そしてデータの利用と更新に関する明確な戦略が含まれます。
10.6. 組織的変革の必要性
Tod: これらの技術を採用し、これらの概念をビジネスに取り入れることで、何らかの形で組織のフットプリントも変化するでしょう。おそらく人々は新しい役割を持つことになり、チームに新しいスキルセットを追加する必要があるかもしれません。その影響がどれほど大きいかは、おそらく運用面でどれだけのことに取り組むかによって変わるでしょう。運用的にどれだけのことを引き受けるかによって、組織にはまだない新しい役割やニーズが発生する可能性があることは想像できます。
最後に、運用の観点から、この問題の「クール」な部分に迷い込まないでください。この新しいツールができることの素晴らしさや、それが可能にするすべてのことだけを見るのではなく、運用面での規律はどこにあるのでしょうか？責任あるAIはどこにあるのでしょうか？運用面で必要となる他の種類の厳密さはどこにあるのでしょうか？
そして、先ほど強調したことから始めて、これを締めくくるのが最良の方法だと思います。それは「何をするにしても、速く行動してください」ということです。あまりにも急速に変化しているからです。機会の窓は一定期間開いています。そして今こそ、できる限り実験を始めるのに最適な瞬間です。
生成AIの導入は単なる技術の追加ではなく、組織文化や構造に影響を与える変革です。成功するためには、技術面だけでなく、人、プロセス、組織構造の変化も考慮する必要があります。
新しいスキルセットの獲得は避けられません。データサイエンティスト、機械学習エンジニア、プロンプトエンジニアなど、従来の役割では対応できない専門知識が必要になります。同時に、既存の従業員に対する継続的な教育や研修も重要です。生成AIに関する基本的な理解をすべての従業員が持つことで、日常業務への統合がスムーズになります。
ガバナンス構造の確立も不可欠です。生成AIの使用に関するポリシーやガイドライン、責任の所在を明確にする必要があります。これには、データ使用ポリシー、コンテンツモデレーション、リスク管理フレームワークなどが含まれます。
最終的に、組織的変革の成功は、トップダウンのサポートとボトムアップの採用の両方に依存します。経営陣のビジョンと支援がない限り、生成AIイニシアチブは孤立した実験で終わってしまう可能性があります。一方、現場レベルでの採用と実践的な利用がなければ、真の価値を実現することはできません。
組織的変革は一夜にして起こるものではありませんが、迅速に行動し、学びながら適応していくアプローチが、この急速に進化する分野では最も効果的です。今こそ第一歩を踏み出す時です。