AWS の最新の生成 AI でイノベーションを推進する

Jonathan Allen:
お越しいただきありがとうございます。忙しい午前中でしたね。基調講演、大変良かったです。チームが築き上げてきたものに対して、大きな情熱と誇りを持っていることがよくわかりました。今朝は 20 を超える発表がありましたね。

Swami Sivasubramanian 博士:
そうですね。

Jonathan Allen:
まるで追経験しているようでした。もう 1 回と。もう 1 回と。とてもすばらしいと思います。発表の急増、顧客にとっての膨大なイノベーションについて振り返ると、実際に頭に浮かぶ 2 つまたは 3 つのことは何ですか?

Swami Sivasubramanian 博士:
やりましょう。まず最初に、お招きいただいたことにお礼申し上げます。ここでグループの皆さんお会いできて本当にうれしいです。先ほどの質問では、お気に入りの子供は誰ですかとたずねられているのと同じですね。実世界では、我が家には 2 人の子供と 1 匹の子犬がいるので、この 2 人と 1 匹がお気に入りということになります。

それはさておき、質問に話を戻すと、さまざまな意味で重要になるのは、AWS の AI へのアプローチは 1 つのモデルや 1 つのチャットボットにとどまらないということです。将来、イノベーションはスタックのあらゆる層、あらゆる企業で起こるだろうと考えています。このコンテキストを設定し、質問に答えますが、誰もが考えるので重要です。つまり、すべての組織のすべてのアプリケーション開発者がモデルと Bedrock が提供する機能を持つすべてのツールでイノベーションするのを見ることになります。もちろん、生成 AI は、デベロッパーだけでなくビジネスユーザーやデータアナリストも実際に支援するようになります。

しかし、もう 1 つ忘れがちなのは、コンピューターサイエンスの学位を持つすべての人、そして現在の学部生は、大規模な言語モデルをゼロから構築する方法を知っているということです。これは既に起こっていることです。これからのワークフォースは、このようなモデルの能動的な作業をオープンソースで実際に行うことができる人で構成されます。だからこそ、スタックのあらゆる層で実際にイノベーションを続けることが重要なのです。これが基盤となります。

心に残っていることという質問でしたので、いくつか掘り下げてみましょう。1 つは、もちろん、AWS に 18 年ほど在籍していることです。したがって、GenAI を使用している多くの点で、AWS の初期の時代、文字通り数人しかいなかったとき、おそらくこの部屋のサイズとそうではないことを思い出させます。従業員の数は多くありませんでしたが、イノベーションのペースは速く、AWS はゲームチェンジャーでした。

また、多くの点で、Bedrock のイノベーションのペースは、DynamoDB や S3 などを構築した時間を思い出させます。また、まだ曖昧な前例のない時期です。2023 年はプロトタイプがすべてでした。私たち全員にとってそうでした。お客様は、どの概念実証が機能するのか、実際に意味があるのは何か、そうでないのは何かを実際に実験していました。

2024 年になると、実際に本番環境に移行するには何が必要かが理解され始めました。そうなると、どのモデルがどのユースケースで機能するかを見つけるのは大変な作業であることが判明しました。そして、必要なのは 1 つのモデルではありません。数多くのモデルが必要になります。そして、それを費用対効果の高い方法で行う必要があります。適切なガードレールなども必要ですし、エージェントなども機能しなければなりません。

だからこそ、Bedrock では、私たちは、このバケットのあらゆる層でイノベーションを行ってきました。モデルの多様性という観点からは業界初で、「ローンチ」が意味することは 1 つのモデルだけでのローンチではありません。さまざまなモデルでローンチすることになります。当時、その理由は弱みだと思われていました。

実際、RDS は単一のデータベースでのローンチではありませんでした。複数のデータベースでローンチしました。その理由は、デベロッパーは自由にイノベーションを起こしたいと考えているというのがこの業界の常だからです。そして、デベロッパーは、データベースとモデルにも選択肢が必要で、ツールにも選択肢が必要だと考えています。

今日の AWS があるのは、デベロッパーにツールや選択の自由を提供することを常に目指してきたからです。Bedrock では、その点を強化しました。しかし、私たちはモデルだけにとどまらず、実際にすべてのツールを提供した結果、多くのイノベーションが見られました。

私のお気に入りは、もちろんデータオートメーションの分野です。私たちの多くは、実際にはまったくアクセスできない状態の大量のデータを取り扱っています。そして今では、コードを記述しなくてもすべての非構造化データに対応する生成 AI 搭載 ETL があります。その点は大きいと思います。

そして、私が考えるもう 1 つの大きな要素は Q Business です。前にもお伝えしましたが、私は、ある時点でチームとビジネスを管理するようになったエンジニアです。その理由から、ビジネスに関連する多くの質問をします。料金設定など、色々なことに取り組んでいます。私はスプレッドシートが苦手です。私の財務チームはすばらしい仕事をしてくれて、表の処理を魔法のように行ってくれています。

私としては、スプレッドシートではなく、Python や Polcode を記述して財務チームがやっていることを実現したいと思っています。それが私のやり方です。しかし、今日 Q シナリオでできることは驚異的です。ビジネス上の複雑な質問への回答やシナリオ分析はスプレッドシートを使って 3 週間を要していましたが、この分野で Q を使えればゲームチェンジャーのようなものになります。

同じことがデベロッパーにも当てはまります。コーディングアシスタントの競争では、Copilot などいずれのアシスタントでも、デベロッパーは 20% を問題に費やしています。デベロッパーは、純粋に新しいコードの記述に 100% の時間を費やしているわけではありません。それはほとんど都市伝説です。そうであればいいのですが、

実際には、ドキュメントの作成、ユニットテスト、コードレビュー、そしてパフォーマンスエンジニアリング、運用調査に相当の時間が費やされています。では、どうすればデベロッパーの時間を 100% 有効に使うことができるようになるのでしょうか。残りの 80% を解決する必要があります。それが、私たちがすべてのローンチで Q を使ってやってきたことです。これらは私のお気に入りで、Amazon で既に実現しています。

実際に Java のソフトウェアアップグレードをすべて Q で行った所、最初の 7 か月だけで デベロッパー4,500 人年分を会社に還元できました。その時の生産性向上について考えてみてください。もっとお話することがありますが、この辺で止めておきましょう。

Jonathan Allen:
そうですね。その 4,500 人年という数字を聞くと、「本当なのか」と疑いたくなります。しかし、データを見て、多くのサイクルも経て、そしてアンディー ジャシーがそれについて話しているのを見ると、「それは本当の数字で、大きな数字であり、本当に重要なものだ」ということがわかります。

Jonathan Allen:
これで、私とあなたは、生成人工知能を繰り返して実際の問題を解決した多くのお客様と連携します。昨日、アンディは、避けては通れないイテレーションについて本当に雄弁に話をしてくれました。私たち 2 人は、多くのお客様のジャーニーを見てきました。私の方は 99% まで進んでいますが、ハルシネーションのため一時停止しています。

Swami Sivasubramanian 博士:
そうですね。

Jonathan Allen:
明らかに、Amazon では非常に多くの科学を行っています。そして、その中で私たちが成し遂げた進歩についてお話しいただければと思います。

Swami Sivasubramanian 博士:
この分野については、LLM で何ができるかを考えると想像力を掻き立てられます。しかし、私たちの多くが時に忘れがちなのは、結局の所、これらは非常に確率的なモデルであるということです。そして、たとえそれが 1% の確率で間違っていたり、不正確だったりしても、実際に何かを生成することになります。特に規制の厳しい業界では、それが本稼働の妨げになる可能性があります。

そこで、この問題を検討したときに、「これらをより確実に根付かせる最善の方法は何か」と実際に疑問を投げかけました。私のチームは、自動推論と呼ばれる科学に投資しました。エンジニアが当社の IAM ポリシーツールとオーサリングを活用している場合、私たちが考えている方法でそのポリシーが適用されているかをチェックする自動推論機能が既に搭載されています。

これは、形式ロジックを使用して数学的に検証できるコンストラクトのようなものです。そして実際、自動推論によって得られる数学的証明を実際に生成 AI の創造性や表現と組み合わせてみたらどうかと考えました。その目的は、非常にクリエイティブでありながら、形式的な論理にも根ざしたものを作成することです。

そして、これこそが、ある意味で状況を変えることができると私が考える画期的なイノベーションの 1 つでした。なぜなら、これは将来、生成 AI のイノベーションを規制対象業界に導入する上での大きな障害の 1 つになるからです。そして、私たちはこのような分野で何社かのお客様と協力してきました。そして初期の結果は本当に有望でした。このようなモデルに、「これが絶対に違反してはならないルールと基本原則です」 というドキュメントをガードレールとして渡すと、LLM による違反を防止するガードレールとして機能するセマンティックモデルが構築されます。

そして、LLM が不正確な応答を生成した場合、LLM に「もう一度やってください。これに違反しています」と指示します。すると、突然すべてが大きく飛躍します。考えてみると、このような手法は Java のアップグレードでも用いていました。形式的論理について考えると、それは新しいことではありません。これこそが、今日の私たちのコンピュータをコンパイラーなどによってさまざまな方法で動かしているものです。

それが私たちがやっていることであり、とてもワクワクしています。もちろん、機械学習ベースのイノベーションは他にもたくさん起こっています。そして、Nova やその他さまざまなものをどのように構築したか、詳しく説明できます。しかし、これは業界が気づいていないことだと思います。

形式的な論理は確実性がすべてであるのに対し、生成 AI は創造性を解き放ち、不完全さを受け入れることがすべてなので、いわば陰と陽の関係にあるものだと私は考えています。そして、実際にこの 2 つをうまく組み合わせれば、すばらしい結果が得られると思います。

Jonathan Allen:
確かに規制の厳しい業界では、数学的な証明はかなり確立されていると思います。しかし、導入される自動推論の要素は、お客様の意見を聞いてみると、すぐに採用されるものだと思います。そのことにとてもワクワクしています。

私は、Amazon に入社する前、この部屋に顧客として来たことがありますが、学んだ教訓について伺いたいと思っていました。あなたは Amazon に長く在籍され、Amazon 全体で多くの機械学習と生成人工知能の取り組みに携わっていらっしゃいます。

このグループのために、これらの取り組みの実現を支援してきた中で得られた最たる教訓をいくつか挙げてもらえませんか。ここにいらっしゃる皆さんに、知らずに同じ過ちを犯してほしくないというようなことや、避けるべきことを話していただければと思います。

Swami Sivasubramanian 博士:
難しいですね。最先端のテクノロジーを扱う際、私たちのような組織のオーナーやプロダクトオーナーは、いくつかの間違いを犯します。つまるところ、エンジニアから CXO レベルまで、それを実際に使って試してみるのに十分な時間を費やしていません。

テクノロジーを本当に理解し、採用し、そして実際に実験しない限り、そのテクノロジーで実現できるパワーと可能性に気づかないのではないでしょうか。その点が見過ごされている気がします。そこで私は毎週、自分に対して設定したルールを必ず実行するようにしています。

少なくとも 3～4 社のお客様と直接会い、少なくとも 3～4 件の研究論文を個人的に読むことです。これが 2 つのルールです。チームにも伝えています。週末には、趣味でコードを記述したり、娘と一緒にロボット工学プロジェクトのためのコードを記述したりしています。そうすることで、理解を深め実際に試してみる時間を確保しています。

Jonathan Allen:
なるほど。何らかの強制力を伴うルールですね。

Swami Sivasubramanian 博士:
そうですね。そうしないと、地に足がつかないレベルでの運用につながります。

次に言いたいのは、イノベーションのペースが非常に速いため、通常、私たちが大規模に組織して管理するメカニズムが実際には機能しなくなった場合、チューニングが必要になるということです。テクノロジーのイノベーションのペースが 5 年前に比べて、突然 10 倍速くなったとき、

プログラムの管理やプロジェクトの設計に関わるすべての既存のメカニズムがイノベーションを起こしたいと考えるペースには追いつかなくなります。そのため、細部にまでこだわらない別の管理スタイルが必要です。そして、実際に製品を設計する人やコードを記述している人などにたどり着くまでは、必ずしもすべての階層のマネージャーの参加を必要としない場合もあります。そういうわけで、この 3 年間で自分のスタイルをかなり劇的に変えました。

そして 3 つ目は言うまでもなく、Amazon の DNA です。お客様の問題と達成すべきビジネス目標を起点として、通常とは反対の流れで取り組みます。結局のところ、生成 AI、AI、データに情熱を注いでいますが、それはお客様やビジネスのために何かを解決するための手段でもあります。

だからこそ、深層学習の初期段階でも、生成 AI の初期の頃でも、私たちは非常に多くの概念実証を行いました。その多くは、緩やかに苦痛を伴いながらお蔵入りになりました。投資収益率の観点から、どれがビジネスに本当に影響を与えるのか、実際にはわからなかったからです。

そして、ビジネスへの影響こそがこれまで以上に重要になります。特に生成 AI の分野ではコストが非常に高くなるからです。そして、私のローンチを見たかと思いますが、ほとんどはどのように大規模に物事を管理するかに関するものです。SageMaker HyperPod のタスクガバナンスをご存じであれば、これは Amazon にとって大きな教訓であることが理解できると思います。去年と同様に、私たちは多くの生成 AI プロジェクトを手がけました。

推論、トレーニング、ファインチューニング、実験と呼んでも構いません。私たちは、プロジェクト間でリソースを自動的に移動するシステムを社内で構築しました。推論のすばらしいところは...「すばらしい」は適切ではありませんね。推論の難しい所は、例えば、ショッピングエージェントがピーク時に 1000 台の Trainium2 インスタンスを必要とするとします。ただ、夜間にはそれほど多くの買い物客はいないため、このインスタンスをアイドル状態のままにしてはおけません。理想的には、トレーニングや実験の微調整など、時間があまり重要視されないワークロードに割り当てたいと思うはずです。

これには積極的なリソース管理が必要でした。そこで、最終的にシステムを構築することになりました。そして、実際に多くのお客様、特に CEO と話をした所、「これには多額の資金を注いでいますが、使用率はそれほど高くありません。なぜそうなったのでしょうか」という声が聞かれました。そして私たちの回答は、「これが私たちが社内でやっていることです」でした。すると、「どうして SageMaker でやれないのか」という質問が返ってきました。

これは大きな教訓でした。生成 AI を大規模に実施するには、コスト管理に非常に長けている必要があります。だからこそ、超強力なタスクガバナンスだけでなく、モデル蒸留により推論でスケールすることにも注目が集まったのです。また、実際にはインテリジェントなプロンプトルーティングなどもあります。これらは私たちが社内で使用している手法です。なぜなら、特に生成 AI プロジェクトは、利用率とコストのあらゆる改善が本当に重要となる規模に達しているからです。

Jonathan Allen:
昨日、あるお客様と話をしていた際、珍しいことではないのですが、お客様は生成 AI でやりたいという案件を 100 件お持ちでした。そのうちいくつか選んだのですが、その 1 つか 2 つでもうまくやっていくのに苦労しています。ご存じのように、障害になるものがあります。

Jonathan Allen:
クラウドへの移行とモダナイゼーションの初期の頃、そして現在でもそうであるように、私が顧客として感じたのは、スタンドアップに近づきつつあり、障害を取り除くことが非常に重要であるということでした。しかし、こうした生成 AI の取り組みで、これら 1 つか 2 つのことを特定したとしたら、それは具体的にどのようなものでしょうか。初期の実験を実際に実施して本稼働への移行を図るお客様には、どのようなことをお勧めしますか。

Swami Sivasubramanian 博士:
プロトタイプから本稼働までの道のりは、非常に細心の注意を払って、実際に何が機能し、何が機能しないかを確認することに尽きると思います。これが 1 つ目のポイントです。

興味深いのは、これらの LLM です。LLM を実際に導入すると、特にこのようなプロジェクトがお客様の目の前にある場合、これらのプロジェクトが本当に共感を呼ぶことがあります。時に、ガードレールをやり過ぎてしまうこともあります。例えば、「トピックに関する質問は受け付けないようにして、これは例外にする」とした場合、チャットボットは、突然、ルールエンジンを記述した 5 つの質問にしか回答できなくなります。

ですから、バランスを取る必要があります。実験を続けないといけません。そのため、特に本稼働へと規模を拡大するなら、イテレーションのペースが非常に重要になります。しかし、だからこそ、Bedrock のいくつかのツールや、ガードレールなどを繰り返し調整できる機能が重要になってきます。

そして、推論のコストは非常に大きな問題です。そして、私たちは、この点について数多く実験し、触れてもきました。そして 3 つ目は、例えば、コンタクトセンターの自動化やその他さまざまなことを行うアプリケーションのように、生成 AI を 1 つの主要な構成要素と捉える場合があるという点です。

このような生成 AI アシスタントは、実際にはデベロッパー以外のユーザーやビジネスユーザーがそのデータや分析に迅速にアクセスし、実際にデータドリブンの意思決定を行えるようにするという、ゲームチェンジャーのようなものだということを忘れがちです。

現在、Amazon のビジネスの多くには、カテゴリバイヤーや広告に携わっている人など、技術者以外の人がいます。この人たちは実際に Q のようなテクノロジーを導入し、データレイクにアクセスして分析を推進することができます。意思決定のスピードが大きく加速するので、ある意味で本当に大きなゲームチェンジャーだと思います。

Jonathan Allen:
今朝は何人かのお客様が登壇してすばらしい話を披露してくれました。私がお客様と仕事をしているとき、これらの構成要素を組み合わせると驚くほどうまくいきました。

そのため、Amazon Q for Connect は重要な違いをもたらすことができます。実際にコンタクトセンターのエージェントを務めるという本当に大変な仕事が少し楽になりました。これは大いに役立ちました。今朝は、検索拡張生成 (RAG) に関する発表があったかと思います。エージェントの仕事をさらに加速させられるのはとてもエキサイティングです。

Jonathan Allen:
頭に浮かぶ 2～3 人の「予想の斜め上を行く」お客様を挙げるとしたら、どのようなお客様ですか。

Swami Sivasubramanian 博士:
お客様との一般的なパターンを見てみると、いくつかのカテゴリーに分けられると思います。1 つ目のカテゴリーは、生成 AI を使ってまったく新しい製品や顧客体験を生み出すお客様です。Autodesk の Eco のようなもので、生成 AI を使って 3D デザインを実質的に再考しています。その業界にとってステップチェンジャーであり、ゲームチェンジャーになります。それは大きなことであり、ある意味でトップラインを改善するようなものです。

2 つ目は、生成 AI を使用して顧客のためにより速く、より安く、より良いサービスを提供できるようにしているお客様です。住宅ローン申請のワークフローを自動化するにはどうすればよいか、これは Rocket が話していましたよね、あるいは、どうすれば顧客により早くサービスを提供できるかと考えるお客様です。これはほんの一例です。そのようなカテゴリーは非常に、非常に重要です。最低ラインを向上させるようなものだからです。

そして 3 つ目のカテゴリーは、既にイノベーションを起こしているお客様です。私たちは巨大なソフトウェア開発チームの管理も行っています。さらに 5 人のお客様をステージに迎えてお話することもできますが、3 時間にわたる基調講演になるでしょう。多くのお客様の共感を呼んでいるもう 1 つの点は、ソフトウェアエンジニアの生産性を 5 倍に高める能力です。

そして、私たちはまさにその最前線にいると思います。特に、Q で行っていることは、すべて 1 つの側面だけでなく、あらゆる側面に焦点を当てています。そして、それは特に私たちが行っていることに対して、本当にお客様の共感を呼んでいることです。Q は業務の調査を支援しているように、ユニットテストや文書化も支援しています。あらゆる側面がゲームチェンジャーになるでしょう。

言うまでもなく、Q はソフトウェアコード生成において現在文字通り世界一です。SWEbench.comでチェックすると、それが最高のアシスタントであることがわかります。しかし、私にとって、それは生産性のパズルの一部にすぎません。

Jonathan Allen:
そうですね。さて、今朝あなたが触れたことの 1 つについて、もう少し深掘りしたいと思います。仰ったように、業務データストアであるか、並列処理エンジンであるか、データレイクであるかにかかわらず、1 つの企業にはさまざまなデータソースがあります。生成人工知能向けにデータを準備するにはどうすればよいでしょうか。

Swami Sivasubramanian 博士:
これは非常に興味深い課題の 1 つだと思います。社内外を問わず、多くのお客様と仕事をしていたとき、次のことがわかりました。人々が生成 AI に興奮していたとき、昨年と今年の初めに分かった目を見張るようなことの 1 つは、生成 AI と RAG がほとんどすべてテキストデータでしか機能しないということでした。データウイルスやデータレイクにはほとんど使用できませんでした。ほとんどのマルチモーダルコンテンツにも使用できませんでした。

つまり、実際には、お客様が本当に望んでいた生成アプリケーションのほとんどが、自然言語から SQL への変換を行う独自のカスタム SQL エンジンを実際に構築するか、生成 AI の ETL を構築しなければ実現できないということです。お客様は自分が作りたいものを実際に作るだけではなく、他にもたくさんのことをしていました。これが、今では「単純な RAG 問題だけでなく、すべてのデータの問題を解決しよう」と言われるようになった所以です。

そこで、私たちは、Q と QuickSight が行うことを実際に作成できるように、構造化データ検索を構築する機能に絞って開始しました。このようなエクスペリエンスを実現する場合、例えば、CS チャットボットを自分で作成して、リレーショナルデータベースなどからデータを取得し、「最後に注文した品はどうなっているの?」などのお客様からの質問に答えられるようにしたいとします。今ならそれができるし、可能です。

また、Bedrock のデータオートメーションを利用すれば、PDF 形式のマルチモーダルコンテンツを画像や動画などに変換し、従来の構造化データの場合と同様に ETL プロセスを自動化できます。コードは一切必要ありません。そして、これらは本当にゲームチェンジャーになるでしょう。

しかし、非常に重要なのは、これらは単なるツールであるということです。その他さまざまな側面に対するガバナンスについて、現在のデータ戦略が引き続き必要です。この点で、SageMaker Catalog のサポートを行いたいと考えています。カタログ作成、編成、ガバナンス、発見のすべてを組み合わせて SegaMaker Catalog に組み込む予定です。

Jonathan Allen:
なるほど。セキュリティと同様に、これはすべてのユーザーにとって常に最優先事項です。コストです。

Swami Sivasubramanian 博士:
そうですね。

Jonathan Allen:
コストです。絵に描いた餅は必要ありません。そうして、その違いを生み出したいと思っています。私たちは、新規のお客様を開拓したいと考えています。当然のことながら、コストはオーディエンスの皆さんにとって非常に大きな懸念事項です。一番のヒントは何ですか。

Swami Sivasubramanian 博士:
私が一番に言いたいのは、生成 AI のプロジェクトがあり、チームがデモを見せに来たら、常に最も有能なモデルでデモをするだろうということです。しかし、これは経済的にまったく機能しない最も費用のかかるモデルだという説明は一切ありません。コスト削減であれば、ユーザー 1 人あたりのドル換算で 5 USD 程度です。しかし、運用コストが実際に 5 USD に近い場合は、役に立ちません。

ですから、自分がやろうとしていることのユニットの経済性を詳しく調べることが非常に重要だと思います。そして、それを大規模に行う場合、「コスト上の制約を実際に満たしながら、精度の基準を確実に満たすようにするにはどうすればよいか」と考える必要があります。これが、私たちがモデル蒸留のような技法を構築した理由です。つまり、コストのかさむ大きな教師モデルは、当然、ユースケースに合わせて小規模なモデルのトレーニングも行えます。

同じことです。大規模モデルは 8 つの博士号を持つ天才のようなものだと例えることがありますが、ソフトウェアの記述方法を解いてもらうのに 8 つの博士号を持つ人は必要ありません。コードプログラムなどを記述するには、私のように 1 つのコンピューターサイエンス博士号を持つ人間で十分です。あらゆる分野の専門知識を取り入れて、実際にそのユースケースの解決方法を教えればよいのです。モデル蒸留はゲームチェンジャーになるでしょう。

2 つ目は、実際には HyperPod のタスクガバナンスです。多くのプロジェクトでは、推論へのクロストレーニングが今でも GPU で直接行われるか、Trainium で行われるケースが増えています。約 90% ではないにしても、使用率をそれに近い値にするのが理想的です。そして今、多くの場合、そうなってはいません。これは本当に重要なことです。私たちが社内で特に注力しており、皆さんにぜひ注目していただきたいことがあります。これによりコストを管理するメカニズムを構築することができます。

Jonathan Allen:
なるほど。もう少し詳しくお聞きしたいのですが、将来何が起こると思いますか。ジェフ ベゾスは、この質問をされるたびに、「変わらないものを軸に戦略を立てよ。選択肢はより多く、価格はより安く、配達はより迅速で確実に」と言っていたことで有名です。

しかし、今後 12 か月でこれがどうなると思うか、もう少しお話しいただけませんか。

Swami Sivasubramanian 博士:
それを引用しようとしていた所でした。

Jonathan Allen:
ええ、笑えますよね。

Swami Sivasubramanian 博士:
それが私が言おうとしていたことで、ジェフも私によく教えてくれました。それは興味深い質問とは言えない、興味深い質問というのは、「何が変わらないのか」ということだ、と。少し楽しい話をしましょう。冗談で楽しませるのではないのですが。

重要なのは、ほぼ 3 つの P カテゴリーに入れたことだと思います。MBA のマーケティングの 3 つの P とは違います。去年はプロトタイプ (P-rototypes) がすべてで、今年は本稼働 (P-roduction) への導入が中心でした。来年は生産性 (P-roductivity) が重視されるでしょう。

そして実際には、組織内のあらゆる分野の生産性が向上する前例のない段階になると思います。そして、これらのテクノロジーを実際に採用し、従業員の生産性を 5 倍、10 倍にするために自社の業務を一新した企業は、イノベーションをより迅速に進めることができます。採用しない企業は遅れを取ることでしょう。

私にとって、それは基本的なことの 1 つになります。生成 AI アシスタントを採用するかどうかということではありません。オフィスツールなどにアシスタントを導入することでもありません。それは面白いかもしれませんが、もっと重要なのは、根本的な業務改善であり、変革です。

そして、解決したくない問題を解決するのです。私たちは皆、非常に難しい課題に取り組むのが大好きで、ありふれた挑戦は好きではありません。例えば、自動切り替えが実現した今日、電話局で電話を手動で切り替えなくなったことに対して不平を言う人はいません。皆、その仕事をする必要がないことに本当に感心しています。

しかし、その間、その移行を管理することは容易ではありません。それはまるで人間の変容の問題のようなものです。そして、リーダーである私たちは、組織をその中で効果的に導かなければならなかったと思います。そうすれば、本当に効率的に物事を行う方法を再発明できるようになります。しかし実際、すべての従業員にこのようなテクノロジーを採用してもらい、私たちの仕事ややり方を改革し、より良いものにし、良い方向に方向に向かわせる必要があります。

Jonathan Allen:
すばらしいですね。Swami、30 分お時間をいただき、見聞をお聞かせいただきありがとうございます。大変感謝します。ご参加いただきありがとうございました。

Swami Sivasubramanian 博士:
こちらこそ、お招きいただき、ありがとうございました。

Jonathan Allen:
ありがとうございます。

Swami Sivasubramanian 博士:
ありがとうございます。

今すぐ聴く

今すぐ聴く

今すぐ聴く