この事例に注目すべき理由
Delphiは、創業エンジニアのSpencer Schoeben氏を含む10人のエンジニアで構成されるチームです。インフラ専任のロールは一人もいません。それでもプロダクトとデザインのメンバーを含む全員がコードをデプロイし、1日100回以上の本番デプロイをfeature flagの裏側で回しています。
背景にあるのは、「デジタルマインド」という新しいカテゴリを切り開く会社である以上、ユーザーの要求が極めて速く変わるという事情です。だからこそ開発者体験（DX）とエージェント体験（AX）が生存条件になります。Spencer氏の言葉を借りれば、「勝つためには優れた開発者・エージェント体験が必要で、そうでなければユーザー要求の速度に適応できない」というわけです。
特に注目したいのは、6か月前にPythonバックエンドまでVercelへ移行した点です。フロントエンドは当初からVercelでしたが、バックエンドはAWS ECS・Docker Desktop・ローカルDBの組み合わせで「悪夢」だったといいます。本記事では、この移行から得られる実務的な教訓を整理します。
問題の本質は「インフラの所有」だった
初期はチームが小さく、AWSベースの構成でも何とか回っていました。問題はチームが拡大するにつれ、新しいエンジニアが最初のデプロイに到達するまで丸一日かかるようになったことです。コンテキストが人の頭の中にしかないため、オンボーディングが遅くなるのは必然でした。
AWS内でこの問題を修正することも可能でしたが、そのためにはインフラを自ら設計・所有する必要がありました。Delphiは**「インフラは当社の目標ではない」と線を引きました。そこで選んだのがバックエンドのVercel移行です。結果として、新しいエンジニアは既存チームと同一のデプロイワークフロー**で本番まで到達できるようになりました。
WorkflowsとQueuesが移行を可能にした
Delphiのバックエンドは長時間実行される処理とキュー駆動のバックグラウンドジョブに依存しています。デジタルマインドはコンテンツを事前生成するdurable agentを必要とし、書籍や講演を知識グラフへ変換するingestionパイプラインも動かさなければなりません。
ここで決定的だったのがVercel WorkflowsとQueuesです。どちらもセットアップが不要です。開発者がコードベースに関数としてワークフローやキューハンドラを書けば、デプロイ時にVercelが必要なリソースを自動でプロビジョニングします。
# 例: Vercel Workflowsで長時間実行のingestion処理を定義
# (概念説明用の擬似コード - 実際のAPIは公式ドキュメントを参照)
from vercel.workflows import workflow, step
@workflow()
def ingest_knowledge_source(source_id: str):
# ステップ1: 元データの読み込み
raw = load_source(source_id)
# ステップ2: 知識グラフへの変換（時間のかかる処理）
graph = build_knowledge_graph(raw)
# ステップ3: ベクトルインデックス作成
index_graph(graph)
return {"status": "done", "source_id": source_id}
# キューハンドラも関数ひとつで完結
from vercel.queues import queue_handler
@queue_handler("content-generation")
def generate_content(job):
mind_id = job["mind_id"]
draft = run_agent(mind_id)
save_draft(mind_id, draft)
この構造の本当の利点は、**「インフラをほとんど意識しなくてよい」**ことです。Spencer氏の表現をそのまま引けば、「Vercelではインフラについてほとんど考えない」とのことです。
ステージングを飛ばして本番へ直行
バックエンドをVercelへ移したことで、Delphiはバックエンド変更を**「重いリリース」ではなく日常的なプロダクト作業」として再定義しました。以前はstaging → productionの順でしたが、現在は中間ステップを省略し、feature flagの裏で1日100回以上デプロイします。変更をリリース単位でまとめる代わりにA/Bテスト**で検証する方式です。
この速度を維持するには可観測性が不可欠ですが、Vercel Agentの異常検知（anomaly detection）が本番をリアルタイムに監視し、問題が起きれば何がなぜおかしいのかをフラグしてくれます。Spencer氏によれば、以前なら気づけなかった問題も多かったといいます。
高速デプロイは、優先リストに載らなかった小さな実験を消化するのにも役立ちました。訪問者を「owner」（マインドと対話しに来て、自分のマインドを作って帰る人）へ転換する実験が代表例です。デプロイはエンジニア専売ではなく、CPOやグロースチームが自分でダッシュボード・プロトタイプ・実験を作ってデプロイしているそうです。以前の構成では考えられなかったことです。
なお、この「ステージング省略 + feature flag + 可観測性」の組み合わせは、リリース自動化ダッシュボードの設計とも通じます。あわせて読みたい記事: Spotifyアプリリリースの舞台裏 — ダッシュボード設計と自動化の教訓
エージェントを第一級市民にするインフラ
Delphiの開発スタイルで最も興味深いのは、「ローカルでほとんど開発しない」という点です。エンジニアは問題をクラウドエージェントに渡し、エージェントが何を作ったかはプレビューデプロイで初めて確認します。
Vercelのプレビューデプロイはpushごとに固有のライブURLを発行します。そのためブランチをpullしなくても、スマホやSlackスレッドから結果をすぐ確認できます。これは人間にも便利ですが、エージェントの自己検証ループを可能にする中核装置でもあります。
| 項目 | 従来のAWS構成 | Vercel移行後 |
|---|---|---|
| 新規エンジニアの初回デプロイ | 約1日（環境構築） | 既存ワークフローで即時 |
| デプロイ頻度 | staging → prodのバッチリリース | 1日100回+（feature flag） |
| バックグラウンドジョブ | ECS/キューを自前運用 | Workflows・Queuesで自動プロビジョニング |
| エージェント検証 | ローカル/手動確認 | プレビューURLで確認 |
| モデルルーティング | 提供元と直接fallback交渉 | AI Gatewayで即時ルーティング・failover |
| 非エンジニアのデプロイ | 事実上不可 | CPO・グロースチームも直接デプロイ |
Spencer氏の表現が印象的です。「以前のインフラではAIの速度に追いつけなかった。人間が8時間かかる作業なら、エージェントは諦めていただろう」とのこと。エージェントが失敗する理由は多くの場合必要な情報にアクセスできないことであり、VercelはSDK・MCP・CLIを通じてログ閲覧、デプロイ検査、環境変数変更といった制御権をエージェントに開放します。つまりプラットフォームは人間と同じくらいエージェントにも易しくなければならないという前提で設計されているわけです。
Sandbox上の内部エージェント
Delphiは自社エージェントもVercel上で動かしています。その一つがVercel Sandbox上の内部エージェントで、カスタマーサクセスチームがSlackで問い合わせるとコードベースを調査し、根本原因と修正案をエンジニアに引き渡します。以前はエッジケースが見落とされがちでしたが、今はSlackで聞けば済む構造です。
Sandboxはファイルシステムを備えた隔離環境を提供し、エージェントがコードベースをチェックアウトして実行し、必要なデータを引き込めるようにします。エージェントフレームワークはVercelのeveで構築しましたが、最初のバージョンはホスティング型エージェントプラットフォームだったため、そのプラットフォームが提供する連携しか使えなかったそうです。eveではツールがDelphiの書くコードそのものであるため、存在しないツールが必要になればチームが直接追加できます。
AI Gatewayでマインドごとにモデルを選択
DelphiのチャットトラフィックはAI Gatewayを通ります。デジタルマインドごとに特性が異なり、あるモデルではより良い出力が得られる場合があるためです。そこで顧客ごとにモデルを選び、自社のeval結果に応じて調整します。新しいモデルが出れば（オープンソースかどうかを問わず）当日中にルーティングできます。
Gatewayはfailoverも担います。以前はモデル提供元と直接、他クラウドのfallback容量を調整する必要があり困難でしたが、今は「fallbackが存在するなら必ず受け取れる」という確信が持てるといいます。
注意点と限界
この事例をそのまま一般化するのは難しいです。いくつか押さえておくべき点があります。
- ワークロードの適合性: Delphiは長時間実行エージェントやキュー駆動ジョブが中核であるため、Vercelのマネージド抽象化がよく適合しました。しかしカスタムネットワーキング、特殊ランタイム、規制上インフラ所有が必要なケースでは逆に制約になり得ます。
- ベンダーロックイン: Workflows・Queues・AI Gateway・Sandbox・eveまでスタックが深く結合すると、移行コストは下がる一方でプラットフォーム依存度は高まります。抽象化の境界をコードレベルで管理しておくのが安全です。
- 可観測性は自動ではない: 異常検知は助けになりますが、1日100回デプロイ環境ではfeature flagの衛生管理、カナリア戦略、ロールバック自動化をチーム規律として必ず整える必要があります。
- エージェントのセキュリティ: エージェントがログ・環境変数・デプロイにアクセスするということは、権限設計がすなわちセキュリティ境界だということです。Sandboxの隔離と最小権限原則を初期から設計すべきです。
まとめ: 「インフラを所有しない」戦略の実体
Delphiの事例の教訓は、単に「Vercelを使えば速くなる」ということではありません。何を所有しないかを明確に決め、その判断を開発者体験とエージェント体験という二つの軸で検証した点が核心です。
- オンボーディング時間を指標にする: 新規エンジニアの初回デプロイまでの時間は、組織の拡張性を示す先行指標です。
- ステージングを惰性で維持しない: feature flagと可観測性が整っていれば、バッチリリースより小さな実験の連続の方が速い場合があります。
- エージェントのためにプラットフォームを設計する: プレビューURL、CLI、MCPといったインターフェースがエージェントの自己検証ループを作ります。
- モデルは固定資産ではない: AI Gatewayのようなルーティング層を置けば、モデル差し替えコストが激減します。
次のステップ学習の方向性
- Vercel Workflows / Queuesの公式ドキュメントでdurable executionパターンを実際に試してみてください。
- Feature flagベースのトランク開発とカナリアデプロイ戦略をチームのワークフローに合わせて設計しましょう。
- MCP（Model Context Protocol） を活用し、社内エージェントにログ・デプロイ制御権限を安全に付与する方法を学びましょう。
- エージェント駆動開発の流れをより広く捉えたい方は、あわせて読みたい記事: Conductor、拡張からプラグインへ進化 — Spec-Driven Developmentの次の段階を完全整理
本記事はVercel公式ブログのDelphi事例を基に、国内開発環境の観点からの解釈と注意点を加えて再構成したものです。