Mastraと先進エージェントで開発を加速！Gremlinが解決する現場の課題とアーキテクチャ

はじめに

エンジニアリングチームの生産性向上と開発体験の改善は、常に重要な課題です。本記事では、Mastraを活用し、わずか1日で開発された「Gremlin」という先進的な自己改善型エージェントについてご紹介します。Gremlinは、既存の開発プロセスにおける様々な「摩擦」を解消し、チームの働き方を大きく変革しました。本記事では、Gremlinが解決しようとした具体的な課題、その革新的なアーキテクチャ、そして開発を通じて得られた教訓を共有いたします。

Gremlinが解決を目指した課題

私たちがGremlinを開発する上で、主に以下の3つの課題を解決したいと考えていました。

1. エンジニアのローカル環境からワークフローをクラウドへ

多くのエンジニアが同時に複数のサブエージェントをローカルマシンで実行している状況がありました。これにより、以下のような問題が発生していました。

リソースの枯渇: ローカル環境で多くのプロセスが動くことで、PCのリソースが圧迫され、ビデオ会議中にカメラがちらついたり、オーディオが途切れたりすることがありました。
作業の停滞: 現在のタスクの実行中に、さらに新しい計画の策定やセキュリティ脆弱性（CVE）の調査など、様々なバックグラウンドタスクがローカルで進行し、メインの作業に集中できない状況を生み出していました。

私たちは、このようなワークフローをクラウドに移行することで、エンジニアのローカルシステムを、本来の「計画立案」や「調査」といった作業のために解放したいと考えました。

2. 「ペーパーカット」問題の解消

「ペーパーカット」とは、ソフトウェア開発において発生する小さな、しかし頻繁な摩擦点を指します。これらは、以下2つの主要な問題につながっていました。

PRに小さすぎる課題の蓄積: 単一のプルリクエスト（PR）としては小さすぎる修正点や改善点が多く、これらが蓄積されがちでした。結果として、ユーザーは不便を強いられ、バグは増え続けてしまいます。
プロジェクト中の「寄り道（サイドクエスト）」: 主要なプロジェクトの遂行中に、長らく悩まされていた小さなバグや不具合に遭遇し、急遽その修正に取り掛かってしまうことがあります。これは、メイン機能のデプロイを遅らせたり、プロジェクト全体の進捗を妨げたりする原因となります。

私たちは、これらの「ペーパーカット」を効率的に解決する仕組みを求めていました。

3. コミュニケーションツール（Slack）でのエージェント活用

現代の開発チームにおいて、多くの議論やコンテキストがSlackのようなコミュニケーションツールで共有されています。私たちは、この豊富なコンテキストをエージェントに活用させたいと考えました。

Slackでの作業完遂: Slackでの議論後、エージェントが直接タスクに取り掛かり、Linearのようなタスク管理ツールを介さずに、素早く作業を完了できるような仕組みを目指しました。これにより、より迅速な開発とデプロイが可能になります。

追加の目標（サイドクエスト）

上記の主要な課題に加え、私たちは以下の2つの目標も掲げていました。

1. 単一モデル・プロバイダーへの依存回避

私たちは、特定のAIモデルやプロバイダーへの依存を避けたいと考えていました。Hugging FaceやAnthropicなどで発生したようなモデルの急な変更や撤退のリスクを考慮し、Prismaでは「モデル非依存」のアプローチを重視しています。これは、構築するプロジェクトやツールが、モデルやプロバイダーがいつでも変更される可能性があるという前提で設計されることを意味します。

2. 既存ソリューションの再構築を避ける

優れたコーディングエージェントはすでに存在します。そのため、私たちは数週間かけて既存のものを再構築するのではなく、最小限の時間で実験を行い、価値を証明することを重視しました。もし価値が証明できなければ、そのアイデアは破棄し、既存のソリューションを購入することを検討する方針でした。

先進エージェント「Gremlin」の紹介

これらの課題と目標を解決するために開発されたのが「Gremlin」です。

Gremlinは、Mastra上に構築されたクラウドエージェントであり、与えられたコンテキストに基づいてコードをデプロイする能力を持っています。その主な特徴は以下の通りです。

豊富なアクセス権: GitHubシークレットやナレッジベースにアクセス可能です。
多様なインターフェース: Slack、Mastra Studio、およびAPI経由で他のエージェントからも呼び出すことができます。
幅広い対応範囲: 小さなバグ修正から、大規模な機能開発まで、様々なタスクを処理できます。

Gremlinのアーキテクチャと進化

初期アーキテクチャとその限界

当初のGremlinのアーキテクチャは非常にシンプルで、Slackで簡単な指示（brief）を作成し、それを直接OpenCodeに送ってPRを作成するというものでした。

しかし、この初期設計にはいくつかの重要な課題がありました。

フィードバックの欠如: OpenCodeインスタンスが失敗した場合や、指示が不完全だった場合に、オペレーター（指示を出した人物）にフィードバックを返す仕組みがありませんでした。
失敗検出の限界: エージェントが作業を完了できない場合でも、その理由や状況をオペレーターに伝える手段がありませんでした。

Mastraの導入によるブレイクスルー

この課題を解決するため、私たちはOpenCodeサンドボックスとSlackの間にMastraを導入するというシンプルな変更を加えました。この変更は、Gremlinの価値を劇的に向上させました。

対話型モデルによるフィードバック: Mastra（GLM 5.2を搭載）が間に入ることで、Gremlinは単に指示を実行するだけでなく、オペレーターと対話できるようになりました。
- 例えば、「何をすべきか分かりません」「どのコードベースについて話しているのですか」「変更を完全に理解できません」といった形で、不明瞭な指示に対して質問を返すことができます。
- これにより、OpenCodeに作業を渡す前に、指示を明確化し、無駄な処理を防ぐことが可能になりました。
セキュリティ層としての機能: Mastraエージェントは、セキュリティ面でも重要な役割を果たします。
- GitHubリポジトリへのアクセス権や環境変数といった機密情報は、Mastraエージェント内に安全に管理されます。
- MastraがOpenCodeサンドボックスをプロビジョニングする際、適切なトークンを照合し、環境変数を注入し、リポジトリをクローンします。これにより、サンドボックスの「爆発半径（blast radius）」、つまり潜在的な被害範囲が非常に限定されます。
- Hugging Faceで発生したようなインシデントがあった場合でも、その影響は鍵が有効な期間に限定されるため、強固なセキュリティ層として機能します。
評価と反復機能: Mastraを介することで、GremlinエージェントはOpenCodeの結果を自動的にレビューし、PRがマージされる前に、納得のいく結果が得られるまで反復的に改善を行うことができます。

このMastraの導入は、一度きりの処理しかできなかった初期アーキテクチャを、極めて価値の高い、自己改善型のシステムへと変貌させました。

技術スタック

Gremlinの技術スタックは非常にシンプルでありながら堅牢です。

Prisma Compute: ベアメタルマシン上でBunランタイムを動かしています。
Prisma Postgres: 同一のベアメタルマシン上でPostgresを運用しています。

これにより、ComputeとPostgres間のレイテンシーは非常に短く、Mastraエージェントを非常に安定して動作させることができています。

Gremlinが実現したこと（例）

ライブデモの代わりに、Gremlinが実際に達成した例をいくつかご紹介します。

ログの永続化: サンドボックスは本来エフェメラル（一時的）ですが、「ログを永続化して」とGremlinに指示するだけで、データベースにログを保存できるようになりました。Gremlinが自律的にデータベースを操作し、この機能を実現しました。

これらの事例は、Gremlinが単なるコンセプトではなく、実際にチームの生産性向上に貢献していることを示しています。

まとめ

本記事では、Mastraを活用して開発された先進的な自己改善型エージェント「Gremlin」についてご紹介しました。Gremlinは、エンジニアのローカル環境のリソース枯渇、開発における小さな摩擦点（ペーパーカット）、そしてコミュニケーションツールでのコンテキスト活用といった、現代の開発現場が抱える具体的な課題を見事に解決しています。

Mastraの導入により、Gremlinは単なる指示実行エージェントから、対話を通じて指示を明確化し、強固なセキュリティ層を提供し、結果を自律的に評価・反復改善する、真に先進的なエージェントへと進化しました。この事例は、AIエージェントが開発プロセスにもたらす可能性と、効率的でセキュアな開発プロセスの実現を示唆しています。

参考動画

https://www.youtube.com/watch?v=_luC8udp2co

ポイント