WEBVTT

00:00:00.080 --> 00:00:05.000
ナレッジナゲットへようこそあなたが会社を経営していて優秀な専門家チームを雇ったと想像してください

00:00:05.000 --> 00:00:08.860
世界クラスの旅行プランナー従業員オンボーディングの専門家そしてITサポート担当者です

00:00:08.860 --> 00:00:10.960
しかし彼らは誰一人として互いに話をしません

00:00:10.960 --> 00:00:15.440
2人の協力が必要なタスクが発生するたびにあなたが彼らのデスクの間を行き来して情報を自分で伝えなければなりません

00:00:15.440 --> 00:00:17.980
今のAIエージェントの多くはまさにその状態です

00:00:17.980 --> 00:00:21.120
明らかにチームワークが必要な問題であっても個別に動作してしまいます

00:00:21.120 --> 00:00:25.660
そこで今日はエージェント同士がどのように通信し作業を引き継ぎ本物のチームのように動けるかについてお話しします

00:00:25.660 --> 00:00:28.720
私はミルコピーターズですこれは未来の話ではありません

00:00:28.720 --> 00:00:31.120
マルチエージェントオーケストレーションはすでに実現しています

00:00:31.120 --> 00:00:33.780
それを支えているのがA2Aと呼ばれるプロトコルです

00:00:33.780 --> 00:00:36.120
まずは課題から始めそのプロトコルを一つずつ紐解き

00:00:36.120 --> 00:00:39.380
マイクロソフトがコパイロットスタジオやアジュールAIでどのように活用しているかを見ていきましょう

00:00:39.380 --> 00:00:41.340
コーヒーを片手にさあ始めましょう

00:00:41.340 --> 00:00:43.220
では実際の課題は何でしょうか

00:00:43.220 --> 00:00:46.240
今日のAIエージェントは先ほどの孤立した専門家たちと全く同じです

00:00:46.240 --> 00:00:48.640
それぞれが独自の知識ツール目標を持っています

00:00:48.640 --> 00:00:50.580
天気予報エージェントは天気を知っています

00:00:50.580 --> 00:00:53.560
ホテルエージェントは空室状況を知っていますが彼らは何も共有しません

00:00:53.560 --> 00:00:57.800
ではユーザーが来週のシアトル旅行でオフィスの近くのホテルを予約してと頼んだところを想像してください

00:00:57.800 --> 00:01:02.300
単一のエージェントが天気旅行そして現地のビジネスのすべてに精通していなければなりません

00:01:02.300 --> 00:01:06.220
つまりあらゆる機能を一つのシステムに詰め込んだ巨大で肥大化したプロンプトが必要になり

00:01:06.220 --> 00:01:08.060
それらのプロンプトは常に壊れてしまいます

00:01:08.060 --> 00:01:10.640
これまでの解決策はカスタムコードを書くことでした

00:01:10.640 --> 00:01:13.100
天気エージェントとホテルエージェントの間にブリッジを作り

00:01:13.100 --> 00:01:17.260
次にホテルとフライトさらにカレンダーエージェントのためにブリッジを作るといった具合です

00:01:17.260 --> 00:01:21.380
最初はうまくいきますがエージェントを新しく追加するたびに別の統合を構築しなければなりません

00:01:21.380 --> 00:01:25.500
すぐに一つの変更がすべてを破壊してしまうスパゲッティのように絡み合った接続の悪夢に陥ります

00:01:25.500 --> 00:01:29.340
AIがもたらすはずだった生産性の向上はメンテナンス作業によって食いつぶされてしまいます

00:01:29.340 --> 00:01:31.440
実際のビジネス上の通点を見てみましょう

00:01:31.440 --> 00:01:34.060
組織にはすでに引き継ぎを伴うプロセスが存在します

00:01:34.060 --> 00:01:39.180
チケットが作成され誰かがトリアージし誰かが解決し誰かが記録する各ステップが引き継ぎです

00:01:39.180 --> 00:01:41.900
これまでの世界では各ステップを別々のエージェントで自動化し

00:01:41.900 --> 00:01:43.940
それらを接続するために何週間も費やしていました

00:01:43.940 --> 00:01:48.800
しかしエージェント同士が互いを見つけ出しカスタムブリッジなしで協力できるプロトコルがあったらどうでしょうか

00:01:48.800 --> 00:01:51.000
それこそがA2Aが行うことなのです

00:01:51.000 --> 00:01:56.180
簡単に言えばA2Aとはエージェントが互いに話し仕事を回しチームとして物事を成し遂げるための標準的な方法です

00:01:56.180 --> 00:01:57.740
A2Aとは何でしょうか

00:01:57.740 --> 00:01:58.900
単純な定義です

00:01:58.900 --> 00:02:01.600
A2Aとはアゲントエージェントエージェント間通信の略です

00:02:01.600 --> 00:02:05.320
これはAIエージェント同士が開発元に関係なく直接対話できるようにするオープンなプロトコルです

00:02:05.320 --> 00:02:07.840
エージェントのためのhttpのようなものだと考えてください

00:02:07.840 --> 00:02:12.960
httpがウェブブラウザとサーバーが通信するための言語であるようにA2Aはエージェントに対して同じ役割を果たします

00:02:12.960 --> 00:02:20.680
マイクロソフトコパイロットスタジオでITチームが構築したエージェントとグーグルクラウド上で他社が構築したエージェントが両者ともA2Aに対応していれば会話が可能です

00:02:20.680 --> 00:02:23.000
これは決して小さなプロジェクトではありません

00:02:23.000 --> 00:02:30.900
A2Aはグーグル、マイクロソフト、シスコ、セールスフォース、SAPなど8つの大手企業が支援しておりリナックスファンデーションがホストしています

00:02:30.900 --> 00:02:33.900
バージョン1.0は安定しており実用段階にあります

00:02:33.900 --> 00:02:37.000
つまり特定のベンダーがプロトコルを独占することはありません

00:02:37.000 --> 00:02:39.200
これはグーグルやマイクロソフトのものではありません

00:02:39.200 --> 00:02:40.640
業界全体のものです

00:02:40.640 --> 00:02:42.600
設計は意図的にシンプルにされています

00:02:42.600 --> 00:02:47.840
A2Aはすべての開発者がすでに知っているhttpやjsonrpcといった既存のウェブ標準に基づいています

00:02:47.840 --> 00:02:50.160
特殊なものや独自技術は含まれていません

00:02:50.160 --> 00:02:54.300
そのため企業は既存のインフラを入れ替えることなく容易に導入できます

00:02:54.300 --> 00:02:58.700
さてmcpモデルコンテキストプロトコルという別のプロトコルを聞いたことがあるかもしれません

00:02:58.700 --> 00:03:00.300
その違いは以下の通りです

00:03:00.300 --> 00:03:04.600
mcpはエージェント対ツールの関係でエージェントを外部データソースやapiに接続します

00:03:04.600 --> 00:03:08.120
A2Aはエージェント対エージェントの関係でエージェント同士を直接つなぎます

00:03:08.120 --> 00:03:10.800
これらは競合するものではなく補完し合う関係です

00:03:10.800 --> 00:03:13.740
mcpをエージェントからツールへの垂直的な接続

00:03:13.740 --> 00:03:17.840
A2Aをエージェント同士を横に結ぶ水平的な接続と考えてください

00:03:17.840 --> 00:03:19.980
もう一つ設計上の選択があります

00:03:19.980 --> 00:03:22.600
A2Aはエージェントを不透明なものとして扱います

00:03:22.600 --> 00:03:24.540
そのためあるエージェントが別のエージェントと話す際

00:03:24.540 --> 00:03:27.480
相手の内部的な推論ツールあるいはプライベートなデータを見ることはできません

00:03:27.480 --> 00:03:30.220
見えるのは送信したタスクと返ってきた結果だけです

00:03:30.220 --> 00:03:32.640
これによりプライバシーと知的財産が保護されます

00:03:32.640 --> 00:03:35.680
天気予報エージェントはホテルエージェントの部屋予約の仕組みを知る必要はなく

00:03:35.680 --> 00:03:37.380
単に予報を渡すだけでいいのです

00:03:37.380 --> 00:03:40.840
ではパズルの最初のピースであるエージェントカードを見てみましょう

00:03:40.840 --> 00:03:43.360
エージェントカードつまり履歴書のようなものです

00:03:43.360 --> 00:03:47.340
全てのA2A対応エージェントはエージェントカードと呼ばれるものを公開します

00:03:47.340 --> 00:03:50.560
そのカードはエージェントのドメイン上の標準的なURL

00:03:50.560 --> 00:03:52.720
具体的にはウェルノーンエージェントカード

00:03:52.720 --> 00:03:55.800
JSONというパスに存在する機械家族な文書です

00:03:55.800 --> 00:04:00.080
エージェントの場所が分かればカードを取得して連携に必要な情報を全て得ることができます

00:04:00.080 --> 00:04:03.020
エージェントカードは履歴書や名詞のようなものだと考えてください

00:04:03.020 --> 00:04:06.460
それは他のエージェントに対し自分は何者で何ができるのかを伝えます

00:04:06.460 --> 00:04:09.940
カードにはエージェント名機能のプレーンテキスト説明

00:04:09.940 --> 00:04:12.940
そして発見を助けるスキルタグが含まれています

00:04:12.940 --> 00:04:16.040
またリクエストを受け付けるエンドポイントURL

00:04:16.040 --> 00:04:19.780
認証要件対応する入出力フォーマットも記載されています

00:04:19.780 --> 00:04:21.340
具体的な例を挙げます

00:04:21.340 --> 00:04:23.440
気象専門のエージェントがいるとしましょう

00:04:23.440 --> 00:04:28.000
そのエージェントカードにはあらゆる都市の現在の天気と5日間の予報を提供できると書かれています

00:04:28.000 --> 00:04:30.800
APIエンドポイントには都市名を受け取り

00:04:30.800 --> 00:04:33.740
気温や天候をJSON形式で返す仕組みが記載されています

00:04:33.740 --> 00:04:34.860
これで全てです

00:04:34.860 --> 00:04:39.220
機密や内部ロジックを公開することなく何ができるかを明確に宣言しているだけです

00:04:39.220 --> 00:04:41.540
ディスカバリー探索は次のように機能します

00:04:41.540 --> 00:04:44.480
オーケストレーターエージェントは基地のエージェントURLリストを持っており

00:04:44.480 --> 00:04:46.000
設定で追加することも可能です

00:04:46.000 --> 00:04:50.060
タスクが発生するとオーケストレーターがエージェントカードを取得して説明を読み

00:04:50.060 --> 00:04:51.800
最適なエージェントを判断します

00:04:51.800 --> 00:04:54.760
天気カードなら天気そのタスクはそこへ送られます

00:04:54.760 --> 00:04:57.600
ホテルカードならホテルそのタスクはそこへ送られます

00:04:57.600 --> 00:05:00.080
中央レジストリが不要であることに注目してください

00:05:00.080 --> 00:05:02.820
エージェントはグローバルディレクトリに登録する必要がありません

00:05:02.820 --> 00:05:07.580
カードを特定の場所に公開するだけでURLを知っている他のエージェントがそれを見つけることができます

00:05:07.580 --> 00:05:11.240
これはシステムを分散化し柔軟に保つための意図的な設計です

00:05:11.240 --> 00:05:15.740
新しいスペシャリストのURLをオーケストレーターに教えるだけで自動的に探索が行われます

00:05:15.740 --> 00:05:18.200
つまりオーケストレーターは誰が利用可能かを把握しています

00:05:18.200 --> 00:05:20.640
しかし実際にどうやって作業を引き継ぐのでしょうか

00:05:20.640 --> 00:05:22.260
A2A通信の仕組みです

00:05:22.260 --> 00:05:26.000
オーケストレーターはエージェントカードを通じてどのエージェントが利用可能かを把握しています

00:05:26.000 --> 00:05:29.040
ではエージェント同士はどのように作業を引き継ぐのでしょうか

00:05:29.040 --> 00:05:30.320
答えは単純です

00:05:30.320 --> 00:05:36.560
全ての通信は今日のほとんどのウェブサービスを支えるプロトコルであるJSON RPCメッセージを用いてHTTP経由で行われます

00:05:36.560 --> 00:05:40.320
独自で複雑なものではなく2つのエージェント間で標準的なウェブトラフィックが流れるだけです

00:05:40.320 --> 00:05:41.740
ここで重要な点があります

00:05:41.740 --> 00:05:43.540
全てのタスクが同じではありません

00:05:43.540 --> 00:05:46.780
A2Aはニーズに応じて3つの異なる対話パターンをサポートしています

00:05:46.780 --> 00:05:50.840
インスタント応答はリモートエージェントが即座に回答できる簡単な紹介を扱います

00:05:50.840 --> 00:05:53.900
リクエストを送るとすぐに返信がありそれで完了です

00:05:53.900 --> 00:05:56.900
気象エージェントに今日の予報を聞くのはまさにこれと同じで

00:05:56.900 --> 00:05:58.560
非同期の応答で完結します

00:05:58.560 --> 00:06:00.980
ストリーミングはより長いタスクを扱います

00:06:00.980 --> 00:06:05.700
スペシャリストエージェントが複数のデータベースを検索したり複雑な分析を行う必要がある場合です

00:06:05.700 --> 00:06:10.680
一つの回答を待たせる代わりにエージェントはサーバーセントイベントを使って作業中に進捗状況を送信します

00:06:10.680 --> 00:06:14.140
途中で進捗報告を受け取り最後に最終結果が届きます

00:06:14.140 --> 00:06:16.040
荷物の追跡も同じ仕組みです

00:06:16.040 --> 00:06:18.300
各ステップが実行される様子を確認できます

00:06:18.300 --> 00:06:23.580
非同期通知はリモートエージェントが数分数時間あるいは数日かかるような長時間タスクを扱います

00:06:23.580 --> 00:06:25.640
従業員のオンボーディングが良い例です

00:06:25.640 --> 00:06:30.460
あるスペシャリストがITアカウントを準備し別のスペシャリストが数日かけて福利構成への加入手続きを行います

00:06:30.460 --> 00:06:34.680
クライアントエージェントはリクエストを送信してタスクIDを受け取り自身の作業を進めます

00:06:34.680 --> 00:06:37.620
後ほどリモートエージェントがwebhook経由で結果を送信します

00:06:37.620 --> 00:06:41.000
クライアントはそのタスクIDにポーリングすることでいつでも進捗を確認できます

00:06:41.000 --> 00:06:44.200
すべての対話は同じ構造に従いすべてがタスクとして整理されます

00:06:44.200 --> 00:06:48.520
クライアントがリクエストを送信するとリモートエージェントはタスクを作成しタスクIDを返します

00:06:48.520 --> 00:06:52.000
そのIDがその後のすべてを追跡するためのハンドルとなります

00:06:52.000 --> 00:06:55.180
タスク内のメッセージには送信者を示す役割があり

00:06:55.180 --> 00:07:03.840
パーツにはプレーンテキスト、画像や文書などのバイナリデータ、JSONペイロード、あるいは外部に保存されたファイルへのURLが含まれます

00:07:03.840 --> 00:07:09.240
認証はオース、APIキー、ベアラートークンといった標準的なweb監修に従います

00:07:09.240 --> 00:07:12.120
おなじみの方法であり、新しく覚えることはありません

00:07:12.120 --> 00:07:17.460
エージェントカードがクライアントに使用すべき認証方法を伝え、クライアントは他のAPI呼び出しと同じように処理します

00:07:17.460 --> 00:07:19.460
実際にどのように機能するか見てみましょう

00:07:19.460 --> 00:07:21.900
オーケストレーターが旅行の天気データを必要としているとします

00:07:21.900 --> 00:07:24.140
オーケストレーターは天気スペシャリストにタスクを送信します

00:07:24.140 --> 00:07:28.360
天気スペシャリストはリクエストを受理し、処理を開始して進捗状況をストリーミングで返します

00:07:28.360 --> 00:07:34.200
データを取得中、結果を解析中、完了、そして最終的な予報を送信します

00:07:34.200 --> 00:07:38.980
オーケストレーターは天気エージェントの内部ツールやAPIキー、推論プロセスを一切見ることができません

00:07:38.980 --> 00:07:40.640
見えるのは出力結果だけです

00:07:40.640 --> 00:07:44.800
これが重要な設計原則であり、エージェント間の境界を明確にし、内部状態を漏洩させないことです

00:07:44.800 --> 00:07:47.420
しかし、エージェント同士の連携、A2Aだけでは不十分です

00:07:47.420 --> 00:07:49.820
これらのスペシャリストを統括する賢いボスが必要です

00:07:49.820 --> 00:07:52.500
そこで登場するのがオーケストレータースペシャリストパターンです

00:07:52.500 --> 00:07:54.420
オーケストレータースペシャリストパターン

00:07:54.420 --> 00:07:55.860
ここで全てが繋がります

00:07:55.860 --> 00:08:00.320
オーケストレータースペシャリストパターンは、今日のマルチエージェントシステムにおいて最も一般的なアーキテクチャです

00:08:00.320 --> 00:08:03.540
IT、人事、財務といった各部署を持つ会社を思い浮かべてください

00:08:03.540 --> 00:08:05.820
それぞれが自分の担当領域を扱います

00:08:05.820 --> 00:08:11.360
中央の意思決定者が専門チームに作業を振り分け、各チームは自分たちの得意分野に専念するのです

00:08:11.360 --> 00:08:13.620
オーケストレーターは全体像を把握しています

00:08:13.620 --> 00:08:18.680
ユーザーのリクエストを受け取り、何をする必要があるかを判断し、どのスペシャリストが各作業を担当できるかを決定します

00:08:18.680 --> 00:08:21.880
例えばユーザーが、来週シアトルへの旅行を計画して、と頼んだ場合です

00:08:21.880 --> 00:08:25.100
オーケストレーター自身が航空券を予約したり、ホテルを調べたりすることはありません

00:08:25.100 --> 00:08:28.840
フライト担当、ホテル担当、天気担当のスペシャリストがいることを知っているからです

00:08:28.840 --> 00:08:31.640
リクエストをそれらの要素に分解し、それぞれを移任します

00:08:31.640 --> 00:08:33.660
各スペシャリストは狭い領域に集中します

00:08:33.660 --> 00:08:38.420
あるエージェントはフライト予約を、別のエージェントはホテル検索を、そして3番目のエージェントはインシデントの優先順位付けを担当します

00:08:38.420 --> 00:08:40.560
互いの専門領域について知っておく必要はありません

00:08:40.560 --> 00:08:43.520
航空便のスペシャリストは、航空会社、路線、価格を把握しています

00:08:43.520 --> 00:08:46.820
ホテルの部屋タイプやキャンセルポリシーについて知る必要は一切ありません

00:08:46.820 --> 00:08:51.040
専門分野を絞ることで、各エージェントはシンプルで保守しやすく、テストも容易になります

00:08:51.040 --> 00:08:52.620
ここが重要なポイントです

00:08:52.620 --> 00:08:54.560
オーケストレーターはタスクを実行しません

00:08:54.560 --> 00:08:56.740
タスクを振り分け、結果を統合するだけです

00:08:56.740 --> 00:08:58.240
それが唯一の役割です

00:08:58.240 --> 00:09:02.400
オーケストレーターの役割は賢いディスパッチャーであることであり、何でもこなすスーパーエージェントになることではありません

00:09:02.400 --> 00:09:06.160
オーケストレーターに専門的な作業までさせると、このパターンの利点が全て失われます

00:09:06.160 --> 00:09:08.300
再びモノリシックで複雑なものになってしまいます

00:09:08.300 --> 00:09:09.920
よくある間違いに注意してください

00:09:09.920 --> 00:09:12.760
専門領域が重複するようにチームが作ってしまうケースがあります

00:09:12.760 --> 00:09:17.600
2つのエージェントがカスタマーサポートやデータ検索を担当できると主張すると、振り分けに混乱が生じます

00:09:17.600 --> 00:09:21.760
オーケストレーターはどちらを選ぶべきか判断できず、ユーザーは一貫性のない結果を受け取ることになります

00:09:21.760 --> 00:09:23.280
解決策は単純です

00:09:23.280 --> 00:09:26.640
各スペシャリストが重複のない明確に境界付けられた領域を担当するようにします

00:09:26.640 --> 00:09:30.260
2つのエージェントが同じことをできる場合は、統合するか、領域をよりきれいに分割してください

00:09:30.260 --> 00:09:33.380
マイクロソフトのコパイロットスタジオは、このパターンをネイティブで採用しています

00:09:33.380 --> 00:09:38.140
メインのコパイロットがオーケストレーターとして機能し、コエージェントや接続されたエージェントがスペシャリストとして機能します

00:09:38.140 --> 00:09:44.000
ユーザーが複数の領域にまたがる質問をした場合、メインのコパイロットがA2Aを通じて適切なスペシャリストに移任します

00:09:44.000 --> 00:09:48.240
プラットフォームに組み込まれているため、オーケストレーションのロジックを一からコーディングする必要はありません

00:09:48.240 --> 00:09:50.360
ここでの最大のメリットはモジュール製です

00:09:50.360 --> 00:09:52.720
ホテル予約のプロバイダーを変更したい場合はどうしますか?

00:09:52.840 --> 00:09:56.100
オーケストレーターや他のエージェントに触れることなく、ホテル専門のエージェントを入れ替えるだけです

00:09:56.100 --> 00:10:01.100
新しい機能を追加したいときは、新しいスペシャリストを作成し、オーケストレーターに登録すれば完了です

00:10:01.100 --> 00:10:04.440
各エージェントは小規模で管理しやすく、独立して展開可能です

00:10:04.440 --> 00:10:07.960
それこそが、モノリシックなエージェントからマルチエージェントシステムへと移行する最大の意義です

00:10:07.960 --> 00:10:10.740
ここまでで、プロトコル、エージェントカード、そしてパターンについて解説しました

00:10:10.740 --> 00:10:13.040
実際のシナリオでどのように動作するか見てみましょう

00:10:13.040 --> 00:10:15.140
A2Aが実際に機能している例です

00:10:15.140 --> 00:10:18.080
では、A2Aは現実世界でどのような形で見えるのでしょうか?

00:10:18.180 --> 00:10:19.680
簡単な例から始めましょう

00:10:19.680 --> 00:10:23.420
AIアシスタントに、来週のシアトル旅行を計画して、と伝えます

00:10:23.420 --> 00:10:29.740
従来のやり方では、その一つのアシスタントが天気、航空便、ホテル、レストランなど、すべてを一度に把握しなければなりませんでした

00:10:29.740 --> 00:10:31.960
一つのプロンプトで要求するには2が重すぎます

00:10:31.960 --> 00:10:34.600
A2Aを使えば、オーケストレーターがタスクを分解します

00:10:34.600 --> 00:10:38.360
特定の日の予報を求めて、天気専門のエージェントにタスクを送るのです

00:10:38.360 --> 00:10:47.500
同時に、火曜の朝に到着し木曜の夜に戻るフライトを探す用フライト専門エージェントに依頼し、シアトルのダウンタウン近くで3泊できる宿泊先を探す用ホテル専門エージェントに依頼します

00:10:47.500 --> 00:10:54.880
各専門家は独立して機能し、それぞれが独自のデータソース、ツール、専門知識を持っているため、他のエージェントとやり取りする必要はありません

00:10:54.880 --> 00:10:58.600
オーケストレーターはすべての結果を収集し、一つの回答に統合します

00:10:58.600 --> 00:11:00.980
ユーザーには単一の回答が表示されます

00:11:00.980 --> 00:11:02.420
こちらが天気予報です

00:11:02.420 --> 00:11:05.580
こちらがフライトの選択肢で、こちらがオフィス近くのホテル3軒です

00:11:05.580 --> 00:11:09.740
舞台裏では、3つの独立したエージェントがカスタム統合コードなしで連携しました

00:11:09.740 --> 00:11:11.760
次に、ビジネスシナリオを見てみましょう

00:11:11.760 --> 00:11:14.980
例えば、ノートPCがVPNに接続できないというチケットが届いたとします

00:11:14.980 --> 00:11:17.840
オーケストレーターは、これがネットワークの問題であると判断します

00:11:17.840 --> 00:11:21.540
標準的な手順を知っているランブック専門エージェントにチケットを引き渡します

00:11:21.540 --> 00:11:26.400
VPNクライアントのステータス確認、ネットワーク資格情報の検証、サービス再起動を行います

00:11:26.400 --> 00:11:28.320
その専門家が手順を返します

00:11:28.320 --> 00:11:33.420
次にオーケストレーターは、その結果をチケット作成専門エージェントに渡し、システムに解決策を記録します

00:11:33.420 --> 00:11:39.880
これらすべてが人間の介入なしに数秒で行われ、自動化された手順で問題が解決しない場合にのみ、ITチームが介入します

00:11:39.880 --> 00:11:44.200
従業員のオンボーディングも別の例ですが、これは数秒ではなく数日を要します

00:11:44.200 --> 00:11:45.840
新入社員が入社します

00:11:45.840 --> 00:11:51.640
オーケストレーターはIT専門エージェントを起動してアカウント作成とハードウェアの割り当てを行いますが、これには数時間かかる場合があります

00:11:51.640 --> 00:11:58.280
同時に、入社手続き起用フォームのために人事副理構成専門エージェントを、後からデスクやバッジアクセスのために施設管理専門エージェントを起動します

00:11:58.280 --> 00:12:04.940
各専門家は独自の長期タスクを独立して実行し、オーケストレーターは先ほど触れたタスクIDを使用して進捗を追跡します

00:12:04.940 --> 00:12:10.600
そのため、IT専門家が完了すればオーケストレーターはそれを把握し、施設管理専門家が遅れていればフォローアップできます

00:12:10.600 --> 00:12:15.900
ユーザーにはスムーズなオンボーディングの流れが見えますが、舞台裏では数日間かけてチームが調整を行っています

00:12:15.900 --> 00:12:17.640
これは単なる理論ではありません

00:12:17.640 --> 00:12:23.880
コカ・コーラビベレイジズアフリカでは、すでにコパイロットスタジオエージェントとダイナミクス365を使用して計画サイクルの自動化を行っています

00:12:23.880 --> 00:12:27.820
以前は、計画担当者が毎日最大1時間半もの時間を反復作業に費やしていました

00:12:27.820 --> 00:12:31.180
マルチエージェントオーケストレーションにより、それらのサイクルは自動で実行されます

00:12:31.180 --> 00:12:35.900
オーケストレーターは、サプライチェーン計画プロセスの異なる部分を担当する専門家に委任します

00:12:35.900 --> 00:12:43.180
その結果、人間がシステム間で情報を仲介する代わりにエージェント同士を連携させるだけで、1人当たり1日1時間以上の削減を実現しました

00:12:43.180 --> 00:12:46.100
つまり、すべての例においてパターンは共通しています

00:12:46.100 --> 00:12:52.280
各エージェントは独自の領域とツールを持つ完結した専門家であり、他のエージェントについて知る必要はありません

00:12:52.280 --> 00:12:57.120
A2Aはシンプルな通信レイヤーを提供し、カスタムコードなしでエージェント同士の連携を可能にします

00:12:57.120 --> 00:13:03.240
標準プロトコルとスマートなオーケストレーターが利用できるため、ブリッジやポイントツーポイントの統合、メンテナンスの煩わしさは不要です

00:13:03.240 --> 00:13:05.400
マイクロソフトはこれに全面的に取り組んできました

00:13:05.400 --> 00:13:08.340
コパイロットスタジオとAzure AIがどのように適合するかを見ていきましょう

00:13:08.340 --> 00:13:11.580
マイクロソフトのエコシステム、コパイロットスタジオ、そしてAzure AIです

00:13:11.580 --> 00:13:14.060
では、マイクロソフトはこの中でどのような位置にあるのでしょうか

00:13:14.060 --> 00:13:15.220
まさに中心にあります

00:13:15.220 --> 00:13:20.160
コパイロットスタジオは現在A2Aをネイティブでサポートしており、2026年4月から一般提供されています

00:13:20.160 --> 00:13:22.120
これはプレビュー版やベータ版ではありません

00:13:22.120 --> 00:13:25.060
本番環境対応であり、対象となるお客様は今すぐ利用可能です

00:13:25.060 --> 00:13:26.500
重要なポイントはここです

00:13:26.500 --> 00:13:29.520
外部エージェントをコパイロットスタジオのオーケストレーターに接続できます

00:13:29.520 --> 00:13:32.340
外部といった場合、それは真の意味での外部を指します

00:13:32.340 --> 00:13:37.540
GoogleクラウドやAWS、その他A2Aプロトコルをサポートするあらゆるプラットフォーム上で構築されたエージェントです

00:13:37.540 --> 00:13:40.960
オーケストレーターはエージェントの所在や構築されたフレームワークを問いません

00:13:40.960 --> 00:13:43.660
A2Aに対応さえしていればチームに参加できるのです

00:13:43.660 --> 00:13:44.940
設定は簡単です

00:13:44.940 --> 00:13:48.200
コパイロットスタジオで接続済エージェント、コネクチュエージェントを作成します

00:13:48.200 --> 00:13:50.640
エージェントのエンドポイントURLを貼り付けるだけです

00:13:50.640 --> 00:13:54.080
コパイロットスタジオはそのURLからエージェントカードを自動的に取得します

00:13:54.080 --> 00:13:57.380
これは前述した標準的なエージェントカードのJSONファイルです

00:13:57.380 --> 00:14:01.700
エージェントの機能、認証要件、入出力形式を読み取ります

00:14:01.700 --> 00:14:06.980
その後、バックグラウンドでカスタムコネクタが構築され、オーケストレーターは直ちにタスクの移民を開始できます

00:14:06.980 --> 00:14:09.760
手動による統合作業やカスタムコードは不要です

00:14:09.760 --> 00:14:11.960
URLを貼り付けるだけで完了します

00:14:11.960 --> 00:14:15.800
Azure側では、Azure iFoundryエージェントサービスもA2Aをサポートしています

00:14:15.800 --> 00:14:22.920
専用のA2A APIエンドポイントがあり、オートゲン、ラングチェーン、セマンティックカーネルといったオープンソースのオーケストレーターからファウンドリのエージェントを呼び出せます

00:14:22.920 --> 00:14:28.380
つまり、それらのフレームワークを使ってエージェントを構築済みであれば、書き直すことなくマイクロソフトのエコシステムに組み込めます

00:14:28.380 --> 00:14:30.100
これは双方向の関係です

00:14:30.100 --> 00:14:33.900
マイクロソフトも、これまで説明してきたオーケストレーターとスペシャリストのパターンに従っています

00:14:33.900 --> 00:14:38.980
コパイロットスタジオのメインエージェントがオーケストレーターとなり、コエージェントや接続済みエージェントがスペシャリストとなります

00:14:38.980 --> 00:14:42.680
それぞれが自身の専門領域を扱い、オーケストレーターがルーティングと統合を行います

00:14:42.680 --> 00:14:45.980
マイクロソフトのプラットフォーム上で動作するというだけで、アーキテクチャは同じです

00:14:45.980 --> 00:14:48.660
しかし、知っておくべき制限事項もいくつかあります

00:14:48.660 --> 00:14:51.940
第一に、オーケストレーションのホップが増えるごとにレイテンシが発生します

00:14:51.940 --> 00:14:57.560
メインエージェントが接続済みエージェントを呼び出し、さらにそのエージェントが別のスペシャリストを呼び出すと、ホップごとにネットワーク時間が加算されます

00:14:57.560 --> 00:15:01.500
リアルタイムの対話において、ホップ数が多すぎると動作が遅く感じられる可能性があります

00:15:01.500 --> 00:15:04.420
第二に、移人のしすぎはルーティングの混乱を招きます

00:15:04.420 --> 00:15:09.500
専門領域が重複するスペシャリストが多すぎると、オーケストレーターは誤ったルーティング判断を下し始めます

00:15:09.500 --> 00:15:13.720
ですから、スペシャリストの数は管理可能な範囲に抑え、ドメインを明確に分けておきましょう

00:15:13.720 --> 00:15:16.860
三つ目に、ファブリックデータエージェントには特定の制限があります

00:15:16.860 --> 00:15:20.740
メインのエージェントをマイクロソフト365個パイロットにデプロイすると、これらは機能しません

00:15:20.740 --> 00:15:24.000
M365へのデプロイを検討している場合は、それに応じた計画を立ててください

00:15:24.000 --> 00:15:26.640
こうした制約は現実に存在しますが、対処は可能です

00:15:26.640 --> 00:15:31.340
プラットフォームは実用レベルに達しており、マイクロソフトはこれらのギャップを解消すべく積極的に取り組んでいます

00:15:31.340 --> 00:15:34.040
それでは、点と点をつなぎ、全体像を見てみましょう

00:15:34.040 --> 00:15:36.800
接続セクションとして、全体がどのように組み合わさるかを説明します

00:15:36.800 --> 00:15:39.340
少し引いた視点で、これらの要素がどうつながるかを見てみましょう

00:15:39.340 --> 00:15:42.400
A2Aとは、エージェント同士が通話するために使う電話システムのようなものです

00:15:42.400 --> 00:15:44.220
エージェントカードは、いわば電話帳です

00:15:44.220 --> 00:15:46.700
誰に連絡すべきか、各エージェントが何を担当しているかがわかります

00:15:46.700 --> 00:15:49.380
オーケストレーターは、呼び出しを適切な部署に振り分ける受付係です

00:15:49.380 --> 00:15:51.160
これらの要素は、単独では機能しません

00:15:51.160 --> 00:15:52.500
3つ全てが必要です

00:15:52.500 --> 00:15:54.600
電話帳がなければ、誰に電話すべきかわかりません

00:15:54.600 --> 00:15:57.120
受付係がいなければ、誰も交通整理ができません

00:15:57.120 --> 00:16:00.080
そして電話システムがなければ、受付係は誰もつなぐことができません

00:16:00.080 --> 00:16:01.780
チームとして初めて機能するのです

00:16:01.780 --> 00:16:03.740
そこで重要になるのがモジュール性です

00:16:03.740 --> 00:16:07.560
スペシャリストがモジュール化されていれば、既存の機能を壊さずに新しい機能を追加できます

00:16:07.560 --> 00:16:13.660
例えば、旅行アシスタントにレンタカー担当のスペシャリストを追加したい場合、それを作成してエージェントカードを公開し、オーケストレーターにURLを教えるだけです

00:16:13.660 --> 00:16:14.440
完了です

00:16:14.440 --> 00:16:17.460
フライト担当やホテル担当のスペシャリストは、以前のまま変わりません

00:16:17.460 --> 00:16:19.420
オーケストレーター側も変更不要です

00:16:19.420 --> 00:16:22.100
新しいパーツを差し込むだけで、システムが適用します

00:16:22.100 --> 00:16:25.440
プロトコルがオープンであるため、特定のベンダーに縛られることもありません

00:16:25.440 --> 00:16:32.820
オーケストレーターをコパイロットスタジオで動かし、天気予報エージェントをGoogleクラウド、ホテルエージェントをAWS、社内システムをAzureで運用することも可能です

00:16:32.820 --> 00:16:34.900
これらはすべて、同じ言語で会話します

00:16:34.900 --> 00:16:37.180
それこそが、オープンスタンダードの素晴らしさです

00:16:37.180 --> 00:16:40.220
ベンダーロックインを防ぎ、それぞれの仕事に最適なツールを選択できます

00:16:40.220 --> 00:16:43.460
A2Aは、すべてを知り尽くした一人のスーパーエージェントを作るためのものではありません

00:16:43.460 --> 00:16:46.940
ニーズの変化に合わせて再配置できる、柔軟なスペシャリスト集団を構築するためのものです

00:16:55.440 --> 00:16:58.080
実践的なヒントをお伝えします

00:16:58.080 --> 00:16:59.540
まずは小さく始めましょう

00:16:59.540 --> 00:17:03.160
組織内で複数のシステムが関与する反復的なプロセスを一つ選んでください

00:17:03.160 --> 00:17:06.940
例えば、チケット解決や従業員のオンボーディング、経費生産などが挙げられます

00:17:06.940 --> 00:17:09.240
各ステップ間での引き継ぎが明確なものが適しています

00:17:09.240 --> 00:17:12.200
次に、一つのオーケストレーターと二つのスペシャリストでプロトタイプを構築してみましょう

00:17:12.200 --> 00:17:13.900
大規模なアーキテクチャは必要ありません

00:17:13.900 --> 00:17:16.360
学びを得るための動作する実例が一つあれば十分です

00:17:16.360 --> 00:17:18.440
すでに対応しているツールを活用しましょう

00:17:18.440 --> 00:17:22.120
Copilot StudioにはA2A機能が組み込まれており、Azure iFoundryにも搭載されています

00:17:22.120 --> 00:17:25.500
プロトコルをゼロから構築したり、独自の連携コードを書く必要はありません

00:17:25.500 --> 00:17:28.840
URLを貼り付け、エージェントを設定して移任を開始するだけです

00:17:28.840 --> 00:17:30.600
よくある落とし穴に注意してください

00:17:30.600 --> 00:17:32.800
専門領域が重複しないように保ちましょう

00:17:32.800 --> 00:17:36.020
二つのエージェントが同じことができるなら、統合するか領域を明確に分けます

00:17:36.020 --> 00:17:38.640
オーケストレーターにはルーティングを任せ、実行は任せないようにします

00:17:38.640 --> 00:17:41.120
また、オーケストレーションの経由による遅延にも注意が必要です

00:17:41.120 --> 00:17:44.040
応答時間が長くなってきたら、移任の回想が多すぎる可能性があります

00:17:44.040 --> 00:17:46.100
最初のステップはシンプルにするのが一番です

00:17:46.100 --> 00:17:48.380
既存のワークフローにおける引き継ぎ箇所を書き出しましょう

00:17:48.380 --> 00:17:51.260
人と人、あるいはシステム間で、どこで情報が受け渡されていますか?

00:17:51.400 --> 00:17:53.400
そこが、エージェントが活躍できるポイントです

00:17:53.400 --> 00:17:55.220
すべての引き継ぎがチャンスになります

00:17:55.220 --> 00:17:57.640
以上が、A2Aシステムの概要です

00:17:57.640 --> 00:17:59.900
三つのシンプルな要素が連携する仕組みです

00:17:59.900 --> 00:18:02.700
エージェントは孤立せず、本当のチームのように機能し始めます

00:18:02.700 --> 00:18:05.540
引き継ぎが明確なワークフローを一つ選び、そこから構築を始めましょう

00:18:05.540 --> 00:18:07.780
チャンネル登録でわかりやすい解説をチェックしてください

00:18:07.780 --> 00:18:09.480
何か気づきがあればコメントをどうぞ