AI開発の新時代：Microsoftが描くエージェント駆動型ウェブの未来

序章：AIが解き放つ「魔法」の再来

私は今でも、初めて書いたコードの一行を鮮明に覚えています。それはCompact 95というコンピューターの上で、まるで魔法をかけるようにして生まれたものでした。初めてのプログラムが動いた時、私は自分一人では決して創り出せなかった、より美しく、より興味深い何かを生み出した感覚に包まれました。その瞬間から、私はずっとその「魔法」について考え続けてきました。

過去15年間、私は機械学習分野で最も重要なプロダクトのいくつかを築き上げてきました。そして今、MicrosoftのコアAIプラットフォームを率いる機会を得ています。私たちの目標は、この部屋にいる一人ひとりがAIを駆使して世界を形作れるよう、力を与えることです。

今日、ここで皆さんとお話しできることを心から楽しみにしています。特に私がワールドフェアを愛しているからです。ワールドフェアは、想像力と現実の影響が融合する場所であり、過去1世紀にわたり、数々の革新がここで生まれました。1939年にはハリウッドが初めて私たちのリビングルームに入り込み、1964年には銅線越しに人の顔が見えるようになりました。そして今日、その舞台の中心にいるのが「エージェント」です。

エージェントは、学習し、適応し、私たちの生活のあり方を拡張します。そして何よりも、プロダクトの作り方を根本的に変えようとしています。では、私たちはどのようにしてこの地点にたどり着いたのでしょうか？

第一部：AI開発のパラダイムシフト - エージェントが変えるソフトウェアの世界

1.1. モデルの爆発的進化とエージェント的ウェブの到来

ここ数年で、モデルの状況は劇的に変化しました。かつてはごく少数のプロバイダーが提供する限られたモデルしかなかったものが、今ではこの場にいる多くの人々の貢献により、推論モデルの爆発的な増加が見られます。この爆発は、新たな能力と効率性をもたらしています。

多くのモデルは今や、複雑な仮説を生成し、非構造化データを理解し、特定の領域では博士号レベルの推論能力を発揮するに至っています。例えば、膨大な科学論文から未発見のパターンを見つけ出したり、医療画像から微細な異常を識別したり、あるいは法的な文書から複雑な条項間の関係性を解析したりといったことが、人間が行うのと同等かそれ以上の精度と速度で可能になりつつあります。

さらに、これらのモデルは単に強力なだけでなく、ますます効率的になっています。もはやデータセンターだけに閉じこもっているわけではありません。私たちのラップトップ上で動作し、ユーザーが完全に制御でき、レイテンシー（遅延）なく機能するローカルモデルが増えています。

このような状況が、「エージェント的ウェブ（Agentic Web）」と呼ばれる新たな世界を生み出し始めています。これは、エージェントがツール、モデル、そしておそらく他のエージェントと相互作用する世界です。その相互作用は、利用しているクラウドの種類、開発した企業、使用するデバイスに関わらず、シームレスに行われます。そして、この基盤の上で、AIエンジニアリングの世界にはいくつかの異なる力が働いています。

1.2. ソフトウェア開発の3つの大きな変化

「エージェント的ウェブ」の到来は、ソフトウェア開発のあり方を根本から変えようとしています。私たちは今、かつてのパラダイムから、より自律的で連携性の高いシステムへと移行する過渡期にいます。この変化は、以下の3つの主要な潮流によって特徴づけられます。

1.2.1. ペアプログラミングからピアプログラミングへ

かつて、私たちはマシンとコードを書き、マシンがそれを実行するという「人」と「マシン」のパートナーシップの下でプログラミングを行っていました。しかし今や、マシン自身がコードを書き、自己修正し、新たな機能のアイデアさえも提案できる世界へと移行しています。

GitHub Copilotはその先駆けとして、以前は単なる「サイドキック」として開発者を補助する存在でした。しかし、その進化は目覚ましく、今ではまるで人間の「チームメイト」のように、より能動的に開発プロセスに参加します。Copilotは、もはや単にコードを補完するだけでなく、コードベース全体を理解し、開発者のブランチ内で直接作業を行います。特定のタスクを割り当てるだけで、関連するコードの記述からテストの実行までを自律的にこなすことができます。これにより、開発者は煩雑なコーディング作業から解放され、より戦略的な「アーキテクチャの意思決定」や「エージェントチームのオーケストレーション」といった、より高レベルのタスクに集中できるようになります。

さらに、ソフトウェアの「メンテナンス」も大きく変わります。かつては新機能開発とメンテナンスが常にリソースを奪い合っていましたが、エージェントを活用することで、コードベースを継続的に改善・修正するエージェントを導入することが可能になります。私たちが開発した「FSY」はその一例です。これは「コードベースのためのグラフRAG」と考えることができ、コードを推論し、説明し、さらに継続的に改善し、問題のある領域を自律的に修正することさえ可能です。これにより、開発者はより創造的な問題解決に集中し、システムの健全性をエージェントに委ねることができるようになります。

GitHub Copilotのもう一つの画期的な進化は、「ピア」としての存在です。これまでAIは一般的なコードベースに対して一般的な知能で操作していましたが、GitHub Copilotの拡張機能がオープンソース化されたことで、Copilotはもはや単なる汎用的なツールではありません。チームのコーディングパターン、プロジェクトのドメイン知識、さらにはチーム固有の慣習までを深く理解するようになりました。これにより、Copilotは開発者自身の「言語」で効果的に対話できるようになり、過去の制約にとらわれず、より未来志向の設計と開発を可能にします。これは、単に開発作業を効率化するだけでなく、開発プロセスそのものを変革する力を持っています。

1.2.2. ソフトウェアファクトリーからエージェントファクトリーへ

従来のソフトウェア開発は、特定の機能を持つ「バイナリ」をビルドし、リリースすることに主眼を置いていました。しかし、エージェント的ウェブの世界では、この考え方が大きく変わります。私たちはもはや単なる実行可能なファイルを出荷するのではなく、むしろ「振る舞い（behaviors）」、つまりライブで学習し、適応し、再訓練し、再デプロイできる「エージェント」を出荷するようになります。

これは、ソフトウェアが一度リリースされたら終わりではなく、デプロイ後も継続的に改善し、変化し続けることを意味します。この変革の核心にあるのが、私たちが「シグナルループ」と呼ぶ概念です。シグナルループとは、エージェントがユーザーとのインタラクションや外部からのフィードバックを通じて、自己のパフォーマンスを評価し、その結果に基づいてモデルを微調整（ファインチューニング）することで、よりパーソナライズされた、より良い成果を生み出すという考え方です。

例えば、医療分野のコパイロット「Dragon」の事例は、このシグナルループの強力な効果を明確に示しています。Dragonは、医師が患者ケアに集中できるよう、診断記録の自動作成などを支援するコパイロットです。当初、汎用モデルをそのまま使用した際の性能は「まずまず」でした。その後、合成データによるファインチューニングを試みましたが、改善は限定的でした。しかし、実際に65万回にわたるユーザーインタラクションから得られたデータを活用し、ABテストを繰り返しながらモデルを微調整した結果、文字認識の受容率（character acceptance rate）は劇的に83%まで向上しました。これは、エージェントが実際の使用状況から学習し、自己改善を繰り返すことで、その品質が飛躍的に向上することを示しています。

この変化は、ソフトウェア開発が「線形のソフトウェアファクトリー」から、常に学習と改善を繰り返す「継続的なループ」へと移行することを意味します。Foundryは、まさにこのエージェント駆動型アプリケーションとエージェントシステムを構築するための基盤として設計されました。

1.2.3. クラウドからエッジへ

これまでの10年間、私たちの開発努力は、データが存在する「クラウド」にモデルを集約させることに注がれてきました。しかし、今やデータはもはや一箇所に集中しているわけではありません。私たちの身の回りのあらゆるデバイス、あらゆる場所にデータが遍在しています。

この変化は、単なる趣味の領域の話ではありません。大規模な実世界のアプリケーションで、その重要性が増しています。例えば、飲料水の瓶詰め工場では、毎秒10万ものセンサーデータをリアルタイムで処理し、潜在的なリスクを検出し、アラートを発し、その概要をクラウドに送信するエージェントが稼働しています。これにより、生産ラインの異常を即座に検知し、ダウンタイムを最小限に抑えることが可能になります。

また、ある病院システムでは、患者の長期的な医療データ（longitudinal data）を要約するエージェントを構築しています。医療データは、その性質上、コンプライアンスやプライバシーの厳格な規制により、クラウドに保存できない場合があります。このような場合でも、エージェントは「ローカル」な環境でデータを処理し、必要な情報のみを匿名化・要約してクラウドからアクセスできるようにすることで、プライバシーを保護しつつ、医療従事者が迅速に患者情報を把握できるよう支援します。

さらに、自動車会社との協力も進んでいます。自動車に搭載されるモデルは、トンネル内のようなネットワーク接続が不安定な環境でも機能する必要があります。エージェントはローカルで動作し、乗車体験をより安全に、よりスマートにするための意思決定を行います。

これらの例が示すように、「ローカル（エッジ）」はもはや、プラットフォームから切り離された派生的な存在ではありません。むしろ、プラットフォームの「コア」となる不可欠な部分です。クラウドでエージェントを作成し、それがローカルでシームレスに実行され、動作し、推論できること。これが、AIの遍在化を可能にし、新たな価値を生み出す鍵となります。

第二部：GitHub Copilotの革命 - 開発者のワークフローを再定義するAIアシスタント

Asha Sharma氏が語るように、Microsoftは開発者のワークフローを根本から変えるためのAI駆動型ツール群、特にGitHub Copilotの進化に注力しています。もはや単なるコード補完ツールではなく、開発プロセス全体をインテリジェントに支援する「ピア（同僚）」として機能するCopilotは、開発者の生産性と創造性を新たなレベルへと引き上げます。

2.1. Copilotの進化：単なる補助から真のチームメイトへ

かつて、プログラミングは人間がコードを書き、マシンがそれを実行するという明確な役割分担がありました。しかし、現代において、マシンはコードを書き、自己修正し、さらには新しい機能のアイデアさえも想像するようになりました。この変革の中心にいるのが、進化を遂げたGitHub Copilotです。

従来のCopilotは、開発者の隣でコードスニペットを提案する「サイドキック」のような存在でした。しかし、今日のCopilotは、開発者のコードベースに常駐し、作業中のブランチ内で直接機能する「チームメイト」へと変貌を遂げています。開発者はCopilotに特定のタスクを割り当てるだけで、Copilotは関連するコードの記述、修正、そしてさらにはテストの実行までを自律的に行い、タスクが完了するまで支援します。

これにより、開発者の時間の使い方は根本的に変わります。煩雑なコーディング作業やデバッグ、定型的なタスクに費やす時間が減り、より高レベルな「アーキテクチャの意思決定」や、複数のエージェントからなる「エージェントチームのオーケストレーション」といった、より戦略的で創造的な仕事に集中できるようになります。

さらに、ソフトウェアの「メンテナンス」のあり方も大きく変わります。かつては、新機能の開発と既存コードのメンテナンスが常に競合し、メンテナンスはしばしば後回しにされがちでした。しかし、新しい世界では、コードベースを継続的に改善・修正するエージェントを導入する機会が生まれます。

2.2. 継続的改善を支えるFSY（Graph RAG for Codebase）

このメンテナンスの課題を解決するために、Microsoftが開発したのが「FSY」です。FSYは、「コードベースのためのグラフRAG（Graph RAG for your codebase）」と考えることができます。RAG（Retrieval-Augmented Generation）は、外部の知識ベースから情報を検索し、それをLLM（大規模言語モデル）の生成に活用する強力な技術ですが、FSYはそのRAGの原則をコードベースに特化させて適用しています。

FSYは、コードベース全体をグラフ構造として捉え、その関係性や依存関係を理解します。これにより、以下のようなことが可能になります。

推論（Reasoning）: コードがどのように機能し、なぜそのように設計されているのかを理解し、複雑なロジックを推論します。
説明（Explanation）: 特定のコードブロックの目的、動作原理、他の部分との関連性などを開発者に分かりやすく説明します。これは、新しい開発者がプロジェクトに参加する際や、レガシーコードを理解する上で非常に役立ちます。
継続的改善（Continuous Improvement）: コードベースの改善点を自律的に特定し、リファクタリングの提案や、潜在的なバグの修正を行います。
問題領域の修正（Fixing Areas）: 特定のバグや脆弱性を発見した場合、その修正コードを提案し、適用することさえ可能です。

FSYの導入により、開発者はメンテナンス作業に費やす時間を削減し、より価値の高い新機能開発に集中できるようになります。また、コードベースの品質と健全性が継続的に維持されるため、技術的負債の蓄積を防ぎ、長期的なプロジェクトの成功に貢献します。

2.3. パーソナライズされたCopilot体験：GitHub Copilot Spacesと拡張性

GitHub Copilotのもう一つの画期的な進化は、そのパーソナライズされた体験と高い拡張性にあります。

2.3.1. GitHub Copilot Spaces：プロジェクト固有の知識への洞察

開発者が新しいプロジェクトに参加したり、既存の複雑なコードベースに取り組む際、初期段階で直面する最大の課題の一つは、「質問相手がいない」ことや「ドキュメントが不足している」ことです。この課題を解決するために導入されたのが「GitHub Copilot Spaces」です。

Copilot Spacesは、特定のプロジェクトに関する質問に答えるためのインテリジェントなQ&A機能を提供します。ユーザーは、Copilot Spaceを作成し、プロンプト（指示）を与えるだけでなく、そのスペースを特定のファイルセットで「グラウンディング（根拠付け）」することができます。これにより、Copilotはプロジェクト固有のコード、ドキュメント、設定ファイルといった「実際の事実」に基づいて質問に答えることができます。

デモでは、あるプロジェクトが「エージェント的なプロジェクト」であるかをCopilot Spaceに尋ねるシーンが紹介されました。Copilotは、その質問に対する優れた説明を返すだけでなく、その説明がコードベースのどの部分（ファイルやコードスニペット）に基づいているのかを明示します。これにより、開発者は単に回答を得るだけでなく、その根拠となるコードを即座に確認し、プロジェクトへの理解を深めることができます。

開発者は必要なだけCopilot Spacesを作成でき、スペースは質問に疲れることなく、常に正確な情報を提供します。これは、プロジェクトへのオンボーディングプロセスを劇的に加速し、新しいタスクに取り組む際の学習コストを大幅に削減します。

2.3.2. オープンソース化された拡張機能：チームのパターン、ドメイン、言語理解

これまでの汎用的なAIは、一般的なコードベースに対して一般的な知見を適用していました。しかし、MicrosoftはGitHub Copilotの拡張機能をオープンソース化することで、この状況を大きく変えました。

このオープンソース化された拡張機能により、GitHub Copilotは、もはや単なる一般的なAIではありません。

チームのコーディングパターンを理解する: チームがどのような命名規則を使用しているか、どのようなデザインパターンを好むか、どのようなライブラリやフレームワークを頻繁に使用しているかを学習します。
ドメイン知識を把握する: プロジェクトが属する特定のビジネスドメインや技術ドメインの専門用語、概念、慣習を理解します。
チームの「言語」を話す: これらパーソナライズされた理解に基づいて、まるでチームの一員であるかのように、開発者自身の「言語」で効果的にコミュニケーションを取り、適切な提案を行います。

これにより、開発者は過去の制約や一般的なベストプラクティスに縛られることなく、チーム固有のニーズや文脈に合わせて「設計を後退させる」のではなく、常に「前進する設計」を構築できるようになります。このパーソナライズされたCopilot体験は、開発者の生産性を高めるだけでなく、チーム全体のコラボレーションと知識共有を促進し、より高品質で整合性の取れたソフトウェア開発を可能にします。

2.4. デモが示すCopilotの驚異的な能力

セス・ワレズ氏によるライブデモでは、GitHub Copilotが開発者の日常業務において、いかに強力な支援となり得るかが鮮やかに示されました。彼のデモは、開発作業における3つの「面倒なタスク」をAIがいかに容易にするかを示しています。

2.4.1. プロジェクト理解の加速（Copilot Spaces）

デモの最初の部分は、新しいプロジェクトに飛び込む際の「千の疑問」に答えるCopilot Spacesの能力に焦点を当てました。Sethは、これからライブマルチエージェント音声デモで使用するプロジェクトについて、「これは本当にエージェント的なプロジェクトなのか？」という質問をCopilot Spaceに投げかけました。

Copilotは瞬時に、プロジェクトのコードベースの「実際の事実」に基づいて、質問に対する詳細かつ的確な回答を生成しました。さらに重要なのは、回答の根拠となったコードスニペットやファイルへの参照を提示したことです。これにより、開発者は回答の信頼性を確認できるだけでなく、関連するコードをすぐに読み解き、プロジェクトの全体像を深く理解するための足がかりを得ることができます。

Copilot Spacesは、新しいチームメンバーのオンボーディングを劇的に加速させ、既存のチームメンバーがプロジェクトの特定の側面について迅速に情報を得るための、 tireless (疲れることのない) な質問相手となります。

2.4.2. タスクの自動化と実行（README作成の例）

次に示されたのは、プロジェクトの最初のタスクをこなすCopilotの能力です。Sethは、新しくリリースしたプロジェクトのREADMEファイルを作成するようにという要望がユーザーから来たものの、自身で書くのは面倒だと感じていました。そこで彼は、GitHubのIssueを新しく作成し、タイトルを「architecture diary: need better setup instructions」（より良いセットアップ手順が必要）とし、説明を加えて、そのIssueをなんと「Copilot」にアサインしました。

驚くべきことに、Issueがアサインされると、Copilotはまるで人間の開発者のように「目玉」のアイコンを表示し、作業を開始しました。数分後（デモでは時間短縮のため結果が示されましたが）、Copilotは完全に自動で、詳細かつ高品質なREADMEファイルを生成しました。このファイルは、プロジェクトのセットアップ手順、アーキテクチャの概要、使用方法などが網羅されており、まるで人間が手間をかけて書いたかのような完成度でした。

このデモは、Copilotが単なるコード生成ツールではなく、プロジェクト管理ツール（GitHub Issues）と連携し、具体的な開発タスクを自律的に引き受けて完了させる能力を持っていることを示しています。これにより、開発者はルーティンワークから解放され、より複雑で創造的な問題解決に集中できるという、AIアシスタントの真価が示されました。

2.4.3. 他エージェントとの連携による深い課題解決（Omalyとの協調によるMLモデル構築と修正）

デモの3番目は、Copilotが他のエージェントと連携し、より深い、専門的な課題を解決する能力を示しました。Visual Studio Code内のGitHub Copilotは、その機能を拡張し、外部の専門エージェントと対話することができます。Sethは、Issueに「住宅価格を推論する新しいエージェントが必要」というタスクがアサインされていると述べ、Copilotに「住宅価格の予測を手伝ってくれませんか？」と尋ねました。

この際、GitHub Copilotは、自身が直接処理するのではなく、機械学習の専門家エージェントである「Omaly (MLE agent)」と連携しました。Omalyエージェントは、さらに内部的に、ユーザーの要求を推論するエージェントと、コードを記述するエージェントの2つのサブエージェントを持っています。

Sethが関連するデータファイル（CSVなど）を指定すると、Omalyエージェントはそれをまるで熟練した機械学習エンジニアのように分析し、その内容に基づいて推論を行いました。デモの最終結果として示されたのは、Omalyがデータの前処理からモデルのトレーニング、評価までを含む、完全な機械学習モデルを自律的に構築したコードでした。

さらに印象的だったのは、このプロセス中に「間違い」があった場合の対応です。デモでは、データファイルに「文字列が浮動小数点数の場所に入り込んでいた」という、よくあるデータ品質の問題が含まれていました。しかし、Omalyはこれを自動的に検知し、適切なデータ型への変換（修正）まで実行していました。

このデモは、GitHub Copilotが単一の汎用AIとして機能するだけでなく、特定の専門分野に特化した複数のAIエージェントと協調することで、開発者が直面する複雑な問題（この場合は機械学習モデルの開発）を、エンドツーエンドで解決できる強力なプラットフォームへと進化していることを示しています。これは、開発者がより複雑なシステムを構築する際に、各分野の専門家AIを動員するような感覚でAIを活用できる未来を示唆しています。

第三部：Microsoft Foundry - エージェント駆動型アプリケーションの核心プラットフォーム

セス氏によるGitHub Copilotのデモで紹介されたエージェントは、Microsoftの「Foundry」という基盤の上に構築されています。Foundryは、単なるAIプラットフォームを超え、エージェント駆動型システムを開発し、運用するための包括的なインフラストラクチャを提供します。Asha Sharma氏は、Foundryがもたらすビジョンと具体的な機能について深く掘り下げて説明しました。

3.1. Foundryのビジョン：ライブで進化するエージェントの実現

Foundryの核心にあるのは、ソフトウェア開発のパラダイムシフトです。従来の開発では、コンパイルされた「バイナリ」をリリースし、その後の機能追加やバグ修正は、次のリリースサイクルで対応するのが一般的でした。しかしFoundryでは、このアプローチが根本から変わります。私たちは「バイナリ」や「決まったリリース」を出荷するのではなく、ライブ環境で「再トレーニング、再デプロイ、そして変化」できる「エージェント」を出荷するようになります。

これは、エージェントが一度デプロイされたら終わりではなく、ユーザーとのインタラクションや実際の運用データから継続的に学習し、自己を改善していくことを意味します。この考え方を具現化したのが、前述の「シグナルループ」です。

シグナルループ：パーソナライズされたモデル微調整による品質向上

シグナルループは、エージェントがより良い結果を生み出すために、モデルをユーザーのニーズや具体的な成果に合わせてパーソナライズし、微調整していくプロセスです。これは長年議論されてきた概念ですが、Foundryはこれを現実のものとして、その効果を具体的な結果で示しています。

Foundryは、7万社以上の顧客をサポートしているだけでなく、Microsoft社内のすべてのCopilot製品の基盤ともなっています。その一例が、医療分野の最先端コパイロット「Dragon」です。Dragonは、医師が患者ケアに集中できるよう、診断記録の自動作成（スクライブ）などを支援します。

Dragonの開発チームは、まず市販の汎用モデルを使用しましたが、その性能は「まずまず」でした。次に、合成データを使ってモデルをファインチューニングし、少しだけ改善が見られました。しかし、真のブレイクスルーは、65万回に及ぶ実際のユーザーインタラクションから得られたデータを活用し、徹底的なABテストを繰り返しながらモデルを微調整した結果もたらされました。これにより、Dragonの文字認識の「受容率（character acceptance rate）」は驚異的な83%にまで向上しました。

このDragonの事例は、シグナルループの強力な効果を明確に示しています。エージェントが実際の運用データから学習し、自己改善を繰り返すことで、その品質と実用性が飛躍的に向上するのです。Foundryは、この「線形のソフトウェアファクトリー」から「継続的なループ」への移行を可能にするために構築されました。これにより、エージェントはデプロイ後も常に進化し続け、ユーザーに最適な価値を提供できるようになります。

3.2. エージェントインフラストラクチャの変革

Foundryは、エージェント駆動型アプリケーションとシステムを構築するためのインフラストラクチャ全体が変化していると捉え、その変化に対応するための包括的な機能を提供しています。時間の制約上、すべてを詳細に説明することはできませんが、主要な要素とその変革のポイントをいくつかご紹介します。

3.2.1. 多様なモデルへのアクセスとインテリジェントルーティング

Foundryは、特定の単一モデルがすべてのプロダクトに最適であるとは考えていません。多くの場合、最高のプロダクトは、多様なモデルのアンサンブル（組み合わせ）や混合によって構築され、それぞれのタスクに合わせて細かく調整されています。

そこでFoundryは、以下のような機能を提供します。

10,000以上のオープンモデルとプロプライエタリモデルへのアクセス: 開発者は、OpenAIのGPTシリーズのような商用モデルから、Llama2やMistralのようなオープンソースモデルまで、幅広い選択肢の中から最適なモデルを自由に選ぶことができます。
インテリジェントルーティング（Switchboard）: ユーザーのクエリやタスクの性質に応じて、最適なモデルに自動的にルーティングします。例えば、高精度が必要なタスクには大規模モデルを、低レイテンシーが求められるタスクには高速なモデルを、あるいは特定のドメイン知識が必要な場合には特化型モデルを選択するといったことが可能です。
セキュリティ、信頼性、データレジデンシー: どのモデルを使用する場合でも、FoundryはMicrosoftレベルのセキュリティ、高可用性、そしてデータが特定の地域に留まることを保証するデータレジデンシー要件を満たします。これにより、企業は安心してAIモデルを運用できます。

この機能により、開発者は特定のモデルに縛られることなく、常に最新かつ最適なAIモデルを組み合わせて、柔軟かつパワフルなエージェントを構築できます。

3.2.2. Agentic RAGによる知識活用の深化

RAG（Retrieval-Augmented Generation）は、今日のAIアプリケーションの約50%で使用されている主要な技術であり、LLMが外部知識を参照してより正確な回答を生成するために不可欠です。しかし、従来のRAGは「シングルショット（一回限りの情報検索）」であり、比較的「ナイーブ（単純）」なアプローチでした。

Foundryは、このRAGをさらに進化させた「Agentic RAG」を導入しています。Agentic RAGは、以下のような特徴を持つ「マルチショット」のアプローチです。

反復（Iterate）: 一度の検索で解決しない場合、質問を再構築したり、検索戦略を変更したりして、複数回にわたって情報を検索します。
評価（Evaluate）: 取得した情報の関連性や信頼性を評価し、生成される回答の品質を向上させます。
計画（Plan）: 複雑なクエリに対しては、問題を複数のサブタスクに分解し、それぞれに適した情報検索と推論の計画を立てて実行します。

このAgentic RAGの導入により、複雑なクエリに対する回答の精度が「40%向上」するという驚くべき結果が出ています。これは、エージェントがより深いコンテキスト理解と、より洗練された情報探索戦略を持つことで、LLMの能力を最大限に引き出し、従来のRAGでは難しかった高度な知識活用を可能にするものです。

3.2.3. インフラとしてのツール

良いエージェントを構築するには、単なるテキスト以上のものが必要です。Foundryは、ツールを単なる機能としてではなく、「インフラストラクチャ」として捉え、エージェント開発に必要なあらゆる要素を提供します。

1500以上のツール: Bing検索のような一般的なツールから、特定のAPI、データソース、あるいは外部サービスと連携するためのツールまで、膨大な数のツールが利用可能です。
MCP（Multi-Party Computation）とA2A（Agent-to-Agent）の採用: MCPは複数の参加者がそれぞれの秘密データを共有することなく共同で計算を行う技術であり、A2Aはエージェント同士が安全かつ効率的に通信し、連携するためのプロトコルです。Foundryはこれらのオープンプロトコルをいち早く採用し、よりセキュアで協調的なエージェントシステムの構築を可能にしています。
コードとコンテナのサポート: エージェントをデプロイし、実行するためには、コードの管理やコンテナ化された環境が必要です。Foundryは、これらも包括的にサポートし、開発者がエージェントのライフサイクル全体をシームレスに管理できるよう支援します。

これにより、開発者は豊富なツール群を活用し、エージェントが外部システムと連携したり、複雑な処理を実行したりすることを容易に実現できます。

3.2.4. エージェントの信頼性と説明責任

AIエージェントの能力が向上するにつれて、その信頼性、安全性、そして説明責任（Accountability）がますます重要になります。Foundryは、この領域にも積極的に投資し、以下の機能を提供しています。

主要な評価SDK（Evaluation SDK）: エージェントのパフォーマンスを客観的に測定し、品質を保証するための評価ツールキットです。これにより、開発者はエージェントの改善点を特定し、効果的なチューニングを行うことができます。
主要なレッドチーミングエージェント（Red Teaming Agents）: エージェントの潜在的な脆弱性、偏見、あるいは不適切な振る舞いを特定するための専門エージェントです。倫理的かつ安全なAIシステムの開発を支援します。
継続的監視（Continuous Observability）: テレメトリー（遠隔測定）はオプションではなく、Foundryの不可欠な要素です。OpenTelemetryとの統合により、エージェントがFoundryプラットフォーム上で構築されたものであろうと、他の場所で構築されたものであろうと、その動作を継続的に監視し、異常を検知し、パフォーマンスを分析することができます。

これらの機能により、開発者は強力なエージェントを構築できるだけでなく、そのエージェントが責任を持って、安全かつ信頼性の高い方法で動作することを保証できます。現在、Foundryのループを利用して毎日5万以上のエージェントが構築されており、その信頼性と実用性が実証されています。

3.3. Foundryのオープン性：エコシステムを拡大する共有の力

Foundryプラットフォームは、そのモジュラー設計に加え、オープン性にも重点を置いています。Microsoftは、オープンソースとオープンプロトコルへの継続的な投資を通じて、AIエコシステム全体の発展を支援し、開発者が「好きなツール」で作業できるようにすることを目指しています。

3.3.1. Gigapath：病理スライド解析の画期的なオープンモデル

オープン性の具体的な成果の一つが「Gigapath」です。これは、その種としては初めてのオープンモデルであり、病理スライドを理解できる最初のモデルです。病理スライドは非常に高解像度であり、もし印刷すれば「テニスコートほどの大きさ」になる10万ピクセル×10万ピクセルもの情報を含んでいます。

従来のモデルでは、このような巨大な画像を処理するためにダウンサンプリング（解像度を落とすこと）やリンティング（不要な情報を削減すること）が必要でしたが、Gigapathはこれらの前処理なしに、オリジナルの高解像度でスライドを理解できます。これを可能にしているのは、音声モデリングから借用した技術である「稀薄なアテンション（dilated attention）」の採用です。

Gigapathの登場により、これまでパッチワークのように部分的にしか分析できなかった免疫腫瘍環境を、マクロ環境だけでなく「ミクロレベル」で、しかも初めて完全に理解できるようになりました。これは、がん研究や診断において画期的な進歩をもたらす可能性を秘めています。そして、この強力なモデルがFoundry上でオープンに提供されていることは、研究者や開発者が最先端のAI技術にアクセスし、新たな発見やアプリケーションを創出するための大きな推進力となります。

3.3.2. DeepSeek R1モデルの迅速な統合

Microsoftは、オープンソースコミュニティの最新の進歩を迅速にFoundryプラットフォームに取り入れることにも力を入れています。その一例が、「DeepSeek R1」モデルの最新アップデートです。このアップデートは、リリースからわずか数日でFoundryプラットフォームに統合され、Microsoftが提供するすべてのセキュリティと安全性の保証の下で、すべてのユーザーがすぐに利用できるようになりました。

これにより、Foundryユーザーは、常に最新かつ最も高性能なオープンモデルにアクセスでき、彼らのエージェントやアプリケーションに迅速に組み込むことが可能になります。これは、Microsoftがオープンソースコミュニティとの連携を重視し、その成果を広く共有していくという姿勢の表れです。

3.3.3. A2A, MCP, その他オープンプロトコルへの継続的な投資

Microsoftは、A2A（Agent-to-Agent）やMCP（Multi-Party Computation）といったオープンプロトコルへの投資を継続しています。これらのプロトコルは、エージェント間の安全で効率的な通信や、プライバシーを保護しながらの共同計算を可能にするための基盤となります。

Microsoftは、これらのプロトコルが今後ますます普及し、AIエコシステムにおいて重要な役割を果たすと確信しています。そのため、Foundryはこれらのプロトコルを全面的にサポートし、開発者が「好きなツール」や標準的な方法で、エージェントやシステムを構築・連携できるようにすることを目指しています。

Foundryのオープン性は、単にモデルへのアクセスを提供するだけでなく、オープンな技術標準とプロトコルを推進することで、より相互運用性が高く、多様なベンダーやコミュニティが貢献できる、健全で活発なAIエコシステムを築くことを目的としています。これにより、AIの進化が特定の企業に限定されることなく、広く社会全体に利益をもたらすことが期待されます。

第四部：マルチエージェントの協調とエッジAIの現実 - Foundryが拓く新たな可能性

Asha Sharma氏のスピーチの後半では、Foundryが提供する具体的な開発体験、特にマルチエージェントアプリケーションの構築と、エッジAIの重要性が強調されました。Amanda氏とElijah氏によるライブデモは、これらの概念がどのように現実のアプリケーションに落とし込まれるかを具体的に示しました。

4.1. Foundry Agent Service SDKによるエージェント構築の容易さ

Foundryは、開発者がエージェントを効率的かつ安全に構築できるようにするため、「Azure AI Foundry Agent Service SDK」とVisual Studio Code (VS Code) 拡張機能を提供しています。

4.1.1. VS Code拡張機能での管理と「スレッド」の透明性

VS Code拡張機能をインストールすると、開発者は自身のプロジェクトに関連付けられたすべてのモデル、エージェント、そして「スレッド」を一覧で確認できます。

特に「スレッド」は、エージェントの透明性にとって不可欠な要素です。エージェントが各ステップで何を行っているのかを視覚的に追跡できるため、開発者はエージェントの意思決定プロセスやツールの呼び出し、生成されたプロンプトやトークン使用量などを詳細に理解できます。デモでは、Amandaが作成した「Elijahにパーソナライズされたメールを送る」というタスクのスレッドが示され、エージェントが連絡先リストから情報を受け取り、ツールを呼び出してメールをドラフトする一連のプロセスが明確に可視化されました。この透明性は、エージェントのデバッグ、改善、そして信頼性確保において極めて重要です。

4.1.2. 多様なツールの統合とエージェント間の接続性

Azure AI Foundry Agent Service SDKを使用すると、開発者はPythonコードを使って簡単にエージェントを初期化し、一連のツールを割り当てることができます。デモで紹介されたエージェントは、以下のツールを使用していました。

Bing grounding tool: ウェブ検索を通じて、エージェントに最新の情報や外部知識を提供します。
File search tool: プロジェクト内のファイルやドキュメントから情報を検索し、エージェントに提供します。
Open API tool: 外部のRESTful APIと連携し、エージェントが外部サービスを利用できるようにします。

Foundryの強力な点は、これらの基本的なツールに加えて、さらに多様な統合が可能であることです。開発者は、MCP（Multi-Party Computation）サーバーのようなセキュアな計算環境、任意の外部API、そしてFoundry Connect Agentツールを使用して「他のFoundryエージェント」とも接続できます。これにより、エージェントは単独で機能するだけでなく、より大きなシステムの一部として連携し、複雑なタスクを分担して実行できるようになります。

4.1.3. 多様なエージェントフレームワークへの対応

Foundryは、特定のフレームワークに限定されません。デモでは、Foundryエージェントの実行が示されましたが、Elijah氏は、LangChainエージェント、Crew AIエージェント、さらにはAsha氏が言及したADA（Agent-to-Agent）プロトコルを使用する複数のエージェントなど、幅広いエージェントフレームワークに対応していることを強調しました。

この柔軟性により、開発者は既存のエージェント資産を活用したり、自身の好みやプロジェクトの要件に最も適したフレームワークを選択したりすることができます。Foundryは、AIエージェント開発のエコシステム全体を包括的にサポートする、真にオープンで汎用的なプラットフォームとして機能します。

4.2. Build Eventsデモ：複雑なイベント企画を自動化するマルチエージェントシステム

Amanda氏とElijah氏は、「Build Events」というマルチエージェントイベントプランナーアプリケーションのライブデモを通じて、Foundry Agent Factoryの威力を示しました。このアプリケーションは、音声制御のエージェント的オーケストレーターによって駆動され、タスクを動的にサブエージェントに委譲することで、複雑なイベント企画を自動化します。

デモでは、AI Engineering World Fairでの投資家ミーティングの計画と準備というシナリオが提示されました。

4.2.1. 音声制御オーケストレーターとリサーチエージェント

まず、ユーザーはイベントプランナーに音声で指示を出します。「AI Engineering World Fairに参加している、プレシリーズAのAIネイティブSaaSスタートアップを支援するトップのエンジェル投資家を見つけてほしい。」

オーケストレーターはこの複雑な要求を受け取り、それを処理するために「リサーチエージェント」を起動します。リサーチエージェントは、イベントの登壇者リスト、オンラインで参加を表明している出席者リスト、そしてBing grounding toolを通じてウェブ検索機能にアクセスします。これにより、広範な情報源から、条件に合致する投資家の情報を収集します。この間、オーケストレーターはユーザーに「情報を収集しています。他に何か知りたいことや計画したいことはありますか？」と状況を伝え、並行して他のタスクを進められるよう促します。

4.2.2. パーソナライズドメールエージェントの起動

投資家の情報収集と並行して、ユーザーは次に「Asha Sharmaに、イベントで会いたい旨のパーソナライズされたメールを送ってほしい」と指示します。

オーケストレーターは、このタスクを「パーソナライズドメールエージェント」に委譲します。メールエージェントは、ユーザーの要求（AIネイティブSaaSスタートアップにおける機会や潜在的コラボレーションへの焦点）に基づき、Asha Sharma氏宛のメールの下書きを瞬時に作成します。ここでも、オーケストレーターはユーザーに状況を伝え、メール内容の確認や他のタスクの指示を促します。メールの下書きが完了すると、ユーザーは内容を確認し、送信を指示できます。

4.2.3. 画像生成・編集エージェントとコンテンツドラフトエージェントの同時並行処理

次に、ユーザーはさらに創造的なタスクを要求します。「Elijahと私のライブ写真を撮って、AIエージェントのようなカートゥーン風に編集してほしい。Azure OpenAIとPixarが出会ったような感じで。」そして、同時に「サンフランシスコにいることを告知し、ワールドフェアでAIエージェントについて話したい人と会うことに前向きだというLinkedInの投稿コンテンツをドラフトしてほしい」と指示します。

この時点で、Build Eventsアプリケーションのマルチエージェントシステムがその真価を発揮します。オーケストレーターは、この2つの異なる要求を認識し、それぞれを独立したサブエージェントに「同時に」委譲します。

画像生成・編集エージェント: ユーザーがカメラアイコンをクリックしてライブ写真を撮ると、このエージェントが起動します。Azure OpenAIの画像生成・編集能力を活用し、撮影された写真からユーザーをAIエージェントのようなカートゥーンスタイルに変換します。
コンテンツドラフトエージェント: 同時に、このエージェントはLinkedIn投稿用のコンテンツをドラフトします。サンフランシスコでのイベント参加、AIエージェントに関する議論への意欲といった、ユーザーの指示に基づいた説得力のあるメッセージを作成します。

これらのエージェントは同時並行で動作し、それぞれのタスクを効率的に処理します。これにより、ユーザーは複数の複雑なタスクを待つことなく、流れるような体験を得られます。

4.2.4. ソーシャルメディア投稿エージェントと継続的な評価

画像とコンテンツの準備が整うと、ユーザーは「この画像とドラフトの両方をLinkedInに投稿してほしい」と指示します。

このタスクは「ソーシャルメディア投稿エージェント」に委譲され、編集された画像とドラフトされたテキストが組み合わされて、LinkedInに自動的に投稿されます。デモでは、数秒後には実際にLinkedInへの投稿が完了したことが示されました。

この一連のデモを通じて、Foundry Agent Factoryが以下のような重要な能力を持っていることが示されました。

音声制御インターフェース: 自然言語での複雑な指示を理解し、エージェントシステムを操作できます。
動的なタスク委譲: オーケストレーターがユーザーの要求を分析し、適切なサブエージェントにタスクを動的に割り当てます。
マルチエージェント協調: 複数のエージェントが同時並行で動作し、複雑なタスクを効率的に処理します。
豊富なツール連携: ウェブ検索、メール作成、画像処理、ソーシャルメディア投稿といった多様な外部ツールやサービスとシームレスに連携します。

そして、Elijah氏は、Asha氏が以前強調した「評価」の重要性にも触れました。Azure OpenAI Agent Serviceは、エージェントが常に高品質な結果を出すことを保証するため、評価SDKをCI/CD（継続的インテグレーション/継続的デリバリー）パイプラインに統合しています。これにより、エージェントがアップデートされるたびに自動的に評価が行われ、品質が維持・向上されます。

「Build Events」のデモは、Foundryが、いかに複雑なビジネスプロセスを自律的かつインテリジェントに自動化し、ユーザーにシームレスで強力な体験を提供できるかを鮮やかに実証しました。これは、エージェント駆動型アプリケーションが、私たちの仕事のやり方や生活をどのように変革していくかを示す強力な未来図です。

4.3. エッジAIの重要性：クラウドからデバイスへ、AIの遍在化

Asha Sharma氏が最後に強調したのは、モデルがもはやクラウドだけに存在するわけではないという点、そして「エッジAI（Local AI）」の重要性です。過去10年間、データがクラウドに集約される中で、AIの進化はクラウド中心に進んできました。しかし、今やデータは「どこにでもある」状態であり、この遍在するデータに対応するためには、AIもまた遍在する必要があります。

これは単なる個人の趣味のプロジェクトではありません。大規模なスケールで、現実世界のアプリケーションがエッジAIを必要としています。Asha氏はいくつかの具体的なユースケースを挙げ、エッジAIの不可欠性を示しました。

4.3.1. 工場におけるリアルタイムセンサーデータ分析

ある瓶詰め工場では、毎秒10万ものセンサーデータを処理するエージェントが稼働しています。このエージェントは、生産ライン上の微細な異常やリスクをリアルタイムで検出し、即座にフラグを立ててオペレーターに通知します。そして、そのサマリー情報はクラウドに送信されます。

このシナリオでは、エッジAIの「リアルタイム性」が極めて重要です。クラウドにデータを送信して処理するのでは、わずかな遅延が生産ラインの停止や品質問題に直結する可能性があります。エージェントが物理的な場所に密接して（エッジで）動作することで、超低レイテンシーでの検知と対応が可能となり、工場の効率性と安全性が飛躍的に向上します。

4.3.2. 病院システムにおける患者データのプライバシーと要約

ある病院システムでは、患者の長期的な医療データ（longitudinal data）を要約するエージェントを構築しています。医療データは極めて機密性が高く、HIPAAなどの厳格なコンプライアンスおよびプライバシー規制により、ほとんどの場合、クラウドに保存することはできません。データは病院のローカルシステム内にとどまる必要があります。

しかし、エッジAIは、この課題を解決します。エージェントはローカル環境で患者データを処理し、必要な情報（例えば、過去の病歴や治療の傾向など）を匿名化・要約します。そして、その要約された情報をクラウドからアクセス可能にすることで、医療従事者が迅速に患者の全体像を把握できるよう支援します。これにより、データのプライバシーとコンプライアンスを維持しつつ、AIの恩恵を医療分野で最大限に活用できるようになります。

4.3.3. 自動車産業における自律走行とインテリジェントな移動体験

自動車業界では、車両に搭載される自律走行モデルの開発が進んでいます。これらのモデルは、トンネル内や山間部のような、ネットワーク接続が不安定または存在しない環境でも、完全に機能し続ける必要があります。また、車両が乗客の旅行をより良く、よりスマートにするためには、リアルタイムでの推論と意思決定が不可欠です。

エッジAIは、これらの要件を満たします。自動車に搭載されたエージェントは、クラウドへの依存なく、車両に搭載されたセンサーデータ（カメラ、レーダー、LIDARなど）をローカルで処理し、自律走行やナビゲーション、エンターテイメントシステムにインテリジェントな機能を提供します。クラウドは、これらのローカルエージェントにソフトウェアアップデートを提供したり、広範な地図データや交通情報を同期したりする役割を担いますが、基本的な動作はエッジで完結します。

クラウドとエッジのシームレスな統合

これらのユースケースが示すように、「ローカル」はもはや、プラットフォームの派生機能やオプションではありません。Foundryは、エッジをプラットフォームの「コア」の一部として位置づけています。

これは、開発者がクラウド環境でエージェントを設計・構築し、それをシームレスにローカルデバイスにデプロイして、その場で動作させ、推論させることを可能にするというビジョンです。クラウドの豊富な計算資源と開発ツールを活用しつつ、エッジのリアルタイム性、プライバシー、そしてオフライン対応の能力を最大限に引き出す。これが、Microsoftが目指すAIの遍在化、つまりAIが私たちの生活のあらゆる側面に深く根ざし、よりスマートで効率的な世界を築くための鍵となります。

セス・ワレズ氏による「ローカル環境でエージェントを動かす」最終デモが控えていますが、その前に、私たちはFoundryとGitHub Copilotが描く未来の全体像を理解することができました。

結論：エージェント駆動型ウェブが拓く未来

Asha Sharma氏がMicrosoftの「AI Engineering World Fair」で示したビジョンは、単なる技術の進化を超え、私たちの仕事、生活、そして社会のあり方を根本から変革する可能性を秘めています。私たちは今、「Agentic Web」という新たな時代、すなわちエージェントが学習し、適応し、協力し合うことで、想像を超えた価値を生み出す世界へと足を踏み入れています。

この変革の核心にあるのは、AI開発のパラダイムシフトです。GitHub Copilotは、単なるコードアシスタントから、開発者の意図を理解し、タスクを自律的に実行し、他の専門エージェントと連携する「ピア（同僚）」へと進化しました。これにより、開発者はルーティンワークから解放され、より戦略的で創造的な「アーキテクチャの意思決定」や「エージェントチームのオーケストレーション」に集中できるようになります。FSYやCopilot Spacesのようなツールは、コードベースの継続的な改善とプロジェクト理解の加速を支え、開発者の生産性を新たなレベルへと引き上げます。

そして、このエージェント駆動型アプリケーションの基盤となるのが、Microsoft Foundryです。Foundryは、単なるAIプラットフォームではなく、ライブ環境で学習し、進化し続けるエージェントを構築・運用するための包括的なインフラストラクチャを提供します。「シグナルループ」を通じてモデルが継続的にパーソナライズされ、Agentic RAGによって知識活用が深化し、10,000以上の多様なモデルへのアクセスとインテリジェントルーティングが可能になります。さらに、Foundryは、Gigapathのような画期的なオープンモデルの提供や、A2A・MCPといったオープンプロトコルへの投資を通じて、オープンなAIエコシステムの発展を強力に推進しています。

「Build Events」のマルチエージェントデモは、音声制御のオーケストレーターが複数のサブエージェント（リサーチ、メール作成、画像生成、コンテンツドラフト、ソーシャルメディア投稿）にタスクを動的に委譲し、複雑なイベント企画をシームレスに自動化する能力を示しました。これは、エージェントが協調することで、これまで人間が行っていた複雑なプロセスを、より効率的かつインテリジェントに処理できる未来の片鱗です。

最後に強調された「エッジAI」の重要性は、AIがクラウドだけでなく、私たちの身の回りにあるあらゆるデバイスへと遍在し、工場、病院、自動車といった多様な産業で、リアルタイム性、プライバシー、オフライン対応といった特有の課題を解決する力を持つことを示しています。クラウドで構築されたエージェントがローカルでシームレスに動作する能力は、AIの可能性を無限に広げます。

Microsoftは、AI開発のこの新たな章において、単にツールを提供するだけでなく、オープン性と信頼性を重視したプラットフォームを通じて、開発者、企業、そして社会全体がAIの「魔法」を最大限に活用し、未来を形作っていけるよう支援しています。

私たちは今、その「魔法」を再び体験する時代の入口に立っています。AIがもたらすこの新たな波に乗り、共に未来のエージェント駆動型ウェブを築き上げましょう。