Twelve-Factor App

Twelve-Factor App とは

Twelve-Factor App は、Heroku の開発者が2011年にまとめた、クラウド（SaaS）で動かしやすいアプリの設計原則12項目です。特定の言語やフレームワークの話ではなく、「どう作っておくと、スケールしやすく・移植しやすく・自動化しやすいか」という 共通の作法 を整理したものです。

背景にあるのは、アプリを 使い捨てできるプロセス として扱うという発想です。サーバを大事に育てる（ペット）のではなく、いつでも壊して作り直せる（家畜）状態にしておく。この考え方は、後のコンテナ（/devops/container-vs-vm/）やイミュータブルインフラ（/devops/immutable-infra/）と一直線につながります。

12の原則（概要）

12項目は次の通りです。1つずつ覚えるより、「設定・状態・ログ・プロセスをどう扱うか」 という塊で捉えると実務に効きます。

コードベース：1アプリ＝1リポジトリ。同じコードを複数環境にデプロイする。
依存関係：使うライブラリを明示的に宣言し、システム任せにしない。
設定：環境ごとに変わる値（DB 接続先・鍵）はコードから分離し 環境変数 へ。
バックエンドサービス：DB やキューは 付け替え可能なリソース として URL 等で接続する。
ビルド・リリース・実行：3段階を厳密に分離する（後述）。
プロセス：アプリは ステートレス な1つ以上のプロセスとして実行する。
ポートバインディング：自分でポートを開いて待ち受け、自己完結する。
並行性：プロセスを 増やして スケールアウトする（垂直増強に頼らない）。
廃棄容易性：起動は速く、停止は穏やかに。いつ落ちても良いように作る。
開発／本番一致：開発・ステージング・本番の差を 小さく 保つ。
ログ：ログは イベントストリーム として標準出力へ流すだけにする。
管理プロセス：DB マイグレーション等は 同じ環境 でワンオフ実行する。

設定は環境変数へ（Factor 3）

最も実務インパクトが大きいのが 「設定とコードの分離」 です。DB のパスワードや API キー、接続先ホストといった 環境ごとに変わる値 をコードに書き込むと、環境を増やすたびに分岐が増え、秘密情報がリポジトリに漏れます。

Twelve-Factor では、これらを 環境変数 として外から注入します。

# コードには書かず、環境から渡す
export DATABASE_URL="postgres://user:pass@db.internal:5432/app"
export LOG_LEVEL="info"

こうしておくと、同じビルド成果物のまま dev / staging / prod を切り替えられます。

「分離できているか」の判定法

判定はシンプルです。「いまこのソースを丸ごと公開しても、秘密が漏れないか？」。漏れるなら設定がコードに混ざっています。設定は環境変数や外部のシークレットストアへ追い出しましょう。

ビルド・リリース・実行の分離（Factor 5）

デプロイを 3つの段階に厳密に分ける のも要点です。

段階	何をするか	可変性
ビルド (Build)	コードを依存ごと実行可能な成果物へ変換	コードのバージョンで決まる
リリース (Release)	ビルド成果物＋その環境の設定を結合	一意のリリース ID を付ける
実行 (Run)	リリースをプロセスとして起動	起動するだけ・変更しない

ポイントは 実行段階でコードや設定を書き換えない こと。各リリースに一意の ID を振れば、問題時に「1つ前のリリースに戻す」だけでロールバックできます。これは CI/CD（/devops/ci-cd/）の考え方そのものです。

ステートレスとログ（Factor 6・11）

ステートレス（Factor 6） とは、プロセスが 自分の中に状態を貯めない こと。セッションやアップロードファイルをプロセスのメモリやローカルディスクに置くと、そのプロセスが落ちたり、別インスタンスに振り分けられたりした瞬間に壊れます。状態は DB やキャッシュ、オブジェクトストレージなど 外部のバックエンドサービス に預けます。

これができていると、プロセスを増やすだけで水平スケール でき、いつ落としても作り直せます（廃棄容易性）。

ログ（Factor 11） は、アプリ側でファイルに書いたりローテーションしたりせず、標準出力にイベントを流すだけ にします。集約・保存・検索は実行環境（コンテナ基盤やログ基盤）に任せる、という分業です。

ローカルディスクは「消えてもよい一時領域」と考える

コンテナや使い捨てインスタンスでは、ローカルに書いたファイルは再起動で消えます。アップロード画像をローカル保存して配信、のような設計は破綻しがち。永続化が要るものは最初から外部ストレージへ。

現代との関係

Twelve-Factor は10年以上前の指針ですが、いま読むと 「コンテナで動かすための前提条件」 に見えます。設定を環境変数で渡し、ステートレスで、ログを標準出力に流すアプリは、そのまま Kubernetes 等に載せやすいからです。

一方で、当時は想定が薄かった領域（オブザーバビリティの徹底、サービス間通信の制御、ビルドの再現性など）を補う「15-Factor」的な拡張も提唱されています。12項目を土台にしつつ、足りない観点を足す のが現実的な使い方です。

まとめ

Twelve-Factor は クラウドで動かしやすいアプリの設計作法 をまとめた12原則。
実務の要は 設定は環境変数へ／プロセスはステートレス／ログは標準出力へ。
ビルド・リリース・実行を分離 すれば、環境差の吸収とロールバックが楽になる。
コンテナ・CI/CD と素直に噛み合うため、クラウドネイティブの共通言語 として今も有効。