2025-08-11

生成AI時代だからこそのAzure AI Services活用術（その２）～リソースの指定方法～

AI Azure Azure AI Services

はじめに

hatsune.hatenablog.jp

Azure AI Serviecsのエンドポイントについて

Azure AI Servicesは、登場当初は様々なURL（エンドポイント）で提供されていました。現在は、Azure AI Servicesの統一したURLで提供されています。

エンドポイントの例外

ただし、Speech ServiceとTranslatorの２つについては、統一したURLではなく登場したときのURLでのアクセスとなります。
ただし、その場合でも、キーについては統一したキーで利用可能です。
１例としてSpeech Serviceについて、実際にAzure ポータルでリソースを作成して比較してみましょう。

Speechリソースとして作成した場合

Speechリソースを指定

Azure ポータルにサインインしたら、

サイドメニューの［リソースの作成］をクリック
［Azureサービスのみ］チェックとして［Marketplaceを検索］欄で「音声」と入力して検索
［音声］リソースの［作成］をクリック

するとSpeechリソースとして音声認識/音声合成などが可能なSpeech ServiceというAIが使えるようになります。

Speech Serviceリソースを設定

Speech Serviceリソースを作成するために必要な設定を行うときに重要なのは次の点です。

リージョン：利用する地域を選択（レイテンシーが早く、域内にすることでデータ保護関連に抵触しないため）
名前：自リソース内での識別子となるのでわかりやすい名前を指定
価格レベル：Freeであれば時間制限ありだが無料利用も可能

Speech Serviceリソースのエンドポイント

作成したSpeech Serviceリソースへアクセスするためのエンドポイントは次のようになります。

https://japanwest.api.cognitive.microsoft.com/

リソース作成時に指定した名前などは含まれず、リージョンとキー値で利用するリソースが特定されます。
Speech ServiceとTranslator以外のAIサービスのエンドポイントは、リソースエンドポイントと同一となります。

Speech Serviceのサービスエンドポイント

Speechリソースのリージョンとして「japanwest」を指定した場合、
音声からテキストにする（いわゆる文字起こし）するSpeech to Text APIのエンドポイントは次のようになります。

https://japanwest.stt.speech.microsoft.com

同様にテキストから音声にする（いわゆる音声合成）するText to Speechのエンドポイントは次のようになります。

https://japanwest.tts.speech.microsoft.com

なお、このエンドポイントにアクセスするときのキー値は、Azure AI Servicesのキー値となります。

Azure AI Serivicesリソースとして作成した場合

Azure ポータルにサインインしたら、

サイドメニューの［リソースの作成］をクリック
［Azureサービスのみ］チェックとして［Marketplaceを検索］欄で「Azure AI サービス」と入力して検索
［Azure AI サービス］リソースの［作成］をクリック

するとAzure AI Serivcesリソースとして、そこに含まれるAIに対して単一エンドポイントでアクセス可能なリソースが作成できます。

Azure AI Serivicesリソースを指定

Azure AI Serivcesリソースを作成するために必要な設定を行うときに重要なのは次の点です。特に名前が重要です。

リージョン：利用する地域を選択（レイテンシーが早く、域内にすることでデータ保護関連に抵触しないため）
名前：グローバルで唯一の名前の指定が必要なので製品名など入れるとよい
価格レベル：Standardプランのみ指定可能（Freeがない）

Azure AI Serivicesリソースのエンドポイント

作成した Azure AI Serivicesリソースへアクセスするためのエンドポイントは次のようになります。

https://[名前].cognitiveservices.azure.com/

作成時に指定した名前を含んだ専用のエンドポイントとなります。
ただし、Speech ServiceとTranslatorについては、個々のエンドポイントとなります。

Speech Serviceのサービスエンドポイント

Azure AI Serivicesリソースのリージョンとして「japaneast」を指定した場合、
音声からテキストにする（いわゆる文字起こし）するSpeech to Text APIのエンドポイントは次のようになります（）。

https://japaneast.stt.speech.microsoft.com

同様にテキストから音声にする（いわゆる音声合成）するText to Speechのエンドポイントは次のようになります。

https://japaneast.tts.speech.microsoft.com

なお、このエンドポイントにアクセスするときのキー値は、Azure AI Servicesのキー値となります。

Azure AI Foundlyとの関係

AzureのAI関連としては、「Azure AI Services」以外に「Azure AI Foundly」もあります。
この両者の関係は次のような関係です。
「Azure AI Foundly」＝「Azure AI Services」+「生成AIモデル」
つまり、Azure AI Foundlyリソースとして、Azure AI Serviceに含まれているAIサービスを使うこともできます。

Azure AI Foundlyリソースとして作成した場合

Azure ポータルにサインインしたら、

サイドメニューの［リソースの作成］をクリック
［Azureサービスのみ］チェックとして［Marketplaceを検索］欄で「Azure AI Foundly」と入力して検索
［Azure AI Foundly］リソースの［作成］をクリック

するとAzure AI Foundlyリソースとして、そこに含まれるAIに対して単一エンドポイントでアクセス可能なリソースが作成できます。

Azure AI Foundlyリソースを指定

Azure AI Foundlyリソースを作成するために必要な設定を行うときに重要なのは次の点です。特に名前が重要です。

リージョン：利用する地域を選択（レイテンシーが早く、域内にすることでデータ保護関連に抵触しないため）
名前：グローバルで唯一の名前の指定が必要なので製品名など入れるとよい
価格レベル：Standardプランのみ指定可能（Freeがない）

Azure AI Foundlyリソースのエンドポイント

作成した Azure AI Serivicesリソースへアクセスするためのエンドポイントは次のようになります。

https://[名前].services.ai.azure.com/

作成時に指定した名前を含んだ専用のエンドポイントとなります。
ただし、Speech ServiceとTranslatorについては同様に個々のエンドポイントとなります。

Azure AI Foundlyポータル

Azure AI Foundlyリソースにアクセスすると「Azure AI Foundlyポータル」への移動リンクがあります。

すべてのエンドポイントを表示

リンクをクリックしてポータルに移動したら、［すべてのエンドポイントを表示する］リンクをクリックしてみてください。

Speech Serviceのエンドポイントを表示

［サービスエンドポイント］をクリックすると、Azure AI Servicesに含まれるAIサービスが一覧表示されるので「Azure AI 音声」=Speech Serviceをクリックします。
表示された内容から、Speech Serviceのサービスエンドポイントは、他の方法で作成したときと同じことがわかります。

最後に

今回は、Azure AI Servicesに含まれている各AIサービスを使うためのリソース作成方法を３種類紹介しました。
どの方法で作成しても、サービスエンドポイントはほぼ同じであり、そこから先の利用方法は同一となります。
３種類の中でお勧めの方法としては、「Azure AI Foundly」で作る方法となります。この方法の利点は、「プレイグラウンド」がある点です。
このプレイグラウンドを使うことで、ノーコードでAIサービスを試すことが可能です。どのようなAIかを確認できます。

次回以降は、この「プレイグラウンド」も活用し、１つ１つAIサービスを見ていきましょう。生成AIのみで完結するのも１つの方法ですが、Auzre AI Servicesも併用し、より効果的な問題解決ができるかを検討してみる一助になれば幸いです。

2025-08-09

生成AI時代だからこそのAzure AI Services活用術（その１）

AI Azure Azure AI Services

はじめに

皆さんこんにちは、去年までのWindows Development / Mixed Realityカテゴリから今年度はAzure AI Servicesカテゴリになった初音です。

Microsoft Azureでは、様々なAIサービスが提供されています。
夏季休暇で集中した時間がある（とはいえ家の掃除や映画を見に行ったりと余暇も満喫しつつ）ので、その中の１つであるAzure AI Servicesについて何回かに分けて紹介していきます。

Azure AI Servicesのはじまり

Azure AI Servicesは、2016年ころに顔認識、音声認識、言語理解などのAI機能をAPIで提供した「Azure Cognitive Servies」が始まりでした。
hatsune.hatenablog.jp
Face APIやSpeech APIなどは2015年には登場してきていましたが、この2016年にCognitive Serviceとして様々なAPIが一気に登場してきました。

利用可能なAzure AI Servicesについて

2016年に登場したあと、APIエンドポイントとしてバラバラであったCognitive Serviceから、いくつかのAIについて「https://xxxxxxxxx.cognitiveservices.azure.com」というエンドポイントに統一化されて、Azure AI Servicesの中にAPIという位置づけになっています。
Azure AI Servicesとして、2025/08/09時点で利用可能なAPIとしては次のようなものがあります。

サービス	説明
Content Moderator	(非推奨：2027/02廃止予定) Content Safetyを使用
Content Safety	不快、危険、望ましくない画像やテキストを判断
Language Understanding	会話意図理解 (非推奨：2026/03/31廃止確定) Language Serviceの「Language Understanding」を使用
Language	テキストを理解し分析するための自然言語処理 (NLP) 機能を提供
Translator	テキスト翻訳
Speech Service	音声認識/音声合成/音声翻訳など
Computer Vision	画像と動画のコンテンツを分析
Custom Vision	独自カスタマイズ可能な画像認識
Face	画像内の人や感情を検出および識別
Document Intelligence	いわゆるOCR機能

おわりに

次回は、一覧に掲載したAzure AI Servicesについて、順番に詳細説明やC#やPythonを使った実際に使うためのコード解説をしていく予定です。
それが終わったら、Azure AI Servicesを含む形のもう少し大きなAzure AI機能である「Azure AI Foundry」についての触れていく予定です。
生成AIのみで完結するのも１つの方法ですが、Auzre AI Servicesも併用し、より効果的な問題解決ができるかを検討してみる一助になれば幸いです。

2025-07-11

Microsoft MVP 受賞報告

AI Azure MicrosoftMVP 開発勉強会

2024-2025 Microsoft MVP for Azure AI Servicesを受賞しました。
2008年から18年連続となります。

今後も、自分の興味のある技術をコミュニティや社会にフィードバックできるように、状況に応じて自分ができる範囲で無理せずコミュニティ活動を続けていけたらと思います。

AIからアウトプット先としてのHMDなどのXRデバイスへの興味は失っていませんので、更に力をいれていきたいと思います。
また、Thunkableをつかったローコード開発でのAI利用ついても引き続き注目していきます。

Windows DevelopmentからMixed Realiy、そして、Azure AI Servicesへとカテゴリ移動となりましたが、引き続きよろしくお願いいたします。

2025-05-21

Microsoft Build Day 2

AI Azure

Microsoft Build Day 2が始まりました。
最近のBuildではDay 2もキーノートがあるのですね。
Day 2 キーノートも、話題の中心は「エージェントAI」でしたがBuildらしく「どうつくるのか」を中心とした話題でした。
MCPクライアントやMCPサーバー作成用のSDKの紹介もあり、いよいよFY25は「実際にうごく」取組が重要になってきた感じですね。

さてその中でも、本日注目のセッションを列挙してみました。

キーノート同様にAI Agent関連が多いですね。

2025-05-20

Microsoft Build 2025 Day1

Azure AI

Build 2025が始まりました。
build.microsoft.com
今回のキーノートで一番気になったトピックは「Open Agentic Web」です。
そして、エージェント作成ツールとしてCopilot Studioの新機能である「Computer Use」「Agent Flows」、そして会社内のデータを使ってチューニングするための「Copilot Turning」も発表されました。

そしてWindowsがネイティブでMCP（Model Context Protocol）をサポートする発表も注目ですね。
MCP対応することで、下記のようなことが可能になります。

AI <-> MCPクライアント <-> Slack用MCPサーバー <-> Slack

Windowsのアプリ用MCPサーバーがOSに標準搭載されることで、AIエージェントからのWindowsの操作がすごく楽になります。

例えば、Visual Studio CodeのCopilit Chatから各種アプリ操作などが可能になります。

Generative AI→Agentic AIときFY25はMCPサポートが注目すべき技術となりそうですね。

2025-04-11

DNS伝搬チェッカー

AI Azure docker

久々に自分でDNSサーバにレコード追加する作業をしたのでDNS伝搬チェッカー『Global DNS Propagation Checker』を時々眺めています。

物理的な距離とは違うところが面白いですね。

2025-03-30

Azure AD B2Cでユーザ認証するアプリをMAUIで作ろう

Azure C# AI MAUI ADB2C

AIを使ったアプリケーションを作る場合、「誰が使ったか分かるようにしてほしい」というのが要件として依頼される場合があります。
Windowsアプリに限らず、自分たちでユーザ管理部分まで作ろうと思うと、本来注力したいAI活用部分だけではなく、ユーザ管理用の仕組み、データベースなどの付随的なサーバやその管理までも発生します。
そのような、あえて言うのであれば本質ではない部分は他に任せたいとしたときの選択は次の２つです。

その部分をつくってくれる人/会社に依頼する
Azure AD B2Cを活用する

今回は「Azure AD B2C」を活用する方法を紹介します。
更に、Webアプリよりも「どこを作るのか」、「どう動くのか」が分かりやすいWindowsアプリとして作成する方法を紹介します。

Azure AD B2Cとは？

Azure Active Directory B2C（Azure AD B2C）は、Microsoftが提供するクラウドベースのアイデンティティ管理サービスです。これにより、企業や開発者は自社のアプリケーションに対して、安全でスケーラブルなユーザー認証を簡単に実装できます。Azure AD B2Cは、ユーザーがGoogle、Facebook、Microsoftアカウントなどの既存のソーシャルアカウントを使用してサインインできるようにするほか、独自のローカルアカウントもサポートします。

このサービスは、ユーザーの登録、サインイン、パスワードリセットなどの機能を提供し、カスタマイズ可能なユーザーエクスペリエンスを実現します。また、セキュリティとコンプライアンスの要件を満たすための高度な機能も備えています。Azure AD B2Cを利用することで、開発者は認証機能の実装にかかる時間と労力を大幅に削減し、アプリケーションの開発に集中することができます。

Azure AD B2Cの説明について

上記の説明はMicrosoft Copilotに以下のプロンプトを投げて作成したものを微調整して掲載しました。

あなたは技術ブログの執筆者です。
今回は、AI活用アプリにAzure AD B2Cを使ってユーザ認証を行うための情報をブログに記載します。
そのイントロダクションとして「Azure AD B2Cとは？」というタイトルでAzure AD B2Cという名称を始めて聞く人にもわかるように500文字以内（短ければ短いほど良い）で文章を作成してください。なお、冒頭で必ずAzure AD B2Cの正式製品名を入れてください。

Azure AD B2Cの設定

Azureポータルサイトに入り、ActiveDirectory B2Cサービスにアプリを登録します。
今回は、新たに「Azure AD B2C」のリソースをつくるのではなく、Azureポータルに入っているリソース上にアプリを登録することにします。

Azure AD B2Cのリソースを分けると何ができる？

今回は、Azure AD B2Cのリソースを新規に作成しませんが、Azure AD B2Cはリソースを分けることで「Azure AD B2C テナント」が作成できます。
テナントが分かれていると組織名や初期ドメイン名を別にすることが出来ます。

また、アプリ登録やユーザ管理なども別になります。
次のようなときは、Azure AD B2Cの新規リソースを作成しましょう。

同じサブスクリプションで別のアプリを登録したいとき
同じアプリでもユーザ管理を別にしたいとき

おすすめとしては、アプリ開発・検証用としては、今回のようにリソースを新規作成せず、本稼働用には新しいリソースでという住み分けです。
こうすることで、重要な認証周りで、開発・検証用と本稼働用が混ざることを防止できます。

AD B2Cにアプリを登録

「リソースの追加」ではなく画面上部の検索ボックスで「Azure AD B2C」として検索し、すでにある「Azure AD B2C」リソースの機能の概要にはいります。

アプリの登録

左側のメニューから[アプリの登録]を押して、画面が変わったらメイン画面の上部メニューの「新規登録」を押します。

画面が変わったら、「表示名」、「アカウントの種類」、「リダイレクトURI」を指定します。

表示名：あとから変更できるので「（検証）Azure AD B2C」と仮設定
アカウントの種類：「任意の組織ディレクトリ内のアカウント」を選択
リダイレクトURI：「パブリッククライアント/ネイティブ(モバイルとデスクトップ)」を選択(URLはあとで決めるので未記入)

準備ができたら[登録]をクリックします。

アカウントの種類とは？

今回、「任意の組織ディレクトリ内のアカウント (任意の Microsoft Entra ID テナント - マルチテナント) と個人用の Microsoft アカウント (Skype、Xbox など)」を選択しました。
この選択で、企業向けアカウントと個人向けアカウントの２種類のアカウントで認証できるようになります。

自社内だけということであれば、会社のディレクトリを選択してからAD B2Cにアプリ登録して、「この組織ディレクトリ内のアカウント」とします。
企業向けアカウントのみにしたいということであれば、「任意の組織ディレクトリ内のアカウント (任意の Microsoft Entra ID テナント - マルチテナント)」とします。
特定の企業向けにしたいときは、残念ながらAzure AD B2Cではできません。特定の企業向けにしたいときは「Microsoft Entra External ID」にアプリを登録し、お客様ドメインのみを許可するように設定します。

プラットフォームの追加

AD B2Cでは認証後のアクセストークンの返し方など、プラットフォーム固有の設定が可能です。
[管理]-[認証]メニューをクリックし、「プラットフォームの追加」を選択します。

プラットフォームの選択

今回は「モバイルアプリケーションとデスクトップアプリケーション」を選びます。

リダイレクトURIの設定

リダイレクトURIは、認証が通ったときのトークンの返却先になります。
以前は、３番目を選択すればよかったのですが、Windowsクライアントの場合は、「カスタムリダイレクトURI」として必ず「http://localhost」を指定します。

これでAzure AD B2C側の設定は完了です。

(参考)Webアプリの時のリダイレクトURIの設定

なお、「Webアプリ」を選ぶと、リダイレクトURI、ログアウトURI、アクセストークンにするのかIDトークンにするのかが選択できます。

アプリ作成

.NET MAUIアプリを「MAUIAuthApp」という名前で新規作成します。
新規作成直後に「Windows Machine」ターゲットとしてを「F5」キーを押してデバック実行すると次のような画面が表示できます。

今回は、この「Click Me」のところでAzure AD B2Cを使ってみましょう。

MVVM化

まずはテンプレートから生成されたアプリをMVVM化します。

フォルダ構成の変更

MVVMで作成するので「Models」「ViewModels」「Views」フォルダを作成して「MainPage.xaml」を「Views」フォルダの中に移動します。

MainViewModelの作成

MainPage.xamlとMainPage.xaml.csに入っていたボタン表示とボタンクリック時の動作をMainViewModelに転記します。
gist.github.com

MainPage.xaml.csの書き換え

MVVM化してカウントアップのロジックをViewから切り離したので、MainPage.xaml.csもかなりシンプルになりました。
gist.github.com

あとは、MainPage.xamlもBinding中心の記述に変更します。
gist.github.com

Azure AD B2C対応

nuget追加

次の2つを追加します。

Microsoft.Identity.Client：認証処理用ライブラリ
System.IdentityModel.Tokens.Jwt：トークン解析用ライブラリ

MSALを呼び出す部分の作成

まずは、MSALを呼び出す部分を作成します。
ここで混乱しやすいのは、WithRedirectUriで指定する値です。
以前であれば、ここに「msal～CliendId～://auth」の文字列を指定できていたのですが、今は「http://localhost」のみが指定できます。
gist.github.com

AuthenticationServiceコンストラクタで、Azure側に登録されているアプリ情報を設定します。"common”と指定しているのは「EntraID」+「個人用MicrosoftAccount」が対象だからです。
LoginAsyncのなかは、GetAccountsAsyncメソッドで既に認証されているアカウントがあれば、そのトークンを返却しようと試みています。
認証されているアカウントがなければMsalExceptionが発生するので、AcquireTokenInteractiveAsyncメソッドを呼び出します。
AcquireTokenInteractiveAsyncメソッドの中では、AcquireTokenInteractiveを使って、ブラウザを自動立ち上げしてサインイン用の画面を表示します。この画面もEntraIDまたは個人用MicrosoftAccountのサインイン画面であり、今回のアプリ側の画面ではありません。

AutenticationModelの作成

AuthenticationServiceクラスができあがったので、それを呼び出すモデルを作成します。
gist.github.com
あとは、このモデルをMainViewModelのボタンクリックのところから呼び出すようにします。

private Models.AuthenticationModel Model { get; } = new Models.AuthenticationModel();
～
this.Message = await Model.LoginAsync();

実際の動作について

アプリが完成したので起動して「Click Me」ボタンをクリックします。
自動的にブラウザが開いて、次のようなサインイン画面がでます。

アカウント種別ごとの動きの違い

ここで初回サインインするときに、アカウント種別ごとに動作が異なりますので、分けて説明します。

EntraIDの場合

EntraIDでサインインするときに、AzureADの管理権限がない利用者の場合、次のような画面になります。

管理権限がある場合は、最初の１回だけ次のような画面になります。
[承諾]ボタンをクリックすれば、以降は、管理者権限がない人も含めて、サインインが可能になります。

個人用MicrosoftAccoutの場合

初回だけアプリの利用の同意画面がでてくるので、[同意]ボタンをクリックして先に進みます。

サインインが完了すると

outlook.jpのメルアドもっているときに、メルアドと(outlook.jpの)パスワードを入力するとブラウザには次のように表示されます。

Authentication complete. You can return to the application. Feel free to close this browser tab.

そして同時にアプリ側ではアクセストークンが取得でき、中身にはClientIdなどが含まれていて認可情報がアプリで取得できます。

AD B2Cの場合、audはClientIdと同じ値となります。
また、v1 エンドポイントにはあった「unique_name」はv2 エンドポイントにはないため、ユーザを特定するのであれば、「preferred_username」を参照してください。

以上で、Azure AD B2Cでユーザ認証をするアプリの作り方を終わります。

最後に

アプリの使用の保存場所

今回は個人用MicrosoftAccountでサインインしたので、Microsoft Accountサイトのアプリのところに今回のアプリが登録されています。「共有を停止」とすることで、アプリを使用できなくなります。

IDとパスワードの保存場所

今回のようにAzure ADB2Cでユーザ認証した場合、ユーザIDやパスワードはAD B2Cにアプリを登録したところには一切保存されていない点に注意してください。
ユーザIDやパスワードは、利用者が選択したEntraIDまたは個人用MicrosoftAccountを管理している側（つまり今回でいえばEntraIDなら自社のAzureAD）ということになります。

EntraIDでの初回サインインについて

特にEntraIDを使ったサインインについては、その企業で最初にサインインする人は、AzureADの管理者権限がある人にサインインしてもらう必要があり、勝手に自社で使われていたのようなことも防止できるような仕組みになっています。