ハクソク

世界を動かす技術を、日本語で。

12ファクターアプリ (2025)

2026年8月28日原文(12factor.net)

概要

  • Twelve-Factor App は現代の SaaS開発 のための手法
  • 宣言的設定 や 環境依存性の分離 などが特徴
  • クラウド対応 や 継続的デプロイ を容易にする設計思想
  • 言語やサービスに依存しない 汎用的なガイドライン
  • Heroku の経験を基にした ベストプラクティス の集大成

Twelve-Factor Appとは

  • 現代の Webアプリケーション や SaaS 向け開発手法
  • 新規開発者の参加コスト最小化 を目的とした 宣言的フォーマット の利用
  • OSとの契約の明確化 により、 実行環境間の移植性 を最大化
  • クラウドプラットフォーム へのデプロイ適性の確保
  • サーバー管理不要 かつ システム管理の省力化 を実現
  • 開発環境と本番環境の差異最小化 による 継続的デリバリー の推進
  • ツールやアーキテクチャの大幅な変更なし でのスケーラビリティ確保
  • 言語やバックエンドサービス （データベース、キュー、メモリキャッシュ等）に依存しない適用性

背景と目的

  • Heroku を通じて 数多くのアプリの開発・運用・スケーリング に携わった知見
  • ソフトウェアの有機的成長 や 開発者間コラボレーション に着目
  • ソフトウェアの劣化防止 を意識した設計
  • 現代アプリ開発の問題提起 と 共通語彙の提供
  • 問題解決のための広範な概念的アプローチ と 用語の提案
  • Martin Fowler の著書を参考にした構成

対象読者

  • サービスとして稼働するアプリケーション を開発する 全ての開発者
  • そのアプリケーションを デプロイ または 管理 する Opsエンジニア

Twelve-Factorの原則

  • I. コードベース ：1つのリビジョン管理されたコードベース、複数のデプロイ
  • II. 依存関係 ：依存関係を明示的に宣言・分離
  • III. 設定 ：設定情報は環境変数に保存
  • IV. バッキングサービス ：外部サービスはアタッチされたリソースとして扱う
  • V. ビルド・リリース・実行 ：ビルドと実行の段階を厳密に分離
  • VI. プロセス ：アプリは1つ以上のステートレスプロセスとして実行
  • VII. ポートバインディング ：サービスはポートバインディングで公開
  • VIII. 並行性 ：プロセスモデルによるスケールアウト
  • IX. 廃棄性 ：高速な起動と優雅なシャットダウンで堅牢性最大化
  • X. 開発/本番パリティ ：開発・ステージング・本番環境の差異を最小化
  • XI. ログ ：ログはイベントストリームとして扱う
  • XII. 管理プロセス ：管理タスクはワンオフプロセスとして実行

Hackerたちの意見

これが12層のMFAデモになると思ってたんだけど、今の痛くて持続不可能なMFAトレンドの馬鹿らしさを示すものだと思ってたんだよね。

└

毎回、仕事を“やっとやるぞ”って思って他の部屋にスマホを置くと、あのクソみたいなSMSに送った番号を入力してくれって言われて、ノートパソコンを閉じちゃう。

└

ちょっと変に聞こえるかもしれないけど、今の僕の人生そのものなんだ… MFAが痛い/持続不可能だと感じる理由を教えてくれない？どうやって解決するつもり？

└

苦痛で持続不可能なMFAのトレンド。このウェブフォーラムは数年前にその方針の大きな支持者だったよね。

当時はHerokuが未来になると思ってたな。Azureの意味不明なことに悩まされるたびに、失ったシンプルな未来を夢見ちゃう。

└

ちゃんと評価しなきゃね… Laravel CloudはHerokuの後を引き継いだ感じがする。少なくともそうしようとしてるみたい。

└

すごく高くなって、結局買収されたんだよね。クライアントとのやり取りを思い出すし、最終的にはAWS ECSに全力投球した。まだ結構高いけど、クライアントはHerokuの請求書に比べてAmazonの請求書について文句を言わなくなった気がする。

└

Fly.ioは、あの簡単なデプロイの感覚を取り戻してくれるね。

└

まだ試してないならCloud Runを使ってみて！基本的にサーバーレスを正しく実現したものだよ。

まだまだめちゃくちゃ重要だよ。たとえ実践しなくても、これを15分で読むだけでも学べることがたくさんある。唯一の不満は第3章の「設定を環境に保存する」とか「Amazon S3やTwitterなどの外部サービスへの認証情報」って部分。これ、悪いアドバイスだし、開発者がローカル環境の秘密を~/.bashrcファイルに入れられると思わせる二次的な影響もあった。これ、やめて。残りの11.5の要素をやってみて。 [1]: https://12factor.net/config

└

これ、開発者がローカル環境の秘密を~/.bashrcファイルに入れられると思わせる二次的な影響もあった。 dotenvの使い方を教えてあげて。設定ファイルでの設定から離れてるのは、特にその設定の一部が秘密の場合、修正が面倒だからだよね。すべてを好みの秘密の保管庫に入れなきゃいけないし、編集には全体を取り出して再アップロードする必要がある。今は、Kubernetesのポッドごとに1つまたは複数の秘密を読み込むことで環境で設定を行ってる（ミックス＆マッチ）。あなたの提案は何？

└

12 Factorの暗黙の前提は「環境は安全である」ってこと。例えば、プロダクションシステムでは環境変数を設定するための安全な手段が常に必要なんだ。別の言い方をすると、ランダムな開発者がプロダクションで環境変数を直接ログインして変更したり、コードをプッシュして間接的に変更したりできるなら、何かが非常に間違ってる。開発者がプロダクションにコードをプッシュするなら、同時に環境設定もプッシュするべきじゃない。これは論理的に異なる二つのことを同時にやってることになるからね：アプリケーションの動作を変更することと、サーバー環境を再構成すること。もし開発者がローカル設定にシークレットを追加して、それを安全でない場所にプッシュしているなら、そのデプロイパイプラインは壊れているから修正すべきだよ。例えば、.envはこの理由でソースにコミットされることはないんだ。

Hacker Newsで議論の続きを見る