社内向けチャットボットやAIエージェント機能を、まずVercel AI SDK（AIアプリ構築を支援するTypeScript向けフレームワーク）で試作した経験がある方は多いと思います。プロトタイプ段階では快適でも、本番運用に入った途端に実行時間やコストの壁にぶつかり、「他の選択肢に切り替えるべきか」を迫られる場面が出てきます。この記事では、その判断を業務システムの保守運用という視点から整理します。
Vercel AI SDKは、ストリーミング応答やReactフック（useChatやuseCompletionなど画面側の状態管理を簡略化する部品）、プロバイダー抽象化（OpenAIとAnthropicを1行の変更で切り替えられる仕組み）が強みです。ツール呼び出し（LLMが外部APIや関数を呼び出す機能）の設計も丁寧で、TypeScriptの型定義も厳密です。
ただし前提としてNext.js（Vercel社が開発するReactベースのWebフレームワーク）でのホスティングを強く想定しています。サーバーアクションやルートハンドラーが推奨パターンとされており、Vercel以外でバックエンドを動かそうとすると途端に扱いにくくなります。
どんな場面でこの判断が必要になるか
典型的なのは、社内向けAIエージェントが「長時間タスクを処理するループ」を持つケースです。Vercel Functionsには実行時間の上限があり、Hobbyプランは5分、Proプランでも通常800秒、拡張ベータ利用時でも30分が上限です。問い合わせ対応の1往復なら十分ですが、複数ステップを踏んで調査・要約・生成を繰り返すエージェントには窮屈です。
もう一つの引き金がコストです。Vercelの課金は関数呼び出し回数・GB時間・帯域幅の組み合わせで決まります。AIのストリーミング応答は帯域を消費し、エージェントのループ処理は呼び出し回数を押し上げます。月20ドル程度だった請求が、エージェントループが本格稼働した月に200ドルへ跳ね上がるケースも珍しくないとされています。
業務システムの担当者にとって重要なのは、この上限とコスト構造が「小規模な問い合わせボット」と「継続的に動くバッチ的エージェント」で全く違う意味を持つ点です。まずは自分たちのワークロードがどちら寄りかを見極める必要があります。
判断軸
実行時間の性質が第一の軸です。1リクエストが数秒〜数十秒で完結するチャット型か、それとも複数ステップを経て数分〜数十分かかるエージェント型かを確認してください。後者であればVercel Functionsの実行時間上限が実運用の障害になりやすいです。
チームの主要言語が第二の軸です。バックエンドがPython中心の組織なのか、TypeScript中心の組織なのかで選択肢の相性が変わります。LangChain（Python発の代表的なAI開発フレームワーク）は元々Python向けに設計されており、TypeScript版は常に1バージョン遅れる構造になっています。
ホスティングの自由度が第三の軸です。既存のインフラがAWSやオンプレのVPS（仮想専用サーバー）に寄っているなら、特定プラットフォームへの依存を増やしたくないはずです。Vercelに縛られない構成を選べるかどうかは、既存の運用体制との整合性に直結します。
運用コストの予測可能性が第四の軸です。関数呼び出し課金は使用量に比例して増えるため、トラフィックが読みにくいエージェント機能では予算超過のリスクがあります。固定費のVPSに寄せた方が予算管理しやすい場面もあります。
選択肢の比較
| 選択肢 | 言語基盤 | 得意な用途 | デプロイ先の自由度 |
|---|---|---|---|
| Vercel AI SDK | TypeScript | 短時間のチャット応答 | Vercel前提で低い |
| Mastra | TypeScript | ワークフロー型エージェント | Cloudflare/AWS/VPSなど高い |
| LangChain/LangGraph | Python中心 | 複雑な状態遷移を伴うエージェント | 自社VPSやLangGraph Cloudで高い |
Mastra（Gatsbyの創業者らが開発したTypeScript製エージェントフレームワーク）は、ステップ単位のワークフローエンジンを持ち、リトライや分岐、並列実行を組み込みで扱えます。ツール定義はZod（TypeScript向けのスキーマ検証ライブラリ）でスキーマを書き、型検査がエンドツーエンドで効きます。デプロイ先はCloudflare Workers、Vercel、AWS Lambda、Node対応の任意のホストと幅広いのが特徴です。
LangGraphは、LangChainのエコシステムの中でも新規プロジェクト向けに推奨される入り口です。エージェントの実行をステートマシン（状態遷移の集合として処理を表現する設計手法）として扱うため、複雑な分岐を持つフローでもデバッグしやすくなります。観測性を高めたい場合はLangSmithと組み合わせる構成が一般的です。
ケース別の推奨
社内ツールの延長で、応答が数秒で終わるチャット機能を作っているならVercel AI SDKをそのまま使い続けて問題ありません。実行時間上限にもコスト構造にも当たりにくく、乗り換えのコストの方が高くつきます。
TypeScriptチームが、複数ステップの業務フロー（例えば問い合わせ内容を分類し、関連ドキュメントを検索し、下書きを生成する一連の処理）を自動化したいならMastraが有力です。既存のNode.js資産を活かしつつ、Cloudflare WorkersやVPSへ実行環境を移せます。
小規模VPSで十分動くという点も確認しておく価値があります。参考情報では、netcupのVPS 500 G12（2vCore・メモリ4GB、月額5.91ユーロ）でMastraの本番エージェントが問題なく稼働するとされています。既存のインフラ予算感と照らし合わせる材料になります。
バックエンドが既にPythonで構築されている、あるいはデータサイエンス系のチームと共同で開発しているならLangChain・LangGraphが自然な選択です。自社でPython対応VPSを用意するか、LangGraph Cloudというホスティング製品を使う二択になります。自己ホストの場合、メモリ4GB程度のVPSで多くのワークロードは動くとされ、前述のnetcup VPS 500 G12やDigitalOceanのBasicドロプレット（2GBメモリ・月額12ドル）が出発点として挙げられています。
あえて見送るべき条件
すでにVercelでの運用が安定していて、リクエストが短時間で完結し、月間コストも把握できているなら、乗り換えは見送るべきです。フレームワークの移行にはツール呼び出しの再実装やテストのやり直しが伴い、既存コードベースへの影響は小さくありません。
チームにPythonの運用経験がほとんどないのに、機能面だけでLangChain・LangGraphを選ぶのも避けた方が無難です。型安全性やCI/CD（継続的インテグレーション・デプロイの自動化）の仕組みを一から作り直すコストが発生します。
またエージェントのステップ数が少なく、将来的にも複雑化する見込みが薄い場合は、ワークフローエンジンを持つMastraのような重量級フレームワークを導入する必要は薄いです。既存のVercel AI SDK構成に、時間のかかる処理だけをキューイングして非同期実行する仕組みを足す方が、変更範囲を小さく抑えられます。
まとめ
Vercel AI SDKからの乗り換えを検討する際は、まず自分たちのワークロードが「短時間のチャット型」か「長時間のエージェント型」かを切り分けてください。次にチームの主要言語がTypeScriptかPythonかを確認し、Mastra寄りかLangChain・LangGraph寄りかの方向性を決めます。
具体的な次の一歩として、直近1か月分のVercelの請求明細を確認し、関数呼び出し回数とGB時間の内訳を洗い出すことをおすすめします。それがエージェントループによるものなら、乗り換えの検討タイミングです。あわせて候補フレームワークの公式デプロイガイドで、自社の既存VPSやクラウド環境がサポート対象に含まれているかを確認しておくと、移行判断がしやすくなります。