Brandnew Systems BRANDNEWSYSTEMS
← 実績・事例一覧へ

Case Study — Self-Initiated SaaS

契約一元管理SaaS「PropBoard」
一人AI駆動開発に、チーム開発の規律を。

契約書のPDF/画像を Claude(Vision)で自動構造化する、不動産向けの自社開発SaaSです。開発は一人+AI。ただしプロセスは、Issue 起票 → Pull Request → CI → AIレビュー+人の最終判断 → リリースタグという、チーム開発の標準フローをそのまま採用しています。ここでは、その進め方と設計判断を公開します。

2.7万行

TypeScript 中心のコードベース

617件

自動テスト(vitest)+E2E

4ジョブ

全PRで必須のCIチェック

0回

main への直接push(保護ブランチ)

※ 数値は 2026年7月時点

Product

何を作っているか

契約書の管理が「ファイルサーバーとExcelと担当者の記憶」に散らばっている——不動産の現場によくある状態を、アップロードするだけで台帳になるSaaSで解決します。

01 — AI-OCR

契約書を自動で構造化

PDF/画像の契約書を Claude(Vision)で解析し、契約期間・金額など15項目以上を自動抽出。手入力の転記作業をなくします。

02 — ALERT

期限・更新の見える化

抽出した契約期限からアラートを自動生成。「更新月に気づかなかった」を、人の注意力ではなく仕組みで防ぎます。

03 — ROLE

本社/支店の権限分離

拠点をまたぐ契約を一元管理しつつ、権限は拠点単位で分離。見えてはいけないものは一覧にも出さない設計です。

SCREENSHOT — COMING SOON

アプリ画面(ダミーデータ)を掲載予定

Process

一人でも、チーム開発の規律で作る

AI駆動開発は速い。ただし、AIがコードを書く速度は、人間がそれを理解する速度を簡単に追い越します。PropBoard では「速く作ること」と同じ重みで「作った本人が中身を説明できること」を置き、一人開発ながら GitHub のチーム開発フローを全面採用しています。

SOLO DEV — TEAM DISCIPLINE ✓ branch protected

01 ISSUE

やることを1件ずつ Issue に起票。1 Issue = 1 つの目的

02 BRANCH

main から作業ブランチを切る。main への直接 push は branch protection で禁止

03 PULL REQUEST

変更は必ず PR 経由。説明文には設計意図と「採用しなかった案とその理由」まで書く

04 CI

lint・型チェック・ユニット/DB・E2E 系の 4 ジョブが全 PR で必須チェック

05 REVIEW

Codex(AI)が差分を網羅的にレビューし、そのうえで人が設計意図を質問して最終判断。納得するまでマージしない

06 MERGE & TAG

Approve 後にマージし、1機能ごとにバージョンタグを打つ(v1.3.x 系)

CI は導入初日から仕事をした

CI 導入初日に、環境差異による不具合を3件検出。人が読むべきは設計の意図、機械が見られるものは機械に任せる分担です。

レビューは形式ではなく設計の対話

コードはまず Codex(AI)が網羅的にレビュー——見落としの少なさで、人はAIにかないません。そのうえで人が差分を読み、「なぜこうなっているのか」を質問して言語化させ、マージの最終判断をする。理解がコードに追い越されないための関所です。

差分は小さく保つ

1 PR = 1 目的。読み切れる粒度に区切るのは丁寧さではなく、レビューが機能するための前提条件です。

REVIEW LOG — 実際のやりとり(要旨)

Q. 権限がないのにその操作ができてしまうということ? それとも URL を直接叩いた場合の防御?

A. 後者です。認可は二層で守っています——一覧には出さない(見せない)+ ID を直接指定されても弾く(触らせない)。この質疑を経てからマージしています。

Issue 駆動・PR レビュー・CI 必須・保護ブランチ——チーム開発の標準フローを日常的に回しているので、
受託でもチーム参画でも、この作法のまま合流できます。

SCREENSHOT — COMING SOON

PR レビューのやりとり・CI(GitHub Actions)の実行結果を掲載予定

Engineering

設計判断ハイライト

「動けばいい」で積まない。制約と理由から決めた設計をいくつか紹介します。

01 — MEMORY

メモリ1GBのサーバーで AI-OCR を成立させる

契約書1件の解析は base64 変換で数十MB級のメモリピークが発生し、同時アップロードで即メモリ不足になります。解析を同時実行1の直列キューにし(待機中は最小限のバッファのみ保持)、ファイル配信はストリーミング化して全量をメモリに載せない構成に。小さなサーバーでも設計で成立させる、が方針です。

02 — AUTHZ

認可は「1関数・1クエリ」に集約

契約データへのアクセス判定を1つの認可関数に一元化し、ルートごとに散在していた判定(最大8クエリ)を1クエリに。存在しないIDには404、権限外のアクセスには403を一貫して返す様式に統一し、リソースの存在秘匿まで設計に含めています。

03 — BOUNDARY

環境で差し替わるものは境界を切る

ファイル保存はアダプタとして抽象化し、ローカル / S3 を同一インターフェースで差し替え可能に。契約テストで両実装の挙動一致を担保しているので、開発環境と本番環境の差がバグにならない構造です。

Stack

技術構成

アプリケーション

Next.js(TypeScript)/ PostgreSQL(マイグレーション管理)/ Tailwind CSS + shadcn/ui(デザインシステム)

AI

Claude API(Vision)による契約書の解析・構造化抽出

インフラ

本番:VPS(Node.js)+ AWS S3 / デモ環境:AWS(ECS on Fargate + ALB + RDS for PostgreSQL + S3)を AWS CDK でコード化して構築・HTTPS 公開中

品質・自動化

GitHub Actions(CI 4ジョブ / CD 2系統:main マージで本番へ自動デプロイ + OIDC 経由で ECR push → ECS デプロイ)/ vitest(ユニット・コンポーネント・DB統合)/ React Testing Library / Playwright(E2E)

Next.js TypeScript PostgreSQL AWS(ECS / RDS / S3) AWS CDK GitHub Actions shadcn/ui vitest Playwright Claude API(Vision)

Status

現在地

開発継続中のプロダクトです(2026年7月時点)。CI と PR レビューの運用は日常稼働しており、1機能ごとに v1.3.x 系のリリースタグを重ねています。CD も稼働中で、main へのマージは本番へ自動デプロイされ、デプロイ後の稼働確認まで毎回実測しています。直近では shadcn/ui ベースのデザインシステムへの刷新と、既存コードへのテスト拡充(認可境界・入力境界を先に固定する方式)を実施。機能拡張と同じ PR の中でテストと設計ドキュメントも一緒に育てる運用を続けています。

Contact

この進め方で、あなたの開発も。

古いシステムの刷新でも新規開発でも、同じ規律(Issue・PR・CI・レビュー)で進めます。
まずは無料でご相談ください。

メールで無料相談する 実績一覧へ戻る