1. オープニング：エージェンティックAIの潮流と財団の課題認識（司会・Agentic AI Foundation）
1.1 中立的な基盤としての財団と「ハーネス」の重要性
司会（Agentic AI Foundation）： 2日目にお越しいただき、ありがとうございます。この素晴らしい都市で開催できることを、私たちは本当にうれしく思っています。本日は、エージェンティックAIの世界で、それぞれの企業のビジネスを実際に動かしている方々に登壇していただきます。そうした方々のお話を楽しみにしていてください。ただ、講演に入る前に、AIからエージェンティックAIへと移行しつつあるこの業界の動向について、私なりの考察をいくつか共有させてください。
司会： まず、私たちAgentic AI Foundationの立場から申し上げます。ご存じの方も多いと思いますが、私たちはエージェンティックAIが構築される中立的な拠点です。そしてその中立的な拠点として、私たちが関心を向ける範囲は、モデルの上位層から実世界に至るまでのすべてです。昨日は、MCPやA2A、エージェントゲートウェイ、AGENTS.mdといったプロトコルについて多くの議論がありました。しかし一方で、私たちは「ハーネス」についてはあまり語ってこなかったように思います。ところが、このハーネスこそが本当に重要なのです。最近はモデルばかりが注目を集めていますが、私はハーネスのほうがさらに重要だと考えています。
司会： なぜそう言えるのかといえば、まったく同じモデルを使っていても、ハーネスが異なれば、同じタスクの遂行結果が大きく変わってしまうからです。ここで言うハーネスには多くの要素が含まれます。推論から実行、そして適応に至るループそのもの、その過程を観察する可観測性、ツールのルーティング、コンテキスト、メモリ、サンドボックスと実行環境、権限や認可、さらにエラー処理とリトライです。これらが、モデルを使ったラボでの実験やチャットボットの段階と、本当の意味での本番システムとを分ける違いになります。本日の基調講演者の方々からも、この点について多くのお話を伺えるはずです。
司会： また、プロトコルについては十分に議論してきましたが、財団としては多くのワーキンググループを通じて、いくつかの本質的な課題にも取り組んでいます。権限と認可の問題、エージェントの説明責任の問題、そしてメモリやコンテキスト、モデルをまたいで、異なるハーネス間でどのように相互運用性を実現するかという問題です。これらが主要な課題であり、この領域では今後、新しいプロジェクトが財団に加わってくることを期待していただいてよいと思います。
1.2 オープンウェイトモデルの台頭とトークン経済
司会： 次にモデルの話をしたいと思います。皆さんの多くはすでにご存じの動向かもしれませんが、オープンウェイトモデルは非常に速いペースでフロンティアモデルに追いついてきています。どの分析や、どのデータを見るかによって異なりますが、現時点で最高のモデルとの差は3〜6ポイント程度にまで縮まっています。私がオープンウェイトモデルについて本当にわくわくしているのは、それによって企業がまったく新しい、ソブリンなエージェンティックAIスタックを構築できるようになったという点です。今では、スタック全体を実質的にノートPC上でも構築できますし、昨日は小型のNVIDIA製マシン上でそれが動いているのを目にしました。これにより、データプライバシーを守りながら、主権を確保した形でこうした機能を構築する自由が得られるのです。
司会： 優れたモデルは次々と登場しています。私たちは先週中国を訪れ、最先端のモデルを開発している多くの企業と会ってきました。いくつかの調査によれば、オープンウェイトモデルを使ってスタック全体を構築すると、フロンティアモデルを使う場合に比べておよそ6分の1のコストで済むとされています。それにもかかわらず、現在、企業の80%は実際にはフロンティアモデルを導入しています。つまり、フロンティアモデルがもたらす追加的な品質が、今日の多くの企業にとって非常に大きな意味を持っているということです。
司会： ここで会場の皆さんに伺います。ジェヴォンズのモデルを聞いたことがある方は手を挙げてください。……何人かいらっしゃいますね、ありがとうございます。Jevonsは19世紀の経済学者で、石炭の価格が下がると消費量が増え、結果として全体の支出はむしろ増えるという仮説を唱えました。同じことはインターネット帯域でも電力でも起きてきましたが、今まさにトークンでも同じ現象が起きています。過去1年でトークン価格は90%以上下落しましたが、私たちが見てきたいくつかの調査によれば、消費量は約50倍、あるいはそれ以上に増えています。つまり全体としては以前より多くを支払っているわけです。しかし、それによって1年前には解けなかった問題に取り組めるようになりました。たとえば深い推論が可能になりましたし、1年前には話題にすらならなかったマルチエージェント間の通信についても議論が始まっています。ですから、これは追いかける価値のある、本当に刺激的な領域だと思います。
司会： 先ほど触れた約6ポイントの差について、グラフでお見せします。このグラフは毎日のように変わります。私は1週間前にスライドを用意したのですが、3日前に差し替えなければなりませんでした。今お見せしているのはその3日前の時点のものです。私が申し上げた約6ポイントの差というのは、Kimiや、文字起こしではGLMの5.3系と読めるモデルと、最新のFable 5.1 Maxとの間の差で、これが現時点の状況です。これはArtificial Analysisの知能指数に基づくもので、コーディングのタスクに加え、事実性やハルシネーションなどを組み合わせて評価した指標です。このチャートは今後も変わり続けますが、興味深いのは、どのモデルもまだ知能指数70には到達していないという点です。それでも、このエコシステムは非常に速く動いています。
1.3 エージェント評価の欠落とコミュニティへの呼びかけ
司会： 私がこのチャートをお見せしたのには理由があります。エージェンティックAIのコミュニティが、本当に重要であるにもかかわらずあまり時間を割いていないテーマがあるからです。それは、エージェントをどのようにベンチマークし、評価するかという問題です。私たちはモデルについて語りますし、トークンのことも理解しています。1ドルあたりのトークン数や、1ワットあたりのトークン数といった指標も理解しています。しかし、エージェンティックAIの評価については語っていません。
司会： ここで私たちにとって本当に重要なのは、特定のモデルの性能そのものではありません。重要なのは、タスク全体を最低のコストで成功裏に完遂できるかどうかであり、それこそが本当の問いです。この領域には、まだ多くの取り組みが必要だと私は考えています。今お見せしているのは、私がこれまでに見た中で、この問いに最も近い分析です。いくつかのモデルに複数のタスクを実際に試させ、タスクを最後までやり遂げられるかを見たものです。このチャートでは、すべてのモデルが与えられたタスクを完了しましたが、緑の領域に入っているモデルは、タスクを完了したうえで最も低いコストでそれを達成したモデルです。これは、Agentic AI Foundationがワーキンググループの中で検討している数多くの課題のひとつです。
司会： ほかにも私たちは、エージェントによる決済をどう標準化するか、エージェントがカタログにどのようにアクセスするかをどう標準化するかといった課題にも取り組んでおり、こうした問題の多くがワーキンググループで議論されています。昨日も申し上げましたが、これらのワーキンググループはオープンで、どなたでも自由に参加できます。ぜひ皆さんにも参加していただきたいと思っています。
司会： そして、新しいワーキンググループを提案していただくことも歓迎します。実際、私には多くの空白が見えています。たとえば、メモリのワーキンググループがありません。メモリとコンテキストは非常に重要です。ハードウェアのワーキンググループもありません。私は、将来ハードウェアは、モデルだけでなくハーネスのスケーラビリティを実現するために、根本から再設計されることになると考えています。モデルではなく、ハーネスのためにです。このように、ワーキンググループにはまだ多くの空白があり、コミュニティからの提案をぜひいただきたいと思っています。
司会： 最後にこのスライドをお見せして締めくくります。私たちは数多くのイベントを開催しています。私たちの役割はコミュニティを広げることであり、幸いにも多くのアンバサダーの方々がその拡大を手伝ってくださっています。次のイベントは来週、ヨーロッパのアムステルダムで開催されます。そこで皆さんの何人かにお会いできればうれしいです。私たちのイベントに参加される際には、こちらの登録コードをご利用ください。25%の割引が受けられます。それでは、素晴らしい基調講演者の方々にバトンを渡したいと思います。最初の登壇者をご紹介します。
2. エージェントAIエコシステムの「上流」へ：消費者から貢献者へ（Yoshi Tabata・日立製作所）
2.1 AI消費大国・日本と「消費者か貢献者か」という問い
司会： 最初の登壇者はYoshi Tabataさんです。Tabataさんは日立製作所のオープンソースプログラムオフィス（OSPO）でチーフOSSコンサルタントを務めていらっしゃいます。また、AAIFのアンバサダーでもあり、そのご尽力に感謝しています。さらにKeycloakのコントリビューターであり、CNCFのIAMに関するホワイトペーパーの共著者でもあります。Tabataさんに大きな拍手をお願いします。
Yoshi Tabata： おはようございます、日本の皆さん。Yoshi Tabataです。本日は、エージェントAIエコシステムの「上流」についてお話ししたいと思います。始める前に、ひとつ質問させてください。すでにオープンソースコミュニティに貢献されている方はどのくらいいらっしゃいますか。……ありがとうございます。1割くらいでしょうか。素晴らしいことです。今日の私の目標はシンプルです。この基調講演が終わるころに、エージェントの上流に貢献し始める人が、あと何人か増えていればと願っています。
Yoshi Tabata： まず、いくつかの数字を見てみましょう。日本ではすでにAIが使われています。最近の調査によれば、日本の組織の85%が、AIはすでに自分たちの技術業務を変えつつあると回答しています。日本ではAI関連の採用も急速に伸びており、2026年にはAI関連の求人が54%増加すると見込まれています。これは世界平均のおよそ2倍にあたります。ここからひとつ明らかなのは、日本はすでにAI技術の主要な消費国だということです。
Yoshi Tabata： では、消費者であるだけで十分なのでしょうか。消費者とは「使う側」です。消費者は技術を選定し、導入し、運用し、サービスを提供し、ベンダーからのサポートを受けます。しかし、もう一方の側もあります。それが貢献者の側、つまり「決める側」です。貢献者は課題を提起し、その課題について議論し、新しいアイデアを提案し、提案をレビューし、仕様やコードを書きます。消費者であることにも価値はあります。しかし消費者は、誰か別の人が作ったルールの中で仕事をすることになります。一方、貢献者はそのルールそのものに影響を与えることができます。これは非常に大きな違いです。
Yoshi Tabata： では、実際にそうした決定を下しているのは誰なのでしょうか。あらゆるプロトコルの背後には、人々のコミュニティがあります。消費者はエージェントを構築し、ツールを接続し、サービスを組み合わせ、製品を届けます。こうした活動のすべてが、プロトコルや仕様、オープンソースプロジェクトに依存しています。そして、それらを作ったのは人間です。どの仕様もひとつのアイデアから始まり、どのプロトコルもひとつの提案から始まりました。コミュニティはそうしたアイデアを議論し、提案をレビューし、何をマージするか、何を仕様の一部にするかを決めていきます。だからこそ、コミュニティに参加することが重要なのです。
2.2 今が貢献の好機である理由：接続性とアイデンティティ・信頼
Yoshi Tabata： では、なぜ今この話をするのでしょうか。それは、今まさに貢献の大きなチャンスが訪れているからです。技術は、まだ形が定まっていない段階のほうが影響を与えやすいものです。OAuth、Kubernetes、Prometheus、Envoyはすでに広く普及しています。OpenTelemetryやSPIFFEも、クラウドネイティブ基盤の確立した構成要素になりつつあります。しかし、これらもすべて、かつては新しい技術でした。そして当時参加した人々が、その技術の形づくりに関わってきたのです。今でもこれらのプロジェクトに貢献することはできます。しかし、ある技術がいったんデフォルトになってしまうと、その方向性に影響を与えることははるかに難しくなります。
Yoshi Tabata： エージェントの領域はそれとは違います。MCP、A2A、エージェントのアイデンティティ、認可、監査といった領域では、多くの重要な問いがまだ答えの出ていない状態にあります。早く参加すればするほど、より大きな影響力を持つことができます。だからこそ、今が貢献すべきタイミングなのです。
Yoshi Tabata： では、具体的にどこにチャンスがあるのでしょうか。エージェンティックなスタックはまだ進化の途上にあり、重要な意思決定が今まさに行われている領域が2つあります。1つ目は接続性です。現在、MCPはツールを接続するための共通の方法になりつつあり、A2Aはエージェント同士の通信の共通の方法になりつつあります。2つ目はアイデンティティと信頼です。こちらの領域は成熟度がはるかに低く、業界はいまだにいくつかの根本的な問いに答えようとしている段階です。そのエージェントは誰なのか。誰の権限を使っているのか。何をすることが許されているのか。なぜ別のエージェントがそれを信頼すべきなのか。接続性は形になりつつありますが、アイデンティティと信頼は今まさに定義されている最中です。AAIFのIdentity and Trustワーキンググループなどで、活発な議論が行われています。
Yoshi Tabata： なぜアイデンティティと信頼が今これほど注目されているのか。それは、エージェンティックAIが概念実証から本番環境へと移行しつつあるからです。典型的なPoCでは、状況は比較的シンプルです。エージェントが1つ、ツールが1つ、トラストドメインも1つで、トークンも1つあれば足りることが多いのです。ところが本番環境はまったく違います。複数のエージェント、複数のツール、複数の組織、そして複数のトラストドメインが存在します。そうなると、ただちに重要な問いが浮かび上がります。そのエージェントは誰のために行動しているのか。何をすることが許されているのか。誰がそれを信頼するのか。こうした問いはもはや無視できません。だからこそ、今まさに活発に議論されているのです。
2.3 標準形成のサイクルと日本の現状、日立の実践
Yoshi Tabata： では、標準は実際にどのように作られるのでしょうか。標準は、ひとつの決定によって作られるものではありません。サイクルを通じて作られていきます。まずガバナンスがあります。ここでは、メンバーシッププログラムやアンバサダー、ワーキンググループが、どのテーマを議論するかを決めます。次に仕様策定と検証の段階があります。仕様、レビュー、ホワイトペーパー、そして適合性検証の作業によって、優先事項がルールへと変わっていきます。続いてエコシステムの構築です。Kubernetes、Keycloak、OpenTelemetry、SPIFFEのようなプロジェクトが、そのルールを実用的なデフォルトへと変えていきます。そして最後にコミュニティ活動が、次の世代の貢献者を育てます。ミートアップ、講演、ブログ、翻訳といった活動です。どのレビュアーも、どのメンテナーも、どのアンバサダーも、最初はこうした活動から始まったのです。標準はひとつの決定で生まれるのではなく、このようなサイクルの繰り返しを通じて進化していきます。
Yoshi Tabata： では、このサイクルの中で日本はどこに立っているのでしょうか。日本がエージェント技術の大きな消費者であることは間違いありません。しかし、日本人の貢献者の数はまだ限られています。ガバナンスの段階では、日本のメンバー企業、アンバサダー、ワーキンググループの参加者はごく少数です。仕様策定と検証の段階では、仕様やレビュー、適合性検証の活動に日本人の名前が登場することはまだ比較的まれです。エコシステム構築の段階でも、AAIFに関連するプロジェクトの日本人メンテナーはまだ少数にとどまっています。そして貢献者の育成という面でも、この領域のローカルなミートアップや講演、コミュニティリーダーはまだ比較的少ないのが現状です。日本はこれらの技術を広く使っていますが、それを形づくることに参加している人は比較的少ないのです。問題は技術力ではなく、参加なのです。
Yoshi Tabata： ただし、これは日本で誰も貢献していないという意味ではありません。日本からの実例はすでにあります。私が勤めている日立製作所もそのひとつです。日立はこのサイクル全体にわたって参加しています。ガバナンスの面では、日立はAAIFのゴールドメンバーであり、AAIFのアンバサダーもいます。Identity and Trustワーキンググループを含むワーキンググループにも参加しています。仕様策定と検証の面では、MCPの認可に貢献しています。これにはホワイトペーパー、仕様レビュー、バグ修正、適合性検証の作業が含まれます。エコシステム構築の面では、Keycloakに貢献しており、コミュニティにはメンターがいて、MCP認可の初期機能の実装にも協力してきました。そして貢献者の育成の面では、講演やブログ、ローカルイベントを通じて、Agentic Tokyoをはじめとするコミュニティ活動を支援しています。つまり、日本からの参加は十分に可能なのです。日立はひとつの例にすぎず、日本の組織や個人も同じように貢献できます。
Yoshi Tabata： では、どうすれば貢献者になれるのでしょうか。消費者と貢献者の距離は、多くの人が思っているよりもずっと近いのです。実際には、ほとんどの人がもっと小さなところから始めています。ワーキンググループに参加する、技術ブログを書く。それが、ワーキンググループのメンバーやAAIFアンバサダーになるための最初の一歩になり得ます。イシューを1つ起票することが、仕様につながることもあります。小さなバグ修正を1つ提出することが、メンテナーやコードコントリビューターへの道につながることもあります。ミートアップに参加することが、コミュニティのオーガナイザーになるきっかけになることもあります。道は1つではありませんし、決められたスタートラインもありません。皆さんが今すでにやっていることに最も近い道を選んでください。
Yoshi Tabata： 最初の問いに戻りましょう。消費者でいるのか、それとも貢献者になるのか。上流はまだ開かれています。皆さんの多くが、今週その最初の一歩を踏み出してくださることを願っています。ありがとうございました。
3. アクセスは信頼ではない：推論から実行へ進むための制御層（Alan Tang・Workato）
3.1 接続性の構想と、エージェントを信頼するための7要件
司会： 素晴らしいお話でした。本当に理想的なアンバサダーですね。次の登壇者はAlan Tangさんです。Alan TangさんはWorkato Japanのバイスプレジデント兼ゼネラルマネージャーであり、Workato Asia Pacificの創業者兼シニアアドバイザーとして、同社のアジア太平洋事業を立ち上げ、拡大させてきた方です。ご来場ありがとうございます。Alanさんを拍手でお迎えください。
Alan Tang： 皆さん、おはようございます。Alanです。私はWorkatoの創業者の一人です。私たちは約13年前、非常にシンプルな考えから会社を立ち上げました。私たちが使っているエンタープライズシステム、つまりアプリケーション同士が、シームレスかつ簡単に互いに対話し、つながり合えるべきだという考えです。シリコンバレーの小さなスタートアップとして始まり、今ではグローバルで約1,500人、日本では約50人のチームになりました。メインホールにはブースも出していますので、ぜひお立ち寄りください。
Alan Tang： AIの重要性が増していく今の世界で、私たちが掲げてきた接続性というビジョンは、多くのAIプロジェクトにとってさらに重要になってきています。AIモデルは、私たちが何を望んでいるのかを理解する能力をどんどん高めています。しかし、エージェントが実際に行動を起こす必要がある場面、たとえば請求書を作成する、返金を処理する、従業員の記録を更新するといった場面では、理解は出発点にすぎません。なぜなら、AIが取った行動に対しては、依然として誰かが責任を負わなければならないからです。そこで今日は、AIエージェントに意味のある仕事を任せながら、同時にエージェントが動作するシステムに対する制御をどう維持するかを考えたいと思います。私がお話しするのは、まさにハーネスの層についてです。
Alan Tang： MCPは、エージェントがツールを発見し呼び出すためのオープンな方法として、強固な基盤です。機能をエージェントやフレームワークをまたいで再利用可能にしてくれます。しかし、アクセスは信頼と同じではありません。エージェントに接続やアクセスを与えたからといって、そのエージェントを信頼できるということにはならないのです。信頼は、AIに何が見えているのか、AIに何ができるのか、そしてAIが行ったすべてのことの記録をどう確実に残すのかを、私たちがどれだけ理解しているかにかかっています。この原則は、異なるモデルやプロトコル、プラットフォームのどれを使っていても変わりません。エージェントを信頼するには、それが何をしているのかを把握している必要があるのです。
Alan Tang： エージェントが何をしているのかという観点から信頼できる状態にするには、7つの要件が必要だと私たちは考えています。そのうち4つは、AIエージェントにできることの境界を定める要件です。統制された操作、決定論的な変更、業務レベルで有用なツール、そして限定されたアクセスです。残りの3つは、実行そのものを信頼に足るものにする要件です。何かが失敗したときに、重複を生み出さずに安全にリトライできるか。何か問題が起きたときに復旧できるか。そして、誰が、どこで、何を、なぜ行ったのかを再構成できるように、エージェントの行動を観察できるか、ということです。
3.2 推論のフロンティアから実行のフロンティアへ：3条件と3つのギャップ
Alan Tang： 現状では、ほとんどの企業がまだ「推論のフロンティア」にとどまっています。知識を検索し、質問に答え、取るべき行動を提案する段階です。しかし、本当のビジネスインパクトが生まれるのは、エージェントが推論のフロンティアを越えて「実行のフロンティア」に入ったときです。そのためには3つのことが必要です。1つ目は、実行が決定論的であることです。つまり、プロセスをエンドツーエンドで一貫して実行できなければなりません。請求書を毎回違うやり方で作成するわけにはいきません。2つ目は、ポリシー、権限、コスト、ガードレールの範囲内で実行されることです。私たちはこれを「統制された実行」と呼んでいます。そして3つ目は、組織全体に展開できるエンタープライズ規模のスケールを備えていることです。
Alan Tang： つまり課題は、モデルが推論できないことではありません。モデルは非常にうまく推論できます。課題は、その下にある基盤が、行動を信頼に足るものにする段階にまだ達していないことなのです。では、組織が推論のフロンティアから実行のフロンティアへ移るのを妨げているのは何でしょうか。私たちが一般的に目にするのは、3つの問題です。
Alan Tang： 1つ目は、私たちが「実行ギャップ」と呼んでいるものです。エージェントは推論はできても、オンプレミスのシステムからレガシーなプロセスまでをまたぐ、複雑で多段階の業務プロセスを最後までやり遂げることに苦労しています。2つ目は「制御ギャップ」です。エージェントはアクセス権を持っていても、その行動が常に統制されているわけでも、完全に追跡可能なわけでもなく、場合によってはエージェントのしていることを信頼すらできません。3つ目は「スケールギャップ」です。共有された機能やガバナンスの上に積み上げるのではなく、ユースケースごとに毎回ゼロから構築しなければならない状態のことです。これらのギャップが解消されるまでは、エージェントは非常に便利なアシスタントであり続けるかもしれませんが、エンタープライズの業務における信頼されたオペレーターになることは難しいでしょう。
3.3 分断されたエンタープライズAIと、制御・実行層の役割
Alan Tang： そして、前の基調講演者の方も触れていたと思いますが、課題はエンタープライズAIがひとつのシステムとして発展しているわけではないという点にあります。組織は、ニーズに応じて異なるモデル、異なるコパイロット、異なるエージェントフレームワークを採用しています。そしてそれぞれが、独自のアイデンティティ、セキュリティ制御、ガバナンス、可観測性、そして業務アプリケーションへの接続を持っている可能性があります。
Alan Tang： そうした制御は、ひとつのエコシステムの中ではうまく機能するかもしれません。しかし考えてみてください。皆さんの仕事は、ひとつのアプリケーションの中だけに存在しているわけではありません。ひとつの業務プロセスが、Slackから始まり、Salesforce、Jira、Confluence、そしてSAPにまで及ぶこともあります。複数のシステムをまたいでいるのです。もしそれぞれのAIが、異なるアクセスモデルや異なるプロトコルを通じてそれらのシステムやアプリケーションにアクセスすれば、生成される監査証跡もまったく異なるものになります。制御は非常に断片化してしまいます。これは新しい問題ではありません。APIが登場し始めたころを思い出してください。あちこちにAPIが乱立し、企業がそれらを統制することが事実上不可能になりました。MCPとAIエージェントも、非常によく似た状況に陥るでしょう。そして、この断片化こそが、実行、制御、スケールのギャップをさらに解消しにくくしているのです。
Alan Tang： これをもっと具体的にするために、ひとつの例を考えてみましょう。たとえば1時間後に会議に行く予定があるとして、「自分の未解決のJiraチケットをすべて引き出し、Salesforceの商談の状況を確認し、この会議があることをSlackでチームに知らせて」と指示するとします。3つのパターンでプロンプトはまったく同じですが、変わるのはエージェントを取り巻くアーキテクチャです。左側の制御層がない場合、エージェントは複数のシステムにまたがって予測不能な変更を加えてしまうかもしれません。真ん中の、制御層はあるものの信頼できる実行が伴っていない場合、エージェントは正しい権限を持っているかもしれませんが、結果は非常に不安定になり得ます。結局、エージェントが作業を正しく行ったかどうかを誰かが確認しなければなりません。そして制御と信頼できる実行の両方がそろっている場合、エージェントはアイデンティティを検証し、適切なポリシーを適用し、ワークフローを一貫して完遂し、何が起きたかを記録できます。モデルも、プロンプトも変わっていません。変わったのは、エージェントとモデルを取り巻く基盤であり、それがより大きなインパクトのある結果を生み出したのです。
Alan Tang： これこそが、ハーネスにおける制御層と実行層の役割です。組織が選んだAIを、実際に仕事が行われているシステムへとつなぎながら、一貫したポリシー、権限、オーケストレーション、そして監査可能性を適用するのです。Workatoは、この層を提供するために構築されたプラットフォームの一例にすぎません。しかし、より広い原則はベンダー中立です。エンタープライズAIには、モデルとプロトコル以上のものが必要です。意図を、統制された現実の行動へと変える信頼できる方法が必要なのです。
Alan Tang： ですから、MCPは積み上げていく価値のある基盤です。オープンなプロトコルは、エコシステムが共にイノベーションを起こすことを容易にしてくれます。しかし、信頼されたエンタープライズの行動には、AIに何が見えるかの制御、AIに何ができるかの制御、そして何が起きたかの記録が必要です。もっと詳しく知りたい方のために、私たちのカンファレンスの無料パスをご用意していますし、外にはブースもあります。最後に申し上げたいのは、問いはもはや「AIに何ができるか」ではないということです。問うべきは、「自分たちの会社の中で、AIに何を安全に任せられるか」なのです。ありがとうございました。
司会： Alanさん、ありがとうございました。信頼できる実行を担うエージェントを構築するうえで、ハーネスがいかに重要であるかを語っていただけたことを、本当にうれしく思います。
4. Skills over MCP：スキルとMCPを一つの経路で届ける（Ola Hungerford・Nordstrom／MCPメンテナー）
4.1 スキルとMCPの補完関係と、配布経路が二つあることの課題
司会： 次の登壇者はOla Hungerfordさんです。Olaさんをご紹介できることを本当にうれしく思います。OlaさんはNordstromのプリンシパルエンジニアであり、AAIFのアンバサダーでもあります。ありがとうございます。さらにMCPのメンテナーであり、コミュニティモデレーターでもあります。Olaさんについてもっと知りたい方は、MCPのリーダーボードをご覧ください。Olaさんがどの位置にいるかがわかるはずです。Olaさんを拍手でお迎えください。
Ola Hungerford： こんにちは、Olaです。ご紹介いただいたとおり、私はNordstromでプリンシパルエンジニアを務めていて、オープンソースの世界ではMCPのメンテナーとコミュニティモデレーターをしており、MCPのワーキンググループのいくつかを率いています。今日お話ししたいのは、今年の初めごろから私がとても興味を持ち始めたテーマです。それは、エージェントスキルとMCPがどう交わるのか、あるいはどう交わり得るのかという問いです。スキルもMCPも、ある程度の期間使われてきたことで、今では両者を競合するものとしてではなく、互いに補完し合うものとして捉える人が増えてきたと思います。今日は、私がこれをどのように実験し、人々を集めて拡張仕様を作り上げるに至ったのかをお話しします。
Ola Hungerford： まず少し自己紹介をさせてください。私は以前シアトルに住んでいて、最近アリゾナに引っ越しました。こちらはご近所さんの写真です。この猫は誰かのペットのように見えるかもしれませんが、実はボブキャットで、うちの前庭で昼寝をすることにしたようです。せっかくなので共有しておきます。それから、この私の写真は、夫と一緒に作ったミュージックビデオからのものです。私たちはツーソンで一緒にレコーディングスタジオも運営しています。自己紹介はこのくらいにして、本題のSkills over MCPに入りましょう。
Ola Hungerford： 最近の私は、エージェントをこんなふうに落書きで表現するのが気に入っています。このキャラクターをエージェンティックな存在だと思ってください。たとえばエージェントがあって、それがサーバーに接続され、ツールの集合を持っているとします。通常そうするときには、特定の目的やタスクが念頭にあります。ツールの説明は、そのツールで何ができるのかをエージェントが理解する助けにはなりますが、そのタスクのためにツールをどう組み合わせて使えばよいのかまでは教えてくれません。実行の順序、ドメイン固有の慣習、専門的な知識といったものも同様です。そこで本当に役立つのがエージェントスキルです。
Ola Hungerford： たとえば「宇宙船を作りたい」という目標をエージェントに伝えたとしましょう。状況によっては、特に非常に高度なフロンティアモデルであれば、エージェントに解の空間を自由に探索させ、目標を達成する方法を自分で考えさせるのが良い選択であることもあります。ツールやその他の構成要素といった素材がそろっていれば、エージェントは良い解決策を見つけられるでしょう。しかし、エージェントに何かを頼むときに、こちらに専門的な知識や好みがあるのであれば、毎回エージェントに一から考えさせたいとは限りません。そうした場合に、スキルを組み合わせて使うことが、特定の成果を得たり、自分の好みや知識を反映させたりする手段になるのです。
Ola Hungerford： では、スキルとMCPを一緒に使いたいとしましょう。これまでの標準的なやり方は、リポジトリにプラグインやスキルを置き、プラグインやプラグインマーケットプレイスを使ってそれらをインストールし、MCPサーバーも同じようにして設定するというものでした。それでも動きはします。しかしそれは、2つの異なる配布経路を持つことを意味します。アクセスの制御方法も2通りになり、それらに接続し、エージェントのハーネスに公開する方法も2通りになってしまうのです。Skills over MCP、つまりスキルをツールと並べて提供するという考え方は、いわば道具と同じ箱に取扱説明書を入れて出荷するようなものです。私たちが目指しているのはまさにそれです。経路を1つにまとめ、アクセス制御も1つ、バージョン管理の方法も1つ、ツールとスキルをまとめて配布する方法も1つにできるのです。
4.2 ワーキンググループでの検討と採用した設計
Ola Hungerford： ワーキンググループでは、いくつかの異なる解決策について議論しました。とても興味深かったのは、ごく初期の段階から、多くの人が同じような慣習にたどり着いていたことです。それでも、議論はいくつかの段階を経ました。たとえば、新しいプリミティブを追加するという提案がありました。つまり、ツール、プロンプト、リソースに加えて、スキルという4つ目のプリミティブを設けるという案です。また、こうした用途には今でもサーバーインストラクションを使うことができます。サーバーインストラクションの中で、ツール同士をどう組み合わせて使えるのかを説明するわけです。実際、これは今でもスキルを指し示す方法として使えますし、今回の拡張仕様を補完するものでもあります。一方で、素のMCPリソースだけでスキルを表現しようとすると、どのリソースが実際にスキルなのかを判別するのが難しくなってしまいます。さらに、実際に世の中で見かけたやり方として、サーバーに専用のツールを追加して、スキルを一覧表示したり提供したりするという方法もありました。
Ola Hungerford： 最終的に私たちが落ち着いたのは、シンプルにMCPリソースを使うという方式です。この拡張仕様には2つの部分があります。1つは、サーバー上でMCP経由で公開したいスキルを一覧表示する仕組みです。もう1つは、スキルがリソースであることを活かして、ローカルのファイルシステム上でファイルを段階的に読み込むのと同じように、MCP上でリソースの読み取りを通じてスキルを読み込めるようにする仕組みです。
Ola Hungerford： これは3つの読み取りステップとして考えることができます。まず、サーバー上のすべてのスキルを一覧表示する段階では、スキルのURIと、フロントマターのすべてが得られます。この拡張仕様では、再発明しようとしていないことがたくさんあります。Agent Skillsの仕様にはすでに慣習や、フロントマターの要件や構造が定められています。ですから私たちはフロントマターをそのまま受け渡すことにしました。多くの人がこのフロントマターをカスタムメタデータなどの用途にも使っています。さらに、SKILL.mdファイルと一緒に置かれている他のファイル、つまりリソースの一覧も含まれます。そして、ローカルファイルの場合と同様に、そのスキルを実際に使う必要が生じたとき、つまりスキルが有効化されたときに初めてSKILL.mdを読み込み、そこから必要に応じて先へ進んでいくわけです。
Ola Hungerford： 私たちが特にきちんと定めたかった点がいくつかあります。1つはスキルの識別子をどう解決するかです。これは、ファイルベースのスキルであっても少し一貫性を欠くことがある問題です。今回は、MCP経由のスキルの識別子を、サーバーとスキルリソースのURIの組み合わせとすることに決めました。また、スライドのテキストが一部欠けているようですが、すべてのスキルと、スキルに含まれるすべてのファイルに対してダイジェストを持たせることについても多く議論しました。これによって、このスキルを自分はすでに承認したか、スキルが変更されていないかを確認できるようになります。
Ola Hungerford： そしてちょっとしたおまけの機能として追加したものもあります。現在のMCPのリソースには、ディレクトリ一覧に相当する仕組みがありません。ローカルであれば、スキルに含まれるファイルを列挙したいときは、そのディレクトリの中身を一覧表示すれば済みます。そこで私たちは、ディレクトリを読み取るためのオプションのメソッドも追加しました。
4.3 仕様化のプロセスと教訓、未解決課題、そして閉会
Ola Hungerford： ここからは、インタレストグループを立ち上げ、拡張仕様を開発・提案し、それが実際に承認されるまでのプロセスについてお話ししたいと思います。承認されたのは確か1週間ほど前で、最終化もほぼ目前で、今まさにその仕上げをしているところです。これは、インタレストグループから始まった非常に興味深い事例でした。先ほど言ったように、私自身がとても興味を持っていましたし、他にも多くの人が関心を持っていたり、この方法をいろいろと実験したりしていました。そこでインタレストグループを結成し、しばらくして、実際の拡張仕様にしたい提案がまとまったと判断した段階で、グループをワーキンググループへと移行させました。
Ola Hungerford： そして、この仕様拡張提案のためのプルリクエストを作成しました。SEP 2640だったと思いますが、なぜかこういう番号はなかなか覚えられません。SEPとはSpecification Enhancement Proposal、つまり仕様拡張提案の略です。その後、先ほど申し上げたように反復的な改善を重ねて承認に至り、最後の「Final」の段階は、これが本物になった、MCPの一部になったという段階です。
Ola Hungerford： ただ、その過程では非常に良い進展があった一方で、反復が必要になると、本当にここまで来られているのだろうかと感じることもありました。多くのフィードバックが寄せられ、それを取り込むには多くの時間と議論が必要になります。私たちは皆、早くリリースしたいと強く思っていました。しかし同時に、拡張仕様とはいえ、現在の形のまま全員に実装してもらって満足できるものにしたいとも考えていました。ですから反復の過程では浮き沈みもありましたが、最終的にはそのおかげでより良いものになったと思います。
Ola Hungerford： 時間がなくなってきたので、その反復の過程で学んだことをいくつか手短にお伝えします。まず、あえてサポートしないことにした機能がいくつかあります。後から追加するほうが、取り除くよりもずっと簡単だからです。最近の仕様バージョンでは、採用されなかったり、どう採用すればよいか理解されなかったりしたために廃止された機能がいくつかありました。私たちは仕様を最小限に保つことも重視しました。これは最後のほうでコアメンテナーから受けたフィードバックの中心的な内容でもありました。もし最初から、スキルをMCP経由で提供し利用するためのあらゆる方法を盛り込んでいたら、選択肢が多くなりすぎて、かえって断片化を招いていたと思います。これも時間をかけて反復したポイントでした。
Ola Hungerford： 参加してくれた組織や人々の多様さについても一言触れさせてください。本当に多くの異なるグループや企業が参加してくれたことを、とてもうれしく思っています。こちらは、発言したり、コメントを書いたり、レビューしたり、コミットしたりしてくれた人たちの一覧です。本当にわくわくする経験でした。
Ola Hungerford： 一方で、まだ解決していないこともいくつかあります。その大きな理由は、それらがスキルに固有の問題ではなく、MCP全体で解決したいより大きな問題に関わっているからです。こうした課題は、皆さんが参加して実現を後押ししてくださるのに最適な場所だと思います。たとえば、ツールやリソース、スキルが大量にある場合に、それらをどう効率的に検索し、ロードするのかという問題です。世の中にはすでに多くの解決策がありますが、私たちが議論しているのは、MCPの中で段階的開示をどう表現するかということです。また、先ほど触れた仮想的なディレクトリの一覧表示についても、今後ファイルシステムのワーキンググループが立ち上がる予定です。さらに、Agent Skillsの仕様の側でフォローアップしたいこともあります。MCPのためだけにそうした問題を解決したくはなかったので、ファイルベースのスキルでもMCPベースのスキルでも同じように動作するよう、Agent Skillsの仕様の中できちんと対応していきたいと考えています。
Ola Hungerford： ですので、こうした問題のどれかに関心があれば、ぜひ参加してください。今日どなたかが言っていた言葉をメモしておいたのですが、確か「これはすべて、参加した人によって形づくられる」という言葉でした。どこに参加すればよいのか、どうやって参加すればよいのかがわかりにくいこともあると思います。このリンク先のページには、今何が起きているのかについてどこで質問すればよいのか、どうやって貢献すればよいのか、メンテナーやグループの他のメンバーとどうやってコミュニケーションを取ればよいのかといった情報がたくさんまとまっています。Discordやその他の経路に参加したい方にとっては、特にここが最良の入り口になると思います。ありがとうございました。
司会： ありがとうございました。今日Olaさんが発表してくださった内容には、本当に圧倒されました。Olaさんは自ら一つのムーブメントを始め、そこに60社もの企業が加わり、非常に短い期間で拡張仕様を作り上げました。これこそアンバサダーの模範です。Olaさん、本当にありがとうございました。
司会： コーヒーブレイクに入る前に、いくつかお伝えしたいことがあります。まず、本日お越しいただいた皆さん、ありがとうございます。東京で初めて開催されるAgentCon + MCPConにご参加いただき、感謝しています。お茶とコーヒーは外にご用意しています。再開は10時20分です。この休憩を、ぜひ皆さん同士のネットワーキングに活用してください。私たちにも声をかけてください。財団にどのように貢献できるかについてアイデアをお持ちの方や、OlaさんやYoshiさんのように何らかのプロジェクトに貢献したいというアイデアをお持ちの方は、ぜひ私たちやアンバサダーのところに来て、このコミュニティに参加し、その一員となるためにどんなことができるかを一緒に話しましょう。それでは、休憩をお楽しみください。