Genzai — プロジェクト技術評価レポート

1 総合評価

4.5 / 5

総合スコア

要件定義から設計・実装・インフラ構築・デプロイまでの全工程を1名で48.4人日で遂行しており、各工程の判断が一貫している点を高く評価した。クリーンアーキテクチャやレイヤード設計の適用範囲が広く、 56テーブル・290エンドポイント・637コンポーネントの規模においても設計方針のブレが少ない。技術選定も2026年時点の業界標準に沿っており、特にHono採用によるAPIサーバー分離は、Next.jsへの依存を制御する合理的な判断と認められる。

プロジェクト概要: Genzaiは、製造業の現場向け資材管理アプリケーション。工具・消耗品の数量管理、入出庫管理、備品台帳管理を統合し、現場ごとの資材持ち出し・返却をリアルタイムで追跡する。iPad対応のタッチ操作、ダッシュボード統計、通知機能を備えた業務SaaS。

387h

総開発時間

270,940

コード行数

290

APIエンドポイント

637

コンポーネント

56 / 25

テーブル / Enum定義

294

ビジネスロジック

36

ページ

70+

設計文書

2 評価一覧

開発スコープ（1人での全工程実施） ★★★★★ 5.0

使用技術（業界標準との整合性、技術選定の妥当性） ★★★★★ 5.0

設計品質（クリーンアーキテクチャ・レイヤード設計・統一性） ★★★★☆ 4.5

実装機能（充実度・ドメイン知識の反映・UX） ★★★★☆ 4.5

デザイン（デジタル庁準拠・デザインシステムの統一性） ★★★★☆ 4.5

セキュリティ（6ロールRBAC・IAP・Cloud Armor・多層防御） ★★★★☆ 4.5

CI/CD・クラウド構成（自動化・運用設計） ★★★★☆ 4.5

データベース設計（56テーブル・正規化・インデックス） ★★★★☆ 4.5

テスト（Vitest / Playwright / Husky / Storybook） ★★★★☆ 4.0

ドキュメント品質（70+文書の体系的整備） ★★★★★ 5.0

3 開発スコープ ★★★★★5.0

評価: ヒアリングからデプロイまでの全工程を1名で遂行している。各工程に対する時間配分（FE 32%、BE 20%、設計 13%）は、この規模のプロジェクトとして妥当であり、特定工程への偏りが少ない。仕様検討・資料作成に全体の14%を充てている点は、設計品質とドキュメント品質の高さに直結していると判断できる。

開発時間内訳

フロントエンド開発

125h

32.3%

バックエンド開発

75.5h

19.5%

設計（FE/BE/App）

55.5h

14.3%

技術・仕様検討

32.5h

8.4%

開発資料作成

27.5h

7.1%

環境構築

25.5h

6.6%

ミーティング

16h

4.1%

DB開発

16h

4.1%

要件分析

13.5h

3.5%

4 使用技術 ★★★★★5.0

評価: 各レイヤーで2026年時点の業界標準ライブラリを採用しており、特殊な技術は含まれていない。これは保守性・採用面で有利に働く。 HonoによるAPIサーバー分離は、Next.js Route Handler / Server Actionsに寄せる選択肢もある中で、FE/BE独立デプロイを可能にする合理的な判断。 Go microserviceの併用はヘルスチェック等の軽量処理に限定されており、ポリグロットの複雑性を最小限に抑えている。

フロントエンド

Next.js 15 (App Router, Turbopack)
React 19, TypeScript 5
Tailwind CSS v4
shadcn/ui + Radix UI (106コンポーネント)
デジタル庁デザインシステム (DADS)
TanStack Query / Table / Virtual
Zustand, React Hook Form + Zod, nuqs
Motion, Recharts, @nivo/treemap
Swiper, @hello-pangea/dnd, dnd-kit
Serwist (PWA), Storybook 10

バックエンド / BaaS

Hono (TypeScript API)
Go 1.23 (Microservice)
Supabase (認証・DB・Storage)
Prisma ORM v7, PostgreSQL
Resend + React Email
Sharp (画像処理)
Cheerio (OGPスクレイピング)
YouTube Data API v3
tus-js-client (大容量Upload)
Kintone REST API, Google Chat Webhooks

インフラ / DevOps

Google Cloud Platform
Cloud Run (4サービス)
Cloud Tasks, Cloud Scheduler
Cloud Load Balancing
Identity-Aware Proxy (IAP)
Cloud Armor (WAF)
Cloud DNS / Cloud Domains
Artifact Registry, Docker (4イメージ)
GitHub Actions (CI/CD)
Turborepo + pnpm, Husky

5 設計品質 ★★★★☆4.5

評価: FEのbulletproof-react準拠とBEのクリーンアーキテクチャが、@repo/sharedを介して型レベルで接続されている設計は、 FE/BEの独立変更を可能にしつつ型の不整合を防ぐ構成として合理的。 290エンドポイントの背後にある169のビジネスロジック(UseCase)がそれぞれ単一責務を持ち、16のGatewayがDB操作を抽象化している点は、テスタビリティとリファクタリング容易性の確保に寄与している。

アーキテクチャ構成

クライアントフェッチ (参照系)

Page / Component

Container (hooks)

TanStack Query

features/*/api/

Hono API (apps/api)

PostgreSQL

サーバサイドフェッチ (RSC)

Page (Server Component)

features/*/api/

Hono API (apps/api)

PostgreSQL

バックエンド: クリーンアーキテクチャ

Presentation (Router)

Application (UseCase)

Domain (Repository IF)

Infrastructure (Gateway)

PostgreSQL / External

設計のポイント

12のエンティティ + ページ機能モジュールに分離
Container/Presentational パターンの適用
@repo/shared でドメインモデル・スキーマ一元管理
UseCase 169件 / Gateway 16件の責務分離
DomainError による統一エラーハンドリング
依存性逆転の原則 (Infrastructure -> Domain)

モノレポ構成

apps/web — Next.js 15 (36 pages)
apps/api — Hono API (20 routers)
apps/go-services — Go 1.23
apps/jobs/ — Cloud Tasks Worker
packages/database — Prisma + Supabase
packages/shared — Entities / Schemas / Types
packages/eslint-config — ESLint共通
packages/typescript-config — TSConfig共通

6 実装機能 ★★★★☆4.5

品目管理

品目カテゴリのツリー管理、品目マスタのCRUD、検索・フィルタ、Swiper画像表示、添付資料管理、複写機能、OGPスクレイピング。47コンポーネント。

備品管理

備品台帳CRUD、購入先・メーカー・型番管理、4種類の履歴管理（現場使用・移管・メンテナンス・貸出）、保管場所管理、画像・添付資料管理、企業マスタ管理。

現場資材管理シート

現場ごとの資材持ち出し・返却管理。マスタからのシート生成、品目別数量入力、ステータス管理（下書き/申請中/出庫/入庫）、履歴追跡。165ファイル。

シートマスタ

資材管理シートのひな型管理。品目のグルーピング、D&D並び替え、マスタからシートへの展開。工場・現場ごとのマスタ管理。

ダッシュボード

全工場KPIサマリー、アラートパネル、工場タブ切替、積上棒グラフ/ドーナツ/ツリーマップの5種チャート、工場別詳細ドリルダウン。

認証・認可

Supabase Auth (Google OAuth)、6ロールRBAC、Next.js + Hono二重Middleware認証ガード、IAP社内限定。Kintone従業員マスタ連携による初回ログイン自動プロフィール生成。

通知・メール

ウェルカム通知、シート申請通知、Google Chat Webhook連携。Resend + React EmailでHTMLメール。Cloud Tasks経由の非同期配信。

管理工場・組織

管理工場・管理部署・保管場所のツリー構造管理。React Flowベースのツリー可視化。組織横断の権限制御。

共通機能

CSV出力、検索パラメータ保存(JSONB永続化)、プロフィール編集、チャットスペース管理、ユーザー管理・一覧、ランディングページ。

7 API設計 / データベース設計 ★★★★☆4.5

Hono API (290エンドポイント / 20ルーター)

ルーター	EP数	主な操作
sheet	51	CRUD, status, history, copy, notification
equipment	47	CRUD, 4種履歴, 状態管理, search
item	25	CRUD, search, filter, copy, image
user	20	CRUD, search-params, settings
organization	19	CRUD, tree, departments, storage
profile	18	get, update, avatar, notification
sheet-master	18	CRUD, items, copy, factory
equipment-attachment	17	upload, download, thumbnail, TUS
item-attachment	16	upload, download, OGP, YouTube
chat-space	15	CRUD, webhook, stats
company	14	CRUD, type-filter, dependencies
dashboard	10	KPI, alerts, charts, factory
その他 8ルーター	20	auth, health, ogp, youtube...
合計	290

データベース設計 (56テーブル / 25 Enum定義)

56テーブル + 25 Enumの大規模スキーマ
Prisma v7による型安全なマイグレーション管理
4種類の履歴テーブルによる変更追跡
JSONB活用（検索パラメータ永続化等）
複合インデックスによるクエリ最適化
論理削除 (deletedAt) + 監査カラム (createdBy/updatedBy)
組織階層 (Factory > Department > StorageLocation)
RFID将来拡張を見据えた設計

API設計の特徴

クリーンアーキテクチャ 4層の責務分離
Zodによるリクエスト/レスポンスバリデーション
DomainError -> HTTPレスポンス変換の一元化
Gateway パターンによるDB操作の抽象化 (16 Gateways)
Middleware: 認証ガード, エラーハンドリング, ロガー

8 デザイン ★★★★☆4.5

評価: デジタル庁デザインシステム(DADS)をshadcn/uiにカスタム統合する判断は、アクセシビリティ基準の達成と開発速度の両立を実現している。 106のUIコンポーネント + 48の共有コンポーネントという規模は、画面ごとの個別実装を避け、UIの一貫性を保つのに十分な粒度。コンパクトモードの用意は、備品台帳やシート入力といったデータ密度の高い画面での実用性を意識した判断と認められる。

UIコンポーネント構成

カテゴリ	数	内容
UIベース (shadcn/ui)	106	Button, Dialog, Table, Form...
共有コンポーネント	48	PageHeading, EmptyState, Spinner...
レイアウト	—	Sidebar, Header, NotificationBell
機能コンポーネント	847+	features/ 配下の専用コンポーネント

デザインシステムの特徴

DADSカラーパレット (12色 x 12段階)
セマンティックカラー (Success, Error, Warning, Focus)
カスタムスクロールバー (Chrome/Safari/Firefox)
prefers-reduced-motion対応
コンパクトモード (データ密度の高い画面用)
Swiper統合スタイル
レスポンシブ: PC/タブレット/iPad/モバイル

9 セキュリティ / CI/CD / クラウド構成 ★★★★☆4.5

セキュリティ

認証・認可

Supabase Auth (Google OAuth)
RBAC 6ロール (SYSTEM_ADMIN / PRODUCTION_MANAGER / FACTORY_CHIEF / DEPUTY / MATERIAL_PREPARER / SITE_SUPERVISOR)
Next.js + Hono 二重Middleware認証ガード
Kintone従業員マスタ連携

ネットワーク保護

Identity-Aware Proxy（特定ドメイン限定）
Cloud Armor (WAF)
Cloud Load Balancing
SSRF対策 (OGP取得時のプライベートIPブロック)
DOMPurify によるXSS防止

CI/CD

CI パイプライン

PR時: Lint -> Unit Test -> Build
Husky pre-push: テスト自動実行
Concurrency制御 (重複ビルド防止)

CD パイプライン

変更検知 -> 変更サービスのみデプロイ
Workload Identity Federation (キーレス認証)
Docker -> Artifact Registry -> Cloud Run
4サービス独立デプロイ (Web, API, Go, Worker)

バックアップ

毎日 0:10 JST 自動DBバックアップ
Cloud Storage 30日保存 + 自動削除

10 ドキュメント品質 ★★★★★5.0

評価: 各機能に対して「要件定義 -> 仕様書 -> UI設計 -> FE/BE設計 -> タスク計画」の一貫したワークフローで文書化されている点は、開発者の入れ替わりや長期保守を想定した設計判断として適切。 CLAUDE.mdを中心としたAI協働開発基盤は、スキル定義・ツール使用方針・コンテキスト管理まで体系化されており、 1人開発の生産性を高める仕組みとして機能している。

基盤ドキュメント

カテゴリ	文書数	対象
プロジェクト・ドメイン	3	概要, 製造業ドメイン, 現場ドメイン
機能概要	11	機能一覧 + 各機能仕様
基本設計	7	FE/BE/DB/CSS/通知...
技術スタック	3	FE/BE/インフラ推奨

機能別設計文書 (抜粋)

機能	文書群
品目管理	要件, 仕様, UI設計(6), FE設計(6), BE設計(3)
備品管理	要件, 仕様, UI(4), FE(2), BE(2), タスク(10)
シート	仕様(14), UI/UX, FE設計(12), BE設計(8)
ダッシュボード	要件(8), FE設計(6), BE設計(2)

11 まとめ

総括

48.4人日という限られた工数の中で、設計方針に一貫性を保ちながら56テーブル・290エンドポイント・637コンポーネント・36ページの規模を構築した点は、工数配分と優先順位判断の的確さを示している。 FE/BE両方でアーキテクチャパターンを徹底し、@repo/shared による型共有で整合性を維持した設計は、チーム開発へのスケールを前提とした判断として評価できる。 GCPのIAP・Cloud Armor・Workload Identity Federationによる多層防御と、変更検知による選択的デプロイは、運用コストを意識した実用的な構成である。 70以上の設計文書による開発基盤の体系化は、属人性の排除とナレッジの再利用性を高めている。

技術

フルスタック実装
ポリグロット構成
最新技術の実践

設計

クリーンアーキテクチャ
レイヤード設計
56テーブルDB設計

実績

48.4人日で完遂
270,940行のコード
4サービスの運用基盤

ドメイン

業務知識の反映
体系的ドキュメント
AI協働開発基盤

+ 付録: プロジェクト基本情報

基本情報
プロジェクト名	Genzai（現在 — 現場資材）
種別	現場資材管理システム
開発体制	1名（フルスタック）
開発者	shota_h / 林翔太
総開発時間	387h (48.4人日)
コード行数	270,940行
ファイル数	2,032
テーブル / Enum定義	56 / 25
APIエンドポイント	290 (20ルーター)
コンポーネント	637
ビジネスロジック	294 (UseCase 169 + Hook 116 + Module 9)
ページ数	36

技術スタック
フレームワーク	Next.js 15, React 19, TypeScript 5
API	Hono (TS) + Go 1.23
スタイリング	Tailwind CSS v4, shadcn/ui, DADS
状態管理	Zustand, TanStack Query
BaaS	Supabase (認証, DB, Storage)
ORM	Prisma v7
クラウド	Google Cloud Platform
CI/CD	GitHub Actions
デプロイ	Cloud Run (4サービス)
セキュリティ	IAP + Cloud Armor + LB
テスト	Vitest, Playwright, Storybook
モノレポ	Turborepo + pnpm