本番でMastraが重要な理由

Mastra は、AI 搭載アプリケーションとエージェントを構築するためのオープンソース TypeScript フレームワークだ。公式の位置づけは単なるエージェントラッパーよりかなり広い。エージェント、ツール、MCP、メモリ、ワークフロー、RAG、評価、ベクターストア、データセットまで一つのスタックに含まれている。つまり、1回のプロンプトを包む道具ではなく、製品の中で実際に動く AI システムの土台に近い。

2026年に入って、その意味はさらに強くなった。2026年1月20日の Mastra 1.0 では、AI SDK v6 対応、サーバーアダプター、thread cloning、composite storage が追加された。続く2026年2月9日には、observational memory が安定したコンテキストウィンドウを実現すると説明された。さらに2026年4月1日には、各実行の duration、token usage、estimated cost を自動で記録する metrics と logs が入った。

これはおもちゃではなく、本番向けのスタックだ。

軽いラッパーより向いている場面

Mastra は、単一のモデル呼び出しと少しのヘルパー関数だけでは足りないときに強い。

単純なプロンプト補助だけなら、より軽いラッパーの方が安い。だが、メモリ、ワークフロー、評価、運用可視性が必要なら、Mastra の方がずっと合っている。

メモリとコンテキストは中核機能

Mastra で最も分かりやすい強みは observational memory だ。2026年2月9日の発表では、複数ターンにわたって prompt cache に乗せやすい、安定したコンテキストウィンドウを持つメモリシステムとして説明されている。毎回動的に検索した断片をプロンプトへ差し戻すのではなく、予測しやすい observation log を保ち、会話の生データを compact な observation に変換していく。

これが重要なのは、長い会話がたいてい次のどちらかで壊れるからだ。

• コンテキストウィンドウが大きくなりすぎて、高くて不安定になる
• 検索の量が多すぎるか少なすぎるかで、動作が予測しづらくなる

Observational memory はこの二つを減らすために作られている。次のような用途に向いている。

• 長く使われるサポートアシスタント
• 営業やアカウント向けのコパイロット
• ユーザー履歴が繰り返し参照されるリサーチエージェント
• コンテキストの形が変わると性能が落ちるアシスタント

実務上の教訓は単純だ。メモリが製品要件になるなら、明示的で、測定できて、キャッシュに優しいメモリシステムが必要になる。

ワークフローとストレージは切り離せない

Mastra 1.0 でワークフローの話はより本番向けになった。2026年1月20日のリリースで、AI SDK v6 対応、サーバーアダプター、thread cloning、composite storage が追加された。特に composite storage は重要で、memory、workflows、scores、observability を一つのストレージに無理やりまとめず、ドメインごとに適切なバックエンドを選べる。

実際のチームでは、すべてのサブシステムが同じストレージ戦略を望むわけではない。

• memory は軽量ストレージの方がよいことがある
• workflows はトランザクション指向のデータベースに向くことがある
• observability は分析向けストレージが向くことがある

Mastra のサーバーアダプターも重要だ。すでに Express, Hono, Fastify, Koa 上でアプリを動かしているなら、エージェント導入のためにランタイム全体を作り直す必要がない。段階的に導入しやすくなる。

可観測性が採用理由になる

Mastra は可観測性をおまけ扱いしない。公式の observability ページは、エージェントとワークフロー向けの first-class logging, tracing, evals をうたっている。

2026年4月1日の時点では、Mastra Studio がすべての agent run, tool call, workflow, model invocation に対して duration, token usage, estimated cost を自動で収集する。これは運用上とても大きい。動作とコストを同じ画面で見られるからだ。

実務では次の問いに答えやすくなる。

• どのワークフロー段階が遅いのか
• どのツール呼び出しが高いのか
• どのエージェント経路のスコアが最も良いのか
• コスト急増はどこから始まったのか
• 変更が品質を上げたのか、それともトークン配置を変えただけなのか

AI 機能がデモから実ユーザーへ移るとき、この可視性は必須になる。

MCP とツールはプラットフォームの一部

Mastra の公式ポジションには、エージェント、ツール、MCP が同じスタックとして含まれている。エージェント文書も、memory、tool calling、MCP、logging、tracing、eval primitives を備えた stateful agent プラットフォームとして説明している。

重要なのは、実運用のエージェントはモデルだけでは足りないことだ。

• 内部ツールが必要
• 外部サービスが必要
• 安全な実行境界が必要
• 承認と追跡が必要

Mastra はそれらをプラットフォームの一部として扱うので、各チームが毎回ゼロから作る負担を減らせる。

1.0 以後のメモリ戦略

2026年2月9日の observational memory の発表は、独立して見る価値がある。核となる考え方は安定したコンテキストウィンドウだ。

毎ターン動的に検索結果を差し込む代わりに、observation 中心の予測可能な履歴を保つ。これで latency と信頼性の両方が改善する。

prompt caching が重要なときにも効く。コンテキスト形状が安定していればキャッシュ効率が上がり、append-only に近い性質ならプロンプトの変動も減る。

つまり、コンテキスト膨張がコスト問題になっている製品ほど、Mastra のメモリ設計は魅力的だ。

実践ロールアウトチェックリスト

Mastra を一つのエージェントデモ以上に広げる前に、次を確認しよう。

1. ビジネス上意味のあるワークフローを一つ選ぶ。
2. 最初の版でメモリが必要か、単純な状態だけで足りるかを決める。
3. 各 storage ドメインをどこに置くか決める。
4. 本番試験の段階から logging, tracing, evals を有効にする。
5. プロンプト調整の前に評価データセットを作る。
6. 許可する MCP サーバーと監視方法を決める。
7. 実履歴を書き換えたくない場合は thread cloning を使う。
8. duration, token usage, estimated cost を標準メトリクスとして見る。
9. モデルルーティングルールを決め、アプリを書き直さずにモデルを変えられるようにする。
10. ワークフローやツール呼び出しが途中で失敗したときの挙動を試す。

よくある失敗

最大の失敗は、メモリを無制限のチャット履歴として扱うことだ。そうするとコンテキストウィンドウはすぐに雑で高価になる。

ほかにもよくある失敗がある。

• 最初のリリースが終わるまで評価を後回しにする
• すべてを一つのストレージに入れる
• ログとトレースを運用計画なしで混ぜる
• 何でもマルチエージェントで解こうとする
• 製品がすでに高くなってから token cost を見始める

Mastra は、エージェントをプロンプト実験ではなく実際のランタイムシステムとして扱うときに最も強い。

実務上の結論

Mastra は、AI アプリケーションとエージェントのためのオープンソース TypeScript プラットフォームを求めるチームに向いている。メモリ、ワークフロー、可観測性、評価、MCP、そして導入しやすいアダプターが揃っているからこそ、プロダクション向けに感じられる。

モデル呼び出しを少し包みたいだけなら、もっと軽い道具で十分だろう。だが、実際に運用し、測定し、拡張できる TypeScript エージェントスタックが必要なら、Mastra はそのために作られている。

References

• Mastra home
• Mastra pricing and framework overview
• Mastra 1.0 changelog
• Mastra observational memory
• Mastra observability
• Mastra metrics and logs