WEBVTT 00:00:00.760 --> 00:00:04.100 皆さん、MC65FMポッドキャストへようこそ。 00:00:04.220 --> 00:00:12.740 今日は、マイクロソフト365コパイロットのプロンプトエンジニアリングに関する、最も一般的な議論の一歩先へと進みます。 00:00:12.940 --> 00:00:19.940 組織がコパイロットを本格的に使い始めると、疑問はすぐに、どうすればより良いプロンプトを書けるか? 00:00:20.100 --> 00:00:28.780 から、どうすればコパイロットを、自社で実際に動いているアプリケーション、データ、業務プロセス、そして知識とつなげられるか? 00:00:28.780 --> 00:00:30.340 絵と変化するからです。 00:00:30.540 --> 00:00:34.420 そこで興味深くなってくるのが、コパイロットの拡張性です。 00:00:34.620 --> 00:00:43.760 本日のゲストは、スイスのAIとワードグループでビジネスアプリケーションコンサルタントを務める、マイクロソフトMVPのイバス・ハーベスト氏です。 00:00:43.940 --> 00:00:55.760 イバス氏は、マイクロソフト365、アジュール、ダイナミクス365、パワープラットフォーム全般にわたり、特にエージェントやカスタム開発を通じたマイクロソフト365コパイロットの拡張に注力しています。 00:00:55.760 --> 00:01:09.860 今回は、マイクロソフト365コパイロットの拡張性、コパイロットスタジオ、マイクロソフトアジュールアイファウンドリー、名称変更が頻繁ですが、マイクロソフトグラフ、カスタム開発、MCPSなどについて深掘りしていきます。 00:01:09.860 --> 00:01:13.740 それではイバスさん、MC65ポッドキャストへようこそ。 00:01:13.900 --> 00:01:15.160 みなさん、こんにちは。 00:01:15.400 --> 00:01:16.900 お招きいただきありがとうございます。 00:01:17.780 --> 00:01:21.300 ここに参加できて、本当に良い機会をいただきました。 00:01:21.540 --> 00:01:23.060 呼んでいただき感謝します。 00:01:23.600 --> 00:01:25.300 ええ、こちらこそありがとうございます。 00:01:25.940 --> 00:01:35.140 技術的な話に入る前に、あなたのこれまでの経歴や、どのようにしてマイクロソフトエコシステムに関わるようになったのか教えていただけますか? 00:01:35.580 --> 00:01:37.980 ええ、はい、そうですね、もちろんです。 00:01:38.180 --> 00:01:41.740 実は正直に言うと、私のキャリアはマイクロソフトの世界から始まったわけではありませんでした。 00:01:41.940 --> 00:01:44.540 私のキャリアはAppleの世界から始まったんです。 00:01:44.960 --> 00:01:50.920 Macプラットフォームのソフトウェアエンジニアとして働いていて、その後iOSなどに移行しました。 00:01:52.680 --> 00:02:00.440 そして、ずいぶん昔のことですが、15年か20年くらい前でしょうか、マイクロソフトの世界に飛び込みました。 00:02:00.920 --> 00:02:04.900 正直に言うと、最初はシェアポイントのキャリアからスタートしました。 00:02:06.080 --> 00:02:10.860 その後、クラウド、Azure、M365へと移行しました。 00:02:11.920 --> 00:02:23.100 オンプレミスのシェアポイントから始まり、その後あらゆるクラウドサービス、最終的にパワープラットフォーム、そして最近では全てのAI関連技術を扱っています。 00:02:23.760 --> 00:02:28.680 正直なところ、今やM365の大部分を占めていますからね。 00:02:28.680 --> 00:02:35.620 エージェント中心の転換期を迎えていますし、これが私のキャリアの概要です。 00:02:35.620 --> 00:02:46.690 私はソフトウェアエンジニアリングの世界でキャリアをスタートさせましたが、今では多くの人が忘れかけている言葉かもしれません。 00:02:46.690 --> 00:02:59.190 現在はあらゆるAI技術が存在し、活動や仕事の性質そのものがAIへとシフトしているため、20年前とは状況が大きく異なります。 00:02:59.190 --> 00:03:14.680 A、シェアポイントやグラフ、ダイナミクス、パワープラットフォームなどに関わってきたと伺いましたが、そうした経歴は現在のAI開発の時代に向けて、どのように役立っているのでしょうか。 00:03:17.410 --> 00:03:21.690 基本的には、私の経歴は非常に多岐にわたるものです。 00:03:24.130 --> 00:03:28.510 これまでキャリアの中で、数多くの製品に携わってきたからです。 00:03:29.290 --> 00:03:33.690 マイクロソフト製品だけでなく、それ以外の製品も扱ってきました。 00:03:33.690 --> 00:03:38.390 そのため、非常に幅広い技術やツールに関するスキルを持っています。 00:03:40.550 --> 00:03:43.870 これまでのすべての経験が強力な基盤になっています。 00:03:46.770 --> 00:03:53.790 今、AIは非常に広範なトピックであり、実現に向けたアプローチや技術が多岐にわたっているからです。 00:03:55.290 --> 00:03:59.630 エージェント型もあれば、ワークフロー中心のものなど様々です。 00:03:59.630 --> 00:04:08.150 ですから、正直なところ、これまでのすべての仕事で得たスキルが、現在のAIへの移行に向けた準備として役立っています。 00:04:08.550 --> 00:04:13.410 ローコードやノーコード、そしてプロコードのツールまで幅広く扱ってきました。 00:04:16.230 --> 00:04:25.130 A、これまでの仕事におけるあらゆる機会や経験が、AIの世界で強みを発揮するための優れたスキルを私に与えてくれたのです。 00:04:25.130 --> 00:04:32.130 なるほど。そして現在は、AIテストリードという立場ですね。 00:04:32.310 --> 00:04:35.390 AIテストリードとは、具体的に何をする仕事なのですか? 00:04:35.590 --> 00:04:38.390 ああ、それは実に良い質問ですね。 00:04:38.590 --> 00:04:40.810 多くの人から同じことを聞かれます。 00:04:42.810 --> 00:04:47.470 私の仕事は、機能要件を技術スタックに適合させることです。 00:04:49.730 --> 00:04:54.410 ビジネス分析が完了した段階で、私がリードを引き継ぎます。 00:04:54.410 --> 00:04:59.250 AIを活用するためのユースケースが定義された後の段階ですね。 00:04:59.510 --> 00:05:02.350 シナリオやユースケースの定義が完了しています。 00:05:03.170 --> 00:05:12.590 ビジネス分析全体が完了した時点で、私がそのニーズを受け取り、裏側の技術スタックと照らし合わせて調整するのが私の仕事です。 00:05:14.910 --> 00:05:21.750 その後、開発を開始する準備が整ったら、ツールやソリューションの実装全体を主導していきます。 00:05:24.840 --> 00:05:25.880 興味深いですね。 00:05:25.880 --> 00:05:39.790 実際、多くの企業が従業員に研修、特にプロンプトエンジニアリングの研修を提供していますが、なぜそれだけでは不十分だと言えるのでしょうか? 00:05:46.150 --> 00:05:49.750 今の時代、プロンプトエンジニアリングだけでいいという意味ですか? 00:05:50.270 --> 00:05:50.590 そうですね。 00:05:50.970 --> 00:05:54.230 ええ、なぜ、なぜ、なぜ、なぜ彼らは、 00:05:56.240 --> 00:06:02.640 なぜ、その、企業にとって、プロンプトエンジニアリングを教えるだけでは不十分なのでしょうか? 00:06:02.640 --> 00:06:06.080 ああ、なるほど、わかりました。 00:06:06.320 --> 00:06:07.380 ええ、そうですね。 00:06:08.760 --> 00:06:14.760 正直に言うと、先ほど申し上げた通り、今は多様なツールや技術があふれています。 00:06:14.760 --> 00:06:22.980 ある段階までは、AIが何をすべきかを理解し、多少のガイドをしてくれることもあります。 00:06:24.320 --> 00:06:32.520 しかし私としては、例えばアーキテクトやソフトウェア設計者の役割には、背景に人間が存在する必要があります。 00:06:32.520 --> 00:06:35.860 顧客の意図を理解しなければならないからです。 00:06:36.560 --> 00:06:40.960 基本的には、AIが顧客の状況を理解しきれないこともあります。 00:06:43.280 --> 00:06:49.880 全体像は見えていても、裏側ではプロンプトエンジニアリングに集中するだけでは不十分な場合があります。 00:06:52.650 --> 00:06:54.750 もっと多くの要素が必要です。 00:06:54.750 --> 00:07:09.450 舞台裏には、アーキテクトやソフトウェアエンジニアといった専門家、そしてシェアポイントやワンドライブ、あるいはセールスフォースといった情報技術に精通した人材が必要なのです。 00:07:12.010 --> 00:07:14.550 そうした技術のスペシャリストが不可欠です。 00:07:14.550 --> 00:07:20.350 なぜなら、AIは多くのことを理解できても、ガイド役に離れるからです。 00:07:20.950 --> 00:07:24.530 素晴らしい技術文書や機能使用書を作成できますが、 00:07:24.530 --> 00:07:28.990 それが適切かどうかを判断する人間が舞台裏に必要です。 00:07:29.310 --> 00:07:33.250 顧客のニーズを満たしているか、すべてを検証する作業があります。 00:07:33.490 --> 00:07:37.650 プロンプトエンジニアリングだけに集中していては、それは難しいでしょう。 00:07:40.450 --> 00:07:47.210 現時点では、スキルを習得する時間や投資の余裕がない場合の選択肢にはなり得るかもしれません。 00:07:50.530 --> 00:07:58.190 ですが正直なところ、ソリューションを構築するには、基礎となる技術の優れたスキルが不可欠だと私は考えます。 00:07:59.450 --> 00:08:00.870 ええ、その通りです。 00:08:01.330 --> 00:08:04.570 あなたはコパイロットの拡張性の専門家ですよね。 00:08:07.980 --> 00:08:15.480 標準のマイクロソフト365コパイロットはどこまでで、コパイロットの拡張性はどこから始まるのでしょうか? 00:08:18.270 --> 00:08:19.810 ああ、いい質問ですね。 00:08:19.810 --> 00:08:31.300 正直なところ、2年前にコパイロットがリリースされた当初の最初のバージョンでは、チャット機能は本当に最小限のものでしたから。 00:08:33.370 --> 00:08:42.770 基本的には、そうですね、チャットGPTのようなものでしたが、マイクロソフトはマイクロソフト365コパイロットを大きく進化させました。 00:08:42.770 --> 00:08:49.810 現在は様々な機能が備わっており、以前と比べて拡張性の意味合いが変わりました。 00:08:49.810 --> 00:09:06.980 以前はプラグインなどを開発していましたが、正直なところ今は、オーケストレーターをカスタマイズしたい場合や、ユーザーインターフェースをよりパーソナライズしたい場合、 00:09:07.420 --> 00:09:15.400 例えばエージェントをマイクロソフト365チャットだけでなく自社のウェブサイトにも統合したいといった場合に拡張が必要になります。 00:09:22.290 --> 00:09:29.170 つまり、裏側の仕組みをもっとカスタマイズしたいという時に、拡張性が求められるようになったのです。 00:09:29.170 --> 00:09:45.880 オーケストレーターのカスタマイズやインターフェースの調整、あるいはコパイロットチャットでは対応できない、あるいは回答できないような様々な側面をカスタマイズしたい場合などがそれに当たります。 00:09:51.960 --> 00:09:57.590 そして、多くの人がエージェントについて語っていると思います。 00:09:57.590 --> 00:10:15.300 ええ、それは、なぜこれほどまでに多くの人がコパイロットエージェントについて考えているのか、そしてなぜ全てをカバーする大きなコパイロットを一つだけ作らないのか、という点についてです。 00:10:18.050 --> 00:10:20.110 ええ、本当に興味深いですね。 00:10:20.110 --> 00:10:25.490 正直なところ、先ほど申し上げた通り、マイクロソフトは大きく進化しました。 00:10:28.110 --> 00:10:31.930 もし6ヶ月前であれば、エージェントが話題の中心でした。 00:10:34.490 --> 00:10:43.290 しかし今は、マイクロソフトがコパイロットの共同作業機能を導入したことで、正直なところ、多くのエージェントがその機能に置き換わるようになりました。 00:10:43.290 --> 00:10:48.750 ただ、私たちが今エージェントについて考えるのは、単に物事を整理するためです。 00:10:49.610 --> 00:10:56.550 現在はマルチエージェントモデルに移行しており、各エージェントがそれぞれのスコープと責任を担っているからです。 00:10:57.390 --> 00:11:02.630 一つの巨大なコパイロットを作らない理由は、単純にパフォーマンスの問題です。 00:11:03.510 --> 00:11:09.770 まず、指示やツールが膨大になると、パフォーマンスの面で収集がつかなくなってしまうからです。 00:11:09.770 --> 00:11:15.030 そして、現在のアーキテクチャはマルチエージェント化が進んでいます。 00:11:15.310 --> 00:11:22.090 コパイロットスタジオを使う場合もあれば、独自のコードやカスタム開発によるエージェントを使う場合もあります。 00:11:23.890 --> 00:11:30.070 しかし最近では、パフォーマンスの観点から各エージェントに独自のスコープと責任を持たせ、 00:11:30.570 --> 00:11:35.490 エージェントのアーキテクチャを明確にするマルチエージェントのアプローチの方が優れています。 00:11:45.410 --> 00:11:56.630 はい、ショーペンハウアーですね。 00:11:56.630 --> 00:12:11.320 そして、基本的なAIエージェントのアーキテクチャを見ると、私はこう考えます。 00:12:14.740 --> 00:12:18.720 いくつかのキーワード、総パスワードですね。分かりました。 00:12:19.840 --> 00:12:25.340 ですが、推論、ツール、知識、そして指示について考えなければなりません。 00:12:25.340 --> 00:12:31.740 これらは、AIエージェントのアーキテクチャにどのように組み込まれるのでしょうか? 00:12:34.300 --> 00:12:39.920 まず最初に考えるべき、回答しなければならない問いの一つは、目標は何か? 00:12:41.080 --> 00:12:41.900 ということです。 00:12:42.580 --> 00:12:44.900 そのエージェントの最初の目的ですね。 00:12:44.900 --> 00:12:54.010 基本的にエージェントのアーキテクチャは、ローコードアプローチかカスタム開発アプローチかによって大きく異なります。 00:12:54.010 --> 00:13:01.740 というのも、カスタム開発では全てを自分で管理する必要があるからです。 00:13:03.060 --> 00:13:08.700 つまり、セキュリティ、ホスティング、その他多くの様々な要素を管理します。 00:13:09.600 --> 00:13:12.620 ローコードアプローチでは状況が大きく異なります。 00:13:12.920 --> 00:13:16.900 指示を与え、ツールを選択することに専念できるからです。 00:13:16.900 --> 00:13:25.810 基本的に、ローコードでのアーキテクチャは今私が言ったほど単純ではありませんが、 00:13:26.270 --> 00:13:34.350 指示の定義、ツールの選択、必要に応じて他のエージェントとの接続が迅速に行えるため、非常に高速です。 00:13:38.400 --> 00:13:44.160 しかし、カスタム開発で独自の開発を行う場合は、話が少し変わってきます。 00:13:45.300 --> 00:13:49.240 例えば、セマンティックカーネルやエージェントフレームワークといったものですね。 00:13:49.240 --> 00:13:56.480 アーキテクチャは、セキュリティのような非常に高度な概念を扱う必要があるため、かなり複雑になります。 00:13:57.160 --> 00:13:57.480 なるほど。 00:13:59.020 --> 00:14:05.080 認証の観点では、マルチツールを使用する場合や、NCPを統合したい場合、 00:14:05.560 --> 00:14:10.720 あるいはリバースプロ機種で保護された社内ツールに接続したい場合などが考えられます。 00:14:13.550 --> 00:14:18.010 ですから、コパイロットスタジオなどでカスタムエージェントを扱う際には、 00:14:18.010 --> 00:14:21.610 アーキテクチャについてより深く検討する必要があります。 00:14:23.190 --> 00:14:29.530 アーキテクチャの観点で見ると、カスタム開発アプローチでは定義を迅速に行うことができます。 00:14:29.970 --> 00:14:35.810 ただ、高度な概念を扱う必要があり、それは非常に基礎的な側面であるため、 00:14:36.310 --> 00:14:39.290 多くの人にとって難しいと感じられるかもしれません。 00:14:39.290 --> 00:14:47.800 そして、正直なところ、私の仕事では多岐にわたるニーズに対応しています。 00:14:48.460 --> 00:14:52.220 カスタム開発の場合もあれば、コパイロットスタジオの場合も、 00:14:52.520 --> 00:14:56.040 エージェントビルダーを使ったごくシンプルなエージェントの場合もあります。 00:14:57.720 --> 00:15:02.560 つまり、アーキテクチャの定義は、どの手法を取るかによって決まるのです。 00:15:02.560 --> 00:15:07.800 基本となる一般的なアーキテクチャは作成できますが、 00:15:08.240 --> 00:15:13.300 最終的にはローコードかフルコードか、どちらのアプローチを選ぶか次第ですね。 00:15:14.540 --> 00:15:17.060 ええ、そうですね、ええと、ですが、 00:15:19.800 --> 00:15:24.960 典型的なエンタープライズAIエージェントの構造について説明していただけますか? 00:15:27.260 --> 00:15:28.540 はい、もちろんです。 00:15:32.980 --> 00:15:36.100 基本的には、できるだけシンプルに話すと、 00:15:36.100 --> 00:15:39.840 例えば、ITサポートエージェントのようなニーズがある場合、 00:15:40.320 --> 00:15:43.180 いくつかの構成要素が存在することになります。 00:15:48.000 --> 00:15:52.720 ただ、最近は先ほど言ったようにマルチエージェントのアプローチを取ることが多く、 00:15:53.200 --> 00:15:57.660 私は最初のエージェントをフロント、つまり窓口として配置しています。 00:15:58.780 --> 00:16:02.960 これがフロントエージェントで、このエージェントがあらゆるリクエストを、 00:16:03.280 --> 00:16:07.100 例えば他の異なるエージェントへと振り分ける役割を担います。 00:16:07.100 --> 00:16:12.680 例えば、ユーザーがセールスフォースについて質問した場合、 00:16:13.120 --> 00:16:17.820 そのリクエストすべてをセールスフォースのITサポートエージェントへと転送します。 00:16:18.760 --> 00:16:23.780 お分かりのように、私たちは顧客のためにこのようなアーキテクチャを構築してきました。 00:16:23.960 --> 00:16:27.200 各エージェントがそれぞれのスコープを担当するためです。 00:16:27.200 --> 00:16:33.860 それはセールスフォースのような製品であったり、あるいはM365のようなものかもしれません。 00:16:34.620 --> 00:16:39.080 その背後で、各エージェントは一連の指示とツールセットを持っています。 00:16:40.580 --> 00:16:44.100 最近では、MCPサーバーを使うのがより良いでしょう。 00:16:44.100 --> 00:16:51.040 MCPサーバーはAIにマルチサービスを統合するためのユニバーサルなプラグインだからです。 00:16:52.660 --> 00:16:59.380 そのため、私はMCPサーバーのセットに加え、いくつかの内部知識ソースも用意しています。 00:16:59.380 --> 00:17:04.560 それはJiraのようなものや、サービスナウのナレッジベースのようなものですね。 00:17:04.940 --> 00:17:08.300 つまり、エージェントごとに一連の指示があるわけです。 00:17:11.690 --> 00:17:15.190 そしてその指示がエージェントの範囲と役割を定義し、 00:17:15.690 --> 00:17:21.430 さらに一連のMCPサーバーやPDFファイルといった知識ソースを活用します。 00:17:25.260 --> 00:17:29.220 ですから、多種多様なデータソースを扱うことができるのです。 00:17:34.160 --> 00:17:37.460 ユーザーがメインエージェントにリクエストを送った後、 00:17:37.460 --> 00:17:42.940 そのエージェントは、このタスクは担当のエージェントに委任すべきだと判断します。 00:17:47.520 --> 00:17:50.920 では、その可能性について少し見ていきましょう。 00:17:53.040 --> 00:17:58.520 コパイロットスタジオは、全体のアーキテクチャの中でどのような位置づけになるのでしょうか。 00:18:00.160 --> 00:18:05.560 正直に言うと、コパイロットスタジオはマイクロソフトが提供するローコードツールです。 00:18:05.960 --> 00:18:10.600 まず、アーキテクチャの観点から見ると、コパイロットスタジオはまさに、 00:18:10.600 --> 00:18:18.450 基本的には開発者ではない人、メーカーのために定義されたものだと言えます。 00:18:20.250 --> 00:18:25.130 アーキテクチャの面で言えば、先ほど挙げたITサポートの例で言うと、 00:18:25.470 --> 00:18:27.750 コパイロットスタジオはうまく適合します。 00:18:30.260 --> 00:18:36.060 なぜなら、アーキテクチャの観点からコパイロットスタジオは期待通りの役割を果たすからです。 00:18:36.060 --> 00:18:43.890 外部や内部のナレッジソースを簡単に統合できますし、必要な設定も可能です。 00:18:45.270 --> 00:18:51.770 ただ、先ほども言ったように、もしオーケストレーターを少しカスタマイズしたいというユースケースがある場合、 00:18:51.770 --> 00:18:56.450 コパイロットスタジオの裏側ではオーケストレーターをカスタマイズすることはできず、 00:18:56.890 --> 00:19:00.910 AIオーケストレーターを有効にするかどうかの選択肢しかないからです。 00:19:01.450 --> 00:19:06.010 例えば、達成したいタスクの優先順位をカスタマイズすることはできません。 00:19:06.670 --> 00:19:12.090 コパイロットスタジオの裏側で計画が定義され、それが実行される仕組みだからです。 00:19:12.090 --> 00:19:22.130 しかし、さらなるカスタマイズが必要な場合は、セマンティックカーネルやラングチェーンといったフレームワークを用いたカスタム開発が必要です。 00:19:24.310 --> 00:19:31.490 最近ではマイクロソフトもフレームワークをリリースしており、これを使えばオーケストレーションを簡単にカスタマイズし、 00:19:31.950 --> 00:19:35.710 ワークフローを定義して思い通りに作り込むことができます。 00:19:38.680 --> 00:19:44.140 コパイロットスタジオというアーキテクチャは、エージェントを非常に簡単に構築できるため、 00:19:44.620 --> 00:19:47.780 まさにビルダーやメーカーのために定義されたものなのです。 00:19:49.480 --> 00:19:57.440 コパイロットスタジオの唯一の懸念点は、パスやアーキテクチャを選択する際にライセンスについて注意しなければならないことです。 00:19:59.320 --> 00:20:04.440 今やどんなソリューションにおいても、それは非常に大きな要素となっているからです。 00:20:06.120 --> 00:20:13.240 現在、コパイロットスタジオは重量課金モデルへと少し進化しており、コスト見積もりに注意が必要です。 00:20:13.660 --> 00:20:18.440 達成したい目標によっては、独自に開発した方が良い場合があります。 00:20:19.540 --> 00:20:27.660 その場合、好きな場所にホストし、すべてのコストを自分で管理できるため、現在よりも容易に見積もりが可能です。 00:20:27.660 --> 00:20:39.500 というのも、コパイロットクレジットのアプローチでは、1ヶ月や2ヶ月といった期間でどれくらいのコストがかかるのか、予測が難しい場合があるからです。 00:20:39.500 --> 00:20:46.550 では、コパイロットスタジオの制限とは一体何でしょうか。 00:20:47.390 --> 00:20:58.390 スタジオについてですが、私が何を選択すべきか迷うとき、マイクロソフトファウンドリ、アジュールファウンドリでしたか、正式名称は定かではありませんが、お考えます。 00:20:58.390 --> 00:21:04.450 そして、よし、完全にカスタム開発をしなければならないと判断するときがあります。 00:21:07.070 --> 00:21:08.390 最初の質問は、 00:21:10.190 --> 00:21:14.550 オーケストレーションをカスタマイズする必要があるか?ということです。 00:21:15.130 --> 00:21:17.390 それが私にとって最初の問いです。 00:21:19.720 --> 00:21:27.360 なぜなら、もしオーケストレーションのカスタマイズや、仕組みや計画生成の深部まで踏み込む必要がなければ、 00:21:27.800 --> 00:21:30.380 コパイロットスタジオのようなローコードアプローチ、 00:21:30.380 --> 00:21:33.820 例えばビルダーなどが使えるとわかるからです。 00:21:35.540 --> 00:21:40.620 また、単純なユースケースであれば、こうしたツールを使用することも可能です。 00:21:42.200 --> 00:21:48.180 しかし、オーケストレーションをカスタマイズしたいなら、特定の実装に進む必要があります。 00:21:50.040 --> 00:21:56.260 その場合、モデルにはファウンドリを使うか、あるいは独自のプラットフォームを持つことになります。 00:21:57.320 --> 00:21:59.120 カスタム開発の利点は、 00:22:00.380 --> 00:22:04.780 マイクロソフトファウンドリでホストされていないモデルも統合できる点です。 00:22:08.410 --> 00:22:11.170 必要であればファウンドリのモデルも使えますが、 00:22:11.610 --> 00:22:14.710 AWSやGoogleプラットフォームを利用していて、 00:22:15.250 --> 00:22:17.230 例えばジェミニを使いたい場合や、 00:22:17.670 --> 00:22:19.790 外部にモデルをデプロイしている場合でも、 00:22:20.270 --> 00:22:24.750 カスタムアプローチならそれらを直接エージェントに統合できる能力があるのです。 00:22:24.750 --> 00:22:30.350 これも利点の一つです。 00:22:31.350 --> 00:22:35.870 その後、オーケストレーションや計画の生成方法をカスタマイズでき、 00:22:36.430 --> 00:22:39.870 すべての要素をエージェントのファウンドリに組み込むことができます。 00:22:41.230 --> 00:22:43.130 現在のファウンドリの問題は、 00:22:43.470 --> 00:22:47.230 当初は単なるモデルホスティングプラットフォームだったということです。 00:22:47.230 --> 00:22:51.370 数年前を振り返ると、ただシンプルなモデルカタログがあり、 00:22:51.870 --> 00:22:53.950 それをデプロイするだけの存在でした。 00:22:55.690 --> 00:22:58.990 現在、マイクロソフトはこの製品を進化させ、 00:22:59.390 --> 00:23:02.690 コパイロットスタジオのようなユーザーインターフェースを使って、 00:23:03.070 --> 00:23:05.930 コードなしでエージェントを作成できるようになりました。 00:23:07.810 --> 00:23:11.690 ガバナンスを含め、多くのことを管理できるようになっています。 00:23:12.230 --> 00:23:15.330 これは、コパイロットスタジオのようなローコードで、 00:23:15.330 --> 00:23:18.490 真にエージェント志向のプラットフォームになりました。 00:23:19.930 --> 00:23:22.930 今日、ファウンドリは急速に進化しているため、 00:23:23.410 --> 00:23:27.730 エコシステムの中でどのような位置づけにするかが非常に難しくなっています。 00:23:31.040 --> 00:23:34.840 基本的にマイクロソフトはいくつかの機能を導入しましたが、 00:23:35.340 --> 00:23:38.940 それらはコパイロットスタジオとMCP統合などの点で、 00:23:39.340 --> 00:23:42.080 違いというよりも類似点が多いように感じます。 00:23:44.840 --> 00:23:49.520 しかし、コパイロットスタジオの主な制限はモデルに関するものです。 00:23:49.940 --> 00:23:54.880 コードを統合したり、何かを可視化したりする機能は備わっています。 00:23:55.840 --> 00:23:59.300 ですが、例えば独自のモデルを統合したい場合、 00:23:59.760 --> 00:24:02.920 特定のバージョンが必要だとしても、それはできません。 00:24:04.360 --> 00:24:07.540 独自のLLMプラットフォームなどを統合するには、 00:24:07.980 --> 00:24:09.640 カスタム開発が必要です。 00:24:10.960 --> 00:24:14.920 AWS上に独自のプラットフォームを持つ顧客もいますが、 00:24:14.920 --> 00:24:19.820 その場合、外部で管理される価格設定でそのモデルを統合できます。 00:24:23.060 --> 00:24:24.400 なるほど、そうですね。 00:24:25.700 --> 00:24:30.120 エージェントを構築する際、あるトピックが非常に重要だと思います。 00:24:39.020 --> 00:24:50.740 はい、それはショーペンハウアー、失礼。 00:24:50.740 --> 00:25:02.260 多くの人が話しているのは、MCP、つまりモデルコンテキストプロトコルのことです。 00:25:03.200 --> 00:25:08.020 なぜそれがエージェント開発における最大の話題の一つになっているのでしょうか。 00:25:09.980 --> 00:25:12.720 また、まだ触れたことがない人のために、 00:25:13.100 --> 00:25:16.580 モデルコンテキストプロトコルとは何か教えていただけますか? 00:25:16.580 --> 00:25:19.840 A、大きなキーワードですね。 00:25:20.380 --> 00:25:25.240 多くの人が話題にしているのは、これが主要な問題を解決するからです。 00:25:28.120 --> 00:25:34.180 AIに対するツールやスキル、あるいは外部ツールの統合をいかに統一するかが課題でした。 00:25:37.730 --> 00:25:44.230 以前はMCPがなかったため、サービスごとに通信方式が異なり、非常に混乱していました。 00:25:44.230 --> 00:25:52.530 技術的なプロトコルもアーキテクチャのアプローチもバラバラでしたが、 00:25:52.950 --> 00:25:55.710 MCPはその統合を統一してくれます。 00:26:01.040 --> 00:26:05.120 AIエージェントであれ、より一般的なAIソリューションであれ、 00:26:05.600 --> 00:26:10.720 外部ツールや内部ツールを統合する手段として、今やMCPが主流です。 00:26:14.340 --> 00:26:16.320 技術的な統一が図れるため、 00:26:16.820 --> 00:26:20.860 MCPは今やAIアーキテクチャの重要な一部となっています。 00:26:21.420 --> 00:26:24.480 今日において、それは非常に重要なポイントです。 00:26:24.480 --> 00:26:29.420 以前はAPI統合が中心でしたが、今はMCPの時代だからです。 00:26:30.020 --> 00:26:34.320 なるほど、これは、ええ、進化というわけではありませんが、 00:26:34.780 --> 00:26:37.660 これまではエージェントをAPIと統合していました。 00:26:37.880 --> 00:26:43.300 認証の方法や管理、ツールの呼び出し方などを自分たちで制御する必要がありました。 00:26:43.520 --> 00:26:46.420 今ではAIが、このツールが使えるから、 00:26:46.840 --> 00:26:50.580 目標を達成するために必要なものを選ぼうと判断できます。 00:26:50.580 --> 00:26:59.100 では、MCPとAPI接続とでは、何が本当に変わったのでしょうか。 00:27:04.280 --> 00:27:10.520 基本的には、これまでの統合という観点では、APIはインテリジェントではありませんでした。 00:27:14.250 --> 00:27:18.930 APIは単に、ツールを呼び出すとデータを返すだけのものでした。 00:27:18.930 --> 00:27:27.830 MCPとの違いは、アーキテクチャの面でMCPの方がよりインテリジェントであることです。 00:27:29.670 --> 00:27:33.730 裏側には、単にデータや情報を返すツールだけでなく、 00:27:34.310 --> 00:27:37.270 スキルや指示、その他様々な要素があり、 00:27:37.830 --> 00:27:40.810 それがMCPを真にインテリジェントにしています。 00:27:41.630 --> 00:27:45.230 基本的に、MCPはAIに対してこう言えます。 00:27:45.450 --> 00:27:47.690 なるほど、これを達成したいんだね。 00:27:48.590 --> 00:27:51.830 リクエストに一致する正確なツールを提供するよ。 00:27:53.290 --> 00:27:55.490 ユーザーは単一のツールだけでなく、 00:27:56.030 --> 00:28:00.370 目的を達成するために必要な複数のツールを呼び出すことができます。 00:28:01.370 --> 00:28:03.590 これこそがMCPの役割です。 00:28:03.590 --> 00:28:07.050 AIに対して、使えるツールはこれだと示し、 00:28:07.470 --> 00:28:13.810 その上で、これやあれ、あるいは複数のツールを組み合わせて目的を達成できるよと教えるのです。 00:28:14.510 --> 00:28:17.890 AIにあらゆるものの真のコンテキストを与えてくれます。 00:28:18.510 --> 00:28:23.710 APIは単にツールと説明があるだけで、それ以上のものではありません。 00:28:26.790 --> 00:28:29.810 では、モデル・コンテキスト・プロトコルというのは、 00:28:30.230 --> 00:28:32.290 メタデータのようなものなのでしょうか? 00:28:32.710 --> 00:28:34.490 それともどのような仕組みなのですか? 00:28:34.490 --> 00:28:38.110 いいえ、違います。 00:28:38.890 --> 00:28:42.370 MCPの裏側は、単なるプロトコルに過ぎません。 00:28:43.990 --> 00:28:46.470 基本的には技術的なプロトコルです。 00:28:47.230 --> 00:28:51.050 その裏側には、確かにメタデータや説明はありますが、 00:28:51.470 --> 00:28:54.290 それ以上にAI向けのスキルが記述されており、 00:28:54.670 --> 00:28:56.270 AIに特化しているのです。 00:28:56.950 --> 00:28:59.810 基本的には、スキルや指示が備わっており、 00:29:00.150 --> 00:29:02.330 AIが、このツールはこう動く、 00:29:02.450 --> 00:29:05.390 あのツールはこう動く、とより深く理解できます。 00:29:05.390 --> 00:29:07.850 そして、これらのスキルを呼び出し、 00:29:08.230 --> 00:29:10.550 MCPサーバーに情報を要求して、 00:29:10.950 --> 00:29:13.670 自分のタスクを達成しようと判断できるのです。 00:29:14.670 --> 00:29:17.290 ですが、メタデータの一部は必要です。 00:29:17.490 --> 00:29:20.690 ツール名や、裏側で何が行われているのかを 00:29:20.690 --> 00:29:22.450 定義しなければならないからです。 00:29:23.770 --> 00:29:27.870 ねえ、私たちは、未来はMCPだと言えるのでしょうか。 00:29:28.070 --> 00:29:32.570 企業には組織内に何百ものREST APIがあるわけですが、 00:29:33.150 --> 00:29:37.230 それらの周りにMCPサーバーを構築し始めるべきなのでしょうか。 00:29:37.230 --> 00:29:40.450 はい、その通りです。 00:29:41.110 --> 00:29:45.790 基本的にMCPサーバーは裏側でAPIと連携して動作します。 00:29:46.050 --> 00:29:48.910 基本的には、これは置き換えではありません。 00:29:49.650 --> 00:29:53.570 まとめると、MCPサーバーは単なる窓口だと言えます。 00:29:54.390 --> 00:29:59.670 コンテキストを提供し、その裏側でMCPがAPIを呼び出すことができるのです。 00:29:59.970 --> 00:30:03.810 裏側ではそうですが、MCPサーバーはフロントエンド、 00:30:04.290 --> 00:30:06.930 つまり呼び出す必要のあるフロントツールです。 00:30:08.070 --> 00:30:12.190 なぜなら、その背後でリクエストの振り分けが行われるからです。 00:30:14.010 --> 00:30:17.810 裏側ではAPIであったり、データベースであったり、 00:30:18.170 --> 00:30:20.890 複数のツールであったりする可能性があります。 00:30:20.890 --> 00:30:27.940 ですが、例えば社内に財務サービスや人事サービスといった 00:30:27.940 --> 00:30:33.220 様々なAPIやサービスがあり、独自のMCPサーバーを持ちたい場合、 00:30:33.680 --> 00:30:36.800 裏側ですべてのAPIを扱う必要があります。 00:30:40.140 --> 00:30:44.820 MCPサーバーは、それらのAPIがどのようなサービスなのか、 00:30:45.220 --> 00:30:49.260 利用可能なツールは何か、スキルは何かといった情報を 00:30:49.260 --> 00:30:51.060 すべて公開しなければなりません。 00:30:52.880 --> 00:30:53.120 うん。 00:30:53.120 --> 00:30:58.440 その後、裏側で認証を処理する必要があります。 00:31:00.360 --> 00:31:05.840 APIによって仕組みが異なり、キーによる認証やその他の方法があるからです。 00:31:06.620 --> 00:31:09.180 そのため、そうした対応が必要になりますが、 00:31:09.540 --> 00:31:11.760 MCPは利用可能なツールを公開し、 00:31:12.180 --> 00:31:15.480 その裏側でツールが複数のAPIを呼び出せるようになります。 00:31:15.680 --> 00:31:20.280 一つのAPIであっても、裏側には様々なアーキテクチャが存在し得ます。 00:31:20.280 --> 00:31:21.500 なるほど。 00:31:22.860 --> 00:31:30.920 それで、MCPはどのようにして、適切なツールを選ぶのでしょうか? 00:31:31.440 --> 00:31:34.980 例えば、100とか500のAIエージェントがある場合です。 00:31:34.980 --> 00:31:42.000 Aと、それはまず最初に、基本的にエージェントにリクエストが来ると、 00:31:42.400 --> 00:31:45.580 利用可能なすべてのツールを探索することになります。 00:31:45.780 --> 00:31:51.440 MCPサーバー側で、よし、利用可能なツールはこれらすべてだと確認するわけです。 00:31:51.440 --> 00:31:55.500 基本的には、エージェントのオーケストレーターが、 00:31:55.880 --> 00:31:59.920 よし、これがあるな、LLMが使えるな、と理解します。 00:32:01.160 --> 00:32:03.220 その後に、プランを作成します。 00:32:05.000 --> 00:32:09.480 少しまとめると、実行するアクションを含むプランを作成し、 00:32:09.880 --> 00:32:14.160 そのアクションの中で、ユーザーが要求したタスクを達成するために、 00:32:14.160 --> 00:32:19.600 1つ、2つ、3つ、あるいはそれ以上のツールを呼び出すことができます。 00:32:21.080 --> 00:32:25.420 つまり、エージェントのオーケストレーターがMCPツールを理解し、 00:32:25.840 --> 00:32:28.300 要求に最適なものを選択するわけです。 00:32:28.480 --> 00:32:29.280 お分かりですね。 00:32:30.920 --> 00:32:35.620 これこそが、ツールの選択などを行うオーケストレーターの役割であり、 00:32:36.100 --> 00:32:38.220 もちろんLLMの助けも借ります。 00:32:41.420 --> 00:32:43.280 LLMがNOの一部であり、 00:32:43.280 --> 00:32:46.820 オーケストレーターはLLMやツールと連携して、 00:32:47.300 --> 00:32:51.280 タスクを達成するための最善の選択と計画を立てるからです。 00:32:54.700 --> 00:32:58.660 A、以前は多くの企業がパワーシェルから始めていましたが、 00:32:59.100 --> 00:33:02.280 今ではマイクロソフトグラフAPIを使っていますね。 00:33:05.530 --> 00:33:08.910 グラフとMCPの関係はどうなっているのでしょうか。 00:33:13.850 --> 00:33:16.050 実のところ、正直に言うと、 00:33:16.050 --> 00:33:19.290 グラフ用のMCPというものは存在しません。 00:33:19.290 --> 00:33:25.760 マイクロソフト365の世界では、 00:33:26.260 --> 00:33:29.800 マイクロソフトが多くのMCPサーバーを導入しており、 00:33:30.340 --> 00:33:34.620 それらのMCPサーバーは裏側でマイクロソフトグラフに基づいています。 00:33:37.840 --> 00:33:41.460 例えば、チームのMCPサーバーを使いたい場合、 00:33:41.920 --> 00:33:46.620 裏側ではMCPサーバーを使う際にグラフAPIが呼び出されています。 00:33:46.620 --> 00:33:55.420 つまり、マイクロソフト365の世界においてグラフAPIは中心的な存在です。 00:33:57.160 --> 00:34:02.340 MCPが裏側でグラフと通信し、リクエストを正しく処理しているからです。 00:34:04.240 --> 00:34:08.780 ですが、現在ではコパイロット全体においてもグラフは中心的です。 00:34:09.180 --> 00:34:13.360 コパイロットのセマンティックインデックスは生データに基づいているからです。 00:34:13.360 --> 00:34:18.720 実際には、MCPサーバーを通じてグラフを利用していることになります。 00:34:19.000 --> 00:34:21.720 最近では、そういった形になっています。 00:34:27.880 --> 00:34:36.220 マイクロソフト365には、組織のコンテキスト、ドキュメント、会議、メール、人、チーム会話、 00:34:36.660 --> 00:34:40.360 そして共有コンテンツといった計り知れない価値が含まれています。 00:34:42.260 --> 00:34:45.100 そうしたコンテキストをどうすれば、 00:34:45.200 --> 00:34:49.420 A、セキュリティ上の悪夢を生み出さずに公開できるのでしょうか。 00:34:50.880 --> 00:34:53.580 ガバナンスといった観点での話でしょうか。 00:34:55.220 --> 00:34:57.360 ええ、それは常に問題です。 00:34:58.320 --> 00:35:03.420 多くの人が適切なガバナンスを裏側で整えずにエージェントを構築していますから、 00:35:03.920 --> 00:35:05.800 エージェントを構築したいとします。 00:35:06.040 --> 00:35:07.440 よし、始めましょう。 00:35:07.720 --> 00:35:09.280 構築して展開しますが、 00:35:09.720 --> 00:35:13.540 その後、このエージェントは大量のデータを扱うことになります。 00:35:13.640 --> 00:35:16.060 それをどう管理すればいいのでしょうか。 00:35:16.060 --> 00:35:21.120 最初の疑問は、エージェントのガバナンスをどう導入するかということです。 00:35:21.460 --> 00:35:25.340 そのままでは、おっしゃる通り、混乱を招く可能性があります。 00:35:25.340 --> 00:35:31.860 多くの人がエージェントやAIソリューションを構築したいと考えていますが、 00:35:32.260 --> 00:35:36.700 舞台裏では、例えばマイクロソフト365環境の場合、 00:35:37.180 --> 00:35:40.180 最初に行うべきことはデータを理解することです。 00:35:40.180 --> 00:35:46.660 データを理解しなければ、どうすればいいかわからなくなります。 00:35:46.860 --> 00:35:48.720 データを理解する必要があります。 00:35:49.000 --> 00:35:53.700 なぜなら、扱っているデータが機密情報かどうかを把握することが重要だからです。 00:35:53.860 --> 00:35:57.220 極めて機密性の高いデータを扱っているのでしょうか。 00:35:57.400 --> 00:36:00.360 そうです。データを理解する必要があります。 00:36:00.360 --> 00:36:03.980 その後、マイクロソフト環境であれば、 00:36:04.360 --> 00:36:08.740 DLP機能や秘密ドラベルといった仕組みを導入する必要があります。 00:36:10.560 --> 00:36:13.460 これがないと問題になる可能性があるからです。 00:36:15.730 --> 00:36:18.470 さらに、データを整理する必要もあります。 00:36:21.950 --> 00:36:25.950 データの質が低ければ、エージェントは期待通りに動作しません。 00:36:31.660 --> 00:36:34.740 シェアポイントやチームのチャンネルなどが乱雑であれば、 00:36:34.740 --> 00:36:39.100 エージェント的なアプローチで正しく機能させることは困難だからです。 00:36:44.260 --> 00:36:46.760 結論として、データを理解し、 00:36:47.160 --> 00:36:51.960 認証やパービューのような基本的なセキュリティ機能を導入する必要があります。 00:36:55.890 --> 00:37:01.850 パービューは、こうしたセキュリティやガバナンスを整えるための中心的なソリューションとなっています。 00:37:07.370 --> 00:37:10.970 データのクレンジングと基本的なセキュリティ対策が済んだら、 00:37:11.370 --> 00:37:14.270 次はライセンスについても理解する必要があります。 00:37:21.190 --> 00:37:26.730 エージェントの構築を始める前に、開発者がそのための訓練を受けているか、 00:37:26.730 --> 00:37:33.390 適切なライセンスがあるか、あるいはサブスクリプションが必要かといった点を確認しなければなりません。 00:37:39.590 --> 00:37:41.790 大きな問題の一つはツールです。 00:37:41.790 --> 00:37:48.830 全てのツールを自分の開発環境やエージェントにどう統合すれば適切か、 00:37:49.250 --> 00:37:54.150 何か制限を設ける必要があるかなど、正直なところ大きな課題です。 00:37:56.580 --> 00:38:03.880 考慮すべき活動は多岐にわたりますが、私にとって最も重要なのは、データを理解すること、です。 00:38:03.880 --> 00:38:10.680 企業が自社のデータを理解していなければ、最初から問題になるでしょう。 00:38:12.950 --> 00:38:23.920 なるほど、えーと、私たちがどのように、私たちは、えーと、それを尋ねましたっけ? 00:38:24.880 --> 00:38:28.860 うーん、セキュリティのトピックですね、えー。 00:38:28.860 --> 00:38:37.130 そこに、2つの、そうですね、2種類の人がいると思います。 00:38:38.630 --> 00:38:44.830 一方はユーザー権限が必要だと言い、もう一方はアプリケーション権限が必要だと言います。 00:38:47.530 --> 00:38:50.670 エージェントは一般的にどう動作すべきでしょうか。 00:38:50.950 --> 00:39:04.300 一般的に、私の一番の推奨は、エージェントソリューションを扱う際は常に、ユーザー権限、つまり委任された権限で行うことです。 00:39:05.980 --> 00:39:15.380 セキュリティの観点から言えば、その方がユーザーは自分がアクセス権を持つデータやツールのみを扱うことになるため、正直なところ安全です。 00:39:17.610 --> 00:39:20.570 それです、それが最も重要な原則です。 00:39:20.930 --> 00:39:28.930 その上で、特定のAPIや特定のコンテキストのためにアプリケーション権限が必要な場合は、それも可能です。 00:39:31.320 --> 00:39:38.060 ただし、アプリケーション権限を直接使用するのではなく、ラッパーというコンテキスト内で処理してください。 00:39:40.510 --> 00:39:48.690 例えば、MCPサーバーのようなものを作成し、その背後でアプリケーション権限を持つMCPを統合するのです。 00:39:48.690 --> 00:39:59.340 そうすれば、MCPが裏側でアプリケーション権限を使ってAPIを呼び出し、必要な情報を返してくれます。 00:40:02.380 --> 00:40:06.400 ユーザーはアプリケーション権限を直接扱う必要はありません。 00:40:06.400 --> 00:40:18.460 ユーザー権限でMCPサーバーなどを呼び出し、MCPサーバーが裏側で、専用のアプリケーション権限を使って各サービスやアプリケーションを呼び出すのです。 00:40:18.700 --> 00:40:20.200 その違いがわかりますか? 00:40:20.200 --> 00:40:24.180 なるほど、興味深いですね。 00:40:25.940 --> 00:40:31.440 アーキテクチャについて考える際は、もう少し深く掘り下げる必要があると思います。 00:40:31.440 --> 00:40:37.760 アーキテクチャには大きく分けて3つの重要なトピックがあると思います。 00:40:39.040 --> 00:40:46.640 検索拡張生成、ラグ、ナレッジトピック、そしていわば裏口的なエンタープライズ検索について扱います。 00:40:47.900 --> 00:40:53.090 えーと、まずはラグから始めましょうか。 00:40:54.250 --> 00:40:57.010 ラグはアーキテクチャのどこに位置するのでしょうか? 00:40:58.430 --> 00:40:59.610 あー、ラグですね。 00:40:59.610 --> 00:41:07.130 正直に言うと、パフォーマンスの観点から言えば、ラグはまさに最も重要なものです。 00:41:10.900 --> 00:41:18.900 AIは様々な種類のデータを理解する必要があり、ラグは基本的に質問に回答するために存在しているからです。 00:41:21.370 --> 00:41:28.090 なぜなら以前は、ラグがなかった頃は、基本的に異なるアプローチで対処する必要があったからです。 00:41:28.250 --> 00:41:32.390 古いやり方というわけではありませんが、当時は複雑でした。 00:41:32.390 --> 00:41:35.070 しかしラグは中心的な存在です。 00:41:36.390 --> 00:41:43.550 ラグは様々な種類のデータを理解し、AIが必要とする情報をドキュメントなどから検索するからです。 00:41:45.470 --> 00:41:48.350 それは多様なデータ形式であっても構いません。 00:41:49.210 --> 00:41:55.050 ですから、そう、現代のAIアーキテクチャにおいてラグは中心的な役割を担っています。 00:41:55.370 --> 00:41:55.570 ええ。 00:41:55.570 --> 00:42:05.070 ですが、多くのユーザーにとって裏側で動いているラグの話をしても、それが何なのかわからないというのは事実です。 00:42:06.610 --> 00:42:13.690 なぜなら、最近のマイクロソフトや多くのソフトウェア企業は、あえてその点について公言しないからです。 00:42:13.690 --> 00:42:22.650 裏側ではラグが動いていても、例えばコパイロットスタジオのユーザーは、裏でラグが働いていることを理解していません。 00:42:24.070 --> 00:42:30.510 深く掘り下げればそういう概念だとわかりますが、多くのユーザーにとってラグは全く未知のものです。 00:42:30.510 --> 00:42:37.150 彼らはツールを使っているだけで、裏側で何が起きているかを知らないのです。 00:42:38.290 --> 00:42:41.830 そこで次のトピックに移りますが、知識についてです。 00:42:42.890 --> 00:42:46.250 AIシステムはどうやって知識を得ているのでしょうか。 00:42:47.410 --> 00:42:51.690 自分で収集しているのか、それともどういう仕組みなのでしょうか。 00:42:51.690 --> 00:43:05.770 実は正直に言いますと、知識というのは、多くの異なるシステムにホストされている可能性があります。 00:43:07.990 --> 00:43:14.550 プレーンテキストファイルの場合もあれば、マークダウンファイルやナレッジベース、あるいは何であっても構いません。 00:43:14.630 --> 00:43:19.990 しかし実際には、MCPサーバーがあれば、そうした知識にアクセスできます。 00:43:20.230 --> 00:43:26.690 あるいは、例えばシェアポイントへのコネクタなど、今日では多くのサービスへのコネクタが用意されています。 00:43:26.690 --> 00:43:31.510 ですから、正直なところ、以前よりも知識へのアクセスは容易になっています。 00:43:31.650 --> 00:43:36.510 というのも、かつてはプラグインを構築して、すべてを個別につなぎ合わせる必要があったからです。 00:43:36.670 --> 00:43:45.530 今日では、あらゆるシステムへの直接的なコネクタがあり、大規模な開発スタッフを抱えることなく、知識を統合することができます。 00:43:47.370 --> 00:43:53.990 私は、よくあることだと思いますが、例えば私のチームの誰かに話をするような感じです。 00:43:53.990 --> 00:44:05.430 では、AIは準備ができていない文書や古い文書、あるいは重複した文書をどのように理解するのでしょうか。 00:44:09.410 --> 00:44:13.490 どのように、どのようにAIシステムはこれを理解できるのでしょうか。 00:44:13.650 --> 00:44:15.990 私たちは何を使うべきなのでしょうか。 00:44:19.440 --> 00:44:25.860 基本的にラグを使用するのは、背後で自分のデータが何であるかを理解する必要があるからです。 00:44:25.860 --> 00:44:34.160 ですが、正直にまとめると、まずはプロンプトから始まりますよね。 00:44:37.000 --> 00:44:42.620 ユーザーは、例えばナレッジベースやワンドライブなどを横断して検索したいと考えます。 00:44:48.470 --> 00:44:56.210 背後では、オーケストレーターがLLMの助けを借りてプロンプトとユーザーの意図を理解すると、インデックスが機能します。 00:44:56.210 --> 00:45:09.460 例えば、コパイロットにはセマンティックインデックスがあり、これがすべての知識を把握しています。 00:45:17.010 --> 00:45:23.890 AIはこれに直接クエリを投げてラグを実行し、ニーズに基づいて適切なドキュメントを選択できます。 00:45:27.680 --> 00:45:30.500 コパイロットにはこのセマンティックインデックスがあり、 00:45:30.980 --> 00:45:36.220 AIは背後で自然言語を使って直接このインデックスにクエリを投げることができます。 00:45:36.220 --> 00:45:42.840 例えば、会社のVPNをどのように設定すればよいか知りたいと尋ねるとします。 00:45:46.080 --> 00:45:49.400 背後でセマンティックインデックスに対してラグが実行され、 00:45:49.820 --> 00:45:53.840 会社のVPN設定がすべて含まれるドキュメントが取得されます。 00:45:55.300 --> 00:46:00.500 例えば、Microsoft 365コパイロットチャットの背後にはグラフAPIがあります。 00:46:00.560 --> 00:46:07.240 先ほど申し上げた通り、セマンティックインデックスはグラフAPIの上に構築されているからです。 00:46:07.240 --> 00:46:12.680 背後にあるのはグラフの機能ですが、カスタム開発の場合は、 00:46:12.980 --> 00:46:15.720 例えば背後にファウンドリーAQが存在します。 00:46:16.420 --> 00:46:20.040 それは以前、別の名前で呼ばれていたAzureサービスでした。 00:46:20.240 --> 00:46:23.940 しかし現在では、必要であれば独自のラグシステムを構築できます。 00:46:24.180 --> 00:46:26.820 基本的には、カスタムエージェントがあれば、 00:46:26.820 --> 00:46:30.840 ファウンドリーAQインスタンスに対して直接質問することができます。 00:46:31.100 --> 00:46:31.420 なるほど。 00:46:31.420 --> 00:46:37.140 例えば、会社のVPN設定情報を取得したい場合、 00:46:37.580 --> 00:46:40.660 AIが必要なドキュメントを検索してきてくれます。 00:46:42.080 --> 00:46:45.480 PDFやWord、Excelといったファイルのことですね。 00:46:48.320 --> 00:46:54.360 そして、それが検索の仕組みですよね。 00:46:59.060 --> 00:47:02.820 あるいは、裏側の仕組みのことですか? 00:47:02.820 --> 00:47:05.480 はい、ああ、裏側の仕組みですね。 00:47:05.720 --> 00:47:07.800 そうです。検索機能があります。 00:47:10.030 --> 00:47:14.030 現在、コパイロットチャットの裏側には3つの機能があります。 00:47:20.010 --> 00:47:22.130 1つ目は標準的な検索で、 00:47:22.530 --> 00:47:26.530 キーワードを入力してドキュメントなどを検索するシンプルなものです。 00:47:30.080 --> 00:47:31.720 これが単純検索です。 00:47:31.720 --> 00:47:35.140 Googleのようなキーワード検索は誰もが知っていますね。 00:47:36.080 --> 00:47:38.700 その後に、2つの異なる機能があります。 00:47:38.700 --> 00:47:42.960 まず、裏側でラグが動いています。 00:47:44.600 --> 00:47:47.480 グラフ内でのラグ機能があり、さらに、 00:47:50.150 --> 00:47:53.130 コパイロットのセマンティックインデックス検索もあります。 00:47:53.790 --> 00:47:55.030 これは少し異なり、 00:47:55.430 --> 00:47:59.590 ラグの型がセマンティックインデックス検索よりも高度なものとなっています。 00:48:04.040 --> 00:48:07.900 これら3つの機能をAIが裏側で使い分けることで、 00:48:08.260 --> 00:48:12.980 ワンドライブやチーム、M365全体からデータを取得できます。 00:48:12.980 --> 00:48:20.620 コパイロットのセマンティックインデックスには、 00:48:21.080 --> 00:48:22.900 コパイロットコネクタも含まれます。 00:48:23.620 --> 00:48:27.600 例えば、セールスフォースをコパイロットコネクタで接続すれば、 00:48:28.040 --> 00:48:29.660 セールスフォースやサービスナウ、 00:48:30.100 --> 00:48:33.700 その他のツール内にあるデータも横断的に検索可能です。 00:48:35.480 --> 00:48:37.100 コパイロットコネクタによって、 00:48:37.240 --> 00:48:40.880 全てのデータがグラフのセマンティックインデックスに統合されるため、 00:48:41.120 --> 00:48:44.720 外部システムに対して直接クエリを実行できるのです。 00:48:44.720 --> 00:48:48.930 なるほど。分かりました。 00:48:50.090 --> 00:48:58.540 次に、エージェントを構築する際のガバナンス、 00:48:59.000 --> 00:49:01.900 特にエージェントのライフサイクル管理についてですが、 00:49:02.300 --> 00:49:04.820 実際にはどのような形になるのでしょうか。 00:49:07.450 --> 00:49:09.630 実際のところ、どうなっていますか。 00:49:10.810 --> 00:49:11.990 正直に言うと、 00:49:12.310 --> 00:49:15.290 マイクロソフトのエコシステムでは非常にシンプルです。 00:49:15.290 --> 00:49:20.950 というのも、コパイロットスタジオのようなローコード環境を扱う場合、 00:49:21.350 --> 00:49:23.870 パワープラットフォームを扱うことになるからです。 00:49:24.250 --> 00:49:26.850 概念は同じで、何も変わっていません。 00:49:27.090 --> 00:49:31.110 ソリューションがあり、アルムが整備され、パイプラインも利用できるのです。 00:49:31.250 --> 00:49:35.110 コパイロットスタジオを扱う場合、正直に言ってこれまで通りです。 00:49:35.110 --> 00:49:41.630 パワープラットフォームのガバナンス、ライフサイクル、アルムに投資してきたすべてがそのまま活かせるからです。 00:49:41.970 --> 00:49:43.610 全く同じことなのです。 00:49:44.210 --> 00:49:46.510 これは良いことで、多くの人から、 00:49:46.910 --> 00:49:50.150 コパイロットスタジオはどう管理すればいいのかと聞かれます。 00:49:50.370 --> 00:49:51.830 何かが違うのでしょうか。 00:49:51.930 --> 00:49:58.110 と、いいえ、パワーアップスやパワーオートメートのアプリケーションライフサイクル管理と全く同じで、とてもシンプルです。 00:49:58.290 --> 00:50:01.390 つまり、今回はエージェントのライフサイクル管理ですが、 00:50:01.590 --> 00:50:04.870 裏側にある概念はパワープラットフォームと同じなのです。 00:50:07.740 --> 00:50:10.120 例えばカスタム開発を扱う場合、 00:50:10.520 --> 00:50:14.940 基本的には.netアプリケーションなどを構築するのと同じで、 00:50:15.340 --> 00:50:17.140 すべてをコードとして管理します。 00:50:20.350 --> 00:50:24.710 フレームワークやセキュリティの側面など、そういったものがあるからです。 00:50:25.270 --> 00:50:26.670 ですから正直なところ、 00:50:27.190 --> 00:50:30.670 アプリケーションやエージェントのライフサイクル管理という点では、 00:50:31.130 --> 00:50:33.230 これまでと概念は全く同じです。 00:50:33.910 --> 00:50:36.110 私にとってこれは良い点です。 00:50:36.110 --> 00:50:41.870 ライフサイクルプロセスなどに多大な投資をする必要がないからです。 00:50:44.580 --> 00:50:51.720 唯一の変更点は、LLMやデプロイなどについて考慮する必要があるという大きな変化があることです。 00:50:51.720 --> 00:50:59.120 しかし裏側では、パイプラインなどを使った過去のDevOpsアプローチとよく似ています。 00:50:59.440 --> 00:51:04.260 ですから私の考えでは、エージェントを管理するという点では何も変わっていません。 00:51:05.580 --> 00:51:09.220 A.カスタム開発であれコパイロットであれ、 00:51:09.680 --> 00:51:12.940 正直なところ今日のアプローチは以前と同じなのです。 00:51:12.940 --> 00:51:24.170 そして、つまり企業がこれまでAIを使っていなかったとしても、 00:51:24.530 --> 00:51:28.090 パービューやディフェンダーなどのツールが完璧に設定されていれば、 00:51:33.330 --> 00:51:35.410 何か変更が必要なのでしょうか、 00:51:35.750 --> 00:51:39.710 それともそれがAIへの準備ができているということなのでしょうか。 00:51:41.870 --> 00:51:43.750 それは非常に大きな問いです。 00:51:43.750 --> 00:51:49.290 マイクロソフトにおけるAIへの準備は、まあ問題ありません。 00:51:50.290 --> 00:51:52.930 シェアポイントの権限管理などもそうですが、 00:51:53.390 --> 00:51:57.090 AIへの準備というのは技術的なアプローチだけではありません。 00:51:58.390 --> 00:52:01.170 技術的なことは何をすべきか分かっています。 00:52:02.070 --> 00:52:06.650 多くのサービスにわたる権限管理が必要だということは分かっていますよね。 00:52:06.770 --> 00:52:09.670 私にとって、AIへの準備とは、 00:52:09.670 --> 00:52:13.790 データ、つまりデータを理解することも含めなければならないのです。 00:52:14.470 --> 00:52:16.730 なぜなら、先ほども言ったように、 00:52:17.230 --> 00:52:19.470 自分のデータを理解していなければ、 00:52:19.810 --> 00:52:22.450 技術的な側面を管理することはできません。 00:52:23.990 --> 00:52:28.310 例えば、何が機密情報で何がそうでないのか分からなければ、 00:52:28.770 --> 00:52:31.570 セキュリティ対策を講じるのは困難だからです。 00:52:33.210 --> 00:52:35.970 しかし、マイクロソフトに従うならば、 00:52:36.310 --> 00:52:39.110 AIレディネスとは、権限を管理し、 00:52:39.110 --> 00:52:41.130 秘密ドラベルを設定し、 00:52:41.550 --> 00:52:45.070 GDPRなどの対応を整えるといったことになります。 00:52:47.520 --> 00:52:50.280 ですが、もっと高次元な側面もあります。 00:52:51.720 --> 00:52:52.600 私にとって、 00:52:53.040 --> 00:52:55.880 AIレディネスは技術的なものだけではありません。 00:52:57.380 --> 00:52:58.320 正直なところ、 00:52:58.820 --> 00:53:00.980 今日では考慮すべき機能的、 00:53:01.360 --> 00:53:03.680 あるいは高次元な側面もあるのです。 00:53:07.270 --> 00:53:09.670 ええ、それは非常に興味深いです。 00:53:09.670 --> 00:53:14.130 多くの企業がAIを使い始めましたが、 00:53:14.510 --> 00:53:16.010 エージェントが登場した今、 00:53:16.470 --> 00:53:17.530 多くの企業が、 00:53:17.910 --> 00:53:20.570 AIがメールをすべて削除したのではないか、 00:53:20.910 --> 00:53:21.090 とか、 00:53:21.610 --> 00:53:24.610 何か悪いことをしているのではないかと懸念しています。 00:53:26.230 --> 00:53:26.610 うーん、 00:53:28.820 --> 00:53:31.400 企業がAIを恐れている理由について、 00:53:31.720 --> 00:53:32.800 どう思われますか? 00:53:35.870 --> 00:53:36.950 いい質問ですね。 00:53:37.910 --> 00:53:39.650 私はスイスに住んでいて、 00:53:40.130 --> 00:53:42.390 そこには多くのプライベートバンクがあり、 00:53:42.850 --> 00:53:43.710 正直なところ、 00:53:44.190 --> 00:53:46.890 非常に機密性の高い顧客を抱えています。 00:53:48.130 --> 00:53:48.630 そのため、 00:53:49.070 --> 00:53:50.370 最も重要なのは、 00:53:50.790 --> 00:53:52.730 データはどこで処理されているのか、 00:53:53.430 --> 00:53:54.530 という点なのです。 00:53:55.110 --> 00:53:56.650 基本的にはそうですし、 00:53:57.070 --> 00:53:59.790 AIが私のメールを検索しているのか、 00:54:00.210 --> 00:54:01.550 といった懸念もあります。 00:54:01.950 --> 00:54:03.410 そういった類のことです。 00:54:03.410 --> 00:54:06.970 舞台裏では常にそうした質問がなされています。 00:54:10.110 --> 00:54:12.330 彼らにとって最も重要なのは、 00:54:12.770 --> 00:54:16.770 データがどこで処理されているのかを理解する必要があるという点と、 00:54:17.190 --> 00:54:18.290 私がAIの、 00:54:18.510 --> 00:54:19.270 という点です。 00:54:22.580 --> 00:54:23.480 所有者である、 00:54:23.740 --> 00:54:24.520 という点です。 00:54:24.800 --> 00:54:26.760 私がAIに指示を出すと、 00:54:27.140 --> 00:54:29.300 AIが裏で作業を実行します。 00:54:30.680 --> 00:54:31.640 彼らは例えば、 00:54:32.160 --> 00:54:32.780 自立性、 00:54:32.980 --> 00:54:34.540 という側面を恐れています。 00:54:37.890 --> 00:54:39.990 現代では指示を出せば裏で、 00:54:39.990 --> 00:54:42.570 AIが検索やクエリを実行しますが、 00:54:42.670 --> 00:54:43.070 彼らは、 00:54:43.550 --> 00:54:45.830 私がAIに何かを頼んだとき、 00:54:46.250 --> 00:54:49.170 裏で何が実行されているのかを恐れているのです。 00:54:52.000 --> 00:54:52.220 ええ、 00:54:52.640 --> 00:54:55.360 そのように多くの疑問が投げかけられています。 00:54:55.720 --> 00:54:56.080 なるほど。 00:54:56.940 --> 00:54:58.100 AIエージェントや、 00:54:58.100 --> 00:55:01.380 AIサービスといったものの背後にある全プロセスを、 00:55:01.780 --> 00:55:03.960 どのように制御すればよいのでしょうか。 00:55:05.100 --> 00:55:05.340 ええ、 00:55:05.680 --> 00:55:08.060 そのような質問はいくつかありますね。 00:55:09.200 --> 00:55:09.660 ですが、 00:55:10.060 --> 00:55:13.180 これは導入やトレーニングに関する問題でもあります。 00:55:13.180 --> 00:55:16.020 AIを理解し、 00:55:16.400 --> 00:55:21.760 裏側で何が実行されているのかを把握するためのトレーニングを導入する必要があります。 00:55:22.820 --> 00:55:24.980 透明性も重要なポイントです。 00:55:25.780 --> 00:55:29.660 すべてのAIソリューションに透明性を組み込む必要があります。 00:55:30.560 --> 00:55:33.360 私にとって透明性は大きなテーマです。 00:55:34.480 --> 00:55:37.240 AIソリューションは透明でなければならないため、 00:55:37.740 --> 00:55:40.320 すべてを適切に導入しなければなりません。 00:55:41.000 --> 00:55:42.860 舞台裏で何が行われているか、 00:55:43.260 --> 00:55:45.480 どのデータがクエリされているかを理解し、 00:55:45.900 --> 00:55:47.020 すべてを追跡し、 00:55:47.320 --> 00:55:48.920 ログに記録する必要があります。 00:55:49.160 --> 00:55:49.820 今日では、 00:55:50.280 --> 00:55:51.520 ソリューションを持つ以上、 00:55:52.040 --> 00:55:54.120 すべてを透明にする必要があります。 00:55:54.380 --> 00:55:55.760 裏で何が実行され、 00:55:56.100 --> 00:55:57.320 どのデータが処理され、 00:55:57.720 --> 00:55:59.260 どのような根拠に基づいて 00:55:59.260 --> 00:56:02.700 推論されているかを正確に理解する必要があるからです。 00:56:02.920 --> 00:56:03.240 なるほど。 00:56:03.660 --> 00:56:06.000 どのようにしてこの計画を生成したのか、 00:56:06.400 --> 00:56:08.320 どのような事実に基づいているのか、 00:56:08.540 --> 00:56:09.300 といったことです。 00:56:09.580 --> 00:56:10.280 素晴らしい。 00:56:10.480 --> 00:56:13.100 おっと、時間が少し足りなくなってきましたね。 00:56:13.300 --> 00:56:13.780 ですから、 00:56:13.960 --> 00:56:14.960 はい、すみません。 00:56:15.200 --> 00:56:16.980 本当に素晴らしい内容でした。 00:56:17.200 --> 00:56:17.520 ですが、 00:56:17.780 --> 00:56:19.040 どのポッドキャストでも恒例の 00:56:19.040 --> 00:56:21.700 ラピッドファイアラウンド一問一答の時間です。 00:56:21.880 --> 00:56:22.140 では、 00:56:23.180 --> 00:56:25.560 私が短い文章を言いますので、 00:56:25.940 --> 00:56:27.640 短い答えを返してください。 00:56:27.640 --> 00:56:29.380 はい、準備はいいですか? 00:56:30.540 --> 00:56:30.760 はい。 00:56:31.160 --> 00:56:32.460 コパイロットスタジオか、 00:56:32.780 --> 00:56:33.720 カスタムコードか? 00:56:34.460 --> 00:56:35.960 コパイロットスタジオですね。 00:56:36.220 --> 00:56:37.660 マイクロソフトファウンドリか、 00:56:37.980 --> 00:56:39.160 コパイロットスタジオか? 00:56:39.820 --> 00:56:41.260 コパイロットスタジオです。 00:56:41.420 --> 00:56:42.500 タイプスクリプトか、 00:56:42.860 --> 00:56:44.300 それともタイプクリプトか? 00:56:46.330 --> 00:56:47.150 GitHubか、 00:56:47.490 --> 00:56:48.650 Azure DevOpsか? 00:56:49.010 --> 00:56:49.890 GitHubです。 00:56:50.450 --> 00:56:50.890 ラグか、 00:56:51.190 --> 00:56:52.290 ファインチューニングか? 00:56:52.290 --> 00:56:54.470 なるほど。 00:56:55.310 --> 00:57:00.830 マイクロソフト365APIの中で最も過小評価されているものは何でしょう? 00:57:04.520 --> 00:57:05.840 ラグAPIですね。 00:57:06.760 --> 00:57:11.500 2026年に全てのマイクロソフト開発者が学ぶべき技術を一つ挙げるとすれば、 00:57:11.500 --> 00:57:14.120 GitHubコパイロットです。 00:57:16.350 --> 00:57:18.410 サティアナデラがあなたのところに来て、 00:57:18.510 --> 00:57:21.350 我々のAIプラットフォームをより良くするために、 00:57:21.710 --> 00:57:25.290 必要な資金とリソースをすべて提供する、と言ったら、 00:57:25.470 --> 00:57:27.690 何か一つ機能を開発できるとしたら、 00:57:27.990 --> 00:57:29.130 それは何になりますか? 00:57:29.310 --> 00:57:32.450 私たちが必要としているガバナンス関連のすべてですね。 00:57:34.590 --> 00:57:34.910 そして、 00:57:35.910 --> 00:57:38.610 次に誰をポッドキャストに招待すべきか、 00:57:38.970 --> 00:57:41.070 またどのような質問をすべきでしょうか? 00:57:47.900 --> 00:57:48.860 いい質問ですね。 00:57:49.460 --> 00:57:51.040 友人はたくさんいますが、 00:57:51.420 --> 00:57:51.860 そうですね、 00:57:52.460 --> 00:57:56.500 多くのカンファレンスで共同登壇している相手に聞いてみてはどうでしょう? 00:57:56.760 --> 00:57:59.140 例えば、黒江もろに聞いてみてください。 00:57:59.520 --> 00:58:02.100 彼女は以前は機能コンサルタントでしたが、 00:58:02.520 --> 00:58:05.240 現在は技術的な側面に携わっています。 00:58:05.960 --> 00:58:07.620 ダイナミクスの世界における、 00:58:08.080 --> 00:58:10.500 技術的すぎない機能面での話として、 00:58:10.620 --> 00:58:13.420 彼女はとても興味深いストーリーを持っていますよ。 00:58:14.600 --> 00:58:16.580 彼女を招いて今の時代、 00:58:16.580 --> 00:58:20.680 機能面と技術面の業務をどう両立させればいいのか、 00:58:20.680 --> 00:58:25.160 大きな課題があるはずだから教えてほしいと聞いてみてはどうでしょうか? 00:58:25.160 --> 00:58:29.260 そうですね、では最後の質問です。 00:58:29.380 --> 00:58:33.040 今回のセッションから何か一つ学びを持ち帰るとしたら、 00:58:33.440 --> 00:58:35.280 何を持ち帰るべきでしょうか? 00:58:36.720 --> 00:58:39.020 このセッションからということですね。 00:58:39.220 --> 00:58:39.580 つまり、 00:58:42.540 --> 00:58:44.700 AIは急速に進化しています。 00:58:44.700 --> 00:58:48.340 最新情報を追うなら、 00:58:48.820 --> 00:58:50.840 すべてをフォローする必要があります。 00:58:52.620 --> 00:58:53.540 正直なところ、 00:58:54.040 --> 00:58:57.740 今のAIはマイクロソフトのスタック全体に広がっていますから、 00:59:00.000 --> 00:59:00.740 今の時代、 00:59:01.200 --> 00:59:02.480 理解しておくべきは、 00:59:02.840 --> 00:59:04.980 進化が非常に早いということです。 00:59:04.980 --> 00:59:11.150 常に最新の状態を持たなければ、 00:59:11.550 --> 00:59:14.130 学びや進化の理解を怠った時点で、 00:59:14.570 --> 00:59:16.690 何かを見逃してしまうことになります。 00:59:21.450 --> 00:59:21.730 そうですね。 00:59:22.930 --> 00:59:24.630 ご参加いただきありがとうございました。 00:59:26.030 --> 00:59:28.470 今回の対談の重要なポイントは、 00:59:28.850 --> 00:59:32.390 マイクロソフト365コパイロットの拡張性は 00:59:32.390 --> 00:59:34.770 単に高度なプロンプトを書くことではない、 00:59:35.050 --> 00:59:36.190 という点だと思います。 00:59:37.430 --> 00:59:38.430 私たちは今、 00:59:38.910 --> 00:59:41.330 コパイロットやエージェントが組織の知識、 00:59:41.630 --> 00:59:42.930 マイクロソフトグラフ、 00:59:43.370 --> 00:59:46.250 ビジネスアプリケーションAPIなどと連携できる 00:59:46.250 --> 00:59:48.610 アーキテクチャへと移行しているのだと思います。 00:59:49.590 --> 00:59:50.630 ええ、そうですね。 00:59:50.930 --> 00:59:52.070 コパイロットスタジオ、 00:59:52.390 --> 00:59:53.690 マイクロソフトファウンドリ、 00:59:54.030 --> 00:59:54.890 カスタム開発、 00:59:55.350 --> 00:59:57.390 そしてMCPのような技術は、 00:59:57.770 --> 01:00:01.310 開発者に素晴らしく強力なツールボックスを提供してくれます。 01:00:03.420 --> 01:00:03.660 ただ、 01:00:04.140 --> 01:00:06.040 エージェントが高度になればなるほど、 01:00:06.560 --> 01:00:07.320 アイデンティティ、 01:00:07.700 --> 01:00:08.120 権限、 01:00:08.520 --> 01:00:09.160 セキュリティ、 01:00:09.560 --> 01:00:10.220 ガバナンス、 01:00:10.560 --> 01:00:10.900 テスト、 01:00:11.380 --> 01:00:12.200 可観測性、 01:00:12.200 --> 01:00:16.780 アプリケーションのライフサイクル管理といった基礎がより重要になってきます。 01:00:18.990 --> 01:00:19.470 ですので、 01:00:19.890 --> 01:00:24.370 これらのトピックについて非常に素晴らしい概要を説明していただいたと思います。 01:00:24.950 --> 01:00:26.290 ご参加ありがとうございました。 01:00:27.050 --> 01:00:28.330 リスナーの皆さんは、 01:00:28.690 --> 01:00:33.090 MC65FMポッドキャストの小ノートで詳細を確認できます。 01:00:33.090 --> 01:00:37.370 そこから接続してEESの活動を見ることもできますので、 01:00:37.770 --> 01:00:39.670 本日は本当にありがとうございました。 01:00:39.670 --> 01:00:41.810 読んでいただきありがとうございます。 01:00:42.250 --> 01:00:44.910 あなたと過ごせて本当に楽しい時間でした。