定義
自分のコードを「常に起動しているサーバ」に置いておく代わりに、リクエストが来たときだけクラウドが少しの間だけ実行環境を立ち上げて動かし、終わると落とす 方式（AWS Lambda など）を理解するための概念だ。サーバ管理をクラウドに任せる代わりに、コードが守るべき制約（状態を覚えられない、初回実行が遅い）が生じる。
まず用語を解くと：無状態（stateless） は関数が前の呼び出しの記憶（メモリに保存した値）を次の呼び出しで使えないという意味、短命（ephemeral） は実行環境が少しの間だけ生きて消えるという意味、コールドスタート（cold start） は新しい実行環境を初めて立ち上げてコードを初期化するために初回リクエストが遅くなる現象だ。
整理すると Serverless 関数は、リクエストごとに短命な隔離された実行環境で動作する無状態プロセスだ。新しいインスタンスをブートしてランタイム（コード実行に必要な環境）を初期化する初回呼び出しの遅延がコールドスタートだ。これは常にメモリに載っている常駐サーバ（long-running process — 起動し続けて状態を維持する伝統的なサーバ）と対比される。
なぜ必要か
常駐サーバはメモリにインデックス・コネクションプール・キャッシュを持ち続けられるが、サーバレスプラットフォームはコスト・拡張性のためにインスタンスを「必要なときに作り、アイドル時に回収」する。したがって「メモリに載り続けねばならないもの」（検索エンジン、インメモリ DB、ファイルベース DB の書き込みハンドルなど）を関数の中に置くと、期待どおりに動作しない。このモデルを理解してこそ「何を関数の中に置けて、何を外に置くべきか」を正しく分けられる。
動作原理
- リクエストが入ると、プラットフォームは warm インスタンスがあれば再利用し、なければ新しいインスタンスをブートする（コールドスタート）。
- モジュールレベルのコードはインスタンスが生きている間に一度だけ実行される → 重い不変オブジェクトはここで lazy singleton として初期化し、warm 再利用を狙う。
- 一時ファイルシステムは実行中の読み取りは可能だが、インスタンスが死ぬと消える。永続的な書き込みは外部ストレージへ送る。
- 関数に含まれるファイルはビルド時に静的に決定される（file tracing）ので、ランタイムで動的に読むビルド成果物は明示的に含めなければならない。
実務での適用
ランタイムで読むビルド成果物（例：事前ビルドしたインデックスファイル）は、バンドル追跡設定に経路を明示してコールドスタートで欠落しないようにする。リクエスト固有のデータはモジュール全域ではなく、引数/リクエストコンテキストへ流す。
トレードオフ
常駐サーバはメモリ状態を自由に維持できるが運用・スケールのコストが大きい。サーバレスはスケール・コストに有利だがコールドスタートの遅延と無状態の制約を受ける。ライブラリ型インデックスを関数に入れると外部ホスティングなしで軽く配備できるが、大規模・高度なトークナイジングは別途の常駐エンジンが必要だ。
使ってはいけない場合
常時起動していなければならない検索エンジン・DB プロセス、インスタンス間の共有が必要な可変状態、大きな永続書き込みワークロードは、関数の中に置いてはいけない。こうした依存は管理型サービス/専用サーバに分離する。
よくある間違い
- リクエスト固有のデータをモジュール全域変数に保存 → 同時実行の汚染・データ喪失（インスタンス共有時）。
- ランタイムで読むビルド成果物をバンドル追跡に入れず、コールドスタートでファイルが欠落。
- 一時ファイルシステムに永続データを書いて、消えずに残ることを期待する。
関連概念
- inverted-index-full-text-search — 常駐エンジンの代わりに関数内のライブラリ型インデックスを選ぶときのデータ構造の背景。
- single-source-of-truth-content-metadata — ランタイム DB を避けてビルド成果物で決める選択と接する。