TypeScriptのエージェント基盤にMastraを選んだ理由
いま開発している4つ目の自社エージェント基盤には、Mastra を使うことにしました。既存のコードが TypeScript で書かれていることと、以前に自作した機能の多くを Mastra に任せられることが理由です。
Mastra は、7月に3つ目の基盤を作ったときにも候補に入っていました。そのときは保留しましたが、今回は採用しています。
本番での採用実績や解説記事の数では、LangGraph が先行しています。それでも今回の基盤には Mastra が合うと判断した経緯を書きます。開発連載の第1回です。4つの実装方式の比較は、第0回のAIエージェントの実装方式は4種類あるを参照してください。
自作しないと決めた範囲
ループやワークフローを自作しないことは、比較の前に決めていました。第0回では、その層自体が製品価値になるかを基準に、実装方式を分けています。
今回の商品は、基盤の上に載るサービスです。エージェントのループ（モデルを呼び、ツールを実行し、結果をまたモデルに渡す繰り返し）やワークフローは、既存のフレームワークに任せます。これらの汎用機能を自社で作り、保守し続ける必要はないと考えました。
候補は次の4つです。
| 候補 | 第0回の方式 | 位置づけ |
|---|---|---|
| Mastra | 方式D（統合フレームワーク） | TypeScript のエージェントフレームワーク |
| LangGraph | 方式D（統合フレームワーク） | Python 版が主力のエージェントフレームワーク |
| Claude Agent SDK | 方式B（ベンダー公式 SDK） | 2つ目の基盤で使った方式 |
| Vercel AI SDK と LLM ゲートウェイの組み合わせ | 方式C（オープンな部品で自作） | 3つ目の基盤で使った方式 |
既存の型定義を共有する
私たちは、入出力の型を zod（TypeScript で型と入力検証を一度に定義するライブラリ）のスキーマで定義し、フロントエンドとエージェント側で共有しています。Python のフレームワークを選ぶと、エージェント側だけ型定義を別に書き、仕様変更を2つの言語で追い続けることになります。今回も TypeScript で組むのは、この二重管理を避けるためです。
既存の型定義や開発の仕組みが Python で書かれているなら、LangGraph は有力な選択肢です。ただ、LangGraph の利用の中心は Python 版にあり、TypeScript 版とは規模が異なります。
2026年10月2日に取得した数字で比べると、次のようになります。
| 対象 | GitHub スター | 直近1か月のダウンロード |
|---|---|---|
| LangGraph（Python 版） | 42,600 | 43,651,931（PyPI） |
| LangGraph.js（TypeScript 版） | 3,332 | 14,091,296（npm） |
Mastra（@mastra/core） | 28,496 | 7,054,478（npm） |
npm の期間は 2026年9月1日〜30日です。PyPI の値は集計サービス pypistats.org の値で、期間が少しずれます。
スター数では、LangGraph の Python 版は TypeScript 版の約13倍あります。TypeScript どうしで比べると、Mastra のスター数は LangGraph.js の約8.5倍です。
一方で、npm のダウンロード数は LangGraph.js が Mastra の約2倍あります。ただし、npm の langchain パッケージは LangGraph.js に依存しているため、この数には langchain を入れただけの利用も含まれます。npm の統計からは、LangGraph.js を目的に選んで使っている数を切り分けられません。
スター数もダウンロード数も、利用者数そのものではありません。私たちは、これらの数字から TypeScript での候補として Mastra を有力と見ました。
伸び方も判断材料にしました。Mastra は 2026年1月20日に 1.0 を出し、10月時点で 1.74 まで進んでいます。npm の週間ダウンロードは、2026年8月上旬の約134万から、9月末の約215万に増えました。日本語でも、2026年7月に技術評論社から Mastra を主題にした入門書『MastraによるAIエージェント開発・運用［実践入門］』が出ています。
自作機能と Mastra の対応
3つ目の基盤では、モデル切り替え、中断と再開、スキル、会話メモリを自作しました。今回それぞれを Mastra に任せられるか、2026年10月2日に Mastra 1.74.0 に同梱されたドキュメントで確かめました。
| 機能 | 3つ目の基盤 | 4つ目の基盤 |
|---|---|---|
| モデル切り替え | LLM ゲートウェイの上に自作 | Mastra に任せる。「プロバイダ名/モデル名」の文字列を渡すと、呼び出し先を切り替える |
| 中断と再開 | 自作 | Mastra に任せる。ワークフローが実行状態を保存して止まり、人の入力を受け取って続きから動く |
| スキルとサブエージェント | 自作 | Mastra に任せる。リクエストごとに渡すスキルを決める関数を書ける |
| 会話メモリと検索 | 自作 | Mastra に任せる。会話履歴とベクトル検索を Postgres に置く |
| 処理の分岐の判断 | （比較対象外） | Mastra に任せる。TypeSafe AI が2026年9月に公開した、文章を書かずに判断だけを返す AI モデル Jev を、分岐の判定役として標準で組み込める |
| 利用量の記録 | コスト計測と監査ログを自作 | 自作する |
| 製品固有の機能 | （比較対象外） | 自作する |
自作に残るのは、利用量の記録と、製品の機能そのものにあたる部分だけです。利用量の記録とは、モデルを呼び出すたびに使ったトークン数（モデルが処理した文字量の単位）を1行ずつデータベースに保存する処理で、原価の切り分けや請求の根拠は後から復元できないため、初日から自分のコードで持ちます。
7月の保留と今回の採用
3つ目の基盤でも、2026年7月にループの実装方式を比較し、記録を残していました。そのときは Vercel AI SDK を採り、Mastra は「長時間の承認待ちや再開が増えたら候補にする」と保留しています。
当時は、ループの外側の責務をすべて自分のコードで持ちたかったからです。実行計画、ツール実行前の許可判定、実行状態の保存、監査ログ、コスト計測、予算超過時の停止がそれにあたります。この責務を全部持ったまま Mastra を入れると、Mastra のワークフローやメモリと役割が重なるため、採る理由がありませんでした。
今回は当面の利用者が限られるため、予算や権限のゲートと承認フローは当面作らないことにしました。実行管理のうち自分のコードで持つのは、利用量の記録です。7月に役割が重なっていたワークフローやメモリは、Mastra に任せられます。中断と再開も、危険度の高い操作を実行前に止めて人に回す処理として、最初の版から使います。
開発と保守の体制
OSS の採用では、利用規模に加えて、誰が開発を続けているかも確認します。個人が一人で保守している OSS は、作者の都合で更新が止まることがあるからです。
Mastra の場合、GitHub でコードを提供した開発者（コントリビューター）は 467 人（2026年10月2日時点）です。開発元は React のフレームワーク Gatsby を作ったチームが創業した Mastra 社で、Y Combinator などから累計3,500万ドルの資金を調達しています。
次回は、Mastra を使って基盤の骨格を実装する過程を書きます。
ZenChAIne では、技術選定とその判断の記録づくりを、技術顧問として支援しています。フレームワークの選定や自作する範囲については、技術顧問・開発支援からご相談ください。