experimentation-platform-orchestrator

実験プラットフォームのオーケストレーション

実験プラットフォームの選定を適切に行い、誤った選定をしてしまった場合に立て直すための、シニアプロダクトリーダーおよびエンジニアリングリーダー向けの実践ガイドです。

実験プラットフォームの選定は、最初は簡単に見えても、その後何年にもわたって影響が積み重なる判断のひとつです。誤った選択は、チームが苦痛を伴うワークフローを避けることで実験の機会を失い、利用状況に合わない料金モデルによってコストが膨らみ、移行は設定変更ではなく実際のエンジニアリング作業であるためベンダーロックインが生じ、さらにプラットフォームのデフォルト設定がチームの実験に対する考え方を形作ることで、文化のずれを招きます。

このスキルは、最初の選定を適切に行うための判断力と、誤った選定をしてしまった場合の移行計画を身につけるためのものです。

このスキルを使う場面：一からプラットフォームを選定するとき、切り替えを検討するとき、複数のプラットフォームを単一のプラットフォームに統合するか決めるとき、または承認済みの移行を計画するときです。

---

このスキルの対象

このスキルでは、プラットフォームの選定、複数プラットフォームに関する判断、移行計画、ガバナンスの設定を扱います。実験設計（experiment-design を使用）、結果の解釈（experimentation-analytics を使用）、フィーチャーフラグの運用（feature-flagging を使用）は扱いません。プラットフォーム固有の MCP の詳細が必要な場合は、関連するインテグレーションのマイクロサイトと併用してください。

対象は、判断を下す、または過去の選定を立て直すプロダクトマネージャー、エンジニアリングリーダー、データリーダーです。明確に判断を示すのが基本姿勢です。「状況によるので、すべて自分で評価してください」という答えはありません。判断の選択肢には明確な構造があり、シニアアドバイザーなら、あなたの状況に基づいて妥当な答えを午後のうちに導き出せます。

---

プラットフォーム選定で考慮すべき7つのポイント

どのプラットフォームを評価する場合も、同じ7つの問いに向き合うことになります。まず率直に答えてから、プラットフォームごとの紹介を読み、最後に比較表を確認してください。この順序が重要です。データアーキテクチャと統計的厳密性が基盤となり、その他の要素はその上に積み重なります。

1. データアーキテクチャ。 実験データはどこに保存されますか？パターンは3つあります。ベンダーネイティブ（Statsig、Optimizely）では、データはベンダーのストレージに保存されます。プロダクトスイート型（PostHog、Amplitude）では、1つのイベントパイプラインの背後で分析と実験を統合します。データウェアハウスネイティブ型（GrowthBook、Eppo）では、既存のデータウェアハウス上で SQL を実行します。このパターンによって、セキュリティレビューの深さ、データの保管場所、統計分析の深さ、コストの構造が決まります。

2. 統計的厳密性。 そのプラットフォームは、CUPED、逐次検定、比率指標に対するデルタ法、多重検定補正を実装していますか？営業担当との通話で簡単に確認できます。「比率指標にはどの分散推定量を使っていますか？」「常に有効な p 値に対応していますか？」と尋ねてください。最新のプラットフォーム（Statsig、Eppo、PostHogの一部）にはこれらの機能があります。古いプラットフォームや自社開発のプラットフォームでは、対応していないことがよくあります。

3. MCP の利用可否。 ここで取り上げる7つのプラットフォームのうち、Eppoを除くすべてに、ファーストパーティまたはホスト型の MCP があります（2026年5月時点）。AI エージェントが実験の作成から読み取りまでをエンドツーエンドで行うエージェント型ワークフローでは、MCP の利用可否がより重要になります。人間が主導する従来型の実験では、それほど重要ではありません。チームが AI を積極的に活用している場合は、重視する価値があります。

4. フィーチャーフラグとの統合。 実験とフィーチャーフラグは同じプラットフォームで管理できますか？Statsig、Optimizely、GrowthBook、PostHogは、いずれも両者を統合しています。Eppoは実験のみを対象としています。Kameleoonはクリエイティブのパーソナライズに重点を置いています。本番環境のインフラとしてフィーチャーフラグ運用も必要な場合は、運用上の規律について feature-flagging を確認してください。プラットフォームは両方の用途に対応している必要があります。そうでなければ、2つ目のツールを使うことになります。

5. 分析機能の深さ。 実験結果と同じ画面で、ファネル、リテンション、コホートを確認できますか？PostHogとAmplitudeは、この点で最も優れています（分析を第一に設計されたプロダクトです）。Statsigには強力な分析機能が備わっています。OptimizelyとGrowthBookは実験を第一に設計されており、分析機能は補完的なものです。

6. ガバナンスと監査。 本番環境のターゲティングを変更できるのは誰ですか？実験を公開できるのは誰ですか？機密性の高い指標を閲覧できるのは誰ですか？エンタープライズ向けプラン（Optimizely、LaunchDarkly Federal）は、成熟した機能でこれらに対応します。オープンソースのプラットフォーム（GrowthBook、セルフホスト型のPostHog）では、ガバナンスを自社で構築する必要があります。規制の厳しい業界（医療、金融、公共部門）では、この問いが決め手になります。

7. コストの構造。 ベンダーネイティブ型はイベント数に応じて費用が増加します。データウェアハウスネイティブ型はユーザー数とデータウェアハウスのコンピューティング量に応じて増加します。プロダクトスイート型は、すべての機能で使用するイベントの総量に応じて増加します。料金体系を実際の使用状況に合わせて選んでください。トラフィックの多いスタートアップと、トラフィックの少ないエンタープライズでは、ベンダーネイティブ型の料金体系の影響は異なります。現在の1か月だけでなく、今後の成長に適した料金体系を選びましょう。

---

Statsig

最新の実験機能とフィーチャーマネジメントを1つのプラットフォームに統合しています。CUPEDと逐次検定を標準で搭載しています。PM主導の使いやすさに優れています。OpenAI、Notion、Brex、Figmaが利用しています。

強み。 最初の実験をすばやく開始できます。実験とフィーチャーフラグが統合されているため、2つ目のツールを使うコストがかかりません。統計的厳密性は最新の文献に沿っています。MCP では、実験、ゲート、動的設定、指標に対する完全な CRUD 操作が可能です。

注意点。 イベント数に応じて料金が増加するため、大規模になると高額になる可能性があります。このプラットフォームには実験の進め方について明確な方針があり、独自の統計ワークフローを望むチームは、デフォルト設定との調整に苦労するでしょう。セルフホストは主要な選択肢ではありません。

理想的な顧客。 フィーチャーフラグと実験を1つのプラットフォームで管理したい、急成長中の SaaS 企業。標準で備わる高度な統計機能を重視し、ベンダーネイティブなデータアーキテクチャを受け入れられる企業です。

---

PostHog

プロダクト分析、実験、機能フラグ、アンケート、セッションリプレイ、エラートラッキング、LLM 分析を組み合わせた、オープンソースのプロダクト OS です。無料プランも利用できます。

強み。 ファネル全体の状況を把握できます。実験が、その背景を理解するための分析機能と隣り合って提供されています。MCP は 200 以上のツールを公開しています（エージェントのコンテキストを絞るには、?features= のようなスコープ指定を活用してください）。セルフホストの選択肢も成熟しています。オープンソースライセンスにより、ベンダーロックインを避けられます。

注意点。 すべての機能でイベント数が合算されるため、規模が大きくなると料金に驚くことがあります。機能が幅広いため、オンボーディングが煩雑に感じられる場合があります。実験の統計的な深さは十分ですが、CUPED のデフォルト設定のような高度な機能では、専用の実験プラットフォーム（Statsig、Eppo）に一歩及びません。

最適な顧客。 分析、実験、機能フラグを一つの画面で利用したいプロダクト主導型の SaaS 企業、オープンソースの柔軟性を重視し、幅広い機能を使いこなせるチームです。

---

GrowthBook

オープンソースの、データウェアハウスネイティブな実験プラットフォームです。データはデータウェアハウス（Snowflake、BigQuery、Redshift、Postgres）に保持されます。セルフホストまたはクラウドで利用できます。

強み。 データ主権を確保できます。データウェアハウスの料金をすでに支払っているため、大規模運用でもコストを管理できます。発表によると、実験向けの本番環境用オープンソース MCP としては初です。ベイズ統計と頻度論の切り替えを含む、成熟した統計デフォルトを備えています。データウェアハウスの指標を持ち込めるため、実験の指標は定義上、分析の指標と一致します。

注意点。 ベンダーネイティブな製品よりもセットアップの負担が大きくなります。データウェアハウスのコンピューティングコストは自社で負担します（通常は欠点ではなくメリットですが、財務上は別の費目として計上されます）。コミュニティは Statsig や PostHog より小規模です。UI の洗練度は、ベンダーのプラットフォームに半歩及びません。

最適な顧客。 すでにデータウェアハウスを運用しているデータ成熟度の高いチーム、データの保管場所に関する要件がある規制対象業界、そして将来の乗り換えに備えてオープンソースを好むチームです。

---

Optimizely

長年にわたりエンタープライズ市場をリードしてきた製品です。Web Experimentation と Feature Experimentation を提供します。パーソナライズ機能と、技術者以外のユーザー向けのビジュアル編集に優れています。

強み。 エンタープライズ向けのガバナンス機能が成熟しています。ビジュアル編集により、エンジニアの支援なしでマーケターが実験を公開できます。カスタマーサクセス体制も充実しています。ホスト型のリモート MCP は、ブラウザベースの ChatGPT と Claude.ai で利用できます。

注意点。 高額です。料金設定はエンジニアリング部門ではなく、マーケティング部門の予算を想定しています。製品には数十年にわたって機能が蓄積されているため、使いこなすには時間がかかります。統計のデフォルト設定は保守的ですが、最新の分散削減手法を探す場ではありません。

最適な顧客。 マーケティング主導の組織、成熟した実験プログラムを持つエンタープライズ、そして技術者以外でも実験を作成できることが必須要件であるチームです。

---

Amplitude

実験と機能フラグを追加機能として備えた行動分析プラットフォームです。無料プランを含むすべての顧客が、ホスト型 MCP を利用できます。

強み。 チームがすでに分析に Amplitude を使っているなら、実験機能を追加するのが最も手軽な方法です。コホート分析と行動セグメンテーションに優れています。無料プランは月間 1,000 万イベントまでと、十分な内容です。

注意点。 実験は主役ではなく、追加機能です。統計的な深さは中程度です。実験がチームの主な専門分野であれば、Amplitude が適切な選択肢になることはほとんどありません。一方、実験が補助的な機能であり、分析が主役であれば適しています。

最適な顧客。 実験を中心的な機能ではなく、補助的な機能として必要とする、分析を最優先するチームです。分析と実験の両方を利用できる無料プランを求める、プロダクトマーケットフィット前のチームにも適しています。

---

Eppo

ウェアハウスネイティブで、統計的に厳密です。Twitch、DraftKings、Perplexityで採用されています。ベイズ統計と頻度論の切り替え、逐次検定、CUPEDなど、統計的に優れたデフォルト設定を備えています。

強み。 統計的な正確さが最大の特長です。チームの多くをデータサイエンティストと統計学者が占めており、デフォルト設定にもその専門性が表れています。ウェアハウスネイティブのアーキテクチャは、データ活用が進んだチームがすでに採用しているパターンに適合します。レポートは明快で、意思決定を重視しています。

注意点。 2026年5月時点で、ファーストパーティの MCP はありません。REST API のみです。AI エージェントによる実験の読み書きがワークフローに欠かせない場合、現時点では Eppo は選択肢として不足しています。今後の MCP リリースに注目してください。価格はエンタープライズ向けで、実用的な無料プランはありません。

理想的な顧客。 統計的な正確さが最優先で、ウェアハウスがすでに信頼できる唯一の情報源となっており、AI エージェントのワークフローは現在の要件ではなく、将来的な課題である、データチーム主導の組織です。

---

Kameleoon

実験で勝ったバリエーションを本番コードに反映するワークフローに特化したプラットフォームです。AI 駆動のパーソナライゼーションを提供します。mcp.kameleoon.com/mcp でホストされる MCP は、OAuth と7つの専用ツールを備えています。

強み。 マーケティングサイトでの実験で勝ったバリエーションを永続的な React コンポーネントに変換します。これは実際のワークフローであり、他のプラットフォームではチームが手動で対応する必要があります。コンテンツサイト向けの AI 駆動のパーソナライゼーションも提供します。MCP は、実験の勝ちパターンをコードに反映するプロセスに特化して構築されています。

注意点。 他のプラットフォームより対象範囲が狭いです。プロダクト実験において、Statsig や Optimizely の代替にはなりません。主要なプラットフォームとしてではなく、別のプラットフォームと併用されることがほとんどです。

理想的な顧客。 マーケティングサイトやコンテンツサイトで実験を実施し、勝ったバリエーションを永続的なコードにする必要があるチームです。ほとんどの場合、主要なプロダクト実験プラットフォームと併用します。

---

コンテキスト別のプラットフォーム選択マトリックス

マトリックスと具体的な例は、references/platform-decision-matrix.md にあります。概要は次のとおりです。

• 純粋な SaaS で急成長しており、フラグと実験を1つのプラットフォームにまとめたい場合は、Statsig を選びます。分析機能も必要なら、PostHog を選びます。
• オープンソースを重視し、データ主権とウェアハウスネイティブを求める場合は、GrowthBook または Eppo を選びます。
• エンタープライズで、マーケティング主導かつ高度なパーソナライゼーションを求める場合は、Optimizely を選びます。
• 分析に Amplitude をすでに深く活用している場合は、統計的な機能の深さがボトルネックになるまでは Amplitude を使い続けます。
• データチーム主導で統計的な正確さを最優先し、MCP がまだ必要でない場合は、Eppo を選びます。
• マーケティングサイトで勝ったバリエーションを本番コードに反映する必要がある場合は、主要なプラットフォームに Kameleoon を追加します。
• 規制の厳しい業界（HIPAA、FedRAMP）で、セルフホストが必須の場合は、セルフホスト版の GrowthBook を選びます。セルフホスト版の PostHog も有力な選択肢です。
• PMF 前のスタートアップで、トラフィックが少なく、無料プランが必要な場合は、PostHog または Statsig の無料プランを利用し、トラフィックに見合う費用の試算ができるまでは、本格的な選定を先送りします。
• 月間イベント数が1億件を超え、コスト管理が最優先の制約である場合は、GrowthBook または Eppo を選びます。この規模では、ウェアハウスネイティブの料金体系のほうが拡張性に優れています。
• AI を積極的に活用するチームで、MCP を最優先するワークフローの場合は、Statsig、PostHog、または Optimizely を選びます。Eppo は MCP がリリースされるまで保留します。

---

マルチプラットフォーム：妥当なケースと混乱を招くケース

マルチプラットフォームが妥当なのは、対象となる領域が実質的に異なり、プラットフォーム間で重複がない場合です。Kameleoon でマーケティングサイトをパーソナライズし、Statsig でプロダクトの実験を行うのは、対象領域、ユーザー層、指標セットが異なり、重複がないため、明確な使い分けです。ワークフローが衝突しないため、2つ目のツールにかかるコストも正当化できます。

対象領域が重複する場合、マルチプラットフォームは混乱を招きます。プロダクトの実験に Statsig と Optimizely の両方を使うと、コストの重複やデータの分散が生じ、「どちらが信頼できる唯一の情報源なのか」という問題が発生します。これは、経営陣の意見が対立して答えが必要になるという、最悪のタイミングで表面化します。

80/20の法則です。チームの80％は1つのプラットフォームを選び、統合すべきです。真に複数の領域（マーケティングサイト、プロダクトアプリ、コンテンツサイト）に対応する必要がある残りの20％は、明確な責任分担を設けることでマルチプラットフォームを正当化できます。

マルチプラットフォームが必要な場合、次の3つの調整パターンは必須です。オーナーシップマトリクスで、どのプラットフォームがどの領域を担当するかを明示します。共通の指標定義により、「アクティベーション率」が両方のプラットフォームで同じ方法で算出されるようにします（これは難しく、多くのマルチプラットフォーム構成がいつの間にか乖離する理由でもあります）。照合可能なダッシュボードにより、両方のプラットフォームで同じ定義の同じ指標を確認できます。詳細は references/multi-platform-orchestration.md を参照してください。

---

移行パターン

移行とは、プラットフォームの選定をやり直せるようにする、目立たないながらも重要なエンジニアリング作業です。よくあるパターンは5つです。

Statsig から PostHog へ。 純粋な実験の枠を超え、アナリティクスと実験を統合したい企業でよくあるパターンです。作業量：エンジニア3～5人週です。4～8週間並行稼働させ、両方のプラットフォームで実験結果が一致することを検証し、信頼性が確認できたら切り替えます。

Optimizely から Statsig へ。 予算の圧迫やモダナイゼーションをきっかけに、よく行われる移行です。作業量：エンジニア4～8人週です。まず機能の同等性を確認します（Optimizely には Statsig にないパーソナライゼーション機能があります）。実験をフラグより先に移行します。旧プラットフォームで進行中の実験がすべて完了してから、Optimizely の利用を終了します。

PostHog から Eppo へ。 統計的な厳密さが制約要因となり、ウェアハウスがすでに信頼できる唯一の情報源になっている場合によくあるパターンです。作業量：エンジニア6～10人週です。多くの場合、PostHog はアナリティクス用に残し、Eppo で実験を実施する構成になります。完全な置き換えではなく、2つのプラットフォームを併用する最終構成を前提に計画してください。

GrowthBook から Eppo へ。 商用サポートや、より高度な統計機能の価値が価格に見合うようになった場合によくあるパターンです。どちらもウェアハウスネイティブで、データがすでにスタック内にあるため、作業量はエンジニア2～4人週です。

任意のプラットフォームから Statsig へ。 マルチプラットフォームの混乱を解消するためによく行われる統合です。作業量はプラットフォーム数と進行中の実験数に応じて変わります。問題なく統合できる場合、エンジニア6～12人週で実施できます。

移行の進め方については references/migration-playbook.md を参照してください。どの移行にも共通するルールは3つです。並行稼働をいつまでも続けないこと、一度にすべてを切り替えないこと、進行中の実験がすべて完了する前に旧プラットフォームの利用を終了しないことです。

---

コストの実態

率直に言うと、ベンダー提供型（Statsig、Optimizely）はイベント数に応じた課金で、通常はイベント100万件あたり0.10～0.50ドルです。小規模なら予測しやすい一方、非常に大規模になると負担が重くなります。データウェアハウスネイティブ型（Eppo、有料版のGrowthBook）はユーザー数とデータウェアハウスのコンピューティングに対する課金です。有料プランの一般的な価格帯は年間5,000～50,000ドルで、データウェアハウスのコンピューティング費用は別の財務項目として計上されます。製品スイート型（PostHog、Amplitude）は全機能にまたがるイベント総量に応じた課金です。頻繁に利用する場合は最も費用対効果が高いことが多い一方、実験機能しか必要ない場合は最も高額になります。

無料プラン。PostHogは月間100万イベントまで無料です。Statsigは100万イベントまで無料です。Amplitudeは基本機能を月間1,000万イベントまで無料で提供します。GrowthBookは無料のオープンソースです。OptimizelyとEppoには、実質的な無料プランがありません。

落とし穴。表示価格だけを最適化しても、総コストは見落とされます。総コストには、エンジニアの作業時間、統計的な正確性（誤った結果を出す実験は、プラットフォーム料金の年間分を超える損失につながる可能性があります）、ガバナンスのオーバーヘッド、移行リスクが含まれます。表示価格は財務にとって重要ですが、総コストはプロダクトの開発速度に影響します。詳細と財務部門との会話の進め方については、references/cost-and-pricing-models.mdをご覧ください。

---

ガバナンスとチームへの適合性

権限レベル、承認ワークフロー、監査証跡、環境への昇格が、ガバナンスの4つの柱です。実験を作成するのは誰か、本番環境のターゲティングを変更するのは誰か、機密性の高いメトリクスを閲覧するのは誰か、ロールアウトを承認するのは誰か。エンタープライズプランでは、これらにすぐ対応できます。オープンソース版をセルフホストする場合は自分たちで構築する必要があります。エンジニアリングの対応力があれば問題ありませんが、対応力がなければ導入を見送る理由になり得ます。

多くの評価で認められている以上に、チームとの適合性が意思決定を左右します。PostHogとGrowthBookはエンジニア主導およびPLGチームに適しています。Optimizelyはマーケティング主導のチームに適しています。EppoとGrowthBookはデータチーム主導のチームに適しています。StatsigはPM主導のチームに適しています。プラットフォームのデフォルト設定は、主要ユーザーの方向にチームの実験文化を導きます。実際に誰に実験を運用してほしいのかに合ったものを選びましょう。

オンボーディングのコスト。新しいPMが初めての実験をリリースできるようになるまで、どれくらいかかるでしょうか。StatsigとPostHogは数時間から数日、Optimizelyは数日から数週間です。EppoとGrowthBookは、データウェアハウスとメトリクスがすでに連携されているかどうかによって異なります（連携済みなら数日、そうでなければ数週間）。詳細はreferences/governance-and-team-setup.mdをご覧ください。

---

MCP の機能レイヤー

AI 活用を重視するチームでは、MCP の機能レイヤーが決め手になりつつあります。2026年5月時点の状況は次のとおりです。

• 対象の7つのプラットフォームすべてに、Eppoを除き、公式またはホスト型のMCPがあります。Eppoが提供しているのはREST APIのみです。
• 機能の差は1桁以上あります。PostHogは200以上のツールを公開し、Kameleoonは7つを公開しています。数が多ければよいわけではなく、適切な規模はワークフローによって異なります。
• AI エージェントが実験を最初から最後まで実行するエージェント型ワークフローでは、MCP経由でCRUD全般に対応するプラットフォーム（Statsig、PostHog、GrowthBook、Optimizely）を優先してください。
• MCPが人間の作業を補助する、人間主導のワークフローでは、7つのどのプラットフォームでも利用できます（EppoはREST経由）。

MCPの提供状況は急速に変化しています。導入を決定する前に、各プラットフォームの最新状況を確認してください。Eppoは、現在のギャップを埋める今後のMCPリリースを注視する価値があります。機能の比較表はreferences/mcp-capability-comparison.mdをご覧ください。

---

判断を先送りすべきとき

「今ではない」が正解の場合もあります。4つのケースを紹介します。

PMF 前。実験用インフラを整えるのは時期尚早です。無料プラン（PostHog または Statsig）で障害を取り除き、どのプラットフォームにも意義が生まれるだけのトラフィックが得られるまで、本格的な判断は先送りしましょう。

単一実験での検証。1つの実験のためにプラットフォームを選ぶのはやめましょう。無料で簡単に使えるものを利用してください。プラットフォームの選択が必要なのは、初めて実験を行うチームではなく、実験を継続的な取り組みとして実施するチームです。

まだ実験文化がない。ツールを導入しても文化は変わりません。チームが実験を行っていないなら、高機能なプラットフォームを選んでも状況は変わりません。まず文化を築きましょう。実験が軌道に乗れば、プラットフォームの選択は明らかになります。

買収または大きな方向転換が保留中。状況が落ち着くまで先送りしましょう。買収側がすでに優先プラットフォームを決めている可能性が高いです。

---

よくある間違い

プラットフォームの選択では、12のパターンが繰り返し見られます。要点は次のとおりです。

• 最も安いものを選んだ。総コストは表示価格を大きく左右します。
• 最も機能が豊富なものを選んだ。使わない機能は技術的負債になります。
• 最初から複数のプラットフォームを試した。ほぼ必ず、後で統合プロジェクトになります。
• プラットフォームが要件に合わなくなっても、移行コストを理由に使い続けた。プラットフォームの維持コストは積み重なりますが、移行コストは一度限りです。
• デモを基準に選んだ。デモは見せ方を最適化していますが、実際に使うと本当のトレードオフが明らかになります。
• ガバナンスを確認しなかった。展開後に、誰でも本番環境のターゲティングを変更できると判明しました。
• チームのタイプに合わないプラットフォームを選んだ。マーケティング主導のプラットフォームを使うPM主導のチームでは、常に摩擦が生じます。
• データウェアハウスのセットアップを甘く見積もった。データウェアハウスネイティブのプラットフォームは、データウェアハウスがすでに整っていることを前提とします。
• 統計的な深さのレビューを省略した。その後、重要な実験で誤った結果に基づく判断が明らかになりました。
• MCP の動向を無視した。AI 重視のチームなのに、MCP に対応していないプラットフォームを選びました。
• トライアルではなくデモを基に要件書を確定した。実際に使うと、要件書の前提は崩れました。
• 再評価せずに契約を更新した。市場は変わりましたが、要件書は変わりませんでした。

症状、根本原因、対処法、予防策については、references/common-mistakes.md をご覧ください。

---

フレームワーク：持続可能なプラットフォーム選定のための11の検討事項

実験プラットフォームを選定または評価する際は、次の11項目を確認してください。推奨に至る前に、それぞれに回答してください。どれか一つでも飛ばすと、1年後にチームが移行プロジェクトに取り組むことになりかねません。

1. データアーキテクチャ。 ベンダー固有、プロダクトスイート、またはデータウェアハウス中心のいずれかです。このパターンは、ほかのすべての判断に影響します。
2. 統計的厳密性。 CUPED、逐次検定、比率指標に対するデルタ法、多重検定補正などです。営業との打ち合わせの段階で確認し、当然備わっていると思い込まないでください。
3. MCP の利用可能性。 現在の機能と今後の方向性です。チームが AI を積極的に活用している場合は、より重視してください。
4. フィーチャーフラグの連携。 同じプラットフォームに含めるか、別にするかです。一度決めたら、その影響を受け入れることになります。
5. 分析の深さ。 同じ画面でファネル、リテンション、コホートを利用できます。分析レイヤーに別のツールが必要かどうかを左右します。
6. ガバナンス。 権限、監査、承認ワークフロー、環境への昇格です。規制対象の業界では必須です。
7. コストの仕組み。 イベント数、シート数、またはデータウェアハウスのコンピューティングコストのいずれに基づくかです。利用状況の推移に合った仕組みを選んでください。
8. チームとの適合性。 PM 主導、エンジニア主導、データ主導、マーケティング主導のいずれかです。プラットフォームのデフォルト設定は、その主なユーザーに合わせてチーム文化を導きます。
9. オンボーディングコスト。 新しいチームメンバーが最初の実験を行うまでにかかる時間です。短いほど望ましいものの、プラットフォームによって大きく異なります。
10. 移行コスト。 選択を誤った場合の撤退計画は何か、という点です。移行コストが高いほど、決定時に求められる確信度も高くなります。
11. マルチプラットフォームとの適合性。 すでに導入済みのプラットフォームとこのレイヤーをきれいに連携できるか、それとも重複が生じるかを確認します。

このフレームワークから導かれる答えは、次の3つのいずれかです。根拠を添えた第一候補の推奨。状況が本当に判断しにくい場合は、候補を2つに絞った短いリスト。前提条件が満たされていない場合（トラフィックがない、社内に文化が根付いていない、ピボットが保留中など）は「保留」。

---

参考ファイル

• references/platform-decision-matrix.md - よくある意思決定の状況に応じたプラットフォームのマトリックスと、具体的な例。
• references/migration-playbook.md - よくある5つの移行について、作業量の見積もりと検証方法を含む、手順ごとの移行パターン。
• references/mcp-capability-comparison.md - 7つのプラットフォームにおける MCP 機能の比較表。
• references/multi-platform-orchestration.md - 実際に複数のプラットフォームを使用する構成における、責任範囲、共有指標の定義、照合ダッシュボード。
• references/cost-and-pricing-models.md - 料金体系、トラフィック規模ごとの実際のコスト範囲、財務部門との話し合いの進め方。
• references/governance-and-team-setup.md - 権限レベル、監査証跡の要件、環境への昇格ルール、チームとの適合性の評価。
• references/common-mistakes.md - 12の失敗パターンについて、それぞれの兆候、根本原因、解決策、予防策。

---

迷ったら、無難な選択をする

分析しても本当に判断がつかない場合は、無難な選択をしてください。無難とは、成熟していて、ドキュメントが充実し、ユーザー数が多く、選択を誤ったと分かった場合にも移行で立て直せることを意味します。SaaSならStatsigが無難です。プロダクト主導の成長ならPostHogが無難です。エンタープライズならOptimizelyが無難です。データウェアハウスネイティブならGrowthBookが無難です。

無難な選択は最適とは限りませんが、間違いであることはほとんどありません。状況が明確になり、チームが本当に必要なものを判断できる経験を積んでから、最適な選択をすればよいのです。無難な選択のコストは、効率が少し下がることです。珍しい選択をして誤った場合のコストは、1年分のプロダクト開発を中断する移行プロジェクトです。

どの無難な選択が適切かでチームの意見が分かれるなら、それはデータから得られるシグナルです。つまり、どの答えが明らかに正しいか判断できるほど、状況がまだ明確ではありません。上位2つを30日間試し、実際の利用データを使って11項目の検討フレームワークに照らして評価し、選択してください。試用を省略しないでください。デモでは実際の利用状況について誤解が生じますが、それを明らかにできるのは試用だけです。