最終更新 2026.06.22 共通前提

Craft ERP Overview

RESEARCH(技術調査・比較・評価)記事の共通前提ページです。各記事はこのページを背景として参照します。

Craft ERP が何で、なぜ開発しているのか、どのような思想・方針で技術選定しているのか——をまとめています。方針の変化に合わせて継続的に更新する「生きたドキュメント」として扱います。

1. Craft ERP とは

Craft ERP は、一人のエンジニアが、生成AI × 仕様駆動開発を用いて、小売業向けの基幹業務システムの開発に挑戦するプロジェクトです。

業務システムを作ること自体が最終目的ではありません。実運用に耐える業務システムを実際に作るという具体的な題材を通じて、人間とAIが協調する開発手法そのものを検証することに主眼があります。

  • 開発主体: 一人のエンジニア
  • 題材: 小売業向け基幹業務システム(まずは1店舗での利用から始め、将来的に複数顧客・多店舗展開も視野)
  • 本質: 生成AI × 仕様駆動開発という開発プロセスの実践と検証

2. なぜ作るのか(開発目的)

  • 実運用に耐える業務システムを、実際に作りきる
  • 生成AI × 仕様駆動開発を、机上ではなく実プロジェクトで実践する
  • 人間とAIが協調する開発プロセスを確立し、その有効性を検証する
  • 技術選定・設計・実装の判断過程を公開し、再現・再評価できる形で残す

技術的な目新しさそのものではなく、「実運用に耐える業務システムを、生成AIを活用してどう作り続けるか」という開発手法の確立を目的に置きます。

3. 重視すること

  • 人間とAIが協調する開発プロセス
  • 仕様を中心とした開発手法(仕様を唯一の信頼できる情報源とする)
  • 実運用に耐える業務システム
  • 継続的な改善が可能な構造

4. システム対象領域

題材となる小売業向け基幹業務システムが扱う領域(想定)。

  • 商品管理
  • 売上管理
  • 在庫管理
  • 発注管理
  • 仕入管理
  • マスタ管理
  • CSV / TSV 連携(取込・出力)
  • 分析・集計機能

いずれも PostgreSQL を中核に据えた、データ整合性を重視する一般的な業務システム構成です。

5. 設計方針

  • シンプルな構造を維持する
  • 過度な抽象化を避ける
  • 不必要な分散設計を行わない
  • 将来の変更や運用に柔軟に対応できる構成を目指す
  • 人間とAIの双方が理解しやすい構成を目指す

その上で、定義・ルール決め・基本設計は人間が行い、詳細設計・実装・テストには生成AIを活用する(人が設計し、AIとつくる)。

6. 技術スタック

現時点の方針。

Flutter Web
FastAPI
PostgreSQL
Docker
Cloudflare(CDN / WAF 候補)
GitHub
生成AI

この構成は確定ではなく、調査・検証の結果によって見直します。見直しの記録が RESEARCH 記事になります。

7. 技術選定方針

  • 流行だけで判断しない
  • 実際に調査・比較・検証する
  • RESEARCH に判断過程を記録する
  • 将来の見直しができる形で残す

判断基準は「技術的に魅力的か」ではなく 「今のプロジェクトの成功確率を高めるか」 に置きます。

8. RESEARCH との関係

Craft ERP では、技術選定やアーキテクチャ評価を「流行」や「直感」で決めず、実際に調査・比較・検証し、その判断過程を RESEARCH として公開しています。これは仕様駆動開発の「判断を記録し、後から再評価できるようにする」という姿勢の延長です。

たとえば「Cloudflare をどう使うか」「PostgreSQL サービスに何を選ぶか」といった比較記事は、この Craft ERP プロジェクトの技術選定の一部であり、本ページがその共通前提になります。

本ページは、以下のような技術調査・比較・評価記事の共通前提とします。各記事の「Craft ERP の前提」はここを参照することで、記事ごとの重複説明を減らします。

  • Cloudflare Workers vs Container
  • Cloudflare Containers
  • Neon vs Supabase
  • PostgreSQL Strategy
  • AI Development Workflow
  • GitHub Spec Kit Evaluation

Related

技術選定の具体的な調査・比較・評価は、RESEARCH の各記事で公開しています。