Azure Functionsは、インフラストラクチャをプロビジョニングまたは管理することなく、イベント ドリブン コードを実行できるサーバーレス コンピューティング サービスです。 関数の実行は、HTTP 要求、キュー メッセージ、タイマー、ストレージ内の変更などのイベントによってトリガーされ、必要に応じて自動的にスケーリングされます。
このガイドでは、特にPythonベースのAzure Functionsの構築に焦点を当て、次のことに役立ちます。
- 関数アプリをローカルで作成して実行する
- Python プログラミング モデルを理解する
- アプリケーションを整理して構成する
- Azureでアプリをデプロイして監視する
- スケーリングとパフォーマンスのベスト プラクティスを適用する
概念の概要をお探しですか? Azure Functions開発者向けリファレンスを参照してください。
実際のユース ケースに関心がありますか? [ シナリオとサンプル ] ページを確認します。
関数アプリのビルド
このセクションでは、Python関数アプリを作成および構築するための重要なコンポーネントについて説明します。 トピックには、 プログラミング モデル、 プロジェクト構造、 トリガーとバインド、 依存関係管理が含まれます。
プログラミング モデル
Functions では、Python プログラミング モデルの 2 つのバージョンがサポートされています。
| Version | 説明 |
|---|---|
| 2.x | デコレーター ベースのアプローチを使用して、Python コード ファイルでトリガーとバインドを直接定義します。 各関数は、 function_app.py ファイルまたは参照先のブループリント ファイルに、グローバルでステートレスなメソッドとして実装します。 このモデル バージョンは、新しいPython アプリに推奨されます。 |
| 1.x | 各関数のトリガーとバインドは、個別の function.json ファイルで定義します。 各関数は、Python コード ファイルにグローバルなステートレス メソッドとして実装します。 このバージョンのモデルでは、レガシ アプリがサポートされています。 |
この記事では、特定のPython モデル バージョンを対象とします。 記事の上部にある目的のバージョンを選択します。
重要
デコレーター ベースのアプローチでは v2 プログラミング モデルを使用して、コード内でトリガーとバインドを直接定義します。
Python v1 プログラミング モデルでは、各関数は、__init__.py という名前のファイル内のグローバルなステートレス main() メソッドとして定義されます。
関数のトリガーとバインドは、 function.json ファイル内で個別に構成され、バインド name 値が main() メソッドのパラメーターとして使用されます。
例
HTTP 要求に応答する単純な関数を次に示します。
# __init__.py
def main(req):
user = req.params.get('user')
return f'Hello, {user}!'
対応する function.json ファイルを次に示します。
{
"scriptFile": "__init__.py",
"bindings": [
{
"authLevel": "function",
"type": "httpTrigger",
"direction": "in",
"name": "req",
"methods": [
"get",
"post"
]
},
{
"type": "http",
"direction": "out",
"name": "$return"
}
]
}
重要な概念
- この関数には、1 つの HTTP トリガーがあります。
-
HttpRequest オブジェクトには、要求ヘッダー、クエリ パラメーター、ルート パラメーター、およびメッセージ本文が含まれています。 この関数は、
nameオブジェクトのparamsパラメーターからクエリ パラメーターの値を取得します。 - この例で名前を送信するには、公開されている関数の URL に
?name={name}を追加します。 たとえば、ローカルで実行している場合、完全な URL はhttp://localhost:7071/api/http_trigger?name=Testのようになります。 バインドの使用例については、「 トリガーとバインド」を参照してください。
azure-functions SDK を使用し、IntelliSense とエディターのサポートを向上させるために型の注釈を含めます。
# __init__.py
import azure.functions as func
def http_trigger(req: func.HttpRequest) -> str:
# requirements.txt
azure-functions
azure-functions ライブラリ
azure-functions Python ライブラリには、Azure Functions ランタイムとの対話に使用されるコア型が用意されています。 使用可能なすべての型とメソッドを確認するには、 azure-functions API にアクセスしてください。
関数コードでは、 azure-functions を使用して次のことができます。
- トリガー入力データへのアクセス (
HttpRequest、TimerRequestなど) - 出力値の作成 (
HttpResponseなど) - ランタイム提供のコンテキストとバインディング データを操作する
アプリで azure-functions を使用している場合は、プロジェクトの依存関係に含まれている必要があります。
注
azure-functions ライブラリは、Python Azure Functionsのプログラミングサーフェイスを定義しますが、汎用 SDK ではありません。 Azure Functions ランタイム内で関数を作成して実行する場合に特に使用します。
代替エントリ ポイント
scriptFile ファイルでentryPointプロパティとfunction.jsonプロパティを指定することで、関数の既定の動作を変更できます。 たとえば、次の function.json ファイルは、Azure関数のエントリ ポイントとして、main.py ファイルの custom_entry() メソッドを使用するようにランタイムに指示します。
{
"scriptFile": "main.py",
"entryPoint": "custom_entry",
"bindings": [
...
]
}
フォルダー構造
Python Azure Functions プロジェクトには、次の構造を使用します。
<project_root>/
│
├── .venv/ # (Optional) Local Python virtual environment
├── .vscode/ # (Optional) VS Code workspace settings
│
├── my_first_function/ # Function directory
│ └── __init__.py # Function code file
│ └── function.json # Function binding configuration file
│
├── my_second_function/
│ └── __init__.py
│ └── function.json
│
├── shared/ # (Optional) Pure helper code with no triggers/bindings
│ └── utils.py
│
├── additional_functions/ # (Optional) Contains blueprints for organizing related Functions
│ └── blueprint_1.py
│
├── tests/ # (Optional) Unit tests for your functions
│ └── test_my_function.py
│
├── .funcignore # Excludes files from being published
├── host.json # Global function app configuration
├── local.settings.json # Local-only app settings (not published)
├── requirements.txt # (Optional) Defines Python dependencies for remote build
├── Dockerfile # (Optional) For custom container deployment
キー ファイルとフォルダー
| ファイル/フォルダー | 説明 | アプリを Azure で実行するために必要です |
|---|---|---|
my_first_function/ |
1 つの関数のディレクトリ。 | ✅ |
__init__.py/ |
my_first_function関数コードが定義されているメイン スクリプト。 |
✅ |
function.json/ |
my_first_function関数のバインド構成を格納します。 |
✅ |
host.json |
アプリ内のすべての関数のグローバル構成。 | ✅ |
requirements.txt |
Python |
❌ (パッケージ管理に推奨) |
local.settings.json |
ローカルのみのアプリ設定とシークレット (公開なし)。 | ❌ (ローカル開発に必要) |
.funcignore |
展開から除外するファイルとフォルダー ( .venv/、 tests/、 local.settings.jsonなど) を指定します。 |
❌ (推奨) |
.venv/ |
Pythonのローカル仮想環境 (デプロイから除外)。 | ❌ |
.vscode/ |
Visual Studio Codeのエディター構成。 デプロイには必要ありません。 | ❌ |
shared/ |
Function App プロジェクト間で共有されるヘルパー コードを保持します | ❌ |
additional_functions/ |
モジュール型のコード編成 (通常はブループリントで) に使用 されます。 | ❌ |
tests/ |
関数アプリの単体テスト。 Azureに発行されていません。 | ❌ |
Dockerfile |
デプロイ用のカスタム コンテナーを定義します。 | ❌ |
Python v2 プログラミング モデルでは、Azure Functionsは decorator ベースのアプローチを使用して、コード内でトリガーとバインドを直接定義します。 各関数は、 ファイル内でfunction_app.pyとして実装されます。
例
HTTP 要求に応答する単純な関数を次に示します。
import azure.functions as func
app = func.FunctionApp()
@app.route("hello")
def http_trigger(req):
user = req.params.get("user")
return f"Hello, {user}!"
# requirements.txt
azure-functions
重要な概念
- このコードは、
azure-functionsパッケージをインポートし、デコレーターと型を使用して関数アプリを定義します。 - この関数には、1 つの HTTP トリガーがあります。
-
HttpRequest オブジェクトには、要求ヘッダー、クエリ パラメーター、ルート パラメーター、およびメッセージ本文が含まれています。 この関数は、
nameオブジェクトのparamsパラメーターからクエリ パラメーターの値を取得します。 - この例で名前を送信するには、公開されている関数の URL に
?name={name}を追加します。 たとえば、ローカルで実行している場合、完全な URL はhttp://localhost:7071/api/http_trigger?name=Testのようになります。 バインドの使用例については、「 トリガーとバインド」を参照してください。
azure-functions ライブラリ
azure-functions Python ライブラリは、Azure Functions プログラミング モデルの中核となる部分です。 これには、デコレーター、トリガーとバインドの型、および実行時に関数を定義して操作するために使用される要求/応答オブジェクトが用意されています。
使用可能なすべての型とデコレーターを表示するには、 azure-functions API にアクセスしてください。
関数アプリのコードは、次の場合にこのライブラリに依存します。
-
FunctionAppオブジェクトを使用してすべての関数を定義する - トリガーとバインドを宣言する (
@app.route、@app.timer_triggerなど) - 型指定された入力と出力にアクセスする (
HttpRequest、HttpResponse、Out など)
azure-functionsは、プロジェクトの依存関係に含まれている必要があります。 詳細については、 パッケージ管理に関するページを参照してください。
注
azure-functions ライブラリは、Python Azure Functionsのプログラミングサーフェイスを定義しますが、汎用 SDK ではありません。 Azure Functions ランタイム内で関数を作成して実行する場合に特に使用します。
型注釈を使用して、IntelliSense とエディターのサポートを向上させます。
def http_trigger(req: func.HttpRequest) -> str:
ブループリントを使用した整理
大規模またはモジュール型のアプリの場合は、blueprints を使用して、別のPython ファイルに関数を定義し、メイン アプリに登録します。 この分離により、コードの整理と再利用が維持されます。
ブループリントを定義して登録するには:
http_blueprint.pyなど、別のPython ファイルでブループリントを定義します。import azure.functions as func bp = func.Blueprint() @bp.route(route="default_template") def default_template(req: func.HttpRequest) -> func.HttpResponse: return func.HttpResponse("Hello World!")ブループリントをメイン
function_app.pyファイルに登録します。import azure.functions as func from http_blueprint import bp app = func.FunctionApp() app.register_functions(bp)
ブループリントを使用すると、次のことができます。
- アプリを再利用可能なモジュールに分割する
- 関連する関数をファイルまたは機能別にグループ化する
- プロジェクト間でブループリントを拡張または共有する
注
Durable Functionsでは、azure-functions-durable を使用したブループリントもサポートされます。
View サンプル →
フォルダー構造
Python Azure Functions プロジェクトには、次の構造を使用します。
<project_root>/
│
├── .venv/ # (Optional) Local Python virtual environment
├── .vscode/ # (Optional) VS Code workspace settings
│
├── function_app.py # Main function entry point (decorator model)
├── shared/ # (Optional) Pure helper code with no triggers/bindings
│ └── utils.py
│
├── additional_functions/ # (Optional) Contains blueprints for organizing related Functions
│ └── blueprint_1.py
│
├── tests/ # (Optional) Unit tests for your functions
│ └── test_my_function.py
│
├── .funcignore # Excludes files from being published
├── host.json # Global function app configuration
├── local.settings.json # Local-only app settings (not published)
├── requirements.txt # (Optional) Defines Python dependencies for remote build
├── Dockerfile # (Optional) For custom container deployment
キー ファイルとフォルダー
| ファイル/フォルダー | 説明 | アプリを Azure で実行するために必要です |
|---|---|---|
function_app.py |
デコレーターを使用してAzure Functionsとトリガーが定義されているメイン スクリプト。 | ✅ |
host.json |
アプリ内のすべての関数のグローバル構成。 | ✅ |
requirements.txt |
Python |
❌ (パッケージ管理に推奨) |
local.settings.json |
ローカルのみのアプリ設定とシークレット (公開なし)。 | ❌ (ローカル開発に必要) |
.funcignore |
展開から除外するファイルとフォルダー ( .venv/、 tests/、 local.settings.jsonなど) を指定します。 |
❌ (推奨) |
.venv/ |
Pythonのローカル仮想環境 (デプロイから除外)。 | ❌ |
.vscode/ |
Visual Studio Codeのエディター構成。 デプロイには必要ありません。 | ❌ |
shared/ |
Function App プロジェクト間で共有されるヘルパー コードを保持します | ❌ |
additional_functions/ |
モジュール型のコード編成 (通常はブループリントで) に使用 されます。 | ❌ |
tests/ |
関数アプリの単体テスト。 Azureに発行されていません。 | ❌ |
Dockerfile |
デプロイ用のカスタム コンテナーを定義します。 | ❌ |
[注]
requirements.txtを使用してデプロイするときに、 ファイルを含めます。 リモート ビルドを使用しない場合、またはアプリの依存関係を定義するために別のファイルを使用する場合は、ローカル ビルドを実行し、事前 にビルド された依存関係を使用してアプリをデプロイできます。
単体テストのガイダンスについては、「 単体テスト」を参照してください。 コンテナーのデプロイについては、「 カスタム コンテナーを使用したデプロイ」を参照してください。
トリガーとバインド
Azure Functionsでは、triggers を使用して関数の実行を開始し、bindings を使用して、コードをストレージ、キュー、データベースなどの他のサービスに接続します。 Python v2 プログラミング モデルでは、デコレーターを使用してバインディングを宣言します。
2 つの主な種類のバインディングが存在します。
- トリガー (関数を開始する入力)
- 入力と出力 (追加のデータ ソースまたは変換先)
使用可能なトリガーとバインドの詳細については、「Azure Functions の
例: BLOB 入力を使用したタイマー トリガー
この関数では、次の処理を実行します。
- 10 分ごとにトリガーが実行される
- SDK 型バインドを使用して BLOB から読み取る
- 結果をキャッシュし、一時ファイルに書き込みます
import azure.functions as func
import azurefunctions.extensions.bindings.blob as blob
import logging
import tempfile
CACHED_BLOB_DATA = None
app = func.FunctionApp()
@app.function_name(name="TimerTriggerWithBlob")
@app.schedule(schedule="0 */10 * * * *", arg_name="mytimer")
@app.blob_input(arg_name="client",
path="PATH/TO/BLOB",
connection="BLOB_CONNECTION_SETTING")
def timer_trigger_with_blob(mytimer: func.TimerRequest,
client: blob.BlobClient,
context: func.Context) -> None:
global CACHED_BLOB_DATA
if CACHED_BLOB_DATA is None:
# Download blob and save as a global variable
CACHED_BLOB_DATA = client.download_blob().readall()
# Create temp file prefix
my_prefix = context.invocation_id
temp_file = tempfile.NamedTemporaryFile(prefix=my_prefix)
temp_file.write(CACHED_BLOB_DATA)
logging.info(f"Cached data written to {temp_file.name}")
重要な概念
- SDK の型バインドを使用して、豊富な型を操作します。 詳細については、「 SDK の型バインド」を参照してください。
- グローバル変数を使用してコストの高い計算をキャッシュできますが、その状態が関数の実行間で保持されるとは限りません。
- 一時ファイルは
tmp/に格納され、呼び出しやスケールアウト インスタンス間で保持される保証はありません。 - Context クラスを使用して、関数の呼び出しコンテキストにアクセスできます。
例: Cosmos DB 入力とイベント ハブ出力を使用した HTTP トリガー
この関数では、次の処理を実行します。
- HTTP 要求のトリガー
- Cosmos DB からの読み取り
- Event Hub 出力への書き込み
- HTTP 応答を返します。
# __init__.py
import azure.functions as func
def main(req: func.HttpRequest,
documents: func.DocumentList,
event: func.Out[str]) -> func.HttpResponse:
# Content from HttpRequest and Cosmos DB input
http_content = req.params.get("body")
doc_id = documents[0]["id"] if documents else "No documents found"
event.set(f"HttpRequest content: {http_content} | CosmosDB ID: {doc_id}")
return func.HttpResponse(
"Function executed successfully.",
status_code=200
)
// function.json
{
"scriptFile": "__init__.py",
"entryPoint": "main",
"bindings": [
{
"type": "httpTrigger",
"direction": "in",
"name": "req",
"methods": ["get", "post"],
"route": "file"
},
{
"type": "http",
"direction": "out",
"name": "$return"
},
{
"type": "cosmosDB",
"direction": "in",
"name": "documents",
"databaseName": "test",
"containerName": "items",
"id": "cosmosdb-input-test",
"connection": "COSMOSDB_CONNECTION_SETTING"
},
{
"type": "eventHub",
"direction": "out",
"name": "event",
"eventHubName": "my-test-eventhub",
"connection": "EVENTHUB_CONNECTION_SETTING"
}
]
}
主な概念
- 各関数には 1 つのトリガーがありますが、複数のバインドを持つことができます。
-
directionでfunction.jsonを "in" として指定して入力を追加します。 出力にはdirectionのoutがあります。 -
HttpRequestオブジェクトから要求の詳細にアクセスし、ヘッダー、状態コード、本文を含むカスタムHttpResponseを構築できます。
import azure.functions as func
app = func.FunctionApp()
@app.function_name(name="HttpTriggerWithCosmosDB")
@app.route(route="file")
@app.cosmos_db_input(arg_name="documents",
database_name="test",
container_name="items",
connection="COSMOSDB_CONNECTION_SETTING")
@app.event_hub_output(arg_name="event",
event_hub_name="my-test-eventhub",
connection="EVENTHUB_CONNECTION_SETTING")
def http_trigger_with_cosmosdb(req: func.HttpRequest,
documents: func.DocumentList,
event: func.Out[str]) -> func.HttpResponse:
# Content from HttpRequest and Cosmos DB input
http_content = req.params.get('body')
doc_id = documents[0]['id']
event.set("HttpRequest content: " + http_content
+ " | CosmosDB ID: " + doc_id)
return func.HttpResponse(
f"Function executed successfully.",
status_code=200
)
重要な概念
-
@route()またはトリガー固有のデコレーター (@timer_trigger、@queue_triggerなど) を使用して、関数の呼び出し方法を定義します。 -
@blob_input、@queue_inputなどのデコレーターを使用して入力を追加します。 - 出力は次のようになります。
- 直接返されます (出力が 1 つだけの場合)
- 複数の出力に対して
Outバインドと.set()メソッドを使用して割り当てられます。
-
HttpRequestオブジェクトから要求の詳細にアクセスし、ヘッダー、状態コード、本文を含むカスタムHttpResponseを構築できます。
SDK 型のバインド
選択トリガーとバインドでは、基になるAzure SDKsとフレームワークによって実装されたデータ型を操作できます。 これらの SDK 型バインドを使用すると、基になるサービス SDK を使用しているかのようにバインディング データを操作できます。 詳細については、 サポートされている SDK の種類のバインドに関する説明を参照してください。
重要
Pythonに対する SDK 型バインドのサポートは、Python v2 プログラミング モデルでのみ使用できます。
環境変数
Azure Functionsの環境変数を使用すると、関数コードでハードコーディングすることなく、構成値、接続文字列、アプリ シークレットを安全に管理できます。
環境変数を定義できます。
- ローカル: local.settings.json ファイル内のローカル開発中。
- Azure: Azure ポータルの Function App の構成ページで、Application Settings。
os.environまたはos.getenvを使用して、コード内の変数に直接アクセスします。
setting_value = os.getenv("myAppSetting", "default_value")
注
Azure Functionsは、Functions ランタイムとPythonワーカー動作を構成するシステム環境変数も認識します。 これらの変数は、関数コードでは明示的に使用されませんが、アプリの実行方法に影響します。 システム環境変数の完全な一覧については、「 アプリ設定のリファレンス」を参照してください。
パッケージの管理
Azure Functions アプリで他のPython パッケージを使用するには、プロジェクトのルートにある requirements.txt ファイルにパッケージを一覧表示します。 これらのパッケージはPythonのインポート システムによってインポートされ、通常どおりにそれらのパッケージを参照できます。
外部依存関係を使用したビルドおよびデプロイ オプションの詳細については、「Build Options for Python Function Appsを参照してください。
たとえば、次の例では、 requests モジュールを関数アプリに含めて使用する方法を示します。
<requirements.txt>
requests==2.31.0
pip install -r requirements.txtを使用してパッケージをローカルにインストールします。
パッケージがインストールされたら、関数コードでパッケージをインポートして使用できます。
import azure.functions as func
import requests
def main(req: func.HttpRequest) -> func.HttpResponse:
r = requests.get("https://api.github.com")
return func.HttpResponse(f"Status: {r.status_code}")
import azure.functions as func
import requests
app = func.FunctionApp()
@app.function_name(name="HttpExample")
@app.route(route="call_api")
def main(req: func.HttpRequest) -> func.HttpResponse:
r = requests.get("https://api.github.com")
return func.HttpResponse(f"Status: {r.status_code}")
考慮事項
- 組み込みモジュールとの競合:
-
Python標準ライブラリ (たとえば、
email/、json/) の後にプロジェクト フォルダーの名前を付けないでください。 -
requirements.txtPythonネイティブ ライブラリ (logging、asyncio、uuidなど) は含めないでください。
-
Python標準ライブラリ (たとえば、
- 展開:
-
ModuleNotFoundエラーを回避するには、必要なすべての依存関係がrequirements.txtに一覧表示されていることを確認します。 - アプリのPythonバージョンを更新する場合は、以前にビルドされたパッケージとの依存関係の競合を回避するために、新しいPython バージョンでアプリを再構築して再デプロイします。
-
- PyPI 以外の依存関係:
- ローカル パッケージ、ホイール ファイル、プライベート フィードなど、PyPI で使用できない依存関係をアプリに含めることができます。 セットアップ手順については、「custom dependencies in Python Azure Functions」を参照してください。
- ワーカーの依存関係をAzure Functions Pythonします。
- パッケージに、ワーカーの依存関係 (
protobufやgrpcioなど) と競合する可能性がある特定のライブラリが含まれている場合は、アプリケーションがワーカーの依存関係を参照しないように、アプリ設定で PYTHON_ISOLATE_WORKER_DEPENDENCIES を 1 に構成します。 Python 3.13 以降では、この機能は既定で有効になっています。
- パッケージに、ワーカーの依存関係 (
実行とデプロイ
このセクションでは、running 関数のローカルでの実行、Python バージョンのサポート、ビルドと配置のオプション、およびランタイム構成について説明します。 この情報を使用して、ローカル環境とAzure環境の両方で関数アプリを正常に実行します。
ローカルでの実行
Azureにデプロイする前に、ローカル コンピューターでPython関数アプリを実行してテストできます。
Azure Functions Core Tools の使用
Azure Functions Core Tools をインストールし、プロジェクト ルートから func start コマンドを実行してローカル ランタイムを開始します。
func start
関数アプリをローカルで起動すると、Core Tools によってアプリで検出されたすべての関数が表示されます。
Functions:
http_trigger: http://localhost:7071/api/http_trigger
Core Tools の使用方法の詳細については、 Core Tools を使用してローカルでAzure Functionsを開発する方法に関するページを参照してください。
関数を直接呼び出す
azure-functions >= 1.21.0 を使用すると、Core Tools を実行せずに Python インタープリターを使用して関数を直接呼び出すこともできます。 この方法は、簡単な単体テストに役立ちます。
# function_app.py
import azure.functions as func
app = func.FunctionApp(http_auth_level=func.AuthLevel.ANONYMOUS)
@app.route(route="http_trigger")
def http_trigger(req: func.HttpRequest) -> func.HttpResponse:
return "Hello, World!"
# Test the function directly
print(http_trigger(None))
出力を表示するには、Pythonを使用してファイルを直接実行します。
> python function_app.py
Hello, World!
# __init__.py
import azure.functions as func
def main(req: func.HttpRequest) -> func.HttpResponse:
return func.HttpResponse("Hello, World!")
# Test the function directly
print(main(None))
出力を表示するには、Pythonを使用してファイルを直接実行します。
> python __init__.py
Hello, World!
この方法では、追加のパッケージやセットアップは必要なく、開発中の迅速な検証に最適です。 詳細なテストについては、「単体テスト」を参照してください。
サポートされているPythonバージョン
Azure Functionsでは、Azure Functions の
重要
関数アプリのPythonバージョンを変更する場合は、新しいバージョンを使用してアプリを再構築して再デプロイする必要があります。 Pythonバージョンが変更された場合、既存のデプロイ成果物と依存関係は自動的に再構築されません。
ビルド & デプロイ
シナリオに推奨されるビルド メカニズムの詳細については、「 ビルド オプション」を参照してください。 デプロイの一般的な概要については、
展開メカニズムのクイック比較
| ツール/プラットフォーム | コマンド/アクション | 最適なユース ケース |
|---|---|---|
| Azure Functions Core Tools | func azure functionapp publish <APP_NAME> |
CI 実行、ローカルオートメーション、またはクロスプラットフォームでの作業に最適です。 |
| AZ CLI | az functionapp deployment source config-zip |
Core Tools の外部でデプロイをスクリプト化する場合に便利です。 自動化されたパイプラインまたはクラウドベースのターミナル (Azure Cloud Shell) で適切に機能します。 |
| Visual Studio Code (Azure Functions Extension) | Command Palette → "Azure Functions: deploy to Azure..." | 初心者または対話型のデプロイに最適です。 パッケージ化とビルドを自動的に処理します。 |
| GitHub Actions | Azure/functions-action@v1 |
GitHubベースの CI/CD に最適です。 プッシュまたは PR マージでの自動デプロイを有効にします。 |
| Azure Pipelines |
AzureFunctionApp@2 タスク |
Azure DevOpsを使用したエンタープライズ CI/CD。 制御されたリリース ワークフロー、ゲート ビルド、マルチステージ パイプラインに最適です。 |
| カスタム コンテナーのデプロイ | コンテナー →をプッシュする az functionapp create --image <container> |
OS レベルのパッケージ、カスタム Python ビルド、固定されたランタイム、またはサポートされていない依存関係 (システム ライブラリ、ローカル バイナリなど) が必要な場合に必要です。 |
| ポータル ベースの関数の作成 | Azure ポータルで関数 →インライン エディターを作成する | 依存関係のない単純な関数にのみ使用します。 デモや学習には最適ですが、サード パーティのパッケージを必要とするアプリには 推奨されません 。 |
注
ポータル ベースの関数の作成 では、サードパーティの依存関係はサポートされていないため、運用アプリの作成には推奨されません。
azure-functions および組み込みのPython標準ライブラリの外部でパッケージをインストールまたは参照することはできません。
重要
2028 年 9 月 30 日以降、従量課金プランで Linux で関数アプリをホストするオプションは廃止されます。 中断を回避するには、Linux 上で実行されている既存の従量課金プラン アプリを、その日付より前の Flex 従量課金プラン に移行します。 従量課金プランのWindowsで実行されているアプリは、この変更の影響を受けません。
2025 年 9 月 30 日以降、Linux 従量課金プランには新機能も新しい言語スタックのサポートも追加されません。 Linux Consumption でサポートされている最後の言語バージョンは、.NET 9、Python 3.12、Node.js 22、PowerShell 7.4、Java 21 です。 Linux Consumption では、新しい言語バージョンはサポートされていません。
詳細については、「 従量課金プラン アプリを Flex 従量課金プランに移行する」を参照してください。
Python 3.13 以降の更新プログラム
Python 3.13 以降、Azure Functionsでは、アプリのビルドと実行方法に影響を与える、いくつかの主要なランタイムとパフォーマンスの向上が導入されています。 主な変更点は次のとおりです。
ランタイム バージョン管理:
requirements.txtでazure-functions-runtimeパッケージを参照することで、必要に応じてアプリを特定のPython worker バージョンにピン留めまたはアップグレードできるようになりました。バージョン管理が有効になっていない場合、アプリは、Functions が管理する既定のバージョンの Python ランタイムで実行されます。 requirements.txt ファイルを変更して、最新リリースバージョン、リリース済みバージョンを要求するか、アプリを特定のバージョンのPython ランタイムにピン留めする必要があります。
ランタイム バージョン管理を有効にするには、Python ランタイム パッケージへの参照を requirements.txt ファイルに追加します。ここで、パッケージに割り当てられた値によって使用されるランタイム バージョンが決まります。
運用アプリをプレリリース (アルファ、ベータ、または開発) ランタイム バージョンにピン留めしないでください。
変更に注意するには、Python ランタイムリリース ノート定期的に確認してください。
次の表は、 requirements.txt ファイルのこの設定のバージョン値に基づくバージョン管理の動作を示しています。
Version 例 行動 値が設定されていません azure-functions-runtimePython 3.13 以降のアプリは、使用可能な最新バージョンの Functions Python ランタイムで実行されます。 このオプションは、アプリが自動的に最新の安定したランタイム更新プログラムを受け取るので、プラットフォームの機能強化と機能を最新の状態に保つのに最適です。 特定のバージョンに固定する azure-functions-runtime==1.2.0Python 3.13 以降のアプリは固定されたランタイム バージョンのままであり、自動更新は受け取りません。 代わりに、ランタイムの新機能、修正、および機能強化を利用するために、ピン留めされたバージョンを手動で更新する必要があります。 ピン留めは、安定性と予測可能性が不可欠な重要な運用ワークロードに推奨されます。 ピン留めすると、開発中にリリース前のランタイム バージョンでアプリをテストすることもできます。 パッケージ参照なし n/a azure-functions-runtimeを設定しないと、Python 3.13 以降のアプリは、最新リリースバージョンの背後にあるPython ランタイムの既定のバージョンで実行されます。 更新は、Functions によって定期的に行われます。 このオプションにより、安定性と広範な互換性が保証されます。 ただし、最新の機能と修正プログラムへのアクセスは、既定のバージョンが更新されるまで遅れます。
依存関係の分離: アプリの依存関係 (
grpcioやprotobufなど) はワーカーの依存関係から完全に分離され、バージョンの競合を防ぎます。 アプリ設定PYTHON_ISOLATE_WORKER_DEPENDENCIESは、Python 3.13 以降で実行されているアプリには影響しません。HTTP ストリーミングのセットアップが簡略化され、特別なアプリ設定は必要ありません。
ワーカー拡張機能と共有メモリ機能のサポートが削除されました。
ランタイム バージョン管理:
requirements.txtでazure-functions-runtime-v1パッケージを参照することで、必要に応じてアプリを特定のPython worker バージョンにピン留めまたはアップグレードできるようになりました。バージョン管理が有効になっていない場合、アプリは、Functions が管理する既定のバージョンの Python ランタイムで実行されます。 requirements.txt ファイルを変更して、最新リリースバージョン、リリース済みバージョンを要求するか、アプリを特定のバージョンのPython ランタイムにピン留めする必要があります。
ランタイム バージョン管理を有効にするには、Python ランタイム パッケージへの参照を requirements.txt ファイルに追加します。ここで、パッケージに割り当てられた値によって使用されるランタイム バージョンが決まります。
運用アプリをプレリリース (アルファ、ベータ、または開発) ランタイム バージョンにピン留めしないでください。
変更に注意するには、Python ランタイムリリース ノート定期的に確認してください。
次の表は、 requirements.txt ファイルのこの設定のバージョン値に基づくバージョン管理の動作を示しています。
Version 例 行動 値が設定されていません azure-functions-runtime-v1Python 3.13 以降のアプリは、使用可能な最新バージョンの Functions Python ランタイムで実行されます。 このオプションは、アプリが自動的に最新の安定したランタイム更新プログラムを受け取るので、プラットフォームの機能強化と機能を最新の状態に保つのに最適です。 特定のバージョンに固定する azure-functions-runtime-v1==1.2.0Python 3.13 以降のアプリは固定されたランタイム バージョンのままであり、自動更新は受け取りません。 代わりに、ランタイムの新機能、修正、および機能強化を利用するために、ピン留めされたバージョンを手動で更新する必要があります。 ピン留めは、安定性と予測可能性が不可欠な重要な運用ワークロードに推奨されます。 ピン留めすると、開発中にリリース前のランタイム バージョンでアプリをテストすることもできます。 パッケージ参照なし n/a azure-functions-runtime-v1を設定しないと、Python 3.13 以降のアプリは、最新リリースバージョンの背後にあるPython ランタイムの既定のバージョンで実行されます。 更新は、Functions によって定期的に行われます。 このオプションにより、安定性と広範な互換性が保証されます。 ただし、最新の機能と修正プログラムへのアクセスは、既定のバージョンが更新されるまで遅れます。
依存関係の分離: アプリの依存関係 (
grpcioやprotobufなど) はワーカーの依存関係から完全に分離され、バージョンの競合を防ぎます。 アプリ設定PYTHON_ISOLATE_WORKER_DEPENDENCIESは、Python 3.13 以降で実行されているアプリには影響しません。ワーカー拡張機能と共有メモリ機能のサポートが削除されました。
可観測性とテスト
このセクションでは、logging、monitoring、testing 機能について説明します。これにより、問題のデバッグ、パフォーマンスの追跡、Python関数アプリの信頼性の確保に役立ちます。
ログ記録と監視
Azure Functionsは、Pythonの組み込みの logging モジュールで直接使用できるルート ロガーを公開します。 このロガーを使用して書き込まれたメッセージは、アプリがAzureで実行されているときに、Application Insights に自動的に送信されます。
ログ記録を使用すると、ランタイム情報をキャプチャし、それ以上のセットアップを必要とせずに問題を診断できます。
HTTP トリガーを使用したログの例
import logging
import azure.functions as func
def main(req: func.HttpRequest) -> func.HttpResponse:
logging.debug("Example debug log")
logging.info("Example info log")
logging.warning("Example warning")
logging.error("Example error log")
return func.HttpResponse("OK")
import logging
import azure.functions as func
app = func.FunctionApp()
@app.route(route="http_trigger")
def http_trigger(req) -> func.HttpResponse:
logging.debug("Example debug log")
logging.info("Example info log")
logging.warning("Example warning")
logging.error("Example error log")
return func.HttpResponse("OK")
ログ レベルの完全なセット (debug、info、warning、error、critical) を使用でき、ログまたは Application Insights のAzure ポータルに表示されます。
ポータルでのAzure Functionsの監視の詳細については、「Monitor Azure Functionsを参照してください。
注
Application Insights でデバッグ ログを表示するには、さらにセットアップが必要です。 この機能を有効にするには、PYTHON_ENABLE_DEBUG_LOGGINGを1に設定し、logLevelをhost.json traceでdebugまたはに設定します。 既定では、デバッグ ログは Application Insights には表示されません。
バックグラウンド スレッドからのログ記録
関数が新しいスレッドを開始し、そのスレッドからログを記録する必要がある場合は、必ず context 引数をスレッドに渡してください。
contextには、スレッド ローカル ストレージと現在のinvocation_idが含まれています。これは、ログを関数の実行に適切に関連付けるためにワーカー スレッドで設定する必要があります。
import logging
import threading
import azure.functions as func
def main(req: func.HttpRequest, context) -> func.HttpResponse:
logging.info("Function started")
t = threading.Thread(target=log_from_thread, args=(context,))
t.start()
return "okay"
def log_from_thread(context):
# Associate the thread with the current invocation
context.thread_local_storage.invocation_id = context.invocation_id
logging.info("Logging from a background thread")
import azure.functions as func
import logging
import threading
app = func.FunctionApp()
@app.route(route="http_trigger")
def http_trigger(req, context) -> func.HttpResponse:
logging.info("Function started")
t = threading.Thread(target=log_from_thread, args=(context,))
t.start()
return "okay"
def log_from_thread(context):
# Associate the thread with the current invocation
context.thread_local_storage.invocation_id = context.invocation_id
logging.info("Logging from a background thread")
カスタム ロガーの構成
カスタムの書式設定、ログのフィルター処理、サード パーティの統合など、ログの動作をより詳細に制御する必要がある場合は、Pythonでカスタム ロガーを構成できます。
カスタム ロガーを構成するには、カスタム名で Python の logging.getLogger() を使用し、必要に応じてハンドラーまたはフォーマッタを追加します。
import logging
custom_logger = logging.getLogger('my_custom_logger')
OpenTelemetry のサポート
PythonのAzure Functionsでは、OpenTelemetry もサポートされています。これにより、トレース、メトリック、ログを標準化された形式で出力できます。 OpenTelemetry の使用は、Application Insights の外部のツール (Grafana や Jaeger など) にテレメトリをエクスポートする分散アプリケーションやシナリオで特に重要です。
セットアップ手順とサンプル コードについては、OpenTelemetry クイック スタート (Azure Functions (Python) を参照してください。
単体テスト
pytestを使用して、関数の単体テストを記述して実行します。
標準のテスト フレームワークを使用して、他のPython コードと同様にPython関数をテストできます。 ほとんどのバインディングでは、 azure.functions パッケージから適切なクラスのインスタンスを作成することで、モック入力オブジェクトを作成できます。
my_functionを例として使用すると、次の例は HTTP によってトリガーされる関数のモック テストです。
まず、 <project_root>/function_app.py ファイルを作成し、HTTP トリガーとして my_function 関数を実装します。
# <project_root>/function_app.py
import azure.functions as func
import logging
app = func.FunctionApp()
# Define the HTTP trigger that accepts the ?value=<int> query parameter
# Double the value and return the result in HttpResponse
@app.function_name(name="my_function")
@app.route(route="hello")
def my_function(req: func.HttpRequest) -> func.HttpResponse:
logging.info('Executing myfunction.')
initial_value: int = int(req.params.get('value'))
doubled_value: int = initial_value * 2
return func.HttpResponse(
body=f"{initial_value} * 2 = {doubled_value}",
status_code=200
)
HTTP トリガーのテスト ケースの記述を開始できます。
# <project_root>/test_my_function.py
import unittest
import azure.functions as func
from function_app import my_function
class TestFunction(unittest.TestCase):
def test_my_function(self):
# Construct a mock HTTP request.
req = func.HttpRequest(method='GET',
body=None,
url='/api/my_function',
params={'value': '21'})
# Call the function.
func_call = main.build().get_user_function()
resp = func_call(req)
# Check the output.
self.assertEqual(
resp.get_body(),
b'21 * 2 = 42',
)
Python仮想環境フォルダー内で、次のコマンドを実行してアプリをテストできます。
pip install pytest
pytest test_my_function.py
次のように、ターミナルに pytest 結果が表示されます。
============================================================================================================ test session starts ============================================================================================================
collected 1 item
test_my_function.py . [100%]
============================================================================================================= 1 passed in 0.24s =============================================================================================================
最適化と高度なトピック
Python関数アプリの最適化の詳細については、次の記事を参照してください。
- スケーリングとパフォーマンス
Flask Framework と Azure Functions - Durable Functions
- HTTP ストリーミング
関連資料
関数の詳細については、次の記事を参照してください。