Mastra AI フレームワーク・レビュー：本音の評価

訳者注: この記事はAI翻訳ベースで、Jim Liu（シドニーの個人開発者）が用語と文章の自然さを校閲しました。誤訳や不自然な表現があれば、メールでご指摘ください。原文（英語）: English.

TL;DR — 30秒で理解するMastra

Mastraは、Gatsbyのコアチームによって構築されたTypeScriptネイティブのAIエージェントフレームワークです。エージェント、ワークフロー、RAG、メモリ、そして「Mastra Studio」という強力な視覚的デバッグツールがパッケージ化されています。私の検証では、同様のプロダクション向けタスクにおいて、LangChainでは構築に約41時間かかったのに対し、Mastraでは約18時間で完了しました。タスク完了率はLangChainの87.4%に対し、Mastraは94.2%を記録。GitHubスター数は22,000超、週間npmダウンロード数は30万件を超え、Y Combinatorのバックアップも受けています。「PythonのオーバーヘッドなしでAIエージェントをTypeScriptで書きたい」のであれば、現時点でMastraは最強の選択肢です。唯一の難点は、エコシステムがまだ若く、サードパーティのチュートリアルが少ないことです。

---

Mastraが実際に提供するもの

Mastraは、単なるラッパーではなく、TypeScriptでAIエージェントを構築するための**プリミティブ（基本要素）**を提供します：

• エージェント (Agents): ツール呼び出し（Tool-calling）、メモリ、構造化出力に対応
• ワークフロー (Workflows): 分岐、条件、リトライ、ヒューマン・イン・ザ・ループ（人間による承認）ステップを統合
• RAG: ベクトルデータベース（Pinecone、pgvector、Qdrant）との標準統合
• メモリ (Memory): スレッドベースのモデルにより、会話をまたいで永続化
• インテグレーション: GitHub、Slack、Googleなど、豊富なプリセットコネクタ
• Mastra Studio: エージェントのテストやトレースの確認ができるローカルWeb UI
• OpenTelemetry: 標準搭載されており、初日からオブザーバビリティ（観測性）を確保

Node.js上で動作し、Vercel、Cloudflare Workers、Netlifyなどへコマンド一つでデプロイ可能です。DockerもPythonの仮想環境も、既存のWebスタックとの依存関係の衝突も心配ありません。

ビルドシステムに長年携わってきたGatsbyチームが開発しただけあり、設定やエラーメッセージ周りの開発者体験（DX）は、他のAIフレームワークよりも明らかに洗練されています。

最初のエージェントを構築する

Webを検索し、調査結果を要約して保存するリサーチ・エージェントを構築しました。以下はその最小限の構成です：

import { Agent } from '@mastra/core';
import { searchTool, saveTool } from './tools';

const researcher = new Agent({
  name: 'researcher',
  instructions: 'トピックを調査し、構造化された要約を保存してください。',
  model: { provider: 'ANTHROPIC', name: 'claude-sonnet-4-20250514' },
  tools: { searchTool, saveTool },
});

const result = await researcher.generate(
  'TypeScript AIフレームワークの最新ベンチマークを調べてください'
);

これだけです。チェインの設定やグラフの定義、エグゼキューターのボイラープレートは不要です。エージェントが自律的にツールの呼び出し順序を判断します。

プロトタイプの完成までにかかった時間は約3時間。その大半は（Zodスキーマを用いた）ツール定義の記述でした。エージェント自体の設定はわずか15分程度です。LangGraphでグラフのトポロジー（構造）を整えるだけで午後を丸ごと潰していた経験と比較すると、開発体験の次元が違います。

特筆すべきはMastra Studioです。エージェントの実行をリプレイし、各ツールの呼び出しやトークン使用量を確認できます。コンソールログを追いかける代わりに、わずか10分でプロンプトの問題を特定できました。

Mastra vs LangGraph vs CrewAI

同じタスク（データの取得、処理、構造化レポートの作成）を3つのフレームワークで実行し、比較しました。

機能	Mastra	LangGraph	CrewAI
言語	TypeScript	Python	Python
アーキテクチャ	Agent + Workflow プリミティブ	グラフベースの状態マシン	役割ベースのマルチエージェント
GitHub スター数	22K+	LangChainの一部 (98K+)	25K+
週間ダウンロード数	約30万 (npm)	約617万 (PyPI, LangGraph)	約45万 (PyPI)
タスク完了率	94.2%	87.4%	約89% (コミュニティ指標)
P95 レイテンシ	1,240ms	2,450ms	約2,100ms
エラー率	5.8%	8.9%	約7.5%
導入時間 (本番用)	約18時間	約41時間	約28時間
組み込み RAG	あり	LangChain経由	あり (基本機能)
可視化デバッガー	Mastra Studio	LangSmith (有料)	なし (標準)
デプロイ先	Vercel / CF Workers / Netlify	LangGraph Cloud / セルフホスト	セルフホスト
オブザーバビリティ	OpenTelemetry 標準搭載	LangSmith	手動設定

最大の驚きはP95レイテンシの違いでした。Mastraの1,240msに対し、LangGraphは2,450msと約2倍の差があり、インタラクティブなテスト中にもその差を肌で感じました。これはTypeScriptのイベントループとPythonの非同期処理の差、そして抽象化によるオーバーヘッドの少なさが影響しています。

ただし、エコシステムの広さでは依然としてLangGraphが勝っています。週間617万ダウンロードという数字は、Stack Overflowでの回答数、ブログ記事、本番事例の多さに直結します。チームがすでにPythonのMLツールに深く習熟している場合、エージェントのためだけにMastraへ切り替える合理性は低いかもしれません。

CrewAIはその中間です。「マネージャー、リサーチ、ライター」といった役割のメタファーは直感的ですが、問題が発生した際に個別の挙動をカスタマイズするのが難しいと感じました。

Mastraのここが良い

至る所に型安全性がある。 ツールの入力と出力はZodで検証されます。スキーマに間違いがあれば、どのフィールドがなぜ失敗したかをエラーが正確に教えてくれます。LangChainでは、同様のエラーがPythonの深いトレースバックとして現れることが多く、特定に苦労します。

コマンド一つでデプロイ。 npx mastra deploy を実行するだけで、約90秒でVercelにデプロイされました。DockerfileもCIパイプラインも不要です。プロトタイプや小規模なプロダクション環境において、デプロイの手間が省けるのは大きな利点です。

Mastra Studioが本当に使える。 AIフレームワークの「プレイグラウンド」はデモ用の玩具に過ぎないことが多いですが、Studioは実用的です。エージェントが要約ステップに進まず検索を繰り返してしまう「ツール呼び出しのループ」をStudioで発見し、リアルタイムで指示を修正できました。

複雑なワークフローも扱える。 分岐、並列ステップ、指数バックオフ付きのリトライ、人間による承認ゲート。これらをすべて備えたコンテンツパイプラインを約200行で構築できました。LangGraphで同等のものを作ると500行を超え、よりグラフ理論的な思考が求められます。

AIエージェント・システムを構築する場合、Mastraのワークフローエンジンは、マルチステップのオーケストレーションを最小限のコードで実現します。

惜しい点・不満な点

ドキュメントの不足。 スタートアップガイドは充実していますが、一歩踏み込んだ使い方をしようとするとソースコードを読み解く必要があります。pgvectorを使用したメモリの永続化設定には45分かかりました。ドキュメントにはメモリ内保存（デフォルト）の例しかなかったからです。

プラグインエコシステムが小さい。 LangChainには数百のインテグレーションがありますが、Mastraはまだ50〜60程度です。特定のCRMやデータウェアハウスなどのニッチなコネクタが必要な場合、自分で作成する必要があります。

破壊的変更がまだある。 v0.3からv0.4の間でワークフローAPIが大幅に変更され、移行作業が必要になりました。プロダクションでの利用を促すのであれば、この点は懸念材料です。v1.0でのAPI安定化が待たれます。

「TypeScript専用」が仇になることも。 Pythonのノートブックで思考するMLエンジニアは直接貢献しにくいです。組織内に既存のPython AIインフラがある場合、言語の境界が連携コストを生む可能性があります。

エラーリカバリが基本的。 ツール呼び出しが失敗した際のデフォルトの挙動はリトライかスキップです。「ツールAが失敗したら、異なるパラメータでツールBを試す」といったカスタムフォールバックロジックを記述する際、期待したほどスマートな書き方はできませんでした。

Mastraを使うべき人・見送るべき人

使うべきケース：

• スタックがTypeScript/Node.js中心で、Pythonを混ぜたくない
• インフラの手間をかけずにWebアプリ（Next.js, Express, Hono）にAIエージェントを組み込みたい
• 開発スピードを最優先する小規模チーム（1〜5人）
• 別途料金を払わずに標準のオブザーバビリティを確保したい

見送るべきケース：

• チームがPython第一で、すでにLangChainやLangGraphの資産がある
• 100種類以上のインテグレーションが最初から必要
• Pythonの科学計算エコシステムが不可欠な、リサーチ中心のMLパイプライン
• v1.0前のAPI変更を許容できないプロダクション環境

AI搭載のWebアプリケーションを構築する際、Mastraのようなフレームワークと併せて、MCPやA2Aプロトコルの比較などのエージェント間通信の仕組みを理解しておくと、システム設計の柔軟性がさらに高まります。

FAQ

関連記事: 私は金融リサーチ・エージェント AlphaGainDaily も運営しています。ターゲットは開発ワークフローではなく市場データですが、活用しているエージェントの仕組みはMastraと同様のパターンに基づいています。

---

日本のエンジニア視点で補足

国内のTypeScriptエンジニアの間では、LangChain JSのラッパー的な複雑さに疲弊し、より軽量で型安全なフレームワークを求める声がZenn等で目立ち始めています。MastraはVercel AI SDK等と組み合わせて、LINEや国内SaaSとの連携を構築する実務的なエージェント開発に非常に適しています。まだ日本語ドキュメントは少ないですが、DifyのようなGUIベースのツールからコードベースの自由度を求める移行先として、今後Qiita等で技術記事が急増する気配を感じます。