Toshiyuki Hara

GlobalAzure とは、世界中の Azure コミュニティが一斉に開催する Microsoft Azure のコミュニティイベントです。今年も世界中のコミュニティが開催期間にイベントを行い、日本からも東京、大阪、福岡、静岡、札幌のコミュニティがイベントを開催しました。私は、品川の日本マイクロソフトで開催した東京会場に参加しました。https://jazug.connpass.com/event/386399/セッションのアジェンダは、こんな感じ。Room C+D と Room B の２トラックで開催しました。YouTube にアーカイブがあるので、気になるセッションがあれば視聴できます。www.youtube.comwww.youtube.comAzure お悩み 996/1000本ノックだけは、配信がありません。当日会場から挙がった質問をその場にいる有識者たちが回答する形式です。ライブ感があって楽しいので、ぜひ現地で参加してほしいと思います。懇親会では LT に登壇しました。先月末に対応してブログに書いた Azure Static Web Apps の話をして、SWA 側の自動ビルドに余計な処理をさせ過ぎてはいけないという学びを紹介しました。 speakerdeck.com実はこれ全部 GitHub Copilot に対応してもらいました。障害が発生したのがシアトルで MVP Summit に参加しているタイミングだったので、セッション中に原因を調べてもらって、いくつか対応策を提案してもらい、Pull Request を作成してもらいました。GitHub Copilot に Azure Skills と MS Learn MCP を差しておくだけで、ここまで AI がやってくれる便利な時代になりました。

Global Azure 2026 に参加してきました

昨年に続き、MVP Summit に現地参加してきました。MVP Summit は、ワシントン州レドモンドのマイクロソフト本社で開催される MVP 向けのイベントです。セッション内容はすべて NDA のため、レドモンドキャンパスやシアトルのダウンタウンを散策した情報のみとなります。Courtyard by Marriott Seattle Bellevue/Downtown今年も、ベルビューの Courtyard by Marriott に宿泊しました。Link light rail の Bellevue Downtown 駅が近く、レドモンドの MS キャンパスまで通えるので便利です。Microsoft Redmond Campus会期中は、ほとんどを Building 33 で過ごしました。たくさんのセッション部屋があり、Microsoft のプロダクトチームや他の MVP と会話できる Hub などもあります。毎年恒例の MVP の名前が書かれたウォールもありました。Hub に Sticker Swap テーブルがあったので、Japan Azure Travelers のステッカーをデプロイしておきました。夕方くらいには枚数が残り少なくなっていたので、どこかの国の MVP がJAT のステッカーを貼ってくれているかもしれません。キャンパス内の風景はこんな感じ。シアトル散策ベルビューとレドモンドに滞在していましたが、シアトルも少し散策しました。Pike Place Marketお馴染みの Pike Place Market や Waterfront 周辺を散策しました。今年は FIFA ワールドカップの開催国ですが、まだそれっぽい雰囲気はありませんでした。有名店というわけでもないのですが、Monorail Espresso というお気に入りのカフェがあって、シアトルに来た際には毎回立ち寄っています。シアトルの Clam Chowder と Mac & Cheese は、安定の美味しさです。Ivar's Acres of Clams の White ChowderBeecher's Handmade Cheese の Mac & Cheese    University of Washingtonシアトルの桜の名所でもあるワシントン大学を散策しました。ちょうど満開でたくさんの人がお花見に来ていて、とても賑わっていました。Fremont Brewingフリーモントにある行きつけのブリュワリーに行きました。どのビールも美味しいですが、Golden Pilsner がお勧めです。ダウンタウンよりも落ち着いた雰囲気のフリーモントの街並みが気に入っています。Gas Works Park からの眺めも、天気が良くて素晴らしかったです。Lake View Cemeteryシアトルにブルース・リーのお墓があると知って、今回初めて Lake View Cemetery に行きました。学生時代をシアトルで過ごし、道場を開いたり奥さんと出会ったり、ブルース・リーにとってはゆかりの地だそうです。Link light railついにシアトルとベルビューの区間で、Link light rail が開通しました。これで空港からベルビューやレドモンドまでバスや配車サービスを使わずに移動できて便利になります。お世話になった 550 番のバスに乗る機会も減りそうです。Lake Washington にかかる浮橋の上を電車が走るのは世界初だそうです。浮橋は、橋脚を湖底に固定せず、巨大なコンクリートの箱型構造物として水に浮かんでいます。開通とは関係ありませんが、Link light rail や市内バスをクレジットカード決済のタッチで乗車できるようになりました。これで ORCA カードを使うこともなくなりました。Andiamo Italian Ristorante宿泊したベルビューのホテルの近くに以前から気になっていたイタリアンレストランがあって、やっと行くことができました。料理がとても美味しかったので、2回も行ってしまいました。Italian Sausage RigatoniLinguini Vongole    まとめ今年の MVP Summit の戦利品として、T シャツやジャケットなどをもらいました。現地参加することで、セッションに集中できますし、より多くのインプットや刺激をもらうことができました。もともと計画にあったのかもしれませんが、プロダクトチームに自分がフィードバックしてきた機能がリリースされたりロードマップに組み込まれたりすると嬉しくなります。今後も Azure や AI を中心とした技術のキャッチアップを継続して、より多くのフィードバックできるようになりたいです。

MVP Summit 2026 に参加してきました

弊社では、事業部ごとの技術ブログを集約する Hub のようなサイトを Azure Static Web Apps で構築しています。gooner.hateblo.jp現象このサイトは、ビルド時に事業部ごとの技術ブログの RSS フィードを取得し、その結果を静的コンテンツとしてデプロイする仕組みです。そのため、ソースコードの変更に関わらず、Schedule トリガーで毎日デプロイしています。エラーログを見ると、 RSS フィードを取得する際にタイムアウトになっていました。原因Azure Static Web Apps の自動ビルドのタイムアウトは、既定で15分に制限されています。試しに build_timeout_in_minutes: 30 を追加して 30分に延長してもタイムアウトになり、対処療法にすらなりませんでした。learn.microsoft.comそもそも RSS フィードの取得に 15分以上もかかりません。原因は、ビルドを実行している環境側にあり、Azure Static Web Apps 側のビルドで外部サイトに依存する処理を実行していることにありそうだと考えました。対応方法本来は RSS フィードの取得をビルドと分けることが望ましいですが、インパクトの大きな改修が必要になります。今回は、ビルド処理を Azure Static Web Apps 側の自動ビルドから GitHub Actions 側に移すことにします。name: Azure Static Web Apps CI/CD Timer Triggeron:  schedule:    - cron:  '0 6 * * *'jobs:  build_and_deploy_job:    runs-on: ubuntu-latest    name: Build and Deploy Job    env:      NODE_OPTIONS: --openssl-legacy-provider    steps:      - uses: actions/checkout@v4        with:          submodules: true      - name: Setup Node.js        uses: actions/setup-node@v4        with:          node-version: 18          cache: yarn      - name: Install dependencies        run: yarn install --frozen-lockfile      - name: Build site        run: yarn build      - name: Build And Deploy        id: builddeploy        uses: Azure/static-web-apps-deploy@v1        with:          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_MANGO_TREE_0F24E2F00 }}          repo_token: ${{ secrets.GITHUB_TOKEN }}          action: "upload"          app_location: "out"          api_location: ""          output_location: ""          skip_app_build: trueGitHub Actions 側で actions/setup-node を使って Node を固定し、yarn install と yarn build を自前で実行させます。SWA deploy アクションでは skip_app_build: true にして、生成済み out だけをアップロードします。さらに、RSS フィードの取得状況をログに出力しつつ、取得毎にタイムアウトも設定するようにしています。github.com対応結果Pull request をマージ後、3日くらい様子を見ましたが、1分半くらいでビルドとデプロイが完了するようになりました。まとめAzure Static Web Apps の自動ビルドがタイムアウトしやすくなった状況に対して、GitHub Actions 側で RSS フィード取得とビルドを行い、Azure Static Web Apps 側では成果物だけをアップロードするようにしました。今回の件で、Azure Static Web Apps 側の自動ビルドに余計な処理をさせ過ぎてはいけないという学びがありました。

Azure Static Web Apps の自動ビルドがタイムアウトしやすくなった状況に対応した件

前回の記事では、App Service から Application Insights へプライベートネットワーク経由でテレメトリを送信する構成に変更しました。gooner.hateblo.jpシステム構成Azure Front Door を経由して App Service へアクセスさせることで、DDoS Protection と WAF (Web Application Firewall) によってアプリケーションを保護する構成を題材に説明していきます。App Service では、Service Tag を使用して Azure Front Door からのアクセスのみを許可します。これは、ネットワークレベルで完全に閉域化する構成ではなく、L7（アプリケーションレイヤー）レベルで App Service へのアクセスを制御する構成となります。learn.microsoft.comAzure Front Door を作成するインターネット上に公開される Web アプリケーションには、クロスサイト スクリプティングや SQL インジェクションなど、さまざまな脅威が存在します。Azure Front Door には WAF の機能が備わっており、これらの脅威を検出・防御することができます。learn.microsoft.com配信元の種類には App Service、配信元のホスト名には 接続したい App Service 名 を指定します。Azure Front Door の作成が完了したら、Front Door の URL でアプリケーションに接続できることを確認します。バックエンドの設定が反映するまでに最大20分かかりますので注意してください。App Service で Service Tag を設定するAzure Front Door を経由せずに App Service へ直接アクセスできないよう、Service Tag を設定します。App Service の Settings - Networking から、インバウンドの Public network access を制限します。選択した仮想ネットワークと IP アドレスから有効にする項目を選択して、Service Tag には AzureFrontDoor.Backend、X-Azure-FDID には Front Door の ID を設定します。この設定により、App Service の URL(https://xxx.azurewebsites.net) にアクセスできないようになりました。なお、 App Service の Advanced Tools(https://xxx.scm.yyy.azurewebsites.net)には接続できる状態のため、必要に応じて規則を追加することを検討してください。WAF を導入するWAF ポリシーを作成して、Azure Front Door のエンドポイントに割り当てます。Microsoft_DefaultRuleSet などの既定のルールセットが用意されていますが、カスタム ルールを使用することで、Web アプリケーションの要件に合わせた柔軟な設定も可能です。learn.microsoft.comまとめAzure Front Door を経由して App Service へアクセスさせることで、DDoS Protection と WAF によりアプリケーションを保護する構成に変更しました。App Service をプライベートネットワークで構成するシリーズとして４本の記事を書きましたが、いったんこの記事で終了としたいと思います。

Azure Front Door で App Service を外部攻撃から保護する

前回の記事では、App Service から SQL Database へプライベートネットワークで接続する構成において、Private Endpoint を利用して Key Vault からシークレットを参照するように変更しました。gooner.hateblo.jpシステム構成App Service から Application Insights へ、プライベートネットワークでテレメトリを送信する構成を例に説明します。Azure Monitor Private Link Scope を作成するAzure Monitor Private Link Scope（AMPLS）は、Azure の監視サービスに対してプライベートネットワークで接続するための 「Private Endpoint の適用範囲」 を定義するリソースです。learn.microsoft.comAMPLS の Configure - Azure Monitor Resources から関連付ける Application Insights と Log Analytics を設定します。Azure Monitor Private Link Scope の Private Endpoint を作成する次に、AMPLS の Configure - Private Endpoint connections から Private Endpoint を作成します。リソースの種類は Microsoft.Insights/privateLinkScopes、対象サブリソースは azuremonitor を選択します。Private Endpoint 用に作成したサブネットを選択し、IP アドレスを動的に割り当てるようにします。監視リソースの FQDN をプライベート IP アドレスに正しく名前解決させるため、Private DNS Zone を統合します。前述した通り、複数の監視リソースが存在することが AMPLS を作成する理由となります。監視リソースのアクセスモードを変更するAMPLS の Private Endpoint を作成したら、Configure – Access modes から監視リソースのアクセスモードを変更します。監視リソースも同様に、Ingestion だけパブリックな通信を無効にします。Application InsightsLog AnalyticsApp Service から Application Insights へプライベートネットワークでテレメトリを送信できるようになりました。App Service の Kudu から nslookup を実行すると、Application Insights の FQDN からプライベート IP アドレスが返されていることを確認できます。まとめApp Service から Application Insights へ、プライベートネットワーク経由でテレメトリを送信する構成に変更しました。gooner.hateblo.jp

Azure App Service と Application Insights をプライベートネットワークで利用する

前回の記事では、App Service の Virtual Network Integration と SQL Database の Private Endpoint を使用し、プライベートネットワーク経由で接続する構成を確認しました。gooner.hateblo.jpシステム構成App Service から SQL Database へプライベートネットワークで接続する構成において、Private Endpoint を使用して Key Vault からシークレットを参照する方法について説明していきます。前準備前回の記事で用意したアプリケーションに対して、SQL Database の接続文字列を Key Vault から取得するように変更します。Azure 環境では、Key Vault を構成プロバイダーとして登録することで、シークレットを IConfiguration 経由で参照できるようになります。if (!builder.Environment.IsDevelopment()){    builder.Configuration.AddAzureKeyVault(new Uri(builder.Configuration["KeyVaultUrl"] ?? ""), new DefaultAzureCredential());}builder.Services.AddDbContext<ShopDbContext>(options =>    options.UseSqlServer(builder.Configuration["ShopDbContext"] ?? throw new InvalidOperationException("Key Vault Secret 'ShopDbContext' not found.")));なお、ローカルの開発環境では、appsettings.json ではなく、.NET Core のシークレット管理（secrets.json）を使用して、ShopDbContext の接続文字列を定義しています。{  "ShopDbContext": "Server=(localdb)\\mssqllocaldb;Database=Shop;Trusted_Connection=True;MultipleActiveResultSets=true"}    Key Vault を作成するまずは、Key Vault を作成して、IAM でシークレットを登録できるロール（Key Vault Secrets Officer）を自分に割り当てます。シークレットに SQL Database の接続文字列を登録します。App Service と Key Vault を Managed Identity で認証する次に、App Service の環境変数に Key Vault の URL（https://xxx.vault.azure.net）を登録します。なお、前回の記事で登録した SQL Database の接続文字列は削除しておきます。App Service の Settings - Identity から、Managed Identity を有効化します。Key Vault の IAM から、シークレットを参照できるロール（Key Vault Secrets User）を App Service に割り当てます。パブリックネットワークアクセスを有効にした Key Vault  からシークレットを取得する構成で、アプリケーションが動作するようになりました。Key Vault の Private Endpoint を作成する最後に、Key Vault の Settings - Networking から Private Endpoint を作成します。リソースの種類は Microsoft.KeyVault/vaults、対象サブリソースは vault を選択します。Private Endpoint 用に作成したサブネットを選択し、IP アドレスを動的に割り当てるようにします。Key Vault の FQDN をプライベート IP アドレスに正しく名前解決させるため、Private DNS Zone を統合させます。Private Endpoint を作成できたら、Key Vault の Settings - Networking からパブリックネットワークアクセスを無効にします。App Service から Key Vault へプライベートネットワークで接続できるようになりました。App Service の Kudu から nslookup を実行すると、Key Vault の FQDN からプライベート IP アドレスが返されていることを確認できます。まとめApp Service から SQL Database へプライベートネットワークで接続する構成において、Private Endpoint を利用して Key Vault からシークレットを参照するように変更しました。gooner.hateblo.jp

Azure App Service と Key Vault をプライベートネットワークで利用する

App Service から SQL Database へのアクセスを仮想ネットワーク内に制限したいという要件がある場合、Virtual Network Integration と Private Endpoint を利用することで、プライベートネットワーク経由で安全に接続することができます。システム構成App Service から SQL Database へプライベートネットワークで接続するシンプルな構成を例に、構成方法を説明します。Virtual Network IntegrationApp Service から仮想ネットワーク内のリソースへのアクセスを制御する機能です。learn.microsoft.comPrivate EndpointSQL Database へのアクセスを仮想ネットワークの中からのみに限定する機能です。learn.microsoft.com前準備ASP.NET Core を使用して、商品一覧を表示するアプリケーションを用意しました。Shop データベースの Product テーブルを参照し、MVC の View に一覧表示しています。public class ProductsController : Controller{    private readonly ShopDbContext _context;    public ProductsController(ShopDbContext context)    {        _context = context;    }    public async Task<IActionResult> Index()    {        return View(await _context.Product.ToListAsync());    }}ShopDbContext を Entity Framework Core の DI コンテナに登録し、データプロバイダーとして SQL Server を使用する構成としています。var builder = WebApplication.CreateBuilder(args);builder.Services.AddDbContext<ShopDbContext>(options =>    options.UseSqlServer(builder.Configuration.GetConnectionString("ShopDbContext") ?? throw new InvalidOperationException("Connection string 'ShopDbContext' not found.")));appsettings.json では、環境変数の ShopDbContext というキーから接続文字列を取得するように構成しています。{  "ConnectionStrings": {    "ShopDbContext": "Server=(localdb)\\mssqllocaldb;Database=Shop;Trusted_Connection=True;MultipleActiveResultSets=true"  }}パブリックネットワークアクセスを有効にした SQL Database に接続する構成で、App Service にデプロイしました。SQL Database の接続文字列は、App Service の環境変数に登録しています。Virtual Network を作成する前置きが長くなりましたが、ここからが本題です。Virtual Network Integration 用のサブネットは、他のリソース（Private Endpoint など）と共有できないことに注意してください。SQL Database の Private Endpoint を作成する次に、SQL Database の Security - Networking から Private Endpoint を作成します。対象サブリソースは、sqlserver を選択します。Private Endpoint 用に作成したサブネットを選択し、IP アドレスを動的に割り当てるようにします。SQL Database の FQDN をプライベート IP アドレスに正しく名前解決させるため、Private DNS Zone を統合させます。Private Endpoint を作成できたら、SQL Database の Security - Networking からパブリックネットワークアクセスを無効にします。これにより、App Service から SQL Database へ接続できなくなりました。App Service の Virtual Network Integration を構成する最後に、App Service の Settings - Networking から Virtual Network Integration を構成します。これにより、App Service から仮想ネットワーク内のリソースへアウトバウンド通信が可能になります。Virtual Network Integration 用に作成したサブネットを選択して接続します。App Service から SQL Database へプライベートネットワークで接続できるようになりました。Virtual Network Integration はアウトバウンド通信の制御となりますので、インバウンド通信を制御したい場合には Private Endpoint を作成する必要があります。App Service の Kudu から nslookup を実行すると、SQL Database の FQDN からプライベート IP アドレスが返されていることを確認できます。まとめApp Service の Virtual Network Integration と SQL Database の Private Endpoint を利用することで、プライベートネットワーク経由の接続を構成しました。gooner.hateblo.jp

Azure App Service と SQL Database をプライベートネットワークで利用する

先週、第8回 Azure Travelers 勉強会 仙台の旅に参加してきました。jat.connpass.com勉強会株式会社 ASAHI Accounting Robot 研究所（ロボ研）さんにご協力をいただき、Microsoft Base Sendai をお借りしました。仙台と同じく、お洒落で素敵な会場でした。予想以上に沢山の方に参加していただけたので、メイン会場だけでは収まり切らず、サテライト会場も作りました。メイン会場の様子をガラス越しに見ながら、サテライト配信側の数秒遅れのリアクションが不思議な感じでした。普段自分が関わることが少ない領域は学びになることが多いですし、技術的な内容だけでなくお仕事や立場の異なる方々の話を聞けるのは面白いです。勉強会の翌日に観光を楽しんでいるところも含めて、Azure Travelers の良さだと思います。X のまとめがあるので、そんな雰囲気を感じ取ってもらえたらと。posfie.com今回もロボ研さんにスポンサーしていただいてステッカーを作りました。スターバックスにコーヒートラベラーというものがあって、酒見さんが買ってきてくれました。会場に出来立てのコーヒーの香りがしていい感じで、ネーミングもコミュニティに合っているので、また機会があれば利用したいです。menu.starbucks.co.jp飛び入りの LT で Azure Durable Functions で作った NL2SQL Agent の精度向上に取り組んだ話をしました。会場の有識者からのフィードバックで今回のアプローチが的外れでないことが分かりましたし、別のアプローチもあるという学びもありました。 speakerdeck.com午前中のみ配信のアーカイブがあります。www.youtube.com懇親会は集合郎 はなれでせり鍋、前夜祭は蔵の庄でネギまぐろ鍋、仙台の美味しいものと日本酒を満喫しました。Azure Travelers では、開催地をサイコロで決める水曜どうでしょう的なルールがあり、次々回は広島に決定しました。既に申し込みサイトがオープンしています。jat.connpass.com仙台観光仙台は東京と比べて寒かったです。最高気温が0℃くらいで、薄っすらと積もる程度でしたが、雪が降ることもありました。秋保温泉秋保温泉は、仙台駅から車で30分くらいのところにあり、別所温泉、野沢温泉とともに日本三御湯と言われています。３年前に来たことがあるのですが、なかなか良い温泉だったので今回も来ました。www.sentabi.jp温泉街っぽい写真は撮っていないのですが、GREAT DANE BREWING というブルワリーのクラフトビールが美味しかったです。ニッカウヰスキー宮城峡蒸溜所秋保から仙台に戻る途中で、ニッカウヰスキー宮城峡蒸溜所に立ち寄りました。何度か来ていますが、今回初めて無料のガイドツアーに参加しました。ウイスキーの製造工程やニッカウヰスキーの歴史を説明してくれて、最後に試飲もついている70分のコースでとても良かったです。仙台仙台では、孤独のグルメに登場した萃萃で牛タンを食べました。本当は井之頭五郎が食べたテール焼きを注文したかったのですが、店主が納得いくテールが仕入れられなかったため、この日は残念ながら品切れとのことでした。一応、仙台っぽい観光地にも行きました。仙台城跡瑞鳳殿少し時間があったので、定禅寺通りのイルミネーションも見に行きました。    松島勉強会の翌日は、友人たちと車で松島を観光しました。京都の天橋立、広島の厳島と並ぶ日本三景のひとつです。湾内を一周する遊覧船に乗って島巡りしました。まとめ第8回 Azure Travelers 勉強会 仙台の旅は、今回も楽しいイベントでした。会場を提供してくださったロボ研さんと参加者の皆様、ありがとうございました。次回は 4月に金沢開催を予定しています。会場と日程を鋭意調整中です。

第8回 Azure Travelers 勉強会 仙台の旅に参加してきました

.NET 10 が GA しましたので、Azure App Service にデプロイされている ASP.NET Core のアプリケーションをマイグレーションしました。github.comこれまでは手動によるマイグレーションでしたが、今回は GitHub Copilot App Modernization を使ってみました。GitHub Copilot App Modernization.NET 9 から 10 にマイグレーションする手順は、こちらのドキュメントの通りです。learn.microsoft.comGitHub Copilot App Modernization を使うと、チャットの @modernize コマンドで .NET アプリを新しいバージョンにアップグレードできます。learn.microsoft.comApplicationVisual Studio 2026 の GitHub Copilot 画面から、@modernize コマンドでアップグレードを開始します。何をするか聞かれるので、Start a .NET upgrade workflow と入力します。対話を進めると、アップグレードプランを提示してくれます。github.com.NET と NuGet packages のバージョンを更新するだけで済みそうなので、approve plan と入力します。その後も対話を進めると、upgrade-to-NET10 ブランチが作成されて計画通りにアップグレードが完了しましたので、finish と入力します。アップグレードレポートを確認して、コードの変更をコミットします。github.comソリューションに含まれないので仕方ありませんが、GitHub Actions の workflow は更新してくれません。こちらの dotnet-version も忘れずに更新しておく必要があります。jobs:  build:    runs-on: windows-latest    steps:      - uses: actions/checkout@v4      - name: Set up .NET Core        uses: actions/setup-dotnet@v1        with:          dotnet-version: '10.0.x'          include-prerelease: true    その他のマイグレーションGitHub Copilot App Modernization がマイグレーションしてくれなかった NuGet packages のバージョンを更新します。バージョンを更新するほかに、追加で対応した内容が２つあります。OpenAPI 3.1 対応.NET 10 で OpenAPI 3.1 のサポートが追加されたので、対応しておきました。learn.microsoft.comapp.UseSwagger(c =>{    c.OpenApiVersion = OpenApiSpecVersion.OpenApi3_1;});    AutoMapperAutoMapper はバージョン 15.0 より商用ライセンスが適用されることになりました。しばらくは無料で使いたいので、14.0 を使うことにしました。www.jimmybogard.comAzure App ServiceApp Service 側は、.NET Version を変更するのみです。以上で、無事に .NET 10 へのマイグレーションが完了しました。まとめGitHub Copilot App Modernization を使って Azure App Service のアプリを .NET10 にマイグレーションしてみました。今回は .NET と NuGet packages のバージョンを更新するだけで済みましたが、破壊的変更があった場合はどのくらい自動で対応してくれるのか気になりました。とはいえ、GitHub Actions の更新漏れがあったように、AI が更新した結果をしっかりとレビューすることは必須です。

GitHub Copilot App Modernization を使って Azure App Service のアプリを .NET10 にマイグレーションする

2025年もあと数時間となりましたので、今年１年を振り返ります。イベント登壇Global Azure 2025Azure Load Testing を使って Azure Functions Flex Consumption の HTTP Trigger Function のパフォーマンスとコストを最適化する話をしました。gooner.hateblo.jp第6回 Azure Travelers 勉強会 愛媛の旅Azure のマルチテナント アーキテクチャ設計について、マルチテナント アプリケーションに共通する課題と、お仕事での顧客導入実績で実証した解決方法を話しました。gooner.hateblo.jpコミュニティ運営Japan Azure User GroupJAZUG の運営は足利さんたちに任せっきりであまりお手伝いできていませんが、Azure Travelers とコラボした15周年は前夜祭の屋形船も含めて楽しいイベントでした。gooner.hateblo.jpAzure Travelers 勉強会Azure Travelers は Azure と旅をテーマとしたコミュニティで、JAZUG とは違った面白さのある勉強会です。今年は、沖縄、愛媛、東京で開催しました。gooner.hateblo.jpどの旅も楽しかったですが、宮古島でのワーケーションが良かったです。gooner.hateblo.jpMicrosoft MVP昨年に続き、MVP Global Summit（グロサミ）に現地参加しました。オンライン参加と比べて多くのインプットや刺激をもらうことができますし、他の MVP の方々とも繋がることができたのも良かったです。gooner.hateblo.jp今年も Microsoft MVP を更新できたので、来年3月のグロサミにも現地参加の予定です。仕事開発内製化を推進したい顧客に対して、最新の Azure PaaS / Serverless によるクラウドネイティブなアーキテクチャを活用した構築支援を行いました。生成 AI を開発ライフサイクルに活用しつつ、エージェントを組み込んだシステムを構築しました。また、Microsoft の海外カンファレンスである Build と  Ignite に現地参加しました。gooner.hateblo.jpgooner.hateblo.jpまとめ今年もいろいろな場所へ旅行に行きましたし、推し活も捗りました。来年も趣味と仕事のどちらも楽しんでいきたいです。おまけ2025年自分が選ぶ今年の8枚。宮古島の伊良部大橋宮古島のカギンミビーチSeattle Mariners 観戦Seattle の Gas Works Park愛媛のしまなみ海道屋形船で LT 大会San Francisco の Golden Gate Bridgeもうすぐ金になるラジオ 2nd Event

2025 年振り返り

昨年11月の Ignite 2024 に続き、今年も Ignite 2025 に現地参加してきました。昨年の開催地はシカゴでしたが、今年はサンフランシスコで開催されました。ignite.microsoft.comBook of Newsブチザッキ（Keynote、Azure Updates (2025-11-19) Microsoft Ignite 2025 Day 1）この記事では、現地参加の雰囲気や個人的に感じたことをお伝えしていきます。Registration会場は、サンフランシスコにある Moscone Center です。参加者数は昨年よりも多い2万人となり、Registration に行列ができていました。Keynote今年のキーノートは、Moscone Center とは別の場所となる Chase Center で行われました。NBA のゴールデンステイト・ウォリアーズのホームアリーナです。今回も MVP 向けの Priority Seat が用意されており、広いアリーナの中でもステージに近い席でテンションが上がりました。キーノートのスピーカーは Satya Nadella ではなく、Judson Althoff でした。Zava という架空の企業を想定したシナリオに沿って、キーノートが進められました。今回の Ignite の重要なキーワードのひとつ「Work IQ」は、RAG を拡張させたインテリジェンスレイヤーです。Copilot やエージェントにデータ、メモリ、推論を与えることで、より有用でパーソナライズされた情報を生成できるようにします。Azure AI Foundry 改め Microsoft Foundry が発表されました。App Builder、Copilot Studio、GitHub Copilot を動かすプラットフォームとして、Model router、Foundry IQ、Agent Service、Control Plane などの機能が統合されています。キーノートでオーディエンスの反応が最も大きかったのは、Anthropic とのパートナーシップの発表でした。Microsoft Foundry で Claude の Sonnet や Opus など最新のモデルをデプロイできるようになります。Microsoft Agent 365 は、企業内でどのようなエージェントが動いているのか、エージェント毎のアクセス制御、利用状況などを一元管理できます。従業員の ID 管理の延長でエージェントも管理するというコンセプトが面白いと感じました。最後に、Scott Guthrie から AI データセンターや Azure アップデートの話があり、AKS Automatic の GA や Azure Horizon DB の発表がありました。Azure Copilot も リソースを選択して質問できるようになり、Migration Agent の発表もありました。今回の Ignite は「Agent」という言葉が頻繁に登場し、エージェントを活用したビジネスのビジョンを強く打ち出していました。これまでの Copilot のような“副操縦士”にとどまらず、タスクを任せられる“人”に近い存在としての将来像でした。Microsoft Agent 365 には、エージェントがきちんと仕事をしているかを確認するための“可観測性”を提供する役割があります。エラーで止まっていれば解決し、結果が物足りなければプロンプトを改善する。まるで、プロジェクトの朝会でメンバーの進捗を確認し、フォローするのと同じ感覚です。AI がチームの一員になる未来が、少しずつ現実味を帯びてきました。歴史は繰り返すと言いますが、エージェントも本質的にはマイクロサービス（API）に近い存在だと思います。ただ、決定的に違うのはインターフェースが自然言語であること。この違いが、エンジニアだけでなくビジネスユーザーにも広く普及する鍵になると感じました。とはいえ、今回のキーノートは概念的な話が中心で、「業務で使えるエージェントを本当に作れるのか？」というモヤっと感は残りました。結局のところ、データをいかに LLM が理解しやすい形式に変換できるか、ナレッジをどう言語化するか。この整備ができれば、汎用的な回答ではなく、より有用でパーソナライズされた回答が得られるはずです。この部分こそがインテリジェンスレイヤー（IQ）だと思いました。Microsoft 365 で ID 管理を担う Entra ID と SharePoint Online に置かれた企業データを握っている Microsoft は強いと改めて感じました。Breakoutブレイクアウトセッションの様子。個人的に熱いと感じた Azure 関連のアップデート。App ServiceManaged Instance(Public Preview)新しいけど何故か懐かしいサービス。zip に固めてデプロイして、RDP もできる・・・Cloud Service（Web Role）じゃないか！Async Scaling(Public Preview)429 エラーに遭遇したことはないけど、非同期で確実にスケーリングしてくれる。Azure FunctionsDurable Task Extension for Microsoft Agent Framework(Public Preview)Agent 開発の本命で期待している機能。Durable Task Scheduler Dedicated SKU (GA)Durable Functions のスケーラビリティと可観測性を向上できるので Agent 開発で使いたい。Azure Container AppsDeployment labels(Public Preview)Blue / Green デプロイの時にラベルをごにょごにょしないで済む。Cosmos DBSemantic Search&Fuzzy Search(GA)Agent 開発ですぐに使いたい機能。Semantic Reranking は Private Preview。Fleet Pools(GA)マルチテナントで TenantID を Partition Key にする以外の選択肢。その他StandardV2 SKU NAT Gateway(Public Preview)NAT Gateway がゾーン冗長に対応。アーセナルファンとして、今回の Ignite で一番ワクワクしたのは、Microsoft と Premier League の協業による事例セッションでした。今シーズンから試合中継の左上に表示される Stats に「Copilot」の文字があります。さらに、公式モバイルアプリも AI を活用したコンパニオンアプリに刷新されています。そして、会場で本物のトロフィーを見られたのは感激でした。スピーカーをサポートしていた女性が Bukayo Saka のユニフォームを着ていたのも、ファンとしてはポイントが高かったです。今シーズンこそ、アーセナルが優勝してそのトロフィーを掲げる瞬間を見たいです。会場の様子Moscone Center には West、North、South の３つの建物があり、自由に聞きたいセッションを選べます。隣の Marriott Marquis Hotel も会場になっており、昨年のシカゴの会場と比較しても、かなり広い会場でセッション間の移動が大変でした。HUB はパートナーのブースやシアターセッションがある広い会場でした。エキスパートのブースもあったので、開発チームにいくつかフィードバックしておきました。Azure Functions Flex Consumption で Dutable Task Scheduler を使いたい（Consumption は発表あり）Azure Functions Flex Consumption で Deployment Slot を使いたい（Rolling updates はあるけど、Swap したい）GitHub Actions の Azure private networking を東日本でも使いたい（西日本はある）恒例の MVP と RD の名前が書かれた Wall もあって、自分の名前を発見しました。今年5月の Build ランチが美味しかったので期待していましたが、Ignite ランチは全体的に例年並みでした。今回の戦利品。Backpack と Water Bottle が貰えました。まとめMicrosoft Ignite 2025 にサンフランシスコで現地参加してきました。gooner.hateblo.jp

Microsoft Ignite 2025 に現地参加してきました

7月の AOAI Dev Day 2025 は仕事の都合で参加できなかったのですが、しばやんさんのセッションをスライドを読んで Agentic Web アプリケーションを MCP に寄せて作るアーキテクチャが面白そうだったので試してみました。 speakerdeck.comなぜ Agentic Web アプリケーションを MCP で構築するのか？今回は、以前に Azure Durable Functions + Durable Task Scheduler を使って構築した旅行コンシェルジュの Agentic Web アプリケーションを題材にします。gooner.hateblo.jpDurable Functions の Activity を Agent に見立て、Orchestration の中で「実行すべき Activity を Function calling で決定→ Activity を呼び出し→ Activity の実行結果を合成」というロジックを実装しています。Activity の決定や実行結果の合成の処理も LLM を利用した Activity として実装しています。このアーキテクチャを MCP に寄せることで、次のようなシーケンスで先程と同様の Agentic Web アプリケーションを構築できます。MCP Server が提供する Tools を Agent に見立て、OrchestratorWorker が MCP Client となり、LLM が登録された Tools を必要に応じて実行し、最終的にユーザー向けのメッセージを合成するところまで処理してくれます。Azure Functions MCP extension や MCP Client SDK を使ってすぐにアーキテクチャを組めるので、Tools（Agent）の内部実装に注力できるLLM に任せる部分が増えることで OrchestratorWorker がシンプルになり、プロンプトを調整しやすいし、LLM の性能向上の恩恵を受やすくなるMCP Server が提供する Tools を拡張するだけで、すぐに MCP Client に反映されるMCP Server を外部公開する想定はないが、外部提供されているリモート MCP Server を組み込みやすいなどが、Agentic Web アプリケーションを MCP で構築するモチベーションです。MCP Server を実装するAzure Functions MCP extension を使って、MCP Server を実装します。PM> NuGet\Install-Package Microsoft.Azure.Functions.Worker.Extensions.Mcp -Version 1.0.0McpToolTriggerAttribute を使用して、Function を実装します。旅行コンシェルジュ向けの Tools をいくつか実装しますが、今回の本題とは逸れるのでロジックは決め打ちの文字列としています。public class DestinationSuggestAgent(ILogger<DestinationSuggestAgent> logger){    private readonly ILogger<DestinationSuggestAgent> _logger = logger;    [Function(nameof(GetDestinationSuggest))]    public string GetDestinationSuggest(        [McpToolTrigger(nameof(GetDestinationSuggest), "希望の行き先に求める条件を自然言語で与えると、おすすめの旅行先を提案します。")] ToolInvocationContext context,        [McpToolProperty(nameof(searchTerm), "行き先に求める希望の条件", true)] string searchTerm)    {        // This is sample code. Replace this with your own logic.    }}    MCP Client を実装するMCP C# SDK を使って、MCP Client を実装します。PM> NuGet\Install-Package Azure.AI.OpenAI -Version 2.5.0-beta.1PM> NuGet\Install-Package Azure.Identity -Version 1.17.0PM> NuGet\Install-Package Microsoft.Extensions.AI -Version 9.10.1PM> NuGet\Install-Package Microsoft.Extensions.AI.OpenAI-Version 9.10.1-preview.1.25521.4PM> NuGet\Install-Package ModelContextProtocol -Version 0.4.0-preview.3Program.cs で、ChatClient のインスタンスを DI に登録しておきます。builder.Services    .AddApplicationInsightsTelemetryWorkerService()    .ConfigureFunctionsApplicationInsights()    .AddTransient<IOrchestratorWorker, OrchestratorWorker>()    .Configure<TravelConciergeSettings>(builder.Configuration.GetSection("Function"))    .AddChatClient(_ => BuildChatClient(builder.Configuration));builder.Build().Run();static IChatClient BuildChatClient(IConfiguration configuration){    string GetRequired(string key) =>        configuration[key] ?? throw new InvalidOperationException($"{key} is required.");    var endpoint = GetRequired("Function:AzureOpenAIEndpoint");    var apiKey = GetRequired("Function:AzureOpenAIApiKey");    var modelDeploymentName = GetRequired("Function:ModelDeploymentName");    return new ChatClientBuilder(            new AzureOpenAIClient(new Uri(endpoint), new AzureKeyCredential(apiKey))                .GetChatClient(modelDeploymentName).AsIChatClient())        .UseFunctionInvocation()        .Build();}AOAI のエンドポイントやキーは、secrets.json に定義しておきます。MCP 関連の項目は後ほど解説します。{  "Function": {    "AzureOpenAIEndpoint": "https://xxx-xxx-eastus2.cognitiveservices.azure.com/",    "AzureOpenAIApiKey": "xxx",    "ModelDeploymentName": "gpt-4o",    "MCPServerEndpoint": "http://localhost:xxxx/runtime/webhooks/mcp",    "MCPExtensionSystemKey": "xxx"  }}OrchestratorWorker クラスに、MCP Client を実装します。public async Task<OrchestratorWorkerResult> RunOrchestrator(Prompt prompt){    var messages = prompt.Messages.ConvertToChatMessageArray();    ChatMessage[] allMessages = [        new ChatMessage(ChatRole.System, OrchestratorWorkerPrompt.SystemPrompt),        .. messages,    ];    // Create the MCP client    // Configure it to start and connect to MCP server.    var mcpClient = await CreateMcpClientAsync();    // List all available tools from the MCP server.    _logger.LogInformation("Available tools:");    var tools = await mcpClient.ListToolsAsync();    foreach (var tool in tools)    {        _logger.LogInformation("Tool: {ToolName} - {ToolDescription}", tool.Name, tool.Description);    }    // Conversation that can utilize the tools via prompts.    var response = await _chatClient.GetResponseAsync(allMessages, new() { Tools = [.. tools] });    return new OrchestratorWorkerResult    {        Content = response.Text,        CalledAgentNames = ExtractFunctionCallNames(response.Messages)    };}上記の通り、シンプルな実装です。secrets.json に定義した MCP Server の Endpoint と MCP Extension の System Key を使った McpClient の生成が肝となります。localhost で実行する場合、MCPExtensionSystemKey はどんな値でも構いません。private async Task<McpClient> CreateMcpClientAsync(){    IClientTransport clientTransport = new HttpClientTransport(new()    {        Endpoint = new Uri(_settings.MCPServerEndpoint),        TransportMode = HttpTransportMode.StreamableHttp,        Name = "Travel Concierge MCP Server",        AdditionalHeaders = new Dictionary<string, string>        {            {"x-functions-key", _settings.MCPExtensionSystemKey}        }    });    return await McpClient.CreateAsync(clientTransport!);}実行された Tools の名前は、返却されたアシスタントのプロンプトから取得できます。private List<string> ExtractFunctionCallNames(IList<ChatMessage> messages){    return messages        .Where(m => m.Role == ChatRole.Assistant && m.Contents != null && m.Contents.All(c => c is FunctionCallContent))        .SelectMany(m => m.Contents.OfType<FunctionCallContent>().Select(c => c.Name))        .ToList();}以上の手順で、MCP を使用した Agentic Web アプリケーションを構築できました。ローカルのエミュレーターで動かすAzurite が Docker Image で公開されていますので、ローカルの Docker Desktop で実行します。$ docker run --rm -it -p 10000:10000 -p 10001:10001 -p 10002:10002 -v c:/azurite:/data mcr.microsoft.com/azure-storage/azurite:3.33.0フロントエンドの Streamlit とバックエンドの Functions をローカルで実行し、チャットを入力してみます。Tools の get_destination_suggest を利用して、おすすめの旅行先が提案されています。Azure にデプロイする構築したアプリケーションを Azure Functions Flex Consumption にデプロイします。ポイントは、MCP Extension の System Key を確認する部分です。MCP Extension の System Key を含め、ローカルの secrets.json に定義していた値を App Settings に追加します。以上の手順で、MCP を使用した Agentic Web アプリケーションを Azure 上でも動かすことができます。まとめAzure Functions MCP Extension を使って、Agentic Web アプリケーションを構築してみました。これまで Function Calling を駆使して実装していた Orchestration ロジックを、LLM と MCP に委ねることで、Tools（Agent）の内部実装に集中できるメリットは大きいと感じました。MCP extension が Ver.1.0.0 となって Streamable HTTP にも対応しました。また、MCP Client に登録する Tools の情報をリクエストごとに取得するのはオーバーヘッドが大きいため、MCP Server と Client を Function App として分離し、Tools の情報を永続化する仕組みも検討したいです。逆に、長時間の処理や複雑なオーケストレーションが求められる Agent に関しては、Durable Functions を活用する方が適していると感じました。今回のソースコードは、こちらのリポジトリで公開しています。github.com

Azure Functions MCP extension を使用して Agentic Web アプリケーションを構築する【Streamable HTTP 版】

先月、Japan Azure User Group 15周年と第7回 Azure Travelers 勉強会 東京の旅のコラボレーションイベントに参加してきました。jazug.connpass.com前夜祭いつもは地方へ旅に行く Azure Travelers ですが、今回は東京開催ということで前夜祭として屋形船の LT 大会を企画しました。jat.connpass.com北品川の船宿平井の屋形船を貸切予約しました。料理は天ぷらとお刺身のプランで、周遊コースはお台場・隅田川コースを選びました。北品川を出港して、お台場沖で停泊しました。停泊中は屋形船の屋根の上のデッキに上がることができて、夜景が奇麗でした。その後、隅田川を北上して勝鬨橋あたりまで行きました。150分の飲み放題付で料理もボリュームがありましたし、とくに揚げたての天ぷらが美味しかったです。船内では LT 大会やカラオケをして盛り上がりましたし、船外に出た時の気候もちょうど良く快適でした。何よりも参加した方たちが皆楽しそうにしていたので、企画して良かったなと思いました。イベント当日JAZUG × JAT で15周年を記念したパネルディスカッションを行いました。このセッションのみ配信のアーカイブがあります。www.youtube.com会場の様子。パネルディスカッションの後のタイムテーブルは、こちら。運営のお手伝いをしていたこともあり、じっくり聴くことはできませんでしたが、どのセッションも面白そうな内容でした。セッション資料は、Connpass にアップロードされているので、そちらをご覧いただければと。今回、Azure Travelers で有志の協賛を募ってステッカーを作りました。Tech Tiles 規格に準拠したコレクションしたくなるステッカーです。懇親会では、開催地をサイコロで決める Azure Travelers 恒例の催しがあり、次々回は石川県に決定しました。まとめ前夜祭の屋形船に始まり、イベント本編と懇親会にも多くの方に参加していただき、３次会まで楽しく過ごすことができました。お仕事でも趣味でも Azure が好きな人たちが集まって楽しめるコミュニティになるように、今後も盛り上げていきたいです。JAZUG は Tokyo Jazug Night を今後も緩く開催していきますし、次回の Azure Travelers は来年1月の仙台の旅となります。jazug.connpass.comjat.connpass.com

Japan Azure User Group 15周年イベント＆第7回 Azure Travelers 勉強会 東京の旅に参加してきました

// 追記@2025/11/03 ----------------------------------------------- ↓gooner.hateblo.jp先日の AOAI Dev Day 2025 は仕事の都合で参加できなかったのですが、しばやんさんのセッションをスライドを読んで Agentic Web アプリケーションを MCP に寄せて作るアーキテクチャが面白そうだったので試してみました。 speakerdeck.comなぜ Agentic Web アプリケーションを MCP で構築するのか？今回は、以前に Azure Durable Functions + Durable Task Scheduler を使って構築した旅行コンシェルジュの Agentic Web アプリケーションを題材にします。gooner.hateblo.jpDurable Functions の Activity を Agent に見立て、Orchestration の中で「実行すべき Activity を Function calling で決定→ Activity を呼び出し→ Activity の実行結果を合成」というロジックを実装しています。Activity の決定や実行結果の合成の処理も LLM を利用した Activity として実装しています。このアーキテクチャを MCP に寄せることで、次のようなシーケンスで先程と同様の Agentic Web アプリケーションを構築できます。MCP Server が提供する Tools を Agent に見立て、OrchestratorWorker が MCP Client となり、LLM が登録された Tools を必要に応じて実行し、最終的にユーザー向けのメッセージを合成するところまで処理してくれます。Azure Functions MCP extension や MCP Client SDK を使ってすぐにアーキテクチャを組めるので、Tools（Agent）の内部実装に注力できるLLM に任せる部分が増えることで OrchestratorWorker がシンプルになり、プロンプトを調整しやすいし、LLM の性能向上の恩恵を受やすくなるMCP Server が提供する Tools を拡張するだけで、すぐに MCP Client に反映されるMCP Server を外部公開する想定はないが、外部提供されているリモート MCP Server を組み込みやすいなどが、Agentic Web アプリケーションを MCP で構築するモチベーションです。MCP Server を実装するAzure Functions MCP extension を使って、MCP Server を実装します。PM> NuGet\Install-Package Microsoft.Azure.Functions.Worker.Extensions.Mcp -Version 1.0.0-preview.6Program.cs で、MCP のメタデータを有効化します。builder.EnableMcpToolMetadata();McpToolTriggerAttribute を使用して、Function を実装します。旅行コンシェルジュ向けの Tools をいくつか実装しますが、今回の本題とは逸れるのでロジックは決め打ちの文字列としています。public class DestinationSuggestAgent(ILogger<DestinationSuggestAgent> logger){    private readonly ILogger<DestinationSuggestAgent> _logger = logger;    [Function(nameof(GetDestinationSuggest))]    public string GetDestinationSuggest(        [McpToolTrigger("get_destination_suggest", "希望の行き先に求める条件を自然言語で与えると、おすすめの旅行先を提案します。")] ToolInvocationContext context,        [McpToolProperty("searchTerm", "string", "行き先に求める希望の条件")] string searchTerm)    {        // This is sample code. Replace this with your own logic.    }}    MCP Client を実装するMCP C# SDK を使って、MCP Client を実装します。PM> NuGet\Install-Package Azure.AI.OpenAI -Version 2.2.0-beta.5PM> NuGet\Install-Package Azure.Identity -Version 1.15.0-beta.1PM> NuGet\Install-Package Microsoft.Extensions.AI -Version 9.7.1PM> NuGet\Install-Package Microsoft.Extensions.AI.OpenAI-Version 9.7.1-preview.1.25365.4PM> NuGet\Install-Package ModelContextProtocol -Version 0.3.0-preview.3Program.cs で、ChatClient のインスタンスを DI に登録しておきます。builder.Services    .AddApplicationInsightsTelemetryWorkerService()    .ConfigureFunctionsApplicationInsights()    .AddTransient<IOrchestratorWorker, OrchestratorWorker>()    .Configure<TravelConciergeSettings>(builder.Configuration.GetSection("Function"))    .AddChatClient(_ => BuildChatClient(builder.Configuration));builder.Build().Run();static IChatClient BuildChatClient(IConfiguration configuration){    string GetRequired(string key) =>        configuration[key] ?? throw new InvalidOperationException($"{key} is required.");    var endpoint = GetRequired("Function:AzureOpenAIEndpoint");    var apiKey = GetRequired("Function:AzureOpenAIApiKey");    var modelDeploymentName = GetRequired("Function:ModelDeploymentName");    return new ChatClientBuilder(            new AzureOpenAIClient(new Uri(endpoint), new AzureKeyCredential(apiKey))                .GetChatClient(modelDeploymentName).AsIChatClient())        .UseFunctionInvocation()        .Build();}AOAI のエンドポイントやキーは、secrets.json に定義しておきます。MCP 関連の項目は後ほど解説します。{  "Function": {    "AzureOpenAIEndpoint": "https://xxx-xxx-eastus2.cognitiveservices.azure.com/",    "AzureOpenAIApiKey": "xxx",    "ModelDeploymentName": "gpt-4o",    "MCPServerEndpoint": "http://localhost:xxxx/runtime/webhooks/mcp/sse",    "MCPExtensionSystemKey": "xxx"  }}OrchestratorWorker クラスに、MCP Client を実装します。public async Task<OrchestratorWorkerResult> RunOrchestrator(Prompt prompt){    var messages = prompt.Messages.ConvertToChatMessageArray();    ChatMessage[] allMessages = [        new ChatMessage(ChatRole.System, OrchestratorWorkerPrompt.SystemPrompt),        .. messages,    ];    // Create the MCP client    // Configure it to start and connect to MCP server.    var mcpClient = await CreateMcpClientAsync();    // List all available tools from the MCP server.    _logger.LogInformation("Available tools:");    var tools = await mcpClient.ListToolsAsync();    foreach (var tool in tools)    {        _logger.LogInformation("Tool: {ToolName} - {ToolDescription}", tool.Name, tool.Description);    }    // Conversation that can utilize the tools via prompts.    var response = await _chatClient.GetResponseAsync(allMessages, new() { Tools = [.. tools] });    return new OrchestratorWorkerResult    {        Content = response.Text,        CalledAgentNames = ExtractFunctionCallNames(response.Messages)    };}上記の通り、シンプルな実装です。secrets.json に定義した MCP Server の Endpoint と MCP Extension の System Key を使った McpClient の生成が肝となります。localhost で実行する場合、MCPExtensionSystemKey はどんな値でも構いません。private async Task<IMcpClient> CreateMcpClientAsync(){    var options = new SseClientTransportOptions    {        Endpoint = new Uri(_settings.MCPServerEndpoint),        TransportMode = HttpTransportMode.Sse,        Name = "Travel Concierge MCP Server",        AdditionalHeaders = new Dictionary<string, string>        {            {"x-functions-key", _settings.MCPExtensionSystemKey}        }    };    var transport = new SseClientTransport(options);    return await McpClientFactory.CreateAsync(transport);}実行された Tools の名前は、返却されたアシスタントのプロンプトから取得できます。private List<string> ExtractFunctionCallNames(IList<ChatMessage> messages){    return messages        .Where(m => m.Role == ChatRole.Assistant && m.Contents != null && m.Contents.All(c => c is FunctionCallContent))        .SelectMany(m => m.Contents.OfType<FunctionCallContent>().Select(c => c.Name))        .ToList();}以上の手順で、MCP を使用した Agentic Web アプリケーションを構築できました。ローカルのエミュレーターで動かすAzurite が Docker Image で公開されていますので、ローカルの Docker Desktop で実行します。$ docker run --rm -it -p 10000:10000 -p 10001:10001 -p 10002:10002 -v c:/azurite:/data mcr.microsoft.com/azure-storage/azurite:3.33.0フロントエンドの Streamlit とバックエンドの Functions をローカルで実行し、チャットを入力してみます。Tools の get_destination_suggest を利用して、おすすめの旅行先が提案されています。Azure にデプロイする構築したアプリケーションを Azure Functions Flex Consumption にデプロイします。ポイントは、MCP Extension の System Key を確認する部分です。MCP Extension の System Key を含め、ローカルの secrets.json に定義していた値を App Settings に追加します。以上の手順で、MCP を使用した Agentic Web アプリケーションを Azure 上でも動かすことができます。まとめAzure Functions MCP Extension を使って、Agentic Web アプリケーションを構築してみました。これまで Function Calling を駆使して実装していた Orchestration ロジックを、LLM と MCP に委ねることで、Tools（Agent）の内部実装に集中できるメリットは大きいと感じました。一方で、Durable Task Scheduler のダッシュボードで可視化できていた可観測性が失われるため、別の手段で組み込む必要があります。また、MCP Client に登録する Tools の情報をリクエストごとに取得するのはオーバーヘッドが大きいため、MCP Server と Client を Function App として分離し、Tools の情報を永続化する仕組みも検討したいです。なお、MCP extension でトランスポートに SSE を使っていますが、もうすぐ Streamable HTTP にも対応予定です。逆に、長時間の処理や複雑なオーケストレーションが求められる Agent に関しては、Durable Functions を活用する方が適していると感じました。今回のソースコードは、こちらのリポジトリで公開しています。github.com

Azure Functions MCP extension を使用して Agentic Web アプリケーションを構築する【SSE 版】

2025年7月10日付けで、Microsoft Most Valuable Professional (MVP) アワードを再受賞しました。カテゴリは AI Platform から Microsoft Azure に戻り、サブカテゴリは Azure Application PaaS です。9 年目の受賞となります。mvp.microsoft.com昨年の主な活動内容JAZUG の14周年イベントで Azure App Service on Linux の Sidecar に Phi-3 を配置するセッションに登壇しました。gooner.hateblo.jpAzure Travelers の山形、福岡、沖縄での勉強会に参加して、ショートセッションや飛び入り LT に登壇しました。gooner.hateblo.jpgooner.hateblo.jpgooner.hateblo.jpブログでは、Azure App Servcie や Azure Functions を中心に生成 AI を活用したアプリケーション構築に関する記事を多く書きました。gooner.hateblo.jpgooner.hateblo.jp昨年に続き、MVP Global Summit にも現地参加しました。gooner.hateblo.jp今年の活動目標JAZUG と Azure Travelers の２つのコミュニティで、登壇だけでなく運営のお手伝いも継続していきたいです。15周年イベントでは、この２つのコミュニティのコラボ開催を予定しており、前夜祭として屋形船 LT 大会も企画しています。jazug.connpass.comjat.connpass.com技術領域としては、Azure App Servcie や Azure Functions を活用した Open Agentic Web なアプリケーション構築についての情報を発信できたらと思います。// 追記@2025/11/07 ----------------------------------------------- ↓// 追記@2025/11/07 ----------------------------------------------- ↑

Microsoft MVP for Microsoft Azure を再受賞しました

先月末、第6回 Azure Travelers 勉強会 愛媛の旅に参加してきました。jat.connpass.com勉強会サイボウズさんにご協力をいただき、松山オフィスをお借りして勉強会を行いました。普段は kintone セミナーを開催しているそうですが、お洒落で素敵な会場でした。JAZUG（Japan Azure User Group）四国支部のコミュニティ「しこあず」にも協力をいただき、愛媛周辺の方も現地参加されていました。今年の１月に徳島で勉強会が開催され、今後も開催を予定しているので、四国地方で Azure に関する技術を勉強したい方はぜひ参加していただければと思います。az-459.connpass.comセッションは、Go、Microsoft Fabric、azd、Azure Local、Power Platform のように Azure に関連する幅広い内容でした。毎度恒例の Azure クイズもそうですが、普段自分が関わることが少ない領域の話を聞けるのは勉強になりますし、何よりスピーカーの皆さんが楽しそうに発表する様子がよかったと思いました。私は、ショートセッションで Azure のマルチテナント アーキテクチャ設計の話をしました。お仕事で書いたホワイトペーパーの内容を解説したのですが、若干ニッチな領域で難しい内容も多かったので、時期的に Build のアップデートまとめとかの方が良かったかなーと少し後悔しました。セッション後に質問のあった認証周りの作り込みは悩ましいところです。 speakerdeck.com午前中のみ配信のアーカイブがあります。www.youtube.comランチは会場の前にあったフードコートで鯛釜飯を食べました。鯛めしには２種類あって、宇和島鯛めし（ご飯と一緒に鯛を炊く）と松山鯛めし（生の鯛を出汁と卵を絡めてからご飯にかけて食べる）があるそうです。懇親会は、五志喜で食べた 鯛めし、じゃこてん、鯛そうめんなどの愛媛の郷土料理が美味しかったです。二次会でクラフトビールを飲んで、締めに生しじみラーメンを食べました。写真は撮り忘れましたが、前夜祭の寿浬庵で食べた鰹の刺身も美味しかったです。Azure Travelers では、開催地をサイコロで決める水曜どうでしょう的なルールがあり、次々回は宮城に決定しました。愛媛観光今回は愛媛に木曜日入りして、道後温泉をキャンプ地にワーケーションしました。道後温泉つい先月にも来たような気もしますが、道後温泉駅は明治時代の洋館のような建物で、坊ちゃん列車やからくり時計などもあります。アーケードには、ガンダムマンホールがありました。大街道にはザクもあったらしいですが、見に行きそびれました。道後温泉本館道後温泉本館は国の重要文化財に指定されていて、昨年末に保存修理工事が終わったばかりです。浴衣やタオルを一式借りることができて、お茶とお茶菓子もついている三階の個室を利用しました。神の湯と霊の湯にはいることができます。道後温泉の泉質は透明で滑らかな良い湯でした。夏目漱石が湯上りにくつろいだと言われる坊ちゃんの間を見学できます。歴代の皇室の方々が訪れた御湯殿である又新殿も見学できます。本館のすぐ隣に道後麦酒館があって、風呂から上がった後に吸い込まれるように入店して湯上り IPA と鯛めしを注文しました。卵かけご飯スタイルの松山鯛めしも美味しいです。夜の道後温泉本館は、昼間とは違った雰囲気となります。道後温泉別館 飛鳥乃湯泉別館の飛鳥乃湯泉は、飛鳥時代の建築様式を取り入れた湯屋となっています。二階の個室を利用しましたが、お風呂は１つだけで内湯と露天がありました。夜の飛鳥乃湯泉は、こんな雰囲気です。伊佐爾波神社道後温泉にある伊佐爾波神社に行きました。階段がしんどそうだなと思いましたが、実際に登ってみるとそうでもなかったです。しまなみ海道しまなみ海道に向かう途中、伊豫水軍でランチを食べました。活ハギのお造りと蛸めしが美味しかったです。天気が良かったので、亀老山展望公園からの眺望は素晴らしかったです。耕三寺しまなみ海道の途中の島である生口島の耕三寺に立ち寄りました。未来心の丘という大理石のモニュメントがある庭園があり、SNS 映えしそうなスポットでした。帰りの飛行機の時間になったので、ここで松山まで引き返すことにしました。広島県尾道市まで来たので、帰りは広島経由にすればよかったかもしれない。まとめ第6回 Azure Travelers 勉強会 愛媛の旅は、今回も楽しいイベントでした。会場を提供してくださったサイボウズさんと参加者の皆様、ありがとうございました。次回は 10/4 に東京開催を予定しています。最近運営側のお手伝いもさせてもらっているで、前夜祭で楽しそうなイベントを企画中です。

第6回 Azure Travelers 勉強会 愛媛の旅に参加してきました

今年もシアトルで Microsoft Build 2025 に参加してきました。build.microsoft.comBuild 2025 でアナウンスされた内容は、このあたりの記事で説明されています。Microsoft 公式ドキュメントブチザッキ（Day1、Day2）この記事では、現地参加の雰囲気や個人的に感じたことをお伝えしていきます。Registration会場は、シアトルにある Seattle Convention Center です。昨年は新しい方の Convention Center Summit でしたが、今年は懐かしい方の Convention Center でした。Keynote：Day1キーノートは、今年も MVP Priority Seat が用意されていたので、前から２列目でした。Imagine Cup の表彰が終了後、キーノートが始まりました。Satya Nadella が GitHub Copilot のデモする様子を目の前で見ることができました。今回の Build では、Agent を活用したシステムをどのように作るのかという話がメインで、基盤は用意したので何を作るのかは参加者の皆さんが考えてほしいというメッセージを受け取りました。どのように作るのかについては、大きく２つの内容がありました。Agentic DevOpsGitHub Copilot Coding Agent、Azure AI Foundry、Azure SRE Agent などを活用して開発ライフサイクルをモダナイゼーションしていく世界観。Building the open agentic webMCP と A2A サポートや NLWeb によって、自然言語による対話型インターフェースを導入したアプリの作り方を標準化していく世界観。Keynote：Day2Day2 のキーノートは、MVP Priority Seat のおかげで最前列を確保できました。この規模のカンファレンスでの最前列はテンションが上がりました。今日も Satya Nadella が話すのか？と思ったら Jay Parikh でした。容姿を Satya に寄せすぎでは？と思ったり（笑）キーノートとは言いつつも、Day1 キーノートの詳細な話でブレイクアウトに近い内容でした。Breakoutキーノートでの発表以外で気になったアップデートは、下記の通り。App ServiceNew App Service Premium v4 planハイパフォーマンスで低コスト、日本リージョンに来たらすぐに使いたい。2-zone Availability Zone support is now generally availableAZ が最小２インスタンスから構成できるようになった。今までは３インスタンス以上が必須だったので、コスト削減できる。    FunctionsAzure Functions integration with Azure AI Foundry Agent ServiceAI Foundry の Agent Service 周りはまったく触っていなかったので、これを機にキャッチアップしておきたい。Azure OpenAI Trigger and Bindings preview updateMI 対応や Comos DB のベクター検索対応などのアップデート。Azure Functions on Azure Container AppsACA でマイクロサービスを作る時にインフラを統一できて良さそう。    Container AppsPublic Preview: Durable task scheduler supportDurable Task Scheduler が使えるようになったので、試してみたい。    Cosmos DBFull-text and Hybrid Searchフルテキストとハイブリッドの検索が GA。Fleet Managementアカウント間で RU を共有できる。マルチテナント アーキテクチャでの使いどころを検証したい。    その他Expose REST APIs as MCP servers with Azure API ManagementAPI Management で MCP サーバーを公開できる。Agentic retrieval with AI SearchRAG の精度向上のために作り込んでいたロジックを AI Search がマネージドで対応してくれる。Managed Redis is now generally available従来の Redis よりもハイパフォーマンスで低コスト。今後はこちらを使う。Azure DevOps with GitHub RepositoriesAzure DevOps と GitHub を組み合わせて使えるようになる。    会場の様子Convention Center には各フロアに部屋があって、自由に聞きたいセッションを選べます。昨年の会場と比較しても、建物が２つある広い会場でセッション間の移動が大変でした。HUB はパートナーのブースやシアターセッションがある広い会場でした。エキスパートのブースもあったので、Azure Functions チームに Dutable Task Scheduler を Flex Consumption でも使いたいとフィードバックしておきました。MVP と RD の名前が書かれた Wall もあって、自分の名前を発見して安心しました。ビルド飯は、こんな感じでした。過去参加したカンファレンスの中で一番美味しかった気がします。スターバックスコーヒーは飲み放題です。今回の戦利品。ウォーターボトルとTシャツ、Tシャツは3種類から選べました。Microsoft Build and AMD Celebration最終日のパーティ会場は、昨年と同じく NFL のシアトル・シーホークスの本拠地である Lumen Field でした。来年の FIFAワールドカップ会場のひとつなので、ここでフットサルできる機会は貴重でした。Microsoft Campus今回一緒に行った同僚を案内するため、Redmond にある Microsoft 本社に行きました。Visitor Center だけでなく、East Campus の新しい建物やツリーハウスも散策しました。まとめMicrosoft Build 2025 にシアトルで現地参加してきました。gooner.hateblo.jp

Microsoft Build 2025 に現地参加してきました

Global Azure 2025 に参加して、Azure Load Testing を使って Azure Functions Flex Consumption の HTTP Trigger Function のパフォーマンスとコストを最適化する話をしてきました。jazug.connpass.comセッション登壇者が当日病欠で枠が空いて急遽の登壇になりましたが、数日前に東日本リージョンで使えるようになったばかりのホットな話題を思いがけず話せることになりました。www.youtube.com speakerdeck.comイベントの数日前に書いたブログの内容をデモを交えて話したので、公開しているスライドに内容はありません。話した内容は、こちらのブログを参照してください。gooner.hateblo.jpX（Twitter）での反応は比較的好評で楽しんでいただけたようですし、今後は Azure Functions を Linux で使う場合は Flex Consumption を選択しておけば良いと思います。今回の Global Azure は、GitHub Copilot ハンズオンも同時開催でした。自分が登壇する Room C+D（メインセッション１）にずっといたので、後ほど他の部屋のセッションも Youtube で確認しておきたいと思います。www.youtube.comwww.youtube.com

Global Azure 2025 で Azure Functions Flex Consumption の話をしてきました

Microsoft Azure の初学者向けの書籍「Azureの知識地図 〜クラウドの基礎から実装・運用管理まで」が出版されました。著者の土田さんから書籍をご恵贈いただいたので、早速読んでみました。Azureの知識地図 〜クラウドの基礎から実装・運用管理まで作者:土田 純平,永田 祥平,栗本 美穂,石塚 航希,乃村 翼,草谷 一輝,酒見 一幸技術評論社Amazon書籍情報目的Microsoft が公開している Azure の公式ドキュメントに書いてあることがわかるようになる対象とする読者今までパブリッククラウドを使ったことがない方Azure の基礎と全体像を体系的に学びたい方目次第1章　クラウドサービスとAzureの基礎第2章　AzureのIaaSを知ろう第3章　AzureのPaaSを知ろう第4章　Azureでシステムを構築・運用しよう第5章　Azureの知識の深め方を知ろう    どんな書籍なのか良かったところこの書籍は、ゼロから Azure を学びたい人が全体像を体系的に理解できる構成になっています。第1章でサブスクリプションやリソースグループなどの概念（用語）を解説したうえで、第2章以降から IaaS や PaaS の代表的なサービスを紹介する流れになっており、広さと浅さが丁度いいバランスだと思いました。Azure 固有のサービス名と専門用語の関連が視覚的に整理されたキーワードマップ歴史的背景からの表記ゆれ（App Service と Web App）や日本語翻訳特有の分かり難さ（関数アプリと関数の違い）の説明があり、公式ドキュメントを意識していることAzure サービスの機能説明だけでなく、App Service プランの分け方、サービスエンドポイントとプライベートエンドポイントの使い分けなどの実用的なコラム正直、公式ドキュメントには取っ付き難くさがあり、内容を理解できるようになるまでには、ある程度の知識や経験が必要だと感じています。難しかったところ第4章では、Cloud Adoption Framework（CAF）と Well-Architected Framework（W-AF）に則ったアーキテクチャ設計を解説する節がありますが、対象とする読者には難易度が高そうだと感じました。アーキテクチャセンターのシナリオ紹介も含めて、第5章で軽く紹介する程度でもよかったかもしれません。次のステップに向けて第5章にあるように、次のステップとして認定資格を取得するのがお勧めです。この書籍を読み終えた読者は、受験対策として公式ドキュメントを読んで理解を深めることができるようになっているはずです。巻末の MCP ロードマップが分かりやすいので、まずは AZ-900 からチャレンジしましょう。（余談ですが、弊社でもこのような MCP ラーニングパスを定義しています。）まとめこれから Azure を初めて学ぶ方にお勧めするとしたらこの書籍です。この春入社した新入社員に読んでもらうと良さそうです。最後にこの書籍を出版した経緯を著者の土田さんがまとめているので、こちらもご参照ください。zenn.dev

書籍「Azureの知識地図 〜クラウドの基礎から実装・運用管理まで」の感想

Azure Functions Flex Consumption が東日本リージョンで使えるようになりました。techcommunity.microsoft.comFlex Consumption とはFlex Consumption は、Azure Functions に新しく追加されたホスティングオプションで、刷新されたバックエンド（Legion）による高速なスケーリングが最大の特徴です。さらに、従来の Consumption Plan では対応していなかった VNET Integration にも対応しています。詳細は公式ドキュメントを参照していただくとして、パフォーマンスとコストに影響するスケーリングの設定を補足します。スケーリングの動作Flex Consumption は Function 毎に独立したインスタンスでスケーリングされますが、下記の３種類の Trigger については同じインスタンスでグループとしてまとめてスケーリングされます。HTTP triggersBlob storage triggers(Event Grid-based)Durable Functionsインスタンスのメモリサイズ現時点では、512 MB と 2,048 MB と 4,096 MB の 3 種類のサイズが提供されています。インスタンス毎のコンカレンシーコンカレンシーとは、インスタンスが処理できる並列リクエストの数です。Flex Consumption では、HTTP Trigger に新しい同時実行性が導入されました。公式ブログから引用既定のコンカレンシーは、下記の通りです。基本的には既定値を使いますが、パフォーマンスとコストを最適化する場合、この値を調整することになります。公式ドキュメントから引用    インスタンスの最大スケーリング数既定ではインスタンス数 0 台からスケーリングが開始され、最大数は 40 ～ 1,000 台まで設定できます。コールドスタート削減Flex Consumption にはコールドスタート削減として Always-ready が導入されており、常時実行させておくインスタンス数を設定できます。Performance Optimizer とはAzure Functions には、Azure Load Testing を使った Performance Optimizer が提供されており、パフォーマンスとコストの適切なバランスを見つけやすくなっています。なお、Azure Load Testing の Test Profile を実行するためには、Azure Functions の Access control（IAM）で Website Contributor ロールにアカウントを追加する必要があります。テストの設定と実行それでは実際に Performance Optimizer を使って HTTP Trigger Function のパフォーマンスとコストの最適化を分析します。前準備Azure Functions Flex Consumption を東日本リージョンに作成します。Runtime Stack には、.NET9 を選択しました。Visual Studio で HTTP Trigger の Function を作成し、1 秒間のスリープを入れました。[Function(nameof(Function1))]public async Task<IActionResult> Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] HttpRequest req){    _logger.LogInformation("C# HTTP trigger function start.");    await Task.Delay(1000);        _logger.LogInformation("C# HTTP trigger function end.");    return new OkObjectResult("Welcome to Azure Functions Flex Consumption!");}この Function App を Visual Studio から Azure にデプロイします。Performance Optimizer で Test Profile を作成するテストプランには、インスタンスのメモリサイズを 2,048 MB と 4,096 MB、コンカレンシーを 8、16、32 の組み合わせで 6 パターンを設定します。テスト対象には、先ほどデプロイした HTTP Trigger Function を設定します。3 分間にわたって10 ユーザーからリクエストを投げるミニマムな設定にしました。Test Profile の作成が完了するとテストが開始されるので、完了まで待ちます。テスト結果の分析Performance Optimizer のテスト結果を確認します。メモリサイズ 4,096 MB と コンカレンシー 32 の構成が最もスループットが高い結果となりました。どのくらいのインスタンス数がスケーリングされているのかを確認します。メモリサイズ 2,048 MB とコンカレンシー 8 の構成が最大 8 台で、それ以外の構成は最大 10 台でした。requests| where timestamp >= datetime(2025-5-7T07:50:00.0000000Z) and timestamp <= datetime(2025-5-7T09:50:00.0000000Z)| summarize dcount(cloud_RoleInstance) by bin(timestamp, 1s)| render columnchart最もスループットが高かったメモリサイズ 4,096 MB とコンカレンシー 32 の構成のみを確認します。開始 1 秒で 10 台まで高速にスケーリングしていることが分かります。Flex Consumption の Functions メトリクスのうち、OnDemandFunctionExecutionUnits メトリクスを確認します。mb-milliseconds 単位で測定されるので分かりにくいですが、インスタンスがアクティブな時間を表しています。右端の山（メモリサイズ 4,096 MB と コンカレンシー 32）の 800M が最もスループットが高い構成です。パフォーマンス要件次第ですが、2 番目にスループットが高い左端の山（メモリサイズ 2,048 MB と コンカレンシー 8）が要件を満たしていれば、600 M 弱の実行時間に相当するコストで済むため、この構成も選択肢に含めて検討することができます。まとめAzure Load Testing を使って Azure Functions Flex Consumption の HTTP Trigger のパフォーマンスとコストを最適化する方法を試してみました。Flex Consumption は、実行時に使用されたメモリとコンピューティング時間に基づいて課金されます。メモリ設定を高くすると実行時間は速くなりますが、リクエストあたりのコストは高くなります。逆に、メモリ設定を低くするとコストは削減されますが、実行時間は長くなる可能性があります。このトレードオフに対して、Performance Optimizer を活用することで、コストとパフォーマンスの最適なバランスを見つけやすくなります。

Azure Load Testing を使って Azure Functions Flex Consumption の HTTP Trigger のパフォーマンスとコストを最適化する

先月、Azure Functions の Durable Task Scheduler（DTS）が public preview になりました。今回は DTS を使って Multi Agent アプリケーションを構築してみます。techcommunity.microsoft.comなぜ Durable Functions で Multi Agent を構築するのか？昨年に話題となった Anthropic の Building effective agents の記事を読むと、エージェントの定義が Durable Functions のパターンと似ていることが分かります。blog.cgillum.techLangGraph や AutoGen などの多くのマルチエージェント向けフレームワークが存在するなかで、個人的な推しは Durable Functions によるマルチエージェント構築です。Microsoft の土田さんが Durable Functions で Orchestrator-Workers パターンを実装するためのテンプレート プロジェクトを公開しています。github.com今回は、このテンプレートから最低限の実装のみを抜き出したアプリケーションを作って試してみます。フロントエンドのチャット画面は Streamlit、バックエンドの API は Durable Functions、LLM は Azure OpenAI Service の gpt-4o を採用しています。Durable Task Scheduler とはDurable Functions は、GA して5～6年が経つ成熟したサービスではありますが、マルチエージェントのユースケースで使われることで、より優れたスケーラビリティ（LLM からのレスポンスに時間がかかりやすいため）可観測性の向上（オーケストレーターから実行されるアクティビティが LLM によって決定されるため）が要求される背景を受けて、Durable Task Scheduler が登場しました。learn.microsoft.comDurable Functions のストレージプロバイダー（Azure Storage、MSSQL、Netherite）に追加される４つめのプロバイダーという位置づけになります。DTS は Durable Functions だけではなく、専用の SDK を使うことで Azure Container Apps や Azure App Service などのバックエンドにも利用できます。Durable Task Scheduler への対応公式ドキュメントのクイックスタートに従って実装すれば OK です。learn.microsoft.comまずは、 DTS の NuGet パッケージをインストールします。PM> NuGet\Install-Package Microsoft.Azure.Functions.Worker.Extensions.DurableTask.AzureManaged -Version 0.4.2-alpha合わせて、Microsoft.Azure.Functions.Worker.Extensions.DurableTask パッケージのバージョンも 1.2.2 以降に更新しておきます。次に、host.json に extensions の構成を追加します。{  "extensions": {    "durableTask": {      "hubName": "%TASKHUB_NAME%",      "storageProvider": {        "type": "azureManaged",        "connectionStringName": "DURABLE_TASK_SCHEDULER_CONNECTION_STRING"      }    }  }}最後に、local.settings.json に DURABLE_TASK_SCHEDULER_CONNECTION_STRING と TASKHUB_NAME の環境変数を追加します。{  "IsEncrypted": false,  "Values": {    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",    "AzureWebJobsStorage": "UseDevelopmentStorage=true",    "DURABLE_TASK_SCHEDULER_CONNECTION_STRING": "Endpoint=http://localhost:8080;Authentication=None",    "TASKHUB_NAME": "default"  }}以上の手順で、Durable Functions を DTS に対応させることができます。ローカルのエミュレーターで動かすDTS のエミュレーターが Docker Image で公開されていますので、ローカルの Docker Desktop で実行します。docker run --rm -it -p 8080:8080 -p 8082:8082 mcr.microsoft.com/dts/dts-emulator:v0.0.5フロントエンドの Streamlit とバックエンドの Functions をローカルで実行し、チャットを入力してみます。http://localhost:8082/ にアクセスして、DTS のダッシュボードを確認します。オーケストレーションの詳細では、タイムラインのビューを確認できます。さらに、シーケンスのビューでは、視覚的にエージェントの呼び出し履歴を確認できるので、Durable Functions を運用する際の可観測性を大きく向上できます。なお、ダッシュボードからはオーケストレーションの一時停止や再開などアクションも実行できます。Azure にデプロイするローカルで動作確認できたので、Azure Portal で DTS を構成した Azure Funcitons をデプロイします。現時点では DTS を利用できるリージョンが限定されており、ホスティングオプションも Functions Premium Plan と App Service Plan のみです。デプロイが完了したので、DTS の Task Hub にダッシュボードを利用するための Access Control を設定します。Durable Task Data Contributor のロールにメンバーを割り当ててあげましょう。あとは、従来通りに Visual Studio から Azure Functions にデプロイします。（本題から逸れるので詳細は割愛します。）チャットを入力すると、Azure Portal の DTS のダッシュボードからオーケストレーションの実行履歴を確認できます。まとめAzure Functions Durable Task Scheduler を使用して Multi Agent アプリケーションを構築してみました。Japan East および West のリージョンFlex Consumption PlanGA に向けてこの２つを対応してもらえるようにフィードバックしています。今回のソースコードは、こちらのリポジトリで公開しています。github.com

Azure Functions Durable Task Scheduler を使用して Multi Agent アプリケーションを構築する

この件は GitHub Actions の仕様であり、ネットを探すとたくさんの記事がありますが、今回のユースケースでの対応をまとめておきます。背景弊社では、各事業部が別サイトで技術ブログを書いているため、所属するエンジニアの個人技術ブログも含めて一覧表示するキュレーションサイトを作成しています。tech-blog-hub.nextscape.netこのアプリケーションでは、ビルド時に各ブログサイトから RSS を取得する作りになっているので、GitHub Actions のワークフローを cron ジョブで毎日デプロイしています。構築した際の話については、こちらの記事を参照してください。gooner.hateblo.jp課題この cron ジョブで毎日デプロイしているワークフローが 60 日で無効化されてしまい、キュレーションサイトに表示されるブログが最新化されない課題が発生しました。公式ドキュメントを読むと、下記のような仕様に関する記載がありました。パブリックリポジトリでは、60日間にリポジトリにアクティビティがなかった場合、スケジュールされたワークフローは自動的に無効化されます。このアプリケーション自体の更新は殆どないので、リポジトリが更新されずとも継続的に cron ジョブのワークフローを実行させたいです。対応GitHub の友人に相談したところ、契約プランや設定で変更できるものではなく、Marketplace に下記のようなライブラリがあることを教えてもらいました。github.comGitHub API で対象ワークフローを有効化するワークフローダミーのコミットを作るワークフローダミーのコミットを作るのは気が進まなかったのと、GitHub API を呼ぶだけならライブラリを使って依存関係を作るまでもないと考え、上記１のワークフローをシンプルに実装しました。name: Keepalive Workflowon:  schedule:    - cron: '0 5 1,15 * *'  workflow_dispatch:concurrency:  group: keepalive  cancel-in-progress: falsejobs:  keepalive:    permissions:      actions: write    runs-on: ubuntu-latest    steps:      - name: Re-enable workflow        env:          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}          GH_REPO: ${{ github.repository }}        run: |          gh workflow enable keepalive.yml          gh workflow enable <無効化させたくないワークフローのファイル名>.ymlポイントは、対象ワークフローが既に有効の場合でも、無効になるまでの期限が延長される点です。自分自身も含め、常に有効化したい YAML ファイル名を指定します。まとめGitHub Actions のワークフローが 60 日後に無効化されないように、GitHub API で対象ワークフローを有効化するワークフローを作ってみました。このワークフローを運用してしばらく様子を見てみたいと思います。最後に、今回の Pull Request はこちらになります。github.com

GitHub Actions のワークフローが 60 日後に無効化されないようにする

先週末、第5回 Azure Travelers 勉強会 沖縄の旅に参加してきました。jat.connpass.com勉強会FOURSEAS さんの全面協力のもと、沖縄市のコザにある Microsoft Base Okinawa で行われました。4seas.vc正確には Microsoft Base Okinawa の下の階にある KOZA Startup Arcade のイベントスペースが会場でした。沖縄のスタートアップ企業やエンジニアが集まって、新たなイノベーションを生み出すコミュニティを築く場として使われているそうです。www.koza.rocksセッションは、生成 AI とセキュリティに関連する内容が多かったです。今回から恒例となる Azure クイズも面白かったです。普段使わないサービスの問題は難しいなと思いました。私自身は、飛び入りで LT に参加して Durable Task Scheduler の紹介をしました。Multi Agent で Durable Functions を使う場面が増えるので、スケーラビリティと可観測性を向上できることに期待しているという内容を話しました。午前中のみ配信のアーカイブがあります。www.youtube.comランチは地元の方のお勧めの大衆食堂ミッキーで食べたフーチキナー定食（からし菜と麩の沖縄風炒め）が美味しかったです。懇親会は、二代目 串カツ劇場→天理スタミナラーメン→コザ麦酒工房をはしご酒して楽しい時間を過ごすことができました。嘉手納基地が近いため、夜のコザは異国情緒あふれる雰囲気の街なのが印象に残りました。Azure Travelers では、開催地をサイコロで決める水曜どうでしょう的なルールがあり、次々回は東京に決定しました。沖縄観光勉強会以外にも、いろいろと観光して沖縄を満喫しました。孤独のグルメ 聖地巡礼2023年の大晦日スペシャルで登場した沖縄料理「ちまぐー」に行きました。ちまぐ定食は、豚足のから揚げが甘辛く味付けされてご飯に合う美味しさでした。古宇利大橋ちまぐーからほど近い古宇利大橋に行きました。海が奇麗でいい景色だったのですが、宮古島に行った後のためか感動が薄かった気がします。美ら海水族館数年ぶりに美ら海水族館に行きました。ジンベエザメのいる巨大な水槽は迫力がありますし、悠然と泳ぐ姿が印象的でした。海ぶどうが生えている姿を初めて見ました。美浜アメリカンビレッジ帰りの飛行機まで時間があったので、北谷のアメリカンビレッジに立ち寄りました。この時期に何故クリスマス仕様なのかはよく分かりませんでした。まとめAzure Travelers のコミュニティは３回目の参加で、今回も楽しいイベントでした。欲を言えば、開催地の地元の人に多く参加してもらえるといいなと思いました。前乗りして宮古島でワーケーションした話は、こちらの記事を参照してください。gooner.hateblo.jpおまけ沖縄で食べた美味しかったもの。BLUE SEAL の紅イモTHE ORION BEER DINING のビールゆうなんぎいのラフテーJACK'S STEAK HOUSE のテンダーロインステーキ花人逢のピザステーキハウス 88 の特選赤肉ステーキ

Toshiyuki Hara

Global Azure 2026 に参加してきました

MVP Summit 2026 に参加してきました

Azure Static Web Apps の自動ビルドがタイムアウトしやすくなった状況に対応した件

Azure Front Door で App Service を外部攻撃から保護する

Azure App Service と Application Insights をプライベートネットワークで利用する

Azure App Service と Key Vault をプライベートネットワークで利用する

Azure App Service と SQL Database をプライベートネットワークで利用する

第8回 Azure Travelers 勉強会仙台の旅に参加してきました

GitHub Copilot App Modernization を使って Azure App Service のアプリを .NET10 にマイグレーションする

2025 年振り返り

Microsoft Ignite 2025 に現地参加してきました

Azure Functions MCP extension を使用して Agentic Web アプリケーションを構築する【Streamable HTTP 版】

Japan Azure User Group 15周年イベント＆第7回 Azure Travelers 勉強会東京の旅に参加してきました

Azure Functions MCP extension を使用して Agentic Web アプリケーションを構築する【SSE 版】

Microsoft MVP for Microsoft Azure を再受賞しました

第6回 Azure Travelers 勉強会愛媛の旅に参加してきました

Microsoft Build 2025 に現地参加してきました

Global Azure 2025 で Azure Functions Flex Consumption の話をしてきました

書籍「Azureの知識地図〜クラウドの基礎から実装・運用管理まで」の感想

Azure Load Testing を使って Azure Functions Flex Consumption の HTTP Trigger のパフォーマンスとコストを最適化する

Azure Functions Durable Task Scheduler を使用して Multi Agent アプリケーションを構築する

GitHub Actions のワークフローが 60 日後に無効化されないようにする

第5回 Azure Travelers 勉強会沖縄の旅に参加してきました

Global Azure 2026 に参加してきました

MVP Summit 2026 に参加してきました

Azure Static Web Apps の自動ビルドがタイムアウトしやすくなった状況に対応した件

Azure Front Door で App Service を外部攻撃から保護する

Azure App Service と Application Insights をプライベートネットワークで利用する

Azure App Service と Key Vault をプライベートネットワークで利用する

Azure App Service と SQL Database をプライベートネットワークで利用する

第8回 Azure Travelers 勉強会 仙台の旅に参加してきました

GitHub Copilot App Modernization を使って Azure App Service のアプリを .NET10 にマイグレーションする

2025 年振り返り

Microsoft Ignite 2025 に現地参加してきました

Azure Functions MCP extension を使用して Agentic Web アプリケーションを構築する【Streamable HTTP 版】

Japan Azure User Group 15周年イベント＆第7回 Azure Travelers 勉強会 東京の旅に参加してきました

Azure Functions MCP extension を使用して Agentic Web アプリケーションを構築する【SSE 版】

Microsoft MVP for Microsoft Azure を再受賞しました

第6回 Azure Travelers 勉強会 愛媛の旅に参加してきました

Microsoft Build 2025 に現地参加してきました

Global Azure 2025 で Azure Functions Flex Consumption の話をしてきました

書籍「Azureの知識地図 〜クラウドの基礎から実装・運用管理まで」の感想

Azure Load Testing を使って Azure Functions Flex Consumption の HTTP Trigger のパフォーマンスとコストを最適化する

Azure Functions Durable Task Scheduler を使用して Multi Agent アプリケーションを構築する

GitHub Actions のワークフローが 60 日後に無効化されないようにする

第5回 Azure Travelers 勉強会 沖縄の旅に参加してきました

第8回 Azure Travelers 勉強会仙台の旅に参加してきました

Japan Azure User Group 15周年イベント＆第7回 Azure Travelers 勉強会東京の旅に参加してきました

第6回 Azure Travelers 勉強会愛媛の旅に参加してきました

書籍「Azureの知識地図〜クラウドの基礎から実装・運用管理まで」の感想

第5回 Azure Travelers 勉強会沖縄の旅に参加してきました