フルスタック · 不動産テック2026年 · 進行中

Homie Platform

物件、入居者、賃貸借契約、請求書、そしてその間のあらゆる業務を扱う、統合型の不動産管理システムです。

HOMIE

Property Management Platform

設計済みモジュール: 12
認証フロー: 稼働中
稼働中のDBテーブル: 4

クライアント: Homie
業種: 不動産管理
依頼内容: フルスタックのプロダクト開発
ステータス: 進行中
期間: 2026年 · 開発中
対応範囲: ウェブアプリケーション、REST API、データベース

01 概要

クライアントは誰か

Homie Platformは、フルスタックのモノレポとして構成された不動産管理システムです。対象は12の運用領域で、入居申込、物件、入居者、オーナー、契約、請求書、入金、内見、社内メッセージ、管理機能です。

02 課題

どんな課題を抱えていたか

クライアントには、物件運用の全体を管理できる、単一の統合プラットフォームが必要でした。機能領域は12に分かれ、共有のデータ層も、統一されたインターフェースも、ロール間のアクセス制御もありませんでした。

分断された業務
12の運用領域（入居申込、物件、入居者、オーナー、契約、請求書、入金、内見、メッセージ、管理）が、それぞれ独立して動いており、それらをつなぐ共有のデータ層がありませんでした。
操作を追跡できる監査証跡がない
データの変更を記録する、信頼できる仕組みがありません。作成・更新・削除のすべてを操作者とタイムスタンプ付きで記録する、セキュリティ要件を満たした改ざんできない監査ログが必要だということは、初日から中核の要件として認識されていました。
アクセス制御がない
チームは、権限レベルの異なる複数のロールにまたがって運用しています。ロールベースのアクセス制御がなければ、どのスタッフもシステム全体に制限なくアクセスできてしまいます。
入居申込を扱う専用の仕組みがない
入居申込の管理には、専用のシステムがありませんでした。プラットフォームの中核となる運用領域として認識されており、独自のモジュールが必要です。
リレーショナルなデータ基盤がない
物件、入居者、オーナー、請求書、契約は相互に依存するエンティティですが、共有のデータベーススキーマがありません。対応するテーブルはPostgreSQLにまだ存在せず、Goの構造体も生成されていません。

03 解決策

どう解決したか

フルスタックの不動産管理システムを、モノレポ構成で設計・構築しました。アーキテクチャは、Go製のREST APIバックエンドとNext.js 16のフロントエンドに分かれ、sqlcによってコンパイル時に型安全なSQLを生成しながら、PostgreSQLデータベースを共有します。

フロントエンドは12の運用モジュールをカバーし、すべてApp Routerの構造のもとで、設計と骨組みの作成が完了しています。認証はエンドツーエンドで稼働しています。運用データベースのスキーマとAPIハンドラーは、現在開発中です。

FE Next.js 16 Reactフロントエンド React 19TypeScriptTailwind v4
API Go REST API バックエンド sqlcCookie認証
DB PostgreSQL データベースマイグレーションsqlcの型

モノレポは1つ · デプロイは1つ · PostgreSQLインスタンスは共有

Next.js 16
React 19
TypeScript
Go (Golang)
PostgreSQL
sqlc
Tailwind CSS v4
Radix UI
TanStack Query v5
FullCalendar
Tiptap
dnd-kit

設計済みの画面 — 骨組みの作成は完了、データ層は進行中

04 プロジェクトの流れ

主なマイルストーンと期間

フェーズ1 2025年Q4
ディスカバリーとアーキテクチャ
技術スタックを選定しました：Next.js 16、React 19、TypeScript、Go、PostgreSQL、sqlc。モノレポ構成を定義し、フロントエンドのサイトマップから12モジュールの範囲を確定しました。
フェーズ2 2025年Q4
フロントエンドの骨組みとデザインシステム
Next.js App Routerの構造一式を、src/appの下に骨組みとして作成しました。認証グループ、保護されたダッシュボードグループ、12モジュールすべてのルートセグメントです。すべてのビューコンポーネントの設計も完了しています。
フェーズ3 2026年Q1
認証システムとコアDBスキーマ
Go APIによるCookieベースのセッション管理（HttpOnly、SameSite=Lax）。3つのエンドポイント（POST /api/auth/login、POST /api/auth/logout、GET /api/auth/me）が稼働中です。最初のマイグレーションで、staff、audit_log、feed_items、settingsの4つのコアスキーマを導入しています。
フェーズ4 2026年Q2 — 進行中
運用DBスキーマ
物件、入居者、オーナー、請求書、契約のPostgreSQLスキーマを作成してマイグレーションします。sqlcでGoの構造体を生成します。
フェーズ5 2026年Q2〜Q3
APIのCRUDハンドラーとRBAC
すべての業務エンティティに対応するGoのルーターハンドラーを実装します。現在コメントアウトされているRequireRoleミドルウェアを有効化し、全ルートでロールベースのアクセス制御を適用します。
フェーズ6 2026年Q3
フロントエンドのデータ連携
12モジュールすべてのUIの静的なモックデータを、TanStack Queryを通じた実際のAPI呼び出しに置き換えます。

05 直面した壁と対処

どんな壁にぶつかり、どう乗り越えたか

複数のスコープにまたがる柔軟な設定
課題システムは、プラットフォーム全体の設定、物件ごとの上書き、入居者ごとの上書きという3つのレベルの設定を同時に扱える必要があります。しかも、スコープごとに別々のテーブルを用意せずに実現しなければなりません。
解決策settingsスキーマはJSONBを使った設計のため、1つのテーブルで全体・物件単位・入居者単位の設定を保存できます。新しい設定キーを追加しても、スキーマの変更は不要です。
React 19とTanStack Query v5の統合
課題フロントエンドはReact 19とTanStack Query v5で構築されています。どちらも本番運用に耐える依存パッケージで、サーバー状態のキャッシュと同期のために、Go APIとの統合を計画的に行う必要があります。
解決策TanStack Query v5が、Next.jsのフロントエンドとGo APIの間の非同期なサーバー状態の管理をすべて担い、キャッシュと同期はクエリ層で処理しています。
GoとNext.jsのセッション共有
課題Go製のバックエンドとNext.jsのフロントエンドにまたがってCookieベースのセッションを調整するには、両側で認証状態を一貫させるために、SameSiteとドメインの設定を慎重に行う必要があります。
解決策HttpOnly、SameSite=LaxのCookieは、Go APIが設定します。Next.jsアプリがトークンを直接扱うことはなく、認証状態はAPI呼び出しのたびに、GET /api/auth/meを通じてサーバー側で検証されます。
データ層より先に作られたフロントエンド
課題12モジュールすべてのUIは、設計と骨組みの作成が完了していますが、運用データベースのテーブルとAPIハンドラーはまだ存在しません。それでも、フロントエンドは実データがなくても動作し、確認できる状態を保つ必要があります。
解決策開発中、すべてのモジュール画面は静的なモックデータを使っています。データ取得レイヤーとしてTanStack Queryはすでに組み込み済みなので、フェーズ6でモックデータを実際のAPI呼び出しに置き換えても、UIの作り直しは不要です。

06 Before / After

プロジェクト前後の状況の比較

Before	After
認証システムがない：プラットフォームのどの部分にも、アクセスを制御する手段がない	エンドツーエンドの認証が稼働中：POST /api/auth/login、POST /api/auth/logout、GET /api/auth/me。Cookieベースのセッションを、Go APIとNext.jsで共有
監査証跡がない：誰が、いつ、何を変更したかの記録もない	改ざんできないaudit_logスキーマが稼働中：追記専用の台帳に、システムのあらゆる変更を操作者、タイムスタンプ、対象データとともに記録
運用エンティティのデータベーススキーマがない：物件、入居者、オーナー、請求書、契約のテーブルが存在しない	全エンティティのPostgreSQLスキーマを設計済み。staff、audit_log、feed_items、settingsはマイグレーション済み（フェーズ3完了）
ロールベースのアクセス制御がない：スタッフのロール間に権限の境界がない	RequireRoleミドルウェアをGoのルーターに組み込み済み：保護対象の全ルートで有効化を待っている状態
運用ワークフロー向けのフロントエンドがない	12モジュールすべてのUIの設計と骨組みの作成が完了：入居申込、物件、入居者、オーナー、契約、請求書、入金、内見、メッセージ、管理

契約モジュール。賃貸借契約書の作成と電子署名を担います。設計と骨組みの作成は完了しており、データ層はフェーズ4で加わります。

07 クライアントにもたらした成果

クライアントはどんな価値を得たか

設計済みモジュール: 12; 全12モジュール中、完了
認証フロー: 稼働中; Go ↔ Next.js
稼働中のDBテーブル: 4; staff · audit_log · feed_items · settings
稼働中のエンドポイント: 3; ログイン · ログアウト · プロフィール

初日からエンドツーエンドの認証を実装
認証フローの全体が稼働しています。ログイン、ログアウト、プロフィールの各エンドポイントが動いており、HttpOnlyのCookieセッションをGo APIとNext.jsのフロントエンドで共有しています。
セキュリティ要件を満たす監査証跡を最初から組み込み
audit_logスキーマは稼働中で、追記専用です。すべてのシステム変更が、操作者、タイムスタンプ、対象データとともに記録され、最初のマイグレーションからセキュリティコンプライアンス要件を満たしています。
システム全体に及ぶ柔軟な設定
JSONBを使ったsettingsテーブルは、全体・物件単位・入居者単位の設定を単一のスキーマで扱えます。設定要件が増えても、テーブルを追加する必要はありません。
フロントエンドは準備完了、データ層は進行中
12モジュールすべてのUIは、設計と骨組みの作成が完了しており、データ層となるTanStack Queryもすでに組み込み済みです。フェーズ6で実際のAPIデータに接続する際も、フロントエンドの作り直しは必要ありません。

請求書モジュール。請求と収支の概要を扱います。設計と骨組みの作成は完了しており、データ層はフェーズ4で加わります。

08 得られた学び

このプロジェクトから何を学んだか

sqlcはSQLから型安全なGoコードを生成する
sqlcは、SQLクエリからコンパイル時に型安全なGoの構造体とクエリ関数を生成します。スキーマの変更は、実行時の障害ではなくコンパイルエラーとして表に出ます。
モノレポなので、Go APIとNext.jsのフロントエンドを1つのリポジトリで管理できる
フルスタックのモノレポ構成のため、バックエンドとフロントエンドが、1つのコードベース、1つの開発環境、1つのデプロイパイプラインを共有します。
認証は、あらゆる運用機能よりも先に作り終えた
認証（ログイン、ログアウト、プロフィールの各エンドポイント）は、フェーズ3で完成しました。以降の開発はすべて、実際に動作するセッションモデルを前提に進めています。
12モジュールすべてのUIを、データベースより先に設計した
フロントエンドの全体は、運用データベースのスキーマができる前に、静的なモックデータで骨組みを作成しました。フェーズ6では、モックデータをTanStack Queryによる実際の呼び出しに置き換えます。UIの作り直しは不要です。
settingsテーブルのJSONBで、全体・物件単位・入居者単位の設定に対応
settingsスキーマはJSONBを使った設計で、1つのテーブルに3つのスコープの設定を保存します。プラットフォーム全体の設定、物件ごとの上書き、入居者ごとの上書きです。