サーバーレスとは何か？概念の本質を掴む

サーバーレスというと「サーバーがない」と誤解されがちですが、実際にはサーバーは存在しています。違いは「サーバーの管理責任」にあります。従来のオンプレミスやIaaS環境では、OSのパッチ適用、スケーリング、可用性の確保などをすべて自分たちで管理する必要がありました。しかしサーバーレスでは、これらのインフラ管理をクラウドプロバイダーが担当し、開発者は「ビジネスロジック」に集中できるようになります。

これは、電気や水道に似ています。自宅で電気を使うとき、発電所の運転やメンテナンスを気にする必要はありません。使った分だけ料金を支払い、必要なときに必要なだけ使えます。サーバーレスも同じ発想で、「使った分だけ課金」される従量課金モデルを採用し、使わないときはコストがゼロになるという大きな特徴があります。

サーバーレスが生まれた背景と市場の変化

クラウドコンピューティングの進化とともに、インフラ管理の負荷をいかに軽減するかが重要な課題となってきました。2014年にAWSがLambdaを発表したことで、サーバーレスコンピューティングの時代が本格的に幕を開けました。当初はシンプルなイベント処理程度の用途でしたが、現在では基幹システムやデータ分析基盤まで幅広く活用されています。

最近の調査によると、2025年には新規デジタルワークロードの95%以上がクラウドネイティブで展開されると予測されており、もはやサーバーレスは特別な技術ではなく、標準的な選択肢の一つになりつつあります。

引用 : Cloud Will Be the Centerpiece of New Digital Experiences

2025年までに、Gartnerは新規のデジタルワークロードの95%以上がクラウドネイティブ・プラットフォーム上に展開されると予測しており、これは2021年の30%から大幅に増加する見込みです。

サーバーレスとコンテナの違いを理解する

よく比較される技術として「コンテナ」があります。両者の違いを理解することで、サーバーレスの特徴がより明確になります。

表 サーバーレスとコンテナの主要な違い

コンテナは柔軟性が高い反面、Kubernetesなどのオーケストレーション基盤の管理が必要です。一方サーバーレスは制約はあるものの、インフラ管理から完全に解放される点が最大の魅力です。

AWSにおけるサーバーレスサービスの全体像

AWSは包括的なサーバーレスサービス群を提供しており、それぞれが特定の用途に最適化されています。ここでは主要なサービスを体系的に整理して解説します。

コンピューティング層のサーバーレスサービス

AWS Lambdaはサーバーレスの中核を担うFaaS

「AWS Lambda」はFunction as a Service（FaaS）の代表格で、サーバーレスアーキテクチャの中心的な役割を果たします。コードをアップロードするだけで、イベントに応じて自動的に実行される仕組みです。

Lambdaの実装例として、画像アップロード時の自動リサイズ処理を見てみましょう。

import { S3Event, Context } from 'aws-lambda';
import sharp from 'sharp';
import { S3Client, GetObjectCommand, PutObjectCommand } from '@aws-sdk/client-s3';

const s3Client = new S3Client({ region: 'ap-northeast-1' });

export const handler = async (event: S3Event, context: Context): Promise<void> => {
  for (const record of event.Records) {
    const bucket = record.s3.bucket.name;
    const key = record.s3.object.key;

    // オリジナル画像を取得
    const getCommand = new GetObjectCommand({ Bucket: bucket, Key: key });
    const originalImage = await s3Client.send(getCommand);

    // 画像をリサイズ
    const resizedImage = await sharp(originalImage.Body)
      .resize(800, 600)
      .toBuffer();

    // リサイズ済み画像を保存
    const putCommand = new PutObjectCommand({
      Bucket: bucket,
      Key: `resized/${key}`,
      Body: resizedImage
    });
    await s3Client.send(putCommand);
  }
};

このコードは、S3にアップロードされた画像を自動的にリサイズする処理です。サーバーの起動や管理は一切不要で、画像がアップロードされたときだけ実行され、処理が終われば自動的にリソースが解放されます。

AWS Fargateはコンテナのサーバーレス実行基盤

「AWS Fargate」は、コンテナをサーバーレスで実行できるサービスです。ECS（Elastic Container Service）やEKS（Elastic Kubernetes Service）と組み合わせて使用し、EC2インスタンスの管理から解放されます。

Lambdaでは15分の実行時間制限がありますが、Fargateならより長時間の処理も可能です。例えば、動画のエンコーディングや大規模なバッチ処理など、Lambdaの制限を超える処理に適しています。

ECS（Fargate）の構成では、セキュリティをさらに強化するために、AWS WAF を構成して ALB と連携させることが可能です。AWS WAF を設定することで、OASP10をはじめとしたSQL インジェクションや XSS などの一般的な攻撃から防御し、アクセス元の地域を制限することも可能となり、より安全なAPI提供が実現します。

また、トレンドのジャムスタック構成（Next.js や Nuxt.js などを用いてシングルページアプリケーション アプリ）をAWS 上で実現する場合、CloudFront と Amazon S3 を組み合わせてサービスを提供するパターンが一般的で、最もコスト効率に優れます。具体的には、パッケージを含む Web アプリケーションに必要な資材を S3 に配置し、Web アプリケーションから必要なデータを API として呼び出すことが可能です。（セキュリティ性能が高い）

データストレージとデータベースのサーバーレスオプション

Amazon DynamoDBは完全マネージドNoSQLデータベース

「DynamoDB」は、自動スケーリング機能を持つサーバーレスNoSQLデータベースです。アクセスパターンに応じて自動的にキャパシティが調整され、使用した分だけ課金される「オンデマンドモード」を選択できます。

以下のような特徴的な料金体系を持っています。

表 DynamoDBの料金モード比較

わたしたちは、Amazon DynamoDBのサービスデリバリープログラム認定を受けており、DynamoDB専用設計ツール「クラウドシェパード」を提供しています。

Amazon Aurora ServerlessはリレーショナルDBのサーバーレス版

「Aurora Serverless」は、MySQLおよびPostgreSQL互換のリレーショナルデータベースです。2022年にバージョン2がリリースされ、より高速なスケーリングと細かい容量調整が可能になりました。

Aurora Serverlessは、開発環境や負荷が不規則なアプリケーションに特に適しています。例えば、日中は高負荷だが夜間はほとんどアクセスがないような社内システムでは、自動的にスケールダウンすることで大幅なコスト削減が実現できます。

API管理とイベント駆動アーキテクチャ

Amazon API GatewayはサーバーレスAPI管理

「API Gateway」は、RESTful APIやWebSocket APIをサーバーレスで公開・管理できるサービスです。バックエンドのLambda関数と連携し、認証、レート制限、キャッシングなどの機能を提供します。

ビジネスやサービスの要件に応じて、認証処理のカスタマイズやアクセスの流量制御を実装したい場合には、Amazon API Gateway （サーバーレス・APIマネージドサービス）を利用することが効果的です。API Gateway には REST API と HTTP API の 2 種類 があり、それぞれで利用できる機能が異なるので、構築したい内容に応じて構成を検討しましょう。

Amazon EventBridgeはイベントバスサービス

「EventBridge」は、アプリケーション間をイベントで疎結合に接続するサービスです。SaaSアプリケーション、AWSサービス、カスタムアプリケーションからのイベントをルーティングし、複雑なワークフローを構築できます。

例えば、ECサイトでの注文処理フローを考えてみましょう。

import { EventBridge } from '@aws-sdk/client-eventbridge';

const eventBridge = new EventBridge({ region: 'ap-northeast-1' });

// 注文イベントを発行
export const publishOrderEvent = async (orderData: any): Promise<void> => {
  const params = {
    Entries: [{
      Source: 'ecommerce.orders',
      DetailType: 'Order Placed',
      Detail: JSON.stringify(orderData),
      EventBusName: 'default'
    }]
  };

  await eventBridge.putEvents(params);
};

このイベントを受けて、在庫管理、請求処理、配送手配、メール通知などの処理が並列で実行されます。各処理は独立したLambda関数として実装され、疎結合なマイクロサービスアーキテクチャを実現できます。

また、Event BridgeとLambda関数を連携させることで、実行をスケジューリングすることが可能です。その様々なAWS製品のイベントを連携することができます。

実践的なユースケースと導入事例の詳細分析

ここまで技術的な側面を見てきましたが、実際のビジネスシーンではどのように活用されているのでしょうか。RAG情報と最新の事例を基に、具体的なユースケースを掘り下げていきます。

Webアプリケーション開発での活用パターン

シングルページアプリケーション（SPA）のバックエンド構築

最近のWebアプリケーション開発では、React、Vue.js、Angularなどを使用したSPAが主流になっています。このようなアプリケーションのバックエンドをサーバーレスで構築する企業が増えています。

典型的なアーキテクチャは以下の通りです。

• フロントエンド：S3 + CloudFrontで静的ホスティング
• API層：API Gateway + Lambda
• データストア：DynamoDB または Aurora Serverless
• 認証：Amazon Cognito
• ファイルストレージ：S3

実際に、米国の大手小売企業「Neiman Marcus」は、このアーキテクチャを採用してモバイルアプリの開発期間を従来の4か月から半分以下に短縮しました。サーバー管理が不要になったことで、開発チームはユーザー体験の向上に集中でき、結果として顧客満足度の向上につながったといいます。

引用 : Neiman Marcus Increases New Application Speed to Market by 50% on AWS, Improves Digital Selling for Associates

成果

• 開発期間を50%短縮
• 従来の方法に比べて開発コストを90%削減
• 販売員の生産性と顧客対応力が向上

技術構成

• AWS Amplifyでフロントエンドと認証機能を構築
• Amazon Cognitoでユーザー管理
• AWS AppSyncでGraphQL APIを活用し、リアルタイム通知を実装
• AWS Lambdaでスケーラブルな処理を実現

効果

• 販売員が顧客情報を一元的に把握でき、関係性を深める支援ツールとして機能
• KPIの可視化により、販売員のモチベーションも向上

リアルタイム処理が必要なアプリケーション

チャットアプリケーションやライブダッシュボードなど、リアルタイム性が要求されるアプリケーションでも、サーバーレスアーキテクチャが活用されています。

API GatewayのWebSocket機能とLambda、DynamoDBを組み合わせることで、スケーラブルなリアルタイムアプリケーションを構築できます。ただし、Lambdaには「コールドスタート」という課題があり、一定時間使用されていない関数は初回実行時に数百ミリ秒から数秒の遅延が発生する可能性があります。

この問題への対策として、以下のアプローチが有効です。

• Provisioned Concurrencyを使用して関数を常に温めておく
• 定期的にウォームアップリクエストを送信する
• レスポンス要求が厳しい処理は別のアーキテクチャを検討する

基幹システムとエンタープライズ領域での導入

東京海上日動火災保険の事例、段階的なクラウド移行

国内の代表的な事例として、東京海上日動火災保険のケースを詳しく見てみましょう。同社は基幹システム（SoR：System of Record）を含む全社システムのクラウド化を推進しており、2021年末時点で約3割のシステムをAWS上に移行済みです。

同社の特徴的なアプローチは、「FaaS基盤優先」の方針です。新規システムはまずサーバーレス（FaaS）での実装を検討し、どうしても難しい場合のみIaaSを使用するという戦略を取っています。具体的には以下のような段階的アプローチを採用しています。

1. AWS LambdaとDynamoDBを中心としたFaaS基盤の構築
2. 必要に応じてAWS Glueなどのサービスを追加
3. オンプレミスとの接続はDirect Connectで冗長化
4. AWS CodeシリーズによるCI/CDパイプラインの自動化

このアプローチにより、開発スピードの大幅な向上と運用負荷の軽減を実現しています。

Toyota Connectedの事例、大規模IoTデータ処理基盤

トヨタ自動車の「Toyota Connected」プラットフォームは、コネクテッドカーから送信される膨大なテレメトリデータをリアルタイムで処理する基盤です。月間180億件のイベントを処理し、通常時の18倍のトラフィック増にも対応可能な、極めてスケーラブルなアーキテクチャを実現しています。

アーキテクチャの主要コンポーネントは以下の通りです。

• データ取り込み：Amazon Kinesis Data Streams + Lambda
• デコード処理：Lambdaによるセンサーデータのデコード
• データ変換：Amazon EMRでのバッチ処理
• データ保存：S3（データレイク）+ DynamoDB（リアルタイムアクセス用）
• 分析：Amazon Athenaによるアドホッククエリ

このアーキテクチャにより、集計ジョブの所要時間を従来比で40分の1に短縮することに成功しています。また、使った分だけ課金されるモデルのため、地域ごとに小規模版を展開する際もコスト効率良くグローバル展開できています。

データ分析基盤における革新的な活用方法

FINRA（米国金融取引規制機構）の事例、金融ビッグデータ処理

FINRAは、1日あたり37億件の株式取引イベントに対して5,000億回のデータ検証を行う必要がありました。従来のオンプレミス環境では処理能力とコストの両面で限界に達していましたが、AWS Lambdaを中心としたサーバーレスアーキテクチャへの移行により、以下の成果を達成しています。

• システムの処理速度が従来比で3倍向上
• インフラコストを50%以上削減
• 必要に応じて数千のLambda関数を並列実行可能に

Fannie Mae（米国住宅金融）の事例、Monte Carloシミュレーション

Fannie Maeは、住宅ローンポートフォリオのリスク分析にMonte Carloシミュレーションを使用していますが、従来のHPCグリッド環境では6時間かかっていた処理をLambdaベースの新基盤では2時間で完了させることに成功しました。

具体的には、15,000個のLambda関数を同時実行し、20百万件のローンをシミュレーションしています。アイドル時にはコストがゼロになるため、非常に経済的だと報告されています。

公共セクターでの活用、浜松市のスマートシティ基盤

浜松市は、人口80万人超の政令指定都市として、スマートシティ推進のため「都市OS」と呼ばれるデータ連携基盤をAWSのサーバーレス環境上に構築しました。

この基盤の特徴は以下の通りです。

• 行政と民間が保有する様々なデータを統合
• 内閣府のスマートシティ参照アーキテクチャに準拠
• Code for Japanと協力してLambda中心のアーキテクチャを採用
• 利用の拡大に応じて自動的にスケールする柔軟性

所有せず必要な分だけ使うクラウドサービスの利点（コスト低減、リスク回避、スモールスタート可能、スケール容易）を最大限に活用し、全国のモデルケースとなっています。

サーバーレス導入の判断基準と実装上の考慮点

ここまで見てきた事例から、サーバーレスが万能ではないことも明らかになってきました。導入を検討する際の判断基準と、実装上の重要な考慮点について整理していきます。

サーバーレスが適しているケースの具体的な判断基準

トラフィックパターンによる判断

サーバーレスは、以下のようなトラフィックパターンを持つシステムに特に適しています。

• 不規則または予測困難なアクセスパターン
• ピークとオフピークの差が大きい
• イベント駆動型の処理が中心
• 開発・検証環境など断続的な利用

例えば、キャンペーンサイトやイベント受付システムなど、特定期間だけ高負荷になるようなケースでは、サーバーレスによって大幅なコスト削減が期待できます。

ビジネス要件による判断

以下のビジネス要件がある場合、サーバーレスの採用を積極的に検討すべきです。

• 短期間でのサービス立ち上げが必要
• 初期投資を抑えてスモールスタートしたい
• 運用人員が限られている
• グローバル展開を視野に入れている

技術要件による判断

技術的な観点では、以下の要件に合致する場合にサーバーレスが有効です。

• ステートレスな処理が中心
• 処理時間が15分以内で完結する（Lambdaの場合）
• マイクロサービスアーキテクチャを採用している
• イベント駆動アーキテクチャとの親和性が高い

サーバーレスが不向きなケースと代替案

レイテンシ要件が極めて厳しいケース

数ミリ秒単位のレスポンスが要求される高頻度取引システムや、リアルタイムゲームのバックエンドなどでは、Lambdaのコールドスタート問題が致命的になる可能性があります。

このような場合の代替案として、以下が考えられます。

• Amazon EC2のリザーブドインスタンスやスポットインスタンスの活用
• ECS/EKSでのコンテナ基盤の構築
• AWS App Runnerなどの中間的なサービスの検討

長時間実行が必要な処理

動画のエンコーディングや大規模なデータ変換など、15分を超える処理時間が必要な場合、Lambdaでは対応できません。

代替案として、以下のアプローチが有効です。

• AWS Batchでのバッチ処理
• Step Functionsでの処理分割とチェーン実行
• AWS Fargateでのコンテナ実行

レガシーシステムとの統合が複雑なケース

既存のオンプレミスシステムやレガシーERPとの密結合が必要な場合、完全なサーバーレス化は困難な場合があります。

このような状況では、段階的なアプローチが推奨されます。

• 新規機能のみサーバーレスで実装
• APIゲートウェイを介した疎結合化
• ハイブリッドアーキテクチャの採用

実装時の技術的な考慮事項

セキュリティとコンプライアンス

サーバーレス環境では、従来とは異なるセキュリティアプローチが必要です。

表 サーバーレスセキュリティの重要ポイント

モニタリングとオブザーバビリティ

分散システムの特性上、エンドツーエンドのトレーシングが重要になります。

以下のツールとプラクティスが推奨されます。

• AWS X-Rayによる分散トレーシング
• CloudWatch Logsによる集中ログ管理
• カスタムメトリクスの定義と監視
• アラートとエスカレーションの自動化

コスト管理と最適化

サーバーレスは従量課金モデルのため、適切なコスト管理が重要です。

コスト最適化のための具体的な施策を以下に示します。

• Lambda関数のメモリサイズ最適化（パフォーマンスとコストのバランス）
• DynamoDBのオンデマンドとプロビジョンドの使い分け
• S3のストレージクラスの適切な選択
• 不要なリソースの定期的な削除

AWS Lambda Power Tuningのようなツールを使用することで、Lambda関数の最適なメモリ設定を自動的に見つけることができます。

情報システム部門とプロジェクトマネージャーのための導入戦略

最後に、情報システム部門やプロジェクトマネージャーの立場から、サーバーレスをどのように導入していくべきか、戦略的な観点で整理します。

段階的導入アプローチの設計

【フェーズ1】パイロットプロジェクトの選定

まずは小規模で影響範囲の限定的なプロジェクトから始めることが重要です。

理想的なパイロットプロジェクトの条件は以下の通りです。

• ビジネスクリティカルではない
• 既存システムとの依存関係が少ない
• 明確な成功基準が設定できる
• 3〜6ヶ月程度で完了できる規模

例えば、社内向けのツールや、新規のキャンペーンサイト、バッチ処理の一部などが適しています。

【フェーズ2】スキルセットの構築と体制整備

サーバーレス開発には、従来とは異なるスキルセットが必要です。

必要な教育・研修項目として以下が挙げられます。

• クラウドネイティブな設計パターン
• イベント駆動アーキテクチャの理解
• Infrastructure as Codeの実践
• 分散システムのデバッグ手法

AWS Skill BuilderやAWS Well-Architected Labsなどの公式リソースを活用することで、体系的な学習が可能です。

【フェーズ3】本格展開と標準化

パイロットプロジェクトで得られた知見を基に、組織全体への展開を進めます。

標準化すべき項目は以下の通りです。

• アーキテクチャパターンの定義
• CI/CDパイプラインのテンプレート化
• セキュリティガイドラインの策定
• コスト管理プロセスの確立

組織変革とカルチャーの醸成

DevOpsカルチャーの推進

サーバーレスの真の価値を引き出すには、DevOpsカルチャーが不可欠です。開発チームと運用チームの垣根を取り払い、エンドツーエンドの責任を持つ体制が求められます。

具体的な施策として以下が有効です。

• クロスファンクショナルチームの編成
• 自動化の徹底（テスト、デプロイ、監視）
• フィードバックループの短縮
• 失敗を許容し学習する文化の醸成

ガバナンスとコンプライアンスの確立

サーバーレス環境では、従来のガバナンスモデルを見直す必要があります。

新しいガバナンスフレームワークには、以下の要素を含めるべきです。

• リソースタギング戦略の策定
• コスト配賦ルールの明確化
• セキュリティベースラインの定義
• 監査ログの一元管理

AWS OrganizationsとAWS Control Towerを活用することで、マルチアカウント環境での一元的なガバナンスが可能になります。

ROI測定と成功指標の設定

定量的指標の設定

サーバーレス導入の効果を測定するため、以下の定量的指標を追跡することが重要です。

• インフラコストの削減率
• デプロイ頻度の向上率
• 平均リードタイムの短縮率
• システム可用性の向上率

定性的な成果の評価

数値だけでなく、以下のような定性的な成果も評価対象とすべきです。

• 開発者の生産性向上
• イノベーションの促進
• ビジネスアジリティの向上
• 顧客満足度の改善

実際に東京海上日動火災保険では、サーバーレス導入により開発サイクルが大幅に短縮され、ビジネス部門からの要求に迅速に対応できるようになったと報告されています。

まとめ

サーバーレスは単なる技術トレンドではなく、ITインフラストラクチャの在り方を根本から変える可能性を秘めた革新的なアプローチです。本記事で見てきたように、適切に活用することで、コスト削減、開発効率の向上、ビジネスアジリティの向上といった複合的な価値を実現できます。

重要なのは、サーバーレスを「銀の弾丸」として捉えるのではなく、自社のビジネス要件や技術的制約を踏まえた上で、適切な領域に適用していくことです。東京海上日動火災保険やToyota Connectedの事例が示すように、段階的なアプローチと継続的な学習により、大規模な基幹システムでもサーバーレスの恩恵を受けることが可能です。

AWS re:Inventでは、さらなるサーバーレスサービスの拡充が発表されており、今後もこの流れは加速していくでしょう。情報システム部門やプロジェクトマネージャーの皆さんには、まずは小さなプロジェクトから始めて、組織内にサーバーレスの知見を蓄積していくことをお勧めします。

テクノロジーの進化は止まりません。しかし、その本質は常に「ビジネス価値の創出」にあります。サーバーレスアーキテクチャは、エンジニアをインフラ管理の負荷から解放し、より創造的な活動に集中できる環境を提供します。これこそが、サーバーレスがもたらす最大の価値なのかもしれません。