# トランクベース開発とは | ブランチ戦略とDORAメトリクス URL: https://codebasechat.com/ja/journal/trunk-based-development Type: blog Locale: ja Published: 2026-09-22 Updated: 2026-09-22 --- > トランクベース開発（Trunk-Based Development）は、すべての開発者が毎日メインブランチにマージするブランチ戦略です。長命フィーチャーブランチを排除し、継続的統合を実現します。 ## トランクベース開発とは トランクベース開発（Trunk-Based Development, TBD）とは、すべての開発者が単一の共有ブランチ（通常は`main`または`trunk`と呼ばれる）に1日に少なくとも1回マージするブランチ戦略です。長命のフィーチャーブランチは存在しません。コードは常にプロダクション対応の状態で保たれます。機能がまだ準備完了していない場合、フィーチャーフラグがそれをユーザーから隠します。ブランチで機能をチームから隔離するわけではありません。 それが短版です。長版では、現在のワークフローが想定以上のリスクを生み出している理由が明らかになります。 ## 長命ブランチがリスクになる理由 ほとんどのチームは、フィーチャーブランチを通じてバージョン管理を学びます。チケットあたり1ブランチ、レビュー後にマージです。整理されているように見えます。 ブランチが24時間以上存在すると、同僚がメインブランチに行ったすべてのコミットは、あなたがまだ見たことのない将来の競合です。8人のエンジニアがそれぞれ2週間のブランチを保持しているチームでは、1つの統合を実行しているわけではありません。毎日さらに分岐する8つの平行した世界を管理しているのです。マージデーは作業ではなく、交渉になります。 DORAリサーチ（数千のチームを対象とした最大規模のソフトウェア配信パフォーマンスの縦断研究）は、ここで厳しい線を引いています。24時間以上存在するブランチは、配信頻度の低下とチェンジの失敗率上昇の予測信号です。エリートレベルのパフォーマンスを示すチームは1日に複数回統合します。それ以外のチームは機能が「完了」したときにマージします。しかし、それが決してクリーンに起こることはありません。 隠れたコストは、マージ競合そのものではありません。それは3週間前に書かれたコードを解決するために必要なコンテキストスイッチングです。誰も意図が何だったかを覚えていません。 ## トランクベース開発の実装 仕組みはシンプルです。メインをプルします。小さくて一貫した変更を加えます。テストスイートを実行します。メインにプッシュします。すべてがランチ前に完了します。 小規模なリポジトリのソロコントリビューターの場合、これはすでにこのように機能しています。300K LOCのモノリポで20人のチームの場合、3つの慣行が一緒に機能する必要があります。 **短命ブランチ（通常だが必須ではない）**：一部のチームは、マージを強制する前に最大2日間のブランチを許可します。これは多週間の分岐を作成することなく、コードレビュー文化を保持します。ブランチはレビュー手段であり、隔離メカニズムではありません。 **すべてのプッシュで継続的統合**：メインへのすべてのコミットは、完全なビルドとテストスイートをトリガーします。壊れたら、2週間のフィーチャーブランチが金曜日の午後4時に到着した後ではなく、数分で壊れます。 **不完全な作業のフィーチャーフラグ**：未完成の機能をフラグの背後のプロダクションに配信します。ユーザーには何も表示されません。チームは一切を統合します。これはほとんどのチームがスキップする部分であり、最初のTBD実験が失敗する理由です。 これらの慣行は、トランクベース開発の専有ではありません。違いは、TBDがこれらすべての3つを必須ではなく、オプションではなく必須にすることです。 ## フィーチャーフラグ：TBDを機能させるメカニズム ![開発者がラップトップキーボードの両手でフィーチャーフラグダッシュボードが画面に表示されている状態](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/283060-inline1.webp) フィーチャーフラグは、実行時に評価される条件をコード内に含めることです。フラグがオフの場合、新しいコードパスは実行されません。オンになった場合、特定のユーザー、トラフィックの割合、または全体のユーザーベースに対して、そうなります。 これは些細に聞こえます。含意は異なります。デプロイメントをリリースから分離できます。コードは継続的にプロダクションに配信されます。機能は準備完了時にローンチするか、ロールアウトが悪く、3週間のコミットをロールバックするのではなく10秒で削除する必要がある場合はまったくローンチしないかです。 最小限の実行可能セットアップには3つが必要です。フラグを定義する方法、実行時に評価する方法、再デプロイなしで変更する方法です。フラットなJSONコンフィグファイルは、3人のチームで機能します。専用フィーチャー管理サービスは、10人のエンジニアの周辺、またはフラグが「ベータコホートのドイツのユーザーに対して有効」というようなターゲティングルールを必要とし始めるまで、その複雑さに値します。 追跡するべきこと：フラグ負債です。機能の配信後にクリーンアップされたことのないフラグは、条件付きスパゲッティになります。TBDを正しく実行するチームは、機能が完全にロールアウトされた後の1スプリント以内に各フラグをリタイアします。フラグを一時的なスカフォールディング、永続的な構成ではなく扱います。 ## TBDとGitflow：2026年の直接比較 Gitflowは2010年にボックス化されたソフトウェアのために設計され、四半期ごとのサイクルで配信されました。それはリリースを長命ブランチとしてモデル化します。毎日または毎時間配信するチームの場合、そのモデルはもはやマップされません。 CI/CDを実行するチームの比較は次のようになります。 **ブランチライフタイム**：Gitflowは日から週です。TBDは時間から最大1～2日です。 **マージ競合**：Gitflowは頻繁で高リスクの競合を生成します。TBDは統合ギャップが週ではなく時間であるため、稀で低リスクの競合を生成します。 **配信頻度**：Gitflowは配信をリリースブランチに関連付けます。TBDは配信と完全にリリースを分離します。 **ロールバック機構**：Gitflowはブランチマージをリバートしてロールバックします。TBDはフィーチャーフラグをオフにしてロールバックします。 **オンボーディングの複雑さ**：Gitflowはdevelop/main/hotfixコンベンション理解が必要です。TBDは1ブランチだけです。メインです。 **必須のCI投資**：Gitflowは低くなっています（ブランチがリスクを吸収）。TBDは高くなっています（メインは常にグリーンである必要があります）。 Gitflowはあらゆるコンテキストで間違っているわけではありません。アプリストアにモバイルアプリを配信し、数分でホットフィックスをプッシュできない場合、リリースブランチモデルは意味があります。配信を制御できるSaaSを実行する場合、追加のブランチ構造は、安全性を追加せずに調整コストを追加するオーバーヘッドです。 ## DORAメトリクスがブランチ戦略について述べていること ![ペアでプログラミングし、共有画面でコードレビューを行っている2人のエンジニア](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/7ec1d3-inline2.webp) [DORA State of DevOps研究](https://dora.dev/research/)は2014年以来ソフトウェア配信パフォーマンスを追跡しています。ここで直接関連する2つの知見があります。 まず、トランクベース開発は、DORAモデルでソフトウェア配信パフォーマンスを予測する24の能力の1つです。「継続的配信」クラスタの下にあります。つまり、DORAはそれをチーム設定ではなくインフラストラクチャプラクティスとして扱っています。 次に、エリートレベルのパフォーマンスを示すチームは1日に複数回配信します。低いパフォーマンスは週に1回または月に1回配信します。長命ブランチと稀な統合は、複数年のデータ全体で分布の遅い側に現れます。 研究は何を主張していないか：TBDが、エリートパフォーマンスを引き起こすこと。TBDを成功裏に採用したチームは、すでに自動化されたテスト、機能するCIパイプライン、および小さなコミットの習慣を持っています。トランクベース開発は、これらが不足している場合、その隙間をすぐに表面化させます。CIがなく、テストフレーク率が40%のチームはTBDから利益を得られません。彼らは単により頻繁にメインを壊すでしょう。 ## トランクベース開発が理に適わなくなるシナリオ TBDがそれが解決するよりも多くの問題を作成する3つのシナリオ。 **リリース前の承認ゲートが必須の高度に規制された環境**：すべてのリリースが配信前にコンプライアンスサインオフを必要とする場合、プロダクションへの継続的配信は管理されません。ブランチモデルは2次的になります。ブランチ戦略に関わらず、変更をバッチ処理します。 **弱いテストスイート**：TBDは高速で信頼性の高いCIパイプラインを必要とします。ビルドが45分かかり、20%のフレークがある場合、開発者は待機を回避するためにコミットをバッチ処理します。それはモデルを破綻させます。制約はブランチコンベンションではなく、テストインフラストラクチャです。 **一貫性のないコード所有権を持つ非常に大きなチーム**：50人以上のチームで各スクワッドが別個のサービスを所有している場合、TBDはサービスレベルで機能します。それを共有モノリポ全体に適用するには、メインをクリーンに保つために厳密なリント規則とCI所有権の規則が必要です。 これら3つのケースで、修正はブランチ戦略ではありません。修正は基盤インフラストラクチャの問題です。TBDはその問題をより速く表面化させます。 ## 配信を中断せずにマイグレーションする方法 ほとんどのチームが間違うマイグレーション：TBDを発表し、フィーチャーブランチコンベンションを削除し、最初の週にメインが壊れるのを観察します。 より安全な経路： - **既存のブランチを保持し、ライフタイムルールを追加**：ブランチは3日以上存在できません。これは古い照明をオフにすることなく、頻繁な統合の圧力を強制します。 - **最初にCIをインストルメント化**：マージが速い前に、マージは安全である必要があります。テストスイートが緑、15分以下で実行、失敗時にメインブランチをブロックすることを確認します。 - **フラグで1つの機能をゲート**：未完成の機能のすべてに必要になる前に、フラグ管理の筋肉を構築します。 - **週ごとにブランチライフタイムを短縮**：3日から2日から1日に6週間で。マージ競合の頻度を主要指標として追跡します。それが減るとき、モデルが機能しています。 - **新しい慣行が機能するときだけ古い慣行をリタイア**：Gitflowコンベンションはパイロット外のすべてのものに対して有効なままです。6～8週間で両方のモデルを実行することは問題ありません。 ## TBDが定着するかどうかを予測する1つの習慣 ![エンジニアがグリーンデプロイメント状態指標でCI/CDパイプラインダッシュボードを監視している状態](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/0e3fc0-inline3.webp) トランクベース開発は、チームがメインにマージできないため失敗しません。それは開発者が1日で配信するのに十分な小ささで機能の範囲を決めるのに十分な習慣がないために失敗します。 根本的なシフトは技術的ではありません。それは計画でどのように機能が定義されるかです。「新しい支払いフローを実装する」と言うストーリーは、2週間のブランチが待っています。「ルートハンドラーを追加し、フラグ`payment-v2`の後ろで501を返す」と言うストーリーは、半日のコミットです。 これにはPMの関与とほとんどのチームが構築していないバックログの衛生が必要です。ブランチ戦略の変更は1日で発表されます。スコーピング規律は構築に6か月かかります。 チームがすでに毎日プロダクションに機能するソフトウェアを配信している場合、TBDはあなたがすでにしていることを形式化します。チームが2週間ごとに配信し、終了時に大量のマージがある場合、TBDはそれが下にある配信習慣が変わるまで快適ではありません。 TBDを保持するチームは、切り替える前に3つのことに投資した団体です：15分未満のサブCIパイプライン、機能するフィーチャー管理サービス、1日でストーリーをクローズするのに十分な小さなストーリーを生成するスプリント儀式です。これら3つがない場合、ブランチコンベンションは間違ったレバーです。 ## TBDワークフローをサポートするツール チームレベルでトランクベース開発を実行することは、より多くの同期的な調整を意味します。統合のドリフトをキャッチするためのクイックスタンドアップ、フラグとCIルールのドキュメント化されたコンベンション、重要な経路でのペアレビューの呼び出し。 ## よくある質問 Q: トランクベース開発とGitflowの主な違いは何ですか？ A: Gitflowは数日から数週間のブランチを想定し、リリースサイクルが長いプロジェクト向けです。トランクベース開発は毎日のマージを前提とし、継続的配信を実現します。 Q: フィーチャーフラグなしでトランクベース開発を実装できますか？ A: 可能ですが、未完成の機能がユーザーに見える問題が発生します。フィーチャーフラグは、開発中の機能をプロダクションに配信しつつ、ユーザーには隠すメカニズムです。 Q: トランクベース開発はどのような規模のチームに適していますか？ A: 5人から50人のチームに特に効果的です。非常に大規模なチーム（50人以上）の場合、各スクワッドのサービスレベルで導入するか、コード所有権を明確にする必要があります。 Q: トランクベース開発への移行期間はどのくらい必要ですか？ A: 通常6～8週間が目安です。既存のGitflowコンベンションを保持しながら、段階的にブランチライフタイムを短縮（3日→2日→1日）することで、リスクを最小化できます。 Q: DORAメトリクスが示すトランクベース開発の効果は何ですか？ A: DORAリサーチでは、トランクベース開発を採用するチームは配信頻度が高く、チェンジの失敗率が低いことが示されています。これはエリートレベルのパフォーマンスの予測指標の1つです。 Q: CI/CDパイプラインが遅い場合、トランクベース開発は機能しますか？ A: 機能しません。CI/CDパイプラインは15分以内に完了する必要があります。45分かかる場合、開発者はコミットをバッチ処理し、モデルが破綻します。 Q: フラグ負債とは何ですか？ A: 本番環境にリリースされたが、クリーンアップされていないフィーチャーフラグが蓄積した状態です。各フラグはロールアウト完了後1スプリント以内に削除すべき一時的なツールです。 ## FAQ ### トランクベース開発とGitflowの主な違いは何ですか？ Gitflowは数日から数週間のブランチを想定し、リリースサイクルが長いプロジェクト向けです。トランクベース開発は毎日のマージを前提とし、継続的配信を実現します。 ### フィーチャーフラグなしでトランクベース開発を実装できますか？ 可能ですが、未完成の機能がユーザーに見える問題が発生します。フィーチャーフラグは、開発中の機能をプロダクションに配信しつつ、ユーザーには隠すメカニズムです。 ### トランクベース開発はどのような規模のチームに適していますか？ 5人から50人のチームに特に効果的です。非常に大規模なチーム（50人以上）の場合、各スクワッドのサービスレベルで導入するか、コード所有権を明確にする必要があります。 ### トランクベース開発への移行期間はどのくらい必要ですか？ 通常6～8週間が目安です。既存のGitflowコンベンションを保持しながら、段階的にブランチライフタイムを短縮（3日→2日→1日）することで、リスクを最小化できます。 ### DORAメトリクスが示すトランクベース開発の効果は何ですか？ DORAリサーチでは、トランクベース開発を採用するチームは配信頻度が高く、チェンジの失敗率が低いことが示されています。これはエリートレベルのパフォーマンスの予測指標の1つです。 ### CI/CDパイプラインが遅い場合、トランクベース開発は機能しますか？ 機能しません。CI/CDパイプラインは15分以内に完了する必要があります。45分かかる場合、開発者はコミットをバッチ処理し、モデルが破綻します。 ### フラグ負債とは何ですか？ 本番環境にリリースされたが、クリーンアップされていないフィーチャーフラグが蓄積した状態です。各フラグはロールアウト完了後1スプリント以内に削除すべき一時的なツールです。