【Microsoft Azure】Azure FunctionsとAzure OpenAIの連携でポイントとなる要素を解説(パート2)

2025.04.08
【Microsoft Azure】Azure FunctionsとAzure OpenAIの連携でポイントとなる要素を解説(パート2)

こんにちは、MS開発部の渋谷です。

前回のパート1では、Azure Functionsの各プランの特徴と選び方について詳しく解説しました。今回はパート2として、Azure FunctionsとAzure OpenAIを連携させる方法に焦点を当てます。

AIを活用したサーバーレスアプリケーションを開発することで、ユーザー体験を大きく向上させることができます。特に、自然言語処理や機械学習モデルを既存のシステムから付け足す形でAPI連携することで、これまでにない高度な機能を比較的簡単に実装することが可能です。

Azure OpenAIは、最先端のAIモデルをクラウド上で簡単に利用できるサービスであり、Azure Functionsと組み合わせることでスケーラブルかつ高性能なAIソリューションを構築できます。
本記事では、前回の内容の続きとして、Azure FunctionsとAzure OpenAIを組み合わせて高度なAI機能を実装する際にポイントとなる点について詳しく解説します。
(※本記事は2025年2月時点での情報を元にしています。最新情報はマイクロソフト公式ドキュメントをご確認ください。)

Azure Functions のどのプランを利用すればよいか

前回のパート1では、Azure Functionsで提供されるホスティングプランについて解説しました。2024年2月現在、5つのプランが存在しますが、基本的にまずは Flex Consumptionプランを最初の検討ポイントとして考えると良い場合が多いでしょう。

理由として挙げられるのは2つあり、生成AIを利用したアプリケーションという特性から需要の変化が大きくスケーリングの速度が重要であるということと、仮想ネットワークへの接続がサポートされていることです。

例えば、Azure Functionsを使ってAzure OpenAIを活用したアプリケーションを作る場合、既存システムへの付け足しという形での実装パターンやAzure OpenAIのAPIエンドポイントの隠蔽理由でプロキシとして実装するパターンなどが考えられ、いずれも大規模なエンタープライズ企業であれば、閉域網でのやり取りが重要になってきます。
そのため、仮想ネットワークへの接続がサポートされており、なおかつ高速にスケーリングする経済的なオプションとして、まずはFlex Consumptionプランを検討することをお勧めします。

一方でFlex Consumptionプランは2024年2月現在、日本リージョンでのデプロイが未対応のため、国内リージョンの利用が要件の場合は、Premiumプランを検討することになります。
なお、検証用途や特に閉域要件がない場合は通常のConsumption(従量課金)プランで全く問題ありません。

Azure OpenAIへのアクセスについて

Azureに限らずですが、OpenAI系のサンプルコードでよくあるAPIのアクセス方法としてOpenAIの「APIキー」を用いているものが多いと思います。
もちろん開発テストや検証段階ではこの方法でも問題ないことが多いのですが、本番を見据えたときには、キーをハードコーディングしないという大前提のもと、キーの管理はより安全に行いたいのが本音であることが多いと思います。

Azure Functions以外のAzure製品でも同様の方法をとることが可能であるという前提で今回はAzure Functionsを題材に2つのプラクティスをご紹介します。

Azure Key Vaultを利用する方法

Azure Key Vault は、Azure の主要な管理ソリューションの 1 つであり、シークレットの管理やキー管理・証明書の管理といった機能を提供しています。今回のユースケースでは、この中でシークレットの管理の機能を利用できます。

Azure Key Vaultを利用することで、Azure OpenAIのAPIキーをハードコーディングすることなく参照することが可能になるだけでなく、キーのローテーションに関する手順も環境変数にAPIキーを格納する場合と比較して簡略化されます。

さらにAzure Key Vaultが持つロールベースアクセス制御やファイアウォール・仮想ネットワークとの接続といったアクセス制御の機能を活用しよりセキュアにAPIキーを管理することが可能となります。
より詳細の内容はこちらのドキュメントを参照してみてください。

マネージドIDを利用する方法

マネージドIDとは、Azure上のリソースに割り当てられたEntra ID上のサービスプリンシパルのことです。
マネージドIDを利用するとEntra ID認証をサポートするリソースへ接続する際に、そのマネージドIDを利用して資格情報を管理することなくアクセストークンを取得可能となります。
以下がマネージドIDの主なメリットです。

  • 資格情報を管理する必要がありません
  • Entra ID認証をサポートしているあらゆるリソースに対して認証可能(もちろんAzure OpenAIも対象です)
  • 追加のコストは必要ありません

Azure上にデプロイしたアプリケーションから他のAzureサービス(例えばSQL DBやStorage、AI Serviceなど)へアクセスするといった「Azure内で完結する連携」の場合はこのマネージドIDを利用することを強くお勧めします。
ちなみに、Azure OpenAI client library for .NETのドキュメントでは、マネージドIDを用いた認証を推奨事項として取り上げられています。

特に.NETで開発する場合、マネージド ID を活用してAzure OpenAIへの認証をする場合も、APIキーを用いて認証する場合とほとんどコードは変わりません。
AzureOpenAIClientの認証をする際に、Azure.IdentityライブラリのDefaultAzureCredential()メソッドをApiKeyCredential()メソッドの代わりに利用するだけでOKです。
あとは、Azure Portal側でマネージドIDの設定とロールベースアクセス権の付与を行うだけです。

余談ですが、Azure.IdentityライブラリのDefaultAzureCredential()は開発時から便利に利用できるもので、マネージドIDやVisual Studio、VS Code、Azure CLIなどの資格情報を順番に試して認証する挙動をします。
そのため、開発時にVS Code上でデバッグするときから、本番のAzure Functions上で実行されるときも同じコードでEntra ID認証をしてくれるため、マネージドIDがAzure環境専用のものだからと言って開発環境用のコードと本番環境用のコードを分ける必要がありません。

Azure Functions のマネージドIDを有効にする方法

AzureポータルのAzure Functions管理画面で「ID」というメニューからマネージドIDを作成できます。

マネージドIDにロールの割り当てをする方法

作成したマネージドIDの実体はEntra IDのアプリケーションなので、一般的なロールの割り当てが可能になります。今回はAzure OpenAIへのアクセスのため、「Cognitive Services OpenAI User」を対象のマネージドIDに割り当てます。

 

まとめ

本記事では、Azure FunctionsとAzure OpenAIを組み合わせて高度なAI機能を実装する際にポイントとなる点について解説しました。
特に、Azure OpenAIとAzure Functionsを利用するメリットとなるマネージドIDの利用方法について詳しく解説しました。

本記事の内容が、セキュアなAIアプリ構築の一助になれば幸いです。

以上、最後までご愛読いただき
ありがとうございました。

お問い合わせは、
以下のフォームへご連絡ください。

お問い合わせ

PAGETOP