Upgrade to Pro — share decks privately, control downloads, hide ads and more …

GlobalAzure@Kansai Microsoft Foundryで構築する AIエージ...

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
Avatar for Taishi Miyata Taishi Miyata
April 21, 2026
28

GlobalAzure@Kansai Microsoft Foundryで構築する AIエージェント開発最前線

Avatar for Taishi Miyata

Taishi Miyata

April 21, 2026

Transcript

  1. Event name or presentation title Global Azure @ Kansai Microsoft

    Foundryで構築する AIエージェント開発最前線 Cloud & AI Apps Cloud Solution Architect Taishi Miyata 2026/04/18
  2. AI エージェントとは 目的達成のために自律的に判断・行動するAIシステム 7/1に新大阪から東京へ出張したい ユーザ エージェント 社内既定DB 交通費検索API 出張申請システム 新幹線

    新大阪-東京 往復 交通費 社内規定 チェック 出張情報 日帰り旅費上限 日当額 はい、お願いします 往復料金は約 28,000 円、日当は 3,000 円、合 計 31,000 円 です。社内規定を満たしています。 出張申請システムに提出してもよろしいですか? 出張申請システムに提出しました。承認通知をお待 ちください。 7/1 東京 日帰り 31,000円 出張申請エージェントの例 エージェントは設計が最も難しく、最も重要。エージェントの設計方法について説明します
  3. 1. まずは業務プロセスを洗い出す ユーザ:4/18 大阪から マイクロソフト品川まで システムからの確認 ・日時:4/18 ・出発地:大阪 ・目的地:マイクロソフト品川 ・出張目的:null

    ユーザ:目的はチームミーティング 1 2 3 システムからの確認 4 システムの確認 旅費が規定をみたしているか 5 申請書送信の確認 6 ポイント 「AIエージェント」という手段ありきではなく、業 務プロセスそのものを書き出すことが重要
  4. 2. ワークフローを設計する システムからの確認 ・日時:4/18 ・出発地:大阪 ・目的地:マイクロソフト品川 ・出張目的:null ユーザ:目的はチームミーティング 2 3

    システムからの確認 4 システムの確認 旅費が規定をみたしているか 5 申請書の作成・送信 6 or ユーザ:4/18 大阪から マイクロソフト品川まで 1 AIエージェント AIエージェント 人間 人間 AIエージェント ロジック ロジック AIエージェント 人間 設計の指針 ・自然言語の解釈・動的なツール実行が必要->AIエージェント ・決定論的な動作・確実なフロー遷移が必要->ロジック(コード) ・出力結果の確認や情報の追加・承認が必要 ->人間(Human-in-the-loop,略してHITL) ポイント AIエージェントは便利な反面、挙動が不安定 になるので、必要最小限の利用にとどめる
  5. 3.アーキテクチャに落とし込む Container Apps フロントエンド Next.js/React バックエンド Python/FastAPI Microsoft Foundry Cosmos

    DB for NoSQL Bing Search セッション管理 出張申請DB Foundry Agent Foundry model 出張申請関数 Application Insights 依頼内容確認 エージェント 出張計画 エージェント 旅費規程チェック エージェント 出張申請 エージェント GPT-5.4 Azure ユーザ Foundry SDK MCP Tool Microsoft Agent Framework 状態管理 推論 インターネット検索 Open Telemetry トレース 実行 オーケストレーション 出張申請 登録 Microsoft Agent Frameworkの選定理由 HITL対応のマルチエージェントワークフローをDAG定義・ 状態永続化込みで最小コードで構築できるため。 Microsoft Foundry Agent Serviceの選定理由 プロンプト定義のみでエージェントを構築でき、Bing検索・ Function・MCPツールとスレッド管理をマネージドで提供するため。
  6. クラウド導入フレームワーク AIエージェント導入 [参考]:Microsoft エコシステムを使用した組織全体の AI エージェントのテクノロジ計画 - Cloud Adoption Framework

    | Microsoft Learn クラウド導入フレームワーク AIエージェント 導入->テクノロジ計画 にサービス選定の 基準が記載されています
  7. AIエージェントを使用しないユースケース 価値の高いエージェント活用を見極める第一歩は、エージェントを使わない判断ができること。非決定的な挙動やコストを伴うエー ジェントは不要なケースも多く、適用外を早期に除外することで、真にビジネス価値を生む領域へ集中できる 構造化され予測可能なタスク 静的な知識検索 • 業務フローが予測可能でルールベース、かつ推論を必要とし ない場合は、決定的なコードや非生成系AIモデルを使うべき • 入力と出力が明確で処理経路が固定されている場合、こ

    れらの手法の方が高速・低コスト・高信頼 • 固定されたインデックスから質問応答や文章生成を行う場 合は、従来型のRAGで十分 • ツール実行や多段階推論が不要なワークフローにエージェント を使うと、不要な複雑性を持ち込むことになる GitHub Microsoft Fabric Foundry Tools Machine Learning コード データサイエンス 事前構築AIモデル カスタムAIモデル Microsoft Foundry 従来型RAGアプリ
  8. AIエージェント導入時の第一判断 AIエージェントの導入では、まず「既存のSaaSエージェントで要件を満たせるか」を確認する Microsoft 365 Copilot 内のエージェント 各製品に組み込まれたSaaSエージェント GitHub Copilot Agent

    Microsoft Fabric Data Agent App Builder Skills Researcher Analyst Azure Copilot Agent Dynamics 365 Agent Security Copilot Agent Workflows 参考:App Builder エージェント、 ワークフロー エージェント、 およびリサーチツー ル を使用すると、Microsoft 365 データからタスクの自動化と情報合成を行う ことができます。 エージェント サクセス キットを使用して、デプロイ アプローチとガ バナンス モデルを構築します。 参考:GitHub Copilot エージェントでは 、コーディング タスクがサポートされていま す。 Microsoft Fabric データ エージェント を使用すると、Fabric のデータからデータ分 析を行うことができます。 Azure Copilot エージェント は、Azure 環境に関する分析 情報と推奨事項を提供します。 Dynamics 365 エージェントは 、カスタマー サービス ワークフローに役立ちます。 セキュリティCopilotエージェントは 、脅威の検出と対応を 強化します。 業務アプリ作成 業務プロセス自動化 情報調査・要約 データ分析 外部連携 コーディング支援 データ基盤分析 コーディング支援 業務プロセス支援 セキュリティ分析
  9. Microsoftがもつエージェントシステムを構築するさまざまな方法 Microsoft Foundry Agent Service Copilot Studio Instant agent runtime

    GPUs & Containers Bring your own frameworks Code handling every detail Code with managed services Drag and drop UI building コントロール・可視性・カスタマイズ プラットフォーム統合、使いやすさ、開発スピード IaaS PaaS SaaS Infrastructure-as-a-service Platform-as-a-service Software-as-a-service IaaS Infrastructure-as-a-Service PaaS Platform-as-a-Service SaaS Software-as-a-Service 細やかな制御が必要なオーケストレーターの実装 はMicrosoft Agent Frameworkを利用 管理やガバナンスが必要なエージェントの構築は Microsoft Foundryを利用
  10. Control Plane セキュリティ・コンプライアンス・ガバナンス GitHub Visual Studio Visual Studio Code Copilot

    Studio 1,400以上の事前構築済みコネクタと MCP ツールにより、文脈理解とアクション実行が可能なエージェントを構築 ネイティブ IDE 連携による開発体験の最適化 Microsoft セキュリティと統合されたシグナル管理レイヤー Microsoft Agent 365 Microsoft Defender Microsoft Purview Microsoft Entra Microsoft Fabric Microsoft OneLake Microsoft Bing Agent Service IQ Tools Machine Learning Models Microsoft Foundry
  11. すべてのモデルです。 あらゆるユースケースで。 プラットフォームは一つ。 モデルロックインを避ける: • 柔軟なモデル選択 • エンタープライズ向けキュレーション • モデルを素早く探索・比較・交換

    できます Foundry Models Azure OpenAI Model Family DeepSeek Model Family xAI Grok Model Family Mistral: Specific Models Meta Llama: Specific Models Black Forest Labs Model Family Sold directly by Microsoft Cohere: Specific Models* Databricks Model Family Hugging Face Collection NVIDIA Model Family Nixtla Time-Gen1 Model Snowflake Model Family Phi SLM Model Family Stability Model Family Bria 2.3 Fast Model Deci Model Family NTT Data Tsuzumi Model Gretel Navigator Model Core 42 Jais Model SDAIA ALLaM Model Industry models: Claude Model Family Foundry Models における 11,000以上の Frontier モデルとオープンモデル Microsoft Foundry モデルの概要 - Microsoft Foundry | Microsoft Learn
  12. Foundry Agent Service Activity Protocol Agent-first SDK, API, and UI

    A2A M365 / A365 へのワンクリック公開 Agent frameworks Copilot Studio M365/A365 モデル メモリ ツール OpenAI Llama Mistral Grok Flux MCP OpenAPI Managed Memory Managed Conversations BYO-Memory Store Logic Apps Functions 宣言型エージェント (Single prompt agents) ホステッド エージェント (Multi-agent hosting) マルチエージェント ワークフロー (Multi-step, deterministic workflows) セキュリティ、コンプライアンス、ガバナンス BYO リソース、VNet、暗号化、ガードレール、Entra Agent ID、可観測性 Open by Design あらゆるフレームワークやプロトコルで構築可能 Connected Intelligence Everywhere メモリ、ナレッジ、1,400 以上の MCP 対応コネクタに よりエージェントの知能を拡張 Enterprise-Grade Trust and Reach 安心・安全にデプロイ可能Microsoft 365 へのワンク リック公開に対応
  13. 業界をリードするエージェント API の上に構築 エージェント型アプリケーション を構築するためのコア API プ リミティブ Azure のセキュリティおよびコ

    ンプライアンスを備えたエン タープライズグレードの Responses API 業界をリードする API 上に構築 された統合エージェント プラットフォーム OpenAI Responses API Azure OpenAI Responses API Foundry Agent Service OpenAI Models OpenAI Tools Azure OpenAI Models Azure OpenAI Tools エンタープライズ保証 (99.9% SLA) ▪ 他の Foundry モデルおよびツールのサポート ▪ 管理されたメモリ ▪ マルチエージェント ワークフロー ▪ ホステッド エージェント ▪ 組み込みの評価および可観測性 ▪ M365 へのワンクリック公開 Azure OpenAI Models Azure OpenAI Tools テナント内 BYO リソース対応 エンタープライズ保証 (99.9% SLA)
  14. 組織全体の可観測性と管理でAIライフサイクルを管理 Foundry Control Plane エージェントを安全に保 ち、入力・出力・ツール 全体でタスクを適切に 管理 ガードレールと制御 の定義

    エンタープライズのID、 ランタイム防御、機密 データ保護を強化 すべてのエージェントを 保護 クラウド、フレームワーク、 チーム全体のエージェント 群を1つのコントロールプ レーンで可視化・管理 エージェントフリートの 管理 開発者が必要とするすべての機能を1か所で / エージェント群の監視、保護、管理 すべてのエージェントの健 全性、コスト、動作をリ アルタイムで把握 エンドツーエンドの 可観測性
  15. 依頼内容確認エージェントの実装 あなたは出張リクエストから情報を抽出する専門エージェントです。 ユーザーの入力から以下の4項目を抽出し、JSON形式で回答してください。 入力に明示されていない項目は空文字にしてください。 推測で補完しないでください。 【抽出項目】 1. departure: 出発地(都市名・駅名など) 2.

    destination: 目的地(都市名・施設名・エリア名など) 3. schedule: 日程(日付や期間をそのまま抽出) 4. purpose: 出張目的(会議、顧客訪問、研修など) 【出力ルール】 必ず以下の JSON 形式のみで回答してください。説明文やマークダウンの装飾は不要 です。 ```json {"departure": "", "destination": "", "schedule": "", "purpose": ""} ``` プロンプト Foundry Agent ロジック 人間 # ① HITL 呼び出し(ワークフロー中断 → ユーザー入力待ち) @handler(input=ClarificationResult, output=str) async def handle_incomplete(self, result, ctx): await ctx.request_info( request_data=ClarificationHITLRequest( question="出張の目的を教えてください", missing_fields=result.missing_fields, ), response_type=ClarificationHITLResponse, ) # ② ユーザー回答受信(ワークフロー再開) @response_handler async def handle_answer(self, original, response, ctx): updated = f"{original.original_input}¥n{response.answer}" await ctx.send_message(updated, target_id="request_clarifier") ポイント: ctx.request_info() でワークフローが自動的に中断・チェックポイント保存され、ユーザー回答後に @response_handler から再開されます。この中断/再開のメカニズムはAgent Frameworkが自動管理します。 Human-in-the-Loopの実装(Agent Framework) Microsoft Agent Framework ワークフロー - ヒューマンインザループ (HITL) | Microsoft Learn
  16. オーケストレーションのパターン ワークフロー オーケストレーション • LLM が 制御フローを動的に判断し、自身のプロセスやツール利用を 自律的に決定する • タスクをどのように達成するかの主導権は

    エージェント側にある エージェント オーケストレーション • LLM、エージェント、ツールの制御フローをあらかじめ定義したコードパ スによって設計する • タスクの進行方法は 開発者側が明示的に制御する
  17. DAG ワークフローエンジン -複雑なフローを宣言的に定義 • DAG (有向非巡回グラフ) とは • DAG (Directed

    Acyclic Graph) は、 ノード(処理) とエッジ (流れ) で構成さ れるグラフ構造 • 各エージェントを独立したノードとして定 義し、条件分岐やループ (制御付き) をエッジで宣言的に表現できる • メリット • フローを視覚的に把握可能 • ノード追加・削除が容易 • 条件分岐を関数で定義 • ループも自然に表現 Sample.py from agent_framework import WorkflowBuilder, Executor, handler # ① 各ステップを Executor クラスとして定義 class StepA(Executor): @handler(input=str, output=str) async def run(self, data, ctx): result = await process(data) await ctx.send_message(result) class StepB(Executor): @handler(input=str, output=str) async def run(self, data, ctx): await ctx.send_message(data) # ② WorkflowBuilder でノードとエッジを宣言的に定義 step_a = StepA(id="step_a") step_b = StepB(id="step_b") step_c = StepC(id="step_c") builder = WorkflowBuilder(start=step_a) builder.add_edge(step_a, step_b) # A → B(無条件) builder.add_edge(step_b, step_c, condition=is_complete) # B → C(条件付き) builder.add_edge(step_b, step_a, condition=is_not_complete) # B → A(ループ) # ③ ワークフロー実行 workflow = builder.build() events = await workflow.run([Message(role="user", contents=["入力テキスト"])]) Microsoft Agent Framework ワークフロー | Microsoft Learn
  18. 推奨アーキテクチャ Cosmos DB Thread storage Key vault Connections Azure Storage

    File storage Microsoft Foundry Standard setup Bot Service Channels BYO resources AI tool resources Grounding with Bing Search Azure AI Search Logic Apps Azure Functions Models Agents Containers (Azure Container Apps, etc) Built-in AI tools Azure AI Search File search index Microsoft Agent Framework Multi-agent orchestrator MCP servers A2A Servers External APIs OpenAPI specs SharePoint Fabric File search Code interpreter Observability 3P agents
  19. まとめ 1. AIエージェント開発は設計が命。 業務プロセスを洗い出し、必要な部分だけにAIエージェントを 適用することで、挙動が安定しコストも抑えられる 2. まずはSaaSエージェントで実現できないか検討する。 自前で開発する前に、既存のSaaSエー ジェントで十分かを見極めることが重要 3.

    Microsoft Foundryを活用すれば迅速にエージェント開発が可能。 構築したエージェントはコ ントロールプレーンで一括管理・監視でき、運用面でも安心 4. オーケストレーターにはMicrosoft Agent Frameworkがおすすめ。DAGベースのワークフロー定 義、状態管理、HITLの中断/再開が標準で備わっており、複雑な業務フローを少ないコードで 実現できる