(LLM Gen) Global Azure 2025 Room C+D まとめ

·

MKURI

今度はすべて一括で処理できるLLMさんにお願いしてみました。
まったく手は加えていません。

Global Azure 2025 CD セッションまとめ (再改訂版)

オープニング・会場案内

  • 登壇者: 司会者
  • 内容:
    • 会場の電源（床のコンセント）、電波（Wi-Fi: MSFT Guest, イベントアテンコード: globalazure25tokyo）の案内。
    • 無料の飲み物（冷蔵庫内）、ゴミの分別についての案内。
    • Global Azureイベントの概要説明。
      • 世界中のAzureユーザーグループ/コミュニティが同期間に開催。
      • 日本では東京、大阪、北海道で開催。東京会場はJAZUG主催。
      • ハッシュタグ: #GlobalAzure, #jazug
      • 期間: 5月8日～10日、96コミュニティ、100以上のイベント。
    • 各ルームの案内:
      • ルームA: インフラ系
      • ルームCD (当会場): AI系
      • ルームB: GitHub Copilotハンズオン (GitHub Copilot for Azureも)
    • 懇親会の案内（有料2000円、LT大会あり）。

セッション1: Microsoft MVP歴1年目が教えるコミュニティの楽しみ方

  • 登壇者: 長瀬 牧 氏 (ゆーま@ymasaoka)
  • 概要:
    • 自己紹介: AzureカテゴリでMVP受賞（1年目）。
    • 目的: 現地参加者同士がワイワイできるような雰囲気作り、新しい知り合いを作るきっかけ。
    • JAZUG参加経験者へのお願い: 初参加者を引き込む。
    • Microsoft MVP受賞者へのお願い: 新しい人をコミュニティ沼に引き込む。
    • コミュニティ初参加者へのお願い: イベントを楽しみ、周りの人に引きずり込まれる。
    • Microsoft MVPとは: ちょでさんのサイト参照。
    • コミュニティの良さ (個人的感想):
      • 楽しみながら知識が広がる。
      • モチベーション向上。
      • 社外の人と技術の話ができる。
      • 仕事のヒントが見つかる。
      • 強者や最新情報を追う人と話せる。
      • 参加者同士の交流で良さが倍増。
    • MVPの先にあるもの: MVP同士の交流、MVP Summit (シアトル本社でのイベント)。
    • 今日を楽しむために必要なもの3点:
      1. X (Twitter) アカウント: ハッシュタグ #jazug, #GlobalAzure で呟く、いいね・リツイート、登壇者・交流した人をフォロー。
      2. 楽しむぞ、何か得て帰るぞという強い意志: 積極的に交流する。登壇者・運営・MVPは話しかけやすい。
      3. 2000円 (現地参加者向け): 懇親会への参加。
    • 懇親会での交流マインド: 隣にいたからでOK、性別気にせず話しかける。
    • 話しかけるネタ (Copilot提案):
      • 「今日はどのアジュールリソースになりきってきました？私はストレージアカウントです。容量だけは無限なので。」
      • 「僕たちの懇親会で1つのリソースグループになったみたいですね。友情とサーバーレスポンスで繋がってます。」
      • 「今日の懇親会、アジールの雲サービスよりも雲（人）に囲まれてる感じがしません？」
    • それでも難しい場合: まずは名刺交換から。雑談ネタ（今日のセッション、使ってるAzureサービスなど）。
    • コミュニティライフをさらに楽しむ: 登壇してみる（運営に声をかける、ハッシュタグで意思表示）。
  • まとめ: 全員で良いイベントにしていきましょう。

セッション2: 正式リリースされた Semantic Kernel の Agent Framework 全部紹介！

  • 登壇者: 大田 一希 氏 (日本マイクロソフト Cloud Solution Architect & Evangelist)
  • 概要: Microsoft が OSS で開発している Semantic Kernel の Agent 開発のためのフレームワークが先日プレビューから正式リリース。本セッションでは、Semantic Kernel の Agent Framework で正式リリースされた機能の全てを紹介 (言語は C# を対象)。
  • 資料: Twitter (#jazug検索) またはCompassサイトにアップロード済み。
  • 目的: エージェント作成時にSemantic Kernelを選択肢として考えてもらう。
  • 前提: 5月10日情報、サンプルはC#、一部プレビュー機能紹介。
  • Semantic Kernel コア機能:
    • エンタープライズ対応のインテリジェントなAIエージェントとマルチエージェントシステムを構築するフレームワーク。
    • 各種LLMへの共通APIアクセス: OpenAI, Hugging Face, Ollama, Gemini等。モデル差し替えが容易。
    • プロンプト管理機能: テンプレートエンジン（変数埋込、if/for）、YAML形式での外部ファイル保存。
    • プラグイン: 機能拡張。OpenAIのTool (Function Calling) に対応。
    • エンタープライズ向け機能: 可観測性、フィルター。
    • 安定したAPI: プレビューが外れたAPIは破壊的変更が少ない。
    • 対応言語: C#, Python。
    • デモ (コア機能):
      • 基本的なプロンプト実行（テンプレートエンジン使用）。
      • チャット履歴管理 (Chat History)。
      • プラグイン (C#クラス) を利用したツール呼び出しと自動実行 (FunctionChoiceBehavior.Auto)。
      • フィルター機能による処理介入（関数呼び出し前の確認）。
  • Semantic Kernel の位置づけ:
    • フレームワーク: エージェントフレームワーク、プロセスフレームワーク（ワークフロー）。
    • その他機能: 組み込みプラグイン、OpenAPIプラグイン、ベクトル検索抽象化API、テキストチャンク機能、Model-Controller-Prompter (MCP) サポート。
  • エージェントフレームワーク:
    • Semantic Kernelコア機能上に構築。
    • エージェント抽象化: 共通APIで各種エージェントを操作。
    • 実装:
      • Chat Completion Agent (GA)
      • OpenAI Assistant API Agent (Preview)
      • Azure AI Agent Service Agent (Preview)
      • OpenAI Responsible AI Agent (Preview)
      • AWS Bedrock Agent (Preview)
    • マルチエージェント機能 (Preview): エージェントグループチャット、エージェントのプラグイン化。
    • エージェント機能の抽象化: Agentクラス、AgentThreadクラス。共通コードで異なるエージェント実装を呼び出し可能。
    • Chat Completion Agent定義: 名前、インストラクション（システムプロンプト）、カーネル（プラグイン含む）、引数（自動関数呼び出し、温度設定など）を宣言的に定義。
    • デモ (シングルエージェント):
      • ChatCompletionAgent を使用した猫型エージェント（天気情報取得プラグイン、人間割り込みフィルター付き）。
      • Azure AI Agent Service を使用したエージェント（デモ時は一部不具合あり）。
  • マルチエージェント機能:
    • エージェントグループチャット:
      • 複数エージェントを連携させてタスクを処理。
      • セレクションストラテジー（次に話すエージェント決定）。
      • ターミネーションストラテジー（会話終了判定）。
      • チャット履歴の要約、グループチャット自体のエージェント化（入れ子構造）。
      • デモ: ライターエージェントとレビューアーエージェントによる記事作成。
    • エージェントのプラグイン化:
      • エージェントを関数化し、プラグインとしてカーネルに登録。
      • オーケストレーターエージェントがプラグイン化された他のエージェントを呼び出す。
  • マルチエージェント機能の現状とホスティング:
    • GA機能のみでは手組みが必要（複数エージェント呼び出しコード、自作プラグイン）。
    • ホスティング:
      • 短時間処理: App Service, Container Apps, AKS, Azure Functionsなど。
      • リトライ・長時間処理: Azure Container Apps Jobs, AKS, Azure Functions (Durable Functions) (個人的推し)。
      • デモ (Durable Functions): ライターとレビューアーのオーケストレーションをDurable Functionsで実装し、Blazorフロントエンドから操作。
  • まとめ:
    • Semantic Kernelは便利なコア機能（プラグイン、フィルター、モデル非依存）を提供。
    • エージェントフレームワークはコア機能上に構築され、エージェント開発を支援（シングルエージェントGA、マルチエージェントはプレビュー）。
    • AIアプリのホスティングにはAzureの各種サービスが利用可能、Durable Functionsが適している場合も。
    • 是非Semantic Kernelを使ってエージェント開発を。

セッション3: Azure × MCP 入門

  • 登壇者: 百田 涼介 氏 (日本マイクロソフト Cloud Solution Architect)
  • 概要: MCPの概要を理解し、Azureでの活用イメージを掴む。
  • 資料: X (#GlobalAzure ハッシュタグ) またはQRコードからSpeaker Deck参照。
  • MCP (Model-Controller-Prompter / Model Context Protocol) の概要:
    • LLMが外部と簡単に繋がるための共通の接続口。業界のUSB-C。
    • Function Callingとの違い: 処理（関数）をLLMアプリの外部に持つか内部に持つか。
    • 生まれた背景: LLMアプリ増加に伴う個別API実装コスト・運用負荷増大 (m×n問題) を解決し、m+nのオーダーに。
  • MCPアーキテクチャ:
    • ホスト/クライアント: 例: VS Code (ホスト) / GitHub Copilot Agent Mode (クライアント)。
    • サーバー:
      • Tools: LLMが特定アクションを実行するための関数（モデル制御）。VS Code Copilot Agent Modeで現在利用可能。
      • Resources: グラウンディング用データソース（アプリ制御）。
      • Prompts: プロンプトテンプレート提供。
    • トランスポートレイヤー:
      • 標準入出力 (ローカル)。
      • SSE (Server-Sent Events): ステートフル、常時接続。多くの既存MCPサーバーが採用。
      • Streamable HTTP: ステートレス。SSEの課題を克服。VS Code v1.100からサポート。今後は主流になる可能性。
  • MCPサーバー:
    • 有志や企業がソースコードを公開 (例: MCP公式リポジトリ)。
    • デモ: VS Code + Copilot Agent Modeで「time」MCPサーバーを利用。
      • settings.json にMCPサーバー起動コマンドを記述。
      • Copilot Agent Modeでツールを選択/自動実行。
      • #ツール名 で明示的なツール指定も可能。
  • MS / Azure におけるMCP:
    • クライアント: VS Code GitHub Copilot Agent。
    • 公式サーバー:
      • Azure MCP Server: Azureサービスを自然言語で操作。
      • GitHub MCP Server: GitHub操作を自然言語で。
      • Playwright MCP Server: ブラウザ操作を自然言語で（E2Eテスト自動化）。
    • コミュニティ開発サーバー: ADX, Azure DevOps, Teams, OneNoteなど。
    • Azureプラットフォーム上のMCP関連アップデート:
      1. Azure FunctionsでMCPトリガー: type = "mcpTrigger" でMCPサーバー関数を容易に作成 (C#, Python, TypeScript)。
      2. API CenterでMCPタイプ: APIのインベントリ管理にMCPサーバーを追加可能。Copilot Studio用コネクタとしてエクスポートも。
      3. Copilot StudioでMCPサーバー利用: MCPサーバースキーマからカスタムコネクタを作成し、アクションとして利用。
  • MCPサーバー開発とデプロイ:
    • SDK: Official MCP SDK, FastMCP (Python向け推奨), Semantic Kernel, AutoGenなど。
    • デプロイオプション: Azure Functions, App Service, Container Appsなど。公式サンプルリポジトリ多数 (IAC付き)。
  • 認証・認可:
    • MCP公式は第三者認証フロー (Azure文脈ではEntra ID認証/OAuth) を推奨。
    • API Management (APIM) を間に挟むのがデファクトスタンダードになりつつある。
      • APIMがOAuthクライアント/サーバーとして機能。
      • 匿名アクセス防止。
      • 公式サンプルリポジトリあり (APIM + MCP)。
      • APIMのPrivate Endpoint (Public Preview) とVNet統合でセキュアな環境を低コストで実現可能。
    • 発展的なサンプル: APIM資格情報マネージャー連携、Semantic Kernel/AutoGenクライアント実装を含んだリポジトリも。
  • MCPが作る未来 (想像図):
    • 開発者はVS Code、市民開発者はCopilot StudioからAPIM経由で各種MCPサーバー (社内DB/API、外部DB、ワークスペース連携、社内AIアプリ連携) にアクセス。
  • まとめとコールトゥアクション:
    • MCPはLLM外部アクセスの標準接続口を目指す。実装コスト低減がメリット。
    1. 便利そうなMCPサーバーを探して使ってみる。
    2. 身の回りを効率化するMCPサーバーを作ってみる。
    3. Azure Functions等にデプロイしてみる。
    4. APIMで認証認可を付けてみる。

セッション4-1: アジールロードテスティングを使って、アジルファンクションフレックスコンサンプションのパフォーマンスとコストを最適化してみよう

  • 登壇者: 原 氏
  • 内容:
    • Azure Functions Flex Consumptionプランについて。
      • 2023年11月IgniteでGA。今週日本リージョンでも利用可能に。
      • 特徴: スケーリングが非常に速い、VNet統合に対応。
      • サーバーレスでありながら高スケーラビリティと閉域構成を実現。Linux Functionsの今後のデファクトスタンダードになる可能性。
    • パフォーマンスとコスト最適化のポイント:
      1. インスタンスメモリサイズ: 500MB, 2GB (デフォルト), 4GBから選択。
      2. HTTPトリガーのコンカレンシー: 1インスタンスが処理できる並列リクエスト数。
        • デフォルト: 2GBインスタンスで16、4GBインスタンスで32。
      3. 最大インスタンススケール数: 40～1000で設定可能。
      4. Always Ready Instances: コールドスタート削減のため、事前にウォームアップしておくインスタンス数を設定。
      • これらの設定はFunctionsポータルの「スケールとコンカレンシー」メニューで調整可能。
    • Azure Load Testing との連携 (パフォーマンスオプティマイザー):
      • Functionsポータルの「パフォーマンスオプティマイザー」から利用。
      • 裏側でAzure Load Testingが作成され、テストプロファイルを実行・結果確認が可能。
      • 注意点: FunctionsからLoad Testingを呼び出すための権限 (ウェブサイト共同作成者 ロール) が必要。
    • デモ:
      • テストプロファイル設定: 2GB/4GBメモリ × コンカレンシー8/16/32の6パターン。シンプルなHTTPトリガー関数 (1秒スリープ) を使用。10ユーザー3分間の負荷。
      • 結果表示: 各パターンのトータル実行時間、レスポンスタイム、スループット。ベストパフォーマンス（スループット最高値）がマーキングされる。
      • Kustoクエリでの詳細分析: インスタンス数の推移（デモでは1秒未満で10インスタンスにスケール）。
      • コスト観点: OnDemandFunctionExecutionUnits メトリクスでアクティブ時間（課金対象）を確認。スループットだけでなく、コストとのバランスで最適な設定を選択。
  • まとめ:
    • Flex Consumptionは高速スケーリングとVNet対応で非常に強力。日本リージョンでも利用開始。
    • メモリとコンピューティング時間で課金されるため、パフォーマンスとコストのバランスが重要。
    • パフォーマンスオプティマイザーを活用してチューニングを。

セッション4-2: プラットフォームエンジニアリングとAzure Deployment Environmentの活用方法

  • 登壇者: 折田 菜津子 氏 (株式会社APコミュニケーションズ)
  • 概要: 近年、ソフトウェア開発の効率化と標準化を実現するために、プラットフォームエンジニアリングが注目を集めています。Azureでは、その代表的なサービスとしてAzure Deployment Environments (ADE) が提供され、開発チームがスムーズに環境を構築し、管理できるようになっています。このセッションでは、プラットフォームエンジニアリングの基本概念と、それを支えるADEの活用方法について説明します。
  • 目的: プラットフォームエンジニアリングのイメージ、ADEの概要と活用方法を理解する。
  • プラットフォームエンジニアリング:
    • 開発者がセルフサービス型でプラットフォーム構築・運用を行えるよう支援するサービスや専門分野。
    • 内部開発プラットフォーム (IDP): API、クラウドインフラ、CI/CDツール等をプラットフォームチームが提供し、開発プロセスの効率化と開発者負担軽減を目指す。
    • 注目される背景:
      1. システムの複雑化と開発者の認知負荷増大 (コンテナ、マイクロサービス化)。
      2. DevOpsの課題 (開発者がインフラ構築・運用も担うケース)。
      3. DX推進 (迅速なソフトウェア開発の要求)。
    • メリット: 生産性向上、デリバリー迅速化、ガバナンス・セキュリティ強化、運用効率向上、コスト削減、開発者満足度向上、スケーラビリティ・柔軟性向上。
    • DevOps/SREとの相違点:
      • DevOpsより開発者の負担を軽減 (プラットフォームチームが基盤提供)。
      • SREの要素を包含しつつ、開発効率向上やセキュリティ強化を含めた自動化プロセスを目指す。
    • 重要と考えること (個人的見解):
      • 開発者の利便性と制約のバランス。
      • 各エンジニアリングチーム (プラットフォーム、開発、SRE) の役割認識と横の連携。
      • 一人一人が役割を自覚し、利便性と制約のバランスを取る努力 (例: ガードレール策定、プラットフォームテンプレートのライフサイクル実装)。
  • Azure Deployment Environments (ADE):
    • Azureで提供されるプラットフォームエンジニアリングサービス。
    • プラットフォームチームが用意したインフラテンプレートを開発者がセルフサービスで展開。
    • 構成:
      • デベロッパーセンター (最上位スコープ)
      • カタログ (GitHub/Azure Reposのテンプレート同期)
      • 環境の種類 (開発、ステージング、本番など)
      • プロジェクト (開発プロジェクト)
      • 環境 (環境の種類ごとにリソースグループ払い出し)
    • 開発者は開発ポータルまたはAzure Developer CLIから操作。
    • 利用シナリオ: サンドボックス、オンデマンドテスト、トレーニング/ハンズオンラボ、CI/CD統合。
    • 活用方法:
      • サンドボックス/テストラボ:
        • 開発者がカタログから環境をデプロイ。
        • 環境作成者ロール: 環境の種類ごとにRBACロールを定義し、デプロイ時に開発者に割り当て。
      • CI/CD統合:
        • GitプッシュやPR作成をトリガーに、サービスアカウントがデプロイ操作。
        • 環境作成者ロールはサービスアカウントに割り当て。
        • 追加のアクセス: 他のユーザー/グループ (例: 開発者) にロールを割り当て可能。
      • CI/CD統合の具体的な実装例 (Azure Pipelines):
        • 開発ブランチプッシュ → 開発環境デプロイ。
        • mainブランチへのPR作成 → ステージング環境デプロイ。
        • mainブランチマージ → 開発・ステージング環境削除、本番環境デプロイ。
        • スケジュールパイプライン: 未使用環境の定期削除。
        • パイプラインコード (GitHub公開済み)。
  • まとめ:
    • プラットフォームエンジニアリングではチーム連携とバランスが重要。
    • ADEはAzureのプラットフォームエンジニアリングサービス。
    • ADEはサンドボックス、CI/CD統合など多様なシナリオで活用可能。

ショートセッションタイムテーブル (Room C+D)

ショートセッション1: Previewでもここまで追える！Azure AI Foundryで始めるLLMトレース

  • 登壇者: ともどさん (吉川 智也 氏)
  • 内容:
    • LLMトレーシングの必要性: Web検索の事実確認、ファインチューニング用データ収集、処理時間ボトルネック特定。
    • Azure AI Factory (旧 Azure AI Studio) のLLMトレーシング機能:
      • プレビュー機能 (2023 Ignite発表)。
      • SDKがOpenTelemetry形式でスパンを発行し、Application Insightsに自動送信。AI FactoryがLLM用ビュー（タイムライン、コスト、レイテンシ）で可視化。
    • 簡単なトレーシング方法: Azure AI Inference SDK:
      • OpenAI SDKに似た使用感のMS製SDK。
      • トレーシング設定は数行で完了 (azure-monitor-opentelemetry-distro を利用)。
      • AI Factoryの「トレース (プレビュー)」で入力/出力トークン、時間、プロンプト内容等を確認可能。Application Insightsでも確認できるが、LLM特化のビューではない。
    • LangChainからのトレーシング:
      • azure-ai-generative ライブラリ内のAI Factoryトレーシング用モジュールを利用。
      • 設定は数行。AI FactoryでInference SDK使用時と同様のビューで確認可能。
    • Azure外モデルのトレーシング (LangChain利用):
      • MSブログで紹介された方法 (当時はAI FactoryトレースがなくAzure Monitorへの直接トレース)。
      • OpenTelemetry関連設定を詳細に行う。
      • 結果はAI Factoryで確認できるが、ローJSON形式で表示され、見た目は少し劣る。
  • まとめ:
    • AI FactoryでのLLMトレースは数行のコードで簡単に実現可能。
    • Inference SDK以外 (LangChain等) からも可能。
    • Azure外モデルもトレース可能だが、表示の質は若干落ちる。
    • PythonだけでなくC#など他の言語用SDKもある。

ショートセッション2: 統合資格分析ダッシュボードサービスを作ってみた話－AzureとFabricのコラボレーション－

  • 登壇者: takasuka_mさん (高塚 氏)
  • 内容:
    • 開発したサービス: 統合資格分析ダッシュボード (Credly, Acclaim, Microsoft Learn等を横断的に分析)。
      • URL公開 (デモ用にFabricにデータ保存あり)。
      • ユーザーID (例: CredlyのURL末尾) を入力して分析開始。
    • 開発のモチベーション:
      1. 資格管理サービスが複数あり管理しづらい（有効期限、保有資格の把握）。
      2. Credlyのソート機能が限定的になったため、ベンダー別ソートなどがしたい。
      3. 多数の資格保有者の場合、Credlyでの表示・検索に時間がかかる。
      4. 自己の資格取得モチベーション向上。
    • アーキテクチャ:
      • フロントエンド: App Service Containers (Python Flaskなど)。
      • データ連携・分析: Microsoft Fabric。
      • BIツール連携。
    • App Service Containers採用理由:
      • スクレイピング時のChrome Driver、Fabric連携時のODBC Driverなど、カスタムミドルウェアが必要なため。
      • 通常はコードベースのApp Serviceが簡易。
    • スクレイピング処理:
      • Credlyのポップアップ対応、全資格表示のための「View More」ボタンクリックの繰り返し。
      • サーバー負荷軽減のためディレイを挟んでおり、取得に時間がかかる。
      • 取得結果をExcel/CSV出力可能、バッジ管理スプレッドシート風表示。
    • Microsoft Fabricへのデータ書き込み:
      • ODBC経由。必要な接続情報（SQLエンドポイント、DB名、ユーザー、パスワード）。
      • SQLで書き込み処理。
  • まとめ:
    • 複数資格管理サービスを統合分析するダッシュボードを開発。
    • App Service ContainersやFabricの活用事例。
    • 次回以降、得意分野である数理最適化とクラウドの組み合わせについても話したい。

ショートセッション3: AOAI で AI アプリを開発する時にまず考えたいこと

  • 登壇者: まっぴぃさん (井嵐 氏)
  • 内容:
    • AI開発で最初に考えるべきこと: ユースケース・シナリオの明確化:
      • インプット/アウトプットの形式（チャット、音声）、内容（命令、質問、相談）。
      • 出力結果をユーザーがどう受け取るか、ネクストアクションは何か（申請、作業、資料作成）。
      • 回答の提示方法（一括、段階的）。
      • 会話コンテキストの必要性。
    • Gartnerの提言 (2024年1月):
      • 企業はAIエージェント導入時に何をしたいかを明確にし、フレームワークで適切に設定・開発すべき。
      • エンジニアはAIの「リアリティ」（現在の性能）を把握し、目利きの力を持つべき。
    • 「How」に走らない: AIに限らず、従来のアプリ開発と同様に要件定義・要求分析が重要。LLMは何か入力すると結果が出てしまうため、「How」に走りがち。
    • シナリオに応じたアーキテクチャ選択:
      • Chat Completion API: 特定シナリオへの迅速な回答（FAQ検索、質疑応答、文章生成、簡単な会話）。
      • AI Agent: タスク実行、外部API連携、フローチャート型プロセス管理、状況に応じた複雑な会話。
    • その他考慮点:
      • API Management: 本番運用では必須。
      • MCP: クライアント/サーバー分離がメリットだが、単なるプロトコル。無理に採用する必要はない。
      • Azureのサポート機能: プロンプトエンジニアリング支援、コンテンツフィルター、DALL-Eのプロンプト変換など、シナリオ実現を助ける機能が多数存在。
    • 評価の重要性:
      • 「性能が出ない」「どう評価すればいいか分からない」はユースケース・シナリオの検討不足が原因。
      • なぜAIアプリか、利用者は何を期待するか、どう楽をしたいか、インプット/アウトプットの想定を明確に。
      • 評価については過去のJAZUG LT資料参照。
  • まとめ: AIアプリ開発時は、まずユースケース・シナリオをしっかり考えましょう。

ショートセッション4: 内製xLLM アラートの自動トリアージで1人分の工数を浮かせた話

  • 登壇者: a-kitaさん (北 淳 氏)
  • 背景:
    • 銀行のインターネットバンキングシステム開発。
    • 大量のアラート（アプリログ、メトリック、サービスヘルス、セキュリティ）への対応が課題。特にアプリログの定型的な警備アラートが開発時間を圧迫。
    • アラート対応フロー: 検知 → 調査（時間大）→ 対応。
    • チャットソフトへのアラート通知（エラーコード有無でパターン分岐）。手動での調査・対応（青田買い）。
  • 最初の試み: 生成AIチャットボット (RAGアプリ):
    • 質問すると対応方法を回答。エラーコードから情報を引いてくる。
    • 課題: 定着せず。
      • モチベーション: チャット入力が面倒。
      • 調査: プロンプトの打ち方が分からない。
      • 回答結果: 精度が低く、自力の方が早い。
      • 利用者と開発者の間にギャップ。「めんどくささ」の解消が必要。
  • 改善アプローチ:
    • 既存の人間による対応フローを分析。
      • プロンプトはほぼ同質。
      • アラート種別による調査方法はある程度パターン化されていた。
    • 改善方針:
      • 面倒さ解消 → チャット操作自体を不要化。
      • プロンプト → 自動化。
      • 回答結果精度 → 地道なヒアリングで改善。
  • 最終的な姿:
    • チャット入力なしで自動的にアラート内容を分析し、対応方法や関連情報をチャットソフトに投稿。
    • システム構成: スーパーバイザーエージェントがアラート種別に応じて専門エージェント（ログ、メトリック等）に振り分け、推論・データ取得・回答生成。
      • MCPへの移行も検討中。
    • 効果:
      • パターン1 (エラーコードあり): 即座に解決。スタンプ1つで完了。
      • パターン2 (エラーコードなし): DataDog等を自動調査し、結果を添付。
      • 確認時間大幅削減、工数削減 (1人分)、定着率向上。生成AI定着の好循環。
  • まとめと気づき:
    • ユーザーの「面倒」が最大の敵。
    • 調査フローのパターン化が自動化の鍵。
    • 単純な自動化が結果的に生成AI推進に寄与。
    • 最も重要だったこと: 人間の対応フローを見つめ直す過程で、根本的な課題（検知が多すぎる等）も見えてきた。今後はそうした課題解決にも生成AIを活用していきたい。

ショートセッション5: How to Use Azure AI Foundry’s New AI Red Teaming Agent

  • 登壇者: mochan_tk_kawamotoさん (川本 氏)
  • 内容:
    • 情報収集: ビッグテックの動向を追うことで、AIセーフティ、レスポンシブルAIといった重要キーワードに早期に気づける。
    • レスポンシブルAI / AIセーフティの重要性:
      • Microsoftはこの分野に注力。AIにおけるセキュリティ。
      • 複雑なAIシステムは脆弱性が生じやすいため、安全性の担保は必須。
      • テストと同様、AIの安全性評価も当たり前になる。
    • AIレッドチーミング:
      • 攻撃を事前にシミュレーションし、AIシステムに内在するリスクを洗い出す手法。
    • Azure AI StudioのAIレッドチーミングエージェント機能:
      • 元々MicrosoftがOSSとして公開していたPyRIT (Python RIT) をAI Factoryに統合。
      • デモ (Jupyter Notebook):
        • ライブラリとして提供され、比較的簡単に利用可能。
        • リスクカテゴリ（暴力的、セクシャル等）と攻撃戦略（多数用意されている）を指定。
        • 実行結果はAI Factory上で可視化。
        • 攻撃成功/失敗、具体的な攻撃内容（例: モールス信号での攻撃）を確認可能。
      • 対象モデル: AI Factoryのモデルカタログだけでなく、Azure Machine Learningでデプロイしたカスタムモデル (例: Gemma 3) に対しても実行可能。
  • その他:
    • IPAからもレッドチーミングの手法ガイドが公開。
    • OpenAIの発表でもAIの安全性は常に言及。
    • 日本語特有のAIセーフティ課題も存在。
    • 関連機能のブログやYouTube動画も公開中。
  • 告知: 来週のMicrosoft Build現地参加。今期からAIスタートアップにも関与。
Categories:

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です