「僕たちは、優秀なCRMを開発していて、CRM市場での成功は確実だった。それなのに、なぜまたDevツールなんて作らないといけないのか？」
TypeScriptベースのAIエージェントフレームワーク「Mastra」を開発するスタートアップの創業者たちは、こんな自問自答から現在の事業に辿り着いたと振り返ります。
2025年5月19日、東京・銀座のLayerXオフィスで開催されたイベント「Mastra創業者がリアルを語る 〜AIエージェント開発の"今"と"未来"」では、Y Combinator出身のMastra創業者、Abhi Aiyer氏（Founder/CTO）とTony Kovanen氏（Founding Engineer）の2人が初来日。
なぜ今、TypeScriptなのか。AIエージェントの未来はどこに向かうのか。そして、「日本のトラフィックが全体の20%を占める」という現象の背景には何があるのか。創業からわずか7ヶ月で急成長を遂げるMastraの創業者たちが、AIエージェント開発の最前線について語りました。
「Salesforceを倒すのは俺たちだ！」失敗から生まれたAIフレームワークの誕生秘話
Abhi：今日は、Mastraの誕生秘話と今後の展開をお話しします。まず、僕たちのジャーニーについて。どの会社にも創業ストーリーがありますが、Mastraは本当にくだらないけど最高に面白いんです。
当時、僕たちは「ファウンダー主導のCRM」を作りたかったんです。
Abhi：Mastraの共同創業者であるSam、Shane、そして僕は、2015年から、静的サイトジェネレーター『Gatsby』 の開発に携わっていました。Samは、Gatsbyの共同創業者でもあるんです。そして2023年、Netlifyという会社に買収され、僕たちは全員、働くことになりました。
Abhi：少し話はそれますが……これは、Gatsbyの成長グラフです。Netlifyに買収される直前の2022年には、ほぼ2,500万ダウンロードを達成していました。ただ、彼らが買収したのはGatsbyのためじゃありません。彼らがGatsbyを買収した理由は、Tonyと僕が作った「Valhalla」という別のプロダクトのためだったんです。まぁ、これは「悲しい話」なので、また別の機会にお話ししましょう。
話を戻すと、買収された僕らですが、正直に言うとNetlifyでの仕事が好きじゃなかった……。そこで、自由時間に別のことをはじめました。「Gatsbyでさんざんやったし、Devツールにはもううんざりだ。今度はCRMみたいなエキサイティングなものを作ろう」と。「Salesforceはを倒すのは俺たちだ！」と思っていたんです。
それで僕たちは、「AI CRM」を謳う「Kepler」という営業向けエージェントプラットフォームを作りました。実は、AIはまだ搭載されていなかったんですけどね（笑）。
それでも資金調達のために投資家のところに行って、「AI CRMがあるんだ」と持ちかけました。すると「AIのパートはどこ？」と聞かれたので、「まだありません」と答えました。
お金は……もちろん、集まりませんでした（笑）。それで仕方なく、CRMにAI機能を追加することになったわけです。
でも、これが地獄でした……。そこは、Python一色の世界だったからです。私たちはTypeScriptを使っていました。そして、出会ったチームの多くは、LangChainが使い物にならないので独自フレームワークを作っていました。TypeScriptなんて二の次です。
挙句の果てには、Google Colabを「アプリケーションです」と言って送ってくる人までいました。ちなみにね、これは断言しておきたいのですが、ColabはAIアプリケーションじゃないですよ。あれは、ただの“Colab”です。覚えておいてください。
僕たちはもっと良いものが欲しかった。でも、「なぜそれを僕たちが作るべきなのか？」と考えたんです。「僕たちは、優秀なCRMを開発していて、CRM市場での成功は確実だ。それなのに、どうしてDevツールなんて作らないといけないのか？」とね。
でも結局、その問いの答えは、Gatsbyにありました。僕たちは、前にも同じことをやったことがある。多分これが答えだったんです。オープンソース精神は僕たちのDNAに刻まれているんです。
AIアプリケーション開発に必要な「プリミティブ」を提供する
Abhi：そうして生まれたのが、TypeScriptのエージェントフレームワーク「Mastra」です。スタートしたのが2024年10月なので、まだたった7ヶ月しか経っていません。今、ここで皆さんにお話しているのが信じられないくらいです。
当時のY Combinator（YC）は、すでにワークフロービルダーに投資をしていました。Vellum AIやStackOneのような、UIを使ってAIエージェントを構築する企業があった。僕たちも試してみましたが、それは正しい方向じゃないと気づきました。
人々はコードを使いたいし、コードを書きたい。TypeScriptで自分を表現したい。だから僕たちは、このエージェントを作ろうと決めました。
Mastra、そして僕たちの夢と目標は、AIアプリケーション開発に必要な『プリミティブ（基本構成要素）』を提供することです。
Abhi：ここで僕が「プリミティブ」という言葉を使うのは、フレームワークとして非常に重要だから。シンプルな構成要素こそが、小さな機能を実現して大きな成果を生むんです。
僕もTonyも、レゴが好きです。僕たちは、生業としてレゴを作っているんです。AIアプリケーションをレゴブロックのように作ることができる。エージェント、ツール、メモリ、RAG、ワークフロー、MCP、A2A……今後、登場するであろう、あらゆる3文字略語に対応したプリミティブを用意しています。
こうして僕たちは、YCに参加することになったんです。
Abhi：この写真は、バッチに合格したときにサンフランシスコのYCビルの外で撮ったものですね。YCに合格したら、初日に看板の前で撮影するのが、お決まりなんですよ。
Paul Grahamに皮肉られながらも急成長！YCバッチ全員との対話作戦
Abhi：YCでは、色んなことが起きました。左上の写真は、YCの初日の最初の夜のトークのとき。みんなの前で「LangChainはクソだ」と言ってね……この写真は、その瞬間です（笑）。
真ん中の写真は「YC Live」に初めて選ばれたときのものです。優れた会社だと認められると、大勢の前でデモをする機会が与えられます。僕たちが選ばれたんだけどね。ほら、見てください、めっちゃストレス溜まってる顔してます。
左下のグラフは、僕たちがLangGraphを乗っ取った瞬間です。
中央上の写真は「YC Demo Day」のステージ。またほら、ストレスMAXです。ピッチしてる時ですね。どれも本当に良い思い出です。ただ、めちゃくちゃストレスフルでもありました。
僕たちを信じてくれたのは、（Rice Capitalの）福山太郎のような投資家をはじめとする人たちです。そのおかげで、Gatsby時代の仲間を再び集めることもできました。まさに「昔の仲間でまたバンドを組んだ」って感じですね。
おかげでスピーディに開発ができて、クラウドプラットフォームを3週間で構築したんです。それが良いものだったかどうかは別として、とにかく作り上げました。YC最初の1ヶ月でプライベートベータをスタートさせたんです。早期のフィードバックとトラクションが得られてクールな出来事でした。何を作るべきかも明確になりましたしね。
ある日、YCのファウンダーであるPaul Grahamが講演するイベントに参加したことがあったんです。そこで彼は、私たちのことを皆の前でからかいました。『ここに3人の男がいて、YCバッチ全員に売り込みをかけてるんだよ（笑）』とね。
まぁ、まさにその通りで。Mastraの今の形は、YCバッチにいたすべてのスタートアップと、とにかく話しまくった結果なんです。『どうやってエージェントを作っている？』『何をしている？』『僕たちはどうしたら手伝える？』みたいに。
そして、ただひたすらに、そのアドバイスを活かしました。言い換えるなら、常に顧客と話し続けること。それが僕たちがやったことです。
サンフランシスコで最もクールなノベルティは「本」？
Abhi：そして、本も書きました。顧客と話していると、みんな「何をすれば良いのかまったくわからない」と言うんです。私たちも同じで、学びたかった。だからYCで毎週学んだことを、そのまま本の各章にしました。各章がYCの1週間に対応しているんです。
たとえば、RAGについて学んだ週は、RAGの章になりました。素晴らしい構成だと思いますよ。そして実はこれは、マーケティングハックにもなったんです。最初はそのことに気がつかなかったんですが、サンフランシスコで最もクールなノベルティは「本」なんです。
『Principles of Building AI Agents（AIエージェント構築の原則）』というタイトルで出版しました。Mastraのストーリーは、想像以上に大きくなりました。デジタル版が欲しい方は、mastra.ai/book でダウンロードできますから、ぜひ。
さて、開発者ツールについて少し話しましょう。私たちが学んだのは、知名度を上げるには、もっとパーソナルにオーディエンスと繋がる必要があるということ。『Mastroverse』と名付けて、LinkedInやTwitterでAIトピックの動画を投稿するようになりました。
マルチエージェントの話題や、あえて議論を呼ぶような内容も含めています。アメリカでは、LinkedInでも「ドゥームスクローリング（SNSなどで悲観的なニュースを延々とスクロールし続けてしまう現象）」が存在することに気づきました。仕事中にトイレでスクロールしているプロフェッショナルたちから、何百万ものインプレッションを獲得できるんです。
最近は、マーケティングコンテンツなど、より多様なコンテンツを作っています。毎日のライブストリームもはじめました。ライブストリームでは、AIの様々なトピックを扱います。Mastraに直接関係ない話題でも、最終的にはすべての道がMastraに通じるんです。
僕らの合言葉は「Train in Python, Ship in TypeScript.」
Abhi：今日、僕らがこのミートアップイベントで来日したのも、その結果の一つです。Mastra全体のトラフィックのうち、なんと20%近くが日本なんです。アメリカに次いで2位ですよ。
Abhi：僕たちは、その理由が知りたかった。（今回の来日はそれを）理解するための素晴らしい旅になって、本当に感謝しています。
Tonyへパスする前に、最後にもう一つ。少し前に、これをXに投稿しました。
Abhi：Pythonには「適した場所」があります。ただ、それは私たちがいるところではありません。僕たちがいるのは、実際にアプリケーションをユーザーに届ける場所です。
だから、私たちの合言葉は『Train in Python, Ship in TypeScript.（Pythonは“訓練用”、TypeScriptは“製品出荷用”）』。この絵の通りです。Pythonの蛇は線路の上で研究やモデル訓練をしている。一方、TypeScriptは港で実際に製品を船に積み込んで世界中に届けている。
AIモデルを作る人たちがPythonを使うのは素晴らしい。でも、私たちMastraのエンジニアは、モデルの「前」に立つ存在です。モデルの上でも下でもない。つまり、優秀なAIモデルを受け取って、それを使った実用的なアプリケーションを素早く作り、実際のユーザーに届ける。それが私たちの仕事です。
型安全性を保ちながらシームレスに！完全書き直しのワークフローの革新
Tony：ここからはMastraが最近実装した機能と、近日リリース予定の機能についてお話ししましょう。
最近、Mastraのワークフロー・プリミティブを完全に書き直した新バージョンをリリースしました。この実装には特に誇りを持っています。なぜなら、TypeScriptの力を最大限に活用したからです。最大の改善点は、型安全性を保ちながら、各ステップの出力が次のステップの入力へシームレスに流れるようになったことです。
以前のバージョンでは、ステップの出力を取得するには getStepResult という特別な関数を使い、ステップの名前やIDを渡す必要がありました。でも今は、すべてがスムーズに流れるようになり、ワークフローの実行で何が起きているかを理解しやすく、視覚的にも把握しやすくなりました。
もう一つの革新的な機能は、Mastraのワークフローを実行するために、異なる実行エンジンを選択できるようにしたことです。実験的なInngest実行エンジンもリリースしました。これは私が直接実装した機能です。また、モジュラー型のワークフロー実行エンジンも開発中で、将来的にはTemporal実行エンジンのサポートも予定しています。
では、現在のワークフローがどのような形になっているか、簡単に見てみましょう。
Tony：上図は、2つのステップが順番に実行されるシンプルな例です。
まず、天気情報を取得し、この例ではOpenWeather APIを使って、そのAPIレスポンスを次のアクティビティプランナー・エージェントに渡しています。このケースでは、fetchWeather ステップの出力（天気予報のJSONレスポンス）が、自動的に planActivities ステップに転送されます。右側にあるのが実際のワークフロー定義で、ステップを .then() でチェーンすることで、処理の流れを定義しています。
オリジナルのワークフロー実装から学んだ重要な教訓は、ワークフローで分岐が発生する場合、それが視覚的に明確でないといけないということです。論理的な分岐やパラレル処理が起きている箇所は、視覚的にはっきりとわかる必要があります。実行中に何が起きているかを確認すると、デバッグがずっと簡単になるからです。
Tony：この新しいシンタックスでは、if-else的な状況や、switch-case的な状況がある場合、.branchメソッドを呼び出します。このメソッドはすべての条件をチェックし、条件を満たした分岐内のステップやネストされたワークフローが実行されます。
そして、条件を満たした分岐の処理がすべて完了したら、次のステップに進みます。ネストしたサブワークフローやほかのステップなど、複数の処理をまとめて実行できます。
もう一つ、僕たちが気づいたことは、ワークフローで前のステップに戻ろうとすると、ロジックがすぐに複雑になるということです。特にコードを再利用して、同じステップを複数の場所で使い、そこから戻ろうとすると問題が起きます。
通常は「このステップ、次、その次」と前向きに考えますが、前に戻る場合は「どこから来たのか？」「どうやって戻るのか？」「その後はどの順番で実行されるのか？」と考え方を切り替える必要があり、混乱してしまいます。
そこで私たちは、すべてをサブワークフロー（ネストされたワークフロー）にカプセル化することにしました。
Tony：そこで、ループ処理もシンプルになりました。ループ操作の引数として、1つのステップまたは1つのサブワークフローを指定するだけです。ループさせたい処理はすべて、その中で繰り返されます。これにより、すべてがカプセル化され、明確になります。
Tony：今、僕たちは新しい「vNext」バージョンのワークフローを使って、社内でとてもエキサイティングな機能を開発しています。これまでは、「ステップ1→2→3」と順番が決まっていましたが、今度はAIエージェントが「次は何をするか」を自分で決められるようになります。
スーパーバイザーと呼ばれるAIが司令塔になって、どのステップをどの順番で実行するか、いつ終了するかを判断します。何回ループするか、何ステップ必要かは、実行してみないと分かりません。これを「エージェントネットワーク」と呼んでいます。
すでに試作版を公開していて、たくさんの意見をもらったので、改良版がもうすぐ出るので、楽しみにしていてください。
マルチエージェントアーキテクチャへ完全にBetしている
Abhi：数週間前、MicrosoftのRSAセキュリティカンファレンスで、Microsoftが「シングルエージェントアーキテクチャだけを推奨している」という話を聞いたんです。理由は「それしかコントロールできないから」。でも、僕たちはそれは違うと考えています。
人生は一方向じゃない。ネットワークのように繋がっています。だから、Microsoftの考えは間違っていると思います。
僕たちはマルチエージェントアーキテクチャに完全にBetしています。未来は、たくさんのエージェントが協力して働く世界でしょう。それこそ、僕らがやろうとしていることです。
さらに面白いのは、エージェントネットワークとワークフローを組み合わせると、アプリケーションの「どこまで決め打ちにするか」を自分で調整できるんです。
Tony：もう一つ開発したことがあります。
たとえば、自分のエージェントセット、MCPツールやローカルツール、ワークフローがあるとします。でも、一部のエージェントは別の場所でホストされている場合があります。
そこで私たちは「エージェント間プロトコル（A2A）」を実装しました。これにより、ほかのサービスやフレームワークでホストされているエージェントも、Mastraのエージェントと同じように呼び出せます。このプロトコルに対応していれば、どんな外部エージェントでもそのままMastraのネットワークに“放り込める”んです。
Abhi：つまり、Python製のエージェントとも、普通に会話できるようになります。
Tony：また、自分のエージェントのセットがあることを想像してください。MCPでもローカルに定義されたツールでも、ツールがあります。ワークフローがあります。
でも今、いくつかのエージェントはほかの場所でホストされています。エージェント間プロトコルの実装に取り組んでいて、ほかのMastraエージェントであるかのように、ほかのサービスやフレームワークでホストされているAPIのエージェントを呼び出せます。そのプロトコルを話す限り、エージェントネットワークやワークフローにドロップできます。ほかのMastraプリミティブのいずれにも。
Abhi：つまり、すべてのPythonフレームワークとも話せるようになるわけです。
Tony：あとは、いま私たちが積極的に開発しているのは、お気に入りの認証プロバイダーを自由に選べるシステムです。
Abhi：Auth0をはじめ、SupabaseAuth、Clerk、Zitadel、WorkOS、Okta……何でも対応しますよ。
Tony：これらのプロバイダーとの連携を進めています。また、カスタム認証システムも作れます。つまり、使いたい認証方法を何でも持ち込めるということです。
それから、Mastraを認証プロセスに組み込めるシステムも開発中です。VercelやMastra Cloudにデプロイしても、認証なしのと同じように動作します。マルチテナンシーにも対応予定です。たとえば、ユーザーごとに異なるOpenAIの認証情報を使えるようになります。楽しみにしていてください。
人間の脳を模倣したメモリーシステム
Abhi：さて、ここからはもう一つ、「メモリー」についても話しましょう。メモリーとは何か、どうあるべきかについて、新しい考えに至りました。僕たちの目標は、AIエージェントに人間と同じような記憶の仕組みを持たせることです。人間の記憶がどう機能するか分析して、それをコードで再現しはじめました。これから紹介する実装が「なるほど、確かに人間っぽい」と思ってもらえたら嬉しいです。
まずは、短期記憶について。皆さんも「短期記憶」を持ってますよね。タスクの実行に必要な情報を一時的に覚えて、終わったらすぐ忘れる。この「急速に忘れる」という特性をAIに実装してます。たとえば、4桁の番号を一時的に覚える時を考えてみてください。「1234、1234、1234」と何度か繰り返して覚えて、いらなくなったら忘れちゃう。でも、ある瞬間は、その記憶が必要だったわけです。だから僕たちも、短期記憶を実装しました。
Abhi：一方で、長期記憶に関しては、エージェントの方が人間より優れています。データベースがありますからね。僕たち人間のデータベースである「脳」は、時間とともに記憶が薄れていきます。でも、エージェントの長期記憶はSQLデータベースやMongoDBです。ストレージ代を払い続ける限り、（特別な事由がなければ）すべての記憶を保持できるでしょう。
長期記憶では「意味的なコール」と「検索」が重要になります。課題は、何年分もの記憶がある時、どうやって素早く取り出して、すぐ使える状態にするのかです。
ワーキングメモリは、基本的にスクラッチパッドみたいなものです。数学でいえば紙で計算して、答えを書いて、それで終わりです。短期記憶と似てますが、短期記憶は会話のなかで一定期間、 複数のメッセージに使えるのに対して、ワーキングメモリは本当に単一のタスク用です。
Tony：エージェントネットワークの例で考えると、エージェントに5つの連続したコールがある場合、ワーキングメモリをめちゃくちゃ使います。このメモリはワークフローが実際に完了するまでしか存在しないからです。
エージェントにタイムトラベルを。「弦理論みたいな」分岐タイムラインの実現
Abhi：僕はずっと、タイムトラベルをしたいと思っていたので、エピソードメモリは僕のお気に入りです。残念ながら僕たちにはできないけど、エージェントならできる。
エピソードメモリは、エージェントの特定のチェックポイントを取って、事実やフィクション、そして時間軸上のチェックポイントを作ることです。エピソード記憶を導入すると、経験、事実、取得した情報に基づいて、タイムライン上の異なるポイントをいつでも取り出せます。重要だとマークしているから検索も簡単。技術的には過去の特定の時点にタイムトラベルできるのだから、超クールでしょう？
サイドエフェクトのないアクションなら、過去に戻れます。でも、サイドエフェクトがあったらどうなるのか。これはもう弦理論みたいな話になってきて、分岐したタイムラインを作る必要があります。
僕たちも普段の生活のなかで、「購入」自体をを取り消すことはできないでしょう？「返品」はできるけど、購入自体を取り消すことはできない。エージェントがアイテムを買って、今度は返品する必要がある場合、タイムラインは分岐することになる。これはディープカスタマー・パーソナライゼーションタイプのエージェントを作るときに重要になってきます。
次に、アーカイブメモリは要約です。たとえば、1ヶ月間の会話があったとして、それを小さな要約や箇条書きなんかにアーカイブする。そうすれば取り出せます。
これらは全部、異なる戦略になります。もうすでに作業をスタートさせていて、これらすべてのメモリー構造をTypeScriptで実装したものが、これから順次公開されていきます。メモリーは、正直、今のAI開発で一番アツいと思ってます。まるで脳みたいですから。
「Lovable meets agents」プロンプトだけでエージェント自動生成の未来
Tony：もう一つ、ワークフローのスケーラビリティについて。最近、ワークフローだけでなく、Mastra関連のプリミティブ全体のスケーラビリティ向上に取り組んでいます。
今、Mastraは「イベントベースの実行システム」へと進化中です。Mastra内で起こる、ほぼすべてのアクションが「ストリーム処理システム」で処理され、大規模な並列処理を実現しています。
Abhi：現在のオープンソース版Mastraは、抽象化のためのプリミティブを提供しています。基本的には、開発者が独自のMastraインスタンスを構築する形になります。.mastra build を実行すると、あなたのAIアプリが、Honoフレームワークを使ったHTTPサーバーの形で自動的に組み立てられ、Web 上で動く状態になります。
Abhi：ここで「Home Server」と書いているのは、ExpressでもCoaでも、お好きなものを使えるという意味です。要するに、HTTPサーバーであれば何でも構いません。
それからMastra独自のプロトコルを設計していて、僕たちはそれが最適だと考えていますが、MCPという選択肢もあります。今後は、Home ServerをMCP対応のサーバーとして動作させられるようにします。もちろんGoogleのプロトコル A2A でも構いません。あとは、現在イベント駆動型のタスクプロトコルを開発しています。
重要なのは、開発者がこれらの詳細を意識する必要がない点です。Mastra側のOSS Frameworkだけを気にしていれば良く、後の変換は自動で行われます。Vercel、Cloudflare、Netlifyへのデプロイが可能ですが、最も推奨するのはMastra Cloudです。
もう一点、エージェントがこれらのタスクを自動化できるかについては、“Lovable meets agents”、つまりは「Lovableのような体験でエージェントを構築するツール」を仕込んでいるところです。
エージェントビルダー、ワークフロービルダーを使えば、プロンプトを入力するだけで自動生成されるようになる予定です。そして、さらに効率化したい方向けの機能も準備中です。
日本にまた来ます。日本は本当に素晴らしかったです！ありがとう！
---------------------
【謝辞】
今回のイベント開催は、多くの方々のご協力によって実現しました。
Rice CapitalのManaging Partner・福山太郎さんがMastraチームの来日を実現してくださり、LayerXさんは素晴らしい会場を提供してくださいました。また、フードスポンサーとしてアマゾンウェブサービスジャパンさんにもご協賛いただき、参加者の皆様との有意義な交流の場を設けることができました。
Mastraの皆さん、貴重な時間を割いて日本に来てくださり、本当にありがとうございました！TypeScriptエコシステムへの情熱と、開発者ファーストの姿勢で築き上げてきたMastraの世界観を、直接お聞きできたことはとても刺激的でした。
「Train in Python, Ship in TypeScript.」という哲学のもと、実用的なAIアプリケーションを世界中に届けようとする皆さんの取り組みに、多くの日本の開発者が共感していることでしょう。次回の来日も心より楽しみにしています。
AIエージェント開発の可能性はまだはじまったばかり。Mastraと共に、新たな未来を築いていくエキサイティングな時代が続いていきそうです。
Abhi Aiyer @abhiaiyer
Founder/CTO, Mastra
Netlifyでプリンシパルエンジニアを務め、100人以上のエンジニア組織をリードした経験を持つ。Gatsby Cloudのインフラを構築し、数万のビルドノードの運用、数十億のファイル配信、および月間数百テラバイトの帯域幅を処理するシステムを実現させた。
Tony Kovanen @TonyKovanen
Founding Engineer, Mastra
Vercelの元共同創業者兼CTO、Gatsby Cloudのプリンシパルエンジニアを歴任。Next.jsの共同クリエイター。元Socket.ioコアチームメンバー。数百万の同時ユーザーに対応するバックエンド、データベース、インフラを構築・スケーリングした実績を持つ。
