AIエージェントを使ったアプリを作ってみたいと思っても、最初からフロントエンド、バックエンド、インフラ、データベースまで全部きれいに設計しようとすると、どうしても手が止まりがちです。
特にMVP（Minimum Viable Product）開発やデモアプリの段階では、まず「本当にこの体験に価値があるのか」を素早く検証したいはずです。
そのときに個人的に扱いやすいと感じているのが、Mastraを使ったTypeScriptベースの最小構成です。
今回はサンプルとしてボートレースの予想を行うCLIアプリを題材に、以下の観点でまとめます。
※本記事は、2026年2月に開催したイベントMastraで作る「ボートレース予想AIエージェント」開発入門の内容を抜粋・再構成したものです。
Mastraは、AIエージェントを構築するためのTypeScript製フレームワークです。
AIエージェント開発ではLangChainを思い浮かべる方も多いと思います。LangChainはPython版のエコシステムが特に厚く広く使われていますが（TypeScript版のLangChain.jsもあります）、Mastraは最初からTypeScriptを主戦場にしている点が大きな特徴です。
この特性は、既存のWebアプリにAI機能を組み込みたい場面でかなり効いてきます。現在のWeb開発では、フロントエンドはReactやVue.js、バックエンドはExpress.jsやNext.js、あるいはHonoといった構成が一般的です。そこでAI部分だけ別の言語やランタイムに分かれてしまうと、開発速度も保守性も落ちやすくなります。
Mastraであれば、フロントエンドからバックエンド、そしてAIエージェントまでTypeScriptでそろえやすいので、試作の初速を出しやすいと感じています。
AIエージェントの価値は、単にチャットができることではなく、人が普段やっている調査や判断の流れを分解して任せられることにあります。
Mastraでは、分解した調査や判断のタスクごとにAIエージェントを定義し、それぞれにプロンプトやツールを割り当てられます。さらに複数のAIエージェントをワークフローとしてつなげられるため、処理の流れを比較的直感的に組み立てられます。
MVPやデモアプリを素早く作るときに、個人的におすすめしている構成は次のようなものです。
ポイントは、TypeScriptで統一できることです。
Mastraはバックエンドに組み込んでもよいですし、必要に応じて別プロセスとして切り出しても構いません。フロントエンド、バックエンド、データベースをDockerでまとめてもよいですし、ローカルで npm コマンドから立ち上げるだけでも十分です。
重要なのは、最初から構成を複雑にしすぎないことです。MVPの段階で必要なのは、完璧な疎結合構成ではなく、最小限のコストで検証可能な状態を早く作ることだと思っています。
今回作ったのは、ボートレースの予想を行うCLIアプリです。
このアプリでは、以下の流れを3つのAIエージェントに担当させました。
今回、題材としてボートレースを選んだのは、AIによる情報収集と推論の相性が比較的よさそうだと感じたからです。
理由はいくつかあります。
競馬のように出走数が多く、不確定要素も大きい題材と比べると、ボートレースは取得できるデータを構造化して推論に乗せやすいと感じています。
特に4つ目の「前日の振り返りを翌日に反映しやすい」点は、今回のようなPDCA型ワークフローと相性がよい部分です。
構成は必要最低限にしています。フロントエンドやバックエンドを大きく分離せず、Node.js上にMastraを組み、CLIとして動かすだけのシンプルな構成です。
ディレクトリは、Mastraの基本に沿って次の3つに分けました。
agents: 検索、予想、レポートの各担当tools: Web検索やファイル保存など、エージェントに使わせる機能workflows: エージェント同士をつなぐ処理の流れ特にMastraでは、検索やファイル書き込みのような外部アクションをツールとして定義してエージェントに渡す形になるため、この分離は分かりやすいと感じました。
今回使ったLLMは、無料枠で扱いやすかった Google Gemini です（2026年2月時点）。
モデル選定では、「事前に情報を集めて、その情報から推論して予想を立てる」という用途を重視しました。もちろん、用途によって最適なモデルは変わります。たとえばコーディング支援やコードレビュー中心のエージェントなら、別のモデルの方が合うケースもあるはずです。
大事なのは、アプリの要件に合わせてモデルの得意分野を選ぶことだと思います。
検索にはTavilyを利用しています。MastraからTavilyのAPIを呼び出し、レースに関する情報を取得する構成です。
検索エンジンを別途組み合わせたのは、リアルタイム性が重要なタスクでは検索基盤の品質が非常に重要だからです。
LLMの学習済みの知識だけに頼ると、古い情報が混ざってしまうことがあります。特に、直近の出走表や開催情報が重要なケースでは、そのズレが予想精度に直結します。
Tavilyのような検索エンジンを組み合わせると、最新情報の取得は検索エンジンに任せ、AIには取得した情報の整理と推論を担当させる、という分業がしやすくなります。
これはボートレースに限らず、最新情報が前提になる業務アプリや支援ツール全般に応用できる考え方だと思います。
最初のエージェントは、レースに関する情報を集める役割です。
入力するのは、次のような最小限の情報です。
この情報をもとにWeb検索を実行し、たとえば以下のような情報を検索して要約します。
検索結果はそのまま渡すのではなく、予想に使える客観的な事実として整理するよう指示しています。
また、このエージェントで意識したのが、AIが何を根拠に予想したのかを人間が追えるようにすることです。
AIに「検索して予想して」とだけ任せることはできますが、それではブラックボックスになりやすく、結果の良し悪しを評価しづらくなります。
そこで、検索結果そのものも保存・出力するようにしました。どのページを参照したのか、どんな情報が抽出されたのかを見えるようにしておくことで、予想の妥当性を人間が確認できます。
2つ目のエージェントは、情報収集の結果を受けて予想を立てる役割です。
今回は、以下の買い目を出力するようにしました。
ボートレースに詳しくない方向けに簡単に説明すると、3連単は1着から3着までを着順通りに当てる形式、3連複は上位3艇を順不同で当てる形式です。2連単・2連複も同様に、上位2艇を順序あり・順序なしで当てます。
このステップでは、調査結果を参照しながら、展開予想も含めて論理的に買い目を組み立てるよう指示しています。
予想の方針はプロンプトで柔軟に調整できます。たとえば「予算3,000円で買い目を組む」「本命寄りで提案する」「穴狙いを含める」といった変更を自然言語で指示しやすいのも、AIエージェントの強みです。
3つ目のエージェントは、実際の結果を受けてレポートを作る役割です。
本来は結果取得もWeb検索で完結させたかったのですが、試した限りでは安定して取れないケースがあったため、今回は着順を手入力する仕様にしました。
結果を入力すると、予想との差分を確認しつつ、
をまとめた振り返りレポートを生成します。
このレポートはプロジェクト内に保存し、次回予想時に参照させるようにしています。つまり、単発の予想で終わらせず、情報収集 → 予想 → 結果確認 → 振り返り → 次回改善というPDCAを回す構成です。
このアプリを実際に試したところ、想像以上に面白い結果が出ました。
たとえば、ある日に1レースから12レースまで予想させたところ、12レース中4レースで3連単または3連複の組み合わせがある程度当たりました。さらに翌日に9レースから12レースまで予想させた際には、4レース連続で的中するケースもありました。
もちろん、これはあくまで検証用であり、実際に賭けに使ったわけではありません。また、たまたま良い結果が出た可能性もあります。ただ、検索結果と振り返りレポートを蓄積しながら改善を回すと、精度が上がる余地を感じられたのは大きな収穫でした。
Mastraを使うと、調査、整理、予想、振り返りといった人間が手でやると面倒な流れを、AIエージェントとしてまとめて実装しやすいと感じました。
今回のサンプルはCLIベースの最小構成でしたが、それでも次の一連の流れを一気通貫で回せます。
MVPやデモアプリの段階では、まず小さく作って動かし、価値があると分かったら後から構成を大きくしていく方が進めやすい場面が多いはずです。
MastraはTypeScriptとの親和性が高く、既存のWebアプリにも組み込みやすいため、AIエージェントを使った検証を素早く始めたい人にとって、かなり扱いやすい選択肢だと思います。
アジアクエストでは、今後もAIエージェントや生成AIを活用した開発に関する勉強会を開催していきます。
connpassのアジアクエスト株式会社グループをフォローして、次回のイベントにもぜひご参加ください。