Why Guren

Guren の立ち位置を正直に整理します — Hono・Next.js・AdonisJS・Laravel との比較と、Guren がこの設計になっている理由です。

要約

• Guren を選ぶべきとき — 認証、データベース、フォーム、バックグラウンドジョブ、メールを備えたフルスタックアプリを、1 つの TypeScript コードベースで、エンドツーエンドに型付けされた状態で組み立てたいとき。
• 素の Hono を選ぶべきとき — 小さくステートレスな API サービスを作りたくて、それ以外は何も要らないとき。
• Next.js を選ぶべきとき — コンテンツ中心で React レンダリングが主役のプロダクトのとき。マーケティングサイト、EC ストアフロント、React Server Components を軸に据えたアプリなど。

さらに Guren は、多くのフレームワークが投資してこなかった領域に力を入れています。AI コーディングエージェントがあなたのプロジェクトを理解し、拡張し、検証しやすくすることです。詳細は後述します。

Hono との比較

Guren の HTTP レイヤーは Hono そのものです。すべてのリクエストが Hono のルーターを通るため、パフォーマンスクラスは Hono と同じ — Guren が足すのは薄い MVC レイヤーであって、新しいサーバーではありません。

Hono が意図的に持たないものを、Guren は同梱しています。

必要なもの	素の Hono	Guren
データベースアクセス	ORM を選んで自分で配線	Drizzle ベースの Model.where().orderBy().get() が最初から使える
バリデーション	ハンドラーごとにスキーマライブラリを呼ぶ	this.validateBody(schema) — 422 レスポンスまで面倒を見る
認証	セッション・ハッシュ・ミドルウェアを自作で組み立て	bunx guren add auth でフロー一式をスキャフォールド
フロントエンド	別建て SPA + 手書きの API レイヤー	Inertia 経由の React ページに型付き props
ジョブ・メール・イベント・キャッシュ	ライブラリを選定して統合	組み込みサブシステム(プロバイダーでオプトイン)
テスト	ハーネスを自作	fluent なアサーションを備えた TestApp

数個の JSON エンドポイントで済むサービスなら、素の Hono は優れた選択です。そして Guren の中身は Hono なので、片方からもう片方へ育てるのは書き直しではなく自然な成長になります。差が出るのはアプリが大きくなってから — 上の表の各行は、Guren がなければ自分で書き、テストし、保守し続けるグルーコードです。

Next.js との比較

Next.js と Guren は答えている問いが違います。Next.js は React ファースト — レンダリング戦略(RSC、ストリーミング、ISR)が中核の抽象で、バックエンドはフロントエンドから育っていきます。Guren はサーバーファースト — Laravel の系譜に連なる MVC アプリケーションで、React は Inertia を通じて届けられるビューレイヤーです。

この違いは、機能の作り方に現れます。

• メンタルモデルが 1 つ。 機能とは、ルート・コントローラー・モデル・ページのことです。クライアント/サーバーコンポーネントの境界を考える必要も、'use client' の判断も、データと React props の間に挟まる API ルート層もありません。
• 手書きのデータ配管が不要。 コントローラーが型付き props をそのままページコンポーネントへ渡します。データベースのカラム名を変更すれば、モデルから React ページまで TypeScript エラーが連鎖して教えてくれます。
• バックエンドが一級市民。 キュー、スケジュールジョブ、メール、ブロードキャスト、ポリシーはフレームワークのサブシステムです。レンダリングフレームワークの周りにサードパーティサービスを寄せ集めて作るものではありません。

サーバーレンダリングされた React そのものがプロダクトである場合 — ヘビーなコンテンツサイト、コンポーネント単位の細かなストリーミング、RSC エコシステムにコミットしたチーム — には、引き続き Next.js が適しています。

AdonisJS との比較

AdonisJS は TypeScript 世界のもう一つのバッテリー同梱 MVC フレームワークで、素晴らしい選択肢です — Laravel のアーキテクチャを Node.js で使いたいなら定番です。Guren は 2 つ、異なる賭けをしています:

• Node ではなく Bun。 同一仕様アプリ同士のベンチマーク（フレームワーク比較リポジトリの Inertia SSR 実装 2 つ）で、Guren は SSR ページで 2.3 倍、JSON 経路で 3.5 倍のスループット、コールドスタートは 1.8 倍高速という結果です — 手法とワンクリック追試はこちら。アプリのコードは同一なので、この差はランタイムの差です。それこそが要点で、アーキテクチャはそのまま、エンジンだけ替わります。
• 独自実装ではなく TypeScript エコシステムの定番を採用。 AdonisJS は独自の ORM（Lucid）やバリデータ（VineJS）を持ちます。Guren はエコシステムで既に標準となった部品 — Drizzle、Zod、Vite、Inertia — を組み立て、そこに規約を載せます。同一仕様アプリの実装で、保守対象のコードは Guren 991 行 / 38 ファイルに対して AdonisJS 2,438 行 / 68 ファイル、直接依存は 17 対 43 でした。

タイプ量はほぼ互角です（どちらもスキャフォールドが優秀で、手書きは約 570 行対 600 行）。選択はランタイムと、どのデータ層と付き合いたいかで決まります。

Laravel・Rails との比較

Laravel や Rails の経験者なら、Guren はすぐに馴染みます。コントローラー、モデル、ミドルウェア、ポリシー、リソース、ジョブ、make:* ジェネレーター — すべて期待どおりに振る舞います。変わるのは言語の境界です。というより、境界がなくなります。

• エンドツーエンドで 1 言語。 バックエンドとフロントエンドの間に PHP と JavaScript の切り替えがありません。バリデーションスキーマも、モデルも、ページ props も、すべて TypeScript です。
• 型がワイヤーを越える。 Laravel の開発体験に静的保証が付きます。コントローラーが送る props と React ページが宣言する props の一致を、コンパイラが検査します。
• モダンなランタイム。 Bun は TypeScript をネイティブ実行します。開発時のトランスパイル不要、高速な起動、組み込みテストランナー。

AI コーディングエージェントのために

多くのフレームワークは「ドキュメントを読む人間」に向けて設計されてきました。Guren はそれに加えて、「リポジトリの中で作業するエージェント」に向けて設計されています。違いを生むのは次の 3 つの性質です。

プロジェクトの把握が安上がり。 bunx guren context は、ルート・モデル・コントローラー・ページのコンパクトな地図を出力します(--json で機械可読)。エージェントはディレクトリツリーを這い回る代わりに、コマンド 1 つで正確なプロジェクト理解を得られます。コンテキストウィンドウは小さいまま、前提は正確なままです。データモデルについては bunx guren model:list が同じ役割を果たします。

規約が決定空間を縮める。 コントローラーは app/Http/Controllers、モデルは app/Models、ページは resources/js/pages — そして bunx guren make:feature Post --fields "title:string,body:text" は一貫した CRUD 一式をスキャフォールドします。すべてに「明らかな置き場所」と「明らかな形」が 1 つずつあるとき、生成コードが最初から正しい場所に収まる頻度は大きく上がります。

間違いはレビューではなく機械が捕まえる。 エージェントが書いたコードを、独立した 3 つのゲートが検証します。

bunx guren check    # ルート ↔ コントローラー ↔ ページの整合性
bunx guren audit    # 変更系ルートのバリデーション/認証漏れ、生SQL、シークレット
bun run typecheck   # 型付き page props とルート契約のズレはビルドが落ちる

ページ props、ルートパラメータ、リクエストボディはすべて型付きの契約なので、エージェントが props 名をハルシネーションしたり、バリデーションスキーマを忘れたりすれば、あなたが diff を 1 行読むより前に、コンパイルエラーか check の失敗として現れます。

結果として得られるのは、読み込むコンテキストが少なく、間違えられる自由度が小さく、成果物が機械的に検証される、という状態です。この「把握 → 生成 → 検証」のループこそが、Guren でのエージェント駆動開発を「祈り」ではなく「当てにできるもの」にします。

これは願望ではなく、計測済みの事実です。 同一の機能追加タスクを 6 つのフレームワークで実行し、typecheck・テスト・エージェントには見えない HTTP スモークで盲検採点する再現可能なエージェント評価で、エージェントは全トライアルで Guren 上に動く機能を出荷しました。同じ調査で、新規 Guren プロジェクトに同梱されるエージェントガイダンス(自動ロードされる CLAUDE.md と、ソース照合済みの正確な API シグネチャを載せたパススコープのルール群)が、ドキュメントなしの状態と比べてエージェントのコストを 40% 削減することも確認しています。ハーネス・生データ・制約事項はすべて公開されています。

Guren を選ぶべきでないとき

どこでも正解のフレームワークは存在しません。次の場合は別の選択肢を検討してください。

• プロダクトがレンダリング中心。 コンポーネント単位のストリーミング SSR、細粒度のキャッシュ、RSC エコシステムは Next.js のホームグラウンドです。
• 極小フットプリントのサービスが欲しい。 Webhook レシーバーやエッジファンクションに MVC は不要です — 素の Hono の方が軽量です。
• チームが別のランタイムにコミットしている。 Guren は設計上 Bun ネイティブです。Node.js ランタイムでのサーバーレスデプロイはサポートしていますが、主たる開発体験は Bun を前提としています。

次のステップ

• クイックスタート — 約 5 分でプロジェクトを作成して起動します。
• First Steps — 1 つのリクエストが全レイヤーを通過する様子を 10 分で追います。
• アーキテクチャ — ルーティング、コントローラー、モデル、Inertia の噛み合い方。
• CLI リファレンス — エージェントが頼る検査コマンドを含む、全コマンドの一覧。