Google Cloud Functionsは、サーバーやコンテナの構築・運用を自分で抱えずに、書いた関数（コード）を1つの単位としてGoogle Cloud上で実行できるサーバーレスのFaaS（Function as a Service）です。HTTPリクエストやストレージへのファイル追加などのイベントをきっかけに関数だけが起動し、使った分だけ課金される従量制のため、常時起動のサーバーを持たずに小さな処理を組み立てられます。本記事では、2024年8月の「Cloud Run functions」への改称と世代ごとの上限値を2026年10月時点の公式ドキュメントで確かめたうえで、トリガー・対応ランタイム・料金と無料枠を整理する構成です。さらにNode.jsの関数をローカルで動かしてからgcloudで公開するまでの実コマンド、AWS LambdaやCloud Run・GKEとの違い、採用の判断軸までを実装者の目線でまとめます。
まとめ：Google Cloud Functionsの正体と2026年時点の採用判断の要点
先に結論を述べます。Google Cloud Functionsは「イベントに反応して短時間の処理を走らせる」用途に向いた土台です。常時稼働のWebサーバーを立てるほどではない自動処理・連携処理を、運用負荷を抑えて素早く動かしたいときに効いてきます。判断の要点は次の4点です。
- 正体はFaaS：関数単位でデプロイし、リクエストやイベントの発生時だけ起動する。アイドル時は課金されず、リクエスト数と計算時間に応じた従量課金になる。
- 改称と世代：2024年8月にCloud Run functionsへ名称が改められ、現行の関数は「ソースコードからデプロイされたCloud Runサービス」として動く。旧第1世代はCloud Run functions（1st gen）として残る（2026年10月時点）。
- 上限値：現行世代はHTTP関数が最大60分、イベント関数が最大9分。メモリは最大16GiB・4vCPU、1インスタンスで最大1,000リクエストを同時に処理できる。
- 向き不向き：Webhook受け・軽量API・ファイル到着時の変換・定期バッチの起点には向く。長時間バッチ、常時稼働の複雑なサービス、コールドスタートを一切許容できない低遅延用途では、Cloud Runなどへの切り替えを検討する。
サーバーレスという考え方そのものの全体像はサーバーレスとは？仕組みとコンテナとの使い分けで、関数実行モデルの制約はFaaSとは？実行時間やコールドスタートの制約と採用判断で補完できます。以下で仕組みから順に掘り下げます。
Google Cloud Functionsの仕組みとサーバーレスFaaSとしての実行単位
Google Cloud Functionsは、Google Cloudが提供するFaaSです。開発者は「入力を受け取り、処理して、結果を返す」という関数を1つ書いてデプロイするだけで、その関数を動かすためのサーバー、OS、スケーリングの仕組みをGoogle Cloud側が受け持ちます。呼び出しが来たときにだけ関数の実行環境が起動し、処理が終われば片付けられるため、待機中のサーバー費用がかかりません。
この「関数だけを預ける」モデルは、サーバーレスと呼ばれる広い分類の中でも、実行の最小単位を関数に置いた形態にあたります。同じサーバーレスでもコンテナ単位で預けるCloud Runとは粒度が異なり、常時起動のインスタンスを持たない点は共通しつつ、扱う対象が「関数」か「コンテナイメージ」かで設計の考え方が分かれます。関数単位ゆえにデプロイが軽く、イベント連携の受け皿を短時間で用意できるのが持ち味です。関数へ確実にタスクを届け、失敗時のリトライやレート制御まで担わせるなら、Cloud Tasksとは（GCPの非同期タスクキュー）の記事が参考になります。
典型的な使いどころは、外部サービスからのWebhookを受けて別処理へ橋渡しする、ストレージにアップロードされた画像をサムネイルへ変換する、データベースの更新をきっかけに通知を送る、定期実行のトリガーから集計を回す、といった「何かが起きたら、短い処理を1つ走らせたい」場面です。逆に、複雑な状態を長く保持し続けるサービスや、数十分に及ぶ重い計算をひとつの実行で完結させたい処理には、後述する制約から不向きになります。
実装の土台になるのは、Googleが公開しているオープンソースのFunctions Framework for Node.js（GitHub）です。Expressをベースにした小さなサーバーで、書いた関数をHTTPの受け口に結び付けます。同じフレームワークがクラウド上でもローカルでも動くため、手元で試した関数をそのまま公開できます。
Cloud Run functionsへの改称と第1世代・現行世代の上限値の違い
Google Cloud Functionsを調べると「Cloud Run functions」という名称に出会います。これは2024年8月に案内された名称の改めで、旧「Cloud Functions（第2世代）」がCloud Run functionsに、旧「Cloud Functions（第1世代）」がCloud Run functions（1st gen）に整理されました。呼び名は変わっても、関数をデプロイして使うという開発体験の骨格は引き継がれています。
現行世代は、Google Cloudのサーバーレスコンテナ実行環境であるCloud Runを基盤に据えています。公式のCloud Run functionsの世代比較ページは、関数を「ソースコードからデプロイされたCloud Runサービス」と説明しています。Cloud Runのリリースノートでは、Cloud Runからの関数デプロイが2024年8月21日にプレビュー、2025年2月19日に一般提供（GA）となりました。両世代の主な差は次の通りです（2026年10月時点の公式値）。
| 観点 | 1st gen | 現行世代 |
|---|---|---|
| HTTP関数の上限 | 最大9分 | 最大60分 |
| イベント関数の上限 | 最大9分 | 最大9分 |
| メモリとvCPU | 8GB・2vCPU | 16GiB・4vCPU |
| 1インスタンスの同時処理 | 1リクエスト | 最大1,000 |
| イベント連携 | 限定的なトリガー | Eventarc経由 |
| 位置づけ | 互換維持向け | 新規構築向け |
見落としやすいのはイベント関数の上限です。現行世代でも60分まで使えるのはHTTP関数だけで、Pub/SubやCloud Storageのイベントで起動する関数は9分で打ち切られます。重い処理をイベント起点で回したい場合は、受け口の関数から別の実行基盤へ渡す設計が前提になります。
また同時処理数の違いは費用にも効きます。1st genは1インスタンスが1リクエストしか持てないため、アクセスが増えるとインスタンスが比例して増える仕組みです。現行世代は1インスタンスで複数のリクエストをさばけるので、I/O待ちの多いAPIほど起動数とコールドスタートを抑えやすくなります。基盤側の詳細はCloud Runとは？GCPのサーバーレスコンテナの仕組みと違いで確認できます。
Google Cloud Functionsの実行モデル：トリガー2系統と対応ランタイム
Google Cloud Functionsの実行は「トリガー」で始まります。トリガーは大きく2系統です。1つはHTTPトリガーで、割り当てられたエンドポイントURLへリクエストが届くと関数が同期的に実行され、レスポンスを返します。軽量なAPIやWebhookの受け口はこの形です。もう1つはイベントトリガーで、クラウド内で発生した出来事を受けて非同期に関数が起動します。
イベントトリガーの供給元には、メッセージングのPub/Sub、ファイル操作を検知するCloud Storage、ドキュメント変更を拾うFirestoreなどがあります。Pub/Subの配信モデルはCloud Pub/Subの基本概念とメッセージング基盤としての役割で、定時起動の起点にするCloud SchedulerはCloud Schedulerとは？GCPのフルマネージドcronの仕組みで整理しています。Firebase側から同じ基盤を使うときのトリガー設計はCloud Functions for Firebaseとはにまとめました。
現行世代ではEventarcを介してイベントを受け取る形が案内されており、対応できるイベント源の幅が広がりました。その起点となるイベントルーティングの仕組みと採用判断はEventarcとは？Google Cloudのイベントルーティングの仕組み・料金と採用判断で解説しています。「HTTPで叩くのか、イベントで発火させるのか」を最初に決めることが、関数設計の出発点になります。
対応言語はNode.js・Python・Go・Java・Ruby・PHP・.NETです。公式のランタイムサポート表（2026年9月24日更新）では、一般提供の最新版はNode.js 24（nodejs24）、Python 3.14（python314）、Java 25、Ruby 4.0、PHP 8.5、.NET 10などで、Node.js 26はプレビューの扱いです。
| ランタイムID | 非推奨日 | 廃止日 |
|---|---|---|
| nodejs24 | 2028-04-30 | 2028-10-31 |
| nodejs22 | 2027-04-30 | 2027-10-31 |
| nodejs20 | 2026-04-30 | 2026-10-30 |
既存の関数をnodejs20で動かしている場合は注意が要ります。非推奨日を過ぎた時点で既に新バージョンへの移行が推奨されており、廃止日以降は関数の作成も更新もできなくなります。2026年10月時点では、新規の関数はnodejs24で始め、既存はnodejs22以上へ上げておくのが安全です。
Node.js関数のローカル実行とgcloud run deployによる公開手順
実装の流れは、環境準備・関数の記述・ローカル確認・デプロイの4段で捉えると迷いません。前提として、Google Cloudのプロジェクトを用意し、gcloudコマンドとNode.jsが使える状態にしておきます。ここではHTTP関数を1つ作り、手元で動かしてから東京リージョンへ公開します。
package.jsonとindex.jsの2ファイルで作るHTTP関数の最小構成
作業用のディレクトリに、依存関係を書くpackage.jsonと、関数本体のindex.jsを置きます。Functions Frameworkは開発時のローカル起動にも使うため、依存に入れておきます。
{
"name": "hello-http",
"main": "index.js",
"scripts": {
"start": "functions-framework --target=helloHttp"
},
"dependencies": {
"@google-cloud/functions-framework": "^5.0.5"
}
}const functions = require('@google-cloud/functions-framework');
functions.http('helloHttp', (req, res) => {
const name = req.query.name || 'world';
res.send('Hello, ' + name);
});functions.httpの第1引数が「エントリポイント名」で、デプロイ時にこの名前を指定します。ファイル名やexportsの書き方ではなく、この登録名で関数が特定される点を押さえておくことが、デプロイ時の指定ミスを防ぐための確認事項です。依存の版は2026年10月時点のnpm最新である5.0系を指定しています。npm installの時点で入る版を確認してください。
npm startとcurlで8080番ポートに返る応答をローカルで確認
依存を入れてから起動すると、Functions Frameworkが既定で8080番ポートに関数を公開します。別のターミナルからcurlで叩き、期待どおりの文字列が返るかを見ます。
npm install
npm start
# 別ターミナルで
curl "http://localhost:8080/?name=issoh"
# Hello, issohここで応答が返れば、クラウドに上げても同じ挙動になります。デプロイしてからエラーに気付くと待ち時間が長いので、ローカルで一度通しておくのが近道です。
gcloud run deployとgcloud functions deployの2種
公式の関数デプロイ手順では、新規の関数はgcloud run deployに–functionでエントリポイントを、–base-imageでランタイムを渡す形が案内されています。
gcloud run deploy hello-http \
--source . \
--function helloHttp \
--base-image nodejs24 \
--region asia-northeast1 \
--allow-unauthenticated既存の関数をgcloud functionsコマンドで管理している場合は、後方互換として次の書き方も引き続き使えます。旧記事で多く見かけるnodejs20の指定は、前章の廃止日を踏まえてnodejs24へ置き換えます。
gcloud functions deploy helloHttp \
--gen2 \
--runtime nodejs24 \
--trigger-http \
--region asia-northeast1 \
--allow-unauthenticatedデプロイが終わると関数のエンドポイントURLが払い出されるので、そのURLへアクセスして期待どおりの応答が返るかを確かめます。ソースからのデプロイではビルドしたイメージがArtifact Registryに保存されるため、保存先と課金の扱いはArtifact Registryとは？Google Cloudの成果物リポジトリの仕組みで押さえておくと見積りが崩れません。
Cloud Storageへのファイル追加で動くイベント関数とEventarcトリガー
イベント関数はfunctions.cloudEventで登録し、引数のcloudEventからバケット名やファイル名を取り出します。Cloud Storageのイベントで関数を起動する公式チュートリアルに沿うと、関数本体は次のとおりです。
const functions = require('@google-cloud/functions-framework');
functions.cloudEvent('helloGCS', (cloudEvent) => {
const file = cloudEvent.data;
console.log(`Bucket: ${file.bucket}`);
console.log(`File: ${file.name}`);
});この関数をgcloud run deployで公開したうえで、ファイルの書き込み完了イベントを関数へ届けるEventarcトリガーを作ります。
gcloud eventarc triggers create gcs-to-hello \
--location=asia-northeast1 \
--destination-run-service=hello-gcs \
--destination-run-region=asia-northeast1 \
--event-filters="type=google.cloud.storage.object.v1.finalized" \
--event-filters="bucket=PROJECT_ID-bucket" \
--service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.comトリガーの作成前に、Cloud Storageのサービスエージェントへroles/pubsub.publisherを、トリガーのサービスアカウントへroles/eventarc.eventReceiverとroles/run.invokerを付与しておきます。権限が欠けるとトリガー作成やイベント配信で止まるため、まず権限を疑うのが、切り分けを早く済ませる方法です。バケット側の設計はCloud Storage（GCS）とは？仕組み・4つのストレージクラスで確認できます。
運用に入ってからは、関数の標準出力がCloud Loggingに集まります。エラー率やコールドスタートの頻度、同時実行の上限に触れていないかを見る仕組みは、Cloud Loggingとは？Google Cloudのログ管理の仕組みを参考にログルーターとアラートまで用意しておくと安心です。
Google Cloud Functionsの料金体系と無料枠・実行制約の確認ポイント
料金は従量課金です。現行世代の関数はCloud Runサービスとして動くため、Cloud Runの公式料金ページの単価で請求されます。課金対象は主に「リクエスト数」と「関数が動いた時間に応じたvCPUとメモリの量」で、これにネットワークの送信量を加えたものが請求の対象です。リクエストベースの課金では、リクエストを処理している時間が100ミリ秒単位で切り上げて計算されます。
無料枠は請求先アカウント単位で毎月リセットされ、us-central1の単価を基準に次の量が差し引かれます（2026年10月時点）。東京リージョン（asia-northeast1）はティア1の単価区分に入っています。
| 課金・制約の観点 | 目安（2026年10月時点） |
|---|---|
| CPUの無料枠 | 毎月180,000 vCPU秒 |
| メモリの無料枠 | 毎月360,000 GiB秒 |
| リクエストの無料枠 | 毎月200万リクエスト |
| 課金単位 | リクエスト＋計算時間＋転送量 |
| 待機中の課金 | 原則なし（従量） |
注意点が2つあります。1つは、1st genの関数はCloud Runの料金表に含まれず、別の料金ページで計算する点です。もう1つは、イベント関数の配信を担うEventarcの料金もCloud Runとは別建てである点です。見積りでは関数本体・イベント配信・イメージ保存・ログ保管を分けて積み上げると、請求との差が出にくくなります。
実装上の勘所は制約側にあります。まず実行時間の上限があるため、数時間かかる重いバッチをひとつの関数で完結させる設計は現実的ではありません。次にコールドスタートで、しばらく呼ばれていない関数は起動に一拍かかるため、常に低遅延を求められる用途では待ち時間が問題になります。加えて、大量アクセスが一気に来るとインスタンス数の上限に触れることがあり、下流のデータベースへ負荷が集中しないよう、最大インスタンス数の設定で流量を絞る設計もあわせて考えます。
AWS LambdaやCloud Run・GKEとの違いと粒度で選ぶ使い分けの判断軸
関数を動かすだけなら似た選択肢が複数あります。まずAWS Lambdaは、AWS側のFaaSで思想がよく似た関係です。Google Cloud Functionsを選ぶ判断は多くの場合「基盤としてどのクラウドに寄せるか」で決まり、周辺サービスとの連携のしやすさが決め手になります。関数モデルそのものの比較観点はAWS Lambdaとは？仕組みと料金・採用判断と読み比べると輪郭がはっきりします。
同じGoogle Cloudの中では、Cloud RunとGKEが比較対象になります。Cloud Runはコンテナ単位のサーバーレスで、任意のイメージを動かせるぶん自由度が高く、複数のエンドポイントや常時性の高い処理まで受け止められます。GKE（Kubernetes）は自前でクラスタを運用し、細かな制御と引き換えに運用負荷を引き受ける選択肢です。粒度と運用負荷の関係を整理すると次のようになります。
| 選択肢 | 実行単位 | 向く用途 |
|---|---|---|
| Cloud Functions | 関数 | イベント受け・軽量API |
| Cloud Run | コンテナ | 常時性のあるWeb処理 |
| GKE | Pod（k8s） | 大規模で複雑な基盤 |
判断軸はシンプルです。「イベントに反応する単発処理」ならCloud Functions、「常に受け付けるWebアプリやAPI群」ならCloud Run、「多数のサービスを緻密に束ねる基盤」ならGKE、と粒度で選ぶのが出発点になります。現行世代のCloud FunctionsはCloud Runサービスそのものとして動くため、関数から始めて手狭になったらコンテナへ寄せるという移行のしやすさも判断材料に加えられます。
認証の扱いも、関数の設計時に決めておくべき項目です。誰でも叩ける公開エンドポイントにするなら–allow-unauthenticated、呼び出し元を絞るなら–no-allow-unauthenticatedを指定し、外部公開する関数では入力検証と認証を関数側で必ず組み込みます。実運用の設計や周辺基盤の構築まで含めて相談したい場合は、インフラ構築（AWS・Google Cloud・Azure）のように、クラウド横断で設計を支援できる体制と組むと、世代選定や移行方針まで含めた判断がしやすくなります。
Google Cloud Functionsを採用すべき場面と見送るべき場面の判断条件
ここは判断を言い切ります。Google Cloud Functionsを採用すべきなのは、次の条件が揃うときです。処理が「イベントに反応する短時間の単発」で完結し、実行が常時ではなくまばら、かつ運用チームを厚く持たずに素早く動かしたい――この3条件に当てはまるなら、関数単位の軽さと従量課金の相性が効き、Cloud Functionsが有力な第一候補になります。Webhook受け、ファイル到着時の変換、更新通知、定期集計の起点は典型的な適用例です。
逆に見送るべきなのは、次のいずれかに強く当てはまる場合です。第一に、ひとつの実行が上限を超える長時間バッチ。イベント起点なら9分、HTTP起点でも60分が壁になります。第二に、コールドスタートによる初回の待ちを一切許容できない低遅延・常時応答の用途。第三に、複雑な状態を長く保持し、細かな並行制御やミドルウェアを自前で握りたいケースです。これらでは、コンテナ単位で常時性を確保できるCloud Runや、緻密な制御が効くGKEへ寄せるほうが素直に収まります。
迷いやすいのは「常時ではないが、たまに重い」処理です。この場合は、軽い受け口だけをCloud Functionsに置き、重い本処理はCloud Runのジョブや非同期の基盤へ渡す、という役割分担が現実解になりやすい構成です。関数を万能の実行環境と捉えず、「イベントの入口」として割り切ると、システム全体の見通しが良くなります。サーバーレス全体の中での位置づけはサーバーレスとはの判断整理とあわせて捉えると、選定の根拠を言語化しやすくなります。
よくある質問
Google Cloud Functionsの名称・選び方・料金・運用について、実装前によく確認される5つの疑問に答えます。
Google Cloud FunctionsとCloud Run functionsは何が違いますか？
別サービスではなく、同じサービスの名称が改められたものです。2024年8月にCloud FunctionsはCloud Run functionsへ改称され、旧第2世代が現行のCloud Run functions、旧第1世代がCloud Run functions（1st gen）にあたります。関数をデプロイして使う仕組みは引き継がれているため、改称によって既存の関数がそのまま動かなくなるわけではありません。ただしランタイムには廃止日があるので、使っている版の期限は別に確認してください（2026年10月時点）。
Google Cloud FunctionsとCloud Runはどちらを選ぶべきですか？
実行単位で選びます。イベントに反応する単発の処理なら関数単位のCloud Functions、常に受け付けるWebアプリやAPI群ならコンテナ単位のCloud Runが素直です。現行世代の関数はソースコードからデプロイされたCloud Runサービスとして動くため、関数から始めて手狭になったらDockerfileを用意してCloud Runへ寄せる移行もしやすくなっています。
Google Cloud Functionsの料金はどのくらいかかりますか？
リクエスト数と計算時間（vCPU秒・GiB秒）、データ転送量に応じた従量課金です。毎月180,000 vCPU秒・360,000 GiB秒・200万リクエストまでの無料枠があり、待機中は課金されません。少量の利用なら無料枠に収まることも多い一方、単価は改定されるため、見積り時は公式の料金ページで最新の値を確認してください。1st genとEventarcは別の料金表で計算します。
コールドスタートはどの程度気にすべきですか？
用途しだいです。バッチや非同期のイベント処理では初回の一拍は問題になりにくい一方、ユーザーが待つ同期APIでは体感に響きます。現行世代は1インスタンスで複数のリクエストをさばけるため、1st genよりも起動回数を抑えやすい構造です。それでも低遅延が要件なら、最小インスタンスを確保する設定や、常時性のあるCloud Runへの切り替えを検討します。
どのプログラミング言語とバージョンで書けますか？
Node.js・Python・Go・Java・Ruby・PHP・.NETに対応しています。2026年10月時点の一般提供版ではNode.js 24、Python 3.14、Java 25などが最新です。いずれも「リクエストやイベントを受け取り、処理して返す」という関数の入口を書く形は共通で、既存チームの得意な言語を選べます。nodejs20は2026年10月30日に廃止予定のため、新規ではnodejs24を選んでください。
関連記事
- サーバーレスとは？仕組み・メリットとコンテナとの使い分けを解説：関数とコンテナのどちらに預けるかの全体像
- FaaSとは？サーバーレスとの関係・実行時間やコールドスタートの制約と採用判断を解説：関数実行モデルに共通する制約
- Cloud Runとは？GCPのサーバーレスコンテナの仕組み・料金とGKE/Cloud Functionsとの違い：現行世代の基盤そのもの
- AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説：AWS側の同等サービスとの比較
- FlutterとCloud Functionsの基本概念とその重要性：モバイルアプリから関数を呼ぶ構成
