GTMロジックを自己進化させる
5系統のアルゴリズムと最前線論文で設計する自己改善エンジン

0. なぜ「自己進化するGTM」が2026年のテーマになるのか

前回までの記事で扱ってきたGTM Engineeringは、基本的に人間が設計したロジックを人間が改善し続けるモデルだった。スコアの重みはRevOps/GTM Engineerが四半期ごとに見直し、アウトリーチ件名はマーケが差し替え、ルーティングルールは営業マネージャが調整する。このモデルにはスケール上限がある。ロジックの分岐数が増えるほど、チューニングが追いつかなくなる。

2025-2026に入り、2つの独立した潮流がGTM Engineering側に合流しつつある。

1. ML側: Contextual Bandit / Uplift Modeling / Off-Policy評価 の論文が「本番データで継続学習するマーケティング最適化」として定式化され、実装事例が出てきた。
2. LLMエージェント側: Reflexion / Self-Refine / Promptbreeder / AlphaEvolve / Darwin Godel Machine (DGM) など、エージェント自身がプロンプト・コード・ワークフローを書き換えて改善する系統が2025年にブレークスルーを迎えた。

この2つを組み合わせると、「人間がGTMロジックを書く」から「GTMロジックが自分を書き換え続ける」への移行が工学的に可能になる。本稿では、この移行に使えるアルゴリズムを5系統に分類し、どの問題にどれを当てるかを整理する。

1. 5系統マップ — どの問題にどのアルゴリズムを当てるか

GTMロジックの自己進化に使える手法は、目的と仮定によって5系統に分類できる。

この5つは排他ではなく階層的に積める。バンディット（行動選択）の上に Uplift（介入対象選別）を載せ、その上に LLM のメッセージ自己改善を走らせ、さらに上位レイヤーで DGM 的にワークフロー全体を進化させる、という構成が理論的な上限である。以下、1つずつ見ていく。

2. 系統(1) : オンライン学習・バンディット

2-1. 問題定義 — 離散選択の継続最適化

アウトリーチ件名の5案、送信チャネル3種、送信時間帯6パターン、CTAテキスト10案 — こうした「離散かつ報酬が確率的な選択」は、A/Bテストで順に検証するとコストと時間が爆発する。Multi-Armed Bandit (MAB) は探索と活用のトレードオフを確率論的に最適化する古典的解法で、2026年時点でもマーケティング最適化の第一選択肢だ。

2-2. アルゴリズム3種

Braze、HubSpot、Optimizely、Iterableなど主要なマーケティングプラットフォームはMAB/Contextual Banditを商用化済みで、「件名A/B/Cのうち、どれを何%に送るか」をリアルタイムで調整する機能を持つ。Nature Scientific Reports 2025 の Multi-Objective Contextual MAB はレコメンデーションシステムで複数目的（CVR×売上×離脱率）の同時最適化を扱っており、B2BのGTMでも「SDR返信率 × 商談化率 × 単価」の3目的最適化に直接使える。

2-3. 実装最小例 — Thompson Sampling

# 各arm（件名案）ごとに Beta(α, β) を持つ
arms = {
  "subject_a": {"alpha": 1, "beta": 1},
  "subject_b": {"alpha": 1, "beta": 1},
  "subject_c": {"alpha": 1, "beta": 1},
  "subject_d": {"alpha": 1, "beta": 1},
}

def pick_arm():
    samples = {k: beta.rvs(v["alpha"], v["beta"]) for k, v in arms.items()}
    return max(samples, key=samples.get)

def update(arm, reward):  # reward ∈ {0,1} = 返信あり/なし
    arms[arm]["alpha"] += reward
    arms[arm]["beta"]  += (1 - reward)

これだけで、「返信率が高い件名ほど選ばれる確率が上がる」自己進化ループが成立する。件名を追加するときは{"alpha":1, "beta":1}でappendするだけでいい。

2-4. Drifting Bandit — 報酬分布が時間で変わる前提へ

季節性やトレンドで「先月勝っていたアーム」が今月劣化することはGTMでは常態。Drifting MABは忘却係数γを入れて過去の観測を減衰させる。シンプルな実装は alpha_t = γ·alpha_{t-1} + reward。2026年現在、SNSやECではこの実装が標準化されている。

3. 系統(2) : 因果推論 / Uplift Modeling

3-1. 「コンバートしそう」vs「介入で変わる」

スコアリング＝コンバート確率の予測、という定義には決定的な欠陥がある。何もしなくてもコンバートする人に広告を出しても、増分効果はゼロだ。これが2024-2025のマーケティングMLで注目されるUplift Modeling（CATE: Conditional Average Treatment Effect 推定）の問題意識である。

Uplift Modelingの目標は以下。

3-2. CATE推定器の比較（Criteo Uplift v2.1）

arXiv:2604.06123 の2025年ベンチマーク（1,398万レコード、Criteo実データ）によれば：

ランダムに比べて3.9倍効率が上がることがわかる。これは「DBに入っている全員に同じ施策を打つ」運用と、「Uplift Top20%だけに打つ」運用のROI差がそのまま4倍近く出ることを意味する。

3-3. Causal Forest × Deep RL（MDPI 2025, Symmetry 17(4))

2025年の注目は、静的なUpliftモデルから動的Upliftモデルへの移行だ。Causal Forestで各顧客のCATEを推定しつつ、深層強化学習（DRL）で介入タイミングと種類を逐次決定する枠組みが提案された。著者らはターゲティング効率で27%改善、ROMI（Return on Marketing Investment）で18%向上を報告している。

GTMに落とすと、「誰に介入するか（Uplift）」と「いつ何を送るか（RLポリシー）」を同じ目的関数で同時最適化する設計になる。従来はこれらは別チーム・別ダッシュボードだった。

3-4. B2Bで特に有効な理由

B2Bは対象母数が小さく、介入1回のコスト（SDR時間、広告費、ウェビナー運営費）が高い。ランダム配布ではなく効果が出る相手だけに絞ることの経済インパクトが、B2Cよりも大きい。California Management Review 2025の5レッスン記事にあるように、Uplift導入は「キャンペーンを止めるべき顧客セグメント」を発見する効果もあり、CACの下方圧力として働く。

4. 系統(3) : Off-Policy評価 — 安全に進化させるための事前テスト

4-1. 自己進化の最大リスクは「悪化したポリシーの本番流出」

バンディットもUpliftモデルも、学習が進めばポリシーは常に変化し続ける。では「新ポリシーが旧ポリシーより本当に優れている」とどう確かめるか。素朴にはA/Bテストだが、毎回A/Bを待っていると進化速度が落ちる。

Off-Policy Evaluation (OPE) は、過去の本番ログ（旧ポリシーが取った行動と観測された報酬）だけから、新ポリシーのもし採用していた場合の期待報酬を推定する技術だ。本番に出す前のオフライン検査として機能する。

4-2. 基本3手法

4-3. 2025年の進化 — CPME（分布ごと推定）

従来のOPEは「新ポリシーの期待報酬」を推定する。だがマーケティングでは「平均は上がったが、ごく一部のユーザーで壊滅的に悪化する」リスクが実運用では致命的になる（例: VIP顧客だけチャーン率が跳ね上がる）。

arXiv:2506.02793 が提案する Counterfactual Policy Mean Embedding (CPME) は、RKHS（再生核ヒルベルト空間）で報酬分布全体を埋め込み、DR的に推定する。結果として、平均値だけでなくテール・リスクの事前評価ができる。GTMで「新ポリシーを出す前に、最悪ケースがどこまで悪化するか」を確認できるのは、本番安全性の観点で大きい。

5. 系統(4) : LLMエージェントの自己改善

5-1. 重み更新なしで改善する系統

従来の機械学習は「新データ→勾配→重み更新」で進化する。LLMエージェントは別ルートで進化できる。プロンプト・スクラッチパッド・エピソディック記憶を書き換えるだけで、同じ基盤モデルで性能が伸びる。2023年の2本の論文がこの系統の起点になった。

• Self-Refine (Madaan et al. 2023, arXiv:2303.17651): 同じLLMが「生成→自己評価→リライト」を1〜3回繰り返すだけで、要約・コード生成・対話品質が有意に改善。追加学習ゼロ。
• Reflexion (Shinn et al. 2023, arXiv:2303.11366): 失敗した試行を「言語的な反省文」としてエピソディック記憶に書き込み、次の試行でコンテキストに注入する。Verbal Reinforcement Learningと著者らは呼ぶ。

5-2. 2025年の発展

• Multi-Agent Reflexion (MAR) (arXiv:2512.20845): 単一エージェントの自己反省には視野の限界がある。批評役ペルソナを複数投入し、エピソディック記憶を合議で形成する。SWE-bench類似タスクで精度向上を確認。ただしAPI呼び出しが単一Reflexionの約3倍。
• Nature Publication (npj Artificial Intelligence 2025): 自己反省プロンプトでGPT-4ですら学術応答品質が統計的有意に向上することを実証。

5-3. 進化的プロンプト最適化

Self-Refineは「1つのプロンプトを手直しする」だが、Promptbreeder / EvoPrompt はプロンプトの集団を進化させる。

• Promptbreeder (Fernando et al. 2023, arXiv:2309.16797): タスクプロンプトだけでなく、変異プロンプト（タスクプロンプトをどう変異させるかの指示）自身もLLMが書き換える。自己参照的自己改善。
• EvoPrompt (arXiv:2309.08532): GA/DE的な交叉・変異をLLMオペレータで実行する。実装コードが公開されており、再現性が高い。

GTMに落とすと、アウトリーチ本文のテンプレート集団を、実際の返信率をfitnessにして世代交代させる運用ができる。件名のバンディットが離散5案の最適化だとすれば、Promptbreederはテンプレートの開放的な探索を担う。

6. 系統(5) : 進化的コード探索 — GTMワークフロー自体を進化させる

6-1. FunSearch → AlphaEvolve → DGM の系譜

ここが2024-2025で最もインパクトのあった領域だ。

AlphaEvolveはGemini Flash + Gemini Proのアンサンブルで提案生成と評価を回し、実際にGoogleの本番行列乗算アルゴリズムを改善したと報告されている。FunSearchとの最大の差は、「関数」ではなくファイル群・アルゴリズム全体を進化対象にする点。

6-2. Darwin Godel Machine (DGM) — 自分のコードを書き換えるエージェント

arXiv:2505.22954（Jenny Zhang et al., Sakana AI / UBC）は、エージェントが自分のPythonコード（ツール定義、ループ制御、コンテキスト管理、レビュー機構など）を読み・書き換え、コーディングベンチマークで経験的に性能が上がったものだけをアーカイブに残す仕組みを提示した。特徴：

• アーカイブ型進化: 直線的最適化ではなく、複数の「興味深い」エージェントを保存し、そこからサンプリングして変異させる。Stepping Stones（踏み石）を明示的に残す。
• 経験的fitness: Gödel Machineの「証明可能性」要件を捨てて、SWE-bench（20.0% → 50.0%）、Polyglot（14.2% → 30.7%）の実測スコアを使う。
• 安全機構: サンドボックス実行、人間監視、Web制限、報酬ハッキング検知、全変更の系譜トラッキング。

GTMへの応用ポテンシャルは大きい。「シグナル検出→ルーティング→アウトリーチ生成→フィードバック学習」の全工程を1つのPythonエージェント実装として持ち、成果指標（商談化率・MRR寄与など）をfitnessにして、エージェントアーキテクチャ自体を開放的に進化させられる。人間がルーティングルールを書く時代ではなく、ルーティングコードをエージェントが自分で書き直す時代である。

6-3. EvoAgentX とサーベイ

実装側では EvoAgentX（GitHub）がマルチエージェント進化のOSSフレームワークとして急成長している。サーベイ arXiv:2508.07407（Fang et al. 2025）は「System Inputs / Agent System / Environment / Optimisers」の4コンポーネントでSelf-Evolving Agentsを統一的に整理しており、自社システムを分類・比較するフレームとして実用的だ。

7. 統合アーキテクチャ — 5系統をどう積むか

5系統は競合ではなく階層化して積む。下から順に。

L1〜L3は数理的に安全なコア、L4〜L5は開放的に広がる探索層である。L3は境界線として特に重要で、L4やL5のエージェントが書き換えた新ロジックも、最終的にL3のOPEゲートを通ってから本番に出す。これで「LLMが暴走して悪い施策を打つ」最悪ケースを抑制できる。

8. MOSH（B2C×C2Cマーケットプレイス）への応用シナリオ

前回の記事で整理した通り、MOSHはB2B SaaS的なSales層を持たない代わりに、クリエイター支援チーム・プロダクト・コンテンツエンジンが「Salesの等価物」として動いている。この各層にどの系統を当てるかを整理するとこうなる。

重要なのは、全部を一度にやらないこと。L1とL3から始めて、半年〜1年かけてL2→L4→L5と上に積むのが現実的。下位層が安定していないと、上位の自己進化は意味をなさない（例: L3のOPEが弱いと、L5のDGMがノイズに沿って進化して本番を壊す）。

9. Crawl / Walk / Run 実装ロードマップ

9-1. Crawl（0〜1ヶ月）: バンディットとOPEから始める

• 件名・CTAなど3〜5アームのThompson Samplingを1本のスクリプトで実装（L1）
• 本番ログに context, action, reward を必ず残す
• 既存ルールベース施策と Thompson版を並走させて、IPW推定でオフライン比較（L3）
• 成果指標の定義書（CAC / Payback / LTV）を経営と合意

9-2. Walk（1〜4ヶ月）: Uplift Modelingで「誰に」を自動化

• 過去1年の介入ログからS-Learner / Causal ForestでCATEを推定（L2）
• Top N% の介入対象だけに絞るポリシーをCPMEで事前評価（L3）
• カナリアリリース（トラフィック1〜5%）→ ロールアウト
• Self-Refineでメッセージ自己レビューGateを追加（L4 – 初級）

9-3. Run（4〜12ヶ月）: エージェント進化へ

• CS応答テンプレートをPromptbreederで集団進化（L4 – 中級）
• ワークフロー実装を 1 Pythonパッケージに集約し、DGM風のアーカイブ進化を導入（L5）
• fitness関数はMRR寄与・Activation率・CACの合成指標に
• 人間レビューは「月1回のアーカイブ・キュレーション会」として制度化
• 事故対応: L3のOPEが悪化検知したら即ロールバックする自動スクリプトを用意

10. 最後に — 「GTMロジックが自己を書く」時代の設計者の役割

自己進化するGTMが可能になると、GTM Engineerの仕事は「ロジックを書く」から「fitness関数とガードレールを書く」に変わる。何を最適化するか、何を禁止するか、どのレイヤーで人間が介入するか — この設計の質が、システムの上限を決める。

2025年のDGM論文が示した最大の教訓は、「証明可能性を捨てて経験的fitnessで回せば、AIは自分でツールを作り、自分のアーキテクチャを書き換える」ということだ。これをGTMという経営インパクトが大きく、かつフィードバックが早い領域に持ち込まない理由はない。B2Cマーケットプレイスのように、シグナルが豊富で、介入の可逆性が高く、成果が売上で即計測できる環境は、自己進化するGTMの最初の実験場として理想的な条件を揃えている。

11. 系統別 FAQ（AEO用）

検索・LLM回答エンジンからの参照利便性のため、各系統ごとに実務上の頻出質問をまとめる。回答は本文中のより詳細な議論へのショートカットとして設計している。

系統1 : オンライン学習 / バンディット

Q. Thompson SamplingとLinUCBはどう使い分ける？
文脈なしの単純な離散選択（件名5案など）はThompson Sampling。文脈が効く場合（企業規模×業種で最適解が変わる）はLinUCBまたはLinear Thompson Samplingへ。非線形な文脈依存性が強ければNeural Contextual Banditへ。

Q. Drifting Banditが必要になるのはいつ？
報酬分布が季節性・トレンド・競合動向で時間変化する場合。B2Bマーケでは決算期・展示会時期で反応率が大きく変わるため、忘却係数γ（0.9〜0.99）で過去観測を減衰させる。

Q. 報酬が遅延する（商談化まで3ヶ月かかる）場合は？
Delayed Feedback Banditかプロキシ報酬を使う。最終成果と相関する早期シグナル（返信率・2nd-mailクリック）を代理報酬にし、相関係数でバイアス補正する。

系統2 : 因果推論 / Uplift Modeling

Q. Uplift Modelingと通常のLift（単純差分）の違いは？
Liftは集団平均の差（ATE）、Upliftは個人ごとの処置効果（CATE）。介入コストが1件あたり無視できない領域ではCATEベースの絞込みが必須。

Q. Causal ForestとS-Learnerはどちらを選ぶ？
2025年のCriteo Uplift v2.1ではS-LearnerがQini 0.376、Causal Forestは0.334。処置効果が比較的一様ならS-Learner、サブグループ間で処置効果が大きく分かれるならCausal Forestの方が頑健。実務では両方作ってQini曲線で勝った方を採用。

Q. 動的Uplift（Causal Forest × DRL）の実装難易度は？
静的Upliftの3〜5倍。状態空間設計・報酬関数・探索戦略・割引率・オフライン評価が追加で必要。まず静的Upliftで+27%改善を再現してからDRL化するのが現実的。

系統3 : Off-Policy Evaluation

Q. Off-Policy評価とオフラインA/Bテストの違いは？
A/Bは過去実施済みのAとBの比較にとどまり、未実施の新ポリシーCは評価不可。OPEはCを採用していたら平均報酬はいくらかを過去ログから反実仮想的に推定する。代償としてpropensity scoreが必須。

Q. IPWとDoubly Robustはどちらを使うべき？
本番ではほぼ常にDoubly Robust。IPWはpropensityが小さい領域で分散が爆発。DRは報酬モデルとpropensityのどちらか一方が正しければ不偏という二重保証を持つ。

Q. CPME (2025, arXiv:2506.02793) を使うべきタイミングは？
平均だけでなく報酬分布のテール・リスクが事業インパクトを左右する場合。全体平均CVRは+5%だがVIP顧客が-20%悪化するケースを、従来のIPW/DRは検出不可。CPMEはRKHS上で報酬分布全体を推定するため、分位点・条件付き分布を直接評価できる。

系統4 : LLMエージェントの自己改善

Q. Self-Refine (arXiv:2303.17651) とReflexion (arXiv:2303.11366) の使い分けは？
Self-Refineは『同じLLMが1出力を反復洗練する』単発タスク向け。Reflexionは『複数試行の失敗を記憶する』マルチエピソード向け。GTMでは単発生成物にSelf-Refine、顧客単位の長期戦略にReflexion。併用可。

Q. Promptbreeder (arXiv:2309.16797) は何アームのGAと等価？
タスクプロンプトと変異プロンプトの2集団を同時進化させるco-evolution構造で、単純GAの2〜5倍の探索効率。集団10〜50、世代20〜100で十分。トークンコストがO(集団×世代)で増える点が最大の運用課題。

Q. LLM自己改善系を本番で暴走させないためには？
3ゲート必須: (1) Static Gate（NG語・PII・虚偽検出）、(2) LLM-as-Judge Gate（別モデルで品質スコア閾値判定）、(3) Human Gate（新テンプレの初回使用は人間レビュー）。この3段を通ったものだけ本番に流す。

系統5 : 進化的コード探索

Q. DGM (arXiv:2505.22954) とAlphaEvolveはどちらを真似るべき？
AlphaEvolveはアルゴリズム発見寄り（Gemini Flash/Proアンサンブル）。DGMはエージェント自身のコードを書き換える自己参照性が特徴で、アーカイブ進化で stepping stones を明示保持。施策コード進化はAlphaEvolve寄り、エージェントアーキテクチャ全体の進化はDGM寄りで設計する。

Q. DGMを本番運用する上での安全機構は？
DGM論文が示す4点: サンドボックス実行、Web／外部API制限、全変更の系譜トラッキング、報酬ハッキング監視。加えて系統3のOPEゲートを最終関門として必ず通す。人間による月次アーカイブキュレーション会を制度化するのが実務上重要。

Q. EvoAgentX (arXiv:2508.07407 参照実装) は何を提供する？
マルチエージェント進化の足場（エージェント定義・進化ループ・評価パイプライン・アーカイブ管理・可視化）。ゼロから数ヶ月の実装が1〜2週間で立ち上がる。

運用全般

Q. fitness関数を何に設定すべきか？
経営KPIに直結する値（CAC / Payback Period / LTV / Activation Rate / Time-to-Activation）に固定。モデル内部指標（Log-Loss, AUC）をfitnessにするとGoodhartの罠に陥る。

Q. 自己進化GTMで最初に失敗するパターンは？
(1) 下位層（L1バンディット+L3 OPE）が不安定なままL5のDGMに手を出して本番を壊す。(2) fitnessに中間指標を使い経営指標と乖離する。(3) ロールバック機構を作らず自動進化を始めてしまう。Crawl/Walk/Runの順序を守ることが最大のリスクヘッジ。

12. 主要参照論文 — 引用プロトコル（arXiv ID 明示）

本稿の主張は以下の一次ソースに基づく。arXiv ID は機械可読な引用識別子として明示する。BibTeXキー相当の短縮記号を併記する。