テストピラミッドとは？各層の役割と理想的な比率の決め方
テストピラミッドとは？各層の役割と理想的な比率の決め方
自動テストを効率よく運用するには、「単体テストを土台に厚く持ち、結合テスト、E2Eテストと上に行くほど件数を絞る」というテストピラミッドの考え方に沿って配分することが基本です。
UIやE2Eテストだけに頼った運用を続けると、テスト実行に何時間もかかったり、原因不明のエラーが頻発してメンテナンスしきれなくなったりと、テスト自動化そのものが破綻してしまいます。
本記事では、テストピラミッドの基本概念や各層（単体・結合・E2E）の役割、よくある失敗パターン、現場で実践できる理想的な比率の決め方を分かりやすく解説します。
テスト自動化ツール「T-DASH」について概要を知りたい方には、無料ダウンロード資料をご用意しております。
▶ テスト自動化ツール「T-DASH」サービス紹介資料をダウンロードする
テストピラミッドとは？
テストピラミッドは、粒度の違う自動テストをそれぞれ何件ずつ持つかという配分だけを示した図です。図の幅はテストケースの件数を表すもので、下の層が上の層より優れているという序列ではありません。Mike Cohnが2009年の『Succeeding with Agile』で示し、Martin Fowlerがブログで取り上げたことで広く知られるようになりました。
3つの層それぞれの守備範囲から確認していきましょう。
1. 最下段：単体テスト（Unit Test）
単体テストは、関数やメソッドといった最小単位を対象に、内部ロジックが正しく動くかを確かめるテストです。
実行速度が非常に速く結果も安定しているため、開発中に何度でも手軽に実行できます。また、失敗した際に「どの関数のどの条件分岐が壊れたのか」が即座に特定できる点も大きなメリットです。ただし、単体テストがすべて通っても、プログラム同士のつなぎ目や外部サービスとの通信が正しいことは保証できません。
2. 中段：結合テスト（Integration Test）
結合テストは、複数のモジュールを組み合わせた状態や、データベース・外部APIと接続した状態で動作を検証するテストです。単体テストでは届かない「システムのつなぎ目」の不具合を検出する役割を担います。
この層は、3つの中で最も定義が揺れやすいという特徴があります。テスト用の簡易的なインメモリDBを使う場合もあれば、本番に近い本格的な環境を用意する場合もあり、現場によって「どこまでを結合テストと呼ぶか」の解釈が分かれがちです。
呼び方も揺れており、JSTQBのシラバスでは同じ層を「統合テスト」と呼びます。本記事では現場で使われることの多い「結合テスト」に表記を統一します。
3. 最上段：E2Eテスト（End-to-End Test）
E2Eテストは、ユーザーが画面を操作するのと同じ経路で、システム全体を通して動作を検証するテストです。例えば「ログインして商品を検索し、カートに入れて決済する」といった一連のユーザーシナリオをそのまま再現します。
本番環境の挙動に最も近い安心感を得られる一方で、実行時間が長く、ネットワークの遅延やUIの細かな変更によってテスト結果がブレやすいという代償があります。さらに、テストが落ちた際に「どのモジュールが原因なのか」を特定しにくいため、保守コストが最も高くなる点に注意が必要です。
なぜテストピラミッドは下ほど厚い？比率の根拠と70:20:10の読み方
下層のテストを多く持つべき理由は、シンプルに「上の層ほど実行が遅く、結果が不安定になりやすいから」です。よく目にする「70:20:10」という比率も、どこかの研究で導かれた絶対的な最適値ではなく、現場の経験則として語られている目安にすぎません。
上に行くほど何が上がり、何が下がるのか
テストは上段（E2E）に近づくほど、本番に近い挙動を確かめられるメリットを得る代わりに、実行速度と結果の安定性（再現性）を手放すことになります。
1件のE2Eテストに30秒かかり、10回に1回エラーが起きる程度であれば許容できるかもしれません。しかし、件数が増えるにつれてその負担は膨れ上がります。もし30秒かかるテストが200件あれば実行に100分以上かかり、少しでも不安定なテストが混ざっていれば、CI（継続的インテグレーション）を回すたびにどこかで失敗してしまいます。
こうなると、開発者はテスト失敗を見ても「またいつもの誤検知だろう」と再実行ボタンを押すだけになり、テストの信頼性が失われてしまいます。上段のテストを絞り、下段を厚くするのは、この悪循環を防ぐためです。
70:20:10と80:15:5という目安の位置づけ
一般的に語られる比率の目安として、以下のような配分がよく挙げられます。
| 想定規模 | 下段（単体） | 中段（結合） | 上段（E2E） |
| 小〜中規模のシステム | 70% | 20% | 10% |
| 大規模なシステム | 80% | 15% | 5% |
システム規模が大きくなるほど上段の比率を減らすのは、規模に比例してE2Eテストの実行時間と不安定さの影響が大きくなるためです。
ただし、この数字を厳密な目標値にする必要はありません。形だけ整えようとして、実際にはDB接続を伴う重いテストを「単体テスト」と名前だけ付け替えても、実行速度や不安定さは改善しないからです。大切なのは比率の再現ではなく、「テストが通れば安心してリリースでき、落ちたときは原因がすぐ分かる」という状態を作ることです。
テストピラミッドのアンチパターンとは？崩れた4つの形
テストの配分が崩れてしまうのには、現場ごとの理由があります。ここでは、よくある4つの失敗パターンについて、その原因とリスクを確認しておきましょう。
1. アイスクリームコーン（逆ピラミッド）
E2EテストやUIテストが最も多く、単体テストがほとんどない状態です。既存の手順書をベースに、手動テストをそのまま自動化していくと自然とこの形に陥ります。
運用が始まると、テストが落ちても原因特定に時間がかかるため「落ちたら再実行」が常態化し、最終的には放置されて自動化の投資が無駄になってしまいます。
2. 砂時計
単体テストとE2Eテストは十分にあるのに、中段の結合テストだけが極端に少ない状態です。
結合テストに必要な環境準備やデータ作成の手間を避けた結果として起こります。モジュール間のつなぎ目の不具合を検出できず、E2Eテストで初めてエラーが出るため、障害の切り分けに最も時間がかかるパターンです。
3. カップケーキ
すべての層が同じくらい厚く、さらに手動テストまで重なっている状態です。
カバレッジ100%を目指すあまり、同じロジックを単体・結合・E2Eの各層で重複してテストしてしまうことで発生します。開発チームとQAチームでテスト範囲の合意がない場合にも起きやすく、守れる範囲は変わらないのに保守コストだけが跳ね上がってしまいます。
4. アンブレラ
自動化の取り組みがUIテストだけに偏り、単体・結合テストがほぼ存在しない状態です。
短期間で目に見える成果を出しやすいため初期は重宝されますが、土台となる単体テストがないため、画面の仕様変更があるたびにテストが一斉に壊れ、修正が追いつかなくなって破綻します。
テストピラミッドはどう実現する？
テストピラミッドを整える作業は、いきなり上段のテストを削除することから始めるべきではありません。
最初に行うべきは、「単体テストか結合テストか」という人によって解釈が分かれがちな分類基準を、誰が見ても客観的に判断できる基準へと改めることです。
段の分け方を「テストサイズ」に置き換える
同じテストを見ても、開発者によって「単体テスト」と呼んだり「DBに触れているから結合テスト」と呼んだりすることがあります。これでは分母と分子の基準が揃わず、比率の議論すら成り立ちません。
そこで有効なのが、Googleが提唱する「テストサイズ」という考え方です。これはテストの目的ではなく、「実行時に何に依存しているか」という事実だけで客観的に分類する手法です。
| サイズ | プロセス・スレッド | ネットワーク | データベース・ファイルシステム | 実行時間の想定 |
| Small | 単一プロセス・スレッドなし | 不可 | 不可（インメモリの代替のみ） | ミリ秒〜秒 |
| Medium | 複数プロセス・スレッド利用可 | localhost宛てのみ可 | ローカルのDB・ファイルは可 | 数秒〜数分 |
| Large | 制約なし（複数マシン可） | 外部ネットワーク可 | 制約なし | 数分〜 |
参考：Google「Software Engineering at Google（第11章 Testing Overview）」2020年）。
この基準を使えば、「localhost以外に通信しているか」「別プロセスを起動するか」というコード上の事実だけで分類できるため、主観によるブレがなくなります。
日常の会話では「単体・結合・E2E」と呼びつつ、比率を測る際は最下段をSmall、中段をMedium、最上段をLargeとして集計することで、初めて健全な改善議論が可能になります。
上段のテストを下段へ移す2つの方向性
基準が揃ったら、上段（Large）に偏っているテストを下段へ移行していきます。移行のアプローチは、対象とする層によって異なります。
上段から中段へ：テストダブルで外部依存を切る
LargeをMediumに落とすには、外部システムとの通信を遮断することが中心になります。決済代行や外部APIへの通信をスタブやフェイク（テスト用の代用品）に置き換え、localhost内で完結させます。これだけで実行速度が大幅に向上し、外部サービスの不調によるテスト失敗を防ぐことができます。
中段から下段へ：ロジックを切り出す設計変更
MediumをSmallに落とす際は、検証したいビジネスロジックをデータベースや外部I/Oから切り離す設計変更が効果的です。例えば、料金計算のロジックがSQL発行と同じメソッドに混ざっていると、テストに必ずDB接続が必要になります。計算処理を独立した関数として切り出せば、DBなしでさまざまな条件分岐や境界値を高速にテストできるようになります。
上段に残すテストの絞り込み方
上段に残すテストは、「主要な業務シナリオが通しで成立することを確認する最小限のハッピーパス」と、「画面遷移やセッション維持など、下段では原理的に確認できない要素」だけに絞り込みます。ECサイトであれば「検索から決済完了までの主要動線」だけを上段に残し、クーポンの複雑な適用条件や細かなエラー表示の確認は下段へ移行するのが理想です。
残った上段テストを壊れにくく保つには？
どれだけ下段へ移行しても、上段のテストをゼロにはできません。そのため、「上段のテストは壊れやすいもの」という前提でメンテナンスの仕組みを作ることが重要です。
Googleの調査によると、同社のテスト実行のうち約1.5%が「コード変更がないのに合否がブレる不安定なテスト（Flaky Test）」になっていると報告されています（出典：Google Testing Blog「Flaky Tests at Google and How We Mitigate Them」2016年）。高度な体制を持つ組織でもゼロにするのは難しいため、不安定なテストを見つけたときの対処ルール（書き直す、下段へ移す、価値が見合わなければ捨てる）を事前に決めておく必要があります。
また、上段のUIテストが放置される大きな原因に「スクリプトの属人化」があります。作成した担当者以外にコードが読めないと、仕様変更のたびにテストが壊れて放置されてしまいます。
この課題を解決する選択肢として、T-DASHのように日本語でテスト手順を記述・自動実行できるツールの導入が有効です。専門的なコードを書かずにテスト手順が可視化されるため、チーム全体でメンテナンスを継続しやすくなります。
テストピラミッドとテスティングトロフィーの違い
テストの配分モデルには、ピラミッドのほかに「テスティングトロフィー」という考え方もあります。自社にどちらが合うかを考える際は、それぞれの特徴と自社のアーキテクチャを照らし合わせることが大切です。
テスティングトロフィーが結合テストを厚くする理由
テスティングトロフィーは、Kent C. Dodds氏が提唱したフロントエンド（特にReactなどのコンポーネント開発）向けのモデルです。単体テストよりも、複数のコンポーネントを組み合わせて検証する結合テストを最も厚く配置する点に特徴があります。
「テストは実際の使われ方に近いほど、ソフトウェアへの確信度が高まる」という思想に基づいており、単体関数を細かくテストするよりも、複数のUIコンポーネントを組み合わせて実際の操作に近い形で検証する層を重視します。
| 観点 | テストピラミッド | テスティングトロフィー |
| 最も厚くする層 | 最下段の単体テスト | 結合テスト（コンポーネント単位） |
| 重視する性質 | 実行速度と決定性、失敗時の原因特定 | 実際の使われ方への近さ（忠実性） |
| 想定する利用者 | 開発者とQAの双方 | 主にコンポーネントを書く開発者 |
| 想定する開発文脈 | サーバサイドを含むシステム全般 | コンポーネント指向のフロントエンド開発 |
一見対立するように見えますが、トロフィーが推奨する結合テストは、DOMをインメモリで動かし外部通信をモックする「テストサイズで言えばSmall〜Medium」のテストです。ピラミッドが警戒している「重くて不安定なLargeテスト」を避けている点では、本質的に同じ方向を向いています。
アーキテクチャによって最適な形は変わる
プロダクト全体で単一のモデルに縛られる必要はありません。システムの領域やアーキテクチャに応じて柔軟に使い分けるのが実務的です。
| アーキテクチャ特性 | 厚くしたい層 | 有効なテスト種別 | 注意点 |
| フロントエンド | 中段寄り | コンポーネント結合テスト、DOMをインメモリで扱うテスト | 単体に細かく分割しすぎると実際の描画挙動から離れやすい |
| バックエンド | 下段中心 | ドメインロジックの単体テスト、DBを含む結合テスト | 永続化層とビジネスロジックを分離しておく必要がある |
| マイクロサービス | 中段を厚めに | APIテスト、サービス間の契約テスト | サービスをまたぐE2Eは環境準備が重く不安定になりやすい |
| モノリス | 標準的なピラミッド | 単体テスト、モジュール間の結合テスト | 境界が曖昧なまま結合テストを増やすと重複しやすい |
例えば、画面側はコンポーネントを結合したテストを中心に据え、サーバー側はビジネスロジックの単体テストを土台にする、といったハイブリッドな運用が現実的です。
AI生成コードが増えると比率は変わるのか
近年、生成AIによるコード生成が普及したことで、テストの比率に対する議論も生まれています。
AIによってコードの記述や変更が頻繁に行われるようになると、実装の細部に依存した単体テストは壊れやすくなり、外部からの振る舞いを保証する上段テストの相対的な価値が上がるという見方もあります。
ただし、これも現時点での一つの仮説にすぎません。大切なのは流行に流されることではなく、テストサイズのような客観的な基準で自チームのテスト状況をいつでも見直し・再配置できるようにしておくことです。
テストピラミッドとは？まとめ
テストピラミッドの目的は、70:20:10という数字や三角形の見た目を綺麗に整えることではありません。「テストが通れば安心してリリースでき、失敗すればすぐに原因を修正できる」という開発スピードと品質の両立を維持することです。
まずは自社のテストコードが「Small・Medium・Large」のどこに位置しているかを棚卸しすることから始めてみてください。外部ネットワークやDBへの依存度を確認するだけで、上段に溜まった重いテストの正体と改善の道筋が明確になります。
また、どうしても残る上段のE2Eテストについては、属人化を防ぎ誰でもメンテナンスできる環境を整えることが継続運用の鍵となります。
バルテスのテスト自動化ツール「T-DASH」は、日本語で書いたテストケースをそのまま自動実行できるため、テストコードの属人化を防ぎ、保守コストを大幅に抑えることが可能です。月額換算 4,950円（税込・年額プラン）から手軽に導入できるため、上段テストのメンテナンスにお困りの方は、ぜひ無料トライアルや相談窓口をご活用ください。
テスト自動化ツール「T-DASH」について概要を知りたい方には、無料ダウンロード資料をご用意しております。
▶ テスト自動化ツール「T-DASH」サービス紹介資料をダウンロードする
