APC 技術ブログ

また、そもそもハブスポーク構成って何？という方はこちらもおすすめです。

また、今回はハブ側の管理権限を持つのはプラットフォームチーム、スポーク側の管理権限を持つのはアプリケーションチームという前提でお話をしたいと思います。
そのため、プラットフォームチームがガバナンスを効かせつつ、アプリケーションチームはシステムが正常に稼働するために必要な許可ルールなどの情報をプラットフォームチームに提供するイメージです。

Azure Firewall ポリシー周りの基本知識

続いて、Azure Firewall ポリシーの設計を理解するうえで最低限必要な知識についても説明したいと思います。
そんなこと知ってるよ！という方は読み飛ばしていただいて構いません。

FirewallインスタンスとFirewall ポリシーの役割について

Azure Firewallには、主要のコンポーネントとしてFirewall ポリシーとFirewallインスタンスが存在します。
Firewallポリシーはルールのリストであり、Firewallインスタンスが実際にルールの処理を行うという間柄です。

また、仕様上Firewallインスタンスには一つのFirewallポリシーしか適用することができませんが、複数のFirewallポリシー同士で親子関係を作ったうえでFirewallインスタンスに子のFirewallポリシーを適用することで、継承元である親ポリシーのルールも自動的に評価されます。
評価順序は 親ポリシー → 子ポリシー となり、親で拒否された通信は子で許可することはできません。これにより、全社的なセキュリティポリシーを強制することが可能になります。

Firewall ポリシーの構成について

Firewall ポリシーには、Rule Collection Group、Rule Collection、Ruleの三種類の階層が存在します。
図にするとこんな感じです。

それぞれ簡単に説明します。

Rule Collection Group（RCG）

一番上の階層で、1個以上のRule Collectionを持ちます。
優先度の概念を持ち、番号が少ないほど先に評価されます。

Rule Collection（RC）

RCGの中に存在し、1個以上のRuleを持ちます。
RCGと同様に優先度の概念を持ち、番号が少ないほど先に評価されます。

Rule Collectionには、トラフィックの種類（DNAT / Network / Application）とアクションの種類(Allow / Deny)によって合計5つの種類に分類されます。

分類 (ルール種別 - アクション)	説明
DNAT	Azure Firewall が持つパブリック IP アドレスに届いたトラフィックを、プライベート IP アドレスに変換するためのルール
Network - 許可	IP アドレス (L3/L4) ベースの通信を許可するためのルール
Network - 拒否	IP アドレス (L3/L4) ベースの通信を拒否するためのルール
Application - 許可	ドメイン・URL (L7) ベースの通信を許可するためのルール
Application - 拒否	ドメイン・URL (L7) ベースの通信を拒否するためのルール

Rule

RCの中に存在し、具体的なルールの内容が定義されています。
優先度の概念は持たないリスト形式になっており、上のRuleから順番に評価されます。

評価順序について

最後に評価順序についてまとめます。
押さえておくべきポイントは、大きく分けて三つです。

Firewall ポリシーの評価順序の法則まとめ

①必ずDNATルール、Networkルール、Applicationルールの順番で評価を行う
②RCGの優先度の番号が小さい順、その次にRCの優先度の番号が小さい順で評価を行う。
③親子関係を持っているポリシーの場合は、親ポリシーの評価が優先される。

ここは非常に重要なポイントであり混乱しやすいポイントでもあるため、ぜひ以下のページを読んでいただき理解していただきたいと思います。
（ここで詳しく説明すると文章量が多くなりすぎてしまうため、割愛します）

Azure Firewall ポリシーの設計について

ここでようやく、今回作成したAzure Firewall ポリシーの設計について触れていきます。

まず、親子関係を作るポリシーは同一リージョンである必要があるため、Azure Firewall ポリシーは同じリージョンに2種類作成し、親子関係（継承）を設定します。
それぞれ以下のような役割でポリシーを分けています。

親ポリシー（Parent Policy）
- 役割: 全社的なガバナンス、セキュリティベースラインを適用する際に利用。
- 適用範囲: 全システム共通の許可・拒否ルール。
子ポリシー（Child Policy）
- 役割: 各システム固有の通信要件への対応。
- 適用範囲: 各スポーク内のシステムに必要な個別ルール。

そのうえで、以下についてそれぞれ説明します。

親ポリシーの設計方針
子ポリシーの設計方針
ポリシー共通: RC内部の優先度とルール

1. 親ポリシーの設計方針

親ポリシーは「全社共通で遵守すべき通信要件」について定める必要があるため、以下の4つの RCG を用意しました。
まずはこの4種類から始めてみて、別カテゴリを増やす必要性を感じたら増やすとよいでしょう。

RCG	目的	RCの分割単位
セキュリティ	セキュリティ上、アクセスさせないIPやドメインのブロック	脅威の種類ごと
共通基盤	各種ワークロードが稼働するために必要なアクセス先へを許可するルールなど、全社的に必要な通信	ワークロードの種類ごと
運用監視	監視エージェント、バックアップ、ログ転送などの通信	ツールごと
オンプレ環境	全社共通で接続が必要なオンプレミスリソースへの通信	接続先環境ごと

親ポリシーの優先度範囲

親ポリシーはシンプルに 100 刻みで設定します。

RCG	優先度
セキュリティ	100
共通基盤	200
運用監視	300
オンプレ環境	400

2. 子ポリシーの設計方針

子ポリシーは、各スポーク（システム）ごとの要件に関連した設定を保持します。
そのため以下のように、スポークごとにRCGを作成して管理していきます（スポークの数=RCGの数）。

スポークその1: 部門Aのシステム①本番環境
スポークその2: 部門Aのシステム①開発環境
スポークその3: 部門Bのシステム①開発環境
スポークその4: 部門Bのシステム②開発環境

子ポリシーの優先度範囲

子ポリシーはシステム数が増えるため、桁を増やして管理します。まず、部門単位で大きな枠を確保します。以下は一例です。

Group種類	Priority範囲
部門A	1000 ~ 1999
部門B	2000 ~ 2999
部門C	3000 ~ 3999

その上で、各枠の中で 「スポーク（環境）」単位 に数値を割り当てます。
以下は一例です。

Group種類	設定値の例
システム① 開発環境	1001
システム① 検証環境	1002
システム① 本番環境	1003
システム② 開発環境	1004
システム② 検証環境	2001 (部門Bの先頭)
システム② 本番環境	2002

このように枠を決めておくことで、将来システムが増えた際も設計の手戻りが少なくなります。

【注意】子ポリシーの設計上発生するルールの抜け穴を防ぐ

子ポリシーで個別にルールを書かせると、どうしても「とりあえず Any で通しちゃえ」という甘い設定が発生しがちです。また、優先度の設計上、もしも高い優先度を持つRCGで緩いルールを書かれると、後続のルールが無効化されるリスクがあります。
それを防ぐため、以下のガイドラインを制定し、可能であればAzure Policyで操作を禁止します。

Source (送信元): *, Any, 0.0.0.0/0 の使用を禁止。必ず送信元を絞らせる。
Destination (宛先): *, Any, 0.0.0.0/0 の使用は許可するが、その場合は 宛先プロトコル（ポート）での * 指定を禁止 する。（「どこからでも、どこへでも、全ポート許可」というルールを作らせない）

運用ルールをドキュメントに書くだけでなく、Azure Policy でシステム的に縛ることで、長期間運用してもポリシーが崩壊しないように工夫しています。

3. ポリシー共通: RC内部の優先度とルール

RCGの中にある、個々のRCについては、アクション種別ごとに優先度を定義することで管理を楽にします。

ルール種別	アクション	Priority範囲
DNAT	-	1000 ~ 1999
Network	Deny	2000 ~ 2999
Network	Allow	3000 ~ 3999
Application	Deny	4000 ~ 4999
Application	Allow	5000 ~ 5999

ポイント： * 明示的な Deny ルールを Allow よりも高い優先度（小さい数値）に設定することで、意図しない許可を防ぎます。 * Azure Firewall のルール処理ロジックとして、DNAT → Network → Application の順に評価されるため、この特性と合わせて設計する必要があります。

おわりに

あくまでも今回の設計は一例です。
ハブスポーク構成や組織の特性によってベストな設計は変わるため、グループの切り方や優先度設計は組織の要件に合わせて自由に変更いただくのが良いと思います。
ただ、どんな構成にしろ大切なのは「今後の運用・拡張性までしっかり考えられた構成になっているか？」という視点を忘れないことです。

本ブログをきっかけに、Azure Firewallの構成について考えてみるきっかけにしていただけたら大変うれしく思います。ぜひこれを機会に、Azure Firewallに触れてみてください。

ここまでお読みいただき、ありがとうございました。

ACS事業部のご紹介

私達ACS事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering、AI駆動開発支援などを通して、攻めのDX成功に向けた開発者体験・開発生産性の向上・内製化のご支援をしております。

www.ap-com.co.jp また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。 www.ap-com.co.jp

本記事の投稿者
青木平：ウイスキーと柔道が好きなエンジニアです。
Kubestronaut/Microsoft Top Partner Engineer 2025

2025-12-04

自然言語でAzureを操作！Azure MCP Server 構築＆使ってみたレポート

Azure MCP Server Azure AI

はじめに

こんにちは。クラウド事業部の田代です。
今回はAzure MCP Serverを構築して、Azureのリソースを操作していこうかと思います。

Azure MCP Serverの概要

Azure MCP Server は、Model Context Protocol（MCP） を実装した軽量サーバで、AI エージェントや各種クライアントから自然言語での Azure 操作を可能にします。
現時点（2025/12/5）ではパブリックプレビューなので、今後新たな機能などが追加される可能性があります。

MCP（Model Context Protocol）：LLM（大規模言語モデル）が外部のツールや API と安全かつ構造化された形でやり取りするためのプロトコルです。
Azure MCP Server：MCPを利用し、自然言語プロンプトを受け取って Azure CLI や az コマンドを実行し、Azure リソースの操作を仲介するサーバです。LLM が直接 az コマンドを実行するのではなく、 MCP Server が安全な仲介役となることで、不適切なコマンド実行を防ぎセキュリティを担保します。

参考：
learn.microsoft.com

Azure MCP Server は、Azure Resource Manager（ARM）で管理されるリソース全般の操作が可能で、特にAIを活用した開発フローで頻繁に利用されるリソースに重点が置かれています。
操作可能なリソースは以下の通りです。

カテゴリ	リソース/サービス	主な操作内容
仮想マシン	Azure Virtual Machines (Azure VM)	作成、起動/停止、管理
Web/モバイル	Azure App Service	Webアプリのデプロイ、構成管理
サーバーレス	Azure Functions	サーバーレス関数のデプロイ、管理
コンテナ	Azure Kubernetes Service (AKS)	クラスターの管理、ノードリソースの操作
ストレージ	Azure Storage (ストレージアカウント)	アカウント一覧の取得、管理
NoSQL データベース	Azure Cosmos DB	アカウント、データベース、コンテナーのリストアップと管理、クエリ実行
データ分析	Azure Data Explorer	クラスター、データベース、テーブルのリストアップ、KQL (Kusto Query Language) クエリ実行
AI 開発環境	Azure AI Foundry	モデルのリストアップ、デプロイ、知識インデックスの管理
データ処理	Azure Databricks	関連リソースの管理
DevOps	Azure DevOps	関連リソースの管理
CLI 連携	Azure Developer CLI Extension	`az` コマンドの直接実行、プロビジョニング、デプロイ
構成管理	Azure App Configuration	ストアのリストアップ、キーと値のペアの管理
機密情報	Azure Key Vault	シークレット、証明書など機密情報へのアクセスと管理 (承認が必要)
ログ	Azure Monitor - Log Analytics	ワークスペースのリストアップ、KQLによるログクエリ
メトリック	Azure Monitor - Metrics	リソースのメトリッククエリ、メトリック定義のリストアップ
ヘルスチェック	Azure Service Health	特定リソースの可用性ステータス取得
基本管理	Azure リソースグループ	リストアップ、作成、管理
ネットワーク	VNet (仮想ネットワーク)	VNetおよび関連リソースの操作
可視化	Azure Workbooks	リストアップ、作成、更新、削除

Azure MCP Serverの構築

それでは、Azure MCP Server をローカルに導入してみようと思います。
今回は VS Code と GitHub Copilot を使いました。

前提条件

Node.js（v18.0以降）がインストールされていること。（以下のURLからインストールします。） docs.npmjs.com MCP Server が主にネットワーク通信（I/O）を仲介する役割を担うため、その処理に特化した Node.js が最適な基盤となっています。
npm（v8.0以降）がインストールされていること。（Node.js に内包されています。）
VS Code が最新のバージョンになっていること

Azure MCP Server インストール

① VS Code の拡張機能から「Azure MCP Server」と検索してインストールします。ローカルで Azure MCP Server を起動し、Github Copilot for Azureと通信するための土台となります。

② ユーザープロファイル配下のフォルダにmcp.jsonファイルを作成します。参考： code.visualstudio.com

【補足】mcp.jsonファイルの役割
このファイルは、Github Copilot for Azure に対して、どの外部ツールやサービス（今回は Azure MCP Server ）を連携させて利用可能にするかを定義する設定ファイルです。つまり、Github Copilot for Azure が mcp.jsonファイルで指定されたサーバーを経由し、自然言語の指示を Azure リソース操作に変換するための「連携設定」を担っています。

③ GitHub Copilot の「ツールの構成」をクリックして、Azure MCP Server が起動できていることを確認します。

Azure MCP Serverを使ってみる

ここからは実際にAzure MCP Serverを使ってみました。リソースグループの一覧を出力するように指示しましたが、、以下の通りAzureへのサインイン画面が出力されてしまいました。

サインイン後、GitHub Copilot for Azure へログインするように促されました。はじめて使用する場合はこのポップアップが出力されるようです。

リソースグループの一覧を出力した結果は以下の通りです。（Japan Eastリージョンに属するリソースグループがあまりにも多かったので、省くように指示しました。）

次に、仮想マシンの作成をするための設定値を出力するように指示しました。結果は以下の通りです。しっかりと設定値を表示してくれました。作成はせずに設定確認後に実行してくれます。今回はVMは作成しないように指示しました。

苦戦した点

Azure リソースグループの一覧を取得するようなプロンプトを投げていたのですが、想定と異なるサブスクリプションから情報を拾ってきてしまい焦りました。。
GitHub Copilot for Azure が Azure 環境に対してクエリを実行する際に、どの Azure AD (Microsoft Entra ID) テナントを既定として参照するかを制御する項目があるので、そこを更新して想定通り指示が通るようになりました。

<設定方法> ① VSCode の拡張機能から GitHub Copilot for Azure を検索して、歯車マークをクリックします。

② 「@azure: Arg Tenant」という項目に、情報を取得したいディレクトリID（組織のテナントを識別するためのID）を入力します。 GitHub Copilot for Azure が既定で参照する Azure AD（Microsoft Entra ID）テナントを切り替える設定です。

終わりに

いかがでしたでしょうか。今回は Azure MCP Server のセットアップから、VS Code 上での実際の操作までをご紹介しました。

途中、テナントの参照先設定で少し躓きましたが、設定さえクリアできれば、普段行っているリソース確認や構成案の作成がチャットベースでスムーズに行えることが分かりました。特に「仮想マシンの設定値案を出してから、作成はしない」といった柔軟な指示が通るのは便利ですね。

導入のハードルはそれほど高くないので、VS Code と Node.js 環境がある方は、ぜひ一度お手元の環境でも試してみてください。

2025-11-21

GitHub x Azure OIDC Connect登録をBackstageで省力化する

GitHub Backstage PlaTT Azure PlatformEngineering

GitHub Actionsを使用してAzureに接続する

GitHub ActionsからAzureに接続する場合、OIDC Connectionで実現することが多いと思います。

OIDC Connectionを利用するとパスワードなど秘匿情報を登録する必要もなく、安全性の高い方式です。パスワードの代わりにGitHubとAzureの双方にそれぞれの情報を登録しておくことが必要です。

登録する内容は、Azure側（Entra ID Application登録側）にはGitHub側のOrganization名とリポジトリ名、および環境名といった情報を、GitHub側にはAzure Entra ID Appliation登録のテナントID、クライアントID、接続するサブスクリプションIDといった情報です。

一般的にはこうした情報を手作業で登録しています。リポジトリ１つに対して行っているだけならばそれほど大変ではありませんが、複数のリポジトリに同じような作業を繰り返していると、ID情報などの取得と設定が意外と面倒な作業と感じるものです。

そこでBackstageを活用してこの作業を省力化することにしました。

BackstageによるOIDC Connection登録の省力化

以前にも紹介していますが、Backstageには（Scaffolder）Templateという機能があります。

この機能は事前に実行したい内容をテンプレートとして用意し、その内容を実行したいときに少数のパラメータ値を加えてテンプレートを実行することで繰り返し作業を楽にするというものです。

一般的にはGitリポジトリの新規作成や更新、Pull Request作成といった用途で利用していることが多いのですが、実はもっと様々な機能を実現することができます。また、Pluginを独自に開発することで必要な機能を追加していくことも可能です。今回は以下のような機能を用意・活用します。

GitHub Environmentの登録（OSSとして公開されています。アクション名は github:environment:create）
Azure Entra ID OIDC登録（こちらは独自実装したものです）

テンプレートを作成するにあたって、入力作業をより簡略化できるようにするため、AzureサブスクリプションやAzure Entra ID Application登録を（Client ID等必要となる情報とともに）Backstage のResource Catalogとして登録することにしました。これによるテンプレートを実行する際にAzureのテナントIDなどをユーザーが入力しなくても済むようにしています。

処理の流れとしては以下のようなことを想定します。

入力パート

Entra ID Applcation登録とAzure Subscriptionを選択
登録対象のGitHubリポジトリを選択

実行パート

GitHub EnvironmentsにAzureの認証必要情報を登録
Azure Application登録のフェデレーション情報としてGitHubの認証情報を登録

テンプレートとしては以下のような内容です。

apiVersion: scaffolder.backstage.io/v1beta3
# https://backstage.io/docs/features/software-catalog/descriptor-format#kind-template
kind: Template
metadata:
  name: example-ms-app-federation
  title: Entra ID App Federation登録
  description: An example template for screating an MS Graph App federation
spec:
  owner: user:guest
  type: ops

  parameters:
    - title: App Registration Info
      require:
        - appReg
        - appId
        - name
      properties:
        signin:
          type: string
          ui:field: MicrosoftSignIn
          ui:options:
            requestUserCredentials:
              secretsKey: AZURE_USER_OAUTH_TOKEN
        appEntity:
          title: Pick Application Entity
          type: string
          ui:field: EntityPicker
          ui:options:
            catalogFilter:
              - kind: 'Resource'
                spec.type: 'entraid-application'
        subscriptionEntity:
          title: Pick Subscription Entity
          type: string
          ui:field: EntityPicker
          ui:options:
            catalogFilter:
              - kind: 'Resource'
                spec.type: 'azure-subscription'
        name:
          title: Federatoin name
          type: string
    - title: GitHub Environment
      required:
        - repoUrl
      properties:
        repoUrl:
          title: Repository Location
          type: string
          ui:field: RepoUrlPicker
          ui:options:
            allowedHosts:
              - github.com
            requestUserCredentials:
              secretsKey: GITHUB_USER_OAUTH_TOKEN
        environment:
          title: GitHub Environment
          type: string
  steps:
    - id: subscription
      name: Fetch Subscription
      action: catalog:fetch
      input:
        entityRef: ${{ parameters.subscriptionEntity }}
    - id: application
      name: Fetch App Registration
      action: catalog:fetch
      input:
        entityRef: ${{ parameters.appEntity }}
    - id: register-federation
      name: Register Federation
      action: msgraph:githubFederation:new
      input:
        applicationId: ${{ steps.application.output.entity.metadata.annotations | pick('azure.com/entraid-app-client-id') }}
        organization: ${{ (parameters.repoUrl |  parseRepoUrl).owner }}
        repository: ${{ (parameters.repoUrl  | parseRepoUrl).repo }}
        entityType: 
          type: 'environment'
          environment: ${{ parameters.environment }}
        name: ${{ parameters.name }}
        description: Federation created by PlaTT
        token: ${{ secrets.AZURE_USER_OAUTH_TOKEN }}
    - id: createGitHubEnvironment
      name: Create GitHub Environment
      action: github:environment:create
      input:
        repoUrl: ${{ parameters.repoUrl }}
        name: ${{ parameters.environment }}
        environmentVariables:
          AZURE_TENANT_ID: ${{ steps.subscription.output.entity.metadata.annotations | pick('azure.com/tenant-id') }}
          AZURE_SUBSCRIPTION_ID: ${{ steps.subscription.output.entity.metadata.annotations | pick('azure.com/subscription-id') }}
          AZURE_CLIENT_ID: ${{ steps.application.output.entity.metadata.annotations | pick('azure.com/entraid-app-client-id') }}
        token: ${{ secrets.GITHUB_USER_OAUTH_TOKEN }}
  output:
    links:
      - title: Repository Environment
        url: ${{ ('https://' ~ parameters.repoUrl | replace('?owner=', '/') | replace('&repo=', '/')) }}/settings/environments/
      - title: App Registration
        url: https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationMenuBlade/~/Credentials/appId/${{ steps.application.output.entity.metadata.annotations | pick('azure.com/entraid-app-client-id') }}/isMSAApp~/false

実行すると、Azure側にはGitHubの情報が、GitHub側にはAzure Entra IDの情報が登録されます。入力情報がかなり削減され、またAzureとGitHubの双方に反映されるため、間違うこともありません。

さらにこのステップをリポジトリ作成テンプレートの中に追加することで、リポジトリ作成時点からGitHubリポジトリとAzureとのOIDC Connection登録が完了している状態とすることができます。

このように、BackstageのTemplate機能を利用することでOIDC Connection登録作業も省力化、簡略化することができます。

最後に

Backstageには他にも開発者の認知負荷を低減する様々な機能が存在します。その効果も使い方次第でより大きくなります。弊社ではOSSであるBackstageをManaged Serviceとして提供させて頂いております。

今回紹介した機能についてはMicrosoft Entra ID関連の部分は独自に拡張したものです。

ご興味のある方がいらっしゃいましたらぜひ弊社までご連絡ください。よろしくお願いします。

2025-11-11

HCP Terraform WorkspaceでAzure Provider認証にOIDCを利用する

Azure Microsoft Entra ID HCP Terraform

はじめに
前提条件
Azure側（Entra ID）でサービスプリンシパルの作成と、フェデレーション資格情報の追加
HCP Terraform Workspaceで環境変数の追加を行う
おわりに
ACS事業部のご紹介

はじめに

こんにちは。ACS事業部の青木です。
このブログでは、HCP TerraformとAzureでOIDC認証連携を行う方法について解説します。

OIDC方式での認証をすることで、デプロイを実行するプリンシパル側でシークレットキーを払い出してHCP Terraform Workspace側に渡すことなく処理を実行することができるようになります。

シークレットキーを使う場合、漏洩した際のセキュリティにおける危険性や、期限切れになった場合のシークレットキーの更新を最低でも2年に一度行わなければいけない手間がありますが、OIDC認証による認証設定を行うことでこれらの懸念点を解消することができます。
早速やってみましょう。

前提条件

以下が対応できていることを前提条件として話を進めていきます。

HCP TerraformのOrganization環境にログインできること
今回作業するHCP Terraformの任意のProjectでWorkspaceが作成されており、そのWorkspaceのAdmin権限を持っていること
Entra IDでアプリケーション（サービスプリンシパル）の作成権限を持っていること

Azure側（Entra ID）でサービスプリンシパルの作成と、フェデレーション資格情報の追加

まずはアプリの登録（サービスプリンシパルの作成）から行っていきましょう。

EntraIDのメニューより、[アプリの登録]をクリックします。

[新規登録]をクリックします。

アプリケーションの登録画面にて、アプリケーションのユーザー向け表示名とアカウントの種類を選択し、[登録]をクリックします。

作成後、作成したアプリの表示名をクリックします。

[証明書とシークレット]→[フェデレーション資格情報]→[資格情報の追加]をクリックします。

では、資格情報の追加を行います。
フェデレーション資格情報のシナリオでは、[その他の発行者]を選択しましょう。ちなみに、GitHub Actionsなどであればプリセットされた設定項目があったりして、設定が簡単だったりします。

続いて、[発行者]、[種類]、[値の入力]です。

設定名	値
発行者	`https://app.terraform.io`
種類	要求照合式
値の入力	`claims['sub'] matches 'organization:<HCP TerraformのOrganization名>:project:<HCP Terraformのプロジェクト名>:workspace:<HCP Terraformのワークスペース名>:run_phase:*'`

run_phaseにはplanやapplyなど、terraformのRunアクションごとに設定を入れることができますが、今回は基本的にどちらも動作させることを可能にするために種類を要求照合式にし、アスタリスクでワイルドカード指定をしています。
また、Organization名やプロジェクト名、ワークスペース名はご自身のものに置き換えて記載してください。

ちょっと解説：値の内容について

種類に「明示的なサブジェクト識別子」と「要求照合式」がありますが、ワイルドカードを使用できるため要求照合式をお勧めします。
また、今回はrun_phaseだけアスタリスクを使用していますが、ワークスペース名やプロジェクト名などでも適宜ワイルドカードは使用できます。これを利用すると、複数のWorkspace環境に対して処理を行う際に共通のプリンシパルを使用する、ということを実現することができます。
例えば「Terraform Workspaceを開発メンバー事に分けつつも、検証の際の権限は同じにしたい」というようなパターンで有用ですので覚えておくとよいと思います。
なお、現状「要求照合式」はプレビューの機能となります。今後GAされていくかと思いますが、念のためご注意ください。
参考：
learn.microsoft.com

設定後、任意のフェデレーション資格情報名を入力し、必要であれば説明も加えます。
設定が完了したら、[追加]をクリックしましょう。

フェデレーション資格情報が追加できていることを確認しましょう。

最後に[概要]ペインをクリックし、クライアントIDの値を控えておきましょう。
（赤いマスキングの箇所に表示されています）

HCP Terraform Workspaceで環境変数の追加を行う

続いては、HCP Terraformでvariableを登録します。

設定を行いたいHCP Terraform Workspaceに移動し、[Variables]→[+ Add variable]をクリックして、variableの作成を行います。

設定するパラメータは以下の通りです。
いずれも環境変数での登録となります。terraformのvariableではなく、環境変数として登録するためカテゴリに注意しましょう。

設定名	値
TFC_AZURE_PROVIDER_AUTH	`true`
TFC_AZURE_RUN_CLIENT_ID	<控えておいたクライアントID>
ARM_SUBSCRIPTION_ID	<AzureリソースをデプロイするサブスクリプションID>
ARM_TENANT_ID	<AzureリソースをデプロイするテナントID>

以下に登録の際の参考キャプチャを載せます。
センシティブ設定やdescriptionなどは適宜調整してください（今回の例ではクライアントIDのみセンシティブ扱いにしています）

設定が完了したら、最後に一覧で確認しましょう。

設定はこれで完了です！
あとはサービスプリンシパルにAzureリソースの操作権限を付与いただき、HCP Terraform Workspaceと連携しているTerraformのコードを作成いただければシークレットキーを環境変数に持たせることなくデプロイを行うことができます。

おわりに

最後に、参考文献をこちらにまとめます。

developer.hashicorp.com

簡単に設定が完了しますので、ぜひOIDC認証の設定を行ってみてください。
HCP Terraformでシークレットキーを用いた認証を行っている環境の改善に、本ブログが助けになると幸いです。

ACS事業部のご紹介

本記事の投稿者
青木平：ウイスキーと柔道が好きなエンジニアです。
Kubestronaut/Microsoft Top Partner Engineer 2025

2025-08-22

【Azure】Microsoft Copilot in Azureを使ってみた

AI Azure

はじめに

こんにちは。クラウド事業部の田代です。
今回はAzure上で利用可能なMicrosoft Copilot in Azureについて書いていこうかと思います。実際の業務でどのように役立つかも記載していくのでよければ是非見ていってください。

Microsoft Copilot in Azureの概要

Microsoft Copilot in Azureって何？

Microsoft Copilot in Azureは、2025年4月8日に正式版（GA）が発表された、AzureポータルやAzureサービスに組み込まれた生成AIアシスタントです。OpenAIの技術とMicrosoftのクラウド基盤を組み合わせることで、Azureの利用者がより効率的にクラウドを設計・運用できるようにサポートします。

Azure Portal上では、以下の画像のようにCopilotのアイコンをクリックして利用します。

詳細についてはドキュメントを参照してください。

公式ドキュメント：

価格

本記事の投稿時点（2025年8月22日）では、無料で利用可能です。今後、機能が追加された場合は課金対象となる可能性もあります。

対応言語

ユーザーの自然言語の入力に応じて回答・操作を支援するために、以下の19言語で利用できます。

中国語 (簡体字)、中国語 (繁体字)、チェコ語、オランダ語、英語、フランス語、ドイツ語、ハンガリー語、インドネシア語、イタリア語、日本語、韓国語、ポーランド語、ポルトガル語 (ブラジル)、ポルトガル語 (ポルトガル)、ロシア語、スペイン語、スウェーデン語、トルコ語

利用可能な地域

日本やアメリカ、ヨーロッパなどの一般的な Azure リージョンでは利用可能です。
しかし、特殊用途のリージョン（ガバメントクラウドや中国本土リージョン）では利用できません。

Copilotと何が違うの？

CopilotとMicrosoft Copilot in Azureの違いを表にまとめました。

項目	Copilot	Microsoft Copilot in Azure
主な用途	生産性向上（文章作成、コード生成、会議要約など）	クラウド管理・運用支援（Azureリソースの構築、監視、最適化など） \|
動作環境	各アプリケーションやIDE（例: Word, VS Code）	Azure Portal、Azure CLI、Azure関連サービス上
入力方法	自然言語プロンプトで「文章生成」「コード補完」「要約」などを依頼	「VMを作成して」「コストを最適化して」と自然言語で依頼（Azureの操作や設定）
出力内容	- テキスト（文章、要約、メール草案） - コード（プログラミング補助） - 分析（Excelグラフやレポート）	- Azureリソース構築用の Bicep / ARM / Terraform コード - Azure Portalでの操作支援 - コストやセキュリティの改善提案
対象ユーザー	ビジネスユーザー、開発者、知識労働者全般	クラウド管理者、インフラエンジニア、DevOps担当
利用するデータ	ユーザーのドキュメント、メール、ソースコードなど（組織データ＋公開情報）	Azure環境のリソース情報、メトリクス、ログ（Monitor、Advisor、App Insightsなど）
導入形態	追加ライセンスが必要な場合あり（例: Microsoft 365 Copilot は有料）	Azure利用者は追加コストなしで利用可能

このように比較してみると、

Copilot → 文章やコードなど人の仕事の効率化に特化
Copilot in Azure → クラウドリソース管理のAzure運用・管理の自動化に特化

していることがわかるかと思います。

とりあえず触ってみた

ここまでMicrosoft Copilot in Azureについて、Copilotとの比較も踏まえて解説しました。
ここからは実際にMicrosoft Copilot in Azureを触っていきます。

効果的なプロンプト

どのAIツールを使うときにも言えることですが、効果的なプロンプト（AIに対して与える、指示・質問・命令文などのこと）を使うことはとても大切です。公式ドキュメントにヒントが記載されているので、AIに対して指示を与える際には参考にしてみてください。 learn.microsoft.com

実演

まず、AKSクラスターのノードスケーリングを有効化するコマンドを表示するように指示を与えました。しかし、具体的な指示が足りなかったため、ノードプールとノード数を提示するように求められました。

もう一度実行。

今度はコマンドを表示してくれました。

次に、サービスのページに移動するよう指示しました。

正式なサービス名称を入力しないと遷移してくれませんでした。
もう一度実行してみます。

今度は無事、遷移しました！

続いて仮想マシンの起動を試してみました。

続行欄で「はい」を選択して無事仮想マシンの起動に成功しました！

次に、個人的に気になっていた「Terraformでコードを出力させる」ことを試してみました。

コードは出力されましたが、与えた情報が少なかったためか、実機の値と異なる箇所がありました。リソースグループ名やリソース名、リージョンなど、細かい設定はこちらで補足しないと正確には出力されないようです。Azure上の設定を読み込んでコードに反映させてくれるものだと思っていました。

実務での利用を考えてみる

色々と試した結果、実務で利用するなら、パラメータなどをしっかりと提示してMicrosoft Copilot in AzureにTerraformのコードを出力させ、その後、手動で微修正してからレビューに回すのが最も良いかと思います。指定した仮想マシンを起動/停止する、Azureサービスのページに遷移する、リソースグループの一覧を出力する、といった簡単な指示は、積極的に活用できると感じました。

終わりに

今回の検証を通して、Microsoft Copilot in AzureがAzure運用の強力なパートナーになりうることが分かりました。まだ発展途上の機能も多いですが、今後のアップデートでさらに多くの機能が追加されることが期待されます。

特に、日常的な簡単なタスク（リソースの起動・停止、ページ遷移など）はCopilotに任せることで、より複雑で高度な作業に集中できるようになるでしょう。これからもCopilotの進化に注目し、日々の業務に積極的に取り入れていきたいと思います。

このブログが、皆さんのAzure運用の一助となれば幸いです。最後までお読みいただき、ありがとうございました。

2025-07-22

VS Code で Cline を試そうとしただけなのに、いつのまにか Azure OpenAI を探索していた話

Azure

はじめに
Azure OpenAI と衝撃のトークン数
Azure OpenAI ログ収集、しかし…
Azure API Management 導入へ
一難去って、また一難
念願のログ出力！！
おわりに
お知らせ

はじめに

Amazon Bedrock と VS Code (Cline) で AI コーディングを始めようとした、とある日のことでした。

普段使っている社内の AWS 環境では Bedrock への API アクセス権限が付与されていなかったため、急遽、社内の Azure 環境で試してみることにしたんです。これが、思わぬ方向へ進むことになった「事の発端」でした。

Azure OpenAI と衝撃のトークン数

Azure OpenAI で環境を構築し、Azure AI Studio で gpt-35-turbo モデルをデプロイしました。

エンドポイントのターゲットURIとキーをコピーして Cline に設定し、いざ実行。無事に返答が返ってきて「よしよし」と思ったのも束の間、あることに気づきました。

簡単な質問をしたはずなのに、表示されたトークン数は 10,000 を超えています。これは明らかに多すぎますよね。

この予期せぬトークン数に戸惑い、ここからAzure環境の本格的な調査が始まることになったのです。

Azure OpenAI ログ収集、しかし…

さて、問題のトークン消費の調査です。まずは、Azure OpenAI のログを取得してみることにしました。

Azure OpenAI の診断設定で、ログを Log Analytics に出力するように設定します。設定後、すぐにリクエストを送信してみたのですが、ログが一向に出力されません。どうやら、ログの反映には少し時間がかかるようで、5分から10分ほどで無事にログが出力されました。

しかし、ログは出力されたものの、残念なことに期待していたプロンプトの情報の記載がありません。これでは、どのようなリクエストが送信されているのかが全く分かりません。

さて、どうしたものか…。

Azure API Management 導入へ

目的のログが取得できないため、AIチャットに相談したところ、Azure API Management (APIM) を経由する方法を提案されました。早速、これを試してみることにします。

Azure API Management は、API の公開とライフサイクル管理を担う API Gateway サービスです。また、調査を進める中で、取得したいログが APIM の診断設定から収集できるのは、価格レベルが Developer 以上の場合のみであり、従量課金レベルではサポートされていないことが分かりました。

従量課金レベルでは、リソースログの収集はサポートされていません。

金額を確認した上で、その中でも安価な Developer レベルで環境を構築することにしました。

azure.microsoft.com

APIM に Azure OpenAI への API を登録するのは非常に簡単です。「APIs」→「API」→「Add API」から「Azure OpenAI Service」を選択し、あとはウィザードの指示に従って作成済みの Azure OpenAI サービスを指定するだけで、パスなどが自動で作成されました。

一難去って、また一難

API の登録まではできたものの、ここから何度か問題に直面しました。

まず、Azure OpenAI へのアクセスが API Management 経由になったため、Cline 側の URL を変更する必要があります。API の画面にある Base URL をコピーし、Cline に第一レベルのパスまでを上書きして登録しました。

さっそくチャットを試しますが、401エラーでつながりません。

デフォルトの設定では、リクエスト時に API キーが必要なようです。そこで、サブスクリプションにあるキーを Cline の設定のヘッダーに登録しました。

まだつながりません。

デフォルトのヘッダー名が Ocp-Apim-Subscription-Key だったのでこれを登録したのですが、どうやら設定を見る限り別のヘッダー名（api-key）が必要なようです。

改めて api-key で設定し直しますが、まだつながりません。

今回試したいのはログ取得であり、認証は本質的な目的ではないため、一時的にサブスクリプションの require 設定を外したところ、無事につながりました。この認証の問題については、また別の機会に深掘りすることにしましょう。

API Gateway 経由で接続できたので、次はログの設定です。OpenAI Service と同じように診断設定を行い、Log Analytics へログを飛ばそうとします。

設定を終え、何度かリクエストを送信してみますが、ログが出力されません。

どうも設定が足りないようで、API Gateway 側での追加設定が必要とのこと。しかし、設定画面を探しても関連するリンクしか見当たらず、設定したい内容がどこにもありません。

何度か診断設定をやり直した結果、ようやく設定項目が表示されるようになりました。これが設定ミスだったのか、それとも単に時間経過で解決したのかは不明です。

これで「Log LLM Message」を On にし、再度 Cline からリクエストを投げて、しばらく待ちます。

念願のログ出力！！

そしてついに、念願のログが出力されました！

ログは Log Analytics の APIManagementGatewayLlmLog テーブルに出力されています。

出力されたログにはシーケンス番号が振られており、その内訳は以下の通りでした。

0: リクエストログ
1～4: リクエストデータ
5: レスポンスログ

リクエストデータを一つ確認してみると、

なるほど、原因はこれです。System Role にかなりの設定ががっつり入っていたのですね。このメッセージは削減できないものか、と次の疑問が湧いてきましたが、まずは原因が特定できてスッキリしました！

おわりに

Cline を試してサクッと AI コーディングを始めようとしたはずが、いつのまにか Azure OpenAI のログ出力方法を学ぶ旅になっていました。想定外の展開でしたが、結果として Azure OpenAI Service にじっくりと触れる良い機会となり、多くの学びがありました。

私と同じように、AI コーディングを進める中で似たような疑問を抱いたり、今回の記事で私が直面した箇所で立ち止まってしまったりする方の参考になれば幸いです。

お知らせ

弊社 APCommunications では、Azure を活用した DX 推進、内製化を支援しております。

www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

hrmos.co

本記事の投稿者: t-umemoto
コンテナや k8s をメインにインフラ系のご支援を担当しています。
更新滞ってますが Qiita や Zenn に k8s を中心とした記事も投稿しております。よろしければ。

2025-06-18

Microsoft Docs MCP Serverを利用して公式情報を効率的に利用する

Azure MCP

はじめに
VS Codeの設定
GitHub Copilot Agent Modeで使ってみる
利用して感じたこと
まとめ
ACS 事業部のご紹介

はじめに

ACS事業部の井田です。先日マイクロソフトから公式ドキュメントの情報を取得可能なMCPサーバーが発表されました。

日々公式ドキュメントを見るたびに、「ドキュメントわかりにくい」と常々感じていた私にとっては非常に嬉しい発表です。

今回はVS Code上でGitHub Copilot Agent Modeから利用してみたので、設定方法から使い方までまとめました。

github.com

VS Codeの設定

上記のGitHubリポジトリにアクセスし、READMEに記載の「VS Code Install Microsoft Docs MCP」をクリックすると、VS Codeを開くか聞かれるので開きます。

選択肢が表示されるので、「Install Server」を選択すると、settings.jsonに以下の記述が追加されます。これだけで利用する準備が整いました。

  "mcp": {
    "servers": {
      "microsoft.docs.mcp": {
        "type": "http",
        "url": "https://learn.microsoft.com/api/mcp"
      }
    }
  }

GitHub Copilot Agent Modeで使ってみる

今回は明示的にMCPを利用させるために、Agent ModeのAdd Contextを選択し、下記の「Tools」から「microsoft_docs_search」を選択しました。

調査中だったAzure AI Foundry関連のリソース作成コマンドを聞いたところ、MCP経由で公式ドキュメントを検索してくれました（ただし、提案してくれたコマンドはハルシネーションを起こしています）。

利用して感じたこと

上記の添付画像では参照ドキュメントのリンクを返してくれませんでしたが、リンクを返すように指示を加えると出力してくれました。

また、Azure AI Foundryのリソース作成はAzure CLIが未提供のものも多いのですが、Azure CLIのコマンドを提示されました。ハルシネーションは普通に起こるようです。提示してくれたドキュメント自体は正しかったので、自分でも確認しながらリソースは作成しました。ハルシネーションについて指摘し、REST APIのCLIコマンドを要求すると正しいコマンドを教えてくれました。

まとめ

設定が容易でGood
ドキュメント検索を意図したタイミングで実行してくれる保証がないため、明示的にツールとして指定した方が確実
Web検索よりもAgentに聞いた方が該当するドキュメントが見つかる可能性は高いかも
ドキュメントを参考にして実行コードを出力してくれるのはGood
ハルシネーションは発生するので、参照したドキュメントのリンク提示とその確認はした方が良い

一次情報の検索性改善や分かりにくいドキュメントを平易に説明してくれるのは非常に便利なので、ハルシネーションと上手く付き合いながら日々利用していきたいと思います。

ACS 事業部のご紹介

私の所属する ACS 事業部では、開発者ポータル Backstage、Azure AI Service などを活用し、Platform Engineering ＋ AI の推進・内製化を支援しています。

また、GitHub パートナーとしてお客様に GitHub ソリューションの導入支援を行っています。 GitHub Copilot などのトレーニングなども行っておりますので、ご興味を持っていただけましたらぜひお声がけいただけますと幸いです。

一緒に働いていただける仲間も募集中です！ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp www.ap-com.co.jp

本記事の投稿者: 井田一貴

2025-05-13

【OCI】OCI・AWS・Azureの主要サービス／用語比較

OCI Azure AWS

はじめに

こんにちは、クラウド事業部の大竹です。
先日 OCI Architect Associate (2024) に無事合格しました。
OCIより先にAzureとAWSに触れていたので、OCIについて学習を開始するにあたり、「このOCIのサービスは、Azure・AWSだと何に当たるの？」ということを理解しようと思い、簡単にまとめました。
※各社のサービス毎に違いがあります。あくまで概要理解の参考に活用ください。説明は主にOCI目線で記載しています。OCI Architect Associate (2024)の出題範囲外の内容を含みます。

どんなひとに読んで欲しい

AWSやAzureについて学習したことがあり、これからOCIについて学習する人
OCIについて学習したことがあり、これからAWSやAzureについて学習する人

OCI、AWS、Azure 類似サービス表

コンピューティング

項目名	OCI	AWS	Azure	説明
仮想マシン	コンピュートインスタンス（仮想マシンとベアメタルサーバー¹が選択可）	EC2	Virtual Machines	CPU、メモリ、ストレージ構成を選択して構成
サーバーレスコンピューティング	OCI Functions	Lambda	Azure Functions	イベント駆動型のコード実行
マネージドKubernetes	Oracle Cloud Infrastructure Container Engine for Kubernetes（OKE）	Amazon Elastic Kubernetes Service（Amazon EKS）	Azure Kubernetes Service (AKS)	コンテナ化されたアプリケーションの管理

ストレージ

項目名	OCI	AWS	Azure	説明
オブジェクトストレージ	オブジェクトストレージ	S3	Blob Storage	非構造化データ保存
アーカイブストレージ	アーカイブストレージ	S3 Glacier	Archive Storage	オブジェクトストレージより長期保存向けの低コストストレージ
ブロックストレージ	ブロックボリューム	Elastic Block Store（EBS）	Disk Storage	仮想マシンにアタッチ可能
ファイルストレージ	ファイルストレージサービス（FSS）	Elastic File System（EFS）	Azure Files	複数VMで共有可能

データベース

項目名	OCI	AWS	Azure	説明
マネージドRDB	Autonomous Database （自律型データベース）	RDS	SQL Database	様々なデータベースエンジンをサポート
NoSQLデータベース	NoSQL Database	DynamoDB	Cosmos DB、Azure Table Storage	高いスケーラビリティとパフォーマンス
データウェアハウス	Autonomous Data Warehouse （ADW）	Redshift	Synapse Analytics	大規模データ分析向け
マネージド MySQL データベースサービス	HeatWave MySQL	Aurora、Amazon RDS for MySQL	Azure Database for MySQL

ネットワーキング

項目名	OCI	AWS	Azure	説明
仮想ネットワーク	Virtual Cloud Network（VCN）	Virtual Private Cloud（VPC）	Virtual Network	仮想的なプライベートIPアドレス空間を提供
ロードバランサ（レイヤー4）	ロードバランサ	Network Load Balancer（NLB）²	Load Balancer	トラフィック分散
ロードバランサ（レイヤー7）	ロードバランサ	Application Load Balancer（ALB）³	Application Gateway	Web アプリケーションに対する負荷分散、WAF
DNSサービス	DNS	Route 53	DNS	ドメイン名解決
専用線接続	FastConnect	Direct Connect	ExpressRoute	オンプレミスとクラウド仮想ネットワーク間の専用接続
VPN接続	サイト間VPN	AWS Site-to-Site VPN	VPN Gateway	オンプレミスとクラウド仮想ネットワーク間のIPSec接続
CDN（コンテンツ配信ネットワーク）	-	Amazon CloudFront	Azure Front Door、Azure CDN	高速コンテンツ配信

その他OCIのサービスについて
- Webアプリケーション・アクセラレーション・・・ロードバランサの機能拡張サービス。レイヤー7のHTTPロードバランサーのトラフィックを高速化するために、キャッシュと圧縮を適用することで、アプリケーションのパフォーマンスを向上。

その他

項目名	OCI	AWS	Azure	説明
IAM	OCI IAM	AWS IAM、 Amazon Cognito	Microsoft Entra ID	ユーザー、グループ、リソースのアクセス制御
ネットワーク監視／診断	ネットワーク・コマンド・センター	AWS CloudWatch	Network Watcher	ネットワークの監視、トラブルシューティング
セキュリティ管理	Cloud Guard	Security Hub	Microsoft Defender for Cloud	脅威検出、脆弱性診断
リソース監視	モニタリング	CloudWatch	Azure Monitor	メトリクス収集、アラーム設定、パフォーマンス監視
ログ管理	ロギング	AWS CloudWatch Logs	Azure Monitor Logs、 Log Analytics	ログの一元管理

OCI、AWS、Azure 概要用語比較

OCI	AWS	Azure	説明
テナンシ（Tenancy）	アカウント（Account）	テナント、サブスクリプション	利用申し込みした際に割り当てられる管理領域。
ホームリージョン（Home Region）	-	-	テナンシが最初に作成されるリージョン。IAMリソースなど、特定のサービスはこのリージョンに存在。後から変更不可。
リージョン（Region）	リージョン	リージョン	地域。クラウドサービスで利用するデータセンターの所在地。
ルートコンパートメント（Root Compartment）	-	-	テナンシ内に最初に作成される最上位のコンパートメント。すべてのリソースはこのコンパートメントまたはサブコンパートメントに存在。
コンパートメント（Compartment）	リソースグループ	リソースグループ	リソースの論理的なグループ。リソースの整理やアクセス制御に利用。コンパートメントは6階層までネスト可能。
可用性ドメイン（Availability Domain: AD）	可用性ゾーン（Availability Zone: AZ）	可用性ゾーン（Availability Zone: AZ）	リージョン内にある1つ以上のデータセンター。ハードウェア障害や電力障害から保護するために、他の可用性ドメインから分離されている。
フォルトドメイン（Fault Domain: FD）	プレイスメントグループ	可用性セット	可用性ドメイン内にあるハードウェアのグループ。ハードウェアの障害・メンテナンスから保護するために、同じ物理ハードウェアに存在しないように分離する。各可用性ドメイン内には3つのフォルトドメインがある。

まとめ

OCI・AWS・Azureの主要サービス／用語について簡単にご紹介しました。この記事がどなたかの学習の参考になれば幸いです。

おしらせ

私達クラウド事業部はクラウド技術を活用したSI/SESのご支援をしております。

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

ベアメタルサーバーとは、専有サーバー環境で、コンピュートリソースを必要とする場合に用いる物理サーバー環境。↩
Elastic Load Balancing（ELB）の一種。↩
Elastic Load Balancing（ELB）の一種。↩

2025-04-18

Azure MCP Server がパブリックプレビューになったので試してみた

Azure MCP VSCode AI GitHub Copilot

こんにちは、ACS 事業部の埜下です。

先日、GitHub 公式の GitHub MCP Server が登場しましたね。

そしてついに！
Microsoft から「Azure MCP Server」が登場しました！

そこで今回は「Azure MCP Server とは」、「GitHub Copilot Agent mode で Azure MCP Server を動かす方法」について紹介します。

「MCP とは」や「Windows の WSL2 で MCP を動かす方法」については、以前 GitHub MCP Server について紹介した記事をご覧ください。

Azure MCP Server とは
Azure MCP Server を使ってみる
- Azure MCP Server がないとき
- Azure MCP Server があるとき
まとめ

Azure MCP Server とは

Azure MCP Server は Microsoft が開発している Azure 用 MCP サーバです。

github.com

Azure MCP Server を使うことで、「MCP」というプロトコルを介して GitHub Copilot Agent mode などの MCP クライアントが Azure リソースを参照しながら回答できるようになります。つまり、GitHub Copilot Agent mode などの MCP クライアントの利用者が自然言語で Azure を参照、操作できる ようになります。

Microsoft による紹介記事が出ていますので、こちらもご覧ください。

devblogs.microsoft.com

Azure MCP Server でできること

Azure MCP Server を使うことで、GitHub Copilot Agent mode などの MCP クライアントから以下を実行できます。現在 (2025/4/18 時点)、Azure MCP Server はパブリックプレビューの状態ですので、今後も増えていくと思われます。

Azure サービス
- Azure Cosmos DB (NoSQL データベース)
  - Cosmos DB アカウントの一覧表示
  - データベースの一覧表示とクエリ実行
  - コンテナとアイテムの管理
  - コンテナのクエリ実行
- Azure ストレージ
  - ストレージアカウントの一覧表示
  - BLOB コンテナと BLOB の管理
  - Table Storage の一覧表示とクエリ実行
  - コンテナのプロパティとメタデータの取得
- Azure Monitor (Log Analytics)
  - Log Analytics ワークスペースの一覧表示
  - Kusto クエリ言語 (KQL) の実行
  - 利用可能なテーブルの一覧
  - 監視オプションの講師絵
- Azure App Configuration
  - App Configuration ストアの一覧表示
  - Key-Value の管理
  - ラベル付き構成の管理
  - 構成設定のロック/ロック解除
- Azure リソースグループ
  - リソースグループの一覧表示
  - リソースグループ管理操作
Azureツール
- Azure CLI
  - Azure CLI コマンドの直接実行
  - すべての Azure CLI 機能のサポート
  - JSON フォーマットの出力
- Azure Developer CLI (azd)
  - azd コマンドの直接実行
  - テンプレートの検出、テンプレートの初期化、プロビジョニング、およびデプロイメントのサポート

Azure MCP Server はこれらの機能を MCP の「ツール」として提供します。 GitHub Copilot Agent mode などの MCP クライアントはこのツールを利用してやりたいことを実現します。

前提条件

VS Code の GitHub Copilot Agent mode から Azure MCP Server を使う場合、いくつか前提条件があります。

VS Code バージョン 1.99 以上にする
Node.js のバージョンを 18.0.0 以上にする
npx コマンドを実行できる状態にする

1 つ目は、VS Code で GitHub Copilot Agent mode を使うために必要な要件です。 1.99 未満の場合は VS Code をバージョンアップしてください。

2 つ目と 3 つ目は、Azure MCP Server を動かすための要件です。 Azure MCP Server の起動には npx コマンドを実行します。また、@azure/mcp というパッケージを利用するので、npm をインストールして npx コマンドを実行できる状態にしておきます。

インストール

Azure MCP Server リポジトリの README には VS Code へ簡単に Azure MCP Server をインストールするボタンも用意されています。

このボタンを押下すると VS Code の設定ファイル settings.json に Azure MCP Server の設定が追加されます。この設定は手動で追加しても構いません。

{
  "servers": {
    "Azure MCP Server": {
      "command": "npx",
      "args": [
        "-y",
        "@azure/mcp@latest",
        "server",
        "start"
      ]
    }
  }
}

画像のように Azure MCP Server の設定に「▷Start」という文字が表示されています。「▷Start」を選択すると、VS Code で Azure MCP Server が起動します。

GitHub Copilot Agent mode から利用

起動した Azure MCP Server を GitHub Copilot Agent mode から利用するには、GitHub Copilot Chat のウィンドウで "Agent" を選択します。

すると、画面左上に⚒️のアイコンと数字が出てきます。これは MCP サーバーから提供されている「ツール」の状態と利用できる数を表しています。 settings.json で指定した MCP サーバーとうまく連携できていない場合、この⚒️がエラーアイコンになります。

エラーがない状態で GitHub Copilot に Azure に関する質問をすると、Azure MCP Server 経由で Azure の情報を使って回答してくれます。

GitHub Copilot for Azure との組み合わせ

既に GitHub Copilot には「GitHub Copilot for Azure」という拡張機能が存在しています。

Azure を利用するうえで GitHub Copilot for Azure はとても便利な機能ですが、直接データプレーンを対象にした操作はできないようです。たとえば、「ストレージアカウント内のデータの参照」や「CosmosDB に対するクエリ実行」などです。 GitHub Copilot for Azure は Azure リソースの参照には Azure Resource Graph を使い、データプレーンの参照などには VS Code 上で Azure CLI を実行して目的を達成しようとします。

一方、Azure MCP Server はデータプレーンの操作をサポートしており、多くの場合 Azure CLI を実行せずに GitHub Copilot Agent mode から直接データプレーンを参照できるようです。

そのため、Azure MCP Server と GitHub Copilot for Azure を使い分けるのではなく、GitHub Copilot Agent mode で両者を組み合わせて使うことで、より効率的に Azure に対する操作ができるようになります。

Azure MCP Server を使ってみる

それでは、Azure MCP Server を使ってみましょう。

今回はストレージアカウント内の BLOB データを GitHub Copilot Agent mode で参照してみます。違いが分かるように、「Azure MCP Server を使わず GitHub Copilot for Azure を使うパターン」と「Azure MCP Server と GitHub Copilot for Azure を使うパターン」で試してみました。

Azure MCP Server がないとき

まずは Azure MCP Server が使われないようにするために、GitHub Copilot の画面から Azure MCP Server を無効化しました。

そして、GitHub Copilot Agent mode に「@azure ストレージアカウントのデータを参照できますか？」と聞いてみました。すると、GitHub Copilot for Azure の機能でサブスクリプションの確認やストレージアカウント一覧の表示がされました。内部的には Azure Resource Graph を使ってリソースの情報を取ってきているようです。

今回は Terraform の tfstate を格納したストレージアカウントに対してデータ参照を指示しました。すると、Azure CLI (az コマンド) の実行を提案されました。

Continue を選択すると、VS Code で新しいターミナルが表示され、GitHub Copilot Agent mode によって Azure CLI が実行されました。

GitHub Copilot Agent mode はターミナルで実行した Azure CLI の結果を解析して、次の作業を判断して提案してくれました。

以降は引き続き Azure CLI を使って BLOB データを参照する流れとなったので割愛します。

このように、GitHub Copilot for Azure のみの場合はデータプレーンに対する操作は、利用者の代わって GitHub Copilot Agent mode が Azure CLI を実行します。

Azure MCP Server があるとき

続いて、Azure MCP Server を有効化して同じ「@azure ストレージアカウントのデータを参照できますか？」という質問をしてみます。

そうすると、Azure MCP Server のツール azmcp-subscription-list の実行を提案されました。

Azure MCP Server を使って利用可能なサブスクリプションが確認される

Continue を選択してツールを実行すると、サインイン済みのサブスクリプション一覧が表示されました。

GitHub Copilot はすべてのサブスクリプションを対象にしてストレージアカウントのデータを参照しようとしたので、特定のサブスクリプションのみを対象としてデータ参照するように指示しました。今度は Azure MCP Server のツール azmcp-storage-account-list の実行を提案されたので、実行してもらうとサブスクリプション内のストレージアカウント一覧が表示されました。

Azure MCP Server を使わないときと同じく、tfstate 用のストレージアカウントを指定します。こちらも Azure MCP Server のツールが提案されました。

実行すると、ストレージアカウント内のコンテナが表示され、Azure MCP Server のツールを使った BLOB データの参照を提案されました。

実行してもらうと、BLOB データについての情報が回答されました。

さらに詳しく情報が取れるということなので指示したところ、Azure CLI を実行するツール azmcp-extension-az を提案されました。

ツール azmcp-extension-az でどんなものが実行されるのか確認したところ、Azure CLI のサブコマンド以降の情報が含まれていました。 Azure MCP Server の個別のツールで対応できない命令に対しては、azmcp-extension-az ツールを使って Azure CLI コマンドを実行するようです。

azmcp-extension-az では Azure CLI のサブコマンドの情報が含まれている

残念ながら BLOB データをダウンロードしてきて中身を確認することまではできませんでした。

Azure MCP Server を使った場合のストレージアカウントの参照は以上としました。

このように、Azure MCP Server を使った場合は GitHub Copilot Agent mode から直接データプレーンへの操作が可能です。 Azure CLI が必要になった場合でも MCP サーバ上で Azure CLI を実行してくれます。 VS Code のターミナルで Azure CLI が実行されるわけではありません。

まとめ

今回はパブリックプレビューとして公開された Azure MCP Server について紹介しました。

GitHub Copilot Agent mode から利用可能な Azure 向け MCP サーバ
Azure MCP Server はデータプレーンの操作をサポート
GitHub Copilot for Azure と組み合わせることでより効率的に

Azure MCP Server と GitHub Copilot for Azure を使うことで、GitHub Copilot Agent mode はより便利になっていくと思います。 GA される日が待ち遠しいですね。

2025-04-09

Microsoft Copilot in Azure が GA しました

Azure Microsoft Copilot

こんにちは、ACS 事業部の埜下です。

本日、Microsoft Copilot in Azure が GA したというアナウンスがありました！

azure.microsoft.com

こちらの記事では Copilot in Azure の概要や使用例を紹介します。

Copilot in Azure とは？
Copilot in Azure を使ってみよう
まとめ

Copilot in Azure とは？

Copilot in Azure は Microsoft Copilot ファミリーの 1 つです。 Copilot in Azure を利用することで Azure で動かすアプリやインフラの設計、運用、最適化、トラブルシューティングを簡素化できます。

通常の Azure だけでなく Azure Arc にも対応しており、Copilot in Azure はクラウドからエッジまで扱うことができます。

Copilot in Azure のドキュメントもありますが、日本語ドキュメントはまだプレビュー時のまま (2025/4/9 時点) のため、英語ドキュメントで確認するのをオススメします。

できること

Copilot in Azure を使うことで自然言語によって Azure リソースに関する情報の参照や、リソースを操作できます。

Copilot in Azure のドキュメントには活用できるシナリオ例として大きく 3 つのジャンルに分けられています。

Azure 環境を理解する
Azure サービスでよりスマートに作業する
コードを記述して最適化する

各ジャンルには具体的なシナリオが掲載されていますので、ぜひご確認ください。

費用

現在、Copilot in Azure の機能を利用するための費用は発生しません (2025/4/9 時点) 。

ただし、今後出てくる新しい機能には追加費用が発生する可能性があると言及されています。

アクセスするリソース

Copilot in Azure がアクセスできるのはユーザーがアクセスできるリソースのみです。

ユーザーの確認後に、ユーザーが実行する権限を持つアクションのみを実行できます。 Azure ロールベースのアクション制御、特権 ID 管理、Azure ポリシー、リソースロックなど、既存のアクセス管理に Copilot in Azure は従っています。

入力データの扱い

ユーザーが提供するプロンプトと Copilot in Azure の応答は Copilot in Azure のトレーニング、改善に使用されることはありません。

ただし、ユーザーが明示的に同意した場合はデータが収集され、Microsoft 製品とサービスの向上に使用されます。チャットセッションの数とセッション期間、特定のセッションで使用された Copilot スキル、高評価、低評価、フィードバックなどのユーザーエンゲージメントデータを収集します。この情報は、Microsoft プライバシーステートメントに規定されているとおりに保持され、使用されます。

アクセス管理

既定ではテナント内のすべてのユーザーが Copilot in Azure を利用できます。

もし Copilot in Azure の利用を制限したい場合はテナントのグローバル管理者がアクセスを管理できます。また、特定のユーザーまたはグループにだけアクセス権を付与することもできます。

詳しい手順はこちらのドキュメントをご確認ください。

制限

現在、Copilot in Azure には以下の制限があります。

24 時間を超える同一会話はできない
同時に 10 個を超えるリソースへのアクションはできない
一部の回答で一覧表示が上位 5 項目に制限される
一部のタスクとクエリでリソース名を使用できない
過度な利用時の Copilot in Azure への一時的なアクセス制限

Copilot in Azure を使ってみよう

それでは Copilot in Azure を使ってみましょう。

Copilot in Azure は「Azure Portal」と「Azure mobile app」そして「AI Shell」から利用できます。 Azure Portal の場合は、ポータル上部にある Copilot ボタンを押すと、ポータル右端に Copilot 専用の画面が表示されます。

この画面にプロンプトを入力して Copilot in Azure を操作します。

Copilot in Azure のドキュメントには Copilot in Azure を使うためのサンプルプロンプトや、Copilot in Azure を活用できるシナリオ例が記載されています。活用シナリオは大きく 3 つのジャンルに分けられています。

Azure 環境を理解する
Azure サービスでよりスマートに作業する
コードを記述して最適化する

その中でも、Copilot in Azure の活用シナリオをいくつか試してみました。

【Azure 環境を理解】コストを分析する

このシナリオでは Azure に構築したリソースなどの情報を Copilot in Azure に聞くことができます。

「過去 6 か月間のコストを集計してください。」と尋ねてみました。すると、特定サブスクリプションで発生しているコストを Azure サービス単位で表示してくれました。

また、「コスト分析で表示」というリンクを選択してみると、Copilot in Azure を開いている Azure Portal の画面で Cost Management が表示されました。しかもデフォルトのビューではなく、Copilot in Azure が作ったビューが表示されており、ちゃんとプロンプトで指定した「過去 6 か月間」を反映した期間になっています。

つづけて、サンプルにあわせて「コストを削減するにはどうすればよいですか？」と尋ねてみます。

すると、「特定のリソースを選択して、対応する推奨事項を表示する？」という回答とともに [Yes] と [No] ボタンが表示されました。 [Yes] ボタンを押してみると、Azure Portal にリソース選択画面が表示されました。サブスクリプション全体ではなく、リソースを絞ってコスト削減を図るようです。

今回は Azure AI Service のリソースを選択しました。すると、Azure Advisor を元にコスト削減方法をいくつか提案してくれました。

【よりスマートに作業】コマンドを実行する

このシナリオでは Copilot in Azure にリソースを操作するコマンドを実行してもらいます。

まずは仮想マシンを停止してみます。「◯◯という VM を停止してください。」というプロンプトを渡します。

すると、Copilot in Azure からコマンドが実行されます。無事に仮想マシンの停止に成功しました。

反対に、仮想マシンの起動もできます。

一方、「リソースグループを削除してください。」というプロンプトに対しては、リソースグループを削除する方法を回答するだけで、Copilot in Azure からリソースグループの削除はできませんでした。 Copilot in Azure を使ったリソースの操作はある程度制限されているようです。

【コードを記述して最適化】Terraform 構成を生成する

このシナリオでは Azure リソースに関する Terraform 構成を Copilot in Azure に作ってもらいます。

今回はサンプルと同じく、Container Apps と Log Analytics 作る構成としています。先程までのシナリオと異なり、プロンプトは少し複雑になっています。

クイックスタートイメージを使用して、名前が「myApp」の Container Apps リソースの Terraform 構成を作成します。
PerGB2018 SKU の Log Analytics ワークスペースを追加し、保持日数を 31 日に設定します。
Container Apps でシングルリビジョンモードを有効にし、CPU とメモリの制限をそれぞれ 2 と 4 GB に設定します。
また、Container Apps Environment の名前を「awesomeAzureEnv」に設定し、コンテナの名前を「myQuickStartContainer」に設定します。

この内容で Copilot in Azure に問い合わせた結果、Terraform 構成が出力されました。

provider "azurerm" {
  features {}
}
resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_log_analytics_workspace" "example" {
  name                = "acctest-01"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  sku                 = "PerGB2018"
  retention_in_days   = 31
}

resource "azurerm_container_app_environment" "example" {
  name                       = "awesomeAzureEnv"
  location                   = azurerm_resource_group.example.location
  resource_group_name        = azurerm_resource_group.example.name
  log_analytics_workspace_id = azurerm_log_analytics_workspace.example.id
}

resource "azurerm_container_app" "example" {
  name                         = "myapp"
  container_app_environment_id = azurerm_container_app_environment.example.id
  resource_group_name          = azurerm_resource_group.example.name
  revision_mode                = "Single"

  template {
    container {
      name   = "myquickstartcontainer"
      image  = "mcr.microsoft.com/k8se/quickstart:latest"
      cpu    = 2
      memory = "4Gi"
    }
  }
}

出力された Terraform 構成が正しいかどうかは実際に Terraform Plan を試す、レビューする等のチェックが必要です。

今回は手直しなく Azure リソースを作成できる Terraform 構成になっていました。リソース間の参照も適切に設定されていていい感じの Terraform 構成ですね。

一方、出力された Terraform 構成を Copilot in Azure から実行することはできません。自動的にストレージアカウントにリモートステートを作ってくれる、みたいなことは対象外のようです。

Copilot in Azure から Terraform Apply はできない

まとめ

Microsoft Copilot in Azure が GA されました。

Copilot in Azure によって自然言語で Azure リソースを扱える
無料で全ユーザーが Copilot in Azure を利用可能 (2025/4/9 時点)
ドキュメントに Copilot in Azure の利用シナリオが掲載

ぜひ Copilot in Azure を活用して、素敵な Azure ライフをお過ごしください。

2025-03-31

【Azure】 FunctionsからApplication Insightsのログ出力を行う

Azure

はじめに

こんにちは。クラウド事業部の菅家です。
これまで、Application InsightsとFunctionsについて学習したところ、
今回はこれを組み合わせてFunctionsアプリにてApplication Insightsにログを出していこうと思います。

関連記事：
techblog.ap-com.co.jp

やることや詰めておきたいこと

使用するTrigger

Funtctionsは外部要因に起用しないTimerTriggerを使用します。
@TimerTrigger：タイマートリガーを使用すると、関数を実行するタイミングを指定する CRON 式を指定して、スケジュールに従って関数を実行できます。

詰めておきたい、ログのこと

ログに関しては「ExecutionContext Interface」の「getLogger()」メソッドからLoggerを取得し、ログ出力する想定です。

得られるLoggerの型は「abstract java.util.logging.Logger」、JavaのLoggerのようですね。
このままだと、ログの話になりそうなのでログの話はここまで。
いっぱいありすぎてとってもややこしいのです、Javaのログ。

参考記事、こちらが分かりやすかったです。
qiita.com

作業

1.Application Insightsの作成と紐づけ

①Application Insightsの設定をします。Azureポータルにログイン。

②「Application Insights」サービスに移動。
新規作成でリソースを作っていきます。

「Review+create」でリソース作成。

③「App Services」サービスに移動し、デプロイしたFunctionsアプリを開きます。

④左メニューから「監視＞Application Insights」をクリック。
前作った時はありもののApplication Insightsを適当に紐づけましたので、「リソースの変更＞既存のリソースの選択」

「適用」をクリック。

2.IntelliJにて、TimerTriggerを追加する

①プロジェクトの作成に関しては「【Azure】IntelliJからAzureFunctionsアプリを作成してデプロイする - APC 技術ブログ」の記事でやりましたので、これをそのまま流用します。

②ソースフォルダ配下のorg.example.functinosパッケージにて右クリックし、「New＞Azure Function Class」を選択
Packageはそのまま（作りたいパッケージで右クリックしたので）、Function Nameはサンプルに合わせて「TimerTriggerJava」とします。
Binding Typeを「TimerTrigger」に変更。

Scheduleですが、私はcronの書き方を確認。

qiita.com

分 時 日  月 曜日
 *  *  *  *   *

とのことなので、デフォルトでは毎分の0秒で実行（1分）で処理が実行される模様。

0 0 * * * *

一先ず1時間ごとで0分に実行されるようにします。

③OKをクリックすると、クラスと同時に自動でメソッドが作成されました。
何と便利。

package org.example.functions;

import java.time.*;
import com.microsoft.azure.functions.annotation.*;
import com.microsoft.azure.functions.*;

/**
 * Azure Functions with Timer trigger.
 */
public class TimerTriggerJava {
    /**
     * This function will be invoked periodically according to the specified schedule.
     */
    @FunctionName("TimerTriggerJava")
    public void run(
        @TimerTrigger(name = "timerInfo", schedule = "0 0 * * * *") String timerInfo,
        final ExecutionContext context
    ) {
        context.getLogger().info("Java Timer trigger function executed at: " + LocalDateTime.now());
    }
}

Triggerに対してスケジュールも設定されています。
見ればロガーもサンプルとしてありますね。

context.getLogger().info("Java Timer trigger function executed at: " + LocalDateTime.now());

④Info、Warningログを処理実装してみる
Errorログを出したいため、logメソッドがよさそうです。

docs.oracle.com

まず、Loggerを使いまわしたいので元のログ出力処理を削除して、「Logger logger= context.getLogger();」とします。

Info、Warningのログ出力処理を実装してみます。

package org.example.functions;


import com.microsoft.azure.functions.annotation.*;
import com.microsoft.azure.functions.*;

import java.io.IOException;
import java.util.logging.Level;
import java.util.logging.Logger;

/**
 * Azure Functions with Timer trigger.
 */
public class TimerTriggerJava {
    /**
     * This function will be invoked periodically according to the specified schedule.
     */
    @FunctionName("TimerTriggerJava")
    public void run(
        @TimerTrigger(name = "timerInfo", schedule = "0 0 * * * *") String timerInfo,
        final ExecutionContext context
    ) {
        Logger logger= context.getLogger();
        logger.log(Level.INFO, "INFO Message");

        try {
            throw new IOException();
        } catch (Exception e) {
            logger.log(Level.WARNING, "WARNING Message:" + e.getMessage(), e);
        }
    }
}

3.デプロイ・動作確認

①デプロイ選択。

②デプロイ完了。

③20:00前後のログで、UTCなので-9時間した値で探します。11時ごろですね。

クエリ

union * 
| where operation_Name contains "TimerTrigger" 
| where timestamp >= datetime(2025-03-30 10:30:00) and timestamp < datetime(2025-03-30 11:30:00)
| order by timestamp desc

union *で全テーブルを結合し、TimerTrigger関連のログを検索。
カラムを絞って結果を出したところこんな感じ、エラークラス出力のためe.class()の方がよかったかも。

Functions＞関数名をクリック＞ログ、にて動作ログも出てました。

おわりに

今回は、AzureFunctions＋Application Insightsで単純ログ出力するシンプルな処理を実装してみました。
Host.jsonを使用したFunctionsのログレベルの設定など、まだまだカスタマイズできる点は多そうです。

お知らせ

私達クラウド事業部はクラウド技術を活用したSI/SESのご支援をしております。
https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です！ご興味持っていただけましたらぜひお声がけください。 hrmos.co

本記事の投稿者: s-sugaya
AWSをメインにインフラ系のご支援を担当しています。

2025-03-27

【Azure】AzureFunctionsアプリのJava構文を読む

Azure

はじめに

こんにちは。クラウド事業部の菅家です。
techblog.ap-com.co.jp 前回、公式チュートリアルに従ってIntelliJからFunctionsのアプリを作成し、デプロイをしてみたところ。
やはり構造などがわからないと、なかなかプログラムを自力で書くのは難しいもので、
書き方の通例を学んでFunctionsの基礎を学んでいきたいと思います。

関数の定義方法

@FunctionName("Azureで表示する関数名")
public HttpResponseMessage run(...)

@FunctionNameアノテーションを特定のメソッドの上に記載することで、関数が定義できます。
Azure上での関数名はアノテーション側で定義するため、アノテーションを付けるJavaメソッド側の名前は任意となります。
デプロイ後、Functionsアプリケーションの関数一覧に表示されます。

Functions
　｜ー関数1
　｜ー関数2
　｜ー関数3
　｜ー関数4
　｜ー関数5
...

このようにFunctions1つに対して関数は複数定義できるようです。

Functionsってどこから開始するの？

Javaといえばpublic static void main(String[] args)ですが、Functionsはイベントをトリガーとしてプログラムを実行します。
○○をクリックしたなど、デスクトップアプリやWebアプリなどに感覚としては近そうです。

トリガーの種類としては以下が参考になりそうです。
learn.microsoft.com
com.microsoft.azure.functions.annotation.*パッケージ内の「○○Trigger」が該当します。

ざっと日本語訳したものまとめ

@HttpTrigger ：HttpTrigger アノテーションは、関数が配置されている HTTP エンドポイントへの呼び出しによってトリガーされる Azure 関数に適用されます。
@TimerTrigger：タイマートリガーを使用すると、関数を実行するタイミングを指定する CRON 式を指定して、スケジュールに従って関数を実行できます。
@BlobTrigger：これを、BLOB から値を取得するパラメータに配置し、BLOB がアップロードされたときにメソッドが実行されるようにします。
@QueueTrigger：これを、ストレージキューから値を取得するパラメーターに配置し、新しい項目がプッシュされたときにメソッドが実行されるようにします。
@EventHubTrigger：これを、イベントハブから値が取得されるパラメーターに配置し、新しいイベントが到着したときにメソッドが実行されるようにします。
@ServiceBusQueueTrigger：これを、Service Bus キューから値を取得するパラメーターに配置し、新しい項目がプッシュされたときにメソッドが実行されるようにします。
@ServiceBusTopicTrigger：これを、Service Bus トピックから値を取得するパラメーターに配置し、新しいアイテムが公開されたときにメソッドが実行されるようにします。
@CosmosDBTrigger：これを、CosmosDB から値を取得するパラメータに配置し、CosmosDB データが変更されたときにメソッドが実行されるようにします。
@EventGridTrigger：これを、EventGrid から値が取得されるパラメータに配置し、イベントが到着したときにメソッドが実行されるようにします。

バインディングについて

また、バインディングという概念もある模様。
遅延バインディングなどは聞いた記憶がありますが、正直何だったか思い出せないので復習します。

以下の記事によると

バインドでは、データを関数に渡し、関数からデータを返す方法が提供されます。

とのこと。
それから、関数定義において「String req」がバインド引数であるところ。

public class Function {
    public String echo(@HttpTrigger(name = "req", 
      methods = {HttpMethod.POST},  authLevel = AuthorizationLevel.ANONYMOUS) 
        String req, ExecutionContext context) {
        return String.format(req);
    }
}

このことから関数において入出力データの受け渡しを担うのがバインドというところになります。
トリガーによって何をバインドするかは変わるため、使い方に関しては各Triggerアノテーションを見るのが良さそうです。
@HttpTriggerはわかりやすい感じがします。「HttpRequestMessage<Optional> request」なのでなにかしらのリクエストの内容が見られそうです。

アノテーションによってバインドを自分でカスタマイズできるし、各トリガーごとの入出力についても記載があります。
learn.microsoft.com

Functionsメソッドの引数について

わかりやすそうかつ、ほかサービスとの連携がないものとして「@HttpTrigger」「@TimerTrigger」がサンプルとしていいかなと思い、リファレンスを読んでみます。

リファレンス
@HttpTrigger
learn.microsoft.com

@FunctionName("hello")
  public HttpResponseMessage<String> helloFunction(
    @HttpTrigger(name = "req",
                  methods = {HttpMethod.GET},
                  authLevel = AuthorizationLevel.ANONYMOUS) HttpRequestMessage<Optional<String>> request
  ) {
     ....
  }

@TimerTrigger*
learn.microsoft.com

@FunctionName("keepAlive")
 public void keepAlive(
    @TimerTrigger(name = "keepAliveTrigger", schedule = "0 */5 * * * *") String timerInfo,
     ExecutionContext context
 ) {
     // timeInfo is a JSON string, you can deserialize it to an object using your favorite JSON library
     context.getLogger().info("Timer is triggered: " + timerInfo);
 }

完全にAzureに関係のないJava余談ですが私は自作アノテーションを作ったことがないので、インターフェースなんだとすごく興味津々でリファレンスを眺めております。
「implements java.lang.annotation.Annotation」アノテーションInterfaceを実装するんですね。

引数①
定義の作りとしては、まず引数に「@HttpTrigger」などのトリガーがあるというところ。トリガーのnameは関数単位で一意であれば良さそうです。
function.jsonに定義されているとか。そういえばAzureのUI上から関数の画面を開いたときに「function.json」を見るみたいなところがありましたので、デプロイされてから定義ファイルに落とし込まれるようですね。
トリガーの設定と考えると良さそうです。

引数②
「HttpRequestMessage<Optional> request」「String timerInfo」これがバインディング関連。
HttpRequestMessageに関しては、書いても書かなくてもいいOptionalですね。
「String timerInfo」は関数がトリガーされた際のスケジュール情報が入っているようです。

引数③
最後にfinal ExecutionContext context。
正直一番気になってました。

リファレンス
learn.microsoft.com

The execution context enables interaction with the Azure Functions execution environment. 実行コンテキストにより、Azure Functions 実行環境との対話が可能になります。

Javaのインターフェース＝規格やシナリオ、外部・他機能との接続部品やデータ受け渡し部品のイメージが私の中でとても強いんですけども、なんとなくこのイメージに合いそうです。
finalは値の変更防止だそうで、情報を自分で書くわけでもこの内容を送るわけでも無いのでつけるのが無難な気がします。

getLogger() Returns the built-in logger, which is integrated with the logging functionality provided in the Azure Functions portal, as well as in Azure Application Insights.

これ、Application Insightsでログを出すためのメソッドっぽいですね。
関数名や呼び出しIDの取得、ロガーの取得。トレースコンテキスト（エラーログなどの意図的に出してない自動生成ログみたいなもの）の取得などの機能があります。
引数①②はトリガーとのやり取りでしたが、Azure Functionsそのものとのやり取りをするのがこのインターフェースだと理解しました。

Functionsアプリケーションの構造について

調べてみましたが、JavaアプリケーションにおけるFunctions用のフレームワークやベストプラクティスのような構造は見つかりませんでした。
src/main配下（今回はGradleのため）は、一般的なmodelやutilなどよく見るパッケージ構成で良さそうです。
Lombokなどと組み合わせるのもできるので、getter/setter/コンストラクタ定義を省きたいであったり、DBを使うなどで他フレームワークとうまく共存するのはありですね。

おわりに

今度はここからApplication Insightsとの連携をし、実際にログを出していこうと思います。
外部アクセスや他リソースの動きに依存しない@TimerTriggerで試すのが良さそうです。
　　→トリガーを使って実行、何かしらの実行結果を得る
　　→Application Insightsに文字を表示する
こちらに手を付けていければと思います。

お知らせ

私達クラウド事業部はクラウド技術を活用したSI/SESのご支援をしております。
https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です！ご興味持っていただけましたらぜひお声がけください。 hrmos.co

本記事の投稿者: s-sugaya
AWSをメインにインフラ系のご支援を担当しています。

2025-03-26

【Azure】IntelliJからAzureFunctionsアプリを作成してデプロイする

Azure

はじめに

こんにちは。クラウド事業部の菅家です。
前回Application Insightsが便利だったという記事を書いたところ。

自分でログを出してみたく、まずはIntelliJにて関数アプリを作成してみようというところでチュートリアルを見つつ進めてみました。

進めながら悩んだ点などを含めて書いていこうと思います。

やったこと

下準備

①リソースグループの作成

後でFunctionsと一緒に作る、でもいいんですが、Azure上でリソースグループを作成しておきます。

名前は「s_sugaya__function_test_02」とします。

②IntelliJのインストール

IDEです。Javaを書く際に使うとともにAzureプラグインがあるため、プロジェクトを簡単作成できます。

www.jetbrains.com

③IntelliJに「Azure Toolkit for IntelliJ」プラグインをインストール

設定＞プラグイン＞「Azure Toolkit」などで検索し、マーケットプレイスからプラグインをインストールします。

インストールできたらIntelliJを一先ず再起動。

公式記事の通りAzureにサインインします。
テナントにあるリソースが「Azure Explorer」上で表示されているか確認します。
リソースがうまく表示されない、などあれば再度サインイン。
learn.microsoft.com

プロジェクトの作成とデプロイ

①Azureプロジェクトの作成

ファイル＞新規＞プロジェクトから、

「Azure Functions」を選択すると、Functions用のプロジェクトを生成してくれます。
SDKはJava11とし「HTTPTrigger」としました。
色々なトリガーがありますが、HTTPTriggerのため、curlなどでAPIのように呼び出せるようです。

ビルドツールに関してはGradleを選択。これに関しては私の趣味です。

プロジェクト名を入力したら、「作成」ボタンをクリックしてプロジェクト作成します。
なんとサンプルコード付き。ありがたし。

このままデプロイしていきます。
ローカル実行には他インストール手順が必要となるので今回は割愛。

②Azure Functions リソースの作成

ここが設定が分からなくて結構詰まりました。
やり方としては、IntelliJの「Azure Explorer」から「＜⚡＞Function App」を右クリックし、メニューから「Create」をクリックします。

Nameに任意の名前を付けます。
Platformは今回はSDKに合わせてWindow-Java11。ランタイムとしては8,11,17が対応しているようです。

「More settings」にチェックを入れてさらに設定していきます。

リソースグループは先ほど前準備で作成したものを設定。

この時、デプロイできなかったりリソースグループが見つからない場合は、「Azure Explorer」で再度サインインしてみてください。
左下に警告表示も出ます。

AppServicePlanですがAzureのFunctions新規作成画面上だと、こんなかんじ。

IntelliJだと他にもプランを選べるので、Freeにしようかなと思ってIntelliJ側でFreeとしたところ、
Functionsではなく、AppServiceができてしまったのでご注意です。
Functionsを作るなら画面でも表示されたものを選択しましょう。

Flex Consumption plan
Premium plan
Dedicated plan
Container Apps
Consumption plan