皆さん、MC65FMポッドキャストへようこそ。今日は、マイクロソフト365コパイロットのプロンプトエンジニアリングに関する、最も一般的な議論の一歩先へと進みます。組織がコパイロットを本格的に使い始めると、疑問はすぐに、どうすればより良いプロンプトを書けるか?から、どうすればコパイロットを、自社で実際に動いているアプリケーション、データ、業務プロセス、そして知識とつなげられるか?絵と変化するからです。そこで興味深くなってくるのが、コパイロットの拡張性です。本日のゲストは、スイスのAIとワードグループでビジネスアプリケーションコンサルタントを務める、マイクロソフトMVPのイバス・ハーベスト氏です。イバス氏は、マイクロソフト365、アジュール、ダイナミクス365、パワープラットフォーム全般にわたり、特にエージェントやカスタム開発を通じたマイクロソフト365コパイロットの拡張に注力しています。今回は、マイクロソフト365コパイロットの拡張性、コパイロットスタジオ、マイクロソフトアジュールアイファウンドリー、名称変更が頻繁ですが、マイクロソフトグラフ、カスタム開発、MCPSなどについて深掘りしていきます。それではイバスさん、MC65ポッドキャストへようこそ。みなさん、こんにちは。お招きいただきありがとうございます。ここに参加できて、本当に良い機会をいただきました。呼んでいただき感謝します。ええ、こちらこそありがとうございます。技術的な話に入る前に、あなたのこれまでの経歴や、どのようにしてマイクロソフトエコシステムに関わるようになったのか教えていただけますか?ええ、はい、そうですね、もちろんです。実は正直に言うと、私のキャリアはマイクロソフトの世界から始まったわけではありませんでした。私のキャリアはAppleの世界から始まったんです。Macプラットフォームのソフトウェアエンジニアとして働いていて、その後iOSなどに移行しました。そして、ずいぶん昔のことですが、15年か20年くらい前でしょうか、マイクロソフトの世界に飛び込みました。正直に言うと、最初はシェアポイントのキャリアからスタートしました。

その後、クラウド、Azure、M365へと移行しました。オンプレミスのシェアポイントから始まり、その後あらゆるクラウドサービス、最終的にパワープラットフォーム、そして最近では全てのAI関連技術を扱っています。正直なところ、今やM365の大部分を占めていますからね。エージェント中心の転換期を迎えていますし、これが私のキャリアの概要です。私はソフトウェアエンジニアリングの世界でキャリアをスタートさせましたが、今では多くの人が忘れかけている言葉かもしれません。現在はあらゆるAI技術が存在し、活動や仕事の性質そのものがAIへとシフトしているため、20年前とは状況が大きく異なります。A、シェアポイントやグラフ、ダイナミクス、パワープラットフォームなどに関わってきたと伺いましたが、そうした経歴は現在のAI開発の時代に向けて、どのように役立っているのでしょうか。

基本的には、私の経歴は非常に多岐にわたるものです。

これまでキャリアの中で、数多くの製品に携わってきたからです。マイクロソフト製品だけでなく、それ以外の製品も扱ってきました。そのため、非常に幅広い技術やツールに関するスキルを持っています。

これまでのすべての経験が強力な基盤になっています。

今、AIは非常に広範なトピックであり、実現に向けたアプローチや技術が多岐にわたっているからです。エージェント型もあれば、ワークフロー中心のものなど様々です。ですから、正直なところ、これまでのすべての仕事で得たスキルが、現在のAIへの移行に向けた準備として役立っています。ローコードやノーコード、そしてプロコードのツールまで幅広く扱ってきました。

A、これまでの仕事におけるあらゆる機会や経験が、AIの世界で強みを発揮するための優れたスキルを私に与えてくれたのです。なるほど。そして現在は、AIテストリードという立場ですね。AIテストリードとは、具体的に何をする仕事なのですか?ああ、それは実に良い質問ですね。多くの人から同じことを聞かれます。

私の仕事は、機能要件を技術スタックに適合させることです。

ビジネス分析が完了した段階で、私がリードを引き継ぎます。AIを活用するためのユースケースが定義された後の段階ですね。シナリオやユースケースの定義が完了しています。ビジネス分析全体が完了した時点で、私がそのニーズを受け取り、裏側の技術スタックと照らし合わせて調整するのが私の仕事です。

その後、開発を開始する準備が整ったら、ツールやソリューションの実装全体を主導していきます。

興味深いですね。実際、多くの企業が従業員に研修、特にプロンプトエンジニアリングの研修を提供していますが、なぜそれだけでは不十分だと言えるのでしょうか?

今の時代、プロンプトエンジニアリングだけでいいという意味ですか?そうですね。ええ、なぜ、なぜ、なぜ、なぜ彼らは、

なぜ、その、企業にとって、プロンプトエンジニアリングを教えるだけでは不十分なのでしょうか?ああ、なるほど、わかりました。ええ、そうですね。正直に言うと、先ほど申し上げた通り、今は多様なツールや技術があふれています。ある段階までは、AIが何をすべきかを理解し、多少のガイドをしてくれることもあります。しかし私としては、例えばアーキテクトやソフトウェア設計者の役割には、背景に人間が存在する必要があります。顧客の意図を理解しなければならないからです。基本的には、AIが顧客の状況を理解しきれないこともあります。

全体像は見えていても、裏側ではプロンプトエンジニアリングに集中するだけでは不十分な場合があります。

もっと多くの要素が必要です。舞台裏には、アーキテクトやソフトウェアエンジニアといった専門家、そしてシェアポイントやワンドライブ、あるいはセールスフォースといった情報技術に精通した人材が必要なのです。

そうした技術のスペシャリストが不可欠です。なぜなら、AIは多くのことを理解できても、ガイド役に離れるからです。素晴らしい技術文書や機能使用書を作成できますが、それが適切かどうかを判断する人間が舞台裏に必要です。顧客のニーズを満たしているか、すべてを検証する作業があります。プロンプトエンジニアリングだけに集中していては、それは難しいでしょう。

現時点では、スキルを習得する時間や投資の余裕がない場合の選択肢にはなり得るかもしれません。

ですが正直なところ、ソリューションを構築するには、基礎となる技術の優れたスキルが不可欠だと私は考えます。ええ、その通りです。あなたはコパイロットの拡張性の専門家ですよね。

標準のマイクロソフト365コパイロットはどこまでで、コパイロットの拡張性はどこから始まるのでしょうか?

ああ、いい質問ですね。正直なところ、2年前にコパイロットがリリースされた当初の最初のバージョンでは、チャット機能は本当に最小限のものでしたから。

基本的には、そうですね、チャットGPTのようなものでしたが、マイクロソフトはマイクロソフト365コパイロットを大きく進化させました。現在は様々な機能が備わっており、以前と比べて拡張性の意味合いが変わりました。以前はプラグインなどを開発していましたが、正直なところ今は、オーケストレーターをカスタマイズしたい場合や、ユーザーインターフェースをよりパーソナライズしたい場合、例えばエージェントをマイクロソフト365チャットだけでなく自社のウェブサイトにも統合したいといった場合に拡張が必要になります。

つまり、裏側の仕組みをもっとカスタマイズしたいという時に、拡張性が求められるようになったのです。オーケストレーターのカスタマイズやインターフェースの調整、あるいはコパイロットチャットでは対応できない、あるいは回答できないような様々な側面をカスタマイズしたい場合などがそれに当たります。

そして、多くの人がエージェントについて語っていると思います。ええ、それは、なぜこれほどまでに多くの人がコパイロットエージェントについて考えているのか、そしてなぜ全てをカバーする大きなコパイロットを一つだけ作らないのか、という点についてです。

ええ、本当に興味深いですね。正直なところ、先ほど申し上げた通り、マイクロソフトは大きく進化しました。

もし6ヶ月前であれば、エージェントが話題の中心でした。

しかし今は、マイクロソフトがコパイロットの共同作業機能を導入したことで、正直なところ、多くのエージェントがその機能に置き換わるようになりました。ただ、私たちが今エージェントについて考えるのは、単に物事を整理するためです。現在はマルチエージェントモデルに移行しており、各エージェントがそれぞれのスコープと責任を担っているからです。一つの巨大なコパイロットを作らない理由は、単純にパフォーマンスの問題です。まず、指示やツールが膨大になると、パフォーマンスの面で収集がつかなくなってしまうからです。そして、現在のアーキテクチャはマルチエージェント化が進んでいます。コパイロットスタジオを使う場合もあれば、独自のコードやカスタム開発によるエージェントを使う場合もあります。しかし最近では、パフォーマンスの観点から各エージェントに独自のスコープと責任を持たせ、エージェントのアーキテクチャを明確にするマルチエージェントのアプローチの方が優れています。

はい、ショーペンハウアーですね。そして、基本的なAIエージェントのアーキテクチャを見ると、私はこう考えます。

いくつかのキーワード、総パスワードですね。分かりました。ですが、推論、ツール、知識、そして指示について考えなければなりません。これらは、AIエージェントのアーキテクチャにどのように組み込まれるのでしょうか?

まず最初に考えるべき、回答しなければならない問いの一つは、目標は何か?ということです。そのエージェントの最初の目的ですね。基本的にエージェントのアーキテクチャは、ローコードアプローチかカスタム開発アプローチかによって大きく異なります。というのも、カスタム開発では全てを自分で管理する必要があるからです。つまり、セキュリティ、ホスティング、その他多くの様々な要素を管理します。ローコードアプローチでは状況が大きく異なります。指示を与え、ツールを選択することに専念できるからです。基本的に、ローコードでのアーキテクチャは今私が言ったほど単純ではありませんが、指示の定義、ツールの選択、必要に応じて他のエージェントとの接続が迅速に行えるため、非常に高速です。

しかし、カスタム開発で独自の開発を行う場合は、話が少し変わってきます。例えば、セマンティックカーネルやエージェントフレームワークといったものですね。アーキテクチャは、セキュリティのような非常に高度な概念を扱う必要があるため、かなり複雑になります。なるほど。認証の観点では、マルチツールを使用する場合や、NCPを統合したい場合、あるいはリバースプロ機種で保護された社内ツールに接続したい場合などが考えられます。

ですから、コパイロットスタジオなどでカスタムエージェントを扱う際には、アーキテクチャについてより深く検討する必要があります。アーキテクチャの観点で見ると、カスタム開発アプローチでは定義を迅速に行うことができます。ただ、高度な概念を扱う必要があり、それは非常に基礎的な側面であるため、多くの人にとって難しいと感じられるかもしれません。そして、正直なところ、私の仕事では多岐にわたるニーズに対応しています。カスタム開発の場合もあれば、コパイロットスタジオの場合も、エージェントビルダーを使ったごくシンプルなエージェントの場合もあります。つまり、アーキテクチャの定義は、どの手法を取るかによって決まるのです。基本となる一般的なアーキテクチャは作成できますが、最終的にはローコードかフルコードか、どちらのアプローチを選ぶか次第ですね。ええ、そうですね、ええと、ですが、

典型的なエンタープライズAIエージェントの構造について説明していただけますか?

はい、もちろんです。

基本的には、できるだけシンプルに話すと、例えば、ITサポートエージェントのようなニーズがある場合、いくつかの構成要素が存在することになります。

ただ、最近は先ほど言ったようにマルチエージェントのアプローチを取ることが多く、私は最初のエージェントをフロント、つまり窓口として配置しています。これがフロントエージェントで、このエージェントがあらゆるリクエストを、例えば他の異なるエージェントへと振り分ける役割を担います。例えば、ユーザーがセールスフォースについて質問した場合、そのリクエストすべてをセールスフォースのITサポートエージェントへと転送します。お分かりのように、私たちは顧客のためにこのようなアーキテクチャを構築してきました。各エージェントがそれぞれのスコープを担当するためです。それはセールスフォースのような製品であったり、あるいはM365のようなものかもしれません。その背後で、各エージェントは一連の指示とツールセットを持っています。最近では、MCPサーバーを使うのがより良いでしょう。MCPサーバーはAIにマルチサービスを統合するためのユニバーサルなプラグインだからです。そのため、私はMCPサーバーのセットに加え、いくつかの内部知識ソースも用意しています。それはJiraのようなものや、サービスナウのナレッジベースのようなものですね。つまり、エージェントごとに一連の指示があるわけです。

そしてその指示がエージェントの範囲と役割を定義し、さらに一連のMCPサーバーやPDFファイルといった知識ソースを活用します。

ですから、多種多様なデータソースを扱うことができるのです。

ユーザーがメインエージェントにリクエストを送った後、そのエージェントは、このタスクは担当のエージェントに委任すべきだと判断します。

では、その可能性について少し見ていきましょう。

コパイロットスタジオは、全体のアーキテクチャの中でどのような位置づけになるのでしょうか。正直に言うと、コパイロットスタジオはマイクロソフトが提供するローコードツールです。まず、アーキテクチャの観点から見ると、コパイロットスタジオはまさに、基本的には開発者ではない人、メーカーのために定義されたものだと言えます。アーキテクチャの面で言えば、先ほど挙げたITサポートの例で言うと、コパイロットスタジオはうまく適合します。

なぜなら、アーキテクチャの観点からコパイロットスタジオは期待通りの役割を果たすからです。外部や内部のナレッジソースを簡単に統合できますし、必要な設定も可能です。ただ、先ほども言ったように、もしオーケストレーターを少しカスタマイズしたいというユースケースがある場合、コパイロットスタジオの裏側ではオーケストレーターをカスタマイズすることはできず、AIオーケストレーターを有効にするかどうかの選択肢しかないからです。例えば、達成したいタスクの優先順位をカスタマイズすることはできません。コパイロットスタジオの裏側で計画が定義され、それが実行される仕組みだからです。しかし、さらなるカスタマイズが必要な場合は、セマンティックカーネルやラングチェーンといったフレームワークを用いたカスタム開発が必要です。

最近ではマイクロソフトもフレームワークをリリースしており、これを使えばオーケストレーションを簡単にカスタマイズし、ワークフローを定義して思い通りに作り込むことができます。

コパイロットスタジオというアーキテクチャは、エージェントを非常に簡単に構築できるため、まさにビルダーやメーカーのために定義されたものなのです。コパイロットスタジオの唯一の懸念点は、パスやアーキテクチャを選択する際にライセンスについて注意しなければならないことです。今やどんなソリューションにおいても、それは非常に大きな要素となっているからです。現在、コパイロットスタジオは重量課金モデルへと少し進化しており、コスト見積もりに注意が必要です。達成したい目標によっては、独自に開発した方が良い場合があります。その場合、好きな場所にホストし、すべてのコストを自分で管理できるため、現在よりも容易に見積もりが可能です。というのも、コパイロットクレジットのアプローチでは、1ヶ月や2ヶ月といった期間でどれくらいのコストがかかるのか、予測が難しい場合があるからです。では、コパイロットスタジオの制限とは一体何でしょうか。スタジオについてですが、私が何を選択すべきか迷うとき、マイクロソフトファウンドリ、アジュールファウンドリでしたか、正式名称は定かではありませんが、お考えます。そして、よし、完全にカスタム開発をしなければならないと判断するときがあります。

最初の質問は、オーケストレーションをカスタマイズする必要があるか?ということです。それが私にとって最初の問いです。

なぜなら、もしオーケストレーションのカスタマイズや、仕組みや計画生成の深部まで踏み込む必要がなければ、コパイロットスタジオのようなローコードアプローチ、例えばビルダーなどが使えるとわかるからです。また、単純なユースケースであれば、こうしたツールを使用することも可能です。しかし、オーケストレーションをカスタマイズしたいなら、特定の実装に進む必要があります。その場合、モデルにはファウンドリを使うか、あるいは独自のプラットフォームを持つことになります。カスタム開発の利点は、マイクロソフトファウンドリでホストされていないモデルも統合できる点です。

必要であればファウンドリのモデルも使えますが、AWSやGoogleプラットフォームを利用していて、例えばジェミニを使いたい場合や、外部にモデルをデプロイしている場合でも、カスタムアプローチならそれらを直接エージェントに統合できる能力があるのです。これも利点の一つです。その後、オーケストレーションや計画の生成方法をカスタマイズでき、すべての要素をエージェントのファウンドリに組み込むことができます。現在のファウンドリの問題は、当初は単なるモデルホスティングプラットフォームだったということです。数年前を振り返ると、ただシンプルなモデルカタログがあり、それをデプロイするだけの存在でした。現在、マイクロソフトはこの製品を進化させ、コパイロットスタジオのようなユーザーインターフェースを使って、コードなしでエージェントを作成できるようになりました。ガバナンスを含め、多くのことを管理できるようになっています。これは、コパイロットスタジオのようなローコードで、真にエージェント志向のプラットフォームになりました。今日、ファウンドリは急速に進化しているため、エコシステムの中でどのような位置づけにするかが非常に難しくなっています。

基本的にマイクロソフトはいくつかの機能を導入しましたが、それらはコパイロットスタジオとMCP統合などの点で、違いというよりも類似点が多いように感じます。

しかし、コパイロットスタジオの主な制限はモデルに関するものです。コードを統合したり、何かを可視化したりする機能は備わっています。ですが、例えば独自のモデルを統合したい場合、特定のバージョンが必要だとしても、それはできません。独自のLLMプラットフォームなどを統合するには、カスタム開発が必要です。AWS上に独自のプラットフォームを持つ顧客もいますが、その場合、外部で管理される価格設定でそのモデルを統合できます。

なるほど、そうですね。エージェントを構築する際、あるトピックが非常に重要だと思います。

はい、それはショーペンハウアー、失礼。多くの人が話しているのは、MCP、つまりモデルコンテキストプロトコルのことです。なぜそれがエージェント開発における最大の話題の一つになっているのでしょうか。また、まだ触れたことがない人のために、モデルコンテキストプロトコルとは何か教えていただけますか? A、大きなキーワードですね。多くの人が話題にしているのは、これが主要な問題を解決するからです。

AIに対するツールやスキル、あるいは外部ツールの統合をいかに統一するかが課題でした。

以前はMCPがなかったため、サービスごとに通信方式が異なり、非常に混乱していました。技術的なプロトコルもアーキテクチャのアプローチもバラバラでしたが、MCPはその統合を統一してくれます。

AIエージェントであれ、より一般的なAIソリューションであれ、外部ツールや内部ツールを統合する手段として、今やMCPが主流です。

技術的な統一が図れるため、MCPは今やAIアーキテクチャの重要な一部となっています。今日において、それは非常に重要なポイントです。以前はAPI統合が中心でしたが、今はMCPの時代だからです。なるほど、これは、ええ、進化というわけではありませんが、これまではエージェントをAPIと統合していました。認証の方法や管理、ツールの呼び出し方などを自分たちで制御する必要がありました。今ではAIが、このツールが使えるから、目標を達成するために必要なものを選ぼうと判断できます。では、MCPとAPI接続とでは、何が本当に変わったのでしょうか。

基本的には、これまでの統合という観点では、APIはインテリジェントではありませんでした。

APIは単に、ツールを呼び出すとデータを返すだけのものでした。MCPとの違いは、アーキテクチャの面でMCPの方がよりインテリジェントであることです。裏側には、単にデータや情報を返すツールだけでなく、スキルや指示、その他様々な要素があり、それがMCPを真にインテリジェントにしています。基本的に、MCPはAIに対してこう言えます。なるほど、これを達成したいんだね。リクエストに一致する正確なツールを提供するよ。ユーザーは単一のツールだけでなく、目的を達成するために必要な複数のツールを呼び出すことができます。これこそがMCPの役割です。AIに対して、使えるツールはこれだと示し、その上で、これやあれ、あるいは複数のツールを組み合わせて目的を達成できるよと教えるのです。AIにあらゆるものの真のコンテキストを与えてくれます。APIは単にツールと説明があるだけで、それ以上のものではありません。

では、モデル・コンテキスト・プロトコルというのは、メタデータのようなものなのでしょうか?それともどのような仕組みなのですか?いいえ、違います。MCPの裏側は、単なるプロトコルに過ぎません。基本的には技術的なプロトコルです。その裏側には、確かにメタデータや説明はありますが、それ以上にAI向けのスキルが記述されており、AIに特化しているのです。基本的には、スキルや指示が備わっており、AIが、このツールはこう動く、あのツールはこう動く、とより深く理解できます。そして、これらのスキルを呼び出し、MCPサーバーに情報を要求して、自分のタスクを達成しようと判断できるのです。ですが、メタデータの一部は必要です。ツール名や、裏側で何が行われているのかを定義しなければならないからです。ねえ、私たちは、未来はMCPだと言えるのでしょうか。企業には組織内に何百ものREST APIがあるわけですが、それらの周りにMCPサーバーを構築し始めるべきなのでしょうか。はい、その通りです。基本的にMCPサーバーは裏側でAPIと連携して動作します。基本的には、これは置き換えではありません。まとめると、MCPサーバーは単なる窓口だと言えます。コンテキストを提供し、その裏側でMCPがAPIを呼び出すことができるのです。裏側ではそうですが、MCPサーバーはフロントエンド、つまり呼び出す必要のあるフロントツールです。なぜなら、その背後でリクエストの振り分けが行われるからです。裏側ではAPIであったり、データベースであったり、複数のツールであったりする可能性があります。ですが、例えば社内に財務サービスや人事サービスといった様々なAPIやサービスがあり、独自のMCPサーバーを持ちたい場合、裏側ですべてのAPIを扱う必要があります。

MCPサーバーは、それらのAPIがどのようなサービスなのか、利用可能なツールは何か、スキルは何かといった情報をすべて公開しなければなりません。うん。その後、裏側で認証を処理する必要があります。APIによって仕組みが異なり、キーによる認証やその他の方法があるからです。そのため、そうした対応が必要になりますが、MCPは利用可能なツールを公開し、その裏側でツールが複数のAPIを呼び出せるようになります。一つのAPIであっても、裏側には様々なアーキテクチャが存在し得ます。なるほど。それで、MCPはどのようにして、適切なツールを選ぶのでしょうか?例えば、100とか500のAIエージェントがある場合です。Aと、それはまず最初に、基本的にエージェントにリクエストが来ると、利用可能なすべてのツールを探索することになります。MCPサーバー側で、よし、利用可能なツールはこれらすべてだと確認するわけです。基本的には、エージェントのオーケストレーターが、よし、これがあるな、LLMが使えるな、と理解します。その後に、プランを作成します。少しまとめると、実行するアクションを含むプランを作成し、そのアクションの中で、ユーザーが要求したタスクを達成するために、1つ、2つ、3つ、あるいはそれ以上のツールを呼び出すことができます。つまり、エージェントのオーケストレーターがMCPツールを理解し、要求に最適なものを選択するわけです。お分かりですね。これこそが、ツールの選択などを行うオーケストレーターの役割であり、もちろんLLMの助けも借ります。

LLMがNOの一部であり、オーケストレーターはLLMやツールと連携して、タスクを達成するための最善の選択と計画を立てるからです。

A、以前は多くの企業がパワーシェルから始めていましたが、今ではマイクロソフトグラフAPIを使っていますね。

グラフとMCPの関係はどうなっているのでしょうか。

実のところ、正直に言うと、グラフ用のMCPというものは存在しません。マイクロソフト365の世界では、マイクロソフトが多くのMCPサーバーを導入しており、それらのMCPサーバーは裏側でマイクロソフトグラフに基づいています。

例えば、チームのMCPサーバーを使いたい場合、裏側ではMCPサーバーを使う際にグラフAPIが呼び出されています。つまり、マイクロソフト365の世界においてグラフAPIは中心的な存在です。MCPが裏側でグラフと通信し、リクエストを正しく処理しているからです。ですが、現在ではコパイロット全体においてもグラフは中心的です。コパイロットのセマンティックインデックスは生データに基づいているからです。実際には、MCPサーバーを通じてグラフを利用していることになります。最近では、そういった形になっています。

マイクロソフト365には、組織のコンテキスト、ドキュメント、会議、メール、人、チーム会話、そして共有コンテンツといった計り知れない価値が含まれています。そうしたコンテキストをどうすれば、A、セキュリティ上の悪夢を生み出さずに公開できるのでしょうか。ガバナンスといった観点での話でしょうか。ええ、それは常に問題です。多くの人が適切なガバナンスを裏側で整えずにエージェントを構築していますから、エージェントを構築したいとします。よし、始めましょう。構築して展開しますが、その後、このエージェントは大量のデータを扱うことになります。それをどう管理すればいいのでしょうか。最初の疑問は、エージェントのガバナンスをどう導入するかということです。そのままでは、おっしゃる通り、混乱を招く可能性があります。多くの人がエージェントやAIソリューションを構築したいと考えていますが、舞台裏では、例えばマイクロソフト365環境の場合、最初に行うべきことはデータを理解することです。データを理解しなければ、どうすればいいかわからなくなります。データを理解する必要があります。なぜなら、扱っているデータが機密情報かどうかを把握することが重要だからです。極めて機密性の高いデータを扱っているのでしょうか。そうです。データを理解する必要があります。その後、マイクロソフト環境であれば、DLP機能や秘密ドラベルといった仕組みを導入する必要があります。これがないと問題になる可能性があるからです。

さらに、データを整理する必要もあります。

データの質が低ければ、エージェントは期待通りに動作しません。

シェアポイントやチームのチャンネルなどが乱雑であれば、エージェント的なアプローチで正しく機能させることは困難だからです。

結論として、データを理解し、認証やパービューのような基本的なセキュリティ機能を導入する必要があります。

パービューは、こうしたセキュリティやガバナンスを整えるための中心的なソリューションとなっています。

データのクレンジングと基本的なセキュリティ対策が済んだら、次はライセンスについても理解する必要があります。

エージェントの構築を始める前に、開発者がそのための訓練を受けているか、適切なライセンスがあるか、あるいはサブスクリプションが必要かといった点を確認しなければなりません。

大きな問題の一つはツールです。全てのツールを自分の開発環境やエージェントにどう統合すれば適切か、何か制限を設ける必要があるかなど、正直なところ大きな課題です。

考慮すべき活動は多岐にわたりますが、私にとって最も重要なのは、データを理解すること、です。企業が自社のデータを理解していなければ、最初から問題になるでしょう。

なるほど、えーと、私たちがどのように、私たちは、えーと、それを尋ねましたっけ?うーん、セキュリティのトピックですね、えー。そこに、2つの、そうですね、2種類の人がいると思います。一方はユーザー権限が必要だと言い、もう一方はアプリケーション権限が必要だと言います。

エージェントは一般的にどう動作すべきでしょうか。一般的に、私の一番の推奨は、エージェントソリューションを扱う際は常に、ユーザー権限、つまり委任された権限で行うことです。セキュリティの観点から言えば、その方がユーザーは自分がアクセス権を持つデータやツールのみを扱うことになるため、正直なところ安全です。

それです、それが最も重要な原則です。その上で、特定のAPIや特定のコンテキストのためにアプリケーション権限が必要な場合は、それも可能です。

ただし、アプリケーション権限を直接使用するのではなく、ラッパーというコンテキスト内で処理してください。

例えば、MCPサーバーのようなものを作成し、その背後でアプリケーション権限を持つMCPを統合するのです。そうすれば、MCPが裏側でアプリケーション権限を使ってAPIを呼び出し、必要な情報を返してくれます。

ユーザーはアプリケーション権限を直接扱う必要はありません。ユーザー権限でMCPサーバーなどを呼び出し、MCPサーバーが裏側で、専用のアプリケーション権限を使って各サービスやアプリケーションを呼び出すのです。その違いがわかりますか?なるほど、興味深いですね。アーキテクチャについて考える際は、もう少し深く掘り下げる必要があると思います。アーキテクチャには大きく分けて3つの重要なトピックがあると思います。検索拡張生成、ラグ、ナレッジトピック、そしていわば裏口的なエンタープライズ検索について扱います。えーと、まずはラグから始めましょうか。ラグはアーキテクチャのどこに位置するのでしょうか?あー、ラグですね。正直に言うと、パフォーマンスの観点から言えば、ラグはまさに最も重要なものです。

AIは様々な種類のデータを理解する必要があり、ラグは基本的に質問に回答するために存在しているからです。

なぜなら以前は、ラグがなかった頃は、基本的に異なるアプローチで対処する必要があったからです。古いやり方というわけではありませんが、当時は複雑でした。しかしラグは中心的な存在です。ラグは様々な種類のデータを理解し、AIが必要とする情報をドキュメントなどから検索するからです。それは多様なデータ形式であっても構いません。ですから、そう、現代のAIアーキテクチャにおいてラグは中心的な役割を担っています。ええ。ですが、多くのユーザーにとって裏側で動いているラグの話をしても、それが何なのかわからないというのは事実です。なぜなら、最近のマイクロソフトや多くのソフトウェア企業は、あえてその点について公言しないからです。裏側ではラグが動いていても、例えばコパイロットスタジオのユーザーは、裏でラグが働いていることを理解していません。深く掘り下げればそういう概念だとわかりますが、多くのユーザーにとってラグは全く未知のものです。彼らはツールを使っているだけで、裏側で何が起きているかを知らないのです。そこで次のトピックに移りますが、知識についてです。AIシステムはどうやって知識を得ているのでしょうか。自分で収集しているのか、それともどういう仕組みなのでしょうか。実は正直に言いますと、知識というのは、多くの異なるシステムにホストされている可能性があります。

プレーンテキストファイルの場合もあれば、マークダウンファイルやナレッジベース、あるいは何であっても構いません。しかし実際には、MCPサーバーがあれば、そうした知識にアクセスできます。あるいは、例えばシェアポイントへのコネクタなど、今日では多くのサービスへのコネクタが用意されています。ですから、正直なところ、以前よりも知識へのアクセスは容易になっています。というのも、かつてはプラグインを構築して、すべてを個別につなぎ合わせる必要があったからです。今日では、あらゆるシステムへの直接的なコネクタがあり、大規模な開発スタッフを抱えることなく、知識を統合することができます。私は、よくあることだと思いますが、例えば私のチームの誰かに話をするような感じです。では、AIは準備ができていない文書や古い文書、あるいは重複した文書をどのように理解するのでしょうか。

どのように、どのようにAIシステムはこれを理解できるのでしょうか。私たちは何を使うべきなのでしょうか。

基本的にラグを使用するのは、背後で自分のデータが何であるかを理解する必要があるからです。ですが、正直にまとめると、まずはプロンプトから始まりますよね。

ユーザーは、例えばナレッジベースやワンドライブなどを横断して検索したいと考えます。

背後では、オーケストレーターがLLMの助けを借りてプロンプトとユーザーの意図を理解すると、インデックスが機能します。例えば、コパイロットにはセマンティックインデックスがあり、これがすべての知識を把握しています。

AIはこれに直接クエリを投げてラグを実行し、ニーズに基づいて適切なドキュメントを選択できます。

コパイロットにはこのセマンティックインデックスがあり、AIは背後で自然言語を使って直接このインデックスにクエリを投げることができます。例えば、会社のVPNをどのように設定すればよいか知りたいと尋ねるとします。

背後でセマンティックインデックスに対してラグが実行され、会社のVPN設定がすべて含まれるドキュメントが取得されます。例えば、Microsoft 365コパイロットチャットの背後にはグラフAPIがあります。先ほど申し上げた通り、セマンティックインデックスはグラフAPIの上に構築されているからです。背後にあるのはグラフの機能ですが、カスタム開発の場合は、例えば背後にファウンドリーAQが存在します。それは以前、別の名前で呼ばれていたAzureサービスでした。しかし現在では、必要であれば独自のラグシステムを構築できます。基本的には、カスタムエージェントがあれば、ファウンドリーAQインスタンスに対して直接質問することができます。なるほど。例えば、会社のVPN設定情報を取得したい場合、AIが必要なドキュメントを検索してきてくれます。PDFやWord、Excelといったファイルのことですね。

そして、それが検索の仕組みですよね。

あるいは、裏側の仕組みのことですか?はい、ああ、裏側の仕組みですね。そうです。検索機能があります。

現在、コパイロットチャットの裏側には3つの機能があります。

1つ目は標準的な検索で、キーワードを入力してドキュメントなどを検索するシンプルなものです。

これが単純検索です。Googleのようなキーワード検索は誰もが知っていますね。その後に、2つの異なる機能があります。まず、裏側でラグが動いています。グラフ内でのラグ機能があり、さらに、

コパイロットのセマンティックインデックス検索もあります。これは少し異なり、ラグの型がセマンティックインデックス検索よりも高度なものとなっています。

これら3つの機能をAIが裏側で使い分けることで、ワンドライブやチーム、M365全体からデータを取得できます。コパイロットのセマンティックインデックスには、コパイロットコネクタも含まれます。例えば、セールスフォースをコパイロットコネクタで接続すれば、セールスフォースやサービスナウ、その他のツール内にあるデータも横断的に検索可能です。コパイロットコネクタによって、全てのデータがグラフのセマンティックインデックスに統合されるため、外部システムに対して直接クエリを実行できるのです。なるほど。分かりました。次に、エージェントを構築する際のガバナンス、特にエージェントのライフサイクル管理についてですが、実際にはどのような形になるのでしょうか。

実際のところ、どうなっていますか。正直に言うと、マイクロソフトのエコシステムでは非常にシンプルです。というのも、コパイロットスタジオのようなローコード環境を扱う場合、パワープラットフォームを扱うことになるからです。概念は同じで、何も変わっていません。ソリューションがあり、アルムが整備され、パイプラインも利用できるのです。コパイロットスタジオを扱う場合、正直に言ってこれまで通りです。パワープラットフォームのガバナンス、ライフサイクル、アルムに投資してきたすべてがそのまま活かせるからです。全く同じことなのです。これは良いことで、多くの人から、コパイロットスタジオはどう管理すればいいのかと聞かれます。何かが違うのでしょうか。と、いいえ、パワーアップスやパワーオートメートのアプリケーションライフサイクル管理と全く同じで、とてもシンプルです。つまり、今回はエージェントのライフサイクル管理ですが、裏側にある概念はパワープラットフォームと同じなのです。

例えばカスタム開発を扱う場合、基本的には.netアプリケーションなどを構築するのと同じで、すべてをコードとして管理します。

フレームワークやセキュリティの側面など、そういったものがあるからです。ですから正直なところ、アプリケーションやエージェントのライフサイクル管理という点では、これまでと概念は全く同じです。私にとってこれは良い点です。ライフサイクルプロセスなどに多大な投資をする必要がないからです。

唯一の変更点は、LLMやデプロイなどについて考慮する必要があるという大きな変化があることです。しかし裏側では、パイプラインなどを使った過去のDevOpsアプローチとよく似ています。ですから私の考えでは、エージェントを管理するという点では何も変わっていません。A.カスタム開発であれコパイロットであれ、正直なところ今日のアプローチは以前と同じなのです。そして、つまり企業がこれまでAIを使っていなかったとしても、パービューやディフェンダーなどのツールが完璧に設定されていれば、

何か変更が必要なのでしょうか、それともそれがAIへの準備ができているということなのでしょうか。

それは非常に大きな問いです。マイクロソフトにおけるAIへの準備は、まあ問題ありません。シェアポイントの権限管理などもそうですが、AIへの準備というのは技術的なアプローチだけではありません。技術的なことは何をすべきか分かっています。多くのサービスにわたる権限管理が必要だということは分かっていますよね。私にとって、AIへの準備とは、データ、つまりデータを理解することも含めなければならないのです。なぜなら、先ほども言ったように、自分のデータを理解していなければ、技術的な側面を管理することはできません。例えば、何が機密情報で何がそうでないのか分からなければ、セキュリティ対策を講じるのは困難だからです。しかし、マイクロソフトに従うならば、AIレディネスとは、権限を管理し、秘密ドラベルを設定し、GDPRなどの対応を整えるといったことになります。

ですが、もっと高次元な側面もあります。私にとって、AIレディネスは技術的なものだけではありません。正直なところ、今日では考慮すべき機能的、あるいは高次元な側面もあるのです。

ええ、それは非常に興味深いです。多くの企業がAIを使い始めましたが、エージェントが登場した今、多くの企業が、AIがメールをすべて削除したのではないか、とか、何か悪いことをしているのではないかと懸念しています。うーん、

企業がAIを恐れている理由について、どう思われますか?

いい質問ですね。私はスイスに住んでいて、そこには多くのプライベートバンクがあり、正直なところ、非常に機密性の高い顧客を抱えています。そのため、最も重要なのは、データはどこで処理されているのか、という点なのです。基本的にはそうですし、AIが私のメールを検索しているのか、といった懸念もあります。そういった類のことです。舞台裏では常にそうした質問がなされています。

彼らにとって最も重要なのは、データがどこで処理されているのかを理解する必要があるという点と、私がAIの、という点です。

所有者である、という点です。私がAIに指示を出すと、AIが裏で作業を実行します。彼らは例えば、自立性、という側面を恐れています。

現代では指示を出せば裏で、AIが検索やクエリを実行しますが、彼らは、私がAIに何かを頼んだとき、裏で何が実行されているのかを恐れているのです。

ええ、そのように多くの疑問が投げかけられています。なるほど。AIエージェントや、AIサービスといったものの背後にある全プロセスを、どのように制御すればよいのでしょうか。ええ、そのような質問はいくつかありますね。ですが、これは導入やトレーニングに関する問題でもあります。AIを理解し、裏側で何が実行されているのかを把握するためのトレーニングを導入する必要があります。透明性も重要なポイントです。すべてのAIソリューションに透明性を組み込む必要があります。私にとって透明性は大きなテーマです。AIソリューションは透明でなければならないため、すべてを適切に導入しなければなりません。舞台裏で何が行われているか、どのデータがクエリされているかを理解し、すべてを追跡し、ログに記録する必要があります。今日では、ソリューションを持つ以上、すべてを透明にする必要があります。裏で何が実行され、どのデータが処理され、どのような根拠に基づいて推論されているかを正確に理解する必要があるからです。なるほど。どのようにしてこの計画を生成したのか、どのような事実に基づいているのか、といったことです。素晴らしい。おっと、時間が少し足りなくなってきましたね。ですから、はい、すみません。本当に素晴らしい内容でした。ですが、どのポッドキャストでも恒例のラピッドファイアラウンド一問一答の時間です。では、私が短い文章を言いますので、短い答えを返してください。はい、準備はいいですか?はい。コパイロットスタジオか、カスタムコードか?コパイロットスタジオですね。マイクロソフトファウンドリか、コパイロットスタジオか?コパイロットスタジオです。タイプスクリプトか、それともタイプクリプトか?

GitHubか、Azure DevOpsか? GitHubです。ラグか、ファインチューニングか?なるほど。マイクロソフト365APIの中で最も過小評価されているものは何でしょう?

ラグAPIですね。2026年に全てのマイクロソフト開発者が学ぶべき技術を一つ挙げるとすれば、GitHubコパイロットです。

サティアナデラがあなたのところに来て、我々のAIプラットフォームをより良くするために、必要な資金とリソースをすべて提供する、と言ったら、何か一つ機能を開発できるとしたら、それは何になりますか?私たちが必要としているガバナンス関連のすべてですね。

そして、次に誰をポッドキャストに招待すべきか、またどのような質問をすべきでしょうか?

いい質問ですね。友人はたくさんいますが、そうですね、多くのカンファレンスで共同登壇している相手に聞いてみてはどうでしょう?例えば、黒江もろに聞いてみてください。彼女は以前は機能コンサルタントでしたが、現在は技術的な側面に携わっています。ダイナミクスの世界における、技術的すぎない機能面での話として、彼女はとても興味深いストーリーを持っていますよ。彼女を招いて今の時代、機能面と技術面の業務をどう両立させればいいのか、大きな課題があるはずだから教えてほしいと聞いてみてはどうでしょうか?そうですね、では最後の質問です。今回のセッションから何か一つ学びを持ち帰るとしたら、何を持ち帰るべきでしょうか?このセッションからということですね。つまり、

AIは急速に進化しています。最新情報を追うなら、すべてをフォローする必要があります。正直なところ、今のAIはマイクロソフトのスタック全体に広がっていますから、

今の時代、理解しておくべきは、進化が非常に早いということです。常に最新の状態を持たなければ、学びや進化の理解を怠った時点で、何かを見逃してしまうことになります。

そうですね。ご参加いただきありがとうございました。今回の対談の重要なポイントは、マイクロソフト365コパイロットの拡張性は単に高度なプロンプトを書くことではない、という点だと思います。私たちは今、コパイロットやエージェントが組織の知識、マイクロソフトグラフ、ビジネスアプリケーションAPIなどと連携できるアーキテクチャへと移行しているのだと思います。ええ、そうですね。コパイロットスタジオ、マイクロソフトファウンドリ、カスタム開発、そしてMCPのような技術は、開発者に素晴らしく強力なツールボックスを提供してくれます。

ただ、エージェントが高度になればなるほど、アイデンティティ、権限、セキュリティ、ガバナンス、テスト、可観測性、アプリケーションのライフサイクル管理といった基礎がより重要になってきます。

ですので、これらのトピックについて非常に素晴らしい概要を説明していただいたと思います。ご参加ありがとうございました。リスナーの皆さんは、MC65FMポッドキャストの小ノートで詳細を確認できます。そこから接続してEESの活動を見ることもできますので、本日は本当にありがとうございました。読んでいただきありがとうございます。あなたと過ごせて本当に楽しい時間でした。