Azure AI 資格（AI-102）のバックアップ(No.15)

「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

戻る
- Azure AI 資格（AI-900）
- Azure AI 資格（AI-102）

目次 †

目次
概要
詳細
参考

↑

概要 †

コース AI-102T00-A: Azure で AI ソリューションを開発する

↑

生成 AI アプリを開発 †

https://learn.microsoft.com/ja-jp/training/paths/create-custom-copilots-ai-studio/

↑

計画と準備 †

https://learn.microsoft.com/ja-jp/training/modules/prepare-azure-ai-development/

AI 機能
- 生成AI ≒ LLM
- （LLM）エージェント
- 画像処理、音声処理、（NLP）自然言語処理
- 情報抽出（OCRやDocument Intelligence、構造化出力）
- 意思決定支援（BI/AI、データ・アナリシス）
- LLM関連キーワード：LLM、SLM、自然言語処理、マルチモーダル、エージェント、構造化出力

Available Foundry Tools
（事前構築済みの拡張ツール群）
- OpenAI
- Vision、Speech、Language、Translator
- AI Face、AI Custom Vision
- Document Intelligence
- Content Understanding
- Microsoft Foundry Content Safety
- AI Search

Microsoft Foundry プロジェクト
- 鋳造所プロジェクト
  - Microsoft Foundryのモデル、Agent Service
  - Tools、評価と責任ある AI 開発のためのツール
- ハブベースのプロジェクト
  - 鋳造所プロジェクトを含む
  - Prompt Flow、ファインチューニングなど
  - Azure Storage と Azure Key Vaultを含む

開発者ツールと SDK

開発ツールと環境
- Microsoft Foundry for VS Code 拡張機能
- GitHub と GitHub Copilot

プログラミング言語、API、SDK
- Microsoft Foundry SDK（統合的利用）
- Foundry Tools SDK（個別利用）
- Microsoft Foundry Models API
- Microsoft Foundry Agent Service

責任ある人工知能 (AI) の原則
引き続き重要：責任ある人工知能 (AI) の原則

演習
全てポータルで実施
https://microsoftlearning.github.io/mslearn-ai-studio/Instructions/01-Explore-ai-studio.html

Foundry ポータルへサインイン
プロジェクトの作成
- モデル選択とプロジェクト作成
- モデルのデプロイ
- プロジェクトの初期画面のplaygroundでテスト

管理センターでリソースを確認
- 左ナビゲーションから Management center を開く。
- Foundry リソースとプロジェクトの構成を確認。
- リソースグループへで作成された Azure リソースを確認。

プロジェクトのエンドポイントとキーを確認
- Foundry プロジェクト
- デプロイ済みモデル
- Azure OpenAI / Azure AI Services

モデルの動作確認（Chat Playground）
- 左メニューの Playgrounds → Chat を開く。
- デプロイした gpt‑4o が選択されていることを確認。
- Setup ペインでシステムメッセージを設定：
- 例としてプロンプトを入力し、応答を確認。

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

モデルの選択・デプロイ †

https://learn.microsoft.com/ja-jp/training/modules/explore-models-azure-ai-studio/

モデルカタログからモデルを選択する。
- GitHub
- Hugging Face
- Microsoft Foundry（主要なエンタープライズ要件が満たす）

LLM系ユースケース
- 音声：テキスト変換・テキスト読上
- 機械翻訳
- テキスト分類
- エンティティ抽出
- テキストの要約
- 質問の回答
- 理由の解説

モデル選択
ユースケースに最適なモデルを選択

タスクの種類
- モダリティ、ツール
- 地域固有およびドメイン特化のモデル

精度/オープン性
- オープンモデルと独自モデルの間で柔軟性とパフォーマンスのバランスを取る
- 精度・パフォーマンスでモデルをフィルター処理

デプロイ
- 大規模/小規模
- パフォーマンス（必要になるリソース的な意味で）

パフォーマンスのベンチマーキング
- 精度：0/1なので主には分類問題
- 一貫性：人間の言語に近いか？
- 流暢さ：自然に聞こえるか？
- グラウンデッドネス：検証データで入出力のアラインメントを測定
- GPT類似性：検証データで出力のセマンティック類似性を定量化
- 品質インデックス：0-1 の比較集計スコア
- 費用：トークンあたりの価格

スケーリング
プロトタイプをスケーリングする際の考慮事項
- モデルのデプロイ
- モデルの監視と最適化
- プロンプト管理
- モデルライフサイクル

デプロイオプション
Microsoft Foundry を使用して言語モデルをエンドポイントにデプロイする

標準デプロイ: Microsoft Foundry プロジェクトリソースでホスト
サーバーレスコンピューティング: Microsoft Foundry ハブプロジェクトの Microsoft が管理する専用サーバーレスエンドポイントでホスト
マネージドコンピューティング: モデルは、Microsoft Foundry ハブプロジェクトのマネージドVMでホスト

	サポート・モデル	ホスティング	課金基準
標準	Foundry モデル	Foundry リソース	トークン
サーバーレス	Foundry モデル	Hub内のリソース	トークン
マネージド	OSS、カスタム	Hub内のリソース	コンピューティング

プロンプト・エンジニアリングで出力最適化
プロンプト・パターンを適用してモデルの出力を最適化する
- （システムプロンプトで）モデルにペルソナを指示
- （システムプロンプト、ユーザープロンプトで）モデルをガイド
- （システムプロンプト、ユーザープロンプトで）出力形式を指定
- （システムプロンプトで）モデルに理由を求める。
- （ユーザープロンプトで）モデルにコンテキストを追加。

モデル最適化戦略
RAGとファインチューニングがある。

演習
全てポータルで実施
https://microsoftlearning.github.io/mslearn-ai-studio/Instructions/02-Explore-model-catalog.html
- モデル探索（Model Catalogの理解）
- モデル比較（Compare models機能）

Foundryプロジェクト作成
- gpt-4o の Overview から Use this model
- プロジェクト作成（ファウンドリーリソース名、サブスクリプション/リソースグループ/リージョン
- gpt-4o を自動デプロイ、TPM（Tokens Per Minute）制限を設定（50K）

デプロイ・テスト
- gpt-4o
- Phi-4-reasoningを追加でデプロイ（考え方の明示が得意）

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

※ モデルのデプロイの一例はコチラを参考にできる。

↑

Microsoft Foundry SDK †

https://learn.microsoft.com/ja-jp/training/modules/ai-foundry-sdk/

Microsoft Foundry SDK とは
プロジェクト接続を操作する
チャットクライアントを作成

演習
ポータルで準備してPython（WebAPI）でテスト
https://microsoftlearning.github.io/mslearn-ai-studio/Instructions/02a-AI-foundry-sdk.html

Foundry プロジェクトに GPT‑4o をデプロイ

クライアントアプリの準備（Cloud Shell）
- GitHub リポジトリを clone
- Python 仮想環境を作成し、必要なライブラリをインストール
- .env ファイルを編集し、エンドポイント・モデル名を設定
- az login して python chat-app.py する方式。

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

プロンプトフロー †

https://learn.microsoft.com/ja-jp/training/modules/get-started-prompt-flow-ai-studio/

ライフサイクル

初期化
- 目的定義
- サンプルデータセットを収集
- 基本的なプロンプトを作成
- フローを設計

実験
- 実行
- 評価
- 改善
- 進む（↓）

評価と絞込
評価/問題特定/最適化

プロダクションで運用
最適化/デプロイ/監視

評価と絞込
評価/問題特定/最適化

プロンプトフロー

3つの部分
何れもノードの部分でエッジではない。
- 入力
- ノード
- 出力

3つのツール
- LLM ツール
- Python ツール
- プロンプトツール

3つの種類
- 標準フロー
- チャットフロー
- 評価フロー

ランタイムと接続

ランタイム
Python コードや LLM 呼び出しを実行するための計算環境

接続
・種類（Azure OpenAI、OpenAI、Azure AI Search、Serp、Custom）
・探索（権限付与して接続、キーはAzure Key Vault二格納）

バリエーションと監視オプション

バリエーション（連続的）とバリアント（離散的）
- LLM ツールでサポートされ以下の利点がある。
- LLM生成の品質向上：LLMノードのバリエーション（プロンプトと設定）
- 生産性の向上：バリエーションの迅速な作成・管理・適用
- 時間と労力を節約：プロンプトバージョンのバリアント
- 簡単な比較：結果を並べて比較し最も効果的なバリアントを選択

デプロイ後の評価メトリックの監視オプション
- 整合性: 出力が入力または追加コンテキストとどの程度一致しているかを測定
- 関連性: 出力が特定の入力にどの程度関連しているかを評価
- 一貫性: 出力テキストの論理フローと読みやすさを評価
- 流暢性: 出力テキストの文法と言語の精度を評価
- 類似性: 推論値と正解値のコンテキストとセマンティックの一致を定量化

演習
全てポータルで実施
https://microsoftlearning.github.io/mslearn-ai-studio/Instructions/03-Use-prompt-flow-chat.html

Foundry Hub Project の作成（基盤準備）
- Prompt flow 機能は Hub ベースの Project が必須
- リージョンは East US 2 / Sweden Central 推奨（Quota 回避）

リソース認可設定（Blob Storage へのアクセス）
- プロンプトフローはファイル（YAML/フォルダ）として Blob に保存
- 読み取り権限がないと、プロンプトフロー作成・実行時にエラーに

生成 AI モデル（GPT-4o）のデプロイ
- 「デプロイ済みモデル」を参照
- 保護のためTPM（Tokens Per Minute）を設定

プロンプトフロー作成（チャットフロー定義）
- 「入力 → LLM → 出力」という会話フロー
- Inputs：question（今回のユーザ発話）、chat_history（過去の会話）
- Chat LLM tool：Azure OpenAI（gpt-4o）を呼び出す
- Outputs：assistant の回答

プロンプト設計（会話文脈の組み込み）
system メッセージ、chat_history をループで展開し再投入

フローのテスト（Chat UI）
- デプロイ前でも即時対話テスト可能
- プロンプト調整 → 即再実行、という試行錯誤が可能

フロー・デプロイ（API 化）
- 作成したプロンプトフローを外部アプリから呼べる API にする
- Testペインで再テスト、Consumeペインから接続情報、サンプルコード取得実行

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

RAG ベースのソリューション †

https://learn.microsoft.com/ja-jp/training/modules/build-copilot-ai-studio/

RAGとは「LLMのRAG - 開発基盤部会 Wiki」

グラウンディングという単語が使用されるが、コレは、生成を外部の事実に接地させる事。

グラウンディングデータの追加
- Azure Blob Storage
- Azure Data Lake Storage Gen2
- Microsoft OneLake?

検索インデックスにAzure AI Search の以下のを使用して統合
- キーワード検索
- セマンティック検索（ベクトル検索）
- ハイブリッド検索（キーワード＋セマンティック）

インデックスを定義
- WebAPIからRAGを使用
- プロンプトフローからRAGを使用

演習
ポータルで準備してPython（WebAPI）でテスト
https://microsoftlearning.github.io/mslearn-ai-studio/Instructions/04-Use-own-data.html

Foundry ハブとプロジェクトの作成

RAG に必要な 2 種類のモデルをデプロイ
- Embedding モデルと生成モデル
- Global Standard デプロイで、TPM（Tokens Per Minute）を抑えめに設定

独自データ（PDF）をプロジェクトに追加
- 旅行会社の架空パンフレット（PDF）をローカルにダウンロード
- Foundry の Data + Indexes からフォルダごとアップロード
- データセット名を brochures（パンフレット）として登録

Azure AI Search によるベクトルインデックス作成
- 新規 Azure AI Search リソースを作成し接続
- Embedding モデルとして text-embedding-ada-002 を指定
- brochures データを元にベクトル検索対応インデックス：brochures-indexを作成

Playground で RAG の効果を確認
- gpt-4o を使用しデータ未接続で質問 → 一般的な回答
- 次にハイブリッド検索に設定したbrochures-indexを接続
- 同じ質問を再実行 → PDF内容に基づいた回答に変化

クライアントアプリの準備（Cloud Shell）
https://github.com/MicrosoftLearning/mslearn-ai-studio/tree/main/labfiles/rag-app/python
- GitHub リポジトリを clone
- Python 仮想環境を作成し、必要なライブラリをインストール
- .env ファイルを編集し、プレースホルダを置き換え
- python rag-app.py する（API キーを使うのでaz loginは不要）

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

ファインチューニング †

https://learn.microsoft.com/ja-jp/training/modules/finetune-model-copilot-ai-studio/

ファインチューニング（FT）

FTとは「LLMのFT - 開発基盤部会 Wiki」

RAG vs FT
プロンプトエンジニアリングではダメな場合はFT

データ準備

種類
- システムメッセージ
- ユーザーメッセージ
- アシスタントの応答

留意点
- 個人情報や機密情報はすべて削除する。
- 大規模なトレーニングデータセットを作成する。
- データセットに多様なサンプルセットを含める。

基本モデル選択の考慮点
- モデルの機能
- トレーニングデータ
- 制限と偏り
- 言語サポート

FTジョブ構成
- 基本モデルを選択
- トレーニングデータ選択
- 検証データ選択（省略可能）
- 詳細オプションを構成
  - バッチサイズ
  - 学習率
  - エポック数
  - シード（再現性を制御）

演習
全てポータルで実施
https://microsoftlearning.github.io/mslearn-ai-studio/Instructions/05-Finetune-model.html

Foundry プロジェクトに GPT‑4o をデプロイしてChat Playgroundでテスト（指定のRegion）

準備
- 計画：SupervisedでXXXを実施
- 例：応答スタイルを学習させる
- ベースモデルの挙動を理解
- 学習データの理解
  https://raw.githubusercontent.com/MicrosoftLearning/mslearn-ai-studio/refs/heads/main/data/travel-finetune-hotel.jsonl

実施後
- ファインチューニングの実施
- FT後のモデルの評価

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

責任ある生成 AI ソリューションの実装 †

https://learn.microsoft.com/ja-jp/training/modules/responsible-ai-studio/

※ PMP：計画 - リスク - 開発基盤部会 Wiki

NIST AI Risk Management Frameworkの機能に密接に対応したリスク計画
- 生成された出力に存在する「リスクの脅威の損害」を測定
- 損害の発生・影響を最小限に抑え、ユーザーにコミュニケーションを確保。
- デプロイと運用の準備計画を定義して従うことで、ソリューションを責任を持って管理。

潜在的な損害をマップ
- 潜在的な損害を特定
- 特定された損害に優先順位を付ける
- 優先順位付けされた損害をテストして検証
- 検証済みの損害を文書化して共有

テスト
- 推論を繰り返し、出力を分類、潜在的な損害を測定。
- 手動テストと自動テストでシナリオ検証する。

潜在的な損害を軽減

モデルレイヤー
- 適切な（サイズ、事前学習）ポテンシャルのベースモデルを使用し
- 適切にファインチューニング学習しシナリオのスコープに適合したモデル

安全システムレイヤー
- コンテンツフィルター：4 カテゴリ(ヘイト、性的、暴力、自傷行為)、4 重大度レベル (安全、低、中、高) に分類
- 不正使用検出アルゴリズム、迅速な対応を可能にするアラート通知

コンテキスト・レイヤー
- モデルの動作パラメタ
- システム・プロンプト
- RAG

UXレイヤー
- UI
- マニュアル類

リリース・エンジニアリング

プレリリースレビューを完了する
ソリューションをリリースして操作する

Microsoft Foundry Content Safety
- プロンプト・シールド：入力攻撃のリスクをスキャン
- 根拠性検出：出力が入力に固定されているかどうかを検出
- 保護されたマテリアルの検出：既知の著作権で保護されたコンテンツをスキャン
- カスタムカテゴリ：新しいまたは既知のパターンのカスタム・カテゴリを定義

演習
全てポータルで実施
https://microsoftlearning.github.io/mslearn-ai-studio/Instructions/06-Explore-content-filters.html

Foundry プロジェクトにモデルをデプロイしてChat Playgroundでテスト
- 既定のコンテンツ・フィルターの挙動確認（自傷に関する質問/銀行強盗の計画/差別的ジョーク）
- 「完全には防げないケースがある」ことを確認しカスタム・コンテンツ・フィルターの作成

潜在的な損害を軽減
- カスタム・コンテンツ・フィルター：4カテゴリすべて最高ブロックレベルに設定
- Prompt Shield（不正使用検出アルゴリズム）も有効化
- 既定のコンテンツ・フィルターより強力な安全制御が働くことを確認

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

パフォーマンス評価 †

https://learn.microsoft.com/ja-jp/training/modules/evaluate-models-azure-ai-studio/

評価対象
- モデル
- チャット・フロー

ベンチマーク
- カタログ・スペック的な意味での
- 項目：精度 / 一貫性 / 流暢性 / GPT 類似度

評価

手動評価
- モデルをデプロイしてChat Playgroundでテストする。
- 人間により関連性 / 情報の質・量 / エンゲージメントなどを評価する。
- 「モデル、パラメタ」「システムメッセージ、ユーザーメッセージ」を変更する。

自動評価のメトリック

AI支援メトリック
・一般的な品質：ベンチマークの項目と同じ
・リスクと安全性：コンテンツ・フィルターの項目と同じ

自然言語処理メトリック
F1スコア、BLEU、METEOR、ROUGE

演習
全てポータルで実施
https://microsoftlearning.github.io/mslearn-ai-studio/Instructions/07-Evaluate-prompt-flow.html

Foundry ハブのプロジェクトにモデルをデプロイ

手動評価
- JSONLをダウンロード＆アップロード
- Question、ExpectedResponse?にマッピング
- 人間が結果を評価する。

自動評価
- 評価タイプ：Evaluate a model
- JSONLをダウンロード＆アップロード
- 使用する評価指標を追加
- 評価結果確認（Metricsタブ：全体、Dataタブ：レコード毎）

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

AI エージェントを開発 †

https://learn.microsoft.com/ja-jp/training/paths/develop-ai-agents-on-azure/

↑

AzureのAIエージェント開発 †

https://learn.microsoft.com/ja-jp/training/modules/ai-agent-fundamentals/

シナリオ：単一エージェント、マルチ・エージェント
AI エージェントとは：コチラ

経費エージェント
ユーザーの請求可能な経費に関する質問を受けRAGりつつLLMに送信し経費請求を生成

経費ポリシー情報を含むナレッジストアをRAGる。
プログラム関数を実行して経費明細書を自動的に送信する。
ビジネスルールと請求金額に基づいて適切な承認者を知らせる。

旅行代理店マルチエージェント
ユーザーの旅行詳細からフライトとホテルを予約し、経費エージェントで出張費の経費請求

外部の旅行サービスAPIを通じてフライトやホテルを予約
適切な領収書を使用して、経費エージェントを通じて経費請求を開始
手動による介入なしで、旅行予約と経費申請のワークフロー全体を完了

リスクと保護
- データとプライバシーの漏洩：機密データが外部に公開されるのを防ぐための適切な制御が不足
- プロンプト・インジェクションとマニピュレーション攻撃：悪意のあるユーザーの意図した動作を超過させる入力
- 未承認のアクセスと特権のエスカレーション：アクセス制御が弱く意図したスコープを超えてアクションを実行
- データ・ポイズニング：学習またはRAGのデータをハッキングし安全でない出力させた。
- サプライ・チェーンの脆弱性：外部ツールの脆弱性がワークフローに影響を与えた。
- 自律的なアクションへの過度の依存：検証や監視なしで不適切なアクションを実行。
- 監査性とログ記録が不十分：データ・アクセスしたか、何時、誰がアクセスしたかを把握できない。
- モデル反転と出力漏れ：モデルの出力から学習データの内容を逆算し復元、モデルが本来出力すべきでない情報を出力

セキュリティ保護のベストプラクティス
- アクセスを厳密に制御する：RBAC と最小限の特権のアクセス許可
- すべての入力を検証する：インジェクション攻撃をキャッチしてブロックするフィルターとバリデーションのレイヤーを追加
- 人間の監視を追加：機密性の高い操作を人間が関与する承認でセーフガード
- すべてを追跡する：包括的なログ記録と追跡可能性を維持
- サプライ・チェーンを監視：サードパーティの依存関係と統合を定期的に監査
- モデルを正常な状態に保つ：モデルを継続的に再トレーニングして検証

エージェント・フレームワーク

LLMエージェント
- OpenAI Agents SDK
- CrewAI
- LangGraph?
- AutoGen?

その他
- M365 Copilot Studio Lite：EUC
- Microsoft Copilot Studio：Power Platform系ローコード
- Microsoft 365 agents SDK：プログラミング初級
- Microsoft Foundry Agent Service：ソリューション開発用SaaS＋SDK
- Microsoft Agent Framework：プログラミング上級

演習
全てポータルで実施
https://microsoftlearning.github.io/mslearn-ai-agents/Instructions/01-agent-fundamentals.html

Foundry プロジェクトにモデルをデプロイ

エージェントを作成

（自然言語文字列で）エージェントの Instructions（役割定義）を設定

あなたは企業経費精算のAIアシスタントです。
経費ポリシーデータに基づいて、経費に関する質問に答えます。
ユーザーが経費請求を希望する場合、メールアドレス、請求内容、請求金額を取得し、請求内容をユーザーがダウンロードできるテキストファイルに書き込みます。

ナレッジとして文書（docx）を追加、ツールとしてコード・インタプリタを追加
経費請求テキストファイルはコード・インタプリタで準備し、ダウンロードできるようにリンクを提供

エージェントの実行
- Playground 上で会話テスト
- [コード]タブのサンプルコードを取得してVS Code Web で実行可能。

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

Microsoft Foundry Agent Service †

https://learn.microsoft.com/ja-jp/training/modules/develop-ai-agent-azure/

ソリューション開発用SaaS＋SDK

SaaS：スケーラビリティ、24・365

ユースケースの例：
自動化、意思決定など
- 個人生産性
- リサーチャー
- デベロッパー
- セールス
- カスタマーサービス

機能
- 自動ツール呼び出し
- 安全に管理されたデータ
- すぐに使用できるツール
- モデルの選択
- エンタープライズレベルのセキュリティ
- カスタマイズ可能なストレージソリューション

リソース

基本セットアップ
Azure AI ハブ、Azure AI プロジェクト、Foundry Tools リソース

標準セットアップ
基本セットアップに加えて、Azure Key Vault、Azure AI Search、Azure Storage。

ツール

ナレッジ
- Bing検索
- ファイル検索（VDB）
- Azure AI Search
- Microsoft Fabric

アクション
- コード・インタプリタ
- カスタム関数
- Azure Functions
- OpenAPI3.0（WebAPI）

セキュリティリスク（既出）
アプリ開発（演習を参照）

演習
ポータルで準備してPython（WebAPI）でテスト
https://microsoftlearning.github.io/mslearn-ai-agents/Instructions/02-build-ai-agent.html

Foundry プロジェクトを作成
Foundry プロジェクトのエンドポイントをメモ
GitHub リポジトリからサンプルアプリを取得
https://github.com/MicrosoftLearning/mslearn-ai-agents/blob/main/Labfiles/02-build-ai-agent/

パッケージをインストールし、.envを構成

agent.py にコードを追加
- インポートの追加：AgentsClient?、CodeInterpreterTool? などを読み込む。
- Foundry プロジェクトへ接続：DefaultAzureCredential? を使って認証。
- コード・インタプリタがアップロード・ファイル（リソース）を参照できるように。

エージェントの作成

・モデル：gpt-4o
・Instructions：データ分析
・Tools：コード・インタプリタとそのリソース

プロンプト

・Instructions：あなたは、アップロードされたファイル内のデータを分析するAIエージェントです。必要に応じてPythonを使用して統計指標を計算します。
・ToolsのResource：以下が書かれたファイル（data.txt）
  Category,Cost
  Accommodation, 674.56
  Transportation, 2301.00
  Meals, 267.89
  Misc., 34.50
・チャットに入力するプロンプト例~
  ・最もコストが高いカテゴリーは何ですか?~
  ・カテゴリ別にコストを示すテキストベースの棒グラフを作成する~
  ・コストの標準偏差はいくらですか?

開始処理
・会話スレッドの作成
・エージェントにプロンプトを送信

終了処理
・実行ステータスで失敗を確認
・エージェントの最後のメッセージを表示
・会話スレッドからメッセージを時系列で表示
・不要になったエージェントとスレッドを削除

Azure にログインしてアプリを実行
```
az login
python agent.py
```

エージェントと対話し、データ分析を実行
コード・インタプリタを使って Python を実行し、統計値やチャートを生成。

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

VSC の Microsoft Foundry 拡張機能 †

https://learn.microsoft.com/ja-jp/training/modules/develop-ai-agents-vs-code/

Visual Studio Code 用の Microsoft Foundry 拡張機能を使用したエージェント開発

機能：以下の統合エクスペリエンスを提供
- エージェントの検出と管理
- エージェントデザイナ（直感的デザイナ→YAML）
- ツールの追加（ツールライブラリ、MCPサーバー）
- 統合テスト - 組込プレイグラウンドでテスト
- デプロイパイプライン - エージェントを直接デプロイ
- コード生成 - エージェントをアプリに統合するサンプルコードを生成

演習
ポータルで準備してVSC/WebAPIでテスト
https://microsoftlearning.github.io/mslearn-ai-agents/Instructions/07-build-agent-in-vs-code.html

VS Code に Foundry 拡張を入れ Azure にログインしてプロジェクトを作成。
Foundry プロジェクトが作成される（Hubではない、エンドポイントのメモは不要）
デザイナでエージェントを作成（名前/モデル/指示）、MCP ツールを追加
エージェントを Foundry にデプロイして Playground で動作確認
エージェントをアプリに統合するサンプルコードを確認（実行はしない）
会話履歴とスレッドを表示

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

カスタム・ツールをエージェントに統合 †

https://learn.microsoft.com/ja-jp/training/modules/build-agent-with-custom-tools/

Microsoft Foundry Agent Service で使用できるカスタムツールオプション
- カスタム関数
- OpenAPI Specツール
- Azure Functions
- Azure Logic Apps

演習
ポータルで準備してPython（WebAPI）でテスト
https://microsoftlearning.github.io/mslearn-ai-agents/Instructions/03-agent-custom-functions.html

Foundry プロジェクトを作成
Foundry プロジェクトのエンドポイントをメモ
GitHub リポジトリからサンプルアプリを取得
https://github.com/MicrosoftLearning/mslearn-ai-agents/tree/main/Labfiles/03-ai-agent-functions

パッケージをインストールし、.envを構成

user_functions.py にカスタム関数を実装
- support ticket を生成してファイル保存する関数
- submit_support_ticket() を追加。
- その関数を user_functions セットに登録。

agent.py にコードを追加（コチラの演習とほぼ同様）
コードの違いは、user_functionsをインポートしてtoolsetに加える点。

Azure にログインしてアプリを実行
```
az login
python agent.py
```

エージェントと対話し、サポート回答をアプリフォルダで受信

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

マルチエージェント・ソリューション †

https://learn.microsoft.com/ja-jp/training/modules/develop-multi-agent-azure-ai-foundry/

接続されているエージェント
- ツール化されたエージェントのようなもの
- 複雑なオーケストレーションなしで、モジュール式のマルチエージェント・システムを簡単に構築できる。

マルチエージェント・ソリューションの設計

主エージェント
処理に最適な接続されたエージェントを決定し実行するオーケストレーターとして機能

ユーザー入力の解釈
適切な接続済みエージェントの選択
関連するコンテキストと手順の転送
結果の集計または要約
接続されたエージェントの責任

接続済みエージェント
単一の責任ドメインに焦点を当て処理を実行するエージェントとして機能

明確なプロンプトに基づいて特定のアクションを完了する
ツール (必要な場合) を使用してタスクを完了する
メインエージェントに結果を返す

演習
ポータルで準備してPython（WebAPI）でテスト
https://microsoftlearning.github.io/mslearn-ai-agents/Instructions/03b-build-multi-agent-solution.html

Foundry プロジェクトを作成
Foundry プロジェクトのエンドポイントをメモ
GitHub リポジトリからサンプルアプリを取得
https://github.com/MicrosoftLearning/mslearn-ai-agents/tree/main/Labfiles/03b-build-multi-agent-solution

パッケージをインストールし、.envを構成

agent_triage.pyにコードを追加
- インポートの追加：AgentsClient?、CodeInterpreterTool? などを読み込む。
- Foundry プロジェクトへ接続：DefaultAzureCredential? を使って認証。

特定の役割を果たす複数のエージェントを作成するコードを追加

・チケットの優先順位を設定するエージェントを作成
・チケットを適切なチームに割り当てるエージェントを作成
・チケットの労力を見積もるエージェントを作成

接続されたエージェントを使用してサポートチケット処理をトリアージするエージェントを作成

・サポート エージェント用に接続されたエージェント ツールを作成（ConnectedAgentTool）
・作成したエージェント ツールを使用するエージェントを定義する

開始処理
・会話スレッドの作成
・エージェントにプロンプトを送信

終了処理
・実行ステータスで失敗を確認
・エージェントの最後のメッセージを表示
・会話スレッドからメッセージを時系列で表示
・不要になったエージェントとスレッドを削除

Azure にログインしてアプリを実行
```
az login
python agent_triage.py
```

エージェントと対話し、サポート回答をアプリフォルダで受信

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

MCP ツールをエージェントに統合 †

https://learn.microsoft.com/ja-jp/training/modules/connect-agent-to-mcp-tools/

MCP（Model Context Protocol）?

利点
- 動的ツール検出：パッケージマネージャ的（スケーラビリティ/モジュール性/保守容易性/柔軟性）
- LLM 間の相互運用性：さまざまな大きな言語モデル (LLM) とシームレスに連携
- 標準化されたセキュリティ：API ごとに個別のキーまたは認証プロトコルを管理する必要がない。

MCPサーバとMCPクライアントを使用してエージェントツールを統合
- MCP サーバ：エージェントが使用できるツールのレジストリとして機能
- MCP クライアント：MCP サーバとエージェント間のブリッジとして機能
  - MCP サーバから使用可能なツールを検出
  - ツールをラップする Python 関数スタブを生成
  - これらの関数をエージェントに登録

ツールを Azure AI エージェントに登録する
- MCP サーバーは、@mcp.toolで修飾されたツール定義をホスト
- MCP クライアントは、サーバーへの MCP クライアント接続を初期化
- MCP クライアントは、session.list_tools()を使用して使用可能なツール定義をフェッチ
- 各ツールはsession.call_toolを呼び出すために非同期関数でラップされFunctionTool? にバンドル

Microsoft Foundry Agent Service を使用して MCP サーバーに接続する場合

リモート MCP サーバーの統合

必要なもの
・リモート MCP サーバーエンドポイント ( https://api.githubcopilot.com/mcp/ など)。
・MCP ツールを使用するように構成された Microsoft Foundry エージェント。

ツール化
・server_label: MCP サーバーの ID
・server_url: MCP サーバーの URL。
・allowed_tools (省略可能): エージェントがアクセスを許可されている特定のツールの一覧。

カスタムヘッダー（コード）
・認証キー (API キー、OAuth トークン)
・MCP サーバーに必要なその他のヘッダー

ツールの呼び出し
- サーバーラベルと url を使用して McpTool? オブジェクトを作成
- update_headersを使用して、サーバーに必要なヘッダーを適用
- set_approval_modeを使用して、承認が必要かどうかを判断（always/never）
- ToolSet? オブジェクトを作成し、McpTool? オブジェクトを追加
- エージェントの実行を作成し、 toolset プロパティを指定
- 承認が必要な MCP サーバを呼び出す際
  ・requires_actionの実行状態が表示（ツール、渡される引数の詳細）
  ・ツールと引数を確認して、承認に関する十分な情報に基づいて決定
  ・承認を true に設定して、call_idを使用して承認をエージェントに送信

演習
ポータルで準備してPython（WebAPI）でテスト
https://microsoftlearning.github.io/mslearn-ai-agents/Instructions/03c-use-agent-tools-with-mcp.html

Foundry プロジェクトを作成
Foundry プロジェクトのエンドポイントをメモ
GitHub リポジトリからサンプルアプリを取得
https://github.com/MicrosoftLearning/mslearn-ai-agents/tree/main/Labfiles/03c-use-agent-tools-with-mcp

パッケージをインストールし、.envを構成

agent_triage.pyにコードを追加
- インポートの追加：AgentsClient?、CodeInterpreterTool? などを読み込む。
- Foundry プロジェクトへ接続：DefaultAzureCredential? を使って認証。

特定の役割を果たす複数のエージェントを作成するコードを追加

・チケットの優先順位を設定するエージェントを作成
・チケットを適切なチームに割り当てるエージェントを作成
・チケットの労力を見積もるエージェントを作成

接続されたエージェントを使用してサポートチケット処理をトリアージするエージェントを作成

・サポート エージェント用に接続されたエージェント ツールを作成（ConnectedAgentTool）
・作成したエージェント ツールを使用するエージェントを定義する

開始処理
・会話スレッドの作成
・エージェントにプロンプトを送信

終了処理
・実行ステータスで失敗を確認
・エージェントの最後のメッセージを表示
・会話スレッドからメッセージを時系列で表示
・不要になったエージェントとスレッドを削除

Azure にログインしてアプリを実行
```
az login
python agent_triage.py
```

エージェントと対話し、サポート回答をアプリフォルダで受信

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

Microsoft Agent Framework (MAF) †

https://learn.microsoft.com/ja-jp/training/modules/develop-ai-agent-with-semantic-kernel/

オープンソース SDKで、-Azure以外に、OpenAI、Anthropicなどにも対応。
Semantic Kernel（ワークフロー）とAutoGen>（エージェント）の長所を統合

ツール開発のベストプラクティス
- 明確な説明: AI が目的を理解するのに役立つ関数とパラメーターの明確で詳細な説明を記述
- 型の注釈: 適切な Python 型ヒントを使用して、予想される入力と出力の種類を指定
- エラー処理: 予期しない入力を適切に処理するための適切なエラー処理をツール関数に実装
- 意味のあるデータを返す: AI が応答で効果的に使用できるデータを関数が返すようにする
- 特定タスクに集中する: 1 つの関数で特定のタスクを処理するように各ツールを設計する

エージェントの種類（概念的なもので、クラスではない）
- Microsoft Foundry Agent
- Chat Agent
- OpenAI Agent
- Anthropic Agent

ワークフローのコアコンポーネント

ノード（実行者/Executor）

エッジ
- 直接エッジ
- 条件付きエッジ
- Switch-Case エッジ
- Fan-Out エッジ
- Fan-In エッジ

イベント（監視とデバッグ）
- WorkflowStartedEvent? ：ワークフローの実行が開始されたとき
- WorkflowOutputEvent?：ワークフローが出力を生成するとき
- WorkflowErrorEvent?：エラーが発生したとき
- ExecutorInvokeEvent?：Executor がタスクの処理を開始したとき
- ExecutorCompleteEvent?：Executor が作業を完了したとき
- RequestInfoEvent?：外部要求が発行されたとき

演習
ポータルで準備してPython（WebAPI）でテスト
https://microsoftlearning.github.io/mslearn-ai-agents/Instructions/04-semantic-kernel.html

Foundry プロジェクトを作成
Foundry プロジェクトのエンドポイントをメモ
GitHub リポジトリからサンプルアプリを取得
https://github.com/MicrosoftLearning/mslearn-ai-agents/tree/main/Labfiles/04-agent-framework/python

パッケージをインストールし、.envを構成

agent-framework.pyにコードを追加
- インポートの追加：AgentsClient?、CodeInterpreterTool? などを読み込む。
- 経費メール送信用のカスタムツール関数（send_email）を定義

エージェントの作成

・モデル：gpt-4o
・Instructions：経費メールを送る
・Tools：send_email ツール
・Azure CLI 認証：AzureCliCredential

エージェントに経費データを渡して応答を取得するコードを追加

Azure にログインしてアプリを実行
```
az login
python agent-framework.py
```

エージェントと対話し（、data.txtの）、経費回答を受信

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

MAF のマルチエージェントソリューション †

https://learn.microsoft.com/ja-jp/training/modules/orchestrate-semantic-kernel-multi-agent-solution/

DevOps マルチエージェントソリューションの例
- モニタエージェント：ログとメトリックを継続的に取り込み、自然言語処理 (NLP) を使用して異常を検出し、問題が発生したときにアラートをトリガー
- 根本原因分析エージェント：機械学習モデルまたは定義済みのルールを使用して、これらの異常を最新のシステム変更と関連付けて、問題の根本原因を特定
- 自動デプロイエージェント：CI/CD パイプラインと対話してデプロイスクリプトを実行し、修正プログラムの実装や問題のある変更のロールバック
- レポートエージェント：異常、根本原因、および解決策を要約した詳細なレポートを生成し、電子メールまたはその他の通信チャネルを介して関係者に通知

重要な理由（可能な操作）
- 各エージェントに個別のスキル、責任、またはパースペクティブを割り当て
- 複数のエージェントからの出力を結合して、意思決定と精度を向上
- 各エージェントの作業が前の作業を基に進められるように、ワークフローのステップを調整
- コンテキストまたはルールに基づいてエージェント間で制御を動的にルーティング

オーケストレーションパターン
- 順次：1 つのエージェントから次のエージェントへの出力を固定順序
- 同時：同じタスクを一度に複数のエージェントにブロードキャストし、結果を個別に収集。
- ハンドオフ：コンテキストまたはルールに基づいてエージェント間で制御を動的に転送
- グループチャット：チャットマネージャーによって管理される複数のエージェント (および人間) 間の会話
- マゼンティック：特別なエージェント間で計画、委任、適応を行うマネージャー主導のアプローチ

統合オーケストレーションワークフロー（デザイナUIらしい）の一般的なフロー
- エージェントを定義し、その機能を記述
- オーケストレーションパターンを選択して作成
- （必要に応じて、マネージャーエージェントを追加）
- （必要に応じて、カスタム入力およびコールバックまたは変換を構成）
- ランタイムを開始して実行を管理
- タスクでオーケストレーションを呼び出し
- 非同期の非ブロッキングの方法で結果を取得

実装の共通項
- AzureOpenAIChatClient? を設定し、AI サービスプロバイダーに接続
- create_agentでエージェントを定義
- Builder クラスでワークフローを定義
  - participants() でエージェントを追加、
  - build() でワークフローを構築する。

順次

ユースケース
- 特定の順序で実行する必要がある複数のステップで構成されるプロセス
- 各ステージで、次ステージが機能するために必要な重要な要素が追加
- ステージを同時に実行できないため、次々に実行する必要があるタスク
- コンテンツの下書き、レビュー、洗練など、段階的な改善が必要な状況

アンチパターン
- 1 つのエージェントでタスク全体を効果的に実行できる。
- ステージは、品質に影響を与えることなく、独立して並列実行可能
- 順次実行では、初期段階で処理の停止や結果の修正方法が無い。
- 作業を順番に受け渡すのではなく、動的に共同作業する必要がある。
- 反復、バックトラッキング、または動的ルーティングが必要

実装
- チャットクライアントを作成
- エージェントを定義
- ワークフローを構築（SequentialBuilder?）
- ワークフローを実行（run_stream）
- ワークフローイベントを処理（WorkflowOutputEvent?）
- 最後の会話を抽出

同時

ユースケース
- ブレーンストーミング
- 異なる推論方法の組み合わせ (アンサンブル推論)
- 投票またはコンセンサス (クォーラム) に基づいて意思決定
- 速度が重要なタスク（並列で実行すると待機時間が短縮）

アンチパターン
- 互いの作業に基づき、特定順序の共有コンテキストに依存
- 結果の競合や矛盾を解決する明確な方法が無い。
- 共有コンテキストを確実に調整できない。
- 厳密な一連の手順または予測可能で反復可能な結果が必要
- モデルの使用クォータなどのリソース制限がある場合
- 結果を組み合わせると複雑になりすぎたり、全体的な品質が低下したりする。

実装
- チャットクライアントを作成
- エージェントを定義
- ワークフローを構築（ConcurrentBuilder?）
- ワークフローを実行（run）
- 結果を処理する（get_outputs）
- 集計された応答を処理

グループチャット

ユースケース
- 創造的なブレーンストーミング
- 議論と合意から利益を得る意思決定
- 学際的な対話が必要な複雑な問題
- 複数の専門家の視点を必要とする
- 作成とレビューを明確に分離

アンチパターン
- 単純なタスク委任または単純な線形パイプラインで十分
- リアルタイムの速度要件でオーバーヘッドが非現実的
- 階層型または確定的なワークフローは、ディスカッションなしで必要です
- チャットマネージャーは、タスク完了タイミングを明確に判断できない
- エージェントが多く会話フローの管理が複雑になりすぎる。

実装
- チャットクライアントを作成
- エージェントを定義
- ワークフローを構築（GroupChatBuilder?）
- ワークフローを実行（run）
- 結果を処理する（get_outputs）
- 集計された応答を処理

カスタマイズ（GroupChatManager?）項目と呼び出し順
・ユーザー入力を要求（should_request_user_input）
・会話を終了するタイミング（should_terminate）
・フィルタリングまたは要約（filter_results）
・次のエージェントの選択方法（select_next_agent）

ハンドオフ

ユースケース
- 専門的な知識やツールが必要だが、エージェントの数や順序を事前に決定できない。
- 専門知識の要件は処理中に動的に発生し、コンテンツ分析に基づいてタスクルーティングがトリガーされる。
- 複数ドメインの問題では、さまざまな専門家が順番に作業する必要がある。
- エージェントが制御をいつ、誰に転送するかを示すルールを定義できる。

アンチパターン
- 関係するエージェントとその順序は事前に固定できる。
- タスクルーティングは単純で静的なルールベース
- 動的なルーティングだと回答の品質が下がる。
- 複数の操作を同時に実行する必要がある。
- 無限ハンドオフループやバウンスの回避が困難。

実装

準備
ワークフロー内でデータを安全かつ型付きで受け渡す。
・AI サービス接続用のチャットクライアントを作成
・Pydantic モデルで構造化 JSON 応答を定義
・ワークフロー間で共有するデータクラスを作成
・エージェントに response_format と JSON 出力命令を設定

特殊Executorの作成
ワークフローの各ステップで必要な処理を分離し流れを明確にする。
・入力ストレージ Executor：分類エージェントへ転送するメッセージを共有状態に保存
・変換 Executor：エージェントの JSON 応答を型付きのルーティング・オブジェクトへ変換
・ハンドラー Executor：ガード条件（条件関数）を使って分類結果ごとに個別の Executor を作成

ルーティングロジックの構築
分類結果に応じて、次に呼び出すエージェントを切り替える条件チェッカーを生成するファクトリ関数を作成
・受信メッセージや分類結果を評価する条件を設計
・Case オブジェクトに条件を設定し、スイッチケース構造を構築
・予期しない分類結果のフォールバックとして必ず default ケースを用意

マゼンティック

ユースケース
- 事前に定義されたソリューションパスを持たない複雑またはオープンエンド
- 有効なソリューションを形成するには、複数の特殊なエージェントからの入力とフィードバックが必要
- システムは、人間のレビューのための文書化されたアプローチ計画を生成する必要がある。
- エージェントには、外部システムやリソースと直接やり取りできるツールがある。
- 動的に構築された実行プランは、タスクを実行する前に価値を追加。

アンチパターン
- ソリューションパスは固定または確定的
- 計画を動的に作成する必要はない。
- より軽量なオーケストレーションパターンに十分にシンプル。
- 高速実行の計画が重視されるため、速度が優先される。
- 解決パスが明確でなくても、頻繁にストールまたはループが発生する可能性。

実装
- 特殊なエージェントを定義
- イベント処理コールバックを設定
- ワークフローを構築（MagenticBuilder?）
- 標準マネージャーを構成（最大ラウンド数、ストール数、リセット数）
- ワークフローを実行（run_stream）
- ワークフローイベントを処理（WorkflowOutputEvent?）
- 最終的な結果を抽出する

演習
ポータルで準備してPython（WebAPI）でテスト
https://microsoftlearning.github.io/mslearn-ai-agents/Instructions/05-agent-orchestration.html

カスタマーサポート自動化
- 問い合わせトリアージ
- VOC（Voice of Customer）分析
- 問い合わせ→対応部署振り分け
- バグ報告や要望の整理

Foundry プロジェクトを作成
Foundry プロジェクトのエンドポイントをメモ
GitHub リポジトリからサンプルアプリを取得
https://github.com/MicrosoftLearning/mslearn-ai-agents/tree/main/Labfiles/05-agent-orchestration

パッケージをインストールし、.envを構成

agents.pyにコードを追加
- インポートの追加：AgentsClient?、CodeInterpreterTool? などを読み込む。

エージェントの作成

・モデル：gpt-4o
・Instructions：Summarizer、Classifier、Actionの役割
・Azure CLI 認証：AzureCliCredential
・SequentialBuilder：エージェントを順序付きで実行
・ChatMessage / WorkflowOutputEvent：入出力管理

現在の顧客フィードバックを初期化

・ダッシュボードは毎日指標のモニタリングに使用しており、全体的には問題なく機能しています。しかし、夜遅くまで作業していると、明るい画面が目に負担をかけます。ダークモードのオプションが追加されれば、より快適な操作性が得られると思います。
・昨日、アカウントにアクセスできなかったため、カスタマーサポートに連絡しました。担当者はほぼ即座に対応し、丁寧かつプロフェッショナルな対応で、数分以内に問題を解決してくれました。正直言って、これまで受けたサポートの中で最高の体験の一つでした。

定義したエージェントを使用して順次オーケストレーションを定義
```
SequentialBuilder().participants([...]).build()
```

オーケストレーションにデータを渡して応答を取得するコードを追加

Azure にログインしてアプリを実行
```
az login
python agents.py
```

オーケストレーションでカスタマーサポート自動化

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

A2A を使用して Azure AI エージェントを検出 †

https://learn.microsoft.com/ja-jp/training/modules/discover-agents-with-a2a/

ツールのMCPのエージェント版がACP → A2A

エージェント間 (A2A) プロトコルの利点
- 強化されたコラボレーション
- 柔軟なモデル選択
- 統合認証

定義するエージェントスキル（特定の機能を記述）の主な要素
- ID ：スキルの一意の識別子
- 名前：スキルを説明するための人が読みやすい名前。
- 説明：スキルの動作の詳細な説明。
- タグ：分類と検出を容易にするキーワード。
- 例：実際のスキルを示すサンプルプロンプトまたはユースケース。
- 入力/出力モード：データ形式またはメディアの種類

公開するエージェントカード（デジタル名刺）の主な要素
- ID 情報: エージェントの名前、説明、およびバージョン。
- エンドポイント URL: エージェントの A2A サービスにアクセスできる場所。
- 機能: ストリーミングやプッシュ通知など、サポートされている A2A 機能。
- 入出力モード: エージェントが処理できるプライマリメディアの種類。
- 認証のサポート: エージェントがアクセスに資格情報を必要とするかどうかを示します。
- スキル: 他のエージェントが呼び出すことができるエージェントのスキルの一覧。

エージェント Executor を実装

AgentExecutor? インターフェイスは、エージェントに送信されたすべての受信要求を処理
- ユーザーまたは他のエージェントによって要求されたタスクを実行
- 応答をストリーム配信するか、個々のメッセージをクライアントに送り返す
- サポートされている場合は、タスクの取り消しを処理

要求処理フロー
- A2Aエージェントにはコアロジックを実装する小さなヘルパクラスがある。
- Executor は要求を受け取り、エージェントのロジックを呼び出す。
- Executor は、結果をイベントとしてラップし、イベントキューに配置。
- ルーティングメカニズムは、イベントを要求元に送り返す。

A2A サーバーをホスト

ホストによってできるようになること
- エージェントカードを介してその機能を公開、検出できるようにする。
- サーバーはエージェント・ロジックと外部の世界との間のブリッジとして機能
- 受信した A2A 要求を受信し、処理のためにエージェント Executor に転送。
- ストリーミング応答やステートフルな対話など、タスクのライフサイクルを管理。

コアコンポーネント

エージェントカード
・エージェントの機能、スキル、入出力モードについて説明
・標準エンドポイント (通常は /.well-known/agent-card.json) で公開

要求ハンドラー
・着信要求をエージェント Executor の適切なメソッドにルーティング
・タスクストアを使用してタスクのライフサイクルを管理。追跡。

サーバーアプリケーション
・HTTP 要求を処理するための Web フレームワーク (Python では Starlette) を使用して構築
・asyncioのASGI サーバー (Uvicorn など) と組み合わせて、NICとポートでリッスンを開始
・エージェントカードと要求ハンドラを公開し、クライアントとエージェントとの対話を可能に。

A2A エージェントサーバーの設定
- エージェントのスキルとエージェントカードを定義
- Executor をタスクストアにリンクする要求ハンドラーを初期化
- エージェントカードと要求ハンドラーを提供して、サーバーアプリを設定
- ASGI サーバーを使用してサーバーを起動し、ネットワーク・アクセス可能に
- 実行によりエージェントは受信要求をリッスンし、定義されたスキルに従って応答

A2A エージェントに接続

クライアントのやること
- エージェントカードの検出
- エージェントに要求を送信
- エージェントの応答を受信

エージェントサーバーに接続
- クライアントは、サーバーのベース URL を認識
- サーバー上の既知のエンドポイントからエージェントカードを取得
- クライアントを初期化し、メッセージを送信できる接続を確立

エージェントに要求を送信
- 非ストリーミング要求：メッセージを送信し、完全な応答を待機
- ストリーミング要求：メッセージを送信し、応答を増分的に受信

エージェントの応答を処理
- ダイレクトメッセージ：テキストや構造化コンテンツなど、エージェントからの即時出力。
- タスクベースの応答：進行中のタスクを表すオブジェクト。状態の確認や結果の取得にフォローアップ呼び出し。

エージェントとの対話
- 各要求は一意に識別。多くの場合、生成された ID を使用。
- ストリーミング応答は非同期であり、最終的な出力の前に部分的な結果が得られる。
- 単純なエージェントはメッセージを直接返す。高度なエージェントでは複数のタスクを同時に管理する。

演習
ポータルで準備してPython（WebAPI）でテスト
https://microsoftlearning.github.io/mslearn-ai-agents/Instructions/06-multi-remote-agents-with-a2a.html

「タイトル生成エージェント」と「アウトライン生成エージェント」をルーティングエージェント経由で連携させる
- タイトルエージェント → ブログタイトルを生成
- アウトラインエージェント → タイトルを受け取り記事構成を生成
- ルーティングエージェント → プロンプトからどのエージェントに処理させるか判断し、結果を統合

Foundry プロジェクトを作成
Foundry プロジェクトのエンドポイントをメモ

GitHub リポジトリからサンプルアプリを取得
https://github.com/MicrosoftLearning/mslearn-ai-agents/tree/main/Labfiles/06-build-remote-agents-with-a2a

python
├── outline_agent/
│   ├── agent.py
│   ├── agent_executor.py
│   └── server.py
├── routing_agent/
│   ├── agent.py
│   └── server.py
├── title_agent/
│   ├── agent.py
│   ├── agent_executor.py
│   └── server.py
├── client.py
└── run_all.py

パッケージをインストールし、.envを構成

タイトル・エージェントを実装

title_agent/agent.py
・インポートの追加：AgentsClient?、CodeInterpreterTool? などを読み込む。
・Foundry プロジェクトへ接続：DefaultAzureCredential? を使って認証。
・スレッド・メッセージを作成、runs.create_and_processで実行し応答を取得

title_agent/server.py
・エージェントスキル・エージェントカードを定義
・Executor を作成し要求ハンドラに設定
・A2A サーバのアプリケーションインスタンスを作成。

ルーティング・エージェントの実装
routing_agent/agent.py にて：
- ユーザーの入力を解析し、どのエージェントに送るか判断
- A2A でリモート・エージェントExecutorへメッセージ送信
- 非同期で send_message を await し、結果を受け取る

エージェント Executor を実装
title_agent/agent_executor.py にて：
- エージェントの生成（await self._get_or_create_agent()）
- タスクのステータスを更新（task_updater.update_status）
- エージェントの会話を実行（run_conversation）
- 応答でタスクを更新（task_updater.update_status）
- タスクを完了としてマーク（task_updater.complete）

Azure にログインしてアプリを実行
```
az login
python run_all.py
```

エージェントと対話し、React プログラミングに関する記事のタイトルとアウトラインを作成

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

自然言語ソリューションを開発 †

https://learn.microsoft.com/ja-jp/training/paths/develop-language-solutions-azure-ai/

↑

テキスト分析 †

https://learn.microsoft.com/ja-jp/training/modules/analyze-text-ai-language/

Azure Language の基本機能
テキストから言語検出、感情分析、抽出（キー・フレーズ、名前付きエンティティ、エンティティリンク）

機能
- 感情分析：0-1の肯定/中立/否定の3値
- キー・フレーズ：名詞に限らない単語。
- エンティティ：人、場所、住所、日時、組織、URI系（カテゴリ＋サブカテゴリに分類）
- エンティティリンク：同音異義語などWikiにリンクするので違いが解る。

演習
ポータルで準備してPython（WebAPI）でテスト
https://microsoftlearning.github.io/mslearn-ai-language/Instructions/Labs/01-analyze-text.html

Azure AI Language リソースの作成
- Azure Portal で Language Service を作成。
- キーとエンドポイントを後で使うために確認しておく。

GitHub リポジトリからサンプルアプリを取得
https://github.com/MicrosoftLearning/mslearn-ai-language/tree/main/Labfiles/01-analyze-text/Python/text-analysis

パッケージをインストールし、.envを構成

text-analysis.pyにコードを追加
- インポートの追加：Text Analytics SDK
- クライアント（TextAnalyticsClient? ）を生成
- 各分析機能の呼び出しを追加（detect_language、analyze_sentiment、extract_key_phrases、recognize_entities、recognize_linked_entities

エンドポイント＆APIキーを使用してアプリを実行
```
python text-analysis.py
```

実行エッカの確認（言語、感情、キーフレーズ、エンティティ、リンク付きエンティテ

クリーンアップ（課金防止）
- Azure Portal で、演習で使用したリソースグループを開く。
- Delete resource group を実行し、すべての関連リソースを削除。

↑

Q&A †

https://learn.microsoft.com/ja-jp/training/modules/create-question-answer-solution-ai-language/

Azure Language の質問に回答する機能（Q＆A サービス）

KBのタイプ
- タイトルとリンク
- 構造化されたテキスト
- 定義済みのチャットパターン

RAGのIndex
Azure AI Search：クエリ（質問、top(-K)、しきい値、メタデータでフィルタ）

精度向上施策
- マルチターン会話の実装（フォローアップ・プロンプトと応答を定義）
- アクティブ・ラーニング（学習し代替質問のKB追加を提案する）
- シノニム定義、

演習
ポータルで準備してPython（WebAPI）でテスト

↑

CLU †

https://learn.microsoft.com/ja-jp/training/modules/build-language-understanding-model/

Azure Language の会話言語理解（CLU）モデルを構築

事前構成済みの機能（前述の①の機能）
概要、固有表現認識、PII検出、キーフレーズ抽出、感情分析、言語検出など

学習済み機能
- トレーニングとデプロイを行う必要がある。
- 会話言語理解 (CLU)、カスタム固有表現認識、カスタムテキスト分類、質問応答

エンティティ定義
- エンティティ定義（発話、意図（インテント）、種類（学習/リスト））
- 発話のパターンを定義して類似した発話の意図を区別できる。
- 1 つのエンティティにつき、最大 5 つの事前構築済みコンポーネントを使用できる。

演習はポータルで準備してPython（WebAPI）でテスト
- Azure Language リソースを作成：モデルをホストするクラウド環境を準備
- Language Studio でプロジェクト作成：NLU モデルの「器」を作る
- 発話・意図の登録：モデルに「意図分類」を学習させる
- モデルをトレーニング & デプロイ：実際に使える形にする
- エンティティ定義：発話から詳細情報（場所・曜日・日付）を抽出
- 再トレーニング & 再デプロイ：エンティティ対応後のモデルを更新

↑

分類 †

https://learn.microsoft.com/ja-jp/training/modules/custom-text-classification/

2 種類のプロジェクト：単一ラベル分類、複数ラベル分類
分類問題のモデルの評価と改善（一般論）
APIペイロード（JSONインターフェイス）
データ（ラベル定義、タグを付け）、モデル（トレーニング、表示、改善、デプロイ最大10）、WebAPIで分類実行
WebAPIが特徴的で、分類テキストをPOSTで送信した後、operation-location応答ヘッダにGETして結果を取得

演習はポータルで準備してPython（WebAPI）でテスト

Azure リソースの準備
- Language Service の作成
- ストレージアカウントの確認（StorageV2）
- RBACの設定

学習データの準備
- サンプル記事のダウンロード
- ストレージ・アカウントへのアップロード
- コンテナ設定（匿名アクセスの一時的許可）

Language Studio プロジェクトの作成
- リソース選択
- プロジェクトタイプ（Single label classification）
- コンテナの接続
- プロジェクト基本情報の設定

データのラベル付け
- クラス（4分類）の作成
- 各記事へのラベル付与
- Training / Testing の割り当て
- ラベルの保存

モデルのトレーニング
- トレーニングジョブの作成
- 手動データ分割の利用
- トレーニング完了の確認

モデルの評価
- モデル性能の確認
- 誤分類の確認
- 改善ポイントの把握

モデルのデプロイ
- デプロイメントの作成
- デプロイ名とモデルの指定
- API利用準備

Cloud Shell でのアプリ開発
- Cloud Shell（PowerShell）の起動
- GitHub リポジトリの取得
- Python 仮想環境の構築
- .env の設定（エンドポイント・キー）
- classify-text.py の編集
- SDK を使った分類コードの追加
- プログラムの実行と結果確認