>
>
公開日
最終更新日
FaaS（ファース：Function as a Service）は、ファイルの保存やHTTPリクエストなどのイベントを受け、必要なプログラムだけを1関数単位で実行するクラウドコンピューティングモデルです。物理的なサーバーがなくなるのではなく、OSの更新、実行環境の準備、負荷に応じた拡張をクラウド事業者が担います。
アクセスが少ない業務処理では待機中の計算費用を抑えやすい一方、常時高負荷の処理が必ず安くなるわけではありません。情シスが導入を判断できるよう、サーバーレスとの関係、1関数の設計、主要4サービス、料金試算、国内企業の活用事例、失敗を避ける運用方法まで具体的に整理します。なお、本記事中の料金・無料枠・実行時間・対応言語などのサービス仕様は変更される場合があるため、導入判断の前に各社公式ドキュメントで最新情報を確認し、条件が変わっていた場合は本記事の試算・比較表の数値を読み替えて使用してください。
FaaSとは
FaaSとは、クラウド事業者が管理する実行基盤上で、イベントに応じて個別の関数を起動するサービスです。
本記事のポイント
FaaSはサーバーレス全体ではなく、計算処理を担う実行モデルです。
アプリケーションを1関数単位に分け、必要な処理だけを起動します。
料金はリクエスト数と実行時間が中心ですが、ログや通信などの周辺費用も発生します。
短時間かつイベント駆動の処理には適しますが、長時間処理や常時高負荷のシステムには別方式が適する場合があります。
FaaSの定義と読み方
FaaSはFunction as a Serviceの略称で、関数として記述したコードをクラウド上にデプロイし、指定したイベントが発生したときに実行する仕組みです。Amazonは2014年にAWS Lambdaを発表し、イベント駆動型の関数実行を主要なクラウド利用モデルの一つとして広げました。
利用者が管理する中心領域は、関数のコード、依存ライブラリ、設定、アクセス権限です。サーバーOSの構築やパッチ適用、実行インスタンスの増減はクラウド事業者が担います。ただし、アプリケーションの脆弱性、過剰な権限、秘密情報の取り扱いまで事業者に移るわけではありません。
サーバーレスとの包含関係
サーバーレスとは、利用者がサーバーの調達やOS運用を直接行わず、利用量に応じて拡張されるマネージドサービスを組み合わせる設計概念です。FaaSはそのうち、プログラムの計算処理を受け持つ構成要素です。
たとえば、関数、マネージドデータベース、オブジェクトストレージ、認証サービス、メッセージキューを組み合わせたシステム全体がサーバーレスアーキテクチャです。したがって「FaaSとサーバーレスは同じ」という説明は正確ではなく、「FaaSはサーバーレスを実現する代表的な実行基盤」と整理すると違いが明確になります。パブリッククラウド上で提供されますが、クラウド上の仮想マシンを使うだけではサーバーレスとは限りません。
IaaS・PaaS等との責任分界
FaaS、IaaS、PaaS、CaaS、SaaSの違いは、利用者がどこまで管理するか、何を単位にデプロイするか、どのように課金されるかにあります。
サービスモデル | 主なデプロイ単位 | 利用者の管理範囲 | 代表的な課金単位 | スケーリング |
|---|---|---|---|---|
FaaS | 関数 | コード、依存関係、設定、権限 | 呼び出し回数、実行時間、メモリ・CPU | イベント数に応じて自動拡張 |
IaaS | 仮想マシン | OS、ミドルウェア、アプリケーション | 仮想マシンの稼働時間、容量 | 利用者がルールや台数を設計 |
PaaS | アプリケーション | コード、アプリケーション設定 | インスタンス、CPU、メモリ、リクエスト | サービス設定に基づき自動拡張 |
CaaS | コンテナ | コンテナイメージ、構成、場合によりクラスタ | CPU、メモリ、ノード、実行時間 | サービスやクラスタ単位で拡張 |
SaaS | 完成済みソフトウェア | ユーザー、データ、利用設定 | ユーザー数、機能、利用量 | 原則として提供事業者が管理 |
iPaaSは複数のSaaSやデータを連携するための基盤であり、FaaSは連携途中の変換処理や独自ロジックを実装する用途で併用できます。DaaSは仮想デスクトップを提供するモデルで、関数実行を目的とするFaaSとは対象が異なります。
国内クラウド市場の拡大
2026年3月時点で参照できる直近の推計として、矢野経済研究所は2025年の国内クラウド基盤サービス市場（IaaS/PaaS、事業者売上高ベース）を前年比118.9％の2兆7,100億円と推計しています（出典：矢野経済研究所「国内クラウド基盤サービス市場動向」https://www.yanoict.com/summary/show/id/801）。同研究所は2023年から2029年までの年平均成長率を18.0％とし、2029年には5兆2,200億円へ達すると予測しています。
IDC Japanは対象範囲がより広い国内クラウド市場について、2024年の売上額を前年比29.2％増の9兆7,084億円と集計しました（出典：IDC Japan プレスリリース https://my.idc.com/getdoc.jsp?containerId=prAP53747625）。IDC Japanは2024年から2029年までの年平均成長率を14.6％、2029年の市場規模を19兆1,965億円と予測しています。調査ごとに市場の定義が異なるため数値の単純比較はできませんが、関数、コンテナ、データ基盤を含むクラウド活用が拡大する方向は共通しています。
▶ 関連記事: パブリッククラウドとは？おすすめ比較と導入で失敗しない対策
▲ クラウドサービス分類（IaaS / PaaS / FaaS）における管理領域の対比
FaaSの主な特徴と動作の仕組み
FaaSは、処理を小さな関数に分割し、イベント発生時だけ起動して、負荷に応じて実行環境を増減させます。
1関数単位でのプログラム実行
FaaSにおける1関数とは、「画像を縮小する」「注文データを検証する」「勤怠情報を取得する」など、一つの責務を持つ処理単位です。関数ごとにコードをデプロイし、トリガー、メモリ、タイムアウト、権限、環境変数を設定します。
1関数単位に分けるメリットは、変更範囲と障害範囲を限定できる点です。画像処理だけを更新しても、メール送信や請求処理の関数には影響を与えません。一方、数行の処理まで細分化すると、関数間通信、ログ追跡、デプロイ管理が増えます。「一つの業務責務を完結できるか」「単独で再実行できるか」を分割基準にすると、巨大な関数と細かすぎる関数の両方を避けられます。
イベント駆動型による自動起動
イベント駆動型とは、特定の出来事をトリガーとして関数を自動実行する方式です。代表例は、オブジェクトストレージへのファイル保存、HTTP APIへのリクエスト、データベースの更新、メッセージキューへの投入、決められた時刻の到来です。
利用者や外部システムがイベントを発生させます。
クラウドサービスがイベントを関数へ渡します。
関数が入力を検証し、変換や登録などの処理を実行します。
処理結果をデータベース、ストレージ、キューへ保存します。
非同期イベントは障害時に再配信される場合があります。二重実行で請求やメール送信が重複しないよう、イベントIDを保存して処理済みか判定する「冪等性」を組み込む設計が欠かせません。
リクエストに応じたシームレスなオートスケーリング
FaaSのオートスケーリングは、同時に届いたイベント数に応じて実行環境を自動的に増減する機能です。アクセスがないときはゼロまで縮小できる構成があり、突発的なリクエストには複数の実行環境を立ち上げて並列処理します。
ただし、無制限に処理できるわけではありません。アカウントやリージョンごとの同時実行上限、接続先データベースの最大接続数、外部SaaSのAPIレート制限がボトルネックになります。関数だけを数千並列にすると接続先が先に停止するため、キューで流量を平準化し、同時実行数に上限を設けます。
状態を外部化するステートレス設計
FaaSの関数は、前回と同じ実行環境で動く保証がないため、原則として状態を内部に保持しません。ユーザーセッション、処理済みフラグ、ワークフローの進捗は、データベース、キャッシュ、オブジェクトストレージなどへ保存します。
一時ディレクトリやメモリ上の値が次回も残る前提で実装するのは失敗パターンです。残っていれば再利用してもよいキャッシュと、必ず永続化すべき業務データを分けることで、実行環境が入れ替わっても処理を継続できます。
▶ 関連記事: AWS（アマゾンウェブサービス）とは？特徴や他社比較を解説
▲ イベント発生から関数実行・リソース破棄までの処理フローと構成
FaaSに向く用途と選定前の判断基準
短時間で完了し、発生頻度が変動するイベント処理ならFaaSが有力であり、長時間かつ常時高負荷の処理ならPaaSやコンテナも比較対象に入ります。
FaaSに適したワークロード
FaaSが特に適するのは、待機時間が長く、イベントが発生したときだけ短い処理を実行するワークロードです。社内業務では、申請フォームの入力検証、SaaSのWebhook受信、CSVファイルの整形、定時のデータ取得、監視アラートの通知などが該当します。
ファイル保存後の画像リサイズ、ウイルス検査、メタデータ抽出
APIリクエストに応答する小規模なバックエンド処理
メッセージキューを介した非同期処理
毎日、毎週、月末などに動かすスケジュール処理
IoT機器から届くデータの検証、変換、振り分け
複数のSaaSをつなぐ独自のデータ変換や承認ロジック
FaaSを避ける条件
動画エンコードや大規模な機械学習など、1回の処理が実行時間上限を超える場合は、長時間ジョブを扱えるコンテナ基盤やバッチ基盤が適します。常時一定の高負荷が続くサービスも、従量課金のFaaSより予約済みのコンピューティング資源が安くなる可能性があります。
常駐プロセス、特殊なOS設定、ローカルディスクへの永続保存が必要なアプリケーションも、そのままではFaaSへ移しにくい領域です。処理を分割できるならキューとワークフローで関数を連携し、分割によって整合性が崩れるならPaaS、CaaS、IaaSに残します。
FaaS・PaaS・CaaSの判断基準
利用条件 | 第一候補 | 判断理由 |
|---|---|---|
イベント発生時だけ数秒から数分動く | FaaS | 実行単位で拡張し、待機中の計算費用を抑えやすいため |
Webアプリケーション全体を継続稼働させる | PaaS | ルーティングやアプリケーション単位の管理に適するため |
任意のコンテナや長時間プロセスが必要 | CaaSまたはサーバーレスコンテナ | ランタイムとプロセスを柔軟に制御できるため |
OS、ネットワーク、特殊ソフトウェアを細かく制御する | IaaS | 管理負荷と引き換えに自由度を確保できるため |
Google App Engineはアプリケーション単位でデプロイするPaaSであり、個別関数をイベントで動かすFaaSとは管理単位が異なります。Cloud Runは利用者が用意したHTTPサーバープロセスを含むコンテナを実行するサービスで、「リクエストごとに必ず新しいコンテナを起動する」「Webサーバーが自動で組み込まれる」という仕組みではありません。既存インスタンスは設定された同時実行数の範囲で複数リクエストを処理できます。
導入候補判定チェックリスト
次の項目のうち、前半四つを満たし、後半の制約を設計で解消できるなら限定検証へ進めます。
処理の開始条件をイベントとして定義できる
1回の処理がサービスの実行時間上限内に収まる
永続データを外部サービスへ保存できる
処理の重複に備えて冪等性を実装できる
接続先のAPIやデータベースが並列実行に耐えられる
ログ、メトリクス、トレースを一元的に追跡できる
月間リクエスト数と平均実行時間を概算できる
障害時の再試行回数と退避先を設定できる
4週間の限定検証計画
検証では機能が動くかだけでなく、費用、復旧、監査まで確認します。
期間 | 実施内容 | 完了条件 |
|---|---|---|
第1週 | 対象業務、現行費用、処理件数、応答時間の記録 | 比較前の基準値を数値化できている |
第2週 | 1関数の試作、最小権限、ログ、秘密情報管理の設定 | テスト環境で正常系を再現できる |
第3週 | 負荷試験、タイムアウト、重複イベント、依存先障害の試験 | 失敗イベントを再処理できる |
第4週 | 月額試算、運用手順、監視通知、撤退条件の評価 | 基準値より費用または運用工数が改善する |
▶ 関連記事: DaaSとは？メリットデメリットや製品選定のポイント
▲ ワークロードの特性に応じたFaaS採用の判定フロー
主要なFaaSサービス比較と選定基準
主要サービスは、既存のクラウド環境、実行時間、言語、イベント連携、監視基盤をそろえて比較すると選定しやすくなります。以下の表は2026年3月時点の代表的な仕様をまとめたものです。料金・無料枠・対応言語・実行時間の上限はプランやリージョンの変更により更新されます。最終確認はAWS Lambda料金ページ、Azure Functionsドキュメント、Google Cloud Run functionsドキュメント、Cloudflare Workersプランページをそれぞれ参照し、確認した日付を社内の検討資料に記録した上で判断してください。
主要4サービスの機能比較
2026年3月時点の代表的な仕様を比較すると、AWS LambdaはAWS連携、Azure FunctionsはMicrosoft環境、Cloud Run functionsはGoogle Cloudのデータ基盤、Cloudflare Workersはエッジ処理に強みがあります。実行時間はトリガー、プラン、世代によって異なるため、表では選定時に見るべき条件も併記します。
サービス | 主な対応言語 | 実行時間の代表的な上限 | 得意領域 | デプロイ方式 |
|---|---|---|---|---|
AWS Lambda | Node.js、Python、Java、C#、Go、Ruby、カスタムランタイム | 900秒（15分） | S3、SQS、DynamoDB、API Gatewayなどとの連携 | ZIPパッケージ、コンテナイメージ |
Azure Functions | C#、JavaScript、TypeScript、Python、Java、PowerShellなど | プラン別。従量課金構成では代表的に最大10分 | Microsoft Entra ID、Teams、SharePoint、Azure SQLとの連携 | コードまたは対応プラン上のコンテナ |
Cloud Run functions | Node.js、Python、Go、Java、Ruby、PHP、.NET | 第2世代はHTTP関数が最大60分、イベント駆動関数が最大9分 | BigQuery、Pub/Sub、Cloud Storage、Vertex AIとの連携 | ソースコードをビルドしてコンテナ化 |
Cloudflare Workers | JavaScript、TypeScript、Python、WebAssembly | CPU時間で管理され、プランとトリガーで異なる | CDN、WAFに近いエッジでの認証、変換、振り分け | Workerスクリプト、WebAssemblyモジュール |
Cloud Run functionsへソースコードをデプロイすると、Google Cloud側のビルド処理を通じてコンテナ化されます。任意のコンテナイメージをそのまま動かす要件なら、関数ではなくCloud Runサービスを比較対象にします。Cloudflare WorkersはV8 Isolate上で動作し、一般的なFaaSとは異なり、ネットワーク待機時間ではなく実際のCPU時間を中心に制限や課金を捉えます。Azure FunctionsはプランやトリガーによってCPU・メモリ・実行時間の上限が大きく異なります。表の値はあくまで代表的な数値であり、実際の設計では各サービスの公式ドキュメント（Azure Functions のホスティングオプション、Cloudflare Workers のプランページ等）で該当プランの上限値を確認し、数値が異なる場合は表の記載より公式値を優先してください。
既存インフラとの親和性
AWS上にストレージ、キュー、データベースが集約されているなら、Lambdaを選ぶと認証、ネットワーク、監視を一つのクラウド内で構成できます。Microsoft 365やAzureを社内基盤として使い、C#やPowerShellの資産が多いならAzure Functionsが候補になります。
BigQueryを中心とした分析基盤やPub/Subのデータパイプラインを運用しているならCloud Run functionsが適します。世界各地の利用者に近い場所でURL書き換え、認証、軽量なAPI応答を行うならCloudflare Workersが候補です。既存環境と異なるサービスを選ぶ場合は、クラウド間通信費、ID管理、監視画面の分散を追加費用として扱います。
実行制約と開発言語の適合性
言語が対応表にあっても、使用できるランタイムバージョン、ネイティブライブラリ、デプロイ容量は異なります。既存コードを移す場合は、依存ライブラリを含めたパッケージ容量、起動時間、メモリ消費を試作環境で測定します。
AWS LambdaはNode.js、Python、Java、C#、Go、Rubyなどを公式ランタイムとして扱い、独自言語にはカスタムランタイムを利用できます。IPAのセキュリティ・キャンプ2024では、WebAssemblyがブラウザだけでなくFaaS、IoT、コンテナでも実行される動向が取り上げられました。2026年時点ではWebAssemblyを使ったエッジ実行も選択肢ですが、社内標準言語、デバッグ手段、脆弱性管理まで含めて採用範囲を決めます。
セキュリティと運用機能の比較軸
情シスが比較すべき項目は、関数の速度だけではありません。組織ポリシー、最小権限、秘密情報管理、プライベートネットワーク接続、監査ログ、脆弱性検査、デプロイ承認、予算アラートを同じ条件で評価します。
既存のID基盤で開発者と実行ロールを分離できるか
関数ごとに接続先を限定できるか
本番コードの変更履歴と承認者を記録できるか
ログの保存期間と個人情報のマスキングを設定できるか
リージョン障害時に再デプロイできる構成情報が残るか
監査ログを一元取得できれば既存クラウド上で限定検証へ進み、取得できなければログ転送基盤を先に設計します。プライベート接続が必須なのに対象プランで利用できない場合は、上位プランの固定費を試算し、費用が現行基盤を超えるなら別サービスへ切り替えます。
FaaSの料金体系とコスト試算
FaaSの費用は関数の実行料金だけでなく、API、通信、ログ、ストレージ、予約済み容量を含めて試算します。
料金を構成する項目
一般的なFaaSは、リクエスト数と、割り当てたメモリまたはCPUに実行時間を掛けた使用量で課金されます。ミリ秒単位で集計されるサービスが多いため、アクセスがない時間に関数の計算料金が発生しない構成を作れます。
費用項目 | 発生条件 | 試算に必要な数値 |
|---|---|---|
リクエスト料金 | 関数が呼び出されたとき | 月間イベント数、再試行回数 |
実行料金 | コードが実行されたとき | 平均実行時間、メモリ、CPU |
API料金 | API Gateway等を経由するとき | APIリクエスト数、キャッシュ利用量 |
通信料金 | リージョン外やインターネットへデータを送るとき | 送信先、月間転送量 |
ログ・監視料金 | ログを保存、検索、通知するとき | 1実行当たりのログ量、保存期間 |
ストレージ・DB料金 | 状態やファイルを外部保存するとき | 容量、読み書き回数、バックアップ量 |
予約済み容量 | コールドスタート対策で常時確保するとき | 確保する同時実行数と時間 |
「アクセスがなければシステム全体が0円」とは限りません。関数がゼロまで縮小しても、ログ、データベース、固定IP、ネットワークゲートウェイ、予約済み同時実行には料金が残る場合があります。
月100万回の試算例
平均実行時間300ミリ秒、割り当てメモリ256MB、月100万回の関数を例にすると、計算使用量は「1,000,000回×0.3秒×0.25GB＝75,000GB秒」です。AWS Lambdaには月100万リクエストと400,000GB秒までの無料枠が案内されているため、同一アカウントで無料枠を消費しておらず、対象条件を満たす場合、関数のリクエストと計算使用量は無料枠内に収まります。
一方、同じ関数が月1,000万回実行されると、計算使用量は750,000GB秒です。無料枠を適用できる条件でも350,000GB秒と900万リクエストが超過対象となり、API、ログ、データ転送の料金も加算されます。金額はリージョン、CPUアーキテクチャ、契約、無料枠の使用状況で変わるため、呼び出し回数とGB秒を先に算出すると比較しやすくなります。なお、Azure Functions、Cloud Run functions、Cloudflare Workersはプランやトリガーの種類によって課金単位が異なるため、AWS Lambdaと同一条件の数値を本記事内で並べることはできません。各サービスの実際の費用は公式の料金計算ツール（Azureの料金計算ツール、AWS料金見積もりツール、Google Cloudの料金計算ツール、Cloudflare Workersのプランページ）に自社の想定リクエスト数・実行時間・メモリを入力して算出し、その結果を比較してください。計算結果がFaaSの月額見込みを現行コストが上回る場合はFaaS移行の費用優位があり、下回る場合はPaaSやコンテナとの比較を継続する判断材料になります。
予算超過を防ぐ管理設計
従量課金では、プログラムの不具合がそのまま費用増加につながります。再試行が別の失敗イベントを生成する循環、公開APIへの攻撃、ログへの巨大データ出力は、短期間でリクエスト数や保存量を増やします。
関数とイベントソースの同時実行数を制限します。
再試行回数を定め、失敗後はデッドレターキューへ退避します。
日次と月次の予算アラートを設定します。
ログにリクエスト本文全体を出力せず、必要な識別子だけを記録します。
関数、API、通信、ログを同じタグやプロジェクトで集計します。
費用内訳を関数単位で取得できれば本番トラフィックの一部を移し、取得できなければ先にタグ付けとログ量の上限を整備します。無料枠だけを根拠に本番移行を決めず、通常料金での月額と突発的に10倍へ増えた場合の金額を並べて判断します。
FaaSの導入メリット
FaaSの主なメリットは、インフラ運用の削減、変動負荷への追随、機能単位の変更、イベント処理の迅速な自動化です。
サーバー運用負荷の削減
FaaSでは、OSの導入、セキュリティパッチ、実行サーバーの台数調整をクラウド事業者へ移せます。情シスと開発チームは、業務ロジック、アクセス権限、データ保護、監視、障害対応に時間を配分できます。
ただし、運用作業が消えるわけではありません。ランタイムのサポート終了への対応、依存ライブラリの更新、権限レビュー、ログ監視は利用企業側に残ります。削減できるのは主にサーバーOSと実行基盤の管理であり、アプリケーション運用は継続します。
変動負荷への自動対応
月末処理、キャンペーン、災害情報など、一時的にアクセスが増えるシステムでは、ピークに合わせたサーバーを常時維持せずに済みます。イベント数に応じて関数が並列起動するため、平常時とピーク時の差が大きいほどFaaSの特性を生かせます。
アクセス増加時の可用性は、関数だけで決まりません。データベース、外部API、ネットワークにも上限があるため、キュー、レート制限、タイムアウト、サーキットブレーカーを組み合わせます。
機能単位の開発と変更
関数を業務責務ごとに分けると、担当チームはアプリケーション全体を再デプロイせずに一部の機能を変更できます。障害が起きた関数だけを以前のバージョンへ戻せるため、変更に伴う影響範囲も限定しやすくなります。
この効果を得るには、ソースコード管理、テスト、デプロイを自動化し、開発環境と本番環境の設定差をなくします。管理画面から手作業で関数を修正すると、誰が何を変更したか追跡できず、1関数単位の利点を失います。
業務自動化との親和性
FaaSは、ストレージ、メール、SaaS、データベースで発生したイベントを起点に処理できるため、業務自動化の接着剤として利用できます。市販の連携サービスだけでは表現できない入力検証、社内コードへの変換、承認条件を小さな関数として補えます。
CNCF（Cloud Native Computing Foundation）が2022年に公開した「CNCF Annual Survey 2022」では、サーバーレスアーキテクチャまたはFaaSの使用率が2020年の30％から53％へ増加しています。2022年時点の調査であり、現在は利用サービスや構成が変化している可能性がありますが、関数とコンテナを用途別に組み合わせる流れを把握できる数値です。
FaaS導入の注意点・デメリットと失敗パターン
FaaSでは、コールドスタート、実行時間、監視、権限、再試行、ベンダーロックインを設計せずに導入すると、応答遅延や障害、予算超過につながります。
コールドスタートへの対策
一定時間使われていない関数や新しく拡張された実行環境では、ランタイムとコードを読み込むコールドスタートが発生します。遅延は言語、パッケージ容量、ネットワーク接続、初期化処理によって変わり、対話型APIでは利用者が遅さを感じる場合があります。
対策は、依存ライブラリと初期化処理を減らし、データベース接続を再利用し、遅延を許容できる処理を非同期化することです。厳格な応答時間が必要なら、AWS LambdaのProvisioned ConcurrencyやAzureの対応プランなど、実行環境を事前確保する機能を使います。その固定費を含めるとPaaSやコンテナの方が安くなる場合があるため、平常時とピーク時の両方を測定します。
実行時間とリソース制限への対策
AWS Lambdaの最大実行時間は900秒、つまり15分です。ほかのサービスにもプランやトリガー別の上限があり、メモリ、一時ディスク、デプロイ容量、同時実行数にも制限があります。
上限を超える処理は、入力データを分割してキューへ投入し、複数関数で処理します。各工程の順序や再実行を管理する場合はワークフローサービスを使います。分割できない動画処理や巨大な一括計算は、長時間ジョブに対応するコンテナまたはバッチ基盤へ移します。
ベンダーロックインへの対策
関数のコード自体が一般的な言語で書かれていても、イベント形式、認証、データベース、ワークフロー、監視のAPIはクラウドごとに異なります。特定事業者のサービスを深く使うほど開発速度は上がりますが、移行時の修正範囲も広がります。
移行可能性が高い業務では、業務ロジックとクラウド固有のイベント処理を別モジュールに分け、Infrastructure as Codeで構成を記録します。移行予定がなく、既存クラウドとの統合効果が移植性を上回る場合は、無理に共通化せず、データのエクスポート手段と代替構成だけを文書化します。
監視と分散トレーシングへの対策
一つの業務処理が複数の関数、キュー、APIを通ると、単一サーバーのログだけでは障害箇所を特定できません。「注文APIは成功したが、後続のメール関数が失敗した」といった部分障害が起こります。
すべてのイベントに相関IDを付け、関数名、実行時間、結果、再試行回数を構造化ログとして保存します。エラー率、待ち行列の滞留数、処理時間の上位パーセンタイル、デッドレターキューの件数を監視すると、利用者からの連絡前に異常を検知できます。
権限と秘密情報への対策
複数の関数へ同じ管理者権限を割り当てると、一つの脆弱性から広い範囲へアクセスされます。関数ごとに実行ロールを分け、読み取り対象のストレージ、書き込み先のテーブル、呼び出せるAPIを限定します。
APIキーやパスワードをコードや通常の環境変数へ直接書き込まず、秘密情報管理サービスから実行時に取得します。開発者の権限と関数の実行権限を分離し、退職や異動時には人のアカウントだけを停止できる構成にします。
やってはいけない失敗パターン
動作確認だけで本番化し、再試行、費用、監査を後回しにする導入は避けます。
失敗パターン | 発生する問題 | 実務上の対処 |
|---|---|---|
1関数に全業務を詰め込む | 変更範囲と権限が肥大化する | 一つの業務責務と再実行単位で分割する |
数行ごとに関数を分ける | 通信、ログ、デプロイ対象が増える | 常に一緒に変更する処理は同じ関数へまとめる |
冪等性なしで非同期処理を行う | 二重請求、二重登録、通知重複が起きる | イベントIDと処理済み状態を外部保存する |
データベース接続数を制御しない | 急拡張時にDBの接続上限へ達する | 同時実行数、キュー、接続プロキシを使う |
再試行を無制限に連鎖させる | 障害と料金が増幅する | 回数を制限し、失敗イベントを隔離する |
管理画面で本番コードを直接修正する | 変更履歴と再現性を失う | コードレビューと自動デプロイを経由する |
ワイルドカード権限を共用する | 侵害時の影響範囲が広がる | 関数ごとに最小権限のロールを割り当てる |
FaaSの代表的な活用事例と導入効果
国内企業の公開事例では、新聞、製造、小売のシステムでFaaSが使われ、仮想サーバーやオンプレミスとの比較で90％を超えるコスト削減例も報告されています。
国内企業の導入事例
以下は2026年3月時点で参照できる各クラウド事業者の公開事例です。導入効果は対象システム、アクセス量、比較対象によって変わるため、各社の数値を一般的な削減率として扱わず、自社検証の比較材料として使います。公開事例で導入年月や対象ユーザー数を確認できない項目は、その旨を明記しています。
企業・業種・規模 | 導入時期 | 課題 | 施策 | 成果 |
|---|---|---|---|---|
日本経済新聞社／新聞／紙面ビューアー機能等。対象ユーザー数は公開情報で未確認 | 公開情報で導入年月を確認できず | 紙面関連サービスの需要変動とインフラ費用への対応 | AWS Lambdaを用いたサーバーレス構成 | AWSの事例では、Amazon EC2による同等構成と比べてコストを約10分の1に削減（出典：AWS 日本経済新聞社事例） |
朝日新聞社／新聞／フロントエンド部分。対象ユーザー数は公開情報で未確認 | 公開情報で導入年月を確認できず | フロントエンド基盤の構築・運用費用の削減 | AWS LambdaとAmazon API Gatewayを組み合わせて構築 | AWSの事例では、Amazon EC2で開発した場合と比べて99％のコスト削減（出典：AWS 朝日新聞社事例ページ） |
KYB／製造／予知保全システム等。設備台数は公開情報で未確認 | 公開情報で導入年月を確認できず | 製造設備データを扱う仕組みの導入・運用負担 | AWS Lambda、AWS Step Functions等を採用 | AWSの事例では、オンプレミスに同等の仕組みを構築する場合と比べて導入・運用コストを約97％削減 |
パル／小売／データ統合・可視化基盤。処理件数は公開情報で未確認 | 公開情報で導入年月を確認できず | 複数のデータを分析基盤へ集約する処理の自動化 | Cloud Storageへ収集したデータをCloud FunctionsでBigQueryへ統合 | Google Cloudの事例では、データ収集から統合・可視化までの仕組みを構築 |
タカギ／製造／複数の業務アプリケーション。利用者数は公開情報で未確認 | 公開情報で導入年月を確認できず | C#で開発されたアプリケーション群のクラウド移行 | App ServiceとAzure Functions上でアプリケーションを稼働 | Microsoftの事例では、既存のC#資産を生かした新システムを構築 |
新聞社事例に見るコスト差
日本経済新聞社の約10分の1という結果は、削減率に換算すると約90％です。朝日新聞社は99％削減を報告しており、いずれも常時稼働するEC2の同等構成と、必要時に実行するLambda構成の差が表れた事例です。
ただし、すべてのFaaS導入で90％以上削減できるわけではありません。処理が24時間連続する、予約済み同時実行を常時確保する、ログを大量保存する、データベース費用が支出の大半を占める場合は差が縮まります。自社では現行のサーバー費、保守工数、監視費と、FaaSの実行、API、通信、ログ、データ保存費を同じ期間で比較します。
ファイルアップロード時の画像処理例
ECサイトや社内の商品管理システムでは、画像がストレージへ保存されたイベントを受けて関数を起動し、サムネイル作成、形式変換、メタデータ削除を自動化できます。画像がアップロードされない時間は関数を実行せず、繁忙時は複数画像を並列処理できます。
元画像をアップロード専用領域へ保存します。
保存イベントから画像処理関数を起動します。
関数がファイル形式と容量を検証します。
複数サイズへ変換し、公開用領域へ保存します。
失敗したイベントはキューへ退避し、原因修正後に再処理します。
同じファイルイベントが再送されても画像を重複生成しないよう、ファイルIDと変換設定から出力先を一意に決めます。大容量動画など処理時間が上限を超えるファイルは、イベントから長時間バッチを起動する構成へ切り替えます。
SaaSデータ統合の自動化例
営業、会計、人事などのSaaSから定期的にデータを取得し、社内コードへ変換して分析基盤へ保存する処理にもFaaSを利用できます。毎日午前2時に関数を起動し、前日分だけを取得すれば、連携サーバーを24時間稼働させずに済みます。
APIの取得上限がある場合は、ページ単位で処理位置を保存し、上限到達後は次回の関数へ引き継ぎます。認証トークンは秘密情報管理サービスへ保存し、ログには顧客情報やトークンを出力しません。株式会社パルの事例は、Cloud Storageに集めたデータを関数でBigQueryへ統合する具体例です。
よくある質問
FaaSの導入検討で生じやすい疑問について、選定に必要な結論を簡潔に整理します。
Q1. FaaSとサーバーレスの違いは何ですか？
サーバーレスは、利用者がサーバー管理を直接行わないアーキテクチャ全体の概念です。FaaSはその中で、イベントを受けて関数を実行するコンピューティング基盤です。
Q2. FaaSでは必ず1関数だけでシステムを作りますか？
一つのシステムを一つの関数だけで作る必要はなく、業務責務ごとに複数の関数を組み合わせます。FaaSの「1関数単位」とは、デプロイ、権限、拡張、課金を個別の処理単位で管理できるという意味です。
Q3. FaaSは利用しなければ完全に無料ですか？
ゼロまで縮小できる関数では、実行されていない時間の計算料金を抑えられます。ただし、ログ、データベース、ストレージ、ネットワーク、固定IP、予約済み容量などには料金が発生する場合があります。
Q4. コールドスタートは完全に回避できますか？
事前に実行環境を確保する機能を使えば発生頻度を抑えられますが、その分の固定費が加わります。パッケージの縮小、初期化処理の削減、非同期化も併用し、応答時間の実測値が基準を満たせばFaaS、満たさなければ常時起動型のPaaSやコンテナを選びます。
Q5. Cloud Run functionsとCloud Runの違いは何ですか？
Cloud Run functionsは関数とイベントトリガーを中心にデプロイするFaaSで、Cloud RunはHTTPを受け付けるコンテナをサービスやジョブとして実行する基盤です。任意のコンテナ、長時間処理、複数ルートを持つアプリケーションにはCloud Runが適し、単一目的のイベント処理にはCloud Run functionsが適します。
Q6. FaaSだけで高可用性を確保できますか？
クラウド事業者が実行基盤を冗長化しても、関数の不具合やデータベース、外部APIの障害までは自動解決されません。タイムアウト、再試行、キュー、冪等性、障害イベントの退避、復旧手順を組み合わせてシステム全体の可用性を設計します。
Q7. 情シスが最初にFaaS化しやすい業務は何ですか？
毎日または毎月決まった時刻に動くデータ取得や、ファイル保存後の変換処理が検証対象に向きます。個人情報や基幹取引を含まない処理から始め、現行の実行時間、件数、費用、運用工数と4週間比較すると導入効果を判断できます。
まとめ
FaaSは、イベントに応じて1関数単位のコードを実行し、サーバーOSの運用と負荷調整をクラウド事業者へ移す仕組みです。短時間で変動の大きい処理には適しますが、実行時間、コールドスタート、状態管理、権限、監視、周辺料金まで含めなければ正しく評価できません。
最初の一歩は、個人情報を含まない定期データ取得かファイル変換を一つ選び、現行の処理件数、実行時間、月額、運用工数を記録することです。その後4週間の限定検証で、重複実行、依存先障害、10倍の負荷、月額費用を測定し、基準値を改善できた処理から段階的に移行します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
