黄色いレンガの道で死を避ける方法 - アプリレイヤーはまだ死んでいない

• AIアプリレイヤーがOpenAI・Anthropicのような大手ラボに浸食されるという懸念が創業者の間で広がっているが、アプリレイヤーは単一の機会ではなく、「黄色いレンガの道（Yellow Brick Road）」 と 「オズの残りの領域（Rest of Oz）」 に分かれる構造
• 黄色いレンガの道は、コード生成・文章作成・画像生成のように モデル自体の性能向上 だけで品質が改善する水平領域であり、ラボが莫大な資源を投じる経路
• オズの残りの領域は、バーティカル・多段階・多重承認 ワークフローのように、モデル上の スキャフォールディング（scaffolding） が信頼性とコンプライアンスを決める領域であり、スタートアップが顧客を所有できる機会がある
• OpenAI・Anthropicがエンタープライズ向けカスタマイズのための 大規模な forward-deployed 合弁会社 を発表した事実そのものが、一般化されたAIコワーカーだけではすべての問題を解決できないことを示唆している
• 次世代のエンタープライズソフトウェアは 「道の外（off the road）」 で作られるのであり、モデルは置き換え可能でも システム・オブ・ワーク（system of work） はそうではない、という点が中核的な防衛線

---

核心的な問いと前提

• 創業者や入社候補者から繰り返し受ける質問は、「OpenAIとAnthropicがすべてを殺してしまうのか、AIアプリレイヤーにまだ作る余地は残っているのか」
• 一部は、恒久的な下層階級を避けられる場所は 大手ラボの内部、あるいはロボティクスやハードテックのような フロンティア だけだと結論づける
• 筆者はAIマキシマリストの立場から、彼らは「半分は正しい」と評価する。ラボがアプリの表層のかなりの部分を吸収していくのは事実
• ただし重要なのは、アプリレイヤーが単一の機会ではないという点 — 黄色いレンガの道の上なのか、オズの別の場所なのか が正しいフレーミング

The Yellow Brick Road — ラボが歩く道

• 高性能モデルにG Drive、Slack、Salesforce、Notion、GitHubのような off-the-shelf コネクタ を挿し、その上にエージェント・オーケストレーション層を載せるパターン
• このパターンが危険な理由は、ラボが CoworkとCodex ですでに同じことをしているから
  • モデルを所有 → より良いマージン、統制力、ダウンストリームに対する 価格決定力
  • 製品がうまく機能するよう定義された アーキテクチャ上の選択権 を保有 — これまで意図的に「model + tool calls」パターンを採用しており、これは道の上の 水平的で低段階の作業 に正確に適合する
• スタートアップがCodexやClaude Codeを性能で上回ったとしても、ラボは莫大な 流通網 とAI分野最大級の ブランド後光 を持つ
• 同じコネクタの組み合わせ、サブエージェントや構成の不在、流通の不在という状態でこのプレイブックを回すAIアプリ企業は、「どこにも行かない道」にいる

The Rest of Oz — スタートアップの機会

• モデルが ツール・自動化・統合の複雑な網 を通じて編み込まれたエージェント体験を構築する領域で、ほとんどが自然に バーティカル に帰着する
• 水平プラットフォームでは届かない 多段階・多参加者 の作業に集中できる
  • システム全体からコンテキストを収集し、段階ごとの承認が必要な多数の人 にルーティング
  • 1つ以上の レガシーシステム と連携し、決定論的な結果 が必要で曖昧さが許されない
  • 価値あるビジネス成果 と結びついていることが多い
• ラボもこの問題の価値を認識しているため、外注構成組織（outsourced configuration shops） を自ら運営しており、強化学習ビジネスのアップマーケット層 が存在する理由でもある

オズの残りの領域が魔法使いに侵食されない理由

• Data and learning flywheels（データ・学習フライホイール）

  • 学習セットにない 暗黙の業界規範、文書化されていない標準、現場担当者の頭の中にある 部族知（tribal knowledge） は公開ウェブには存在しない
  • 2つのフライホイールが重なって機能する
    • across-customer: 同じ問題のバリエーションを複数顧客で見ながら蓄積されるパターン
    • within-customer: 特定の判断の理由、暗黙の例外、その会社固有の経験則
  • 100件の法務redline、1,000件の保険underwriting、10,000件のSDRキャンペーンを回した企業は、新規参入者が立ち上げたばかりのエージェントでは複製できない 問題の形 を内在化している
  • 水平エージェントが同じ学習インフラを作れない核心的な理由は UX — ワークフロー表面を正確に設計できるのはバーティカルプレイヤーだけ
  • Evalセット、ラベル付き出力、エッジケース分類体系が バーティカル特化データフライホイール として蓄積され、ファインチューニングの燃料になる

• Managing model variability and complexity（モデルの多様性・複雑性の管理）

  • ラボは内部でリクエストごとのモデルルーティングやアンサンブルをすでに行っているが、ベンダー間ルーティング、競合モデルの評価、オープンソースのファインチューニングモデル を狭い領域に投入することはできない
  • Rest of Oz企業は、親会社のラボが出したものだけでなく、モデル市場全体 からサブタスクごとに最適なモデルを選べる
  • アップグレードのたびに evalを再実行 し、顧客のエッジケースに合わせてプロンプトを再調整し、本番を壊さないロールアウトを行うといった「誰もやりたがらない仕事」を引き受ける
  • ラボは次のモデルを売って「移行しろ」と伝えるだけだが、Rest of Oz企業は 移行を吸収 して、顧客に市場全体で最高の知能とアップグレードの連続性を提供する

• Cost optimization（コスト最適化）

  • すべてのクエリを Opus 4.7 で回すのは、売上総利益をマイナスにする最短ルート
  • 優れたRest of Oz企業はモデルを ティア別にルーティング する
    • 最も難しい作業にはフロンティアモデル
    • 大半の作業にはmid-tier
    • 条件を満たす部分には 小型のカスタム・ファインチューニングモデル
  • 一部企業はその上で自前の post-training も行い、顧客が重視する狭いスライスに最適化して、フロンティアAPIの一部コストで提供する
  • ラボが「Xドルで最低限の知能」という 底値 を設定するなら、Rest of Oz企業はその逆、すなわちワークフローが実際に必要とする知能水準に対して 最小ドルコスト を売る

• Governance（ガバナンス）

  • そのバーティカルで顧客がAIを運用する方法の コントロールプレーン になることには大きな価値がある — 権限、監査、エージェントが何をできるか、実際に何をしたかがすべてそこに収束する
  • コントロールプレーンは業界・職務ごとに完全に異なる ユースケース別ガードレール で構成される
  • ツール・ワークフロー・データをエンドツーエンドで所有するため、水平ツールでは難しい 決定論的な結果 を提供できる
  • 最終購買者の代わりに規制の複雑さを引き受ける主体になる
    • 法務: FRCPと弁護士倫理規程
    • 医療: HIPAA
    • 金融: SECとFINRA
    • 保険: 州単位の保険規制など
  • CIOは、自分が提供するエージェントのコンプライアンスを 契約上引き受けるパートナー を求めている

• 共通の結論: フォーカス

  • バーティカル（保険・法務・会計）であれ、深く実行される機能（営業・カスタマーサポート・財務）であれ、単一の顧客集合のワークフロー・エッジケース・規制に献身するチームが必要
  • ラボは全員のためにどこにでも存在しなければならない構造なので、この仕事はできない — 「どこにでもいる」か「1つをうまくやる」かのどちらか

Sales事例 — 11x CEO Prabhav Jainの実践的なヒント

• Focus on outcomes（成果に集中）

  • ラボ耐性のある会社を作る戦術的な道筋は、顧客が本当に気にする 特定の成果 から始めること — 11xでは パイプライン創出
  • 各活動をタスクに分解し、エージェント的なものとそうでないもの、精緻なドメイン洞察が必要なものとそうでないものを区別する
  • 多段階で、入力が雑多で、状態の解釈が難しく、現実世界の制約があるワークフローでは、より良いモデルだけでは不十分で、従来型のソフトウェアエンジニアリング が必要であり、この表面ではラボに優位性はない
  • 11xが扱うタスクの例
    • カスタムシグナルベースのリードprospecting、lead enrichment、deep account research
    • CRMコンテキストフェッチャー、チャネル別メッセージ作成機、リード適格性検証エージェント、メール到達性システム
  • 一般的な学習データにはないドメイン知識を、ワークフローの適切な時点でモデルに注入することがアプリ企業の仕事であり、それは 蓄積されていく
  • スキルはビジネスの進化によって絶えず陳腐化するため、ワークフローとコンテキストを進化させる能力そのものが競争優位になる
    • 例: AI作成メールが登場して以来、ユーザーの感覚は数か月ごとに変化しており、エージェントは市場動態に合わせて継続的に適応しなければならない
    • ここ数か月で positive reply rateが4倍に上昇 し、顧客のために数億ドル規模のパイプラインを創出

• Work on problems where complexity is high（複雑性の高い問題に取り組む）

  • 複雑な問題でこそ本当のビジネス価値が解放され、そうでなければ 薄いラッパー（thin wrapper） になる
  • GTMの例: 「すでに顧客である企業のコンタクトには連絡してはいけない」という単純なルールも、実際には非常に複雑
    • CRMにドメインマッピングがある場合もあれば、数十の子会社を持つ企業もあり、親会社のドメインだけが記録されている場合もあり、Salesforceの古いマッチングフィールドのせいで 現顧客のCROにコールドピッチ が送られる事故も起きうる
  • 現実世界のデータは雑多であり、人間もモデルも魔法のようには解決できない — 問題の具体的な形に合わせて設計された 目的特化エージェント が必要
  • 11xのデータでは、自社データの品質と鮮度が顧客側より高いため、自社データにアンカーする のが基本

• Guardrails — 悪いことを防ぐためではなく、顧客が金を払う本質

  • ガードレールは深刻に過小評価されており、同じ製品内でもユースケースごとに別々に必要
  • 規制の厳しい金融サービスの見込み客とmid-market SaaS顧客では求められる保証が異なり、それはエージェントの書き方、連絡相手、アクセスするデータ、通話での発言、意思決定のログ記録方法にまで及ぶ
  • 画一的なシステムは崩壊し、ユースケース別の設計、顧客別の構成、継続的な監査が必要
  • そのために、顧客要件に合わせて調整する FDE（Forward Deployed Engineer） と技術導入戦略担当を運用している
  • F1000機関の事例
    • 大規模なSMB顧客向けに同意ベースのアウトバウンド音声を実施
    • 初期の反復では応答率が低かったが、通話開始10秒以内にSMB事業主を引き込む方法を素早く学習
    • SMB事業主は大企業B2Bバイヤーや消費者とは異なる行動を取り、現在このセグメントについては顧客企業の営業チーム1か月分を上回る 営業機会を1日で創出 している

Insurance事例 — FurtherAI CEO Aman Gour

• 実際の保険オペレーションにAIを導入しながら繰り返し出会った前提 — 「モデルが知能であり、ワークフローは単なるスキャフォールディングにすぎない」— は、保険会社と仕事をするほど 逆だ と確信するようになった
• 保険では、知能のかなりの部分が ワークフローそのもの に存在する
  • 2社の保険会社が同じ経路（submission → review → quote → bind）をたどっていても、違いはその中身のすべてにある
    • どのリスクが escalation されるのか
    • どの損失シグナルが重要なのか
    • appetiteルール が衝突したとき、どちらが優先されるのか
    • 人間の承認が入るタイミング、外部データ呼び出し、最終判断の文書化方法
  • このロジックは、きれいなルールエンジン1か所にあるのではなく、SOP、マネージャーレビュー、引受哲学、保険会社固有のappetite、長年の運用経験に分散しており、その多くはモデルが読める形で文書化されていない
• 結論は毎回ゼロから推論する 純粋なエージェント でも、現実が雑然としてくると壊れる 硬直したワークフロー でもなく、agentic workflows である
  • ワークフロー → 反復可能性、監査可能性、コスト管理
  • エージェント → 変動性への対処、happy pathが崩れたときの回復
  • ヒューマン・イン・ザ・ループ → 責任が重要な判断コール
• Day 1では手作業の自動化にすぎないが、時間がたつにつれて、あらゆるescalationがシグナルとなり、例外がフィードバックとなり、人間の修正がランブックの抜けを示す信号となって、ワークフローは 保険会社の運用記憶（operating memory） へと進化する
• ラボはより良いモデルとより良い汎用エージェントを出し続けるだろうが、どのアカウントがescalationされたのか、どのリスクが拒否されたのか、アンダーライターがappetiteガイドを覆して正しかった理由は、保険会社の本番環境の中に十分長く留まらなければ学習できない
• 「Day 1で出したワークフローが堀なのではなく、本番利用が時間をかけて作る ループ が堀なのだ」

オズの残りの領域に属するかを判定する3つのテスト

• The tools-and-steps test（ツール・ステップテスト）

  • その作業はいくつの段階を経て、支援ツールはどれほど複雑か
  • 比較
    • 水平AI検索（Google Drive横断）: 1ステップ、1ツール、結果には寛容 — 間違っていれば聞き直せばよい
    • 法務redline（3年分の事務所先例との照合）: 数十ステップ、多数のツール、パートナーのレビューを通過しなければならず、法廷で争われる可能性もある出力
  • どちらも「エージェントが働いている様子」ではあるが、フォーカスしたチームが数年かけて作る深いソフトウェア を要するのは片方だけ

• The system test（システムテスト）

  • 顧客は自分の仕事を 通すシステム を作っているのか、それとも既存システムの上に載るツールなのか
  • システムはデータ取得、ガバナンス、実行記録をエンドツーエンドで所有し、顧客が「実際の仕事が起きる場所」として指し示す対象
  • ツールは顧客がすでに運用しているワークフローに知能を加えるだけで、売上は立つが ラボが奪える 領域
  • 高いACV はシステムのシグナルであることが多いが保証ではない — ラボが直接競合製品を出しても、顧客が依然としてあなたのツールを必要とするかが判定基準

• The hedge fund / P&L test（ヘッジファンド / P&Lテスト）

  • ラボの成果はベンチマークで、Rest of Ozの成果は 顧客のP&L で評価される
  • 顧客は SWE-Bench・MMLU のスコアに興味はない — エージェントが案件を成約させたか、契約を正しくredlineしたか、適切なポリシーをbindしたかを見る
  • ワークフロー特化の結果に執着する顧客なら Rest of Oz、一般能力にお金を払う顧客なら ClaudeやCodexのseatで十分
  • 最高のエージェントビジネスは、ヘッジファンドのように 顧客のP&Lで測られるアルファ で勝負しなければならない

両方とも勝てる

• 黄色いレンガの道の上でも巨大な勝者は出る — ラボはモデルを所有し、自ら設計した水平ツールの流通も所有している
• Rest of Ozの勝利条件は system of work の所有 — 企業の仕事が実際に実行され、データが取得される表面
  • データ取得、ワークフローのアクションシステム、ガバナンスを所有する
  • バーティカルにおける複雑なワークフローが成熟するほど、顧客が依存する1つの 中核体験 に凝縮される
  • 新旧のモデル世代がリリースされるたびに、企業はそれらを統合・提供するレイヤーになる
  • モデルはその下で 代替可能（fungible） だが、system of workはそうではない
• 次世代のエンタープライズソフトウェアは 「道の外」 で作られる