A-MLE解説：広告ランキングのML実験ループを自律エージェントで高速化する

AI利用の明示

本記事の構成と本文は、OpenAIのコーディングエージェント「Codex」が作成しました。数値や主張は原論文を確認して記載していますが、利用時は原文も確認してください。

今回取り上げるのは、MetaのErwin Gaoらによる論文「Agentic ML Exploration (A-MLE) for Ads Ranking」です。2026年9月8日にarXiv v1として公開されたプレプリントで、PDFはこちらです。

この論文の価値は、広告ランキングモデルの改善を「優れた新手法を1つ発見する問題」ではなく「多数のモデル × 手法の組み合わせを試すML実験ループのスループット問題」と捉え直し、仮説生成から学習・評価・提案までをエージェントでつないだ点にあります。

ただし、公開情報だけでA-MLEを再現したり、費用対効果を検証したりすることはできません。評価対象はMeta内部の匿名化されたモデル群で、コード、データ、プロンプト、スキル、評価期間、主要な運用指標の絶対値は公開されていません。この記事では、論文が示した結果と、そこから導く実装案を分けて説明します。

課題：モデル性能より実験回数が制約になる箇所になる

大規模な広告ranking systemは、クリック、conversion、viewなど目的の違う多数のモデルで構成されます。モデルごとに学習データ、特徴量、アーキテクチャ、実行基盤の制約が異なるため、あるモデルで効果があった手法を別のモデルへ移植するだけでも大きな工数がかかります。

論文が整理する人手のML 反復は、次の6工程です。

文献、過去の提案、直近の学習履歴から仮説を作る
計算予算の中で試す候補と比較案を優先順位付けする
モデルや学習設定を変更する
学習ジョブを監視し、失敗時に復旧する
継続更新される比較手法と比較し、区分別の退行や分散を調べる
統計分析とlaunch判断を含むproposalを作る

1回の一連の実験には、経験豊富なMLエンジニアが数日から数週間関与します。人員が有限なら、検証できる組み合わせはごく一部です。特に、専門家の注意が向きにくいロングテールのモデルには、近いモデルですでに成功した改善案さえ展開されにくくなります。

A-MLEは、各工程を単発のスクリプトで省力化するだけではありません。工程間のhandoffも含めて1つのagent loopにし、人間を逐次操作するoperatorからstage境界のreviewerへ移します。

A-MLEの5段階アーキテクチャ

A-MLEの1セッションは、(model, objective, compute)を入力として受け取り、最終的にlaunch候補のproposalまたはnull result（有望な結果が得られなかった記録）を出力します。

Model + Objective + Compute
  ↓
Hypothesis Generation
  ↓ human checkpoint
Exploration Strategy ←──────────┐
  ↓ human checkpoint            │ multi-round feedback
Experiment Execution            │
  ↓ human checkpoint            │
Result Analysis ────────────────┘
  ↓ human checkpoint
Proposal / Null Result

各段階が Shared Knowledge Substrate と sandbox を読み書きする

1. Hypothesis Generation

エージェントは、対象モデルの直近の学習設定、baseline metric、過去に試した手法を読み、少数の候補と根拠を提案します。候補はモデル内部状態のanalyzer、training efficiencyのanalyzer、最近の文献検索などから作り、LLM criticがnoveltyとfeasibilityを評価します。

固定されたモデルのスナップショットではなく、現在の状態に基づいて仮説を立てることが重要です。比較手法が更新されれば、以前は妥当だった仮説がそのまま移植できるとは限りません。

2. Exploration Strategy

学習実行数、総計算量、実経過時間といった制約の中で、候補をどの順に試すかを決めます。個別仮説を切り分けて確認するexplorationと、有望な変更を組み合わせるexploitationを交互に行い、途中結果に応じて計画を更新します。

この境界では、人間がaggressivenessと計算コストのトレードオフを確認します。エージェントに自由な探索を任せても、資源配分の責任まで無条件に渡す設計ではありません。

3. Experiment Execution

エージェントはsandbox上で設定またはアーキテクチャを変更し、type check、unit test、イメージのビルド、短いsmoke testを通してから本学習を投入します。その後は非同期ジョブを監視し、失敗を次のように分類して対処します。

一時的な基盤の一時障害なら再試行する
コードや設定の問題なら修正する
本当のtraining divergenceなら候補を打ち切る
使えなくなったbranchの残り計算量を別の候補へ振り向ける

数時間かかる非同期ジョブを扱うため、agent loopには外部イベントまで停止し、完了後に文脈を保って再開する明示的なwaiting operatorがあります。これは通常の1 turnのLLM呼び出しとは異なる、運用基盤側の重要な機能です。

4. Result Analysis

結果は固定比較手法ではなく継続更新される比較手法と比較します。指標をadやユーザーの区分別に分解し、局所的な退行を確認します。run内分散がしきい値を超えた場合は自動で再実行し、単一seedの偶然を有望な結果として昇格させにくくします。

各roundの候補は構造化した結果一覧へまとめ、追加探索へ戻すか、最終proposalを作るかを判断します。成功だけでなくnull resultも文書化するため、同じ失敗を別モデルで繰り返すことを避けられます。

5. Shared Knowledge Substrate

セッションをまたぐ知識は、バージョン管理でバージョン管理された長寿命のMarkdown treeに保存します。per-techniqueとper-modelの記録には、適用可能なアーキテクチャなどのeligibility annotationとTrack Recordが含まれます。

新しいセッションでは、対象モデルに近い条件で過去に効果があった手法を検索します。終了時には結果をTrack Recordへ戻し、人が通常のコード変更と同じようにレビューできます。A-MLEの狙いは、エージェント個体の曖昧なメモリではなく、監査・差分確認・再利用ができる組織の知識を蓄積することです。

分野別スキルがLLM単体の能力より重要だった

論文は能力を3 tierに分けています。

Tier	評価する能力	代表的なタスク
L1	Tool availability	設定、metric store、学習基盤に関する単一ステップの操作
L2	Autonomous workflow execution	ジョブ投入、待機、障害復旧、結果要約を含むmulti-step task
L3	Open-ended exploration	モデル、目的、計算量を渡し、最善の改善を探索する

単一の実験モデルM*におけるL1 benchmarkでは、ドメイン知識と専用ツールを備えたA-MLEがoverall 68%でした。cross-portfolio toolだけを持つgeneric ML agentは16%、ツールを持たないgeneric LLMは8%です。ジョブの設定変更ではA-MLEが100%に達した一方、汎用な2構成は40%未満でした。

この比較が示すのは、「新しいLLMへ交換すれば業務エージェントになる」のではなく、対象システムのAPI、専門知識、検証手順をスキルとして接続する必要があるということです。ただし、このベンチマークの設問数や信頼区間は論文に示されていないため、68%という値を一般的なML agentの性能へ外挿はできません。

どこまで改善したのか

単一モデルのオフライン結果

M*は、比較的軽量なregression objectiveのranking modelです。Table 1は、回帰誤差の低減の継続更新される比較手法に対する相対改善を示しています。

A-MLE構成	相対的なオフライン改善	Training QPSへの影響
単一仮説でアーキテクチャをscale-up	+0.44%	neutral
multi-roundのアーキテクチャ探索	+0.58%	neutral
アーキテクチャとefficiencyを使うmulti-source探索	+2.56%	+0.42%

最大値は、論文本文では +2.557%、表では丸めて +2.56% と記載されています。これは相対的な回帰誤差の低減であり、CTRや売上が2.56%上昇したという意味ではありません。また、オンラインA/Bテストや本番導入後の事業指標は報告されていません。

Portfolio全体の結果

論文は、評価したモデルの過半数で測定可能なオフライン改善が得られ、エンジニア1人の1週間あたりの完了実験数は人手による比較手法の複数倍になったと述べています。training success rateは比較手法を「meaningfully surpassed」、proposal acceptance rateは「much higher」と報告されています。

しかし、これら3指標には絶対値、サンプル数、評価期間、分散、統計検定結果がありません。したがって「A-MLEがMeta内部の評価で改善傾向を示した」とは言えても、「生産性が何倍になり、何人月を削減したか」は公開情報から判断できません。

手法 family別の結果も、機密性のため件数がbucket化されています。self-supervised pretrainingは8モデル以上で試して過半数が人手のgatingを通過、embedding-based featureは3〜7モデルで試して過半数が通過しました。オプティマイザー / 損失、token-mixing、architecture scalingはmixedな結果です。ここでも、候補がオフラインの統計的有意性と人手レビューを通過したことは、オンライン投入の成功と同じではありません。

LLMを替えると探索行動も変わる

著者らはagent loop、スキル、プロンプトを固定し、Claude Sonnet、Gemini、GPT familyを比較しています。L2ではSonnet 3.5以降、Gemini 2.5、GPT-5が90点台後半のtask completenessを示す一方、一部モデルはworkflow IDをhallucinateしたり、非同期ジョブを待てなかったりしました。

L3では単純な優劣になりません。basic promptではGemini 2.5とGPT-5がaggressiveに探索し、Sonnet familyは比較的conservativeでした。競争を強調するstressful promptでは、Sonnet 4.0が比較中で最大の改善を見つけた一方、GPT-5は保守的になり、basic prompt時の改善の多くを失っています。

つまり、同じharnessでもモデルとプロンプトの組み合わせが探索方針を変えます。「強く改善を要求すれば良い候補が増える」とは限りません。本番環境ではモデル更新やプロンプト変更を独立したシステム変更として扱い、タスク完了率だけでなく、計算量消費、false promotion、null resultの質も再評価する必要があります。

観測された5つの失敗パターン

論文が報告する失敗は、実運用のエージェント設計にそのまま使えるchecklistです。

Failure mode	症状	A-MLEの対策
Hallucinated APIs	存在しないtraining APIを呼ぶ	launch前のpre-flight check
Baseline drift	offline winが並行する比較手法更新で消える	継続更新される比較手法で比較
Infrastructure fragility	一時障害をtraining divergenceと誤判定する	原因分類とbounded 再試行
Over-confident triage	単一seedの結果を昇格する	分散しきい値によるauto re-run
LLM-specific failures	ジョブ IDの捏造、完了したふり、プロンプトへの非単調な反応	モデル別評価とstage checkpoint

各stage境界のhuman-in-the-loopは、単なる安心材料ではありません。誤ったコード変更を学習投入前に止め、誤った統計判断をproposal化前に止めるblast-radius controlです。エージェントの権限を広げるほど、checkpointには承認対象、必要なevidence、タイムアウト時の挙動を明文化する必要があります。

公開情報から作る最小実装案

ここからは論文の内部実装そのものではなく、公開された設計を一般的なML teamへ適用する案です。Meta内部のAPI、プロンプト、スキル、データは公開されていないため、完全再現ではありません。

1. まずL1だけを作る

最初からopen-endedなL3探索を目指さず、読み取り専用の単一ステップから始めます。

現行比較手法と対象データの対象期間を取得する。学習設定のschemaを説明する。

過去runの指標と失敗理由を取得する。モデルのリビジョンと特徴量の依存関係を列挙する。

API responseを型付きschemaにし、架空のジョブや指標を返せないよう、取得元のIDとtimestampを出力へ必須にします。L1のgolden taskでツール呼び出しと回答を検証してから、設定変更へ進みます。

2. Experiment contractを固定する

各セッションの入力、予算、昇格条件をmachine-readableにします。

session:
  model_revision: ranker-conversion@a1b2c3d
  objective: reduce_normalized_entropy
  data_window: 2026-08-01/2026-08-28
  max_training_runs: 6
  max_retries_per_run: 2

gates:
  smoke_test_required: true
  compare_against: rolling_baseline
  min_seeds: 3
  segment_regression_budget: 0
  require_human_approval:
    - before_full_training
    - before_proposal

min_seeds: 3などは説明用の例で、論文が推奨する固定値ではありません。指標の分散、1 runのコスト、意思決定のリスクに応じて事前に設計します。

3. 状態機械としてorchestrateする

LLMの自由文だけで進行状態を管理せず、遷移条件をコード側に置きます。

PROPOSED
  → APPROVED
  → PREFLIGHT_PASSED
  → TRAINING_SUBMITTED
  → WAITING
  → EVALUATED
  → {RERUN_REQUIRED | NEXT_ROUND | PROPOSAL_READY | NULL_RESULT}

各遷移でモデルのリビジョン、code 差分、ジョブ ID、データの対象期間、指標、エージェント / prompt versionをappend-only logへ残します。WAITINGからの再開はジョブ IDを実在確認し、タイムアウト、cancel、重複投入をidempotentに扱います。

4. Failureを分類して再試行予算を分ける

OOM、scheduler preemption、data unavailable、NaN lossを同じ「失敗」にしないことが重要です。基盤の障害だけを自動再試行対象にし、code defectはsandboxへ戻し、training divergenceは別hypothesisとして記録します。上限を超えた再試行は人へescalateし、エージェントが計算量を使い続けないようにします。

5. Shared knowledgeをレビュー可能にする

1 手法の記録を、たとえば次のように管理します。

technique: wider-cross-layer
eligibility:
  architecture_family:
    - deep-cross-network
track_record:
  - model_revision: ranker-a@91e4d2a
    data_window: 2026-07-01/2026-07-28
    result: positive_offline
    metric_delta_relative: -0.0044
    proposal: experiments/exp-1842.md
  - model_revision: ranker-b@5bd013f
    data_window: 2026-08-01/2026-08-28
    result: null
    reason: segment_regression

自然言語の成功談だけでなく、対象revision、データの対象期間、比較手法、失敗理由を構造化します。更新をPull Requestにすれば、機密情報の混入、古い比較手法への過剰適合、エージェントによる根拠の書き換えを人が確認できます。

6. L2、限定L3の順で評価する

L2では、baseline refresh、同一条件のvariance test、単純な設定変更、既存ジョブのbatch evaluationなど、正解を検証しやすいタスクを使います。次の条件が安定してから、小さい計算予算のL3へ進みます。

存在しないAPIやジョブ IDを作らない
ジョブの重複投入と無限再試行がない
比較手法とデータの対象期間を取り違えない
区分 regressionを隠さない
null resultを成功へ言い換えない
人手なしで実行した範囲と、人が介入した範囲をログから区別できる

評価指標にはオフライン性能だけでなく、エンジニア1人の1週間あたりの完了実験数、人間の介入時間、学習成功率、proposalの無修正通過率、計算コスト、incident数を含めます。manual、スクリプト中心のsemi-automated、エージェントの3群を同じevaluation suiteで比べると、単なるツール導入とend-to-end orchestrationの効果を分離しやすくなります。

再現性と制約

本論文は本番システムの設計知見として興味深い一方、外部検証には大きな制約があります。

arXiv v1のプレプリントであり、査読済みとは記載されていない。データセット、モデル、コード、スキル、プロンプト、sandbox実装が非公開。

モデル群のモデル数、評価期間、学習実行数、計算量が非公開。スループット、training success、proposal acceptanceに絶対値や信頼区間がありません。

L1 benchmarkの設問数と構成が不明で、単一モデルM*の結果です。最大 +2.56% はオフラインの相対誤差改善で、online KPIや収益への効果ではありません。

human checkpointに要した時間が不明で、完全自律との比較ではありません。cross-LLM比較のAPI version、temperature、コスト、反復数などが十分に記載されていない。

また、論文が強く示しているのは、未知のアーキテクチャを発明するdepthより、すでに別モデルで効果があった手法を近いモデルへ展開するbreadthです。著者らも、新しいアーキテクチャやパイプライン設計へ深く参加させることをfuture workに挙げています。

そのためA-MLEを「AI研究者の完成形」と見るより、分野別スキル、状態管理、統計評価、障害復旧、人手gatingを組み合わせたML engineering automationと捉える方が正確です。

まとめ

A-MLEの中心的な発想は、強いLLMに自由に研究させることではありません。多数の広告ranking modelに対し、仮説生成、探索計画、実験実行、結果分析、共有知識という5段階を、検証可能なツールとhuman checkpointでつなぐことです。

単一モデルでは最大 +2.56% の相対オフライン誤差改善、L1ではdomain-equipped構成が68%の正答率を示しました。一方、モデル群全体の生産性向上には詳細な数値がなく、production KPIも未報告です。結果の強さは限定して読む必要があります。

実装時に優先すべきなのは、open-ended explorationより先に、read-only tool、型付きexperiment contract、明示的なwaiting、bounded 再試行、継続更新される比較手法、区分評価、レビュー可能なknowledge storeを整えることです。A-MLEが示す最大の教訓は、エージェントの信頼性は基盤モデル単体ではなく、その周囲のorchestration harnessで決まるという点にあります。

参照

Erwin Gao et al., Agentic ML Exploration (A-MLE) for Ads Ranking, arXiv:2609.08248v1, 2026-09-08.
Erwin Gao et al., PDF, 7 pages, 4 figures.