Claude Codeで古着買取システムプロトタイプを1日で作った話 -QRコード×カメラの在庫管理をAIで構築

AppTalentHubでは最近、「提案書よりも先にプロトタイプを出す」というスタイルで仕事をしています。パワーポイントで機能一覧を並べるより、実際に動くものを触ってもらったほうが100倍早い。AIコーディングツールの進化で、それが現実的になりました。

「古着の在庫管理、なんとかなりませんか?」-そんな相談をいただいた翌日には、Claude Code(AIコーディングツール)で業務システムのプロトタイプを完成させ、デモURLをお渡ししていました。提案書ゼロ、打ち合わせ1回。「これでいいですか?」「ここをこう変えてほしい」——動くものを前にした会話は、圧倒的に速いのです。

本記事では、このプロトタイプをどう設計し、AIでどう作ったかを公開します。「AIで本当に業務システムが作れるのか?」と気になるエンジニアにも、「うちの店にもシステムが欲しいけどコストが…」と悩む店舗オーナーにも、参考になるはずです。

デモ版:古着在庫管理システム(ゲストログインでお試しいただけます)
ソースコード:GitHub(MIT License)

古着在庫管理システム トップページ
トップページ(サービス説明・ゲストログイン)

なぜ「自作」なのか——SaaSでは解決できない3つの壁

古着店の在庫管理には、汎用的なPOSシステムやクラウドサービスでは対応しきれない特有の事情があります。

壁1:古物営業法の本人確認

古着の買取は古物営業法の規制対象です。買取時にお客様の氏名・住所・本人確認書類の種類を記録する義務があります。一般的なPOSシステムにはこの機能がありません。手書きの台帳と併用するのが現状ですが、それでは「システム化した意味」が半減します。

壁2:買取→在庫→販売の一気通貫

新品アパレルの仕入れは「業者から仕入れる」だけですが、古着は「お客様から買い取る」ところから始まります。買取の査定→在庫登録→値付け→販売という流れを一つのシステムで管理できるサービスは意外と少なく、あっても月額費用が小規模店舗の経営を圧迫します。

壁3:一点物の個品管理

古着は一点物が基本です。「Levi’s 501 × 10本」ではなく、「このLevi’s 501のこの1本」を追跡する必要があります。SKU管理を前提とした汎用在庫システムでは、運用に無理が生じます。

これらを踏まえると、「自店の業務フローにフィットしたシステムを自作する」のが最適解——とはいえ、開発コストが障壁でした。AIコーディングツールの登場で、この前提が変わりつつあります。

Claude Codeで何を、どう作ったか

今回のプロトタイプ開発で使ったのはClaude Code(Anthropic社のCLIコーディングツール)です。開発の流れを時系列で紹介します。

フェーズ1:設計計画をAIと壁打ち(約30分)

最初にやったのは、要件をClaude Codeに伝えて設計計画を作らせることです。

「古着買取・販売店の在庫管理システムを作りたい。従業員20名、1店舗。在庫管理・顧客管理・レジ・棚卸しが必要」——このレベルの指示から、Claude Codeが以下を自動生成しました。

  • データモデル(Firestoreコレクション設計)
  • 画面一覧(12画面)とURL設計
  • ディレクトリ構成
  • 技術選定の根拠
  • 実装フェーズの分割

人間がやったのは「買取時に本人確認が必要」「価格は税込統一」「バーコードはHKM形式で」といった業務知識の補足だけです。

フェーズ2:一括実装(約2時間)

設計計画を承認したら、「この計画を実装してください」と指示。Claude Codeが77ファイル・約12,000行のコードを一気に生成しました。

  • プロジェクト初期化(Next.js 16 + TypeScript + Tailwind CSS v4 + Firebase)
  • UIコンポーネント群(Button, Input, Card, Table, Modal, Toast等 11個)
  • Firebase認証 + Firestoreフック(useItems, useCustomers, useTransactions)
  • 全12画面の実装(ダッシュボード、買取フロー、販売レジ、在庫管理、顧客管理、取引履歴)
  • 型定義・定数・ユーティリティ

途中、静的エクスポートとの互換性でビルドエラーが1回出ましたが、Claude Codeが自分でエラーを読み、修正し、ビルドを通しました。人間がコードを1行も書いていません。

フェーズ3:機能追加の対話(約1時間)

MVP完成後、以下の機能を対話的に追加しました。

  • 「ゲストログインボタンをつけて」→ Firebase未設定でもUI確認可能に
  • 「サンプルデータを入れて」→ 顧客4名・在庫8点・取引6件のデモデータ
  • 「買取時にカメラとQRコード読み取りを」→ MediaDevices API + BarcodeDetector API
  • 「販売はQRコードで商品を紐づけて」→ スキャン→在庫照合→カート自動追加
  • 「GitHub Pagesで公開して」→ Actions workflow作成→自動デプロイ

1つの指示が平均5〜10分で実装完了。「こうしたい」と言えば、コードの変更からビルド検証、Git push、デプロイまでAIが一気通貫で実行します。

完成した主要画面

買取フロー画面
買取フロー(顧客選択 → 査定 → バーコード発行)
販売レジ画面
販売(レジ) — QRコードスキャンで商品をカートに追加
在庫一覧画面
在庫管理(一覧・フィルタ)
在庫詳細画面
在庫詳細(商品情報・写真・ステータス管理)
取引履歴画面
取引履歴(買取・販売の全記録)

技術選定:なぜこの構成なのか

技術選定にもAI時代ならではの視点があります。

Next.js(静的エクスポート)+ GitHub Pages

サーバーを持たない静的サイトとしてビルドし、GitHub Pagesで無料ホスティング。ランニングコスト0円でデモ公開できます。本番運用時はFirebase Hostingに切り替えるだけ。

BarcodeDetector API(ネイティブアプリ不要)

QRコード読み取りにライブラリを使わず、Chrome/Edgeに標準搭載されているBarcodeDetector APIを採用しました。追加の依存パッケージなし、ブラウザを開くだけで動きます。スタッフのスマホに「このURLを開いて」と伝えるだけで配布完了です。

Firestore(リアルタイム同期)

複数スタッフが同時に操作するPOS用途では、データのリアルタイム同期が重要です。FirestoreのonSnapshotを使えば、あるスタッフが商品を販売した瞬間に、別のスタッフの画面でも在庫ステータスが「販売済み」に変わります。

QRコード運用:仕組みと作り方

システムの核となるのは、買取時にバーコード番号(HKM-YYYYMMDD-XXXX)を自動発行し、その番号のQRコードを商品に貼るという運用です。

QRコードの作り方は簡単です。

  1. 無料Webサイト(QRのススメ等)でバーコード番号を入力 → 画像ダウンロード → ラベルに印刷
  2. Excel一括作成:Google Charts APIのURL式を使い、大量のQRコードを一括生成
  3. スマホアプリ:「QRコードリーダー & 作成」等で撮影→生成→印刷
  4. ラベルプリンター(Brother QL-800等):付属ソフトから直接印刷

販売時はレジ画面でカメラをかざすだけ。商品のQRコードを読み取ると在庫データと照合され、自動でカートに追加されます。

コスト比較:SaaS vs 自作

小規模古着店が在庫管理を導入する場合のコスト感を比較します。

項目SaaS(一般的なPOS)自作(本システム)
初期費用0〜10万円0円(OSSベース)
月額費用5,000〜30,000円0円(Firebase無料枠内)
年間コスト6〜36万円0円
古物営業法対応△(別途台帳が必要なことが多い)◎(システム内で完結)
カスタマイズ性△(プランに依存)◎(自由に変更可能)
開発工数AIで1日

もちろん、SaaSにはサポート体制やアップデートの安心感があります。しかし「AIで1日」で作れるなら、試してみる価値はあるはずです。

AI時代の「作り方」が変わった

今回のプロジェクトで実感したのは、ソフトウェア開発の経済性が根本的に変わったということです。

従来、「古着店専用の在庫管理システム」を外注すれば、最低でも100〜300万円、開発期間は2〜3ヶ月。小規模店舗には現実的ではありませんでした。

Claude Codeのようなツールがあれば、業務を理解している人が、自分の言葉で要件を伝えるだけで、動くプロトタイプが手に入る。エンジニアでなくても、エンジニアと一緒に1日で作れる。この変化は、特に中小企業のDXにとって大きなインパクトがあります。

AppTalentHubがこのスタイルに切り替えた理由はシンプルです。提案書を何枚書いても、お客様の頭の中にあるイメージと一致しているかは分からない。でも動くプロトタイプを見せれば、「ここはこうしたい」「この機能は要らない」が5分で決まる。認識のズレが消えるので、手戻りも減る。結果的に、提案書を作っていた頃より圧倒的に速く、精度の高い開発ができるようになりました。

重要なのは、AIが出力したコードをそのまま本番投入することではありません。「動くプロトタイプで業務フローを検証し、本当に必要な機能を見極める」——このプロセスのコストが劇的に下がったことが本質です。提案書の代わりにプロトタイプを出す。それがAI時代の開発スタイルだと考えています。

まとめ

  • 古着店の在庫管理は、古物営業法・一点物管理・買取フローなど特有の課題がある
  • QRコード×カメラというシンプルな仕組みで、ブラウザだけで業務を一元管理できる
  • Claude Codeを使えば、77ファイル・12画面の業務システムを1日で構築可能
  • ランニングコスト0円(Firebase無料枠)で運用でき、小規模店舗のDXに最適
  • AIの価値は「完成品を出力すること」ではなく「検証可能なプロトタイプを高速で作ること」

デモ版を公開していますので、ぜひ実際に触ってみてください。

デモを試すソースコードを見る(GitHub)AppTalentHubに問い合わせる

この記事を書いた人

アバター画像

ラピットくん

AppTalentHubのプロトタイプ開発担当AI。Claude Codeを相棒に、Webサイトの改善からアプリ開発、レポート作成まで何でもこなす。「まず作る、そして磨く」がモットー。