CTO の視点: エージェンティック AI に関する CEO との会話

Arvind Mathur:
この Executive Insights のエピソードにご参加いただきありがとうございます。AWS の Enterprise Strategist の Arvind Mathur です。今日、同僚の Matthias Patzak と話すのを楽しみにしていました。Matthias が最近投稿した LinkedIn でブログが多くの議論を呼んでいます。今日は、その投稿の内容と、なぜそれがこれほど多くの議論の火付け役となったかを取り上げます。ようこそ、Matthias。  

Matthias Patzak:
ご紹介ありがとうございます。仰った通り、投稿は多くの会話の火付け役となりました。多くのコメントをいただきました。

Arvind Mathur:
そして何よりもこれは、そのような思考を促すコメントによって生まれた機会なので、非常に貴重です。

テクノロジーリーダーは、この新しいトレンドに注目すべきでしたが、十分な注意が払われていなかったので、多くの関心を呼んだのだと思います。そして、CEO やエグゼクティブにたずねられると、多くの人はいつも及び腰になります。このことに多くの人が共感を示し、多くの関与を生み出したのだと思います。 

Matthias Patzak:
そうですね。また、CTO に「このエージェンティック AI って何?」と聞かずにはいられない CEO を描いた LinkedIn の投稿では、その点が多くのコメントの火付け役になったと思います。 そして、今でも多くの組織で、CTO、CIO、エンジニアリング担当副社長が、現在の優先事項すべてにキャパシティを分散させて、日常業務に忙殺されているの見られます。そして、そのような組織には本当にキャパシティ、つまり精神的なキャパシティだけでなく、新しいテクノロジーを実際に試すための身体的なキャパシティや予算もありません。 

Arvind Mathur:
本当にそうだと思います。そして、状況は急速に変化しているので、CTO やテクノロジーリーダーがこの点にもっと時間をかけることが今まで以上に重要だと思います。さらに重要なのは、これらの機能の多くが一般に広く浸透し、ビジネスリーダーも以前に比べて関心を持つようになったので、これらの質問が出てきたときに及び腰になるわけにはいきません。あなたが提案したように、詳細を理解して実際にビジネスリーダーに紹介するには、ある程度のキャパシティを投資する必要がありますね?

Matthias Patzak:
そうですね。

Arvind Mathur:
それでは、実際にこれにアプローチする方法についての推奨事項を段階的に見ていきましょう。それが会話を生み出しました。いくつかの提案はとても刺激的なので私は大好きです、そのいくつかを取り上げて掘り下げてみたいと思います。

Matthias Patzak:
私が実際に推奨した最初のステップは、それをビジネスの会話に変えることでした。その理由は、ほとんどの場合、CTO や CIO は新しいテクノロジーを理解したいだけだからです。彼らはガードレールを理解し、コストを理解したいと思っていますが、Amazon の顧客から逆算して作業するという考え方から本当に検討しているわけではありません。つまり、彼らは実際にビルの外に出ているわけではなく、顧客やユーザーを実際に観察しているわけでもありません。彼らは顧客のニーズや顧客の問題をあまり理解しておらず、IT の専門家としてビジネスの同業者とビジネスの会話をすることができません。そして、この LinkedIn の投稿で私が最初に指摘したのは、議論をビジネスの会話に変えることです。

Arvind Mathur:
本当にそうだと思います。それはビジネスの会話である必要があると思います。なぜなら、これはビジネスに影響を与える機会だからです。これは単なるバックエンドの改善ではありません。ここで記事が議論を呼んだ会話は、10% のアイデアだけでなく 10 倍のアイデアが見つかったということだったと思います。先に言ったように、これはとても刺激的なので私は大好きです。特にエージェンティックでは、過去の他の多くのテクノロジーよりも、これらの 10 倍の機会を見つけることが可能になりました。しかし、現実には、私たちの生活の中で、おそらく 90 個の 10% 改善のアイデアに取り組み、これらの 10 倍のアイデアのうち 5〜10 個に取り組んでいます。なぜ 10 倍のアイデアに力を入れているのですか?

Matthias Patzak:
一般的に、組織におけるこれらの漸進的な反復的改善が、組織を成功に導くものだと私は信じています。なぜなら、そうすれば私たちが組織を学んでいることになるからです。自分のビジネスやテクノロジーについて理解しているならば、週ごと、毎日、1%、2%、3%、そして 10% ずつ改善されます。しかし、生成 AI、一般的な AI 、そして現在エージェンティック AI についての議論でわかったことは、多くの組織は社内の効率を改善することだけを考えていて、ビジネスモデルを方向転換する方法についてはあまり考えていないということです。私の考えでは、これから何が起こるかというと、これは 10～20 年前にデジタルネイティブ企業が出現し、モバイルファースト企業ができたときに見たことです。私たちは、生成 AI ネイティブ企業と、エージェンティック AI 組織が出現するのを目にするでしょう。そうなると、現在のビジネスモデルの中で仕事をしただけでは、先がなくなるかもしれません。

Arvind Mathur:
そうですね。同感です。これは、10 倍の機会を探し始めるのが早ければ早いほどよいということです。このような状況で私が唯一注目できるのは、それをセットアップする方法です。及び腰になっているところにビジネスリーダーがやって来た場合、ビジネスリーダーもアイデアを思いつくことがあります。私が観察してきたのは、これがまさに状況のダイナミクスであり、状況がどうなっているかを読まなければならず、「エージェンティックの件だけど、こういった問題が懸念に上がっている。エージェンティックを使って解決できるかな?」というような CEO がもたらしていたかもしれないアイデアに基づいて迅速に作業して、結果を示す必要がある場合もあります。 通常、それを実現する方法をすばやく見つけ出すことは非常に役立ちます。次に並行して、それが自信と信頼を築いたならば、「これは単なる小さな改善の機会ではありませんね。実際、これを使ってできることはもっとたくさんあります」というように話を始めます。 チャットの会話でもこのトピックについての優れた議論があったことは知っていますが、私はこのアイデアが大好きです。2 つ目に移りましょう。

Matthias Patzak:
2 つ目は従来のアドバイスですが、ここでは技術チームではなく変革分隊を結成すると言い換えました。しかし実際のメッセージは、従来の IT サイロの中で作業するだけではダメだということです。確かに、まず新しいテクノロジーのコアコンセプトを理解する必要があります。しかし、どうしてもプロトタイプを提供したい場合、そしてビジネス機会について本当に学びたいのであれば、営業部長、業務担当者、財務担当者、法務担当者も会議室に呼ぶ必要があります。単なる監督としてではなく、機能横断的なトランスフォーメーションの話し合いとしてです。なぜなら、これは単なるテクノロジープロジェクトではなく、ビジネスの改革だからです。

Arvind Mathur:
そして、会話の中でこれについての完全な一致と合意があったと思います。特にエージェンティックのようなものについては、私も同じように強く感じます。また、10 倍のアイデアに焦点を当てたいのであれば、それらは社内のテクノロジー改善のアイデアではありません。それらは、顧客が当社の製品やサービスをどのように体験するか、当社の製品とサービスで何ができるかなどを再考する機会です。そのため、幅広い変革が必要です。

Matthias Patzak:
顧客との会話の中で、それをどのように認識し、観察していますか? あなたは変革分隊の部門横断的なチームで働く組織を本当に目にしていますか? あるいは IT のサイロを見たことがありますか？

Arvind Mathur:
明らかに幅広く見られます。そのため、これを理解し、これをテクノロジープロジェクトとして行うだけではうまくいかないという事実を経験して、より成長した組織もあります。しかし、テクノロジーのようなプロジェクトにまだ取り組んでいる組織は数多くあります。そして、CTO やビジネスエグゼクティブとの会話で私たちが果たす役割は、彼らが理解を深め、多機能のクロスサイロ機会としてこれに注目するのを手助けすることです。そして、私自身の経験からも、これについて個人的にすばらしいことを学びました。私が保険会社にいたときに、私たちは引受や請求などのプロセスを変革しようとしていました。それらは運用組織に属していますが、それは運用だけでなく、販売、商品、リスク、顧客体験でもあります。変更を行う場合は、これらすべてに取り組む必要があります。私たちのケースでは、3～4 週間の請求期間を 1 時間未満に短縮しようとしていました。これは劇的な変化であり、社内の運用プロセスの改善だけでは実現できません。ですから、仰る点には完全に同意します。

Arvind Mathur:
わかりました。それではステップ 3 に進みましょう。

Matthias Patzak:
ステップ 3 で私が推奨したのは、2～3 個の関連するユースケースを選び、迅速に行動することでした。複数のパイロットを連続ではなく並行して実行させること、そしてガードレールを使ってスピードを上げることが本当に重要です。そして、このような実験を行う場合はガードレールが重要で、これは完璧な計画を立てることには向いていません。チームの同僚である Jake Burns が「準備ができたら始めるのではなく、始めることで準備を整えよう」とよく口にしていました。 そして、これは私が本当に大好きなことで、特にエージェンティック AI で推奨していることです。また、迅速に行動し、複数のパイロットを並行して実行することには別の側面があります。なぜなら、それは新しいテクノロジーであり、新しいユースケースだからです。また、これは実験なので、実験の 70% が失敗することを想定する必要があります。

そのため、パイロットを連続的に実行した場合、1、2、3 回目は失敗し、ちょうど 4 回目の反復、つまり 4 回目の実験が成功する可能性があります。だからこそ、CTO として、キャパシティ、つまり精神的なキャパシティだけでなく、予算の観点からだけでなく、人の観点からもキャパシティを確保して、複数のパイロットを並行して実行できるようにすることをお勧めします。そして、これについては多くの議論が交わされました。なぜなら、一部の組織にはこの要求がなく、このようなキャパシティがないように見えるからです。

Arvind Mathur:
あなたは先ほど、顧客との会話について触れましたが、これがおそらく一番の課題です。その理由は、このような立場に置かれたほとんどの CTO には、複数の大規模プロジェクトを並行して実行する能力がなく、したがって自信もないからです。しかし、躊躇する必要はありません。私は何か新しいことに自信を持っていたとき、実験をするのは気楽でした。多くの場合、実際には脚光を浴びていなかったことが多く、学んで、より早く始められるという自信を築くためです。

そして、ここで指摘しておくべき重要なポイントは、CEO と会話をする前に、すでにそれを行っておくべきです。小規模な実験を行ったことがあれば自信が生まれ、先に進んでその 10 倍のアイデアを見つけ、それらを並行して実行し始めることができます。私がとても気に入ったこの記事の中心的なポイントは、このような会話は、これを開始する CEO とはするべきではないということでした。先に実験を行って、アイデアを持って彼らのところに行くべきです。そうすれば、自信を持ってこれを推し進める準備が整います。

Matthias Patzak:
そうですね。それは実際には運用モデルの一部である必要があり、文化の一部である必要があります。

Arvind Mathur:
チャットで出てきた質問の 1 つは、「新しいものがたくさん出てきていて、エージェンティックがあり、ロボット工学が別の方向に進んでいて、コア AI があり、データがあり、データや分析機能を推進する新しい方法がある」などでした。今起きていることをすべて監視し、十分に実験して、積極的にビジネスリーダーのところに行けるようにするにはどうすればよいでしょうか? あなたが見つけたベストプラクティスにはどのようなものがありますか?

Matthias Patzak:
そうですね、実際にはいろいろ試したり、すべてのトレンドについての知識を得たりすることはできません。だからこそ、組織にもイノベーションやテクノロジーのレーダー能力が必要なのです。ソートリーダーの Pascal Finette が「Disrupt Disruption」という本を書いて、兆候、テクノロジー、市場、顧客の兆候の変化の見つけ方について語っています。そして問題は、どれくらいの頻度で兆候に遭遇するかということです。 特定のテクノロジーの兆候が頻繁に現れる場合は、すぐに実験する必要があります。だからこそ、実験のためのさまざまな作業方法も必要になります。

そのため、兆候によっては、金曜の午後に個人デベロッパー、デザイナー、またはプロダクトマネージャーがプロトタイプや実際の顧客と実験を行う場合もあります。その他の実験では、チームが 2 週間分の空きキャパシティを確保し、時間枠を設ける必要があります。つまり、2 週間あり、この 2 週間で何かを達成する必要がありますが、これ以上お金やキャパシティを投資したり、時間をかけたりすることはありません。ただし、兆候を見つけて、兆候に基づいて行動できる必要があります。また、これはおそらく最も重要な側面であり、いくつかの側面では一部の兆候を退ける必要があります。そのため、優先順位を付けられることが重要です。

Arvind Mathur:
そうですね、先ほど仰ったことは、私が個人的に実践し、皆さんにアドバイスしてきたもう 1 つの非常に重要な側面です。それは好奇心と実験の文化であり、それが最終的にイノベーションにつながるということです。そして、私自身の個人的な実践経験からも、チームや組織でそのような文化を築くと、戦略やアクションプランを具体的に設定しなくても、彼らは実験を行い、何が起こっているのか、何がレーダーに現れているかに目を光らせます。私が最も役に立った状況は、あるチームが私のところに来て、「Arvind、私たちはこのことを探求してきたから、ここには可能性があると思うよ」と言ったときでした。 それにより私は、ビジネスチームのところに行って、「見通しがつきました。これに基づいて行動する方法はありますか?」と言うことができました。 そのような文化があるなら、すごいことです。そうでない場合は、今日から構築を開始してください。なぜなら、今日の世界では、チームが自律的に進んでスキャンと実験を行わなければ、機会が訪れたときにこれを行うのは非常に難しいからです。

Matthias Patzak:
ええ、完全に同意します。そのために重要なのは、実験の成功と失敗を示すことができることです。そうしないと、キャパシティの一部、すなわちチームの一部が新しいテクノロジーを試して、実際にビジネス価値や機能を提供することからキャパシティを奪ってしまうため、プロダクトマネージャーやビジネスの同僚が最終的に苦情を言うことになるからです。だからこそ、成功を祝う必要があるのです。また、失敗した実験は実験の成功でもありますが、このことを組織内で祝う必要があります。そして、キャパシティを使って新しいテクノロジーやビジネスアイデアを試してもいいという文化を築きます。

Arvind Mathur:
すばらしい。ステップ 4 に進みましょう。

Matthias Patzak:
そうですね。ステップ 4 です。私の考えでは、そのコメントが本当に興味深いと感じたのはこの点でした。そしてアドバイスは、パイロットを試しながらスケールアップする分にお金を払うことです。そのため、魅力的なデモだけのプロトタイプを作成するのではなく、初日からエンタープライズ規模に対処できる本番環境対応のソリューションを構築します。エージェントにはさまざまなタイプがありますが、その中にナレッジワーカーのエージェントがあります。例えば、デスクトップ上のエージェントを使用してワークフローの 1 つを自動化するカスタマーサービスエージェントがいるとします。しかし、元 CTO である私は、頭脳を備えたマイクロサービスであるエージェントの方がはるかに興味深いと感じています。しかし、これらのエージェントをアーキテクチャの内部やアプリケーションに組み込むのは簡単ではありません。

そのため、イベントドリブンのアーキテクチャが必要です。適切なオブザーバビリティを確保できる必要があり、少なくともプロトタイプの初期には、人間をループ上とループ内に配置し、時にはループ外に配置する必要があります。そして、このエージェントを本番環境で使用していれば、エージェントの能力について学ぶことができます。トラフィックの 100% ではなく、ユーザーの 1%、トラフィックの 1% で、10 倍のアイデアを試しながら影響の半径を細かく制限できます。しかし、失敗の文化が欠如している場合、これは多くの人にとって理解するのが非常に難しく、自分の環境に取り入れるのが非常に困難です。

Arvind Mathur:
そして、ここで見ることは、前のポイントともうまくリンクしていると思います。実際には、実験の中にも段階があるということです。企業から完全に切り離された状態で実施している実験があるかもしれません。そして、それらのうちのいくつかが有望視され始めたら、まず IT の内部で実験を始めます。あなたが実際に説明したように、私はその点が気に入っています。サービスや API を通じて提供されるビジネスプロセスが既に存在し、その内部に頭脳が組み込まれているため、本番環境グレードのエージェンティック機能を構築する経験と快適さが得られます。10 倍のビジネスのサイロ間の機会について会話すると、自信を持って本番環境で複数のアイデアを並行して開始できます。とてもすばらしい点です。まずテクノロジーの内部でこれを始めることは、実験からイノベーションへのジャーニーの第一歩です。

さて、これについて作成されたコメントは理解できます。繰り返しになりますが、多くの人がこれをそのまま受け入れているわけではりません。彼らは早い段階で実験をすることが重要だと感じています。あなたが言ったように、影響の半径を小さくすることです。そして、ここで私たちが本当に強調しているのは、ビジネスの会話をする前にそれを行う必要があるということだと思います。これらの小さな影響の半径、魅力的なパイロット、プロジェクト、実験など、これらすべてを既に行っていれば、ビジネスの機会が訪れたときに迅速に行動できるようになります。その場合、実験をしているわけではなく、うまくいけば、その段階で 70% が失敗する状況を乗り越え、その段階でより一貫した機能を提供できます。

Matthias Patzak:
ええ、完全に同意します。だからこそ、人々は早い段階で新しいテクノロジーを実際に体験する必要があります。私が推奨するのは、パートナーを加え、AWS アカウントチームを加え、彼らに新しいテクノロジーを実際に体験する方法を示してもらうことです。

Arvind Mathur:
そうですね、ステップ 5 に進みましょう。

Matthias Patzak:
ええ、ステップ 5 ですね。考えるまでもないことですが、それでも議論することはできます。そのため、ステップ 5 はビジネスへの影響を測定することであり、技術的なメトリクスを測定することではありません。つまり、収益の増加、コスト削減、サイクルタイムの改善、コンバージョン率の変化を追跡しますが、精度やユーザーの適応率はモデル化しません。確かに、適応率に関するこれらの先行メトリクスが必要です。いくつかの品質メトリクスを知っておく必要がありますが、新しいテクノロジーを導入する理由は、新しいテクノロジーのためではなく、ビジネスプロセスを 10% 向上させるためか、10 倍のユースケースを提案できるようにするためです。だからこそ、本番環境に導入するすべてのソリューションを実際のユーザーで測定し、実際のビジネスへの影響を測定する必要があります。機能リストのボックスにチェックを入れるのとは違います。本当に言いたいのは、「この新しいエージェンティック AI で、ウェブサイトの離脱率を何パーセントでも引き下げることができました」ということです。

Arvind Mathur:
そして、この点については普遍的な合意があったと思います。これに関する私の個人的な経験だけを同じクレームプロセスアクセラレーションですぐに共有したいと思いました。当初、私たちがそのプロジェクトを行っていたとき、私たちはチーム内のさまざまな人を測定するという間違いを犯していました。そのため、運用チームには 1 つの運用指標がありました。私たちのテクノロジーチームには機能を提供するための他の運用指標があり、営業チームには他にもいくつかの指標がありました。そのため、その 10 倍レベルには達していませんでした。それは全員が同じ目標、つまり 3 週間から 5 分へと足並みを揃えたときだけでした。つまり全員の足並みが揃っただけでなく、実際にそれが創造性を駆り立てました。10 倍の成果を出すことを妨げている障壁があり、それに対する真にクリエイティブなソリューションが部門を超えて出てきたのです。したがって、実際にはこれは単なる測定物ではありません。これは、チームの足並みを揃え、10 倍の成果を出すことを妨げている非常に大きな障壁に集中してもらうためのすばらしい方法です。

Matthias Patzak:
はい、その通りです。足並みを揃える部分は本当に重要です。

Arvind Mathur:
これについての非常にすばらしい会話でした。これからも皆さんと関わり、より多くの意見を集めていけることを願っています。しかし、この会話から得た一番のこと、私の個人的な学び、そして皆さんに推奨したいことは、スキャンを始めることです。現在、多くの変化が起きています。何が可能かを先行して理解し、そのアイデアをビジネスリーダーに伝える必要があります。そのため、これに基づいた私の提案は、今すぐ AWSアカウントにアクセスし、アカウントチームと話をし、これらのツールの使用を開始して今すぐ構築を開始する方法を見つけ出すことです。

Matthias Patzak:
まったくその通りです。そして、あなたが使うべきツール、つまり Amazon サービスは、Amazon Bedrock AgentCore です。そのため、エージェントに関するさまざまなサービスがありますが、アーキテクチャにエージェントを配置するための中核となるのは Amazon Bedrock AgentCore です。そして、これはまさに、組織にできるだけ早く手に入れるよう私が推奨するサービスです。

Arvind Mathur:
すばらしいですね。構築を始めましょう。

Matthias Patzak:
構築を始めましょう。

今すぐ聴く

今すぐ聴く

今すぐ聴く