Azure Functionsの「Go language support on Azure Functions」は、GoでAzure Functionsのサーバーレスアプリを作成できるようにするPublic Previewです。結論からいうと、Go開発者にとってはAzure Functionsをかなり使いやすくする更新ですが、現時点では本番移行を急ぐ機能ではありません。Go function appsはPublic Preview中で、サポートされるホスティングはFlex Consumptionプランに限定されています。(Microsoft Learn)
これまでGoでAzure Functionsを使う場合、カスタムハンドラーなどを検討する場面がありました。今回のGo言語サポートでは、Go worker SDKとGo向けプログラミングモデルにより、main.goで関数とトリガーを登録し、Goらしい書き方でイベント駆動の処理を実装できます。HTTP API、タイマー処理、Service Bus、Event Hubs、Event Grid、Cosmos DB、Blob Storageなどを使うサーバーレス処理をGoで書きたいチームは、まず検証環境で採用可否を確認する価値があります。(Microsoft Learn)
Azure FunctionsのGo言語サポートで何が変わるのか
今回の変更点は、「GoでもAzure Functionsを動かせるようになった」というだけではありません。実務上のポイントは、Azure Functions側にGo向けの開発体験が用意され、Goを第一級の言語オプションとして扱えるようになったことです。Microsoft Learnでも、GoはAzure Functionsの開発者リファレンスに追加され、2026年6月3日時点の公式ドキュメントとして公開されています。(Microsoft Learn)
主な変化を整理すると、次のようになります。
| 変更点 | これまでの課題 | 今回の意味 |
|---|---|---|
| Go向けプログラミングモデルが追加 | GoでFunctionsを使う場合、標準言語に比べて設計・運用の判断が難しかった | Go worker SDKを使って、Goのコード内で関数とトリガーを定義できる |
| コードファーストで関数を登録 | function.jsonや周辺設定を手作業で意識しやすかった | main()でFunctionAppを作り、HTTPやTimerなどのトリガーをGoコードで登録できる |
| 標準的なGoの書き方に近い | HTTP処理で独自の受け渡しを意識しやすかった | HTTPトリガーではhttp.ResponseWriterと*http.Requestを使える |
| Azure Functions Core Toolsによるビルド・展開 | GoアプリとしてのビルドとFunctions展開の境界が分かりにくかった | func startやfunc azure functionapp publishなどの一般的なFunctions開発フローに乗せやすい |
| 対象プランが明確 | どのホスティング構成で使えるか確認が必要 | Public Preview中はFlex Consumptionプランのみ対応 |
特に大きいのは、HTTPトリガーで標準Goのnet/httpに近い感覚で実装できる点です。たとえば軽量なAPI、Webhook受信、イベント処理の入口をGoで書きたい場合、既存のGo開発者がAzure Functionsに参加しやすくなります。
対象になるユーザーと影響範囲
この更新の影響を受けるのは、主にGoを使ってAzure上にイベント駆動アプリケーションを構築したい開発者や、Azure Functionsの言語選定を行うアーキテクトです。一方で、既存のC#、JavaScript、TypeScript、Python、Java、PowerShellなどのFunctionsアプリに対して、すぐに移行作業が必要になる変更ではありません。
| 対象者 | 影響 | まず確認すべきこと |
|---|---|---|
| Go開発者 | Azure FunctionsをGoで直接書く選択肢が増える | サポートされるトリガー、Flex Consumptionの制約、CI/CDのビルド方法 |
| Azure管理者 | Go Function App用の実行環境を用意する必要がある | Flex Consumption対応リージョン、Linux前提、ストレージ、監視、権限 |
| 既存Functions利用チーム | 既存アプリへの直接影響は小さい | 新規機能だけGoにするか、既存処理を移行する価値があるか |
| SRE・運用担当 | 監視、ログ、スケーリング、プレビュー利用範囲の整理が必要 | OpenTelemetry、Application Insights、アラート、障害時の切り分け方法 |
| セキュリティ担当 | プレビュー機能の利用ルール確認が必要 | 本番利用可否、認証設定、接続文字列やManaged Identityの扱い |
注意したいのは、Public Previewは「試せる状態」ではあっても、一般提供済みの本番機能と同じ前提で扱うべきではない点です。Azure Updatesのステータス定義でも、In previewはすべてのAzure顧客が非本番用途の利用・テストに使える段階とされています。(Microsoft Azure)
開発者が押さえるべきGoプログラミングモデル
Azure FunctionsのGo workerでは、Goのコードプロジェクトは標準的なGo moduleとして扱われます。func init --worker-runtime goを実行すると、host.json、local.settings.json、go.mod、go.sum、main.goなどを含むプロジェクト構成が作成されます。(Microsoft Learn)
基本イメージは次のような構成です。
my-function-app/
├── host.json
├── local.settings.json
├── go.mod
├── go.sum
└── main.gomain.goでは、sdk.FunctionApp()でアプリを作成し、HTTPトリガーやTimerトリガーなどを登録してからWorkerを開始します。公式リファレンスでは、HTTPトリガーのハンドラーにhttp.ResponseWriterと*http.Requestを使う例が示されています。(Microsoft Learn)
package main
import (
"fmt"
"net/http"
"github.com/azure/azure-functions-golang-worker/sdk"
"github.com/azure/azure-functions-golang-worker/worker"
)
func main() {
app := sdk.FunctionApp()
app.HTTP("hello", hello,
sdk.WithMethods("GET", "POST"),
sdk.WithAuth("anonymous"),
)
worker.Start(app)
}
func hello(w http.ResponseWriter, r *http.Request) {
name := r.URL.Query().Get("name")
if name == "" {
name = "world"
}
fmt.Fprintf(w, "Hello, %s!", name)
}この書き方の利点は、GoのWeb開発経験がある人にとって理解しやすいことです。API Gateway的にHTTPリクエストを受ける処理、外部サービスからのWebhookを処理する関数、小さな管理用APIなどは、Goの標準ライブラリの感覚に近い形で実装できます。
ただし、サンプルのWithAuth("anonymous")をそのまま本番相当の環境に持ち込むのは避けるべきです。検証用のHTTPエンドポイントでは便利ですが、社内APIや外部公開APIでは、Functionsの認証レベル、API Management、Microsoft Entra ID、ネットワーク制御などを組み合わせて設計する必要があります。
サポートされるトリガーと向いている用途
Public Preview中のGoサポートでは、すべてのAzure Functions機能がGoで使えるわけではありません。公式リファレンスでは、Core triggersとしてHTTP、Timer、Azure Cosmos DB、Azure Service BusのQueueとTopic、Event Hubs、Event Gridが示されています。Blob StorageはExtension triggerとして扱われ、Blob用のパッケージをblank importして使う形です。(Microsoft Learn)
| トリガー | Goでの活用例 | 向いているケース |
|---|---|---|
| HTTP | REST API、Webhook、軽量な管理API | Goのnet/httpに慣れたチームが小さなAPIを素早く作る |
| Timer | 定期実行バッチ、ヘルスチェック、期限切れデータ処理 | cronベースのジョブをサーバーレス化する |
| Azure Cosmos DB | 変更フィード処理、データ更新イベント処理 | Cosmos DBを中心にイベント駆動で処理をつなぐ |
| Service Bus Queue | 非同期ジョブ、バックグラウンド処理 | リクエスト処理と重い処理を分離する |
| Service Bus Topic | 複数購読者へのイベント配信 | ドメインイベントを複数サービスへ配布する |
| Event Hubs | ストリーミングイベント処理 | ログ、IoT、クリックストリームなどを処理する |
| Event Grid | Azureリソースや外部イベントへの反応 | Blob作成、リソース変更、イベント通知に反応する |
| Blob Storage | ファイル投入後の処理、画像・ログ・CSV処理 | オブジェクトストレージを起点に処理を開始する |
Goの強みは、軽量なバイナリ、シンプルな構文、並行処理の扱いやすさです。そのため、HTTP APIだけでなく、キューからメッセージを取り出して外部APIを呼ぶ処理、Event Hubsから受けたイベントを整形して保存する処理、Blobに置かれたファイルを順次処理する用途と相性があります。
一方で、Durable FunctionsはPublic Preview中のGoではサポートされていません。長時間のワークフロー、オーケストレーション、リトライ状態管理をDurable Functions前提で設計している場合は、C#やJavaScriptなど既存のサポート言語を使うか、Go側では別のワークフロー基盤を検討する必要があります。(Microsoft Learn)
管理者が確認すべき設定と前提条件
Go言語サポートを試す前に、管理者やプラットフォーム担当者は実行環境の制約を確認しておく必要があります。特に重要なのは、Public Preview中はFlex Consumptionプランのみ、Azure上ではLinuxのみ、Core Toolsのバージョン要件がある点です。(Microsoft Learn)
| 確認項目 | 推奨確認内容 | 見落としやすいポイント |
|---|---|---|
| ホスティングプラン | Flex Consumptionプランを使う | 従来のConsumptionや既存App Service Planにそのまま載せられると考えない |
| OS | Azure上ではLinux前提で設計する | Windows前提のパス、外部バイナリ、シェルスクリプトを混ぜない |
| リージョン | Flex Consumption対応リージョンを確認する | 既存リソースと同じリージョンで使えるとは限らない |
| Goバージョン | Go 1.24以降を用意する | 開発端末、CI環境、ローカル検証環境でバージョンがずれる |
| Core Tools | Azure Functions Core Tools 4.12以降を使う | 古いCore Toolsでは--worker-runtime goやGo向けビルドが期待通り動かない可能性がある |
| Azure CLI | Azure CLI 2.87.0以降を用意する | リソース作成やデプロイ用のスクリプトが古いCLIで失敗する |
| アプリ設定 | FUNCTIONS_WORKER_RUNTIMEやストレージ設定を確認する | ローカルとAzure上で設定値が違い、起動時エラーになる |
| 監視 | Application InsightsまたはOpenTelemetry連携を設計する | stdout/stderrの扱いによってログが重複する場合がある |
| 権限 | Managed IdentityやRBACを使う | 接続文字列を安易にアプリ設定へ残す |
Flex ConsumptionプランはLinuxベースのホスティングプランで、従来のConsumptionプランのサーバーレス課金モデルを拡張し、仮想ネットワーク統合、インスタンスメモリサイズの選択、Always ready instances、関数単位のスケーリングなどを備えています。(Microsoft Learn)
Go対応を試すだけなら小さく始められますが、管理者目線では「Goを使えるか」よりも「組織の標準的なAzure Functions運用に乗せられるか」を確認することが重要です。既存の監視、ログ保管、アラート、IaC、CI/CD、RBAC、ネットワーク制御の基準に合うかを、検証段階でチェックしておきましょう。
ローカル開発からデプロイまでの基本手順
検証の最短ルートは、ローカルでGo Function Appを作成し、HTTPトリガーを動かしてからAzureへデプロイする流れです。公式クイックスタートでは、ローカルのコマンドラインツールでHTTPリクエストに応答する関数を作成し、検証後にFlex Consumptionプランへデプロイする手順が示されています。(Microsoft Learn)
ツールのバージョンを確認する
go version
func --version
az version確認するポイントは次の3つです。
| ツール | 必要な目安 | 理由 |
|---|---|---|
| Go | 1.24以降 | Go Function Appのビルドに必要 |
| Azure Functions Core Tools | 4.12以降 | Go worker対応、ローカル実行、パッケージングに必要 |
| Azure CLI | 2.87.0以降 | Azureリソース作成やデプロイに必要 |
Go Function Appを作成する
func init MyGoFunctionApp --worker-runtime go
cd MyGoFunctionApp生成されたmain.goを確認し、まずはサンプルのHTTPトリガーをそのまま動かします。
func startローカル実行では、Functions Core ToolsがGoプロジェクトを検出し、go buildでバイナリを作成してからFunctions hostを起動します。local.settings.jsonではFUNCTIONS_WORKER_RUNTIMEがnativeとして扱われ、go.modの存在によってGo workerに解決される流れです。(Microsoft Learn)
Azureへ展開する
既存のFunction Appへ展開する場合は、次のようにCore Toolsから発行できます。
func azure functionapp publish <APP_NAME>別途ZIP成果物を作ってデプロイしたい場合は、func packでパッケージを作成し、Azure CLIでZIPデプロイする流れもあります。公式リファレンスでは、func packで作成したパッケージはAzureで実行できる状態になっているため、デプロイ時にリモートビルドを要求しないよう説明されています。(Microsoft Learn)
CI/CDで注意すべきなのは、Azure向けのパッケージングがLinux x64を前提としている点です。func pack --no-buildを使う場合は、事前に次のような形でLinux x64向けにビルドしておく必要があります。(Microsoft Learn)
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o bin/app .WindowsやmacOSのローカル環境では動いたのにAzureで起動しない場合、OS依存のファイルパス、CGO、外部バイナリ、ビルドターゲットの違いを疑ってください。
移行を検討する場合の判断基準
既存のAzure FunctionsアプリをすぐGoに移行する必要はありません。移行判断では、「Goで書けるようになった」ことよりも、「Goにすることで運用・性能・開発体制のメリットが出るか」を見極めるべきです。
| 判断軸 | Go採用を検討しやすいケース | 慎重にすべきケース |
|---|---|---|
| 開発体制 | チームの主力言語がGo | Functionsの既存資産がC#やTypeScript中心 |
| 処理内容 | 軽量API、イベント処理、並行処理が多い | Durable Functionsや複雑なワークフローに依存 |
| 運用 | Flex Consumptionへ新規構築できる | 既存プランや既存リージョンを変えにくい |
| 安定性 | PoC、社内ツール、非重要ワークロード | ミッションクリティカルな本番処理 |
| 依存関係 | Go moduleで管理しやすい | CGOやOS依存ライブラリが多い |
| 監視 | OpenTelemetryや構造化ログを整備できる | 既存監視基盤がGo workerの挙動をまだ検証していない |
実務では、まず新規の小さな非本番ワークロードで試すのが安全です。たとえば、社内向けWebhook受信、Blobアップロード後のメタデータ抽出、Service Bus Queueの軽量コンシューマー、Timerトリガーの定期クリーンアップなどです。
既存の本番Functionsを移行する場合は、いきなり置き換えず、次の順序で進めると失敗しにくくなります。
- 現在使っているトリガーとバインディングを一覧化する
- Go Public Previewでサポートされるトリガーに収まるか確認する
- Flex Consumptionに移せるネットワーク・リージョン・課金条件か確認する
- ローカルで同等処理を実装し、入出力と例外処理を比較する
- ステージング環境でApplication InsightsやOpenTelemetryのログを確認する
- 負荷試験でコールドスタート、同時実行、メモリ使用量を測る
- GA前の本番投入可否を社内ルールに照らして判断する
展開時に失敗しやすいポイント
Go support for Azure Functionsは便利ですが、プレビュー段階ならではの制約があります。特に以下のポイントは、検証時につまずきやすい箇所です。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| 古いCore Toolsを使っている | プロジェクト作成、ローカル実行、発行でエラーになる | func --versionで4.12以降を確認する |
| 既存のConsumptionプランに載せようとする | Go Function Appがサポート範囲外になる | Flex Consumptionプランで新規検証する |
| Windows前提のビルド成果物をデプロイする | Azure上でバイナリが実行できない | Linux x64向けビルドをCIで明示する |
local.settings.jsonを信用しすぎる | Azure上のアプリ設定が不足して起動しない | Azure App Settingsを別途確認する |
| 接続文字列をそのまま使う | シークレット管理が複雑になる | Managed IdentityとRBACを優先する |
| サポート外トリガーを使う | 設計後に実装できないことが分かる | 最初にトリガー一覧を確認する |
func new前提で作業する | 期待した関数追加フローにならない | Public Preview中はmain.goを直接編集して関数を追加する |
| Durable Functionsを前提にする | GoではPublic Preview中に利用できない | ワークフロー要件は別言語または別サービスで設計する |
特にfunc newが未サポートである点は、既存のFunctions開発に慣れている人ほど見落としやすいポイントです。Goでは、関数を追加するときにテンプレートコマンドだけで進めるのではなく、main.goへトリガー登録とハンドラーを追加する流れをチーム内の開発手順に入れておきましょう。(Microsoft Learn)
監視とログ設計で確認すべきこと
Go Function Appを検証するなら、コードが動くことだけでなく、運用時に必要なログとトレースが取れるかも確認してください。Azure FunctionsのGo workerは構造化ログとOpenTelemetryベースの可観測性をサポートし、標準のlog/slogのコンテキスト対応メソッドを使って関数呼び出しとの相関を取りやすくできます。(Microsoft Learn)
OpenTelemetryを使う場合、host.jsonにtelemetryModeを設定し、アプリ設定で出力先を指定します。Azure Functionsでは、ホストプロセスとワーカープロセスの両方がテレメトリに関係するため、二重ログや二重トレースに注意が必要です。公式ドキュメントでも、コンソール出力やConsoleExporterの使い方によって重複ログが発生し得ることが説明されています。(Microsoft Learn)
実務では、次の3点をステージング環境で確認するとよいでしょう。
| 確認項目 | 見るべき内容 |
|---|---|
| ログ | リクエストID、関数名、エラー内容、外部サービス呼び出し結果が追えるか |
| メトリック | 実行回数、失敗数、実行時間、メモリ使用量、スケール状況が見えるか |
| トレース | HTTP、Service Bus、Event Hubsなどの入口から後続処理まで相関できるか |
Goのfmt.Printlnやlog.Printfだけで済ませると、障害調査時に検索しにくいログになりがちです。検証段階からcontext.Contextと構造化ログを使い、どの関数実行で、どの外部リソースに、どの入力で失敗したのかを追える形式にしておくと、本番化の判断がしやすくなります。
Flex Consumption前提で設計するポイント
Go Function AppはPublic Preview中、Flex Consumptionプランのみ対応です。Flex Consumptionは、従来のサーバーレス課金モデルをベースにしながら、VNet統合、インスタンスメモリサイズ選択、Always ready instances、関数単位のスケーリングなどを提供します。(Microsoft Learn)
管理者が特に見ておきたいのは、メモリサイズとコールドスタート対策です。Flex Consumptionでは512MB、2048MB、4096MBのインスタンスサイズが示されており、公式ドキュメントでは多くのシナリオで2048MBを既定の選択肢として考え、用途に応じて512MBまたは4096MBを検討する考え方が説明されています。(Microsoft Learn)
| 設計項目 | 実務上の判断 |
|---|---|
| インスタンスサイズ | まず2048MBで検証し、CPU・メモリ・同時実行の実測で調整する |
| Always ready instances | 低レイテンシが必要なHTTP APIでは検討する |
| VNet統合 | 内部API、DB、閉域ネットワーク接続が必要な場合に確認する |
| 関数単位のスケーリング | HTTP、Blob、その他トリガーでスケール特性が違う前提で負荷試験する |
| Azure Filesマウント | 大きなバイナリや共有データをパッケージに含めたくない場合に検討する |
Goは軽量なバイナリを作りやすい言語ですが、外部ライブラリやCGOを使う構成では、思ったより起動やデプロイが重くなることがあります。Azure Functionsのコールドスタート対策は言語だけでなく、パッケージサイズ、依存関係、初期化処理、外部接続、インスタンス設定の組み合わせで考えましょう。
採用前のチェックリスト
Go support for Azure Functionsを検証・採用する前に、次のチェックリストを使うと判断しやすくなります。
| チェック項目 | OKの目安 |
|---|---|
| Public Previewであることを関係者が理解している | 本番投入可否を社内ルールで判断している |
| Flex Consumptionを使える | 対応リージョン、ネットワーク、課金、監視の条件を満たしている |
| Go 1.24以降、Core Tools 4.12以降、Azure CLI 2.87.0以降を用意できる | ローカルとCI環境の両方で確認済み |
| 使用するトリガーがサポート範囲に入っている | HTTP、Timer、Cosmos DB、Service Bus、Event Hubs、Event Grid、Blobなどで収まる |
| Durable Functionsに依存していない | 必要な場合は別言語または別アーキテクチャで代替できる |
| Linux x64向けビルドをCI/CDに組み込める | OS依存の問題をステージングで検証済み |
| 認証とシークレット管理を設計済み | anonymous公開や接続文字列の放置を避けている |
| ログ・メトリック・トレースを確認できる | Application InsightsまたはOpenTelemetryで障害調査できる |
| ロールバック方針がある | 既存実装や別ルートに戻せる |
まず何から始めるべきか
Azure FunctionsのGo言語サポートは、Goでサーバーレス処理を書きたいチームにとって大きな前進です。HTTPトリガーではGo標準のnet/httpに近い形で実装でき、Service Bus、Event Hubs、Event Grid、Cosmos DB、Blob Storageなどのイベント駆動処理にも広げられます。
ただし、現時点ではPublic Previewであり、Flex Consumptionプランのみ、Azure上ではLinuxのみ、Durable Functions未対応、サポートトリガー限定という制約があります。いきなり重要な本番処理を移行するのではなく、まずは非本番の小さなHTTP APIやキュー処理で検証し、ビルド、デプロイ、監視、スケーリング、認証の運用手順を固めるのが現実的です。
次に取るべき行動は明確です。Goで動かしたいFunctions候補を1つ選び、Flex Consumptionの検証環境を用意し、func init --worker-runtime goからローカル実行とAzure展開までを一度通してください。そのうえで、トリガーのサポート範囲、ログの見え方、CI/CDのビルドターゲット、プレビュー利用ルールを確認すれば、GoをAzure Functionsで採用すべきか判断しやすくなります。
コメント