第1章: サーバーレスアーキテクチャとFirebase Functionsの基礎
近年、ウェブおよびモバイルアプリケーション開発の世界では、「サーバーレス」という言葉が主流となりつつあります。しかし、この言葉は文字通りの意味とは少し異なります。サーバーが不要になるわけではなく、開発者がサーバーのプロビジョニング、管理、スケーリングといったインフラストラクチャの運用から解放されるアーキテクチャモデルを指します。この革新的なアプローチの中心に位置するのが、Firebase FunctionsのようなFunctions-as-a-Service (FaaS) プラットフォームです。
サーバーレスコンピューティングの本質
従来の開発モデルでは、アプリケーションのバックエンドロジックを実行するために、常に稼働しているサーバー（物理的または仮想的）が必要でした。開発者は、OSのパッチ適用、セキュリティアップデート、トラフィックの増減に応じたリソースの調整など、煩雑なサーバー管理業務に多くの時間を費やす必要がありました。これに対し、サーバーレスアーキテクチャでは、クラウドプロバイダーがこれらの管理業務をすべて引き受けます。
開発者は、特定のイベントに応答して実行される個別の「関数」としてバックエンドコードを記述し、クラウドプラットフォームにデプロイするだけです。これらの関数は、リクエストが発生したときにのみ起動され、処理が完了すると自動的に停止します。このイベント駆動型の性質により、リソースの効率的な利用が可能となり、アイドル時間に対するコストが発生しないという大きな経済的メリットが生まれます。
Firebase Functionsの役割と強力なエコシステム
Firebase Functionsは、Google Cloud Platform上で動作する、スケーラブルなサーバーレスコンピューティングサービスです。その最大の特徴は、Firebaseの他のサービス群とシームレスに統合されている点にあります。これにより、開発者は強力なバックエンド機能を迅速に構築できます。
- イベントトリガー: Firebase Authentication、Cloud Firestore、Realtime Database、Cloud Storageなど、Firebaseエコシステム内の様々なイベントをトリガーとして関数を実行できます。例えば、「新しいユーザーが登録されたとき」「データベースに新しいドキュメントが作成されたとき」「ストレージにファイルがアップロードされたとき」といったイベントに自動的に応答するロジックを実装できます。
- 自動スケーリング: アプリケーションへのトラフィックが増加すると、Firebase Functionsは自動的にインスタンスの数を増やしてリクエストを処理します。逆にトラフィックが減少すれば、インスタンスは縮小されます。開発者はスケーラビリティについて一切心配する必要がありません。
- 従量課金制: 料金は、関数の実行回数、実行時間、および割り当てられたコンピューティングリソースに基づいて計算されます。コードが実行されていない間は料金が発生しないため、特にトラフィックが断続的なアプリケーションや、開発初期段階のプロジェクトにおいてコストを大幅に削減できます。
- HTTPSエンドポイント: HTTPリクエストをトリガーとして関数を実行することも可能です。これにより、独自のWeb APIやWebhookを簡単に作成し、外部サービスとの連携を実現できます。
Firebase Functionsの具体的なユースケース
Firebase Functionsの柔軟性は、多岐にわたるユースケースを可能にします。
- データ処理の自動化: Cloud Storageに画像がアップロードされたら自動的にサムネイルを生成する、Firestoreに書き込まれたテキストデータをサニタイズ（無害化）する、不適切なコンテンツを検出してフラグを立てるなど。
- リアルタイム通知: チャットアプリで新しいメッセージがデータベースに投稿された際に、受信者のデバイスにプッシュ通知を送信する。
- サードパーティAPIとの連携: ユーザー登録時にStripe APIを呼び出して決済顧客情報を作成する、外部の気象情報APIから定期的にデータを取得してデータベースを更新するなど。
- 定型的なメンテナンス作業: スケジュールされた関数を使用して、毎日深夜に不要なログファイルを削除したり、週次レポートを生成してメールで送信したりする。
- 複雑なビジネスロジックの実行: クライアントサイドでは処理が重すぎる、あるいはセキュリティ上の理由で実行させたくない複雑な計算やデータベース操作をバックエンドで安全に実行する。
このように、Firebase Functionsは単なるバックエンドの代替ではなく、アプリケーションの機能を拡張し、開発プロセスを加速させるための強力なツールです。次の章では、この強力なツールを使い始めるための具体的な環境構築手順について詳しく見ていきましょう。
第2章: 開発環境の構築とプロジェクト初期化
Firebase Functionsの開発を始めるためには、まずローカルマシンに適切な開発環境をセットアップする必要があります。この章では、必要なツールのインストールからFirebaseプロジェクトの初期化まで、ステップバイステップで詳しく解説します。
前提条件: Node.jsとFirebase CLIのインストール
Firebase FunctionsはNode.jsランタイム上で実行されるため、Node.jsのインストールが必須です。また、関数の管理やデプロイはFirebase CLI（コマンドラインインターフェース）を通じて行います。
1. Node.jsのインストール
Firebase Functionsは、特定のバージョンのNode.jsをサポートしています。公式ドキュメントでサポートされているバージョンを確認し、インストールすることが推奨されます。通常、LTS（Long Term Support）版をインストールしておけば問題ありません。Node.jsの公式サイトからインストーラーをダウンロードするか、nvm (Node Version Manager) のようなバージョン管理ツールを使用してインストールします。
インストール後、ターミナル（またはコマンドプロンプト）で以下のコマンドを実行し、バージョンが表示されることを確認してください。
node -v
npm -v
2. Firebase CLIのインストール
Node.jsに付属するパッケージマネージャーであるnpmを使用して、Firebase CLIをグローバルにインストールします。
npm install -g firebase-tools
インストールが完了したら、Firebaseアカウントにログインします。以下のコマンドを実行すると、ブラウザが開き、Googleアカウントでの認証が求められます。
firebase login
認証が成功すると、CLIがFirebaseプロジェクトにアクセスできるようになります。
Firebaseプロジェクトの初期化
次に、ローカルで開発するFunctionsプロジェクトを、Firebase上のプロジェクトと紐付けます。まず、プロジェクト用のディレクトリを作成し、そのディレクトリに移動します。
mkdir my-functions-project
cd my-functions-project
そして、以下のコマンドを実行してFirebaseプロジェクトを初期化します。
firebase init functions
このコマンドを実行すると、対話形式でいくつかの質問が表示されます。
- Please select an option: ここでは、既存のFirebaseプロジェクトを使用するか、新しいプロジェクトを作成するかを選択します。「Use an existing project」を選択し、リストから対象のプロジェクトを選びます。
- What language would you like to use to write Cloud Functions? 関数の記述に使用する言語を選択します。
JavaScriptまたはTypeScriptから選択できます。TypeScriptは静的型付けによりコードの堅牢性が向上するため、大規模なプロジェクトでは推奨されますが、ここではJavaScriptを基本に進めます。
- Do you want to use ESLint to catch probable bugs and enforce style? ESLintは、コードの品質を保つための静的解析ツールです。導入することが強く推奨されます。「Yes」と答えるのが一般的です。
- Do you want to install dependencies with npm now? プロジェクトに必要なライブラリ（`firebase-functions`や`firebase-admin`など）をインストールするかどうか尋ねられます。「Yes」と答えると、自動的に
npm installが実行されます。
初期化が完了すると、カレントディレクトリにfunctionsという新しいディレクトリが作成されます。これが、実際にCloud Functionsのコードを記述していく場所になります。
プロジェクト構造の理解
生成されたfunctionsディレクトリの中身は、以下のようになっています。
node_modules/: プロジェクトの依存ライブラリが格納されるディレクトリ。index.js: Functionsのメインファイル。ここに関数の定義を記述していきます。package.json: プロジェクトの情報（名前、バージョンなど）や依存ライブラリ、スクリプトを定義するファイル。.eslintrc.js: (ESLintを選択した場合) ESLintの設定ファイル。.gitignore: Gitでバージョン管理する際に、無視するファイルやディレクトリ（node_modulesなど）を指定するファイル。
特に重要なのは index.js と package.json です。開発の大部分はindex.jsで行い、外部ライブラリを追加する際にはpackage.jsonを編集（またはnpm installコマンドを使用）します。
これで、Firebase Functionsを開発するための準備が整いました。次の章から、具体的な関数の種類とその実装方法について学んでいきます。
第3章: HTTPトリガー: Web APIエンドポイントの作成
Firebase Functionsの最も汎用性の高い機能の一つが、HTTPリクエストによって関数をトリガーする機能です。これにより、特別なクライアントライブラリを必要としない、標準的なWeb APIやWebhookを簡単に構築できます。この章では、onRequestハンドラを使った基本的なHTTP関数の作成から、リクエストデータの処理、レスポンスのカスタマイズまでを詳しく解説します。
基本的なHTTPS関数の作成 (`onRequest`)
最もシンプルなHTTP関数は、リクエストを受け取り、固定のレスポンスを返すものです。functions/index.jsファイルを開き、以下のコードを記述してみましょう。
// firebase-functionsモジュールをインポート
const functions = require('firebase-functions');
// "helloWorld" という名前のHTTP関数をエクスポート
exports.helloWorld = functions.https.onRequest((request, response) => {
// functions.loggerを使用してログを出力
functions.logger.info("Hello logs!", {structuredData: true});
// レスポンスとして "Hello, World!" という文字列を送信
response.send('Hello, World!');
});
このコードの要点は以下の通りです。
require('firebase-functions')で、Functions SDKを読み込みます。exports.helloWorldのようにexportsオブジェクトに関数を割り当てることで、その関数がデプロイ対象となります。helloWorldが関数名になります。functions.https.onRequest()がHTTPトリガーを定義します。- コールバック関数は、Express.jsのハンドラと同様に
requestとresponseの2つの引数を取ります。requestオブジェクトにはリクエストに関する情報（ヘッダー、ボディ、クエリパラメータなど）が含まれ、responseオブジェクトを使ってクライアントに応答を返します。
関数のデプロイと確認
この関数をデプロイするには、プロジェクトのルートディレクトリ（functionsディレクトリの親）で以下のコマンドを実行します。
firebase deploy --only functions
デプロイが完了すると、ターミナルに関数のURLが表示されます。このURLにブラウザやcURLコマンドでアクセスすると、"Hello, World!"というレスポンスが返ってくることを確認できます。
リクエストデータの処理
静的なレスポンスを返すだけではあまり実用的ではありません。APIとして機能させるためには、クライアントから送られてくるデータを処理する必要があります。
クエリパラメータの取得
URLのクエリ文字列（例: ?name=Firebase）からデータを取得するには、request.queryオブジェクトを使用します。
exports.greetUser = functions.https.onRequest((request, response) => {
const name = request.query.name || 'Guest';
response.send(`Hello, ${name}!`);
});
この関数をデプロイし、.../greetUser?name=Taroのようにアクセスすると、"Hello, Taro!"と表示されます。
リクエストボディの解析
POSTリクエストなどで送信されるJSONデータを処理するには、request.bodyオブジェクトを使用します。Firebase Functionsは自動的にJSONボディをパースしてくれます。
exports.createUser = functions.https.onRequest((request, response) => {
// HTTPメソッドがPOSTでない場合はエラーを返す
if (request.method !== 'POST') {
response.status(405).send('Method Not Allowed');
return;
}
const email = request.body.email;
const password = request.body.password;
if (!email || !password) {
response.status(400).send('Bad Request: email and password are required.');
return;
}
// ここで実際にユーザー作成処理を行う (例: Firebase Admin SDKを使用)
// ...
response.status(201).json({ result: `User ${email} created.` });
});
この関数は、POSTメソッドでのみ受け付け、リクエストボディにemailとpasswordが含まれていることを期待します。
レスポンスのカスタマイズとCORSへの対応
ステータスコードとヘッダー
responseオブジェクトは、Express.jsのそれと非常によく似ています。
response.status(200): HTTPステータスコードを設定します。response.send('...'): テキストやHTMLを送信します。response.json({...}): JSONオブジェクトを送信します。Content-Typeヘッダーは自動的にapplication/jsonに設定されます。response.set('Header-Name', 'Header-Value'): カスタムHTTPヘッダーを設定します。response.redirect('/another/path'): リダイレクトを指示します。
CORS (Cross-Origin Resource Sharing)
WebブラウザからHTTP関数を呼び出す場合、CORSの問題に直面することがあります。これは、異なるオリジン（ドメイン、プロトコル、ポート）からのリクエストをブラウザがセキュリティ上の理由でブロックするためです。これを解決するには、関数側で適切なCORSヘッダーをレスポンスに含める必要があります。
手動で設定することも可能ですが、corsというnpmパッケージを使用するのが最も簡単です。
まず、functionsディレクトリでcorsをインストールします。
npm install cors
そして、コードを以下のように修正します。
const functions = require('firebase-functions');
const cors = require('cors')({origin: true});
exports.corsEnabledFunction = functions.https.onRequest((request, response) => {
// corsミドルウェアを適用
cors(request, response, () => {
// ここに本来のロジックを記述
response.json({ message: "CORS is enabled!" });
});
});
cors({origin: true})とすることで、リクエスト元のオリジンを自動的に許可するようになります。本番環境では、originオプションに許可するドメインを明示的に指定することがセキュリティ上推奨されます（例: cors({origin: 'https://your-app.com'})）。
HTTPトリガーをマスターすることで、Firebaseのバックエンド機能を外部のシステムやWebフロントエンドと柔軟に連携させることが可能になります。
第4章: スケジュール実行: 定期的なタスクの自動化
多くのアプリケーションでは、特定の時間に定期的に処理を実行する必要があります。例えば、日次レポートの生成、不要なデータのクリーンアップ、外部APIからのデータ同期などです。Firebase Functionsは、Cloud Pub/SubとCloud Schedulerを内部的に利用して、このようなスケジュールされたタスク（cronジョブ）を簡単に実装する機能を提供します。
スケジュールされた関数の作成
スケジュールされた関数を作成するには、functions.pubsub.schedule()ビルダーを使用します。このメソッドに、実行したいスケジュールを文字列で指定します。
例えば、5分ごとに実行される関数を作成するには、functions/index.jsに以下のように記述します。
const functions = require('firebase-functions');
const admin = require('firebase-admin');
// Admin SDKを初期化（データベース操作などに必要）
// admin.initializeApp()はプロジェクト全体で一度だけ呼び出す
try {
admin.initializeApp();
} catch (e) {
console.log('Admin SDK already initialized.');
}
exports.scheduledFunction = functions.pubsub.schedule('every 5 minutes').onRun((context) => {
console.log('This function will be run every 5 minutes!');
// ここに定期実行したい処理を記述
// 例: データベースの特定のフィールドを更新する
// return admin.firestore().collection('logs').add({timestamp: new Date()});
return null; // 処理が正常に完了したことを示す
});
onRun()メソッドのコールバック関数が、指定されたスケジュールで実行されるコードブロックです。この関数はcontextオブジェクトを引数に取ります。これにはイベントIDやタイムスタンプなどのメタデータが含まれています。
スケジュールの構文
schedule()メソッドには、2種類の構文が使用できます。
1. App Engine cron.yaml 構文
より人間が読みやすい、シンプルな構文です。
every 5 minutes - 5分ごとevery 12 hours - 12時間ごとevery day 09:00 - 毎日午前9時1st,3rd monday of month 10:00 - 毎月第1、第3月曜日の午前10時
多くの一般的なユースケースはこの構文でカバーできます。
2. Unix Crontab 構文
より複雑で詳細なスケジュールを指定したい場合は、標準的なUnixのcrontab構文を使用します。5つのフィールド（分、時、日、月、曜日）をスペースで区切って指定します。
// 毎時0分と30分に実行 (*は「毎」を表す)
exports.complexScheduledFunction = functions.pubsub.schedule('0,30 * * * *').onRun(context => {
console.log('This will run at the 0 and 30 minute mark of every hour.');
return null;
});
* * * * * - 毎分0 9 * * 1-5 - 月曜日から金曜日の午前9時0分*/15 * * * * - 15分ごと
この構文により、非常に柔軟なスケジュール設定が可能です。
タイムゾーンの管理
スケジュールされたタスクで最も重要な考慮事項の一つがタイムゾーンです。デフォルトでは、すべてのスケジュールはUTC（協定世界時）で解釈されます。 これを意識しないと、意図した時間とは異なる時間にタスクが実行されてしまう可能性があります。
特定のタイムゾーンを指定するには、timeZone()メソッドをチェーンします。タイムゾーンは、tz database name format（例: 'America/New_York', 'Asia/Tokyo'）で指定します。
const functions = require('firebase-functions');
exports.scheduledFunctionWithTimeZone = functions.pubsub.schedule('every day 09:00')
.timeZone('Asia/Tokyo') // 日本標準時を指定
.onRun((context) => {
console.log('This function will be run every day at 9:00 AM JST!');
return null;
});
この例では、関数は日本時間の毎日午前9時に実行されます。サマータイム（DST）も自動的に考慮されるため、非常に便利です。
デプロイと注意点
スケジュールされた関数も、他の関数と同様にfirebase deploy --only functionsコマンドでデプロイします。デプロイが完了すると、Google Cloud Schedulerに新しいジョブが自動的に作成され、指定されたスケジュールで関数がトリガーされるようになります。
注意点として、スケジュールされた関数をFirebaseコンソールから削除しても、Cloud Scheduler上のジョブが自動で削除されない場合があります。関数を完全に削除したい場合は、Google Cloud ConsoleのCloud Schedulerのページも確認し、不要なジョブを手動で削除することが推奨されます。
第5章: Cloud Firestoreトリガー: データベース変更への応答
Cloud Firestoreは、リアルタイム同期とオフラインサポートを備えた、スケーラブルなNoSQLドキュメントデータベースです。Firebase FunctionsのFirestoreトリガーを使用すると、データベース内のドキュメントが作成、更新、または削除されたときに、バックエンドコードを自動的に実行できます。これにより、データの整合性維持、集計、他のサービスへの通知といった多くの強力な機能を実装できます。
Firestoreトリガーの基本
Firestoreトリガーは、functions.firestore.document()ビルダーを使用して定義します。このメソッドには、監視したいドキュメントまたはコレクションへのパスを指定します。パスにはワイルドカードを使用して、特定のパターンに一致するドキュメントすべてを監視対象にできます。
ワイルドカードの活用
例えば、/users/{userId}というパスを指定すると、usersコレクション内のいずれかのドキュメントに変更があった場合にトリガーが起動します。ワイルドカードでキャプチャされた部分（この場合はuserId）は、後述するcontextオブジェクトを通じて関数内で利用できます。
ドキュメントの生成 (`onCreate`)
onCreateトリガーは、コレクションに新しいドキュメントが作成されたときに一度だけ実行されます。ユーザー登録時に、関連するプロフィール情報ドキュメントを作成する、といったシナリオで非常に役立ちます。
const functions = require('firebase-functions');
const admin = require('firebase-admin');
try { admin.initializeApp(); } catch (e) {}
// usersコレクションに新しいドキュメントが作成されたときにトリガー
exports.createProfileOnUserCreation = functions.firestore
.document('users/{userId}')
.onCreate((snapshot, context) => {
// context.paramsからワイルドカード部分を取得
const userId = context.params.userId;
console.log(`New user created with ID: ${userId}`);
// 作成されたドキュメントのデータを取得
const userData = snapshot.data();
const email = userData.email;
// 別のコレクションに、公開用のプロフィールを作成する
// この処理は非同期なのでPromiseを返す必要がある
return admin.firestore().collection('profiles').doc(userId).set({
email: email,
createdAt: admin.firestore.FieldValue.serverTimestamp(),
followerCount: 0,
});
});
この例では、usersコレクションにドキュメントが追加されると、そのuserIdを使ってprofilesコレクションに対応するドキュメントを自動的に作成しています。snapshotオブジェクトには作成されたドキュメントのデータが含まれており、snapshot.data()で取得できます。
ドキュメントの更新 (`onUpdate`)
onUpdateトリガーは、既存のドキュメントのフィールドが変更されたときに実行されます。このトリガーのコールバック関数は、changeとcontextという2つの引数を取ります。
change.before: 変更前のドキュメントデータを持つスナップショット。change.after: 変更後のドキュメントデータを持つスナップショット。
これらを利用して、特定のフィールドの変更を検知し、処理を実行できます。
exports.onProfileNameUpdate = functions.firestore
.document('profiles/{userId}')
.onUpdate((change, context) => {
const beforeData = change.before.data();
const afterData = change.after.data();
// displayNameが変更された場合のみ処理を実行
if (beforeData.displayName !== afterData.displayName) {
console.log(`User ${context.params.userId} changed name from ${beforeData.displayName} to ${afterData.displayName}`);
// 例えば、このユーザーの投稿すべてに含まれる著者名を更新するなどの処理を行う
// ...
return; // Promiseを返す非同期処理
}
return null; // 変更がない場合は何もしない
});
この例は、プロフィールのdisplayNameが変更されたことを検知し、関連するデータの更新処理を行うきっかけとしています。
ドキュメントの削除 (`onDelete`)
onDeleteトリガーは、ドキュメントが削除されたときに実行されます。ユーザーがアカウントを削除した際に、そのユーザーに関連するすべてのデータをクリーンアップするのに最適です。
exports.cleanupUserData = functions.firestore
.document('users/{userId}')
.onDelete((snapshot, context) => {
const userId = context.params.userId;
console.log(`User ${userId} deleted. Cleaning up associated data.`);
const db = admin.firestore();
const profileRef = db.collection('profiles').doc(userId);
const postsRef = db.collection('posts').where('authorId', '==', userId);
// バッチ書き込みを使用して、複数の操作をアトミックに実行
const batch = db.batch();
batch.delete(profileRef);
// ユーザーの投稿もすべて削除
return postsRef.get().then(snapshot => {
snapshot.forEach(doc => {
batch.delete(doc.ref);
});
return batch.commit(); // バッチ処理を実行
});
});
この関数は、usersドキュメントが削除されると、対応するprofilesドキュメントと、そのユーザーが作成したすべてのpostsドキュメントを削除します。
注意点: 無限ループの回避
Firestoreトリガーを使用する際、最も注意すべきは無限ループです。例えば、posts/{postId}のonUpdateトリガー内で、同じposts/{postId}ドキュメントを更新するコードを書いてしまうと、その更新が再びonUpdateトリガーを起動し、処理が無限に繰り返されてしまいます。
これを避けるには、
- 関数内で更新する前に、値がすでに目的の状態になっていないか確認する。
- 処理済みであることを示すフラグフィールドを追加し、そのフラグが立っていない場合のみ処理を実行する。
- そもそもトリガーとなったドキュメントを更新する設計を避け、別のドキュメントやコレクションに書き込む。
などの対策が必要です。
第6章: Firebase Realtime Databaseトリガー
Cloud Firestoreが登場する前から存在していたFirebase Realtime Databaseも、リアルタイム性に優れたJSONベースのNoSQLデータベースです。Firestoreと同様に、Realtime Databaseのデータ変更をトリガーとしてFirebase Functionsを実行することができます。この章では、Realtime Databaseトリガーの基本的な使い方を解説します。
基本的なイベントトリガーの作成
Realtime Databaseトリガーは、`functions.database.ref()`ビルダーを使用して定義します。監視したいデータベースのパスをワイルドカードと共に指定する点は、Firestoreトリガーと共通しています。
onCreateイベントトリガーの作成
`onCreate`トリガーは、指定されたパスに新しいデータノードが追加されたときに発火します。`snapshot`オブジェクトには作成されたデータのスナップショットが、`context`オブジェクトにはイベントに関するメタデータが含まれます。
const functions = require('firebase-functions');
const admin = require('firebase-admin');
try { admin.initializeApp(); } catch(e) {}
exports.newNodeCreated = functions.database.ref('/path/to/nodes/{nodeId}')
.onCreate((snapshot, context) => {
const nodeId = context.params.nodeId;
const nodeData = snapshot.val(); // .val()でデータを取得
console.log(`ID "${nodeId}" の新しいノードがデータと共に作成されました：`, nodeData);
// ここに実行したい処理を記述
});
この関数は、`/path/to/nodes/`の下に新しいノードが作成されるたびに実行されます。
onUpdateイベントトリガーの作成
`onUpdate`トリガーは、既存のデータノードが更新されたときに発火します。Firestoreと同様に、コールバック関数は`change`オブジェクトを受け取り、`change.before.val()`で変更前、`change.after.val()`で変更後のデータを取得できます。
exports.nodeUpdated = functions.database.ref('/path/to/nodes/{nodeId}')
.onUpdate((change, context) => {
const nodeId = context.params.nodeId;
const beforeData = change.before.val();
const afterData = change.after.val();
console.log(`ID "${nodeId}" のノードが`, beforeData, 'から', afterData, 'に更新されました');
// ここに実行したい処理を記述
});
この関数は、指定されたパスのデータが更新されるたびに実行されます。
onDeleteイベントトリガーの作成
`onDelete`トリガーは、データノードが削除されたときに発火します。コールバック関数は削除されたデータの`snapshot`を受け取ります。
exports.nodeDeleted = functions.database.ref('/path/to/nodes/{nodeId}')
.onDelete((snapshot, context) => {
const nodeId = context.params.nodeId;
const deletedData = snapshot.val();
console.log(`ID "${nodeId}" のノードがデータと共に削除されました：`, deletedData);
// ここに実行したい処理を記述
});
この関数は、指定されたパスのノードが削除されるたびに実行されます。
onWriteイベントトリガー
Realtime Databaseには、作成、更新、削除のすべてのイベントを捕捉する`onWrite`トリガーも存在します。イベントの種類を判別する必要がある場合は、`change.before.exists()`と`change.after.exists()`を組み合わせて使用します。
- 作成: `!change.before.exists() && change.after.exists()`
- 更新: `change.before.exists() && change.after.exists()`
- 削除: `change.before.exists() && !change.after.exists()`
イベントトリガーのデプロイ
これらの関数も、他の関数と同様に以下のコマンドでデプロイします。
firebase deploy --only functions
デプロイが完了すると、関数は指定されたRealtime Databaseのイベントに応答して自動的に実行されるようになります。
第7章: Cloud Storageトリガー: ファイル操作の自動化
Firebase向けのCloud Storageは、画像、動画、音声ファイルなどのユーザー生成コンテンツを保存・提供するための強力でスケーラブルなオブジェクトストレージです。Storageトリガーを使用すると、バケットへのファイルのアップロード、削除、メタデータ更新といったイベントに応じて、サーバーレスコードを実行できます。
Storageトリガーの主な種類
Storageトリガーは、functions.storageビルダーを使用して定義します。特定のバケットを指定したい場合は.bucket('bucket-name')を、そうでなければデフォルトのバケットが対象となります。
`onFinalize` - ファイルアップロードの完了
onFinalizeトリガーは、新しいオブジェクトがバケットに正常に作成されたとき（アップロードが完了したとき）に実行されます。これは最も一般的に使用されるStorageトリガーです。
実践例：画像のサムネイル生成
ユーザーがプロフィール画像をアップロードした際に、自動的にサムネイル画像を生成する関数を考えてみましょう。これには、画像処理ライブラリ（`sharp`など）と、GCSファイルを操作するための`@google-cloud/storage`が必要です。
まず、必要なライブラリをインストールします。
cd functions
npm install sharp @google-cloud/storage
そして、index.jsに以下のように記述します。
const functions = require('firebase-functions');
const admin = require('firebase-admin');
const { Storage } = require('@google-cloud/storage');
const path = require('path');
const os = require('os');
const fs = require('fs');
const sharp = require('sharp');
try { admin.initializeApp(); } catch (e) {}
const gcs = new Storage();
exports.generateThumbnail = functions.storage.object().onFinalize(async (object) => {
const bucket = gcs.bucket(object.bucket);
const filePath = object.name; // ファイルのパス
const contentType = object.contentType; // ファイルのMIMEタイプ
// 画像ファイル以外、または既にサムネイルの場合は処理を終了
if (!contentType.startsWith('image/') || path.basename(filePath).startsWith('thumb_')) {
return console.log('This is not an image or already a thumbnail.');
}
// 一時ディレクトリにファイルをダウンロード
const tempFilePath = path.join(os.tmpdir(), path.basename(filePath));
await bucket.file(filePath).download({ destination: tempFilePath });
// sharpを使用して200x200のサムネイルを生成
const thumbFileName = `thumb_${path.basename(filePath)}`;
const thumbFilePath = path.join(os.tmpdir(), thumbFileName);
await sharp(tempFilePath).resize(200, 200).toFile(thumbFilePath);
// サムネイルを元のバケットにアップロード
const metadata = { contentType: contentType };
await bucket.upload(thumbFilePath, {
destination: path.join(path.dirname(filePath), thumbFileName),
metadata: metadata,
});
// 一時ファイルをクリーンアップ
return fs.unlinkSync(tempFilePath);
});
この関数は、画像がアップロードされると、それを一時領域にダウンロードし、リサイズしてから同じバケットの同じディレクトリに`thumb_`というプレフィックスを付けてアップロードします。
`onDelete` - ファイルの削除
onDeleteトリガーは、バケットからオブジェクトが削除されたときに実行されます。関連データのクリーンアップに役立ちます。
exports.cleanupOnDelete = functions.storage.object().onDelete(async (object) => {
const filePath = object.name;
console.log(`File ${filePath} was deleted.`);
// 例えば、Firestoreに保存されているこのファイルのURLを削除する処理など
// ...
return;
});
`onArchive` と `onMetadataUpdate`
- `onArchive`: オブジェクトのバージョニングが有効なバケットで、オブジェクトがアーカイブされたときにトリガーされます。
- `onMetadataUpdate`: 既存のオブジェクトのメタデータ（Content-Typeなど）が更新されたときにトリガーされます。
これらのトリガーは特定のユースケースで有用ですが、onFinalizeとonDeleteが最も頻繁に使用されます。
第8章: Authenticationトリガー: ユーザーライフサイクルの管理
Firebase Authenticationは、安全で簡単なユーザー認証システムを提供するサービスです。Authenticationトリガーを使用すると、ユーザーの作成や削除といったライフサイクルイベントをフックして、バックエンドで自動的に処理を実行できます。これにより、ユーザーデータの同期やウェルカムメールの送信などをシームレスに実現できます。
ユーザー作成 (`onCreate`)
`onCreate`トリガーは、新しいユーザーアカウントがFirebase Authenticationで正常に作成された直後に実行されます。これには、メール/パスワード、ソーシャルプロバイダ（Google, Facebookなど）、カスタム認証など、すべてのサインアップ方法が含まれます。
このトリガーのコールバック関数は、作成されたユーザーの情報を含むUserRecordオブジェクトを引数に取ります。
実践例：ユーザープロファイルの同期
Authにユーザーが作成されたら、Cloud Firestoreにそのユーザー専用のプロファイルドキュメントを作成する、という非常によくあるパターンを実装してみましょう。
const functions = require('firebase-functions');
const admin = require('firebase-admin');
try { admin.initializeApp(); } catch (e) {}
exports.createUserProfile = functions.auth.user().onCreate((userRecord) => {
// UserRecordから情報を取得
const { uid, email, displayName, photoURL } = userRecord;
console.log(`New user signed up: ${uid}, email: ${email}`);
// Firestoreの'users'コレクションに新しいドキュメントを作成
// ドキュメントIDはユーザーのUIDと一致させるのが一般的
return admin.firestore().collection('users').doc(uid).set({
email: email,
displayName: displayName || null, // displayNameがない場合もある
photoURL: photoURL || null,
createdAt: admin.firestore.FieldValue.serverTimestamp(),
// アプリケーション固有の初期値を設定
role: 'user',
level: 1,
});
});
この関数により、どの方法でユーザーが登録されても、Firestoreには必ず対応するユーザーデータが作成され、アプリケーション全体でデータの一貫性が保たれます。
ユーザー削除 (`onDelete`)
`onDelete`トリガーは、ユーザーアカウントがFirebase Authenticationから削除されたときに実行されます。これは、ユーザーに関連するすべての個人情報やコンテンツをシステムから完全に消去する（GDPRなどのプライバシー規制への対応）ために不可欠です。
実践例：関連データの完全なクリーンアップ
ユーザーが削除された際に、そのユーザーのFirestoreドキュメント、Storageにアップロードしたファイルなどをすべて削除する関数です。
exports.cleanupUser = functions.auth.user().onDelete(async (userRecord) => {
const { uid } = userRecord;
console.log(`User ${uid} is being deleted. Cleaning up all associated data.`);
const db = admin.firestore();
const storage = admin.storage().bucket();
// 1. Firestoreのユーザープロファイルドキュメントを削除
const userDocRef = db.collection('users').doc(uid);
// 2. Cloud Storageのユーザー専用フォルダを削除
// 例: 'user-files/{uid}/' のような構造を想定
const userStoragePath = `user-files/${uid}/`;
try {
// FirestoreとStorageの削除処理を並行して実行
await Promise.all([
userDocRef.delete(),
storage.deleteFiles({ prefix: userStoragePath })
]);
console.log(`Successfully cleaned up data for user ${uid}.`);
} catch (error) {
console.error(`Error cleaning up data for user ${uid}:`, error);
}
});
この関数は、ユーザーの削除を検知し、そのユーザーIDに関連付けられたデータを各サービスから削除します。これにより、手動でのクリーンアップ作業が不要になり、データの不整合や「ゴミデータ」が残るのを防ぎます。
Authenticationトリガーは、アプリケーションのユーザー管理におけるバックエンドロジックの中核を担う、非常に重要な機能です。
第9章: ローカル開発とデバッグ: Firebase Emulator Suiteの活用
Firebase Functionsの開発が進むにつれて、コードを変更するたびにデプロイして動作確認を行うのは非効率的になります。デプロイには数分かかることもあり、開発サイクルが著しく遅くなります。この問題を解決するのが、Firebase Emulator Suiteです。
Firebase Emulator Suiteとは？
Firebase Emulator Suiteは、Firebaseの主要なサービス（Functions, Firestore, Realtime Database, Authentication, Storageなど）をローカルマシン上で再現するツールセットです。これにより、実際のFirebaseプロジェクトに影響を与えることなく、オフラインで迅速に関数のテストやデバッグを行うことができます。
セットアップと起動
1. 初期設定
まだ設定していない場合、firebase initコマンドでエミュレータを設定します。
firebase init emulators
対話形式で、使用したいエミュレータ（Functions, Firestoreなど）と、それらが使用するポート番号を選択します。通常はデフォルトのままで問題ありません。
2. 起動
プロジェクトのルートディレクトリで以下のコマンドを実行すると、設定したエミュレータが起動します。
firebase emulators:start
起動すると、ターミナルに各エミュレータのエンドポイントと、エミュレータの状態を視覚的に確認できるEmulator Suite UIのURL（通常は `http://localhost:4000`）が表示されます。
Functionsエミュレータでのテスト
エミュレータが起動している状態で、index.jsのコードを編集・保存すると、Functionsエミュレータが自動的に変更を検知し、リロードしてくれます。デプロイの待ち時間は一切ありません。
HTTP関数のテスト
ターミナルに表示されたHTTP関数のローカルURL（例: `http://localhost:5001/your-project/us-central1/helloWorld`）に、cURLやPostman、ブラウザから直接アクセスすることで、即座に動作を確認できます。
バックグラウンドトリガーのテスト
Emulator Suite UIが非常に強力です。例えば、FirestoreエミュレータのUI（`http://localhost:4000/firestore`）にアクセスし、ブラウザ上で直接データを追加・編集・削除すると、それに対応するFirestoreトリガー関数がローカルで実行されます。実行時のログは、エミュレータを起動したターミナルにリアルタイムで表示されるため、デバッグが非常に容易です。
まとめ
Firebase Emulator Suiteは、現代のFirebase開発において不可欠なツールです。開発速度を劇的に向上させ、安全なテスト環境を提供し、クラウドサービスの利用料金を節約することにも繋がります。Functions開発を本格的に行うのであれば、必ず導入しましょう。
第10章: 高度なトピックとベストプラクティス
ここまででFirebase Functionsの基本的な使い方を学んできました。この章では、より堅牢でスケーラブルなアプリケーションを構築するための、高度なトピックとベストプラクティスについて解説します。
環境変数と設定管理
APIキーや外部サービスの設定値など、ハードコーディングすべきでない情報をコード内で扱うには、環境変数を使用します。Firebase CLIには、環境変数を安全に管理するための機能が備わっています。
# 設定値をセット (例: apy.keyというキーにシークレット値を設定)
firebase functions:config:set api.key="your-secret-api-key"
# 設定値を確認
firebase functions:config:get
# コード内でのアクセス方法
const apiKey = functions.config().api.key;
この方法で設定した値は、デプロイ時に安全に関数の実行環境に注入されます。コードをGitなどで公開しても、機密情報が漏洩する心配がありません。
エラーハンドリングとロギング
本番環境で問題が発生した際に迅速に対応できるよう、適切なエラーハンドリングとロギングは不可欠です。
パフォーマンス最適化
- コールドスタート: 関数がしばらく呼び出されていない状態から最初に呼び出される際、起動に時間がかかることがあります。これをコールドスタートと呼びます。グローバルスコープでの処理を最小限に抑える、依存関係を少なくするなどの対策で影響を緩和できます。常に一定のインスタンスをウォーム状態に保つ「最小インスタンス数」の設定も可能です（追加料金が発生します）。
- リージョンの選択: 関数をデプロイするリージョンは、ユーザーや他のリソース（Firestoreデータベースなど）に地理的に近い場所を選択することで、ネットワークレイテンシを削減できます。
- メモリとタイムアウト: 各関数には、割り当てるメモリとタイムアウト時間を設定できます。メモリを多く割り当てるとCPU性能も向上しますが、コストも増加します。処理内容に応じて適切な値を設定することが重要です。
べき等性の確保
ネットワークの問題などで、同じイベントが複数回配信され、関数が複数回実行されてしまう可能性があります。例えば、決済処理を行う関数が2回実行されると、二重課金に繋がってしまいます。このような事態を防ぐため、関数を「べき等」に設計することが重要です。つまり、同じ入力で何度実行されても、結果が常に同じになるように設計します。
- イベントIDを記録し、処理済みのIDであればスキップする。
- Firestoreトランザクションを使用して、処理が一度しか成功しないようにする。
などのテクニックが用いられます。
第11章: まとめ
本稿では、Firebase Functionsの基本的な概念から、各種トリガーの実装、ローカルでの開発手法、そして本番運用を見据えたベストプラクティスまで、幅広く解説してきました。
Firebase Functionsは、サーバーインフラの管理という煩雑な作業から開発者を解放し、アプリケーションのコアな価値創造に集中させてくれる強力なツールです。Firebaseの他のサービスとのシームレスな連携により、従来は多大な工数を要したバックエンド機能を、驚くほど迅速かつスケーラブルに構築できます。
ここで紹介した内容は、Firebase Functionsが持つ可能性のほんの一部に過ぎません。ぜひ、ご自身のプロジェクトで実際に手を動かし、サーバーレスバックエンド開発のパワーを体感してください。
