A/Bテスト基盤の開発案件｜必要スキル・単価と実験設計の実務

A/Bテスト基盤とは｜実験プラットフォームが担う4つの機能

結論から言えば、A/Bテスト基盤は「振り分けて、配って、測って、判定する」の4工程を仕組み化したものです。画面上のボタン色を変える作業ではありません。どのユーザーをどの群に入れたかを一貫して管理し、その結果を統計的に読める形にするのが本体です。

実験プラットフォームが持つ4つの機能

このうち特に事故が起きやすいのが計測です。割り当てログが欠けたり重複したりすると、後段の判定がまるごと信用できなくなります。実験基盤の案件で「データ基盤の経験」が歓迎要件に並びやすいのは、この構造が理由です。データ基盤側の全体像はデータ基盤案件の単価相場｜ETL・DWH・BIレイヤー別の目安とスキルで整理しています。

フィーチャーフラグとA/Bテストの関係

両者は重なりますが、目的が違います。

• フィーチャーフラグ：機能のオン・オフをデプロイと切り離す仕組み。段階的リリースや緊急停止が主目的

• A/Bテスト：フラグで分けた群の指標を比較し、施策の効果を判定する行為

多くの現場では、フラグ基盤の上にA/Bテスト運用が乗る形になります。実験SaaSのようにフラグ管理と分析を一体で提供する製品もありますが、フラグだけ入っていて露出ログも集計もない現場は珍しくない。案件要件に「Feature Flag導入」とだけ書かれている場合、実験の判定まで含むのか、リリース制御だけなのかは面談で必ず確認してください。ここを取り違えると、想定していたスキルと業務が噛み合いません。

ミニFAQ：SaaSを入れるだけなら基盤開発とは呼べませんか？

呼べる範囲とそうでない範囲があります。SDK組み込みとイベント設計、露出ログのデータ基盤への接続まで担当するなら基盤構築の一部です。管理画面でテストを作るだけの運用業務は、開発案件としては評価されにくくなります。

A/Bテスト基盤の開発案件はどれだけあるか｜公開案件の観測

先に数字を出します。A/Bテスト基盤の開発を主題にした案件は、主要エージェントの公開案件ではほとんど見つかりません。これは市場に需要が無いという意味ではなく、案件名が別の名前で立っているということです。

公開案件を検索した結果

以下は2026年9月時点で、国内のフリーランスエージェント2社の公開案件検索ページにキーワードを入力して確認した結果です。会員登録なしで閲覧できる公開案件のみを対象としており、非公開案件は含みません。

上記の件数は、各社の公開案件検索に「A/Bテスト」と入力して表示された数です。検索仕様・掲載タイミング・「ABテスト」「A/B testing」といった表記ゆれで変動するため、固定の数値としては扱わないでください。

テクフリで確認できた25件の表示単価は月額39万〜121万円と幅がありましたが、これは「A/Bテスト」を要件に含む公開案件全体の表示レンジであって、A/Bテスト基盤の開発案件の相場ではありません。案件の主業務はRAG開発やデータ分析であり、A/Bテストは付随する要件として書かれていました。

この観測から言えるのは1つです。A/Bテスト基盤を「専業スキル」として案件を探すと、公開案件ではほぼ空振りします。

探し方｜どのKW・要件文で絞るか

現実的な探し方は、職種タグで広く取って要件文を読む方法です。

1. フリコンの案件一覧などで、まず「バックエンド」「データエンジニア」「SRE」の職種で絞る

2. 要件文・歓迎要件を「実験」「A/Bテスト」「Feature Flag」「グロース」「効果検証」で目視スキャンする

3. 事業フェーズがグロース期のtoC・SaaSプロダクトを優先する。実験基盤はユーザー数がある程度ないと成立しないため、立ち上げ直後のプロダクトには存在しにくい

4. 面談で「実験を回している頻度」を数字で聞く。月1回未満だと、専用基盤を作る優先度は上がりにくい

媒体によっては、フリーワード検索が要件文まで十分に拾わない場合があります。要件文まで自分で読む前提で、ヒット件数の少なさに落胆しないでください。

ミニFAQ：非公開案件なら基盤開発の募集はありますか？

公開情報だけでは判断できません。公開案件で0件だったからといって非公開でも無いとは言えず、逆に非公開に多いと断定する根拠もありません。エージェントの担当者に「実験基盤・Feature Flagの構築経験を活かせる案件」と具体語で伝えて探してもらうのが確実です。

案件の3類型と必要スキル・単価の考え方

A/Bテスト関連の案件は、技術ブログと求人票を突き合わせると3つの層に分かれます。この分け方は求人票にも技術ブログにも明示されていないため、参画前の見極めに使ってください。

類型A：SaaS導入・計測実装

既存のSaaS（LaunchDarkly、Optimizely、Firebase A/B Testing など）を入れ、SDKを組み込み、イベントを設計する仕事です。Webフロントエンドやモバイルアプリ側の実装が中心になります。

• 求められる経験：該当プラットフォームのSDK組み込み、タグマネージャやアナリティクスの設計、3年程度のWeb実務

• 詰まりやすい点：SPAでのフラグ評価タイミング、初回描画時のちらつき、計測イベントの重複

• 位置づけ：入りやすいが、単体では単価が伸びにくい層

類型B：内製基盤の開発・移行

自社で割り当てサービスや管理画面を持ち、その開発・刷新を担う仕事です。国内の事業会社が技術ブログで公開している事例は、ほぼこの層にあたります。

• 求められる経験：分散システムの設計、低レイテンシなAPI、データパイプライン構築。これらの実務経験を数年単位で求められやすい

• 周辺技術：BigQueryなどのDWH、Airflow系のワークフローエンジン、マイクロサービス構成、イベント駆動アーキテクチャ

• 位置づけ：最も高い技術要件と、相応の報酬が期待できる層

実像を掴むには公開事例が手っ取り早い。ZOZOの推薦システムにおけるA/Bテスト標準化は、設計テンプレートとサンプルサイズ自動推定を整備して1テストあたりの作業を42時間から8時間に短縮したと公開しています。メルカリのA/Bテスト分析自動化はCloud Composer（Airflow）のDynamic DAG生成とBigQuery、Streamlitの組み合わせ。サイバーエージェントのABEMAにおけるA/Bテスト運用はベイジアンA/Bテストを採用し、レポートを自動生成してTableauで全社に共有しています。求人票には書かれない「実際に触る技術スタック」がここに出ています。

類型C：実験設計・分析自動化

統計的な妥当性の担保と、レポーティングの自動化を担う仕事です。データサイエンティスト寄りの募集に混ざって出てきます。

• 求められる経験：仮説検定の実務理解、SQLでの指標設計、Python（pandas等）での集計自動化

• 参考：統計検定の2級程度の知識があると要件文の読解が楽になります。pandasとSQLは前提スキル

• 位置づけ：データ職からの横入りがしやすい層

LINEヤフーのYahoo!広告ディスプレイ広告におけるABテスト実践では、デルタ法・A/Aテストのシミュレーション・検出力分析の自動化が公開されています。この層の実務が具体的に分かる数少ない日本語一次情報です。

単価の考え方｜専業相場は存在しないと考える

A/Bテスト基盤の開発案件に限定した単価相場は、公開情報では確認できませんでした。 前述のとおり公開案件が独立した職種として立っていないためです。ここで「月◯◯万円が相場」と書ける根拠は無い、というのが正直なところです。

実務的には、隣接領域の単価レンジを基準に置き、実験基盤の経験を上乗せ材料として交渉するのが現実的です。近い領域の相場は次の記事で整理しています。

• データ基盤案件の単価相場｜ETL・DWH・BIレイヤー別の目安とスキル

• SREフリーランスの単価相場｜DevOps案件の月額レンジと参入目安

• BIエンジニアのフリーランス単価相場｜Tableau・Power BI案件の実情

自分の経歴でどのレンジを狙えるかを確認したい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を出せます。単価の上げ方そのものは【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？にまとめてあります。

実験設計で問われる実務論点｜SRM・ピーキング・サンプルサイズ

面談で差がつきやすいのはこの領域です。ツール名を並べられるかではなく、壊れ方を知っているかが問われます。

割り当ての一貫性とSRM（サンプル比率のミスマッチ）

同じユーザーが訪問のたびに別の群に入ると、実験は成立しません。ユーザーIDと実験IDを組み合わせてハッシュ化し、決定的に群を決めるのが基本形です。

その割り当てが設計どおりに効いているかを監視するのがSRMです。50対50の設計なのに、サンプルサイズに照らして不自然な偏りが続くなら、どこかが壊れている可能性があります。比率の差だけで判断するのではなく、サンプルサイズを踏まえた検定で確認するのが一般的です。MicrosoftのExperimentation Platformチームは、SRMの診断に関する研究で、原因を割り当て・実行・ログ処理・分析の4段階に分類しています。基盤側でSRMを自動検知し、検知したら結果を出さない設計にしておくのが実務の定石です。手作業のチェックに任せると必ず見落とします。

ピーキング問題と逐次検定

実験の途中経過を何度も覗き、有意になった瞬間に止める。これをピーキング問題と呼びます。固定サンプルサイズを前提とした検定で途中停止を繰り返すと、偽陽性率が名目の水準を大きく超えます。

対策は2つです。事前に決めた期間・サンプル数まで見ないか、逐次検定に対応した統計手法を使うか。後者の実装例はGrowthBookの逐次検定に関するドキュメントが公開されています。学術的な出典としては、Johariらによる "Peeking at A/B Tests: Why it matters, and what to do about it"（KDD 2017、DOI 10.1145/3097983.3097992）が定番です。

管理画面で途中経過を常時表示するなら、逐次検定を入れるか、警告を出す。 この設計判断ができるかどうかが、基盤開発者としての評価を分けます。

サンプルサイズと実施期間の決め方

必要サンプル数は、検出したい効果量（MDE）、指標の分散、有意水準、検出力から算出します。ZOZOの前掲記事では n = 2σ²(z_α+z_β)²/δ² の式を明示し、検証期間を2〜4週間に設定したうえで自動推定を組み込んだと公開しています。

期間の目安については、GoogleのFirebase A/B Testing 公式ドキュメントがRemote Configを使う実験で最低14日間の実施を推奨しています。曜日変動をまたぐ目安として2週間前後がよく使われますが、必要な期間はトラフィック量・指標の発生頻度・季節性で変わります。平日だけの3日間で判断するのは避けたほうが無難です。

なお有意水準0.05・検出力0.8という数値は業界と学術の慣行であって、規格ではありません。プロダクトやリスク許容度に応じて変えるものです。要件として一律に固定されているかのように扱わないでください。

ガードレールメトリクスとA/Aテスト

主要指標が改善しても、別の指標が壊れていれば施策は失敗です。エラー率、ページ読み込み時間、退会率といった下げてはいけない指標をガードレールとして常時監視する設計が必要になります。KohaviらによるTrustworthy A/B Tests の資料は、この種の落とし穴を体系的に扱っており、面談前の予習に向いています。

A/Aテストは、同じ内容を両群に配って差が出ないことを確認する手法です。基盤を作った直後や、ログ収集の実装を変えた直後に回します。差が出たら計測か割り当てが壊れている。地味ですが、基盤の信頼性を担保する手段としては最も確実です。

ツール選定｜SaaSとOSSセルフホストの比較

案件では「なぜこのツールを選んだのか」を説明できることが求められます。以下は各社の公式情報で確認した内容です（2026年9月時点）。

料金の詳細はLaunchDarklyの料金ページとStatsigの料金ページで確認できます。数値は改定されるため、提案時には必ず公式ページで最新の条件を見てください。

ライセンスと提供終了リスクを見落とさない

OSSだから自由に使える、とは限りません。UnleashはリポジトリのLICENSEでAGPL-3.0が指定されています。AGPLはネットワーク越しの提供時の扱いが論点になりやすいライセンスです。自社プロダクトに組み込んで外部提供する構成では、ライセンス条件を確認したうえで法務と相談して判断してください。GrowthBookも単一ライセンスではなく、enterprise配下のディレクトリだけ別ライセンスが適用されます。「GrowthBookはMIT」と一括で説明すると不正確です。

もう1つ。AWS CloudWatch Evidently は提供終了しています。 AWS公式がサポート終了の告知を出しており、終了日は2025年10月17日、移行先としてAWS AppConfigが案内されています。古い技術記事を参考に提案資料へ載せると、その場で信頼を失います。クラウドのマネージドサービスは畳まれることがある。この前提で選定理由を組み立ててください。

なお、Firebaseまわりの案件動向はFirebaseとは？特徴・主要サービス・案件単価をフリーランス視点で徹底解説でも触れています。

よくある失敗と対策｜フラグ負債とSRM見落とし

失敗1：フラグが消えず技術的負債になる

実験が終わってもフラグが残り、条件分岐が積み上がる。半年後には誰も削除できないコードになります。これはフィーチャーフラグ導入で最も頻繁に起きる失敗です。

対策は運用ルールの側にあります。フラグに有効期限とオーナーを必須属性として持たせ、期限切れを一覧で検出できるようにする。業務委託で参画する場合は、自分が作ったフラグの撤去まで契約期間に含まれるかを最初に確認してください。 契約終了後に残骸だけが残るのは、双方にとって不幸です。

失敗2：SRMを見落として誤った結論を出す

割り当て比率のズレに気づかないまま「勝った」と判定し、施策を全展開してしまうパターンです。前述のとおり自動検知の仕組みを基盤に入れておくのが正解で、レポート生成時にSRMチェックを通す実装が現実的です。検知したら結果を表示しない、という強めの制御をかけている事業会社もあります。

失敗3：効果を過大に見積もる

初期の実験は劇的な数値が出やすい。サンプルが少なく分散が大きいためで、期間を延ばすと差が縮むことがよくあります。ノベルティ効果（新しいUIへの一時的な反応）も混ざります。曜日変動をまたぐ期間を確保し、初週の数字だけで意思決定しないという運用ルールを提案できると、基盤の作り手として信頼されます。適切な期間はトラフィック量と指標特性で変わるため、一律の日数で固定しないことも併せて伝えてください。

参画前に確認したい10のチェックリスト

面談や初回ミーティングで聞いておくと、参画後のミスマッチが減る項目です。技術ブログにも求人票にも載っていない論点をまとめました。

4番と7番は特に重要です。データ参照権限が出ないまま実験基盤の改修を任されるケースは実際にあり、着手してから詰まります。

ケース別｜どの経歴からどう入るか

バックエンド出身の場合

割り当てAPIとSDK組み込みが最短の入口です。既存プロダクトにフィーチャーフラグを導入した経験があれば、そのまま職務経歴に書けます。不足しがちなのは統計側の語彙なので、サンプルサイズと有意水準の話を自分の言葉で説明できるところまで詰めておくと通りやすくなります。マイクロサービス構成での実験基盤は類型Bの主戦場です。

データエンジニア出身の場合

露出ログの取り込みとレポート自動化が担当範囲になります。Airflow系のワークフロー構築とDWHの設計経験があれば、類型Cから類型Bへ広げやすい。データエンジニアとは？仕事内容・年収・将来性をわかりやすく解説とエンジニアの職種転換｜開発からSRE・データ職へ移る順序と段階も参考になります。

フロントエンド・グロース寄りの場合

計測実装とUI側の分岐実装から入る道です。ここは類型Aに近く、単体では単価が伸びにくい。プロダクト側の意思決定に関われるポジションを狙うと評価が変わります。プロダクトマネージャー（PdM）とは｜仕事内容・年収・PMとの違いを解説で役割の境界を把握しておくと、面談での自己定義がしやすくなります。

CI/CDとの接続も評価対象です。フラグ配信をデプロイパイプラインに組み込む話はGitHub Actionsとは？CI/CDの仕組み・基本ワークフロー・案件単価をフリーランス視点で解説が入口になります。

まとめ

A/Bテスト基盤の開発案件は独立した募集としてはほぼ存在せず、データ基盤・バックエンド案件の要件に埋もれています。 単独スキルで探すのではなく、既存の職種タグで案件を取り、要件文から実験・Feature Flagの記述を拾う進め方が現実的です。

• 公開案件の観測（2026年9月時点、エージェント2社）では、A/Bテスト専業の案件は確認できなかった

• 案件はSaaS導入・内製基盤開発・実験設計の3類型に分かれ、必要な経験年数が異なる

• 専業の単価相場は公開情報に存在しない。データ基盤・SRE・BIの隣接レンジを基準に交渉する

• 実務で問われるのはSRM検知、ピーキング問題への対処、ガードレール監視といった壊れ方の知識

• ツールはライセンスと提供終了リスクを確認する。Unleashは AGPL-3.0、CloudWatch Evidentlyは2025年10月17日に終了

• 参画前に「データ参照権限」と「フラグ撤去責任の所在」は必ず確認する

次のアクションとしては、まず現在の経歴がどの類型に近いかを整理し、フリコンの案件一覧で職種タグから要件文を読む作業から始めてください。狙えるレンジの目安は単価診断で確認できます。

参照した一次情報は以下のとおりです。

• ZOZOTOWNの推薦システムにおけるA/Bテストの標準化（ZOZO TECH BLOG）

• Yahoo!広告ディスプレイ広告におけるABテスト実践（LINEヤフー Tech Blog）

• メルカリにおけるA/Bテスト分析自動化の取り組み（メルカリエンジニアリング）

• ABEMAにおけるA/Bテスト運用への取り組み（CyberAgent Developers Blog）

• Firebase A/B Testing 公式ドキュメント

• Support for Amazon CloudWatch Evidently ending soon（AWS公式）

• Diagnosing Sample Ratio Mismatch in A/B Testing（Microsoft Research）

• Sequential Testing（GrowthBook Docs）