---
title: "Mastra徹底解説 — TypeScriptでAIエージェントを作る仕組みと始め方【2026年8月最新】"
description: "TypeScript製のAIエージェント開発フレームワークMastraを徹底解説。5つの構成部品・動くコード・常時稼働を支えるHarness・AI SDK/LangGraphとの比較・料金まで、非エンジニア向けの始め方つきで紹介。"
url: "https://shiftb.dev/articles/mastra-ai-guide"
publishedAt: "2026-08-19"
updatedAt: "2026-08-19"
author: "立川修平（ぶべ）"
category: "ai-development"
tags: ["Mastra", "AIエージェント", "TypeScript", "AI駆動開発", "業務自動化"]
---

# Mastra徹底解説 — TypeScriptでAIエージェントを作る仕組みと始め方【2026年8月最新】

僕がiDM ReplyというInstagram向けのツールを作った理由は、格好いいものではありません。毎日1〜2時間、Instagramに届くコメントへ手作業でDMを返していて、この作業が何年も続く未来が見えてしまったからです。今そのツールは**有料会員70名**を1人で運営していて、**CS対応は1日30分以下**に収まっています。最初は1日3時間かかっていた仕事です。

当時と今で決定的に違うのは、こういう「人がいなくても動き続ける仕組み」を作るための土台が、既製品として用意されるようになったことです。僕がiDM Replyを作ったときは、会話の記憶の持ち方も、失敗したときのリトライも、定期実行の仕組みも全部自分で書きました。その大半が最初から部品になっているのが**Mastra**という、TypeScript製のAIエージェント開発フレームワークです。

僕はShiftB校長として**150名以上**の受講生のAI駆動開発を伴走しながら、**iDM Reply（月30万円規模・1人運営）やVibely（オンラインスクール向けSaaS。社内で1年以上運用して検証してからSaaS化）**を自分で開発・運営しています。その立場から見ると、Mastraが解こうとしている問題は、エンジニアだけの話ではありません。ChatGPTを毎日開いているのに業務時間が減らない人が引っかかっているのは、まさにここだからです。

この記事では、Mastraが何を解決する道具なのかを整理した上で、5つの構成部品、実際に動く最小コード、「自分がいなくても回る」を実現する機能、Vercel AI SDK・LangGraph・Claude Agent SDKとの比較と料金、そして非エンジニアが今日から取れる現実的な手順まで書きます。数字はすべて2026年8月19日時点で、GitHubとnpmの公開APIおよび公式ドキュメントを直接確認したものを使っています。

## Mastraとは — 「呼ばれたら動くAI」との決定的な差

### TypeScriptでAIエージェントを組み立てるためのフレームワーク

Mastra（マストラ）は、**TypeScriptでAIエージェントやAI機能つきのアプリを作るためのオープンソースのフレームワーク**です。公式サイトの説明を借りると「早い段階の試作から本番運用まで必要なものが一通り入っている」道具立てで、AIへの指示、外部サービスの呼び出し、複数ステップの処理、会話の記憶、動作の記録までを一つの作法で書けるようにしたものです。

フレームワークという言葉に馴染みがなければ、**「アプリを作るときの骨組みと共通部品のセット」**と考えて差し支えありません。家を建てるときに柱や配管を毎回ゼロから設計しないのと同じで、AIエージェントを作るたびに必要になる部分をあらかじめ用意しておくものです。

### ChatGPTやClaude Codeとは、そもそも役割が違う

ここが一番誤解されやすいところなので、先に整理しておきます。ChatGPTやClaude Codeは**「あなたが呼んだときに動く」**道具です。優秀ですが、あなたが開いて、指示を打って、返ってきたものを受け取る、という手順が毎回発生します。

Mastraが作るのは**「あなたが呼ばなくても動く」**側です。毎朝8時に前日の問い合わせを分類してSlackに投げる。フォームに新しい回答が入ったら中身を判定して担当者に振る。Slackで話しかけられたら、過去のやり取りを踏まえて答える。人間がトリガーを引かなくても回り続ける処理を書くための土台です。

ChatGPTを毎日使っているのに業務時間が減らない、という状態にはこの構造的な理由があると僕は見ています。作業がAIで速くなっても、**「AIを呼ぶ」という作業自体は自分に残り続ける**からです。1日20分の作業が5分になっても、その5分を毎日自分で起動しているうちは、仕事の総量は思ったほど減りません。消えるのは、起動ごと誰かに預けたときです。

![呼ばれたときだけ動くAIと、呼ばれなくても動き続けるAIエージェントの違いを示した比較図](https://shiftb.dev/images/articles/mastra-ai-guide-concept.png)

### 作ったのは、Gatsbyを作ったチーム

Mastraを開発しているのは、Sam Bhagwat氏、Abhi Aiyer氏、Shane Thomas氏の3人が中心となったチームです。彼らは以前、**GatsbyというReactのフレームワーク**を作っていました。Web開発の世界で10年近く使われてきた道具を作った人たちが、今度はAIエージェント向けに同じことをやっている、という系譜です。

資金面では、2025年10月8日に**1,300万ドルのシードラウンド**を発表しています。Y Combinatorに加え、Paul Graham氏、Gradient Ventures、VercelのGuillermo Rauch氏、ReplitのAmjad Masad氏といった名前が並ぶ、120名超が参加したラウンドでした。公式ブログでは導入企業としてReplit、SoftBank、Marsh McLennan、PayPal、Adobe、Elastic、Dockerが挙げられています。

### 数字で見るMastraの現在地

いま触る価値があるかどうかは、勢いを見ると判断しやすくなります。2026年8月19日時点で、GitHubとnpmの公開APIから直接取った数字を並べます。

- **GitHubスター数：27,283**（フォーク2,654）
- **npm週間ダウンロード数：約124万**（`@mastra/core`、2026年8月9日〜15日）
- **v1.0のリリース：2026年1月20日**。最初のパッケージ公開は2024年10月2日
- **最新版：1.59.0**（2026年8月14日公開）
- 対応モデル：公式ドキュメント上で**178プロバイダー・6,101モデル**

個人的に一番注目しているのはリリース間隔です。npmの公開日で並べると、1.55.0が7月30日、1.56.0と1.57.0が8月5日、1.58.0が8月12日、1.59.0が8月14日。**16日間で5回のマイナーバージョンアップ**が入っています。開発が活発なのは良いことですが、裏を返せば**仕様が動いている最中の道具**でもあります。この点は後半の落とし穴の章でもう一度触れます。

## Mastraを構成する5つの部品 — Agent・Tool・Workflow・Memory・Harness

### まず全体像を押さえる

Mastraのドキュメントは項目数が多く、初見だと何から読めばいいか分かりにくい構成になっています。ただし中心にある考え方は5つに整理できます。この5つの関係が頭に入っていれば、残りは必要になったときに引けば足ります。

| 部品 | 役割 | 業務にたとえると |
| --- | --- | --- |
| **Agent（エージェント）** | AIモデルに人格と役割を与えたもの。指示文・使うモデル・持たせる道具をひとまとめに定義する | 担当者そのもの |
| **Tool（ツール）** | エージェントが呼び出せる外部処理。DB検索、API呼び出し、メール送信などを型付きで定義する | 担当者が使える社内システムや権限 |
| **Workflow（ワークフロー）** | 決まった手順を順番・並列・分岐で組み立てる仕組み。途中で止めて人の承認を挟むこともできる | 業務フロー図・承認フロー |
| **Memory（メモリ）** | 会話履歴や利用者ごとの情報を保持する。過去のやり取りを踏まえた応答が可能になる | 引き継ぎノート・顧客カルテ |
| **Harness（ハーネス）** | エージェントを常時稼働させる土台。接続が切れても続行、定期実行、目標達成までの反復を担う | 勤務シフトと業務目標の管理 |

### AgentとTool — 担当者と、その人が使える権限

Agentは`instructions`（どう振る舞うかの指示文）と`model`（どのAIモデルを使うか）を持ちます。Mastraの特徴的なところは、モデルの指定が**`"openai/gpt-5.6-sol"`のような単なる文字列**で済むことです。OpenAI用のライブラリ、Anthropic用のライブラリ、と個別に入れる必要がありません。文字列を`"anthropic/claude-sonnet-4-6"`に書き換えれば、それだけでモデルが切り替わります。

Toolは、エージェントに持たせる「できること」です。天気を調べる、在庫を検索する、Slackに投稿する、といった処理を関数として定義し、**入力の形をスキーマで縛る**のが作法になっています。ここが型付き言語であるTypeScriptを採用している旨みで、AIが変な形式のデータを渡してきた場合に実行前に弾けます。

### Workflow — AIに任せる範囲を意図的に狭める道具

ここは特に実務で効いてくる部分です。エージェントは自分で考えて動きますが、**自由に考えさせると結果がブレます**。請求処理や顧客対応のように手順が決まっている仕事では、ブレは事故に直結します。

Workflowは、処理を`createStep()`で定義したステップに分け、`.then()`で順番に、`.parallel()`で同時に実行する形で組み立てます。前のステップの出力の型と、次のステップの入力の型が一致していないとエラーになる設計なので、**つながっていない配線は動かす前に気づけます**。さらに一時停止して人間の承認を挟む機能や、途中経過を保存して後から再開する機能まで用意されています。

AIエージェントの実務投入で失敗する典型は、全部をエージェントの判断に委ねてしまうことだと僕は見ています。決まっている部分はWorkflowで固定し、判断が要る部分だけAgentに渡す。この線引きができるかどうかが、動くデモと使える仕組みの分かれ目になります。

### Memory — 「昨日の話」を覚えている状態を作る

標準のAI呼び出しは、基本的に毎回まっさらな状態から始まります。Memoryは会話の履歴や利用者ごとの情報を保存し、次の会話に引き継ぐための仕組みです。単純な履歴の保持だけでなく、関連する過去の発言を意味的に検索して引っ張ってくる機能もあります。

### Harness — 2026年のMastraを特徴づけている部分

Harnessは、エージェントを**一回の呼び出しで終わらせず、動かし続ける**ための層です。通信が切れても処理が死なない実行方式、バックグラウンドでのタスク実行、定期スケジュール、外部からの合図（シグナル）での起動、そして「目標を達成するまで繰り返す」仕組みが含まれます。

この層があるかどうかが、他のフレームワークと比べたときのMastraの性格を一番よく表しています。詳しくは次の次の章で扱います。

## 最小のエージェントを作る — 3ファイルで動く全体像

### 環境の準備は1コマンド

Mastraのプロジェクトは、次のコマンド1つで作れます。実行すると、作業用のフォルダ、シェル操作の道具、記憶、タスク管理、Web検索、定期実行までが入った汎用エージェントの雛形が生成されます。

```
npm create mastra@latest
```

前提として、Node.js（JavaScriptをパソコン上で動かすための実行環境）が必要です。公式ドキュメントによると**Node.js 22.18.0以降**であればTypeScriptのファイルをそのまま実行できるので、変換作業を挟まずに済みます。加えて、使いたいAIモデルのAPIキー（利用するための鍵となる文字列）を環境変数に設定します。OpenAIなら`OPENAI_API_KEY`、Anthropicなら`ANTHROPIC_API_KEY`という具合です。

### 1. ツールを1つ作る

まずエージェントに持たせる道具を定義します。ここでは公式ドキュメントの例に沿って、天気を返すツールを作ります。`inputSchema`で受け取るデータの形を宣言しているのがポイントで、AIが余計なものを渡してきても実行前に弾かれます。

```
// src/mastra/tools/weather-tool.ts
import { createTool } from '@mastra/core/tools'
import { z } from 'zod'

export const weatherTool = createTool({
  id: 'get-weather',
  description: 'Get current weather for a location',
  inputSchema: z.object({
    location: z.string().describe('City name'),
  }),
  outputSchema: z.object({
    location: z.string(),
    temperatureCelsius: z.number(),
    conditions: z.string(),
  }),
  execute: async ({ location }) => {
    return {
      location,
      temperatureCelsius: 21,
      conditions: 'sunny',
    }
  },
})
```

公式ドキュメントには**「ただのオブジェクトでツールを定義すると、エラーも出ないまま実行されない」**という警告が明記されています。必ず`createTool()`を通す、と覚えておくと最初の数時間を無駄にせずに済みます。

### 2. エージェントに持たせる

次にエージェント本体です。`instructions`に書いた文章がそのまま振る舞いの規定になります。

```
// src/mastra/agents/weather-agent.ts
import { Agent } from '@mastra/core/agent'
import { weatherTool } from '../tools/weather-tool.ts'

export const weatherAgent = new Agent({
  id: 'weather-agent',
  name: 'Weather Agent',
  instructions: '天気を案内するアシスタントです。湿度・風・降水の情報を添えて、簡潔に答えてください。',
  model: 'openai/gpt-5.6-sol',
  tools: { weatherTool },
})
```

### 3. 登録して呼び出す

最後に、作ったエージェントをMastra本体に登録します。ここが全体の入り口になり、エージェントが増えてもこの一箇所を見れば把握できる構造です。

```
// src/mastra/index.ts
import { Mastra } from '@mastra/core'
import { weatherAgent } from './agents/weather-agent.ts'

export const mastra = new Mastra({
  agents: { weatherAgent },
})
```

あとは呼び出すだけです。

```
import { mastra } from './src/mastra/index.ts'

const agent = mastra.getAgentById('weather-agent')
const response = await agent.generate('Weather in SF')
console.log(response.text)
```

ここまでで3ファイル、実質40行ほどです。**「道具を定義する・担当者に持たせる・登録して呼ぶ」**という並びは、業務でいえば、マニュアルを作って、担当者に権限を渡して、窓口に配置するのと同じ順序です。この順序が最後まで変わらないのがMastraの分かりやすさだと感じています。

### Studioで動きを目で見る

Mastraには**Studio**という画面がついています。ローカルで立ち上げると、エージェントとの会話を試したり、ワークフローがどのステップを通ったかを図で確認したり、どのツールがどんな引数で呼ばれたかを追ったりできます。

エージェント開発でしんどいのは、期待通りに動かないときに**どこで判断を間違えたのかが見えない**ことです。ログを自分で仕込んで追いかける作業に何時間も溶かした経験がある身としては、この画面が最初から入っているのは素直にありがたい部分です。

ここまで読んで「コードの意味はなんとなく分かるが、これを自分の業務に当てはめて組めるかは別問題だ」と感じたなら、その感覚は正確です。フレームワークの文法を知ることと、自分の仕事を分解してどこを機械に渡すか決めることは、まったく別のスキルだからです。ShiftBのAIシフトコースは、後者から先に扱います。

## 「自分がいなくても回る」を作る3つの機能

ここからが、Mastraを他のフレームワークと分けている部分です。冒頭に書いた「呼ばれなくても動く側」を作るための具体的な機能を3つ取り上げます。

![Mastraの常時稼働を支える3機能（Harness・Observational Memory・Channels）の関係図](https://shiftb.dev/images/articles/mastra-ai-guide-harness.png)

### Durable Agents — 通信が切れても、処理は死なない

`@mastra/core`のバージョン1.45.0で追加された機能で、エージェントの処理をワークフローの中で走らせることで**状態を保存しながら実行する**仕組みです。公式ドキュメントによれば、これが効くのは次のような場面です。

- スマホや電波の悪い環境で、途中で接続が切れて再接続する可能性がある
- 調査や多段階の作業で、処理が1回のリクエストの寿命より長くかかる
- 誰かが始めた処理の続きを、別の画面や別の人が引き継いで見たい

実行方式は3種類用意されていて、手元での開発には`createDurableAgent()`、バックグラウンド実行には`createEventedAgent()`、本番運用には再試行や監視画面が付く`createInngestAgent()`という使い分けになります。

```
import { Agent } from '@mastra/core/agent'
import { createDurableAgent } from '@mastra/core/agent/durable'

const agent = new Agent({
  id: 'researcher',
  name: 'Researcher',
  instructions: 'You research topics thoroughly.',
  model: 'openai/gpt-5.6-sol',
})

export const durableResearcher = createDurableAgent({ agent })
```

ブラウザを閉じても処理が続き、あとから同じ実行を覗きに行ける。この性質は、5分以上かかる仕事をAIに任せようとした瞬間に必要になります。

### Goals — 「終わったと判断できるまで」やらせる

バージョン1.42.0で追加された機能で、**スレッドに紐づく持続的な目標**を設定できます。エージェントが1回答えて終わりではなく、別のAIモデルが審査役となって「目標が達成されたか」を毎回判定し、達成されるまでループを続けます。

```
const worker = new Agent({
  id: 'worker',
  name: 'worker',
  instructions: 'You complete software tasks end to end.',
  model: 'openai/gpt-5.6-sol',
  memory,
  goal: {
    judge: 'openai/gpt-5-mini',
    maxRuns: 50,
  },
})

await worker.setObjective('Add and test a /health endpoint', {
  threadId,
  resourceId,
})
```

`maxRuns`の既定値は**50回**で、上限に達すると目標は一時停止の扱いになります。無限にAPI料金を消費し続けないための安全弁がある設計です。判定役のモデルを設定しない限りこの機能は何もしない、というのも明記されています。

ここは強力な反面、危ない機能でもあります。目標の書き方が曖昧だと、審査役がいつまでも合格を出さず、50回分のAPI料金だけが溶けます。実際に使うなら**「テストが通ったときだけ達成とみなす」**のように、判定基準を機械的に確かめられる形で書くのが前提になります。

### Observational Memory — 裏方2人が会話を要約し続ける

`@mastra/memory`の1.1.0で入った、長い会話を扱うための記憶方式です。**ObserverとReflectorという2つのバックグラウンドのエージェント**が会話を監視し、要点をまとめた観測ログを維持します。会話が長くなると、生のやり取り全部ではなくこのログのほうが使われます。

設定自体は1行です。

```
const memory = new Memory({
  options: {
    observationalMemory: true,
  },
})
```

長い会話をそのまま毎回AIに渡すと、料金も応答時間も膨らみます。議事録を毎回全文読み返すのではなく、要約と決定事項だけ引き継ぐようにするのと同じ発想です。ストレージ（保存先のデータベース）の設定が必須になる点だけ注意が要ります。

### Channels — Slackやチャットの中に住まわせる

非エンジニアの業務という観点では、ここが一番実用に近い機能だと思っています。バージョン1.22.0で追加された**Channels**は、エージェントを**Slack、Microsoft Teams、Discord、Telegram、WhatsApp、GitHub、Linear**といった普段使っているツールに接続する仕組みです。

```
import { Agent } from '@mastra/core/agent'
import { createSlackAdapter } from '@chat-adapter/slack'

export const yourAgent = new Agent({
  id: 'your-agent',
  name: 'Your Agent',
  instructions: 'You are a helpful assistant.',
  model: 'openai/gpt-5.6-sol',
  channels: {
    adapters: {
      slack: createSlackAdapter(),
    },
  },
})
```

社内にAIを導入するときの本当の壁は、性能ではなく**「新しい画面を開いてもらえない」**ことです。どれだけ便利でも、既存の業務の外に置かれたツールは使われなくなります。普段のSlackのスレッドに同席させられるかどうかは、導入が定着するかどうかを直接左右します。

### 良い任せ方と、悪い任せ方

機能が揃っていても、渡し方を間違えると使えません。実際に受講生の相談を受けていて、差が出るのはここです。

**悪い例：**「問い合わせ対応をいい感じにやっておいて」とエージェントに丸投げする。判断基準がないので返答の質が日によって変わり、確認作業が増えて結局は手作業より時間がかかる。

**良い例：**「問い合わせを『料金』『不具合』『その他』の3つに分類し、料金は定型文で返信、不具合は担当者にSlackで通知、その他は下書きだけ作って人が確認」とWorkflowで手順を固定し、分類の判断だけをAgentに渡す。

後者は地味に見えますが、こちらのほうが確実に時間が減ります。僕がiDM ReplyでCS対応を1日3時間から30分以下にできたのも、AIを賢くしたからではなく**返答パターンを分類して、判断が要る部分だけ手元に残した**からでした。

## Mastra vs AI SDK vs LangGraph vs Claude Agent SDK — 選び方と料金

### 数字で見る勢力図

「Mastraは流行っているのか」という問いには、npmのダウンロード数で答えるのが一番正直です。2026年8月9日〜15日の週間ダウンロード数を、npm公開APIから取得しました。

| パッケージ | 週間ダウンロード数 | 性格 |
| --- | --- | --- |
| `ai`（Vercel AI SDK） | 約1,837万 | チャットUIとストリーミング表示に強い、事実上の標準 |
| `@anthropic-ai/claude-agent-sdk` | 約802万 | Claude Codeと同じ仕組みを自分のプログラムから使う |
| `@langchain/langgraph` | 約224万 | 複雑な状態遷移と分岐に強い。Python側の実績が厚い |
| `@mastra/core` | 約124万 | エージェントを製品として組み上げる部品が一式そろう |
| `@openai/agents` | 約108万 | OpenAIのモデルを前提にした軽量な構成 |

規模でいえばMastraは最大手ではありません。ただ、v1.0が2026年1月20日で、そこから7ヶ月で週124万まで来ているのは十分に速い部類です。参考までに、同じチームが以前作ったGatsbyは4年かけて週19万ダウンロード規模に到達したと公式ブログに書かれています。

### 選び方は「何を作るか」で決まる

4つは競合というより、担当範囲が違います。僕の整理は次の通りです。

- **Vercel AI SDK**：Webサービスにチャット欄やAI機能を「足す」なら第一候補。文字が流れるように表示される部分の実装は、これが最も洗練されています。ただし常時稼働や記憶の管理は範囲外なので、自分で用意することになります
- **Claude Agent SDK**：Claude Codeと同じ動きをプログラムから呼びたいとき。ファイル操作やコマンド実行を伴う作業に強く、開発まわりの自動化と相性が良い選択肢です
- **LangGraph**：状態の遷移が複雑で、分岐とループが入り組んでいる処理を精密に制御したいとき。Pythonでの運用実績が厚いのが強みです
- **Mastra**：エージェント自体が製品の中心にあり、記憶・定期実行・Slack連携・評価・監視まで含めて一式で組みたいとき。TypeScriptで完結させたい場合の有力候補です

併用も普通にあります。実際、Mastraは画面側でAI SDKのUI部品と組み合わせる構成が公式に案内されていますし、MCP（AIに外部ツールを繋ぐ共通規格）やA2Aといった外部連携の規格にも対応しています。どれか1つを選んで他を捨てる、という判断は必要ありません。

### 料金 — フレームワーク自体は無料

Mastra本体は**Apache 2.0ライセンスのオープンソース**で、自分のサーバーで動かす限り無料です（企業向けの一部コードは別ライセンス）。有料になるのは、公式のホスティングサービスであるMastra Cloudを使う場合です。

| プラン | 月額 | 主な内容 |
| --- | --- | --- |
| **セルフホスト** | 無料 | Apache 2.0。自分のサーバーやVPSで動かす |
| **Starter** | $0 | 記録イベント10万件、CPU 24時間、データ保持15日。ユーザー数・プロジェクト数は無制限 |
| **Teams** | $250 | 記録イベント100万件、CPU 250時間、データ保持6ヶ月、SSO対応 |
| **Enterprise** | 要問い合わせ | 権限管理、監査ログ、稼働率の保証、専任サポート |

注意しておきたいのは、**実際に効いてくる費用はフレームワーク側ではなくAIモデルのAPI料金だ**という点です。エージェントは1つの依頼に対してモデルを何度も呼びます。ツールを使い、結果を読み、また考える、という往復が発生するためです。前述のGoalsのように反復する機能を使えば、この回数はさらに増えます。個人で試す段階なら、月数百円から数千円の枠を決めて、超えたら止める運用にしておくのが安全です。

## つまずきポイントと、非エンジニアの現実的な5ステップ

### 先に知っておきたい4つの落とし穴

公式ドキュメントを読み込んだ上で、最初に引っかかりやすいと感じた箇所を挙げます。

- **ベータ表記の機能が混ざっている**：Durable AgentsもGoalsも、ドキュメントに「メジャーバージョンが上がらないまま仕様変更が入る可能性がある」と明記されています。業務の根幹に据えるなら、この注記の有無を必ず確認してから使うべきです
- **モデル指定の書式を間違えやすい**：`openai/gpt-5.6-sol`のようにスラッシュ区切りで書く必要があり、コロン区切りやプロバイダーのオブジェクトを渡す書き方は想定されていません。ドキュメントにわざわざ警告が書かれているということは、それだけ間違える人が多い箇所だと読めます
- **記憶系はストレージ設定が前提**：Observational MemoryもGoalsも、保存先のデータベースを設定していないと動きません。まず動かすだけならファイルベースの簡易DBで足ります
- **更新が速い**：前述の通り、16日間で5回のマイナーバージョンアップが入るペースです。ネット上の解説記事が数ヶ月で古くなる可能性が高いので、**迷ったら公式ドキュメントを一次情報として当たる**習慣が要ります

### 非エンジニアが今日から取れる5ステップ

「Mastraを勉強する」から入るのは、順番として損だと考えています。道具の使い方を先に覚えても、渡す仕事が決まっていなければ手が止まるからです。僕が勧めるのは次の順序です。

1. **Step 1：自分の作業を1週間記録する（所要：1週間・1日5分）**  
   何にどれだけ時間を使ったかを書き出します。ここで探すのは「大変な仕事」ではなく**「毎週必ず発生する、判断が少ない仕事」**です。週報の集計、問い合わせの一次分類、定例資料の更新あたりが典型です
2. **Step 2：1つ選んで手順書に落とす（所要：1〜2時間）**  
   選んだ作業を、他人に引き継げる粒度で文章にします。この作業自体がエージェント設計の8割です。手順書に書けない仕事は、AIにも任せられません
3. **Step 3：まずClaude CodeやChatGPTで手動再現する（所要：数日）**  
   いきなりフレームワークに行かず、手順書をそのまま指示文として貼り付けて動かします。ここで成果物の品質が業務水準に届かないなら、自動化しても届きません
4. **Step 4：Mastraの雛形を動かす（所要：1〜2時間）**  
   `npm create mastra@latest`で生成し、Studioを開いて挙動を眺めます。目的はコードを書くことではなく、**エージェント・ツール・記憶が画面上でどう繋がっているかを見ること**です
5. **Step 5：手順書をWorkflowの形に写す（所要：1〜2週間）**  
   Step 2の手順書のうち、決まりきった部分をステップに分解し、判断が必要な部分だけエージェントに渡します。ここまで来て初めて「自分がいなくても回る」状態が視野に入ります

### やらないほうがいいこと

逆に、時間を溶かしやすい進め方も挙げておきます。ドキュメントを頭から全部読む、いきなり複数のエージェントを協調させる構成に挑む、業務データを使う前にセキュリティの設計を後回しにする。この3つは、途中で必ず止まります。

特に3つ目は現実的なリスクです。顧客情報や社内資料を扱うなら、どのデータが外部のAIに送られるのかを把握した上で始める必要があります。ここを曖昧にしたまま社内展開すると、動くものができても止められる結果になります。

この5ステップを読んで手が止まるとしたら、多くの場合はStep 1かStep 2です。技術ではなく**自分の仕事を分解して、どこを機械に渡せるか判断する部分**で詰まります。ここは1人で考えても答えが出にくく、実際に何度も作った人に自分の業務を見てもらうのが最短です。ShiftBのAIシフトコースでは、無料相談会で受講前にこの分解を一緒にやっています。まず自分のケースが自動化に向いているかを確かめるところから使ってもらえればと思います。

## よくある質問（FAQ）

### Q1. プログラミング未経験でもMastraは使えますか？

Mastra自体はTypeScriptのコードを書く前提の道具なので、完全な未経験からいきなり実務投入するのは現実的ではありません。ただし、**コードをAIに書かせながら理解していく進め方**であれば十分に射程に入ります。実際、ShiftBの受講生には非エンジニアから入って業務アプリを自分で作れるようになった人が多数います。順序としては、まずClaude Codeなどで小さなアプリを作れる状態を経由してからMastraに触るのが遠回りに見えて速いはずです。

### Q2. ChatGPTのGPTsやDifyとは何が違いますか？

GPTsやDifyは、画面上の操作で組み立てられる手軽さが利点です。一方Mastraはコードで書くぶん、**既存の社内システムとの接続、細かい条件分岐、バージョン管理、テスト**といった「業務システムとして運用する」ための要求に応えやすくなっています。試作までなら前者が速く、業務に載せて何年も動かすなら後者、という住み分けだと考えています。

### Q3. 学習コストはどれくらいですか？

TypeScriptでWebアプリを作った経験がある人なら、雛形を動かして最初のエージェントを作るまでは数時間の範囲です。ただし**Workflow、Memory、Harnessまで含めて業務に耐える形にする**となると話が変わります。ドキュメントの構成を見る限り、扱う概念の数はかなり多く、腰を据えて数週間は必要だと見ています。

### Q4. 日本語の情報は足りていますか？

日本語の入門記事はいくつか出ていますが、Mastraの更新ペースを考えると**数ヶ月前の記事が現行仕様と食い違っている可能性が高い**状況です。実際、公式サイトのトップページと公式ドキュメントで対応プロバイダー数の表記が違っていました。この記事の数字を含め、重要な判断をするときは公式ドキュメントを直接確認することをお勧めします。

### Q5. 個人開発や副業で使う価値はありますか？

作るものがエージェントそのもの、あるいは常時動き続ける自動化なら価値があります。逆に、一般的なWebサービスにAIチャットを足すだけならVercel AI SDKのほうが構成が軽くて済みます。副業として受注する観点でいえば、**Slack連携と定期実行を含む業務自動化**は法人からの需要が見えやすい領域で、そこにMastraの機能は素直に噛み合います。

### Q6. 会社のデータを使っても大丈夫ですか？

Mastraは自分のサーバーで動かせるので、**データの置き場所を自社内に保つ構成は取れます**。ただしAIモデルの呼び出し自体は外部のAPIを使うため、モデルに渡す内容は外に出ます。個人情報や機密情報を扱うなら、渡す前に伏せる処理を入れるか、その情報を渡さずに済む設計にするのが前提です。社内展開の前に、情報システム部門とデータの流れを確認しておくべき部分です。

## まとめ — 「使う側」から「仕組みを置く側」へ

Mastraは、TypeScriptでAIエージェントを組み立てるためのフレームワークです。2026年1月20日にv1.0が出て、8月時点でGitHubスター27,283、週間ダウンロード約124万。Gatsbyを作ったチームが開発し、1,300万ドルのシード資金を得て、16日間で5回というペースで更新が続いています。

機能面で押さえるべきは、Agent・Tool・Workflow・Memory・Harnessの5つです。中でもHarnessまわりの機能群、つまり通信が切れても死なない実行、目標を達成するまでの反復、Slackへの常駐といった部分が、この道具の性格を決めています。ChatGPTやClaude Codeが「呼ばれたら動く」道具だとすれば、Mastraが作るのは**呼ばれなくても動き続ける仕組み**のほうです。

ただ、記事の後半で書いた通り、本当の難所はフレームワークの文法ではありません。自分の仕事を分解して、どこを固定した手順にして、どこをAIの判断に渡すか決める部分です。ここは道具が新しくなっても自動的には解決しません。iDM ReplyでCS対応を1日3時間から30分以下にできたのも、賢いAIを入れたからではなく、返答を分類して判断の必要な部分だけ手元に残したからでした。

AIを毎日使っているのに仕事が減らない状態から抜けるには、AIを速く使う練習ではなく、**仕組みを置いて自分を外す**側に回る必要があります。Mastraはその選択肢の1つとして、今かなり有力な位置にいると見ています。まずは自分の1週間の作業記録を取るところから始めてみてください。渡せる仕事は、たいてい思っているより近くにあります。
