生成AIによるアプリ作成手順～システム開発の手順は家を建てる工程と全く同じ～

2026年8月19日

ステップ（工程）	家づくりで例えると	作業内容（何をするか）	なぜこの順番か（理由）	作成する主なファイルと役割
ステップ1：プロジェクトの基本設定（環境構築）	地ならしと道具の手配	開発に必要な専用の道具箱（ライブラリ）と安全設定を揃える作業。	最初に開発環境を隔離して道具を揃えないと、プログラム同士が衝突して動かなくなる事故を防ぐため。	requirements.txt（必要な道具一覧） .env（秘密の安全設定） .gitignore（除外設定）
ステップ2：データベースの定義（データ構造）	建物の基礎（土台）作り	顧客・商品・受注などの情報を保存する保管棚の仕切りを決める作業。	「何をどう保存するか」を最初に決めないと、後からデータが紐付かないなどの致命的な手戻りが発生するため。	app/database.py（DB接続設定） app/models.py（顧客・商品・受注など8つのデータ構造定義）
ステップ3：ログイン機能とセキュリティ（認証・共通枠）	入口のドア・鍵の設置とデザイン枠	関係者以外を弾く入口の鍵と、全画面共通のメニュー枠を作る作業。	安全なアクセス制限とデザイン枠を先に用意することで、後から作る画面も自動的に安全かつ統一された見た目になるため。	app/security.py（暗号化） app/dependencies.py（閲覧権限チェック） app/templates/base.html（共通枠） app/routers/auth.py（ログイン画面）
ステップ4：基本データ管理（マスター画面）	基本台帳（名簿・カタログ）の準備	顧客名簿や商品カタログなど、業務の前提となる台帳データを登録・変更する画面作成。	業務システムは「台帳が先、取引は後」が鉄則。商品や顧客が未登録だと受注を記録できないため。	app/routers/ & templates/配下の各機能（顧客・商品・カテゴリ・仕入先・従業員の管理画面）
ステップ5：受注管理機能（複数商品同時入力）	メインとなる取引処理の部屋作り	「誰が・何を・何個買ったか」の伝票入力画面を作る（複数商品を一括追加可能）。	アプリの一番の価値（コア機能）を作成。1回の注文で複数商品を扱えるようにし、現場の入力ストレスを軽減するため。	app/routers/orders.py app/templates/orders/ （動的な複数明細入力画面）
ステップ6：入出庫・在庫管理機能	自動計算される在庫保管庫	商品の出入り履歴から現在の本当の在庫数を全自動計算する仕組み。	在庫数の手入力を防ぎ、モノの出入り履歴からの引き算で自動算出することで、データのズレを物理的に防ぐため。	app/stock_utils.py（在庫算出ロジック） app/routers/stock.py app/templates/stock/（在庫一覧・入出庫登録）
ステップ7：ダッシュボードと起動テスト	コックピット（管理画面）と最終点検	経営状況が一目でわかる集約画面を作り、全体の動作確認を行う最後の仕上げ。	部品が揃った段階で経営数値（売上・欠品リスク）を一画面に集約し、実業務で使える状態へ仕上げるため。	app/routers/dashboard.py app/templates/dashboard.html app/main.py（全機能の統合・起動）

システム開発の手順は家を建てる工程と全く同じです。「土台（データ）」から「骨組み（基本機能）」、そして「内装や設備（応用機能）」の順で作ることで、途中の崩壊や無駄なやり直しを防ぐ設計になっています。

各ステップの意味と理由

ステップ1：プロジェクトの基本設定（環境構築）

意味: 開発に必要な専用の道具箱（ライブラリ）と安全設定を揃える作業です。
理由: 家を建てる前の「地ならし」と「道具手配」にあたります。最初に開発環境を隔離して道具を揃えておかないと、途中でプログラム同士が衝突してシステムが動かなくなる事故が起きるためです。

ステップ2：データベースの定義（データ構造）

意味: 顧客・商品・受注などの情報を保存する「保管棚の仕切り」を決める作業です。
理由: 建物の「基礎（土台）」作りに相当します。「何をどう保存するか」のルールを最初に確定させないと、後から「注文データに商品を紐付けられない」といった致命的な手戻りが発生します。

ステップ3：ログイン機能とセキュリティ（認証・共通レイアウト）

意味: 関係者以外を弾く「入口の鍵」と、全画面共通の「メニュー枠」を作る作業です。
理由: 店舗にドアと鍵を最初に取り付ける段階です。安全なアクセス制限と共通のデザイン枠を先に用意することで、この後に作るどの画面も自動的に「安全かつ統一された見た目」になります。

ステップ4：基本データ（マスター）の管理画面

意味: 顧客名簿や商品カタログなど、業務の前提となる「台帳データ」を登録・変更する画面作りです。
理由: 業務システムでは「台帳が先、取引は後」が鉄則です。「商品」や「顧客」がシステム内に登録されていなければ、そもそも「受注を記録する」ことができないため、先にこの画面を作ります。

ステップ5：受注管理機能（複数商品の同時入力）

意味: 「誰が・何を・何個買ったか」という日々のメイン業務（伝票入力）を処理する画面作りです。
理由: アプリの「一番の価値（コア機能）」を作る段階です。1回の注文で複数商品を同時に扱える動的な仕組みを入れ、現場の入力ストレスを最小限に抑える狙いがあります。

ステップ6：入出庫・在庫管理機能

意味: 商品の入出庫履歴から、現在の「本当の在庫数」を全自動で計算する仕組みです。
理由: 在庫数を手入力させると「記入漏れ」や「数値の食い違い」が必ず起きます。モノの「出入り履歴」だけを記録し、引き算で在庫数を毎回自動算出する設計にすることで、データのズレを物理的に防ぎます。

ステップ7：ダッシュボード作成と起動テスト

意味: 経営状況が一目でわかる「コックピット画面」を作り、全体の動作を確認する最後の仕上げです。
理由: 部品がすべて揃った段階で、経営に必要な数値（売上や欠品リスク）を一画面に集約します。全体を接続して試運転し、実際の業務で使える状態へと仕上げます。

（参考1）「顧客管理アプリ」作成手順

AIアシスタント（Claude CodeやCursorなど）に順番に指示を貼り付けるだけで、全く同じアプリをゼロから構築できるプロンプト（指示文）集です。

準備：パソコンでの下準備

コマンドプロンプトやターミナルを開き、アプリを作るための空フォルダを作成して移動します。

Bash

mkdir customer_app
cd customer_app

ステップ1：プロジェクトの基本設定

最初のプロンプトをAIに送信します。Webサーバーの土台と必要なライブラリを準備させます。

プロンプト 1

Python + FastAPI + SQLite を使って「顧客管理アプリ」を作成します。

まず、以下の基本ファイルを生成し、環境をセットアップしてください。

requirements.txt（fastapi, uvicorn, sqlalchemy, jinja2, python-multipart, passlib[bcrypt], python-dotenv を指定）

.env および .env.example（SECRET_KEY, ADMIN_USERNAME=admin, ADMIN_PASSWORD=admin1234 を設定）

.gitignore（.venv, app.db, .env などを除外）

Python仮想環境 .venv を作成し、requirements.txt のパッケージをインストールしてください。

ステップ2：データベース（データ構造）の定義

データを保存する箱（テーブル）を定義させます。顧客、商品、受注、入出庫など8つのデータを扱います。

プロンプト 2

データの構造を定義するため、app/database.py と app/models.py を作成してください。

作成するテーブル構造：

employees（従業員・ログイン用）：ID, ユーザー名, ハッシュ化パスワード, 氏名, 管理者フラグ

customers（顧客）：ID, 顧客名, フリガナ, 電話番号, メール, 住所, 備考

categories（商品カテゴリ）：ID, カテゴリ名

suppliers（仕入先）：ID, 仕入先名, 担当者, 電話番号, 住所

products（商品）：ID, 商品名, 型番, カテゴリID, 販売単価, 備考

orders（受注親データ）：ID, 顧客ID, 担当従業員ID, 受注日, 備考

order_items（受注明細）：ID, 受注ID, 商品ID, 数量, 販売単価

stock_movements（入出庫履歴）：ID, 商品ID, 種別(入庫/出庫), 数量, 日時, 仕入先ID(任意), 受注ID(任意), 備考

SQLite接続用の database.py と、上記テーブルを再現する SQLAlchemy モデル models.py を定義してください。

ステップ3：安全に使うための「ログイン機能」

関係者以外のアクセスを防ぐセキュリティと、初期管理者の自動登録を設定します。

プロンプト 3

アプリのログイン機能と共通レイアウトを作成してください。

app/security.py: パスワードを暗号化（ハッシュ化）・検証する関数（bcrypt使用）

app/dependencies.py: ログイン判定（未ログイン時はログイン画面へ誘導）および管理者権限判定の処理

app/main.py: アプリ起動時に employees テーブルが空なら .env の情報で初期管理者アカウントを自動作成する処理

app/templates/base.html: スマホ対応（Bootstrap 5）の共通ナビゲーションバー（レスポンシブ対応）

app/templates/login.html & app/routers/auth.py: ログイン・ログアウト処理と画面

ステップ4：基本データ（マスター）の管理画面

顧客・商品・仕入先などの登録・編集・削除画面を一括作成させます。

プロンプト 4

以下のマスター管理機能（CRUD）を一覧・登録・編集・詳細画面付きで作成してください。

顧客管理 (routers/customers.py, templates/customers/)

商品カテゴリ管理 (routers/categories.py, templates/categories/)

仕入先管理 (routers/suppliers.py, templates/suppliers/)

商品管理 (routers/products.py, templates/products/)：登録時にカテゴリを選択可能にする

従業員管理 (routers/employees.py, templates/employees/)：管理者権限を持つユーザーのみ操作可能にする

ステップ5：受注管理機能（複数商品の同時入力）

最も複雑な「1つの受注に複数の商品を追加する」機能をJavaScript連携付きで作成します。

プロンプト 5

受注管理機能を作成してください (routers/orders.py, templates/orders/)。

必須要件：

受注登録画面で「顧客」と「担当従業員」を選択できること。

JavaScriptを使い、「明細行を追加」ボタンで商品を動的に複数行追加・削除できるようにすること。

商品を選択した際、販売単価を自動セットすること。

受注詳細画面で、購入された商品の一覧と合計金額が正しく表示されること。

ステップ6：入出庫・在庫管理機能

在庫数を自動計算する仕組みを作成します。

プロンプト 6

在庫管理および入出庫履歴機能を作成してください。

app/stock_utils.py: stock_movements の**（入庫数 – 出庫数）を計算**して各商品の「現在の在庫数」を算出する共通ロジックを作成。

routers/stock.py & templates/stock/:

在庫一覧画面: 各商品の現在在庫数を表示。

入出庫登録画面: 手動での入庫・出庫登録（仕入先や受注IDとの紐付けが可能）。

受注画面からの連携: 受注詳細画面に「この受注から出庫登録」ボタンを配置し、出庫処理をスムーズに行えるようにする。

ステップ7：ダッシュボード作成と起動テスト

全体状況を一目で把握できるトップ画面を作成し、アプリを立ち上げます。

プロンプト 7

トップ画面となるダッシュボード機能を作成し、動作確認をしてください。

routers/dashboard.py & templates/dashboard.html:

顧客数、商品数、今月の受注件数などのサマリ表示

直近の受注一覧

在庫が少なくなっている商品（在庫数5以下など）の警告表示

最後に main.py に全てのルーターを登録し、uvicorn app.main:app --reload でサーバーを起動して動作確認を行ってください。

開発を進める際のアドバイス

1ステップずつ実行する: AIに一度に全部頼むとエラーが出やすくなります。上記のように1つの機能ごとに完了を確認しながら進めてください。
スマホ表示の確認: ブラウザの「検証ツール（F12）」でスマホ画面サイズ（幅375px程度）に切り替えると、レイアウト崩れがないかチェックできます。

主要なコアファイルの中身を確認してから、ディレクトリ構成全体を説明します。

（参考2）ディレクトリ構成と各ファイルの役割

こきゃ_顧客管理/
├── .claude/
│   └── launch.json          # Claude Code Browserプレビュー用のサーバー起動設定
├── .venv/                   # Python仮想環境（依存パッケージの実体）
├── .env                     # 環境変数の実値（SECRET_KEY, ADMIN_USERNAME, ADMIN_PASSWORD）※gitignore対象
├── .env.example             # .envのひな形（実値なし）
├── .gitignore
├── app.db                   # SQLiteデータベース本体（初回起動時に自動作成）
├── requirements.txt         # 依存パッケージ一覧
├── README.md                # セットアップ・起動手順
│
└── app/                      # アプリ本体
    ├── main.py               # FastAPIエントリポイント。ミドルウェア設定・DB初期化・ルーター登録
    ├── database.py            # DBエンジン/セッション定義（SQLite接続、get_db依存関数）
    ├── models.py               # SQLAlchemyのテーブル定義（後述）
    ├── dependencies.py         # ログイン必須(require_login)・管理者限定(require_admin)の認可チェック
    ├── security.py              # パスワードのハッシュ化・検証（bcrypt）
    ├── stock_utils.py            # 在庫数の算出ロジック（入出庫履歴のSUMから計算）
    │
    ├── routers/                 # 機能別のエンドポイント定義（FastAPI Router）
    │   ├── auth.py                # ログイン・ログアウト
    │   ├── dashboard.py            # ダッシュボード（サマリ表示）
    │   ├── customers.py             # 顧客CRUD
    │   ├── categories.py             # 商品カテゴリCRUD
    │   ├── suppliers.py               # 仕入先CRUD
    │   ├── products.py                 # 商品CRUD
    │   ├── orders.py                    # 受注CRUD（複数明細対応）
    │   ├── stock.py                      # 入出庫登録・在庫一覧・入出庫履歴
    │   └── employees.py                   # 従業員CRUD（管理者限定）
    │
    ├── templates/                # Jinja2テンプレート（画面のHTML）。routers配下の各機能に対応したサブフォルダ構成
    │   ├── base.html               # 共通レイアウト（ナビゲーション等）
    │   ├── login.html
    │   ├── dashboard.html
    │   ├── customers/ (list/detail/form)
    │   ├── products/ (list/detail/form)
    │   ├── orders/ (list/detail/form)
    │   ├── categories/list.html
    │   ├── suppliers/list.html
    │   ├── employees/ (list/form)
    │   └── stock/ (list/form/movements)
    │
    └── static/css/style.css    # 画面用のカスタムCSS

設計上のポイント

認証の仕組み(dependencies.py) セッションにemployee_idを保存する方式。require_loginが未ログインを検知すると例外を投げ、main.pyのexception_handlerでログイン画面へリダイレクトします。require_adminはさらにis_adminフラグをチェックし、従業員管理を管理者限定にしています。

テーブル構成(models.py) employees / customers / categories / suppliers / products / orders / order_items / stock_movements の8テーブル。ordersとorder_itemsは1対多（受注に複数の商品明細）、stock_movementsはproduct_idに加えてsupplier_id（入庫元）とorder_id（出庫先）を任意で持てる設計になっており、これが「入庫元・出庫先の紐付け」を実現しています。

在庫は専用テーブルを持たない(stock_utils.py) 在庫数カラムは存在せず、stock_movementsの「入庫はプラス・出庫はマイナス」をSUMして都度算出しています。テーブルを1つ減らせる代わりに、履歴が増えるほど集計コストは上がる設計です。

初回起動時の管理者アカウント自動作成(main.py:32-48) employeesテーブルが空の場合のみ、.envのADMIN_USERNAME/ADMIN_PASSWORDから管理者を1件作成します。2回目以降の起動では作られません。