AutoBE レビュー: コンパイラ検証で組み立てる TypeScript バックエンド生成エージェント

AutoBE が埋めようとしている穴は「動かない生成コード」である

LLM にバックエンドを書かせると、それらしいコントローラとスキーマは出てくるが、型が合わずビルドが通らない、テストが存在しない、という状態になりやすい。AutoBE はこの問題を、生成そのものよりも生成物の検証に重みを置いて解こうとしている。README は生成されたバックエンドについて「designed to be 100% buildable by AI-friendly compilers」と述べており、ビルド可能性を設計目標として明示している。対象読者は、TypeScript のバックエンドをこれから立ち上げる人、あるいは要件定義から API 仕様、DB 設計、テストまでを一続きの成果物として残したい人だ。README はジュニアの学習素材になり、シニアの生産性を上げると位置づけているが、これは提供側の主張であり、効果を第三者が検証した数値は示されていない。

Facade Controller の下に 5 つの機能エージェントが並ぶ

README のフロー図によれば、構成は二層である。上位に Facade Controller があり、その下に Analyze、Database、Interface、Test、Realize という 5 つの機能エージェントがぶら下がる。Facade Controller が要件分析、ERD、API 設計、テストコード、本体プログラムという順にタスクを振り分ける。この順序は README が「Waterfall Model」として文書化している考え方に対応しており、要件が固まってから DB、DB が固まってから API、という依存関係を崩さない。各エージェントの出力は下段のコンパイラ群に渡される。Database エージェントは Database Compiler で検証され、Interface エージェントは OpenAPI Compiler を生成し、Test エージェントは Test Compiler で解析され、Realize エージェントは Hybrid Compiler でコンパイルされる。注目したいのは、これらが単なる出力先ではなくフィードバック経路として図に描かれている点で、コンパイルエラーがエージェント側に返る前提の設計だと読める。

生成物は NestJS と Prisma の既存慣習に着地する

AutoBE は独自フレームワークを発明しない。README の Backend Stack は TypeScript、Prisma ORM、NestJS Framework の 3 つを挙げており、生成物はこの構成に従う。autobe-examples の ERP サンプルでは、DB 設計が docs/ERD.md と prisma/schema に、API 設計が src/controllers と src/api/structures に、E2E テストが test/features/api に、実装が src/providers に置かれている。つまり生成結果は、NestJS のコントローラとプロバイダ、Prisma のスキーマファイルという、その分野の開発者が既に知っている形で出てくる。ここは採用判断で効く。独自 DSL を覚える必要がなく、生成後に人間が手で直せる。一方、スタックが固定されるという意味でもある。Fastify や Drizzle を使いたい場合、この構成はそのままでは当てはまらない。

起動手順は playground をローカルで動かす一点に集約される

README が示す手順は短い。git clone https://github.com/wrtnlabs/autobe --depth=1 で取得し、cd autobe の後 pnpm install、そして pnpm run playground を実行する。playground は http://localhost:5173 で待ち受ける。README によれば、この画面でチャット形式のやり取りを行い、複数セッションの管理と、qwen3.5-397b-a17b のようなローカルモデルを含む複数の LLM プロバイダの切り替えができる。会話の進め方も例示されており、要件分析、DB スキーマ設計、API 仕様作成、E2E テスト作成、API 実装という 5 段階のプロンプトを順に投げる流れになっている。加えて http://localhost:5173/replay/index.html にリプレイ機能があり、開発チームのテストとベンチマークのセッションを閲覧できる。設定項目の詳細は README には書かれておらず、Configuration のページに委ねられている。

「100% ビルド可能」はテストが通ることを意味しない

ここは README の表現を慎重に読むべき箇所だ。ビルドが通ることと、生成された API が業務要件を満たすことは別である。AutoBE は E2E テストを生成し、Test Compiler で解析するが、テストが検証するのは生成物自身が定義した振る舞いであり、元の要件文との突き合わせを保証するものではない。要件分析の段階で解釈がずれれば、そのずれは下流の DB 設計と API 仕様に伝播する。Waterfall 型の順序を採る以上、上流の誤りは後から戻りにくい。もう一つの現実的な制約は、README が示す利用経路がリポジトリの clone とローカル実行だという点である。ホスト型サービスとしての提供は README には書かれておらず、動かすには Node 環境と pnpm、そして LLM プロバイダの用意が要る。手軽に試したいだけの読者には、この前提は重い。

NestJS を手で書く場合との差は工程の順序にある

比較対象として素直なのは、NestJS と Prisma のプロジェクトを自分で立ち上げ、要件定義書と ERD を別途書き、テストを後から足す進め方である。この場合、設計判断はすべて人間の側にあり、生成物という概念は存在しない。AutoBE との違いは、成果物の種類ではなく順序にある。AutoBE は要件分析、ERD、API 仕様、テスト、実装という 5 つを一つのセッションの中で連続して作る。つまり、ドキュメントとコードが同じ会話から生まれ、互いに参照できる状態で出てくる。手書きの進め方では、設計書とコードが乖離しがちなのに対し、AutoBE は乖離そのものを小さくしようとしている。ただしこれは、生成された仕様をそのまま正とする場合に限り利点になる。既存の設計書や社内の API ガイドラインに合わせたい場合、生成物を後から寄せる作業が発生し、手書きより遠回りになる可能性がある。

AGPL-3.0 とメンテナンス負荷をどう見るか

ライセンスは AGPL-3.0 である。README のバッジもこの表記で、ライセンスファイルへのリンクが示されている。AGPL はネットワーク越しに利用させる場合にもソース開示を求める条項を含むため、AutoBE を組み込んだサービスを外部に提供する形態では条件の確認が要る。ここでは法的助言はできないので、配布形態が決まっているなら法務に確認するのが妥当だ。メンテナンス面では、リポジトリの最終 push が 2026-06-24、直近のリリースが v0.31.1（2026-04-10）、その前が v0.31.0 と v0.30.5 で、いずれも 2026 年 3 月から 4 月にかけて出ている。バージョン番号が 0.x 台であること、リリース間隔が短いことから、API と生成物の形が今後も動く前提で接するべきだ。ロードマップも Alpha、Beta、Gamma が done、Delta が active と記載されており、安定版に到達していない。生成コードを自社リポジトリに取り込む場合、AutoBE 本体の更新に追随するコストを誰が負うかを先に決めておきたい。

編集部の結論

AutoBE が向くのは、NestJS と Prisma を前提にした新規バックエンドのたたき台を短時間で得たいチームと、生成された仕様書やテストを読んで学びたい開発者である。逆に、既存の大規模サービスに段階的に機能を足したい場合や、AGPL-3.0 のソース開示条件を自社プロダクトに持ち込めない場合は採用すべきではない。導入前に確認すべきは、playground が動く環境で pnpm run playground を実行し、生成物が prisma/schema と src/controllers、test/features/api のどこに出力されるかを自分の目で追うこと、そして生成コードをどのライセンスで配布するかを決めることだ。autobe-examples の ERP サンプルのように、生成された ERD と E2E テストがそのまま仕様として読めるかどうかが、採用判断の分かれ目になる。

公式情報源

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. wrtnlabs/autobe on GitHub