스크립트
00:00:00アレックス・ハンコック：皆さんこんにちは。アレックス・ハンコックです。本日は「AIのためのユニバーサル
00:00:17リモコン」についてお話しします。始める前に一言言いたいのですが、前の登壇者が
00:00:21MCPクライアントのメンテナーは頭が良いからタスクのサポートを実装していないと言っていました。私は
00:00:26MCPクライアントのメンテナーですが、単にめんどくさがりだから実装してないだけだと言えます。さて、
00:00:33始める前に私について少し紹介します。私はBlockのソフトウェアエンジニアです。Blockは
00:00:37Cash App、Square、Tidalの親会社です。現在、いくつかの異なる事業を展開しています。
00:00:43私はそこで長く働いており、SquareのプロダクトやCash Appの開発に携わってきました。
00:00:47しかしここ数年は、オープンソースのAIに取り組んでいます。具体的には、
00:00:51Gooseというオープンソースのハーネスプロジェクトに携わっており、これはもともとBlockの社内プロジェクトとして始まりました。
00:00:56そう、会場にもGooseファンがいますね。そして、これをオープンソース化し、
00:01:02Linux Foundationに寄贈しました。そのため知財はそこにありますが、
00:01:07Blockのメンバーの多くは今でもこのプロジェクトに関わっています。私はまた、Model Context ProtocolであるMCPのメンテナーでもあり、そのRust SDKの開発に携わっています。
00:01:14そして最近では、Agent Client ProtocolであるACPの開発にも少し携わっており、本日はそのお話をします。
00:01:20ハーネスに関して、皆さんに提起したい課題があります。本日はそれを問題として提示し、
00:01:27解決策を提案したいと思います。最近私が気づいているのは、素晴らしいハーネスがたくさん登場しているということです。
00:01:35研究機関から提供されているものもあり、さまざまな企業のものもあります。オープン標準をベースにしたものもたくさんあります。
00:01:46しかし、それらへのインターフェースはカスタムや個別仕様であることが多い点に気づきました。最悪の場合、
00:01:52そのハーネスを操作するために使えるクライアントアプリケーションが文字通り1つしか存在しない、
00:01:57というようなハーネスもありますよね。これにはいくつかの問題があると考えていますが、
00:02:03ウェブに例えるなら、すべてのウェブサイトに接続するためにたった1つのブラウザや1つの特定のプロトコルしか使えないようなものです。
00:02:11それでは機能しませんよね。もしブラウザの現実がそうだとしたら、オープンなウェブのようなものは存在しなかったでしょう。
00:02:16したがって、私たちはもっとうまくやれるはずです。そして、標準規格を見つけることには意義があります。
00:02:22標準規格というものは、エコシステムや市場を創出します。エージェント型AIの領域においても、
00:02:28エージェントが外部に出て活動するための優れた標準規格が存在すると私は主張したいです。
00:02:35ツールの呼び出し、他のシステムでのアクションの実行、リソースやデータの読み込みなどです。私たちはコミュニティとして、MCPがあることの恩恵を皆で受けてきましたよね。
00:02:41そして、MCPの最も強力な点は、
00:02:47MCP自体というよりも、誰もがMCPを使用しているという事実にあります。だからこそ、世界中に数千、あるいは
00:02:53数万ものサーバーが存在し、あらゆるエージェントがそれらに接続して、
00:02:58他のシステムで作業を行うことができるのです。一方で、クライアントソフトウェアがエージェントに何をすべきか指示し、
00:03:05タスクを与え、作業内容を指示し、進捗状況のアップデートを受け取るための優れたソリューションや標準規格は、まだ存在していないと言えます。
00:03:13そこで本日は、優れた選択肢となり得るオプションを提案したいと思います。私たちのチームが取り組んできたものであり、
00:03:20オープン標準の分野において優れたソリューションであると考えています。
00:03:26それがACPです。Agent Client Protocolがこのプロジェクトの名前です。これはエディター企業から生まれました。
00:03:32例えば、Zedテキストエディターを使ったことがある方や、JetBrainsの製品のいずれかを使ったことがあるなら分かるでしょう。
00:03:39Zedの開発チームとJetBrainsの開発チームがタッグを組み、
00:03:45クライアントがハーネスを制御できるようにするための標準規格を提案したのです。彼らの立場に立ってみれば、非常に理にかなっていますよね。
00:03:49彼らがやりたかったのは、エディター（ZedやIntelliJなど）内に
00:03:54高品質なクライアントの実装をひとつだけ作成し、その単一のクライアント実装を用いてあらゆるハーネスを制御できるようにすることです。
00:04:00タスクの送信、結果の取得、
00:04:06どのファイルが編集されているかの確認などを行います。彼らの立場に立てば、非常に理にかなっていますよね。
00:04:10しかし、私たちGooseチームはこれに注目しました。そして、エディターだけに留まらない、はるかに幅広い有用性があると考えています。
00:04:17比較的ニュートラルであり、エディター固有の機能があまり多く含まれていないためです。したがって、
00:04:22これはより広範なクライアントソフトウェアに普及させることができると考えています。ACPの設計や
00:04:30それで何ができるのかについて、もう少し詳しく説明すると、クライアントとエージェントハーネスの間に接続を確立できるようにし、
00:04:37その接続に関連付けられた特定の機能セットを持たせることができます。その上でセッションを作成できます。セッション内では、ユーザーがアプリに
00:04:45入力している内容や、クライアントソフトウェアが送信したい内容といった、ユーザーメッセージを送信できます。
00:04:51エージェントはそれに対して、テキスト、画像や音声、テキストなどで応答したり、状況についてのアップデートを返すことができます。
00:04:59例えばツールが呼び出された場合、ツール呼び出しの通知を送信し、どのようなツールが呼び出され、
00:05:04メタデータが何であったかを説明できます。また、
00:05:10クライアントソフトウェアがユーザーに対して「このツール呼び出しを実行してもよろしいですか、はい・いいえ」と表示する必要がある場合などに、
00:05:16このプロトコルを介してやり取りを行うことができます。設計は非常にシンプルで、JSON-RPCメッセージを使用しています。
00:05:24そして私たちが最も気に入っている点は、拡張性もあるということです。そのため、
00:05:29もっと幅広いクライアントソフトに展開できると考えています。ACPのデザインや
00:05:37そこで何ができるのかについて、もう少し詳しく見ていきましょう。
00:05:41ACPでは、接続に関連付けられた一連の機能を持つクライアントと
00:05:46エージェントハーネスの間で接続を確立できます。そしてセッションを作成し、
00:05:52セッション内では、ユーザーがアプリに入力している内容やクライアントソフトが
00:05:58送信したい内容などのユーザーメッセージを送信できます。エージェントはそれに伴い、
00:06:03テキストや画像、音声、あるいは状況のアップデートなどで応答できます。
00:06:12例えばツールが呼び出された場合、ツール呼び出しの通知を送信して、
00:06:18どのツールが呼ばれ、どのようなメタデータだったのかを説明できます。
00:06:25また、クライアントソフトがユーザーに対して「このツール呼び出しを実行しますか？
00:06:31はい、いいえ」と表示する必要がある場合などの権限リクエストも送信できます。
00:06:36設計は非常にシンプルで、JSON-RPCメッセージを使用しています。
00:06:42そして私たちが最も気に入っている点は、拡張性があるということです。
00:06:50そのため、標準プロトコルだけに限定されず、カスタムメソッドを追加できます。
00:06:55規則として、アンダースコアを付けてからカスタムメソッドを記述します。
00:07:01私が気に入っているのは、これによって十分な数のハーネスプロジェクトや
00:07:06クライアントプロジェクトがこれを採用すれば、私たち全員が行っている共通の作業が
00:07:13見えてくるという点です。
00:07:21例えば、codexチームやgooseチーム、その他のクライアントチームに
00:07:25それぞれのカスタムメソッドがある場合、エコシステムの中で何が自然に現れ、
00:07:31トランスポートとしてHTTP版とWebSocketアップグレードを導入しました。これによりメッセージや
00:07:37確認できます。つまり、実際の利用状況やコミュニティによって形作られていくのです。
00:07:42それでは、標準入出力バージョンのデモをお見せします。
00:07:49Zedを開きます。ここには本当にシンプルなプロジェクトがあり、
00:07:54「このプロジェクトについて教えて」と指示してみます。
00:07:59ご覧の通り、これは単一のHTMLファイルです。Zedにクエリを入力することができ、
00:08:04ここで動いているエージェントはGooseです。GooseのACPインターフェースを使用しています。
00:08:13テキストを返し、何を読むべきか、何を実行したかという
00:08:18ツール呼び出しの情報を返しているのが分かります。
00:08:24そして単一のHTMLファイルであることを見つけ出して説明してくれました。
00:08:29もう一つ別のデモをお見せします。今度はPoolside AIという企業のものです。
00:08:34同じプロジェクトに対して「このプロジェクトについて教えて」と言ってみます。
00:08:39これはターミナルベースのクライアントであり、同じエージェントから
00:08:46まったく同じ体験を得ています。ハーネス側は1つの実装でありながら、
00:08:53任意のクライアントを使用できるようになりました。
00:09:01ご覧の通り、先ほどと同様にテキスト結果やツール呼び出しを表示し、
00:09:03その後要約をストリーミングしています。
00:09:09これが、ローカル環境で標準入力を介して2つのクライアントが
00:09:15同じエージェントと通信している様子を示す基本的なデモです。
00:09:21しかし、ローカルだけではもちろん不十分ですよね？
00:09:25これを普及させるには、リモートにも対応できなければなりません。
00:09:29エージェントはいずれクラウド上で実行されるようになるからです。
00:09:34私たちがこのプロジェクトに取り組んだ際、まだリモートサポートが
00:09:41実装されていないことに気づきました。そこでHTTPトランスポートを仕様として定め、
00:09:49HTTPバージョンとWebSocketアップグレードを用意しました。
00:09:54これにより、メッセージやプロトコルのセマンティクスは同じままで、
00:10:00リモートを可能にする新しいトランスポートが導入されました。
00:10:06Gooseチームとしてエージェントスタックについて考えるとき、
00:10:12主に4つの重要なコンポーネントが存在します。
00:10:171つ目はユーザーが使用するアプリやマシン上で動作するヘッドレスアプリなどのクライアント、
00:10:222つ目はツール呼び出しのループを実装するプログラムであるハーネス、
00:10:263つ目はMCPであるツール自体、そして4つ目はモデルです。
00:10:33エージェントクライアントプロトコルにリモートトランスポートがあり、
00:10:37ツール呼び出し用のMCPリモートトランスポートや長年存在するモデルのAPIエンドポイントを組み合わせることで、これら4つのコンポーネントを自由に配置できるようになります。
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기