Mind the Gap — Microsoft Foundry の Agent Observability ワークショップ (Amy Boyd & Nitya Narasimhan)

AI Engineer Europe 2026 (London) ワークショップ / 2026/05/14

Nitya Narasimhan · 17:30 「ペネトレーションテストは、 業者に 『うちに侵入してくれ』 って依頼するようなもの。 一方 evaluations は、 建築監査員が法令違反を探しに来る感じ。 守るために、 まず誰かに本気で壊してもらう必要がある」

AI Engineer Europe 2026 (Queen Elizabeth II Centre、 London、 2026/04/08-10 開催、 2026/05/14 公開) Day 1 ワークショップトラックより。 エイミー・ボイド (Amy Boyd、 Microsoft Foundry AI Advocacy Lead) と ニチャ・ナラシムハン (Nitya Narasimhan、 Senior AI Advocate / Foundry developer 0) による共同登壇 (約 80 分)。 ワークショップレポジトリ: aka.ms/aie-london-2026

Microsoft Foundry Microsoft の cloud agent platform (旧 Azure AI Foundry)。 build / host / observe / safeguard を一貫させた enterprise agent プラットフォーム。 開発・運用・観測・安全を 1 つの control plane で扱う設計。 OpenTelemetry ベースの tracing、 PyRIT による red teaming、 Azure Monitor 統合まで含む。 docs: learn.microsoft.com/azure/foundry/ DevRel チームの 2 人による、 enterprise agent プラットフォームのライブ実演ワークショップ。 ロンドン地下鉄の 「Mind the Gap (隙間にご注意)」 を観測の比喩として展開する。 train (= 実装) と platform (= 要求仕様) の間にギャップがある状態 = ガードレールも告知も両方必要、 という見立て。

エイミー・ボイドは Microsoft の Principal Cloud Advocate / AI Foundry Advocacy Lead。 ニチャ・ナラシムハンは Ph.D 取得 + 25 年以上のソフトウェア研究開発キャリアを持つ Senior AI Advocate、 Foundry の 「developer 0」 (= プロダクトに最初にフィードバックを返す立場) を担う。 Motorola Labs での 10 年研究、 NY Google Developer Groups 創設の経歴を経て Microsoft へ。 「Mind the Gap」 のフレーズは、 ニチャがニューヨークから London に来た時に 「あ、 こっちは Watch the Gap じゃなくて Mind the Gap や」 と気づいた個人的エピソードから生まれた。

1、 Reliability の 3 軸 — (a) Evaluate (品質・安全・適応をベンチマーク)、 (b) Monitor (時間経過の挙動変化を観測)、 (c) Optimize (データから改善ループを回す)。 これを Microsoft Foundry の build / host / observe / manage プレーンに溶け込ませる。 単一の SDK ではなく、 「観測を最初から組み込んだ開発フロー」 として位置づける。

2、 Evaluation は階層的 — intent resolution (ユーザーの意図を正しく解釈したか) → tool call accuracy (適切なツールを呼んだか) → response completeness (応答が要件を満たしたか) → task adherence (時間経過で品質を維持しているか) と 4 段階で評価する。 「LLM の出力 1 つ」 ではなく 「agent の workflow 全体」 の品質を 4 つの観測点で測る思想。 task adherence (時間経過で品質維持してるか) が最もチューニングが必要、 と DevRel チームが実運用から語る。

3、 Tracing は OTel + Azure Monitor — Microsoft 独自計装ではなく OpenTelemetry ベンダー中立のテレメトリ収集標準。 trace / metric / log の 3 シグナル仕様。 CNCF (Cloud Native Computing Foundation) のインキュベートプロジェクト。 Microsoft Foundry は agent の内部 LLM 呼び出し・tool call・stepをすべて OTel スパンとして発行する設計。 公式: opentelemetry.io 標準を採用。 他社で作った agent を Foundry control plane で観測できる相互運用性を確保。 Multi-agent fleet 管理 (A2A プロトコルとの連携) も視野に入る。

着眼点

「人間が evaluator のループに入ると、 開発速度が指数関数的に下がる」 (実演中、 Amy)

ボイドが Foundry の Skill 機能を実演する文脈で出した主張。 Foundry の Skill は、 空のエージェントエンドポイントを与えると、 それ自身が自律的に構築・評価・改善を回すツール。 Codespaces + dev container でゼロセットアップ環境を作り、 1 コマンドで自律ループが回る実演をした。

これは Project Glasswing (Anthropic + Apple + 金融機関等の早期アクセス) の文脈と方向性が同じ — 評価作業自体を AI で回す設計。 RLHF (人間がループに入る評価) vs RLVR (検証可能な報酬で人間レス) の 議論 と同じ問題の運用版と言える。 Microsoft は democratize 路線で、 Anthropic は限定アクセス路線、 という対比が AI Engineer Europe Day 1 で並んで見えた。

「Foundry の Skill は空のエージェントから自律構築する」 (33:00、 Nitya)

ナラシムハンが実演した 「Contoso Travel Agent」 の構築。 通常コースでは SDK で 1 ステップずつエージェントを組み立てるが、 オプションコースとして 「空のエージェントエンドポイントを Foundry に登録して Skill を起動するだけ」 という自律構築モードがある。 ハッカソン参加者が手元の環境で literally 1 コマンドで動くレベルに来ている。

これは Karpathy の agentic coding と並列に置ける、 「coding agent が agent を作る」 レベルの自動化が enterprise 文脈で実装されている事例。 Skill が Foundry のプラットフォーム機能として組み込まれていることが象徴的 — 「コードを書くより、 仕様を渡して agent に作らせる」 が前提の開発フロー。

「PyRIT (OSS) と組んで、 agent への攻撃 simulation を 1 クリックで」 (14:00 前後、 Amy)

Red teaming を製品レベルで標準化する Microsoft の動き。 PyRIT (Python Risk Identification Toolkit) は Microsoft の OSS、 LLM への敵対的プロンプトインジェクション・jailbreak 試行を自動化するフレームワーク。 これを Foundry の build フローに組み込み、 evaluations と並列に 「壊してくれる業者を呼ぶ」 体験として提供する。

この設計が示唆するのは 「safeguarding は 1 回やって終わりではない、 build フローに織り込む継続的活動」。 evaluations と safeguarding の 「建築監査員 vs 侵入業者」 の比喩 (リード引用) はこの設計に直結している。

「Tracing は OpenTelemetry 標準、 他社で作った agent も Foundry で観測できる」 (13:00 前後)

Microsoft 独自の計装ではなく OTel ベースという選択。 これにより:

  • 他社 SDK (LangChain、 AutoGen、 LlamaIndex、 さらには Pi や Claude Code 等) で作った agent も OTel instrumentation を入れれば Foundry control plane で観測可能
  • 既存の Azure Monitor、 Application Insights など Microsoft cloud の運用基盤と即時連携
  • Multi-agent fleet (= 多数の agent を 1 つの組織で運用する未来) で、 「どの agent も同じ観測標準で見える」 状態を作れる

Templestein の event-sourced agent harness が 「event を共通言語にする」 と主張するのと、 Microsoft が 「OTel スパンを共通言語にする」 と主張するのは、 抽象化レベルは違うが同じ方向性。 どちらも 「agent エコシステムを単一標準で繋ぐ」 を目指している。

動画の構成 (主要セクション)

  • (00:00) ロンドン地下鉄 「Mind the Gap」 メタファーの導入、 3 つの意味 (品質 / 安全 / 適応)
  • (06:00) 非決定性は demo だけの問題ではない、 reliability の 3 軸: evaluate / monitor / optimize
  • (09:00) Microsoft Foundry の構造: cloud agent platform、 build に限らず host / observe / manage
  • (13:00) Tracing は OpenTelemetry ベース、 Azure Monitor 統合、 複数開発環境からの集約
  • (17:00) Red teaming + PyRIT (OSS) との連携、 ニチャの 「業者を呼んで侵入させる感覚」 比喩
  • (22:00) Codespaces + dev container = ゼロセットアップでワークショップ参加
  • (28:00) Contoso travel agent の段階的構築 — instructions / Bing search / app insights を順に追加
  • (33:00) 「Skill」 デモ — 空のエージェントエンドポイントを Foundry が自律的に構築・評価
  • (40:00) Evaluator 一覧 — intent resolution / tool call accuracy / task adherence / response completeness
  • (50:00) Tracing 実演: OTel スパンで agent の内部 LLM 呼び出しを可視化、 cost / token / step を計測
  • (1:05:00) Multi-agent fleet 管理の構想、 A2A プロトコルとの相互運用、 未来のロードマップ

出典

AB

エイミー・ボイド

Amy Boyd

Microsoft Foundry DevRel / AI Advocacy Lead

NN

ニチャ・ナラシムハン

Nitya Narasimhan

Microsoft Senior AI Advocate / Microsoft Foundry developer 0

用語集

Microsoft Foundry
Microsoft の cloud agent platform (旧 Azure AI Foundry)。 build / host / observe / safeguard を一貫させた enterprise agent プラットフォーム。 開発・運用・観測・安全を 1 つの control plane で扱う設計。 OpenTelemetry ベースの tracing、 PyRIT による red teaming、 Azure Monitor 統合まで含む。
Reliability の 3 軸 (Evaluate / Monitor / Optimize)
Microsoft DevRel チームが整理した agent 信頼性のフレーム。 Evaluate = ベンチマーク (品質・安全・適応の 3 観点)、 Monitor = 時間経過の挙動変化観測、 Optimize = データからの改善ループ。 単発の評価ではなく継続的サイクルとして設計する思想。
Evaluation の 4 段階 (Intent Resolution → Tool Call → Response → Task Adherence)
Agent workflow を 4 つの観測点で評価する設計。 Intent resolution (意図解釈)、 Tool call accuracy (適切な tool 選択)、 Response completeness (応答の要件充足)、 Task adherence (時間経過での品質維持)。 LLM 1 出力ではなく workflow 全体の品質を測る。
Foundry Skill
Microsoft Foundry の機能。 空のエージェントエンドポイントを登録すると、 それ自身が自律的に構築・評価・改善を回す。 「コードを書くより、 仕様を渡して agent に作らせる」 開発フローを実現。 Codespaces + dev container でゼロセットアップ環境と組み合わせて 1 コマンドで動く。
PyRIT (Python Risk Identification Toolkit)
Microsoft の OSS red teaming フレームワーク。 LLM への敵対的プロンプトインジェクション・jailbreak 試行を自動化する。 Foundry の build フローに組み込み、 evaluations と並列に 「壊してくれる業者を呼ぶ」 体験として提供する。 GitHub: Azure/PyRIT
OpenTelemetry (OTel)
ベンダー中立のテレメトリ収集標準。 trace / metric / log の 3 シグナル仕様。 CNCF インキュベートプロジェクト。 Microsoft Foundry は agent の内部 LLM 呼び出し・tool call・step をすべて OTel スパンとして発行する設計を採る。 他社 SDK で作った agent も OTel instrumentation を入れれば Foundry で観測可能。
Multi-agent fleet
1 つの組織が多数の agent を運用する状態。 Microsoft は単一 multi-agent system を超えた 「組織全体の agent 群を統一観測する」 control plane を将来構想として提示。 A2A (Agent-to-Agent) プロトコルとの相互運用も視野。