この連載の第1回で、私たちはAIエージェントの開発にMastraというフレームワークを利用していることを紹介しました。Mastraは、AIエージェントやAIアプリケーションを開発するためのオープンソースのTypeScriptフレームワークです。私たちがMastraを採用した理由は、単にAIエージェントを簡単に作れるからではありません。
私たちは、AIそのものを開発したいわけではありません。AIを現実の業務システムに落とし込みたいのです。
企業のWebサイトや社内システム、データベースなどと接続し、実際の業務の中でAIを動かす。そのためには、AIモデルだけでなく、既存システムとの連携、セキュリティ、監視、テスト、継続的な運用まで考えなければなりません。私たちが探していたのは、AIを「試す」ためのライブラリではなく、AIを使ったシステムを構築し、本番で運用するためのフレームワークでした。
それがMastraでした。
「試して終わり」にしないために生まれたMastra
Mastraが最初に公開したブログ記事「A framework for the next million AI developers」を読むと、このフレームワークが生まれた理由がよく分かります。
Mastraの創業者たちは、もともとWeb開発フレームワークのGatsbyを開発していたチームでした。その後、AIを使ったCRM「Kepler」の開発に取り組み、いくつかのAIフレームワークを試しました。ところが、プロトタイプを作るところまでは便利でも、より信頼できるシステムにしようとすると、フレームワークで書いた部分を取り除き、モデルのAPIを直接呼び出す形へ作り直すことになったそうです。
そこで彼らが目指したのが、気軽にAIを試せる一方で、そのまま本番環境まで持っていけるほど堅牢なフレームワークでした。
私が最初にこの記事を目にした時、「そうそう！その通り！」と嬉しくなったのを思い出します。AIに何かをさせるデモを作ることと、お客様の実際の業務で長期間動かすことの間には、大きな距離があります。Mastraは、その距離を埋めることを最初から目指しているフレームワークです。
フレームワークだから、「結局必要になるもの」が揃っている
AIモデルをAPIから呼び出すだけなら、それほど難しくありません。しかし、実際の業務に組み込もうとすると、途端に必要なものが増えていきます。外部システムを利用するTool、一連の処理を組み立てるWorkflow、会話や文脈を保持するMemory。さらに、前回紹介したGuardrailや人間による承認、テストや評価の仕組みも必要になります。
Mastraには、こうしたAIエージェントを本格的に作ると結局必要になるものが、ほぼ一通り用意されています。Mastraは、この設計思想を「Domain-complete」と呼んでいます。
特定の機能だけを便利にするのではなく、その領域で必要になる主要な機能について、フレームワークとして一通りの答えを用意する。Mastraはその例として、Web開発におけるNext.jsや、インフラ構築におけるTerraformを挙げています。
第1回でMastraを「Webサイト構築におけるCMSのような存在」と紹介したのも、この特徴があるからです。CMSにも、ページ管理、権限、ワークフロー、検索、APIなど、企業のWebサイトを作ると結局必要になるものが揃っています。
必要な基盤を毎回ゼロから作らず、本当に作りたいものの開発に集中できる。
Mastraにも、それとよく似た便利さがあります。
本番運用には「可観測性」が必要
Mastraの中でも、私たちが特に重要だと考えているのがObservability（可観測性）です。
AIエージェントでは、プログラムとして正常に動いていても、期待していない回答や判断をすることがあります。そのとき、「AIだからそういうこともあります」では、本番システムとして運用できません。
Mastraでは、AIモデルへの入出力やToolの呼び出しなど、Agentが回答に至るまでの処理をTraceとして追跡できます。さらにScorerやEvalを使って、AIの回答品質そのものを評価する仕組みも用意されています。
つまりMastraは、AIエージェントを作るところだけでなく、動かした後に観察し、評価し、改善するところまでをフレームワークの守備範囲として考えています。
これは、お客様のシステムを作って終わりではなく、その後も保守・運用していく私たちにとって重要なポイントです。
Pythonではなく、TypeScriptで「製品」を作る
もう一つ、Mastraを特徴づけているのがTypeScriptです。Mastraは、TypeScriptをプロダクト開発のための言語と捉えています。
彼らが対象としているのは、AIモデルを研究する人だけではありません。フロントエンド、バックエンド、フルスタックといった、実際の製品を作ってきた開発者です。Mastraは、そのような既存のエンジニアたちが「次の100万人のAIエンジニア」になると考えています。
AIを研究するのではなく、AIを使ったソフトウェアを作る。
そのための言語としてTypeScriptを選んだMastraは、私たちにとって非常に馴染みやすいフレームワークでした。
マカルーデジタルでは、TypeScriptにも比較的早い時期から取り組んできました。AIエージェント開発のために、まったく新しい言語や開発環境から習得するのではなく、これまでWebシステム開発で培ってきた技術を活かしてMastraへ入っていけることも、大きなメリットです。
Mastraを、一部のエンジニアだけの技術にしない
現在、私たちは弊社のエンジニア全員がMastraを使えるようになることを目指して、社内での習得を進めています。ここでも、Concrete CMSで専門性を築いてきたときの経験が活きています。Concrete CMSを本格的に扱い始めた際には、開発元であるPortlandLabsへコンタクトを取り、コアコミッター自ら弊社エンジニアへのレクチャーをしていただくことができました。
今回も同じようにMastraの開発元とコミュニケーションを取り、サポートしてもらいながら習得を進めています。実際にやり取りをしていて感じるのは、開発チームのフットワークの軽さと、開発者に対するオープンな姿勢です。私たちからの相談にも、とても親切に対応してくれています。また、彼らの「次の100万人のAI開発者」のためのフレームワークを作るという目標が、単なるキャッチコピーではなく、本気でMastraを世界中の100万人のAI開発者に普及させようとしているのだと感じます。
私たちもその力を借りながら、Mastraを一部のAI専門エンジニアだけが扱う技術ではなく、Webシステムを作るエンジニアが普通に使える技術にしていきたいと考えています。
AIを作るのではなく、AIが働けるシステムを作る
私たちマカルーデジタルは、AIモデルの研究開発を専門としてきた会社ではありません。
CMSをはじめとした企業向けのWebシステムを開発し、データベースやAPI、認証、権限、クラウド環境などを組み合わせて、実際の業務で使える仕組みを作ってきました。
AIエージェントを業務に組み込むことも、その延長線上にあると考えています。
AIを現実の業務に組み込み、本当に使えるシステムとして動かす。
そのための開発基盤として、私たちはMastraを採用しています。
次回は、実際にAIエージェントを作ってみます
ここまでAIエージェントの考え方や開発基盤について紹介してきましたが、実際にはどのように作るのでしょうか。
次回はMastraを使って、AIモデルを選び、役割を与え、Toolを持たせるところから、専用の開発画面ですぐに動かしてみるところまで、AIエージェント構築の「基本のキ」を紹介します。
