atelier-kyo-manager
BUYMA販売管理システム。出品パイプライン・自動発注ステートマシン・ AIチャットボット・価格スクレイピングWebサイトのページを読み込んで、必要な情報(価格・在庫等)を自動で抜き出すことを統合したFlaskPythonでWebアプリや管理画面を軽く作るためのフレームワーク。必要最小限の機能だけを提供する「軽量」設計が特徴で、小規模な社内ツール等に向くアプリ。
なぜ作ったか
BUYMA(海外ブランドの買い付け代行プラットフォーム)での販売業務は、出品・価格調整・発注・顧客対応など多岐にわたる手作業が発生します。これらをFlask Webアプリ + AI/LLMで自動化し、1人でもスケール可能な物販システムを目指して開発しました。
アーキテクチャ
Flask App Factory (create_app)
├── Blueprint (6モジュール) ← HTTPルーティング
│ analytics / orders / partners / products / misc / warehouse_webhook
├── Service層 (8モジュール) ← ビジネスロジック
│ auto_order / chatbot / image / notification / pipeline
│ price_scraper / template / warehouse_event
├── Models (16種) ← SQLAlchemyデータモデル
├── Utils (20+モジュール) ← ai_llm_controller / fx_utils / pricing_calculator 等
└── Templates / Static ← Jinja2 + CSS/JS
設計のポイント: FlaskのBlueprint + Service層の2層構造にすることで、ルーティング(Blueprint)とビジネスロジック(Service)を分離。テスト時にService層だけを単体テスト可能にしています。
主要ビジネスロジック
自動発注ステートマシン
注文の状態遷移を自動管理する仕組みです:
pending → sourcing → cart_added → checkout → payment_done → shipped → completed
各状態遷移にはガード条件(遷移可能かの判定)があります。例えば sourcing → cart_added に遷移するには「仕入先の在庫確認が完了していること」が必要です。
出品パイプライン
画像収集 → AI背景除去(rembg) → AI説明文生成(LLM) → 出品テキスト生成 → BUYMA出品
各ステップが独立しているため、途中で失敗しても再開可能です。
AIチャットボット(3段階分類)
顧客からの問い合わせを3段階で処理します:
- FAQテンプレートマッチ: 既知の質問パターンに一致するか確認
- AI回答生成: 一致しない場合、LLMで回答を生成
- エスカレーション判定: AIが自信を持てない場合は人間(私)に通知
なぜ3段階にしたか: 全ての問い合わせをAIに任せると不正確な回答のリスクがある。FAQで確実に回答できるものは高速に処理し、AIが必要なものだけLLMを使うことで、品質とコストのバランスを取っています。
価格スクレイピング
Playwrightヘッドレスブラウザで仕入先の価格を自動取得します。
なぜrequests/BeautifulSoupではなくPlaywrightか: 仕入先サイトがJavaScriptレンダリングに依存しているため、静的HTMLの取得では価格情報が取得できませんでした。Playwrightなら実際のブラウザと同じようにJSを実行してからDOMを取得できます。
18日ルール管理
BUYMAには「18日以内に発送しないとキャンセルされる」ルールがあります。決済方法によって延長期限が異なるため、これを自動計算・管理します:
| 決済方法 | 延長期限 |
|---|---|
| クレジットカード | 45日 |
| 銀行振込 | 90日 |
| コンビニ決済 | 30日 |
面接で聞かれそうなポイント
「なぜFlask?DjangoPython用の「全部入り」Webフレームワーク。管理画面・ユーザー認証・データベース操作等が最初から揃っている。大規模向けだが、小さい用途には過剰になりがちではない理由」
- atelier-kyo-managerは管理画面 + APIApplication Programming Interface(エーピーアイ)の略。あるプログラムの機能を、別のプログラムから呼び出せるようにした「窓口」。予約システムがLINE社の機能とやり取りするのもAPI経由の構成で、DjangoのORM/admin/templates等の「全部入り」機能が不要だった
- Flaskの方が軽量で、必要なライブラリ(SQLAlchemy / Playwright / rembg等)を自由に選べる
- 結果的にFlask App Factory + Blueprintの構成で十分スケールした
「なぜSQLite?PostgreSQLではない理由」
- 個人利用のシステムで同時接続数が少ないため、SQLiteで十分
- デプロイ作ったプログラムを、実際に動くサーバーや公開環境へ設置して動かし始めることが簡単(サーバー不要、ファイル1つで完結)
- 将来的にスケールする必要があれば、SQLAlchemy経由でPostgreSQLに移行可能(モデル層の変更なし)
技術スタック
- PythonAI・データ分析の分野で最も使われるプログラミング言語(読み: パイソン)。AI関連の道具が最も豊富で、文法が読みやすいのが特徴 3.10+ / Flask / SQLAlchemy
- Playwright(ヘッドレスブラウザ)
- pytest(2,000+テストケース)
- rembg(AI背景除去)
用語の平易な解説(専門用語を読み解く)
🌶️ Flask(フラスク)・Django(ジャンゴ)
一言で: 「PythonでWebアプリを作るための枠組み(フレームワーク)」。
- フレームワーク: アプリを作る際の基本骨組み。土台が用意されているので、肉付けだけ済む
- Flask: 必要最小限の軽量な枠組み。必要な部品だけ選んで組み合わせられる
- Django(ジャンゴ): 管理画面・DB処理・画面表示等が「全部入り」の重量級枠組み
- 本章では「全部入りのDjangoは過剰だったので、軽量なFlaskを選んだ」
🏭 App Factory(アプリファクトリー)・Blueprint(ブループリント)
一言で: 「Flaskアプリを整理整頓するための仕組み」。
- App Factory: アプリ本体を「工場(ファクトリー)」のように生成する作り方。テスト時に設定を切り替えやすくなる
- Blueprint(青写真): アプリの機能を「注文管理」「商品管理」等のブロックに分けて整理する仕組み。1つの巨大ファイルにならないよう分割
🧠 Service層(サービスそう)・ビジネスロジック
一言で: 「画面表示と切り離した、業務ルールの詰め所」。
- ビジネスロジック: 「18日以内に発送しないとキャンセル」「クレジット決済は45日まで延長可」等の業務ルール
- Service層: この業務ルールだけを集めた階層。画面の見た目(ルーティング)と分離することで、ルールだけ単体テストできる
🗄️ SQLAlchemy(エスキューエルアルケミー)・ORM
一言で: 「データベースを、Pythonのオブジェクトのように扱える仕組み」。
- ORM(オブジェクト関係マッピング): データベースの表(テーブル)と、プログラム内のデータ(オブジェクト)を自動で結びつける技術。SQL文を直接書かずにデータ操作できる
- SQLAlchemy: Python界隈の代表的なORM道具
- データモデル: 「商品には名前・価格・在庫がある」のような、データの形を定義した設計
🚦 ステートマシン・状態遷移・ガード条件
一言で: 「注文が『注文受け→仕入→発送→完了』と状態を変えていく仕組みと、次の状態へ進むための条件」。
- ステートマシン(状態機械): 状態が決まったルールで移り変わっていく仕組み
- 状態遷移: 「Aの状態からBの状態へ変わること」
- ガード条件: 次の状態へ進むための条件。「在庫確認が済んでいないと仕入→カート追加へ進めない」等
🕷️ スクレイピング・Playwright(プレイライト)・ヘッドレスブラウザ
一言で: 「Webサイトの情報を自動で集める技術」と「目に見えないブラウザ」。
- スクレイピング: Webサイトの画面からデータを自動収集する技術。本章では仕入先の価格を自動取得
- ヘッドレスブラウザ: 画面(頭部=ヘッド)を持たないブラウザ。人間の目には映らないが、裏でWebページを開いて操作できる
- Playwright: ヘッドレスブラウザを操作する道具
- DOM(ドム): Webページの構造を表すデータ。プログラムから「この部分のテキスト」を読み取る際の対象
- JavaScriptレンダリング: ページを表示するためにJavaScriptを実行すること。Playwrightはこれを再現できるので、動的に表示される価格も取得可能