[Mastra YouTube 解説] Agent Editor ワークショップ — エージェントをビジュアルで反復する
Mastra の公式YouTubeチャンネルにアップされたウィークリーワークショップをお届けします。今回は Agent Editor（エージェントエディター） の機能を詳しく掘り下げた回です。単なる要約にとどまらず、ワークショップの実演の流れそのものを活かした読み物として構成しました。
動画情報
- URL: https://www.youtube.com/live/XTjuRoI7t_k
- 原題: Mastra Workshop: Agent Editor
- 公開日: 2026年4月30日
- 長さ: 約55分
- 言語: 英語
-
出演:
- Alex — Mastra の開発者体験・開発者教育担当。YouTube チュートリアルやワークショップを主催
- Daniel Lou — Mastra フレームワーク本体のエンジニア。エージェントエディターの実装者
概要
Mastra の Agent Editor は、TypeScript のコードを触らずにエージェントのシステムプロンプトやツール設定を変更・バージョン管理・パブリッシュできるビジュアルインターフェースです。エンジニアだけでなく、プロダクトマネージャーや会計士など非技術的なメンバーもエージェントの改善に参加できるようにすることを目的に設計されました。
本ワークショップでは、シンプルなカスタマーサポートエージェントを題材に、Alex がリモートでリンクを受け取ってリアルタイムにプロンプトを編集する様子を実演しながら、エディターの全機能を丁寧に解説しています。
Mastra Editor の公式アナウンスを受けて作った紹介記事はこちらです。
要点
- Agent Editor は「ソースコードとプロダクションの間に存在するステートフルなレイヤー」であり、コードは変更しない
- プロンプトの変更はドラフトとして保存され、明示的にパブリッシュするまで本番に影響しない
- ツールの追加・削除・説明の変更が GUI でできる。MCP ツールの説明もオーバーライド可能
- プロンプトブロック（Prompt Block） を使えば、トーンオブボイスや挨拶文などを複数エージェントで共有・一元管理できる
- リクエストコンテキスト（Request Context） を使ってシステムプロンプトに動的な変数を埋め込める
- 条件付きブロックで「プレミアムティアのユーザーにだけ適用するプロンプト」のような分岐ができる
- Studio のリンクに対して RBAC（ロールベースアクセス制御）を設定できる
- すべてのエディター操作は API でプログラマブルに実行できる
- 「コードとデータベースどちらが信頼できる情報源か」という問いは現在進行形の設計課題
- 安全なロールアウト（段階的なトラフィック配分）機能が近く追加予定
詳細
Agent Editor が生まれた背景
Mastra はもともと TypeScript 開発者向けのオープンソースフレームワークとして始まりました。コードで完全にコントロールできる自由度は開発者にとって魅力ですが、エージェントを「育てる」プロセスはそれだけで完結しません。
プロダクションで優れたエージェントを作るには膨大な試行錯誤が伴います。「このトーンオブボイスが合っているか」「ツールをもう一個追加したらどうなるか」「このフューショット例を入れると精度が上がるか」――こういった問いに答えていくのは、開発者だけでなく、プロダクトマネージャー、デザイナー、ドメイン知識を持つ専門家（例えば会計士が会計エージェントを評価する）なども関わるべき仕事です。
しかし、そのたびにコードのプルリクエストを開いていては効率が悪い。ここに Agent Editor という選択肢が生まれました。ビジュアルインターフェース上でプロンプトを調整し、バージョンを保存し、テストし、満足したらパブリッシュする。 TypeScript を書かなくていい、コードを触らなくていい、でも変更の履歴はちゃんと残る。
デモの設定：Studio をチームで共有する
ワークショップの実演は一味違う設計でした。Daniel がローカルで動かしていたカスタマーサポートエージェント（注文確認・クレジット発行などを行うシンプルなモックエージェント）を、Mastra Studio にデプロイしてリンクを Alex に送るという形をとっています。
mastra studio deploy
このコマンドで Studio をデプロイすると、チームで共有できる URL が発行されます。Daniel がそのリンクに認証を設定してから Alex に渡し、Alex がブラウザからログインして同じエージェントを操作する――というリアルタイムのコラボレーションが実演されました。
Studio は単なるローカルの開発ツールではなく、チームの共有環境です。同じインターフェースを、コードへのアクセスがないメンバーにも提供できます。
エディタータブの基本：バージョンを作ってパブリッシュする
Editor タブを開くと、エージェントの設定がアコーディオン形式で表示されます：
- Variables（変数 / リクエストコンテキスト）
- System Prompt（システムプロンプト）
- Tools（ツール）
ここでプロンプトを編集して「Save Version（バージョンを保存）」を押すと、メッセージ付きでバージョンが作成されます。このバージョンはまだドラフトです。右側のプレビュー欄で動作をテストできますが、外部からエンドポイントを叩いてもこの変更は反映されません。
Alex はデモで、全部大文字で返答するよう指示を追加しました（「HELLO. HOW CAN I HELP YOU TODAY?」という結果を見て会場は笑いに包まれましたが、変更が明確に反映されていることはよくわかりました）。
「Agent Chat」タブは常に最後にパブリッシュされたバージョンと話します。Editor タブで「Publish（パブリッシュ）」を押して初めて、エンドポイントを叩くクライアントアプリケーションにも変更が届きます。このドラフト／パブリッシュの分離こそが、安心して試行錯誤できる仕組みの核心です。
バージョンはいくつでも作れます。過去のバージョン一覧を見て、以前の状態に戻すこともできます。
ツールの設定：GUI でエージェントの「手」を増やす
Agent Editor からできるのはプロンプトの変更だけではありません。ツールの追加・変更・削除も GUI でできます。追加できるツールは3種類に分類されます。
1. Mastra インスタンス上のツール
コードで tools: に定義した独自ツールです。ツールの説明（description）をエディターから変更したり、一時的に無効にしたりできます。
2. 統合ツール（Integration Tools）
Composio と Arcade がデフォルトでサポートされています。API キーをコードに渡すだけで、何百もの SaaS ツール（Gmail、Google Calendar、Slack、GitHub など）にアクセスできるようになります。エディターの UI から「Google News を追加する」のような操作がリアルタイムで行えます。
Daniel がデモで Google News のツールをその場で追加してエージェントに聞いてみると、すぐにそのツールを使えるようになっていました。Arcade や Composio の「ツールのカタログ」を使ってエージェントに機能を足していく体験は、まさにビジュアルなエージェントビルダーです。
OAuth が必要なツール（Gmail など）については、ユーザーごとの OAuth 認証のサポートも現在開発中とのことです。
3. MCPツール（MCP Tools）
コードで設定した MCP サーバーのツールをエディターから追加できます。Mastra インスタンス上のサーバー、リモートサーバー、stdio サーバーのどれでも使えます。
特に面白い点として Daniel が強調したのは、MCPツールの説明（description）をエディターから書き換えられることです。通常、MCP サーバーが提供するツールの説明はサーバー側で固定されています。しかし、同じツールを使っていても、あるエージェントには説明 A がベストマッチで、別のエージェントには説明 B がベストマッチということはよくあります。エディターではツールの実装はそのままに、自分のエージェント向けに説明だけをチューニングできます。
リクエストコンテキストと変数：プロンプトに「動的なデータ」を埋め込む
エージェントの設定を見ると、「Variables（変数）」というセクションがあります。これは Mastra の Request Context Schema（リクエストコンテキストスキーマ） という機能と対応しています。
コードでエージェントに requestContextSchema を定義すると、クライアントからエージェントを呼び出す際に渡せる値の「型」が決まります。例えば：
requestContextSchema: z.object({
customer_name: z.string(),
tier: z.enum(["free", "premium"]),
user_role: z.string(),
})
このスキーマが定義されていると、エディターのプロンプトブロック内で 補間（Interpolation） が使えます：
ユーザーを {{ customer_name }} と呼んで必ず名前で挨拶すること。
ネストされたオブジェクトなら {{ products.name }} のような形式でアクセスできます。エージェントを呼び出すたびに渡すリクエストコンテキストが変わることで、プロンプトの内容もそれに合わせて動的に変わります。
プロンプトブロック：プロンプトを「部品」として再利用する
「トーンオブボイスの指示」「挨拶の文言」「フューショット例」――このような定型的なプロンプトのパーツを、複数のエージェントで同じ内容を繰り返し書いていませんか？それを解決するのが Prompt Block（プロンプトブロック） です。
プロンプトブロックは、エージェントをまたいで共有できる「プロンプトの部品」です。一箇所で更新すれば、そのブロックを参照しているすべてのエージェントに変更が反映されます。左ナビゲーションの「Prompts」タブから、どのブロックがどのエージェントで使われているかを一覧で確認できます。
コードからもプログラムで事前定義できます：
await mastra.editor.blocks.create({
blockId: "holiday-greeting",
content: "Happy holidays! 🎉 How can I make your day special today?",
description: "Holiday season greeting",
})
Daniel はデモで「retail 系なら季節のセールや休日ごとのメッセージングを事前にブロックとして準備しておいて、必要なときにエージェントにアタッチ・デタッチできる」と説明していました。
また、プロンプト全体を単一のブロックに書くのはアンチパターンとも指摘しています。理由は2つ：
- エージェント間でのプロンプトの共有が難しくなる
- プロンプトの順序が LLM の性能に影響するため、ブロックごとに分割することで順序の調整が容易になる
LLM はシステムプロンプトの先頭と末尾に特に注目する傾向があり、中盤の情報は「埋もれる」ことがあります。複数ブロックに分割することで、重要な指示を適切な位置に配置しやすくなります。
条件付きブロック：コンテキストに応じてプロンプトを出し分ける
プロンプトブロックには 条件（Condition） を設定できます。例えば：
- ブロック内容：「このユーザーはVIPです。問題は何があっても必ず解決してください」
- 条件：
tier == "premium"のときだけ適用
こうすることで、無料プランのユーザーには通常の応答をして、プレミアムプランのユーザーにはより優遇された対応をするエージェントが、プロンプトの分岐で実現できます。
デモでは条件設定のフォームに若干の不具合があったため（Daniel が「あとで直します」と笑いながら言っていました）、Studio の「Context（コンテキスト）」ボタンから手動でリクエストコンテキストの値を設定して動作確認していました。
コード側の設定：Editor を有効にする
Agent Editor の有効化は非常にシンプルです。Mastra インスタンスに @mastra/agent-editor パッケージを追加するだけです。
import { Mastra } from "@mastra/core";
import { AgentEditor } from "@mastra/agent-editor";
export const mastra = new Mastra({
agents: { customerSupportAgent },
editor: new AgentEditor({
storage: yourStorageInstance,
}),
});
エージェントエンドポイントを呼び出す際に、バージョン指定ができます：
// 最新の公開バージョンを使用（デフォルト）
GET /api/agents/customer-support/generate
// 特定バージョンにピン留め
GET /api/agents/customer-support/generate?version=abc123
// 最新ドラフトを使用（ステージング環境向け）
GET /api/agents/customer-support/generate?status=draft
推奨構成として Daniel が紹介したのは、**ステージング環境は status=draft（最新ドラフト）、プロダクション環境は status=published（公開済み）**に設定するパターンです。これにより、エディターで調整→ステージングで確認→問題なければパブリッシュ→プロダクションに反映、というフローが自然に組めます。
Studio の認証：RBAC でアクセスを制御する
Mastra Studio を外部公開する場合、認証は必須です。ワークショップでは、デプロイされた Studio に対して RBAC（ロールベースアクセス制御）を設定する方法も紹介されました。
ロールと権限の設計例：
| ロール | できること |
|---|---|
| Admin | すべての操作 |
| Editor | バージョンの作成・テスト・パブリッシュ |
| Member | エージェントの利用のみ（ドラフト閲覧不可） |
コードでは arbback-studio と mastra-auth を使って認証を設定します：
// WorkOS（hosted Studio デプロイ時に自動）または
// カスタム OAuth プロバイダー（セルフホスト時）
現在 Mastra Platform（ホスト版 Studio）では Admin と Member の2ロールのみですが、カスタムロールの定義は近日サポート予定とのことです。
「信頼できる情報源はどこか」という問い
ワークショップの最後で最も深い議論になったのが、ソースオブトゥルース（Source of Truth）問題です。
Josh さんからの質問：
Mastra をコアプロジェクトに統合していますが、Agent Editor のデータはデータベースにあります。エンジニアがローカルで開発するとき、エディターで加えた変更はローカルに反映されていません。どう整合性をとればいいですか？
Daniel の回答：
エージェントエディターは、コードで定義されたプロンプトやツールを「オーバーライドする」仕組みです。エージェントの特定フィールドのコントロールをデータベース側に移譲することになります。全エージェントに適用する必要はなく、特定のエージェントだけ Editor 管理にする選択もできます。
Daniel が提案した導入方法：
- まず1つのエージェントだけ Editor 対応にして様子を見る
- ステージング→プロダクションの流れで感触を掴む
Alex はさらに踏み込んで「エディターで加えた変更をソースコードに同期できればいいですよね」と提案し、「コーディングエージェントならできそうでは？」と冗談交じりに言いながらも、これが本質的な課題だと認めていました。
Daniel：
これは CMS の世界が何年も解こうとしてきた問題と同じです。WordPress、Drupal、Contentful... 完璧な解決策はなく、「信頼できる情報源を複数持つ」と必ず複雑さが増します。機能を追加するためにはある種のコントロールを手放す必要があります。
この課題はドキュメントの整備も含めて現在進行形で取り組まれているとのことでした。
ロードマップ：これから来る機能
Daniel が語った今後の機能：
安全なロールアウト（Safe Rollout）
新バージョンのパブリッシュ後、トラフィックを段階的に増やしていく機能。
- 新バージョンに1%のトラフィックを流す
- スコアリング結果が閾値を超えたら10%に増やす
- さらにスコアが良ければ段階的に引き上げていく
デプロイプラットフォームでよく見られる「カナリアリリース」に近い考え方を、エージェントのバージョン管理に適用するものです。
スーパーバイザーとサブエージェントのバージョン管理
スーパーバイザーエージェントとそれが委任する複数のサブエージェントのバージョンをエディターから一括管理する機能。どのバージョンの組み合わせで実行するかをコントロールできます。
エージェントビルダー（Agent Builder）
Shane のロードマップストリームでスニークピークが公開された機能。現在の Editor を進化させた、よりリッチなエージェント構築体験を提供するものです。Arcade/Composio のような統合ツールや、コードなしでのスキル追加なども含まれる予定。
データセット・eval との連携
エージェントの新バージョンをパブリッシュする前に、データセットに対してスコアリングを実行して品質を確認するフローが、将来的に Editor と密接に連携する予定です。
Discussion