(LLM Gen) Global Azure 2025 Room C+D (メインセッション1) まとめ

前半の部分を文字起こしデータをそのまままとめていただいたものです。
お名前だけ手修正しました。ツッコミどころはごめんなさい。

Global Azure 2025 Room C+D (メインセッション1)
https://www.youtube.com/live/bCA67k-s2ls

セッションのまとめ

セッション1: 会場案内とGlobal Azureイベントの紹介

• 講演者: Maki Nagase さん
• 内容:
  • 会場設備:
    • 電源: 各席の足元にあり、蓋を開けて利用可能。コンセントの形状に注意。
    • Wi-Fi: SSID「MSFT Guest」、イベントアテンコード「globalazure25tokyo」で利用可能。
    • 飲み物: 会場外の冷蔵庫内のドリンクは無料。
    • ゴミ: 分別して、隣のセッション会場（Bの部屋）との間にあるゴミ箱へ。
  • Global Azure イベント概要:
    • 世界中のAzureユーザーグループやコミュニティが同期間に開催するイベント。
    • 日本では東京（本会場、ジャズUG主催）の他、大阪、北海道でも開催。
    • ハッシュタグ: #GlobalAzure および #jazzug （ジャズUGのイベントの場合）。
    • 開催期間: 5月8日から10日。今年は世界96のコミュニティが100以上のイベントを開催。
  • 当日のセッション構成:
    • ルームA: インフラ寄りの話題。
    • ルームCD（本会場）: AI系の話題。
    • ルームB（隣の部屋）: GitHub Copilotのハンズオン（GitHub Copilot for Azureに関するセッションも最後にあり）。
  • 飲食: 周囲の邪魔にならない範囲で可能。
  • 懇親会:
    • 会費2000円（当日参加も可能）。参加者にはバンドを配布。
    • LT（ライトニングトーク）大会も開催。スライドなしのトークも歓迎。

---

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

• 講演者: 長瀬 マキ さん（Twitter: @chomado、Microsoft MVP アジュールカテゴリ歴1年目）
• 内容:
  • 自己紹介: 昨年MVPを受賞し、昨年のGlobal AzureではMVPではなかったが司会を担当。
  • セッションの目的: 現地参加者同士の交流促進と、新しい知り合いを作るきっかけ作り。オンライン参加者にはX（旧Twitter）での積極的な発信を奨励。
  • JazzUG参加経験者へのお願い: 初参加者への積極的な声かけと交流。
  • Microsoft MVP受賞者へのお願い: 他の参加者をMicrosoftコミュニティへ引き込むような積極的な関与。
  • コミュニティ初参加者へのお願い: イベントを楽しみ、周囲のMVPや先輩参加者に積極的に関わっていくこと。
  • Microsoft MVPについて: 詳細はちょまど氏のサイトを参照。
  • コミュニティの良さ（長瀬氏の個人的感想）:
    • 楽しみながら知識が広がる。
    • モチベーションが上がる。
    • 社外の技術者と話せる。
    • 仕事のヒントが見つかる。
    • 専門分野の猛者と話せる、最新情報の注目ポイントがわかる。
    • 発表を聞くだけでなく、参加者同士の交流でさらに良さが深まる。
  • Microsoft MVPというアワード: MVP同士の交流が楽しく、濃い人が多い。MVPサミット（シアトル本社開催）では世界中のMVPや製品開発者と交流できる貴重な機会がある。
  • 今日を楽しむために必要なもの3点:
    1. X（旧Twitter）アカウント: ハッシュタグ #jazzug #GlobalAzure をつけて積極的に発信し、他の人の投稿にも反応する。登壇者や交流した人をフォローする。
    2. 楽しむぞ、何か得て帰るぞという強い意志: 積極的に交流する。特に登壇者、運営、MVPは話しかけやすい。
    3. 2000円（現地参加者向け）: 懇親会への参加を推奨。
  • 懇親会での交流マインド:
    • 話しかける理由は「隣にいたから」で十分。
    • 相手の性別などを気にせず話しかける。
    • 困りごとは運営へ。
  • 話しかけるネタに困ったら（Copilot提案のネタ）:
    • 「今日はどAzureリソースになりきってきましたか？私はストレージアカウントです。容量だけは無限なので。」
    • 「僕たちの懇親会で1つのリソースグループになったみたいですね。友情とサーバーレスポンスで繋がってます。」
    • 「今日の懇親会、Azureのクラウドサービスよりも雲（群衆）に囲まれてる感じがしませんか？」
  • それでも話しかけにくい場合: まずは長瀬氏と名刺交換から。
  • 雑談ネタ例: 今日のセッション内容、気になった話、登壇者への感想、使っているAzureサービスについて。
  • コミュニティライフをさらに楽しむために: 登壇を推奨。経験は誰かの役に立つ。運営やハッシュタグで登壇希望を表明。
  • 締め: 今日は全員で良いイベントにしましょう。

---

セッション3: 正式リリースされたセマンティックカーネルのエージェントフレームワーク全部紹介

• 講演者: 大田 一希 さん（日本マイクロソフト クラウドソリューションアーキテクト）
• 資料: Twitterで #jazzug 検索、またはコンパスのサイトにアップロード済み。
• 内容:
  • 自己紹介: .NET Framework 1.0からの開発経験。Azure PaaS系、AI系サービス（特にOpenAI周り）が専門。
  • セッションの目的: セマンティックカーネルを使ってエージェントを作ってみようと思ってもらうこと。
  • 前提: 2025年5月10日時点の情報。サンプルはC#。プレビュー機能も含む。
  • セマンティックカーネルのコア機能:
    • エンタープライズ対応のインテリジェントなAIエージェントとマルチエージェントシステムを構築するフレームワーク。
    • 特徴:
      • 各種AIモデル（OpenAI, Hugging Face, Ollama, Gemini等）への共通APIアクセス。
      • プロンプトテンプレートエンジン（変数埋め込み、if/for文、YAML形式での外部ファイル保存）。
      • プラグイン機能（OpenAIのツール/ファンクションコーリングに相当）。
      • フィルター機能（可観測性向上）。
      • APIの安定性（プレビューが外れたものは破壊的変更がほぼない）。
      • 対応言語: C#, Python（Javaはエージェント関連でプレビュー）。
    • デモ1（コア機能）:
      • Nugetパッケージのアップデート実演（1.4.8 → 1.4.9）。
      • シンプルなAI応答（Kernelクラスを使用し、KernelBuilderで設定）。
      • チャット履歴管理（ChatHistoryクラス、IChatCompletionServiceインターフェース）。
      • ツール呼び出し（プラグイン機能）。C#クラスをプラグインとして登録し、AIから呼び出させる（例: 天気情報取得）。FunctionChoiceBehavior.Autoで自動実行。
      • フィルター機能。関数呼び出し前などに割り込み処理を実装（例: ユーザーに関数実行の可否を確認）。IFunctionInvocationFilterを実装。
  • セマンティックカーネルの提供機能（コア機能以外）:
    • エージェントフレームワーク: シングルエージェント、マルチエージェント対応。
    • プロセスフレームワーク: ワークフロー構築。
    • その他: 組み込みプラグイン、OpenAPIプラグイン読み込み、ベクトル検索抽象化API、テキスト検索、Model-as-a-Service (MaaS) プロトコルサポート。
  • エージェントフレームワーク詳解:
    • セマンティックカーネルのコア機能上に構築されたAIエージェント構築フレームワーク。
    • 提供機能:
      • エージェントの抽象化レイヤー（Agentクラス、AgentThreadクラス）。
      • 各種エージェント実装:
        • ChatCompletionAgent (GA): Chat Completion APIを利用。
        • OpenAI Assistant API Agent (プレビュー)。
        • Azure AI Agent Service Agent (プレビュー)。
        • OpenAI REST API Agent (プレビュー)。
        • AWS Bedrock Agent (プレビュー)。
      • マルチエージェント機能 (プレビュー):
        • エージェントグループチャット。
        • エージェントのプラグイン化。
    • エージェントの抽象化API: どのエージェント実装でも共通のコードで呼び出し可能（InvokeAsyncなど）。
    • ChatCompletionAgentの定義: 名前、インストラクション（システムプロンプト）、カーネル（プラグイン含む）、引数（関数呼び出しの自動化、Temperature等）を設定。
    • デモ2（シンプルなエージェント）:
      • コンソールアプリケーションを新規作成。
      • 必要なNugetパッケージ（Microsoft.SemanticKernel, Microsoft.SemanticKernel.Agents.Core）をインストール。
      • ChatCompletionAgentを作成し、天気プラグインと人間割り込みフィルターを組み込み、ターミナルで対話。
    • Azure AI Agent Service連携 (プレビュー):
      • AI Studio (旧 AI Foundry) のクライアントを作成し、エージェントを定義。
      • AzureAIAgentクラスでラップ。
      • デモでは、ローカルプラグイン呼び出し時の文字化けや、Bingコネクターのエラーなど、プレビュー版特有の不安定さが見られた。
  • マルチエージェント機能 (プレビュー):
    • エージェントグループチャット:
      • 複数のエージェントを連携させてタスクを実行。
      • SelectionStrategy: 次に話すエージェントを選択するロジック。
      • TerminationStrategy: 会話を終了するか決定するロジック。
      • チャット履歴のトリミング機能、グループチャット自体のエージェント化（入れ子構造）。
      • デモ3（エージェントグループチャット）:
        • ライターエージェント（Azure AI Agent Service、記事執筆担当）とレビューアーエージェント（Chat Completion Agent、レビュー担当、構造化出力で結果を返す）を作成。
        • AgentGroupChatに両エージェントを追加。
        • SelectionStrategyは順次実行（標準提供クラス）。
        • TerminationStrategyはカスタム実装（レビューアーがOKを出すまで継続）。
        • C#の入門記事を執筆させ、レビューと修正を繰り返す様子を実演。
    • エージェントのプラグイン化:
      • エージェントを関数としてラップし（AgentKernelFunctionFactory.CreateFromAgent）、プラグインとしてカーネルに登録。
      • 別のエージェント（オーケストレーター）が、これらのプラグイン化されたエージェントをファンクションコール経由で呼び出してタスクを実行。
    • 現状のマルチエージェント: プレビュー機能が多いため、本番リリース版の機能だけでオーケストレーションを行うには手組みが必要。
  • エージェントの実行環境:
    • 短時間処理: App Service, Container Apps, AKS, Azure Functionsなど何でも。
    • リトライや長時間実行が必要な場合: Azure Container Apps の Job機能, AKS。
    • 個人的な推し: Azure Functions の Durable Functions。
    • デモ4（Durable Functionsによるマルチエージェント）:
      • ライターとレビューアーのシナリオをDurable Functionsのオーケストレーターで実装。
      • フロントエンド（Blazor）から起動し、進捗確認、結果取得を行う。
      • .NET Aspireで複数プロジェクト（フロントエンド、Azure Functions、Azure Storage Emulator）をまとめて起動・管理。
      • 執筆とレビューのループを画面で確認。
  • まとめ:
    • セマンティックカーネルは、コア機能（フィルター、プラグイン等）の上に、LLM抽象化、エージェント抽象化、そしてエージェント実装（Chat Completion Agent等）やマルチエージェント機能が構築されている。
    • 基本機能は便利で、エージェントフレームワークによりエージェント開発が容易になる（シングルエージェントはGA、マルチエージェントはプレビュー）。
    • AIアプリのホスティングにはAzureの各種サービスが利用可能で、特にDurable Functionsが推奨される。
  • 最後に: セマンティックカーネルを使ったエージェント開発をぜひ試してほしい。
  • 質疑応答:
    • Q: エージェントのプラグインはA2A（Agent-to-Agent communication protocol）になるのか？
    • A: A2Aはプロトコル。セマンティックカーネルのエージェント実装にA2Aエージェントが出てくる可能性はある。現状説明したエージェントのプラグイン化とはレイヤーが異なる話。MaaSのリポジトリにあるセマンティックカーネルのサンプル（Pythonのみ）が参考になるかもしれない。

---

---

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

• 講演者: 百田 涼介 氏（Microsoft クラウドソリューションアーキテクト）
• 資料: Speaker Deckにて公開済み（Global AzureハッシュタグでXに投稿）
• 内容:
  • 自己紹介:
    • Microsoftでクラウドソリューションアーキテクトとして勤務（大田氏と同ロール）。
    • Azure PaaS、AI周りを担当。以前はAzure Monitorのサポートエンジニアも経験。
    • 得意分野: Log Analytics、Application Insights、アラート設定。
    • 好きなこと: DevOps (CI/CD、IaC)、一人居酒屋、筋トレ、個人開発。
    • 好きな言語: Python, TypeScript, Go。C#は勉強中。
  • セッションのゴール:
    • MCP (Model Context Protocol) の概要を理解する。
    • MicrosoftおよびAzureの文脈でのMCPを学ぶ。
    • MCPを理解し、Azure上で展開・社内開発するイメージを掴む。
  • MCP (Model Context Protocol) 概要:
    • LLMが外部と簡単に繋がるための共通の接続口。業界のUSB Type-Cのようなもの。
    • LLMが外部データ（DB、APIなど）へアクセスする際の標準プロトコル。
    • ファンクションコーリングとの違い: アクションや処理の定義をLLMアプリの内部に持つか（ファンクションコーリング）、外部に切り出すか（MCP）。
  • MCPが生まれた背景・メリット:
    • LLMアプリの普及に伴い、外部情報アクセス（RAGなど）の需要が増加。
    • 個別API呼び出しの実装コストと運用負荷の増大（m x n問題: LLMアプリ数 x 接続先数）。
    • MCPにより、接続先への実装はMCPサーバーに吸収され、LLMアプリからの呼び出しは画一化される（m + nのオーダーに）。
  • MCPアーキテクチャ:
    • ホスト/クライアント:
      • ホスト例: VS Code
      • クライアント例: GitHub Copilot エージェントモード
    • サーバー: 主に3つの機能を提供。
      • Tools (モデル制御): LLMが特定のアクションを実行するための関数群（例: 天気API呼び出し）。VS CodeのCopilotエージェントモードでは現在これが主に利用可能。
      • Resources (アプリ制御): LLMがアクセスできるデータソース（グラウンディング用）。REST APIエンドポイントなども設置可能。
      • Prompts: プロンプトテンプレートを提供。
    • トランスポートレイヤー:
      • 標準入出力: ローカルでのMCPサーバーとのやり取り。
      • SSE (Server-Sent Events): 現在の主流。サーバーからクライアントへのストリーミング。ステートフルで常時接続。
      • Streamable HTTP (HTTP): 最新仕様で推奨。SSEの課題（ステートフル、常時接続によるリソース消費や中断時の復帰困難性、ミドルウェア適用難）を克服。VS Code v1.100よりサポート。オプションでSSEも利用可能。
  • MCPサーバーの探し方と利用デモ:
    • MCP公式リポジトリ (GitHub: microsoft/model-context-protocol) で公式実装やコミュニティ開発のサーバーがまとめられている。
    • デモ:
      • VS Codeを使用。
      • MCP公式リポジトリから「Time」MCPサーバー（現在時刻取得、タイムゾーン変換）をDockerでインストール設定。
      • VS Codeのsettings.jsonにMCPサーバーの起動コマンドを記述。
      • GitHub Copilotをエージェントモードにし、使用するMCPサーバー（ツール）を選択。
      • プロンプトで指示し、MCPサーバーのツール（例: getCurrentTime）を実行させ、結果を取得。
      • #ツール名で明示的にツールを指定することも可能。
  • Microsoft / Azure におけるMCP:
    • クライアント: VS Code (GitHub Copilot エージェントモード)
    • 公式サーバー:
      • Azure MCP Server: 多数のAzureサービス（DB系、Log Analytics、Azure CLI/AZD CLIなど）を自然言語で操作可能。
      • GitHub MCP Server: Personal Access Token (PAT) を設定し、GitHubの各種操作（コード検索、プルリクエスト操作など）を自然言語で実行。
      • Playwright MCP Server: Microsoft製のE2EテストツールPlaywrightを自然言語で操作（Webページ操作、キーボード操作、データ抽出）。
    • コミュニティ開発サーバー: Azure Data Explorer (ADX), Azure DevOps, Teams, OneNoteなど。
  • Azureプラットフォーム上のMCP関連アップデート:
    • Azure Functions: MCPトリガーが追加。既存のPython関数などにデコレータを付与するだけでMCPサーバーとして機能。C#, Python, TypeScriptに対応。
    • Azure API Center: APIの種類としてMCPを選択可能になり、MCPサーバーをAPIインベントリに含められる。API CenterからCopilot Studio用コネクタとしてエクスポート可能に。
    • Microsoft Copilot Studio: MCPサーバーのスキーマ情報（YAML）をインポートしてカスタムコネクタを作成し、エージェントから容易に呼び出し可能に。
  • MCPサーバー開発SDK:
    • Official MCP SDK
    • FastMCP (Python向け推奨、MCP v2ベース)
    • クライアントサイド: Semantic Kernel, AutoGenなど。
  • MCPサーバーのデプロイオプション: Azure Functions以外にもApp Service, Container Appsなど。公式サンプルリポジトリが多数提供（IaC込みでAZD upでデプロイ可能）。
  • MCPサーバーの認証・認可:
    • MCP公式では第三者認証フロー（Azure文脈ではEntra ID認証/OAuth認証）を推奨。
    • API Management (APIM) の活用: MCPクライアントとサーバーの間にAPIMを配置し、認証ゲートウェイとするのがデファクトスタンダードになりつつある。
      • APIMがEntra IDに対するOAuthクライアントとして機能。
      • クライアントはAPIM経由で認証し、取得したトークンでMCPサーバーと安全に通信。
    • 公式サンプルリポジトリでAPIMを使ったセキュアなMCPサーバー構築例が提供されている。
    • APIMのPrivate Endpoint対応 (Public Preview) により、よりセキュアでコスト効率の良い構成が可能に。
    • APIMの資格情報マネージャーやSemantic Kernel/AutoGenクライアント実装まで含んだ包括的なサンプルリポジトリも存在。
  • MCPが作る未来の展望:
    • 開発者はVS Code等、市民開発者や一般社員はCopilot Studio製エージェント等からMCPサーバーにアクセス。
    • API Managementが仲介し、FunctionsやContainer Appsでホストされた各種MCPサーバー（社内DB/APIアクセス用、外部DBアクセス用、業務効率化用、社内AIアプリ接続用など）を利用。
    • 標準化プロトコルにより実装コストを低減し、APIMでセキュアに連携。
  • まとめとコールトゥアクション:
    • MCPはLLMの外部アクセス標準化を目指す。実装コスト低減がメリット。
    • ステップ:
      1. 便利そうなMCPサーバーを探して使ってみる。
      2. 身の回りを効率化するMCPサーバーを作ってみる。
      3. Azure Functions等にデプロイしてみる。
      4. API Management等で認証認可を付けてみる。
• 質疑応答: なし

---

セッション5-1: Azure Load Testingを使ってAzure Functions Flex Consumptionのパフォーマンスとコストを最適化してみよう

• 講演者: 原 敏之さん (Microsoft MVP for Azure & AI、株式会社デクストスケープ)
• ブログ記事: 当日朝に執筆した内容を公開済み (ハッシュタグでツイート)
• 内容:
  • ピンチヒッター: 急遽登壇。スライドは最小限で、ブログとデモを中心に解説。
  • Azure Functions Flex Consumption:
    • 2023年11月のIgniteでGA。
    • 特徴:
      • スケーリングが非常に速い。
      • VNet統合に対応。
      • 「本当の意味でのサーバーレス」で高速スケーリングと閉域網構成が可能。
    • 日本リージョンで利用可能に: 今週水曜日（ゴールデンウィーク明け）から。
    • 今後のLinuxベースFunctionsのデファクトスタンダードになる可能性。
  • パフォーマンスとコスト最適化のポイント:
    • インスタンスのメモリサイズ: 3種類 (512MB, 2GB (デフォルト), 4GB)。
    • HTTPトリガーのコンカレンシー: 1インスタンスが処理できる並列リクエスト数。
      • デフォルト値: 2GBインスタンスで16、4GBインスタンスで32。
      • インスタンスサイズとコンカレンシーの適切な組み合わせを見つけることが重要。
    • 最大スケーリング数: 0 (ミニマム) から40～1000の間で指定可能。
    • コールドスタート対策: Always Readyインスタンス設定でウォーム状態のインスタンス数を指定可能。
    • 設定場所: Functionsポータルの「スケールとコンカレンシー (Scale and concurrency)」タブ。
  • Azure Load Testing との連携 (パフォーマンスオプティマイザー):
    • Functionsポータルの「パフォーマンスオプティマイザー (Performance Optimizer)」機能。
    • FunctionsポータルからAzure Load Testingを裏で利用し、テストプロファイル作成、実行、結果確認が可能。
    • 事前準備: 作成したFunctionsの「Webサイト共同作成者 (Website Contributor)」ロールを自身のアカウントに付与する必要あり。
  • デモ (パフォーマンスオプティマイザー):
    • テスト対象: シンプルなC# HTTPトリガー (1秒スリープするだけ)。
    • テストパターン: メモリサイズ2GB/4GB × コンカレンシー8/16/32 の計6パターン。
    • 負荷設定: 10ユーザーが3分間。
    • 結果確認:
      • スループットが最も高い組み合わせが「ベストパフォーマンス」としてマークされる。
      • 今回のデモでは4GB/コンカレンシー16がベストと表示。
      • Kustoクエリで詳細分析: インスタンス数の推移（最大10インスタンスまでスケール）、各パターンの実行状況。
      • スケーリングの速さ: 開始1秒未満で10インスタンスが立ち上がる様子を確認。
    • コストとのバランス:
      • 「On-demand function units」メトリクスでアクティブ時間（≒課金額）を確認。
      • スループットが最高でなくても、パフォーマンス要件を満たし、かつコストが低い組み合わせを選択することが重要。
  • まとめ:
    • Flex Consumptionはスケーリングが速くVNet対応で、日本リージョンでも利用可能になったので積極的に活用してほしい。
    • メモリとコンピューティング時間で課金されるため、パフォーマンスとコストのバランスをパフォーマンスオプティマイザー等でチューニングすることが推奨される。

---

---

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

• 講演者: 織田 菜津子 さん（株式会社エーピーコミュニケーションズ）
• 内容:
  • 自己紹介:
    • 株式会社エーピーコミュニケーションズに先月入社。
    • プラットフォームエンジニアリング業務を担当予定（主に開発者向けのガードレール作成など）。
    • 趣味はタロットで、本日のスライドデザインにも取り入れている。
  • セッションのゴール:
    1. プラットフォームエンジニアリングの大まかなイメージを理解する。
    2. Azure Deployment Environments (ADE) の概要を理解する。
    3. ADEの活用方法を理解する。
  • プラットフォームエンジニアリング概要:
    • 開発者がセルフサービス型でアプリケーション実行に必要なプラットフォームの構築・運用を行えるように、ツール、サービス、専門知識を提供する取り組みや専門分野。
    • 中核となるのが内部開発プラットフォーム (Internal Developer Platform – IDP) であり、API、クラウドインフラ、CI/CDツールなど、開発プロセスに必要なプラットフォームを専門チーム（プラットフォームチーム）が一元的に提供する。
    • これにより、開発プロセスの効率化と開発者の負担軽減を目指す。
  • プラットフォームエンジニアリングが注目される背景:
    1. システムの複雑化と開発者の認知負荷増大: コンテナ技術やマイクロサービスの普及により、開発者が習得すべき知識範囲が広がり、システム構成も複雑化。結果として、アプリケーション開発以外のインフラ管理などの業務負担が増え、認知負荷が高まっている。
    2. DevOpsの課題: DevOps導入は開発と運用の連携を強化し開発スピードを向上させたが、場合によっては開発者がDevOps基盤の構築・運用まで担うことになり、負担増につながるケースもある。
    3. DXの推進: 企業がDXを推進する中で、変化に迅速に対応できるソフトウェア開発が求められており、開発者の負担を軽減し、高品質な開発に集中できる環境の整備が不可欠。
  • プラットフォームエンジニアリングのメリット:
    • 開発者の生産性向上（インフラ管理からの解放）。
    • ソフトウェアデリバリーの迅速化（CI/CD基盤の提供）。
    • ガバナンスとセキュリティ強化（標準化されたテンプレート等による安全性確保）。
    • 運用効率の向上（インフラ管理集約による開発者の運用負荷軽減）。
    • コスト削減（共通基盤の活用と自動化）。
    • 開発者の満足度向上（開発への集中によるエンゲージメント向上）。
    • スケーラビリティと柔軟性の向上（クラウド技術の活用）。
  • DevOpsやSREとの相違点:
    • DevOpsとの違い: プラットフォームエンジニアリングは、DevOpsで開発者が担う可能性のあった開発以外の基盤構築・運用をプラットフォームチームが専門的に提供することで、開発者の負担をより軽減する点に特徴がある。
    • SREとの違い: SREはシステムの信頼性と品質向上を主目的とするが、プラットフォームエンジニアリングはそれに加えて開発効率の向上やセキュリティ強化を含めた自動化プロセス全体を実現することを目指しており、SREの要素を一部包含していると言える。
  • プラットフォームエンジニアリングで大事なこと（織田子氏の個人的見解）:
    • 開発者の利便性と組織としての制約のバランス: 開発者が快適に開発できる環境（フィードバック反映、認知負荷軽減）と、セキュリティ・コンプライアンス強化や品質の一貫性といった組織的な統制との間で、適切なバランスを取ることが重要。どちらかに偏ると、開発者のモチベーション低下や、逆にサービスの信頼性低下を招く可能性がある。
    • 各エンジニアリングチームの連携: プラットフォームチーム、開発チーム、SREチームなどが、それぞれの役割を認識しつつも、上下関係ではなくフラットな横の繋がりで協力し合うことが成功の鍵。
    • 一人ひとりが自分の役割を自覚し、バランスを取る努力:
      • 例1 (セキュリティ担当): セキュリティを強化しつつも、開発者の利便性を損なわないガードレールの策定を心がける。
      • 例2 (プラットフォームテンプレート): 品質の高いテンプレートを提供しつつ、CI/CDと連携したライフサイクル管理を実装することで、統制と開発効率のバランスを取る。
  • Azure Deployment Environments (ADE) の概要:
    • Azureが提供する、プラットフォームエンジニアリングを実現するためのマネージドサービス。
    • プラットフォームチームが事前に用意したインフラストラクチャテンプレート（ARMテンプレート、Bicep、Terraformなど）をカタログとして提供し、開発者はそれを利用してセルフサービスで必要な環境をオンデマンドに展開できる。
    • ADEの構成要素:
      • デベロッパーセンター: ADEの管理単位となる最上位のスコープ。
      • 環境の種類 (Environment Types): 「開発(dev)」「テスト(test)」「本番(prod)」など、環境の特性やポリシーを定義。
      • カタログ (Catalogs): GitHubリポジトリやAzure Reposに格納されたインフラテンプレートをADEに同期し、開発者が利用できるようにする。
      • プロジェクト (Projects): 開発チームやアプリケーション単位で環境をグループ化。
      • 環境 (Environments): カタログのテンプレートと環境の種類に基づいて実際にデプロイされるAzureリソース群。通常、リソースグループとして払い出される。
    • 開発者は、Azureポータル上の「開発者ポータル」またはAzure Developer CLI (AZD) を通じて環境の作成や管理を行う。
  • ADEの利用シナリオ:
    1. サンドボックス環境/オンデマンドテスト環境: 新機能の検証や一時的なテスト用に、開発者が迅速に環境を用意。
    2. トレーニング/ハンズオンラボ環境: 教育や研修用に、標準化された環境を簡単に配布・利用。
    3. CI/CDパイプラインへの統合: 開発、テスト、ステージング、本番といった各環境へのデプロイを自動化。
  • ADEの活用方法:
    • サンドボックス/テストラボ環境での活用:
      • 開発者は開発者ポータルやAZDから必要なテンプレートを選択し、環境をデプロイ。
      • ロール設定の重要性: 環境の種類ごとに、デプロイされるリソースグループに対する開発者のRBACロールを事前に定義可能。これにより、環境払い出し時に適切な権限が自動的に付与され、手動設定の手間を削減し、セキュリティを担保。
    • CI/CD統合における活用:
      • GitへのPushやPull Request作成などをトリガーとして、CI/CDパイプラインが起動し、サービスアカウント（サービスプリンシパルなど）によってADEを通じた環境デプロイが実行される。
      • ロール設定:
        • 環境作成者ロール: デプロイ操作を行うCI/CDのサービスアカウントに割り当てる。
        • 追加のアクセス許可: デプロイされた環境に対して、開発者チームなどの特定のEntra IDグループやユーザーに追加のロールを自動的に割り当てることが可能。
  • CI/CD統合における具体的な実装例 (Azure Pipelines を使用):
    • 環境ライフサイクルの自動化例:
      • 開発者が特定の開発ブランチ（例: feature/*）にコードをプッシュすると、対応する「開発環境」がADEによってデプロイされる。
      • mainブランチに対してPull Requestが作成されると、「ステージング環境」がデプロイされる。
      • Pull Requestがmainブランチにマージされると、「開発環境」と「ステージング環境」は削除され、「本番環境」がデプロイされる。
    • スケジュールパイプラインによる未使用環境のクリーンアップ: マージされずに放置された開発ブランチや、不要になった環境を定期的に（例: 毎日深夜に）スキャンし、自動的に削除する仕組みを導入することで、リソースの無駄遣いを防ぐ。
    • パイプラインの実装詳細:
      • 環境作成パイプライン: リポジトリへのコード変更時やPull Request作成時にトリガー。
      • 環境削除パイプライン: Pull RequestのマージイベントをAzure Service Hooksで検知し、Logic Appsを経由してパイプラインをトリガー（Azure Pipelinesのトリガー機能の制約を回避するため）。
      • スケジュール削除パイプライン: シェルスクリプト等でワークフローを組み、定期実行。
    • コード公開: この実装例のパイプラインコードや、環境構築に必要なTerraformコードはGitHub上で公開されており、誰でも試すことができる。
  • まとめ:
    1. プラットフォームエンジニアリングを成功させるには、各エンジニアリングチームが部門の壁を越え、フラットな関係で連携することが不可欠。
    2. チームの各メンバーが自身の役割を深く理解した上で、開発の自由度や利便性と、組織としての統制や制約との間で最適なバランスを見つける努力を継続することが求められる。
    3. Azureにおいては、Azure Deployment Environments (ADE) がプラットフォームエンジニアリングを支援する主要なサービスとなる。
    4. ADEは、サンドボックス環境の提供、テストの効率化、CI/CDパイプラインとの統合など、開発ライフサイクルの様々なシナリオで活用できる強力なツールである。

---