Mastra、自社開発のオープンソースファクトリ「Factory」をベータ公開

本日、Mastra Factory のベータ版をリリースしました。

これは私たちが自社の課題解決のために構築したオープンソースのソフトウェアファクトリーです。現在、当社のプルリクエスト（PR）の 25〜35% を自動生成し、課題（Issue）の 50〜60% を自動的にクローズしています。このツールは独自の Mastra プリミティブを基盤としており、貢献や協働のプロセスに根本的な変化をもたらしました。

ファクトリーの仕組み

Mastra Factory は、GitHub、Linear、Slack を設定可能なボードに接続します。当社のワークフローでは「Intake → Triage → Planning → Build → Review → Done」の 6 つのステップを踏みますが、ユーザーは独自のフローを設定し、各ステップを手動または自動モードで実行できます。

各ステップでは、エージェントがサンドボックス環境内で動作し、タスクの開始、変更のレビュー、作業の進行に関するルールに従います。差分（diff）の確認やディスカッションへの参加、アクションの承認、そして自分が注力すべきタスクの確認が可能です。各作業アイテムは、チャット、ツールの活動状況、ワークスペース内のファイルを含むエージェントセッションとして展開されます。

デモはこちら：

お使いのブラウザは動画タグに対応していません。

これまでの成果

Mastra はコミュニティからの貢献とコアチームによるメンテナンスが行われるアクティブなオープンソースプロジェクトです。週に 100 件以上の課題が開かれ、200〜250 件の PR がマージされています。7 月にファクトリーをアルファ版として導入して以来、PR の 25〜35% を自動化し、課題の 50〜60% をクローズする成果を上げています。

マージされた PR：

クローズされた課題：

ファクトリーの導入により、エンジニア数を減らしつつもメンテナンス能力は向上し、課題数の急増も抑制されています。

調査によるトリアージの改善

これらの改善を推進している要因とは何でしょうか？

一例として、イシューの受け付けプロセスの改善が挙げられます。コミュニティ内のユーザーは GitHub で多様な課題を報告しますが、その中には実際に存在するものもあれば、セットアップ手順に従わなかったことが原因のものや、私たちが再現できるほど具体的でないものも多く含まれています。

以前はラベル付けと歓迎コメントを提供するボットを構築していましたが、Factory を導入することで、次の担当者が活用できる調査結果が得られるようになりました。これには診断内容、裏付けとなる証拠、仮定、そして再現テストの結果が含まれます。例えば、A2A に関する調査では、6 つの失敗した再現アサーションを特定し、サーバー統合が責任を持つべき対象であると結論付けています。

Factory がこれほど正確に作業を行える理由は、Mastra の観測メモリ機能にあります。コーディング調査ではファイル内容や検索結果、テスト出力など大量の一時的なテキストが発生しますが、それらは重要な情報のみを抽出した行ごとのログへと圧縮されます。

完全設定可能なイシューパイプラインの構築

当初は「完全自動」モードから始めました。イシューが開始されると、レビュー段階に至るまで各ステージを自動的に実行する仕組みでした。しかし、このアプローチにはいくつかの問題が発生しました。バックログの取り込み時に処理が集中し、インフラに負荷がかかるだけでなく、レビューが困難な作業量が生じてしまったのです。

その結果、私たちは手動モードへ移行せざるを得なくなり、最終的には各ステージを個別に設定可能にする方針を決定しました。

例えば、トリアージは自動的に実行される一方で、計画、実装、レビューの各工程は手動で進めることも可能です。あるいは、バグ修正はプロセス全体を自動で流すことができますが、機能リクエストについてはその限りではありません。

最大の課題は、上位工程での誤った前提が下位工程で問題を引き起こすことです。マーク・トウェインはこう言っています。「あなたが知らないことがあなたをトラブルに巻き込むのではありません。確信しているのに実際にはそうではないことが、あなたをトラブルに陥れるのです」。

ある事例では、エージェント型観測ツールが誤ったアラートを発令しました。別の事例では、トリアージ用エージェントが収益損失を誤って特定し、クローズすべきプルリクエスト（PR）を生成してしまいました。

エージェントにウィキを提供し、セッション管理・誘導・サンドボックス化を行う

ファクトリーを支えるのは、新しい知識ベースであるグラフベースのウィキです。ノードはエンティティ（事実）であり、出典や関連するセッションへのリンクが付いています。エッジはエンティティ間の関係性を表します。各ページには名称、種別を示す文字列、コンテンツ、および他のページへのリンクが含まれます。これは専門的な知識キュレーターエージェントによって構築されます。

この知識グラフはまもなく、独立したプリミティブとして公開される予定です。

Mastra の AgentController クラスは、モデルとツールのループを囲むライブなエージェントセッションを管理します。これにより、Factory は作業開始、更新情報の提供、入力待ちでの一時停止、適切な状態での継続といった一貫した方法を提供できます。

ステアリングは Signals を介して行われます。実行中のワーカーに対して、ユーザーがスコープを修正したり、コラボレーターが文脈を追加したり、他のエージェントが発見を送ったりできます。ワーカーは、別の会話を開始することなく、実行が進むにつれてこれらの更新を取り込むことができます。

Factory はローカル環境とクラウドの両方で実行をサポートしています。ローカルで実行する場合でも、必要に応じてコードの記述や実行にリモートサンドボックスを利用可能です。

貢献モデルの変化について

私たちは 10 年以上にわたりオープンソースプロジェクトを運営してきました。小さな不具合への対応は、これまで新規コントリビューターがプロジェクト構築に参加する手段として機能してきました。時には、コントリビューターが想定外のやり方で修正を行うケースもあり、そのやり取りが行き来することもあります。

Factory では、こうしたバグを修正するコストが劇的に低下したため、従来の貢献モデルはもはや意味をなさない状況となりました。私たちは、コミュニティからのプルリクエスト（PR）を推奨する方針から、詳細な不具合再現手順の報告を促す方針へと転換し、マージされた PR に対しては不具合報告者のクレジットを明記する仕組みを導入します。

はじめに

Factory のインストールは以下のコマンドで行えます：

npm create factory@latest

手順の解説動画をご覧になりたい場合は、Abhi と Alex が主催する「Build and Own Your Software Factory」ワークショップ（こちら）へご参加ください。