Craft Functionsの課金時間（Billable time）の目安

このページの使い方

Craft Functionsを使った機能を設計する際に、想定する処理と実行頻度から 課金時間 を設計段階で概算するためのページです。

契約プランに応じて、ファンクション課金時間について月間あたりの上限が決められています。やりたいことに対してどのプランを契約すれば足りるかの判断のための事前見積もりにお役立てください。

本ページでは、代表的な利用パターンごとに 課金時間 の消費目安を掲載しています。掲載数値はすべて参考値であり、実際の消費量を保証するものではありません。より正確な見積もりには、ご自身の処理内容・呼び出し回数で数十〜数百件ほど試行し、管理画面の課金時間の平均を取ることを推奨します。

課金時間の見積もり

課金時間の計上の考え方

ファンクション内に発生する I/O（データの入出力、Craft KVS等のデータベースとの通信や、外部APIを用いた外部との通信を指します）には、1回あたりの 処理時間 がかかります。本ページでは、この I/Oの処理時間 を積み上げることで、1実行あたり・月間の 課金時間 を見積もります。

本章では、Craft Functionsから利用できるI/Oの種類ごとに、I/Oの処理時間の参考値を掲載します。

なお、I/Oを伴わない通常の業務ロジック（条件分岐・小さな配列操作など）は課金時間に対して誤差程度であることから、本ページでは原則として計上しません。

対象機能一覧

#	対象	使う機能（API）
1	Craft KVS	kvs.get / kvs.write / kvs.list
2	Craft Document DB	docDb.find / docDb.update
3	Craft Counter	counter.get / counter.set
4	外部API	Google Sheets / Analytics / Search Console API

数値の前提

各機能のI/O処理時間は、次の前提に基づく参考値です。

項目	前提
トリガー	イベント駆動タイプのCraft Functions
計測回数	100回
実行形態	ウォーム実行を想定（コールドスタートによる課金時間の増加は含まない）
外部API	ソリューションブログに紹介されている代表的なユースケースで取得した参考値

1回のファンクション実行内で同じI/Oを繰り返す場合、 1回あたりのI/O処理時間は基本的に同じ とみなしています。

課金時間の見積もりでは、I/Oの処理時間を1回あたりの平均時間で足し合わせ、実行回数と日数を掛ける形を取っています。

ただし、外部APIのレート制限や応答のスパイクがある場合は、1件あたりの時間が増えて単純な積み上げでは見積もれないことがあります。ご留意ください。

数値の見方

計測結果に基づいて、 平均時間 と p95 を算出します。

指標	意味合い	見積もりでの使い方
平均時間	通常のI/O処理時間の目安	通常の見積もり時に参照
p95	ごく一部の遅延（スパイク）を除いた、「やや遅いが起こりうる」上限の目安	より保守的な見積もり時に参照

課金時間の計算式

1回のファンクション実行で複数のI/Oを使う場合も、各I/Oの処理時間を合算して見積もります。

1実行あたりのI/O処理時間 ≒ ファンクション内のI/Oの処理時間の合計

1実行あたりの課金時間 ≒ 1実行あたりのI/O処理時間

月間の課金時間 ≒ 1実行あたりの課金時間 × 1日あたりの実行回数 × 30

保守的に見積もる場合は、I/O処理時間に p95 を用いてください。

計算例 — Google SheetsからKVSへ書き込む

想定 : 1回のファンクション実行で、スプレッドシートの設定セルを読み取り（Google Sheets values.get）、KVSの現行値を確認（kvs.get × 2）、差分があれば書き込む（kvs.write × 1）。

項目	内容
1実行あたりのI/O	設定セル取得（values.get）＋現行値確認（kvs.get × 2）＋書き込み（kvs.write × 1）
1実行あたりのI/O処理時間	0.354 + 0.025 × 2 + 0.030 ≒ 0.43秒
1実行あたりの課金時間	上記I/O処理時間の合計 ≒ 0.43秒
実行頻度	1日100回
月間の課金時間	0.43 × 100 × 30 ≒ 1,290秒

I/Oの処理時間の計測結果

1. Craft KVS（読み取り・書き込み・一覧取得）

Craft KVSにアクセスし、1件分のデータの読み取り・書き込みと、複数のデータをまとめて一覧取得する機能の計測です。

1回あたりのI/O処理時間の目安（読み取り・書き込み）

処理	概要	API	平均時間（秒）	p95（秒）
読み取り	1件の読み取り	kvs.get	0.025	0.034
書き込み	1件の書き込み	kvs.write	0.030	0.041

1回あたりのI/O処理時間の目安（一覧取得）

複数ページ分のkvs.listを繰り返して、指定件数をすべて取得するまでの合計時間です（pageSize=30で計測）。

取得件数	pageSize	平均時間（秒）	p95（秒）
20	30	0.039	0.054
50	30	0.074	0.093
100	30	0.134	0.152
500	30	0.546	0.635

2. Craft Document DB（検索・更新・一覧取得）

Craft Document DBにアクセスし、主キーでの1件分の検索と更新、複数のデータをまとめて一覧取得する機能の計測です。

1回あたりのI/O処理時間の目安（主キー操作）

処理	概要	API	平均時間（秒）	p95（秒）
検索	主キーによる1件の検索	docDb.find	0.048	0.062
更新	主キーによる1件の更新	docDb.update	0.060	0.077

1回あたりのI/O処理時間の目安（一覧取得）

複数ページ分の検索を繰り返して、指定件数をすべて取得するまでの合計時間です（take=50で計測）。

取得件数	take	平均時間（秒）	p95（秒）
20	50	0.060	0.086
50	50	0.057	0.068
100	50	0.120	0.146
500	50	0.659	0.738

3. Craft Counter（取得・設定）

Craft Counterの値を取得・設定（カウンタ更新）する機能の計測です。

1回あたりのI/O処理時間の目安

処理	概要	API	平均時間（秒）	p95（秒）
取得	1キーのカウンタ値取得	counter.get	0.019	0.023
設定	1キーのカウンタ値設定	counter.set	0.018	0.025

4. 外部API（Google Sheets・GA4・Search Console）

Google Sheets / GA4 / Search Console等を 同期的に 呼び出す機能の計測です。

1回あたりのI/O処理時間の目安（Google Sheets）

読み取り・書き込み対象のセルサイズを切り替えながら計測します。対象の処理はvalues.get、values.updateとvalues.batchUpdateです。

次の表はセル内が5〜6字程度の短い文字列を想定した参考値です。

セル数	範囲	読み取りvalues.get 平均（秒）	読み取り p95（秒）	書き込みvalues.update 平均（秒）	書き込み p95（秒）	一括書き込みvalues.batchUpdate 平均（秒）	一括書き込み p95（秒）
1	1×1	0.354	0.415	0.328	0.405	0.334	0.416
100	10×10	0.359	0.548	0.352	0.405	0.309	0.421
1,000	10×100	0.342	0.448	0.382	0.511	0.346	0.469
10,000	10×1,000	0.469	0.868	0.592	0.724	0.591	0.704

また、上記に加えてセル内5000字（r0c0 + あ繰り返し）での検証結果は以下となります。(1×1、10×10のみ)

セル数	範囲	読み取りvalues.get 平均（秒）	読み取り p95（秒）	書き込みvalues.update 平均（秒）	書き込み p95（秒）	一括書き込みvalues.batchUpdate 平均（秒）	一括書き込み p95（秒）
1	1×1	0.374	0.645	0.390	0.930	0.438	1.472
100	10×10	0.398	0.634	1.045	1.284	1.169	1.377

両表を比較すると、セル内の文字数が多いほどI/Oの処理時間は伸びる傾向にあります。

1回あたりのI/O処理時間の目安（その他API）

処理	概要	API	平均時間（秒）	p95（秒）
GA4レポート取得	7日分の参照元レポート取得（GA4リファラー分析ソリューションと同型）	analyticsdata.runReport	0.420	0.974
Search Consoleデータ取得	7日分・最大100行の検索分析データ取得（Search Consoleクロス集計ソリューションと同型）	searchanalytics.query	0.247	0.529

参考：craftFunctions.invokeの挙動について

craftFunctions.invokeで別のCraft Functionsを起動する場合の課金時間の計上について説明します。APIの詳細はcraftFunctionsモジュールを参照してください。

仕様上、craftFunctions.invokeは、呼び出し先ファンクションの実行完了までは待たず、 ファンクション実行キューに積んだ時点で 処理が完了します。よって、呼び出し先のファンクションの処理自体は非同期で実行されます。

そのため、呼び出し元の課金時間にはinvokeのAPI呼び出し自体の時間のみが計上され、呼び出し先ファンクションの課金時間は呼び出し元には乗りません。呼び出し先は別の実行として、それぞれの課金時間枠に計上されます。

代表的なユースケースの試算例

以下は、代表的な業務パターンについて、本章の表と課金時間の計算式から試算した月間の課金時間の参考値です。

Datahubの商品マスタをKVSへ同期（5分おき）

ユースケース概要

Datahub上で更新された商品情報（SKU・在庫・価格など）をCraft KVSに反映します。

処理イメージ

営業時間（1日10時間）のあいだに、1商品分のデータ更新が5分に1回のペースで発生し、Datahub連携処理が実行されると仮定します（合計で120回/日）。1度のデータ連携で、KVS書き込み先のキーの存在チェックと更新前のデータ値の取得（kvs.get × 2）、マスタの書き込み（kvs.write × 1）を行います。

試算結果

以下が試算結果です。月間の課金時間は 288秒 となります。

項目	内容
1実行あたりのI/O	キー存在確認・更新前読み取り（kvs.get × 2）＋マスタ反映（kvs.write × 1）
1実行あたりのI/O処理時間	0.025 × 2 + 0.030 ≒ 約0.08秒
1実行あたりの課金時間	上記I/O処理時間の合計 ≒ 約0.08秒
実行頻度	5分に1回 （120回/日）
月間の課金時間	0.08 × 120 × 30 ≒ 288秒

GA4×Search Consoleクロス集計レポート（毎時1回）

ユースケース概要

GA4とSearch Consoleの指標をクロス集計し、スプレッドシートへレポートを出力します。各行には、Craft Document DBに登録した商品情報を紐づけます。

処理イメージ

上記レポート更新処理を 毎時1回 実行すると仮定します（1日24回）。1回あたり、GA4レポート取得（runReport × 1）とSearch Consoleデータ取得（searchanalytics.query × 1）を行います。続けて、レポート用セルの読み取り（Google Sheets values.get × 1）、商品マスタ500件の一覧取得（docDb.find・cursorページング、take=50）、レポートの書き込み（Google Sheets values.update × 1）を行います。

試算結果

以下が試算結果です。月間の課金時間は 約1,400秒 となります。

項目	内容
1実行あたりのI/O	分析データ取得（GA4＋Search Console）＋レポート用セルの読み取り（Google Sheets values.get × 1）＋商品マスタ500件の一覧取得（docDb.find・take=50）＋レポートの書き込み（Google Sheets values.update × 1）
1実行あたりのI/O処理時間	0.420 + 0.247 + 0.354 + 0.659 + 0.328 ≒ 約2.0秒
1実行あたりの課金時間	上記I/O処理時間の合計 ≒ 約2.0秒
実行頻度	毎時1回 （24回/日）
月間の課金時間	2.0 × 24 × 30 ≒ 約1,400秒

「今何人がサイトを見ています」のリアルタイム表示（ページビューごと）

ユースケース概要

サイト上に「現在の訪問者数」をリアルタイム表示します。Craft Counterで訪問者数を集計し、ページ表示時に最新の件数を返します。

処理イメージ

1日10,000 PV のサイトと仮定します。ページビュー（または同等のKARTEイベント）ごとに、訪問者数のインクリメント（counter.set × 1）と、表示用の現在値取得（counter.get × 1）を行います。

試算結果

以下が試算結果です。月間の課金時間は 約1.1万秒 となります。

項目	内容
1実行あたりのI/O	訪問者数の更新（counter.set × 1）＋現在値の取得（counter.get × 1）
1実行あたりのI/O処理時間	0.018 + 0.019 ≒ 約0.04秒
1実行あたりの課金時間	上記I/O処理時間の合計 ≒ 約0.04秒
実行頻度	ページビューごと （10,000回/日）
月間の課金時間	0.04 × 10,000 × 30 ≒ 約1.1万秒

課金時間を抑えるための設計上の留意点

課金時間枠を意識した設計では、次の点に留意できます。

一覧取得はページングを活用する

Craft KVSやCraft Document DBのデータ取得は、複数レコードを一度に取得できる場合は単一レコード取得を繰り返すより課金時間を短くできます。また、複数レコードの取得ではページングサイズを大きくした方が速いです（Craft KVSの上限値は 30 、Craft Document DBには上限は設けられていませんが、最大で 50 を目安としてください）。

I/O回数を減らす

課金時間は概ね I/Oの回数 に比例します。1実行あたりのget/write・外部API呼び出しを必要最小限にし、まとめて処理する（bulk）構築を優先してください。

独立したI/Oの並列実行（Promise.all）

互いに依存しないI/Oを、同期的な処理のままPromise.allで並列に実行すると、 1実行の完了までの時間（レイテンシ）は短縮 しやすいです。非同期な処理を行う際は、ファンクションの性質と制約のとおり、 必ず関数内で非同期処理の完了を待ってください 。

RetryableErrorでリトライを分離する

エラー発生時にリトライを行う場合、実装方法によって課金時間の消費の仕方が異なります。

関数内でリトライする場合（async-retry など）

次回のリトライを待機している間もファンクションが起動し続けているため、その待機時間もファンクションの課金時間を消費してしまいます。

RetryableError を利用する場合

エラーを発生させた時点でファンクションの実行が一旦終了し、次回リトライ時に新たな実行がトリガーされます。そのため、次回リトライを待機している間は課金時間を消費しません。

待機中の無駄な課金時間の消費を抑えるため、RetryableError を利用してシステムにリトライを委譲することを推奨します。